JP2003534582A6

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

Info

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

Abstract

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

Description

【０００１】
【発明の属する技術分野】
本発明は、サプライチェーン（supply chain）ネットワークの改善に関し、より詳細には、多数のオペレーション作業工程を中央集中化することにより、従来技術のシステムよりも能率的かつ低コストであるサプライチェーンを生じさせるサプライチェーンネットワークに関する。
【０００２】
【従来の技術】
製造業者（以後、概略的に“顧客（customer）”と称する）、および、製品またはサービス（以後、集合的に“製品（product）”と称する）の供給業者（supplier）は、コストの低下に常に関心を有している。材料は、サプライチェーン管理コストと同様に、総コストの大部分を占める。サプライチェーンは、製品の製造において用いられる部品およびサブ部品の定義、設計、生産、受け取り、監視、貯蔵、および、使用と関連した任意のおよび全ての活動（activity）である。製造業者／顧客は、しばしば、自分たちが高い代価を支払っていることに気づき、需要（demand）が高いときに製品が不足し、需要について不正確な予測を行い、かつ、棚卸資産（inventory）の動きを緩慢にさせている。その理由は、彼らが、自分たちのサプライチェーンを適切に管理するための専門知識、資源、または、機会を有していないためである。
【０００３】
直接材料（direct materials）は、製造業者の総コストの３５％〜７０％を占め、かつ、しばしば、最も大きな支出カテゴリーを構成する。材料のコストを低下させることによって、収益性が著しく向上する。例えば、請負いの電子部品の製造に従事している会社は、直接材料価格を１％下げるだけで、総収益性を２０％〜３０％向上させることができる。
【０００４】
サプライチェーンのコストは、製造業者の総支出のうち、かなりの部分を構成する。例えば、サプライチェーンのコストには、計画、購入、引取貨物運送料（inbound freight）、受け取り、棚卸資産の管理、運送コスト、供給業者のモニタリング、測定、管理、および、送り状の支払いが含まれる。これらのコストは、会社の支出の５％〜２５％を占める。この概算は、製造業者による部品の製造および供給の両方に当てはまる。例えば、サプライチェーンのコストを２０％低下させることによって、所定の製造業者の収益が著しく向上し、多くの場合においては２倍にもなり得る。
【０００５】
従来技術による通常的なサプライチェーンが、図１に示されている。顧客は、概して、従来技術のサプライチェーンを用いて部品およびサブ部品を調達するための２つの方法を有している。従来技術のサプライチェーン５０に示されるように、大規模な相手先商標製品製造業者（ＯＥＭ）、請負電子部品製造業者（contract electronics manufacturer：ＣＥＭ）（図示せず）、または、（部品の）顧客５２は、通常的には、部品製造業者（すなわち、供給業者５６）から直接的に購買する。このテクニックは、この業界において、“直接的購買（buying direct）”として知られている。大規模な顧客５２は、部品が必要となる毎に、供給業者に対して注文を行う。供給業者５６は、製品を運送業者（carrier）５８に渡し、運送業者５８は、注文された製品を大規模な顧客５２へ配達する。
【０００６】
小規模な顧客５４は、通常的には、第三者的な卸売業者（distrobutor）または代理店６０を通して購入を行う。卸売業者６０は供給業者５６から部品を購入し、供給業者５６は製品を運送業者６２に渡し、運送業者６２は製品を卸売業者６０へ持ってくる。次に、卸売業者６０は製品を他の運送業者６４へ移送し、該運送業者６４が製品を小規模な顧客５４へ配達する。他の形式の第三者的な卸売業者は、部品の競売を開催するために電子的手段を用いる。しかしながら、電子競売に伴う時間が冗長であるので、このようなサービスは、一回限りまたはスポット買いで部品が必要な場合を除いては、ほとんど用いられていない。
【０００７】
当事者たちの多くは、従来技術のサプライチェーンに満足していない。公知のサプライチェーンネットワークは、通常は、出荷のミスや、顧客への部品供給の断絶を生じさせる。これらの欠陥は、特に、重要な部品が不足している場合の“割り当て”のときに、顧客を失望させる。このことにより、最終的な出荷に遅延が生じ、かつ、これに伴い、歳入および収益の損失が生じる。
【０００８】
特に、部品供給業者５６は、従来技術のサプライチェーンに失望している。これらのエンティティの最終製品に関する市場状態の変化は、変動が激しい（volatile）製造スケジュールを生じさせ、非能率的な工場の利用およびコストの上昇という結果をもたらす。部品供給業者５６は、工場の負荷と棚卸資産レベルを徐々に向上させようとすべく、資材資源計画（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）および承認についても、注文管理モジュールの一部として組み込むことができる。需要が有効化されかつ顧客の信用（credit）がチェックされた後に、需要は、計画モジュールへ送られる。信用状態を保留されている（credit hold）顧客に関する需要については、アカウントマネージャ（Account Manager）による作用のために、サスペンドファイルへ送ることができる。
【００４０】
以下に、注文管理モジュールの例示的な実施形態について説明する。図４を参照すると、規則的な需要スケジュール中において、注文管理モジュールにより実行される需要捕捉および有効化工程を示す図である。規則的な需要スケジュール中において、サプライチェーンサーバー７４は、２０４において、顧客による１３週分の予測２００と、第０週の毎日のコールアウト（week 0 daily callouts）とを、顧客から受け取る。これらの予測については、複数の顧客からのものであってもよく、または、一人の顧客による複数のソースからものであってもよい。受け取り回路２０４は、例えば、ＥＤＩ（電子データ交換）予測や、（例えば、ＥＸＣＥＬ（登録商標）のスプレッドシートによる）電子メールや、ＥＤＩ購買注文（“ＰＯ”）を通して、または、ＸＭＬ（拡張可能なマーク付け言語）通信を通して、顧客の需要を捕捉することができる。受け取り回路２０４は、顧客との契約においては条件指定できない特定のサービスを捕捉することもできる。例えば、緊急の配達（expedited delivery）や、特殊なラベリングや、パッケージングなどを、全て捕捉することができる。サプライチェーンサーバー７４は、２０６において、顧客の需要２００，２０２を、該サプライチェーンサーバー７４が用いる標準的なフォーマットに変換して、該顧客の需要を分析する。変換２０６に問題があれば、全ての技術的問題点を修正するためのエラールーチン２０８が実行される。好ましい実施形態において、このような全ての技術的問題点は、営業日の終わりまでに解決される。その後に、遅延回路２１０は、全ての変換された需要が貯蔵されることを保証し、かつ、必要とされる機能上の有効化（functional validation）が、営業日の終わりまでに実行される。このような遅延によって、サーバー７４が、全ての顧客のための需要（２００，２０２）を蓄積することが可能となる。
【００４１】
顧客情報収集回路２１２は、変換された顧客の需要を、対応する顧客の契約２１４、および、該顧客の製品に関する顧客製品情報２１３と比較する。前記情報２１３は、例えば、承認された供給業者、仕様の改訂レベルなどを含む。
【００４２】
有効化回路２１６は、変換された需要が有効であるか否かを判断する。有効化回路２１６は、例えば、需要している顧客が実際にサプライチェーンネットワーク７０の顧客であるか否かを検出する。さらに、有効化回路２１６は、場所に対する計画／出荷と部品番号との全ての組み合わせに関して予測がなされているという点で、および、全ての部品番号が特定の数量を有しているという点で、顧客の予測２００が完全であるか否かを検出する。最終的に、有効化回路２１６は、要求された部品番号が、顧客７２とサプライチェーンサーバー７４を運営するエンティティとの間で契約された有効な部品に関連することを検証することができる。
【００４３】
前記有効化回路２１６が、特定の顧客の需要が有効ではないと判断すれば、エラールーチン２１８が実行され、この場合に、未払いの（outstanding）問題を解決するための通知が、アカウントマネージャに送られる。アカウントマネージャは、全ての顧客の支払い履歴を評価することにより該顧客に関する現在の評価（standing）を維持するために用いられる。次に、サプライチェーンサーバー７４は、ある点において需要が不完全であることを知らせるための例外通知を、顧客７２に送る。例外通知自体は、作用を受けるまではサスペンドファイルに貯蔵される。顧客の需要が有効であれば、サプライチェーンサーバー７４は、顧客の信用履歴２２２を参照することにより、２２０において、顧客の信用状態をチェックする。顧客の信用評価が２２４において承認されれば、サプライチェーンサーバー７４は、計画モジュール（図８）へ分岐する。顧客の信用評価が２２４において承認されなければ、エラールーチン２２６が開始され、この場合に、プランナー、アカウントマネージャ、および、クレジットマネージャ（Credit Manager）は、問題の解決法を考え出そうとする。支払いの遅延または滞納状態の預金口座は、クレジットマネージャにより監視される。信用状態を拒否された全ての顧客の需要は、クレジットサスペンドファイルに貯蔵される。劣悪な信用状態の故に顧客の需要が拒否されれば、顧客の購買の意向について知らせる通知が、アカウントマネージャと、クレジットマネージャと、プランナーとに送られる。このような状況において、プランナーは、顧客の要求について考慮することができるが、信用問題が解決されるまでは、実際に計画を実施する義務はない。
【００４４】
アドホックな需要に関して、注文管理モジュールの工程の流れが図５に示されている。図５を参照すると、図４の規則的な顧客の予測の場合のように、サプライチェーンサーバー７４は、２３０において、アドホックな需要２３２を受け取り、かつ、２３４において、前述したように、アドホックな需要２３２を標準的なフォーマットに変換する。再び述べると、アドホックな需要２３２については、例えば、ＥＸＣＥＬ（登録商標）のスプレッドシートによる電子メールや、ＥＤＩ購買注文（“ＰＯ”）を介して捕捉することができる。顧客との契約において条件指定されなかった、緊急の配達（expedited delivery）や、特殊なラベリングや、パッケージングのような追加的サービスもまた捕捉される。規則的な顧客の予測とは異なり、注文の課金情報を追跡すべく、アドホックな需要を識別するためのフィールド（図示せず）が確立される。このフィールドについては、アドホックな注文に対して追加料金を発生させるために任意選択的に用いることができる。顧客の需要を標準的なフォーマットに変換することに問題があれば、全ての技術的問題点を修正するためのエラールーチン２３６が実行される。好ましい実施形態において、このような全ての技術的問題点は、営業日の終わりまでに解決される。
【００４５】
その後に、遅延回路２３８は、全ての変換された需要が貯蔵されることを保証し、かつ、必要とされる機能上の有効化が、営業日の終わりまでに実行される。顧客情報収集回路２４０は、変換された顧客の需要を編集しかつ該需要を顧客の契約２１４および顧客製品情報２１３と比較することにより、有効化を実行する。
【００４６】
有効化回路２４４は、変換された需要が有効であるか否かを判断する。有効化回路２４４は、例えば、需要している顧客が実際にサプライチェーンネットワーク７０の顧客であるか否かを検出する。さらに、有効化回路２４４は、要求された部品番号が、顧客７２とサプライチェーンサーバー７４との間で契約された有効な部品であるか否かを検出する。正常に（normal）予測された需要とは異なり、アドホックな需要２３２が完全であるか否かを判断するための有効化は不要である。その理由は、このような需要は、予測されていない需要であり、かつ、１つ以上の顧客の部品番号を含み得るためである。
【００４７】
前記有効化回路２４４が顧客の需要が有効ではないと判断すれば、エラールーチン２４６が実行され、この場合に、未払いの問題を解決するための通知が、アカウントマネージャに送られる。次に、サプライチェーンサーバー７４は、ある点において需要が不完全であることを知らせるための例外通知を、顧客７２に送る。例外通知自体は、サスペンドファイルに貯蔵される。顧客の需要が有効であれば、サプライチェーンサーバー７４は、顧客の信用履歴２５０を参照することにより、２４８において、顧客の信用状態をチェックする。顧客の信用評価が２５２において承認されれば、サプライチェーンサーバー７４は、計画モジュールへ分岐する。顧客の信用評価が２５２において承認されなければ、エラールーチン２５４が開始され、この場合に、プランナー、アカウントマネージャ、および、クレジットマネージャは、問題の解決法を考え出そうとする。信用状態を拒否された全ての顧客の需要は、クレジットサスペンドファイルに貯蔵される。劣悪な信用状態の故に顧客の需要が拒否されれば、顧客の購買の意向について知らせる通知が、アカウントマネージャと、クレジットマネージャと、プランナーとに送られる。
【００４８】
こうして、前記サプライチェーンサーバー７４の注文管理モジュールは、従来技術において用いられていた購入注文システムに取って代わる予測システムを用いることができる。従来技術のサプライシステムにおいては、供給業者は、予測を調べなかったので、予測が契約上の同意に反するものであるか否かを、または、予測の中に望ましくないエラーが存在するか否かを判断することができなかった。供給業者は、特定の顧客が何を供給業者に与えたのかについて調べるだけであった。たとえ供給業者がＭＰＲシステムを用いたとしても、ＭＲＰの需要は、頻繁に著しく変動するので、供給業者は、これらの需要を検討して異常なまたは予想されていない要求を確認するための能力を有していなかった。したがって、供給業者は、しばしば、在庫品の予想消耗量について決して確信を持てないような様式で、自分たちの在庫品を補充する補充アルゴリズム（replenishment algorithms）を用いていた。
【００４９】
本発明は、契約上の同意との一貫性と以前に行われた予測とに関して、顧客の予測を検討することにより、これらの問題を克服する。これにより、本発明は、連続的な配達およびパフォーマンスを生じさせ、これにより、供給業者が過剰な棚卸資産を有している場合に生じる望ましくない残り物の材料の量を低下させる。需要の変動性（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）の評価１０４を行い、かつ、該予測の可変性が定義パラメータに順応しない場合に、例外通知１０６を発行する。顧客７２が要求した部品番号は、対応するサプライチェーンネットワークの部品番号に変換される。サプライチェーンサーバー７４は、１１０において、サプライチェーンネットワークの部品番号に関する需要の可変性を評価する。顧客評価１０４の場合のように、サプライチェーンサーバー７４は、全体的な需要の可変性を判断する。この計算は、たとえ個々の顧客が許容範囲の超過を回避したとしても、特に多くの顧客が供給業者の許容限界点に近い注文を行った場合に、全ての顧客による要求の総計が供給業者の総供給量を超過してしまう可能性がある、という点で有用である。このような注文によって、供給業者の製品全体が枯渇し、復旧するためにはかなりの時間がかかる可能性がある。次に、サプライチェーンネットワークの部品番号は、１１２において、対応する供給業者の部品番号に変換される。
【００７２】
供給業者７６の生産能力は、顧客７２の予測１００と関係した生産能力の問題が存在するか否かを判断するために、１１４において有効化される。１１５に示されるように、この工程は、現在の第０週の需要によって開始され、かつ、１２週分の需要にわたって反復される。生産能力に関するあらゆる問題は、１１６において、通知１１８を供給業者７６へ送りかつ通知１２０を顧客７２へ送ることにより解決される。さらに、顧客７２は、該顧客７２が予測１００の一部または全てに関する任意選択的な中止１２４を送ることを可能にする中止コード（abort code）１２２を受け取る。次に、サプライチェーンサーバー７４は、供給業者７６との全ての需要問題１２６を解決し、かつ、制御は、図１０Ａの調達モジュールへ分岐する。このような中止は、顧客がサプライチェーンサーバー７４を通してそのアカウントにアクセスした場合に表示され、これにより、顧客は、特定の部品に関する注文が中止されたことを知る。以下に、これらの工程について、例によって詳細に説明する。
【００７３】
以下に、図７を参照すると、正常な計画シナリオ中にサプライチェーンサーバー７４が実行する工程が示されている。計画モジュールにおいて、サプライチェーンサーバー７４は、顧客の予測に関する情報を、（前述の）注文管理モジュールから受け取る。次に、サプライチェーンサーバー７４は、１３０において、全ての有効化された顧客の要求を整理統合する。この整理統合は、顧客の部品および番号に基づいて、全ての顧客の予測を、１つの大きなファイル（図示せず）の形にグループ化することを含む。有効化自体については、注文管理モジュールの欄で前述した。簡潔に述べれば、有効化は、顧客の需要が契約下において無効、不完全、または、異常であるか否かを判断することを含む。有効化に問題があれば、エラー工程１３２が実行される。エラー工程１３２についても、より十分に前述してある。簡潔に述べれば、サプライチェーンサーバー７４は、有効化問題を有する顧客と連絡を取って、需要の変更を理解しかつ解決する。このことは、特定の部品番号に関して需要の数量を調整することを含む。これにより、あらゆる変更が、調整された予測に反映される。
【００７４】
次に、前記整理統合された需要ファイルは、１３４において、対応するサプライチェーンネットワークの部品番号を識別するために分析され、かつ、サプライチェーンネットワークの部品番号に対応する部品を提供する供給業者へ提案される。供給業者の識別は、前述のように顧客と協議された契約に基づくものである。分析１３４において、独自の識別子が、各週の間における各々の顧客からの各々の部品に対する需要を示すために割り当てられる。これらの識別子は、各々の需要に関する会計報告（audit trail）を作成するために用いられる。さらに、分析１３４は、前週の需要からの予測１００を評価して、（注文管理モジュールの説明において、より十分に前述したような）例外的条件を判断する。
【００７５】
次に、前記サプライチェーンサーバー７４は、１３６において、整理統合された需要ファイルのサプライチェーンネットワークの部品番号を、対応する供給業者の部品番号に変換する。この変換については、顧客の部品番号を用いて行うこともできる。次に、整理統合された需要ファイルは、１３８において集計されて、これにより、サプライチェーンサーバー７４と供給業者７６との間の契約上の要因に基づいて、供給業者のＭＰＵが生じる。次に、整理統合された需要ファイルは、１４２において、供給業者７６の生産能力と、サプライチェーンサーバー７４と供給業者７６との間の契約上の規定に基づいて有効化される。これらの契約上の規定は、あらゆる契約上の生産能力、または、整理統合された需要ファイルに基づいて可能にすることができる供給業者の凍結限界点（freeze horizon）に関連する。最終的に、サプライチェーンサーバー７４は、１４４において、集計された需要が供給業者の生産能力よりも多いか否かを問い合わせる。供給業者の生産能力については、供給業者７６がサーバー７４へ供給したデータから、または、供給業者７６が自分たちのそれぞれのデータベースへサーバー７４がアクセスすることを可能にすることにより、判断することができる。需要が生産能力よりも多くなければ、サプライチェーンサーバー７４は、図１０Ａを参照して説明する段階３３０へ分岐する。需要が生産能力よりも多ければ、サプライチェーンサーバー７４は、図８に示されるような、制約された供給計画ルーチン１４８へ分岐する。
【００７６】
図８を参照すると、制約的な（constrained）供給計画ルーチン１４８は、最初に、１５０において、需要と供給との間にいかなるアンバランスも結果的に生じないことを保証しようとして、顧客の需要を再分配する。この再分配は、反復的工程を用いて実行され、かつ、プランナーは、供給業者の生産能力と契約上の凍結限界点とに鑑みて、プランナーツール（図２４を参照して後述する）を用いて代替的供給ソースを決定する。次に、サプライチェーンサーバー７４は、１５２において、新たな結果として生じた需要が供給業者の生産能力よりも多いか否かを問い合わせる。再び述べると、需要が生産能力よりも多くなければ、サプライチェーンサーバー７４は、調達モジュールにおける３３０へ分岐する。そうでない場合には、サプライチェーンサーバー７４は、供給業者への介入１５４へ分岐する。供給業者への介入１５４において、サプライチェーンサーバー７４は、供給業者７６の生産能力が需要に追従できない原因となっている状況（例えば、原材料の制約、または、破綻的な生産能力の問題）について確認するために供給業者７６と連絡を取り、かつ、可能な代替案（例えば、今後の生産能力の増大のために、前もって作るかまたは貯蔵しておく可能性）を評価する。これにより、新たな供給業者の生産能力が生じる。
【００７７】
前記供給業者への介入１５４において供給業者と連絡を取った後に、サプライチェーンサーバー７４は、１５６において、新たな生産能力が顧客の需要よりも少ないか否かを問い合わせる。再び述べると、需要が生産能力よりも多くなければ、サプライチェーンサーバー７４は、調達モジュールにおける３３０へ分岐する。そうでない場合には、サプライチェーンサーバー７４は、顧客への介入１５８へ分岐する。顧客への介入１５８において、サプライチェーンサーバー７４は、顧客７２の柔軟性（例えば、部品の代用、配達日の前倒しまたは引き延ばし）について確認するために顧客７２と連絡を取り、これにより、新たな顧客の需要が生じる。前記顧客への介入１５８において顧客と連絡を取った後に、サプライチェーンサーバー７４は、１６０において、新たな顧客の需要が供給業者の生産能力よりも多いか否かを問い合わせる。再び述べると、需要が生産能力よりも多くなければ、サプライチェーンサーバー７４は、調達モジュールにおける３３０へ分岐する。そうでない場合には、サプライチェーンサーバー７４は、供給割り当てルーチン１６２へ分岐する。
【００７８】
前記供給割り当てルーチン１６２において、供給業者から実際に利用可能な部品（“制約部品”）は、需要している顧客の間で均等に割り当てられ、かつ、これに応じて、顧客の予測が変更される。このような場合において、需要している全ての顧客は均等数の制約部品を受け取ることができるか、または、需要している顧客は、ある特定の顧客が要求している部品の個数と他の顧客が要求している部品の個数との関係に基づいて、比例した（pro rata）分担数の制約部品を受け取ることもできる。その後に、サプライチェーンサーバー７４は、調達モジュールにおける３３０へ分岐する。
【００７９】
図７および図８において詳述したような、顧客の予測に応じてサプライチェーンサーバー７４が実行する正常な計画シナリオの他に、計画モジュールは、アドホックな需要を処理することもできる。図９を参照すると、顧客からのアドホックな需要に応じてサプライチェーンサーバー７４が実行する工程が示されている。正常な注文の場合のように、サプライチェーンサーバー７４は、顧客需要ファイルを、注文管理モジュールから受け取る。次に、この需要ファイルは、１６６において、対応するサプライチェーンサーバーの供給番号を識別するために分析され、かつ、サプライチェーンサーバーの供給番号に対応する部品を提供する供給業者へ提案される。供給業者の識別は、前述のように好ましい供給業者に関して顧客と協議された契約に基づくものである。分析１６６において、独自の識別子が、各週の間における各々の顧客からの各々の部品に対する需要を示すために割り当てられる。
【００８０】
次に、前記サプライチェーンサーバー７４は、１６８において、需要ファイルのサプライチェーンサーバーの供給番号を、対応する供給業者の部品番号に変換する。この変換については、顧客の部品番号を用いて行うこともできる。その後に、識別回路１７０において、サプライチェーンサーバー７４は、供給業者７６と連絡を取り、かつ、アドホックな需要のために代替的な供給品を提供できる種々の供給業者を識別する。
【００８１】
その後に、前記サプライチェーンサーバー７４は、１７２において、第０週の供給予測を修正して、供給業者および顧客の両方に関する新たな数量を反映した修正予測１７８を生じさせる。さらに、修正された第０週の予測は、後述する調達モジュールへ送られる。サプライチェーンサーバー７４は、１７４において、購入注文番号と類似した各々の供給業者に対する特定の週の需要を示す独自の識別子とともに、修正予測１７８を供給業者へ送る。最終的に、サプライチェーンサーバー７４は、１７６において、アドホックな需要に関する積み込みおよび配達指示を示す文書１８０を、３ＰＬ７８へを送る。アドホックな需要による注文は、直接的に顧客へ送られ、かつ、大抵の場合には、前述したクロスドックを通しては送られない。
【００８２】
こうして、複数の顧客から予測を受け取って処理し、かつ、これらの予測を供給業者の生産能力の総計に関して評価することにより、計画モジュールは、従来技術において利用可能であったものよりも効率的かつ有用な供給計画を生じさせることができる。さらに、ネットワークが複数の供給業者と連絡しているので、計画モジュールは、顧客の需要の割り当てを供給業者間でシフトすることができ、これにより、これらの需要が満たされることが保証される。
【００８３】
《IV．調達（Procurement）》
調達モジュール（Procurement Module）は、購入工程を実行する。この機能の焦点は、注文処理工程（注文処理モジュールについては、より完全に後述する）の正確さおよび適時性に関する有効化を含む購入対支払い（purchase-to-pay）サイクルにある。調達モジュールが扱うさらなる領域は、供給注文を、供給業者（データインターフェース）へ伝達することと、リバースロジスティックス（reverse logistics）とを含む。
【００８４】
前記リバースロジスティックスは、他の方法では得られない値を捕捉する目的のために、または、適切な製品の処分のために、製品を該製品の通常的な最終目的地から他の地点へ移動させる工程である。調達モジュールの好ましい実施形態について、以下に説明する。サプライチェーンサーバー７４は、計画モジュールの完了時に、ＥＤＩやウェブや電子メール、または、他の手段を介して、供給計画（第０週の需要を含む）を供給業者７６へ伝送する。供給業者７６が供給計画を実行しかつ３ＰＬ７８が出荷品を積み込んだ後に、供給業者７６は、ＡＳＮ（事前出荷通知）をサプライチェーンサーバー７４へ伝送する。各々のＡＳＮは、通常的には、１ラインの品目（one line item）を含み、かつ、契約協議過程に基づいて同意された全ての必要なデータを含んで電子的に受信される。ＡＳＮは、供給計画に対して有効化され、かつ、例外的事態がプランナーにより解決される。有効なＡＳＮは、購入注文と（ＡＳＮと購入注文との間には、概して、１対１の関係が存在する。すなわち、全てのラインの品目は、供給業者の部品番号を用いて識別される。）、クロスドック指示（３ＰＬへ伝送される）とを生成するために用いられる。これと平行して、ＥＲＰシステムにおいて、領収証が作成される。従来技術のサプライチェーンとは異なり、本発明は、購入注文と、需要部品の入手を示す受領通知との生成を誘発するために、供給業者のＡＳＮを用いる。これにより、従来技術のシステムにおいて行われていた多数の段階が切り詰められる。その理由は、需要が購入注文ではなく予測に基づくものであるので、注文処理できる可能性がより高い供給業者へ伝達されるためである。
【００８５】
顧客から毎日受け取られる全ての支払いは、各々の供給業者７６のために、サプライチェーンサーバー７４によりリスト化され、かつ、整理統合される。特定の注文に対する支払いがＥＦＴ（電子資金移動）を介して顧客７２から受け取られれば、サプライチェーンサーバー７４は、支払いファイルを銀行へアップロードし、かつ、供給業者７６に支払いが行われる（例えば、１日に１回）。支払い情報のリリースによって、ＥＲＰが自動的に更新される。さらに、銀行は、支払い情報を示す確認書をサプライチェーンサーバー７４へ送る。支払いが小切手を介して行われれば、送金通知書（remittance advice notice）および小切手に押印され、かつ、供給業者へ送られる。
【００８６】
顧客がサプライチェーンネットワーク７０を通して調達された材料を返品したいと判断すれば、顧客は、返品認可（return authorization）を得るために、サプライチェーンサーバー７４に連絡を取る。サプライチェーンサーバー７４は、供給業者７６から事前に認可されかつ返品受理に関する条項（terms）に基づいて同意された返品認可を有している。サプライチェーンサーバー７４は、この認可を顧客７２へ送り、かつ、コピーを供給業者７６へ送る。供給業者７６が確立された返品工程を有していれば、サプライチェーンサーバー７４は、返品指示を顧客７２へ送る。いったん、サプライチェーンサーバーが供給業者の運送業者９６からＰＯＤ（配達証明）を得ると、サプライチェーンサーバー７４は、供給業者の預金口座に借方記入（debit）を行い、かつ、顧客に貸方記入（credit）を発行する。あらゆる借方記入または貸方記入は、最初に、供給業者からのあらゆる未決算の送り状（open invoices）に適用される。
【００８７】
供給業者７６が確立された返品工程を有していなければ、いったん、前記認証が実施されると、サプライチェーンサーバー７４は、必要に応じて、積み込み指示を３ＰＬ７８へ送る。（１）供給業者が取り替え部品を棚卸資産内に有しているか否か、および、（２）顧客が取り替え部品を直ちに必要とするか否か、または、取り替え部品の需要を、既存の予測に追加することができるか否か、について判断する必要がある。顧客が取り替え部品を直ちに必要とすれば、供給業者の利用可能な棚卸資産が好ましいソースとなる。棚卸資産が利用可能でなければ、取り替え部品を速やかに製造し、かつ、顧客へ配達すべきである。取り替え部品を既存の予測に追加することができれば、計画工程は、次の１３週分の予測に組み込まれたさらなる需要によって継続される（計画モジュールの説明を参照）。再び述べると、いったん、サプライチェーンサーバー７４が３ＰＬ７８からＰＯＤを受け取ると、サプライチェーンサーバー７４は、供給業者の預金口座に借方記入を行い、かつ、顧客に貸方記入を発行する。あらゆる借方記入または貸方記入は、最初に、供給業者からのあらゆる未決算の送り状に適用される。以下に、これらの工程について、例によって説明する。
【００８８】
図１０Ａを参照すると、本発明による、調達モジュール中における情報の流れが示されている。サプライチェーンサーバー７４が、計画モジュールに関係した作業工程を終了した後に、第０週（すなわち、今週）の供給需要が、適切な供給業者７６へ送られる。供給業者７６は、３３０において、第０週の需要を実行処理し、供給業者ＡＳＮ３３２を発行し、かつ、ＡＳＮ３３２をサプライチェーンサーバー７４へ送る。サプライチェーンサーバー７４は、３３４において、供給業者ＡＳＮ３３２を受け取る。概して、各々のＡＳＮ３３２には、１ラインの品目のみが含まれる。ＡＳＮ情報自体は、供給業者の部品番号の形で存在する。供給業者のＡＳＮの正確さのパーセンテージが低ければ、または、供給業者がＡＳＮを送ることができなければ、パッキングスリップ（packing slip）が代わりに用いられる。
【００８９】
前記サプライチェーンサーバー７４は、３３６において、該サプライチェーンサーバー７４が顧客の予測に応じて生成した供給計画３３８に対してＡＳＮ３３２を有効化する。３４０において、ＡＳＮが供給計画３３８マッチングしなければ、すなわち、供給業者が配達した製品が該供給業者に注文した製品とマッチングしないことが示されれば、エラールーチン３４２が実施され、かつ、供給業者７６に通知される。このような場合においては、サプライチェーンサーバー７４は、例えば、残りの部分的出荷を直ちにキャンセルしたり、または、出荷品を返品するなどの、契約上の選択権を有する。そうでない場合には、サプライチェーンサーバー７４は、図１１に示される段階３４４へ分岐する。
【００９０】
図１０Ｂを参照すると、本発明による、エラールーチン３４２の例が示されている。サプライチェーンサーバー７４は、４６０において、合致した出荷品ではないことを警告する例外通知４６２を供給業者７６へ送る。その後に、サプライチェーンサーバー７４は、ＡＳＮ３３２と供給計画３３８との比較が、所定の許容範囲外となる出荷過剰（over-shipment）または出荷不足（short-shipment）という結果となるか否かを判断する。
【００９１】
前記比較が出荷過剰を生じさせれば、制御は段階４６６へ分岐し、この場合に、サプライチェーンサーバー７４は、出荷過剰に関係した超過材料の処分を決定する。このことは、プランナーにこの状況について供給業者７６および関連顧客７２と討議させることにより実行され、これにより、超過材料の適切な処分が決定される。その後に、サプライチェーンサーバー７４は、４７０において、結果として生じた処分計画を実行処理し、次に、図１１に示される段階３４４へ分岐する。処分の例は、超過材料を供給業者へ返品すること、追加的な材料を顧客へ出荷すること（および、必要に応じて、予測を調整すること）、または、超過材料を３ＰＬ７８に貯蔵することを含む。材料が供給業者へ返品される場合には、供給業者７６には、何らかの追加的な貨物運送料が課金される。さらに、供給業者７６には、超過材料を３ＰＬ７８に貯蔵するためにかかる追加的な費用も課金される。
【００９２】
前記比較が出荷不足を生じさせれば、サプライチェーンサーバー７４は、４６８において、プランナーに供給業者７６および関連顧客７２に連絡を取らせることにより、この状況を評価する。この連絡は、出荷不足が単なる出荷の遅延であるか否かを、または、プランナーが供給の割り当てをさらに行う必要があるか否かを判断するのに役立つ。プランナーは、この状況について、影響を受ける顧客と討議することもできる。その後に、サプライチェーンサーバー７４は、４７２において、利用可能な供給品のパーセンテージを各々の顧客に割り当て、かつ、制御は、図１１に示される段階３４４へ分岐する。
【００９３】
以下に、図１１を参照すると、前記段階３４４において、サプライチェーンサーバー７４は、ＡＳＮ３３２に基づいて購入注文を作成する。購入注文は、各々の顧客のための各々の部品に対して作成される。次に、サプライチェーンサーバー７４は、３５０において、領収書を作成し、かつ、３４６において、３４４での購入注文に基づいてクロスドック指示３４８を生成する。領収書は、購入注文と同様に、部品単位で、供給業者により系統的に整理される。クロスドック指示３４８は、顧客による返品のための積み込み指示を含むことができる。出荷不足の状況において、クロスドック指示３４８は、前述のようなプランナーの割り当てを反映する。合致していない出荷物を受け取るとすぐに、３ＰＬ７８は、サプライチェーンサーバー７４に通知する。クロスドック指示３４８に関する完全な説明については、注文処理モジュールの説明において後述する。
【００９４】
全ての第０週の需要が受け取られかつ処理されることを保証する固有の（inherent）遅延３５２の後に、サプライチェーンサーバー７４は、段階３５０において作成された領収書を、先に作成された供給計画３３８（図１０Ａを参照）、および、図１７において後述する販売注文２９０とマッチングする。このマッチングは、運送中に損失された材料がないことを検証するために行われる。ある購入注文を構成する全ての販売注文については、このマッチングが実行される前に生じさせる。３５６において、文書がマッチングしなければ、エラールーチン３５８が開始される。３５０において作成された領収書が数量または価格のいずれかの点において販売注文２９０よりも多ければ、考えられる問題の原因は、販売注文の生成の遅延であり得る。領収書が数量または価格のいずれかの点において販売注文２９０よりも少なければ、考えられる問題の原因は、データの完全性の問題、または、その材料が３ＰＬにおいてまたは運送中に損失されたことであり得る。いずれの場合においても、プランナーが介入すべきである。段階３５０において作成された領収書が、３５６において、供給計画３３８および販売注文２９０とマッチングすれば、サプライチェーンサーバー７４は、段階３６０，３６２へ移動し、これらの段階において、証票（voucher）および支払勘定（payable）がそれぞれ作成される。
【００９５】
次に、前記サプライチェーンサーバーは、図１２の問い合わせ３６４へ分岐し、かつ、特定の供給業者に関する借方記入（または、貸方記入）が未払いであるか否かを判断する。未払いの借方記入がなければ、制御は、段階３７６（図１３）へ分岐する。そうでない場合には、制御は、段階３６６へ分岐し、この場合に、サプライチェーンサーバー７４は、特定の供給業者に関する未決算の送り状が存在するか否かを判断する。未決算の送り状が存在すれば、サプライチェーンサーバー７４は、３６８において、段階３６４で判断された借方記入をこの未決算の送り状に対して適用し、かつ、段階３７２へ分岐する。そうでない場合には、サプライチェーンサーバー７４は、特定の供給業者に関する今後の残高に対して借方記入を適用し、かつ、段階３７２へ分岐する。段階３７２において、サプライチェーンサーバー７４は、顧客の貸方記入３７４を発行する。その後に、サプライチェーンサーバー７４の制御は、さらに、段階３７６へ分岐する。
【００９６】
以下に、図１３を参照すると、段階３７６において、サプライチェーンサーバー７４は、顧客７２からの支払いが受け取られたか否かを問い合わせる。支払いがまだ受け取られていなければ、サプライチェーンサーバー７４は、遅延期間３７８だけ待機し、次に、支払いが受け取られたか否かに関する問い合わせ３７６を続ける。こうして、供給業者への支払いは、支払いが顧客から受け取られるまで遅延される。顧客の支払い自体は、終日にわたって集計される。支払いが受け取られると、制御は、支払いがＥＦＴを通して行われたか否かを判断する問い合わせ３８０へ分岐する。支払いがＥＦＴを通して行われていなければ、サプライチェーンサーバー７４は、３８２において、小切手および送金通知書に押印し、次に、段階３８６へ分岐する。そうでない場合には、サプライチェーンサーバー７４は、３８４において、ＥＦＴファイルを生成し、次に、段階３８６へ分岐する。特定の供給業者に関するＥＦＴ情報は、マスターデータファイルの一部である。ＥＦＴによる支払いは、（顧客から受け取った支払いの終日にわたる集計に基づいて）毎日の終わりに各々の供給業者へ送られる。
【００９７】
前記段階３８６において、サプライチェーンサーバー７４は、小切手および送金通知書３８８によって、供給業者７６と３ＰＬ７８とに支払いを行う。図２１を参照して後述する融資オプションが実施されれば、サプライチェーンサーバー７４は、さらに、ＥＦＴファイルを銀行３９２へ送る。ＥＦＴファイル３９０は、貨物運送料金表（freight tables）に基づいて、供給業者７６には１日に１回、かつ、３ＰＬ７８には１ヶ月に１回だけ送られる。その後、しばらくして、預金口座の状態３９４が、サプライチェーンサーバー７４へ送られる。サプライチェーンサーバー７４は、預金口座の状態３９４を受け取り、かつ、３９６において、銀行３９２へ伝送されたＥＦＴファイル３９０と比較する。次に、サプライチェーンサーバー７４は、３９８において、一ヶ月の終わり、四半期の終わりなどの報告を含む報告を生成する。
【００９８】
前記調達モジュールは、顧客７２がサプライチェーンネットワーク７０を通して得られた材料の返品を望む状況においても用いられる。図１４を参照すると、返品工程を開始するために、顧客７２は、部品返品認可のための要求４１０を、サプライチェーンサーバー７４に行う。各々の供給業者７６は、自分が供給した部品に関して事前に発行した返品認可４１２を、サプライチェーンサーバー７４に提供する。サプライチェーンサーバー７４は、要求４１０と返品認可４１２とを受け取り、かつ、４１４において、所定の供給業者固有の基準を用いて、材料の返品を認可する。サプライチェーンサーバー７４は、さらに、マスター供給記録（図示せず）を受け取って、返品すべき品目のソースを判断する。このマスター供給記録は、どの顧客が、何日に、対応する供給業者から製品を受け取ったのかを示す。こうして、サプライチェーンサーバー７４は、顧客が返品を望んでいる製品の製造元を確認することができる。
【００９９】
段階４１６において、前記サプライチェーンサーバー７４は、返品認可４１８を、顧客７２および供給業者７６の両方へ送る。次に、サプライチェーンサーバー７４は、４２０において、製品を返品される予定の供給業者が確立された返品工程を有しているか否かに関する問い合わせを行う。供給業者がこのような工程を有していれば、この工程が用いられ、かつ、サプライチェーンサーバー７４は、４２２において、対応する返品指示４２４を顧客７２へ送る。次に、制御は、図１２に示される段階４２６へ分岐する。そうでない場合には、供給業者が確立された工程を有していなければ、制御は、図１５の段階４４０へ分岐する。
【０１００】
再び、図１２を参照すると、段階４２６において、サプライチェーンサーバー７４は、製品が顧客から返品されたことを示す返品製品の配達証明（Proof of Delivery：ＰＯＤ）４３０が供給業者の運送業者９６から受け取られたか否かに関する問い合わせを行う。否定的結果であれば、サプライチェーンサーバー７４は、遅延期間４２８だけ待機し、次に、返品製品のＰＯＤ４３０の受け取りを待ち続ける。明らかに、返品製品のＰＯＤが受け取られなければ、貸方記入は発生されない。サプライチェーンサーバー７４は、返品製品のＰＯＤ４３０を受け取れば、４３２において、支払勘定が適切に処理された場合に適用される借方記入を、供給業者７６に対して発行する。次に、制御が、詳細に前述した段階３６４へ分岐する。
【０１０１】
図１５を参照すると、供給業者が確立された返品工程を有していなければ、段階４４０において、サプライチェーンサーバー７４は、顧客７２が取り替え部品を必要としているか否かを判断する。取り替え部品が必要とされていなければ、制御は、図１２を参照して前述した段階４２６へ分岐する。そうでない場合には、制御は段階４４２へ分岐し、この場合に、サプライチェーンサーバー７４は、顧客にとって好ましい供給業者として列挙されているか、または、出荷品を直ちに提供できる供給業者の棚卸資産から取り替え部品が利用可能であるか否かを判断する。部品が棚卸資産から利用可能でなければ、制御は段階４４４へ分岐し、この場合に、サプライチェーンサーバー７４は、取り替え部品が今週中に必要とされるか否かを判断する。取り替え部品が今週中に必要とされれば、制御は、図５を参照して前述したアドホックな需要のための注文管理モジュールへ分岐する。取り替え部品が今週中に必要とされなければ、制御は、計画モジュールへ分岐し、かつ、この需要は、例えば、図６において説明したように、今後の数週間分の予測に吸収される。
【０１０２】
前記段階４４２へ戻ると、取り替え部品が棚卸資産から利用可能でなければ、サプライチェーンサーバー７４は、４４６において、指示４４８を供給業者７６へ送る。指示４４８は、利用可能な取り替え部品を棚卸資産から直ちに出荷するように、供給業者７６に指図するものである。このような場合において、供給業者７６は、出荷費用を負担し、かつ、３ＰＬ７８を用いる。さらに、サプライチェーンサーバー７４は、４５０において、積み込み／配達指示４５２を生じさせ、該積み込み／配達指示４５２は、３ＰＬ７８へ送られる。次に、制御は、再び、図１２を参照して前述した段階４２６へ分岐する。
【０１０３】
こうして、従来技術においては、供給業者、３ＰＬ、運送業者、および、顧客により別々に行われていた工程を中央集中化することにより、調達モジュールによって、供給業者と顧客との間において、従来技術のサプライチェーンよりも能率的に製品を移送することが可能となる。さらに、顧客による出荷および返品の問題についてもまた、より迅速かつ能率的に処理される。
【０１０４】
《Ｖ．注文処理（Fulfillment）》
注文処理モジュール（Fulfillment Module）は、供給業者７６から顧客７２への製品の輸送の保証に関係する。図１６を参照すると、本発明による、タイムフェーズ型（time-phased）注文処理モジュールの流れ図が示されている。情報の流れの大部分については、計画モジュール、注文管理モジュール、および、調達モジュールを参照して詳細に説明してきたので、このような女医右方についての詳細な説明は、簡潔のために省略する。
【０１０５】
注文処理モジュールにおいて、サプライチェーンサーバー７４は、顧客の予測２００および第０週の毎日のコールアウト（図４）を、供給業者７６へ送る。供給業者７６は、需要された製品に関する積み込み指示５００を、３ＰＬ７８へ送る。次に、供給業者７６は、５０２において、製品を準備し、かつ、ＡＳＮ（図１０Ａ）をサプライチェーンサーバー７４へ送る。その後すぐに、３ＰＬ７８は、発送通知５０４を運送業者９６へ送る。サプライチェーンサーバー７４は、配達問題３３６，３４０，３４２（図１０Ａおよび図１０Ｂ）を解決し、その一方で、運送業者９６は、５０６において、適切な製品を積み込むための発送用輸送手段（dispatch vehicles）を、供給業者７６へ送る。発送用輸送手段が製品を得ると、出荷品積み込み通知５２４が、サプライチェーンサーバー７４へ送られる。
【０１０６】
前記発送用輸送手段は、指定されたクロスドック位置（この場合には、３ＰＬがクロスドック位置として用いられるが、より詳細に後述するように、他の場所を利用できることも明らかである）へ移動し、かつ、クロスドック指示の到着を待つ。サプライチェーンサーバー７４は、３４６（図１１）において、クロスドック指示を生成し、かつ、３ＰＬ７８へ送る。発送用輸送手段がクロスドック位置に到着すると、到着通知５０８がサプライチェーンサーバー７４へ送られる。この地点で、５１０において、クロスドックが実行される。
【０１０７】
従来技術のサプライチェーンとは異なり、サプライチェーンネットワーク７０において、同じまたは類似の部品を注文する複数の顧客７２の注文は、供給業者７６から調達すべき大規模な注文の形に、一緒にグループ化される。次に、供給業者７６は、これらの部品に関して、３ＰＬ７８を通して、より大規模な注文を、はるかに少数だけ出荷する。従来技術においては、供給業者７６は、各々の注文を個々に処理し、かつ、各々の注文を個々のボックスの形で出荷していた。多くの顧客に関する全ての注文および部品を管理することの重大さが要求されていたので、このやり方は、非常にコストがかかっていた。
【０１０８】
本発明においては、サプライチェーンサーバー７４は、供給業者７６からのより大規模な注文を積み込むように、これらの注文をクロスドック地点へ運ぶように、次に、荷を降ろしかつこれらの製品を顧客７２へ副次的出荷（sub-ship）するように、３ＰＬ７８に指示する。クロスドック地点については、顧客への出荷の能率を最大にすべく、効果的に配置することができる。クロスドック地点自体においては、到着した製品に対する自動化された検査、受理などがある。出荷品のエラーは、通常的には、クロスドック地点５１０において修正される。
【０１０９】
製品自体に関して、これらの製品が供給業者７６のドックを出たときに、サプライチェーンサーバー７４のオペレータは、顧客７２のためのタイトル（title）を得る。タイトルは、製品が顧客７２に到着したときに、該顧客へ移送される。サプライチェーンサーバー７４のオペレータは、記録のインポータ（importer）としても作用する。
【０１１０】
再び、図１６を参照すると、クロスドック５１０がクロスドック地点（この場合には、３ＰＬ７８）において実行された後に、製品の積み込みを要求する発送通知５１２が運送業者９６へ送られ、かつ、出荷通知２６２（図１７を参照して後述する）が、サプライチェーンサーバー７４へ送られる。次に、製品は、運送業者９６により積み込まれ、かつ、適切な顧客７２へ輸送される。顧客７２は、所望の積み込みまたは配達場所を要求することができる。製品が輸送されている一方で、サプライチェーンサーバー７４は、ＡＳＮ（図１０Ａ）を顧客７２へ送る。３ＰＬ７８は、必要に応じて、税関到着（custom in）通知５１４および税関出発（custom out）通知５１６を、サプライチェーンサーバー７４へ送ることもできる。このような情報は、顧客７２にとって利用可能となる。製品が顧客７２へ配達された後に、運送業者９６は、配達証明通知ＰＯＤ５１８を３ＰＬ７８へ送る。３ＰＬ７８は、ＰＯＤ５１８を、サプライチェーンサーバー７４へ転送する。
【０１１１】
その後に、顧客７２は支払い２９８（図４）をサプライチェーンサーバー７４へ送り、かつ、サプライチェーンサーバー７４は、支払い２９８の金額から管理料金を差し引いた金額を、供給業者７６と３ＰＬ７８と運送業者９６とに転送する。次に、３ＰＬ７８は、支払い調停通知（payment reconciliation notification）２５０をサプライチェーンサーバー７４へ送る。何らかの払い戻し（refund）が必要であれば、３ＰＬ７８は、５２２において、このような払い戻しをサプライチェーンサーバー７４へ送る。次に、サプライチェーンサーバー７４は、払い戻し５２２を顧客７２へ転送する。
【０１１２】
さらに、前記サプライチェーンサーバー７４を用いる顧客７２は、注文処理工程全体にわたって注文状態を追跡する能力を有する。この注文追跡能力については、後述するエクストラネットを介して、サプライチェーンサーバー７４を用いる全ての顧客７２へ提供することができる。
【０１１３】
こうして、より大規模な注文をより少ない数だけ供給業者に提供することにより、また、大規模な注文をクロスドック地点において分類することにより、従来技術よりも低コストでありかつ能率的な注文処理工程が利用可能となる。さらに、顧客、供給業者、および、３ＰＬの全てに、中央集中型サプライチェーンサーバーに対して報告を行わせることにより、全ての当事者が、出荷工程に関する最新の情報を受け取ることができる。一実施形態において、このような情報は、サプライチェーンサーバーが配した情報とともに、ウェブサイト上で容易に利用可能となる。
【０１１４】
《VI．課金および支払い（Billing and Payment）》
いったん、顧客の需要が注文処理されると、課金および支払いモジュール（Billing and Payment Module）は、課金や顧客の支払い処理のような金融取引の実行において用いられる規則および活動を定義する責任を有する。課金および支払いモジュールに関するさらなる提案は、サプライチェーンネットワークの顧客が、未処理の注文の状態を検討しかつ製品を受け取る時までこの注文の状態を追跡することを可能にすることである。
【０１１５】
概して、顧客の需要が注文処理され、かつ、３ＰＬ７８からの出荷通知が受け取られた後に、サプライチェーンサーバー７４は、販売注文の生成を誘発する。同時に、予想された顧客の出荷と実際の顧客の出荷との間の偏差を判断するために、出荷通知が検討される。この工程は、輸送中、または、３ＰＬ設備のいずれかにおいて製品に対して行われた出荷不足または損傷を識別するのに役立つ。
【０１１６】
顧客は、サプライチェーンネットワーク７０を介して、供給業者７６から幾つかの出荷品を所定日に受け取ることができる。しかしながら、顧客は、これらの出荷品を１つの請求書に整理統合する送り状を、１日につき１つ受け取ることが好ましい。サプライチェーンサーバー７４と顧客７２との間の全ての金融取引については、好ましい実施形態において、ＥＦＴ（電子資金移動）を用いて実行することができ、これにより、全体的なサイクル時間がさらに短縮される。
【０１１７】
図１７および図１８を参照すると、課金および支払いモジュールは、サプライチェーンサーバー７４が、２０６において、製品が顧客７２へ配達されたことを示す出荷通知２６２を３ＰＬ７８から受け取ることによって開始される。領収書２０６については、ＥＤＩを通したものであってもよい。サプライチェーンサーバー７４は、２６４において、出荷通知２６２を有効化し、かつ、２６６において、出荷品の注文価格を計算する。有効化２６４において、サプライチェーンサーバー７４は、出荷通知２６２における総数量を、供給計画３３８（図１１を参照）により指定された数量と比較する。この比較は、顧客の部品番号につき２つ以上の出荷通知を含むことができ、かつ、予め規定された許容範囲を考慮に入れる。サプライチェーンサーバー７４が、２７０において、出荷通知２６２が有効であると判断すれば、有効化２６４は終了する。そうでない場合には、図１０Ｂを参照して前述したエラールーチン３４２のようなエラールーチン２７２が実行される。エラーが発生した場合には、このことは、データの完全性（出荷通知の正確さ）の問題、または、３ＰＬのパフォーマンス（３ＰＬ設備または運送中における材料の損失または損傷）の問題を示している。いずれの場合においても、エラールーチン２７２において出荷過剰および出荷不足の両方の解決法を実施するために、プランナーの介入が利用される。
【０１１８】
注文価格計算回路２６６において、出荷通知２６２と関連した注文の価格は、クロスドック指示３４６（図１６）と、供給業者７６と顧客７２との間における契約２７６と、出荷された実際の製品２７８とに基づいて計算される。このコストは、購入された部品の数と、供給業者７６と協議された価格とに基づくものである。基本管理料金に含まれていないサービスに対しては、さらなるコストが追加される。これらのサービスは、緊急の配達、特殊なラベリング、または、パッケージングなどを含む。最終的に、アドホックな注文には、追加料金を与えることができる。
【０１１９】
製品自体の料金に加えて、前記サプライチェーンサーバー７４は、さらに２８０において、標準的な貨物運送料金を有する貨物運送料金表に基づいて、製品の出荷と関連した貨物運送料金を計算する。概して、貨物運送料金は、出荷品の重量や個数、および、貨物運送形式（例えば、パレット運搬、小包など）に基づいている。顧客の預金口座に対して調節を行うために、３ＰＬ７８による調停（reconciliation）に基づいて、調停を定期的に利用することができる。従来技術の中にはあまりにも早急に販売注文を生成するものもあったので、販売注文の後に貨物運送料金を適用する必要があった。明らかなように、このような問題は、本発明のアーキテクチャにおいては存在しない。
【０１２０】
次に、前記サプライチェーンサーバー７４は、２８４において、適切な料金表２８６を用いて、販売注文の総計を計算する。これらの表は、関税と為替レートとを計算するために用いられる。付加価値税および売上税の他に、保険料も追加される。次に、サプライチェーンサーバー７４は、２８８において、販売注文２９０を生成する。好ましい実施形態において、１つの販売注文は、顧客の部品番号につき生成され、かつ、料金は、例えば、貨物運送、税、追加サービスなどのように、項目別に記入される。
【０１２１】
以下において、さらに、図１８を参照すると、前記サプライチェーンサーバー７４は、次に、段階２９２，２９４へ進行して、販売注文２９０に関する送り状２９６を作成し（段階２９２）、かつ、顧客７２へ送る（段階２９４）。送り状の作成段階２９２は、各々の販売注文に対する要求額（terms）について略述している電子送り状を用いて、各々の注文に対して自動的に実行される。支払い要求額は、出荷日に基づいており、かつ、前述したような項目別に記入された料金を含む。２９４での送り状２９６の送付に関して、同じ顧客に対する全ての送り状が、毎日整理統合されるので、顧客は、１日につき１つの送り状を受け取る。これにより、２９４での送付によって、受取勘定（receivable）が作成される。
【０１２２】
その後のある時点において、顧客７２は、好ましくは、電子資金移動（ＥＦＴ）を通して、サプライチェーンサーバー７４へ支払い２９８を送る。サプライチェーンサーバー７４は、３００において、支払い２９８を受け取ろうとする。契約上で規定された期間内に支払い２９８が受け取られなければ、エラールーチン３０４が実行され、この場合に、サプライチェーンサーバー７４は、顧客または対応する銀行のいずれかと連絡を取る。規定された期間内に支払い２９８が受け取られれば、支払い２９８は、３０２において処理されて、これにより、到着した支払いは、未決算の送り状とマッチングされる。支払い２９８を送った顧客の預金口座は、他の未払いの送り状（貸方記入および借方記入の差額）に関して再検討され、かつ、支払い２９８が、顧客の預金口座に対して適用される。最終的に、３０６において、サプライチェーンサーバー７４は、所定の送り状２９６に対して、顧客７２が十分な支払いを行ったのか、または、必要以上に支払ったのかを判断する。支払い２９８に問題がなければ、送り状のルーチンは終了する。そうでない場合には、エラールーチン３０８が実行され、この場合には、過去の顧客履歴に基づいて集金工程が開始されるか、または、必要以上に支払った場合には顧客の預金口座に対して貸方記入が適用される。複数の供給業者７６が顧客７２のために部品を提供していた可能性があるので、支払い２９８は、複数の供給業者７６に関連している可能性がある。この場合には、支払い２９８を分類し、これに応じて、供給業者７６に分配しなければならない可能性がある。こうして、サプライチェーンサーバー７４の形でのサプライチェーンネットワーク７０の制御の中央集中化によって、供給業者が、顧客に対する課金処理の管理にかかるコストを回避することが可能となる。
【０１２３】
《VII．情報管理》
前記サプライチェーンサーバー７４は、サプライチェーンネットワークの参加者へ提供できる貴重なデータを蓄積する。好ましい実施形態において、情報配信能力は、主として、安全なエクストラネットにより実施される。能率的なサプライチェーンネットワークはリアルタイム情報のアクセス可能性（accessibility）および可視性（visibility）の両方を組み込むので、情報配信は、サプライチェーンサーバー７４のビジネスモデルにとって非常に有用である。
【０１２４】
情報配信は、定期定期に発生する離散的（discrete）工程というよりは、サプライチェーンサーバー７４とそのビジネスパートナーとの間における本質的に連続的な（例えば、１日２４時間、週７日）連絡を可能にする能力である。さらに、情報配信能力は、顧客（および、潜在的な供給業者や３ＰＬ）がワークフロー工程を開始する手段を提供する。例えば、顧客が注文を中止する能力に関する工程は計画モジュールに配置されているが、情報配信が、中止コードの伝達を処理する（例えば、ワークフロー工程を開始するための電子メールまたはＥＤＩメッセージを誘発するエクストラネット上のボタン）。図１９は、サプライチェーンネットワーク７０のユーザーへ提供することができる情報を示している。情報配信工程によって、サプライチェーンネットワークの参加者の必要に応じて、非常に適時的な様式で情報を配信することが可能となる。
【０１２５】
明らかなように、顧客、供給業者、および、３ＰＬにとって利用可能な情報の形式は、注文固有（order-specific）情報／統計と、顧客固有（customer-specific）統計（例えば、日付までの一週間（Week-to-date）、日付までの一ヶ月間（Month-to-date）、日付までの一年間（Year-to-date））とを含むが、これらの制限されるものではない。
【０１２６】
《VIII．融資（Financing）》
前記サプライチェーンネットワーク７０の構成は、さらに、必ずしも必要ではないが、製品を調達する顧客に対して新たな形式の融資（financing）を提供することも可能にする。前述したように、従来技術の融資形式においては、供給業者は顧客に支払い期間を与えていたが、顧客はこの期間を頻繁に無視していた。したがって、供給業者は、消費者が期限通りに支払いを行わないことに起因して見込まれる損害に対して、製品の価格を上昇させていた（事実上の利息）。さらに、販売者は、自分たちのバランスシートを改善するために製品を早期に販売したい場合には、卸売業者からの不合理な価格づけの言いなりになっていた。
【０１２７】
本発明は、（従来技術における単なる供給業者および顧客だけではなく）三者の当事者のアーキテクチャを提供することにおいて、事実上の利息と、従来技術における卸売業者とを廃する。最初に、図２０を参照すると、サプライチェーンネットワーク７０におけるタイトルおよび支払いの流れの例が示されている。注文処理モジュールの説明において前述したように、サプライチェーンサーバー７４のオペレータは、いったん、製品２７８が供給業者７６から出ると、該製品２７８のタイトルを得る。製品２７８は、クロスドック５１０へ移動し、次に、顧客７２へ移動する。顧客７２は、５３６において、製品を使用し、かつ、支払い５３８を（例えば、クロスドック地点における）サプライチェーンサーバー７４へ送る。サプライチェーンサーバー７４は、５４０において、支払い５３８を受け取り、かつ、供給業者７６へ送る。供給業者７６は、支払い５３８を受け取り、かつ、５４２において、支払いを自分の銀行へ預金する。
【０１２８】
図２１には、融資の代替的形式が示されている。図２０に示される流れの場合のように、製品２７８は、クロスドック５１０へ送られる。この時点で、顧客の送り状５３２のコピーが、顧客の送り状の支払いの担保（collateral）として、金融業者または銀行３９２へ送られる。銀行３９２は、顧客の送り状のために必要な融資金５３４を調達し、かつ、５４０において、この融資金をサプライチェーンサーバー７４へ返送する。次に、サプライチェーンサーバー７４は、融資金５３４を供給業者７６へ転送し、次に、供給業者７６は、５４２において、融資金５３４を自分の銀行へ預金する。したがって、供給業者７６には、製品２７８が出荷された直後に支払いが行われる。銀行３９２は、供給業者７６に支払いを行うために必要な融資金を、顧客７２に対して効率的に貸し付けを行い、かつ、サプライチェーンサーバー７４は、この顧客の債務（obligation）を保証する。顧客７２は、５３６において、製品２７８の使用し続け、次に、支払い５３８を生じさせ、この支払いは、今や直接的に、銀行へ送られる。銀行３９２は、５４４において、支払い５３８を預金し、かつ、５４６において、支払い済みとして印を付けられた送り状５３２を顧客７２へ返送し、かつ、送り状５３２に支払いが行われたことを示す通知５４８をサプライチェーンサーバー７４へ送る。
【０１２９】
こうして、いったん、製品２７８が配達されると、たとえ、サプライチェーンサーバー７４が顧客７２の代わりに債務を保証していても、該顧客７２は、なおも、その記録上に支払勘定（payable）を有する。支払勘定自体は、実際には、サプライチェーンサーバー７４または銀行３９２に対するものであって、供給業者７６に対するものではない。このような支払勘定のスケジュールは、例示的信用状態（exemplary credit）によって顧客に対して拡張される。さらに、顧客が期限通りに支払いを行わなければ、サプライチェーンサーバー７４は、顧客への部品の流れを差し控える選択権を有し、これにより、顧客７２には、大きな犠牲が生じる。供給業者７６は、支払いを早期にかつ規則正しく受け取るという点で利益を得る。サプライチェーンサーバー７４は期限通りに供給業者７６へ支払いを行うので、供給業者７６は、もはや、事実上の利息を請求する必要がない。このコストの節約は、顧客７２にもたらされ、かつ、サプライチェーンサーバー７４のオペレータの収益として実現される。
【０１３０】
供給業者７６が、顧客７２を満足させるのの必要な時期の前に製品２７８を出荷したいと望む場合には、サプライチェーンサーバー７４は、顧客７２の予想２００に基づいて、これらの製品の幾つかを安全に保持することができ、かつ、従来技術の卸売業者が請求するよりも低い金利を、供給業者７６に対して請求することができる。
【０１３１】
前述した技術を用いて、サプライチェーンサーバー７４は、より好ましい価格をレバレッジ（leverage）するために、または、関係する当事者のためにより魅力的なバランスシートを作成するために、支払い期間（payment term）による融資の取り決めを行うことができる。例えば、供給業者には、従来技術のサプライチェーンにおいてよりも早期に支払いを行うことができるので、供給業者は、より好意的に、価格の譲歩と融資コストの引き下げとに関して考慮するようになる。サプライチェーンサーバー７４は、棚卸資産をバランスシートと頭書（premises）とから外すことを可能にする融資を取り決めることができる。
【０１３２】
さらに、前記サプライチェーンサーバー７４は、商品の価格変更のリスクを、よりリスクを有する傾向がある（risk-inclined）当事者へシフトすることもできる。例えば、揮発性商品（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ））において、製品および現金の流れを制御することにより、前記サーバー７４は、ヘッジ（hedges）、コール（calls）、プット（put）などのようなリスクシフト（risk-shifting）製品を提供することもできる。従来技術のサプライチェーンにおいては、製品および現金を制御する当事者が存在しなかったので、このような製品を提供することができなかった。
【０１３３】
さらに、前記サーバー７４は、従来技術において利用可能ではなかった保険を提供することもできる。サーバー７４は、多数の顧客および供給業者と接続されているので、製品の需要または供給における変動が激しい情勢（swings）に対して計画を立てることができる。例えば、サーバー７４は、供給業者７６から臨時の製品を受け取ることができ、かつ、これらの製品を、顧客の需要が不測的に増大した場合に備えて保持することができる。サーバー７４が受け取る臨時の製品は、以前の予測に基づいて、保険計理人による計算（actuarial calculations）により決定される。これらの臨時の製品は定期的に更新され、これにより、これらの製品については、新しいままとなり、古くなることはない。こうして、サーバー７４は、需要の急騰や供給不足に対して保険をかける。
【０１３４】
こうして、前記サプライチェーンサーバー７４による提供によって、サプライチェーンネットワークの当事者が、従来技術において利用可能ではなかった融資オプションを利用することが可能となる。さらに、供給業者は、事実上の利息がもはや不必要であるので、製品をより安価で提供することができる。
【０１３５】
《IX．アーキテクチャ》
前記サプライチェーンネットワーク７０については、多くの方法で設定することができる。概略的なアーキテクチャの設定が、図２２に示されている。サプライチェーンサーバー７４は、顧客７２、供給業者７６、３ＰＬ７８、銀行３９２、および、運送業者９６の全てに連結されて示されている。この接続については、例えば、インターネットにようなネットワーク５６０を通したものであってもよい。
【０１３６】
前記ネットワーク５６０が用いられれば、図２２に示される当事者間の連絡については、ダイヤルアップのシリアル回線インターフェースプロトコル／ポイントツーポイントプロトコル（“ＳＬＩＰ／ＰＰＰ”）、統合サービスディジタル網（“ＩＳＤＮ”）、専用回線サービス、ブロードバンド（ケーブル）アクセス、デジタル加入者回線（“ＤＳＬ”）、非同期転送モード（“ＡＴＭ”）、または、他のアクセス技術のような、通信サーバーにアクセスするための任意の既知の取り決めを通したものであってもよい。サプライチェーンサーバー７４は、図２２の当事者のうちの１つによりアクセスされるウェブページをホストするために用いられる場合には、ウェブページのＨＴＭＬおよび／またはＪａｖａ（登録商標）データを提供することができる。サプライチェーンサーバー７４は、このようなハードウェア要素に制限されるものではない。
【０１３７】
前記サプライチェーンサーバー７４自体については、多くの公知のハードウェア構成を用いて実施することができる。最も概略的な意味で、サプライチェーンサーバー７４については、図２３に示されるような構成を用いて実施することができる。ＣＰＵ５６２は、ＲＯＭ５６４とＲＡＭ５６６と記憶装置５６８とサーバー装置５７０と入力装置５７２とに、バス５７４を通して連結されている。再び述べると、サプライチェーンサーバー７４は、これらの構成に制限されるものではない。
【０１３８】
図２４を参照すると、サプライチェーンサーバー７４に関する、より詳細なアーキテクチャが示されている。サプライチェーンサーバー７４は、エクストラネットマネージャ５８０と、ＥＲＰシステム５８４と、プランナー支援ツール５８６と、メッセージングサービスセクション５８８とを有し、これらは、全てシステムモニター５８２に連結されている。システムモニター５８２は、サーバー７４の全ての構成要素の作業工程を監視し、かつ、これらの構成要素間における情報の流れを促進する。図２４に示されるように、顧客７２および供給業者７６は、ファイアウォール５９０を通して、エクストラネットマネージャ５８０と連絡を取ることができる。顧客７２、供給業者７６、３ＰＬ７８、および、銀行３９２は、全て、やはりファイアウォール５９０を通して、サプライチェーンサーバー７４のメッセージングサービスセクション５８８と連絡を取る。
【０１３９】
前記エクストラネットマネージャ５８０は、顧客７２および供給業者７６に、注文および予測情報へのアクセスと、サプライチェーンサーバー７４と契約された任意のプレミアム情報サービスへのアクセスと、顧客の書誌的情報（bibliographic information）（例えば、氏名、住所、預金口座番号など）である顧客マスターデータへのアクセスとを提供する。エクストラネットマネージャ５８０は、ウェブページを表示することにより、かつ、後述するＥＲＰシステム５８４から受け取った情報を有する新たなウェブページを生成するすることにより、この機能を実行する。最終的に、エクストラネットマネージャ５８０は、サイトのメンバーシップとセキュリティとを管理し、かつ、サーバー７４から／への安全なデータ通信を提供する。
【０１４０】
前記ＥＲＰ（企業資源計画）システム５８４は、サーバー７４に、融資、注文管理、需要管理、調達、および、他の企業処理能力に関するアプリケーションおよびシステムサポートを提供する。ＥＲＰシステム５８４は、供給業者７６、顧客７２，ロジスティクスプロバイダ７８、および、金融機関（financial institutions）３９２（“パートナー”）からのデータの合併を可能にし、かつ、これらのパートナーからのデータを標準的なフォーマットの形で貯蔵しかつ管理する。さらに、ＥＲＰシステム５８４は、サーバー７４の従業員に、企業情報へのリアルタイムアクセスを提供し、かつ、ビジネス処理の完了を保証するためのワークフロー能力を提供する。最終的に、ＥＲＰシステム５８４は、顧客マスターデータを追跡する。
【０１４１】
前記メッセージングサービスセクション５８８は、サプライチェーンサーバー７４とその全てのパートナーとの間の連絡を合理化する。メッセージングサービスセクション５８８は、全ての受け取られた情報を、ＥＲＰシステム５８４へ入力される標準的なフォーマットの形に変換する。逆に、メッセージングサービスセクション５８８は、ＥＲＰシステム５８４から情報を受け取り、かつ、発信メッセージを特定の顧客が期待するフォーマットの形で生成する。メッセージングサービスセクション５８８は、サーバー７４とそのパートナーとの間の安全なデータ伝送を管理し、全ての伝送に関してインターネットの利用を可能にし、かつ、会計検査目的のために、全ての伝送のロギング（logging）およびシリアライゼーション（serialization）を提供する。
【０１４２】
前記プランナー支援ツール５８６によって、サーバー７４のために働くプランナーが、予測、需要、および供給データを操作することが可能になる。プランナー支援ツール５８６は、ＥＲＰシステム５８４から抽出されたデータを集計し、これにより、柔軟な、構成可能な（configurable）分析方法を促進し、かつ、広範囲の報告能力を提供し、分析工程における例外的条件の定義を提供し、例外が発生した場合の作用過程（ワークフロー）を提供し、データへの安全なアクセスを提供し、かつ、このデータの完全性を維持しながら、このデータに対する多数のユーザーによるアクセスを可能にする。エクストラネット５８０の外部に配し、ＥＲＰシステム５８４と協働させ、かつ、メッセージングサービスセクション５８８に連結するようにプランナー支援ツールを設けることにより、所望の供給−需要のバランスを達成することができる。
【０１４３】
《Ｘ．要約》
こうして、以前に従来技術においては個々のエンティティが行っていた多数の工程を処理するためにサプライチェーンサーバーを提供することにより、より能率的でありかつコストを最小限にするアーキテクチャが実現される。購入およびサプライチェーンの管理を整理統合することにより、サプライチェーンサーバーは、従来技術のサプライチェーンの顧客および供給業者が費やしていた多くの段階およびコストを不要にする。顧客は、価格の低下と、貨物輸送や購買やシステムプランニングなどに対する支出の低下と、配達の迅速化および信頼性の向上と、リードタイムの短縮および棚卸資産の減少と、サプライチェーン管理の節約と、関税および税金の低下と、製品に関する専門的技術と、サプライチェーンの完全な可視性と、データの完全性の向上と、収益の向上と、自分たちの顧客へのサービスの向上と、供給業者の質の向上と、意思決定の向上とを高く評価する。供給業者は、販売費用の低下と、計画コストの低下と、棚卸資産の減少と、配達の向上と、製品コストの低下と、需要の可視性と、運用費用の低下と、より円滑な製品の流れによる製造コストの低下とにおいて利益を得る。これらのことは、全て、販売価格を低下させる一方で収益性の向上につながり、これにより、需要が増大する。顧客および供給業者の両方は、サプライチェーンサーバーがホストする安全なウェブサイトへのアクセスを有することができ、該ウェブサイトは、従来技術において利用可能ではなかった貴重な情報を提供する。この情報は、顧客の購買習慣と、供給される市場の規模および成長率とを含む。顧客の購買パターンについて詳述する履歴データが発展するにつれて、他のサプライチェーンネットワークへ転換することは、より不経済となる。
【０１４４】
サプライチェーンサーバーのコストについては、部品番号の数と、累積的な購買値とに基づいて、顧客が生じさせる。供給業者には、考えられる限りの最も低い価格を提供させるような形で料金を負担させる必要が無くなる。サプライチェーンネットワークは、製品を大量に調達するので、これらの品目に対してより低いコストを受け取り、かつ、この低いコストを収益の形に具体化する。
【０１４５】
製品の需要および供給について説明してきたが、サービスを含む任意のリソースの需要および供給もまた、本発明の範囲内にあることは明らかである。したがって、本明細書全体にわたって、“製品”という語は、このような任意のリソースまたはサービスを指す。例えば、顧客は、ネットワーク内の幹線上の帯域幅を所望する個人であり得る。また、供給業者は、ネットワークの帯域幅のソースであり得る。さらに、顧客は、例えば、対応する供給業者から航空券または劇場の座席を所望する個人であり得る。
【０１４６】
本発明に関する好ましい実施形態について開示してきたが、その一方で、本明細書に開示されている原理を実行する種々の様式が、冒頭の請求項の範囲内にあるものとして予想される。したがって、本発明の範囲は、前記請求項に提示されている内容以外により制限されるべきではないことが理解される。
【図面の簡単な説明】
【図１】従来技術によるサプライチェーンアーキテクチャを示すブロック図である。
【図２】本発明によるサプライチェーンネットワークを示すブロック図である。
【図３】図２のサプライチェーンネットワークを実施するモジュールを示すブロック図である。
【図４】本発明による、規則的な需要要求中において、注文管理モジュールにより実行される需要捕捉および有効化工程を示す図である。
【図５】アドホックな需要要求中において、注文管理モジュールにより実行される需要捕捉および有効化工程を示す図である。
【図６】本発明による、計画モジュールにより実行される工程を示す図である。
【図７】図６の計画モジュール中における情報の流れの例を示す図である。
【図８】顧客の需要が供給業の生産能力を超過した場合に、図６の計画モジュール中において実行される工程を示す図である。
【図９】アドホックな顧客の要求を受けたことに基づいた、図６の計画モジュール中における情報の流れの例を示す図である。
【図１０Ａ】本発明による、調達モジュールの工程を示す図である。
【図１０Ｂ】図１０Ａの調達モジュールにおいて実行されるエラールーチンを示す図である。
【図１１】図１０Ａの調達モジュールにおいて実行される工程の続きを示す図である。
【図１２】図１０Ａおよび図１１の調達モジュールにおいて実行される工程の続きを示す図である。
【図１３】図１０Ａ、図１１、および、図１２の調達モジュールにおいて実行される工程の続きを示す図である。
【図１４】顧客がサプライチェーンネットワークを通して生産された品目を返品したいと希望した場合に、調達モジュールにより実行される工程を示す図である。
【図１５】図１４に示された工程の続きを示す図である。
【図１６】本発明による、注文処理モジュール中における情報および製品の流れを示す図である。
【図１７】本発明による、課金および支払いモジュールにより実行される送り状の生成を示す図である。
【図１８】課金および支払いモジュール中における送り状の支払いを示す図である。
【図１９】本発明による、サプライチェーンネットワークにより提供される情報およびこれに対応する時間間隔の形式を示す図である。
【図２０】本発明の実施形態による、製品に関するタイトルおよび支払いの流れを示す図である。
【図２１】本発明の他の実施形態による、製品に関するタイトルおよび支払いの代替的な流れを示す図である。
【図２２】本発明によるサプライチェーンアーキテクチャのためのアーキテクチャ設定の実施形態を示す図である。
【図２３】本発明によるサプライチェーンサーバーの実施形態を示す図である。
【図２４】図２３に示されたサプライチェーンサーバーのためのサプライチェーンサーバー環境をより詳細に示す図である。
【符号の説明】
７０サプライチェーンネットワーク
７２顧客
７４サプライチェーンサーバー
７６供給業者
７８ロジスティクスプロバイダ
９６運送業者
３９２銀行
５８０エクストラネットマネージャ５８０
５８２システムモニター
５８４ＥＲＰシステム
５８６プランナー支援ツール
５８８メッセージングサービスセクション
５９０ファイアウォール

Claims

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