JP2005115930A - 第１のコンピュータと第２のコンピュータとの間の通信プロトコルを確立するための方法 - Google Patents

Abstract

【課題】 自己記述型ビジネス文書コラボレーションプロトコルを実現する。
【解決手段】 情報を処理するための命令を有するコンピュータ読取り可能媒体を提供する。そのような命令は、活動シーケンスにおいて交換されるビジネスエンティティの構造を定めるビジネスエンティティモジュールと、ビジネストランザクションで用いられる関連活動の活動シーケンスを定めるエンティティ活動モジュールと、そのような活動シーケンスおよびそのようなビジネスエンティティモジュールに基づいて、対応する規定文書を作成するトランザクション文書モジュールとを含む。
【選択図】 図３

Description

本発明は、第１のコンピュータと第２のコンピュータとの間の通信プロトコルを確立するための方法に関する。より詳細には、本発明は、ビジネスネットワークコンピューティング環境におけるビジネス文書の共同交換に関し、より具体的には、ビジネスネットワークを介して通信するビジネスパートナー間のビジネス文書の交換を管理する企業間プロセス調整プロトコル（企業間トランザクションプロトコル）を確立することに関連した、第１のコンピュータと第２のコンピュータとの間の通信プロトコルを確立するための方法及び記録媒体並びにビジネスネットワークに関する。

ビジネスは、典型的には、会計、支払い、人的資源、従業員追跡、顧客関連追跡などのビジネス運用プロセスの制御および分析を行うための様々な機構を使用してきた。これらのプロセスを支援し、制御し、調整するツールは、しばしばコンピュータソフトウェアを用いて具現化される。例えば、あるソフトウェアパッケージは、ビジネス会計を管理することができ、他のソフトウェアパッケージは新たな注文の受注を担うことができ、さらに他のソフトウェアパッケージは在庫目録を追跡し、さらなるソフトウェアパッケージは注文処理および出荷を扱う。他の環境において、企業間トランザクションを行うことができるように、あるビジネスによって動作されるビジネスソフトウェアパッケージが、他のビジネスによって動作されるソフトウェアパッケージとデータを交換することが必要になる。

現行の企業間トランザクションの実装は、様々な文書交換および通信ネットワークプロセスを用いて、ビジネスパートナー間のトランザクションを行う。現行のプロセスは有効でありうるが、そのようなプロセスの多くは、ビジネスコラボレーションプロトコルの規則によって管理される連続した通信文書交換のシーケンスによってビジネスパートナー間で調整されていないため、それらの実装は誤差を生じやすく、膨大な時間および費用を要する。その結果、ビジネスアプリケーション開発者が、文書交換プロトコルのそれらのコンピュータ実装をカスタマイズし、具現化し、試験し、維持することが困難になっている。

例えば、注文から換金までのプロセスは、価格表、注文票、発注の承認、出荷通知および請求書を使用してサプライヤと顧客の間の通信文書のシーケンスを含みうる。これらの文書がそれらのビジネス運用プロセスに組み込まれなければ、手動データ入力による誤差が生じ、パートナー間の複数の文書転送により不十分なプロセスになってしまう可能性がある。

したがって、連結トランザクション文書のシーケンスを開発することで、ビジネストランザクションを完了するための費用および時間が低減されることになるであろう。加えて、ビジネスアプリケーション開発者が、カスタマイズされたトランザクションシーケンスのすべての部分（送受信）を定めることを可能にすることで、具現化および維持のための時間および費用効果のより高い確実でユーザフレンドリーなビジネスネットワーキング環境が可能になるであろう。

本発明は、このような状況に鑑みてなされたもので、その目的とするところは、自己記述型ビジネス文書コラボレーションプロトコルを実現する、第１のコンピュータと第２のコンピュータとの間の通信プロトコルを確立するための方法を提供することにある。

情報を処理するための命令を有するコンピュータ読取り可能な記録媒体を提供する。そのような命令は、活動シーケンスにおいて交換されるビジネスエンティティの構造を定めるビジネスエンティティモジュールと、ビジネストランザクションで用いられる関連活動の活動シーケンスを定めるエンティティ活動モジュールと、複数のトランザクション文書を定め、活動シーケンスおよびビジネスエンティティモジュールに基づいて対応する文書を作成するトランザクション文書モジュールとを含む。

本発明の他の態様は、第１のコンピュータと第２のコンピュータとの間の通信プロトコルを確立するための方法である。そのような方法は、トランザクションに関連づけられた複数の文書を識別し、複数の文書に対する活動シーケンスに対する活動を定めることを含む。さらに、そのような複数の文書の１つは、活動シーケンスに基づいて作成される。

本発明のさらなる態様は、プロセステンプレートを含むメモリを備えた第１のコンピュータを有するビジネスネットワークを含む。そのようなプロセステンプレートは、活動シーケンスにおいて交換されるビジネスエンティティの構造を定めるビジネスエンティティモジュールと、ビジネスエンティティに対して行うことができる関連活動の活動シーケンスを定めるエンティティ活動モジュールとを含む。トランザクション文書モジュールは、トランザクション文書を定め、ビジネスエンティティのモジュールおよび活動シーケンスに基づいて対応する文書を作成する。そのようなネットワークは、プロセステンプレートのコピーを含むメモリを有する第２のコンピュータをも含む。第２のコンピュータは、プロセステンプレート、および第１のコンピュータと第２のコンピュータとの関係に基づいて活動を行う。

本発明によれば、自己記述型ビジネス文書コラボレーションプロトコルを実現することができる。

以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。本発明は、コンピュータソフトウェアにおけるビジネス論理の実装に関する。本明細書ではビジネストランザクションに用いられるビジネス論理の実装に関して説明するが、本発明は、概してオブジェクトに対するいくつかの特性にまたがる他のタイプの論理にも適用されうる。しかし、本発明についてより詳細に述べる前に、本発明を使用することができる例示的な環境の一実施形態について述べる。

図１は、本発明を具現化できる好適なコンピューティングシステム環境１００の例を示す図である。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲に関して、何ら制限を示唆することを意図するものではない。コンピューティングシステム環境１００は、例示的なオペレーティング環境であるコンピューティングシステム環境１００に示される構成要素のいずれか１つまたは組合せに関連する依存性または要件を有するものと解釈されるべきではない。

本発明は、多くの他の汎用または専用のコンピューティングシステム環境または構成で動作可能である。本発明との使用に適するよく知られたコンピューティングシステム、環境および／または構成の例としては、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム式家庭用電化製品、ネットワークＰＣ（personal computer）、ミニコンピュータ、大型コンピュータ、上記システムまたはデバイスのいずれかを含む分散コンピューティング環境等が挙げられるが、それらに限定されない。

コンピュータによって実行されるプログラムモジュールの如きコンピュータ実行可能命令の一般的な状況で本発明を説明することができる。一般に、プログラムモジュールは、特定の作業を行うか、または特定の抽象データ型を具現化するルーチン、プログラム、オブジェクト、構成要素、データ構造等を含む。通信ネットワークを通じて連結されるリモート処理デバイスによって作業を行う分散コンピューティング環境において、本発明を実施することもできる。分散コンピューティング環境において、メモリ記憶デバイスを含むローカルおよびリモートコンピュータ記憶媒体の両方にプログラムモジュールを配置できる。プログラムおよびモジュールによって行われる作業を以下に、図面を利用して説明する。当業者は、任意の形のコンピュータ読取り可能媒体に書き込むことができるプロセッサ実行可能命令としてそのような説明および図を具現化することができる。

図１を参照すると、本発明を実施するための例示的なシステムは、コンピュータ１１０の形の汎用コンピューティングデバイスを含む。コンピュータ１１０の構成要素としては、プロセッサ１２０、システムメモリ１３０、およびシステムメモリ１３０を含む様々なシステム構成要素をプロセッサ１２０に結合するシステムバス１２１を挙げることができるが、それらに限定されない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、様々なバス構成のいずれかを用いたローカルバスを含むいくつかのタイプのバス構造体のいずれかであってもよい。限定ではなく、例示を目的として、そのようなアキテクチャとしては、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが挙げられる。

コンピュータ１１０は、典型的には、様々なコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータ１１０によってアクセスでき、揮発性および不揮発性のリムーバブルおよびノンリムーバブル媒体を含む利用可能な任意の媒体でありうる。限定ではなく例示を目的として、コンピュータ読取り可能媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュールまたは他のデータの如き情報を記憶するための任意の方法または技術で具現化される揮発性および不揮発性のリムーバブルおよびノンリムーバブル媒体を含む。コンピュータ記憶媒体としては、ＲＡＭ（random access memory）、ＲＯＭ（random access memory）、ＥＥＰＲＯＭ（electrically erasable programmable read-only memory）、フラッシュメモリまたは他のメモリ技術、ＣＤ（compact disc）−ＲＯＭ、ＤＶＤ（Digital Versatile Disc）または他の光ディスク記憶機構、磁気カセット、磁気テープ、磁気ディスク記憶機構または他の磁気記憶デバイス、あるいは所望の情報を記憶するのに使用でき、コンピュータ１１０によってアクセスできる任意の他の媒体を挙げられるが、それらに限定されない。通信媒体は、典型的には、コンピュータ読取り可能命令、データ構造、プログラムモジュール、あるいは搬送波または他の伝達機構の如き変調データ信号内の他のデータを具体化し、任意の情報配信媒体を含む。「変調データ信号」という用語は、その特徴の１つまたは複数の特徴を信号内の情報を符号化するように設定または変更する信号を意味する。限定ではなく、例示を目的として、通信媒体としては、有線ネットワークまたは直接配線接続の如き有線媒体、音響、ＲＦ（radio frequency）、赤外線および他の無線媒体の如き無線媒体が挙げられる。上記いずれかの組合せもコンピュータ読取り可能媒体の範囲に含まれるものとする。

システムメモリ１３０は、読出し専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２の如き揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。起動時などにコンピュータ１１０内の要素間で情報を転送するのに役立つ基本ルーチンを含むＢＩＯＳ（Basic Input/Output System）１３３は、典型的には、ＲＯＭ１３１に記憶される。ＲＡＭ１３２は、典型的には、プロセッサ１２０に直接アクセス可能で、かつ／またはプロセッサ１２０によって現在動作されているデータおよび／またはプログラムモジュールを含む。限定ではなく、例示を目的として、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６およびプログラムデータ１３７を示す。

コンピュータ１１０は、他のリムーバブル／ノンリムーバブル揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。例示のみを目的として、図１は、ノンリムーバブル不揮発性磁気媒体に対する読取りまたは書込みを行うハードディスクドライブ１４１、リムーバブル不揮発静磁気ディスク１５２に対する読取りまたは書込みを行う磁気ディスクドライブ１５１、およびＣＤ ＲＯＭまたは他の光媒体の如きノンリムーバブル不揮発性光ディスク１５６に対する読取りまたは書込みを行う光ディスクドライブ１５５を示す。例示的なオペレーティング環境で使用することができる他の着脱式／ノンリムーバブル揮発性／不揮発性コンピュータ記憶媒体としては、磁気テープカセット、フラッシュメモリカード、ＤＶＤ、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ等が挙げられるが、それらに限定されない。ハードディスクドライブ１４１は、典型的には、インタフェース１４０の如きノンリムーバブルメモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、典型的には、インタフェース１５０の如きリムーバブルメモリインタフェースによってシステムバス１２１に接続される。

上述し、図１に示したドライブおよびそれに関連づけられたコンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、およびコンピュータ１１０に対応した他のデータの記憶機構を提供する。例えば、図１において、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６およびプログラムデータ１４７を記憶するものとして示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６およびプログラムデータ１３７と同じであっても異なっていてもよいことに留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、プログラムデータ１４７には、最低限、それらが異なるコピーであることを示すためにコピーであることを示すために、異なる番号が与えられている。

ユーザは、キーボード１６２、マイクロフォン１６３、およびマウス、トラックボールまたはタッチパッドの如きポインティングデバイス１６１のような入力デバイスを通じて、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力デバイス（不図示）としては、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ等を挙げることができる。これらおよび他の入力デバイスは、システムバスに結合されるユーザ入力インタフェース１６０を通じてプロセッサ１２０にしばしば接続されるが、平行ポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）の如き他のインタフェースおよびバス構造体によって接続することもできる。モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインタフェース１９０の如きインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは、出力周辺インタフェース１９５を通じて接続できるスピーカ１９７およびプリンタ１９６の如き他の周辺出力デバイスを含むことができる。

コンピュータ１１０は、リモートコンピュータ１８０の如き１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードであってもよく、典型的には、コンピュータ１１０に相対的な上記の要素の多くまたはすべてを含む。図１に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。そのようなネットワーキング環境は、オフィス、企業内コンピュータネットワーク、イントラネットおよびインターネットにおいて広く使用されている。

コンピュータ１１０は、ＬＡＮネットワーキング環境で使用されるときは、ネットワークインタフェースまたはアダプタ１７０を通じてＬＡＮ１７１に接続される。コンピュータ１１０は、ＷＡＮネットワーキング環境で使用されるときは、典型的には、モデム１７２、またはインターネットの如き、ＷＡＮ１７３を介した通信を確立する他の手段を含む。内部にあっても外部にあってもよいモデム１７２を、ユーザ入力インタフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境において、コンピュータ１１０に相対的に示されているプログラムモジュールまたはその部分をリモートメモリ記憶デバイスに記憶することができる。限定ではなく、例示を目的として、図１は、リモートコンピュータ１８０上にあるリモートアプリケーションプログラム１８５を示す。示されているネットワーク接続は例示的なものであって、コンピュータ間の通信リンクを確立する他の手段も使用できることが理解されるであろう。

図２は、ビジネスネットワーク環境の簡易構成図である。そのようなネットワーク環境において、ハブビジネスサーバ２００が、サーバ２０１、サーバ２０２、サーバ２０３およびサーバ２０４を含むいくつかの他のスポークビジネスサーバに接続されている。ビジネスパートナーは、サーバ２０１〜２０４に関連づけられ、サーバ２００に関連づけられたハブパートナーとビジネス関係を有する。一例において、ハブパートナーはサプライヤであり、他のスポークパートナーはハブパートナーの顧客である。

本発明の一実施形態によれば、ハブパートナーは、複数のトランザクション文書を含むビジネストランザクションを実施するためのプロトコルを定めるサーバ２００上のプロセステンプレートを設定し、定めることができる。スポークサーバ２０１〜２０４は、ハブサーバからのプロセステンプレートのコピーを要求し、それを保持することができ、あるいはプロセステンプレートにアクセスすることができる。プロセステンプレートを使用して、ビジネスパートナーは、それらの内部ビジネスプロセスを容易に整理し、統合することができる。この整理および統合は、一斉に動作して、調整文書交換シーケンスを提供するビジネスパートナー間のビジネストランザクション文書の送受信の管理／制御を行う一組のプロトコル規則を作成することによって達成される。さらに、プロセステンプレートは、文書に書き込まれた情報および文書上の活動が、交換に先立ってプロセステンプレートに照らし合わせて検証されるように、有効文書および活動を定める。

図３は、関連アプリケーションサーバ上のプロセステンプレートを利用して、ビジネストランザクションに関連する文書を交換する２つのビジネスパートナー間のコラボレーション環境のより詳細な構成図である。アプリケーションサーバ２１０およびアプリケーションサーバ２１２は、ともに、それぞれビジネスネットワークサーバソフトウェアモジュール２１４および２１６を含む。それぞれのビジネスサーバソフトウェアモジュール２１４および２１６は、様々な異なる通信手段を通じて互いに通信することができる。例えば、サーバ２１０と２１２の間にピアツーピア接続２１８を確立できる。他の実施形態において、ビジネスサーバソフトウェアモジュール２１４および２１６は、仮想プライベートネットワーク（例えば、ワシントン州レドモンドのマイクロソフトコーポレーションが提供するマイクロソフトビジネスネットワーク（商標））、またはインターネットのような公衆網の一部である中間ホスト２２０を通じて通信することができる。

サーバ２１０は、複数のプロセステンプレート２２２および複数のアプリケーション２２４を含む。同様に、サーバ２１２は、複数のプロセステンプレート２２６および複数のアプリケーション２２８を含む。一実施形態において、プロセステンプレート２２２および２２６は、一組のビジネス文書定義、１つまたは複数のコラボレーション定義、および１つまたは複数のアプリケーション統合プロフィルを含む。そのような一組の文書定義は、プロセステンプレートに関連づけられた文書、例えば価格表または出荷通知を識別する。コラボレーション定義は、文書を関連づけ、閲覧し、作成する方法を定める。例えば、定義は、サプライヤの価格表を発注書に関連づける方法、価格表から発注書を作成する方法、発注書をユーザが閲覧する方法、および発注書をサプライヤに伝送する方法を規定することができる。また、アプリケーション統合プロフィルは、プロセステンプレートおよび関連文書を様々なアプリケーションと一体化する方法を定める。

プロセステンプレートを利用するための動作の一様式において、サーバ２１０は、プロセステンプレートパブリッシャハブサーバであり、サーバ２１２はプロセステンプレートサブスクライバである。パブリッシャによってプロセステンプレートを選定されたサブスクライバ、例えばパブリッシャ企業と共同することに同意したサブスクライバ企業に伝えることができる。プロセステンプレートパブリッシャは、サブスクライバが、プロセステンプレートのコラボレーションプロトコルのローカルコピーのないトランザクション文書を受け取る場合に、サブスクライバに伝えられるプロセステンプレートをホストすることができる。プロセステンプレートは、どのようにして文書を関連づけ、閲覧し、変換し、承認できるかを定める。プロセステンプレートを使用して、サブスクライバは、パブリッシャとの共同トランザクション文書交換関係を築いて、彼らのビジネスプロセスとパブリッシャのビジネスプロセスを一体化する。

図４は、ビジネスプロセスの整理および統合を行うために開発された例示的なプロセステンプレート２３０を図解した図である。プロセステンプレート２３０は、ビジネスプロセスを実行するときに追従すべきシーケンスを定めるための様々な要素を含むことができる。プロセステンプレートは、ビジネスコラボレーションプロトコルを実施するためのビジネスエンティティとトランザクション文書との組合せを定める。

エンティティは、発注、請求書または出荷通知のようなビジネスコラボレーションプロトコルの特定部分に対する情報ビルディングブロックを含む。トランザクション文書は、ビジネスパートナー間で交換される電子文書で、発注書の完成の如きエンティティに対する特定の活動を実行するのに必要とされる情報を含むことができる。トランザクション文書は、文書の追跡、相関付けおよび表示を行うとともに、受け取ったトランザクション文書の承認を行うためのプロセステンプレート２３０に対する参照を含む。

ビジネスエンティティモジュール２３２は、活動シーケンスを実行して、ビジネスプロセスを完了するためのプロセステンプレート２３０に関連づけられたエンティティおよびトランザクション文書に対する有効構造を定める。エンティティの構造は、トランザクション文書の各々を構成する変動要素、スキームなどに関係する。エンティティ、および活動の定められたシーケンスに基づき、関連トランザクション文書モジュール２３４でトランザクション文書を作成することができる。

活動シーケンスをさらに定めるために、プロセステンプレート２３０は、エンティティモジュール２３２およびトランザクション文書モジュール２３４に関連して動作するバージョン識別子２３６、表示モジュール２４０、エンティティアクションモジュール２４２、ルーティングモジュール２４４および相関モジュール２４６を含む。プロセステンプレート２３０内の各々の要素は、企業が取引先との共同ソリューションを確立することを可能にする。

バージョン識別子２３６は、プロセステンプレート２３０に対する特定バージョンに対する参照である。スポークサーバは、バージョン識別子２３６を使用して、プロセステンプレートの特定バージョンがそこに記憶されているかどうかを判断することができる。トランザクション文書がスポークサーバによって受信され、関連するプロセステンプレートが局所的に記憶されない場合、スポークサーバは、プロセステンプレートの送信を要求する。プロセステンプレートが記憶された後に、プロセステンプレートの要素によって定められたプロトコル規則によって管理される共同関係が確立される。

表示モジュール２４０は、各々のトランザクション文書を様々なアプリケーションで表示する方法を定める。例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ（登録商標）の如き電子メールプログラム、あるいはＭｉｃｒｏｓｏｆｔ（登録商標） Ｅｘｃｅｌ（商標）またはＭｉｃｒｏｓｏｆｔ（登録商標） ＩｎｆｏＰａｔｈ（商標）の如き他のプログラムでトランザクション文書を表示することができる。これらの表示定義を提供することによって、プロセステンプレートは、様々なクライアントおよびバックオフィスアプリケーションとの統合を容易にすることが可能である。

エンティティ活動モジュール２４２は、プロセステンプレート２３０に関連づけられたビジネスエンティティモジュール２３２によって定められたビジネスエンティティに対して実行できる有効活動を定める。そのような活動は、ビジネスエンティティの生成、承認および準備を含む。トランザクション文書を使用して、ビジネスエンティティに対する活動を伝達する。例えば、サプライヤと顧客の関係における顧客は発注書を生成することが可能になり、サプライヤは、エンティティアクションモジュール２４２に基づいて発注書を承認することが可能になる。他の例は、顧客が価格表から発注書を準備することが可能になる場合である。

ルーティングモジュール２４４は、トランザクション文書に対するルーティング規則を定める。これらのルーティング規則は、モジュール２３４によって定められた各々のトランザクション文書に対するルーティングプロトコルを規定し、確立するのに役立つ。相関モジュール２４６は、履歴においてこれらのトランザクション文書の各々を関連づける方法を定める。例えば、発注書承認のシーケンスに追従される発注書、出荷指示および商品領収トランザクション文書を、ビジネストランザクションと見なすことができるトランザクション履歴において相関づける。

図５は、注文から換金までのビジネストランザクションにおける文書の交換についての例示的な流れ図である。この例示的な流れ図において、サーバ２１０はサプライヤを表し、サーバ２１２は顧客を表す。プロセステンプレート２２２は、ハブサーバに記憶されたマスタプロセステンプレートで、マスタプロセステンプレートのコピーであるプロセステンプレート２２６は、上述のように、関連サーバがサプライヤであるか顧客であるかに関連した情報を含み、それに応じて文書を処理することができる。

ステップ２５０において、入手可能な製品の価格表はサーバ２１０上で生成される。一実施形態において、プロセステンプレート２２２および表計算プログラムを用いて作成される。プロセステンプレート２２２は、価格表生成活動はサプライヤに関連づけられており、サプライヤのみが価格表を顧客に伝送するため、誤差を防ぐためには、サプライヤが価格表を準備し、伝送することを可能にするだけでよいことを把握している。

次いで、プロセステンプレート２２２を使用して、価格表をサーバ２１２に送る。サーバ２１２がプロセステンプレート２２２、またはコピー２２６の如きプロセステンプレート２２２のローカルコピーにアクセスしない場合は、プロセステンプレートをサーバ２１２に送るよう要求する。

プロセステンプレート２２２は、価格表をどこに送るべきかを把握するために、顧客のビジネス識別子を使用する。例えば、パートナーオペレーティングサーバ２１０は、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ（登録商標）の如き生産性プログラムにおけるコンタクトを識別することができる。プロセステンプレート２２２はプログラムと一体化して、そのようなコンタクトのルーティング情報を識別することができる。

さらに、プロセステンプレート２２２は、文書をサーバ２１２に送信する前に作成された価格表に対する検証規則を含むことができる。プロセステンプレート２２６のコピーは、価格表を受信した後に、価格表をステップ２５２で閲覧できるように表示する。そのような表示は、表示モジュール２４０（図４）、および顧客に関連づけられているプロセステンプレート２２６に関連する情報に基づいて行われる。価格表を閲覧した後に、サーバ２１２は、顧客から受信した活動に基づいて、ステップ２５４において発注書を生成することができる。プロセステンプレート２２６は、それが顧客に関連づけられていることを把握し、発注書を作成、生成するために価格表のなかのメニュー品目を提示することができる。

サーバ２１２上で発注書を生成した後で、発注書をプロセステンプレート２２６によりサーバ２１０に送る。発注書を受信した後で、プロセステンプレート２２２は、サーバ２１０上で販売注文書を表示することができ、ステップ２５６においてそれを閲覧することができる。プロセステンプレート２２２はサプライヤに関連づけられているため、文書は販売注文書と見なされる。

ステップ２５８において、注文の承認を準備する。次いで、注文の承認をサーバ２１２に送信し、ステップ２６０においてそれを閲覧することができる。注文した製品が出荷されると、サーバ２１０は、ステップ２６２において出荷通知を準備することができる。次いで、出荷通知をサーバ２１２に送信することができ、ステップ２６４においてそれを閲覧することができる。さらに、ステップ２６６において請求書を生成し、サーバ２１２に送信することができ、ステップ２６８においてそれを閲覧することができる。

上述のプロセステンプレートを使用した結果として、パートナー間でビジネスプロセスの統合および整理を容易に行うための活動シーケンスを定めることができる。そのような活動シーケンスは、どの活動をどのシーケンスで実行するかを定める。プロセステンプレートは、企業、その金融業者、通信事業者、ロジスティックプロバイダ等を含む様々なビジネス環境で具現化されうる。歯科医／保険会社の関係のようなサービス産業。

ソフトウェアのパターンおよび実践に熟達した者であれば、上述のプロセステンプレートを使用して他のプロセスおよびトランザクションを具現化できることを認識するであろう。例えば、サプライヤビジビリティ（visibility）プロセステンプレートにより、製造業者が、サプライヤからの個別的な注文ライン品目の生産状況となるのが可能になる。例えば、顧客は、プロセス中半製品（work-in-process）要求を製造業者／サプライヤに送信することができる。サプライヤは、注文されている品目の各々に対する状況に対応し、それに応じて応答することができる。

本発明を特定の実施形態に関して説明したが、本発明の主旨および範囲から逸脱することなく形態および詳細を変更できることを当業者なら認識するであろう。

（米国特許仮出願第６０／５０９，６３０号の開示）
本出願は、その内容が参照により全面的に本明細書に組み込まれている、２００３年１０月８日に出願した米国特許仮出願第６０／５０９，６３０号に基づいており、その有益性を主張する。
以下、米国特許仮出願第６０／５０９，６３０号の内容を開示する。その内容は、ｐａｒｔ１〜３から構成されており、それらを順に開示する。

＜ ｐａｒｔ１ ＞
発明の名称：自己記述型ビジネス文書コラボレーションプロトコル（Self-Describing Business-Document Collaboration Protocols）

はじめに：Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｂｕｓｉｎｅｓｓ Ｎｅｔｗｏｒｋ（ＭＢＮ（商標）（商標））Ｖｅｒｓｉｏｎ １．０の主な機能は、自己記述型ビジネスコラボレーションプロトコルの定義、配布および実行である。ビジネスパートナー（顧客、サプライヤ、通信事業者、金融業者、保険業者など）は各自のビジネス文書交換の調整や検証にこのプロトコルを使用する。

自己記述型ビジネスコラボレーションプロトコルの目的は、ビジネスパートナーが内部ビジネスプロセスの調整（サプライヤの新製品導入プロセスと顧客への製品調達プロセスの調整、顧客の発注プロセスとサプライヤへの販売注文プロセスの調整など）を容易にできるようにすることである。ビジネスパートナー同士が一連のビジネストランザクション文書（価格表、発注書、発注の承認、出荷指示、請求書など）を送受信し、プロセスを同期することによって、調整が行われる。

発明の説明：統合ソフトウェアベンダ（ＩＳＶ）、付加価値再販業者（ＶＡＲ）またはビジネスパートナーはプロセステンプレートを使用してコラボレーションプロトコルを定義する。プロセステンプレートでは、プロトコルのバージョン、交換文書の有効な構造、Ｅｘｃｅｌ（商標）フォームやＨＴＭＬ（Hyper Text Markup Language）フォームでの文書表示、トランザクション文書のビジネスエンティティで実行可能な一連のアクション（生成、承認、準備など）、文書のルーティング規則、文書履歴の文書をリンクするための文書の相関規則が定義される。

統合ソフトウェアベンダ（ＩＳＶ）、付加価値再販業者（ＶＡＲ）またはビジネスパートナーは、ＭＢＮ（商標）サーバをホストするコンピュータまたはリモートコンピュータのフォルダシステムにプロセステンプレートをインストールする。このフォルダ構造は、プロセステンプレートの解決されたＵｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｎａｍｅ（ＵＲＮ）に対応する。このＵＲＮは交換される各文書の一部で、プロセステンプレートプロファイルにエンコードされる。

ビジネスユーザ（販売促進マネージャなど）はプロセステンプレートの特定のバージョンからＥｘｃｅｌ（商標）のトランザクション文書フォーム（価格表など）を作成して、対話（受注から現金回収まで（ｏｒｄｅｒｓ−ｔｏ−ｃａｓｈ））を開始する。プロセステンプレートでは、価格表を作成するビジネスパートナーがサプライヤであることが認識される。顧客は価格表を使用することしかしないためである。つまり、顧客は、新製品導入について顧客に通知するためにサプライヤのみが使用するフィールドが含まれた価格表を表示できる。

また、プロセステンプレートでは、価格表でサプライヤが実行できるアクションが、顧客への最初の価格表文書の送信のみであることが認識される。これにより、販売促進マネージャが選択する１つのＥｘｃｅｌ（商標）メニュー項目が返される。

販売促進マネージャはＥｘｃｅｌ（商標）フォームに顧客のビジネスＩＤ（identification）と価格表データを入力して、文書を生成する。プロセステンプレートは、Ｅｘｃｅｌ（商標）フォームから作成されたＸＭＬ（eXtensible Markup Language）文書に達し、顧客のビジネスＩＤを取得して、ＭＢＮ（商標）ルーティングＩＤに変換し、ＸＭＬ文書を検証して顧客のＭＢＮ（商標）サーバにその文書を送信する。

顧客のＭＢＮ（商標）サーバでは、ローカルハードディスクまたはリモートコンピュータのハードディスク（自己記述型ビジネスコラボレーションプロトコルの格納先）のテンプレートフォルダに、受信した文書の共同名前空間（ＵＲＮ）を解決しようとする。これにより、文書を検証して、Ｏｕｔｌｏｏｋ（登録商標）でＨＴＭＬプレビュー文書を作成できる。プロセステンプレートフォルダがない場合は、配布プロトコルによってサプライヤのＭＢＮ（商標）サーバにプロセステンプレートの要求と共にメッセージが返される。サプライヤの配布プロトコルは応答としてプロセステンプレートを送信する。このテンプレートは、顧客のＭＢＮ（商標）サーバのハードディスクのフォルダ構造（解決された共同名前空間（ＵＲＮ）に対応）にインストールされる。その後、電子メール通知はビジネスメールボックス（データベース）に配置され、Ｏｕｔｌｏｏｋ（登録商標）クライアントによって取得される。取得の際、Ｏｕｔｌｏｏｋ（登録商標）クライアントはプロセステンプレートからＨＴＭＬプレビュー文書を要求し、文書へのリンクが電子メールメッセージの添付ファイルとして追加される。

プロセステンプレートはビジネス文書に達し、各ビジネス文書を関連付けるためのビジネスＩＤ（価格表ＩＤ、発注ＩＤ、販売注文ＩＤなど）を取得する。これらの相関関係はＭＢＮ（商標）サーバに格納され、トランザクション履歴フォームに後で取得される。

顧客はＯｕｔｌｏｏｋ（登録商標）の添付ファイルからＥｘｃｅｌ（商標）を起動できる。Ｅｘｃｅｌ（商標）アドインによって、プロセステンプレートから対応するＥｘｃｅｌ（商標）フォームが取得される。プロセステンプレートでは顧客が価格表を起動していることが認識されるため、顧客が発注書を作成するのに必要なフィールドがＥｘｃｅｌ（商標）価格表フォームに配置される。サプライヤと顧客は同じ文書からフォームを起動するが、顧客のフォームはサプライヤのＥｘｃｅｌ（商標）価格表フォームとは異なる。プロセステンプレートは文書内の顧客またはサプライヤの会社キーデータとＭＢＮ（商標）サーバの会社キーに基づいて、生成するフォームを決定する。また、プロセステンプレートは、この文書で顧客が実行できるアクションを判別し、Ｅｘｃｅｌ（商標）に適切なメニュー項目を返す。

このビジネスコラボレーションの定義、配布および実行のサイクルは、新しいプロセステンプレートの各バージョンで繰り返される。古いプロセステンプレートのバージョンは決して削除されない。これらの古いプロセステンプレートを使用するトランザクション文書が処理中であったり、追跡や監査を目的としてトランザクション文書が再度開かれることがあるためである。

図とフローチャート：
図６は、ＭＢＮ（商標）システムの構成要素を示す図である。

＜ ｐａｒｔ２ ＞
Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｂｕｓｉｎｅｓｓ Ｎｅｔｗｏｒｋ（ＭＢＮ）（商標）
製品概要

ホワイトペーパー
２００３年８月

目次
はじめに．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．
ＭＢＮ（商標）の概要．．．．．．．．．．．．．．．．．．．．．．．．．．．．
企業間のプロセステンプレート．．．．．．．．．．．．．．．．．．．．
Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ（登録商標）の統合．．．．
Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｅｘｃｅｌ（商標）とＭＢＮ（商標） Ｅｘｃｅｌ（商標）アドイン．．．．
追加設定なしで使用できるプロセステンプレート．．．．．．．．．．．
信頼できるＷｅｂサービスネットワーク．．．．．．．．．．．．．．．
統合ビジネスメールボックス．．．．．．．．．．．．．．．．．．．
ＭＢＮ（商標）の格納と転送サービス（Store and Forward Service） ．．．．
ＭＢＮ（商標）接続．．．．．．．．．．．．．．．．．．．．．．．．．．．
セキュリティ、信頼性、プライバシー、ビジネスの整合性．．．．．．
ＭＢＮ（商標）でホストされるサービス．．．．．．．．．．．．．．．．．．．
プロセステンプレートダウンロードセンター．．．．．．．．．．．．
パートナー管理ツール．．．．．．．．．．．．．．．．．．．．．．

法律上の通知事項
このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものである。変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とはみなされないものとする。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もしない。

このホワイトペーパーに記載された内容は情報の提供のみを目的としており、明示または黙示にかかわらず、これらの情報についてマイクロソフトはいかなる責任も負わない。

ユーザは著作権に関する法律を遵守する必要がある。このドキュメントのいかなる部分も、米国マイクロソフトコーポレーションの書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含む。ただしこれは、著作権法上のお客様の権利を制限するものではない。

マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合がある。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をユーザに許諾するものではない。

別途記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、電子メールアドレス、ロゴ、人物、場所、イベントなどの名称は架空のものです。実在する商品名、団体名、個人名などとは一切関係がない。

Copy right 2003 Microsoft Corporation. All rights reserved.

Ｍｉｃｒｏｓｏｆｔ（登録商標）、ｂＣｅｎｔｒａｌ（商標）、Ｅｘｃｅｌ（商標）ロゴ、Ｏｕｔｌｏｏｋ（登録商標）、Ｇｒｅａｔ Ｐｌａｉｎｓ（登録商標）、ＢｉｚＴａｌｋ（登録商標）、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（商標）ロゴ、Ｗｉｎｄｏｗｓ（登録商標）、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（登録商標）は、米国マイクロソフトコーポレーション、Ｇｒｅａｔ Ｐｌａｉｎｓ Ｓｏｆｔｗａｒｅ Ｉｎｃ．、Ｍｉｃｒｏｓｏｆｔ Ｂｕｓｉｎｅｓｓ Ｓｏｌｕｔｉｏｎｓ ＡｐＳまたはその支社の、米国およびその他の国における登録商標または商標である。

Ｇｒｅａｔ Ｐｌａｉｎｓ Ｓｏｆｔｗａｒｅ Ｉｎｃ．およびＭｉｃｒｏｓｏｆｔ Ｂｕｓｉｎｅｓｓ Ｓｏｌｕｔｉｏｎｓ ＡｐＳは、米国マイクロソフトコーポレーションの子会社である。

記載されている会社名、製品名には、各社の商標のものもある。

はじめに
このホワイトペーパーでは、Ｍｉｃｒｏｓｏｆｔ Ｂｕｓｉｎｅｓｓ Ｓｏｌｕｔｉｏｎｓの新製品Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｂｕｓｉｎｅｓｓ Ｎｅｔｗｏｒｋ（ＭＢＮ（商標））Ｖｅｒｓｉｏｎ １．０について説明する。この新製品によって、顧客、ベンダなどのビジネスパートナーとの接続が自動化される。

ＭＢＮ（商標）に関するマイクロソフトの目的は、簡単かつ費用効果の高い方法で中小規模の企業とその取引先との通信を自動化できるようにすることである。他の企業とのやり取りや情報交換では、企業情報がデジタルデータから用紙上のアナログデータに変換されることが多くある（アナログデータはあまり有用とはいえない）。つまり、発注書をファックスで送信したり、会計報告書を印刷して郵送したり、顧客に関する報告書を印刷したり、支払を紙の小切手で済ませたりする。ＭＢＮ（商標）では、デジタルプロセスがそのまま保持され、取引先まで拡張される。

企業では現在、サプライチェーンに関して次のような問題に直面している。
・受注や関連文書の送信に、複数の方法（電子データ交換（ＥＤＩ）、ＸＭＬ、ファックスなど）が必要である。
・サプライチェーンの統合度と表示範囲の不足。サプライヤからの発注には手動の手順が含まれることがある（すなわち、発注書のファックス送信、請求書の入力など）。
・ＥＲＰ（Enterprise Resource Planning）アプリケーションとの統合度の低さ。このため、手動でデータを再入力する必要があるため、入力ミスにつながることがある。
・フォーマット間のマッピングプロセスが困難で時間がかかり、さらに特定の問題に関する更新も必要である。

ＭＢＮ（商標）では、サプライヤおよび顧客のネットワークと接続し、ビジネスアプリケーションを統合し、取引先との共同作業の費用を抑えることを可能にするソフトウェアと関連するＷｅｂサービスを提供して、これらの問題を解決する。

ＭＢＮ（商標）は最初のバージョンであるが、メキシコとアルゼンチンで使用されているＭｉｃｒｏｓｏｆｔ（登録商標） ｂＣｅｎｔｒａｌ（商標）の小規模ビジネスサービスで実行される企業間（Ｂ２Ｂ）サブスクリプションサービスをベースに構築されている。このサービスでは、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ（登録商標）メッセージ機能と共同作業のクライアントベースの「ビジネス用受信トレイ」が提供される。そのため、小規模なサプライヤは付加価値通信網（ＶＡＮ）を介したＥＤＩを使用したりインターネット経由でＸＭＬを直接使用して、大規模な小売業者に簡単に接続できる。ｂＣｅｎｔｒａｌ（商標）サービスはメキシコで２年前から使用されており、現在、メキシコの最大規模の小売業者２５社（すなわち、ハブ）とオンラインで接続され、さらに、４，０００社の小規模な取引先とも接続している。

ＭＢＮ（商標）の概要
Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｂｕｓｉｎｅｓｓ Ｎｅｔｗｏｒｋ（商標）は、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｏｆｆｉｃｅ（商標） Ｓｙｓｔｅｍ ２００３およびオプションでＭｉｃｒｏｓｏｆｔ Ｂｕｓｉｎｅｓｓ Ｓｏｌｕｔｉｏｎｓ（ＭＢＳ）アプリケーション（ＭＢＮ（商標） １．０のＧｒｅａｔ Ｐｌａｉｎｓ（登録商標）版製品以降）またはＭｉｃｒｏｓｏｆｔ（登録商標） ＢｉｚＴａｌｋ（登録商標）Ｓｅｒｖｅｒと統合するＭｉｃｒｏｓｏｆｔ（登録商標） ．ＮＥＴ（商標）接続ソリューションである。このオンサイトソフトウェアは、ホストされる一連のＷｅｂサービスと動作して、取引先への接続やビジネス文書の交換を行う。

ＭＢＮ（商標）の主要な目的は、顧客、ベンダなどのビジネスパートナーとの共同作業の方法を合理化する企業間の共同ソリューションを提供することである。このため、マイクロソフトではいくつかの主要なソフトウェアコンポーネント、ツール、コミュニティ構築サービスを構築して、企業が取引先のネットワークを拡張および統合できるようにした。

図７は、ＭＢＮ（商標）の概要を示す図である。
ＭＢＮ（商標）は次の要素で構成される。
・信頼できるＷｅｂサービスネットワーク。取引先との間で、信頼性のある、セキュリティが強化された、企業文書の機密送信を行うことができる。このネットワークを基盤として、すべての共同ソリューションが展開される。
・企業間のプロセステンプレートのライブラリ。プロセステンプレートはＭＢＳアプリケーションとＯｆｆｉｃｅ（商標）に統合される。プロセステンプレートは業界固有のもので、必要なデータ形式とプロセスをサポートする。
・あらゆる規模の取引先に対する接続オプション。ＭＢＮ（商標）の真価は、企業の取引先との接続にある。通常、企業にはあらゆる規模の取引先があるので、ＭＢＮ（商標）には各種の取引先に対する接続オプションが用意されている。
− Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｂｕｓｉｎｅｓｓ Ｎｅｔｗｏｒｋで小規模な取引先を有効にするには、ＭＢＮ（商標） Ｓｔａｎｄａｒｄ ＳＫＵ（stock-keeping unit）でＭｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ（登録商標）とＥｘｃｅｌ（商標）を使用する。将来的には、ＭＢＮ（商標）はブラウザでＷｅｂベースの文書追跡ツールを使用して、小規模な取引先にアクセスする予定である。
− 中規模の取引先も、ＭＢＮ（商標）での共同作業にＭｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ（登録商標）とＥｘｃｅｌ（商標）を使用する。ＭＢＮ（商標）では、ＭＢＳアプリケーションを実行する企業にバックオフィスの統合を行う。ＢｉｚＴａｌｋ（登録商標） Ｓｅｒｖｅｒを使用すると、ＭＢＳ以外のバックオフィスアプリケーションに統合できる。
− ＭＢＮ（商標）で大規模な取引先を有効にするには、Ｍｉｃｒｏｓｏｆｔ（登録商標） ＢｉｚＴａｌｋ（登録商標） Ｓｅｒｖｅｒを使用する。
・取引先ネットワークの準備ツールとサポート（コミュニティの構築）。ＭＢＮ（商標）では、一連のホストされたサービスを提供し、企業の取引先のネットワークを拡張できるようにする。ＭＢＮ（商標）のパートナー管理ツールを使用すると、企業は取引先を招待し、準備作業を行い、取引先を管理することができる。マイクロソフトおよびそのパートナー企業は、必要に応じて企業の取引コミュニティの拡張をサポートする。これらのツールおよびサービスは、支援付きピアツーピア通信の「支援」部分にあたる。

企業間のプロセステンプレート
ＭＢＮ（商標）の意義は、取引先に共同サプライチェーン管理（ＳＣＭ）ソリューションを展開することにある。共同ソリューションはＭＢＮ（商標）プロセステンプレートから作成される。企業は共同ソリューションを使用して、取引先に接続および統合し、サプライチェーンプロセスの効率性を高め表示範囲を増やす。これにより、非統合の手動プロセスによるミスが軽減される。

技術的には、ＭＢＮ（商標）プロセステンプレートは次の要素で構成される。
・業界固有の一連のビジネス文書定義（価格表、発注、承認、出荷通知、請求書など）。
・１つまたは複数のコラボレーション定義。これらの文書の相関関係、表示方法、作成方法が記述される。
・アプリケーション統合プロファイル。プロセステンプレートとＭｉｃｒｏｓｏｆｔ（登録商標） Ｏｆｆｉｃｅ（商標）およびＭＢＳアプリケーションとの統合方法が記述される。

展開された各プロセステンプレートには、「パブリッシャ」と１つまたは複数の「サブスクライバ」がある。
・プロセステンプレートパブリッシャ。プロセステンプレートパブリッシャは、取引先でプロセステンプレートを使用可能にし、アクセスする取引先を制御する企業である。パブリッシャは、既存のＭＢＮ（商標）プロセステンプレートをカスタマイズすることも、プロセステンプレートをそのまま使用することもできる。パブリッシャは、「チャネルマスタ」または「ハブ」と見なすこともできる。
・プロセステンプレートサブスクライバ。プロセステンプレートサブスクライバは、プロセステンプレートをパブリッシュした企業との共同関係に参加する予定の取引先である。プロセステンプレートサブスクライバの例としては、Ｏｒｄｅｒｓ−ｔｏ−Ｃａｓｈプロセステンプレート内のサプライヤがある。このサプライヤは、大規模な小売業者または販売業者から購入する。

Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｏｆｆｉｃｅ（商標） Ｓｙｓｔｅｍ ２００３で、ＭＢＮ（商標） Ｓｔａｎｄａｒｄ ＳＫＵと共にＭｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ（登録商標）とＥｘｃｅｌ（商標）を使用すると、追加設定なしでＭＢＮ（商標）プロセステンプレートが動作するように構成されている。

Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ（登録商標）の統合
取引先に対して送受信するビジネス文書はすべてＭｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ（登録商標）に表示される。企業がＭｉｃｒｏｓｏｆｔ（登録商標） Ｂｕｓｉｎｅｓｓ Ｓｏｌｕｔｉｏｎｓユーザの場合、文書はバックオフィスでも直接統合されるが、Ｏｕｔｌｏｏｋ（登録商標）内でも常に文書が表示される。ＭＢＮ（商標）文書は電子メールに似ているが、実際は、ＨＴＭＬプレビューとＸＭＬビジネス文書への添付ファイルリンクが統合ビジネスメールボックスに表示された、構造化されたビジネス文書である。

Ｏｕｔｌｏｏｋ（登録商標）は、ビジネス文書をフォルダに編成できる企業ユーザ向けの一般的なユーザインタフェースを提供する。また、特定の基本文書（発注など）に関するビジネス文書をグループ化したり関連付けたりできる便利なテーマビュー（ｃｏｎｖｅｒｓａｔｉｏｎ ｖｉｅｗ）もある。例については、図８のスクリーンショットを参照。

Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｅｘｃｅｌ（商標）とＭＢＮ（商標） Ｅｘｃｅｌ（商標）アドイン
ＭＢＮ（商標）では、ＭＢＮ（商標）プロセステンプレートで動作するＥｘｃｅｌ（商標）アドインを提供することで、ＭＢＮ（商標）ソリューションのクライアントとしてＭｉｃｒｏｓｏｆｔ（登録商標） Ｅｘｃｅｌ（商標）を利用する。ＭＢＮ（商標） Ｅｘｃｅｌ（商標）アドインを使用すると、ビジネスエンティティ（発注、請求書、出荷通知など）の表示や作成、文書履歴の表示を行うことができる。文書履歴は、企業間プロセスの一部であるビジネス文書（発注書などの関連文書）の相関関係を表したものである。

企業でＭＢＳアプリケーションを実行している場合、Ｅｘｃｅｌ（商標）のビジネスエンティティには適宜バックオフィスからデータが入力される。

図９は、ＭＢＮ（商標）Ｅｘｃｅｌ（商標）アドインのスクリーンショットの一例を示す図である。

追加設定なしで使用できるプロセステンプレート
Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｂｕｓｉｎｅｓｓ Ｓｏｌｕｔｉｏｎｓでは、ＭＢＮ（商標） １．０の一部として、追加設定なしで使用できるグローバルな２つのプロセステンプレートを用意している。
・Ｏｒｄｅｒｓ−ｔｏ−Ｃａｓｈ（小売業者のサプライチェーン用）
・Ｓｕｐｐｌｉｅｒ Ｖｉｓｉｂｉｌｉｔｙ（製造業用）
マイクロソフトのパートナー企業では、ＭＢＮ（商標）ソフトウェア開発キット（ＳＤＫ）を使用してこれらのプロセステンプレートをカスタマイズできる。

Ｏｒｄｅｒｓ−ｔｏ−Ｃａｓｈ（小売業者のサプライチェーン用）
Ｏｒｄｅｒｓ−ｔｏ−Ｃａｓｈプロセステンプレートでは、小売業者のサプライチェーン内の取引先間での受注から現金回収までのプロセスに、構造化されたビジネス文書を提供する。このプロセステンプレートには、価格表、発注、発注の承認、出荷通知、請求書などの文書が含まれている。

Ｓｕｐｐｌｉｅｒ Ｖｉｓｉｂｉｌｉｔｙ（製造業用）
Ｓｕｐｐｌｉｅｒ Ｖｉｓｉｂｉｌｉｔｙプロセステンプレートを使用すると、製造業者はサプライヤからの各注文品目の製造ステータスを表示できる。このためには、製造業者が仕掛品（ＷＩＰ）ステータス要求をサプライヤに送信する。サプライヤは各品目のマイルストーンでステータスを入力し、ＷＩＰ応答を使用して応答する。サプライヤは、Ｅｘｃｅｌ（商標）またはバックオフィスアプリケーション（ＢｉｚＴａｌｋ（登録商標） ＳｅｒｖｅｒまたはＥｘｃｅｌ（商標）のインポート／エクスポート操作を使用）を使用して、マイルストーンステータスを手動で入力できる。

信頼できるＷｅｂサービスネットワーク
ＭＢＮ（商標）プロセステンプレートは、Ｗｅｂサービス経由で企業間にビジネス文書を確実に配信する、信頼できるＷｅｂサービスネットワーク上に展開される。以降では、ＭＢＮ（商標） Ｗｅｂサービスネットワークの構成要素について説明する。

統合ビジネスメールボックス
ＭＢＮ（商標） Ｗｅｂサービスネットワークの主要概念は統合ビジネスメールボックスである。取引先に対して送受信するビジネス文書はすべて、統合ビジネスメールボックスを通過する。ＭＢＮ（商標）では、企業の場所（すなわち、屋内）に展開されたＭＢＮ（商標）サーバで統合ビジネスメールボックスを維持する。

ビジネスメールボックスの主なメリットは、取引先のネットワークへの接続方法や文書の送信形式にこだわらない点である。すべての文書は、ＸＭＬ形式で企業の統合メールボックスに確実に配信される。ＸＭＬ形式を使用すると、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｏｆｆｉｃｅ（商標）やＭＢＳアプリケーションに統合できる。

ＭＢＮ（商標）の格納と転送サービス
ＭＢＮ（商標）では、企業間のプロキシＷｅｂサービス呼び出しに対して、ホストされた格納と転送サービスを提供する。ＭＢＮ（商標）では非同期Ｗｅｂサービス呼び出しを使用して、企業間でビジネス文書を送信する。

このサービスを使用するのは、すべての企業でＷｅｂサービスを直接公開するわけではないからである。例えば、小規模な企業には専用のブロードバンドインターネット接続がなかったり、ファイアウォールの外側にＷｅｂサービス呼び出しを公開したくない企業もある。これらのニーズを満たすために、ＭＢＮ（商標）ではホストされた格納と転送サービスを提供して、ビジネス文書をキューに入れ、企業が各自の文書を「ポーリング」できるようにする。この方法では展開と維持が最も簡単にできるため、取引先にＭＢＮ（商標）を展開する場合の既定の方法になる。

ＭＢＮ（商標）接続
ＭＢＮ（商標）では、取引先への複数の接続オプションが用意されている。
・Ｗｅｂサービス。ＭＢＮ（商標）は、インターネット経由で非同期Ｗｅｂサービス呼び出しを使用したビジネス文書の送信を既定でサポートする。
・ＶＡＮ接続（１．０の後、マイクロソフトのパートナー企業を通じて）。ＭＢＮ（商標） Ｗｅｂサービスに統合するマイクロソフトのパートナー企業のソフトウェアを使用すると、ＭＢＮ（商標）の取引先はＶＡＮ上のＥＤＩ取引先に接続できる。
・ＡＳ２（Applicability Statement 2）のサポート（１．０の後、マイクロソフトのパートナー企業を通じて）。ＡＳ２は、インターネット経由でＨＴＴＰ（HyperText Transport Protocol）を使用してＥＤＩ文書を安全に送信できる、最新の標準である。Ｍｉｃｒｏｓｏｆｔ（登録商標） ＢｉｚＴａｌｋ（登録商標） ＳｅｒｖｅｒのＥＤＩアクセラレータを使用すると、ＭＢＮ（商標）の取引先はＥＤＩ／ＡＳ２取引先に接続できる。
・ＷｅｂベースのＤｏｃｕｍｅｎｔ Ｔｒａｎｓｆｅｒ Ｃｅｎｔｅｒ（１．０の後）。ＭＢＮ（商標） のＷｅｂベースのＤｏｃｕｍｅｎｔ Ｔｒａｎｓｆｅｒ Ｃｅｎｔｅｒ（ＤＴＣ）を使用すると、小規模な取引先はＷｅｂブラウザだけでビジネス文書を送受信できる。ＭＢＮ（商標） ＤＴＣのエンドユーザは小規模な企業であるが、この機能の本来の目的は、すべての取引先とＭＢＮ（商標）ユーザを接続することである。最小規模の取引先でも、出資しているハブとビジネス文書を交換できるようにするために、ＤＴＣのハードウェアとソフトウェアの要件は最小限のものになっている。ＤＴＣは、ＦＴＰ（file transfer protocol）と同様にＵＩ（user interface）の使用方法が簡単である。

セキュリティ、信頼性、プライバシー、ビジネスの整合性
マイクロソフトのＴｒｕｓｔｗｏｒｔｈｙ Ｃｏｍｐｕｔｉｎｇ（信頼できるコンピューティング）への取り組みは、セキュリティ、信頼性、プライバシー、ビジネスの整合性の観点から定義される。マイクロソフトでは、ＭＢＮ（商標）製品とサービスを信頼できるものにするために努力を積み重ねてきた。セキュリティ、信頼性、プライバシーを確保するために、ＭＢＮ（商標）は基礎から設計されている。

ＭＢＮ（商標）のセキュリティ
企業はＭｉｃｒｏｓｏｆｔ（登録商標） Ｐａｓｓｐｏｒｔ（商標）を使用して、ＭＢＮ（商標） Ｗｅｂサービスと取引先のディレクトリで認証される。ＭＢＮ（商標）でホストされるサーバは、Ｗｉｎｄｏｗｓ（登録商標）Ｓｅｒｖｅｒ ２００３を実行する。また、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（登録商標）ディレクトリサービスによるセキュリティ機能を備え、強化されたセキュリティを実現するように強制されている。

Ｗｅｂサービス呼び出しを行う際、クライアント側のデジタル証明書を使用して取引先を認証する。すべてのビジネス文書はＳＳＬ（Secure Sockets Layer）で暗号化され、送信される。

ＭＢＮ（商標）の信頼性
企業間での信頼性のあるメッセージ
ＭＢＮ（商標）では、ＨＴＴＰＳ（hypertext transfer protocol, secure）を使用して信頼性のある非同期のビジネスメッセージを提供する。ＭＢＮ（商標）では、文書は一度だけ配信され、問題がある場合は、配信不能の確認メッセージ（ｒｅｃｅｉｐｔ）が送信される。この信頼性の一環として、ＭＢＮ（商標）には３段階の確認メッセージ／配信不能の確認メッセージがある。
・配信確認メッセージ。ビジネス文書が取引先に配信されたときにＭＢＮ（商標）が確認メッセージを送信するように選択できる。
・機能上の受信確認（Ｆｕｎｃｔｉｏｎａｌ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）。ビジネス文書が配信され、形式が取引先で確認されると、機能上の受信確認が生成される。機能上の受信確認は、ＭＢＮ（商標） ＸＭＬの文書の種類として既定でサポートされている。
・ビジネスレベルの受信確認。プロセステンプレートでは、ビジネスプロセスの観点からビジネス文書が受け入れられたことを示す、ビジネスレベルの受信確認を設定できる。ビジネスレベルの受信確認の例として、発注の承認がある。

ＭＢＮ（商標） Ｗｅｂサービスの利用可能性／信頼性
ＭＢＮ（商標） Ｗｅｂサービスは、クラスタテクノロジやデータアーカイブ機能を使用して、世界規模の運用チームで活用できるように構成されている。

ＭＢＮ（商標）でホストされるサービス
ＭＢＮ（商標）では、次の一連のホストされたサービスを提供して、支援付きのピアツーピアネットワーク設計を可能にする。支援付きのピアツーピアネットワークとは、マイクロソフトが一連のサービスを提供して、企業の取引先ネットワークの拡張、構成、維持をサポートすることによって、取引先間のピアツーピア通信を支援することである。

プロセステンプレートダウンロードセンター
ＭＢＮ（商標）プロセステンプレートダウンロードセンターには、企業がダウンロードして使用できるプロセステンプレートが表示される。ダウンロードセンターの各プロセステンプレートは、次の要件を満たす。
− プロセステンプレートはマイクロソフトによって検証されており、マイクロソフトによって直接サポートされる。
− プロセステンプレートは文書化されている。エンドユーザとカスタマイズの文書化が可能。
− プロセステンプレートは追加設定なしでＭｉｃｒｏｓｏｆｔ（登録商標） Ｂｕｓｉｎｅｓｓ ＳｏｌｕｔｉｏｎｓアプリケーションとＭｉｃｒｏｓｏｆｔ（登録商標） Ｏｆｆｉｃｅ（商標）に統合される。
− パブリッシャがプロセステンプレートをカスタマイズする場合にサブスクライバのアプリケーション統合に影響を与えないように、プロセステンプレートは開発されている。

企業のオンサイトＭＢＮ（商標） Ｐｒｏｆｅｓｓｉｏｎａｌサーバにプロセステンプレートをダウンロードおよびインストールして、カスタマイズしたり、そのまま使用したりできる。プロセステンプレートをテストして有効にしたら、企業は共同作業に取引先を招待できる。

ＭＢＮ（商標）の支援付きのピアツーピアネットワーク設計の主なメリットは、企業が取引先に対して簡単にプロセステンプレートのパブリッシュ、展開、更新を行えることである。ＭＢＮ（商標）はプロセステンプレートのバージョン管理をサポートする。プロセステンプレートパブリッシャは、必要に応じて、プロセステンプレートの複数のバージョンを使用して実行される。

パートナー管理ツール
ホストされるパートナー管理ツールを使用すると、企業は取引先コミュニティを拡張したり管理したりできる。ＭＢＮ（商標） Ｐｒｏｆｅｓｓｉｏｎａｌを実行している企業はこのツールを使用して、取引先一覧のアップロード、取引先への招待の送信、プロセステンプレートへのアクセス制御を行う。

＜ ｐａｒｔ３ ＞
「エンパワードオートメーション（Empowered Automation）」

ビジネスプロセス管理アプリケーションの領域における
ソフトウェアによる人々の能力増強のための設計原則

ＢｉｌｌＧ「Ｔｈｉｎｋ Ｗｅｅｋ」向け論文
２００３年５月執筆

執筆者：Ｊｅｆｆ Ｓｔａｉｍａｎ
協力者：Ｊｅａｎ Ｓｃｈｅｎｃｋ、Ｔｒａｃｅｙ Ｔｒｅｗｉｎ

プロジェクトＨａｌｉｆａｘ（商標）
Office of the CTO/Platform Technology & Strategy

主要概念
人々は、意思決定、スキル、および人間的接触によって多数のビジネスプロセスに価値を付加している。これらのプロセスを抜きにして人々が行う仕事をソフトウェアでオートメーション化することはできない。その傾向は、会社とそのビジネスパートナーとの間のプロセスの場合は特に強くなる。

現在のビジネスソフトウェアでは、これらのプロセスの仕事を行う人々に対するサポートが大きく欠けている。実社会におけるエンドツーエンドビジネスプロセスは、現在のソフトウェアソリューションの前提である構造化データの順次的な交換より多岐にわたる。現在のアプリケーションでは多数の重要な活動がまったくサポートされていないか、サポートされていたとしてもそのサポートは不十分である。そのため、人々はアプリケーションの外部で仕事を行ってこれらのタスクを遂行している。

ソフトウェアは、これらのタスクでの人々の支援が可能であり、また支援するべきである。情報ワーカーは、エンドツーエンドビジネスプロセスの管理を支援する新しい種類のアプリケーションを必要としているのである。

これらのビジネスプロセス管理アプリケーションは、以下のような設計上のヒントを、高性能ＳＬＲ（single-lens reflex）カメラを使用する写真家や、オートパイロットを使用する操縦士のユーザ体験から得るべきである。
・管理は、人々（情報ワーカー）が行う。
・意思決定に役立つ情報を人々に提供する。
・人々がやりたがらない繰り返し行うタスクのオートメーション化を支援する。
この設計原則を
「エンパワードオートメーション」
と呼ぶ。
・適用範囲：オートメーション化できない、人間が価値を付加するビジネスプロセス
・対象ユーザ：これらのプロセスの仕事を行う情報ワーカー

０．背景と範囲
この論文は、Ｈａｌｉｆａｘ（商標）プロジェクトのために我々のチームによって行われた研究に基づいている。このチームの本来の目的は、マイクロソフトのために中小企業（ＳＭＯＲＧ）向けのＢ２Ｂに対応する新製品の可能性を特定することであった。

Ｈａｌｉｆａｘ（商標） ｖ１は、ＳＭＯＲＧを対象とした分散受注管理アプリケーションである。我々の観察およびマイクロソフト内部および外部の人々との討論から、Ｈａｌｉｆａｘ（商標）およびエンパワードオートメーションの設計原則は、受注以外のその他の多数のビジネスプロセスに広く適用できることが明らかになった。

Ｈａｌｉｆａｘ（商標）およびエンパワードオートメーションの原則につながる研究成果の主な源は、中小企業への我々のチームの現場訪問であった。その現場で、我々は、あらゆる規模のビジネスパートナーとのプロセスに関与しながら日常業務を遂行する情報ワーカーを観察した。我々は、ＬＯＲＧ（大企業）、産業アナリスト、ＭＢＳ ＶＡＲおよび彼らの顧客、マイクロソフトの他のチームとの討論の中でその研究成果を確証した。

範囲
この論文の目的は、ビジネスプロセス管理（「ＢＰＭ」）アプリケーション、特に会社間で行われるプロセスに対する「エンパワードオートメーション」の原則、つまり設計パターンを示すことである。

エンパワードオートメーションは、Ｈａｌｉｆａｘ（商標）の設計の基礎となる主要な原則であるが、この論文では、Ｈａｌｉｆａｘ（商標）自体や、エンパワードオートメーションの原則の「パッケージ」方法、その他の特定の製品に対する適用方法については直接触れない。

Ｔｈｉｎｋ Ｗｅｅｋの論文「Ｉｎｔｅｒａｃｔｉｖｅ Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓｅｓ」（執筆：Ｂｉｌｌ ＤｅｖｌｉｎおよびＴｒａｃｅｙ Ｔｒｅｗｉｎ）には、エンパワードオートメーションがＨａｌｉｆａｘ（商標） ｖ１の設計にどのように反映されているかが記載されている。

１．ビジネスプロセスにおける人間の関与
企業間の重要な対話の大部分、および企業内で行われるサポート活動の多くは、ビジネスプロセスのコンテキスト（製品およびサービスの購買および販売、共同設計および開発、プランニングと予測、保険金請求処理、取り付け作業員のスケジュールなど）の中で行われている。これらのプロセスは、多くの場合、構造化データを含むメッセージの順次交換としてモデル化されている（例えば、発注書とそれに続く発注確認）。そして、構造化データの交換は実際にこれらのプロセスの多くで重要な部分となっている。

しかし、実社会におけるこれらのプロセス事例には、そのモデルで捕捉されていない重要な要素がある。明確に言えば、それは特定のビジネスコンテキストにおいてこれらのプロセスを首尾よく行うために人間が実行する実際のタスクに関する要素である。エンドツーエンドビジネスプロセスは、構造化データの交換よりもはるかに複雑なのである。

エンパワードオートメーションの概念の基礎となる基本的な研究成果は、「実社会におけるエンドツーエンドビジネスプロセスの多数の事例において、情報ワーカーは、ソフトウェアで置き換えることができない方法によって、重要な価値を付加している」ということである。次に例を示す。

図１０は、エンパワードオートメーションと写真の例を示す図である。この図は、Ｃａｎｏｎ ＥＯＳ−１Ｄｓ（商標）である。これは、現在の世界最先端のカメラの１つである。このカメラは写真家が望むとおりに写真を撮影できる高性能な制御を提供する。写真家は、撮影プロセスの中で彼の判断が重大な価値を付加すると考える要素にのみ注意を払うことができる。残りの部分はカメラによって行われる。オートメーションにおける進歩によって、撮影プロセスにおけるアクティブな人間の関与と判断の必要性がなくなることはないだろう。人間が多数のビジネスプロセスの付加価値の不可欠な部分であることを、ビジネスプロセス管理アプリケーションは受け入れなければならない。

・判断：コンテキストに沿った意思決定。情報ワーカーは、ビジネス上の意思決定を適切に迅速に繰り返し行っている。彼らは、この意思決定を明示的および暗黙的なポリシーと優先順位を含む非常に動的で複雑な（多変量の）コンテキストの中で行っており、多くの場合、それらをソフトウェアとしてモデル化し、最新の状態に保持するのは、困難であるか、非経済的であるか、不可能である。例えば、在庫の少ない商品を複数の顧客に分配しなければならず、それらの顧客の一人が、前の注文の対応が遅かったことに憤慨している状況を考えてみよう。オートメーション化されたアプリケーションによって、受注商品の割当にその苦情の電子メールを反映させる方法を適切にモデル化できる可能性はほとんどない。しかし、通常人々が（多くの場合）その高いスキルで行っていることは、このような種類のものなのである。

人々は、アプリケーションでモデル化できる可能性が低い、コンテキストに応じたデータを使用するだけでなく、ビジネスプロセスの形式的な分析では通常モデル化できない方法で、そのコンテキストに応じた知識を使用して１つ１つのプロセスを進めてゆくのである。実社会での需要とリソースの変化に基づいて、人々はプロセスの進行、手順の省略（受注確認の受け取りがないことに注意を払わない）、手順の繰り返し（重要な注文に関する状況の問い合わせを再送信する）、手順の修正（特定の決定を委任したり、上長の判断を求めたりする）、手順の順序の変更（正式な発注書を受け取る前に請求書を送る）、プロセスへの手順の追加（顧客からの特定の設計変更要求を確認する前に、製造部門から正式に買い取る）を行っている。

・人間固有のスキル。情報ワーカーは、スキルに基づいてタスクを実行し、それは本質的にモデル化が不可能であるか困難である。これらのタスクのいくつかは、プロセスの例外的な部分である。例えば、これには特定のビジネス上の問題に対する代替ソリューションを評価するための他の者との共同作業などがある。その他のタスクは、モデル化されたプロセスの不可欠な部分で、設計スキルやセンス、市場の理解、工学原理、顧客シナリオなどを必要とするタスクである。

・人間的接触。情報ワーカーは、他の人々との人間的接触によってプロセスに価値を付加する。それは、ソフトウェアによって決して複製できない高い付加価値を生み出す方法（説得、取引契約の生成（または提示）、関係の構築、うその感知など）で行われる。例えば、小売業者がサプライヤに季節商品を大量発注したシナリオを考えてみよう。バイヤーに電話して人間関係を活用し、その発注と釣り合うリソースを使用してその商品を売り込むという小売業者の取引契約を評価したり、販売条件を修正し、商品を返品して払い戻しを受ける小売業者の権利を制限し、サプライヤが最終的に売れ残って販売できない季節商品の大量の在庫を抱えることがないようにすることができる情報ワーカーは、多くの価値を生み出す。

当然のことながら、すべてのビジネスがこれらのパターンに合致するわけではない。人間によって意味のある価値が付加されないプロセスもある。例えば、高度にオートメーション化された金融取引などである。人間によって固有の価値が付加されないこれらのプロセスを対象にしたアプリケーションの場合、エンパワードアプリケーションが特に意味を持つ概念とならない可能性が高い。しかし、完全にオートメーション化可能なプロセスの多くは、完全にオートメーション化できない、より大規模なプロセスの一部でもある。

２．プロセス管理に対する現在のアプローチ
正しい理解では、多数の一般的なエンドツーエンドビジネスプロセスは、構造化ビジネスデータの処理および交換よりも広範囲に及ぶ。この構造化データの交換は、構造化されていない重要なコミュニケーションの交換とともに行われる。人々は、共同作業、データの評価、意思決定などを行う。現在のビジネスアプリケーションとＢ２Ｂソリューションは、ビジネスプロセスの主要な特定の部分で人々をサポートしていない。例えば、ＥＲＰ、ＣＲＭ、およびＳＣＭなどの一般的なビジネスアプリケーションには、次の特徴がある。
・外部パートナーとのコミュニケーションのための機能がないか、制限された機能しかない。
・プロセスの中の、アプリケーションがサポートする機能エリア外のプロセス部分の管理に対するサポートが提供されていない。
・例外的なプロセス事例に対応する必要がある場合に、アプリケーションでタスクを完了するためにわずらわしい代替策を必要とする。

図１１は、情報ワーカーを示す図である。
人々が遂行しなければならない多数のタスクに対する、ＬＯＢ（基幹業務）アプリケーションでのサポートの欠如を調べる簡単な方法は、実際にそれらを使用している多数の人々がＬＯＢアプリケーション外部での作業に長時間を費やしていることに注目することである。彼らは、様々な手動プロセスをつなぎ合わせて作業している。スプレッドシート、最先端のアプリケーションなどの追加のシステムやノートブック、ファイルフォルダなどの物理的な道具を使用しているのである。

これらのプロセスは、前のコミュニケーションの検索やフォローアップのためのタスクリストへの項目の追加などで手作業ではあるがその大半は繰り返し作業でソフトウェアによってサポートすることが可能である。この作業の大部分はソフトウェアによって完全にオートメーション化することはできないが、構造化文書の処理を支援するＬＯＢアプリケーションに統合されているアプリケーション機能でこれらのタスクをサポートすることによって、これらの作業のより効率的で正確な遂行を支援できる可能性が高い。

ＥＤＩおよびＸＭＬベースのソリューションは、ビジネスプロセスの中の同一の小さな断片に対応してきた。これらのソリューションによって、１つの会社から、別の会社にあるコンピュータで読み取り可能なメッセージを正しい形式で送信したり、同様の形式でパートナーからメッセージを受信することができる。これらのソリューションが（多くの場合はＬＯＲＧで）実装された場合、それによって、発注書などのビジネス文書の印刷、ビジネスパートナーへのビジネス文書の送信、（ビジネスパートナーでの）その会社のビジネスアプリケーションへのデータの再入力などの手作業が除去されてきた。

しかし、Ｂ２Ｂソリューションが展開された事例でも、エンドツーエンドプロセスの管理には多数の問題が残っている。２００３年５月の大規模小売業者４社に対する非難は、それらの小売業者はＥＤＩを介してサプライヤからビジネス文書の大部分またはすべてを受信しているが、データレベルの正確性には依然として大きな問題が残っており、同期の処理を行わなければならない場合が多いことを示している（例えば、小売業者が受信したメッセージが適切にマッピングされたデータを含む読み取り可能なものであっても、在庫がない品目に対するものであったり、誤った価格が使用されている場合などである）。小売業者は、ＥＤＩメッセージを誤った順序で受信する（製品の出荷前に請求書を受信する）など処理レベルの整合性の問題も報告している。メッセージ形式に重点を置き、処理の問題を軽視するＢ２Ｂソリューションは、人々がこれらの処理を行うための支援にほとんど、あるいはまったく役に立たない。大規模小売業者に納入しているサプライヤは、現在のシステムで十分にサポートされていない処理の整合性の問題および争議の対応に苦慮していることを報告している。

ＬＯＢアプリケーションと同様に、Ｂ２Ｂソリューションでは構造化データに焦点が当てられている。通常、それらには非構造化コミュニケーション、人対人の共同作業、動的または複雑なコンテキストでの人間の意思決定と問題解決プロセスに対するサポート、例外処理、およびエンドツーエンドプロセスの管理に対する概念が欠けている。設計における暗黙性（および、場合によってはＢ２Ｂソリューションのマーケティングにおける明示性）は、ソフトウェアを使用してビジネスプロセスから人々を排除するという考え方である。これは、複雑で付加価値の高いビジネスプロセスにおいて人間がその判断、スキル、および人間的接触によって果たしている中心的な役割を無視している。

これらの設計では、ビジネスプロセスにおける人間の関与は、十分にサポートされていない不適切なケースとしてモデル化されていることがある。多くの場合、それらは例外として処理される。例えば、何かを承認または拒否するためのＵＩコントロールがユーザに提供されているが、意思決定に必要なコンテキスト情報への系統的なアクセスが限られているかまったくない場合などある。さらに悪い場合は、人間の関与が完全に無視されている。アプリケーションによるビジネスプロセスのコンテキストの解釈によって予想外の結果を招く管理されていない活動を考えてみよう。

完全にオートメーション化できないタスクは、それらのシステムではサポートされていないか、不十分なサポートしかなされていない。したがって、人々は、価値を付加するために、これらのシステムの外部で物理的な道具や特別なシステムを使用して手作業でプロセスを実行し続けているのである。そのようなシステムの問題の詳細な説明は、それ自体のホワイトペーパーに記載されているが、我々と話をしたほとんどすべての会社がこの問題に言及していたことからも明らかなように、これによって、従業員が病欠したり、休暇を取ったり、離職したりする場合に失われ、再作成が必要になる個人的な情報およびコンテキストの孤立した固まりが作成されることは注目に値する。

ただし、特に統合された形式で提供される場合は、ソフトウェアは、情報ワーカーが彼らの判断、スキル、および人間的接触によって価値を付加することを可能にするとともに、共同作業、意思決定サポート、プロセスの整合性などのタスクにおいて人々を支援することが可能である。

３．エンパワードオートメーションとビジネスプロセス管理
エンパワードオートメーションは、ビジネスプロセス管理（「ＢＰＭ」）アプリケーションの新しい種類について開発者に伝えるための設計原則である。エンパワードオートメーションは、特定のテクノロジではない。それは、特定のビジネスプロセスを管理するアプリケーションの中心に人間を配置する世界観である。これらのＢＰＭアプリケーションの第一目標は、人々が現在行っている仕事をより正確により迅速に実行できるように力を与え、エンドツーエンドビジネスプロセスの各事例に真の価値を付加するための能力を高めることである。

エンパワードオートメーションは、プロセス内に存在する繰り返し手順をオートメーション化することに高い価値があるという（議論の余地がない）前提と完全に一致している。

これは、以下の点に注意することによってエンパワードオートメーションにより拡張される。
・エンドツーエンドビジネスプロセス事例のすべての部分をオートメーション化できるわけではない。
・人々がその判断、スキル、人間的接触によって固有の（「ソフトウェアによって置き換えることができない」）価値を付加するタスクを遂行する場合でも、ソフトウェアアプリケーションは、意思決定、共同作業およびコミュニケーション、ならびにデータ保存（例えば、決定事項の文書化）をサポートするための適切なデータの検索を支援する機能によって価値を付加することが可能であり、付加するべきである。
・オートメーション化された機能と人間がサポートする機能は可能な限り緊密に統合する必要がある。

ビジネスプロセス管理アプリケーションは、人々がプロセスを適切に進めるために使用する深い知識を尊重する必要がある。アプリケーションは、人々に対して、単にソフトウェアを使用して彼らの仕事を行うための、あるいは、その仕事の繰り返し部分をオートメーション化するためのプロセスモデル化の専門家になることを求めるべきではない。

３．１．タスクを効率的に完了するためのユーザの能力増強
エンパワードオートメーションの原則は、それぞれのタスクをオートメーション化することと、プロセスの中で人々が人間固有の価値を付加する部分において人々をサポートするために可能な限り多くの機能を提供することである。

オートメーションと人間中心の仕事との適切な統合を理解する最適な方法は、これらのプロセスのサポートにおいて人々が現在行っている活動を詳細に調べることである。これには、人々がビジネスプロセスに関する仕事をするときに、実行する５つの基本的な活動を考えてみると役に立つ。受注確認の受け取りなどビジネスプロセスの特定の手順内では、これらの活動は次のような順序で行われることが多い。
・人が、自身が担当するプロセスで状態が変化したことに気づく（例えば、顧客からファックスを受信する）。
・人が、その意思決定のために必要な意思決定サポートデータを収集する。
・状態の変化に応じて実行する必要がある事項について人が意思決定する。
・人が、１つまたは複数のアクションを行って、適切な状態にプロセスを進める。
・これらの活動のいくつかまたはすべてに、社内または外部の人々との共同作業が含まれていることがある。

これらを以下の図１２に示す。図１２は、ビジネスプロセス事例での手順における情報ワーカーの活動を示す図である。このうち、人間が完了するタスクは点線で囲んである。

以下の表４は、活動のサポートにおいて人々が実行する一般的なタスクの例である。人々が実際に実行する具体的なタスクを確認すると、これらのプロセスでの人々の関与をサポートするためにどのような種類のアプリケーション機能が必要なのかが明確になる。

これらの様々な活動には、様々な種類のアプリケーションサポートが必要で、オートメーションの可能性も異なることは明らかである。そのため、エンパワードオートメーションでは、何をオートメーション化しなければならないのか、また、人間が価値を付加するタスクに対してどのような種類のサポートを提供する必要があるのかを正確に把握する必要がある。

当然のことながら、その完全な答えは、常に、具体的なビジネスプロセスのニーズに応じて異なる。それぞれ正当な理由により、ある会社がオートメーション化を選択したタスクを、他の会社では人間が行うことを選択することがある。しかし、ある程度の概括はできる。以下の表５は、ビジネスプロセス内の一般的な手順のうち人々が実行する中核的な各活動の中で、アプリケーションが実行するものと人間が実行するものの一般的な分類の概要である（例えば、サプライヤからの発注確認の受け取り、顧客への事前出荷通知の送信など）。

エンパワードオートメーションを目標の設計原則とするアプリケーションは、豊富な機能を提供し、そのアプリケーションが対象としているエンドツーエンドビジネスプロセスの一部であるアクションの多くをユーザが遂行することができる。一般的にどのタスクをオートメーション化し、どのタスクをオートメーション化しないのかについては偏見を持たないようにしなければならない。これによって、そのプロセス内でオートメーション化するタスクの選択の幅が広がる。

３．２．日常業務のオートメーション化
ＢＰＭは、ユーザによるタスクの効率的な遂行を可能にするアプリケーションの表面的な機能だけでなく、他の機能も提供する必要がある。ユーザが多数のビジネスプロセスの一部である日常業務を選択してオートメーション化できるようにするとともに、そのプロセスのオートメーション化された部分を確認および制御できるようにする必要がある。

これは、基本的には、現在までのＢ２Ｂソフトウェアを特徴付けるモデルとは異なるオートメーション化モデルである。エンパワードオートメーションは、人間の関与が、プロセス内の多くの重要な手順の中心となることを前提しているが、人間が関与する部分がすべてのプロセス事例において同じ手順である必要はない。例えば、顧客からの発注の管理の中でオートメーション化される活動は、顧客や発注に含まれる商品の種類によって異なることもある。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

オートパイロット：ＢＰＭアプリケーション内でのエンパワードオートメーションのユーザ体験の比喩（オートパイロットの比喩は、２つのシステムの適切なユーザ体験の類似性を示すことのみを目的としている。また適切に実装されたＢＰＭオートメーションとオートパイロットとの間にはいくつかの大きな相違があるのは明らかである。そのうちの最も重要なものは、ＢＰＭアプリケーションでは継続的なビジネスルールの追加および修正の必要性が非常に高いことである。）
理想的にはビジネスプロセスに関与する人間がＢＰＭアプリケーションと対話する方法は、操縦士がオートパイロットと対話する方法と非常に類似したものとなる。この説明では、実際の操縦士によるオートパイロットの使用方法を理解することが不可欠である。その使用方法は、実際は用語「オートパイロット」の通俗的な使用方法とは対照的である。

厳密に言えば、オートパイロットによって操縦士が不要になることはない。高性能なオートパイロットは場合によっては、離陸から着陸までのフライトを管理できるが、実際にはこれはオートパイロットの通常の使用方法ではない。オートパイロットは、通常、複雑で変化する操縦環境で、指定された目標（飛行方位、ピッチ、高度）の達成を容易にするために、特定の再現可能な手動タスク（フラップを動かす、スロットルを調整することなど）を操縦士が実行する必要性を除去するものである。それによって操縦士は、マップや空港侵入ダイアグラムの確認、航空管制官との通信（悪天候を回避する間の通過点の変更に関する話し合いなど）、装置の故障や乗客の病気のような異例の事態の対処などのより高位の問題に集中できる。

操縦士は、彼の代わりにオートパイロットが行うアクションすべてを確認でき、通常、オートパイロットのアクションを監視できる。さらに重要なことに、操縦士は、いつでもそのワークプロセスに介入し、前にオートパイロットに委任したタスクの制御をオートパイロットから取り戻すことができる。明確に言えば、オートパイロットが指定されたルールに厳密に従って操縦している場合でも、最終目標とは異なることを行っていることが判明したらそのアクションを訂正するために操縦士が介入することができるのである。

同様に、高性能なオートパイロットは、様々なシステムおよびインジケータを監視し、操縦士に警告し、必要なときに操縦士に決定を要求する。例えば、オートパイロットが実際に操縦士に、「侵入するためにこの時点で保つべき高度よりも数百フィート高度が高い。侵入を中止して再度試みるか、それともこのまま続けて着陸するか」と言うことを促すこともある。

ＢＰＭアプリケーションの最終目標は、オートパイロットと同じように動作することである。ユーザから委任された繰り返しタスクを実行するだけでなく、ユーザがそれらのアクションを確認でき、エンドユーザが必要に応じていつでも介入でき、一般的にエンドユーザを彼らが最も大きな価値を付加する高位の問題に集中できるようにすることである。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

プロセス事例によって人間の関与の必要性が異なるという事実から、重要な論理的結果が導き出される。プロセス事例によって、オートメーションの必要性が異なるということである。

例えば、アプリケーションに委任される特定の活動は、以下の要因によって変わることがある。
・コンテキスト。例えば、企業が、状況によっては特定の顧客に対するオートメーション化された応答を許可し、主要な顧客に対してはオートメーション化された回答を決して許可しない場合がある。また、その他のコンテキストとしては、特定の種類の商品またはサービス（危険物、キャンセル不可および返品不可の商品、高額なローン）、様々な種類の例外、日付（営業日であるか週末または休日であるかによって警告が異なる動作など）がある。
・アプリケーションを使用する人。例えば、確立されたパートナー関係を持つ経験を積んだユーザは、活動のいくつかをオートメーション化することを好むが、その仕事を始めたばかりの新人は自身で直接制御することを好む場合がある。
・相手側の人間。例えば、顧客側に新しいバイヤーが加わった場合、ＣＳＲでは、対話において同じ会社の経験を積んだバイヤーとの確立された関係の維持に必要な制御と人間的接触よりも、多くの制御と人間的接触が必要になることがある。

その結果、アプリケーションには、特定のタスクをオートメーション化する場合としない場合についてのコンテキストの指定と認識に高い柔軟性がなければならない。

さらに、オートメーションと制御の必要性は、継続中のプロセス事例の中で変化することがある。その結果、ユーザは継続中のプロセスを常に確認できなければならず、必要であれば介入するか、その他の場合であればオートメーション化されるプロセス内の手順を直接制御できなければならない。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

「完全なオートメーション」は極めて少なくなる可能性が高い
ビジネスプロセスの１つの手順でもその状況のほぼ１００％がオートメーション化されることは極めてまれである。

ビジネスプロセスの１つの手順を完全にオートメーション化するには、以下のすべてに該当する必要がある。
・アプリケーションが、関連するプロセスに影響を与える状態変化を発生させる可能性があるすべてのソースからの、プロセス状態の変化に対してアクションを実行する必要性を認識できる。
・アプリケーションが、プロセスを進めるための適切なパスを評価するために必要な意思決定サポートデータのすべてにアクセスできる。これには、現在複数の人の間で行われている共同作業を必要とするデータも含む。
・アプリケーションが、明示的にモデル化され、起こり得る状態とコンテキストごとの一連の適切なアクションの最新の表現を提供するビジネスポリシーにアクセスできる。
・アプリケーションがプロセスを適切な状態に進めるために必要なタスクのすべてを正常に完了できる。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

ルール
オートメーション化の基本モデルは、会社と情報ワーカーがビジネスルールを使用して権限をアプリケーションに委任し、定義された状況でアクションが実行されるようにすることである。ルールは、１つまたは複数の基準が満たされた場合（トリガ）に特定のアクション（既定のアクション以外のアクション）を実行するというアプリケーションに対する指示である。

オートメーションの有用性を最大限に高めるためには、ユーザがアプリケーションのＵＩを使用して実行できるほとんどのタスクをアプリケーション内でオートメーション化できるようにする必要がある。ただし、このことは、ユーザが（１）アプリケーションがどのようなアクションを実行する必要があるのかと、（２）どのような状況のときにアプリケーションがこのアクションを実行する必要があるのかを明確に記述する場合かつその場合に限り、そのタスクをオートメーション化可能にすることを明記することによって限定されなければならない。

ルールは、会社全体に適用することも、特定のパートナーとの対話、特定のＳＫＵを含む注文、または特定の従業員に限定することもできる。

オートメーションのためのロードマップ
オートメーションは段階的に行う。大部分の会社は、プロセスモデリングでビジネスプロセス管理アプリケーションを最初に実装すると同時に多数のタスクをオートメーション化して混乱に招くことはしない。ＳＭＯＲＧの場合は特にそうである。ＳＭＯＲＧでは、現在、プロセスモデリングは高い付加価値を生み出す活動とはみなされておらず、ＳＭＯＲＧの市場区分にそのようなサービスを提供する熟練した広義の従業者（内部または外部）が存在しない。

オートメーション化は時間をかけて行う。オートメーション化は、以下の事項に比例して増加する。
（ｉ）プロセス内のオートメーション化される活動の部分
（ｉｉ）特定の活動の実行において、アプリケーションがユーザの代わりに実行しなければならない権限の程度
ユーザがオートメーションの価値を発見し、アプリケーションを使用して、以前は手動で行っていたタスクを選択してオートメーション化することに慣れてくるにつれて、上記のどちらとも時間の経過とともに増加する。最初にオートメーション化するタスクは、単純で、有用で、リスクが低いタスク（例えばメッセージの転送や警告の送信）である。時間の経過とともに、ユーザが経験を積み、アプリケーションを信頼するようになるにつれて、より複雑で強力なルールを使用するようになる。

アプリケーションに権限を委任するための段階的なアプローチによって、ユーザはリスクの低い方法で信頼を高めることができる。例えば、単純な例を挙げると、ユーザは、数週間、数カ月、または数年間かけて、以下の事項を順番に実行する。
（ｉ）ユーザが直面する一般的なシナリオの意思決定サポートデータの収集をオートメーション化する。
（ｉｉ）意思決定サポートデータの評価をオートメーション化する。
（ｉｉｉ）データの評価とアプリケーションポリシーに基づいて、ユーザに既定の推奨事項を提供するアプリケーションの機能をオートメーション化する。
（ｉｖ）ユーザが安心してその権限を委任した単純な事例で、ユーザの代わりに特定のタスクを実行する権限をアプリケーションに委任する。

アプリケーションは、このオートメーション化をサポートし、支援する必要があるが、多くの場合、それを強制的に進めるべきではない。つまり、プロセス内の手順のオートメーション化は、ユーザが希望し、かつそれを行えるようになるまで、アプリケーションがユーザに強制するべきではない。エンドユーザは、彼らの発注プロセスの繰り返し部分をオートメーション化するのに役立つ適切なツールがあれば、この機能を利用すると思われる。

さらに、現実的には会社やユーザによって、オートメーションの使用程度は異なる。これは、部分的には会社とその社員が関与するビジネスプロセスのダイナミクスに基づいている。しかし、別の大きな要因として、その会社の情報ワーカーと経営者の態度とスキルがある。従業員が彼らが行っているオートメーション化可能な決まりきったアクションそれぞれをＢＰＭアプリケーションを使用して直ちにオートメーション化しなくても、会社は、従業員の「設置ベース（ｉｎｓｔａｌｌｅｄ ｂａｓｅ）」を評価する可能性が高い。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

オートメーション化のユーザの承認
ユーザが、その判断が価値を付加すると考えているタスクを安心してオートメーション化するまでには長い期間を要することがある。

Ｏｌｄｓｍｏｂｉｌｅは、１９４０年に最初の商業的に成功を収めたオートマティックトランスミッションを導入した。しかし、米国でオートマティックトランスミッションが標準となるまでに数十年かかった（多くの場合は、新しい世代のドライバーになっていた）。当然のことながら、この標準としての受け入れには、トランスミッション自体の進歩も大きな役割を果たしている。

さらに、人間の判断によって生み出されると考えられている価値が大きいほど、オートメーション化までにかかる期間は長くなる。

実際の例としては、高性能のスポーツカーのドライバーの大半は、オートマティックトランスミッションを受けて入れておらず、最近になってようやくクラッチを使用する必要がないトランスミッションを受け入れ始めていることが挙げられる。そして、当然のことながら、この受け入れにもテクノロジの進歩が大きな役割を果たしている。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

付録Ａ−ルールの詳細
ルールの機能とトリガ
そのアクションを正確に記述できるのであれば、ユーザがアプリケーションのＵＩを使用して遂行できるどのタスクもルールが遂行できなければならない。例えば、ルールは、以下に関する機能を持っていなければならない。
・内部メッセージのルーティングと警告
・コンテキストに応じた意思決定サポートデータの収集
・ＬＯＢアプリケーションからのデータの保存とクエリ
・アプリケーションでの状態を変化させるタスクの実行（例：承認、拒否、委任）
・ユーザまたはパートナーに対するメッセージの変換、ルーティング、および送信

ルールは、アプリケーションによって認識されるイベントに基づいて起動可能でなければならない。以下に例を示す。
・パートナーからの新しいメッセージの受信
・ＢＰＭアプリケーションに接続しているアプリケーションの状態の変化
・応答を予期していたが受け取らなかったメッセージのタイムアウト

当然のことながら、トリガは、特定のコンテキスト、つまりプロセスやアプリケーションの状態に対して構成可能でなければならない。

ＢＰＭアプリケーションには、プロセス状態に影響するシステムへのクエリに関する様々な機能が必要になる。例えば、実装に何らかの困難が伴う例としては、上位の顧客との関係の拡大を目指している会社は、「ＣＲＭアプリケーションで追跡している「ターゲットリスト」に記載された顧客から、その顧客が以前注文したことがないカテゴリのＳＫＵを含む注文を受けること」に関するトリガを持つことが重要と考える場合がある。

プロセスオートメーションのルールのソース
単純なプロセス事例を管理する人々の支援には、ＢＰＭアプリケーションの「追加設定なしで使用できる」基本プロセスで、十分な場合もある。しかし、実社会の多数のビジネスプロセス、特に情報ワーカーの関与が強いビジネスプロセスでは、特定のビジネス上の目標を達成するためにカスタマイズが行われる。

アプリケーションに組み込まれている基本プロセスには、そのアプリケーションの処理対象のプロセス内で適用される一般的に必要なルールの構成に必要なフックなどがなければならない。例えば、受注ライフサイクルを処理対象とするアプリケーションは、発注書の受け取り後、特定の期間内に発注確認を受け取ることを期待している顧客の考え方に対応して簡単に構成できる必要がある。

アプリケーションは、様々なソースからビジネスプロセスの構成とオートメーション化を可能にするルールが作成されるように設計しなければならない。これには以下が含まれる。

・パートナー。取引先との契約によって、プロセスの整合性を促進するルールが必要になる。これらのルールは、交渉の対象となるか強制的に課せられる契約内に記述される。プロセスに関する契約に従わない場合（これは、ＬＯＲＧ小売業者と取引を行うサプライヤで顕著である）は、プロセスに従わない場合の「入金相殺」ペナルティにつながることがある。

・業界標準。縦型構造の産業は、ルールとして表現できるいくつかの基準（データセマンティクス、メッセージ構造、またはモデル化されたプロセスフロー）が作成されている場合がある。これらは、それらの産業に関与する企業にとって有用であり、ＬＯＲＧパートナーとの契約の出発点となることがある。

業界標準とパートナー契約では、通常、メッセージ形式と、予期されるプロセスの特定の局面（フローやタイミングなど）のみが指定される。これらのルールには、パートナーコミュニケーションの面で実行できるようにするためにその内部プロセスを運用可能にする方法は示されていない。その結果、企業は、それらのパートナーとのプロセスを管理するために、それらのパートナーのルールを採用するだけでなく、より多くのことを実行しなければならないことを認識する。

・ＶＡＲ、ＩＴ（information technology）スタッフ。内部ＩＴスタッフおよびＶＡＲ（アウトソースのＩＴスタッフとして稼動する者）は、プロセスモデリングを行い、利用可能なＯＯＢではない特定のプロセスとポリシーを明文化するルールの定義と実装に役立てる。

・エンドユーザ。特にＳＭＯＲＧでは、エンドユーザが自身の仕事を容易にするために役立つルールの開発に責任を持つ（または開発したいと考えている）。ユーザの役割と社会経験と知識のレベルによって、この機能を使用する度合いが異なる。社会経験が豊かで様々な知識を持つユーザ間、および多数の繰り返しタスクを必要とする役割を持つユーザ間のほうがルールを使用する度合いが強い。類似したパターンは、エンドユーザによるＯｕｔｌｏｏｋ（登録商標）のルールウィザードの使用にみられる。様々なトピックを含み、優先順位が異なる大量の電子メールを受信する、社会経験が豊かで様々な知識を持つユーザは、それほど経験や知識がないユーザや電子メールを少ししか受信しないユーザよりもルールウィザードを使用する傾向が強い。

ルールのライフサイクル−概要
ルールに必要な機能の詳細な説明はこの論文の範囲外であるが、プロセス管理に明示的にエンドユーザを組み込むと、ルールの設計だけでなく、上記の説明のように、それらの開発、使用、管理などに関する固有の機能が必要になる可能性があることに注意が必要である。プロセスオートメーションのためにルールを使用する場合、ユーザ（存在する場合はＩＴスタッフおよび情報ワーカー管理者を含む広い意味でのユーザ）は基本的に以下の実行を可能にする機能を求める。
・ユーザの役割とスキルレベルに合わせた環境でルールを設計する。
・製造プロセスに実装する前にルールをテストする。
・その他のルールに基づいて手動または自動的にルールのオンとオフを切り替える。
・外部ソースからルールをインポートする（例：ダウンロードしたパートナーとの契約）。
・エンドユーザ間でのルールを共有する（例：ルールを開発した予測専門家が、それを有用と考える可能性があるその他の予測専門家と共有できる）。
・ルールを展開するための承認ワークフロー（例：カスタマーサービス担当者が展開を求めているルールの承認を行う部門管理者）。
・該当する場合は、リアルタイムでルールの活動を監視する（ルールのトレースなど）。
・ポリシーに対してルールの実際のアクションを監視する。
・ルールが矛盾した場合の続行方法に関するメタルールを含めてルールを管理する。

付録Ｂ−エンパワードオートメーションとセルフサービス
オートメーションに対して明らかになっている一般的な目標の１つは、セルフサービスを可能にすることである。セルフサービスは、特定の結果を達成するためのコストを軽減するだけではない。場合によっては、サービスを受ける者により高い満足感を与えることもある。しかし、エンドツーエンドプロセスのセルフサービスには、完全なオートメーション化が不可能である部分や、望ましくない部分も含むプロセス全体のオートメーションが必要である。

エンパワードオートメーションは、プロセス内の特定の手順を選択してオートメーション化するためのフレームワークを提供するのと同じ方法で、特定のプロセス手順または特定の状況でセルフサービスを実装できるようにすることによって、選択的なセルフサービスを可能にするフレームワークも提供する。これには、ビジネスプロセス全体をセルフサービス、エンドツーエンドにすることを困難にするビジネスプロセス全体の根本的な再構築を必要としない。エンパワードオートメーションを対象とするＢＰＭアプリケーションは、完全にオートメーション化されたシナリオよりも、豊かなセルフサービス経験を提供することができる。それは、そのようなアプリケーションでは、完全にオートメーション化されたアプリケーションでは行えない、データの保存やデータへのアクセスが行えるためである。例えば、完全にオートメーション化されたアプリケーションでは、電子メールのような構造化されていない関連するコミュニケーションなどのアイテムが組み込まれる可能性が低い。

付録Ｃ−ビジネスプロセス管理の重要性
過去２０年間にわたり、規制緩和とコミュニケーションテクノロジの向上が、大きなマーケットトレンドを作り出してきた。そのトレンドとは、購入とソーシングのグローバル化、顧客の知識と力の増大、製品ライフサイクルの短縮化、製造、出荷と物流、およびその他のビジネス機能のアウトソーシングである。

これらのトレンドはすべて、様々な高度な技術を持つあらゆるサイズのビジネスパートナーを含む動的で、場合によっては地域的に分散したネットワークを利用して効率的に仕事をこなせる会社に有利に働く。適切なネットワークを持っていることだけでなく、彼らと効率的に仕事をすることが重要である。これによって、会社の様々なパートナーと正確に迅速に機敏にビジネスプロセスを実行できる能力の重要性が急速に高まった。さらに、多数の会社、特にＬＯＲＧは、すでに多くの仕事を行って内部プロセスを改良しており、パートナーとの対話のプロセスが、今後向上を目指すための改良に最も適した部分となっている。

図１３は、ビジネスプロセス管理の重要性を推進するダイナミクスを示す図である。

ビジネスプロセス管理は新たに生まれたニーズであるが、ＢＰＭ対応のテクノロジ（つまりミドルウェア）は、企業に対する新しいソフトウェアカテゴリとして出現する。我々は、現在提供されているパッケージ化されたＢＰＭアプリケーションは把握していない。また、Ｇａｒｔｎｅｒも、２００３年３月の時点でパッケージ化されたＢＰＭアプリケーションを認識していない。

本発明を適用できる実施形態の一般的なコンピューティング環境を示す図である。 本発明を適用できる実施形態の一般的なビジネスネットワーキング環境を示す図である。 本発明を適用できる実施形態のビジネスネットワーキング環境において連結する２つのサーバの構成図である。 本発明を適用できる実施形態のプロセステンプレートの構成図である。 本発明を適用できる実施形態の顧客／サプライヤビジネストランザクションプロトコルにおけるトランザクション文書の流れ図である。 ＭＢＮ（商標）システムの構成要素を示す図である。 ＭＢＮ（商標）の概要を示す図である。 Ｏｕｔｌｏｏｋ（登録商標）のスクリーンショットの図である。 ＭＢＮ（商標）Ｅｘｃｅｌ（商標）アドインのスクリーンショットの一例を示す図である。 エンパワードオートメーションと写真の例を示す図である。 情報ワーカーを示す図である。 ビジネスプロセス事例での手順における情報ワーカーの活動を示す図である。 ビジネスプロセス管理の重要性を推進するダイナミクスを示す図である。

符号の説明

２１０ アプリケーションサーバ
２１４ ビジネスサーバソフトウェアモジュール
２１６ ビジネスサーバソフトウェアモジュール
２１８ ピアツーピア接続
２２０ 中間ホスト
２２２ プロセステンプレート
２２４ アプリケーション
２２６ プロセステンプレート
２２８ アプリケーション

Claims (19)

1. 情報を処理するための命令を有するコンピュータ読取り可能な記録媒体であって、前記命令は、
   活動シーケンスにおいて交換されるビジネスエンティティの構造を定めるビジネスエンティティモジュールと、
   前記ビジネスエンティティに対して実行することができる関連活動の活動シーケンスを定めるエンティティ活動モジュールと、
   トランザクション文書を定め、前記ビジネスエンティティモジュールおよび前記活動シーケンスに基づいて対応するトランザクション文書を作成するトランザクション文書モジュールと
   を備えたことを特徴とするコンピュータ読取り可能な記録媒体。
2. 前記命令は、前記エンティティの各々を関連づけ、履歴に記録する方法を定める相関モジュールをさらに備えた
   ことを特徴とする請求項１に記載のコンピュータ読取り可能な記録媒体。
3. 前記命令は、前記ビジネスエンティティモジュール、前記活動シーケンスおよび前記トランザクション文書モジュールの特定のバージョンを識別するバージョン識別子をさらに備えた
   ことを特徴とする請求項１に記載のコンピュータ読取り可能な記録媒体。
4. 前記命令は、前記トランザクション文書の各々に対するルーティング規則を定めるルーティングモジュールをさらに備えた
   ことを特徴とする請求項１に記載のコンピュータ読取り可能な記録媒体。
5. 第１のコンピュータと第２のコンピュータとの間の通信プロトコルを確立するための方法であって、
   トランザクションに関連づけられた複数の文書を識別するステップと、
   前記複数の文書に対する活動シーケンスを定めるステップと、
   前記活動シーケンスに基づいて、前記複数の文書の１つを作成するステップと
   を備えることを特徴とする方法。
6. バージョン識別子をチェックして、前記第１のコンピュータおよび第２のコンピュータが、前記活動シーケンスに関連するプロセステンプレートの同一バージョンを含むかどうかを確認するステップをさらに備える
   ことを特徴とする請求項５に記載の方法。
7. 前記第２のコンピュータが前記プロセステンプレートの同一バージョンを含まない場合に、前記第２のコンピュータによる前記プロセステンプレートのコピーを要求するステップをさらに備える
   ことを特徴とする請求項６に記載の方法。
8. 前記文書の各々に対する一組の表示規則に基づいて文書を表示するステップをさらに備える
   ことを特徴とする請求項５に記載の方法。
9. 前記文書の各々に対して実行することができる活動を定めるステップをさらに備える
   ことを特徴とする請求項５に記載の方法。
10. 前記第１のコンピュータと前記第２のコンピュータとの関係に基づいて、前記文書の１つを作成するステップをさらに備える
    ことを特徴とする請求項９に記載の方法。
11. 前記第１のコンピュータはサプライヤに関連づけられ、前記第２のコンピュータは顧客に関連づけられている
    ことを特徴とする請求項１０に記載の方法。
12. ルーティング規則に基づいて、前記文書を前記第１のコンピュータから前記第２のコンピュータに送るステップをさらに備える
    ことを特徴とする請求項５に記載の方法。
13. 前記文書の各々における情報を、前記第１のコンピュータおよび前記第２のコンピュータの一方のアプリケーションに統合するステップをさらに備える
    ことを特徴とする請求項５に記載の方法。
14. プロセステンプレートを含むメモリを有する第１のコンピュータであって、前記プロセステンプレートは、
    活動シーケンスにおいて交換されるビジネスエンティティの構造を定めるビジネスエンティティモジュールと、
    前記ビジネスエンティティに対して実行することができる関連活動の活動シーケンスを定めるエンティティ活動モジュールと、
    トランザクション文書を定め、前記ビジネスエンティティモジュールおよび前記活動シーケンスに基づいて対応する文書を作成するトランザクション文書モジュールと
    を含む第１のコンピュータと、
    前記プロセステンプレートのコピーを含むメモリを有し、前記プロセステンプレート、および前記第１のコンピュータと第２のコンピュータとの関係に基づいて活動を実行する第２のコンピュータと
    を備えたことを特徴とするビジネスネットワーク。
15. 前記プロセステンプレートは、前記エンティティの各々を関連づけ、履歴に記録する方法を定める相関モジュールをさらに含む
    ことを特徴とする請求項１４に記載のネットワーク。
16. 前記プロセステンプレートは、前記ビジネスエンティティモジュール、前記活動シーケンスおよび前記トランザクション文書モジュールの特定のバージョンを識別するバージョン識別子をさらに含む
    ことを特徴とする請求項１４に記載のネットワーク。
17. 前記第２のコンピュータは、前記バージョン識別子をチェックして、前記プロセステンプレートの前記特定バージョンがそこに記憶されているかどうかを確認し、前記第２のコンピュータが前記プロセステンプレートの前記特定バージョンを含んでいない場合は、前記プロセステンプレートの前記特定バージョンの新たなコピーを要求するように構成されている
    ことを特徴とする請求項１６に記載のネットワーク。
18. 前記プロセステンプレートは、前記トランザクション文書の各々に対するルーティング規則を定めるルーティングモジュールをさらに含む
    ことを特徴とする請求項１４に記載のネットワーク。
19. 前記関係は、サプライヤに関連づけられている前記第１のコンピュータと、顧客に関連づけられている前記第２のコンピュータとを含む
    ことを特徴とする請求項１４に記載のネットワーク。
    

Images