JP2003534582A

JP2003534582A - サプライチェーンアーキテクチャ

Info

Publication number: JP2003534582A
Application number: JP2001552308A
Authority: JP
Inventors: デレック・リドウ
Original assignee: アイサプリコーポレイション
Priority date: 2000-01-12
Filing date: 2001-01-12
Publication date: 2003-11-18

Abstract

(57)【要約】本発明は、顧客７２、供給業者７６、ロジスティクスプロバイダ７８、運送業者７８、および、金融機関３９２が全て中央集中型サプライチェーンサーバー７４に接続されているサプライチェーンネットワーク７０を提供する。前記サーバーは、顧客が望む注文について詳述された予測を、該顧客から受け取る。これらの予測は、サプライチェーンサーバーにより分析されて、これにより、これらの予測が契約上の同意に従いかつ誤りを含まないことが保証される。これらの予測は、今後の需要について供給業者に警告するためにも用いられ、これに応じて、供給業者は、需要を予想することができ、かつ、棚卸資産について計画を立てることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は、サプライチェーン（supply chain）ネットワークの改善に関し、よ
り詳細には、多数のオペレーション作業工程を中央集中化することにより、従来
技術のシステムよりも能率的かつ低コストであるサプライチェーンを生じさせる
サプライチェーンネットワークに関する。

【０００２】

【従来の技術】

製造業者（以後、概略的に“顧客（customer）”と称する）、および、製品ま
たはサービス（以後、集合的に“製品（product）”と称する）の供給業者（sup
plier）は、コストの低下に常に関心を有している。材料は、サプライチェーン
管理コストと同様に、総コストの大部分を占める。サプライチェーンは、製品の
製造において用いられる部品およびサブ部品の定義、設計、生産、受け取り、監
視、貯蔵、および、使用と関連した任意のおよび全ての活動（activity）である
。製造業者／顧客は、しばしば、自分たちが高い代価を支払っていることに気づ
き、需要（demand）が高いときに製品が不足し、需要について不正確な予測を行
い、かつ、棚卸資産（inventory）の動きを緩慢にさせている。その理由は、彼
らが、自分たちのサプライチェーンを適切に管理するための専門知識、資源、ま
たは、機会を有していないためである。

【０００３】直接材料（direct materials）は、製造業者の総コストの３５％〜７０％を占
め、かつ、しばしば、最も大きな支出カテゴリーを構成する。材料のコストを低
下させることによって、収益性が著しく向上する。例えば、請負いの電子部品の
製造に従事している会社は、直接材料価格を１％下げるだけで、総収益性を２０
％〜３０％向上させることができる。

【０００４】サプライチェーンのコストは、製造業者の総支出のうち、かなりの部分を構成
する。例えば、サプライチェーンのコストには、計画、購入、引取貨物運送料（
inbound freight）、受け取り、棚卸資産の管理、運送コスト、供給業者のモニ
タリング、測定、管理、および、送り状の支払いが含まれる。これらのコストは
、会社の支出の５％〜２５％を占める。この概算は、製造業者による部品の製造
および供給の両方に当てはまる。例えば、サプライチェーンのコストを２０％低
下させることによって、所定の製造業者の収益が著しく向上し、多くの場合にお
いては２倍にもなり得る。

【０００５】従来技術による通常的なサプライチェーンが、図１に示されている。顧客は、
概して、従来技術のサプライチェーンを用いて部品およびサブ部品を調達するた
めの２つの方法を有している。従来技術のサプライチェーン５０に示されるよう
に、大規模な相手先商標製品製造業者（ＯＥＭ）、請負電子部品製造業者（cont
ract electronics manufacturer：ＣＥＭ）（図示せず）、または、（部品の）
顧客５２は、通常的には、部品製造業者（すなわち、供給業者５６）から直接的
に購買する。このテクニックは、この業界において、“直接的購買（buying dir
ect）”として知られている。大規模な顧客５２は、部品が必要となる毎に、供
給業者に対して注文を行う。供給業者５６は、製品を運送業者（carrier）５８
に渡し、運送業者５８は、注文された製品を大規模な顧客５２へ配達する。

【０００６】小規模な顧客５４は、通常的には、第三者的な卸売業者（distrobutor）また
は代理店６０を通して購入を行う。卸売業者６０は供給業者５６から部品を購入
し、供給業者５６は製品を運送業者６２に渡し、運送業者６２は製品を卸売業者
６０へ持ってくる。次に、卸売業者６０は製品を他の運送業者６４へ移送し、該
運送業者６４が製品を小規模な顧客５４へ配達する。他の形式の第三者的な卸売
業者は、部品の競売を開催するために電子的手段を用いる。しかしながら、電子
競売に伴う時間が冗長であるので、このようなサービスは、一回限りまたはスポ
ット買いで部品が必要な場合を除いては、ほとんど用いられていない。

【０００７】当事者たちの多くは、従来技術のサプライチェーンに満足していない。公知の
サプライチェーンネットワークは、通常は、出荷のミスや、顧客への部品供給の
断絶を生じさせる。これらの欠陥は、特に、重要な部品が不足している場合の“
割り当て”のときに、顧客を失望させる。このことにより、最終的な出荷に遅延
が生じ、かつ、これに伴い、歳入および収益の損失が生じる。

【０００８】特に、部品供給業者５６は、従来技術のサプライチェーンに失望している。こ
れらのエンティティの最終製品に関する市場状態の変化は、変動が激しい（vola
tile）製造スケジュールを生じさせ、非能率的な工場の利用およびコストの上昇
という結果をもたらす。部品供給業者５６は、工場の負荷と棚卸資産レベルを徐
々に向上させようとすべく、資材資源計画（Materials Resource Planning：Ｍ
ＲＰ）／企業資源計画（Enterprise Resource Planning：ＥＲＰ）システムにも
大量に投資している。

【０００９】これらのシステムにおいて、部品供給業者は、同じシステムを用いて、顧客の
工場または一連の工場が生成した生産計画に基づいて部品を提供しようと計画す
る。しかしながら、これらのシステムは、個々の部品供給業者において機能する
だけであって、しばしば、生産計画を週単位で処理するだけであるので、これら
のシステムは、しばしば、失望させるような結果を生じさせる。したがって、こ
れらのシステムは、通常的には、注文の変動率と比較して反応が緩慢であり、か
つ、主要ではない倉庫に配置された過剰な棚卸資産を検出することができず、こ
れにより、過剰な部品が注文されるという結果をもたらす。

【００１０】これらの問題の一部を解決するために、大規模な製造業顧客５２の中には、必
要とする製品に関する現場の（on-site）または局所的な（local）専用の委託棚
卸資産（consignment inventories）を、供給業者５６に維持させることを要求
する顧客もいる。しかしながら、これらの棚卸資産位置を追加して維持すること
は、非常にコストがかかり、かつ、統制が困難である。さらに、棚卸資産の追加
によって、生産能力や総棚卸資産の利用が、さらに、非能率的なものとなる。

【００１１】さらに、顧客５４は、しばしば、卸売業者６０を通してサービスを受け、該卸
売業者６０は、これらの顧客５４が既に生じさせたサプライチェーンのコストに
加えて、棚卸資産の処理コストの管理および担当に対して７％〜３５％の売上総
利益（gross margin）ポイントを要求する。これらの卸売業者のマージンは、中
小規模の顧客５４に対する供給業者５６の収益性を低下させ、かつ、供給業者５
６と卸売業者６０との間に、卸売業者６０のマージンを制限する方法またはその
是非に関して緊張関係を生じさせる。さらに、注文の分配には、出荷／借方記入
（ship-and-debit）価格と在庫品（stock）の回転とを管理するのに必要とされ
る特殊な工程およびシステムを施行するために、より多くのコストがかかる。最
終的に、顧客に対して販売およびサービスを行うためには、マーケティングコス
トや広告コストを除いて、売上高の５％〜１０％のコストがかかる。供給業者５
６は、これらの投資に関する元金回収（pay-back）を行うことが困難である。

【００１２】従来技術のサプライチェーンにおいては、支払いの問題も存在する。従来技術
による多くのシステムにおいて、製品は、支払い期間を度外視して顧客５２，５
４に販売される。例えば、顧客は、製品を供給業者５６から受け取り、かつ、配
達日から供給業者５６に支払いを提供するまでに３０日間を有する。顧客は、頻
繁に、この支払い期間に便乗して、この期間が過ぎた後まで（例えば、配達日か
ら４５日後まで）支払いを行わない。顧客は、製品のコストを埋め合わせるため
には、ローンを利用して期限通りにローンの支払いを行うよりも、この取り決め
の方が望ましいことを知っている。支払いの遅延により、顧客のバランスシート
（balance sheets）は、ローンの代わりに支払勘定（payable）を示し、これは
、投資者にとってはより魅力的な展望である。概して、供給業者５６にとって１
５日間の食い違いについて文句を言うことに労力を費やす価値はなく、供給業者
５６は、これら１５日間分の金額を損失することになる。この問題を解決するた
めに、供給業者５６は、顧客に部品の割増請求を行うことにより、支払いの遅延
に起因して損失されることが予想される金額に対して、事実上の（de facto）利
息を生じさせる。この事実上の利息は、明らかに、顧客５２，５４にとって望ま
しいものではない。

【００１３】さらに、会計期間（accounting periods）の終わり頃になると、供給業者５６
は、それぞれのバランスシートの体裁を改善するために、頻繁に、スケジュール
の前に製品を出荷することを望む。供給業者５６に対する卸売業者６０は、この
要望に気づいており、かつ、その結果として、予定された出荷日の前に商品を受
け取るために値引きを提供するように供給業者５６に要求する。卸売業者６０が
要求するこれらの臨時の値引きは、公知のサプライチェーンネットワークに関し
て、さらに他の不都合な点を呈している。

【００１４】

【発明が解決しようとする課題】

したがって、従来技術においては、前述した非能率性を一掃することにより、
製品の販売および分配において顧客および供給業者の両方が被る損失を低下させ
るサプライチェーンアーキテクチャの必要性が存在する。

【００１５】

【課題を解決するための手段】

本発明は、顧客、供給業者、ロジスティクスプロバイダ、運送業者、および、
金融機関（financial institutions）が全て中央集中型（centralized）サプラ
イチェーンサーバーに接続されているサプライチェーンネットワークを提供する
。前記サーバーは、顧客が望む注文について詳述された予測を、該顧客から受け
取る。これらの予測は、サプライチェーンサーバーにより分析されて、これによ
り、これらの予測が契約上の同意に従いかつ誤りを含まないことが保証される。
これらの予測は、今後の需要について供給業者に警告するためにも用いられ、こ
れに応じて、供給業者は、需要を予想することができ、かつ、棚卸資産について
計画を立てることができる。

【００１６】前記サプライチェーンサーバーは、供給業者に問い合わせて、供給業者が予測
を注文処理（fulfillment）できるか否かを判断する。供給業者が予測を注文処
理できなければ、サプライチェーンサーバーは、顧客と供給業者とに連絡し、か
つ、顧客の需要を別の供給業者へ再分配（redistribute）しようとするか、また
は、顧客に需要の変更を要求しようとする。供給の問題が解決すると、顧客の需
要はグループの形で供給業者へ送られ、これにより、供給業者は、より大規模な
注文を、より少ない数だけ準備すればよい。

【００１７】前記サプライチェーンサーバーは、供給業者から顧客への製品の分配に関係し
た工程（購入注文および送り状の生成を含む）を、監督しかつ制御する。顧客は
、サプライチェーンサーバーに支払いを行い、次に、この支払いは、適切な供給
業者とロジスティクスプロバイダとに転送される。顧客が製品を返品（return）
したいと希望すれば、返品工程もまた、サプライチェーンサーバーにより監督さ
れかつ制御される。顧客、供給業者、および、ロジスティクスプロバイダが全て
サプライチェーンサーバーと連絡を取るので、新しいアーキテクチャは、従来技
術においては利用不可能である有用な情報をもたらす。この情報には、例えば、
顧客の需要傾向や、供給業者のパフォーマンス（performance）などが含まれる
。

【００１８】前記サプライチェーンサーバーは顧客の予測を受け取るので、サプライチェー
ンサーバーのオペレータは、より確信的に、供給業者の製品を、指定されたスケ
ジュールの前に受け取ることができ、これにより、供給業者は、自分のアカウン
ティングブック（accounting books）を改善すべく、早期に出荷することが可能
となる。さらに、サプライチェーンサーバーのオペレータは、より確信的に、需
要された製品に関連した融資（financing）の取り決めを顧客に提供することが
できる。この取り決めは、顧客が契約通りに支払いを行わなければ、オペレータ
は該顧客へ今後の製品の出荷を見合わせることができるためのものである。

【００１９】

【発明の実施の形態】

本発明を例示する目的のために、図面において、現状において好ましい形式が
示されている。しかしながら、これと寸分違わない取り決めや手段に本発明が制
限されるものではないことを理解すべきである。

【００２０】《Ｉ．全般的な概観》説明される機能については、多くの様々な形式のハードウェアやソフトウェア
を用いて、または、人為的にも実施できることは明らかであるので、以下の説明
において、工程およびハードウェアについて説明する用語については、相互交換
的に用いるものとする。

【００２１】本発明は、同じまたは類似の製品を要求する顧客をサポートするネットワーク
を作成する。本発明によるサプライチェーンネットワークを利用する顧客は、供
給品の需要が変更された場合であっても、コストの低下と柔軟性の増大とを実現
する。一実施形態において、顧客が受け取る製品は、最初に、該顧客により適格
と認められる（qualify）。その理由は、顧客が、これらの製品を、自分たちの
製造工程において適格と認めるかまたは許容する前に、徹底的にテストすること
ができるためである。いったん、製品が適格と認められると、定義されたセット
の相互作用が特定の順序および指定された回数で発生し、これにより、サプライ
チェーンを顧客と供給業者との間で適切に管理しかつ同期させることが可能とな
る。このように適切に同期したサプライチェーンは、最小限の棚卸資産と、短い
反応供給時間とを有する。

【００２２】図２を参照すると、本発明によるサプライチェーンネットワークの全般的な概
観が示されている。サプライチェーンネットワーク７０は、任意の規模の顧客７
２を含む。各々の顧客７２は、サプライチェーンサーバー７４に対して注文を行
う。サプライチェーンサーバー７４は、同じまたは類似の製品を用いる顧客７２
からの需要予測を蓄積する。次に、これらの需要は集計され、かつ、サプライチ
ェーンサーバー７４は、要求された全ての製品を、承認された供給業者７６から
顧客７２へ分配するための最適な方法を決定する。

【００２３】前記サプライチェーンサーバー７４は、通常的には、コンピュータから構成さ
れるが、この説明の全般においては、契約上の関係を取り扱うことが可能なエン
ティティを指す。このような説明において、前記サーバーのオペレータは、契約
における真の当事者（real party）であることを理解すべきである。サプライチ
ェーンサーバー７４については、コンピュータとして実施する必要がないことも
また理解すべきである。

【００２４】前記顧客の注文はサプライチェーンサーバー７４により集計されるので、供給
業者７６は、顧客の数と比較して相対的により少数の注文と、これらの顧客のネ
ットワーク全体に関する出荷品とを整理する（assemble）必要がある。次に、一
実施形態において、製品は、ロジスティクスプロバイダ７８（以後、本明細書に
おいて、“３ＰＬ”（third party logistic provider）と称する）として示さ
れるような貨物会社により積み込まれ、かつ、製品の分配のための指示がサプラ
イチェーンサーバー７４により提供される場所（この場所については、出荷品が
積み込まれた場所と同じ場所であってもよい）へ運ばれる。これらの指示は、ど
のように注文を分類（break down）し、かつ、特定の顧客が要求する正確な数量
の形に再整理（re-assemble）すべきかを示す。注文を分類することは、クロス
ドック（cross-dock）と称され、かつ、クロスドック地点（cross-dock point）
において実行される。サプライチェーンネットワーク７０は、任意の数の顧客、
供給業者、および、ロジスティクスプロバイダと協働することができる。他の実
施形態においては、顧客または供給業者の地点において、ロジスティクスプロバ
イダが行うべき活動が行われる。

【００２５】誰に対して、および、何処へ製品を出荷すべきかを、後の分配工程において決
定することにより、最大の柔軟性と最小の全体的サイクル時間とがもたらされ、
かつ、供給業者の注文管理システム内において顧客の注文を管理するための高コ
ストの必要性がなくなる。このことは好都合である。その理由は、注文を管理す
るためのコストは、多数の顧客と多数の様々な部品の形式および数とを管理する
供給業者にとって、相当な額になり得るためである。一つの部品に対して一つの
注文を管理することは、概して、多数の部品に関する大規模な注文を特定の数量
の形に分類することよりもコストがかかるので、本発明は経済的な利点を提供す
る。

【００２６】これらの製品が分類された後に、個々の顧客の注文については、従来の手段お
よび運送業者を用いて、これらの注文の最終的な目的地へ出荷することができる
。多数量の製品を多くの様々な供給業者から到着させ、かつ、多くの様々な顧客
の場所へ向かわせるために、クロスドックを効果的に配置することができ、これ
により、出荷および処理の全体的コストが最小となる。

【００２７】図３を参照すると、前記サプライチェーンネットワーク７０のオペレーション
については、以下の５つの主要モジュールの形に分類することができる：１）注文管理（Order Management）４０ − 顧客の予測の収集、および、要求
が有効（valid）であるか否かについての判断、２）計画（Plannning）４２ − 顧客の需要が供給を超過しているか否かにつ
いての判断、および、需要が供給を超過した場合の解決法の提供、３）調達（Procurement）４４ − 購入工程の実行、４）注文処理（Fulfillment）４６ − 供給業者から顧客への製品の輸送、５）課金および支払い（Billing and Payment）４８ − 送り状の生成および
支払い。

【００２８】典型的な顧客の需要は、通常的は、図３に示されるモジュールの順序に従うが
、より十分に後述するように、これらのモジュールは、独立して（ときには同時
に）機能する。例えば、ある日の需要に関する注文管理は、前日の需要の注文処
理と同時に発生することがある。従来技術のサプライチェーンシステムは、これ
らの機能の多くを、各々の機能モジュール間の連絡を行わずに、完全に独立した
事象として処理していた。例えば、注文処理については、供給業者の支払いから
（または、注文管理からさえも）独立して処理されていた。さらに、情報管理は
、ユーザーに利益を与えるように、これらのモジュールの各々に組み込まれてい
る。情報管理とは、顧客および供給業者にとって有益であるサプライチェーン管
理情報の蓄積を指す。

【００２９】本発明は、多くの顧客と多くの供給業者とに関する全ての活動を、同時に管理
する。これにより、本発明が、これらのタスクを、全ての当事者のためにより能
率的に実行することが可能となる。この点について例示するために、大きな仕事
を急ぎで受注した顧客Ｘが、ある部品を供給業者Ａ，Ｂに要求しているが、供給
業者Ａ，Ｂがいずれも顧客の必要性を満たすための棚卸資産を有していない場合
について考える。顧客および供給業者による多くの需要および供給の必要性を同
時に処理することにより、本発明によるサプライチェーンアーキテクチャは、求
められているものと同じ形式の臨時の部品を供給業者Ｃが有していると判断する
ことができ、かつ、他の顧客Ｙが自分の必要性のために供給業者Ｂ，Ｃのいずれ
か一方を利用しようとしていると判断することができる。これにより、サプライ
チェーンサーバーは、顧客Ｙが要求している臨時の部品を供給業者Ｃが出荷する
ように取り決めることができ、これにより、供給業者Ｂは、顧客Ｘが要求してい
る臨時の部品を出荷することができる。

【００３０】一実施形態において、前記サプライチェーンネットワーク７０は、全ての取引
が互いにリンクされかつ規則的に実行されるケイデンス（cadence）を用いて実
施される。例えば、サプライチェーンネットワーク７０を利用する全ての顧客は
、ある商品ファミリー（commodity family）内の全ての部品を、週の所定の曜日
に注文することができる。これにより、ネットワークユーザーに伝えられる注文
処理活動において、大きな規模の経済（economy of scale）が生じる。生産の要
求が週末にかけて頻繁に計画されることにより、月曜日が注文管理サイクルを開
始するのに望ましい曜日となる。こうして、本発明の一実施形態において、計画
は月曜日の夜に発生し、全ての部品の注文処理は火曜日に発生し、かつ、課金は
火曜日の夜に発生する。部品の中には、非常に大容量の形で用いられるものもあ
れば、壊れやすいものもある。本発明によれば、これらの部品については、時間
毎に均等に区画された毎日のケイデンスに基づいて、計画し、注文し、かつ、注
文処理を行うことができる。従来の技術においては、注文された製品に関して予
想される配達状態に応じて、多くの日付を入力し、追跡し、かつ、変更する必要
があった。このことは、非常にコストがかかり、かつ、時間を浪費するタスクで
ある。その理由は、情報、製品、および、流通の順序は、ネットワークを利用し
ている特定の顧客、供給業者、および、ロジスティクスプロバイダの必要性に応
じて変化し得るためである。

【００３１】顧客による製品の利用は、しばしば、ＥＲＰコンピュータシステムにより週単
位で決定され、本発明によるサプライチェーンネットワークは、注文と、計画と
、累積的には一週間よりも随分と短い配達時刻とを実現する。このシステムによ
って、顧客は、仕事の終わりに生産計画を著しく変動させることが可能となり、
さらに、コストがかかる棚卸資産の形で多数の部品の寄せ集めを用いることなく
、必要な部品を受け取ることが可能となる。これにより、ＥＲＰシステムにおい
て多くの日付を管理する必要もなくなる。

【００３２】引き続き、図３を参照して、以下に、個々のモジュールについて詳細に説明す
る。再び述べると、これらのモジュールの一部は同時に機能することに留意され
たい。

【００３３】《II．注文管理（Order Management）》注文管理モジュール（Order Management Module）は、サプライチェーンサー
バー７４が直接的に顧客７２と対話する環境を提供する。このモジュールは、顧
客の需要を捕捉するために必要な工程と、該顧客の需要を処理するために必要な
有効化（validation）および承認（approval）とを含む。

【００３４】顧客７２は、多様な方法で、所望の製品に対する需要をサプライチェーンサー
バー７４に提出する。例えば、好ましい実施形態において、顧客７２は、１３週
分の予測と、第０週の毎日のコールアウト（week 0 daily callouts）と、アド
ホック（ad hoc）な要求とを用いて要求を提出する。各週毎に、顧客７２は、サ
プライチェーンサーバー７４との契約において条件指定された場所に対する計画
／出荷の各々に関して、１３週分の予測を提出する。ＤＲＡＭ（ダイナミックラ
ンダムアクセスメモリ）のような大容量および揮発性商品に関して、顧客７２は
、第０週（すなわち、今週）の需要について、毎日のコールアウトを送ることに
より伝達する。さらに、顧客７２は、アドホックな要求を送ることにより、予測
されていない需要をサプライチェーンサーバー７４に提出する能力をも有する。
このようなアドホックな要求とは、予測がなされずに、供給業者と顧客との間の
契約上の同意において規定された予測の許容範囲内に収まらず、さらに、ネット
ワークに関する契約において規定された予測の許容範囲内にも収まらなかった故
に、どの供給業者も受注する準備ができていない注文である。したがって、アド
ホックな注文は、人間のプランナー（これについては、後述する）による介入が
なければ、標準的なケイデンスの範囲内で注文処理が行われない可能性がより高
い。

【００３５】いったん、顧客の需要が受け取られると、この需要は、注文管理モジュールに
より、顧客による最初の設定工程中に略述された契約の条項（terms）／詳細内
容に対して有効化される。この有効化は、予測が完全であることを検証（verify
）すること、および、全ての部品番号がサプライチェーンサーバーシステム内に
存在することを保証し、かつ／または、必要な全ての情報が完全かつ正確である
ことを保証することを含むことができる。顧客の需要が無効（invalid）、異常
、または、不完全であれば、サプライチェーンサーバー７４は、例外的に、要求
に不備があることを顧客に通知し、かつ、解決工程が開始される。注文管理モジ
ュールを実行することによって、受け取った予測の有効性（validity）を向上さ
せることができる分析の例は、 − 前週の予測に対する主要な変化を識別すること、 − 購買パターンにおける主要な累積的変化を識別すること、および、 − 生産能力（capability）に基づいて同意された以上の要求を識別すること
、を含むが、これらに制限されるものではない。

【００３６】前記サプライチェーンサーバー７４またはプランナーは、供給および需要の必
要性を、（例えば、操業開始、操業終了、工場の操業停止のような）既知である
顧客の事象に対してチェックすることもできる。後述するように、プランナーは
、サプライチェーンサーバー７４が、利用可能な供給品によって、全ての非制約
的な（unconstrained）需要を注文処理できなくなった場合に介入するサプライ
チェーンサーバー７４のオペレータの従業員である。プランナーは、例えば、電
子メールを用いて、顧客および供給業者と連絡を取り、かつ、それぞれの生産計
画の調整を提案して、全ての当事者のために、より優れた供給と需要とのバラン
スを取る。サーバー７４は、例外報告を用いて、これらの状況をプランナーに通
知する。プランナーは、サプライチェーンサーバー７４により生じた貴重なかつ
独自の情報を提供するプランナーサプライツール（Planner Supply Tool）（こ
れについては、後述する）を用いることができる。これにより、プランナーは、
供給と需要とのバランスをどのように取るのかについて、顧客または供給業者が
独自に行う方法よりも優れた提案を行うことができる。

【００３７】無効な需要に応答して、前記サプライチェーンサーバー７４は、電子メールま
たは他のメッセージ警告を、影響を受ける可能性を有する全ての当事者（サプラ
イチェーンサーバーの従業員（すなわち、プランナー）を含む）へ送る。このよ
うなメッセージ警告は、必要な注意に関する相対的な重要度および即時性を示す
ための“赤色光（Red light）”または“黄色光（Yellow light）”の警告を発
行することを含み得るが、これに制限されるものではない。このような警告の例
について、以下に示す。警告メッセージを生じさせるために、他の基準を用いる
ことができることも明白である。

【００３８】〈用語体系〉・Ｎ_ab ＝第"ｂ"週に配達すべき数量に関して、第"ａ"週になされる予測（ここ
で、ｂ＞ａ）、・Ｋ_c ＝第"ｃ"週において利用可能な生産能力、第０〜１３週の異常性：黄色光ａ，ａ−１，ａ−２，…ａ−１３全てに対して、 0.8 ＜ E N_ab/E N_a-1b-1 ＜ 1.2（0＃b-a＃13に関して合計する）（週から週へかけての必要品（requirement）の総計の変化は２０％のみ）
、および、 0.75 ＜ E N_ab/max(E N_ab)（0＃b-a＃13に関して合計する）（過去１３週にわたる変動性（volatility）の上昇は２５％のみ） E N_a+1b+1/min(E N_ab) ＜ 1.25（0＃b-a＃13に関して合計する）（過去１３週にわたる変動性の下降は２５％のみ）・第９〜１３週の異常性：黄色光ｂ＝ａ＋９，１０Ａ，１１，１２，１３に対して、 0.8 ＜ N_ab/ N_a-1b-1 ＜ 1.2 （週から週へかけての必要品の変化は２０％のみ）・第７，８，９週の異常性：黄色光ｂ＝ａ＋７，８，９に対して、 0.8 ＜ N_ab/ N_a-1b-1 ＜ 1.2 （週から週へかけての必要品の変化は２０％のみ）赤色光Ｎ_ab＞Ｋ_b （どの週の必要品も、生産能力を超過しない）・第０〜６週の異常性：黄色光 0.8 ＜ E N_ab/E N_a-1b-1 ＜ 1.2（0＃b-a＃6に関して合計する）（週から週へかけての必要品の変化は２０％のみ）、および、ｂ＝ａ＋０，１，２，…，６に対して、 0.9 ＜ N_ab/ N_a-1b-1 ＜ 1.1 （週から週へかけての必要品の変化は１０％のみ）赤色光Ｎ_ab＃Ｋ_b （どの週の必要品も、生産能力を超過しない）、または、 0.7 ＜ E N_ab/E N_a-6b ＜ 1.05（0＃b-a＃6に関して合計する）（６週間前の生産において開始された必要品と比較した場合に、用いられて
いない必要品は３０％のみ、および、５％のみの超過（over））・第０，１，２週の異常性：赤色光ｂ＝ａ＋０，１，２に対して、 0.95 ＜ N_ab/ N_a-1b-1 ＜ 1.05 （週から週へかけての必要品の変化は５％のみ）

【００３９】顧客の信用履歴（credit history）および承認についても、注文管理モジュー
ルの一部として組み込むことができる。需要が有効化されかつ顧客の信用（cred
it）がチェックされた後に、需要は、計画モジュールへ送られる。信用状態を保
留されている（credit hold）顧客に関する需要については、アカウントマネー
ジャ（Account Manager）による作用のために、サスペンドファイルへ送ること
ができる。

【００４０】以下に、注文管理モジュールの例示的な実施形態について説明する。図４を参
照すると、規則的な需要スケジュール中において、注文管理モジュールにより実
行される需要捕捉および有効化工程を示す図である。規則的な需要スケジュール
中において、サプライチェーンサーバー７４は、２０４において、顧客による１
３週分の予測２００と、第０週の毎日のコールアウト（week 0 daily callouts
）とを、顧客から受け取る。これらの予測については、複数の顧客からのもので
あってもよく、または、一人の顧客による複数のソースからものであってもよい
。受け取り回路２０４は、例えば、ＥＤＩ（電子データ交換）予測や、（例えば
、ＥＸＣＥＬ（登録商標）のスプレッドシートによる）電子メールや、ＥＤＩ購
買注文（“ＰＯ”）を通して、または、ＸＭＬ（拡張可能なマーク付け言語）通
信を通して、顧客の需要を捕捉することができる。受け取り回路２０４は、顧客
との契約においては条件指定できない特定のサービスを捕捉することもできる。
例えば、緊急の配達（expedited delivery）や、特殊なラベリングや、パッケー
ジングなどを、全て捕捉することができる。サプライチェーンサーバー７４は、
２０６において、顧客の需要２００，２０２を、該サプライチェーンサーバー７
４が用いる標準的なフォーマットに変換して、該顧客の需要を分析する。変換２
０６に問題があれば、全ての技術的問題点を修正するためのエラールーチン２０
８が実行される。好ましい実施形態において、このような全ての技術的問題点は
、営業日の終わりまでに解決される。その後に、遅延回路２１０は、全ての変換
された需要が貯蔵されることを保証し、かつ、必要とされる機能上の有効化（fu
nctional validation）が、営業日の終わりまでに実行される。このような遅延
によって、サーバー７４が、全ての顧客のための需要（２００，２０２）を蓄積
することが可能となる。

【００４１】顧客情報収集回路２１２は、変換された顧客の需要を、対応する顧客の契約２
１４、および、該顧客の製品に関する顧客製品情報２１３と比較する。前記情報
２１３は、例えば、承認された供給業者、仕様の改訂レベルなどを含む。

【００４２】有効化回路２１６は、変換された需要が有効であるか否かを判断する。有効化
回路２１６は、例えば、需要している顧客が実際にサプライチェーンネットワー
ク７０の顧客であるか否かを検出する。さらに、有効化回路２１６は、場所に対
する計画／出荷と部品番号との全ての組み合わせに関して予測がなされていると
いう点で、および、全ての部品番号が特定の数量を有しているという点で、顧客
の予測２００が完全であるか否かを検出する。最終的に、有効化回路２１６は、
要求された部品番号が、顧客７２とサプライチェーンサーバー７４を運営するエ
ンティティとの間で契約された有効な部品に関連することを検証することができ
る。

【００４３】前記有効化回路２１６が、特定の顧客の需要が有効ではないと判断すれば、エ
ラールーチン２１８が実行され、この場合に、未払いの（outstanding）問題を
解決するための通知が、アカウントマネージャに送られる。アカウントマネージ
ャは、全ての顧客の支払い履歴を評価することにより該顧客に関する現在の評価
（standing）を維持するために用いられる。次に、サプライチェーンサーバー７
４は、ある点において需要が不完全であることを知らせるための例外通知を、顧
客７２に送る。例外通知自体は、作用を受けるまではサスペンドファイルに貯蔵
される。顧客の需要が有効であれば、サプライチェーンサーバー７４は、顧客の
信用履歴２２２を参照することにより、２２０において、顧客の信用状態をチェ
ックする。顧客の信用評価が２２４において承認されれば、サプライチェーンサ
ーバー７４は、計画モジュール（図８）へ分岐する。顧客の信用評価が２２４に
おいて承認されなければ、エラールーチン２２６が開始され、この場合に、プラ
ンナー、アカウントマネージャ、および、クレジットマネージャ（Credit Manag
er）は、問題の解決法を考え出そうとする。支払いの遅延または滞納状態の預金
口座は、クレジットマネージャにより監視される。信用状態を拒否された全ての
顧客の需要は、クレジットサスペンドファイルに貯蔵される。劣悪な信用状態の
故に顧客の需要が拒否されれば、顧客の購買の意向について知らせる通知が、ア
カウントマネージャと、クレジットマネージャと、プランナーとに送られる。こ
のような状況において、プランナーは、顧客の要求について考慮することができ
るが、信用問題が解決されるまでは、実際に計画を実施する義務はない。

【００４４】アドホックな需要に関して、注文管理モジュールの工程の流れが図５に示され
ている。図５を参照すると、図４の規則的な顧客の予測の場合のように、サプラ
イチェーンサーバー７４は、２３０において、アドホックな需要２３２を受け取
り、かつ、２３４において、前述したように、アドホックな需要２３２を標準的
なフォーマットに変換する。再び述べると、アドホックな需要２３２については
、例えば、ＥＸＣＥＬ（登録商標）のスプレッドシートによる電子メールや、Ｅ
ＤＩ購買注文（“ＰＯ”）を介して捕捉することができる。顧客との契約におい
て条件指定されなかった、緊急の配達（expedited delivery）や、特殊なラベリ
ングや、パッケージングのような追加的サービスもまた捕捉される。規則的な顧
客の予測とは異なり、注文の課金情報を追跡すべく、アドホックな需要を識別す
るためのフィールド（図示せず）が確立される。このフィールドについては、ア
ドホックな注文に対して追加料金を発生させるために任意選択的に用いることが
できる。顧客の需要を標準的なフォーマットに変換することに問題があれば、全
ての技術的問題点を修正するためのエラールーチン２３６が実行される。好まし
い実施形態において、このような全ての技術的問題点は、営業日の終わりまでに
解決される。

【００４５】その後に、遅延回路２３８は、全ての変換された需要が貯蔵されることを保証
し、かつ、必要とされる機能上の有効化が、営業日の終わりまでに実行される。
顧客情報収集回路２４０は、変換された顧客の需要を編集しかつ該需要を顧客の
契約２１４および顧客製品情報２１３と比較することにより、有効化を実行する
。

【００４６】有効化回路２４４は、変換された需要が有効であるか否かを判断する。有効化
回路２４４は、例えば、需要している顧客が実際にサプライチェーンネットワー
ク７０の顧客であるか否かを検出する。さらに、有効化回路２４４は、要求され
た部品番号が、顧客７２とサプライチェーンサーバー７４との間で契約された有
効な部品であるか否かを検出する。正常に（normal）予測された需要とは異なり
、アドホックな需要２３２が完全であるか否かを判断するための有効化は不要で
ある。その理由は、このような需要は、予測されていない需要であり、かつ、１
つ以上の顧客の部品番号を含み得るためである。

【００４７】前記有効化回路２４４が顧客の需要が有効ではないと判断すれば、エラールー
チン２４６が実行され、この場合に、未払いの問題を解決するための通知が、ア
カウントマネージャに送られる。次に、サプライチェーンサーバー７４は、ある
点において需要が不完全であることを知らせるための例外通知を、顧客７２に送
る。例外通知自体は、サスペンドファイルに貯蔵される。顧客の需要が有効であ
れば、サプライチェーンサーバー７４は、顧客の信用履歴２５０を参照すること
により、２４８において、顧客の信用状態をチェックする。顧客の信用評価が２
５２において承認されれば、サプライチェーンサーバー７４は、計画モジュール
へ分岐する。顧客の信用評価が２５２において承認されなければ、エラールーチ
ン２５４が開始され、この場合に、プランナー、アカウントマネージャ、および
、クレジットマネージャは、問題の解決法を考え出そうとする。信用状態を拒否
された全ての顧客の需要は、クレジットサスペンドファイルに貯蔵される。劣悪
な信用状態の故に顧客の需要が拒否されれば、顧客の購買の意向について知らせ
る通知が、アカウントマネージャと、クレジットマネージャと、プランナーとに
送られる。

【００４８】こうして、前記サプライチェーンサーバー７４の注文管理モジュールは、従来
技術において用いられていた購入注文システムに取って代わる予測システムを用
いることができる。従来技術のサプライシステムにおいては、供給業者は、予測
を調べなかったので、予測が契約上の同意に反するものであるか否かを、または
、予測の中に望ましくないエラーが存在するか否かを判断することができなかっ
た。供給業者は、特定の顧客が何を供給業者に与えたのかについて調べるだけで
あった。たとえ供給業者がＭＰＲシステムを用いたとしても、ＭＲＰの需要は、
頻繁に著しく変動するので、供給業者は、これらの需要を検討して異常なまたは
予想されていない要求を確認するための能力を有していなかった。したがって、
供給業者は、しばしば、在庫品の予想消耗量について決して確信を持てないよう
な様式で、自分たちの在庫品を補充する補充アルゴリズム（replenishment algo
rithms）を用いていた。

【００４９】本発明は、契約上の同意との一貫性と以前に行われた予測とに関して、顧客の
予測を検討することにより、これらの問題を克服する。これにより、本発明は、
連続的な配達およびパフォーマンスを生じさせ、これにより、供給業者が過剰な
棚卸資産を有している場合に生じる望ましくない残り物の材料の量を低下させる
。需要の変動性（volatility）が最小となるので、供給業者は、サプライチェー
ンアーキテクチャから利益を得る。このことは、需要予測の蓄積と、需要を検討
する濾過（filtration）システムとに起因する。供給業者は、今や数週間前に多
くの顧客からの需要予測を与えられているので、より確信を持って、自分たちの
在庫品を補充することもできる。電子部品に対する需要のような、非常に需要の
変動が激しい業界においては、ある週から次の週にかけて需要が５０％変更され
る可能性もあるので、従来技術のサプライチェーンは、顧客の予測に基づいて機
能することができなかった。従来技術のサプライチェーンは、顧客へ製品を配達
するのにあまりにも時間がかかり過ぎるので、これらの非常に変動が激しい需要
に追従していくことができなかった。しかしながら、本発明のサプライチェーン
アーキテクチャは、はるかに迅速な配達（例えば、１週間以内）を可能にし、こ
れにより、顧客の予測に基づく需要が可能となる。

【００５０】さらに、前記注文管理モジュールは、注文の状態をチェックする能力を顧客に
提供する。通常の顧客は、何の製品を購入しているのかと、その製品がいつ配送
されるのかとについて正確に知ることに対して関心を有している。サプライチェ
ーンサーバー７４が追跡できる幾つかの典型的な事象について、以下に列挙する
。これらの通知の各々において、情報をサプライチェーンサーバー７４に送るこ
とができ、これに応じて、該サプライチェーンサーバー７４のエクストラネット
（extranet）（サプライチェーンサーバー７４のハードウェアについては、より
十分に後述する）を更新することができる。

【００５１】〈注文リリース通知〉計画モジュールにより提供される注文リリース通知については、特定の注文が
一人または複数の供給業者７６へリリースされた後に生成することができる（１
つの顧客の注文について、複数の供給業者により注文処理を行う可能性がある）
。この事象については、顧客７２の注文が検討され、かつ、該注文を注文処理す
る責任を有する供給業者へ渡されたことを知らせるために用いることができる。
次に、計画モジュールは、予測が供給業者へリリースされた時点で、エクストラ
ネットを更新する。

【００５２】〈出荷品積み込み通知〉運送業者が所定の組の供給業者７６から製品を積み込んだことを示す出荷品積
み込み通知を、３ＰＬ７８によりサプライチェーンサーバー７４へ送ることがで
きる。この事象は、供給業者７６および３ＰＬ７８のパフォーマンスを監視する
ために用いる情報を、サプライチェーンサーバー７４に提供する。この事象は、
さらに、予想された供給業者の出荷と実際の供給業者の出荷との間の食い違いを
識別すべく、供給計画に対して比較することができる情報を捕捉する。

【００５３】〈クロスドック到着通知〉製品がクロスドックに到着したことを示すクロスドック到着通知を、３ＰＬ７
８によりサプライチェーンサーバー７４へ送ることができる。この事象は、さら
に、３ＰＬ７８のパフォーマンスを絶えず監視するための情報を、サプライチェ
ーンサーバー７４に提供する。

【００５４】〈出荷通知〉注文が顧客７２へ向かう途中であることを示す出荷通知を、３ＰＬ７８により
サプライチェーンサーバー７４へ送ることができる。

【００５５】〈税関到着（Custom-In）通知〉適用可能な場合に、製品が税関内にあることを示す税関到着通知を、３ＰＬ７
８によりサプライチェーンサーバー７４へ送ることができる。

【００５６】〈税関出発（Custom-Out）通知〉適用可能な場合に、製品が税関から出たことを示す税関出発通知を、３ＰＬ７
８によりサプライチェーンサーバー７４へ送ることができる。

【００５７】〈配達証明（Proof of Delivery：ＰＯＤ）通知〉顧客の出荷品が条件指定された場所へ配達されたことを示すＰＯＤ／最終通知
を、３ＰＬ７８によりサプライチェーンサーバー７４へ送ることができる。

【００５８】〈流れ監視（Flow Monitoring）〉前記サーバー７４は、サプライチェーン内のボトルネックまたはピンチポイン
ト（pinch point）を通る製品の流れを監視することができる。例えば、特定の
目的地へのフライトを予約したり、または、特定の都市において税関を通過させ
ることが困難なことがある。部品がフライトからはじき出された時点で、または
、込み合ったフライトに搭載された場合に、通知を送ることができる。通知を供
給業者の生産ラインにも送ることができる。

【００５９】《III．計画（Plannning）》前記サプライチェーンネットワークの計画モジュールは、顧客の需要を満たす
ために供給業者７６のソースをマッチング（matching）させる責任と、注文処理
モジュールを開始する責任とを有する。この能力は、産業界の傾向、商品／製品
の傾向、顧客の予測の正確さ、および、供給業者のパフォーマンスに関する重要
なリアルタイムデータを捕捉するための輸送手段（vehicle）としても機能する
。このデータは、サプライチェーンネットワーク７０がその供給業者７６と顧客
７２とに提供する毎日の管理報告および追加的な専門サービスの多くに関する基
礎を構成する。

【００６０】前記サプライチェーンネットワーク７０の長期計画機能については、頻繁な通
知や高い頻度によって実行する必要がないので、人為的に実行することができる
。しかしながら、製造および材料調達のリードタイム（lead time）内における
短期計画機能については、非常に高い頻度で実行されるので自動化すべきである
。短期計画の結果については、およそ数時間または数分以内で、高い精度によっ
て実行可能であるべきである。そうしなければ、計画は、もはや、今日の多くの
市場に特有の速いペースでの変化に適用できなくなる。

【００６１】前記計画モジュールについては、多数の事象により誘発する（trigger）こと
ができる。これらの事象の例示的実施形態は、顧客の計画期間（例えば、四半期
または１３週間）の予測の受け取り、第０週の需要に関する毎日の予測の受け取
り、顧客からのアドホックな注文（予測されていない需要）の受注、出荷時期に
おける供給業者の公約不履行（de-commit）（出荷不足）、または、返品部品の
取り替え（replacement）の遅延を含む。これら全ての可能性については後述す
る。これら全ての状況において、工程は、顧客からの需要情報、（必要であれば
）供給業者に対する顧客の選好度、供給業者からの現在の生産能力情報、顧客の
部品と、サプライチェーンネットワーク７０内で用いられる他の類似部品とを相
互参照する表、および、サプライチェーンネットワーク７０内で用いられる部品
番号と供給業者の部品番号とを相互参照する表、のような多様な入力に依存する
。このような表の例については、"SYSTEM AND METHOD FOR GENERATING A CROSS
REFERENCE GUIDE"として２０００年１１月２日に出願された同時係属中の出願で
ある第０９／７０４，６４３号において見出すことができ、この内容全体は、本
明細書に参照として組み込まれている。

【００６２】前述したように、好ましい実施形態においては、顧客は、１３週分の需要予測
を、その期間にわたって必要とする全ての部品に関して、週毎に提出する。計画
モジュールにおいて、サプライチェーンサーバー７４はこれらの予測を管理し、
かつ、需要は、整理統合され（consolidate）、供給業者の部品番号に変換され
、かつ、特定の供給業者の必要性（requirements）に変換される。サプライチェ
ーンサーバー７４は、需要の集計や、大雑把な生産能力のマッチングや、供給計
画の最適化を介して、この変換を達成する。さらに、前記サーバー７４は、顧客
７２からの予想需要および履歴データに基づいて、予測を推定することもできる
。

【００６３】前記サプライチェーンサーバー７４は、同じまたは類似の供給業者の製造工程
を用いて行われた製品に対する需要を蓄積することにより、集計を実行する。顧
客（および、しばしば、供給業者）は同じまたは類似の製品に異なった部品番号
を割り当てることを好むので、同一の部品番号をマッチングさせようとすること
による集計は、概して非能率的である。しかしながら、供給業者は、自分たちの
生産設備をスケジューリングするために、顧客の注文をＭＰＵまたはマスタープ
ランニングユニット（Master Planning Units）（マスタープランニングファミ
リーとも称される）内に集計するので、サプライチェーンサーバー７４は、同じ
供給業者が定義したこれらのＭＰＵを用いて、その集計を実行する。

【００６４】前記サプライチェーンサーバー７４は、最初に、集計された需要を、顧客が好
ましい供給業者であると決定した特定の供給業者に割り当てることにより、大雑
把な生産能力のマッチングを実行する。各々の顧客７２は好ましい供給業者に関
して独自の定義を行い、かつ、サプライチェーンサーバー７４は、この情報を、
各々の顧客の部品番号のために、データバンクに保持する。サプライチェーンサ
ーバー７４は、各々の好ましい供給業者に対するこのデフォルト状態の需要割り
当てが、供給業者７６により与えられた生産能力の制約範囲内に収まるか否かを
調べるテストを行う。所定の供給業者に対する需要が該供給業者の生産能力の制
約範囲を超過した場合には、サプライチェーンサーバー７４は、顧客が二番目に
選択した選好度に基づいて、または、ネットワークが用いる他のアルゴリズムに
基づいて、他の供給業者へ再割り当てを行う。サプライチェーンサーバー７４は
、この反復的アプローチを用いて、利用可能な供給業者に対する大雑把な需要の
割り当てを決定する。

【００６５】前記サプライチェーンのプランナーについては、サプライチェーンの最適化を
行うための介入が必要であるか否かを判断すべく、大雑把な生産能力のマッチン
グを検討するために用いることができる。多くの形式の部品の供給／需要は非常
に変動が激しくかつ非常に急な通知に基づいて変更されるので、プランナーは、
大雑把な生産能力のマッチングに対して人為的に調整を行うために介入したいと
希望することがある。このような介入の例として、最先端部品の供給業者は、し
ばしば、ある期間にわたって自分たちの公式の生産能力通りに生産できないとい
う周期的な生産上の問題を被る。このような例においては、サプライチェーンサ
ーバー７４には、供給業者により、電子メッセージや、電話や、または、ＡＳＮ
（事前出荷通知）を通して、期待されていたよりも少数の部品が実際には出荷さ
れたことを知らされる。次に、サプライチェーンのプランナーは、サプライチェ
ーンネットワーク７０上で自分たちが利用可能な広範な情報を用いて、人為的に
システムをオーバーライドすることにより、または、新たなパラメータをシステ
ムに入力することにより、需要製品の再割り当てを行う最適な方法を決定する。
この結果、影響を受ける供給業者の需要が減少し、かつ、他の供給業者の需要が
増加する。これにより、サプライチェーンネットワーク７０については、全ての
サプライチェーンネットワークの顧客が期待通りに部品を受け取ることがより確
実であるとプランナーが感じることができるように制御することができる。同様
に、ときには、市場をより競合させるべく、ある需要を好ましくない供給業者へ
割り当てることが顧客の最大の関心事である可能性があり、また、サプライチェ
ーンサーバー７４が、ある需要をシフトさせることによって、サプライチェーン
ネットワーク７０を最適化する可能性がある。

【００６６】サプライチェーンの最適化の結果は、供給業者の生産能力の制約範囲内で、全
ての顧客の需要を能率的に満たす供給計画である。ある揮発性商品（すなわち、
ＤＲＡＭ）に関する需要／供給マッチング工程については、第０週中に毎日実行
することができる。供給業者は、自分たちがこの計画をサポートする能力を有し
ていることを確認した後で、第０週中の需要の準備を行い、かつ、注文処理モジ
ュールにおいて注文処理工程を開始する。供給業者は、需要された製品に関連し
て、規定された生産に関する規約に、または、棚卸資産の管理に関する規約に従
うように要求される可能性もある。

【００６７】ときには、顧客は、サプライチェーンサーバー７４に、該顧客による週単位の
予測に最初から含まれていなかった数量および材料に関してアドホックな注文を
行う。このような場合において、新たな需要をサポートする生産能力の利用可能
性が、プランナーにより調査される。プランナーは、可能な場合には、新たな要
求に関するソースを識別し、かつ、注文処理モジュールにおいて注文処理工程を
開始する。

【００６８】供給業者７６が公約に応ずることができなければ（出荷不足）、プランナーは
、この状況を解決するために、顧客と供給業者との間の仲介者として作用するこ
とができる。必要に応じて、プランナーは、供給に関する代替的ソースを識別し
、かつ、注文処理モジュールを再度開始させる。材料が供給業者へ返品されかつ
後日に取り替え部品が必要とされれば、プランナーは、今後の需要を調整して、
取り替え部品の必要性に反映させる。

【００６９】これらの工程における取引上の性質は、サプライチェーンサーバー７４に、該
サーバー７４が提供できる幾つかの付加価値（value added）サービスにとって
重大な情報を提供する。この情報は、顧客／産業界の購買パターン、顧客の予測
の正確さ、供給業者のパフォーマンス、および、製品の推移（transitions）を
含む。後述する情報管理セクションに説明されるように、このような情報につい
ては、利用可能にすることができる。

【００７０】図６を参照すると、計画モジュールの作業工程中における情報の流れが示され
ている。複数の顧客７２（この図では、２人示されている）、複数の供給業者７
６（２人示されている）、３ＰＬ７８、および、運送業者９６が、サプライチェ
ーンサーバー７４に接続されている。計画モジュールは、供給業者７６が供給品
の不足量に関する前週の生産能力の例外９８を送りかつ顧客７２が予測１００を
サプライチェーンサーバー７４へ送ることによって開始される。予測１００は、
直ちに取り替えられずに未だ該予測に反映されていない前週の返品について考慮
するように調整される。（後述する調達モジュールの説明を参照。）サプライチ
ェーンサーバー７４は、これらの入力９８，１００を受け取り、かつ、予測１０
０において顧客が行った需要の有効化１０２を実行する。

【００７１】前記注文管理モジュールの説明において前述したように、サプライチェーンサ
ーバー７４は、予測１００の可変性（valiability）の評価１０４を行い、かつ
、該予測の可変性が定義パラメータに順応しない場合に、例外通知１０６を発行
する。顧客７２が要求した部品番号は、対応するサプライチェーンネットワーク
の部品番号に変換される。サプライチェーンサーバー７４は、１１０において、
サプライチェーンネットワークの部品番号に関する需要の可変性を評価する。顧
客評価１０４の場合のように、サプライチェーンサーバー７４は、全体的な需要
の可変性を判断する。この計算は、たとえ個々の顧客が許容範囲の超過を回避し
たとしても、特に多くの顧客が供給業者の許容限界点に近い注文を行った場合に
、全ての顧客による要求の総計が供給業者の総供給量を超過してしまう可能性が
ある、という点で有用である。このような注文によって、供給業者の製品全体が
枯渇し、復旧するためにはかなりの時間がかかる可能性がある。次に、サプライ
チェーンネットワークの部品番号は、１１２において、対応する供給業者の部品
番号に変換される。

【００７２】供給業者７６の生産能力は、顧客７２の予測１００と関係した生産能力の問題
が存在するか否かを判断するために、１１４において有効化される。１１５に示
されるように、この工程は、現在の第０週の需要によって開始され、かつ、１２
週分の需要にわたって反復される。生産能力に関するあらゆる問題は、１１６に
おいて、通知１１８を供給業者７６へ送りかつ通知１２０を顧客７２へ送ること
により解決される。さらに、顧客７２は、該顧客７２が予測１００の一部または
全てに関する任意選択的な中止１２４を送ることを可能にする中止コード（abor
t code）１２２を受け取る。次に、サプライチェーンサーバー７４は、供給業者
７６との全ての需要問題１２６を解決し、かつ、制御は、図１０Ａの調達モジュ
ールへ分岐する。このような中止は、顧客がサプライチェーンサーバー７４を通
してそのアカウントにアクセスした場合に表示され、これにより、顧客は、特定
の部品に関する注文が中止されたことを知る。以下に、これらの工程について、
例によって詳細に説明する。

【００７３】以下に、図７を参照すると、正常な計画シナリオ中にサプライチェーンサーバ
ー７４が実行する工程が示されている。計画モジュールにおいて、サプライチェ
ーンサーバー７４は、顧客の予測に関する情報を、（前述の）注文管理モジュー
ルから受け取る。次に、サプライチェーンサーバー７４は、１３０において、全
ての有効化された顧客の要求を整理統合する。この整理統合は、顧客の部品およ
び番号に基づいて、全ての顧客の予測を、１つの大きなファイル（図示せず）の
形にグループ化することを含む。有効化自体については、注文管理モジュールの
欄で前述した。簡潔に述べれば、有効化は、顧客の需要が契約下において無効、
不完全、または、異常であるか否かを判断することを含む。有効化に問題があれ
ば、エラー工程１３２が実行される。エラー工程１３２についても、より十分に
前述してある。簡潔に述べれば、サプライチェーンサーバー７４は、有効化問題
を有する顧客と連絡を取って、需要の変更を理解しかつ解決する。このことは、
特定の部品番号に関して需要の数量を調整することを含む。これにより、あらゆ
る変更が、調整された予測に反映される。

【００７４】次に、前記整理統合された需要ファイルは、１３４において、対応するサプラ
イチェーンネットワークの部品番号を識別するために分析され、かつ、サプライ
チェーンネットワークの部品番号に対応する部品を提供する供給業者へ提案され
る。供給業者の識別は、前述のように顧客と協議された契約に基づくものである
。分析１３４において、独自の識別子が、各週の間における各々の顧客からの各
々の部品に対する需要を示すために割り当てられる。これらの識別子は、各々の
需要に関する会計報告（audit trail）を作成するために用いられる。さらに、
分析１３４は、前週の需要からの予測１００を評価して、（注文管理モジュール
の説明において、より十分に前述したような）例外的条件を判断する。

【００７５】次に、前記サプライチェーンサーバー７４は、１３６において、整理統合され
た需要ファイルのサプライチェーンネットワークの部品番号を、対応する供給業
者の部品番号に変換する。この変換については、顧客の部品番号を用いて行うこ
ともできる。次に、整理統合された需要ファイルは、１３８において集計されて
、これにより、サプライチェーンサーバー７４と供給業者７６との間の契約上の
要因に基づいて、供給業者のＭＰＵが生じる。次に、整理統合された需要ファイ
ルは、１４２において、供給業者７６の生産能力と、サプライチェーンサーバー
７４と供給業者７６との間の契約上の規定に基づいて有効化される。これらの契
約上の規定は、あらゆる契約上の生産能力、または、整理統合された需要ファイ
ルに基づいて可能にすることができる供給業者の凍結限界点（freeze horizon）
に関連する。最終的に、サプライチェーンサーバー７４は、１４４において、集
計された需要が供給業者の生産能力よりも多いか否かを問い合わせる。供給業者
の生産能力については、供給業者７６がサーバー７４へ供給したデータから、ま
たは、供給業者７６が自分たちのそれぞれのデータベースへサーバー７４がアク
セスすることを可能にすることにより、判断することができる。需要が生産能力
よりも多くなければ、サプライチェーンサーバー７４は、図１０Ａを参照して説
明する段階３３０へ分岐する。需要が生産能力よりも多ければ、サプライチェー
ンサーバー７４は、図８に示されるような、制約された供給計画ルーチン１４８
へ分岐する。

【００７６】図８を参照すると、制約的な（constrained）供給計画ルーチン１４８は、最
初に、１５０において、需要と供給との間にいかなるアンバランスも結果的に生
じないことを保証しようとして、顧客の需要を再分配する。この再分配は、反復
的工程を用いて実行され、かつ、プランナーは、供給業者の生産能力と契約上の
凍結限界点とに鑑みて、プランナーツール（図２４を参照して後述する）を用い
て代替的供給ソースを決定する。次に、サプライチェーンサーバー７４は、１５
２において、新たな結果として生じた需要が供給業者の生産能力よりも多いか否
かを問い合わせる。再び述べると、需要が生産能力よりも多くなければ、サプラ
イチェーンサーバー７４は、調達モジュールにおける３３０へ分岐する。そうで
ない場合には、サプライチェーンサーバー７４は、供給業者への介入１５４へ分
岐する。供給業者への介入１５４において、サプライチェーンサーバー７４は、
供給業者７６の生産能力が需要に追従できない原因となっている状況（例えば、
原材料の制約、または、破綻的な生産能力の問題）について確認するために供給
業者７６と連絡を取り、かつ、可能な代替案（例えば、今後の生産能力の増大の
ために、前もって作るかまたは貯蔵しておく可能性）を評価する。これにより、
新たな供給業者の生産能力が生じる。

【００７７】前記供給業者への介入１５４において供給業者と連絡を取った後に、サプライ
チェーンサーバー７４は、１５６において、新たな生産能力が顧客の需要よりも
少ないか否かを問い合わせる。再び述べると、需要が生産能力よりも多くなけれ
ば、サプライチェーンサーバー７４は、調達モジュールにおける３３０へ分岐す
る。そうでない場合には、サプライチェーンサーバー７４は、顧客への介入１５
８へ分岐する。顧客への介入１５８において、サプライチェーンサーバー７４は
、顧客７２の柔軟性（例えば、部品の代用、配達日の前倒しまたは引き延ばし）
について確認するために顧客７２と連絡を取り、これにより、新たな顧客の需要
が生じる。前記顧客への介入１５８において顧客と連絡を取った後に、サプライ
チェーンサーバー７４は、１６０において、新たな顧客の需要が供給業者の生産
能力よりも多いか否かを問い合わせる。再び述べると、需要が生産能力よりも多
くなければ、サプライチェーンサーバー７４は、調達モジュールにおける３３０
へ分岐する。そうでない場合には、サプライチェーンサーバー７４は、供給割り
当てルーチン１６２へ分岐する。

【００７８】前記供給割り当てルーチン１６２において、供給業者から実際に利用可能な部
品（“制約部品”）は、需要している顧客の間で均等に割り当てられ、かつ、こ
れに応じて、顧客の予測が変更される。このような場合において、需要している
全ての顧客は均等数の制約部品を受け取ることができるか、または、需要してい
る顧客は、ある特定の顧客が要求している部品の個数と他の顧客が要求している
部品の個数との関係に基づいて、比例した（pro rata）分担数の制約部品を受け
取ることもできる。その後に、サプライチェーンサーバー７４は、調達モジュー
ルにおける３３０へ分岐する。

【００７９】図７および図８において詳述したような、顧客の予測に応じてサプライチェー
ンサーバー７４が実行する正常な計画シナリオの他に、計画モジュールは、アド
ホックな需要を処理することもできる。図９を参照すると、顧客からのアドホッ
クな需要に応じてサプライチェーンサーバー７４が実行する工程が示されている
。正常な注文の場合のように、サプライチェーンサーバー７４は、顧客需要ファ
イルを、注文管理モジュールから受け取る。次に、この需要ファイルは、１６６
において、対応するサプライチェーンサーバーの供給番号を識別するために分析
され、かつ、サプライチェーンサーバーの供給番号に対応する部品を提供する供
給業者へ提案される。供給業者の識別は、前述のように好ましい供給業者に関し
て顧客と協議された契約に基づくものである。分析１６６において、独自の識別
子が、各週の間における各々の顧客からの各々の部品に対する需要を示すために
割り当てられる。

【００８０】次に、前記サプライチェーンサーバー７４は、１６８において、需要ファイル
のサプライチェーンサーバーの供給番号を、対応する供給業者の部品番号に変換
する。この変換については、顧客の部品番号を用いて行うこともできる。その後
に、識別回路１７０において、サプライチェーンサーバー７４は、供給業者７６
と連絡を取り、かつ、アドホックな需要のために代替的な供給品を提供できる種
々の供給業者を識別する。

【００８１】その後に、前記サプライチェーンサーバー７４は、１７２において、第０週の
供給予測を修正して、供給業者および顧客の両方に関する新たな数量を反映した
修正予測１７８を生じさせる。さらに、修正された第０週の予測は、後述する調
達モジュールへ送られる。サプライチェーンサーバー７４は、１７４において、
購入注文番号と類似した各々の供給業者に対する特定の週の需要を示す独自の識
別子とともに、修正予測１７８を供給業者へ送る。最終的に、サプライチェーン
サーバー７４は、１７６において、アドホックな需要に関する積み込みおよび配
達指示を示す文書１８０を、３ＰＬ７８へを送る。アドホックな需要による注文
は、直接的に顧客へ送られ、かつ、大抵の場合には、前述したクロスドックを通
しては送られない。

【００８２】こうして、複数の顧客から予測を受け取って処理し、かつ、これらの予測を供
給業者の生産能力の総計に関して評価することにより、計画モジュールは、従来
技術において利用可能であったものよりも効率的かつ有用な供給計画を生じさせ
ることができる。さらに、ネットワークが複数の供給業者と連絡しているので、
計画モジュールは、顧客の需要の割り当てを供給業者間でシフトすることができ
、これにより、これらの需要が満たされることが保証される。

【００８３】《IV．調達（Procurement）》調達モジュール（Procurement Module）は、購入工程を実行する。この機能の
焦点は、注文処理工程（注文処理モジュールについては、より完全に後述する）
の正確さおよび適時性に関する有効化を含む購入対支払い（purchase-to-pay）
サイクルにある。調達モジュールが扱うさらなる領域は、供給注文を、供給業者
（データインターフェース）へ伝達することと、リバースロジスティックス（re
verse logistics）とを含む。

【００８４】前記リバースロジスティックスは、他の方法では得られない値を捕捉する目的
のために、または、適切な製品の処分のために、製品を該製品の通常的な最終目
的地から他の地点へ移動させる工程である。調達モジュールの好ましい実施形態
について、以下に説明する。サプライチェーンサーバー７４は、計画モジュール
の完了時に、ＥＤＩやウェブや電子メール、または、他の手段を介して、供給計
画（第０週の需要を含む）を供給業者７６へ伝送する。供給業者７６が供給計画
を実行しかつ３ＰＬ７８が出荷品を積み込んだ後に、供給業者７６は、ＡＳＮ（
事前出荷通知）をサプライチェーンサーバー７４へ伝送する。各々のＡＳＮは、
通常的には、１ラインの品目（one line item）を含み、かつ、契約協議過程に
基づいて同意された全ての必要なデータを含んで電子的に受信される。ＡＳＮは
、供給計画に対して有効化され、かつ、例外的事態がプランナーにより解決され
る。有効なＡＳＮは、購入注文と（ＡＳＮと購入注文との間には、概して、１対
１の関係が存在する。すなわち、全てのラインの品目は、供給業者の部品番号を
用いて識別される。）、クロスドック指示（３ＰＬへ伝送される）とを生成する
ために用いられる。これと平行して、ＥＲＰシステムにおいて、領収証が作成さ
れる。従来技術のサプライチェーンとは異なり、本発明は、購入注文と、需要部
品の入手を示す受領通知との生成を誘発するために、供給業者のＡＳＮを用いる
。これにより、従来技術のシステムにおいて行われていた多数の段階が切り詰め
られる。その理由は、需要が購入注文ではなく予測に基づくものであるので、注
文処理できる可能性がより高い供給業者へ伝達されるためである。

【００８５】顧客から毎日受け取られる全ての支払いは、各々の供給業者７６のために、サ
プライチェーンサーバー７４によりリスト化され、かつ、整理統合される。特定
の注文に対する支払いがＥＦＴ（電子資金移動）を介して顧客７２から受け取ら
れれば、サプライチェーンサーバー７４は、支払いファイルを銀行へアップロー
ドし、かつ、供給業者７６に支払いが行われる（例えば、１日に１回）。支払い
情報のリリースによって、ＥＲＰが自動的に更新される。さらに、銀行は、支払
い情報を示す確認書をサプライチェーンサーバー７４へ送る。支払いが小切手を
介して行われれば、送金通知書（remittance advice notice）および小切手に押
印され、かつ、供給業者へ送られる。

【００８６】顧客がサプライチェーンネットワーク７０を通して調達された材料を返品した
いと判断すれば、顧客は、返品認可（return authorization）を得るために、サ
プライチェーンサーバー７４に連絡を取る。サプライチェーンサーバー７４は、
供給業者７６から事前に認可されかつ返品受理に関する条項（terms）に基づい
て同意された返品認可を有している。サプライチェーンサーバー７４は、この認
可を顧客７２へ送り、かつ、コピーを供給業者７６へ送る。供給業者７６が確立
された返品工程を有していれば、サプライチェーンサーバー７４は、返品指示を
顧客７２へ送る。いったん、サプライチェーンサーバーが供給業者の運送業者９
６からＰＯＤ（配達証明）を得ると、サプライチェーンサーバー７４は、供給業
者の預金口座に借方記入（debit）を行い、かつ、顧客に貸方記入（credit）を
発行する。あらゆる借方記入または貸方記入は、最初に、供給業者からのあらゆ
る未決算の送り状（open invoices）に適用される。

【００８７】供給業者７６が確立された返品工程を有していなければ、いったん、前記認証
が実施されると、サプライチェーンサーバー７４は、必要に応じて、積み込み指
示を３ＰＬ７８へ送る。（１）供給業者が取り替え部品を棚卸資産内に有してい
るか否か、および、（２）顧客が取り替え部品を直ちに必要とするか否か、ま
たは、取り替え部品の需要を、既存の予測に追加することができるか否か、につ
いて判断する必要がある。顧客が取り替え部品を直ちに必要とすれば、供給業者
の利用可能な棚卸資産が好ましいソースとなる。棚卸資産が利用可能でなければ
、取り替え部品を速やかに製造し、かつ、顧客へ配達すべきである。取り替え部
品を既存の予測に追加することができれば、計画工程は、次の１３週分の予測に
組み込まれたさらなる需要によって継続される（計画モジュールの説明を参照）
。再び述べると、いったん、サプライチェーンサーバー７４が３ＰＬ７８からＰ
ＯＤを受け取ると、サプライチェーンサーバー７４は、供給業者の預金口座に借
方記入を行い、かつ、顧客に貸方記入を発行する。あらゆる借方記入または貸方
記入は、最初に、供給業者からのあらゆる未決算の送り状に適用される。以下に
、これらの工程について、例によって説明する。

【００８８】図１０Ａを参照すると、本発明による、調達モジュール中における情報の流れ
が示されている。サプライチェーンサーバー７４が、計画モジュールに関係した
作業工程を終了した後に、第０週（すなわち、今週）の供給需要が、適切な供給
業者７６へ送られる。供給業者７６は、３３０において、第０週の需要を実行処
理し、供給業者ＡＳＮ３３２を発行し、かつ、ＡＳＮ３３２をサプライチェーン
サーバー７４へ送る。サプライチェーンサーバー７４は、３３４において、供給
業者ＡＳＮ３３２を受け取る。概して、各々のＡＳＮ３３２には、１ラインの品
目のみが含まれる。ＡＳＮ情報自体は、供給業者の部品番号の形で存在する。供
給業者のＡＳＮの正確さのパーセンテージが低ければ、または、供給業者がＡＳ
Ｎを送ることができなければ、パッキングスリップ（packing slip）が代わりに
用いられる。

【００８９】前記サプライチェーンサーバー７４は、３３６において、該サプライチェーン
サーバー７４が顧客の予測に応じて生成した供給計画３３８に対してＡＳＮ３３
２を有効化する。３４０において、ＡＳＮが供給計画３３８マッチングしなけれ
ば、すなわち、供給業者が配達した製品が該供給業者に注文した製品とマッチン
グしないことが示されれば、エラールーチン３４２が実施され、かつ、供給業者
７６に通知される。このような場合においては、サプライチェーンサーバー７４
は、例えば、残りの部分的出荷を直ちにキャンセルしたり、または、出荷品を返
品するなどの、契約上の選択権を有する。そうでない場合には、サプライチェー
ンサーバー７４は、図１１に示される段階３４４へ分岐する。

【００９０】図１０Ｂを参照すると、本発明による、エラールーチン３４２の例が示されて
いる。サプライチェーンサーバー７４は、４６０において、合致した出荷品では
ないことを警告する例外通知４６２を供給業者７６へ送る。その後に、サプライ
チェーンサーバー７４は、ＡＳＮ３３２と供給計画３３８との比較が、所定の許
容範囲外となる出荷過剰（over-shipment）または出荷不足（short-shipment）
という結果となるか否かを判断する。

【００９１】前記比較が出荷過剰を生じさせれば、制御は段階４６６へ分岐し、この場合に
、サプライチェーンサーバー７４は、出荷過剰に関係した超過材料の処分を決定
する。このことは、プランナーにこの状況について供給業者７６および関連顧客
７２と討議させることにより実行され、これにより、超過材料の適切な処分が決
定される。その後に、サプライチェーンサーバー７４は、４７０において、結果
として生じた処分計画を実行処理し、次に、図１１に示される段階３４４へ分岐
する。処分の例は、超過材料を供給業者へ返品すること、追加的な材料を顧客へ
出荷すること（および、必要に応じて、予測を調整すること）、または、超過材
料を３ＰＬ７８に貯蔵することを含む。材料が供給業者へ返品される場合には、
供給業者７６には、何らかの追加的な貨物運送料が課金される。さらに、供給業
者７６には、超過材料を３ＰＬ７８に貯蔵するためにかかる追加的な費用も課金
される。

【００９２】前記比較が出荷不足を生じさせれば、サプライチェーンサーバー７４は、４６
８において、プランナーに供給業者７６および関連顧客７２に連絡を取らせるこ
とにより、この状況を評価する。この連絡は、出荷不足が単なる出荷の遅延であ
るか否かを、または、プランナーが供給の割り当てをさらに行う必要があるか否
かを判断するのに役立つ。プランナーは、この状況について、影響を受ける顧客
と討議することもできる。その後に、サプライチェーンサーバー７４は、４７２
において、利用可能な供給品のパーセンテージを各々の顧客に割り当て、かつ、
制御は、図１１に示される段階３４４へ分岐する。

【００９３】以下に、図１１を参照すると、前記段階３４４において、サプライチェーンサ
ーバー７４は、ＡＳＮ３３２に基づいて購入注文を作成する。購入注文は、各々
の顧客のための各々の部品に対して作成される。次に、サプライチェーンサーバ
ー７４は、３５０において、領収書を作成し、かつ、３４６において、３４４で
の購入注文に基づいてクロスドック指示３４８を生成する。領収書は、購入注文
と同様に、部品単位で、供給業者により系統的に整理される。クロスドック指示
３４８は、顧客による返品のための積み込み指示を含むことができる。出荷不足
の状況において、クロスドック指示３４８は、前述のようなプランナーの割り当
てを反映する。合致していない出荷物を受け取るとすぐに、３ＰＬ７８は、サプ
ライチェーンサーバー７４に通知する。クロスドック指示３４８に関する完全な
説明については、注文処理モジュールの説明において後述する。

【００９４】全ての第０週の需要が受け取られかつ処理されることを保証する固有の（inhe
rent）遅延３５２の後に、サプライチェーンサーバー７４は、段階３５０におい
て作成された領収書を、先に作成された供給計画３３８（図１０Ａを参照）、お
よび、図１７において後述する販売注文２９０とマッチングする。このマッチン
グは、運送中に損失された材料がないことを検証するために行われる。ある購入
注文を構成する全ての販売注文については、このマッチングが実行される前に生
じさせる。３５６において、文書がマッチングしなければ、エラールーチン３５
８が開始される。３５０において作成された領収書が数量または価格のいずれか
の点において販売注文２９０よりも多ければ、考えられる問題の原因は、販売注
文の生成の遅延であり得る。領収書が数量または価格のいずれかの点において販
売注文２９０よりも少なければ、考えられる問題の原因は、データの完全性の問
題、または、その材料が３ＰＬにおいてまたは運送中に損失されたことであり得
る。いずれの場合においても、プランナーが介入すべきである。段階３５０にお
いて作成された領収書が、３５６において、供給計画３３８および販売注文２９
０とマッチングすれば、サプライチェーンサーバー７４は、段階３６０，３６２
へ移動し、これらの段階において、証票（voucher）および支払勘定（payable）
がそれぞれ作成される。

【００９５】次に、前記サプライチェーンサーバーは、図１２の問い合わせ３６４へ分岐し
、かつ、特定の供給業者に関する借方記入（または、貸方記入）が未払いである
か否かを判断する。未払いの借方記入がなければ、制御は、段階３７６（図１３
）へ分岐する。そうでない場合には、制御は、段階３６６へ分岐し、この場合に
、サプライチェーンサーバー７４は、特定の供給業者に関する未決算の送り状が
存在するか否かを判断する。未決算の送り状が存在すれば、サプライチェーンサ
ーバー７４は、３６８において、段階３６４で判断された借方記入をこの未決算
の送り状に対して適用し、かつ、段階３７２へ分岐する。そうでない場合には、
サプライチェーンサーバー７４は、特定の供給業者に関する今後の残高に対して
借方記入を適用し、かつ、段階３７２へ分岐する。段階３７２において、サプラ
イチェーンサーバー７４は、顧客の貸方記入３７４を発行する。その後に、サプ
ライチェーンサーバー７４の制御は、さらに、段階３７６へ分岐する。

【００９６】以下に、図１３を参照すると、段階３７６において、サプライチェーンサーバ
ー７４は、顧客７２からの支払いが受け取られたか否かを問い合わせる。支払い
がまだ受け取られていなければ、サプライチェーンサーバー７４は、遅延期間３
７８だけ待機し、次に、支払いが受け取られたか否かに関する問い合わせ３７６
を続ける。こうして、供給業者への支払いは、支払いが顧客から受け取られるま
で遅延される。顧客の支払い自体は、終日にわたって集計される。支払いが受け
取られると、制御は、支払いがＥＦＴを通して行われたか否かを判断する問い合
わせ３８０へ分岐する。支払いがＥＦＴを通して行われていなければ、サプライ
チェーンサーバー７４は、３８２において、小切手および送金通知書に押印し、
次に、段階３８６へ分岐する。そうでない場合には、サプライチェーンサーバー
７４は、３８４において、ＥＦＴファイルを生成し、次に、段階３８６へ分岐す
る。特定の供給業者に関するＥＦＴ情報は、マスターデータファイルの一部であ
る。ＥＦＴによる支払いは、（顧客から受け取った支払いの終日にわたる集計に
基づいて）毎日の終わりに各々の供給業者へ送られる。

【００９７】前記段階３８６において、サプライチェーンサーバー７４は、小切手および送
金通知書３８８によって、供給業者７６と３ＰＬ７８とに支払いを行う。図２１
を参照して後述する融資オプションが実施されれば、サプライチェーンサーバー
７４は、さらに、ＥＦＴファイルを銀行３９２へ送る。ＥＦＴファイル３９０は
、貨物運送料金表（freight tables）に基づいて、供給業者７６には１日に１回
、かつ、３ＰＬ７８には１ヶ月に１回だけ送られる。その後、しばらくして、預
金口座の状態３９４が、サプライチェーンサーバー７４へ送られる。サプライチ
ェーンサーバー７４は、預金口座の状態３９４を受け取り、かつ、３９６におい
て、銀行３９２へ伝送されたＥＦＴファイル３９０と比較する。次に、サプライ
チェーンサーバー７４は、３９８において、一ヶ月の終わり、四半期の終わりな
どの報告を含む報告を生成する。

【００９８】前記調達モジュールは、顧客７２がサプライチェーンネットワーク７０を通し
て得られた材料の返品を望む状況においても用いられる。図１４を参照すると、
返品工程を開始するために、顧客７２は、部品返品認可のための要求４１０を、
サプライチェーンサーバー７４に行う。各々の供給業者７６は、自分が供給した
部品に関して事前に発行した返品認可４１２を、サプライチェーンサーバー７４
に提供する。サプライチェーンサーバー７４は、要求４１０と返品認可４１２と
を受け取り、かつ、４１４において、所定の供給業者固有の基準を用いて、材料
の返品を認可する。サプライチェーンサーバー７４は、さらに、マスター供給記
録（図示せず）を受け取って、返品すべき品目のソースを判断する。このマスタ
ー供給記録は、どの顧客が、何日に、対応する供給業者から製品を受け取ったの
かを示す。こうして、サプライチェーンサーバー７４は、顧客が返品を望んでい
る製品の製造元を確認することができる。

【００９９】段階４１６において、前記サプライチェーンサーバー７４は、返品認可４１８
を、顧客７２および供給業者７６の両方へ送る。次に、サプライチェーンサーバ
ー７４は、４２０において、製品を返品される予定の供給業者が確立された返品
工程を有しているか否かに関する問い合わせを行う。供給業者がこのような工程
を有していれば、この工程が用いられ、かつ、サプライチェーンサーバー７４は
、４２２において、対応する返品指示４２４を顧客７２へ送る。次に、制御は、
図１２に示される段階４２６へ分岐する。そうでない場合には、供給業者が確立
された工程を有していなければ、制御は、図１５の段階４４０へ分岐する。

【０１００】再び、図１２を参照すると、段階４２６において、サプライチェーンサーバー
７４は、製品が顧客から返品されたことを示す返品製品の配達証明（Proof of D
elivery：ＰＯＤ）４３０が供給業者の運送業者９６から受け取られたか否かに
関する問い合わせを行う。否定的結果であれば、サプライチェーンサーバー７４
は、遅延期間４２８だけ待機し、次に、返品製品のＰＯＤ４３０の受け取りを待
ち続ける。明らかに、返品製品のＰＯＤが受け取られなければ、貸方記入は発生
されない。サプライチェーンサーバー７４は、返品製品のＰＯＤ４３０を受け取
れば、４３２において、支払勘定が適切に処理された場合に適用される借方記入
を、供給業者７６に対して発行する。次に、制御が、詳細に前述した段階３６４
へ分岐する。

【０１０１】図１５を参照すると、供給業者が確立された返品工程を有していなければ、段
階４４０において、サプライチェーンサーバー７４は、顧客７２が取り替え部品
を必要としているか否かを判断する。取り替え部品が必要とされていなければ、
制御は、図１２を参照して前述した段階４２６へ分岐する。そうでない場合には
、制御は段階４４２へ分岐し、この場合に、サプライチェーンサーバー７４は、
顧客にとって好ましい供給業者として列挙されているか、または、出荷品を直ち
に提供できる供給業者の棚卸資産から取り替え部品が利用可能であるか否かを判
断する。部品が棚卸資産から利用可能でなければ、制御は段階４４４へ分岐し、
この場合に、サプライチェーンサーバー７４は、取り替え部品が今週中に必要と
されるか否かを判断する。取り替え部品が今週中に必要とされれば、制御は、図
５を参照して前述したアドホックな需要のための注文管理モジュールへ分岐する
。取り替え部品が今週中に必要とされなければ、制御は、計画モジュールへ分岐
し、かつ、この需要は、例えば、図６において説明したように、今後の数週間分
の予測に吸収される。

【０１０２】前記段階４４２へ戻ると、取り替え部品が棚卸資産から利用可能でなければ、
サプライチェーンサーバー７４は、４４６において、指示４４８を供給業者７６
へ送る。指示４４８は、利用可能な取り替え部品を棚卸資産から直ちに出荷する
ように、供給業者７６に指図するものである。このような場合において、供給業
者７６は、出荷費用を負担し、かつ、３ＰＬ７８を用いる。さらに、サプライチ
ェーンサーバー７４は、４５０において、積み込み／配達指示４５２を生じさせ
、該積み込み／配達指示４５２は、３ＰＬ７８へ送られる。次に、制御は、再び
、図１２を参照して前述した段階４２６へ分岐する。

【０１０３】こうして、従来技術においては、供給業者、３ＰＬ、運送業者、および、顧客
により別々に行われていた工程を中央集中化することにより、調達モジュールに
よって、供給業者と顧客との間において、従来技術のサプライチェーンよりも能
率的に製品を移送することが可能となる。さらに、顧客による出荷および返品の
問題についてもまた、より迅速かつ能率的に処理される。

【０１０４】《Ｖ．注文処理（Fulfillment）》注文処理モジュール（Fulfillment Module）は、供給業者７６から顧客７２へ
の製品の輸送の保証に関係する。図１６を参照すると、本発明による、タイムフ
ェーズ型（time-phased）注文処理モジュールの流れ図が示されている。情報の
流れの大部分については、計画モジュール、注文管理モジュール、および、調達
モジュールを参照して詳細に説明してきたので、このような女医右方についての
詳細な説明は、簡潔のために省略する。

【０１０５】注文処理モジュールにおいて、サプライチェーンサーバー７４は、顧客の予測
２００および第０週の毎日のコールアウト（図４）を、供給業者７６へ送る。供
給業者７６は、需要された製品に関する積み込み指示５００を、３ＰＬ７８へ送
る。次に、供給業者７６は、５０２において、製品を準備し、かつ、ＡＳＮ（図
１０Ａ）をサプライチェーンサーバー７４へ送る。その後すぐに、３ＰＬ７８は
、発送通知５０４を運送業者９６へ送る。サプライチェーンサーバー７４は、配
達問題３３６，３４０，３４２（図１０Ａおよび図１０Ｂ）を解決し、その一方
で、運送業者９６は、５０６において、適切な製品を積み込むための発送用輸送
手段（dispatch vehicles）を、供給業者７６へ送る。発送用輸送手段が製品を
得ると、出荷品積み込み通知５２４が、サプライチェーンサーバー７４へ送られ
る。

【０１０６】前記発送用輸送手段は、指定されたクロスドック位置（この場合には、３ＰＬ
がクロスドック位置として用いられるが、より詳細に後述するように、他の場所
を利用できることも明らかである）へ移動し、かつ、クロスドック指示の到着を
待つ。サプライチェーンサーバー７４は、３４６（図１１）において、クロスド
ック指示を生成し、かつ、３ＰＬ７８へ送る。発送用輸送手段がクロスドック位
置に到着すると、到着通知５０８がサプライチェーンサーバー７４へ送られる。
この地点で、５１０において、クロスドックが実行される。

【０１０７】従来技術のサプライチェーンとは異なり、サプライチェーンネットワーク７０
において、同じまたは類似の部品を注文する複数の顧客７２の注文は、供給業者
７６から調達すべき大規模な注文の形に、一緒にグループ化される。次に、供給
業者７６は、これらの部品に関して、３ＰＬ７８を通して、より大規模な注文を
、はるかに少数だけ出荷する。従来技術においては、供給業者７６は、各々の注
文を個々に処理し、かつ、各々の注文を個々のボックスの形で出荷していた。多
くの顧客に関する全ての注文および部品を管理することの重大さが要求されてい
たので、このやり方は、非常にコストがかかっていた。

【０１０８】本発明においては、サプライチェーンサーバー７４は、供給業者７６からのよ
り大規模な注文を積み込むように、これらの注文をクロスドック地点へ運ぶよう
に、次に、荷を降ろしかつこれらの製品を顧客７２へ副次的出荷（sub-ship）す
るように、３ＰＬ７８に指示する。クロスドック地点については、顧客への出荷
の能率を最大にすべく、効果的に配置することができる。クロスドック地点自体
においては、到着した製品に対する自動化された検査、受理などがある。出荷品
のエラーは、通常的には、クロスドック地点５１０において修正される。

【０１０９】製品自体に関して、これらの製品が供給業者７６のドックを出たときに、サプ
ライチェーンサーバー７４のオペレータは、顧客７２のためのタイトル（title
）を得る。タイトルは、製品が顧客７２に到着したときに、該顧客へ移送される
。サプライチェーンサーバー７４のオペレータは、記録のインポータ（importer
）としても作用する。

【０１１０】再び、図１６を参照すると、クロスドック５１０がクロスドック地点（この場
合には、３ＰＬ７８）において実行された後に、製品の積み込みを要求する発送
通知５１２が運送業者９６へ送られ、かつ、出荷通知２６２（図１７を参照して
後述する）が、サプライチェーンサーバー７４へ送られる。次に、製品は、運送
業者９６により積み込まれ、かつ、適切な顧客７２へ輸送される。顧客７２は、
所望の積み込みまたは配達場所を要求することができる。製品が輸送されている
一方で、サプライチェーンサーバー７４は、ＡＳＮ（図１０Ａ）を顧客７２へ送
る。３ＰＬ７８は、必要に応じて、税関到着（custom in）通知５１４および税
関出発（custom out）通知５１６を、サプライチェーンサーバー７４へ送ること
もできる。このような情報は、顧客７２にとって利用可能となる。製品が顧客７
２へ配達された後に、運送業者９６は、配達証明通知ＰＯＤ５１８を３ＰＬ７８
へ送る。３ＰＬ７８は、ＰＯＤ５１８を、サプライチェーンサーバー７４へ転送
する。

【０１１１】その後に、顧客７２は支払い２９８（図４）をサプライチェーンサーバー７４
へ送り、かつ、サプライチェーンサーバー７４は、支払い２９８の金額から管理
料金を差し引いた金額を、供給業者７６と３ＰＬ７８と運送業者９６とに転送す
る。次に、３ＰＬ７８は、支払い調停通知（payment reconciliation notificat
ion）２５０をサプライチェーンサーバー７４へ送る。何らかの払い戻し（refun
d）が必要であれば、３ＰＬ７８は、５２２において、このような払い戻しをサ
プライチェーンサーバー７４へ送る。次に、サプライチェーンサーバー７４は、
払い戻し５２２を顧客７２へ転送する。

【０１１２】さらに、前記サプライチェーンサーバー７４を用いる顧客７２は、注文処理工
程全体にわたって注文状態を追跡する能力を有する。この注文追跡能力について
は、後述するエクストラネットを介して、サプライチェーンサーバー７４を用い
る全ての顧客７２へ提供することができる。

【０１１３】こうして、より大規模な注文をより少ない数だけ供給業者に提供することによ
り、また、大規模な注文をクロスドック地点において分類することにより、従来
技術よりも低コストでありかつ能率的な注文処理工程が利用可能となる。さらに
、顧客、供給業者、および、３ＰＬの全てに、中央集中型サプライチェーンサー
バーに対して報告を行わせることにより、全ての当事者が、出荷工程に関する最
新の情報を受け取ることができる。一実施形態において、このような情報は、サ
プライチェーンサーバーが配した情報とともに、ウェブサイト上で容易に利用可
能となる。

【０１１４】《VI．課金および支払い（Billing and Payment）》いったん、顧客の需要が注文処理されると、課金および支払いモジュール（Bi
lling and Payment Module）は、課金や顧客の支払い処理のような金融取引の実
行において用いられる規則および活動を定義する責任を有する。課金および支払
いモジュールに関するさらなる提案は、サプライチェーンネットワークの顧客が
、未処理の注文の状態を検討しかつ製品を受け取る時までこの注文の状態を追跡
することを可能にすることである。

【０１１５】概して、顧客の需要が注文処理され、かつ、３ＰＬ７８からの出荷通知が受け
取られた後に、サプライチェーンサーバー７４は、販売注文の生成を誘発する。
同時に、予想された顧客の出荷と実際の顧客の出荷との間の偏差を判断するため
に、出荷通知が検討される。この工程は、輸送中、または、３ＰＬ設備のいずれ
かにおいて製品に対して行われた出荷不足または損傷を識別するのに役立つ。

【０１１６】顧客は、サプライチェーンネットワーク７０を介して、供給業者７６から幾つ
かの出荷品を所定日に受け取ることができる。しかしながら、顧客は、これらの
出荷品を１つの請求書に整理統合する送り状を、１日につき１つ受け取ることが
好ましい。サプライチェーンサーバー７４と顧客７２との間の全ての金融取引に
ついては、好ましい実施形態において、ＥＦＴ（電子資金移動）を用いて実行す
ることができ、これにより、全体的なサイクル時間がさらに短縮される。

【０１１７】図１７および図１８を参照すると、課金および支払いモジュールは、サプライ
チェーンサーバー７４が、２０６において、製品が顧客７２へ配達されたことを
示す出荷通知２６２を３ＰＬ７８から受け取ることによって開始される。領収書
２０６については、ＥＤＩを通したものであってもよい。サプライチェーンサー
バー７４は、２６４において、出荷通知２６２を有効化し、かつ、２６６におい
て、出荷品の注文価格を計算する。有効化２６４において、サプライチェーンサ
ーバー７４は、出荷通知２６２における総数量を、供給計画３３８（図１１を参
照）により指定された数量と比較する。この比較は、顧客の部品番号につき２つ
以上の出荷通知を含むことができ、かつ、予め規定された許容範囲を考慮に入れ
る。サプライチェーンサーバー７４が、２７０において、出荷通知２６２が有効
であると判断すれば、有効化２６４は終了する。そうでない場合には、図１０Ｂ
を参照して前述したエラールーチン３４２のようなエラールーチン２７２が実行
される。エラーが発生した場合には、このことは、データの完全性（出荷通知の
正確さ）の問題、または、３ＰＬのパフォーマンス（３ＰＬ設備または運送中に
おける材料の損失または損傷）の問題を示している。いずれの場合においても、
エラールーチン２７２において出荷過剰および出荷不足の両方の解決法を実施す
るために、プランナーの介入が利用される。

【０１１８】注文価格計算回路２６６において、出荷通知２６２と関連した注文の価格は、
クロスドック指示３４６（図１６）と、供給業者７６と顧客７２との間における
契約２７６と、出荷された実際の製品２７８とに基づいて計算される。このコス
トは、購入された部品の数と、供給業者７６と協議された価格とに基づくもので
ある。基本管理料金に含まれていないサービスに対しては、さらなるコストが追
加される。これらのサービスは、緊急の配達、特殊なラベリング、または、パッ
ケージングなどを含む。最終的に、アドホックな注文には、追加料金を与えるこ
とができる。

【０１１９】製品自体の料金に加えて、前記サプライチェーンサーバー７４は、さらに２８
０において、標準的な貨物運送料金を有する貨物運送料金表に基づいて、製品の
出荷と関連した貨物運送料金を計算する。概して、貨物運送料金は、出荷品の重
量や個数、および、貨物運送形式（例えば、パレット運搬、小包など）に基づい
ている。顧客の預金口座に対して調節を行うために、３ＰＬ７８による調停（re
conciliation）に基づいて、調停を定期的に利用することができる。従来技術の
中にはあまりにも早急に販売注文を生成するものもあったので、販売注文の後に
貨物運送料金を適用する必要があった。明らかなように、このような問題は、本
発明のアーキテクチャにおいては存在しない。

【０１２０】次に、前記サプライチェーンサーバー７４は、２８４において、適切な料金表
２８６を用いて、販売注文の総計を計算する。これらの表は、関税と為替レート
とを計算するために用いられる。付加価値税および売上税の他に、保険料も追加
される。次に、サプライチェーンサーバー７４は、２８８において、販売注文２
９０を生成する。好ましい実施形態において、１つの販売注文は、顧客の部品番
号につき生成され、かつ、料金は、例えば、貨物運送、税、追加サービスなど
のように、項目別に記入される。

【０１２１】以下において、さらに、図１８を参照すると、前記サプライチェーンサーバー
７４は、次に、段階２９２，２９４へ進行して、販売注文２９０に関する送り状
２９６を作成し（段階２９２）、かつ、顧客７２へ送る（段階２９４）。送り状
の作成段階２９２は、各々の販売注文に対する要求額（terms）について略述し
ている電子送り状を用いて、各々の注文に対して自動的に実行される。支払い要
求額は、出荷日に基づいており、かつ、前述したような項目別に記入された料金
を含む。２９４での送り状２９６の送付に関して、同じ顧客に対する全ての送り
状が、毎日整理統合されるので、顧客は、１日につき１つの送り状を受け取る。
これにより、２９４での送付によって、受取勘定（receivable）が作成される。

【０１２２】その後のある時点において、顧客７２は、好ましくは、電子資金移動（ＥＦＴ
）を通して、サプライチェーンサーバー７４へ支払い２９８を送る。サプライチ
ェーンサーバー７４は、３００において、支払い２９８を受け取ろうとする。契
約上で規定された期間内に支払い２９８が受け取られなければ、エラールーチン
３０４が実行され、この場合に、サプライチェーンサーバー７４は、顧客または
対応する銀行のいずれかと連絡を取る。規定された期間内に支払い２９８が受け
取られれば、支払い２９８は、３０２において処理されて、これにより、到着し
た支払いは、未決算の送り状とマッチングされる。支払い２９８を送った顧客の
預金口座は、他の未払いの送り状（貸方記入および借方記入の差額）に関して再
検討され、かつ、支払い２９８が、顧客の預金口座に対して適用される。最終的
に、３０６において、サプライチェーンサーバー７４は、所定の送り状２９６に
対して、顧客７２が十分な支払いを行ったのか、または、必要以上に支払ったの
かを判断する。支払い２９８に問題がなければ、送り状のルーチンは終了する。
そうでない場合には、エラールーチン３０８が実行され、この場合には、過去の
顧客履歴に基づいて集金工程が開始されるか、または、必要以上に支払った場合
には顧客の預金口座に対して貸方記入が適用される。複数の供給業者７６が顧客
７２のために部品を提供していた可能性があるので、支払い２９８は、複数の供
給業者７６に関連している可能性がある。この場合には、支払い２９８を分類し
、これに応じて、供給業者７６に分配しなければならない可能性がある。こうし
て、サプライチェーンサーバー７４の形でのサプライチェーンネットワーク７０
の制御の中央集中化によって、供給業者が、顧客に対する課金処理の管理にかか
るコストを回避することが可能となる。

【０１２３】《VII．情報管理》前記サプライチェーンサーバー７４は、サプライチェーンネットワークの参加
者へ提供できる貴重なデータを蓄積する。好ましい実施形態において、情報配信
能力は、主として、安全なエクストラネットにより実施される。能率的なサプラ
イチェーンネットワークはリアルタイム情報のアクセス可能性（accessibility
）および可視性（visibility）の両方を組み込むので、情報配信は、サプライチ
ェーンサーバー７４のビジネスモデルにとって非常に有用である。

【０１２４】情報配信は、定期定期に発生する離散的（discrete）工程というよりは、サプ
ライチェーンサーバー７４とそのビジネスパートナーとの間における本質的に連
続的な（例えば、１日２４時間、週７日）連絡を可能にする能力である。さらに
、情報配信能力は、顧客（および、潜在的な供給業者や３ＰＬ）がワークフロー
工程を開始する手段を提供する。例えば、顧客が注文を中止する能力に関する工
程は計画モジュールに配置されているが、情報配信が、中止コードの伝達を処理
する（例えば、ワークフロー工程を開始するための電子メールまたはＥＤＩメッ
セージを誘発するエクストラネット上のボタン）。図１９は、サプライチェーン
ネットワーク７０のユーザーへ提供することができる情報を示している。情報配
信工程によって、サプライチェーンネットワークの参加者の必要に応じて、非常
に適時的な様式で情報を配信することが可能となる。

【０１２５】明らかなように、顧客、供給業者、および、３ＰＬにとって利用可能な情報の
形式は、注文固有（order-specific）情報／統計と、顧客固有（customer-speci
fic）統計（例えば、日付までの一週間（Week-to-date）、日付までの一ヶ月間
（Month-to-date）、日付までの一年間（Year-to-date））とを含むが、これら
の制限されるものではない。

【０１２６】《VIII．融資（Financing）》前記サプライチェーンネットワーク７０の構成は、さらに、必ずしも必要では
ないが、製品を調達する顧客に対して新たな形式の融資（financing）を提供す
ることも可能にする。前述したように、従来技術の融資形式においては、供給業
者は顧客に支払い期間を与えていたが、顧客はこの期間を頻繁に無視していた。
したがって、供給業者は、消費者が期限通りに支払いを行わないことに起因して
見込まれる損害に対して、製品の価格を上昇させていた（事実上の利息）。さら
に、販売者は、自分たちのバランスシートを改善するために製品を早期に販売し
たい場合には、卸売業者からの不合理な価格づけの言いなりになっていた。

【０１２７】本発明は、（従来技術における単なる供給業者および顧客だけではなく）三者
の当事者のアーキテクチャを提供することにおいて、事実上の利息と、従来技術
における卸売業者とを廃する。最初に、図２０を参照すると、サプライチェーン
ネットワーク７０におけるタイトルおよび支払いの流れの例が示されている。注
文処理モジュールの説明において前述したように、サプライチェーンサーバー７
４のオペレータは、いったん、製品２７８が供給業者７６から出ると、該製品２
７８のタイトルを得る。製品２７８は、クロスドック５１０へ移動し、次に、顧
客７２へ移動する。顧客７２は、５３６において、製品を使用し、かつ、支払い
５３８を（例えば、クロスドック地点における）サプライチェーンサーバー７４
へ送る。サプライチェーンサーバー７４は、５４０において、支払い５３８を受
け取り、かつ、供給業者７６へ送る。供給業者７６は、支払い５３８を受け取り
、かつ、５４２において、支払いを自分の銀行へ預金する。

【０１２８】図２１には、融資の代替的形式が示されている。図２０に示される流れの場合
のように、製品２７８は、クロスドック５１０へ送られる。この時点で、顧客の
送り状５３２のコピーが、顧客の送り状の支払いの担保（collateral）として、
金融業者または銀行３９２へ送られる。銀行３９２は、顧客の送り状のために必
要な融資金５３４を調達し、かつ、５４０において、この融資金をサプライチェ
ーンサーバー７４へ返送する。次に、サプライチェーンサーバー７４は、融資金
５３４を供給業者７６へ転送し、次に、供給業者７６は、５４２において、融資
金５３４を自分の銀行へ預金する。したがって、供給業者７６には、製品２７８
が出荷された直後に支払いが行われる。銀行３９２は、供給業者７６に支払いを
行うために必要な融資金を、顧客７２に対して効率的に貸し付けを行い、かつ、
サプライチェーンサーバー７４は、この顧客の債務（obligation）を保証する。
顧客７２は、５３６において、製品２７８の使用し続け、次に、支払い５３８を
生じさせ、この支払いは、今や直接的に、銀行へ送られる。銀行３９２は、５４
４において、支払い５３８を預金し、かつ、５４６において、支払い済みとして
印を付けられた送り状５３２を顧客７２へ返送し、かつ、送り状５３２に支払い
が行われたことを示す通知５４８をサプライチェーンサーバー７４へ送る。

【０１２９】こうして、いったん、製品２７８が配達されると、たとえ、サプライチェーン
サーバー７４が顧客７２の代わりに債務を保証していても、該顧客７２は、なお
も、その記録上に支払勘定（payable）を有する。支払勘定自体は、実際には、
サプライチェーンサーバー７４または銀行３９２に対するものであって、供給業
者７６に対するものではない。このような支払勘定のスケジュールは、例示的信
用状態（exemplary credit）によって顧客に対して拡張される。さらに、顧客が
期限通りに支払いを行わなければ、サプライチェーンサーバー７４は、顧客への
部品の流れを差し控える選択権を有し、これにより、顧客７２には、大きな犠牲
が生じる。供給業者７６は、支払いを早期にかつ規則正しく受け取るという点で
利益を得る。サプライチェーンサーバー７４は期限通りに供給業者７６へ支払い
を行うので、供給業者７６は、もはや、事実上の利息を請求する必要がない。こ
のコストの節約は、顧客７２にもたらされ、かつ、サプライチェーンサーバー７
４のオペレータの収益として実現される。

【０１３０】供給業者７６が、顧客７２を満足させるのの必要な時期の前に製品２７８を出
荷したいと望む場合には、サプライチェーンサーバー７４は、顧客７２の予想２
００に基づいて、これらの製品の幾つかを安全に保持することができ、かつ、従
来技術の卸売業者が請求するよりも低い金利を、供給業者７６に対して請求する
ことができる。

【０１３１】前述した技術を用いて、サプライチェーンサーバー７４は、より好ましい価格
をレバレッジ（leverage）するために、または、関係する当事者のためにより魅
力的なバランスシートを作成するために、支払い期間（payment term）による融
資の取り決めを行うことができる。例えば、供給業者には、従来技術のサプライ
チェーンにおいてよりも早期に支払いを行うことができるので、供給業者は、よ
り好意的に、価格の譲歩と融資コストの引き下げとに関して考慮するようになる
。サプライチェーンサーバー７４は、棚卸資産をバランスシートと頭書（premis
es）とから外すことを可能にする融資を取り決めることができる。

【０１３２】さらに、前記サプライチェーンサーバー７４は、商品の価格変更のリスクを、
よりリスクを有する傾向がある（risk-inclined）当事者へシフトすることもで
きる。例えば、揮発性商品（例えば、ダイナミックランダムアクセスメモリ（Ｄ
ＲＡＭ））において、製品および現金の流れを制御することにより、前記サーバ
ー７４は、ヘッジ（hedges）、コール（calls）、プット（put）などのようなリ
スクシフト（risk-shifting）製品を提供することもできる。従来技術のサプラ
イチェーンにおいては、製品および現金を制御する当事者が存在しなかったので
、このような製品を提供することができなかった。

【０１３３】さらに、前記サーバー７４は、従来技術において利用可能ではなかった保険を
提供することもできる。サーバー７４は、多数の顧客および供給業者と接続され
ているので、製品の需要または供給における変動が激しい情勢（swings）に対し
て計画を立てることができる。例えば、サーバー７４は、供給業者７６から臨時
の製品を受け取ることができ、かつ、これらの製品を、顧客の需要が不測的に増
大した場合に備えて保持することができる。サーバー７４が受け取る臨時の製品
は、以前の予測に基づいて、保険計理人による計算（actuarial calculations）
により決定される。これらの臨時の製品は定期的に更新され、これにより、これ
らの製品については、新しいままとなり、古くなることはない。こうして、サー
バー７４は、需要の急騰や供給不足に対して保険をかける。

【０１３４】こうして、前記サプライチェーンサーバー７４による提供によって、サプライ
チェーンネットワークの当事者が、従来技術において利用可能ではなかった融資
オプションを利用することが可能となる。さらに、供給業者は、事実上の利息が
もはや不必要であるので、製品をより安価で提供することができる。

【０１３５】《IX．アーキテクチャ》前記サプライチェーンネットワーク７０については、多くの方法で設定するこ
とができる。概略的なアーキテクチャの設定が、図２２に示されている。サプラ
イチェーンサーバー７４は、顧客７２、供給業者７６、３ＰＬ７８、銀行３９２
、および、運送業者９６の全てに連結されて示されている。この接続については
、例えば、インターネットにようなネットワーク５６０を通したものであっても
よい。

【０１３６】前記ネットワーク５６０が用いられれば、図２２に示される当事者間の連絡に
ついては、ダイヤルアップのシリアル回線インターフェースプロトコル／ポイン
トツーポイントプロトコル（“ＳＬＩＰ／ＰＰＰ”）、統合サービスディジタル
網（“ＩＳＤＮ”）、専用回線サービス、ブロードバンド（ケーブル）アクセス
、デジタル加入者回線（“ＤＳＬ”）、非同期転送モード（“ＡＴＭ”）、また
は、他のアクセス技術のような、通信サーバーにアクセスするための任意の既知
の取り決めを通したものであってもよい。サプライチェーンサーバー７４は、図
２２の当事者のうちの１つによりアクセスされるウェブページをホストするため
に用いられる場合には、ウェブページのＨＴＭＬおよび／またはＪａｖａ（登録
商標）データを提供することができる。サプライチェーンサーバー７４は、この
ようなハードウェア要素に制限されるものではない。

【０１３７】前記サプライチェーンサーバー７４自体については、多くの公知のハードウェ
ア構成を用いて実施することができる。最も概略的な意味で、サプライチェーン
サーバー７４については、図２３に示されるような構成を用いて実施することが
できる。ＣＰＵ５６２は、ＲＯＭ５６４とＲＡＭ５６６と記憶装置５６８とサー
バー装置５７０と入力装置５７２とに、バス５７４を通して連結されている。再
び述べると、サプライチェーンサーバー７４は、これらの構成に制限されるもの
ではない。

【０１３８】図２４を参照すると、サプライチェーンサーバー７４に関する、より詳細なア
ーキテクチャが示されている。サプライチェーンサーバー７４は、エクストラネ
ットマネージャ５８０と、ＥＲＰシステム５８４と、プランナー支援ツール５８
６と、メッセージングサービスセクション５８８とを有し、これらは、全てシス
テムモニター５８２に連結されている。システムモニター５８２は、サーバー７
４の全ての構成要素の作業工程を監視し、かつ、これらの構成要素間における情
報の流れを促進する。図２４に示されるように、顧客７２および供給業者７６は
、ファイアウォール５９０を通して、エクストラネットマネージャ５８０と連絡
を取ることができる。顧客７２、供給業者７６、３ＰＬ７８、および、銀行３９
２は、全て、やはりファイアウォール５９０を通して、サプライチェーンサーバ
ー７４のメッセージングサービスセクション５８８と連絡を取る。

【０１３９】前記エクストラネットマネージャ５８０は、顧客７２および供給業者７６に、
注文および予測情報へのアクセスと、サプライチェーンサーバー７４と契約され
た任意のプレミアム情報サービスへのアクセスと、顧客の書誌的情報（bibliogr
aphic information）（例えば、氏名、住所、預金口座番号など）である顧客マ
スターデータへのアクセスとを提供する。エクストラネットマネージャ５８０は
、ウェブページを表示することにより、かつ、後述するＥＲＰシステム５８４か
ら受け取った情報を有する新たなウェブページを生成するすることにより、この
機能を実行する。最終的に、エクストラネットマネージャ５８０は、サイトのメ
ンバーシップとセキュリティとを管理し、かつ、サーバー７４から／への安全な
データ通信を提供する。

【０１４０】前記ＥＲＰ（企業資源計画）システム５８４は、サーバー７４に、融資、注文
管理、需要管理、調達、および、他の企業処理能力に関するアプリケーションお
よびシステムサポートを提供する。ＥＲＰシステム５８４は、供給業者７６、顧
客７２，ロジスティクスプロバイダ７８、および、金融機関（financial instit
utions）３９２（“パートナー”）からのデータの合併を可能にし、かつ、これ
らのパートナーからのデータを標準的なフォーマットの形で貯蔵しかつ管理する
。さらに、ＥＲＰシステム５８４は、サーバー７４の従業員に、企業情報へのリ
アルタイムアクセスを提供し、かつ、ビジネス処理の完了を保証するためのワー
クフロー能力を提供する。最終的に、ＥＲＰシステム５８４は、顧客マスターデ
ータを追跡する。

【０１４１】前記メッセージングサービスセクション５８８は、サプライチェーンサーバー
７４とその全てのパートナーとの間の連絡を合理化する。メッセージングサービ
スセクション５８８は、全ての受け取られた情報を、ＥＲＰシステム５８４へ入
力される標準的なフォーマットの形に変換する。逆に、メッセージングサービス
セクション５８８は、ＥＲＰシステム５８４から情報を受け取り、かつ、発信メ
ッセージを特定の顧客が期待するフォーマットの形で生成する。メッセージング
サービスセクション５８８は、サーバー７４とそのパートナーとの間の安全なデ
ータ伝送を管理し、全ての伝送に関してインターネットの利用を可能にし、かつ
、会計検査目的のために、全ての伝送のロギング（logging）およびシリアライ
ゼーション（serialization）を提供する。

【０１４２】前記プランナー支援ツール５８６によって、サーバー７４のために働くプラン
ナーが、予測、需要、および供給データを操作することが可能になる。プランナ
ー支援ツール５８６は、ＥＲＰシステム５８４から抽出されたデータを集計し、
これにより、柔軟な、構成可能な（configurable）分析方法を促進し、かつ、広
範囲の報告能力を提供し、分析工程における例外的条件の定義を提供し、例外が
発生した場合の作用過程（ワークフロー）を提供し、データへの安全なアクセス
を提供し、かつ、このデータの完全性を維持しながら、このデータに対する多数
のユーザーによるアクセスを可能にする。エクストラネット５８０の外部に配し
、ＥＲＰシステム５８４と協働させ、かつ、メッセージングサービスセクション
５８８に連結するようにプランナー支援ツールを設けることにより、所望の供給
−需要のバランスを達成することができる。

【０１４３】《Ｘ．要約》こうして、以前に従来技術においては個々のエンティティが行っていた多数の
工程を処理するためにサプライチェーンサーバーを提供することにより、より能
率的でありかつコストを最小限にするアーキテクチャが実現される。購入および
サプライチェーンの管理を整理統合することにより、サプライチェーンサーバー
は、従来技術のサプライチェーンの顧客および供給業者が費やしていた多くの段
階およびコストを不要にする。顧客は、価格の低下と、貨物輸送や購買やシステ
ムプランニングなどに対する支出の低下と、配達の迅速化および信頼性の向上と
、リードタイムの短縮および棚卸資産の減少と、サプライチェーン管理の節約と
、関税および税金の低下と、製品に関する専門的技術と、サプライチェーンの完
全な可視性と、データの完全性の向上と、収益の向上と、自分たちの顧客へのサ
ービスの向上と、供給業者の質の向上と、意思決定の向上とを高く評価する。供
給業者は、販売費用の低下と、計画コストの低下と、棚卸資産の減少と、配達の
向上と、製品コストの低下と、需要の可視性と、運用費用の低下と、より円滑な
製品の流れによる製造コストの低下とにおいて利益を得る。これらのことは、全
て、販売価格を低下させる一方で収益性の向上につながり、これにより、需要が
増大する。顧客および供給業者の両方は、サプライチェーンサーバーがホストす
る安全なウェブサイトへのアクセスを有することができ、該ウェブサイトは、従
来技術において利用可能ではなかった貴重な情報を提供する。この情報は、顧客
の購買習慣と、供給される市場の規模および成長率とを含む。顧客の購買パター
ンについて詳述する履歴データが発展するにつれて、他のサプライチェーンネッ
トワークへ転換することは、より不経済となる。

【０１４４】サプライチェーンサーバーのコストについては、部品番号の数と、累積的な購
買値とに基づいて、顧客が生じさせる。供給業者には、考えられる限りの最も低
い価格を提供させるような形で料金を負担させる必要が無くなる。サプライチェ
ーンネットワークは、製品を大量に調達するので、これらの品目に対してより低
いコストを受け取り、かつ、この低いコストを収益の形に具体化する。

【０１４５】製品の需要および供給について説明してきたが、サービスを含む任意のリソー
スの需要および供給もまた、本発明の範囲内にあることは明らかである。したが
って、本明細書全体にわたって、“製品”という語は、このような任意のリソー
スまたはサービスを指す。例えば、顧客は、ネットワーク内の幹線上の帯域幅を
所望する個人であり得る。また、供給業者は、ネットワークの帯域幅のソースで
あり得る。さらに、顧客は、例えば、対応する供給業者から航空券または劇場の
座席を所望する個人であり得る。

【０１４６】本発明に関する好ましい実施形態について開示してきたが、その一方で、本明
細書に開示されている原理を実行する種々の様式が、冒頭の請求項の範囲内にあ
るものとして予想される。したがって、本発明の範囲は、前記請求項に提示され
ている内容以外により制限されるべきではないことが理解される。

【図面の簡単な説明】

【図１】従来技術によるサプライチェーンアーキテクチャを示すブロック
図である。

【図２】本発明によるサプライチェーンネットワークを示すブロック図で
ある。

【図３】図２のサプライチェーンネットワークを実施するモジュールを示
すブロック図である。

【図４】本発明による、規則的な需要要求中において、注文管理モジュー
ルにより実行される需要捕捉および有効化工程を示す図である。

【図５】アドホックな需要要求中において、注文管理モジュールにより実
行される需要捕捉および有効化工程を示す図である。

【図６】本発明による、計画モジュールにより実行される工程を示す図で
ある。

【図７】図６の計画モジュール中における情報の流れの例を示す図である
。

【図８】顧客の需要が供給業の生産能力を超過した場合に、図６の計画モ
ジュール中において実行される工程を示す図である。

【図９】アドホックな顧客の要求を受けたことに基づいた、図６の計画モ
ジュール中における情報の流れの例を示す図である。

【図１０Ａ】本発明による、調達モジュールの工程を示す図である。

【図１０Ｂ】図１０Ａの調達モジュールにおいて実行されるエラールーチ
ンを示す図である。

【図１１】図１０Ａの調達モジュールにおいて実行される工程の続きを示
す図である。

【図１２】図１０Ａおよび図１１の調達モジュールにおいて実行される工
程の続きを示す図である。

【図１３】図１０Ａ、図１１、および、図１２の調達モジュールにおいて
実行される工程の続きを示す図である。

【図１４】顧客がサプライチェーンネットワークを通して生産された品目
を返品したいと希望した場合に、調達モジュールにより実行される工程を示す図
である。

【図１５】図１４に示された工程の続きを示す図である。

【図１６】本発明による、注文処理モジュール中における情報および製品
の流れを示す図である。

【図１７】本発明による、課金および支払いモジュールにより実行される
送り状の生成を示す図である。

【図１８】課金および支払いモジュール中における送り状の支払いを示す
図である。

【図１９】本発明による、サプライチェーンネットワークにより提供され
る情報およびこれに対応する時間間隔の形式を示す図である。

【図２０】本発明の実施形態による、製品に関するタイトルおよび支払い
の流れを示す図である。

【図２１】本発明の他の実施形態による、製品に関するタイトルおよび支
払いの代替的な流れを示す図である。

【図２２】本発明によるサプライチェーンアーキテクチャのためのアーキ
テクチャ設定の実施形態を示す図である。

【図２３】本発明によるサプライチェーンサーバーの実施形態を示す図で
ある。

【図２４】図２３に示されたサプライチェーンサーバーのためのサプライ
チェーンサーバー環境をより詳細に示す図である。

【符号の説明】

７０サプライチェーンネットワーク７２顧客７４サプライチェーンサーバー７６供給業者７８ロジスティクスプロバイダ９６運送業者３９２銀行５８０エクストラネットマネージャ５８０５８２システムモニター５８４ＥＲＰシステム５８６プランナー支援ツール５８８メッセージングサービスセクション５９０ファイアウォール

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号０９／７５８，５０９ (32)優先日平成12年６月22日(2000．6．22) (33)優先権主張国米国（ＵＳ） (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ

Claims

【特許請求の範囲】

【請求項１】顧客の需要を処理するための方法であって、少なくとも１人の顧客から、予測需要を受け取る段階と、予測需要が有効であるか否かを判断するために、該予測需要を分析する段階と
、予測需要が有効である場合に、該予測需要を、少なくとも１人の供給業者へ送
る段階とを具備することを特徴とする方法。
【請求項２】前記予測需要を受け取る段階は、顧客による予想需要に基づ
いて、予測需要を推定する段階をさらに含むことを特徴とする請求項１に記載の
方法。
【請求項３】前記推定は、予測需要の履歴データに基づくことを特徴とす
る請求項２に記載の方法。
【請求項４】前記推定は、顧客が供給した情報に基づくことを特徴とする
請求項２に記載の方法。
【請求項５】前記送る段階に鑑みて、供給業者に、生産に関する規約に従
うように要求する段階をさらに具備することを特徴とする請求項１に記載の方法
。
【請求項６】前記送る段階に鑑みて、供給業者に、棚卸資産に関する規約
に従うように要求する段階をさらに具備することを特徴とする請求項１に記載の
方法。
【請求項７】前記需要が有効ではない場合に、例外通知を顧客へ送る段階
をさらに具備することを特徴とする請求項１に記載の方法。
【請求項８】前記顧客の需要は、サプライチェーンサーバーにより受け取
られ、前記分析段階は、顧客の信用、需要が、完全な予測であるか否か、全ての情報が、完全かつ正確であるか否か、顧客が、サプライチェーンサーバーと契約しているか否か、需要と関連した部品番号が、サプライチェーンサーバーと顧客との間の契約
に含まれているか否か、のうちの少なくとも１つをチェックする段階を有することを特徴とする請求項１
に記載の方法。
【請求項９】前記予測需要は、少なくとも１人の顧客からの、複数の期間
にわたる需要に関連することを特徴とする請求項１に記載の方法。
【請求項１０】前記予測需要を蓄積することにより、蓄積予測を生じさせ
る段階と、需要が有効である場合に、蓄積予測を、少なくとも１人の供給業者へ送る段階
とをさらに具備することを特徴とする請求項１に記載の方法。
【請求項１１】前記予測需要は、複数の顧客から生じることを特徴とする
請求項１０に記載の方法。
【請求項１２】前記予測需要は、顧客が決定したフォーマットの形である
ことを特徴とする請求項１に記載の方法。
【請求項１３】前記予測需要を、異なるフォーマットの形に変換する段階
をさらに具備することを特徴とする請求項１２に記載の方法。
【請求項１４】前記予測需要は、電子メール、スプレッドシート、および
、ＸＭＬフォーマットのうちの１つの形で受け取られることを特徴とする請求項
１２に記載の方法。
【請求項１５】前記予測需要は、製品に関連することを特徴とする請求項
１に記載の方法。
【請求項１６】前記予測需要は、サービスに関連することを特徴とする請
求項１に記載の方法。
【請求項１７】前記予測需要は、ネットワーク内の帯域幅に関連すること
を特徴とする請求項１に記載の方法。
【請求項１８】前記予測需要は、航空券に関連することを特徴とする請求
項１に記載の方法。
【請求項１９】前記顧客が予測需要のうちの１つに関連する注文を中止す
ることを可能にする中止コードを、該顧客へ送る段階をさらに具備することを特
徴とする請求項１に記載の方法。
【請求項２０】前記顧客が中止コードを送れば、予測需要のうちの１つに
対応する注文をキャンセルする段階をさらに具備することを特徴とする請求項１
９に記載の方法。
【請求項２１】前記予測需要に対応する製品を、供給業者から顧客へ送る
段階をさらに具備することを特徴とする請求項１に記載の方法。
【請求項２２】前記製品と、顧客および供給業者のうちの少なくとも一方
とに関連する追跡情報を提供する段階をさらに具備することを特徴とする請求項
２１に記載の方法。
【請求項２３】前記追跡情報は、顧客および供給業者のうちの少なくとも
一方がアクセス可能なウェブサイトを生じさせることにより提供されることを特
徴とする請求項２２に記載の方法。
【請求項２４】前記追跡情報は、供給業者と顧客との間における潜在的な
ボトルネックに関連する情報を含むことを特徴とする請求項２２に記載の方法。
【請求項２５】前記ボトルネックは、税関を含むことを特徴とする請求項
２４に記載の方法。
【請求項２６】前記少なくとも１人の顧客による、特定の製品に関する返
品要求を受け取る段階と、特定の製品を、対応する供給業者へ返品する段階と、顧客が取り替え製品を望むか否かを判断する段階とをさらに具備し、前記受け取る段階は、サプライチェーンネットワーク内のサプライチェーンサ
ーバーにより実行されることを特徴とする請求項１に記載の方法。
【請求項２７】前記取り替え製品が、サプライチェーンネットワーク内の
供給業者のうちの少なくとも１人から利用可能であるか否かを判断する段階をさ
らに具備することを特徴とする請求項２６に記載の方法。
【請求項２８】前記取り替え製品がサプライチェーンネットワーク内の供
給業者から利用可能ではない場合に、予測需要を調整する段階をさらに具備する
ことを特徴とする請求項２７に記載の方法。
【請求項２９】サプライチェーンネットワークにおいて、製品に対する顧
客の需要を処理するための方法であって、複数の顧客から、予測需要を受け取る段階と、予測需要を蓄積する段階により、蓄積予測を生じさせる段階と、蓄積予測を、少なくとも１人の供給業者へ送る段階と、蓄積予測に対応する製品を、少なくとも１人の供給業者からクロスドック地点
へ送る段階と、予測需要を生じさせた特定の顧客に基づいて、製品をクロスドック地点におい
て整理する段階と、対応する製品を、予測需要を生じさせた特定の顧客へ送る段階とを具備することを特徴とする方法。
【請求項３０】前記製品と、顧客および供給業者のうちの少なくとも一方
とに関連する追跡情報を提供する段階をさらに具備することを特徴とする請求項
２９に記載の方法。
【請求項３１】前記追跡情報は、顧客および供給業者のうちの少なくとも
一方がアクセス可能なウェブサイトを生じさせることにより提供されることを特
徴とする請求項３０に記載の方法。
【請求項３２】前記追跡情報は、クロスドック地点の前における製品の移
動を含むことを特徴とする請求項３０に記載の方法。
【請求項３３】前記追跡情報は、クロスドック地点の後における製品の移
動を含むことを特徴とする請求項３０に記載の方法。
【請求項３４】前記追跡情報は、潜在的なボトルネックの始めから終わり
までにおける製品の移動を含むことを特徴とする請求項３０に記載の方法。
【請求項３５】前記ボトルネックは、税関を含むことを特徴とする請求項
３４に記載の方法。
【請求項３６】前記ボトルネックは、クロスドック地点を含むことを特徴
とする請求項２９に記載の方法。
【請求項３７】前記クロスドック地点は、特定の顧客により条件指定され
ることを特徴とする請求項２９に記載の方法。
【請求項３８】前記蓄積する段階は、実質的に相互交換可能な製品に対す
る顧客の需要を一緒にグループ化する段階を含むことを特徴とする請求項２９に
記載の方法。
【請求項３９】前記製品を送る段階および前記製品を整理する段階は、少
なくとも１人の供給業者が予測需要を管理する時間を節約する、という結果をも
たらすことを特徴とする請求項２９に記載の方法。
【請求項４０】前記クロスドックにおける製品を、蓄積予測と比較する段
階をさらに具備することを特徴とする請求項２９に記載の方法。
【請求項４１】前記クロスドックにおける製品と、蓄積予測とがマッチン
グしなければ、前記クロスドックにおける製品が出荷過剰または出荷不足を示し
ているか否かを判断する段階をさらに具備することを特徴とする請求項４０に記
載の方法。
【請求項４２】前記クロスドックにおける製品が出荷過剰を示している場
合に、蓄積予測を超過した前記クロスドックにおける製品の処分を決定する段階
をさらに具備することを特徴とする請求項４１に記載の方法。
【請求項４３】前記クロスドックにおける製品が出荷不足を示している場
合に、蓄積予測を生じさせた特定の顧客の間で、利用可能な製品の供給を割り当
てる段階をさらに具備することを特徴とする請求項４１に記載の方法。
【請求項４４】需要された製品を顧客に提供するための方法であって、前記需要された製品が特定の供給業者に対して望まれていることを示す需要を
、顧客から受け取る段階と、前記特定の供給業者が前記需要された製品を供給できるか否かを判断する段階
と、前記特定の供給業者が前記需要された製品を供給できなければ、他の供給業者
が前記需要された製品を供給できるか否かを判断する段階とを具備することを特徴とする方法。
【請求項４５】前記他の供給業者が前記需要された製品を供給できる場合
に、前記需要された製品を、前記他の供給業者から顧客へ送る段階をさらに具備
することを特徴とする請求項４４に記載の方法。
【請求項４６】前記需要は、アドホックな需要であることを特徴とする請
求項４４に記載の方法。
【請求項４７】前記需要を、対応する供給業者の１つ以上の部品番号の形
に変換する段階をさらに具備することを特徴とする請求項４４に記載の方法。
【請求項４８】サプライチェーンネットワーク内の複数の顧客から需要を
受け取る段階と、サプライチェーンネットワーク内の供給業者が複数の顧客の需要を供給できる
か否かを判断する段階と、サプライチェーンネットワーク内の供給業者が複数の顧客の需要を供給できな
ければ、複数の顧客の間で、供給業者から利用可能な製品を分配する段階とをさらに具備することを特徴とする請求項４４に記載の方法。
【請求項４９】前記分配する段階は、比例配分に基づいて実行されること
を特徴とする請求項４８に記載の方法。
【請求項５０】少なくとも１人の顧客による、少なくとも１人の供給業者
からの製品の購入に融資を行うための方法であって、供給業者から顧客へ製品を送る段階と、製品に対する融資支払いを、銀行から第三者へ送る段階と、融資支払いを、第三者から供給業者へ転送する段階と、製品に対する顧客の支払いを、顧客から銀行へ送る段階とを具備することを特徴とする方法。
【請求項５１】前記製品は、複数の供給業者からの複数の製品を具備し、前記顧客の支払いは、複数の供給業者に対する一括支払い（batch payment）
であることを特徴とする請求項５０に記載の方法。
【請求項５２】前記製品を送る段階は、供給業者からクロスドック地点へ製品を送る段階と、クロスドック地点から顧客へ製品を送る段階とを具備することを特徴とする請求項５０に記載の方法。
【請求項５３】リスクシフトサービスを、顧客および供給業者のうちの少
なくとも一方へ提供する段階をさらに具備することを特徴とする請求項５０に記
載の方法。
【請求項５４】前記リスクシフトサービスは、製品の価格に関連するヘッ
ジ、コール、および、プットのうちの１つであることを特徴とする請求項５１に
記載の方法。
【請求項５５】前記製品を送る段階は、供給業者から第三者へ、製品のタイトルを移送する段階と、第三者から顧客へ、製品のタイトルを移送する段階とを具備することを特徴とする請求項４８に記載の方法。
【請求項５６】サプライチェーンネットワーク内において受け取られた顧
客の需要を処理するための方法であって、サプライチェーンサーバーにより、複数の顧客から、予測需要を受け取る段階
と、予測需要を、集計予測の形に集計する段階と、集計予測を、サプライチェーンサーバーから、少なくとも１人の供給業者へ送
る段階とを具備することを特徴とする方法。
【請求項５７】需要された製品を顧客に提供するための方法であって、条件指定された製品を第２時刻までに供給することを供給業者に要求する第１
時刻に、条件指定された製品を配達するための予測需要を、少なくとも１人の顧
客から受け取る段階と、第２時刻の前に製品を受け取るための割増料金を供給業者に請求することなく
、第２時刻の前に供給業者から製品を受け取る段階と、ほぼ第１時刻に、製品を顧客へ配達する段階とを具備することを特徴とする方法。
【請求項５８】サプライチェーンネットワークにおいて、製品に対する顧
客の需要を処理するための方法であって、顧客の需要を受け取る段階と、顧客の需要を集計して、集計需要を生じさせる段階と、集計需要を、少なくとも１人の供給業者へ送る段階と、集計需要に対応する製品を、少なくとも１人の供給業者からクロスドック地点
へ送る段階と、顧客の需要を生じさせた特定の顧客に基づいて、製品をクロスドック地点にお
いて整理する段階と、対応する製品を、顧客の需要を生じさせた特定の顧客へ送る段階とを具備することを特徴とする方法。
【請求項５９】少なくとも１人の顧客が少なくとも１人の供給業者へ需要
した１つ以上の製品に関する供給／需要の変動のために保険をかけるための方法
であって、少なくとも１つの製品を、少なくとも１人の供給業者から受け取る段階と、少なくとも１人の顧客が製品に対する需要の不測的な増大を被り、かつ、供給
業者が製品の供給量の不測的な不足を被るまで製品を保持する段階と、対応する顧客へ、製品を送る段階とを具備することを特徴とする方法。
【請求項６０】前記製品は、サービスであることを特徴とする請求項５９
に記載の方法。
【請求項６１】少なくとも１つの製品に関して、少なくとも１人の顧客か
ら、予測需要を受け取る段階をさらに具備することを特徴とする請求項５９に記
載の方法。
【請求項６２】前記予測需要を受け取る段階は、顧客が予想した需要に基
づいて、予測需要を推定する段階を含むことを特徴とする請求項６１に記載の方
法。
【請求項６３】前記推定する段階は、保険計理人による計算に基づいて決
定されることを特徴とする請求項６２に記載の方法。
【請求項６４】前記製品は、該製品が新しいままであるために十分なだけ
頻繁に取り替えられることを特徴とする請求項５９に記載の方法。
【請求項６５】サプライチェーンネットワークにおいて、製品に対する顧
客の需要を処理するための方法であって、需要を受け取る段階と、サプライチェーンネットワークに連結された供給業者の供給により需要を注文
処理できるか否かを判断する段階と、サプライチェーンネットワークに連結された供給業者により需要を注文処理で
きない場合には、需要および供給のうちの一方を変更できるか否かを確認するた
めに、顧客および供給業者と連絡を取る段階とを具備することを特徴とする方法。
【請求項６６】前記需要は、複数の顧客から受け取られ、前記連絡を取る段階は、複数の顧客と連絡を取る段階を含むことを特徴とする
請求項６５に記載の方法。
【請求項６７】前記需要は、顧客が複数の期間にわたって望む製品に関す
る予測を具備することを特徴とする請求項６５に記載の方法。
【請求項６８】前記判断する段階は、前記期間の始めから終わりまで反復
する段階と、各々の期間に対して利用可能な供給品を判断する段階とを含むこと
を特徴とする請求項６５に記載の方法。
【請求項６９】前記期間は、複数の週であることを特徴とする請求項６７
に記載の方法。
【請求項７０】顧客の需要を処理するためのシステムであって、少なくとも１人の顧客と、少なくとも１人の供給業者とに連結され、メッセー
ジングサービスシステムとＥＲＰシステムとを有するサプライチェーンサーバー
を具備し、前記メッセージングサービスシステムは、少なくとも１人の顧客から、予測需
要を受け取り、前記ＥＲＰシステムは、メッセージングサービスシステムが受け取った予測需
要が有効であるか否かを判断するために、該予測需要を分析し、前記メッセージングサービスシステムは、予測需要が有効である場合に、該予
測需要を、少なくとも１人の供給業者へ送ることを特徴とするシステム。
【請求項７１】前記ＥＲＰシステムは、さらに、顧客による予想需要に基
づいて、予測需要を推定することを特徴とする請求項７０に記載のシステム。
【請求項７２】前記ＥＲＰシステムは、予測需要の履歴データに基づいて
推定することを特徴とする請求項７１に記載のシステム。
【請求項７３】前記ＥＲＰシステムは、顧客が供給した情報に基づいて、
予測需要を推定することを特徴とする請求項７１に記載のシステム。
【請求項７４】前記メッセージングサービスシステムが送る予測需要に鑑
みて、供給業者に、生産に関する規約に従うように要求する契約上の同意をさら
に具備することを特徴とする請求項７０に記載のシステム。
【請求項７５】前記メッセージングサービスシステムが送る予測需要に鑑
みて、供給業者に、棚卸資産に関する規約に従うように要求する契約上の同意を
さらに具備することを特徴とする請求項７０に記載のシステム。
【請求項７６】前記メッセージングサービスシステムは、需要が有効では
ないとＥＲＰシステムが判断した場合に、例外通知を顧客へ送ることを特徴とす
る請求項７０に記載のシステム。
【請求項７７】前記ＥＲＰシステムは、顧客の信用、需要が、完全な予測であるか否か、全ての情報が、完全かつ正確であるか否か、顧客が、サプライチェーンサーバーと契約しているか否か、需要と関連した部品番号が、サプライチェーンサーバーと顧客との間の契約
に含まれているか否か、のうちの少なくとも１つをチェックすることにより、予測需要を分析することを
特徴とする請求項７０に記載のシステム。
【請求項７８】前記予測需要は、少なくとも１人の顧客からの、複数の期
間にわたる需要に関連することを特徴とする請求項７０に記載のシステム。
【請求項７９】前記ＥＲＰシステムは、さらに、予測需要を蓄積すること
により、蓄積予測を生じさせ、前記メッセージングサービスシステムは、需要が有効である場合に、蓄積予測
を、少なくとも１人の供給業者へ送ることを特徴とする請求項７０に記載のシス
テム。
【請求項８０】前記蓄積された予測需要は、複数の顧客から生じることを
特徴とする請求項７９に記載のシステム。
【請求項８１】前記予測需要は、顧客が決定したフォーマットの形である
ことを特徴とする請求項７０に記載のシステム。
【請求項８２】前記メッセージングサービスシステムは、さらに、予測需
要を、異なるフォーマットの形に変換することを特徴とする請求項８１に記載の
システム。
【請求項８３】前記予測需要は、ＥＤＩ、電子メール、スプレッドシート
、および、ＸＭＬフォーマットのうちの１つの形で受け取られることを特徴とす
る請求項８１に記載のシステム。
【請求項８４】前記予測需要は、製品に関連することを特徴とする請求項
７０に記載のシステム。
【請求項８５】前記予測需要は、サービスに関連することを特徴とする請
求項７０に記載のシステム。
【請求項８６】前記予測需要は、ネットワーク内の帯域幅に関連すること
を特徴とする請求項７０に記載のシステム。
【請求項８７】前記予測需要は、航空券に関連することを特徴とする請求
項７０に記載のシステム。
【請求項８８】前記メッセージングサービスシステムは、顧客が予測需要
のうちの１つに関連する注文を中止することを可能にする中止コードを、該顧客
へ送ることを特徴とする請求項７０に記載のシステム。
【請求項８９】前記ＥＲＰシステムは、さらに、顧客が送った中止コード
を受け取るとすぐに、予測需要のうちの１つに対応する注文をキャンセルするこ
とを特徴とする請求項８８に記載のシステム。
【請求項９０】前記サプライチェーンサーバーは、さらに、少なくとも１
人のロジスティクスプロバイダに接続され、前記ＥＲＰシステムは、さらに、指令をロジスティクスプロバイダへ送り、こ
れにより、ロジスティクスプロバイダは、サプライチェーンサーバーからの注文
に応答して、予測需要に対応する製品を、供給業者から顧客へ移送することを特
徴とする請求項７０に記載のシステム。
【請求項９１】前記サプライチェーンサーバーは、さらに、エクストラネ
ットマネージャを具備し、該エクストラネットマネージャは、製品に関連する追
跡情報を提供することを特徴とする請求項９０に記載のシステム。
【請求項９２】前記エクストラネットマネージャは、顧客および供給業者
のうちの少なくとも一方がアクセス可能なウェブサイトを生じさせることにより
、追跡情報を提供することを特徴とする請求項９１に記載のシステム。
【請求項９３】前記追跡情報は、供給業者と顧客との間における潜在的な
ボトルネックの始めから終わりまでにおける製品の状態に関する情報を含むこと
を特徴とする請求項９１に記載のシステム。
【請求項９４】前記ボトルネックは、税関を含むことを特徴とする請求項
９３に記載のシステム。
【請求項９５】前記サプライチェーンサーバーは、さらに、ロジスティク
スプロバイダに連結され、前記メッセージングサービスシステムは、少なくとも１人の顧客による、特定
の製品に関する返品要求を受け取り、前記ＥＲＰシステムは、特定の製品を、対応する供給業者へ返品するように、
ロジスティクスプロバイダを統制し、前記ＥＲＰシステムは、顧客が取り替え製品を望むか否かを判断することを特
徴とする請求項７０に記載のシステム。
【請求項９６】前記ＥＲＰシステムは、さらに、取り替え製品が、システ
ム内の供給業者から利用可能であるか否かを判断することを特徴とする請求項９
５に記載のシステム。
【請求項９７】前記ＥＲＰシステムは、さらに、取り替え製品がシステム
内の供給業者から利用可能ではない場合に、予測需要を調整することを特徴とす
る請求項９６に記載のシステム。
【請求項９８】製品に対する顧客の需要を処理するためのシステムであっ
て、少なくとも１人の顧客と、少なくとも１人の供給業者とに連結され、かつ、メ
ッセージングサービスシステムと、ＥＲＰシステムとを有するサプライチェーン
サーバーと、ロジスティクスプロバイダとを具備し、前記メッセージングサービスシステムは、複数の顧客から、予測需要を受け取
り、前記ＥＲＰシステムは、予測需要を蓄積することにより、蓄積予測を生じさせ
、前記メッセージングサービスシステムは、蓄積予測を、少なくとも１人の供給
業者へ送り、前記ＥＲＰシステムは、蓄積予測に対応する製品を、少なくとも１人の整理供
給業者からクロスドック地点へ送るように、ロジスティクスプロバイダを統制し
、前記ＥＲＰシステムは、さらに、予測需要を生じさせた特定の顧客に基づいて
、製品をクロスドック地点において整理するように、ロジスティクスプロバイダ
を統制し、前記ＥＲＰシステムは、対応する製品を、予測需要を生じさせた特定の顧客へ
送るように、ロジスティクスプロバイダを統制することを特徴とするシステム。
【請求項９９】前記サプライチェーンサーバーは、製品に関連する追跡情
報を提供するエクストラネットマネージャをさらに具備することを特徴とする請
求項９８に記載のシステム。
【請求項１００】前記エクストラネットマネージャは、顧客および供給業
者のうちの少なくとも一方がアクセス可能なウェブサイトを生じさせることによ
り、追跡情報を提供することを特徴とする請求項９９に記載のシステム。
【請求項１０１】前記追跡情報は、クロスドック地点の前における製品の
移動を含むことを特徴とする請求項１００に記載のシステム。
【請求項１０２】前記追跡情報は、クロスドック地点の後における製品の
移動を含むことを特徴とする請求項１００に記載のシステム。
【請求項１０３】前記追跡情報は、潜在的なボトルネックの始めから終わ
りまでにおける製品の移動を含むことを特徴とする請求項１００に記載のシステ
ム。
【請求項１０４】前記ボトルネックは、税関を含むことを特徴とする請求
項１０３に記載のシステム。
【請求項１０５】前記ボトルネックは、クロスドック地点を含むことを特
徴とする請求項１０４に記載のシステム。
【請求項１０６】前記クロスドック地点は、特定の顧客により条件指定さ
れることを特徴とする請求項１０５に記載のシステム。
【請求項１０７】前記ＥＲＰシステムは、実質的に相互交換可能な製品に
対する顧客の需要を一緒にグループ化することにより、予測需要を蓄積すること
を特徴とする請求項９８に記載のシステム。
【請求項１０８】前記ＥＲＰシステムが製品の送付と該製品の整理とを統
制することによって、少なくとも１人の供給業者が予測需要を管理する時間を節
約する、という結果がもたらされることを特徴とする請求項９８に記載のシステ
ム。
【請求項１０９】前記サプライチェーンサーバーは、クロスドックにおけ
る製品を、蓄積予測と比較するプランナーツールをさらに具備することを特徴と
する請求項９８に記載のシステム。
【請求項１１０】前記プランナーツールは、クロスドックにおける製品と
、蓄積予測とがマッチングしないと判断すれば、前記クロスドックにおける製品
が出荷過剰または出荷不足を示しているか否かを判断することを特徴とする請求
項１０９に記載のシステム。
【請求項１１１】前記クロスドックにおける製品が出荷過剰を示している
場合に、前記プランナーツールは、蓄積予測を超過した前記クロスドックにおけ
る製品の処分を決定することを特徴とする請求項１１０に記載のシステム。
【請求項１１２】前記クロスドックにおける製品が出荷不足を示している
場合に、前記プランナーツールは、蓄積予測を生じさせた特定の顧客の間で、利
用可能な製品の供給を割り当てることを特徴とする請求項１１０に記載のシステ
ム。
【請求項１１３】需要された製品を顧客に提供するためのシステムであっ
て、少なくとも１人の顧客と、少なくとも１人の供給業者とに連結され、かつ、メ
ッセージングサービスシステムと、ＥＲＰシステムとを有するサプライチェーン
サーバーを具備し、前記メッセージングサービスシステムは、前記需要された製品が特定の供給業
者に対して望まれていることを示す需要を、顧客から受け取り、前記ＥＲＰシステムは、前記特定の供給業者が前記需要された製品を供給でき
るか否かを判断し、前記特定の供給業者が前記需要された製品を供給できなければ、前記ＥＲＰシ
ステムは、他の供給業者が前記需要された製品を供給できるか否かを判断することを特徴とするシステム。
【請求項１１４】前記サプライチェーンサーバーは、ロジスティクスプロ
バイダに連結され、前記ＥＲＰシステムは、さらに、前記他の供給業者が前記需要された製品を供
給できる場合に、前記需要された製品を、前記他の供給業者から顧客へ送るよう
に、ロジスティクスプロバイダを統制することを特徴とする請求項１１３に記載
のシステム。
【請求項１１５】前記需要は、アドホックな需要であることを特徴とする
請求項１１３に記載のシステム。
【請求項１１６】前記ＥＲＰシステムは、さらに、前記需要を、対応する
供給業者の１つ以上の部品番号の形に変換することを特徴とする請求項１１３に
記載のシステム。
【請求項１１７】前記メッセージングサービスシステムは、複数の顧客か
ら需要を受け取り、前記ＥＲＰシステムは、供給業者が複数の顧客の需要を供給できるか否かを判
断し、前記供給業者が複数の顧客の需要を供給できなければ、前記ＥＲＰシステムに
よって、複数の顧客の間で、供給業者から利用可能な製品が分配されることを特
徴とする請求項１１３に記載のシステム。
【請求項１１８】前記分配は、比例配分に基づいて実行されることを特徴
とする請求項１１７に記載のシステム。
【請求項１１９】少なくとも１人の顧客による、少なくとも１人の供給業
者からの製品の購入に融資を行うためのシステムであって、少なくとも１人の顧客と、少なくとも１人の供給業者と、ロジスティクスプロ
バイダとに連結され、かつ、供給業者から顧客へ移送するようにロジスティクス
プロバイダを統制するサプライチェーンサーバーと、製品に対する融資支払いを、サプライチェーンサーバーへ送る金融機関とを具備し、前記サプライチェーンサーバーは、融資支払いを、供給業者へ転送し、前記顧客は、製品に対する顧客の支払いを、銀行へ送ることを特徴とするシステム。
【請求項１２０】前記製品は、複数の供給業者からの複数の製品を具備し
、前記顧客の支払いは、複数の供給業者に対する一括支払い（batch payment）
であることを特徴とする請求項１１９に記載のシステム。
【請求項１２１】前記サプライチェーンサーバーは、供給業者からクロスドック地点へ製品を送るように、クロスドック地点から顧客へ製品を送るように、ロジスティクスプロバイダを統制することを特徴とする請求項１１９に記載のシ
ステム。
【請求項１２２】前記サプライチェーンサーバーは、さらに、リスクシフ
トサービスを、顧客および供給業者のうちの少なくとも一方へ提供することを特
徴とする請求項１１９に記載のシステム。
【請求項１２３】前記リスクシフトサービスは、製品の価格に関連するヘ
ッジ、コール、および、プットのうちの１つであることを特徴とする請求項１２
２に記載のシステム。
【請求項１２４】前記ＥＲＰシステムは、供給業者からサプライチェーンサーバーへの、製品のタイトルの移送と、サプライチェーンサーバーから顧客への、製品のタイトルの移送とを実行することにより製品を移送するように、ロジスティクスプロバイダを統制
することを特徴とする請求項１１９に記載のシステム。
【請求項１２５】サプライチェーンネットワーク内において受け取られた
顧客の需要を処理するためのシステムであって、少なくとも１人の顧客と、少なくとも１人の供給業者とに連結され、かつ、メ
ッセージングサービスシステムと、ＥＲＰシステムとを有するサプライチェーン
サーバーを有し、前記メッセージングサービスシステムは、複数の顧客から、予測需要を受け取
り、前記ＥＲＰシステムは、予測需要を、集計予測の形に集計し、前記メッセージングサービスシステムは、集計予測を、少なくとも１人の供給
業者へ送ることを特徴とするシステム。
【請求項１２６】需要された製品を顧客に提供するためのシステムであっ
て、少なくとも１人の顧客と、少なくとも１人の供給業者と、ロジスティクスプロ
バイダとに連結され、かつ、メッセージングサービスシステムと、ＥＲＰシステ
ムとを有するサプライチェーンサーバーを具備し、前記メッセージングサービスシステムは、条件指定された製品を第２時刻まで
に供給することを供給業者に要求する第１時刻に、条件指定された製品を配達す
るための予測需要を、少なくとも１人の顧客から受け取り、前記ＥＲＰシステムは、第２時刻の前に製品を受け取るための割増料金を供給
業者に請求することなく、第２時刻の前に供給業者から製品を受け取るように、
ロジスティクスプロバイダを統制し、前記ＥＲＰシステムは、さらに、ほぼ第１時刻に、製品を顧客へ配達するよう
に、ロジスティクスプロバイダを統制することを特徴とするシステム。
【請求項１２７】少なくとも１つの製品に対する顧客の需要を処理するた
めのシステムであって、少なくとも１人の顧客と、少なくとも１人の供給業者と、ロジスティクスプロ
バイダとに連結され、かつ、メッセージングサービスシステムと、ＥＲＰシステ
ムとを有するサプライチェーンサーバーを具備し、前記メッセージングサービスシステムは、顧客の需要を受け取り、前記ＥＲＰシステムは、顧客の需要を集計して、集計需要を生じさせ、前記メッセージングサービスシステムは、集計需要を、少なくとも１人の供給
業者へ送り、前記ＥＲＰシステムは、集計需要に対応する製品を、少なくとも１人の供給業
者からクロスドック地点へ移送するように、ロジスティクスプロバイダを統制し
、前記ＥＲＰシステムは、さらに、顧客の需要を生じさせた特定の顧客に基づい
て、製品をクロスドック地点において整理するように、ロジスティクスプロバイ
ダを統制し、前記ＥＲＰシステムは、対応する製品を、顧客の需要を生じさせた特定の顧客
へ送るように、ロジスティクスプロバイダを統制することを特徴とするシステム。
【請求項１２８】製品に対する顧客の需要を処理するためのシステムであ
って、少なくとも１人の顧客と、少なくとも１人の供給業者とに連結され、かつ、メ
ッセージングサービスシステムと、ＥＲＰシステムと、プランナー支援ツールと
を有するサプライチェーンサーバーを具備し、前記メッセージングサービスシステムは、需要を受け取り、前記ＥＲＰシステムは、サプライチェーンネットワークに連結された供給業者
の供給により需要を注文処理できるか否かを判断し、サプライチェーンネットワークに連結された供給業者により需要を注文処理で
きない場合には、前記プランナー支援ツールは、需要および供給のうちの一方を
変更できるか否かを確認するために、顧客および供給業者と連絡を取ることを特徴とするシステム。
【請求項１２９】前記需要は、複数の顧客から受け取られ、前記プランナ
ー支援ツールは、複数の顧客と連絡を取ることを特徴とする請求項１２８に記載
のシステム。
【請求項１３０】前記需要は、顧客が複数の期間にわたって望む製品に関
する予測を具備することを特徴とする請求項１２８に記載のシステム。
【請求項１３１】前記プランナー支援ツールは、前記期間の始めから終わ
りまで反復され、かつ、各々の期間に対して利用可能な供給品を判断することを
特徴とする請求項１２８に記載のシステム。
【請求項１３２】前記期間は、複数の週であることを特徴とする請求項１
３０に記載のシステム。