JP5375627B2 - 計算機システム、ワークフロー制御方法及びワークフロー制御プログラム - Google Patents

Description

本発明は、計算機システムに関し、特に、所定の順番で実行されるよう定義された複数のノードの処理順番を変更する計算機システムに関する。

ビジネスプロセスの全体又は一部をワークフローとして定義し、これをコンピュータ上で管理することによって、効率的な業務の遂行を可能とするワークフローシステムが提案されている。

このようなワークフローシステムの適用例として、企業内の発注業務システムや旅費精算業務システム等がある。これらのシステムでは、まず申請者が電子化された帳票に必要事項を入力して申請する。そうすると、予め定義されたワークフロー上に、申請された案件が投入される。その後、ワークフローを構成する各ノードの処理者（課長や部長等）がシステム上でこの案件を順次承認することによって、業務プロセスが進む。

このように、紙帳票に承認印が順次付与される業務プロセスがシステム化されることによって、業務プロセス全体の処理時間を短縮することができる。また、書類、伝票等の紙帳票が電子化されることによって、紙帳票の紛失等を防ぐことができる。さらには、予め定義されたワークフローに従って業務プロセスが遂行されることによって、企業のルールに従って正しく遂行されていることを保証できる。

従来のワークフローシステムでは、複数のノードの処理が所定の順番で逐次実行されるワークフロー定義と、複数のノードの処理が並列に実行可能であるワークフロー定義と、がある。また、原則的には前者のワークフロー定義のように複数のノードの処理が所定の順番で逐次実行されるが、未実行のノードの処理を先行作業として予め定義しておき、所定の条件を満たしたときにこれを先行して開始させるものがある（特許文献１参照）。特許文献１の技術によれば、並列処理を実現するとともに、業務プロセス全体の処理時間の短縮化及び効率化を実現することができる。

特開２００１−１０１３１０号公報

ところで、特許文献１に開示された技術では、所定の条件を満たした時点で先行作業として定義されたノードの処理は即座に開始する。そのため、一旦先行作業が開始した後に元の作業が却下又は差戻しされた場合、先行して開始した先行作業が無駄になる又は再実行の必要が生じるリスクがあった。しかしながら、特許文献１に開示された技術では、このような点について考慮されていなかった。

また、特許文献１に開示された技術では、先行作業を開始するための条件をワークフロー作成時に予め定義するという観点から、どういうケースで作業を先行して開始できるかについて予め明確に定義可能な業務プロセスについてのみ適用できる。そのため、業務プロセスの運用状況に応じて先行作業を先行開始するか否かを判断したい場合に、予めこれを条件として定義するのは困難であった。さらに、業務プロセスの運用状況に応じて条件を変更するのは、ワークフローの作成者にとって負担であった。

本発明は、上述した問題を考慮したものであって、先行開始した作業が無駄になる又は再実行の必要が生じるリスクを抑えつつ、業務プロセス全体の処理時間の短縮化及び効率化を実現する計算機システム、ワークフロー制御方法及びワークフロー制御プログラムを提供することを目的とする。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、複数のノードの処理が所定の順番で実行されるよう定義されたワークフロー定義に従って業務プロセスを遂行するワークフローサービスを提供するサーバ装置と、前記サーバ装置とネットワークを介して接続され、前記サーバ装置から前記ワークフローサービスの提供を受けるクライアント装置と、を備えた計算機システムであって、前記サーバ装置、前記クライアント装置の各々は、プログラムを実行するプロセッサと、前記プロセッサによって実行されるプログラムを格納するメモリと、を備え、前記サーバ装置は、前記複数のノードのうちの所定のノードを、前記クライアント装置において現に処理が実施されたノードと前記所定のノードとの間に存在するノードに対して、先行して処理を開始可能な先行作業ノードとして定義する先行作業定義情報と、前記業務プロセスが、所定の入力値に対して承認又は却下が実施されるものである場合、前記現に処理が実施されたノードから、前記先行作業ノードへの遷移率を、前記現に処理が実施されたノードと前記先行作業ノードとの間に存在するノードにおいて、過去に承認されたときの承認平均値、却下されたときの却下平均値を用いて算出し、算出された前記遷移率に基づいて、前記先行作業ノードの処理を先行して開始するか否かを判定する先行作業管理部と、前記先行作業ノードの処理を先行して開始すると判定された場合、前記先行作業ノードの処理を先行して開始することによって、前記ワークフロー定義に定義されたノードの処理順番を動的に変更するフロー構成変更部と、前記変更されたノードの処理順番に従って、前記業務プロセスを遂行する案件処理部と、を備えることを特徴とする。

本発明によれば、先行作業ノードを開始するタイミングを適切に判定したうえで先行開始している。そのため、ワークフロー上を流れる案件が完了するまでの全体時間を短縮することができる。また、現に処理が実施されたノードから先行作業ノードの処理に到達するまでの遷移率に着目し、履歴情報を利用して先行作業ノードを開始している。そのため、同じ業務であっても運用状況に応じて適切なタイミングで先行作業を開始することができる。

ワークフローシステムの全体構成図である。 ワークフローシステムによるワークフロー制御方法の概要を示す第１の図である。 ワークフローシステムの一例である備品発注システムのフロー遷移図である。 フロー定義テーブルの一例を示す図である。 申請者が備品を発注するための帳票画面例を示す図である。 発注申請者が発注を申請するための帳票画面例を示す図である。 帳票定義テーブルの一例を示す図である。 先行作業定義テーブルの一例を示す図である。 案件処理部の第１の制御ロジックを示すフローチャートである。 案件管理テーブルの一例を示す図である。 帳票データテーブルの一例を示す図である。 先行作業管理部の制御ロジックを示すフローチャートである。 先行開始判定部の制御ロジックを示すフローチャートである。 履歴データテーブルの一例を示す図である。 フロー構成変更部の制御ロジックを示すフローチャートである。 先行作業管理テーブルの一例を示す図である。 構成変更されたフロー遷移の説明図である。 履歴データテーブルの一例を示す図である。 発注申請者が案件一覧を閲覧するための案件一覧画面例を示す図である。 先行作業の詳細情報画面例を示す図である。 案件処理部の第２の制御ロジックを示すフローチャートである。 案件処理部の第３の制御ロジックを示すフローチャートである。 案件処理部の第４の制御ロジックを示すフローチャートである。 ワークフローシステムによるワークフロー制御方法の概要を示す第２の図である。

以下、本発明の実施の形態について図面に基づいて説明する。

図２は、ワークフローシステムによるワークフロー制御方法の概要を示す第１の図である。図２（ａ）は、本実施形態のワークフロー制御方法を適用する前のノード１、ノード２、ノード３の処理が順番に実行されるフロー遷移を示す。

遷移率Ｘは、ノード１の処理が正常に完了してノード２の処理に遷移する確率の値（0.0から1.0の間）である。閾値ｍは、ノード２の処理をノード１の処理に先行して開始するための遷移率Ｘの閾値（0.0から1.0の間）である。遷移率Ｘの値が閾値ｍよりも大きいことは、ノード２の処理をノード１の処理に先行して開始可能であることを意味する。一方、遷移率Ｘの値が閾値ｍよりも小さいことは、ノード２の処理をノード１の処理に先行して開始不能であることを意味する。同様に、遷移率Ｙは、ノード２の処理が正常に完了してノード３の処理に遷移する確率の値（0.0から1.0の間）である。また、閾値ｎは、ノード３の処理をノード２の処理に先行して開始するための遷移率Ｙの閾値（0.0から1.0の間）である。

ここで、各ノードの処理は、原則的にはノード１、ノード２、ノード３の順番に逐次実行される。しかしながら、各々のノードの処理は独立していて、前行程のノードの処理が異常終了、却下、差戻し等によって無駄になる又は再実行の必要が生じるリスクを考慮しない場合には並列に実行可能であるものとする。

本実施形態のワークフロー制御方法を図２（ａ）に示すフロー遷移に適用した場合、遷移率Ｘ、Ｙと閾値ｍ、ｎの値の比較により、図２（ｂ）、（ｃ）に示すフロー遷移に変更することができる。

図２（ｂ）は、ノード１の処理が完了した後に、ノード２の処理とノード３の処理とを並列に実行するフロー遷移を示す。これは、遷移率Ｘ＜閾値ｍ、遷移率Ｘ×遷移率Ｙ＜閾値ｎ、遷移率Ｙ≧閾値ｎという条件を満たすケースのフロー遷移である。すなわち、ノード２の処理をノード１の処理に先行して開始するリスクは高いため（遷移率Ｘ＜閾値ｍ）、ノード２の処理は、ノード１の処理が完了した後に実行される。一方、ノード３の処理をノード１の処理に先行して開始するリスクは高いが（遷移率Ｘ×遷移率Ｙ＜閾値ｎ）、ノード３の処理をノード２の処理に先行して開始するリスクは低いため（遷移率Ｙ≧閾値ｎ）、ノード３の処理は、ノード１の処理が完了した後にノード２の処理と並列に実行される。

図２（ｃ）は、ノード１、ノード２、ノード３の処理を並列に実行するフロー遷移を示す。これは、遷移率Ｘ≧閾値ｍ、遷移率Ｘ×遷移率Ｙ≧閾値ｎという条件を満たすケースのフロー遷移である。すなわち、ノード２及びノード３の処理をノード１の処理に先行して開始するリスクが低いため（遷移率Ｘ≧閾値ｍ、遷移率Ｘ×遷移率Ｙ≧閾値ｎ）、ノード１、ノード２、ノード３の処理は、並列に実行される。

ここで、ノードの処理が無駄になる又は再実行の必要が生じるリスクがあっても、ノードの処理を早く実施すべき場合や、再実行しても手戻りとなる作業量が少ない場合、閾値ｍ、ｎには低い値が設定される。また、ノードの処理が無駄になる又は再実行の必要が生じるリスクを重視すべき場合や、再実行した場合に手戻りとなる作業量が多い場合、閾値ｍ、ｎには高い値が設定される。一方、遷移率Ｘ、Ｙの値は、過去にワークフローを流れた案件の履歴情報の中から遷移率Ｘ、Ｙの値を求めるために利用する情報を予め定義し、その定義に基づいて導出される。詳細には後述する。

以上のように、本実施形態のワークフロー制御方法は、遷移率Ｘ、Ｙと閾値ｍ、ｎの値を用いて所定のノードの処理を前行程のノードの処理に先行して開始できるか否かを判定することによって、フロー遷移（フロー構成）を動的に変更することができる。

図１は、ワークフローシステム１の全体構成図である。図１に示すワークフローシステム（計算機システム）１は、ネットワーク１３０を介して接続されたクライアントＰＣ１４０、クライアントＰＣ１４０に対してワークフローサービス１０３を提供するサーバ１０１等を備える。

クライアントＰＣ１４０は、サーバ１０１によって提供されるワークフローサービス１０３の利用者が操作するＰＣである。このクライアントＰＣ１４０は、主記憶装置１４１、ＣＰＵ（Central Processing Unit）１４３を備える。またクライアントＰＣ１４０は、入出力装置１４４に接続されている。

主記憶装置１４１は、ＣＰＵ１４３によって実行されるプログラム、及び、プログラムの実行に必要なデータを記憶するＲＡＭ（Random Access Memory）等の記憶装置である。この主記憶装置１４１は、画面表示部１４２を含む。画面表示部１４２は、サーバ１０１の案件一覧表示部１０８によって表示される案件一覧画面や、帳票表示部１１０によって表示される帳票画面を入出力装置（ディスプレイ）１４４に表示するプログラムである。ＣＰＵ１４３は、主記憶装置１４１に記憶されているプログラムを実行する演算処理装置である。入出力装置１４４は、ユーザインターフェイスを提供する入出力装置（例えばキーボード、マウス、ディスプレイ）である。

サーバ１０１は、ワークフローサービス１０３をクライアントＰＣ１４０に提供するサーバ装置である。このサーバ１０１は、主記憶装置１０２、ＣＰＵ１０９を備える。またサーバ１０１は、ディスク装置１２０に接続されている。

主記憶装置１０２は、ＣＰＵ１０９によって実行されるプログラム、及び、プログラムの実行に必要なデータを記憶するＲＡＭ等の記憶装置である。この主記憶装置１０２には、ワークフローサービス１０３を実現するための案件処理部１０４、先行作業管理部１０５、案件一覧表示部１０８、帳票表示部１１０、フロー定義テーブル１１１、帳票定義テーブル１１２、先行作業定義テーブル１１３が格納されている。また先行作業管理部１０５は、先行開始判定部１０６、フロー構成変更部１０７を含む。ディスク装置１２０には、案件管理テーブル１２１、先行作業管理テーブル１２２、帳票データテーブル１２３、履歴データテーブル１２４が格納されている。各構成要素については詳細に後述する。

図３は、ワークフローシステム１の一例である備品発注システムのフロー遷移を示す図である。備品発注システムでは、最初に「申請」ノードにおいて、申請者が購入したい備品の品名や品数を帳票に記入して案件を申請する。次に「課長承認」、「部長承認」ノードにおいて、それぞれ課長、部長が申請された案件を承認する。その後「発注申請」ノードにおいて、資材部門の担当者が帳票上の発注に関する詳細、発注先や納品希望日などを記入して発注を申請する。その後「発注承認」ノードにおいて、資材部門の上長が発注を承認する。これにより、備品発注の業務プロセスが完了するとともに、発注システム（不図示）が連携して起動して発注業務を開始する。

図４は、フロー定義テーブル１１１の一例を示す図である。フロー定義テーブル１１１では、備品発注システムにおけるワークフローに関する定義が、予めフロー作成者によって定義される。

ノードＩＤ４０１には、各ノードを一意に識別するための識別子が格納される。ノード名４０２には、各ノードの名前が格納される。作業者４０３には、ノードの作業者の名前が格納される。なお、作業者４０３は、個人の名前でなくてもよい。例えば、申請者の属性によって動的に決定される名前（「申請者の所属組織の課長」等）であってもよい。また、ノードＮ０の申請者とノードＮ３の「発注申請」の作業者は同一であってもよい。申請者が申請し、課長、部長が承認した後に、申請者が発注申請を実行する場合も考えられるためである。

図５は、申請者が備品を発注するための帳票画面５００の一例を示す図である。

帳票表示部１１０（図１参照）は、クライアントＰＣ１４０からの要求に応じて、帳票画面５００をクライアントＰＣ１４０に表示させる。ノードＮ０の申請者は、帳票画面５００の各項目欄にデータを入力し、申請ボタンを操作する。そうすると、記入内容がサーバ１０１に送信される。その後、ノードＮ１以降のノードの処理が開始する。

図６は、発注申請者が発注を申請するための帳票画面６００の一例を示す図である。

帳票表示部１１０（図１参照）は、クライアントＰＣ１４０からの要求に応じて、図６に示す帳票画面６００をクライアントＰＣ１４０に表示させる。ノードＮ３の資材部門の担当者は、帳票画面５００上に入力された内容（図５）を参照して、各項目欄にデータを入力し、申請ボタンを操作する。そうすると、記入内容がサーバ１０１に送信される。その後、ノードＮ４の処理が開始する。

図７は、帳票定義テーブル１１２の一例を示す図である。帳票定義テーブル１１２は、帳票画面５００、６００（図５、図６参照）のレイアウト情報を定義する。

項目ＩＤ７０１には、帳票画面５００、６００に定義される各項目（入力項目、ラベル等）を一意に識別するための識別子が格納される。項目名７０２には、帳票画面５００、６００に定義される各項目の名称が格納される。タイプ７０３には、帳票画面５００、６００に定義される各項目の属性（タイトル、入力項目である場合にはテキスト（文字列）又は数値）が格納される。

図８は、先行作業定義テーブル１１３の一例を示す図である。先行作業定義テーブル１１３は、先行して作業を開始する可能性のあるノード（以下、「先行作業ノード」という。）に関する情報を定義する。

先行作業開始ノード８０１には、先行作業ノードの開始ノード（ここではＮ３の「発注申請」ノード）が格納される。先行作業終了ノード８０２には、先行作業ノードの終了ノード（ここではＮ４の「発注承認」ノード）が格納される。このように、先行作業開始ノード８０１及び先行作業終了ノード８０２によって、先行作業ノードの範囲として１又は２以上のノードを指定することができる。先行作業閾値８０３には、先行作業ノードの処理を先行して開始するための遷移率の閾値が格納される。ここでは0.85が格納されているので、遷移率が85％以上の場合に先行作業ノードの処理を先行して開始できる。第１条件８０４には、遷移率を求めるための第１の条件（ここでは「承認率」）が指定される。承認率の求め方については後述する。第１条件の重み８０５には、複数の条件がある場合の第１条件８０４の重みが0.0〜1.0の範囲の値（ここでは0.5）で指定される。第２条件８０６には、遷移率を求めるための第２の条件（ここでは、図７の帳票定義テーブル１１２で定義された項目ＩＤ７０１が「004」の「見積もり金額」）が指定される。帳票内容に基づく遷移率の求め方については後述する。第２条件の重み８０７には、複数の条件がある場合の第２条件８０６の重みが0.0〜1.0の範囲の値（ここでは0.5）で指定される。なお、遷移率を求めるための条件が図８のように複数ある場合、各条件の重みの合計が1.0になるように設定される。

続いて、本実施形態の備品発注システムにおいて、申請者が備品発注を申請してから先行作業が開始するまでの処理の流れや、先行作業が開始した後の処理の流れについて説明する。

図９は、案件処理部１０４の第１の制御ロジックを示すフローチャートである。申請者がクライアントＰＣ１４０から備品発注の帳票を起票し、帳票画面５００（図５参照）の各項目欄にデータを入力した後に申請ボタンを操作すると、案件処理部１０４は、図９に示す制御ロジックを開始する。

まずステップＳ９０１では、案件処理部１０４は、要求された処理内容が申請（案件投入）であるか、申請以外（承認・却下による案件情報の更新）であるかを判定する（Ｓ９０１）。最初は申請であるため、ステップＳ９０２に移る。ステップＳ９０２では、案件処理部１０４は、案件管理テーブル１２１に案件情報を格納する（Ｓ９０２）。

図１０は、案件管理テーブル１２１の一例を示す図である。案件管理テーブル１２１は、申請者によって申請された案件に関する情報を管理する。

案件ＩＤ１００１には、各案件を一意に識別するために案件処理部１０４によって採番された識別子が格納される。なお、以降の説明では、案件ＩＤ１００１が「0015」の案件に着目する。業務名称１００２には、案件の業務名称が格納される。申請者名１００３には、案件の申請者の名称が格納される。申請日時１００４には、案件の申請日時が格納される。滞在ノード１００５には、現に滞在しているノードのノードＩＤが格納される。なお、案件ＩＤ１００１が「0015」の案件は申請者によって申請された直後であるため、滞在ノード１００５にはノードＮ０（申請）の次のノードＮ１が格納されている。

図９に戻り、ステップＳ９０３では、案件処理部１０４は、帳票データテーブル１２３に帳票データを格納する（Ｓ９０３）。

図１１は、帳票データテーブル１２３の一例を示す図である。この帳票データテーブル１２３は、図１の帳票データテーブル１２３に対応する。帳票データテーブル１２３は、申請者によって帳票画面５００の各項目欄に入力された帳票に関する情報を格納する。

案件ＩＤ１１０１には、図１０の案件ＩＤ１００１と同一の識別子が格納される。データ１１０２には、申請者が帳票画面５００（図５参照）の各項目欄に入力した内容が入力項目と対応付けて格納される。データ１１０３には、ノードＮ３の作業者が帳票画面６００（図６参照）の各項目欄に入力した内容が入力項目と対応付けて格納される。なお、案件ＩＤ１１０１が「0015」の案件は申請者によって申請された直後であるため、データ１１０３は空である。

図９に戻り、ステップＳ９０４では、案件処理部１０４は、先行作業管理部１０５を呼び出す（Ｓ９０４）。なお、先行作業管理部１０は、申請、承認等によってノードの処理が遷移するタイミング毎に、このステップＳ９０４によって呼び出される。

図１２は、先行作業管理部１０５の制御ロジックを示すフローチャートである。図９のステップＳ９０４に進むと、先行作業管理部１０５は、図１２に示す制御ロジックを開始する。

まずステップＳ１２０１では、先行作業管理部１０５は、先行作業定義テーブル１１３（図８参照）に定義された全ての先行作業ノードに関する情報を取得する（Ｓ１２０１）。本実施例では、ノードＮ３の「発注申請」からノードＮ４の「発注承認」までの先行作業ノードに関する情報が取得される。

ステップＳ１２０２では、先行作業管理部１０５は、先行開始の可否について未判定の先行作業ノードが存在するか否かを判定する（Ｓ１２０２）。本実施例では、ステップ１２０１で取得された先行作業ノードに対する先行開始の可否について未判定であるため（Ｓ１２０２でＹＥＳ）、ステップＳ１２０３に移る。

ステップＳ１２０３では、先行作業管理部１０５は、ステップＳ１２０２で存在すると判定された先行作業ノードの処理が開始済みか否かを、先行作業管理テーブル１２２（図１６参照）を参照して判定する（Ｓ１２０３）。先行作業管理テーブル１２２の詳細については図１６を用いて後述するが、先行作業ノードの処理が先行して開始すると、先行作業管理テーブル１２２にレコードが追加される。そのため、ステップＳ１２０３では、先行作業管理テーブル１２２にレコードが存在するか否かを探索することによって、上記判定が実施される。

先行作業ノードの処理が既に開始済みの場合には（Ｓ１２０３でＹＥＳ）、ステップＳ１２０２に戻り、次の先行作業ノードの処理が開始済みか否か判定される。本実施例では、先行作業ノードの処理は開始していないため（Ｓ１２０３でＮＯ）、ステップＳ１２０４に移る。

ステップＳ１２０４では、先行作業管理部１０５は、現在の滞在ノードから先行作業開始ノードまでの範囲で処理が未完了のノードを抽出する（Ｓ１２０４）。本実施例では、現在の滞在ノードがＮ１であり、先行作業開始ノードはＮ３である。そのため、この範囲で処理が未完了であるＮ１及びＮ２の２つのノードが抽出される。

ステップＳ１２０５では、先行作業管理部１０５は、ステップＳ１２０４でノードが抽出されたか否かを判定する（Ｓ１２０５）。ステップＳ１２０４でノードが抽出されない場合（例えば現在の滞在ノードと先行作業開始ノードが同一であるような場合、Ｓ１２０５でＮＯ）、先行作業開始ノードの処理は先行して開始することなく、通常通り処理される。この場合には、ステップＳ１２０２に戻り、次の先行作業ノードの処理が開始済みか否か判定される。

本実施例では、ステップＳ１２０４でＮ１及びＮ２の２つのノードが抽出されるため（Ｓ１２０５でＹＥＳ）、ステップＳ１２０６に移る。ステップＳ１２０１からＳ１２０５までの処理により、先行作業開始ノードであるＮ３が、先行開始判定部１０６によって先行して開始できるか否かの判定対象となることが確定する。

ステップＳ１２０６では、先行作業管理部１０５は、先行開始判定部１０６を呼び出す（Ｓ１２０６）。なお、呼び出された先行開始判定部１０６による処理が完了すると、ステップＳ１２０２に戻り、次の先行作業ノードの処理が開始済みか否か判定される。

図１３は、先行開始判定部１０６の制御ロジックを示すフローチャートである。図１２のステップＳ１２０６に進むと、先行開始判定部１０６は、図１３に示す制御ロジックを開始する。

まずステップＳ１３０１では、先行開始判定部１０６は、先行作業定義テーブル１１３（図８参照）から、先行作業ノードに関する情報を取得する（Ｓ１３０１）。先行作業ノードに関する情報（先行作業定義情報）とは、現に処理が実施されたノードから、この先行開始判定部１０６による判定対象の先行作業ノードへの遷移率を求めるための条件や重みといった各種情報である。

ステップＳ１３０２では、先行開始判定部１０６は、履歴データテーブル１２４から、判定対象の先行作業ノードについての履歴情報を取得する（Ｓ１３０２）。本実施例では、図１２のステップＳ１２０４で抽出されたＮ１及びＮ２の２つのノードについての履歴情報が取得される。

図１４は、履歴データテーブル１２４の一例を示す図である。履歴データテーブル１２４は、先行作業定義テーブル１１３（図８参照）に定義された遷移率を求める条件に対応する履歴情報を格納する。

ノードＩＤ１４０１には、各ノードを一意に識別するための識別子が格納される。これにより、各ノード単位での履歴情報が、この履歴データテーブル１２４に格納される。承認回数１４０２には、各ノードにおいて過去に承認された回数が格納される。却下回数１４０３には、各ノードにおいて過去に却下された回数が格納される。このように、承認回数１４０２及び却下回数１４０３には、先行作業定義テーブル１１３（図８参照）の第１条件８０４に指定された第１の条件（承認率）に対応する履歴情報が格納されている。承認平均値１４０４には、過去に承認された案件における帳票項目Ｎｏ００４（図７参照）の値の平均値が格納される。却下平均値１４０５には、過去に却下された案件における帳票項目Ｎｏ００４（図７参照）の値の平均値が格納される。このように、承認平均値１４０４及び却下平均値１４０５には、先行作業定義テーブル１１３（図８参照）の第２条件８０６に指定された第２の条件（帳票内容：帳票項目Ｎｏ００４）に対応する履歴情報が格納されている。

図１３に戻り、ステップＳ１３０３では、先行開始判定部１０６は、ステップＳ１３０２で取得された履歴情報から、条件単位で遷移率を計算する（Ｓ１３０３）。本実施例では、第１の条件（承認率）及び第２の条件（帳票内容：帳票項目Ｎｏ００４）の各々についての遷移率を計算する。

まず、第１の条件（承認率）についての遷移率の計算方法を説明する。

承認率は、承認回数１４０２及び却下回数１４０３の各々に格納されている承認回数と却下回数から、承認率＝承認回数／(承認回数＋却下回数)によって算出される。ここでは、ノードＮ１の承認率として、80/(20+80)＝0.8が算出される。一方、ノードＮ２の承認率として、72/(72+8)＝0.9が算出される。

以上から、現在の滞在ノードであるＮ１から先行作業開始ノードであるＮ３までの第１の条件についての遷移率は、ノードＮ１の承認率及びノードＮ２の承認率の乗算によって算出される0.8×0.9＝0.72となる。

次に、第２の条件（帳票内容：帳票項目Ｎｏ００４）についての遷移率の計算方法を説明する。

第２の条件についての遷移率は、承認平均値１４０４及び却下平均値１４０５の各々に格納されている情報から、下記条件式（１）から（７）によって算出される。
（１）入力値≦承認平均値＜却下平均値の場合には、遷移率＝1.0
（２）承認平均値＜却下平均値≦入力値の場合には、遷移率＝0.0
（３）却下平均値＜承認平均値≦入力値の場合には、遷移率＝1.0
（４）入力値≦却下平均値＜承認平均値の場合には、遷移率＝0.0
（５）却下平均値＝承認平均値の場合には、入力値に関係なく遷移率＝0.5
（６）承認平均値＜入力値＜却下平均値の場合には、遷移率＝1−(入力値−承認平均値)/(却下平均値−承認平均値))
（７）却下平均値＜入力値＜承認平均値の場合には、遷移率＝1−(承認平均値−入力値)/(承認平均値−却下平均値))

本実施例では、申請者による入力値は30000である（図１１参照）。また、ノードＮ１の承認平均値、却下平均値は、それぞれ20000、80000である（図１４参照）。上記（１）から（６）に当てはめると、（６）の式に合致する。従って、第２の条件に基づくノードＮ１の遷移率として、1−(30000−20000)/(80000-20000))＝1−1/6≒0.83が算出される。

一方、ノードＮ２の承認平均値、却下平均値は、それぞれ30000、100000である（図１４参照）。上記（１）から（６）に当てはめると、（１）の式に合致する。従って、第２の条件に基づくノードＮ２の遷移率として、1.0が算出される。

以上から、現在の滞在ノードであるＮ１から先行作業開始ノードであるＮ３までの第２の条件についての遷移率は、ノードＮ１の遷移率及びノードＮ２の遷移率の乗算によって算出される0.83×1.0＝0.83となる。

以上から、第１の条件（承認率）についての遷移率は0.72、第２の条件（帳票内容：帳票項目Ｎｏ００４）についての遷移率は0.83となる。

続いてステップＳ１３０４では、先行開始判定部１０６は、ステップＳ１３０３で算出された各条件の遷移率を重み付けして加算する（Ｓ１３０４）。本実施例では、0.72(第１の条件についての遷移率)×0.5(第１の条件の重み)＋0.83(第２の条件についての遷移率)×0.5(第２の条件の重み)≒0.78が算出される。

続いてステップＳ１３０５では、先行開始判定部１０６は、ステップＳ１３０４で算出された遷移率と先行作業閾値８０３（図８参照）の値を比較する（Ｓ１３０５）。遷移率が閾値より大きい場合には（Ｓ１３０５でＹＥＳ）、先行して開始できると判定し、ステップＳ１３０６に移る。遷移率が閾値以下である場合には（Ｓ１３０５でＮＯ）、先行して開始できないと判定し、処理を終了する。本実施例では、ステップＳ１３０４で算出された遷移率は0.78である。一方、先行作業閾値８０３の値は0.85である。このように遷移率0.78は閾値0.85以下であるため（Ｓ１３０５でＮＯ）、処理を終了する。すなわち、申請直後の段階では、ノードＮ３の「発注申請」を先行して開始するのはリスクが高いと判断されたことを意味する。

続いて、本実施形態の備品発注システムにおいて、ノードＮ１の承認処理が正常に終了した場合の処理の流れについて説明する。課長がクライアントＰＣ１４０から案件を承認すると、案件処理部１０４は、図９に示す制御ロジックを開始する。

まずステップＳ９０１では、案件処理部１０４は、要求された処理内容が申請（案件投入）であるか、申請以外（承認・却下による案件情報の更新）であるかを判定する（Ｓ９０１）。ここでは申請ではないため、ステップＳ９１０に移る。ステップＳ９１０では、案件処理部１０４は、承認であるか又は却下であるかを判定する（Ｓ９１０）。ここでは承認であるため、ステップＳ９０５に移る。なお、ステップＳ９０５からＳ９０９の処理については後述するものとし、ここではステップＳ９０４の処理について説明する。

図９のステップＳ９０４に進むと、先行作業管理部１０５は、図１２に示す制御ロジックを開始する。ここでは先行作業ノードであるノードＮ３の処理は先行して開始していないため、ステップＳ１２０４に移る。その後ステップＳ１２０４では、先行作業管理部１０５は、現在の滞在ノードＮ２から先行作業開始ノードＮ３までの範囲で処理が未完了のノードであるＮ２を抽出する（Ｓ１２０４）。その後ステップＳ１２０５でＹＥＳからステップＳ１２０６に進んで、先行作業管理部１０５は、先行開始判定部１０６を呼び出す（Ｓ１２０６）。

図１２のステップＳ１２０６に進むと、先行開始判定部１０６は、図１３に示す制御ロジックを開始する。ステップＳ１３０１及びＳ１３０２を実施した後に、ステップＳ１３０３では、先行開始判定部１０６は、履歴情報から条件単位で遷移率を算出する（Ｓ１３０３）。ここでは説明の都合上、履歴情報に格納されている値が申請時点と変わらないものとして算出する。そうすると、第１の条件についての遷移率は0.9になる。また、第２の条件についての遷移率は、前述の式（１）に該当し、1.0になる。従って、続くステップＳ１３０４で算出される遷移率は、0.9（第１条件に基づく遷移率）×0.5（第１条件の重み）＋1.0（第２条件に基づく遷移率）×0.5（第２条件の重み）＝0.95となる（Ｓ１３０４）。

その後、ステップＳ１３０５では、ステップＳ１３０４で算出された遷移率が0.95であり、図８の先行作業定義テーブル１１３の先行作業閾値８０３の値0.85よりも大きいため（Ｓ１３０５でＹＥＳ）、先行して開始できると判定し、ステップＳ１３０６に移る。ステップＳ１３０６では、先行開始判定部１０６は、フロー構成変更部１０７を呼び出す（Ｓ１３０６）。

図１５は、フロー構成変更部１０７の制御ロジックを示すフローチャートである。図１３のステップＳ１３０６に進むと、フロー構成変更部１０７は、図１５に示す制御ロジックを開始する。

ステップＳ１５０１では、フロー構成変更部１０７は、先行作業管理テーブル１２２（図１６参照）に、先行して開始した案件情報を格納する（Ｓ１５０１）。その後、処理を終了する。

図１６は、先行作業管理テーブル１２２の一例を示す図である。先行作業管理テーブル１２２は、先行して開始した作業に関する情報を管理する。

案件ＩＤ１６０１には、案件ＩＤ１００１（図１０参照）が格納される。ここでは、案件ＩＤ「0015」が格納される。先行作業開始日時１６０２には、先行作業を開始した日時が格納される。滞在ノード１６０３には、現に滞在しているノードのノードＩＤが格納される。なお、案件ＩＤ１６０１が「0015」の案件は先行作業が先行開始された直後であるため、滞在ノード１６０３には先行作業開始ノードであるＮ３が格納されている。先行作業ノード１６０４には、先行作業ノードが格納される。開始元１６０５には、先行作業が先行開始できると判定したタイミングでの開始元ノードが格納される。ここでは、ノードＮ１の処理が完了したタイミングで、ノードＮ３の処理が先行して開始できると判定されたため、ノードＮ１が格納される。第１条件の遷移率１６０６には、遷移率を求めるための第１の条件で計算された結果の値（ここでは0.9）が格納される。第２条件の遷移率１６０７には、遷移率を求めるための第２の条件で計算された結果の値（ここでは1.0）が格納される。最終遷移率１６０８には、最終的に求められた遷移率の値（ここでは0.95）が格納される。

以上より、図１７（ａ）に示すフロー遷移（図３と同一のフロー遷移）が、図１７（ｂ）に示すフロー遷移に変更される。図１７（ｂ）は、ノードＮ１の処理が完了した後に、ノードＮ２の処理と先行作業ノードであるノードＮ３及びＮ４の処理とを並列に実行するフロー遷移を示す。なお、図１７は、構成変更されたフロー遷移の説明図である。

続いて、本実施形態の備品発注システムにおいて、フロー遷移の構成が変更される別の例として、ノードＮ０の承認処理が正常に終了した場合の処理の流れを説明する。

ここでは、申請者による入力値は30000ではなく10000であるものとする。また、履歴データテーブル１２４の代わりに履歴データテーブル１２４（図１８参照）が用いられるものとする。なお、先行作業閾値８０３（図８参照）には、前述と同様に閾値0.85が格納されている。

図１８は、履歴データテーブル１２４の一例を示す図である。履歴データテーブル１２４は、図１４に示す履歴データテーブル１２４と同様に、先行作業定義テーブル１１３（図８参照）に定義された遷移率を求める条件に対応する履歴情報を格納する。

この履歴データテーブル１２４は、承認回数１４０２、却下回数１４０３、承認平均値１４０４及び却下平均値１４０５に格納された値が図１４に示す履歴データテーブル１２４と異なる。

この場合、図１３のステップＳ１３０３では、第１の条件（承認率）及び第２の条件（帳票内容：帳票項目Ｎｏ００４）の各々についての遷移率は、以下のように算出される。すなわち、第１の条件（承認率）についての遷移率として、（ノードＮ１の承認率）×（ノードＮ２の承認率）＝（300/(300+30)≒0.91）×（280/(280+20)）≒0.93）≒0.85が算出される。一方、第２の条件（帳票内容：帳票項目Ｎｏ００４）についての遷移率として、（第２条件に基づくノードＮ１の遷移率）×（第２条件に基づくノードＮ２の遷移率）＝1.0×1.0＝1.0が算出される。なお、ノードＮ１及びＮ２はいずれも上記式（１）に合致している。

従って、続くステップＳ１３０４で算出される遷移率は、0.85（第１条件に基づく遷移率）×0.5（第１条件の重み）＋1.0（第２条件に基づく遷移率）×0.5（第２条件の重み）≒0.93となる。

その後、ステップＳ１３０５では、ステップＳ１３０４で算出された遷移率が0.93であり、図８の先行作業定義テーブル１１３の先行作業閾値８０３の値0.85よりも大きいため（Ｓ１３０５でＹＥＳ）、先行して開始できると判定し、ステップＳ１３０６に移る。

以上より、図１７（ａ）に示すフロー遷移が、図１７（ｃ）に示すフロー遷移に変更される。図１７（ｃ）は、ノードＮ０の処理が完了した後に、ノードＮ１の処理と先行作業ノードであるノードＮ３及びＮ４の処理とを並列に実行するフロー遷移である。

図１９は、発注申請者が案件一覧を閲覧するための案件一覧画面１９００の一例を示す図である。

案件一覧表示部１０８は、クライアントＰＣ１４０からの要求に応じて、図１９に示す案件一覧画面１９００をクライアントＰＣ１４０に表示させる。図１９に示す案件一覧画面１９００は、特に、先行作業ノードＮ３の処理が先行開始した後に、先行作業ノードＮ３の処理者である発注申請者からの要求に応じて表示される画面である。

案件一覧表示部１０８は、案件管理テーブル１２１（図１０参照）及び先行作業管理テーブル１２２（図１６参照）を参照して、滞在ノード１００５、滞在ノード１６０３がノードＮ３であるレコードを検索し、検索されたレコードの情報をクライアントＰＣ１４０に送信する。

その後クライアントＰＣ１４０は、受信したレコードの情報に基づいて、図１９に示すように、通常のフロー遷移を流れてきた案件と、先行作業として流れてきた案件と、を区別させて表示する。これにより、発注申請者は、先行開始されている案件を画面上で判断することができる。

図２０は、先行作業の詳細情報画面例を示す図である。

図１９に示す詳細ボタン１９０１が入出力装置１４４（マウス）によってクリックされた場合、案件一覧表示部１０８は、クリックされた詳細ボタン１９０１の案件に関する詳細情報を先行作業管理テーブル１２２（図１６参照）から取得し、取得された詳細情報をクライアントＰＣ１４０に送信する。

その後クライアントＰＣ１４０は、受信した詳細情報に基づいて、図２０のウィンドウ２０００に示すように、案件に関する詳細情報を表示する。このように、先行開始した案件の遷移率を発注申請者に通知することによって、発注申請者は、処理の優先順位の判断材料とすることができる。

続いて、本実施形態の備品発注システムにおいて、いずれかのノードで承認・却下処理が実施された場合の処理の流れについて図９を参照して説明する。いずれかのノードの処理者がクライアントＰＣ１４０から案件を承認・却下すると、案件処理部１０４は、図９に示す制御ロジックを開始する。

まずステップＳ９０１において、案件処理部１０４は、要求された処理内容が申請（案件投入）であるか、申請以外（承認・却下による案件情報の更新）であるかを判定する（Ｓ９０１）。ここでは申請ではないため、ステップＳ９１０に移る。ステップＳ９１０では、案件処理部１０４は、要求された処理内容が承認であるか又は却下であるかを判定する（Ｓ９１０）。

承認である場合には、ステップＳ９０５に移る。ステップＳ９０５では、案件処理部１０４は、処理を実施したノードが先行作業ノードであり、且つ、先行開始済みであるか否かを判定する（Ｓ９０５）。Ｓ９０５でＹＥＳの場合には、ステップＳ９０６に移って、案件処理部１０４は、図２１のフローチャートの処理を実行する。一方、Ｓ９０５でＮＯの場合（処理を実施したノードが先行作業ノードではない、又は、先行作業ノードであるが先行開始していない場合）には、ステップＳ９０７に移って、案件処理部１０４は、図２２のフローチャートの処理を実行する。また、ステップＳ９１０で却下である場合には、ステップＳ９１１に移って、案件処理部１０４は、図２３のフローチャートの処理を実行する。なお、以降の説明においては、先行開始していない先行作業ノードの処理を「通常処理」と呼ぶ。

図２１は、案件処理部１０４の第２の制御ロジックを示すフローチャートである。図９のステップＳ９０６に進むと、案件処理部１０４は、図２１に示す制御ロジックを開始する。

まずステップＳ２１０１では、案件処理部１０４は、処理が実施されたノードが先行作業ノードの終了ノードか否か判定する（Ｓ２１０１）。すなわち、先行作業ノードの処理が完了したか否かが判定される。先行作業ノードの終了ノードでない場合には（Ｓ２１０１でＮＯ）、ステップＳ２１０２に移り、案件処理部１０４は、先行作業管理テーブル１２２（図１６参照）の該当する案件ＩＤ１６０１のレコードの滞在ノード１６０３を“次のノードＩＤ”に更新する（Ｓ２１０２）。

先行作業ノードの終了ノードである場合には（Ｓ２１０１でＹＥＳ）、ステップＳ２１０３に移り、案件処理部１０４は、先行作業管理テーブル１２２（図１６参照）の該当する案件ＩＤ１６０１のレコードの滞在ノード１６０３を“完了”に更新する。

なお、図２１に示す制御ロジックが終了すると、図９のステップＳ９０８に戻り、案件処理部１０４は、履歴データテーブル１２４（図１４参照）を更新する（Ｓ９０８）。これにより、常に最新の履歴情報に基づいて先行作業ノードの先行開始の可否を判定することができる。続くステップＳ９０９では、案件処理部１０４は、帳票データテーブル１２３（図１１参照）を更新する（Ｓ９０９）。

図２２は、案件処理部１０４の第３の制御ロジックを示すフローチャートである。図９のステップＳ９０７に進むと、案件処理部１０４は、図２２に示す制御ロジックを開始する。

まずステップＳ２２０１では、案件処理部１０４は、処理が実施されたノードの次のノードが存在するか判定する（Ｓ２２０１）。次のノードが存在しない場合には（Ｓ２２０１でＮＯ）、処理が実施されたノードが最後のノードであり、該当する案件のワークフローは完了したことになる。そのため、案件処理部１０４は、案件管理テーブル１２１（図１０参照）の該当する案件ＩＤ１００１の滞在ノード１００５を“完了”に更新し、処理を終了する。

次のノードが存在する場合には（Ｓ２２０１でＹＥＳ）、ステップＳ２２０２に移り、案件処理部１０４は、次のノードが先行作業ノードか否かを判定する（Ｓ２２０２）。次のノードが先行作業ノードでない場合には（Ｓ２２０２でＮＯ）、ステップＳ２２０４に移り、案件処理部１０４は、案件管理テーブル１２１（図１０参照）の該当する案件ＩＤ１００１の滞在ノード１００５を“次のノードＩＤ”に更新し（Ｓ２２０４）、処理を終了する。

次のノードが先行作業ノードである場合には（Ｓ２２０２でＹＥＳ）、ステップＳ２２０３に移り、案件処理部１０４は、この先行作業ノードの処理が開始済みか否かを、先行作業管理テーブル１２２（図１６参照）を参照して判定する（Ｓ２２０３）。先行作業ノードの処理が先行開始していない場合には（Ｓ２２０３でＮＯ）、この先行作業ノードの処理は上記の通常処理である。そのため、ステップＳ２２０４に移り、案件処理部１０４は、案件管理テーブル１２１（図１０参照）の該当する案件ＩＤ１００１の滞在ノード１００５を次のノードＩＤに更新し（Ｓ２２０４）、処理を終了する。

一方、先行作業ノードの処理が先行開始済みである場合には（Ｓ２２０３でＹＥＳ）、ステップＳ２２０５に移る。ステップＳ２２０５では、案件処理部１０４は、先行作業ノードの終了ノードの処理が完了したか否かを、先行作業管理テーブル１２２（図１６参照）の該当する案件ＩＤ１６０１の滞在ノード１６０３の値を参照して判定する（Ｓ２２０５）。

先行作業ノードの終了ノードの処理が完了していない場合には（Ｓ２２０５でＮＯ）、ステップＳ２２０７に移り、案件処理部１０４は、先行作業管理テーブル１２２（図１６参照）の該当する案件ＩＤ１６０１の滞在ノード１６０３の値を、案件管理テーブル１２１（図１０参照）の該当する案件ＩＤ１００１の滞在ノード１００５にコピーし、先行作業管理テーブル１２２（図１６参照）の該当する案件ＩＤ１６０１のレコードを削除する（Ｓ２２０７）。ここでは、先行開始した先行作業ノードの内の処理が未完了のノードの処理が上記の通常処理となる。そのため、このステップＳ２２０７では、案件処理部１０４は、先行開始した先行作業ノードの処理を現に滞在しているノードの処理として扱うべく、上記のコピーを実施している。

一方、先行作業ノードの終了ノードの処理が完了した場合には（Ｓ２２０５でＹＥＳ）、ステップＳ２２０６に移る。ここでは、先行開始した先行作業ノードの直前までのノードの処理は全て完了し、先行開始した先行作業ノードの処理も全て完了している。すなわち、先行作業ノードの終了ノードの処理までが全て完了している。そのため、このステップＳ２２０６では、案件処理部１０４は、最後に処理を実施したノードの処理が、先行作業定義テーブル１１３（図８参照）の終了ノードの処理であるものとみなし、先行作業管理テーブル１２２（図１６参照）の該当する案件ＩＤ１６０１のレコードを削除する（Ｓ２２０６）。その後ステップＳ２２０１に戻り、案件処理部１０４は、一連の処理を繰り返す。

なお、図２２に示す制御ロジックが終了すると、図９のステップＳ９０８に戻り、案件処理部１０４は、履歴データテーブル１２４（図１４参照）を更新する（Ｓ９０８）。これにより、常に最新の履歴情報に基づいて先行作業ノードの先行開始の可否を判定することができる。続くステップＳ９０９では、案件処理部１０４は、帳票データテーブル１２３（図１１参照）を更新する（Ｓ９０９）。

図２３は、案件処理部１０４の第４の制御ロジックを示すフローチャートである。図９のステップＳ９１１に進むと、案件処理部１０４は、図２３に示す制御ロジックを開始する。

まずステップＳ２３０１では、案件処理部１０４は、先行作業管理テーブル１２２（図１６参照）から該当する案件ＩＤ１６０１のレコードを全て削除する（Ｓ２３０１）。先行開始した先行作業ノードの処理は、図９のステップＳ９１０の却下によって差し戻されるためである。次にステップＳ２３０２では、案件処理部１０４は、案件管理テーブル１２１（図１０参照）の該当する案件ＩＤ１００１の滞在ノード１００５の値を“Ｎ０(申請)”に更新する（Ｓ２３０２）。その後ステップＳ２３０３では、案件処理部１０４は、履歴データテーブル１２４（図１４参照）に却下されたノードに対応する履歴情報を更新し（Ｓ２３０３）、処理を終了する。

なお、ステップＳ２３０１では、案件処理部１０４は、無条件に先行開始していた作業を削除しているが、この場合には限らない。例えば、先行開始していた作業が無駄となったことをステップＳ２３０１の処理の前に、メールで処理者に対して通知してもよい。これは、先行開始した作業は先行作業管理テーブル１２２（図１６参照）によって管理されているため、先行開始しており、かつ完了済みの作業がどれか判定することができるからである。

図２４は、ワークフローシステムによるワークフロー制御方法の概要を示す第２の図である。図２４（ａ）は、本実施形態のワークフロー制御方法を適用する前のノード１、ノード２、ノード３の処理が順番に実行されるフロー遷移を示す。この図２４（ａ）に示すフロー遷移は図２（ａ）と同様である。

本実施形態のワークフロー制御方法を図２４（ａ）に示すフロー遷移に適用した場合、遷移率Ｘ、Ｙと閾値ｍ、ｎの値の比較により、図２（ｂ）、（ｃ）に示すフロー遷移に加え、図２４（ｂ）から（ｅ）に示すフロー遷移に変更することもできる。

図２４（ｂ）は、ノード２の処理をノード１の処理に先行して開始できるが、ノード３の処理をノード１の処理に先行して開始できないフロー遷移を示す。これは、遷移率Ｘ≧閾値ｍ、遷移率Ｘ×遷移率Ｙ＜閾値ｎ、遷移率Ｙ≦閾値ｎという条件を満たすケースのフロー遷移である。

図２４（ｃ）は、図２４（ｂ）の変形例で、ノード２の処理がノード１の処理よりも早く完了し、ノード１の処理が完了する前にノード３の処理が実行されるフロー遷移を示す。これは、遷移率Ｘ≧閾値ｎという条件を満たすケースのフロー遷移である。

図２４（ｄ）は、図２４（ｃ）の変形例で、ノード１の処理がノード２の処理よりも早く完了し、ノード２の処理が完了する前にノード３の処理が実行されるフロー遷移を示す。これは、遷移率Ｙ≧閾値ｎという条件を満たすケースのフロー遷移である。

図２５（ｅ）は、ノード３の処理は、ノード１及びノード２の処理に先行して開始できるが、ノード２の処理は、ノード１の処理が完了した後に実行されるフロー遷移である。これは、遷移率Ｘ×遷移率Ｙ≧閾値ｎ、遷移率Ｘ＜閾値ｍ、閾値ｍ＞閾値ｎという条件を満たすケースのフロー遷移である。

以上のように、本実施形態のワークフロー制御方法は、遷移率Ｘ、Ｙと閾値ｍ、ｎの値を用いて所定のノードの処理を他のノードの処理に先行して開始できるか否かを判定することによって、フロー遷移（フロー構成）を動的に変更することができる。

以上説明してきた本実施形態のワークフローシステムによれば、先行作業ノードの処理が先行開始していた場合でも、先行開始していない場合でも、ノードの遷移に不整合が起きないように処理を進めることができる。

また、先行作業ノードを開始するタイミングを適切に判定したうえで先行開始している。そのため、ワークフロー上を流れる案件が完了するまでの全体時間を短縮することができる。また、現に処理が実施されたノードから先行作業ノードの処理に到達するまでの遷移率に着目し、履歴情報を利用して先行作業ノードを開始している。そのため、同じ業務であっても運用状況に応じて適切なタイミングで先行作業を開始することができる。また、遷移率の算出に履歴情報を用いることによって、同じ業務プロセスであっても運用状況や申請内容に応じてフロー遷移（フロー構成）を複数のパターンに動的に変更し、適切なタイミングで先行作業ノードの処理を開始することができる。なお、遷移率は、過去にワークフローを流れた案件の履歴情報をもとに各ノードにおける承認率や、過去に承認された帳票の入力内容の統計情報など、複合的な要素を組み合わせて算出される。

以上、本発明の各実施形態について説明したが、上記実施形態は本発明の適用例の一つを示したものであり、本発明の技術的範囲を上記実施形態の具体的構成に限定する趣旨ではない。

例えば、上記説明においては、遷移率を算出するための履歴情報として、各ノード単位での承認回数・却下回数や、特定の帳票項目の承認平均値・却下平均値を用いたが、この場合に限らない。処理者自身の履歴情報を用いることも可能である。この場合、申請者Ａが申請した回数と、ノード１上で処理した処理者Ｂの承認回数・却下回数を履歴として保存しておき、これを利用することで遷移率を算出することができる。

１０１ サーバ
１０２、１４１ 主記憶装置
１０３ ワークフローシステム
１０４ 案件処理部
１０５ 先行作業管理部
１０６ 先行開始判定部
１０７ フロー構成変更部
１０８ 案件一覧表示部
１０９、１４３ ＣＰＵ
１１０ 帳票表示部
１１１ フロー定義テーブル
１１２ 帳票定義テーブル
１１３ 先行作業定義テーブル
１２０ ディスク装置
１２１ 案件管理テーブル
１２２ 先行作業管理テーブル
１２３ 帳票データテーブル
１２４ 履歴データテーブル
１３０ ネットワーク
１４０ クライアントＰＣ
１４２ 画面表示部
１４４ 入出力装置

Claims (12)

1. 複数のノードの処理が所定の順番で実行されるよう定義されたワークフロー定義に従って業務プロセスを遂行するワークフローサービスを提供するサーバ装置と、前記サーバ装置とネットワークを介して接続され、前記サーバ装置から前記ワークフローサービスの提供を受けるクライアント装置と、を備えた計算機システムであって、
   前記サーバ装置、前記クライアント装置の各々は、プログラムを実行するプロセッサと、前記プロセッサによって実行されるプログラムを格納するメモリと、を備え、
   前記サーバ装置は、
   前記複数のノードのうちの所定のノードを、前記クライアント装置において現に処理が実施されたノードと前記所定のノードとの間に存在するノードに対して、先行して処理を開始可能な先行作業ノードとして定義する先行作業定義情報と、
   前記業務プロセスが、所定の入力値に対して承認又は却下が実施されるものである場合、前記現に処理が実施されたノードから、前記先行作業ノードへの遷移率を、前記現に処理が実施されたノードと前記先行作業ノードとの間に存在するノードにおいて、過去に承認されたときの承認平均値、却下されたときの却下平均値を用いて算出し、算出された前記遷移率に基づいて、前記先行作業ノードの処理を先行して開始するか否かを判定する先行作業管理部と、
   前記先行作業ノードの処理を先行して開始すると判定された場合、前記先行作業ノードの処理を先行して開始することによって、前記ワークフロー定義に定義されたノードの処理順番を動的に変更するフロー構成変更部と、
   前記変更されたノードの処理順番に従って、前記業務プロセスを遂行する案件処理部と、
   を備えることを特徴とする計算機システム。
2. 前記先行作業管理部は、前記現に処理が実施されたノードと前記先行作業ノードとの間に存在するノードが複数ある場合には、これら各ノードの遷移率を算出し、各ノードの遷移率を乗算することによって算出される遷移率に基づいて、前記先行作業ノードの処理を先行して開始するか否かを判定することを特徴とする請求項１に記載の計算機システム。
3. 前記先行作業管理部は、前記現に処理が実施されたノードから、前記先行作業ノードへの遷移率を、前記現に処理が実施されたノードと前記先行作業ノードとの間に存在するノードにおいて、過去に承認された回数、却下された回数を、さらに用いて算出することを特徴とする請求項１に記載の計算機システム。
4. 前記先行作業定義情報は、さらに、前記先行作業ノードの処理を先行して開始するための条件及び前記条件毎に定められる重みを含み、
   前記先行作業管理部は、前記条件毎に前記遷移率を算出し、前記算出された条件毎の遷移率を重み付けして加算することによって算出される遷移率に基づいて、前記先行作業ノードの処理を先行して開始するか否かを判定することを特徴とする請求項１に記載の計算機システム。
5. 前記先行作業定義情報は、さらに、前記先行作業ノードの処理を先行して開始するための遷移率の閾値を定義しており、
   前記先行作業管理部は、前記算出された遷移率と前記閾値との比較によって、前記先行作業ノードの処理を先行して開始するか否かを判定することを特徴とする請求項１に記載の計算機システム。
6. 前記サーバ装置は、さらに、処理順番が変更されていない案件と、処理順番が変更された案件と、を区別可能に表示するためのデータを生成する案件一覧表示部を有することを特徴とする請求項１に記載の計算機システム。
7. 前記案件一覧表示部は、さらに、前記処理順番が変更された案件についての前記先行作業ノードの遷移率を表示するためのデータを生成することを特徴とする請求項６に記載の計算機システム。
8. 複数のノードの処理が所定の順番で実行されるよう定義されたワークフロー定義に従って業務プロセスを遂行するワークフローサービスを提供するサーバ装置と、前記サーバ装置とネットワークを介して接続され、前記サーバ装置から前記ワークフローサービスの提供を受けるクライアント装置と、を備えた計算機システムにおけるワークフロー制御方法であって、
   前記サーバ装置、前記クライアント装置の各々は、プログラムを実行するプロセッサと、前記プロセッサによって実行されるプログラムを格納するメモリと、を備え、
   前記サーバ装置は、
   前記複数のノードのうちの所定のノードを、前記クライアント装置において現に処理が実施されたノードと前記所定のノードとの間に存在するノードに対して、先行して処理を開始可能な先行作業ノードとして定義する先行作業定義情報を有しており、
   前記方法は、
   前記業務プロセスが、所定の入力値に対して承認又は却下が実施されるものである場合、前記サーバ装置が、前記現に処理が実施されたノードから、前記先行作業ノードへの遷移率を、前記現に処理が実施されたノードと前記先行作業ノードとの間に存在するノードにおいて、過去に承認されたときの承認平均値、却下されたときの却下平均値を用いて算出し、算出された前記遷移率に基づいて、前記先行作業ノードの処理を先行して開始するか否かを判定する手順と、
   前記先行作業ノードの処理を先行して開始すると判定された場合、前記先行作業ノードの処理を先行して開始することによって、前記ワークフロー定義に定義されたノードの処理順番を動的に変更する手順と、
   前記変更されたノードの処理順番に従って、前記業務プロセスを遂行する手順と、
   を含むことを特徴とするワークフロー制御方法。
9. 前記判定する手順では、前記サーバ装置は、前記現に処理が実施されたノードと前記先行作業ノードの間に存在するノードが複数ある場合には、これら各ノードの遷移率を算出し、各ノードの遷移率を乗算することによって算出される遷移率に基づいて、前記先行作業ノードの処理を先行して開始するか否かを判定することを特徴とする請求項８に記載のワークフロー制御方法。
10. 前記判定する手順では、前記サーバ装置は、前記現に処理が実施されたノードから、前記先行作業ノードへの遷移率を、前記現に処理が実施されたノードと前記先行作業ノードとの間に存在するノードにおいて、過去に承認された回数、却下された回数を、さらに用いて算出することを特徴とする請求項８に記載のワークフロー制御方法。
11. 前記方法は、さらに、
    前記サーバ装置が、処理順番が変更されていない案件と、処理順番が変更された案件と、を区別可能に表示するためのデータを生成する手順を含むことを特徴とする請求項８に記載のワークフロー制御方法。
12. 複数のノードの処理が所定の順番で実行されるよう定義されたワークフロー定義に従って業務プロセスを遂行するワークフローサービスを、クライアント装置に提供するサーバ装置に用いられるワークフロー制御プログラムであって、
    前記サーバ装置は、
    前記複数のノードのうちの所定のノードを、前記クライアント装置において現に処理が実施されたノードと前記所定のノードとの間に存在するノードに対して、先行して処理を開始可能な先行作業ノードとして定義する先行作業定義テーブルを有しており、
    前記ワークフロー制御プログラムは、
    前記業務プロセスが、所定の入力値に対して承認又は却下が実施されるものである場合、前記現に処理が実施されたノードから、前記先行作業ノードへの遷移率を、前記現に処理が実施されたノードと前記先行作業ノードとの間に存在するノードにおいて、過去に承認されたときの承認平均値、却下されたときの却下平均値を用いて算出し、算出された前記遷移率に基づいて、前記先行作業ノードの処理を先行して開始するか否かを判定する手順と、
    前記先行作業ノードの処理を先行して開始すると判定された場合、前記先行作業ノードの処理を先行して開始することによって、前記ワークフロー定義に定義されたノードの処理順番を動的に変更する手順と、
    前記変更されたノードの処理順番に従って、前記業務プロセスを遂行する手順と、
    を前記サーバ装置に実行させることを特徴とするワークフロー制御プログラム。

Images