JP2008537266A

JP2008537266A - 適応性のあるデータクリーニング

Info

Publication number: JP2008537266A
Application number: JP2008507805A
Authority: JP
Inventors: ブラッドリー，ランドルフ・エル
Original assignee: Boeing Co
Current assignee: Boeing Co
Priority date: 2005-04-20
Filing date: 2006-04-17
Publication date: 2008-09-11
Also published as: EP1883922A2; CA2604694A1; WO2006113707A2; US20060238919A1; WO2006113707A3; KR20080002941A; IL186958A0; AU2006236390A1; EP1883922A4

Abstract

データクリーニングプロセスは、少なくとも２つのソースシステムからロードされたデータを検証するステップと、検証されたデータを正規化データクリーニングリポジトリに付加するステップと、ソースシステムの優先順位を選択するステップと、クリーンなデータベースを作成するステップと、クリーンなデータベースからの矛盾がなく、正規化され、かつ、クレンジングされたデータを、当該データを用いるデータシステムおよびソフトウェアツールが必要とするフォーマットにロードするステップと、レポートを作成するステップと、ソースシステムを更新することなくユーザによってクリーンなデータベースを更新するステップとを含む。データクリーニングプロセスは、矛盾のない分析を可能にする最適化モデルのために、異なるソースからのデータを収集および分析するプロセスを標準化する。データクリーニングプロセスはさらに、動的なデータセットを用いるデータシステムおよびソフトウェアツールの入力および出力に対する完全な監査可能性を提供する。データクリーニングプロセスは、たとえばサプライチェーン管理のために、軍用および商用の両方の航空機産業における応用例に適しているが、これに限定されない。

Description

関連出願との相互参照
この出願は、２００５年４月２０日に出願された米国仮出願番号第６０／６７３，４２０号の利益を主張する。

発明の背景
この発明は概してデータの処理および管理プロセスに関し、より詳細には、適応性のあるデータクリーニングのプロセスおよびシステムに関する。

実世界の大型のデータセットの品質はいくつかの問題に依存するが、データのソースが決定的な要因である。データのエントリおよび取得は、本質的に、単純なエラーおよび複雑なエラーの両方を被りやすい。エントリエラーの低減に関してこのフロントエンドプロセスに対してしばしば非常に努力が行なわれるが、大型のデータセットの中のエラーはよく起こるという事実が多くの場合残る。大型のデータセットについてのフィールドエラー率は、典型的にはおよそ５％以上である。データ分析に必要な時間の半分までは、典型的にはデータのクリーニングのために費やされる。概して、データクリーニングは大型のデータセットに適用される。データクリーニングは、大型のデータセットの精度を向上させるための、データをかき集める（scrubbing）プロセスである。理想的には、データクリーニングは、明白な転写エラーを排除できるべきであり、誤った部品番号または無効なコードなどの誤ったエントリを補正できるべきであり、価格付けまたはリードタイムなどの欠落したデータを更新できるべきであり、データの複数のソースおよび定義が存在し得ることを認識できるべきである。効果的なデータクリーニングは、ルールに基づいたまたは手動の選択の根拠を説明するために電子注釈を組入れるべきであり、監査証跡を提供すべきであり、操作が容易であるべきである。

データクリーニングはしばしば、骨が折れ、時間がかかり、かつエラーを被りやすい手動のプロセスを使用してなされる。その結果、大型のデータセットの中のエラーを自動検出できる方法またはエラーの検出を助ける方法が非常に興味深い。自動化されたデータクリーニングのプロセスは典型的には多面的であり、任意の特定のデータクリーニングの問題を解決するためにはいくつかの問題に対処しなければならない。概して、起こり得るエラータイプを定義および決定する必要があり、エラーの検索を行なう必要があり、エラーを識別する必要があり、発見されたエラーを補正する必要がある。

たとえば、ｉ２テクノロジーズ（i2 Technologies）、ＩＢＭ、マニュジスティックス（Manugistics）、ＭＣＡソリューションズ（MCA Solutions）、システムズ・エクスチェンジ（Systems Exchange）、またはゼルス（Xelus）などの現在のサプライチェーンソフトウェアソリューションのベンダーは、内部データ構造を十分に開発し、考案してきた。これらの構造は、顧客のソースシステムにマッピングされなければならず、定期的に更新されなければならない。このマッピングは、実行中には「ハードワイヤード」であり、ソースまたはビジネスルールが変化したときには記録を必要とする。さらに、サプライチェーンソフトウェアへのローディングに先立って顧客データを記憶する中間データベースの開発がしばしば必要である。また、現在のサプライチェーンソフトウェアソリューションは、結果のアーカイブ、その結果に繋がる入力のアーカイブ、または時の経過に伴うデータのバージョニングを支援しない。これは、たとえば航空機、トラック、船または機械な
どの重機のストックの推奨に繋がる決定プロセスを顧客が監査することを妨げる。寿命が長い重機などの修理可能なアイテムについてのサービス部品のストックレベルが数千万ドルから数億ドルに達するので、監査可能性は多くの顧客にとって重要な要件である。

ソースシステムと中間データベースとの間のギャップを橋渡しするために、抽出、変換およびロード（Extract, Transform, and Load）（ＥＴＬ）ツールが典型的に使用される。ＥＴＬツールは、データベースソフトウェアの１つのオペレーティングシステムおよびブランドから別のものにデータを変換するために使用される。ＥＴＬツールは、データを変換およびフィルタリングするために限られたビジネスルールを適用する。ＥＴＬツールは、同じデータの複数のソースを扱うようには設計されていない。さらに、ビジネスルールは、データの複数のソースに適用されると、データ収集プロセス中に適用され、これは２つ以上のデータのソースに対する変更が後で目に見えるようになることを排除する。ＥＴＬツールはまた、時の経過に伴うデータの変更を追跡することを含むデータのバージョニングを支援しない。

２０００年に、アメリカ合衆国マサチューセッツ州ハーバード（Harvard）のベンタナ・システムズ・インコーポレイテッド（Ventana Systems, Inc）は、Ｃ−１７空輸プログラムのためのサプライソフトウェアソリューションについて、アメリカ合衆国カリフォルニア州ロングビーチ（Long Beach）のボーイング・カンパニー（Boeing Company）のためにデータクリーニングソリューションを開発した。この先行技術のクリーニングソリューションは、オラクル（Oracle）およびＣ⁺⁺で書かれており、エクセル（Excel）（登録商標）のようなユーザインターフェイスを有する。このデータクリーニングソリューションは、ユーザがデータベースにおけるデータを変更でき、変更されたデータを色分けすることによって、データに対する変更が単純な決定ツリー論理を使用して時の経過に伴って持続可能であるようにする方法を開発することによって、およびクリーニングしたいと思うデータ要素をユーザが選択できるようにすることによって、先行技術を進歩させている。それでも、この先行技術のデータクリーニングソリューションにはいくつかの制約が組入れられている。たとえば、サプライチェーンソフトウェアソリューションは、データのカプセル化の使用に対して、任意のルーチンによって変更され得る大域変数（global variable）を使用し、データクリーニングソリューションは、維持することを困難にする複雑な内部データ構造を使用し、アプリケーションによるデータのローディングは厳密な手順に準拠しなければならず、そうでなければデータは破損する可能性がある。

分かるように、自動化されかつ複数のソースからのデータの選択を可能にするデータクリーニングのための方法が必要である。さらに、結果のアーカイブ、その結果に繋がる入力のアーカイブ、または時の経過に伴うデータのバージョニングのための支援を可能にするデータクリーニングプロセスが必要である。さらに、既存のデータ管理システムに容易に組込むことができるデータクリーニングプロセスが必要である。

したがって、標準化された手順を提供し、企業の共通のデータウェアハウスプロジェクトを補完し、複数のソースからデータを選択するデータクリーニングのためのプロセスを提供する必要が生じてきた。さらに、異なる顧客が表面上同じデータ要素の異なるソースを見る必要があるかもしれないこと、および理論的には同じデータであるべきものの複数のバージョンが存在する可能性があることを認識するデータクリーニングのためのプロセスを提供する必要が生じてきた。さらに、分析のために使用されるデータおよび分析の結果の両方をアーカイブできる、適応性のあるデータクリーニングのためのプロセスを提供する必要が生じてきた。

発明の概要
この発明の一局面においては、データクリーニングプロセスは、データフォーマッティングユーティリィティおよびデータクリーニングユーティリィティを用いて、少なくとも２つのソースシステムからロードされたデータを検証するステップと、検証されたデータを正規化データクリーニングリポジトリに付加するステップと、ソースシステムの優先順位を選択するステップと、クリーンなデータベースを作成するステップと、固有のデータ識別子間の相互参照を作成および維持するステップと、クリーンなデータベースからの矛盾がなく、正規化され、かつ、クレンジングされたデータを、当該データを用いるデータシステムおよびソフトウェアツールが必要とするフォーマットにロードするステップと、当該矛盾がなく、正規化され、かつ、クレンジングされたデータを用いて標準化データクリーニングおよび管理レポートを作成するステップと、ソースシステムを更新することなくユーザにより当該矛盾がなく、正規化され、かつ、クレンジングされたデータを更新するステップとを含む。クリーンなデータベースは、少なくとも２つのソースシステムからの各データ要素のための固有のデータ識別子を含む。

この発明の別の局面においては、サプライチェーンのためのデータクリーニングプロセスは、複数のソースシステムからデータ要素およびソースのマスタテーブルにデータをロードするステップと、ソースシステムの優先度を選択するステップと、高ドライバおよびエラーレポートを検討するステップと、データ要素およびソースのマスタテーブルに含まれるロジスティックスデータをクリーニングするステップと、データ要素およびソースのマスタテーブルの矛盾がなく、正規化され、かつ、クレンジングされたデータを承認し、当該クレンジングされたデータを、当該データを用いるデータシステムおよびソフトウェアツールに供給するステップと、当該クレンジングされたデータを用いて、戦略的在庫表最適化モデルを用いるストックレベルおよび発注点の在庫表最適化を開始するステップと、ストックレベルおよび発注点の推奨を含む予備品分析を行うステップと、顧客監査証跡のための支援データをアーカイブするステップと、レポートを作成するステップと、当該レポートに従って不足をカバーするよう予備品を購入するステップとを含む。

この発明のさらに他の局面においては、データクリーニングシステムは、データフォーマッティングユーティリィティ、データクリーニングユーティリィティ、正規化データクリーニングリポジトリ、ソース優先順位付けユーティリィティ、クリーンなデータベース、相互参照ユーティリィティ、およびデータクリーニングユーザインターフェースを含む。データフォーマッティングユーティリィティは、少なくとも２つのソースシステムからダウンロードされたデータを検証するのに用いられる。データクリーニングユーティリィティはデータをクリーニングするのに用いられる。ソース優先順位付けユーティリィティは、少なくとも２つのソースシステムの優先順位を選択するのに用いられる。正規化データクリーニングリポジトリは、フォーマットされ、かつ、クレンジングされたデータを受信する。クリーンなデータベースはクレンジングされたデータと優先順位が付けられたデータとを組み合わせる。クリーンなデータベースは、各データ要素のための最良値および固有のデータ識別子を含むアイテムデータの単一のソースである。相互参照ユーティリィティは、固有のデータ識別子間の相互参照を作成および維持するのに用いられる。データクリーニングユーザインターフェースにより、ユーザがクリーンなデータベースを更新することが可能となる。

この発明のこれらおよび他の特徴、局面および利点は、添付の図面、以下の説明および添付の特許請求の範囲を参照するとよりよく理解されるだろう。

発明の詳細な説明
以下の詳細な説明は、現在のところ考えられる、この発明を実施する最良の形態である。この発明の範囲が添付の特許請求の範囲によって最もよく規定されるので、この説明は
限定的な意味で取られるべきではなく、この発明の一般的な原理を例示する目的でのみなされる。

概して、この発明は、最適化モデルのために異なるソースからのデータを収集および分析するプロセスを標準化する、適応性のあるデータクリーニングのプロセスおよびシステムを提供する。この発明はさらに、時の経過に伴って変化する動的なデータセットを使用して周期的に実行される最適化モデルまたは他のツールもしくはモデルの入力および出力に対して完全な監査可能性を与えるデータクリーニングプロセスを概して提供する。この発明の一実施例におけるような適応性のあるデータクリーニングのプロセスおよびシステムは、矛盾がない分析を可能にし、１回限りのデータベースの符号化を排除し、変化するデータソースに合わせるのに必要な時間を低減し、たとえば在庫表最適化モデルのためにまたはサプライチェーンの提案の展開中に使用され得る。この発明の一実施例は、たとえばサプライチェーン管理についての、軍用機産業および民間航空機産業の両方での適用例に好適であるがそれに限定されないデータクリーニングプロセスを提供する。この発明の一実施例は、寿命が長い重機を利用する産業での適用例にさらに好適であるがそれに限定されないデータクリーニングプロセスを提供する。大型のデータベースを管理する必要がある場合、データベースが複数のソースからデータを受信する場合、たとえばいくつかのサブ組織からのデータを組合せる必要がある大企業の場合、および管理されるべきデータが運送業における重機などの高価値の商品に関連する場合に、この発明の一実施例におけるようなデータクリーニングプロセスが使用され得る。さらに、たとえば在庫表の管理、注文の管理、消費者データの管理のために、または工業用メンテナンスに関連して、この発明の一実施例におけるようなデータクリーニングプロセスが使用され得る。

一実施例では、この発明は、複数のソースからデータを選択し、優先度に基づくヒューリスティックス（heuristics）を使用して複数のソースから最良のソースを選択し、予測のために最良値を選択するデータクリーニングプロセスを提供する。既存のＥＴＬ（抽出、変換およびロード）ツールは、同じデータの複数のソースを扱うようには設計されていない。現在のＥＴＬツールは、複数のソースからデータをロードし得るが、別のソースに優先して１つのソースを選択するためにカスタム論理を作成するようにソフトウェア開発者またはユーザに要求し得る。さらに、ソフトウェア開発者またはユーザの手動の介入なしに典型的なＥＴＬツールを最初に組込んだ後は、ソースを追加または削除できない。先行技術に反して、この発明の一実施例におけるようなデータクリーニングプロセスによって、無限の数のデータ要素およびソースをいつでも追加または廃棄できる。先行技術のデータクリーニングプロセスに反して、この発明の一実施例におけるようなデータクリーニングプロセスは、顧客などの異なるユーザが、部品購入の内部値および部品販売の外部値を有し得る、単価などの表面上同じデータ要素の異なるソースを見る必要があるかもしれないことを認識し得る。この例では、価格の両方の値が有効であり、どちらの値が使用されるかはアプリケーションに依存する。この発明の一実施例におけるようなデータクリーニングプロセスは、異なるソースからの選択されたデータ要素の複数の値を表示する能力を有し得る。ユーザは、ソースシステムにおける情報よりも正確であり得る情報で元の選択をオーバーライドし得る。各データ要素の１つの値のみが目に見える伝統的なデータベースとは異なって、この発明の一実施例におけるようなデータクリーニングプロセスは、以前の値に対するバージョニングおよび異なるソースシステムから利用可能な各データ要素のすべてのバージョンに対するトレーサビリティを提供し得る。

一実施例では、この発明は、データリポジトリエリアにおけるデータ要素に対してなされるすべての変更を取込みかつ識別する能力、およびその変更をユーザに戻すように再表示する能力を有するデータクリーニングプロセスを提供する。データ要素に対する変更についての情報は、その変更が画面の変更であるかまたは一括更新であるかにかかわらず、データを変更するユーザ、変更の日付、およびなぜ変更がなされたかを含むコメントを追
跡することによって取込まれ得る。これは、概して疑わしいデータのみにフラグを立てることができ、概して記録のシステムに対して変更がなされることを要求する先行技術のデータクリーニングプロセスと比較した利点である。多くの場合、記録のシステムは、データクリーナが更新権限を持たない顧客のデータベースまたは部門のデータベースである。その結果、ユーザが記録のシステムを更新せざるを得ない先行技術のデータクリーニングソリューションはしばしば実用的ではない。先行技術に反して、この発明の一実施例におけるようなデータクリーニングプロセスは、コンピュータモデルへの入力および出力の両方への日付の入ったバージョニング、時の経過に伴うデータに対する変更の追跡を提供する。既存のＥＴＬツールは、時の経過に伴うデータのバージョニングを支援しない。この発明の一実施例におけるようなデータクリーニングプロセスによって、結果ならびにその結果が依拠していたデータおよびデータソースの両方の監査可能性が可能になる。この発明の一実施例におけるようなデータクリーニングプロセスはさらに、ユーザが定義可能なビジネスルールに反するデータを選別することによってデータの完全性を保証する。さらに、この発明の一実施例におけるようなデータクリーニングプロセスによって、ユーザがたとえばソースシステムから部品番号に追加および削除することが可能になり、追加されたものに対するトレーサビリティを維持し、物理的にデータを削除するのではなくトレーサビリティのために削除されたデータにフラグを立てる。その結果、データは、削除されるときに電子的にタグを付けられるが、データリポジトリから物理的に除去されるわけではない。さらに、この発明の一実施例におけるようなデータクリーニングプロセスは、自動化された注を追加し、手製の注を考慮に入れ、これらは、各データ要素に添付されることができ、自動化された処理、フォーマット変換についての情報および他のデータ品質情報を提供し得る。これは、分析のためにデータを変換しなければならないとき、たとえばイギリスポンドからアメリカドルに通貨を正規化するときに、監査可能性を与える。

一実施例では、この発明は、たとえばサプライチェーンソフトウェアツールに関連して使用されることができ、かつ、このようなサプライチェーンソフトウェアツールの結果をアーカイブおよび共有することを可能にし得るデータクリーニングプロセスを提供する。現在存在しているデータリポジトリは、分析を行なうのに必要な現在の入力データを記憶する。この発明の一実施例におけるようなデータクリーニングプロセスは、分析が行なわれたときに使用されたデータおよびその分析の結果の両方をアーカイブすることを可能にする。これは、データのソースおよびそのデータに基づくモデル結果に対して完全な監査可能性を与える。これは、たとえば、費用のかかるメンテナンス予備品の購入の背景にある根拠に対する監査可能性が必要な政府のサプライチェーン契約および民間の契約にとって重要である。データおよび結果のアーカイブを支援する公知のサプライチェーンツールは存在しない。さらに、この発明の一実施例におけるようなデータクリーニングプロセスによって、警告を与えるデータ要素レベルに閾値およびトリガを確立でき、この警告は、たとえば資産管理者およびデータ所有者に、特定のデータ要素が疑わしく、検討されるべきであることを通知する。これらの閾値は、大量のデータが更新されているときには特に重要である。なぜなら、エラーについて各々のおよびすべてのデータ要素をスキャンすることは物理的に不可能である可能性があり、エラーが発生しやすい可能性があるためである。さらに、この発明の一実施例におけるようなデータクリーニングプロセスは、手動の検討のために極めて重要な欠落したデータにフラグを立てる間に、欠落したデータを埋めるためにデフォルトを与える。これによって、全アイテムについての任意のデータ要素が欠落しているかまたは無効である場合に全アイテムを削除する伝統的なソリューションと比較して、すべての部分を分析の中に含める可能性がより高くなる。この発明の一実施例におけるようなデータクリーニングプロセスは、デフォルトが使用されたすべてのデータ要素に対するトレーサビリティを提供する。

ここで図１を参照して、データクリーニングのハイレベルアーキテクチャ１０がこの発明の一実施例に従って示される。データクリーニングのハイレベルアーキテクチャ１０は
、既存のインターフェイス１１に組込まれるデータクリーニングシステム２０を含み得る。データクリーニングシステム２０は、ＥＴＬ（抽出、変換およびロード）ツール２１と、データフォーマッティングユーティリティ２２と、データクリーニングユーティリティ２３と、正規化データクリーニングリポジトリ２４と、ソース優先順位付けユーティリティ２６と、データ要素およびソースのマスタテーブル３０（図２にも図示）と、相互参照ユーティリティ２７と、レポート２８と、データクリーニングユーザインターフェイス２９とを含み得る。既存のインターフェイス１１は、企業、顧客および供給者データ１２と、ＥＴＬツール１３と、データウェアハウス１４と、外部のデータソース１５と、サプライチェーン在庫表最適化システム１６１、統合情報システム１６２、在庫表管理システム１６３、契約および価格付けシステム１６４、エンジニアリングシステム１６５、およびシミュレーションシステム１６６などのデータシステムならびにソフトウェアツール１６とを含み得る。企業、顧客および供給者データ１２は、ＥＴＬツール１３を使用してデータウェアハウス１４にロードされ得る。

ＥＴＬツール２１は、データウェアハウス１４からまたは外部のデータソース１５からデータを抽出でき、抽出されたデータをデータクリーニングのために共通のフォーマットに変換でき、変換されたデータをデータクリーニングシステム２０にロードできる。この動作はまた、カスタムデータベースクエリーを使用して行なわれてもよい。データウェアハウス１４および外部のデータソース１５は、ソースデータのためのソースシステムまたはソースであり得る。データフォーマッティングユーティリティ２２は、データ検証の一部として固有のデータ識別子を共通のフォーマットに調整するために使用され得る。

データフォーマッティングユーティリティ２２は、ダッシュまたは空白スペースを含むなどの固有のデータ識別子のわずかな変化によって、ダッシュまたは空白スペースがあるべきではないときに識別子が異なるアイテムとして解釈される可能性があるというデータエントリの問題を説明し得る。

データクリーニングユーティリティ２３は、データ検証の一部として、データウェアハウス１４および外部のデータソース１５などのソースシステムからのデータをクリーニングするために使用され得る。データクリーニングユーティリティ２３は、各ソースシステム（データウェアハウス１４または外部のデータソース１５）からデータクリーニングフォーマットにロードされたデータの有効性を保証するために使用され得る。

正規化データクリーニングリポジトリ２４は、フォーマットされ、かつ、クレンジングされたデータを異なるソースシステムから受信し得る。正規化データクリーニングリポジトリ２４は、データウェアハウス１４および外部のデータソース１５などの異なるソースシステムからのクレンジングされたデータをマスタデータテーブルにロードし得る。

ソース優先順位付けユーティリティ２６は、データウェアハウス１４および外部のデータソース１５などのデータソースの優先順位を選択するために使用され得る。データウェアハウス１４および外部のデータソース１５などのソースシステムは典型的には、異なる組織によってロードおよび維持されることができ、表面上同じデータ要素３２であるもののために記憶されている異なる値に繋がる。これは、複数の部門を有する大きな組織内で、ならびに顧客、供給者および政府組織にわたって共通である。

データ要素およびソースのマスタテーブル３０（図２にも図示）は、複数のソースからのクレンジングされたデータと優先順位が付けられたデータとを組合せるクリーンなデータベースとして作成され得る。データ要素およびソースのマスタテーブル３０は、各データ要素３２の最良値を含むアイテムデータの単一のソースであり得る。

相互参照ユーティリティ２７は、固有のデータ識別子３１間の相互参照を作成および維持するために使用され得る。異なるデータソースは、セクション参照、（ＮＡＴＯ（North Atlantic Treaty Organization）（北大西洋条約機構）ストック番号または米国ストック番号のいずれかと定義される）ＮＳＮ（NATO stock number or national stock number）、または部品番号および製造者のコードなどの異なる固有のデータ識別子３１を使用し得る。多くの場合、固有のデータ識別子３１は、特定のデータソース内で相互参照されることになる。これによって、クリーンなデータベースがデータウェアハウス１４または外部のデータソース１５などの複数のソースから作成されるときに相互参照を展開することが可能になり得る。アイテムごとに固有の参照番号を作成することがさらに可能であり得る。１つのスキームについての固有のデータ識別子３１が別のスキームについての複数の固有のデータ識別子３１にマッピングするとき、およびその逆のときに、相互参照において一対多、多対一または多対多の関係が生じる可能性がある。その結果、データ要素およびソースの、優先順位が付けられたデータクリーニングマスタテーブル３０はしばしば、重複した固有のデータ識別子３１を含み得る。相互参照ユーティリティ２７は、不要な重複物を削除するためおよび相互参照における矛盾を補正するためにユーティリティを提供し得る。さらに、データクリーニングシステム２０からデータを送られるデータシステム１６が真に固有のデータ識別子番号を受信できるように固有の参照番号を作成し得る。これによって、データシステム１６および接続されたアプリケーションは、相互参照が完璧であることを要求することなく実行可能であり得る。たとえば、４つのタイヤおよび予備タイヤを有する自動車についてのいくつかの適用例は、固有のアイテム識別子を複数回使用できるようにし得る。たとえば、特定のモデルのタイヤが好ましい供給者および最も最近に見積られた価格のみをリストにすることを要求する購入システムについての他の適用例は、一度だけ生じるように固有のアイテム識別子を要求し得る。この問題を解決するために、刻み目が付けられた（indentured）マスタデータアイテムリストを作成および維持し得る。必要なときに、マスタデータアイテムリストによって、固有のアイテム識別子を複数回使用できる。一例は軍用機の部品のリストである。たとえば、ヘリコプターは６つの回転翼の羽根を含んでいてもよく、前方パイロンアセンブリの一部として３つの羽根を含み、機尾パイロンアセンブリの一部として３つの羽根を含んでいてもよい。購入システム１６１は、回転翼の羽根についての年間の購入を知る必要があるだけでよいのに対して、在庫表最適化システム１６３は羽根当たりの要求される需要およびアセンブリに応じた羽根の数量を知りたいと思うかもしれない。１組のユーティリティによって、マスタデータアイテムリストにおける重複したデータをデータ要素およびソースのマスタテーブル３０（図２に図示）における固有のアイテムデータとマージすることが可能であり得る。需要レートなどのデータ要素３２について適切な比率を計算に入れることができる。このデータは次いで、適切なソフトウェアツール、たとえばサプライチェーンソフトウェア１６１で使用するために供給され得る。

ＥＴＬツール２１またはカスタムデータベースクエリーは、データ要素およびソースのマスタテーブル３０からの矛盾がなく、正規化され、かつ、クレンジングされたデータを、サプライチェーンソフトウェア１６１、統合情報システム１６２、在庫表管理システム１６３、契約および価格付け１６４、エンジニアリング１６５、およびシミュレーション１６６などのデータシステムならびにソフトウェアツール１６に必要なフォーマットにロードするために使用され得る。

また、標準化されたデータクリーニングおよび管理レポート２８を作成し得る。多くの場合、１つのシステムにおける管理レポートは、別のシステムにおける管理レポートと類似しているか、または全く同じでさえある。データクリーニングシステム２０は、要素およびソースのマスタテーブル３０に対して最も一般的なレポートのうちいくつかを提供し得る。たとえば、要素およびソースのマスタテーブル３０（図２に図示）における固有のアイテム識別子３１の番号を記録し得るラインカウントレポートを作成し得る。ラインカ
ウントは、異なるデータ要素３２に対して相互作表され得る。たとえば、在庫表管理システム１６３が消耗部品の総数および修理可能な部品の総数を知りたい場合、この情報はラインカウントレポートから引出され得る。さらに、標準化された高ドライバレポート４０（図３に図示）を作成し得る。標準化された高ドライバレポート４０は、検討のためにデータを優先順位付けすることを可能にし得る。優先順位付けによって、一貫性および精度についてデータを検討するときに異常をすばやく突き止めることが可能になり得る。

データクリーニングユーザインターフェイス２９は、閉じループデータクリーニングを可能にし得る。データクリーニングは、ほとんどの場合、在庫表管理１６３などの実行システム（データシステムおよびソフトウェアツール１６）のユーザによって「第一線」で行なわれる。これらのユーザは、新しい見積もりを求める間、またはたとえば顧客、供給者または修理店と協力しながらデータに補正を加える間、頻繁にデータを更新する。ユーザは、データウェアハウス１４または外部のデータソース１５などのソースシステムを更新することなくデータクリーニングシステム２０を更新する方法を持たなければならない。これは、データウェアハウス１４または外部のデータソース１５などのソースシステムがしばしば別の組織またはさらには別の顧客もしくは供給者の管理下にあるために必要であり得る。その結果、ソースシステム（１４および／または１５）を更新することは実用的でない可能性があり、または実現可能でない可能性さえある。データクリーニングユーザインターフェイス２９によって、データクリーニングシステム２０によって提供されるクレンジングされたデータに基づいて決定を行なうデータシステムおよびソフトウェアツール１６のユーザは、データクリーニングシステム２０を更新することが可能であり得る。これによって、すべてのデータシステムおよびソフトウェアツール１６、たとえばサプライチェーンソフトウェア１６１は、クレンジングされたデータへの更新に基づいて一貫性を維持できる。手動の更新は、日付および時刻を刻印することができ、更新を行なうユーザに対するトレーサビリティを含むことができ、ユーザにとって重要であると考えられる情報を取込むために共通のフィールドを含み得る。データクリーニングユーザインターフェイス２９はウェブで可能となり得る。ソース優先順位付けユーティリティ２６によって、データクリーニングシステム２０からの情報に頼るデータシステムおよびソフトウェアツール１６は、特定の要件に基づいて、このユーザ（または、サプライチェーンソフトウェア１６１などの特定のソフトウェアツールのユーザ）からの更新を選択できる場合もあれば、選択できない場合もある。手動の更新は、データウェアハウス１４または外部のデータソース１５などのソースシステムへのその後の更新中に時の経過に伴って持続する可能性がある。ソースデータが同じままであれば、データクリーニング値を使用し得る。ソースデータが（ユーザ指定の許容帯域内で）データクリーニング値と同じ値に変化する場合、ソースデータを選択でき、ソースシステムが更新されたときにデータクリーニング値にフラグを立て得る。ソースデータが変化するが、ユーザ指定の許容帯域外である場合には、手動の検討のためにデータ要素３２にフラグを立て得る。

データクリーニングシステム２０は、コンピュータシステム（図示せず）に統合可能である。コンピュータシステムは、上述のＥＴＬ（抽出、変換およびロード）ツール２１、データフォーマッティングユーティリティ２２、データクリーニングユーティリティ２３、正規化データクリーニングリポジトリ２４、ソース優先順位付けユーティリティ２６、データ要素およびソースのマスタテーブル３０（図２にも図示）、および相互参照ユーティリティ２７などのユーティリティを実行するために使用され得る。データクリーニングシステム２０を使用するデータクリーニングは、マイクロソフトのエクセル（登録商標）ファイルなどの直接的なスプレッドシートファイル、またはマイクロソフトのアクセス（ACCESS）（登録商標）もしくはFoxProテーブルなどのデータベーステーブルを使用して、またはデータクリーニングユーザインターフェイス２９を介して、なされ得る。

ここで図２を参照して、データ要素およびソースのマスタテーブル３０のデータクリー
ニングテーブルのレイアウトがこの発明の一実施例に従って示される。データ要素およびソースのマスタテーブル３０は、フィールド番号を含む列３５と、フィールド名を含む列３６と、エントリタイプを含む列３７と、エントリ幅を含む列３８と、説明を含む列３９とを含み得る。テーブルの第１の行は、１つ以上の索引付けスキームからの固有のデータ識別子３１を含み得る。図２に示すように、与えられる例では、部品は、たとえ固有の参照が１つだけ必要であるとしても、（ａ）ＤＭＣ（domestic management code）（国内管理コード）およびＩＩＮ（item identification number）（アイテム識別番号）、（ｂ）ＮＳＣ（NATO (or national) supply classification code）（ＮＡＴＯ（もしくは米国）サプライ分類コード）と、ＮＣＢ（national codification bureau）（米国コード化局用コード）と、ＩＩＮ（アイテム識別番号）とからなるＮＳＮ（ＮＡＴＯストック番号もしくは米国ストック番号）、または（ｃ）Part no.（part number）（部品番号）およびＣＡＧＥ（commercial and government entity code）（民間および政府のエンティティコード）によって固有に識別されることができる。固有のデータ識別子３１に続いて、データ要素３２をリストにすることができ、予備品プログラム１１０（図７に図示）などのプログラム名３３が続く。データ要素およびソースのマスタテーブル３０にさらにリストにされるのは、データ要素３２の値３２１、（図１に示すデータウェアハウス１４または外部のデータソース１５などの）データ要素３２のソース３２２、更新情報３４、およびデータ要素３２に添付されることができかつデータ処理中に使用され得るフラグ３２３であり得る。データ要素およびソースのマスタテーブル３０の最後の行はテキストコメント３４１を含み得る。データ要素およびソースのマスタテーブル３０によって、コードを修正することなくデータ要素およびソースを変更することが可能になり得る。データリポジトリのように、参照の整合性が慎重に実施されることはない。

ここで図３を参照して、高ドライバレポート４０の高ドライバ分析マトリックスがこの発明の一実施例に従って示される。高ドライバレポート４０は、図１に示すようにデータクリーニングシステム２０によって作成されたレポート２８のうちの１つであり得る。高ドライバレポート４０は、検討のためにアイテムを優先順位付けするために使用され得る。これによって、最も目立つエラーをすみやかに識別することが可能になり得て、しばしば制限される、利用可能な検討時間を最大にする。高ドライバは、図３に示す年間使用量、年間消費量、重み付けされた修理ターンアラウンド時間、調達リードタイム、スクラップ発生／不良品の設定率、価格、および予備品不足のコストなどのキーとなるデータドライバに従ってデータ要素３２をソートし得る。

ここで図４を参照して、データクリーニングプロセス５０がこの発明の一実施例に従って示される。データクリーニングプロセス５０は、第１のステップ５１において、データクリーニングのために、データウェアハウス１４などの企業、顧客および供給者ソースシステムからのデータまたは外部のデータソース１５（図１に図示）からのデータを共通のフォーマットにロードすることを含み得る。ステップ５１を実行するために、商業的に利用可能なＥＴＬツール２１またはカスタムデータベースクエリーのいずれが使用されてもよい。

ステップ５２において、データクリーニングシステム２０のデータフォーマッティングユーティリティ２２（図１に図示）は、データ検証プロセスの一部として固有のデータ識別子３１を共通のフォーマットに調整するために使用され得る。ステップ５２は、先頭の空白を削除し、必要に応じて数字フィールドから文字フィールドへ固有のデータ識別子３１（図２に図示）を変換し、データが数字としてロードされた場合には取除かれた先頭の０を入れ替えることを含み得る。ステップ５２は、検討のために、無効で、認識されず、かつ、欠落したアイテム識別子にフラグを立てることをさらに含み得る。ステップ５２は、データを共通のフォーマットに正規化することをさらに含み得る。たとえば、外貨をアメリカドルに換算すること、取得原価データを当年度の価格に上昇させること、またはパ
ッケージ数量当たりの需要を一つの単位当たりの需要に換算することである。

ステップ５３において、（図１に示される）データクリーニングシステム２０のデータクリーニングユーティリティ２３を用いて、データ検証プロセスの一環としてデータウェアハウス１４または外部のデータソース１５などのソースシステムからロードされたデータをクリーニングし得る。ステップ５３は、重複するエントリを検討するステップと、異なるレポートを検討するステップと、ソースシステムからロードされたデータ間の違いを検討して、データの変化を検証し、データ変換およびロードエラーを検出するステップと、クレンジングされたデータを用いるソフトウェアの入力および出力（ソースデータおよび結果）の違いを検討して、入力データの変化によってもたらされる結果における変動を識別および理解するステップとを含む。ステップ５３の間、重複したエントリにフラグが立てられ、データ要素についての矛盾する値がデータ要素３２（図２）によって検討され、ソースデータをオーバーライドする手動の補正または更新が可能になり得る。ステップ５３においては、固有のデータ識別子によって２つのデータテーブル間の違いを強調する自動化されたリポートが作成され得る。また、ステップ５３において、特定のデータ要素３２によってこれらのリポートに優先順位が付けられて、最大の財務的影響を与える高ドライバに対してデータ検討の焦点を合わせ得る。

ステップ５４において、検証されクレンジングされたデータが正規化データクリーニングリポジトリ２４（図１）に付加され得る。当該データは、正規化データクリーニングリポジトリ２４（図１）のマスタテーブルにロードされ得る。当該データは、各データ要素３２（図２）および各ソースシステム、たとえば、データウェアハウス１４または外部のデータソース１５（図１）のためにロードされ得る。同じデータが同じソースシステムから予めロードされている場合、データがロードされる可能性はない。結果として、変更だけがロードされる。ロードされたデータの日付がソースデータに追加されることにより、最新データの識別が可能になり得る。データがロードされた状態でエラーが存在した場合、特定のデータソースのためにすべてのデータをパージし、それをリロードするためのオプションが存在し得る。パージすべきデータは最初に検証のために表示されてもよい。ユーザは、データクリーニングシステム２０（図１）の完全性を確実にするためにデータを削除できるようアドミニストレータとして許可され得る。データクリーニングシステム２０（図１に図示）は、データウェアハウス１４または外部のデータソース１５などの各ソースシステムからのすべてのバージョンのデータに対するトレーサビリティを与え得る。これにより、前のデータの値に対する監査証跡が与えられ、さらに、履歴上の時点でデータをプルすることが可能となり得る（バージョニング）。

ステップ５５において、データソースの優先順位が選択され得る。ステップ５５は、固有のデータ要素３２（図２）の番号を決定するステップと、各データ要素３２のために（図１のデータウェアハウス１４または外部のデータソース１５などの）ソースシステムの番号を決定するステップとを含み得る。個々のデータ要素は、アプリケーションに応じて変わる可能性があり、時間が経つにつれてデータの使用が進行すると変わる可能性がある。データソースはアプリケーションに応じて変わる可能性があり、時間が経つにつれてデータの使用およびその品質の理解が変化すると変わる可能性がある。データクリーニングシステム２０（図１）は、ソフトウェアソースコードに変更を加える必要なしに、データ要素３２（図２）の追加および削除に適合し得る。ステップ５５は、データに予め優先順位が付けられていた場合、ユーザが、特定のデータプルのためにデータソースの優先順位を更新することを可能にし得る。そうでない場合、ステップ５５は、図１に示されるデータウェアハウス１４または外部のデータソース１５などの各データソースの優先順位をユーザが特定することを可能にし得る。第１の優先順位のソースからのデータが利用可能であれば、これが用いられる。そうでない場合、第２の優先順位のソースからのデータが選択されることとなる。ステップ５５はさらに、ユーザが、データを選択する（たとえば、
ソースＡ、ＢおよびＣから最高値を選択する）ために条件文を特定することを可能にし、データが（図１のデータウェアハウス１４または外部のデータソース１５などの）いかなるソースシステムからも利用可能でない場合、用いるべきデフォルトをユーザが選択することを可能にするステップを含み得る。特定のデータソースは、そのソースからのデータが考慮される必要がなければ選択されなくてもよいかもしれない。ステップ５５はさらに、過去のある時点で用いられたデータ選択スキームがたとえば監査の目的で選択され得るように、以前の優先順位付けの履歴記録を維持するステップを含み得る。

ステップ５６において、（図１のデータウェアハウス１４または外部のデータソース１５などの）複数のソースからのクリーンなデータベースが（図２に示される）データ要素およびソースのマスタテーブル３０の形で作成され得る。データ要素およびソースのマスタテーブル３０は、各データ要素３２の最良値を含むアイテムデータの単一のソースであり得る。ステップ５６は、各データ要素のソースに対するトレーサビリティを維持し、ソースが固有のデータ識別子３１によって変わり得ることを認識し、データをさらに理解させるために各データ要素に添付され得る注を維持するステップを含み得る。第１の優先順位のソースからのデータが利用可能であれば、これが利用されてもよい。そうでない場合、次に優先順位の高いソースからの有効なデータが選択され得る。各々の固有のデータ識別子３１のために選択される（図１のデータウェアハウス１４または外部のデータソース１５などの）データソースのログを維持するステップがステップ５６に含まれてもよい。データ要素３２のために有効なデータが存在しない場合、ユーザ指定のデフォルトが選択されるかもしれない。次いで、デフォルトが適用されたことについて、データ記録に注釈が付けられてもよい。ステップ５６においても、異なるアプリケーション、たとえば、サプライチェーン在庫表最適化システム１６１、在庫表管理システム１６３、財務および見積りシステム１６４、統合情報システム１６２、シミュレーションシステム１６６またはエンジニアリングシステム１６５（図１に図示）などは、異なる優先順位のシーケンスでデータ要素３２（図２）を選択することができるだろう。各データ要素３２は、たとえば、図２に図示のとおり、最良値３２１、最良データのソース３２２およびコメント３４１などの各々の固有のデータ識別子３１についての３つの情報を含み得る。

ステップ５７において、固有のデータ識別子３１間で相互参照が作成され得る。ステップ５７は、固有のデータ識別子に基づいて、相互参照されたデータに優先順位を付けるステップを含み得る。たとえば、固有にアイテムを記述するための最良値としてスキームがセクション参照を識別し得るが、この後、ＮＳＮ（ＮＡＴＯストック番号または米国ストック番号）が続き、次に、部品番号および製造者コードが続き得る。

ステップ５８において、固有のデータ識別子３１間の相互参照がユーティリティによって維持され得る。ステップ５８は、（図１のデータウェアハウス１４または外部のデータソース１５などの）複数のソースからデータベース（図２０のデータ要素およびソースのマスタテーブル３０）を作成する際に生じた不一致を検討し、各々の識別スキームのために主要な固有のデータ識別子を識別するステップを含み得る。部品についての最新の設計構成を検討するステップについては、たとえば、旧式の部品構成についての部品番号が最新の設計構成または販売されている最新の構成に変換され得るが、ステップ５８の一部であり得る。さらに、データリポジトリにおけるデータに基づいた相互参照のためにすべてのオプションを識別するためのユーティリティが提供されてもよく、たとえば、部品番号および製造者コードが複数のＮＳＮにマッピングしてもよく、ＮＳＮが、当該ＮＳＮの規格を満たす部品を供給する別の製造業者の番号付けスキームに基づいて多くの異なる部品番号にマッピングしてもよい。ステップ５８はさらに、固有のデータ識別子の変化に伴ってインデックステーブルを維持するステップと、部品番号および製造者コードが変更された部品番号および製造者コードと取替えられるとインデックステーブルを維持するステップと、部品番号が無効な供給者に誤って相互参照されないことを確実にするために重複し
た部品番号と製造者コードとの組合せを検討するステップと、有効な固有のデータ識別子３１のリストであり得るマスタデータアイテムリストを維持するステップとを含み得る。マスタデータアイテムリストに含まれないアイテムには、疑わしいものとして検討するためにフラグが立てられてもよい。

ステップ５９において、各データ要素３２（図２）についての固有の参照番号が作成されて、データクリーニングシステム２０（図１）からデータが供給され得るデータシステムおよびソフトウェアツール１６（図１）が、真に固有のアイテム識別番号を受信することを可能にし得る。ステップ５９はさらに、不要な重複物を削除するようユーティリティを提供し、相互参照における矛盾を補正するようユーティリティを提供するステップを含み得る。ステップ５９において、データシステムおよびソフトウェアツール１６（図１）などのアプリケーションは、相互参照を完璧にしなくても実行可能にされ得る。

ステップ６１において、固有のアイテム識別番号を含み得る刻み目が付けられたマスタデータアイテムリストが維持され得る。所望される場合、マスタデータアイテムリストは、固有のアイテム識別番号の複数回の使用を可能にし得る。ステップ６１は、マスタデータアイテムリストにおける重複したアイテムデータをデータ要素およびソースのマスタテーブル３０（図２）における固有のアイテムデータとマージするステップを含み得る。

ステップ６２において、矛盾がなく、正規化され、かつ、クレンジングされたデータが、データ要素およびソースのマスタテーブル３０（図２）から、これらのデータを使用し得るデータシステムおよびソフトウェアツール１６（図１）によって必要とされるフォーマットにロードされ得る。市販のＥＴＬツール２１（図１）またはカスタムデータベースクエリを用いてステップ６２を実行し得る。結果として、一貫した単位に正規化された、一貫した同じソースからのクレンジングされたデータが、図１に示されるデータシステムおよびソフトウェアツール１６などの複数の意思決定システムにとって利用可能となり得る。すべての意思決定システムが、図１に示されるデータクリーニングシステム２０によって与えられる同じ入力データから開始するので、結果が一貫したものになり得、サプライチェーン在庫表最適化システム１６１、在庫表管理システム１６３、財務および見積りシステム１６４、統合情報システム１６２、シミュレーションシステム１６６またはエンジニアリングシステム１６５（図１に図示）などのシステム間で有効な比較がなされ得る。たとえば個々の部品番号に関して決定を下すことを可能にし得る戦術意思決定ツールは、より長距離または広域のプラニングシステムツールとして作動し得る戦略意思決定ツールと同じデータにアクセスし得る。

ステップ６３において、ラインカウントレポートおよび高ドライバレポート４０（図３）などの標準化データクリーニングおよび管理レポートが作成され得る。ラインカウントレポートは、データ要素およびソースのマスタテーブル３０（図２）における番号または固有のアイテム識別子３１を記録することによって作成され得、異なるデータ要素３２に対して相互作表され得る。図３に示される高ドライバレポート４０などの高ドライバレポートは、検討のためにアイテムに優先順位を付け、最も明らかなエラーの速やかな識別を可能にし得る。

ステップ６４において、データクリーニングシステム２０（図１）は、データウェアハウス１４および外部のデータソース１５（図１）などのソースシステムを更新することなくユーザによって更新され得る。ステップ６４は閉ループデータクリーニングを可能にし得る。

図５を参照すると、サプライチェーン７０におけるデータクリーニングアプリケーションが、この発明の別の実施例に従って示される。サプライチェーン７０におけるデータク
リーニングアプリケーションは、データクリーニングシステム２０（図１に図示）およびデータクリーニングプロセス５０（図４に図示）のアプリケーションについての一例であり得る。サプライチェーン７０は、埋込まれた（図１に示される）データクリーニングシステム２０、（図１に示される）データクリーニングユーザインターフェイス２９、統計的需要予測ユーティリティ７２、戦略的在庫表最適化ツール７３、シミュレーションツール７４、戦術分析ユーティリティ７５、ウェブポータル７６、在庫表管理システム７７、統制化されたプロセス７８および分散ネットワーク最適化ツール７９を有する統合情報システム７１を含み得る。統合情報システム７１は、（図１に示される）データクリーニングユーザインターフェイス２９、統計的需要予測ユーティリティ７２、戦略的在庫表最適化ツール７３、シミュレーションツール７４、戦術分析ユーティリティ７５、ウェブポータル７６および在庫表管理システム７７との間でデータをやり取りし得る。統合情報システム７１内に埋込まれた（図１に示される）データクリーニングシステム２０によって、有効なデータクリーニングが提供され得る。（図４に示される）データクリーニングプロセス５０は、正規化されてクレンジングされたデータの一貫したソースを介して、決定支援（７８，７２）、最適化（７３，７９）、シミュレーション（７４）、報告（７５，７６）および在庫表管理ツール（７７）をリンクすることによってサプライチェーン７０を同期し得る。

ここで図６を参照すると、サプライチェーン７０のためのデータクリーニングプロセス８０がこの発明の一実施例に従って示される。サプライチェーン７０のためのデータクリーニングプロセス８０は、ステップ８１において（図１のデータウェアハウス１４または外部のデータソース１５などの）ソースシステムからのデータの抽出を開始するステップと、ステップ８２において、ＥＴＬツール２１（図１）を用いてデータ変換を実行するステップとを含み得る。データ要素およびソースのマスタテーブル３０（図２）にデータをロードするステップがステップ８３において追従し得る。ステップ８４は、ソース優先順位付けユーティリティ２６（図１）を用いてソースデータの優先度を選択するステップを含み得る。高ドライバおよびエラーレポートを検討するステップと、ロジスティックスデータをかき集めるステップとがステップ８５において実行され得る。ステップ８６は、予備品分析最適化計算のためのデータを承認するステップを含み得、次に、ステップ８７において、戦略的モデルを用いることによってストックレベルおよび発注点の在庫表最適化を開始するステップが続き得る。レポート２８（図１）およびウェブのビューでの予備品分析がステップ８８において検討され、在庫表最適化がステップ８９において承認され得る。ステップ９１は、ストックレベルおよび発注点の推奨、戦略的モデル入力、ソース、および、サプライチェーンソフトウェア１６１（図１）の一部であり得る戦略的モデル７３（図５）からのコメントをデータリポジトリ２４（図１）にエクスポートし、顧客監査証跡のための支援データを維持するためにすべての入力および出力をアーカイブするステップを含み得る。ウェアハウス、供給者などによる部品、供給者、ストックレベル、発注点などのレポート２８（図１）を作成するステップはステップ９２において実行され得る。ステップ９３において、在庫表の不足をカバーするための所望される予備品が購入され得、ステップ９４において、ストックレベルおよび発注点の推奨が、在庫表管理システム１６３（図１）にエクスポートされ得る。最後のステップ９５において、日常的な資産管理のために保持テーブルに見出されるレコードについて、在庫表管理システム１６３（図１）に対する更新が開始され得る。

図７を参照すると、予備品モデリングプロセス１１０がこの発明の別の実施例に従って示される。予備品モデリングプロセス１１０は、データクリーニングプロセス５０（図４）の実現例であり得る。在庫表管理システム１６３（図１）の一部であり得る予備品モデリングプロセス１１０は、ステップ１１１において機器モデルおよびシナリオを識別するステップと、ステップ１１２において目標を決定するステップと、ステップ１１３において取引調査機会を決定するステップとを含み得る。ステップ１１４は、ロジスティックス
データを収集するステップを含み得、この後、ステップ１１５においてデータクリーニングプロセス５０（図４）が実行され得る。ストックレベルの戦略的在庫表最適化がステップ１１６においてエクスポートされ、リスクを減らすためのシミュレーション１６６（図１）がステップ１１７において実行され、ステップ１１８において内部の検討が実行され得る。ステップ１１９は、顧客の検討を実行するステップを含み得、この後、ステップ１２０において、モデルが繰返されるべきかどうかが決定され得る。モデルの繰返しが所望される場合、ステップ１２０はステップ１１４に戻るステップを含み得る。モデルの繰返しが必要でない場合、ステップ１２１において、提案レポートを作成するステップが実行され、この後、ステップ１２２において、提案を送出し、提案を獲得し、健全なプログラムを実行するステップが続き得る。予備品モデリングプロセス１１０では、ステップ１１５におけるデータクリーニングプロセス５０（図４）によって与えられる矛盾がなく、正規化され、かつ、クレンジングされたデータのために、確実かつ実施可能な結果が提供され得る。

上述のことがこの発明の具体的な実施例に関連しており、添付の特許請求の範囲に記載されるとおりこの発明の精神および範囲から逸脱することなく変更がなされ得ることが当然理解されるはずである。

この発明の一実施例に従うデータクリーニングのハイレベルアーキテクチャのフローチャートである。この発明の一実施例に従うデータクリーニングテーブルのレイアウトである。この発明の一実施例に従う高ドライバ分析マトリックスである。この発明の一実施例に従うデータクリーニングプロセスのフローチャートである。この発明の別の実施例に従うサプライチェーンにおけるデータクリーニングアプリケーションのブロック図である。この発明の一実施例に従うサプライチェーンのためのデータクリーニングプロセスのフローチャートである。この発明の一実施例に従うサプライチェーンのためのデータクリーニングプロセスのフローチャートである。この発明の別の実施例に従う予備品モデリングプロセスのフローチャートである。

Claims

データクリーニングプロセスであって、
データフォーマッティングユーティリティおよびデータクリーニングユーティリティを用いて、少なくとも２つのソースシステムからロードされたデータを検証するステップと、
前記検証されたデータを正規化データクリーニングリポジトリに付加するステップと、
前記ソースシステムの優先順位を選択するステップと、
前記少なくとも２つのソースシステムからの各データ要素のための固有のデータ識別子を含むクリーンなデータベースを作成するステップと、
前記固有のデータ識別子間の相互参照を作成および維持するステップと、
前記クリーンなデータベースからの矛盾がなく、正規化され、かつ、クレンジングされたデータを、前記データを用いるデータシステムおよびソフトウェアツールが必要とするフォーマットにロードするステップと、
前記矛盾がなく、正規化され、かつ、クレンジングされたデータを用いて標準化データクリーニングおよび管理レポートを作成するステップと、
前記ソースシステムを更新することなく、ユーザによって前記矛盾がなく、正規化され、かつ、クレンジングされたデータを更新するステップとを含む、データクリーニングプロセス。
抽出、変換およびロードツールを用いたデータクリーニングのために前記少なくとも２つのソースシステムからのデータを共通のフォーマットにロードするステップと、
前記データ要素の各々の最良値を含むアイテムデータの単一のソースとしてデータ要素およびソースのマスタテーブルを作成するステップと、
前記データ要素の各々に注を添付して、前記データ要素をさらに理解させ、前記データ要素およびソースのマスタテーブルにおける注を維持するステップと、
前記データ要素の各々の前記ソースシステムに対するトレーサビリティを維持するステップと、
前記データ要素の各々についての固有の参照番号を作成して、前記データシステムおよびソフトウェアツールが固有のアイテム識別番号を受信することを可能にするステップと、
前記固有のアイテム識別番号を含む刻み目が付けられたマスタデータアイテムリストを維持するステップとをさらに含む、請求項１に記載のデータクリーニングプロセス。
前記データ検証ステップはさらに、
少なくとも２つのソースシステムからロードされた前記データを共通のフォーマットに正規化するステップと、
固有のデータ識別子を共通のフォーマットに調整するステップと、
検討のために、無効で、認識されず、かつ、欠落したアイテム識別子にフラグを立てるステップと、
少なくとも２つのソースシステムからロードされた前記データをクリーニングするステップとを含む、請求項１に記載のデータクリーニングプロセス。
前記ソースシステムの各々からのすべてのバージョンのデータに対するトレーサビリティを提供するステップと、
履歴上の時点でプルすべきデータの以前の値に対する監査証跡を提供するステップとをさらに含む、請求項１に記載のデータクリーニングプロセス。
固有のデータ要素の番号を決定するステップと、
前記固有のデータ要素の各々についての前記ソースシステムの番号を決定するステップ
と、
ユーザ指定の優先順位に従って前記固有のデータ要素の各々についての前記ソースシステムを選択するステップと、
ユーザによる特定のデータプルのために前記優先順位を更新するステップと、
すべての優先順位付けの履歴記録を維持するステップとをさらに含む、請求項１に記載のデータクリーニングプロセス。
ラインカウントレポートを作成するステップと、
前記データ要素およびソースのマスタテーブルにおける前記固有のアイテム識別子の番号を記録するステップと、
異なるデータ要素に対して前記固有のアイテム識別子を相互作表するステップとをさらに含む、請求項１に記載のデータクリーニングプロセス。
高ドライバレポートを作成するステップと、
検討のためにアイテムに優先順位を付けるステップと、
明らかなエラーを速やかに識別するステップとをさらに含む、請求項１に記載のデータクリーニングプロセス。
前記ユーザが前記データ要素およびソースのマスタテーブルを更新することを可能にするデータクリーニングユーザインターフェイスを提供することにより、閉ループデータクリーニングを可能にするステップをさらに含む、請求項１に記載のデータクリーニングプロセス。
サプライチェーンのためのデータクリーニングプロセスであって、
複数のソースシステムからのデータをデータ要素およびソースのマスタテーブルにロードするステップと、
前記ソースシステムの優先度を選択するステップと、
高ドライバおよびエラーレポートに基づいて前記データ要素およびソースのマスタテーブルに含まれるロジスティックスデータをクリーニングするステップと、
前記データ要素およびソースのマスタテーブルの矛盾がなく、正規化され、かつ、クレンジングされたデータを承認し、前記クレンジングされたデータを、前記データを用いるデータシステムおよびソフトウェアツールに供給するステップと、
前記クレンジングされたデータを用いて、戦略的在庫表最適化モデルを用いるストックレベルおよび発注点の在庫表最適化を開始するステップと、
ストックレベルおよび発注点の推奨を含む予備品分析を提供するステップと、
顧客監査証跡のための支援データをアーカイブするステップと、
レポートを作成するステップと、
前記レポートに従って不足をカバーするために予備品を購入するステップとを含む、サプライチェーンのためのデータクリーニングプロセス。
前記ソースシステムから前記データを抽出するステップと、
データクリーニングのために前記データを共通のフォーマットに変換するステップと、
前記高ドライバおよびエラーレポートを検討するステップとをさらに含む、請求項９に記載のサプライチェーンのためのデータクリーニングプロセス。
前記戦略的在庫表最適化モデルのために前記データ要素およびソースのマスタテーブルからデータを抽出および変換するステップと、
前記予備品分析のために前記データを前記戦略的在庫表最適化モデルから前記レポートにエクスポートするステップとをさらに含む、請求項９に記載のサプライチェーンのためのデータクリーニングプロセス。
在庫表最適化を承認するステップと、
レポートおよびウェブのビューを用いて前記予備品分析を検討するステップと、
前記ストックレベルおよび発注点の推奨、戦略的モデル入力、ソースシステム情報ならびにコメントを前記戦略的在庫表最適化モデルからデータリポジトリにエクスポートするステップとをさらに含む、請求項９に記載のサプライチェーンのためのデータクリーニングプロセス。
前記ストックレベルおよび前記発注点を在庫表管理システムにエクスポートするステップと、
資産管理のために、前記ストックレベルおよび前記発注点についての前記在庫表管理システムを在庫表管理データウェアハウスに更新するステップとをさらに含む、請求項９に記載のサプライチェーンのためのデータクリーニングプロセス。
データクリーニングシステムであって、
データフォーマッティングユーティリティを含み、前記データフォーマッティングユーティリティは、少なくとも２つのソースシステムからダウンロードされたデータを検証するのに用いられ、前記データクリーニングシステムはさらに、
データクリーニングユーティリティを含み、前記データクリーニングユーティリティは、前記データをクリーニングするのに用いられ、前記データクリーニングシステムはさらに、
正規化データクリーニングリポジトリを含み、前記正規化データクリーニングリポジトリは前記フォーマットされクレンジングされたデータを受信し、前記データクリーニングシステムはさらに、
ソース優先順位付けユーティリティを含み、前記ソース優先順位付けユーティリティは、前記少なくとも２つのソースシステムの優先順位を選択するのに用いられ、前記データクリーニングシステムはさらに、
クリーンなデータベースを含み、前記クリーンなデータベースは、前記クレンジングされたデータおよび優先順位が付けられたデータを組合せ、前記クリーンなデータベースは、各データ要素のための最良値および固有のデータ識別子を含むアイテムデータの単一のソースであり、前記データクリーニングシステムはさらに、
相互参照ユーティリティを含み、前記相互参照ユーティリティは、前記固有のデータ識別子間の相互参照を作成および維持するのに用いられ、前記データクリーニングシステムはさらに、
データクリーニングユーザインターフェイスを含み、前記データクリーニングユーザインターフェイスは、ユーザが前記クリーンなデータベースを更新することを可能にする、データクリーニングシステム。
抽出、変換およびロードツールをさらに含み、前記抽出、変換およびロードツールは、前記少なくとも２つのソースシステムから前記データを抽出し、データクリーニングのために前記データを共通のフォーマットに変換し、前記データを前記データクリーニングシステムにロードする、請求項１４に記載のデータクリーニングシステム。
前記抽出、変換およびロードツールは、前記クリーンなデータベースからの前記データを、前記データを用いるデータシステムおよびソフトウェアツールにとって必要なフォーマットにロードするのに用いられる、請求項１５に記載のデータクリーニングシステム。
前記クリーンなデータベースはデータ要素およびソースのマスタテーブルである、請求項１４に記載のデータクリーニングシステム。
標準化データクリーニングおよび管理レポートをさらに含み、前記レポートは、前記データ要素およびソースのマスタテーブルに含まれる前記データから作成され得る、請求項１７に記載のデータクリーニングシステム。
前記データクリーニングユーティリティは、前記ソースシステムから前記データクリーニングフォーマットにロードされるデータの有効性を確実にするために用いられる、請求項１４に記載のデータクリーニングシステム。
前記ソース優先順位付けユーティリティは以前の優先順位付けの履歴記録を維持する、請求項１４に記載のデータクリーニングシステム。
前記データ要素およびソースのマスタテーブルは各データ要素のソースに対するトレーサビリティを維持する、請求項１４に記載のデータクリーニングシステム。
前記データクリーニングシステムは前記少なくとも２つのソースシステムからデータを受信し、前記データクリーニングシステムは、前記データシステムおよびソフトウェアツールに対して、矛盾がなく、正規化され、かつ、クレンジングされたデータを供給し、ユーザは、前記ソースシステムを更新することなく前記データクリーニングシステムを更新し得る、請求項１４に記載のデータクリーニングシステム。
前記ソフトウェアツールはサプライチェーンソフトウェアである、請求項２２に記載のデータクリーニングシステム。
前記データシステムは在庫表管理システムである、請求項２２に記載のデータクリーニングシステム。