(57)【要約】      【課題】  バリューチェーン内の各企業の計画を効率良く運営させる。      【解決手段】  それぞれネットワークに接続可能な端末を有した業務上関連している複数の企業と、該ネットワークを介することにより各該端末と通信可能なサーバから構築し、サーバに、複数の企業の各々から収集した、物品の取引に関する計画データを記憶する記憶手段と、該記憶された各企業の計画データに基づいて該各企業の計画データを再計画して更新する更新手段とを設け、さらに、該計画データが更新された各企業に更新した計画データを返信する機能を付与する。【選択図】      図１
2005122364.tif 000002
【特許請求の範囲】
【請求項１】
それぞれネットワークに接続可能な端末を有した業務上関連している複数の企業と、該ネットワークを介することにより各該端末と通信可能なサーバと、を有した、該複数の企業間における物品の取引に関する計画を連携させる為の取引計画連携システムであって、
前記サーバは、前記複数の企業の各々から収集した、物品の取引に関する計画データを記憶する記憶手段と、該記憶された各企業の計画データに基づいて該各企業の計画データを再計画して更新する更新手段と、を具備し、該計画データが更新された各企業に、更新した計画データを返信すること、を特徴とする取引計画連携システム。
【請求項２】
前記記憶手段は、各計画データをレコード単位で記憶すること、を特徴とする請求項１に記載の取引計画連携システム。
【請求項３】
前記計画データを示すレコードは、販売計画を示す販売計画レコードと、購入計画を示す購入計画レコードと、を含むこと、を特徴とする請求項２に記載の取引計画連携システム。
【請求項４】
前記販売計画レコード及び前記購入計画レコードは、共通のデータ構造を有すること、を特徴とする請求項３に記載の取引計画連携システム。
【請求項５】
前記販売計画レコード及び前記購入計画レコードの各々は、計画元の企業名、製品名、オーダー番号、販売先または購入先である取引先を示す企業名、数量、納期を示すフィールドを有すること、を特徴とする請求項４に記載の取引計画連携システム。
【請求項６】
各計画データには各企業を識別する企業識別コードが付与されていること、を特徴とする請求項１から請求項５のいずれかに記載の取引計画連携システム。
【請求項７】
前記サーバは、各企業間で取引される同型の物品に共通の型番を付与し、
前記記憶手段は、該共通の型番と、該同型の物品に付与された企業毎に異なる型番の各々と、それぞれ異なる各型番に対応する企業の各々と、を関連付けて記憶すること、を特徴とする請求項１から請求項６のいずれかに記載の取引計画連携システム。
【請求項８】
物品を購入する側の企業が計画データを変更した場合、サーバは、該変更された計画データに基づいて、該物品を販売する側の企業の計画データを更新すること、を特徴とする請求項１から請求項７のいずれかに記載の取引計画連携システム。
【請求項９】
前記計画データは、物品の納期に関連したデータを含み、
前記サーバは、物品を購入する側の企業が希望する納入日に基づいて、該物品を販売する側の企業の出荷納期を決定すること、を特徴とする請求項８に記載の取引計画連携システム。
【請求項１０】
前記サーバは、物品を販売する側の企業の出荷可能日に基づいて、該物品を購入する側の企業の計画データに該物品の納入予定日データを付与すること、を特徴とする請求項１から請求項９のいずれかに記載の取引計画連携システム。
【請求項１１】
前記計画データは、在庫状況、出庫状況、物品の積送状況の中の少なくとも１つのデータを含むこと、を特徴とする請求項１から請求項１０のいずれかに記載の取引計画連携システム。
【請求項１２】
業務上関連している複数の企業間における物品の取引に関する計画を連携させる為のサーバであって、
前記複数の企業と通信可能な通信手段と、
該複数の企業の各々から収集した、物品の取引に関する計画データを記憶する記憶手段と、
該記憶された各企業の計画データに基づいて該各企業の計画データを再計画して更新する更新手段と、を具備し、
該計画データが更新された各企業に、更新した計画データを返信すること、を特徴とするサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、業務上関連している複数の企業間における物品の取引に関する計画を連携させる為の取引計画連携システム及びサーバに関する。
【背景技術】
【０００２】
従来より、多くの企業が関連して、物品の販売や、購入、生産等を行っていくことにより、１つの製品が生み出されている。このように、原材料から最終製品に至までのプロセス毎に、関連する複数の企業がそれぞれに価値を創生する連鎖過程は、一般に、バリューチェーンと呼ばれている。
【０００３】
バリューチェーン内の各企業は、自社製品の生産・販売や他社製品の購入等の計画を立てる為の計画システムを独自に構築している。このようなシステムは一般に企業独自が構築したものである為、汎用性がないことが多い。すなわちこのようなシステムは自社以外では使用できず、バリューチェーン内で個々に独立して存在している。
【０００４】
なお、本願発明に関連する先行技術を記載した文献はない為、本明細書では先行技術文献の開示はない。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら従来存在する計画システムには以下の如き問題がある為、バリューチェーン内の各企業の計画は、非効率に運営せざるを得なかった。例えば、各自に計画システムを開発し構築している為、各企業は、該システムに多額のコストを費やさなければならない。また、各企業は、バリューチェーン内の企業であって、自社の業務に直接または間接的に関わっている企業のうち、直接取引を行っている企業の販売や購入の計画しか認識したりコントロールしたりすることができない。従って、バリューチェーン内のある企業でトラブルが発生した場合、そのトラブルの情報は、各企業間で、ＦＡＸ等の人手を用いた手段によってシリアルに伝達されていく。そのため、間接的な関わりしか持たない企業においてトラブルが発生した場合、各企業は、自社に関わる影響を認識する為に長時間必要としなければならない。もしくは、トラブルの情報の伝達が機能せず、各企業は、そのトラブルによる自社の影響を認識できないこともある。また、バリューチェーン内の全体的な状況を把握することが難しい為、各企業は、余剰在庫や、余裕リードタイム、余剰手配等をする傾向にある。そのため、各企業において、無駄な在庫や、リードタイムの長時間化、不必要な手配等が増加することとなり、販売や、購入、生産等の計画が、結果的に非効率なものとなっている。また、各企業において売上げや検収基準が相違している為、システム上での物品の動き（在庫状態や積送状態である等）を捕捉することができない。
【０００６】
そこで、本発明は上記の事情に鑑み、バリューチェーン内の各企業の計画を効率良く運営させる為の計画システム及びサーバを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記の課題を解決する本発明の一態様に係る取引計画連携システムは、それぞれネットワークに接続可能な端末を有した業務上関連している複数の企業と、該ネットワークを介することにより各該端末と通信可能なサーバとを有した、該複数の企業間における物品の取引に関する計画を連携させる為のシステムであり、該サーバは、複数の企業の各々から収集した、物品の取引に関する計画データを記憶する記憶手段と、該記憶された各企業の計画データに基づいて該各企業の計画データを再計画して更新する更新手段とを具備しており、該計画データが更新された各企業に、更新した計画データを返信する機能を果たす。
【０００８】
また、上記取引計画連携システムにおいて、記憶手段は各計画データをレコード単位で記憶することができる。このとき計画データを示すレコードは、販売計画を示す販売計画レコードと、購入計画を示す購入計画レコードとを含んだものであってもよい。さらに、販売計画レコード及び購入計画レコードの各々は、共通のデータ構造を有したものであってもよく、データ構造として、計画元の企業名、製品名、オーダー番号、販売先または購入先である取引先を示す企業名、数量、納期を示すフィールドを有したものであってもよい。
【０００９】
また、上記取引計画連携システムにおいて、各計画データには各企業を識別する企業識別コードが付与されていてもよい。
【００１０】
また、上記取引計画連携システムにおいて、サーバは各企業間で取引される同型の物品に共通の型番を付与し、記憶手段は、該共通の型番と、該同型の物品に付与された企業毎に異なる型番の各々と、それぞれ異なる各型番に対応する企業の各々とを関連付けて記憶することができる。
【００１１】
また、上記取引計画連携システムにおいて、物品を購入する側の企業が計画データを変更した場合、サーバは、該変更された計画データに基づいて、該物品を販売する側の企業の計画データを更新することができる。また、計画データが物品の納期に関連したデータを含んでいる場合、サーバは、物品を購入する側の企業が希望する納入日に基づいて、該物品を販売する側の企業の出荷納期を決定することができる。
【００１２】
また、上記取引計画連携システムにおいて、サーバは、物品を販売する側の企業の出荷可能日に基づいて、該物品を購入する側の企業の計画データに該物品の納入予定日データを付与することができる。
【００１３】
また、上記取引計画連携システムにおいて、計画データは、在庫状況、出庫状況、物品の積送状況の中の少なくとも１つのデータを含んでいてもよい。
【００１４】
また、上記の課題を解決する本発明の一態様に係るサーバは、業務上関連している複数の企業間における物品の取引に関する計画を連携させる為のものであり、複数の企業と通信可能な通信手段と、該複数の企業の各々から収集した、物品の取引に関する計画データを記憶する記憶手段と、該記憶された各企業の計画データに基づいて該各企業の計画データを再計画して更新する更新手段とを具備しており、該計画データが更新された各企業に、更新した計画データを返信する機能を果たす。
【発明の効果】
【００１５】
本発明の取引計画連携システム及びサーバによると、従来の如く独自に計画システムを構築する必要がない為、バリューチェーン内の各企業は、計画システムに投資していた多額のコストを大幅に削減することができる。また、各企業の状況を加味して各企業の計画を連携させて処理できる為、各企業は、直接取引を行っている企業の状況だけでなく他の企業の状況も認識しながら販売や購入の計画を立てることができる。また、各企業はバリューチェーン全体の状況を把握できる為、余剰在庫や、余裕リードタイム、余剰手配等の無駄を省いた計画を立てることができる。また、各企業間で実施される取引を連携させることによって、各企業間で異なる検収基準の相違に起因して製品の流通が一時的に不可視となるという状態がなくなり、製品の流通が常に捕捉できる。
【発明を実施するための最良の形態】
【００１６】
本発明の実施形態の取引計画連携システム及びサーバは、バリューチェーン内の各企業の計画を効率良く運営させる為のものである。これを実現させる為には、各企業の計画システムを連携させることによりチェーン内の企業を１つの企業の如く処理できるシステムを構築する必要がある。本実施形態の取引計画連携システムはこれを満たし、また、本実施形態のサーバはこのようなシステムを実現する為の機能を備えている。
【００１７】
各企業は、各社共同で使用できる本システムを採用することにより、従来の如く独自に計画システムを構築する必要がない。従って、計画システムに投資していた多額のコストを大幅に削減することができる。
【００１８】
本実施形態のサーバは、各企業から取り込んだ計画情報を収集し、これら収集した計画情報に基づいて各計画情報を適宜再計画し、これら再計画した計画情報を各企業に配信する機能を果たす。これにより、各企業は、最適化された計画情報を取得することができる。また、いずれかの企業の計画情報に変更が生じた場合、本実施形態のサーバは、各企業の計画情報に、この変更を迅速に反映させることができる。以下に図面を参照して本実施形態の取引計画連携システム及びサーバについて説明する。
【００１９】
図１は、本実施形態の取引計画連携システム５００の構成を示した構成図である。取引計画連携システム５００は、バリューチェーン内の各企業（図１の得意先Ｃ、販売会社Ａ、製造会社Ｂ、外注製造会社Ｄ、部品会社Ｅ、物流会社Ｆ）と、これら各企業とネットワークＮを介して相互通信可能に接続されたサーバ１００から構築されている。本実施形態では、サーバ１００が、上記バリューチェーン内の各企業の計画を連携させて該各企業の計画を効率良く運営させている。なお、別の実施形態では、物流会社Ｆを、例えば船会社や航空会社に置き換えることもできる。
【００２０】
製造会社Ｂはある製品を製造する会社であり、販売会社Ａは製造会社Ｂから該製品を購入し販売する会社であり、得意先Ｃは販売会社Ａで販売されている該製品を購入する会社である。また、外注製造会社Ｄは、製造会社Ｂに、委託された該製品の一部を製造し納品する会社である。また、部品会社Ｅは、該製品を構成する部品を製造し外注製造会社Ｄに納品する会社である。
【００２１】
得意先Ｃと販売会社Ａ、販売会社Ａと製造会社Ｂ、製造会社Ｂと外注製造会社Ｄ、及び外注製造会社Ｄと部品会社Ｅは、それぞれ顧客と製造元（または販売元）との関係となっている。製造元（または販売元）は、一般に、顧客の要望に合わせて製品の納期や日程等を決定している。従って、本システムのバリューチェーン内における該製品の納期や日程等は、基本的に、得意先Ｃ、販売会社Ａ、製造会社Ｂ、外注製造会社Ｄ、部品会社Ｅの順に意見が反映されて決定されていく。本明細書では、図１において最も左側に示された企業をバリューチェーン内において最も上流の企業と定義し、図１中右側に示されている企業ほど下流の企業であると定義する。すなわちここでは、得意先Ｃが最も上流の企業として位置付けられ、部品会社Ｅが最も下流の企業として位置付けられている。
【００２２】
バリューチェーン内の各企業は、先ず、関連する企業に対する製品の販売や購入等の注文計画（以下、計画オーダーとする）を立てる。図１では、得意先Ｃ、販売会社Ａ、製造会社Ｂ、外注製造会社Ｄ、部品会社Ｅは、それぞれ計画オーダーとして、計画データベースＣ１、計画データベースＡ１、計画データベースＢ１、計画データベースＤ１、計画データベースＥ１を立てている。また、確定したオーダーや実績（実際の製品の入出庫数や納期等）の情報を含んだデータベースとして、実績データベースＣ２、実績データベースＡ２、実績データベースＢ２、実績データベースＤ２、実績データベースＥ２を蓄積している。なお、図ではデータベースをＤＢと略記する。
【００２３】
また、得意先Ｃ、販売会社Ａ、製造会社Ｂ、外注製造会社Ｄ、部品会社Ｅは、ネットワークＮを介してサーバ１００と相互通信する為の送受信部（送受信部Ｃ３、送受信部Ａ３、送受信部Ｂ３、送受信部Ｄ３、送受信部Ｅ３）をそれぞれ備えている。各企業は、これらの各送受信部を使用して自社が立てた計画オーダーをサーバ１００に送信する。
【００２４】
サーバ１００は、ネットワークＮを介して各企業と相互通信する為のデータ送受信コントロール部１０と、計画コントロール部２０と、取引連携部３０と、企業間取引定義部４０を備えている。各企業が送信した各計画オーダーは、ネットワークＮ及びデータ送受信コントロール部１０を介して計画コントロール部２０に記憶される。
【００２５】
サーバ１００は、計画コントロール部２０により、各企業から取得した計画オーダーを状況に応じて適宜再計画し更新することができる。また、取引連携部３０により、各企業間で実施される取引を連携させることによって、各企業間で異なる検収基準の相違に起因して製品の流通が一時的に不可視となるという状態をなくし、製品の流通を常に捕捉できるようにしている。
【００２６】
企業間取引定義部４０は、上述した処理を実行する際に使用される各種パラメータを記憶するデータベースである。バリューチェーン内の各企業は、取引計画連携システム５００を使用するにあたり、先ず、企業間取引定義部４０に自身に関わる各種パラメータを登録する。
【００２７】
この企業間取引定義部４０には、会社データベース４１、品目データベース４２、会社間取引データベース４３、倉庫データベース４４、計画条件データベース４５、送受信条件データベース４６が記憶されている。
【００２８】
会社データベース４１には、例えば各会社の属性（例えば販売業者やメーカー等）を示したデータが記憶されている。また、品目データベース４２には、例えば、ある製品の自社に対する型番や他社に対する型番や、品目の属性（ある製品が購買品であるか製造品であるか等）を示したデータが記憶されている。また、会社間取引データベース４３には、例えば製品のリードタイム等を示したデータが記憶されている。また、倉庫データベース４４には、例えばある製品に対する搬出元の倉庫や搬入先の倉庫を示したデータが記憶されている。また、計画条件データベース４５には、例えば品目毎のリードタイムを示したデータが記憶されている。また、送受信条件データベース４６には、例えば何時に計画データ等を送受信するかという送受信時刻を示したデータが記憶されている。計画コントロール部２０及び取引連携部３０は、これらのパラメータを使用することにより処理を実行していく。
【００２９】
計画コントロール部２０は、バリューチェーン内の各企業の計画オーダーを記憶する為の複数の記憶領域を有している。本実施形態では、計画コントロール部２０は、これらの記憶領域の各々に、得意先Ｃの計画オーダーを格納した計画データベース２１、販売会社Ａの計画オーダーを格納した計画データベース２２、製造会社Ｂの計画オーダーを格納した計画データベース２３、外注製造会社Ｄの計画オーダーを格納した計画データベース２４、部品会社Ｅの計画オーダーを格納した計画データベース２５を記憶することができる。先ず、各企業が独自に立てた計画オーダーがサーバ１００に送信された段階では、上記記憶領域の各々には、計画データベースＣ１、計画データベースＡ１、計画データベースＢ１、計画データベースＤ１、計画データベースＥ１と同一内容の計画オーダーが記憶される。
【００３０】
また、計画コントロール部２０は、上述したように、これらの記憶した計画オーダーを各企業の状況に応じて適宜再計画し更新する機能を有している。図２は、計画コントロール部２０による販売会社Ａの計画オーダー（計画データベース２２に記憶されたデータベース）の再計画処理を示した図である。図２では、販売会社Ａの計画オーダーをレコードレーベルの形式で示している。以下、図２を参照して、本実施形態のサーバ１００において計画オーダーを再計画する処理について説明する。
【００３１】
図２によると、販売会社Ａは、バックオーダー（Back Order）として、顧客オーダー（Customer Order）２０１と、購入／製造オーダー（Purchase Order / Manufacturing Order）２０２を、サーバ１００に送信する。すなわち計画データベース２２には、顧客オーダー２０１と購入／製造オーダー２０２のレコードレーベルが記憶される。このとき記憶される顧客オーダー２０１は、会社識別コード（Co）が「Ａ」の会社すなわち販売会社Ａが、顧客（Customer）「Ｃ」すなわち得意先Ｃに、型番（Item）「ＸＹＺ」の製品を、５００個（Order qtyはオーダー数）販売するというオーダーである。さらに説明を加えると、このときのオーダー番号（Order No）は「Ｃ１２３４５６」であり、納期（Due Date）は「２００３年３月１日」、積送状態になっている製品数（Shipped）は４９０個であり、未確定の状態にある製品数（Open）は１０個である。また、購入／製造オーダー２０２は、販売会社Ａが、業者（Vendor）「Ｂ」すなわち製造会社Ｂから、型番「ＸＹＺ」の製品を、７００個購入するというオーダーである。このときのオーダー番号は「Ｐ１２３４５６」であり、納期は「２００３年３月１日」、受入状態になっている製品数は５００個であり、未確定の状態にある製品数は２００個である。
【００３２】
計画データベース２２には、バックオーダーに基づいてイン／アウト トランザクション（In / Out Transaction）のレコードレーベルが作成される。さらに説明すると、顧客オーダー２０１に基づいて売上げ（Sales）２１１のレコードレーベルが作成され、購入／製造オーダー２０２に基づいて購入／製造オーダー受入（Purchase Order Receipt / Manufacturing Order Receipt）２１２のレコードレーベルが作成される。売上げ２１１は、販売会社Ａが得意先Ｃに型番「ＸＹＺ」の製品を４９０個（TR Qtyは処理数）売り上げることを示している。ここで処理数（ここでは売上げる製品数）が４９０となっているのは、顧客オーダー２０１において積送状態になっている製品数（すなわち現状で販売会社Ａが得意先Ｃに販売可能となる製品数）が４９０個となっていることに起因している。なお、製品の販売を実行する日時（TR Date）は、「２００３年４月３日」となっている。また、購入／製造オーダー受入２１２は、販売会社Ａが製造会社Ｂから型番「ＸＹＺ」の製品を５００個購入することを示している。ここで処理数（ここでは購入する製品数）が５００となっているのは、購入／製造オーダー２０２において受入状態になっている製品数（すなわち現状で販売会社Ａ製造会社Ｂから購入可能となる製品数）が５００個となっていることに起因している。なお、製品の受入を実行する日時は、「２００３年４月２日」となっている。
【００３３】
次に、上述したイン／アウト トランザクションのレコードレーベルに基づいて、在庫（Inventory）２２１のレコードレーベルが作成される。在庫２２１には、販売会社Ａの情報であって、型番「ＸＹＺ」の製品に対する情報が記憶されている。この在庫２２１は、販売会社Ａが型番「ＸＹＺ」の製品を、４９０個出庫するという情報と、５００個入庫するという情報とを含み、さらに、型番「ＸＹＺ」の製品が在庫として１０個残るという情報を含んでいる。ここで出庫数が４９０となっているのは、売上げ２１１において販売可能となる製品数が４９０個となっていることに起因している。また、入庫数が５００となっているのは、購入／製造オーダー受入２１２において購入可能となる製品数が５００個となっていることに起因している。なお、在庫２２１は、予め販売会社Ａが作成してサーバ１００に送信されたものであってもよい。また、出入庫の状況が変化することもある為、在庫２２１は、日次で変更されることもあり得る。なお、その場合には、各企業からサーバ１００にその差分（変更分）のみの情報が送信されてくる。
【００３４】
計画コントロール部２０は、さらに、製造会社Ｂや得意先Ｃの状況を加味して販売会社Ａの計画オーダー（計画データベース２２）を再計画（最適化）または作成することができる。計画オーダーコントロール（Planned Order Control）２３０は、計画コントロール部２０により再計画または作成された、販売会社Ａの計画オーダーを示したものである。計画オーダーコントロール２３０には、顧客オーダー残（Customer Order Balance）２３１、購入／製造オーダー残（Purchase Order / Manufacturing Order Balance）２３２、計画売上げ（Planned Sales）２４１、計画購入／製造（Planned Purchase / Planned Manufacturing）２４２が含まれている。
【００３５】
顧客オーダー残２３１及び購入／製造オーダー残２３２は、オーダー残調整（Order Balance Adjustment）機能により作成されるレコードレーベルである。オーダー残調整とは、既オーダーと計画オーダーとのバランスを調整する機能である。ここでは、バックオーダーにより、顧客オーダー残２３１及び購入／製造オーダー残２３２が調整されている。顧客オーダー残２３１及び購入／製造オーダー残２３２では、納期が「２００３年４月１日」とされており、他のパラメータはバックオーダーと同一となっている。
【００３６】
計画売上げ２４１は、需要予測や、実績更新、オーダー残調整等に基づいて作成されるものである。計画売上げ２４１は、販売会社Ａが得意先Ｃに型番「ＸＹＺ」の製品を週次（Bucket「Ｗ」）で２００個販売するという計画である。なお、このオーダー番号は「Ｃ００００００１」であり、納期は「２００３年４月１日」である。計画売上げ２４１は、オートメーションでなく、ユーザーがマニュアルで入力することもできる。
【００３７】
計画購入／製造２４２は、販売会社Ａが製造会社Ｂから型番「ＸＹＺ」の製品を週次で３００個購入するという計画である。なお、このオーダー番号は「Ｐ００００００２」である。
【００３８】
計画コントロール部２０は、上述した計画オーダーコントロール２３０に基づいて在庫２２１のレコードレーベルを更新することができる。先ず、計画コントロール部２０は、顧客オーダー残２３１に基づいて在庫２２２のレコードレーベルを作成する。在庫２２２は、販売会社Ａが型番「ＸＹＺ」の製品を、５００個出庫するという情報と、５００個入庫するという情報とを含み、さらに、型番「ＸＹＺ」の製品が在庫として残らないという情報を含んでいる。５００個出庫するという情報は、顧客オーダー残２３１の販売のオーダー数が５００であることに起因して作成された情報である。また、在庫として残らないという情報は、在庫２２２における入出庫の製品数を単純に計算して算出した情報である。
【００３９】
次に、計画コントロール部２０は、購入／製造オーダー残２３２に基づいて在庫２２３のレコードレーベルを作成する。在庫２２３は、販売会社Ａが型番「ＸＹＺ」の製品を、５００個出庫するという情報と、７００個入庫するという情報とを含み、さらに、型番「ＸＹＺ」の製品が在庫として２００個残るという情報を含んでいる。７００個入庫するという情報は、購入／製造オーダー残２３２の購入のオーダー数が７００であることに起因して作成された情報である。また、在庫として２００個残るという情報は、在庫２２３における入出庫の製品数を単純に計算して算出した情報である。
【００４０】
さらに、計画コントロール部２０は、計画売上げ２４１に基づいて在庫２２４のレコードレーベルを作成する。在庫２２４は、販売会社Ａが型番「ＸＹＺ」の製品を、７００個出庫するという情報と、７００個入庫するという情報とを含み、さらに、型番「ＸＹＺ」の製品が在庫として残らないという情報を含んでいる。７００個出庫するという情報は、５００個出庫するという情報に、さらに計画売上げ２４１で２００個出庫するという情報を加味したことにより作成されたものである。また、在庫として残らないという情報は、在庫２２４における入出庫の製品数を単純に計算して算出した情報である。
【００４１】
最後に、計画コントロール部２０は、計画購入／製造２４２に基づいて在庫２２５のレコードレーベルを作成する。在庫２２５は、販売会社Ａが型番「ＸＹＺ」の製品を、７００個出庫するという情報と、１０００個入庫するという情報とを含み、さらに、型番「ＸＹＺ」の製品が在庫として３００個残るという情報を含んでいる。１０００個入庫するという情報は、７００個入庫するという情報に、さらに計画購入／製造２４２で３００個入庫するという情報を加味したことにより作成されたものである。また、在庫として３００個残るという情報は、在庫２２５における入出庫の製品数を単純に計算して算出した情報である。
【００４２】
在庫２２１が更新されて在庫２２５となったレコードレーベルは、実績のデータベースとして、販売会社Ａに送信される。そして送信された在庫２２５は、実績データベースＡ２に記憶される。販売会社Ａは、自身が備えるモニタ等の表示部Ａ４により実績データベースＡ２を視認することができる。
【００４３】
なお、図２では販売会社Ａのレコードレーベルは製造会社Ｂや得意先Ｃの状況を加味して作成されているが、例えば製造会社Ｂと外注製造会社Ｄとの間でも同様の連携処理が実行される為、結果的に、販売会社Ａのレコードレーベルは、バリューチェーン内の全ての企業の状況を加味して作成されているといえる。
【００４４】
計画コントロール部２０は、さらに計画連携処理部２６を備えている。計画連携処理部２６は、計画コントロール部２０に記憶された各企業の計画オーダーの連携処理を実行することができる。ここでいう連携処理とは、例えば、製品を購入する上流側の企業が希望する納入日に基づいて該製品を販売する下流側の企業の出荷納期を自動的に決定する処理（波及処理）であったり、製品を販売する下流側の企業の出荷可能日に基づいて該製品を購入する上流側の企業の計画データに該製品の納入予定日のデータを付与する処理（遡及処理）であったりする。図３は、販売会社Ａと製造会社Ｂとの間の計画を連携させる為の計画連携処理部２６による連携処理を示した図である。以下、図３を参照して、計画連携処理部２６による連携処理について説明する。
【００４５】
販売会社Ａと製造会社Ｂとの間で取引、すなわち販売会社Ａが製造会社Ｂから製品を購入する場合、計画連携処理部２６は、販売会社Ａの取引計画を含んだ計画オーダーコントロール３０１と、製造会社Ｂの取引計画を含んだ計画オーダーコントロール３１１とを用いて、会社間計画オーダーコントロール（Inter Company Planned Order Control (Cascading / Retroactive chain)）３２１により、販売会社Ａと製造会社Ｂとの計画を連携させて処理する。
【００４６】
計画オーダーコントロール３０１は、計画売上げ３０２のレコードレーベルと計画購入３０３のレコードレーベルを含んでいる。計画売上げ３０２は得意先Ｃに対する販売計画であり、計画購入３０３は製造会社Ｂに対する購入計画である。従って、販売会社Ａと製造会社Ｂとの計画を連携させて処理する際には、計画購入３０３が活用される。
【００４７】
また、計画オーダーコントロール３１１は、計画売上げ３１２のレコードレーベルと計画製造３１３のレコードレーベルを含んでいる。計画売上げ３１２は販売会社Ａに対する販売計画であり、計画生産（Planned Production）３１３は図示しない作業区（Shop）Ｌ０１に対する生産計画である。従って、販売会社Ａと製造会社Ｂとの計画を連携させて処理する際には、計画売上げ３１２が活用される。
【００４８】
また、会社間計画オーダーコントロール３２１は、カンパニーマスター（Company Master）３２２のレコードレーベルとベンダーマスター（Vendor Master）３２３のレコードレーベルを含んでいる。カンパニーマスター３２２では、販売会社Ａと製造会社Ｂとの計画を連携させることを定義している。また、ベンダーマスター３２３では、購入側である販売会社Ａが販売側である製造会社Ｂから型番「ＸＹＺ」の製品を購入し、その際に必要なリードタイム（Lead Time）が２０日間であることを定義している。これらの定義は、企業間取引定義部４０の各データベースに記憶された各種パラメータに基づいて決定されている。
【００４９】
上述したようにバリューチェーン内では基本的に上流に位置する企業の要望が優先的に採用される。この例では、先ず、販売会社Ａが当該製品の納期を決定する。計画購入３０３では、販売会社Ａは当該製品の納期を「２００２年３月２５日」に設定している。なお、計画購入３０３のオーダー数や納期は、計画売上げ３０２のオーダー数や納期に基づいて計画連携処理部２６により設定されるようにしてもよい。具体的には、計画売上げ３０２のオーダー数が３００個である為、計画連携処理部２６は、少なくとも３００個のオーダーを計画購入３０３に設定する機能を果たす。また、計画売上げ３０２の出荷の納期が「２００２年４月１日」である為、計画連携処理部２６は、少なくとも「２００２年４月１日」より前の日を計画購入３０３に設定する機能を果たす。このとき自動的に設定されるオーダー数や納期は、企業間取引定義部４０の各データベースに記憶された各種パラメータに基づいて決定される。
【００５０】
計画購入３０３内の納期が設定されると、計画連携処理部２６は、波及処理を実行する。具体的には、会社間計画オーダーコントロール３２１が有するデータを参照して、計画オーダーコントロール３１１に、計画購入３０３に対応する製造会社Ｂ側のレコードレーベルを作成する。計画購入３０３に対応するレコードレーベルは、製造会社Ｂが販売会社Ａに型番「ＸＹＺ」の製品を５００個販売するというものである。すなわち計画オーダーコントロール３１１には、計画売上げ３１２が作成される。このとき、計画連携処理部２６は、ベンダーマスター３２３で定義されたリードタイムに基づいて計画売上げ３１２内の出荷の納期を設定する。具体的には、製造会社Ｂ側の出荷の納期を「２００２年３月５日」に設定する。
【００５１】
また、計画連携処理部２６は、波及処理に対する処理であって、下流に位置する企業の状況を考慮した遡及処理を実行することもできる。具体的には、製造会社Ｂが設定した出荷の納期に基づいて、会社間計画オーダーコントロール３２１が有するデータを参照し計画購入３０３内の到着予定日（ＥＴＡ）を更新する。製造会社Ｂの出荷状況に何ら問題がない場合、計画購入３０３内の到着予定日には、計画購入３０３内の納期と同日が付与される。また、製造会社Ｂの出荷状況に何らかの問題がある（例えば生産が納期に間に合わない等）場合、計画購入３０３内の到着予定日は、計画売上げ３１２に設定された出荷の納期及びベンダーマスター３２３で定義されたリードタイムに基づいて設定される。例えば計画売上げ３１２で出荷の納期が「２００２年３月１０日」に設定された場合、計画購入３０３内の到着予定日には、「２００２年３月３０日」が設定される。
【００５２】
なお、販売会社Ａと製造会社Ｂとの計画の連携処理を実施する場合、計画連携処理部２６は、図３に示されている各レコードレーベルにおいて、取引の対象となっている当該製品に同一の型番「ＸＹＺ」を付している。サーバ１００は、企業間取引定義部４０の会社データベース４１や品目データベース４２により、型番「ＸＹＺ」と、当該製品を取引する企業の各々（すなわち販売会社Ａと製造会社Ｂ）と、該各企業が当該製品を自社で取り扱う際に使用している型番の各々とを関連付けて定義し、各種処理を実施している。従って、各企業でそれぞれ異なる型番が付与されている同型の製品は、サーバ１００内においては共通の型番が付与され処理されている。すなわち各企業における型番の相違はサーバ１００の上述の機能によりなくなる為、取引計画連携システム５００における当該製品の連携処理は円滑に実施される。
【００５３】
以上説明したように、計画連携処理部２６は、会社間計画オーダーコントロール３２１を用いて、波及処理や遡及処理を実行することにより、企業間の計画の連携を実現している。
【００５４】
計画コントロール部２０は、さらに、リリース管理部２７と、ＶＣコーディネーション部２８とを備えている。リリース管理部２７は、週次や日次で変更し得る計画オーダー等の種々の情報を、所定のタイミングでスナップショットとして保存し管理する機能を果たす。また、ＶＣコーディネーション部２８は、バリューチェーン全体のパフォーマンスを最適化するコンサルタントサービスを提供する機能を果たす。
【００５５】
本実施形態の取引計画連携システム５００では、計画コントロール部２０を用いることにより、各企業の状況を加味して各企業の計画を連携させて処理している。従って、各企業は、直接取引を行っている企業の状況だけでなく他の企業の状況も認識しながら販売や購入の計画を立てることができる。また、各企業はバリューチェーン全体の状況を把握できる為、余剰在庫や、余裕リードタイム、余剰手配等の無駄を省いた計画を立てることができる。
【００５６】
各企業間で実際に製品の取引が実行される場合には、サーバ１００が備える取引連携部３０が機能する。取引連携部３０は、バリューチェーン内の各企業間の取引の連携処理を実行する為の処理機能及び複数の記憶領域を有している。取引連携部３０は、複数の記憶領域として、得意先Ｃと販売会社Ａとの取引の連携処理を実行する為のＩＣＴ（Inter Company transaction）３１ａ及びＩＣＷ（Inter Company Warehouse）３２ａ、販売会社Ａと製造会社Ｂとの取引の連携処理を実行する為のＩＣＴ３１ｂ及びＩＣＷ３２ｂ、製造会社Ｂと外注製造会社Ｄとの取引の連携処理を実行する為のＩＣＴ３１ｃ及びＩＣＷ３２ｃ、及び外注製造会社Ｄと部品会社Ｅとの取引の連携処理を実行する為のＩＣＴ３１ｄ及びＩＣＷ３２ｄを備えている。
【００５７】
図４は、販売会社Ａと製造会社Ｂとの間で行われる取引を連携させる為の取引連携部３０による取引連携処理を示した図である。以下、図４を参照して、取引連携部３０による取引連携処理について説明する。
【００５８】
販売会社Ａと製造会社Ｂとの間で取引が実施される場合、先ず、販売会社Ａが、実績データベースＡ２に記憶されている、確定したオーダーである購入オーダー４０１を、製造会社Ｂに送信する。なお、購入オーダー４０１は、販売会社Ａが製造会社Ｂに対して型番「ＸＹＺ」の製品を５００個オーダーしたことを示すレコードレーベルである。また、そのオーダー番号は「１２３４５６」である。
【００５９】
製造会社Ｂが販売会社Ａから購入オーダー４０１を受信すると、製造会社Ｂは、購入オーダー４０１に対応した確定オーダーであって、実績データベースＢ２に記憶された顧客オーダー４１１に基づいて、販売会社Ａとの取引の処理を開始する。なお、顧客オーダー４１１は、製造会社Ｂが販売会社Ａから型番「ＸＹＺ」の製品を５００個オーダーされたことを示すレコードレーベルである。また、そのオーダー番号は「Ｃ９８７６５４」である。
【００６０】
また、製造会社Ｂが型番「ＸＹＺ」の製品を製造すると、製造受入（MO Receipt）４１３のレコードレーベルが作成される。この製造受入４１３は、製造会社Ｂが型番「ＸＹＺ」の製品を２５０個製造したことを示すレコードレーベルである。また、この製造受入４１３は、製造会社Ｂが型番「ＸＹＺ」の製品を在庫として２５０個保管していることも示している。
【００６１】
製造会社Ｂは、製造受入４１３に基づいて販売会社Ａ用に積送する製品数を決定する。決定された積送品に関する情報は、出庫売上げ（Sales Issue）４１２で示される。出庫売上げ４１２は、型番「ＸＹＺ」の製品を１１０個販売することを示すレコードレーベルである（すなわち製造会社Ｂ側の売上げ情報）。
【００６２】
顧客オーダー４１１は出庫売上げ４１２に基づいて更新される。具体的には、顧客オーダー４１１は、オーダーされた５００個のうち１１０個を積送状態にできることを示した内容に更新される。また、残り３９０個に関しては未定である為、顧客オーダー４１１にはそのことを示す情報も記憶される。
【００６３】
取引連携部３０は、出庫売上げ４１２に基づいて会社間の取引の連携処理（Inter Company transaction Control）を実行する。販売会社Ａと製造会社Ｂとの取引の連携処理を実行する為のＩＣＴ３１ｂが出庫売上げ４１２を取り込むと、ＩＣＴ３１ｂに、会社間在庫受入（Inter Company Warehouse Receipt）４２１が作成される。会社間在庫受入４２１は、製造会社Ｂから販売会社Ａに販売される型番「ＸＹＺ」の製品が、会社間の在庫に１１０個入庫された（すなわち積送状態となった）ことを示すレコードレーベルである。なお、当該取引を取引連携部３０で処理する場合、ＩＣＴ３１ｂに出庫売上げ４１２が取り込まれた段階（すなわち製造会社Ｂの売上げ情報が受入となった段階）で、当該製品に関する処理は販売会社Ａに属する。従って、会社間在庫受入４２１以降にＩＣＴ３１ｂ（またはＩＣＷ３２ｂ）で作成される全てのレコードレーベルに、会社識別コード「Ａ」が付与される。
【００６４】
取引連携部３０は、製造会社Ｂの売上げ情報（出庫売上げ４１２に相当）を、会社間在庫受入４２１に対する製品の積送情報（会社間在庫受入４２１）に置き換えている為、各検収基準の相違によりこのとき発生し得る製品の流通の一時的な不可視をなくすことができる。従って取引計画連携システム５００内では常に製品の流通を捕捉できる。
【００６５】
また、取引連携部３０では販売会社Ａによる発注と製造会社Ｂにおける受注とを等価に取り扱っている為、製造会社Ｂが製品を売り上げた時点において、販売会社Ａの発注における製品の残数と、製造会社Ｂの受注における製品の残数とが異なる場合、洗い換え発注時における二重手配のリスクを防止することができる。
【００６６】
ＩＣＴ３１ｂに会社間在庫受入４２１が作成されると、販売会社Ａに積送品納品書（GIT Invoice(Shipping Notice)）４０２が送信される。これにより、販売会社Ａは、１１０個の型番「ＸＹＺ」の製品が積送状態となったことを認識できる。
【００６７】
実際に販売会社Ａに型番「ＸＹＺ」の製品が入庫すると、実績データベースＡ２には、受入（Receipt）４０３が作成される。この受入４０３は、販売会社Ａに型番「ＸＹＺ」の製品が１１０個入庫したことを示すレコードレーベルである。
【００６８】
なお、販売会社Ａは、積送品納品書４０２を受信せずに受入４０３のみで当該製品の入庫に対応するよう設定することもできる。
【００６９】
受入４０３が作成されて販売会社Ａ側でその内容が確認されると、ＩＣＴ３１ｂに、その旨を報知する信号が送信され、会社間在庫出庫（ICW Issue）４２２が作成される。会社間在庫出庫４２２は、製造会社Ｂから販売会社Ａに販売された型番「ＸＹＺ」の製品が、会社間の在庫から１１０個出庫されたことを示すレコードレーベルである。従って、会社間の在庫は０となる為、その事を示すレコードレーベルすなわち会社間在庫（Inter Company Inventory (ICI or ICW)）４２３が作成される。
【００７０】
なお、製造会社Ｂは型番「ＸＹＺ」の製品を２５０個製造して１１０個出庫した為、製造会社Ｂの実績データベースＢ２には、当該製品を在庫として１４０個保管していることを示したレコードレーベルすなわち在庫４１４が作成される。
【００７１】
また、販売会社Ａは型番「ＸＹＺ」の製品を１１０個入庫した為、販売会社Ａの実績データベースＡ２には、当該製品を在庫として１１０個保管していることを示したレコードレーベルすなわち在庫４０４が作成される。
【００７２】
以上が本発明の実施形態である。本発明はこれらの実施形態に限定されるものではなく様々な範囲で変形が可能である。
【図面の簡単な説明】
【００７３】
【図１】本実施形態の取引計画連携システムの構成を示した構成図である。
【図２】本実施形態の構成要素である計画コントロール部による計画オーダーの再計画処理を示した図である。
【図３】本実施形態の構成要素である企業間の計画を連携させる為の計画連携処理部による連携処理を示した図である。
【図４】本実施形態の構成要素である企業間で行われる取引を連携させる為の取引連携部による取引連携処理を示した図である。
【符号の説明】
【００７４】
２０  計画コントロール部
２６  計画連携処理部
３０  取引連携部
４０  企業間取引定義部
１００  サーバ
５００  取引計画連携システム
【図１】
2005122364.tif 000003
【図２】
2005122364.tif 000004
【図３】
2005122364.tif 000005
【図４】
2005122364.tif 000006