(57)【要約】本発明は、作業リストを予報するシステムおよび方法に関する。このような方法の一実施形態は、（ａ）問題とするワークフロー・プロセスに関する情報を受け取るステップと（１５２）、（ｂ）ワークフロー・プロセスについてプロセス定義を受け取るステップと（１５６）、（ｃ）プロセス定義に基づいてワークフロー・プロセスのケースについて少なくとも１つの未解決ステップを決定するステップと（１５８）、（ｄ）未解決ステップについて定義を受け取るステップと（１６０）、（ｅ）未解決ステップを実行して、未解決ステップについて予想終了時間を計算するステップと（１６２）、ステップ（ａ）〜（ｅ）を使用して、問題とするワークフロー・プロセスに関連することが予想される作業項目を予報することを含む。未解決ステップの定義は、予報条件を含むことができる。未解決ステップの実行は、少なくとも部分的にプロセス定義およびケース・データに基づいて、条件を評価することを含むことができる。
2005527916.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つの指定されたプロセスについて作業リストを予報する作業リスト予報システムであって、
指定されたワークフロー・プロセスについてプロセス定義を受け取るように動作するプロセス定義受け取りモジュールと、
プロセス定義受け取りモジュールに結合され、プロセス定義に基づくケースについて少なくとも１つの未解決ステップを決定するように動作するステップ決定モジュールと、
ステップ決定モジュールに結合され、未解決ステップについて定義を受け取るように動作するステップ定義受け取りモジュールと、
ステップ定義受け取りモジュールに結合され、未解決ステップを実行して、未解決ステップについて予想終了時間を計算するように動作する実行モジュールと
を備えるシステム。
【請求項２】
更に、プロセス定義受け取りモジュールに結合され、問題とするワークフローに関する情報を受け取るように動作する予報情報受け取りモジュールを備える、請求項１に記載のシステム。
【請求項３】
作業リストを予報する方法であって、
（ａ）ワークフロー・プロセスに関する情報を受け取るステップと、
（ｂ）ワークフロー・プロセスのプロセス定義を受け取るステップと、
（ｃ）プロセス定義に基づいて、ケースについて少なくとも１つの未解決ステップを決定するステップと、
（ｄ）未解決ステップについて定義を受け取るステップと、
（ｅ）未解決ステップを実行して、未解決ステップについて予想終了時間を計算するステップと、
を備える方法。
【請求項４】
ワークフロー・プロセスのプロセス定義が予報条件を含む、請求項３に記載の方法。
【請求項５】
未解決ステップを実行するステップが、
少なくとも部分的にワークフロー・プロセス定義およびケース・データに基づいて、予報条件を実行する工程を備える、請求項４に記載の方法。
【請求項６】
予報条件を実行するステップが、条件定義の設定を決定する工程を備える、請求項５に記載の方法。
【請求項７】
更に、ステップ（ａ）〜（ｅ）を使用して、問題とする時間間隔内に期限が来ると予想される作業項目を予報するステップと、
問題とするパラメータに従って作業リストから項目を提供するステップと、
を備える、請求項３に記載の方法。
【請求項８】
作業リストから項目を提供するステップが、問題とするパラメータを包含するクエリーに応答して作業リストから項目を提供する工程を備える、請求項７に記載の方法。
【請求項９】
ワークフロー・プロセスに関する情報が、問題とする時間間隔を含む、請求項３に記載の方法。
【請求項１０】
ワークフロー・プロセスに関する情報が、ワークフロー・プロセスに関連づけられたケース参照番号を含む、請求項３に記載の方法。
【請求項１１】
ワークフローに関する情報が、問題とする作業者を含む、請求項３に記載の方法。
【請求項１２】
ワークフロー・プロセスに関する情報が、ワークフロー・プロセスの名前を含む、請求項３に記載の方法。
【請求項１３】
ワークフロー・プロセスに関する情報が、ケース・データを含む、請求項３に記載の方法。
【請求項１４】
ワークフロー・プロセスに関連づけられた作業リストを予報する方法であって、
（ａ）ワークフロー・プロセスに関する情報を受け取るステップと、
（ｂ）ワークフロー・プロセスのプロセス定義を受け取るステップと、
（ｃ）プロセス定義に基づいて、ワークフロー・プロセスのケースについて少なくとも１つの未解決ステップを決定するステップと、
（ｄ）未解決ステップについて定義を受け取るステップと、
（ｅ）未解決ステップを実行して、未解決ステップについて予想終了時間を計算するステップと、
ステップ（ａ）〜（ｅ）を使用して、ワークフロー・プロセスに関連して期限が来ると予想される項目の作業リストを予報するステップと、
（ｆ）問題とするパラメータに従って作業リストから項目を提供するステップと、
を備える方法。
【請求項１５】
ワークフロー・プロセスのプロセス定義が、予報条件を含む、請求項１４に記載の方法。
【請求項１６】
未解決ステップを実行するステップが、少なくとも部分的にプロセス定義およびケース・データに基づいて、予報条件を実行する工程を備える、請求項１５に記載の方法。
【請求項１７】
問題とするパラメータが、問題とする時間間隔を含む、請求項１４に記載の方法。
【請求項１８】
問題とするパラメータが、少なくとも１つのワークフローのケース番号を含む、請求項１４に記載の方法。
【請求項１９】
問題とするパラメータが、問題とする作業者を含む、請求項１４に記載の方法。
【請求項２０】
ワークフロー・プロセスに関する情報が、ワークフロー・プロセスの名前およびワークフロー・プロセスに関連づけられたケース参照番号を含む、請求項１４に記載の方法。
【発明の詳細な説明】
【発明の背景】
【０００１】
本発明は、ワークフローの管理に関し、更に具体的には、ワークフローに関連した作業リストを予報するシステムおよび方法に関する。
【０００２】
ワークフローは、典型的には、多数の区別可能なステップを含む。例えば保険申込書のような申込書を処理するワークフローは、１）申込書の詳細を捕捉、２）完成した申込書をプロセッサへ割り振り、３）完成した申込書を処理、４）完成した申込書をアーカイブすることを含んでもよい。ケースとは、ワークフローのインスタンスである。
【０００３】
現在、ワークフローを管理するシステムは存在している。例えば、Ｔａｒｕｍｉ  ｅｔ  ａｌへ発行された「Ｗｏｒｋｆｌｏｗ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｏｐｅｒａｔｉｎｇ  ａｎｄ  Ｍａｎａｇｉｎｇ  Ｊｏｂｓ  ｗｉｔｈ  Ｐｒｅｄｉｃｔｉｎｇ  Ｆｕｔｕｒｅ  Ｐｒｏｇｒｅｓｓ  ｏｆ  Ｗｏｒｋｆｌｏｗ  Ｊｏｂ」と題する米国特許第５，９１８，２２６号は、特に、ワークフローの特定のケースが所定のデッドラインを満たすかどうかを予報することに関する。
【０００４】
Ｔａｒｕｍｉへ発行された「Ｗｏｒｋｆｌｏｗ  ｓｙｓｔｅｍ  ｆｏｒ  ｒｅａｒｒａｎｇｅｍｅｎｔ  ｏｆ  ａ  ｗｏｒｋｆｌｏｗ  ａｃｃｏｒｄｉｎｇ  ｔｏ  ｔｈｅ  ｐｒｏｇｒｅｓｓ  ｏｆ  ａ  ｗｏｒｋ  ａｎｄ  ｉｔｓ  ｗｏｒｋｆｌｏｗ  ｍａｎａｇｅｍｅｎｔ  ｍｅｔｈｏｄ」と題する米国特許第６，１１５，６４０号も、特に、ワークフローの特定のケースが所定のデッドラインを満たすかどうかを予報することに関する。
【０００５】
しかし、予想開始時間および持続時間と一緒に将来の仕事をリストし、ワークフローのケースについて将来の仕事をリストし、特定の作業者または作業者のグループについて将来の仕事をリストし、および／またはデータの特定の項目、例えば患者の識別番号に関連した将来の仕事をリストするシステムおよび方法の必要性が残っている。更に、ワークフローの設計者が作業リストの予報の中に条件命題を含めることができるシステムおよび方法の必要性が存在する。
【発明の概要】
【０００６】
本発明は、作業リストを予報するシステムおよび方法に関する。一実施形態において、提供された作業リストは、現在期限に達している作業項目だけでなく、将来期限に達すると、システムが予想する作業項目を含む。
【０００７】
本発明の一実施形態は、ワークフローの１つのケースについて将来の作業ステップを予報する。システムがワークフローの名前を受け取ったとき、システムは指名されたワークフローについて将来の作業ステップを予報する。本発明の実施形態は、指名されたワークフローの生のケースに対して予報するか、そのワークフローの仮想ケースをシミュレートすることができる。双方のケースで、本発明の実施形態は、問題とするワークフローの定義（ワークフロー・ステップおよびそれらステップ間のルーティング・ロジックの定義）を検索する。
【０００８】
システムが生のケースで動作するとき、システムはケースのデータを検索する。次にシステムは、そのケースについて１つまたは複数の未解決ステップを検索するようにワークフローに求める。これらの未解決ステップを使用して、予報ロジックは未解決ステップを実行し（実行をシミュレートし）、ステップの予想持続時間を決定し、現在の未解決ステップに後続するステップをプロセス定義から決定する。後続するステップは条件付きアクションを含んでよい。予報ロジックは、条件付きアクションを実行し、条件付きアクションを含むステップに先立つステップの完了時にプロセスで取られるルートを決定する。
【０００９】
前述したメカニズムを使用して、本発明の一実施形態に従ったシステムは、将来のステップおよびそれらの予想開始時間および持続時間のリストを作り出す。
【００１０】
システムがワークフローの仮想ケースで動作するとき（シミュレーション）、システムはシミュレートされたデータおよび予報を開始するステップを受け取る。この受け取られるデータの差異を除いて、他の全てのアクションは生のケースと同じである。本発明の他の実施形態は、１つまたは複数のワークフロー・プロセスの１つまたは複数の生のケースについて、特定のクエリー規準を満足させる将来の作業ステップのリストを予報する。
【００１１】
この実施形態において、エンティティ、例えば作業者が、ワークフローのケースの上でアクションを実行するとき、アクションの実行は予報モジュールをトリガする。予報モジュールは問題とするケースおよびワークフローの識別子を受け取る。予報モジュールは、ワークフロー定義およびケース特定データを検索する。次に予報モジュールは、前述したような将来の作業リストを生成する。一実施形態において、将来の作業リストは、ワークフローの全ての生のケースについて将来の作業リストを含むマスター・リストを更新する。ケースの新しく生成された将来の作業リストが将来のマスター作業リストを更新するとき、新しく生成された将来の作業リストは、問題とするケースの以前の将来の作業リストと入れ替わる。
【００１２】
次にシステムは、多様な規準、例えば、問題とする作業者ＩＤ、ケース番号／主題ＩＤ、および期限に従って将来の作業リストを見つけるように、マスター・リストに照会することができる。
【００１３】
本発明の他の実施形態は、作業リストを予報する方法を提供する。方法は、（ａ）問題とするワークフロー・プロセスに関する情報を受け取るステップと、（ｂ）指定されたプロセスのプロセス定義を受け取るステップと、（ｃ）プロセス定義に基づいて、ワークフロー・プロセスのケースについて少なくとも１つの未解決ステップを決定するステップと、（ｄ）未解決ステップの定義を受け取るステップと、（ｅ）未解決ステップを実行して、未解決ステップの予想終了時間を計算するステップと、ステップ（ａ）〜（ｅ）を使用して、問題とするワークフロー・プロセスとの関連で期限が来ると予想される作業項目を予報するステップを含む。未解決ステップの定義は、予報条件を含むことができる。未解決ステップの実行は、少なくとも部分的にプロセス定義およびケース・データに基づいて、条件を評価することを含む。
【００１４】
本発明の更に他の実施形態は、少なくとも１つの指定されたワークフロー・プロセスについて作業リストを予報する作業リスト予報システムを提供する。システムは、指定されたプロセスについてプロセス定義を受け取るように動作するプロセス定義受け取りモジュールを含む。システムは、更に、プロセス定義受け取りモジュールと通信するステップ決定モジュールを含む。ステップ決定モジュールは、プロセス定義に基づいてケースの少なくとも１つの未解決ステップを決定する。システムは、ステップ決定モジュールと通信するステップ定義受け取りモジュールを含む。ステップ定義受け取りモジュールは、未解決ステップについて定義を受け取る。システムは、更に、ステップ定義受け取りモジュールと通信する実行モジュールを含む。実行モジュールは、未解決ステップを実行して、未解決ステップについて予想終了時間を計算する。
【００１５】
本発明は、以下の詳細な説明および本発明の実施形態の添付の地面から、より完全に理解されることが可能である。図面は例示を目的とするだけで、本発明の範囲を限定するものではない。
【例示的実施形態の詳細な説明】
【００１６】
本発明は、作業リスト、例えば、完了すべき作業項目のリストを予報するシステムおよび方法に関する。作業項目は、１つまたは複数のワークフローの一部分であることができる。ワークフローは、典型的には、多数の区別可能なステップを含む。各々のステップは１つまたは複数の作業項目を含むことができる。
【００１７】
一実施形態において、作業リストは、現在、期限が来ている作業項目および将来期限が来ることが予想される作業項目の双方を含む。例としては、特定の患者が病院に滞在する間（多くの日数であるかも知れない）に予想される全作業のリスト、および責任を有する看護士が患者について現在のシフト（８時〜１２時）の間に実行すべき全作業のリストである。他の例としては、当月の間に特定の保険アプリケーション・プロセッサが実行することを予想される全作業のリスト、および特定のマネージャの監督のもとで保険業者が当月の間に実行すべき全作業のリストである。
【００１８】
上記の事項を実行する能力を有すれば、ユーザは作業の予測を改善して、どのような作業が未解決であるかを決定することができ、更に作業が将来いつ完了するかをマネージャが決定することを助けることができる。マネージャまたはスーパーバイザは、この機能を使用して、予想されるリソースが更に信頼性をもって働くように助けることができる。顧客サービスの要員は、ケースで起こる予想アクションの問い合わせについて更に信頼性をもって答えることができる。
【００１９】
ワークフロー管理システムは、少なくとも１つのワークフローを管理する。ワークフロー、ワークフロー・プロセス、およびプロセスの用語は、現在の目的からは互換的である。前述したように、ワークフローは、典型的には、多数の区別可能なステップを含む。各々のワークフローは、データに関連づけられ、データベースの中の他のシステムへリンクする。ケースとは、ワークフローの１つのインスタンスである。作業者／当事者は、ケースを作り上げているステップまたはステップの一部分を実行する。一実施形態において、作業者／当事者は作業キューを介してケースを受け取る。ワークフロー・プロセスの設計者は、最初にワークフローのステップを指定し、次に、各々のステップについてステップの目的を決定し、ステップに関連づけられたデータ要件およびユーザ関与を定義する。こうして、定義された関係を有する多数のステップが、ワークフローを作り上げることができる。
【００２０】
生のデータおよび現実の未解決ステップの代わりに、テスト・データを使用し、開始ステップのリストを提供することは、ケースをシミュレートするため本発明の予報機能を使用できることを意味する。
【００２１】
ワークフロー管理システムを使用して、本発明の一実施形態のシステムおよび方法を使用することができる。図１を参照すると、ワークフロー管理システム１００のソフトウェア・アーキテクチャは、通信層１０８、作業キュー・サービス１１０、バックグラウンド／ワークフロー・サービス１１２、データ・サービス１１４、ファイル・インタフェース層１１６、アプリケーション・サーバ１１８、アプリケーション層１２０、および予報モジュール１４０を含む層状構造を採用することができる。更に、図１には、ワークフロー管理システム１００と対話するように構成され、プロセス・エンジンとも呼ばれるプロセス・オブジェクト・クライアント（１０４）が示される。
【００２２】
クライアント・サービスは、作業キュー・サービス１１０、アプリケーション・サーバ１１８、およびアプリケーション層１２０を含む。ワークフロー・サービスは、バックグラウンド／ワークフロー・サービス１１２および予報モジュール１４０を含む。クライアント・サービスおよびワークフロー・サービスは、ファイル・インタフェース層（１１６）を介してデータ・サービス（１１４）にアクセスする。
【００２３】
［プロセス・オブジェクト「クライアント」１０４］
プロセス・オブジェクト（ＰＯ）クライアント１０４は、アプリケーション１２４、プロセス・オブジェクト・クライアント・コンポーネント１２６、および通信層１２８を含む。開発者は、プロセス・オブジェクト・クライアント・コンポーネント１２６によって露出されたインタフェースを使用して、アプリケーション１２４を作り出す。アプリケーションは、ユーザ対面アプリケーション、即ち、ユーザ・インタフェースを含むアプリケーションであるか、他のアプリケーションに直接インタフェースするアプリケーションであることができる。ワークフロー管理システムは、多数のこのようなアプリケーション、例えばプロセス・デファイナ（プロセスの定義に使用される）を提供する。全てのケースにおいて、アプリケーションはプロセス情報を検査するか、作業キューから作業項目をオープンし、作業項目を管理することができる。多くのケースにおいて、ワークフロー管理システムの顧客は、プロセス・オブジェクト・クライアント１２６によって提供される機能を使用して、自分自身のアプリケーションを作り出す。
【００２４】
ＰＯクライアント１２６は、プログラミング・インタフェースを露出して、ワークフロー管理システムの顧客がワークフロー・アプリケーションを構築できるようにする。ＰＯクライアントは、ワークフロー機能およびデータを露出して、アプリケーションがワークフロー・プロセス、作業項目、ワークフロー関連データ、および組織および管理情報／機能にアクセスできるようにする。ワークフロー管理システムは、更に、ＰＯオブジェクト・インタフェースの上に構築されるアプリケーションを提供する。ＰＯクライアントは、通信層１２８および１０８を介してプロセス・オブジェクト・アプリケーション・サーバ１１８の対応するサーバ・ベース・コンポーネントへアクセスすることによって、データおよび機能を提供する。
【００２５】
クライアント側の通信層１２８は、サーバ側の送信層１０８と通信して、ワークフロー関連データおよび機能が、ＰＯクライアント１２６とＰＯアプリケーション・サーバ１１８との間で双方向的に交換されるのを容易にする。
【００２６】
プロセス・オブジェクト「クライアント」は、企業規模のワークフロー・アプリケーションを開発するのに必要な労力および時間を削減するオブジェクト指向インタフェースをアプリケーション開発者に提供する。企業標準インタフェースを使用してプロセス・オブジェクト「クライアント」を実現することによって、開発者は自由に選択した開発ツールを使用して、顧客のビジネス・ソリューションとインタフェースすることができる。プロセス・オブジェクト・クライアントは、顧客のシステムの管理機能へのアクセスをアプリケーション開発者に提供する。ＴＣＰ／ＩＰは、サーバとの通信を容易にする。ＰＯクライアントは、ＰＯアプリケーション・サーバ１１８を介してワークフロー管理システム１００とインタフェースする。
【００２７】
プロセス・オブジェクト・クライアントは、Ｗｉｎｄｏｗｓ３２ビット・プラットフォーム（Ｗｉｎｄｏｗｓ  ９８／Ｍｅ、Ｗｉｎｄｏｗｓ  ＮＴ、およびＷｉｎｄｏｗｓ  ２０００）およびＷｅｂクライアント（シン・ブラウザ・ベース・クライアント）の双方で利用可能である。Ｗｅｂクライアントは、アクティブ・サーバ・ページ（ＡＳＰ）およびＪａｖａサーバ・ページ（ＪＳＰ）テクノロジをそれぞれ使用して、マイクロソフトおよびＵＮＩＸベースのＷｅｂサーバで使用することができる。Ｗｅｂクライアントは、アプリケーション１２４の一実施形態である。しかし、システム１００とインタフェースする他のアプリケーション１２４を使用することができる。
【００２８】
Ｗｉｎｄｏｗｓ  ３２ビット・ベースの変形では、開発者はアプリケーション層（ＡＬ）プログラミング・インタフェースへのアクセスを有する。アプリケーション層プログラミング・インタフェースによって、開発者は、アプリケーション１２４によって提供されたユーザ・インタフェースをカスタマイズすることができる。例えば、開発者は、標準形式ファシリティの代わりに代替形式パッケージを使用することができる。
【００２９】
Ｗｉｎｄｏｗｓ  ３２ビットの変形では、ＴＣＰ／ＩＰがプロセス・オブジェクト・クライアント１０４とプロセス・エンジン１００との間の通信を容易にし、同時にＷｅｂクライアントは、ブラウザとＷｅｂサーバとの間で通信するため標準のＨＴＴＰオプション（ＳＨＴＴＰを含む）を使用する。
【００３０】
［ファイル・インタフェース層（ＦＩＬ）１１６］
ファイル・インタフェース層（ＦＩＬ）１１６は、ホスト・ファイル・システムまたはリレーショナル・データベース管理システム（ＲＤＢＭＳ）のいずれかに存在するデータへのアクセスを、クライアントを含む他の全てのコンポーネントへ提供するモジュールである。データがＲＤＢＭＳに保持されるケースでは、データへの物理アクセスは、データベース・サービス・コンポーネントによって実行されるが、ＦＩＬによってコントロールされる。ＦＩＬは、データがホスト・ファイル・システム上のファイルに保持されるかＲＤＢＭＳに保持されるかに関して他のコンポーネントへトランスペアレントであるように、その機能を実行する。
【００３１】
［プロセス・オブジェクト・アプリケーション・サーバ１１８］
プロセス・オブジェクト・アプリケーション（ＰＯＡ）サーバ１１８は、プロセス・オブジェクト・クライアント１０４とプロセス・エンジン１００との間のゲートウェイ・サービスである。ＰＯＡサーバ１１８は、プロセス・エンジンとプロセス・オブジェクト・ベース・アプリケーションとの間の接続を管理する責任を有し、クライアントがリクエストするワークフロー機能をクライアントに提供する。ＰＯＡサーバ１１８は、高いパフォーマンスおよびスケーラビリティを有するように設計されたマルチスレッド・コンポーネントである。ダイレクト・ソケットは、プロセス・オブジェクト・クライアントとサーバ１００との間のＴＣＰ／ＩＰを介する通信を容易にする。
【００３２】
［Ｗｅｂクライアント・ゲートウェイ］
Ｗｅｂクライアントは、Ｗｅｂサーバの上に存在するＷｅｂクライアント・ゲートウェイと通信する。Ｗｅｂクライアント・ゲートウェイは、プロセス・オブジェクト・クライアント（１２６）の最上部に構築されるアプリケーションである。実際には、それはアプリケーション（１２４）の１つの例である。それはＷｅｂサーバ環境で実行され、Ｗｅｂページ上のハイパーテキスト・リンクを介してＷｅｂブラウザへ露出される。Ｗｅｂページ・アクセスを介して活性化されたとき、それはワークフロー関連データ、プレゼンテーション、および機能をＷｅｂブラウザへ提供することができ、また通信層（１０８および１２８）を介してワークフロー・サーバ（１００）と通信することができる。Ｗｅｂクライアント・ゲートウェイは、プロセス・オブジェクトを使用して、Ｗｅｂクライアントのために国境のないワークフロー機能を提供し、ＴＣＰ／ＩＰを使用してＰＯＡサーバ１１８と通信し、したがって別個のマシンに存在することができる。
【００３３】
［アプリケーション層（ＡＬ）１２０］
アプリケーション層（ＡＬ）１２０は、異なったクライアント・ベース・サービス（クライアント・ユーザ・インタフェースおよびプロセス・オブジェクト・アプリケーション・サーバ１１８）のためにクライアント・ベース・ワークフロー機能を提供する。ＡＬによって提供されるサービスは、ログイン／ログアウト、オープン作業項目からリリース作業項目までの範囲にわたる。オープン作業項目およびリリース作業項目は、ワークフロー管理システムによって管理される特定の作業項目と対話するときに使用されるサービスである。ＡＬ１２０は、更に、後で説明する定義を処理するためのアクセスを提供する。
【００３４】
［作業キュー・サービス１１０］
作業キュー・サービス１１０は、次のサービスを提供する。
・ユーザがどのキューにアクセスし、それらのキューにどれくらいの作業が存在するかの情報をユーザに供給する。
・どのような項目が作業キューに現れるかの情報をユーザに供給する。
・キューの中の項目をサーチ／ソート／フィルタするインタフェースを供給する。
【００３５】
作業キュー・サービス１１０は、図１のアーキテクチャを組み込んだワークフロー管理システムを拡大縮小する能力を促進する。作業キュー・サービス１１０は、マルチプロセッシングおよびマルチスレッド・テクノロジを使用して、利用可能なハードウェアおよびオペレーティング・システムのファシリティの利用を改善する。
【００３６】
作業キュー・サービスは、２つのコンポーネント・タイプを含む。即ち、ａ）誰が様々なキューへアクセスするかの情報を提供する作業キュー・サーバ（ＷＱＳ）、およびｂ）作業キューの内容に関する（即ち、作業キューの中に存在する作業項目に関する）情報を提供する作業項目サーバ（ＷＩＳ）である。
【００３７】
一実施形態は、１つのＷＱＳプロセスを組み込んでいるが、構成可能な数のＷＩＳプロセスを組み込んでいる。システムの開始時には、構成された数のＷＩＳプロセスは作業キューを共有して負荷平衡を提供する。構成された数のＷＩＳプロセスは、ラウンド・ロビン・ベースで共有するか、（可能であれば）最も重く負荷されたキューを異なるＷＩＳへ割り振ることによって共有する。
【００３８】
典型的なワークフロー管理システムにおいて、作業キューの数は、構成されたＷＩＳプロセスの数を超過する。その結果、各々のＷＩＳプロセスは、多数の作業キューを管理する必要がある。各々のＷＩＳプロセスがオペレーションを順次に処理し、それによってクライアント・アプリケーションがリクエストしたオペレーションに遅延を生じることがないように保証するため、ＷＩＳプロセスはマルチスレッドにされる。各々のＷＩＳプロセスは、実行スレッドのプールを有する。ＷＩＳプロセスがワークフロー・サービスまたはクライアント・アプリケーションによってリクエストされると、ＷＩＳプロセスはリクエストをスレッドへ割り振る。こうして、各々のＷＩＳは、多数のサービス・リクエストへ平行にサービスすることができる。ＷＩＳプロセスが多数のキューを管理しなければならないのと同じように、ＷＱＳプロセスは全てのＷＩＳプロセスにサービス可能でなければならない。そのため、ＷＱＳはマルチスレッド・テクノロジを使用して、ＷＩＳプロセスからの多数のサービス・リクエストへ平行にサービスできるようにする。
【００３９】
これらのテクノロジを使用した結果、何千というクライアントを同時にサポートすることができる。個々のサーバは、同時に実行されている多数のクライアントに責任を有するかも知れない。このようなサーバは、マルチプロセッシングおよびマルチスレッド・テクノロジを使用して、そのクライアントへ同時にサービスすることができる。
【００４０】
更に、作業項目をクライアントへ提供するために使用される方法は、クライアント・サーバのレイテンシーが最小に維持され、ネットワーク帯域幅の利用が経済的になることを意味する。
【００４１】
作業キュー・サービス１１０は、作業項目のリストをクライアントへ断片として供給する。作業キュー・サービスは、完全な作業キューを送信するのではなく、オンデマンドでクライアントへ断片を送信する。ユーザが作業キューをスクロールして作業項目を選択するユーザ・インタフェースの場合には、画面へ配置するのに十分な作業項目のみが、１つのオペレーションでダウンロードされる。作業キュー・サービスはクライアントのペースで働くので、作業キュー・サービスは最小のレイテンシーで作業項目を供給することができ、ネットワーク・インフラストラクチャに過度の負担を与えることなしに巨大なユーザ人口にサービスすることができる。
【００４２】
［ワークフロー・サービス１１２］
ワークフロー・サービス・コンポーネント１１２は、プロセス設計者がプロセス・デファイナ（アプリケーション１２４の１つの例）を使用して定義したビジネス規則の解釈に責任を有し、またビジネス規則を自動プロセスへ変える責任を有する。ワークフロー・サービスは、アーキテクチャの様々な層を介してプロセス・オブジェクト・クライアント１０４の中のアプリケーション１２４からリクエストを受け取り、指定されたワークフロー・プロセスのケースを開始するアクション、またはインスタンス（ケース）の特定のステップを完了（リリース）するアクションなどを実行する。ワークフロー・サービス・コンポーネント１１２は、プロセス定義を検査し、次に何を起こす必要があるかを決定する。例えば、ワークフロー・サービス・コンポーネントは、リリースされ／完了した前のステップの一部分として修正されたデータを更新し、新しい作業項目を作業キューへ送り出す。
【００４３】
前述したように、プロセス・デファイナは、プロセス・オブジェクト・クライアント１０４の中のアプリケーション１２４である。プロセス・デファイナのユーザは、新しいプロセスを作り出すか、修正のために既存のプロセスをオープンし、ユーザ・インタフェース・ファシリティを使用してプロセスを編集する。プロセス・エンジン１００は、プロセス・エンジン・データベースの中にプロセス定義を記憶し、ファイル・インタフェース層（ＦＩＬ）１１６を介してプロセス定義にアクセスする。
【００４４】
予報モジュール１４０は、リクエストをＦＩＬ１１６へ送ることによってプロセス定義にアクセスする。予報モジュール１４０は、後で図２を参照して説明される。
【００４５】
ワークフロー・プロセスの各々のステップ（活動）について、１つまたは複数のアクション（即ち、次に起こるもの）が存在する。アクションは、ステップＡが完了したときステップＢへ行くのように、単純なものであってよい。しかし、アクションは、次のように条件を含むことができる。
【００４６】
ローン金額＞１００００ドルであればステップＢへ行き、そうでなければステップＣへ行く。
【００４７】
アクションが条件を含むとき、ワークフロー・サービス・コンポーネントは、プロセス定義を読み取り、現在のステップのアクションが何であるかを発見し、アクションに関連づけられた条件を評価する。本発明の特定の実施形態によってサポートされる式の全ての可能なタイプを知っている式エバリュエータが存在する。式は、１つまたは複数の変数を有する方程式である。式の変数へ値を挿入し、変数の値を与えられた式が真であるかどうかを評価することができる。式エバリュエータは、適切な情報部分を取得する。与えられた例において、式エバリュエータは、ワークフロー関連データからローン金額の値を決定し、演算子が何であるかを決定し（このケースでは＞）、式エバリュエータがローン金額と比較するため何が必要か（１０，０００ドル）を決定する。式エバリュエータは真または偽の値へ評価され、この値はワークフロー・サービス・モジュールのメイン・ボディーへ返される。次にメイン・ボディーは、どのルートを下るか、したがってどのアクション（ステップＢまたはステップＣ）を取るかを決定することができる。
【００４８】
ワークフロー・サービス・コンポーネントは、作業者／当事者の作業キューまたは外部アプリケーションへ作業項目ままたは仕事を送る。ワークフロー・サービス・コンポーネントは、完了した作業項目をユーザの作業キューまたは外部アプリケーションから受け取り、データおよびプロセス定義に基づいて意思決定を行い、次の作業項目をワークフローの中のどこへ送るかを決定する。言い換えれば、ワークフロー・サービス・コンポーネント１１２は、プロセスの中のステップを介して取得されたデータを受け取り、プロセスに関連づけられたデータベースを更新する。次に、ワークフロー・サービス・コンポーネント１１２は、プロセス定義および更新されたケース・データを取得し、更新されたケース・データをプロセス定義へ適用し、プロセスのそのケースにおける次のステップを決定する。
【００４９】
［データベース層サービス１１４］
データがＲＤＢＭＳに記憶されるケースでは、データベース・サービス・コンポーネント１１４がＦＩＬ１１６へデータへのアクセスを提供する。
【００５０】
プロセス・デファイナ
図１Ｂおよび図１Ｃを参照すると、プロセス・デファイナ（ＰＤ）８２の一実施形態は、プロセスを定義するツールバー８０を含む。ドラッグ・アンド・ドロップ機能を使用し、ツールバー８２から適切な要素を選択し、選択された要素を下のパレットへドラッグすることによって、プロセスを定義することができる。ツールバーは、次の被選択要素を含む。即ち、ポインタ、コネクタ、ルータ、複合ルータ、標準ステップ、統合ステップ、外部イベント、バックグラウンド・ステップ、意思決定、待機、ストップ、コメント、サブプロセス、レポート、およびオープン・クライアントである。以下は、これらの被選択要素の説明である。例示された実施形態では、プロセスで定義可能なステップの４つのタイプが存在する。それらのタイプは、次のとおりである。
【００５１】
１．正規／標準ステップ  −  このタイプのステップは、エンドユーザ対話へ向けられ、ユーザと対話する方法を関連づけられる。このタイプのステップは多様な方法で達成され、ステップ・デファイナを使用して定義されたフォームを使用するか、市販の製品、例えば、Ｍｉｃｒｏｓｏｆｔ  Ｖｉｓｕａｌ  Ｂａｓｉｃ、ＰｏｗｅｒＳｏｆｔ  ＰｏｗｅｒＢｕｉｌｄｅｒ、ＣおよびＣ＋＋、および他の多くのものを使用して達成されることができる。正規ステップは、このようにエンドユーザ対話に重点を置くので、当然のことながらユーザの作業キューの中に現れる。しかし、正規ステップは必ずしも常にフォームを関連づけられる必要はなく、ユーザに通知するためフォームなしで使用されることができる。
【００５２】
２．統合ステップ  −  このタイプのステップは、所与のステップに関連した活動の或るものを自動化する手段として使用される。自動ステップは、ユーザの介入なしに実行される外部アプリケーションを呼び出すために使用される。例えば、統合ステップは、データベースと情報を交換するため、標準文字を印刷するため、または画像または文書管理ソフトウェアを呼び出すために使用されてよい。統合ステップの性質によって、統合ステップはユーザの作業キューの中に現れない。
【００５３】
３．イベント・ステップ  −  イベント・ステップは、或る特別の条件  −  可能性としてプロセスの外部にある  −  が起こるまで、プロセスの流れを停止するステップである。したがって、イベント・ステップは、ワークフローの中のステップを或る外部イベントと同期させるために使用されてよい。イベント・ステップは、ケースを小休止または一時停止させるため、プロセス例外を管理するため、またはステップ・データを変更するために使用されてよい。イベント・ステップは、更に、独立したワークフローを同期させるために使用されてよい。
【００５４】
４．オープン・クライアント・ステップは、本発明の実施形態と、デスクトップ・アプリケーション、例えば、マイクロソフト・エクスチェンジおよびロータス・ノーツとの統合を容易にするために使用される。オープン・クライアント・ステップは、統合ステップとイベントとの組み合わせである。オープン・クライアント・ステップを使用するとき、本発明の実施形態は作業項目を送り出さず、その代わりにパラメータを使用してアプリケーションを呼び出す。ワークフローは、ユーザ・アプリケーションが継続を命ずるまで一時停止される。言い換えれば、システムは、外部アプリケーションがレスポンスを提供するまで、ワークフロー・プロセスのインスタンス／ケースの実行を一時停止する。全体のシステムは一時停止されない。なぜなら、ワークフロー・サービスは、同一または異なったワークフロー・プロセスの他のインスタンスの処理を継続できるからである。
【００５５】
サブプロセス
本発明の実施形態は、開発者がツールボックスからサブプロセスを選択し、それらをＰＤパレットへドラッグし、それらを既存または新規のプロセスへ付加することができるようにする。
【００５６】
ユーザがサブプロセスを付加したいと思うとき、ユーザはＰＤツールバーからコンポーネント・ツールを選択する。ユーザは、選択されたツールをパレットの上にドラッグし、プロセスの中の必要な場所にドロップする。正規のステップを付加するために、同じ方法が使用される。
【００５７】
一度ドロップされると、ＰＣは、ユーザがサブプロセスの名前を指定することをリクエストする。ユーザは、更に、コントロールしているプロセスが、サブプロセスのどのステップにサブプロセスを入れるかを指定することができる。既存のプロセスは、コントロールしているプロセスへリンクされ、アイコンをダブルクリックすることによってアクセス可能である。コントロールしているプロセスは、それに付加された新しいプロセスの全ての属性を有する（フィールド、アクション、ステップ定義／フォームなど）。前述したように、アクションはワークフロー・プロセスの中のイベントである。言い換えれば、アクションは、ステップ・デファイナによってステップへ割り当てられる自動的行為であるか、ユーザ対話または外部アプリケーション入力を必要とする行為である。
【００５８】
一実施形態において、サブプロセスを含むフルプロセスは、１つの強化された追跡記録を有する。追跡記録は、ワークフローのケースの上で実行されたアクションの記録である。それは次のようなイベントを含む。
開始されたケース
ユーザＸへ送られたステップＡ
ユーザＸによってリリースされたステップＡ
完了したケース
終了したケース
トリガされたイベント
一時停止されたケース
再活性化されたケース
【００５９】
一実施形態において、全ての活動はタイムスタンプを与えられる。追跡記録は、少なくとも２つの目的に使用される。i）追跡記録はプロセスをデバッグするときの助けとなり、ii）追跡記録は実際に起こった活動の証拠を提供する。
【００６０】
サブプロセス機能の利点は、次のとおりである。
・再使用可能性  −  多数のステップおよび関連したプロセス・ロジックをサブプロセスへカプセル化することができ、このサブプロセスは同じプロセスの中または多数のプロセスにまたがって再使用可能である。
・プロセスのモジュール化  −  複合プロセスの中には、多数のステップが存在可能である。このようなプロセスが、１つのプロセスとして実現される場合、様々な困難を提起する可能性があり、このような困難の中には、全プロセスの理解、プロセスのメンテナンスおよび強化が含まれる。プロセスを多数の論理ブロックへ分割し、それらブロックの各々をサブプロセスへカプセル化して、マスター・プロセスが全体の流れをコントロールすることは、これらの困難を軽減するときの助けとなる。
・マルチユーザの開発  −  プロセスを多数の論理ブロックへ分割できるケースでは、異なったプロセス・デファイナがブロックの各々を実現およびメンテナンスすることができる。
【００６１】
他のステップ・オプション
プロセス・ステップと組み合わせて使用され、プロセス定義の豊富さを更に向上する他のメカニズムが存在する。それらのメカニズムは、次のとおりである。
【００６２】
デッドライン  −  デッドラインはタイムベース警告の設計構造である。デッドラインは、ステップに関連づけられるが、異なったタイプのステップではなくステップの属性である。本発明の実施形態によれば、期間または式を使用してデッドラインを定義することができる。期間デッドラインは、システムがデッドライン・アクションを呼び出す前に経過しなければならない時間の期間を静的に定義する。本発明の実施形態は、作業項目がユーザの作業キューに最初に現れた時点からこの期間を測定する。本発明の実施形態は、他方では、実行時にデッドラインを動的に定義するため式デッドラインを使用する。多様な日付および時間関数が存在し、本発明の実施形態はそれらの関数をケース・データへ適用して、適切なデッドライン期間を確立することができる。デッドラインが満期になると、本発明の実施形態はステップの他のシーケンスを開始し、場合によりユーザの作業キューからステップを除去することができる。後者の方法は、ステップ撤回アクションとして知られる。言い換えれば、撤回アクションは、ステップの実行デッドラインが満期になると、ユーザ／作業者の作業キューからステップを除去する。
【００６３】
ルーティング、ブランチング、条件、および平行性  −  これらの設計構造は、ワークフローのルーティング・ロジックを管理するために使用される。ルーティング・ロジックは、プロセス経路がケース・データの現行条件によってダイナミックに変更されるにつれて、コントロールが移譲されることを可能にする。言い換えれば、ケース・データを使用して評価できる条件が存在するので、同じワークフロー・プロセスの２つの異なったケース（インスタンス）が、実際には異なったルートを取ることが可能になる。同様に、特定の活動へ割り当てられる受け手（作業者）は、実行時に決定されてよい。したがって、経路および作業者の双方は、１つのケースから他のケースへと異なってよい。しかし、プロセスのレイアウトは設計時に固定される。
【００６４】
ケース・データの現行条件の結果としてプロセス経路をダイナミックに変更することは、プロセスが開始した後、プロセスが効果的にイベントへ反応できることを意味する。異なったステップから構成される平行ブランチを構成することができる。例えば、１つのケースが、複数の平行なブランチを下方へ導かれ、このようなブランチでは、ユーザへの情報提示およびプロセスの振る舞いが、各ブランチでの定義に依存して全く異なることができる。（ＯＲ）スプリットのケースでは、ケースは１つのルートまたは他のルートを下って進行する。（ＡＮＤ）スプリットのケースでは、ケースは双方の経路を平行に下って進行する。アクション／ステップ／提示は、各々の経路で非常に異なっていてよい。
【００６５】
複合ルータ  −  これは実際にはヌル・アクションであるステップのタイプであり、最小のサーバ・オーバーヘッドを有する。バックグラウンド・プロセスが複合ルータを処理するとき、複合ルータのアクションは即時に処理され、ステップは実際にはキューへ送り出されない。
【００６６】
複合ルータは、次のシナリオで有用である。
・複合アクションの収集点  −  複合アクションの同じ集合を有する幾つかのステップが存在するならば、これらのアクションは複合ルータへ割り当てられることができ、他のステップが共通の複合アクションの処理を欲するときに処理される。
・ＰＤの明確性  −  ＰＤにおけるプロセスのレイアウトは、ステップ間のリンクの重複を除去するため複合ルータを使用することによって改善される。
【００６７】
待機  −  待機はルーティング構造の特別のタイプであり、厳密にはステップのタイプではない。待機は、ワークフローにおける多数の平行ルートの同期点を実現する。待機ルーティング構造は、２つの経路、例えば、前述した２つのＡＮＤ通路を再び結合する方法である。実際に、待機は、時によってはＡＮＤ接合と呼ばれる。平行性、待機、およびイベントの組み合わせは、現実世界のシナリオを定義するメカニズムをプロセス・デファイナに与える。例えば、不完全なブランチが撤回アクションを使用して対応的に終了するワークフロー・シナリオを実現することができる。したがって、プロセス・デファイナを使用することによって、プロセス設計者はステップ間の関係を作り出すことができ、関係するステップを定義することができる。
【００６８】
図１Ｂに示されるプロセスの例を詳述すると、プロセスは、補助の申請を処理する。補助ステップは、申請人からの情報、例えば補助の目的および申請人の背景情報を取得する。プロセスは、マネージャがケースを適切なプロセッサ／作業者へ割り振る割り振りステップへ進行する。プロセスは、補助を承認するかどうかをプロセッサが決定するプロセス・ステップへ進行する。プロセッサが、指定された時間までにケースを承認しないか拒絶するならば、定義されたプロセスがマネージャに通知する。処理に続いて、多数の条件または意思決定が続く。最初の意思決定は、ケースをクローズまたはアーカイブし、停止するかどうかを決定する。プロセッサがケースをアーカイブしなければ、次の意思決定は申請を未決定にするかどうかである。ケースが未決定ルートを取れば、定義されたプロセスは、ケースの処理段階へケースを再循環させる。ケースが未決定ルートを取らなければ、次の意思決定は、交付の詳細を印刷するかどうか、および申請を未決定にするかどうかである。再び、ケースの印刷ルートが取られるならば、定義されたプロセスはケースの処理段階へケースを再循環させる。交付の印刷ルートが取られないならば、定義されたプロセスは、異なったプロセッサへケースを再び割り振る。即ち、マネージャは申請を処理する他の作業者を選択する。
【００６９】
図２を参照して、設計者がどのようにプロセスの構造およびプロセスを作り上げているステップの定義を決定するかを説明すると、本発明の一実施形態に従って作業リストを予報するシステム１４０は、予報情報受け取りモジュール１４２を含む。予報情報受け取りモジュールは、問題とするワークフローに関連する情報、例えば、呼び出すプロセスの名前およびケース参照番号を受け取る。システムは、予報情報受け取りモジュールと通信するプロセス定義受け取りモジュール１４４を含む。プロセス定義受け取りモジュールは、指定されたワークフロー・プロセスのプロセス定義を受け取る。システムは、プロセス定義受け取りモジュールと通信するステップ決定モジュール１４６を含む。ステップ決定モジュール１４６は、プロセス定義に基づいてケースのために少なくとも１つの未解決ステップを決定する。システムは、ステップ決定モジュールと通信するステップ定義受け取りモジュール１４８を含む。ステップ定義受け取りモジュール１４８は、未解決ステップの定義を受け取る。システムは、更に、ステップ定義受け取りモジュール１４８と通信する実行モジュール１５０を含む。実行モジュール１５０は未解決ステップを実行し、未解決ステップの予想される終了時間を計算する。システムは、更に、実行モジュール１５０と通信する予報条件処理モジュール１５１を含むことができる。予報条件処理モジュール１５１は、未解決ステップの一部分である条件を処理する。
【００７０】
動作において、図３を参照すると、本発明の一実施形態に従ったシステムは、１５２で、予報情報、例えば、問題とする時間間隔および問題とするケースを受け取る。予報情報に基づいて、システムは、１５４で、呼び出すプロセスの名前およびプロセスに関連づけられたケース参照番号を受け取る。次に、システムは、１５６で、指定されたプロセスのプロセス定義を受け取る。プロセス定義およびケース参照番号に基づいて、システムは、１５８で、未解決のステップを決定する。次に、システムは、１６０で、指定されたプロセスのために未解決ステップの定義を受け取り、１６２で、未解決ステップの実行をシミュレートし、ステップの各々のために予想終了時間（ＥＥＴ）を計算するため予報条件を管理する。作業項目がその時間間隔の中で期限に達すれば、システムは、１６６で、作業リストの中にその項目を含める。期限に達しなければ、システムは、１６８で、その項目を作業リストの中に含めない。次に、システムは、１６９で、問題とする１つまたは複数のパラメータに従って作業リストから項目を提供する。
【００７１】
システムは、予報機能、即ち予報モジュールを呼び出し、指定されたケースについて直接予報を得ることができる。システムは、図２で示された予報モジュール１４０によって生成された結果をリストに記憶し、他の予報機能呼び出しによって、そのリストを検索することができる。あるいは、予報モジュールはバックグラウンドで継続的に実行して、バックグラウンドがケースの上でアクションを実行するとき、常に各々のケースを予報し直すことができる。システムは、実行している予報の結果をデータ記憶装置に記憶し、次にシステムはそれを照会することができる。
【００７２】
予報プロセスは、どのルートから呼び出されようと、生またはシミュレートされたケース・データを使用して、指定されたプロセスをステップごとに通過し、条件付きアクションが存在する場合には、どのルートを取るかを決定する。各々のステップは予想持続時間を有し、予報モジュールは予想持続時間を使用して、現在のステップの処理終了時間および次のステップの処理開始時間を計算する。一度ステップが処理されると、システムは検索のために全ての重要情報を記憶する。直接呼び出しについては、この検索はリストから行われる。継続的に実行される予報によってデータ記憶装置から生成されたデータにアクセスするためには、検索はクエリーを介して行われ、本発明の実施形態はこの目的のためにクエリー・インタフェースを提供する。
【００７３】
こうして、一実施形態において、図１２を参照すると、ワークフロー・サービス／バックグラウンド・サービス１１２が各々のステップを完了するにつれて、これらのサービスは予報サービス１４０をトリガし、ワークフロー・サービス１１２によって更新されたデータに基づいて計算をやり直す。予報サービス１４０は、関連したプロセス定義１０３および関連し更新されたケース・データ１０１を取得して作業リストを生成し、次に、この作業リストは、関連したプロセス・オブジェクト１０４へ送られる。示された作業リストは、ケース番号、作業者、作業項目、および予想開始時間のフィールドを含む。これらのフィールドは、例示を目的とするだけで、限定の意味を有しない。予想終了時間のような他のフィールドを含めることができる。
【００７４】
ケース変更の通知
バックグラウンド・プロセス（ＢＧ）１１２が命令を処理した結果、ケースへの変更が生じたとき、ＢＧは予報サービス／モジュール１４０へ通知して、データベースに保持された予報データが更新され、最新データを反映できるようにする。
【００７５】
一実施形態において、ＢＧは、次の命令を処理しているときケースへの変更を行う。
・ＮＥＷＣＡＳＥ
この命令は、ワークフロー・プロセスの新しいケースを開始できるようにするためＢＧへ送られる。
・ＲＥＬＥＡＳＥ
この命令は、クライアントが未解決ステップをリリースしたときＢＧへ送られる。
・ＦＯＲＷＡＲＤ
この命令は、クライアントが１つのキューから他のキューへステップを転送したときＢＧへ送られる。
・ＥＶＥＮＴ
この命令は、「イベント」がワークフロー・プロセスのケースで発行されたときＢＧへ送られる。この命令は、ケースについてケース・データを更新するか、死んだケースを復活させるために使用できる。
・ＣＬＯＳＥ
この命令は、ケースがクローズされるとき、即ち、ケースが死んだケースになるときＢＧへ送られる。ケース・データおよび追跡記録情報は、依然としてシステムに存在し、ケースは「イベント」命令を使用することによって復活させることができる。
・ＰＵＲＧＥ
この命令は、ケースが消去されるときＢＧへ送られる。この命令は、システムから全てのケース・データおよび追跡記録情報を除去し、このことはケースを復活できないことを意味する。
【００７６】
ワークフロー・プロセスが予報のためにフラグを付けられるならば、ＢＧプロセスは、メッセージを予報キューへ入れ、変更されたケースを表示し、変更を生じたワークフロー・プロセスおよび命令を表示する。
【００７７】
ケースが開始されると、ワークフロー・プロセスが予報のためにフラグを付けられるならば、ＢＧは予報ロック・データベース・テーブルへエントリを書き込む。このエントリは、ＢＧプロセスによってケース情報テーブルへ付加された１つの行とマッチする。
【００７８】
予報キュー
一実施形態において、このキューはメッセージを保持するために使用され、これらのメッセージは、ケースへの変更を生じる命令をＢＧが処理する命令処理の一部分として生成される。
【００７９】
キューへ入れられるメッセージは、次の情報を含む。
・ケース番号
この番号は、データ／状況が変更されたケース番号である。
・リクエストＩＤ
この識別子は一意のリクエスト識別子であり、ＢＧプロセスによって送り出されたステップに関連づけられる。
・ワークフロー・プロセス番号
この番号は、ケース参照に関連づけられたワークフロー・プロセスの番号である。
・命令名
この名前は、ＢＧによって処理され、上記のケース番号によって識別されたケースに変更を生じた命令の名前である。
【００８０】
予報データの更新
ＢＧプロセスが、変更されたケースに関する情報を有するメッセージを告示したとき、予報プロセスはそのメッセージを予報キューから読み取り、ケース・データベースを更新し、ケース・データベースは最新の予報情報を含むようになる。
【００８１】
この予報プロセスは、ＢＧプロセスと同じように、多数の実行インスタンスを有することができ、そこへインスタンスを更に付加（または除去）することができる。
【００８２】
図１を参照すると、この予報プロセスは、各々の命令についてアプリケーション層１２０のインタフェースを呼び出し、ＢＧプロセスによって行われた変更から生じる予報ステップのリストをメモリの中に生成する。次に予報プロセスは、キャッシュされた予報ステップをデータベースへフラッシュし、それらの予報ステップは外部アプリケーションによって照会可能となる。
【００８３】
一実施形態において、予報キューからメッセージを出し、予報ステップを生成し、データベースを更新するプロセスは、全てトランザクションの一部分として起こる。ステップが失敗すると、トランザクションはロールバックされ、メッセージは後の処理のためにキューへ戻される。
【００８４】
２つのプロセスが同じワークフロー・プロセスおよびケース番号を同時に更新しないことを確実にするため、ケース参照エントリ（ワークフロー・プロセスおよびケース番号）の上にロックが達成される。このロックは、処理が完了し、トランザクションが完了するまで維持される。
【００８５】
データベース・テーブル
一実施形態において、２つのデータベース・テーブルがケースについて予報データを記憶する。
【００８６】
予報ロック
このテーブルは、現在、予報テーブルの中に予報を有する各々のワークフロー・プロセスおよびケース番号についてエントリを保持する。このテーブルは、予報プロセスがケース参照を処理している間、ケース参照をロックするために使用される。
【００８７】
このテーブルは、次のフォーマットを有する。
【表１】
2005527916.tif 000003
【００８８】
予報
このテーブルは、所与のワークフロー・プロセスおよびケース番号について予報データを保持する。予報ロック・テーブルには、マッチする行が存在する。このテーブルは、１つのワークフロー・プロセスおよびケース番号について複数の行を含むことができ、各々の行は予報されるステップおよび関連ファイル・データを表示する。
【００８９】
このテーブルは次のフォーマットを有する。
【表２】
2005527916.tif 000004
【００９０】
このテーブルは、ｐｒｏｃ＿ｎｕｍ、ｃａｓｅ＿ｎｕｍ、およびｆｉｅｌｄ＿ｎａｍｅの欄で一意の一次キーを有し、ｐｒｏｃ＿ｎｕｍおよびｃａｓｅ＿ｎｕｍ欄で予報ロック・テーブルへの外部キーを有する。
【００９１】
一実施形態によれば、ワークフロー管理システムが予報モジュール１４０を呼び出すとき、ワークフロー管理システムは次の情報を予報モジュール１４０へ渡す。
１．呼び出すワークフロー・プロセスの名前
２．ケース参照番号（予報モジュール１４０が、アクティブのケースについて、ケースのデータを抽出する必要があれば）
３．ステップまたは処理を開始するステップ
４．フィールドおよび値の配列  −  生のケースで予報しているとき既存のケースから取られたもの、またはシミュレーションのために手作業で引き出されたもの。このデータは、条件を評価するときに使用される。
【００９２】
他の実施形態において、予報モジュール１４０は、生のケースから予報するならば、この情報のサブセット、即ち、項目１および項目２を必要とする。生のケースでは、システムは、指定されたプロセスのプロセス定義を検索し、ケース参照番号を使用してケースの全ての未解決ステップを突き止める。システムは、更に、プロセスについて生のケース・データを検索する。システムは、これらの未解決ステップの定義をプロセスから検索し、定義へ参照を未解決ステップ・リスト（ＯＳＬ）の上に置く。ＯＳＬは、実行を待機しているステップのリストである。次にシステムは、ＯＳＬ上でステップをループして、それらのステップを実行する。
【００９３】
システムがステップを実行するとき、システムは初期スクリプトおよびリリース・スクリプトを実行し、個々のステップ持続時間（ＳＤ）からステップの予想終了時間（ＥＥＴ）を計算する。コンピュータ・プログラミングにおいて、スクリプトとは、（コンパイルされたプログラムのように）コンピュータ・プロセッサによってではなく、他のプログラムによって解釈または実行される命令のプログラムまたはシーケンスである。初期スクリプトとは、ユーザ／アプリケーションが最初に作業キューから作業項目をオープンするとき、アプリケーションが呼び出すスクリプトである。リリース・スクリプトとは、ユーザ／アプリケーションが作業項目を完了したとき、しかし完了／リリースをワークフロー・サービスが通知される前に、アプリケーションが呼び出すスクリプトである。
【００９４】
ＳＤは、ステップがキューに到着してから、キューからリリースされるまでのプロセスに、ステップが取る予想時間として設計時に設定された時間である。ＥＥＴは、ワークフロー管理システムがステップをリリースする日付および時間としてシステムが予想する将来の日付および時間である。システムは、ステップのアクションを評価し、結果として更に多くのステップをＯＳＬ上に置くかも知れない。ステップの実行が完了したとき、システムはステップに関する重要な情報、例えば開始時間および予想終了時間を、データ記憶装置に保存する。
【００９５】
ケースの予報は、デッドラインの処理、および適切であれば撤回アクションの処理を含む。
【００９６】
予報モジュール１４０は、データ記憶装置にアクセスして将来の作業項目に関するデータを検索させるクエリー・インタフェースを提供する。一実施形態において、このインタフェースはソート能力を提供する。
【００９７】
図１および図１１を参照すると、本発明の特徴を実現することのできる例示的クライアント１０４、１０２、またはサーバ１００を表すシステム３００は、システムのコンポーネント間で情報を伝えるためのバスまたは他の通信手段３０２を含む。システム３００は、更に、バス３０２に結合されたプロセッサ３０４、および同じくバスに結合されたメイン・メモリ、例えばランダム・アクセス・メモリ（ＲＡＭ）または他のダイナミック記憶装置３０６を含む。ＲＡＭはプロセッサ３０４によって実行される命令を記憶する。メイン・メモリは、更に、一時変数を記憶することができる。システム３００は、ＲＡＭに記憶された情報のように定期的にアクセスされない情報を記憶するため、バス３０２に結合された大容量記憶装置３１６を含むことができる。
【００９８】
システム３００は、作業リストのような情報をユーザへ表示するディスプレイ３０８を含むことができる。システムは、ユーザに意思決定を入力させる入力デバイス、例えばカーソル制御デバイス３１２およびキーボード３１０を含むことができる。意思決定の効果は、作業リストの表示を含むことができる。
【００９９】
システム３００は、更に、通信デバイス３１４を含むことができる。システム３００が本発明の一実施形態の一部分を実現しているのであれば、通信デバイス３１４によって、システムはシステムの他の部分およびクライアント５６と通信することができる。あるいは、システム３００がユーザのパーソナル・コンピュータまたはパーソナル・ディジタル・アシスタントの上でシステムを実現しているのであれば、通信デバイス３１４は、ネットワーク・カード、ＲＦトランシーバ、またはネットワークへ結合するための他の周知の通信デバイスを含むことができる。
【０１００】
予報モジュール１４０
以下で、どのようにして予報モジュール１４０の実施形態をプロセス・デファイナ（ＰＤ）の中にセットアップするか、どのようにしてそれを呼び出すか、それが呼び出されたとき何が起こるか、どのようにしてその結果へアクセスするか、どのようにしてそれをメンテナンスするかを説明する。
【０１０１】
サーバの設定が存在し、予報モジュール１４０を構成するダイアログボックスがＰＤの中に存在する。
【０１０２】
予報モジュール１４０は、次の場合に呼び出される。
１．例えば、作業項目がキューへディスパッチされたり、ケースが開始したりして、ケースに影響を及ぼす活動をバックグラウンドが実行したためトリガが発行されるとき。
２．プロセス・オブジェクト（ＰＯ）１０４が、予報モジュールへの直接呼び出しを行うとき。
【０１０３】
予報モジュール１４０が呼び出されたとき、予報モジュール１４０は、与えられた情報を使用して、将来のステップが処理される日付および時間を予報する。一実施形態において、予報モジュール１４０は、上記のオプション１を介して開始したときには、この情報をデータ記憶装置に記憶し、オプション２によって開始したときにはリストの中に記憶する。
【０１０４】
結果は、
１．結果がバックグラウンド・プロセスから来れば、クエリー・インタフェースから利用可能となる。
２．直接呼び出しが行われたのであれば、リストから利用可能となる。
【０１０５】
データ記憶装置に影響を及ぼす２つのメンテナンス活動が存在する。
１．復元およびケースの再開始が起こるとき、データ記憶装置へロードする。ケースが自然に完了する前に、ケースを（外部的に）クローズすることができる。この例では、本発明に従ったシステムの一実施形態は、ケースを復活および再開始することができる。同様に、システムはケースに関連した全ての情報をバックアップすることができ、ケースのオンライン・バージョンをシステムから消去することができる。後の或る日付で、システムは、前のバックアップからケースについて情報を復元し、したがって、必要であれば、ケースを復活させることができる。
２．ケースがクローズされるか消去されるとき、データ記憶装置からデータを削除する。
【０１０６】
予報機能を使用するためのセットアップ
セットアップは２つの部分に分割される。
１．サーバのセットアップ
２．プロセスのセットアップ
【０１０７】
一実施形態において、このセットアップ要件は、バックグラウンド・プロセスとして働いている予報機能にのみ適用される。
【０１０８】
サーバのセットアップ
一実施形態において、予報を動作可能にするか不能にするサーバの設定が存在する。この設定は、この機能の使用を望むか望まないかをユーザに選択させる。この実施形態において、更に、サーバで許容されるループ数を制限するＭＡＸＬＯＯＰＳ変数が存在する。これは構成可能であるが、デフォルト値は高い値である。
【０１０９】
一実施形態によれば、プリセットされた限界を超えて降下するサブプロセス呼び出しを防止するＭＡＸＳＵＢＰＲＯＣＥＳＳＤＥＰＴＨ変数が存在する。この変数の使用は、サブプロセスが再帰的に呼び出される（可能性として、誤っている）場合の助けとなる。ＭＡＸＬＯＯＰＳを維持するとき、ＭＡＸＳＵＢＰＲＯＣＥＳＳＤＥＰＴＨは構成可能であるが、デフォルト値は大数である（例えば、１００）。
【０１１０】
一実施形態において、１つのノードを表す各々のサーバは、それ自身の設定を有することができる。
【０１１１】
プロセスのセットアップ
一実施形態において、予報機能を動作可能にするＰＤへの追加事項が幾つか存在する。これらの追加事項は、プロセスの状況、作業ステップ、および条件に影響を与える。
【０１１２】
プロセスの状況
図５を参照すると、一実施形態において、プロセス状況ダイアログの中に、プロセスの予報を動作可能または不能にする追加フラグが存在する。このフラグは、同じサーバの上でプロセスに予報を実行させるか実行させない柔軟性をユーザに与える。
【０１１３】
一実施形態において、サブプロセスは、それが予報に含められるかどうかを示す予報フラグを有する。
【０１１４】
持続時間ボタンは、持続する期間を入れることのできるダイアログボックスを提供する。一実施形態において、上記のようなサブプロセス状況で持続時間を入力したならば、サブプロセス・ステップでの設定によってそれを無効にすることはできない。
【０１１５】
プロセスの作業ステップ
図６を参照すると、各々の作業ステップは、ステップ持続時間を追加することのできる新しいダイアログボックスを有する。このダイアログボックスは、デッドライン／持続時間ボタンからアクセスすることができる。
【０１１６】
図７を参照すると、デッドライン／ステップ持続時間定義ダイアログボックスは、ステップ持続時間およびデッドライン・タブを含む。ステップ持続時間およびデッドラインの時間は、それぞれステップ持続時間およびデッドライン・タブをクリックすることによって、独立して入力することができる。
【０１１７】
チェックボックスによって、予報計算は、ステップ持続時間を使用することができるが、将来の作業項目を出力から除外する。このチェックボックスは、「仲介業者タイプ」のステップおよび企業アプリケーション統合（ＥＡＩ）ステップ、即ち非手作業ステップを除外して、手作業で処理される作業項目のみを出力に含ませるので有用である。
【０１１８】
図８を参照すると、式を使用してステップ持続時間を入力することができる。
【０１１９】
一実施形態において、デッドラインを入力し、ステップ持続時間が同じである必要があれば、デッドラインの日付および時間が持続時間を決定することをチェックボックスが指示する。
【０１２０】
図９を参照すると、ユーザが「持続時間タブ」を選択し、更に「ステップ持続時間にデッドラインを使用」を選択すると、フォーム／ダイアログボックスの持続時間タブは、デッドラインの式または期間の設定が不能にされることを示し、したがってユーザは、デッドライン指定の内容を見ることができるが、それらのデッドライン指定は、デッドライン・タブからのみ編集することができる。
【０１２１】
プロセスの条件付きアクション
図１０を参照すると、条件付きアクション機能は、予報条件を含むように拡張される。予報条件を評価するか、予報条件を真または偽のデフォルト値にするかを選択することができる。
【０１２２】
「評価」を選択すると、予報モジュール１４０は、条件を評価して、取るべきルートを条件から決定する。同様に、真または偽を選択すると、予報モジュール１４０は、条件を真または偽のデフォルト値にして、取るべきルートを条件から決定する。
【０１２３】
予報の呼び出し
バックグラウンドから開始されたトリガは、予報を呼び出すことができる。例えば、バックグラウンドが作業をキューへディスパッチするか、新しいケースを開始して、バックグラウンドがケースに影響を与える活動を実行したとき、バックグラウンドはトリガを開始することができる。あるいは、ＰＯは、予報モジュール１４０を直接呼び出すことができる。これらの方法は、相互から独立に働く。
【０１２４】
予報モジュール１４０がケース・データのコピーを取って、条件付き計算またはスクリプトで使用するならば、システムは、ケース・データのコピーに結果を記憶し、生のケース・データに影響を与えない。
【０１２５】
バックグラウンドからトリガを生成する
バックグラウンドが、ケースに影響を及ぼす活動を実行するとき、動作可能にされた予報を有するプロセスに作業項目が属するならば、バックグラウンドは更に予報モジュール１４０をトリガする。バックグラウンドはケース参照を予報モジュール１４０へ渡し、予報モジュール１４０はケース参照を使用して、ケースについて全ての未解決ステップを突き止め、ケース・データを検索する。必要とする全ての情報を取得すると、予報モジュール１４０はプロセスを実行し、将来の作業項目および関連データを出力のために生成する。
【０１２６】
この方法は、予報モジュールによって生成された将来の作業項目が最新であり、質問に対して使用できることを意味する。
【０１２７】
ＰＯから直接に
ケース・オブジェクトからのＰＯ呼び出しは、生のケースのケース参照をアーギュメントとして渡す。（場合により、予報がシミュレーションのために使用されていれば、ステップのリストおよびデータ項目の配列も渡すことができる。）次に、予報はプロセス定義およびケース・データを突き止め、将来の作業項目および関連データを出力のために生成する。
【０１２８】
この方法は、リクエストによる予報のために将来の作業項目を生成する。
【０１２９】
予報はどのようにして将来の作業項目を生成するか
図４は例示的プロセスを提供する。以下は、予報モジュールが、異なったステップ・タイプおよびサブプロセスをどのように処理し、デフォルトの条件を使用するかに関する情報を提供する。
【０１３０】
例示的計算
図４で詳細に示される例示的プロセスは、予報モジュール（ＰＭ）によって使用されるロジックおよびデータを示す。ＰＭは、処理されるのを待機しているステップを未解決ステップ・リスト（ＯＳＬ）の上に置く。ＰＭがステップを処理するとき、ＰＭはステップをデータ記憶装置の中に置く。
【０１３１】
図４は多数のステップ、即ち、ステップＡ〜ＮおよびＰを示し、各々のステップは、ステップ・ラベルのすぐ下のボックスで示されるように、定義されたステップ持続時間（ＳＤ）、例えば１、２、３、または４時間を有する。計算を容易にするため、図４では１つの時間単位、例えば、時間を使用する。言い換えれば、ボックスの中の数字は、関連づけられているステップの持続時間である。例示された例において、ボックスの中の数字は、関連したステップの持続時間を時間で表す。ステップは、プロセスがたどることのできる経路を定義する線によって接続される。
【０１３２】
更に具体的には、１時間の持続時間を有するステップＡは、それぞれ２、１、４、および１時間の持続時間を有するステップＢ、Ｃ、Ｄ、およびＦへ平行経路を介して接続される。ステップＣは、２時間の持続時間を有するステップＥへ接続される。ステップＢ、Ｅ、およびＤの各々は、２時間の持続時間を有するステップＧへ接続され、ステップＧは３時間の持続時間を有するステップＨへ接続される。ステップＨは、それぞれ３、４、および１時間を有するステップＩ、Ｊ、およびＫへ平行経路を介して接続される。ステップＫは、８時間の持続時間を有するステップＬへ接続される。ステップＩ、Ｊ、およびＬの各々は、１時間の持続時間を有するステップＭへ接続される。ステップＭは、前述した待機構成へ接続される。ステップＦは、２時間の持続時間を有するステップＮへ接続される。ステップＮは、ステップＭが接続された同じ待機構成へ接続される。最後に、待機構成は、３時間の持続時間を有するステップＰへ接続される。下記のロジックは、ＰＭがどのようにステップ持続時間の各々を加算して、プロセスの中の各々のステップについて予想終了時間（ＥＥＴ）を計算できるかを示す。
【０１３３】
ＰＭが新しいステップをＯＳＬの上に置くとき、ＰＭは新しいステップを実行順序で挿入する。ＰＭは、次の規則に従って実行順序を決定する。
【０１３４】
ＯＳＬの中にステップが存在しなければ、ＰＭはステップをＯＳＬへ付加する。ＯＳＬに１つのステップが存在すれば、ＰＭは最初のステップを実行中であるから、ＰＭはステップをＯＳＬの終わりに付加する。リストの中に２つ以上のステップが存在すれば、ＰＭは２番目のステップで開始し、各々のステップを順番に検査しながらリストを移動する。
【０１３５】
ＰＭがリストを移動するとき、ＰＭは、挿入されるステップの開始時間と、検査されているＯＳＬのステップとを比較する。挿入されるステップの開始時間が、選択／検査されたＯＳＬステップよりも大きければ、ＰＭは、ＯＳＬの中の次のステップへ移動する。選択／検査されるＯＳＬステップが、リストの中の最後のステップであれば、ＰＭは、挿入されるステップをリストの最後に付加する。挿入されるステップの開始時間が、選択／検査されるＯＳＬステップよりも小さければ、ＰＭは、挿入されるステップを、選択／検査されるＯＳＬステップの前に付加する。
【０１３６】
挿入されるステップの開始時間がＯＳＬステップと等しければ、ＰＭは、挿入されるステップの終了時間と、選択／検査されるＯＳＬステップとを比較する。挿入されるステップの終了時間が、選択／検査されるＯＳＬステップよりも大きければ、ＰＭは、ＯＳＬの中の次の項目へ移動する。選択／検査されるＯＳＬステップが、リストの中の最後のステップであれば、ＰＭは、挿入されるステップをリストの最後に付加する。挿入されるステップの終了時間が、選択／検査されるＯＳＬステップよりも小さければ、ＰＭは、選択／検査されるＯＳＬステップの前にステップを挿入する。挿入されるステップの終了時間が、選択／検査されるＯＳＬステップと等しければ、ＰＭは、挿入されるステップを、選択／検査されるＯＳＬステップの後に付加する。
【０１３７】
システムが既に実行したステップは、ＰＭが新しいステップを付加するとき現在の順序に止まる。これらのステップは、システムが実行した待機前のステップであって、待機を越える進行が、先ず実行される他のステップに依存するので、除去されることができないステップであるかも知れない。
【０１３８】
付加される重複ステップ、即ち、ステップの第２のインスタンスの開始時間が、タイム・フレームの中で、既にＯＳＬの上に存在するステップの最初のインスタンスの開始時間と終了時間との間で起こるならば、重複したステップが除去されてよい。
【０１３９】
前述したように、実行順序はＯＳＬの順序である。
【０１４０】
本発明の一実施形態に従ったシステムが、図４のプロセスについてケースを処理するとき、ＰＭはステップＡをＯＳＬの上に置き、予報は説明したばかりの規則に従って将来の作業項目の全てを計算する。図４は、ステップＡ〜ＮおよびＰを示し、幾つかの平行経路および待機構成を含む。
【０１４１】
図４で示された例において、ステップＡが午前９時に開始したと仮定すれば、前述したプロセスが完了したとき、実行結果のステップ・リストは次のようになる（次の実行ステップ・リストを生成する計算は提供されていないが、前述したプロセスを、図４で示される例に直接適用して得られる。）
【０１４２】
【表３】
2005527916.tif 000005
デフォルトのルート条件を使用する
【０１４３】
図２および図１０を参照すると、条件付きアクション・ボックスの中のラジオボタンは、条件の後に取るルートを予報モジュールがどのように決定するかに関して、３つのオプションをユーザに提供する。
１．評価
２．真
３．偽
【０１４４】
評価ラジオボタンを選択すると、予報モジュール１４０は条件を評価してルートを決定するように命令される。デフォルトの条件が真であれば、これが取られるルートであり、デフォルトの条件が偽であるときも同様である。ユーザが評価オプションを選択すると、ユーザは、更に、図１０の条件付きアクション・ボックスの中で、式フィールドに条件式を供給する。条件式は、プロセスのために定義されたデータ・フィールドを参照するブール式であってよい。更に具体的には、ステップを定義する時点で、設計者はプロセスのためにデータ・フィールドを定義することができ、条件式はそのデータ・フィールドを参照することができる。
【０１４５】
更に一般的には、予報モジュールがケースのために呼び出されるとき、予報モジュールはその時点で最新のケース・データを収集する。このケース・データは、後続の条件計算で使用される。真または偽の結果を有する条件付きアクションは、評価されるべき条件を入れる条件ボックスおよび予報に関する３つの定義オプション、即ち、評価、真、または偽を有する。プロセス開発者は、予報が条件を処理する方法を予報に指示するため、１つのオプションを選択しなければならない。評価が選択されると、予報はそのケース・データを使用して条件ボックスの中の条件を評価し、真または偽の結果は、予報がどのルートを取るかを命令する。真または偽が設定されると、条件は無視され、予報は真または偽のルートを取る。
【０１４６】
どの順序で経路が予報されるかについての保証はなく、したがって、予報されるフィールド値が２つ以上の平行経路に沿って変更されると、予報されるフィールド値がどうなるかの保証はない。
【０１４７】
ケースのモデル化
本発明の実施形態によれば、ケースのモデル化に予報モジュール１４０を使用することができる。特定のルートを取ることについて、百分率の確率を指定することができる。システムは、ステップの予想処理時間と組み合わせて個々のルートの百分率確率を使用し、プロセスを通る各々の全ルートについて百分率の確率および予想時間を計算することができる。
【０１４８】
異なったステップ・タイプが一実施形態で処理される方法
一実施形態において、予報モジュールは、次のステップ・タイプを処理する。
・標準作業ステップ
・イベント
・サブプロセス
・企業アプリケーション統合（ＥＡＩ）ステップ
【０１４９】
予報モジュールは、プロセス・デファイナ・マップによって命令されるように、サブプロセス・ルートをたどってメイン・プロセスへ戻る。
【０１５０】
以下は、本発明に従ったシステムの一実施形態がステップを実行するとき、それがどのように各々のステップ・タイプを管理するかを説明する。
【０１５１】
システムは、標準作業ステップの初期スクリプトおよびリリース・スクリプトを実行し、ステップ持続時間を読み取り、ステップの開始時間および終了時間を計算する。
【０１５２】
次のような異なった理由によって、プロセスの中にイベント・ステップを含めることができる。
１．イベント・ステップのデッドライン特徴を使用して、所定時間の間ケースを小休止するため。
２．ステップを再開始する外部イベント・トリガを予想して、ケースを一時停止するため。
３．メイン・ブランチから独立して、プロセスのブランチを開始するため。
４．スタンドアロン・イベントに、その場限りでケース・データをケースへ付加させるため。
【０１５３】
予報モジュールが、項目１のようなイベントを発見するとき、デッドライン・アクションの処理は、ＯＳＬの上に置かれるステップを決定する。この場合、ＳＤはデッドラインの日付および時間に従う。
【０１５４】
シミュレーションにおいて、項目２で概説されたタイプのイベント・ステップから引き出されたＥＥＴは、関連した外部イベントのシミュレートされた時間に依存する。
【０１５５】
項目３および４は、予報モジュールには分からない。なぜなら、予報モジュールは、イベント・ステップ、および項目３の場合には後続ステップを、ＯＳＬの上に置かないからである。実際の、即ちシミュレートされない場合には、システムは外部インタフェースを介してこれらのステップを活性化する。
【０１５６】
システムはＥＡＩステップのＳＤを読み取り、そのステップまでを含めてＥＥＴを計算する。
【０１５７】
一実施形態において、システムがサブプロセスのステップを予報するならば、システムは、サブプロセス・ステップ自身を将来の作業項目として出力の中に含めない。しかし、システムがサブプロセス・ステップを予報していないならば、システムはサブプロセス・ステップを将来の作業項目として含める。
【０１５８】
結果の検索
本発明の実施形態において、データ記憶装置から結果を検索するクエリー・インタフェースが存在し、このクエリー・インタフェースはＰＯの中でリストを形成する。このリストによって、システムは結果をブロックで返すことができるが、一実施形態において、リスト上でソーティングおよびフィルタリングを直接行うことはできない。システムは、リストを生成したクエリーにソート・ファシリティを提供することができる。直接呼び出しは自動的にリストを形成する。
【０１５９】
ＰＯインタフェースから返された結果は、将来の作業項目を含む。前述したリストの中の各々の項目は、次の情報を含むことができる。
【表４】
2005527916.tif 000006
【０１６０】
各々のデータ・フィールドは、偽のデフォルト値を有する予報属性を有することができる。予報属性が１つまたは複数のデータ・フィールドのために真へ設定され、それらのデータ・フィールドが所与の受け手（作業者）のために作業キューに関連づけられるならば、将来の作業項目がその受け手を含むとき、常に、将来の作業項目の情報はそれらのデータ・フィールドを含む。
【０１６１】
一実施形態において、上記のフィールドの全ては、次の事項と組み合わせてクエリーの中で使用可能である。
−  比較演算子「＝」
−  論理演算子「ＡＮＤ」
−  等価チェックの一部分としてのワイルドカード文字「＊」および「？」の使用
−  付加演算子「＞＝」、「＜＝」、「？」、および「＜＞」の使用
−  論理演算子「ＯＲ」
−  オペランド間の正規の式演算子「？」の使用
【０１６２】
クエリーの例は、次のとおりである。
ａ）１０６７８３のＩＤを有する患者について、次の８時間以内に完了しなければならない全ての将来の仕事を見つけよ。
患者のＩＤは、ＰＡＴＩＥＮＴ＿ＩＤと呼ばれるデータ・フィールドに記憶されていると仮定する。問題とする日付および時間の限度は、現在の日付および時間に８時間を加え、必要ならば日付を増分することによって計算される。システムが、この計算の結果を終了日付および終了時間に記憶するならば、クエリーは次のようになる。
ＰＡＴＩＥＮＴ＿ＩＤ＝“１０６７８３”および離脱日付＜＝終了日付および離脱時間＜＝終了時間
【０１６３】
データ記憶装置のロード
本発明の実施形態において、ロード機能には３つの粒度レベルが存在する。
１．予報を動作可能にして、全てのプロセスについて全てのケースを予報する
２．予報が動作可能にされていれば、定義されたプロセスについて全てのケースを予報する
３．予報が或るプロセスについて動作可能にされていれば、そのプロセスについて１つのケースを予報する
【０１６４】
管理者がシステムの復元をリクエストすると、プレロード機能がサーバ上の全てのプロセスをループし、プロセス・デファイナがプロセスのために予報フラグを動作可能にしたかどうかをチェックする。システムが立ち上げられ、システムが予報モジュールと結合したとき、現存するケースについて生成された予報データは存在しない。作業項目がリリースされるか、新しいケースが開始したときにのみ、予報データが生成される。したがって、一実施形態において、システムはスタートアップ時にプレロード・ファシリティを使用して、全ての現存するケースについて予報データを生成する。システムがスタートアップするとき、システムはどのようなケースが現存するかを決定し、各々のケースについて予報が起こるようにする。プロセス・デファイナが予報フラグを動作可能にしたならば、プレロード機能は、プロセスについて全てのアクティブ・ケースをループし、各々のケースについて全ての将来の作業項目を予報し、結果をデータ記憶装置の中へロードする。要求者がプロセスの復元をリクエストすれば、プレロード機能は問題とするプロセスのケースだけを予報する。クローズされたケースを再開始する場合、プレロード機能は１つのケースをプレロードする。
【０１６５】
本発明の実施形態は、ユーザに次ぎのことを行わせることによって、現実または想像上のケースの予想結果を決定する。
・生のケース・データを使用し、未解決ステップの結果を予測することによって、アクティブ・ケースのプロセス経路および持続時間を予報する。
・予報を動作可能にされた全てのワークフロー・プロセスにまたがる全てのアクティブ・ケースについて、未解決ステップの結果を予報する。
・開始ステップおよびテスト・データの特定の集合を有する想像上のケースの処理をシミュレートする。
【０１６６】
当業者は本発明への多数の修正を認識するであろうが、全てのこのような修正は、クレイムのみによって限定されるものとして、本発明の範囲の中にある。
【図面の簡単な説明】
【０１６７】
【図１】プロセス管理システムのソフトウェア・アーキテクチャの１つのバージョンを示す。
【図１Ｂ】図１のシステムと一緒に使用されるプロセス・デファイナのスクリーンショットを示す。
【図１Ｃ】図１Ｂのプロセス・デファイナのツールバーに含まれるボタンを示す。
【図２】一実施形態では図１のアーキテクチャで使用できる本発明に従った作業リスト予報モジュールのブロック図である。
【図３】本発明に従った方法の一実施形態を示すフローチャートであって、上記方法は図２の作業リスト予報モジュールによって実行可能である。
【図４】プロセスについてプロセス定義の一例を示す線図であって、所与のケースについてプロセスに残っている未解決ステップのみを含む線図である。
【図５】ユーザと図１のシステムとの対話を可能にするプロセス状況ダイアログボックスを示す。
【図６】ユーザと図１のシステムとの対話を可能にするステップ定義ダイアログボックスを示す。
【図７】図６のステップ定義ダイアログボックスからアクセス可能で、ステップ持続時間の期間ラジオボタンを選択されたステップ持続時間ダイアログボックスを示す。
【図８】図６のステップ定義ダイアログボックスからアクセス可能で、式ラジオボタンを選択されたステップ持続時間ダイアログボックスを示す。
【図９】ユーザと図１のシステムとの対話を可能にするステップ・デッドライン・ダイアログボックスを示す。
【図１０】条件定義ダイアログボックスを示す。
【図１１】本発明の一実施形態を実現するコンピュータ・システムを示すブロック図である。
【図１２】図２の予報モジュールによる作業リストの生成を示すブロック図である。
【図１】
2005527916.tif 000007
【図１Ｂ】
2005527916.tif 000008
【図１Ｃ】
2005527916.tif 000009
【図２】
2005527916.tif 000010
【図３】
2005527916.tif 000011
【図４】
2005527916.tif 000012
【図５】
2005527916.tif 000013
【図６】
2005527916.tif 000014
【図７】
2005527916.tif 000015
【図８】
2005527916.tif 000016
【図９】
2005527916.tif 000017
【図１０】
2005527916.tif 000018
【図１１】
2005527916.tif 000019
【図１２】
2005527916.tif 000020
【国際調査報告】
2005527916.tif 000021
2005527916.tif 000022
2005527916.tif 000023