(57)【要約】【課題】スペアパーツの在庫管理を円滑に行う。【解決手段】部品管理システムは、製造資産に対するパーツ在庫所要量を示す文書の作成及び調整を合理化する１若しくは複数のソフトウェアツールを含むことができる。部品管理システムを用いて、在庫許可文書をオンラインで処理することによって承認プロセスを強化することができる。さらに、ＳＡＰなどの企業資源計画システムとインターフェースをとることによって、部品及び在庫管理をより効率的かつフレキシブルにすることができる。例えば、部品のインストールベースの将来版のシミュレーションを用いて、先を見越した部品管理に有用な部品予測文書を作成することができる。別の例として、資産定義文書及び在庫許可文書をオンライン形式で処理することによって、企業資源管理システムから情報を検索し、企業資源管理システムへ情報をアップロードすることができる。【選択図】図２
2010535366.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ化された在庫管理の方法であって、
少なくとも１つのキューを維持するステップと、
少なくとも１つの製造資産に関連付けられている１若しくは複数の部品在庫所要量を識別するデータを含む資産定義文書を、前記少なくとも１つのキューに置くステップと、
前記１若しくは複数の部品在庫所要量の１若しくは複数の修正を定義する設計データを受信するステップと、
前記設計データを受信した後に、修正された前記１若しくは複数の部品在庫所要量を識別するように前記資産定義文書を更新するステップと、
修正された前記１若しくは複数の部品所要量に基づいて、在庫許可の承認が必要とされるか否かを決定するステップとを含むことを特徴とする方法。
【請求項２】
設計データを受信する前に、少なくとも１つの製造資産を識別する選択データを受信するステップと、
前記少なくとも１つの識別された製造資産に関連付けられているデータに対して少なくとも１つの企業管理データセットに対するクエリを実行するステップと、
前記クエリの結果に基づいて資産定義文書を作成するステップとをさらに含み、
前記置くステップが、前記作成された資産定義文書を前記少なくとも１つのキューに置くステップを含むことを特徴とする請求項１の方法。
【請求項３】
前記クエリを実行するステップの前に、少なくとも１つの企業資源計画データベースにアクセスし、各部分が製造資産と関連付けられているような前記データベースの複数の部分のイメージを作成するステップをさらに含み、
前記企業資源計画データセットが、前記企業資源計画データベースの前記イメージ化された部分を含むことを特徴とする請求項２の方法。
【請求項４】
前記少なくとも１つの部分に関連付けられている製造資産が進行中のプロジェクトに関連付けられているか否かの決定に基づいて、少なくとも１つの部分のイメージが更新されることを特徴とする請求項３の方法。
【請求項５】
前記製造資産に関連付けられている資産定義文書の少なくとも１つのバージョンに含まれるにデータ基づいて、前記少なくとも１つの製造資産に関連付けられている少なくとも１つの部品在庫所要量への変更を決定するステップをさらに含むことを特徴とする請求項２の方法。
【請求項６】
少なくとも１つの部品在庫所要量の前記決定された変更に基づいて、部品在庫予測文書を作成するステップをさらに含み、
前記部品在庫予測文書が、或る施設での部品在庫所要量の少なくとも１つの与えられた変更を定義するデータを含むことを特徴とする請求項５の方法。
【請求項７】
前記部品在庫予測文書を作成するステップが、
各決定された変更に関連付けられている与えられた日付を示すデータにアクセスするステップと、
前記施設のための現在の部品在庫所要量を定義するデータに関して、少なくとも１つの企業管理データセットに対するクエリを実行するステップと、
前記現在の部品在庫所要量、前記決定された少なくとも１つの部品所要量の変更、及び各決定された変更に関連付けられている前記与えられた日付に基づいて、前記施設のための将来の部品在庫所要量をシミュレートするステップとをさらに含むことを特徴とする請求項６の方法。
【請求項８】
少なくとも第１及び第２のキューを維持するステップと、
前記第１のキュー内の少なくとも１つの資産定義文書に関するリリースデータを受信するステップと、
前記リリースデータに応じて前記少なくとも１つの資産定義文書を前記第２のキューに転送するステップをさらに含み、
前記置くステップが前記資産定義文書を前記第１のキューに置くステップを含むことを特徴とする請求項１の方法。
【請求項９】
前記第２のキューにおいて前記資産定義文書内の前記部品在庫所要量への１若しくは複数の監督者の修正を定義する監督者設計データを受信するステップと、
修正された少なくとも１つの部品在庫所要量を定義するように前記資産定義文書を更新するステップと、
修正された前記１若しくは複数の部品在庫所要量に基づいて、在庫許可の承認が必要とされているか否かを決定するステップとをさらに含むことを特徴とする請求項８の方法。
【請求項１０】
前記第２のキュー内の少なくとも１つの資産定義文書に対する承認データを受信するステップと、
前記承認データが承認を示すならば、
前記第２のキューにおいて前記資産定義文書内に定義された製造資産に対する少なくとも１つの部品在庫所要量を反映させるように少なくとも１つの企業管理データベース内のデータを修正するステップと、
前記承認データが却下を示すならば、
前記少なくとも１つの企業管理データベースを修正することなく、前記少なくとも１つの資産定義文書を前記少なくとも１つの他のキューに置くステップとをさらに含むことを特徴とする請求項８の方法。
【請求項１１】
前記維持するステップが、少なくとも第１、第２、第３のキューを維持するステップを含み、
前記方法が、
前記第２のキュー内の少なくとも１つの資産定義文書に関する承認データを受信するステップと、
前記承認データが承認を示すならば、
前記リリースデータに応じて前記少なくとも１つの資産定義文書を前記第３のキュー内に置くステップと、
前記承認データが却下を示すならば、
前記少なくとも１つの資産定義文書を前記第３のキュー以外のキュー内に置くステップをさらに含むことを特徴とする請求項８の方法。
【請求項１２】
或る部品に対して在庫許可の承認が必要とされる場合、前記資産定義文書に対応する少なくとも１つの在庫許可文書が利用可能であるか否かを決定するステップと、
少なくとも１つの在庫許可文書が利用可能であれば、前記部品に関連するデータを含むように前記在庫許可文書を更新するステップと、
少なくとも１つの在庫許可文書が利用可能でなければ、前記部品に関連するデータを含む在庫許可文書を作成し、前記在庫許可文書を少なくとも１つのキューに置くステップをさらに含むことを特徴とする請求項１の方法。
【請求項１３】
前記在庫許可文書を置くステップが、前記在庫許可文書を第１のキューに置くステップを含み、
前記方法が、
少なくとも第２のキューを維持するステップと、
前記第１のキュー内の少なくとも１つの在庫許可文書に関連するリリースデータを受信するステップと、
前記リリースデータに応じて前記少なくとも１つの在庫許可文書を前記第２のキューに転送するステップをさらに含むことを特徴とする請求項１２の方法。
【請求項１４】
前記少なくとも１つのキュー内の少なくとも１つの在庫許可文書に対する承認データを受信するステップと、
前記承認データが承認を示すならば、少なくとも１つの企業管理データベースを、前記在庫許可文書において指定されたデータを含むように修正するステップをさらに含むことを特徴とする請求項１２の方法。
【請求項１５】
部品管理システムであって、
請求項１ないし１４のいずれか１つに記載の方法を実行するように適合された少なくとも１つの計算装置を含むことを特徴とするシステム。
【請求項１６】
少なくとも１つの計算装置を含む部品管理システムであって、
前記少なくとも１つの計算装置が、
少なくとも１つのキューを維持し、
少なくとも１つの製造資産に関連付けられている１若しくは複数の部品在庫所要量を識別するデータを含む資産定義文書を、前記少なくとも１つのキューに置き、
前記１若しくは複数の部品在庫所要量への１若しくは複数の修正を定義する設計データを受信し、
設計データを受信した後、修正された前記１若しくは複数の部品在庫所要量を識別するように前記資産定義文書を更新し、
修正された前記１若しくは複数の部品所要量に基づいて、在庫許可の承認が必要とされているか否かを決定するように適合されていることを特徴とするシステム。
【請求項１７】
前記少なくとも１つの計算装置が、
少なくとも１つの企業計画データベースにアクセスして、各部分が製造資産と関連付けられているような前記データベースの複数の部分のイメージを作成し、
設計データを受信する前に、少なくとも１つの製造資産を識別する選択データを受信し、
前記少なくとも１つの識別された製造資産に関連付けられているデータに対して、前記データベースのイメージ化された部分を含む少なくとも１つの企業管理データセットに対するクエリを実行し、
前記クエリの結果に基づいて、資産定義文書を作成するようにさらに適合され、
前記置くステップが、前記作成された資産定義文書を前記少なくとも１つのキューに置くステップを含み、
前記企業計画データベースの少なくとも１つの部分のイメージが、前記少なくとも１つの部分に関連付けられている前記製造資産が進行中のプロジェクトに含まれているか否かの決定に基づいて更新されることを特徴とする請求項１６のシステム。
【請求項１８】
前記少なくとも１つの計算装置が、
前記製造資産に関連付けられている資産定義文書の少なくとも１つのバージョンに含まれるデータに基づいて、前記少なくとも１つの製造資産に関連付けられている少なくとも１つの部品在庫所要量への変更を決定するようにさらに適合されていることを特徴とする請求項１７のシステム。
【請求項１９】
前記少なくとも１つの計算装置が、
前記少なくとも１つの製造資産への変更に基づいて、部品のインストールベースにおける少なくとも１つの与えられた変更を定義するデータを含む部品在庫予測文書を作成するようにさらに適合され、
前記部品在庫予測文書が、
各決定された変更に関連付けられている与えられた日付を示すデータにアクセスし、
前記現在の部品のインストールベースを定義するデータに関して、少なくとも１つの企業管理データベースに対するクエリを実行し、
前記現在のインストールベース、前記決定された少なくとも１つの部品所要量の変更、及び各決定された変更に関連付けられている前記与えられた日付に基づいて、将来の日付での少なくとも１つの将来の部品のインストールベースをシミュレートすることによって作成されることを特徴とする請求項１８のシステム。
【請求項２０】
前記少なくとも１つの計算装置が、
前記資産定義文書が置かれている第１のキューと、第２のキューとを少なくとも維持し、
前記第１のキュー内の少なくとも１つの資産定義文書に関するリリースデータを受信し、
前記リリースデータに応じて前記少なくとも１つの資産定義文書を前記第２のキューに転送するようにさらに適合されていることを特徴とする請求項１６のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、企業の部品在庫管理に関する。
【背景技術】
【０００２】
製造企業は、様々な工程（プロセス）を支援するために、数千とは言わないまでも数百の部品を用いている。例えば、企業は、１若しくは複数の工場または施設からなることがあり、各工場／施設は、企業の事業目標を達成するために、複数の機械または設備を用いている。各機械または設備は、適切なメンテナンス及び稼働のために用いられる個々のパーツ、サブアセンブリ及びツールなどの多くの部品を含みかつ／またはそのような部品に関連付けられている。企業は、その事業目標を達成するために、既存の工程を維持しかつ新たな工程の稼働を開始する際に用いるための十分な量の部品をいつでも在庫として持っている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願第１１／３２１，７５９号
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、十分な量の部品を在庫として持つことは、かなりの難しい課題及びリスクを伴う場合がある。例えば、部品の在庫が多すぎると、企業はめったに必要とされないかまたはもう使われることのないスペアパーツなどの不要または稀にしか使わない部品に過度に資本を拘束されかねない。その一方で、部品の在庫量が不十分だと、企業には既存の工程の中断及び／または新たな工程の開始の遅延というリスクがあり、そのどちらもがかなりの経済的損失をもたらしかねない。従って、企業は通常、スペアパーツの在庫管理を円滑に行うために多額の投資をしている。
【課題を解決するための手段】
【０００５】
本明細書では、「製造資産」なる語は、企業が行う１若しくは複数の工程（プロセス）を支援するために用いられる任意の設備を含むものとする。例として、これに限定されるものではないが、製造資産には、機械、複数の機械を含む組立ライン及び／または工場または施設全体（工場または施設は１若しくは複数の機械及び／または組立ラインを含む）を含めることができる。しかし、「製造資産」なる語は、原材料、半加工材または製造工程中に加工される他の資材を意味するものではない。
【０００６】
「部品」なる語は、製造資産の任意の構成パーツと、資産（例えば、ツール、ツールキットなど）の加工のサポートまたはメンテナンスに用いられる任意の他のパーツとを指すものとする。「部品」なる語の範囲は、対象となる製造資産の状況によって異なることになる。例えば、製造資産に施設全体が含まれるのであれば、その部品には工場内の１若しくは複数の組立ラインが含まれ得る。製造資産に組立ラインが含まれるのであれば、その部品には個々の機械が含まれ得る。製造資産に機械が含まれるのであれば、その部品にはパーツ及びサブアセンブリが含まれ得る。製造資産にパーツまたはサブアセンブリが含まれるのであれば、その部品にはさらに他のパーツまたはサブアセンブリが含まれ得る。
【０００７】
一般的に、設計工程中に、コンテクストデータを用いて、設計変更、レビューまたは他の活動の対象となる１若しくは複数の製造資産を指定することができる。以下で検討できるように、コンテクストデータは、１若しくは複数の対象となる製造資産を意味する「プロジェクト」を参照することによって、指定されることができる。例えば、再設計プロジェクトは、機械または機械の一部などの製造資産を指定し得る。再設計プロジェクトのための部品は、プロジェクトにおいて対象となる機械またはサブアセンブリを構成するパーツ、サブアセンブリ及び他の設備を含むことができる。
【０００８】
「インストールベース（installed base）」なる語は、所与の時間に企業が使用する製造資産であり、もう使われなくなった資産、予備部品などの他の設備及び部品とは区別されると考えられているものを指すものとする。「インストールベース」の範囲は、インストールベースが考慮されている企業のレベルによって異なり得る。例えば、企業全体に対しては、インストールベースは全ての製造資産及びそれらの部品を含むことになる。工場に対しては、インストールベースは工場における全ての製造資産（機械及び／または組立ライン（及びそれらの部品）など）を含むことになる。機械に対しては、インストールベースは機械のパーツ及びサブアセンブリを含むことになる。
【０００９】
本発明は、操業を維持する際に用いられる部品の在庫を効率的に管理する企業の能力の向上と同時に部品在庫管理に費やされる資源の量の削減に関する。一部の実施形態では、製造資産のインストールベースへの変更が提案されることによって導入される部品所要量の変化を追跡することによって、かなりの節減が達成され得る。例えば、既存の資産構造を修正すると、部品所要量が変更され得る。パーツ在庫所要量の変更は、インストールベースへの新たな資産の追加、例えば新たな製造工程のための設備の追加などによっても、インストールベースから製造資産を取り除くことによってもすることができる。従って、先を見越したパーツ在庫及び他の経営意思を決定するために、企業の職員は、設計工程中の変更の程度を追跡することによって、情報の提供を受けることができる。加えて、または代わりに、部品在庫及び他の経営意思の側面は、変更の識別及び追跡に基づいて完全にまたは部分的に自動化され得る。
【００１０】
例えば、部品在庫管理を容易にするために、メンテナンスパーツ計画ソフトウェアツールを提供することができる。メンテナンスパーツ計画ツールを用いて、部品所要量の変更をモニタすることができる。決定された変更に基づいて、修正後の製造資産に対するパーツ所要量を修正前の製造資産に対するパーツ所要量と比較することによって、部品需要予測を作成することができる。加えて、一部の実施形態では、部品所要量の変更を追跡することによって、ソフトウェアツールは、部品在庫管理をサポートするための他の文書を作成することができる。一例として、製造資産を変更することで企業が現在在庫のない部品を仕入れる（在庫を持つ）ことが必要になるのであれば、設計承認プロセスが行われている間に部品を仕入れるための承認プロセスを開始するために、ソフトウェアツールは、在庫許可文書（authority to stock document：ＡＴＳ）を作成することができる。
【００１１】
一部の実施形態では、在庫を管理する方法は、少なくとも１つのキュー（待ち行列）を維持するステップを含むことができる。例えば、キューは、少なくとも１つの設計者キューを含み得る。例えば、サーバなどの１若しくは複数のコンピュータは、メンテナンスパーツ計画ソフトウェアツールによって、設計者（及び／または他の職員）が様々なタスクに関連付けられている文書にアクセスして修正することができるようなインタフェースを提供するように構成されることができる。本方法は、資産定義文書（asset definition document：ＡＤＤ）を設計者キュー（または他のキュー）に置くステップをさらに含むことができる。資産定義文書は、少なくとも１つの製造資産に関連付けられている１若しくは複数の部品在庫所要量を識別するデータを含むことができる。例えば、製造資産は、１若しくは複数のプロジェクトにおいて対象とされているような機械、サブアセンブリまたは全体工程を含み得る。部品在庫所要量は、例えば、別な方法で資産のメンテナンス及びサポート作業に関連付けられているようなパーツ、サブアセンブリ、モジュール、ツールキット及び／または製造資産或いは設備の他の構成部分のリストとともに、部品が仕入れられるか否か及びどのように仕入れられるかを示すデータを含み得る。
【００１２】
例えば、一部の実施形態では、資産定義文書は、資産の様々な部品を識別するスプレッドシートまたは他の電子文書として提示される場合がある。本方法は、製造資産に関連付けられている部品所要量の１若しくは複数の修正を定義する設計データを受信するステップをさらに含むことができる。例えば、技術者または他の適切な職員が、製造資産で用いられるかあるいは製造資産と併用される部品の変更及び／または在庫所要量の変更を手作業または自動で入力し得る。例えば、資産に機械が含まれ、設計者が機械を再設計して新たなパーツを使うのであれば、設計データは、既存の設計に用いられるパーツの変更及び／または追加を識別するデータを含み得る。別の例として、設計者が以前は使われていなかった機械を利用して新たな工程を実施しているならば、設計データは、新たな機械を製造するのに用いられるパーツを識別し得る。修正は、在庫として持つ必要がある１若しくは複数の部品の数の変更を含む場合がある。
【００１３】
設計データの受信完了後、本方法は、少なくとも１つの更新された製造資産を定義するように資産定義文書を更新するステップを含むことができる。例えば、技術者は、スプレッドシートまたは他の電子文書に変更を手作業で入力し得る。代わりに、または加えて、技術者は１若しくは複数の他のソフトウェアプログラム、例えば設計プログラムなどから変更をエクスポートし得る。変更は、資産定義文書の更新版として保存されることができる。例えば、資産定義文書は、資産定義文書に前の変更と並んで最新の変更が保存されるバージョンの追跡（トラッキング）をサポートし得る。代わりに、メンテナンスパーツ計画ソフトウェアツールは、元の資産定義文書を更新版と区別するためにバージョン管理を提供し得る。一部の実施形態では、設計データを受信する前に、本方法は、設計変更の対象になる少なくとも１つの製造資産を識別する選択データを受信するステップを含むことができる。例えば、技術者が既存の機械のための設計を修正しているならば、技術者は修正されている機械（または機械の一部）を識別し得る。代わりに、選択データは、新たな製造資産が定義されていることを示し得る。上記したように、設計、再設計または別な方法で変更するべき１若しくは複数の製造資産を識別するようなプロジェクトが、作成または選択され得る。プロジェクトは、設計変更の承認に関連付けられている職員及びキュー構造などの他の情報をさらに定義し得る。
【００１４】
本方法は、少なくとも１つの識別された製造資産に関連付けられているデータに対して少なくとも１つの企業資源計画（エンタープライズ・リソース・プラニング：ＥＲＰ）データセットに対するクエリを実行するステップを含むことができる。例えば、企業は、企業の資源管理のための集中型または分散型データベース（または複数のデータベース）を維持し得る。例えば、企業資源管理データベースは、製造資産履歴、費用などを追跡するために企業が用いるＳＡＰなどのシステムに関連付けられている１若しくは複数のデータベースを含み得る。企業資源管理データベースは、機械のための部品及び部品在庫所要量、及び各部品に関連付けられている技術、財務及び他のデータなど、様々な製造資産を定義するデータを含むことができる。少なくとも１つの企業資源計画データセットに対するクエリを実行するステップは、一部の実施形態では直接的に、他の実施形態では間接的に、企業資源計画システム・データベースにアクセスするステップを含むことができる。
【００１５】
例えば、本方法は、企業資源計画システム内のデータの複数の部分のイメージを作成するステップを含み得る。直接的に企業資源計画システムにアクセスするのではなくイメージにアクセスすることによって、企業資源計画データセットに対するクエリを実行することができる。一部の実施形態では、企業資源計画システムの異なる部分は、それぞれ別の時間にイメージ化（イメージ作成）され得る。例えば、進行中のプロジェクトの対象である製造資産に関するデータに対応する企業資源計画データの部分は、他の部分よりも定期的にイメージ化され得る。一部の実施形態では、１若しくは複数の進行中のプロジェクトの対象である製造資産に対応する企業資源計画データ項目は毎晩イメージ化され得るが、他の製造資産に関連付けられているデータ項目は３０日毎にイメージ化される。企業資源計画データセットのイメージは、例えば設計者キュー及び他のキューを提供しかつ資産定義文書を管理するような部品管理システムに関連付けられている１若しくは複数の計算装置によって維持され得る。
【００１６】
クエリの結果に基づいて、本方法は、設計者キューに置かれる文書である資産定義文書を作成するステップをさらに含むことができる。企業資源管理データベースにはまだ生成されていない資産に関連する情報が含まれていないことがあるので、新たな製造資産が定義される場合、資産定義文書は「白紙状態」からなることがある。当然のことながら、一部の実施形態では、新たに定義された資産に関連する新たな資産定義文書は、現在存在する資産に対する文書及び／またはテンプレートに基づくかあるいはそれに倣って作られ得る。他方では、現在存在する製造資産が修正されていれば、企業資源計画データセットからの既存のデータを用いて資産定義文書を追加することができる。
【００１７】
一部の実施形態では、本方法は、少なくとも１つの製造資産に関連付けられている少なくとも１つの部品所要量の変更を決定するステップをさらに含むことができる。例えば、上記したように、資産定義文書に指定された部品は、計画または提案された製造資産への修正に基づいて変更され得る。決定するステップは、更新された資産定義文書の内容と、資産に対する「現在の」部品所要量を反映しているデータを比較するステップを含むことができる。例えば、資産定義文書の内容は、企業資源計画データセットに指定された製造資産に対する部品在庫所要量と比較され得る。別の例として、資産定義文書の内容は、旧バージョンの資産定義文書内に指定された製造資産に対する部品在庫所要量と比較され得る。
【００１８】
本方法は、（少なくとも）修正された部品在庫所要量に基づいて、在庫許可の承認が必要であるか否かを決定するステップをさらに含むことができる。例えば、或る修正された部品在庫所要量は、以前に在庫として持ったことがない部品が在庫として持つ必要があるものとして示されていることを示す。一部の実施形態では、企業によって、そのような部品の追加は、１若しくは複数のレベルの承認を要求し得る。例えば、一部の実施形態では、如何なる現在在庫のない部品の追加も承認を必要とし得る。当然のことながら、他の実施形態では、全てのそのような追加が承認を必要とし得るとは限らない。
【００１９】
一部の実施形態では、承認が必要であるか否かの決定に基づいて、本方法は、所要量を追加する資産定義文書に関連付けられている１若しくは複数の在庫許可文書が利用可能であるか否かを決定するステップを含むことができる。そのような在庫許可文書が利用可能であれば、本方法は、所要量が追加される部品に関するデータを含むように在庫許可文書を更新するステップを含むことができる。１若しくは複数の在庫許可文書が利用可能でなければ、本方法は、所要量が追加される部品に関するデータを含む在庫許可文書を作成するステップを含むことができる。
【００２０】
多くの製造企業では、部品の在庫及び発注に関する決定は、複数のレベルで監視（管理）され得る。この監視は、最適な在庫レベルを確保するために必要であり得るが、かなりの資源の使用を意味する場合がある。例えば、設計終了後に承認プロセスが始まるのであれば、承認プロセスは、そうでなければ生産の準備が整っているであろう設計の実施を遅らせる場合がある。しかし、設計変更に応じて在庫許可文書を作成または更新することによって、承認プロセスは、部品がより早く利用できるようにするように（少なくとも部分的に）設計工程と並行して行われることができる。
【００２１】
例えば、製造資産が新たなパーツを含むように修正されたら、パーツ所要量の変更は、新たなパーツの仕入れを承認することができる在庫許可文書の作成をトリガすることができる。一部の実施形態では、在庫許可文書は、資産定義文書に指定されているデータによってトリガされ得る。例えば、資産定義文書を更新する技術者または他の職員は、或るパーツが企業によって仕入れられることになることを、チェックボックスを用いることなどによって指定し得る。本方法は、パーツが企業に現在在庫があるか否かを決定し、現在在庫がなければ在庫許可文書を作成するステップを含むことができる。
【００２２】
在庫許可文書は先ず、設計者キュー及び／または別のキュー内に置かれ得る。メンテナンスパーツ計画ソフトウェアツールは、資産定義文書に関連付けられている在庫許可文書の分配、変更及び承認／却下のための複数のキューをサポートすることができる。一部の実施形態では、資産定義文書内の部品の識別に基づき、他のデータが在庫許可文書に含まれる場合もある。例えば、パーツ識別及び仕様書データ、耐用期間及び交換間隔を決定するための公式、並びに推定調達時間を決定するためのデータが、当該部品に関して利用可能であり得る。例えば、そのような情報は、企業資源計画データセットにおいて利用可能であり得、企業資源計画データセットは各部品に対するそのようなデータの一部または全部を含むことができる。そのような利用可能情報は在庫許可文書にエクスポートされることができ、このことは、在庫許可文書を作成またはレビューする職員がそのような情報を個別に取得する必要がなくなるので、資源のかなりの節減をもたらし得る。
【００２３】
一部の実施形態では、製造資産の変更は、部品在庫予測文書の根拠として用いられることができる。例えば、部品在庫予測文書は、資産定義文書に提案された設計（または他の）変更が実施されるのであれば、与えられたレベルの部品在庫所要量を定義するデータを含むことができる。例えば、部品在庫予測文書は、機械、施設または企業レベルで部品のインストールベース内の予期される変更を示すことができる。一部の実施形態では、各変更に関連付けられている日付とともに部品所要量の変更を含むデータにアクセスすることによって、部品在庫予測文書を作成することができる。現在のインストールベースに関連付けられている所要量などの現在の部品在庫所要量を決定するために、企業資源管理データセットに対するクエリを実行することができる。部品所要量の決定された変更に基づいて、各変更に関連付けられている予測日、現在の部品在庫所要量、将来の部品在庫所要量をシミュレートすることができる。シミュレートされた所要量は、その後、部品在庫予測文書において用いられることができる。
【００２４】
例えば、進行中のプロジェクトに関連付けられた１若しくは複数の資産定義文書に指定された変更が実施されるとインストールベースが現れることになるので、部品在庫予測文書は、企業に対するインストールベースの推定を含むことができる。一部の実施形態では、部品在庫予測文書は、時間依存性の１若しくは複数のインジケータをさらに含むことができる。例えば、部品在庫所要量の変更に関連付けられている日付は、特別な処理を保証する一定期間内に含まれ得る。一例として、変更をスケジュール通りに実施するために予測文書の作成日から１４日以内に部品が仕入れまたは発注される必要があれば、当該部品は、部品在庫予測文書中でハイライトされるかまたは別な方法で注釈が付けられ得る。ハイライト表示及び／または他の注釈は、他の要因に従って変更し得る。別の例として、シミュレーションが、或る部品が部品在庫予測文書の作成日よりも前の日に発注されているべきであったのに発注されていなかったことを示すならば、その部品はハイライトされ得る。
【００２５】
一部の実施形態では、本方法は、設計者キューなどの少なくとも第１及び第２のキュー並びに１若しくは複数の監督者キューを維持するステップを含むことができる。本方法は、設計者キューなどの第１のキューにおいて、少なくとも１つの資産定義文書に関するデータを受信し、リリースデータに応じて、監督者キューなどの第２のキューに資産定義文書を置くステップを含むことができる。第２のキュー内の資産定義文書に関して、本方法は、製造資産への１若しくは複数の監督者の修正を定義する監督者設計データを受信するステップをさらに含むことができる。例えば、管理者または他の監督者は、設計キューの技術者または他のユーザによって供給される設計変更をレビューし得る。管理者は、設計への１若しくは複数の変更をなすことを望むであろうし、資産定義文書を監督者キューにある間に更新することによってそのような変更をなすことができる。
【００２６】
本方法は、第２のキューの管理者または他のユーザによってなされた変更に基づいて、在庫許可文書の変更をトリガしかつ／または資産定義文書に関連付けられている既存の在庫許可文書の変更をトリガするステップを含むことができる。例えば、管理者が現在在庫のないパーツを企業に現在在庫のあるパーツと置き換えるならば、変更は、キューに現在ある在庫許可文書の削除または保留をトリガすることができる。別の例として、管理者が現在在庫のないパーツを追加すれば、在庫許可文書が作成されることができる。（例えば、別の現在在庫のないパーツに対する承認を得るために）在庫許可文書が既に資産定義文書に関連付けられているならば、既存の在庫許可文書が、追加された現在在庫のないパーツも含むように更新されることができる。当然のことながら、在庫許可文書の作成／変更は、他の方法でトリガされてもよい。例えば、管理者が文書内の在庫決定を変えても、資産定義文書中の部品は変更されないままであり得る。
【００２７】
本方法は、設計者キュー及び複数の監督者キューを含み得るような少なくとも第１、第２及び第３のキューなどの複数のキューを維持するステップをさらに含むことができる。例えば、第１の監督者キューは、資産定義文書を受信しかつ文書の承認または却下のいずれかを行い得る。文書が承認されると、文書は第２の監督者キューに提供され得る。文書が却下されると、文書は設計者キューなどの別のキューに戻され得る。
【００２８】
一部の実施形態では、本方法は、或るキューにおいて少なくとも１つの資産定義文書のための承認データを受信するステップをさらに含むことができる。承認データが、設計が承認されていることを示すならば、本方法は、監督者キューにおける資産定義文書において定義された製造資産への修正を反映させるように少なくとも１つの企業計画データベース内のデータを修正するステップを含むことができる。例えば、部品管理システムは、承認された資産定義文書に定義された少なくとも１つの部品在庫所要量を反映するために、データを企業資源計画システムに送信し、企業資源計画システムによって維持されているデータを変更することができる。例えば、ＳＡＰを用いている企業では、ひとたび資産定義文書が必要なレベルの承認を通過したら、資産定義文書に定義された製造資産への変更は実施の承認がなされたものと考えられ得、変更はＳＡＰにアップロードされ得る。
【００２９】
しかし、承認データが却下を示すならば、本方法は、企業資源管理データベースを修正することなしに資産定義文書を設計者キューに置くステップを含むことができる。例えば、技術者による設計変更を監督者が却下したら、資産定義文書は別のキューに置かれ得る。文書は、文書が却下された監督者キューと設計者キューの間で設計者キューまたは監督者キュー（または他のキュー）に戻され得る。
【００３０】
一部の実施形態では、一定の監督者キューのみが企業資源計画データベースの修正を開始し得る。例えば、修正を開始することができるような１若しくは複数の中間監督者キューが設計者キューと監督者キューの間にあり得るが、中間監督者キューは資産定義文書の承認または却下に限定されている。中間監督者キューの一部または全部は、資産定義文書を修正する権限も有し得る。
【００３１】
一部の実施形態では、本方法は、承認データに応じて在庫許可文書を少なくとも１つの監督者キューに提供するステップを含み得る。在庫許可文書は、１若しくは複数の資産定義文書に関連付けられることができ、それらの文書内で変更を反映するように更新され得る。本方法は、ひとたび最終承認が受信されたらデータを在庫許可文書から企業資源計画システムへアップロードするステップをさらに含むことができる。例えば、企業資源計画システムが承認された在庫許可文書において指定されたデータを含むようにデータが企業資源計画システムに送信され得る。例えば、部品の識別、発注及び配送データ、承認の証拠（プルーフ）などがアップロードされ得、かつ／または、設計変更の時点で企業に在庫のなかったパーツの承認を文書化するために企業資源計画システム内の既存のデータが修正され得る。
【００３２】
部品管理システムは、部品管理機能を提供するように適合された少なくとも１つの計算装置を含むことができる。１若しくは複数の計算装置が用いられ得、装置は任意の適切なタイプまたは配置のハードウェア及びソフトウェアを含み得る。装置は、１若しくは複数のソフトウェア・アプリケーション及び／または専門のハードウェア・コンポーネントによって機能性を提供するように適合され得る。
【図面の簡単な説明】
【００３３】
【図１】部品管理システムを提供するのに用いられるハードウェア・コンポーネント及びネットワーク接続を、企業資源計画システムを提供するのに用いられるハードウェアを示す例示的な部品とともに示すブロック図。
【図２】部品管理システムにおける例示的なデータ構造及びデータフローを示すブロック図。
【図３】設計者キューなどのキューにおける例示的なワークフロー内のステップを示すフローチャート。
【図４】監督者キューなどのキューにおける例示的なワークフロー内のステップを示すフローチャート。
【図５】最終承認権限を有する監督者キューなどのキューにおける例示的なワークフロー内のステップを示すフローチャート。
【図６】企業資源計画システム・データセットの一部をイメージ化するための例示的なプロセス内のステップを示すフローチャート。
【図７】在庫許可文書を作成しかつ／または更新するための例示的なプロセス内のステップを示すフローチャート。
【図８】部品需要予測文書を作成するための例示的なプロセス内のステップを示すフローチャート。
【図９】部品管理システムにおける例示的な構造及びデータフローを示すフローチャート。
【発明を実施するための形態】
【００３４】
ここで、本発明の様々な実施形態について詳細に参照し、それらのうちの１若しくは複数の例を添付図面に示す。各例は、本開示の例として与えられるが、
例の特定のものに制約されるものではない。事実、本発明の範囲または趣旨から逸脱することなしに様々な修正及び改変をなし得ることは当業者であれば容易に分かるであろう。例えば、１つの実施形態の一部として図示または説明されている機能を別の実施形態で用いてさらなる実施形態を生み出すことができる。それゆえ、本開示は、特許請求の範囲及びそれに相当するものの範囲内にあるそのような修正形態及び変形形態を対象とするものとする。
【００３５】
図１は、本発明の実施形態を実施するために用いることができる例示的なシステム９を示すブロック図である。この例では、部品管理システム１０は、部品管理システムサーバ１４及び部品管理システムデータベース１３を含む。サーバ１４は、任意の適切な数の計算装置を含み得る。計算装置は、専ら部品管理システム内での使用に充てられ得るか、あるいは他のタスクと並んで部品管理機能性をサポートし得る。データベース１３は、データを保存及び検索するために用いられる任意の適切な論理的及び／または物理的配置の部品を含み得る。部品管理のために、データベース１３は、製造資産またはそれらのパーツを定義するデータ、部品の変更（及び文書自体）の承認プロセスにおいて用いられる様々な文書の状態、及び以前の設計変更及び承認に関するアーカイブされたデータを含むことができる。データベース１３は、専用の部品管理データベースを含み得るか、あるいは別の、より大きなデータベースの一部を含み得る。部品管理システム１０は、任意の適切な数または配置の計算装置を含み得、１つの位置または複数の位置にわたって配置された部品を含み得る。
【００３６】
企業資源計画システム１２はまた、サーバ（この例ではサーバ１８）を企業資源計画データベース２０とともに含む。公知のＳＡＰシステムなどの企業資源計画システムは、会計、在庫及び他の企業活動をサポートするために用いられてきた。典型的なシステムは、データベース２０などの１若しくは複数のデータベースと並んでサーバ１８などの１若しくは複数の計算装置を用いて、企業情報を連動的に保存及び制御する。上記したように、サーバ１４に関しては、サーバ１８は任意の適切な数、種類及び／または配置の計算装置を含み得、データベース２０は任意の適切な論理的または物理的配置に１若しくは複数のデータベースを含み得る。企業資源計画システム１２の部品は、１つの位置に配置され得るか、あるいは複数の位置に分散され得る。ＳＡＰは現在人気のある一式の企業資源計画ツールであるが、本発明は、追加または代替ツールと同時に用いられることができ、ＳＡＰソフトウェアを利用するシステムとの併用に限定されるものではない。例えば、オラクル、マイクロソフトまたはＢＡＡＮ社製などの他の企業資源計画ソフトウェア一式が用いられ得る。別の例として、企業は、資源管理のための専用のソフトウェアまたは社内で開発されたソフトウェアを利用し得る。
【００３７】
本明細書中の例は１つの企業資源計画システムを示しているが、部品管理システムを、これらの例の１つの企業資源計画システムの機能性を提供する複数のシステムとともに機能するように適合させることができる。
【００３８】
接続１６は、部品管理システム１０と企業資源計画システム１２間のデータの交換を表している。例えば、部品管理システム１０及び資源計画システム１２が異なる計算装置を用いているのであれば、接続１６はシステム間の１若しくは複数のネットワーク接続（広域接続、ローカルエリア接続及び／または他の接続）を表し得る。部品管理システム１０及び資源計画システム１２が同じかまたは重複する計算装置を用いているのであれば、データは２つのシステム間で内部で転送され得る。
【００３９】
一般的に、企業資源管理計画システム１２は、資産が変更されるときに製造資産の「現在の」状況に関するデータのデータソースとして、部品管理システム１０によって用いられる。例えば、企業資源計画システムは、企業の部品のインストールベースに関する在庫データを含むことになる。本発明は、企業資源計画システム１２がインストールベースに対する部品データを利用できるようにする限り、企業資源計画システム１２に対する特定のタイプ、アーキテクチャ、またはデータ形式の使用を必要としない。一例として、所与の工場に対して、企業資源計画システムは、工場で積極的に使用されている様々な組立ライン、機械及び他の設備の部品に関する部品表（Ｂ．Ｏ．Ｍ）、在庫所要量、及び他のパーツデータを含む在庫データを利用できるようにすることができる。
【００４０】
しかし、インストールベースが（例えば、１若しくは複数の製造資産の再設計や製造資産の追加、あるいは製造資産の削除によって）変更されることになるならば、企業の部品所要量は変わることになる。企業資源計画システム１２からのデータを用いて、製造資産の設計／再設計中の企業の部品所要量の変更の識別及び計画プロセス中に用いられる様々な計画文書を追加することができる。部品管理システム１０を用いて、それらの計画文書を維持し、設計変更に関連付けられている部品所要量の変更ステータスを追跡し、かつ別な方法で調整を設計変更プロセス中に行うことができる。この調整は、企業のあらゆるレベルに広げることができる。さらに、部品管理システム１０は、部品を在庫として持つための承認プロセスの部分的または完全自動化を可能にすることができる。
【００４１】
一部の実施形態では、企業資源計画システムデータベース２０の内容などの企業資源計画システム１２によって維持されているデータは、設計及び承認プロセス中に企業資源計画システムから直接アクセスされない。代わりに、企業資源計画システムの１若しくは複数のイメージが、例えば部品管理システム１０によって取得または維持されることができる。従って、企業資源計画システムから得られるデータは、データが企業資源計画システムから直接または間接的にアクセスされ得るので、本明細書では「企業資源計画システム・データセット」と呼ばれる。例えば、企業資源計画システム１２が、設計工程中に職員に干渉されずにその正常なサポートの役割を果たすことを許可され得るように、企業資源計画システム１２によって維持されているデータのイメージ（イメージは部品計画システム１０にアクセス可能である）を提供することは、状況次第では有利であり得る。例えば、企業資源計画システム・データの一部または全部をイメージ化することによって、インストールベースの提案された変更に関連付けられかつ在庫決定に関連付けられたクエリ及び他のシステムオーバヘッドは、企業資源計画システムのリソースに重い負担をかけるのではなく、部品システム１０によって処理されることができる。
【００４２】
図１はさらに、複数のユーザ計算装置、すなわちユーザ計算装置２２、２４及び２６を示している。各計算装置は、例えば、ラップトップ、サーバ、デスクトップ、タブレットまたは他のコンピュータ、あるいは個人用携帯情報端末（ＰＤＡ）、携帯電話、ネットワーク端末などの別の計算装置を含み得る。
【００４３】
各計算装置は、任意の適切な数及び配置のネットワークリンクを介して、部品管理システム１０にリンクされている。計算装置２２はネットワークリンク２８を介して部品管理システム１０に接続され、計算装置２４はネットワークリンク３２を介して部品管理システム１０に接続され、計算装置２６はネットワークリンク３０及び３２を介して部品管理システム１０に接続されている。
【００４４】
ネットワークリンクは、説明のためだけのものであり、限定的なものではない。任意の適切なネットワークリンクが、直接であれ間接であれ用いられ得る。例えば、計算装置２２、２４及び２６、部品管理システムサーバ１４及び／または企業資源計画サーバ１８のうちの一部または全部は、インターネット、ローカルエリア・ネットワーク、または企業のイントラネットなどの広域ネットワークにリンクされ得る。図１に示す装置は、複数の方法で互いにリンクされ得る。例えば、図１には示されていないが、各装置２２、２４、２６はさらに、企業資源計画サーバ１８にも接続され得る。
【００４５】
一部の実施形態では、部品管理システム１０は、部品管理をサポートするための様々な機能性を提供するようにシステム１０を構成する１若しくは複数の部品管理ソフトウェアツールを含むことができる。「ソフトウェアツール」なる語が用いられているが、実際の実装は、ソフトウェアベース、ハードウェアベースのものであり得、あるいはハードウェアとソフトウェアの組合せを利用し得る。ソフトウェアツールは、様々なユーザがキュー及びそれらの内容にアクセスすることができるようなインタフェースを提供するように部品管理システムサーバ１４を構成することができる。ユーザによってかつ／または部品管理システムによって、部品管理文書及び他の文書を、様々なキューに置きかつ様々なキューから除去することができる。例えば、各ユーザは、設計及び／または部品調達承認プロセスにおいて各ユーザのそれぞれの役割によって決定される文書アクセス権、文書検索権及び文書修正権と共に、１若しくは複数のキューへのアクセスを有し得る。アクセス、検索、修正及び他の許可、並びにキューユーザ同士の互いに対する相対的な関係は、部品管理システム１０の構築中にデータによって定義されることができる。「文書」なる語が用いられているが、部品管理システム１０によって用いられる特定のデータ構造は可変であることを理解されたい。例えば、各資産定義文書、在庫許可文書及び他の文書は、一部の実施形態ではスプレッドシートまたは他の文書などの個別ファイルを含むことができる。
【００４６】
図１の計算装置２４は、例えば、製造資産の設計変更を行う際に技術者が用いる計算装置に相当し得る。それゆえ、ウィンドウ２４ａは、技術者に関連付けられかつ技術者によってアクセス可能な設計者キューの内容の表示を示し得る。計算装置２６は技術者の監督者が用いる装置に相当し得るので、ウィンドウ２６ａは監督者キューの内容の表示を示し得る。計算装置２２は、施設や企業のために在庫決定を管理するパーツ・コーディネータなどの追加監督者が用いる装置であり得る。それゆえ、ウィンドウ２２ａ及び２２ｂは各々、パーツ・コーディネータに対応する別の監督者キューの内容の表示を含み得る。
【００４７】
キュー及び文書は、任意の適切な方法でレンダリングされ得る。例えば、ユーザキュー及びその中の文書は、専門ソフトウェアまたは標準ソフトウェアコンポーネント（例えば、ウェブブラウザ、文書処理ソフト、表計算ソフトなど）の改変版を用いてレンダリングされ得る。部品管理サーバ１４は、暗号化されるかまたは別な方法で保護される接続でキューにパスワード保護を提供するなど、任意の適切なアクセス制限及び／または他のセキュリティ強化をサポートし得る。
【００４８】
キューの内容の管理は、任意の適切な方法でも同様に達成され得る。例えば、部品管理サーバ１４は、各キュー、ユーザ及び／または 文書に関連付けられている内容及びパラメータ（アクセス権、文書など）を識別する部品管理データベース１３内にデータを維持し得る。文書そのものは、データベース１３及び／または部品管理システム１０がアクセス可能な１若しくは複数の他の位置に保存され得る。
【００４９】
一例として、一部の実施形態では、部品管理ソフトウェアツールは、ワシントン州レドモンドのマイクロソフト社の．ＮＥＴフレームワークを用いて実装される。例えば、１若しくは複数の．ＮＥＴアプリケーションには、部品管理システムサーバ１４を介して、キューがＥメールソフトと同じようにアクセスされ得るユーザ・インタフェースを提供するアプリケーションが与えられ得る。例えば、各ユーザには、タスクのリスト及び共有資源へのアクセスを提供するインタフェースが与えられ得る。さらに、一部の実施形態では、．ＮＥＴアプリケーションは、資産定義文書、在庫許可文書及び／またはソフトウェアツールによって提供される他の文書などの文書を見て変更するためのスプレッドシートのようなユーザ・インタフェースを提供することができる。加えて、ソフトウェアツールは、任意の適切なフォーマットまたは様式でエクスポートされることになる文書を提供し得る。資産定義文書を作成し、在庫許可文書を作成し、プロジェクト及び文書ステータスを追跡するなどのために用いられるデータは、例えば、フロントエンドを提供する．ＮＥＴアプリケーションとともに、部品管理システムデータベース１３に維持されているＳＱＬデータベース内に保存されることができる。
【００５０】
使用中、文書は、部品管理システム１０によって提供される様々なキューに置かれ得る。どのキューが次に文書を受信することになるのかを指定するシステムにデータを提供することによって、文書をシステムのユーザが見て修正し、その後文書を１若しくは複数の他のユーザに転送することができる。文書の経路、文書の内容及びキュー構造は、企業のニーズによって異なることになる。一部の実施形態では、ユーザは、文書を受信する次のキューのアドレスに関して制限的に制御し得るかまたは制御しないことがある。例えば、或るユーザは文書の承認及び／または文書の却下に制限され得るが、他のユーザは宛先キューの所定のリストから選択することができ、さらに他のユーザは自分で選択したキューを指定することができる。
【００５１】
例えば、後述の幾つかの例では、部品管理システム１０は、２種類の文書のための２つの経路、すなわち資産定義文書のための第１の経路及び在庫許可文書のための第２の経路を提供するように構成されることができる。資産定義文書は、製造資産への変更に関連付けられている部品所要量の変更を指定するために、技術者及び他の職員によって用いられる。在庫許可文書は、設計変更に関連付けられている部品を仕入れるか否か及びどのように仕入れるかを決定するステップにおいて適切な意思決定手順が踏まれたことを保証するために用いられる承認文書を表すことができる。
【００５２】
図２は、例示的な部品管理システム３１０によって提供されるようなデータ構造及びデータのフローを示すブロック図である。部品所要量の変更及びシステムが取る関連するアクションの幾つかの例について、図２とともに考察する。図２は、企業資源計画システム３１２の例示的な部分、すなわち例示的な企業資源計画データベース３２０の内容を示す。この例では、データベースは、それぞれの製造資産Ａ、Ｂ及びＣのための部品表３００、３０２及び３０４を含む。データベースは、資産Ａ、Ｂ及びＣのための部品在庫所要量３０１、３０３及び３０５をさらに含む。例えば、部品在庫所要量は、所望の量、位置を示すデータ及び部品表にリストアップされた部品の発注スケジュールを含み得る。企業資源計画システムデータベース３２０は、パーツデータ３０６をさらに含む。例えば、パーツデータ３０６は、技術仕様書、製造者データ、性能データ、再発注公式、及び多数のパーツに関する企業資源計画システム３１２内に維持されている他の情報を含み得る。例えば、データは、企業が使用するパーツ及び企業が使用しないパーツを含むパーツライブラリの一部であり得る。
【００５３】
繰り返して述べるが、図２に示すデータ構造は単なる例示のためのものである。図解及び説明を簡単にするために、図２には各資産に対する別々の部品表及び在庫所要量と、別々のパーツデータセットとが示されている。企業資源管理データベース３２０内のデータの正確な論理的及び物理的配置及び部品管理システムによって維持されているその対応するイメージは、用いられる特定のデータベース実装により異なる場合がある。
【００５４】
図２は、部品管理システムデータベース３１３を示す。この例では、矢印３０８は、企業資源計画データベース３２０内のデータの一部または全部が部品管理システムデータベース３１３内でイメージ化されることを示している。例えば、部品管理システムデータベース３１３は、それぞれの部品表３００、３０２及び３０４のイメージ３００’、３０２’及び３０４’と、パーツデータ３０６のイメージ３０６’と、在庫所要量３０１、３０３及び３０５のイメージ３０１’、３０３’及び３０５’とをそれぞれ含む。部品管理システムデータベース３１３は、部品管理システムデータ３０７をさらに含む。システムデータ３０７は、部品管理システムの作動をサポートするために用いられる追加情報を含み得、それには、限定されるものではないが、キュー構造及び内容を識別するデータと、進行中のプロジェクトに関連付けられている資産及び職員を識別するデータと、資産定義文書、在庫許可文書、部品予測文書などの文書の内容と、ユーザのプロフィール、嗜好及びパスワードなどのユーザデータと、以前の及び進行中のプロジェクトからのデータのアーカイブされたバージョンとが含まれる。
【００５５】
この例では、部品管理システム３１０は、設計者キュー３５０、監督者キュー３５２、３５４及び３５６（それぞれ図２において「監督者Ｉキュー」、「監督者Ｉ−Ａキュー」、「監督者２キュー」と表示されている）を含む複数のキューを提供するように構成される。この例のために、企業の組織は、設計の事柄に関して監督者Ｉに、パーツ在庫承認の事柄に関して監督者Ｉ−Ａに監督される設計者を含むと仮定する。この例では、監督者２は、パーツ在庫承認及び設計の両方の事柄に対する最終決定権を持つ。
【００５６】
例えば、設計者が、製造資産「Ａ」の設計を更新するプロジェクトに関わっていると仮定する。例えば、製造資産「Ａ」は、新たな製品を処理するように更新されている機械内にサブアセンブリを含み得る。そうするために、設計者及び／または他のユーザは、プロジェクトに関連付けられている製造資産とともにプロジェクトに関連付けられているユーザ及び役割を識別するなどして、プロジェクトを定義する部品管理システム３１０にデータを供給することができる。
【００５７】
資産定義文書３３０が、製造資産「Ａ」に関するデータに基づいて、部品管理システムによって作成され得る。例えば、部品管理システムは、部品のリスト及び現在のパーツ在庫所要量など資産Ａに関する情報に関して企業資源管理データセットに対するクエリを実行し得る。この情報及び可能な他の情報を用いて資産定義文書を作成することができる。データセットは、一部の実施形態では企業資源管理データベースから直接取得され得る。しかし、この例では、データセットは、企業資源管理データベース３１２のイメージ化された部分に対するクエリを実行することによって取得され得る。すなわち、資産定義文書３３０を作成／追加するために、イメージ化された部品表３００’及び部品在庫所要量３０１’に対するクエリが実行され得る。この例示的なクエリ実行及び文書作成は、図２に矢印４０６及び４０８で示されている。
【００５８】
一部の実施形態では、システム３１０などの部品管理システムは、企業資源計画データベース３１２からのデータの或る部分を他の部分より頻繁にイメージ化することによって、より良好なパーツ計画を提供し得る。例えば、一部の実施形態では、あらゆる製造資産に関するデータが、３０日毎など定期的に企業資源計画データベース３１２からイメージ化され得る。しかし、そのようなイメージ化は、部品管理システムに最良のデータセットを提供するとは限らない。例えば、毎月または他の間隔で、製造資産のインストールベースに変更が加えられ得る。一例として、保守要員及び他の職員によってなされるパーツの交換などの下限変更が生じ得る。そのような変更は、企業資源計画データベースに反映され得るが、イメージ化が定期的に生じなければ、資産定義文書は古い情報に基づく可能性がある。変更の例に戻ると、資産定義文書が作成された後に下限変更がなされるならば、資産定義文書は下限変更を反映しないであろう。
【００５９】
それゆえ、一部の実施形態では、より最近の企業資源計画データベースの一定部分の「スナップショット」が撮られる。例えば、進行中のプロジェクトに関連付けられている資産に関する企業資源計画データベース３１２の部分が、毎晩または任意の他の適切な間隔でイメージ化され得る。当該部分は、企業資源計画データベース３１２内でソートされた１若しくは複数のデータ項目を含み得、データ項目は、各データ項目（及び／または他の識別子）に関連付けられている部品識別子を、１若しくは複数の進行中のプロジェクトに関連付けられている部品（または他のデータ項目）に相互参照させることによってイメージ化のために識別される。
【００６０】
図２を例に取れば、ひとたび製造資産Ａが進行中のプロジェクトの一部として指定されると、部品表３００及び在庫所要量データ３０１の毎晩のイメージ化がまだ行われていなければ、そのような毎晩のイメージ化が行われ得る。それゆえ、部品表イメージ３００’及び在庫所要量データイメージ３０１’は、製造資産Ａに対する企業資源計画データベースへの最新の変更を反映するようにリフレッシュされ得る。加えて、資産Ａに関連付けられているデータ項目及びパーツデータ３０６に含まれるデータ項目、例えば、部品情報、発注及び配送方式などが、パーツデータイメージ３０６’の対応する部分をリフレッシュするようにイメージ化され得る。イメージ化は、概ね矢印４００、４０２及び４０４によって表されている。
【００６１】
頻繁なイメージ化の更新はまた、有利には、重複する資産に影響を及ぼす設計プロジェクトの調整を助け得る。例えば、資産Ｂが製造資産Ａを利用する同じ機械の別のサブアセンブリを含むと仮定する。設計構想の一部として、資産Ｂは、製造資産Ａも調整する別の設計者または設計チームによって修正され得る。例えば、資産Ｂサブアセンブリが変更されたら、資産Ｂと資産Ａのサブアセンブリ間のインタフェースの変更は、資産Ａサブアセンブリの調整を必要とし得る。資産Ｂの設計チームによってなされた変更が企業資源計画データベース３２０にアップロードされたら、部品表３００及び３０１に反映された資産Ａへの関連する変更は、企業資源計画データベースのそれらの部分の定期的なイメージ化によって取り込まれることになる。
【００６２】
企業資源計画データセットのソースのイメージ化頻度または他の側面に関わらず、ひとたび製造資産Ａに関する適切なデータが得られると、資産定義文書３３０が作成され、その後設計者キュー３５０に置かれる。例えば、部品管理システム３１０は、Ｅメールのようなユーザ用インタフェースに、着信・発信メッセージとして表されるタスクを与え得る。設計者は、新たなタスクの準備が整っていること、すなわち製造資産Ａプロジェクトのための資産定義文書３３０を更新することを警告され得る。
【００６３】
設計者は、任意の適切な方法で資産定義文書３３０にアクセスすることができる。例えば、一部の実施形態では、資産定義文書３３０は、スプレッドシートを含むことができる。スプレッドシートは、任意の数の市販のソフトウェア・アプリケーションで用いるために初期化され得る。代わりに、部品管理システム３１０は、スプレッドシートなどの文書を見て、修正して保存できるような機能性を提供し得る。資産定義文書３３０は、当然のことながら、スプレッドシート以外の任意の適切なフォーマットを含むことができる。
【００６４】
設計者は、任意の適切な方法で製造資産Ａに対する部品在庫所要量を更新するデータを提供することができ、更新は矢印４１１で示されているようになされる。例えば、設計者は、変更をスプレッドシートへ手作業で入力し得るか、あるいは他の文書またはアプリケーションから変更をコピー・アンド・ペーストし得る。加えて、または代わりに、設計者は、他の文書またはアプリケーションからデータをエクスポートし得る。別の例として、設計者は、文書によって提供される１若しくは複数の選択肢からなる選択を示すことによって、例えば、チェックボックス（または他のインジケータ）を選択することによって、プルダウン・メニューから１若しくは複数のオプションを選択することによって、及び同様のことによって、データを提供し得る。
【００６５】
例えば、資産定義文書３３０は、通常動作でサブアセンブリ「Ａ」を構築しかつ維持するために用いられるツール及びパーツリスト、サブアセンブリを含み得る。設計変更の一部として、いくつかのパーツ所要量が変わることがある。例えば、サブアセンブリ「Ａ」が異なる材料を処理するように適合されているならば、 古い材料を処理するのに適したいくつかのパーツは、新しい材料を処理するためのパーツに置換されるかまたは適合させる必要があり得る。例えば、サブアセンブリＡが、オムツ製造機で材料を切断するために用いられると仮定する。設計変更によって、切断するのに力のいるようなより堅牢な材料（より強くて薄い材料など）が得られた場合、より強くて薄い材料を適切な方法で処理するためにブレード、アクチュエータなどの多くの部品を交換する必要があり得る。
【００６６】
設計者は、加えて、または代わりに、在庫所要量を指定し得る。例えば、設計変更は、現在在庫のない部品を仕入れる必要を生じさせ得るか、あるいは現在在庫のある部品の数の変更をもたらし得る。さらに、一部の実施形態では、設計変更は各々１若しくは複数の発効日に関連付けられている。例えば、各部品在庫所要量は、実施の発効日を有することができる。実施及び他の時間データは、予測文書及び他の文書の作成時に部品管理システムに用いられることができる。
【００６７】
設計変更に基づいて、設計者は資産定義文書３３０内のパーツリストを変更することができる。例えば、設計者は、現在のカッティングブレード及びアクチュエータを取り除いて、新しい材料を処理するための定格を持つパーツを代用し得る。この情報は、任意の適切な方法で提供され得る。例えば、正確なターミノロジーを用いるなどの目的で、及び／または部品数などのデータを直接インポートするために、パーツ仕様書データ３０６’は設計者によってアクセスされ得る。ひとたび設計者が所望の変更をなしたら、設計者は、「保存」オプションを選択することなどによって資産定義文書３３０を更新することができる。ひとたび設計者が、更新された資産定義文書に完全に満足したら、設計者は、矢印４１２及び４１４で示すように文書をレビューのために次のキューにリリースすることができる。図２では、設計者が修正した資産定義文書は、符号３３１で表されている。
【００６８】
上記したように、キューの配置及びキューからキューへの文書の流れ（フロー）は、企業の構造及びニーズによって異なることになる。キュー構造及び文書フローに関するデータは、プロジェクトを定義するパーツとして部品管理システム３１０に明記され得る。加えて、または代わりに、キュー構造及び文書フローの態様は、複数のプロジェクト及び／またはシステム全体にわたって適用可能であるものとして定義され得る。
【００６９】
手短に設計者に戻ると、一部の実施形態では、資産定義文書３３０は、１若しくは複数の仕入れ指示子をサポートし得る。例えば、各パーツ（または他の部品）と並んで、当該パーツ（または他の部品）が企業によって仕入れられることになるか否かを示すためのチェックボックスまたは他のインジケータが含まれる場合がある。設計変更時に在庫がないパーツを必要とさせるような設計変更は、効率的なパーツ管理の重大な課題を呈する場合がある。例えば、パーツを仕入れるか否かの決定は、通常は設計者以外の１人若しくは複数人の職員によって承認されなければならず、設計変更が有効になったときに、適切な供給量のパーツが確実に手元に供給されるように措置がタイムリーに講じられなければならない。具体的には、この例では、在庫許可文書は、設計者、監督者Ｉ−Ａ及び監督者２によって承認されなければならない。従って、一部の実施形態では、部品管理システムは、現在在庫のない部品の追加に関して資産定義文書をモニタする。
【００７０】
例えば、部品管理システムは、資産定義文書３３０中のパーツが「仕入れ」と示されているか否かを示すデータをモニタし得る。そのようなインジケータが「真」であれば、部品管理システムは、パーツが現在在庫があるか否かを評価し得る。例えば、パーツデータ３０６’（及び／または在庫所要量３０１’または他のデータ）は、企業がどのパーツの在庫を持ち、どのパーツの在庫を持っていないかを識別し得る。一部の実施形態では、設計変更が工場レベルで処理されるならば、チェックボックスは、或る部品を工場に在庫として持つ必要があるか否かを示し得る。パーツデータ３０６’は、部品の在庫があるか否かのみならず、その部品がどの工場に在庫としてあるかも示し得る。いずれにせよ、設計変更によって、現在在庫のないパーツが現在在庫のない場所で必要になったら、部品管理システムは、矢印４２４で示すように在庫許可文書３４０を作成することができる。
【００７１】
図２では、パーツデータ３０６’に基づいて在庫許可文書３４０が作成される。例えば、設計者は、（パーツデータ３０６’がパーツに関する情報を含むという意味で）システムに既知であるカッティングブレードを指定したが、設計者の施設には在庫がない場合を想定する。設計者は１若しくは複数の在庫許可文書を手作業で作成し得るが、このタスクは部品管理システムによる自動作成によって容易にされ得る。例えば、設計者は、製造資産Ａにおけるブレード部品の使用を指定しかつそれが工場に在庫として持つ必要があることを示し得る。パーツ指定（及び現在パーツの在庫がないという判定）に基づいて、部品管理システムは、在庫許可文書３４０を作成しかつ必要な情報を持つ文書を追加し得る。この情報は、例えばパーツ番号及び他の識別子、ソース情報、使用情報、発注情報などを含み得る。一部の実施形態では、在庫許可文書の作成の一部として、部品管理システムは、在庫許可文書の承認及び設計変更の発効日に基づくパーツの発注の必要なタイミングを決定し得る。この情報に基づいて、在庫許可文書は、設計者キュー及び監督者キューにおいて優先順位を決められ、それによって最適な時間枠において在庫許可文書が考慮されることが保証され得る。
【００７２】
図２に矢印４２６で示されるように、在庫許可文書３４０は、設計者キュー３５０に置かれ得、設計者（または他の職員）が作成された文書に変更または追加を行うことができる。ひとたびそれらの変更が最終的に決定されると、設計者は、矢印４２８及び４３３で示すように在庫許可文書を次のキューにリリースし得る。この例では、リリースされた在庫許可文書は符号３４１で示されている。例えば、部品管理システムは、手作業で入力された他のパーツに対する在庫許可文書を、自動的に作成された在庫許可文書に統合し得る。在庫許可文書３４１は、その後、監督者Ｉ−Ａによるレビューのために監督者キュー３５４に置かれる。一例として、監督者Ｉ−Ａは、適切なターミノロジー及び発注時期が指定されたことを保証するべく、パーツ管理の見通しから在庫決定を見直すことに関与し得る。
【００７３】
監督者Ｉ−Ａは、在庫許可文書３４１を承認するか、在庫許可文書３４１を修正しかつリリースするか、あるいは在庫許可文書３４１を却下し得る。例えば、在庫許可文書３４１は、却下されたら、矢印４３１で示すように設計者キュー３５０に戻され得る。しかし、在庫許可文書３４１は、承認されたら（または修正されてその後に承認されたら）、矢印４３２及び４３４で示すように監督者２によるレビューのためにキュー３５６に提供され得る。図２では、監督者Ｉ−Ａによってリリースされた在庫許可文書のバージョンは、明確にするために符号３４２で示されている。この例は、監督者２（詳細は後述）に戻ることになるが、ここでは資産定義文書３３１に戻る。
【００７４】
この例では、設計者によって修正された資産Ａのための部品在庫所要量を表す資産定義文書３３１が、監督者Ｉによるレビューのためにキュー３５２に置かれる。例えば、監督者Ｉは、設計者の仕事のチェック、パーツ互換性の確保、設計が企業の基準を満たしていることの確認に関与する工場長を表し得る。例えば、企業は、同種の用途に同種のカッティングブレードが用いられることを義務付けることがある。設計者が、例えば要求を満たせる程度に適切なブレードであるが好適でないブレードを指定したならば、監督者Ｉは設計を変更し得る。例えば、監督者Ｉは、資産定義文書３３１にアクセスして指定されたカッティングブレードを変更し得る。代わりに、または加えて、監督者Ｉは、評価のため、または設計者が変更を実施するために、資産定義文書を設計者に戻し得る。資産定義文書３３１は、却下されると、矢印４１３及び４１５で示すように設計者キュー３５０に戻される。しかし、監督者Ｉが資産定義文書を承認すれば、資産定義文書は矢印４１８及び４２０で示すように監督者２によるレビューのためにキュー３５６に置かれる。図２では、キュー３５６に置かれている資産定義文書のバージョンはＡＤＤ３３２として示されている。
【００７５】
場合によっては、監督者Ｉなどの監督者は、パーツ在庫決定回付ルート（チェーン）内の職員（監督者Ｉ−Ａなど）からの承認を必要とする場合がある資産定義文書への変更をなし得る。例えば、監督者Ｉが好適なブレードを要求するように資産定義文書を変更し、かつその好適なブレードを企業が現在在庫として持っていれば、在庫許可文書は必要ないであろう。その場合、在庫許可文書３４１（または、文書が既にキュー３５４を離れてしまっている場合は、在庫許可文書３４２）に関するアクティビティは、その部品に関する最終決定が下されるまで保留されることができる。別の例として、監督者Ｉは、追加の在庫のないパーツの仕入れを要求するように資産定義文書３３１を変更し得る。例えば、監督者Ｉは別の在庫のないパーツを追加し得る。変更は、新たな在庫許可文書の作成をトリガし得る。しかし、一部の実施形態では、変更は、在庫許可文書３４１などの既存の文書に反映され得る。
【００７６】
一般的に、部品管理システムは、一部の実施形態では１若しくは複数の資産定義文書と１若しくは複数の在庫許可文書を関連付けるように構成され得る。それゆえ、資産定義文書が変更されたら、システムは１若しくは複数の関連在庫許可文書を識別することができ、逆の場合も同じである。１つの文書内の変更は、他の対応する文書に自動的に反映され得る。加えて、変更は、キューからの１若しくは複数の文書の除去、別のキューへの１若しくは複数の文書の転送、及び／または変更された優先順位を反映するようにキュー内での文書の再順位付けをもたらすことができる。
【００７７】
監督者２は、この例では、在庫許可文書３４２などの在庫許可文書と、資産定義文書３３２などの資産定義文書とを両方承認する二重の役割を持っている。例えば、監督者２は、企業または工場レベルでのパーツ計画に関与し得る。監督者２（及び／または他の監督者）は、資産定義文書及び／または在庫許可文書の変更に関する限られた権限を有し得る。例えば、監督者２は、資産定義文書の承認または却下に制限され得るか、あるいは在庫所要量の数量の調整など一定の種類の変更に制限され得る。
【００７８】
この例では、監督者２は、最終的に部品所要量及び在庫許可文書への変更の最終的な決定にも関与する。それゆえ、ひとたび監督者２が資産定義文書（最終版が図２中に３３３で示されている）の承認（矢印４２２で示す）を示したら、資産定義文書に定義される部品在庫所要量への変更は、企業資源計画データベース３２０にアップロードされる（矢印４４４で示す）。例えば、製造資産Ａに対する変更された部品リスト及び在庫所要量は、部品表３００及び在庫所要量３０１を修正するために資産定義文書３３３から適切な位置にエクスポートされ得る。加えて、承認された在庫許可文書（図２に符号３４３で示す）からのデータは、矢印４４６で示すように企業資源計画データベース３２０の適切な部分にアップロードされ得る。例えば、企業資源計画データベースは、適切な職員が取得を「認めた」ことの評価などのパーツ承認プロセスに関するデータを含み得る。例えば、そのような情報は、パーツデータ３０６内に識別されている各パーツに含まれるかまたは関連付けられ得る。
【００７９】
一部の実施形態では、ひとたびデータが企業資源計画データベース３２０にアップロードされると、在庫許可文書、資産定義文書及び他の文書のバージョンは部品管理システムデータベース３１３にアーカイブされる。アーカイビングは、矢印４４０及び４４２で示されている。当然のことながら、資産定義文書、在庫許可文書及び他の部品管理システムデータは、他の期間、規則的な間隔及び／または不規則な間隔でアーカイブされ得る。
【００８０】
上記の例では概して１つの製造資産に対する設計変更の効果について述べたが、複数の資産にわたる複数の設計変更が部品管理システムによって追跡され得ることは明らかであろう。例えば、任意の所与の施設で、設計変更が当該施設に対するパーツ在庫所要量に多大な影響を与える可能性があるような、様々な時間軸にわたるプロジェクトに複数の設計者が取り組んでいることがある。各設計者、監督者及び／または他のキューは、複数の異なるプロジェクトに関する文書を含み得る。より大きなレベルでは、企業の全パーツ所要量（及びパーツ・ステータスに関する関連する金融上の義務及び規制義務）は、複数の異なる施設にわたって行われている変更を反映し得る。本発明に従う部品管理システムを用いることによって、企業は、工場レベル及び／または企業レベルで先を見越して部品を仕入れることを決定することができ得る。
【００８１】
例えば、一部の実施形態では、部品管理システムは、設計工程中のパーツ所要量への進行中の変更の追跡に基づいて、部品需要予測の作成をサポートする。例えば、１若しくは複数の資産定義文書が、所与の施設に関連付けられた複数のキューを通過する様々な段階に存在し得る。図２の例を用いると、例えば、第１の資産定義文書は、資産Ａを変更中の設計者のキューに存在し得る。資産Ｂの再設計に関連する変更は中間レベルにあり得るが、資産Ｃの設計への変更は、実施及び最終承認を受ける準備がほとんどできている状態であり得る。各々の一連の変更は、変更の発効日に基づいて施設の部品在庫の必要性に影響を与える場合がある。例えば、この例では資産Ａへの変更は初期段階で行われるが、それらの変更の発効日は、資産Ｃへの変更の発効日より早い時期であり得る。資産Ａへの設計変更は規制義務に関連する機械の再設計などの予期せぬ出来事に対応するが、資産Ｃへの設計変更は、例えば生産ラインにおける季節的変更への適応に対応し得る。それゆえ、施設のパーツ所要量全体が将来変更されることになるのみならず、変更のタイミングは程度の異なる反応を要求し得る。
【００８２】
従って、一部の実施形態では、部品管理システムは、現在のインストールベース（「現在」は予測日に相当する）、資産定義文書、資産定義文書に指定された設計変更の発効日を含むデータに基づき得る部品需要予測を作成することができる。例えば、一部の実施形態では、将来の１若しくは複数の時期における部品に対するインストールベースのシミュレーションを決定するために、定期的に、資産定義文書に指定された製造工程の部品所要量は、部品に対する現在のインストールベースなどの参照データと比較されることができる。
【００８３】
一例として、現在の機械の同一複製物をネットワークにつなぐなどの第１の設計変更によって、現在在庫のあるパーツの数が増加し得る。第２の設計変更によって、現在在庫のあるパーツの使用が中断され得、その一方で、第３の設計変更は、以前に在庫として持ったことのないパーツを導入し得る。管理者及び他の職員が部品需要予測を用いて、どのパーツを発注する必要があるか及びそのようなパーツを発注する日付を決定することができる。
【００８４】
例えば、予測は、（第２の設計変更が原因で）現在在庫のあるパーツが３０日経てばもはや使用されなくなることを示し得る。施設で毎日２個のパーツが使用され７０個のパーツ在庫があるならば、職員はそのパーツを発注する必要がないことを決定することができる。予測は、（第１の設計変更が原因で）現在在庫のあるパーツの数を２倍にする必要があることを示し得る。第１の設計変更の日付及び現在在庫のあるパーツのリードタイムによって、職員は様々な措置を講じる必要があり得る。一例として、標準配送を用いて必要数が利用できるように発効日が将来のずっと先の日であれば、パーツ管理者は緊急配送のために余計な出費が生じることを回避することができる。予測は、しかし、現在在庫のないパーツの使用発効日が、現在の日付から通常配送を用いて現在在庫のないパーツを入手するまでのリードタイム内にあることを示すことがある。すなわち、仮に標準配送を用いてパーツを発注したとしても、パーツが時間内に配送されることはないであろう。当然のことながら、パーツの性質にもよるが、速達配送が選択肢であり得、パーツ管理者は、速達配送を考慮するかあるいは潜在的な問題について前もって相手方に知らせるように警告され得る。
【００８５】
一部の実施形態では、上記の例で述べたような時間事項に基づいて異なる部品所要量が注釈を付けられるように、部品需要予測を作成することができる。例えば、スケジュール通りに変更を実施するために、予測文書が作成された日付から一定の日、週または月以内に或る部品が仕入れまたは発注される必要があるならば、部品はハイライトされ得る。例えば、予測文書の日付から１４日以内に部品が発注される必要があれば、部品は黄色でハイライトされ得る。別の例として、シミュレーションが、或る部品が部品在庫予測文書の作成日より前の日に発注されるべきであったが発注されていないことを示しているならば、その部品は赤色でハイライトされ得る。当然のことながら、他の色及び／またはタイプの注釈も用いられ得る。発注のタイミング、配送、リードタイムなどを決定するために用いられる情報は、例えばパーツのリードタイム及び／または推奨発注戦略を含み得る企業資源計画データセットに対するクエリを実行することによって、取得され得る。
【００８６】
ここで、図３ないし図８を参照して、例示的なプロセスステップについて説明する。以下の例では特定のステップが示されているが、ステップの順序を変えてもよいし、ステップをサブステップに分けたり組み合わせたりしてもよいし、特に断りのない限り、ステップの順序を変えることができ、かつ／または複数のステップを並行して行うことができる。そのようなステップは、１若しくは複数の部品管理システム・ソフトウェア・ツール、アプリケーション、プロセス、またはモジュールによって実行され得る。一部の実施形態では、幾つかのステップは部品管理システムを用いて実行され得るが、他のステップは、部品管理システムに関連付けられている他のシステムまたはアプリケーションを用いて実行される。当然ながら、本発明の実施形態を実施するために、任意の適切な計算装置が用いられ得る。さらに、計算装置は、ハードウェア、ソフトウェア、またはハードウェア及びソフトウェアの組合せによって機能するように適合され得る。
【００８７】
図３は、設計者キューなどのキューにおける例示的なワークフロー１０００内のステップを示すフローチャートである。ステップ１００２では、資産定義文書などの文書を取得する。例えば、部品管理システムは、プロジェクトにおける資産定義に基づいて１若しくは複数の資産定義文書を作成し得る。資産定義文書は、プロジェクトが定義されるときまたはそれより後のいつかなど、任意の適切な時点で作成され得る。例えば、或るプロジェクトが、初日に定義され得るが、もっと先の日まで作業が始まらないことがある。一部の実施形態では、資産定義文書は後日作成され得るか、あるいは先に作成されて後日更新され得る。他の実施形態では、資産定義文書は別のキューから取得され得る。例えば、ステップ１００２で得られた資産定義文書は、キューの設計者の管理者または監督者または他のユーザなどの別のユーザから受信した改訂または却下された資産定義文書を含み得る。いずれにせよ、資産定義文書は、その後、ステップ１００４で示すように設計者キューなどのプロジェクトに関連付けられている１若しくは複数のキューに置かれ得る。その後、ステップ１００６で設計データを受信する。
【００８８】
例えば、設計データは、製造資産において用いられるかまたは製造資産と併用される部品のリストへの変更、例えば部品の追加、削除及び／または置換などを含み得る。別の例として、設計データは、１若しくは複数の部品に対する在庫所要量の変更を含み得る。例えば、機械または他の資産が、作業または在庫計画の関係に基づいて、所与の部品がより多くまたは少なく在庫のある状態に維持される必要があるように再設計され得る。データは、任意の数または組合せの方法で受信され得る。例えば、設計者またはキューの他のユーザは、データをタイプするか、選択肢から選ぶか、または別な方法で入力するなどして、資産定義文書内の入力を手作業で変更し得る。別の例として、資産定義文書にインポートされるデータは、別のアプリケーションまたはハードウェアデバイスからエクスポートされ得る。
【００８９】
ステップ１００８では、受信データに基づいて、１若しくは複数の部品在庫所要量を更新する。例えば、資産定義文書がスプレッドシートとして維持されている実施形態では、更新されたスプレッドシートのバージョンが保存され得る。部品管理システムは、設計変更を追跡しかつデータ保持を提供するために、或る資産定義文書の１若しくは複数のバージョンまたはコピーを保存し得る。ステップ１０１２では、資産定義文書を次のキューにリリースする。例えば、キュー経路を定義するプロジェクトの一部として設計変更が生じているならば、資産定義文書を、プロジェクト定義データに記載のキューにリリースし得る。例えば、設計者は、１若しくは複数の監督者によるレビューのために資産定義文書をリリースし得る。しかし、次のキューは必ずしも明確に定義される必要がない。例えば、一部の実施形態では、設計者または他のユーザは、ドロップダウン・リストまたは他のリストからキューを選択することによって、かつ／またはキューまたはユーザ識別子を打ち込むことによって、次に文書を受信するキューを選択することができる。
【００９０】
上記の例では資産定義文書との関連でキューのワークフローについて考察したが、同じ動作原理を在庫許可文書に適用することができる。例えば、先ず、在庫許可文書が取得され得る。一例として、現在在庫のない部品に対する在庫所要量を追加する設計変更が検出されたら、部品管理システムによって１若しくは複数の在庫許可文書が作成され得る。現在在庫のない部品は、（以前に在庫を持ったことがないという点で）システムにとって全く新しい部品であり得るか、以前に在庫を持っていたが設計変更時に在庫のなかった部品であり得る。設計者または他のキューユーザは、好適なサプライヤ、発注時間、配送要求、在庫場所等を指定するなど、在庫許可文書にデータを入力することができる。部品がシステムにとって既知のものであれば、在庫許可文書に含まれるデータの一部が企業資源計画データセットから取得され得る。例えば、一部の実施形態では、部品管理システムは、その中にリストアップされた部品に基づくかまたはユーザからの入力（「インポート」命令など）に基づき、在庫許可文書の作成時に、自動的に在庫許可文書のためのデータをインポートするようサポートする。在庫許可文書は、その後、承認のために１若しくは複数の他のキューにリリースされ得る。一部の実施形態では、在庫許可文書の承認に関わるキューのうちの一部または全部が、資産定義文書の承認に関わるキューと重複し得るが、他の実施形態では、キュー経路は部分的にまたは完全にはっきりと異なり得る。
【００９１】
設計者（または他のキューユーザ）が在庫許可文書（または他の文書）を承認するとき、企業によって必要とされる承認の回付ルートを確立するために承認が追跡され得る。例えば、資産定義文書のバージョンを物理的に「認める」職員を要求するよりもむしろ、在庫許可文書及び／または他の文書、キューからの文書の承認またはリリースが物理的署名に相当するものとして扱われ得る。
【００９２】
図４は、監督者キューなどのキューにおける例示的なワークフロー１１００内のステップを示すフローチャートである。ステップ１１０２では、資産定義文書を監督者キューに置く。例えば、資産定義文書は、監督者に報告する１若しくは複数の設計者によってリリースされたものであり得る。別の例として、資産定義文書は、例えば改訂または変更確認のために、より高いレベルの経営管理者から監督者に戻されたものであり得る。ステップ１１０４及び１１０６では、プロセスは、設計データを受信しかつ資産定義文書中の１若しくは複数の部品在庫所要量を更新するステップを含む。これらのステップは、必ずしも常に行われるわけではないので破線の囲みで示してある。例えば、１若しくは複数の監督者が、受信した文書を単にレビューだけして、変更なしに文書を承認または却下することもある。別の考えとして、全ての監督者（または他のキューユーザ）が文書を変更する能力を有し得るわけではない。例えば、企業内での特定のユーザの役割及びユーザのキュー内の文書の種類によっては、ユーザは或る文書の一部または全部の変更を制限されることがある。一例として、一部の監督者ユーザは、部品を変更する権限はなく、資産定義文書に指定された仕入れのための部品の数を変更する権限のみに制限されることがある。そのような制限は、任意の適切な方法で実施され得る。例えば、文書は、文書がどのキューにあるかに基づいて決定されるユーザのＩＤ次第で、フィールド毎に（または他の基準で）許可をサポートし得る。別の例として、文書がどのキューに位置するかに基づいて、ある種の変更が部品管理システムによって却下されることがある。
【００９３】
ステップ１１０８では、文書が承認されるか否かを示すデータを受信する。文書は、承認されればステップ１１１０で次のキューに提供される。上記したように、宛先キューは、ユーザによって選択されるかまたは事前に決められ得る。ステップ１１１１では、文書は、承認されなければ前のキューに戻される。例えば、監督者は、資産定義文書または在庫許可文書を設計者に戻し得る。別の例として、監督者は、文書を、監督者と設計者の間に位置する中間ユーザキューに戻し得る。文書は、当初受信した状態のままで戻され得るか、あるいは監督者が変更を加えた状態で戻され得る。
【００９４】
図３に関して上記したように、在庫許可文書の処理にも同じ動作原理を適用することができる。すなわち、在庫許可文書の承認回付ルートにおける監督者は、必要に応じて在庫許可文書の内容を調整し、文書を承認または却下することができる。
【００９５】
図５は、最終承認権限を持つ監督者または他のユーザキューなどのプロセス１２００のキューでの例示的なワークフローを示すフローチャートである。ステップ１２０２では、資産定義文書はキューに置かれる。例えば、文書は、幾つかのキューを移動したかもしれず、この例の監督者キューは承認プロセスの最終局面を表す。ステップ１２０４では、文書が承認されるか否かを示す情報を受信する。この例では、監督者は文書の承認または却下に制限されているが、他の実施形態では、最終承認権限を持つ監督者もまた、企業構造によって、変更をなす制限付きかまたは完全な権限を有し得る。ステップ１２０７では、文書は、承認されなければ前のキューに戻される。文書は、変更のために発信元（設計者キューなど）または中間キュー（もしあれば）に戻され得る。
【００９６】
ステップ１２０６では、文書が承認されれば、資産に対する変更された部品在庫所要量（及び／または他のデータ）を反映するように企業資源計画データベースを更新する。たとえ部品管理システムが企業資源計画データセット（例えばＳＡＰまたは他のシステムからの１若しくは複数のイメージ）を用いるとしても、ひとたび承認が最終的に決定されると、「ライブ」データベースのイメージのみならずデータベースも更新し得る。イメージは、実施形態に応じて、更新されることもされないこともある。加えて、更新が最終承認時に生じ得るか、あるいは全ての最終承認がバッチ更新プロセスにおいてアップロードされ得る。
【００９７】
例えば、資産定義文書が承認されれば、必要な部品の変更をエクスポートして、企業資源計画システム内の部品表、部品在庫所要量及び他のデータを変更し得る。変更が緊急でなければ、更新には変更の発効日も含まれ得る。在庫許可文書が承認されれば、企業資源計画データベースの更新は、例えば任意の追加された部品データ（全く新しい部品に対するサプライヤ情報など）と、部品データの変更と、承認プロセス（例えば必要な職員による承認の証拠）が後に続いたことを示すデータとを含むことができる。一部の実施形態では、企業資源計画データベースが更新されるとき、資産定義文書、在庫許可文書及び設計変更に関連付けられている他のデータも、部品管理システムによって維持されているデータにアーカイブする。
【００９８】
図６は、企業資源計画システム・データセットの一部をイメージ化するための例示的なプロセス１３００におけるステップを示すフローチャートである。本明細書中の全ての例と同様に、示されている特定のステップ及びプロセスは例示のためだけのものである。この例では、その部分が１若しくは複数の進行中の設計プロジェクトの対象であるか否かに基づいて、企業資源計画システムがイメージ化される。先に述べたように、企業資源計画データセットの使用により、企業資源計画システムのための作業負荷及びシステム経費が削減され得る。ひとたび設計変更が最終的に決定されると、実際の企業資源計画システムが更新され得る。
【００９９】
ステップ１３０２では、部品管理システムは、オープンなプロジェクトを定義するデータにアクセスする。例えば、各プロジェクトは、どの製造資産が設計変更の対象であるかを示すデータを、例えば設計工程開始予定日によって決まる「アクティブ」ステータスとともに含み得る。ステップ１３０４では、システムは、どの資産データ項目がオープンなプロジェクトに関連付けられているかを決定する。例えば、或るプロジェクトにおける特定の製造資産が指定され得る。
【０１００】
ステップ１３０４では、システムは、企業資源計画システム内のどのデータ項目がオープンなプロジェクトに関連付けられているかを、１若しくは複数のプロジェクトの対象になることが決定された製造資産とデータ項目を関連付けることによって決定する。データ項目は、直接または間接的に識別され得る。部品表など一部のデータ項目に対して、資産は明確に識別され得る。例えば、プロジェクトが「製造資産Ａ」を識別するならば、対象となるデータ項目は、「製造資産Ａ」部品表、在庫所要量などを含み得る。具体的に識別されていないか特定の資産（パーツ毎に体系化されたパーツのサプライヤ及び発注データなど）と関連付けられていない他のデータ項目は、他のデータを相互参照することによって、オープンなプロジェクトと関連付けられているものとして決定され得る。例えば、「製造資産Ａ」部品表は、部品番号または他の識別子によって部品をリストアップし得る。リストアップされている部品のパーツ供給業者及び発注データは、部品表を相互参照することによって、進行中のプロジェクトに関連付けられているものとしてそれゆえ識別され得る。
【０１０１】
ステップ１３０６では、システムは、企業資源計画システムデータ項目の１若しくは複数のイメージにアクセスする。例えば、部品管理システムが企業資源計画システムデータの或る部分のイメージを既に維持しているならば、現在維持されているイメージはその「新しさ」が評価され得る。この例では、ステップ１３０８で各イメージ化されたデータ項目を評価する。ステップ１３１０に示すように、データ項目が進行中のプロジェクトに関連しているかまたは関連付けられているならば、データ項目のイメージは２４時間以上経過していれば更新される。ステップ１３１１に示すように、データ項目のイメージが進行中のプロジェクトに関連していないかまたは関連付けられていないならば、イメージを、３０日以上経過している場合に限り更新する。イメージを更新するためのベンチマークとして２４時間及び３０日を用いているが、これらは単なる例示の目的のためである。他の実施形態では、それよりも長いかまたは短い他の時間間隔が適していることもある。一部の実施形態では、データ項目イメージのイメージが全くないことは、イメージの「更新」の要求として扱われ得る。
【０１０２】
実際のイメージ化プロセスは、任意の適切な方法で実行され得る。例えば、一部の実施形態では、部品管理システムは、その現在のイメージ化されたデータ項目（もしあれば）を評価し、必要なデータ項目イメージのリストを決定する。その後、データ項目イメージは、企業資源計画システム使用レベルが低いとき、一括処理で（例えば毎晩）取得され得る。当然ながら、一括イメージ化の他の時間または間隔も適している。加えて、一括イメージ化は全ての実施形態で必要とされるわけではない。
【０１０３】
図７は、在庫許可文書を作成しかつ／または更新するための例示的なプロセス１４００におけるステップを示すフローチャートである。ステップ１４０２では、資産定義文書などの１若しくは複数の文書を、部品管理システムによってモニタしている。例えば、部品管理システムは、規則的または不規則に全ての進行中の資産定義文書にアクセスし、資産定義文書中の部品に関連付けられている状態インジケータをレビューし得る。代わりに、部品管理システムは、部品管理システムが特定の種類のアクティビティまたは資産定義文書への変更への注意を喚起されるような機能性のトリガをサポートし得る。以下のステップは、部品毎の在庫決定の評価に関するアクティビティを示す。評価された部品は、１つの資産定義文書に含まれ得るか、あるいは複数の資産定義文書に含まれ得る。
【０１０４】
ステップ１４０４では、システムは、１若しくは複数の部品に対して資産定義文書（図７において「ＡＤＤ」と表示されている）が「工場が在庫として持つ必要がある」ことを示しているか否かを決定する。例えば、資産定義文書内の部品への各入力は、或る工場が部品を在庫として持つ必要があるか否かを示すように設計者（または他のユーザ）が調整できるチェックボックスまたは他のインジケータを含み得る。この例では在庫決定が工場レベルでなされるが、在庫決定は企業の他のレベルに関連していることもある。チェックボックスは、部品に対して在庫許可文書が作成される必要があるか否かを決定するために、部品管理システムによって用いられ得る。例えば、上記したように、部品管理システムは、在庫許可文書を精査して、工場に在庫があるものとしてフラグが立っているのはどの部品かを判定し得る。別の例として、チェックボックス（または他のインジケータ）を選択することによって、部品及び仕入れステータスを識別するメッセージまたは他のトリガが、部品管理システムに提供され得る。
【０１０５】
ステップ１４０６では、部品が、工場が在庫として持つ必要があるものとして示されていなければ、プロセスは、資産定義文書内の次の部品（もしあれば）の評価及び／または他の資産定義文書内の部品の評価までプロセスのループを戻る。
【０１０６】
或る部品が在庫として持つ必要がある部品として示されていたら、ステップ１４０８でプロセスは次にその部品の在庫が既にあるか否かを評価する。例えば、企業資源計画データセットからのパーツデータ（または他のデータ）は、部品が工場に在庫があることを示す場合がある。部品の在庫が既にあれば、在庫許可文書は一部の実施形態では必要とされず、従ってこの例では作成されない。例えば、設計変更は在庫のある部品の数の調整を必要とし得るが、そのような調整は、変更に関連付けられている資産定義文書の承認プロセスにおいて処理され得る。
【０１０７】
しかし、パーツが現在在庫のない状態であれば、在庫許可の承認を必要とすることがあり、ステップ１４１０で在庫許可文書を作成または更新する。例えば、資産定義文書に関連付けられている１若しくは複数の在庫許可文書が既に存在し得る。例えば、設計者が、他の部品に対する在庫許可文書を手作業で準備し始めているかもしれない。一部の実施形態では、各在庫許可文書は資産定義文書に関連付けられているので、部品管理システムは在庫許可文書の内容を更新することができる。上記したように、在庫許可文書が作成されるのであれ更新されるのであれ、文書中のデータを企業資源計画データセットから得ることができる。例えば、在庫許可文書の必須の内容であるパーツの発注、供給、使用及び技術的情報を、作成（または更新）された文書に自動的に置くことができる。在庫許可文書の内容要件は、企業のポリシー及び手順によって異なることになる。ステップ１４１２では、在庫許可文書（図７においてＡＴＳと表示されている）を適切なキューに置く。
【０１０８】
ＡＴＳを受信するキューは異なり得る。例えば、資産定義文書が設計者キュー内にあれば、対応するＡＴＳも同様に設計者のキューに置かれ得る。しかし、設計変更は、異なるキューにおけるＡＴＳの更新をもたらし得る。例えば、第１の監督者は資産定義文書のレビューに関与し得るが、第２の監督者は資産定義文書に関連付けられている在庫許可文書のレビューに関与し得る。例えば、第１の監督者は、設計者によってリリースされたときに資産定義文書に存在しなかったパーツ所要量を追加し得る。設計者は、設計変更に関連付けられている在庫許可文書を既に第２の監督者にリリースしたかも知れない。部品管理システムは、現在存在する在庫許可文書を更新しかつそれを第２の監督者のキューに置き得る。一部の実施形態では、文書は、第１のユーザのキューから、別のユーザ及び／またはシステムによって、第１のユーザによるリリースの前の任意の時点で「引き戻」され得る。それゆえ、ＡＴＳ文書は、設計者に「引き戻」され得る。代わりに、当初実施された変更に在庫許可文書が関連付けられていなかったら、新たに作成された在庫許可文書は設計者のキューに置かれ得る。さらなる例として、第１の監督者は、現在在庫のないパーツに対する要求をなくすような資産定義文書への変更をなし得る。その場合、当該パーツに対する在庫許可文書は必要とされないであろう。それゆえ、現存する在庫許可文書が第２の監督者のキューから除去され得るか、あるいは、削除されたパーツに関連するその一部を除去するようにＡＴＳ文書が更新され得るであろう。
【０１０９】
図８は、部品需要予測文書を作成するための例示的なプロセス１５００を示すフローチャートである。この例では、特定の工場に対してインストールベース予測を作成し得る。しかし、部品需要予測は、企業の他のレベルに適用される場合もある。例えば、他の実施形態では、複数の工場または全企業的なインストールベース予測を、部品管理システムデータから直接的に、かつ／または複数の工場からのインストールベース予測を集計することによって、作成することができる。
【０１１０】
ステップ１５０２では、部品管理システムが、進行中の資産定義文書及び企業資源計画システム・データセットにアクセスする。ステップ１５０４では、進行中の資産定義文書に記載の部品所要量が現在存在する部品所要量と比較され、どちらの資産定義文書に変更が取り入れられたかと、その変更の程度とが判定される。例えば、各資産に対する部品所要量が、企業資源計画システムデータセットに記載の資産に対する部品所要量と比較され得る。別の例として、各資産定義文書に記載の各資産に対する部品所要量が、それぞれの資産定義文書の１若しくは複数の旧バージョンにおける所要量と比較され得る。ステップ１５０４では、各変更の発効日を決定する。例えば、資産定義文書は、各変更の実施日を指定し得る。別の例として、新たな部品在庫所要量の予期される承認日を決定するためにも在庫許可文書にアクセスし得る。
【０１１１】
ステップ１５０８では、現在のインストールベース、資産構造の決定された変更及び変更の発効日を含むデータに基づいて、将来のインストールベースの１若しくは複数のシミュレーションを作成する。この時点で、現在検討中の設計変更に基づいて１若しくは複数の将来の日付における所与の施設に対するパーツ所要量をリストアップしている報告書など、部品需要予測文書を作成することが可能である。「現在」は、報告書の作成時を意味するために用いられる。例えば、予測は、工場に現在在庫のある部品のリストを含み、かつ１若しくは複数の将来の日付において工場が在庫として持っている部品を含むことができる。一部の実施形態では、各部品毎に、予測は、各部品に対する現在の在庫所要量及び将来の在庫所要量を含む。仮想的予測文書の一部の簡略版を下表に示す。レイアウト、時間枠、パーツ識別子及び数は、説明のためだけのものである。
【表１】
2010535366.tif 000003
【０１１２】
インストールベース予測は、パーツ計画者に多くの有用な情報を提供し得る。例えば、上記の例では、パイプラインの設計変更は、僅かな増加は別として、パーツＷの所要量を著しくは変更しない。ツールＸは、パーツ管理向上の機会を表し得る興味深い事例を表している。「現在の」設計変更に基づいて、ツールＸは、報告日（「現在の日付」）から３０日後には工場では必要とされないことになる。しかし、現在の日付から９０日後、ツールＸは再び同じような量を必要とされることになる。それゆえ、短期の所要量は、ツールＸが必要ないことを示しているが、ツールＸの予備を売却または移転することは最適ではないかもしれない。例えば、ツールＸの再仕入れと比べて金銭的にかなり損をしてツールＸを捨てるしかないならば、工場は、有利には、将来再び仕入れる必要性を見越してツールＸの在庫の維持を決定し得る。
【０１１３】
サブアセンブリＹの事例は、別の著しい事例を表している。現在、工場はＹを６ユニットしか在庫を持たないが、たった１ヶ月で所要量は１１９ユニットの在庫を持つことになる。さらに、３ヶ月で所要量は３００ユニットになるであろう。予測に基づいて、パーツ計画者は、この著しい（この例では）変更を行う準備ができていることができる。他方では、パーツＺは３ヶ月必要とされないことになる。予期される使用及び発注時期などの他のデータに基づいて、工場は、報告から約９０日後にその在庫を使い果たすために、パーツＺをなくしてゆくプロセスを始めることができる。
【０１１４】
図８に戻り、一部の実施形態では、部品予測文書に追加ガイダンスを含めるためにさらなる措置を取ることができる。例えば、ステップ１５１０では、企業資源計画データセットにアクセスして、変更を行うための発注要件、配送要件及び／または他の要件を決定し得る。例えば、各パーツは、リードタイム及び配送時間などのデータを含み得る。このデータ（及び／または他のデータ）に基づいて、ステップ１５１２では、注釈付きの部品需要予測文書を作成し得る。例えば、予測文書は、配送時期を踏まえて変更の「重大性」に基づいてハイライトされ得る。例えば、パーツＸの追加は８ユニットしか要求されないが、パーツＸのリードタイムは２週間であることがある。それゆえ、８ユニットの追加のパーツＸを２週間以内に発注して、３０日後の予期される要求日までに確実に配送されるようにする必要があり得る（実際の発注はパーツＸの現在の計画されている配送及び使用率に基づいて異なることがある）。従って、パーツＸの入力は、ハイライトされるかまたは別な方法で注釈を付けられ得る。部品管理システムは、例えば、期限に間に合わせるために、パーツが２週間以内に発注されなければならないときに、そのようなパーツを予測文書中で黄色でハイライトするように構成され得る。
【０１１５】
異なるグレードのハイライト表示または他の注釈が可能である。例えば、現在の日付が既にパーツのリードタイム内に入っている場合、パーツは赤色でハイライトされ得る。例えば、パーツＹに６０日間のリードタイムがありかつ在庫切れであれば、パーツＹを発注する時期が過ぎてしまったことを示すためにパーツＹは赤色でハイライトされ得る。パーツ計画者は、それによって、発注／配送を早めるか、代替または追加のサプライヤと連絡を取るか、変更の実施を遅らせるなどの追加的行動を取る必要があることを警告され得る。
【０１１６】
一部の実施形態では、部品在庫予測文書の作成を、資産定義文書及び／または在庫許可文書への変更によってトリガすることができる。加えて、既存の部品在庫予測文書を、変更に基づいて更新することができる。トリガは、設計者または他の職員からの或る入力への応答として、及び／または規則的または不規則な間隔での部品管理システム内の文書のモニタリングへの応答として、実施し得る。一部の実施形態では、新たな部品需要予測文書が毎晩作成される。
【０１１７】
図９は、部品管理システムにおける例示的な構造及びデータフローを示すフローチャートである。この例では、複数のキュー間での文書承認及びフローを説明することにする。この例では、資産定義文書は、第１のキュー１１０、第２のキュー１１１、第３のキュー１１２、第４のキュー１１４、第５のキュー１１５を通過し、第６のキュー１１６で最終承認されなければならない。在庫許可文書は、第１のキュー１１０を発端として、その後、第７のキュー１３０、第３のキュー１１２（これはそれゆえ資産定義及び在庫許可の承認プロセスにおいて役割を有する）、第８のキュー１３２、第９のキュー１３４、第１０のキュー１３５を通過し、第１１のキュー１３８で最終承認される。この例では、第１２のキュー１４０も示されている。第１２のキュー１４０は、承認プロセスに関与していないが、部品予測文書１４２を受信する。例えば、キュー１１０、１１１、１３０及び１３０のユーザは、施設レベルでの部品管理の計画及び実行の担当者を表し得る。キュー１４０、１３２、１１４、１３４、１１５、１３５、１１６及び１３８のユーザは、部門及び／または企業レベルでの部品管理に関与するユーザを表し得る。上記したように、特定のキュー構造は、部品所要量及び在庫決定の実施、追跡及び承認に関しての企業のポリシー及び嗜好によって決まることになる。
【０１１８】
この例では、資産定義文書及び対応する在庫許可文書は、図９に示す複数のキューを実質的に並行して通過することができ、図９では、資産定義文書の承認に関連するキューを左側に、在庫許可文書の承認に関連するキューを右側に示している。一方の文書が他方に比べて承認回付ルートの先まで進みすぎないことを確実にするために、部品管理システムは、一方または他方の文書の進展を制限するように構成され得る。例えば、キュー１１１から資産定義文書がリリースされ得るが、対応する在庫許可文書が並行キュー１３０からリリースされ終わるまで次のキューに現れないことがある。そのような同期は、一部の実施形態では好ましいが、必須ではない。
【０１１９】
この例では、資産定義文書（ＡＤＤ）１００はキュー１１０に置かれ、キュー１１０は設計者キューを含み得る。矢印２００で示すように、設計者は、部品在庫所要量の変更を表すデータを追加し得る。この例では、データの追加が２つの文書の作成（または更新）をトリガする。例えば、矢印２００で与えられるデータが、以前に在庫として持ったことのないパーツの追加を表していれば、矢印２５０で示されるように、在庫許可文書（ＡＴＳ）１２０を作成（または更新）する。在庫許可文書１２０はキュー１１０に置く。矢印２５６ａ及び２５６ｂで示すように、矢印２００で与えられたデータによって、部品需要予測文書、この例では、インストールベース予測１４２の作成または更新をトリガすることができる。例えば、部品管理システムは、在庫として持つ（かつ／または現在在庫のない部品を追加する）必要がある特定部品の個数を設計者が変更したことを判定し得る。図９の例示的な管理構造では、キュー１１１及び１４０のユーザは各々、インストールベース予測１４２のコピーを受信する。
【０１２０】
矢印２１２で示されているように、ひとたびキュー１１０のユーザがＡＤＤ１００に満足したら、ＡＤＤ１００は、矢印２１２で示すように次のキューすなわちキュー１１１にリリースされ得る。キュー１１１におけるＡＤＤのバージョンは、明確にするためにＡＤＤ１０１と表示されている。少なくとも受信されるとき、ＡＤＤ１０１はＡＤＤ１００と同じデータを含み得ることを理解されたい。２０２では、キュー１１１のユーザはデータを追加し得る。例えば、ユーザは、受信されたときにＡＤＤにおいて指定された部品在庫所要量への追加、削除または変更を指定し得る。矢印２５８及び２６０で示すように、そのような変更は、インストールベース予測文書１４２の更新または作成をもたらし得る。矢印２５２で示すように、変更は、加えて、または代わりに、キュー１３０内の対応する在庫許可文書２５２の更新をもたらし得る。キュー１１１のユーザは、当初受信したままかまたは修正したＡＤＤ１０１をリリースし得るか、あるいは（受信したままかまたは修正した）ＡＤＤ１００を却下して矢印２２４で示すようにＡＤＤをキュー１１０に戻し得る。例えば、ＡＤＤは、キュー１１１のユーザによってなされる変更の改訂及び／または承認に戻され得る。
【０１２１】
在庫許可文書１２０に戻ると、キュー１１０のユーザは、矢印２２６で示すように文書をリリースし得る。ユーザはまた、データ２０１を入力することによって別のＡＴＳ文書１２１を手作業で準備していたかも知れない。ＡＴＳ文書１２１を、同様に矢印２２８で示すように次のキューにリリースし得る。この例では、ＡＤＤ１００に関連付けられている全てのＡＴＳ文書が、図９において符号１２２で表示されている１つのＡＴＳに統合される。この例では、キュー１１０の後のＡＴＳ目的のための次のキューはキュー１３０である。キュー１３０のユーザは、矢印２０６で示されるようなデータを加えることによってＡＴＳ１２２に変更を加え得る。上記したように、矢印２５２を参照して、対応するＡＤＤ１０１への変更によって、ＡＴＳ１２２を更新し得る。キュー１３０のユーザは、矢印２４２で示すようにＡＴＳ文書１２２を却下するか、あるいは矢印２３０で示すように次のレベルでの検討のために当該文書を承認し得る。
【０１２２】
この例では、キュー１１２は、資産定義文書及び在庫許可文書の両方を受信する。説明のために、それぞれＡＤＤ１０２及びＡＴＳ１２４として示す。上記したように、この例で示されているＡＴＳ及びＡＤＤの番号の付け方は、明確にするためだけのものである。例えば、ＡＤＤ及び／またはＡＴＳ文書は、キュー１１０から始まり、何ら変更されることなく全てのキューを通過し得る。それゆえ、異なる番号の付け方は、各キューに対して別バージョンが必要とされることを示すことを意図しているのではない。むしろ、変更がなされるか否かに基づいて別バージョンが作られ得る。
【０１２３】
キュー１１２のユーザは、それぞれ矢印２０４及び２０８によって示される文書の一方または両方にデータを追加し得る。上記したように、一部のユーザは、変更することができる範囲に関して制限され得る。例えば、キュー１１２は、どのパーツを用いるかに関する技術的な決定ではなくパーツの量及び仕入れ手順において変更を加えることを制限されているような工場のパーツ監督者によってアクセスされ得る。ＡＤＤ１０２及び／またはＡＴＳ１２４は、矢印２１６及び２３２で示すようにさらなる検討のために承認され得る。代わりに、一方または両方が却下されて、矢印２２２及び２３８で示すようにそれぞれの以前のキューに戻され得る。
【０１２４】
キュー１１４及び１１５は、資産定義文書１０２に対する中間承認レベルを示し得る。例えば、キュー１１４のユーザは、工場全体に及ぶ部品在庫所要量の決定を調整し得るが、キュー１１５のユーザは、部門を通じて部品在庫所要量の調整を保証する。承認を矢印２１８及び２２０で示し、却下を矢印２２２で示す。ＡＤＤ１０２はこの例ではキュー１１１より上位のレベルで却下されればキュー１１１に戻されるが、ＡＤＤ１０２は、却下によって任意の前のレベルに戻され得る。
【０１２５】
キュー１１６は、部品所要量の変更に対して最終決定権を持つ管理者に用いられ得る。例えば、ＡＤＤ１０２内の変更がキュー１１６で承認されると、変更を、矢印２４４で示すように企業資源計画システムデータストア２０にアップロードし得る。変更を、部品管理システムデータストア１３にアーカイブすることもできる。
【０１２６】
ＡＴＳ１２４に戻ると、キュー１１２のユーザは、文書を次のキュー（この例ではキュー１３２である）にリリースする。キュー１３２のユーザは、ＡＴＳ１２４を承認または却下し得る。この例では、２つの異なる承認経路２３４ａ及び２３４ｂが示されている。例えば、在庫許可文書が、指定された金額（または他の費用）の閾値以上の在庫決定に関わっているならば、企業はキュー１３４のユーザの承認を要求し得る。キュー１３４のユーザは、矢印２３５で示すようにＡＴＳ１２４を承認するか、あるいは矢印２４０で示すようにＡＴＳ１２４を却下し得る。この例では、キュー１３０より上位のキューからのＡＴＳ１２４の却下は全てＡＴＳ１２４をキュー１３０に戻す。尤も、文書を他の中間キューに戻すこともできる。しかし、ＡＴＳ１２４が閾値以下の在庫決定に関わっているならば、矢印２３４ａで示すように、キュー１３４を迂回させ得る。キュー１３５は最終中間レベルを示し、承認を矢印２３６で、却下を矢印２３８で示す。
【０１２７】
キュー１３８は、在庫許可の決定の最終決定権を持つ管理者によって用いられ得る。矢印２１０で示すように、この例では、管理者は、在庫許可文書（明確にするためにＡＴＳ１２６として示されている）に変更を加えることができる。矢印２４８で示すようにひとたび承認されると、在庫許可データを企業資源計画データベース２０にアップロードする。例えば、企業資源データベース２０は、キュー１１０、１３０、１３２等の各ユーザが文書を電子的に「認めた」ことを示すデータによって証明され得るような承認回付ルートの追跡をサポートし得る。別の例として、システムに新たなパーツが追加されると、承認プロセス中に回収されたパーツデータが自動的に企業資源計画システムにアップロードされることができる。これは、以前は単調で退屈だったプロセスを自動化し得る。というのも、特定の企業資源計画システムのアーキテクチャ及び構成により、パーツデータは複数の異なる位置に指定され得るためである。最終的に決定されたＡＤＤの場合と同様に、ＡＴＳデータも部品管理システムデータベース１３にアーカイブされ得る。
【０１２８】
上記の例は説明のためだけのものであり、限定的なものではないことを理解されたい。例えば、キューのための役割及び識別子は、特定のプロジェクト、企業及び他の状況によって異なることができ、部品管理システムがどのように構成されているかによって固定または可変であり得る。例えば、「設計者キュー」、「監督者キュー」などの指示子は、可能なタイプまたは数のキューまたはユーザを制限することを意味するものではない。加えて、各キューは、１若しくは複数のユーザによってアクセスされ得る。さらに、任意のデータ構造またはフォーマットを用いて、キューの内容を管理、レンダリング及び調整し得る。
【０１２９】
本明細書の例で述べたような部品管理システム及び方法は、任意の適切な状況で用いられ得る。例えば、部品管理システム及び／または方法の一部の実施形態が単独で用いられ得る。部品管理システム及び／または方法の他の実施形態は、パーツ計画、管理などの他の態様に対応する他のシステム及び／または方法と一緒にかつ／またはその一部として用いられることができる。例えば、特許文献１には、様々な例示的な態様のスペアパーツ管理に関する考察が記載されている。特許文献１は、全文を引用することを以て本明細書の一部となす。
【０１３０】
上記の例は、サーバ、データベース、ソフトウェア・アプリケーション及び他のコンピュータベースのシステム及び装置、並びに講じられる措置及びそのようなシステムと送受信される情報に言及している。部品間のタスク及び機能性の任意の可能な構成、組合せ及び分割は、それらが適していれば、用いられ得る。例えば、クライアント／サーバ・アーキテクチャが用いられるのであれば、当該アーキテクチャは、組み合わせて働きかつ１若しくは複数のクライアントと通信することができる単一のサーバまたは複数のサーバを用いて実装されることができる。データベース及びアプリケーションは、１つのシステムに実装されるかあるいは複数のシステムに分散され得る。分散型部品は、連続適に、または並行して作動し得る。
【０１３１】
第１と第２のコンピュータシステムまたはその部品間でデータが獲得またはアクセスされるとき、実際のデータはシステム間を直接または間接的に移動し得る。例えば、第１のコンピュータが、第２のコンピュータからのファイルまたはデータにアクセスするならば、アクセスには、１若しくは複数の中間コンピュータ、プロキシなどが含まれ得る。実際のファイルまたはデータがコンピュータ間を移動し得るか、あるいは、１つのコンピュータが、例えば第１のコンピュータ以外のコンピュータからの実際のデータにアクセスするために第２のコンピュータが用いるポインタまたはメタファイルを提供し得る。
【０１３２】
ネットワーク通信はまた、限定するものではないが、ダイヤルイン・ネットワーク、ローカルエリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、公衆交換電話網（ＰＳＴＮ）、インターネット、イントラネットまたは他のタイプのネットワークを含む任意の適切なネットワークでなされ得る。ネットワークは、任意の数及び／または組合せの有線、無線または他の通信リンクを含み得る。本明細書に記載の種々のコンピュータシステム／計算装置は、特定のハードウェア・アーキテクチャまたは構成に限定されない。任意の適切なプログラミング言語、スクリプト言語または他の種類の言語または言語の組合せが用いられ得る。本明細書に記載の方法及びシステムの実施形態は、コンピュータ読み取り可能形式でレンダリングされたソフトウェア命令にアクセスする１若しくは複数の汎用または専用の計算装置によって実施され得る。本明細書に記載の方法及びシステムの実施形態はまた、限定されるものではないがアプリケーション固有の回路を含む配線論理または他の回路によって実施され得る。当然ながら、コンピュータで実行されるソフトウェアと配線論理の組合せも同様に適切であり得る。
【０１３３】
本明細書において開示されている発明の対象を実施または実行するために、ディスケット、ドライブ及び他の磁気ベースの記憶媒体、ディスク（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ及びそれらの変形形態を含む）、フラッシュメモリ、ＲＡＭ、ＲＯＭ及び他のメモリ装置を含む光記憶媒体などを含めて任意の適切なコンピュータ読み取り可能媒体が用いられ得る。
【０１３４】
本開示の少なくとも１つの好適実施形態について具体例を用いて説明してきたが、そのような説明は、例示のためだけのものであり、本発明の趣旨または特許請求の範囲から逸脱することなく変更及び変形がなされ得ることを理解されたい。
【図１】
2010535366.tif 000004
【図２】
2010535366.tif 000005
【図３】
2010535366.tif 000006
【図４】
2010535366.tif 000007
【図５】
2010535366.tif 000008
【図６】
2010535366.tif 000009
【図７】
2010535366.tif 000010
【図８】
2010535366.tif 000011
【図９】
2010535366.tif 000012