(57)【特許請求の範囲】
【請求項１】
サーバが、申請者が申請情報を申請するユーザ端末から申請情報を受け取って前記申請情報のワークフロー処理を実行するワークフロー処理システムであって、
前記ユーザ端末は、
表示部と、
前記サーバにより判定された前記申請情報の判定結果を前記ユーザ端末の表示部に表示する画面表示制御部であって、承認待ちの前記申請情報を含む申請情報の一覧を表示する第１の画面と、前記申請情報が所定の形式的な条件を満たしていると判定されて受け付けられた申請情報以外の他の申請情報の一覧を表示する第２の画面と、前記所定の形式的な条件以外の実体的な条件を満たしていないと判定されて過去の前記申請情報を蓄積したログファイルに記憶されている１つ前のサイクルに戻された申請情報と前記他の申請情報との一覧を表示する第３の画面と、を前記表示部に表示する前記画面表示制御部と、を備え、
前記サーバは、
前記申請情報が前記所定の形式的な条件を満たしているか否かを判定する第１の判定部と、
前記第２の画面が表示されることに並行して、前記第１の判定部により判定された前記申請情報が、前記実体的な条件を満たしているか否かを判定する第２の判定部であって、前記第１の判定部により判定された前記申請情報が前記実体的な条件を満たしていないと判定した場合、前記実体的な条件を満たしていない前記申請情報を、前記１つ前のサイクルの申請情報に上書きして申請前の状態に戻す前記第２の判定部と、を備え、
前記ユーザ端末の前記画面表示制御部は、前記第１の画面を表示した後、前記第１の判定部による判定結果として前記第２の画面を表示し、前記第２の画面が表示されることに並行して実行された前記第２の判定部による判定結果として前記第３の画面を表示する、
ことを特徴とするワークフロー処理システム。
【請求項２】
サーバが、申請者が申請情報を申請するユーザ端末から申請情報を受け取って前記申請情報のワークフロー処理を実行するワークフロー処理方法であって、
前記ユーザ端末が、承認待ちの前記申請情報を含む申請情報の一覧を第１の画面として表示部に表示する第１の画面表示ステップと、
前記サーバが、前記申請情報が前記所定の形式的な条件を満たしているか否かを判定する第１の判定ステップと、
前記ユーザ端末が、前記申請情報が所定の形式的な条件を満たしていると判定されて受け付けられた申請情報以外の他の申請情報の一覧を第２の画面として前記表示部に表示する第２の画面表示ステップと、
前記サーバが、前記第２の画面が表示されることに並行して、前記第１の判定ステップにおいて判定された前記申請情報が、前記実体的な条件を満たしているか否かを判定する第２の判定ステップであって、前記第１の判定ステップにおいて判定された前記申請情報が前記実体的な条件を満たしていないと判定した場合、前記実体的な条件を満たしていない前記申請情報を、過去の前記申請情報を蓄積したログファイルに記憶されている１つ前のサイクルの申請情報に上書きして申請前の状態に戻す前記第２の判定ステップと、
前記ユーザ端末が、前記所定の形式的な条件以外の実体的な条件を満たしていないと判定されて戻された前記１つ前のサイクルの申請情報と前記他の申請情報との一覧を第３の画面として前記表示部に表示する第３の表示ステップと、を含み、
前記ユーザ端末は、前記第１の画面を表示した後、前記第１の判定ステップにおける判定結果として前記第２の画面を表示し、前記第２の画面が表示されることに並行して実行された前記第２の判定ステップにおける判定結果として前記第３の画面を表示する、
ことを特徴とするワークフロー処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、大量なワークフローをストレスなく処理するワークフロー処理システム、及びその方法に関するものである。
【背景技術】
【０００２】
ワークフロー処理における複数ユーザの操作によるデータの整合性は、排他制御無しでは実現することは難しく、その制御を行わない場合には致命的なデータ不整合が生じてシステムとして成り立たなくなってしまう。一般的に排他制御を行おうとすると、各申請のステータスのみならず、申請者・各承認者の作業順序や処理ステータスを管理する必要がある。これらの管理にはキューイング（処理を指示された順番どおりに実施する為に、その順序性を含めて管理し実行すること）が必須となり、順序性を担保する為に大規模な並列処理が難しくなる。その結果、一度に処理できる件数が低下し、利用者から見たシステムの応答時間は長くなる。利用者が１件の処理を実施すればよいだけであれば、特に問題とならないが、大規模なワークフローシステムを活用する企業においては、ワークフローの承認を専門とする部署や人が必要となり、その際に１件あたりの応答時間が長いと待ち時間が多くなり、作業効率が著しく低下することになる。
【０００３】
そこで待ち時間を限りなく無くすことが作業効率改善となる点に着目し、結果画面表示処理とワークフロー処理を並列処理とすることによって、使用者は結果画面を即時に見ることができ、且つデータの整合性を確保することが可能になり、上記のようなシステム処理の待ち時間を回避でき、作業効率の向上を図ることが出来る。上記の関連技術として、データの書き込みを複数の記憶媒体に並列で行うことによって、全体での処理時間を短縮させる方法が知られている。（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−３０６３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一人当たりの月間平均ワークフロー申請数を５件、１ワークフローにおける平均承認回数は５段階、社員１万人の企業、月末日の定時前２時間にその３０％が集中する、と仮定した場合、５件/月  ×  ５段階  ×  １万人  ＝  ２５万トランザクション/月、２５万トランザクション ×  ３０％/２時間  ＝  75000トランザクション/２時間、
75000トランザクション ÷  ２時間  ＝  37500トランザクション/1時間、月末過渡期におけるワークフローの承認トランザクション数は３７５００／１時間となる。これを１件のワークフローを処理するのに要するシステム時間を１秒と仮定した場合、１０プロセスでの並列処理でキューイングを行ったとすると、
3600件/1時間  ×  １０並列  ＝  36000件/1時間で可能な処理件数、37500件  ÷  36000件  ＝  稼働率１０４％となり、稼働率は１０４％を超える。更にそれらの処理が平均的に実施されることは有り得ないので、２５％の偏りが発生すると仮定すると、１０４％ × １２５％ ＝  １３０％となり、瞬間稼働率が１３０％を超えることがわかる。これを利用者から見た応答時間に置き換えると、１件のワークフローの承認を行った際、その応答が返ってくるのに要する最大時間は、60分 × 超過30％ ＝ 18分となる。これは業務の観点から見ると、一人の承認担当者が複数の承認作業を短時間で実施する場合、例えば数分内に10件余の承認作業を実施する場合、3時間近い待ち時間を要することとなる。
【０００６】
この問題を解決する上で最も単純な手段は、必要環境の性能を最大限に高める事であり、無制限な費用を投じることが出来るのであれば、容易に待ち時間の短縮を実施することは可能である。例えば、上記特許文献１に開示された技術のように、データ記憶の際に、複数の記憶装置に分散して記録することによって、記憶装置に対する書き込みの時間を短縮する方法などがある。但し、この場合、単にサーバの処理速度や端末の表示速度が向上するだけであり、大規模システムの場合ネットワークにボトルネックが発生する事が容易に想像でき、本質的に問題を解決しているとはいえず、これを現状の社会環境では解決することは難しい。
【０００７】
本発明は、上記に鑑みてなされたものであって、ワークフロー使用者の待ち時間を短縮することが可能なワークフロー処理システム、及びその方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するために、本発明にかかるワークフロー処理システムは、ユーザ端末から申請情報を受け取って前記申請情報のワークフロー処理を実行するワークフロー処理システムであって、前記申請情報が所定の形式的な条件を満たしているか否かを判定する第１の判定部と、前記第１の判定部による前記申請情報の判定結果を前記ユーザ端末の表示部に表示する画面表示制御部と、前記第１の判定部により判定された前記申請情報が、前記所定の形式的な条件以外の実体的な条件を満たしているか否かを判定する第２の判定部と、を備えることを特徴とするワークフロー処理システムとして構成される。
【０００９】
また、本発明は、上記ワークフロー処理システムで実行されるワークフロー処理方法としても把握される。
【発明の効果】
【００１０】
本発明によれば、ワークフロー使用者の待ち時間を短縮することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態に係るコンピュータネットワークシステム１００の全体構成例を示す図である。
【図２】基幹業務システムサーバとワークフローサーバ２００のハードウェア構成例を示す図である。
【図３】業務基幹サーバ２００が記憶する申請情報テーブル４００のデータ構成例を示す図である。
【図４】業務基幹サーバ２００が記憶する申請情報チェック条件テーブル５００のデータ構成例を示す図である。
【図５】業務基幹サーバ２００が記憶する申請情報ロックテーブル６００のデータ構成例を示す図である。
【図６】ワークフローサーバ３００が記憶するワークフロー情報テーブル７００の処理を示すデータ構成例を示す図である。
【図７】ワークフローサーバ３００が記憶するワークフロー情報ロックテーブル８００の処理を示すデータ構成例を示す図である。
【図８】ワークフローサーバ３００が記憶するワークフローキューテーブル９００の処理を示すデータ構成例を示す図である。
【図９】業務基幹サーバ２００が実行する申請情報の内容チェック１０００の処理を示すフローチャートである。
【図１０】業務基幹サーバ２００が実行する申請情報のロック１１００の処理を示すフローチャートである。
【図１１】業務基幹サーバ２００が実行する申請情報の登録１２００の処理を示すフローチャートである。
【図１２】業務基幹サーバ２００が実行する申請情報のロック１３００の処理を示すフローチャートである。
【図１３】ワークフローサーバ３００が実行する画面表示１４００の処理を示すフローチャートである。
【図１４】ワークフローサーバ３００が実行するワークフロー情報のロック１５００の処理を示すフローチャートである。
【図１５】ワークフローサーバ３００が実行するワークフロー情報の承認者決定１６００の処理を示すフローチャートである。
【図１６】ワークフローサーバ３００が実行するワークフロー情報のロック解除１７００の処理を示すフローチャートである。
【図１７】ワークフローサーバ２００が実行する申請情報の戻し１８００の処理を示すフローチャートである。
【図１８】図９から図１７までの全体の流れを示すフローチャートである。
【図１９】ユーザ端末の表示部に表示される画面の例を示す図である。
【発明を実施するための形態】
【００１２】
以下、本発明の一実施例について、図面を参照して詳細に説明する。
【００１３】
図１は、本実施例に係るコンピュータネットワークシステム１００の全体構成例を示す図である。ワークフロー申請システム１００は、ネットワーク１０４を介して、基幹業務システムサーバ１０１と、ワークフローサーバ１０２と、複数のユーザ端末１０３に接続されて構成される。基幹業務システムサーバ１０１は申請情報に含まれるコンテンツを管理し、ワークフローサーバはワークフローに関わるルートやステータスを管理する。ユーザが直接意識する部分は基幹業務システムサーバ１０１となり、ワークフローサーバ１０２はバックエンドシステムとしてユーザが認識することは無い。申請された情報は基本的に基幹業務システムにて管理され、次の承認者の決定やワークフローの終了判定をワークフローサーバにて判定され、そのワークフロー情報の登録や更新が行われ、結果のみを基幹業務システムサーバ１０１にフィードバックされる。ユーザ端末１０３はユーザが申請・承認する為の入出力装置であり、ディスプレイ等の表示部（不図示）から申請状況の確認や、キーボード等の入力部（不図示）から過去の申請を検索することが可能となっている。
【００１４】
図２は、基幹業務システムサーバ１０１とワークフローサーバ１０２のハードウェア構成例を示す図である。基幹業務システムサーバ１０１は、制御部２０２と、ネットワークインタフェース部２０３と、記憶部２０１で構成され、記憶部２０１にはプログラム２１０として、申請情報の内容チェック機能２１１、申請情報のロック機能２１２、申請情報のロック解除機能２１３、申請情報の画面表示機能２１４を実現するためのプログラムがインストールされている。また、記憶部２０１にはテーブル２２０として、申請情報テーブル２２１と、申請情報チェック条件テーブル２２２と、申請情報ロックテーブル２２３が記憶されている。ワークフローサーバ１０２は、制御部３０２と、ネットワークインタフェース部３０３と、記憶部３０１で構成され、記憶部３０１にはプログラム３１０として、ワークフロー情報の内容チェック機能３１１、ワークフロー情報のロック機能３１２、ワークフロー情報のロック解除機能３１３を実現するためのプログラムがインストールされている。また、記憶部３０１にはテーブル３２０として、ワークフロー情報テーブル３２１と、ワークフロー情報ロックテーブル３２２と、ワークフローキューテーブル３２３が記憶されている。上記各部はバス（ＢＵＳ）によって接続されている。なお、上記各サーバの記憶部はミラーリング等の手法により二重化されており、上記各テーブルのほか、処理履歴が記録されたログファイルが格納されている。
【００１５】
ログファイルは、一般的な処理の履歴が記録されたものであるため特に図示していないが、例えば、後述するフローチャートにおける各処理（図９〜１８）での処理時刻と、処理内容やその結果とを対応付けたデータである。処理内容や処理結果の例としては、図９のチェック内容およびその結果、図１０および１２のロック情報によるチェックおよびその結果、図１１の申請情報テーブルに登録された情報、図１３の画面表示処理の内容およびその結果、図１４および１６のロック情報によるチェックおよびその結果、図１５の承認者決定やエラー検出結果、図１７の過去履歴情報の抽出結果が挙げられる。  なお、上記各サーバにインストールされたプログラムは、インストール可能な形式又は実行可能な形式のファイルであって、ＵＳＢ（Universal Serial Bus）メモリ等のコンピュータで読み取り可能な記録媒体に記録されて提供されたり、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。
【００１６】
図３は、記憶部２０１が記憶する申請情報テーブル２２１のデータ構成例を示す図である。申請情報テーブル２２１は、申請の内容を示す情報である申請情報を格納するテーブルである。図３に示すように、申請情報を識別するための申請番号４０１をキー項目とし、その申請情報の申請日４０２、ワークフローサーバ１０２と紐付けをする為のワークフロー番号４０３、そのワークフローがどんな状態にあるかを示すステータス４０４、その申請書の種別を判断するための申請種別４０５、申請情報の具体的な一または複数の項目内容４０６から構成される。
【００１７】
図３では、例えば、申請番号００００００１によって識別される申請情報は、２０１３年１０月１日に申請され、対応するワークフローの識別情報はＷＦ０００１であり、ステータスが申請中（未承認の状態）であることを示している。また、その申請情報は、申請情報の種別を示す申請種別が１０１（例えば、旅費精算）、その内訳である項目Ａ（例えば、電車代）、その金額である項目Ｂ（例えば、１３３円）、その区間である項目Ｃ（例えば、大森−蒲田間）等の情報を含んでいる。
【００１８】
図４は、記憶部２０１が記憶する申請情報チェック条件テーブル２２２のデータ構成例を示す図である。申請情報チェック条件テーブル２２２は、上記申請種別単位でのチェックすべき内容を格納するテーブルである。図４に示すように、申請種別５０１をキー項目とし、申請情報テーブル２２１の申請種別４０５と紐付けをする。また、申請情報チェック条件テーブル２２２は、チェック対象項目である対象５０２を上記申請種別５０１に対応付けて記憶し、各申請種別にてどの項目がチェック対象なのかを対象５０２により判断される。また、申請情報チェック条件テーブル２２２は、上記項目のチェック基準を示すチェック内容５０３に示された条件によりチェックを行う。尚、申請種別によっては該当レコードが無い場合もあり得るが、その場合は申請種別毎のチェックは行われない。図４では、例えば、申請種別が１０１である旅費精算の場合には、項目Ａである電車代が１０（千円）未満であることが条件であることを示している。
【００１９】
図５は、記憶部２０１が記憶する申請情報ロックテーブル２２３のデータ構成例を示す図である。申請情報ロックテーブル２２３は、どの申請情報がロック状態（誰かに操作されている状態）かを格納するテーブルである。図５に示すように、申請番号６０１をキー項目とし、申請情報ロックテーブル２２３に存在すればロック状態と判断する。図５では、例えば、申請番号００００００１により識別される申請情報は、申請当日の３時００分５５秒にロックが開始されたことを示している。このように、申請情報がロックされるたびに、ロック状態を開始した時刻が申請番号に対応付けて記録される。
【００２０】
図６は、ワークフローサーバ１０２の記憶部３０１が記憶するワークフロー情報テーブル３２１のデータ構成例を示す図である。ワークフロー情報テーブル３２１は、ワークフローの承認ルートや現処理者を含み、ワークフローを処理するために必要なワークフロー情報を格納するテーブルである。図６に示すように、ワークフロー番号７０１をキー項目とし、そのワークフローの状態を示すステータス７０３、そのワークフローの申請者を示す登録者７０４、その申請書の現在の処理者７０５（通常は承認者）、そのワークフローの終了や次の承認者を判断する為のルート７０６から構成される。図６では、ワークフロー番号７０１によって識別されるワークフローは、申請情報が２０１３年１０月１日に申請者の識別情報Ｓ２０２８によって識別される申請者により申請され、そのステータスが申請中であることを示している。また、現在は処理者の識別情報Ｓ２１２１により識別される処理者が処理中であり、その承認者により承認された後のワークフロー上のルート（次の承認者へのルート）はＤＤ（例えば、担当部署上長から経理部担当者への承認ルート）であることを示している。
【００２１】
図７は、記憶部３０１が記憶するワークフロー情報ロックテーブル３２２のデータ構成例を示す図である。ワークフロー情報ロックテーブル３２２は、どのワークフロー情報がロック状態（システムにて処理されている状態）かを格納するテーブルである。図７に示すように、ワークフロー番号８０１をキー項目とし、ワークフロー情報ロックテーブル３２２に存在すればロック状態と判断する。図７では、図５に示した場合と同様、例えば、申請番号００００００１により識別される申請情報は、申請当日の３時００分５５秒にロックが開始されたことを示している。
【００２２】
図８は、記憶部３０１が記憶するワークフローキューテーブル３２３のデータ構成例を示す図である。ワークフローキューテーブル３２３は、ワークフロー処理の順番を格納するテーブルである。図８に示すように、シーケンス番号９０１をキー項目とし、シーケンス番号の若い順にワークフロー番号９０２のワークフロー処理（申請・承認・更新・削除等のコミット処理）を実行していく。図８では、例えば、ワークフロー番号ＷＦ０００１によって識別されるワークフローは、２０１３年１月１日の１２時５０分１０秒にキューイングされ、最初に処理されることを示している。続いて、本システムで行われる処理について説明する。  図９は、基幹業務システムサーバ１０１にインストールされた申請情報の内容チェック機能２１１を実行するプログラム（以下、申請情報内容チェックプログラム）による処理およびその前後処理を示すシーケンス図である。本処理は、申請情報に含まれる各項目（例えば、図３に示した項目Ａ〜Ｃ）が、図４に示した申請情報チェック条件テーブル２２２に記憶されている条件を満たしているか否かをチェックするための処理である。後述するワークフロー情報の内容をチェックする処理（図１４〜１７）が、ワークフローを処理するための実体的な条件（例えば、承認者を決定するための条件）を満たしているか否かをチェックする処理であることに対して、本処理は、ワークフローを処理するための形式的な条件（例えば、申請日が先日付となっていないか、電車代が所定の金額未満であるかを判定するための条件）を満たしているか否かをチェックする処理である。
【００２３】
申請情報内容チェックプログラム２１１は、ユーザ端末１０３から実行された申請情報に基づくワークフロー処理の実行を要求する要求データをもとに申請情報テーブル２２３から申請済み処理中データを取得し（Ｓ１００１）、申請種別４０５をもとに申請情報チェック条件テーブル２２２からチェック対象データを取得し（Ｓ１００２）、上記要求データのワークフロー処理を要求してよいか否かについて判定する（Ｓ１００３）。例えば、申請情報の内容チェックプログラム２１１は、申請日が先日付となっていないか、電車代が所定の金額未満であるかをチェックする。
【００２４】
申請情報内容チェックプログラム２１１は、チェック内容に問題が無ければ終了とし（Ｓ１００４）、チェック内容に問題があればエラーメッセージを発行して処理を中断する（Ｓ１００５）。例えば、申請日が先日付となっていたり、電車代が所定の金額以上となっていると判定された場合には、形式的なチェックによりエラーが発生した旨を示すエラーメッセージを発行し、処理を中断する。尚、新規登録の場合は要求データに含まれる申請情報に申請種別があるため、申請情報テーブル２２３からの読み込みは行わず、その申請情報を直接参照する。申請情報テーブル２２１のデータ構造の詳細は図３で、申請情報チェック条件テーブル２２２のデータ構造の詳細は図４で述べた通りである。
【００２５】
図１０は、基幹業務システムサーバ１０１にインストールされた申請情報のロック機能２１２を実行するプログラム（以下、申請情報ロックプログラム）による処理およびその前後処理を示すシーケンス図である。
【００２６】
申請情報ロックプログラム２１２は、前提条件として上記申請情報内容チェックプログラム２１１が実行された後、そのチェック内容に問題が無い場合には申請情報ロックテーブル２２３から情報を抽出し（Ｓ１１０１）、ロック状態であるか否か確認し（Ｓ１１０２）、ロック状態でないことが確認された場合、申請情報ロックテーブル２２３にロック情報を記録する。一方、申請情報ロックプログラム２１２は、ロック状態であることが確認された場合には、既に他のユーザ端末１００からアクセスされていると判断し、エラーメッセージを出力して処理を中断する。申請情報ロックテーブル２２３のデータ構造の詳細は図５で述べた通りである。
【００２７】
図１１は、基幹業務システムサーバ１０１にインストールされた申請情報の登録機能２１３を実行するプログラム（以下、申請情報登録プログラム）による処理およびその前後処理を示すシーケンス図である。申請情報登録プログラム２１３は、前提条件として上記申請情報ロックプログラム２１２が実行された後、図９のＳ１００４でチェック内容に問題がないと判定された申請情報の申請番号及び付随情報を図３に示した申請情報テーブル２２１に書き込む（Ｓ１１０２）。具体的には、申請情報登録プログラム２１３は、登録される申請情報のうち、申請日、申請番号、ワークフロー番号を自動採番して設定し、申請種別、項目Ａ〜Ｃにユーザにより入力された値を設定し、新規の場合は申請中、継続の場合は承認済み、手続き完了の場合は完了をステータスに設定する。尚、登録処理が完了すると、申請情報の画面表示機能２１５を実行するプログラム（以下、申請情報画面表示プログラム、図１３）及びワークフロー情報のロック機能３１１を実行するプログラム（以下、ワークフロー情報ロックプログラム、図１４）が並行して実行される。
【００２８】
図１２は、基幹業務システムサーバ１０１にインストールされた申請情報のロック解除機能２１４を実行するプログラム（以下、申請情報ロック解除プログラム）による処理およびその前後処理を示すシーケンス図である。申請情報ロック解除プログラム２１４は、図５に示した申請情報ロックテーブル２２３からの情報を抽出し（Ｓ１３０１）、ロック状態であるか否か確認し（Ｓ１３０２）、ロック状態であることが確認された場合には申請情報ロックテーブル２２３から該当レコードを削除する（Ｓ１３０４）。このとき、申請情報ロック解除プログラム２１４は、以降のワークフロー処理を進めるため、ロックを解除したレコードの申請情報をワークフローサーバ１０２に送信する。一方、申請情報ロック解除プログラム２１４は、ロック状態でないことが確認された場合にはデータ不整合の可能性が考えられる為、エラーメッセージを表示して処理を中断する（Ｓ１３０３）。
【００２９】
図１３は、基幹業務システムサーバ１０１にインストールされた申請情報画面表示プログラムによる処理およびその前後処理を示すシーケンス図である。申請情報画面表示プログラム２１５は申請情報テーブル２２１から、図１１で登録された申請番号及び付随情報を含むレコードを抽出し（Ｓ１４０１）、抽出した情報の画面に表示する（Ｓ１４０２）。ユーザは、Ｓ１４０２において表示された画面を確認することにより、自身の申請情報がワークフロー処理されているか否かを確認することができる。この画面の例については図１９を用いて後述するが、本システムでは、申請情報について形式的にチェックした段階でその結果を画面上に表示するので、ユーザは、自身の申請情報がワークフロー処理されるか否かについての結果を速やかに確認することができるようになっている。
【００３０】
図１４は、ワークフローサーバ１０２にインストールされたワークフロー情報ロックプログラム３１１による処理およびその前後処理を示すシーケンス図である。ワークフロー情報ロックプログラム３１１は、図１２で基幹業務システムサーバ１０１から受信した申請情報に含まれるワークフロー番号を参照してワークフロー情報ロックテーブル３２２からの情報を抽出し（Ｓ１５０１）、ロック状態であるか否か確認し（Ｓ１５０２）、ロック状態でないことが確認された場合にはワークフロー情報ロックテーブル３２３にロック情報を記録する（Ｓ１５０４）。一方、ワークフロー情報ロックプログラム３１１は、ロック状態であることが確認された場合にはエラーメッセージを出力して処理を中断する（Ｓ１５０３）。ワークフロー情報ロックテーブル３２３のデータ構造の詳細は図５で述べた通りである。
【００３１】
なお、ワークフロー情報ロックプログラム３１１は、ロック情報を記録すると、ロック情報を記録した申請情報についてのワークフロー情報をワークフロー情報テーブル３２１に設定する。具体的には、ワークフロー情報ロックプログラム３１１は、ワークフロー番号、申請日、ステータスに申請情報と同項目の値を設定し、申請者に申請情報を申請したユーザのユーザＩＤ（申請情報とともに入力されている）を設定し、処理者にワークフローの現在の処理者（新規の場合には申請者）を設定する。また、ワークフロー情報ロックプログラム３１１は、図１２で基幹業務システムサーバ１０１から受信した申請情報に含まれる申請種別を参照し、申請情報ルートにあらかじめ定められたルート（例えば申請種別が旅費精算であれば、担当部署上長から経理部担当者への承認ルート）を設定する。
【００３２】
図１５は、ワークフローサーバ１０２にインストールされた承認者決定機能３１２を実行するプログラム（以下、承認者決定プログラム）による処理およびその前後処理を示すシーケンス図である。本処理は、ワークフローを処理するための実体的な条件を満たしているか否かをチェックする処理であり、以下ではその一例として承認者の決定について示しているが、他の実体的な条件（例えば、旅費精算であれば、目的地がクライアント企業の訪問先の駅であるか否か等）をチェックする処理であってもよい。
【００３３】
承認者決定プログラム３１２は、基幹業務システムサーバ１０１から要求されたワークフロー実行処理命令に基づき、ワークフロー情報テーブル３２１から処理中データを取得し（Ｓ１６０１）、図６に示したワークフロー情報テーブル３２１のルート７０６をもとに次の承認者を決定する（Ｓ１６０２）。例えば、承認者決定プログラム３１２は、会社の部署およびその部署の担当業務と、担当者およびその上長と対応付けた組織データベースを参照し、旅費精算業務の担当者（例えば、経理部の担当者）を読み出して、次の承認者として決定する。このように、本処理では、他のデータベースを参照する必要がある等、図４に示した申請情報チェック条件テーブル２２２だけではチェックができない条件についての処理を実行している。
【００３４】
承認者決定プログラム３１２は、承認者決定処理のエラーを検出し（Ｓ１６０３）、エラーが発生したことを検出した場合は処理を中断してエラーメッセージを出力し（Ｓ１６０４）、申請情報の戻し処理２１６（図１７）が実行され、処理は中断される。例えば、承認者決定プログラム３１２は、予め定められた旅費精算の予算と現時点での使用金額とを対応付けた予算テーブルを参照し、申請金額が予算内であるか否かを判定し、申請金額が予算を超えると判定した場合、エラーと判断する。一方、承認者決定プログラム３１２は、エラーが発生したことを検知しなかった場合には、ワークフロー番号７０１を参照してワークフロー情報テーブル３２１を更新する。例えば、承認者決定プログラム３１２は、ワークフロー情報テーブル３２１のステータスを承認１に更新し、処理者を承認者のユーザＩＤであるＳ２１２１に更新する。ワークフロー情報テーブル３２１のデータ構造の詳細は図６で述べた通りである。
【００３５】
図１６は、ワークフローサーバ１０２にインストールされたワークフロー情報のロック解除機能３１３を実行するプログラム（以下、ワークフロー情報ロック解除プログラム）による処理およびその前後処理を示すシーケンス図である。ワークフロー情報ロック解除プログラム３１３は、ワークフロー情報ロックテーブル３２２から情報を抽出し（Ｓ１７０１）、ロック状態であるか確認し（Ｓ１７０２）、ロック状態であることが確認された場合には申請情報ロックテーブル３２３から該当レコードを削除する（Ｓ１７０４）。
【００３６】
このとき、ワークフロー情報ロック解除プログラム３１３は、更新されたワークフロー情報テーブル３２１のレコードを基幹業務システムサーバ１０１に送信し、基幹業務システムサーバ１０１の申請情報登録プログラム２１３は、ワークフローサーバ１０２から受信したそのレコードに含まれるワークフロー番号を参照してそのワークフロー番号を含む申請情報のステータスを更新する。例えば、申請情報登録プログラム２１３は、申請情報のステータスを「申請中」から「承認１」に更新する。一方、ワークフロー情報ロック解除プログラム３１３は、ロック状態でないことが確認された場合にはデータ不整合の可能性が考えられる為、エラーメッセージを表示して処理を中断する（Ｓ１７０３）。
【００３７】
図１７は、基幹業務システムサーバ１０１にインストールされた申請情報の戻し機能２１５を実行するプログラム（以下、申請情報戻しプログラム）による処理およびその前後処理を示すシーケンス図である。申請情報戻しプログラム２１５は、前提条件として上記ワークフロー情報更新プログラム３１１が実行された後、エラーが発生した場合（Ｓ１５０４）に限り起動される。申請情報戻しプログラム２１５は、ログファイルから申請情報テーブル２２１を抽出し（Ｓ１８０１）、抽出した申請情報テーブル２２１のログからエラーとされたワークフロー処理のワークフロー番号に対応する申請番号を含む該当レコードの過去履歴情報を抽出し（Ｓ１８０２）、抽出した過去履歴情報の中から１サイクル前の過去履歴情報で申請情報テーブル２２１を上書きし、申請情報画面表示プログラム２１５は、その結果を画面に表示させる。
【００３８】
図１８は、上記一連の全体処理を示すシーケンス図である。図１８に示すように、本システムでは、申請情報のうち形式的な条件を満たすか否かを判定した後（図９）、申請情報をロックし（図１０）、その結果をユーザ端末１００の画面に表示させる一方、その表示と並行して実体的な条件を満たすか否かを判断するためのワークフロー処理に進む（図１４、図１５）。この段階で、実体的な条件を満たさないとしてエラーが検出された場合には申請情報の戻し処理を実行し（図１７）、申請前の状態に申請情報を戻したうえでユーザ端末１００にその結果を表示し、これと並行してワークフロー情報および申請情報のロック解除処理を実行する（図１６、図１２）。
【００３９】
図１９は、ユーザ端末１００の表示部に表示される画面の例を示す図である。図１９の上段に示すように、従来システムでは、申請情報が申請された場合、承認待ち画面Ｄ１の中で承認待ちであることを表示（本例ではレ点により表示）する。その後、システム側で形式的なチェックや実体的なチェックが実行されているときには、ユーザ端末１００の表示部には、処理中Ｔ１であることを示す画面が表示され、その処理が終了しなければ、ユーザ自身が申請した申請情報の状態を確認することができなかった。本例では、レ点が表示されていたＮｏ１〜３の申請情報が承認され、画面上からはその表示が削除されていることを示している。
【００４０】
一方、図１９の下段に示すように、本システムでは、申請情報が申請された場合、承認待ち画面Ｄ１の中で承認待ちであることを表示（本例ではレ点により表示）するが、システム側で形式的なチェックＴ１Ａを実行した後すぐにその結果（申請情報が受け付けられたか否か）を示す結果画面Ｄ２が表示される。画面Ｄ１から画面Ｄ２を表示するまでの時間は、形式的な条件のチェックを実行する処理が完了するまでの時間であり、上記従来システムによる画面Ｄ２を表示するまでの時間に比べ、実体的な条件チェックを実行しない分だけ速やかに表示することができる。本システムにより画面Ｄ２が表示される一方、並行して実体的な条件のチェックＴ１Ｂを実行し、その中でエラーが検知された場合には、申請前の申請情報を表示した画面Ｄ３を表示し、ユーザに再度の申請情報を申請するように促す。本例では、Ｎｏ１の旅費申請が、実体的な条件のチェックによりエラーが検知されたことを示している。
【００４１】
以上本発明の一実施例について説明した。上記実施例によれば、処理データのチェックと更新を分離して実施し、エラー発生確率を限りなく下げると同時に画面を先行表示し、エラーが発生した際にはその戻し処理をすることで、通常時のワークフロー処理待ちを排除することができ、従来から生じていた大幅な処理待ち時間の削減をすることが可能になる。さらに、本システムを導入するユーザにとって、ワークフローの申請・承認処理に関わる待ち時間を削減することができるため、業務上作業効率を高めることや、人員コストの低減を計ることが可能となる。
【００４２】
以上本発明の実施例を説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【符号の説明】
【００４３】
１０１・・・基幹業務システムサーバ、１０２・・・ワークフローサーバ、１０３・・・ユーザ端末、１０４・・・ネットワーク、２０１，３０１・・・記憶部、２０２、３０２・・・コントローラ（制御部）、２２１、２２２、２２３、３２１，３２２，３２３・・・テーブル、２０３、３０３・・・ネットワークインタフェース部。
【図１】
0006324884.tif 000002
【図２】
0006324884.tif 000003
【図３】
0006324884.tif 000004
【図４】
0006324884.tif 000005
【図５】
0006324884.tif 000006
【図６】
0006324884.tif 000007
【図７】
0006324884.tif 000008
【図８】
0006324884.tif 000009
【図９】
0006324884.tif 000010
【図１０】
0006324884.tif 000011
【図１１】
0006324884.tif 000012
【図１２】
0006324884.tif 000013
【図１３】
0006324884.tif 000014
【図１４】
0006324884.tif 000015
【図１５】
0006324884.tif 000016
【図１６】
0006324884.tif 000017
【図１７】
0006324884.tif 000018
【図１８】
0006324884.tif 000019
【図１９】
0006324884.tif 000020