JP2016162141A - ワークフローサーバ、ワークフローサーバの制御方法およびプログラム - Google Patents

Abstract

【課題】処理中の案件の工程定義を変更した場合、変更後の工程定義で当該案件の処理が行えるようにする技術を提供する。【解決手段】処理中の案件に対し、既に割り当てられている工程定義を変更する場合、変更後の工程定義の工程の工程処理担当者と同じ工程処理担当者の指定により、案件がこれまでに処理されているかを判定する。処理されていないと判定した場合、処理されていないと判定した変更後の工程定義の工程を、処理中の案件の処理待ちの工程とすることで、処理中の案件が、変更後の工程定義で処理できるようにする。また、処理されていると判定した場合、判定した処理中の案件の工程が処理済みか処理待ちかを判定する。処理済みであると判定した場合は、前回処理した工程の次に実行される工程が、再度、工程処理担当者と同じ工程処理担当者の指定により、案件がこれまでに処理されているかを判定する処理を行う。【選択図】図５

Description

本発明は、処理中の案件の工程定義を変更する方法に関する。

業務情報、経路情報、組織情報等の定義情報を世代管理できるワークフローシステムにおいて、案件を起案時点の定義をもとに処理を行うことが出来るワークフローシステムが存在したとする。そのようなワークフローシステムにおいて、定義情報を年の前記、後期に分けて管理し、世代管理を行った場合、前の期に申請したフローは、前の期の定義にもとづいたフロー制御が行われ、期が切り替わった以降に申請されたフローでは、その期の新しい定義にもとづいたフロー制御を行うことができる。

一般的に、ワークフローにおける承認経路の情報や、組織情報における大規模な変更は、期ごとに行われるため、申請から最終承認されるまで比較的短期間に行われるようなワークフローであれば、「月末までに今月分の申請を行う」など運用方法により組織情報や業務情報、或いは経路情報が期をまたぐことによって一致しなくなるという不都合は避けることができる。

しかし、期ごとに上記定義情報を管理している場合において、ワークフローの申請から最終承認まで1年間かかるようなフローが存在する場合、このようなフローでは、処理途中に期が変わってしまうことが発生するため、業務情報や、組織情報、経路情報について、処理される期のものを適応することを行わないと、ワークフロー処理が運用に耐えられなくなるという問題が発生する。

すなわち、すでに起案、申請済みのワークフローについても、起案時の業務情報、組織情報、或いは経路情報ではなく、その時点で有効な新しい組織情報、業務情報、経路情報を使って、処理を継続させる必要が発生するということである。

例えば、起案時点の定義を元にワークフローが進むワークフローシステムにおいて、起案申請され、「本部長承認」が処理待ちになっている、図３のような承認フローがあったとする。起案された案件が、「課長承認」→「部長承認」→「本部長承認」→「経理承認」というように処理がされる案件が存在したとする。そして、「本部長承認」で処理待ちになっていたとする。

これにおき、「本部長承認」を組織変更などの理由により新しい経路においては、「事業部長承認」としたいことも発生する。また、経路の見直し等によって、新しい経路において「本部長承認」を省き、「部長承認」の次の承認を「経理承認」とすることも発生する。

ワークフローシステムにおいて、処理中の案件が、起案時の組織情報ではなく、新しい組織で処理されるようにする機能や、起案時の業務情報ではなく、新たしい業務情報で処理されるようにする機能は以下の特許文献に記載の通り既に存在する。

特開２００８‐３１０７１０ 特開２０１１‐３４４９２

例えば、特開２００８‐３１０７１０は、案件が処理する際に使用する組織を最新に変更する機能がある（以降、案件に対して最新の組織で処理するよう変更する処理を「組織の振り直し」とする）。しかし特開２００８‐３１０７１０の「組織の振り直し」には、経路定義の最新化機能がないため、組織変更により担当者が変わった場合であっても、処理中の案件に対する経路定義の変更ができない。

特開２０１１‐３４４９２は、案件が処理する際に使用する業務情報を最新に変更する機能がある（以降、案件に対して最新の業務情報で処理するよう変更する処理を業務の「付け替え」とする）。この技術は、業務情報の中でも比較的更新頻度の高い、ワークフローの処理を行う画面の設計情報である「フォーム定義」と「項目定義」について、処理中の案件に対し「付け替え」を行うための技術である。

しかしながら、処理中の案件に対する経路変更は行えないとしている。したがって、処理中の案件は経路変更が発生する前に処理を終了させる、或いは、経路変更が発生してしまった場合は、再度案件を起案してもらう等、ワークフローシステム内の運用で対応することが行われている。そのため、「経路定義」の「付け替え」については「付け替え」の対象外となっている。

このように、処理中の案件であっても、経路に変更が生じた場合に、処理の途中から新しい経路の定義で処理がされるようになっていない。そのため、新しい経路で承認を行うために、再度起案を行う等の手間が発生してしまうことがある。

そこで、本発明は上記課題を鑑み、処理中の案件の工程定義を変更した場合、変更後の工程定義で当該案件の処理が行えるようにすることを目的とする。

本発明は、最終承認が完了していない処理中の案件に対して現在割り当てられている変更前の工程定義と、前記案件に対し変更を行うための変更後の工程定義を記憶した工程定義記憶手段と、前記案件の処理を行った工程処理担当者とこれから処理を行う工程処理担当者を識別可能にする工程状態記憶手段を有する記憶装置と通信可能であって、前記案件に対し、前記変更後の工程定義に割り当てることにより、当該案件を前記変更後の工程定義によって処理することを可能するワークフローサーバにおいて、工程定義を変更する案件の選択を受け付ける案件受付手段と、前記案件受付手段で受け付けた前記案件に対し、前記変更後の工程定義の割り当てを行う変更後の工程定義割り当て手段と、前記変更後の工程割り当て手段により割り当てた前記変更後の工程定義が保持する１つの工程である検証工程の工程処理担当者と同じ工程処理担当者の指定により、前記案件の処理済みの工程において処理が行われたことがあるか否かを判定する判定手段と、前記判定手段で、前記変更後の工程割り当て手段により割り当てた前記変更後の工程が保持する１つの工程である検証工程の工程処理担当者と同じ工程処理担当者の指定により、前記案件の処理済みの工程において処理が行われたことがないと判定した場合、前記案件が次に処理する工程処理担当者を、前記判定手段において存在しないと判定した前記検証工程の工程処理担当者に変更するべく、前記工程状態記憶手段において、当該検証工程の工程処理担当者が前記案件の処理待ちである状態とするレコードを作成する処理待ち状態作成手段と、を備え、前記変更後の工程定義割り当て手段は、前記受付手段で受け付けた案件を、前記処理待ち状態作成手段により、処理待ち状態として作成した工程以降、前記変更後の工程定義割り当て手段で割り当てた工程定義により処理をすることを可能とすることを特徴とする。

本発明によれば、処理中の案件の工程定義を変更した場合、変更後の工程定義で当該案件の処理が行えるようにすることが可能になる。

本発明の実施形態における、システム構成の一例を示す図である。 本発明の実施形態における、クライアント端末１０１、管理端末１０２、ワークフローサーバ１０３、データベースサーバ１０４のハードウェア構成の一例を示す図である。 本発明の実施形態における、機能構成の一例を示す図である。 本発明の実施形態における、定義情報と案件情報を構成するテーブルの一例を示す図である。 本発明の実施形態における、処理中の案件の工程定義を変更するための処理の一例を示すフローチャートである。 本発明の実施形態における、ワークフローにおいて起案された案件が処理される変更前の工程の処理順序を示した工程定義の概念図である。 本発明の実施形態における、ワークフローにおいて起案された案件が処理される変更後の工程の処理順序を示した工程定義の概念図である。 本発明の実施形態における、工程定義テーブルの一例を示す図である。 本発明の実施形態における、工程状態テーブルの一例を示す図である。 本発明の実施形態における、工程定義テーブルの一例を示す図である。 本発明の実施形態における、工程状態テーブルの一例を示す図である。 本発明の実施形態における、工程状態テーブルの一例を示す図である。 本発明の実施形態における、工程状態テーブルの一例を示す図である。 本発明の実施形態における、変形例を説明するための、工程定義テーブルと、工程状態テーブルの一例を示す図である。 本発明の実施形態における、変形例を説明するための、工程定義テーブルと、工程状態テーブルの一例を示す図である。 本発明の実施形態における、変形例を説明するための、工程定義テーブルと、工程状態テーブルの一例を示す図である。

図１は、本発明の一実施形態を示すワークフローシステムの全体構成を示すシステム構成図である。

図１に示すように、本実施形態のワークフローシステムは、クライアント端末１０１、管理端末１０２、ワークフローサーバ１０３、データベースサーバ１０４がネットワーク１０５を通じて接続されている。

ユーザは、例えばウェブブラウザやクライアントソフトウェアなどを利用して、クライアント端末１０１において案件の起案を行う、或いは、案件の承認を行うことによって、ワークフローサーバ１０３に対して、案件に対してワークフロー上の処理がしかるべき処理担当者においてなされるようにするため、ワークフローの進行の要求などを行う。

ワークフローサーバ１０３は、クライアント端末１０１からのワークフローを進行させるために必要となる要求を受け付け、受け付けた処理（例えば、起案、承認などの処理）に応じて、経路情報に従い、案件がしかるべき次の処理担当者によって処理が行われるようにする。

ワークフローサーバ１０３によって、しかるべき次の処理担当者に処理が行われるように処理がされた案件は、次の処理担当者によってクライアント端末１０１において作業が可能になる。

管理端末１０２からは、案件をしかるべき処理担当者へ処理依頼が行えるようにするための、案件の処理担当者のルールを設定した経路情報や、ワークフローシステムを運用するために必要となる、処理担当者（ユーザ）、処理担当者（ユーザ）が所属する組織、あるいは、処理担当者（ユーザ）に紐付く役割（ロール）の情報を登録、管理することを可能とする。

データベースサーバ１０４は、ワークフローシステムを運用するために必要となる、処理担当者（ユーザ）、処理担当者（ユーザ）が所属する組織、あるいは、処理担当者（ユーザ）に紐付く役割（ロール）の情報、或いは、クライアント端末１０１において案件を申請し、処理していくために必要となるアプリケーションの設計情報、また、経路情報を保持する。また、クライアント端末１０１によって申請された案件を管理するテーブル、配送を管理するテーブルの情報も保持する。

なお、クライアント端末１０１、管理端末１０２、ワークフローサーバ１０３、データベースサーバ１０４間の通信は、通常のＨＴＴＰのリクエストでもよいし、ＳＯＡＰ等を利用したウェブサービスのリクエストでもよいこととする。

なお、経路情報は、本発明においては、工程定義とも呼ぶこととする。

図２は、本発明の実施形態におけるクライアント端末１０１、管理端末１０２、ワークフローサーバ１０３のハードウェア構成を示す図である。

ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、Ｒ０Ｍ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。

ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。

また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイス（或いは、画面に接触することによる直接の指示）からの入力を制御する。なお、携帯端末や、タブレット端末である場合は、タッチパネルが入力を制御する。

ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものである。本発明には直接関係があるものではない。

メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。

また、携帯端末の場合、インターネット通信以外にも、公衆回線を用いて電話としての通信が可能であっても良い。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明を実現するためのプログラムは外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。

図３は、本発明の実施形態における機能構成図の一例について説明をする。

本発明の実施形態における機能構成は、管理端末１０２は、案件選択部３０１から構成され、ワークフローサーバ１０３は、案件受付部３０２、変更後の工程定義割り当て部３０３、判定部３０４、処理待ち状態作成部３０５、状態変更部３０６から構成され、クライアント端末１０１は、案件処理部３０７から構成されることとする。

案件選択部３０１は、管理端末１０２において、工程定義の変更を行う対象とする処理中の案件の選択を行う。

案件受付部３０２は、案件選択部３０１で受け付けた、工程定義の変更を行う対象とする処理中の案件の受付を行う。

変更後の工程定義割り当て部３０３は、案件受付部３０２が受け付けた案件に対し、変更後の工程定義の割り当てを行う。

判定部３０４は、変更後の工程定義割り当て部３０３により割り当てた、変更後の工程定義が保持する１つの工程である検証工程の工程処理担当者と同じ工程処理担当者の指定により、案件受付部３０２により受け付けた案件の処理済みの工程において処理が行われたことがあるか否かを判定する。

処理待ち状態作成部３０５は、判定部３０４で、変更後の工程定義割り当て部３０３により割り当てた、変更後の工程定義が保持する１つの工程である検証工程の工程処理担当者と同じ工程処理担当者の指定により、案件受付部３０２により受け付けた案件の処理済みの工程において処理が行われたことがないと判定した場合、案件受付部３０２で受け付けた案件の次ぎに処理する工程処理担当者を、判定部３０４において存在しないと判定した検証工程の工程処理担当者に変更するべく、工程状態記憶テーブルにおいて、当該検証工程の工程処理担当者が、案件の処理待ちである状態とするレコードを作成する。

状態変更部３０６は、処理待ち状態作成部３０５により、当該検証工程の工程処理担当者が、案件の処理待ちである状態とするレコードを作成した後、は、更に、工程状態記憶テーブルにおいて、案件受付部３０２で受け付けた案件の、変更前の工程定義で処理された、処理待ちの状態であるレコードの状態を取り消しの状態に変更する。また、案件受付部３０２で受け付けた案件が、変更後の工程定義の全ての工程の工程処理担当者と同じ工程処理担当者の指定により処理されていて、かつ、案件受付部３０２で受け付けた案件の、次に処理される工程の状態が処理待ちであるレコードが存在する場合、当該案件の次に処理される工程のレコードの状態を取り消しに変更する。

案件処理部３０７は、クライアント端末１０２において、ワークフローシステムにおいて案件が処理されるように、ワークグローサーバ１０３へ処理を依頼する。

次に、ワークフローシステムを実現するためのデータテーブルについて説明する。データベースサーバ１０４は、ワークフローの処理を行うために必要となるアプリケーションの設計情報である定義情報と、実際に定義情報に基づくアプリケーションを利用して申請された情報である案件情報とを各種データテーブルにおいて記憶している。

図４は、本発明の説明において必要となる定義情報と案件情報の一例を示す図である。図４に示す定義情報４００は、ワークフローにおいて案件を起案できるようにするために必要となる各種設計情報で、設計者により、予め設計や定義がされているものである。なお、本実施形態に係る定義情報４００では、業務テーブル４０１と、経路テーブル４０２と、工程定義テーブル４０３とを有することとする。なお、処理の説明において、テーブル名が同じであり、テーブル名の後に数値を付加して記載している箇所、或いは、テーブル名の後に数値を付加して記載していない箇所は、保持するデータは異なる場合があるが、ここで説明するテーブルと同じ定義を持つテーブルを指すこととする。あわせてテーブルが保持する項目についても同様であることとする。

また、図４に示す案件情報４１０は、実際に定義情報４００に基づいて構築されたワークフローシステムにおいて申請されたことによって、生成される情報であり、本実施形態に係る案件情報４１０は、案件テーブル４１１、ジョブテーブル４１２、工程状態テーブル４１３を有することとする。なお、処理の説明において、テーブル名が同じであり、テーブル名の後に数値を付加して記載している箇所、或いは、テーブル名の後に数値を付加して記載していない箇所は、保持するデータは異なる場合があるが、ここで説明するテーブルと同じ定義を持つテーブルを指すこととする。あわせてテーブルが保持する項目についても同様であることとする。

まず、はじめに、定義情報４００を構成するテーブルについて説明をする。

業務テーブル４０１には、ワークフローにおいて申請を行うために必要となるアプリケーションの設計情報が業務単位で登録される。アプリケーションの設計情報の単位は、業務ＩＤ及び業務名により識別可能とするため、業務テーブル４０１は、業務ＩＤ、業務名により構成される。業務ＩＤには、業務を識別するためのＩＤが登録され、業務名には、業務ＩＤに対応する名称が登録される。

経路テーブル４０２には、案件を申請するための業務に紐付く経路の情報が登録される。経路テーブル４０２は、業務ＩＤ、経路ＩＤ、バージョン、経路名、起案可能部門ＩＤ、起案可能ロールＩＤ、経路データの項目から構成される。
業務ＩＤには、経路が適応される業務の業務ＩＤが登録される。経路ＩＤは案件を申請するための業務に紐付く経路を識別するためのＩＤが登録される。バージョンには、経路のバージョンが登録される。このバージョンによって、経路の変更を行った単位で経路情報をバージョン管理する。
経路名には、経路の名称が登録される。起案可能部門ＩＤには、紐付く経路が割り当てられている業務を起案することが可能な組織の部門ＩＤが登録される。起案可能ロールＩＤには、起案可能なユーザのロールＩＤが登録される。経路データには、処理フローとして作成された経路データが登録される。

工程定義テーブル４０３には、経路テーブルに登録されている経路を構成する各処理単位の処理単位の情報が登録される。工程定義テーブル４０３は、業務ＩＤ、経路ＩＤ、バージョン、工程定義ＩＤ、工程処理担当者、工程種別、工程の担当部門ＩＤ、工程の担当ロールＩＤの項目から構成される。

業務ＩＤには、経路が適応される業務の業務ＩＤが登録される。経路ＩＤには、案件を申請するための業務に紐付く経路を識別するためのＩＤが登録される。バージョンには、経路のバージョンが登録される。このバージョンによって、経路の変更を行った単位で経路情報をバージョン管理する。工程定義ＩＤには、経路における処理単位である工程を識別するためのＩＤが登録される。なお、本実施例においては、工程定義ＩＤの番号の低い順に工程が処理されることとする。工程処理担当者には、経路における処理単位である工程に設定されている処理担当者情報が登録される。工程種別には、経路における処理単位であるアクティビティの処理が合議処理ではなく部門情報や、ユーザ情報、ロール情報の指定により処理が行われるユーザ実行の工程であるのか、あるいは、合議処理を行う工程であるのかの識別を可能にする種別が登録される。工程の担当部門ＩＤには、処理単位である工程の処理担当者が所属する部門ＩＤが登録される。工程の担当ロールＩＤには、処理単位である工程の処理担当者に付与されているロールＩＤが登録される。

次に、案件情報４１０を構成するテーブルについて説明をする。

案件テーブル４１１には、ワークフローシステムにおいて申請された案件のデータが登録される。案件テーブル４１１は、案件ＩＤ、業務ＩＤ、ジョブＩＤ、案件データから構成される。案件ＩＤには、申請された案件データを識別するためのＩＤが登録される。業務ＩＤには、申請された案件に紐付く業務の業務ＩＤが登録される。ジョブＩＤには、案件を１つのジョブ情報として管理するテーブルであるジョブテーブル４１２のジョブＩＤと紐付けるためのＩＤが登録される。案件データには、起案がされた案件の案件データが登録される。

ジョブテーブル４１２には、案件を１つのジョブとして管理するために、案件に紐付く経路のバージョンや、申請、承認、否認など案件の状態、申請され承認が完了した日を管理する。ジョブテーブル４１２は、ジョブＩＤ、案件ＩＤ、業務ＩＤ、経路ＩＤ、バージョン、状態、申請日時、完了日時から構成される。

ジョブＩＤには、案件を１つのジョブとして識別するためのＩＤが登録される。案件ＩＤには、申請された案件データを識別するためのＩＤが登録される。業務ＩＤには、申請された案件に紐付く業務の業務ＩＤが登録される。経路ＩＤには、案件を申請するための業務に紐付く経路を識別するためのＩＤが登録される。バージョンには、経路のバージョンが登録される。状態には、申請、承認、否認、取り消しなど案件の処理を識別するための状態が登録される。申請日時は、案件が申請された日時が登録される。完了日時は、案件の処理が完了した日時が登録される。

工程状態テーブル４１３は、案件の処理履歴と、これから処理が行われる工程を、案件を処理する工程定義の単位で管理するテーブルである。工程状態テーブル４１３は、工程状態ＩＤ、ジョブＩＤ、案件ＩＤ、業務ＩＤ、経路ＩＤ、バージョン、工程定義ＩＤ、工程処理担当者、状態から構成される。この工程状態テーブルに存在する処理履歴となるレコードは、「工程状態」とも表現することとする。

工程状態ＩＤには、工程状態テーブル４１３に登録される、工程定義単位で案件を処理した処理履歴の情報を識別するためのＩＤが登録される。ジョブＩＤには、案件を１つのジョブとして識別するためのＩＤが登録される。案件ＩＤには、申請された案件（案件データ）を識別するためのＩＤが登録される。業務ＩＤには、申請された案件に紐付く業務の業務ＩＤが登録される。経路ＩＤには、案件を申請するための業務に紐付く経路を識別するためのＩＤが登録される。バージョンには、経路のバージョンが登録される。工程定義ＩＤには、案件が、それに紐付く経路のどの工程定義で処理されたのかを識別するためのＩＤが登録される。工程処理担当者には、工程定義ＩＤに紐付く工程定義の処理担当者の指定が登録される。状態には、申請、承認、否認、取り消し、処理待ちなど案件の処理を識別するための状態が登録される。

なお、本実施例において、申請、承認、取り消しが行われた場合の状態は、処理待ちの状態とそうでないものの状態の区別を付けやすくするため、完了（申請）、完了（承認）、完了（取り消し）という値を、状態を表現する値として記載することとする。

更に、後述の処理の説明において使用するテーブルにおいては、本発明の処理を説明するために必要となるデータ項目のみによる構成とする。

なお、図中の「１」と「＊」は、１対多の関係にあることを示す。例えば、図４に示す例においては、業務テーブル４０１の１つの業務情報に対し、経路テーブル４０２の複数の情報が紐付く。また、経路テーブル４０２の１つの経路情報に対し、工程定義テーブル４０３の複数の工程情報が存在することになる。また、案件情報４１０の案件テーブル４１１に、経路テーブル４０２の１つ経路情報を基に申請されたワークフローの案件データが申請単位で存在することとなる。

案件テーブル４１１は、ジョブテーブル４１２の情報に１対１の関係で紐付き、ジョブテーブル４１２の情報は、各工程において処理を行われた単位で、複数の工程の処理履歴の情報を保持する工程状態テーブル４１３と紐付く。

続いて、図６について説明を行う。図６は、ワークフローにおいて起案された案件が処理される工程の処理順序を示した工程定義の概念図である。また、図６は、本実施例においては、変更前の工程定義とする。図６に示す変更前の工程定義は、工程の単位として、実行順に、申請工程６０１、課長承認工程６０２、部長承認工程６０３、本部長承認工程６０４、経理承認工程６０５を含む。

続いて、図７について説明を行う。図７は、ワークフローにおいて起案された案件が処理される工程の処理順序を示した工程定義の概念図である。また、図７は、本実施例においては、変更後の工程定義とする。図７に示す変更後の工程定義は、工程の単位として、実行順に、申請工程７０１、課長承認工程７０２、部長承認工程７０３、事業部長承認工程７０４、経理承認工程７０５を含む。

なお、図６の変更前の工程定義をテーブルに登録した状態は、図８の工程定義テーブル８００で図示するレコードとする。また、図７の変更後の工程定義を、変更前の工程定義がテーブルに登録されている状態で追加登録した状態は、図１０の工程定義テーブル１０００で図示するレコードとする。すなわち、図１０の工程定義テーブル１０００において、バージョン１００３が「１」のレコードを、変更前の工程定義に関するレコードし、また、バージョン１００２が「２」のレコードを、変更後の工程定義に関するレコードとする。

続いて、図５を用いて、本発明の処理について説明をする。なお、本処理は、ワークフローサーバ１０３のＣＰＵ２０１が行う処理であることとする。

本処理は、申請された案件の業務の業務ＩＤが００１、申請された案件の案件ＩＤが０００１の、申請後、最終承認が終了していない処理途中の案件に対し、経路の変更を行った場合（変更後の工程定義を割り当てた場合）、適切な工程において、その工程を処理待ち状態とし、当該処理待ちの工程以降を変更後の工程定義で処理されるようにするというものである。

すなわち、本処理は、処理待ち案件が処理されるときに、変更後の工程定義と、実際に変更前の工程定義で処理された案件の履歴である工程状態における処理履歴を確認しながら、変更後の工程定義の工程の処理が、変更前の工程定義で処理されてきた案件の処理履歴の工程に存在している場合は、処理された工程はそのままとし、変更後の工程定義の工程の処理が、変更前の工程定義で処理されてきた案件の処理履歴の工程に存在しない場合、新たに、その変更後の工程定義における工程を、案件の処理待ちの状態とし（変更後の工程定義で処理されるように切り替え）、それ以降の工程においては、変更後の工程定義で処理がされるようにするということである。

なお、本処理は、変更後の工程定義で処理されるようにするため、変更後の工程定義における引き継がれた工程において処理待ち状態とする処理までを行うこととする。

また、当該案件に対して、割り当てられていた変更前の工程定義は、図６の変更前の工程定義とする。そして、当該案件に対して、これから割り当てる、変更後の工程定義は、図７の変更後の工程定義であるとする。

また、処理を説明するにあたっての、最初のデータ例は、当該案件が、図６の変更前の工程定義における本部長承認の処理待ち状態となっている状態で、図７の変更後の工程定義を割り当てた場合を例に挙げて説明をする。

ステップＳ５０１において、ワークフローサーバ１０３のＣＰＵ２０１は、工程状態テーブル９００から対象案件のデータの各工程における処理の状態を、工程状態として取得する。

例えば、業務ＩＤが「００１」、案件ＩＤが「０００１」に該当する案件の場合、図９の工程状態テーブル９００から、工程処理担当者９０７が「申請」の状態９０８が「完了（申請）」であり（９１１）、工程処理担当者９０７が「課長承認」、「部長承認」の状態９０８が「完了（承認）」であり（９１２、９１３）、工程処理担当者９０７が「本部長承認」の状態９０８が「処理待ち」である（９１４）工程状態を取得する。

ステップＳ５０２において、ワークフローサーバ１０３のＣＰＵ２０１は、工程定義テーブル１０００から変更後の工程定義を取得する。

図１０の工程定義テーブル１０００において、バージョン１００３が「１」のレコードを、変更前の工程定義に関するレコードし、また、バージョン１００２が「２」のレコードを、変更後の工程定義に関するレコードとする。この場合、業務ＩＤ１００１が「００１」の変更後の工程定義は、バージョン１００２が「２」のレコードを、変更後の工程定義の情報として取得することが出来る。すならち、変更後の工程定義として、工程処理担当者１１０５が、「申請」、「課長」、「部長」、「事業部長」、「経理」、として遷移していく工程定義の情報を取得する。

なお、図６の変更前の工程定義の概念図は、図１０の工程定義テーブル１０００において、バージョン１００３が「１」の工程定義を概念図としたものであり、図７の変更後の工程定義の概念図は、図１０の工程定義テーブル１０００において、バージョン１００３が「２」の工程定義を概念図としたものである。また、バージョン１００３が「２」の工程定義は、工程定義の変更を行うと生成される情報であることとする。

続いてステップＳ５０３以降の処理について説明をする。ステップＳ５０３以降の処理は、ステップＳ５０２で取得した、案件に割り当てられた、変更後の工程定義の各工程を基準に行う処理を、実行順に行う（本実施例では工程定義ＩＤに登録されている数値が低い順に行う）処理となる。なお、変更後の工程定義の中で処理対象となる工程を検証工程ということとする。

ステップＳ５０３において、ワークフローサーバ１０３のＣＰＵ２０１は、変更後の工程定義の情報を取得する。初回は最初に処理される工程の情報を取得し、再度この処理が行われる場合は、前回取得した工程の次に処理がされる工程が取得する。そして取得できたかを判定する。ステップＳ５０３で工程が取得できたと判定した場合、ステップＳ５０４に処理を進める。取得できなかったと判定した場合は、Ｓ５０８へ処理を進める。

ステップＳ５０４において、ワークフローサーバ１０３のＣＰＵ２０１は、ステップＳ７０３で取得した次の工程を検証工程とする。

ステップＳ５０５において、ワークフローサーバ１０３のＣＰＵ２０１は、検証工程と同じ工程処理担当者が指定されている工程が、工程状態データから取得した工程状態の中に存在するか確認する。すなわち、検証工程の処理担当者の指定と同じ指定で処理された工程がステップＳ５０１で取得した工程状態に存在するかを確認する。なお、工程状態の各レコードを確認する順番は、一実施例として、処理された順に行うこととする。例えば、工程定義ＩＤに登録されている数値が低い順に行うこととする。

この方法により、検証工程が、申請よりも後の工程である場合は、前回の処理において、工程状態の中で確認した工程よりも後に処理される工程の中に存在するかを確認したいためである。例えば、工程状態で前回、工程状態の中で確認した工程よりも前に行なわれている場合は、順序が逆になるため、あくまで後で処理された工程の中に存在するかを確認するということである。

なお、差し戻し、否認が行われた場合は、否認が行われた工程と否認された工程、或いは、差戻しを行った工程と差戻しされた工程までの直前の承認処理は取り消されたものとして扱い、工程状態テーブルのレコードからは処理対象外として本処理を行うこととする。すなわち、工程において最新の承認された工程を有効として処理を行うこととする。

これを実現するために、ワークフローにおいて、否認処理が行われた場合は、否認を行った工程のレコード」と「否認された対象工程の直前に申請・承認したレコードの承認状態を取り消し状態とする。或いは、差し戻し処理が行われた場合は、「差し戻しを行った工程のレコード」と「差し戻しされた対象工程まで、直前に申請・承認したレコード」の承認状態を取り消し状態とする。以上、取り消し状態のレコードを作成しておくことによって、工程状態テーブルにおける、そのレコードについては、「検証工程」の工程と同じ工程処理担当者を持つ工程によって処理されたレコードがあるか否かを確認する対象とはしないこととする。また、ループする工程定義で処理されたレコードも同様に対応することとする。

ステップＳ５０５において、存在すると判定した場合、ステップＳ５０６へ処理を進める。ステップＳ５０５において、存在しないと判定した場合、ステップＳ５０７へ処理を進める。

ステップＳ５０６において、ワークフローサーバ１０３のＣＰＵ２０１は、ステップＳ５０５で確認した、検証工程と同じ工程処理担当者によって処理された工程状態が、処理済みか、処理待ちかを確認する。処理済みの判定した場合、ステップＳ５０３に処理を進める。処理待ちと判定した場合、本処理を終了する。なお、処理済みとは、工程状態テーブルにおいて、状態の値が完了で始まるものを指すこととする。

ステップＳ５０７において、ワークフローサーバ１０３のＣＰＵ２０１は、検証工程の工程が
工程状態テーブルにおいて、状態が「処理待ち」となるように、検証工程の工程定義をもとに工程状態テーブルに対してレコードを追加する。

ステップＳ５０８において、ワークフローサーバ１０３のＣＰＵ２０１は、ステップＳ５０１で取得した工程状態のうち、工程状態テーブルにおいて、変更前の工程定義によって案件が処理され「処理待ち」となっているレコードの状態を「完了（取り消し）」に変更し、本処理を終了する。
続いて、ステップＳ５０３以降の処理について実データを元に説明する。

ステップＳ５０３において、Ｓ５０１で取得した工程定義より、処理の基準となる工程である、検証工程が存在するか確認する。例えば、図１０の工程定義テーブル１０００のバージョン１００２が「２」のレコードを、変更後の工程定義に関するレコードとして取得しているため、この処理を初めて行う場合は、この工程定義の中で最初に処理が行われる工程処理担当者１００５が「申請」の工程定義のレコードが存在していることが確認できる。

ステップＳ５０４において、ステップＳ５０３で存在を確認した、工程処理担当者１００５が「申請」の工程定義を、検証工程とする。

ステップＳ５０５において、ステップＳ５０４で検証工程とした工程の工程処理担当者と、同じ工程処理担当者によって処理された工程状態のレコードが工程状態テーブルに存在するかを確認する。
例えば、初回の処理では、検証工程が、工程処理担当者１００５が「申請」であり、工程処理担当者が「申請」で処理された工程状態は、図９の９１０で図示するレコードにおいて存在することが確認できる。

ステップＳ５０６において、ステップＳ５０５において存在することを確認した工程状態のレコードの状態が「処理済み（本実施例では、完了（申請）または、完了（承認））」か、処理待ちかを確認する。

ステップＳ５０６において、状態が「処理済み」であると判定した場合は、ステップＳ５０３へ処理を進め、状態が「処理済み」と判定した場合は、本処理を終了する。例えば、ステップＳ５０５で存在すると確認した、図９の９１０で図示するレコードにおいては、状態９０８は「完了（承認）」となっているため、処理済みと判断する。この場合、ステップＳ５０３に処理を進める。

続いて再度ステップＳ５０３以降の処理を進めるが、次の処理においては、ステップＳ５０２において、変更後の工程定義として取得している、図１０の工程定義テーブル１０００のバージョン１００２が「２」のレコードのうち、前回検証工程として処理を行った工程の次に処理を行う工程が存在するかを確認する。例えば、前回は、図１０の工程定義テーブル１０００の、工程処理担当者１００５が「申請」のレコード（１０００）であったため、次に処理されるレコードとして、工程処理担当者１００５が「課長」のレコード（１０１１）が取得することができる。

なお、ステップＳ５０３以降の、変更後の工程定義において次に処理を行う工程が、工程処理担当者１００５が「課長」である場合の処理は、前回の、工程処理担当者１００５が「申請」の工程を検証工程とした場合と同様となる。また、さらに、変更後の工程定義において次に処理を行う、工程処理担当者１００５が「部長」の工程を検証工程とした場合の処理も、工程処理担当者１００５が「申請」、または、「課長」の場合と同様となる。

続いて、ステップＳ５０３以降の、工程処理担当者１００５が「事業部長」の工程を検証工程とした場合の処理について説明をする。

ステップＳ５０３において、Ｓ５０１で取得した工程定義より、処理の基準となる工程である、検証工程が存在するか確認する。例えば、前回の、検証工程が、工程処理担当者１００５が「部長」の工程であった場合、変更後の工程定義に関するレコードとして取得している、図１０の工程定義テーブル１０００のバージョン１００２が「２」のレコードの中より、次に処理する工程として、工程処理担当者１００５が「事業部長」の工程定義のレコードが存在していることが確認できる（１０１２）。

ステップＳ５０４において、ステップＳ５０３で存在を確認した、工程処理担当者１００５が「事業部長」の工程定義を、検証工程とする。

ステップＳ５０５において、ステップＳ５０４で検証工程とした工程の工程処理担当者と、同じ工程処理担当者によって処理された工程状態のレコードが工程状態テーブルに存在するかを確認する。
例えば、今回の処理では、検証工程が、工程処理担当者１００５が「事業部長」であり、工程処理担当者が「事業部長」で処理された工程状態は、図９で図示する工程状態テーブル９００に存在するレコードにおいて存在しないことが確認できる。従って、この場合、ステップＳ５０７へ処理を進める。

ステップＳ５０７において、検証工程である、工程処理担当者１００５が「事業部長」の工程が、工程状態テーブルにおいて、状態が「処理待ち」となるように、検証工程の工程定義をもとに工程状態テーブルに対してレコードを追加する。例えば、図１１の工程状態テーブル１１００の１１１１で図示するように、工程処理担当者１１０７が「事業部長承認」で、状態１１０８が「処理待ち」のレコードを作成する。

ステップＳ５０８において、ワークフローサーバ１０３のＣＰＵ２０１は、ステップＳ５０１で取得した工程状態のうち、工程状態テーブルにおいて、「処理待ち」となっているレコードの状態を「完了（取り消し）」に変更し、本処理を終了する。例えば、図１１の工程状態テーブル１１００の１１１０で図示するように、工程処理担当者１１０７が「本部長承認」のレコードの、状態１１０８を「完了（取り消し）」に更新する。

以上の処理により、変更後の工程定義の工程の処理担当者と同じ処理担当者によって、当該案件の処理が変更前の工程定義でなされている場合に、その工程における処理を有効とした上で、変更後の工程定義で当該案件の処理がされるようにすることが可能になる。

続いて、ステップＳ５０６において処理済みと判定した場合について説明を行う。

ステップＳ５０６において、ステップＳ５０５において存在することを確認した工程状態のレコードの状態が処理済み（本実施例では、完了（申請）または、完了（承認））」か、処理待ちかを確認する。
例えば、図１２の１２１０で図示するレコードが、ステップＳ５０５で存在すると確認したレコードである場合、状態１２０８は「処理待ち」となっている。この場合は、ステップＳ５０６において処理待ちの状態であると判定し、本処理を終了することとなる。すなわち、処理待ちよりも後の工程は変更後の工程定義で切り替えて、案件が処理されるようになる、ということである。

続いて、ステップＳ５０３で存在しないと判定され、ステップＳ５０８に処理が進むケースについて説明をする。

変更後の工程定義で処理すべき工程が、工程状態テーブルの工程状態で実際に処理された承認済み工程として、履歴として存在する場合があったとする。例えば、図１３の１３１０、１３１１、１３１２、１３１３、１３１４は、図７の変更後の工程定義で同じ処理担当者で処理すべき工程が、処理済みとなっている（状態１３０８＝完了（申請）または、完了（承認））。

そして、次の工程処理担当者１３０７が「業務」で、状態１３０８が「処理待ち」のレコード１３１５が存在していることとなっている。（なお、変更前の工程定義が、経理の工程の後、業務の工程において処理がなされるようにする定義であることを前提とする。）

この状態において、変更後の工程定義を割り当てると、工程定義と処理履歴の工程が１３１０から１３１４まで一緒であるが、次のステップＳ５０３の処理に入った場合、変更後の工程定義においては検証工程がもはや存在しなくなるため（ステップＳ５０３で存在しない）、ステップＳ５０８において、工程状態テーブルに存在する、状態が「処理待ち」のレコードに対し、そのレコードがこれ以上処理されないようにするため、状態を「完了（取り消し）」に変更する処理を行うということである。
例えば、図１３の１３１５は、工程処理担当者１３０７か「業務」で状態１３０８が「処理待ち」のレコードであるが、このレコードの状態１３０８を、図１３の１３１６で図示するように、「完了（取り消し）」に変更を行うということである。

続いて、本処理を行う際の変形例についていくつか説明を行う。

まず、変更後の工程定義の検証工程が、既に承認済みとなった工程において存在し、かつ、その存在した工程状態の工程の前に処理された工程が存在していることが確認できた場合、当該承認済みとなった工程を再度処理待ち状態として、その工程から案件の処理がなされるよういしても良い。すなわち、このケースは、変更後の工程定義において、処理済みの工程が存在していないものが存在した場合、その後に処理される直近の処理済みの工程を処理待ちとしても良いということである。

例えば、図１４の工程定義テーブル１４００で図示するように、変更前の工程定義が、申請、課長、部長、本部長、経理の順番で処理される工程定義であったとし、変更後の工程定義が、申請、部長、本部長、経理の順番で処理される工程定義であったとする。そして、案件は、部長まで変更前の工程定義において、処理がされ、本部長の処理待ち状態であったとする。このケースの場合、図５の実施例によると、図１４の工程処理担当者１４１７が「本部長」で、状態１４１８が「処理待ち」のレコードが、処理待ちのままの状態とし、処理が終了する。しかし、工程状態テーブル１４１０の１４２０で図示する、工程処理担当者１４１７が「課長」で、状態１４１８が「完了（承認）」のレコードは、変更前の工程定義における工程にないが、既に処理が行われているレコードである。こういった場合は、削除が行われた工程の次の処理済みの工程である、部長の工程を処理待ちとし、再度、処理を行わせるようにしても良いということである。例えば、図１４、工程状態テーブル１４３０における、工程処理担当者１４１７が「部長」のレコード（１４３９）を、状態１４１８を「処理待ち」として再度処理が行われるようにしても良いということである。

更に、次の変形例について説明をする。変更後の工程定義の検証工程が、工程状態テーブルにおいて既に承認済みとなった工程において存在がしないと確認したが、次の検証工程が工程状態テーブルにおいて存在すると確認した場合、検証工程の工程で工程状態の処理履歴の工程に存在しなかったとしても、既に変更前の工程定義において処理が行われてしまっている工程と判断し、その場合には、工程状態テーブルにおいて、存在しなかった検証工程が存在したとしても、工程状態テーブルにおいて処理待ち状態としなくて良いということである。

例えば、図１５の工程定義テーブル１５００で図示するように、変更前の工程定義が、申請、課長、部長、本部長、経理の順番で処理される工程定義であったとし、変更後の工程定義が、申請、課長、業務担当、部長、本部長、経理の順番で処理される工程定義であったとする。

そして、案件は、部長まで変更前の工程定義において、処理がされ、本部長の処理待ち状態であったとする。このケースの場合、図５の実施例によると、図１５の工程処理担当者１５１７が「本部長」で、状態１５１８が「処理待ち」のレコードの、状態１５１８を「完了（取り消し）」にし、新たに、工程処理担当者１５１７が「業務担当」で、状態１５１８が「処理待ち」レコードを作成することとなる。

しかし、工程定義テーブル１５００の１５０７のレコードである、工程処理担当者１５０５が部長によって承認が行われる工程は、工程状態テーブル１５１０の１５１９のレコードで図示するとおり、状態１５１９が「完了（承認）」となっている。このように、変更前に既に承認処理が行われた工程が、変更後の工程において含まれている場合は、そこまでは変更後の工程定義においても承認がおこなわれたものとしてみなし、図１５、工程状態テーブル１５１０の１５２０のレコードで図示するとおり、工程処理担当者１５１７が「本部長」のレコードの、状態１５１８は、処理待ちのままにする方法をとれるようにしても良いということである。

続いて、前述した、ステップＳ５０３で存在しないと判定され、ステップＳ５０８に処理が進むケースについての変形例について説明をする。

例えば、図１６の工程定義テーブル１６００で図示するように、変更前の工程定義が、申請、課長、部長、本部長、経理の順番で処理される工程定義であったとし、変更後の工程定義が、申請、課長、部長の順番で処理される工程定義であったとする。そして、案件の処理履歴が、図１６の工程状態テーブル１６１０に図示するように、工程処理担当者１６１７が「部長」の工程の処理が終了し（状態１６１８が「完了（承認）」）、工程処理担当者１６１７が「本部長」の工程において案件が処理待ち（状態１６１８が「処理待ち」）である状況であるとする。

この場合、図５の実施例によると、工程状態テーブル１６１０の１６２１から１６２３までのレコードの工程処理担当者１６１７は、それぞれ、工程定義テーブル１６００の１６０６から１６０８のレコードの工程処理担当者１６０５と同じである。この場合、図５の処理を適応した場合は、工程状態テーブル１６１０のである１６２４のレコードの状態１６１８を「処理待ち」から「完了（取り消し）」とする（１６３９）ことで、本案件の処理はこれ以上行われないようにしている。しかしながら、最終承認となる工程が他の工程と比べ重要度が高いと判断した場合に、再度、その工程を案件の処理待ちになるようにし、確実に最終承認が行えるようにしても良いこととする。

例えば、図１６の１６４０のレコードで図示するように、工程処理担当者１６３７が「部長」で、状態１６３８が「処理待ち」のレコードを作成することによって、部長により再度案件の処理が行われるようにしても良いということである。

以上、変形例の説明を終了する。

以上、本実施例により、処理中の案件の工程定義を変更した場合、変更後の工程定義で当該案件の処理が行えるようにすることが可能になる。

以上、１実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明におけるプログラムは、図５に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図５の処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図５の各装置の処理方法ごとのプログラムであってもよい。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ クライアント端末
１０２ 管理端末
１０３ ワークフローサーバ
１０４ データベースサーバ
１０５ ネットワーク
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ システムバス
２０５ 入力コントローラ（入力Ｃ）
２０６ ビデオコントローラ（ＶＣ）
２０７ メモリコントローラ（ＭＣ）
２０８ 通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）
２０９ ＫＢ（キーボード）
２１０ ＣＲＴ
２１１ 外部メモリ（ＨＤ、ＦＤ）

Claims (8)

1. 最終承認が完了していない処理中の案件に対して現在割り当てられている変更前の工程定義と、前記案件に対し変更を行うための変更後の工程定義を記憶した工程定義記憶手段と、前記案件の処理を行った工程処理担当者とこれから処理を行う工程処理担当者を識別可能にする工程状態記憶手段を有する記憶装置と通信可能であって、前記案件に対し、前記変更後の工程定義に割り当てることにより、当該案件を前記変更後の工程定義によって処理することを可能するワークフローサーバにおいて、
   工程定義を変更する案件の選択を受け付ける案件受付手段と、
   前記案件受付手段で受け付けた前記案件に対し、前記変更後の工程定義の割り当てを行う変更後の工程定義割り当て手段と、
   前記変更後の工程割り当て手段により割り当てた前記変更後の工程定義が保持する１つの工程である検証工程の工程処理担当者と同じ工程処理担当者の指定により、前記案件の処理済みの工程において処理が行われたことがあるか否かを判定する判定手段と、
   前記判定手段で、前記変更後の工程割り当て手段により割り当てた前記変更後の工程が保持する１つの工程である検証工程の工程処理担当者と同じ工程処理担当者の指定により、前記案件の処理済みの工程において処理が行われたことがないと判定した場合、前記案件が次に処理する工程処理担当者を、前記判定手段において存在しないと判定した前記検証工程の工程処理担当者に変更するべく、前記工程状態記憶手段において、当該検証工程の工程処理担当者が前記案件の処理待ちである状態とするレコードを作成する処理待ち状態作成手段と、
   を備え、
   前記変更後の工程定義割り当て手段は、前記受付手段で受け付けた案件を、前記処理待ち状態作成手段により、処理待ち状態として作成した工程以降、前記変更後の工程定義割り当て手段で割り当てた工程定義により処理をすることを可能とすること
   を特徴とするワークフローサーバ。
   
2. 前記判定手段で、前記検証工程の工程処理担当者と同じ工程処理担当者の指定により、前記案件の処理済みの工程において処理が行われたことがあると判定した場合、前記検証工程の工程処理担当者と同じ工程処理担当者の指定により、前記案件の処理済みの工程において処理が行われた工程の状態が、処理済みか処理待ちかを判定する処理済み判定手段と、
   前記処理済み判定手段において、処理済みと判定した場合、前記判定手段は、前記変更後の工程定義における前記検証工程の次の工程の工程処理担当者と同じ工程担当者の指定により、前記案件の処理済みの工程において処理が行われたことか否かを、判定すること
   を特徴とする請求項１に記載のワークフローサーバ。
3. 前記処理済み判定手段において、前記判定手段で、検証工程と同じ工程処理担当者が割り当てられている工程と判定した前記案件に割り当てられている工程の状態が、処理待ちと判定した場合、
   前記案件に現在割り当てられている経路において処理待ちの工程を、
   前記処理済み判定手段で処理待ちの状態と判断した工程を、前記案件の処理が行われるようにするべく、処理待ちの状態のままとすること
   を特徴とする請求項２に記載のワークフローサーバ。
   
4. 前記処理待ち状態作成手段は、更に、前記工程状態記憶手段において、前記案件の、変更前の工程定義で処理された、処理待ちの状態であるレコードの状態を取り消しの状態に変更する状態変更手段
   を特徴とする請求項１乃至３のいずれか１項に記載のワークフローサーバ。
   
5. 前記判定手段は、前回の処理に引き続き判定を行う場合、前記検証工程の工程処理担当者と同じ工程処理担当者の指定により、前記案件の処理済みの工程における前回判定した工程よりも後に処理が行われた工程において処理が行われたことがあるか否かを判定すること
   を特徴とする
   請求項１乃至４のいずれか１項に記載のワークフローサーバ。
   
6. 状態変更手段は、更に、前記案件が、前記変更後の工程定義の全ての工程の工程処理担当者と同じ工程処理担当者の指定により処理されていて、かつ、前記案件の次に処理される工程の状態が処理待ちであるレコードが存在する場合、前記案件の次に処理される工程のレコードの状態を取り消しへ変更すること
   を特徴とする請求項４または５のいずれか１項に記載のワークフローサーバ。
7. 最終承認が完了していない処理中の案件に対して現在割り当てられている変更前の工程定義と、前記案件に対し変更を行うための変更後の工程定義を記憶した工程定義記憶手段と、前記案件の処理を行った工程処理担当者とこれから処理を行う工程処理担当者を識別可能にする工程状態記憶手段を有する記憶装置と通信可能であって、前記案件に対し、前記変更後の工程定義に割り当てることにより、当該案件を前記変更後の工程定義によって処理することを可能するワークフローサーバの制御方法において、
   案件受付手段が、工程定義を変更する案件の選択を受け付ける案件受付ステップと、
   変更後の工程定義割り当て手段が、前記案件受付ステップで受け付けた前記案件に対し、前記変更後の工程定義の割り当てを行う変更後の工程定義割り当てステップと、
   判定手段が、前記変更後の工程割り当て手段により割り当てた前記変更後の工程定義が保持する１つの工程である検証工程の工程処理担当者と同じ工程処理担当者の指定により、前記案件の処理済みの工程において処理が行われたことがあるか否かを判定する判定ステップと、
   処理待ち状態作成手段が、前記判定ステップで、前記変更後の工程割り当て手段により割り当てた前記変更後の工程が保持する１つの工程である検証工程の工程処理担当者と同じ工程処理担当者の指定により、前記案件の処理済みの工程において処理が行われたことがないと判定した場合、前記案件が次に処理する工程処理担当者を、前記判定ステップにおいて存在しないと判定した前記検証工程の工程処理担当者に変更するべく、前記工程状態記憶手段において、当該検証工程の工程処理担当者が前記案件の処理待ちである状態とするレコードを作成する処理待ち状態作成ステップと、
   を含み、
   前記変更後の工程定義割り当てステップは、前記受付ステップで受け付けた案件を、前記処理待ち状態作成ステップにより、処理待ち状態として作成した工程以降、前記変更後の工程定義割り当てステップで割り当てた工程定義により処理をすることを可能とすること
   を特徴とするワークフローサーバの制御方法。
8. 最終承認が完了していない処理中の案件に対して現在割り当てられている変更前の工程定義と、前記案件に対し変更を行うための変更後の工程定義を記憶した工程定義記憶手段と、前記案件の処理を行った工程処理担当者とこれから処理を行う工程処理担当者を識別可能にする工程状態記憶手段を有する記憶装置と通信可能であって、前記案件に対し、前記変更後の工程定義に割り当てることにより、当該案件を前記変更後の工程定義によって処理することを可能するワークフローサーバにおいて実行可能なプログラムであって、
   工程定義を変更する案件の選択を受け付ける案件受付手段と、
   前記案件受付手段で受け付けた前記案件に対し、前記変更後の工程定義の割り当てを行う変更後の工程定義割り当て手段と、
   前記変更後の工程割り当て手段により割り当てた前記変更後の工程定義が保持する１つの工程である検証工程の工程処理担当者と同じ工程処理担当者の指定により、前記案件の処理済みの工程において処理が行われたことがあるか否かを判定する判定手段と、
   前記判定手段で、前記変更後の工程割り当て手段により割り当てた前記変更後の工程が保持する１つの工程である検証工程の工程処理担当者と同じ工程処理担当者の指定により、前記案件の処理済みの工程において処理が行われたことがないと判定した場合、前記案件が次に処理する工程処理担当者を、前記判定手段において存在しないと判定した前記検証工程の工程処理担当者に変更するべく、前記工程状態記憶手段において、当該検証工程の工程処理担当者が前記案件の処理待ちである状態とするレコードを作成する処理待ち状態作成手段と、
   として機能させ、
   前記変更後の工程定義割り当て手段は、前記受付手段で受け付けた案件を、前記処理待ち状態作成手段により、処理待ち状態として作成した工程以降、前記変更後の工程定義割り当て手段で割り当てた工程定義により処理をすることを可能とすること
   を特徴とするワークフローサーバで実行可能なプログラム。

Images