(57)【特許請求の範囲】
【請求項１】
複数の関連する業務プロセスを含むビジネス手続きを実行するための複数のクライアント計算機が接続されたワークフロー管理システムの制御方法において、
業務プロセスに関する属性情報を格納するアプリケーションデータベースと、
業務プロセス毎に、業務プロセスの開始、または終了の判定条件と、これらの判定に使うアプリケーションデータベースの属性とを記述した業務状態定義表とを備え、
前記業務状態定義表を参照し、業務プロセスの開始条件と前記業務プロセスとは異なる他の業務プロセスの開始条件とが同じであり、該開始条件を満たすと当該業務プロセスと当該他の業務プロセスとの並行実行を許可するものであって、
例外処理手段が、
前記業務状態定義表を参照して、同じ開始条件を有する業務プロセスであって、前記クライアント計算機で並行に実行されることが可能な関連する業務プロセスについて、前記開始条件の属性を、例外状態を検出するための属性として設定し、
例外ステータスウオッチャが、
前記予め例外処理手段により決定された例外状態を検出するための属性を基に前記アプリケーションデータベースに格納された業務プロセスの属性を参照し、関連する業務プロセスについての属性の変更の有無を検出し、変更があった場合、前記業務状態定義表を参照して、検出された属性を開始条件として有する複数の業務プロセスを選択し、また、前記選択された業務プロセスの終了条件を開始条件とする業務プロセスを選択し、これら選択した業務プロセスをユーザ検索部へ出力し、
ユーザ検索部が、
例外ステータスウオッチャから出力された前記業務プロセスを担当するユーザを、業務と業務を担当するユーザとが登録されている作業データベースから選択し、
ノーティファイアが、
ユーザ検索部により選択されたユーザが関連する業務プロセスを完了するのを避けることができるよう関連する業務プロセスで例外状態が発生した前記選択されたユーザに対応するクライアント計算機に例外状態を通知することを特徴とするワークフロー管理システム制御方法。
【請求項２】
請求項１記載のワークフロー管理システム制御方法において、前記例外状態は、業務プロセスの中断であることを特徴とするワークフロー管理システム制御方法。
【請求項３】
複数の関連する業務プロセスを含むビジネス手続きを実行するための複数のクライアント計算機が接続されたワークフロー管理システムにおいて、
業務プロセスに関する属性情報を格納するアプリケーションデータベースと、
業務プロセス毎に、業務プロセスの開始、または終了の判定条件と、これらの判定に使うアプリケーションデータベースの属性とを記述した業務状態定義表とを備え、
前記業務状態定義表を参照し、業務プロセスの開始条件と前記業務プロセスとは異なる他の業務プロセスの開始条件とが同じであり、該開始条件を満たすと当該業務プロセスと当該他の業務プロセスとの並行実行を許可するものであって、
前記業務状態定義表を参照して、同じ開始条件を有する業務プロセスであって、前記クライアント計算機で並行に実行されることが可能な関連する業務プロセスについて、前記開始条件の属性を、例外状態を検出するための属性として設定する例外処理手段と、
前記予め例外処理手段により決定された例外状態を検出するための属性を基に前記アプリケーションデータベースに格納された業務プロセスの属性を参照し、関連する業務プロセスについての属性の変更の有無を検出し、変更があった場合、前記業務状態定義表を参照して、検出された属性を開始条件として有する複数の業務プロセスを選択し、また、前記選択された業務プロセスの終了条件を開始条件とする業務プロセスを選択し、これら選択した業務プロセスをユーザ検索部へ出力する例外ステータスウオッチャと、
例外ステータスウオッチャから出力された前記業務プロセスを担当するユーザを、業務と業務を担当するユーザとが登録されている作業データベースから選択するユーザ検索部と、
ユーザ検索部により選択されたユーザが関連する業務プロセスを完了するのを避けることができるよう関連する業務プロセスで例外状態が発生した前記選択されたユーザに対応するクライアント計算機に例外状態を通知するノーティファイアとを備えることを特徴とするワークフロー管理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、業務プログラムの処理順序を制御するワークフロー管理システム制御方法及びワークフロー管理システムに関する。
【０００２】
【従来の技術】
従来からグループで行う事務作業の効率化のために計算機を用いた様々な方法が提案されている。その１つとして、伝票等の書類を電子化し、その電子化した書類を予め設定した規則に従ってユーザに回覧するワークフロー管理システムが知られている。この種のワークフロー管理システムの概念については、例えば、秋藤俊介、伊勢広敏、馬嶋宏著、「ワークフロー管理システムの動向」  システム／制御／情報、第４０巻、第５号、第２０３頁〜第２０８頁（平成８年５月）に記載されている。そして、通常、ワークフロー管理システムは、自業務の手順である業務フロー（ワークフロー）を、アイコン、アロー等のグラフィカル・ユーザ・インタフェースを用いて作成し、ワークフロー・エンジンというプログラムが、その業務フローを解釈し、ユーザに電子化した文書の処理を指示するものである。
【０００３】
ワークフロー管理システムに関する従来技術として、例えば、特開平８―３６５３８号公報等に記載されている技術が知られている。この従来技術は、予め定められたワークフローに基づいて、ネットワークを介して接続された多数の情報処理装置が、それぞれ個別に実行される個々の業務の連携管理を行うワークフロー管理システムに関するものであり、異なる担当者が割り付けられた互いに関連性を有する複数の業務の実行のために、その業務の内容についての指示及び問い合わせに伴なって各々の担当者の間で行われるコミュニケーション処理を統一管理するコミュニケーション管理手段を備えて構成されている。
【０００４】
そして、コミュニケーション管理手段は、第１の業務が割り付けられた第１の担当者から他の第２の業務の内容に対する指示及び問い合わせの操作が行われたとき、第２の業務が割り付けられた第２の担当者を自動的に検索した後、第１及び第２の担当者間のコミュニケーション処理を開始するものである。
【０００５】
【発明が解決しようとする課題】
一般に、業務プロセスは、１つずつ実行されるのではなく、全体の業務時間を短縮するために、複数の互いに関係のある業務プロセスが並行して実施される場合が多い。例えば、商品の受注から引き渡しまでの業務の流れにおいては、引合の終了後、見積があり、その後、生産に至るが、生産を早く開始するために、引合の途中で見積を開始する等が現実にはあり得る。
【０００６】
前述の従来技術は、互いに依存関係のある複数の業務プロセスが並行して進行している場合で、１つの業務プロセスが中止になったときに、中止になった業務プロセスの担当者が、その業務の中止を、他の業務プロセスを実施しているユーザに知らせなければ、中止になったことがわからず、本来必要のない残りの業務プロセスを実施してしまうという問題点を有している。
【０００７】
本発明の目的は、前記従来技術の問題点を解決し、互いに依存関係のある複数の業務プロセスを並行して進行させている場合に、１つの業務プロセスが中止になったとき、他の業務プロセスを実施している適切なユーザに業務の中断を通知することを可能にしたワークフロー管理システム制御方法及びワークフロー管理システムを提供することにある。
【０００８】
【課題を解決するための手段】
本発明によれば前記目的は、複数の関連する業務プロセスを含むビジネス手続きを実行するための複数のクライアント計算機が接続されたワークフロー管理システムの制御方法において、業務プロセスに関する属性情報を格納するアプリケーションデータベースと、業務プロセス毎に、業務プロセスの開始、または終了の判定条件と、これらの判定に使うアプリケーションデータベースの属性とを記述した業務状態定義表とを備え、前記業務状態定義表を参照し、業務プロセスの開始条件と前記業務プロセスとは異なる他の業務プロセスの開始条件とが同じであり、該開始条件を満たすと当該業務プロセスと当該他の業務プロセスとの並行実行を許可するものであって、例外処理手段が、前記業務状態定義表を参照して、同じ開始条件を有する業務プロセスであって、前記クライアント計算機で並行に実行されることが可能な関連する業務プロセスについて、前記開始条件の属性を、例外状態を検出するための属性として設定し、例外ステータスウオッチャが、前記予め例外処理手段により決定された例外状態を検出するための属性を基に前記アプリケーションデータベースに格納された業務プロセスの属性を参照し、関連する業務プロセスについての属性の変更の有無を検出し、変更があった場合、前記業務状態定義表を参照して、検出された属性を開始条件として有する複数の業務プロセスを選択し、また、前記選択された業務プロセスの終了条件を開始条件とする業務プロセスを選択し、これら選択した業務プロセスをユーザ検索部へ出力し、ユーザ検索部が、例外ステータスウオッチャから出力された前記業務プロセスを担当するユーザを、業務と業務を担当するユーザとが登録されている作業データベースから選択し、ノーティファイアが、ユーザ検索部により選択されたユーザが関連する業務プロセスを完了するのを避けることができるよう関連する業務プロセスで例外状態が発生した前記選択されたユーザに対応するクライアント計算機に例外状態を通知することにより達成される。
【０００９】
また、前記目的は、複数の関連する業務プロセスを含むビジネス手続きを実行するための複数のクライアント計算機が接続されたワークフロー管理システムにおいて、業務プロセスに関する属性情報を格納するアプリケーションデータベースと、業務プロセス毎に、業務プロセスの開始、または終了の判定条件と、これらの判定に使うアプリケーションデータベースの属性とを記述した業務状態定義表とを備え、前記業務状態定義表を参照し、業務プロセスの開始条件と前記業務プロセスとは異なる他の業務プロセスの開始条件とが同じであり、該開始条件を満たすと当該業務プロセスと当該他の業務プロセスとの並行実行を許可するものであって、前記業務状態定義表を参照して、同じ開始条件を有する業務プロセスであって、前記クライアント計算機で並行に実行されることが可能な関連する業務プロセスについて、前記開始条件の属性を、例外状態を検出するための属性として設定する例外処理手段と、前記予め例外処理手段により決定された例外状態を検出するための属性を基に前記アプリケーションデータベースに格納された業務プロセスの属性を参照し、関連する業務プロセスについての属性の変更の有無を検出し、変更があった場合、前記業務状態定義表を参照して、検出された属性を開始条件として有する複数の業務プロセスを選択し、また、前記選択された業務プロセスの終了条件を開始条件とする業務プロセスを選択し、これら選択した業務プロセスをユーザ検索部へ出力する例外ステータスウオッチャと、例外ステータスウオッチャから出力された前記業務プロセスを担当するユーザを、業務と業務を担当するユーザとが登録されている作業データベースから選択するユーザ検索部と、ユーザ検索部により選択されたユーザが関連する業務プロセスを完了するのを避けることができるよう関連する業務プロセスで例外状態が発生した前記選択されたユーザに対応するクライアント計算機に例外状態を通知するノーティファイアとを備えることにより達成される。
【００１２】
【発明の実施の形態】
以下、本発明によるワークフロー管理システム制御方法及びワークフロー管理システムの一実施形態を図面により詳細に説明する。
【００１３】
図１は本発明の第１の実施形態によるワークフロー管理システムの構成を示すブロック図、図２はアプリケーションデータベースの詳細を説明する図、図３は業務状態定義表の詳細を説明する図、図４はアクション部門定義表の詳細を説明する図、図５は組織構造データベースの詳細を説明する図、図６は担当振り分けルールの詳細を説明する図、図７はステータスウォッチャの動作を説明するフローチャート、図８はワークフローエンジンの動作を説明するフローチャート、図９はリソースセレクタの動作を説明するフローチャートである。図１〜図６において、１０は業務状態定義表、２０はアクション−部門定義表、３０は組織構造データベース、４０は担当振り分けルール、５０は作業データベース、６０はクライアントアプリケーション、７０はサーバアプリケーション、８０はアプリケーションデータデース、９０はステータスウオッチャ、１００はワークフローエンジン、１１０はリソースセレクタ、１２０はノーティファイア、１３０はインボックス、１４０はユーザである。
【００１４】
本発明の第１の実施形態によるワークフロー管理システムは、ワークフロー管理システムのデータベースとは別のアプリケーションデータベースに記憶したデータを参照し、既存のアプリケーション・プログラムをワークフロー管理システムで制御するところに特徴を有する。
【００１５】
図１に示す本発明の第１の実施形態によるワークフロー管理システムは、業務の状態と属性の対応を記述した業務状態定義表１０と、業務状態及びアクションと業務処理単位及び部門とを対応づけるアクション−部門定義表２０と、部門と組織の構造とを対応づける組織構造データベース３０と、部門と業務処理単位の組と職位と振り分け条件と担当者との対応を付ける担当振り分けルール４０と、ワークフロー管理システムのデータを記憶する作業データベース５０と、クライアントコンピュータで実行されるクライアントアプリケーション６０と、クライアントアプリケーション６０と通信し、サーバコンピュータで実行されるサーバアプリケーション７０と、サーバアプリケーション７０のデータを記憶するアプリケーションデータデース（ＡＰＤＢ）８０と、アプリケーションデータベース８０の状態変更を監視するステータスウオッチャ（ＳＷ）９０と、ステータスウオッチャ９０からの出力と作業データベース５０に記憶したデータとを参照し、作業データベースを変更するワークフローエンジン（ＷＥ）１００と、ワークフローエンジン１００からの出力を受け作業データベース５０とアクション−部門定義表２０と組織構造データベース３０とを参照し、ユーザを選択するリソースセレクタ（ＲＳ）１１０と、リソースセレクタ１１０で選択されたユーザへ通知を送るノーティファイア１２０と、リソースセレクタ１２０からの通知を記憶するインボックス１３０とにより構成されている。そして、ユーザ１４０は、インボックス１３０に記憶した通知を参照し、クライアントアプリケーションを実行する。
【００１６】
アプリケーションデータベース８０は、その詳細を図２に示すように、それぞれ商談番号、見積開始、見積終了を表わす属性情報２０１０〜２０３０を備えて構成され、商談番号に対応したレコード２１００が記録されている。
【００１７】
業務状態定義表１０は、その詳細を図３に示すように、それぞれ業務状態名、項目条件、商談番号、見積開始、見積終了を表わす属性情報３０１０〜３０５０を備えて構成され、業務状態名に対応したレコード３１００と３１１０とが記録されている。
【００１８】
アクション−部門定義表２０は、その詳細を図４に示すように、それぞれ業務状態名、アクション名、業務処理単位、部門ノードを表わす属性情報４０１０〜４０４０を備えて構成され、業務状態名に対応したレコード４１００と４１１０とが記録されている。
【００１９】
組織構造データベース３０は、その詳細を図５に示すように、それぞれ部門ノードと組織構成とを表わす属性情報５０１０と５０２０とを備えて構成され、部門ノードに対応したレコード５１００と５１１０とが記録されている。ここで、組織の構造は、図５に示す通り木構造で表現される。
【００２０】
担当振り分けルール４０は、その詳細を図６に示すように、それぞれ部門ノードの担当振り分けルール６０１０と６０２０とによりなり、部門ノードの担当振り分けルール６０１０には、業務処理単位を示す領域６０３０があり、この領域６０３０には、それぞれ「振り分け条件」、「担当者名」の属性情報６０６０、６０７０と、「振り分け条件」によるレコード６０４０、６０５０が記録されている。
【００２１】
次に、前述のように構成される本発明の第１の実施形態によるワークフロー管理システムの処理動作を説明する。図１に示すワークフロー管理システムにおける処理は、別々のプログラムであり、それぞれが並行して動作するステータスウオッチャ９０、ワークフローエンジン１００、リソースセレクタ１１０及びノーティファイア１２０によって行われる。これらのプログラムは、プロセス実行とプロセス間通信等の機能とを用いて容易に実現することができる。
【００２２】
まず、図７に示すフローを参照してステータスウオッチャ９０の処理動作を説明する。
【００２３】
（１）ステータスウオッチャ９０は、処理を開始すると、業務状態定義表１０に記憶された各属性名を入力し、監視するアプリケーションデータベース８０の属性を設定する（ステップ７０００〜７０２０）。
【００２４】
（２）アプリケーションデータベース８０に設定した属性の変更の有無を判定し、変更があったとき、そのレコードの業務状態名と項目条件とをワークフローエンジン１００へ出力する（ステップ７０３０、７０４０）。
【００２５】
（３）ステップ７０３０で、アプリケーションデータベース８０に設定した属性の変更がない場合、及び、ステップ７０４０の処理後、ステップ７０２０へ戻って、ステップ７０２０〜７０４０の処理を繰り返す。
【００２６】
前述の処理において、業務状態定義表１０に記憶したデータは、図３に示すようなものであり、属性である商談番号、見積開始、見積終了の属性が監視対象とされている。この例の場合、ワークフローエンジン１００へ出力するデータは、属性として商談番号が入力であり、見積開始が入力されていないとき、業務状態が「引合中」の開始であり、見積開始が入力されたとき、業務状態が「引合中」の終了とする。また、属性として商談番号が入力であり、見積終了が入力されていないとき、業務状態が「見積中」の開始であり、見積終了が入力されたとき、業務状態が「見積中」の終了とする。
【００２７】
また、アプリケーションデータベース８０には、図２に示すように、商談番号が「００１」で見積開始と見積終了とが未入力であるレコード２１００が記憶されている。このレコードは、サーバアプリケーション７０が書き込んだものである。ここでは、商談番号が入力されており、見積開始が未入力なので、ステータスウオッチャ９０は、ステップ７０４０の処理でワークフローエンジン１００に業務状態の「引合中」が開始であることを出力する。
【００２８】
次に、図８に示すフローを参照してワークフローエンジン１００の処理動作を説明する。
【００２９】
（１）ワークフローエンジン１００は、前述のステップ７０４０の処理による変更通知により処理を開始し、アクション−部門定義表２０に記憶された全てのレコードを入力する（ステップ８０００、８０１０）。
【００３０】
（２）ステータスウオッチャ９０からの入力の有無を判定し、入力がない場合、この判定処理を繰り返し、入力があった場合、ステータスウオッチャ９０からの入力とステップ８０１０で入力したアクション−部門定義表２０に記憶された全てのレコードとを比較して、行うべき処理の判定を行う（ステップ８０２０、８０３０）。
【００３１】
（３）ステップ８０３０で判定した行うべき処理に、状態を変更するオブジェクトが存在するか否かをチェックし、状態を変更するオブジェクトが存在しない場合、作業データベース５０に新たに作業用のデータを記憶するオブジェクトを作成する（ステップ８０４０、８０５０）。
【００３２】
（４）ステップ８０５０の処理後、あるいは、ステップ８０４０で、すでにオブジェクトが存在し、業務状態が変更になっている場合、作業デーテベース５０に作成したオブジェクトの状態を変更し、アクション名、業務処理単位、部門ノードをリソースセレクタ１１０へ出力し、ステップ８０２０に戻ってステップ８０２０からの処理を繰り返す（ステップ８０６０、８０７０）。
【００３３】
前述した処理において、ステップ８０１０で、アクション−部門定義２０を入力し、ステータスウオッチャからの入力があったので、ステップ８０５０で、作業データベース５０にオブジェクトを生成し、ステップ８０６０で、データを設定し、ステップ８０７０でリソースセレクタ１１０へ出力する。ここでは、業務状態が「引合中」なので、ステップ８０７０でアクション名「引合書作成」、業務処理単位「引合」、及び、部門ノード「営業」がリソースセレクタへ出力されることになる。
【００３４】
次に、図９に示すフローを参照してリソースセレクタ１１０の処理動作を説明する。
【００３５】
（１）リソースセレクタ１１０は、前述のステップ８０７０のワークフローエンジン１００の処理での通知が行われたとき処理を開始し、まず、組織構造データベース３０に記憶された全てのレコードを入力すると共に、担当振り分けルール４０に記憶した全てのレコードを入力する（ステップ９０００〜９０２０）。
【００３６】
（２）ワークフローエンジン１００から入力したアクション名、業務処理単位、部門ノードと、作業データベース５０のデータとを比較し、ユーザを選択して、ノーティファイア１２０へ該当するユーザとアプリケーション名とを出力して処理を終了する（ステップ９０３０〜９０５０）。
【００３７】
前述の処理において、リソースセレクタ１１０は、ステップ９０１０で、図５に示す組織構造データベースを入力し、ステップ９０２０で、担当振り分けルールを入力し、ステップ９０３０で、ユーザの選択を行う。ここでは、ワークフローエンジンからの入力が、業務処理単位「引合」と部門ノード「営業」となっているので、ステップ９０３０で作業データベースに記憶された他のデータを参照し、業務組織データベースの「直販営業部」の「営業１課」と、担当振り分けルールで、部門ノード「営業１課」で業務処理単位「引合」の担当者名「Ａ」を選択し、ステップ９０４０で、これらの情報とアプリケーション名「引き合い書作成」とを出力することになる。
【００３８】
ノーティファイア１２０は、ステータスウオッチャ１１０から入力されたユーザのインボックスにアプリケーション名を通知する。ここでは、担当者「Ａ」のインボックスにアプリケーション名「引き合い書作成」を通知する。
【００３９】
図１に示す本発明の第１の実施形態によるワークフロー管理システムは、前述した処理を外部から停止の命令が入力されるまで、それぞれのプログラムが繰り返し実行される。これにより、ユーザ１４０は、自分が担当している業務に関連する他の業務の進行、変更等の状況を知ることができる。
【００４０】
前述した本発明の第１の実施形態によれば、ワークフロー管理システムのデータベースとは別のアプリケーションデータベースに記憶したデータを参照して処理を行っているので、既存のアプリケーション・プログラムを大幅に変更することなく、ワークフロー管理システムとの連携を実現することができる。
【００４１】
前述したステータスウオッチャ９０の処理において、ステップ７０３０でアプリケーションデータベース８０に変更がないとき、ステップ７０２０に戻り、業務状態定義表１０に記憶されたデータを入力するとしたが、ステップ７０２０へ戻らずステップ７０３０を繰り返してもよい。
【００４２】
また、前述した本発明の第１の実施形態において、ステータスウオッチャ９０は、図７示すようにアプリケーションデータベース８０を参照するループを繰り返すとして説明したが、本発明は、アプリケーションデータベースに利用するデータベースマネージメントシステムの機能を用いて、アプリケーションデータベース８０から変更の通知を受け取るようにしてもよい。
【００４３】
図１０はアプリケーションデータベース８０から変更の通知を受け取る場合のステータスウオッチャ９０及びアプリケーションデータベース８０の処理動作を説明するフローチャートであり、以下、これについて説明する。
【００４４】
（１）ステータスウオッチャ９０は、処理を開始すると、業務状態定義表１０に記憶された各属性名を入力し、監視するアプリケーションデータベース８０の属性をアプリケーションデータベースへ８０へ出力して処理を終了する（ステップ１００００〜１００３０）。
【００４５】
（２）アプリケーションデータベース８０は、処理を開始すると、ステータスウオッチャ９０からの設定属性を入力し、設定した属性の変更の有無を判定する（ステップ１０１００、１０１１０、１０１２０）。
【００４６】
（３）設定した属性の変更の有無の判定において、変更があった場合、そのレコードの業務状態名と項目条件とをワークフローエンジン１００へ出力する（ステップ１０１３０、１０１４０）。
【００４７】
（４）ステップ１０１４０の処理後、または、ステップ１０１３０で、設定した属性の変更がないと判定した場合、ステップ１０１２０へ戻ってステップ１０１２０から１０１４０の処理を繰り返す。
【００４８】
前述した図１０に示す処理を用いる本発明の実施形態は、アプリケーションデータベース８０が、データベースの変更の有無を検出する機能を持ったデータベースマネージメントシステムで構成されている必要があるが、一般に、外部のプログラム、ここではステータスウオッチャ９０が変更を検出するループを繰り返すよりも、データベースシステムの機能を用いたほうが処理性能が高いので、短時間で効率よくアプリケーションデータベース８０のデータの変更を検出することができる。
【００４９】
前述した本発明の第１の実施形態は、互いに関係する複数の業務が存在し、それらが並行して実行されている場合、１つの業務の処理が途中で中断された等の例外的な処理が生起したとき、他の業務を実行している者が、その中断を知らずに無駄な処理を進めてしまう可能性が高い。本発明は、このような無駄な処理を行わせることのないように、適切にユーザに業務処理の中断を通知するようにすることができる。
【００５０】
図１１は本発明の第２の実施形態によるワークフロー管理システムの構成を示すブロック図、図１２は例外ステータスウオッチャの動作を説明するフローチャート、図１３は例外条件の生成を説明するための業務状態定義表を示す図、図１４は例外条件の生成の他の例を説明するための業務状態定義表を示す図である。図１１において、１１０００は例外処理部、１１０１０は例外ステータスウオッチャ、１１０２０はユーザ検索部であり、他の符号は図１の場合と同一である。
【００５１】
図１１に示す本発明の第２の実施形態によるワークフロー管理システムは、業務処理の中断をユーザに通知することを可能にしたもので、図１に説明した本発明の第１の実施形態に対して、業務状態定義表１０から例外状態の属性を生成する例外処理部１１０００と、例外処理部１１０００が出力した属性を入力し、アプリケーションデータベース８０の状態変更を監視する例外ステータスウオッチャ１１０１０と、ステータスウオッチャ１１０１０からの出力を受けて、適切なユーザを選択し、ノーティファイア１２０へ出力するユーザ検索部１１０２０とを加えて構成されている。
【００５２】
まず、図１３を参照して例外処理部１１０００で生成する属性の選択方法の処理を説明する。
【００５３】
図１３に示す例では、「引合中」と「見積中」との２つの業務状態があり、それぞれの開始条件が商談番号の入力となり同一である。この場合、いずれか一方が開始されたときには、他方も開始されている可能性が高い。従って、一方を中止したとき、他方も中止される可能性が高く、それをユーザに通知すべきである。このような場合、処理を適切に実行させるために、業務状態定義表１０内に開始条件が同一の業務状態があるとき、その開始条件の属性として例外処理を設定条件とすることとする。
【００５４】
ここでは、例外処理部１１０００が、すでに図１３で説明した処理を行い、属性として「商談番号」を生成しているものとして、図１２に示すフローを参照して、例外ステータスウオッチャ１１０１０の処理を説明する。
【００５５】
（１）例外ステータスウオッチャ１１０１０は、処理を開始すると、前述で説明した例外処理部１１０００が設定した図示しない例外定義に記憶された各属性名を入力し、監視するアプリケーションデータベース８０の属性を設定する（ステップ１２０００〜１２０２０）。
【００５６】
（２）アプリケーションデータベース８０に設定した属性の変更の有無を判定し、変更があった場合、業務状態名をユーザ検索部１１０２０へ出力する（ステップ１２０３０、１２０４０）。
【００５７】
（３）ステップ１２０３０で、変更がないと判定した場合、または、ステップ１２０４０の処理後、ステップ１２０２０へ戻り、ステップ１２０２０〜１２０４０の処理を繰り返す。
【００５８】
前述のステップ１２０４０で通知を受けたユーザ検索部１１０２０は、作業データベース５０を参照し、業務状態の業務を行っているユーザを選択して、ノーティファイア１２０にそのユーザに中断が生じたことを出力する。
【００５９】
例えば、アプリケーションデータベース８０のレコード２１００で、商談番号が入力され、「引合中」と「見積中」との業務が、それぞれ前述した処理を開始し、「引合中」の処理の途中で、外部的な要因でユーザ１４０がクライアントアプリケーション６０を通じて、サーバアプリケーション７０を操作し、商談番号を削除したとする。このとき、例外ステータスウオッチャ１１０１０は、属性「商談番号」が変更になったので、ユーザ検索部１１０２０へ変更された状態名「引合中」と「見積中」とを出力する。
【００６０】
これにより、ユーザ検索部１１０２０は、作業データベース５０を参照し、業務状態の業務を行っているユーザ、つまり、「引合中」と「見積中」とを実行しているユーザを選択し、ノーティファイア１２０にそのユーザに中断が生じたことを出力する。
【００６１】
前述した本発明の第２の実施形態は、開始条件が同一な場合の単純な例について説明したが、１つの例外処理が引き金となって連鎖的に処理の中断を通知したい場合がある。このような場合、例外ステータスウオッチャ１１０１０は、業務状態定義表１０と例外処理部１１０００で生成された属性とを入力として、終了条件と開始条件とが同一の業務状態を出力するようにしてもよい。
【００６２】
この場合の例外条件の生成を説明するための業務状態定義表１０が図１４に示されており、以下、図１４を参照して、例外条件の生成を説明する。
【００６３】
図１４に示す業務状態定義表１０には、「引合中」と「見積中」と「手配中」との３つの業務状態があり、「引合中」の終了条件と、「手配中」の開始条件とが見積開始の入力で同一である。この場合、「引合中」が終了した後に、「手配中」が開始される。「見積中」が中止になった場合、それが原因で「引合中」を中止する可能性が高く、それがまた「手配中」を中止にすることを必要とさせることになる。
【００６４】
従って、業務状態定義表１０に開始条件と終了条件とが同一の業務状態があるとき、例外ステータスウオッチャ１１０１０は、開始状態が同一な業務状態だけではなく、終了条件と開始条件とが同一の業務状態も出力するとよい。図１４の例では、「引合中」と「見積中」とに加えて「手配中」も、例外ステータスウオッチャ１１０１０の処理におけるステップ１２０４０で出力の対象とする。
【００６５】
例えば、アプリケーションデータベース８０のレコード２１００で、商談番号が入力され、「引合中」と「見積中」と「手配中」との３つの業務が、それぞれ前述した開始したとし、「見積中」の処理の途中で、外部的な要因でユーザ１４０がクライアントアプリケーション６０を通じて、サーバアプリケーション７０を操作し、商談番号を削除したとする。
【００６６】
この場合、ステータスウオッチャ１１０１０は、属性「商談番号」が変更になったので、ユーザ検索部１１０２０へ変更された状態名「引合中」と「見積中」とを出力し、さらに、「引合中」の終了条件と「手配中」の入力条件とが同一なので「手配中」をも出力する。
【００６７】
前述した実施形態は、直接的には関係ないが、他の業務を介して間接的に関連する業務にも処理の中断を通知することができる。
【００６８】
図１５は本発明の第３の実施形態によるワークフロー管理システムの構成を示すブロック図、図１６は部門内フロー定義の詳細な例を説明する図、図１７は担当振り分けルールの詳細を説明する図、図１８はリソースセレクタＡの動作を説明するフローチャート、図１９はサブプロセス実行部の動作を説明するフローチャート、図２０はワークフローエンジンＢの動作を説明するフローチャート、図２１はリソースセレクタＢの動作を説明するフローチャートである。図１５において、１５０００は部門内フロー定義、１５０１０は担当振り分けルール、１５０２０はリソースセレクタＡ、１５０３０はサブプロセス実行部、１５０４０はワークフローエンジンＢ、１５０５０はリソースセレクタＢであり、他の符号は図１、図１１の場合と同一である。
【００６９】
本発明の第３の実施形態によるワークフロー管理システムは、事前に手順が決まらない業務の処理と予め定めた手順がある業務の処理との２種類を使い分けることのできるものであり、図１１により説明した実施形態に対して、部門ノード内の業務の処理順序を記述した部門内フロー定義１５０００と、部門と業務処理単位の組と職位と振り分け条件と担当者の対応をづける担当振り分けルール１５０１０と、ワークフローエンジン１００からの出力を受け作業データベース５０とアクション部門定義表２０と組織構造データベース３０を参照し、サブプロセスを選択するリソースセレクタＡ１５０２０と、作業データベース５０にサブプロセスのオブジェクトを生成するサブプロセス実行部１５０３０と、部門内フロー定義１５０００を参照し、作業データベース５０のオブジェクトをリソースセレクタＢに出力するワークフローエンジンＢ１５０４０と、ワークフローエンジンＢ１５０４０からの出力を受け、作業データベース５０と担当振り分けルール１５０１０とを参照し、ユーザを選択するリソースセレクタＢ１５０５０とを設けて構成される。
【００７０】
図１６に示す部門内フロー定義の詳細な例を示す図において、１６０００と１６０１０とは、それぞれ営業１課と営業２課との部門内フローであり、業務処理単位が「見積」の業務の手順を記憶する領域１６０２０を備えている。この領域１６０２０には、ユーザの職位が担当、主任、課長であることを示すアイコン１６０３０、１６０４０、１６０５０が矢印で接続されたフローが格納されている。そして、このフローは、矢印の順序でアイコンの職位をもつユーザが処理を行うことを示している。
【００７１】
図１７に示す担当振り分けルールの詳細を示す図において、１７０００と１７０１０とは、それぞれ営業１課と営業２課の担当振り分けルールであり、業務処理単位が「見積」の担当振り分けルールを記憶する領域１７０２０を備えている。この領域１７０２０には、職位、振り分け条件、担当者の属性１７０３０、１７０４０、１７０５０と、レコード１７０６０とが格納されている。
【００７２】
次に、図１８〜図２１に示すフローを参照して、図１５における各処理部の動作を詳細に説明する。なお、ステータスウオッチャ９０、ワークフローエンジンＡ１００、例外処理部１１０００、例外ステータスウオッチャ１１０１０、ユーザ検索部１１０２０の動作は前述した実施形態の場合と同一であるので、これらの動作についての説明は省略する。
【００７３】
まず、図１８に示すフローを参照して、リソースセレクタＡ１５０２０の動作を説明する。
【００７４】
（１）リソースセレクタＡ１５０２０は、処理を開始すると、組織構造データベース３０に記憶された全てのレコードを入力する（ステップ１８０００、１８０１０）。
【００７５】
（２）そして、リソースセレクタＡ１５０２０は、ワークフローエンジン１００から入力したアクション名、業務処理単位、部門ノードと、作業データベース５０のデータとを比較し、部門ノードの部門内フロー定義を選択し、サブプロセス実行部１５０３０へ実行する部門内フロー定義を出力して処理を終了する（ステップ１８２０〜１８０４０）。
【００７６】
前述において、ワークフローエンジン１００は、前述で説明した第１の実施形態の場合と同様に動作し、リソースセレクタＡ１５０２０は、部門ノードが「営業１課」で、業務処理単位を「引合」、アクション名「引合書作成」を出力し、リソースセレクタＡ１５０２０がこれを入力したとする。
【００７７】
この結果、リソースセレクタＡ１５０２０は、ステップ１８０２０で前述のデータと作業データベース５０のデータとを比較し、部門内フロー定義１５００から、部門ノードが「営業１課」で業務処理単位が「引合」の部門内フロー定義１６０２０を選択し、これらをサブプロセス実行部１５０３０へ出力することになる。
【００７８】
図１９のフローに示すように、サブプロセス実行部１５０３０は、処理を開始する（ステップ１９０００）と、作業データベース５０にサブプロセスの実行に必要なデータを記憶するオブジェクトを生成して、その処理を終了する（ステップ１９０１０、１９０２０）。
【００７９】
ここでは、部門内フロー定義１６０２０がサブプロセスであり、このサブプロセスの実行に必要なデータを記憶するオブジェクトが生成されることになる。
【００８０】
次に、図２０に示すフローを参照して、ワークフローエンジンＢ１５０４０の動作を説明する。
【００８１】
（１）ワークフローエンジンＢ１５０４０は、処理を開始すると、部門内フロー定義１５０００に記憶された全てのレコードを入力し、作業データベース５０のデータを参照する（ステップ２００００〜２００２０）。
【００８２】
（２）作業データベース５０の参照の結果、フローを遷移できるか否か、すなわち、次の職位に業務を移動できるか否かを判定し、フローを遷移することができない場合、ステップ２００２０に戻って処理を続ける（ステップ２００３０）。
【００８３】
（３）ステップ２００３０の判定で、次の職位に業務を移動できる場合、作業データベース５０のデータを変更し、リソースセレクタＢ１５０５０へアクション名と部門ノードと職位と業務処理単位とを出力する。その後、ステップ２００２０に戻って前述の処理を繰り返す（ステップ２００４０、２００５０）。
【００８４】
前述の処理において、ワークフローエンジンＢ１５０４０は、ステップ２０１０で図１６に示す部門内フロー定義を全て入力し、ステップ２００２０で入力した作業データベース５０のデータを参照し、ステップ２００３０で、フローの遷移ができる、すなわち、次の職位に業務を移動できる場合であったとし、アイコン１６０３０の「担当者」に遷移したとする。
【００８５】
この結果、ワークフローエンジンＢ１５０４０は、ステップ２００４０で作業データベース５０のデータを変更し、リソースセレクタＢ１５０５０へアクション名「引合書作成」と部門ノード「営業１課」と職位「担当」と業務処理単位「引合」を出力することになる。
【００８６】
次に、図２１に示すフローを参照して、リソースセレクタＢ１５０５０の動作を説明する。
【００８７】
（１）リソースセレクタＢ１５０５０は、処理を開始すると、担当振り分けルール１５０１０に記憶された全てのレコードを入力する（ステップ２００００、２１０１０）。
【００８８】
（２）入力した担当振り分けルール１５０１０のレコードのデータと、作業データベース５０のデータとを比較してユーザを選択し、ノーティファイア１２０へ該当するユーザとアプリケーション名とを出力して処理を終了する（ステップ２１０２０〜２１０４０）。
【００８９】
前述の処理において、ステップ２１０１０で、図１７に示す担当振り分けルールを入力し、ステップ２１０２０で、アクション名「引合書作成」と部門ノード「営業１課」と職位「担当」と業務処理単位「引合」であったことと、作業データベース５０の他のデータから担当者、すなわち、ユーザを「Ａ」を選択し、ノーティファイア１２０へ該当するユーザ「Ａ」とアプリケーション名「引合書作成」とを出力する。
【００９０】
また、例外処理部１１０００は、すでに図１３により説明した処理を行い、属性として「商談番号」、「見積開始」を生成しているとする。そして、例えば、アプリケーションデータベース８０のレコード２１００で、商談番号が入力され、「引合中」、「見積中」、「手配中」の各業務が、それぞれ開始されたとし、「見積中」の処理の途中で、外部的な要因でユーザ１４０がクライアントアプリケーション６０を通じて、サーバアプリケーション７０を操作して、商談番号を削除したとする。
【００９１】
このとき、例外ステータスウオッチャ１１０１０は、属性「商談番号」が変更になったので、ユーザ検索部１１０２０へ変更された状態名「引合中」、「見積中」、「手配中」を出力する。
【００９２】
次に、ユーザ検索部１１０２０は、作業データベース５０を参照し、業務状態の業務を行っているユーザ、つまり、「引合中」と「見積中」と「手配中」を実行しているユーザを選択し、ノーティファイア１２０に、そのユーザに中断が生じたことを出力する。
【００９３】
図１５に示す本発明の第３の実施形態によるワークフロー管理システムは、前述した処理を外部から停止の命令が入力されるまで、それぞれのプログラムが繰り返し実行される。
【００９４】
前述した本発明の第３の実施形態によるワークフロー管理システムによれば、事前に手順が決まらない業務の処理を行うワークフローエンジンの出力からユーザを選択する代わりに、予め定めた手順がある業務の処理を記述した部門内フロー定義を選択し、それを他のワークフローエンジンで実現することができるので、事前に全ての業務フローの手順を決めず、実行時に作業データベースやアプリケーションデータベースなどに記憶したデータの状況に合わせて適切な部門内フロー定義を選択することができる。
【００９５】
前述した本発明の実施形態は、例外条件として、１つの業務状態が中止となったときとして説明したが、本発明は、アプリケーションデータベースのデータを参照し、予め設定した処理期限を超えたいたとき、そのことをユーザへ通知するようにすることもできる。
【００９６】
前述した本発明の第１の実施形態によるワークフロー管理システムによれば、業務プロセスを記述したビジネスプロセス定義を参照し、起動するアプリケーションの順序を制御するワークフロー・エンジンが、ワークフロー管理システムのデータベースとは別のアプリケーションデータベースに記憶したデータを参照するステータスウオッチャ処理からの入力を用いるので、既存のアプリケーション・プログラムを大幅に変更することなくワークフロー管理システムとの連携が実現できる。
【００９７】
また、本発明の第２の実施形態によるワークフロー管理システムによれば、ステータスウオッチャに設定する条件から、例外条件を抽出する処理と、アプリケーションデータベースのデータを参照し、予め設定した例外条件を満たす変更があったときはユーザへ通知する処理とを備えているので、互いに依存関係のある複数の業務プロセスが並行して進行している場合で、１つの業務プロセスが中止になったときに、他の業務プロセスを実施している適切なユーザに、業務の中断を通知することができる。
【００９８】
さらに、本発明の第３の実施形態によるワークフロー管理システムによれば、事前に手順が決まらない業務の処理を行うワークフローエンジンの出力からユーザを選択する代わりに、予め定めた手順がある業務の処理を記述した部門内フロー定義を選択し、それを他のワークフローエンジンで実現することができるので、事前に全ての業務フローの手順を決めることなく、実行時に作業データベースやアプリケーションデータベースなどに記憶したデータの状況に合わせて適切な部門内フロー定義を選択することができる。
【００９９】
【発明の効果】
以上説明したように本発明によれば、互いに依存関係のある複数の業務プロセスを並行して進行させている場合に、１つの業務プロセスが中止になったとき、他の業務プロセスを実施している適切なユーザに業務の中断を通知することができ、ユーザに無駄な業務を行わせることを防止することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態によるワークフロー管理システムの構成を示すブロック図である。
【図２】アプリケーションデータベースの詳細を説明する図である。
【図３】業務状態定義表の詳細を説明する図である。
【図４】アクション部門定義表の詳細を説明する図である。
【図５】組織構造データベースの詳細を説明する図である。
【図６】担当振り分けルールの詳細を説明する図である。
【図７】ステータスウォッチャの動作を説明するフローチャートである。
【図８】ワークフローエンジンの動作を説明するフローチャートである。
【図９】リソースセレクタの動作を説明するフローチャートである。
【図１０】アプリケーションデータベースから変更の通知を受け取る場合のステータスウオッチャ及びアプリケーションデータベースの処理動作を説明するフローチャートである。
【図１１】本発明の第２の実施形態によるワークフロー管理システムの構成を示すブロック図である。
【図１２】例外ステータスウオッチャの動作を説明するフローチャートである。
【図１３】例外条件の生成を説明するための業務状態定義表を示す図である。
【図１４】例外条件の生成の他の例を説明するための業務状態定義表を示す図である。
【図１５】本発明の第３の実施形態によるワークフロー管理システムの構成を示すブロック図である。
【図１６】部門内フロー定義の詳細な例を説明する図である。
【図１７】担当振り分けルールの詳細を説明する図である。
【図１８】リソースセレクタＡの動作を説明するフローチャートである。
【図１９】サブプロセス実行部の動作を説明するフローチャートである。
【図２０】ワークフローエンジンＢの動作を説明するフローチャートである。
【図２１】リソースセレクタＢの動作を説明するフローチャートである。
【符号の説明】
１０  業務状態定義表
２０  アクション−部門定義表
３０  組織構造データベース
４０  担当振り分けルール
５０  作業データベース
６０  クライアントアプリケーション
７０  サーバアプリケーション
８０  アプリケーションデータデース
９０  ステータスウオッチャ
１００  ワークフローエンジン
１１０  リソースセレクタ
１２０  ノーティファイア
１３０  インボックス
１４０  ユーザ
１１０００  例外処理部
１１０１０  例外ステータスウオッチャ
１１０２０  ユーザ検索部
１５０００  部門内フロー定義
１５０１０  担当振り分けルール
１５０２０  リソースセレクタＡ
１５０３０  サブプロセス実行部
１５０４０  ワークフローエンジンＢ
１５０５０  リソースセレクタＢ
【図１】
0004020504.tif 000002
【図２】
0004020504.tif 000003
【図３】
0004020504.tif 000004
【図４】
0004020504.tif 000005
【図５】
0004020504.tif 000006
【図６】
0004020504.tif 000007
【図７】
0004020504.tif 000008
【図８】
0004020504.tif 000009
【図９】
0004020504.tif 000010
【図１０】
0004020504.tif 000011
【図１１】
0004020504.tif 000012
【図１２】
0004020504.tif 000013
【図１３】
0004020504.tif 000014
【図１４】
0004020504.tif 000015
【図１５】
0004020504.tif 000016
【図１６】
0004020504.tif 000017
【図１７】
0004020504.tif 000018
【図１８】
0004020504.tif 000019
【図１９】
0004020504.tif 000020
【図２０】
0004020504.tif 000021
【図２１】
0004020504.tif 000022