JP3654812B2 - 部品供給管理システムにおける表示方法及び管理方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、部品供給を受ける会社（ユーザ）と部品製造を行う会社（サプライヤ）とを密接に結び付け、必要な時期に、必要な部品を過不足なく供給ならびに購入するための部品供給管理システムの表示方法等に関するものであり、特に、ユーザとサプライヤとがとりうる最適な方法を決定するためのシュミレーションの方法とシュミレーションを行うための情報ならびにシュミレーション結果の表示方法に関するものである。
【０００２】
【従来の技術】
ユーザは、複数のサプライヤから部品を購入し、それらの部品を組み立てて、最終製品等として出荷している。通常サプライヤは、多種多用の部品を扱っているため、常に全ての種類の部品を大量に在庫しているわけではない。しかしながら、ユーザからは、特定の部品について、出来るだけ短い納期で希望する量の納品を行うよう要望されている。
【０００３】
そこで、サプライヤは、ユーザから部品使用予測情報（フォーキャスト）を受取り、そのフォーキャストに基づいて、ユーザが必要な部品を予め製造し、ユーザの近くの集積地（ストックポイント）まで輸送して保管していた。これによって、ユーザから、例えば、明日中に所定の部品を所定数量納品してほしい旨の発注を受けても、速やかにユーザの希望通りの納品を行えるように準備していた。
【０００４】
しかしながら、最近の市場動向の移り変わりの速さを反映し、人気のある製品の出荷予定数が大幅に増加し、その反面、人気の無い製品の出荷予定が大幅に減少することがある。したがって、ユーザはフォーキャスト通りにサプライヤに部品の注文を行うとは限らず、さらにフォーキャストと実際の部品の注文との間に大きな差が生ずる場合もあった。
【０００５】
フォーキャストの方が実際の発注より大きい場合、サプライヤが過剰な量の部品を在庫として保管することが必要となり、逆に、フォーキャストの方が実際の発注より小さい場合、ユーザが希望する量の部品を納品することが出来ないという不具合が生じることとなる。
また、ストックポイントに保管されている部品の在庫は、必ずしも１回分の納品数量分だけが保管されている訳ではないが、例えば急に注文された部品量が増えた場合、その時に納品する量は確保できるが、次回又は次々回になって、その時の歪みによって納品すべき量が不足する場合もあった。このような場合に、納品すべき部品が不足したのは、ユーザ側のフォーキャストを越えた発注が原因なのか、それともサプライヤが部品の輸送等を怠ったからなのかが明確ではなかった。そして、いずれの場合も、サプライヤ（弱者）の責任と費用負担で問題が解決されていた。
【０００６】
【発明が解決しようとする課題】
本発明の目的は、このような従来例が有する欠点を補ったものであり、ユーザとサプライヤ間の情報のやり取りを密にして、臨機応変に対応可能な部品供給システムの表示方法等を提供しようとするものである。
また、本発明の目的は、ネットワークを利用した部品供給システムの表示方法等を提供しようとするものである。
【０００７】
さらに、本発明の目的は、ユーザとサプライヤの責任分担を明確にした部品供給システムの表示方法等を提供しようとするものである。
さらに、本発明の目的は、ユーザとサプライヤとがとりうる最適な方法を決定するためのシュミレーションの方法とシュミレーションを行うための情報ならびにシュミレーションの結果の情報等の表示方法を提供しようとするものである。
【０００８】
【課題を解決するための手段】
上記課題を解決するために、本発明に従った部品供給管理システムにおける表示方法は、記憶部及び処理部を含むサプライヤ側端末、ユーザ側端末、及びそれらが接続されるネットワークによって構成され、ユーザ側端末は前記ネットワークを介して部品使用予測情報及び注文情報を送信し、サプライヤ側端末における前記処理部は、部品使用予測情報及び前記注文情報を受信し、部品使用予測情報及び注文情報を前記記憶部に記憶し、部品使用予測情報に基づいて部品の発注輸送を開始するための発注情報を求め、部品使用予測情報又は注文情報に基づいて在庫予測情報を求め、部品使用予測情報及び在庫予測情報に基づいて部品の補充輸送を開始するための補充情報を求め、発注情報、在庫予測情報及び補充情報を含む表示画面を作成し、ネットワークを介して前記表示画面を送信する。
【０００９】
また、発注情報は、サプライヤからユーザへの部品の供給に必要な期間以上の第１の期間における部品使用予測情報に基づいて決定され、補充情報は、前記第１の期間より短い第２の期間における部品使用予測情報及び在庫予測情報に基づいて決定されることが好ましい。
さらに、処理部は、注文情報と在庫予測情報を比較し、在庫予測情報が注文情報に満たない場合には、表示画面に警告表示を行うようにすることが好ましい。
【００１０】
さらに、処理部は、部品使用予測情報に基づいてサプライヤがユーザに対して納品を約束する部品量に対応した納品約束数情報及びサプライヤがユーザに対して在庫として保管することを約束する部品量に対応した在庫約束数情報を求めて、表示画面に表示することが好ましい。
さらに、処理部は、納品約束数情報及び注文情報に基づいて、ユーザ側の注文の状況を表す過剰使用数情報を求めて、表示画面に表示することが好ましい。
【００１１】
さらに、処理部は、発注情報及び補充情報に基づいて、サプライヤ側の部品供給状況を示す情報を求めて、表示画面に表示することが好ましい。
さらに、サプライヤ側の処理部は、ユーザ側端末からネットワークを介して送信される緊急輸送情報を受信し、緊急輸送情報に基づいて、在庫予測情報の変更を行うようにすることが好ましい。
【００１２】
さらに、緊急輸送情報は、輸送方法に関する情報を含むことが好ましい。
また、上記課題を解決するために、本発明に従った部品供給管理システムにおける表示方法は、記憶部及び処理部を含むサプライヤ側端末、ユーザ側端末およびネットワークから構成される部品供給システムを有し、サプライヤ側端末における処理部は、ユーザ側端末から受信した部品使用予測情報及び注文情報を前記記憶部に記憶し、部品使用予測情報に基づいて部品の発注輸送を開始するための発注情報を求め、部品使用予測情報又は注文情報に基づいて在庫予測情報を求め、部品使用予測情報及び在庫予測情報に基づいて部品の補充輸送を開始するための補充情報を求め、表示画面を作成するために発注情報、在庫予測情報及び補充情報をネットワークを介して前記ユーザ側端末に送信する。
【００１３】
さらに、処理部は、部品使用予測情報に基づいてサプライヤがユーザに対して納品を約束する部品量に対応した納品約束数情報及びサプライヤがユーザに対して在庫として保管することを約束する部品量に対応した在庫約束数情報を求めて、ネットワークを介してユーザ側端末に送信することが好ましい。
さらに、処理部は、納品約束数情報及び注文情報に基づいて、ユーザ側の注文の状況を表す過剰使用数情報を求めて、ネットワークを介してユーザ側端末に送信することが好ましい。
【００１４】
さらに、処理部は、発注情報及び補充情報に基づいて、サプライヤ側の部品供給状況を示す情報を求めて、ネットワークを介してユーザ側端末に送信することが好ましい。
また、上記課題を解決するために、本発明に従った部品供給システムにおける管理方法は、サプライヤ側端末における処理部が、ユーザ側端末から受信した部品使用予測情報及び注文情報を記憶部に記憶し、部品使用予測情報に基づいて部品の発注輸送を開始するための発注情報を求め、部品使用予測情報又は注文情報に基づいて在庫予測情報を求め、部品使用予測情報及び在庫予測情報に基づいて部品の補充輸送を開始するための補充情報を求め、発注情報、在庫予測情報及び補充情報をネットワークを介してユーザ側端末に送信する。
【００１５】
【発明の実施の形態】
図１は、本発明による部品供給システムの一実施形態を示したシステム図である。図１を用いて、本システムの概要について説明する。本システムは、インターネットや特殊回線等の各種のネットワーク１に接続された、サプライヤ側端末１０及びユーザ側端末２０から構成される。
【００１６】
サプライヤ側端末１０は、サプライヤ側サーバ１１と各種の表示を行う表示部１５から構成されており、サプライヤ側サーバ１１は、各種データの送受信及び各種の処理を行う処理部１２、各種データの記憶を行うための主記憶部１３および各種データの入力や各種操作入力を行うための入力部１４から構成されている。同様に、ユーザ側端末２０は、ユーザ側サーバ２１及び表示部２５から構成され、ユーザ側サーバ２１は、処理部２２、主記憶部２３及び入力部２４から構成されている。
【００１７】
サプライヤは、電子部品等を製造し、製造した電子部品をユーザの所在地の近傍に位置するストックポイント（倉庫等）に一時的に保管して、ユーザからの注文があった場合に速やかに納品できるように準備している。
なお、ストックポイントに端末をおいて、その端末からストックポイントにおける部品の入庫情報等をネットワークを介して送信するようにすることも可能である。
【００１８】
図２は、部品供給システムの全体処理フローを示す図である。以下に、図２を用いて、本システムの全体の処理フローについて説明する。
まず、ユーザはユーザ側端末２０の入力部２４を用いて「フォーキャスト」データ、「確定注文」データ又は「緊急輸送情報」データを入力し、処理部２２を用いネットワーク１を介してサプライヤ側に送信する（ステップ２０１）。各種データの詳細については後述する。
【００１９】
次に、サプライヤ側端末１０は、ネットワーク１と接続された処理部１２を用いて、ユーザ側からの「フォーキャスト」データ、「確定注文」データ、又は「緊急輸送情報」データを受信する（ステップ２０２）。
次に、サプライヤ側端末１０の処理部１２は、受信した「フォーキャスト」データ、「確定注文」データ及び「緊急輸送情報」データを、それぞれ記憶部１３に記憶する（ステップ２０３）。
【００２０】
次に、サプライヤ側端末１０の処理部１２は、予め主記憶部１３に記憶されている事前設定パラメータ及び前述した各種受信データに基づき、「出荷約束在庫数」データ、「出荷準備在庫数」データ、「過剰使用数累計」データ、「不足数累計」データ、「出荷約束数」データ、「納品指示」データ、「発注数」データ、「入庫予定発注数」データ、「補充数」データ、「入庫予定補充数」データ、及び「入庫予定緊急輸送数」データを演算により求める（ステップ２０４）。事前設定パラメータ及び各種演算データの詳細については後述する。
【００２１】
次に、各種演算データをサプライヤ側主記憶部１３に記憶する（ステップ２０５）。
次に、「確定注文」データに応じた「納品指示」データをストックポイントへ送信する（ステップ２０６）。この「納品指示」データに応じて、ストックポイントに一時保管されている電子部品等がユーザに納品されることとなる。
【００２２】
次に、サプライヤ側端末１０の処理部１２は、各種受信データ及び各種演算データに基づいて、納品状況画面を作成する（ステップ２０７）。納品状況画面の詳細については後述する。
次に、サプライヤ側端末１０の処理部１２は、ネットワーク１を介して、作成した納品状況画面をユーザ側に送信する（ステップ２０８）。
【００２３】
次に、ユーザ側端末２０の処理部２２は、納品状況画面を受信し（ステップ２０９）、表示部２５等に表示を行い、ユーザ側に詳細な部品納品管理に関する現状をレポートすることとなる。この様にして受信された納品状況画面を確認しながら、ユーザは、さらに次回以降の「フォーキャスト」データ、「確定注文」データ、及び「緊急輸送情報」データ等を送信することとなり、以後、同様のステップが繰り返される。
【００２４】
なお、図２のフローにおいては、サプライヤ側端末から納品状況画面が作成されてユーザ側端末に送信されたが、サプライヤ側端末から所定のデータのみが送信され、ユーザ側端末に予め記憶されている所定のソフトウエアにしたがってユーザ側端末で所定の画面が構成されるようにしても良い。
図３には、「フォーキャスト」データの一実施形態が示されている。図３を用いて、以下に「フォーキャスト」データについて説明する。図示されるように、「フォーキャスト」データは、フォーキャストの発行日データ３０１、納品予定データ３０２及びフォーキャストデータ３０３から構成される。ここでは、ユーザは１９９９年第３６週の時点において、第４２週に１００ユニット、第４３週に１００ユニット、第４４週に１００ユニット、第４５週に６０ユニット、第４６週に５０ユニット、第４７週に５０ユニット、第４８週に５０ユニット、及び第４９週に５０ユニットの注文を予測しているというデータ構成となっている。なお、図３では、１９９９年の第４２週から第４９週までの８週分についてのデータが記載されているが、８週間分に限られることなく、任意の期間についてのデータを添付することが可能である。また、図３では、納品予定データは、週単位のデータとなっているが、状況に応じて、日単位、月単位又は任意の期間を基準とすることも可能である。さらに、図３において、フォーキャストデータは、ユニット単位となっているが、個々の部品の実際の個数を用いること等も可能である。
【００２５】
図４には、「確定注文」データの一実施形態が示されている。図４を用いて、以下「確定注文」データについて説明する。図示されるように、「確定注文」データは、確定注文の発行日データ４０１、納品予定データ４０２及び注文データ４０３から構成される。ここでは、ユーザは１９９９年の第４２週の時点において、第４３週に１５０ユニット及び第４４週に１８０ユニットの確定した注文を正式に依頼しているというデータ構成となっている。なお、図４では、１９９９年の第４３週及び第４４週の２週分についてのデータが記載されているが、２週間分に限られることなく、任意の期間についてのデータを添付するすることが可能である。また、図４では、納品予定データは、週単位のデータとなっているが、状況に応じて、日単位、月単位又は任意の期間を基準とすることも可能である。さらに、図４において、注文データは、ユニット単位となっているが、個々の部品の実際の個数を用いること等も可能である。
【００２６】
図５には、「緊急輸送情報」データの一実施形態が示されている。図５を用いて、「緊急輸送情報」データについて説明する。図示されるように、「緊急輸送情報」データは、緊急輸送情報の発行日データ５０１、納品予定データ５０２、輸送データ５０３及び輸送方法データ５０４から構成される。ここでは、ユーザは１９９９年の第４２の時点において、第４３週にストックポイントに入庫するように、１０ユニットを航空便で依頼するというデータ構成となっている。なお、図５では、１９９９年の第４３週の１週分についてのデータが記載されているが、１週間分に限られることなく、任意の期間についてのデータを添付することが可能である。また、図５では、納品予定データは、週単位のデータとなっているが、状況に応じて、日単位、月単位又は任意の期間を基準とすることも可能である。さらに、図５において、輸送データ５０３は、ユニット単位となっているが、個々の部品の実際の個数を用いること等も可能である。また輸送方法データとしては、他に船便、トラック便にがあり、それぞれに輸送方法を指定することが可能となっている。
【００２７】
次に、各種事前設定パラメータについて説明する。各種事前設定パラメータは、主記憶部１２に記憶されており、「決定期間」データ、「在庫期間」データ、「製造期間」データ、「所要期間」データ及び「納品期間」データを含んでいる。
まず、「決定期間」データとは、後述する「発注数」等を決定するタイミングを定めるためのパラメータをいう。「在庫期間」データとは、「出荷約束在庫数」データを決定するために用いられるパラメータをいう。「製造期間」データとは、対象となっている電子部品の製造に必要な期間に関するパラメータをいう。「所要期間」データとは、サプライヤからストックポイントまで電子部品を輸送するのに必要な期間に関するパラメータをいい、後述する「補充数」等を決定するタイミングを定めるためにも使用できる。「納品期間」データとは、ストックポイントからユーザまでの納品に必要な期間に関するパラメータをいう。
【００２８】
以後の説明では、「決定期間」データは６週間に、「在庫期間」データは４週間に、「製造期間」データは２週間に、「所要期間」データは３週間に、及び「納品期間」データは０週間に事前に設定されているものとする。なお、「決定期間」データは、部品の発注のタイミングを定めるものであるので、「製造期間」データ＋「所要期間」データ以上の期間であることが望ましい。また、これらのパラメータは状況等に応じで自由に設定することができるものであって、これらの数値に限定されるものではない。
【００２９】
次に、各種演算データについて説明する。
「出荷約束数」は、「決定期間」データに該当する週に（例えば、現時点が１９９９年第３６週で「決定期間」データが６週間とすれば、第４２週に）、その時点でサプライヤ側がユーザに対して出荷を約束した電子部品の数量に関するデータである。また、「出荷約束在庫数」は、サプライヤが、「決定期間」データに該当する週の始めの時点に、「在庫期間」データに相当する分（ここでは４週間分）の数量をストックポイントに入庫することを約束した数量に関するデータである。また、「発注数」は、ユーザへ納品するために、製造の開始等を指示する電子部品の数量に関するデータである。また、「入庫予定発注数」は、発注された電子部品が何時ストックポイントに入庫されるかに関するデータであって、「製造期間」データ及び「所要期間」データに基づいて求められる。
【００３０】
「出荷準備在庫数」は、その週の初めの時点で実際にストックポイントに在庫されている電子部品の数量に関するデータ、又はシュミレーションによってその週の始めに在庫されていることが予想される電子部品の数量に関するデータである。なお、後者の場合には、カッコ付きで表示される。また、「補充数」は、所定の場合に、補充的に製造の開始等を指示する電子部品の数量に関するデータである。また、「入庫予定補充数」は、補充するように指示された電子部品が何時ストックポイントに入庫されるかに関するデータであって、「製造期間」データ及び/ 又は「所要期間」データに基づいて求められる。
【００３１】
「納品指示」データは、「出荷準備在庫数」データと「確定注文」データに基づいて求められ、ストックポイントからユーザに納品する数量と予定に関するデータである。
「過剰使用数累計」は、サプライヤ側が出荷することを約束した「出荷約束数」を越えて出された「確定注文」の累計を表すデータである。
【００３２】
「不足数累計」は、サプライヤ側が決定した「発注数」及び「補充数」の通りに電子部品がストックポイントに輸送されなかった場合、その不足する電子部品数の累計に関するデータである。
「入庫予定緊急輸送数」は、緊急輸送される電子部品が何時ストックポイントに入庫されるかに関するデータであって、「所要期間」データに基づいて求められる。
【００３３】
次に、各種演算データの求め方について説明する。
図６は、「出荷約束数」、「出荷約束在庫数」、「発注数」及び「入庫予定発注数」を求めるためのフローを示す図である。
まず、サプライヤ側端末１０の処理部１２は、主記憶部１３に予め記憶されている「決定期間」データ（この場合は６週間）及び「在庫期間」データ（この場合は４週間分）を読み出す（ステップ６０１）。次に、「決定期間」データに該当する最新の「フォーキャスト」データが存在するか否かを判断する（ステップ６０２）。該当するデータが無ければ、このプログラムは終了される。該当するデータがある場合、該当する最新の「フォーキャスト」データが、そのまま「出荷約束数」データとされる（ステップ６０３）。ただし、他の基準、例えば今までの「フォーキャスト」データと「確定注文」データとのトレンド等に基づいて、「出荷約束数」を決定するようにしても良い。
【００３４】
次に、「在庫期間」データに基づいて、「出荷約束在庫数」データが求められる（ステップ６０４）。例えば、「決定期間」データに該当する週が第４２週で、「在庫期間」データが４週間である場合、第４２週〜第４５週の４週間分の最新の「フォーキャスト」データが合計されて「出荷約束在庫数」データとなる。
次に、「フォーキャスト」データ及び「決定期間」データに基づいて、「発注計画数」データを求める（ステップ６０６）。なおここで、「発注計画数」データとは、「発注数」データを求めるために便宜上使用するデータである。具体的には、例えば現時点が第４２週とすると、一週前（第４１週）の「フォーキャスト」データと現時点（第４２週）の「フォーキャスト」データの差から「発注計画数」を所定の演算により求めている。
【００３５】
次に、本システムスタートから、現時点が「決定期間」データ以内か否かが判断される（ステップ６０６）。この場合、本システムが最初にユーザから「フォーキャスト」データ等を受信し始めてから、６週間以内の場合には、ステップ６０７に分岐し、「発注計画数」データがそのまま「発注数」データとされる。さらに、「製造期間」データ＋「所要期間」データ分先の週に、「発注数」と同じ数量の「入庫予定発注数」が決定される。「製造期間」データが２週間、「所要期間」データが３週間とすると、５週間先に「発注数」データに相当する部品が入庫予定である旨が示されることとなる。即ち、部品の発注を行ってから、部品を製造し、ストックポイントまで輸送するまでの期間を想定して、部品の入庫予定時期を判断しているわけである。
【００３６】
また、ステップ６０６において、現時点が「決定期間」データ以内でないと判断された場合には、ステップ６０８に分岐し、主記憶部１３から「出荷約束在庫数」データ及び「過剰使用数累計」データを読み出す。次に、ステップ６０５で求めた「発注計画数」データ、「出荷約束在庫数」データ及び「過剰使用数累計」データから、「発注数」データを求め、さらにステップ６０７における方法と同様な方法で「入庫予定発注数」データを求めて（ステップ６０９）、図６のフローを終了する。
【００３７】
図７は、「出荷準備在庫数」データ、「補充数」データ及び「入庫予定補充数」データを求めるフロー図である。
まず、主記憶部１３から「決定期間」データ、「製造期間」データ及び「所要期間」データを読み出す（ステップ７０１）。同様に、主記憶部１３から、「入庫予定発注数」データ、「入庫予定補充数」データ、「入庫予定緊急輸送数」データ及び「出荷約束在庫数」データを読み出す（ステップ７０２）。
【００３８】
次に、「決定期間」データに該当する「フォーキャスト」データ又は「確定注文」データが存在するか否かが判断される（ステップ７０３）。例えば、現時点が１９９９年の第３６週であって、「決定期間」データが６週間である場合、第４２週分の「フォーキャスト」データ又は「確定注文」データが存在するか否かが判断されることとなる。該当するデータがない場合には、このフローは終了する。
【００３９】
該当するデータがある場合、次に、「フォーキャスト」データ又は「確定注文」データと、「入庫予定発注数」データ、「入庫予定補充数」データ、「入庫予定緊急輸送数」データに基づいて、「出荷準備在庫数」データを求める（ステップ７０４）。即ち、ストックポイントに入荷される予定の部品の数量とユーザに納品される数量又は納品される予定の数量から、各週においてストックポイントに準備されている部品の数量をシュミレーションによって求めるわけである。「出荷準備在庫数」は、全ての週についてシュミレーションを行っても良いし、例えば「所要期間」データ以内の週のみについて行っても良い（例えば、現時点が第４０週として、「所要期間」データが３週間の場合、第４０週〜第４３週までの分についてのみシュミレーションを行っても良い）。
【００４０】
次に、「所要期間」データに該当する週において、「出荷約束在庫数」−「出荷準備在庫数」がプラスとなっているか否かが判断される（ステップ７０５）。例えば、現時点が第４０週であり、「所要期間」データが３週間の場合、第４３週の「出荷約束在庫数」−「出荷準備在庫数」を考慮するわけである。即ち、サプライヤ側がストックポイントに入庫することを約束した部品の数量と、その後の「フォーキャスト」の変化等に応じてシュミレーションした在庫の予測とを比較し、その時点でストックポイントにおける部品の数量が足りなくなるか否かを判断するものである。付け加えれば、ユーザからの部品使用予測情報である「フォーキャスト」データに基づき、一様部品の製造及び輸送の指示に該当する「発注数」データを求めた上に、さらに期限が迫ってきた時点で、シュミレーションによって求めた在庫予測情報である「出荷準備在庫数」等に基づき、再度製造及び/ 又は輸送の指示に該当する「補充数」データを求めて、ストックポイントに入庫する部品の数量の調整を図っているわけである。
【００４１】
ステップ７０５で記載した条件に該当する場合には、不足分である「出荷約束在庫数」−「出荷準備在庫数」に相当する分の部品の数量が「補充数」データとされる（ステップ７０６）。即ち、「補充数」データに相当する電子部品の数量をストックポイントに補充すべく指示がなされることとなる。実際には、この「補充数」データに基づいて、部品の製造及び/ 又は輸送が指示される。
次に、「所要期間」データ及び/ 又は「製造期間」データより、「入庫予定補充数」データが求められる（ステップ７０７）。例えば、補充するに際し、既に製造されている電子部品がある場合には、「所要期間」データに相当する期間後にストックポイントに入庫することが予測されるが、新たに製造から開始する必要がある場合には、「製造期間」データ＋「所要期間」データ分の期間が必要となる。以後では、「入庫予定補充数」データは、「製造期間」データ＋「所要期間」データ分の期間が必要であるものとして説明するが、状況に応じて変更することも可能である。なお、図７のフローにおいて、各データがまだ演算等により求められていない場合には「０」と判断するものとする。他のフロー図についても原則同じである。
【００４２】
図８は、「納品指示」データ、「過剰使用数累計」及び、警告表示を行うためのフローである。図８のフローは、「確定注文」データを受信した場合にのみ発動する。
まず、主記憶部１３から該当週の「確定注文」データ及び「出荷準備在庫数」データを読み出す（ステップ８０１）。
【００４３】
次に、「出荷準備在庫数」−「確定注文」＞０であるか否かを判断する（ステップ８０２）。
仮に、ステップ８０２の条件を満足する場合には、ステップ８０３に分岐し、「確定注文」データをそのまま「納品指示」データとする。この「納品指示」データによって、その数量の電子部品が、ストックポイントからユーザへ実際に納品されることとなる。なお、他のパラメータを用いて、「確定注文」データをそのまま「納品指示」データとしない方法を採用することも可能である。
【００４４】
次に、各週毎に「納品指示」―「出荷約束数」を計算し、その累計を「過剰使用数累計」とする（ステップ８０４）。「過剰使用数累計」がプラスの場合は、ユーザが、サプライヤが約束した「出荷約束数」よりも多い確定注文を行っていることが理解される。逆に、「過剰使用数累計」がマイナスの場合は、ユーザが、サプライヤが約束した「出荷約束数」よりも少ない確定注文を行っていることが理解される。
【００４５】
また、ステップ８０２の条件を満足しない場合には、ステップ８０３に分岐し、警告表示がなされる（ステップ８０５）。即ち、警告表示がなされる場合は、ユーザからの確定注文に対応した電子部品がストックポイントに準備できないことを警告していることとなる。
図９は、「不足数累計」を求めるためのフローを示している。
【００４６】
まず、主記憶部１３から、「入庫予定発注数」、「入庫発注数累計」、「入庫予定補充数」及び「入庫補充数累計」が読み出される（ステップ９０１）。ここで、「入庫発注数累計」とは、発注された電子部品の内、実際にストックポイントに入庫した電子部品の数量を示している。例えば、１９９９年第４１週に、３６０ユニットの「入庫予定発注数」がある場合、実際に第４１週にストックポイントに３６０ユニットの部品の入庫があれば、「入庫発注数累計」は３６０ユニットである。
【００４７】
次に、（「入庫予定発注数」―「入庫発注数累計」）＋（「入庫予定補充数」―「入庫補充数累計」）を各週毎に計算して累計した値を「不足数累計」とする（ステップ９０２）。即ち、「不足数累計」がプラスの場合には、サプライヤ側が、発注及び補充の予定通りの部品をストックポイントに納品していないこととなる。
【００４８】
「入庫発注数累計」及び「入庫補充数累計」は、本システムでは、ストックポイント側の実際の状況を把握してサプライヤ側のオペレータ等によって、主記憶部１３に記憶されることとなるが、ストックポイント側にも電子サーバ等の端末を設置して、そこからデータを送信するようにしても良い。また、本システムでは、「入庫発注数累計」及び「入庫補充数累計」が求められた場合にのみ、図９のフローが動作する。
【００４９】
図１０は、「入庫予定緊急輸送数」データを求めるためのフローである。
まず、主記憶部１３から、「所要期間」データ及び「緊急輸送情報」データが読み出される（ステップ１００１）。
次に、「緊急輸送情報」データに含まれる輸送方法データ（図５の５０４参照）に対応した「所要期間」データに基づいて、「入庫予定緊急輸送数」データが求められる。ここまででは、「所要期間」データは（船便）３週間に予め設定されていると説明したが、実際に「所要期間」データは（航空便）１週間、（速達航空便）３日等とも設定されており、具体的な輸送方法データに応じて、緊急輸送される電子部品が何時ストックポイントに入庫するかが判断されて、「入庫予定緊急輸送数」データが求められる。
【００５０】
ここで、図１０のフローは、「緊急輸送情報」データが受信された場合にのみ発動される。
なお、図１０のフローでは、「緊急輸送情報」データが受信された場合には、自動的に「入庫予定緊急輸送数」データが求められるフローとなっている。しかしながら、既に、部品等の発注又は補充の指示を行っている場合では、それらの部品がストックポイントに入庫する時期を早めるような指示を行うことも可能である。即ち、「緊急輸送情報」データに応じて、「入庫予定発注数」データ又は「入庫予定補充数」データの入庫予定時期を前手繰りになるように変更することとなる。さらに、このような変更に伴い、図７のフローに従って「出荷準備在庫数」データも変更されることとなる。
【００５１】
図１１〜図１８は、納品状況画面の一実施形態を示したものである。以下に、受信された「フォーキャスト」データ、「確定注文」データ及び「緊急輸送情報」に基づいて、どのような納品状況画面が作成されていくかを時系列を追って説明する。
ここに示す実施形態では、１９９９年第４２週から実際の電子部品の納品が始まるように、１９９９年第３６週から情報のやり取りが始まる、即ち１９９９年第３６週から本システムがスタートするものとする。さらに、ここでは、「決定期間」データは６週間に、「在庫期間」データは４週間に、「製造期間」データは２週間に、「所要期間」データは３週間（船便）及び１週間（航空便）に、及び「納品期間」データは０週間に予め設定されているものとする。なお、通常「所要期間」データは３週間（船便）に設定されているものとする。
【００５２】
図１１は、第３６週現在の納品状況画面を示す図である。図１１において、１１０１は、ユーザ側から発信され、サプライヤ側端末が受信したデータであり、１１０２は、このデータに基づいて作成された納品状況画面の一例である。
受信されたデータ１１０１には、前述したように、「フォーキャスト」データ、「確定注文」データ、及び「緊急輸送情報」データが含まれる。なお、１１０１の最上段は、１９９９年の各週を示している。即ち、１１０１では、１９９９年第４２週から１９９９年第４９週までを示している。
【００５３】
また、納品状況画面１１０２の最上段は、１９９９年の各週を示している。即ち、１１０２では、１９９９年第３４週から１９９９年第４３週までを示していることとなる。
１１０２の最新の「フォーキャスト」欄には、その週にユーザから受信した最新の「フォーキャスト」データ（１１０１と同じ）を表示することとする。また、１１０２の「確定注文」及び「緊急輸送情報」の欄には、ユーザから受信した「確定注文」データ及び「緊急輸送情報」データをそのまま表示する。なお、「未出荷指示数」とは、「確定注文」があった電子部品中、ストックポイントからユーザへ向けて納品するようにまだ指示を出していない電子部品の数量に関するデータであり、「納品指示数―出荷約束数」とは、「納品指示数」から「出荷約束数」を減算した値に関するデータである。
【００５４】
図１１について説明する。ここに示される１９９９年第３６週では、１１０１に示されるような１９９９年第４２週〜第４９週分の「フォーキャスト」データを受信したものとする。なお、１１０１に示されているように、１９９９年第３６週では、「確定注文」データ及び「緊急輸送情報」データは受信されていない。
【００５５】
第３６週現在において、第４２週は６週間先であって、「決定期間」データに相当するので、図６のフローに従い、「フォーキャスト」データに基づいて、「出荷約束数」１００ユニット及び「出荷約束在庫数」３６０ユニットが演算により求められ、第４２週の欄に表示される。即ち、「フォーキャスト」データの第４２週分の１００ユニットがそのまま「出荷約束数」とされている。また、「フォーキャスト」データの第４２週〜第４５週の４週分が加算されて、３６０ユニット（１００＋１００＋１００＋６０）の「出荷約束在庫数」とされている。
【００５６】
また、図６のフローに従い、「フォーキャスト」データに基づいて、「発注数」３６０ユニットが演算により求められ、第３６週の欄に表示される。即ち、前週の「フォーキャスト」データが存在しないので、第４２週分が０−１００＝−１００、第４３週分が０−１００＝−１００、第４４週分が０−１００＝−１００、第４５週分が−６０で、合計がー３６０となり、その分を「発注数」としている。
【００５７】
さらに、図６のフローに従い、「入庫予定発注数」３６０ユニットが、第４１週の欄に表示される。即ち、第３６週現在において発注した電子部品は、その後製造及び輸送されて、５週間先（＝「製造期間」データ＋「所要期間」データ）の第４１週にストックポイントに到着する予定であることを示している。
なお、第３６週現在では、図７〜図１０のフローを発動する条件がそろわないので、「出荷準備在庫数」、「補充数」、「入庫予定補充数」、「過剰使用数累計」、「入庫予定緊急輸送数」及び「不足数累計」等は、演算により求められることはない。また、上記のようにして作成された納品状況画面１１０２は、ユーザ側端末に送信される。
【００５８】
第１２図は、図１１の状態から１週間進んだ１９９９年第３７週時点の納品状況画面を示している。ここでは、１２０１に示されるような１９９９年第４２週〜第４９週分の「フォーキャスト」データを受信したものとする。
第３７週現在において、第４３週は６週間先であって、「決定期間」データに相当するので、図６のフローに従い、「フォーキャスト」データに基づいて、「出荷約束数」６０ユニット及び「出荷約束在庫数」２４０ユニットが演算により求められ、第４３週の欄に表示される。即ち、「フォーキャスト」データの第４３週分の６０ユニットがそのまま「出荷約束数」とされている。また、「フォーキャスト」データの第４３週〜第４６週の４週分が加算されて、２４０ユニット（６０＋６０＋６０＋６０）の「出荷約束在庫数」とされている。
【００５９】
また、図６のフローに従い、「フォーキャスト」データに基づいて、「発注数」０ユニットが演算により求められ、第３７週の欄に表示される。即ち、前週（第３６週）の「フォーキャスト」データと第３７週現在に受信した「フォーキャスト」データとを比較し、第４３週分が１００−６０＝４０、第４４週分が１００−６０＝４０、第４５週分が６０−６０＝０、第４６週分が−６０で、合計が２０となり、マイナスではないので、発注は行われない。
【００６０】
さらに、図６のフローに従い、「入庫予定発注数」０ユニットが、第４２週の欄に表示される。
なお、第３７週現在では、図７〜図１０のフローを発動する条件がそろわないので、「出荷準備在庫数」、「補充数」、「入庫予定補充数」、「過剰使用数累計」、「入庫予定緊急輸送数」及び「不足数累計」等は、演算により求められることはない。また、上記のようにして作成された納品状況画面１２０２は、ユーザ側端末に送信される。
【００６１】
第１３図は、図１２の状態から１週間進んだ１９９９年第３８週時点の納品状況画面を示している。ここでは、１３０１に示されるような１９９９年第４２週〜第４９週分の「フォーキャスト」データを受信したものとする。
第３８週現在において、第４４週は６週間先であって、「決定期間」データに相当するので、図６のフローに従い、「フォーキャスト」データに基づいて、「出荷約束数」５０ユニット及び「出荷約束在庫数」２５０ユニットが演算により求められ、第４４週の欄に表示される。
【００６２】
また、図６のフローに従い、「フォーキャスト」データに基づいて、「発注数」７０ユニットが演算により求められ、第３８週の欄に表示される。即ち、前週（第３７週）の「フォーキャスト」データと第３８週現在に受信した「フォーキャスト」データとを比較し、第４４週分が６０−５０＝１０、第４５週分が６０−５０＝１０、第４６週分が６０−５０＝１０、第４７週分が−１００で、合計が−７０となり、その分の７０を「発注数」としている。
【００６３】
さらに、図６のフローに従い、「入庫予定発注数」７０ユニットが、第４３週の欄に表示される。
なお、第３８週現在では、図７〜図１０のフローを発動する条件がそろわないので、「出荷準備在庫数」、「補充数」、「入庫予定補充数」、「過剰使用数累計」、「入庫予定緊急輸送数」及び「不足数累計」等は、演算により求められることはない。また、上記のようにして作成された納品状況画面１３０２は、ユーザ側端末に送信される。
【００６４】
第１４図は、図１３の状態から１週間進んだ１９９９年第３９週時点の納品状況画面を示している。ここでは、１４０１に示されるような１９９９年第４２週〜第５０週分の「フォーキャスト」データを受信したものとする。
第３９週現在において、第４５週は６週間先であって、「決定期間」データに相当するので、図６のフローに従い、「フォーキャスト」データに基づいて、「出荷約束数」１０ユニット及び「出荷約束在庫数」１３０ユニットが演算により求められ、第４５週の欄に表示される。
【００６５】
また、図６のフローに従い、「フォーキャスト」データに基づいて、「発注数」０ユニットが演算により求められ、第３９週の欄に表示される。即ち、前週（第３８週）の「フォーキャスト」データと第３９週現在に受信した「フォーキャスト」データとを比較し、第４５週分が５０−１０＝４０、第４６週分が５０−１０＝４０、第４７週分が１００−１０＝９０、第４６週分が−１００で、合計がマイナスではないので、発注は行われない。
【００６６】
さらに、図６のフローに従い、「入庫予定発注数」０ユニットが、第４４週の欄に表示される。
さらに、第４２週は３週間先であって、「所要期間」データ以内に該当するので、図７のフローに従い、「出荷準備在庫数」（３６０）ユニットが演算により求められ、第４２週の欄に記載される。カッコを付して表示しているのは、予測値であるからである。ここで、「確定注文」及び「納品指示数」は第４２週の「フォーキャスト」通りの５０ユニットであると仮定して演算がなされることから、カッコを付けて、第４２週の欄にそれぞれ表示されているが、必ずしも表示する必要はない。
【００６７】
さらに、図７のフローに従い、第４２週の「出荷約束在庫数」と「出荷準備在庫数」との差から、「補充数」０ユニットが演算により求められ、「入庫予定補充数」０が第４４週に表示される。
なお、第３９週現在では、図８〜図１０のフローを発動する条件がそろわないので、「過剰使用数累計」、「入庫予定緊急輸送数」及び「不足数累計」は、演算により求められることはない。また、上記のようにして作成された納品状況画面１４０２は、ユーザ側端末に送信される。
【００６８】
第１５図は、図１４の状態から１週間進んだ１９９９年第４０週時点の納品状況画面を示している。ここでは、１５０１に示されるような１９９９年第４２週〜第５０週分の「フォーキャスト」データを受信したものとする。
第４０週現在において、第４６週は６週間先であって、「決定期間」データに相当するので、図６のフローに従い、「フォーキャスト」データに基づいて、「出荷約束数」５ユニット及び「出荷約束在庫数」１０５ユニットが演算により求められ、第４６週の欄に表示される。
【００６９】
また、図６のフローに従い、「フォーキャスト」データに基づいて、「発注数」０ユニットが演算により求められ、第４０週の欄に表示される。
さらに、図６のフローに従い、「入庫予定発注数」０ユニットが、第４５週の欄に表示される。
さらに、第４２週及び第４３週は３週間先以内であって、「所要期間」データ以内に相当するので、図７のフローに従い、第４２週及び第４３週の欄に、「出荷準備在庫数」（３６０）ユニット及び（２９０）ユニットが演算により求められて、表示される。第４３週の「出荷準備在庫数」（２９０）ユニットは、第４１週に３６０ユニットが入庫する予定であり（「入庫予定発注数」参照）、第４２週には７０ユニットと最新の「フォーキャスト」に表示されていることから、３６０−７０＝２９０より求められる。
【００７０】
さらに、図７のフローに従い、第４３週の「出荷約束在庫数」と「出荷準備在庫数」との差から、「補充数」０ユニットが演算により求められ、「入庫予定補充数」０が第４５週に表示される。
なお、第４０週現在では、図８〜図１０のフローを発動する条件がそろわないので、「過剰使用数累計」、「入庫予定緊急輸送数」及び「不足数累計」は、演算により求められることはない。また、上記のようにして作成された納品状況画面１５０２は、ユーザ側端末に送信される。
【００７１】
第１６図は、図１５の状態から１週間進んだ１９９９年第４１週時点の納品状況画面を示している。ここでは、１６０１に示されるような１９９９年第４３週〜第５０週分の「フォーキャスト」データ、及び１９９９年第４２週分の「確定注文」データを受信したものとする。なお、１６０１に示されているように、１９９９年第４１週では、「緊急輸送情報」データは受信されていない。また、「納品指示数」の欄を見ると、第４２週について新たに１１０ユニットの電子部品のユーザへの納品指示がなされたことが理解される。また、「入庫発注数累計」の欄を参照すると、３６０ユニットが、実際にストックポイントに入荷されたことが理解される。
【００７２】
第４１週現在において、第４７週は６週間先であって、「決定期間」データに該当するので、図６のフローに従い、「フォーキャスト」データに基づいて、「出荷約束数」１０ユニット及び「出荷約束在庫数」１３０ユニットが演算により求められ、第４１週の欄に表示される。
また、図６のフローに従い、「フォーキャスト」データに基づいて、「発注数」３０ユニットが演算により求められ、第４１週の欄に表示される。同様に、「入庫予定発注数」３０ユニットが、第４６週の欄に表示される。
【００７３】
さらに、第４２週〜第４４週は３週間先以内であって、「所要期間」データ以内に相当するので、図７のフローに従い、第４２週〜第４４週の欄に、「出荷準備在庫数」として、３６０ユニット、（２５０）ユニット及び（２４０）ユニットが演算により求められて、表示される。第４３週の「出荷準備在庫数」（２５０）ユニットは、実際にストックポイントに入荷された３６０ユニットから「納品指示」１１０ユニットを引き、３６０−１１０＝２５０から求められる。また、第４４週の「出荷準備在庫数」（２４０）ユニットは、第４３週の「出荷準備在庫数」（２５０）ユニットから、最新の「フォーキャスト」８０ユニットが納品されて、「入庫予定発注数」（７０）ユニットが入庫されたものとして、２５０−８０＋７０＝２４０から求められる。
【００７４】
さらに、図７のフローに従い、第４４週の「出荷約束在庫数」２５０ユニットと「出荷準備在庫数」（２４０）ユニットを比較すると、「出荷準備在庫数」が１０不足していることから、「補充数」１０ユニットが演算により求められて第４１週の欄に表示され、また「入庫予定補充数」１０が第４６週の欄に表示される。
【００７５】
さらに、図８のフローに従い、「過剰使用数累計」１０が、「納品指示」−「出荷約束数」（１１０−１００＝１０）から求められて、第４２週の欄に表示される。なお、第４２週では、「出荷準備在庫数」−「確定注文」がマイナスとならないので、警告表示は行われない。
さらに、図９のフローに従い、（「入庫予定発注数」−「入庫発注数累計」）＋（「入庫予定補充数」−「入庫補充数累計」）によって、「不足数累計」０（（３６０−３６０）＋（０−０）＝０）が演算により求められる。
【００７６】
なお、第４１週現在では、「緊急輸送情報」データは受信していないので、図１０のフローは発動せず、「入庫予定緊急輸送数」の演算は行われない。また、上記のようにして作成された納品状況画面１６０２は、ユーザ側端末に送信される。
第１７図は、図１６の状態から１週間進んだ１９９９年第４２週時点の状況を示している。ここでは、１７０１に示されるような１９９９年第４５週〜第５１週分の「フォーキャスト」データ、及び１９９９年第４３週及び第４４週分の「確定注文」データを受信したものとする。なお、１７０１に示されているように、この時点では、「緊急輸送情報」データは受信されていない。また、「納品指示数」の欄を見ると、第４３週について新たに１５０ユニットの電子部品のユーザへの納品指示がなされたことが理解される。
【００７７】
第４２週現在において、第４８週は６週間先であって、「決定期間」データに相当するので、図６のフローに従い、「フォーキャスト」データに基づいて、「出荷約束数」２０ユニット及び「出荷約束在庫数」１７０ユニットが演算により求められ、第４８週の欄に表示される。
また、図６のフローに従い、「フォーキャスト」データに基づいて、「発注数」５０ユニットが演算により求められ、第４２週の欄に表示される。同様に、「入庫予定発注数」５０ユニットが、第４７週の欄に表示される。
【００７８】
さらに、第４２週〜第４５週は３週間先以内であって、「所要期間」データ以内に相当するので、図７のフローに従い、第４２週〜第４５週の欄に、「出荷準備在庫数」として、３６０ユニット、２５０ユニット、１７０ユニット及び（−１０）ユニットが演算により求められて、表示される。
さらに、図７のフローに従い、第４５週の「出荷約束在庫数」１３０ユニットと「出荷準備在庫数」（−１０）ユニットとが比較され、「出荷準備在庫数」が１４０不足していることから、「補充数」１４０ユニットが演算により求められて第４２週の欄に表示され、また「入庫予定補充数」１４０が第４７週の欄に表示される。
【００７９】
さらに、図８のフローに従い、第４２週分１０ユニットに第４３週分９０ユニット（１５０−６０＝９０）が加算され、「過剰使用数累計」１００が、第４３週の欄に表示される。また、第４４週では、「出荷準備在庫数」−「確定注文」がマイナス（１７０−１８０＝−１０）となるので、その欄が点滅等するように警告表示がなされる。
【００８０】
さらに、図９のフローに従い、第４２週分の０ユニットに、第４３週分の０ユニットが加算され、「不足数累計」０が求められて、第４３週に表示される。
なお、第４２週現在では、「緊急輸送情報」データは受信していないので、図１０のフローは発動せず、「入庫予定緊急輸送数」の演算は行われない。また、上記のようにして作成された納品状況画面１７０２は、ユーザ側端末に送信される。
【００８１】
図１７の状況を考察すると、第４４週において、ストックポイントにおいて準備できる電子部品の数量（１７０ユニット）より、ユーザが納品を要求している数量（１８０）が多いので、「確定注文」に応じることができない。ここで、なぜこのような事態が生じたかを、「過剰使用数累計」及び「不足数累計」から考察する。まず「過剰使用数累計」が１００となっており、ユーザ側の「確定注文」がユーザ側からの「フォーキャスト」に基づく「出荷約束数」を大幅に上回っていることが理解できる。逆に、「不足数累計」は０で、サプライヤ側は発注数及び補充数として決めた数量は確実にストックポイントに入庫していることがわかる。したがって、この場合、第４４週で、「確定注文」に応じられないのは、ユーザ側の責任であることが理解できる。
【００８２】
図１８は、図１７の１７０２に相当する納品状況画面をユーザ側端末の表示部２５で表示したユーザが、１８０１に示すような「緊急輸送情報」を送信した状況に対応した納品状況画面１８０２を示している。なお、図１８も、図１７と同様に、１９９９年第４２週現在を示している。
サプライヤ側端末が、「緊急輸送情報」データを受信したことにより、図１０のフローに従って、「入庫予定緊急輸送数」１０が第４３週に表示される。これは、「緊急輸送情報」データの「輸送方法」データが航空便であったため、それに対応する「所要期間」データが１週間であることから求められたものである。また、「入庫予定緊急輸送数」が変化したことにより、図７のフローに従って、第４４週以降の「出荷準備在庫数」の予測値が変化していることに留意されたい。
【００８３】
このように、図１８の１８０２として示した納品状況画面が作成され、ユーザに対して送信される。
なお、図１８において重要となるのは、緊急輸送によって、ストックポイントに輸送された１０ユニットの航空便費用である。前述のように、通常は、船便３週間であるので、それに対応した輸送費用は、予め部品のコストに入っていると考えられるが、航空便のコストはどうなるかが問題となる。従前では、サプライヤ側とユーザという立場の関係から、サプライヤ側がこの追加コストを支払うことが常であった。しかしながら、本発明のシステムを使用すれば、緊急の輸送を必要とする原因を明確にすることが可能となる。前述したように、この場合に緊急輸送が発生したのは、ユーザ側の責任と考えられる。
【００８４】
なお、図１１〜図１８で用いた納品状況画面は、一例であって、種々の変更が可能であることに留意されたい。例えば、上記の例では、週単位で各種演算データ等が表示されるように構成したが、日単位、月単位等に変更することも可能である。また、上記の例では、電子部品の供給に関して説明したが、電子部品以外の部品等の供給管理に応用することも可能である。
【００８５】
【発明の効果】
ユーザから提供される「フォーキャスト」データに基づいて「発注数」データを求め、「フォーキャスト」データ及び演算によって求めた「出荷約束在庫数」データに基づいて、さらに「補充数」データを求めているので、ユーザ側の部品の発注予測の変化に機敏に対応することができる部品供給システムを提供することを可能としている。
【００８６】
また、サプライヤからユーザへの部品の供給に必要な期間（例えば、「製造期間」データ＋「所要期間」データに相当する期間）以上の第１の期間（例えば「決定期間」データに相当）で「発注数」データを求めて電子部品の発注を行い、さらに第１の期間より短い第２の期間（例えば「所要期間」データに相当する期間）で「補充数」データを求めて補充を行っているので、ユーザ側の部品の発注予測の変化に機敏に対応することができる部品供給システムを提供することを可能としている。
【００８７】
さらに、ユーザから提供される「フォーキャスト」データ及び「確定注文」データに基づいて、将来ユーザの希望通りに納品が行えなくなる予測が生じた場合には、その旨の警告表示を行うことによって、そのような不具合を未然の防止することを可能としている。
さらに、「過剰使用数累計」及び「不足数累計」を表示することにより、ストックポイントにおける部品状況が悪化した原因がユーザ側にあるのかサプライヤ側にあるのかを明確にすることを可能としている。
【図面の簡単な説明】
【図１】本発明に従ったシステムの一実施形態の概略を示す図である。
【図２】本発明に従ったシステムの一実施形態の全体処理フローを示すフォローチャートである。
【図３】「フォーキャスト」データの一実施形態におけるデータ構成を示す図である。
【図４】「確定注文」データの一実施形態におけるデータ構成を示す図である。
【図５】「緊急輸送情報」データの一実施形態におけるデータ構成を示す図である。
【図６】「出荷約束数」データ、「出荷約束在庫数」データ、「発注数」データ及び「入庫予定発注数」データを求めるためのフロー図である。
【図７】「出荷準備在庫数」データ、「補充数」データ及び「入庫予定補充数データ」を求めるためのフロー図である。
【図８】「過剰使用数累計」データ及び「納品指示」データを求めるためのフロー図である。
【図９】「不足数累計」データを求めるためのフロー図である。
【図１０】「入庫予定緊急輸送数」データを求めるためのフロー図である。
【図１１】本発明に従ったシステムで用いられる納品状況画面の一実施形態を示す図である。
【図１２】本発明に従ったシステムで用いられる納品状況画面の一実施形態を示す図である。
【図１３】本発明に従ったシステムで用いられる納品状況画面の一実施形態を示す図である。
【図１４】本発明に従ったシステムで用いられる納品状況画面の一実施形態を示す図である。
【図１５】本発明に従ったシステムで用いられる納品状況画面の一実施形態を示す図である。
【図１６】本発明に従ったシステムで用いられる納品状況画面の一実施形態を示す図である。
【図１７】本発明に従ったシステムで用いられる納品状況画面の一実施形態を示す図である。
【図１８】本発明に従ったシステムで用いられる納品状況画面の一実施形態を示す図である。
【符号の説明】
１…ネットワーク
１０…サプライヤ側端末
１１…サプライヤ側サーバ
１２…サプライヤ側処理部
１３…サプライヤ側主記憶部
１４…サプライヤ側入力部
１５…サプライヤ側表示部
２０…ユーザ側端末
２１…ユーザ側サーバ
２２…ユーザ側処理部
２３…ユーザ側主記憶部
２４…ユーザ側入力部
２５…ユーザ側表示部

Claims (14)

1. 記憶部及び処理部をそれぞれ含むサプライヤ側端末、ユーザ側端末、及びそれらが接続されるネットワークによって構成される部品供給管理システムにおける表示方法であって、
   前記ユーザ側端末は、前記ネットワークを介して部品使用予測情報及び注文情報を送信し、
   前記サプライヤ側端末における前記処理部は、
   前記部品使用予測情報及び前記注文情報を受信し、
   前記部品使用予測情報及び前記注文情報を前記記憶部に記憶し、
   サプライヤからユーザへの部品の供給に必要な期間以上の第１の期間における前記部品使用予測情報に基づいて、部品の発注輸送を開始するための発注情報を求め、
   前記部品使用予測情報又は前記注文情報に基づいて、在庫予測情報を求め、
   前記第１の期間より短い第２の期間における前記部品使用予測情報及び前記在庫予測情報に基づいて、部品の補充輸送を開始するための補充情報を求め、
   前記発注情報、前記在庫予測情報及び前記補充情報を含む表示画面を作成し、
   前記ネットワークを介して前記表示画面を送信する、
   ことを特徴とする部品供給管理システムにおける表示方法。
2. 前記処理部は、前記注文情報と前記在庫予測情報を比較し、前記在庫予測情報が前記注文情報に満たない場合には、前記表示画面において警告表示を行う請求項１に記載の部品供給管理システムにおける表示方法。
3. さらに、前記処理部は、前記部品使用予測情報に基づいてサプライヤがユーザに対して納品を約束する部品量に対応した納品約束数情報及びサプライヤがユーザに対して在庫として保管することを約束する部品量に対応した在庫約束数情報を求めて、前記表示画面に表示する請求項１に記載の部品供給管理システムにおける表示方法。
4. さらに、前記処理部は、前記納品約束数情報及び前記注文情報に基づいて、ユーザ側の注文の状況を表す過剰使用数情報を求めて、前記表示画面に表示する請求項３に記載の部品供給管理システムにおける表示方法。
5. さらに、前記処理部は、前記発注情報及び前記補充情報に基づいて、サプライヤ側の部品供給状況を示す情報を求めて、前記表示画面に表示する請求項１に記載の部品供給管理システムにおける表示方法。
6. さらに、前記サプライヤ側の前記処理部は、前記ユーザ側端末から前記ネットワークを介して送信される緊急輸送情報を受信し、前記緊急輸送情報に基づいて、前記在庫予測情報の変更を行う請求項１に記載の部品供給管理システムにおける表示方法。
7. 前記緊急輸送情報は、輸送方法に関する情報を含む請求項６に記載に部品供給管理システムにおける表示方法。
8. 記憶部及び処理部をそれぞれ含むサプライヤ側端末、ユーザ側端末およびネットワークから構成される部品供給システムにおける表示方法であって、前記サプライヤ側端末における処理部は、
   ユーザ側端末から受信した部品使用予測情報及び注文情報を前記記憶部に記憶し、
   サプライヤからユーザへの備品の供給に必要な期間以上の第１の期間における前記部品使用予測情報に基づいて、部品の発注輸送を開始するための発注情報を求め、
   前記部品使用予測情報又は前記注文情報に基づいて、在庫予測情報を求め、
   前記第１の期間より短い第２の期間における前記部品使用予測情報及び前記在庫予測情報に基づいて、部品の補充輸送を開始するための補充情報を求め、
   表示画面を作成するために前記発注情報、前記在庫予測情報及び前記補充情報を前記ネットワークを介して前記ユーザ側端末に送信することを特徴とする部品供給システムにおける表示方法。
9. さらに、前記処理部は、前記部品使用予測情報に基づいてサプライヤがユーザに対して納品を約束する部品量に対応した納品約束数情報及びサプライヤがユーザに対して在庫として保管することを約束する部品量に対応した在庫約束数情報を求めて、前記ネットワークを介して前記ユーザ側端末に送信する請求項８に記載の部品供給管理システムにおける表示方法。
10. さらに、前記処理部は、前記納品約束数情報及び前記注文情報に基づいて、ユーザ側の注文の状況を表す過剰使用数情報を求めて、前記ネットワークを介して前記ユーザ側端末に送信する請求項９に記載の部品供給管理システムにおける表示方法。
11. さらに、前記処理部は、前記発注情報及び前記補充情報に基づいて、サプライヤ側の部品供給状況を示す情報を求めて、前記ネットワークを介して前記ユーザ側端末に送信する請求項８に記載の部品供給管理システムにおける表示方法。
12. さらに、前記サプライヤ側の前記処理部は、前記ユーザ側端末から前記ネットワークを介して送信される緊急輸送情報を受信し、前記緊急輸送情報に基づいて、前記在庫予測情報の変更を行う請求項８に記載の部品供給管理システムにおける表示方法。
13. 前記緊急輸送情報は、輸送方法に関する情報を含む請求項１２に記載の部品供給管理システムにおける表示方法。
14. 記憶部及び処理部をそれぞれ含むサプライヤ側端末、ユーザ側端末およびネットワークから構成される部品供給システムにおける管理方法であって、前記サプライヤ側端末における処理部は、
    ユーザ側端末から受信した部品使用予測情報及び注文情報を前記記憶部に記憶し、
    サプライヤからユーザへの備品の供給に必要な期間以上の第１の期間における前記部品使用予測情報に基づいて、部品の発注輸送を開始するための発注情報を求め、
    前記部品使用予測情報又は前記注文情報に基づいて、在庫予測情報を求め、
    前記第１の期間より短い第２の期間における前記部品使用予測情報及び前記在庫予測情報に基づいて、部品の補充輸送を開始するための補充情報を求め、
    前記発注情報、前記在庫予測情報及び前記補充情報を前記ネットワークを介して前記ユーザ側端末に送信することを特徴とする管理方法。

Images