(57)【要約】  【課題】サプライチェーンマネジメントの分野において、複数企業が全体として満たさなければならない多様な取引フローを柔軟に記述する手段は提供されていない。  【解決手段】多数の企業間のメッセージの交換手順として、理想的な一つの手順のみを標準として許容するのではなく、全体の取引フローを複数のブロックに分割し、各ブロックに複数の処理手順の選択肢を用意し、それらの組み合わせによって全体として多様な交換手順を許容し得る標準を規定することにより、各拠点のサーバが自己の処理手順にしたがってメッセージを交換することにより、全体として協調的な動作を実現することができる。【選択図】  図１
2006178690.tif 000002
【特許請求の範囲】
【請求項１】
サプライチェーンを構成する組織に対応して、処理を行なうプロセスを生成可能なモジュールを保持するモジュール保持部と、
各モジュールが、サプライチェーン中における処理に応じて外部とのメッセージの入出力を規定するための入出力プロトコルを保持するプロトコル保持部と、
プロトコル保持部に保持されている入出力プロトコルに従って、入力された情報に基づいていずれかのモジュールが生成するプロセスに処理を実行させる処理実行部と、
を有する標準ＳＣＭシステム。
【請求項２】
処理実行部は、
サプライチェーンにおける取引フロー上の役割を示す情報であるロール定義情報を取得するロール定義情報取得手段と、
前記ロール定義情報取得手段にて取得したロール定義情報に基づいて、モジュール保持部に保持されている複数のモジュールから処理を実行するためのモジュールを選択するための選択手段と、
を有する請求項1に記載の標準ＳＣＭシステム。
【請求項３】
入出力プロトコルは、プロセスによる処理を実行するための複数のパターンであるプロセスパターンを有し、
前記プロトコル保持部は、処理を実行するために、複数のプロセスパターンの中から、一のプロセスパターンを選択するプロセスパターン選択手段を有する請求項１または２に記載の標準ＳＣＭシステム。
【請求項４】
前記入出力プロトコルは、前記プロセスパターンのいずれに対しても共通である請求項３に記載の標準ＳＣＭシステム。
【請求項５】
サプライチェーンにおける取引フロー上の役割を示すロール定義情報に基づいて決定される組織の処理に伴って発生する外部とのメッセージの入出力を規定し、前記処理をプロセスによって実行するための複数のパターンであるプロセスパターンを有する入出力プロトコルに基づいて、サプライチェーンを構成するべき組織ごとのロール定義情報の選択結果を示す情報であるロール定義情報選択結果情報を取得するロール定義情報選択結果情報取得部と、
前記プロセスパターンからの選択結果を示す情報であるプロセスパターン選択結果情報を取得するプロセスパターン選択結果情報取得部と、
ロール定義情報選択結果情報取得部で取得されたロール定義情報選択結果情報とプロセスパターン選択結果情報取得部で取得されたプロセスパターン結果情報に基づいて、標準ＳＣＭシステムの設定を行なう設定部と、
を有する標準ＳＣＭ設定装置。
【請求項６】
サプライチェーンを構成する組織に対応して、処理を行なうプロセスを生成可能なモジュールを保持するモジュール保持ステップと、
各モジュールが、サプライチェーン中における処理に応じて外部とのメッセージの入出力を規定するための入出力プロトコルを保持するプロトコル保持ステップと、
プロトコル保持ステップにて保持されている入出力プロトコルに従って、入力された情報に基づいていずれかのモジュールが生成するプロセスに処理を実行させる処理実行ステップと、
を有する標準ＳＣＭシステムの動作方法。
【請求項７】
サプライチェーンにおける取引フロー上の役割を示すロール定義情報に基づいて決定される組織の処理に伴なって発生する外部とのメッセージの入出力を規定し、前記処理をプロセスによって実行するための複数のパターンであるプロセスパターンを有する入出力プロトコルに基づいて、サプライチェーンを構成するべき組織ごとのロール定義情報の選択結果を示す情報であるロール定義情報選択結果情報を取得するロール定義情報選択結果情報取得ステップと、
前記プロセスパターンからの選択結果を示す情報であるプロセスパターン選択結果情報を取得するプロセスパターン選択結果情報取得ステップと、
ロール定義情報選択結果情報取得ステップで取得されたロール定義情報選択結果情報とプロセスパターン選択結果情報取得ステップで取得されたプロセスパターン結果情報に基づいて、標準ＳＣＭシステムの設定を行なう設定ステップと、
を含む標準ＳＣＭシステムの設定を行なうための装置の設定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サプライチェーンマネジメント（ＳＣＭ）における全体のメッセージのフローを記述し、電子的にメッセージを交換する標準ＳＣＭシステムに関する。
【背景技術】
【０００２】
インターネットなどの広域ネットワークを介して企業が電子的な情報を交換することで、サプライチェーンマネジメント（ＳＣＭ）の効率化が可能になってきた。これにより、電子商取引を用いたＳＣＭを導入することで、企業にまたがった処理の自動化や在庫削減、リードタイム短縮が可能になる。
【０００３】
こうした電子商取引を実現するために、業界標準は必要不可欠なものである。業界標準はその業界に属する企業間で交換されるメッセージのフォーマットとそれらのメッセージの交換手順などを規定するものである。取引に関わる複数の企業が共通に、業界標準に準拠することによってはじめて、電子商取引が可能になる。
【０００４】
特に、XMLと呼ばれる計算機により可読なメッセージフォーマットを用いて、インターネットを介した取引を実現するための業界標準が数多く策定されている。例えば、電子部品業界で策定されたRosettaNetと呼ばれる電子商取引の国際標準は、多くの企業で利用されている。RosettaNetでは、交換するメッセージのフォーマットはXMLによって記述されているが、PIPと呼ばれる取引メッセージの交換手順の規定は人間によってのみ可読な文書として記述されている。
【０００５】
取引メッセージの交換手順を計算機により可読なXMLのメッセージとして記述する方法として、ebXML BPSSが標準として考案されている。BPSSを用いるとPIPのような取引手順をそれぞれの業界の事情に合わせて記述することが可能である。XMLによるメッセージ交換処理の手順を記述する方法には、この他にBPEL4WSと呼ばれるものがある。この言語では、XMLメッセージを用いて、Webサービスと呼ばれる分散配置されたサービスを順次呼び出して実行することで、処理の連携を記述することができる。
【０００６】
ワークフロー技術は、企業内の複数部署間での業務を円滑に進めるためシステムとして発明され、発展してきた。この技術を企業間の取引手順の制御のために活用するために様々な発明が行われてきた。企業間での取引手順を制御するために重要な要件は、各企業内の業務プロセスは他の企業に公開することができないという点である。企業内でのワークフローの場合であれば、社内の1カ所に社内の全ての関連する部門の業務フローを定義し、それらを連携させることのできるサーバを用意し、各部門がそのサーバからの指示に従って業務を遂行するような構成を採ることができた。なお、企業内であってもグローバルに展開されている企業などでは、業務フロー制御のためのサーバがそれぞれの部門に配置されることが必要とされることもある。
【０００７】
例えば、特許文献１においては、それぞれビジネスプロセスを分散管理されているワークフローサブシステム間で処理を連携させるシステムの発明について記載されている。この発明では、各ビジネスプロセスに入口と出口を定義して、これらをリンクさせることで複数のビジネスプロセスをリンクさせることを可能にしている。
【０００８】
また、例えば、特許文献２においては、各部門でのビジネスプロセス定義システムの持つ定義情報から、連携したいビジネスプロセスを探し出して、連結した定義情報を完成させ実行時に合わせて実行する方法が示されている。
【０００９】
また、例えば、特許文献３においては、異なる企業間での連携において、各企業で運営されているワークフローシステムに、連携規則の情報を問い合わせて合致するプロセスを起動する方法について記述されている。
【００１０】
このアプローチとは反対に部門間や企業間でのメッセージ交換の手順を規定し、それに合わせてローカルなビジネスプロセスを生成する発明もなされている。例えば、特許文献４においては、Webサービスの間での情報交換の手順から、各々のワークフロー管理で処理するべきフロー定義を生成する技術について記述されている。
【００１１】
例えば、RosettaNetのPIPは、企業間での情報交換の手順までは示しているものの、それを満たす企業内のフロー制御をどのように実現するかは各企業のシステムに任されている。
【００１２】
また、例えば、ebXML BPSSは、企業間でのメッセージ交換手順を記述する一般的な言語であるが、やはり、それを実現するための企業内のフロー制御については、各企業のシステムに任せている。
【００１３】
さらに、企業間で行われる取引フローのバリエーションを増やすために、プロセスフローを柔軟に実行させるメカニズムについても様々な考案がなされている。
【００１４】
例えば、WebサービスのUDDIと呼ばれる技術では、実行時に連携が必要なサービスをリポジトリから動的に検索して、呼び出すことで連携する相手を柔軟に選択することを可能にするものである。選択されたサービスの実行手順は問わないため、全体として柔軟なフローを実現することが可能になる。
【００１５】
また、例えば、特許文献５においては、論理プログラミングの技術を用いて、メッセージを送信する相手先をその時々の状況に応じて選択することのできる、さらに柔軟なフロー制御について記述されている。
【特許文献１】特開平8-123744号公報
【特許文献２】特開平9-305660号公報
【特許文献３】特開平10-326315号公報
【特許文献４】特開2004-16449号公報
【特許文献５】特開2001-188865号公報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
特許文献１から３の発明は、部門や企業のローカルに定義されたプロセスから、他の部門や企業のプロセスを連携する方法を示すものである。しかしながら、これらいずれの発明においても、複数企業が全体として満たさなければならない多様なフローを柔軟に記述する手段は提供されていない。
【００１７】
特許文献４、RosettaNetのPIP、ebXML BPSSなどの技術を用いることによって、企業間の取引手順を記述することはできるが、サプライチェーン全体の取引フローを記述し、それをブロック化して選択肢を持たせるような利用をするには十分ではない。
【００１８】
WebサービスのUDDIと呼ばれる技術、特許文献５の技術における動的に取引先などを変更できる柔軟性は、現実の商取引上は実はそれほど大きなメリットではない。信頼できる取引先と一定の期間の間、安定した取引関係を維持し、確実な取引手順を実施することのほうが、現実的にはより重要である。電子商取引の普及に必要なフローの多様性は、取引先の組み合わせや、取引のパターンは基本的に固定的な確実なものであるが、その選択の仕方にバリエーションを持たせられるものである。上述した、いずれの従来技術も、このような多様性を実現するのに有用なメカニズムは提供していない。
【００１９】
そこで、本発明は、複数企業が満たすべき多様なフローを記述する手段を提供し、また、全体のフローをブロック化して選択肢を持たせることにより企業間取引に関わる多くの企業を納得させることのできる標準ＳＣＭシステムを提供することを目的とする。
【課題を解決するための手段】
【００２０】
企業間の電子商取引を普及させ、本来のＳＣＭの効果を出すためには、多くの役割の企業から成り立っている現在のビジネスモデルを許容し、従来の処理手順を大きく変更することなく、取引の標準化によって得られるメリットも享受できるものであることが望ましい。そこで、本発明は、従来のように、理想的な一つの手順のみを標準として許容するのではなく、全体の処理フローを複数のブロックに分割し、各ブロックに複数の処理手順の選択肢を用意し、それらの組み合わせによって全体として多様な交換手順を許容し得る標準を規定するものである。また、本発明は、そうして規定された標準に基づいた処理手順を遂行するために不可欠な、企業間取引システムの構成について記述するものである。さらに、そうした企業間取引システムを実現する上で、特に有用な分散配置による構成についても記述するものである。
【発明の効果】
【００２１】
本発明により、ＳＣＭの全体のフローを記述することができ、複数拠点にまたがるビジネスフローを、各拠点が自律的に動作することで、全体のフロー制御を協調的に動作させることができる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明を実施するための最良の形態について、実施形態と実施例とにより、図を用いて説明する。なお、本発明は、これら実施形態と実施例に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施し得る。
【００２３】
（実施形態１）
本発明の実施形態１として、プロセスを生成可能なモジュールを、サプライチェーンを構成する組織に対応して保持し、組織での処理に応じたプロトコルにしたがって、プロセスに処理をさせる標準ＳＣＭシステムについて説明する。なお、「サプライチェーン」とは、商品や役務が供給者から消費者などの需要者に届けられるまでの開発、資材調達、配送、販売などを担当する企業などの組織の業務の連携をいう。「サプライチェーンマネジメント（ＳＣＭ）」とはこれら組織の事業活動を計算機を使って総合的に管理することをいう。本発明は、ＳＣＭを実践するためのシステム、方法に関するが、商品や役務の流れに伴なうシステム限定されることなく、複数の組織間でのメッセージの交換処理などにも適用が可能である。
【００２４】
（実施形態１：構成）
図１は、本発明の実施形態１に係る標準ＳＣＭシステムの機能ブロック図を例示する。標準ＳＣＭシステム１００は、モジュール保持部１０１と、プロトコル保持部１０２と、処理実行部１０３と、を有する。
【００２５】
「モジュール保持部」１０１は、サプライチェーンを構成する組織に対応してモジュールを保持する。モジュールとは、処理を行なうプロセスを生成可能なものである。ここでいう「処理」とは、サプライチェーンを構成する各組織内部で行なわれる様々な処理を意味する。モジュール保持部が保持するモジュールの例としては、発注者の組織に対応する「発注者モジュール」、受注者の組織に対応する「受注者モジュール」などがある。以下、発注者モジュールと受注者モジュールとを例として用いて説明を行なう。
【００２６】
ここで「プロセス」とは、あらかじめ定められた種類の入力メッセージに対して処理を行ない、あらかじめ定められた種類の出力メッセージを出力するエンティティである。プロセスは複数の種類の入力メッセージを処理する場合には、その複数のメッセージが入力されるまで待ち状態になり、全ての入力メッセージが入力され、起動するべき時間の到達などの条件の成就により処理を開始し、その結果得られる出力メッセージを出力する。したがって、プロセスは、入力メッセージがどれだけ入力されたか、処理が開始可能であるかどうかなどの状態を有している。このような状態はデータとして保持され、そのデータは例えば後述の処理実行部で変更される。このようなデータに永続性を持たせることにより、通常の計算機内で動作する通常のプロセスと異なり、計算機の電源をＯＦＦにしてもプロセスを存在させることが可能であり、計算機の電源が再度ＯＮになったときに処理を継続して行なうことができる。したがって、モジュールは、例えば、そのようなデータを生成するプログラムにより実現することができ、モジュール保持部は、そのようなプログラムを保持する半導体メモリなどにより実現することが可能である。
【００２７】
なお、図１では、一つのモジュール保持部が複数のモジュールを有しているが、複数のモジュール保持部があり、それぞれにモジュールが保持されるようになっていてもよい。図２は、そのような場合を示しており、第一のモジュール保持部１０１−１と第二のモジュール保持部１０１−２とがあり、第一のモジュール保持部１０１−１には、発注者モジュール１０４が保持され、第二のモジュール保持部１０１−２には、受注者モジュール１０５が保持されている。例えば、発注者の役割をする拠点（例えば、ある企業）には、第一のモジュール保持部１０１−１が設置され、受注者の役割をする拠点（別の企業）には、第二のモジュール保持部１０１−２が設置されているという具合である。
【００２８】
「プロトコル保持部」１０２は、入出力プロトコルを保持する。「入出力プロトコル」とは、各モジュールが、サプライチェーン中における処理に応じて外部とのメッセージの入出力を規定するための情報である。ここで「外部」とは、標準ＳＣＭシステムの外部を意味する。入出力プロトコルをサプライチェーンマネジメントに特化して述べると、全体の取引フローを記述する情報である。特に、取引フローの外部仕様を記述することになっていてもよい。例えば、各モジュールが、サプライチェーン中において、各組織が受発注処理、入出荷処理、仕入売上処理のどの処理を行なうための役割として何があるか、他のモジュールや組織の人間や装置に対して入出力を行なうメッセージの交換手順、順序、フォーマットなどを規定するための情報も含まれていてよい。「規定するための情報」とあるので、外部のみならず、内部のメッセージの交換手順についても入出力プロトコルにより記述されていてもよい。また、全体の取引フローが、受発注処理、入出荷処理、仕入売上処理などのように、処理の目的に応じて、いくつかのブロックに分割されていてもよい。なお、「受発注処理、入出荷処理、仕入売上処理」と書いたが、この部分は、必要に応じて様々な処理に置き換えることができる。例えば、仕入確定、支払確定、商品情報交換、見積請求、カタログ請求、在庫確認、経路確認などの処理が他に考えられる。
【００２９】
図３は、入出力プロトコルの図による例示である。この例では、発注者モジュールと受注者モジュールとの間で交換されるメッセージの交換手順などが図示されている。左側は発注者側となっており、これは発注者モジュールが生成するプロセスにより処理がされる。右側は受注者側となっており、受注者モジュールが生成するプロセスにより処理がされる。例えば、受発注処理では、発注者に相当する組織などが発注情報３０１を入力メッセージとして入力すると、モジュールにより生成されたプロセスにより受発注処理が行なわれた後に、発注者への出力メッセージとして入荷予定情報３０２が出力され、受注者側への出力メッセージとして出荷予定情報３０３が出力される。同様に、入荷予定情報３０２と出荷予定情報３０３を入力メッセージとして、入出荷処理が行なわれると、入荷確定情報３０４と出荷確定情報３０５が出力メッセージとして出力される。さらに、入荷確定情報３０４と出荷確定情報３０５が入力メッセージとして、仕入売上処理が行なわれると、仕入情報３０６と売上情報３０７が出力メッセージとして出力される。なお、図３に例示した入出力プロトコルは、例えば、ＸＭＬにより計算機が直接読み取る形式で記述することが可能である。
【００３０】
図４は、受発注処理の入出力プロトコルを実現するためのフロー（「プロセスパターン」という）を記述した例である。入力メッセージとして発注情報が入力されると、発注数量確定プロセス４０１が発注者モジュールにより生成され、そのプロセスの処理の結果として、入荷予定情報と発注確定情報という出力メッセージが出力される。発注確定情報というメッセージを受注者側が受け取ると、受注回答プロセス４０２が受注者モジュールにより生成され、その処理の結果として、出荷予定情報が出力される。このようなプロセスパターンの記述は、入出力プロトコルの一部として記述されていてもよい。あるいは入出力プロトコルはあくまでも標準ＳＣＭシステムが扱うサプライチェーンを構成する組織の入出力メッセージを記述するものとして、プロセスパターンの記述を含まないものであってもよい。
【００３１】
「処理実行部」１０３は、プロトコル保持部１０２に保持されているプロトコルにしたがって、入力された情報に基づいていずれかのモジュールが生成するプロセスに処理を実行させる。「入力された情報」とは上記の入力メッセージである。処理実行部１０３は、例えば、入力メッセージを受け取ると、その入力メッセージの種類を確定し、種類に応じて、プロトコルにしたがって、どの処理を行なうべきかを判断し、モジュール保持部１０１に保持されているいずれかのモジュールが生成したプロセスを受け取り、そのプロセスにより入力メッセージを処理させ、出力メッセージを出力させる。必要に応じて、その出力メッセージをさらに別のプロセスが入力メッセージとして受け取り、処理を継続するようになっていてもよい。
【００３２】
処理実行部は複数存在してもよい。例えば、拠点や組織ごとに処理実行部が備えられるようになっていてもよい。モジュール保持部も拠点ごとに備えられている場合には、例えば、処理実行部は、その拠点に備えられたモジュール保持部が生成するプロセスを実行する。
【００３３】
なお、図１に例示される構成は、ハードウェア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウェア的にはメモリにロードされたプログラムなどによって実現されるが、ここでは主にそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組み合せによっていろいろな形で実現できる。例えば、ソフウェアのみで実現する場合には、モジュール保持部を実現するステップ（モジュール保持ステップ）と、プロトコル保持部を実現するステップ（プロトコル保持ステップ）と、処理実行部を実現するステップ（処理実行ステップ）とからなるプログラムにより、標準ＳＣＭシステムが実現される。
【００３４】
また、モジュール保持部１０１は、さらに出荷拠点モジュールを有するようになっていてもよい。すなわち、モジュール保持部で保持されるモジュールのなかの一つが出荷拠点に対応したモジュールになっている。
【００３５】
図５は、出荷拠点モジュールの生成するプロセスが関係したプロセスパターンの一例を図示する。受注者側が出荷予定情報を入力すると、それに対応して、出荷指示プロセス５０１の処理が行なわれる。その処理の結果、出荷指示情報と出荷確定情報という出力メッセージが出力される。出荷指示情報は、出荷プロセス５０２の入力メッセージとなり、処理が行なわれる。この出荷プロセス５０２は、出荷拠点モジュールが生成したプロセスであり、実際の商品などの出荷の指示を行なう。
【００３６】
（実施形態１：主な効果）
本実施形態により、サプライチェーンを構成する組織によるＳＣＭを実現することができ、各組織が入出プロトコルに基づいて自律的に動作することが可能となる。
【００３７】
（実施形態２）
本発明の実施形態２として、ロール定義を取得して、モジュールを選択して処理を行なう標準ＳＣＭシステムについて説明する。
【００３８】
（実施形態２：構成）
図６は、本発明の実施形態３に係る標準ＳＣＭシステムの機能ブロック図を例示する。標準ＳＣＭシステム６００は、モジュール保持部１０１と、プロトコル保持部１０２と、処理実行部１０３と、を有し、処理実行部は、ロール定義情報取得手段６０１と、選択手段６０２と、を有する。したがって、本実施形態に係る標準ＳＣＭシステムは、実施形態１又は２に係る標準ＳＣＭシステムの処理実行部１０３が、ロール定義情報取得手段６０１と、選択手段６０２と、を有する構成となっている。
【００３９】
「ロール定義情報取得手段」６０１は、ロール定義情報を取得する。「ロール定義情報」とは、自システムが取引フロー上のどの役割を果たすかを示す情報である。例えば、本明細書のこれまでの実施形態に即して説明すると、発注者としての役割を果たすのか、受注者としての役割を果たすのか、あるいは、出荷拠点としての役割を果たすのか、を示す情報である。このような情報は、ＸＭＬなどにより計算機可読な状態で表現ができ、処理実行部１０３は、処理の開始時などに、ロール定義情報を読み込む。したがって、本実施形態は、複数の標準ＳＣＭシステムが通信網などで接続され、それらの標準ＳＣＭシステムが協調して動作する場合を主に念頭に置いている。しかし、本実施形態は、そのような場合に限定されることはなく、例えば、一つの標準ＳＣＭシステムが複数のロールを果たすようになっていても構わない。また、時間に応じてロール定義情報が変化し、同一の標準ＳＣＭシステムの役割が時間に応じて変化することが可能な場合であってもよい。このような構成により、例えば、発注者の組織と出荷拠点との両方のロールを一つの標準ＳＣＭシステムで果たすことが可能となる。
【００４０】
「選択手段」６０２は、ロール定義情報取得手段６０１にて取得されたロール定義情報に基づいて、モジュール保持部１０１に保持されている複数のモジュールから、処理を実行するためのモジュールを選択する。「処理を実行するためのモジュール」とは、そのモジュールが生成したプロセスを処理するためのモジュールを意味するものとする。すなわち、本実施形態では、処理実行部は任意のモジュールが生成したプロセスの処理を行なうのではなく、ロール定義情報により特定されるモジュールが生成したプロセスの処理を行なう。そのため、モジュール保持部１０１で保持されるモジュールが複数あれば、ロールに応じて複数の処理実行部が備えられるようになっていてもよい。例えば、複数の標準ＳＣＭシステムが用意され、それらが協調して動作することになる。あるいは、一つの標準ＳＣＭシステムが複数の処理実行部を有していてもよい。
【００４１】
図７は、複数の処理実行部を有する標準ＳＣＭシステムの機能ブロック図を例示する。図７においては、第一の処理実行部１０３−１と第二の処理実行部１０３−２が標準ＳＣＭシステムに備えられており、それぞれ、ロール定義取得手段、選択手段を有している。ロール定義取得手段６０１−１とロール定義取得手段６０１−２とが取得するロール定義情報は、一般には異なるロール（役割）を定義することになる。
【００４２】
（実施形態２：主な効果）
本実施形態により、同じ装置を配備しておき、拠点の役割に応じて適切な処理を選択的に実行することができるので、標準処理の展開が容易になるという効果がある。
【００４３】
（実施形態３）
本発明の実施形態３として、モジュールが複数のプロセスパターンを有し、一のプロセスパターンを選択することが可能な標準ＳＣＭシステムについて説明する。
【００４４】
（実施形態３：構成）
図８は、本発明の実施形態４に係る標準ＳＣＭシステムの機能ブロック図を例示する。標準ＳＣＭシステム８００は、モジュール保持部１０１と、プロトコル保持部１０２と、処理実行部１０３と、を有している。プロトコル保持部１０２は、プロセスパターン選択手段８０１を有している。処理実行部１０３は、ロール定義情報取得手段６０１と、選択手段６０２と、を有していてもよい。したがって、本実施形態に係る標準ＳＣＭシステムは、実施形態１または２の実施形態に係る標準ＳＣＭシステムのプロトコル保持部１０２がプロセスパターン選択手段８０１を有した構成となっている。
【００４５】
なお、本実施形態においては、入出力プロトコルは、処理を実行するための複数のパターンであるプロセスパターンを有している。例えば、受発注処理のプロセスパターンの一つは図４に例示した通りであるが、別のプロセスパターンとしては、図９に例示したパターンがある。図９のプロセスパターンでは、発注確定プロセスが図４のプロセスパターンに加わった構成となっている。
【００４６】
「プロセスパターン選択手段」８０１は、処理を実行するために、複数のプロセスパターンの中から、一のプロセスパターンを選択する。すなわち、受発注処理、入出荷処理、仕入売上処理といった処理ごとに、どのプロセスパターンを選択するかを示す情報を取得して、その取得された情報に基づいて、プロセスパターンを選択する。例えば、受注発注処理においては、図４のプロセスパターンを選択するのか、図９のプロセスパターンを選択するのか、を示す情報を取得（例えば、ＸＭＬなどで記述されたファイルを読み込むなど）して、選択を行なう。
【００４７】
（実施形態３：主な効果）
本実施形態によれば、複数のプロセスパターンの中から、一番適切なものを選択することができるので、すでに多様な処理が行なわれている拠点に本実施形態に係る標準ＳＣＭシステムを導入することができる。
【００４８】
（実施形態４）
本発明の実施形態４として、入出力プロトコルがプロセスパターンのいずれに対しても共通であるような標準ＳＣＭシステムについて説明する。
【００４９】
（実施形態４：構成）
本発明の実施形態４に係る標準ＳＣＭシステムにおいては、前記入出力プロトコルは、前記プロセスパターンのいずれに対しても共通である。「前記入出力プロトコル」とは、実施形態３に係る標準ＳＣＭシステムのプロトコル保持部１０２が保持する入出力プロトコルであり、「前記プロセスパターン」とは、プロセスパターン選択手段８０１により選択されるプロセスパターンである。
【００５０】
このように入出力プロトコルがプロセスパターンのいずれに対しても共通であるということは、一つの入出力プロトコルが定められ、プロセスパターンは、その入出力プロトコルに適合したものであることを意味する。すなわち、プロセスパターンは、少なくとも、入出力プロトコルで規定されるメッセージを標準ＳＣＭシステムの外部に入出力するようになっている。したがって、あるメッセージが標準ＳＣＭシステムに入力され、プロセスパターンによる処理の結果を示すメッセージが標準ＳＣＭシステムから出力されるまでを一つの処理単位としてブロックとしてまとめることが可能となる。また、モジュールは、そのような入出力プロトコルに適合するプロセスを生成すればよいことになるので、入出力プロトコルが複数あることに対応してモジュールを複数用意することが無くなる。
【００５１】
（実施形態４：主な効果）
標準として規定された入出力プロトコルごとにモジュールを配備する必要のない汎用のメカニズムを提供することにより、入出力プロトコルに適合したプロセスパターンの変更や追加が生じても各組織で大きなシステム変更をする必要がなくなるため、標準の取引手順を普及させることが可能となる。
【００５２】
（実施形態５）
本発明の実施形態５として、以上説明してきた標準ＳＣＭシステムの設定を行なうための標準ＳＣＭ設定装置について説明する。
【００５３】
（実施形態５：構成）
図１０は、本発明の実施形態５に係る標準ＳＣＭ設定装置の機能ブロック図を例示する。標準ＳＣＭ設定装置１０００は、ロール定義情報選択結果情報取得部１００１と、プロセスパターン選択結果情報取得部１００２と、設定部１００３と、を有する。なお、図１０に例示される構成は、ハードウェア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウェア的にはメモリにロードされたプログラムなどによって実現されるが、ここでは主にそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できる。他の実施形態で例示された機能ブロック図についても同様である。
【００５４】
「ロール定義情報選択結果情報取得部」１００１は、入出力プロトコルに基づいて、サプライチェーンを構成するべき組織ごとのロール定義情報選択結果情報を取得する。ここに、ロール定義情報選択結果情報とは、ロール定義情報の選択結果情報を示す情報である。ロール定義情報とは、実施形態２で説明したように、取引フロー上の役割を示す情報である。また、入出力プロトコルとは、実施形態１で説明したように、サプライチェーンにおける取引フロー上の役割を有する組織の処理に伴なって発生する外部とのメッセージの入出力を規定するための情報であり、図３に例示される情報がその一例である。
【００５５】
例えば、ロール定義情報選択結果情報取得部１００１は、入出力プロトコルを画面に表示し、標準ＳＣＭ設定装置１０００の利用者にサプライチェーンを構成する組織には何があるかを示し、その結果、利用者が入力するロール定義情報の選択の結果を取得する。入出力プロトコルを示す情報は、例えば、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）などを用いて公開することができる。ロール定義情報選択結果情報取得部１００１は、このようにして公開される入出力プロトコルを表示してもよい。
【００５６】
図１１は、例えば、図３の入出力プロトコルを表示し、発注者と受注者というロールをどの組織が果たすべきかを入力する画面１１０１を例示する。欄１１０２には、発注者のロールを果たすべき組織の名前などが入力される。図１１では、発注者のロールを果たすのは、Ｃｏｍｐａｎｙ１．ｃｏｍ．ｊｐというＦＱＤＮ（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ）で示される組織となっている。同様に、欄１１０３には、受注者のロールを果たすべき組織の名前などが入力され、Ｃｏｍｐａｎｙ３．ｃｏｍ．ｊｐというＦＱＤＮが入力されている。
【００５７】
「プロセスパターン選択結果情報取得部」１１０２は、プロセスパターン選択結果情報を取得する。プロセスパターン選択結果情報とは、実施形態３で説明したように、サプライチェーンにおける取引フロー上の役割を果たす組織の処理をプロセスによって実行するためのパターンである。一般に、入出力プロトコルと適合するプロセスパターンは一に限られることはなく、複数あり得る。そこで、プロセスパターン選択結果情報取得部１１０２は、このように複数あり得るプロセスパターンから一つのパターンを選択した結果を示す。例えば、受発注処理に対応するプロセスパターンとして図４と図９とに例示されるパターンがあるので、画面にこられのプロセスパターンを表示して、マウスなどを用いてチェックボックスなどに選択が行なわれることにより、プロセスパターン選択結果情報が取得される。また、プロセスパターンを区別する質問を発し、その結果、標準ＳＣＭ設定装置１０００の利用者から得られる応答に基づいて、プロセスパターン選択結果情報を取得するようになっていてもよい。質問の例としては、「受注回答情報を得ることなく、入荷予定情報を出力してもよいですか？」があり、この質問に対する応答が「はい」であれば、図４のプロセスパターンを選択し、「いいえ」であれば、図９のプロセスパターンを選択する。
【００５８】
図１２は、例えば、図３の入出力プロトコルを表示し、受注者の役割をＣｏｍｐａｎｙ１．ｃｏｍ．ｊｐが果たし、発注者の役割をＣｏｍｐａｎｙ３．ｃｏｍ．ｊｐが果たす場合における、受発注処理のプロセスパターンを選択するための画面１２０１を例示する。欄１２０２には、受発注処理のプロセスパターンの選択結果が入力され、例えば、第１パターンという文字列が入力される。プロセスパターン選択結果情報取得部１１０２は、このように入力される選択結果を示す情報を取得する。
【００５９】
「設定部」１１０３は、ロール定義情報選択結果情報取得部１００１で取得されたロール定義情報選択結果情報とプロセスパターン選択結果情報取得部１００２で取得されたプロセスパターン選択結果情報に基づいて、標準ＳＣＭシステムの設定を行なう。例えば、実施形態３で説明した標準ＳＣＭシステムのロール定義情報取得手段が、ロール定義情報選択結果情報取得部１００１で取得されたロール定義情報選択結果情報で示されるロール定義情報を取得できるようにする。ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）などのファイル転送用のプロトコルに基づいて、ロール定義情報を指定するファイルを標準ＳＣＭシステムが動作する計算機に配置する。同様に、プロセスパターン選択手段が、プロセスパターン選択結果情報取得部１００２で取得されたプロセスパターン選択結果情報で示されるプロセスパターンを選択するよう、設定を行なうために、設定部はプロセスパターンを指定するファイルを配置する。
【００６０】
図１３は、標準ＳＣＭ設定装置が、Ｃｏｍｐａｎｙ１．ｃｏｍ．ｊｐの標準ＳＣＭシステム１３０１とＣｏｍｐａｎｙ３．ｃｏｍ．ｊｐの標準ＳＣＭシステム１３０２に、ロール定義情報とプロセスパターンとを指定するファイルを配置する様子を例示する。標準ＳＣＭ設定装置１０００は、標準ＳＣＭシステム１３０１に対しては、発注者指定という情報を含むファイル１３０３を配置する。ファイル１３０３では、発注者に対応する受注者の役割を果たすのは、Ｃｏｍｐａｎｙ３．ｃｏｍ．ｊｐであり、受発注処理として、第１パターンが選択されていることが示される。
【００６１】
同様に、標準ＳＣＭ設定装置１０００は、標準ＳＣＭシステム１３０２に対しては、受注者指定という情報を含むファイル１３０４を配置する。ファイル１３０４では、受注者に対応する発注者の役割を果たすのは、Ｃｏｍｐａｎｙ１．ｃｏｍ．ｊｐであり、受発注処理として、第１パターンが選択されていることが示される。
【００６２】
このようにファイル１３０３、１３０４が配置されることにより、標準ＳＣＭシステム１３０１と標準ＳＣＭシステム１３０２とは、入出力プロトコルにおける相手方を知ることができ、それぞれの処理をどのように進めればよいかを知ることができる。結果として、標準ＳＣＭシステムを協調して動作させることが可能となる。
【００６３】
本実施形態に係る標準ＳＣＭシステムを例えば汎用的な計算機によって実現する場合には、その計算機は、ロール定義情報選択結果情報取得ステップと、プロセスパターン選択結果情報取得ステップと、設定ステップとを含む方法を使用して動作することになる。ここに、ロール定義情報選択結果情報取得ステップとは、上記に説明したロール定義情報選択結果情報を取得するステップであり、プロセスパターン選択結果情報取得ステップとは、プロセスパターン選択結果情報を取得するステップであり、設定ステップとは、ロール定義情報選択結果情報取得ステップで取得されたロール定義情報選択結果情報とプロセスパターン選択結果情報取得ステップで取得されたプロセスパターン選択結果情報に基づいて、標準ＳＣＭシステムの設定を行なうステップである。
【００６４】
なお、このように、ロール定義情報の指定とプロセスパターンの選択を行なうことにより、例えば、Ｃｏｍｐａｎｙ１．ｃｏｍ．ｊｐが、第三の組織であるＣｏｍｐａｎｙ２．ｃｏｍ．ｊｐと取引フローを交換する場合、Ｃｏｍｐａｎｙ１．ｃｏｍ．ｊｐは受注者の役割を果たし、Ｃｏｍｐａｎｙ２．ｃｏｍ．ｊｐは発注者の役割を果たし、受発注処理として第2パターンを選択することも可能である。すなわち、取引フローを交換する組織のグループごとに異なるロール定義情報、プロセスパターンを指定することが可能である。
【００６５】
（実施形態５：主な効果）
本実施形態により、これまでの実施形態で説明された標準ＳＣＭシステムの設定を行なうことが可能である。特に、取引フローを交換する組織のグループごとに異なるロール定義情報、プロセスパターンを指定することが可能である。
【００６６】
（実施例）
以下に、以上の実施形態の実施例について説明する。
【００６７】
図１４は、一つの標準ＳＣＭシステムを構成するためのプロセスフロー実行エンジンの機能ブロック図を例示する。例えば、それぞれの拠点にプロセスフロー実行エンジンが設置され、ネットワークで通信可能な状態にしておき、複数のプロセスフロー実行エンジンがメッセージの交換を行なう。
【００６８】
メインユニット（１）は、プロセスフロー実行エンジン全体を司るものであり、各部を実行して処理を行なわせる。メインユニットは、例えば、スタンドアロンで動作するアプリケーションプログラムで実現される。
【００６９】
メッセージ受信部（２）は、外部から例えばXML形式で記述された発注情報のようなメッセージを受信し、内容を解析し入力メッセージとしてプロセス選択部に引き渡す。
【００７０】
プロセスフロー読み込み部（３）は、例えばXMLの形式で記述された標準SCMモデル（下記参照）、コラボレーション定義（下記参照）、ロール定義（下記参照）を読み込み、自システム内で実行できるプロセスを選択し、そのプロセスの情報（入力メッセージの種類、出力するメッセージの種類）を内部で保持する。必要に応じて自システム内で実行できるプロセスの一覧をプロセス選択部に引き渡したり、プロセス実行に伴い生成されたメッセージの送信先をメッセージ送信部に引き渡したりする。プロセスフロー読み込み部で読み込まれた情報を保持する部分が、モジュール保持部の一部とプロトコル保持部に相当する。
【００７１】
プロセス選択部（４）は、プロセスフロー読み込みより、自システム内で実行できるプロセスの一覧を取得し、受信したメッセージを入力とするプロセスを調べる。該当プロセスを受信メッセージと共にプロセス状態管理部に引き渡す。プロセス選択部は、処理実行部の一部を構成する。
【００７２】
プロセス状態管理部（５）は、プロセス選択部より渡されたプロセスと受信メッセージを管理する。プロセスが必要とする受信メッセージが全て入力された場合、そのプロセスと受信メッセージをプロセススケジューラに引き渡す。プロセス状態管理部は、処理実行部の一部を構成する。
【００７３】
プロセススケジューラ（６）は、プロセス状態管理部より渡されたプロセスと入力メッセージを管理する。プロセス定義読み込みから、そのプロセスが実行される時刻を取得し、実行時刻に達したプロセスとその受信メッセージをプロセス実行部に引き渡す。プロセススケジューラは、処理実行部の一部を構成する。
【００７４】
プロセス定義読み込み部（７）は、例えばXMLの形式で記述されたプロセス定義を読み込み、内部で保持する。必要に応じてプロセスの処理内容および実行時刻をプロセス実行部、プロセススケジューラに引き渡す。プロセス定義読み込み部で読み込まれた情報を保持する部分が、モジュール保持部の一部を構成する。
【００７５】
プロセス実行部（８）は、プロセススケジューラよりプロセスと入力メッセージを受け取り、プロセス定義読み込みより取得されたプロセス処理内容に従い、プロセスを実行する。処理内容の必要に応じて業務システム接続部を通じて、企業内業務システムと通信を行なう。プロセスの実行により生成されたメッセージをメッセージ送信部に引き渡す。プロセス実行部は、処理実行部の一部を構成する。
【００７６】
業務システム接続部（９）は、プロセス実行部と企業内業務システムとのデータの送受信を仲介する役目を負う。業務システムに合わせたデータ形式の変換や通信を行なう。
【００７７】
メッセージ送信部（１０）は、プロセス実行部よりメッセージを受け取り、プロセスフロー読み込みから該当メッセージの送信先を取得し、メッセージを送信する。
【００７８】
上述した標準SCMモデル、コラボレーション定義、ロール定義、プロセス定義は、以下のように定義される。
【００７９】
（１）標準SCMモデル
標準SCMモデルは、複数の企業の間の標準取引手順を記述したものであり、ある共通の業務領域に含まれる企業間で共有される情報である。標準SCMモデルは、図１５で示されるようにグループ、パターン、プロセス、入力メッセージ、出力メッセージから構成される。標準SCMモデルは上記の入出力プロトコルに相当する。
【００８０】
プロセスとは、本実施例に即して再定義すると、標準SCMモデルの基本単位であり、入力メッセージを受信して、それを元に内部で処理を行い、出力メッセージを送信する機能を持つエンティティである。取引手順の全体は、プロセスによるメッセージの送受信として表現されるが、実際の取引手順においては、取引の目的は同じであるが、複数の取引の手順が存在することがある。そういった場合に備えて、取引の目的をグループという単位で管理し、具体的な取引手順の違いをパターンという単位で管理する。なお、ここでいうパターンが、実施形態の項で説明したプロセスパターンに相当する。
【００８１】
以下の説明では、図１６に示すようなモデルを使用する。本モデルは発注者、出荷拠点、受注者の３つの役割をそれぞれ持つ拠点が登場する。全体として受発注、入荷・出荷、仕入・売上の３つの処理で構成される。受発注処理は、発注情報の入力メッセージから入荷予定、出荷予定の出力メッセージを生成する。入荷予定処理は、入荷予定と出荷予定の２つの入力メッセージから入荷確定、出荷確定の出力メッセージを生成する。仕入・売上処理は、入荷確定と出荷確定の２つの入力メッセージから仕入情報、売上情報の２つの出力メッセージを生成する。各処理は図１６に示すようにそれぞれ２つのパターンを持ち、パターンごとに異なるプロセス構成により処理が行われる。
【００８２】
図１７は図１６で示した標準SCMモデルをXML形式で記述したものである。＜ｇｒｏｕｐ  ｎａｍｅ＝”受発注”＞と＜／ｇｒｏｕｐ＞とで囲まれる部分が受発注処理を表わしており、その中の＜ｐａｔｔｅｒｎ  ｉｄ＝”１”＞と＜／ｐａｔｔｅｒｎ＞とで囲まれる部分が第一のパターンを表わしている。
【００８３】
（２）コラボレーション定義
コラボレーション定義は、実際に取引を行なう企業間で各企業が負う役割と、どのパターンを使用して取引を行なうかについて記述したものであり、取引を行なう企業間で共有される情報である。コラボレーション定義は、図１８で示されるようにロール割り当て、パターン選択から構成される。したがって、コラボレーション定義は、プロセスパターンの選択を示す情報である。
【００８４】
ロール割り当てとは、各企業がどのロールを担当するのかを定義したものである。パターン選択とは、実際の取引において、標準SCMモデルに含まれる各グループのどのパターンを使用するかを定義したものである。ロール割り当てにより、ロール定義情報が決定されることになる。
【００８５】
本実施例では、図１９で示すように、受発注ではパターン1を、入荷・出荷ではパターン２を、仕入・売上ではパターン１を使用する。
【００８６】
図２０はロールの割り当てと図１９で示したパターン選択の内容をXML形式で記述したものである。「＜ａｓｓｉｇｎ  ｒｏｌｅ＝…／＞」によりどの役割がどのドメイン名を持つ企業により果たされ、「＜ｇｒｏｕｐ  ｎａｍｅ＝…／＞」により、各処理ごとにどのパターンを使用するかが指定される。コラボレーション定義のうち、「＜ｇｒｏｕｐ  ｎａｍｅ＝…／＞」を読み込んだ結果に基づいてプロセスパターンを選択するのが、がプロセスパターン選択手段である。
【００８７】
（３）ロール定義
ロール定義は、自システムがどのロールを担当するのかについて定義したものであり、企業ごとに異なる情報である。ロール定義には、図２１で示されるように担当するロール名を記述する。このようなロール定義を読み込むのが、例えば、ロール定義取得手段である。
【００８８】
図２２は発注者のロールを担当する企業のロール定義をXML形式で記述した例である。このロール定義を読み込んだ標準ＳＣＭシステムの処理実行部は、発注者のためのプロセスを処理することになる。
【００８９】
（４）プロセス定義
プロセス定義は、標準SCMで定義されたプロセスについて図２３に示すような実行時刻や具体的な処理内容を定義したものであり、企業ごとに異なる情報である。図２４は発注者のロールを担当する企業のためのプロセス定義をXML形式で記述したものである。この例では、パターン1の発注数量確定プロセスの処理内容はJava（登録商標）のクラスjp.co.ulsystems.bm.Process1において定義されており、14:00に起動されることを示している。なお、スケジュールの実行時刻に"immediate"と指定することにより、入力メッセージが全て入力された段階で即時に実行させる指定もできる。
【００９０】
プロセスフロー制御の実行手順について以下に説明する。
【００９１】
図２５は、メッセージ受信した後、プロセスが実行され、メッセージを送信するまでの実行手順について示している。メインモジュール起動時に図１４に示されているモジュールのプロセスフロー読み込み、プロセス定義読み込みが実行されており、あらかじめ自システムで実行されるプロセスとその処理内容、起動時刻がシステムに保持されているものとする。
【００９２】
ステップ１：メッセージを受信する。外部のシステムよりメッセージを受け取ると、メッセージ受信部のモジュールが起動され、内容が解析され、プロセス選択部に引き渡される。
【００９３】
ステップ２：受信したメッセージを入力とするプロセスを検索する。プロセス選択部では、プロセスフロー読み込みから自システムで実行できるプロセスの一覧を取得する。そして、受信したメッセージを入力とするプロセスを抽出する。該当プロセスが存在しないときはエラーを通知する。
【００９４】
ステップ３：検索したプロセスにメッセージをセットし、"実行待ち"の状態にする。ステップ２で抽出されたプロセスと受信したメッセージをプロセス状態管理部に引き渡す。
【００９５】
ステップ４：入力メッセージが全て入力されている"実行待ち"のプロセスを検索する。プロセス状態管理部では、"実行待ち"のプロセスを調べ、入力メッセージが全て入力されているものをプロセススケジューラに引き渡す。
【００９６】
ステップ５：実行時刻に達しているプロセスを検索する。プロセススケジューラでは、入力メッセージが全てそろっているプロセスのうち、プロセス定義を参照しながら、実行時刻に達しているもの、もしくは即時実行のプロセスをプロセス実行部に引き渡す。
【００９７】
ステップ６：起動条件を満たしているプロセスを実行する。プロセス実行部では、プロセス定義に従いプロセスを実行する。実行中に企業内業務システムと情報のやり取りを行なう際は、業務システム接続部を通して通信を行なう。プロセスの実行により出力メッセージが生成されると、メッセージ送信部に渡される。
【００９８】
ステップ７：生成されたメッセージを送信する。メッセージ送信部では、プロセスフロー読み込みが保持しているプロセスの出力メッセージの送り先に従い、メッセージを送信する。
【００９９】
以下に具体例として、図１６、図１７、図１９、図２０、図２２、図２４の定義を元に発注者のロールのシステムが発注情報メッセージを受信した場合の処理の流れを説明する。
【０１００】
ステップ1：メッセージを受信する。図２９に示したメッセージを受信し内容の解析を行ない、発注情報メッセージであることを検出する。
【０１０１】
ステップ２：受信したメッセージを入力とするプロセスを検索する。発注情報メッセージを入力とするプロセスを検索する。標準SCMモデルより、発注情報メッセージはパターン１の発注数量確定プロセスとパターン２の発注数量確定プロセスが入力としていることが分かる。ところがコラボレーション定義には、受発注のパターン１を使用することが記述されているため、検索結果としてパターン１の発注数量確定プロセスを得る。
【０１０２】
ステップ３：検索したプロセスにメッセージをセットし、"実行待ち"の状態にする。パターン１の発注数量確定プロセスに発注情報メッセージをセットし、プロセス状態管理部に引き渡す。
【０１０３】
ステップ４：入力メッセージが全てそろっている"実行待ち"のプロセスを検索する。標準SCMモデルより、パターン１の発注情報確定プロセスは発注情報メッセージのみを入力メッセージとすることが分かる。そのため、プロセス状態管理部は、メッセージが全てそろったものとみなし、プロセススケジューラに引き渡す。
【０１０４】
ステップ５：実行時刻に達しているプロセスを検索する。
【０１０５】
プロセス定義より、パターン１の発注情報確定プロセスの実行時刻の定義は"14:00"であることが分かる。そのため、プロセススケジューラは14:00となった時点で、プロセス実行部に引き渡す。
【０１０６】
ステップ６：起動条件を満たしているプロセスを実行する。プロセス定義より、パターン１の発注情報確定プロセスの処理内容は"jp.co.ulsystems.bm.Process1"であることが分かる。そのため、プロセス実行部は該当クラスを呼び出し実行する。なお、この処理により図３０に示される発注確定情報メッセージが作成される。
【０１０７】
ステップ７：生成されたメッセージを送信する。標準SCMモデルより、パターン１の発注確定プロセスの発注確定情報メッセージは、受信者に送られることが分かる。また、コラボレーション定義より受注者は"company2.com"であることが分かるため、メッセージ送信部では、"company2.com"に対して発注確定情報メッセージを送信する。
【０１０８】
次に、ロールによるプロセスフロー選択の内部処理の実行手順について説明する。
【０１０９】
図２６は標準SCMモデル、コラボレーション定義、ロールを元に自システムで実行できるプロセスを抽出する手順について示している。
【０１１０】
ステップ１：標準SCMモデルを読み込む。プロセスフロー読み込みモジュールが標準SCMモデルを読み込み、内容を保持する。
【０１１１】
ステップ２：コラボレーション定義を読み込む。プロセスフロー読み込みモジュールがコラボレーション定義を読み込み、内容を保持する。
【０１１２】
ステップ３：自システムのロールを取得する。プロセスフロー読み込みモジュールがロール定義を読み込み、内容を保持する。
【０１１３】
ステップ４：標準SCMモデルの中からコラボレーション定義に書かれたパターンを検索する。標準SCMモデルで定義されたパターンの中からコラボレーション定義で記述されているパターンを選択し、そのパターンに含まれるプロセスを抽出する。該当パターンが存在しないときはエラーを通知する。
【０１１４】
ステップ５：パターンの中から自システムのロールに対応するプロセスを検索する。ステップ４で抽出したプロセスの中から、ロール定義で定義されたロールのプロセスを抽出する。
【０１１５】
ステップ６：検索されたプロセスをシステムで保持する。ステップ５で抽出されたプロセスをシステムで保持し、必要に応じてプロセス選択部やメッセージ送信部に情報を引き渡す。
【０１１６】
以下に具体例として、図１６、図１７、図１９、図２０、図２２の定義を元に発注者のロールのシステムがプロセスを選択する場合の処理の流れを示す。
【０１１７】
ステップ１：標準SCMモデルを読み込む。図１７に示されている標準SCMモデルを読み込む。
【０１１８】
ステップ２：コラボレーション定義を読み込む。図２０に示されているコラボレーション定義を読み込む。
【０１１９】
ステップ３：自システムのロールを取得する。図２２に示されているロール定義を読み込む。
【０１２０】
ステップ４：標準SCMモデルの中からコラボレーション定義に書かれたパターンを検索する。コラボレーション定義より、受発注のパターン１、入荷・出荷のパターン２、仕入・売上のパターン１を使用することが分かる。そのため、標準SCMモデルより、受発注パターン１の発注数量確定、受注回答、発注確定プロセスと入荷・出荷パターン２の出荷指示、出荷、入荷検品プロセスと仕入・売上パターン１の仕入仮計上、売上計上、違算調整プロセスを抽出する。
【０１２１】
ステップ５：パターンの中から自システムのロールに対応するプロセスを検索する。自ロールが発注者のため、受発注パターン１の発注数量確定、発注確定プロセスと入荷・出荷パターン2の入荷検品プロセスと仕入・売上パターン１の仕入仮計上、違算調整プロセスを抽出する。
【０１２２】
ステップ６：検索されたプロセスをシステムで保持する。ステップ５で抽出されたプロセスをシステムで保持し、必要に応じてプロセス選択部やメッセージ送信部に情報を引き渡す。
【０１２３】
（実施例の変形例）
上記の実施例の構成では、各企業がそれぞれ独立にシステムを動作させ、他の企業で動作しているシステムとの処理の連携は、送受信する取引メッセージを媒介にすることによって実現する構成になっている。このような構成は、各企業で個別最適なシステムを構築することができるという利点がある。
【０１２４】
しかしながら、本発明の実施は必ずしもこのような構成に限るものではない。全てあるいは複数の企業で実施するべきプロセスをすべて実施することのできるシステムを動作させる拠点を設け、各企業はネットワークを介してシステムに対して必要な取引メッセージを入出力することだけを行なうように構成しても構わない。
【０１２５】
また上記の実施例の構成では、メインモジュールが必要なプロセス定義の読み込みというフローの定義時の動作と、メッセージ受信時のプロセス実行の両方を行っている。
【０１２６】
プロセス定義とプロセス実行を別のシステムによって実行するような構成をとっても構わない。例えば、プロセスの実行は標準的な企業内のアプリケーション連携のためのシステムを利用し、プロセスの定義としてそのシステムが解釈できるフロー記述を生成するような構成にしても構わない。
【０１２７】
例えば、BPEL4WSの記述を生成することで、こうした準拠したアプリケーション連携システムのフローを定義することができる。上記実施例にて具体的に説明したような、発注者のロールのシステムが発注情報メッセージを受信した際に企業内連携のために実行するフローは、図２７のようになる。図２８はこのフローをXML形式によって記述した例である。
【産業上の利用可能性】
【０１２８】
本発明に係る標準ＳＣＭシステムは、ＳＣＭの全体のフローを記述することができ、複数拠点にまたがる取引フローを、各拠点が自律的に動作することで、全体のフロー制御を協調的に動作させることが実現でき、産業上有用である。
【図面の簡単な説明】
【０１２９】
【図１】実施形態１に係る標準ＳＣＭシステムの機能ブロック図
【図２】複数のモジュール保持部の一例図
【図３】入出力プロトコルの一例図
【図４】プロセスパターンの一例図
【図５】出荷拠点モジュールの生成するプロセスが関係したプロトコルの一例図
【図６】実施形態３に係る標準ＳＣＭシステムの機能ブロック図
【図７】実施形態３に係る標準ＳＣＭシステムの別の機能ブロック図
【図８】実施形態４に係る標準ＳＣＭシステムの機能ブロック図
【図９】発注確定プロセスが加わったプロセスパターンの一例図
【図１０】実施形態５に係る標準ＳＣＭ設定装置の機能ブロック図
【図１１】ロール定義情報選択結果情報を取得するための画面の一例図
【図１２】プロセスパターン選択結果情報を取得するための画面の一例図
【図１３】標準ＳＣＭシステムの設定を行なっている状態の一例図
【図１４】プロセスフロー実行エンジンの機能ブロック図
【図１５】標準SCMモデルの構造図
【図１６】標準SCMモデルの全体の一例図
【図１７】標準SCMモデルをXMLで記述した一例図
【図１８】コラボレーション定義の構造図
【図１９】コラボレーション定義によるプロセスフローの選択の一例図
【図２０】コラボレーション定義のXMLによる記述の一例図
【図２１】ロール定義の構造図
【図２２】ロール定義のXMLによる記述の一例図
【図２３】プロセス定義の一例図
【図２４】プロセス定義のXMLによる記述の一例図
【図２５】プロセスフロー制御のフローチャート
【図２６】ロールによるプロセス選択のフローチャート
【図２７】受発注数量確定プロセスにおいて企業内連携のための処理のフローチャート
【図２８】発注数量確定プロセスのXMLによる記述の一例図
【図２９】発注情報メッセージのXMLによる記述の一例図
【図３０】発注数量確定情報メッセージのXMLによる記述の一例図
【符号の説明】
【０１３０】
１００  標準ＳＣＭシステム
１０１  モジュール保持部
１０２  プロトコル保持部
１０３  処理実行部
１０４  発注者モジュール
１０５  受注者モジュール
【図１】
2006178690.tif 000003
【図２】
2006178690.tif 000004
【図３】
2006178690.tif 000005
【図４】
2006178690.tif 000006
【図５】
2006178690.tif 000007
【図６】
2006178690.tif 000008
【図７】
2006178690.tif 000009
【図８】
2006178690.tif 000010
【図９】
2006178690.tif 000011
【図１０】
2006178690.tif 000012
【図１１】
2006178690.tif 000013
【図１２】
2006178690.tif 000014
【図１３】
2006178690.tif 000015
【図１４】
2006178690.tif 000016
【図１５】
2006178690.tif 000017
【図１６】
2006178690.tif 000018
【図１７】
2006178690.tif 000019
【図１８】
2006178690.tif 000020
【図１９】
2006178690.tif 000021
【図２０】
2006178690.tif 000022
【図２１】
2006178690.tif 000023
【図２２】
2006178690.tif 000024
【図２３】
2006178690.tif 000025
【図２４】
2006178690.tif 000026
【図２５】
2006178690.tif 000027
【図２６】
2006178690.tif 000028
【図２７】
2006178690.tif 000029
【図２８】
2006178690.tif 000030
【図２９】
2006178690.tif 000031
【図３０】
2006178690.tif 000032