(57)【要約】  【課題】  他のビジネスプロセスなどの外部での例外発生時に、事前に定義された対処方法に従って処理を行うワークフロー管理システムの提供。  【解決手段】  案件の作業者が関連付け設定画面より関連付けたい案件を設定する。設定した情報は、案件関連テーブル1040に登録され、監視定義テーブル1030には例外発生を検出する例外発生条件が登録される。例外監視プログラム1003は案件テーブル1010の案件状態と作業テーブル1020の進捗状況の情報を監視し、監視定義テーブル1030の例外発生条件と一致する状態を検出すると、例外対処プログラム1004を実行する。例外対処プログラム1004は、事前に例外発生時の対処方法を定義してある対処方法定義ファイル1050を参照し、その定義にしたがい処理を行う。【選択図】  図1
2005084944.tif 000002
【特許請求の範囲】
【請求項１】
業務における一連の作業順序を管理するビジネスプロセス管理システムにおいて、
複数のビジネスプロセスの案件の間の関連付けの入力を受付ける手段と、
入力された関連付けにより関連づけた案件のうち影響元となる案件の例外発生を検出する手段と、
対処方法定義情報と、
前記例外発生検出手段が例外発生を検出した場合に、あらかじめ対処方法定義情報として格納された，影響先の案件に関する処理を実行する手段とを備えることを特徴とするビジネスプロセス管理システム。
【請求項２】
請求項１記載のビジネスプロセス管理システムであって、
前記案件間の関連付けの入力を受付ける手段は、関連付け設定画面を表示し、
表示した設定画面に基づいて入力された案件の関連付けの内容を案件関連テーブルに格納する記憶装置とを備えることを特徴とするビジネスプロセス管理システム。
【請求項３】
請求項１記載のビジネスプロセス管理システムであって、
前記案件ごとに設定された、例外発生を検出する基準である例外発生条件を格納する監視定義テーブルと、
案件の作業状況に関する案件情報を格納する案件テーブルと、
前記監視定義テーブルに格納された例外発生条件に基づき例外を検出する例外監視手段とを備えることを特徴とするビジネスプロセス管理システム。
【請求項４】
業務における作業順序を管理するビジネスプロセス管理方法において、
予め定義されたビジネスプロセスに基づいて実行される一連の作業の集合である案件と該案件における作業の種別と該作業が現在の作業であるか否かを示す進捗状況の情報とを対応付けて作業テーブルに格納し、
前記案件における作業の種別と、該作業が現在の作業であるときに例外が発生した場合の対処方法の情報とを対応付けて対処方法ファイルに格納し、
前記案件の進捗状況に基づいて他の案件に影響を与える影響元案件について、該影響元案件から影響を受ける案件である影響先案件に関する情報の入力を受付け、
入力された影響先案件に関する情報を前記影響元案件に関する情報と対応付けて案件関連テーブルに格納し、
前記影響元案件において例外が発生した場合に、当該影響元案件に対応する影響先案件の現在の作業の種別に基づいて前記対処方法ファイルに格納した対処方法の情報を読み出し送信することを特徴とするビジネスプロセス管理方法。
【請求項５】
請求項４記載のビジネスプロセス管理方法において、
予め前記案件と当該案件において例外が発生したと判断する基準となる例外発生条件とを対応付けて格納し、
前記作業テーブルに格納した情報が、前記格納した例外発生条件を満たした場合に、例外が発生したと判定することを特徴とするビジネスプロセス管理方法。
【請求項６】
請求項５記載のビジネスプロセス管理方法において、
前記例外発生条件は、前記案件における作業の種別と進捗状況の組を含むことを特徴とするビジネスプロセス管理方法。
【請求項７】
請求項４記載のビジネスプロセス管理方法において、
前記入力の受付けにおいては、前記影響先案件のビジネスプロセス種別の入力をさらに受付け、
入力されたビジネスプロセス種別を前記入力された影響先案件に関する情報と対応付けて格納し、
前記対処方法ファイルは、ビジネスプロセス種別に関する情報をも前記対処方法および前記作業の種別と対応付けて格納し、
前記対処方法の情報の読み出しにおいては前記案件関連テーブルに格納されたビジネスプロセス種別と前記影響先案件の現在の作業の種別に基づいて対処方法の情報を読み出すことを特徴とするビジネスプロセス管理方法。
【請求項８】
業務における作業順序を管理するビジネスプロセス管理システムにおいて、
予め定義されたビジネスプロセスに基づいて実行される一連の作業の集合である案件の進捗状況に基づいて他の案件に影響を与える影響元案件について、該影響元案件から影響を受ける案件である影響先案件に関する情報の入力を受付ける手段と、
入力された影響先案件に関する情報を前記影響元案件に関する情報と対応付けて格納し、案件と該案件における作業の種別と該作業の進捗状況とを対応付けて格納し、前記案件における作業の種別と、該作業が現在の作業であるときに例外が発生した場合の対処方法に関する情報とを対応付けて格納する記憶装置と、
前記影響元案件において例外が発生した場合に、当該影響元案件に対応する影響先案件の現在の作業の種別に基づいて前記格納した対処方法の情報を読み出し送信する手段とを備えることを特徴とするビジネスプロセス管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は業務の一連の作業順序を制御するワークフロー管理システムに関する。
【背景技術】
【０００２】
ワークフロー管理システムとは、業務における処理を作業の流れとしてビジネスプロセスを定義し、それに従って作業通知や作業遷移をワークフローエンジンによって制御するものである。
【０００３】
ワークフロー管理システムにおいて、複数のビジネスプロセスが実行されており、その一つのビジネスプロセスの案件状態によっては、別のビジネスプロセスの案件に影響を及ぼすことがある場合、特許文献１に提案されている方法を用いて、影響を受ける側（影響先）の案件の作業者へ自動的に通知を行うことができる。この特許文献１の方法は、事前に案件の関連付けを設定しておき、影響を与える側（影響元）の案件で例外発生を検出し、影響先の案件の作業者へ自動的に通知を行うしくみである。
【０００４】
【特許文献１】特開2000-67130号公報（図１）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
前記特許文献１記載の技術は、あらかじめ案件の関連付けを定義しておくということから、常に案件同士が関連性をもつことになる。このため、通常は独立して運用されるビジネスプロセスに対し、ある時だけ関連付けを行いたいといった要求には答えられない。また、例外発生時の影響先案件の対処については、通知のみであるため、影響先案件の作業者が判断ミスを犯してしまう可能性を排除できない。
【０００６】
本発明の目的は、前記の問題を解決し、他のビジネスプロセスなどの外部での例外発生時に、事前に定義された対処方法に従って処理を行うワークフロー管理システムを提供することにある。
【課題を解決するための手段】
【０００７】
本発明によれば前記目的は，業務における一連の作業順序を管理するビジネスプロセス管理システムにおいて、複数のビジネスプロセスの案件の間の関連付けの入力を受付ける手段と、入力された関連付けにより関連づけた案件のうち影響元となる案件の例外発生を検出する手段と、対処方法定義情報と、前記例外発生検出手段が例外発生を検出した場合に、あらかじめ対処方法定義情報として格納された，影響先の案件に関する処理を実行する手段とを備えることにより達成される。
【発明の効果】
【０００８】
本発明によれば、ビジネスプロセス管理システムにおいて、例外発生時にあらかじめ定義された対処方法に従って処理を行うことができる。
【０００９】
また、本発明によれば、関連付け設定画面で作業者から複数案件間の関連付けの入力を受付けることにより、案件同士の関連付けを行うことができる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明による一実施形態について図面を用いて説明する。
【００１１】
図１はワークフロー管理システムの構成を示す図であり、ネットワーク1000に接続されたクライアントコンピュータ1100上で実行され、各作業の作業者が必要な業務データを参照・登録するクライアントアプリケーション1001と、ネットワーク1000に接続されたワークフローサーバ1200上で実行され、作業遷移を制御するワークフローエンジン1002と、ワークフローエンジン1002により案件情報が参照・更新される案件テーブル1010および作業情報が参照・更新される作業テーブル1020と、検出する例外情報を登録する監視定義テーブル1030と、案件の関連情報を登録する案件関連テーブル1040と、例外検出時の対処方法を定義してある対処方法定義ファイル1050と、案件テーブル1010と作業テーブル1020と監視定義テーブル1030を参照し例外検出を行う例外監視プログラム1003と、作業テーブル1020と案件関連テーブル1040と対処方法定義ファイル1050を参照し、例外発生時の処理を行う例外対処プログラム1004で構成される。
【００１２】
図２は案件テーブル1010の詳細を説明する図であり、予め定義されたビジネスプロセスに基づいて実行される一連の作業の集合である案件を管理するテーブルである。案件テーブル1010は案件の識別に用いる案件ID2001、案件IDに付けられた案件名2002、案件の開始日時2003、案件の完了日時2004、案件の状態を示すステータス2005のカラムにより構成される。各カラムは案件開始時にワークフローエンジン1002により設定され、図２の行2010のステータス2005に「実行中」がセットされる。案件完了時は図２の行2020のステータス2005に「終了」がセットされ（図２の2020行）、案件が強制終了された場合はステータス2005に「強制終了」がセットされる（図２の2030行）。
【００１３】
図３は作業テーブル1020の詳細を説明する図であり、ビジネスプロセスにしたがって作業者またはアプリケーションにより実行される処理単位である作業を管理するテーブルである。作業テーブル1020は案件の識別に用いる案件ID3001、作業の識別に用いる作業ID3002、作業IDに付けられた作業名3003、作業を実施する作業者名3004、作業の発生日時3005、作業の完了日時3006、作業の状態を示すステータス3007のカラムにより構成される。定義されたビジネスプロセスに従ってワークフローエンジン1002により作業が生成され、図３の作業テーブル1020の行3020に案件ID3001、作業ID3002、作業名3003、作業者名3004、発生日時3005を設定し、ステータス3007を「発生」にセットする。作業完了時は、作業テーブル1020の行3010に示すように完了日時3006を設定し、ステータス3007を「完了」にセットする。このようにステータス3007は、案件の進捗状況を表し、「終了」または「強制終了」の場合、その作業が現在の作業でないことを示し、「発生」の場合、その作業が現在の作業であることを示す。
【００１４】
図4は監視定義テーブル1030のデータ構成図で、影響を与える側（影響元）となる案件の例外発生状況を監視するための情報をもち、監視対象の案件ＩＤ4001、監視対象作業4002および監視対象の案件の進捗状況を示すステータス4003のカラムにより構成される。本テーブルは、これら格納された値により例外発生を検出する基準を示す例外発生条件である。このテーブルの詳しい説明は後述する。
【００１５】
図５は案件関連テーブル1040の詳細を説明する図で、影響を与える側（影響元）の案件と、影響を受ける側（影響先）の案件の関連情報をもつテーブルである。影響元となる案件の情報を示すために、影響元のビジネスプロセス名5001と影響元の案件ID5002、影響先となる案件の情報を示すために、影響先のビジネスプロセス名5003と影響先の案件ID5004で構成される。
【００１６】
図６は案件の関連を設定する画面の詳細を説明する図である。影響元の案件の作業者は、影響先案件設定画面6001により、影響先のビジネスプロセス名と案件IDを設定する。設定された影響元と影響先の関連は案件関連テーブルに登録され、また、影響元の監視対象情報は監視定義テーブル1030に登録される。
【００１７】
図７は、実施例として貸しビル業における２つのビジネスプロセスを説明する図で、以下はこのビジネスプロセスを例として説明を行う。
【００１８】
図７のテナント等の入居手続きプロセス7100は、商談相手の情報を入力する受付作業7110、入居希望の物件が決まった時に物件情報を入力する入居物件入力作業7120、決裁を行う決裁作業7130、契約締結を行う契約締結作業7140のフローで構成される。また、工事プロセス7200は、具体的な工事の内容を入力する工事内容入力作業7210、前作業において入力された内容について対象物件で工事可能かどうか調査する工事内容技術審査7220、決裁を行う決裁作業7230、実際に工事を実施する工事作業7240のフローで構成される。この２つのビジネスプロセスは、入居手続きのみ、工事のみを行うこともあり、ビジネスプロセスとして独立しているが、入居物件決定に伴って内装工事など関連して業務を行うこともある。関連して業務を行う場合は、入居する物件決定時にあらかじめ工事プロセス7200において工事内容技術審査7220まで実施しておくことにより、入居プロセス7100側で契約締結と同時に工事を実施することができ、契約締結から実際に入居するまでの期間短縮が可能となる。
【００１９】
このとき、入居手続きプロセス7100の入居物件入力作業7120で作業者は物件の情報を登録したのち、図６の影響先案件設定画面6001で、影響先となる工事プロセス7200のビジネスプロセス名、案件IDを設定する。この情報は図5の案件関連テーブル1040に登録される。この登録処理と同時に図４の監視定義テーブル1030に検出する例外情報が登録される。検出する例外情報とは、物件変更が起きた場合などに決裁作業7130または契約締結作業7140から入居物件入力7120または受付作業7110へ作業の差戻しが行われたり、案件自体が強制終了した場合などがある。図４の監視定義テーブル1030の4010行は、作業テーブル1020において入居物件作業のステータス3007が「発生」になっていたら例外とすることを意味する。つまり、一度作業が完了してステータスが「完了」になっていたのだが、差戻しにより再び入居物件作業7120が発生した状態を示している。4030行は案件が強制終了された状態を示しており、案件テーブル1010の該当行のステータス2005が「強制終了」になっていたら例外とすることを意味している。
【００２０】
図８は例外監視プログラム1003のフローチャートである。例外監視プログラム1003は、一定のタイミングもしくは任意のタイミングで実行され、ループの始め（ステップ8010）とループ終わり（ステップ8100）までを監視定義テーブル1030の行数分以下の処理を繰り返す。監視定義テーブル1030に登録された情報を1行取得し（ステップ8020）、取得したステータスが「強制終了」であるかの判断を行う（ステップ8030）。
【００２１】
取得したステータスが「強制終了」であれば、案件テーブル1010より案件ID2001がステップ8020で監視定義テーブル1030より取得した案件ID4001と一致する行におけるステータス2005が「強制終了」となっている行を取得（ステップ8050）し、その取得結果の有無を判断する（ステップ8060）。ここで取得できていれば案件が強制終了されたことになるので、影響先となる案件の情報を取得し（ステップ8080）、その情報を例外処理プログラム1004へ渡し、例外処理プログラム1004を実行する（ステップ8090）。
【００２２】
また、ステップ8030において、取得したステータスが「強制終了」以外であれば、作業テーブル1020の案件ID3001、作業名3003がステップ8020で監視定義テーブルより取得した案件ID4001、監視対象作業名4002と一致する行のステータス3007を取得し、ステップ8020で取得したステータス4003と一致するかどうかのチェック行い（ステップ8070）、一致すれば影響先となる案件の情報を取得し（ステップ8080）、その情報を例外処理プログラム1004へ渡し、例外処理プログラム1004を実行する（ステップ8090）。例外処理プログラムについては図１０で説明する。
【００２３】
図９は対処方法定義ファイルの1050の一例を示す図である。対処方法定義ファイル1050は作業段階ごとに例外発生時の処理内容を定義した構造化文書ファイル、例えばXMLファイルで、bpタグ9001の属性としてビジネスプロセスの種別であるビジネスプロセス名を設定し、bpタグ9001の子要素としてruleタグ9002、ruleタグの子要素としてworknameタグ9003とactionタグ9004、notifyタグ9005を用意する。worknameタグ9003は要素内容に作業の種別を識別する作業名を持つ。
【００２４】
actionタグ9004は属性にアクション内容、要素内容にアクションさせる具体的な値を持つ。アクション内容は、「遷移」、「別ビジネスプロセス起動」などである。actionタグ9004の要素内容はアクション内容に応じた引数である。例えば、アクション内容が「遷移」であれば要素内容は作業名であり、アクション内容が「別ビジネスプロセス起動」であれば、要素内容はビジネスプロセス名である。notifyタグ9005は作業者への通知の有無を設定し、要素内容が「yes」であれば作業者へ通知を行う。
【００２５】
たとえば、図９のruleタグ9002の定義した処理内容は、図７の7300の遷移のように、工事プロセス7200において、作業遷移段階が決裁7230のときに例外が発生した場合に、決裁の作業者へ例外発生により案件が処理されたことを通知し、工事内容入力作業7210に作業を遷移するという意味である。
【００２６】
ruleタグ9006は、図７の7400の遷移のように、工事プロセス7200において、工事7240の作業のときに例外が発生した場合には、工事の作業者には例外発生の通知は行わず、別ビジネスプロセスである工事中断プロセスを実行するという意味である。ここで、工事中断プロセスとは、工事の中断処理を定義したビジネスプロセスのことであり、図１１はその一例である。また、今回は対処方法の定義をXMLファイルにて実施する例を示したが、データベースに定義情報を登録することでも実施可能である。
【００２７】
このように対処方法を構造化文書で定義することにより、テキストエディタなどで対処方法の定義を編集可能にできる。また、actionタグの要素内容は、actionタグの属性値に応じて種々の値を取ることができ、要素内容を作業名とすることやビジネスプロセス名にすることができる。
【００２８】
図１０は例外対処プログラム1004のフローチャートある。例外対処プログラム1004は例外監視プログム1003によって呼び出されて実行され、例外監視プログラム1003において取得した処理対象となる影響先ビジネスプロセス名と一致するビジネスプロセスの対処方法定義を対処方法定義ファイル1050から取得する（ステップ10010）。処理対象となる影響先案件の現在の作業遷移段階を取得するために、例外監視プログラム1003から取得した影響先案件IDと作業テーブル1020の案件ID3001が一致する行でステータスが「発生」となっている作業名を現在の作業名として作業テーブル1020より取得する（ステップ10020）。
【００２９】
ステップ9010で取得した対処定義の内容にステップ9020で取得した作業名が定義されているかチェックし（ステップ10030）、定義されている場合は、actionタグとnotifyタグの情報を取得する（ステップ10040）。取得したactionタグの属性値により処理の振り分けを行い（ステップ10050）、属性値が「遷移」の場合はactionタグの要素内容の値に作業を遷移させ（ステップ10060）、属性値が「別ビジネスプロセス起動」の場合はactionタグの要素内容の値のビジネスプロセスを実施する（ステップ10070）。notifyタグの要素内容の値が「yes」であれば（ステップ10080）、作業者へ通知を行い（ステップ10090）、監視定義テーブル1020から影響元案件の情報を削除する（ステップ10100）。
【００３０】
以上のように、例外監視プログラム1003と例外対処プログラム1004により、影響元に例外が発生した場合に、それを検出し対処方法定義ファイル1050の定義に沿った処理を自動に行うことができる。
【００３１】
今回の実施例では例外監視プログラム1003により例外を検出すると、例外対処プログラム1004を自動的に実行していたが、システム管理者の判断などにより、例外対処プログラムを単独で実行することも可能である。また、今回の実施例では２つのビジネスプロセスは影響元と影響先に分かれる従属の関係だったが、案件関連テーブル1040で影響元と影響先を入れ替えたデータを登録しておけば、お互い影響を及ぼすような関連付けも可能である。
【図面の簡単な説明】
【００３２】
【図１】本発明のワークフロー管理システムの構成を表す図である。
【図２】案件テーブルの詳細を説明する図である。
【図３】作業テーブルの詳細を説明する図である。
【図４】監視定義テーブルの詳細を説明する図である。
【図５】案件関連テーブルの詳細を説明する図である。
【図６】案件関連を設定する画面の詳細を説明する図である。
【図７】実施例としての２つのビジネスプロセスを表した図である。
【図８】例外監視プログラムの動作を説明するフローチャートである。
【図９】対処方法定義ファイルの詳細を説明する図である。
【図１０】例外対処プログラムの動作を説明するフローチャートである。
【図１１】例外対処時に呼び出されるビジネスプロセスの例を示した図である。
【符号の説明】
【００３３】
1000  ネットワーク、1001  クライアントアプリケーション、1002  ワークフローエンジン、1003  例外監視プログラム、1004  例外対処プログラム、1010  案件テーブル、1020  作業テーブル、1030  監視定義テーブル、1040  案件関連テーブル、1050  対処方法定義ファイル、1100  クライアントコンピュータ、1200  ワークフローサーバ
【図１】
2005084944.tif 000003
【図２】
2005084944.tif 000004
【図３】
2005084944.tif 000005
【図４】
2005084944.tif 000006
【図５】
2005084944.tif 000007
【図６】
2005084944.tif 000008
【図７】
2005084944.tif 000009
【図８】
2005084944.tif 000010
【図９】
2005084944.tif 000011
【図１０】
2005084944.tif 000012
【図１１】
2005084944.tif 000013