JP5738779B2 - 供給能力推定システム、方法、及びプログラム - Google Patents

Description

本発明は、製品生産計画、部品調達管理、ＳＣＭ、ＥＤＩなどに関する情報処理の技術に関する。特に、生産計画（日時や数量）の調整の業務や、部品のバイヤ−サプライヤ間での取引（受発注）の業務を支援する情報処理システムなどに関する。

企業のグローバル化の進展により、サプライヤ及び工場（部品を用いて製品を製造する工場）等がグローバルに多数点在する。これに伴い、バイヤや生産計画者にとって、サプライヤと工場の組み合わせ毎における、部品納入要求に対する部品納入回答の確認や、生産計画の調整は、非常に煩雑となる。

従来、複数工場の生産計画に基づいて複数サプライヤへの部品納入要求を最適に立案する技術などは既に存在する。しかし、生産計画は製品の需要変動などに基づいて常に変化する。そのため、一度立案したサプライヤへの部品納入要求（部品所要数など）も、当該需要変動などに基づき、変更されることが常時・頻繁に発生している。このような場合、変更後の部品納入要求（部品所要数など）が実行（供給）可能かどうかについて、サプライヤ側は確認をとって納入回答を作成する必要があり、また、バイヤ側はサプライヤに問い合わせて納入回答を得る必要がある。サプライヤ側は当該確認・納入回答作成のためにある程度の時間（例えば１〜２日）を要している。

また前提技術として、上記バイヤ−サプライヤ間での部品の取引（受発注など）の業務を支援して納期調整の効率化などを実現するシステムは既に存在する。当該システム例としては、ネットワーク（インターネット）上にサーバ等が設けられ、バイヤ及びサプライヤがそれぞれアクセスし、Ｗｅｂインタフェース等で取引情報を登録・表示する等の支援サービスを提供する。バイヤは、製品生産計画に応じた部品所要数などを含むサプライヤへの納入要求をシステムに登録する。サプライヤは、バイヤの納入要求に対する部品供給可能数などを含むバイヤへの納入回答をシステムに登録する。これにより納期調整の効率化などができる。

先行技術例として、特開２００９−３０１４６６号公報（特許文献１）、特開２００８−５２４１３号公報（特許文献２）などがある。

特許文献１（サプライチェーンの効率化支援方法）では、当初想定した販売変動を上回る急な販売数増加の販売計画変動が生じても資材の欠品による生産遅延及び製品在庫不足による出荷遅延を防止できること等が記載されている。

特許文献２（販売計画の評価支援システム）では、販売計画を見直すタイミングによって棚卸資産残高がどのように推移するか可視化し、計画変更の意思決定タイミングが業務指標へ与える影響の評価を支援すること等が記載されている。

特開２００９−３０１４６６号公報 特開２００８−５２４１３号公報

従来システム例の問題点として、前述のようにバイヤからサプライヤへの納入要求（部品所要数など）を変更した場合、バイヤはサプライヤからの納入回答（部品供給可能数など）を待たないと、当該サプライヤが変更後の部品所要数を供給可能かどうか等はわからない。即ちバイヤ−サプライヤ間での需給調整・生産計画調整などの業務において効率性に改善余地がある。

なお特許文献１は、生産計画の変動を見込んで部品を仕込むことについて言及しているが、サプライヤの供給能力の推定を考慮した技術ではない。

なお特許文献２は、複数タイミング（時点）の計画調整が及ぼす影響を考慮可能とする技術であるが、サプライヤの供給能力の推定を考慮した技術ではない。

以上を鑑み、本発明の主な目的は、バイヤ−サプライヤ間の部品の取引を支援する技術に関して、サプライヤの供給能力を推定することにより、需給調整・生産計画調整の短縮などが実現できる技術を提供することである。

本発明のうち代表的な形態は、バイヤ−サプライヤ間の部品の取引を支援する情報処理を行うシステム（部品取引システム、サプライヤ部品供給能力推定システム）等であって、以下に示す構成を有することを特徴とする。

本発明は、サプライヤの部品供給能力を推定する推定機能（サプライヤ部品供給能力推定機能）を提供する。本システムは、コンピュータの情報処理により実現される、取引情報表示機能、取引履歴管理機能、及び上記推定機能などを備える。

取引情報表示機能は、バイヤ及びサプライヤの人が、納入要求及び納入回答を含む部品の取引に係わる情報（取引情報）を登録して互いに表示・確認できる機能である。また取引情報表示機能は、推定機能による推定結果情報を含む情報を、バイヤ担当者、生産計画者などの人に対して表示する画面（ＧＵＩ）を提供する。

取引履歴管理機能は、取引情報表示機能により登録・表示される取引情報を含むデータ情報について、過去及び現在の取引情報を含めて時系列の取引履歴情報としてＤＢに管理・把握する機能である。取引履歴管理機能は、ＤＢからの検索により、過去及び現在の取引情報を、バイヤ別、サプライヤ別、部品別、時系列、納入日順などで抽出可能である。

推定機能では、生産計画調整時（特に部品所要数などの変更時）、バイヤからサプライヤへの納入要求時に、以下の方式・ロジックに従い、サプライヤ部品供給能力（供給可否、供給可能数など）を自動的に推定して当該推定結果情報を出力する。これにより、人間系（例えばバイヤ担当者−サプライヤ担当者間）での確認のやり取りを削減し、生産計画調整（確定）の短縮を図る。

（１）第１の推定機能として、取引履歴管理機能（取引履歴情報）に基づき、過去、バイヤの納入要求（部品所要数など）に対するサプライヤの納入回答（部品供給可能数など）がどのような内容であったかをみながら、サプライヤ側の輸送中在庫、仕掛、及び注残などの要素の数量を推定する。そして、この推定値に基づき、バイヤ側への部品の着荷の時点（納入日）を基準として、サプライヤの各種の工程リードタイム（部品輸送リードタイム、部品製造リードタイム、マテリアル調達リードタイム等）分を時間的に遡及（オフセット）した時点の納入回答から、サプライヤ側の輸送中在庫、仕掛、及び注残などの要素の数量に基づくサプライヤ部品供給能力（供給可否、供給可能数など）を推定し、第１推定結果情報として記憶・出力する。

（２）第２の推定機能として、取引履歴管理機能（取引履歴情報）に基づき、過去、バイヤの納入要求（部品所要数など）における変更（特に増加分）に対してサプライヤの納入回答（部品供給可能数など）がどれだけ追従（対応）できていたかを表す指標値（追従数）を算出する。サプライヤ側は、マテリアル在庫、及び部品在庫（予備）を利用することで、上記変更（増加分）に追従（対応）が可能である。そして、この指標値（追従数）から、マテリアル在庫、及び部品在庫の要素の数量に基づくサプライヤ部品供給能力（供給可否、供給可能数など）を推定し、第２推定結果情報として記憶・出力する。

本システムは、例えば、通信網を介してバイヤ−サプライヤ間での部品の取引を支援する情報処理を行う供給能力推定システムであって、前記バイヤからの部品の所要数を含む納入要求の情報、及び前記サプライヤからの部品の供給可能数を含む納入回答の情報を含む、前記部品の取引の情報を画面で登録して表示する取引情報表示機能と、前記取引情報表示機能による前記部品の取引の一連の情報を時系列で取引履歴情報としてＤＢに記憶し管理する取引履歴管理機能と、前記バイヤの納入要求に対する前記サプライヤの納入回答に関する当該サプライヤの部品の供給能力を推定する処理を行う推定機能と、を有する。

前記推定機能は、前記ＤＢから前記バイヤの納入要求に関する納入要求履歴情報を取得する処理と、前記ＤＢから前記サプライヤの納入回答に関する納入回答履歴情報を取得する処理と、前記サプライヤによる部品の提供に関する工程リードタイム情報を取得する処理と、前記納入要求履歴情報、納入回答履歴情報、及び工程リードタイム情報を用いて、過去の納入要求の所要数に対する過去の納入回答の供給可能数を判断することにより、前記サプライヤの部品の供給能力を、推定される供給可能数または供給可否の形で推定し、推定結果情報として作成し記憶する処理と、前記推定結果情報を含む画面をユーザに対して出力する処理と、を行う。

本発明のうち代表的な形態によれば、バイヤ−サプライヤ間の部品の取引を支援する技術に関して、サプライヤの供給能力を推定することにより、需給調整・生産計画調整の短縮などが実現できる。

例えばバイヤ・生産計画者は、サプライヤの確認・納入回答（供給可能数など）を待たずに、生産計画調整の確定が可能となる。これにより、生産計画調整時間の大幅な短縮などが見込める。これらの効果により、需要変動への迅速な対応による売上拡大・在庫縮小が期待できる。

本発明の一実施の形態のシステム（部品取引システム及びサプライヤ供給能力推定システムを含んで成る）の全体の構成を示す図である。 本実施の形態のバイヤ−サプライヤ間の部品取引システムの構成例を示し、前提技術のシステムである部品取引システムに取引履歴管理機能を追加した構成例を示す図である。 本発明の一実施の形態のサプライヤ供給能力推定システム（推定装置）の構成を示す図である。 （ａ）は従来システムでの取引シーケンス例、（ｂ）は本実施の形態のシステムでの取引シーケンス例を示す図である。 本実施の形態での推定のメカニズムについて説明するための説明図である。 （ａ），（ｂ）は、本実施の形態での推定に関する例を説明するための図である。 納入回答履歴情報（品目別・時点別情報）の表における値の一例を示す図である。 図７に対応して、（ａ）は、従来システムでの納入要求−納入回答の例を示し、（ｂ）は、本システムでの納入要求−納入回答の例を示す図である。 第２推定機能による第２ロジックの概要及び例を説明するための図である。 図３の推定装置の基本処理フローを示す図である。 入力情報のデータ例を示す図である。 第１推定部の第１推定処理フローを示す図である。 第１推定処理における時点別・納入日別情報の表を示す図である。 第２推定部の第２推定処理フローを示す図である。 第２推定処理における時点別・納入日別情報の表を示す図である。 推定装置によりユーザに対して表示する画面例である推定納入回答情報の表示画面を示す図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。本実施の形態は、図１〜図３等に示すシステム構成を有し、各要素間で図４（ｂ）のようなシーケンスで情報を授受する。本システムでは、図５〜図９等で説明する概念で推定を行う。本システムでは、図１０〜図１５等で示す処理を行う。本システムでは、図１６のような画面を表示する。

従来のバイヤ−サプライヤ間の部品取引システムでは、最新の取引情報（バイヤからの納入要求（部品所要数）情報と、それに対するサプライヤからの納入回答（部品供給可能数）情報など）しか保持していない。一方、本実施の形態のシステムでは、従来の部品取引システム（取引情報表示機能２０）に、取引履歴情報をＤＢ５０に管理する機能（取引履歴管理機能２１）を追加した構成とする（図２）。そして本システムは、図１で示すように、当該ＤＢ５０（取引履歴情報）及び工程ＬＴ情報などを用いて、所定の方式・ロジックで、サプライヤの部品の供給能力（供給可否、供給可能数など）を推定する処理を行う推定機能（第１推定機能１１、第２推定機能１２）を提供する。

［システム（１）］
図１において、一実施の形態のシステム（部品取引システム及びサプライヤ供給能力推定システムを含んで成る）の全体の構成例を示している。本システム全体は、通信網上で、バイヤ（バイヤ端末・システム）１、サプライヤ（サプライヤ端末・システム）２、生産計画者（生産計画者端末・システム）３、部品取引システム１０、サプライヤ部品供給能力推定システム１００（推定システム／推定装置と略す）、及び生産管理・ＭＲＰ等システム３０、等が接続される構成である。バイヤ１−サプライヤ２間の部品取引システム１０（後述の図２、前提技術、基本部分）に、新たに、サプライヤ部品供給能力推定システム１００が追加接続され連携する構成である。なお推定システム１００は、部品取引システム１０の一部として実装されてもよい。

バイヤ（バイヤ端末・システム）１は、バイヤ担当者Ｕ１が使用する端末やシステムであり、部品の発注（購入）などの業務用である。サプライヤ（サプライヤ端末・システム）２は、サプライヤ担当者Ｕ２が使用する端末やシステムであり、部品の受注（販売）などの業務用である。生産計画者（生産計画者端末・システム）３は、生産計画者Ｕ０が使用する端末やシステムであり、製品の生産計画などの業務用である。

生産管理・ＭＲＰ等システム３０は、生産計画者３やバイヤ１がアクセスして利用する生産管理システムやＭＲＰシステム等である。生産管理やＭＲＰ（資材計画）は公知技術である。生産管理・ＭＲＰ等システム３０は、製品の生産計画に係わる、製品を製造（構成）する部品の所要数量や納期などの情報が登録・表示される。

部品取引システム１０は、取引情報表示機能２０と、取引履歴管理機能２１とを有する。取引情報表示機能２０は、バイヤ１（Ｕ１）による取引情報（納入要求など）の登録・表示、及びサプライヤ２（Ｕ２）による取引情報（納入回答など）の登録・表示の処理を行う。取引履歴管理機能２１は、取引情報表示機能２０が処理する取引情報を、すべて、取引履歴情報としてＤＢ（５０）に格納し管理する。

推定システム１００は、第１推定機能１１、第２推定機能１２を有する（詳細は後述）。推定機能（１１，１２）は、過去のバイヤ１の納入要求（ａ３）に対するサプライヤ２の納入回答（ａ５）の情報を含むＤＢ（取引履歴情報）を用いて、サプライヤ２の部品供給能力（供給可否や供給可能数など）を推定する処理を行う機能である。

データ情報授受例として、ａ１は、生産計画者３（Ｕ０）によるＭＰＲ等（３０）に対する生産計画変更（変更情報登録など）を示す。ａ２は、ａ１に応じた部品所要数などの情報を示す。例えばバイヤ１（Ｕ１）はＭＰＲ等システム（３０）からａ２情報を取得する（あるいは自動的な通知など）。ａ３は、バイヤ１（Ｕ１）から部品取引システム１０（取引情報表示機能２０）への部品納入要求（ａ２に応じた部品所要数を含む）の情報の登録を示す。

以下ａ４〜ａ８は従来（推定無し）の場合の情報である。ａ４は、ａ３に対応した同様情報である。例えばサプライヤ２（Ｕ２）は部品取引システム１０（取引情報表示機能２０）からａ４の部品納入要求（部品所要数を含む）の情報を取得する（あるいは自動的な通知など）。ａ５は、サプライヤ２（Ｕ２）から部品取引システム１０（取引情報表示機能２０）への、ａ３（ａ４）の情報に対するサプライヤ２（Ｕ２）の部品納入回答（部品供給可能数などを含む）の情報の登録を示す。ａ６は、ａ５に対応した同様情報である。例えばバイヤ１（Ｕ１）は部品取引システム１０（取引情報表示機能２０）からａ６の部品納入回答（部品供給可能数を含む）の情報を取得する（あるいは自動的な通知など）。ａ７は、ａ６に対応した、部品供給可能数などの情報を示す。例えばバイヤ１（Ｕ１）はＭＰＲ等システム（３０）へａ７情報を登録する。ａ８は、ａ７に対応した同様情報である。例えば生産計画者３（Ｕ０）はＭＰＲ等システム（３０）からａ８情報を取得する（あるいは自動的な通知など）。

以下ｂ１〜ｂ４は本システムで独自の情報である。ｂ１は、ａ３の納入要求（部品所要数を含む）に応じた、部品取引システム１０から推定装置１００への連携による推定指示（入力）を示す。これにより推定装置１００（１１，１２）はサプライヤ部品供給能力（供給可否、供給可能数など）の推定処理を行う。ｂ２は、推定装置１００から部品取引システム１０へ連携される、ｂ１に対する推定結果（出力）の情報である。ｂ３は、ｂ２に対応した、部品取引システム１０からバイヤ１（Ｕ１）への、推定結果を含む情報（特に画面情報）である。同様にｂ４は、ｂ３に対応した、バイヤ１から生産計画者３（Ｕ０）への、推定結果を含む情報である。

［システム（２）］
図２は、本実施の形態のバイヤ１−サプライヤ２間の部品取引システム１０の構成例を示し、前提技術（公知技術）のシステム例である部品取引システム１０（需給調整支援サービス等）に、新たに取引履歴管理機能２１（及びＤＢ５０）や推定装置１００との連携機能などを追加した構成例を示す。部品取引システム１０は、バイヤ端末・システム１（複数可）及びサプライヤ端末・システム２（複数可）と、インターネット９上でＳＳＬなどのセキュア通信で接続される。また部品取引システム１０は、Ｗｅｂ−ＥＤＩサービス８などと連携し、注文、買掛情報などを入出力する。

例えば、バイヤ１から部品取引システム１０の取引情報表示機能２０にアクセスし、表示画面にて、部品納入要求（ａ３）を登録する。また、サプライヤ２から、部品取引システム１０の取引情報表示機能２０にアクセスし、表示画面にて、部品納入要求（ａ３）などを確認し、それに対する部品納入回答（ａ５）を登録する。そして、バイヤ１から部品取引システム１０の取引情報表示機能２０にアクセスし、表示画面にて、部品納入回答（ａ５）の情報を確認する。取引履歴管理機能２１は、上記各取引情報をＤＢ５０に取引履歴情報として格納する。

前提システムでは、部品のバイヤ１（複数）−サプライヤ２（複数）間を含むＳＣＭに係わる企業間の情報共有のサービス、及び複数企業間に跨る納期調整業務（発注業務−受注業務）を支援するサービスを、Ｗｅｂインタフェース、ＳａａＳ形態などで提供する。バイヤ１−サプライヤ２間で、品目（部品）ごとの所要計画、注残、納期回答、着荷・検査、在庫など、ＳＣＭに係わる一連の情報を組み合わせ、納入・在庫状況などを時系列で情報共有できる。日々変動する需給調整上の状況及び問題点について、例えば在庫過不足・納入遅延のアラートとして、Ｗｅｂ画面表示やメール通知を行う。これにより、例えばバイヤ１（Ｕ１）は、問題の早期検知により、事前調整・解決が可能となり、サプライヤ２（Ｕ２）へのフォローアップ作業を削減できる。例えばサプライヤ２（Ｕ２）は、複数のバイヤ１（Ｕ１）の案件を一覧形式で参照して確認可能であり、アラート件数一覧表示機能などにより、問題点も明らかになるため、解決すべき案件の特定が早期に可能である。バイヤ１は、サプライヤ２からの問合せの削減と精度の高い納期回答により、納期調整時間短縮（工数削減）などが可能である。

バイヤ１は、例えば企業の基幹システム及びＤＢなどで構成される。バイヤ１では、調達部門、製造部門、着荷部門などの人（ユーザ）が各端末装置などからアクセスする。ＤＢには、所要計画、注残一覧、納期回答、着荷・検査、在庫・消費計画、在庫入出庫、などの情報が管理される。

サプライヤ２は、例えば企業の基幹システム及びＤＢなどで構成される。サプライヤ２では、製造部門、営業部門、出荷部門などの人（ユーザ）が各端末装置などからアクセスする。

部品取引システム１０は、図示しないサーバ、ＤＢ、ＬＡＮ等で構成され、システム連携インタフェース（推定装置１００との連携機能を含む）、Ｗｅｂインタフェース（Ｗｅｂページ画面提供）、ヘルプデスク等の諸機能を含む、取引情報表示機能２０、及び取引履歴管理機能２１を備える。例えば各国語のＷｅｂインタフェースで、所要注残受払、注残一覧、納期回答、納品書発行、アラート件数一覧、出荷通知、などの情報（少なくとも納入要求情報及び納入回答情報を含む）を表示する。

なおバイヤ１及びサプライヤ２が相手に開示する情報の種類については各自設定可能である。

［システム（３）］
図３は、推定装置１００の構成例として、１つのサーバ装置などで構成する場合を示す。推定装置１００は、制御部１１０、演算部１２０、記憶部１３０、通信Ｉ/Ｆ装置１４０、入力装置１５０、出力装置１６０、及びバスなどで構成される。制御部１１０、演算部１２０は、ＣＰＵ及び主メモリ等によるソフトウェアプログラム処理などで構成される。記憶部１３０は、二次記憶装置及びその制御処理などで構成される。通信Ｉ/Ｆ装置１４０は、ネットワーク（９）とのインタフェース処理を行う。入力装置１５０・出力装置１６０は、例えばユーザ（設定者）による設定入力操作を可能とする、キーボードやディスプレイ等である。

制御部１１０は、詳しい処理部として、新規納入要求受付部１１１、推定納入回答表示部１１２、設定部１１３などを有する。新規納入要求受付部１１１は、部品取引システム１０を介してバイヤ１（Ｕ１）からの新規の納入要求を受付・入力する。推定納入回答表示部１１２は、演算部１２０で推定した納入回答（サプライヤ部品供給能力）の情報（特にＷｅｂページ）を、部品取引システム１０を介してバイヤ１に対し表示（送信）する。設定部１１３は、画面でユーザ入力操作による設定情報を入力する。設定情報は、例えば、工程ＬＴ情報（１３３）の内容や、推定機能（１１，１２）の設定（一方／両方の機能の使用選択や、各種詳細設定）などがある。その他、図示しないが、ＤＢ（５０）の取引履歴情報を検索して取得する機能などを備えてもよい。

演算部１２０は、詳しい処理部として、第１推定部（供給能力推定部）１２１、第２推定部（追従数生成部）１２２を有する。第１推定部１２１は第１推定機能１１を構成する。第２推定部１２２は第２推定機能１２を構成する。

記憶部１３０は、納入要求履歴情報１３１、納入回答履歴情報１３２、工程ＬＴ情報１３３、第１推定結果（推定供給能力情報）１３４、第２推定結果（追従数情報）１３５などを記憶する。納入要求履歴情報１３１、及び納入回答履歴情報１３２は、前述のＤＢ５０の取引履歴情報と対応しており、部品取引システム１０との通信及びＤＢ５０からの検索などにより取得可能である。なお推定装置１００側にＤＢ５０（及び取引履歴管理機能２１）を設ける構成としてもよい。

［シーケンス］
図４は、生産計画者３（Ｕ０）、バイヤ１（Ｕ１）、及びサプライヤ２（Ｕ２）等における情報授受のシーケンス例を示す。図４（ａ）は従来システム例の場合、図４（ｂ）は本実施の形態のシステムの場合である（ｓ１，Ｓ１等はステップを示す）。

（ｓ１）まず図４（ａ）において、生産計画者Ｕ０は、生産管理・ＭＲＰ等システム３０に対し、製品の生産計画の変更の情報を登録する。

（ｓ２）生産管理・ＭＲＰ等システム３０から、バイヤ１の担当者Ｕ１へ、製品の生産計画の変更（ｓ１）に応じた部品所要数などの情報を伝える。あるいは担当者Ｕ１が生産管理・ＭＲＰ等システム３０へアクセスして当該情報を参照する。

（ｓ３）バイヤ１の担当者Ｕ１は、上記部品所要数などの情報（ｓ２）をもとに、従来の部品取引システムを介して、サプライヤ２（担当者Ｕ２）へ、納入要求（部品所要数を含む）を伝える。

（ｓ４）サプライヤ２の担当者Ｕ２は、上記要求（ｓ３）を受けて確認・検討し、納入回答を作成する。この際、相応の時間（例えば１，２日）を要する。

（ｓ５）サプライヤ２の担当者Ｕ２は、上記作成した納入回答（部品供給可能数を含む）を、部品取引システム等を介して、バイヤ１（担当者Ｕ１）へ伝える。あるいはバイヤ１の担当者Ｕ１が部品取引システムへアクセスし当該情報を参照する。

（ｓ６）バイヤ１の担当者Ｕ１は、上記回答（ｓ５）をもとに、部品供給可能数などの情報を、生産管理・ＭＲＰ等システム３０を介して、生産計画者３（Ｕ０）へ伝える。

（ｓ７）生産計画者３（Ｕ０）は、上記部品供給可能数などの情報（ｓ６）をもとに、生産計画の調整を確定する。

（Ｓ１）次に図４（ｂ）において、生産計画者３（Ｕ０）は、生産管理・ＭＲＰ等システム３０に対し、製品の生産計画の変更の情報を登録する（ｓ１と同じ）。

（Ｓ２）生産管理・ＭＲＰ等システム３０から、バイヤ１の担当者Ｕ１へ、製品の生産計画の変更（Ｓ１）に応じた部品所要数などの情報を伝える。あるいは担当者Ｕ１が生産管理・ＭＲＰ等システム３０へアクセスして当該情報を参照する（ｓ２と同じ）。

例えばバイヤ１の担当者Ｕ１は、上記部品所要数などの情報（Ｓ２）をもとに、本システム（１０，１００）に対し、サプライヤ供給能力の推定を要求する。

２０１に示すステップでは、Ｓ２を受けて、推定装置１００は、ＤＢ５０の取引履歴情報（過去の納入要求、及び納入回答など）を用いて、第１推定機能１１、第２推定機能１２により、サプライヤ供給能力（供給可能数など）を推定する処理を行う。推定結果情報は、第１推定結果１３４、第２推定結果１３５として記憶する。

（Ｓ３） そして本システム（１０，１００）は、上記２０１のサプライヤ供給能力の推定結果情報（１３４，１３５）を、取引情報表示機能２０（推定納入回答表示部１１２）を用いて、バイヤ１（Ｕ１）に対して提示する。バイヤ１の担当者Ｕ１は、上記推定結果のサプライヤ供給能力（供給可能数など）に応じて、生産計画者３（Ｕ０）に対し、生産計画調整の依頼が可能である。あるいは、直接、生産計画者３（Ｕ０）に対して生産計画調整の依頼が可能である。

（Ｓ４）生産計画者３（Ｕ０）は、Ｓ３の情報に応じて、生産計画調整の実行（確定）が可能である。

上記Ｓ３，Ｓ４への処理ルートの場合、バイヤ１がサプライヤ２の回答を待つ時間が省略されるので、図４（ａ）に比べて２０３のように生産計画調整時間を短縮できる。

なお上記処理ルートではなく、２０２のように従来調整ルート（図４（ａ）と同様）を使い分け可能である。例えば、バイヤ１の担当者Ｕ１は納入要求（数量）の変動が大きいと判断した場合、２０２の従来調整ルートでサプライヤ２の担当者Ｕ２へ問い合わせ、回答を待って調整可能である。

［推定機能（１）］
以下図５等を用いて、本システムでの推定のメカニズム（考え方）等について説明する。そのために図５ではサプライヤ２及びバイヤ１の各拠点や工程ＬＴ（リードタイム）、バイヤ１への納入までの時間（Ｔ）などを模式的に示している。図５上側で、右側（５１１，５１２）はバイヤ１側であり、中央（５２１，５２２）はサプライヤ２側であり、左側（５３０）はサプライヤ２へ部品製造のための原材料（マテリアル）を提供する他サプライヤである。５１１はバイヤ１側の工場（倉庫）、及びそこに着荷（納入）する部品を示す。５１２は、５１１の部品を用いた生産（ＣＡＭ／ＣＥＦ／ＲＳＤ生産等）を示す。５２１は、サプライヤ２の工場（倉庫）へ着荷するマテリアル及びその在庫を示す。５２２は、サプライヤ２の工場で５２１のマテリアルから製造される部品及びその倉庫・在庫を示す。

Ｃ１，Ｃ２，Ｃ３は、サプライヤ２における各種の工程ＬＴを示す。Ｃ１は、サプライヤ２が他サプライヤ（５３０）からマテリアルを調達しマテリアル在庫（５２１，Ｂ１）に格納するまでのマテリアル調達ＬＴである（例えば５ｗ（５週））。Ｃ２は、サプライヤ２がマテリアル在庫（５２１）のマテリアルから部品を製造して部品在庫（５２２）に格納するまでの部品製造ＬＴである（例えば４ｗ）。Ｃ３は、サプライヤ２の部品在庫（５２２）の部品をバイヤ１側工場（５１１）へ輸送し着荷するまでの部品輸送ＬＴである（例えば４ｗ）。

図５下側には、上側の工程ＬＴ（Ｃ１，Ｃ２，Ｃ３）等に対応して、横軸左方向（時間を遡る方向）にバイヤ１側（５１１）への部品の着荷（納入）までの時間Ｔ（単位：ｗ（週））をとり、縦軸に部品の在庫等（Ｂ１，Ｂ２，Ａ１，Ａ２，Ａ３）の数量をとったグラフを示している。バイヤ１側（５１１）に部品が着荷した時点（納入日）を基準（０ｗ）として例えば１ｗ単位で考える。

Ｂ１は、５２１に対応したサプライヤ２側工場でのマテリアル在庫を示す。Ｂ２は、５２２に対応したサプライヤ２側工場での部品在庫を示す。Ａ１は、他サプライヤ（５３０）からサプライヤ２側（５２１）へのマテリアル調達ＬＴ（Ｃ１）に応じた１ｗごとの注残を示す。Ａ２は、サプライヤ２工場におけるマテリアル在庫Ｂ１（５２１）から部品在庫Ｂ２（５２２）への部品製造ＬＴ（Ｃ２）に応じた１ｗごとの仕掛を示す。Ａ３は、サプライヤ２側の部品在庫Ｂ２（５２２）からバイヤ１側（５２１）までの部品輸送ＬＴ（Ｃ３）に応じた１ｗごとの輸送中在庫を示す。

本実施の形態で、サプライヤ２の部品供給能力は、サプライヤ２のマテリアル在庫Ｂ１、部品在庫Ｂ２、輸送中在庫Ａ３、仕掛Ａ２、及び注残Ａ１の５つの要素の数量がそれぞれどれだけあるかによって以下のように推定することができる。

まずこれらの５つの要素の値（情報）を、バイヤ１が高頻度かつ正確（高精度）に把握することができる場合には、本システムの推定機能によって推定するまでもなく、サプライヤ供給能力を算出（把握）可能である。しかし従来システムでは、そのような高精度の把握はできない。例えばサプライヤ２からバイヤ１へ、サプライヤ２が管理している一部の情報しか開示されない場合である。

本発明（実施の形態）のシステムでは、上記のようにサプライヤ情報の高精度の把握（多くの情報の取得）はできない状況（環境）であっても、取引履歴管理機能２１及び推定機能（１１，１２）により、サプライヤ供給能力を算出（推定）できるという特徴を有する。即ち本システムでは、取引履歴管理機能２１などを用いつつ、ある程度までサプライヤ情報（推定に利用可能な情報である納入回答履歴１３２や工程ＬＴ情報１３３）を取得・把握する。それと共に、当該サプライヤ情報に基づき、上記５つの要素（Ａ１〜Ａ３，Ｂ１，Ｂ２）の値を推定し、当該推定値などを用いて、サプライヤ部品供給能力（供給可否、供給可能数など）を算出（推定）する。

本システムで推定に利用する情報として、少なくとも、過去の取引履歴情報（時点別の納入要求及び納入回答情報）（１３１，１３２）、工程ＬＴ情報（Ｃ１，Ｃ２，Ｃ３）（１３３）がある。最新の在庫数、最新の仕掛数、最新の注残数などの情報は得られなくてもよい。

［推定機能（２）］
本システムの推定機能（１１，１２）では、サプライヤ２の｛マテリアル在庫Ｂ１，部品在庫Ｂ２，注残Ａ１，仕掛Ａ２，輸送中在庫Ａ３｝を下記の方式により推定する。

第１方式（第１推定機能１１による）として、過去、サプライヤ２が、バイヤ１の納入要求（部品所要数など）（ａ３）に対してどのように納入回答（部品供給可能数など）（ａ５）していたかという実績（納入回答履歴）によって、対象として輸送中在庫Ａ３，仕掛Ａ２，及び注残Ａ１の要素の数量を推定する。この推定は、サプライヤ２が納入回答に基づいて調達・生産しているという仮定の下で行われる。

第２方式（第２推定機能１２による）として、過去、サプライヤ２が、バイヤ１の納入要求の変更（例えば部品所要数の増加）に対してどれだけ納入回答（部品供給可能数）で追従（対応）できていたかという実績によって、対象としてマテリアル在庫Ｂ１，及び部品在庫Ｂ２の要素の数量を推定する。

前述の従来システム例では、取引情報表示機能２０相当で表示する最新の取引情報しか保持しておらず、本実施の形態のような取引履歴管理機能２１や推定機能は無い。本実施の形態のシステムでは、取引履歴管理機能２１を用いて最新及び過去の取引情報（納入要求・納入回答を含む）を取引履歴情報ＤＢ５０として蓄積する。この取引履歴情報を用いて、過去の各時点別にどれだけの納入要求・納入回答があったか及びその数量値などについて時間的に遡及して把握が可能である。

そして本システムでは、上記要素（Ａ１〜Ａ３，Ｂ１，Ｂ２）の推定値に基づき、サプライヤ２の部品供給能力を下記のロジックにより推定する。

第１ロジック（第１推定機能１１による）として、図５の基準日時（Ｔ＝０）からサプライヤ２の工程ＬＴ（Ｃ１，Ｃ２，Ｃ３）の時間分をオフセット（遡及）した過去の時点の納入回答情報（１３２）を参照し、この納入回答情報から、輸送中在庫Ａ３，仕掛Ａ２，注残Ａ１に基づく供給能力を推定する。遡及の方向で考えると、Ａ３，Ａ２，Ａ１の順である。

第２ロジック（第２推定機能１２による）として、バイヤ１の納入要求の部品所要数の増分に対するサプライヤ２の納入回答の部品供給可能数の追従の数量（追従数）を算出し、当該追従数から、マテリアル在庫Ｂ１，部品在庫Ｂ２に基づく供給能力を推定する。

［推定機能（３）］
図６を用いて上記方式・ロジックによる推定に関する例を示す。図６（ａ），（ｂ）は、図５中に示したのと同様の時間Ｔと数量のグラフである。

（１−１） 図６（ｂ）で、第１推定機能１１に関する第１の例として、バイヤ１側への着荷までの時間Ｔが３ｗである６１１の箇所の輸送中在庫Ａ３の数量を考えてみる。６１１の箇所（３ｗ）は、サプライヤ２側の部品在庫Ｂ２からの出荷時点（４ｗ）からみて１ｗ後であり、バイヤ１側への着荷までにあと３ｗかかる。ここで、６１１のＡ３の数量は、バイヤ１側が現時点から１週間前に提示した納入要求における４週間（Ｃ３＝４ｗ）後の納入要求数量（４週間後に必要な部品の数量）により生成された数量であると考えられる。この６１１の分は既に輸送中であるため、増やすことも減らすこともできない。

（１−２） 第２の例として、Ｔが７ｗである６１２の箇所の仕掛Ａ２の数量を考えてみる。６１２の箇所（７ｗ）は、サプライヤ２側のマテリアル在庫Ｂ１の時点（８ｗ）からみて１ｗ後であり、製造により部品在庫Ｂ２となるまでにあと３ｗかかる。ここで、６１２のＡ２の数量は、上記（１−１）と同様に、バイヤ１側が現時点から１週間前に提示した納入要求における８週間（Ｃ２（４ｗ）＋Ｃ３（４ｗ）＝８ｗ）後の納入要求数量（８週間後に必要な部品の数量）により生成されたと考えられる。この６１２の分は既に製造中であるため、部品在庫Ｂ２になるまで増やすことも減らすこともできない。

注残Ａ１についても同様の考え方ができる。

（２−１） 第２推定機能１２に関する第１の例として、Ｔが４ｗである６２１の箇所の部品在庫Ｂ２の数量を考えてみる。例えばバイヤ１が７週間後の納入要求数量を増加させようと思った場合、サプライヤ２側は、上記（１−２）の論理（７ｗ（６１２）の分は製造中）に基づき、増やすことも減らすこともできないが、部品在庫Ｂ２（特に予備在庫）が十分に存在する場合はそれを利用することで当該増加に対応（追従）が可能である。６２１で指し示す数量は、部品在庫Ｂ２全体（図６（ａ）のＢ２の数量）のうちの上記増加（追従）に利用できる分を示す。

また上記（２−１）と同様の考え方で、変更できない注残Ａ１についても、６２２で示すマテリアル在庫Ｂ１の余裕分を用いて増加の要求に対応（追従）が可能である。

［第１ロジック］
図７，図８を用いて、第１推定機能１１による第１ロジックの概要及び例を説明する。図７は、時点別・納入日別納入回答履歴情報１３２の表における値の一例を示す。なおこの表（時点別・納入日別情報）は第１推定機能１１による第１推定処理の際に作成される。ItemCDは、部品の識別情報（例えばP001）を示す。BaseDateは、基準となる日時（時点）を示し、下方向に時系列（ここでは１ｗ単位）で並んでいる。例えば現時点が2011/2/28であり、このレコードより前（2/21）までは値（履歴）有りであり、以降は値が未格納である。BaseDate（時点）に対し、右方向には、納入日（図５のバイヤ１側（５１１）に部品が着荷（納入）する日（Ｔ＝０））の項目が並んでいる。BaseDate−納入日の各セルには、サプライヤ２の納入回答の中に含まれている部品供給可能数の値が格納される。例えば4/4納入日についてみると、バイヤ１の要求数量（非図示）に対するサプライヤ２の回答数量が、336→288→416→288といったように変遷している。

例えば4/4納入日（現時点2/28からは５ｗ後）について、７０１のように基準として考えたとき、そこから図５の製造ＬＴ（Ｃ２＝４ｗ）＋輸送ＬＴ（Ｃ３＝４ｗ）分である８ｗ前の時点である2/7の日（７０３）に、バイヤ１からサプライヤ２に提示していた納入要求に対するサプライヤ２の納入回答の数量＝416である。この値416が、2/28時点までのサプライヤ２の部品供給能力（７１１）であると考えること（推定）ができる。また同様に、輸送ＬＴ（Ｃ３＝４ｗ）分である４ｗ前の時点である3/7の日（７０２）に、バイヤ１からサプライヤ２に提示していた納入要求に対するサプライヤ２の納入回答の数量が288であれば、この値288が2/28以降4/4までのサプライヤ供給能力（７１２）であると考えること（推定）ができる。

図８（ａ）は、図７の表に対応して、従来システムにおける、納入要求（図４（ａ）のｓ３）−納入回答（ｓ４，ｓ５）の例である。現時点が2011/2/28とする。バイヤ１（Ｕ１）がサプライヤ２（Ｕ２）に対し、納入要求（ｓ３）で、「4/4納入日の要求（所要部品数）を288→416に増加可能かどうか」を問い合わせしている。それに対し、サプライヤ２（Ｕ２）が、「生産ラインに確認必要」と一旦回答し、正式には後日具体的な供給可否や供給可能数などが納入回答（ｓ５）される。

図８（ｂ）は、図７の表に対応して、本実施の形態のシステムにおける、納入要求（図４（ｂ）のＳ２）−納入回答（Ｓ３）の例である。現時点が2011/2/28とする。バイヤ１の担当者Ｕ１が部品取引システム１０の推定装置１００に対し、納入要求（Ｓ２）で、「4/4納入日の要求（所要部品数）を288→416に増加可能かどうか」と要求している。なお単に所要部品数＝416として納入要求することで自動的に推定を実行する形としてもよいし、ユーザ（Ｕ１）により別途推定指示入力を行う形としてもよい。上記納入要求（Ｓ２）に対し、推定装置１００は、第１推定機能１１による推定処理の実行により、推定結果である推定納入回答（Ｓ３）として、｛供給能力：供給可，供給可能数＝416｝（4/4から８ｗ前の2/7時点の納入回答が416だったので当該数量は既に製造中という理由から当該288→416の増加は可能と推定される）といったように回答している。これは、図７のようにサプライヤ２の工程ＬＴ（Ｃ３，Ｃ２）分を考慮して遡及した過去の2/7時点の回答の値＝416に基づき、当該数量分は既に製造中のはずなので、このように推定できるということである。

このように、第１ロジックでは、基準時点（納入日）からサプライヤ２の工程ＬＴ（Ｃ１〜Ｃ３）分をオフセットした過去の時点の納入回答の数量から、Ａ１〜Ａ３に基づく供給能力（供給可否、供給可能数など）を推定する。

遡及する範囲（工程階層）は、Ｃ３まで、Ｃ２まで、Ｃ１まで、といったように選択可能である。

［第２ロジック］
図９を用いて、第２推定機能１２による第２ロジックの概要及び例を説明する。図９（ａ）は、納入回答履歴情報１３２の表（時点別情報）における値の一例を示す。対応して、図９（ｂ）は、納入要求履歴情報１３１の表（時点別情報）における値の一例を示す。なお品目が部品P001の場合とする。

例えば前述の第１ロジック（第１推定機能１１）によるサプライヤ供給能力（部品供給可能数）を超える納入要求（所要部品数）の増加の場合については、第２ロジック（第２推定機能１２）での推定数量（追従数）を用いる。追従数は、バイヤ１の過去の納入要求（所要部品数）の増加分に対して、サプライヤ２の実際の納入回答（供給可能数）がどこまで追従できていたかについての統計値を工程別に算出することにより求める。工程とは、図５の輸送工程（Ｃ３対応）や製造工程（Ｃ２対応）である。

例えば図９（ｂ）の納入要求履歴（１３１）で、バイヤ１は、納入日4/4の数量に関して、2011/2/7時点の要求数量＝416から、2/14時点の要求数量＝480へ、＋64で、増加要求している。これに対し、図９（ａ）の納入回答履歴（１３２）で、サプライヤ２は、納入日4/4の数量に関して、2/7時点の回答数量＝416から、2/14時点の回答数量＝448へ、＋32まで、増加で対応（追従）している。これは、前述のように在庫（Ｂ２）の余裕分を利用して対応していると推定される。なお図９（ａ）で、時点4/4と3/7との間の輸送工程＝３ｗであり、時点3/7と2/7との間の製造工程＝３ｗである。

この場合、2/7−2/14間での追従数は、＋64に対する＋32である。率で言うと５０％である。したがって、第２推定機能１２では、2/7−2/14間に限らず、その後の日時においても、同様の追従数（＋32）（５０％）の範囲内でサプライヤ２が追従して納入回答する可能性が高いと推定できる。

［基本処理］
図１０は、図３の推定装置１００の基本処理フローを示す。

（Ｓ１０１） 新規納入要求受付部１１１は、図４のＳ２のように、バイヤ１（Ｕ１）の新規納入要求（部品所要数など）を受け付け、入力する。また新規納入要求受付部１１１は、推定機能（１１，１２）に対する推定指示を入力する。ここでは、新規納入要求をそのまま推定指示として捉えて自動的に推定処理を実行する形とするが、ユーザ（Ｕ１）が別途推定指示を入力する形としてもよい。なお新規納入要求情報は、納入要求履歴１３１の一部として格納される。

（Ｓ１０２） Ｓ１０１の情報を受け、演算部１２０で推定処理を実行する。本実施の形態では、第１推定機能１１と第２推定機能１２の両方を使用するが、一方のみとしてもよい。

第１推定部１２１は、前述の第１ロジックによる第１推定処理を行い、サプライヤ供給能力（推定納入回答）を算出する。第１推定部１２１は、取引履歴情報ＤＢ５０のうちの納入要求履歴（１３１）及び納入回答履歴（１３２）と、工程ＬＴ情報１３３とを参照し、前述のように、サプライヤ２の工程ＬＴ分をオフセットした過去の時点の納入回答の数量から、Ａ１〜Ａ３に基づく供給能力（部品供給可能数、供給可否）を算出する。

第２推定部１２２は、前述の第２ロジックによる第２推定処理を行い、サプライヤ供給能力（推定納入回答）（特に追従数）を算出する。第２推定部１２２は、取引履歴情報ＤＢ５０のうちの納入要求履歴（１３１）及び納入回答履歴（１３２）と、工程ＬＴ情報１３３とを参照し、前述のように、バイヤ１の要求数量の増分に対するサプライヤ２の回答数量の追従数から、Ｂ１，Ｂ２に基づく供給能力（部品供給可能数、供給可否）を算出する。

（Ｓ１０３） 演算部１２０（１２１，１２２）は、Ｓ１０２の結果を、推定納入回答（部品供給可能数や供給可否などの情報を含む）として、それぞれ第１推定結果１３４、第２推定結果１３５として作成し、記憶部１３０に保存する。

（Ｓ１０４） 推定納入回答表示部１１２は、Ｓ１０３の情報（１３４，１３５）を用いて、画面表示用の推定納入回答情報（推定サプライヤ部品供給能力情報を含む）を作成し、バイヤ１等に対して送信し、表示させる（図４のＳ３相当）。これにより、バイヤ１の担当者Ｕ１や生産計画者Ｕ０は、画面でサプライヤ２の推定納入回答情報を確認することができる。

［入力情報］
図１１は、推定に用いる入力情報のデータ例を示す。（ａ）は納入要求履歴１３１の表、（ｂ）は納入回答履歴１３２の表、（ｃ）は新規納入要求の表、（ｄ）は工程ＬＴ情報１３３の表を示す。

（ａ）の納入要求履歴１３１では、サプライヤ２がC社である部品P001について、例えば納入日2011/4/4について、時点1/3，1/10，1/17，1/24ごとに、納入要求の所要部品数の値が格納されている。

（ｂ）の納入回答履歴１３２では、（ａ）の納入要求履歴１３１と同じ値が格納される場合を示している。

（ｃ）の１１０１は、ある日時の新規納入要求情報で、サプライヤ２がC社である部品P001について、例えばそれぞれの納入日2011/4/4，4/11，4/18，4/25について、納入要求の所要部品数の値が格納されている。

（ｄ）の工程ＬＴ情報１３３では、サプライヤ２がC社である部品P001や、S社である部品P001などの各部品について、「工程階層」、「工程ＬＴ」の情報を管理している。「工程階層」列の値は、例えば前述の部品輸送ＬＴ（Ｃ３），部品製造ＬＴ（Ｃ２），マテリアル調達ＬＴ（Ｃ１）などの区別を示し、「工程ＬＴ」はその時間を週（ｗ）単位などで示す。例えば工程階層＝１は部品輸送ＬＴ（Ｃ３）に対応し、工程階層＝２は部品製造ＬＴ（Ｃ２）に対応する。

［第１推定処理］
図１２は、第１推定機能（第１推定部１２１）による第１推定処理フローを示す（Ｓ１１等は処理ステップ）。なお左側の処理ステップＳ１１等に対応する記憶部１３０の処理データ情報（表）の例を右側及び別図面で示す。

（Ｓ１１） まず、第１推定部１２１は、納入回答履歴１３２より、対象の品目（部品）の時点別・納入日別の数量を取得し、処理用の表に格納する。

例えば、図１３の１３０１の品目別・時点別・納入日別情報（表）に格納する。図１１（ｂ）の１３２の表の第１〜第４行の値を、情報１３０１の表の対応列に格納する。

（Ｓ１２） １２１は、工程ＬＴ情報１３３より、当該部品の工程ＬＴの情報を工程階層別（Ｃ１，Ｃ２，Ｃ３）に取得する。

例えば、図１１（ｄ）の１３３の表の第１〜第２行の値（工程階層＝１（Ｃ３）では４ｗ，工程階層＝２（Ｃ２）では４ｗ）を取得する。

（Ｓ１３） １２１は、上記Ｓ１１，Ｓ１２の情報より、基準時点から当該部品の工程ＬＴ分だけオフセット（遡及）し、過去の時点の数量を取得する。１２１は、当該処理を同様に工程階層分実行（繰返し）する。

例えば、図１３のように、１３０１の表において、各納入日を基準とした時点から各工程ＬＴごとに遡及した時点の数量を工程階層別に取得する。例えば納入日4/4を基準として４ｗ＋４ｗ＝８ｗ遡及した時点1/31の数量＝416が納入日4/4における工程階層２の数量である。例えば納入日4/11を基準として４ｗ＋４ｗ＝８ｗ遡及した時点2/7の数量＝424が，納入日4/11における工程階層２の数量である。

（Ｓ１４） １２１は、Ｓ１３で工程階層別に取得した過去の時点の数量のうち、現時点を含む工程階層の数量を、現時点のサプライヤ供給能力（推定供給能力）として、当該情報を例えば第１推定結果１３４の一部として記憶部１３０に格納する。

例えば、図１３のように、１３０２の推定供給能力のレコードで、基準時点2/28で、各納入日（4/4，4/11，……，5/2）ごとに推定供給能力の数量値（416，416，……，無限大）を格納する。

（Ｓ１５） １２１は、上記Ｓ１４の推定供給能力情報（１３０２）と、新規納入要求（図１１（ｃ）の１１０１）とを比較し、各納入日（4/4，4/11，……，5/2）ごとに推定供給能力の数量値の小さい方（416，416，……，384）を、１３０４の推定納入回答情報のレコードに格納し、第１推定結果１３４として保存・出力する。

１２１は、上記Ｓ１１〜Ｓ１５の処理を全品目（部品）について同様に実行（繰返し）する。

［第２推定処理］
図１４は、第２推定機能（第２推定部１２２）による第２推定処理フローを示す（Ｓ２１等は処理ステップ）。なお左側の処理ステップＳ２１等に対応する記憶部１３０の処理データ情報（表）の例を右側及び別図面で示す。

（Ｓ２１） まず、第２推定部１２２は、納入要求履歴１３１及び納入回答履歴１３２より、当該部品の時点別・納入日別の数量を取得し、処理用の表に格納する。

例えば、図１５のように、図１１（ａ）の１３１、及び（ｂ）の１３２の表の第１〜第４行の値を、１５０１の品目別・時点別・納入日別情報（表）の対応列に格納する。

（Ｓ２２） １２２は、工程ＬＴ情報１３３より、当該部品の納入要求・納入回答を、工程別に分類する。

例えば、図１５のように、図１１（ｄ）の１３３の表の第１〜第２行の値（前述同様）を取得する。そして、品目別・時点別情報の表１５０１の納入日ごとの欄において、「工程」列に工程階層の値を格納し、当該工程別に、「要求」列に納入要求数量を格納し、「回答」列に対応する納入回答数量を格納する。なお「工程」＝０は在庫ポイント（Ｂ１，Ｂ２相当）を示す。

１５０１の表で、例えば、納入日4/4の数量について、「工程」＝２である基準日2/21と2/28の時点を比較してみてみると、要求数量が384から448へ増加している。これに対し、回答数量では、同じく384から448へ増加して追従している。それぞれの増加量は＋64である。同様に、「工程」＝１である基準日3/14と3/21では、要求数量が416から424へ増加し、回答数量では、同じく416から424へ増加して追従しており、増加量は＋8である。

（Ｓ２３） １２２は、工程別に、要求の数量の増加に対して回答の数量がどこまで追従できたかを示す追従数を算出する。１２２は、当該処理を同様に工程階層分実行（繰返し）する。なお算出した追従数の情報は、第２推定結果１３５の一部として保存する。

例えば、図１５のように、１５０２の追従数の表（レコード）を作成する。１５０１の表で、例えば、「工程」＝２の箇所では、2/21から2/28への増加量＝＋64であるため、１５０２の追従数に、「工程階層」＝２、「追従数」＝＋64としたレコードを格納する。同様に、１５０１の「工程」＝１の箇所では、3/14から3/21への増加量＝＋8であるため、１５０２の追従数に、「工程階層」＝１、「追従数」＝＋8としたレコードを格納する。

（Ｓ２４） １２２は、Ｓ２３の追従数（例えば１５０２）と、新規納入要求（例えば図１１（ｃ）の１１０１に基づく１５０３）とから、推定納入回答（例えば１５０４）を生成し、第２推定結果１３５として保存・出力する。たとえば，図１３に示したように時点2/28における推定納入回答（１３０４）の納入日4/4が416であったとする。時点2/28における納入日4/4は工程階層＝２であるので，追従数情報（１５０２）より品目P001のC社の工程階層２の追従数+64が、416からさらに追従可能な回答数となる。新規納入要求（１５０３）の納入日4/4の要求数は448であり、これは推定納入回答（１３０４）の416より32大きいが、追従数+64以内であるため追従可能と判断し、最終的に推定納入回答（１５０４）の納入日4/4分は448となる。

１２２は、上記Ｓ２１〜Ｓ２４の処理を全品目（部品）について同様に実行（繰返し）する。

［画面例］
図１６は、推定装置１００の推定納入回答表示部１１２の処理によりユーザ（バイヤ１の担当者Ｕ１や生産計画者Ｕ０）に対して表示する推定納入回答（推定供給能力）情報の表示画面例を示す。本画面の表示内容は、第１推定結果１３４、及び第２推定結果１３５等を用いて作成される。例えばＷｅｂページ形式で、図示するように文字やテーブルや操作用ボタンなどを表示する。本テーブル例では、項目として、品目（部品）、サプライヤ、要調整、各納入日などを有する。各納入日では、数量と各種関連情報とを表示する。関連情報としては、第１推定機能１１（第１ロジック）によりＯＫ判定の場合は、例えば青色の星印などで表示する。また第２推定機能１２（第２ロジック）によりＯＫ判定の場合は例えば緑色の星印で表示する。ＯＫ判定とは、納入要求の部品所要数（あるいは増分）の供給が可能である可能性が十分に高いという推定結果に相当する。また推定結果がＮＧ判定の場合は、例えば納入要求に対する納入回答（推定）における不足分の数量などを赤字などで強調して表示し、要調整の項目に○印を表示する。

ユーザ（Ｕ１やＵ０）は、本画面で推定納入回答情報を確認した後、ＯＫの場合は、すぐに生産計画の確定（Ｓ４）へ連携することができる。図１６の画面内に当該連携用のボタンなどを設けた構成としてもよい。また、ＮＧ（要調整：○）の場合は、従来ルートでの調整（図４の２０２）などへ移ることができる。図１６の画面内に当該調整用のボタンなどを設けた構成としてもよい。また本画面から、取引情報表示機能２０等による既存の他の情報の表示画面へ移ることもできる。

［効果等］
以上説明したように、本実施の形態によれば、例えばバイヤ１（Ｕ１）は納入要求（部品所要量など）に対するサプライヤ２の供給能力（供給可能数）を自動的に推定した結果を画面で確認することができ、サプライヤ２（Ｕ２）の納入回答を待たずにすぐに生産計画調整（確定）への連携などが可能となる。これにより生産計画調整時間の大幅な短縮（図４の２０３）などが見込める。これらの効果により、需要変動への迅速な対応による売上拡大・在庫縮小が期待できる。

なお本実施の形態では、第１推定機能１１、第２推定機能１２の両方を実装したシステムとしたが、一方のみ実装したシステムとしてもよい。

なお本システムによる推定機能（１１，１２）は、あくまで推定であるため、推定値と実際値（サプライヤ２（Ｕ２）の回答値）とでズレが生じ得るが、その取扱いに関しては例えば以下が可能である。

（１）バイヤ１−サプライヤ２間の契約（ならびに部品取引システム１０・推定装置１００を提供する事業者を含む契約）に基づき、上記推測・ズレを予め了解済みのシステム・サービスとして利用する。例えばバイヤ１側はズレの可能性を見込んだ上で部品発注や生産計画調整を行う。

（２）例えばズレの発生に応じて、バイヤ１（担当者Ｕ１）からサプライヤ２（担当者Ｕ２）へアラーム通知などで連携する。この場合、部品取引システム１０・推定装置１００にアラーム通知機能を備える。サプライヤ２（担当者Ｕ２）はアラーム通知を調整や業務改善などに役立てる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

本発明は、ＳＣＭ、生産管理、調達管理、電子商取引などのシステムに利用可能である。

１…バイヤ（端末・システム）、２…サプライヤ（端末・システム）、３…生産計画者（端末・システム）、８…Ｗｅｂ−ＥＤＩサービス、９…インターネット（ＳＳＬ）、１０…部品取引システム、１１…第１推定機能、１２…第２推定機能、２０…取引情報表示機能、２１…取引履歴管理機能、３０…生産管理・ＭＲＰ等システム、５０…ＤＢ（取引履歴情報ＤＢ）、１００…サプライヤ部品供給能力推定システム（推定装置）、１１１…新規納入要求受付部、１１２…推定納入回答表示部、１１３…設定部、１２１…第１推定部、１２２…第２推定部、１３１…納入要求履歴、１３２…納入回答履歴、１３３…工程ＬＴ情報、１３４…第１推定結果、１３５…第２推定結果。

Claims (14)

1. コンピュータを用いて通信網を介したバイヤ−サプライヤ間での部品の取引を支援する情報処理を行う供給能力推定システムであって、
   前記バイヤからの部品の所要数および当該部品が納入される納入日を含む納入要求の情報、及び前記サプライヤからの前記納入日における部品の供給可能数を含む納入回答の情報を含む、前記部品の取引の情報を時系列で取引履歴情報としてＤＢに記憶し管理する取引履歴管理機能と、
   前記バイヤの納入要求に対する前記サプライヤの納入回答に関する当該サプライヤの部品の供給能力を推定する処理を行う推定機能と、を有し、
   前記推定機能は、
   前記ＤＢから前記バイヤの納入要求に関する納入要求履歴情報を取得する処理と、
   前記ＤＢから前記サプライヤの納入回答に関する納入回答履歴情報を取得する処理と、
   前記サプライヤによる部品の提供に関する工程リードタイム情報を取得または入力する処理と、
   前記納入要求履歴情報、納入回答履歴情報、及び工程リードタイム情報を用いて、過去の納入要求の所要数に対する過去の納入回答の供給可能数を判断することにより、任意の納入日における前記サプライヤの部品の供給能力を、推定される供給可能数または供給可否の形で推定し、推定結果情報として作成し記憶する処理と、
   前記推定結果情報を含む画面をユーザに対して出力する処理と、を行うこと、を特徴とする供給能力推定システム。
2. 請求項１記載の供給能力推定システムにおいて、
   前記推定機能は、
   前記納入要求履歴情報、納入回答履歴情報、及び工程リードタイム情報を用いて、前記部品ごとに、前記バイヤへの部品の納入日を基準として工程リードタイム分を時間的に遡及した過去の時点の納入要求の所要数に対する納入回答の供給可能数を参照することにより、現在または未来の納入要求の所要数に対する納入回答の供給可能数を前記供給能力として推定する処理を行う第１の推定機能を有し、
   前記工程リードタイム情報は、サプライヤ側の輸送中在庫に関する、サプライヤからバイヤへ部品を輸送する第１の工程のリードタイムを有し、
   前記第１の推定機能は、前記バイヤへの部品の納入日を基準として前記第１の工程のリードタイム分を時間的に遡及した過去の時点の納入要求の所要数に対する納入回答の供給可能数を参照することにより、前記サプライヤ側の輸送中在庫に基づく数量値を前記供給能力として推定する処理を行うこと、を特徴とする供給能力推定システム。
3. 請求項２記載の供給能力推定システムにおいて、
   前記工程リードタイム情報は、サプライヤ側の仕掛に関する、サプライヤにおける原材料から部品を製造する第２の工程のリードタイムを有し、
   前記第１の推定機能は、前記バイヤへの部品の納入日を基準として前記第１の工程及び第２の工程のリードタイム分を時間的に遡及した過去の時点の納入要求の所要数に対する納入回答の供給可能数を参照することにより、前記サプライヤ側の輸送中在庫及び仕掛に基づく数量値を前記供給能力として推定する処理を行うこと、を特徴とする供給能力推定システム。
4. 請求項３記載の供給能力推定システムにおいて、
   前記工程リードタイム情報は、サプライヤ側の注残に関する、サプライヤへ原材料を調達する第３の工程のリードタイムを有し、
   前記第１の推定機能は、前記バイヤへの部品の納入日を基準として前記第１の工程、第２の工程、及び第３の工程のリードタイム分を時間的に遡及した過去の時点の納入要求の所要数に対する納入回答の供給可能数を参照することにより、前記サプライヤ側の輸送中在庫、仕掛、及び注残に基づく数量値を前記供給能力として推定する処理を行うこと、を特徴とする供給能力推定システム。
5. 請求項１記載の供給能力推定システムにおいて、
   前記推定機能は、
   前記納入要求履歴情報、納入回答履歴情報、及び工程リードタイム情報を用いて、前記部品ごとに、前記バイヤの過去の時点の納入要求間における所要数の変動量と、対応する前記サプライヤの過去の時点の納入回答間における供給可能数の変動量と、を参照し、当該変動に対するサプライヤ側の追従の度合いを示す指標値を算出し、当該指標値に基づき、現在または未来の納入要求の所要数に対する納入回答の供給可能数を前記供給能力として推定する処理を行う第２の推定機能を有すること、を特徴とする供給能力推定システム。
6. 請求項５記載の供給能力推定システムにおいて、
   前記第２の推定機能は、前記バイヤの過去の時点の納入要求間における所要数の増加量と、対応する前記サプライヤの過去の時点の納入回答間における供給可能数と、を参照し、前記サプライヤ側の部品在庫及び原材料在庫の余裕分に基づく対応を想定して、当該増加量に対するサプライヤ側の追従の度合いを示す指標値を算出し、当該指標値に基づき、現在または未来の納入要求の所要数に対する納入回答の供給可能数を前記供給能力として推定する処理を行うこと、を特徴とする供給能力推定システム。
7. 請求項１記載の供給能力推定システムにおいて、
   前記推定機能は、
   前記バイヤの担当者により新規に作成された前記部品の納入要求の情報を受け付ける新規納入要求受付部と、
   前記新規の納入要求の情報の入力に対する、前記推定機能による前記推定結果情報を含む、推定納入回答情報を含む画面を生成し、前記バイヤの担当者に対して表示する処理を行う推定納入回答表示部と、を有すること、を特徴とする供給能力推定システム。
8. 請求項２記載の供給能力推定システムにおいて、
   前記第１の推定機能は、
   前記納入回答履歴情報から、部品別、時点別、及び納入日別の数量値を取得する処理と、
   前記工程リードタイム情報から、上記納入日を基準として工程リードタイム分を時間的に遡及した過去の時点の納入要求の所要数に対する納入回答の供給可能数を取得する処理と、
   現時点を含む工程の数量値を現時点の推定供給能力として当該推定供給能力情報を記憶する処理と、
   上記推定供給能力情報と新規納入要求情報とを比較して小さい方の数量値を推定納入回答情報として記憶する処理と、を行うこと、を特徴とする供給能力推定システム。
9. 請求項５記載の供給能力推定システムにおいて、
   前記第２の推定機能は、
   前記納入要求履歴情報、及び納入回答履歴情報から、部品別、時点別、及び納入日別の数量値を取得する処理と、
   前記工程リードタイム情報から、上記部品の納入要求及び納入回答を工程別に分類する処理と、
   上記工程別に、前記納入要求間の変動量に対する前記納入回答間の変動量による前記指標値を算出する処理と、
   上記指標値と、新規納入要求情報の所要数とから、推定される納入回答の供給可能数を前記供給能力として推定する処理と、を行うこと、を特徴とする供給能力推定システム。
10. 請求項１記載の供給能力推定システムにおいて、
    前記推定結果情報を含む画面において、部品、サプライヤ、納入日、当該納入日の推定される供給可能数の情報を表示すること、を特徴とする供給能力推定システム。
11. 請求項１０記載の供給能力推定システムにおいて、
    前記推定結果情報を含む画面において、前記推定機能による判定結果情報を表示し、
    前記推定機能は、上記判定結果情報として、前記納入要求の所要数を、前記推定される納入回答の供給可能数で供給可能な場合はＯＫ、供給不可能な場合はＮＧと判定し、
    上記ＮＧの場合は、上記画面に要調整を示す情報を表示し、バイヤ−サプライヤ間での調整用の画面へ連携可能とすること、を特徴とする供給能力推定システム。
12. コンピュータを用いて通信網を介したバイヤ−サプライヤ間での部品の取引を支援する情報処理を行う部品取引システムに接続または内蔵される供給能力推定システムであって、
    前記部品取引システムは、
    前記バイヤからの部品の所要数および当該部品が納入される納入日を含む納入要求の情報、及び前記サプライヤからの前記納入日における部品の供給可能数を含む納入回答の情報を含む、前記部品の取引の情報を画面で登録して表示する取引情報表示機能と、
    前記取引情報表示機能による前記部品の取引の情報を時系列で取引履歴情報としてＤＢに記憶し管理する取引履歴管理機能と、を有し、
    前記供給能力推定システムは、
    前記バイヤの納入要求に対する前記サプライヤの納入回答に関する当該サプライヤの部品の供給能力を推定する処理を行う推定機能を有し、
    前記推定機能は、
    前記部品取引システムから前記バイヤの納入要求に関する納入要求履歴情報を取得する処理と、
    前記部品取引システムから前記サプライヤの納入回答に関する納入回答履歴情報を取得する処理と、
    前記サプライヤによる部品の提供に関する工程リードタイム情報を取得または入力する処理と、
    前記納入要求履歴情報、納入回答履歴情報、及び工程リードタイム情報を用いて、過去の納入要求の所要数に対する過去の納入回答の供給可能数を判断することにより、任意の納入日における前記サプライヤの部品の供給能力を、推定される供給可能数または供給可否の形で推定し、推定結果情報として作成し記憶する処理と、
    前記推定結果情報を含む画面をユーザに対して出力する処理と、を行うこと、を特徴とする供給能力推定システム。
13. コンピュータを用いて通信網を介したバイヤ−サプライヤ間での部品の取引を支援する情報処理を行う供給能力推定方法であって、
    前記バイヤからの部品の所要数および当該部品が納入される納入日を含む納入要求の情報、及び前記サプライヤからの前記納入日における部品の供給可能数を含む納入回答の情報を含む、前記部品の取引の情報を画面で登録して表示する処理ステップと、
    前記部品の取引の情報を時系列で取引履歴情報としてＤＢに記憶し管理する処理ステップと、
    前記バイヤの納入要求に対する前記サプライヤの納入回答に関する当該サプライヤの部品の供給能力を推定する処理を行う推定処理ステップと、を有し、
    前記推定処理ステップは、
    前記ＤＢから前記バイヤの納入要求に関する納入要求履歴情報を取得する処理ステップと、
    前記ＤＢから前記サプライヤの納入回答に関する納入回答履歴情報を取得する処理ステップと、
    前記サプライヤによる部品の提供に関する工程リードタイム情報を取得または入力する処理ステップと、
    前記納入要求履歴情報、納入回答履歴情報、及び工程リードタイム情報を用いて、過去の納入要求の所要数に対する過去の納入回答の供給可能数を判断することにより、任意の納入日における前記サプライヤの部品の供給能力を、推定される供給可能数または供給可否の形で推定し、推定結果情報として作成し記憶する処理ステップと、
    前記推定結果情報を含む画面をユーザに対して出力する処理ステップと、を有すること、を特徴とする供給能力推定方法。
14. 通信網を介したバイヤ−サプライヤ間での部品の取引を支援する情報処理をコンピュータに実行させる供給能力推定プログラムであって、
    前記バイヤからの部品の所要数および当該部品が納入される納入日を含む納入要求の情報、及び前記サプライヤからの前記納入日における部品の供給可能数を含む納入回答の情報を含む、前記部品の取引の情報を画面で登録して表示する処理を行わせるプログラムと、
    前記部品の取引の情報を時系列で取引履歴情報としてＤＢに記憶し管理する処理を行わせるプログラムと、
    前記バイヤの納入要求に対する前記サプライヤの納入回答に関する当該サプライヤの部品の供給能力を推定する処理を行う推定処理を行わせるプログラムと、を有し、
    前記推定処理を行わせるプログラムは、
    前記ＤＢから前記バイヤの納入要求に関する納入要求履歴情報を取得する処理と、
    前記ＤＢから前記サプライヤの納入回答に関する納入回答履歴情報を取得する処理と、
    前記サプライヤによる部品の提供に関する工程リードタイム情報を取得する処理と、
    前記納入要求履歴情報、納入回答履歴情報、及び工程リードタイム情報を用いて、過去の納入要求の所要数に対する過去の納入回答の供給可能数を判断することにより、任意の納入日における前記サプライヤの部品の供給能力を、推定される供給可能数または供給可否の形で推定し、推定結果情報として作成し記憶する処理と、
    前記推定結果情報を含む画面をユーザに対して出力する処理と、を行わせること、を特徴とする供給能力推定プログラム。

Images