JP4999567B2 - 情報処理装置および情報処理装置の制御方法およびプログラムおよび記録媒体 - Google Patents

Description

本発明は、遷移経路が前記組織情報で定義されたジョブのワークフロー制御に関する。

特許文献１には、組織変更後及び変更前の新旧両組織を登録し、あるユーザが、現在もしくは過去において指定された組織に所属していた（または所属している）ことをもってワークフロー処理の実行権限があるかどうかを判定するワークフローが開示されている。
特開２００６−１９５８１２号公報

しかしながら、特許文献１では、ユーザの実行権限の有無は判定可能であるが、組織変更を跨いだワークフローの場合、次の担当者（遷移先）を自動的に決定できない場合が発生するといった問題点があった。

例えば、あるユーザが同一部門に所属している間に上司にあたる課長が替わっている場合に、そのユーザが申請した伝票をどちらの課長が承認するべきなのかを自動的に決定することが出来ないため、ユーザが判断をしてどちらかの課長に承認を依頼するといった煩雑な作業をユーザに課してしまうといった問題点があった。

また、組織の判定を現在から過去に向かって行うので、将来の組織と現在の組織と区別がつかないため、将来の組織をあらかじめ登録しておくといったことが出来ない。

また、ワークフロー開始時に指定した組織コードをもとに参照する組織を決定するため、個別のワークフローの進行のみ現組織での運用を行いたい場合に対応できないといった問題点があった。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、ワークフローにおいて新旧を含む複数のバージョンを共存させ、組織情報を効率的に管理できる仕組みを提供することである。

本発明は、遷移経路が組織情報により定義されたジョブのワークフローを制御する情報処理装置であって、前記組織情報を構成する要素毎に当該要素の有効となる期間の開始を示すバージョンを特定可能な開始バージョン識別情報および期間の終了を示すバージョンを特定可能な終了バージョン識別情報を記憶する組織情報格納手段と、前記バージョン毎の有効となる期間を特定する日時情報を記憶するバージョン有効期間格納手段と、前記ジョブの遷移先を決定する際に参照する前記組織情報のバージョンとして、指定されたバージョン識別情報、又は、指定された日時と前記バージョン有効期間格納手段に格納された日時情報から確定されるバージョンを該ジョブの関連情報として設定する設定手段と、前記遷移経路を定義する組織情報および前記ジョブの関連情報として設定された前記組織情報のバージョンに応じて、該ジョブの遷移先を決定し、該決定された遷移先にジョブを遷移させてワークフローを進行させるワークフロー進行手段と、前記組織情報の更新指示を受付けた際に前記要素の更新種別を判別する要素更新判別手段と、前記要素更新判別手段による判別結果に応じて前記組織情報格納手段に格納された開始バージョン識別情報または終了バージョン識別情報を更新する組織情報更新手段と、を有することを特徴とする。

本発明によれば、組織情報の開始バージョンと終了バージョンを管理することで、組織情報があった場合の組織変更を効率的に管理し実行することができる。

また、ワークフローの状態に関わらず将来の組織情報を登録することができる。また、有効化を行うまで使用しないことができる。

また、旧バージョンの組織で進行中のワークフローでも、途中で現バージョンの組織での運用に切り替えることができる。そして、このような切替のために発生しうる合議のやり直しを抑制することができる。

また、複数のバージョンの組織を管理するが、変更がない部分のデータを効率よく管理することにより、データレコード数を抑えることができる。また、差分を考慮しないバッチ処理による編集を行ってもデータレコード数が膨大になってしまうといった事態の発生を抑制することができる。

従って、新旧を含む複数のバージョンの組織で進行するワークフローを共存させ、矛盾なく処理することができる等の効果を奏する。即ち、旧組織で進行するワークフローと、新組織で進行するワークフローとを共存させることができる。即ち、進行中のワークフローの組織バージョンを新旧自在に変更することができる。

〔第１実施形態〕
以下、本発明の実施形態について図面を参照して説明する。

図１は、本発明の一実施形態を適用可能なワークフローシステムの一例を示す図である。

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

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

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

ワークフローサーバ１０１とワークフロークライアント１０２の間の通信は、通常のＨＴＴＰのリクエストでもよいし、ＳＯＡＰなどを利用したウェブサービスのリクエストでもよい。

図２は、図１に示したワークフローサーバ１０１とワークフロークライアント１０２のハードウェア構成の一例を示すブロック図である。

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

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

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

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

外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、外部メモリコントローラ２０７には、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。

この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。

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

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

図３は、図１に示したワークフローサーバ１０１において実現される機能構成の一例を示す図である。

図３に示すように、ワークフローサーバ１０１は、その機能構成として、入出力処理部３０１と、ワークフロー進行部３０２と、担当者判定部３０３と、組織情報登録部３０４と、組織付替部３０５と、プロセス定義情報格納部３１０と、ジョブ情報格納部３１１と、バージョン有効期間情報格納部３１２と、組織情報格納部３１６（部門情報格納部３１３と、ロール情報格納部３１４と、ユーザポジション情報格納部３１５）とを含んでいる。

入出力処理部３０１は、ワークフローサーバ１０１の入力コントローラ２０５または通信Ｉ／Ｆコントローラ２０８からの入力情報を受け付ける処理を行う。また、入出力処理部３０１は、受け付けた入力情報を内容によりワークフロー進行部３０２や組織情報登録部３０４への要求に変換する。さらに、入出力処理部３０１は、上記要求に対応する結果が応答される場合には、その結果を出力コントローラ２０６または通信Ｉ／Ｆコントローラ２０８に対して出力する。

ワークフロー進行部３０２は、入出力処理部３０１からの要求に応じて、ワークフローの進行（回覧）を制御する。詳細には、ワークフロー進行部３０２は、プロセス定義情報格納部３１０に格納されているプロセス定義情報を参照して、ジョブの作成または進行を行い、作成または進行したジョブをジョブ情報格納部３１１に格納し、次回の進行時に参照する。なお、ジョブの作成の際には、ワークフロー進行部３０２は、後述する図１２に示すバージョン番号確定処理により確定したバージョン番号をジョブ情報格納部３１１にあわせて格納する。また、ジョブの進行の際には、ワークフロー進行部３０２は、担当者判定部３０３によって判定された担当者をジョブの担当者として、ジョブ情報格納部３１１にあわせて格納する。

担当者判定部３０３は、ワークフロー進行部３０２などからの要求に応じて、部門情報格納部３１３に格納されている部門情報と、ロール情報格納部３１４に格納されているロール情報と、ユーザポジション情報格納部３１５に格納されているユーザポジション情報と、バージョン有効期間情報格納部３１２に格納されているバージョン有効期間情報と、を参照して指定された部門およびロール（役割）の担当者が指定されたバージョンにおいてどのユーザポジションであるかの判定を行う。

組織付替部３０５は、ワークフロー進行部３０２などからの要求に応じて、ジョブ情報格納部３１１に格納されているジョブ情報と、部門情報格納部３１３に格納されている部門情報と、ロール情報格納部３１４に格納されているロール情報と、ユーザポジション情報格納部３１５に格納されているユーザポジション情報と、バージョン有効期間情報格納部３１２に格納されているバージョン有効期間情報と、を参照してジョブの参照組織バージョンの付替え（詳細は後述する）を行う。

組織情報登録部３０４は、入出力処理部３０１から要求された組織登録要求を処理し、部門情報を部門情報格納部３１３に、ロール情報をロール情報格納部３１４に、ユーザポジション情報をユーザポジション情報格納部３１５に、バージョン有効期間情報をバージョン有効期間情報格納部３１２に、それぞれ格納する。

プロセス定義情報格納部３１０は、プロセス定義情報を格納する格納部である。なお、プロセス定義情報格納部に格納されているプロセス定義情報の詳細は後述する図４などに示す。

ジョブ情報格納部３１１は、ジョブ情報を格納する格納部である。ジョブ情報格納部３１１には、項目として、ジョブ識別情報、参照プロセス定義識別情報、参照組織バージョン識別情報、現在アクティビティ識別情報、割当担当者識別情報等を含む。

部門情報格納部３１３は、部門情報を格納する格納部である。なお、部門情報格納部３１３に格納されている部門情報の詳細は後述する図６などに示す。

ロール情報格納部３１４は、ロール情報（役割情報）を格納する格納部である。なお、ロール情報格納部３１４に格納されているロール情報の詳細は後述する図７などに示す。

ユーザポジション情報格納部３１５は、ユーザポジション情報（所属情報）を格納する格納部である。なお、ユーザポジション情報格納部３１５に格納されているユーザポジション情報の詳細は後述する図８などに示す。

バージョン有効期間情報格納部３１２は、バージョン有効期間情報を格納する格納部である。なお、バージョン有効期間情報格納部３１２に格納されているバージョン有効期間情報の詳細は後述する図９などに示す。

なお、入出力処理部３０１と、ワークフロー進行部３０２と、担当者判定部３０３と、組織情報登録部３０４と、組織付替部３０５は、ワークフローサーバ１０１のＣＰＵ１０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２にロードして実行することにより実現される機能に対応する。

また、プロセス定義情報格納部３１０と、ジョブ情報格納部３１１と、バージョン有効期間情報格納部３１２と、組織情報格納部３１６（部門情報格納部３１３と、ロール情報格納部３１４と、ユーザポジション情報格納部３１５）とは、外部メモリ２１１内の記憶領域として実現される。

以下、図４〜図９を用いて、本実施形態の説明に用いるプロセス定義、組織、部門情報、ロール情報、ユーザポジション情報、バージョン有効期間情報等を説明する。

図４は、図３に示したプロセス定義情報格納部３１０に格納されるプロセス定義情報の一例を示す図である。

図４に示すように、プロセス定義情報は、アクティビティ５０１において、申請者が申請を行うと、次のアクティビティ５０２に遷移し、申請部門の課長が担当者となり、さらに、アクティビティ５０２において、担当者である申請部門の課長が承認を行うと、次のアクティビティ５０３に遷移し、申請部門の部長と業務部の部長が合議担当者となり、さらに、アクティビティ５０３において、合議担当者である申請部門部長と業務部部長が賛成の承認処理を行うと、完了アクティビティに遷移する、ことを示す情報に対応する。

なお、上記申請部門とは、申請者が所属する部門のことを示している。また、上記合議担当者とは、１つのアクティビティを複数人の投票によって承認の可否を決定するようなアクティビティの場合の担当者のことをいう。例えば、営業課課員のＣが申請した場合には、アクティビティ５０２の担当者は申請部門である営業課の課長Ｂが担当となるし、合議アクティビティ５０３では申請部門である営業部の部長Ａと、業務部部長Ｄが合議の担当者となり、ワークフローが進行する。

図４に示したプロセス定義は単純な例だが、分岐や並列処理をともなう複雑なプロセス定義であるとしても、担当部門と担当ロールが定義されたアクティビティと、その遷移先を示すトランジションが定義されていることにおいて、かわりはない。また、この例においては、部門の指定を申請部門としているが、実際の部門識別情報を用いて指定することもできる。

以上に示したように、本実施形態のワークフローサーバ１０１は、図４に示したように、遷移経路が組織情報（部門，役割）で定義されたプロセス定義によって定義されたジョブのワークフローを制御する構成となっている。

図５は、本実施形態の説明に用いる組織の一例を示す図である。

例えば、図５に示すように、２００７年３月１日以降２００７年４月１日までは、Ｖ２バージョン６０１の組織が有効である。このＶ２バージョン６０１の組織には、例えば営業部６１０と、営業課６１１と、業務課６１２と、が含まれ、営業課６１１と、業務課６１２と、は営業部６１０の配下にあることを示す。

また、営業部６１０には、ユーザＡが部長として所属６２０し、営業課６１１には、ユーザＢが課長として所属６２１し、ユーザＣが課員として所属６２２し、業務課６１２には、ユーザＤが課長として所属６２３し、ユーザＥが課員として所属６２４している様子を表している。

また、Ｖ３バージョン６０２の組織においては、２００７年４月１日以降２００７年４月１０日まで有効である。このＶ３バージョン６０２の組織では、業務部６１３が新設され、業務課６１２は業務部６１３の配下に移る組織変更が行われ、業務部６１３にユーザＥが部長として所属６２５（兼務）になる、人事異動が行われたことを示している。

また、Ｖ４バージョン６０３の組織においては、２００７年４月１０日以降２００７年７月１日まで有効である。このＶ４バージョン６０３の組織では、営業課６１１に課長として所属していたユーザＢ６２１は任をとかれ、新たに課長としてユーザＧが所属６２７になり、業務課６１２に課長を兼務していたユーザＤはその任を解かれ、業務課６１２に課員として所属していたユーザＥは、業務課６１２に課長として所属６２６になり、あらたにユーザＦが課員として所属６２８する、人事異動が行われたことを示している。

図６は、図３に示した部門情報格納部３１３に格納されている部門情報の一例を示す図である。

図６に示すように、部門情報は、各部門毎に、項目として、部門ＩＤ７０１と、部門名７０２と、親部門ＩＤ７０３と、開始バージョン番号７０４（開始情報）と、終了バージョン番号７０５（終了情報）とを含む。

例えば、部門ＩＤ７０１には、部門を識別する識別情報が設定されている。また、部門名７０２には、前記部門の名称が設定されている。また、親部門ＩＤ７０３には、前記部門が所属する部門の識別情報が設定されている。

また、開始バージョン番号７０４には、前記部門が新設された組織のバージョン番号が設定されている。また、終了バージョン番号７０５には、前記部門が破棄された組織のバージョン番号、または前記組織がもっとも未来の組織のバージョンにおいても存在する場合にはそれを示す値、例えば「ＨＶ」が設定されている。

なお、図６に示す例は、図５に示した組織変更が行われた例に対応する。例えば、部門ＩＤ７０１がＤ３である業務課６１２の親部門７０３は、バージョンＶ１以降Ｖ３まではＤ１（営業部）であるが、バージョンＶ３以降は、Ｄ４（業務部）となっていることが表されている。また、バージョンＶ３以降に、部門ＩＤ７０１がＤ４である業務部が新設されたことが表されている。

図７は、図３に示したロール情報格納部３１４に格納されているロール情報の一例を示す図である。

図７に示されるように、ロール情報は、ロール（役割）毎に、項目として、ロールＩＤ８０１と、ロール名称８０２と、開始バージョン番号８０３と終了バージョン番号８０４とを含む。

例えば、ロールＩＤ８０１には、ロールを識別する識別情報が設定されている。また、ロール名８０２には、前記ロールの名称が設定されている。

また、開始バージョン番号８０４には、前記ロールが新設された組織のバージョン番号が設定されている。また、終了バージョン番号８０５には、前記ロールが破棄された組織のバージョン番号、または前記ロールがもっとも未来の組織のバージョンにおいても存在する場合にはそれを示す値、例えば「ＨＶ」が設定されている。

図８は、図３に示したユーザポジション情報格納部３１５に格納されているユーザポジション情報の一例を示す図である。

図８に示されるように、ユーザポジション情報は、ユーザポジション毎に、項目として、ユーザＩＤ９０１と、部門ＩＤ９０２と、ロールＩＤ９０３と、ユーザポジション名称９０４と、開始バージョン番号９０５と、終了バージョン番号９０６とを含む。

例えば、ユーザＩＤ９０１にはユーザを識別する識別情報が設定されている。また、部門ＩＤ９０２には、前記ユーザが所属する部門の識別情報が設定されている。

また、ロールＩＤ９０３には、前記ユーザが前記部門に所属する際のロールの識別情報が設定されている。また、ユーザポジション名称９０４には、前記ユーザが前記部門に前記ロールで所属する際のユーザ名称などが設定されている。また、開始バージョン番号９０５には、前記ユーザが前記部門に前記ロールで所属し始めた組織のバージョン番号が設定されている。

また、終了バージョン番号９０６には、前記ユーザが前記部門に前記ロールで所属しなくなった組織のバージョン番号、または前記ロールがもっとも未来の組織のバージョンにおいても所属する場合にはそれを示す値、例えば「ＨＶ」が設定されている。

図８に示した例は、図５に示した人事異動が行われた例に対応している。例えば、ユーザＩＤ９０１がＤであるユーザについては、バージョンＶ１以降バージョンＶ４までは、部門ＩＤ９０２がＤ３（業務課）にロールＩＤ９０３がＲ２（課長）として所属していることを示す。また、バージョンＶ３以降は、部門ＩＤ９０２がＤ４（業務部）にロールＩＤ９０３がＲ１（部長）として所属していることを示す。

図９は、図３に示したバージョン有効期間情報格納部３１２に格納されるバージョン有効期間情報の一例を示す図である。

図９に示されるように、バージョン有効期間情報は、バージョン毎に、項目として、バージョン番号１００１と、有効開始日時１００２と、有効終了日時１００３とを含む。

例えば、バージョン番号１００１には、組織のバージョンを識別する識別番号が設定されている。

また、有効開始日時１００２には、前記バージョンが有効となる日時の情報が設定されており、有効終了日時１００３には前記バージョンが有効でなくなる日時の情報、または前記バージョンがもっとも未来のバージョンであり、未来に渡って有効である場合にはそれを示す値、例えば「ＨＶ」が設定されている。

従って、ワークフローの状態に関わらず将来の組織情報を登録しておき、有効開始日時まで使用しないように運用することができる。

以上、図６〜図８に示したように、部門情報，ロール情報，ユーザポジション情報等から構成される組織情報は、レコード毎に当該レコードが有効となる１又は複数のバージョンを特定可能なバージョン識別情報（開始バージョン番号，終了バージョン番号）を保持し、複数のバージョンの組織情報を共存させて外部メモリ２１１（部門情報格納部３１３，ロール情報格納部３１４，ユーザポジション情報格納部３１５）に記憶可能な構成になっている。

また、図９に示したように、バージョン毎の有効となる期間を特定する日時情報（有効開始日時，有効終了日時）を有するバージョン有効期間情報が外部メモリ２１１（バージョン有効期間情報格納部３１２）に記憶されている。

以下、図１０〜図１７を参照して、本発明におけるワークフロー進行処理について説明する。

図１０は、本発明における第１の制御処理手順の一例を示すフローチャートであり、ワークフロー進行部３０２等により実行されるワークフロー進行処理に対応する。即ち、このフローチャートの処理は、ワークフローサーバ１０１のＣＰＵ１０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２にロードして実行することにより実現される。

入出力処理部３０１を経由してワークフロー開始の要求がなされたとき、ワークフロー進行部２０２は、ジョブ開始処理を行い（Ｓ４０１）、ジョブを作成および開始する。なお、ジョブの開始時には、日付またはバージョン番号によって、ジョブが参照する組織のバージョンが決定される。なお、Ｓ４０１のジョブ開始処理の詳細については後述する図１１に示す。

次に、ステップＳ４０２では、ワークフロー進行部２０２は、遷移先のアクティビティがプロセス完了を示すものかどうかの判定を行う。

そして、ステップＳ４０２で、遷移先のアクティビティがプロセス完了を示すと判定した場合には、ワークフロー進行部２０２は、ステップＳ４０９においてジョブ終了処理を行い、当該ジョブを完了する。

一方、ステップＳ４０２で、遷移先のアクティビティがプロセス完了を示すものでないと判定した場合には、ワークフロー進行部２０２は、ステップＳ４０３の担当者割当処理へ処理を進める。

ステップＳ４０３の担当者割当処理では、ワークフロー進行部２０２は、担当者判定部３０３に依頼し、前記アクティビティにおける担当者を確定する。担当者判定部３０３は前記ジョブが参照する組織バージョンを使用して担当者の判定を行う。なお、ステップＳ４０３の担当者割当処理の詳細については後述する図１３に示す。

次に、ステップＳ４０４において、ワークフロー進行部２０２は、要求待ち処理を実行する。詳細には、ワークフロー進行部２０２は、入出力処理部３０１を経由して前記アクティビティの担当者からの承認要求、または管理者からの組織付替要求が行われるのまで待機し、いずれかの要求が行われると、ステップＳ４０５へ処理を進める。なお、ステップＳ４０４の要求待ち処理の詳細については後述する図１５に示す。

ステップＳ４０５では、ワークフロー進行部２０２は、ステップＳ４０４の要求待ち処理で受けた要求が「承認要求」であったかどうかの判定を行う。なお、図４の５０３に示したように合議の場合は、合議での承認要求があった場合に「承認要求」があったと判定する。

そして、ステップＳ４０５において、ステップＳ４０４で受けた要求が「承認要求」であったと判定した場合には（Ｙｅｓ）、ワークフロー進行部２０２は、ステップＳ４０７のワークアイテム承認処理へ処理を進める。

ステップＳ４０７のワークアイテム承認処理では、ワークフロー進行部２０２は、前記承認要求の内容に応じて承認処理を行い、遷移先のアクティビティを確定し、ステップ４０２の判定へ処理を戻す。なお、ステップＳ４０７のワークアイテム承認処理の詳細については後述する図１６に示す。

一方、ステップＳ４０５において、ステップＳ４０４で受けた要求が「承認要求」でなかったと判定した場合には（Ｎｏ）、ワークフロー進行部２０２は、ステップＳ４０６へ処理を進める。

ステップＳ４０６では、ワークフロー進行部２０２は、ステップＳ４０４の要求待ち処理で受けた要求が「組織付替要求」であったかどうかの判定を行う。

そして、ステップＳ４０５において、ステップＳ４０４で受けた要求が「承認要求」でなかったと判定した場合には（Ｎｏ）、ワークフロー進行部２０２は、ステップＳ４０４の要求待ち処理へ処理を戻し、再び要求待ちを行う。なお、その他の要求について対応する処理を行う場合には、Ｓ４０４の要求待ち処理に戻るまえに、前記その他の要求に対応する処理を行ってもよい。

一方、ステップＳ４０６において、ステップＳ４０４で受けた要求が「組織付替要求」であったと判定した場合には（Ｙｅｓ）、ワークフロー進行部２０２は、ステップＳ４０８において、組織付替部３０５へ組織付替処理を実行させる。

ステップＳ４０８の組織付替処理では、組織付替部３０５は、前記組織付替要求の内容に応じて前記ジョブが参照する組織バージョンを新たに指定したものに付替える処理を行い、Ｓ４０４へ処理を戻す。なお、ステップＳ４０８の組織付替処理の詳細については後述する図１７に示す。

以上、図１０に示すような処理を行うことで、ワークフローの実体であるジョブは、開始時（ジョブ作成時）に指定された、参照する組織バージョンに応じて、遷移先アクティビティの担当者を決定しながら、ワークフローを進行し、処理することができる。

従って、図１０に示すような処理を実行することにより、単一のワークフローサーバ１０１の単一のワークフローシステム上においてであっても、過去や現在や未来の組織を共存させ、ワークフローを矛盾なく進行することができる。

また、必要に応じて、個々のワークフローの実体であるジョブ毎に、それまで参照していた組織とは別のバージョンを参照させることにより、旧組織時代のジョブをスムーズに新組織に移行することができる。

以下、図１１を参照して、図１０のステップＳ４０１に示したジョブ作成処理について説明する。

図１１は、本発明における第２の制御処理手順の一例を示すフローチャートであり、図１０のステップＳ４０１に示したジョブ作成処理に対応する。即ち、このフローチャートの処理は、ワークフローサーバ１０１のＣＰＵ１０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２にロードして実行することにより実現される。

図１１に示すように、ジョブ作成処理が開始されると、ステップＳ１１０１において、ワークフロー進行部３０２は、入出力処理部３０１から渡された入力情報を使用し、バージョン確定処理を行う。なお、ステップＳ１１０１のバージョン確定処理の詳細については後述する図１２において示す。

そして、ステップＳ１１０１のバージョン確定処理においてジョブが参照する組織のバージョン番号が確定すると、ステップＳ１１０２へ処理を進める。

ステップＳ１１０２では、ワークフロー進行部３０２は、入出力処理部３０１から渡された入力情報に含まれるプロセス定義識別情報に該当する、プロセス定義格納部３１０に格納されるプロセス定義情報を参照し、ワークフローの実体であるジョブを作成する。さらに、ワークフロー進行部３０２は、Ｓ１１０１のバージョン確定処理により確定した組織のバージョン番号をジョブ関連情報と関連付けて、ジョブの他の属性とともにジョブ情報格納部３１１に格納し、ステップＳ１１０３に処理を進める。

次に、ステップＳ１１０３において、ワークフロー進行部３０２は、プロセス定義ジョブの状態を開始状態にするなどして、ジョブを開始し、その状態をジョブ情報格納部３１１に格納し、ステップＳ１１０４に処理を進める。

ステップＳ１１０４では、ワークフロー進行部３０２は、プロセス定義格納部３１０に格納される前記プロセス定義を参照し、その最初のアクティビティを遷移先アクティビティとしてジョブ情報に設定し、ジョブ情報格納部３１１に格納する。

以上、図１１に示すような処理を行うことによって、入力情報に応じたプロセス定義に基づくジョブが、入力情報に応じた組織のバージョンを参照する状態で作成、開始される。

以下、図１２を参照して、図１１のステップＳ１１０１に示したバージョン確定処理について説明する。

図１２は、本発明における第３の制御処理手順の一例を示すフローチャートであり、図１１のステップＳ１１０１に示したバージョン確定処理に対応する。即ち、このフローチャートの処理は、ワークフローサーバ１０１のＣＰＵ１０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２にロードして実行することにより実現される。

図１２に示すように、バージョン確定処理が開始されると、ステップＳ１２０１において、ワークフロー進行部３０２は、組織バージョン指定方法について判定を行う。組織バージョン指定方法としては、日時による指定方法と、バージョン番号による指定方法と、無指定とがある。この組織バージョン指定方法は、申請時に申請者によりワークフロークライアント１０２の入力部から入力されるものであり、ワークフロー開始要求内に含まれる。

なお、組織バージョン指定方法が「日時」による指定方法の場合には、ワークフロー進行部３０２は、指定された日時を指定日時としてステップＳ１２０３へ処理を進める。

また、組織バージョン指定方法が「バージョン番号」による指定方法の場合には、ワークフロー進行部３０２は、そのバージョン番号を指定バージョン番号としてステップＳ１２０４へ処理を進める。

また、組織バージョン指定方法が「無指定」の場合には、ワークフロー進行部３０２は、そのまたステップＳ１２０２へ処理を進める。

ステップ１２０２では、担当者判定部３０３は、現在の日時を取得し、それをもって指定日時とみなして、ステップＳ１２０３へ処理を進める。

ステップ１２０３では、担当者判定部３０３は、バージョン有効期間情報格納部３１２に格納されるバージョン有効期間情報を参照し、前記指定日時が有効開始日時１００２以降であることと、且つ、前記指定日時が有効終了日時１００３より前であることと、を満たすバージョン番号１００１を取得し、そのバージョン番号をもって指定バージョン番号とし、ステップ１２０４へ処理を進める。

ステップ１２０４においては、担当者判定部３０３は、指定バージョン番号を入力情報に対応する組織のバージョン番号として確定し、バージョン確定処理の結果として、呼出元（図１１の処理）に返し、本フローチャートの処理を終了する。

以上、図１２に示すような処理を行うことによって、現在時において有効な組織のバージョンのみならず、日時やバージョン番号といった指定方法で対象となる組織のバージョン番号を確定することができる。このことによって、現在の組織だけでなく、ジョブに対応する業務の種類などによって前月の組織のバージョンを指定したり、翌月の組織のバージョンを指定したり、といった柔軟な指定が可能となる。

以下、図１３を参照して、図１０のステップＳ４０３に示した担当者割当処理について説明する。

図１３は、本発明における第４の制御処理手順の一例を示すフローチャートであり、図１０のステップＳ４０３に示した担当者割当処理に対応する。即ち、このフローチャートの処理は、ワークフローサーバ１０１のＣＰＵ１０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２にロードして実行することにより実現される。

図１３に示すように、担当者判定部３０３は、ステップＳ１３０１において、ジョブ情報格納部３１１に格納される当該ジョブのジョブ情報を参照し、遷移先アクティビティ情報と、参照している組織のバージョン番号とを取得し、ステップＳ１３０２へ処理を進める。

ステップＳ１３０２では、担当者判定部３０３は、プロセス定義情報格納部３１０に格納されている当該ジョブが結びついているプロセス定義情報を参照し、前記遷移先アクティビティの定義情報に定義される、担当者の部門識別情報と、担当者のロール識別情報とを取得し、Ｓ１３０３の担当者検索処理へ処理を進める。なお、ステップＳ１３０３の担当者検索処理の詳細については後述する図１４に示すが、前記組織のバージョン番号と、前記担当者の部門情報と、前記担当者のロール情報と、から、少なくとも１つ以上のユーザポジション情報を検索し、ステップ１３０４へ処理を進める。

次に、ステップＳ１３０４において、担当者判定部３０３は、Ｓ１３０３の担当者検索処理において検索されたユーザポジション情報の一部または全部を、当該ジョブの遷移先アクティビティの担当者として割当て、ジョブ情報格納部３１１にジョブ情報の一部として格納し、ステップＳ１３０５へ処理を進める。

次に、ステップＳ１３０５において、担当者判定部３０３は、前記ユーザポジション情報を参照し、該当ユーザにメールなどによる通知を行い、本フローチャートの処理を終了する。なお、S１３０５の通知の処理は必須の処理ではない。

以上、図１３に示すような処理を行うことによって、ジョブの遷移先のアクティビティにおける担当者をジョブが参照する組織のバージョンにおいて検索し、割当てることが可能となる。

以下、図１４を参照して、図１３のステップＳ１３０３に示した担当者検索処理について説明する。

図１４は、本発明における第５の制御処理手順の一例を示すフローチャートであり、図１３のステップＳ１３０３に示した担当者検索処理に対応する。即ち、このフローチャートの処理は、ワークフローサーバ１０１のＣＰＵ１０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２にロードして実行することにより実現される。

まず、担当者判定部３０３は、担当者の部門識別情報と、担当者のロール識別情報と、組織のバージョン番号とが与えられており、ステップＳ１４０１では、担当者判定部３０３は、ユーザポジション情報格納部３１５に格納されているユーザポジション情報を参照し、前記担当者の部門識別情報が部門ＩＤ９０２と一致することと、前記担当者のロール識別情報がロールＩＤ９０３と一致することと、組織のバージョン番号が開始バージョン番号９０５以上であることと、組織のバージョン番号が終了バージョン番号９０６未満であることとを全て満たすユーザポジション情報を検索し、ステップＳ１４０２へ処理を進める。

ステップＳ１４０２では、担当者判定部３０３は、ステップＳ１４０１で少なくとも１つの該当ユーザポジション情報が検索されたかどうか判定する。

そして、ステップＳ１４０２において、ステップＳ１４０１で１つの該当ユーザポジション情報も存在しなかったと判定した場合には（Ｎｏ）、担当者判定部３０３は、ステップＳ１４０３へ処理を進める。

ステップＳ１４０３では、担当者判定部３０３は、部門情報格納部３１３に格納されている部門情報を参照し、前記担当者の部門識別情報と部門ＩＤ７０１が一致することと、組織のバージョン番号が開始バージョン番号７０４あることと、組織のバージョン番号が終了バージョン番号７０５あることと、を全て満たすユーザポジション情報を検索し、その部門情報の項目である親部門ＩＤ７０３の部門識別情報の値で前記担当者の部門識別情報を書き換え、ステップ１４０１へ処理を戻す。

一方、ステップＳ１４０２において、ステップＳ１４０１ですくなくとも１つの該当ユーザポジション情報が検索された（存在した）と判定した場合には（Ｙｅｓ）、担当者判定部３０３は、ステップＳ１４０４へ処理を進める。

ステップ１４０４では、担当者判定部３０３は、ステップ１４０１で検索された少なくとも１つのユーザポジション情報を担当者検索処理の結果として、呼出元（図１３の処理）に返し、本フローチャートの処理を終了する。

以上、図１４に示すような処理を行うことによって、アクティビティに定義された部門識別情報およびロール識別情報を元に、特にその部門に該当ロールのユーザポジションが存在しない場合は、部門階層を上位へ登りながら、該当するユーザポジションを検索することが可能である。

以下、図１５を参照して、図１０のステップＳ４０４に示した要求待ち処理について説明する。

図１５は、本発明における第６の制御処理手順の一例を示すフローチャートであり、図１０のステップＳ４０４に示した要求待ち処理に対応する。即ち、このフローチャートの処理は、ワークフローサーバ１０１のＣＰＵ１０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２にロードして実行することにより実現される。

図１５に示すように、入出力処理部３０１は、ステップＳ１５０１において、ワークフローサーバ１０１の入力コントローラ２０５または通信Ｉ／Ｆコントローラ２０８から何らかの入力情報の入力を待機し、入力を受け取ると、ステップＳ１５０２に処理を進める。

続いてステップＳ１５０２において、入出力処理部３０１は、その入力が「ワークフロー実行要求」であるか否かを判定する。

そして、ステップＳ１５０２において、入力が「ワークフロー実行要求」でない（即ち「組織登録要求」もしくは「その他のワークフローサーバ１０１が対応する要求」）と判定した場合には、入出力処理部３０１は、図示しないステップにおいて、該要求を処理して、ステップＳ１５０１に処理を戻す。

一方、ステップＳ１５０２において、入力が「ワークフロー実行要求」と判定した場合には、入出力処理部３０１は、本フローチャートの処理を終了する。

以下、図１６を参照して、図１０のステップＳ４０７に示したワークアイテム承認処理について説明する。

図１６は、本発明における第７の制御処理手順の一例を示すフローチャートであり、図１０のステップＳ４０７に示したワークアイテム承認処理に対応する。即ち、このフローチャートの処理は、ワークフローサーバ１０１のＣＰＵ１０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２にロードして実行することにより実現される。

図１６に示すように、まずステップ１６０１において、ワークフロー進行部３０２は、入出力処理部３０１が受け付けたワークアイテム承認要求を取得し、ステップＳ１６０２へ処理を進める。

ステップＳ１６０２では、Ｓ１６０１で取得したワークアイテム承認要求が、そのアクティビティを「承認」するものなのか、それともそのアクティビティを否認して「差戻」するものなのかの判定を行う。この判定は、前記ワークアイテム承認要求に含まれるフラグなどを参照することなどで行う。

ステップＳ１６０２において、Ｓ１６０１で取得したワークアイテム承認要求がそのアクティビティを「承認」するものであると判定した場合には、ワークフロー進行部３０２は、ステップＳ１６０３に処理を進める。

ステップＳ１６０３では、ワークフロー進行部３０２は、ジョブ情報格納部３１１に格納されているジョブ情報を参照し、現在の遷移先アクティビティの情報を取得し、プロセス定義情報格納部３１０に格納されているプロセス定義情報を参照し、現在の遷移先アクティビティの次のアクティビティ情報を取得し、前記次のアクティビティをあらたに遷移先アクティビティに設定し、ジョブ情報格納部３１１にジョブ情報を格納し、本ワークアイテム承認処理を終了する。

一方、ステップＳ１６０２において、Ｓ１６０１で取得したワークアイテム承認要求がそのアクティビティを否認して「差戻」するものであると判定した場合には、ワークフロー進行部３０２は、ステップＳ１６０４に処理を進める。

ステップ１６０４において、ワークフロー進行部３０２は、ジョブ情報格納部３１１に格納されているジョブ情報を参照し、現在の遷移先アクティビティの情報を取得し、プロセス定義情報格納部３１０に格納されているプロセス定義情報を参照し、現在の遷移先アクティビティの少なくとも一つ以上手前のアクティビティ情報を取得し、前記次のアクティビティをあらたに遷移先アクティビティに設定し、ジョブ情報格納部３１１にジョブ情報を格納し、本ワークアイテム承認処理を終了する。

以上、図１６に示すような処理を行うことによって、ワークアイテム承認要求毎に、遷移先のアクティビティを決定し、次の担当者にワークフローを進行することが可能になる。

以下、図１７を参照して、図１０のステップＳ４０８に示した組織付替処理について説明する。

図１７は、本発明における第８の制御処理手順の一例を示すフローチャートであり、図１０のステップＳ４０８に示した組織付替処理に対応する。即ち、このフローチャートの処理は、ワークフローサーバ１０１のＣＰＵ１０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２にロードして実行することにより実現される。

図１７に示すように、組織付替部３０５は、ステップＳ１７０１において、入出力処理部３０１を経由して付替え対象のジョブと、付替える組織のバージョンの指定とを受け付け、Ｓ１７０２のバージョン再確定処理へ処理を進める。

ステップＳ１７０２のバージョン再確定処理では、組織付替部３０５は、前記付替る組織のバージョンの指定を伴って、担当者判定部３０３に、付替える組織のバージョン番号の再確定処理を依頼し、確定した組織のバージョン番号を受け取り、ステップＳ１７０３へ処理を進める。なお、バージョン番号の再確定処理の詳細については前述の図１２で示したとおりである。

次に、ステップＳ１７０３において、組織付替部３０５は、ジョブ情報格納部３１１に格納されているジョブ情報を参照し、前記付替え対象のジョブが現在参照している組織のバージョン番号を取得し、Ｓ１７０４の担当者検索処理へ処理を進める。

ステップＳ１７０４の担当者検索処理では、組織付替部３０５は、ステップＳ１７０３で参照したジョブ情報より、現在の遷移先アクティビティの担当部門識別情報と、現在の遷移先アクティビティの担当ロール識別情報と、前記ジョブが現在参照している組織のバージョン番号をともなって、担当者判定部３０３に担当者となるユーザポジション情報の検索を依頼し、結果を受け取り、Ｓ１７０５の担当者検索処理へ処理を進める。なお、担当者検索処理の詳細については前述の図１４で示したとおりである。

次に、ステップＳ１７０５の担当者検索処理では、組織付替部３０５は、ステップＳ１７０３で参照したジョブ情報より、現在の遷移先アクティビティの担当部門識別情報と、現在の遷移先アクティビティの担当ロール識別情報と、バージョン確定処理Ｓ１７０２により確定した付替える組織のバージョン番号をともなって、担当者判定部３０３に担当者となるユーザポジション情報の検索を依頼し、結果を受け取り、ステップＳ１７０６へ処理を進める。なお、担当者検索処理の詳細については前述の図１４で示したとおりである。

ステップＳ１７０６では、組織付替部３０５は、Ｓ１７０４で検索したユーザポジション情報とＳ１７０５で検索したユーザポジション情報の比較を行う。

そして、ステップＳ１７０６において、比較の結果、Ｓ１７０４で検索したユーザポジション情報とＳ１７０５で検索したユーザポジション情報の双方に差異がある場合は、組織付替部３０５は、ステップＳ１７０８へ処理を進める。

ステップＳ１７０８においては、組織付替部３０５は、担当者検索処理Ｓ１７０４で検索したユーザポジションを参照し、該当ユーザにメールなどによる通知を行い、ステップＳ１７０９に処理を進める。なお、Ｓ１７０８の通知処理は必須ではない。

ステップＳ１７０９では、組織付替部３０３は、ジョブ情報格納部３１１に格納されている当該ジョブのジョブ情報から割当に関連する情報があれば破棄し、ステップＳ１７１０へ処理を進める。

ステップＳ１７１０では、組織付替部３０３は、前記付替える組織のバージョン番号をジョブ関連情報として、ジョブの他の属性とともにジョブ情報格納部３１１に格納し、Ｓ１７１１の担当者割当処理へ処理を進める。

ステップＳ１７１１の担当者割当処理において、組織付替部３０３は、担当者判定部３０３に担当者割当処理を依頼して、本組織付替え処理を終了する。なお、担当者割当処理の詳細については前述の図１３で示したとおりであるが、ステップＳ１７１０において当該ジョブの参照する組織のバージョンが付替える組織のバージョンに変更済みであるため、担当者割当処理（Ｓ１７１１）の結果は、付替える組織のバージョンにおける担当者となる。

一方、ステップＳ１７０６において、比較の結果、Ｓ１７０４で検索したユーザポジション情報とＳ１７０５で検索したユーザポジション情報の双方が同一の場合は、組織付替部３０５は、ステップＳ１７０７へ処理を進める。

ステップＳ１７０７では、組織付替部３０５は、付替える組織のバージョン番号をジョブ関連情報として、ジョブの他の属性とともにジョブ情報格納部３１１に格納して、本組織付替え処理を終了する。なお、ステップＳ１７０７では、ステップＳ１７１０と同様の処理を行うが、担当者割当処理の依頼は行わない。なぜなら、ステップ１７０６の判定の結果担当者に変更がないことが判明しているからである。

なお、ステップＳ１７０２で再確定されたバージョン番号とステップＳ１７０２で取得したジョブに関連づいたバージョン識別情報（即ち、再確定前のバージョン識別情報）とが一致する場合には、ステップＳ１７０４以降の処理を実行せず、そのまま本組織付替処理を終了するように構成してもよい。

以上、図１７に示すような処理を行うことによって、特定のジョブを指定してその組織のバージョンを付替えることが可能であり、その際に、担当者の変更がない場合には不要なユーザへの通知や、再割当処理や、それにともなう承認の遣り直しなどの発生を抑制することが可能となる。

以上のような形態をそなえることによって、たとえば、あるユーザが同一部門に所属している間に上司にあたる課長が替わっている場合であっても、申請時に確定したジョブが関連する組織バージョンに基づいて、そのバージョンの組織における課長が承認すべきであることを、自動的に判断して、承認すべき課長に通知を行うことができる。

また、以上のような形態をそなえることによって、あるジョブが参照する組織のバージョンが特定されているため、将来の組織のバージョンをあらかじめ登録しておき、現在のジョブは前記組織のバージョンは参照しないものの、その将来となった時点以降のジョブは前記組織のバージョンを参照する、といった運用が可能となり、組織の切替に起因するシステム停止を行う必要がないために、ワークフローシステムの可用性の向上に役立つ。

また、以上のような形態をそなえることによって、業務の種類などに応じて参照する組織のバージョンを切り替えたり、進行中のジョブであっても組織のバージョンを付替えることが可能であるので、個別のワークフローの進行のみ現組織での運用を行いたい場合などでも対応でき、柔軟なワークフローの進行を行うことができることとなる。

通常企業において、人事情報はその時点でのスナップショットの情報であり、以前の組織との差分情報がない場合、もしくは差分情報を作成するのが煩雑である場合がおおい。

本発明において、組織情報は、図６および図７および図８に示すように、それぞれの組織要素が存続したバージョンの番号の範囲で構成されているため、その編集のためには、直前の組織との差分の情報、すなわち追加情報と、変更情報と、削除情報とが必要となる。

しかし、前述の通り多くの企業において差分情報を保持しておらず、その作成も煩雑であるため、一旦、組織要素全体を削除したのち、現在存在する要素をすべて追加するという手法をとることも多い。

ただし、この手法をとると図１８に示すように、存在しつづける組織要素についてもバージョン毎に一旦削除された状態となるので、組織情報のデータ量が非常に増大してしまうという問題点があった。

図１８は、従来の組織登録時の問題点を説明するためのイメージ図である。

これを防ぐために、図３に示した組織情報登録部３０４では図１９に示すような組織登録方法を行っている。

以下、図１９を用いて、図３に示した組織情報登録部３０４における組織情報更新処理を説明する。

図１９は、本発明を適用可能なワークフローサーバ１０１における組織情報更新処理の一例を示した図である。

図１９は、本発明における第９の制御処理手順の一例を示すフローチャートであり、図３に示した組織情報登録部３０４等で実行される組織登録処理に対応する。即ち、このフローチャートの処理は、ワークフローサーバ１０１のＣＰＵ１０１が外部メモリ２１１に格納されるプログラム２１２をＲＡＭ２０２にロードして実行することにより実現される。

図１９に示すように、入出力処理部３０１が、ステップＳ２００１において、ワークフローサーバ１０１の入力コントローラ２０５または通信Ｉ／Ｆコントローラ２０８から組織編集（更新）コマンドの入力を待機し、該入力を受け取ると、ステップＳ２００２に処理を進める。なお、組織編集コマンドは、項目として、コマンド種別と、要素データとを含む。コマンド種別には、「クリア」、「追加」、「変更」、「削除」等があり、要素データにはそれぞれのコマンドに対応した要素の識別情報などのデータが含まれる。なお、組織編集コマンドは、複数のコマンドをまとめで入力することも可能である。その場合には、組織登録部３０５は、ステップＳ２００２〜Ｓ２０１３の処理を組織編集コマンドの分だけ繰り返す。即ち、ステップＳ２００２〜Ｓ２０１３の処理を各組織編集コマンドに対して実行する。

ステップＳ２００３では、組織登録部３０５は、処理対象の組織編集コマンドの前記コマンド種別が「クリア」であるかどうかを判定し、「クリア」であると判定した場合には（Ｙｅｓ）、ステップＳ２００４に処理を進める。

ステップＳ２００４では、組織登録部３０５は、例えば部門情報格納部３１３から１つ前のバージョンにおいて存在している要素を、すなわち終了バージョン番号が「ＨＶ」のものを全て取得し、ステップＳ２００５に処理を進める。

ステップＳ２００５では、組織登録部３０５は、ステップＳ２００４で取得した要素の終了バージョンに、現バージョンを設定し、例えば部門情報格納部３１３に格納し、ステップＳ２０１３へ処理を進める。なお、ステップＳ２００５の処理により、全ての要素が一旦現バージョンにおいて削除された状態となる。

一方、ステップＳ２００３において、処理対象の組織編集コマンドの前記コマンド種別が「クリア」でないと判定した場合には（Ｎｏ）、ステップＳ２００６に処理を進める。

ステップ２００６では、組織登録部３０５は、前記組織編集コマンドの要素データに含まれる、識別情報により、例えば部門情報格納部３１３から該当要素の情報を取得し、ステップＳ２００７に処理を進める。

ステップＳ２００７では、組織登録部３０５は、処理対象の組織編集コマンドのコマンド種別を判定する。

ステップＳ２００７において、前記コマンド種別が「削除」であると判定した場合には、組織登録部３０５は、ステップＳ２０１２に処理を進める。

ステップＳ２０１２では、組織登録部３０５は、ステップＳ２００６で取得した該当要素の終了バージョン番号に、現バージョンを設定し、例えば部門情報格納部３１３に格納し、ステップＳ２０１３へ処理を進める。この処理により、識別情報で指定された要素の情報は、現バージョンにおいて削除された状態となる。

また、ステップＳ２００７において、前記コマンド種別が「変更」であると判定した場合には、組織登録部３０５は、ステップＳ２０１１に処理を進める。

ステップＳ２０１１では、組織登録部３０５は、ステップＳ２００６で取得した該当要素の終了バージョン番号に、現バージョンを設定し、例えば部門情報格納部３１３に格納し、ステップＳ２０１０へ処理を進める。

ステップＳ２０１０では、前記処理対象の組織編集コマンドの要素データにより、新たな要素を作成し、その開始バージョン番号（開始情報）を現バージョンに設定し、その終了バージョン（終了情報）を「ＨＶ」に設定し、例えば部門情報格納部３１３に該当要素の情報を追加し、ステップＳ２０１３へ処理を進める。このステップＳ２０１１およびステップＳ２０１０の処理により、前記組織編集コマンドの要素データに含まれる、識別情報で識別される組織要素は、現バージョンにおいて変更されたことになる。

また、ステップＳ２００７において、前記コマンド種別が「追加」であると判定した場合には、組織登録部３０５は、ステップＳ２００８に処理を進める。

ステップＳ２００８では、組織登録部３０５は、ステップＳ２００６で取得した該当要素の終了バージョン番号に設定されているバージョン番号と現バージョンのバージョン番号が等しいか否か判定する。

そして、ステップＳ２００８において、ステップＳ２００６で取得した該当要素の終了バージョン番号に設定されているバージョン番号と現バージョンのバージョン番号が等しくない判定した場合には（Ｎｏ）、組織登録部３０５は、ステップＳ２０１０を実行し、ステップＳ２０１３へ処理を進める。このステップＳ２００８およびステップＳ２０１０の処理により、前記組織編集コマンドの要素データに含まれる、識別情報で識別される組織要素が、現バージョンにおいて追加されたことになる。

一方、ステップＳ２００８において、ステップＳ２００６で取得した該当要素の終了バージョン番号に設定されているバージョン番号と現バージョンのバージョン番号が等しい判定した場合には（Ｙｅｓ）、組織登録部３０５は、ステップＳ２００９へ処理を進める。

ステップＳ２００９においては、ステップＳ２００６で取得した該当要素の終了バージョン番号に設定されているバージョン番号を「ＨＶ」に変更して設定し、例えば部門情報格納部３１３に格納し、ステップＳ２０１３へ処理を進める。このステップＳ２００８およびステップＳ２００９の処理により、前記組織編集コマンドの要素データに含まれる、識別情報で識別される組織要素が、以前のバージョンから継続していたことになる。

そして、ステップＳ２０１３では、組織登録部３０５は、未だ入力された全てのコマンドに対してステップＳ２００２〜Ｓ２０１３の処理を終了していないと判定した場合には、処理対象を次のコマンドの移し、ステップＳ２００２に処理を戻す。

一方、ステップＳ２０１３では、組織登録部３０５は、入力された全てのコマンドに対してステップＳ２００２〜Ｓ２０１３の処理を終了したと判定した場合には、本組織編集処理を終了する。

なお、ここでは、例として部門情報格納部３１３の登録処理をあげたが、他の情報の登録処理でも同様である。なお、部門情報の登録時には部門情報登録部３１２が格納先であり、ロール情報の登録時にはロール情報格納部３１４が格納先であり、ユーザポジション情報の登録時にはユーザポジション情報３１４が格納先となることはいうまでもない。

以上、図１９のような処理を行うことにより、一旦クリアをしてから全体を追加するような手法で組織の登録を行ったとしても、図１８のように細切れになることによるデータ量の増大を抑制し、図２０のような連続した組織要素として管理することが可能となる。即ち、差分を考慮しないバッチ処理による編集を行っても、ステップＳ２００８，Ｓ２００９の処理において、コマンドに該当する要素の終了バージョン番号に設定されているバージョン番号と現バージョンのバージョン番号が等しい場合には、前記コマンドに該当する要素の終了バージョン番号に設定されているバージョン番号を「ＨＶ」に変更して設定することにより、データレコード数が膨大になってしまうといった事態（図１８）の発生を抑制することができる（図２０）。

図２０は、本発明の組織登録処理における組織登録時のイメージ図である。

以上示したように、本発明によれば、ワークフローに使用する組織情報を複数のバージョン登録することができ、ワークフローは開始時に指定したバージョンの組織に従って進行、即ち指定されたバージョンの組織における各担当者の決定が行われるため、例えば月初めに組織変更がなされても、前月分の清算処理と今月分の申請処理等を同時に矛盾なく処理することができる。即ち、ワークフロー開始時の組織情報のスナップショットに従ってジョブを進行させ、組織変更の影響を受けないようにすることができる。

また、ワークフローの状態に関わらず将来の組織情報を登録することができる。また、有効化を行うまで使用しないことができる。

また、旧バージョンの組織で進行中のワークフローでも、途中で現バージョンの組織での運用に切り替えることができる。そして、このような切替のために発生しうる合議のやり直しを抑制することができる。

また、複数のバージョンの組織を管理するが、変更がない部分のデータを効率よく管理することにより、データレコード数を抑えることができる。また、差分を考慮しないバッチ処理による編集を行ってもデータレコード数が膨大になってしまうといった事態の発生を抑制することができる。

従って、新旧を含む複数のバージョンの組織で進行するワークフローを共存させ、矛盾なく処理することができる等の効果を奏する。即ち、旧組織で進行するワークフローと、新組織で進行するワークフローとを矛盾なく共存させることができる。さらに、旧組織で進行するワークフローを新組織で進行するように変更させることもできる。

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

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

以下、図２１に示すメモリマップを参照して本発明に係るワークフローサーバで読み取り可能なデータ処理プログラムの構成について説明する。

図２１は、本発明に係るワークフローサーバで読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。

なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図１０，図１１，図１２，図１３，図１４，図１５，図１６，図１７，図１９に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

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

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

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

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

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

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

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

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

図１は、本発明の一実施形態を適用可能なワークフローシステムの一例を示す図である。 図１に示した本発明に適応可能な情報処理装置としてのワークフローサーバ１０１とワークフロークライアント１０２のハードウェア構成の一例を示すブロック図である。 図１に示したワークフローサーバ１０１において実現される機能構成の一例を示す図である。 図３に示したプロセス定義情報格納部３１０に格納されるプロセス定義情報の一例を示す図である。 本実施形態の説明に用いる組織の一例を示す図である。 図３に示した部門情報格納部３１３に格納されている部門情報の一例を示す図である。 図３に示したロール情報格納部３１４に格納されているロール情報の一例を示す図である。 図３に示したユーザポジション情報格納部３１５に格納されているユーザポジション情報の一例を示す図である。 図３に示したバージョン有効期間情報格納部３１２に格納されるバージョン有効期間情報の一例を示す図である。 本発明における第１の制御処理手順の一例を示すフローチャートである。 本発明における第２の制御処理手順の一例を示すフローチャートである。 本発明における第３の制御処理手順の一例を示すフローチャートである。 本発明における第４の制御処理手順の一例を示すフローチャートである。 本発明における第５の制御処理手順の一例を示すフローチャートである。 本発明における第６の制御処理手順の一例を示すフローチャートである。 本発明における第７の制御処理手順の一例を示すフローチャートである。 本発明における第８の制御処理手順の一例を示すフローチャートである。 従来の組織登録時の問題点を説明するためのイメージ図である。 本発明における第９の制御処理手順の一例を示すフローチャートである。 本発明の組織登録処理における組織登録時のイメージ図である。 本発明に係るワークフローサーバで読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。

符号の説明

１００ ネットワーク
１０１ ワークフローサーバ
１０２ ワークフロークライアント
２０１ ＣＰＵ
２０２ ＲＡＭ
２１１ 外部メモリ
２１２ プログラム
３０１ 入出力処理部
３０２ ワークフロー進行部
３０３ 担当者判定部
３０４ 組織情報登録部
３０５ 組織付替部
３１０ プロセス定義情報格納部
３１１ ジョブ情報格納部
３１３ 部門情報格納部
３１４ ロール情報格納部
３１５ ユーザポジション情報格納部
３１２ バージョン有効期間情報格納部３１２

Claims (9)

1. 遷移経路が組織情報により定義されたジョブのワークフローを制御する情報処理装置であって、
   前記組織情報を構成する要素毎に当該要素の有効となる期間の開始を示すバージョンを特定可能な開始バージョン識別情報および期間の終了を示すバージョンを特定可能な終了バージョン識別情報を記憶する組織情報格納手段と、
   前記バージョン毎の有効となる期間を特定する日時情報を記憶するバージョン有効期間格納手段と、
   前記ジョブの遷移先を決定する際に参照する前記組織情報のバージョンとして、指定されたバージョン識別情報、又は、指定された日時と前記バージョン有効期間格納手段に格納された日時情報から確定されるバージョンを該ジョブの関連情報として設定する設定手段と、
   前記遷移経路を定義する組織情報および前記ジョブの関連情報として設定された前記組織情報のバージョンに応じて、該ジョブの遷移先を決定し、該決定された遷移先にジョブを遷移させてワークフローを進行させるワークフロー進行手段と、
   前記組織情報の更新指示を受付けた際に前記要素の更新種別を判別する要素更新判別手段と、
   前記要素更新判別手段による判別結果に応じて前記組織情報格納手段に格納された開始バージョン識別情報または終了バージョン識別情報を更新する組織情報更新手段と、
   を有することを特徴とする情報処理装置。
2. 前記要素更新判別手段により要素が変更されたと判別された場合、
   前記組織情報更新手段は、前記組織情報格納手段に格納された現在の要素の終了バージョン識別情報を現在のバージョンに、かつ変更後の要素を作成するとともに該要素の開始バージョン識別情報を現在のバージョンにかつ該要素の終了バージョン識別情報を終了バージョンがないことを示す情報に更新することを特徴とする請求項１記載の情報処理装置。
3. 前記要素更新判別手段により要素が追加されたと判別された場合、
   前記組織情報更新手段は、前記追加された要素を作成するとともに該要素の開始バージョン識別情報を現在のバージョンにかつ該要素の終了バージョン識別情報を終了バージョンがないことを示す情報に更新することを特徴とする請求項１または２記載の情報処理装置。
4. 前記要素更新判別手段により要素が削除されたと判別された場合、
   前記組織情報更新手段は、前記削除された要素の終了バージョン識別情報を現在のバージョンに更新することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記設定手段により前記ジョブの関連情報として設定された前記組織情報のバージョンの変更指示を受付けた場合に、該指示された組織情報のバージョンを前記ジョブの関連情報として再設定する再設定手段と、
   前記再設定手段により再設定されたバージョンに応じて前記組織情報を構成する要素の開始バージョン識別情報および終了バージョン識別情報を参照して前記ジョブの遷移先を変更する組織付替手段を更に有し、
   該組織付替手段は、前記再設定手段により再設定されたバージョンに基づくジョブの遷移先と前記再設定前のバージョンに基づくジョブの遷移先とが一致する場合には、前記ジョブの遷移先は変更しない、ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記組織情報は、部門を示す部門情報、役割を示すロール情報およびユーザを示すユーザポジション情報を含むことを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 遷移経路が組織情報により定義されたジョブのワークフローを制御する情報処理装置の制御方法であって、
   組織情報登録手段が、組織情報を構成する要素毎に当該要素の有効となる期間の開始を示すバージョンを特定可能な開始バージョン識別情報および期間の終了を示すバージョンを特定可能な終了バージョン識別情報を組織情報格納手段に登録する組織情報登録ステップと、
   バージョン有効期間登録手段が、前記バージョン毎の有効となる期間を特定する日時情報をバージョン有効期間格納手段に登録するバージョン有効期間登録ステップと、
   設定手段が、前記ジョブの遷移先を決定する際に参照する前記組織情報のバージョンとして、指定されたバージョン識別情報、又は、指定された日時と前記バージョン有効期間格納手段に格納された日時情報から確定されるバージョンを該ジョブの関連情報として設定する設定ステップと、
   ワークフロー進行手段が、前記遷移経路を定義する組織情報および前記ジョブの関連情報として設定された前記組織情報のバージョンに応じて、該ジョブの遷移先を決定し、該決定された遷移先にジョブを遷移させてワークフローを進行させるワークフロー進行ステップと、
   要素更新判別手段が、前記組織情報の更新指示を受付けた際に前記要素の更新種別を判別する要素更新判別ステップと、
   組織情報更新手段が、前記要素更新判別ステップによる判別結果に応じて前記組織情報格納手段に格納された開始バージョン識別情報または終了バージョン識別情報を更新する組織情報更新ステップと、
   を有することを特徴とする情報処理装置の制御方法。
8. 遷移経路が組織情報により定義されたジョブのワークフローを制御するコンピュータを、
   前記組織情報を構成する要素毎に当該要素の有効となる期間の開始を示すバージョンを特定可能な開始バージョン識別情報および期間の終了を示すバージョンを特定可能な終了バージョン識別情報を記憶する組織情報格納手段と、
   前記バージョン毎の有効となる期間を特定する日時情報を記憶するバージョン有効期間格納手段と、
   前記ジョブの遷移先を決定する際に参照する前記組織情報のバージョンとして、指定されたバージョン識別情報、又は、指定された日時と前記バージョン有効期間格納手段に格納された日時情報から確定されるバージョンを該ジョブの関連情報として設定する設定手段と、
   前記遷移経路を定義する組織情報および前記ジョブの関連情報として設定された前記組織情報のバージョンに応じて、該ジョブの遷移先を決定し、該決定された遷移先にジョブを遷移させてワークフローを進行させるワークフロー進行手段と、
   前記組織情報の更新指示を受付けた際に前記要素の更新種別を判別する要素更新判別手段と、
   前記要素更新判別手段による判別結果に応じて前記組織情報格納手段に格納された開始バージョン識別情報または終了バージョン識別情報を更新する組織情報更新手段として機能させるためのプログラム。
9. 遷移経路が組織情報により定義されたジョブのワークフローを制御するコンピュータを、
   前記組織情報を構成する要素毎に当該要素の有効となる期間の開始を示すバージョンを特定可能な開始バージョン識別情報および期間の終了を示すバージョンを特定可能な終了バージョン識別情報を記憶する組織情報格納手段と、
   前記バージョン毎の有効となる期間を特定する日時情報を記憶するバージョン有効期間格納手段と、
   前記ジョブの遷移先を決定する際に参照する前記組織情報のバージョンとして、指定されたバージョン識別情報、又は、指定された日時と前記バージョン有効期間格納手段に格納された日時情報から確定されるバージョンを該ジョブの関連情報として設定する設定手段と、
   前記遷移経路を定義する組織情報および前記ジョブの関連情報として設定された前記組織情報のバージョンに応じて、該ジョブの遷移先を決定し、該決定された遷移先にジョブを遷移させてワークフローを進行させるワークフロー進行手段と、
   前記組織情報の更新指示を受付けた際に前記要素の更新種別を判別する要素更新判別手段と、
   前記要素更新判別手段による判別結果に応じて前記組織情報格納手段に格納された開始バージョン識別情報または終了バージョン識別情報を更新する組織情報更新手段として機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images