(57)【要約】【課題】アクティビティの追加や削除等が発生した場合でも、他のアクティビティの必須チェックに修正がおよぶことを回避すること。また、項目の入力済が必須となる時点までその項目の入力の遅延を許可して、業務全体のスループットを向上すること。【解決手段】ワークフロー進行部７０２は、現在のアクティビティを完了する際、アクティビティ前提項目定義情報７０３に定義された次に遷移するアクティビティに対する前提項目が全て入力されているか判定し、前提項目が全て入力されている場合、前記現在のアクティビティを完了して、次のアクティビティに遷移させ、一方、前提項目のうち未入力の入力項目が存在する場合、該未入力の入力項目への入力要求を、アクティビティ入力項目定義情報７０４で前記未入力の入力項目の入力が定義されたアクティビティを実行する実行者の通知先に対して通知する。【選択図】図３
2010140231.tif 000002
【特許請求の範囲】
【請求項１】
ワークフローの実行を制御するワークフローサーバであって、
ワークフロープロセスを定義したプロセス定義情報と、ワークフロープロセスの各アクティビティにおける入力項目を定義した入力項目定義情報と、各アクティビティへ遷移する際に入力済みであることが前提となる入力項目を示す前提項目を定義した前提項目定義情報を格納する定義情報格納手段と、
現在のアクティビティを完了する際、前記前提項目定義情報に定義された次に遷移するアクティビティに対する前提項目が全て入力されたか否かを判定する判定手段と、
前記判定手段により次に遷移するアクティビティに対する前提項目が全て入力されたと判定された場合、前記現在のアクティビティを完了して、次のアクティビティに遷移させる遷移手段と、
前記判定手段により次に遷移するアクティビティに対する前提項目のうち未入力の入力項目が存在すると判定された場合、該未入力の入力項目への入力要求を、前記入力項目定義情報で前記未入力の入力項目の入力が定義されたアクティビティを実行する実行者の通知先に対して通知する通知手段と、
を有することを特徴とするワークフローサーバ。
【請求項２】
前記未入力の入力項目が前記現在のアクティビティの入力項目でない場合、前記現在のアクティビティを完了して、該未入力の入力項目への入力要求を、前記入力項目定義情報で前記未入力の入力項目の入力が定義された完了済みのアクティビティを実行する実行者の通知先に対して通知することを特徴とする請求項１に記載のワークフローサーバ。
【請求項３】
前記判定手段は、前記通知手段による通知に応じて処理された現在のアクティビティを完了する際にも、前記前提項目定義情報に定義された次に遷移するアクティビティに対する前提項目が全て入力されたか否かを判定することを特徴とする請求項２に記載のワークフローサーバ。
【請求項４】
前記通知手段は、前記未入力の入力項目が前記現在のアクティビティの入力項目である場合、前記現在のアクティビティを完了することなく、該未入力の入力項目への入力要求を、現在のアクティビティを実行する実行者の通知先に対して通知することを特徴とする請求項１乃至３のいずれか１項に記載のワークフローサーバ。
【請求項５】
ワークフローの実行を制御するワークフローサーバの制御方法であって、
定義手段が、ワークフロープロセスを定義したプロセス定義情報と、ワークフロープロセスの各アクティビティにおける入力項目を定義した入力項目定義情報と、各アクティビティへ遷移する際に入力済みであることが前提となる入力項目を示す前提項目を定義した前提項目定義情報を定義情報格納手段に格納させる定義ステップと、
判定手段が、現在のアクティビティを完了する際、前記前提項目定義情報に定義された次に遷移するアクティビティに対する前提項目が全て入力されたか否かを判定する判定ステップと、
遷移手段が、前記判定ステップで次に遷移するアクティビティに対する前提項目が全て入力されたと判定された場合、前記現在のアクティビティを完了して、次のアクティビティに遷移させる遷移ステップと、
通知手段が、前記判定ステップで次に遷移するアクティビティに対する前提項目のうち未入力の入力項目が存在すると判定された場合、該未入力の入力項目への入力要求を、前記入力項目定義情報で前記未入力の入力項目の入力が定義されたアクティビティを実行する実行者の通知先に対して通知する通知ステップと、
を有することを特徴とするワークフローサーバの制御方法。
【請求項６】
ワークフローの実行を制御するワークフローサーバを、
ワークフロープロセスを定義したプロセス定義情報と、ワークフロープロセスの各アクティビティにおける入力項目を定義した入力項目定義情報と、各アクティビティへ遷移する際に入力済みであることが前提となる入力項目を示す前提項目を定義した前提項目定義情報を格納する定義情報格納手段、
現在のアクティビティを完了する際、前記前提項目定義情報に定義された次に遷移するアクティビティに対する前提項目が全て入力されたか否かを判定する判定手段、
前記判定手段により次に遷移するアクティビティに対する前提項目が全て入力されたと判定された場合、前記現在のアクティビティを完了して、次のアクティビティに遷移させる遷移手段、
前記判定手段により次に遷移するアクティビティに対する前提項目のうち未入力の入力項目が存在すると判定された場合、該未入力の入力項目への入力要求を、前記入力項目定義情報で前記未入力の入力項目の入力が定義されたアクティビティを実行する実行者の通知先に対して通知する通知手段、
として機能させるためのプログラム。
【請求項７】
請求項６に記載されたプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワークフローの実行を制御するワークフローサーバに関する。
【背景技術】
【０００２】
従来のワークフローシステムでは、多くの場合、ワークフローの画面に必須の入力項目があり、その項目が未入力の場合にはエラーメッセージなどを表示して、再入力を促す構成となっている。
【０００３】
特許文献１では、この再入力を的確に行うことで作業の効率化を計る技術が開示されている。
【特許文献１】特開２００８−０７１０８６号公報
【特許文献２】特開２００６−２１５９６８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したワークフローシステムを使用した業務における「必須項目」とは、あるアクティビティにおいて、入力が必須な項目のことを指している。しかし、本来はその項目の情報は「使用するまでに設定されることが必須」なのであって、入力画面での入力が必須なのはその準備作業にすぎない。
【０００５】
それにもかかわらず、特許文献１を始めとするワークフローシステムでは、入力画面の設計時に、予め以後のワークフロープロセスを踏まえて必須の入力項目を決定しておく必要があるために、以後のワークフロープロセスへのアクティビティの追加や処理順の変更によって、直接関係しないアクティビティの入力画面までも設計の変更が必要となってしまい、ワークフロープロセスの変更に柔軟に対応する妨げとなっている。
【０００６】
また、多くの場合には、あるアクティビティでの入力値は直ちに利用されるとは限らず、もっと後方のアクティビティに遷移する時点までに入力されていればよい項目も存在する。
【０００７】
それにもかかわらず、入力画面において必須チェックなどが行われ、情報の設定を強制されるために、その情報がすべて確定するまでワークフローを進行させることが出来ず、業務全体の効率化を妨げることになっている。
【０００８】
特許文献２では、複数の入力画面で入力された情報を分類し、ある処理で必要な情報が揃った時点で処理を開始することで並列性を高め、業務全体の効率化を計る試みを行っている。しかし、特許文献２においても同一画面上の項目は同じ時点で確定する必要がある。そのため、もっと後方のアクティビティに遷移する時点までに入力されていればよい項目であっても、その項目の入力が滞ると、業務全体の効率が下がってしまうことには変わりがない。
【０００９】
以下、図１５〜図２０を参照して、具体的に説明する。
【００１０】
例えば、図１５のような業務のワークフローがあったとする。
【００１１】
図１５は、業務のワークフローの一例を示す図である。
【００１２】
ワークフローの入力項目としては、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードがある。
【００１３】
Ａ１：商品名、Ｂ１：定価は、２つ目のアクティビティである「課長承認」までに確定している必要があるものとする。
【００１４】
また、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードは、３つ目のアクティビティである「購買」までに入力済みである必要があるものとする。
【００１５】
従来こういった場合には、図１６に示すような画面から、アクティビティ用画面の定義情報として、項目ごとに必須かどうかの設定を行い、その設定情報を図１７のような形式で保持していた。
【００１６】
図１６は、従来のアクティビティ画面に必須項目を設定するＧＵＩの一例を示す図である。
【００１７】
図１７は、アクティビティ画面に必須項目を設定した際の定義情報の一例を示す図である。
【００１８】
この設定情報に従って、１つめのアクティビティである「申請」の完了処理において、Ａ１：商品名とＢ１：定価について入力が完了しているかどうかの必須チェックを行う。また、２つめのアクティビティである「課長承認」の完了処理において、Ａ２：商品コード、Ｂ２：見積価格、Ｃ１：負担部門コードについて入力が完了しているかどうかの必須チェックを行っていた。従来、このような必須チェックによって、３つめのアクティビティである「購買」の開始時点で、必須項目が入力済みであることを担保するようにシステムを作成することが一般的であった。
【００１９】
しかし、このような方法をとっていると、業務ルールが変わったことに伴うワークフロープロセスの変更が行われて、図１８のように、「課長承認」アクティビティと「購買」アクティビティの間に「部長承認」のアクティビティを追加する必要がでてしまった場合には、以下のような設計変更が必要となってしまう。
【００２０】
これまで「課長承認」アクティビティで行っていた、Ａ２：商品コード、Ｃ１：負担部門コードについての必須チェックを、「部長承認」のアクティビティで行うような再設計が必要になってしまう。
【００２１】
この変更を実現するためには、図１９のように「部長承認」のアクティビティ用の画面定義を追加するだけでなく、既存の「課長承認」アクティビティの画面についても修正が必要となり、工数が発生してしまうことになる。その後、別のアクティビティが追加される場合や「部長承認」アクティビティを削除する場合にも同様に、対象のアクティビティの定義情報だけでなく他のアクティビティの定義情報に対しても修正が発生するために工数が加し、修正範囲が広がることによって不具合の可能性が増えてしまう。
【００２２】
なお、図１８は、図１５に示したプロセスに変更があった場合の一例を示す図である。
【００２３】
また、図１９は、図１８の変更を反映する際のアクティビティ画面に必須項目を設定するＧＵＩのイメージを示す図である。
【００２４】
以上示したように、従来のワークフローシステムでは、アクティビティの追加や削除による他のアクティビティの必須チェックの修正が発生してしまい非常に煩雑であった。また、このように、修正範囲が広がることによって、不具合の可能性が増えてしまうといった問題点もあった。
【００２５】
また、例えば、図２０のような業務のワークフローがあったとする。
【００２６】
図２０は、業務のワークフローの一例を示す図である。
【００２７】
ワークフローの入力項目としては、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードがある。
【００２８】
Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格は、２つ目のアクティビティである「課長承認」までに確定している必要があるものとする。
【００２９】
また、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードは、３つ目のアクティビティである「購買」までに入力済みである必要があるものとする。
【００３０】
こういった場合には、従来では、１つめのアクティビティである「申請者」の完了処理において、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格について入力が完了しているかどうかの必須チェックを行い、２つめのアクティビティである「課長承認」の完了処理において、Ｃ１：負担部門コードについて入力が完了しているかどうかの必須チェックを行うことによって、３つめのアクティビティである「購買」開始時点で必須項目が入力済みであることを担保するようにシステムを作成することが一般的である。
【００３１】
しかし、このような構成では、「課長承認」アクティビティ時点では必須でないA2商品コードやB2見積金額が確定するまで「課長承認」アクティビティへの遷移を行うことが出来ず、業務の滞りが発生してしまう。
【００３２】
本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、アクティビティの追加や削除等が発生して次のアクティビティの必須項目が変更になった場合でも、他のアクティビティの必須チェックの修正なしで動的で柔軟な必須チェックが可能となるとともに、項目の入力済が必須となる時点までその項目の入力を遅延させることができ、それ以外の項目についての承認処理を先に進めることができ、業務全体のスループットを向上することができる仕組を提供することである。
【課題を解決するための手段】
【００３３】
本発明は、ワークフローの実行を制御するワークフローサーバであって、ワークフロープロセスを定義したプロセス定義情報と、ワークフロープロセスの各アクティビティにおける入力項目を定義した入力項目定義情報と、各アクティビティへ遷移する際に入力済みであることが前提となる入力項目を示す前提項目を定義した前提項目定義情報を格納する定義情報格納手段と、現在のアクティビティを完了する際、前記前提項目定義情報に定義された次に遷移するアクティビティに対する前提項目が全て入力されたか否かを判定する判定手段と、前記判定手段により次に遷移するアクティビティに対する前提項目が全て入力されたと判定された場合、前記現在のアクティビティを完了して、次のアクティビティに遷移させる遷移手段と、前記判定手段により次に遷移するアクティビティに対する前提項目のうち未入力の入力項目が存在すると判定された場合、該未入力の入力項目への入力要求を、前記入力項目定義情報で前記未入力の入力項目の入力が定義されたアクティビティを実行する実行者の通知先に対して通知する通知手段とを有することを特徴とする。
【発明の効果】
【００３４】
本発明によれば、アクティビティの追加や削除等が発生して次のアクティビティの必須項目が変更になった場合でも、動的で柔軟な必須チェックが可能となる。
【００３５】
また、項目の入力が必須となる時点までその項目の入力を遅延させることができ、それ以外の項目についての承認処理を先に進めることができる。その結果、業務全体のスループットを向上することができる等の効果を奏する。
【発明を実施するための最良の形態】
【００３６】
以下、本発明の実施形態について図面を参照して説明する。
【００３７】
図１は、本発明のワークフローサーバを適用可能なワークフローシステムの一例を示す図である。
【００３８】
図１に示すように、ワークフローシステムでは、少なくとも１つのワークフローサーバ１０１とワークフロークライアント１０２がネットワーク１０３を介して接続されている。
【００３９】
ユーザは、例えばウェブブラウザやクライアントソフトウェアなどを利用して、ワークフロークライアント１０２から、ワークフローサーバ１０１に対して、ワークフロー進行の要求などを行う。
【００４０】
ワークフローサーバ１０１は、ワークフロークライアント１０２からの要求に応じた処理、管理を行い、必要があればワークフロークライアント１０２に対して結果などを送信する。
【００４１】
ワークフローサーバ１０１とワークフロークライアント１０２の間の通信は、通常のＨＴＴＰのリクエストでもよいし、ＳＯＡＰなどを利用したウェブサービスのリクエストでもよい。
【００４２】
図２は、図１に示したワークフローサーバ１０１，ワークフロークライアント１０２のハードウエア構成を示すブロック図である。
【００４３】
図２において、２０１はＣＰＵであり、システムバス２０４に接続される各デバイスを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。
【００４４】
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。
【００４５】
入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。また、印刷装置等では、タッチパネル、ボタン、スイッチ等が挙げられる。
【００４６】
出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶等が挙げられる。
【００４７】
外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。
【００４８】
通信Ｉ／Ｆコントローラ２０８は、ネットワーク１０３を介して外部機器との通信制御処理を実行する。
【００４９】
本発明を実現するためのプログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
【００５０】
図３は、図１に示したワークフローサーバ１０１において実現される機能構成の一例を示す図である。
【００５１】
図３に示すように、ワークフローサーバ１０１は、その機能構成として、入出力処理部７０１と、ワークフロー進行部７０２と、ワークフロー定義情報格納部７０５と、ワークフロー実行情報格納部７０８を含んでいる。
【００５２】
ワークフロー定義情報格納部７０５は、プロセス定義情報７０９と、アクティビティ入力項目定義情報７０４（図５）と、アクティビティ前提項目定義情報７０３（図６）とを含んでいる。
【００５３】
また、ワークフロー実行情報格納部７０８は、実行済アクティビティ情報７０６（図８）と、ジョブ入力済項目情報７０７（図９）とを含んでいる。
【００５４】
入出力処理部７０１は、ワークフローサーバ１０１の入力コントローラ２０５、又は、通信Ｉ／Ｆコントローラ２０８からの入力情報を受け付ける処理を行う。なお、入出力処理部７０１は、受け付けた入力情報を内容によりワークフロー進行部７０２への要求に変換する。
【００５５】
ワークフロー進行部７０２は、入出力処理部７０１からの要求に応じて、ワークフローの進行を行う。詳細には、ワークフロー進行部７０２は、ワークフロー定義情報格納部７０５に格納されている情報およびワークフロー実行情報格納部７０８に格納されている当該ジョブについての情報を参照し、実行中アクティビティ情報７１０を使用しながらジョブの作成および進行を行い、作成または進行したジョブについての情報をワークフロー実行情報格納部７０８に格納する。
【００５６】
また、ワークフロー進行部７０２は、ジョブの進行において入力情報の不備などがあると、入出力処理部７０１を通して担当者に対する通知を行う。この通知は、入力情報に対する直接結果として示される場合もあれば、メールなど非同期のメッセージングシステムを経由して行われる場合もある。
【００５７】
なお、入出力処理部７０１，ワークフロー進行部７０２は、ワークフローサーバ１０１のＣＰＵ２０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２上で実行することにより実現される機能に対応する。また、実行中アクティビティ情報７１０は、ワークフローサーバ１０１のＲＡＭ２０２内の記憶領域として実装される。さらに、ワークフロー定義情報格納部７０５およびワークフロー実行情報格納部７０８は、ワークフローサーバ１０１の外部メモリ２１１内に構築されるものとする。
【００５８】
以下、図３に示したワークフロー定義情報格納部７０５に格納される情報について説明する。
【００５９】
図４は、ワークフロープロセスの一例を示す図である。
【００６０】
図４に示す例では、アクティビティ１：申請者→アクティビティ２：課長承認→アクティビティ３：購買といった、ワークフロープロセスが定義されている。また、ワークフローの入力項目として、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードが定義されている。
【００６１】
なお、Ａ１：商品名、Ｂ１：定価は、２つ目のアクティビティである「課長承認」に遷移するまでに確定している必要がある（課長承認の前提項目）。また、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格、Ｃ１：負担部門コードは、３つ目のアクティビティである「購買」に遷移するまでに入力済みである必要がある（購買の前提項目）。
【００６２】
図３に示したプロセス定義情報７０９では、図４に示したようなワークフロープロセスを定義する情報が所定のデータ形式で格納されているものとする。なお、各アクティビティの入力項目の定義はアクティビティ入力項目定義情報７０４（図５）で定義される。また、各アクティビティの前提項目の定義はアクティビティ前提項目定義情報７０３（図６）で定義される。
【００６３】
図５は、図３に示したアクティビティ入力項目定義情報７０４の一例を示す図である。
【００６４】
アクティビティ入力項目定義情報７０４には、図５の１２０１〜１２０３に示すように、アクティビティごとに、入力する項目と、該項目のデータ型が定義されている。
【００６５】
図６は、図３に示したアクティビティ前提項目定義情報７０３の一例を示す図である。
【００６６】
アクティビティ前提項目定義情報７０３には、図６の１１０１〜１１０３に示すように、アクティビティごとに、アクティビティに遷移する際に入力されていることが前提（必須）となる項目（前提項目）が定義されている。
【００６７】
図７は、図６に示したアクティビティ前提項目定義情報７０３の入力画面（アクティビティ前提項目定義画面）の一例を示す図である。
【００６８】
図７（ａ）に示すようなアクティビティ前提項目定義画面から、アクティビティごとに、アクティビティに遷移する際に入力されていることが前提（必須）となる項目（前提項目）にチェックを入れることにより、アクティビティ前提項目定義情報７０３を生成可能となる。
【００６９】
本実施形態では、例えば、業務ルールが変わったことに伴うワークフロープロセスの変更が行われて、図１８に示したように、「課長承認」アクティビティと「購買」アクティビティの間に「部長承認」のアクティビティを追加する必要がでてしまった場合でも、図７（ｂ）に示すように、新たに加わった「部長承認」アクティビティの前提項目を定義するだけでよく、「課長承認」アクティビティについては前提項目の変更を行う必要がない。
【００７０】
従来では、１つめのアクティビティである「申請者」の完了処理において、Ａ１：商品名、Ａ２：商品コード、Ｂ１：定価、Ｂ２：見積価格について入力が完了しているかどうかの必須チェックを行い、２つめのアクティビティである「課長承認」の完了処理において、Ｃ１：負担部門コードについて入力が完了しているかどうかの必須チェックを行うことによって、３つめのアクティビティである「購買」の開始時点で必須項目が入力済みであることを担保するようにシステムが作成されていた。
【００７１】
しかしこのような従来の構成では、「課長承認」アクティビティと「購買」アクティビティの間に「部長承認」のアクティビティを追加する必要がでてしまった場合、図１９に示したように、新たに加わった「部長承認」アクティビティの前提項目を定義するだけでなく、「課長承認」アクティビティについても前提項目の変更を行う必要があり、工数が発生してしまっていた。また、その後、別のアクティビティが追加される場合や、「部長承認」アクティビティを削除する場合にも同様に、対象のアクティビティの定義情報だけでなく他のアクティビティの定義情報に対しても修正が発生するため、修正範囲が広がってしまい、不具合の可能性が増えてしまう。
【００７２】
このように、従来の構成では、アクティビティの追加や削除による他のアクティビティの必須チェックの修正が発生して煩雑であったり、修正範囲が広がることによって不具合の可能性が増えてしまっていた。
【００７３】
これに対して、本発明では、上述のように、アクティビティの追加や削除による他のアクティビティの必須チェックの修正の発生を抑えることができる。そのため、修正範囲が広がることもなく、不具合の可能性が増えてしまうといったことも抑制できる。
【００７４】
また、従来の構成では、「課長承認」アクティビティ時点では必須でないＡ２：商品コードやＢ２：見積金額が確定するまで、「課長承認」アクティビティへの遷移を行うことができず、業務の滞りが発生してしまう。
【００７５】
これに対して、本発明では、上述したように、各アクティビティの前提項目を予め設定しておく構成を有することにより、実際利用されるまで入力を遅延できるため、未確定な項目があってもワークフロー自体を進行させておくことが可能になり、全体の効率を挙げることが可能になる。
【００７６】
例えば、申請者は、項目Ａ２の商品コードや項目Ｂ２の見積価格が確定していない段階で、課長承認の前提項目となっている項目Ａ１の商品名と項目Ｂ１の定価を入力して、課長承認にワークフローを進めることができる。そして、項目Ａ２の商品コードと項目Ｂ２の見積価格が必要な「購買」の直前で入力待ち状態のままとなる。そして、申請者が項目Ａ２の商品コードと項目Ｂ２の見積価格を入力した段階で、「購買」にワークフローが進められる。
【００７７】
本発明では、このように、申請者は、項目Ａ２の商品コードと項目Ｂ２の見積価格が確定した段階で、これらの項目を入力して、購買アクティビティにワークフローを進めるといった運用が可能となり、全体の効率を挙げることができる。
【００７８】
なお、図示しないが、図５に示したアクティビティ入力項目定義情報７０４も、図７に示したアクティビティ前提項目定義画面と同様の画面により定義可能である。
【００７９】
以下、図３に示したワークフロー実行情報格納部７０８に格納される情報について説明する。
【００８０】
図８は、図３に示した実行済アクティビティ情報７０６の一例を示す図である。
【００８１】
実行済アクティビティ情報７０６には、図８の１３０１，１３０２に示すように、実行済となったアクティビティごとに、アクティビティ入力項目の入力の入力状態（未入力／入力済）が記憶される。
【００８２】
図９は、図３に示したジョブ入力済項目情報７０７の一例を示す図である。
【００８３】
ジョブ入力済項目情報７０７には、図９に示すように、ワークフロージョブで入力された各項目の情報が保存される。
【００８４】
以下、図１０のフローチャートを参照して、ワークフロー進行部７０２によるアクティビティの完了処理について説明する。
【００８５】
図１０は、図３に示したワークフロー進行部７０２によるアクティビティの完了処理を示したフローチャートである。即ち、本フローチャートの処理は、ワークフローサーバ１０１のＣＰＵ２０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２上で実行することにより実現される。
【００８６】
ワークフロークライアント１０２からの入力を受けて、入出力処理部７０１は、ワークフロー進行部７０２にアクティビティの完了を指示する。そして、入出力処理部７０１を通してアクティビティの完了が指示されると、ワークフロー進行部７０２は、当該アクティビティのための実行中アクティビティ情報７１０を一時的に作成し、ステップＳ８０１に処理を進める。
【００８７】
ステップＳ８０１では、ワークフロー進行部７０２は、入出力処理部７０１から受け取った入力情報を前記実行中アクティビティ情報７１０に格納し、当該アクティビティにおける各項目の入力／未入力の別を判定する。そして、ステップＳ８０２に処理を進める。
【００８８】
ステップＳ８０２では、ワークフロー進行部７０２は、実行中のワークフロージョブに関するジョブ入力済項目情報７０７（図９）をワークフロー実行情報格納部７０８から取得する。
【００８９】
次に、ステップＳ８０３では、ワークフロー進行部７０２は、上記ジョブ入力済項目情報７０７（図９）に、上記Ｓ８０１において実行中アクティビティ情報７１０に格納した入力情報を反映させる。
【００９０】
次に、ステップＳ８０４では、ワークフロー進行部７０２は、ワークフロー定義情報格納部７０５のプロセス定義情報７０９を参照して、現在のアクティビティの直後のアクティビティを特定し、該直後のアクティビティについての必須項目情報（アクティビティ前提項目定義情報７０３）を取得しておく。
【００９１】
そして、ステップＳ８０５において、ワークフロー進行部７０２は、上記Ｓ８０４で取得したアクティビティ前提項目定義情報７０３（図６）で必須となっている項目が、上記ジョブ入力済項目情報７０７（図９）において全て入力済みでとなっているかどうかの判定を行う。
【００９２】
そして、上記Ｓ８０５において、上記アクティビティ前提項目定義情報７０３（図６）で必須となっている項目がジョブ入力済項目情報７０７（図９）において全て入力済みになっていると判断した場合（Ｓ８０５でＹ）、ステップＳ８０６へ処理を進める。
【００９３】
ステップＳ８０６では、ワークフロー進行部７０２は、直後のアクティビティを実行中アクティビティとし、さらにそのアクティビティの状態を「処理待ち状態」とする。即ち、直後のアクティビティにワークフローを遷移させる。なお、アクティビティの状態については、図１３を用いて後述する。
【００９４】
次に、ステップＳ８０７では、ワークフロー進行部７０２は、入出力処理部７０１を通じて次のアクティビティを実行すべきユーザに対してアクティビティが割当てられた旨の通知を行う。なお、通知の方法は、電子メール・インスタントメッセージ・タスクリストへの追加など様々あるが、方法は問わない。
【００９５】
次に、ステップＳ８０８において、ワークフロー進行部７０２は、前記実行中アクティビティ情報７１０を実行済アクティビティ情報７０６としてワークフロー実行情報格納部７０８に格納する。格納できたら処理完了として、入出力処理部７０１に制御を戻す。そして、入出力処理部７０１を介して、「処理待ち状態」のアクティビティを実行すべきユーザが、処理を行うと、再度、本フローチャートの処理が実行される。
【００９６】
一方、上記Ｓ８０５において、直後のアクティビティ前提項目定義情報７０３（図６）で必須となっている項目の中で、ジョブ入力済項目情報７０７（図９）において未入力の項目があると判断した場合（Ｓ８０５でＮ）、ワークフロー進行部７０２は、ステップＳ８１０へ処理を進める。
【００９７】
ステップＳ８１０では、ワークフロー進行部７０２は、上記Ｓ８０４で取得したアクティビティ前提項目定義情報７０３で必須となっている項目の中で未入力の項目が実行中アクティビティ情報７１０の入力項目に含まれているかどうか判定する。
【００９８】
そして、上記Ｓ８１０において、上記Ｓ８０４で取得したアクティビティ前提項目定義情報７０３で必須となっている項目の中で未入力の項目が実行中アクティビティ情報７１０の入力項目に含まれていないと判断した場合には、ワークフロー進行部７０２は、ステップＳ８１１へ処理を進める。
【００９９】
ステップＳ８１１では、ワークフロー進行部７０２は、直後のアクティビティを実行中アクティビティとし、さらにそのアクティビティの状態を「遷移待ち」状態とする。なお、アクティビティの状態については図１３を用いて後述する。
【０１００】
次に、ステップＳ８１２において、ワークフロー進行部７０２は、ワークフロー実行情報格納部７０８に格納されている実行中のワークフロージョブに関する実行済アクティビティ情報７０６（図８）を全て読み出す。
【０１０１】
次に、ステップＳ８１３では、ワークフロー進行部７０２は、上記Ｓ８１２で読み出した実行済アクティビティ情報７０６の中から、上記Ｓ８０４で取得したアクティビティ前提項目定義情報７０３で必須となっている項目が含まれ、かつ未入力となっているものを抽出し、ステップＳ８１４へ処理を進める。
【０１０２】
ステップＳ８１４では、ワークフロー進行部７０２は、上記Ｓ８１３で抽出した実行済アクティビティ情報７０６の実行者に対して、入出力処理部７０１を通じて、前提項目の入力が未完了であり、そのために処理が待ち状態となっている旨の通知を行い、ステップＳ８０８へ処理を進める。なお、通知の方法は、電子メール・インスタントメッセージ・タスクリストへの追加など様々あるが、方法は問わない。例えば、図１１のようなメッセージが通知される。
【０１０３】
なお、図１１は、前提項目の入力が未完了であり処理が待ち状態となっている旨の通知の一例を示す図である。
【０１０４】
図１１に示すような、未入力通知画面１９００が、対応するユーザが使用するワークフロークライアント１０２のディスプレイに表示される。
【０１０５】
なお、１９０１は「入力画面を開く」ボタンであり、このボタンを指示することにより、後述する図１２に示す処理が開始され、未入力となっている項目に対する入力を行うための入力画面が表示される。
【０１０６】
１９０２は「ＵＲＬを保存」ボタンであり、このボタンを指示することにより、未入力となっている項目に対する入力を行うための入力画面のＵＲＬをワークフロークライアント１０２の外部メモリに保存することができる。
【０１０７】
以下、図１０のフローチャートの説明に戻る。
【０１０８】
次に、ステップＳ８０８において、ワークフロー進行部７０２は、前記実行中アクティビティ情報７１０を実行済アクティビティ情報７０６としてワークフロー実行情報格納部７０８に格納する。格納できたら処理完了として、入出力処理部７０１に制御を戻す。
【０１０９】
一方、上記Ｓ８１０において、上記Ｓ８０４で取得したアクティビティ前提項目定義情報７０３で必須となっている項目の中で未入力の項目が実行中アクティビティ情報７１０の入力項目に含まれていると判断した場合には、ワークフロー進行部７０２は、ステップＳ８２０へ処理を進める。
【０１１０】
ステップＳ８２０では、ワークフロー進行部７０２は、現在のアクティビティを実行中アクティビティとし、さらにそのアクティビティの状態を「処理待ち状態」とする。アクティビティの状態については図１３を用いて後述する。
【０１１１】
ステップＳ８２１では、ワークフロー進行部７０２は、入出力処理部７０１を通じて前記実行中アクティビティ情報７１０の実行者に対して必須項目が未入力である旨の警告通知を行う。警告通知の方法はエラーメッセージなどが一般的であるが、他の通知同様方法は問わない。
【０１１２】
ステップＳ８２２では、ワークフロー進行部７０２は、前記実行中アクティビティ情報７１０を破棄し、処理完了として、入出力処理部７０１に制御を戻す。そして、入出力処理部７０１を介して、「処理待ち状態」のアクティビティを実行すべきユーザが、直後のアクティビティの前提項目の中で未入力の項目の入力処理等を行うと、再度、本フローチャートの処理が実行される。
【０１１３】
次に、より具体的な例をあげながら図１０のフローを説明する。図４に示したようなプロセス定義のワークフローにおいて、ユーザＡが申請処理を行う場合を例にあげる。
【０１１４】
アクティビティ１：申請の入力項目は、アクティビティ入力項目定義情報７０４に図５の１２０１のように定義されているため、項目Ａ１、項目Ａ２、項目Ｂ１、項目Ｂ２が入力可能である。
【０１１５】
ユーザＡが項目Ａ１、項目Ｂ１を入力して申請を完了させた場合、ステップＳ８０１では、実行中アクティビティ情報７１０に項目Ａ１、項目Ｂ１のみが格納される。なお、ワークフロー開始直後のため、ジョブ入力済項目情報１４０１では、ジョブＩＤ１４０２に、開始したワークフロージョブのＩＤ「１００００」が格納されている以外は全て空欄である。
【０１１６】
そこに、前記実行中アクティビティ情報７１０を反映すると、項目Ａ１（１４０３）と項目Ｂ１（１４０５）にそれぞれユーザＡの入力値「業務用ＰＣ」、「199,800」が反映される（ステップＳ８０３）。
【０１１７】
ステップＳ８０４で取得する遷移先アクティビティの前提項目定義情報７０３は、図６の１１０２のように前提項目としてＡ１とＢ１が指定されているので、ステップＳ８０５では、前記ジョブ入力済項目情報にＡ１とＢ１が入力済みかどうかの判定を行う。この判定はＹＥＳとなるので、ステップＳ８０６へ進んで、アクティビティの遷移を完了し、該遷移先の担当者への通知を行う（ステップＳ８０７）。
【０１１８】
その後、前記実行中アクティビティ情報７１０の内容をアクティビティ１：申請の実行済みアクティビティ情報として保存格納する（図５の１２０１）。この時点で前記実行済みアクティビティは、図８の１３０１ように、項目Ａ１、項目Ｂ１のみが入力済みとなる。このように、ユーザＡが４つの入力項目（Ａ１、Ａ２、Ｂ１、Ｂ２）の全てではなく、少なくとも直後のアクティビティの前提項目（Ａ１、Ｂ１）のみを入力するだけで、次のアクティビティへの遷移を行うことが可能となる。
【０１１９】
次のアクティビティ２：課長承認の入力項目は、アクティビティ入力項目定義情報７０４に図５の１２０２のように定義されているため、当該アクティビティを実行すべきユーザ（課長Ｂとする）は項目Ｃ１が入力可能である。
【０１２０】
課長Ｂが、項目Ｃ１を入力せずに承認を完了させた場合、ステップＳ８０１では実行中アクティビティ情報７１０は全て空欄となる（ステップＳ８０１）。ジョブ入力済項目情報１４０１には、ユーザＡが入力した項目Ａ１、項目Ｂ１が入力された状態（ステップＳ８０２）であり、実行中アクティビティ情報７１０を反映させても状態は変わらない（ステップＳ８０３）。
【０１２１】
遷移先アクティビティであるアクティビティ３：購買のアクティビティ前提項目定義情報７０３は、図６の１１０３のように前提項目として項目Ａ１、項目Ａ２、項目Ｂ１、項目Ｂ２、項目Ｃ１が指定されているので、ステップＳ８０５では、前記ジョブ入力済項目情報にこれら全てが入力済みかどうかの判定を行う。この場合、判定はＮＯとなるので、ステップＳ８１０に進む。
【０１２２】
ステップＳ８１０では、当該アクティビティの入力項目１２０２に定義されている項目Ｃ１と、ステップＳ８０５で未入力と判断された項目Ａ２、項目Ｂ２、項目Ｃ１の比較を行う。項目Ｃ１が一致するので実行中アクティビティの入力項目が未入力である（ＹＥＳ）と判断し、ステップＳ８２０へ進み、実行者である課長Ｂに当該項目が未入力であることを警告する。このように、直後のアクティビティが前提としている項目が未入力の場合には、直ちに警告を行うことが可能である。
【０１２３】
なお、課長Ｂが項目Ｃ１を入力して承認を完了させた場合でも、遷移先の前提項目のうち項目Ａ２、項目Ｂ２が未入力となるため、ステップＳ８１０へ進む。ステップＳ８１０では、当該アクティビティの入力項目１２０２に定義されている項目Ｃ１と、ステップＳ８０５で未入力だった項目Ａ２、項目Ｂ２の比較を行う。この場合、一致する項目がないためＮＯと判断し、次のアクティビティを遷移待ち状態とする（ステップＳ８１１）。
【０１２４】
次に、このワークフロージョブの実行済アクティビティ情報を全て取得し（ステップＳ８１２）、ステップＳ８０５で未入力だった項目Ａ２、項目Ｂ２が未入力のままとなっているアクティビティを探す。この例では、アクティビティ１：申請がそれにあたるため、その実行者であるユーザＡに対して、未入力項目があることを通知し（ステップＳ８１４）、課長承認の処理が完了する。
【０１２５】
このように、あるアクティビティが前提としている項目が入力されるまで、そのアクティビティへの遷移を保留することが可能である。
【０１２６】
以下、図１２のフローチャートを参照して、図１０のステップＳ８１４の遷移待ち通知に応じた必須項目の遅延入力処理について説明する。
【０１２７】
図１２は、図１０のステップＳ８１４の遷移待ち通知に応じた必須項目の遅延入力処理を示したフローチャートである。即ち、本フローチャートの処理は、ワークフローサーバ１０１のＣＰＵ２０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２上で実行することにより実現される。
【０１２８】
図１０のステップＳ８１４の通知を受けたユーザが、「入力画面を開く」ボタン１９０１を指示すると（又は、Ｓ８１４の通知から保存されたＵＲＬへのアクセスすると）、ワークフロークライアント１０２は、未入力通知に対する入力要求をワークフローサーバ１０１に送信する。この未入力通知に対する入力要求を入出力処理部７０１を介して受信すると、ワークフロー進行部７０２は、図１２に示すフローチャートの処理を開始する。
【０１２９】
また、ワークフロークライアント１０２から図１０のステップＳ８１４の通知から保存されたＵＲＬへのアクセスを受信した場合も、ワークフロー進行部７０２は、図１２に示すフローチャートの処理を開始する。
【０１３０】
まず、ステップＳ９０１では、ワークフロー進行部７０２は、ワークフロー実行情報格納部７０８から該当する実行済アクティビティ情報７０６を取得し、入出力処理部７０１を介して該当するアクティビティの入力画面（フォーム）をクライアントに送信し、ステップＳ９０２へ処理を進める。
【０１３１】
これにより、ワークフロークライアント１０２では、該当するアクティビティのフォームが表示され、ユーザ入力可能となる（Ｓ９０２）。そして、ワークフロークライアント１０２から入力処理がなされ、入出力処理部７０１を介して、アクティビティの完了が指示されると、ワークフロー進行部７０２は、ステップＳ９０３に処理を進める。
【０１３２】
ステップＳ９０３では、ワークフロー進行部７０２は、入出力処理部７０１から受け取った入力情報を前記実行中アクティビティ情報７１０に格納し、当該アクティビティにおける各項目の入力／未入力の別を判定する。そして、ステップＳ９０４に処理を進める。
【０１３３】
ステップＳ９０４では、ワークフロー進行部７０２は、ワークフロー実行情報格納部７０８に格納してある実行中のワークフロージョブに関するジョブ入力済項目情報７０７（図９）に、上記Ｓ９０３において実行中アクティビティ情報７１０に格納した入力情報を反映させる。
【０１３４】
次に、ステップＳ９０５では、ワークフロー進行部７０２は、ワークフロー定義情報格納部７０５から遷移待ち状態のアクティビティについての必須項目情報（アクティビティ前提項目定義情報７０３）を取得しておく。
【０１３５】
そして、ステップＳ９０６において、ワークフロー進行部７０２は、上記Ｓ９０５で取得したアクティビティ前提項目定義情報７０３（図６）で必須となっている項目が、上記ジョブ入力済項目情報７０７（図９）において全て入力済みでとなっているかどうかの判定を行う。
【０１３６】
そして、上記Ｓ９０６において、上記アクティビティ前提項目定義情報７０３（図６）で必須となっている項目がジョブ入力済項目情報７０７（図９）において全て入力済みになっていると判断した場合（Ｓ９０６でＹ）、ステップＳ９０７へ処理を進める。
【０１３７】
ステップＳ９０７では、ワークフロー進行部７０２は、遷移待ち状態のアクティビティを実行中アクティビティとし、さらにそのアクティビティの状態を「処理待ち状態」とする。即ち、直後のアクティビティにワークフローを遷移させる。なお、アクティビティの状態については、図１３を用いて後述する。
【０１３８】
次に、ステップＳ９０８では、ワークフロー進行部７０２は、入出力処理部７０１を通じて次にアクティビティを実行すべきユーザに対してアクティビティが割当てられた旨の通知を行う。なお、通知の方法は、電子メール・インスタントメッセージ・タスクリストへの追加など様々あるが、方法は問わない。
【０１３９】
次に、ステップＳ９０９において、ワークフロー進行部７０２は、前記実行中アクティビティ情報７１０を実行済アクティビティ情報７０６としてワークフロー実行情報格納部７０８に格納する。格納できたら処理完了として、入出力処理部７０１に制御を戻す。そして、入出力処理部７０１を介して、「処理待ち状態」のアクティビティを実行すべきユーザが、処理を行うと、図１０に示したフローチャートの処理が実行される。
【０１４０】
一方、上記Ｓ９０６において、遷移待ち状態のアクティビティ前提項目定義情報７０３（図６）で必須となっている項目の中で、ジョブ入力済項目情報７０７（図９）において未入力の項目があると判断した場合（Ｓ９０６でＮ）、ワークフロー進行部７０２は、ステップＳ９１０へ処理を進める。
【０１４１】
なお、ステップＳ９１０〜Ｓ９２２では、未入力項目があった場合の処理を行うが、これは図１０のステップＳ８１０〜Ｓ８２２までと同様であるので説明は省略する。
【０１４２】
図１３は、アクティビティの状態について表したものである。
【０１４３】
図１３において、遷移元のアクティビティの完了１００１によって、次のアクティビティの実体が作成され、「遷移待ち状態」１０１０となる。
【０１４４】
遷移待ち状態１０１０では、そのアクティビティが実行中アクティビティではあるものの遷移が完全には完了していない状態のため、担当者への通知やタスクリストへの表示はまだ行われていない。
【０１４５】
遷移待ち状態１０１０の際には、遷移完了処理１００２によって、「処理待ち状態」１０１１となる。なお、処理待ち状態１０１１は、担当者による項目の入力や承認を待っている状態である。
【０１４６】
処理待ち状態１０１１の時に、入力処理１００３を行うと、図１０のような完了処理が行われ、そのアクティビティ自体は「処理完了状態」１０１２となって、実行中アクティビティは次のアクティビティとなる。
【０１４７】
以上のような構成により、次のアクティビティの必須項目が変更になった場合にも動的で柔軟な必須チェックが可能であるとともに、本当にその項目の入力済が必須となる時点まで、入力の遅延を許可することにより、それ以外の項目についての承認処理を先に進めることが可能となる。その結果、業務全体のスループットを向上することができる。
【０１４８】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０１４９】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１５０】
以上のように、アクティビティの追加や削除等が発生した場合でも、他のアクティビティの必須チェックに修正がおよぶことを回避することができる。また、項目の入力済が必須となる時点までその項目の入力の遅延を許可して、業務全体のスループットを向上することができる。
【０１５１】
以下、図１４に示すメモリマップを参照して、本発明に係るワークフローサーバとしてコンピュータを機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体（記憶媒体）の構成について説明する。
【０１５２】
図１４は、本発明に係るワークフローサーバとしてコンピュータを機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体（記憶媒体）のメモリマップを説明する図である。
【０１５３】
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１５４】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１５５】
本実施形態における図１０，図１２に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１５６】
以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１５７】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１５８】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１５９】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１６０】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１６１】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１６２】
さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１６３】
なお、上述した各実施形態の変形例を組み合わせた構成も全て本発明に含まれるものである。
【図面の簡単な説明】
【０１６４】
【図１】本発明のワークフローサーバを適用可能なワークフローシステムの一例を示す図である。
【図２】図１に示したワークフローサーバ１０１，ワークフロークライアント１０２のハードウエア構成を示すブロック図である。
【図３】図１に示したワークフローサーバ１０１において実現される機能構成の一例を示す図である。
【図４】ワークフロープロセスの一例を示す図である。
【図５】図３に示したアクティビティ入力項目定義情報７０４の一例を示す図である。
【図６】図３に示したアクティビティ前提項目定義情報７０３の一例を示す図である。
【図７】図６に示したアクティビティ前提項目定義情報７０３の入力画面（アクティビティ前提項目定義画面）の一例を示す図である。
【図８】図３に示した実行済アクティビティ情報７０６の一例を示す図である。
【図９】図３に示したジョブ入力済項目情報７０７の一例を示す図である。
【図１０】図３に示したワークフロー進行部７０２によるアクティビティの完了処理を示したフローチャートである。
【図１１】図１１は、前提項目の入力が未完了であり処理が待ち状態となっている旨の通知の一例を示す図である。
【図１２】図１０のステップＳ８１４の遷移待ち通知に応じた必須項目の遅延入力処理を示したフローチャートである。
【図１３】アクティビティの状態について表したものである。
【図１４】本発明に係るワークフローサーバとしてコンピュータを機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体（記憶媒体）のメモリマップを説明する図である。
【図１５】業務のワークフローの一例を示す図である。
【図１６】従来のアクティビティ画面に必須項目を設定するＧＵＩの一例を示す図である。
【図１７】アクティビティ画面に必須項目を設定した際の定義情報の一例を示す図である。
【図１８】図１５に示したプロセスに変更があった場合の一例を示す図である。
【図１９】図１８の変更を反映する際のアクティビティ画面に必須項目を設定するＧＵＩのイメージを示す図である。
【図２０】業務のワークフローの一例を示す図である。
【符号の説明】
【０１６５】
１０１    ワークフローサーバ
１０２    ワークフロークライアント
１０３    ネットワーク
２０１    ＣＰＵ
２０２    ＲＡＭ
２１１    外部メモリ
２１２    プログラム
７０１    入出力処理部
７０２    ワークフロー進行部
７０３    アクティビティ前提項目定義情報
７０４    アクティビティ入力項目定義情報
７０５    ワークフロー定義情報格納部
７０６    実行済アクティビティ情報
７０７    ジョブ入力済項目情報
７０８    ワークフロー実行情報格納部
７０９    プロセス定義情報
７１０    実行中アクティビティ情報
【図１】
2010140231.tif 000003
【図２】
2010140231.tif 000004
【図３】
2010140231.tif 000005
【図４】
2010140231.tif 000006
【図５】
2010140231.tif 000007
【図６】
2010140231.tif 000008
【図７】
2010140231.tif 000009
【図８】
2010140231.tif 000010
【図９】
2010140231.tif 000011
【図１０】
2010140231.tif 000012
【図１１】
2010140231.tif 000013
【図１２】
2010140231.tif 000014
【図１３】
2010140231.tif 000015
【図１４】
2010140231.tif 000016
【図１５】
2010140231.tif 000017
【図１６】
2010140231.tif 000018
【図１７】
2010140231.tif 000019
【図１８】
2010140231.tif 000020
【図１９】
2010140231.tif 000021
【図２０】
2010140231.tif 000022