JP4628048B2 - ワークフローサーバおよびワークフロー制御方法およびプログラムおよび記録媒体 - Google Patents

Description

本発明は、クライアント・サーバシステムで構成されるワークフローシステムにおいて電子文書（業務案件）の回覧を代行委任制御可能なワークフローサーバおよびワークフロー制御方法およびプログラムおよび記録媒体に関する。

電子文書（業務案件）の承認業務の効率を向上させるインフラの１つとして、ワークフローシステムがある。

ワークフローシステムは、組織または役割、もしくはユーザという個人単位の配布者を設定し、配布者間の電子文書の配布ルート（配布順序）を予めワークフローサーバに登録しておき、この順序に従って自動的に電子文書を配布しようとするものである。

ワークフローシステムでは、案件の配布先となったユーザが不在となる場合の業務停滞を回避する目的で、他のユーザ（代行者）による案件処理を可能にしておく機能が必要とされている。

代行者による案件処理を可能にした従来のワークフローシステムとしては、たとえば、特許文献１（特開平１０−１７７６０３号公報）がある。

これは、不在ユーザへ電子文書を送付する際、代行者が指定されている場合は指定されているユーザを新たな送付先ユーザとして指定し、また、代行者が指定されていない場合は同一の役割をもったユーザを１つにまとめたロール内の別のユーザを新たな配布先候補として指定し、ロールごとに文書の受付可否（受付状態）を記録したユーザ管理テーブルを参照して、代行者を決定しようとするものである。即ち、ユーザ管理テーブルにおける送付先候補者の受付状態が受付許可を示していれば、該候補者を代行者に決定し、指定された送付先候補者の受付状態が受付禁止を示していた場合は、案件の最初の送付に失敗したことになり、ロールに定義された次のユーザについて、同様の手順を繰り返す。
特開平１０−１７７６０３号公報

上記のワークフローシステムは、代行者が設定されていない場合にはロール内のユーザを順次、候補としていくため業務停滞回避の面では効果的であるが、しかし一方では、ロールの設定者は同一の役割をもつユーザを業務内容を確認しながら案件ごとに登録、受け付け可否設定も行わなければならず、運用や管理の面で非効率的である。

また、代行者をロールの中から選択するため、ロールの設定方法（設定ミス）によっては、案件と関連のない代行者に配布されてしまう可能性もあるという問題点があった。本来、業務案件は、業務の流れ、即ち組織に従って配布されるものであり、ロールで設定されたユーザといえども、配送ルートにない組織の者が承認・決裁業務を代行するのは不自然であり、業務上問題がある。

本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、不在担当者に送付された電子文書（業務案件）を業務の流れ、即ち組織に従って配送し、代行委任設定されたユーザといえども、配送ルートにない組織のユーザには承認・決裁業務を代行させない（即ち、配送ルートにある組織のユーザには承認・決裁業務を代行させる）というような業務の流れに従った自然な代行委任処理を可能とする、フレキシブルなワークフローシステムを構築可能なワークフローサーバおよびワークフロー制御方法およびプログラムおよび記録媒体を提供することである。

本発明は、クライアント・サーバシステムで構成されるワークフローシステムにおいて電子文書の回覧を制御するワークフローサーバであって、登録される複数のユーザ情報、前記各ユーザ情報に紐付けられた役割情報、前記各ユーザ情報に紐付けられた所属情報、前記各所属情報と上位の所属情報とを階層的に紐付けた階層情報、電子文書の配送経路を前記役割情報により定義した経路情報、及び、前記各ユーザ情報に紐付けて前記各ユーザ情報の委任先として設定される１又は複数の委任先ユーザ情報を記憶可能な記憶手段と、クライアントからの電子文書処理要求に応じて、該電子文書に対して役割情報で定義された経路情報に基づいて該電子文書の次配送先となるユーザ情報を決定するとともに、該決定された配送先となるユーザ情報に紐付けられて委任先ユーザ情報が前記記憶手段に記憶されている場合には、前記配送先を該委任先ユーザ情報に変更決定する配送先決定手段と、前記電子文書の起案者のユーザ情報を含む電子文書の配送情報を記憶する配送情報記憶手段と、前記配送情報記憶手段に記憶された前記起案者のユーザ情報から、前記記憶手段に記憶された該起案者のユーザ情報に紐付けられた所属情報を取得する取得手段とを有し、前記配送先決定手段は、前記決定された配送先のユーザ情報に紐付けられた複数の委任先ユーザ情報が前記記憶手段に記憶されている場合には、該複数の委任先ユーザ情報のうち、前記階層情報により前記取得手段で取得された起案者の所属情報の上位の所属情報に紐付けられた委任先ユーザ情報を、前記電子文書の次配送先となるユーザ情報として決定することを特徴とする。

本発明によれば、不在担当者（代行依頼者）に送付される電子文書（業務案件）を、業務の流れ、即ち組織に従って配送し、代行委任設定されたユーザといえども、配送ルートにない組織のユーザには承認・決裁業務を代行させない（配送ルートにある組織のユーザには承認・決裁業務を代行させる）というような業務の流れに従った自然な代行委任処理を可能とする。

従って、電子文書（業務案件）ごとに、配送ルートに沿った、フレキシブルなワークフローシステムを構築することができる等の効果を奏する。

以下、図面を参照して、本発明の詳細を説明する。

図１は、本実施形態が適用されるワークフローシステムの概略構成を示す図である。

本実施形態におけるワークフローシステムは、ワークフロー及び伝票設計用コンピュータ端末（ワークフロー及び伝票設計用端末）４００、業務を遂行する処理者（担当者）に対応して設けられたワークフロー操作用コンピュータ端末（ワークフロー操作用端末）３００、ワークフローを実行するための各種テーブル，各種プログラムを格納するワークフローサーバ２００を備えている。

これらワークフロー及び伝票設計用端末４００，ワークフロー操作用端末３００，ワークフローサーバ２００は、それぞれネットワーク５００に接続され運用されている。

ワークフロー及び伝票設計用端末４００は、伝票デザイナプログラム４０１及びシステム管理プログラム４０２を有し、ワークフローシステムにて使用する伝票の定義体の作成及びワークフローシステムで利用する各種定義情報の作成を行う。例えば、ワークフロー及び伝票設計用端末４００は、ワークフローサーバ２００に組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，各種伝票情報等を登録することができる。このワークフロー及び伝票設計用端末４００は、これらの作業を行うために、自己の識別情報を入力することによりワークフローサーバ２００に接続することが可能になる。

ワークフロー操作用端末３００は、ワークフロー操作用端末３００上で実行されるＷｅｂブラウザ３０１を用いて、伝票に関するアクセス情報をワークフローサーバ２００に対してＨＴＴＰで送信し、その結果を受信するものであり、その際に、発生する表示・計算処理は、Ｊａｖａ（登録商標）アプレット３０２等を利用することにより実行する。なお、このワークフロー操作用端末３００は、予め指定された所定の業務を行う担当者（例えば、起票者、課長、部長等）に配置されている。

ワークフローサーバ２００は、ワークフローシステムに関する情報（組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，配送情報テーブル，各種伝票情報）を格納するＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）２０５、ワークフロー操作用コンピュータ端末よりの要求を受け付けて要求を実行するためのＨＴＴＰサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０３、ワークフロー通知機能を実現するＳＭＴＰサーバ２０４にて構成されている。

以下、図２を参照して、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成について説明する。

図２は、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。

図２において、１０１はＣＰＵで、ＲＯＭ１０３又はハードディスク（ＨＤ）（その他の記憶装置、例えば、フレキシブルディスク，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭ等どのような記憶装置であってもよい）１０４に格納されたプログラムをＲＡＭ１０２上にロードして実行することにより、コンピュータ全体を制御する。ＲＡＭ１０２は、ＣＰＵ１０１の作業領域として使用される。

１０７は通信インタフェースで、ネットワーク５００への接続を可能とする。１０５は入力装置で、キーボードやマウス等のポインティングデバイス等に相当する。１０６は表示装置で、ＣＲＴ，ＬＣＤ等で構成される。

なお、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５は、ワークフローサーバ２００のＨＤ１０４内に構築されている。また、ワークフローサーバ２００のＨＴＴＰサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０３，ＳＭＴＰサーバ２０４は、ワークフローサーバ２００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。

また、図１に示したワークフロー操作用端末３００のＷｅｂブラウザ３０１は、ワークフロー操作用端末３００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。

さらに、図１に示したワークフロー操作用端末３００のＪａｖａ（登録商標）アプレット３０２は、ワークフロー操作用端末３００のＣＰＵ１０１が、ワークフローサーバ２００よりダウンロードされたプログラムをＷｅｂブラウザ３０１上で実行することにより、実現される。

また、図１に示したワークフロー及び伝票設計用端末４００の伝票デザイナプログラム４０１，システム管理プログラム４０２は、ワークフロー及び伝票設計用端末４００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。

図３は、図１に示したワークフローシステムにおける伝票の流れを示す模式図である。

本実施形態のワークフローシステムでは、ワークフロー操作用端末３００を用いて、図３に示すように、伝票の起票，伝票の承認／否認の手続きを、ノードと呼ばれる組織と役割で定義された担当者が行う。なお、伝票が配送されるノードをひとつに括ったものをビジネスプロセスと定義する。

図４は、本実施形態のワークフローシステムにおける説明に用いる組織の階層構造の一例を示す組織図である。

組織は階層構造になっており、図４に示すように、部署には２桁のコードが付けられ、最上位の階層から任意の部署までの部署コードを連結したコードが組織ＩＤとなる。

例えば、６−（１５）に示す「Ａ会社Ａ事業本部ＡＡ本部ＡＡＡ部１課」を部署登録したい場合、組織ＩＤは、６−（１０）,６−（１１）,６−（１２）,６−（１３）,６−（１４）に示す各部署の部署コード「８０」，「１０」，「１０」，「１０」，「１０」を連結した「８０１０１０１０１０」となり、後述する図５の３−Ａ−（１）に示すように組織テーブルに登録される。なお、図４の組織図を登録したものが図５に示す組織テーブルとなる。

以下、図４の組織図に沿って、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，配送情報テーブルについて説明する。

図５は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される組織テーブルのデータ構造の一例を示すデータ構成図である。なお、この組織テーブルは、ワークフローを実現するための組織に関する情報記憶するためのものである。

図５に示す組織テーブルにおいて、組織ＩＤは、任意の組織名をコードとして表記したものであり、常に上位組織ＩＤを網羅している。また、組織名は、組織ＩＤの表示上の名称を示したものである。さらに、親組織ＩＤは、上位の組織ＩＤを示したものである。

図６は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される役割テーブルのデータ構造の一例を示すデータ構成図である。なお、この役割テーブルは、ワークフローを実現するための役割に関する情報記憶するためのものである。

図６に示す役割テーブルにおいて、役割ＩＤは、任意の役割名をコードとして表記したものである。また、役割名は、役割ＩＤの表示上の名称を示したものである。

例えば、３−Ｂ−（１）に対応する役割は、役割ＩＤが「００２」、役割名が「事業本部長」であることを示している。

図７は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶されるユーザテーブルのデータ構造の一例を示すデータ構成図である。なお、このユーザテーブルは、ワークフローを利用するためのユーザの情報を記憶するためのものである。

図７に示すユーザテーブルにおいて、ユーザＩＤは、利用者を任意のコードとして表示したものである。また、パスワードは、ワークフローシステムにログインする際にユーザＩＤと共に認証に利用するためのものである。さらに、ユーザ名は、ユーザＩＤの表示上の名称を示したものである。また、Ｅメールは、図１に示したＳＭＴＰサーバ２０４により行われるワークフロー通知処理の通知先を示すものである。

さらに、委任先ＩＤは、代行依頼される人（依頼先）のユーザＩＤを登録する項目である。また、複数委任は、後述する下位組織の複数委任設定の有無を登録する項目である。

なお、「委任先ＩＤ」項目，「複数委任」項目は、本発明の特徴の委任制御を実現するためのものであり、後述する図１６に示す代行設定画面からの委任設定により設定制御される。

以下、代行設定について簡単に説明する。

まず、1人に代行委任する場合、例えば、図７の３−Ｃ−（１）に示すユーザＩＤ「Ｕ００１２」の「課長Ｋ１」が、３−Ｃ−（２）に示すユーザＩＤ「Ｕ０００７」の「部長Ｂ１」に代行依頼する場合は、３−Ｃ−（３）に示すように、ユーザＩＤ「Ｕ００１２」のレコードの「委任先ＩＤ」に「部長Ｂ１」のユーザＩＤ「Ｕ０００７」を登録する。

次に、複数人に代行委任する場合、３−Ｃ−（４）に示すユーザＩＤ「Ｕ０００２」の「事業本部長Ｊ」が、３−Ｃ−（５）に示すユーザＩＤ「Ｕ０００３」〜「Ｕ０００６」の「本部長Ｈ１」〜「本部長Ｈ４」に代行依頼する場合は、３−Ｃ−（６）に示すように、ユーザＩＤ「Ｕ０００２」のレコードの「委任先ＩＤ」に「本部長Ｈ１」〜「本部長Ｈ４」のユーザＩＤ「Ｕ０００３」，「Ｕ０００４」，「Ｕ０００５」，「Ｕ０００６」を登録するとともに、３−Ｃ−（７）に示すように、「複数委任」に「１」を登録する。

図８は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される役職テーブルのデータ構造の一例を示すデータ構成図である。なお、この役職テーブルは、ワークフローを利用するための役職の情報を記憶するためのものである。

図８に示すように、役職テーブルの各レコードは、ユーザテーブル内で定義されている「ユーザＩＤ」，役割テーブル内で定義されている「役割ＩＤ」，組織テーブル内で定義されている「組織ＩＤ」で構成されている。

例えば、図４の６−（９）に示した「Ａ事業本部」の「事業本部長」に「事業本部長Ｊ」を登録する場合、役職テーブルに登録するユーザＩＤは、ユーザテーブル（図７）から「事業本部長Ｊ」のユーザＩＤを参照して「Ｕ０００２」（３−Ｃ−（４））となる。また、役職テーブルに登録する役割ＩＤは、役割テーブル（図６）から「事業本部長」の役割ＩＤを参照して「００２」（３−Ｂ−（１））となる。さらに、役職テーブルに登録する組織ＩＤは、組織テーブル（図５）から「Ａ会社Ａ事業本部」の組織ＩＤを参照して「８０１０」となる。

図９は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される配送定義情報のデータ構造の一例を示すデータ構成図である。なお、この配送定義情報は、伝票が配送される経路を定義した情報を記憶するためのものである。

ここでは、一例として役割が「社員」→「部長」→「本部長」→「事業本部長」→「社長」の順に伝票配送をする例を示している。このように伝票の配送経路を定義した場合、この配送経路の配送定義情報は、図９に示すような５レコードの情報として作成される。

以下、配送定義情報の作成方法について説明する。

例えば、伝票名が「交通費」の場合、まず、ユーザがワークフロー及び伝票設計用端末４００から、システム管理プログラムを用いて、伝票名に「交通費」と設定し、次に、各ノードを設定する。ノード１を例にすると、ノード１に役割ＩＤに部長を示すコード「Ｕ０００７」を設定し、対象となる組織を選択（ここでは組織ＩＤ「８０」の「Ａ会社」を選択）することにより、「伝票名」が「交通費」，「組織ＩＤ」が「８０」，「ノード番号」が「１」，「経路役割ＩＤ」が「部長」を示す役割ＩＤ「００４」、「経路組織ＩＤ」が役割を担う組織ＩＤとして設定される。なお、ここでは、対象となる組織として、組織ＩＤ「８０」の「Ａ会社」が選択されており、役割ＩＤ「部長」を持つ配送対象者は決定されない。そのため、経路組織ＩＤは「ＮＵＬＬ」となっている（図中では空白で示している）。

図１０は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される配送情報テーブルのデータ構造の一例を示すデータ構成図である。なお、この配送情報テーブルは、後述する図１１に示すワークフローシステムにおける配送処理時に図９に示した配送定義情報に基づいて生成されるものであり、ワークフローの経路，状態等を記憶するためのものである。また、この配送情報テーブルは、特に、ユーザＩＤ「Ｕ００１２」のユーザが起票した場合に対応する。この場合、伝票は、ユーザＩＤ「Ｕ００１２」，「Ｕ０００７」，「Ｕ０００３」，「Ｕ０００２」，「Ｕ０００１」のように配送されることとなる。

以下、図１１を参照して、本発明のワークフローシステムにおける配送処理手順の全体の流れについて説明する。

図１１は、本発明のワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートであり、図１に示したワークフローサーバ２００のワークフロープログラム２０３による配送処理に対応する。なお、図中、（５０００）〜（５０１５）は各ステップを示す。

まず、ワークフロープログラム２０３を実行するワークフローサーバ２００のＣＰＵ（以下、ワークフローサーバ２００のＣＰＵ）が、ワークフロー操作用端末３００より伝票処理要求を受信すると（ステップ（５０００））、配送処理を開始する。

ワークフローサーバ２００のＣＰＵは、ステップ（５０００）で受信した伝票処理要求の要求区分である「起票」，「承認」，「否認」に基づいて、配送処理を切り替えていく（ステップ（５００１））。

ステップ（５００１）において、ワークフローサーバ２００のＣＰＵが、ステップ（５０００）で受信した伝票処理要求の要求区分が「起票」であると判定した場合には、ステップ（５００２）において、ワークフローサーバ２００のＣＰＵは、起票時の情報として、ノード番号「０」を配送情報テーブルに設定する。「処理ユーザ」には、起票したユーザのユーザＩＤを設定する。

例えば、図９に示した配送定義情報に基づく伝票が起票された場合、図１０に示したように、配送情報テーブルのノード番号「０」のレコードに、伝票名に「交通費」、伝票番号を起票時に発行される伝票番号（ここでは「００００１」とする）、ノード番号に「０」、処理ユーザを起票ユーザのユーザＩＤ「Ｕ００１２」、状態に「処理済」を設定する。

次に、ステップ（５００３）において、ワークフローサーバ２００のＣＰＵは、現在のノード番号を「１」とし、ステップ（５０００）で受信した伝票処理要求の伝票名に対応する配送定義情報（図９）を参照し、ノード番号「１」の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップ（５００９）に進む。

例えば、図９に示した配送定義情報に基づく伝票が起票された場合、経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」を取得する。

一方、ステップ（５００１）で、ワークフローサーバ２００のＣＰＵが、ステップ（５０００）で受信した伝票処理要求の要求区分が「承認」又は「否認」であると判定した場合には、ステップ（５００４）において、ワークフローサーバ２００のＣＰＵは、配送情報テーブル（図１０）を参照して現在のノード番号を取得する。

次に、ステップ（５００５）において、ワークフローサーバ２００のＣＰＵは、ステップ（５０００）で受信した伝票処理要求の要求区分が「承認」であるか「否認」であるかを判定し、「否認」であると判定した場合には、ステップ（５００８）において、ステップ（５００４）で取得した現在のノード番号をデクリメントした後、該デクリメントした現在のノード番号を持つ配送定義情報（図９）を参照し、該現在のノード番号の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップ（５００９）に進む。

一方、ステップ（５００５）で、ワークフローサーバ２００のＣＰＵが、ステップ５０００で受信した伝票処理要求の要求区分が「承認」であると判定した場合には、ステップ（５００６）において、ワークフローサーバ２００のＣＰＵは、ステップ（５０００）で受信した伝票処理要求が最終承認者からのものであるか否かを判定する。

ステップ（５００６）で、ワークフローサーバ２００のＣＰＵが、ステップ（５０００）で受信した伝票処理要求が最終承認者からのものであると判定した場合には、ステップ（５０１５）において、配送情報テーブル（図１０）から当該配送情報を削除するとともに、ＳＭＴＰサーバ２０４により起票者に全て承認された旨のワークフロー通知を行い、処理を終了する。

一方、ステップ（５００６）で、ワークフローサーバ２００のＣＰＵが、ステップ（５０００）で受信した伝票処理要求が最終承認者からのものでないと判定した場合には、ステップ（５００７）において、ステップ（５００４）で取得した現在のノード番号をインクリメントした後、該インクリメントした現在のノード番号を持つ配送定義情報（図９）を参照し、該現在のノード番号の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップ（５００９）に進む。

そして、ステップ（５００９）において、ワークフローサーバ２００のＣＰＵは、ステップ（５００３）、（５００７）、又は（５００８）で取得した経路役割ＩＤ，経路組織ＩＤを用いて、ユーザ役割情報（図８に示した役職テーブル）を参照して次の配送対象ユーザＩＤを決定する（役職テーブル（図８）から役割ＩＤが経路役割ＩＤで、組織ＩＤが経路組織ＩＤのユーザＩＤを決定する）。なお、取得した組織経路ＩＤが「ＮＵＬＬ」の場合（図９の空白の場合）には、現在のノード番号より１つ小さいノード番号に対応するユーザＩＤの属する組織ＩＤを「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定するものとする。さらに、これでも次の配送対象ユーザＩＤを決定することができない場合（ユーザ役職情報（図８）に、役割ＩＤが経路役割ＩＤで、組織ＩＤが経路組織ＩＤのレコードが存在しない場合）には、該組織ＩＤの親組織ＩＤを「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定するものとし、次の配送対象ユーザＩＤが決定するまでこの処理を繰り返すものとする。

例えば、図９に示した配送定義情報に基づく伝票が起票された場合、ステップ（５００３）で、ノード番号「１」の経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」が取得され、該取得された経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」に基づいて配送対象となるユーザＩＤが決定される。ここで、取得した経路組織ＩＤが「ＮＵＬＬ」であるため、現在のノード番号「１」より１つ小さいノード番号「０」に対応するユーザＩＤ「Ｕ００１２」の属する組織ＩＤ「８０１０１０１０１０」を「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定する。このとき、役職テーブル（図８）に、役割ＩＤ「００４」で、組織ＩＤ「８０１０１０１０１０」のレコードが存在しないため、組織ＩＤ「８０１０１０１０１０」の親組織ＩＤ「８０１０１０１０」を「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定する。ここで、役職テーブル（図８）を参照すると、役割ＩＤ「００４」で、組織ＩＤ「８０１０１０１０１０」のユーザＩＤは「Ｕ０００７」となり、このユーザＩＤ「Ｕ０００７」が次の配送対象ユーザＩＤに決定される。（図１０のノード番号２）。

次に、ステップ（５０１０）において、ワークフローサーバ２００のＣＰＵは、ユーザテーブル（図７）を参照して、上記決定された次の配送対象ユーザＩＤに対応する委任先ＩＤが設定されているか否かを判定する。

ステップ（５０１０）で、ワークフローサーバ２００のＣＰＵが、上記決定された次の配送対象ユーザＩＤに対応する委任先ＩＤが設定されていると判定した場合には、ステップ（５０１１）において、委任依頼先決定処理（次の配送対象ユーザＩＤとなる委任依頼先を決定する処理（詳細には、図１７に示す））を行い、ステップ（５０１０）に戻る。

一方、ステップ（５０１０）で、ワークフローサーバ２００のＣＰＵが、上記決定された次の配送対象ユーザＩＤに対応する委任先ＩＤが設定されていないと判定した場合には、ステップ（５０１２）において、ワークフローサーバ２００のＣＰＵは、ステップ（５０００）で受信した伝票処理要求の要求区分が「承認」又は「起票」であるか「否認」であるかを判定し、「否認」であると判定した場合には、ステップ（５０１４）において、配送情報テーブル（図１０）から上記現在のノード番号を削除するとともに、ＳＭＴＰサーバ２０４により配送対象者に否認された旨のワークフロー通知を行い、処理を終了する。

一方、ステップ（５０１２）で、ワークフローサーバ２００のＣＰＵが、ステップ（５０００）で受信した伝票処理要求の要求区分が「承認」又は「起票」であると判定した場合には、ステップ（５０１３）において、配送情報テーブル（図１０）に次のノード番号の情報を設定（この時、「処理ユーザ」には、ステップ（５００９）で決定された次の配送対象ユーザＩＤを設定）するとともに、ＳＭＴＰサーバ２０４により配送対象者にワークフロー通知を行い、処理を終了する。

以下、図１２〜図１４を参照して、本発明の代行設定について説明する。

図１２〜図１４は、本発明の代行設定を説明するための配送ルートを示した模式図である。

まず、通常の代行について図１２，図１３を用いて説明する。

例えば、図１２に示すように、事業本部長Ｊ（７−（４））が本部長Ｈ１（７−（５））に代行依頼した場合について説明する。

まず、ユーザテーブル（図７）に代行依頼（委任先ＩＤ）を設定する。図７に示したように、ユーザテーブルの項目「ユーザＩＤ」の値が「事業本部長Ｊ」のユーザＩＤ「Ｕ０００２」であるレコードの項目「委任先ＩＤ」に、「本部長Ｈ１」のユーザＩＤ「Ｕ０００３」を登録する。これにより「事業本部長Ｊ」は「本部長Ｈ１」に代行依頼をしている状態（７−（６））となる。

この状態で、「部長Ｂ１」が起票すると、承認者は「本部長Ｈ１」となり伝票が「本部長Ｈ１」に渡り（７−（１））、「本部長Ｈ１」が承認する。すると、次承認者は「事業本部長Ｊ」となるが「事業本部長Ｊ」は「本部長Ｈ１」へ代行依頼（委任）しているため伝票は再び「本部長Ｈ１」に渡る（７−（６））。再度、「本部長Ｈ１」が承認する。すると、次承認者は「社長Ｓ」となる。よって、伝票の配送ルートは「部長Ｂ１」→「本部長Ｈ１」→「本部長Ｈ１」→「社長Ｓ」となる。

このように、代行依頼されたユーザ「本部長Ｈ１」が所属している組織「ＡＡ本部」内で起票された伝票の場合、配送ルートに問題はない。

しかし、組織外で起票された伝票の場合、例えば、図１３に示すように、「部長Ｂ４」が起票し、本部長Ｈ４（８−（１））に渡り、本部長Ｈ４が承認したとき、次承認者は「事業本部長Ｊ」となる（８−（２））。

ここで、次承認者「事業本部長Ｊ」は「本部長Ｈ１」へ代行を依頼している（８−（４））ため、伝票は「本部長Ｈ１」に渡ることになる。この場合、「部長Ｂ４」が起票した伝票が別の本部の人「本部長Ｈ１」に配送されることになり、業務上の配送ルートとして問題が発生する。

そこで、下位組織の複数のユーザに代行委任するとき、以下のように伝票を回付したい。この複数委任について図１４を用いて説明する。

例えば、「事業本部長Ｊ」が「本部長Ｈ１」〜「本部長Ｈ４」に代行依頼をしたとき、「部長Ｂ４」が起票した伝票は「本部長Ｈ４」のみに渡り（９−（５））、別組織の「本部長Ｈ１」〜「本部長Ｈ３」には伝票が渡らない（９−（６））ようにする。つまり、ワークフローサーバ２００が、別組織の代行依頼先を次承認者（次の配送者）としないように上述した図１１のステップ（５０１１）に示した委任依頼先決定処理を制御する。この制御が本発明の特徴であり、従来のワークフローシステムでは、図１４に示したような配送ルートを決定可能なものは存在しなかった。なお、委任依頼先決定処理の詳細は図１７に示す。

以下、その委任方式を下位組織の複数委任と名づけ、該下位組織の複数委任を実現するための委任設定（図７に示したユーザテーブルへの「委任先ＩＤ」，「複数委任」の設定）について説明する。

この委任設定は、ユーザが以下図１５に示す代行設定画面から下位組織への代行委任を設定するという簡単な操作を行うだけで、ワークフローサーバ２００のＣＰＵにより、後述する図１６に示すフローチャートに基づいて実行される。

以下、図１５，図１６を参照して、本発明の代行設定処理について説明する。

図１５は、本発明のワークフローシステムにおける代行設定画面の一例を示す模式図であり、代行設定を行うための画面に対応する。なお、この画面は、図１に示したワークフロー操作用端末３００からのユーザＩＤ及びパスワードによるユーザ認証後の代行委任設定指示により、ワークフローサーバ２００からワークフロー操作用端末３００に返送され、ワークフロー操作用端末３００のＷｅｂブラウザ３０１上で表示される。

図１５において、１０−（１）は委任先の組織範囲選択欄で、この代行設定画面表示前に認証されたユーザを基準とした「上位組織へ代行委任」，「下位組織へ代行委任」，「同組織へ代行委任」のいずれかを設定するためのものである。

１０−（２）は下位組織の複数委任設定欄で、下位組織の複数委任の「あり」又は「なし」を設定するためのものであり、委任先の組織範囲選択欄１０−（１）で、「下位組織へ代行委任」が設定された場合にのみ設定可能となるようにワークフローサーバ２００のＣＰＵが制御するものとする。

１０−（３）は委任役職選択欄で、委任したいユーザの役職を選択するためのものである。１０−（４）は委任ユーザ選択欄で、委任役職選択欄１０−（３）で選択された役職のユーザから委任したいユーザを選択するためのものである。この委任ユーザ選択欄１０−（４）は、下位組織の複数委任設定欄１０−（２）で、下位組織の複数委任の「あり」が設定されている場合にのみ複数選択可能となるようにワークフローサーバ２００のＣＰＵが制御するものとする。

１０−（５）は委任設定ボタンで、委任ユーザ選択欄１０−（４）で代行依頼したいユーザを選択後、この委任設定ボタンを押下することにより、該選択されたユーザへの委任設定処理を開始するように、ワークフローサーバ２００のＣＰＵが制御する。１０−（６）は取消ボタンで、委任ユーザ選択欄１０−（４）の選択状態を解除するためのものである。

１０−（７）は代行委任解除ボタで、設定済みの代行委任を解除するためのものであり、代行委任が設定されていない場合には選択不可能な状態に表示制御される。

なお、この代行設定画面で、委任先の組織範囲選択欄１０−（１），委任役職選択欄１０−（３），委任設定ボタン１０−（５），代行委任解除ボタン１０−（７）のいずれかがワークフロー操作用端末３００の入力装置から指示されるとその旨を示す代行設定処理要求が、ワークフロー操作用端末３００よりワークフローサーバ２００に送信され、図１６に示すフローチャートの処理が実行される。

図１６は、本発明のワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートであり、図１に示したワークフローサーバ２００のサーブレットエンジン２０２による代行設定画面処理に対応する。なお、図中、（１２００１）〜（１２０１１）は各ステップを示す。

まず、図１５に示した代行設定画面で、委任先の組織範囲選択欄１０−（１），委任役職選択欄１０−（３），委任設定ボタン１０−（５），代行委任解除ボタン１０−（７）のいずれかがワークフロー操作用端末３００の入力装置から指示され、その旨を示す代行設定処理要求が、ワークフロー操作用端末３００よりワークフローサーバ２００に送信されると、サーブレットエンジン２０２を実行するワークフローサーバ２００のＣＰＵ（以下、ワークフローサーバ２００のＣＰＵ）が、図１５の代行設定画面表示前に認証されたユーザに対応する処理を開始し、まず、ステップ（１２００１）において、ワークフロー操作用端末３００より代行設定処理を受信する。

次に、ステップ（１２００２）において、ワークフローサーバ２００のＣＰＵは、受信した処理要求を判定し、委任先の組織範囲選択欄１０−（１）で組織範囲を選択したことに対する処理要求であると判定した場合には、ステップ（１２００７）において、ワークフローサーバ２００のＣＰＵは、選択された組織範囲に存在するユーザが持つ役割を役割テーブル（図８）から取得しワークフロー操作用端末３００に返信し、図１５の委任役職選択欄１０−（３）に表示させるように制御する。

次に、ステップ（１２００８）において、ワークフローサーバ２００のＣＰＵは、委任先の組織範囲選択欄１０−（１）で「下位組織」が選択されているか否かを判定し、「下位組織」が選択されていると判定した場合には、ステップＳ（１２００９）において、ワークフローサーバ２００のＣＰＵは、下位組織の複数委任設定１０−（２）を使用可能にし、処理を終了する。

一方、ステップ（１２００８）で、ワークフローサーバ２００のＣＰＵが、委任先の組織範囲選択欄１０−（１）で「下位組織」が選択されていないと判定した場合には、そのまま処理を終了する。

また、ステップ（１２００２）で、ワークフローサーバ２００のＣＰＵが、委任役職選択欄１０−（３）で役職を選択したことに対する処理要求であると判定した場合には、ステップ（１２００３）において、ワークフローサーバ２００のＣＰＵは、選択された役職に存在するユーザの情報を役割テーブル（図８），役割テーブル（図６），ユーザテーブル（図７）から取得しワークフロー操作用端末３００に返信し、委任ユーザ選択欄１０−（４）に表示させるように制御し、処理を終了する。なお、ステップ（１２００３）の処理において、ワークフローサーバ２００のＣＰＵは、複数委任役職選択欄１０−（２）の下位組織の複数委任設定で「あり」が選択されている場合にのみ委任ユーザ選択欄１０−（４）において複数選択可能となるように制御する。

また、ステップ（１２００２）で、ワークフローサーバ２００のＣＰＵが、委任設定ボタン１０−（５）を指示したことに対する委任設定処理要求であると判定した場合には、ステップ（１２００４）において、ワークフローサーバ２００のＣＰＵは、委任ユーザ選択欄１０−（４）で選択されている１又は複数のユーザのユーザＩＤを、図７に示したユーザテーブルの上述の認証されたユーザに対応するレコードの「委任先ＩＤ」項目に設定する。なお、ユーザが複数選択されている場合、ユーザーＩＤを“；”で連結して設定するものとする。

次に、ステップ（１２００５）において、ワークフローサーバ２００のＣＰＵは、下位組織の複数委任設定で「あり」が選択されているか否かを判定し、下位組織の複数委任設定で「あり」が選択されていると判定した場合には、ステップＳ（１２００６）において、ワークフローサーバ２００のＣＰＵは、図７に示したユーザテーブルの「複数委任」項目に「１」を設定し、処理を終了する。

一方、ステップ（１２００５）で、ワークフローサーバ２００のＣＰＵが、委任先の組織範囲選択欄１０−（１）で「下位組織」が選択されていないと判定した場合には、そのまま処理を終了する。

また、ステップ（１２００２）で、ワークフローサーバ２００のＣＰＵが、代行委任解除ボタン１０−（７）を指示したことに対する代行委任解除処理要求であると判定した場合には、ステップ（１２０１０）において、ワークフローサーバ２００のＣＰＵは、図７に示したユーザテーブルの「委任先ＩＤ」項目のユーザＩＤを削除し、ステップ（１２０１１）において、図７に示したユーザテーブルの「複数委任」項目にＮＵＬＬを設定し、処理を終了する。

以下、図１７のフローチャートを参照して、本発明の特徴的構成である図１４に示した委任配送を実現するための委任依頼先決定処理（図１６のステップ（５０１１））について説明する。

図１７は、本発明のワークフローシステムにおける第３の制御処理手順の一例を示すフローチャートであり、図１に示したワークフローサーバ２００のサーブレットエンジン２０２による委任依頼先決定処理（図１６のステップ（５０１１））に対応する。なお、図中、（１１００１）〜（１１０１１）は各ステップを示す。

まず、ステップ（１１００１）において、ワークフローサーバ２００のＣＰＵは、図７に示したユーザテーブルを参照して、図１１のステップＳ５００９等で決定された次の配送対象ユーザＩＤに対応するユーザの「委任先ＩＤ」項目，「複数委任」項目の値を取得する。

次に、ステップ（１１００２）において、ワークフローサーバ２００のＣＰＵは、複数委任の値が「１」か否かを判定し、複数委任の値が「１」でないと判定した場合には、ステップ（１１０１０）において、「委任ＩＤ」に指定されている委任先ユーザを、次の配送対象ユーザＩＤに決定し、処理を終了する（図１１のフローチャートの処理に戻る）。

一方、ステップ（１１００２）で、ワークフローサーバ２００のＣＰＵが、複数委任の値が「１」であると判定した場合には、ステップ（１１００３）において、「委任ＩＤ」の値が複数存在するか否かを判定し、複数存在しないと判定した場合には、ステップ（１１０１０）に進み、「委任ＩＤ」に指定されている委任先ユーザを、次の配送対象ユーザＩＤに決定し、処理を終了する（図１１のフローチャートの処理に戻る）。

一方、ステップ（１１００３）で、ワークフローサーバ２００のＣＰＵが、「委任ＩＤ」の値が複数存在すると判定した場合には、ステップ（１１００４）において、ワークフローサーバ２００のＣＰＵは、図１０に示したような配送情報テーブルのノード番号「０」のレコードの「処理ユーザ」項目の値を、起票者のユーザＩＤとして取得し、該起票者のユーザＩＤをキーとして図８に示した役職テーブルを検索して、起票者の組織ＩＤを取得する。

次に、ステップ（１１００５）において、ワークフローサーバ２００のＣＰＵは、ステップ（１１００１）で取得した委任先ＩＤから１つの委任先ＩＤを取り出し、ステップ（１１００６）において、ステップ（１１００５）で取り出した委任先ＩＤをキーとして、図８に示した役職テーブルを検索して、該委任先ＩＤの組織ＩＤを代行依頼先の組織ＩＤとして取得する。

次に、ワークフローサーバ２００のＣＰＵは、ステップ（１１００４）で取得した起票者の組織が、ステップ（１１００６）で取得した依頼先の組織の下の組織であるか否かを判定する。この判定は、起票者の組織ＩＤが依頼先の組織ＩＤを含む（網羅している）場合には、起票者の組織が依頼先の組織の下の組織であると判断し、一方、起票者の組織ＩＤが依頼先の組織ＩＤを含まない（網羅していない）場合には、起票者の組織が依頼先の組織の下の組織でないと判断する。

ステップ（１１００７）で、ワークフローサーバ２００のＣＰＵが、起票者の組織が依頼先の組織の下の組織でないと判定した場合には、ステップ（１１００９）において、ステップ（１１００５）で取得した委任先ＩＤのユーザは次承認者にならないと判定し、ステップＳ１１０１１に進む。

次に、ステップ（１１０１１）において、ワークフローサーバ２００のＣＰＵは、ステップ（１１０１）で取得した委任先ＩＤのうち未処理の委任先ＩＤが残っているか否かを判定し、まだ残っていると判定した場合には、ステップ（１１０５）の処理に戻り、次の委任先ＩＤに対しての処理を行う。

一方、ステップ（１１０１１）で、ワークフローサーバ２００のＣＰＵが、スステップ（１１０１）で取得した委任先ＩＤのうち未処理の委任先ＩＤがのこっていないと判定した場合には、委任先ＩＤが未決定のまま処理を終了する（図１１のフローチャートの処理に戻る）。なお、図１１のフローチャートの処理に戻ると、再度、ステップ（５０１０）に処理が移行されることとなるが、上記委任先ＩＤが未決定の場合、ステップ（５０１０）で、委任先ＩＤなしと判定するものとする。

一方、ステップ（１１００７）で、ワークフローサーバ２００のＣＰＵが、起票者の組織が依頼先の組織の下の組織であると判定した場合には、ステップ（１１００８）において、ステップ（１１００５）で取得した委任先ＩＤのユーザを次の承認者に決定し、処理を終了する（図１１のフローチャートの処理に戻る）。

以上の処理により、本発明の特徴的構成である図１４に示した委任配送を実現することができる。

以上説明したように、本実施形態では、該ワークフローシステム上のユーザに対して、ユーザごとに代行者を複数設定可能なユーザ管理テーブルを設け、電子文書を配布する際、ワークフローサーバは配布先候補として指定した上記テーブルから代行設定の情報を参照することにより、当該ユーザへ電子文書を送付するか否かを決定する。

そして、承認または決裁者が代行を下位組織の役職者に設定した場合は、上記複数設定から、起票者の上位組織の代行者を、代行依頼先として決定する。これにより、各役職者に配布された電子文書は、次承認者の代行として起票者の上位組織の役職者が再度、承認を行い、さらに次の承認者へ配布されることになる。

以上の構成により、下位組織に属する複数のユーザに代行委任しておき、電子文書を配布する際、不在担当者（代行依頼者）に送付される電子文書（業務案件）を、業務の流れ、即ち組織に従って決定し、配送するので、代行委任設定されたユーザといえども、配送ルートにない組織のユーザには承認・決裁業務を代行させない（即ち、配送ルートにある組織のユーザに承認・決裁業務を代行させる）というような業務の流れに従った自然な代行委任処理を可能とする。

従って、代行設定において、下位組織の複数承認者への代行委任設定がなされた場合、配送電子文書は、次承認者の代行として既配送ルート上の委任設定された代行者が再度、承認を行い、さらに次の承認者へ配送することができ、電子文書（業務案件）ごとに、配送ルートに沿った、フレキシブルなワークフローシステムを構築することができる等の効果を奏する。

本実施形態では、ワークフロー操作用端末３００は、ブラウザアプリケーションでのＨＴＭＬファイルの表示を行い、クライアントからはイベントをワークフローサーバ２００に送信することで、ワークフローサーバ側はサーブレット（ＣＧＩ等でも可）を用いて処理を行う構成について説明したが、ワークフロー操作用端末３００にクライアント用のワークフロープログラムをインストールし、ワークフロー操作用端末３００で実行させるように構成してもよい。

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

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

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

以上説明したように、本実施形態によれば、クライアント・サーバシステムで構成されるワークフローシステムにおいて、ワークフローサーバ２００は、登録される複数のユーザ情報（ユーザＩＤ），前記各ユーザ情報に紐付けられた役割情報（役割ＩＤ），前記各ユーザ情報に紐付けられた所属情報（組織ＩＤ），前記各所属情報の階層構造を示す階層情報（組織テーブル），電子文書の配送経路を前記役割情報により定義した経路情報（配送定義情報）と、前記各ユーザ情報に紐付けて前記各ユーザ情報の委任先として設定される１又は複数の委任先ユーザ情報（委任先ＩＤ）とを記憶可能な記憶手段（ＲＤＢＭＳ２０５）と、電子文書の回覧を制御するワークフローサーバ２００のＣＰＵが、クライアント（ワークフロー操作用端末３００）からの電子文書処理要求（図１１のステップ（５０００））に応じて、該電子文書に対して役割情報で定義された経路情報に基づいて該電子文書の次配送先となるユーザ情報を決定する（図１１のステップ（５００１）〜（５００９））とともに、該決定された配送先となるユーザ情報に対して委任先ユーザ情報が設定されている場合には、前記配送先を該委任先ユーザ情報に変更決定するものであり（図１１のステップ（５０１０），図１７）、特に、前記決定された配送先となるユーザ情報に対して複数の委任先ユーザ情報が設定されている場合には、該複数の委任先ユーザ情報のうち、前記電子文書の起案者となるユーザ情報に紐付けられた所属情報の上層の所属情報に紐付けられた委任先ユーザ情報を、前記該電子文書の次配送先となるユーザ情報として決定する（図１７のステップＳ１１０４）〜（１１０８））ように制御するので、下位組織に属する複数のユーザに代行委任しておくとことにより、不在担当者（代行依頼者）に送付される電子文書（業務案件）を、業務の流れ、即ち組織に従って配送し、代行委任設定されたユーザといえども、配送ルートにない組織のユーザには承認・決裁業務を代行させない（即ち、配送ルートにある組織のユーザに承認・決裁業務を代行させる）というような業務の流れに従った自然な代行委任処理を可能とする。

従って、電子文書（業務案件）ごとに、配送ルートに沿った、フレキシブルなワークフローシステムを構築することができる等の効果を奏する。

以下、図１８に示すメモリマップを参照して本発明に係るワークフローサーバで読み取り可能なデータ処理プログラムの構成について説明する。

図１８は、本発明に係るワークフローサーバで読み取り（読み出し）可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。

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

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

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

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

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

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

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

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

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

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

本実施形態が適用されるワークフローシステムの概略構成を示す図である。 図１に示したワークフローサーバ，ワークフロー操作用端末，ワークフロー及び伝票設計用端末に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。 図１に示したワークフローシステムにおける伝票の流れを示す模式図である。 本実施形態のワークフローシステムにおける説明に用いる組織の階層構造の一例を示す組織図である。 図１に示したワークフローサーバのＲＤＢＭＳに記憶される組織テーブルのデータ構造の一例を示すデータ構成図である。 図１に示したワークフローサーバのＲＤＢＭＳに記憶される役割テーブルのデータ構造の一例を示すデータ構成図である。 図１に示したワークフローサーバのＲＤＢＭＳに記憶されるユーザテーブルのデータ構造の一例を示すデータ構成図である。 図１に示したワークフローサーバのＲＤＢＭＳに記憶される役職テーブルのデータ構造の一例を示すデータ構成図である。 図１に示したワークフローサーバのＲＤＢＭＳに記憶される配送定義情報のデータ構造の一例を示すデータ構成図である。 図１に示したワークフローサーバのＲＤＢＭＳに記憶される配送情報テーブルのデータ構造の一例を示すデータ構成図である。 本発明のワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートである。 本発明の代行設定を説明するための配送ルートを示した模式図である。 本発明の代行設定を説明するための配送ルートを示した模式図である。 本発明の代行設定を説明するための配送ルートを示した模式図である。 本発明のワークフローシステムにおける代行設定画面の一例を示す模式図である。 本発明のワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。 本発明のワークフローシステムにおける第３の制御処理手順の一例を示すフローチャートである。 本発明に係るワークフローサーバで読み取り（読み出し）可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。

符号の説明

２００ ワークフローサーバ
３００ ワークフロー操作用端末
４００ ワークフロー及び伝票設計用端末
５００ ネットワーク

Claims (5)

1. クライアント・サーバシステムで構成されるワークフローシステムにおいて電子文書の回覧を制御するワークフローサーバであって、
   登録される複数のユーザ情報、前記各ユーザ情報に紐付けられた役割情報、前記各ユーザ情報に紐付けられた所属情報、前記各所属情報と上位の所属情報とを階層的に紐付けた階層情報、電子文書の配送経路を前記役割情報により定義した経路情報、及び、前記各ユーザ情報に紐付けて前記各ユーザ情報の委任先として設定される１又は複数の委任先ユーザ情報を記憶可能な記憶手段と、
   クライアントからの電子文書処理要求に応じて、該電子文書に対して役割情報で定義された経路情報に基づいて該電子文書の次配送先となるユーザ情報を決定するとともに、該決定された配送先となるユーザ情報に紐付けられて委任先ユーザ情報が前記記憶手段に記憶されている場合には、前記配送先を該委任先ユーザ情報に変更決定する配送先決定手段と、
   前記電子文書の起案者のユーザ情報を含む電子文書の配送情報を記憶する配送情報記憶手段と、
   前記配送情報記憶手段に記憶された前記起案者のユーザ情報から、前記記憶手段に記憶された該起案者のユーザ情報に紐付けられた所属情報を取得する取得手段とを有し、
   前記配送先決定手段は、前記決定された配送先のユーザ情報に紐付けられた複数の委任先ユーザ情報が前記記憶手段に記憶されている場合には、該複数の委任先ユーザ情報のうち、前記階層情報により前記取得手段で取得された起案者の所属情報の上位の所属情報に紐付けられた委任先ユーザ情報を、前記電子文書の次配送先となるユーザ情報として決定することを特徴とするワークフローサーバ。
2. クライアントからの要求に応じて、前記委任先ユーザ情報を前記いずれかのユーザ情報に紐付けて前記記憶手段に記憶させる設定手段を設け、
   前記設定手段は、前記いずれかのユーザ情報を委任元ユーザ情報として、前記階層情報により該委任元ユーザ情報の所属情報が上位の所属情報として紐付けられている所属情報に紐付けられているユーザ情報に対応する下位ユーザ情報への、代行委任設定が要求された場合にのみ、複数の下位ユーザ情報を委任先ユーザ情報として設定することを許可することを特徴とする請求項１記載のワークフローサーバ。
3. クライアント・サーバシステムで構成されるワークフローシステムにおいて、登録される複数のユーザ情報、前記各ユーザ情報に紐付けられた役割情報、前記各ユーザ情報に紐付けられた所属情報、前記各所属情報と上位の所属情報とを階層的に紐付けた階層情報、電子文書の配送経路を前記役割情報により定義した経路情報、及び、前記各ユーザ情報に紐付けて前記各ユーザ情報の委任先として設定される１又は複数の委任先ユーザ情報を記憶可能な記憶手段と、前記電子文書の起案者のユーザ情報を含む電子文書の配送情報を記憶する配送情報記憶手段とを有し、電子文書の回覧を制御するワークフローサーバにおけるワークフロー制御方法であって、
   前記ワークフローサーバが、
   クライアントからの電子文書処理要求に応じて、該電子文書に対して役割情報で定義された経路情報に基づいて該電子文書の次配送先となるユーザ情報を決定する第１の決定ステップと、
   前記第１の決定ステップで決定された配送先となるユーザ情報に対して委任先ユーザ情報が前記記憶手段に記憶されている場合には、前記配送先を該委任先ユーザ情報に変更決定する第２の決定ステップとを実行し、
   前記第２の決定ステップは、前記第１の決定ステップで決定された配送先のユーザ情報に紐付けられた複数の委任先ユーザ情報が前記記憶手段に記憶されている場合には、前記配送情報記憶手段に記憶された前記起案者のユーザ情報から、前記記憶手段に記憶された該起案者のユーザ情報に紐付けられた所属情報を取得し、該複数の委任先ユーザ情報のうち、前記階層情報により前記取得した起案者の所属情報の上位の所属情報に紐付けられた委任先ユーザ情報を、前記電子文書の次配送先となるユーザ情報として決定することを特徴とするワークフロー制御方法。
4. 請求項３に記載されたワークフロー制御方法をコンピュータに実行させるためのプログラム。
5. 請求項３に記載されたワークフロー制御方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images