(57)【要約】通信ネットワークを利用して企業間等の取引情報などを送受信するトランスミッションレイヤーと、該レイヤーで送受信されるメッセージ情報に対して内容のチェック等の管理を行うビジネスロジックレイヤーと、該レイヤーから受けたメッセージ情報を紐付けし、需要情報と供給情報の追跡と在庫推移の追跡を行う紐付け管理レイヤーとから成り、該管理レイヤーはメッセージ情報を「需要情報」「供給情報」「在庫情報」「生産情報」の４つの情報にモデル化する紐付け実行モジュールと、ビジネスロジックレイヤーから受けたメッセージ情報を紐付け実行モジュールのデータ構造や紐付けルールに適合するように加工し紐付け実行モジュールに受け渡す紐付けロジックモジュールと、該実行モジュールで紐付けられた情報を基に追跡情報を作成する需給トラッキンダグモジュールと、からサプライチェーン紐付け管理システムを構成したので、紐付け管理に必要な情報と、その紐付け方法を、企業形態、業務プロセス、商流・物流フローなどから分離することができ、それらに依存せずに紐付け管理を行うことができる。
2004085297.tif 000002
【特許請求の範囲】
【請求項１】
インターネットなどの通信ネットワークを利用して企業間や組織間でやり取りされる取引情報などを送受信するトランスミッションレイヤーと、トランスミッションレイヤーで送受信されるメッセージ情報に対して、業務プロセス・ルール情報、商流情報、物流情報などに基づいて、メッセージ内容のチェックやメッセージフロー／ワークフローの管理を行うビジネスロジックレイヤーと、ビジネスロジックレイヤーから受けたメッセージ情報を紐付けし、需要情報と供給情報のトラッキング（追跡）と在庫推移のトラッキングを行う紐付け管理レイヤーとより成り、紐付け管理レイヤーはメッセージ情報を「需要情報」「供給情報」「在庫情報」「生産情報」等の情報にモデル化する紐付け実行モジュールと、ビジネスロジックレイヤーから受けたメッセージ情報を紐付け実行モジュールのデータ構造や紐付けルールに適合するように加工し紐付け実行モジュールに受け渡す紐付けロジックモジュールと、紐付け実行モジュールで紐付けられた情報を基にトラッキング情報を作成する需給トラッキングモジュールとから成ることを特徴とするサプライチェーン紐付け管理システム。
【発明の詳細な説明】
【技術分野】  この発明は、複数の組織・企業によって商品が消費者の手元に届くまでの、原材料の調達から生産、販売に至る一連のものの流れ（以下、単に「サプライチェーン」という。）を管理し、個々の段階において需要と供給が一致しているか否かを確認し、各段階の需要と供給のずれが他の段階に与える影響を検出するために、サプライチェーン上の物の移動に関する情報を紐付け管理するための方法に関する。
技術背景
従来サプライチェーンの管理方法としては、商品が消費者の手元に届くまでの、原材料の調達から生産、販売に至る一連のものの流れを、おのおのの段階ごとに独立して管理していた。
例えば、原材料の調達から部品の生産までを「部品生産段階」として管理し、これとはまったく別に、部品を組立てて製品を生産するまでを「組立・生産段階」として管理し、また、生産された商品を仕入れて小売店に販売する「卸売段階」として管理し、さらに卸業者から商品を仕入れて小売販売する「小売販売段階」として管理するといったように、原材料メーカー、部品メーカー、組立メーカー、卸業者、小売店など、複数の企業が各段階毎に、それぞれ自己の業務が計画通り進行するよう独自に管理していた。
造船やビル建築など、あるプロジェクトの計画の進行を管理するためには、計画全体の中のある特定の出来事（イベント）と、膨大な数の個々の作業（アクティビティ）を洗い出し、それぞれの作業の最速開始時刻や最遅完了時刻をコンピュータに入力し、計画全体が最も効率よく進行するようにしたＰＥＲＴ手法などが知られている。
つまりＰＥＲＴ手法（「システム工学とは何か」渡辺  茂・須賀  雅夫  著、日本放送協会  １９７０年２月２０日発行）は、あるプロジェクトを作業の組合されたネットワーク、すなわちイベントとアクティビティのネットワークとして図表化し、各アクティビティの前後にあるイベントの番号と、そのアクティビティの所要時間という二つの要素のみをコンピュータに入力し、個々の作業の相互関係を明確にすることによって、イベント数が数万という大きなプロジェクトの進行状況を管理・把握することができる。
時間管理だけでなく、与えられた時刻内で最も安価にその作業を仕上げるというコスト管理も取入れたＰＥＲＴ／ＣＯＳＴ手法など、ＰＥＲＴ／ＴＩＭＥ手法を発展させたものが広く普及している。
生産や部品の調達を効率的に行う、いわゆるカンバン方式も知られている（「サプライヤー・システム」藤本  隆宏・西口  敏宏・伊藤  英史  編  有斐閣  １９９８年１０月発行）。この方式は必要なものを、必要な時に、必要な数量だけ生産・調達する方式で、部品や製品の在庫を最小限にするための手法である。
これらの管理手法のほか、ＴＯＣ（Ｔｈｅｏｒｙ  ｏｆ  Ｃｏｎｓｔｒａｉｎｔ）、ＭＲＰ（Ｍａｔｅｒｉａｌ  Ｒｅｑｕｉｒｅｍｅｎｔｓ  Ｐｌａｎｎｉｎｇ：資材所要量計画）方式、製番管理、物流業者のトラッキングサービスなど、生産や流通に関するいろいろな管理手法が提案され使用されている。
しかし、原材料の調達から生産、販売に至る一つ一つの管理段階を見ても、極めて多くの不確定な要素、変動要素などが存在するため、コンピュータで管理していても計画通りに作業を進めたり、現在の状況を常に正確に把握することが困難であった。
その上一つ一つの管理段階は、まったく独立して管理されており、互いに連携して全体を管理することが極めて困難であった。
例えば、工場で部品や資材などを調達する場合、注文番号によって需要情報（注文情報）と供給情報（入荷情報）を紐付けして入荷管理を行い、入荷個数（発注残）と入荷納期を把握していた。
しかし、これは注文内容と入荷実績を比較するだけの極めて簡単な方法であり、近年の調達業務におけるグローバル化、業務のアウトソーシング化、あるいは需要の変動が激しい状況のもとでは、確定された需要情報、供給情報の管理だけでなく、計画情報や予定情報（手配状況、輸送状況など）も管理する必要が生じ、それらの管理がますます難しくなっている。
例えば、激しい需要変動に対応するために、需要情報も確定された注文情報だけでなく、所要量計画情報、内示注文、確定注文、納入指示情報など、複数の情報種で送信されることが多い。
従って、予定と確定情報を含んだ複数の需要情報と複数の供給情報を、すべて紐付け管理することが求められるが、以下のような事情により、完全な紐付けを実現することは困難であった。すなわち、
Ａ）注文書により発注する企業もあり、注文書を発行せずに使用した量だけを買い取る企業もあるといったように、各企業によって業務方式が異なり、注文情報などの需要情報と入荷情報などの供給情報の使い方が異なっている。
Ｂ）一つの企業においても、その取引先や品物によって、複数の調達方式を使用する場合があり、需要情報と供給情報の使い方が異なる場合がある。
Ｃ）調達先は、部品メーカー、商社、原料メーカーなど、さまざまな種類の企業が、さまざまな場所に位置しており、需要情報、供給情報の使い方は企業形態、国の法律、輸送のリードタイムなど、さまざまな要因によって決まる。
Ｄ）物流業者は複数社利用され、また、受注者が業者を指定する場合もあり、物流業者によって取得できる供給情報の種類や内容が異なる。
Ｅ）発注者、受注者、物流業者はそれぞれ個別のＩＴシステムを利用しており、企業によって情報の内容が異なる。
以上の理由にみられるように、複数の組織・企業をまたがって、需要情報と供給情報を、伝票番号などにより一つ一つ紐付けるためには、非常に多くの課題がある。
従って、今まで各企業は個別に自社の商流経路と物流経路などの情報をもとに紐付けを決定し、管理していた。また、その場合においても全ての情報の紐付けではなく、確定注文情報と、物流業者からのトラッキング情報との紐付けなど、ごく一部の情報の紐付けに留まっていた。
さらに、グローバル化されたサプライチェーンでは、バイヤーのバイヤーや、サプライヤーのサプライヤーといった、他社の販売・調達状況や生産状況も見たいという要求が高まっている。
例えば、工場が商社に部品を発注する場合、商社はさらに部品メーカーに発注し、部品メーカーから商社を通じて工場に納品されるので、工場の調達担当者は商社の営業担当者とのみ連絡をとり、納品の確認をしていた。
しかし、工場の調達担当者が部品メーカーへの発注状況や部品メーカーからの出荷状況を知ることができれば、より早く納品遅れを確認することができ、より高い精度でスケジュール管理が行えるが、これらの企業間で個別に紐付け方法を決定しようとしても、それらの個別対応数は膨大な数となってしまうため、このような複雑な情報管理は極めて困難であった。
従来、多くの企業は、このような基幹業務の情報システムを自社で独自に開発していたが、システム構築のためのコストとそれを構築するために要する膨大な開発期間を短縮する必要性が出てきた。
そのため、近年、情報の一元化管理やリアルタイム管理などを行うために、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ  Ｒｅｓｏｕｒｃｅ  Ｐｌａｎｎｉｎｇ  統合業務パッケージ：受注・販売管理、在庫管理、生産管理、会計といった企業の基幹業務をサポートする情報システムパッケージ）（「図解ＥＲＰ入門」ＥＲＰ研究会著、日本能率協会マネジメント・センター  １９９７年１１月１日発行）やＳＣＰ（Ｓｕｐｐｌｙ  Ｃｈａｉｎ  Ｐｌａｎｎｉｎｇ）といったＳＣＭ（Ｓｕｐｐｌｙ  Ｃｈａｉｎ  Ｍａｎａｇｅｍｅｎｔ）の計画機能をサポートする既製のソフトウェアを導入する企業が増えてきたが、まだまだグローバルサプライチェーン全体の最適化には至っていない。
その理由の一つとして、顧客やサプライヤーといった取引先との情報共有や、ロジスティック業者からの物流情報のインテグレーションなど、サプライチェーン全体の実行系システムによる社外との情報共有が不十分であることが挙げられる。
ＥＲＰやＳＣＰは、基本的にＰＤＣＡ（Ｐｌａｎ→Ｄｏ→Ｃｈｅｃｋ→Ａｃｔｉｏｎ）のマネージメントサイクルに基づいたバッチ型の管理方式であり、サプライチェーン全体を紐付け管理した状況下での現場レベルでリアルタイムに問題を発見し、すばやく対処するための、予測イベント型の管理方式への対応が不十分である。
一方、ＰＥＲＴ手法においては、ある作業が完了しなければ次の作業が開始できないという、クリティカルパスを中心に全体の作業を管理しているが、例えばある一種類の部品を大量に使用する作業があった場合、その部品を大量生産する工場が予定数量の全数の生産を完了しなくとも、生産が完了した一部の部品を出荷し、その後に生産が完了した部品を順次出荷することにより、その部品を仕入れて使用する別の生産者の作業は継続的に順調に進めることが可能であり、全数生産の遅れが必ずしもクリティカルパスとはならない。
従って、このような場合にはＰＥＲＴ手法による管理を行うことは最適とはいえない。
また、ＰＥＲＴ手法においては、計画進行中に個々の作業に予期せぬ変動が起きた場合、その都度計画を修正しなければならず、その修正やクリティカルパスの変更などを関係者に伝達することも極めて煩雑であった。
さらに、ＰＥＲＴ手法においては、一つのプロジェクトを計画通りの日程やコストで完結させるという点では大きな成果を得ることができるが、日常的な商業活動において行われる商品の需要・供給の流れや反復する業務などを、広い範囲において日々継続して管理するという点では応用することが不可能であった。
一方、生産において、いわゆるカンバン方式を実践するには、以下の条件を満たす必要がある。
（１）小ロット化
（２）生産計画の平準化（複数の品種を均一のペースで生産することが必要）
（３）工程間の同期化（各工程の供給速度を等しくすることが必要）
（４）段取り替え時間と運搬時間の短縮
これらの条件が崩れてしまうと、需給バランスが崩れてしまい、在庫もしくは欠品が発生してしまう。
しかし、現実的には異なる品種をさまざまな機械、もしくは同一の機械で加工したり組立てたりする必要があるため、全ての業種や業態でカンバン方式を適用し、機械間（工程間）の需要量と供給量を一致させることは非常に困難である。
また、カンバン方式においては、ロットサイズは段取り替え時間と運搬時間とで決まるため、可能な限り無駄を排除し、段取り替え時間と運搬時間を可能な限り短縮することが最も重要である。
この方式では、小ロット・多頻度輸送が必要となり、例えば部品の供給者（工場）は、小ロットの納品の運搬時間を短縮するため、その部品を納入する工場の近隣に位置することが求められ、部品の需要・供給の管理手法としては限られた地域内でしか通用しないこととなってしまい、グローバル化した部品調達を管理するには適さない場合がある。
これらの管理手法のほか、ＴＯＣ方式（「在庫ゼロ  リードタイム半減ＴＯＣプロジェクト」村上  悟・石田  忠由・井川  伸治  著  中経出版  ２００２年発行）、ＭＲＰ方式、製番管理、物流業者のトラッキングサービスなど、生産や流通に関するいろいろな管理手法が提案され使用されているが、複数の組織・企業にまたがって、原材料の供給から商品が消費者に渡るまでのすべての工程を一括して管理する方式は存在しなかった。
この発明はかかる現状に鑑み創案されたものであって、その目的とするところは、サプライチェーンにおいて、あらゆる企業・組織形態が関わる状況下（消費者、小売、卸、工場、商社など）と、あらゆる状況下（量、納期、場所、経路の変更／追加／取消）において、物の移動に関わるあらゆる情報（需要情報、供給情報、生産情報、在庫情報）を常に矛盾無く的確にそれらの情報を管理し、それぞれの段階において需要と供給のずれと、そのずれが他の段階に与える影響、ならびに在庫の推移を知ることにより事前に問題を検知し対処するための紐付け管理システムを提供しようとするものである。
【発明の開示】
上記目的を達成するため、請求の範囲１に記載のサプライチェーン紐付け管理システムに係る発明は、インターネットなどの通信ネットワークを利用して企業間や組織間でやり取りされる取引情報などを送受信するトランスミッションレイヤーと、トランスミッションレイヤーで送受信されるメッセージ情報に対して、業務プロセス・ルール情報、商流情報、物流情報などに基づいて、メッセージ内容のチェックやメッセージフロー／ワークフローの管理を行うビジネスロジックレイヤーと、ビジネスロジックレイヤーから受けたメッセージ情報を紐付けし、需要情報と供給情報のトラッキング（追跡）と在庫推移のトラッキングを行う紐付け管理レイヤーとより成り、紐付け管理レイヤーはメッセージ情報を「需要情報」「供給情報」「在庫情報」「生産情報」等の情報にモデル化する紐付け実行モジュールと、ビジネスロジックレイヤーから受けたメッセージ情報を紐付け実行モジュールのデータ構造や紐付けルールに適合するように加工し紐付け実行モジュールに受け渡す紐付けロジックモジュールと、紐付け実行モジュールで紐付けられた情報を基にトラッキング情報を作成する需給トラッキングモジュールとから成るよう構成したものである。
【図面の簡単な説明】  図１は、この発明に係る紐付け管理システムの構成を示す概念図である。
図２は、紐付け方法を示す概念図である。
図３は、情報モデル図の見方を説明する図である。
図４（Ａ）（Ｂ）（Ｃ）は、要求情報の例を示す図である。
図５（Ａ）（Ｂ）（Ｃ）は、供給情報の例を示す図である。
図６は、生産情報の例を示す図である。
図７（Ａ）（Ｂ）は、需要情報に供給情報を紐付ける場合の例を示す説明図である。
図８は、手配供給情報に手配供給情報を紐付ける場合の例を示す説明図である。
図９は、手配供給情報に複数の出荷供給情報を紐付ける場合の例を示す説明図である。
図１０は、出荷供給情報に輸送供給情報を紐付ける場合の例を示す説明図である。
図１１は、需要情報に需要情報を紐付ける場合の例を示す説明図である。
図１２は、供給情報が出庫として在庫情報と紐付けされる場合の例を示す説明図である。
図１３は、供給情報が入庫として在庫情報と紐付けされる場合の例を示す説明図である。
図１４は、供給情報が入庫として在庫情報と紐付けされる場合の例を示す説明図である。
図１５（Ａ）は、完成品生産情報が在庫情報と紐付けられる場合の例を示す説明図を、（Ｂ）は、資材生産情報が在庫情報と紐付けられる場合の例を示す説明図である。
図１６は、１次ティアの需給情報に２次ティアの需要情報が紐付けられる場合の例を示す説明図である。
図１７は、上流ティアの需給情報に完成品生産情報が紐付けられる場合の例を示す説明図である。
図１８は、資材生産情報に下流ティアの需給情報が紐付けられる場合の例を示す説明図である。
図１９は、トラッキング情報の作成例（紐付けの例）を示す説明図である。
図２０は、図１９に基づく一覧表を示す図である。
【発明を実施するための最良の形態】  以下、この発明の好適な実施例を添付図面に基づいて詳細に説明する。尚、以下に述べる実施例は、この発明の好適な具体例であるから、技術的に好ましい種々の限定が付されているが、この発明の範囲は、以下の説明において特にこの発明を限定する旨の記載がない限り、この実施例に限られるものではない。
また、本明細書において用いられる用語の意味は、以下の通りである。
・メッセージ情報：企業間でやり取りされるトランザクション情報。注文情報、納期回答情報、出荷情報、在庫情報など。
・シングルティア：管理対象において、発注者と受注者が１組だけ存在する環境。
・マルチティア：管理対象において、発注者と受注者が２組以上存在する環境。
・要求者：品物の納品を要求する者。通常は発注者。
・供給者：要求者からの要求を受けて、品物の納品に責任を持つ者。通常は受注者。
・荷受者：荷物を輸送者から受取り、荷受業務を行う者。
・出荷者：出荷業務を行い、荷物を輸送者に渡す者。
・輸送者：荷物を鉄道車輛、トラック、船舶、航空機、その他の輸送機関によって、ある地点から他の地点へ移動させる者。
【実施例１】  図１は、本発明になるサプライチェーン紐付け管理システムの構成を示す概念図であり、１はトランスミッションレイヤー、２はビジネスロジックレイヤー、３は紐付け管理レイヤーである。
紐付け管理レイヤー３は、紐付けロジックモジュール３ａ、紐付け実行モジュール３ｂ、需給トラッキングモジュール３ｃから成っている。
トランスミッションレイヤー１は、ＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ：電子データ交換）に代表される企業間のメッセージ情報を転送するレイヤーである。
各企業によって異なるバックエンドシステムを使用しているため、ファイルフォーマットのＡｎｙ−ｔｏ−Ａｎｙ  Ｔｒａｎｓｌａｔｉｏｎや文字コード変換、データ補完・加工などの機能が要求される。この機能レイヤーは、既存のＥＤＩシステムで代用することができる。
ビジネスロジックレイヤー２は、トランスミッションレイヤー１で送受信されるメッセージ情報に対して、業務プロセス・ルール情報、商流情報、物流情報に基づいて、メッセージ内容のチェックやメッセージフロー／ワークフローの管理を行う。すなわち、
・ビジネスルールに基づいてメッセージ内のビジネスデータ（注文数量、納期など）をチェック。
・ビジネスデータの補完・加工（要求入荷日から要求出荷日を計算など）。
・メッセージフロー管理（送受信者管理、転送管理など）
・注文残管理、などである。
ビジネスロジックレイヤー２のルール情報は、取引先ごとにビジネスプロセス／ルール、商流・物流情報が異なるため、取引先ごとにそれらの情報が設定される。
紐付け管理レイヤー３は、ビジネスロジックレイヤー２から受けたメッセージ情報を紐付けし、需要と供給のトラッキング（追跡）と在庫推移のトラッキングを行う。
紐付け情報は、メッセージ情報が作成・変更されるたびに、紐付け管理レイヤー３に渡され、内容が変更される。
紐付けロジックモジュール３ａでは、その上位の紐付け実行モジュール３ｂのデータ構造、紐付けルールに適合するようにメッセージ情報を加工し、紐付け実行モジュール３ｂに必要な情報を受け渡す。
また、メッセージの作成、変更、取消に対して、事前に設定されたルールに従って、適切に紐付けの設定、変更、解除を行う。
ビジネスロジックレイヤー２は、メッセージ内容をチェックし、メッセージ情報の却下やデータの加工など、メッセージ情報に影響を与えるのに対して、紐付けロジックモジュール３ａでは、紐付け管理のためだけにデータ加工や紐付け設定が行われ、メッセージ情報に影響を与えることはない。
紐付け実行モジュール３ｂでは、メッセージ情報を「需要情報」「供給情報」「在庫情報」「生産情報」の４つの情報にモデル化し、紐付けロジックモジュール３ａから受けた情報を紐付け管理する。
需給トラッキングモジュール３ｃでは、紐付け実行モジュール３ｂで紐付けられた情報を基にトラッキング情報を作成する。
これによりサプライチェーンのどこで需要と供給がずれているか、またそのずれがどこに影響を与えるかを検知することができる。
以下、本発明になるサプライチェーン紐付け管理システムの中核となる紐付け実行モジュール３ｂでのモデル化方法について説明し、その紐付けモデルとメッセージ情報をつなげるための紐付けロジックモジュール３ａの機能と、トラッキング情報を作成するための需要トラッキングモジュール３ｃについて説明する。
紐付け実行モジュール３ｂでは、トランスミッションレイヤー１で送受信されるメッセージ情報を、「需要情報」「供給情報」「在庫情報」「生産情報」の４つの情報にモデル化し、紐付け管理を行う。紐付け情報は、トランスミッションレイヤー１でメッセージ情報が送受信されるたびに、リアルタイムに更新される。
なお、紐付けルールに基づいた紐付け実行や、紐付け時のエラー処理は、すべて紐付けロジックモジュール３ａで行われる。
紐付け実行モジュール３ｂでは、紐付けロジックモジュール３ａからの指示に従って紐付けを行う機能と、紐付け情報が設定・更新されたときに影響を受ける既存の紐付け情報をイベントとして紐付けロジックモジュール３ａに通知する。これは、企業ごとの既存のＩＴシステムや業務用ルールの違いにより、処理方法が異なる場合がある。
紐付け実行モジュール３ｂで定義される、４つの情報モデルを以下に示す。
１）  需要情報：品物を要求場所に納品することを要求する情報（所要量計画、内示注文、確定注文、納入指示など）。
２）  供給情報：品物を要求された場所へ納品する際の予定もしくは実績を表す情報（納期回答、出荷通知、入荷通知など）
３）  在庫情報：保管場所での、ある時点での品物の在庫数を表す情報。
４）  生産情報：完成品の生産予定もしくは実績を表す情報、および完成品を生産するために必要な資材を要求する情報。
これらの４つの情報モデルは、参照番号もしくは場所情報によって紐付けられる。参照番号によって紐付けられるのは、次の場合である。すなわち、
１）  需要情報に対する供給情報を紐付ける場合
２）  供給情報に供給情報を紐付ける場合
３）  需要情報に需要情報を紐付ける場合
４）  異なるティアの需要情報と紐付ける場合
５）  需要情報と生産情報を紐付ける場合
また、場所情報によって紐付けられるのは、次の場合である。すなわち、
６）  供給情報と在庫情報を紐付ける場合
７）  異なるティアの供給情報を紐付ける場合
図２は、以上の紐付け方法を示す概念図である。実線は参照番号によって互いに紐付けられることを示し、点線は場所情報によって紐付けられることを示す。
ここでは、要求者と供給者が２組の場合を示しているが、さらに下流側、上流側にも同様のルールによって紐付けを行うことができる。
尚、受注組立生産の場合は、生産情報＋在庫情報（仕掛品）＋生産情報によって管理される。また、生産情報を細かくトラッキングしたい場合は、複数の生産情報と在庫情報を組み合わせて管理される。
次に、４つの情報モデル（需要情報モデル、供給情報モデル、在庫情報モデル、生産情報モデル）について説明する。
図３は、各々の情報モデル図の見方を説明する説明図である。
＜１．需要情報モデル＞
図４は要求情報の例を示す図であり、図４（Ａ）、図４（Ｂ）、図４（Ｃ）は説明を図解する説明図である。
ここで、「需要情報」は、要求者が、品物を、要求場所へ、供給数量、要求期日までに、納品することを供給者に要求する情報である。「需要情報」に要求される事項の例を以下に挙げる。これらは、システムの構成によって異ならせることができる。
・１つの需要情報は、図４に示すように１つの品物（Ｐａｒｔ  ＡＢＣ）を、１つの要求場所（ＷＨ１）に対して、複数の要求スケジュール（要求入荷日・要求入荷数）として指定することができる。
・需要情報に、需要情報が紐付けられるとき、紐付けられる情報を「親需要情報」、紐付ける情報を「子需要情報」と呼ぶことにする。
・１つの親需要情報に対して、複数の子需要情報を紐付けることができる（図４Ａ参照）。
・同じ紐付けレベルの需要情報の要求数量はそれぞれ排他的でなければならない（図４Ｂ参照）。
・需要情報が改正される場合は、その需要情報が要求するすべての要求数量を含む必要がある（図４Ｃ参照）。
＜２．供給情報モデル＞
図５は供給情報の例を示す図であり、図５（Ａ）、図５（Ｂ）は説明を図解する説明図である。
「供給情報」は、要求者からの要求を受けて、品物を、要求場所へ納品する際の、出荷者から荷受者までの供給状況を通知する情報である。
供給情報は、需要情報を受け取ってから出荷場所に品物を手配するまでの状況を表す「手配供給情報」と、出荷者から品物が出荷されたことを通知する「出荷供給情報」と、出荷者から荷受者までの輸送状況を表す「輸送供給情報」と、荷受者が品物を受け取ったことを示す「入荷供給情報」に分けられる（図５参照）。「供給情報」に要求される事項の例を以下に挙げる。これらは、システムの構成によって異ならせることができる。
・供給情報は、手配供給情報→出荷供給情報→輸送供給情報→入荷供給情報の順序で発行される。出荷供給と入荷供給は必ず発行されなければならないが、手配供給と輸送供給は省略することができる。
・１つの供給情報は、１つの品物（Ｐａｒｔ  ＡＢＣ）、１つの供給場所（ＷＨ１）に対して、複数の供給スケジュールを指定することができる（図５Ａ参照）。
・供給情報に、供給情報が紐付けられるとき、紐付けられる情報を親供給情報、紐付ける情報を子供給情報と呼ぶことにする。
・手配供給情報同士と輸送供給情報同士は紐づくことが可能であるが、出荷供給情報同士と入荷供給情報同士は紐づくことができない。
・１つの親供給情報に対して、複数の子供給情報を紐付けることができる。
・供給情報は、紐付き先の需要情報が存在しない、独立した供給情報が存在する場合がある。
・同じ紐付けレベルの供給情報の供給数量はそれぞれ排他的でなければならない。
・供給情報が改正される場合は、その供給情報が表すすべての供給数を含まなければならない。
＜３．在庫情報モデル＞
「在庫情報」は、特定の場所に保管されている、ある時点での品物の数量を表す情報である。「在庫情報」に要求される事項の例を以下に挙げる。これらは、システムの構成によって異ならせることができる。
・１つの在庫情報は、１つの保管場所に対して、１つの品物とその保管数量を指定することができる。
・保管場所は、物理的な保管場所の指定だけでなく、同じ保管場所であっても特定の要求者向けの在庫を管理するために、システム上、異なる論理的な保管場所を指定することができる。ただし、異なる保管場所での在庫数は、それぞれ排他的でなければならない。
・在庫情報は、供給情報もしくは生産情報と、品番と場所情報によって紐付けされ、供給情報、生産情報が更新されるたびに、紐付け内容も更新される。
・供給情報と紐付く場合、納品場所が保管場所と同じ場合は、入庫として紐付き、出荷場所と保管場所が同じ場合は、出庫として紐付く。従って、出庫として紐付く場合は、手配供給情報もしくは出荷供給情報とのみ紐付くことができ、輸送供給情報、入荷供給情報とは紐付かない。
・生産情報と紐付く場合、完成品生産情報の生産場所と保管場所が同じ場合は、入庫として紐付き、資材生産情報の生産場所と在庫情報の保管場所が同じ場合は、出庫として紐付く。
・在庫情報は、品物を保管する情報で、需要情報には保管要求は含まれないため、在庫情報と需要情報は参照番号によって紐付けされない。
・在庫情報は、紐付けロジックモジュール３ａによってデータが更新されないため、紐付け改正番号の項目を持たない。
＜４．生産情報（完成品・資材）モデル＞
「生産情報」は、「完成品」の生産スケジュールと、その生産に必要な「資材」の要求スケジュールを示す情報である。
資材とは、調達資材もしくは受注組立生産における部品資材を指す。
図６は生産情報の例を示す図である。「生産情報」に要求される事項の例を以下に挙げる。これらは、システムの構成によって異なることができる。
・生産情報には、完成品生産情報と、資材生産情報の２つの種類がある。
・完成品生産情報と資材生産情報は、生産紐付番号もしくは生産場所によって紐付けされる。なお、完成品生産情報、もしくは資材生産情報が更新される場合は、影響を受けるすべての生産情報が更新され、常に整合性が取られていなければならない。
・生産紐付け番号で紐付けされる場合、１つの完成品に１つ以上の資材生産情報が紐付くことができる（図６参照）。
・生産場所によって紐付く場合、複数の完成品と複数の資材が、同じ生産場所によって紐付くことができる。
・１つの完成品情報は、１つの完成品、１つの生産場所に対して、複数の完成品スケジュールを持つことができる（完成品スケジュールは、予定と実績の情報を含む）。
・１つの資材生産情報は、１つの生産場所に対して、複数の資材要求スケジュールを持つことができる（資材要求スケジュールは予定と実績の情報を含む）。
・生産情報は、ＭＲＰやＳＣＰによって適宜更新され、予定外の問題（資材の欠品など）が発生した場合は速やかに再計画し、完成品生産情報が更新されることが望ましい。
・生産情報は、参照番号によって需要情報と紐付くか、場所情報によって、在庫情報と紐付けられる。
次に、この発明になる紐付け管理システムにおける紐付け方法の例について、
１．需要情報に供給情報を紐付ける場合、
２．供給情報に供給情報を紐づける場合、
３．需要情報に需要情報を紐づける場合、
４．在庫情報に供給情報を紐づける場合、
５．在庫情報に生産情報を紐づける場合、
６．異なるティアで需要情報と需要情報が紐付けられる場合、
７．需要情報と生産情報（完成品）が紐付けられる場合、
８．生産情報（資材）と需要情報が紐付けられる場合、の８通りについて説明する。
＜１．需要情報に供給情報を紐付ける場合＞
供給情報の需要紐付先番号に需要情報の準キー番号（要求者、供給者、需要情報番号、メッセージ改正番号、紐付け改正番号）を指定することで紐付けられる。
図７（Ａ）、図７（Ｂ）は、需要情報に供給情報を紐付ける場合の例を示す。
図７ａは、１つの需要情報（ＤＰＯ１ｖ０）に１つの供給情報（ＳＰＯ１ｖ０）が紐付づく場合を示している。
図７（Ｂ）は、１つの需要情報（ＤＰＯ１ｖ０）に１つの供給情報（ＳＰＯ１ｖ０）が紐付づいているものに、更に供給情報（ＳＰＯ２ｖ０）が紐付づけられた場合を示している。
需要情報に紐付けられる供給情報は、手配供給と出荷供給のみである。
＜２．供給情報に供給情報を紐づける場合＞
子供給情報の供給紐付先番号に親供給情報の準キー番号（要求者、供給者、供給情報番号、メッセージ改正番号、紐付け改正番号）を指定することで紐付けられる。
図８は、手配供給情報に手配供給情報を紐付ける場合の例であり、需要情報（ＤＰＯ１ｖ０−０）に手配供給情報（ＳＰＯ１ｖ０−０）が紐付けされているものが、手配供給情報（ＳＰＯ１ｖ０−１）と手配供給情報（ＳＣＯ１ｖ０−０）が紐付けされた場合を示している。
図９は、手配供給情報に複数の出荷供給情報を紐付ける場合の例であり、需要情報（ＤＰＯ１ｖ０−０）に手配供給情報（ＳＰＯ１ｖ０−１）が紐付けされ、その手配供給情報（ＳＰＯ１ｖ０−１）に出荷供給情報（ＳＤＯ１ｖ０−０）が紐付けされているものが、さらに出荷供給情報（ＳＤ０２ｖ０−０）が紐付けされ、手配供給情報（ＳＰＯ１ｖ０−１）が手配供給情報（ＳＰＯ１ｖ０−２）と更新されている。
図１０は、出荷供給情報に輸送供給情報を紐付ける場合の例であり、需要情報（ＤＰＯ１ｖ０−０）に手配供給情報（ＳＰＯ１ｖ０−２）が紐付けされ、その手配供給情報（ＳＰＯ１ｖ０−２）に出荷供給情報（ＳＤ０１ｖ０−０）と出荷供給情報（ＳＤ０２ｖ０−０）が紐付けされているものが、さらに出荷供給情報（ＳＤ０１ｖ０−０）に輸送供給情報（ＳＰＯ１ｖ０−０）が紐付けされ、出荷供給情報（ＳＤ０１ｖ０−０）が出荷供給情報（ＳＤ０１ｖ０−０）に更新されている。
＜３．需要情報に需要情報を紐付ける場合＞
子需要情報の需要紐付先番号に親需要情報の準キー番号（供給者、供給者、需要情報番号、改正番号）を指定することで紐付けられる。
図１１は、需要情報に需要情報を紐付ける場合の例であり、需要情報（ＤＰＯ１ｖ０−０）に手配供給情報（ＳＰＯ１ｖ０−０）が紐付けされているものが、親需要情報（ＤＰＯ１ｖ０−０）に子需要情報（ＤＪＯ１ｖ０−０）が新たに紐付けされ、親需要情報（ＤＰＯ１ｖ０−０）が親需要情報（ＤＰＯ１ｖ０−１）に更新されている。
さらに、需要情報（ＤＰＯ１ｖ０−０）に紐付けされていた手配供給情報（ＳＰＯ１ｖ０−０）が、手配供給情報（ＳＰＯ１ｖ０−１）に更新されている。
＜４．在庫情報に供給情報を紐付ける場合＞
在庫情報か供給情報が紐付け実行モジュール３ａで作成・更新されたときに、品番および、納入場所／出荷場所と保管場所がチェックされ、それぞれの品番と場所が同じ場合は自動的に紐付けられる。
供給情報の出荷場所と在庫情報の保管場所が同じ場合は出庫として紐付けられ、納品場所と保管場所が同じ場合は入庫として紐付けられる。
在庫情報、供給情報が更新された場合は、その都度、紐付け内容も更新される。
図１２は、供給情報が１つの場合、供給情報（ＳＰＯ１ｖ０−０）が出庫として在庫情報（１０１）と紐付けされる場合の例であり、図１３は、供給情報が複数の場合、供給情報（ＳＰＯ２ｖ０−０）が出庫として在庫情報（１０１）と紐付けされる場合の例である。
図１４は、供給情報が入庫として在庫情報と紐付けされる場合の例であり、既に出庫として供給情報が紐付けられている在庫情報に対して、複数の供給情報が入庫として紐付く場合を示している。
＜５．在庫情報に生産情報を紐付ける場合＞
在庫情報か生産情報が紐付け実行モジュール３ａで作成・更新されたときに、自動的に、品番および、生産場所と保管場所がチェックされ、それぞれの品番と場所が同じ場合は自動的に紐付けられる。
完成品生産情報の場合は、入庫として紐付けられ、資材生産情報の場合は、出庫として紐付けられる。
在庫情報、生産情報が更新された場合は、その都度、紐付け内容も更新される。
図１５（Ａ）は、完成品生産情報（生完Ｐ０１）が在庫情報（在１０１）と紐付けられる場合の例であり、図１５（Ｂ）は資材生産情報（生資ＰＭ０１）が在庫情報（在１０１）と紐付けられる場合の例である。
６．異なるティアで需給情報と需給情報が紐付けられる場合：
２次ティアの最上流需要情報の需給紐付先番号に、１次ティアの最上流需要情報の準キー番号（要求者、供給者、需要情報番号、改正番号）を指定することで紐付けられる。
また、１次ティアに需要情報が存在しない場合は、最上流の供給情報の準キー番号が指定される。
図１６は、１次ティアの需給情報に２次ティアの需要情報が紐付けられる場合の例である。
７．需給情報と生産情報（完成品）が紐付けられる場合：
完成品生産情報の需給紐付先番号に、上流ティアの最上流需要情報の準キー番号（要求者、供給者、需要情報番号、改正番号）を指定することで紐付けられる。
また、１次ティアに需要情報が存在しない場合は、最上流の供給情報のキー番号が指定される。
図１７は、上流ティアの需給情報に完成品生産情報が紐付けられる場合の例である。
８．生産情報（資材）と需給情報が紐付けられる場合：
下流ティアの最上流需要情報の需給紐付先番号に、資材生産情報のキー番号（要求者、供給者、需要情報、情報日時）を指定することで紐付けられる。
図１８は、資材生産情報に下流ティアの需給情報が紐付けられる場合の例である。
次に、この発明になるサプライチェーン紐付け管理システムにおける更新方法の例について、１．供給情報の更新、２．需要情報の更新、３．在庫情報の更新、４．生産情報の更新、の４通りのついて説明する。
１．供給情報の更新：
合計供給数と有効供給数は、更新内容に従って、自動的に更新される。
イ）供給情報が単独で存在する場合：
合計供給数が変更になる場合は、供給引当数（０）以上でなければならない。
ロ）供給情報が親供給情報に紐付いている場合：
合計供給数が変更になる場合は、供給引当数以上でなければならず、親供給情報の供給引当数と有効供給数が再計算される。
また、紐付けロジックモジュール３ａに、親供給情報に対する変更依頼イベントを通知する。紐付けロジックモジュール３ａは、親供給情報の供給スケジュールを有効供給数に合うように更新する。
ハ）供給情報に子供給情報が紐付けられている場合：
合計供給数が変更になる場合は、供給引当数以上でなければならない。もし、供給引当数以下に変更したい場合は、子供給情報の合計供給数を先に変更する必要がある。これらは、紐付けロジックモジュール３ａで行われる。
ニ）供給情報に在庫情報が紐付けられている場合：
合計供給数が変更になる場合は、供給引当数以上でなければならず、在庫情報の有効在庫数が再計算される。
なお、場所情報（出荷場所、納品場所）が変更になった場合は、紐付けがキャンセルされ、必要に応じて他の在庫情報と紐付けられる。
ホ）供給情報が需要に紐付いている場合：
合計供給数が変更になる場合は、供給引当数以上でなければならない。
ヘ）供給情報に他のティアの需給情報が紐付けられている場合：
合計供給数が変更になる場合は、供給引当数以上でなければならない。
２．需要情報の更新：
合計要求数と有効需要数は、更新内容に従って、自動的に更新される。
イ）需要情報が単独で存在する場合：
合計供給数が変更になる場合は、需要引当数（０）以上でなければならない。
ロ）需要情報が親需要情報に紐付いている場合：
合計要求数が変更になる場合は、需要引当数以上でなければならず、親需要情報の需要引当数と有効需要数が再計算される。
また、紐付けロジックモジュール３ａに、親需要情報に対する変更依頼イベントを通知する。
紐付けロジックモジュール３ａは、親需要情報の要求スケジュールを有効需要数に合うように変更する。
ハ）需要情報に子需要情報が紐付けられている場合：
合計要求数が変更になる場合は、供養引当数以上でなければならない。もし、需要引当数以下に変更したい場合は、子需要情報の合計要求数を先に変更する必要がある。これらは、紐付けロジックモジュール３ａで行われる。
ニ）需要情報に供給情報が紐付けられている場合：
合計要求数が変更になる場合は、需要引当数以上でなければならない。
紐付けロジックモジュール３ａに、供給情報に対する変更依頼イベントを通知し、紐付けロジックモジュール３ａは、供給情報の合計供給数を、需要情報の有効需要数に合うように更新検討を行う。なお、更新方針は、事前に決められたルールに従う。
ホ）需要情報が生産情報に紐付けられている場合：
合計要求数が変更になる場合は、需要引当数以上でなければならない。
ヘ）需要情報に他のティアの需要情報が紐付けられている場合：
合計要求数が変更になる場合は、需要引当数以上でなければならない。
３．在庫情報の更新：
イ）在庫情報に供給情報が紐付けられている場合：
紐付けられているすべての供給情報（入庫側、出庫側）に対して、有効在庫数を更新する。
有効在庫数が０以下になった場合は、紐付けロジックモジュール３ａに通知する。
ロ）在庫情報に生産情報が紐付けられている場合：
紐付けられているすべての供給情報（入庫側、出庫側）に対して、有効在庫数を更新する。
有効在庫数が０以下になった場合は、紐付けロジックモジュール３ａに通知する。
４．生産情報の更新：
イ）生産情報に在庫情報が紐付けられている場合：
在庫情報の有効在庫数が再計算される。なお、生産場所が変更になった場合は、紐付けがキャンセルされ、必要に応じて他の在庫情報と紐付けられる。
次に、紐付け管理レイヤー３の紐付けロジックモジュール３ａについて説明する。（図１参照）
紐付けロジックモジュール３ａでは、事前に設定されたルールに従って、ビジネスロジックレイヤー２から受け取った情報をもとに、紐付け実行モジュール３ｂに実行要求を発行し、紐付け管理を行う。具体的な機能は、
１．情報の加工・補完：
ビジネスロジックレイヤー２から受け取った情報が紐付け実行モジュール３ａでの情報形式に合っていない場合、事前に決められたルールに従って情報の加工や補完を行う。
（例：所要量計画情報の紐付け、ブランケットオーダーの納期指定）
２．参照番号の作成・補正：
ビジネスロジックレイヤー２から受け渡される情報に、紐付け先の参照番号が指定されていない場合に参照番号を作成したり、必要に応じて参照番号を補正する。
作成方法や補正方法は、ビジネスプロセスを基に事前に決定される。
３．供給情報種の指定：
ビジネスロジックレイヤー２から受け取った供給情報に対して、事前に決められたルールに従って、供給情報種を指定する。
４．要求スケジュール、供給スケジュールの修正・更新：
ビジネスロジックレイヤー２から受け取った要求スケジュール（要求納品日、要求数）、供給スケジュール（納品日、供給数）は、合計要求数、合計供給数を対象にしている場合がある。
紐付け実行モジュール３ａでは、それらは、有効需要数、有効供給数を対象にしているため、必要に応じてスケジュールを修正する。修正方法は、ビジネスルールに従って事前に決定される。
５．紐付け実行モジュールへの紐付け実行要求の発行：
紐付け実行モジュール３ａに対して、紐付けに必要な情報を受け渡し、紐付け実行コマンドを発行する。
６．紐付け実行モジュールから発行されたイベントの受信と、そのイベント処理：
紐付け実行を行った結果、紐付け実行モジュール３ａからイベントを受け取った場合は、事前に決められたルールに従って処理する。
次に、紐付け管理レイヤー３の需給トラッキングモジュール３ｃについて、図１、図１９および図２０に基づいて説明する。
図１９は、トラッキング情報の作成例（紐付けの例）であり、図２０は図１９に基づく一覧表である。
需給トラッキングモジュール３ｃは、紐付け実行モジュール３ａで紐付けされた情報を基に、供給が要求通りに行われているか否かを確認する機能を提供する。
この機能では、マルチティアを含めた対象のサプライチェーン全体で、要求日、要求数量と、供給日、供給数量とを比較し、納期遅れ（早い）が発生する日とその期間、遅れ（早い）の数量を、出荷場所から要求場所までの各場所において、リアルタイムに可視化する。また、すべての在庫ポイントでの在庫推移も併せて可視化する。
以下、需給トラッキングモジュール３ｃの需給トラッキング方法の例について説明する。
１）トラッキング表の作成：
紐付け実行モジュール３ａで紐付けられた情報を基に、各場所（要求場所、経由場所、出荷場所）での要求数と供給数を日付順に並べる。具体的には、
・対象となる需要情報を選択する。（需要情報は最上流でなくてもよい）
・その需要情報と下流側に紐付けられているすべての需要情報の要求内容（納品日、要求数など）を日付順に要求内容のコラムに並べる。（有効需要数が０の情報は要求内容を持たないため、結果的に計算対象とならない。）
・その需要情報と下流側に紐付けられているすべての需要情報に紐付けられている、すべての供給情報の供給内容（納品日、納品数など）を日付順に並べる。この時、供給情報の場所情報に従って、コラムを分ける。入荷場所での供給内容は、要求内容コラムの右横に入荷コラムとして並べ、供給場所ごとに、出荷から入荷までの供給内容を、入荷コラムに向かって、右から左の方向に場所コラムごとに並べる。
・供給情報に在庫情報が紐付けられている場合は、その場所コラムに対して、出荷の場合は供給情報の右側、入荷の場合は供給情報の左側に在庫数を日付に従って並べる。日付ごとに在庫数は、在庫情報の紐付けログから計算される。
・在庫情報に生産情報が紐付けられている場合は、完成品生産情報は在庫情報の右側、資材生産情報は在庫情報の左側に、生産内容（完成日、完成数、資材要求日、資材要求数など）を日付順に並べる。
・需要情報に完成品生産情報が紐付けられている場合は、生産場所と同じ需給情報の場所コラムに対して、その右側に生産内容を並べる。また、需給情報に資材生産情報が紐付けられている場合は、生産場所と同じ需給情報の場所コラムに対して、その右側に要求内容を並べる。
・需給情報に他のティアの需給情報が紐付けられている場合は、１次需給情報に対する手配状況が分かるように、１次供給情報の出荷情報を左側、２次需要情報の要求情報を右側になるように日付順に並べる。
２）比較方法：
いつからいつまで、いくつの品物の納期が遅れる（早い）かを可視化するために、トラッキング表の場所情報が同じコラムに対して、（供給数−要求数）の累積を計算する。
・需要情報に対する納品状況を確認する場合は、納品場所での、（供給数−納品数）の累積を計算する。なお、出荷場所での要求出荷日と要求出荷日も分かっている場合は、（出荷数−出荷要求数）の累積を計算し、供給場所での供給状況を確認することも可能である。
・受注生産など、需給情報と完成品生産情報を比較する場合は、出荷場所（生産場所）での、（完成品数−出荷数）の累積を計算する。また資材生産情報と需給情報を比較する場合は、生産場所（入荷場所）での、（供給数−要求数）の累積を計算する。
・他のティアの手配状況を確認するために、需給情報と他のティアの需給情報を比較する場合は、直送の時は、（２次需要情報の供給数−１次需要情報の要求数）の累積を計算し、直送でない場合は、夫々の（供給数−要求数）の累積と、（２次供給情報の供給数−１次供給情報の出荷数）の累積を計算する。これによって、予定通り出荷場所から品物が出荷できるかどうかを確認することができる。
・各保管場所での在庫推移は、トラッキング表の在庫数を日付に従って確認すればよい。
【産業上の利用可能性】  請求の範囲１に記載の発明によれば、紐付けトラッキングに必要な情報をモデル化し、そのモデル化された情報に対して紐付け管理を行うようにしたため、紐付け管理に必要な情報と、その紐付け方法を、企業・組織形態、業務プロセス、商流・物流フローなどから分離することができ、それらに依存せずに紐付け管理を行うことが可能となる。
従って、複数の組織・企業を対象とした、計画から実績までを含んだ注文から入荷までの情報のシームレスな紐付け管理と、紐付けによるリアルタイムな状況トラッキングが実現でき、各企業が個別に独自のシステム開発を行う必要がなくなり、独自システム構築のためのコスト削減とそれを構築するために要する膨大な開発期間を短縮することができる。
そして、サプライチェーン紐付け管理システムをベースに、検出された問題に対する重み付け機能、Ｗｈａｔ−ｉｆシミュレーション機能、パフォーマンス分析機能を構築し、グローバルなサプライチェーンにおいて、需給バランスがずれるリスクを管理するシステムを実現することが可能となる。
【図１】
2004085297.tif 000003
【図２】
2004085297.tif 000004
【図３】
2004085297.tif 000005
【図４】
2004085297.tif 000006
【図５】
2004085297.tif 000007
【図６】
2004085297.tif 000008
【図７】
2004085297.tif 000009
【図８】
2004085297.tif 000010
【図９】
2004085297.tif 000011
【図１０】
2004085297.tif 000012
【図１１】
2004085297.tif 000013
【図１２】
2004085297.tif 000014
【図１３】
2004085297.tif 000015
【図１４】
2004085297.tif 000016
【図１５】
2004085297.tif 000017
【図１６】
2004085297.tif 000018
【図１７】
2004085297.tif 000019
【図１８】
2004085297.tif 000020
【図１９】
2004085297.tif 000021
【図２０】
2004085297.tif 000022
【国際調査報告】
2004085297.tif 000023
2004085297.tif 000024
2004085297.tif 000025