(57)【要約】【課題】組織単位で自由に電子文書を回付可能にするワークフロー管理システムを提供する。【解決手段】複数の組織の各々に含まれる１又は複数の端末と、端末とネットワークを介して接続されたワークフロー管理サーバとを備えたワークフロー管理システムにおいて、端末は、回付すべき１又は複数の回付先組織と、該回付先組織内の１又は複数の回付先端末とを設定する回付情報を作成する手段と、回付情報とともに回付要求をサーバへ送信する手段とを有し、サーバは、回付情報に基づいて、タスク管理データベースに格納する手段と、ワークフロー管理データベースに格納する手段と、ワークフロールート管理データベースに格納する手段と、回付処理を実施する手段と、各データベースを更新する手段とを有する。【選択図】図１
2010231689.tif 000002
【特許請求の範囲】
【請求項１】
複数の組織の各々に含まれる１又は複数の端末と、前記端末とネットワークを介して接続されたワークフロー管理サーバとを備えたワークフロー管理システムにおいて、
前記端末は、
起案者端末として、タスク選択情報と稟議書起票情報とを前記サーバへ送信する手段と、
起案者端末として、１又は複数の回付先組織と、該回付先組織における１又は複数の回付先端末とを設定する回付情報とともに回付要求を前記サーバへ送信する手段と、
回付先端末として、回付先に変更のある場合は１又は複数の回付先組織と該回付先組織における１又は複数の回付先端末とを設定する回付情報とともに回付要求を、回付先に変更のない場合は回付要求のみを前記サーバへ送信する手段とを有し、
前記サーバは、
前記起案者端末から送信されたタスク選択情報及び稟議書起票情報に基づいて、稟議書に対応するタスクを一意に識別するタスク番号と、該タスク番号に係るタスクを保有する端末とを対応付けてタスク管理データベースに格納する手段と、
前記起案者端末または前記回付先端末から送信された回付情報に基づいて、タスク番号と、タスクの現在のワークフロー状態と、最終的な稟議状態とを対応付けてワークフロー管理データベースに格納する手段と、
前記起案者端末または前記回付先端末から送信された回付情報に基づいて、タスク番号と、回付先組織と、該回付先組織における決済状態とを対応付けてワークフロールート管理データベースに格納する手段と、
前記起案者端末または前記回付先端末から回付要求があった場合に、前記回付情報により指定された回付先端末に前記稟議書を回付する回付処理を実施する手段と、
回付処理を実施された回付先端末を前記タスク管理データベースに新たに登録する手段と、
回付処理を実施された回付先端末が該回付先組織における最終承認者の端末であった場合に、前記ワークフロールート管理データベースの該回付先組織における決済状態を更新する手段と、
前記回付処理の実施後、全ての回付先組織の決済状態が更新された場合に、前記ワークフロー管理データベースの最終的な稟議状態を更新する手段とを有することを特徴とする
ワークフロー管理システム。
【請求項２】
前記サーバは、
回付処理を実施する毎に、前記タスク番号と、該回付を実施された回付先組織及び回付先端末と、該回付先組織毎の承認状態とをワークフロー承認管理データベースに格納する手段と、
回付処理を実施する毎に、前記タスク番号と、該回付を実施された回付先組織及び回付先端末と、該回付先端末毎の回付結果とを対応付けてワークフロー履歴管理データベースに格納する手段とを有することを特徴とする請求項１に記載のワークフロー管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子稟議書などの電子文書を企業等の中で回付するためのワークフロー管理システムに関する。
【背景技術】
【０００２】
例えば、特許文献１には、以下のようなワークフロー管理システムが開示されている。稟議雛形データベースには、各稟議書の内容を格納し、担当者データベースには、回付先組織と各組織内の回付順番を格納し、稟議雛形データベースと担当者データベースとを用いて具体的な回付順番を決定し、その回付順番で電子メールを送信し、各担当者は回付された内容に問題がなければ承認を行う。回付内容に問題がある場合は、担当者データベースにアクセスして回付先組織や回付順番を変更し承認を行う。このようなシステムを用いると、組織内の担当者の追加や変更、移動、回付順番の変更に対し、稟議が決裁完了するまでの間はいつでも行うことが可能になる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2002−99687号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１のワークフロー管理システムにおいては、以下３点の問題がある。
(１)回付予定の各担当者（以下、「ユーザ」と称する）を回付処理実施前に定義をする必要があり、回付済みのユーザに対して回付物を再度回付することについては考えられていない。
(２)複数組織に対して回付を行うことには対応しているが、複数組織に対して同時に回付を行うことについては考えられていないため、複数の組織に跨って回付を行う場合は組織単位で順番に承認を受ける必要がある。そのため、緊急を要する稟議書の決裁を行う場合、起案から決裁まで時間を要してしまう。
(３)組織毎に各種情報を保持するためにサーバやデータベースを保有しているが、組織追加等によりサーバやデータベースの追加または削除が必要となり、拡張性・保守性の低下が懸念される。
【０００５】
よって本発明の目的は、組織単位で自由に電子文書を回付可能にする新規な構成のワークフロー管理システムを提供することである。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明のワークフロー管理システムは、複数の組織の各々に含まれる１又は複数の端末と、前記端末とネットワークを介して接続されたワークフロー管理サーバとを備えたワークフロー管理システムにおいて、
前記端末は、起案者端末として、タスク選択情報と稟議書起票情報とを前記サーバへ送信する手段と、起案者端末として、１又は複数の回付先組織と、該回付先組織における１又は複数の回付先端末とを設定する回付情報とともに回付要求を前記サーバへ送信する手段と、回付先端末として、回付先に変更のある場合は１又は複数の回付先組織と該回付先組織における１又は複数の回付先端末とを設定する回付情報とともに回付要求を、回付先に変更のない場合は回付要求のみを前記サーバへ送信する手段とを有する。一方、前記サーバは、前記起案者端末から送信されたタスク選択情報及び稟議書起票情報に基づいて、稟議書に対応するタスクを一意に識別するタスク番号と、該タスク番号に係るタスクを保有する端末とを対応付けてタスク管理データベースに格納する手段と、前記起案者端末または前記回付先端末から送信された回付情報に基づいて、タスク番号と、タスクの現在のワークフロー状態と、最終的な稟議状態とを対応付けてワークフロー管理データベースに格納する手段と、前記起案者端末または前記回付先端末から送信された回付情報に基づいて、タスク番号と、回付先組織と、該回付先組織における決済状態とを対応付けてワークフロールート管理データベースに格納する手段と、前記起案者端末または前記回付先端末から回付要求があった場合に、前記回付情報により指定された回付先端末に前記稟議書を回付する回付処理を実施する手段と、回付処理を実施された回付先端末を前記タスク管理データベースに新たに登録する手段と、回付処理を実施された回付先端末が該回付先組織における最終承認者の端末であった場合に、前記ワークフロールート管理データベースの該回付先組織における決済状態を更新する手段と、前記回付処理の実施後、全ての回付先組織の決済状態が更新された場合に、前記ワークフロー管理データベースの最終的な稟議状態を更新する手段とを有する。
さらに、前記サーバは、回付処理を実施する毎に、前記タスク番号と、該回付を実施された回付先組織及び回付先端末と、該回付先組織毎の承認状態とをワークフロー承認管理データベースに格納する手段と、回付処理を実施する毎に、前記タスク番号と、該回付を実施された回付先組織及び回付先端末と、該回付先端末毎の回付結果とを対応付けてワークフロー履歴管理データベースに格納する手段とを有することが好適である。
【発明の効果】
【０００７】
本発明のワークフロー管理システムによれば、次のような効果がある。
（１）回付処理を実施済みのユーザ（起案者端末または回付先端末）に再度回付をすることが可能となる。
（２）複数の組織に対して回付処理を同時に依頼することが可能となり、承認作業の速度向上が図られる。
（３）組織変更等により組織の数に変更が発生した場合においてもサーバ及びデータベースの追加及び削除を発生させない。
本発明によるワークフロー管理システムは、この３点の効果により組織内外において自由に稟議書を回付することを実現とする。
【図面の簡単な説明】
【０００８】
【図１】本発明の一実施の形態におけるシステム構成図である。
【図２】本発明の一実施の形態におけるデータベース関連図である。
【図３】本発明の一実施の形態におけるである回付ルートの例である。
【図４】処理フローである。
【図５】起案後のデータベースの一例である。
【図６】回付先設定処理画面の一例である。
【図７】回付先設定処理後のワークフロールート管理ＤＢの一例である。
【図８】回付処理画面の一例である。
【図９】回付後のデータベースの一例である。
【図１０】決裁後のデータベースの一例である。（図１１に続く）
【図１１】決裁後のデータベースの一例である。（図１０から続く）
【発明を実施するための形態】
【０００９】
以下、本発明によるワークフロー管理システムの一実施の形態について説明する。
＜１．環境構成＞
図１は、本発明の一実施の形態におけるシステム構成図である。例えば図１に示すように、社内ＬＡＮ（local Area Network）であるネットワーク１には、ワークフロー管理に用いられるサーバＡ及びサーバＢと、起案者、起案組織決裁者、本部決裁者、協議決裁者等がそれぞれ使用するクライアント端末１１〜１４とが接続されている。サーバＡ及びサーバＢの数、クライアント端末１１〜１４の数は、図１に示された数に制限されるものではなく、社員数等に依存して変更することが可能である。
【００１０】
ワークフロー管理に用いられるサーバＡは、回付要求が発生した際に処理制御を行う制御部Ａ１と、ワークフロー情報を格納しているサーバＢ内の各データベースを更新する更新部Ａ２とを備え、これらを管理する。
【００１１】
サーバＢは、稟議起案元となるタスク情報を格納するタスク管理データベース（ＤＢ）２０と、タスクより発生した稟議書の内容を格納する稟議データベース（ＤＢ）２１と、稟議書とワークフロー情報の紐付けとワークフローの状態とを格納するワークフロー管理データベース（ＤＢ）２２と、ワークフローの組織毎の回付状態を格納するワークフロールート管理データベース（ＤＢ）２３と、ワークフロー内での組織毎の承認結果を格納するワークフロー承認管理データベース（ＤＢ）２４と、ワークフローの履歴を格納するワークフロー履歴管理データベース（ＤＢ）２５とを備え、これらを管理する。
【００１２】
またクライアント端末１１〜１４には、本実施の形態に係るワークフロー管理のためのクライアントアプリケーションがインストールされている。例えば、ＩＥ（Internet Explore）のようなウェブブラウザである。クライアントアプリケーションにより実現される機能は、サーバ側から送信された要求を制御またはユーザが指定した要求をサーバへ送信を行う処理部と、処理部からの要求に対して画面上反映を行う、またはユーザが指定した要求を処理部へ要求を行う表示入力部とを備え、これらを管理する。
【００１３】
＜２．データベース構成＞
図２は、サーバＢに格納されている各データベース内のデータの関連性について示した図である。全てのデータベースは、「タスク番号」というワークフロー管理システム内で一意となる連番をデータ項目として保有している。この「タスク番号」を元にワークフローの制御を行う。
以下、各ＤＢ及び主要なデータ項目についての説明を記述する。
【００１４】
（１）タスク番号
各ユーザが業務を行うためのきっかけとなる作業単位を識別する番号である。そのため、作業単位をより詳細にする場合は、本項目をより細分化することも可能である。例えば、種類及び日付を作業単位とした場合、タスク番号は「タスク種類、タスク日付」という２項目を含むことになる。稟議書はこのタスク番号と１対１で紐付けが行われる。
【００１５】
（２）ルート区分
稟議書を回付する際の、組織毎の役割を示す区分である。ルート区分には「起案、本部、協議、連絡」の４点がある。「起案」は稟議書を起案した組織であり、稟議書に対して決裁権限を保有している。「本部」は起案組織内で決裁が完了しなかった場合に最終的に決裁を行う組織であり、稟議書に対して決裁権限を保有している。「協議」は起案組織が本部以外の任意の数の組織に承認依頼を行う際の組織であり、稟議書に対して決裁権限を保有している。「連絡」は起案組織が本部以外の任意の数の組織に承認依頼を行う際の組織であり、稟議書に対して決裁権限を保有していない。
【００１６】
タスク番号に対しては必ず起案ルートが一つ存在する。その他のルートは回付中に追加または削除が可能である。これはワークフローを開始した組織を起案ルートとするためである。
【００１７】
また上記のルート区分の種類については本発明の形態の１例であるため、その他ルートを任意で追加することも可能である。例えば、「監査」というルートを追加し、監査ルートが否決した場合にはいかなる場合も稟議書は否決で決裁される、等である。
【００１８】
（３）タスク管理ＤＢ２０
タスク番号を基に、タスクを共有できるユーザ単位の情報をキーとする。例えば、タスク番号、組織番号、ユーザ番号をキーとした場合、同組織内外では同タスクを共有可能であるが、ユーザ一人は同タスクを複数保有することは可能である。
またルート単位で更新権限を保有し、更新権限を保有するルートのみが回付処理を実施できるよう制御部Ａ１は制御を行う。
【００１９】
（４）稟議ＤＢ２１
電子稟議書の内容を格納する。タスク番号をキーとする。
【００２０】
（５）ワークフロー管理ＤＢ２２
稟議書とワークフロー情報の紐付けとワークフローの状態を格納する。タスク番号をキーとする。
【００２１】
（６）ワークフロールート管理ＤＢ２３
ワークフローの組織毎の決裁状態を格納する。タスク番号、ルート区分、組織番号をキーとする。ワークフロー管理ＤＢ２２と本ＤＢは、タスク番号を元に１対Ｎの関係が成り立つ。
【００２２】
（７）ワークフロー承認管理ＤＢ２４
ワークフローの組織毎の承認状態を格納する。タスク番号、ルート区分、組織番号、連番をキーとする。ワークフロールート管理ＤＢ２３と本ＤＢは、タスク番号、ルート区分、組織番号を元に１対Ｎの関係が成り立つ。
【００２３】
（８）ワークフロー履歴管理ＤＢ２５
ワークフローの履歴を格納する。タスク番号、ルート区分、組織番号、連番をキーとする。ワークフロールート管理ＤＢ２３と本ＤＢは、タスク番号、ルート区分、組織番号を元に１対Ｎの関係が成り立つ。
【００２４】
＜３．処理概要＞
次に組織Ａを起案ルートとした、稟議書が回付される処理概要の実施例を、図１と図３から図１０までを用いて説明する。本実施例では、図３のように組織Ａから組織Ｂ及び組織Ｃまで回付を行い、決裁を実施するワークフローを想定している。
【００２５】
最初に、電子稟議書の起案者３１はタスク一覧からタスクを選択し、稟議書作成用メニューにアクセスする（図４：ステップ０１）。そして今回起票する電子稟議書の種類を指定して起票を命ずると、クライアントの処理部は、起票をサーバＡへ要求する（ステップ０２）。起票命令を受けた制御部Ａ１はタスクと稟議書を紐付けるため更新部Ａ２を呼び出す。更新部Ａ２は、稟議ＤＢ２１、ワークフロー管理ＤＢ２２、ワークフロールート管理ＤＢ２３にタスクと稟議書の情報を格納する。その後制御部Ａ１は、稟議ＤＢ２１からタスクのデータを参照し、稟議書作成用メニューに表示するためクライアントへ表示要求を送信する。要求を受けたクライアントの処理部は表示入力部を呼び出し、稟議書作成用メニューを表示する。この起票命令からの更新によって、ワークフローの処理が開始される。
図５は、登録されるワークフロー情報の一例を示す。
【００２６】
稟議書が起票された後、起案者３１は、起案組織内の最終決裁者と、回付先組織の情報とを入力する（ステップ０３）。これにより、ワークフロールート管理ＤＢ２３には起案組織内の最終決裁者と回付先組織を含んだ情報が格納される。
【００２７】
上記の回付先の設定の一例について図６及び図７を用いて説明する。本実施の形態において、回付先設定を行う場合には、図６に示すような画面を用いて行う。図６に表した画面例には、起案・本部・協議・連絡のルート毎に組織名６１と、初回回付先６２と、最終承認者６３とを選択するプルダウンと、画面内で指定した情報を用いてサーバＡへ要求を送信するためのボタン（確定）とが用いられている。ユーザは、本画面にて回付先の情報を設定し確定ボタンを押下することにより、処理部は選択した情報をサーバＡに送信し、要求を受けた制御部Ａ１は、ワークフロールート管理２３を更新するために更新部Ａ２を呼び出す。呼び出された更新部Ａ２はワークフロー管理ＤＢ２２を更新する。
図７は、ワークフロールート管理ＤＢ２３に登録される回付先情報の一例を示す。
【００２８】
その後、稟議書作成用メニューより回付先ユーザを指定して回付処理を実施する（ステップ０４）と、回付要求を受けた制御部Ａ１は回付先の組織と回付種類が正しいかチェックを行い（ステップ０５）、問題が無い場合は次に回付先のユーザと指定した回付種類に問題がないかをチェックする（ステップ０６）。チェックの結果問題が無い場合は、制御部Ａ１は指定された回付種類が最終承認かを判定し（ステップ０７）、最終承認ではない場合は回付先ユーザにタスク情報を登録するため更新部Ａ２を呼び出す。更新部Ａ２はタスク管理ＤＢ２０と、ワークフロー管理ＤＢ２２と、ワークフロールート管理ＤＢ２３と、ワークフロー承認管理ＤＢ２４とワークフロー履歴管理ＤＢ２５に対して登録・更新を行う（ステップ０８）。
【００２９】
上記の回付処理の一例について図８及び図９を用いて説明する。本実施の形態において、回付処理を行う場合には、図８に示すような画面を用いて行う。図８に表した画面例には、回付先組織を選択するためのプルダウンと、回付先のユーザを選択するためのプルダウンと、回付の種類を選択するためのプルダウンと、画面内で指定した情報を用いてサーバへ要求を送信するためのボタン（回付）とが用いられている。ユーザは本画面にて回付先の情報を設定し回付ボタンを押下することにより、処理部は選択した情報をサーバＡに送信し、要求を受けた制御部Ａ１はタスク管理ＤＢ２０と、ワークフロー管理ＤＢ２２と、ワークフロールート管理ＤＢ２３とを更新するために更新部Ａ２を呼び出す。呼び出された更新部Ａ２は、タスク管理ＤＢ２０には回付先ユーザ３２にタスクを更新権限有りで登録し、起案者３１のタスクを更新権限無しで更新し、ワークフロー管理ＤＢ２２はワークフローの状態を更新し、ワークフロールート管理ＤＢ２３は回付を実施したルートの状態を更新し、ワークフロー承認管理ＤＢ２４とワークフロー履歴管理ＤＢ２５には回付を実施したユーザ情報を登録する。
また、図９は、各テーブルに登録されるワークフロー情報の一例を示す。
【００３０】
回付処理が完了すると、制御部Ａ１は処理部にタスク一覧を表示するために表示要求を送信する。要求を受けた処理部は表示入力部を呼び出し、クライアントの画面上にタスク一覧を表示する。これにより起案者３１の回付が全て完了する。
【００３１】
回付されたユーザ３２は、起案者３１より回付されたタスクをタスク一覧上で受け取る。ユーザ３２は、タスクを選択し稟議作成用メニューを表示する。この時、表示要求をサーバＡが受け取ると、制御部Ａ１ではタスク管理ＤＢを参照し更新権限が存在するかをチェックし、更新権限がない場合は回付を実施できないよう制御する。例えば、ボタンを非表示または非活性にする。チェックにて問題が無かった場合は、制御部Ａ１は受け取ったタスクを元にワークフロールート管理ＤＢ２３にアクセスし、回付実施可能となるように制御を行う。
【００３２】
ユーザ３２は回付物に問題が無いかを確認し、問題がなければ回付先ユーザを指定して回付を実施する。回付要求を受けた制御部Ａ１は回付先の組織と回付種類が正しいかチェックを行い（ステップ０５）、問題が無い場合は次に回付先のユーザと指定した回付種類に問題がないかをチェックする（ステップ０６）。チェックの結果問題が無い場合は、制御部Ａ１は指定された回付種類が最終承認かを判定し（ステップ０７）、最終承認ではない場合は回付先ユーザにタスク情報を登録するため更新部Ａ２を呼び出す。更新部Ａ２はタスク管理ＤＢ２０と、ワークフロー管理ＤＢ２２と、ワークフロールート管理ＤＢ２３と、ワークフロー承認管理ＤＢ２４とワークフロー履歴管理ＤＢ２５に対して登録・更新を行う（ステップ０８）。
【００３３】
上記の更新部Ａ２では、タスク管理ＤＢ２０に回付先ユーザにタスクを登録しているが、仮に回付先に同一タスクが存在した場合は、更新部Ａ２は回付先ユーザのタスクは更新権限有りで更新を行う。本発明の実施例においても起案者３１に対してはすでにタスクは登録済みである。そのため、更新部Ａ２は起案者３１のタスクに対して更新権限有りで更新を行う。
【００３４】
回付処理が完了すると、制御部Ａ１は処理部にタスク一覧を表示するために表示要求を送信する。要求を受けた処理部は表示入力部を呼び出し、クライアントの画面上にタスク一覧を表示する。これによりユーザ３２の回付が全て完了する。
【００３５】
回付された起案者３１及びユーザ３２は、タスクをタスク一覧上で受け取る。タスクを指定して稟議書作成用メニュー表示後の回付動作は上記で述べた処理と変わらない。ただし、ユーザ３２については回付先の指定が本部ルートのユーザ３３となる。
【００３６】
この時回付元のユーザと回付先のユーザの組織が異なり回付先が本部ルートである場合は、制御部Ａ２はワークフロールート管理ＤＢ２３にアクセスし、起案ルートの決裁状態を「決裁済」に更新する。
【００３７】
また、回付先組織にタスク未登録ルートが存在する場合（ステップ０９）、未登録ルートの初回回付先ユーザ（ユーザ３３）にタスク情報を登録するために更新部Ａ２を呼び出す。更新部Ａ２はタスク管理ＤＢ２０には回付先ユーザ３３にタスクを更新権限有りで登録しユーザ３２のタスクを更新権限無しで更新し、ワークフロー管理ＤＢ２３は回付を実施したルートの状態を更新し、ワークフロー承認管理ＤＢ２４とワークフロー履歴管理ＤＢ２５には回付を実施したユーザ情報を登録する（ステップ１０）。
【００３８】
回付処理が完了すると、制御部Ａ１は処理部にタスク一覧を表示するために表示要求を送信する。要求を受けた処理部は表示入力部を呼び出し、クライアントの画面上にタスク一覧を表示する。これによりユーザ３２の回付が全て完了する。
【００３９】
回付された本部ルートのユーザ３３は、起案ルートより回付されたタスクをタスク一覧上で受け取る。ユーザ３３はタスクを選択し稟議作成用メニューを表示する。この時、表示要求をサーバＡが受け取ると、制御部Ａ１ではタスク管理ＤＢを参照し更新権限が存在するかをチェックし、更新権限がない場合は回付を実施できないよう制御する。例えば、ボタンを非表示または非活性にする。チェックにて問題が無かった場合は、制御部Ａ１は受け取ったタスクを元にワークフロールート管理ＤＢ２３にアクセスし、回付実施可能となるように制御を行う。
【００４０】
ユーザ３３は回付物に問題が無いかを確認し、問題が無い場合はユーザ３３自身が最終承認者であるため最終承認を実施する。回付要求を受けた制御部Ａ１は、回付先の組織と回付種類が正しいかチェックを行い（ステップ０５）、問題が無い場合は次に回付先のユーザと指定した回付種類に問題が無いかをチェックする（ステップ０６）。チェックの結果問題が無い場合は、制御部Ａ１は指定された回付種類が最終承認かを判定し（ステップ０７）、最終承認である場合は自組織の決裁情報を更新するため更新部Ａ２を呼び出す。更新部Ａ２はタスク管理ＤＢ２０と、ワークフロールート管理ＤＢ２３と、ワークフロー承認管理ＤＢ２４とワークフロー履歴管理ＤＢ２５に対して登録・更新を行う（ステップ１１）。
【００４１】
また、制御部Ａ１はワークフロールート管理ＤＢ２３を参照し、全てのルートが決裁済みになっているかを判定する（ステップ１２）。全ルートが決裁済みでない場合は何も処理をしない。
【００４２】
回付処理が完了すると、制御部Ａ１は処理部にタスク一覧を表示するために表示要求を送信する。要求を受けた処理部は表示入力部を呼び出し、クライアントの画面上にタスク一覧を表示する。これによりユーザ３３の回付が全て完了する。
【００４３】
回付された協議ルートのユーザ３４は起案ルートより回付されたタスクをタスク一覧上で受け取る。ユーザ３４はタスクを選択し稟議作成用メニューを表示する。この時、表示要求をサーバＡが受け取ると、制御部Ａ１ではタスク管理ＤＢを参照し更新権限が存在するかをチェックし、更新権限がない場合は回付を実施できないよう制御する。例えば、ボタンを非表示または非活性にする。チェックにて問題が無かった場合は、制御部Ａ１は受け取ったタスクを基にワークフロールート管理ＤＢ２３にアクセスし、回付実施可能となるように制御を行う。
【００４４】
ユーザ３４は回付物に問題が無いかを確認し、問題がない場合はユーザ３４自身が最終承認者であるため最終承認を実施する。回付要求を受けた制御部Ａ１は回付先の組織と回付種類が正しいかチェックを行い（ステップ０５）、問題が無い場合は次に回付先のユーザと指定した回付種類に問題がないかをチェックする（ステップ０６）。チェックの結果問題が無い場合は、制御部Ａ１は指定された回付種類が最終承認かを判定し（ステップ０７）、最終承認である場合は自組織の決裁情報を更新するため更新部Ａ２を呼び出す。更新部Ａ２はタスク管理ＤＢ２０と、ワークフロールート管理ＤＢ２３と、ワークフロー承認管理ＤＢ２４とワークフロー履歴管理ＤＢ２５に対して登録・更新を行う（ステップ１１）。
【００４５】
また、制御部Ａ１はワークフロールート管理ＤＢ２３を参照し、全てのルートが決裁済みになっているかを判定する（ステップ１２）。全ルートが決済済みである場合は稟議自体を決裁済みとするために、制御部Ａ１は更新部Ａ２を呼び出す。更新部Ａ２はワークフロー管理ＤＢ２１に対して更新を行う（ステップ１３）。
【００４６】
図１０、図１１に決裁後の各テーブルの状態を示す。
以上により起案から決裁までのワークフローが完了する。
以上で述べた本実施の形態は一例であって、様々な変形が可能である。図４のフローも一例であって、ステップを追加することも可能である。例えば、ステップ０６の後に新たなチェックを追加することなどが可能である。
【符号の説明】
【００４７】
１  ネットワーク
１１，１２，１３，１４ クライアント端末
２０、２１、２２，２３，２４，２５ データベース
６１ 回付先組織プルダウン
６２ 初回回付先プルダウン
６３ 最終承認者プルダウン
８１ 回付先組織プルダウン
８２ 回付先ユーザプルダウン
８３ 回付種類プルダウン
【図１】
2010231689.tif 000003
【図２】
2010231689.tif 000004
【図３】
2010231689.tif 000005
【図４】
2010231689.tif 000006
【図５】
2010231689.tif 000007
【図６】
2010231689.tif 000008
【図７】
2010231689.tif 000009
【図８】
2010231689.tif 000010
【図９】
2010231689.tif 000011
【図１０】
2010231689.tif 000012
【図１１】
2010231689.tif 000013