JP3867858B2 - ワークフロー支援システム - Google Patents

Description

本発明は、複数の情報処理装置がネットワークによって接続された分散環境におけるワークフローの支援を行うワークフロー支援システムに関する。

ワークフローシステムと呼ばれるもののルールの表記法はシステムによって様々であるが、各作業（タスク）を各ユーザに配送した電子メール文書の編集作業に対応させ、その作業の依存関係に基づいて順次の配送経路を定義する形態でルール化するのが一般的である。
一般に、このようなルールはルール定義のための専用開発ツールを用いて専門家によって記述されるが、特に、部署を横断するような広域に跨るワークフローのルールを定義する場合には、全体の情報の流れの調査や分析、さらにその整合性を維持した設計が必要であり、ほとんど専門家以外には行うことが難しい。

これに対して、全体のワークフローを把握することなく、各部署や各個人において隣接者に対するルールを定義するだけで広域のワークフローのルールを定義したのと同じ効果を得ることができるシステムとして、特開平８−１０１８１７号公報に開示された発明が知られている。
このシステムにおいては、分散して独立に定義されたルールによって生成されたタスクや、そもそもルールが存在せずに手動で生成されたタスクが結果として連携し、広域の大きなワークフローが実現される。そして、この広域の大きなワークフローのルールがあらかじめ与えられていたかのようにそのフローを辿ることができ、関連するタスクの実行状態やタスク遂行の成果情報を得ることができる。

すなわち、従来のワークフローのルールは、現場に即して考案されるにせよ、結局はトップで決定が行われ、トップダウンに与えられるものであるのに対し、特開平８−１０１８１７号公報に示されるシステムでは、これに加えてボトムアップのルール定義も行えるようになっている。
現実には、仕事のやり方はマネージャからトップダウンに与えられたり、現場でボトムアップに改善されたりする。それゆえ、このようにトップダウンとボトムアップの両方からのルール定義が行えることは大きな長所である。

ここで、常にトップダウンにだけルールを与えるシステムの場合には、全てのルールを集中管理できるので、あらかじめ全体の動作を確認するためのシミュレーション・ツールなどを用意することができる。しかしながら、特開平８−１０１８１７号公報に示されるシステムのようにルールを分散させる方式では、例えば部署毎のボトムアップの改善を許す柔軟性を持つ一方で、事前の動作確認を行うことができない問題があった。
また、いずれにせよ、時間とともに仕事のやり方というものは変化してくるものであるが、それを知る術をシステムは用意していないため、実際に行われている仕事の仕方とトップマネージャの認識の間にギャップが生じて来るという問題もあった。

本発明は、上述した事情に鑑みてなされたもので、ルールが分散して存在する場合においてもシミュレーションを行えるようにして、起こり得る動作をあらかじめユーザに知らせることを可能にすることを目的とする。
また、本発明は、初期に認識していた仕事のやり方から逸脱した仕事のやり方が増加してきた場合に、自動的にそれを検知して、ユーザに知らせることを可能にすることを目的とする。

本発明は、ネットワークによって接続された分散システム上のワークフロー支援システムにおいて、要求されたタスクと当該要求タスクを遂行するための部分タスクとの関係を規定したルールを例えば各部署毎の複数のルール格納手段に格納し、ワークフローにおいて遂行される各タスクの情報をタスク履歴として履歴格納手段に格納し、各タスク履歴間の接続情報をタスク接続情報格納手段に格納している。そして、履歴格納手段に格納されている各タスク履歴について、ルール準拠判定手段がルール格納手段に格納されているルールに準拠しているかを検証する。
したがって、各タスクがあらかじめ想定されている仕事のやり方に沿って遂行されているか、或いは、逸脱しているかを見極めることができる。

また、本発明に係るワークフロー支援システムでは、ルール格納手段は格納されているルールの分類属性を保持する手段を有し、ルール準拠判定手段は参照するルールを特定の分類属性の範囲に限定して検証処理を行う。
したがって、あらかじめ想定されている仕事のやり方の集合を限定して、適切な検証処理を行うことができる。

また、本発明に係るワークフロー支援システムは、ルール準拠判定手段によりルールに準拠しないと判定されたタスク履歴の数が、履歴格納手段に格納されている全タスク履歴の数に対して所定の割合を超えた場合に、当該割合をユーザに通知するユーザインタフェースを有する。
したがって、ユーザは、組織の中であらかじめ想定した仕事のやり方から逸脱した行為の割合が、ある閾値を超えたことをタイミングよく知ることができる。

また、本発明は、ネットワークによって接続された分散システム上のワークフロー支援システムにおいて、要求されたタスクと当該要求タスクを遂行するための部分タスクとの関係を規定したルールを格納する複数のルール格納手段と、ルールを適用して要求されたタスクを遂行させる複数のルール解釈実行手段とを有している。そして、シミュレーション属性を有するタスク要求を受理した場合に、仮想ルール展開手段が、当該要求をルール解釈実行手段に渡す代わりに、ルールを適用した場合に新たに生成されるタスク要求の情報を生成して、シミュレーション属性を有するタスク要求の要求元へ返送する。
したがって、エンドユーザにおいても自分が起動したタスクがどのように処理されるか、どのように組織に影響を与えるかをその時点での現実のルールに即してシミュレーションすることができる。

また、本発明に係るワークフロー支援システムでは、仮想ルール展開手段はユーザによって指定された回数の範囲でルール展開のシミュレーションを行う。
したがって、シミュレーションの範囲を必要に応じて限定することができる。

また、本発明は、ネットワークによって接続された分散システム上のワークフロー支援システムにおいて、要求されたタスクと当該要求タスクを遂行するための部分タスクとの関係を規定したルールを格納する複数のルール格納手段と、ルールを適用して要求されたタスクを遂行させる複数のルール解釈実行手段とを有している。そして、タスク要求を受理した場合に、予想ルール展開手段が、当該要求をルール解釈実行手段に渡す前に、ルールを適用した場合に逐次的に生成される新たなタスク要求に予想属性を付与して並列に生成し、これら予想属性を持つタスク要求をタスク到着予想表示ユーザインタフェースがユーザに対して表示する。
したがって、ユーザは近く到着するであろうタスク要求をあらかじめ知ることができ、仕事の計画を立て易くなる。

以上、詳細に説明したように、本発明によれば、ルールが分散して存在する場合においてもシミュレーションを行うことができ、起こり得る動作をあらかじめユーザは知ることができる。また、各ユーザはこれから来る仕事をあらかじめ知ることができるので、スケジュールの調整が行いやすくなる。
さらに、初期に認識していた仕事のやり方から逸脱した仕事のやり方が増加してきた場合に、それが自動的に検知されるので、マネージャをはじめ全てのユーザが仕事の形態が変わってきていることを知ることができる。

本発明のワークフロー支援システムを実施例を参照して具体的に説明する。
図１には、ネットワークによって接続された分散システムを用いたワークフロー支援システムの第１実施例の構成を示してある。
本実施例のワークフロー支援システムは、ネットワークを介して受け付けたタスクの遂行要求を保持するタスク要求受付データベース１と、遂行された各タスクの情報をタスク履歴として格納するとともに各タスク履歴間の接続情報を格納するタスク履歴／タスク接続データベース２と、タスクと当該タスクを実行するための部分タスクとの関係を規定したルールを格納するワークフロールールベース３と、タスク履歴／タスク接続データベース２に格納されたタスク履歴がワークフロールールベース３に格納されたルールに準拠しているかを検証するルール準拠判定処理部４と、を有している。なお、少なくともルールベース３は、例えば各部署毎と言ったように分散されて複数設けられており、各部署毎にローカルなルールを設定可能となっている。

また更に、このワークフロー支援システムは、ネットワーク上に分散された種々なユーザインタフェースを有し、タスク履歴／タスク接続データベース２に格納された情報に対するユーザからの参照指示を受け付けるタスク参照ユーザインタフェース５と、検証処理において用いる分類をユーザから受け付けるとともに検証処理の結果をユーザに対して表示通知するルール分類・逸脱率通知ユーザインタフェース６と、を有している。
なお、本発明においては、ワークフロー支援システムの構成は任意であり、要は、ネットワーク上のいずれかの端末において要求されたタスクを遂行するために、ネットワーク上の他のいずれかの端末において部分タスクが遂行されるようにすればよい。

次に、上記のワークフロー支援システムによる処理動作を、物品の購入処理のためのワークフローを例にとって説明する。
物品を購入しようとする者は、まず購入伝票を記述し、上長の承認を得てから購買部門に依頼し、納品後に確認の報告をする形態であったとし、このようなルールが組織の中央で決定されてトップダウンに与えられるとする。
ワークフローシステムと呼ばれるもののルールの表記法はシステムによって様々であるが、本例では特開平８−１０１８１７号公報に記載されている表記法を用いて説明する。この表記法では、上記のワークフローのルールは次のように定義することができる。

物品購入処理（？依頼者，経理部門，？購入伝票）←
購入伝票作成（？依頼者，？依頼者，？購入伝票），
承認処理（？依頼者，？上長，？購入伝票），
発注依頼（？依頼者，購買部門，？購入伝票），
納品確認報告（？依頼者，経理部門，？購入伝票）。

ここで、第一引数は遂行者、第二引数は要求者（報告先ともなる）、第三以降の引数は交換および保存される情報または電子文書またはそれらの格納場所を表すものである。また、？は変数であることを示す。このルールにおける変数名は同一名のものが同一値を持つべきであるという関係を示していることが重要であって、名前そのものはルール適用後は破棄されて構わない。
また、←は含意（〜ならば）を示す。すなわち、ａ←ｂ，ｃはｂかつｃならばａである。この後ろ向き推論による証明過程を手続き的に解釈すれば、ａが達成（証明）されるためにはｂとｃがともに達成されなければならず、ゆえにａのタスクが起動（達成しなければならないものとして発生）された場合には、ｂ，ｃのタスクを起動することになる。また、ｂとｃは同時（並列）に実行されることも許されている。

今、Ｙ氏を上長とするＡ氏がこの処理を行ったとする。すなわち、タスク”物品購入処理（Ａ，経理部門，情報格納域１）”がゴールとして発生したとする。
このタスクを受理すると、そのタスク情報をタスク管理用データベース（タスク履歴格納部）２のテーブルに図２に示すように登録する。なお、ここではタスク情報のうち、本発明に関係する最小限の項目のみを示してある。すなわち、タスク”物品購入処理（Ａ，経理部門，情報格納域１）”について、タスクＩＤとして「０２０００」、タスク名として「物品購入処理」、遂行状態として「実行中」、遂行者として「Ａ」、報告先として「経理部門」、項目１として実データの格納場所を示す「情報格納域１」等が登録される。

このようにタスク情報をテーブルに登録することにより、ルールベース３に格納されているルールが当該タスクの遂行に適用可能となり、このワークフローが開始されて、ゴールとなる当該要求タスク（親タスク）を遂行するための部分タスク（子タスク）が下記のように新たに発生する。

購入伝票作成（Ａ， Ａ， 情報格納域１），
承認処理（Ａ， Ｙ， 情報格納域１），
発注依頼（Ａ， 購買部門， 情報格納域１），
納品確認報告（Ａ， 経理部門， 情報格納域１）。

そして、これら子タスクも受理されると、図３に示すようにタスク管理用データベース２のタスクテーブルに追加される。
ここで、タスクＩＤは新たに生成されたタスクの場合はネットワーク上にまだ出現していないユニークな値が生成されて付与される。なお、ネットワーク上でこの環境をユニークに指し示すアドレスと当該環境でユニークな値を組み合わせることにより、ネットワーク上でユニークである値は簡単に生成することができる。

また、適用したルール上の←（含意）は、タスク間の親子関係として、図４に示すように、タスク管理用データベース２のプロセステーブル（タスク接続情報格納手段）に格納される。
上記のように、要求されたタスクに適用可能なルールが存在する場合には、ルール解釈実行手段（図示せず）によって、当該要求タスクを遂行するための子タスクがルールに従って特定され、これら子タスクがタスクテーブルに登録されるとともに、親タスクと子タスクとの接続関係がプロセステーブルに登録される。

さて、時間の経過とともに、この処理の仕方が変化してきたとする。例えば、購入依頼者は、購入伝票を作成するとともに部門内の予算管理表にも支出予定金額を書き込むようになったとする。すなわち、トップでルールを変更すると決定したわけではなく、ある部門だけがローカルなルールを再定義したり、ルールに従わずに手動で違った処理の仕方をする人が徐々に増えてくるような現象が起きたとする。例えば、ローカルなルールを用いた場合はもちろん、ユーザが手動で任意にタスクを追加されたような場合においても、タスク管理用データベース２には、ルールが存在する場合と全く同様にデータが蓄積されることになる。
したがって、”予算管理表記入”のタスクが追加された変化によって、タスクテーブル及びプロセステーブルには、図５及び図６に示すようなデータが格納されるようになる。

上記のような変化に対して、ユーザからの指示や予め設定したタイミング等に従って、ルール準拠判定部４が図８に示す手順で動作して、タスク管理用データベース２に格納されたデータがルールベース３に格納されているルールに準拠しているか否かの検証がなされる。
なお、先にも示した下記のような各ルールはそのままの形態でルールベース３に格納されている。また、それぞれのルールにはユニークなＩＤが付与されており、ルールに関する分類属性が、ルールベース３のルール分類属性テーブルにルールのＩＤとの対として図７に示すようにあらかじめ設定格納されている。

物品購入処理（？依頼者，経理部門，？購入伝票）←
購入伝票作成（？依頼者，？依頼者，？購入伝票），
承認処理（？依頼者，？上長，？購入伝票），
発注依頼（？依頼者，購買部門，？購入伝票），
納品確認報告（？依頼者，経理部門，？購入伝票）。

まず、ルール分類属性テーブルを参照して、ユーザが指定した分類属性の範囲で、ルール準拠検証に用いるルールＩＤの集合を求め、それらのＩＤを持つルールを抽出して検証処理用のデータベース（ルール準拠判定部４が作業に用いるメモリ領域）に格納する（ステップＳ１）。ここでは、全社標準（ルールＩＤが「０７００１」）のものだけを指定したとし、ルール集合の要素は先の一つだけであったとする。
この結果、下記のようにルールベース３に格納されている上記のルールがルール集合として抽出される。

物品購入処理（？依頼者，経理部門，？購入伝票）←
購入伝票作成（？依頼者，？依頼者，？購入伝票），
承認処理（？依頼者，？上長，？購入伝票），
発注依頼（？依頼者，購買部門，？購入伝票），
納品確認報告（？依頼者，経理部門，？購入伝票）。

そして、タスクテーブルの先頭から一つずつタスク履歴を取り出す（ステップＳ２）。なお、本例では、先頭が図９に示すレコードであったとする。
次いで、このタスク履歴からタスクＩＤ「０３０００」を取得し（ステップＳ３）、このタスクＩＤが「０３０００」であるタスクの子タスク（すなわち親の方に０３０００を持つレコード）を、図６に示したプロセステーブルを参照して得る（ステップＳ４）。
次いで、これら子タスクが存在することを確認して（ステップＳ５）、取得した子タスクのＩＤに対応するタスク履歴をタスクテーブルから取得する（ステップＳ６）。

そして、親タスク及び子タスクの履歴から、タスク名を述語名とし、必要なフィールドを引数として並べ、それぞれ次のような述語表現に変換する（ステップＳ７）。
すなわち、親タスクは、”物品購入処理（Ａ，経理部門，情報格納域１）”、子タスクは、”購入伝票作成（Ａ，Ｘ部門，情報格納域１）”、”予算管理表記入（Ａ，？依頼者，情報格納域１）”、”承認処理（Ａ，？上長，情報格納域１）”、”発注依頼（Ａ，購買部門，情報格納域１）”、”納品確認報告（Ａ，経理部門，情報格納域１）、という述語表現に変換する。

次いで、子タスクから得られた述語を定理として上記の検証処理用のデータベースに格納し（ステップＳ８）、親タスクから得られた述語をゴールとしてルールに準拠しているかの検証処理を行う（ステップＳ９）。すなわち、親タスクの述語が、推論規則であるルール集合と公理または定理である子タスクの述語の集合とから証明できるかどうかを検証する。
この証明処理は、例えば、閉世界仮説（失敗による否定）を持つ一階述語論理に基づき、ＳＬＤ反駁法などを用いたＰｒｏｌｏｇ言語と全く同様に後ろ向き推論を行って計算することができる。すなわち、ルール集合と子タスクの述語の集合のみをａｓｓｅｒｔした状態で、親タスクの述語をゴールとして与えれば計算できる。

そして、この処理によって証明できなかった場合には（ステップＳ１０）、ここに現れたタスク全てはルールには準拠していないという判定を下して（ステップＳ１１）、次のタスク履歴についての処理を行う（ステップＳ１５）。
一方、証明できた場合には、更に、その証明のために全ての公理または定理が使われたかどうかを調査する（ステップＳ１２）。この調査処理は、例えば、公理又は定理に証明過程で使ったときに印を付けておき、後で全てに印がついているかを参照すれば良い。なお、一回の証明が終わる毎に、次回のために全ての印を消しておく。

上記の調査の結果、全ての公理または定理が使われている場合には、ここに現れたタスク全てはルールに準拠していると判定し（ステップＳ１３）、全てが使われていない場合には、強制的にバックトラックさせて別の証明経路の探索を繰り返し行う（ステップＳ１４）。なお、このようなこり返し処理を行って他の証明経路がもうなくなった場合には、ここに現れたタスク全てはルールには準拠していないという判定をする（ステップＳ１１）。
上記のような処理を、タスク履歴の全てのレコードについて繰り返し行い（ステップＳ１５、Ｓ１６）、その検証結果をユーザインタフェース６を通してユーザに通知する。

このユーザへの通知は種々な方法で行うことがでいるが、本実施例では、ルールに対する逸脱率をユーザに対して通知している。
この逸脱率は、（ルールに準拠していないタスクのレコード数）／（タスク履歴の全レコードの数）×１００、という演算を行うことにより求めることができ、これによって、何パーセントのタスクが想定していたルールから逸脱しているかをユーザが認識することができる。

例えば、最初に全社標準の分類属性でルール集合を決定し、逸脱率がある閾値を超えた場合は、既に標準として想定した仕事のやり方がその組織の実状に合わなくなってきていることを示していると解釈すべきである。そこで、本実施例では、ユーザインタフェース６にユーザが所定の閾値を設定しておき、当該閾値を上回った時にユーザに対して警告や逸脱率の表示を行うようにしている。これにより、マネージャはボトムアップで自然発生してきた別の秩序を追認するのか、新たな仕事の仕方をデザインするのかを決定すべきタイミングを掴むことができる。

図１１には、本発明の第２実施例に係るワークフロー支援システムの構成を示してある。
エンドユーザにおいても自分が起動したタスクが以降どのように処理されるのかをある程度掴んでおきたいこともあるので、本実施例のワークフロー支援システムは、これを実現する仮想ルール展開手段を有している。

すなわち、上記した第１実施例の構成に加えて、このワークフロー支援システムは、ユーザから発せられたシミュレーション属性を有するタスク要求を保持するシミュレーション要求受付データベース７と、要求されたタスクをルールを適用して遂行させる複数のルール解釈実行処理部８と、シミュレーション属性を有するタスク要求を受理した場合に当該要求をルール解釈実行処理部８に渡す代わりに、ルールを適用した場合に新たに生成されるタスク要求の情報を生成してシミュレーション属性を有するタスク要求の要求元へ返送する仮想ルール展開処理部９と、シミュレーションの結果をユーザに対して出力するシミュレーション実行ユーザインタフェース１０と、を有している。

次に、本実施例において、主に仮想ルール展開処理部９により行われる仮想ルール展開処理を説明する。
なお、以下の説明では、第１実施例と同様に、下記のようなルールが既にルールベース３に格納されているとする。

物品購入処理（？依頼者，経理部門，？購入伝票）←
購入伝票作成（？依頼者，？依頼者，？購入伝票），
承認処理（？依頼者，？上長，？購入伝票），
発注依頼（？依頼者，購買部門，？購入伝票），
納品確認報告（？依頼者，経理部門，？購入伝票）。

ここで、実際に物品購入処理タスクの起動を行うということは、このタスクが証明すべきゴールとして与えることである。したがって、ルールの右辺（含意記号の右側の実行列）のタスクもルール解釈実行処理部８によって順次起動され、子タスクが展開されることになる。これらのタスクは各ユーザのタスク要求受付データベース１のアジェンダ（メールボックスあるいはＴｏＤｏリスト）に届き、受理されればデータベース２のタスクテーブルに履歴として格納され、ユーザインタフェース５を通してユーザから参照可能なものとなる。
しかしながら、本実施例では、ユーザがユーザインタフェース１０でシミュレーションであることを指定した場合には、ゴールにシミュレーションであることを示す属性と、ルール適用回数を付与した、［物品購入処理（Ａ，経理部門，？購入伝票），シミュレーション，２回］というようなタスクの転送を行う。

受け取ったゴールがこのようにシミュレーション属性を持っている場合には、このゴールをユーザが参照するアジェンダ（メールボックスあるいはＴｏＤｏリスト）およびタスクテーブルには格納せず、ルール解釈実行処理部８によるタスクの起動を行うことなく、仮想ルール展開処理部９でルールに従った展開のみを並列に行う。そして、展開したタスク全ても同じようにシミュレーション属性を付与し、ルール適用回数は１を減じて付与して転送する。
そして、この処理において、適用するルールが見つからないか、あるいはルール適用回数が０になった場合には、展開された結果を要求元に返却する。なお、結果を受け取った環境の仮想ルール展開処理部９において、さらに要求元がある場合には受け取った結果とその環境自体が展開した結果をまとめて要求元に返却する。
このような処理によって、シミュレーションを要求したユーザの元に、自分が起動したタスクがルールに従ってどのように展開されるかの情報が返却され、ユーザインタフェース１０を通して通知される。

図１２には、本発明の第３実施例に係るワークフロー支援システムの構成を示してある。
ユーザにおいては、どのようなタスクが到着するかをあらかじめ掴んでおきたいこともあるので、本実施例のワークフロー支援システムは、これを実現する予測ルール展開手段を有している。

すなわち、上記した第１実施例の構成に加えて、このワークフロー支援システムは、要求されたタスクをルールを適用して遂行させる複数のルール解釈実行処理部８と、ユーザから発せられた予測属性を有するタスク要求を保持する予測タスク要求受付データベース１１と、タスク要求を受理した場合に当該要求をルール解釈実行処理部８に渡す前にルールを適用した場合に逐次的に生成される新たなタスク要求に予想属性を付与して並列に生成する予想ルール展開処理部１２と、予想属性を持つタスク要求を表示するタスク到着予想表示ユーザインタフェース１３と、を有している。

次に、本実施例において、主に予想ルール展開処理部１２により行われるタスク到着予想処理を説明する。
本実施例では、ユーザによって最初のタスクが起動された際に、従来のようなタスクゴールの転送に加えて、第２実施例で示したシミュレーション属性の代わりに予想属性と、このタスクのＩＤを付与した、［物品購入処理（Ａ，経理部門，？購入伝票），予想，タスクＩＤ：０３０００］といったようなタスクの転送を行う。

そして、受け取ったゴールがこのように予想属性を持っている場合には、このゴールをユーザが参照するアジェンダ（メールボックスあるいはＴｏＤｏリスト）におよびタスクテーブルには格納せず、予測ルール展開処理部１２が別の到着予想テーブルに格納する。そして、予測ルール展開処理部１２がルールの展開を並列に行い、展開した全てのタスクも同じように予想属性を付与し、タスクＩＤはそのまま継承し、さらに適用したルールＩＤを付与し転送する。例えば、先のルールのＩＤが０７００１であれば、［購入伝票作成（Ａ，Ａ，？購入伝票），予想，タスクＩＤ：０３０００，ルールＩＤ：０７００１］といったようなタスクの転送を行う。
なお、適用するルールが見つからなかった場合には、そこで処理を終了する。

このような処理によって、到着が予想されるタスクが該当するユーザの到着予想テーブルに格納されるので、ユーザはインタフェース１３を通してこれを参照することにより、これから到着するタスクをあらかじめ知ることができる。
ここで、現実には途中で別のルールが選択される場合もないわけではないので、本実施例の予測ルール展開処理部１２は、次のような削除処理を行う機能も有している。

すなわち、最初のタスクＩＤを継承しているあるゴールに対して、今まさに適用しようとしているルールのＩＤを取得し、到着予想テーブルを参照して、タスクＩＤが一致しているがルールＩＤが一致していない場合は、予想とは異なったルールが選択されたと判定し、この予想に関するデータの削除処理を行う。
具体的には、［購入伝票作成（Ａ，Ａ，？購入伝票），予想削除，タスクＩＤ：０３０００，ルールＩＤ：０７００１］といったような予想削除属性を持ったタスクを転送する。

そして、このような予想削除属性を持ったタスクを受け取った場合には、各環境はこれに該当する情報を到着予想テーブルから削除し、また、この削除タスクも同様にルールによって展開する。
また、これと同時に、このように別のルールを適用した場合においては、もう一方で新たにそのルールＩＤを属性として付与した予想属性を持ったタスクを転送する。
このような処理によって、実際のルール選択に合わせて予想内容も修正されて行き、ユーザはどのようなタスクが到着するかを正確に把握することができる。

本発明の第１実施例に係るワークフロー支援システムの構成図である。 タスクテーブルの一例を示す図である。 タスクテーブルの一例を示す図である。 プロセステーブルの一例を示す図である。 タスクテーブルの一例を示す図である。 プロセステーブルの一例を示す図である。 ルール分類属性テーブルの一例を示す図である。 本発明の第１実施例に係る処理手順を示すフローチャートである。 タスクテーブルの一例を示す図である。 タスクテーブルの一例を示す図である。 本発明の第２実施例に係るワークフロー支援システムの構成図である。 本発明の第３実施例に係るワークフロー支援システムの構成図である。

符号の説明

２・・・タスク履歴／タスク接続データベース、
３・・・ワークフロールールベース、
４・・・ルール準拠判定処理部、
６・・・ルール分類・逸脱率通知ユーザインタフェース、
８・・・ルール解釈実行処理部、
９・・・仮想ルール展開処理部、
１０・・・シミュレーション実行ユーザインタフェース、
１２・・・予想ルール展開処理部、
１３・・・タスク到着予想表示ユーザインタフェース、

Claims (1)

1. ネットワークによって接続された分散システム上のワークフロー支援システムにおいて、
   要求されたタスクと当該要求タスクを遂行するための部分タスクとの関係を規定したルールを格納する複数のルール格納手段と、
   要求されたタスクの遂行のための部分タスクをルールを適用して特定して、部分タスクを実行するユーザが前記ネットワーク上に分散されたユーザインタフェースを通して参照するタスクテーブルに前記特定された部分タスクを格納することで、前記要求されたタスクをユーザに遂行させる複数のルール解釈実行手段と、
   シミュレーション属性を有するタスク要求を受理した場合に、当該要求されたタスクをルール解釈実行手段に渡す代わりに、ルールを適用して特定される当該要求されたタスクを遂行するための部分タスクを特定して、当該部分タスクをシミュレーション属性を有するタスク要求の要求元へ返送する仮想ルール展開手段と、
   を有することを特徴とするワークフロー支援システム。

Images