JP2008090667A - ワークフロー管理プログラムおよびワークフロー管理システム - Google Patents

Abstract

【課題】
複数の作業を遷移する複数の処理案件に対して一括処理を可能としたワークフロー管理プログラムおよびワークフロー管理システムを提供する。
【解決手段】
ワークフローを構成する制約チェック工程で設定した制約条件の評価処理を行い、制約条件に該当する処理案件である場合、その処理案件の起案定義名と同一の起案定義名を持つ処理案件をワークフローから検索し、合致する処理案件全てに対して予め指定された処理工程まで差し戻すという一括処理を行う。
【選択図】図２

Description

本発明は、ワークフロー管理プログラムおよびワークフロー管理システムに関する。

複数の作業（アクティビティ）を経て業務を遂行する際に用いられる仕組みとして、ワークフローシステムがあり、このワークフローシステムによって効率的な業務運用が可能となる。例えば、報告書や提案書、稟議書などの電子文書を企業内の部門間で回覧する場合に用いられ、回覧者が確実に閲覧することや承認することが可能となる。

このワークフローシステムを用いて業務運用を行った場合、処理案件ごとに各作業で処理が行われ、各作業に設けられた制約条件に該当する場合にのみ次の作業へ遷移することが可能となっている。この制約条件が複数の処理案件に対して設定されている場合、制約条件に該当する処理案件は次の作業へ進み、制約条件に該当しない処理案件については次の作業へ進むことを制限している。

この場合、先行して進んだ処理案件に対しても処理を行う場合、対象となる処理案件を検索して手動で一時停止や中止などの操作を行う必要がある。

特許文献１に開示された従来技術では、所定の制約条件に合致する処理案件を動的に抽出できるようにした技術である。この従来技術では、作業ごとに、処理が終了した処理案件の処理履歴データを記録し、指定された制約条件に当てはまる処理案件を処理履歴データに基づいて検索して一覧表示している。
特開平１１−０８５８７７

本発明は、複数の作業を遷移する複数の処理案件に対して一括処理を可能としたワークフロー管理プログラムおよびワークフロー管理システムを提供することを目的とする。

上記目的を達成するため、請求項１の発明は、コンピュータを、複数の作業の手順を規定したワークフローにしたがって処理案件を順次処理する処理手段と、前記処理手段で処理する処理案件に対して該処理案件に関連する複数の処理案件に跨る条件を設定する条件設定手段と、前記処理案件を処理するに際して前記条件設定手段によって設定した前記条件に該当するか否かを判断する条件判断手段と、前記条件判断手段によって前記処理案件が前記条件に該当すると判断された場合は、該処理案件に関連する前記ワークフロー上の処理済みの処理案件を再度処理する案件再処理手段として機能させることを特徴とする。

また、請求項２の発明は、請求項１の発明において、前記条件設定手段は、前記ワークフロー上での前記処理案件の処理状態に応じた条件を設定し、前記案件再処理手段は、前記条件設定手段によって設定された各処理状態に対する条件ごとに該処理案件に関連する前記ワークフロー上の処理済みの処理案件を再度処理することを特徴とする。

また、請求項３の発明は、請求項１または２の発明において、前記条件設定手段によって設定された条件を変更する条件変更手段を具備し、前記条件判断手段は、前記条件変更手段によって前記条件が変更されたとき、当該条件に該当するか否かの判断を行うことを特徴とする。

また、請求項４の発明は、請求項１から３のいずれかの発明において、前記案件再処理手段は、前記処理案件と属性情報が同一の処理案件を関連する処理案件として再度処理することを特徴とする。

また、請求項５の発明は、請求項１または４の発明において、前記処理案件に対応して緊急度属性を設定し、前記条件判断手段は、前記処理案件の緊急度属性が示す緊急度の高いものから順に、前記条件に該当するか否かを判断することを特徴とする。

また、請求項６の発明は、請求項１の発明において、前記案件再処理手段は、前記条件判断手段によって前記処理案件が前記条件に該当しないと判断された場合、該処理案件に関連する前記ワークフロー上の処理済みの処理案件を所定の作業へ戻して再処理することを特徴とする。

また、請求項７の発明は、複数の作業の手順を規定したワークフローにしたがって処理案件を順次処理する処理手段と、前記処理手段で処理する処理案件に対して該処理案件に関連する複数の処理案件に跨る条件を設定する条件設定手段と、前記処理案件を処理するに際して前記条件設定手段によって設定した条件に該当するか否かを判断する条件判断手段と、前記条件判断手段によって前記処理案件が前記条件に該当しないと判断された場合は、該処理案件に関連する前記ワークフロー上の処理済みの処理案件を再度処理する案件再処理手段とを具備することを特徴とする。

本発明の請求項１、７によれば、ワークフロー上に存在するいずれの処理案件に対しても、指定された制約条件に該当する処理案件とともに一括して処理することができるようになり、業務の効率化が図れるという効果を奏する。また、処理案件の誤指定がなくなるばかりでなく、制約条件に該当する処理案件を指定することがなくなるため、より高い操作性を実現する。

また、請求項２によれば、処理案件の処理状態ごとに一括して処理ができるようになり、より高い効率化が図れるという効果を奏する。

また、請求項３から６の発明によれば、業務状態に応じた一括処理が可能となり、効率的な業務運用が可能になるという効果を奏する。

以下、本発明に係わるワークフロー管理プログラムおよびワークフロー管理システムの一実施例を添付図面を参照して詳細に説明する。

図１は、本発明に係わるワークフロー管理プログラムおよびワークフロー管理システムを適用して構成したワークフロー管理システムの処理エンジンの一例を示す構成図である。

図１に示す処理エンジンは、複数の作業（アクティビティ）の手順を規定したワークフローシステムを管理、運用する装置であって、各処理案件に対して行う処理の内容および処理対象ユーザを定義して管理する。このとき、各作業に指定された処理を実行することによって処理案件を次作業へ遷移させる。

この処理エンジンは、ワークフロー定義保管部１１、案件履歴保管部１２、制約条件保管部１３、案件一括処理保管部１４、一括処理メール通知保管部１５、ルーティング管理部１６、集計処理部１７、案件一括処理部１８を具備して構成され、ワークフロー定義保管部１１には、ワークフロー定義記述アプリケーション（１１−１）がインストールされ、案件履歴保管部１２には案件操作アプリケーション（１２−１）がインストールされ、制約条件保管部１３には、制約条件記述アプリケーション（１３−１）がインストールされ、案件一括処理保管部１４には、案件一括処理記述アプリケーション（１４−１）がインストールされ、一括処理メール通知保管部１５には、一括処理メール通知アプリケーション（１５−１）がインストールされている。

ワークフロー定義保管部１１にインストールされたワークフロー定義記述アプリケーション（１１−１）では、各作業で行われる処理の内容および処理対象ユーザを定義するほか、複数の作業の手順を規定したワークフローの処理体系を定義している。図２に示すワークフローを例にすると、「発注申請工程２０１→制約チェック工程２０２→部門長承認工程２０３→経理処理工程２０４→発注工程２０５」という処理体系が定義される。

また、案件履歴保管部１２にインストールされた案件操作アプリケーション（１２−１）では、各作業で行われた処理案件に対する処理の内容および処理を行ったユーザなどを履歴情報として記録して保管する。

また、制約条件保管部１３にインストールされた制約条件記述アプリケーション（１３−１）では、複数の処理案件に跨る制約条件を記述して保管する。制約条件の設定方法として、例えば、図３に示すような画面を用いて制約条件を設定することができる。

また、案件一括処理保管部１４にインストールされた案件一括処理記述アプリケーション（１４−１）では、処理案件が制約条件保管部１３に保管された制約条件に該当する場合に、その処理案件に対して行われる「一括処理」の処理内容を記述して保管する。この処理内容は、例えば、図４に示すような画面を用いて設定することができる。

また、一括処理メール通知保管部１５にインストールされた一括処理メール通知アプリケーション（１５−１）では、案件一括処理保管部１４に保管された一括処理の処理内容が実行された際に、予め指定された関係者に送信する電子メールを保管する。

そして、ルーティング管理部１６は、ワークフロー定義保管部１１で保管されたワークフローの処理体系に基づき、起案された処理案件をルーティング（遷移）する。このルーティングに際し、制約条件を適用する作業では、ルーティング管理部１６が集計処理部１７に対して制約条件の評価処理を依頼する。

この集計処理部１７では、制約条件保管部１３に保管された制約条件に基づいて処理案件を評価することによって、制約条件に該当する処理案件であるか否かを判断する。そして、その評価した結果を依頼元のルーティング管理部１６へと通知する。

評価結果を受信したルーティング管理部１６は、その評価結果が制約条件に該当しない場合に、評価対象の処理案件を次作業へ遷移させる。それに対して、その評価結果が制約条件に該当する場合には、案件一括処理部１８へと案件一括処理要求を行う。

この案件一括処理部１８では、ルーティング管理部１６から案件一括処理要求を受信することによって、一括処理対象となる処理案件を検索し、合致した処理案件に対して一括処理を行う。

このときの一括処理として、例えば、予め指定した特定の作業まで合致した処理案件を差し戻す処理ができ、さらに、合致した処理案件を中止することもできる。なお、一括処理対象の処理案件がどのような作業にあった場合であっても指定された一括処理を行うことができる。

そしてさらに、案件一括処理部１８では、処理案件に対して一括処理を行うと同時に、一括処理メール通知保管部１５で保管された電子メールを予め指定された関係者に送信する。この電子メールを受信した関係者は、一括処理によって差し戻された処理案件若しくは中止された処理案件を確認し、各処理案件に対してそれぞれ最適な処理を行うことが可能となる。

例えば、制約条件に該当しないように処理案件の属性を変更したり、差し戻された処理案件のうち不要な処理案件を削除したりする。

次に、図２に示すワークフローを例にして、図１に示す構成を説明する。この図２には、図５の図５（ａ）に示す状態の処理案件が示されている。

図２に示すワークフローは、商品などを発注する工程の遷移を示したワークフローであって、発注申請工程２０１、制約チェック工程２０２、部門長承認工程２０３、経理処理工程２０４、発注工程２０５の各作業から構成される。また、これらの作業は、「発注申請工程２０１→制約チェック工程２０２→部門長承認工程２０３→経理処理工程２０４→発注工程２０５」というワークフローの処理体系を形成しており、これをもとにルーティングが行われる。

図５（ａ）には、「処理案件１」、「処理案件２」、「処理案件３」という[処理案件名]５０１を持つ３つの処理案件が示されており、これら３つの処理案件の[起案定義名]５０２として「資材調達」が指定されている。この起案定義名は処理案件の案件種別を示すものである。これら３つの処理案件の[起案部門]５０３として「部門Ａ」が指定されており、この[起案部門]５０３は、起案された部門の名称を示す。

さらに、これらの各処理案件が現在、遷移している工程が[処理工程]５０４に示されており、処理案件１と処理案件２は「経理処理工程」に遷移し、処理案件３は「制約チェック工程」に遷移していることが示されている。

このことから図２のワークフローに示す制約チェック工程２０２には、処理案件３が遷移した状態にあり、また、経理処理工程２０４には、処理案件１および処理案件２が遷移した状態にある。

また、図５（ｂ）には、図５（ａ）で示した処理案件の履歴情報が示されており、この履歴情報はルーティングされた各作業で記録される。記録された履歴情報が示す[属性名]５０６は制約条件を適用する属性の名称であって、[属性値]５０８はその[属性名]５０６に対する値である。また、この履歴情報が記録された日付情報が[処理日]５０７である。

図５（ａ）の[処理工程]５０４から「処理案件１」および「処理案件２」は、経理処理工程に遷移していることが示されているため、その経理処理工程２０４に至るまでに経過した制約チェック工程２０２、部門長承認工程２０３それぞれで履歴情報が記録されていることになる。また、「処理案件３」は、図５（ａ）の[処理工程]５０４から制約チェック工程に遷移し、この制約チェック工程によって制約条件の評価が行われた状態にあるため、制約チェック工程２０２における履歴情報が記憶されていることとなる。

例えば、制約チェック工程２０２では申請金額に対して処理が行われるため、[属性名]５０６として「申請金額」が指定され、その[属性値]５０８として申請金額が示される。また、部門長承認工程２０３では部門長が承認する処理を行うため、[属性名]５０６として「部門長承認」が指定され、その[属性値]５０８として承認の有無が示される。

このような履歴情報を持つ処理案件が図２のワークフローに示されている。

図２に示す発注申請工程２０１は、発注する商品の商品名や数量などを指定して発注申請を行う工程であって、図１に示す処理エンジンのルーティング管理部１６がワークフロー定義保管部１１に保管された処理体系に基づいて、指定された商品名や数量などの申請情報を元に起案された処理案件を制約チェック工程２０２へとルーティング（遷移）する。

このとき、ルーティング処理部１６では、処理の履歴情報を案件履歴保管部１２へと保管する処理が行われる。

続いて、制約チェック工程２０２は、発注申請工程２０１から受信した処理案件に対して制約条件を評価する工程である。この制約チェック工程２０２では、図１に示すルーティング管理部１６が集計処理部１７に対して制約条件の評価処理を依頼し、依頼を受けた集計処理部１７が制約条件保管部１３に保管された制約条件を呼び出して制約条件に該当する処理案件であるか否かを評価する処理を行う。

この制約条件保管部１３に保管された制約条件の一例として、図５（ｃ）に示すような制約条件があり、この図５（ｃ）に示す制約条件は図３に示す画面を用いて設定したものである。

図５（ｃ）の制約条件には、制約条件を識別する名称を示した[制約条件名]５０９に「部門ごとの発注条件」が指定され、その制約条件として、条件を適用する単位を示した[集計対象リソース]５１０が「部門ごと」であって、条件を適用する対象を示した[集計対象]５１１が「起案定義名＝「資材調達」」であって、条件を適用する期間を示した[集計期間]５１２が「月曜日始まりの毎週」であって、その[条件]５１３が「申請金額の合計額が１００万円超過」であることが示されている。

この制約条件で集計処理部１７が図５（ａ）に示す３つの処理案件に対して行う評価処理を示す。

まず、処理案件１に対して、集計処理部１７では、月曜日始まりの一週間内に処理案件１が示す部門Ａから起案定義名が「資材調達」である処理案件が起案されていないかを検索する。起案されていないことを確認後、処理案件１の申請金額「５０万円」が条件に指定された申請金額の合計金額「１００万円」超過であるかを判断して「１００万円」を超過していないことを確認する。

これによって、処理案件１は制約条件に該当しない処理案件であることを集計処理部１７からルーティング管理部１６へ通知する。

続いて、処理案件２に対して、集計処理部１７では、処理案件１と同様に、月曜日始まりの一週間内に処理案件１が示す部門Ａから起案定義名が「資材調達」である処理案件が起案されていないかを検索する。既に処理案件１が起案されていることを確認後、処理案件１の申請金額「５０万円」と処理案件２の申請金額「４０万円」の合計金額が条件に指定された申請金額の合計金額「１００万円」超過であるかを判断して１００万円を超過していないことを確認する。

これによって、処理案件２は制約条件に該当しない処理案件であることを集計処理部１７からルーティング管理部１６へ通知する。

さらに、処理案件３に対して、集計処理部１７では、処理案件１および処理案件２と同様に、月曜日始まりの一週間内に処理案件１が示す部門Ａから起案定義名が「資材調達」である処理案件が起案されていないかを検索する。既に処理案件１および処理案件２が起案されていることを確認後、処理案件１の申請金額「５０万円」と処理案件２の申請金額「４０万円」と処理案件３の申請金額「４０万円」の合計金額が条件に指定された申請金額の合計金額「１００万円」超過であるかを判断して１００万円を超過していることを確認し、処理案件３は制約条件に該当する処理案件であると評価する。

これによって、処理案件３は制約条件に該当する処理案件であることを集計処理部１７からルーティング管理部１６へ通知する。

集計処理部１７から評価処理結果を受信したルーティング管理部１６では、評価処理の結果を判断して、処理案件が制約条件に該当しない場合には、ワークフロー定義保管部１１に保管された処理体系に基づいてその処理案件を部門長承認工程２０３へとルーティングする。すなわち、制約条件によって処理案件が制約されることはなく、継続して次作業での処理を行うことを示す。

それに対して、処理案件が制約条件に該当する場合には、ルーティング管理部１６が案件一括処理部１８に対して処理要求を行い、案件一括処理部１８は、一括処理対象となる処理案件を検索し、合致した処理案件に対して図５（ｄ）に示される一括処理を行う。

このときの一括処理対象となる処理案件の検索処理として、制約条件に該当する処理案件に指定された[起案定義名]５０２と等しい処理案件を検索する方法がある。上記の例では、処理案件３に対して評価処理を行うことによって、この処理案件３が制約条件に該当しており、この場合、処理案件３の[起案定義名]５０２として指定された「資材調達」と等しい[起案定義名]５０２を持つ「処理案件１」および「処理案件２」が検索される。

このような検索処理によって検索された処理案件に対して、図５（ｄ）では、[処理対象]５１５で示された「全案件」に対して[処理内容]５１６が示す「部門長承認工程へ移動」するという一括処理を行う。

図２に示す部門長承認工程２０３には、「処理案件３」が制約条件に該当するため、この「処理案件３」と同一の起案定義名を持つ「処理案件１」および「処理案件２」が案件一括処理部１８による一括処理によって差し戻された状態を示している。ちなみに、全ての処理案件が差し戻された状態における図５（ａ）の[処理工程]５０４には、「部門長承認工程」と示されることになる。

そして、案件一括処理部１８が一括処理を行うと、一括処理メール通知保管部１５に保管された電子メールを予め指定された関係者に対して送信して差し戻しなどの一括処理が行われたことを通知する。このときの送信される電子メールの一例を図７に示す。

続いて、部門長承認工程２０３は、制約チェック工程２０２から受信した処理案件に対して部門長が承認処理を行う工程である。処理案件の内容を承認が承認することによってルーティング管理部１６がワークフロー定義保管部１１に保管された処理体系に基づいてその処理案件を経理処理工程２０４へとルーティングする。このとき、ルーティング処理部１６では、処理の履歴情報を案件履歴保管部１２へと保管する処理が行われる。

なお、図２に示す部門長承認工程２０３には、制約チェック工程２０２の制約チェックによって制約条件に該当する「処理案件３」と、その処理案件３と同一の起案定義名が指定された「処理案件１」および「処理案件２」が差し戻された状態が示されており、これら３つの処理案件に対して処理を行う。例えば、上記のように、制約条件に該当しないように処理案件の属性を変更したり、差し戻された処理案件のうち不要な処理案件を削除したりする。

続いて、経理処理工程２０４は、部門長承認工程２０３から受信した処理案件に対して経理担当者が経理処理を行う工程である。通常、経理処理では、申請内容が予算内であるかなどを判断する処理が行われる。このような経理処理が行われると、ルーティング管理部１６がワークフロー定義保管部１１に保管された処理体系に基づいてその処理案件を発注工程２０５へとルーティングする。このとき、ルーティング処理部１６では、処理の履歴情報を案件履歴保管部１２へと保管する処理が行われる。

そして、発注工程２０５は、申請された発注内容に基づいて発注処理を行う工程である。通常、発注処理として、指定された業者に起案された商品名や数量の情報を送信し、納品を待つ状態となる。納品が確認されると、発注工程２０５にある処理案件が終了することとなる。

図３には、制約条件を設定する画面の一例を示しており、この図３に示す制約条件設定画面を用いて設定された制約条件は、図１に示す制約条件保管部１３に保管される。

図３に示す制約条件設定画面は、制約条件の名称３０１、制約条件を適用する対象の設定項目３０２、制約条件の評価内容の設定項目３０３、設定ボタン３０４、キャンセルボタン３０５から構成される。図１に示す制約条件保管部１３に、制約条件の名称３０１に指定された名称を識別情報として、図３に示す制約条件を適用する対象の設定項目３０２、制約条件の評価内容の設定項目３０３それぞれを保管する。

制約条件を適用する対象の設定項目３０２は、制約条件を適用する対象となる処理案件を特定する項目であって、集計対象リソース３１、調査対象定義カテゴリ３２、案件定義名３３、集計期間３４を具備して構成される。

集計対象リソース３１は、制約条件を適用する単位を示しており、「部門ごと」、「ユーザごと」などの単位で指定可能である。図３では「部門ごと」が指定されており、この場合「部門」単位で制約条件が適用される。

調査対象定義カテゴリ３２は、制約条件を適用する対象の処理案件を検索するカテゴリを指定する項目であって、案件定義名３３は、調査対象定義カテゴリ３２で「定義指定」が設定された場合に処理案件に指定された起案定義名を指定する項目である。図３では調査対象定義カテゴリ３２として「定義指定」が示され、案件定義名３３として「資材調達」が示されていることから処理案件の案件種別が「資材調達」であることが示されている。

集計期間３４は、制約条件を適用する処理案件の期間を示しており、図３では「毎週（月曜日始まり）」が示されており、これは月曜日を起点とする一週間内に起案された処理案件を対象としていることを示す。

次に、制約条件の評価内容の設定項目３０３は、制約条件を指定する項目であって、図３には作業属性ごとに申請金額の合計金額が１００万円超過するかを評価することが示されている。

この図３に示す制約条件設定画面によって指定された制約条件は、図５（ｃ）に示すように保管される。

図４には、一括処理の処理内容を設定する画面の一例を示しており、この図４に示す一括処理指定画面を用いて設定された一括処理内容は、図１に示す案件一括処理保管部１４に保管される。

図４に示す一括処理指定画面は、制約条件の名称４０１、一括処理内容の指定項目４０２、設定ボタン４０３、キャンセルボタン４０４から構成され、制約条件の名称４０１に指定された名称を識別情報として一括処理内容の指定項目４０２で指定された項目を保管する。

一括処理内容の指定項目４０２は、一括処理対象案件４１、一括処理内容４２、一括処理詳細項目４３、メール通知ボタン４４を具備して構成される。

一括処理対象案件４１は、一括処理の対象となる案件を指定する項目であって、「全案件」、「未完了案件」、「完了案件」、「詳細設定」などを指定することができる。図４では「全案件」が指定されており、これは一括処理対象案件がいずれの作業にあり、どのような状態であるか（作業が完了した状態や未完了状態）を問わず該当する全ての処理案件を一括処理の対象とするものである。

一括処理内容４２は、一括処理としてどのような処理を行うかを指定する項目であって、「一括移動」、「一括中止」などを指定することができる。また、一括処理詳細項目４３は、一括処理内容４２で指定された項目に対して詳細な情報を指定する項目であり、一括処理内容４２で「一括移動」が指定された場合にはその移動先の作業を指定することができる。

図４に示す例では、一括処理内容４２に「一括移動」が指定され、一括処理詳細項目４３に「部門長承認に移動」が指定されていることから、部門長承認工程２０３に差し戻すことを示す。

この図４に示す一括処理指定画面によって指定された一括処理の設定項目は、図５（ｄ）に示すように保管される。

また、メール通知ボタン４４を押下することにより図７に示すような電子メールの編集が可能となる。

図６は、本願発明の実施の態様における処理の一例を示すフローチャートである。

図６に示すフローチャートは、制約条件を適用する作業で行われる処理の内容を示しており、図２に示すワークフローにおける「制約チェック工程」で行われる処理を示している。

制約チェック工程に処理案件が遷移すると処理が開始され、処理案件に指定された属性値に基づき、制約条件の評価処理を行う（６０１）。

例えば、図５（ｃ）に示すような制約条件（図５（ａ）の[起案定義名]５０２に「資材調達」が指定され、月曜日始まりの一週間ごとに各「部門ごと」に申請された「申請金額」の合計額が「１００万円を超えた」という条件）が設定されている状態で、図５（ｂ）の[属性名]５０６が「申請金額」であって、その[属性名]５０６に対する[属性値]５０８が「５０万円」である処理案件（「資材調達−１」）を受け付けると、申請金額の合計金額が「５０万円」であると評価される。

また、同様の制約条件で、[起案定義名]５０２に「資材調達」が指定された申請金額が「５０万円」である処理案件（「資材調達−１」）と、申請金額が「４０万円」である処理案件（「資材調達−２」）とを評価した状態で、[起案定義名]５０２に「資材調達」が指定された申請金額が「４０万円」である処理案件（「資材調達−３」）を受け付けると、申請金額の合計金額が「１３０万円」と評価される。

このようにして制約条件の評価処理が行われると、続いて、その評価処理によって制約条件が成立したかを判断する（６０２）。制約条件に該当する場合（６０２でＹＥＳ）、例えば上記例の場合で、申請金額の合計額が「１００万円」を超えた場合には、[起案定義名]５０２に「資材調達」が指定された処理案件（処理案件１、処理案件２、処理案件３）に対して一括処理を行う（６０３）。

このときの一括処理の一例として、上記のように全ての処理案件を所定の作業まで差し戻したり、全ての処理案件を中止したりする処理がある。

それに対して、制約条件に該当しない場合（６０２でＮＯ）には、評価対象となった処理案件を次作業へ遷移させる（６０４）。

上記の実施例１で用いた図４に示す画面では、制約条件に合致する全ての処理案件に対し、一括処理を行う場合の例を示しているが、本実施例２では、処理案件の状態に応じて一括処理を指定する方法を示す。本実施例２に示す内容は、実施例１に類似するため異なる点を中心に説明する。

図８は、実施例２における一括処理指定画面の一例を示す図である。なお、図８は実施例１で用いた図４と類似することから図４で用いた符号を使用する。

図８は、一括処理内容の指定項目４０２が複数、設けられた画面であって、一括処理追加ボタン４０５を押下することによってこの一括処理内容の指定項目４０２を追加することができる。

この一括処理内容の指定項目４０２では、一括処理対象案件項目４１で一括処理対象の処理案件の状態を指定し、指定されたその処理案件に対して行う一括処理の処理内容を一括処理内容項目４２と一括処理詳細項目４３で指定する。

図８には、この一括処理内容の指定項目４０２を２つ（４０２−１、４０２−２）表示した例を示している。

一つ目の一括処理内容の指定項目（４０２−１）には、「未完了処理案件」を「部門長承認工程」へ「一括移動」することが示されており、二つ目の一括処理内容の指定項目（４０２−２）には、「完了処理案件」については「何もしない」ことが示されている。

すなわち、図１の集計処理部１７によって、制約条件に該当する処理案件であると評価された場合に、ルーティング管理部１６が未完了の処理案件について、一括して部門長承認工程２０３へ一括移動する一括処理を行い、また、完了処理案件については何もしない。

この図８で設定した一括処理の処理内容は図９（ｄ）に示すように保管される。この図９（ｄ）では、一括処理を行う処理対象案件を示す処理対象項目５１５にそれぞれ「未完了処理案件」、「完了処理案件」が示され、各処理対象項目５１５に対して処理内容項目５１６にそれぞれ「部門長承認工程へ移動」、「何もしない」が示される。

なお、上記では一括処理内容の指定項目４０２の一括処理内容項目４２に「未完了処理案件」、「完了処理案件」を示した場合の例を示しているが、この一括処理内容項目４２ではこれらの他に、「詳細設定」を設定することができる。この「詳細設定」を設定することによって、一括処理の対象となる処理案件を指定する条件に緊急度を設定することができるようになる。この緊急度は、制約条件に合致した処理案件の緊急の度合いを示す値であって、起案時に処理案件に対して指定することができる。

図８の一括処理内容項目４２で「詳細設定」が指定された場合に、緊急度を指定する緊急度項目が表示される。

各処理案件に緊急度を設定した場合の状態を図９（ａ）に示し、図８の一括処理内容項目４２で「詳細設定」が指定され、緊急度が指定された場合の状態を図１０に示す。

図９（ａ）では、図５（ａ）に比べて新たに緊急度項目９０１が設けられており、また、図１０では、図９（ｄ）に比べて新たに緊急度項目９０２が設けられている。

このように図７を用いて、処理案件の状態に応じた制約条件を設定することができるようになる。

この図７を用いて設定された一括処理の処理内容を図１に示す案件一括処理保管部１４で保管する。そして、案件一括処理部１８では対象となる処理案件ごとに指定された一括処理を行う。

本実施例３では、図３に示すような画面を用いて設定した制約条件をワークフローの運用中に随時、変更できるようにした例を示している。

例えば、図３に示す制約条件設定画面の制約条件の評価内容項目３０３の合計金額の項目３９を「１００万円」から「７０万円」に変更した場合、この画面を用いて設定した図５（ｃ）に示す条件項目５１３の「申請金額の合計金額＞１００万円」が「申請金額の合計金額＞７０万円」と変更される。

すなわち、図１に示す制約条件保管部１３に保管された制約条件が変更される。

この制約条件に基づいてチェックする図２に示す制約チェック工程では、図１に示す集計処理部１７がその制約条件に当てはまる処理案件をワークフロー全体から検索し、再度、その制約条件に基づく制約チェックを行う。

例えば、図２のワークフローで処理案件３が起案される前に、処理案件１と処理案件２が経理処理工程に遷移した状態で、制約条件が変更されると、その制約条件が示す処理案件をワークフロー全体から検索する。この検索は上記に示す検索方法によって行われ、処理案件１と処理案件２が検索される。

続いて、集計処理部１７では、この処理案件１と処理案件２の申請金額の合計金額が演算され、この合計金額が７０万円以下であるか評価される。処理案件１の申請金額が５０万円であって処理案件２の申請金額が４０万円であるため合計金額が９０万円と演算され、この合計金額が７０万円を超過していることをルーティング管理部１６へ通知し、ルーティング管理部１６がこの処理案件に対する一括処理要求を案件一括処理部１８へ行う。

そして、この案件一括処理部１８が処理案件１と処理案件２を部門長承認工程２０３に差し戻す一括処理を行う。

すなわち、制約条件の変更をトリガとして、再度制約チェック工程２０２で変更後の制約条件に基づく制約チェックが行われる。

本発明は、上記し、且つ図面に示す実施例に限定することなく、その要旨を変更しない範囲内で適宜変形して実施できるものである。

なお、本発明は、通信機能を備えたフロー管理システムで上述の動作を実行させ、あるいは上述の手段を構成させるためのプログラムを格納した記録媒体（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等）から該プログラムをコンピュータにインストールし、これを実行させることにより、上述の処理を実行する情報管理システムを構成することも可能である。フロー処理システムを構成するコンピュータは、システムバスを介してＣＰＵ（Central Processor Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ハードディスクが接続されている。ＣＰＵは、ＲＯＭまたはハードディスクに記憶されているプログラムに従い、ＲＡＭを作業領域にして処理を行う。

また、プログラムを供給するための媒体は、通信媒体（通信回線、通信システムのように一時的または流動的にプログラムを保持する媒体）でもよい。例えば、通信ネットワークの電子掲示板（ＢＢＳ：Bulletin Board Service）に該プログラムを掲示し、これを通信回線を介して配信するようにしてもよい。

本発明は、ワークフローシステムに設けられた処理工程を遷移する複数の処理案件に対し、制約条件に基づいて処理するものに有用である。

本発明に係わるワークフロー管理プログラムおよびワークフロー管理システムを適用して構成したワークフロー管理システムの処理エンジンの一例を示す構成図。 ワークフローの一例を示す図。 制約条件の設定画面の一例を示す図。 一括処理の指定画面の一例示す図。 テーブル構成の一例を示す図。 本願発明の処理の一例を示すフローチャート。 一括処理が行われた際に関係者に送信する電子メールの一例を示す図。 実施例２における一括処理指定画面の一例を示す図。 テーブル構成の一例を示す他の図。 図９に示す一括処理内容管理テーブルの構成の一例を示す他の図。

符号の説明

１１ ワークフロー定義保管部
１１−１ ワークフロー定義記述アプリケーション
１２ 案件履歴保管部
１２−１ 案件操作アプリケーション
１３ 制約条件保管部
１３−１ 制約条件記述アプリケーション
１４ 案件一括処理保管部
１４−１ 案件一括処理記述アプリケーション
１５ 一括処理メール通知保管部
１５−１ 一括処理メール通知アプリケーション
１６ ルーティング管理部
１７ 集計処理部
１８ 案件一括処理部
２０１ 発注申請工程
２０２ 制約チェック工程
２０３ 部門長承認工程
２０４ 経理処理工程
２０５ 発注工程

Claims (7)

1. コンピュータを、
   複数の作業の手順を規定したワークフローにしたがって処理案件を順次処理する処理手段と、
   前記処理手段で処理する処理案件に対して該処理案件に関連する複数の処理案件に跨る条件を設定する条件設定手段と、
   前記処理案件を処理するに際して前記条件設定手段によって設定した前記条件に該当するか否かを判断する条件判断手段と、
   前記条件判断手段によって前記処理案件が前記条件に該当すると判断された場合は、該処理案件に関連する前記ワークフロー上の処理済みの処理案件を再度処理する案件再処理手段
   として機能させるためのワークフロー管理プログラム。
2. 前記条件設定手段は、
   前記ワークフロー上での前記処理案件の処理状態に応じた条件を設定し、
   前記案件再処理手段は、
   前記条件設定手段によって設定された各処理状態に対する条件ごとに該処理案件に関連する前記ワークフロー上の処理済みの処理案件を再度処理する請求項１記載のワークフロー管理プログラム。
3. 前記条件設定手段によって設定された条件を変更する条件変更手段
   を具備し、
   前記条件判断手段は、
   前記条件変更手段によって前記条件が変更されたとき、当該条件に該当するか否かの判断を行う請求項１または２に記載のワークフロー管理プログラム。
4. 前記案件再処理手段は、
   前記処理案件と属性情報が同一の処理案件を関連する処理案件として再度処理する請求項１から３のいずれかに記載のワークフロー管理プログラム。
5. 前記処理案件に対応して緊急度属性を設定し、
   前記条件判断手段は、
   前記処理案件の緊急度属性が示す緊急度の高いものから順に、前記条件に該当するか否かを判断する請求項１または４に記載のワークフロー管理プログラム。
6. 前記案件再処理手段は、
   前記条件判断手段によって前記処理案件が前記条件に該当しないと判断された場合、該処理案件に関連する前記ワークフロー上の処理済みの処理案件を所定の作業へ戻して再処理する請求項１記載のワークフロー管理プログラム。
7. 複数の作業の手順を規定したワークフローにしたがって処理案件を順次処理する処理手段と、
   前記処理手段で処理する処理案件に対して該処理案件に関連する複数の処理案件に跨る条件を設定する条件設定手段と、
   前記処理案件を処理するに際して前記条件設定手段によって設定した条件に該当するか否かを判断する条件判断手段と、
   前記条件判断手段によって前記処理案件が前記条件に該当しないと判断された場合は、該処理案件に関連する前記ワークフロー上の処理済みの処理案件を再度処理する案件再処理手段と
   を具備するワークフロー管理システム。

Images