(57)【要約】      （修正有）【課題】プロセス定義を変更することなく、案件データを適切な処理担当者に配送することが可能な仕組みを提供する。【解決手段】案件の処理フローを決定するプロセス定義の処理担当者を設定するアクティビティにおいて、処理担当者の所属部門を識別子で指定する。アクティビティが識別子で指定された箇所へ案件の処理依頼が来た時は、識別子に紐付く部門ＩＤを参照することにより、案件の処理担当者を決定する。組織変更が行われた場合は、案件の処理が組織変更後の組織で行われるようにするため、識別子に紐付く部門ＩＤも組織変更後の部門ＩＤによって更新する。また、案件の、あるアクティビティにおいて申請部門ごとに処理担当者を部門単位で変更したい場合、識別子でその部門ＩＤを複数管理して、申請部門ごとに適切な部門へ案件の処理依頼をかける。【選択図】図８
2015228141.tif 000002
【特許請求の範囲】
【請求項１】
案件をプロセス定義の処理単位に設定された処理担当者指定に基づき配送を行うワークフローシステムにおいて、
異なる処理担当者指定を行うことによって配送先を異なるようにする前記案件の処理単位に対し、処理担当者指定をまとめて行うことを可能とする配送先管理手段と、
配送先管理手段によってまとめた処理担当者指定を識別子で管理する識別子管理手段と、
前記異なる処理担当者指定が行われる前記処理単位を前記識別子管理手段で管理される前記識別子で処理担当者指定を行う配送先指定手段と、
前記配送先指定手段により前記処理単位に設定された識別子により、前記案件の処理担当者を、異なる処理担当者指定に該当する処理担当者に決定する処理担当者決定手段
を備えることを特徴とするワークフローシステム。
【請求項２】
前記異なる処理担当者指定とは、申請部門ごとに異なる処理担当者指定を行う、あるいは、組織変更が行われた後、組織変更前とは異なる組織変更後の新しい組織の情報を基に新たに処理担当者指定を行うことであること
を特徴とする請求項１に記載のワークフローシステム。
【請求項３】
前記識別子は、前記案件の配送先の部門ＩＤを管理するものであることを特徴とする請求項１または２に記載のワークフローシステム。
【請求項４】
前記処理担当者決定手段は、前記識別子で特定した配送先の部門ＩＤと役割ＩＤによって、前記案件の処理担当者を決定することを特徴とする請求項３に記載のワークフローシステム。
【請求項５】
前記識別子によって管理される配送先の部門ＩＤは、単数または、複数であることを特徴とする請求項３または４に記載のワークフローシステム。
【請求項６】
前記識別子によって管理される配送先の部門が複数である場合、前記案件が申請された部門ＩＤと、前記識別子によって管理される配送先の前記部門との関係において、共通する階層数が多い部門ＩＤを、識別子によって決定する前記案件の処理担当者が所属する部門ＩＤとして指定することを特徴とする請求項３乃至５のいずれか１項に記載のワークフローシステム。
【請求項７】
前記識別子によって管理される配送先の部門が複数であり、前記案件が申請された部門ＩＤと、前記識別子によって管理される配送先の前記部門との関係において、共通する階層数が多い部門ＩＤが複数ある場合、前記部門ＩＤの中より、前記申請された部門ＩＤとの関係において距離が近い部門ＩＤを、識別子によって決定する前記案件の処理担当者が所属する部門ＩＤとして指定することを特徴とする請求項３乃至６のいずれか１項に記載のワークフローシステム。
【請求項８】
前記ワークフローシステムの処理が行われる組織において組織変更に対応するべく、前記識別子によって管理される配送先の部門を前記組織変更が行われた後の部門に変更することで、前記案件の処理待ちとなっている処理単位の処理担当者が識別子で設定されている場合、前記案件を前記組織変更が行われた後の組織における処理担当者を割り当て、前記案件の処理を進めることを可能とすること
を特徴とする請求項１乃至７のいずれか１項に記載のワークフローシステム。
【請求項９】
案件をプロセス定義の処理単位に設定された処理担当者指定に基づき配送を行うワークフローシステムの制御方法において、
配送先管理手段が、異なる処理担当者指定を行うことによって配送先を異なるようにする前記案件の処理単位に対し、処理担当者指定をまとめて行うことを可能とする配送先管理ステップと、
識別子管理手段が、配送先管理ステップによってまとめた処理担当者指定を識別子で管理する識別子管理ステップと、
配送先指定手段が、前記異なる処理担当者指定が行われる前記処理単位を前記識別子管理ステップで管理される前記識別子で処理担当者指定を行う配送先指定ステップと、
処理担当者決定手段が、前記配送先指定ステップにより前記処理単位に設定された識別子により、前記案件の処理担当者を、異なる処理担当者指定に該当する処理担当者に決定する処理担当者決定ステップ
を含むことを特徴とするワークフローシステムの制御方法。
【請求項１０】
案件をプロセス定義の処理単位に設定された処理担当者指定に基づき配送を行うワークフローシステムにおいて実行されるプログラムあって、
異なる処理担当者指定を行うことによって配送先を異なるようにする前記案件の処理単位に対し、処理担当者指定をまとめて行うことを可能とする配送先管理手段と、
配送先管理手段によってまとめた処理担当者指定を識別子で管理する識別子管理手段と、
前記異なる処理担当者指定が行われる前記処理単位を前記識別子管理手段で管理される前記識別子で処理担当者指定を行う配送先指定手段と、
前記配送先指定手段により前記処理単位に設定された識別子により、前記案件の処理担当者を、異なる処理担当者指定に該当する処理担当者に決定する処理担当者決定手段
として機能させることを特徴とするワークフローシステムのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、組織変更発生時に新組織上で適切な処理担当者を決定するワークフロー制御に関する。
【背景技術】
【０００２】
組織情報を世代管理可能で、案件を配送するためのプロセス定義を組織情報（部門、役割、ユーザ）によって定義するワークフローシステムでは、システムを運用中に組織変更が発生した場合、案件を変更後の新しい組織で、起案時に割り当てたプロセス定義で配送することを行うことがある。この場合、ワークフローシステムにおける処理を、組織変更を行った後の新しい組織で行う運用に切り替えた結果、処理担当者に該当するユーザが組織変更後の組織に存在せず、案件がエラーとなる場合がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１１−３９６２６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
例えば、このような問題を解決するために、特許文献１では、代理の処理担当者を新しい組織において検索して、新しい処理担当者を割り当てられるようにするための再割当ルールを処理担当者ごとに登録しておくことにより、処理担当の解決を図る仕組みが開示されている。
【０００５】
例えば、特許文献１では、「組織変更前と同一の処理担当に割り当てる」「組織変更後に元の処理担当と同一の部門、ロールに着任したユーザに割り当てる」などのルールを指定する。例えば、「組織変更前と同一の処理担当に割り当てる」のルールを割り当てて、処理担当者が組織変更後の新しい組織に存在した場合、組織変更で処理担当者が別部門へ異動した場合であっても、処理担当者にとっては異動後の組織となる、組織変更後の処理担当を割り当てることができる。
【０００６】
しかし、上記、特許文献１の仕組みでは、組織内での機能は同一であっても部門ＩＤが変更された場合など、組織変更後に元の部門と同一部門が存在しないケースでは、新しい組織情報適用時に処理担当者が解決できない。つまり、経路の、ある処理単位の処理担当者を、組織と役割の指定（どこの部門のどの役割をもつ処理担当者という指定）で行っている場合に、起案された案件が、変更前の組織の部門ＩＤで作成された経路定義で配送されることになっていて、かつ、変更後の新しい組織で配送を行う場合、組織変更を行う前の部門ＩＤで定義された配送先で、新しい組織において案件を配送することは部門ＩＤ自体がそもそも存在しないため不可能となるということである。
【０００７】
例えば、申請者の所属部門から組織階層を元に判断される「上長承認」等では新しい組織情報にて上長を割当可能であるが、「人事処理」といった特定部門が定義されている場合、処理プロセスの定義情報の中にこの「人事部門」という特定部門の部門ＩＤを指定することになる。この「人事部門」の部門ＩＤを組織情報において変更すると、案件起案時の経路設定で次の処理担当者となる配送先として指定していた組織変更前の部門ＩＤが組織変更後の部門ＩＤに存在しないため、配送処理においては処理担当者が解決できずエラーとなる。このようなケースの場合、滞留した伝票については、新しい組織で配送できるように対応を行わなくてはならない処理が発生するのと、また、組織変更後に起案された案件が配送できるようにするための、経路設定を用意しなくてはならないという処理が発生する。
【０００８】
さらに、同じプロセス定義に対して、メインテナンスを行わなくてはならないケースというのは、組織変更ときのみに発生する問題ではない。例えば、同じ役割を持つ部門が複数あり、その部門を経路のある同じ機能を持つ処理単位において、申請部門によって処理を担当する部門を変更したい場合、例えば、「経理部門」として「本社経理」「支店経理」という２つの部門が存在し、申請部門によって処理を担当する部門を切り替えたい場合、「経理処理」という特定部門が定義された処理プロセスにおいて、申請部門毎に処理を担当すべき「経理部門」を指定する必要がある。
【０００９】
これらのケースにより、経路上の処理単位に指定されている処理担当者の所属する部門の部門ＩＤが変更される組織変更があった場合、あるいは、申請部門ごとに経路上の処理担当者を切り替えたい場合に、プロセス定義を変更する手間をかけることなく、案件データを適切な処理担当者に配送することを行えるようにすることが望まれる。
【００１０】
そこで、本発明ではこれらの点を鑑み、プロセス定義を変更することなく、案件データを適切な処理担当者に配送することが可能な仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、案件をプロセス定義の処理単位に設定された処理担当者指定に基づき配送を行うワークフローシステムにおいて、異なる処理担当者指定を行うことによって配送先を異なるようにする前記案件の処理単位に対し、処理担当者指定をまとめて行うことを可能とする配送先管理手段と、配送先管理手段によってまとめた処理担当者指定を識別子で管理する識別子管理手段と、前記異なる処理担当者指定が行われる前記処理単位を前記識別子管理手段で管理される前記識別子で処理担当者指定を行う配送先指定手段と、前記配送先指定手段により前記処理単位に設定された識別子により、前記案件の処理担当者を、異なる処理担当者指定に該当する処理担当者に決定する処理担当者決定手段を備えることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、プロセス定義を変更することなく、案件データを適切な処理担当者に配送することが可能な仕組みを提供することが可能となる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態におけるワークフローシステムの構成の一例を示す図である。
【図２】本発明の実施形態における各種端末のハードウェア構成の一例を示す図である。
【図３】本発明の実施形態における機能構成の一例を示す図である。
【図４】本発明の実施形態におけるワークフローを処理する組織の一例を示す図である。
【図５】本発明の実施形態における識別子情報を格納するテーブルの一例を示す図である。
【図６】本発明の実施形態におけるプロセス定義の一例を示す図である。
【図７】本発明の実施形態におけるプロセス定義における各アクティビティに設定されている処理担当を管理するテーブルの一例を示す図である。
【図８】本発明の実施形態のワークフローシステムにおいて、処理担当者を決定する処理の一例を示すフローチャートである。
【図９】本発明の実施形態のワークフローシステムにおいて、指定された組織情報における部門ＩＤ、役割ＩＤを持つユーザを案件の処理担当者として決定する処理の一例を示すフローチャートである。
【図１０】本発明の実施形態のワークフローシステムにおいて、処理担当部門ＩＤの候補が複数候補ある場合に、その中から配送先をとなる部門を１つに決定する部門ＩＤ絞込み処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、図面を参照して、本発明の実施形態を詳細に説明する。図１は、本発明の一実施形態を示すワークフローシステムの全体構成を示すシステム構成図である。
【００１５】
図１に示すように、本実施形態のワークフローシステムは、クライアント１０１、管理端末１０２、ワークフローサーバ１０３、システムデータベース１０４がネットワーク１００を通じて接続されている。
【００１６】
図２は、図１に示したクライアント端末１０１、管理端末１０２、ワークフローサーバ１０３に適用可能な情報処理装置のハードウェア構成の一例を示すブロック図である。
【００１７】
図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。
【００１８】
入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。
【００１９】
出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶ディスプレイ等が挙げられる。
【００２０】
外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザーファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、外部メモリコントローラ２０７には、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。
【００２１】
この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。
通信Ｉ／Ｆコントローラ２０８は、ネットワーク１００を介して外部機器との通信制御処理を実行する。
【００２２】
なお、外部メモリ２１１には、本発明を実現するためのプログラム２１２が記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
【００２３】
また、図１に示したワークフローサーバ１０３のデータベースアクセス制御部１１６は、ワークフローサーバ１０３を構成する情報処理装置のＣＰＵ２０１が外部メモリ２１１に記憶されたプログラムを読み出して実行することにより実現される機能に対応する。
【００２４】
図３は、本発明の一実施形態を示すワークフローシステムにおける機能構成を示す図である。クライアント端末１０１と管理端末１０２はワークフローサーバ１０３を通してシステムデータベース１０４にアクセスする。
【００２５】
クライアント端末１０１は、主に表示部１１１と指示入力部１１２を有しており、指示入力部１１２は、ワークフローサーバ１０３を通してシステムデータベース１０４の案件データ１１８を取得し、表示部１１１へ表示し、および更新の指示を行う。
【００２６】
管理端末１０２は、設定部１１３と更新適用司令部１１４を有する。設定部１１３は、システムや業務の設定を行い、設定された情報はワークフローサーバ１０３を通してシステムデータベース１０４に格納される。
【００２７】
ワークフローサーバ１０３はフロー制御部１１５とデータベースアクセス制御部１１６を有す。データベースアクセス制御部１１６は管理端末１０２およびクライアント端末１０１の指示によりシステムデータベース１０４の入出力を行う。
【００２８】
フロー制御部１１５は、管理端末１０２の更新適用司令部１１４、およびクライアント端末１０１からの指示により、業務情報１１９、プロセス定義１２０、組織情報１２２および識別子情報１２３を参照して案件データ１１８の処理待ち情報の更新を行う。
【００２９】
システムデータベース１０４には、案件データ１１８と、システム全体の設定情報であるシステム定義１２１と、ワークフローで扱う各業務の設計情報である業務情報１１９、業務情報に紐付くプロセス定義１２０、および組織情報１２２と組織情報に紐付く識別子情報１２３を有する。
【００３０】
案件データ１１８には各業務項目のデータや、案件データが承認プロセス上のどのアクティビティのどのユーザの処理待ち状態であるかという処理待ち情報が格納されている。
【００３１】
業務情報１１９には、業務毎の画面の構成情報や、業務別の閲覧権限や委任情報など、業務設計以外の情報が定義されている。また、プロセス定義１２０には、後述する図６、および７で示すような業務別のワークフローの開始から終了までの承認プロセスを定義したデータが格納されている。
【００３２】
システム定義１２１にはワークフローシステム全体における、認証方法や、メール設定など、各種サーバ設定に関する情報が定義されている。
【００３３】
組織情報１２２には、後述する図４で示す組織を定義したデータが格納されている。識別子情報１２３には、プロセス定義１２０にて利用可能な識別子と、組織情報１２２の部門ＩＤを紐づけたデータが格納されている。
【００３４】
図４は、本実施形態の説明に用いる組織の一例を示す図である。組織図（変更前）４０１は、組織変更を行う前の階層形式で図示した組織図である。
【００３５】
なお、図４の組織図（変更前）４０１の４１１から４２０で示している各部門に記載を行っているＡ０００１からＦ００３のコードは、各部門に割り当てられている部門ＩＤを示す。
【００３６】
この組織図（変更前）４０１の組織には、会社４１１（部門ＩＤ：Ａ００１）の配下に本社４１２（部門ＩＤ：Ａ００１Ｂ００１）、Ａ支店４１６（部門ＩＤ：Ａ００１Ｂ００２）とＢ支店４１９（部門ＩＤ：Ａ００１Ｂ００３）が存在し、本社４１２の配下に人事部４１３（部門ＩＤ：Ａ００１Ｂ００１Ｃ００１）、経理部４１４（部門ＩＤ：Ａ００１Ｂ００１Ｄ００１）、営業部４１５（部門ＩＤ：Ａ００１Ｂ００１Ｅ００１）、Ａ支店４１６の配下に経理部４１７（部門ＩＤ：Ａ００１Ｂ００２Ｄ００２）、営業部４１８（部門ＩＤ：Ａ００１Ｂ００２Ｅ００２）、Ｂ支店４１９の配下に開発部４２０（部門ＩＤ：Ａ００１Ｂ００３Ｆ００３）が存在することとする。
【００３７】
また、各部門の横に記載をしている内容（例えば、Ａ００１の横に記載の一般Ａ１２）は、その組織に所属する人に割り当てられる担当役割の名称と担当役割ＩＤを示すこととする。例えば、人事部４１３には担当役割ＩＤがＣ１１で担当役割が部門長のユーザと、担当役割ＩＤがＣ１２の担当役割が一般のユーザが所属していることを示す。営業部４１５には担当役割ＩＤがＥ１１で担当役割が部門長のユーザと、担当役割ＩＤがＥ１２で担当役割が一般のユーザが所属していることになる。
【００３８】
続いて、図４の組織図（変更後）４０２の説明を行う。図４の組織図（変更後）４０２は、図４の組織図（変更前）４０１の組織を変更した後の組織図になる。
【００３９】
なお、組織図（変更前）４０１から変更が行われている点は、組織図（変更後）４０２において、人事部４１３の部門ＩＤが変更されていること（部門ＩＤがＡ００１Ｂ００１Ｃ００１からＡ００１Ｂ００１Ｚ００１へ変更）、Ａ支店４１６に業務部４２１（部門ＩＤ：Ａ００１Ｂ００２Ｇ００２）が新設され、経理部４１７が業務部４２１の配下となっていること（部門ＩＤ：Ａ００１Ｂ００２Ｇ００２Ｄ００２）、Ｂ支店４１９はＡ支店に統合となり、Ｂ支店４１９の配下にあった開発部４２０がＡ支店４１６の配下になっていること（部門ＩＤ：Ａ００１Ｂ００２Ｆ００３）、また、Ｂ支店４１９の所属ユーザはＡ支店４１６の所属となる人事異動が行われていること、になる。
【００４０】
続いて、図５において、図３で示した識別子情報に格納されている識別子情報の一例について説明する。
【００４１】
図５の識別子設定（変更前）５０１と、識別子設定（変更前）５０２は、識別を管理するテーブルであり、組織の変更が行われる前の情報が管理されている状況を示すテーブルが、識別子設定（変更前）５０１であり、組織の変更が行われた後の情報が管理されている状況を示すテーブルが、識別子設定（変更前）５０２である。
【００４２】
なお、識別子とは、後述するプロセス定義の設定において、配送先を指定するために使用するものである。また、本発明の実施例においては、組織が変更されて新しい組織で案件を配送する場合は、識別子設定（変更前）５０１が更新された状態である、識別子設定（変更前）５０２の識別子の情報がプロセスで定義に反映されて配送処理が行われることとする。図５に示すように、識別子設定（変更前）５０１と識別子設定（変更前）５０２は、識別子５１１、識別子名５１２、部門ＩＤ５１３、参照モード５１４からなる。
【００４３】
識別子５１１には識別子を特定するＩＤが設定される。識別子名５１２には前記識別子の名称が設定される。部門ＩＤ５１３は、識別子によって特定する部門ＩＤが設定される。この部門ＩＤは複数設定することが可能である。すなわち、複数まとめた処理担当者指定を識別子で管理する（識別子管理手段）。また、識別子によって管理される配送先の部門ＩＤは、単数または、複数である。なお、本実施例では、複数指定されている場合一番左に登録されている部門ＩＤをデフォルトの組織とすることにする。
【００４４】
また、参照モード５１４は、部門ＩＤが複数設定された場合の担当部門決定ルールが設定されている。設定された複数の部門ＩＤ全てを担当部門として利用する「全部門」、または、設定されている複数部門ＩＤのうち、「申請部門からみて、共通の階層数の値が大きい部門、または、共通の階層数が設定されている部門同士で同じ場合は最小ノード数、でたどり着ける部門」の、条件にあてはまる一部門を処理担当部門として利用する「１部門」の値のどちらかが設定される。
【００４５】
図５の識別子設定（変更前）５０１は組織図（変更前）４０１を基に後述のプロセス定義で使用される識別子情報であり、識別子５１１が「Ａ０１０」で設定されている識別子情報は、部門ＩＤ５１３に、組織図（変更前）４０１の人事部４１３の部門ＩＤ「Ａ００１Ｂ００１Ｃ００１」が設定されている。また、識別子５１１が「Ｂ０１０」で設定されている識別子情報は、部門ＩＤ５１３に、本社４１２配下の経理部４１４の部門ＩＤ「Ａ００１Ｂ００１Ｄ００１」、および、Ａ支店４１６配下の経理部４１７の部門ＩＤ「Ａ００１Ｂ００２Ｄ００２」が設定されている。また、識別子５１１が「Ｂ０２０」で設定されている識別子情報は、部門ＩＤ５１３は、識別子５１１が「Ｂ０２０」と同じ内容が登録されているが、参照モード５１４が全部門となっている識別子情報が登録されている。
【００４６】
図５の識別子設定（変更前）５０２は組織図（変更前）４０２を基に後述のプロセス定義で使用される識別子情報であり、識別子５１１が「Ａ０１０」で設定されている識別子情報は、部門ＩＤ５１３に、組織図（変更前）４０２の人事部４１３の部門ＩＤ「Ａ００１Ｂ００１Ｚ００１」が設定されている。また、識別子５１１が「Ｂ０１０」で設定されている識別子情報は、部門ＩＤ５１３に、本社４１２配下の経理部４１４の部門ＩＤ「Ａ００１Ｂ００１Ｄ００１」、および、Ａ支店４１６と業務部４２１配下の経理部４１７の部門ＩＤ「Ａ００１Ｂ００２Ｇ００２Ｄ００２」が設定されている。また、識別子５１１が「Ｂ０２０」で設定されている識別子情報は、部門ＩＤ５１３は、識別子５１１が「Ｂ０２０」と同じ内容が登録されているが、参照モード５１４が全部門となっている識別子情報が登録されている。
【００４７】
次に、図６について説明を行う。図６は、プロセス定義１２０に格納されるプロセス定義の一例を示す図である。プロセス定義とは、ワークフローシステムにおいて起案または申請がされる業務の承認フローのルールを設定した経路設定のことである。なお、以下アクティビティという表現は、処理単位という意味で使用することとする。
【００４８】
図６のプロセスＡ６０１は、申請６１１のアクティビティにて申請者が「申請」を行うと、次の上長承認６１２のアクティビティに遷移し、さらに人事処理６１３のアクティビティを経て処理が完了するフローが設定されていることを示す。
人事処理６１３が完了すると、案件データの申請、承認のフローが完了する。
【００４９】
図６のプロセスＢ６０２は、申請６２１のアクティビティにて申請者が「申請」を行うと、次の上長承認６２２のアクティビティに遷移し、さらに経理処理６２３のアクティビティを経て処理が完了するフローが設定されていることを示す。経理処理６２３が完了すると、案件データの申請、承認のフローが完了する。
次に、図７について説明を行う。図７は図６のプロセス定義の各アクティビティの処理担当者の設定の一例を示す。
【００５０】
図７に示すように、プロセスの担当者設定情報は、項目として、プロセス７１１、アクティビティ７１２、担当部門７１３、部門指定方法７１４、部門ＩＤ７１５、識別子７１６、担当役割７１７からなる。
【００５１】
プロセス７１１には起案または申請される業務、アクティビティ７１２にはプロセス定義のアクティビティの種別が設定される。担当部門７１３には処理を担当するユーザの部門に関する情報指定される。担当部門７１３は部門指定方法７１４、部門ＩＤ７１５、識別子７１６から構成される。
【００５２】
部門指定方法７１４には、担当部門の指定方法が設定される。担当部門の指定方法としては、一例として、部門ＩＤを直接指定する「部門ＩＤ」、申請者が所属する部門を取得する「申請部門」、識別子設定から部門情報を取得する「識別子」の何れかを設定することが可能である。本実施例では、「申請部門」と「識別子」を使用することとする。
【００５３】
部門ＩＤ７１５は、部門指定方法７１４にて「部門ＩＤ」が指定された場合に固定の部門ＩＤの値が設定され、識別子７１６は部門指定方法７１４にて「識別子」が指定された場合に図５の識別子設定で管理されている識別子を特定するＩＤが設定される。すなわち、これにより、異なる処理担当者指定を行うことによって配送先を異なるようにする案件の処理単位に対し、処理担当者指定をまとめて行うことを可能とする（配送先管理手段）。部門指定方法７１４で、「申請部門」が指定された場合は、部門ＩＤ７１５と識別子７１６の両項目は設定されない。担当役割７１７は処理を担当するユーザの役割が設定される。
【００５４】
なお、部門ＩＤ７１５は、ワークフローシステムを運用している組織である、組織の部門ＩＤの値が入ることになる。なお、本実施例では、図４の組織図における部門ＩＤの値が入ることになる。また、担当役割７１７は、ワークフローシステムを運用している組織である、組織の担当役割の値が入ることになる。なお、本実施例では、図４の組織図における担当役割の値が入ることになる。
【００５５】
一例として、図６のプロセスＡ６０１のプロセス定義の各アクティビティの処理担当者の設定（図７の７２１から７２３）は、アクティビティ７１２の設定が「上長承認」（７２２）では、部門指定方法７１４は「申請部門」が設定され、担当役割７１７には「部門長」が設定されている。アクティビティ７１２の設定が「人事処理」（７２３）では、部門指定方法７１４は「識別子」、識別子７１６は「Ａ０１０」、担当役割７１７には「一般」が設定されている。すなわち、異なる処理担当者指定が行われる処理単位を識別子で処理担当者指定を行う（配送先指定手段）。また、識別子で特定した配送先の部門ＩＤと役割ＩＤによって、案件の処理担当者を決定する。
【００５６】
また、図６のプロセスＢ６０２のプロセス定義の各アクティビティの処理担当者の設定（図７の７２４から７２６）は、アクティビティ７１２の設定が「上長承認」（７２５）では、部門指定方法７１４は「申請部門」が設定され、担当役割７１７には「部門長」が設定されている。アクティビティ７１２の設定が「経理処理」（７２６）では、部門指定方法７１４は「識別子」、識別子７１６は「Ｂ０１０」、担当役割７１７には「一般」が設定されている。すなわち、異なる処理担当者指定が行われる処理単位を識別子で処理担当者指定を行う（配送先指定手段）。また、識別子で特定した配送先の部門ＩＤと役割ＩＤによって、案件の処理担当者を決定する。
【００５７】
次に、図８、図９、図１０の説明を行う。図８、図９、図１０は、本発明における、ワークフローの案件の処理担当者への割当処理を、識別子を用いてプロセス定義を編集することによって行う方法について説明をするフローチャート図である。
【００５８】
まず、図８の説明を行う。ステップＳ８０１では、案件に指定された組織情報を取得する。なお、各案件には、新規作成時点で最新の組織情報が適用されており、組織変更後も最新組織が適用されない限りは同じ組織情報にてワークフロー処理を行う。
【００５９】
ステップＳ８０２では、プロセス定義１２０を参照し、図７に示すような、処理待ちとなっているアクティビティ７１２の情報を取得する。また、担当役割７１７で設定されている役割の情報を取得する。
【００６０】
ステップＳ８０３ではステップＳ８０２で取得した、処理待ちとなっているアクティビティ７１２の、担当部門７１３の部門指定方法７１４を参照し、部門指定が「申請部門」であるかを判定する。部門指定が「申請部門」であった場合（ステップＳ８０３でＹＥＳの場合）は、ステップＳ８０４へ処理を進める。
ステップＳ８０４では、申請者の所属部門である申請部門の部門ＩＤを取得し、ステップＳ８１３へ処理を進める。
【００６１】
ステップＳ８１３では、ステップＳ８０４で取得した担当部門７１３に指定された部門ＩＤ７１５と、ステップＳ８０２で取得した担当役割７１７に該当するユーザを検索し、案件の割当を行う。案件割当処理については、図９の案件の処理担当者割り当て処理において説明する。
【００６２】
一方、ステップＳ８０３にて、ステップＳ８０２で取得した、処理待ちとなっている次のアクティビティ７１２の部門指定方法７１４が「申請部門」でない場合（ステップＳ８０３でＮＯの場合）は、ステップＳ８０５へ処理を進める。
【００６３】
ステップＳ８０５では、ステップＳ８０２で取得した、処理待ちとなっている次のアクティビティ７１２の部門指定方法７１４が「識別子」であるかを判定する。部門指定方法７１４が「識別子」でない場合（ステップＳ８０５でＮＯ）は、ステップＳ８０６へ処理を進める。
【００６４】
ステップＳ８０６では、Ｓ８０２で取得した、処理待ちとなっている次のアクティビティ７１２の部門ＩＤ７１５を取得し、ステップＳ８１３の処理担当者割り当て処理（図９）へと処理を進める。
【００６５】
一方、ステップＳ８０５にて、Ｓ８０２で取得した、処理待ちとなっている次のアクティビティ７１２の部門指定方法７１４が「識別子」であった場合（ステップＳ８０５でＹＥＳ）は、ステップＳ８０７へ処理を進める。
【００６６】
ステップＳ８０７では、ステップＳ８０５で取得した識別子を特定するＩＤを基に、図５の識別子設定のテーブルより識別子情報を取得し、ステップＳ８０８へ処理を進める。なお、最新の組織が図４の組織変更前の組織図（変更前）４０１である場合は、案件の配送を組織図（変更前）４０１で行うため、組織図（変更前）４０１で構成される識別子設定（変更前）５０１の識別子情報が使用されるが、組織変更が行われ、最新の組織が図４の組織図（変更後）４０２となった場合は、案件の配送を組織図（変更後）４０２で行うため、組織図（変更後）４０２で構成される識別子設定（変更後）５０２の識別子情報が使用されることとする。
【００６７】
ステップＳ８０８では、ステップＳ８０７にて取得（識別子７１６と識別子５１１が合致したものを取得）した識別子情報に紐付くの部門ＩＤ５１３を参照し、部門ＩＤが複数指定されているかを判定する。部門ＩＤが複数指定されていない場合（ステップＳ８０８でＮＯ）は、ステップＳ８１３の処理担当者割り当て処理（図９）へと処理を進める。部門ＩＤが複数指定されている場合（ステップＳ８０８でＹＥＳ）は、ステップＳ８０９へと処理を進める。  ステップＳ８０９では、ステップＳ８０７にて取得した識別子情報の参照モード５１４を参照し、参照モードが「全部門」であるかを判定する。参照モードが「全部門」である場合（ステップＳ８０９でＹＥＳ）はステップＳ８１０へ処理を進める。参照モードが「全部門」でない場合（ステップＳ８０９でＮＯ）はステップＳ８１１の処理を全ての部門ＩＤに対して繰り返し実行する。
【００６８】
ステップＳ８１０では、ステップＳ８０７にて取得した識別子情報の部門ＩＤ５１３の部門ＩＤの中より、申請部門に応じて次の処理担当となる部門ＩＤを１つに絞り込む処理を行う。なお、その部門ＩＤとは、識別子で管理されているそれぞれ複数の部門ＩＤと申請部門との関係において、組織階層上、共通の階層が一番多い部門、または、共通階層が多い部門が複数存在した場合は、その中で申請部門とそれぞれの部門までの階層の距離が一番短い部門、であることとする。なお、ステップＳ８１０の処理は、図１０の部門ＩＤ絞込み処理において説明する。  ステップＳ８１２では、図９の処理担当者割り当て処理を実行する。以上、図８の説明を終了する。
【００６９】
次に図９の説明を行う。図９は、取得した部門ＩＤ７１５、または、部門ＩＤ５１３と担当役割７１７に該当するユーザを検索し、案件を処理担当者に割り当てる処理である。
【００７０】
ステップＳ９０１では、案件が配送されている最新の組織情報において、これまでに取得した部門ＩＤ５１３、または部門ＩＤ７１５、担当役割７１７の情報から該当するユーザを検索する。
【００７１】
ステップＳ９０２では、ステップＳ９０１で検索した結果、該当ユーザが存在したかどうかを判定する。該当ユーザが存在しない場合（ステップＳ９０２でＮＯの場合）は、ステップＳ９０４へ処理を進める。
【００７２】
ステップＳ９０４では、該当ユーザが存在しないためエラー処理を行う。
一方、ステップＳ９０２で該当ユーザが存在する場合（ステップＳ９０２でＹＥＳの場合）は、ステップＳ９０３へ処理を進める。
【００７３】
ステップＳ９０３では、検索結果に該当するユーザに対して、案件の割り当てを実行する。以上、図９の処理の説明を終了する。
【００７４】
次に、図１０に説明を行う。図１０は、ステップＳ８０７で取得した識別子情報の部門ＩＤ５１３の部門ＩＤの中より、次の処理担当となる部門の部門ＩＤを１に絞り込む処理である。
【００７５】
ステップＳ１００１では、ステップＳ１００４で部門ＩＤを代入するために必要となる領域である、ワークエリアＡをクリアする処理を行う。
【００７６】
図１０では、図８のステップＳ８０７で部門ＩＤ５１３から取得した複数の部門ＩＤ全てについて、ステップＳ１００２〜Ｓ１００４の処理を、識別子情報の部門ＩＤ５１３の登録順に、繰り返し実行する。
【００７７】
ステップＳ１００２では、申請者が所属する部門ＩＤから判定対象となる部門ＩＤとの共通階層数と、申請部門と判定対象の部門との距離を取得する。なお、距離については、一階層上、又は下へ移動するごとに距離は１として数えることにする。
【００７８】
ステップＳ１００３では、「ステップＳ１００４で保持されている部門ＩＤとの共通階層数よりもお大きい」または、「ステップＳ１００４で保持されている部門ＩＤと共通階層数を比較して共通階層数が同じであり、且つステップＳ１００４で保持されている部門ＩＤとの距離が小さい」のいずれの条件に合致するかを判定する。
【００７９】
すなわち、識別子によって管理される配送先の部門が複数である場合、案件が申請された部門ＩＤと、識別子によって管理される配送先の部門との関係において、共通する階層数が多い部門ＩＤを、識別子によって決定する案件の処理担当者が所属する部門ＩＤとして指定する。また、識別子によって管理される配送先の部門が複数であり、案件が申請された部門ＩＤと、識別子によって管理される配送先の部門との関係において、共通する階層数が多い部門ＩＤが複数ある場合、その部門ＩＤの中より、申請された部門ＩＤとの関係において距離が近い部門ＩＤを、識別子によって決定する案件の処理担当者が所属する部門ＩＤとして指定する。
【００８０】
条件に当てはまらない場合（ステップＳ１００３でＮＯの場合）は、ステップＳ１００５へ処理を進める。「ステップＳ１００４で保持されている部門ＩＤとの共通階層数よりもお大きい」または、「ステップＳ１００４で保持されている部門ＩＤと共通階層数を比較して共通階層数が同じであり、且つステップＳ１００４で保持されている部門ＩＤとの距離が小さい」場合い（ステップＳ１００３でＹＥＳの場合）は、ステップＳ１００４へ処理を進める。なお、本処理の、ステップＳ１００２からステップＳ１００４の繰返し処理の初回は、必ず、ステップＳ１００４でワークエリアＡに部門ＩＤが設定されることになる。
【００８１】
なお、ひとつ前の繰り替えし処理のステップＳ１００４で保持されたワークエリアＡの部門ＩＤと申請部門との共通階層数及び距離がどちらも同値である部門ＩＤがあった場合、ステップＳ１００４においては、部門ＩＤを上書きしないこととしている。この場合、先に処理したものが優先して部門ＩＤとして絞込みが行われることにしている。又、先に処理が行われ、優先が与えられるようにするため、図５の部門ＩＤ５１３には、処理担当として優先度の高い部門ＩＤから処理が行われるように登録を行うこととする。
【００８２】
ステップＳ１００４では、ステップＳ１００３で条件に合致した部門ＩＤをワークエリアＡに設定する。
【００８３】
なお、ステップＳ８０７で取得した識別子情報の部門ＩＤ５１３の部門ＩＤについて全て処理が終了したら図１０の処理を終了する。以上、図１０の説明を終了する。
【００８４】
次に、プロセス定義に対して設定された識別子によって、どのように処理担当者を決定しているのか、について例を挙げて説明する。
【００８５】
まず、図４の組織図（変更前）４０１、図５の識別子設定（変更前）５０１、図６のプロセスＢ６０２のプロセス定義、図７のプロセス７１１がプロセスＢのアクティビティに対する処理担当者指定、の情報によって、営業部４１５のユーザＥ１２が業務をプロセスＢで申請した場合について説明を行う。
【００８６】
この場合、次の処理となるアクティビティ７１２の「上長承認」（図７の７２５）の処理担当者は、部門指定方法７１４で「申請部門」で指定されている。この場合、図８のステップＳ８０２で担当役割７１７の担当役割：部門長と、ステップＳ８０４で、申請部門の部門ＩＤ：Ａ００１Ｂ００１Ｅ００１を取得し、図９の処理担当者割り当て処理を実行する。ステップＳ９０１にて担当部門ＩＤ「Ａ００１Ｂ００１Ｅ００１」、担当役割「部門長」のユーザを検索した結果、部門長であるユーザＥ１１が組織図（変更前）４０１に存在するため、ステップＳ９０３にてユーザＥ１１に案件が割り当てられる。
【００８７】
続いて、ユーザＥ１１が承認処理を実行した場合、次の処理となるアクティビティ７１２の「経理処理」（図７の７２６）の処理担当者は、部門指定方法７１４で「識別子」で指定されていて、識別子７１６のＩＤがＢ０１０で指定されている。この場合、図８のステップＳ８０２で担当役割７１７の担当役割：一般と、ステップＳ８０７にて識別子５１１がＢ０１０である情報の部門ＩＤ５１３の値：「Ａ００１Ｂ００１Ｄ００１，Ａ００１Ｂ００２Ｄ００２」を取得する。この場合、部門ＩＤが複数指定されており、参照モード５１４が「１部門」であるため、図１０の部門ＩＤ絞込み処理を実行する。
【００８８】
登録順に（図５では部門ＩＤ５１３に左から記載順に）処理するため、ステップＳ１００２で、まず、経理部４１４の部門ＩＤ「Ａ００１Ｂ００１Ｄ００１」について、申請部門との共通階層数と、距離を取得する。この場合、共通階層数が２で、距離が２となる。
【００８９】
ステップＳ１００３では、初回は、Ｓ１００４で設定した部門ＩＤよりも共通階層数が大きいと必ずなるため、ステップＳ１００３では、ＹＥＳとなり、ステップＳ１００４では、ワークエリアＡに、部門ＩＤとしてＡ００１Ｂ００１Ｄ００１が設定される。
【００９０】
次に、経理部４１７の「Ａ００１Ｂ００２Ｄ００２」について処理を行う。ステップＳ１００２で、申請部門との共通階層数と、距離を取得すると、この場合、共通階層数が１で、距離が４となる。
【００９１】
なお、ステップＳ１００３の条件には、合致しないため、本処理は終了となる。よって、絞り込まれた部門ＩＤは経理部４１４の「Ａ００１Ｂ００１Ｄ００１」となる。その後、図９の処理担当者割り当て処理のステップＳ９０１にて部門ＩＤ「Ａ００１Ｂ００１Ｄ００１」、担当役割「一般」であるユーザの検索を行い、案件は経理部４１４のユーザＤ１１に割り当てられることになる。
【００９２】
次に、先に説明を行った内容と同じ条件で（図４の組織図（変更前）４０１、図５の識別子設定（変更前）５０１、図６のプロセスＢ６０２のプロセス定義、図７のプロセス７１１がプロセスＢのアクティビティに対する処理担当者指定、の情報によって）、営業部４１８のユーザＥ２２が申請した場合について説明を行う。なお、先の説明と同様のプロセスを使用しているため、動作として違いが生じる箇所となる識別子による処理担当者を指定する処理のみ説明を行う。
【００９３】
識別子情報としては、この場合、先の説明と同じく、識別子７１６がＢ０１０の値が得られるが、ステップＳ１００２で、経理部４１４の部門ＩＤ「Ａ００１Ｂ００１Ｄ００１」について、申請部門との共通階層数と、距離を取得する。この場合、共通階層数が１、距離が４となる。
【００９４】
ステップＳ１００３では、初回は、ステップＳ１００４で設定した部門ＩＤよりも共通階層数が大きいと必ずなるため、ステップＳ１００３では、ＹＥＳとなり、ステップＳ１００４では、ワークエリアＡに、部門ＩＤとしてＡ００１Ｂ００１Ｄ００１が設定される。
【００９５】
次に、経理部４１７の「Ａ００１Ｂ００２Ｄ００２」について処理を行う。ステップＳ１００２で、申請部門との共通階層数と、距離を取得すると、この場合、共通階層数が２、距離が２となる。
【００９６】
次に、ステップＳ１００３では、前回ステップＳ１００３で判定した「Ａ００１Ｂ００１Ｄ００１」よりも共通階層数が大きいため（ステップＳ１００３においてＹＥＳ）、ステップＳ１００４で、ワークエリアＡに、部門ＩＤとして「Ａ００１Ｂ００２Ｄ００２」を設定する。その後、図９の処理担当者割り当て処理のステップＳ９０１にて、部門ＩＤ「Ａ００１Ｂ００１Ｄ００２」、担当役割「一般」であるユーザの検索を行い、案件は経理部４１７のユーザＤ２２に案件が割り当てられることになる。
【００９７】
次に、先に説明を行った内容と同じ条件で（図４の組織図（変更前）４０１、図５の識別子設定（変更前）５０１、図６のプロセスＢ６０２のプロセス定義、図７のプロセス７１１がプロセスＢのアクティビティに対する処理担当者指定、の情報によって）、開発部４２０のユーザＦ３２が申請した場合について説明を行う。なお、この場合においても、先の説明と同様のプロセスを使用しているため、動作として違いが生じる箇所となる識別子による処理担当者を指定する処理のみ説明を行う。
【００９８】
識別子情報としては、この場合、先の説明と同じく、識別子７１６がＢ０１０の値が得られるが、ステップＳ１００２で、経理部４１４の部門ＩＤ「Ａ００１Ｂ００１Ｄ００１」について、申請部門との共通階層数と、距離を取得する。この場合、共通階層数が１、距離が４となる。
【００９９】
ステップＳ１００３では、初回は、ステップＳ１００４で設定した部門ＩＤよりも共通階層数が大きいと必ずなるため、ステップＳ１００３では、ＹＥＳとなり、ステップＳ１００４では、ワークエリアＡに、部門ＩＤとしてＡ００１Ｂ００１Ｄ００１が設定される。
【０１００】
次に、経理部４１７の「Ａ００１Ｂ００２Ｄ００２」について処理を行う。ステップＳ１００２で、申請部門との共通階層数と、距離を取得すると、共通階層数は１、距離は４となる。
【０１０１】
ステップＳ１００３における判定処理では、共通階層数、距離とも初回にステップＳ１００４で設定した「Ａ００１Ｂ００１Ｄ００１」の共通階層数と距離が同値であるため、ステップＳ１００３ではＮＯとなる。従って、ステップＳ１００４で初回に設定された部門ＩＤである、識別子の中で最初に図１０の処理を行った、Ａ００１Ｂ００１Ｄ００１が部門ＩＤとして割り当てられることになる。
【０１０２】
なお、今回のように、処理を行っていく途中で、共通階層数とノード数が同じであった場合に、先にステップＳ１００４で設定された組織（事実上、デフォルトの組織）で優先して承認が行えるようにするため、図５の部門ＩＤ５１３には、処理担当として優先度の高い部門ＩＤから処理が行われるように登録を行うこととする。なお、図１０の処理を行う部門ＩＤの優先順の指定についてこの方法に限ることなく、別の項目を持たせ、どの部門ＩＤから最初に図１０の処理を行うようにするかを図５のテーブルで管理を行っても良いこととする。
【０１０３】
その後、図９の処理担当者割り当て処理のステップＳ９０１にて、部門ＩＤ「Ａ００１Ｂ００１Ｄ００１」、担当役割「一般」であるユーザの検索を行い、案件は経理部４１４のユーザＤ１２に案件が割り当てられることになる。
【０１０４】
次に、この業務が、図４の組織図（変更後）４０２、図５の識別子設定（変更後）５０２、図６のプロセスＢ６０２、図７のプロセス７１１がプロセスＢのアクティビティに対する処理担当者指定の情報によって、開発部４２０のユーザＦ３２が申請した場合について説明を行う。
【０１０５】
この場合、次の処理となるアクティビティ７１２の「上長承認」（図７の７２５）の処理担当者は、部門指定方法７１４で「申請部門」で指定されている。この場合、図８のステップＳ８０２で担当役割７１７の担当役割：部門長と、ステップＳ８０４で、申請部門の部門ＩＤ：Ａ００１Ｂ００１Ｆ００１を取得し、図９の処理担当者割り当て処理を実行する。ステップＳ９０１にて担当部門ＩＤ「Ａ００１Ｂ００１Ｆ００３」、担当役割「部門長」のユーザを検索した結果、部門長であるユーザＦ３１が組織図（変更後）４０２に存在するため、ステップＳ９０３にてユーザＥ３１に案件が割り当てられる。
【０１０６】
続いて、ユーザＦ３１が承認処理を実行した場合、次の処理となるアクティビティ７１２の「経理処理」（図７の７２６）の処理担当者は、部門指定方法７１４で「識別子」で指定されていて、識別子７１６のＩＤがＢ０１０で指定されている。この場合、図８のステップＳ８０２で担当役割７１７の担当役割：一般と、ステップＳ８０７にて識別子５１１がＢ０１０である情報の部門ＩＤ５１３の値：「Ａ００１Ｂ００１Ｄ００１，Ａ００１Ｂ００Ｇ０００２Ｄ００２」を取得する。この場合、部門ＩＤが複数指定されており、参照モード５１４が「１部門」であるため、図１０の部門ＩＤ絞込み処理を実行する。
【０１０７】
登録順に（図５では部門ＩＤ５１３に左から記載順に）処理するため、ステップＳ１００２で、まず経理部４１４の部門ＩＤ「Ａ００１Ｂ００１Ｄ００１」について、申請部門との共通階層数と、距離を取得する。この場合、共通階層数が１で、距離が４となる。
【０１０８】
ステップＳ１００３では、初回は、Ｓ１００４で設定した部門ＩＤよりも共通階層数が必ず大きくなるため、ステップＳ１００３では、ＹＥＳとなり、ステップＳ１００４では、ワークエリアＡに、部門ＩＤとしてＡ００１Ｂ００１Ｄ００１が設定される。
【０１０９】
次に、経理部４１７の「Ａ００１Ｂ００２Ｇ００２Ｄ００２」について処理を行う。ステップＳ１００２で、申請部門との共通階層数と、距離を取得すると、共通階層数が２、距離が５となる。
【０１１０】
ステップＳ１００３では、前回ステップＳ１００３で判定した「Ａ００１Ｂ００１Ｄ００１」よりも、共通階層数が大きいため（ステップＳ１００３においてＹＥＳ）、ステップＳ１００４で、ワークエリアＡに、部門ＩＤとして「Ａ００１Ｂ００２Ｇ００２Ｄ００２」を設定する。
【０１１１】
よって、絞り込まれた部門ＩＤは経理部４１７の「Ａ００１Ｂ００２Ｇ００２Ｄ００２」となる。その後、図９の処理担当者割り当て処理のステップＳ９０１にて部門ＩＤ「Ａ００１Ｂ００２Ｇ００２Ｄ００２」、担当役割「一般」であるユーザの検索を行い、案件は経理部４１７のユーザＤ２２に割り当てられることになる。
【０１１２】
なお、これまでの説明では、このプロセスＢの７２６で設定されている識別子７１６が、Ｂ０１０で説明を行ってきたが、Ｂ０２０に設定されている場合、識別子５１１がＢ０２０の参照モード５１４は、全部門となっている。
【０１１３】
この場合例えば、営業部４１５のユーザＥ１１が申請した案件は、プロセスＢ６０２の経理処理６２３（アクティビティ７１２が７２６）において、識別子７１６に、Ｂ０２０の識別子が割り当てられて、担当役割７１７が「一般」である。この場合、識別子５１１がＢ０２０に該当する部門ＩＤ５１３は、「Ａ００１Ｂ００１Ｄ００１」と「Ａ００１Ｂ００２Ｇ００２Ｄ００２」となっているため、これら全ての部門ＩＤに所属し、担当役割が「一般」の処理担当者に割り当てることになる。
【０１１４】
このため、経理部４１４のユーザＤ１２、経理部４１７のユーザＤ２２の両方に割り当てられることになる。なお、本実施例においては、図４の組織図（変更前）４０１でワークフローを運用している時は図５の識別子設定（変更前）５０１を、図４の組織図（変更後）４０２でワークフローを運用している時は識別子設定（変更後）５０２を参照して処理担当者を決定しているが、結果はどちらの組織においても同じ担当者に割り当てられることとなっている。もちろん、図４の組織図（変更前）４０１と図４の組織図（変更後）４０２の組織の内容、識別子設定（変更前）５０１と識別子設定（変更後）５０２の参照モード５１４が全部門で、部門ＩＤ５１３に設定されている内容が、変更前と変更後で異なる場合はこの限りではない。
【０１１５】
なお、案件はどちらかのユーザが処理を実行した場合に完了することとする。
【０１１６】
これまでは、処理担当となる部門が複数ある場合に、プロセスにおいて処理担当者を識別子で指定し、識別子を管理するテーブル上で部門ＩＤを管理することによって、処理担当者を決定する例について述べたが、次は、組織変更が行われた場合のことを考慮し、プロセスで指定されていた処理担当者の識別子で指定することにより、処理担当者を決定する例を説明する。
【０１１７】
図４の組織図（変更前）４０１、図５の識別子設定（変更前）５０１、図６のプロセスＡ６０１のプロセス定義、図７のプロセス７１１がプロセスＡのアクティビティに対する処理担当者指定、の情報によって、営業部４１５のユーザＥ１２が業務をプロセウスＡで申請した場合について説明を行う。
【０１１８】
この場合、次の処理となるアクティビティ７１２の「上長承認」（図７の７２２）の処理担当者は、部門指定方法７１４で「申請部門」で指定されている。この場合、図８のステップＳ８０２で担当役割７１７の担当役割：部門長と、ステップＳ８０４で、申請部門の部門ＩＤ：Ａ００１Ｂ００１Ｅ００１を取得し、図９の処理担当者割り当て処理を実行する。ステップＳ９０１にて担当部門ＩＤ「Ａ００１Ｂ００１Ｅ００１」、担当役割「部門長」のユーザを検索した結果、部門長であるユーザＥ１１が組織図（変更前）４０１に存在するため、ステップＳ９０３にてユーザＣ１１に案件が割り当てられる。
【０１１９】
続いて、ユーザＣ１１が承認処理を実行した場合、次の処理となるアクティビティ７１２の「人事処理」（図７の７２３）の処理担当者は、部門指定方法７１４で「識別子」で指定されていて、識別子７１６のＩＤがＡ０１０で指定されている。この場合、図８のステップＳ８０２で担当役割７１７の担当役割：一般と、ステップＳ８０７にて識別子５１１がＡ０１０である情報の部門ＩＤ５１３の値：「Ａ００１Ｂ００１Ｃ００１」を取得する。
【０１２０】
この後、組織変更が行われたとする。このため、今までは、図４の組織図（変更前）４０１において、申請された案件が処理されていたが、案件の処理を組織変更後の図４の組織図（変更後）４０２で処理を行い、案件のプロセスで使用されている識別子情報については、識別子設定（変更後）５０２を適用するようにする。
【０１２１】
組織図（変更後）４０２と識別子設定（変更後）５０２の情報により案件を進めるとすると、組織変更適用前の識別子５１１「Ａ０１０」に紐付く部門ＩＤ５１３は「Ａ００１Ｂ００１Ｃ００１」は、組織変更後は部門ＩＤ５１３「Ａ００１Ｂ００１Ｚ００１」が適応されるため、部門ＩＤが「Ａ００１Ｂ００１Ｚ００１」で、担当役割が「一般」である組織図（変更後）４０２のユーザＣ１１に案件が割り当てられることになる。
【０１２２】
すなわち、ワークフローシステムの処理が行われる組織において組織変更に対応するべく、識別子によって管理される配送先の部門を組織変更が行われた後の部門に変更することで、案件の処理待ちとなっている処理単位の処理担当者が識別子で設定されている場合、案件を組織変更が行われた後の組織における処理担当者を割り当て、案件の処理を進めることを可能とする。
【０１２３】
このように、組織情報１２２が更新された場合、それに紐付く識別子情報１２３を更新すれば、業務情報１１９に割り当てられるプロセス定義１２０を修正することなく、最新組織における処理担当者に案件を割り当てることができる。
【０１２４】
以上により、処理担当となる組織が複数あっていずれかの部門に処理が進むようにしなくてはならない場合や、組織変更が行われて処理担当者への配送先を変更しなくてはならない場合であっても、プロセスの処理担当者の指定で使用される機能別承認単位である図５の識別子設定の部門ＩＤ５１３を最新の組織情報で更新することにより、業務情報１１９に割り当てられるプロセス定義１２０（図６のプロセス定義）を修正することなく、案件を最新の組織における処理担当者に割り当てることができる。
【０１２５】
すなわち、処理単位に設定された識別子により、申請部門ごとに異なる処理担当者指定を行う、あるいは、組織変更が行われた後、組織変更前とは異なる組織変更後の新しい組織の情報を基に新たに処理担当者指定を行うことにより、案件の処理担当者を、異なる処理担当者指定に該当する処理担当者に決定する（処理担当者決定手段）。
【０１２６】
以上、１実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１２７】
また、本発明におけるプログラムは、図８、図９、図１０に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図８、図９、図１０の処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図８、図９、図１０の各装置の処理方法ごとのプログラムであってもよい。
【０１２８】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１２９】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。
【０１３０】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。
【０１３１】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３２】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３３】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１３４】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１３５】
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１３６】
１００  ネットワーク
１０１  クライアント端末
１０２  管理端末
１０３  ワークフローサーバ
１０４  システムデータベース
２０１  ＣＰＵ
２０２  ＲＡＭ
２０３  ＲＯＭ
２０４  システムバス
２０５  入力コントローラ
２０６  出力コントローラ
２０７  外部メモリコントローラ
２０８  通信Ｉ／Ｆコントローラ
２０９  入力部
２１０  出力部
２１１  外部メモリ
２１２  プログラム
【図１】
2015228141.tif 000003
【図２】
2015228141.tif 000004
【図３】
2015228141.tif 000005
【図４】
2015228141.tif 000006
【図５】
2015228141.tif 000007
【図６】
2015228141.tif 000008
【図７】
2015228141.tif 000009
【図８】
2015228141.tif 000010
【図９】
2015228141.tif 000011
【図１０】
2015228141.tif 000012