JP2009265936A - 外部システムからのフロー制御可能なワークフローシステム - Google Patents

Abstract

【課題】ワークフローシステムにおいて、外部業務システムと連携する場合に、案件データの安全性を確保し、また、外部業務システムには新たな機能を追加することなく、ワークフローを構築し、その設定にもとづいてフロー制御をすること。
【解決手段】外部システムと連携可能なワークフローシステムであって、外部システムからのデータであってフロー制御に関する指示が含まれていないデータに応じたフロー制御を示すフロー制御情報を定義する定義手段と、定義したフロー制御情報に基づいてワークフローを制御する制御手段とを備えることを特徴とするワークフローシステムを提供する。一例として、ワークフローの工程に関する工程情報をキーとするフロー制御テーブルを利用してフローの制御を行う。
【選択図】図１

Description

本発明は、ワークフローシステムに関する。より詳細には、本発明は、外部システムと連携して処理を行うことが可能なワークフローシステムに関する。

従来より、外部の業務システムと連携して、業務処理を行わせるワークフローシステムが実用化されている。ワークフローシステムは、予め定義された経路やルールに従って様々な業務プロセスを処理するシステムである。一例としては、社内決裁などを電子的に処理する際に用いられ、サーバに格納されるデータを、クライアント端末上で参照したり、更新したりすることで、各権限者による認証処理が各工程で行われる性質を備えた経費管理システムや、人事管理システムなどである。このようなワークフローシステムでは、ワークフローシステム上のデータを特定の入出力インターフェースを経由して送受信することで連携を実現している。

単純なデータの入出力であれば連携も容易であるが、複雑なデータのやり取りやフローの制御が必要になる場合には、お互いのシステムの入出力インターフェースを考慮してシステムを改変したり、連携するための中間プログラムの開発が必要となる。

特許文献１では、外部への見積もり依頼および見積書の受け入れを行うＦＡＸシステムと連携するワークフローシステムについて説明している。この特許ではＦＡＸシステムを入出力インターフェースとして定義しており、特定のユーザーインターフェースとステータスを持つことでワークフローシステム上のデータの特定や制御を行っている。

特開２００１−３１９０１９号公報

しかしながら、外部の業務システムには人が介在せずに自動化されているものが多くあり、外部システムからのフロー制御を自動的におこなわせることは容易ではない。また、外部の業務システムは既に稼働しているシステムであることが多く、改変することが難しい場合がある。さらには、中間プログラムを新たに開発する場合には、特定の業務システムに依存してしまうため、他の業務システムでの再利用は難しく現実的な対応方法ではない。

本発明は、かかる課題を解決するために、外部システムと連携可能なワークフローシステムにおいて、外部システムからのデータであってフロー制御に関する指示が含まれていないデータに応じたフロー制御を示すフロー制御情報を定義する定義手段と、定義したフロー制御情報に基づいてワークフローを制御する制御手段とを備えることを特徴とするワークフローシステムを提供する。フロー制御に関する情報が含まれていないデータに対してもワークフローの制御を実施することができるため、既に稼動している外部システムを修正する必要がなくなる。

また、定義手段は、前記フロー制御情報として、ワークフローの工程に関する工程情報をキーとするフロー制御情報を定義してもよい。また、定義手段は、工程の遷移を指示する工程遷移指示情報をさらに含む前記フロー制御情報を定義してもよい。また、定義手段は、工程毎に、一または複数の所定の条件と、工程遷移指示情報と、を少なくとも含む一または複数のレコードからなるフロー制御情報を定義してもよい。このように、所定の工程において、所定の条件が合致した場合における工程遷移の指示をワークフローサーバ側にて定義しておくことで、外部システムからのデータに応じてワークフローサーバ側での処理が支障なく継続される。

また、外部システムからのデータを取得する取得手段をさらに備えてもよく、制御手段は、取得したデータに工程の遷移を指示するデータが含まれているかを判定する手段と、判定した結果が工程の遷移を指示するデータが含まれていない場合に、定義されたフロー制御情報を取得する手段と、を含み、取得したデータと、取得したフロー制御情報と、に基づいて工程の遷移のフロー制御を行ってもよい。

本発明によれば、ワークフロー構築者によって外部システムとの入出力データおよびフロー制御ルールを定義することで外部システムと連携するワークフローシステムを構築でき、外部システムへの機能追加や変更を行わずに容易にワークフロー制御ができるように
なる。

以下、図面を参照して、本発明の実施形態を詳細に説明する。なお、本発明はこれら実施の形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施しうる。なお、以下の図面においては、同種の要素、データ等に関しては同一の符号を付している。

図１は、本発明によるワークフロー構築・運用システムの一実施例の構成を示すシステム構成図である。図１において、ワークフローシステムは少なくとも１つのワークフローサーバ１０４と複数のワークフロークライアント１０５〜１０６がイントラネット１０７を介して接続されている。これらが、従来技術で説明した狭義の意味でのワークフローシステムである。そして、ワークフローサーバ１０４と外部業務システムサーバ１０１〜１０２とがネットワーク１０３を介して接続されている。本明細書では、この外部業務システムサーバも含めた構成についても広義の意味でワークフローシステムと称する場合がある。また、本明細書においては、外部業務システムサーバを外部業務システムと称する場合がある。

ネットワーク１０３の構成は公知であるから詳細な説明は省略するが、ネットワーク１０３としてローカルエリアネットワーク（ＬＡＮ）・ワイドエリアネットワーク（ＷＡＮ）・イントラネット・インターネットなどを利用することができる。なお、イントラネット１０７は企業内ネットワークを想定しているが、ネットワーク１０３と同様にＬＡＮ・ＷＡＮ・イントラネット・インターネットを利用することができる。

ユーザはワークフロークライアント１０５〜１０６から、ワークフローサーバ１０４に対して、ワークフロー操作の要求等を行う。ワークフローサーバ１０４はワークフロークライアント１０５〜１０６からの要求に応じた処理を行い、必要があればワークフロークライアント１０５〜１０６に対して結果等を送信する。

外部業務システム１０１〜１０２はワークフローサーバ１０４に対して処理要求を送り、これに対する応答を受け取って、それぞれの業務システムで処理を行い、業務システムの処理結果をワークフローサーバ１０４に対して登録する処理を要求する。本実施形態では、外部業務システムは、一種のワークフロークライアントとして動作することができる。

管理用クライアント１０８は、後述する定義データを生成する処理を行う装置である。管理用クライアント１０８は、必須の構成ではなく、定義データを生成する機能をクライアント又はサーバに備えてもよい。また、図外のコンピュータ装置などで生成された定義データを単に記憶する記憶媒体を、管理用クライアントに代えて備えてもよい。

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

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。また、印刷装置等では、この入力部２０９として、タッチパネル、ボタン、スイッチ等が挙げられる。出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶等が挙げられる。

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

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

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

＜各処理部の説明＞
図３は、図１に示したワークフローサーバ１０４において実現される機能構成を示すブロック図である。図３において、ワークフローサーバ１０４は、その機能構成として、ワークフロー処理部３０１と、業務定義設定処理部３０２と、案件処理部３０３と、データ項目定義処理部３０４と、経路定義処理部３０５と、案件データ処理部３０６と、配送処理部３０７と、を備え、データとして、定義データ３１１と案件データ３２１とを備える。また、定義データ３１１は、データ項目定義３１２と経路定義３１３とを含む。さらに経路定義３１３は、プロセス定義テーブル３１４と、アクセス制御定義テーブル３１５（アクセス制御定義テーブル）と、配送判断定義テーブル３１６（配送判断定義テーブル、フロー制御情報）とを含む。以下、各機能等について説明する。なお、各処理部は、例えば図２で示すようなコンピュータに含まれるメモリ等に含まれるプログラムを、ＣＰＵ、メモリ等を用いて処理を実行することで実現される。また、一例として、各処理部を、プログラム言語における関数やメソッドとして本実施形態を実施することができる。

ワークフロー処理部３０１は、管理用クライアント１０８からの業務定義設定の処理要求を受け、業務定義設定処理部３０２に処理要求を送り、業務定義設定処理部３０２の処理結果を呼び出し元の管理用クライアント１０８に返却する。

また、ワークフロー処理部３０１は、ワークフロークライアント１０５〜１０６、または外部業務システムサーバ１０１〜１０２からの案件参照要求または案件更新要求などの案件処理要求を受信する。その後、ワークフロー処理部３０１は、案件処理部３０３に処理要求を送り、案件処理部３０３から受ける処理結果を、呼び出し元のワークフロークライアント１０５〜１０６、または外部業務システムサーバ１０１〜１０２へ返却する。このように、ワークフロー処理部３０１は、処理要求を受信して、その処理要求の内容に応じて、システムの構築・設定に関する定義設定処理を実行するか、あるいは、実際の案件データを取り扱う案件処理を実行するかを判定する。

業務定義設定処理部３０２は、ワークフロー処理部３０１から処理要求を受け取る。そして、処理要求の内容によって、データ項目定義処理部３０４か経路定義処理部３０５を呼び出す。データ項目定義処理部３０４は、データ項目定義３１２の設定、またはデータ項目定義３１２のデータを取得してワークフロー処理部３０１へ返却する。

経路定義処理部３０５は、経路定義３１３の設定、または経路定義３１３のデータを取得して、ワークフロー処理部３０１へ返却する。

なお、経路定義は、工程をキーとする、データのアクセス制御等を行うための工程情報である。定義データ３１１に含まれるデータ項目定義３１２は、データの項目名や種類（文字や数値など）などの、案件データ３２１のテンプレートとなる定義情報を有する。定義データ３１１に含まれる経路定義３１３は、ワークフローの工程定義と工程間のフロー制御ルールを示すプロセス定義３１４と、ワークフロー運用時に特定の工程にて案件データのどの項目に対して参照・更新の操作を行えるかを示すアクセス制御定義３１５と、案件データの内容によって配送方法を決定するルールを示す配送判断定義３１６とを有する。配送とは、承認や否認、差し戻し、保留などのワークフロー工程の操作（遷移）に対する概念である。例えば、承認は次の工程に進みことを意味し、否認は案件を却下して完了することを意味し、差戻しは直前、または任意の工程に戻すことを意味し、保留は工程を移動しないことを意味する。

アクセス制御定義によって、例えば外部業務システムに対する案件データへのアクセス制御をワークフローサーバ側で制御することが可能となる。例えば、外部業務システムから所定のデータを要求された際には、アクセス制御定義を参照して、所定条件に一致する場合には、そのアクセス制御定義に定義される所定の動作を許可したり実行したりすることができる。このように、運用側（ワークフローサーバ側）の設定によって各種の制御を行うことが可能となる。

また、配送判断定義３１６によって、インタフェース入出力定義を行いワークフローサーバ側にて入出力の制御を実現できる。

案件処理部３０３は、ワークフロー処理部３０１から案件処理要求を受ける。要求が案件参照要求であれば、案件データ処理部３０６に、案件参照要求を送り、案件データ処理部３０６によって返却された案件データをワークフロー処理部３０１へ返却する。一方、要求が案件更新要求であれば、案件データ処理部３０６に、案件更新要求を送り、案件データ処理部３０６によって案件データの更新、およびデータベースへの登録が行われる。続けて案件処理部３０３は配送処理部３０７を呼び出し、配送処理部３０７によって配送処理が行われる。

案件データ処理部３０６は、案件処理部３０３から案件参照要求を受け付けた場合は、アクセス制御定義３１５に従って案件データ３２１から参照可能なデータ項目を取り出して、案件処理部３０３に返却する。なお、案件データ３２１とは、ワークフロー運用時に、データ項目定義３１２を元に、ワークフロークライアントにより登録される実データである。また、案件データ処理部３０６は、案件処理部３０３から案件更新要求を受け付けた場合は、アクセス制御定義３１５に従って案件データ３２１の更新可能なデータ項目を変更して、変更したデータ項目を案件データ３２１に更新登録する。

なお、案件データ処理部３０６の詳細な処理の流れに関しては、後述する図１５〜１９に関連して説明する。

配送処理部３０７は、案件処理部３０３から配送要求を受け付けて、配送判断定義３１６に従って配送内容を特定し、特定された配送処理を行う。

図４は、本発明の実施形態のワークフローを構築する場合のデータ関連の一例を示す図である。図４は、どのデータがどのデータを参照して構築されるかを示す。例えば、経路定義３１３は、組織情報４０１、データ項目定義３１２、および帳票フォーム４０２を参照して構築される。なお、組織情報とは、ワークフローユーザと、ユーザが所属する部門（部署）やロール（役職など）を定義したデータであり、ある工程を実行する担当者・担当部門等を示す情報である。また、帳票フォーム４０２とは、ワークフローを運用する際にワークフローユーザによって使用される帳票のデザインを定義したデータであり、ワークフロー運用時の案件データ３２１の入力・参照画面のことである。

本発明における定義手段は、業務定義設定処理部３０２、データ項目定義処理部３０４、および経路定義処理部３０５の少なくとも１つとすることができる。また、本発明の制御手段は、案件処理部３０３、案件データ処理部３０６、および配送処理部３０７の少なくとも１つとすることができる。取得手段は、ワークフロー処理部３０１、業務定義設定処理部３０２、および案件処理部３０３の少なくとも１つとすることができる。

図５は、本発明の実施形態のワークフローを構築する場合のデータ作成手順の一例を示す図である。まず、図５の組織情報作成ステップＳ５０１で、図４の組織情報４０１を作成する。続いて、図５のデータ項目定義作成ステップＳ５０２で、図４のデータ項目定義３１２を作成する。続いて、図５のフォームの作成ステップＳ５０３で、図４の帳票フォーム４０２を作成する。続いて、図５の経路定義の作成ステップＳ５０４で、図４の経路定義３１３を作成する。経路定義３１３に含まれるプロセス定義３１４には、工程を処理する担当者を設定するため、経路定義３１３は、組織情報４０１を参照する。またプロセス定義３１４には工程で使用する入力フォームを設定するため、経路定義３１３は、帳票フォーム４０２も参照する。

図６は、図５に示した経路定義の作成ステップＳ５０４（プロセス定義３１４、アクセス制御定義３１５、配送判断定義３１６）の一例を示す画面イメージである。６０１では、プロセス定義の一例として「備品購買稟議申請」のワークフローの工程が定義されている。図６の例では、この「備品購買稟議申請」のワークフローの工程は、「申請」、「金額相見積」、「経理承認」の各工程（各プロセス）から構成されている。６０２〜６０４では、「備品購買稟議申請」の「経理承認」の工程についての設定が行われている例を示す。６０２では、工程を処理する担当者の設定が行われている。つまり、組織情報を参照して設定がなされている。６０３では、工程の処理フォームと担当者への通知設定が設定されている。つまり、帳票フォームを参照して設定がなされている。６０４では、工程のアクセス制御定義３１５と配送判断定義３１６の設定が行われている。このように定義された情報を用いてワークフローシステムの運用が行われる。

図７は、本発明の実施形態のワークフローシステムにおいてユーザ（ワークフロークライアント１０５〜１０６）のワークフロー利用手順の一例を示すフロー図である。

図８は、本発明の実施形態のワークフローシステムにおいて外部業務システムサーバ１０１〜１０２のワークフロー利用手順の一例を示すフロー図である。

以下、図７および図８を用い、ユーザ（ワークフロークライアント１０５〜１０６）と外部業務システム１０１〜１０２の利用手順の違いを説明する。

ユーザは、システムにログインし（ステップＳ７０１）、帳票一覧画面にアクセスする（ステップＳ７０２）。次に、図５のＳ５０３で作成された帳票フォーム４０２を起動する（ステップＳ７０３）。次に、起動した帳票フォーム４０２からデータを入力し（ステップＳ７０４）、帳票フォーム４０２の配送ボタンをクリックする（ステップＳ７０５）。その後、配送処理結果を画面上で確認し（ステップＳ７０６）、システムからログアウトする（ステップＳ７０７）。

一方、外務業務システム１０１〜１０２は、システムにログインし（ステップＳ８０１）、ワークフローサーバ１０４から案件データを取得し（ステップＳ８０２）、外部業務システムの処理を行い（ステップＳ８０３）、処理結果をワークフローサーバに登録し（ステップＳ８０４）、システムからログアウトする（ステップＳ８０５）。

このように、ユーザであるワークフロークライアントでは、データの参照、編集、登録に際して、ワークフローシステム専用の帳票フォーム４０２を用いている。つまり、帳票フォーム４０２に定義された処理しか行うことができないため、入出力の制御が帳票フォームを介して行われていることになる。これに対して外部業務システムは、データの参照、編集、登録に、単にデータ入出力インタフェースを介してデータ入力等が行われており、ワークフローシステム専用のツールを用いていない点に留意されたい。つまり、通常のワークフロークライアントにおいては、帳票フォームによって、入出力されるデータの制御が行われることになるが、外部業務システムにおいては、帳票フォームを用いることができない。このため、ワークフローサーバから外部業務システムに対してデータを出力する場合には、出力する際のデータが、いわばフィルタリングがされない状態となって出力されてしまうため、必要以上のデータを開示してしまう危険性がある。そこで、ワークフローサーバ側にて、データアクセスの制御を行う必要が生じることになる。

図９は、図３で示したデータ項目定義３１２のデータ構造を示す図である。データ項目定義３１２は、一例として、項目定義テーブル９００と明細項目定義テーブル９１０に分けられる。なお、明細項目とは、明細形式（表形式）で扱う項目のことをいい、複数行の設定を扱う項目である。

項目定義テーブル９００は、
・項目定義を一意に識別するための情報として、項目ＩＤ ９０１を有する。
・項目定義が明細項目定義を持つかを判断するための情報として、明細グループフラグ９０２を持つ。明細項目定義を持つ場合には、「Ｙ」が設定される。

明細項目定義テーブル９１０は、
・明細項目定義がどの項目定義テーブル９００のデータに紐付いているかを識別するための情報として、項目ＩＤ ９１１を有する。
・項目ＩＤ ９１１と組み合わせて、明細項目定義を一意に識別するための情報として、明細項目ＩＤ ９１２を有する。

なお、図９で示す例のほかに、各項目のデータの種類（文字、数値など）や桁数、説明、設定可能な値の範囲などを設けることが可能であり、項目に入力値の制限を設けることもできる。

図１０は、図３で示した経路定義３１３（プロセス定義３１４、アクセス制御定義３１５、配送判断定義３１６）のデータ構造図の一例を示す図である。

プロセス定義テーブル３１４は、
・プロセス定義テーブル３１４の工程を一意に識別するための情報（工程情報）として、工程ＩＤ １００１を有する。
・工程を処理できる担当者を識別するための情報として、担当者ＩＤ １００２を有する。なお、ワークフローのユーザを直接指定する方法と、部門や役割を指定して、間接的に、ユーザを指定する方法とがある。
・工程で使用する帳票フォーム４０２を識別するための情報としてフォームＩＤ １００３を有する。なお、この帳票フォームは、ワークフロークライアントとワークフローサーバとの間で使用するものであり、外部業務システムとワークフローサーバとの間では使用されない。
・工程を処理する依頼を行うための手段を設定した 通知手段 １００４を有する。通知手段は、工程の担当者に対して、処理依頼（承認依頼）、配送結果（処理結果）を通知するための手段が設定されている。

アクセス制御定義テーブル３１５は、本実施形態において外部業務システムとの間のアクセス制御を定義するためのテーブルである。アクセス制御テーブル３１５は、
・どの工程に使用されるアクセス制御定義なのかを識別するための情報として、工程ＩＤ １０１１を有する。
・アクセス制御定義を使用できる条件を設定した、条件１０１２を有する。
・工程ＩＤ １０１１、条件１０１２が一致した場合に、操作可能になる対象となる項目を設定した、項目ＩＤ １０１３を有する。
・工程ＩＤ １０１１、条件１０１２が一致した場合に、操作可能になる対象となる項目が明細項目の場合に、操作可能になる対象となる明細項目を設定した、明細項目ＩＤ １０１４を有する。
・工程ＩＤ １０１１、条件１０１２が一致した場合に、実行可能な操作内容を設定した、操作ＩＤ １０１５を有する。

図１０に示すアクセス定義テーブルでは、例えば工程ＩＤが「金額相見積」の場合に、更新指示に含まれる見積履歴の見積金額が０より大きければ、項目ＩＤ「見積履歴」に関連する明細項目ＩＤ「見積金額」および「見積実施者」の項目に関して、操作ＩＤで示される「行追加」の動作を許可する場合の設定である。

配送判断定義テーブル３１６は、
・どの工程に使用される配送判断定義なのかを識別するための情報として、工程ＩＤ １０２１を有する。
・配送判断定義を使用できる条件を設定した、条件１０２２を有する。
・工程ＩＤ １０２１、条件１０２２が一致した場合に、配送可能になる配送の種類を設定した、配送内容ＩＤ １０２３（工程遷移指示情報）を有する。

図１０に示す配送判断定義テーブルでは、例えば工程ＩＤが「金額相見積」の場合において、案件の最低見積金額が案件の希望金額以下で、かつ２以上の見積履歴がある場合には、かかる条件においては、承認という配送動作がなされることになる。

なお、工程ＩＤ１０２１には外部システムからの要求である制御であれば何でも良い。例えば、在庫管理の場合は在庫マスタの更新などが該当する。

図１１は、図３で示した案件データ３２１のデータ構造図の具体例を示す図である。案件データ３２１は、項目データを格納するためのテーブルとして、案件項目データテーブル１１００と、明細項目データを格納するためのテーブルとして、案件明細項目データテーブル１１１０とに分かれる。

案件項目データテーブル１１００は、
・案件を特定するための情報として、案件ＩＤ １１０１を有する。
・案件ＩＤ １１０１と組み合わせて、項目を特定するための情報として、項目ＩＤ １１０２を有する。
・項目の値を格納するための、値１１０３を有する。

案件明細項目データテーブル１１１０は、
・案件を特定するための情報として、案件ＩＤ １１１１を有する。
・項目を特定するための情報として、項目ＩＤ １１１２を有する。
・項目のデータ行を特定するための情報として、行番号１１１３を有する。
・明細項目を特定するための情報として、明細項目ＩＤ １１１４を有する。
・明細項目の値を格納するための、値１１１５を有する。

なお、案件項目データテーブルにおいては、特殊な案件項目ＩＤとして「次担当者」を指定できる。次担当者とは、配送を行ったその次のフロー担当者のことである。次担当者が指定されている場合は、値の項目に設定されているユーザが次担当者として指定される。

図１２は、図３で案件処理部３０３から案件データ処理部３０６に送られる案件参照要求１２００の構造を示す図である。案件参照要求１２００は、
・処理対象の案件を特定するための情報である案件ＩＤ １２０１を有する。
・処理対象の工程を特定するための情報である工程ＩＤ １２０２を有する。
・処理を実行する実行者を特定するための情報である実行者ＩＤ １２０３を有する。実行者とは、例えばワークフローサーバに対して処理を要求する、ワークフロークライアントや外部業務システムサーバのことである。

図１３は、図３で案件処理部３０３から案件データ処理部３０６に送られる案件更新要求１３００の構造を示す図である。案件更新要求１３００は、
・処理対象の案件を特定するための情報である案件ＩＤ １３０１を有する。
・処理対象の工程を特定するための情報である工程ＩＤ １３０２を有する。
・処理を実行する実行者を特定するための情報である実行者ＩＤ １３０３を有する。
・配送を指示するための情報である配送指示１３０４を有する。なお、配送指示には、承認や差し戻しなどワークフローの工程を動かすための指示が設定される。配送指示を指定しないことも可能である。
・案件データ更新指示の内容である案件更新指示１３０５を有する。

図１４は、図１３で示した案件更新指示１３０５の構造の具体的な一例を示す図である。案件更新指示１３０５は、案件項目データ１１００に対する更新指示１４００と、案件明細項目データ１１１０に対する更新指示１４１０とを複数設定することができる。

案件項目データ１１００に対する更新指示１４００は、
・更新対象の項目を特定するための情報として項目ＩＤ １４０１を有する。
・更新の操作内容を特定するための情報として操作１４０２を有する。
・更新対象の項目に設定される値として、値１４０３を有する。

案件明細項目データ１１００に対する更新指示１４１０は、
・更新対象の項目を特定するための情報として、項目ＩＤ １４１１を有する。
・更新の操作内容を特定するための情報として、操作１４１２を有する。一例としては、「参照」、「更新」、「行追加」、「行変更」、「行削除」などが設定される。
・操作１４１２が、行変更、行削除の場合に対象とする行を特定するための、行番号１４１３を有する。
・操作１４１２が、「行追加」、「行変更」の場合に、どの明細項目に値を設定するのかを特定するために、明細項目ＩＤ １４１４を有する。
・操作１４１２が、「行追加」、「行変更」の場合に、明細項目に設定する値１４１５を有する。

以上で説明した各データを用いた処理の流れについて、図１５以降を参照にしながら説明する。

図１５は、図７のＳ７０５または、図８のＳ８０４に示した更新処理手順を示すフローチャートである。クライアントまたは外部システムからの更新指示を受け、案件データ処理部３０６で案件データを更新し(ステップＳ１５０２)、配送処理部３０７で配送処理を行う(ステップＳ１５０３)。

図１６は、図１５に示した配送処理Ｓ１５０３の処理手順を示すフローチャートである。配送処理部３０７が案件処理部３０３から配送要求を受信し処理が開始される(ステップＳ１６０１)。まず、受け取った配送要求内容を解析し、処理対象の案件ＩＤ １３０１、処理対象の工程ＩＤ １３０２、実行者ＩＤ １３０３、配送指示１３０４を取り出す(ステップＳ１６０２)。

次に、配送指示１３０４が指定されているかを確認し(ステップＳ１６０３)、存在する場合は指示内容に従って配送処理を行う(ステップＳ１６０７)。ここで、配送指示が指定されているということは、通常のワークフロークライアントからの要求がなされたものである点に留意されたい。すなわち、配送指示が指定されるということは、図７で構築されたワークフローのように、サーバと共通の入出力用のインタフェースを備えるクライアントからの要求だからである。したがって、この場合には、通常のワークフローの配送処理をそのまま実行することになる。

一方で、配送指示が存在しない場合は、外部システムからの処理要求があった場合である。かかる場合には、フローの工程や、条件などの配送定義テーブルに定義されている情報に基づいて、配送処理の要否および配送処理の内容などが決定される。以下、図１６に戻って説明を続ける。案件項目データテーブル１１００の案件ＩＤ １１０１と処理対象の案件ＩＤ １３０１が一致する案件項目データ、および案件明細項目データテーブル１１１０の案件ＩＤ １１１１と処理対象の案件ＩＤ １３０１が一致する案件明細項目データを取得する(ステップＳ１６０４)。次に、配送判断定義を取得する(ステップＳ１６０５)。このステップＳ１６０５の処理については、後述する図１７にて説明する。次に、取得した配送判断定義に基づいて配送内容が存在するかをチェックし(ステップＳ１６０６)、存在する場合は内容に従って配送処理を行い(ステップＳ１６０７)、存在しない場合は配送せずに終了する(ステップＳ１６０８)。ステップＳ１６０７については、後述する図１８にて説明する。なお、ここでは、配送をスキップさせているが、配送判断が行えない場合の処理を、別途設定することで、配送エラーとするか、配送実行をスキップするかを決定することが可能になる。

図１７は、図１６に示した配送判断定義取得Ｓ１６０５の処理手順を示すフローチャートである。プロセス定義３１４から現在の工程ＩＤを取得し、関連する配送判断定義３１６を取得する(ステップＳ１７０２)。そして、現在の案件データから、配送判断定義テーブル３１６の工程ＩＤ １０２１と処理対象の工程ＩＤ １３０２とが一致する、配送判断定義の条件１０２２と一致するものを検索し(ステップＳ１７０３、Ｓ１７０４、Ｓ１７０６)、見つかった場合は配送内容１０２３を返却する(ステップＳ１７０５)。

図１８は、図１６に示した配送実行Ｓ１６０７の処理手順を示すフローチャートである。案件データから次担当者項目を取得する(ステップＳ１８０２)。次担当者項目が指定されていない場合は、次の工程を処理する担当者の情報をプロセス定義３１４から現在の工程の定義を取得し、担当者情報を取得する(ステップＳ１８０３、Ｓ１８０４)。次に、配送内容が承認であるかをチェックし(ステップＳ１８０５)、承認である場合は承認処理を行いＳ１８０４で得られた担当者へ配送する(ステップＳ１８０６)。配送内容が承認でない場合、否認であるかをチェックし(ステップＳ１８０７)、否認である場合は否認処理を行う(ステップＳ１８０８)。配送内容が否認でない場合、差戻しであるかをチェックし(ステップＳ１８０９)、差戻しである場合は担当者に対し差し戻し処理を行う(ステップＳ１８１０)。配送内容が差し戻しでない場合は保留処理を行う(ステップＳ１８１１)。なお、先に説明したとおりであるが、配送とは、承認や否認、差し戻し、保留などのワークフロー工程の操作に対する概念である。例えば、承認は次の工程に進みことを意味し、否認は案件を却下して完了することを意味し、差戻しは直前、または任意の工程に戻すことを意味し、保留は工程を移動しないことを意味する。

図１９は、本発明の実施形態のワークフローシステムにおいてワークフローのプロセス定義の一例を示す図である。１９０１〜１９０３は業務プロセスのワークフロー工程の一例を示している。

申請工程１９０１は、申請に関する工程であり、申請１９０１が担当者によって申請されると業務を開始し、金額相見積１９０２の工程に遷移する。なお、図１９の例では、「担当者：制限なし」１９１１が設定されているので、誰でも申請処理を行うことが可能である。金額相見積工程１９０２は、外部業務システムによって、商品金額の見積が行われ、見積の結果が登録される工程である。一定の条件をクリアした場合には、経理承認工程１９０３に遷移する。経理承認工程１９０３は、経理承認１９０３が経理担当者によって承認されると業務は完了する。

図１９において、１９１１〜１９１３は、工程を処理することができる役割（もしくはユーザ）を表している。これは、図１０で示すように、プロセス定義テーブルの中の担当者ＩＤ １００２にて示され、また本明細書においては、組織情報としても説明を行っている。１９２１〜１９２２は工程の入力参照を行う帳票フォームを表している。金額相見積１９０２の工程では、外部業務システムが工程を処理するため、帳票フォームが設定されていないことに留意されたい。なお、１９３１は、工程の担当者に対して、承認依頼を通知するための手段が設定されている。

図２０は、本発明の実施形態のワークフローシステムにおいてワークフローの利用例の一例を示す図である。

（前提）
図５に示したワークフロー設計手順により、図２０で示すような業務が、図４に示すようなワークフロー設計の定義データ３１１として作成される。作成された定義データ３１１の内容としては、図９で示したデータ項目定義３１２、図１０で示した経路定義３１３（プロセス定義３１４、アクセス制御定義３１５、配送判断定義３１６）が設定されているものとする。さらに、ワークフロー設計の定義データ３１１をもとにワークフローが運用されているものとする。

また、申請１９０１の工程で、申請者Ａより申請処理が行われ、処理が金額相見積１９０２に移り、通知手段１００４に従って、外部業務システム１０１〜１０２に、処理依頼の通知が行われているものとする。なお、備品購買稟議の申請内容は、案件ＤＢ ３２１にＤ２００１のような案件データとして登録される。案件ＤＢは、案件データを格納するデータベースサーバであり、ワークフローサーバ（ＷＦサーバ）と同一であってもよいし、別個のサーバであってもよい。

（金額相見積１９０２の処理）
ステップＳ２００１では、Ａ社見積システム１０１が、ワークフローサーバ１０４に対して、見積依頼内容を確認するために、図１２のような案件データの参照要求１２００を送る。ステップＳ２００２では、ワークフローサーバ１０４が、案件ＤＢ ３２１から案件データＤ２００１を取得する。

ステップＳ２００３では、図２０で説明されている案件データＤ２００１から参照可能なデータを取り出す処理が行われる。参照可能なデータＤ２００２は、案件項目データ１１００の、
項目ＩＤ １１０２＝商品名：ホワイトボード
である。ステップＳ２００４では、ワークフローサーバ１０４から、Ａ社見積システム１０１に対して、Ｓ２００３で取り出された、参照可能な案件データＤ２００２が返却される。

ステップＳ２００５では、Ａ社見積システム１０１が（見積依頼内容を元に見積を行って）、ワークフローサーバ１０４に対してＡ社の見積結果を登録するために、図１３のような案件データの更新要求１３００を送る。案件更新指示１３０５には、Ｄ２００３のような内容が設定される。

ステップＳ２００６では、ワークフローサーバ１０４が、案件ＤＢ ３２１から案件データＤ２００１を取得する。ステップＳ２００７では、Ｓ２００６で取得した案件データＤ２００１に対して、案件データのデータ内容を変更する処理が行われる。Ｄ２００３には更新不可能な案件更新指示が無いので、すべての変更が適用される。ステップＳ２００８では、Ｓ２００７で変更したデータ内容Ｄ２００４で案件データを更新登録する。ステップＳ２００９では、図１６〜１８で説明される配送判断が行われるが、本事例の場合には、Ｄ２００４の案件データ内容に一致する配送判断定義３１６が存在しないため配送処理はスキップされる（Ｓ１６０６参照）。ステップＳ２０１０では、ワークフローサーバ１０４からＡ社見積システム１０１に対して、Ｓ２００５の見積結果登録要求が成功した旨が返される。

ステップＳ２０１１では、Ｂ社見積システム１０２が、ワークフローサーバ１０４に対して、見積依頼内容を確認するために、図１２のような案件データの参照要求１２００を送る。ステップＳ２０１２では、ワークフローサーバ１０４が、案件ＤＢ ３２１から案件データＤ２００４を取得する。ステップＳ２０１３では、図２０で説明されている案件データＤ２００４から参照可能なデータを取り出す処理が行われる。参照可能なデータＤ２００５は、案件項目データ１１００の、
項目ＩＤ １１０２＝商品名：ホワイトボード
である。ステップＳ２０１４では、ワークフローサーバ１０４から、Ｂ社見積システム１０２に対して、Ｓ２０１３で取り出された参照可能な案件データＤ２００５が返却される。

ステップＳ２０１５では、Ｂ社見積システム１０２が（見積依頼内容を元に見積を行い）、ワークフローサーバ１０４に対してＢ社の見積結果を登録するために、図１３のような案件データの更新要求１３００を送る。案件更新指示１３０５には、Ｄ２００６のような内容が設定される。ステップＳ２０１６では、ワークフローサーバ１０４が、案件ＤＢ ３２１から案件データＤ２００４を取得する。ステップＳ２０１７では、Ｓ２０１６で取得した案件データＤ２００４に対して、案件データのデータ内容を変更する処理が行われる。

Ｄ２００６の[見積履歴]行追加の更新指示は、適用される。しかしながら、Ｄ２００６の案件見積金額の更新指示が、アクセス制御定義３１５の条件に成り立たないため、案件見積金額の変更のみ適用されない。つまり、Ｂ社の見積金額は、￥９７，０００円であるのに対して、Ａ社の見積金額は、￥９６，０００円であるために、Ｂ社の見積金額の方が少ないために、見積金額の更新は行われない。これに対して、見積履歴についての条件には、合致するために、見積更新履歴には、データが追加更新される。

より詳細に説明すると、アクセス制御定義３１５の工程ＩＤ １０１１は「金額相見積」で、操作ＩＤ １０１５は「更新」の場合には、図１０で示す、
条件１０１２ 案件.最低見積金額 ＞ 更新指示.最低見積金額 が成り立たない。したがって、項目ＩＤ １０１３の「最低見積金額」の更新はできないことになる。

ステップＳ２０１８では、Ｓ２００７で変更したデータ内容で案件データを更新登録する。更新後の案件データはＤ２００７のようになる。ステップＳ２０１９では、図１６〜１８で説明される配送判断が行われ、配送判断定義３２１と案件データＤ２００７の内容から、「承認」処理が決定される。具体的には、配送判断定義３１６の工程ＩＤが「金額相見積」で、条件の
(見積金額(\96,000) <= 希望金額(\100，000)) and count(見積履歴) >= 2
が成り立つ。したがって、配送内容ＩＤ １０２０の「承認」が配送内容として決定される。ステップＳ２０２０では、Ｓ２０１９で決定した配送内容「承認」を実行する。ステップＳ２０２１では、ワークフローサーバ１０４からＢ社見積システム１０２に対して、Ｓ２０１５の見積結果登録要求が成功した旨が返される。

以上、示したように本発明によれば、外部業務システムと連携する工程、案件のデータ状態、によって配送を制御する経路定義をすることができる。また、この定義にもとづいて案件データの入出力を処理することで、案件データ状態によってフロー制御が可能なワークフローシステムと外部業務システムとが連携した業務運用システムを実現できる。

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

本発明によるワークフロー構築・運用システムの一実施例の構成を示すシステム構成図である。 図１に示したワークフローサーバ１０４とワークフロークライアント105〜106のハードウェア構成の一例を示すブロック図である。 図１に示したワークフローサーバ１０４において実現される機能構成を示すブロック図である。 本発明の実施形態のワークフローを構築する場合のデータ関連の一例を示す図である。 本発明の実施形態のワークフローを構築する場合のデータ作成手順の一例を示す図である。 図５に示した経路定義の作成Ｓ５０４（プロセス定義３１４、アクセス制御定義３１５、配送判断定義３１６）の一例を示す画面イメージである。 本発明の実施形態のワークフローシステムにおいてユーザー（ワークフロークライアント１０５〜１０６）のワークフロー利用手順の一例を示すフロー図である。 本発明の実施形態のワークフローシステムにおいて外部業務システムサーバ１０１〜１０２のワークフロー利用手順の一例を示すフロー図である。 図３で示したデータ項目定義３１２のデータ構造を示す図である。 図３で示した経路定義３１３（プロセス定義３１４、アクセス制御定義３１５、配送判断定義３１６）のデータ構造図である。 図３で示した案件データ321のデータ構造図である。 図３で案件処理部３０３から案件データ処理部３０６に送られる案件参照要求の構造を示す図である。 図３で案件処理部３０３から案件データ処理部３０６に送られる案件更新要求の構造を示す図である。 図１３で示した案件更新指示１３０７の構造の一例を示す図である。 図７のＳ７０５または、図８のＳ８０４の更新処理手順を示すフローチャートである。 図３に示した配送処理部３０７の配送処理手順を示すフローチャートである。 図１６に示した配送判断定義取得Ｓ１６０５の処理手順を示すフローチャートである。 図１７に示した配送処理Ｓ１６０７の処理手順を示すフローチャートである。 本発明の実施形態のワークフローシステムにおいてワークフローのプロセス定義の一例を示す図である。 本発明の実施形態のワークフローシステムにおいてワークフローの利用例の一例を示す図である。

符号の説明

１０１〜１０２ 外部業務システムサーバ
１０３ ネットワーク
１０４ ワークフローサーバ
１０５〜１０６ ワークフロークライアント
１０７ イントラネット
３０１ ワークフロー処理部
３０２ 業務定義設定処理部
３０３ 案件処理部
３０４ データ項目定義処理部
３０５ 経路定義処理部
３０６ 案件データ処理部
３０７ 配送処理部
３１１ 定義データ
３１２ データ項目定義
３１３ 経路定義
３１４ プロセス定義
３１５ アクセス制御定義
３１６ 配送判断定義
３２１ 案件データ

Claims (8)

1. 外部システムと連携可能なワークフローシステムにおいて、
   前記外部システムからのデータであってフロー制御に関する指示が含まれていないデータに応じたフロー制御を示すフロー制御情報を定義する定義手段と、
   前記定義したフロー制御情報に基づいてワークフローを制御する制御手段と
   を備えることを特徴とするワークフローシステム。
2. 前記定義手段は、前記フロー制御情報として、ワークフローの工程に関する工程情報をキーとするフロー制御情報を定義することを特徴とする請求項１に記載のワークフローシステム。
3. 前記定義手段は、工程の遷移を指示する工程遷移指示情報をさらに含む前記フロー制御情報を定義することを特徴とする請求項２に記載のワークフローシステム。
4. 前記定義手段は、前記工程毎に、一または複数の所定の条件と、工程遷移指示情報と、を少なくとも含む一または複数のレコードからなるフロー制御情報を定義することを特徴とする請求項３に記載のワークフローシステム。
5. 前記外部システムからのデータを取得する取得手段をさらに備え、
   前記制御手段は、
   前記取得したデータに工程の遷移を指示するデータが含まれているかを判定する手段と、
   前記判定した結果が工程の遷移を指示するデータが含まれていない場合に、前記定義されたフロー制御情報を取得する手段と、
   を含み、
   前記取得したデータと、前記取得したフロー制御情報と、に基づいて工程の遷移のフロー制御を行うことを特徴とする請求項１から４のいずれかに記載のワークフローシステム。
6. 外部システムと連携可能なワークフローの処理方法において、
   前記外部システムからのデータであってフロー制御に関する指示が含まれていないデータに応じたフロー制御を示すフロー制御情報を定義する定義ステップと、
   前記定義したフロー制御情報に基づいてワークフローを制御する制御ステップと
   を備えることを特徴とするワークフローの処理方法。
7. コンピュータに、請求項１から５のいずれかに記載の各機能を実現させるためのプログラム。
8. コンピュータに、請求項１から５のいずれかに記載の各機能を実現させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images