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

Abstract

(57)【要約】 【課題】 ユーザとサプライヤとの間の密接な関係を保
ちながら過不足のない部品供給を行うための部品供給管
理システムを提供することにある。 【解決手段】 ユーザ側端末２０は、ネットワーク１を
介して部品使用予測情報及び注文情報を送信し、サプラ
イヤ側端末１０における処理部１２は、部品使用予測情
報及び注文情報を受信し、部品使用予測情報及び注文情
報を記憶部１３に記憶し、部品使用予測情報に基づいて
部品の発注輸送を開始するための発注情報を求め、部品
使用予測情報又は注文情報に基づいて在庫予測情報を求
め、部品使用予測情報及び在庫予測情報に基づいて部品
の補充輸送を開始するための補充情報を求め、発注情
報、在庫予測情報及び補充情報を含む表示画面を作成
し、ネットワークを介して表示画面をユーザ側端末に送
信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、部品供給を受ける
会社（ユーザ）と部品製造を行う会社（サプライヤ）と
を密接に結び付け、必要な時期に、必要な部品を過不足
なく供給ならびに購入するための部品供給管理システム
の表示方法等に関するものであり、特に、ユーザとサプ
ライヤとがとりうる最適な方法を決定するためのシュミ
レーションの方法とシュミレーションを行うための情報
ならびにシュミレーション結果の表示方法に関するもの
である。

【０００２】

【従来の技術】ユーザは、複数のサプライヤから部品を
購入し、それらの部品を組み立てて、最終製品等として
出荷している。通常サプライヤは、多種多用の部品を扱
っているため、常に全ての種類の部品を大量に在庫して
いるわけではない。しかしながら、ユーザからは、特定
の部品について、出来るだけ短い納期で希望する量の納
品を行うよう要望されている。

【０００３】そこで、サプライヤは、ユーザから部品使
用予測情報（フォーキャスト）を受取り、そのフォーキ
ャストに基づいて、ユーザが必要な部品を予め製造し、
ユーザの近くの集積地（ストックポイント）まで輸送し
て保管していた。これによって、ユーザから、例えば、
明日中に所定の部品を所定数量納品してほしい旨の発注
を受けても、速やかにユーザの希望通りの納品を行える
ように準備していた。

【０００４】しかしながら、最近の市場動向の移り変わ
りの速さを反映し、人気のある製品の出荷予定数が大幅
に増加し、その反面、人気の無い製品の出荷予定が大幅
に減少することがある。したがって、ユーザはフォーキ
ャスト通りにサプライヤに部品の注文を行うとは限ら
ず、さらにフォーキャストと実際の部品の注文との間に
大きな差が生ずる場合もあった。

【０００５】フォーキャストの方が実際の発注より大き
い場合、サプライヤが過剰な量の部品を在庫として保管
することが必要となり、逆に、フォーキャストの方が実
際の発注より小さい場合、ユーザが希望する量の部品を
納品することが出来ないという不具合が生じることとな
る。また、ストックポイントに保管されている部品の在
庫は、必ずしも１回分の納品数量分だけが保管されてい
る訳ではないが、例えば急に注文された部品量が増えた
場合、その時に納品する量は確保できるが、次回又は次
々回になって、その時の歪みによって納品すべき量が不
足する場合もあった。このような場合に、納品すべき部
品が不足したのは、ユーザ側のフォーキャストを越えた
発注が原因なのか、それともサプライヤが部品の輸送等
を怠ったからなのかが明確ではなかった。そして、いず
れの場合も、サプライヤ（弱者）の責任と費用負担で問
題が解決されていた。

【０００６】

【発明が解決しようとする課題】本発明の目的は、この
ような従来例が有する欠点を補ったものであり、ユーザ
とサプライヤ間の情報のやり取りを密にして、臨機応変
に対応可能な部品供給システムの表示方法等を提供しよ
うとするものである。また、本発明の目的は、ネットワ
ークを利用した部品供給システムの表示方法等を提供し
ようとするものである。

【０００７】さらに、本発明の目的は、ユーザとサプラ
イヤの責任分担を明確にした部品供給システムの表示方
法等を提供しようとするものである。さらに、本発明の
目的は、ユーザとサプライヤとがとりうる最適な方法を
決定するためのシュミレーションの方法とシュミレーシ
ョンを行うための情報ならびにシュミレーションの結果
の情報等の表示方法を提供しようとするものである。

【０００８】

【課題を解決するための手段】上記課題を解決するため
に、本発明に従った部品供給管理システムにおける表示
方法は、記憶部及び処理部を含むサプライヤ側端末、ユ
ーザ側端末、及びそれらが接続されるネットワークによ
って構成され、ユーザ側端末は前記ネットワークを介し
て部品使用予測情報及び注文情報を送信し、サプライヤ
側端末における前記処理部は、部品使用予測情報及び前
記注文情報を受信し、部品使用予測情報及び注文情報を
前記記憶部に記憶し、部品使用予測情報に基づいて部品
の発注輸送を開始するための発注情報を求め、部品使用
予測情報又は注文情報に基づいて在庫予測情報を求め、
部品使用予測情報及び在庫予測情報に基づいて部品の補
充輸送を開始するための補充情報を求め、発注情報、在
庫予測情報及び補充情報を含む表示画面を作成し、ネッ
トワークを介して前記表示画面を送信する。

【０００９】また、発注情報は、サプライヤからユーザ
への部品の供給に必要な期間以上の第１の期間における
部品使用予測情報に基づいて決定され、補充情報は、前
記第１の期間より短い第２の期間における部品使用予測
情報及び在庫予測情報に基づいて決定されることが好ま
しい。さらに、処理部は、注文情報と在庫予測情報を比
較し、在庫予測情報が注文情報に満たない場合には、表
示画面に警告表示を行うようにすることが好ましい。

【００１０】さらに、処理部は、部品使用予測情報に基
づいてサプライヤがユーザに対して納品を約束する部品
量に対応した納品約束数情報及びサプライヤがユーザに
対して在庫として保管することを約束する部品量に対応
した在庫約束数情報を求めて、表示画面に表示すること
が好ましい。さらに、処理部は、納品約束数情報及び注
文情報に基づいて、ユーザ側の注文の状況を表す過剰使
用数情報を求めて、表示画面に表示することが好まし
い。

【００１１】さらに、処理部は、発注情報及び補充情報
に基づいて、サプライヤ側の部品供給状況を示す情報を
求めて、表示画面に表示することが好ましい。さらに、
サプライヤ側の処理部は、ユーザ側端末からネットワー
クを介して送信される緊急輸送情報を受信し、緊急輸送
情報に基づいて、在庫予測情報の変更を行うようにする
ことが好ましい。

【００１２】さらに、緊急輸送情報は、輸送方法に関す
る情報を含むことが好ましい。また、上記課題を解決す
るために、本発明に従った部品供給管理システムにおけ
る表示方法は、記憶部及び処理部を含むサプライヤ側端
末、ユーザ側端末およびネットワークから構成される部
品供給システムを有し、サプライヤ側端末における処理
部は、ユーザ側端末から受信した部品使用予測情報及び
注文情報を前記記憶部に記憶し、部品使用予測情報に基
づいて部品の発注輸送を開始するための発注情報を求
め、部品使用予測情報又は注文情報に基づいて在庫予測
情報を求め、部品使用予測情報及び在庫予測情報に基づ
いて部品の補充輸送を開始するための補充情報を求め、
表示画面を作成するために発注情報、在庫予測情報及び
補充情報をネットワークを介して前記ユーザ側端末に送
信する。

【００１３】さらに、処理部は、部品使用予測情報に基
づいてサプライヤがユーザに対して納品を約束する部品
量に対応した納品約束数情報及びサプライヤがユーザに
対して在庫として保管することを約束する部品量に対応
した在庫約束数情報を求めて、ネットワークを介してユ
ーザ側端末に送信することが好ましい。さらに、処理部
は、納品約束数情報及び注文情報に基づいて、ユーザ側
の注文の状況を表す過剰使用数情報を求めて、ネットワ
ークを介してユーザ側端末に送信することが好ましい。

【００１４】さらに、処理部は、発注情報及び補充情報
に基づいて、サプライヤ側の部品供給状況を示す情報を
求めて、ネットワークを介してユーザ側端末に送信する
ことが好ましい。また、上記課題を解決するために、本
発明に従った部品供給システムにおける管理方法は、サ
プライヤ側端末における処理部が、ユーザ側端末から受
信した部品使用予測情報及び注文情報を記憶部に記憶
し、部品使用予測情報に基づいて部品の発注輸送を開始
するための発注情報を求め、部品使用予測情報又は注文
情報に基づいて在庫予測情報を求め、部品使用予測情報
及び在庫予測情報に基づいて部品の補充輸送を開始する
ための補充情報を求め、発注情報、在庫予測情報及び補
充情報をネットワークを介してユーザ側端末に送信す
る。

【００１５】

【発明の実施の形態】図１は、本発明による部品供給シ
ステムの一実施形態を示したシステム図である。図１を
用いて、本システムの概要について説明する。本システ
ムは、インターネットや特殊回線等の各種のネットワー
ク１に接続された、サプライヤ側端末１０及びユーザ側
端末２０から構成される。

【００１６】サプライヤ側端末１０は、サプライヤ側サ
ーバ１１と各種の表示を行う表示部１５から構成されて
おり、サプライヤ側サーバ１１は、各種データの送受信
及び各種の処理を行う処理部１２、各種データの記憶を
行うための主記憶部１３および各種データの入力や各種
操作入力を行うための入力部１４から構成されている。
同様に、ユーザ側端末２０は、ユーザ側サーバ２１及び
表示部２５から構成され、ユーザ側サーバ２１は、処理
部２２、主記憶部２３及び入力部２４から構成されてい
る。

【００１７】サプライヤは、電子部品等を製造し、製造
した電子部品をユーザの所在地の近傍に位置するストッ
クポイント（倉庫等）に一時的に保管して、ユーザから
の注文があった場合に速やかに納品できるように準備し
ている。なお、ストックポイントに端末をおいて、その
端末からストックポイントにおける部品の入庫情報等を
ネットワークを介して送信するようにすることも可能で
ある。

【００１８】図２は、部品供給システムの全体処理フロ
ーを示す図である。以下に、図２を用いて、本システム
の全体の処理フローについて説明する。まず、ユーザは
ユーザ側端末２０の入力部２４を用いて「フォーキャス
ト」データ、「確定注文」データ又は「緊急輸送情報」
データを入力し、処理部２２を用いネットワーク１を介
してサプライヤ側に送信する（ステップ２０１）。各種
データの詳細については後述する。

【００１９】次に、サプライヤ側端末１０は、ネットワ
ーク１と接続された処理部１２を用いて、ユーザ側から
の「フォーキャスト」データ、「確定注文」データ、又
は「緊急輸送情報」データを受信する（ステップ２０
２）。次に、サプライヤ側端末１０の処理部１２は、受
信した「フォーキャスト」データ、「確定注文」データ
及び「緊急輸送情報」データを、それぞれ記憶部１３に
記憶する（ステップ２０３）。

【００２０】次に、サプライヤ側端末１０の処理部１２
は、予め主記憶部１３に記憶されている事前設定パラメ
ータ及び前述した各種受信データに基づき、「出荷約束
在庫数」データ、「出荷準備在庫数」データ、「過剰使
用数累計」データ、「不足数累計」データ、「出荷約束
数」データ、「納品指示」データ、「発注数」データ、
「入庫予定発注数」データ、「補充数」データ、「入庫
予定補充数」データ、及び「入庫予定緊急輸送数」デー
タを演算により求める（ステップ２０４）。事前設定パ
ラメータ及び各種演算データの詳細については後述す
る。

【００２１】次に、各種演算データをサプライヤ側主記
憶部１３に記憶する（ステップ２０５）。次に、「確定
注文」データに応じた「納品指示」データをストックポ
イントへ送信する（ステップ２０６）。この「納品指
示」データに応じて、ストックポイントに一時保管され
ている電子部品等がユーザに納品されることとなる。

【００２２】次に、サプライヤ側端末１０の処理部１２
は、各種受信データ及び各種演算データに基づいて、納
品状況画面を作成する（ステップ２０７）。納品状況画
面の詳細については後述する。次に、サプライヤ側端末
１０の処理部１２は、ネットワーク１を介して、作成し
た納品状況画面をユーザ側に送信する（ステップ２０
８）。

【００２３】次に、ユーザ側端末２０の処理部２２は、
納品状況画面を受信し（ステップ２０９）、表示部２５
等に表示を行い、ユーザ側に詳細な部品納品管理に関す
る現状をレポートすることとなる。この様にして受信さ
れた納品状況画面を確認しながら、ユーザは、さらに次
回以降の「フォーキャスト」データ、「確定注文」デー
タ、及び「緊急輸送情報」データ等を送信することとな
り、以後、同様のステップが繰り返される。

【００２４】なお、図２のフローにおいては、サプライ
ヤ側端末から納品状況画面が作成されてユーザ側端末に
送信されたが、サプライヤ側端末から所定のデータのみ
が送信され、ユーザ側端末に予め記憶されている所定の
ソフトウエアにしたがってユーザ側端末で所定の画面が
構成されるようにしても良い。図３には、「フォーキャ
スト」データの一実施形態が示されている。図３を用い
て、以下に「フォーキャスト」データについて説明す
る。図示されるように、「フォーキャスト」データは、
フォーキャストの発行日データ３０１、納品予定データ
３０２及びフォーキャスデータ３０３から構成される。
ここでは、ユーザは１９９９年第３６週の時点におい
て、第４２週に１００ユニット、第４３週に１００ユニ
ット、第４４週に１００ユニット、第４５週に６０ユニ
ット、第４６週に５０ユニット、第４７週に５０ユニッ
ト、第４８週に５０ユニット、及び第４９週に５０ユニ
ットの注文を予測しているというデータ構成となってい
る。なお、図３では、１９９９年の第４２週から第４９
週までの８週分についてのデータが記載されているが、
８週間分に限られることなく、任意の期間についてのデ
ータを添付することが可能である。また、図３では、納
品予定データは、週単位のデータとなっているが、状況
に応じて、日単位、月単位又は任意の期間を基準とする
ことも可能である。さらに、図３において、フォーキャ
ストデータは、ユニット単位となっているが、個々の部
品の実際の個数を用いること等も可能である。

【００２５】図４には、「確定注文」データの一実施形
態が示されている。図４を用いて、以下「確定注文」デ
ータについて説明する。図示されるように、「確定注
文」データは、確定注文の発行日データ４０１、納品予
定データ４０２及び注文データ４０３から構成される。
ここでは、ユーザは１９９９年の第４２週の時点におい
て、第４３週に１５０ユニット及び第４４週に１８０ユ
ニットの確定した注文を正式に依頼しているというデー
タ構成となっている。なお、図４では、１９９９年の第
４３週及び第４４週の２週分についてのデータが記載さ
れているが、２週間分に限られることなく、任意の期間
についてのデータを添付するすることが可能である。ま
た、図４では、納品予定データは、週単位のデータとな
っているが、状況に応じて、日単位、月単位又は任意の
期間を基準とすることも可能である。さらに、図４にお
いて、注文データは、ユニット単位となっているが、個
々の部品の実際の個数を用いること等も可能である。

【００２６】図５には、「緊急輸送情報」データの一実
施形態が示されている。図５を用いて、「緊急輸送情
報」データについて説明する。図示されるように、「緊
急輸送情報」データは、緊急輸送情報の発行日データ５
０１、納品予定データ５０２、輸送データ５０３及び輸
送方法データ５０４から構成される。ここでは、ユーザ
は１９９９年の第４２の時点において、第４３週にスト
ックポイントに入庫するように、１０ユニットを航空便
で依頼するというデータ構成となっている。なお、図５
では、１９９９年の第４３週の１週分についてのデータ
が記載されているが、１週間分に限られることなく、任
意の期間についてのデータを添付することが可能であ
る。また、図５では、納品予定データは、週単位のデー
タとなっているが、状況に応じて、日単位、月単位又は
任意の期間を基準とすることも可能である。さらに、図
５において、輸送データ５０３は、ユニット単位となっ
ているが、個々の部品の実際の個数を用いること等も可
能である。また輸送方法データとしては、他に船便、ト
ラック便にがあり、それぞれに輸送方法を指定すること
が可能となっている。

【００２７】次に、各種事前設定パラメータについて説
明する。各種事前設定パラメータは、主記憶部１２に記
憶されており、「決定期間」データ、「在庫期間」デー
タ、「製造期間」データ、「所要期間」データ及び「納
品期間」データを含んでいる。まず、「決定期間」デー
タとは、後述する「発注数」等を決定するタイミングを
定めるためのパラメータをいう。「在庫期間」データと
は、「出荷約束在庫数」データを決定するために用いら
れるパラメータをいう。「製造期間」データとは、対象
となっている電子部品の製造に必要な期間に関するパラ
メータをいう。「所要期間」データとは、サプライヤか
らストックポイントまで電子部品を輸送するのに必要な
期間に関するパラメータをいい、後述する「補充数」等
を決定するタイミングを定めるためにも使用できる。
「納品期間」データとは、ストックポイントからユーザ
までの納品に必要な期間に関するパラメータをいう。

【００２８】以後の説明では、「決定期間」データは６
週間に、「在庫期間」データは４週間に、「製造期間」
データは２週間に、「所要期間」データは３週間に、及
び「納品期間」データは０週間に事前に設定されている
ものとする。なお、「決定期間」データは、部品の発注
のタイミングを定めるものであるので、「製造期間」デ
ータ＋「所要期間」データ以上の期間であることが望ま
しい。また、これらのパラメータは状況等に応じで自由
に設定することができるものであって、これらの数値に
限定されるものではない。

【００２９】次に、各種演算データについて説明する。
「出荷約束数」は、「決定期間」データに該当する週に
（例えば、現時点が１９９９年第３６週で「決定期間」
データが６週間とすれば、第４２週に）、その時点でサ
プライヤ側がユーザに対して出荷を約束した電子部品の
数量に関するデータである。また、「出荷約束在庫数」
は、サプライヤが、「決定期間」データに該当する週の
始めの時点に、「在庫期間」データに相当する分（ここ
では４週間分）の数量をストックポイントに入庫するこ
とを約束した数量に関するデータである。また、「発注
数」は、ユーザへ納品するために、製造の開始等を指示
する電子部品の数量に関するデータである。また、「入
庫予定発注数」は、発注された電子部品が何時ストック
ポイントに入庫されるかに関するデータであって、「製
造期間」データ及び「所要期間」データに基づいて求め
られる。

【００３０】「出荷準備在庫数」は、その週の初めの時
点で実際にストックポイントに在庫されている電子部品
の数量に関するデータ、又はシュミレーションによって
その週の始めに在庫されていることが予想される電子部
品の数量に関するデータである。なお、後者の場合に
は、カッコ付きで表示される。また、「補充数」は、所
定の場合に、補充的に製造の開始等を指示する電子部品
の数量に関するデータである。また、「入庫予定補充
数」は、補充するように指示された電子部品が何時スト
ックポイントに入庫されるかに関するデータであって、
「製造期間」データ及び/ 又は「所要期間」データに基
づいて求められる。

【００３１】「納品指示」データは、「出荷準備在庫
数」データと「確定注文」データに基づいて求められ、
ストックポイントからユーザに納品する数量と予定に関
するデータである。「過剰使用数累計」は、サプライヤ
側が出荷することを約束した「出荷約束数」を越えて出
された「確定注文」の累計を表すデータである。

【００３２】「不足数累計」は、サプライヤ側が決定し
た「発注数」及び「補充数」の通りに電子部品がストッ
クポイントに輸送されなかった場合、その不足する電子
部品数の累計に関するデータである。「入庫予定緊急輸
送数」は、緊急輸送される電子部品が何時ストックポイ
ントに入庫されるかに関するデータであって、「所要期
間」データに基づいて求められる。

【００３３】次に、各種演算データの求め方について説
明する。図６は、「出荷約束数」、「出荷約束在庫
数」、「発注数」及び「入庫予定発注数」を求めるため
のフローを示す図である。まず、サプライヤ側端末１０
の処理部１２は、主記憶部１３に予め記憶されている
「決定期間」データ（この場合は６週間）及び「在庫期
間」データ（この場合は４週間分）を読み出す（ステッ
プ６０１）。次に、「決定期間」データに該当する最新
の「フォーキャスト」データが存在するか否かを判断す
る（ステップ６０２）。該当するデータが無ければ、こ
のプログラムは終了される。該当するデータがある場
合、該当する最新の「フォーキャスト」データが、その
まま「出荷約束数」データとされる（ステップ６０
３）。ただし、他の基準、例えば今までの「フォーキャ
スト」データと「確定注文」データとのトレンド等に基
づいて、「出荷約束数」を決定するようにしても良い。

【００３４】次に、「在庫期間」データに基づいて、
「出荷約束在庫数」データが求められる（ステップ６０
４）。例えば、「決定期間」データに該当する週が第４
２週で、「在庫期間」データが４週間である場合、第４
２週〜第４５週の４週間分の最新の「フォーキャスト」
データが合計されて「出荷約束在庫数」データとなる。
次に、「フォーキャスト」データ及び「決定期間」デー
タに基づいて、「発注計画数」データを求める（ステッ
プ６０６）。なおここで、「発注計画数」データとは、
「発注数」データを求めるために便宜上使用するデータ
である。具体的には、例えば現時点が第４２週とする
と、一週前（第４１週）の「フォーキャスト」データと
現時点（第４２週）の「フォーキャスト」データの差か
ら「発注計画数」を所定の演算により求めている。

【００３５】次に、本システムスタートから、現時点が
「決定期間」データ以内か否かが判断される（ステップ
６０６）。この場合、本システムが最初にユーザから
「フォーキャスト」データ等を受信し始めてから、６週
間以内の場合には、ステップ６０７に分岐し、「発注計
画数」データがそのまま「発注数」データとされる。さ
らに、「製造期間」データ＋「所要期間」データ分先の
週に、「発注数」と同じ数量の「入庫予定発注数」が決
定される。「製造期間」データが２週間、「所要期間」
データが３週間とすると、５週間先に「発注数」データ
に相当する部品が入庫予定である旨が示されることとな
る。即ち、部品の発注を行ってから、部品を製造し、ス
トックポイントまで輸送するまでの期間を想定して、部
品の入庫予定時期を判断しているわけである。

【００３６】また、ステップ６０６において、現時点が
「決定期間」データ以内でないと判断された場合には、
ステップ６０８に分岐し、主記憶部１３から「出荷約束
在庫数」データ及び「過剰使用数累計」データを読み出
す。次に、ステップ６０５で求めた「発注計画数」デー
タ、「出荷約束在庫数」データ及び「過剰使用数累計」
データから、「発注数」データを求め、さらにステップ
６０７における方法と同様な方法で「入庫予定発注数」
データを求めて（ステップ６０９）、図６のフローを終
了する。

【００３７】図７は、「出荷準備在庫数」データ、「補
充数」データ及び「入庫予定補充数」データを求めるフ
ロー図である。まず、主記憶部１３から「決定期間」デ
ータ、「製造期間」データ及び「所要期間」データを読
み出す（ステップ７０１）。同様に、主記憶部１３か
ら、「入庫予定発注数」データ、「入庫予定補充数」デ
ータ、「入庫予定緊急輸送数」データ及び「出荷約束在
庫数」データを読み出す（ステップ７０２）。

【００３８】次に、「決定期間」データに該当する「フ
ォーキャスト」データ又は「確定注文」データが存在す
るか否かが判断される（ステップ７０３）。例えば、現
時点が１９９９年の第３６週であって、「決定期間」デ
ータが６週間である場合、第４２週分の「フォーキャス
ト」データ又は「確定注文」データが存在するか否かが
判断されることとなる。該当するデータがない場合に
は、このフローは終了する。

【００３９】該当するデータがある場合、次に、「フォ
ーキャスト」データ又は「確定注文」データと、「入庫
予定発注数」データ、「入庫予定補充数」データ、「入
庫予定緊急輸送数」データに基づいて、「出荷準備在庫
数」データを求める（ステップ７０４）。即ち、ストッ
クポイントに入荷される予定の部品の数量とユーザに納
品される数量又は納品される予定の数量から、各週にお
いてストックポイントに準備されている部品の数量をシ
ュミレーションによって求めるわけである。「出荷準備
在庫数」は、全ての週についてシュミレーションを行っ
ても良いし、例えば「所要期間」データ以内の週のみに
ついて行っても良い（例えば、現時点が第４０週とし
て、「所要期間」データが３週間の場合、第４０週〜第
４３週までの分についてのみシュミレーションを行って
も良い）。

【００４０】次に、「所要期間」データに該当する週に
おいて、「出荷約束在庫数」−「出荷準備在庫数」がプ
ラスとなっているか否かが判断される（ステップ７０
５）。例えば、現時点が第４０週であり、「所要期間」
データが３週間の場合、第４３週の「出荷約束在庫数」
−「出荷準備在庫数」を考慮するわけである。即ち、サ
プライヤ側がストックポイントに入庫することを約束し
た部品の数量と、その後の「フォーキャスト」の変化等
に応じてシュミレーションした在庫の予測とを比較し、
その時点でストックポイントにおける部品の数量が足り
なくなるか否かを判断するものである。付け加えれば、
ユーザからの部品使用予測情報である「フォーキャス
ト」データに基づき、一様部品の製造及び輸送の指示に
該当する「発注数」データを求めた上に、さらに期限が
迫ってきた時点で、シュミレーションによって求めた在
庫予測情報である「出荷準備在庫数」等に基づき、再度
製造及び/ 又は輸送の指示に該当する「補充数」データ
を求めて、ストックポイントに入庫する部品の数量の調
整を図っているわけである。

【００４１】ステップ７０５で記載した条件に該当する
場合には、不足分である「出荷約束在庫数」−「出荷準
備在庫数」に相当する分の部品の数量が「補充数」デー
タとされる（ステップ７０６）。即ち、「補充数」デー
タに相当する電子部品の数量をストックポイントに補充
すべく指示がなされることとなる。実際には、この「補
充数」データに基づいて、部品の製造及び/ 又は輸送が
指示される。次に、「所要期間」データ及び/ 又は「製
造期間」データより、「入庫予定補充数」データが求め
られる（ステップ７０７）。例えば、補充するに際し、
既に製造されている電子部品がある場合には、「所要期
間」データに相当する期間後にストックポイントに入庫
することが予測されるが、新たに製造から開始する必要
がある場合には、「製造期間」データ＋「所要期間」デ
ータ分の期間が必要となる。以後では、「入庫予定補充
数」データは、「製造期間」データ＋「所要期間」デー
タ分の期間が必要であるものとして説明するが、状況に
応じて変更することも可能である。なお、図７のフロー
において、各データがまだ演算等により求められていな
い場合には「０」と判断するものとする。他のフロー図
についても原則同じである。

【００４２】図８は、「納品指示」データ、「過剰使用
数累計」及び、警告表示を行うためのフローである。図
８のフローは、「確定注文」データを受信した場合にの
み発動する。まず、主記憶部１３から該当週の「確定注
文」データ及び「出荷準備在庫数」データを読み出す
（ステップ８０１）。

【００４３】次に、「出荷準備在庫数」−「確定注文」
＞０であるか否かを判断する（ステップ８０２）。仮
に、ステップ８０２の条件を満足する場合には、ステッ
プ８０３に分岐し、「確定注文」データをそのまま「納
品指示」データとする。この「納品指示」データによっ
て、その数量の電子部品が、ストックポイントからユー
ザへ実際に納品されることとなる。なお、他のパラメー
タを用いて、「確定注文」データをそのまま「納品指
示」データとしない方法を採用することも可能である。

【００４４】次に、各週毎に「納品指示」―「出荷約束
数」を計算し、その累計を「過剰使用数累計」とする
（ステップ８０４）。「過剰使用数累計」がプラスの場
合は、ユーザが、サプライヤが約束した「出荷約束数」
よりも多い確定注文を行っていることが理解される。逆
に、「過剰使用数累計」がマイナスの場合は、ユーザ
が、サプライヤが約束した「出荷約束数」よりも少ない
確定注文を行っていることが理解される。

【００４５】また、ステップ８０２の条件を満足しない
場合には、ステップ８０３に分岐し、警告表示がなされ
る（ステップ８０５）。即ち、警告表示がなされる場合
は、ユーザからの確定注文に対応した電子部品がストッ
クポイントに準備できないことを警告していることとな
る。図９は、「不足数累計」を求めるためのフローを示
している。

【００４６】まず、主記憶部１３から、「入庫予定発注
数」、「入庫発注数累計」、「入庫予定補充数」及び
「入庫補充数累計」が読み出される（ステップ９０
１）。ここで、「入庫発注数累計」とは、発注された電
子部品の内、実際にストックポイントに入庫した電子部
品の数量を示している。例えば、１９９９年第４１週
に、３６０ユニットの「入庫予定発注数」がある場合、
実際に第４１週にストックポイントに３６０ユニットの
部品の入庫があれば、「入庫発注数累計」は３６０ユニ
ットである。

【００４７】次に、（「入庫予定発注数」―「入庫発注
数累計」）＋（「入庫予定補充数」―「入庫補充数累
計」）を各週毎に計算して累計した値を「不足数累計」
とする（ステップ９０２）。即ち、「不足数累計」がプ
ラスの場合には、サプライヤ側が、発注及び補充の予定
通りの部品をストックポイントに納品していないことと
なる。

【００４８】「入庫発注数累計」及び「入庫補充数累
計」は、本システムでは、ストックポイント側の実際の
状況を把握してサプライヤ側のオペレータ等によって、
主記憶部１３に記憶されることとなるが、ストックポイ
ント側にも電子サーバ等の端末を設置して、そこからデ
ータを送信するようにしても良い。また、本システムで
は、「入庫発注数累計」及び「入庫補充数累計」が求め
られた場合にのみ、図９のフローが動作する。

【００４９】図１０は、「入庫予定緊急輸送数」データ
を求めるためのフローである。まず、主記憶部１３か
ら、「所要期間」データ及び「緊急輸送情報」データが
読み出される（ステップ１００１）。次に、「緊急輸送
情報」データに含まれる輸送方法データ（図５の５０４
参照）に対応した「所要期間」データに基づいて、「入
庫予定緊急輸送数」データが求められる。ここまでで
は、「所要期間」データは（船便）３週間に予め設定さ
れているつと説明したが、実際に所要期間」データは
（航空便）１週間、（速達航空便）３日等とも設定され
ており、具体的な輸送方法データに応じて、緊急輸送さ
れる電子部品が何時ストックポイントに入庫するかが判
断されて、「入庫予定緊急輸送数」データが求められ
る。

【００５０】ここで、図１０のフローは、「緊急輸送情
報」データが受信された場合にのみ発動される。なお、
図１０のフローでは、「緊急輸送情報」データが受信さ
れた場合には、自動的に「入庫予定緊急輸送数」データ
が求められるフローとなっている。しかしながら、既
に、部品等の発注又は補充の指示を行っている場合で
は、それらの部品がストックポイントに入庫する時期を
早めるような指示を行うことも可能である。即ち、「緊
急輸送情報」データに応じて、「入庫予定発注数」デー
タ又は「入庫予定補充数」データの入庫予定時期を前手
繰りになるように変更することとなる。さらに、このよ
うな変更に伴い、図７のフローに従って「出荷準備在庫
数」データも変更されることとなる。

【００５１】図１１〜図１８は、納品状況画面の一実施
形態を示したものである。以下に、受信された「フォー
キャスト」データ、「確定注文」データ及び「緊急輸送
情報」に基づいて、どのような納品状況画面が作成され
ていくかを時系列を追って説明する。ここに示す実施形
態では、１９９９年第４２週から実際の電子部品の納品
が始まるように、１９９９年第３６週から情報のやり取
りが始まる、即ち１９９９年第３６週から本システムが
スタートするものとする。さらに、ここでは、「決定期
間」データは６週間に、「在庫期間」データは４週間
に、「製造期間」データは２週間に、「所要期間」デー
タは３週間（船便）及び１週間（航空便）に、及び「納
品期間」データは０週間に予め設定されているものとす
る。なお、通常「所要期間」データは３週間（船便）に
設定されているものとする。

【００５２】図１１は、第３６週現在の納品状況画面を
示す図である。図１１において、１１０１は、ユーザ側
から発信され、サプライヤ側端末が受信したデータであ
り、１１０２は、このデータに基づいて作成された納品
状況画面の一例である。受信されたデータ１１０１に
は、前述したように、「フォーキャスト」データ、「確
定注文」データ、及び「緊急輸送情報」データが含まれ
る。なお、１１０１の最上段は、１９９９年の各週を示
している。即ち、１１０１では、１９９９年第４２週か
ら１９９９年第４９週までを示している。

【００５３】また、納品状況画面１１０２の最上段は、
１９９９年の各週を示している。即ち、１１０２では、
１９９９年第３４週から１９９９年第４３週までを示し
ていることとなる。１１０２の最新の「フォーキャス
ト」欄には、その週にユーザから受信した最新の「フォ
ーキャスト」データ（１１０１と同じ）を表示すること
とする。また、１１０２の「確定注文」及び「緊急輸送
情報」の欄には、ユーザから受信した「確定注文」デー
タ及び「緊急輸送情報」データをそのまま表示する。な
お、「未出荷指示数」とは、「確定注文」があった電子
部品中、ストックポイントからユーザへ向けて納品する
ようにまだ指示を出していない電子部品の数量に関する
データであり、「納品指示数―出荷約束数」とは、「納
品指示数」から「出荷約束数」を減算した値に関するデ
ータである。

【００５４】図１１について説明する。ここに示される
１９９９年第３６週では、１１０１に示されるような１
９９９年第４２週〜第４９週分の「フォーキャスト」デ
ータを受信したものとする。なお、１１０１に示されて
いるように、１９９９年第３６週では、「確定注文」デ
ータ及び「緊急輸送情報」データは受信されていない。

【００５５】第３６週現在において、第４２週は６週間
先であって、「決定期間」データに相当するので、図６
のフローに従い、「フォーキャスト」データに基づい
て、「出荷約束数」１００ユニット及び「出荷約束在庫
数」３６０ユニットが演算により求められ、第４２週の
欄に表示される。即ち、「フォーキャスト」データの第
４２週分の１００ユニットがそのまま「出荷約束数」と
されている。また、「フォーキャスト」データの第４２
週〜第４５週の４週分が加算されて、３６０ユニット
（１００＋１００＋１００＋６０）の「出荷約束在庫
数」とされている。

【００５６】また、図６のフローに従い、「フォーキャ
スト」データに基づいて、「発注数」３６０ユニットが
演算により求められ、第３６週の欄に表示される。即
ち、前週の「フォーキャスト」データが存在しないの
で、第４２週分が０−１００＝−１００、第４３週分が
０−１００＝−１００、第４４週分が０−１００＝−１
００、第４５週分が−６０で、合計がー３６０となり、
その分を「発注数」としている。

【００５７】さらに、図６のフローに従い、「入庫予定
発注数」３６０ユニットが、第４１週の欄に表示され
る。即ち、第３６週現在において発注した電子部品は、
その後製造及び輸送されて、５週間先（＝「製造期間」
データ＋「所要期間」データ）の第４１週にストックポ
イントに到着する予定であることを示している。なお、
第３６週現在では、図７〜図１０のフローを発動する条
件がそろわないので、「出荷準備在庫数」、「補充
数」、「入庫予定補充数」、「過剰使用数累計」、「入
庫予定緊急輸送数」及び「不足数累計」等は、演算によ
り求められることはない。また、上記のようにして作成
された納品状況画面１１０２は、ユーザ側端末に送信さ
れる。

【００５８】第１２図は、図１１の状態から１週間進ん
だ１９９９年第３７週時点の納品状況画面を示してい
る。ここでは、１２０１に示されるような１９９９年第
４２週〜第４９週分の「フォーキャスト」データを受信
したものとする。第３７週現在において、第４３週は６
週間先であって、「決定期間」データに相当するので、
図６のフローに従い、「フォーキャスト」データに基づ
いて、「出荷約束数」６０ユニット及び「出荷約束在庫
数」２４０ユニットが演算により求められ、第４３週の
欄に表示される。即ち、「フォーキャスト」データの第
４３週分の６０ユニットがそのまま「出荷約束数」とさ
れている。また、「フォーキャスト」データの第４３週
〜第４６週の４週分が加算されて、２４０ユニット（６
０＋６０＋６０＋６０）の「出荷約束在庫数」とされて
いる。

【００５９】また、図６のフローに従い、「フォーキャ
スト」データに基づいて、「発注数」０ユニットが演算
により求められ、第３７週の欄に表示される。即ち、前
週（第３６週）の「フォーキャスト」データと第３７週
現在に受信した「フォーキャスト」データとを比較し、
第４３週分が１００−６０＝４０、第４４週分が１００
−６０＝４０、第４５週分が６０−６０＝０、第４６週
分が−６０で、合計が２０となり、マイナスではないの
で、発注は行われない。

【００６０】さらに、図６のフローに従い、「入庫予定
発注数」０ユニットが、第４２週の欄に表示される。な
お、第３７週現在では、図７〜図１０のフローを発動す
る条件がそろわないので、「出荷準備在庫数」、「補充
数」、「入庫予定補充数」、「過剰使用数累計」、「入
庫予定緊急輸送数」及び「不足数累計」等は、演算によ
り求められることはない。また、上記のようにして作成
された納品状況画面１２０２は、ユーザ側端末に送信さ
れる。

【００６１】第１３図は、図１２の状態から１週間進ん
だ１９９９年第３８週時点の納品状況画面を示してい
る。ここでは、１３０１に示されるような１９９９年第
４２週〜第４９週分の「フォーキャスト」データを受信
したものとする。第３８週現在において、第４４週は６
週間先であって、「決定期間」データに相当するので、
図６のフローに従い、「フォーキャスト」データに基づ
いて、「出荷約束数」５０ユニット及び「出荷約束在庫
数」２５０ユニットが演算により求められ、第４４週の
欄に表示される。

【００６２】また、図６のフローに従い、「フォーキャ
スト」データに基づいて、「発注数」７０ユニットが演
算により求められ、第３８週の欄に表示される。即ち、
前週（第３７週）の「フォーキャスト」データと第３８
週現在に受信した「フォーキャスト」データとを比較
し、第４４週分が６０−５０＝１０、第４５週分が６０
−５０＝１０、第４６週分が６０−５０＝１０、第４７
週分が−１００で、合計が−７０となり、その分の７０
を「発注数」としている。

【００６３】さらに、図６のフローに従い、「入庫予定
発注数」７０ユニットが、第４３週の欄に表示される。
なお、第３８週現在では、図７〜図１０のフローを発動
する条件がそろわないので、「出荷準備在庫数」、「補
充数」、「入庫予定補充数」、「過剰使用数累計」、
「入庫予定緊急輸送数」及び「不足数累計」等は、演算
により求められることはない。また、上記のようにして
作成された納品状況画面１３０２は、ユーザ側端末に送
信される。

【００６４】第１４図は、図１３の状態から１週間進ん
だ１９９９年第３９週時点の納品状況画面を示してい
る。ここでは、１４０１に示されるような１９９９年第
４２週〜第５０週分の「フォーキャスト」データを受信
したものとする。第３９週現在において、第４５週は６
週間先であって、「決定期間」データに相当するので、
図６のフローに従い、「フォーキャスト」データに基づ
いて、「出荷約束数」１０ユニット及び「出荷約束在庫
数」１３０ユニットが演算により求められ、第４５週の
欄に表示される。

【００６５】また、図６のフローに従い、「フォーキャ
スト」データに基づいて、「発注数」０ユニットが演算
により求められ、第３９週の欄に表示される。即ち、前
週（第３８週）の「フォーキャスト」データと第３９週
現在に受信した「フォーキャスト」データとを比較し、
第４５週分が５０−１０＝４０、第４６週分が５０−１
０＝４０、第４７週分が１００−１０＝９０、第４６週
分が−１００で、合計がマイナスではないので、発注は
行われない。

【００６６】さらに、図６のフローに従い、「入庫予定
発注数」０ユニットが、第４４週の欄に表示される。さ
らに、第４２週は３週間先であって、「所要期間」デー
タ以内に該当するので、図７のフローに従い、「出荷準
備在庫数」（３６０）ユニットが演算により求められ、
第４２週の欄に記載される。カッコを付して表示してい
るのは、予測値であるからである。ここで、「確定注
文」及び「納品指示数」は第４２週の「フォーキャス
ト」通りの５０ユニットであると仮定して演算がなされ
ることから、カッコを付けて、第４２週の欄にそれぞれ
表示されているが、必ずしも表示する必要はない。

【００６７】さらに、図７のフローに従い、第４２週の
「出荷約束在庫数」と「出荷準備在庫数」との差から、
「補充数」０ユニットが演算により求められ、「入庫予
定補充数」０が第４４週に表示される。なお、第３９週
現在では、図８〜図１０のフローを発動する条件がそろ
わないので、「過剰使用数累計」、「入庫予定緊急輸送
数」及び「不足数累計」は、演算により求められること
はない。また、上記のようにして作成された納品状況画
面１４０２は、ユーザ側端末に送信される。

【００６８】第１５図は、図１４の状態から１週間進ん
だ１９９９年第４０週時点の納品状況画面を示してい
る。ここでは、１５０１に示されるような１９９９年第
４２週〜第５０週分の「フォーキャスト」データを受信
したものとする。第４０週現在において、第４６週は６
週間先であって、「決定期間」データに相当するので、
図６のフローに従い、「フォーキャスト」データに基づ
いて、「出荷約束数」５ユニット及び「出荷約束在庫
数」１０５ユニットが演算により求められ、第４６週の
欄に表示される。

【００６９】また、図６のフローに従い、「フォーキャ
スト」データに基づいて、「発注数」０ユニットが演算
により求められ、第４０週の欄に表示される。さらに、
図６のフローに従い、「入庫予定発注数」０ユニット
が、第４５週の欄に表示される。さらに、第４２週及び
第４３週は３週間先以内であって、「所要期間」データ
以内に相当するので、図７のフローに従い、第４２週及
び第４３週の欄に、「出荷準備在庫数」（３６０）ユニ
ット及び（２９０）ユニットが演算により求められて、
表示される。第４３週の「出荷準備在庫数」（２９０）
ユニットは、第４１週に３６０ユニットが入庫する予定
であり（「入庫予定発注数」参照）、第４２週には７０
ユニットと最新の「フォーキャスト」に表示されている
ことから、３６０−７０＝２９０より求められる。

【００７０】さらに、図７のフローに従い、第４３週の
「出荷約束在庫数」と「出荷準備在庫数」との差から、
「補充数」０ユニットが演算により求められ、「入庫予
定補充数」０が第４５週に表示される。なお、第４０週
現在では、図８〜図１０のフローを発動する条件がそろ
わないので、「過剰使用数累計」、「入庫予定緊急輸送
数」及び「不足数累計」は、演算により求められること
はない。また、上記のようにして作成された納品状況画
面１５０２は、ユーザ側端末に送信される。

【００７１】第１６図は、図１５の状態から１週間進ん
だ１９９９年第４１週時点の納品状況画面を示してい
る。ここでは、１６０１に示されるような１９９９年第
４３週〜第５０週分の「フォーキャスト」データ、及び
１９９９年第４２週分の「確定注文」データを受信した
ものとする。なお、１６０１に示されているように、１
９９９年第４１週では、「緊急輸送情報」データは受信
されていない。また、「納品指示数」の欄を見ると、第
４２週について新たに１１０ユニットの電子部品のユー
ザへの納品指示がなされたことが理解される。また、
「入庫発注数累計」の欄を参照すると、３６０ユニット
が、実際にストックポイントに入荷されたことが理解さ
れる。

【００７２】第４１週現在において、第４７週は６週間
先であって、「決定期間」データに該当するので、図６
のフローに従い、「フォーキャスト」データに基づい
て、「出荷約束数」１０ユニット及び「出荷約束在庫
数」１３０ユニットが演算により求められ、第４１週の
欄に表示される。また、図６のフローに従い、「フォー
キャスト」データに基づいて、「発注数」３０ユニット
が演算により求められ、第４１週の欄に表示される。同
様に、「入庫予定発注数」３０ユニットが、第４６週の
欄に表示される。

【００７３】さらに、第４２週〜第４４週は３週間先以
内であって、「所要期間」データ以内に相当するので、
図７のフローに従い、第４２週〜第４４週の欄に、「出
荷準備在庫数」として、３６０ユニット、（２５０）ユ
ニット及び（２４０）ユニットが演算により求められ
て、表示される。第４３週の「出荷準備在庫数」（２５
０）ユニットは、実際にストックポイントに入荷された
３６０ユニットから「納品指示」１１０ユニットを引
き、３６０−１１０＝２５０から求められる。また、第
４４週の「出荷準備在庫数」（２４０）ユニットは、第
４３週の「出荷準備在庫数」（２５０）ユニットから、
最新の「フォーキャスト」８０ユニットが納品されて、
「入庫予定発注数」（７０）ユニットが入庫されたもの
として、２５０−８０＋７０＝２４０から求められる。

【００７４】さらに、図７のフローに従い、第４４週の
「出荷約束在庫数」２５０ユニットと「出荷準備在庫
数」（２４０）ユニットを比較すると、「出荷準備在庫
数」が１０不足していることから、「補充数」１０ユニ
ットが演算により求められて第４１週の欄に表示され、
また「入庫予定補充数」１０が第４６週の欄に表示され
る。

【００７５】さらに、図８のフローに従い、「過剰使用
数累計」１０が、「納品指示」−「出荷約束数」（１１
０−１００＝１０）から求められて、第４２週の欄に表
示される。なお、第４２週では、「出荷準備在庫数」−
「確定注文」がマイナスとならないので、警告表示は行
われない。さらに、図９のフローに従い、（「入庫予定
発注数」−「入庫発注数累計」）＋（「入庫予定補充
数」−「入庫補充数累計」）によって、「不足数累計」
０（（３６０−３６０）＋（０−０）＝０）が演算によ
り求められる。

【００７６】なお、第４１週現在では、「緊急輸送情
報」データは受信していないので、図１０のフローは発
動せず、「入庫予定緊急輸送数」の演算は行われない。
また、上記のようにして作成された納品状況画面１６０
２は、ユーザ側端末に送信される。第１７図は、図１６
の状態から１週間進んだ１９９９年第４２週時点の状況
を示している。ここでは、１７０１に示されるような１
９９９年第４５週〜第５１週分の「フォーキャスト」デ
ータ、及び１９９９年第４３週及び第４４週分の「確定
注文」データを受信したものとする。なお、１７０１に
示されているように、この時点では、「緊急輸送情報」
データは受信されていない。また、「納品指示数」の欄
を見ると、第４３週について新たに１５０ユニットの電
子部品のユーザへの納品指示がなされたことが理解され
る。

【００７７】第４２週現在において、第４８週は６週間
先であって、「決定期間」データに相当するので、図６
のフローに従い、「フォーキャスト」データに基づい
て、「出荷約束数」２０ユニット及び「出荷約束在庫
数」１７０ユニットが演算により求められ、第４８週の
欄に表示される。また、図６のフローに従い、「フォー
キャスト」データに基づいて、「発注数」５０ユニット
が演算により求められ、第４２週の欄に表示される。同
様に、「入庫予定発注数」５０ユニットが、第４７週の
欄に表示される。

【００７８】さらに、第４２週〜第４５週は３週間先以
内であって、「所要期間」データ以内に相当するので、
図７のフローに従い、第４２週〜第４５週の欄に、「出
荷準備在庫数」として、３６０ユニット、２５０ユニッ
ト、１７０ユニット及び（−１０）ユニットが演算によ
り求められて、表示される。さらに、図７のフローに従
い、第４５週の「出荷約束在庫数」１３０ユニットと
「出荷準備在庫数」（−１０）ユニットとが比較され、
「出荷準備在庫数」が１４０不足していることから、
「補充数」１４０ユニットが演算により求められて第４
２週の欄に表示され、また「入庫予定補充数」１４０が
第４７週の欄に表示される。

【００７９】さらに、図８のフローに従い、第４２週分
１０ユニットに第４３週分９０ユニット（１５０−６０
＝９０）が加算され、「過剰使用数累計」１００が、第
４３週の欄に表示される。また、第４４週では、「出荷
準備在庫数」−「確定注文」がマイナス（１７０−１８
０＝−１０）となるので、その欄が点滅等するように警
告表示がなされる。

【００８０】さらに、図９のフローに従い、第４２週分
の０ユニットに、第４３週分の０ユニットが加算され、
「不足数累計」０が求められて、第４３週に表示され
る。なお、第４２週現在では、「緊急輸送情報」データ
は受信していないので、図１０のフローは発動せず、
「入庫予定緊急輸送数」の演算は行われない。また、上
記のようにして作成された納品状況画面１７０２は、ユ
ーザ側端末に送信される。

【００８１】図１７の状況を考察すると、第４４週にお
いて、ストックポイントにおいて準備できる電子部品の
数量（１７０ユニット）より、ユーザが納品を要求して
いる数量（１８０）が多いので、「確定注文」に応じる
ことができない。ここで、なぜこのような事態が生じた
かを、「過剰使用数累計」及び「不足数累計」から考察
する。まず「過剰使用数累計」が１００となっており、
ユーザ側の「確定注文」がユーザ側からの「フォーキャ
スト」に基づく「出荷約束数」を大幅に上回っているこ
とが理解できる。逆に、「不足数累計」は０で、サプラ
イヤ側は発注数及び補充数として決めた数量は確実にス
トックポイントに入庫していることがわかる。したがっ
て、この場合、第４４週で、「確定注文」に応じられな
いのは、ユーザ側の責任であることが理解できる。

【００８２】図１８は、図１７の１７０２に相当する納
品状況画面をユーザ側端末の表示部２５で表示したユー
ザが、１８０１に示すような「緊急輸送情報」を送信し
た状況に対応した納品状況画面１８０２を示している。
なお、図１８も、図１７と同様に、１９９９年第４２週
現在を示している。サプライヤ側端末が、「緊急輸送情
報」データを受信したことにより、図１０のフローに従
って、「入庫予定緊急輸送数」１０が第４３週に表示さ
れる。これは、「緊急輸送情報」データの「輸送方法」
データが航空便であったため、それに対応する「所要期
間」データが１週間であることから求められたものであ
る。また、「入庫予定緊急輸送数」が変化したことによ
り、図７のフローに従って、第４４週以降の「出荷準備
在庫数」の予測値が変化していることに留意されたい。

【００８３】このように、図１８の１８０２として示し
た納品状況画面が作成され、ユーザに対して送信され
る。なお、図１８において重要となるのは、緊急輸送に
よって、ストックポイントに輸送された１０ユニットの
航空便費用である。前述のように、通常は、船便３週間
であるので、それに対応した輸送費用は、予め部品のコ
ストに入っていると考えられるが、航空便のコストはど
うなるかが問題となる。従前では、サプライヤ側とユー
ザという立場の関係から、サプライヤ側がこの追加コス
トを支払うことが常であった。しかしながら、本発明の
システムを使用すれば、緊急の輸送を必要とする原因を
明確にすることが可能となる。前述したように、この場
合に緊急輸送が発生したのは、ユーザ側の責任と考えら
れる。

【００８４】なお、図１１〜図１８で用いた納品状況画
面は、一例であって、種々の変更が可能であることに留
意されたい。例えば、上記の例では、週単位で各種演算
データ等が表示されるように構成したが、日単位、月単
位等に変更することも可能である。また、上記の例で
は、電子部品の供給に関して説明したが、電子部品以外
の部品等の供給管理に応用することも可能である。

【００８５】

【発明の効果】ユーザから提供される「フォーキャス
ト」データに基づいて「発注数」データを求め、「フォ
ーキャスト」データ及び演算によって求めた「出荷約束
在庫数」データに基づいて、さらに「補充数」データを
求めているので、ユーザ側の部品の発注予測の変化に機
敏に対応することができる部品供給システムを提供する
ことを可能としている。

【００８６】また、サプライヤからユーザへの部品の供
給に必要な期間（例えば、「製造期間」データ＋「所要
期間」データに相当する期間）以上の第１の期間（例え
ば「決定期間」データに相当）で「発注数」データを求
めて電子部品の発注を行い、さらに第１の期間より短い
第２の期間（例えば「所要期間」データに相当する期
間）で「補充数」データを求めて補充を行っているの
で、ユーザ側の部品の発注予測の変化に機敏に対応する
ことができる部品供給システムを提供することを可能と
している。

【００８７】さらに、ユーザから提供される「フォーキ
ャスト」データ及び「確定注文」データに基づいて、将
来ユーザの希望通りに納品が行えなくなる予測が生じた
場合には、その旨の警告表示を行うことによって、その
ような不具合を未然の防止することを可能としている。
さらに、「過剰使用数累計」及び「不足数累計」を表示
することにより、ストックポイントにおける部品状況が
悪化した原因がユーザ側にあるのかサプライヤ側にある
のかを明確にすることを可能としている。

【図面の簡単な説明】

【図１】本発明に従ったシステムの一実施形態の概略を
示す図である。

【図２】本発明に従ったシステムの一実施形態の全体処
理フローを示すフォローチャートである。

【図３】「フォーキャスト」データの一実施形態におけ
るデータ構成を示す図である。

【図４】「確定注文」データの一実施形態におけるデー
タ構成を示す図である。

【図５】「緊急輸送情報」データの一実施形態における
データ構成を示す図である。

【図６】「出荷約束数」データ、「出荷約束在庫数」デ
ータ、「発注数」データ及び「入庫予定発注数」データ
を求めるためのフロー図である。

【図７】「出荷準備在庫数」データ、「補充数」データ
及び「入庫予定補充数データ」を求めるためのフロー図
である。

【図８】「過剰使用数累計」データ及び「納品指示」デ
ータを求めるためのフロー図である。

【図９】「不足数累計」データを求めるためのフロー図
である。

【図１０】「入庫予定緊急輸送数」データを求めるため
のフロー図である。

【図１１】本発明に従ったシステムで用いられる納品状
況画面の一実施形態を示す図である。

【図１２】本発明に従ったシステムで用いられる納品状
況画面の一実施形態を示す図である。

【図１３】本発明に従ったシステムで用いられる納品状
況画面の一実施形態を示す図である。

【図１４】本発明に従ったシステムで用いられる納品状
況画面の一実施形態を示す図である。

【図１５】本発明に従ったシステムで用いられる納品状
況画面の一実施形態を示す図である。

【図１６】本発明に従ったシステムで用いられる納品状
況画面の一実施形態を示す図である。

【図１７】本発明に従ったシステムで用いられる納品状
況画面の一実施形態を示す図である。

【図１８】本発明に従ったシステムで用いられる納品状
況画面の一実施形態を示す図である。

【符号の説明】

１…ネットワーク １０…サプライヤ側端末 １１…サプライヤ側サーバ １２…サプライヤ側処理部 １３…サプライヤ側主記憶部 １４…サプライヤ側入力部 １５…サプライヤ側表示部 ２０…ユーザ側端末 ２１…ユーザ側サーバ ２２…ユーザ側処理部 ２３…ユーザ側主記憶部 ２４…ユーザ側入力部 ２５…ユーザ側表示部

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/60 ３２０ Ｇ０６Ｆ 17/60 ３２０ Ｆターム(参考） 3C030 AA20 DA01 DA09 DA10 5B049 BB07 BB31 CC05 CC21 CC27 CC31 EE01 EE31 EE41 FF03 FF04 GG04 GG07 5H215 AA06 AA20 BB01 CC05 CC09 CX06 GG05 GG09 JJ14 KK03 9A001 JJ47 JJ52 JJ67 JZ25 KK54

Claims (18)

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