JP2005284765A - ワークフロー制御システムおよびワークフロー制御プログラム - Google Patents

Abstract

【課題】 種々のワークフローを表現し、文書の流れやその状態を正確に把握しかつ制御する。
【解決手段】 制御サーバ１０のフロー進行処理部２２は、回議者を特定して、回議情報テーブル、権限テーブルを参照して、関連する権限タイプコードを特定するとともに、前記ステータステーブルを参照して、文書のステータスタイプコードを特定する。さらに、フロー進行処理部２２は、権限タイプコードおよびステータスタイプコードにより、文書に対して回議者が実行可能な操作を特定し、回議者からの実行可能な操作から選択された何れかにしたがって、文書のステータスを変更し、回議順連結テーブルを参照して、次の回議者を特定する。
【選択図】 図１

Description

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

会社内などで、申請書を電子的に回覧させて決済するための種々のワークフローシステムが提案されている。たとえば、特許文献１には、決済文書を、設定された稟議ルートにしたがって、文書提出者から第１承認者、第２承認者、・・・という順に送っていく直列型稟議シーケンスや、複数の同報回覧者による承認がそろった時点で、最終的な回覧者に文書が送られて最終的に承認が確定する並列型稟議シーケンスを備えたワークフローシステムが開示されている。
特開２００２−２４４９９号公報（図４、図８） 特開平９−１９８３２６号公報

稟議ルートなど、文書の回覧ルートが確定しており、変更の必要を要さない場合には、上述したようなワークフロー制御システムは適切に機能する。しかしながら、回覧ルート上にある意思決定を行う者以外が、ワークフロー上に存在する場合も考えられる。たとえば、文書を閲覧するが、承認などの意思決定を行わない者や、回覧ルート外にある相談や照会を受けた者などである。また、文書の作成自体を、文書提出者以外のものが、文書を作成する場合もある。

たとえば、特許文献２には、文書の回覧途中に作業者（たとえば承認者）が処理についての疑問を感じ、或いは、不都合な点を見出したときに、その文書の照会先を自動的に作業者に通知することができるワークフロー制御システムが提案されている。

しかしながら、特許文献２に開示された技術においても、ワークフロー自体が変更されるものではなく、ある作業者による他の者への照会はワークフロー外で生じたことになり、ワークフロー制御システムが、照会の事実などを把握するのが困難であるという問題点があった。

特に、照会、連絡、相談など、規定された回議順だけでなく、決裁権を持たないが報告が必要な者が存在するケースが多種存在する。このような者がワークフロー上に存在しないことになると、別途、これらの者を管理する必要が生じ、ワークフロー制御システムを導入するメリットが損なわれる。また、上記照会、連絡、相談のほか、申請前の文書作成、決裁後の手続きなども、文書が回覧されたことを示す履歴が残せることが望ましい。

本発明は、種々のワークフローを表現でき、文書の流れやその状態を正確に把握しかつ制御することができるワークフロー制御システムおよびプログラムを提供することを目的とする。また、本発明の目的は、複雑な手順を経ることなくワークフロー自体を変更することが可能なワークフロー制御システムおよびワークフロー制御プログラムを提供することを目的とする。

本発明の目的は、回議者の権限およびその権限タイプを示す権限タイプコードを含むレコードを格納した権限定義テーブルと、文書のステータスおよびそのステータスタイプを示すステータスタイプコードを含むレコードを格納したステータス定義テーブルと、前記権限タイプコードおよびステータスタイプコードに応じて回議者が実行可能な操作を関連付けたレコードを含むアクション定義テーブルと、文書フローにおいて使用可能な権限タイプコード、および、その権限タイプコードを特定する情報を含むレコードを格納した権限テーブルと、文書フローにおいて生じ得るステータスタイプコードを含む情報を含むレコードを格納したステータステーブルと、特定の回議者名、回議順を特定する回議順ＩＤ、前記権限タイプコードを特定する情報を含む回議情報テーブルと、前記隣接する回議順ＩＤの先後を示す情報を含むレコードを格納した回議順連結テーブルと、回議者を特定して、前記回議情報テーブル、権限テーブルを参照して、関連する権限タイプコードを特定し、かつ、前記ステータステーブルを参照して、文書のステータスタイプコードを特定し、さらに、前記権限タイプコードおよびステータスタイプコードにより、当該文書に対して回議者が実行可能な操作を特定して、回議者からの前記実行可能な操作から選択された何れかにしたがって、前記文書のステータスを変更するとともに、回議順連結テーブルを参照して、次の回議者を特定するフロー進行処理手段とを備えたことを特徴とするワークフロー制御システムにより達成される。

好ましい実施態様においては、ユーザの指定にしたがって、所望の回議順或いは隣接する回議順の間に、所定の権限をもつ回議者を追加するために、回議者、回議順ＩＤおよび権限タイプコードを特定する情報を含むレコードを、前記回議情報テーブル中の所定の位置に挿入するとともに、必要に応じて、前記回議順連結テーブルのレコードを挿入およびレコードの値を更新するフロー更新手段を備える。これにより、回議者などが、ワークフロー自体を変更することが可能となる。

より好ましい実施態様においては、前記フロー更新手段が、前記権限テーブルを参照して、追加可能な回議者の権限を示す情報を提示し、前記追加可能な権限を示す情報から選択させる。

別の好ましい実施態様においては、前記回議情報テーブルのレコードが、同回議順内での順序を示す値を含み、前記フロー更新手段が、同回議順に回議者が追加される場合に、新たなレコード中、回議順内での順序示す値として、既に存在する同回議順のレコードと異なる値を採番する。これにより、同回議順に、複数の回議者が存在するワークフローを実現することができる。

また、さらに別の好ましい実施態様においては、前記フロー更新手段が、既に存在する隣接する回議順の間に新たな回議順の回議者を追加する場合に、既存の隣接する回議順ＩＤの間に、新たな回議順ＩＤが挿入されるように、前記回議順連結テーブルのレコードを更新する。

別の好ましい実施態様においては、さらに、前記権限テーブルおよびステータステーブルを更新するテーブル更新手段を備える。たとえば、テーブル更新手段による権限テーブルおよびステータステーブルの更新は、システムの管理者のみが行えるようにすればよい。

たとえば、前記権限タイプコードが、少なくとも、申請、承認、決裁、相談、および、連絡にそれぞれ対応する値を含む。

また、本発明の目的は、回議者の権限およびその権限タイプを示す権限タイプコードを含むレコードを格納した権限定義テーブルと、文書のステータスおよびそのステータスタイプを示すステータスタイプコードを含むレコードを格納したステータス定義テーブルと、前記権限タイプコードおよびステータスタイプコードに応じて回議者が実行可能な操作を関連付けたレコードを含むアクション定義テーブルと、文書フローにおいて使用可能な権限タイプコード、および、その権限タイプコードを特定する情報を含むレコードを格納した権限テーブルと、文書フローにおいて生じ得るステータスタイプコードを含む情報を含むレコードを格納したステータステーブルと、特定の回議者名、回議順を特定する回議順ＩＤ、前記権限タイプコードを特定する情報を含む回議情報テーブルと、前記隣接する回議順ＩＤの先後を示す情報を含むレコードを格納した回議順連結テーブルとを備えたコンピュータにより読み出し可能なワークフロー制御プログラムであって、回議者を特定して、前記回議情報テーブル、権限テーブルを参照して、関連する権限タイプコードを特定するステップと、前記ステータステーブルを参照して、文書のステータスタイプコードを特定するステップと、前記権限タイプコードおよびステータスタイプコードにより、当該文書に対して回議者が実行可能な操作を特定するステップと、前記回議者からの前記実行可能な操作から選択された何れかにしたがって、前記文書のステータスを変更するとともに、回議順連結テーブルを参照して、次の回議者を特定するステップとを、前記コンピュータに実行させることを特徴とするワークフロー制御プログラムによっても達成される。

好ましい実施態様においては、ユーザの指定にしたがって、所望の回議順或いは隣接する回議順の間に、所定の権限をもつ回議者を追加するために、回議者、回議順ＩＤおよび権限タイプコードを特定する情報を含むレコードを、前記回議情報テーブル中の所定の位置に挿入し、必要に応じて、前記回議順連結テーブルのレコードを挿入およびレコードの値を更新するフロー更新ステップを、前記コンピュータに実行させる。

より好ましい実施態様においては、前記フロー更新ステップにおいて、前記権限テーブルを参照して、追加可能な回議者の権限を示す情報を提示し、前記追加可能な権限を示す情報から選択させるステップを、前記コンピュータに実行させる。

別の好ましい実施態様においては、前記回議情報テーブルのレコードが、同回議順内での順序を示す値を含み、前記フロー更新手段ステップにおいて、同回議順に回議者が追加される場合に、新たなレコード中、回議順内での順序示す値として、既に存在する同回議順のレコードと異なる値を採番するステップを、前記コンピュータに実行させる。

さらに別の好ましい実施態様においては、前記フロー更新ステップにおいて、既に存在する隣接する回議順の間に新たな回議順の回議者を追加する場合に、既存の隣接する回議順ＩＤの間に、新たな回議順ＩＤが挿入されるように、前記回議順連結テーブルのレコードを更新するステップを、前記コンピュータに実行させる。

また、好ましい実施態様においては、さらに、前記権限テーブルおよびステータステーブルを更新するテーブル更新ステップを、前記コンピュータに実行させる。

本発明によれば、種々のワークフローを表現でき、文書の流れやその状態を正確に把握しかつ制御することができるワークフロー制御システムおよびプログラムを提供することが可能となる。また、本発明の目的によれば、複雑な手順を経ることなくワークフロー自体を変更することが可能なワークフロー制御システムおよびワークフロー制御プログラムを提供することが可能となる。

以下、添付図面を参照して、本発明の実施の形態について説明する。図１は、本発明の実施の形態にかかるワークフロー制御サーバを含む全体構成を示すブロックダイヤグラムである。図１に示すように、ワークフロー制御サーバ（以下、単に「制御サーバ」とも称する。）１０には、ＬＡＮ、ＷＡＮなどのネットワーク１２を介して、クライアント１３−１、１３−２、・・・が接続できるようになっている。本実施の形態においては、制御サーバ１０を、企業の社員の、承認が必要な文書の回覧に利用している。クライアント１３のそれぞれは、社員が使用し、ネットワーク１２を介して、制御サーバ１０にアクセスし、文書を受け取って、文書の所定の項目への記入や承認など、文書に必要な処理を施すことができるようになっている。

図１に示すように、制御サーバ１０は、後述する権限定義テーブル１０１、ステータス定義テーブル１０２、アクション定義テーブル１０３などを記憶した定義情報ＤＢ１４と、文書種別ごとにワークフローに関して、権限に関する情報を含む権限テーブル１１０、および、当該文書のワークフローに関して、そのステータスに関する情報を含むステータステーブル１１１、各文書のデータおよび現在のステータスを含む文書テーブル１１２、および、文書ごとの回議者の情報を含む回議情報テーブル１１３、および、文書ごとの回議順を示す情報を含む回議順連結テーブル１１４を記憶する文書情報ＤＢ１６とを有する。文書情報ＤＢ１６は、上記テーブルのほか、実際に回議された文書およびその文書の履歴を記憶することも可能である。

また、ワークフロー制御サーバ１０は、クライアント１３からの指示にしたがって、各種テーブルを生成し、また、指示に基づくレコードの追加等を実行するテーブル管理部２０と、テーブルの情報にもとづいて実際に文書のステータスを変更してフローを進行させるフロー進行処理部２２と、クライアント１３の表示装置の画面上に表示すべき画像を生成し、また、クライアント１３からの指示を受信するインタフェース（Ｉ／Ｆ）２４とを有している。

本実施の形態にかかる制御サーバ１０において、権限定義テーブル１０１、ステータス定義テーブル１０２およびアクション定義テーブル１０３は、予め作成され、定義情報ＤＢ１４に記憶される。図２（ａ）は、権限定義テーブル１０１の例を示す図、図２（ｂ）は、ステータス定義テーブル１０２の例を示す図である。

図２（ａ）に示すように、権限定義テーブル１０１は、項目として、「ＩＤ」、「権限タイプ」および「状態」を含む。「権限タイプ」は、ある値をとり、その値が表わす状態が、項目「状態」に記述されている。権限定義テーブル１０１の項目の値の組は、それぞれ、ワークフローの文書にかかわる社員など回議者の権限を示す。たとえば、「権限タイプ＝０」は、「状態＝申請」であることを示し、「権限タイプ＝２」は、「状態＝承認」であることを示す。

また、図２（ｂ）に示すように、ステータス定義テーブル１０２は、項目として、「ＩＤ」、「ステータスタイプ」および「状態」を含む。ステータス定義テーブル１０２の項目の値の組は、それぞれ、文書のステータスを示す。たとえば、「スタータスタイプ＝２」は、「状態＝申請中（申請文書回覧状態）」を示し、また、「ステータスタイプ＝４」は、「状態＝決済済み状態」を示す。

また、図３に示すように、アクション定義テーブル１０３は、項目として、「権限タイプコード」、「ステータスタイプコード」および「実行可能な操作」を含む。すなわち、回議者の権限および文書のステータスにより、当該回議者が文書について、どのような操作をなすことができるかを特定することができる。たとえば、「権限タイプコード（図３においては、「権限タイプ」と記載している。）＝０」で、「ステータスタイプコード（図３においては、「ステータスタイプ」と記載している）＝２」であれば、その権限タイプコードを有する回議者は、文書を「申請」或いは「保存」できることを示している。また、「権限タイプコード＝２」で、「ステータスコード＝２」であれば、その権限タイプコードを有する回議者が、文書を「承認」または「差戻し」できることを示している。

このように構成されたシステムにおいて実行される処理について説明する。図４（ａ）は、ある文書の申請から、承認および決済までの単純なワークフローの例を示す図である。この例では、社員Ａが、申請した文書を、社員Ｂが承認し、最終的に、社員Ｃが決裁する流れとなっている。このような流れを保持するために、本実施の形態においては、このような回議順を定義するために、権限テーブル１１０、ステータステーブル１１１および回議情報テーブル１１３が利用される。なお、図４（ａ）において、符号４０１、４０２、４０３は、それぞれ、別個の回議順にあるという。また、申請の回議順（符号４０１）においては、社員Ａが「申請」という「権限」と有することを意味している。ここに、左下の数字は、対応する権限タイプコードを示す。符号４０２、４０３においても同様である。

図４（ｂ）は、図４（ａ）に示すフローの権限を記述した権限テーブル、図４（ｃ）は、文書のステータスを記述したステータステーブルである。これら権限テーブルおよびステータステーブルは、文書フローを作成することができる権限を有する者（以下、「管理者」と称する）が作成、変更することができる。

図４（ｂ）に示すように、権限テーブルのレコードは、項目として、「権限タイプコード」、「権限」および「権限名称」を有する。「権限タイプコード」は、権限定義テーブル１００の「権限タイプコード」に相当する。「権限」は、後述するようにテーブルのキーとして利用される一種のＩＤとして機能する。また、「権限名称」は、「権限」と関連付けて、管理者が、任意に付与することができる。

図４（ｃ）に示すように、ステータステーブルのレコードは、項目として、「ステータスコード」、「ステータスタイプコード」および「ステータス名称」を有する。「ステータスコード」はレコードに対して一意的に付されるものである。「ステータスタイプコード」は、ステータス定義テーブル１０１の「ステータスタイプコード」に相当する。また、「ステータス名称」は管理者が任意に付すことができる。たとえば、図４（ａ）において「社員Ａ」が書類を申請した状態、および、「社員Ｂ」が書類を承認した状態において、その「ステータスコード」は、「２：申請中」であることに変わりはない。そこで、管理者は、前者を「申請中」、後者を「決裁待ち」とすればよい。

図５（ａ）は、実際の回議順を定義した回議情報テーブルの例を示す図、図５（ｂ）は、回議順を定義した回議順連結テーブルの例を示す図である。図５（ａ）に示すように、回議情報テーブルのレコードは、項目として、「回議ＩＤ」、「回議順ＩＤ」、「回議順通し番号」、「回議者社員」および「権限」とを有する。この回議情報テーブルは、テーブルに記述された社員に文書を回議するために利用される。したがって、回議される文書ごとにこのテーブルは作成される。「回議ＩＤ」は、回議される文書ごとに一意的に付与される。「回議順ＩＤ」は、ワークフローにおいて文書が回覧される回議順を特定するためのものであり、同一の回議順に複数の者が存在する場合には、同じ値が与えられる。「回議順通し番号」」は、同一の回議順の回議者を区別するための値である。

「回議者」は、実際に文書が回議される社員が順に記述される。図５（ａ）の例では、図４（ａ）にしたがって、「社員Ａ」、「社員Ｂ」、「社員Ｃ」の順に、各レコードに値が格納される。また、「権限」は図４（ｂ）に示す権限テーブルのレコードにおける「権限」に相当する。図５（ａ）に示す回議情報テーブルは、申請者など管理者以外の社員（以下、管理者と区別するため「ユーザ」とも称する）が、作成、変更が可能である。

図５（ｂ）に示すように、回議順連結テーブルのレコードは、項目として、「回議ＩＤ」、「開始回議順ＩＤ」および「終了回議順ＩＤ」を有する。「開始回議順ＩＤ」および「終了回議順ＩＤ」の組により、どの社員からどの社員に文書が回議されるかを定義することができる。この回議順連結テーブルも、ユーザが作成、変更可能である。

本実施の形態では、管理者が、文書の種別ごとに、権限定義テーブルおよびステータス定義テーブルを参照して、権限テーブルおよびステータス定義テーブルを作成し、ユーザは、実際に回議する文書ごとに、回議情報テーブルおよび回議順連結テーブルを作成しておく。以下、図４（ａ）の例にしたがった文書の回議について説明する。

図６に示すように、「社員Ａ」がクライアント（たとえば、クライアント１３−１とする）を操作して、制御サーバ１０にアクセスして、申請すべき文書を受信する（ステップ６００）。なお、制御サーバ１０は、ステータステーブルを参照して、先頭のレコードにある「ステータスタイプコード＝１：申請前」を文書に付与する（ステップ６０１）。ステータスタイプコードは、実際に文書の一部に付与しても良いし、別途、制御サーバ１０が、回議ＩＤと関連付けてステータスタイプコードを記憶するように構成しても良い。

なお、制御サーバ１０は、回議情報テーブル（図５（ａ））を参照して、テーブル中のレコードを特定し、アクセスした者の「権限」を特定する（ステップ６０２）。この例では、回議情報テーブルにおいて、「申請者Ａ」の「権限＝Ａ００１」であり、これは、権限テーブルを見ると、「権限タイプコード＝０」であることがわかる。また、文書のステータスは、「ステータスタイプコード＝１：申請前」である。そこで、制御サーバ１０は、アクション定義テーブルを参照して、特定された権限タイプコードおよびステータスコードにより、実行可能な操作を特定する（ステップ６０３）。この例では、「権限タイプコード＝０」かつ「ステータスタイプコード＝１」であるため、実行可能な操作は、「申請」或いは「保存」となる。したがって、制御サーバ１０は、クライアント１３−１の表示装置の画面中に、可能な操作として、「申請」ボタンおよび「保存」ボタンを表示すればよい。

「社員Ａ」は、クライアント１３−１の表示装置の画面上に表示された文書を参照して、必要な事項を記入する（ステップ６０４）。記入後に、「社員Ａ」は、入力装置を操作して、所定の操作をする。この例では、可能な操作は、「申請」或いは「保存」であり、「社員Ａ」は、何れかのボタンをオンする。たとえば「申請」ボタンがオンされると、制御サーバ１０は、必要事項が記入された文書を、実行された操作とともに受信する（ステップ６０５）。

実行された操作が「申請」であれば、制御サーバ１０は、回議順連結テーブルを参照して、次の回議順に相当する社員（この場合、「社員Ｂ」）を特定する（ステップ６０６）。また、制御サーバ１０は、ステータステーブルのレコードを参照して、文書のステータスタイプコードを、「１：申請前」から「２：申請中」に変更する（ステップ６０７）。また、制御サーバ１０は、次の回議順に相当する社員に対して、制御サーバ１０へのアクセスを求めるメールを送信する（ステップ６０８）。

図７（ａ）に示すように、次の回議順に相当する「社員Ｂ」が、クライアント（たとえば、１３−２）を操作して、文書の取得を要求すると、制御サーバ１０は、「ステータスタイプコード＝２」が付与された文書をクライアント１３−２に送信する（ステップ７０１）。ここで、回議情報テーブルを参照すると、「社員Ｂ」は、「権限＝０２１」であり、これは、権限テーブルによれば、「権限タイプコード＝２：承認」である。また、文書について、「ステータスタイプコード＝２」であるため、「社員Ｂ」の実行可能な操作は、「承認」或いは「差戻し」である。

「社員Ｂ」が、クライアント１３−２を操作して、「承認」ボタンをオンした場合には（ステップ７０２）、文書および実行された操作（承認）が制御サーバ１０に送信される（ステップ７０３）。制御サーバ１０は、回議順連結テーブルを参照して、次の回議順に相当する社員（この場合、「社員Ｃ」を特定し（ステップ７０４）、当該「社員Ｃ」に対して、制御サーバ１０へのアクセスを求めるメールを送信する（ステップ７０５）。また、ステータステーブルを参照すると、次のレコードにおいて、「ステータス名称＝決裁待ち」であるが、「ステータスコード＝２」で変化はない。「社員Ｃ」のクライアントのアクセスから生じる処理は、図６および図７の処理とほぼ同様である。

その一方、図７（ｂ）に示すように、「社員Ｂ」がクライアント１３−２を操作して、「差戻し」ボタンをオンした場合には（ステップ７１１）、文書および実行された操作（差戻し）が制御サーバ１０に送信される（ステップ７１２）。制御サーバ１０は、回議順連結テーブルを参照して、元の社員（この場合、「社員Ａ」）に文書を戻す（ステップ７１３）。

このように、本実施の形態では、回議情報テーブルからアクセスした者の「権限」を特定し、かつ、その「権限」から特定される「権限タイプコード」と、文書の「ステータスタイプコード」とから、その者が実行可能な操作を特定することができる。したがって、以下のように、テーブルを変更することで、多種多様な回議を定義することが可能となる。

ワークフローは、図４（ａ）に示すように単純なものとは限らない。最終的な決裁に至るまでに、複数の承認者が順次承認すべき場合もあるし、同時に、複数の者の承認を要する場合もありえる。また、承認の際などに、アドバイザーに相談を求めた上で承認或いは差戻しを決定する場合もあり得る。本実施の形態においては、このように多種多様なワークフローを、管理者が権限テーブルやステータステーブルを作成或いは変更することにより、比較的簡単な操作で実現できる。管理者は、権限テーブルおよびステータステーブルを作成、変更することで、所望のワークフローを定義することができる。その一方、ユーザは、権限テーブルやステータステーブルを作成、更新することはできず、これらに定義された範囲で、回議情報テーブルや回議順連結テーブルを変更することで、ワークフローを変更することができる。

たとえば、図８（ａ）に示すように、「申請者Ａ」が申請し、「承認者Ｂ」が承認した上で、「決裁者Ｃ」が決裁するようなワークフローが存在すると考える。ここで、「申請者Ａ」は、図８（ｂ）に示すように、同回議順で、「承認者Ｂ」および「承認者Ｂ’」の得た上で「決裁者Ｃ」の決裁を受けるようなワークフローに変更したいと考える。ここで、権限テーブルは、図９に示すように、「申請」、「承認」、「決裁」および「相談」が定義されていると考える。

ユーザ（たとえば、この場合には「申請者Ａ」）は、回議情報テーブルを変更することで、同回議順に複数の承認者が承認するようなフローを作ることができる。図１０（ａ）は、図８（ａ）のワークフローに関する回議情報テーブル、図１０（ｂ）は、当該ワークフローに関する回議順連結テーブルを示す図である。この場合には、回議情報テーブルが、図１０（ｃ）に示すように変更されれば良い。図１０（ｃ）においては、「回議順ＩＤ」が、「承認者Ｂ」による承認に関するレコードの「回議順ＩＤ」の値「２」と同じであり、かつ、「回議順通し番号」が、上記レコードの値から「１」を加えられた「２」であるようなレコードが追加される。また、この例では、回議順、「開始回議順ＩＤ＝ＲＰ００１」〜「終了回議順ＩＤ＝ＲＰ００２」および「開始回議順ＩＤ＝ＲＰ００２」〜「終了回議順ＩＤ＝ＲＰ００３」自体には変更がない。つまり、「回議順ＩＤ＝００２」に、複数の承認者が存在するだけである。したがって、回議順連結レコードの変更はない。

このような回議の追加や変更に際するユーザの手順について以下に説明する。本実施の形態においては、クライアントの表示装置の画面の一部（たとえば、下部）に、文書フローを示す画像を表示する。たとえば、図８（ａ）に示す画像が表示された状態で、回議を追加したい位置（回議順）を指定する（ステップ１１０１）。制御サーバ１０は、これに応答して、権限テーブルを参照して、追加され得る「名称」を提示する（ステップ１１０２）。上記例では、「相談」が選択される。ユーザが「名称」を選択すると（ステップ１１０３）、制御サーバ１０は、回議情報テーブル中、レコードを挿入すべき位置を見出して、レコードを挿入する（ステップ１１０４）。また、回議順連結テーブルにレコードを挿入すべき場合には（ステップ１１０５でイエス(Yes)）、制御サーバ１０は、回議順連結テーブル中、指定された回議順の位置にレコードを挿入する（ステップ１１０６）。

ユーザが入力装置を操作して、当該回議者を入力する（ステップ１１０７）。制御サーバ１０は、回議情報テーブルおよび回議順連結テーブルのレコードの値を格納する（ステップ１１０７）。

隣接する回議順の間に、新たに回議順を追加する場合について説明する。図１２（ａ）に示すワークフロー（図８（ａ）と同様である）において、「承認者Ｂ」の承認に先立って、「申請者Ａ」は、「承認者Ｂ’」の承認を得る場合を考える。つまり、「申請人Ａ」の回議順と、「承認者Ｂ」の回議順との間に、新たに回議順が追加されている（図１２（ｂ）参照）。

この場合、図１３（ａ）に示す回議情報テーブルにおいて、「回議順ＩＤ＝４」、「回議順通し番号＝１」、「回議者社員＝社員Ｂ’」、「権限＝Ａ０２１」であるようなレコードが挿入される（図１３（ｃ）参照）。また、回議順連結テーブルにおいては、回議順が、「回議順ＩＤ＝ＲＰ００１」、「回議順ＩＤ＝ＲＰ００４」、「回議順ＩＤ＝ＲＰ００２」および「回議順ＩＤ＝ＲＰ００３」となるように、レコードが追加される（図１３（ｄ）参照）。

次に、被相談者の追加について説明する。被相談者は、相談者（たとえば、申請者や承認者が相談を持ちかける相談者になり得る）と同回議順に追加される。たとえば、図１４（ａ）に示すワークフロー（図８（ａ））において、「承認者Ｂ」が相談者として、「被相談者Ｄ」に相談した上で、承認の是非を決定する場合である（図１４（ｂ）参照））。

この場合のテーブルへのレコードの挿入等は、同回議順に承認者を追加した場合（図８および図１０参照）と同様である。図１５（ｃ）は、「被相談者Ｄ」の追加により、もとの回議情報テーブル（図１５（ａ））からレコードが追加された状態の回議情報テーブルを示す図である。なお、同回議順の追加であるため、回議順連結テーブルは変更されない（図１５（ｂ）参照）。

なお、被相談者がワークフローに挿入された場合にも、本実施の形態にかかる制御サーバ１０においては、回議情報テーブルから、アクセスした者の「権限」（この場合には、Ａ０９０）が特定され、その「権限」から特定される「権限タイプコード（この場合、「２０：相談」）」と、文書の「ステータスタイプコード（この場合、「２：申請中」）」とから、被相談者の実行可能な操作を特定することができる。図３を参照すれば、この場合、被相談者は、文書を「返信」することになる。

また、上記本実施の形態においては、ワークフローにおける回議の追加について説明したが、回議の削除も同様に実現できる。この場合、回議情報テーブルから削除対象となるレコードが削除され、必要な場合には、これに伴って、回議順連結テーブルのレコードの値が変更される。

さらに、本実施の形態においては、文書の申請前の段階、たとえば、「文書代行作成」、「申請前承認」などを含むフローを実現することもできる。この場合には、図２に示す「権限タイプコード」が負の値をとるもの、たとえば、「権限タイプコード＝−４：文書代行作成」や「権限タイプコード＝−２：申請前承認」を含む権限タイプテーブルを作成しておけば、ユーザは、所望のように、申請前の回議者を含むワークフローを作成することができる。図１６は、起案（文書代行作成）をする起案者が存在するようなワークフローの一例を示す。申請前の段階の者（この場合、「起案者ａａａ」）が制御サーバ１０にアクセスして、文書を作成するときには、申請後のワークフローをその者には提示しないのが望ましい。

図１７は、起案者が制御サーバ１０にアクセスした際に、当該起案者が操作するクライアントの表示装置の画面上に表示される文書作成用の画像例を示す図である。図１７に示すように、制御サーバは、ワークフローとして起案者（この場合、「起案者ａａａ」）および申請者（この場合、「申請者ｂｂｂ」）のみを提示した画像を作成して、起案者の操作するクライアントの表示装置の画面上に表示する。これに対して、文書の申請段階においては、制御サーバは、文書の申請前の段階のワークフローは提示せず、申請からのワークフローのみを提示した画像を生成する。図１８は、申請者が制御サーバにアクセスした際に、申請者が操作するクライアントの表示装置の画面上に表示される画像例を示す図である。

本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。

図１は、本発明の実施の形態にかかるワークフロー制御サーバを含む全体構成を示すブロックダイヤグラムである。 図２（ａ）は、本実施の形態にかかる権限定義テーブルの例を示す図、図２（ｂ）は、ステータス定義テーブルの例を示す図である。 図３は、本実施の形態にかかるアクション定義テーブルの例を示す図である。 図４（ａ）は、ある文書の申請から、承認および決済までの単純なワークフローの例、 図４（ｂ）は、図４（ａ）に示すフローの権限を記述した権限テーブルの例、図４（ｃ）は、文書のステータスを記述したステータステーブルの例を示す図である。 図５（ａ）は、実際の回議順を定義した回議情報テーブルの例を示す図、図５（ｂ）は、回議順を定義した回議順連結テーブルの例を示す図である。 図６は、本実施の形態にかかる文書の回議における処理を示すフローチャートである。 図７（ａ）、（ｂ）は、それぞれ、本実施の形態にかかる文書の回議における処理を示すフローチャートである。 図８（ａ）、（ｂ）は、それぞれ、ワークフローの例を示す図である。 図９は、権限テーブルの一例を示す図である。 図１０（ａ）、（ｃ）は、回議情報テーブルの例を示す図、図１０（ｂ）は、回議順連結テーブルの例を示す図である。 図１１は、本実施の形態にかかるワークフロー更新処理の例を示すフローチャートである。 図１２（ａ）、（ｂ）は、それぞれ、ワークフローの例を示す図である。 図１３（ａ）、（ｃ）は、回議情報テーブルの例を示す図、図１０（ｂ）、（ｄ）は、回議順連結テーブルの例を示す図である。 図１４（ａ）、（ｂ）は、それぞれ、ワークフローの例を示す図である。 図１５（ａ）、（ｃ）は、回議情報テーブルの例を示す図、図１５（ｂ）は、回議順連結テーブルの例を示す図である。 図１６は、ワークフローの例を示す図である。 図１７は、本実施の形態において、クライアントの表示装置の画面上に表示される画像例を示す図である。 図１８は、本実施の形態において、クライアントの表示装置の画面上に表示される画像例を示す図である。

符号の説明

１０ ワークフロー制御サーバ
１３ クライアント
１４ 定義情報ＤＢ
１６ 文書情報ＤＢ
２０ テーブル管理部
２２ フロー進行処理部
２４ インタフェース

Claims (13)

1. 回議者の権限およびその権限タイプを示す権限タイプコードを含むレコードを格納した権限定義テーブルと、
   文書のステータスおよびそのステータスタイプを示すステータスタイプコードを含むレコードを格納したステータス定義テーブルと、
   前記権限タイプコードおよびステータスタイプコードに応じて回議者が実行可能な操作を関連付けたレコードを含むアクション定義テーブルと、
   文書フローにおいて使用可能な権限タイプコード、および、その権限タイプコードを特定する情報を含むレコードを格納した権限テーブルと、
   文書フローにおいて生じ得るステータスタイプコードを含む情報を含むレコードを格納したステータステーブルと、
   特定の回議者名、回議順を特定する回議順ＩＤ、前記権限タイプコードを特定する情報を含む回議情報テーブルと、
   前記隣接する回議順ＩＤの先後を示す情報を含むレコードを格納した回議順連結テーブルと、
   回議者を特定して、前記回議情報テーブル、権限テーブルを参照して、関連する権限タイプコードを特定し、かつ、前記ステータステーブルを参照して、文書のステータスタイプコードを特定し、さらに、前記権限タイプコードおよびステータスタイプコードにより、当該文書に対して回議者が実行可能な操作を特定して、回議者からの前記実行可能な操作から選択された何れかにしたがって、前記文書のステータスを変更するとともに、回議順連結テーブルを参照して、次の回議者を特定するフロー進行処理手段とを備えたことを特徴とするワークフロー制御システム。
2. ユーザの指定にしたがって、所望の回議順或いは隣接する回議順の間に、所定の権限をもつ回議者を追加するために、回議者、回議順ＩＤおよび権限タイプコードを特定する情報を含むレコードを、前記回議情報テーブル中の所定の位置に挿入するとともに、必要に応じて、前記回議順連結テーブルのレコードを挿入およびレコードの値を更新するフロー更新手段を備えたことを特徴とする請求項１に記載のワークフロー制御システム。
3. 前記フロー更新手段が、前記権限テーブルを参照して、追加可能な回議者の権限を示す情報を提示し、前記追加可能な権限を示す情報から選択させることを特徴とする請求項２に記載のワークフロー制御システム。
4. 前記回議情報テーブルのレコードが、同回議順内での順序を示す値を含み、前記フロー更新手段が、同回議順に回議者が追加される場合に、新たなレコード中、回議順内での順序示す値として、既に存在する同回議順のレコードと異なる値を採番することを特徴とする請求項２または３に記載のワークフロー制御システム。
5. 前記フロー更新手段が、既に存在する隣接する回議順の間に新たな回議順の回議者を追加する場合に、既存の隣接する回議順ＩＤの間に、新たな回議順ＩＤが挿入されるように、前記回議順連結テーブルのレコードを更新することを特徴とする請求項２または３に記載のワークフロー制御システム。
6. さらに、前記権限テーブルおよびステータステーブルを更新するテーブル更新手段を備えたことを特徴とする請求項２ないし５の何れか一項に記載のワークフロー制御システム。
7. 前記権限タイプコードが、少なくとも、申請、承認、決裁、相談、および、連絡にそれぞれ対応する値を含むことを特徴とする請求項１ないし６の何れか一項に記載のワークフロー制御システム。
8. 回議者の権限およびその権限タイプを示す権限タイプコードを含むレコードを格納した権限定義テーブルと、文書のステータスおよびそのステータスタイプを示すステータスタイプコードを含むレコードを格納したステータス定義テーブルと、前記権限タイプコードおよびステータスタイプコードに応じて回議者が実行可能な操作を関連付けたレコードを含むアクション定義テーブルと、文書フローにおいて使用可能な権限タイプコード、および、その権限タイプコードを特定する情報を含むレコードを格納した権限テーブルと、文書フローにおいて生じ得るステータスタイプコードを含む情報を含むレコードを格納したステータステーブルと、特定の回議者名、回議順を特定する回議順ＩＤ、前記権限タイプコードを特定する情報を含む回議情報テーブルと、前記隣接する回議順ＩＤの先後を示す情報を含むレコードを格納した回議順連結テーブルとを備えたコンピュータにより読み出し可能なワークフロー制御プログラムであって、
   回議者を特定して、前記回議情報テーブル、権限テーブルを参照して、関連する権限タイプコードを特定するステップと、
   前記ステータステーブルを参照して、文書のステータスタイプコードを特定するステップと、
   前記権限タイプコードおよびステータスタイプコードにより、当該文書に対して回議者が実行可能な操作を特定するステップと、
   前記回議者からの前記実行可能な操作から選択された何れかにしたがって、前記文書のステータスを変更するとともに、回議順連結テーブルを参照して、次の回議者を特定するステップとを、前記コンピュータに実行させることを特徴とするワークフロー制御プログラム。
9. ユーザの指定にしたがって、所望の回議順或いは隣接する回議順の間に、所定の権限をもつ回議者を追加するために、回議者、回議順ＩＤおよび権限タイプコードを特定する情報を含むレコードを、前記回議情報テーブル中の所定の位置に挿入し、必要に応じて、前記回議順連結テーブルのレコードを挿入およびレコードの値を更新するフロー更新ステップを、前記コンピュータに実行させることを特徴とする請求項８に記載のワークフロー制御プログラム。
10. 前記フロー更新ステップにおいて、前記権限テーブルを参照して、追加可能な回議者の権限を示す情報を提示し、前記追加可能な権限を示す情報から選択させるステップを、前記コンピュータに実行させることを特徴とする請求項９に記載のワークフロー制御プログラム。
11. 前記回議情報テーブルのレコードが、同回議順内での順序を示す値を含み、前記フロー更新手段ステップにおいて、同回議順に回議者が追加される場合に、新たなレコード中、回議順内での順序示す値として、既に存在する同回議順のレコードと異なる値を採番するステップを、前記コンピュータに実行させることを特徴とする請求項９または１０に記載のワークフロー制御プログラム。
12. 前記フロー更新ステップにおいて、既に存在する隣接する回議順の間に新たな回議順の回議者を追加する場合に、既存の隣接する回議順ＩＤの間に、新たな回議順ＩＤが挿入されるように、前記回議順連結テーブルのレコードを更新するステップを、前記コンピュータに実行させることを特徴とする請求項９または１０に記載のワークフロー制御プログラム。
13. さらに、前記権限テーブルおよびステータステーブルを更新するテーブル更新ステップを、前記コンピュータに実行させることを特徴とする請求項９ないし１２の何れか一項に記載のワークフロー制御プログラム。

Images