(57)【要約】【課題】原材料の在庫の低減と効率的な安定運用を実現する。【解決手段】原材料供給サブシステムと、副生産サブシステムと、主生産サブシステムと、中央管理サブシステムとを備えた原材料調達システムにおいて、前記中央管理サブシステムは、前記原材料供給サブシステムからの原材料の供給および、その原材料の供給を受けて副生産サブシステムで行われる中間部品の生産に基づいて動的に変動する副生産サブシステムにおける原材料の在庫量を管理する中央管理サーバ部を備え、前記副生産サブシステムは、当該原材料の在庫量を取得して中央管理サーバ部へ伝える在庫量取得部を備える。【選択図】  図１
2004318611.tif 000002
【特許請求の範囲】
【請求項１】
所定の原材料の供給元となる１または複数の原材料供給サブシステムと、当該原材料供給サブシステムから原材料の供給を受け、当該原材料をもとに中間部品を生産する１または複数の副生産サブシステムと、当該副生産サブシステムから中間部品の供給を受け、当該中間部品をもとに所定の最終部品の生産を行う主生産サブシステムと、前記原材料の調達に関連する各種情報の管理を行うと共に、前記原材料供給サブシステムとの間で原材料の調達に関連する情報の通信を行う中央管理サブシステムとを備えた原材料調達システムにおいて、
前記中央管理サブシステムは、
前記原材料供給サブシステムからの原材料の供給および、その原材料の供給を受けて前記副生産サブシステムで行われる中間部品の生産に基づいて動的に変動する副生産サブシステムにおける原材料の在庫量を管理する中央管理サーバ部を備え、
前記副生産サブシステムは、
当該原材料の在庫量を取得して中央管理サーバ部へ伝える在庫量取得部を備えたことを特徴とする原材料調達システム。
【請求項２】
請求項１の原材料調達システムにおいて、
前記副生産サブシステムが主生産サブシステムから中間部品生産依頼を受けたときに、当該中間部品生産依頼に基づいて中間部品の生産を行う場合、前記主生産サブシステムが将来の発注に関する予測量を原材料供給サブシステムに伝え、当該原材料供給サブシステムは、この予測量と、前記中央管理サーバ部から得た在庫量をもとに、前記原材料の生産量を制御することを特徴とする原材料調達システム。
【請求項３】
請求項１の原材料調達システムにおいて、
前記中央管理サーバ部は、
前記原材料供給サブシステムにおける原材料の在庫量を取得して管理することを特徴とする原材料調達システム。
【請求項４】
請求項１の原材料調達システムにおいて、
前記中央管理サーバ部は、
前記副生産サブシステムの原材料の在庫量に関して所定の上限在庫量を設定し、当該副生産サブシステムから中央管理サーバ部経由で行われる原材料供給サブシステムに対する原材料の発注量が、その時点の当該副生産サブシステムにおける原材料の在庫量に加算されると上限在庫量を越えるか否かを判定する発注量判定部を備え、
当該発注量判定部が、前記上限在庫量を越えると判定した場合、当該中央管理サーバ部は、当該副生産サブシステムから原材料供給サブシステムへの発注情報の中継を拒否することを特徴とする原材料調達システム。
【請求項５】
請求項１の原材料調達システムにおいて、
前記中央管理サーバ部は、
当該中央管理サーバ部が、前記副生産サブシステムから送信された発注情報を原材料供給サブシステムに中継し、当該原材料供給サブシステムにおいてその受付けが行われたあと、該当する原材料の副生産サブシステムに対する供給が完了するまでの間に発注情報の変更を許容する場合、その副生産サブシステムと原材料供給サブシステムのあいだで発注情報の変更に関するネゴシエーションを促進し、当該ネゴシエーションを介して原材料供給サブシステムから変更の承認が得られた場合に発注情報の変更を許可するネゴシエーション促進部を備えたことを特徴とする原材料調達システム。
【請求項６】
請求項１の原材料調達システムにおいて、
前記中央管理サーバ部は、
当該中央管理サーバ部が、前記副生産サブシステムから送信された発注情報を原材料供給サブシステムに中継し、当該原材料供給サブシステムにおいてその受付けが行われたあと、該当する原材料の副生産サブシステムに対する供給が完了するまでの間に発注情報の変更を許容する場合、予め原材料供給サブシステムから変更を許容する期限を示す変更期限情報を得ておき、当該副生産サブシステムが発注情報の変更を求めるために中央管理サーバ部にアクセスしてきたとき、当該変更期限情報に応じた処理を実行する変更期限対応部を備えたことを特徴とする原材料調達システム。
【請求項７】
請求項１の原材料調達システムにおいて、
前記中央管理サーバ部は、
当該中央管理サーバ部が、前記副生産サブシステムから送信された発注情報を原材料供給サブシステムに中継するとき、当該副生産サブシステムに対し発注情報中で指定される原材料の納期に関して時間的な幅の設定を要求する幅設定要求部を備えたことを特徴とする原材料調達システム。
【請求項８】
請求項７の原材料調達システムにおいて、
前記幅の限界を規定する２つの時間位置のうち、早いほうを納入開始時間位置、遅いほうを納入終了時間位置とし、納入の準備を開始してから納入を完了するまでの時間を納入リードタイムとすると、現在を基準として納入リードタイムに１単位時間を加えたタイミングとなる時間位置を、前記納入終了時間位置とするものの、その時間位置が、前記原材料供給サブシステムまたは副生産サブシステムが稼働していないタイミングである場合には、当該時間位置にもっとも近い未来であって、前記原材料供給サブシステムおよび副生産サブシステムが稼働しているタイミングを、納入終了時間位置とすることを特徴とする原材料調達システム。
【請求項９】
請求項１の原材料調達システムにおいて、
前記原材料がその特性上、前記原材料供給サブシステムから副生産サブシステムへの供給量に誤差の混入が避けられないものである場合、前記副生産サブシステムから発注した発注量を基準として、当該供給量に制限を設けることを特徴とする原材料調達システム。
【請求項１０】
請求項１の原材料調達システムにおいて、
前記中央管理サーバ部は、
前記原材料が、所定の供給単位ごとにまとめられ、供給単位ごとに管理用の表示手段を付与された状態で供給される場合、当該表示手段の表示内容を示す情報を、前記原材料供給サブシステムから取得する表示内容取得部と、
取得した表示内容に応じた画像情報であって、前記表示手段の表示内容を忠実に再現したものを、前記副生産サブシステムに配信する画像情報配信部とを備え、
前記副生産サブシステムでは、配信を受けた画像情報を用いて、前記表示手段の表示内容を再生することを特徴とする原材料調達システム。
【請求項１１】
請求項１の原材料調達システムにおいて、
前記原材料供給サブシステムは、
前記原材料の供給を実行する前に、供給に関する詳細な情報を供給予告情報として中央管理サーバ部へ送信する供給予告部を備え、
前記副生産サブシステムは、
前記原材料が、所定の供給単位ごとにまとめられ、供給単位ごとに管理用の表示手段を付与された状態で供給される場合、１つの発注に対応して供給単位が複数存在すると、各供給単位に付与された表示手段をもとに１つの発注に対応する供給単位を識別するとともに、前記供給予告情報をもとに当該発注に対応する供給単位の数を検査し、その検査結果に基づいて当該発注に対応する全供給単位の供給が完了したことを検出することを特徴とする原材料調達システム。
【請求項１２】
請求項１１の原材料調達システムにおいて、
前記副生産サブシステムは、
１つの発注に対応する全供給単位の供給が完了したことを検出したとき、前記発注量を基準として、前記供給量が所定の下限値を下回ったか否かを検査し、下回った場合には、その旨を中央管理サーバ部を介して原材料供給サブシステムに伝え、追加の供給を促すことを特徴とする原材料調達システム。
【請求項１３】
請求項１の原材料調達システムにおいて、
前記中央管理サーバ部は、
前記副生産サブシステムの内部における原材料の在庫量を表現するとき第１の表現単位を用い、当該原材料を原材料供給サブシステムから副生産サブシステムへ供給するときには、原材料の供給量を表現するために第２の表現単位を用いる場合、第１の表現単位を第２の表現単位に変換するための表現単位変換部を備えたことを特徴とする原材料調達システム。
【請求項１４】
請求項１の原材料調達システムにおいて、
前記中央管理サーバ部は、
所定の数の中間部品を生産するために消費される原材料の量をもとに、当該中間部品の数を対応する原材料の量に変換するための数量変換部と、
当該副生産サブシステムから主生産サブシステムへ渡された中間部品の数に基づいて、当該副生産サブシステムに残っている原材料の量を求め、その原材料の量をもとに当該副生産サブシステムの内部の生産工程で処理されている途中の原材料の量を求める生産中原材料量算出部とを備えたことを特徴とする原材料調達システム。
【請求項１５】
所定の原材料の供給元となる１または複数の原材料供給サブシステムと、当該原材料供給サブシステムから原材料の供給を受け、当該原材料をもとに中間部品を生産する１または複数の副生産サブシステムと、当該副生産サブシステムから中間部品の供給を受け、当該中間部品をもとに所定の最終部品の生産を行う主生産サブシステムと、前記原材料の調達に関連する各種情報の管理を行うと共に、前記原材料供給サブシステムとの間で原材料の調達に関連する情報の通信を行う中央管理サブシステムとを用いる原材料調達方法において、
前記中央管理サブシステムでは、
前記原材料供給サブシステムからの原材料の供給および、その原材料の供給を受けて前記副生産サブシステムで行われる中間部品の生産に基づいて動的に変動する副生産サブシステムにおける原材料の在庫量を、中央管理サーバ部が管理し、
前記副生産サブシステムでは、
在庫量取得部が、当該原材料の副生産サブシステムにおける在庫量を取得して中央管理サーバ部へ伝えることを特徴とする原材料調達方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は原材料調達システムおよび方法に関し、例えば、鋼材などの原材料を調達するためのＳＣＭ（サプライチェーンマネジメント）に適用して好適なものである。
【０００２】
【従来の技術】
従来、この種の調達システムは、図２に示すような構成を有する。
【０００３】
図２において、当該調達システム１０には、本社１１と、親工場１２と、協力企業１３と、サプライヤ１４が含まれている。
【０００４】
このうち本社１１内のホスト１１Ａは、専用回線１５でサプライヤシステム１４Ａと接続されている。
【０００５】
サプライヤシステム１４Ａを有するサプライヤ１４は、具体的には、商社や鉄鋼メーカなどであり、調達の対象となる鋼材の生産や、その物流管理などの機能を有し、協力企業１３へ鋼材の供給を行う。
【０００６】
これに対し、本社システム１１Ａを有する本社１１とは、鋼材の加工品であるベアリング、自動車部品、精機製品等の製造、販売メーカの本社を指し、親工場１２は、そのメーカの親工場であり、協力企業１３とは、親工場１２からの依頼に基づいて、ベアリング、自動車部品、精機製品等の構成要素となる部品の製造を行う企業である。この部品は、サプライヤから供給される鋼材を用いて製造されることになる。
【０００７】
調達システム１０全体の処理は、図２中に示したＳ１〜Ｓ１０の各ステップにしたがって進行する。
【０００８】
最初に、親工場１２が生産計画にしたがって協力企業１３に対し部品加工依頼を行って部品の加工を依頼するとともに（Ｓ１）、材料となる鋼材の調達計画も行い、本社１１の調達部門に発注依頼を行う（Ｓ２）。部品加工依頼は月単位で行われるので発注依頼も月単位で行われることになる。また、部品加工依頼には、協力企業１３が製造する部品の量が記載され、発注依頼には鋼材毎の発注量や納期が含まれている。また、部品加工依頼や発注依頼は、電話、ＦＡＸ、電子メール等を利用して行われている。
【０００９】
ステップＳ２の発注依頼を受けた本社１１の調達部門では、当該発注依頼をもとに各鋼材の発注量や納期をまとめ、ホスト１１Ａへ発注データとして登録する（Ｓ３）。ホスト１１Ａは前記専用回線１５を用いたＥＤＩで、その発注データをサプライヤシステム１４Ａへ伝え、サプライヤ１４がこれを受注する（Ｓ４）。
【００１０】
発注は月に一度、各サプライヤに対し一括して行われるため、一度の発注で多岐にわたる発注データが大量に送信されることになる。そして、これを受注したサプライヤ側では、在庫引き当てや出荷指示、物流手配等を行い、正式な納入量や納期を明記した伝票（納品伝票）をＦＡＸや郵送で本社１１に送る。
【００１１】
次に、当該納品伝票に記載された納入量や納期にしたがって、サプライヤ１４から各協力企業（例えば、１３）への鋼材の配達（供給）が行われる（Ｓ５）。実際の配達には、トラックなどの物流機能が利用される。鋼材が協力企業１３に届くと、協力企業１３の受入担当者は検品後、倉庫に運ぶ（Ｓ６）。
【００１２】
配達される鋼材は、複数の束（現品）から構成されており、それぞれの束には現品Ｎｏ等が記載された現品札が付加されているので、当該担当者は、この現品札の記載などをもとに検品を行うことになる。
【００１３】
協力企業１３が部品を製造するときには、倉庫から必要な量の鋼材を払い出し、払い出された鋼材に対して加工作業を施す。そしてこの加工作業によって製造された部品は、協力企業１３から親工場１２へ出荷されることになる（Ｓ１０）。
【００１４】
【発明が解決しようとする課題】
ところで、上述した調達システム１０では、協力企業１３の内部およびサプライヤ１４の内部で鋼材の在庫が発生するが、その在庫を十分に低減するとともに、システム１０全体として効率的な安定運用を行うことは難しい。
【００１５】
例えば、親工場１２では、協力企業１３の内部の在庫を正確に把握することは困難であるため、前記ステップＳ２の発注依頼の内容は、発注依頼の担当者の経験や勘によって決められているのが現状である。発注依頼に含まれる発注量が多すぎればサプライヤ１４から協力企業１３へ供給される鋼材の量が過多となり、協力企業１３は不必要に多い在庫をかかえることになる。また、これと反対に、発注量が過少となると、協力企業１３は鋼材不足のためにステップＳ１の部品加工依頼で依頼された量の部品を製造することができなくなってしまう。
【００１６】
また、月単位で部品加工依頼や発注依頼を出していたのでは、協力企業１３やサプライヤ１４の在庫量の変動幅が大きくなり、少なくとも一時的に過大な在庫量をかかえることを避けることが難しいので、月よりも短い時間を単位として部品加工依頼や発注依頼を出すことが望ましいが、前記調達システム１０では、それを実現することは困難である。
【００１７】
【課題を解決するための手段】
かかる課題を解決するために、第１の本発明では、所定の原材料の供給元となる１または複数の原材料供給サブシステム（例えば、サプライヤシステム３７など）と、当該原材料供給サブシステムから原材料の供給を受け、当該原材料をもとに中間部品を生産する１または複数の副生産サブシステム（例えば、通信端末３１を含む協力企業Ｅ３など）と、当該副生産サブシステムから中間部品の供給を受け、当該中間部品をもとに所定の最終部品の生産を行う主生産サブシステム（例えば、通信端末３０を含む親工場Ｅ１−１など）と、前記原材料の調達に関連する各種情報の管理を行うと共に、前記原材料供給サブシステムとの間で原材料の調達に関連する情報の通信を行う中央管理サブシステム（例えば、鋼材調達サーバ３２，アプリケーションサーバ３３等を含む本社Ｅ１−０など）とを備えた原材料調達システムにおいて、前記中央管理サブシステムは、前記原材料供給サブシステムからの原材料の供給および、その原材料の供給を受けて前記副生産サブシステムで行われる中間部品の生産に基づいて動的に変動する副生産サブシステムにおける原材料の在庫量を管理する中央管理サーバ部（例えば、データベースサーバ３４，データベース３５など）を備え、前記副生産サブシステムは、当該原材料の在庫量を取得して中央管理サーバ部へ伝える在庫量取得部（例えば、通信端末３１、バーコードリーダ（ＢＣＲ）など）を備えたことを特徴とする。
【００１８】
また、第２の本発明では、所定の原材料の供給元となる１または複数の原材料供給サブシステムと、当該原材料供給サブシステムから原材料の供給を受け、当該原材料をもとに中間部品を生産する１または複数の副生産サブシステムと、当該副生産サブシステムから中間部品の供給を受け、当該中間部品をもとに所定の最終部品の生産を行う主生産サブシステムと、前記原材料の調達に関連する各種情報の管理を行うと共に、前記原材料供給サブシステムとの間で原材料の調達に関連する情報の通信を行う中央管理サブシステムとを用いる原材料調達方法において、前記中央管理サブシステムでは、前記原材料供給サブシステムからの原材料の供給および、その原材料の供給を受けて前記副生産サブシステムで行われる中間部品の生産に基づいて動的に変動する副生産サブシステムにおける原材料の在庫量を、中央管理サーバ部が管理し、前記副生産サブシステムでは、在庫量取得部が、当該原材料の副生産サブシステムにおける在庫量を取得して中央管理サーバ部へ伝えることを特徴とする。
【００１９】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかる原材料調達システムおよび方法を、鋼材の調達を行うための鋼材調達システムに適用した場合を例に実施形態について説明する。
【００２０】
この鋼材調達システムは、いわゆるＢｔｏＢ型のＥＣ（電子商取引）システムの一種であり、ＢｔｏＢ型のＥＣシステムのなかでも、参加企業が限定されているクローズ形式のＥＣシステムに属する。
【００２１】
第１の実施形態では、鋼材受入予想量をもとに、月単位で協力企業Ｅ３（図３参照）からの鋼材の発注量を制限することを特徴とする。これにより、サプライヤＥ２における鋼材の在庫量や協力企業Ｅ３における鋼材の在庫量が過大となることを月単位で防止できる。
【００２２】
第１の実施形態のもう１つの特徴は、１回の発注量にも制限を設けることにある。これにより、月の半ばに親工場による生産計画（親工場生産計画）が変更された場合などにも柔軟に対応することが可能となる。
【００２３】
（Ａ−１）第１の実施形態の構成
本実施形態にかかる鋼材調達システム２０の全体構成例を図３に示す。
【００２４】
図３において、当該鋼材調達システム２０は、３つのネットワーク２１〜２３と、２つの通信端末３０，３１と、鋼材調達サーバ３２と、アプリケーションサーバ３３と、データベースサーバ３４と、データベース３５と、ホスト３６と、サプライヤシステム３７とを備えている。
【００２５】
ネットワーク２１〜２３のうち、ネットワーク２１は、ＬＡＮ（ローカルエリアネットワーク）、ＩＰ−ＶＰＮ網などのネットワークにも置換可能であるが、ここではインターネットを想定している。ネットワーク２１をインターネットとすることにより、鋼材調達システム２０の導入が低コストで容易に行える。
【００２６】
また、ネットワーク２３は、ＬＡＮや、ＩＰ−ＶＰＮ網、インターネットなどにも置換可能であるが、ここでは、専用線伝送網（専用回線）を想定している。ネットワーク２３に専用回線を想定するのは、主として、既存の鋼材調達システムですでにサプライヤと本社のあいだを専用回線で接続しているケースからの移行の容易性に配慮したものである。したがって、例えば図２に示した調達システム１０のような既存の鋼材調達システムが存在しないところから、まったく新たに当該鋼材調達システム２０を構築する場合などには、ネットワーク２３をインターネットなどに置換することも望ましい。ネットワーク２３がインターネットである場合には、ホスト３６は不要であり、ホスト３６の機能は、鋼材調達サーバ３２などに集約され得る。
【００２７】
この鋼材調達システム２０の構成要素３０〜３７はそれぞれ３つの企業Ｅ１〜Ｅ３のいずれかに属する。構成要素３０〜３７のうち、構成要素３０，３２〜３６は企業（親企業）Ｅ１に属する構成要素である。なかでも、構成要素３２〜３６は企業Ｅ１の本社Ｅ１−０に属し、構成要素３０は企業Ｅ１の工場（親工場）Ｅ１−１に属する。必要に応じて、構成要素３０がインターネット２１ではなく、社内ＬＡＮ２２に接続されていてもよいことは当然である。ただし工場機能は本社機能と地理的に離れた場所に配置されることが多いため、図示した構成となる可能性が高い。
【００２８】
企業Ｅ１は、鋼材の加工品の製造や販売を業とするメーカである。鋼材の加工品としては、例えば、ベアリング、自動車部品、精機製品等があげられる。
【００２９】
これに対し、構成要素（サプライヤシステム）３７は、鋼材のサプライヤである企業Ｅ２に属する。具体的には、企業Ｅ２は、商社や鉄鋼メーカなどであり、鋼材の生産や、その物流管理などを業とする。企業Ｅ２側では（当該鋼材調達システム２０とは別個の）ＥＣシステムを構築していることも多く、その場合にはサプライヤシステム３７は当該ＥＣシステムの一部である可能性が高いが、専用回線２３を介して行われる通信など、他の企業Ｅ１，Ｅ３とのインタフェースに関する部分さえ本実施形態の鋼材調達システム２０に適合したものであれば、企業Ｅ２側でどのようなＥＣシステムが構築されていたとしても、本実施形態への影響はない。
【００３０】
構成要素（通信端末）３１は、協力企業である企業Ｅ３に属する。
【００３１】
協力企業とは、親工場Ｅ１−１からの依頼に基づいて、ベアリング、自動車部品、精機製品等の構成要素となる部品ＰＴ１（図１参照）の製造を行う企業である。この部品ＰＴ１は、サプライヤから供給される鋼材ＭＴ１を用いて製造される。部品ＰＴ１を製造する機能を有するのは協力企業Ｅ３であるため、物理的には鋼材ＭＴ１は直接、サプライヤＥ２から協力企業Ｅ３へ供給されるが、契約上は、サプライヤＥ２から親企業の本社Ｅ１−０が購入して本社Ｅ１−０が協力企業Ｅ３へ支給したものである。
【００３２】
サプライヤＥ２では、供給する鋼材ＭＴ１を予め確保しておく必要があり、協力企業Ｅ３では供給を受けた鋼材ＭＴ１を倉庫に保管し、適宜、倉庫から払い出して部品ＰＴ１の生産を行うため、本実施形態の構成上、鋼材ＭＴ１の在庫は、サプライヤＥ２と協力企業Ｅ３で発生する。したがって在庫の低減は、サプライヤＥ２および／または協力企業Ｅ３のかかえる鋼材の在庫の低減を指す。
【００３３】
図３上は親工場Ｅ１−１，サプライヤＥ２、協力企業Ｅ３をそれぞれ１つずつ図示しているが、これらの数は複数であってよいことは当然である。その場合、各企業や工場の関係は、一例として、図４に示すものとなる。
【００３４】
図３中の構成要素３０〜３７のうち、インターネット２１経由で通信端末３０、３１からのアクセスを受ける鋼材調達サーバ３２は、例えば、Ｗｅｂサーバを主体として実現することができる。図３には示していないが、必要に応じて、サプライヤＥ２にも、当該鋼材調達サーバ３２にアクセスするための通信端末を配置してもよい。
【００３５】
鋼材調達サーバ３２がＷｅｂサーバである場合、通信端末３０，３１はＷｅｂブラウザを搭載し、ＨＴＴＰプロトコルを用いて鋼材調達サーバ３２と通信することになる。ここで、通信端末３０に搭載されるＷｅｂブラウザをＢ０とし、通信端末３１に搭載されるＷｅｂブラウザをＢ１とする。ＨＴＴＰプロトコルを用いて通信端末（例えば、３１）からの要求が届くと、その要求に応じて鋼材調達サーバ３２がアプリケーションサーバ３３を機能させ、アプリケーションサーバ３３がデータベースサーバ３４に依頼してデータベース３５にアクセスし、その要求に対する応答のもとになる情報を生成することになる。アプリケーションサーバ３３から当該情報を受け取った鋼材調達サーバ３２は、当該情報をもとに応答を生成して前記要求を送信してきた通信端末（例えば、３１）へ宛ててその応答を返す。
【００３６】
アプリケーションサーバ３３の機能や、データベースサーバ３４の機能は、Ｗｅｂサーバである鋼材調達サーバ３２と同じマシン上に搭載することも可能であり、アプリケーションサーバ３３の機能をデータベースサーバ３４と同じマシンに搭載すること等も可能であるが、本実施形態ではそれぞれ別なマシンに搭載している。
【００３７】
なお、インターネット２１経由で行われる各通信端末３０，３１と、鋼材調達サーバ３２のあいだの通信にセキュリティ性を確保するには、例えば、ＩＰｓｅｃやＳＳＬを利用することができる。本実施形態の構成上、セッション管理やセッション管理の内容を反映したユーザ管理は不可欠であるが、セッション管理のためには、例えば、クッキー変数や、ＳＳＬセッションＩＤを利用することができる。
【００３８】
前記鋼材調達サーバ３２の内部構成例は図５に示す通りである。
【００３９】
（Ａ−１−１）鋼材調達サーバの内部構成例
図５において、当該鋼材調達サーバ３２は、通信部４０と、制御部４１と、記憶部４２とを備えている。
【００４０】
このうち通信部４０はインターネット２１を経由した通信のために機能する部分で、上述したＨＴＴＰプロトコルに対応した処理などを実行する。
【００４１】
制御部４１は、ハードウエア的には当該鋼材調達サーバ３２のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＷｅｂサーバソフトＷＳ１やＯＳ（オペレーティングシステム）などの各種プログラムに相当する部分である。
【００４２】
記憶部４２はハードウエア的には、ＲＡＭ（ランダムアクセスメモリ）や、ハードディスクなどによって構成される記憶資源であり、ソフトウエア的には、各種のファイルがこの部分に含まれ得る。ＷｅｂサーバソフトＷＳ１やＯＳなどのプログラムファイルもこのようなファイルの一つであるから、その物理的な実体は、この記憶部４２に位置する。
【００４３】
前記アプリケーションサーバ３３、データベースサーバ３４、ホスト３６も基本的にこの鋼材調達サーバ３２と同じ内部構成を有するものであってよい。
【００４４】
ただしアプリケーションサーバ３３には、前記ＷｅｂサーバソフトＷＳ１の替わりにビジネスロジックに対応したアプリケーションソフトＡＰ１が搭載され、データベースサーバ３４には、ＤＢＭＳ（データベース管理システム）に対応するＤＢＭＳ１が搭載される。
【００４５】
ＢｔｏＣ型のＥＣシステムと異なり、ＢｔｏＢ型のＥＣシステム、特に本実施形態の鋼材調達システム２０のようにクローズ形式のＢｔｏＢ型では、単位時間あたりのアクセス数の上限値を予測することが十分に可能、なおかつこの上限値は一般的なＷｅｂサーバの処理能力に比較して十分に小さいためレスポンスタイムが問題になることはほとんどないが、データベース３５に蓄積される情報の経済的価値が大きいため、ミラーリングなどデータベース３５の二重化構成によって、障害などの不測の事態が発生したときにも蓄積した情報が失われないように配慮する必要性は高い。
【００４６】
データベース３５は、直接的には、データベースサーバ３４のＤＢＭＳによって管理される。データベースサーバ３４を介したアクセスによって、当該データベース３５に蓄積した情報が読み出されたり、変更されたりする。
【００４７】
通信端末３０を操作するユーザＵ０や、通信端末３１を操作するユーザＵ１は、鋼材調達サーバ３２に前記ＨＴＴＰでアクセスすることによって、サプライヤシステム３７はホスト３６を介したアクセスによって、当該データベース３５に蓄積した情報の読み出しや変更を行うことができる。
【００４８】
なお、ホスト３６がサプライヤシステム３７に対して提供する機能は、基本的に、鋼材調達サーバ３２やアプリケーションサーバ３３などが、通信端末３０，３１に対して提供する機能と同じである。
【００４９】
また、図３上は省略しているが、社内ＬＡＮ２２の内部や、鋼材調達サーバ３２とインターネット２１のあいだなどには、ファイアウオール、ルータなどのネットワーク機器、ＤＮＳサーバなどのサーバ類が配置され得る。さらに、通信端末３０が配置される親工場Ｅ１−１や、協力企業Ｅ３側にＬＡＮが構築される場合には、そのＬＡＮにも、ネットワーク機器やサーバ類が配置され得る。
【００５０】
一方、通信端末３１の内部構成例は図６に示す通りである。通信端末３０の内部構成も図６と同じであってよい。通信端末３１はユーザＵ１によって操作され、通信端末３０はユーザＵ０によって操作されるが、ユーザＵ１には、協力企業Ｅ３の社員であって、鋼材調達サーバ３２へのアクセスを担当するものが該当し、ユーザＵ０には、企業Ｅ１の社員であって親工場Ｅ１−１内で鋼材調達サーバ３２へのアクセスを担当するものが該当する。
【００５１】
（Ａ−１−２）通信端末の内部構成例
図６において、当該通信端末３１は、通信部５０と、制御部５１と、記憶部５２と、操作部５３と、表示部５４とを備えている。
【００５２】
このうち通信部５０は前記通信部４０に対応し、制御部５２は前記制御部４１に対応し、記憶部５２は前記記憶部４２に対応するのでその詳しい説明は省略する。
【００５３】
ただし本実施形態の構成上、協力企業Ｅ３に配置される通信端末３１は後述するバーコードリーダ（ＢＣＲ）と接続することがある場合には、通信部５０は、当該バーコードリーダとの接続機能も提供する。
【００５４】
また、制御部５１には、前記ＷｅｂサーバソフトＷＳ１の替わりに前記ＷｅｂブラウザＢ１が含まれることになる。電子メールを利用する必要がある場合には、メーラなどの機能もこの制御部５１に含まれることになる。
【００５５】
操作部５３は、ユーザＵ１が操作して通信端末３１に指示を伝える部分で、例えば、マウスなどのポインティングデバイスやキーボードなどを有する。
【００５６】
表示部５４は、前記ＷｅｂブラウザＢ１（やメーラなど）の機能に応じて画面表示を行うディスプレイ装置に対応する部分で、ユーザＵ１に前記データベース３５に蓄積されている情報を含むＷｅｂページを閲覧させるのも、この表示部５４である。ユーザＵ１はこの画面表示を目視しながら前記操作部５３を操作することにより、鋼材調達サーバ３２へ必要な情報を提供することが可能である。
【００５７】
本実施形態では、協力企業Ｅ３内部における鋼材の在庫情報なども含め、重要な情報のすべてを本社Ｅ−１内のデータベース３５に蓄積するため、自企業Ｅ３内の在庫量を確認するにも、鋼材調達サーバ３２へアクセスする必要がある。
【００５８】
鋼材ＭＴ１には棒状や板状、輪状などの様々な形状があり、例えば、１ｔ（１トン）や１０ｔなどの単位で供給されたり、倉庫に保管されたりするため、物理的に近くにいるからといって、必ずしもその在庫量を正確に把握できるものではない。
【００５９】
データベース３５に蓄積された情報をもとに協力企業Ｅ３内の在庫量を把握するため、本実施形態でも親工場Ｅ１−１から前記ステップＳ２に相当する発注依頼を出すことが可能であるが、ここでは、協力企業Ｅ３から発注依頼を出すものとする。
【００６０】
協力企業Ｅ３の通信端末３１から送信された発注依頼は、前記鋼材調達サーバ３２などの処理を経てデータベース３５に格納されたあと、ホスト３６が専用回線２３経由でサプライヤシステム３７へ送信する。
【００６１】
以下、上記のような構成を有する本実施形態の動作について、図１，図７〜図９を参照しながら説明する。
【００６２】
図１は本実施形態以外の実施形態にも共通する共通動作を示しており、図９のフローチャートが本実施形態に特徴的な特徴動作を示している。
【００６３】
図１には、Ｓ１１〜Ｓ２０の各ステップが含まれており、図９のフローチャートは、Ｓ２１〜Ｓ２６の各ステップから構成されている。
【００６４】
（Ａ−２）第１の実施形態の動作
最初は、共通動作について説明する。
【００６５】
（Ａ−２−１）共通動作
図１において、親工場Ｅ１−１が協力企業Ｅ３に対し、部品加工依頼を送信して部品ＰＴ１の加工を依頼する（Ｓ１１）。依頼の方法は電話、及びＦＡＸ、電子メール等の従来通りの方法を用いることができるが、本社Ｅ１−０の鋼材調達サーバ３２に電子掲示板の機能を持たせること等により、電子掲示板を用いて加工依頼を行うことも可能となる。電子掲示板の実現法には様々なものがあるが、ＣＧＩを利用したＣＧＩ掲示板ならば、鋼材調達サーバ３２などのＷｅｂサーバ上で簡便に実現することができる。
【００６６】
協力企業Ｅ３は、親工場Ｅ１−１から加工を依頼されると、これを基に生産計画（協力企業生産計画）を立てる。
【００６７】
同時に材料となる鋼材ＭＴ１の調達計画も立てることになるが、まずは協力企業Ｅ３自身における鋼材ＭＴ１の在庫を確認し、在庫が不足していれば発注を計画する。この在庫の確認のためにも、ユーザＵ１は通信端末３１を操作して、上述したように本社Ｅ１−０の鋼材調達サーバ３２にアクセスすることになる（Ｓ１２）。
【００６８】
在庫が不足していた場合、サプライヤ（例えば、Ｅ２）に発注を行うことになるが、同一鋼材を複数のサプライヤが扱っている場合があるので、サプライヤの在庫（Ｓ在庫）も確認して、発注先のサプライヤの選定を行うこともある。サプライヤ在庫も本社Ｅ１−０の鋼材調達サーバ３２が管理しているため、当該ユーザＵ１は、サプライヤ在庫の確認でも鋼材調達サーバ３２へアクセスすることになる（Ｓ１２）。
【００６９】
確認によって在庫が不足していることが判明し、発注を行う場合、本実施形態では、協力企業Ｅ３が直接サプライヤ（例えば、Ｅ２）と取り引きを行うのではなく、本社Ｅ１−０の鋼材調達サーバ３２などを経由して発注を依頼することになる（Ｓ１３）。上述したように鋼材ＭＴ１は、物理的には直接、サプライヤＥ２から協力企業Ｅ３へ供給されるが、契約上は、サプライヤＥ２から親企業の本社Ｅ１−０が購入して本社Ｅ１−０から協力企業Ｅ３へ支給したものであるため、鋼材ＭＴ１の購入や支給で中心的な役割を担う本社Ｅ１−０が、このように発注の状況を逐一、監視できる構成は管理する上で好ましいといえる。
【００７０】
この発注に際しても、ＷｅｂブラウザＢ１を利用したＨＴＴＰプロトコルによる通信が行われる。以下の説明でも、特に断らない限り、通信端末３１と本社Ｅ１−０のあいだの通信や、通信端末３０と本社Ｅ１−０のあいだの通信などは、Ｗｅｂブラウザを利用したＨＴＴＰプロトコルによる通信である。
【００７１】
この発注の内容を容認するか否かなどに関しても後述するように本社Ｅ１−０側で様々な判断が行われるが、容認された場合には、その発注の内容がそのまま前記ホスト３６などを経由して本社Ｅ１−０からサプライヤシステム３７へ提供されてサプライヤＥ２による受注が行われる（Ｓ１４）。発注の内容自体は、上述したステップＳ２の発注依頼と同様であり、鋼材毎の発注量や納期が含まれている。
【００７２】
受注すると、サプライヤＥ２は在庫引き当てや出荷指示、物流手配等を行い、正式な納入量や納期を明記した入荷予報を、前記専用回線２３を介してホスト３６へ伝える（Ｓ１５）。サプライヤＥ２からの入荷予報をホスト３６が受け取ると、ホスト３６はそれを鋼材調達サーバ３２に送り、鋼材調達サーバ３２は（前記アプリケーションサーバ３３，データベースサーバ３４を介して）データベース３５に登録する。
【００７３】
そして、この入荷予報に記載された納期までに、サプライヤＥ２から協力企業Ｅ３に鋼材ＭＴ１が配達される。この配達では、トラックなどの物流機能が利用される。配達される鋼材ＭＴ１は、複数の束（現品）から構成されており、それぞれの束には現品Ｎｏ（現品ナンバ）等を示すバーコードを有する現品札が付加されている。
【００７４】
鋼材ＭＴ１が協力企業Ｅ３に届くと、協力企業Ｅ３の受入担当者（この受入担当者は、ユーザＵ１と同じであってよい）はバーコードリーダ（ＢＣＲ）で当該バーコードの現品Ｎｏ等を読み込み、読み込んだデータをファイル転送で鋼材調達サーバ３２に送る。鋼材調達サーバ３２は、送られてきたデータと、登録されている入荷予報を付き合わせ、該当の束（現品）を倉庫在庫として登録する。このファイル転送のために必要ならば、ＷｅｂブラウザＢ１とは別に、ＦＴＰクライアントソフトを用いてもよい。
【００７５】
また、バーコードリーダ自体がＦＴＰクライアントの機能を搭載している場合などには、通信端末３１を介することなく、バーコードリーダから前記バーコードの現品Ｎｏ等の情報を本社Ｅ１−０へファイル転送することができる。
【００７６】
ただし現品Ｎｏ等の情報を本社Ｅ１−０に提供する際、必ずしもバーコードリーダを利用する必要はない。ユーザＵ１が目視などによって現品Ｎｏを確認し、その現品Ｎｏを、鋼材調達サーバ３２が提供するＷｅｂページ（フォーム）中の該当する欄（フィールド）に記述すること等により、通常のＨＴＴＰプロトコルによって現品Ｎｏの内容を本社Ｅ１−０に提供することができるからである。この場合、前記アプリケーションソフトＡＰ１がデータベース３５内の該当する入荷予報を特定し、その鋼材ＭＴ１の供給が完了した旨の登録を行うことで、受入処理が実行される。
【００７７】
あるいは、鋼材調達サーバ３２が提供するＷｅｂページ上で、鋼材調達サーバ３２側で管理されている前記入荷予報を呼び出し、該当の束（現品）を選択して受入処理を行うこともできる。
【００７８】
ただし以下の説明では、主として、バーコードリーダの利用を想定する。目視確認した現品ＮｏをＷｅｂページの該当する欄に記述したり、倉庫在庫情報（前記入荷予報に対応）をＷｅｂページ上に呼び出したりして鋼材ＭＴ１の移動を管理できる点は、倉庫に鋼材ＭＴ１を受け入れる場合だけでなく、倉庫から鋼材ＭＴ１を払い出す場合でも同様であるが、以下では、倉庫からの払い出しに関しても、主として、バーコードリーダの利用を想定する。
【００７９】
前記受入処理が実行されることにより、データベース３５では、該当の鋼材ＭＴ１の束（現品）が、協力企業Ｅ３における倉庫在庫として登録されることになる。
【００８０】
そして受入処理が行われたことを確認することにより、予定されていた鋼材ＭＴ１の受入が無事に完了したことを検出すると、鋼材調達サーバ３２がホスト３６に対して検収を依頼する（Ｓ１８）。
【００８１】
ところで、協力企業Ｅ３が、前記ステップＳ１１で親工場Ｅ１−１から依頼された部品ＰＴ１の加工を行う場合、加工に必要となる量の鋼材ＭＴ１を倉庫から払い出すことになる。
【００８２】
この払出処理に際し、バーコードリーダで、束（現品）に付いているバーコードを読み込むと、協力企業Ｅ３において倉庫から払い出された鋼材ＭＴ１は仕掛在庫として計上される。
【００８３】
払い出した鋼材ＭＴ１を加工して部品ＰＴ１の製造が完了すると、その部品ＰＴ１が協力企業Ｅ３から親工場Ｅ１−１へ出荷されることになる。この出荷に際しても、出荷が行われたことや、出荷された部品ＰＴ１の量などの各種情報が鋼材調達サーバ３２を介して本社Ｅ１−０のデータベース３５に登録されるものであってもよいが、ここでは、後述するように、出荷に関しては、鋼材調達システム２０と別個のシステム（出荷管理システム）が管理する構成とする。なお、ステップＳ１１で依頼された量と同じ量の部品ＰＴ１が出荷されることが保証されている場合には、出荷された部品ＰＴ１の量などの各種情報を逐一、管理しなくても、部品加工依頼と出荷の対応関係だけを管理すれば足りるものと考えられる。
【００８４】
次に、図７〜図９を用いて本実施形態の特徴動作について説明する。本実施形態の特徴動作は、前記共通動作におけるステップＳ１３の部分に関連するものである。この特徴動作では、発注量を制限することによって在庫量を抑制し、前記親工場生産計画の変更に即応できる柔軟性に寄与するものである。柔軟性は、結局のところ、各時点における在庫量を極限まで抑制することによって高めることができる。
【００８５】
本実施形態では発注行為を協力企業Ｅ３が行うことにしたが、鋼材ＭＴ１はあくまでも本社（親工場も含んだ親企業）Ｅ１から協力企業Ｅ３への支給であり、在庫量を抑制することによって、無計画な発注で在庫を増やさないことは、親企業Ｅ１にとっても重要である。
【００８６】
（Ａ−２−２）特徴動作
図７には、鋼材受入予想量をもとに、月単位で協力企業Ｅ３からの鋼材ＭＴ１の発注量を制限する様子が示されている。
【００８７】
鋼材受入予想量とは、協力企業Ｅ３が近い未来に受け入れる鋼材ＭＴ１の量に関する予想量のことで、親工場Ｅ１−１が決定する。換言するなら、鋼材受入予想量とは、サプライヤＥ２が協力企業Ｅ３のために用意しておくべき鋼材ＭＴ１の量に関する親工場Ｅ１−１からの内示である。
【００８８】
具体的には、親工場Ｅ１−１は、毎月、月の半ばに、次月と次々月の鋼材受入予想量を決定してサプライヤＥ２に提示する。これを受けたサプライヤＥ２は、ホスト３６を介して協力企業Ｅ３における鋼材ＭＴ１の在庫量を調べ、在庫量と鋼材受入予想量の差などに基づいて、鋼材ＭＴ１の仕入れ量や生産量を決定する。
【００８９】
ただし発注には納期指定があり、発注で指定された納期が当月（発注を行った日が属する月）に属する場合と、次月以降である場合で処理が異なる。図７では処理が月単位で行われているため、納期が当月に属する場合には、当月中にすでに受入が行われた鋼材ＭＴ１の量の累計を考慮する必要がある。
【００９０】
発注で指定された納期が当月に属する場合は、次の式（１）にしたがって処理する。
【００９１】
Ｐ（Ｘ）≧  Ｘ月の１日からの受入量累計＋Ｘ月納期指定の発注残合計＋発注量（α）              …（１）
また、次月以降の月に属する場合には、式（２）にしたがって処理する。
【００９２】
Ｐ（Ｘ＋１）≧  Ｘ＋１月納期指定の発注残合計＋発注量（α）    …（２）
ここで、Ｘ月とは協力企業Ｅ３による発注の時点では当月を指し、親工場Ｅ１−１による鋼材受入予想量の決定時点では、次月を指す。また、Ｘ＋１月とは、Ｘ月の次月を指す。したがって、Ｘ＋１月は、発注の時点では次月にあたり、鋼材受入予想量の決定時点では次々月にあたる。
【００９３】
また発注時点で、Ｐ（Ｘ）は、当月の鋼材受入予想量を指し、Ｐ（Ｘ＋１）は次月の鋼材受入予想量を指す。なお、発注残合計とは、発注が行われたものの、まだ協力企業Ｅ３の倉庫への受入時に行う受入処理が完了していない鋼材ＭＴ１の量を指す。
【００９４】
協力企業Ｅ３のユーザＵ１が本社Ｅ１−０と通信して前記ステップＳ１３の発注を行ったとき、式（１）、（２）の不等式が成立すればその発注量（α）に対応する発注は容認され、成立しなければ、拒否される。発注が拒否されると、その発注に関し前記ステップＳ１４以降の処理が実行されないことは当然である。
【００９５】
なお、発注を行ったあとで発注量や納期など、発注内容（注文内容）が変更されることがあり得るが、その変更を指示する発注に対しても、式（１）、（２）が適用され、発注量の制限が行われる。
【００９６】
このような処理により、協力企業Ｅ３における鋼材ＭＴ１の在庫量は、前記鋼材受入予想量を上限とした値に制限されるため、在庫を低減することが可能となる。
【００９７】
ただし式（１）、（２）による制限は、月単位の制限であるため、その不等式が成立する範囲内であれば、協力企業Ｅ３が一度に大量の鋼材ＭＴ１を発注することを許してしまう。そして、一度に大量の鋼材ＭＴ１を発注することを許すと、月初めの一括発注で、大量の鋼材ＭＴ１を受入れ、まとめ生産を行うことが可能となってしまう。このような、まとめ生産は従来から行われていたものであるが、親工場Ｅ１−１の観点からすると、上述した親工場生産計画を月の半ばに変更したい場合でも、その時点ではすでに協力企業Ｅ３による部品ＰＴ１の生産が完了しているため、変更を行うことができなくなってしまったり、変更すると、製造済みの部品ＰＴ１が大量に倉庫に死蔵されるというという問題が生じる。
【００９８】
この問題を解決するには、次の式（３）にしたがって、図８に示す動作を行うことが有効である。
【００９９】
Ｓ（Ｅ３）≧  倉庫在庫合計＋仕掛在庫合計＋発注残合計＋発注量（α）…（３）
ここで、倉庫在庫とは、協力企業Ｅ３が受け入れた鋼材ＭＴ１のうち、倉庫に保存されている鋼材ＭＴ１の量を指す。倉庫から払い出された鋼材ＭＴ１は、元の鋼材ＭＴ１のままの状態であるか、製造ラインで加工され、元の鋼材ＭＴ１と製造済みの部品ＰＴ１の中間の状態であるか、あるいは、製造済みの部品ＰＴ１となっているが前記ステップＳ２０の出荷がまだ行われていない状態にあるかを問わず、仕掛在庫に分類される。
【０１００】
したがって、協力企業Ｅ３における鋼材ＭＴ１の在庫は、倉庫在庫か仕掛在庫のいずれかであり、仕掛在庫でないものは当該倉庫在庫に該当する。
【０１０１】
また、前記Ｓ（Ｅ３）は、各協力企業（ここでは、Ｅ３）ごと、鋼材ＭＴ１の種類ごとに親工場Ｅ１−１が設定する基準在庫量を指す。この基準在庫量Ｓ（Ｅ３）を十分に小さな値に設定することにより、協力企業Ｅ３は、従来のような、まとめ生産を行うことができなくなり、親工場生産計画を月の半ばに変更しても、部品ＰＴ１の死蔵などが発生せず、柔軟性が向上する。ただし、基準在庫量Ｓ（Ｅ３）の設定にあたって、親工場Ｅ１−１は、基準在庫量Ｓが小さすぎるために各協力企業（ここでは、Ｅ３）の生産活動に支障が生じないように配慮する必要がある。
【０１０２】
この式（３）の不等式が成立すればその発注量（α）に対応する発注は容認され、成立しなければ、拒否される点や、発注を行ったあとで発注量を変更する場合にも式（３）が適用される点は、前記式（１）、（２）と同じである。ただし式（３）には、鋼材受入予想量が反映されないため、式（１）または（２）による制限よりも、はるかに小さい値に発注量αを制限し、小ロット発注を実現することが可能である。
【０１０３】
また、式（３）は、前記式（１）および（２）とともに適用してもよく、単独で適用してもよい。
【０１０４】
式（３）を、前記式（１）および（２）とともに適用する場合の動作例を示したものが、図９のフローチャートである。
【０１０５】
図９では親工場Ｅ１−１のユーザＵ０が本社Ｅ１−０と通信して協力企業Ｅ３の在庫量を確認し（Ｓ２１）、当該協力企業Ｅ３の鋼材受入予想量（例えば、Ｐ（Ｘ）など）を決定した上で本社Ｅ１−０のデータベース３５に登録している（Ｓ２２，Ｓ２３）。
【０１０６】
そして、協力企業Ｅ３のユーザＵ１が発注を行うために鋼材調達サーバ３２にアクセスすると（Ｓ２４）、当該鋼材受入予想量をもとに前記式（１）、（２）の不等式が成立するか否かという観点からステップＳ２５の検査を行い、不等式が成立するときには、ステップＳ２６で前記式（３）の不等式が成立するか否かを検査している。
【０１０７】
ただし、このように式（３）を、前記式（１）および（２）とともに適用する場合、一般的に式（３）の不等式が成立する確率よりも式（１）または（２）のいずれかの不等式が成立する確率のほうが高いとするならば、ユーザＵ１の操作負担軽減の観点および本社Ｅ１−０内の各構成要素３２〜３５の処理能力にかかる負荷を軽減する観点から、ステップＳ２５とＳ２６の順番を入れ替えたほうが効率的となる可能性が高い。
【０１０８】
（Ａ−３）第１の実施形態の効果
本実施形態によれば、協力企業（例えば、Ｅ３）およびサプライヤ（例えば、Ｅ２）における鋼材（ＭＴ１）の在庫を十分に低減するとともに、システム（２０）全体として効率的な安定運用を行うことが可能である。
【０１０９】
この効率的な安定運用には、親企業生産計画の変更に対して即応できる柔軟性の向上も寄与している。
【０１１０】
（Ｂ）第２の実施形態
以下では、本実施形態が第１の実施形態と相違する点についてのみ説明する。
【０１１１】
本実施形態は、上述した発注の内容（注文の内容）を変更する際、協力企業とサプライヤのあいだで行うネゴシエーションを支援することを特徴とする。
【０１１２】
上述したように、サプライヤＥ２は、鋼材受入予想量などに基づいて、予め鋼材ＭＴ１の仕入れや、生産を行うのであるから、協力企業のみの都合で発注内容が変更されると、サプライヤＥ２側に鋼材ＭＴ１の在庫が増える等の不都合が発生し、システム２０全体として効率的な安定運用を行うことが困難となるため、このようなネゴシエーションが必要となる。
【０１１３】
（Ｂ−１）第２の実施形態の構成および動作
本実施形態が第１の実施形態と相違するのは、鋼材調達システム２０の動作のみである。
【０１１４】
本実施形態の動作は、図１０および図１１に示す。
【０１１５】
図１０は、協力企業Ｅ３から発注を行うと、その発注内容（注文内容）を変更するには、サプライヤＥ２の承認が必要であることを示している。
【０１１６】
この間の動作の詳細は、図１１のフローチャートに示す通りである。図１１のフローチャートは、Ｓ３１〜Ｓ４０の各ステップから構成されている。
【０１１７】
図１１において、協力企業Ｅ３のユーザＵ１が本社Ｅ１−０と通信して、前記ステップＳ１３の発注を行うと（Ｓ３１）、その発注の内容は所定の検査でチェックされ（Ｓ３２）、検査結果がＯＫであると、本社Ｅ１−０から専用回線２３を介してサプライヤＥ２に中継され、サプライヤＥ２により前記ステップＳ１４の受注が行われる（Ｓ３３）。当該ステップＳ３２の検査は、例えば、図９のステップＳ２５，Ｓ２６で行われた検査と同じであってよい。
【０１１８】
受注直後は、当然、その受注にかかる鋼材ＭＴ１の協力企業Ｅ３への受入が完了していないから、その受注にかかるデータは、本社Ｅ１−０のデータベース３５内では発注残として管理される。基本的に、受入処理が完了するまでの発注残の状態にある限り、協力企業Ｅ３側のユーザＵ１は発注内容の変更を要求することが可能であると認識しているため、発注内容の変更を要求する可能性がある。
【０１１９】
ユーザＵ１が発注内容の変更を要求すると（Ｓ３５）、その変更内容は、ステップＳ３６の検査結果がＯＫであることを条件に、仮の変更としてデータベース３５に登録（仮登録）される（Ｓ３７）。ステップＳ３６の検査の内容は、前記ステップＳ３２と同じである。
【０１２０】
サプライヤシステム３７がホスト３６を介してデータベース３５に登録されている当該仮の変更の内容を取得すると、サプライヤシステム３７が（あるいは、サプライヤＥ２側の担当者が）その仮の変更の内容を承認するか、否認するかを決定する。この決定の内容は、データベース３５に登録してもよく、電子メールなどを利用して通信端末３１のユーザＵ１へ通知するようにしてもよいが、いずれにしても、本社Ｅ１−０には伝えてデータベース３５の登録内容に反映しておく必要がある。ここでは、当該決定の内容は本社Ｅ１−０に伝えられ、本社Ｅ１−０を介してユーザＵ１へも伝えられる手順となっている（Ｓ３８，Ｓ３９）。特に、否認された場合にはユーザＵ１へ伝える必要性が高いと考えられる。
【０１２１】
仮の変更の内容が承認された場合には、データベース３５の登録内容を変更する必要が生じる。この変更では、既存の発注残データに対する本来の変更が行われる（Ｓ４０）とともに、前記仮の変更に関する登録内容も処理される。この処理では、例えば、仮の変更を削除するものであってよい。
【０１２２】
（Ｂ−２）第２の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることができる。
【０１２３】
加えて、本実施形態では、発注内容変更時のネゴシエーションを効率的に行うことができるため、サプライヤ（Ｅ２）側に鋼材（ＭＴ１）の在庫が増える等の不都合が発生せず、システム（２０）全体としての効率的な安定運用に寄与することが可能である。
【０１２４】
（Ｃ）第３の実施形態
以下では、本実施形態が第１、第２の実施形態と相違する点についてのみ説明する。
【０１２５】
本実施形態は、入荷予報をもとに、第２の実施形態と同様なネゴシエーションをさらに効率化することを特徴とする。
【０１２６】
協力企業からの発注データには、発注する鋼材ＭＴ１の量と納期（協力企業が希望する納期）が示されているが、実際に納入される量や納期は、サプライヤの都合で変更されることもある。特に量に関しては、棒状や板状、輪状などの様々な形状があり、例えば、１ｔ（１トン）や１０ｔなどの単位で供給されるという鋼材ＭＴ１の特性上、少なからぬ誤差（例えば、数十ｋｇや数百ｋｇ程度の誤差）が混入することが避けられない。
【０１２７】
この誤差には、サプライヤ側の都合で意図的に発注量とは異なる量の鋼材が納入される場合の、発注量と納入量の差分も含まれる。
【０１２８】
このような誤差に起因して発注量とは異なる量の鋼材が納入される場合もあり得るため、最終的に供給する鋼材ＭＴ１の量や納期を供給前にサプライヤＥ２側から伝えることが必要となり、そのために、当該入荷予報が用いられる。入荷予報は前記ステップＳ１５で行われたように、サプライヤＥ２から本社Ｅ１−０に伝えられるものである。
【０１２９】
（Ｃ−１）第３の実施形態の構成および動作
本実施形態が第１、第２の実施形態と相違するのは、鋼材調達システム２０の動作のみである。
【０１３０】
本実施形態の特徴動作は、図１２および図１３に示す。
【０１３１】
図１２は、前記入荷予報が本社Ｅ１−０に伝えられる前ならば発注内容の変更が可能であるが、伝えられたあとでは変更ができないことを示している。
【０１３２】
この間の動作の詳細は、図１３のフローチャートに示す通りである。図１３のフローチャートは、Ｓ３１〜Ｓ４４の各ステップから構成されている。
【０１３３】
図１３において、図１１と同じ符号Ｓ３１〜Ｓ３７を付与した各ステップの処理は図１１と同じである。
【０１３４】
ただし図１１には具体的な注番（注文番号（発注番号））を示していなかったが、図１３中には、ＡＡＡＡＡ、ＢＢＢＢＢとして示してある。また、図１３中では、異なる注番に該当する処理を区別するため、注番ＡＡＡＡＡのほうには、符号Ｓ３１〜Ｓ３３をそのまま使用し、注番ＢＢＢＢＢのほうには、符号の末尾に「Ａ」を付与した符号Ｓ３１Ａ〜Ｓ３３Ａを使用している。したがって、Ｓ３１Ａ〜Ｓ３３Ａの処理の内容は実質的にＳ３１〜Ｓ３３の処理と同じである。この点は、Ｓ３５とＳ３５Ａの関係にもあてはまる。
【０１３５】
図１３において、ステップＳ３５で協力企業Ｅ３が注番ＡＡＡＡＡの発注の変更を依頼すると（Ｓ３５）、ステップＳ３６の検査結果がＯＫであれば、その変更の内容はデータベース３５に仮登録される（Ｓ３７）。この変更の内容が最終的に容認されるかいなかは、第２の実施形態と同様に、サプライヤＥ２の承認、否認に依存して決まる。このような手順となるのは、注番ＡＡＡＡＡに関する入荷予報がまだサプライヤＥ２から本社Ｅ１−０に届いていないからである。
【０１３６】
次に、ステップＳ４１でサプライヤＥ２が注番ＢＢＢＢＢに関する入荷予報を送信してきたことを受けて、本社Ｅ１−０では、その入荷予報をデータベース３５に登録し（Ｓ４２）、そのあと、当該注番ＢＢＢＢＢに関する発注内容の変更依頼が協力企業Ｅ３から届くと（Ｓ３５Ａ）、本社Ｅ１−０内の鋼材調達サーバ３２（前記アプリケーションサーバ３３も含む）の判断で即座にその変更依頼の受付が拒否され（Ｓ４３）、その旨が即座に協力企業Ｅ３の通信端末３１に伝えられる（Ｓ４４）。
【０１３７】
ステップＳ４３の受付拒否は、登録された入荷予報に基づいてアプリケーションサーバ３３が判断するものであるから、ステップＳ３７の仮登録の場合のように、サプライヤＥ２側の承認や否認を待つことなく、即座に行われる。したがって、協力企業Ｅ３側のユーザＵ１も通信端末３１の表示部５４の表示画面を閲覧するだけで直ちに拒否されたことを認識できる。
【０１３８】
サプライヤＥ２の立場からみると、発注内容の変更依頼が届いても否認するしかない状態となったときに、入荷予報を本社Ｅ１−０に送信するようにすれば、個別に、承認や否認の意思表示をする必要もなくなる。
【０１３９】
発注内容の変更依頼が届いても否認するしかない状態が具体的にどのような状態であるかは、サプライヤごとに相違し得るが、例えば、受注してから、サプライヤが在庫引き当てや物流手配を行った状態がこれに該当する。このような状態で注文内容の変更を認めると、サプライヤとしては在庫引き当て等をやり直さなければならなくなるからである。
【０１４０】
もちろん、このようなやり直しを行うか、行わないかは、サプライヤのポリシーに依存するので、行うポリシーを持つサプライヤならば、物流手配等を行ったあとでも入荷予報を送信しなければよいし、行わないポリシーを持つサプライヤならば、物流手配等を行った直後に入荷予報を送信すればよい。
（Ｃ−２）第３の実施形態の効果
本実施形態によれば、第２の実施形態の効果と同等な効果を得ることができる。
【０１４１】
加えて、本実施形態では、入荷予報をもとに、協力企業とサプライヤのあいだのネゴシエーションを効率化することが可能である。
【０１４２】
（Ｄ）第４の実施形態
以下では、本実施形態が第１〜第３の実施形態と相違する点についてのみ説明する。
【０１４３】
従来は月単位の一括発注で、大量の鋼材ＭＴ１をまとめて受入れ、まとめ生産を行っていたが、第１の実施形態（特に、前記式（３）を適用するケース）によって、一度に発注される発注量を低減すれば物流の効率が低下する傾向が強くなる。例えば、従来は１台のトラックに積載量の限界近くまで鋼材ＭＴ１を積載して効率的な物流を行うことができたのに対し、発注量が低減すれば、積載量の一部だけを消費するわずかな量の鋼材ＭＴ１をトラックに積載して配達しなければならない可能性が高まり、物流の効率が低下し得る。
【０１４４】
そこで本実施形態では、納期（協力企業が希望する納期）に幅を持たせることを特徴とする。これにより、サプライヤ側の判断で行う物流手配の自由度が高まり、例えば、注番の異なる発注にかかる鋼材ＭＴ１を同じトラックにまとめて積載する頻度を高めること等が可能となり、全体として物流効率を高めることができる。もちろん、鋼材ＭＴ１の種類が異なっていても同じトラックにまとめて積載してよいことは当然である。
【０１４５】
（Ｄ−１）第４の実施形態の構成および動作
本実施形態が第１の実施形態と相違するのは、鋼材調達システム２０の動作のみである。
【０１４６】
本実施形態の特徴動作は、図１４および図１５に示す。
【０１４７】
図１４（Ａ）は本実施形態を適用しない場合の物流の様子を示し、図１４（Ｂ）は、本実施形態を適用した場合の物流の様子を示している。
【０１４８】
本実施形態では、上述した納期の幅の概念を明確にするために、幅の両端を規定する時間位置のうち、時間的に早いほうを開始日（納入開始日）とし、遅いほうを終了日（納入終了日）とする。納入終了日は、それ以上、鋼材ＭＴ１の納入が遅れると、部品ＰＴ１の生産に支障が生じる日である。時間の単位は必ずしも日に限る必要はないが、ここでは、日を単位としている。
【０１４９】
鋼材ＭＴ１の配達に使用するトラックＴＲ１の積載量の上限を例えば２０００ｋｇとし、協力企業Ｅ３から納期が異なり、発注量が１０００ｋｇずつの２つの発注が行われたケースを想定する。
【０１５０】
このケースにおいて、本実施形態を適用しない図１４（Ａ）の例では、それぞれの発注Ｄ１１，Ｄ１２で、協力企業Ｅ３が希望する納期が４月３日と４月５日であるため、トラックＴＲ１を用いて、４月３日に１０００ｋｇ、４月５日に１０００ｋｇを配達している。この例では、トラックＴＲ１に２０００ｋｇの積載能力があるのに、その能力の半分しか活用できておらず、物流の効率が低い。
【０１５１】
一方、本実施形態を適用した図１４（Ｂ）の例では、１つの発注Ｄ２１で協力企業Ｅ３が希望する納期は、納入開始日が４月１日で納入終了日が４月３日であり、もう１つの発注Ｄ２１で協力企業Ｅ３が希望する納期は、納入開始日が４月３日で納入終了日が４月５日である。
【０１５２】
これら２つの発注Ｄ２１，Ｄ２２を受けてサプライヤＥ２は、４月３日に、合計２０００ｋｇの鋼材ＭＴ１を１台のトラックＴＲ１に積載して配達を行わせているため、トラックＴＲ１の積載能力を１００％活用しており、物流の効率が高い。なお、図１４（Ａ）および（Ｂ）の例では、各発注にかかる鋼材ＭＴ１の具体的な種類が相違するケース（種類Ａ、Ｂ）を例に取っているが、各発注の鋼材ＭＴ１の種類が同じであっても同様のことは起こり得る。
【０１５３】
ところで、実際には、協力企業Ｅ３にもサプライヤＥ２にも休日（休業日）が存在し、休日には、基本的に各業務を行うことはできない。また、納入に関しては、鋼材ＭＴ１の種類ごと、またサプライヤごとに納入リードタイムが相違する可能性がある。
【０１５４】
したがって現実には、納入リードタイムや、各企業の休日に配慮した配達を行う必要性が高い。なお、納入リードタイムとは、納入の準備を開始してから納入を完了するまでの時間を指す。
【０１５５】
また、本社Ｅ１−０にかかる親企業Ｅ１にも通常、休日は存在するが、鋼材調達サーバ３２など、図３や図１に示した本社Ｅ１−０の各構成要素３２〜３６は、２４時間３６５日停止することなく運用することが可能であるから、本実施形態の構成上、親企業Ｅ１の休日に配慮する必要はない。
【０１５６】
納入リードタイムを３日、前記幅（フレックス日数）を２日と仮定した場合、協力企業Ｅ３およびサプライヤＥ２の休日と、鋼材ＭＴ１の納入リードタイムに配慮した納入開始日と納入終了日の設定は、例えば、図１５（Ａ）〜（Ｅ）に示すようになる。
【０１５７】
図１５（Ａ）に示すように、現在から納入終了日（終了日）までのあいだに休日が存在しない場合には、単純に、納入リードタイムに１日を加えた日数（ここでは、４日）分、現在を含めて数えた日が、設定可能な最も早い納入終了日となる。したがって図１５（Ａ）の例では、現在（今日）から３日後が納入終了日として設定されている。
【０１５８】
また、図１５（Ｂ）〜（Ｅ）に示すように、現在から納入終了日（終了日）までのあいだに、サプライヤの休日が入る場合には、その日を算入することなく、前記４日をカウントして納入終了日を設定する必要がある。この結果、例えば、図１５（Ｅ）の例では、２日分のサプライヤの休日を含む、現在から５日後が設定可能な最も早い納入終了日となる。
【０１５９】
算入せずにカウントした結果、協力企業Ｅ３の休日と重なってしまった場合には、翌稼働日まで振り替えを行い、その稼働日から、納入終了日として設定可能となる。
【０１６０】
なお、協力企業Ｅ３の休日には、倉庫への受入などを行うことができないため、納入終了日も納入開始日も、協力企業Ｅ３の休日を避けて設定する必要がある。ここで、納入終了日または納入開始日は、鋼材ＭＴ１の協力企業Ｅ３への配達（納入）を行ってもよい日であるものとしている。納入終了日、納入開始日のいずれでもない日は、前記幅に属する日であっても、協力企業Ｅ３の休日には納入を行うことはできないので、その休日の翌日（翌稼働日）に納入することになる。サプライヤＥ２や物流を実行する配送業者などには、協力企業Ｅ３の休日を伝えて、その日に納入しないようにしておく必要があることは当然である。
【０１６１】
サプライヤＥ２の休日を算入することなく、前記４日をカウントする操作や、納入終了日および納入開始日を、協力企業Ｅ３の休日を避けて設定する操作などを組み合わせた結果として、図１５（Ｂ）〜（Ｅ）に示すような設定が行われる。
【０１６２】
なお、サプライヤＥ２の休日であっても協力企業Ｅ３の休日でなければ納入は可能なので、図１５（Ｂ）〜（Ｄ）には、納入開始日がサプライヤの休日に設定されている。
また、上述したサプライヤＥ２側に構築されているＥＣシステムが２４時間３６５日運用され、サプライヤの休日にも自動的に物流の手配を行えるものである場合には、納入開始日や納入終了日の設定にあたり、サプライヤの休日を考慮する必要はないことは当然である。
【０１６３】
（Ｄ−２）第４の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることができる。
【０１６４】
加えて、本実施形態では、納期（協力企業が希望する納期）に幅を持たせることによって、サプライヤ側の判断で行う物流手配の自由度が高まるため、在庫量を低減しているにもかかわらず、全体として物流効率を高めることが可能になる。
【０１６５】
（Ｅ）第５の実施形態
以下では、本実施形態が第１〜４の実施形態と相違する点についてのみ説明する。
【０１６６】
上述した現品Ｎｏ等を示すバーコードの使用は、受入処理や、在庫管理の効率化を行う上で極めて有効であるが、バーコードを表示している現品札が配達などの途中で汚れたり、紛失したり、破損したりしてバーコードが読みとれなくなることがある。このような現品札の汚れ、紛失、破損などに対する対策を取ることは本来、サプライヤまたは配送業者の義務であると考えられるが、バーコードが読みとれなくなると、現実に、受入処理などの効率が低下したり、行うこと自体が不可能となってしまうので、ここでは、鋼材調達システム２０がその対策を講じるものとする。
【０１６７】
また、サプライヤが零細な企業である場合など、サプライヤが鋼材にバーコードを有する現品札を付加できないこともあり得るので、その対策も必要となる。
【０１６８】
本実施形態は、鋼材調達サーバ３２からバーコードを示す画像情報を配信することにより、常に、正常なバーコードを利用できる環境を提供することを特徴とする。
【０１６９】
（Ｅ−１）第５の実施形態の構成および動作
本実施形態が第１の実施形態と相違するのは、鋼材調達システム２０の動作のみである。
【０１７０】
本実施形態の特徴動作は、図１６と図１７に示す。
【０１７１】
図１６は、物流過程で現品札のバーコードが汚れたとき、協力企業Ｅ３のユーザＵ１が通信端末３１を用いて本社Ｅ１−０と通信し、当該バーコードを示す画像情報の配信を受ける様子を示している。
【０１７２】
また、図１７のフローチャートは、Ｓ４１〜Ｓ４７の各ステップを備えている。このうち、図１３と同じ符号Ｓ４１，Ｓ４２を付与した各ステップの処理は、図１３（第３の実施形態）と同じである。
【０１７３】
画像情報のためのデータ形式には様々なものがあり得るが、図１６の例ではＰＤＦ形式を用いている。ＰＤＦ形式は電子出版などにも利用される文書データフォーマットで、画像の表示にも利用できる。ＰＤＦ形式は、通常のＨＴＭＬなどより、はるかに高度な表現力を有し、詳細かつ忠実に、線や図の大きさ、アスペクト、位置、色を表示することができるため、ＰＤＦ形式で表示したバーコードの画像は、紙に印刷したバーコードの代替手段として機能し得る。
【０１７４】
ただしＰＤＦ形式の画像は、通常のＷｅｂブラウザＢ１の機能だけでは画面表示することができないため、特殊なブラウザ（ＰＤＦブラウザ）や、プラグインソフト（ヘルパーアプリケーション）などを活用する必要がある。プラグインソフトは、必要が生じたとき動的に鋼材調達サーバ３２などからネットワーク経由で通信端末３１に配信するようにしてもよいが、図１７の例では、予め通信端末３１にインストールしておき、ステップＳ４７で配信されたＰＤＦファイルを閲覧可能としている。
【０１７５】
ＰＤＦ形式で生成されるバーコード（ＰＤＦファイルに収容されている）は、予め前記ステップＳ４２で登録された入荷予報の内容などをもとに、ステップＳ４６でアプリケーションサーバ３３が生成したものである。
【０１７６】
協力企業Ｅ３側では、配信を受けたバーコードを示す画像を印刷出力して、印刷結果を鋼材ＭＴ１の束などに付加することが可能であるので、現品札の汚れなどにより、ステップＳ４５では実行できなかった受入処理などを、新たに付加したこのバーコードに基づいて実行することが可能である。
【０１７７】
なお、このようなバーコードを示す画像の配信は、協力企業Ｅ３のほか、サプライヤＥ２に対して行ってもよい。
【０１７８】
サプライヤＥ２が零細な企業で、自身でバーコード付きの現品札を作成することができない場合などでも、これによって、バーコード付きの現品札を有する鋼材ＭＴ１を配達すること等が可能となる。
【０１７９】
（Ｅ−２）第５の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることができる。
【０１８０】
加えて、本実施形態では、常に、バーコードを利用できる環境を提供し、受入処理や、在庫管理などの効率性を確保することが可能となる。
【０１８１】
（Ｆ）第６の実施形態
以下では、本実施形態が第１〜第５の実施形態と相違する点についてのみ説明する。
【０１８２】
１つの発注に対する配達は必ずしも１台のトラックで行われる保証はなく、物流の都合などで、複数のトラックに分けて配達されることも多い。
【０１８３】
例えば１０００ｋｇの鋼材ＭＴ１の供給を求める１つの発注に対し、本来、１つの注番に対応するこの注文（発注）を、サプライヤＥ２が５００ｋｇと、３００ｋｇと、２００ｋｇの３つの分番に分割し３台のトラックで配達してくる場合があるが、このようなケースでは、どの時点で配達の完了とみなすかが在庫管理などの観点で重要となる。
【０１８４】
サプライヤＥ２には最後の分番である２００ｋｇの入荷予報データに、最終分番マークを付けて送ってもらう運用とする。
分番という考え自体は従来から存在しているが、分番の振り方に確立されたルールがなかったために、各サプライヤで独自の振り方をしている。‘１’から順に振るところもあれば、一つ飛ばしで振るところもある。場合によってはランダムもあり得る。また、実際に配達されてくる順番も、最終分番マークが付いた分番が最後とは限らない。
そこで、本実施形態では、分番の数字は一切考慮せず、最終分番マーク付の分番を含んだ、全ての分番（その時点で送られて来ている入荷予報）が受け入れられた時点で完納とみなすことを特徴とする。
（Ｆ−１）第６の実施形態の構成および動作
本実施形態が第１の実施形態と相違するのは、鋼材調達システム２０の動作のみである。
【０１８５】
本実施形態の特徴動作は、図１８〜図２０に示す。
【０１８６】
図１９は、協力企業Ｅ３からの１つの発注（１つの注番）に対しサプライヤＥ２が３つの分番（「０１」，「０５」，「０３」）を振って３つの入荷予報を本社Ｅ１−０に送信し、３台のトラックＴＲ１１〜ＴＲ１３に分けて協力企業Ｅ３へ配達する様子を示している。
【０１８７】
図１８（Ａ）のステップＳ５０〜Ｓ５３もこれと同様な動作を示しており、上述したように、１つの発注に応じた１つの注文（１つの注番）を、３つの分番に分割し、分番ごとに別なトラックで配達している。
【０１８８】
例えば、１０００ｋｇの鋼材ＭＴ１は膨大な量であるので、３００ｋｇ、３００ｋｇ、４００ｋｇなどと、３つに分割したとしても、分割されたそれぞれもかなり膨大な量であって、例えば、図１８（Ｂ）に示すように、１本２ｋｇの棒状の鋼材ＭＴ１を１０本まとめた２０ｋｇの束がいくつも配達されることになり、各束ごとに、上述したバーコードを有する現品札が付加される。
【０１８９】
図２０のフローチャートは、Ｓ３１〜Ｓ５９の各ステップを備えている。
【０１９０】
ただし、すでに説明した各ステップと同じ符号Ｓ３１〜Ｓ３４，Ｓ４１，Ｓ４２，Ｓ４５を付与した各処理の内容はすでに説明したものと同じである。また、これらの符号と符号の末尾の「Ａ」や「Ｂ」の有無だけが相違する各符号Ｓ４１Ａ、Ｓ４１Ｂ、Ｓ４２Ａ、Ｓ４２Ｂは、末尾の「Ａ」や「Ｂ」のない対応する符号の各処理と実質的に同じである。
【０１９１】
すなわち、これらの各ステップにより、本社Ｅ１−０に発注依頼が行われ、１つの注番（ここでは、ＡＡＡＡＡ）を採番し、本社Ｅ１−０から発注がサプライヤＥ２へ中継され、サプライヤＥ２で、注番ＡＡＡＡＡが３つの分番０１，０３，０５に分割され、分番ごとに本社Ｅ１−０への入荷予報の送信が繰り返される。
【０１９２】
入荷予報をもとに、ある程度の予測を行うことは可能であるが、実際に各分番０１〜０５に対応する配達が、どのような順番で行われるかは、物流の都合で動的に決まり、正確に予測することは困難である。
【０１９３】
図２０の例では、分番０１の配達が最初に行われており、ステップＳ４５でその受入（着荷）が実行される。このとき、バーコードリーダ（ＢＣＲ）などを用いてその分番に対応する１または複数の鋼材ＭＴ１の束の現品札に表示されたバーコードの内容が協力企業Ｅ３から本社Ｅ１−０へ送信される（Ｓ５５）。これを受けて本社Ｅ１−０では、前記アプリケーションサーバ３３が、着荷された束を倉庫在庫として登録し（Ｓ５６）、前記受入処理の一部を実行する。
【０１９４】
同様な処理は、新たな分番の受入が行われるたびに、繰り返される（Ｓ４５Ａ、Ｓ５５Ａ、Ｓ５６Ａ、Ｓ４５Ｂ、Ｓ５５Ｂ、Ｓ５６Ｂ）。
【０１９５】
また、図２０では、ステップＳ５６の次のステップＳ５７（または、Ｓ５７Ａ、Ｓ５７Ｂ）で最終分番０５の受入が完了しているか否かを検査している。この検査で最終分番０５の受入が完了していることが確認されると、ステップＳ５８，Ｓ５８Ａに示すように、注番ＡＡＡＡＡに対応する全分番０１，０３，０５の受入が完了しているか否かを検査する。全分番０１，０３，０５の受入が完了したとの検査結果が出たとき、それまで発注残として登録していた注番ＡＡＡＡＡの発注を、完納として取り扱い、受入処理を完了する。
【０１９６】
なお、全分番０１，０３，０５の受入が完了したか否かの検査には、当然、最終分番である０５の受入が完了したか否かの検査が含まれる。分番０１，０３，０５のいずれか１つでも欠けた場合には、当然、受入処理が完了しないが、存在しないはずの分番が読み取られて送信されてきた場合には、何らかの誤りが発生したことを意味するので、別途、対応する必要がある。
【０１９７】
（Ｆ−２）第６の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることができる。
【０１９８】
加えて、本実施形態では、１つの発注に対する配達が複数台のトラックに分けて行われた場合にも、配達の完了を適切に検出することが可能となり、在庫管理などを適切に行うことが可能である。
【０１９９】
これによって、例えば、納期が経過したにもかかわらず、全分番の配達が完了していないときには、サプライヤ（Ｅ２）に配達の催促を行うこと等も可能となる。
【０２００】
（Ｇ）第７の実施形態
以下では、本実施形態が第１〜第６の実施形態と相違する点についてのみ説明する。
【０２０１】
上述したように、鋼材ＭＴ１には棒状や板状、輪状のものがあり、それぞれに材質やサイズといった属性がある。発注の単位も、１ｔ（１０００ｋｇ）とか１０ｔ（１００００ｋｇ）といった単位であり、これだけの重量のものを誤差なく揃える事は現実の作業効率などを考えると不可能である。１０００ｋｇの発注であっても、どうしても９８０ｋｇとか１０１０ｋｇという納入量になってしまう。１０００ｋｇの発注に対して、何ｋｇを納入するかは、従来は、サプライヤの判断にまかされていた。
しかしながら、協力企業Ｅ３や本社Ｅ１−０などの立場からすると、発注量に比べてあまりにも多い量を納入されることは不利益につながる。納入量が多すぎれば在庫削減にならないだけでなく、サプライヤへの支払いも増えるからである。  そこで、本実施形態では、サプライヤから送られてくる入荷予報に設定されている納入量を用いて、過剰納入を抑制する。
【０２０２】
（Ｇ−１）第７の実施形態の構成および動作
本実施形態が第１の実施形態と相違するのは、鋼材調達システム２０の動作のみである。
【０２０３】
本実施形態の特徴動作は、図２１および図２２に示す。
【０２０４】
図２１は、１つの発注に対する受注を行ったサプライヤＥ２が、その１つの注番を複数の分番に分割し、分番ごとに、入荷予報を本社Ｅ１−０に送信してくるとき、３つ目までの分番に対応する入荷予報の納入量を合計したものは、ほぼ発注量に対応する範囲（発注量未満または、発注量を越えているが許容できる範囲）内にあるが、４つ目の入荷予報の納入量をこれら３つの納入量と合計すると、その合計値が許容できる範囲を越えるケースでは、協力企業Ｅ３が４つ目の入荷予報を否認できることを示している。４つ目の入荷予報を協力企業Ｅ３が否認した場合、本社Ｅ１−０は、４つ目の入荷予報の最終的な受付を拒否することができる。
【０２０５】
図２２のフローチャートは、Ｓ３１〜Ｓ６２の各ステップから構成されている。
【０２０６】
このうち、すでに説明したものと同じ符号Ｓ３１，Ｓ３２，Ｓ３３，Ｓ３４、Ｓ４１，Ｓ４２を付与した各ステップの処理内容は、すでに説明したものと同じである。
【０２０７】
また、符号の末尾に「Ｃ」などのアルファベットを付与する場合の規則も、すでに説明した図２０などと同じで、実質的に、同じ処理を異なるデータに対して施す場合、各処理を区別するために末尾にアルファベットを付与している。
【０２０８】
図２２の例では、発注量１０００ｋｇの１つの発注に対する注番ＡＡＡＡＡを、サプライヤＥ２が４つの分番０１，０２，０３，０４に分割している。そして、分番０１に対応する納入量は２００ｋｇであり、分番０２に対応する納入量は３３０ｋｇであり、分番０３に対応する納入量は３８０ｋｇであり、分番０４に対応する納入量は６００ｋｇである。
【０２０９】
したがって、ステップＳ４２Ｄまでに本社Ｅ１−０に届いた各分番の入荷予報の納入量を合計すると、９１０ｋｇで、発注量の１０００ｋｇをやや下回る程度であるが、これに４つ目の分番０４の入荷予報の納入量を加えると、１５１０ｋｇとなって、発注量を大幅に上回ってしまう。
【０２１０】
アプリケーションサーバ３３は、このような各入荷予報の納入量の合計の算出や、算出結果と発注量の比較などを実行することで、４つ目の分番に対応する入荷予報を登録するステップＳ４２Ｅの処理では、他のステップＳ４２、Ｓ４２Ｃ、Ｓ４２Ｄと異なり、単に、入荷予報を登録するだけでなく、過剰納入を示すフラグを付けた上でデータベース３５に対する当該入荷予報の登録を行うことができる。
【０２１１】
ただし過剰納入か否かの判断にあたっては、あまり厳格に判断せず、所定のしきい値ＴＨ１を越えない範囲の過剰であれば、過剰納入とみなさないようにすることが望ましい。例えば１０００ｋｇの発注量に対し、合計の納入量が１００１ｋｇとなった場合にまで過剰とみなしたのでは、これまでの鋼材の供給に関する慣例に照らしてサプライヤＥ２側に過酷すぎる結果となる可能性が高いからである。
【０２１２】
しきい値ＴＨ１はどのような値に設定することも可能であるが、例えば、発注量に対して所定の割合となるように設定することもできる。また、その割合を発注量に応じて変化させ、例えば次のように、発注量が小さいほど大きな割合まで許容するようにすることも望ましい。発注量が小さければ割合が大きくてもそれほど大きな量にはならないからである。
【０２１３】
発注量が１ｔ（１０００ｋｇ）未満：入荷予報量は発注量の２００％までを正常に受付可能とする。
発注量  １ｔ（１０００ｋｇ）以上、１０ｔ（１００００ｋｇ）未満：入荷予報量は発注量の１５０％までを正常に受付可能とする。
発注量  １０ｔ（１００００ｋｇ）以上：入荷予報量は発注量の１２０％までを正常に受付可能とする。
過剰納入のフラグが付いた入荷予報が受付られデータベース３５に登録された場合、協力企業Ｅ３のユーザＵ１は、通信端末３１を用いて本社Ｅ１−０の鋼材調達サーバ３２にアクセスすることにより、４つ目の分番に対応する入荷予報が登録されたことや、その入荷予報に、過剰納入を示すフラグが付与されていることを認識することができる。したがってユーザＵ１は、ステップＳ６１で、その入荷予報に対応する入荷（納入）を承認するか否認するかを判断し、判断結果に応じて、Ｗｅｂページ上の対話部品を操作すること等により、前記過剰納入フラグをＯＦＦすること等も可能となる（Ｓ６２）。
【０２１４】
ここで、過剰納入フラグのＯＦＦは、承認の意思表示である。
【０２１５】
なお、ＷｅｂブラウザＢ１によるＷｅｂサーバ（ここでは、鋼材調達サーバ３２）との通信はプル型であり、ユーザＵ１側からアクセスしない限り、何の情報も鋼材調達サーバ３２からＷｅｂブラウザ側へ届けることはできない。したがって、ユーザＵ１が鋼材調達サーバ３２にアクセスしてこなければ、ユーザＵ１の意思（承認、否認の意思）を確認することもできない。ユーザＵ１の意思が確認できない場合にどのような取り扱いを行うかは、予め決めておくとよいが、できれば速やかに意思確認を行い、その結果に応じた取り扱いを行うことが好ましい。
【０２１６】
そのために必要ならば、電子メールなどのプッシュ型の通信手段を利用することも望ましい。
【０２１７】
すなわち、協力企業Ｅ３宛ての納入に関し、過剰納入フラグ付きの入荷予報がデータベース３５に登録されたことを伝える電子メールを、例えば、ユーザＵ１が携帯する携帯電話機やＰＨＳ端末などの携帯通信端末へ宛てて送信するようにすれば、ユーザＵ１がどこにいても、即座に、前記ステップＳ６１のような意思表示の必要性を認識させることができるため、速やかな意思確認を実現することが可能である。
【０２１８】
なお、図２２のステップＳ４１Ｅに示すように、分番０４の入荷予報には最終分番マーク（最終マーク）が付与されているため、否認の場合には、分番０３の入荷予報などへ最終分番マークを付与し直す必要がある。
【０２１９】
（Ｇ−２）第７の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることができる。
【０２２０】
加えて、本実施形態では、サプライヤ（Ｅ２）から送られてくる入荷予報に設定されている納入量を用いて、協力企業（Ｅ３）側の意思を確認し、鋼材（ＭＴ１）の過剰納入を抑制することが可能となる。
【０２２１】
（Ｈ）第８の実施形態
以下では、本実施形態が第１〜第７の実施形態と相違する点についてのみ説明する。
【０２２２】
第７の実施形態で対応した過剰納入と反対に、発注量に対して、納入量の合計が少なすぎる過少納入に対しても対策を講じる必要がある。発注量に対して、あまりにも少ない量の納入では生産業務に支障を起こしてしまうからである。
【０２２３】
ところが、過剰納入の場合と異なり、過少納入の場合には入荷予報の納入量の合計を用いて対応することは困難である。完納済み状態（受入処理の完了した状態）となるまで、入荷予報は随時受け付け可能であるため、判断時点、すなわち、どの時点で過少かどうかの判断を行うかが問題となるからである。例えば、ある時点で過少であっても、続きの分番の入荷予報が送られてきて過少ではなくなることが起こり得るからである。
【０２２４】
そこで、本実施形態では、最終分番マーク付の分番を受け入れた時点で、既に入荷予報を受け付けている全ての分番も受け入れ済みであれば、その時点を判断時点（本来は、この時点で完納とされる）として過少か否かの判断を行うことを特徴とする。
【０２２５】
この判断の結果、過少であるとされた場合、この判断時点の状態を完納とはみなさず、入荷予報の追加を許容する。その一方で、サプライヤに対し追加の納入の催促などを行えば、確実に、過少納入を防止することが可能となる。
【０２２６】
（Ｈ−１）第８の実施形態の構成および動作
本実施形態が第１の実施形態と相違するのは、鋼材調達システム２０の動作のみである。
【０２２７】
本実施形態の特徴動作は、図２３および図２４に示す。
【０２２８】
図２３は、最終分番マーク付の分番を受け入れた時点で、既に入荷予報を受け付けている全ての分番も受け入れ済みであれば、その時点を判断時点として過少か否かの判断を行い、判断結果が過少であれば、それ以後も、サプライヤＥ２から本社Ｅ１−０への入荷予報の登録の受付が可能な状態を維持することを示している。
【０２２９】
また、図２４のフローチャートは、Ｓ３１〜Ｓ６６の各ステップから構成されている。
【０２３０】
このうち、すでに説明したものと同じ符号Ｓ３１，Ｓ３２，Ｓ３３，Ｓ３４、Ｓ４１，Ｓ４２、Ｓ４５，Ｓ５５，Ｓ５６，Ｓ５９を付与した各ステップの処理内容は、すでに説明したものと同じである。
【０２３１】
また、符号の末尾に「Ｃ」などのアルファベットを付与する場合の規則も、すでに説明した図２０などと同じで、実質的に、同じ処理を異なるデータに対して施す場合、各処理を区別するために末尾にアルファベットを付与している。
【０２３２】
図２４において、ステップＳ５５で、協力企業Ｅ３からバーコードリーダ（ＢＣＲ）などを用いてその分番に対応する１または複数の鋼材ＭＴ１の束の現品札に表示されたバーコードの内容が協力企業Ｅ３から本社Ｅ１−０へ送信されると、これを受信した本社Ｅ１−０では、前記アプリケーションサーバ３３が、着荷された束を倉庫在庫として登録し（Ｓ５６）、前記受入処理の一部を行うが、そのあと、本実施形態に特徴的なステップＳ６５の処理が行われる。
【０２３３】
ステップＳ６５では、そのステップＳ５５で送信されてきたバーコードの内容が最終分番に対応するものであるか否かが検査されるとともに、既に入荷予報を受け付けている全分番の受入が完了しているか否かを検査する。この２つの検査の結果がともに、肯定的なもの（ＯＫ）であれば、２つの検査の完了時点が、前記判断時点とされ、過少納入か否かを判断する。
【０２３４】
図２４の例の場合、ステップＳ３１の発注量が１０００ｋｇであるのに対し、ステップＳ４１にかかる分番０１の入荷予報の納入量（重量）が２００ｋｇ、ステップＳ４１Ｆにかかる分番０２の入荷予報の納入量が３００ｋｇ、ステップＳ４１Ｇにかかる分番０３の入荷予報の納入量が３５０ｋｇであるため、これらの合計は、８５０（＝２００＋３００＋３５０）ｋｇとなる。
【０２３５】
過少の判断にあたっても、第７の実施形態で行った過剰か否かの判断の場合と同様、所定のしきい値ＴＨ２を設定して、発注量に不足していても、その不足分（の絶対値）がわずかであって、このしきい値ＴＨ２（の絶対値）より小さい場合には、過少とみなさないようにすることが望ましい。
【０２３６】
また、このしきい値ＴＨ２についても、第７の実施形態のしきい値ＴＨ１と同様、どのような値に設定することも可能であるが、例えば、発注量に対して所定の割合となるように設定することも望ましい。これにより、例えば、受入量が発注量の９０％に満たない場合、過少納入と判断することも可能となる。
【０２３７】
しきい値ＴＨ２を利用して判断する場合、１０００ｋｇに対する８５０ｋｇが過少であるか否かは、予め設定するしきい値ＴＨ２の値に応じて異なってくるが、しきい値ＴＨ２を発注量の９０％を指すように設定した場合には、９００ｋｇ以下を過少と判断するため、当該８５０ｋｇは過少に該当する。
【０２３８】
このようにして過少と判断したため、図２４のステップＳ６６では、いま注目している注番ＡＡＡＡＡの発注は発注残とし、まだ完納されていないものとして処理している。発注残の状態にある限り、サプライヤＥ２は、追加の入荷予報を本社Ｅ１−０に送信することが可能である。
【０２３９】
ただしこれだけでは、追加の入荷予報が実際に本社Ｅ１−０に送信される保証はないから、例えばアプリケーションサーバ３３の判断で、サプライヤＥ２（または、サプライヤシステム３７）に対してホスト３６経由の催促を行い、確実に追加の入荷予報を送信させるようにすることも望ましい。
【０２４０】
図２４の例では、ステップＳ６６のあと、ステップＳ４１Ｈ、Ｓ４２Ｈで、サプライヤＥ２からの追加の入荷予報（分番０４）が届き、ステップＳ４５Ｃ、Ｓ５５Ｃ、Ｓ５６Ｃで協力企業Ｅ３によるその分番０４を付加された鋼材ＭＴ１の受入と、その現品札のバーコードが示す内容の本社Ｅ１−０への通知と、受入れられた分の倉庫在庫への登録が行われている。
【０２４１】
ステップＳ５６Ｃにつづいて、前記ステップＳ６５と同じ内容のステップＳ６５Ａが実行される。当該分番０４の納入量は１００ｋｇであるので、前記８５０ｋｇと合わせて９５０ｋｇとなる。これでも発注量の１０００ｋｇに対して５０ｋｇ不足しているが、前記しきい値ＴＨ２が指す９００ｋｇを越えているので、過少とはみなされず、ステップＳ５９で当該注番ＡＡＡＡＡを完納としている。
【０２４２】
（Ｈ−２）第８の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることができる。
【０２４３】
加えて、本実施形態では、過少納入を防止することが可能となる。
【０２４４】
（Ｉ）第９の実施形態
以下では、本実施形態が第１〜第８の実施形態と相違する点についてのみ説明する。
【０２４５】
鋼材調達システム２０内部での鋼材ＭＴ１の管理単位は基本的に重量（ｋｇ）であり、本社Ｅ１−０，親工場Ｅ１−１，サプライヤＥ２では重量が利用され、サプライヤへの支払も重量できまる。
【０２４６】
ところが、協力企業Ｅ３側で倉庫からの払い出しを行うときの単位（払い出し用単位）には、通常、重量は用いられない。例えば、鋼材ＭＴ１が棒状の鋼材の場合には、本数などを単位として払い出しを行っている。また、１本の鋼材の一部を切断して払い出した場合には、長さ（ｍなど）が払い出し単位とされ、板状の鋼材などでは、枚数が払い出し単位とされる。
【０２４７】
協力企業Ｅ３の内部でも管理単位として重量が使用されることはあり得るが、少なくとも払い出しに際しては、重量ではなく、本数などの払い出し単位を用いるほうがはるかに効率的である。鋼材ＭＴ１を払い出すたび、逐一、その重量を工場の作業者に計測させるのは、作業効率を著しく低下させ、非現実的だからである。
【０２４８】
しかしながらその一方で、協力企業Ｅ３における鋼材ＭＴ１の在庫を正確に管理するためには、払い出されていない鋼材ＭＴ１に関する倉庫在庫と、払い出された鋼材ＭＴ１に関する仕掛在庫を明確に区別することが求められることが少なくない。
【０２４９】
そこで、本実施形態では、払い出し用単位を重量に変換して、より正確な在庫管理を行うことを特徴とする。
【０２５０】
この変換にあたっては、鋼材マスタのなかの単重と呼ばれる情報を利用する。
【０２５１】
単重とは例えば、Ａという鋼材は長さが単位であり１ｍあたり１０ｋｇであるとか、Ｂという鋼材は本数が単位で１本あたり２０ｋｇであるという情報である。  このような単重を含む鋼材マスタは、前記データベース３５のなかに登録されている。
【０２５２】
（Ｉ−１）第９の実施形態の構成および動作
本実施形態が第１の実施形態と相違するのは、鋼材調達システム２０の動作のみである。
【０２５３】
本実施形態の特徴動作は、図２５および図２６に示す。
【０２５４】
図２５は、予め親工場が本社Ｅ１−０のデータベース３５に含まれる鋼材マスタに単重を登録しておくと、協力企業Ｅ３で鋼材ＭＴ１の倉庫からの払い出しが行われたとき、その払い出しの量が、前記払い出し単位で協力企業Ｅ３から本社Ｅ１−０へ伝えられ、本社Ｅ１−０内では、当該払い出し単位を重量に換算して、重量に基づいた正確な在庫管理を行う様子を示している。
【０２５５】
この間の動作の詳細は、図２６のフローチャートに示す通りである。図２６のフローチャートは、Ｓ７０〜Ｓ７５の各ステップから構成されている。
【０２５６】
図２６において、親工場のユーザＵ０が通信端末３０を用いて、鋼材ＭＴ１の基本属性（前記単重も含む）を鋼材調達サーバ３２に送信すると（Ｓ７０）、前記アプリケーションサーバ３３はデータベースサーバ３４を介して、前記データベース３５内の鋼材マスタにその基本属性を登録する（Ｓ７１）。
【０２５７】
ここでは、親工場Ｅ１−１から単重などの基本属性を登録しているが、十分な信憑性のある情報である限り、基本属性はどこから登録されてたものであってもかまわない。例えば、本社、サプライヤ、協力企業などからの登録であってもよい。
【０２５８】
このような単重が登録されたあとで、協力企業Ｅ３で鋼材ＭＴ１の倉庫からの払い出しが行われると、例えば、ステップＳ７２のようにバーコードリーダで払い出した鋼材ＭＴ１のバーコードを読み取ったり、ステップＳ７４のようにＷｅｂブラウザで閲覧中の所定のＷｅｂページへ入力を行ったりすることで、前記払い出し単位によって払い出し量が本社Ｅ１−０へ伝えられる。
【０２５９】
これを受けて本社Ｅ１−０では、前記アプリケーションサーバ３３などが、当該払い出し単位を重量に換算した上で、協力企業Ｅ３の倉庫在庫からその重量を差し引く（Ｓ７３，Ｓ７５）。例えば、鋼材マスタに１ｍあたり１０ｋｇと登録されている場合、１．５ｍを払い出すと倉庫在庫から“１０ｋｇ／ｍ  ×１．５ｍ  ＝  １５ｋｇ”が差し引かれることになる。
【０２６０】
これにより、従来よりも正確な在庫管理をほぼリアルタイムで行うことが可能になる。
【０２６１】
また、ステップＳ７４に先だって行われるユーザＵ１によるＷｅｂページへの入力でも、協力企業Ｅ３における払い出し単位をそのまま利用することができるため、協力企業Ｅ３側の負担は小さい。
【０２６２】
なお、払い出し単位を単重を用いて重量に換算する方法では、誤差が生じることが避けられない。例えば、実際の倉庫からは該当鋼材ＭＴ１は全て払い出されたとしても、システム上は数ｋｇ残っているという矛盾が発生する可能性がある。
【０２６３】
このような矛盾は、定期的な棚卸しで解消することもできるが、払い出し単位に‘全数’という単位も用意して、該当鋼材ＭＴ１の残り全てを払い出す時に活用することによっても、解消することができる。
【０２６４】
（Ｉ−２）第９の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることができる。
【０２６５】
加えて、本実施形態では、正確な在庫管理を効率的に実現することが可能になる。
【０２６６】
（Ｊ）第１０の実施形態
以下では、本実施形態が第１〜第９の実施形態と相違する点についてのみ説明する。
【０２６７】
第９の実施形態では協力企業Ｅ３における倉庫在庫の管理を正確に行うことができるが、前記仕掛在庫のほうも、正確に管理することが望ましい。
【０２６８】
倉庫在庫と異なり、仕掛在庫のなかには、様々な状態のものが含まれる。倉庫から払い出された鋼材ＭＴ１がすべて仕掛在庫に分類されるものとすると、仕掛在庫のなかには、生産ラインで加工されている途中の中間品、払い出されたもののまだ生産ラインで加工されていないもの、加工が完了し、部品ＰＴ１となっているが出荷されていないもの、すでに出荷されたものが含まれることになる。
【０２６９】
例えば、１００ｋｇの鋼材ＭＴ１が払い出されたとしても、その１００ｋｇを利用して一つの製品（部品）を加工する訳ではなく、通常は、複数種類の鋼材ＭＴ１を少しずつ使用して多種、多量の部品に加工するため、工場の生産ライン上にどれだけの鋼材ＭＴ１が存在しているのか、追跡することは困難である。
【０２７０】
仕掛在庫を、より詳細に管理できれば、様々な利点が得られる可能性がある。
【０２７１】
そこで、本実施形態では、出荷管理システムが提供する情報（部品ＰＴ１の出荷量）と、部品マスタの情報（部品ＰＴ１を１つ製造するために消費される鋼材ＭＴ１の量）を利用して、仕掛在庫の管理の詳細化をはかることを特徴とする。これによって少なくとも、すでに出荷されたものと、それ以外のものを区別することができるようになる。
【０２７２】
出荷管理システムとは、協力企業Ｅ３から親工場Ｅ１−１への部品ＰＴ１の出荷を管理しているシステムで、部品の出荷量を提供する能力を有する。
【０２７３】
部品マスタとは、上述した鋼材マスタと同様に、前記データベース３５のなかに登録されており、部品に関する情報を管理している。部品マスタから、部品ＰＴ１を１つ製造するために消費される鋼材ＭＴ１の量を得ることができる。
【０２７４】
（Ｊ−１）第１０の実施形態の構成および動作
本実施形態が第１の実施形態と相違するのは、鋼材調達システム２０の動作のみである。
【０２７５】
本実施形態の特徴動作は、図２７および図２８に示す。
【０２７６】
図２７は、協力企業Ｅ３がサプライヤＥ２から供給された鋼材ＭＴ１を倉庫に受け入れたあと、部品ＰＴ１を生産するために倉庫から払い出し、生産ラインで部品ＰＴ１に加工したあと出荷する一連の流れのなかで、倉庫に保存されている鋼材ＭＴ１は倉庫在庫に分類され、倉庫から払い出された鋼材ＭＴ１が仕掛在庫に分類されることを示している。
【０２７７】
図２８のフローチャートは、Ｓ４５〜Ｓ８６の各ステップから構成されている。
【０２７８】
このうち、すでに説明したものと同じ符号Ｓ４５，Ｓ５５，Ｓ５６，Ｓ２０を付与した各ステップの処理内容は、すでに説明したものと同じである。
【０２７９】
図２８のステップＳ８０では、協力企業Ｅ３において、倉庫から鋼材ＭＴ１を払い出すとき、前記バーコードリーダやＷｅｂブラウザを用いてその払い出しに関する情報を本社Ｅ１−０へ送信している（Ｓ８０，Ｓ８１）。この情報には少なくとも、払い出された鋼材ＭＴ１の種類や量を示す情報が含まれており、本社Ｅ１−０のアプリケーションサーバ３３は、データベースサーバ３４を介して当該鋼材ＭＴ１の当該量を、倉庫在庫から差し引く。このあと、当該鋼材ＭＴ１の当該量は、仕掛在庫に登録される。
【０２８０】
当該鋼材ＭＴ１が協力企業Ｅ３内で部品ＰＴ１に加工されると、親工場Ｅ１−１へ出荷される（Ｓ２０）。この出荷に際して、協力企業Ｅ３から本社Ｅ１−０の前記出荷管理システムに出荷された部品の量が登録される（Ｓ８４）。部品の量は様々な単位で表現され得るが、図２８の例では、個数で表現されており、１０００個の部品ＰＴ１が出荷されている。
【０２８１】
この１０００個を示す情報は、本社Ｅ１−０の内部において、出荷管理システムから鋼材調達システムへ渡される。具体的には、例えば、前記アプリケーションサーバ３３がデータベース３５の登録内容を書き換えることによって、このような受け渡しを行うことができる。
【０２８２】
当該１０００個をもとに、１０００個の部品ＰＴ１を生産するために消費された鋼材ＭＴ１の量を算出するのは、出荷管理システム側で行うものであってもよいが、ここでは、鋼材調達システム（例えば、アプリケーションサーバ３３）側で行っている。図示したように、算出された鋼材ＭＴ１の消費量が例えば７００ｋｇであれば、前記ステップＳ８０で倉庫から払い出した１０００ｋｇから当該７００ｋｇを差し引いて得られる、３００ｋｇが、すでに出荷されたものを除いた仕掛在庫であると分かる。
【０２８３】
協力企業Ｅ３内で生産管理システムが導入されている場合には、さらに詳細に、上述した生産ラインで加工されている途中の中間品、払い出されたもののまだ生産ラインで加工されていないもの、加工が完了し、部品ＰＴ１となっているが出荷されていないものを区別することもできるが、本実施形態では、生産管理システムが導入されていなくても、仕掛在庫の内部で、出荷された部品ＰＴ１とそれ以外のものを区別することが可能である。
【０２８４】
（Ｊ−２）第１０の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることができる。
【０２８５】
加えて、本実施形態では、少なくとも、すでに出荷されたものと、それ以外のものを区別することができるため、仕掛在庫の在庫管理を、より詳細に行うことが可能になる。
【０２８６】
（Ｋ）他の実施形態
上記第９の実施形態では鋼材マスタを利用したが、鋼材マスタには、前記単重以外にも様々なデータ項目が用意されている。また鋼材マスタのデータ項目の重要度は一様ではない。重要度が高く、鋼材調達システム２０で鋼材を取り扱うために必須のデータ項目（必須データ項目）もあれば、重要度が低く、無くても鋼材の取り扱いを行うことのできるデータ項目（非必須データ項目）もある。新たな鋼材の取り扱いを開始するにはその鋼材に関する鋼材マスタの各データ項目のうち少なくとも必須データ項目の情報を登録することが不可欠である。
【０２８７】
しかしながら、各データ項目ごとに鋼材に関するその情報を知り得る主体（あるいは、決定すべき主体）が異なることが多いため、鋼材マスタを直接、管理している本社Ｅ１−０だけですべての必須データ項目の情報を得られるとは限らない。通常、例えば“鋼材Ｎｏ”は本社が採番すべき項目であり、“発注方式”は親工場や協力企業が判断して決定すべきである。“納入リードタイム”はサプライヤでなければ判断できない。
【０２８８】
このため、データ項目ごとにその情報を登録すべき主体を決めておくようにすることも望ましい。
【０２８９】
これにより、鋼材マスタのデータ項目を速やかに登録し、速やかに新たな鋼材の取り扱いを開始することが可能となる。
図２９は、鋼材マスタを示すテーブルＴＢ１の各データ項目の情報を異なる主体（本社、親工場、協力企業、サプライヤ）が登録し、ある鋼材（例えば、鋼材名ＡＡＡの鋼材）について、必須データ項目の登録が完了したと本社Ｅ１−０が判断した時点から、鋼材調達システム２０の内部でその鋼材の取り扱いを開始する様子を示している。
【０２９０】
図２９のテーブルＴＢ１には、各主体による情報の登録が完了したか否かを管理するためのデータ項目（協力企業を指す「協」、親工場を指す「親」、サプライヤを指す「サ」）が用意されており、本社が必須データ項目の登録が完了したか否かを判断することを容易にしている。
【０２９１】
この様子は、図３０のフローチャートのＳ９０〜Ｓ９５の各ステップにも示されている。
【０２９２】
ステップＳ９０で本社Ｅ１−０が取り扱いを決めた新たな鋼材につき、本社（Ｓ９１），親工場（Ｓ９２）、協力企業（Ｓ９３）、サプライヤ（Ｓ９４）の各主体による情報の登録が完了したら、本社Ｅ１−０が、その鋼材のステータスを「準備中」から「開始」に変更して鋼材調達システム２０の内部でその鋼材の取り扱いを開始する（Ｓ９５）。運用開始時には、単に鋼材マスタのステータスを‘開始’とするだけでなく、運用に必要となる各種データの作成等の初期処理が実行される。
【０２９３】
図３０の例では、各主体が必要な情報を登録するときにも、本社がステータスを変更するときにも、Ｗｅｂブラウザを使用している。
【０２９４】
この場合、鋼材マスタを含むテーブルＴＢ１内に、各担当（各主体）毎の‘済み’フラグを持っている訳ではなく、各担当が登録すべき前記必須データ項目の情報が登録されていれば、画面上に“済”を表示するものであってよい。
【０２９５】
全てが“済”になった時点で、自動的に運用開始としないのは、属性登録完了時点と運用開始時点が同一とは限らないからである。従来は本社が各所から情報を集め、一括して登録していたが、これにより、外部との共同作業が可能となる。またマスタ登録作業の効率を高め、ボトルネックを見分けることも可能となる。
【０２９６】
一方、一般的なクライアントサーバシステムでは、画面表示からデータ更新までを、一体不可分な１つのトランザクションとして制御することも可能であるが、Ｗｅｂサーバは同時に複数の要求を受け取った場合には同時に複数の要求を処理して応答を返す構成となっているため、Ｗｅｂでは通常、画面表示とデータ更新は一体不可分な１つのトランザクションではない。したがって、例えば、前記通信端末（例えば、３１など）の表示部５４における画面表示と、その画面表示（Ｗｅｂページ）を利用して各ユーザ（例えば、Ｕ１）が行うデータベース３５のデータ更新とのあいだに他のユーザ（例えば、Ｕ０）によるデータ更新が行われる可能性がある。これによって、多くのユーザが同一のデータベース３５に登録された情報を同時に共用することも可能になる利点がある反面、データの一貫性を損ない矛盾が生じる原因ともなり得る。
【０２９７】
例えば、共同で行う前記鋼材マスタなどのマスタ登録の場合、ある時期に担当者Ａと担当者Ｂが同時に同じマスタデータを表示し、担当者Ａと担当者Ｂがそれぞれの設定を行いデータ更新を行おうとすると、データベース３５に反映されるのは後から更新を行った方だけとなる。
【０２９８】
後から更新を行った方だけが最終的なデータベース３５の内容に反映されてもレコードなどに関して情報（データ）の一貫性が維持されていれば、それ自体は特に問題ではないが、例えば、１つのレコードで、データ項目ＤＡ１とデータ項目ＤＡ２の情報のあいだに所定の関係が成立しなければならないようなケースにおいて、担当者Ａがデータ項目ＤＡ１の情報を変更し、担当者Ｂがデータ項目ＤＡ２の情報を変更した結果として、データ項目ＤＡ１とＤＡ２の情報のあいだに前記関係が成立しなくなって一貫性が失われる場合などには、問題である。
【０２９９】
画面表示とデータ更新が１つのトランザクションでなく、データベースサーバ３４の持つトランザクション制御機能を利用できない以上、前記アプリケーションサーバ３３が搭載するアプリケーションソフトＡＰ１の機能で、この問題に対処しなければならない。
【０３００】
アプリケーションソフトＡＰ１の機能を利用してこの問題に対応する方法には様々なものがあり、例えば、アクセス制御によって、特定のレコード、あるいは特定のデータ項目の情報に関する更新（書き込み）の権限を一人の担当者（例えば、前記“発注方式”については、協力企業Ｅ３の担当者Ｕ１）だけに認め、別な担当者がアクセス権限を持つデータ項目のあいだには特別な関係が生じないようにスキーマを定義しておくことによってもこの問題に対応することは可能であるが、ここでは、特定のデータ項目の情報に関するアクセス権限を一人に限定すること等は行わず、データベース３５に格納されている情報を画面表示するとき、その時点のデータベース３５の情報を全てメモリ上に保持しておき、データ更新時にデータベース３５の情報と、メモリに保持しておいた情報を比較し、同一の場合にのみ、その更新を許すようにする。
【０３０１】
ただしこの方法では、複数人が同時に利用し、なおかつ、画面に大量の情報が表示される可能性がある場合、その情報を全てメモリに保持しておくことは記憶資源が限られている点を考慮すると実行困難となる可能性がある。
そこで、データベース３５に含まれる各テーブル（例えば、ＴＢ１）の全レコードに、データ項目の１つとして排他用のカウンタ項目を付加し、更新毎にカウントアップしていくことで対応するものとする。この方法では、前記全情報のかわりに、当該カウンタ項目の情報をメモリ上に保持し、画面表示時とデータ更新時でカウンタ項目の情報（カウント値）が変化していない場合にのみ、データの更新を許容する。これにより、例えば、図３１の例のように、ユーザＡとユーザＢが各自の通信端末のＷｅｂブラウザを用いて、ほぼ同時に同じ情報（ここでは、ａｂｃ）を閲覧し始め、ユーザＢが先にデータ更新を要求し、ユーザＡが後からデータ更新を要求すると、ユーザＢによる先のデータ更新（ａｂｃをｘｙｚに更新）では、その時点のデータベース３５の該当レコードのカウント値は「１」のままでメモリ上に保持されている値「１」と同じであるため、当該データ更新が許可され、後からユーザＡが要求するデータ更新（ａｂｃを１２３に更新）は、その時点ではすでにデータベース３５の該当レコードのカウント値は「２」になっていて、メモリ上のカウント値「１」と異なるため、許可されない。
【０３０２】
これにより、メモリの記憶資源を大幅に節約することができる。
【０３０３】
なお、当該排他カウンタをカウントアップする機能を、アプリケーションソフトＡＰ１の替わりに、データベースサーバ３４に搭載される前記ＤＢＭＳ１に持たせることも好ましい。
【０３０４】
この場合、データベースサーバ３４自体がカウントアップを行うため、アプリケーションサーバ３３を経由しないデータベースアクセスが起こりうるシステム構成を取る場合などにも有効である。
【０３０５】
なお、当該カウントアップは、カウントダウンに置換可能であることは当然である。また、同時にアクセスしている複数のユーザ（例えば、Ａ、Ｂ）のなかで先にデータ更新を要求した一人にのみ、更新を許すには、単純にフラグを利用するだけでもよい。例えば、未更新を示すフラグの状態を「０」、更新済みを示すフラグの状態を「１」とすると、フラグの状態が「０」である場合にのみデータ更新を許し、フラグの状態が「１」に変わったあとではデータ更新を許さない構成とする。同時にアクセスしていた全ユーザ（例えば、ＡおよびＢ）のアクセスが終了したあと、新たなデータベースアクセスが発生して当該レコードが読み出された場合には、このフラグの状態を再び「０」にリセットして同様な処理を行えばよい。
【０３０６】
上記第１〜第１０の実施形態の特徴は、相互に矛盾しない限り、１つの鋼材調達システム上で組み合わせて用いてもよいことは当然である。
【０３０７】
また、鋼材以外の原材料を調達する場合にも本発明を適用できることは当然である。
【０３０８】
さらに、上記第１〜第１０の実施形態では、参加企業が限定されているクローズ形式のＥＣシステムに本発明を適用したが、本発明は、参加企業が限定されないオープン形式のＥＣシステムにも適用可能である。システム中で入札などが行われ得るものが、オープン形式のＥＣシステムの例である。
【０３０９】
なお、上記第１〜第１０の実施形態では、複数の企業間で電子商取引を行う場合を例に説明したが、本発明は、単一の企業の内部で行う生産管理などに適用してもよいことは当然である。
【０３１０】
以上の説明では主としてソフトウエア的に本発明を実現したが、本発明はハードウエア的に実現することも可能である。
【０３１１】
【発明の効果】
以上に説明したように、本発明の原材料調達システムおよび方法によれば、原材料の在庫の低減と効率的な安定運用を実現することが可能となる。
【図面の簡単な説明】
【図１】第１〜第１０の実施形態に係る鋼材調達システムの全体構成例および動作例を示す概略図である。
【図２】従来の鋼材調達システムの全体構成および動作を示す概略図である。
【図３】第１〜第１０の実施形態に係る鋼材調達システムの全体構成例を示す概略図である。
【図４】第１〜第１０の実施形態に係る鋼材調達システムの全体構成に関する変形例を示す概略図である。
【図５】第１〜第１０の実施形態で使用する鋼材調達サーバの内部構成例を示す概略図である。
【図６】第１〜第１０の実施形態で使用する通信端末の内部構成例を示す概略図である。
【図７】第１の実施形態の動作説明図である。
【図８】第１の実施形態の動作説明図である。
【図９】第１の実施形態の動作説明図である。
【図１０】第２の実施形態の動作説明図である。
【図１１】第２の実施形態の動作説明図である。
【図１２】第３の実施形態の動作説明図である。
【図１３】第３の実施形態の動作説明図である。
【図１４】第４の実施形態の動作説明図である。
【図１５】第４の実施形態の動作説明図である。
【図１６】第５の実施形態の動作説明図である。
【図１７】第５の実施形態の動作説明図である。
【図１８】第６の実施形態の動作説明図である。
【図１９】第６の実施形態の動作説明図である。
【図２０】第６の実施形態の動作説明図である。
【図２１】第７の実施形態の動作説明図である。
【図２２】第９の実施形態の動作説明図である。
【図２３】第８の実施形態の動作説明図である。
【図２４】第８の実施形態の動作説明図である。
【図２５】第９の実施形態の動作説明図である。
【図２６】第９の実施形態の動作説明図である。
【図２７】第１０の実施形態の動作説明図である。
【図２８】第１０の実施形態の動作説明図である。
【図２９】第１〜第１０の実施形態の動作説明図である。
【図３０】第１〜第１０の実施形態の動作説明図である。
【図３１】他の実施形態の動作説明図である。
【符号の説明】
２０…鋼材調達システム、２１…インターネット、２２…社内ＬＡＮ、２３…専用回線、３０，３１…通信端末、３２…鋼材調達サーバ、３３…アプリケーションサーバ、３４…データベースサーバ、３５…データベース、３６…ホスト、３７…サプライヤシステム、ＭＴ１…鋼材。
【図１】
2004318611.tif 000003
【図２】
2004318611.tif 000004
【図３】
2004318611.tif 000005
【図４】
2004318611.tif 000006
【図５】
2004318611.tif 000007
【図６】
2004318611.tif 000008
【図７】
2004318611.tif 000009
【図８】
2004318611.tif 000010
【図９】
2004318611.tif 000011
【図１０】
2004318611.tif 000012
【図１１】
2004318611.tif 000013
【図１２】
2004318611.tif 000014
【図１３】
2004318611.tif 000015
【図１４】
2004318611.tif 000016
【図１５】
2004318611.tif 000017
【図１６】
2004318611.tif 000018
【図１７】
2004318611.tif 000019
【図１８】
2004318611.tif 000020
【図１９】
2004318611.tif 000021
【図２０】
2004318611.tif 000022
【図２１】
2004318611.tif 000023
【図２２】
2004318611.tif 000024
【図２３】
2004318611.tif 000025
【図２４】
2004318611.tif 000026
【図２５】
2004318611.tif 000027
【図２６】
2004318611.tif 000028
【図２７】
2004318611.tif 000029
【図２８】
2004318611.tif 000030
【図２９】
2004318611.tif 000031
【図３０】
2004318611.tif 000032
【図３１】
2004318611.tif 000033