ワークフローシステムおよび滞留電子文書処理方法
【課題】ワークフロー上の正規の決裁担当者が不在であること等が判明した場合にも、起案者の決裁完了希望日を満足できるよう、配送経路上の最適な代行決裁者へ代行決裁委任を行うことができ、電子文書の円滑な処理が促進できるようにすること。
【解決手段】ワークフローサーバ２００のＣＰＵが、次の承認・決裁者による電子文書のワークフロー処理が所定の滞留期限を超過している滞留電子文書を検知し、該検知された滞留電子文書の配送経路上で次の承認・決裁者の上長にあたる承認・決裁者のスケジュールを参照し、該上長にあたる参照した承認・決裁者のスケジュールと、前記滞留期限とに基づいて決裁代行者として委任設定する上長を決定する構成を特徴とする。
【解決手段】ワークフローサーバ２００のＣＰＵが、次の承認・決裁者による電子文書のワークフロー処理が所定の滞留期限を超過している滞留電子文書を検知し、該検知された滞留電子文書の配送経路上で次の承認・決裁者の上長にあたる承認・決裁者のスケジュールを参照し、該上長にあたる参照した承認・決裁者のスケジュールと、前記滞留期限とに基づいて決裁代行者として委任設定する上長を決定する構成を特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワークフローシステムにおいて、承認担当者不在等により滞留している未処理案件である滞留電子文書の処理に関する。
【背景技術】
【０００２】
電子文書の承認業務の効率を向上させるインフラの１つとして、ワークフローシステムがある。
【０００３】
ワークフローシステムは、組織または役割、もしくはユーザという個人単位の配布者を設定し、配布者間の電子文書の配布ルート（配布順序）を予めワークフローサーバに登録しておき、この順序に従って自動的に電子文書を配布しようとするものである。
【０００４】
多くのワークフローシステムでは、電子文書の配布先となった決裁担当者が不在となる場合、同等の役割をもつ担当者を事前に決裁代行者として設定し、決裁担当者に配布されるべき電子文書を該代行者が代わって受信し、業務処理を代行することで業務停滞を回避させている。
【０００５】
しかし、現実の運用においては、ワークフロー上の正式な決裁担当者の突発的な所用、例えば病気や緊急出張等があったため、代行担当者を設定することなく不在にしてしまい、結果、長期間の電子文書の滞留を引き起こしていた。
【０００６】
このような問題を解決するための提案としては、特開平１１-２１９３９３がある。
【０００７】
これは、ワークフロー上の決裁担当者に代わって、決裁担当者による代行担当者を予め設定しておき、ワークフロー上の決裁担当者に対して処理が依頼されている電子文書について、予め設定された処理期間内に処理が完了しているか否かを所定のタイミングで判定し、滞留と判断された場合に、決裁担当者に代わる代行担当者に対し、当該電子文書の処理を依頼するための電子メールを生成して送信するというものである。
【０００８】
これにより、ワークフロー上の正規の担当者が不在の場合でも、システム側で代行担当者に電子文書処理を依頼することができる。
【特許文献１】特開平１１-２１９３９３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら上述のワークフローシステムは、ワークフロー上の正規の業務担当者が長期不在により電子文書が滞留したことが判明した段階で、予め定めた決裁代行担当者に電子文書の処理依頼メールを送信し、代行を促す手法であるため、決裁担当者と代行担当者が同時期に急遽、長期不在となった場合、やはり、長期間、業務案件を滞留させてしまうことになり、電子文書の円滑な処理を損なうことになる。
【００１０】
また、同じ電子文書でも、たとえば社内稟議書や人事異動申請書といった重要な電子文書の場合、予め設定された決裁代行者に無条件に配送したのでは不都合が発生する場合もある。
【００１１】
そもそも、決裁代行者への配送はワークフロー上の正規の決裁担当者が明示的に代行委任設定を行ったときに限り行うべきものであり、突発的な事由による電子文書の滞留の場合には、当該事案の代行決裁は上長に委ねた方がセキュリティの観点からも無難な場合が多い。
【００１２】
決裁担当者不在時の代行決裁者を電子文書配送経路上の直属の上長とした場合、該上長の長期不在においては、やはり電子文書の決裁業務が滞るという問題が考えられる。
【００１３】
また、配送経路上のすべての上長の中で長期不在でない上長を決裁代行者として委任した場合にも、代行決裁者のスケジュールによっては、該上長への代行決裁では、起案者の決裁完了希望日までに決裁が完了できないという問題が考えられる。
【００１４】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、次の承認・決裁者による電子文書のワークフロー処理が所定の滞留期限を超過している滞留電子文書を検知し、該検知された滞留電子文書の配送経路上で次の承認・決裁者の上長にあたる承認・決裁者のスケジュールを参照し、該上長にあたる参照した承認・決裁者のスケジュールと、前記滞留期限とに基づいて決裁代行者として委任設定する上長を決定することにより、ワークフロー上の正規の決裁担当者が不在であること等が判明した場合にも、起案者の決裁完了希望日を満足できるよう、配送経路上の最適な代行決裁者へ代行決裁委任を行うことができ、電子文書の円滑な処理が促進できるようにする仕組を提供することである。
【課題を解決するための手段】
【００１５】
本発明は、所定の配送経路に従って電子文書を回覧して承認・決裁のワークフロー処理を行うワークフローシステムにおいて、承認・決裁者の組織情報，承認・決裁者のスケジュールを記憶する記憶手段と、次の承認・決裁者による電子文書のワークフロー処理が所定の滞留期限を超過している滞留電子文書を検知する滞留検知手段と、前記滞留検知手段で検知された滞留電子文書の配送経路上で次の承認・決裁者の上長にあたる承認・決裁者のスケジュールを参照し、該上長にあたる参照した承認・決裁者のスケジュールと、前記滞留期限とに基づいて決裁代行者として委任設定する上長を決定制御する制御手段とを有することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、ワークフローの滞留を防止でき、処理すべきワークフロー業務の効率化を促進することができる。
【００１７】
従って、ワークフローシステムにおいて、承認担当者不在等により滞留している未処理案件を、その状態をシステム管理者に通達し、長期間滞留を回避させることができる等の効果を奏する。
【発明を実施するための最良の形態】
【００１８】
〔第１実施形態〕
以下、図面を参照して、本発明の詳細を説明する。
【００１９】
図１は、本実施形態が適用されるワークフローシステムの概略構成を示す図である。
【００２０】
本実施形態におけるワークフローシステムは、ワークフロー及び伝票設計用コンピュータ端末（ワークフロー及び伝票設計用端末）４００、業務を遂行する処理者（担当者）に対応して設けられたワークフロー操作用コンピュータ端末（ワークフロー操作用端末）３００、ワークフローを実行するための各種テーブル，各種プログラムを格納するワークフローサーバ２００を備えている。
【００２１】
これらワークフロー及び伝票設計用端末４００，ワークフロー操作用端末３００，ワークフローサーバ２００は、それぞれネットワーク５００に接続され運用されている。
【００２２】
ワークフロー及び伝票設計用端末４００は、伝票デザイナプログラム４０１及びシステム管理プログラム４０２を有し、ワークフローサーバ２００上の図示しない管理プログラムと通信して、ワークフローシステムにて使用する伝票の定義体の作成及びワークフローシステムで利用する各種定義情報の作成を行う。例えば、ワークフロー及び伝票設計用端末４００は、ワークフローサーバ２００に組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，各種伝票情報等を登録することができる。このワークフロー及び伝票設計用端末４００は、これらの作業を行うために、自己の識別情報を入力することによりワークフローサーバ２００に接続することが可能になる。
【００２３】
ワークフロー操作用端末３００は、ワークフロー操作用端末３００上で実行されるＷｅｂブラウザ３０１を用いて、伝票に関するアクセス情報をワークフローサーバ２００に対してＨＴＴＰで送信し、その結果を受信するものであり、その際に、発生する表示・計算処理は、Ｊａｖａ（登録商標）アプレット３０２等を利用することにより実行する。なお、このワークフロー操作用端末３００は、予め指定された所定の業務を行う担当者（例えば、起票者、課長、部長等）に配置されている。
【００２４】
ワークフローサーバ２００は、ワークフローシステムに関する情報（組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，配送情報テーブル，決裁担当者のスケジュールデータ，システム管理者テーブル等）を格納するＲＤＢＭＳ（Relational DataBaSe Management System）２０５、ワークフロー操作用コンピュータ端末よりの要求を受け付けて要求を実行するためのＨＴＴＰサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０４、ワークフロー通知機能を実現するＳＭＴＰサーバ２０３にて構成されている。
【００２５】
なお、ワークフローサーバ２００は、外部ＤＢに格納された所定のスケジュール情報（一般的なスケジュール管理ソフトウェアを用いて入力された各ユーザのスケジュール情報）を取得可能である。
【００２６】
以下、図２を参照して、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成について説明する。
【００２７】
図２は、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。
【００２８】
図２において、１０１はＣＰＵで、ＲＯＭ１０３又はハードディスク（ＨＤ）（その他の記憶装置、例えば、フレキシブルディスク，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭ等どのような記憶装置であってもよい）１０４に格納されたプログラムをＲＡＭ１０２上にロードして実行することにより、コンピュータ全体を制御する。ＲＡＭ１０２は、ＣＰＵ１０１の作業領域として使用される。
【００２９】
１０７は通信インタフェースで、ネットワーク５００への接続を可能とする。１０５は入力装置で、キーボードやマウス等のポインティングデバイス等に相当する。１０６は表示装置で、ＣＲＴ，ＬＣＤ等で構成される。
【００３０】
なお、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５は、ワークフローサーバ２００のＨＤ１０４内に構築されている。また、ワークフローサーバ２００のＨＴＴＰサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０４，ＳＭＴＰサーバ２０３は、ワークフローサーバ２００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００３１】
また、図１に示したワークフロー操作用端末３００のＷｅｂブラウザ３０１は、ワークフロー操作用端末３００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００３２】
さらに、図１に示したワークフロー操作用端末３００のＪａｖａ（登録商標）アプレット３０２は、ワークフロー操作用端末３００のＣＰＵ１０１が、ワークフローサーバ２００よりダウンロードされたプログラムをＷｅｂブラウザ３０１上で実行することにより、実現される。
【００３３】
また、図１に示したワークフロー及び伝票設計用端末４００の伝票デザイナプログラム４０１，システム管理プログラム４０２は、ワークフロー及び伝票設計用端末４００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００３４】
図３は、図１に示したワークフローシステムにおける伝票の流れを示す模式図である。
【００３５】
本実施形態のワークフローシステムでは、ワークフロー操作用端末３００を用いて、図３に示すように、伝票の起票，伝票の承認／否認の手続きを、ノードと呼ばれる組織と役割で定義された担当者が行う。なお、伝票が配送されるノードをひとつに括ったものをビジネスプロセスと定義する。
【００３６】
図４は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される組織テーブルのデータ構造の一例を示すデータ構成図である。なお、この組織テーブルは、ワークフローを実現するための組織に関する情報を記憶するためのものである。
【００３７】
図４に示す組織テーブルにおいて、組織ＩＤは、任意の組織名をコードとして表記したものであり、常に上位組織ＩＤを網羅している。また、組織名は、組織ＩＤの表示上の名称を示したものである。さらに、親組織ＩＤは、上位の組織ＩＤを示したものである。
【００３８】
図５は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される役割テーブルのデータ構造の一例を示すデータ構成図である。なお、この役割テーブルは、ワークフローを実現するための役割に関する情報を記憶するためのものである。
【００３９】
図５に示す役割テーブルにおいて、役割ＩＤは、任意の役割名をコードとして表記したものである。また、役割名は、役割ＩＤの表示上の名称を示したものである。
【００４０】
図６は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶されるユーザテーブルのデータ構造の一例を示すデータ構成図である。なお、このユーザテーブルは、ワークフローを利用するためのユーザの情報を記憶するためのものである。
【００４１】
図６に示すユーザテーブルにおいて、ユーザＩＤは、利用者を任意のコードとして表示したものである。また、パスワードは、ワークフローシステムにログインする際にユーザＩＤと共に認証に利用するためのものである。さらに、ユーザ名は、ユーザＩＤの表示上の名称を示したものである。
【００４２】
図７は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される役職テーブルのデータ構造の一例を示すデータ構成図である。なお、この役職テーブルは、ワークフローを利用するための役職の情報を記憶するためのものである。
【００４３】
図７に示すように、役職テーブルの各レコードは、ユーザテーブル内で定義されている「ユーザＩＤ」，役割テーブル内で定義されている「役割ＩＤ」，組織テーブル内で定義されている「組織ＩＤ」で構成されている。
【００４４】
図８は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される配送定義情報のデータ構造の一例を示すデータ構成図である。なお、この配送定義情報は、伝票が配送される経路を定義した情報を記憶するためのものである。
【００４５】
ここでは、一例として役割が「社員」→「部長」→「本部長」→「事業本部長」→「社長」の順に伝票配送をする例を示している。このように伝票の配送経路を定義した場合、この配送経路の配送定義情報は、図８に示すような５レコードの情報として作成される。
【００４６】
以下、配送定義情報の作成方法について説明する。
【００４７】
例えば、伝票名が「交際費」の場合、まず、ユーザがワークフロー及び伝票設計用端末４００から、システム管理プログラムを用いて、伝票名に「交際費」と設定し、次に、各ノードを設定する。ノード１を例にすると、ノード１に役割ＩＤに部長を示すコード「００４」を設定し、対象となる組織を選択（ここでは組織ＩＤ「８０」の「Ａ会社」を選択）することにより、「伝票名」が「交際費」，「組織ＩＤ」が「８０」，「ノード番号」が「１」，「経路役割ＩＤ」が「部長」を示す役割ＩＤ「００４」、「経路組織ＩＤ」が役割を担う組織ＩＤとして設定される。なお、ここでは、対象となる組織として、組織ＩＤ「８０」の「Ａ会社」が選択されており、役割ＩＤ「部長」を持つ配送対象者は決定されない。そのため、経路組織ＩＤは「ＮＵＬＬ」となっている（図中では空白で示している）。
【００４８】
図９は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される配送情報テーブルのデータ構造の一例を示すデータ構成図である。なお、この配送情報テーブルは、後述する図１０に示すワークフローシステムにおける配送処理時に図８に示した配送定義情報に基づいて生成されるものであり、ワークフローの経路，状態等を記憶するためのものである。また、この配送情報テーブルは、特に、ユーザＩＤ「Ｕ００１２」のユーザが起票した場合に対応する。この場合、伝票は、ユーザＩＤ「Ｕ００１２」，「Ｕ０００７」，「Ｕ０００３」，「Ｕ０００２」，「Ｕ０００１」のように配送されることとなる。
【００４９】
図９に示すように、配送情報テーブルは、「伝票名」項目５０１、「伝票番号」項目５０２、「ノード番号」項目５０３、「処理ユーザ」項目５０４、「状態」項目５０５、「最終処理日付け」項目５０６、「決済完了希望」項目５０７、「決済完了希望日」項目５０８、「代行済」項目５０９等の項目を含む。
【００５０】
「伝票名」項目５０１には、"交際費"等の伝票名そのものが起票時に格納される。「伝票番号」項目５０２には、伝票を識別するための識別子が起票示に格納される。「処理ユーザ」項目５０４には、「ノード番号」項目５０３に対応する処理者のユーザＩＤが格納される。「状態」項目５０５には、"処理待ち"や"処理済"等の状態を示す情報が格納される。「最終処理日付け」項目５０５には、「ノード番号」項目５０３に対応するノードを処理した日時が格納される。
【００５１】
なお、「決済完了希望」項目５０７、「決済完了希望日」項目５０８、「代行済」項目５０９については、後述する。
【００５２】
以下、図１０を参照して、本発明のワークフローシステムにおける配送処理手順の全体の流れについて説明する。
【００５３】
図１０は、本発明のワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートであり、図１に示したワークフローサーバ２００のワークフロープログラム２０４による配送処理に対応する。なお、図中、Ｓ５０００〜Ｓ５０１３は各ステップを示す。
【００５４】
まず、ワークフロープログラム２０４を実行するワークフローサーバ２００のＣＰＵ（以下、ワークフローサーバ２００のＣＰＵ）が、ワークフロー操作用端末３００より伝票処理要求を受信すると（ステップＳ５０００）、配送処理を開始する。
【００５５】
ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分である「起票」，「承認」，「否認」に基づいて、配送処理を切り替えていく（ステップＳ５００１）。
【００５６】
ステップＳ５００１において、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「起票」であると判定した場合には、ステップＳ５００２において、ワークフローサーバ２００のＣＰＵは、起票時の情報として、ノード番号「０」を配送情報テーブルに設定する。「処理ユーザ」には、起票したユーザのユーザＩＤを設定する。
【００５７】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、図８に示したように、配送情報テーブルのノード番号「０」のレコードに、伝票名に「交際費」、伝票番号を起票時に発行される伝票番号（ここでは「００００１」とする）、ノード番号に「０」、処理ユーザを起票ユーザのユーザＩＤ「Ｕ００１２」、状態に「処理済」を設定する。
【００５８】
次に、ステップＳ５００３において、ワークフローサーバ２００のＣＰＵは、現在のノード番号を「１」とし、ステップＳ５０００で受信した伝票処理要求の伝票名に対応する配送定義情報（図８）を参照し、ノード番号「１」の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００５９】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」を取得する。
【００６０】
一方、ステップＳ５００１で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」又は「否認」であると判定した場合には、ステップＳ５００４において、ワークフローサーバ２００のＣＰＵは、配送情報テーブル（図９）を参照して現在のノード番号を取得する。
【００６１】
次に、ステップＳ５００５において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」であるか「否認」であるかを判定し、「承認」であると判定した場合には、ステップＳ５００６において、ステップＳ５００４で取得した現在のノード番号をインクリメントした後、該インクリメントした現在のノード番号を持つ配送定義情報（図８）を参照し、該現在のノード番号の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００６２】
一方、ステップＳ５００５で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「否認」であると判定した場合には、ステップＳ５００７において、ステップＳ５００４で取得した現在のノード番号をデクリメントした後、該デクリメントした現在のノード番号を持つ配送定義情報（図８）を参照し、該現在のノード番号の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００６３】
そして、ステップＳ５００８において、ワークフローサーバ２００のＣＰＵは、ステップＳ５００３、Ｓ５００６、又はＳ５００７で取得した経路役割ＩＤ，経路組織ＩＤを用いて、ユーザ役職情報（図７）を参照して次の配送対象ユーザＩＤを決定する（役職テーブル（図７）から役割ＩＤが経路役割ＩＤで、組織ＩＤが経路組織ＩＤのユーザＩＤを決定する）。なお、取得した経路組織ＩＤが「ＮＵＬＬ」の場合（図８の空白の場合）には、現在のノード番号より１つ小さいノード番号に対応するユーザＩＤの属する組織ＩＤを「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定するものとする。さらに、これでも次の配送対象ユーザＩＤを決定することができない場合（ユーザ役職情報（図７）に、役割ＩＤが経路役割ＩＤで、組織ＩＤが経路組織ＩＤのレコードが存在しない場合）には、該組織ＩＤの親組織ＩＤを「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定するものとし、次の配送対象ユーザＩＤが決定するまでこの処理を繰り返すものとする。
【００６４】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、図９に示したように、ステップＳ５００３で、ノード番号「１」の経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」が取得され、該取得された経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」に基づいて配送対象となるユーザＩＤが決定される。ここで、取得した経路組織ＩＤが「ＮＵＬＬ」であるため、現在のノード番号「１」より１つ小さいノード番号「０」に対応するユーザＩＤ「Ｕ００１２」の属する組織ＩＤ「８０１０１０１０１０」を「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定する。このとき、ユーザ役職情報（図７）に、役割ＩＤ「００４」で、組織ＩＤ「８０１０１０１０１０」のレコードが存在しないため、組織ＩＤ「８０１０１０１０１０」の親組織ＩＤ「８０１０１０１０」を「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定する。ここで、ユーザ役職情報（図７）を参照すると、役割ＩＤ「００４」で、組織ＩＤ「８０１０１０１０１０」のユーザＩＤは「Ｕ０００７」となり、このユーザＩＤ「Ｕ０００７」が次の配送対象ユーザＩＤに決定される。
【００６５】
次に、ステップＳ５００９において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものであるか否かを判定する。最終承認者は、図８のノード番号の最大値のレコードに該当する役割ＩＤの承認者からの承認であるかを判定するものとし、元々の最終承認者が委任（代行）ありの場合は、更にその上長とする。
【００６６】
ステップＳ５００９で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものでないと判定した場合には、ステップＳ５０１１において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」又は「起票」であるか「否認」であるかを判定し、「承認」又は「起票」であると判定した場合には、ステップＳ５０１２において、配送情報テーブル（図９）に次のノード番号の情報を設定する。この時、「ノード番号」項目５０３には現在のノード番号を設定し、「処理ユーザ」項目５０４にはステップＳ５００９で決定された次の配送対象ユーザＩＤを設定し、「状態」項目５０５には"処理待ち"を設定し、「最終処理日付け」項目５０６には現在の日時を設定する。そして、ワークフローサーバ２００のＣＰＵは、ＳＭＴＰサーバ２０３により配送対象者にワークフロー通知を行い、処理を終了する。
【００６７】
一方、ステップＳ５０１１で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「否認」であると判定した場合には、ステップＳ５０１３において、配送情報テーブル（図９）から上記現在ノード番号を削除するとともに、ＳＭＴＰサーバ２０３により配送対象者に否認された旨のワークフロー通知を行い、処理を終了する。
【００６８】
一方、ステップＳ５００９で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものであると判定した場合には、ステップＳ５０１０において、配送情報テーブル（図９）から当該配送情報を削除するとともに、ＳＭＴＰサーバ２０３により起票者に全て承認された旨のワークフロー通知を行い、処理を終了する。
【００６９】
以下、図１１〜図１９を用いて本実施形態における長期滞留時の処理について説明する。
【００７０】
図１１は、本実施形態における決裁完了希望期限付きの電子文書（伝票）の一例を示す図であり、起票時に、ワークフロー操作用端末３００の表示装置に表示され、ワークフロー操作用端末３００の入力装置により入力指示可能である。
【００７１】
図１１に示すように、決裁完了希望期限付きの電子文書は、通常の電子文書に決裁完了希望無のチェックボックス６０１，決裁完了希望有のチェックボックス６０２を配置する。この決裁完了希望無のチェックボックス６０１，決裁完了希望有のチェックボックス６０２は、排他的にチェック「ＯＮ」可能である。
【００７２】
希望有チェックボックスが「ＯＮ」の場合は、決裁完了希望日を決裁完了希望日入力欄６０３に入力する。
【００７３】
この伝票が起票されると、ワークフローサーバ２００のＣＰＵは、通常の電子文書に決裁完了希望無のチェックボックス６０１，決裁完了希望有のチェックボックス６０２の情報を、図９に示した配送情報テーブルの「決済完了希望の有無」項目５０７に格納する。また、ワークフローサーバ２００のＣＰＵは、決裁完了希望日入力欄６０３の情報を、図９に示した配送情報テーブルの「決裁完了希望日」項目５０８に格納する。なお、この処理は、図１０のステップＳ５００２で実行される。
【００７４】
図１２は、本実施形態における電子文書の配送経路上の決裁担当者のスケジュールデータを示した図である。
【００７５】
なお、この決裁担当者のスケジュールデータは、一般的なスケジュール管理ソフトウェアを用いて入力された担当者のスケジュール情報を、本代行決裁業務向けに外部データとして取り込み、加工したものであり、ワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される。
【００７６】
この決裁担当者のスケジュールデータは、決済完了希望のある伝票が起票されると、該伝票の配送情報テーブルに基づいて、該起票された伝票毎に、ワークフローサーバ２００により作成されるものである。
【００７７】
図１２において、この決裁担当者のスケジュールデータは、担当者欄７０１，日程欄７０２等から構成される。
【００７８】
担当者欄７０１には、配送経路上の承認担当者を特定する情報（ユーザ名やユーザＩＤ等）が格納される。また、日程欄７０２には、起案日（起票日）から決裁完了希望日までの日程が格納される。なお、決裁完了希望日がない場合は所定期間（例えば２週間）分の日程が格納される。
【００７９】
ワークフローサーバ２００のＣＰＵは、起票された伝票の配送情報テーブルに基づいて、配送経路上の各承認担当者を決定し、該各承認担当者を特定する情報（ユーザ名やユーザＩＤ等）を取得し、担当者欄７０１に格納する。また、ワークフローサーバ２００のＣＰＵは、担当者欄７０１に格納した各承認担当者の日程を、一般的なスケジュール管理ソフトウェアから取得して、日程欄７０２に格納する。その際、終日外出の日、半日外出または半日以上連続した打ち合わせのある日、前記以外の日の３種類に分類して格納する。なお、スケジュールが未定の場合はＮｕｌｌを格納する。
【００８０】
本実施形態は、終日外出の日は７０３のように「×」印で示す。また、半日外出または半日以上連続した打ち合わせのある日は７０４のように「△」印で示す。上記以外の日は７０５のように「○」印で示す。なお、スケジュールが未定の場合は７０６に示すように空白で示す。
【００８１】
図１３は、電子文書の承認・決裁処理が所定の滞留期限を超過し、上長への代行決裁の設定ができなかった場合に、そのことを通知するシステム管理者の宛先を一覧表示する画面である。この画面は、ワークフローサーバ２００に管理者モードでログインして、システム管理者宛先一覧の表示を指示することにより、ワークフロー操作用端末３００の表示画面上に表示される。
【００８２】
このシステム管理者宛先一覧では、ワークフローサーバ２００のＲＤＢＭＳ２０５に登録されているシステム管理者テーブル内の情報が表示される。
【００８３】
このシステム管理者宛先一覧には、管理者の名称８０１、管理者のメールアドレス８０２、管理対象組織８０３、当該組織における滞留を容認する期間を示す滞留期間８０４が表示される。
【００８４】
そして、このシステム管理者宛先一覧に登録されているシステム管理者テーブルの情報を変更する場合は、編集ボタン８０５、新規追加する場合は新規ボタン８０６、削除する場合は削除ボタン８０７、システム管理者登録機能を終了するときは、閉じるボタン８０８を押下する。これにより、ワークフローサーバ２００のＣＰＵは、対応する処理を行うように制御する。
【００８５】
なお、編集ボタン８０５又は新規ボタン８０６を押下した場合は、ワークフローサーバ２００のＣＰＵは、図9のシステム管理者設定画面をワークフロー操作用端末３００の表示装置に表示させる。
【００８６】
システム管理者一覧画面の例として、図８のように、システム管理者毎に滞留期間８０４を設定する構成について示したが、滞留期間８０４は伝票の種別ごとに設定可能であってもよい。このシステム管理者一覧画面で編集されたシステム管理者テーブルは、ワークフローサーバ２００のＲＤＢＭＳ２０５に登録される。
【００８７】
図１４は、本実施形態におけるシステム管理者設定画面の一例を示す図である。
【００８８】
このシステム管理者設定画面は、管理者の名称９０１、管理者メールアドレス９０２、滞留期間９０３、対象組織９０４の各入力欄を有し、既登録の情報を編集する場合は各入力欄に既登録情報が表示され、新規登録する場合は各入力欄は空欄表示される。
【００８９】
上記各入力欄９０１〜９０４に各情報が入力され、登録ボタン９０５が押下されると、ワークフローサーバ２００のＣＰＵは、該情報をＲＤＢＭＳ２０５内のシステム管理者テーブルに登録し、図１３に示したシステム管理者宛先一覧に画面を戻す。なお、対象組織９０４は、リストボックスから該当組織を選択可能である。
【００９０】
また、取消ボタン９０６が押下されると、ワークフローサーバ２００のＣＰＵは、各入力欄９０１〜９０４への入力情報をキャンセルし、図１３に示したシステム管理者宛先一覧に画面を戻す。
【００９１】
また、システム管理者は、全組織で1人を指定することも、１又は複数部門ごとに１人を指定して全組織で複数人数指定することも可能である。
【００９２】
以下、図１５，図１６を参照して、本発明のワークフローシステムにおける決裁未処理電子文書の滞留を検知する処理の流れについて説明する。
【００９３】
図１５は、本発明のワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートであり、図１に示したワークフローサーバ２００のワークフロープログラム２０４による決裁未処理電子文書の滞留検知処理に対応する。なお、図中、Ｓ１００１〜Ｓ１０１３は各ステップを示す。
【００９４】
まず、ワークフロープログラム２０４を実行するワークフローサーバ２００のＣＰＵ（以下、ワークフローサーバ２００のＣＰＵ）は、所定の期間が経過すると（定期的に）、ステップＳ１００１において、配送情報テーブルを検索（チェック）する。
【００９５】
ワークフローサーバ２００のＣＰＵは、ステップＳ１００２において、配送情報テーブルの「状態」項目５０５を確認し、状態が"処理済"ならば、処理を終了させる。また、フローチャートには示していないが「代行済」項目５０９"済"の場合も処理を終了させる。
【００９６】
一方、ステップＳ１００２で、配送情報テーブルの「状態」項目５０５が"処理待ち"と判断した場合には、ステップＳ１００３に処理を進め、その伝票を「処理ユーザ」項目５０４内のユーザＩＤに基づいて役職テーブルを検索して組織コードを取得する。また、その伝票の「最終処理日付」項目５０６の情報も取得する。
【００９７】
次に、ステップＳ１００４において、ワークフローサーバ２００のＣＰＵは、当該伝票が決裁完了希望日付き電子文書であるか、配送情報テーブルの「決済完了希望」項目５０６内の情報から判断する。
【００９８】
当該伝票が決裁完了希望日付き電子文書でないと判断した場合には、ステップＳ１００５において、ワークフローサーバ２００のＣＰＵは、ステップＳ１００３で取得した組織コードに基づいてシステム管理者テーブル内の滞留期間の情報を取得する。さらに、ワークフローサーバ２００のＣＰＵは、現在日時と処理待ち開始日時（最終処理日付）との差分を滞留猶予期間とし、ステップＳ１００７に処理を進める。
【００９９】
一方、ステップＳ１００４で、当該伝票が決裁完了希望日付き電子文書であると判断した場合には、ステップＳ１００６において、ワークフローサーバ２００のＣＰＵは、決裁完了希望日までの所要日数と全ノード通過日数の差分を滞留猶予期間とし、ステップＳ１００７に処理を進める。以下、詳細に説明する。まず、決裁完了希望日までの所要日数は「決裁完了希望日−現在日時」となる。また、１つの決裁ノード通過に「１＋α」日要すると仮定すると（αは補正値であり、組織の状態に応じて適宜定める）、全ノード通過日数は、「（全ノード数−現在ノード）×（１＋α）」と算出される。よって、滞留猶予期間は「（決裁完了希望日−現在日時）−（全ノード数−現在ノード）×（１＋α）」と算出される。
【０１００】
次に、ステップＳ１００７において、ワークフローサーバ２００のＣＰＵは、ステップＳ１００５又はＳ１００６で算出した滞留猶予期間と、管理者テーブル内の滞留期間とを比較して、滞留オーバであるか否かを判定する。
【０１０１】
ステップＳ１００７で、滞留オーバでない（ステップＳ１００５又はＳ１００６で算出した滞留猶予期間が管理者テーブル内の滞留期間を超えていない）と判断した場合には、ワークフローサーバ２００のＣＰＵは、そのまま処理を終了させる。
【０１０２】
一方、ステップＳ１００７で、滞留オーバ（ステップＳ１００５又はＳ１００６で算出した滞留猶予期間が管理者テーブル内の滞留期間を超えている）と判断した場合には、ワークフローサーバ２００のＣＰＵは、ステップＳ１００８において、配送経路上の代行承認可能な上長を選択する（詳細は図１６に示す）。
【０１０３】
次に、ステップＳ１００９において、ワークフローサーバ２００のＣＰＵは、ステップＳ１００８の処理で、配送経路上に代行承認可能な上長が存在したか否かを判定し、存在したと判断した場合には、ステップＳ１０１１に処理を進める。
【０１０４】
ステップＳ１０１１において、ワークフローサーバ２００のＣＰＵは、ユーザテーブルから当該上長のメールアドレスを取得する。
【０１０５】
次に、ステップＳ１０１２において、ワークフローサーバ２００のＣＰＵは、ステップＳ１０１１で取得したメールアドレスに対して承認代行依頼を通知する電子メールを生成し送信するとともに、ステップＳ１００８で選択された上長を承認代行者としてセットする。即ち、ステップＳ１００８で選択された上長のユーザＩＤを配送情報テーブル内の現在滞留しているノード番号の「処理ユーザ」項目５０４にセットし、さらに「代行済」項目５０９に"済"をセットする。そして、本フローチャートの処理を終了する。
【０１０６】
一方、ステップＳ１０１２において、ワークフローサーバ２００のＣＰＵは、ステップＳ１００８の処理で配送経路上に代行承認可能な上長が存在しなかったと判断した場合には、ステップＳ１０１０において、ステップＳ１００３で取得した組織コードに基づいてシステム管理者テーブルを検索し、システム管理者のメールアドレスを取得する。
【０１０７】
次に、ステップＳ１０１３において、ワークフローサーバ２００のＣＰＵは、ステップＳ１０１０で取得したシステム管理者のメールアドレスに対して、当該電子文書の承認・決済処理が滞留している旨を知らせる電子メールを生成して送信する。さらに、ワークフローサーバ２００のＣＰＵは、ワークフローサーバ２００のＲＤＢＭＳ２０５内の承認・決裁滞留伝票一覧テーブル（図１７）の「対象組織」項目１７０１，「伝票番号」項目１７０２，「ノード番号」項目１７０３，「滞留時間」項目１７０４に、ステップＳ１００３で取得した組織コード，当該滞留伝票の伝票番号，当該滞留ノード番号，ステップＳ１００５又はＳ１００６で算出した滞留猶予期間をそれぞれ格納して、承認・決裁滞留伝票一覧テーブルを更新する。そして、本フローチャートの処理を終了する。
【０１０８】
図１６は、本発明のワークフローシステムにおける第３の制御処理手順の一例を示すフローチャートであり、図１５のステップＳ１００８の配送経路上の代行承認可能な上長を選択する処理に対応する。なお、図中、Ｓ１１０１〜Ｓ１１０７は各ステップを示す。
【０１０９】
まず、ワークフローサーバ２００のＣＰＵは、ステップＳ１１０１において、当該承認者の直近の上長を当該伝票の配送経路上から選択する。
【０１１０】
次に、ステップＳ１１０２において、ワークフローサーバ２００のＣＰＵは、ステップＳ１１０１で選択した上長の承認スケジュールについて、終日外出の日（×印）はコストを「１日」とし、半日外出または半日以上連続した打ち合わせのある日（△印）はコストを「０．５日」とし、上記以外の日（○印）はコストを「０日」とし、さらに、組織の環境を加味した補正値を「α」とし、これを各コストに加算し、半日外出または半日以上連続した打ち合わせのある日（△印）または上記以外の日（○印）が出現するまで、上記コストを加算した総和を、当該承認代行者の決裁処理予定日（決裁予定コスト）とする。
【０１１１】
次に、ステップＳ１１０３において、ワークフローサーバ２００のＣＰＵは、ステップＳ１１０２で算出した決裁処理予定コストが図１５のステップＳ１１０５又はＳ１００６で算出さいた滞留猶予予定日以内であるか判断し、滞留猶予予定日以内であると判断した場合には、ステップＳ１１０７に処理を進める。
【０１１２】
そして、ステップＳ１１０７において、ワークフローサーバ２００のＣＰＵは、当該上長を決裁代行者（代行承認可能な上長）として選択し、処理を終了する。
【０１１３】
一方、ステップＳ１１０３で、ワークフローサーバ２００のＣＰＵは、ステップＳ１１０２で算出した決裁処理予定コストが図１５のステップＳ１１０５又はＳ１００６で算出さいた滞留猶予予定日以内でない（滞留猶予予定日を超過する）と判断した場合には、ステップＳ１１０４に処理を進める。
【０１１４】
次に、ステップＳ１１０４において、ワークフローサーバ２００のＣＰＵは、当該伝票の配送経路上の全ての上長を検査したか否かを判定し、まだ検査していない上長がいると判断した場合には、ステップＳ１１０５において、次の上長を選択し、ステップＳ１１０２に処理を戻す。
【０１１５】
一方、ステップＳ１１０４で、ワークフローサーバ２００のＣＰＵは、当該伝票の配送経路上の全ての上長を検査したと判断した場合には、ステップＳ１１０６において、該当伝票を代行承認可能な上長不在として、処理を終了する。
【０１１６】
なお、ステップＳ１１０２で用いた補正値「α」は、組織の環境や伝票の種別等により変更可能に構成してもよい。
【０１１７】
図１７は、本実施形態における滞留伝票情報テーブルの一例を示す図である。
【０１１８】
なお、この滞留伝票情報テーブルは、ワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される。
【０１１９】
滞留伝票情報テーブルは、「対象組織」項目１７０１，「伝票番号」項目１７０２，「ノード番号」項目１７０３，「滞留時間」項目１７０４を含む。
【０１２０】
以下、図１８，図１９を参照して、本発明のワークフローシステムにおける処理が滞留している伝票にシステム管理者が代行者を設定する処理の流れについて説明する。
【０１２１】
図１８は、本実施形態において承認・決裁滞留伝票一覧で表示した画面を示す図である。
【０１２２】
この画面は、システム管理者がワークフロー操作用端末３００からワークフローサーバ２００にログインすると、ワークフローサーバ２００は、該システム管理者に対応する組織コードに基づいて、図１７に示した滞留伝票情報テーブルを検索し、対応する滞留伝票情報を取得する。そして、ワークフローサーバ２００は、取得した滞留伝票情報に基づいて、承認・決裁滞留伝票一覧画面を生成し、システム管理者のワークフロー操作用端末３００に送信する。これにより、システム管理者のワークフロー操作用端末３００は承認・決裁滞留伝票一覧画面を表示装置に表示する。
【０１２３】
この承認・決裁滞留伝票一覧画面には、承認もしくは決裁の処理が滞留している伝票の伝票番号１３０２、ノード番号１３０３、処理ユーザ１３０４、状態１３０５、滞留時間１３０６が表示される。なお、各伝票には、承認チェック欄１３０１，代行者設定欄１３０７が設けられている。
【０１２４】
システム管理者は、この承認・決裁滞留伝票一覧画面を用いて滞留している処理を代行するユーザを設定する。まず、代行者を設定する伝票の承認チェック欄１３０１にチェックを入れ、代行者設定欄１３０７に処理を代行するユーザのメールアドレスを入力する。
【０１２５】
なお、一度に複数の伝票に対して代行者の設定をすることが可能である。全ての設定が完了したら実行ボタン１３０８を押下する。また、この承認・決裁滞留伝票一覧画面を閉じる時には、閉じるボタン１３０９を押下する。
【０１２６】
実行ボタン１３０８が押下されると、当該ワークフロー操作用端末３００から、この画面の情報がワークフローサーバ２００に送信される。そして、これを受信したワークフローサーバ２００は、図１９に示す処理を開始する。
【０１２７】
図１９は、本発明のワークフローシステムにおける第４の制御処理手順の一例を示すフローチャートであり、図１に示したワークフローサーバ２００のワークフロープログラム２０４による処理が滞留している伝票にシステム管理者が代行者を設定する処理に対応する。なお、図中、Ｓ１４０１〜Ｓ１４１０は各ステップを示す。
【０１２８】
システム管理者によりワークフロー操作用端末３００で図１８に示した承認・決裁滞留伝票一覧画面で処理代行者が設定され、実行ボタン１３０８が押下されると、滞留案件の情報（図１８の情報）がワークフローサーバ２００に送信される。すると、ステップＳ１４０１において、ワークフロープログラム２０４を実行するワークフローサーバ２００のＣＰＵ（以下、ワークフローサーバ２００のＣＰＵ）は、ワークフロー操作用端末３００より滞留案件の情報を取得する。
【０１２９】
次に、ステップＳ１４０２において、ワークフローサーバ２００のＣＰＵは、まず、滞留案件の情報に承認チェック欄１３０１に承認チェックが入力されている案件があるか否かを判定し、承認チェックが入力されている案件がないと判断した場合には、処理を終了する。
【０１３０】
一方、ワークフローサーバ２００のＣＰＵは、承認チェックが入力されている案件があると判断した場合には、ステップＳ１４００３に処理を進める。
【０１３１】
ステップＳ１４０３において、ワークフローサーバ２００のＣＰＵは、滞留案件の情報の承認チェック欄１３０１に承認チェックが入力されている案件の代行者設定欄１３０７に代行者のメールアドレスが入力されている案件があるか否かを判定する。
【０１３２】
そして、ステップＳ１４０３において、ワークフローサーバ２００のＣＰＵは、代行者設定欄１３０７に代行者のメールアドレスが入力されている案件がないと判断した場合には、ステップＳ１４０７に処理を進め、代行者アドレスを入力するようメッセージをワークフロー操作用端末３００に送信して画面表示させ、処理を終了する。
【０１３３】
一方、ステップＳ１４０３で、ワークフローサーバ２００のＣＰＵは、滞留案件の情報の承認チェック欄１３０１に承認チェックが入力されている案件の代行者設定欄１３０７に代行者のメールアドレスが入力されている案件があると判断した場合には、ステップＳ１４０４に処理を進める。
【０１３４】
ステップＳ１４０４において、ワークフローサーバ２００のＣＰＵは、代行者に対して処理を依頼するメールを作成し、送信する。なお、送信するメールには、伝票番号、ノード番号、処理ユーザ、滞留時間などの代行処理の情報を含める。
【０１３５】
代行処理依頼のメールを送付後、ステップＳ１４０５において、ワークフローサーバ２００のＣＰＵは、代行者に対して伝票処理依頼を送信する。ワークフローサーバ２００のＣＰＵは、該代行者を当該滞留しているノード番号の「処理ユーザ」項目５０４にセットし、さらに「代行済」項目５０９に"済"をセットする。
【０１３６】
そして、ステップＳ１４０６において、ワークフローサーバ２００のＣＰＵは、承認・決裁滞留伝票情報テーブル（図１７）から該当の伝票番号とノード番号の行を削除して更新した滞留伝票一覧画面をワークフロー操作用端末３００に送信して画面更新させる。そして、本フローチャートを終了する。
【０１３７】
以上の処理により、ワークフロー上の正規の決裁担当者が不在であることが判明した場合にも、起案者の決裁完了希望日を満足できるよう、配送経路上の最適な代行決裁者へ代行決裁委任を行うことができ、電子文書の円滑な処理が促進できる。
【０１３８】
従って、ワークフローの滞留を防止でき、処理すべきワークフロー業務の効率化を促進することができる等の効果を奏する。
【０１３９】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０１４０】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１４１】
以下、図２０に示すメモリマップを参照して本発明に係るワークフローサーバ２００で読み取り可能なデータ処理プログラムの構成について説明する。
【０１４２】
図２０は、本発明に係るワークフローサーバ２００で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【０１４３】
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１４４】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１４５】
本実施形態における図１０，図１５，図１６，図１９に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１４６】
以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１４７】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１４８】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１４９】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１５０】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１５１】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１５２】
さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１５３】
なお、上記実施形態内で示した各変形例のいずれか又は全てを組み合わせた構成も全て本発明に含まれるものである。
【０１５４】
以上のように、ワークフローシステムにおいて、承認担当者不在等により滞留している未処理案件について、その状態をシステム管理者に通達し、前記未処理案件の長期間滞留を回避させることができる等の効果を奏する。
【図面の簡単な説明】
【０１５５】
【図１】本実施形態が適用されるワークフローシステムの概略構成を示す図である。
【図２】図１に示したワークフローサーバ，ワークフロー操作用端末，ワークフロー及び伝票設計用端末に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。
【図３】図１に示したワークフローシステムにおける伝票の流れを示す模式図である。
【図４】図１に示したワークフローサーバのＲＤＢＭＳに記憶される組織テーブルのデータ構造の一例を示すデータ構成図である。
【図５】図１に示したワークフローサーバのＲＤＢＭＳに記憶される役割テーブルのデータ構造の一例を示すデータ構成図である。
【図６】図１に示したワークフローサーバのＲＤＢＭＳに記憶されるユーザテーブルのデータ構造の一例を示すデータ構成図である。
【図７】図１に示したワークフローサーバのＲＤＢＭＳに記憶される役職テーブルのデータ構造の一例を示すデータ構成図である。
【図８】図１に示したワークフローサーバのＲＤＢＭＳに記憶される配送定義情報のデータ構造の一例を示すデータ構成図である。
【図９】図１に示したワークフローサーバのＲＤＢＭＳに記憶される配送情報テーブルのデータ構造の一例を示すデータ構成図である。
【図１０】本発明のワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートである。
【図１１】本実施形態における決裁完了希望期限付きの電子文書（伝票）の一例を示す図である。
【図１２】本実施形態における電子文書の配送経路上の決裁担当者のスケジュールデータを示した図である。
【図１３】電子文書の承認・決裁処理が所定の滞留期限を超過し、上長への代行決裁の設定ができなかった場合に、そのことを通知するシステム管理者の宛先を一覧表示する画面である。
【図１４】本実施形態におけるシステム管理者設定画面の一例を示す図である。
【図１５】本発明のワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。
【図１６】本発明のワークフローシステムにおける第３の制御処理手順の一例を示すフローチャートである。
【図１７】本実施形態における滞留伝票情報テーブルの一例を示す図である。
【図１８】本実施形態において承認・決裁滞留伝票一覧で表示した画面を示す図である。
【図１９】本発明のワークフローシステムにおける第４の制御処理手順の一例を示すフローチャートである。
【図２０】本発明に係るワークフローサーバ２００で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【符号の説明】
【０１５６】
２００ ワークフローサーバ
２０４ ワークフロープログラム
２０５ ＲＤＢＭＳ
３００ ワークフロー操作用端末
１０１ ＣＰＵ
１０２ ＲＡＭ
１０３ ＲＯＭ
１０４ ＨＤ
【技術分野】
【０００１】
本発明は、ワークフローシステムにおいて、承認担当者不在等により滞留している未処理案件である滞留電子文書の処理に関する。
【背景技術】
【０００２】
電子文書の承認業務の効率を向上させるインフラの１つとして、ワークフローシステムがある。
【０００３】
ワークフローシステムは、組織または役割、もしくはユーザという個人単位の配布者を設定し、配布者間の電子文書の配布ルート（配布順序）を予めワークフローサーバに登録しておき、この順序に従って自動的に電子文書を配布しようとするものである。
【０００４】
多くのワークフローシステムでは、電子文書の配布先となった決裁担当者が不在となる場合、同等の役割をもつ担当者を事前に決裁代行者として設定し、決裁担当者に配布されるべき電子文書を該代行者が代わって受信し、業務処理を代行することで業務停滞を回避させている。
【０００５】
しかし、現実の運用においては、ワークフロー上の正式な決裁担当者の突発的な所用、例えば病気や緊急出張等があったため、代行担当者を設定することなく不在にしてしまい、結果、長期間の電子文書の滞留を引き起こしていた。
【０００６】
このような問題を解決するための提案としては、特開平１１-２１９３９３がある。
【０００７】
これは、ワークフロー上の決裁担当者に代わって、決裁担当者による代行担当者を予め設定しておき、ワークフロー上の決裁担当者に対して処理が依頼されている電子文書について、予め設定された処理期間内に処理が完了しているか否かを所定のタイミングで判定し、滞留と判断された場合に、決裁担当者に代わる代行担当者に対し、当該電子文書の処理を依頼するための電子メールを生成して送信するというものである。
【０００８】
これにより、ワークフロー上の正規の担当者が不在の場合でも、システム側で代行担当者に電子文書処理を依頼することができる。
【特許文献１】特開平１１-２１９３９３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら上述のワークフローシステムは、ワークフロー上の正規の業務担当者が長期不在により電子文書が滞留したことが判明した段階で、予め定めた決裁代行担当者に電子文書の処理依頼メールを送信し、代行を促す手法であるため、決裁担当者と代行担当者が同時期に急遽、長期不在となった場合、やはり、長期間、業務案件を滞留させてしまうことになり、電子文書の円滑な処理を損なうことになる。
【００１０】
また、同じ電子文書でも、たとえば社内稟議書や人事異動申請書といった重要な電子文書の場合、予め設定された決裁代行者に無条件に配送したのでは不都合が発生する場合もある。
【００１１】
そもそも、決裁代行者への配送はワークフロー上の正規の決裁担当者が明示的に代行委任設定を行ったときに限り行うべきものであり、突発的な事由による電子文書の滞留の場合には、当該事案の代行決裁は上長に委ねた方がセキュリティの観点からも無難な場合が多い。
【００１２】
決裁担当者不在時の代行決裁者を電子文書配送経路上の直属の上長とした場合、該上長の長期不在においては、やはり電子文書の決裁業務が滞るという問題が考えられる。
【００１３】
また、配送経路上のすべての上長の中で長期不在でない上長を決裁代行者として委任した場合にも、代行決裁者のスケジュールによっては、該上長への代行決裁では、起案者の決裁完了希望日までに決裁が完了できないという問題が考えられる。
【００１４】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、次の承認・決裁者による電子文書のワークフロー処理が所定の滞留期限を超過している滞留電子文書を検知し、該検知された滞留電子文書の配送経路上で次の承認・決裁者の上長にあたる承認・決裁者のスケジュールを参照し、該上長にあたる参照した承認・決裁者のスケジュールと、前記滞留期限とに基づいて決裁代行者として委任設定する上長を決定することにより、ワークフロー上の正規の決裁担当者が不在であること等が判明した場合にも、起案者の決裁完了希望日を満足できるよう、配送経路上の最適な代行決裁者へ代行決裁委任を行うことができ、電子文書の円滑な処理が促進できるようにする仕組を提供することである。
【課題を解決するための手段】
【００１５】
本発明は、所定の配送経路に従って電子文書を回覧して承認・決裁のワークフロー処理を行うワークフローシステムにおいて、承認・決裁者の組織情報，承認・決裁者のスケジュールを記憶する記憶手段と、次の承認・決裁者による電子文書のワークフロー処理が所定の滞留期限を超過している滞留電子文書を検知する滞留検知手段と、前記滞留検知手段で検知された滞留電子文書の配送経路上で次の承認・決裁者の上長にあたる承認・決裁者のスケジュールを参照し、該上長にあたる参照した承認・決裁者のスケジュールと、前記滞留期限とに基づいて決裁代行者として委任設定する上長を決定制御する制御手段とを有することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、ワークフローの滞留を防止でき、処理すべきワークフロー業務の効率化を促進することができる。
【００１７】
従って、ワークフローシステムにおいて、承認担当者不在等により滞留している未処理案件を、その状態をシステム管理者に通達し、長期間滞留を回避させることができる等の効果を奏する。
【発明を実施するための最良の形態】
【００１８】
〔第１実施形態〕
以下、図面を参照して、本発明の詳細を説明する。
【００１９】
図１は、本実施形態が適用されるワークフローシステムの概略構成を示す図である。
【００２０】
本実施形態におけるワークフローシステムは、ワークフロー及び伝票設計用コンピュータ端末（ワークフロー及び伝票設計用端末）４００、業務を遂行する処理者（担当者）に対応して設けられたワークフロー操作用コンピュータ端末（ワークフロー操作用端末）３００、ワークフローを実行するための各種テーブル，各種プログラムを格納するワークフローサーバ２００を備えている。
【００２１】
これらワークフロー及び伝票設計用端末４００，ワークフロー操作用端末３００，ワークフローサーバ２００は、それぞれネットワーク５００に接続され運用されている。
【００２２】
ワークフロー及び伝票設計用端末４００は、伝票デザイナプログラム４０１及びシステム管理プログラム４０２を有し、ワークフローサーバ２００上の図示しない管理プログラムと通信して、ワークフローシステムにて使用する伝票の定義体の作成及びワークフローシステムで利用する各種定義情報の作成を行う。例えば、ワークフロー及び伝票設計用端末４００は、ワークフローサーバ２００に組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，各種伝票情報等を登録することができる。このワークフロー及び伝票設計用端末４００は、これらの作業を行うために、自己の識別情報を入力することによりワークフローサーバ２００に接続することが可能になる。
【００２３】
ワークフロー操作用端末３００は、ワークフロー操作用端末３００上で実行されるＷｅｂブラウザ３０１を用いて、伝票に関するアクセス情報をワークフローサーバ２００に対してＨＴＴＰで送信し、その結果を受信するものであり、その際に、発生する表示・計算処理は、Ｊａｖａ（登録商標）アプレット３０２等を利用することにより実行する。なお、このワークフロー操作用端末３００は、予め指定された所定の業務を行う担当者（例えば、起票者、課長、部長等）に配置されている。
【００２４】
ワークフローサーバ２００は、ワークフローシステムに関する情報（組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，配送情報テーブル，決裁担当者のスケジュールデータ，システム管理者テーブル等）を格納するＲＤＢＭＳ（Relational DataBaSe Management System）２０５、ワークフロー操作用コンピュータ端末よりの要求を受け付けて要求を実行するためのＨＴＴＰサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０４、ワークフロー通知機能を実現するＳＭＴＰサーバ２０３にて構成されている。
【００２５】
なお、ワークフローサーバ２００は、外部ＤＢに格納された所定のスケジュール情報（一般的なスケジュール管理ソフトウェアを用いて入力された各ユーザのスケジュール情報）を取得可能である。
【００２６】
以下、図２を参照して、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成について説明する。
【００２７】
図２は、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。
【００２８】
図２において、１０１はＣＰＵで、ＲＯＭ１０３又はハードディスク（ＨＤ）（その他の記憶装置、例えば、フレキシブルディスク，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭ等どのような記憶装置であってもよい）１０４に格納されたプログラムをＲＡＭ１０２上にロードして実行することにより、コンピュータ全体を制御する。ＲＡＭ１０２は、ＣＰＵ１０１の作業領域として使用される。
【００２９】
１０７は通信インタフェースで、ネットワーク５００への接続を可能とする。１０５は入力装置で、キーボードやマウス等のポインティングデバイス等に相当する。１０６は表示装置で、ＣＲＴ，ＬＣＤ等で構成される。
【００３０】
なお、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５は、ワークフローサーバ２００のＨＤ１０４内に構築されている。また、ワークフローサーバ２００のＨＴＴＰサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０４，ＳＭＴＰサーバ２０３は、ワークフローサーバ２００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００３１】
また、図１に示したワークフロー操作用端末３００のＷｅｂブラウザ３０１は、ワークフロー操作用端末３００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００３２】
さらに、図１に示したワークフロー操作用端末３００のＪａｖａ（登録商標）アプレット３０２は、ワークフロー操作用端末３００のＣＰＵ１０１が、ワークフローサーバ２００よりダウンロードされたプログラムをＷｅｂブラウザ３０１上で実行することにより、実現される。
【００３３】
また、図１に示したワークフロー及び伝票設計用端末４００の伝票デザイナプログラム４０１，システム管理プログラム４０２は、ワークフロー及び伝票設計用端末４００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００３４】
図３は、図１に示したワークフローシステムにおける伝票の流れを示す模式図である。
【００３５】
本実施形態のワークフローシステムでは、ワークフロー操作用端末３００を用いて、図３に示すように、伝票の起票，伝票の承認／否認の手続きを、ノードと呼ばれる組織と役割で定義された担当者が行う。なお、伝票が配送されるノードをひとつに括ったものをビジネスプロセスと定義する。
【００３６】
図４は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される組織テーブルのデータ構造の一例を示すデータ構成図である。なお、この組織テーブルは、ワークフローを実現するための組織に関する情報を記憶するためのものである。
【００３７】
図４に示す組織テーブルにおいて、組織ＩＤは、任意の組織名をコードとして表記したものであり、常に上位組織ＩＤを網羅している。また、組織名は、組織ＩＤの表示上の名称を示したものである。さらに、親組織ＩＤは、上位の組織ＩＤを示したものである。
【００３８】
図５は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される役割テーブルのデータ構造の一例を示すデータ構成図である。なお、この役割テーブルは、ワークフローを実現するための役割に関する情報を記憶するためのものである。
【００３９】
図５に示す役割テーブルにおいて、役割ＩＤは、任意の役割名をコードとして表記したものである。また、役割名は、役割ＩＤの表示上の名称を示したものである。
【００４０】
図６は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶されるユーザテーブルのデータ構造の一例を示すデータ構成図である。なお、このユーザテーブルは、ワークフローを利用するためのユーザの情報を記憶するためのものである。
【００４１】
図６に示すユーザテーブルにおいて、ユーザＩＤは、利用者を任意のコードとして表示したものである。また、パスワードは、ワークフローシステムにログインする際にユーザＩＤと共に認証に利用するためのものである。さらに、ユーザ名は、ユーザＩＤの表示上の名称を示したものである。
【００４２】
図７は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される役職テーブルのデータ構造の一例を示すデータ構成図である。なお、この役職テーブルは、ワークフローを利用するための役職の情報を記憶するためのものである。
【００４３】
図７に示すように、役職テーブルの各レコードは、ユーザテーブル内で定義されている「ユーザＩＤ」，役割テーブル内で定義されている「役割ＩＤ」，組織テーブル内で定義されている「組織ＩＤ」で構成されている。
【００４４】
図８は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される配送定義情報のデータ構造の一例を示すデータ構成図である。なお、この配送定義情報は、伝票が配送される経路を定義した情報を記憶するためのものである。
【００４５】
ここでは、一例として役割が「社員」→「部長」→「本部長」→「事業本部長」→「社長」の順に伝票配送をする例を示している。このように伝票の配送経路を定義した場合、この配送経路の配送定義情報は、図８に示すような５レコードの情報として作成される。
【００４６】
以下、配送定義情報の作成方法について説明する。
【００４７】
例えば、伝票名が「交際費」の場合、まず、ユーザがワークフロー及び伝票設計用端末４００から、システム管理プログラムを用いて、伝票名に「交際費」と設定し、次に、各ノードを設定する。ノード１を例にすると、ノード１に役割ＩＤに部長を示すコード「００４」を設定し、対象となる組織を選択（ここでは組織ＩＤ「８０」の「Ａ会社」を選択）することにより、「伝票名」が「交際費」，「組織ＩＤ」が「８０」，「ノード番号」が「１」，「経路役割ＩＤ」が「部長」を示す役割ＩＤ「００４」、「経路組織ＩＤ」が役割を担う組織ＩＤとして設定される。なお、ここでは、対象となる組織として、組織ＩＤ「８０」の「Ａ会社」が選択されており、役割ＩＤ「部長」を持つ配送対象者は決定されない。そのため、経路組織ＩＤは「ＮＵＬＬ」となっている（図中では空白で示している）。
【００４８】
図９は、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される配送情報テーブルのデータ構造の一例を示すデータ構成図である。なお、この配送情報テーブルは、後述する図１０に示すワークフローシステムにおける配送処理時に図８に示した配送定義情報に基づいて生成されるものであり、ワークフローの経路，状態等を記憶するためのものである。また、この配送情報テーブルは、特に、ユーザＩＤ「Ｕ００１２」のユーザが起票した場合に対応する。この場合、伝票は、ユーザＩＤ「Ｕ００１２」，「Ｕ０００７」，「Ｕ０００３」，「Ｕ０００２」，「Ｕ０００１」のように配送されることとなる。
【００４９】
図９に示すように、配送情報テーブルは、「伝票名」項目５０１、「伝票番号」項目５０２、「ノード番号」項目５０３、「処理ユーザ」項目５０４、「状態」項目５０５、「最終処理日付け」項目５０６、「決済完了希望」項目５０７、「決済完了希望日」項目５０８、「代行済」項目５０９等の項目を含む。
【００５０】
「伝票名」項目５０１には、"交際費"等の伝票名そのものが起票時に格納される。「伝票番号」項目５０２には、伝票を識別するための識別子が起票示に格納される。「処理ユーザ」項目５０４には、「ノード番号」項目５０３に対応する処理者のユーザＩＤが格納される。「状態」項目５０５には、"処理待ち"や"処理済"等の状態を示す情報が格納される。「最終処理日付け」項目５０５には、「ノード番号」項目５０３に対応するノードを処理した日時が格納される。
【００５１】
なお、「決済完了希望」項目５０７、「決済完了希望日」項目５０８、「代行済」項目５０９については、後述する。
【００５２】
以下、図１０を参照して、本発明のワークフローシステムにおける配送処理手順の全体の流れについて説明する。
【００５３】
図１０は、本発明のワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートであり、図１に示したワークフローサーバ２００のワークフロープログラム２０４による配送処理に対応する。なお、図中、Ｓ５０００〜Ｓ５０１３は各ステップを示す。
【００５４】
まず、ワークフロープログラム２０４を実行するワークフローサーバ２００のＣＰＵ（以下、ワークフローサーバ２００のＣＰＵ）が、ワークフロー操作用端末３００より伝票処理要求を受信すると（ステップＳ５０００）、配送処理を開始する。
【００５５】
ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分である「起票」，「承認」，「否認」に基づいて、配送処理を切り替えていく（ステップＳ５００１）。
【００５６】
ステップＳ５００１において、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「起票」であると判定した場合には、ステップＳ５００２において、ワークフローサーバ２００のＣＰＵは、起票時の情報として、ノード番号「０」を配送情報テーブルに設定する。「処理ユーザ」には、起票したユーザのユーザＩＤを設定する。
【００５７】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、図８に示したように、配送情報テーブルのノード番号「０」のレコードに、伝票名に「交際費」、伝票番号を起票時に発行される伝票番号（ここでは「００００１」とする）、ノード番号に「０」、処理ユーザを起票ユーザのユーザＩＤ「Ｕ００１２」、状態に「処理済」を設定する。
【００５８】
次に、ステップＳ５００３において、ワークフローサーバ２００のＣＰＵは、現在のノード番号を「１」とし、ステップＳ５０００で受信した伝票処理要求の伝票名に対応する配送定義情報（図８）を参照し、ノード番号「１」の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００５９】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」を取得する。
【００６０】
一方、ステップＳ５００１で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」又は「否認」であると判定した場合には、ステップＳ５００４において、ワークフローサーバ２００のＣＰＵは、配送情報テーブル（図９）を参照して現在のノード番号を取得する。
【００６１】
次に、ステップＳ５００５において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」であるか「否認」であるかを判定し、「承認」であると判定した場合には、ステップＳ５００６において、ステップＳ５００４で取得した現在のノード番号をインクリメントした後、該インクリメントした現在のノード番号を持つ配送定義情報（図８）を参照し、該現在のノード番号の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００６２】
一方、ステップＳ５００５で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「否認」であると判定した場合には、ステップＳ５００７において、ステップＳ５００４で取得した現在のノード番号をデクリメントした後、該デクリメントした現在のノード番号を持つ配送定義情報（図８）を参照し、該現在のノード番号の情報（経路役割ＩＤ，経路組織ＩＤ）を取得し、ステップＳ５００８に進む。
【００６３】
そして、ステップＳ５００８において、ワークフローサーバ２００のＣＰＵは、ステップＳ５００３、Ｓ５００６、又はＳ５００７で取得した経路役割ＩＤ，経路組織ＩＤを用いて、ユーザ役職情報（図７）を参照して次の配送対象ユーザＩＤを決定する（役職テーブル（図７）から役割ＩＤが経路役割ＩＤで、組織ＩＤが経路組織ＩＤのユーザＩＤを決定する）。なお、取得した経路組織ＩＤが「ＮＵＬＬ」の場合（図８の空白の場合）には、現在のノード番号より１つ小さいノード番号に対応するユーザＩＤの属する組織ＩＤを「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定するものとする。さらに、これでも次の配送対象ユーザＩＤを決定することができない場合（ユーザ役職情報（図７）に、役割ＩＤが経路役割ＩＤで、組織ＩＤが経路組織ＩＤのレコードが存在しない場合）には、該組織ＩＤの親組織ＩＤを「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定するものとし、次の配送対象ユーザＩＤが決定するまでこの処理を繰り返すものとする。
【００６４】
例えば、図８に示した配送定義情報に基づく伝票が起票された場合、図９に示したように、ステップＳ５００３で、ノード番号「１」の経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」が取得され、該取得された経路役割ＩＤ「００４」，経路組織ＩＤ「ＮＵＬＬ」に基づいて配送対象となるユーザＩＤが決定される。ここで、取得した経路組織ＩＤが「ＮＵＬＬ」であるため、現在のノード番号「１」より１つ小さいノード番号「０」に対応するユーザＩＤ「Ｕ００１２」の属する組織ＩＤ「８０１０１０１０１０」を「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定する。このとき、ユーザ役職情報（図７）に、役割ＩＤ「００４」で、組織ＩＤ「８０１０１０１０１０」のレコードが存在しないため、組織ＩＤ「８０１０１０１０１０」の親組織ＩＤ「８０１０１０１０」を「経路組織ＩＤ」として次の配送対象ユーザＩＤを決定する。ここで、ユーザ役職情報（図７）を参照すると、役割ＩＤ「００４」で、組織ＩＤ「８０１０１０１０１０」のユーザＩＤは「Ｕ０００７」となり、このユーザＩＤ「Ｕ０００７」が次の配送対象ユーザＩＤに決定される。
【００６５】
次に、ステップＳ５００９において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものであるか否かを判定する。最終承認者は、図８のノード番号の最大値のレコードに該当する役割ＩＤの承認者からの承認であるかを判定するものとし、元々の最終承認者が委任（代行）ありの場合は、更にその上長とする。
【００６６】
ステップＳ５００９で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものでないと判定した場合には、ステップＳ５０１１において、ワークフローサーバ２００のＣＰＵは、ステップＳ５０００で受信した伝票処理要求の要求区分が「承認」又は「起票」であるか「否認」であるかを判定し、「承認」又は「起票」であると判定した場合には、ステップＳ５０１２において、配送情報テーブル（図９）に次のノード番号の情報を設定する。この時、「ノード番号」項目５０３には現在のノード番号を設定し、「処理ユーザ」項目５０４にはステップＳ５００９で決定された次の配送対象ユーザＩＤを設定し、「状態」項目５０５には"処理待ち"を設定し、「最終処理日付け」項目５０６には現在の日時を設定する。そして、ワークフローサーバ２００のＣＰＵは、ＳＭＴＰサーバ２０３により配送対象者にワークフロー通知を行い、処理を終了する。
【００６７】
一方、ステップＳ５０１１で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求の要求区分が「否認」であると判定した場合には、ステップＳ５０１３において、配送情報テーブル（図９）から上記現在ノード番号を削除するとともに、ＳＭＴＰサーバ２０３により配送対象者に否認された旨のワークフロー通知を行い、処理を終了する。
【００６８】
一方、ステップＳ５００９で、ワークフローサーバ２００のＣＰＵが、ステップＳ５０００で受信した伝票処理要求が最終承認者からのものであると判定した場合には、ステップＳ５０１０において、配送情報テーブル（図９）から当該配送情報を削除するとともに、ＳＭＴＰサーバ２０３により起票者に全て承認された旨のワークフロー通知を行い、処理を終了する。
【００６９】
以下、図１１〜図１９を用いて本実施形態における長期滞留時の処理について説明する。
【００７０】
図１１は、本実施形態における決裁完了希望期限付きの電子文書（伝票）の一例を示す図であり、起票時に、ワークフロー操作用端末３００の表示装置に表示され、ワークフロー操作用端末３００の入力装置により入力指示可能である。
【００７１】
図１１に示すように、決裁完了希望期限付きの電子文書は、通常の電子文書に決裁完了希望無のチェックボックス６０１，決裁完了希望有のチェックボックス６０２を配置する。この決裁完了希望無のチェックボックス６０１，決裁完了希望有のチェックボックス６０２は、排他的にチェック「ＯＮ」可能である。
【００７２】
希望有チェックボックスが「ＯＮ」の場合は、決裁完了希望日を決裁完了希望日入力欄６０３に入力する。
【００７３】
この伝票が起票されると、ワークフローサーバ２００のＣＰＵは、通常の電子文書に決裁完了希望無のチェックボックス６０１，決裁完了希望有のチェックボックス６０２の情報を、図９に示した配送情報テーブルの「決済完了希望の有無」項目５０７に格納する。また、ワークフローサーバ２００のＣＰＵは、決裁完了希望日入力欄６０３の情報を、図９に示した配送情報テーブルの「決裁完了希望日」項目５０８に格納する。なお、この処理は、図１０のステップＳ５００２で実行される。
【００７４】
図１２は、本実施形態における電子文書の配送経路上の決裁担当者のスケジュールデータを示した図である。
【００７５】
なお、この決裁担当者のスケジュールデータは、一般的なスケジュール管理ソフトウェアを用いて入力された担当者のスケジュール情報を、本代行決裁業務向けに外部データとして取り込み、加工したものであり、ワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される。
【００７６】
この決裁担当者のスケジュールデータは、決済完了希望のある伝票が起票されると、該伝票の配送情報テーブルに基づいて、該起票された伝票毎に、ワークフローサーバ２００により作成されるものである。
【００７７】
図１２において、この決裁担当者のスケジュールデータは、担当者欄７０１，日程欄７０２等から構成される。
【００７８】
担当者欄７０１には、配送経路上の承認担当者を特定する情報（ユーザ名やユーザＩＤ等）が格納される。また、日程欄７０２には、起案日（起票日）から決裁完了希望日までの日程が格納される。なお、決裁完了希望日がない場合は所定期間（例えば２週間）分の日程が格納される。
【００７９】
ワークフローサーバ２００のＣＰＵは、起票された伝票の配送情報テーブルに基づいて、配送経路上の各承認担当者を決定し、該各承認担当者を特定する情報（ユーザ名やユーザＩＤ等）を取得し、担当者欄７０１に格納する。また、ワークフローサーバ２００のＣＰＵは、担当者欄７０１に格納した各承認担当者の日程を、一般的なスケジュール管理ソフトウェアから取得して、日程欄７０２に格納する。その際、終日外出の日、半日外出または半日以上連続した打ち合わせのある日、前記以外の日の３種類に分類して格納する。なお、スケジュールが未定の場合はＮｕｌｌを格納する。
【００８０】
本実施形態は、終日外出の日は７０３のように「×」印で示す。また、半日外出または半日以上連続した打ち合わせのある日は７０４のように「△」印で示す。上記以外の日は７０５のように「○」印で示す。なお、スケジュールが未定の場合は７０６に示すように空白で示す。
【００８１】
図１３は、電子文書の承認・決裁処理が所定の滞留期限を超過し、上長への代行決裁の設定ができなかった場合に、そのことを通知するシステム管理者の宛先を一覧表示する画面である。この画面は、ワークフローサーバ２００に管理者モードでログインして、システム管理者宛先一覧の表示を指示することにより、ワークフロー操作用端末３００の表示画面上に表示される。
【００８２】
このシステム管理者宛先一覧では、ワークフローサーバ２００のＲＤＢＭＳ２０５に登録されているシステム管理者テーブル内の情報が表示される。
【００８３】
このシステム管理者宛先一覧には、管理者の名称８０１、管理者のメールアドレス８０２、管理対象組織８０３、当該組織における滞留を容認する期間を示す滞留期間８０４が表示される。
【００８４】
そして、このシステム管理者宛先一覧に登録されているシステム管理者テーブルの情報を変更する場合は、編集ボタン８０５、新規追加する場合は新規ボタン８０６、削除する場合は削除ボタン８０７、システム管理者登録機能を終了するときは、閉じるボタン８０８を押下する。これにより、ワークフローサーバ２００のＣＰＵは、対応する処理を行うように制御する。
【００８５】
なお、編集ボタン８０５又は新規ボタン８０６を押下した場合は、ワークフローサーバ２００のＣＰＵは、図9のシステム管理者設定画面をワークフロー操作用端末３００の表示装置に表示させる。
【００８６】
システム管理者一覧画面の例として、図８のように、システム管理者毎に滞留期間８０４を設定する構成について示したが、滞留期間８０４は伝票の種別ごとに設定可能であってもよい。このシステム管理者一覧画面で編集されたシステム管理者テーブルは、ワークフローサーバ２００のＲＤＢＭＳ２０５に登録される。
【００８７】
図１４は、本実施形態におけるシステム管理者設定画面の一例を示す図である。
【００８８】
このシステム管理者設定画面は、管理者の名称９０１、管理者メールアドレス９０２、滞留期間９０３、対象組織９０４の各入力欄を有し、既登録の情報を編集する場合は各入力欄に既登録情報が表示され、新規登録する場合は各入力欄は空欄表示される。
【００８９】
上記各入力欄９０１〜９０４に各情報が入力され、登録ボタン９０５が押下されると、ワークフローサーバ２００のＣＰＵは、該情報をＲＤＢＭＳ２０５内のシステム管理者テーブルに登録し、図１３に示したシステム管理者宛先一覧に画面を戻す。なお、対象組織９０４は、リストボックスから該当組織を選択可能である。
【００９０】
また、取消ボタン９０６が押下されると、ワークフローサーバ２００のＣＰＵは、各入力欄９０１〜９０４への入力情報をキャンセルし、図１３に示したシステム管理者宛先一覧に画面を戻す。
【００９１】
また、システム管理者は、全組織で1人を指定することも、１又は複数部門ごとに１人を指定して全組織で複数人数指定することも可能である。
【００９２】
以下、図１５，図１６を参照して、本発明のワークフローシステムにおける決裁未処理電子文書の滞留を検知する処理の流れについて説明する。
【００９３】
図１５は、本発明のワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートであり、図１に示したワークフローサーバ２００のワークフロープログラム２０４による決裁未処理電子文書の滞留検知処理に対応する。なお、図中、Ｓ１００１〜Ｓ１０１３は各ステップを示す。
【００９４】
まず、ワークフロープログラム２０４を実行するワークフローサーバ２００のＣＰＵ（以下、ワークフローサーバ２００のＣＰＵ）は、所定の期間が経過すると（定期的に）、ステップＳ１００１において、配送情報テーブルを検索（チェック）する。
【００９５】
ワークフローサーバ２００のＣＰＵは、ステップＳ１００２において、配送情報テーブルの「状態」項目５０５を確認し、状態が"処理済"ならば、処理を終了させる。また、フローチャートには示していないが「代行済」項目５０９"済"の場合も処理を終了させる。
【００９６】
一方、ステップＳ１００２で、配送情報テーブルの「状態」項目５０５が"処理待ち"と判断した場合には、ステップＳ１００３に処理を進め、その伝票を「処理ユーザ」項目５０４内のユーザＩＤに基づいて役職テーブルを検索して組織コードを取得する。また、その伝票の「最終処理日付」項目５０６の情報も取得する。
【００９７】
次に、ステップＳ１００４において、ワークフローサーバ２００のＣＰＵは、当該伝票が決裁完了希望日付き電子文書であるか、配送情報テーブルの「決済完了希望」項目５０６内の情報から判断する。
【００９８】
当該伝票が決裁完了希望日付き電子文書でないと判断した場合には、ステップＳ１００５において、ワークフローサーバ２００のＣＰＵは、ステップＳ１００３で取得した組織コードに基づいてシステム管理者テーブル内の滞留期間の情報を取得する。さらに、ワークフローサーバ２００のＣＰＵは、現在日時と処理待ち開始日時（最終処理日付）との差分を滞留猶予期間とし、ステップＳ１００７に処理を進める。
【００９９】
一方、ステップＳ１００４で、当該伝票が決裁完了希望日付き電子文書であると判断した場合には、ステップＳ１００６において、ワークフローサーバ２００のＣＰＵは、決裁完了希望日までの所要日数と全ノード通過日数の差分を滞留猶予期間とし、ステップＳ１００７に処理を進める。以下、詳細に説明する。まず、決裁完了希望日までの所要日数は「決裁完了希望日−現在日時」となる。また、１つの決裁ノード通過に「１＋α」日要すると仮定すると（αは補正値であり、組織の状態に応じて適宜定める）、全ノード通過日数は、「（全ノード数−現在ノード）×（１＋α）」と算出される。よって、滞留猶予期間は「（決裁完了希望日−現在日時）−（全ノード数−現在ノード）×（１＋α）」と算出される。
【０１００】
次に、ステップＳ１００７において、ワークフローサーバ２００のＣＰＵは、ステップＳ１００５又はＳ１００６で算出した滞留猶予期間と、管理者テーブル内の滞留期間とを比較して、滞留オーバであるか否かを判定する。
【０１０１】
ステップＳ１００７で、滞留オーバでない（ステップＳ１００５又はＳ１００６で算出した滞留猶予期間が管理者テーブル内の滞留期間を超えていない）と判断した場合には、ワークフローサーバ２００のＣＰＵは、そのまま処理を終了させる。
【０１０２】
一方、ステップＳ１００７で、滞留オーバ（ステップＳ１００５又はＳ１００６で算出した滞留猶予期間が管理者テーブル内の滞留期間を超えている）と判断した場合には、ワークフローサーバ２００のＣＰＵは、ステップＳ１００８において、配送経路上の代行承認可能な上長を選択する（詳細は図１６に示す）。
【０１０３】
次に、ステップＳ１００９において、ワークフローサーバ２００のＣＰＵは、ステップＳ１００８の処理で、配送経路上に代行承認可能な上長が存在したか否かを判定し、存在したと判断した場合には、ステップＳ１０１１に処理を進める。
【０１０４】
ステップＳ１０１１において、ワークフローサーバ２００のＣＰＵは、ユーザテーブルから当該上長のメールアドレスを取得する。
【０１０５】
次に、ステップＳ１０１２において、ワークフローサーバ２００のＣＰＵは、ステップＳ１０１１で取得したメールアドレスに対して承認代行依頼を通知する電子メールを生成し送信するとともに、ステップＳ１００８で選択された上長を承認代行者としてセットする。即ち、ステップＳ１００８で選択された上長のユーザＩＤを配送情報テーブル内の現在滞留しているノード番号の「処理ユーザ」項目５０４にセットし、さらに「代行済」項目５０９に"済"をセットする。そして、本フローチャートの処理を終了する。
【０１０６】
一方、ステップＳ１０１２において、ワークフローサーバ２００のＣＰＵは、ステップＳ１００８の処理で配送経路上に代行承認可能な上長が存在しなかったと判断した場合には、ステップＳ１０１０において、ステップＳ１００３で取得した組織コードに基づいてシステム管理者テーブルを検索し、システム管理者のメールアドレスを取得する。
【０１０７】
次に、ステップＳ１０１３において、ワークフローサーバ２００のＣＰＵは、ステップＳ１０１０で取得したシステム管理者のメールアドレスに対して、当該電子文書の承認・決済処理が滞留している旨を知らせる電子メールを生成して送信する。さらに、ワークフローサーバ２００のＣＰＵは、ワークフローサーバ２００のＲＤＢＭＳ２０５内の承認・決裁滞留伝票一覧テーブル（図１７）の「対象組織」項目１７０１，「伝票番号」項目１７０２，「ノード番号」項目１７０３，「滞留時間」項目１７０４に、ステップＳ１００３で取得した組織コード，当該滞留伝票の伝票番号，当該滞留ノード番号，ステップＳ１００５又はＳ１００６で算出した滞留猶予期間をそれぞれ格納して、承認・決裁滞留伝票一覧テーブルを更新する。そして、本フローチャートの処理を終了する。
【０１０８】
図１６は、本発明のワークフローシステムにおける第３の制御処理手順の一例を示すフローチャートであり、図１５のステップＳ１００８の配送経路上の代行承認可能な上長を選択する処理に対応する。なお、図中、Ｓ１１０１〜Ｓ１１０７は各ステップを示す。
【０１０９】
まず、ワークフローサーバ２００のＣＰＵは、ステップＳ１１０１において、当該承認者の直近の上長を当該伝票の配送経路上から選択する。
【０１１０】
次に、ステップＳ１１０２において、ワークフローサーバ２００のＣＰＵは、ステップＳ１１０１で選択した上長の承認スケジュールについて、終日外出の日（×印）はコストを「１日」とし、半日外出または半日以上連続した打ち合わせのある日（△印）はコストを「０．５日」とし、上記以外の日（○印）はコストを「０日」とし、さらに、組織の環境を加味した補正値を「α」とし、これを各コストに加算し、半日外出または半日以上連続した打ち合わせのある日（△印）または上記以外の日（○印）が出現するまで、上記コストを加算した総和を、当該承認代行者の決裁処理予定日（決裁予定コスト）とする。
【０１１１】
次に、ステップＳ１１０３において、ワークフローサーバ２００のＣＰＵは、ステップＳ１１０２で算出した決裁処理予定コストが図１５のステップＳ１１０５又はＳ１００６で算出さいた滞留猶予予定日以内であるか判断し、滞留猶予予定日以内であると判断した場合には、ステップＳ１１０７に処理を進める。
【０１１２】
そして、ステップＳ１１０７において、ワークフローサーバ２００のＣＰＵは、当該上長を決裁代行者（代行承認可能な上長）として選択し、処理を終了する。
【０１１３】
一方、ステップＳ１１０３で、ワークフローサーバ２００のＣＰＵは、ステップＳ１１０２で算出した決裁処理予定コストが図１５のステップＳ１１０５又はＳ１００６で算出さいた滞留猶予予定日以内でない（滞留猶予予定日を超過する）と判断した場合には、ステップＳ１１０４に処理を進める。
【０１１４】
次に、ステップＳ１１０４において、ワークフローサーバ２００のＣＰＵは、当該伝票の配送経路上の全ての上長を検査したか否かを判定し、まだ検査していない上長がいると判断した場合には、ステップＳ１１０５において、次の上長を選択し、ステップＳ１１０２に処理を戻す。
【０１１５】
一方、ステップＳ１１０４で、ワークフローサーバ２００のＣＰＵは、当該伝票の配送経路上の全ての上長を検査したと判断した場合には、ステップＳ１１０６において、該当伝票を代行承認可能な上長不在として、処理を終了する。
【０１１６】
なお、ステップＳ１１０２で用いた補正値「α」は、組織の環境や伝票の種別等により変更可能に構成してもよい。
【０１１７】
図１７は、本実施形態における滞留伝票情報テーブルの一例を示す図である。
【０１１８】
なお、この滞留伝票情報テーブルは、ワークフローサーバ２００のＲＤＢＭＳ２０５に記憶される。
【０１１９】
滞留伝票情報テーブルは、「対象組織」項目１７０１，「伝票番号」項目１７０２，「ノード番号」項目１７０３，「滞留時間」項目１７０４を含む。
【０１２０】
以下、図１８，図１９を参照して、本発明のワークフローシステムにおける処理が滞留している伝票にシステム管理者が代行者を設定する処理の流れについて説明する。
【０１２１】
図１８は、本実施形態において承認・決裁滞留伝票一覧で表示した画面を示す図である。
【０１２２】
この画面は、システム管理者がワークフロー操作用端末３００からワークフローサーバ２００にログインすると、ワークフローサーバ２００は、該システム管理者に対応する組織コードに基づいて、図１７に示した滞留伝票情報テーブルを検索し、対応する滞留伝票情報を取得する。そして、ワークフローサーバ２００は、取得した滞留伝票情報に基づいて、承認・決裁滞留伝票一覧画面を生成し、システム管理者のワークフロー操作用端末３００に送信する。これにより、システム管理者のワークフロー操作用端末３００は承認・決裁滞留伝票一覧画面を表示装置に表示する。
【０１２３】
この承認・決裁滞留伝票一覧画面には、承認もしくは決裁の処理が滞留している伝票の伝票番号１３０２、ノード番号１３０３、処理ユーザ１３０４、状態１３０５、滞留時間１３０６が表示される。なお、各伝票には、承認チェック欄１３０１，代行者設定欄１３０７が設けられている。
【０１２４】
システム管理者は、この承認・決裁滞留伝票一覧画面を用いて滞留している処理を代行するユーザを設定する。まず、代行者を設定する伝票の承認チェック欄１３０１にチェックを入れ、代行者設定欄１３０７に処理を代行するユーザのメールアドレスを入力する。
【０１２５】
なお、一度に複数の伝票に対して代行者の設定をすることが可能である。全ての設定が完了したら実行ボタン１３０８を押下する。また、この承認・決裁滞留伝票一覧画面を閉じる時には、閉じるボタン１３０９を押下する。
【０１２６】
実行ボタン１３０８が押下されると、当該ワークフロー操作用端末３００から、この画面の情報がワークフローサーバ２００に送信される。そして、これを受信したワークフローサーバ２００は、図１９に示す処理を開始する。
【０１２７】
図１９は、本発明のワークフローシステムにおける第４の制御処理手順の一例を示すフローチャートであり、図１に示したワークフローサーバ２００のワークフロープログラム２０４による処理が滞留している伝票にシステム管理者が代行者を設定する処理に対応する。なお、図中、Ｓ１４０１〜Ｓ１４１０は各ステップを示す。
【０１２８】
システム管理者によりワークフロー操作用端末３００で図１８に示した承認・決裁滞留伝票一覧画面で処理代行者が設定され、実行ボタン１３０８が押下されると、滞留案件の情報（図１８の情報）がワークフローサーバ２００に送信される。すると、ステップＳ１４０１において、ワークフロープログラム２０４を実行するワークフローサーバ２００のＣＰＵ（以下、ワークフローサーバ２００のＣＰＵ）は、ワークフロー操作用端末３００より滞留案件の情報を取得する。
【０１２９】
次に、ステップＳ１４０２において、ワークフローサーバ２００のＣＰＵは、まず、滞留案件の情報に承認チェック欄１３０１に承認チェックが入力されている案件があるか否かを判定し、承認チェックが入力されている案件がないと判断した場合には、処理を終了する。
【０１３０】
一方、ワークフローサーバ２００のＣＰＵは、承認チェックが入力されている案件があると判断した場合には、ステップＳ１４００３に処理を進める。
【０１３１】
ステップＳ１４０３において、ワークフローサーバ２００のＣＰＵは、滞留案件の情報の承認チェック欄１３０１に承認チェックが入力されている案件の代行者設定欄１３０７に代行者のメールアドレスが入力されている案件があるか否かを判定する。
【０１３２】
そして、ステップＳ１４０３において、ワークフローサーバ２００のＣＰＵは、代行者設定欄１３０７に代行者のメールアドレスが入力されている案件がないと判断した場合には、ステップＳ１４０７に処理を進め、代行者アドレスを入力するようメッセージをワークフロー操作用端末３００に送信して画面表示させ、処理を終了する。
【０１３３】
一方、ステップＳ１４０３で、ワークフローサーバ２００のＣＰＵは、滞留案件の情報の承認チェック欄１３０１に承認チェックが入力されている案件の代行者設定欄１３０７に代行者のメールアドレスが入力されている案件があると判断した場合には、ステップＳ１４０４に処理を進める。
【０１３４】
ステップＳ１４０４において、ワークフローサーバ２００のＣＰＵは、代行者に対して処理を依頼するメールを作成し、送信する。なお、送信するメールには、伝票番号、ノード番号、処理ユーザ、滞留時間などの代行処理の情報を含める。
【０１３５】
代行処理依頼のメールを送付後、ステップＳ１４０５において、ワークフローサーバ２００のＣＰＵは、代行者に対して伝票処理依頼を送信する。ワークフローサーバ２００のＣＰＵは、該代行者を当該滞留しているノード番号の「処理ユーザ」項目５０４にセットし、さらに「代行済」項目５０９に"済"をセットする。
【０１３６】
そして、ステップＳ１４０６において、ワークフローサーバ２００のＣＰＵは、承認・決裁滞留伝票情報テーブル（図１７）から該当の伝票番号とノード番号の行を削除して更新した滞留伝票一覧画面をワークフロー操作用端末３００に送信して画面更新させる。そして、本フローチャートを終了する。
【０１３７】
以上の処理により、ワークフロー上の正規の決裁担当者が不在であることが判明した場合にも、起案者の決裁完了希望日を満足できるよう、配送経路上の最適な代行決裁者へ代行決裁委任を行うことができ、電子文書の円滑な処理が促進できる。
【０１３８】
従って、ワークフローの滞留を防止でき、処理すべきワークフロー業務の効率化を促進することができる等の効果を奏する。
【０１３９】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０１４０】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１４１】
以下、図２０に示すメモリマップを参照して本発明に係るワークフローサーバ２００で読み取り可能なデータ処理プログラムの構成について説明する。
【０１４２】
図２０は、本発明に係るワークフローサーバ２００で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【０１４３】
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１４４】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１４５】
本実施形態における図１０，図１５，図１６，図１９に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１４６】
以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１４７】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１４８】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１４９】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１５０】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１５１】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１５２】
さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１５３】
なお、上記実施形態内で示した各変形例のいずれか又は全てを組み合わせた構成も全て本発明に含まれるものである。
【０１５４】
以上のように、ワークフローシステムにおいて、承認担当者不在等により滞留している未処理案件について、その状態をシステム管理者に通達し、前記未処理案件の長期間滞留を回避させることができる等の効果を奏する。
【図面の簡単な説明】
【０１５５】
【図１】本実施形態が適用されるワークフローシステムの概略構成を示す図である。
【図２】図１に示したワークフローサーバ，ワークフロー操作用端末，ワークフロー及び伝票設計用端末に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。
【図３】図１に示したワークフローシステムにおける伝票の流れを示す模式図である。
【図４】図１に示したワークフローサーバのＲＤＢＭＳに記憶される組織テーブルのデータ構造の一例を示すデータ構成図である。
【図５】図１に示したワークフローサーバのＲＤＢＭＳに記憶される役割テーブルのデータ構造の一例を示すデータ構成図である。
【図６】図１に示したワークフローサーバのＲＤＢＭＳに記憶されるユーザテーブルのデータ構造の一例を示すデータ構成図である。
【図７】図１に示したワークフローサーバのＲＤＢＭＳに記憶される役職テーブルのデータ構造の一例を示すデータ構成図である。
【図８】図１に示したワークフローサーバのＲＤＢＭＳに記憶される配送定義情報のデータ構造の一例を示すデータ構成図である。
【図９】図１に示したワークフローサーバのＲＤＢＭＳに記憶される配送情報テーブルのデータ構造の一例を示すデータ構成図である。
【図１０】本発明のワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートである。
【図１１】本実施形態における決裁完了希望期限付きの電子文書（伝票）の一例を示す図である。
【図１２】本実施形態における電子文書の配送経路上の決裁担当者のスケジュールデータを示した図である。
【図１３】電子文書の承認・決裁処理が所定の滞留期限を超過し、上長への代行決裁の設定ができなかった場合に、そのことを通知するシステム管理者の宛先を一覧表示する画面である。
【図１４】本実施形態におけるシステム管理者設定画面の一例を示す図である。
【図１５】本発明のワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。
【図１６】本発明のワークフローシステムにおける第３の制御処理手順の一例を示すフローチャートである。
【図１７】本実施形態における滞留伝票情報テーブルの一例を示す図である。
【図１８】本実施形態において承認・決裁滞留伝票一覧で表示した画面を示す図である。
【図１９】本発明のワークフローシステムにおける第４の制御処理手順の一例を示すフローチャートである。
【図２０】本発明に係るワークフローサーバ２００で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【符号の説明】
【０１５６】
２００ ワークフローサーバ
２０４ ワークフロープログラム
２０５ ＲＤＢＭＳ
３００ ワークフロー操作用端末
１０１ ＣＰＵ
１０２ ＲＡＭ
１０３ ＲＯＭ
１０４ ＨＤ
【特許請求の範囲】
【請求項１】
所定の配送経路に従って電子文書を回覧して承認・決裁のワークフロー処理を行うワークフローシステムにおいて、
承認・決裁者の組織情報，承認・決裁者のスケジュールを記憶する記憶手段と、
次の承認・決裁者による電子文書のワークフロー処理が所定の滞留期限を超過している滞留電子文書を検知する滞留検知手段と、
前記滞留検知手段で検知された滞留電子文書の配送経路上で次の承認・決裁者の上長にあたる承認・決裁者のスケジュールを参照し、該上長にあたる参照した承認・決裁者のスケジュールと、前記滞留期限とに基づいて決裁代行者として委任設定する上長を決定制御する制御手段と、
を有することを特徴とするワークフローシステム。
【請求項２】
前記制御手段は、前記次の承認・決裁者の直近の上長のスケジュールが前記滞留期限を満足しない場合、前記配送経路上の全ての上長にあたる承認・決裁者についてスケジュールを参照して、前記滞留期限を満足するスケジュールを有する上長を決裁代行者として委任設定することを特徴とする請求項１記載のワークフローシステム。
【請求項３】
少なくとも一人のシステム管理者を設定するシステム管理者設定手段と、
前記制御手段は、前記滞留期限を満足するスケジュールを有する上長が配送経路上に存在しない場合、前記電子文書の承認・決裁処理が前記滞留期限を超過している旨を前記システム管理者に対し通知することを特徴とする請求項２記載のワークフローシステム。
【請求項４】
前記制御手段により電子文書の承認・決裁処理が前記滞留期限を超過している旨の通知をうけた電子文書に対して、前記システム管理者により決裁代行者を設定可能な設定手段を有することを特徴とする請求項３記載のワークフローシステム。
【請求項５】
電子文書に対して決裁完了希望期限を設定可能な決裁希望期限設定手段を有し、
前記検知手段は、前記決裁希望期限設定手段により設定された決裁完了希望期限に基づいて前記滞留期限を決定することを特徴とする請求項１乃至４のいずれかに記載のワークフローシステム。
【請求項６】
所定の配送経路に従って電子文書を回覧して承認・決裁のワークフロー処理を行うワークフローシステムの滞留電子文書処理方法において、
承認・決裁者の組織情報，承認・決裁者のスケジュールを記憶手段に登録する登録ステップと、
次の承認・決裁者による電子文書のワークフロー処理が所定の滞留期限を超過している滞留電子文書を検知する滞留検知ステップと、
該検知された滞留電子文書の配送経路上で次の承認・決裁者の上長にあたる承認・決裁者のスケジュールを参照し、該上長にあたる参照した承認・決裁者のスケジュールと、前記滞留期限とに基づいて決裁代行者として委任設定する上長を決定する決定ステップと、
を有することを特徴とする滞留電子文書処理方法。
【請求項７】
請求項６に記載された滞留電子文書処理方法をコンピュータに実行させるためのプログラム。
【請求項８】
請求項６に記載された滞留電子文書処理方法をコンピュータに実行させるためのプログラムをコンピュータが読み取り可能に記憶した記録媒体。
【請求項１】
所定の配送経路に従って電子文書を回覧して承認・決裁のワークフロー処理を行うワークフローシステムにおいて、
承認・決裁者の組織情報，承認・決裁者のスケジュールを記憶する記憶手段と、
次の承認・決裁者による電子文書のワークフロー処理が所定の滞留期限を超過している滞留電子文書を検知する滞留検知手段と、
前記滞留検知手段で検知された滞留電子文書の配送経路上で次の承認・決裁者の上長にあたる承認・決裁者のスケジュールを参照し、該上長にあたる参照した承認・決裁者のスケジュールと、前記滞留期限とに基づいて決裁代行者として委任設定する上長を決定制御する制御手段と、
を有することを特徴とするワークフローシステム。
【請求項２】
前記制御手段は、前記次の承認・決裁者の直近の上長のスケジュールが前記滞留期限を満足しない場合、前記配送経路上の全ての上長にあたる承認・決裁者についてスケジュールを参照して、前記滞留期限を満足するスケジュールを有する上長を決裁代行者として委任設定することを特徴とする請求項１記載のワークフローシステム。
【請求項３】
少なくとも一人のシステム管理者を設定するシステム管理者設定手段と、
前記制御手段は、前記滞留期限を満足するスケジュールを有する上長が配送経路上に存在しない場合、前記電子文書の承認・決裁処理が前記滞留期限を超過している旨を前記システム管理者に対し通知することを特徴とする請求項２記載のワークフローシステム。
【請求項４】
前記制御手段により電子文書の承認・決裁処理が前記滞留期限を超過している旨の通知をうけた電子文書に対して、前記システム管理者により決裁代行者を設定可能な設定手段を有することを特徴とする請求項３記載のワークフローシステム。
【請求項５】
電子文書に対して決裁完了希望期限を設定可能な決裁希望期限設定手段を有し、
前記検知手段は、前記決裁希望期限設定手段により設定された決裁完了希望期限に基づいて前記滞留期限を決定することを特徴とする請求項１乃至４のいずれかに記載のワークフローシステム。
【請求項６】
所定の配送経路に従って電子文書を回覧して承認・決裁のワークフロー処理を行うワークフローシステムの滞留電子文書処理方法において、
承認・決裁者の組織情報，承認・決裁者のスケジュールを記憶手段に登録する登録ステップと、
次の承認・決裁者による電子文書のワークフロー処理が所定の滞留期限を超過している滞留電子文書を検知する滞留検知ステップと、
該検知された滞留電子文書の配送経路上で次の承認・決裁者の上長にあたる承認・決裁者のスケジュールを参照し、該上長にあたる参照した承認・決裁者のスケジュールと、前記滞留期限とに基づいて決裁代行者として委任設定する上長を決定する決定ステップと、
を有することを特徴とする滞留電子文書処理方法。
【請求項７】
請求項６に記載された滞留電子文書処理方法をコンピュータに実行させるためのプログラム。
【請求項８】
請求項６に記載された滞留電子文書処理方法をコンピュータに実行させるためのプログラムをコンピュータが読み取り可能に記憶した記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２００７−１５６６７８（Ｐ２００７−１５６６７８Ａ）
【公開日】平成１９年６月２１日（２００７．６．２１）
【国際特許分類】
【出願番号】特願２００５−３４８８９９（Ｐ２００５−３４８８９９）
【出願日】平成１７年１２月２日（２００５．１２．２）
【出願人】（３０１０１５９５６）キヤノンソフトウェア株式会社 (364)
【公開日】平成１９年６月２１日（２００７．６．２１）
【国際特許分類】
【出願日】平成１７年１２月２日（２００５．１２．２）
【出願人】（３０１０１５９５６）キヤノンソフトウェア株式会社 (364)
[ Back to top ]