JP2011034492A - 情報処理装置、情報処理システム、情報処理方法、プログラム、および記録媒体。 - Google Patents

Abstract

【課題】ワークフローシステムにおいて、進行中の案件の設計情報の変更を、案件の再申請をすることなく可能とする。
【解決手段】複数バージョンの業務定義が可能な業務設計情報を記憶する記憶手段と、ユーザーからの要求により、バージョンの変更指示を受け付ける変更指示受付手段と、前記変更指示に応じて、当該変更指示にかかる業務設計情報に基づいて生成された案件の進行を制限する制限手段と、前記変更指示に応じて、前記記憶手段に記憶された業務設計情報にそれぞれ含まれる、変更前バージョンの業務定義と、変更後バージョンの業務定義との整合性の確認を行う確認手段と、前記確認手段により整合性の確認が取れた場合、前記制限手段により制限された案件にかかる案件情報を、変更後バージョンの業務定義を用いて変更する変更手段とを有し、前記制限手段は、前記変更手段により案件情報に含まれる項目が変更された案件の制限を解除することを特徴とする。
【選択図】図７

Description

本発明は、版管理された業務設計に従ってワークフローを管理するワークフローシステムに関する。

近年では、企業内でさまざまな業務プロセスがシステム化されているが、社会的なＩＴ統制のニーズによって、ＩＴシステムへの変更管理や改ざん防止の機能が必須になりつつある。

通常ワークフローシステムでは、データの改ざんを防ぐために、既に作成された案件データは、業務設計で処理を許可されたユーザー以外が関与することを許可しないし、一部例外的に管理者であろうと修正することを許可しない。

また、改ざんを防ぐという目的からある版で作成した業務設計をその版で修正することを許可しない。

特許文献１には、複数のワークフローを並行運用するワークフローシステムが開示されている。

また、特許文献２には、新旧を含む複数のバージョンの組織のワークフローを共存させて、進行中のワークフローの組織を自在に変更可能にすることを可能にするワークフローシステムが開示されている。

特開２００５−９２５４４号公報 特開２００８−３１０７１０号公報

しかしながら、特許文献１に記載の技術は、複数のワークフローを並行運用させることを可能とし、１つ１つのワークフローを版として扱うことで、版管理可能なワークフローシステムとして運用することができるというものであるが、作成したワークフロー設計の間違いに気がついた場合に、新しいワークフローで継続運用することができない。

このようなワークフローシステムでは、申請画面の入力チェックに間違いがある場合や、ワークフローを進めるための条件判断に間違いがあった場合には、業務設計や案件データの修正が行えないため、案件が滞留してしまう。滞留を解消するためには新しい版の業務設計を作成・修正した上で、滞留している案件をすべて再申請しなければならず、手間が大きいという問題点がある。また、上記業務設計の間違いだけでなく、外部的な要因（社名変更、法律の制度改定）などでも帳票文言の修正や、レイアウトの変更は発生する。長期間の業務運用を想定した場合には、業務設計の変更は必ず必要になり、進行中のワークフローを変更後の業務設計で継続的に運用できるようにする仕組みが必須となる。

また、 特許文献２に記載技術は、進行中のワークフローの組織を自在に変更することを可能にするものであるが、進行中のワークフローの業務設計を変更することができない。そのため、進行中の案件の設計情報の変更ができない。

本発明は、上記課題を解決するものであり、ワークフローシステムにおいて、進行中の案件の設計情報の変更を、案件の再申請をすることなく可能とすることを目的とする。

本発明は、ワークフローの手順において進行中の案件の基となる業務設計情報の変更が可能な情報処理装置において、複数バージョンの業務定義が可能な業務設計情報を記憶する記憶手段と、ユーザーからの要求により、バージョンの変更指示を受け付ける変更指示受付手段と、前記変更指示に応じて、当該変更指示にかかる業務設計情報に基づいて生成された案件の進行を制限する制限手段と、前記変更指示に応じて、前記記憶手段に記憶された業務設計情報にそれぞれ含まれる、変更前バージョンの業務定義と、変更後バージョンの業務定義との整合性の確認を行う確認手段と、前記確認手段により整合性の確認が取れた場合、前記制限手段により制限された案件にかかる案件情報を、変更後バージョンの業務定義を用いて変更する変更手段とを有し、前記制限手段は、前記変更手段により案件情報に含まれる項目が変更された案件の制限を解除することを特徴とする。

本発明によれば、ワークフローシステムにおいて、進行中の案件の設計情報の変更を、案件の再申請をすることなく可能となる。

ワークフローシステムの構成を示すシステム構成図 各種端末のハードウエア構成を示す図 ワークフローサーバにおける機能構成の一例を示す図 業務設計と案件情報のデータ構造を示す図 業務設計を登録するための画面例 各種エディタの画面例 滞留が発生した場合に業務の付け替えを行い滞留案件が進んだ一例 案件情報の一例（項目知空白） 案件情報の一例（Ｖ１） 業務設計の一例（Ｖ２追加） フォームエディタの一例（項目追加例） 業務メンテナンス画面の一例 案件情報の一例（Ｖ２） 業務バージョン付け替え処理の流れを示すフローチャート 整合性チェックの処理の流れを示すフローチャート

以下、本発明の好ましい実施の形態について図面を参照しながら詳細に説明する。

図１は、本発明に係るワークフローシステム（情報処理システム）の構成を示すシステム構成図である。

図１において、ワークフローシステムは、少なくとも１つのワークフローサーバ１０１とワークフロークライアント１０２がネットワークを介して接続されている。

ユーザーは、例えばウェブブラウザやクライアントソフトウェアなどを利用して、ワークフロークライアント１０２から、ワークフローサーバ１０１に対して、ワークフロー進行の要求などを行う。

ワークフローサーバ１０１は、要求に応じた処理、管理をおこない、必要があればワークフロークライアント１０２に対して結果などを送信する。

ワークフローサーバ１０１とワークフロークライアント１０２の間の通信は、通常のＨＴＴＰのリクエストでもよいし、ＳＯＡＰなどを利用したウェブサービスのリクエストでもよい。また、ワークフローサーバ１０１からネットワークを介してＤＢサーバ１０３へ接続されており、ＤＢサーバ１０３に処理履歴データ１０４を保持している。

図２は、本発明の実施形態の各種端末のハードウエア構成を示す図である。

図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。

また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。

入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。また、印刷装置等では、タッチパネル、ボタン、スイッチ等が挙げられる。

出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶等が挙げられる。

外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザーファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。

通信Ｉ／Ｆコントローラ２０８は、ネットワーク２１４を介して外部機器との通信制御処理を実行する。

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

図３は、本発明のワークフローサーバ（情報処理装置）における機能構成の一例を示す図である。

ワークフロー処理部３０１は、一般ユーザーが操作するワークフロークライアント１０２からの要求を受け、業務設計格納部３１０に格納された業務設計情報を基に、案件情報を作成し、案件情報格納部３２０に案件情報を格納する。また、ワークフロー処理部３０１は、一般ユーザーが操作するワークフロークライアント１０２からの要求を受け、案件情報格納部３２０から案件情報を取り出し、ワークフローの進行と、案件情報の更新を行う。なお、ワークフロー処理部３０１が、ワークフローの進行と、案件情報の更新を行う際には、業務設計格納部３１０に格納された業務設計情報に設定された定義にしたがって、処理を行う。

バージョン情報付け替え処理部３０２は、管理ユーザーが操作するワークフロークライアント１０２からの案件の業務設計バージョン付け替え要求（もしくは、付け替え指示、変更要求、変更指示）を受けて、案件情報格納部３２０に格納されている案件情報が参照している、特定のバージョンの業務情報への参照を、別のバージョンの業務情報へ付け替える処理を行う。（付け替えとは、変更ともいう。以下同じ。）
図４は、業務設計と案件情報のデータ構造を示す図である。

業務設計３１１は、業務設計格納部３１０に格納された情報で、実データとして、業務定義４０１と経路定義４０２とフォーム定義４０３と項目定義４０４とを含む。また、複数バージョンの業務設計情報を含む。後述する付け替え指示がなされた場合は、複数バージョンの業務設計情報から変更前バージョンと、変更後バージョンとの定義情報を用いる。

この業務設計３１１は、管理ユーザーがワークフロークライアント１０２を使用して、ワークフローの開始前に登録を行うものである。

業務定義４０１は、業務設計３１１を特定するための定義情報を保持する。また、業務定義４０１は、業務設計の１つを特定するための情報として、業務ＩＤおよび、業務バージョン番号を保持する。また、業務定義４０１は、業務名と、有効期間Ｆｒｏｍと有効期間Ｔｏを保持する。有効期間Ｆｒｏｍと有効期間Ｔｏとは、合わせて業務定義４０１の有効期間を示し、案件の起案時点に有効な業務定義を特定するために使用される。

経路定義４０２は、ワークフローの流れ（手順）の定義情報を保持する。また、経路定義４０２は、業務定義４０１への関連を示すための情報として、業務ＩＤおよび、業務バージョン番号とを保持し、業務ＩＤ、業務バージョン番号、経路ＩＤを合わせて１つの経路定義を特定するための情報として保持する。また、経路定義４０２は、経路名と、経路データの定義情報を保持する。経路データは、「誰が申請・承認を行えるか」や「申請ではどのフォーム定義を使用するか」などの定義情報を保持している。

フォーム定義４０３は、ワークフローを操作するユーザーが直接操作する画面の定義情報を保持する。また、フォーム定義４０３は、業務定義４０１への関連を示すための情報として、業務ＩＤおよび、業務バージョン番号とを保持し、業務ＩＤ、業務バージョン番号、フォームＩＤを合わせて１つのフォーム定義を特定するための情報として保持する。また、フォーム定義４０３は、フォーム名と、フォームデータなどの定義情報を保持する。フォームデータは、「申請や承認などで使用するフォームのレイアウト定義」だけでなく、「承認ボタンを押下した時の入力内容チェックロジック」「画面オープン時の初期値表示ロジック」などの処理ロジックも保持している。

項目定義４０４は、案件情報３２１が、保持するべきデータの型や長さなどのデータ定義情報を保持する。また、項目定義４０４は、業務定義４０１への関連を示すための情報として、業務ＩＤおよび、業務バージョン番号とを保持し、業務ＩＤ、業務バージョン番号、項目ＩＤを合わせて１つの項目定義を特定するための情報として保持する。また、項目定義４０４は、項目名と、型と、長さ、などの定義情報を保持する。

上述した通り、この業務設計３１１は、管理ユーザーがワークフロークライアント１０２を使用して、ワークフローの開始前に登録を行うものである。

なお、有効期間Ｆｒｏｍに到達して、有効になった業務設計３１１の修正は行えないが、本実施の形態によれば、新しいバージョンの業務設計３１１を作成して、業務設計３１１を変更することができるので、管理ユーザーは、期間的な制約なく業務設計をメンテナンスが行える。

次に、案件情報３２１は、案件情報格納部３２０に格納された情報で、実データとして、案件データ４０５と案件子データ４０６を含む。

この案件情報３２１は、ユーザーがワークフロークライアント１０２を使用して、ワークフローを開始した時に作成されるデータである。

案件データ４０５は、案件情報３２１を特定するためのデータ情報を保持する。また、案件データ４０５は、業務定義４０１への関連を示すための情報として、業務ＩＤおよび、業務バージョン番号とを保持し、業務ＩＤ、案件ＩＤを合わせて１つの案件データを特定するための情報として保持する。また、案件データ４０５は、業務バージョン番号やワークフローの進捗状況なども保持する。

案件子データ４０６は、案件情報３２１の実データを保持する。また、案件子データ４０６は、案件データ４０５への関連を示すための情報として、業務ＩＤおよび、案件ＩＤを保持し、業務ＩＤ、案件ＩＤ、項目ＩＤを合わせて１つの案件子データを特定するための情報として保持する。また、業務ＩＤ、業務バージョン番号、項目ＩＤは、案件子データ４０６の定義情報である項目定義４０４を特定するための情報としても利用される。また、案件子データ４０６は、業務バージョン番号や項目値を案件の実データ情報として保持する。

ところで、通常は、案件の起案時点で有効な業務設計３１１を使用して、案件を作成するが、ワークフローシステムによっては、過去や未来の時点を指定して、指定された時点で有効な業務設計３１１を使用した案件を作成できるシステムを構築することも可能である。

図４に示す案件データ４０５では、１つの業務定義４０１へのみ関連付けられているが、本実施の形態によれば、起案時点の業務定義と、付け替え処理後の業務定義を複数保持することも可能である。

一方、業務定義への関連を１つしか持たないワークフローシステムでは、例えば、最終承認工程の承認待ちの案件があり、付け替え後の業務設計の経路定義では、最終承認工程が存在しない場合には、最終承認が行われたと判断するべきか、案件不成立として否決するべきか、１つ前の工程に差し戻するべきか、適当な工程を選択してそこからフローを継続するべきか、などの選択肢を選ぶ必要がある。

しかしながら、本実施の形態における、案件に業務設計への関連を複数保持するワークフローシステムにおいては、経路定義の変更は、フォーム定義のようなレイアウトの変更に比べて、頻繁に行われる変更ではないので、付け替え時の処理を繁雑にするよりも、経路定義は付け替えが行われた場合でも、起案時点のものを使用し続けて、フォーム定義、項目定義のみ、新しい業務設計へ関連付け替えるというに制限することで、付け替え処理の負担を軽減することが可能である。

図５は、業務設計を登録するための画面例である。

業務設計は、管理ユーザーがワークフロークライアント１０２を操作して編集・登録を行う。

具体的には、項目エディタ５０１、経路エディタ５０２、およびフォームエディタ５０３を使用して、業務設計３１１の編集・登録を行う。

項目エディタ５０１は、図４に示す、業務定義４０１および、項目定義４０４の定義情報を登録するための画面である。この例では、「業務ＩＤ」、「業務バージョン」、「業務名」、「有効期間」の欄へ入力された値が、業務定義４０１へ登録され、「項目ＩＤ」、「項目名」、「型」、「文字」等に入力された値が項目定義４０４へ登録されることとなる。

経路エディタは５０２、図４に示す、経路定義４０２の定義情報を登録するための画面である。この例では、「申請」「承認」「最終承認」の順にワークフローが進む経路が定義されている。

フォームエディタ５０３は、図４に示す、フォーム定義４０３の定義情報を登録するための画面である。なお、フォームエディタ５０３では、フォームのレイアウトだけでなく、フォームでボタンを押下した場合の処理内容や、フォームを開いたときの初期表示などの処理ロジックを登録することができる。この例では、「Ｃｌｉｃｋ［ＦＯＲＭ＿ＳＹＯＮＩＮ］＿承認」５０３１には、ＦＯＲＭ＿ＳＹＯＮＩＮフォームの、承認ボタンをクリックした際の処理として、入力チェックや、ワークフローサーバへの承認要求の呼び出しが記載されている。具体例として、入力チェックには、後述の業務の付け替えを説明するために、間違い（「存在しない項目 ＩＴＥＭ＿ＳＹＯＮＩＮＳＹＡ の入力チェックを行っている」）が含まれている。

図６に、上記各種エディタを介して編集・登録された業務設計３１１の具体例を示す。

次に、図７〜図１３を用いて、起案した案件が滞留し、業務付け替えにより、案件が無事流れるまでの具体例を説明する。

図７は、滞留が発生した場合に業務の付け替えを行い滞留案件が進んだ一例を示す図である。

「ステップ１」
ユーザーが操作するワークフロークライアントの要求により、ワークフローサーバが、案件と、ワークフローを生成したことを示している。なお、生成した案件は、この時点で有効な業務定義Ｖ１を参照するように設定されているものとする。この時点における案件情報（案件データ４０５と案件子データ４０６とを含む）の例を図８に示す。案件データに登録されている業務ＩＤ、業務バージョン番号の組み合わせが、図７に示す業務定義Ｖ１である業務設計３１１への参照を示している。

「ステップ２」
ユーザーが操作するワークフロークライアントの申請要求により、ワークフローサーバが、前記案件のフローを承認工程に進めたことを示している。この時点における案件情報（案件データ４０５と案件子データ４０６とを含む）の例を図９に示す。申請内容が、案件子データに項目値として登録されたことを示している。

「ステップ３」
フォームエディタ５０３での登録内容に誤り「存在しない項目 ＩＴＥＭ＿ＳＹＯＮＩＮＳＹＡ の入力チェックを行っている」がある場合を例として説明する。

このケースでは、承認ユーザーが操作するワークフロークライアントにより承認指示がなされた場合であっても、フォームエディタ５０３での登録内容に誤り「存在しない項目 ＩＴＥＭ＿ＳＹＯＮＩＮＳＹＡ の入力チェックを行っている」があるため、ワークフローサーバは、承認処理を行うことができず、案件が滞留することになる。

そこで、管理ユーザーは、ワークフロークライアント端末を操作して、項目エディタ５０１を使用して、業務定義Ｖ２を作成し、項目ＩＴＥＭ＿ＳＹＯＮＩＮＳＹＡを登録する。さらに、フォームエディタ５０３を使用して、承認フォーム上に承認者欄を配置する設計を行う。

新たに設計した内容は、業務設計３１１に追加して記録される。追加設計した業務設計の例を図１０に示す。図１０では、業務定義４０１、フォーム定義４０３、項目定義４０４の「業務バージョン番号」にそれぞれＶ２のレコードが追加して記録されていることが分かる。

ここでは、項目定義４０４の最終行にＩＴＥＭ＿ＳＹＯＮＩＮＳＹＡを登録されている。また、フォーム定義４０３のフォームデータが変更されていることが分かる（１００１）。図１１は、フォームエディタ５０３で「承認者欄」１１０１を配置した例である。これにより承認者は、承認する際に、「承認者欄」に承認者名を入力することとなる。

続いて、管理ユーザーは、ワークフロークライアントを操作し、図１２に示す案件メンテナンス画面１２００を介して、案件を検索して、検索結果の案件を行選択して、業務の付け替えを、ワークフローサーバへ要求する。ワークフローサーバは、業務付け替えが行えるかどうかをチェックして、付け替え可能と判断した場合には、案件の業務定義Ｖ１への参照を、現在有効な業務定義である業務定義Ｖ２への参照に付け替えをおこなう。この時点の案件は図１３に示すように登録されており、案件データの業務バージョンが修正され（１３０１）、案件子データにＩＴＥＭ＿ＳＹＯＮＩＮＳＹＡが項目値なしで登録されている（１３０２）。

なお、業務付け替えが行えるかのチェックはワークフローサーバが行うため、付け替えを行う管理ユーザーは、案件のデータ部分にアクセスする必要がない。このため管理者ユーザーによるデータの漏えい、改ざんなどのリスクを防ぐことができる。ワークフローサーバが行う付け替え処理およびチェックについては、図１４、１５を用いて詳細に説明する。

「ステップ４」
業務定義Ｖ２の「承認ボタンを押下した時の入力チェックロジック」が使用されたため、正常に承認を行うことが可能になり、滞留が解消する。

具体的には、承認者が滞留案件を承認する画面を再度表示すると、新たに設計された承認者欄１１０１が承認画面に表示される。承認者はこの欄に承認者名を入力した後、承認ボタンを押下すると、ワークフロークラインとからワークフローサーバへ承認依頼がなされる。そしてワークフローサーバで入力チェックロジックが動き、正常に認証処理を行うことが可能となる。案件は、次に進み、最終承認者が承認作業を行うこととなる。

以上、ステップ１〜ステップ４において一例を挙げ説明したが、例えば、「フォーム修正して、承認ボタン押下時のチェックロジックを除去する」、という方法も考えられる。

また、本実施の形態では、管理ユーザーが業務定義Ｖ２を作成した業務設計データは、図１０に示すようにすべて再作成するかのごとく説明しているが、差分があるデータ（追加した項目 ＩＴＥＭ＿ＳＹＯＮＩＮＳＹＡと、修正したフォーム ＦＯＲＭ＿ＳＹＯＮＩＮ）のみを登録して、データ量が増えすぎないようにすることも可能である。

さらに、業務付け替えの、付け替え先の業務バージョンは、現在有効な業務バージョンとせずに、業務バージョンを選択して特定の業務バージョンへ付け替えたり、過去のバージョンへ付け替えたりすることも可能である。

図１４は、ワークフローサーバにおける業務バージョン付け替え処理の流れを示すフローチャートである。

この業務バージョン付け替えの処理は、図７の「ステップ３」で示した、管理ユーザーが、ワークフロークライアントを操作して、ワークフローサーバに対して業務の付け替え処理を指示した際の、ワークフローサーバにおける処理の流れを記述したものである。具体的には、図１２に示す「業務付け替え」ボタン１２０１が押下されることにより処理が開始される。

ステップＳ６０１において、管理用クライアント１０３からの業務バージョンの付け替え処理要求を受け取り、処理を開始する。

ステップＳ６０２において、他のユーザーと案件更新の衝突を避けるために、付け替えを行う対象の案件情報３２１（案件データ４０５と、案件子データ４０６とを含む）を取得して、取得した案件をロック（制限）する。すなわち、案件をロックすることにより、ワークフローの進行が制限されることとなる。

ステップＳ６０３において、付け替えを行う案件に関連づけられている業務設計３１１（業務定義４０１と、経路定義４０２と、フォーム定義４０３と、項目定義４０４とを含む）を取得する。

以下、ここで取得した業務設計３１１を、付け替え前業務設計とし、項目定義４０４を、付け替え前項目定義とする。例として、付け替え前業務設計として、業務バージョンが「１」で登録されている各データを取得する。

ステップＳ６０４において、新しく関連づける業務定義３１１（業務定義４０１と、経路定義４０２と、フォーム定義４０３と、項目定義４０４とを含む）を取得する。

以下、ここで取得した業務設計３１１を、付け替え後業務設計とし、項目定義４０４を、付け替え後項目定義とする。例として、付け替え後業務設計として、業務バージョンが「２」で登録されている各データを取得する。

続いて、ステップＳ６０５からステップＳ６０８まで、付け替え前項目定義と付け替え後項目定義との件数分繰り返す。

ステップＳ６０７において、付け替えが行えるかの整合性チェックを行う。この整合性チェックの詳細を、図１５のフローチャートを用いて説明する。

ステップＳ６１２〜Ｓ６１５は、ステップＳ６０７から続けて処理される。

ステップＳ６１３において、付け替え前項目定義に存在する項目定義が、付け替え後項目定義で削除されていないことを確認する。もし削除されている場合は、付け替えエラーとして、以降の処理を中断し、ワークフローサーバは、管理ユーザーが操作するワークフロークライアントに対して、付け替えエラーを通知する。

一例を次に示す。図９に示す案件情報において、項目定義の業務バージョン「１」の項目定義を１件取り出して、その項目定義が業務バージョン「２」でも存在することを、図１０に示す業務設計３１１を参照して確認する。この具体例では、エラーならない。

ループ１回目：業務バージョン「１」の”ＩＴＥＭ＿ＳＨＩＮＳＥＩＢＩ”は、業務バージョン「２」でも存在する。 ループ２回目：業務バージョン「１」の”ＩＴＥＭ＿ＳＨＩＮＳＥＩＳＹＡ”は、業務バージョン「２」でも存在する。以下省略する。

なお、ここでは、付け替えエラーとしているが、付け替えエラーとせずに、ワークフローサーバは、削除された項目定義４０４を、付け替え後項目定義へ再作成するか、もしくは、案件子データ４０６から削除された項目定義４０４に一致するデータを、案件情報３２１から削除して、案件情報の整合性を保つようにし、以降の処理を継続してもよい。

ステップＳ６１４において、付け替え前項目定義が、付け替え後項目定義で属性（型や長さ）の変更が行われていないことを確認する。もし変更されている場合は、付け替えエラーとして、以降の処理を中断し、ワークフローサーバは、管理ユーザーが操作するワークフロークライアントに対して、付け替えエラーを通知する。

一例を次に示す。図９に示す案件情報において、項目定義の業務バージョン「１」の項目定義を１件取り出して、その項目定義の項目型と長さが業務バージョン「２」でも同様であることを、図１０に示す業務設計３１１を参照して確認する。この具体例では、エラーならない。

ループ１回目：業務バージョン「１」の”ＩＴＥＭ＿ＳＨＩＮＳＥＩＢＩ”の「項目型＝日時、長さは＝なし」であり、業務バージョン「２」の”ＩＴＥＭ＿ＳＨＩＮＳＥＩＢＩ”の「項目型＝日時、長さは＝なし」であるため同じであることが分かる。

ループ２回目：業務バージョン「１」の”ＩＴＥＭ＿ＳＨＩＮＳＥＩＳＹＡ”の「項目型＝文字、長さは＝２０」であり、業務バージョン「２」の”ＩＴＥＭ＿ＳＨＩＮＳＥＩＳＹＡ”の「項目型＝文字、長さは＝２０」であるため同じであることが分かる。以下省略する。

なお、ここでは、付け替えエラーとしているが、付け替えエラーとせずに、ワークフローサーバは、変更された項目定義４０４の属性を変更するか、案件子データ４０６の項目値を、付替え後項目定義の属性に一致するように、変更を行い、案件情報の整合性を保つようにし、以降の処理を継続してもよい。

ステップＳ６１５において、整合性チェックの結果を呼び出し元のステップＳ６０７に返却し、ステップＳ６０８を継続する。

ところで、ステップＳ６１３では、項目の削除を禁止しているが、もし項目定義が不要な場合には、フォーム定義４０３のフォームデータから項目定義を配置しないようにすれば良い。また、ステップＳ６１４では、項目定義の属性変更を禁止しているが、もし項目定義の属性を変更したい場合には、古い項目定義を残して、新しく項目定義を追加作成することで、項目定義の属性変更を実現すれば良い。このような項目定義の削除、項目定義の属性変更の代替策をとれば、案件情報３２１からデータの欠落なく、業務設計の付け替え処理を行うことが可能となる。

次に、ステップＳ６０９において、ステップＳ６０２で取得した案件情報３２１（案件情報３２１に含まれる、案件データ４０５と、案件子データ４０６が対象）の業務設計３１１への関連を、付け替え前業務設計から、付け替え後業務設計へ変更する。より詳細には、案件データ４０５の業務バージョン番号を「１」から「２」へ変更し、案件子データ４０６を、業務設計３２１からＶ２の項目定義を抽出して、新たに定義された項目を追加する。具体的には、図９から図１３へ変更するものである。

ステップＳ６１０において、ステップＳ６０９で変更した案件情報３２１の情報を、案件情報格納部３２０へ格納して、ステップＳ６０２で実施した、案件情報３２１のロックを解除する。案件情報が解除されることにより、この案件のワークフローの進行が再開される。

なお、この際、案件更新の後処理として、案件の最終更新日や、案件の最終更新者を記録することも可能である。

ステップＳ６１１において、業務バージョンの付け替え処理が完了し、ワークフローサーバから、管理ユーザーが操作するワークフロークライアントに対して、付け替え完了が通知され、処理が終了する。

以上説明した通り、本発明によれば、ワークフローシステムにおいて、進行中の案件の設計情報の変更を、案件の再申請をすることなく可能となる。

また、新旧を含む複数のバージョンの業務設計のワークフローを共存させることができ、進行中の案件であっても、新しい設計情報を反映することが可能になる。例えば、ワークフローを進めるための条件判断に間違いがあり、案件が滞留してしまう場合には、新しいバージョンの業務設計を登録し、条件判断を修正し、業務設計のバージョンを付け替えることで、案件の滞留を解消することができ、再申請の手間を抑制することができる。

また、案件の業務設計を付け替えによって、案件のデータが欠落してしまわぬように、付け替え前に、付け替え可能かどうかをチェックすることができる。

また、付け替えを行う管理ユーザーは、案件のデータ部分にアクセスする必要がないため、管理者ユーザーによるデータの漏えい、改ざんなどのリスクを防ぐことができる。

また、一括で最新の設計情報に変更するのではなく、案件を選択して、設計情報を反映することができるので、ある案件は、修正前の設計情報で動作し、別のある案件は、修正後の設計情報で動作することができる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

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

１０１ ワークフローサーバ
１０２ ワークフロークライアント
１０３ ＤＢサーバ
１０４ 回覧履歴

Claims (8)

1. ワークフローの手順において進行中の案件の基となる業務設計情報の変更が可能な情報処理装置において、
   複数バージョンの業務定義が可能な業務設計情報を記憶する記憶手段と、
   ユーザーからの要求により、バージョンの変更指示を受け付ける変更指示受付手段と、
   前記変更指示に応じて、当該変更指示にかかる業務設計情報に基づいて生成された案件の進行を制限する制限手段と、
   前記変更指示に応じて、前記記憶手段に記憶された業務設計情報にそれぞれ含まれる、変更前バージョンの業務定義と、変更後バージョンの業務定義との整合性の確認を行う確認手段と、
   前記確認手段により整合性の確認が取れた場合、前記制限手段により制限された案件にかかる案件情報を、変更後バージョンの業務定義を用いて変更する変更手段とを有し、
   前記制限手段は、前記変更手段により案件情報に含まれる項目が変更された案件の制限を解除することを特徴とする情報処理装置。
2. 前記確認手段は、変更前バージョンの定義情報にかかる項目定義と、変更後バージョンの業務定義にかかる項目定義との整合性の確認を行うものであり、
   前記変更手段は、前記制限手段により制限された案件にかかる案件情報に含まれる項目を、変更後バージョンの業務定義にかかる項目定義を用いて変更することを特徴とする請求項１に記載の情報処理装置。
3. 前記確認手段は、変更前バージョンから変更後バージョンにおいて、削除されている項目定義がないかをチェックすることにより整合性の確認を行うことを特徴とする請求項２に記載の情報処理装置。
4. 前記確認手段は、変更前バージョンから変更後バージョンにおいて、属性が変更されている項目定義がないかをチェックすることにより整合性の確認をお行うことを特徴とする請求項２または３に記載の情報処理装置。
5. クライアントと、ワークフローの手順において進行中の案件の基となる業務設計情報の変更が可能な情報処理装置とが通信可能な情報処理システムにおいて、
   複数バージョンの業務定義が可能な業務設計情報を記憶する記憶手段と、
   ユーザーからの要求により、バージョンの変更指示を受け付ける変更指示受付手段と、
   前記変更指示に応じて、当該変更指示にかかる業務設計情報に基づいて生成された案件の進行を制限する制限手段と、
   前記変更指示に応じて、前記記憶手段に記憶された業務設計情報にそれぞれ含まれる、変更前バージョンの業務定義と、変更後バージョンの業務定義との整合性の確認を行う確認手段と、
   前記確認手段により整合性の確認が取れた場合、前記制限手段により制限された案件にかかる案件情報を、変更後バージョンの業務定義を用いて変更する変更手段とを有し、
   前記制限手段は、前記変更手段により案件情報に含まれる項目が変更された案件の制限を解除することを特徴とする情報処理システム。
6. 記憶手段を有し、ワークフローの手順において進行中の案件の基となる業務設計情報の変更が可能な情報処理装置における情報処理方法において、
   前記記憶手段が、複数バージョンの業務定義が可能な業務設計情報を記憶する記憶ステップと、
   ユーザーからの要求により、バージョンの変更指示を受け付ける変更指示受付ステップと、
   前記変更指示に応じて、当該変更指示にかかる業務設計情報に基づいて生成された案件の進行を制限する制限ステップと、
   前記変更指示に応じて、前記記憶手段に記憶された業務設計情報にそれぞれ含まれる、変更前バージョンの業務定義と、変更後バージョンの業務定義との整合性の確認を行う確認ステップと、
   前記確認ステップにより整合性の確認が取れた場合、前記制限ステップにより制限された案件にかかる案件情報を、変更後バージョンの業務定義を用いて変更する変更ステップとを有し、
   前記制限ステップは、前記変更ステップにより案件情報に含まれる項目が変更された案件の制限を解除することを特徴とする情報処理方法。
7. ワークフローの手順において進行中の案件の基となる業務設計情報の変更が可能な情報処理装置において実行可能なプログラムであって、
   複数バージョンの業務定義が可能な業務設計情報を記憶する記憶手段、
   ユーザーからの要求により、バージョンの変更指示を受け付ける変更指示受付手段、
   前記変更指示に応じて、当該変更指示にかかる業務設計情報に基づいて生成された案件の進行を制限する制限手段、
   前記変更指示に応じて、前記記憶手段に記憶された業務設計情報にそれぞれ含まれる、変更前バージョンの業務定義と、変更後バージョンの業務定義との整合性の確認を行う確認手段、
   前記確認手段により整合性の確認が取れた場合、前記制限手段により制限された案件にかかる案件情報を、変更後バージョンの業務定義を用いて変更する変更手段として前記情報処理装置を機能させ、
   前記制限手段は、前記変更手段により案件情報に含まれる項目が変更された案件の制限を解除することを特徴とするプログラム。
8. 請求項７に記載のプログラムをコンピュータ読み取り可能に記憶した記録媒体。

Images