JP5266032B2 - ワークフローサーバ、ワークフローサーバの制御方法、プログラム、及び、記録媒体 - Google Patents

Description

本発明は、ワークフローの実行を制御するワークフローサーバに関する。

従来のワークフローシステムでは、多くの場合、ワークフローの画面に必須の入力項目があり、その項目が未入力の場合にはエラーメッセージなどを表示して、再入力を促す構成となっている。

特許文献１では、この再入力を的確に行うことで作業の効率化を計る技術が開示されている。
特開２００８−０７１０８６号公報 特開２００６−２１５９６８号公報

上述したワークフローシステムを使用した業務における「必須項目」とは、あるアクティビティにおいて、入力が必須な項目のことを指している。しかし、本来はその項目の情報は「使用するまでに設定されることが必須」なのであって、入力画面での入力が必須なのはその準備作業にすぎない。

それにもかかわらず、特許文献１を始めとするワークフローシステムでは、入力画面の設計時に、予め以後のワークフロープロセスを踏まえて必須の入力項目を決定しておく必要があるために、以後のワークフロープロセスへのアクティビティの追加や処理順の変更によって、直接関係しないアクティビティの入力画面までも設計の変更が必要となってしまい、ワークフロープロセスの変更に柔軟に対応する妨げとなっている。

また、多くの場合には、あるアクティビティでの入力値は直ちに利用されるとは限らず、もっと後方のアクティビティに遷移する時点までに入力されていればよい項目も存在する。

それにもかかわらず、入力画面において必須チェックなどが行われ、情報の設定を強制されるために、その情報がすべて確定するまでワークフローを進行させることが出来ず、業務全体の効率化を妨げることになっている。

特許文献２では、複数の入力画面で入力された情報を分類し、ある処理で必要な情報が揃った時点で処理を開始することで並列性を高め、業務全体の効率化を計る試みを行っている。しかし、特許文献２においても同一画面上の項目は同じ時点で確定する必要がある。そのため、もっと後方のアクティビティに遷移する時点までに入力されていればよい項目であっても、その項目の入力が滞ると、業務全体の効率が下がってしまうことには変わりがない。

以下、図１５〜図２０を参照して、具体的に説明する。

例えば、図１５のような業務のワークフローがあったとする。

図１５は、業務のワークフローの一例を示す図である。

ワークフローの入力項目としては、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードがある。

Ａ１：商品名、Ｂ１：定価は、２つ目のアクティビティである「課長承認」までに確定している必要があるものとする。

また、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードは、３つ目のアクティビティである「購買」までに入力済みである必要があるものとする。

従来こういった場合には、図１６に示すような画面から、アクティビティ用画面の定義情報として、項目ごとに必須かどうかの設定を行い、その設定情報を図１７のような形式で保持していた。

図１６は、従来のアクティビティ画面に必須項目を設定するＧＵＩの一例を示す図である。

図１７は、アクティビティ画面に必須項目を設定した際の定義情報の一例を示す図である。

この設定情報に従って、１つめのアクティビティである「申請」の完了処理において、Ａ１：商品名とＢ１：定価について入力が完了しているかどうかの必須チェックを行う。また、２つめのアクティビティである「課長承認」の完了処理において、Ａ２：商品コード、Ｂ２：見積価格、Ｃ１：負担部門コードについて入力が完了しているかどうかの必須チェックを行っていた。従来、このような必須チェックによって、３つめのアクティビティである「購買」の開始時点で、必須項目が入力済みであることを担保するようにシステムを作成することが一般的であった。

しかし、このような方法をとっていると、業務ルールが変わったことに伴うワークフロープロセスの変更が行われて、図１８のように、「課長承認」アクティビティと「購買」アクティビティの間に「部長承認」のアクティビティを追加する必要がでてしまった場合には、以下のような設計変更が必要となってしまう。

これまで「課長承認」アクティビティで行っていた、Ａ２：商品コード、Ｃ１：負担部門コードについての必須チェックを、「部長承認」のアクティビティで行うような再設計が必要になってしまう。

この変更を実現するためには、図１９のように「部長承認」のアクティビティ用の画面定義を追加するだけでなく、既存の「課長承認」アクティビティの画面についても修正が必要となり、工数が発生してしまうことになる。その後、別のアクティビティが追加される場合や「部長承認」アクティビティを削除する場合にも同様に、対象のアクティビティの定義情報だけでなく他のアクティビティの定義情報に対しても修正が発生するために工数が加し、修正範囲が広がることによって不具合の可能性が増えてしまう。

なお、図１８は、図１５に示したプロセスに変更があった場合の一例を示す図である。

また、図１９は、図１８の変更を反映する際のアクティビティ画面に必須項目を設定するＧＵＩのイメージを示す図である。

以上示したように、従来のワークフローシステムでは、アクティビティの追加や削除による他のアクティビティの必須チェックの修正が発生してしまい非常に煩雑であった。また、このように、修正範囲が広がることによって、不具合の可能性が増えてしまうといった問題点もあった。

また、例えば、図２０のような業務のワークフローがあったとする。

図２０は、業務のワークフローの一例を示す図である。

ワークフローの入力項目としては、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードがある。

Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格は、２つ目のアクティビティである「課長承認」までに確定している必要があるものとする。

また、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードは、３つ目のアクティビティである「購買」までに入力済みである必要があるものとする。

こういった場合には、従来では、１つめのアクティビティである「申請者」の完了処理において、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格について入力が完了しているかどうかの必須チェックを行い、２つめのアクティビティである「課長承認」の完了処理において、Ｃ１：負担部門コードについて入力が完了しているかどうかの必須チェックを行うことによって、３つめのアクティビティである「購買」開始時点で必須項目が入力済みであることを担保するようにシステムを作成することが一般的である。

しかし、このような構成では、「課長承認」アクティビティ時点では必須でないA2商品コードやB2見積金額が確定するまで「課長承認」アクティビティへの遷移を行うことが出来ず、業務の滞りが発生してしまう。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、アクティビティの追加や削除等が発生して次のアクティビティの必須項目が変更になった場合でも、他のアクティビティの必須チェックの修正なしで動的で柔軟な必須チェックが可能となるとともに、項目の入力済が必須となる時点までその項目の入力を遅延させることができ、それ以外の項目についての承認処理を先に進めることができ、業務全体のスループットを向上することができる仕組を提供することである。

本願発明は、ワークフローの実行を制御するワークフローサーバであって、
ワークフロープロセスを定義したプロセス定義情報と、前記ワークフロープロセスの各アクティビティにおける入力項目を定義した入力項目定義情報と、各アクティビティ毎に遷移する際に入力済みであることが前提となる入力項目を示す前提項目を定義した前提項目定義情報と、を格納する定義情報格納手段と、現在のアクティビティを完了した後、次に遷移するアクティビティの前記前提項目定義情報を取得する前提項目取得手段と、前記次のアクティビティに遷移する前に、該次のアクティビティの入力項目のうち、前記前提項目取得手段で取得した前記前提項目定義情報に定義された前提項目の全ての入力項目が入力されているか判定する判定手段と、前記判定手段により、前記前提項目のうち未入力の入力項目が存在すると判定された場合、前記入力項目定義情報で定義された該前提項目のうち未入力の入力項目を有するアクティビティの実行者に対して入力要求を通知する通知手段と、を有することを特徴とする。

本発明によれば、アクティビティの追加や削除等が発生して次のアクティビティの必須項目が変更になった場合でも、動的で柔軟な必須チェックが可能となる。

また、項目の入力が必須となる時点までその項目の入力を遅延させることができ、それ以外の項目についての承認処理を先に進めることができる。その結果、業務全体のスループットを向上することができる等の効果を奏する。

以下、本発明の実施形態について図面を参照して説明する。

図１は、本発明のワークフローサーバを適用可能なワークフローシステムの一例を示す図である。

図１に示すように、ワークフローシステムでは、少なくとも１つのワークフローサーバ１０１とワークフロークライアント１０２がネットワーク１０３を介して接続されている。

ユーザは、例えばウェブブラウザやクライアントソフトウェアなどを利用して、ワークフロークライアント１０２から、ワークフローサーバ１０１に対して、ワークフロー進行の要求などを行う。

ワークフローサーバ１０１は、ワークフロークライアント１０２からの要求に応じた処理、管理を行い、必要があればワークフロークライアント１０２に対して結果などを送信する。

ワークフローサーバ１０１とワークフロークライアント１０２の間の通信は、通常のＨＴＴＰのリクエストでもよいし、ＳＯＡＰなどを利用したウェブサービスのリクエストでもよい。

図２は、図１に示したワークフローサーバ１０１，ワークフロークライアント１０２のハードウエア構成を示すブロック図である。

図２において、２０１はＣＰＵであり、システムバス２０４に接続される各デバイスを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。

入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。また、印刷装置等では、タッチパネル、ボタン、スイッチ等が挙げられる。

出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶等が挙げられる。

外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。

通信Ｉ／Ｆコントローラ２０８は、ネットワーク１０３を介して外部機器との通信制御処理を実行する。

本発明を実現するためのプログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。

図３は、図１に示したワークフローサーバ１０１において実現される機能構成の一例を示す図である。

図３に示すように、ワークフローサーバ１０１は、その機能構成として、入出力処理部７０１と、ワークフロー進行部７０２と、ワークフロー定義情報格納部７０５と、ワークフロー実行情報格納部７０８を含んでいる。

ワークフロー定義情報格納部７０５は、プロセス定義情報７０９と、アクティビティ入力項目定義情報７０４（図５）と、アクティビティ前提項目定義情報７０３（図６）とを含んでいる。

また、ワークフロー実行情報格納部７０８は、実行済アクティビティ情報７０６（図８）と、ジョブ入力済項目情報７０７（図９）とを含んでいる。

入出力処理部７０１は、ワークフローサーバ１０１の入力コントローラ２０５、又は、通信Ｉ／Ｆコントローラ２０８からの入力情報を受け付ける処理を行う。なお、入出力処理部７０１は、受け付けた入力情報を内容によりワークフロー進行部７０２への要求に変換する。

ワークフロー進行部７０２は、入出力処理部７０１からの要求に応じて、ワークフローの進行を行う。詳細には、ワークフロー進行部７０２は、ワークフロー定義情報格納部７０５に格納されている情報およびワークフロー実行情報格納部７０８に格納されている当該ジョブについての情報を参照し、実行中アクティビティ情報７１０を使用しながらジョブの作成および進行を行い、作成または進行したジョブについての情報をワークフロー実行情報格納部７０８に格納する。

また、ワークフロー進行部７０２は、ジョブの進行において入力情報の不備などがあると、入出力処理部７０１を通して担当者に対する通知を行う。この通知は、入力情報に対する直接結果として示される場合もあれば、メールなど非同期のメッセージングシステムを経由して行われる場合もある。

なお、入出力処理部７０１，ワークフロー進行部７０２は、ワークフローサーバ１０１のＣＰＵ２０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２上で実行することにより実現される機能に対応する。また、実行中アクティビティ情報７１０は、ワークフローサーバ１０１のＲＡＭ２０２内の記憶領域として実装される。さらに、ワークフロー定義情報格納部７０５およびワークフロー実行情報格納部７０８は、ワークフローサーバ１０１の外部メモリ２１１内に構築されるものとする。

以下、図３に示したワークフロー定義情報格納部７０５に格納される情報について説明する。

図４は、ワークフロープロセスの一例を示す図である。

図４に示す例では、アクティビティ１：申請者→アクティビティ２：課長承認→アクティビティ３：購買といった、ワークフロープロセスが定義されている。また、ワークフローの入力項目として、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードが定義されている。

なお、Ａ１：商品名、Ｂ１：定価は、２つ目のアクティビティである「課長承認」に遷移するまでに確定している必要がある（課長承認の前提項目）。また、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードは、３つ目のアクティビティである「購買」に遷移するまでに入力済みである必要がある（購買の前提項目）。

図３に示したプロセス定義情報７０９では、図４に示したようなワークフロープロセスを定義する情報が所定のデータ形式で格納されているものとする。なお、各アクティビティの入力項目の定義はアクティビティ入力項目定義情報７０４（図５）で定義される。また、各アクティビティの前提項目の定義はアクティビティ前提項目定義情報７０３（図６）で定義される。

図５は、図３に示したアクティビティ入力項目定義情報７０４の一例を示す図である。

アクティビティ入力項目定義情報７０４には、図５の１２０１〜１２０３に示すように、アクティビティごとに、入力する項目と、該項目のデータ型が定義されている。

図６は、図３に示したアクティビティ前提項目定義情報７０３の一例を示す図である。

アクティビティ前提項目定義情報７０３には、図６の１１０１〜１１０３に示すように、アクティビティごとに、アクティビティに遷移する際に入力されていることが前提（必須）となる項目（前提項目）が定義されている。

図７は、図６に示したアクティビティ前提項目定義情報７０３の入力画面（アクティビティ前提項目定義画面）の一例を示す図である。

図７（ａ）に示すようなアクティビティ前提項目定義画面から、アクティビティごとに、アクティビティに遷移する際に入力されていることが前提（必須）となる項目（前提項目）にチェックを入れることにより、アクティビティ前提項目定義情報７０３を生成可能となる。

本実施形態では、例えば、業務ルールが変わったことに伴うワークフロープロセスの変更が行われて、図１８に示したように、「課長承認」アクティビティと「購買」アクティビティの間に「部長承認」のアクティビティを追加する必要がでてしまった場合でも、図７（ｂ）に示すように、新たに加わった「部長承認」アクティビティの前提項目を定義するだけでよく、「課長承認」アクティビティについては前提項目の変更を行う必要がない。

従来では、１つめのアクティビティである「申請者」の完了処理において、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格について入力が完了しているかどうかの必須チェックを行い、２つめのアクティビティである「課長承認」の完了処理において、Ｃ１：負担部門コードについて入力が完了しているかどうかの必須チェックを行うことによって、３つめのアクティビティである「購買」の開始時点で必須項目が入力済みであることを担保するようにシステムが作成されていた。

しかしこのような従来の構成では、「課長承認」アクティビティと「購買」アクティビティの間に「部長承認」のアクティビティを追加する必要がでてしまった場合、図１９に示したように、新たに加わった「部長承認」アクティビティの前提項目を定義するだけでなく、「課長承認」アクティビティについても前提項目の変更を行う必要があり、工数が発生してしまっていた。また、その後、別のアクティビティが追加される場合や、「部長承認」アクティビティを削除する場合にも同様に、対象のアクティビティの定義情報だけでなく他のアクティビティの定義情報に対しても修正が発生するため、修正範囲が広がってしまい、不具合の可能性が増えてしまう。

このように、従来の構成では、アクティビティの追加や削除による他のアクティビティの必須チェックの修正が発生して煩雑であったり、修正範囲が広がることによって不具合の可能性が増えてしまっていた。

これに対して、本発明では、上述のように、アクティビティの追加や削除による他のアクティビティの必須チェックの修正の発生を抑えることができる。そのため、修正範囲が広がることもなく、不具合の可能性が増えてしまうといったことも抑制できる。

また、従来の構成では、「課長承認」アクティビティ時点では必須でないＡ２：商品コードやＢ２：見積金額が確定するまで、「課長承認」アクティビティへの遷移を行うことができず、業務の滞りが発生してしまう。

これに対して、本発明では、上述したように、各アクティビティの前提項目を予め設定しておく構成を有することにより、実際利用されるまで入力を遅延できるため、未確定な項目があってもワークフロー自体を進行させておくことが可能になり、全体の効率を挙げることが可能になる。

例えば、申請者は、項目Ａ２の商品コードや項目Ｂ２の見積価格が確定していない段階で、課長承認の前提項目となっている項目Ａ１の商品名と項目Ｂ１の定価を入力して、課長承認にワークフローを進めることができる。そして、項目Ａ２の商品コードと項目Ｂ２の見積価格が必要な「購買」の直前で入力待ち状態のままとなる。そして、申請者が項目Ａ２の商品コードと項目Ｂ２の見積価格を入力した段階で、「購買」にワークフローが進められる。

本発明では、このように、申請者は、項目Ａ２の商品コードと項目Ｂ２の見積価格が確定した段階で、これらの項目を入力して、購買アクティビティにワークフローを進めるといった運用が可能となり、全体の効率を挙げることができる。

なお、図示しないが、図５に示したアクティビティ入力項目定義情報７０４も、図７に示したアクティビティ前提項目定義画面と同様の画面により定義可能である。

以下、図３に示したワークフロー実行情報格納部７０８に格納される情報について説明する。

図８は、図３に示した実行済アクティビティ情報７０６の一例を示す図である。

実行済アクティビティ情報７０６には、図８の１３０１，１３０２に示すように、実行済となったアクティビティごとに、アクティビティ入力項目の入力の入力状態（未入力／入力済）が記憶される。

図９は、図３に示したジョブ入力済項目情報７０７の一例を示す図である。

ジョブ入力済項目情報７０７には、図９に示すように、ワークフロージョブで入力された各項目の情報が保存される。

以下、図１０のフローチャートを参照して、ワークフロー進行部７０２によるアクティビティの完了処理について説明する。

図１０は、図３に示したワークフロー進行部７０２によるアクティビティの完了処理を示したフローチャートである。即ち、本フローチャートの処理は、ワークフローサーバ１０１のＣＰＵ２０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２上で実行することにより実現される。

ワークフロークライアント１０２からの入力を受けて、入出力処理部７０１は、ワークフロー進行部７０２にアクティビティの完了を指示する。そして、入出力処理部７０１を通してアクティビティの完了が指示されると、ワークフロー進行部７０２は、当該アクティビティのための実行中アクティビティ情報７１０を一時的に作成し、ステップＳ８０１に処理を進める。

ステップＳ８０１では、ワークフロー進行部７０２は、入出力処理部７０１から受け取った入力情報を前記実行中アクティビティ情報７１０に格納し、当該アクティビティにおける各項目の入力／未入力の別を判定する。そして、ステップＳ８０２に処理を進める。

ステップＳ８０２では、ワークフロー進行部７０２は、実行中のワークフロージョブに関するジョブ入力済項目情報７０７（図９）をワークフロー実行情報格納部７０８から取得する。

次に、ステップＳ８０３では、ワークフロー進行部７０２は、上記ジョブ入力済項目情報７０７（図９）に、上記Ｓ８０１において実行中アクティビティ情報７１０に格納した入力情報を反映させる。

次に、ステップＳ８０４では、ワークフロー進行部７０２は、ワークフロー定義情報格納部７０５のプロセス定義情報７０９を参照して、現在のアクティビティの直後のアクティビティを特定し、該直後のアクティビティについての必須項目情報（アクティビティ前提項目定義情報７０３）を取得しておく。

そして、ステップＳ８０５において、ワークフロー進行部７０２は、上記Ｓ８０４で取得したアクティビティ前提項目定義情報７０３（図６）で必須となっている項目が、上記ジョブ入力済項目情報７０７（図９）において全て入力済みでとなっているかどうかの判定を行う。

そして、上記Ｓ８０５において、上記アクティビティ前提項目定義情報７０３（図６）で必須となっている項目がジョブ入力済項目情報７０７（図９）において全て入力済みになっていると判断した場合（Ｓ８０５でＹ）、ステップＳ８０６へ処理を進める。

ステップＳ８０６では、ワークフロー進行部７０２は、直後のアクティビティを実行中アクティビティとし、さらにそのアクティビティの状態を「処理待ち状態」とする。即ち、直後のアクティビティにワークフローを遷移させる。なお、アクティビティの状態については、図１３を用いて後述する。

次に、ステップＳ８０７では、ワークフロー進行部７０２は、入出力処理部７０１を通じて次のアクティビティを実行すべきユーザに対してアクティビティが割当てられた旨の通知を行う。なお、通知の方法は、電子メール・インスタントメッセージ・タスクリストへの追加など様々あるが、方法は問わない。

次に、ステップＳ８０８において、ワークフロー進行部７０２は、前記実行中アクティビティ情報７１０を実行済アクティビティ情報７０６としてワークフロー実行情報格納部７０８に格納する。格納できたら処理完了として、入出力処理部７０１に制御を戻す。そして、入出力処理部７０１を介して、「処理待ち状態」のアクティビティを実行すべきユーザが、処理を行うと、再度、本フローチャートの処理が実行される。

一方、上記Ｓ８０５において、直後のアクティビティ前提項目定義情報７０３（図６）で必須となっている項目の中で、ジョブ入力済項目情報７０７（図９）において未入力の項目があると判断した場合（Ｓ８０５でＮ）、ワークフロー進行部７０２は、ステップＳ８１０へ処理を進める。

ステップＳ８１０では、ワークフロー進行部７０２は、上記Ｓ８０４で取得したアクティビティ前提項目定義情報７０３で必須となっている項目の中で未入力の項目が実行中アクティビティ情報７１０の入力項目に含まれているかどうか判定する。

そして、上記Ｓ８１０において、上記Ｓ８０４で取得したアクティビティ前提項目定義情報７０３で必須となっている項目の中で未入力の項目が実行中アクティビティ情報７１０の入力項目に含まれていないと判断した場合には、ワークフロー進行部７０２は、ステップＳ８１１へ処理を進める。

ステップＳ８１１では、ワークフロー進行部７０２は、直後のアクティビティを実行中アクティビティとし、さらにそのアクティビティの状態を「遷移待ち」状態とする。なお、アクティビティの状態については図１３を用いて後述する。

次に、ステップＳ８１２において、ワークフロー進行部７０２は、ワークフロー実行情報格納部７０８に格納されている実行中のワークフロージョブに関する実行済アクティビティ情報７０６（図８）を全て読み出す。

次に、ステップＳ８１３では、ワークフロー進行部７０２は、上記Ｓ８１２で読み出した実行済アクティビティ情報７０６の中から、上記Ｓ８０４で取得したアクティビティ前提項目定義情報７０３で必須となっている項目が含まれ、かつ未入力となっているものを抽出し、ステップＳ８１４へ処理を進める。

ステップＳ８１４では、ワークフロー進行部７０２は、上記Ｓ８１３で抽出した実行済アクティビティ情報７０６の実行者に対して、入出力処理部７０１を通じて、前提項目の入力が未完了であり、そのために処理が待ち状態となっている旨の通知を行い、ステップＳ８０８へ処理を進める。なお、通知の方法は、電子メール・インスタントメッセージ・タスクリストへの追加など様々あるが、方法は問わない。例えば、図１１のようなメッセージが通知される。

なお、図１１は、前提項目の入力が未完了であり処理が待ち状態となっている旨の通知の一例を示す図である。

図１１に示すような、未入力通知画面１９００が、対応するユーザが使用するワークフロークライアント１０２のディスプレイに表示される。

なお、１９０１は「入力画面を開く」ボタンであり、このボタンを指示することにより、後述する図１２に示す処理が開始され、未入力となっている項目に対する入力を行うための入力画面が表示される。

１９０２は「ＵＲＬを保存」ボタンであり、このボタンを指示することにより、未入力となっている項目に対する入力を行うための入力画面のＵＲＬをワークフロークライアント１０２の外部メモリに保存することができる。

以下、図１０のフローチャートの説明に戻る。

次に、ステップＳ８０８において、ワークフロー進行部７０２は、前記実行中アクティビティ情報７１０を実行済アクティビティ情報７０６としてワークフロー実行情報格納部７０８に格納する。格納できたら処理完了として、入出力処理部７０１に制御を戻す。

一方、上記Ｓ８１０において、上記Ｓ８０４で取得したアクティビティ前提項目定義情報７０３で必須となっている項目の中で未入力の項目が実行中アクティビティ情報７１０の入力項目に含まれていると判断した場合には、ワークフロー進行部７０２は、ステップＳ８２０へ処理を進める。

ステップＳ８２０では、ワークフロー進行部７０２は、現在のアクティビティを実行中アクティビティとし、さらにそのアクティビティの状態を「処理待ち状態」とする。アクティビティの状態については図１３を用いて後述する。

ステップＳ８２１では、ワークフロー進行部７０２は、入出力処理部７０１を通じて前記実行中アクティビティ情報７１０の実行者に対して必須項目が未入力である旨の警告通知を行う。警告通知の方法はエラーメッセージなどが一般的であるが、他の通知同様方法は問わない。

ステップＳ８２２では、ワークフロー進行部７０２は、前記実行中アクティビティ情報７１０を破棄し、処理完了として、入出力処理部７０１に制御を戻す。そして、入出力処理部７０１を介して、「処理待ち状態」のアクティビティを実行すべきユーザが、直後のアクティビティの前提項目の中で未入力の項目の入力処理等を行うと、再度、本フローチャートの処理が実行される。

次に、より具体的な例をあげながら図１０のフローを説明する。図４に示したようなプロセス定義のワークフローにおいて、ユーザＡが申請処理を行う場合を例にあげる。

アクティビティ１：申請の入力項目は、アクティビティ入力項目定義情報７０４に図５の１２０１のように定義されているため、項目Ａ１、項目Ａ２、項目Ｂ１、項目Ｂ２が入力可能である。

ユーザＡが項目Ａ１、項目Ｂ１を入力して申請を完了させた場合、ステップＳ８０１では、実行中アクティビティ情報７１０に項目Ａ１、項目Ｂ１のみが格納される。なお、ワークフロー開始直後のため、ジョブ入力済項目情報１４０１では、ジョブＩＤ１４０２に、開始したワークフロージョブのＩＤ「１００００」が格納されている以外は全て空欄である。

そこに、前記実行中アクティビティ情報７１０を反映すると、項目Ａ１（１４０３）と項目Ｂ１（１４０５）にそれぞれユーザＡの入力値「業務用ＰＣ」、「199,800」が反映される（ステップＳ８０３）。

ステップＳ８０４で取得する遷移先アクティビティの前提項目定義情報７０３は、図６の１１０２のように前提項目としてＡ１とＢ１が指定されているので、ステップＳ８０５では、前記ジョブ入力済項目情報にＡ１とＢ１が入力済みかどうかの判定を行う。この判定はＹＥＳとなるので、ステップＳ８０６へ進んで、アクティビティの遷移を完了し、該遷移先の担当者への通知を行う（ステップＳ８０７）。

その後、前記実行中アクティビティ情報７１０の内容をアクティビティ１：申請の実行済みアクティビティ情報として保存格納する（図５の１２０１）。この時点で前記実行済みアクティビティは、図８の１３０１ように、項目Ａ１、項目Ｂ１のみが入力済みとなる。このように、ユーザＡが４つの入力項目（Ａ１、Ａ２、Ｂ１、Ｂ２）の全てではなく、少なくとも直後のアクティビティの前提項目（Ａ１、Ｂ１）のみを入力するだけで、次のアクティビティへの遷移を行うことが可能となる。

次のアクティビティ２：課長承認の入力項目は、アクティビティ入力項目定義情報７０４に図５の１２０２のように定義されているため、当該アクティビティを実行すべきユーザ（課長Ｂとする）は項目Ｃ１が入力可能である。

課長Ｂが、項目Ｃ１を入力せずに承認を完了させた場合、ステップＳ８０１では実行中アクティビティ情報７１０は全て空欄となる（ステップＳ８０１）。ジョブ入力済項目情報１４０１には、ユーザＡが入力した項目Ａ１、項目Ｂ１が入力された状態（ステップＳ８０２）であり、実行中アクティビティ情報７１０を反映させても状態は変わらない（ステップＳ８０３）。

遷移先アクティビティであるアクティビティ３：購買のアクティビティ前提項目定義情報７０３は、図６の１１０３のように前提項目として項目Ａ１、項目Ａ２、項目Ｂ１、項目Ｂ２、項目Ｃ１が指定されているので、ステップＳ８０５では、前記ジョブ入力済項目情報にこれら全てが入力済みかどうかの判定を行う。この場合、判定はＮＯとなるので、ステップＳ８１０に進む。

ステップＳ８１０では、当該アクティビティの入力項目１２０２に定義されている項目Ｃ１と、ステップＳ８０５で未入力と判断された項目Ａ２、項目Ｂ２、項目Ｃ１の比較を行う。項目Ｃ１が一致するので実行中アクティビティの入力項目が未入力である（ＹＥＳ）と判断し、ステップＳ８２０へ進み、実行者である課長Ｂに当該項目が未入力であることを警告する。このように、直後のアクティビティが前提としている項目が未入力の場合には、直ちに警告を行うことが可能である。

なお、課長Ｂが項目Ｃ１を入力して承認を完了させた場合でも、遷移先の前提項目のうち項目Ａ２、項目Ｂ２が未入力となるため、ステップＳ８１０へ進む。ステップＳ８１０では、当該アクティビティの入力項目１２０２に定義されている項目Ｃ１と、ステップＳ８０５で未入力だった項目Ａ２、項目Ｂ２の比較を行う。この場合、一致する項目がないためＮＯと判断し、次のアクティビティを遷移待ち状態とする（ステップＳ８１１）。

次に、このワークフロージョブの実行済アクティビティ情報を全て取得し（ステップＳ８１２）、ステップＳ８０５で未入力だった項目Ａ２、項目Ｂ２が未入力のままとなっているアクティビティを探す。この例では、アクティビティ１：申請がそれにあたるため、その実行者であるユーザＡに対して、未入力項目があることを通知し（ステップＳ８１４）、課長承認の処理が完了する。

このように、あるアクティビティが前提としている項目が入力されるまで、そのアクティビティへの遷移を保留することが可能である。

以下、図１２のフローチャートを参照して、図１０のステップＳ８１４の遷移待ち通知に応じた必須項目の遅延入力処理について説明する。

図１２は、図１０のステップＳ８１４の遷移待ち通知に応じた必須項目の遅延入力処理を示したフローチャートである。即ち、本フローチャートの処理は、ワークフローサーバ１０１のＣＰＵ２０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２上で実行することにより実現される。

図１０のステップＳ８１４の通知を受けたユーザが、「入力画面を開く」ボタン１９０１を指示すると（又は、Ｓ８１４の通知から保存されたＵＲＬへのアクセスすると）、ワークフロークライアント１０２は、未入力通知に対する入力要求をワークフローサーバ１０１に送信する。この未入力通知に対する入力要求を入出力処理部７０１を介して受信すると、ワークフロー進行部７０２は、図１２に示すフローチャートの処理を開始する。

また、ワークフロークライアント１０２から図１０のステップＳ８１４の通知から保存されたＵＲＬへのアクセスを受信した場合も、ワークフロー進行部７０２は、図１２に示すフローチャートの処理を開始する。

まず、ステップＳ９０１では、ワークフロー進行部７０２は、ワークフロー実行情報格納部７０８から該当する実行済アクティビティ情報７０６を取得し、入出力処理部７０１を介して該当するアクティビティの入力画面（フォーム）をクライアントに送信し、ステップＳ９０２へ処理を進める。

これにより、ワークフロークライアント１０２では、該当するアクティビティのフォームが表示され、ユーザ入力可能となる（Ｓ９０２）。そして、ワークフロークライアント１０２から入力処理がなされ、入出力処理部７０１を介して、アクティビティの完了が指示されると、ワークフロー進行部７０２は、ステップＳ９０３に処理を進める。

ステップＳ９０３では、ワークフロー進行部７０２は、入出力処理部７０１から受け取った入力情報を前記実行中アクティビティ情報７１０に格納し、当該アクティビティにおける各項目の入力／未入力の別を判定する。そして、ステップＳ９０４に処理を進める。

ステップＳ９０４では、ワークフロー進行部７０２は、ワークフロー実行情報格納部７０８に格納してある実行中のワークフロージョブに関するジョブ入力済項目情報７０７（図９）に、上記Ｓ９０３において実行中アクティビティ情報７１０に格納した入力情報を反映させる。

次に、ステップＳ９０５では、ワークフロー進行部７０２は、ワークフロー定義情報格納部７０５から遷移待ち状態のアクティビティについての必須項目情報（アクティビティ前提項目定義情報７０３）を取得しておく。

そして、ステップＳ９０６において、ワークフロー進行部７０２は、上記Ｓ９０５で取得したアクティビティ前提項目定義情報７０３（図６）で必須となっている項目が、上記ジョブ入力済項目情報７０７（図９）において全て入力済みでとなっているかどうかの判定を行う。

そして、上記Ｓ９０６において、上記アクティビティ前提項目定義情報７０３（図６）で必須となっている項目がジョブ入力済項目情報７０７（図９）において全て入力済みになっていると判断した場合（Ｓ９０６でＹ）、ステップＳ９０７へ処理を進める。

ステップＳ９０７では、ワークフロー進行部７０２は、遷移待ち状態のアクティビティを実行中アクティビティとし、さらにそのアクティビティの状態を「処理待ち状態」とする。即ち、直後のアクティビティにワークフローを遷移させる。なお、アクティビティの状態については、図１３を用いて後述する。

次に、ステップＳ９０８では、ワークフロー進行部７０２は、入出力処理部７０１を通じて次にアクティビティを実行すべきユーザに対してアクティビティが割当てられた旨の通知を行う。なお、通知の方法は、電子メール・インスタントメッセージ・タスクリストへの追加など様々あるが、方法は問わない。

次に、ステップＳ９０９において、ワークフロー進行部７０２は、前記実行中アクティビティ情報７１０を実行済アクティビティ情報７０６としてワークフロー実行情報格納部７０８に格納する。格納できたら処理完了として、入出力処理部７０１に制御を戻す。そして、入出力処理部７０１を介して、「処理待ち状態」のアクティビティを実行すべきユーザが、処理を行うと、図１０に示したフローチャートの処理が実行される。

一方、上記Ｓ９０６において、遷移待ち状態のアクティビティ前提項目定義情報７０３（図６）で必須となっている項目の中で、ジョブ入力済項目情報７０７（図９）において未入力の項目があると判断した場合（Ｓ９０６でＮ）、ワークフロー進行部７０２は、ステップＳ９１０へ処理を進める。

なお、ステップＳ９１０〜Ｓ９２２では、未入力項目があった場合の処理を行うが、これは図１０のステップＳ８１０〜Ｓ８２２までと同様であるので説明は省略する。

図１３は、アクティビティの状態について表したものである。

図１３において、遷移元のアクティビティの完了１００１によって、次のアクティビティの実体が作成され、「遷移待ち状態」１０１０となる。

遷移待ち状態１０１０では、そのアクティビティが実行中アクティビティではあるものの遷移が完全には完了していない状態のため、担当者への通知やタスクリストへの表示はまだ行われていない。

遷移待ち状態１０１０の際には、遷移完了処理１００２によって、「処理待ち状態」１０１１となる。なお、処理待ち状態１０１１は、担当者による項目の入力や承認を待っている状態である。

処理待ち状態１０１１の時に、入力処理１００３を行うと、図１０のような完了処理が行われ、そのアクティビティ自体は「処理完了状態」１０１２となって、実行中アクティビティは次のアクティビティとなる。

以上のような構成により、次のアクティビティの必須項目が変更になった場合にも動的で柔軟な必須チェックが可能であるとともに、本当にその項目の入力済が必須となる時点まで、入力の遅延を許可することにより、それ以外の項目についての承認処理を先に進めることが可能となる。その結果、業務全体のスループットを向上することができる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

以上のように、アクティビティの追加や削除等が発生した場合でも、他のアクティビティの必須チェックに修正がおよぶことを回避することができる。また、項目の入力済が必須となる時点までその項目の入力の遅延を許可して、業務全体のスループットを向上することができる。

以下、図１４に示すメモリマップを参照して、本発明に係るワークフローサーバとしてコンピュータを機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体（記憶媒体）の構成について説明する。

図１４は、本発明に係るワークフローサーバとしてコンピュータを機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体（記憶媒体）のメモリマップを説明する図である。

なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図１０，図１２に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。

プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

なお、上述した各実施形態の変形例を組み合わせた構成も全て本発明に含まれるものである。

本発明のワークフローサーバを適用可能なワークフローシステムの一例を示す図である。 図１に示したワークフローサーバ１０１，ワークフロークライアント１０２のハードウエア構成を示すブロック図である。 図１に示したワークフローサーバ１０１において実現される機能構成の一例を示す図である。 ワークフロープロセスの一例を示す図である。 図３に示したアクティビティ入力項目定義情報７０４の一例を示す図である。 図３に示したアクティビティ前提項目定義情報７０３の一例を示す図である。 図６に示したアクティビティ前提項目定義情報７０３の入力画面（アクティビティ前提項目定義画面）の一例を示す図である。 図３に示した実行済アクティビティ情報７０６の一例を示す図である。 図３に示したジョブ入力済項目情報７０７の一例を示す図である。 図３に示したワークフロー進行部７０２によるアクティビティの完了処理を示したフローチャートである。 図１１は、前提項目の入力が未完了であり処理が待ち状態となっている旨の通知の一例を示す図である。 図１０のステップＳ８１４の遷移待ち通知に応じた必須項目の遅延入力処理を示したフローチャートである。 アクティビティの状態について表したものである。 本発明に係るワークフローサーバとしてコンピュータを機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体（記憶媒体）のメモリマップを説明する図である。 業務のワークフローの一例を示す図である。 従来のアクティビティ画面に必須項目を設定するＧＵＩの一例を示す図である。 アクティビティ画面に必須項目を設定した際の定義情報の一例を示す図である。 図１５に示したプロセスに変更があった場合の一例を示す図である。 図１８の変更を反映する際のアクティビティ画面に必須項目を設定するＧＵＩのイメージを示す図である。 業務のワークフローの一例を示す図である。

符号の説明

１０１ ワークフローサーバ
１０２ ワークフロークライアント
１０３ ネットワーク
２０１ ＣＰＵ
２０２ ＲＡＭ
２１１ 外部メモリ
２１２ プログラム
７０１ 入出力処理部
７０２ ワークフロー進行部
７０３ アクティビティ前提項目定義情報
７０４ アクティビティ入力項目定義情報
７０５ ワークフロー定義情報格納部
７０６ 実行済アクティビティ情報
７０７ ジョブ入力済項目情報
７０８ ワークフロー実行情報格納部
７０９ プロセス定義情報
７１０ 実行中アクティビティ情報

Claims (7)

1. ワークフローの実行を制御するワークフローサーバであって、
   ワークフロープロセスを定義したプロセス定義情報と、前記ワークフロープロセスの各アクティビティにおける入力項目を定義した入力項目定義情報と、各アクティビティ毎に遷移する際に入力済みであることが前提となる入力項目を示す前提項目を定義した前提項目定義情報と、を格納する定義情報格納手段と、
   現在のアクティビティを完了した後、次に遷移するアクティビティの前記前提項目定義情報を取得する前提項目取得手段と、
   前記次のアクティビティに遷移する前に、該次のアクティビティの入力項目のうち、前記前提項目取得手段で取得した前記前提項目定義情報に定義された前提項目の全ての入力項目が入力されているか判定する判定手段と、
   前記判定手段により、前記前提項目のうち未入力の入力項目が存在すると判定された場合、前記入力項目定義情報で定義された該前提項目のうち未入力の入力項目を有するアクティビティの実行者に対して入力要求を通知する通知手段と、
   を有することを特徴とするワークフローサーバ。
2. 前記判定手段により、前記前提項目のうち未入力の入力項目が存在すると判定された場合、前記入力項目定義情報で定義された該未入力の入力項目の入力担当が前記完了したアクティビティの入力担当であるかを判定するアクティビティ入力判定手段と、
   前記アクティビティ入力判定手段により、前記未入力の入力項目の入力担当が前記完了したアクティビティの入力担当でないと判定された場合、該未入力の入力項目の入力担当に対して入力要求を通知する遅延入力通知手段と、
   を有することを特徴とする請求項１に記載のワークフローサーバ。
3. 前記通知手段は、前記アクティビティ入力判定手段により、前記未入力の入力項目の入力担当が前記完了したアクティビティの入力担当であると判定された場合、該完了したアクティビティの入力担当に対して、該未入力の入力項目の入力要求を通知することを特徴とする請求項１または２に記載のワークフローサーバ。
4. 前記判定手段は、前記通知手段による通知に応じて処理された現在のアクティビティを完了する際にも、前記前提項目定義情報に定義された次に遷移するアクティビティに対する前提項目が全て入力されたか否かを判定することを特徴とする請求項１乃至３に記載のワークフローサーバ。
5. ワークフローの実行を制御するワークフローサーバの制御方法であって、
   定義手段が、ワークフロープロセスを定義したプロセス定義情報と、前記ワークフロープロセスの各アクティビティにおける入力項目を定義した入力項目定義情報と、各アクティビティ毎に遷移する際に入力済みであることが前提となる入力項目を示す前提項目を定義した前提項目定義情報と、を定義情報格納手段に格納させる定義ステップと、
   前提項目取得手段が、現在のアクティビティを完了した後、次に遷移するアクティビティの前記前提項目定義情報を取得する前提項目取得ステップと、
   判定手段が、前記次のアクティビティに遷移する前に、該次のアクティビティの入力項目のうち、前記前提項目取得ステップで取得した前記前提項目定義情報に定義された前提項目の全ての入力項目が入力されているか判定する判定ステップと、
   通知手段が、前記判定ステップで、前記前提項目のうち未入力の入力項目が存在すると判定された場合、前記入力項目定義情報で定義された該前提項目のうち未入力の入力項目を有するアクティビティの実行者に対して入力要求を通知する通知ステップと、
   を有することを特徴とするワークフローサーバの制御方法。
6. ワークフローの実行を制御するワークフローサーバを、
   ワークフロープロセスを定義したプロセス定義情報と、前記ワークフロープロセスの各アクティビティにおける入力項目を定義した入力項目定義情報と、各アクティビティ毎に遷移する際に入力済みであることが前提となる入力項目を示す前提項目を定義した前提項目定義情報と、を格納する定義情報格納手段、
   現在のアクティビティを完了した後、次に遷移するアクティビティの前記前提項目定義情報を取得する前提項目取得手段、
   前記次のアクティビティに遷移する前に、該次のアクティビティの入力項目のうち、前記前提項目取得手段で取得した前記前提項目定義情報に定義された前提項目の全ての入力項目が入力されているか判定する判定手段、
   前記判定手段により、前記前提項目のうち未入力の入力項目が存在すると判定された場合、前記入力項目定義情報で定義された該前提項目のうち未入力の入力項目を有するアクティビティの実行者に対して入力要求を通知する通知手段、
   として機能させるためのプログラム。
7. 請求項６に記載されたプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images