ワークフローシステム
【課題】案件の回覧を最適に早く実現することにより、ワークフロー回覧の滞留に起因する業務処理遅延を防止する。
【解決手段】ワークフローシステムはサーバのプログラムの実行によって実現され、端末から送信される案件の承認者の承認依頼要求に従って、承認ルートにおける承認者及び代理承認者、又は副代理承認者を把握して、その在席状態を取得する共通処理部と、承認者及び代理承認者、又は副代理承認者の在席状態を把握して処理可能な処理者に案件を遷移させる案件処理部と、承認者、代理承認者、副代理承認者からの在席状態の応じて最適な承認者に案件処理を遷移させる在席状態変更による承認者切換え処理部と、承認者切換え処理部によって指定された最適な承認者へ案件の承認処理を通知するメール処理部を有する。
【解決手段】ワークフローシステムはサーバのプログラムの実行によって実現され、端末から送信される案件の承認者の承認依頼要求に従って、承認ルートにおける承認者及び代理承認者、又は副代理承認者を把握して、その在席状態を取得する共通処理部と、承認者及び代理承認者、又は副代理承認者の在席状態を把握して処理可能な処理者に案件を遷移させる案件処理部と、承認者、代理承認者、副代理承認者からの在席状態の応じて最適な承認者に案件処理を遷移させる在席状態変更による承認者切換え処理部と、承認者切換え処理部によって指定された最適な承認者へ案件の承認処理を通知するメール処理部を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワークフローシステムに係り、特に、承認者の在席状態を把握して、適宜、最適な承認者を自動選択する、ワークフローシステム及びその機能を実現するプログラムに関するものである。
【背景技術】
【０００２】
ワークフローシステムの回覧自動選択機能を実現するための種々の技術が提案されている。例えば、特許文献１には、ワークフローシステムにおいて、回覧経路が決まっている業務が複数存在する場合、データ作成時に予め、回覧経路を付加情報として設定し、作成したデータに対して最適な回覧経路を自動的に選択される手段を有することで、各回覧先において作業者が次の回覧先へ送信するための回覧経路を選択することなく、回覧を自動実行する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平９−８１４８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
現状、承認者の適切な承認を受けた上で業務処理が実行されたという承認証跡を残す手段として、ワークフローを利用したシステムが用いられている。業務処理に応じて各回覧経路が存在する場合、その最適な回覧経路を自動的に選択することは、特許文献1に記載の技術で実現可能であるが、次のような問題点が考えられる。
【０００５】
（１）自動的に選択された回覧経路上の承認者が不在の場合、そこで回覧が滞るために承認が受けられずに、業務処理が遅延してしまう可能性がある。それを回避するために、回覧者が随時承認者の在席状況を把握することが考えられるが、その時点での最適な承認者を選択して回覧を行うことは困難である。
【０００６】
（２）また、承認者が不在から在席状態に変更になった場合に、代理承認者に遷移した案件を再び承認者の処理に戻す場合に、遷移した案件と経路を把握した上でそれらを自らの処理に戻す作業は大変困難となる。
【０００７】
このように、従来では承認者が不在の場合にワークフロー回覧が滞留し、その結果、業務処理実行までに適切な承認を受けられずに業務処理作業が遅延し、また承認者が復帰したにも拘らず代理承認者に案件の処理が遷移したままとなり、処理を本来の処理者である承認者に戻すことが困難であるという不具合がある。
【０００８】
本発明の目的は、ワークフロー中の承認者の在席状況を把握し、その時点での最適な承認者を自動選択することで、案件の回覧を最適に早く実現することにより、ワークフロー回覧の滞留に起因する業務処理遅延を防止することにある。
【課題を解決するための手段】
【０００９】
本発明によるワークフローシステムは、好ましくは、ユーザにより操作される複数の端末がネットワークを介して接続される、サーバの処理装置でプログラムを実行することにより構築されるワークフローシステムであって、
案件の承認者及び代理承認者、又は副代理承認者を含むユーザの在席状態を管理する第１記憶手段と、承認を受ける対象の案件に関する情報を管理する第２の記憶手段と、案件の承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を管理するための第３記憶手段とを有し、更に
該処理装置でプログラムを実行することにより実現される；
いずれかの該端末から送信される承認者への案件の承認依頼要求に従って、該第３の記憶手段を参照して、該承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を特定し、更に該第１の記憶手段を参照して、特定された該承認者及び代理承認者、又は副代理承認者の在席状態を把握する共通処理部と、
特定された該承認者及び代理承認者、又は副代理承認者の在席状態に応じて、処理可能な処理者に案件を遷移し、該第２の記憶手段を更新する案件処理部と、
特定された該承認者、代理承認者、又は副代理承認者からの在席状態に応じて、最適な承認者に案件処理を遷移させる、在席状態変更による承認者切換え処理部と、
該承認者切換え処理部により指定された最適な承認者へ承認依頼を通知するメール処理部を有することを特徴とするワークフローシステムとして構成される。
【００１０】
また、本発明によるワークフローシステム用プログラムは、好ましくは、ユーザにより操作される複数の端末がネットワークを介して接続される、サーバの処理装置でプログラムを実行することにより構築されるワークフローシステム用プログラムであって、
該処理装置で実行されることにより、
案件の承認者及び代理承認者、又は副代理承認者を含むユーザの在席状態を管理する第１記憶手段をアクセスし、承認を受ける対象の案件に関する情報を管理する第２の記憶手段をアクセスし、案件の承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を管理するための第３記憶手段をアクセスし、かつ、
いずれかの該端末から送信される承認者への案件の承認依頼要求に従って、該第３の記憶手段を参照して、該承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を特定し、更に該第１の記憶手段を参照して、特定された該承認者及び代理承認者、又は副代理承認者の在席状態を把握する共通処理部と、
特定された該承認者及び代理承認者、又は副代理承認者の在席状態に応じて、処理可能な処理者に案件を遷移し、該第２の記憶手段を更新する案件処理部と、
特定された該承認者、代理承認者、又は副代理承認者からの在席状態に応じて、最適な承認者に案件処理を遷移させる、在席状態変更による承認者切換え処理部と、
該承認者切換え処理部により指定された最適な承認者へ承認依頼を通知するメール処理部を実現することを特徴とするワークフローシステム用プログラムとして構成される。
【発明の効果】
【００１１】
本発明によれば、承認者不在時に最適な他の承認者に自動的に処理が遷移し、また承認者の在席状態が変更になった際に自動的に処理が遷移することが可能となる。これにより、案件が承認者に回覧された時点、或いは承認者の在席状態が変更になった時点で最適な回覧者を自動的に選択でき、ワークフロー回覧の滞留による業務処理遅延を防止することが可能となる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施例によるワークフローシステムの全体を示す図である。
【図２Ａ】一実施例による案件承認依頼処理部１０６の処理動作を説明するフローチャートである。
【図２Ｂ】一実施例による案件承認依頼処理部１０６の処理動作を説明するフローチャートである。
【図３】一実施例による代理承認者への切換え処理部１０７の処理動作を説明するフローチャートである。
【図４】一実施例による副代理承認者への切換え処理部１０８の処理動作を説明するフローチャートである。
【図５】一実施例による承認者在席状態変更時の案件承認者切換え処理部１１０の処理動作を説明するフローチャートである。
【図６】一実施例による在席から不在へ変更時の案件承認者切換え処理部１１１の処理動作を説明するフローチャートである。
【図７】一実施例による承認者在席から不在へ変更時の案件承認者切換え処理部１１２の処理動作を説明するフローチャートである。
【図８】一実施例による代理承認者在席から不在へ変更時の案件承認者切換え処理部１１３の処理動作を説明するフローチャートである。
【図９】一実施例による副代理承認者在席から不在へ変更時の案件承認者切換え処理部１１４の処理動作を説明するフローチャートである。
【図１０】一実施例による不在から在席へ変更時の案件承認者切換え処理部１１５の処理動作を説明するフローチャートである。
【図１１】一実施例による承認依頼通知メール処理部１１７の処理動作を説明するフローチャートである。
【図１２】一実施例による在席フラグ取得処理部１１９の処理動作を説明するフローチャートである。
【図１３】一実施例による在席マスタテーブルの構成例を示す図である。
【図１４】一実施例による案件マスタテーブルの構成例を示す図である。
【図１５】一実施例によるルート承認者正副マスタテーブルの構成例を示す図である。
【図１６】一実施例によるメッセージマスタテーブルの構成例を示す図である。
【図１７】一実施例によるユーザマスタテーブルの構成例を示す図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して、本発明の好適な実施例について詳細に説明する。
図１は一実施例によるワークフローシステムの全体構成を示す。
ワークフローシステムは、サーバ１に案件管理システム１０が構築されることで実現する。サーバ１には、ネットワーク１９を介してユーザにより操作される複数の端末１８が接続される（都合上１台の端末１８のみ図示）。サーバ１は、処理装置（ＣＰＵ）、記憶装置、主メモリ、キーボード、マウス等の入力装置及び表示装置を有し、ＣＰＵで所定のプログラムが実行されることで、案件管理システム１０の各処理部の機能が構築される。
【００１４】
この案件管理システム１０は、案件処理部１０５、在席状態変更による承認者切換え処理部１０９、メール処理部１１６、共通処理部１１８、及び在席マスタ１２０、案件マスタ１２１、ルート承認者正副マスタ１２２、メッセージマスタ１２３、ユーザマスタ１２４の各データベース（ＤＢという）から構成される。
【００１５】
上記４つの処理部は、それぞれ以下の処理部により構成される。
案件処理部１０５は、案件承認依頼処理部１０６、代理承認者への切換え処理部１０７、副代理承認者への切換え処理部１０８により構成される。
在席状態変更による承認者切換え処理部１０９は、承認者在席状態変更時の案件承認者切換え処理部１１０、在席から不在へ変更時の案件承認者切換え処理部１１１、承認者在席から不在へ変更時の案件承認者切換え処理部１１２、代理承認者在席から不在へ変更時の案件承認者切換え処理部１１３、副代理承認者在席から不在へ変更時の案件承認者切換え処理部１１４、不在から在席へ変更時の案件承認者切換え処理部１１５により構成される。
メール処理部１１６は、承認依頼通知メール処理部１１７により構成される。共通処理部１１８は、在席フラグ取得処理部１１９により構成される。
なお、上記各処理部の処理動作については、フローチャートを参照して詳述する。
【００１６】
次に、各ＤＢの構成について説明する。
図１３は在席マスタテーブル１２０の構成例を示す。
在席マスタテーブル１２０は、システム利用者に固有の「ユーザＩＤ」と、ユーザの在席状況を示す「在席フラグ」の項目を１つのレコードとして、複数のレコードを格納するように構成される。ここで、在席フラグは、在席時は「１」、不在時は「０」で表される。この各レコードによりユーザの在席状況を特定することができる。
【００１７】
図１４は案件マスタテーブル１２１の構成例を示す。
案件マスタテーブル１２１は、案件管理システム１０内で案件を一意に示すシステム内部用ＩＤとしての「案件ＩＤ」と、案件管理システム１０内で案件を一意に示す「案件ＩＤ」に紐付く「案件コード」と、現在の案件処理者のユーザＩＤを示す「現処理者ＩＤ」と、現在の案件のルート位置を示す「ルート表示ＩＤ」と、案件を登録したユーザのＩＤを示す「登録者ＩＤ」と、案件を登録した日時を示す「登録日時」と、案件を更新した直近のユーザのＩＤを示す「更新者ＩＤ」と、案件を更新した直近の日時を示す「更新日時」と、現処理者ＩＤにセットされている承認者の立場を示す「案件承認者立場フラグ」の各項目を１つのレコードとして、複数のレコードを格納するように構成される。ここで、「案件承認者立場フラグ」に関して、承認者は「1」、代理承認者は「２」、副代理承認者は「３」、その他は「０」で表される。この各レコードにより案件を特定することができる。
【００１８】
図１５はルート承認者正副マスタテーブル１２２の構成例を示す。
ルート承認者正副マスタテーブル１２２は、ルート位置を示す「ルートＩＤ」と、ルートに対する承認者のユーザＩＤを示す「承認者ＩＤ」と、ルートに対する代理承認者のユーザＩＤを示す「代理承認者ＩＤ」と、ルートに対する副代理承認者のユーザＩＤを示す「副代理承認者ＩＤ」の各項目を１つのレコードとして、複数のレコードを格納するように構成される。このレコードによりルートに対する承認者及び代理承認者、副代理承認者を特定することができる。
【００１９】
図１６はメッセージマスタテーブル１２３の構成例を示す。
メッセージマスタテーブル１２３は、メッセージを一意に表す「メッセージＩＤ」と、メッセージＩＤに対するメッセージ内容を示す「メッセージ内容」の項目を１つのレコードとして、複数のレコードを格納するように構成される。このレコードによりメッセージの内容を特定することができる。
【００２０】
図１７はユーザマスタテーブル１２４の構成例を示す。
ユーザマスタテーブル１２４は、案件管理システム１０内でユーザを一意に表す「ユーザＩＤ」と、ユーザの氏名を表す「氏名」と、ユーザが所属する会社ＩＤを表す「会社ＩＤ」と、ユーザが所属する組織ＩＤを表す「組織ＩＤ」と、ユーザのメールアドレスを表す「メールアドレス」の各項目を１つのレコードとして、複数のレコードを格納するように構成される。このレコードによりユーザの情報を特定することができる。
【００２１】
次に、図２Ａ〜図２Ｂを参照して、案件承認依頼処理部１０６による処理動作について説明する。
（１）端末１８のユーザの操作により承認者への案件承認依頼要求が開始されると、承認依頼があった案件の案件ＩＤがサーバ１へ送信され、サーバ１はその要求を保持する（Ｓ２０１）。
（２）メッセージＩＤに値"１０１"をセットする（Ｓ２０２）。
（３）Ｓ２０１で保持した案件ＩＤをキーに、案件マスタ１２１を参照して、案件ＩＤが一致したレコードのルート表示ＩＤを取得する（Ｓ２０３〜Ｓ２０５）。
（４）Ｓ２０５で取得したルート表示ＩＤをキーに、ルート承認者正副マスタ２０７を参照して、ルート承認者正副マスタ２０７のルートＩＤとルート表示ＩＤが一致したレコードの承認者ＩＤ及び代理承認者ＩＤ、副代理承認者ＩＤを取得する（Ｓ２０６〜２０８）。
【００２２】
（５）Ｓ２０８で取得した承認者ＩＤを在席フラグ取得処理Ｓ２０９に送信し、在席フラグ取得処理Ｓ２０９の処理結果である承認者の在席フラグの値を取得する（Ｓ２０９）。
（６）取得した承認者の在席フラグを判定して、在席を示す値"１"であれば、Ｓ２０１で保持した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"１"をセットする。その後、承認依頼通知メール処理２２１へ遷移する。
一方、在席フラグが不在を示す値"０"であれば、Ｓ２０８で取得した代理承認者ＩＤのNULLチェックを行う（Ｓ２１０〜２１２）。
【００２３】
（７）Ｓ２０８で取得した代理承認者ＩＤがNULLであるか、Not NULLであるかを判定し、NULLであった場合は２１６へ遷移する。一方、Not NULLであった場合、代理承認者ＩＤを代理承認者への切換え処理Ｓ２１４に送信し、代理承認者への切換え処理Ｓ２１４の処理結果である代理承認者の在席フラグの値を取得する（Ｓ２１３〜２１４）。
（８）取得した代理承認者の在席フラグを判定し、在席を示す値"１"であれば、承認依頼通知メール処理Ｓ２２１へ遷移する。一方、在席フラグが不在を示す値"０"であれば、Ｓ２０８で取得した副代理承認者ＩＤのNULLチェックを行う（Ｓ２１５）。
【００２４】
（９）Ｓ２０８で取得した副代理承認者ＩＤがNULLであるか、Not NULLであるかを判定し、NULLであった場合はＳ２１９へ遷移する。一方、Not NULLであった場合、副代理承認者ＩＤを副代理承認者への切換え処理２１７へ送信し、副代理承認者への切換え処理Ｓ２１７の処理結果である副代理承認者の在席フラグの値を取得する（Ｓ２１６〜Ｓ２１７）。
（１０）取得した副代理承認者の在席フラグを判定し、在席を示す値"１"であれば、承認依頼通知メール処理Ｓ２２１へ遷移する。在席フラグが不在を示す値"０"であれば、Ｓ２０１で保持した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"１"をセットする（Ｓ２１８〜２２０）。
（１１）最後に、セットされたメッセージＩＤを承認依頼通知メール処理へ送信して（Ｓ２２１、一連の処理を終了する。
【００２５】
次に、図３を参照して、代理承認者への切換え処理部１０７による処理動作（Ｓ２１４）について説明する。
（１）この処理は、Ｓ２１３の処理から送信された代理承認者ＩＤを取得して、処理が開始される。まず、Ｓ２１３の処理から送信された代理承認者ＩＤを在席フラグ取得処理３０１に送信し、在席フラグ処理３０１の処理結果である代理承認者の在席フラグの値を取得する（Ｓ３０１）。
（２）取得した代理承認者の在席フラグを判定し、その判定の結果、在席を示す値"１"であれば、Ｓ２０１で保持した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に代理承認者ＩＤをセットし、また案件承認者立場フラグ列に"２"をセットする。その後、メッセージＩＤに値"１０２"をセットして、代理承認者への切換え処理１０７を完了する。
上記判定Ｓ３０２の結果、在席フラグが不在を示す値"０"であれば、Ｓ３０３〜Ｓ３０５の処理を行わず、代理承認者への切換え処理部１０７による処理を完了する（Ｓ３０２〜３０５）。
【００２６】
次に、図４を参照して、副代理承認者への切換え処理部１０８による処理動作（Ｓ２１７）について説明する。
（１）この処理は、Ｓ２１６の処理から送信された副代理承認者ＩＤを取得して処理が開始される。まず、Ｓ２１６の処理から送信された副代理承認者ＩＤを在席フラグ取得処理４０１に送信し、在席フラグ処理４０１の処理結果である副代理承認者の在席フラグの値を取得する（Ｓ４０１）。
（２）取得した副代理承認者の在席フラグを判定し、その結果、在席を示す値"１"であれば、Ｓ２０１で保持した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に副代理承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"３"をセットする。その後、メッセージＩＤに値"１０３"をセットして、副代理承認者への切換え処理１０８の処理を完了する。
一方、上記判定Ｓ４０２の結果、在席フラグが不在を示す値"０"であれば、Ｓ４０３〜Ｓ４０５の処理を行わず、副代理承認者への切換え処理部１０８の処理を完了する（Ｓ４０２〜Ｓ４０５）。
【００２７】
次に、図５を参照して、承認者在席状態変更時の案件承認者切換え処理部１１０の処理動作について説明する。
（１）この処理は、端末を使用するユーザからの在席フラグの入力により開始される。まず、ユーザが端末１８に入力した在席フラグがサーバ１へ送信され、サーバ１はそれを保持する（Ｓ５０１）。
（２）在席フラグを送信したユーザのユーザＩＤをキーに、在席マスタ１２０を参照して、在席マスタ１２０のユーザＩＤと一致したレコードの在席フラグを取得する（Ｓ５０２〜Ｓ５０４）。
【００２８】
（３）次に、Ｓ５０１で取得したユーザ入力の在席フラグと、Ｓ５０４で取得した在席フラグを比較する（Ｓ５０５）。その結果、ユーザ入力の在席フラグとＳ５０４で取得した在席フラグが一致した場合は、Ｓ５０６〜Ｓ５０８の処理を行わず、承認者在席状態変更時の案件承認者切換え処理部１１０の処理を完了する。一方、上記比較Ｓ５０５の結果、ユーザ入力の在席フラグとＳ５０４で取得した在席フラグが不一致の場合は、ユーザ入力の在席フラグの値判定を行う。
（４）Ｓ５０１で取得したユーザ入力の在席フラグを判定し（Ｓ５０６）、不在を示す値"０"であれば、在席から不在へ変更時の案件承認者切換え処理Ｓ５０７へ遷移する。一方、在席フラグが在席を示す値"１"であれば、不在から在席へ変更時の案件承認者切換え処理Ｓ５０８へ遷移する（Ｓ５０６〜Ｓ５０８）。
【００２９】
次に、図６を参照して、在席から不在へ変更時の案件承認者切換え処理部１１１の処理動作について説明する。
（１）Ｓ５０１で在席フラグを送信したユーザのユーザＩＤをキーに案件マスタ１２１を参照して、案件マスタの現処理者ＩＤとユーザＩＤが一致したレコードの案件ＩＤを取得する（Ｓ６０１〜Ｓ６０３）。
（２）そして、現処理者ＩＤとユーザＩＤが一致したレコード数が０件か判定し（Ｓ６０４）、その結果、０件ならばＳ６０５〜Ｓ６１５の処理を行わず、在席から不在へ変更時の案件承認者切換え処理部１１１の処理を完了する。
一方、判定の結果、現処理者ＩＤとユーザＩＤが一致したレコード数が０件でない場合、Ｓ６０５の処理へ遷移する（Ｓ６０４）。
【００３０】
（３）そして、Ｓ６０３で取得した案件ＩＤをキーに、案件マスタ１２１を参照し、案件ＩＤが一致したレコードのルート表示ＩＤを取得する（Ｓ６０５〜Ｓ６０７）。
（４）Ｓ５０１で在席フラグを送信したユーザのユーザＩＤとＳ６０７で取得したルート表示ＩＤをキーに、ルート承認者正副マスタ１２２を参照して、ルートＩＤが一致したレコードの承認者ＩＤ列の値とユーザＩＤが一致した場合、承認者在席から不在へ変更時の案件承認者切換え処理Ｓ６１１へ遷移する。一方、ルートＩＤが一致したレコードの承認者ＩＤ列の値とユーザＩＤが不一致の場合、Ｓ６１２の処理へ遷移する（Ｓ６０８〜Ｓ６１１）。
【００３１】
（５）ルートＩＤが一致したレコードの代理承認者ＩＤ列の値とユーザＩＤが一致した場合、代理承認者在席から不在へ変更時の案件承認者切換え処理６１３へ遷移する。一方、ルートＩＤが一致したレコードの代理承認者ＩＤ列の値とユーザＩＤが不一致の場合、Ｓ６１４の処理へ遷移する（Ｓ６１２〜Ｓ６１３）。
（６）ルートＩＤが一致したレコードの副代理承認者ＩＤ列の値とユーザＩＤが一致した場合、副代理承認者在席から不在へ変更時の案件承認者切換え処理Ｓ６１５へ遷移する。一方、ルートＩＤが一致したレコードの副代理承認者ＩＤ列の値とユーザＩＤが不一致の場合、Ｓ６１５の処理を行わず、在席から不在へ変更時の案件承認者切換え処理部１１１の処理を完了する（Ｓ６１４〜Ｓ６１５）。
【００３２】
次に、図７を参照して、承認者在席から不在へ変更時の案件承認者切換え処理部１１２の処理動作について説明する。
（１）Ｓ６０７で取得したルート表示ＩＤをキーにルート承認者正副マスタＳ７０２を参照して、ルート承認者正副マスタ７０２のルートＩＤの値とルート表示ＩＤが一致したレコードの代理承認者ＩＤと副代理承認者ＩＤを取得する（Ｓ７０１〜７０３）。
（２）次に、Ｓ７０３で取得した代理承認者ＩＤがNULLであるか、Not NULLであるかを判定する（Ｓ７０４）。その結果、NULLの場合はＳ７１１の処理へ遷移する。Not NULLの場合、代理承認者ＩＤを在席フラグ取得処理７０５に送信し、在席フラグ取得処理Ｓ７０５の処理結果である代理承認者の在席フラグの値を取得する（Ｓ７０５）。
（３）次に、Ｓ７０５で取得した代理承認者の在席フラグの値を判定する（Ｓ７０６）。その結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に代理承認者ＩＤをセットし、また案件承認者立場フラグ列に"２"をセットする。メッセージＩＤに値"１０２"をセットし、その後承認依頼通知メール処理Ｓ７１０へ遷移する。一方、在席フラグが不在を示す値"０"であれば、Ｓ６０３で取得した副代理承認者ＩＤのNULLチェックを行う（Ｓ７０６〜Ｓ７１０）。
【００３３】
（４）次に、Ｓ７０３で取得した副代理承認者ＩＤがNULLであるか、Not NULLであるかを判定する（Ｓ７１１）。その結果、NULLであった場合はＳ７１２〜７１７の処理を行わず、承認者在席から不在へ変更時の案件承認者切換え処理部１１２の処理を完了する。一方、Not NULLであった場合、副代理承認者ＩＤを在席フラグ取得処理７１２に送信し、在席フラグ取得処理７１２の処理結果である副代理承認者の在席フラグの値を取得する（Ｓ７１１〜Ｓ７１２）。
（５）次に、Ｓ７１２で取得した副代理承認者の在席フラグを判定する（Ｓ７１３）。その結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に副代理承認者ＩＤをセットし、また案件承認者立場フラグ列に"３"をセットする。また、メッセージＩＤに値"１０３"をセットし、その後承認依頼通知メール処理７１７へ遷移する。一方、在席フラグが不在を示す値"０"であれば、Ｓ７１４〜Ｓ７１７の処理を行わず、承認者在席から不在へ変更時の案件承認者切換え処理部１１２の処理を完了する（Ｓ７１３〜Ｓ７１７）。
【００３４】
次に、図８を参照して、代理承認者在席から不在へ変更時の案件承認者切換え処理部１１３の処理動作について説明する。
（１）Ｓ６０７で取得したルート表示ＩＤをキーに、ルート承認者正副マスタＳ８０２を参照し、ルート承認者正副マスタＳ８０２のルートＩＤの値とルート表示ＩＤが一致したレコードの承認者ＩＤと副代理承認者ＩＤを取得する（Ｓ８０１〜Ｓ８０３）。
（２）Ｓ８０３で取得した承認者ＩＤを在席フラグ取得処理Ｓ８０４に送信し、在席フラグ取得処理Ｓ８０４の処理結果である承認者の在席フラグの値を取得する（Ｓ８０４）。
（３）次に、Ｓ８０４で取得した承認者の在席フラグの値を判定する（Ｓ８０５）。判定の結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に承認者ＩＤをセットし、また案件承認者立場フラグ列に"１"をセットする。また、メッセージＩＤに値"１０１"をセットして、その後、承認依頼通知メール処理Ｓ８０９へ遷移する。一方、在席フラグが不在を示す値"０"であれば、Ｓ６０３で取得した副代理承認者ＩＤのNULLチェックを行う（Ｓ８０５〜Ｓ８０９）。
【００３５】
（４）Ｓ８０３で取得した副代理承認者ＩＤがNULLであるか、Not NULLであるかを判定する（Ｓ８１０）。その結果、NULLであった場合はＳ８１１〜Ｓ８１６の処理を行わず、代理承認者在席から不在へ変更時の案件承認者切換え処理部１１３の処理を完了する。
一方、Not NULLであった場合、副代理承認者ＩＤを在席フラグ取得処理８１１に送信し、在席フラグ取得処理Ｓ８１１の処理結果である副代理承認者の在席フラグの値を取得する（Ｓ８１０〜Ｓ８１１）。
（５）次に、Ｓ８１１で取得した副代理承認者の在席フラグを判定する（Ｓ８１２）。その結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に副代理承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"３"をセットする。また、メッセージＩＤに値"１０３"をセットし、その後、承認依頼通知メール処理Ｓ８１６へ遷移する。
一方、在席フラグが不在を示す値"０"であれば、Ｓ８１３〜８１６の処理を行わず、代理承認者在席から不在へ変更時の案件承認者切換え処理部１１３の処理を完了する（Ｓ８１２〜Ｓ８１６）。
【００３６】
次に、図９を参照して、副代理承認者在席から不在へ変更時の案件承認者切換え処理部１１４の処理動作について説明する。
（１）Ｓ６０７で取得したルート表示ＩＤをキーに、ルート承認者正副マスタ９０２を参照して、ルート承認者正副マスタ９０２のルートＩＤの値とルート表示ＩＤが一致したレコードの承認者ＩＤと代理承認者ＩＤを取得する（Ｓ９０１〜Ｓ９０３）。
（２）Ｓ９０３で取得した承認者ＩＤを在席フラグ取得処理９０４に送信し、在席フラグ取得処理Ｓ９０４の処理結果である承認者の在席フラグの値を取得する（Ｓ９０４）。
（３）Ｓ９０４で取得した承認者の在席フラグの値を判定し（Ｓ９０５）、その結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"１"をセットする。またメッセージＩＤに値"１０１"をセットし、その後、承認依頼通知メール処理Ｓ９０９へ遷移する。
一方、在席フラグが不在を示す値"０"であれば、Ｓ６０３で取得した代理承認者ＩＤのNULLチェックを行う（Ｓ９０５〜Ｓ９０９）。
【００３７】
（４）次に、Ｓ９０３で取得した代理承認者ＩＤがNULLであるか、Not NULLであるかを判定する（Ｓ９１０）。その結果、NULLであった場合はＳ９１１〜Ｓ９１６の処理を行わず、副代理承認者在席から不在へ変更時の案件承認者切換え処理部１１４の処理を完了する。
一方、Not NULLであった場合、代理承認者ＩＤを在席フラグ取得処理Ｓ９１１に送信し、在席フラグ取得処理Ｓ９１１の処理結果である代理承認者の在席フラグの値を取得する（Ｓ９１０〜Ｓ９１１）。
（５）Ｓ９１１で取得した代理承認者の在席フラグを判定し（Ｓ９１２）、その結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に代理承認者ＩＤをセットし、また案件承認者立場フラグ列に"２"をセットする。また、メッセージＩＤに値"１０２"をセットし、その後、承認依頼通知メール処理Ｓ９１６へ遷移する。
一方、在席フラグが不在を示す値"０"であれば、Ｓ９１３〜Ｓ９１６の処理を行わず、副代理承認者在席から不在へ変更時の案件承認者切換え処理部１１４の処理を完了する（Ｓ９１２〜Ｓ９１６）。
【００３８】
次に、図１０を参照して、不在から在席へ変更時の案件承認者切換え処理部１１５の処理動作について説明する。
（１）案件マスタ１２１を参照して、１レコード目の案件ＩＤ、現処理者ＩＤ、ルート表示ＩＤ及び案件承認者立場フラグを取得する（Ｓ１００１〜Ｓ１００２）。
（２）Ｓ１００１で取得した案件承認者立場フラグの値を判定する（Ｓ１００３）。その結果、その他を示す値"０"もしくは承認者を示す値"１"であれば、Ｓ１０１７の処理へ遷移する。一方、案件承認者立場フラグの値が"０"もしくは"１"以外の場合はＳ１００４の処理へ遷移する（Ｓ１００３）。
（３）次に、Ｓ５０１で取得したユーザＩＤ及びＳ１００１で取得したルート表示ＩＤをキーに、ルート承認者正副マスタＳ１００５を参照して、Ｓ１００１で取得したルート表示ＩＤとルート承認者正副マスタＳ１００５のルートＩＤが一致したレコードを取得する（Ｓ１００４）。
【００３９】
（４）Ｓ１００４で取得したレコードの承認者ＩＤの値とＳ５０１で取得したユーザＩＤの値を判定し（Ｓ１００６）、その結果、一致した場合はＳ１００１で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に、承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"１"をセットする。またメッセージＩＤに値"１０１"をセットし、その後、承認依頼通知メール処理Ｓ１０１０へ遷移する。
一方、Ｓ１００４で取得したレコードの承認者ＩＤの値とＳ５０１で取得したユーザＩＤの値が一致しなかった場合、Ｓ１０１１の案件承認者立場フラグの判定処理へ遷移する（Ｓ１００７〜Ｓ１０１１）。
（５）Ｓ１００１で取得した案件承認者立場フラグの値を判定し（Ｓ１０１１）、その結果、副代理承認者を示す値"３"であれば、Ｓ１０１２の処理へ遷移する。案件承認者立場フラグの値が"３"以外の場合はＳ１０１７の処理へ遷移する（Ｓ１０１１）。
【００４０】
（６）Ｓ１００４で取得したレコードの代理承認者ＩＤの値とＳ５０１で取得したユーザＩＤの値を判定し（Ｓ１０１２）、その結果、一致した場合はＳ１００１で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの"現処理者ＩＤ列に代理承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"２"をセットする。またメッセージＩＤに値"１０２"をセットし、その後、承認依頼通知メール処理１０１６へ遷移する。
一方、Ｓ１００４で取得したレコードの代理承認者ＩＤの値とＳ５０１で取得したユーザＩＤの値が一致しなかった場合、Ｓ１０１７の処理へ遷移する（Ｓ１０１２〜Ｓ１０１６）。
（７）次に、案件マスタ１２１のレコード位置を取得し、その位置が案件マスタ１２１の最終レコードの場合、不在から在席へ変更時の案件承認者切換え処理部１１５の処理を完了する。一方、案件マスタ１２１のレコード位置が最終でなかった場合、案件マスタ１２１の処理対象レコードを次のレコードに移し、Ｓ１００１の処理へ遷移する（Ｓ１０１７〜Ｓ１０２１）。
【００４１】
次に、図１１を参照して、承認依頼通知メール処理部１１７の処理動作について説明する。
（１）案件処理部１０５や在席状態変更による承認者切換え処理部１０９の処理内でセットされたメッセージＩＤをキーにメッセージマスタ１２３を参照し、メッセージマスタ１２３のメッセージＩＤの値と一致したレコードのメッセージ内容を取得する（Ｓ１１０１〜Ｓ１１０３）。
（２）現処理者にセットされているユーザＩＤをキーに、ユーザマスタ１１０５を参照して、ユーザマスタ１２４のユーザＩＤの値と一致したレコードのメールアドレスを取得する（Ｓ１１０４〜Ｓ１１０６）。
（３）Ｓ１１０３で取得したメッセージ内容と、Ｓ１１０６で取得したメールアドレスを電子メールＳ１１０８のメール本文、送信先メールアドレスにそれぞれセットして電子メールＳ１１０８を送付し、承認依頼通知メール処理１１７を完了する（Ｓ１１０７〜Ｓ１１０８）。
【００４２】
次に、図１２を参照して、在席フラグ取得処理部１１９の処理動作について説明する。
（１）在席フラグ取得処理部１１９に引き渡されたユーザＩＤをキーに在席マスタ１２０を参照して、在席マスタ１２０のユーザＩＤの値と一致したレコードの在席フラグを取得し、在席フラグ取得処理１１９を完了する（Ｓ１２０１〜Ｓ１２０３）。
【００４３】
以上説明した処理により、案件管理システム１０の承認者の在席状況に応じて、その時点での最適な承認者が自動的に選択され、それにより最適、最速の案件回覧が実現され、ワークフロー回覧の滞留による業務処理遅延を防止することが可能となる。
【００４４】
なお、本発明は上記実施例に限定されることなく、種々変形して実施することができるであろう。例えば、上記実施例では、承認のルートを承認者及び代理承認者、副代理承認者の順で設定しているが、副代理承認者が不要な場合もある。このような場合には、図１の案件管理システム及び関係するフローチャートから副代理承認者による処理部又は処理を削除して実現すればよい。逆に、副代理承認者が不在の場合、更に第二或いは第三の副代理者に承認を求めることもあり得る。このような場合には、図１の案件管理システム及び関係するフローチャートに第二或いは第三の副代理承認者による処理部又は処理を追加して実現すればよい。このような第二或いは第三の副代理承認者による追加の処理は、上述した副代理承認者による同様の処理動作を更に追加すればよく、その実現は容易に類推できるであろう。
【符号の説明】
【００４５】
１：サーバ １８：端末 １９：ネットワーク １０：案件管理システム
１０５：案件処理部 １０６：案件承認依頼処理部 １０７：代理承認者への切換え処理部 １０８：副代理承認者への切換え処理部
１０９：在席状態変更による承認者切換え処理部 １１０：承認者在席状態変更時の案件承認者切換え処理部 １１１：在席から不在へ変更時の案件承認者切換え処理部 １１２：承認者在席から不在へ変更時の案件承認者切換え処理部 １１３：代理承認者在席から不在へ変更時の案件承認者切換え処理部 １１４：副代理承認者在席から不在へ変更時の案件承認者切換え処理部 １１５：不在から在席へ変更時の案件承認者切換え処理部
１１６：メール処理部 １１７：承認依頼通知メール処理部 １１８：共通処理部 １１９：在席フラグ取得処理部
１２０：在席マスタ １２１：案件マスタ １２２：ルート承認者正副マスタ １２３：メッセージマスタ １２４：ユーザマスタ。
【技術分野】
【０００１】
本発明は、ワークフローシステムに係り、特に、承認者の在席状態を把握して、適宜、最適な承認者を自動選択する、ワークフローシステム及びその機能を実現するプログラムに関するものである。
【背景技術】
【０００２】
ワークフローシステムの回覧自動選択機能を実現するための種々の技術が提案されている。例えば、特許文献１には、ワークフローシステムにおいて、回覧経路が決まっている業務が複数存在する場合、データ作成時に予め、回覧経路を付加情報として設定し、作成したデータに対して最適な回覧経路を自動的に選択される手段を有することで、各回覧先において作業者が次の回覧先へ送信するための回覧経路を選択することなく、回覧を自動実行する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平９−８１４８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
現状、承認者の適切な承認を受けた上で業務処理が実行されたという承認証跡を残す手段として、ワークフローを利用したシステムが用いられている。業務処理に応じて各回覧経路が存在する場合、その最適な回覧経路を自動的に選択することは、特許文献1に記載の技術で実現可能であるが、次のような問題点が考えられる。
【０００５】
（１）自動的に選択された回覧経路上の承認者が不在の場合、そこで回覧が滞るために承認が受けられずに、業務処理が遅延してしまう可能性がある。それを回避するために、回覧者が随時承認者の在席状況を把握することが考えられるが、その時点での最適な承認者を選択して回覧を行うことは困難である。
【０００６】
（２）また、承認者が不在から在席状態に変更になった場合に、代理承認者に遷移した案件を再び承認者の処理に戻す場合に、遷移した案件と経路を把握した上でそれらを自らの処理に戻す作業は大変困難となる。
【０００７】
このように、従来では承認者が不在の場合にワークフロー回覧が滞留し、その結果、業務処理実行までに適切な承認を受けられずに業務処理作業が遅延し、また承認者が復帰したにも拘らず代理承認者に案件の処理が遷移したままとなり、処理を本来の処理者である承認者に戻すことが困難であるという不具合がある。
【０００８】
本発明の目的は、ワークフロー中の承認者の在席状況を把握し、その時点での最適な承認者を自動選択することで、案件の回覧を最適に早く実現することにより、ワークフロー回覧の滞留に起因する業務処理遅延を防止することにある。
【課題を解決するための手段】
【０００９】
本発明によるワークフローシステムは、好ましくは、ユーザにより操作される複数の端末がネットワークを介して接続される、サーバの処理装置でプログラムを実行することにより構築されるワークフローシステムであって、
案件の承認者及び代理承認者、又は副代理承認者を含むユーザの在席状態を管理する第１記憶手段と、承認を受ける対象の案件に関する情報を管理する第２の記憶手段と、案件の承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を管理するための第３記憶手段とを有し、更に
該処理装置でプログラムを実行することにより実現される；
いずれかの該端末から送信される承認者への案件の承認依頼要求に従って、該第３の記憶手段を参照して、該承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を特定し、更に該第１の記憶手段を参照して、特定された該承認者及び代理承認者、又は副代理承認者の在席状態を把握する共通処理部と、
特定された該承認者及び代理承認者、又は副代理承認者の在席状態に応じて、処理可能な処理者に案件を遷移し、該第２の記憶手段を更新する案件処理部と、
特定された該承認者、代理承認者、又は副代理承認者からの在席状態に応じて、最適な承認者に案件処理を遷移させる、在席状態変更による承認者切換え処理部と、
該承認者切換え処理部により指定された最適な承認者へ承認依頼を通知するメール処理部を有することを特徴とするワークフローシステムとして構成される。
【００１０】
また、本発明によるワークフローシステム用プログラムは、好ましくは、ユーザにより操作される複数の端末がネットワークを介して接続される、サーバの処理装置でプログラムを実行することにより構築されるワークフローシステム用プログラムであって、
該処理装置で実行されることにより、
案件の承認者及び代理承認者、又は副代理承認者を含むユーザの在席状態を管理する第１記憶手段をアクセスし、承認を受ける対象の案件に関する情報を管理する第２の記憶手段をアクセスし、案件の承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を管理するための第３記憶手段をアクセスし、かつ、
いずれかの該端末から送信される承認者への案件の承認依頼要求に従って、該第３の記憶手段を参照して、該承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を特定し、更に該第１の記憶手段を参照して、特定された該承認者及び代理承認者、又は副代理承認者の在席状態を把握する共通処理部と、
特定された該承認者及び代理承認者、又は副代理承認者の在席状態に応じて、処理可能な処理者に案件を遷移し、該第２の記憶手段を更新する案件処理部と、
特定された該承認者、代理承認者、又は副代理承認者からの在席状態に応じて、最適な承認者に案件処理を遷移させる、在席状態変更による承認者切換え処理部と、
該承認者切換え処理部により指定された最適な承認者へ承認依頼を通知するメール処理部を実現することを特徴とするワークフローシステム用プログラムとして構成される。
【発明の効果】
【００１１】
本発明によれば、承認者不在時に最適な他の承認者に自動的に処理が遷移し、また承認者の在席状態が変更になった際に自動的に処理が遷移することが可能となる。これにより、案件が承認者に回覧された時点、或いは承認者の在席状態が変更になった時点で最適な回覧者を自動的に選択でき、ワークフロー回覧の滞留による業務処理遅延を防止することが可能となる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施例によるワークフローシステムの全体を示す図である。
【図２Ａ】一実施例による案件承認依頼処理部１０６の処理動作を説明するフローチャートである。
【図２Ｂ】一実施例による案件承認依頼処理部１０６の処理動作を説明するフローチャートである。
【図３】一実施例による代理承認者への切換え処理部１０７の処理動作を説明するフローチャートである。
【図４】一実施例による副代理承認者への切換え処理部１０８の処理動作を説明するフローチャートである。
【図５】一実施例による承認者在席状態変更時の案件承認者切換え処理部１１０の処理動作を説明するフローチャートである。
【図６】一実施例による在席から不在へ変更時の案件承認者切換え処理部１１１の処理動作を説明するフローチャートである。
【図７】一実施例による承認者在席から不在へ変更時の案件承認者切換え処理部１１２の処理動作を説明するフローチャートである。
【図８】一実施例による代理承認者在席から不在へ変更時の案件承認者切換え処理部１１３の処理動作を説明するフローチャートである。
【図９】一実施例による副代理承認者在席から不在へ変更時の案件承認者切換え処理部１１４の処理動作を説明するフローチャートである。
【図１０】一実施例による不在から在席へ変更時の案件承認者切換え処理部１１５の処理動作を説明するフローチャートである。
【図１１】一実施例による承認依頼通知メール処理部１１７の処理動作を説明するフローチャートである。
【図１２】一実施例による在席フラグ取得処理部１１９の処理動作を説明するフローチャートである。
【図１３】一実施例による在席マスタテーブルの構成例を示す図である。
【図１４】一実施例による案件マスタテーブルの構成例を示す図である。
【図１５】一実施例によるルート承認者正副マスタテーブルの構成例を示す図である。
【図１６】一実施例によるメッセージマスタテーブルの構成例を示す図である。
【図１７】一実施例によるユーザマスタテーブルの構成例を示す図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して、本発明の好適な実施例について詳細に説明する。
図１は一実施例によるワークフローシステムの全体構成を示す。
ワークフローシステムは、サーバ１に案件管理システム１０が構築されることで実現する。サーバ１には、ネットワーク１９を介してユーザにより操作される複数の端末１８が接続される（都合上１台の端末１８のみ図示）。サーバ１は、処理装置（ＣＰＵ）、記憶装置、主メモリ、キーボード、マウス等の入力装置及び表示装置を有し、ＣＰＵで所定のプログラムが実行されることで、案件管理システム１０の各処理部の機能が構築される。
【００１４】
この案件管理システム１０は、案件処理部１０５、在席状態変更による承認者切換え処理部１０９、メール処理部１１６、共通処理部１１８、及び在席マスタ１２０、案件マスタ１２１、ルート承認者正副マスタ１２２、メッセージマスタ１２３、ユーザマスタ１２４の各データベース（ＤＢという）から構成される。
【００１５】
上記４つの処理部は、それぞれ以下の処理部により構成される。
案件処理部１０５は、案件承認依頼処理部１０６、代理承認者への切換え処理部１０７、副代理承認者への切換え処理部１０８により構成される。
在席状態変更による承認者切換え処理部１０９は、承認者在席状態変更時の案件承認者切換え処理部１１０、在席から不在へ変更時の案件承認者切換え処理部１１１、承認者在席から不在へ変更時の案件承認者切換え処理部１１２、代理承認者在席から不在へ変更時の案件承認者切換え処理部１１３、副代理承認者在席から不在へ変更時の案件承認者切換え処理部１１４、不在から在席へ変更時の案件承認者切換え処理部１１５により構成される。
メール処理部１１６は、承認依頼通知メール処理部１１７により構成される。共通処理部１１８は、在席フラグ取得処理部１１９により構成される。
なお、上記各処理部の処理動作については、フローチャートを参照して詳述する。
【００１６】
次に、各ＤＢの構成について説明する。
図１３は在席マスタテーブル１２０の構成例を示す。
在席マスタテーブル１２０は、システム利用者に固有の「ユーザＩＤ」と、ユーザの在席状況を示す「在席フラグ」の項目を１つのレコードとして、複数のレコードを格納するように構成される。ここで、在席フラグは、在席時は「１」、不在時は「０」で表される。この各レコードによりユーザの在席状況を特定することができる。
【００１７】
図１４は案件マスタテーブル１２１の構成例を示す。
案件マスタテーブル１２１は、案件管理システム１０内で案件を一意に示すシステム内部用ＩＤとしての「案件ＩＤ」と、案件管理システム１０内で案件を一意に示す「案件ＩＤ」に紐付く「案件コード」と、現在の案件処理者のユーザＩＤを示す「現処理者ＩＤ」と、現在の案件のルート位置を示す「ルート表示ＩＤ」と、案件を登録したユーザのＩＤを示す「登録者ＩＤ」と、案件を登録した日時を示す「登録日時」と、案件を更新した直近のユーザのＩＤを示す「更新者ＩＤ」と、案件を更新した直近の日時を示す「更新日時」と、現処理者ＩＤにセットされている承認者の立場を示す「案件承認者立場フラグ」の各項目を１つのレコードとして、複数のレコードを格納するように構成される。ここで、「案件承認者立場フラグ」に関して、承認者は「1」、代理承認者は「２」、副代理承認者は「３」、その他は「０」で表される。この各レコードにより案件を特定することができる。
【００１８】
図１５はルート承認者正副マスタテーブル１２２の構成例を示す。
ルート承認者正副マスタテーブル１２２は、ルート位置を示す「ルートＩＤ」と、ルートに対する承認者のユーザＩＤを示す「承認者ＩＤ」と、ルートに対する代理承認者のユーザＩＤを示す「代理承認者ＩＤ」と、ルートに対する副代理承認者のユーザＩＤを示す「副代理承認者ＩＤ」の各項目を１つのレコードとして、複数のレコードを格納するように構成される。このレコードによりルートに対する承認者及び代理承認者、副代理承認者を特定することができる。
【００１９】
図１６はメッセージマスタテーブル１２３の構成例を示す。
メッセージマスタテーブル１２３は、メッセージを一意に表す「メッセージＩＤ」と、メッセージＩＤに対するメッセージ内容を示す「メッセージ内容」の項目を１つのレコードとして、複数のレコードを格納するように構成される。このレコードによりメッセージの内容を特定することができる。
【００２０】
図１７はユーザマスタテーブル１２４の構成例を示す。
ユーザマスタテーブル１２４は、案件管理システム１０内でユーザを一意に表す「ユーザＩＤ」と、ユーザの氏名を表す「氏名」と、ユーザが所属する会社ＩＤを表す「会社ＩＤ」と、ユーザが所属する組織ＩＤを表す「組織ＩＤ」と、ユーザのメールアドレスを表す「メールアドレス」の各項目を１つのレコードとして、複数のレコードを格納するように構成される。このレコードによりユーザの情報を特定することができる。
【００２１】
次に、図２Ａ〜図２Ｂを参照して、案件承認依頼処理部１０６による処理動作について説明する。
（１）端末１８のユーザの操作により承認者への案件承認依頼要求が開始されると、承認依頼があった案件の案件ＩＤがサーバ１へ送信され、サーバ１はその要求を保持する（Ｓ２０１）。
（２）メッセージＩＤに値"１０１"をセットする（Ｓ２０２）。
（３）Ｓ２０１で保持した案件ＩＤをキーに、案件マスタ１２１を参照して、案件ＩＤが一致したレコードのルート表示ＩＤを取得する（Ｓ２０３〜Ｓ２０５）。
（４）Ｓ２０５で取得したルート表示ＩＤをキーに、ルート承認者正副マスタ２０７を参照して、ルート承認者正副マスタ２０７のルートＩＤとルート表示ＩＤが一致したレコードの承認者ＩＤ及び代理承認者ＩＤ、副代理承認者ＩＤを取得する（Ｓ２０６〜２０８）。
【００２２】
（５）Ｓ２０８で取得した承認者ＩＤを在席フラグ取得処理Ｓ２０９に送信し、在席フラグ取得処理Ｓ２０９の処理結果である承認者の在席フラグの値を取得する（Ｓ２０９）。
（６）取得した承認者の在席フラグを判定して、在席を示す値"１"であれば、Ｓ２０１で保持した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"１"をセットする。その後、承認依頼通知メール処理２２１へ遷移する。
一方、在席フラグが不在を示す値"０"であれば、Ｓ２０８で取得した代理承認者ＩＤのNULLチェックを行う（Ｓ２１０〜２１２）。
【００２３】
（７）Ｓ２０８で取得した代理承認者ＩＤがNULLであるか、Not NULLであるかを判定し、NULLであった場合は２１６へ遷移する。一方、Not NULLであった場合、代理承認者ＩＤを代理承認者への切換え処理Ｓ２１４に送信し、代理承認者への切換え処理Ｓ２１４の処理結果である代理承認者の在席フラグの値を取得する（Ｓ２１３〜２１４）。
（８）取得した代理承認者の在席フラグを判定し、在席を示す値"１"であれば、承認依頼通知メール処理Ｓ２２１へ遷移する。一方、在席フラグが不在を示す値"０"であれば、Ｓ２０８で取得した副代理承認者ＩＤのNULLチェックを行う（Ｓ２１５）。
【００２４】
（９）Ｓ２０８で取得した副代理承認者ＩＤがNULLであるか、Not NULLであるかを判定し、NULLであった場合はＳ２１９へ遷移する。一方、Not NULLであった場合、副代理承認者ＩＤを副代理承認者への切換え処理２１７へ送信し、副代理承認者への切換え処理Ｓ２１７の処理結果である副代理承認者の在席フラグの値を取得する（Ｓ２１６〜Ｓ２１７）。
（１０）取得した副代理承認者の在席フラグを判定し、在席を示す値"１"であれば、承認依頼通知メール処理Ｓ２２１へ遷移する。在席フラグが不在を示す値"０"であれば、Ｓ２０１で保持した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"１"をセットする（Ｓ２１８〜２２０）。
（１１）最後に、セットされたメッセージＩＤを承認依頼通知メール処理へ送信して（Ｓ２２１、一連の処理を終了する。
【００２５】
次に、図３を参照して、代理承認者への切換え処理部１０７による処理動作（Ｓ２１４）について説明する。
（１）この処理は、Ｓ２１３の処理から送信された代理承認者ＩＤを取得して、処理が開始される。まず、Ｓ２１３の処理から送信された代理承認者ＩＤを在席フラグ取得処理３０１に送信し、在席フラグ処理３０１の処理結果である代理承認者の在席フラグの値を取得する（Ｓ３０１）。
（２）取得した代理承認者の在席フラグを判定し、その判定の結果、在席を示す値"１"であれば、Ｓ２０１で保持した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に代理承認者ＩＤをセットし、また案件承認者立場フラグ列に"２"をセットする。その後、メッセージＩＤに値"１０２"をセットして、代理承認者への切換え処理１０７を完了する。
上記判定Ｓ３０２の結果、在席フラグが不在を示す値"０"であれば、Ｓ３０３〜Ｓ３０５の処理を行わず、代理承認者への切換え処理部１０７による処理を完了する（Ｓ３０２〜３０５）。
【００２６】
次に、図４を参照して、副代理承認者への切換え処理部１０８による処理動作（Ｓ２１７）について説明する。
（１）この処理は、Ｓ２１６の処理から送信された副代理承認者ＩＤを取得して処理が開始される。まず、Ｓ２１６の処理から送信された副代理承認者ＩＤを在席フラグ取得処理４０１に送信し、在席フラグ処理４０１の処理結果である副代理承認者の在席フラグの値を取得する（Ｓ４０１）。
（２）取得した副代理承認者の在席フラグを判定し、その結果、在席を示す値"１"であれば、Ｓ２０１で保持した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に副代理承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"３"をセットする。その後、メッセージＩＤに値"１０３"をセットして、副代理承認者への切換え処理１０８の処理を完了する。
一方、上記判定Ｓ４０２の結果、在席フラグが不在を示す値"０"であれば、Ｓ４０３〜Ｓ４０５の処理を行わず、副代理承認者への切換え処理部１０８の処理を完了する（Ｓ４０２〜Ｓ４０５）。
【００２７】
次に、図５を参照して、承認者在席状態変更時の案件承認者切換え処理部１１０の処理動作について説明する。
（１）この処理は、端末を使用するユーザからの在席フラグの入力により開始される。まず、ユーザが端末１８に入力した在席フラグがサーバ１へ送信され、サーバ１はそれを保持する（Ｓ５０１）。
（２）在席フラグを送信したユーザのユーザＩＤをキーに、在席マスタ１２０を参照して、在席マスタ１２０のユーザＩＤと一致したレコードの在席フラグを取得する（Ｓ５０２〜Ｓ５０４）。
【００２８】
（３）次に、Ｓ５０１で取得したユーザ入力の在席フラグと、Ｓ５０４で取得した在席フラグを比較する（Ｓ５０５）。その結果、ユーザ入力の在席フラグとＳ５０４で取得した在席フラグが一致した場合は、Ｓ５０６〜Ｓ５０８の処理を行わず、承認者在席状態変更時の案件承認者切換え処理部１１０の処理を完了する。一方、上記比較Ｓ５０５の結果、ユーザ入力の在席フラグとＳ５０４で取得した在席フラグが不一致の場合は、ユーザ入力の在席フラグの値判定を行う。
（４）Ｓ５０１で取得したユーザ入力の在席フラグを判定し（Ｓ５０６）、不在を示す値"０"であれば、在席から不在へ変更時の案件承認者切換え処理Ｓ５０７へ遷移する。一方、在席フラグが在席を示す値"１"であれば、不在から在席へ変更時の案件承認者切換え処理Ｓ５０８へ遷移する（Ｓ５０６〜Ｓ５０８）。
【００２９】
次に、図６を参照して、在席から不在へ変更時の案件承認者切換え処理部１１１の処理動作について説明する。
（１）Ｓ５０１で在席フラグを送信したユーザのユーザＩＤをキーに案件マスタ１２１を参照して、案件マスタの現処理者ＩＤとユーザＩＤが一致したレコードの案件ＩＤを取得する（Ｓ６０１〜Ｓ６０３）。
（２）そして、現処理者ＩＤとユーザＩＤが一致したレコード数が０件か判定し（Ｓ６０４）、その結果、０件ならばＳ６０５〜Ｓ６１５の処理を行わず、在席から不在へ変更時の案件承認者切換え処理部１１１の処理を完了する。
一方、判定の結果、現処理者ＩＤとユーザＩＤが一致したレコード数が０件でない場合、Ｓ６０５の処理へ遷移する（Ｓ６０４）。
【００３０】
（３）そして、Ｓ６０３で取得した案件ＩＤをキーに、案件マスタ１２１を参照し、案件ＩＤが一致したレコードのルート表示ＩＤを取得する（Ｓ６０５〜Ｓ６０７）。
（４）Ｓ５０１で在席フラグを送信したユーザのユーザＩＤとＳ６０７で取得したルート表示ＩＤをキーに、ルート承認者正副マスタ１２２を参照して、ルートＩＤが一致したレコードの承認者ＩＤ列の値とユーザＩＤが一致した場合、承認者在席から不在へ変更時の案件承認者切換え処理Ｓ６１１へ遷移する。一方、ルートＩＤが一致したレコードの承認者ＩＤ列の値とユーザＩＤが不一致の場合、Ｓ６１２の処理へ遷移する（Ｓ６０８〜Ｓ６１１）。
【００３１】
（５）ルートＩＤが一致したレコードの代理承認者ＩＤ列の値とユーザＩＤが一致した場合、代理承認者在席から不在へ変更時の案件承認者切換え処理６１３へ遷移する。一方、ルートＩＤが一致したレコードの代理承認者ＩＤ列の値とユーザＩＤが不一致の場合、Ｓ６１４の処理へ遷移する（Ｓ６１２〜Ｓ６１３）。
（６）ルートＩＤが一致したレコードの副代理承認者ＩＤ列の値とユーザＩＤが一致した場合、副代理承認者在席から不在へ変更時の案件承認者切換え処理Ｓ６１５へ遷移する。一方、ルートＩＤが一致したレコードの副代理承認者ＩＤ列の値とユーザＩＤが不一致の場合、Ｓ６１５の処理を行わず、在席から不在へ変更時の案件承認者切換え処理部１１１の処理を完了する（Ｓ６１４〜Ｓ６１５）。
【００３２】
次に、図７を参照して、承認者在席から不在へ変更時の案件承認者切換え処理部１１２の処理動作について説明する。
（１）Ｓ６０７で取得したルート表示ＩＤをキーにルート承認者正副マスタＳ７０２を参照して、ルート承認者正副マスタ７０２のルートＩＤの値とルート表示ＩＤが一致したレコードの代理承認者ＩＤと副代理承認者ＩＤを取得する（Ｓ７０１〜７０３）。
（２）次に、Ｓ７０３で取得した代理承認者ＩＤがNULLであるか、Not NULLであるかを判定する（Ｓ７０４）。その結果、NULLの場合はＳ７１１の処理へ遷移する。Not NULLの場合、代理承認者ＩＤを在席フラグ取得処理７０５に送信し、在席フラグ取得処理Ｓ７０５の処理結果である代理承認者の在席フラグの値を取得する（Ｓ７０５）。
（３）次に、Ｓ７０５で取得した代理承認者の在席フラグの値を判定する（Ｓ７０６）。その結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に代理承認者ＩＤをセットし、また案件承認者立場フラグ列に"２"をセットする。メッセージＩＤに値"１０２"をセットし、その後承認依頼通知メール処理Ｓ７１０へ遷移する。一方、在席フラグが不在を示す値"０"であれば、Ｓ６０３で取得した副代理承認者ＩＤのNULLチェックを行う（Ｓ７０６〜Ｓ７１０）。
【００３３】
（４）次に、Ｓ７０３で取得した副代理承認者ＩＤがNULLであるか、Not NULLであるかを判定する（Ｓ７１１）。その結果、NULLであった場合はＳ７１２〜７１７の処理を行わず、承認者在席から不在へ変更時の案件承認者切換え処理部１１２の処理を完了する。一方、Not NULLであった場合、副代理承認者ＩＤを在席フラグ取得処理７１２に送信し、在席フラグ取得処理７１２の処理結果である副代理承認者の在席フラグの値を取得する（Ｓ７１１〜Ｓ７１２）。
（５）次に、Ｓ７１２で取得した副代理承認者の在席フラグを判定する（Ｓ７１３）。その結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に副代理承認者ＩＤをセットし、また案件承認者立場フラグ列に"３"をセットする。また、メッセージＩＤに値"１０３"をセットし、その後承認依頼通知メール処理７１７へ遷移する。一方、在席フラグが不在を示す値"０"であれば、Ｓ７１４〜Ｓ７１７の処理を行わず、承認者在席から不在へ変更時の案件承認者切換え処理部１１２の処理を完了する（Ｓ７１３〜Ｓ７１７）。
【００３４】
次に、図８を参照して、代理承認者在席から不在へ変更時の案件承認者切換え処理部１１３の処理動作について説明する。
（１）Ｓ６０７で取得したルート表示ＩＤをキーに、ルート承認者正副マスタＳ８０２を参照し、ルート承認者正副マスタＳ８０２のルートＩＤの値とルート表示ＩＤが一致したレコードの承認者ＩＤと副代理承認者ＩＤを取得する（Ｓ８０１〜Ｓ８０３）。
（２）Ｓ８０３で取得した承認者ＩＤを在席フラグ取得処理Ｓ８０４に送信し、在席フラグ取得処理Ｓ８０４の処理結果である承認者の在席フラグの値を取得する（Ｓ８０４）。
（３）次に、Ｓ８０４で取得した承認者の在席フラグの値を判定する（Ｓ８０５）。判定の結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に承認者ＩＤをセットし、また案件承認者立場フラグ列に"１"をセットする。また、メッセージＩＤに値"１０１"をセットして、その後、承認依頼通知メール処理Ｓ８０９へ遷移する。一方、在席フラグが不在を示す値"０"であれば、Ｓ６０３で取得した副代理承認者ＩＤのNULLチェックを行う（Ｓ８０５〜Ｓ８０９）。
【００３５】
（４）Ｓ８０３で取得した副代理承認者ＩＤがNULLであるか、Not NULLであるかを判定する（Ｓ８１０）。その結果、NULLであった場合はＳ８１１〜Ｓ８１６の処理を行わず、代理承認者在席から不在へ変更時の案件承認者切換え処理部１１３の処理を完了する。
一方、Not NULLであった場合、副代理承認者ＩＤを在席フラグ取得処理８１１に送信し、在席フラグ取得処理Ｓ８１１の処理結果である副代理承認者の在席フラグの値を取得する（Ｓ８１０〜Ｓ８１１）。
（５）次に、Ｓ８１１で取得した副代理承認者の在席フラグを判定する（Ｓ８１２）。その結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に副代理承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"３"をセットする。また、メッセージＩＤに値"１０３"をセットし、その後、承認依頼通知メール処理Ｓ８１６へ遷移する。
一方、在席フラグが不在を示す値"０"であれば、Ｓ８１３〜８１６の処理を行わず、代理承認者在席から不在へ変更時の案件承認者切換え処理部１１３の処理を完了する（Ｓ８１２〜Ｓ８１６）。
【００３６】
次に、図９を参照して、副代理承認者在席から不在へ変更時の案件承認者切換え処理部１１４の処理動作について説明する。
（１）Ｓ６０７で取得したルート表示ＩＤをキーに、ルート承認者正副マスタ９０２を参照して、ルート承認者正副マスタ９０２のルートＩＤの値とルート表示ＩＤが一致したレコードの承認者ＩＤと代理承認者ＩＤを取得する（Ｓ９０１〜Ｓ９０３）。
（２）Ｓ９０３で取得した承認者ＩＤを在席フラグ取得処理９０４に送信し、在席フラグ取得処理Ｓ９０４の処理結果である承認者の在席フラグの値を取得する（Ｓ９０４）。
（３）Ｓ９０４で取得した承認者の在席フラグの値を判定し（Ｓ９０５）、その結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"１"をセットする。またメッセージＩＤに値"１０１"をセットし、その後、承認依頼通知メール処理Ｓ９０９へ遷移する。
一方、在席フラグが不在を示す値"０"であれば、Ｓ６０３で取得した代理承認者ＩＤのNULLチェックを行う（Ｓ９０５〜Ｓ９０９）。
【００３７】
（４）次に、Ｓ９０３で取得した代理承認者ＩＤがNULLであるか、Not NULLであるかを判定する（Ｓ９１０）。その結果、NULLであった場合はＳ９１１〜Ｓ９１６の処理を行わず、副代理承認者在席から不在へ変更時の案件承認者切換え処理部１１４の処理を完了する。
一方、Not NULLであった場合、代理承認者ＩＤを在席フラグ取得処理Ｓ９１１に送信し、在席フラグ取得処理Ｓ９１１の処理結果である代理承認者の在席フラグの値を取得する（Ｓ９１０〜Ｓ９１１）。
（５）Ｓ９１１で取得した代理承認者の在席フラグを判定し（Ｓ９１２）、その結果、在席を示す値"１"であれば、Ｓ６０３で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に代理承認者ＩＤをセットし、また案件承認者立場フラグ列に"２"をセットする。また、メッセージＩＤに値"１０２"をセットし、その後、承認依頼通知メール処理Ｓ９１６へ遷移する。
一方、在席フラグが不在を示す値"０"であれば、Ｓ９１３〜Ｓ９１６の処理を行わず、副代理承認者在席から不在へ変更時の案件承認者切換え処理部１１４の処理を完了する（Ｓ９１２〜Ｓ９１６）。
【００３８】
次に、図１０を参照して、不在から在席へ変更時の案件承認者切換え処理部１１５の処理動作について説明する。
（１）案件マスタ１２１を参照して、１レコード目の案件ＩＤ、現処理者ＩＤ、ルート表示ＩＤ及び案件承認者立場フラグを取得する（Ｓ１００１〜Ｓ１００２）。
（２）Ｓ１００１で取得した案件承認者立場フラグの値を判定する（Ｓ１００３）。その結果、その他を示す値"０"もしくは承認者を示す値"１"であれば、Ｓ１０１７の処理へ遷移する。一方、案件承認者立場フラグの値が"０"もしくは"１"以外の場合はＳ１００４の処理へ遷移する（Ｓ１００３）。
（３）次に、Ｓ５０１で取得したユーザＩＤ及びＳ１００１で取得したルート表示ＩＤをキーに、ルート承認者正副マスタＳ１００５を参照して、Ｓ１００１で取得したルート表示ＩＤとルート承認者正副マスタＳ１００５のルートＩＤが一致したレコードを取得する（Ｓ１００４）。
【００３９】
（４）Ｓ１００４で取得したレコードの承認者ＩＤの値とＳ５０１で取得したユーザＩＤの値を判定し（Ｓ１００６）、その結果、一致した場合はＳ１００１で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの現処理者ＩＤ列に、承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"１"をセットする。またメッセージＩＤに値"１０１"をセットし、その後、承認依頼通知メール処理Ｓ１０１０へ遷移する。
一方、Ｓ１００４で取得したレコードの承認者ＩＤの値とＳ５０１で取得したユーザＩＤの値が一致しなかった場合、Ｓ１０１１の案件承認者立場フラグの判定処理へ遷移する（Ｓ１００７〜Ｓ１０１１）。
（５）Ｓ１００１で取得した案件承認者立場フラグの値を判定し（Ｓ１０１１）、その結果、副代理承認者を示す値"３"であれば、Ｓ１０１２の処理へ遷移する。案件承認者立場フラグの値が"３"以外の場合はＳ１０１７の処理へ遷移する（Ｓ１０１１）。
【００４０】
（６）Ｓ１００４で取得したレコードの代理承認者ＩＤの値とＳ５０１で取得したユーザＩＤの値を判定し（Ｓ１０１２）、その結果、一致した場合はＳ１００１で取得した案件ＩＤと案件マスタ１２１の案件ＩＤが一致するレコードの"現処理者ＩＤ列に代理承認者ＩＤをセットし、かつ案件承認者立場フラグ列に"２"をセットする。またメッセージＩＤに値"１０２"をセットし、その後、承認依頼通知メール処理１０１６へ遷移する。
一方、Ｓ１００４で取得したレコードの代理承認者ＩＤの値とＳ５０１で取得したユーザＩＤの値が一致しなかった場合、Ｓ１０１７の処理へ遷移する（Ｓ１０１２〜Ｓ１０１６）。
（７）次に、案件マスタ１２１のレコード位置を取得し、その位置が案件マスタ１２１の最終レコードの場合、不在から在席へ変更時の案件承認者切換え処理部１１５の処理を完了する。一方、案件マスタ１２１のレコード位置が最終でなかった場合、案件マスタ１２１の処理対象レコードを次のレコードに移し、Ｓ１００１の処理へ遷移する（Ｓ１０１７〜Ｓ１０２１）。
【００４１】
次に、図１１を参照して、承認依頼通知メール処理部１１７の処理動作について説明する。
（１）案件処理部１０５や在席状態変更による承認者切換え処理部１０９の処理内でセットされたメッセージＩＤをキーにメッセージマスタ１２３を参照し、メッセージマスタ１２３のメッセージＩＤの値と一致したレコードのメッセージ内容を取得する（Ｓ１１０１〜Ｓ１１０３）。
（２）現処理者にセットされているユーザＩＤをキーに、ユーザマスタ１１０５を参照して、ユーザマスタ１２４のユーザＩＤの値と一致したレコードのメールアドレスを取得する（Ｓ１１０４〜Ｓ１１０６）。
（３）Ｓ１１０３で取得したメッセージ内容と、Ｓ１１０６で取得したメールアドレスを電子メールＳ１１０８のメール本文、送信先メールアドレスにそれぞれセットして電子メールＳ１１０８を送付し、承認依頼通知メール処理１１７を完了する（Ｓ１１０７〜Ｓ１１０８）。
【００４２】
次に、図１２を参照して、在席フラグ取得処理部１１９の処理動作について説明する。
（１）在席フラグ取得処理部１１９に引き渡されたユーザＩＤをキーに在席マスタ１２０を参照して、在席マスタ１２０のユーザＩＤの値と一致したレコードの在席フラグを取得し、在席フラグ取得処理１１９を完了する（Ｓ１２０１〜Ｓ１２０３）。
【００４３】
以上説明した処理により、案件管理システム１０の承認者の在席状況に応じて、その時点での最適な承認者が自動的に選択され、それにより最適、最速の案件回覧が実現され、ワークフロー回覧の滞留による業務処理遅延を防止することが可能となる。
【００４４】
なお、本発明は上記実施例に限定されることなく、種々変形して実施することができるであろう。例えば、上記実施例では、承認のルートを承認者及び代理承認者、副代理承認者の順で設定しているが、副代理承認者が不要な場合もある。このような場合には、図１の案件管理システム及び関係するフローチャートから副代理承認者による処理部又は処理を削除して実現すればよい。逆に、副代理承認者が不在の場合、更に第二或いは第三の副代理者に承認を求めることもあり得る。このような場合には、図１の案件管理システム及び関係するフローチャートに第二或いは第三の副代理承認者による処理部又は処理を追加して実現すればよい。このような第二或いは第三の副代理承認者による追加の処理は、上述した副代理承認者による同様の処理動作を更に追加すればよく、その実現は容易に類推できるであろう。
【符号の説明】
【００４５】
１：サーバ １８：端末 １９：ネットワーク １０：案件管理システム
１０５：案件処理部 １０６：案件承認依頼処理部 １０７：代理承認者への切換え処理部 １０８：副代理承認者への切換え処理部
１０９：在席状態変更による承認者切換え処理部 １１０：承認者在席状態変更時の案件承認者切換え処理部 １１１：在席から不在へ変更時の案件承認者切換え処理部 １１２：承認者在席から不在へ変更時の案件承認者切換え処理部 １１３：代理承認者在席から不在へ変更時の案件承認者切換え処理部 １１４：副代理承認者在席から不在へ変更時の案件承認者切換え処理部 １１５：不在から在席へ変更時の案件承認者切換え処理部
１１６：メール処理部 １１７：承認依頼通知メール処理部 １１８：共通処理部 １１９：在席フラグ取得処理部
１２０：在席マスタ １２１：案件マスタ １２２：ルート承認者正副マスタ １２３：メッセージマスタ １２４：ユーザマスタ。
【特許請求の範囲】
【請求項１】
ユーザにより操作される複数の端末がネットワークを介して接続される、サーバの処理装置でプログラムを実行することにより構築されるワークフローシステムであって、
案件の承認者及び代理承認者、又は副代理承認者を含むユーザの在席状態を管理する第１記憶手段と、
承認を受ける対象の案件に関する情報を管理する第２の記憶手段と、
案件の承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を管理するための第３記憶手段を有し、
更に該処理装置でプログラムを実行することにより実現される；
いずれかの該端末から送信される承認者への案件の承認依頼要求に従って、該第３の記憶手段を参照して、該承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を特定し、更に該第１の記憶手段を参照して、特定された該承認者及び代理承認者、又は副代理承認者の在席状態を把握する共通処理部と、
特定された該承認者及び代理承認者、又は副代理承認者の在席状態に応じて、処理可能な処理者に案件を遷移し、該第２の記憶手段を更新する案件処理部と、
特定された該承認者、代理承認者、又は副代理承認者からの在席状態に応じて、最適な承認者に案件処理を遷移させる、在席状態変更による承認者切換え処理部と、
該承認者切換え処理部により指定された最適な承認者へ承認依頼を通知するメール処理部を有することを特徴とするワークフローシステム。
【請求項２】
前記第１記憶手段は、ユーザに付与された固有のユーザＩＤに対応してユーザの在席状況を１つのレコードとして格納する、ユーザの在席状態を管理するための在席マスタテーブルにより構成され、
前記第２記憶手段は、案件ごと付与された固有の案件ＩＤに対応して、現在の案件処理者のユーザＩＤを示す現処理者ＩＤと、現在の案件のルート位置を示すルート表示ＩＤと、現処理者ＩＤにセットされている、承認者、代理承認者、副代理承認者の立場を示すフラグを１つのレコードとして格納する、案件を管理するための案件マスタテーブルにより構成され、
前記第３記憶手段は、承認のルート位置を示すルートＩＤと、ルートに対する承認者に固有の承認者ＩＤと、ルートに対する代理承認者に固有の代理承認者ＩＤと、ルートに対する副代理承認者に固有の副代理承認者ＩＤを１つのレコードとして格納する、レコードにより承認を受けるルートに対する承認者及び代理承認者、副代理承認者を管理するためのルート承認者正副マスタテーブルにより構成され、
第４記憶手段は、メッセージを一意に表すメッセージＩＤと、メッセージＩＤに対するメッセージ内容を示すメッセージ内容を１つのレコードとして格納する、メッセージの内容を管理するメッセージマスタテーブルにより構成されることを特徴とする請求項１のワークフローシステム。
【請求項３】
ユーザにより操作される複数の端末がネットワークを介して接続される、サーバの処理装置でプログラムを実行することにより構築されるワークフローシステム用プログラムであって、
該処理装置で実行されることにより、案件の承認者及び代理承認者、又は副代理承認者を含むユーザの在席状態を管理する第１記憶手段をアクセスし、
承認を受ける対象の案件に関する情報を管理する第２の記憶手段をアクセスし、
案件の承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を管理するための第３記憶手段をアクセスし、かつ、
いずれかの該端末から送信される承認者への案件の承認依頼要求に従って、該第３の記憶手段を参照して、該承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を特定し、更に該第１の記憶手段を参照して、特定された該承認者及び代理承認者、又は副代理承認者の在席状態を把握する共通処理部と、
特定された該承認者及び代理承認者、又は副代理承認者の在席状態に応じて、処理可能な処理者に案件を遷移し、該第２の記憶手段を更新する案件処理部と、
特定された該承認者、代理承認者、又は副代理承認者からの在席状態に応じて、最適な承認者に案件処理を遷移させる、在席状態変更による承認者切換え処理部と、
該承認者切換え処理部により指定された最適な承認者へ承認依頼を通知するメール処理部を実現することを特徴とするワークフローシステム用プログラム。
【請求項１】
ユーザにより操作される複数の端末がネットワークを介して接続される、サーバの処理装置でプログラムを実行することにより構築されるワークフローシステムであって、
案件の承認者及び代理承認者、又は副代理承認者を含むユーザの在席状態を管理する第１記憶手段と、
承認を受ける対象の案件に関する情報を管理する第２の記憶手段と、
案件の承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を管理するための第３記憶手段を有し、
更に該処理装置でプログラムを実行することにより実現される；
いずれかの該端末から送信される承認者への案件の承認依頼要求に従って、該第３の記憶手段を参照して、該承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を特定し、更に該第１の記憶手段を参照して、特定された該承認者及び代理承認者、又は副代理承認者の在席状態を把握する共通処理部と、
特定された該承認者及び代理承認者、又は副代理承認者の在席状態に応じて、処理可能な処理者に案件を遷移し、該第２の記憶手段を更新する案件処理部と、
特定された該承認者、代理承認者、又は副代理承認者からの在席状態に応じて、最適な承認者に案件処理を遷移させる、在席状態変更による承認者切換え処理部と、
該承認者切換え処理部により指定された最適な承認者へ承認依頼を通知するメール処理部を有することを特徴とするワークフローシステム。
【請求項２】
前記第１記憶手段は、ユーザに付与された固有のユーザＩＤに対応してユーザの在席状況を１つのレコードとして格納する、ユーザの在席状態を管理するための在席マスタテーブルにより構成され、
前記第２記憶手段は、案件ごと付与された固有の案件ＩＤに対応して、現在の案件処理者のユーザＩＤを示す現処理者ＩＤと、現在の案件のルート位置を示すルート表示ＩＤと、現処理者ＩＤにセットされている、承認者、代理承認者、副代理承認者の立場を示すフラグを１つのレコードとして格納する、案件を管理するための案件マスタテーブルにより構成され、
前記第３記憶手段は、承認のルート位置を示すルートＩＤと、ルートに対する承認者に固有の承認者ＩＤと、ルートに対する代理承認者に固有の代理承認者ＩＤと、ルートに対する副代理承認者に固有の副代理承認者ＩＤを１つのレコードとして格納する、レコードにより承認を受けるルートに対する承認者及び代理承認者、副代理承認者を管理するためのルート承認者正副マスタテーブルにより構成され、
第４記憶手段は、メッセージを一意に表すメッセージＩＤと、メッセージＩＤに対するメッセージ内容を示すメッセージ内容を１つのレコードとして格納する、メッセージの内容を管理するメッセージマスタテーブルにより構成されることを特徴とする請求項１のワークフローシステム。
【請求項３】
ユーザにより操作される複数の端末がネットワークを介して接続される、サーバの処理装置でプログラムを実行することにより構築されるワークフローシステム用プログラムであって、
該処理装置で実行されることにより、案件の承認者及び代理承認者、又は副代理承認者を含むユーザの在席状態を管理する第１記憶手段をアクセスし、
承認を受ける対象の案件に関する情報を管理する第２の記憶手段をアクセスし、
案件の承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を管理するための第３記憶手段をアクセスし、かつ、
いずれかの該端末から送信される承認者への案件の承認依頼要求に従って、該第３の記憶手段を参照して、該承認を受けるルートにおける承認者及び代理承認者、又は副代理承認者を特定し、更に該第１の記憶手段を参照して、特定された該承認者及び代理承認者、又は副代理承認者の在席状態を把握する共通処理部と、
特定された該承認者及び代理承認者、又は副代理承認者の在席状態に応じて、処理可能な処理者に案件を遷移し、該第２の記憶手段を更新する案件処理部と、
特定された該承認者、代理承認者、又は副代理承認者からの在席状態に応じて、最適な承認者に案件処理を遷移させる、在席状態変更による承認者切換え処理部と、
該承認者切換え処理部により指定された最適な承認者へ承認依頼を通知するメール処理部を実現することを特徴とするワークフローシステム用プログラム。
【図１】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１１−１１３３３１（Ｐ２０１１−１１３３３１Ａ）
【公開日】平成２３年６月９日（２０１１．６．９）
【国際特許分類】
【出願番号】特願２００９−２６９４４８（Ｐ２００９−２６９４４８）
【出願日】平成２１年１１月２７日（２００９．１１．２７）
【出願人】（０００１５２９８５）株式会社日立情報システムズ (409)
【公開日】平成２３年６月９日（２０１１．６．９）
【国際特許分類】
【出願日】平成２１年１１月２７日（２００９．１１．２７）
【出願人】（０００１５２９８５）株式会社日立情報システムズ (409)
[ Back to top ]