JP2007305129A - ビジネスプロセス統合リポジトリ - Google Patents

Abstract

【課題】ビジネスプロセスを統合するリポジトリを提供する。
【解決手段】方法および装置は異なるバックエンドシステムからのビジネスプロセスを記憶するメタリポジトリを提供し、異なるバックエンドシステムにビジネスプロセスを利用可能とする。一実施形態において、バックエンドシステムは互換性のないソフトウェアを実効するが、ビジネスプロセスは標準化され、バックエンドシステムの各々においてインスタンス生成することが可能である。
【選択図】図６

Description

本発明は、ビジネスプロセス管理に関し、より詳しくは、ビジネスプロセスを記憶およびアクセスすることに関する。

企業は、ビジネスプロセスを通して規則正しく作業を実行し、タスクを完了する。ビジネスプロセスは、全体の業務の１つまたは複数のタスクおよびフェーズが関連するメカニズムを提供する。各々のタスクの完了は全ての業務を完了する。例えば、組織は、志願者を集め、志願者を評価し、最終的に選ばれた志願者を採用するためのフェーズを有する雇用プロセスを有し得る。各フェーズは１つまたは複数のタスクを有し得る。例えば、志願者を集めるフェーズについて、タスクは、求人を市場に出し、履歴書を集め、履歴書をえり分け、選ばれた志願者との面接の予定を立て、または他のあるいは異なるタスクを含むことが可能である。上記の各フェーズは異なるラベルを有し得るとともに、より少ないまたはより多くのフェーズが存在し得ることに留意すべきである。簡単な雇用プロセスが与えられたが、ビジネスプロセスは、販売、財務、マーケティング、製造、出荷、等を含む組織のあらゆる領域に関係し得る。

組織のビジネスプロセスは、組織の収益に影響を与える作業を遂行するために効率および機能の点で大きな価値を与え得る。組織のビジネスプロセスは、新たな技術革新、新たな技術の導入、組織またはその部門の拡張としてのタスクの分離、等のような進展と歩調をそろえて時間にわたって発展すべきである。大量販売を含むビジネスプロセスの従来の修正または発展は変化し、そこでは“現在の”ビジネスプロセスは、それらを置換することを意味する“更新された”ビジネスプロセスと置き換えられる。ビジネスプロセスの従来の変更は、本来備わっている予測不能およびリスクを有する。更新された手順における欠陥は、結果として、多大の費用を要する遅延および事実上プロセスへの非効率の導入となり得る。１つのプロセスをもう１つのプロセスと置換することは、ビジネスプロセスの変更の性質のために変更の実現を遅らせるかなりの投資を表わす。

組織が適切なビジネスプロセスを有するとしても、組織が成長するに連れてビジネスプロセスは異なり得るとともに必ずしも十分に適合するとは限らず、ビジネスプロセスは組織の異なる領域または部門において開発され得る。ビジネスプロセスは必ずしも同一のソフトウェアを用いて実行することが可能であるとは限らない。崩壊したビジネスプロセスの使用は、類似のプロセスの再開発、および、異なるが類似の目的の達成を試みるプロセスの維持のために、結果として非効率となる。各種バックエンドシステム（例えば、顧客関係管理（ＣＲＭ）、企業資源計画（ＥＲＰ）、等）の配備は、従来から、１つのシステムからもう１つのシステムへのプロセスの再利用を可能としない。従って、ビジネスプロセスを使用し、または新たなビジネスプロセスを生成するために、他の情報源またはシステムが特定の実装のために望ましいビジネスプロセスを有するとしても、一般にアクセスはビジネスプロセスの単一の情報源または単一のバックエンドシステムに制限される。

さらに、現在のシステムはアドホックワークフローの使用を通して手順の開発を可能とし、一般にアドホックワークフローは部分ごとに手順の開発を可能とする。部分ごとの開発は、特定の個人または役職（例えば、管理者、財務承認者、等）による実際の実装のためのアクションを生成することによってビジネスプロセスからワークフローまたは一連の業務／アクションを生成することと対照をなす。アドホックワークフローは、全体の業務が部分ごとに実行されるに連れて開発される。ワークフローの系列における各ポイントは、ワークフローオブジェクトとなり、全体のワークフローの各フェーズのために新たなオブジェクトが生成される。アドホックワークフローは、従来から、それらが開発されるローカルな状況に制限されてきた。特に、アドホックワークフローは、従来から、別個のバックエンドシステムに利用可能な共通システムに接続しない。従って、それが生成されたバックエンドシステム以外でのアクセスのために利用可能でないアドホックワークフローが開発され得る。

異なるバックエンドシステムからのビジネスプロセスを記憶するためにメタリポジトリを提供することが可能であり、メタリポジトリは異なるバックエンドシステムにビジネスプロセスを利用可能とする。一実施形態において、メタリポジトリに記憶されたビジネスプロセスは、ビジネスプロセス修正フレームワークによって修正することが可能である。従って、複数のバックエンドシステムに利用可能な１つまたは複数のビジネスプロセスは、システムが発展することを可能とするように更新することが可能である。

続く記載は、本発明の実施形態による実装の例として与えられた説明を含む各種図面の説明を含む。図面は、例として理解すべきであり、限定として理解すべきでない。

ここで用いられる、１つまたは複数の“実施形態”への言及は、本発明の少なくとも１つの実装に含まれる特定の特徴、構造、または特性を説明するものとして理解すべきである。従って、ここに現われる“一実施形態において”等の語句は、本発明の各種の実施形態および実装を説明し、必ずしも全て同一の実施形態に言及するとは限らない。しかしながら、それらは必ずしも相互に排他的であるとも限らない。本発明の実施形態の全体像の説明が以下に与えられ、図面を参照して行われるある細部および実装のより詳細な説明が続く。

ビジネスプロセス修正フレームワークまたは再帰的修正モデルは、組織がそのビジネスプロセスを増分的に修正することを可能とし、ビジネスプロセスを各種の情報源から各種のバックエンドシステムに利用可能とする。さらに、修正フレームワークは各種バックエンドシステムに利用可能な新たなビジネスプロセスを生成するテンプレートとして保存することが可能なアドホックワークフローの生成をサポートすることが可能である。

＜ビジネスプロセス修正フレームワーク＞
一度に多くのビジネスプロセスまたは多くのビジネスプロセスの側面を変更するために単一の大規模なプロジェクトを開始することを含む従来のビジネスプロセスの修正とは対照的に、修正フレームワークは、ビジネスプロセスの変更が動的かつ増分的であることを可能とする。動的、増分的なビジネスプロセスの変更は、小さな破壊のリスクを有して、ビジネスプロセスの修正が、組織およびその構成員の優先度およびニーズに、より焦点を合わせることを可能とする。動的な変更の使用は、組織の構成員がそれ自身の内部プロセスの中で革新することを可能とし、内部プロセスは、システムをサポートするバックエンドシステムまたはバックエンドプロセスまたはプロセスコンポーネントの変更を必要としない。修正フレームワークは、創案から最終的な実装までの変更を誘導する手順を含む。一実施形態において、そのような手順は、修正提案、最初の修正評価、提案された修正の検査、提案された修正の配備、提案され配備された修正の監視のためのメカニズムを含み、また、寄与者に報償を与えるメカニズム、および、提案され配備された修正を撤回してシステムを既知の良好なプロセスにロールバックするメカニズムを含むことが可能である。修正フレームワークは、より少ない部分を含むことが可能であり、修正フレームワークが全ての部分を含むとしても１つまたは複数は選択的とすることが可能である。メカニズムのためのラベルの例として、修正フレームワークは、提案、評価、検査、配備、監視、撤回、報償のようなフェーズを含むことが可能である。修正フレームワークを通して、ビジネスプロセスは、従来から行われたような基礎を成すビジネスプロセスソフトウェアを変更することを必要とするのではなく、基礎を成すソフトウェアを発展させることが可能である。従って、ビジネスプロセスを実行するソフトウェアは、ビジネスプロセスにおける変更を実装するために変更される必要がない。

従来から、企業システム（例えば、ドイツ、ウォールドルフのＳＡＰ ＡＧから入手可能なシステム）を実装することは膨大なテンプレートの設定を必要とした。ここで説明される修正フレームワークの実装は、テンプレートの実装を超える機能を提供する。テンプレートを介して設定を変更するのではなく、修正フレームワークは組織の基礎を成すビジネスプロセスの変更を可能とする。企業システムソフトウェアのより新しいバージョンが利用可能となるか否かにかかわらず、企業システムは、修正フレームワークを通して付加されるより新しい実務を含むように時間にわたって発展することが可能である。修正フレームワークはビジネスプロセスの開発のために再帰的モデルを提供する。

実務におけるプロセス修正の例として、組織内の個人またはチームは、注文の承諾前に信用調査を含むオーダーエントリープロセスへの変更を提案することが可能である。“短い調達時間の注文プロセス”、“優先顧客の注文”のような、オーダーエントリービジネスプロセスの変形を生成することが可能である。これらのプロセスは、ここで説明されるプロセス修正フレームワークを通して実装することが可能であり、オーダーエントリービジネスプロセスを実装する基礎を成すプログラミングまたはバックエンドシステムに影響を与えることなく配備することが可能である。従って、プログラマーまたはＩＴ管理者の助けなく変更を生じさせることが可能である。一実施形態において、ビジネスプロセスの修正は、提案を通してプロセス修正フレームワークの中で開始することが可能であり、提案は、修正を実装し、かつその実用性を検査するために一連の業務／イベントを開始することが可能である。

＜ビジネスプロセスメタリポジトリ＞
従来のシステムにおいて、ビジネスプロセスは、全体の企業システムの別個のバックエンドシステムのような、サブシステムの状況の中でのインスタンス生成（instantiation）のために利用可能である。時間にわたって異なるバックエンドシステムが発展するに連れて、個々のビジネスオブジェクトおよびプロセスワークフローオブジェクトは個々のバックエンドシステムの中で異なる可能性があり、（例えば、互換性のないソフトウェア、異なるオブジェクトに基づいて）必ずしも互換性を有するとは限らない。例えば、異なるバックエンドシステムの中で類似のプロセスの匹敵するフェーズに適用する異なるアクションを用いて、異なるバックエンドシステムの中で異なる方法で類似のプロセスを実行することが可能である。一実施形態において、ビジネスプロセスの統合リポジトリが設けられ、異なるバックエンドシステムにアクセス可能である。統合リポジトリにおけるプロセスと対応付けられたオブジェクトは、アプリケーション内に従来から含まれることが可能なロジックを含む。従って、プロセスロジックは、プロセスがアクセスされ実行されるアプリケーションから分離することが可能である。可搬性のあるプロセスとともに、プロセスは、複数のバックエンドシステム内でインスタンス生成することが可能なプロセスを有する単一の統合リポジトリまたはメタリポジトリ内に記憶することが可能である。各バックエンドシステムは、ビジネスプロセスの情報源として動作することが可能であり、もう１つのバックエンドシステム（すなわち、もう１つの“情報源”）内に適用することが可能なメタリポジトリにプロセスを提供する。メタリポジトリ内のプロセスの修正は、ここで説明されるビジネスプロセス修正フレームワーク内で達成することが可能である。従って、単一のリポジトリは、複数のバックエンドシステムに利用可能なプロセスを記憶することが可能であり、修正は、メタリポジトリにおいてプロセスを発展させるために任意のバックエンドシステム内で適用することが可能である。

＜アドホックワークフロー＞
従来のアドホックワークフローは、典型的に、生成されたシステムにローカルなワークフローを生成する。アドホックワークフローは汎用であるように生成することが可能である。ワークフローが生成されると、ワークフローを生成したユーザはそのワークフローを保存することが可能である。ユーザは、特定のインスタンスとして、テンプレートとして、または、最善の実務としてワークフローを保存することが可能である。一実施形態において、ユーザは、ワークフローを保存することができる異なる可能な方法の中で選択することを促される。ワークフローがテンプレートまたは最善の実務として保存されると、ユーザは、ワークフローを移植性および再利用性があるように生成することを可能とするために追加の情報を提供することが必要となり得る。例えば、ユーザは、ワークフローがどのように、いつ使用することが可能であるかを示し得る、使用基準、説明、予想される利益、等を含めることが必要となり得る。従って、ワークフローは他のバックエンドシステムに利用可能であるビジネスプロセスとしてのテンプレートとして保存することが可能である。

図１は、実行時（run-time）コンポーネントおよび設計時（design-time）コンポーネントを有するアプリケーションフレームワークの実施形態のブロック図である。一般に、複合アプリケーションフレームワーク１００は、基礎を成す企業基盤システム１８０に影響を与え、かつ強化し、企業基盤システム１８０は、１つまたは複数のデータ要素および／またはオペレーションを実行する機能を含むことが可能である。複合アプリケーションフレームワーク１００は、モデル化／生成されたソフトウェアである複合アプリケーションを生成するために構造を与える。複合アプリケーションは、半構造化プロセスをサポートし、イベント駆動型ビジネスシナリオおよび知識ベース型ビジネスシナリオを処理し、および／またはコラボレーションをサポートする。一実施形態において、複合アプリケーションはＪＡＶＡ（登録商標）スタックをサポートする。複合アプリケーションは各種部分に細分化することができ、各々は別個に生成／モデル化することができる。１つの実装において、複合アプリケーションの部分はエンタープライズジャバビーンズ（Enterprise Java（登録商標） Beans（ＥＪＢ））として実現することができ、他の実装において、設計時コンポーネントは、Ｊ２ＥＥ（Java（登録商標） 2 Enterprise Edition）、ＡＢＡＰ（ＳＡＰ Ｒ／３の開発専用言語）、または．ＮＥＴ（ドットネット）のような異なるプラットフォームへの実行時（run-time）実装を生成する機能を有することが可能である。一実施形態において、複合アプリケーションフレームワーク１００は、ドイツ、ウォールドルフのＳＡＰ ＡＧから入手可能な複合アプリケーションフレームワーク（composite application framework（ＣＡＦ））である。

複合アプリケーションフレームワーク１００は、一般に、基礎を成す企業プラットフォームからアプリケーションを分離することによって、複合アプリケーションが既存のシステム環境で動作することを可能とする。基礎を成す企業プラットフォームからアプリケーションを分離することは、主要なインタフェースを介してバックエンドシステムへの通信を提供し、バックエンドに独立のオブジェクトモデルを提供することを含み得る。複合アプリケーションフレームワーク１００は、設計時コンポーネント１０２および実行時コンポーネント１０４を含む。設計時コンポーネント１０２は、複合アプリケーションを生成するためのモデル化コンポーネント、およびモデルを生成するための１つまたは複数のメカニズムを含む。一般に、設計時コンポーネント１０２は、実行時コンポーネント１０４によって実行される複合アプリケーションを開発する役割を果たす。

設計時コンポーネント１０２は、プロセスモデラー（process modeler）１１０、ＵＩモデラー１２０、サービスモデラー１３０を含む。これらのモデラーは別個のエンティティとすることが可能であるが、別個のエンティティである必要はない。さらに、設計時コンポーネント１０２には、追加のモデル化ツールを設けることが可能である。一般に、モデラーは、ビジネスオブジェクト、ビジネスサービス、ビジネスプロセス、ユーザインタフェース、等を統合することを可能とする。プロセスモデラー１１０は、プロセスの各種フェーズを表わす１つまたは複数のアクション１１２を生成する機能を含む。アクション１１２の各々は、アクション１１２の作業を表わす対応付けられた１つまたは複数のオペレーションを有する。アクション１１２は、生成される業務の一部、またはオペレーションの実行においてユーザとの相互作用を提供する案内手順の一部とすることが可能である。アクション１１２が案内手順の一部である実施形態において、プロセスモデラー１１０は、各アクション１１２とともに案内手順を実行するための情報を含む。

また、プロセスモデラー１１０はコンテキスト１１４を含み、コンテキスト１１４は動作している企業システムに関するプロセスを認識する。企業システムを認識しないアプリケーションからファンクションが使用されると、プロセスモデラー１１０は、ファンクションをシステムに組み込むために、ファンクションをメタデータの中に包む。

ユーザインタフェース（ＵＩ）モデラー１２０は、ユーザインタフェースを生成する機能を提供し、複合アプリケーションフレームワーク１００を用いて生成された複合アプリケーションを通してアクセスすることが可能なデータまたはプロセスのビューを提供する。ＵＩモデラー１２０は、データについての任意の多数のビュー１２２を生成することが可能である。一実施形態において、開発されたアプリケーションの各々について標準のビューまたはパターンが用いられる。ユーザインタフェースは、テンプレートからのある要素を含むことが可能である。従って、ユーザインタフェースは、ある共通コンポーネントを有し、複数のアプリケーションにわたって馴染みやすいルックアンドフィールを提供することが可能である。あるビューは、アプリケーションが実行される環境に依存する。ビュー１２２は、アプリケーションと対応付けられた役割、権限、業務に基づいて動的にビューを生成する機能を含むことが可能である。ＵＩモデラー１２０のパターン設定１２４は、テンプレートおよび標準ＵＩコンポーネントの使用を可能とする。

サービスモデラー１３０は複合アプリケーションがデータをアクセスすることを可能とする。データオブジェクトはサービスを介してアクセスされる。従って、サービスモデラー１３０は、データがアクセスされるサービス指向モデルを提供する。一実施形態において、サービスモデラー１３０は企業サービスアーキテクチャ（enterprise service architecture（ＥＳＡ））を提供し、モデル駆動型アーキテクチャではなくサービス駆動型アーキテクチャによってアプリケーションが開発される。サービス駆動型アーキテクチャは、データとの相互作用を与える呼び出し可能なサービスへのアクセスを提供する。サービスモデラー１３０はサービス１３２を含み、サービス１３２は、提供することが可能な１つまたは複数のサービスを表わす。サービス１３２は、限定しないが、案内手順、オブジェクト監視、独立型アクション、プログラム、ファンクション、等を含むことが可能である。サービスモデラー１３０のエンティティ１３４は、企業内のサービスまたはウェブサービスにアクセスするように生成されたコンポーネントを提供する。ここで説明される企業サービスまたはウェブサービスは、アドレス指定可能であり、（例えば、航空券予約のような）要求および／または入力のパラメータに基づいて機能を提供するネットワーク内（企業ネットワーク内またはインターネット内のいずれか）のエンティティを指す。

ジェネレータ１４０は、モデルを実行時コンポーネントに変換する１つまたは複数のコンポーネントを表わす。一実施形態において、ジェネレータ１４０は単一のコンポーネントであり、代わりの実施形態において、ジェネレータ１４０は複数のコンポーネントである。

実行時コンポーネント１０４は、設計時コンポーネント１０２を用いてモデル化された項目のインスタンス生成（instantiation）を与え、オブジェクトインスタンスまたはサービスインスタンスが動作する各種フレームワークを含む。プロセスフレームワーク１５０は、１つまたは複数のプロセスのインスタンスを実行可能なフレームワークを表わす。例えば、プロセスフレームワーク１５０は、案内手順１５２、共通作業リスト１５４、および／またはワークフローインスタンス１５６を含むことが可能である。案内手順１５２は、上述した案内手順のインスタンスを表わす。共通作業リスト１５４は、ユーザに利用可能な全てのワークフローまたはプロセスの項目のリストを提供する。ワークフローまたはプロセスは、ワークフロー／プロセスにおいてユーザに要求されるオペレーションを通して、および／または、ワークフロー／プロセスに関して責任権限を有するユーザを通して、ユーザに利用可能とすることが可能である。共通作業リスト１５４は、利用可能な各プロセスについて作業センター（work center）にアクセスするために使用することが可能である。ワークフローインスタンス１５６は、ユーザに要求される作業を表わす１つまたは複数のワークフローの例を提供する。ワークフローはユーザのために１つまたは複数のアクションを実行させることが可能である。

ＵＩフレームワーク１６０は、データおよびプロセスについてのビューを表示する機能を提供する。一実施形態において、ＵＩフレームワーク１６０は、ユーザに表示または提示されるコンテンツの動的な管理を提供する（図示しない）ビューマネージャーを含む。ＵＩフレームワーク１６０はＵＩコンポーネント１６２を含み、ＵＩコンポーネント１６２はユーザ表示の１つまたは複数の要素を表わす。一実施形態において、ＵＩコンポーネント１６２は、他の環境を用いることも可能であるが、ウェブブラウザ内で表示を与えるための要素を含む。一実施形態において、別個のアプリケーションビューワを用いることが可能である。ＵＩパターン１６４は、ユーザインタフェースを表示するためのパターンおよび標準の要素を提供する。ＵＩパターン１６４はＵＩコンポーネント１６２を提供することが可能である。ＵＩパターン１６４は、ボタン、リンク、テキスト、等を提供するために各種コンポーネント１６２を有するテンプレートとすることが可能であり、生成される全てのアプリケーションに標準とするか、あるいは、インスタンス固有のデータを用いて部分的にカスタマイズすることが可能である。

一実施形態において、ＵＩフレームワーク１６０は動的ビュー１６６を含む。動的ビュー１６６は、１つまたは複数の動的コンポーネントを有するビューを表わし、ユーザに提供されるアプリケーションのコンテンツを変更することが可能である。動的ビュー１６６はユーザの権限に基づいてコンテンツを変更する。コンテンツは、人員構成の変更（例えば、転勤、昇進、退職）、および基礎を成すデータまたはサービスコンテンツの変更を反映して動的に変更することが可能である。

サービスフレームワーク１７０は、ユーザに利用可能なサービスを通してデータアクセスを実現する。ユーザは、１つまたは複数のエンティティサービス１７２、アプリケーションサービス１７４、ＪＡＶＡ（登録商標）データオブジェクト（ＪＤＯ）サービス１７６、および／または外部サービス１７８へのアクセスを有することが可能である。アプリケーションサービス１７４は、複合アプリケーションにローカルな、またはアプリケーションによって直接にアクセス可能なサービスを表わす。ＪＤＯ・１７６は企業基盤システム１８０のデータ１８２をアクセスすることが可能である。データ１８２は、任意の種類のオブジェクト、または、企業レベルの情報を記憶するオブジェクトリポジトリを表わす。また、企業基盤システム１８０は、１つまたは複数のリモートファンクションコール（ＲＦＣ）１８４および１つまたは複数のウェブサービス１８６を通してアクセスされるリモートファンクションを含むことが可能である。外部サービス１７８は遠隔要素（例えば、ＲＦＣ・１８４およびウェブサービス１８６）をアクセスする。企業基盤システム１８０は企業内の１つまたは複数のバックエンドシステムを表わし、１つまたは複数の他の別個のシステムにアクセス可能な共通バックエンドシステムを含むことが可能である。一実施形態において、企業基盤システム１８０はプロセスリポジトリ１８８を含み、プロセスリポジトリ１８８は、ビジネスプロセスを記憶する１つまたは複数のデータ記憶を表わす。プロセスリポジトリ１８８は、複数の別個のバックエンドシステムにアクセス可能なビジネスプロセスを記憶する共通ビジネスプロセス記憶として動作するメタリポジトリを含むことが可能である。

メタデータ１０６は、設計時コンポーネント１０２および実行時コンポーネント１０４によってアクセスされ、利用されることが可能な１つまたは複数のデータおよび／またはアクセス／サービスリソースの抽象化情報を表わす。メタデータ１０６はコンポーネントの１つの中のリソースである必要はなく、コンポーネントにのみ利用可能であると認識される必要はない。メタデータ１０６は、アプリケーション部分のモデル化および／または実行において使用するための、ビジネスオブジェクト、ビジネスサービス、ビジネスプロセス、および／または他のアプリケーション部分についてのメタデータを含むリポジトリを提供する。従って、アプリケーション部分は、データの出所とともに、ローカルデータベース、リモートデータベース、または２つの組み合わせのいずれかにおいてモデル化することが可能である。一実施形態において、メタデータ１０６のコンテンツは、アプリケーション部分の固有の実装を超えて拡張する情報を含む。固有の実装を記述するリポジトリが存在することが可能であり、より汎用的なリポジトリから書き込むことが可能である。メタデータ１０６は、汎用の、固有の、または組み合わせのリポジトリ情報を含むと理解することが可能である。

プロセス修正モジュール１９０は、複合アプリケーションフレームワーク１００を通してプロセス修正フレームワークを提供するモジュールまたはエージェントを表わす。プロセス修正モジュール１９０は、プロセスリポジトリ１８８内でのプロセスの発展を可能とするために１つまたは複数の修正手順のフェーズを管理することが可能である。

図２は、企業サービスアーキテクチャの実施形態のブロック図である。企業サービスアーキテクチャは、動的コンテンツビューを提供し、かつアクセスポータル２１０を通してアクセスを提供するアーキテクチャを提供する。アクセスポータル２１０は、企業にアクセス可能な任意の種類のネットワークポータルとすることが可能である。

図２のシステムは、複合アプリケーションとして結合される機能のための複数の種類の情報源を含むことが可能である。例示の目的のために、限定しないが、複合アプリケーションは、いくつかの機能の情報源からのコンポーネントを含むと考えられる。機能の異なる情報源の使用は、ここで説明される動的データビューの開発への要求条件として理解すべきではない。機能の潜在的な情報源の例は、モデル化プロセス２５０、従来型アプリケーション２６０、外部ファンクション２７０を含む。

モデル化プロセス２５０は、例えば、図１に示すフレームワークによるモデル化コンポーネントから生成される１つまたは複数のプロセスを含む。モデル化プロセス２５０はデータ２５８を含み、データ２５８はモデル化プロセス２５０のプロセスに関するデータを表わす。プロセスの１つの要素はフェーズ２５２であり、フェーズ２５２は、あるアクションまたは業務または案内手順を含むことが可能である。

従来型アプリケーション２６０は、より多くの従来型アプリケーションから生成された１つまたは複数のプロセスを含む。この場合において、より多くの従来型アプリケーションは、モデル化プロセス２５０と対照的にモデル化されていないアプリケーションである。従来型アプリケーション２６０は、モデル化され生成されるのではなく、サブシステムにわたって利用可能な標準コンポーネントに基づかない固有の機能またはサービスおよびデータを含むことが可能である。従来型アプリケーション２６０はデータ２６８を含み、データ２６８は従来型アプリケーション２６０のプロセスに関するデータを表わす。プロセスの１つの要素はフェーズ２６２であり、フェーズ２６２は動的複合ビューのために望ましい機能を含むことが可能である。従来型アプリケーション２６０およびモデル化プロセス２５０は、複合ビューがインスタンス生成（instantiate）される基礎を成すフレームワークおよびシステムを認識することが可能である。従って、フェーズ２５２および２６２はコンテキストを認識することが可能である。

外部ファンクション２７０は、企業システムの環境の外部で利用可能な１つまたは複数のプロセスを含む。例えば、外部ファンクション２７０は、企業システムに関してサードパーティであるプログラムから利用可能なファンクションを表わし得る。外部ファンクション２７０は、アクセスされ実行されるリモートファンクションとすることが可能である。フェーズ２７２および２７４は、複合アプリケーションのために望ましい外部ファンクション２７０のプロセスのフェーズを表わす。外部ファンクション２７０からコンポーネントに持ち込むときにメタデータを含めることが可能であり、メタデータは外部機能を組み込むためにラッパー（wrapper）としての役割を果たすことが可能である。

サービス２８０は、サービスを複合プロセスに提供することが可能な１つまたは複数のサービスを表わす。サービス２８０はサービス２８２を含み、サービス２８２は、複合アプリケーションの複合プロセスに組み込まれるサービスを提供する。オブジェクトはサービス２８０を通して利用可能である。

選択されたプロセスのフェーズおよびサービスは、複合アプリケーションフレームワーク２４０を通して企業サービスアーキテクチャ２３０に取り込まれる。複合アプリケーションフレームワーク２４０は、図１の複合アプリケーションフレームワーク１００の実施形態によるフレームワークである。また、プロセスのフェーズは、既存プロセスから取り込まれないフレームワーク内で生成することが可能である。例えば、複合アプリケーションフレームワークは、複合アプリケーションプロセスの要素としてフェーズ２４２をモデル化することが可能である。複合アプリケーションのために選択された各々のフェーズおよびサービスは複合アプリケーション２２０を生成するために結合され、複合アプリケーション２２０は各種の選択された要素から生成された複合プロセス２２２を含む。すなわち、フェーズ２５２、２４２、２６２、２７２、２７４は、アクセスポータル２１０を通してユーザにアクセス可能な複合プロセス２２２を構成するために結合される。

一実施形態において、図２のシステムは、複数のビジネスプロセスリポジトリ（ＢＰＲ）２９２〜２９６、または複数のＢＰＲ情報源からのビジネスプロセスを含むことが可能なメタリポジトリ２９０を含む。メタリポジトリ２９０は、ビジネスプロセスで使用されるビジネスプロセスおよび／またはコンポーネントオブジェクトの１つまたは複数のリポジトリまたはギャラリー（gallery）を提供し、ビジネスプロセスは複合アプリケーション２２０によって実行することが可能である。メタリポジトリ２９０は、複数の異種のバックエンドシステムにアクセス可能なビジネスプロセスにアクセスするための共通リポジトリを提供する。プロセス修正モジュール２９８は、メタリポジトリ２９０内に記憶されるビジネスプロセスを修正するために修正フレームワークおよびロジックを提供する。一実施形態において、プロセス修正モジュール２９８は、さらに、アドホックワークフローの生成、および、ビジネスプロセステンプレートとしてのアドホックワークフローの保存を可能とする１つまたは複数のメカニズムを含むことが可能である。

図３は、システムアーキテクチャの実施形態のブロック図である。フロントエンド３１０は、対応付けられた機器において実行される、ここで説明される任意の実施形態による複合アプリケーションまたは複合ビューを表示する機器および／または対応付けられたユーザインタフェースの例である。フロントエンド３１０は、バックエンドシステムの相互機能（cross-functional）コンポーネントへのアクセスを提供するためにサービス指向アーキテクチャを用いて生成される。フロントエンド３１０は、コンテキストのビューを有する複合アプリケーション３１２を含み、コンテキストのビューは、アクセスされる基礎を成すシステムコンポーネントの変更に応じてコンテンツを変化させ、複合アプリケーションにアクセスするために使用される異なるアクセス許可に応じてコンテンツを変化させる動的ビューを表わす。複合アプリケーション３１２は、ロール、作業センター、複合アプリケーションに固有のユーザインタフェース等を含む。動的ビューに関して、特定の権限を有するユーザによる呼び出しに応答して、複合アプリケーション３１２は、あるコンテンツを表示することが可能である。異なる権限を有する異なるユーザ、または、異なる権限を有する同一のユーザによる呼び出しに応答して、異なるコンテンツが表示され、または異なるアクセスを許容することが可能である。

フロントエンド３１０は複合アプリケーションオブジェクト３２０を含み、複合アプリケーションオブジェクト３２０はフロントエンド３１０に関するオブジェクトを表わす。複合アプリケーションオブジェクト３２０はステータス／アクション管理３２２を含み、ステータス／アクション管理３２２は複合アプリケーションオブジェクト３２０を追跡するために使用することが可能である。ステータス／アクション管理３２２はオブジェクトの振る舞いを管理し、複合アプリケーションオブジェクト３２０のインスタンスと企業プラットフォーム３３０との間の整合性を与えることが可能である。一実施形態において、ステータス／アクション管理３２２は複合アプリケーション３１２のコンテキストに影響を与える。一実施形態において、複合アプリケーションオブジェクト３２０は、対応付けられたプロセスエージェント３８０を有し、プロセスエージェント３８０はオブジェクト３２０への入力およびオブジェクト３２０からの出力を提供する。一実施形態において、プロセスエージェント３８０は複数のエージェントエンティティを含み、入力エージェントおよび出力エージェントとすることが可能である。さらに、プロセスエージェント３８０は、複合アプリケーションオブジェクト３２０への問合せまたは複合アプリケーションオブジェクト３２０からの要求を提供することが可能である。

一実施形態において、フロントエンド３１０の各オブジェクトは個々のエージェントを有する。もう１つの実施形態において、プロセスエージェント３８０はフロントエンド３１０と対応付けられ、フロントエンド３１０内で複数のオブジェクトインスタンスのためのサービスを提供する。プロセスエージェント３８０は、以下で説明される情報管理３７２に関連性データを提供することが可能である。プロセスエージェント３８０はコントローラ３８２を含み、コントローラ３８２はオブジェクト３２０のための入力制御および／または出力制御を表わす。一実施形態において、プロセスエージェント３８０はモデル化され、コントローラ３８２は、基礎を成す企業システム内のビジネスプロセスのための標準であるアプリケーションプログラムインタフェース（ＡＰＩ）を含む。オブジェクト３２０はコントローラ３８２を通して企業バックエンドにインタフェースする。コントローラ３８２を通して、標準の同期された相互作用が提供される。複合アプリケーション３１２がオンラインで実行されるとき、コントローラ３８２は一般にオブジェクト３２０へのインタフェースを提供すると考えることができる。プロセスエージェント３８０は非同期制御３８４を含み、非同期制御３８４は、複合アプリケーション３２０がオフラインで使用され、企業バックエンドと同期されることを可能とする制御を表わす。従って、バックエンドに接続されたオブジェクト３２０を保持する同期通信に対して、非同期制御３８４は、オブジェクト３２０が、オフラインで使用後にバックエンドと同期することを可能とする。パーシステンス３８６は、オブジェクト３２０とバックエンドとの間の接続の履歴を提供する。パーシステンス３８６は、複合アプリケーション３１２が、コンテキストに基づいて適応するビューを提供することを可能とする。

企業プラットフォーム３３０は複数のオブジェクト３４０および３５０を有することが可能であり、各々はインタフェースエージェント、具体的には、それぞれインタフェースエージェント３４４および３５４を有することが可能である。エージェントを通して、オブジェクト３４０および３５０は企業プラットフォーム３３０の他のコンポーネントをアクセスし、他のコンポーネントによってアクセスされることが可能である。また、オブジェクト３４０および３５０は、それぞれステータス／アクション管理３４２および３５２を含む。オブジェクト３４０および３５０は、フロンドエンド３１０において特定のインスタンスが生成されることが可能なオブジェクトを表わす。

企業プラットフォーム３３０はバックエンド３６０を含み、バックエンド３６０は企業のためにバックエンドコンポーネントを提供する。バックエンド３６０はビジネスロジックおよび企業のアクセス可能性を提供する。バックエンド３６０はフレームワーク３６２を含み、フレームワーク３６２は、複合アプリケーション３１２を生成するフレームワークを提供する、ここで説明される複合アプリケーションフレームワークとすることが可能である。エンジンサービス３６４は、複合アプリケーション３１２を生成するために影響が与えられるバックエンドサービスを提供する。従属オブジェクト３６６およびマスタデータオブジェクト３６８は、バックエンド３６０において利用可能なオブジェクトの種類を表わす。

また、企業プラットフォーム３３０は情報管理３７２を有する企業サーバ３７０を含み、情報管理３７２は分析、調査、タスク、マスタデータ、等を含む、管理ファンクションを提供する。一実施形態において、情報管理３７２はプロセス管理モジュール３７４を含み、プロセス管理モジュール３７４は、プロセス修正モジュール、リポジトリマネージャー、および／または、ビジネスプロセステンプレートとしてアドホックワークフローを記憶するマネージャーを含む１つまたは複数のコンポーネントを含むことが可能である。

図４は、アプリケーションコンテンツマネージャーを有するユーザ機器の実施形態のブロック図である。ユーザ機器４１０は、ユーザが企業にアクセスするコンピュータ機器を表わす。ユーザ機器４１０は複合アプリケーション４２０を含み、複合アプリケーション４２０は、ビジネスプロセスにおいて動作し、ビジネスプロセスのフェーズのアクションに関する作業を実行するために使用することが可能なモデル化されたソフトウェアを表わす。ここで用いられるビジネスプロセスのフェーズは、プロセスオブジェクトを意味し、プロセスオブジェクトは、プロセスの特定のフェーズと対応付けられた１つまたは複数のアクションを表わす。複合アプリケーション４２０は任意の数のビジネスプロセス４２２〜４２４を含むことが可能である。一実施形態において、１つまたは複数のビジネスプロセス４２２〜４２４は、ビジネスプロセスのメタリポジトリから検索される。一実施形態において、ビジネスプロセス４２２〜４２４のうちの１つまたは複数は、評価のためにプロセス修正フレームワークに提供することが可能な、修正または提案されたビジネスプロセスを表わす。

一実施形態において、ユーザ機器４１０はビジネスプロセス（ＢＰ）修正モジュール４１２を含み、ＢＰ修正モジュール４１２は、ビジネスプロセスの修正または記憶管理に関するファンクションを提供することが可能な１つまたは複数のモジュールを表わす。ＢＰ修正モジュール４１２は、ビジネスプロセスの修正に影響を与える修正提案を受信する１つまたは複数のメカニズムであるか、または１つまたは複数のメカニズムを含むことが可能である。上述したように、修正は増分的であり、修正されたビジネスプロセスが実装され、成果が評価されることが可能である。ＢＰ修正モジュール４１２は、ビジネスプロセスが可搬性のあることを可能とするためにプロセスオブジェクトにプロセスロジックを結びつける１つまたは複数のメカニズムであるか、または１つまたは複数のメカニズムを含むことが可能である。可搬性のあるビジネスプロセスは、複数のバックエンドシステムの中で再利用のために利用可能な単一のリポジトリに記憶することが可能である。ＢＰ修正モジュール４１２はユーザ機器４１０内で実行／常駐することが可能なコンポーネントを表わす。サーバ４５０のＢＰ修正モジュール４５４として示すように、異なる、追加の、および／または相補的なコンポーネントが企業内に存在することが可能である。

企業サービスインタフェース４３０は、ユーザ機器４１０からネットワークおよび基礎を成す企業システムへのアクセスを提供する１つまたは複数のコンポーネントを表わす。また、企業サービスインタフェース４３０は、ネットワーク４４０にアクセスするためのポータルを含むことが可能である。ネットワーク４４０は任意の種類のネットワークを含み、ハードウェアおよびソフトウェアの両方またはユーザ機器４１０がサーバ４５０にアクセスするネットワークプロトコルを表わす。ネットワーク４４０は、ローカルエリアネットワーク（ＬＡＮ）、無線ＬＡＮ（ＷＬＡＮ）、仮想プライベートネットワーク（ＶＰＮ）、仮想ＬＡＮ（ＶＬＡＮ）、広域ネットワーク（インターネットを含む）、等を含むことが可能である。

サーバ４５０は複合アプリケーションを開発するフレームワーク４５２を含む。フレームワーク４５２は、図１の複合アプリケーションフレームワーク１００の一例を与える。サーバ４５０は企業サーバであり、１つまたは複数のサービス４６０へのアクセスを提供し、サービス４６０は複合アプリケーション４２０に組み込まれ、企業データ４７０の１つまたは複数の要素へのアクセスを提供することが可能である。企業データ４７０は任意の種類のデータまたは情報を含むことが可能であり、例えば、拡張マークアップ言語（ＸＭＬ）データ、企業資源計画データベース（ＥＲＰ ＤＢ）４７４、または他のデータ４７６を含むことが可能である。

一実施形態において、サーバ４５０はＢＰ修正モジュール４５４を含み、ＢＰ修正モジュール４５４は、企業レベルにおいて常駐／実行する修正モジュールの１つまたは複数のコンポーネントを表わす。コンポーネントはＢＰ修正モジュール４１２から分離することが可能である。一実施形態において、ＢＰ修正モジュール４５４および４１２は、ビジネスプロセスを修正し、提案された修正を評価するためのフレームワークおよびメカニズムを提供する協業要素である。例えば、ＢＰ修正モジュール４１２は、提案プロセスおよび修正生成プロセスを通してユーザを促すエージェントまたはスタブを含むことが可能である。ＢＰ修正モジュール４５４は、提案を受信し、提案における処理を実行することが可能である。一実施形態において、ＢＰ修正モジュール４５４は、修正プロセスに含まれ得る各種の作用主体についてのワークフローを生成し、修正プロセスに関するタスク、作業リスト項目、データ、等を送信する。ワークフローの生成は、ＢＰ修正モジュール４５４が、含まれ得る作用主体を決定することを可能とするコンテキストとすることが可能である。例えば、ＢＰ修正モジュール４５４は、プロセスの所有者および／または特定のプロセス提案を評価すべき審査グループを決定することが可能である。一実施形態において、ＢＰ修正モジュール４１２は、ユーザ機器が、提案者、審査者、ビジネスプロセス所有者、等と対応付けられているか否かについて、ユーザ機器４１０がビジネスプロセスの修正と対応付けられた情報を受信することを可能とする１つまたは複数のメカニズムを含む。従って、例えば、ワークフローの受信に応答して実行されるアクションは、修正フレームワークに結びつけ、プロセス修正の開発に影響を与えることが可能である。

図５は、プロセス発展モジュールの実施形態のブロック図である。プロセス発展モジュール５００は制御ロジック５０２を含み、制御ロジック５０２は、プロセス発展モジュール５００のオペレーションを管理するための論理的、機能的な制御、および／またはプロセス発展モジュール５００のオペレーションの管理と対応付けられたハードウェアを実装する。ロジックは、ハードウェア論理回路および／またはソフトウェアルーチンとすることが可能である。一実施形態において、プロセス発展モジュール５００は１つまたは複数のアプリケーション５０４を含み、アプリケーション５０４は、コード列および／または制御ロジック５０２に命令を与えるプログラムを表わす。プロセス発展モジュール５００はメモリ５０６を含み、メモリ５０６は、データおよび／または命令を記憶するためのメモリ装置および／またはメモリ資源へのアクセスを表わす。メモリ５０６は、プロセス発展モジュール５００が常駐するホストシステムのメモリを含むとともに、または、それに代えて、プロセス発展モジュール５００にローカルなメモリを含むことが可能である。また、プロセス発展モジュール５００は１つまたは複数のインタフェース５０８を含み、インタフェース５０８は、プロセス発展モジュール５００の外部の（電子的な、または人間の）エンティティに関して、プロセス発展モジュール５００への、または、プロセス発展モジュール５００からのアクセスインタフェース（入力／出力インタフェース）を表わす。インタフェース５０８は、プロセス発展モジュール５００をホストアプリケーションに組み込むことが可能なメカニズムを含み、プロセス発展モジュール５００から、ホストアプリケーションが実行されるシステムの他のコンポーネントまたはアプリケーションへのインタフェースをさらに含むことが可能である。

また、プロセス発展モジュール５００はフレームワーク修正エンジン５１０を含み、フレームワーク修正エンジン５１０は、プロセス発展モジュール５００が、動的なプロセスの修正を提供することを可能とする１つまたは複数のファンクションを表わす。ファンクションまたは機能は、変更提案モジュール５２０、評価モジュール５３０、配備モジュール５４０、報償モジュール５５０のうちの１つまたは複数を含み、または、これらのうちの１つまたは複数によって提供される。これらのモジュールの各々は、他のファンクションを提供する他のモジュールをさらに含むことが可能である。ここで用いられるモジュールは、ハードウェア、ソフトウェア、または組み合わせのいずれかにおいて実現されるルーチン、サブシステム、等を意味する。

変更提案モジュール５２０は、プロセス発展モジュール５００がビジネスプロセスの修正のための提案を受信することを可能とする。変更提案モジュール５２０は受信部５２２を含み、受信部５２２は、提案を修正フレームワークに入力するためのメカニズムを表わす。提案は、任意の各種の情報源から受信することが可能であり、各種の情報源は“提案者”と呼ばれる。一実施形態において、ユーザがボタンを選択し、または領域に入力し、提案を与えることが可能な特定のユーザインタフェースがシステム内に設けられる。もう１つの実施形態において、ユーザは、ユーザが作業している機器にローカルにビジネスプロセスを生成または編集することが可能であり、変更提案モジュール５２０は、バックエンド企業システムによるビジネスプロセスの修正提案として作業が受信されるべきか否かをユーザに促すロジックを提供する。また、ユーザがプロセスオブジェクトのインスタンスを修正することが可能な複合アプリケーションにおいて編集オプションを利用可能とすることによって変更の提案を受信することが可能である。プロセスオブジェクトの修正は、システムに、ビジネスプロセスへの変更が提案されていることを示すことが可能である。

ビジネスプロセスの修正が企業システム内の基礎を成すビジネスプロセスを変更する提案であることを示されるとき、受信部５２２を呼び出すことが可能である。受信部５２２は、ビジネスプロセスの変更の特定の詳細が提供されることを要求することが可能である。例えば、ユーザは、変更されたプロセスについての使用条件を提供し、修正されたビジネスプロセスが最良の実務を表わし得るときを示し、予期される結果を宣言し、プロセスの検査または監視のための規則を示す、等が可能である。一実施形態において、提案者は受信部５２２を通して、結果についての予測とともにビジネスプロセスの評価のための統計モデルを提供する。受信部５２２は、入力および／または出力パラメータを（例えば、ユーザインタフェースにおける特定のフィールドまたは選択領域／プルダウン領域を通して）受信するよう促すことが可能であり、またはそうでなければ受信するメカニズムを有することが可能である。

評価モジュール５３０は、提案された修正に基づいてビジネスプロセスを配備する前に、プロセス発展モジュール５００が修正を評価および検査することを可能とする。評価モジュール５３０はアクセス所有者モジュール５３２を含み、アクセス所有者モジュール５３２は、提案を適用するビジネスプロセスの所有者が誰であるかを判定する機能を提供する。ビジネスプロセス所有者（ＢＰＯ（Business Process Owner）とも呼ぶ）はビジネスプロセスに責任を持つ。従って、ビジネスプロセスの最終的な変更の前に、ＢＰＯによって修正提案が承認されるべきである。一人より多くの個人がビジネスプロセスへの変更を承認する権限を有することが可能である。アクセス所有者モジュール５３２は、提案者による直接の表示を通して、またはビジネスプロセスと対応付けられた識別子によって、ＢＰＯを識別することが可能である。例えば、メタデータは、特定のプロセスを所有する個人または役職を示すことが可能である。一実施形態において、ビジネスプロセスは特定のグループまたは部門によって所有することが可能であり、アクセス所有者モジュール５３２は、ビジネスプロセス所有者としてグループの長を特定することが可能である。ビジネスプロセス所有者は、より詳細な検査に進めるか否かを判定する提案の最初の評価を提供することが可能である。例えば、方法論が評価され、仮定が検査される、等が可能である。評価は、結果として、修正の拒否、修正の承認、または提案の修正になり得る。提案の編集は、提案者に戻され、提案が最終的に承認または拒否されるまでプロセスが継続されることが可能である。

評価は、個人または委員会／グループによって実行することが可能である。一実施形態において、“専門家”または関連する経験／知識を有する個人は、提案を評価する。評価は、組織の内部または外部において利用可能な情報に対して、提案を調査することを含み得る。評価は、提案の承認または拒否のいずれかについて投票することによって行うことが可能である。一実施形態において、アクセス所有者モジュール５３２は、審査のためのチームを編成し、そのチームは、同僚、中心グループのメンバー、顧客、供給業者、専門家グループ（内部または外部の、例えば、コンサルタント）、政府の役人、システムインテグレータ、ビジネスプロセスベンダー、他社、等を含む個人を含むことが可能である。

評価モジュール５３０は動作割当モジュール５３４を含み、動作割当モジュール５３４は、ビジネスプロセスの特定の予期される動作について識別および検査する機能を提供する。例えば、受信部５２２は、予期される結果を示す入力パラメータとともにビジネスプロセスの修正のための提案を受信することが可能である。動作割当モジュール５３４は、予期される結果に対して結果を検査することによって、検査が、ビジネスプロセスについて成功の結果となったか、または、不成功の結果となったかを判定するための予期される結果パラメータを使用することが可能である。動作割当モジュール５３４は、予期される結果を与える結果ギャラリーを含みおよび／またはアクセスすることが可能である。一実施形態において、動作割当モジュール５３４は、ユーザが動作割当モジュール５３４に予期される結果を示すことが可能な予期される結果ギャラリーへのアクセスをユーザに単に提供する。動作割当モジュール５３４は、シミュレーションまたは検査のために提案をモデル化することを含むことが可能である。モデル化および結果ギャラリーは、以下で、より詳細に説明される。

また、評価モジュール５３０は検査モジュール５３６を含み、検査モジュール５３６は、一般に、提案の動作を検査（例えば、シミュレーション）するために使用することが可能な１つまたは複数のメカニズムを表わす。検査モジュール５３６は、シミュレーション結果を記憶および評価する場所を提供することが可能である。検査モジュール５３６は、実行される検査に重要な入力パラメータを受信し、その入力パラメータは提案において示されるパラメータとともに、検査するために直接に入力されるパラメータを含むことが可能である。一実施形態において、検査は、例えば、検査グループに対してビジネスプロセスの試行として実行される。検査および検査者は選択され、結果が予測されることが可能である。一実施形態において、検査モジュール５３６には１つまたは複数の閾値（例えば、時間、ユーザ数、特定の結果、等）が設けられる。その閾値を用いて、検査モジュール５３６は、閾値が達成されると、検査を終了し、または検査をもう１つのレベルに進め、または自動的により大きい規模にプロセスを配備し、または他のアクションを実行するように動作することが可能である。

検査は、検査配備を有する特定のグループに対してパイロットとして実行することが可能であり、その検査は、以前のビジネスプロセスを用いる管理グループと並行して実行することが可能であり、または、以前のビジネスプロセスおよび提案のビジネスプロセスの両方を並行して検査グループに実行させる。結果はビジネスプロセス所有者に戻すことが可能であり、分析手段（例えば、“撃ち放し式（fire and forget）”の検査）を用いて評価することが可能である。ビジネスプロセス検査は、中央の検査システムを用いて、例えば、案内スクリプトの生成を用いて実行することができる。

配備モジュール５４０は、プロセス評価モジュール５００が、提案されたビジネスプロセスの変更を配備および監視することを可能とする。配備は、ビジネスプロセス（例えば、ソフトウェア）のインストールを提供する。一実施形態において、配備は、前進的に（例えば、まず、特定のグループに対して、次に、もう１つのグループに対して、等）実行することが可能である。配備モジュール５４０はリポジトリ更新モジュール５４２を含み、リポジトリ更新モジュール５４２はビジネスプロセスリポジトリを更新する機能を提供する。ビジネスプロセスに提案された変更を行うことが可能であり、修正されたビジネスプロセスが生成される。修正されたビジネスプロセスは、一般には利用可能でない検査プロセスとして記憶することが可能であり、検査目的のために利用可能な記憶場所に局所的にのみ記憶することが可能である。配備のために、修正されたビジネスプロセスは、利用可能なビジネスプロセスのリポジトリに記憶することが可能である。１つの実装において、修正されたビジネスプロセスは、複数のバックエンドシステムにわたって利用可能なビジネスプロセスの共有記憶を提供するメタリポジトリに記憶される。リポジトリを更新することは、変更を取り込む、新たなプロセスを指し示す等のために、単にプロセスオブジェクトを修正することを含むことが可能である。

配備モジュール５４０は、所望の結果が達成されたか否かを判定するために、プロセスを追跡する機能を提供するためのプロセス監視モジュール５４４を含む。プロセス監視モジュール５４４は、ある結果が達成されたか否かを示すこと、例えば、配備の次のフェーズがロールアウトされるべきであることを示すことが可能である。一実施形態において、配備は、（例えば、複数のフェーズに変更が行われるならば、）ある時間において全体のプロセスの単一のフェーズによって実行される。配備がフェーズの１つについて成功したならば、もう１つのフェーズを配備することが可能である。また、ビジネスプロセスのユーザの基盤システムは、完全に配備されるまで、徐々に増加されることが可能である。

プロセス監視モジュール５４４は、予期される結果から実際の成果における変動（例えば、予期されるより長くかかっているフェーズ、予期しない時期であるが適切な結果、より早期のまたは遅延したフェーズ、予期しない費用、等）を検出することが可能である。プロセス監視モジュール５４４は、全ての結果、または、ビジネスプロセス所有者への整理された報告を提供するメカニズムを含むことが可能である。一実施形態において、監視のために発見的なアルゴリズムを利用するビジネスプロセスにおいて、自己適合ファンクションが用いられる。従って、良好な結果を発見するために、ファンクションのパラメータについての異なる可能な変形を試みることが可能である。プロセス監視モジュール５４４は、予期される結果からの特定の逸脱が、ビジネスプロセスのさらなる修正とともに取り組むべき課題を示すことを判定するためのロジックおよび／または分析手段を含むことが可能である。一実施形態において、特定の成果が、予期される結果からのかなりの逸脱を示すとき警告が引きこされることが可能である。この警告は結果として、オペレータへの訓練を与える、機械を修理する、管理を審査する、プロセスを撤回する、プロセスを拡大する、等の他のプロセスの実行となり得る。警告は、課題を解決するために実行することが可能な潜在的なプロセスに沿ってビジネスプロセス所有者に与えることが可能である。監視が（例えば、特定の期間、特定の試行回数、等のための）特定のパラメータにおいて成功であるならば、ビジネスプロセスは恒久的としてマークを付与することが可能である。一実施形態において、マークの付与は、プロセスについてのメタデータとして含まれるＸＭＬ（拡張マークアップ言語）タグである。リポジトリ更新モジュール５４２は、プロセスにマークを付与し、プロセスを共通リポジトリに移動し、“恒久的でない”タグを恒久的に変更し、プロセスの成功を示すもう１つのアクションを実行することが可能である。一実施形態において、ビジネスプロセスの監視は、ビジネスプロセスの耐用期間について継続する。

一実施形態において、プロセス監視モジュール５４４は、ビジネスプロセスが予期されたように実行されていない、またはある要求条件の下に低下していることを判定し、プロセスが中断されるべきであることを撤回モジュール５４６に示すことが可能である。撤回モジュール５４６は、ビジネスプロセスをオペレーションから除去し、システムを以前の状態（すなわち、提案され修正されたプロセスの以前の配備）に戻すことによって、配備と異なるオペレーションを実行することが可能である。撤回プロセスは、配備プロセスが確立されると同時に確立することが可能である。従って、配備からビジネスプロセスを除去することは、アドホックなオペレーションとして発生しない。一実施形態において、撤回は、既に配備されたインスタンスを単に停止することより多くを含む。例えば、ビジネスプロセスの使用における条件が設けられ、ユーザはビジネスプロセスの停止が通知される、等である。

フレームワーク修正エンジン５１０によって提供される変更管理プロセスは、フェーズの１つまたは複数を複数回繰り返すことが可能な繰り返しプロセスである。所望の成果が達成されるか、またはプロセスが拒否されるまで、変更が提案され、評価、検査、および可能な配備とともに提案への修正が行われることが可能である。

報償モジュール５５０は、プロセス評価モジュール５００が変更管理プロセスにおける参加者に報償を与えることを可能とする。報償は、組織によって望まれる任意のモデルに従って構成することが可能である。報償は、組織の全体の成果を向上させることにおいて参加者を奨励するために運用することが可能である。報償モジュール５５０は、選択された報償モデルまたは基準に従って動作することが可能である。例えば、報償モジュール５５０は、修正フレームワーク内で１つまたは複数のイベントの完了（修正提案の承認、成功した検査、配備、等）において報償を与えるように設計することが可能である。プロセスの各ステージは報償を与えられることが可能であり、報償は成功した配備の最後に与えられることが可能である。

一実施形態において、報償モジュール５５０は報償をモデル化するソフトウェアを含む。例えば、報償はプロセスの結果との関係を有することが可能である。例えば、ある結果はある報償に対応することが可能である。ある一定量の報償が、プロセスの各マイルストーンについて提供される（例えば、各々の次のフェーズへの進行について等しい報償が与えられる）ことが可能であり、または、報償を段階分けする（すなわち、プロセスを通して提案がさらに進行するに連れて、報償がより高い増分で増加する）ことが可能である。報償は、金銭による、または金銭によらないことが可能であり、抽選に基づく（何かを獲得するために抽選に参加する）ことが可能である。提案についての報償に加えて、報償はプロセス（例えば、審査または評価）における参加者のためにも提供することが可能である。報償モジュール５５０は、行われた参加についての個々の報償を通知する通知メカニズムを含むことが可能である。

プロセス発展モジュール５００は、リポジトリ５６０に結合することが可能である。結合は、電気的、機械的、および／または通信の接続を提供するものと理解することができる。リポジトリ５６０はビジネスプロセス５６２および５６４を含み、ビジネスプロセス５６２および５６４は、それぞれ、異なる情報源５７０および５８０から得ることが可能である。ビジネスプロセス５６２〜５６４は、上述したように、プロセス発展モジュール５００によって動作させることが可能なビジネスプロセスの例を表わす。従って、ビジネスプロセスの一方または両方の修正は、上述したように実行することが可能である。一実施形態において、リポジトリ５６０は、複数の情報源からのプロセスを記憶し、プロセスを複数の情報源（例えば、バックエンドシステム）に利用可能とするメタリポジトリである。一実施形態において、ビジネスプロセス５６２〜５６４のうちの１つまたは複数は、アドホックワークフローとして生成される。アドホックワークフローは、複数のシステムにおいて再利用可能なテンプレートの可搬性のあるビジネスプロセスとしてワークフローをモデル化することによってビジネスプロセスについてのテンプレートとして記憶することが可能である。従って、共通バックエンドシステムの外部で生成されたプロセスは、組織の中心的なシステムにおいて利用可能なビジネスプロセスとして共通バックエンドに結合することが可能である。

プロセス発展モジュール５００は、ビジネスプロセスにおいて動作する（モデル化されたソフトウェアである）複合アプリケーション５９０に結合することが可能である。一実施形態において、複合アプリケーション５９０は、ここで説明される修正フレームワークによって実行される変更管理と対応付けられた１つまたは複数のオペレーションを実行するモデル化されたソフトウェアを表わす。

プロセス発展モジュール５００は、ハードウェア、ソフトウェア、および／またはこれらの組み合わせを含むことが可能である。プロセス発展モジュール５００またはその構成要素がソフトウェアを含む場合、機械／電子機器／ハードウェアによる製品によってソフトウェアデータ、命令、および／または設定を提供することが可能である。製品は、命令、データ、等を提供するためのコンテンツを有する機械読み取り可能な媒体を含むことが可能である。コンテンツは、結果として、ここで説明された各種の動作または処理を実行する電子機器となることが可能である。読み取り可能、アクセス可能な媒体は、機械（例えば、コンピューティング機器、電子機器、電子システム／サブシステム、等）によってアクセス可能な形態において情報／コンテンツを提供する（すなわち、記憶および／または送信する）任意のメカニズムを含む。例えば、機械読み取り可能な媒体は、記録可能な／記録可能でない媒体（例えば、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、等）を含む。機械読み取り可能な媒体は、電子機器が動作しているときに実行される記憶装置にロードされるコードを有する電子機器をさらに含むことが可能である。従って、そのようなコードとともに電子機器を供給することは、ここで説明されたようなコンテンツとともに製品を提供することとして理解することが可能である。さらに、データベースまたは他の記憶場所にコードを記憶すること、および通信媒体を介したダウンロードのためにコードを提供することは、ここで説明されたようなコンテンツとともに製品を提供することとして理解することが可能である。

図６は、プロセス修正モジュールおよびメタリポジトリを有するネットワークの実施形態のブロック図である。システム６００は、ここで説明されたようなビジネスプロセスの修正を実行するための構成要素を含むシステムの例を与える。提案者６１０は、既存のビジネスプロセスに修正を提案する提案の情報源を表わす。提案は、１つまたは複数のプロセスオブジェクトまたはビジネスプロセスのフェーズの変更、および／または、他のプロセスの追加、他のフェーズの追加、等を含むことが可能である。提案者６１０はユーザインタフェース（ＵＩ）フレームワークアクセス６１２を含み、ＵＩフレームワークアクセス６１２は、提案者が修正フレームワーク（フレームワーク６２２）へのアクセスを取得する１つまたは複数のメカニズムを表わす。一実施形態において、ＵＩフレームワークアクセス６１２は、ユーザが提案を与えることが可能な案内手順を提供するモデル化されたソフトウェアを含むことが可能である。

提案者６１０はネットワーク６３０を介して修正フレームワークにアクセスし、ネットワーク６３０は、任意の各種のネットワークまたはネットワークのいつくかの組み合わせを表わす。ネットワーク６３０は、１つまたは複数のネットワーク（例えば、ローカルエリアネットワーク（ＬＡＮ）、仮想ＬＡＮ（ＶＬＡＮ）、仮想プライベートネットワーク（ＶＰＮ）、無線ＬＡＮ（ＷＬＡＮ）、等）と対応付けられたハードウェアまたはソフトウェアを含む。プロセス発展モジュール６２０はネットワーク６３０を介してアクセス可能である。一実施形態において、プロセス発展モジュール６２０は、ネットワーク６３０の企業サーバに常駐する。

また、ネットワーク６３０を介して、提案者６１０およびプロセス発展モジュール６２０は、ビジネスプロセス所有者（ＢＰＯ）６３０にアクセスすることが可能であり、ＢＰＯ・６３０は、ビジネスプロセスに関する所有者の役割を有する１つまたは複数の個人を表わす。ＢＰＯ・６３０以外の審査者が変更の提案の審査／評価を提供するために用いられる実装において、審査者６４０はネットワーク６３０に結合される。ＢＰＯ・６３０および審査者６４０は、それぞれＵＩフレームワークアクセス６３２および６４２を含む。ＵＩフレームワークアクセス６３２〜６４２は、ＢＰＯおよび審査者がフレームワーク６２２にアクセスすることを可能とするために、ＵＩフレームワークアクセス６１２と同様とすることが可能である。ＢＰＯ・６３０は提案、検査、等の審査を提供するとともに、プロセス発展モジュール６２０からの提案を受信するためにＵＩフレームワーク６３２を利用することが可能である。また、ＵＩフレームワークアクセスを通して、ＢＰＯ・６３０は、変更管理の検査および／または配備フェーズにおいてビジネスプロセスへのアクセスを有する。

メタリポジトリ６５０はネットワーク６３０に結合され、メタリポジトリ６５０は、情報源６６０から利用可能なプロセス６５２、および情報源６７０から利用可能なアドホックテンプレート６５４を含む。一実施形態において、提案者６１０は、既存のプロセスに追加する、または既存のビジネスプロセスの一部または全部を置換するために、提案されたビジネスプロセスの修正としてアドホックテンプレート６５４またはプロセス６５２を提供する。

システム６００は検査エージェント６８０および／または監視エージェント６９０を含み、検査エージェント６８０および／または監視エージェント６９０は、ビジネスプロセス修正フレームワークと対応付けられたプロセスの要素とすることが可能である。検査エージェント６８０は、提案されたビジネスプロセスの修正の検査（例えば、モデル化およびシミュレーション）を実行する機能を提供する。一実施形態において、検査エージェント６８０は、検査に範囲を与える。例えば、ある条件（例えば、ある結果の達成、ある検査期間、または他の条件の失敗）の下で、検査エージェント６８０は、提案された修正に関する判断（例えば、拒否、審査の次の段階についての承認）を自動的に実行することが可能である。検査エージェント６８０は、パラメータとして、提案者および／またはＢＰＯによって確立されたモデルおよび／または条件を受信する。

監視エージェント６９０は、配備されたビジネスプロセスの修正を監視する。ビジネスプロセスの修正が評価および承認されると、それは配備することが可能である。配備されたビジネスプロセスは、配備の後、適切な成果のために監視される。一実施形態において、監視エージェント６９０は、ビジネスプロセスの実際の成果について検査される成果の範囲を含む。例えば、ある条件の下で、警告が生成され、報償が生成され、配備の次の段階が開始される、等が可能である。監視エージェント６９０は修正され配備されたビジネスプロセスの予期される動作を示す入力パラメータを受信する。成果を評価するために監視エージェント６９０によって発見的アルゴリズムを使用することが可能である。

システム６０２は複数のバックエンドシステム６０２〜６０４を含むことが可能であり、バックエンドシステム６０２〜６０４は前述したバックエンドシステムを表わす。バックエンドシステムは、限定しないが、顧客関係管理（ＣＲＭ）システム、人的資源（ＨＲ）システム、企業資源計画（ＥＲＰ）システム、または財務システムを含む企業内の任意の種類のバックエンドシステムを含むことが可能である。一実施形態において、バックエンドシステム６０２〜６０４は互換性のないシステムであり、異なるソフトウェアを実行するか、またはビジネスオブジェクトにおいて異なって動作する異なるビジネスロジックを有し得る。異なるバックエンドスステムは、それぞれのビジネスプロセスを構成する基本要素となるコンポーネントまたは異なるビジネスオブジェクトを有することが可能である。一実施形態において、バックエンドシステム６０２は可搬性のあるアドホックワークフローを生成し、それはアドホックテンプレート６５４として記憶される。バックエンドシステム６０４は、バックエンドシステム６０２において生成されても、アドホックテンプレート６５４に基づいてバックエンドシステム６０４の中でそのテンプレートを使用し、ビジネスプロセスを生成することが可能である。一実施形態において、アドホックテンプレート６５４はワークフローを生成したバックエンドシステム６０２において利用可能なリポジトリに記憶され、ワークフローはテンプレートとして共有される。

図７は、ビジネスプロセスの修正を提案する実施形態のフロー図である。７０２において、提案者は提案を提出する。一実施形態において、提案者は提案される検査モデルを示すことを含む。その代わりに、提案の最初の審査において、提案された検査モデルを提供することが可能である。ビジネスプロセス所有者または他の審査者は、提案された検査計画に追加し、または提案された審査計画から取り去ることが可能である。提案はフレームワークによって処理され、このフレームワークは変更管理プロセスが実行されるフレームワークを意味する。フレームワーク自体は、ここで修正モジュールまたは評価モジュールとして言及される変更管理によって実現される。７０４において、フレームワークは、ビジネスプロセスと対応付けられた１つまたは複数のビジネスプロセス所有者を識別する。一実施形態において、７０６において、フレームワークは識別されたビジネスプロセス所有者のうちの１つまたは複数についてワークフローを生成する。ワークフローは、ＢＰＯの作業センターにおいて生成および提供することが可能である。例えばドイツ、ウォールドルフのＳＡＰ ＡＧから入手可能な、動的な作業センターは、ワークフローが、ユーザの作業アクションにおけるビューの中に動的に生成されることを可能とする。

７０８において、ＢＰＯは提案を受信し、その提案は、ＢＰＯが提案において実行する１つまたは複数のアクションを有することを示すワークフローとして受信されることが可能である。７１０において、ＢＰＯは提案を審査（評価）することが可能であり、７２０において、提案に変更が必要であるか否かを判定する。提案に変更が必要でないならば、評価プロセスは他の審査グループによってより深く継続することが可能であり、検査は選択的に実行することが可能である。７２０において、提案が変更を必要とするならば、７２２において、ＢＰＯは提案への変更のための要求を生成することが可能である。７２４において、ＢＰＯによる要求はフレームワークによって処理することが可能であり、そのフレームワークは提案を編集するために、提案者のためにワークフローを生成することが可能である。７２６において、提案者は変更要求を受信し、提案プロセスを提案のもう１つの繰り返しの開始に戻すことが可能である。一実施形態において、変更要求を生成するのではなく、ＢＰＯは提案を拒否することを判断し、フレームワークが提案者に報告することが可能な拒否を発行する。

図８は、提案されたビジネスプロセスの修正を評価する実施形態のフロー図である。８０２において、ＢＰＯは、ビジネスプロセスの修正提案の最初の評価を提供する。最初の評価は、承認または拒否、または提案への変更の要求を判定することが可能である。８０４において、提案において変更が必要ならば、８０６において、最初の提案は拒否され、８０８において、提案者は提案の最初の拒否が通知される。通知は、提案を承認することが必要とみなされる変更の記述を含むことが可能である。図７に表わされているように、提案プロセスは、提案が最終的に拒否または承認されるまで繰り返すことが可能である。一実施形態において、提案を作成するために報償を提供することが可能である。８１０において、報償が適用可能ならば、適用可能な報償が、提案の提供に対して提案者に与えられることが可能である。

８０４において、変更の必要がない承認可能な提案が受信されると、８２０において、評価の種類を決定することが可能であり、これは検査モデルを識別することを含むことが可能である。検査モデルは、提案者および／またはＢＰＯによって提供されることが可能である。一実施形態において、フレームワークは、例えば分析手段によって、必要な評価の種類を判定する。ＢＰＯは、適用可能であるべき評価の種類を示すパラメータを提供することが可能であり、および／または、ＢＰＯは提案に適用する評価の種類を示すことが可能である。評価の種類は、複数の異なる種類のうちの１つまたは複数とすることが可能である。複数の評価の種類が使用される場合、それらは並行して実行することが可能である。

８２２において、モデルおよびシミュレーションの評価を使用することが可能である。モデルは、提案されたプロセス／修正がどのように使用されるか、いつ使用されるか、どのような条件で使用されるかを示す入力パラメータから生成される。ビジネスプロセスのリアルタイムな実装において発生することが予期される状況による入力をシミュレーションするソフトウェアを用いてシミュレーションを実行することが可能である。ビジネスプロセスの結果は入力への応答に基づいて予測される。

一実施形態において、８２４において、調査が実行される。調査は、提案されたビジネスプロセスの修正の認識される実行可能性に関連し得る情報の内部および／または外部の調査を含むことが可能である。例えば、組織内で収集された経験上のデータは、提案されたビジネスプロセスの妥当性および潜在的な有効性を示すことが可能である。もう１つの例において、標準団体から入手可能な標準は、業界標準または要求条件への、新たな手順の準拠を保証するために評価することが可能である。

８２６において、顧客アプローチを使用することが可能であり、提案者および／またはＢＰＯによって定義することが可能である。

一実施形態において、８３０において、チーム評価が実行される。８３２において、フレームワークはチームを識別し、８３４において、提案について審査および報告する審査者としてチームメンバーに提案を与える。チームメンバーは、ビジネスプロセスの提案の成果において利害関係を有する個人、関連する専門的知識を有する個人、等として識別することが可能である。一実施形態において、８４０において、専門家の評価が実行される。８４２において、フレームワークは、例えば既知の専門的知識によって、専門家を識別する。８４４において、識別された専門家は提案を受信し、提案は審査および報告されることが可能である。図８に明示されていないが、フレームワークは審査プロセスと対応付けられた各々の審査者のためにワークフローを生成することが可能である。

図９は、提案されたビジネスプロセスの修正を配備および監視する実施形態のフロー図である。提案は受信および審査される。９０２において、審査および提案の段階が承認された提案を生成すると、審査された提案が検査される。検査は一般に、組織で稼働している現在の運用システムではなく、ミラー化されたシステムまたは並列処理システムにおいて実行される。９１０において、結果が良好であるかどうかを判定するために結果が検査される。一実施形態において、フレームワーク内で動作する修正評価モジュールによって結果が評価される。結果が良好でないならば、９１２において、検査されたビジネスプロセスに変更が行われる。検査されたビジネスプロセスを変更することは、実際、いくつかの段階が存在し、提案者に指示が返送され、これは承認された提案を生成するように繰り返すことが可能である。

９１０において、検査の結果が良好であるならば、９１４において、修正または変更されたビジネスプロセスを実行するように実装された提案とともに提案において修正されたビジネスプロセスが配備される。配備は、一般に、組織の現在の運用システムにおける実装と考えることが可能である。現在の運用システムは“実世界”として言及することが可能である。上述したように、配備の各々の以前のレベルが成功したことが判明するに連れて到達する配備の異なる範囲を用いて、配備は徐々に実行することが可能である。一実施形態において、報償は、成功した検査および／または配備と対応付けされる。９１６において、プロセス発展モジュールは、適切に提案者に報償を与えることが可能である。

９１８において、配備され変更されたプロセスの成果が承認されるかどうかを判定するために配備されたプロセスが監視される。９２０において、成果が良好でないならば、９２２において、変更されたプロセスは撤回することが可能であり、変更されたプロセスによって置換された元のプロセスを復旧することを含むことが可能である。９２０において、成果が良好であるならば、成果が、望ましい成果の基準（適時性、コスト、効果、等）を達成していることを意味し、９２４において、変更されたプロセスは、恒久的な、かつおそらく最良の実務プロセスとして実装することが可能である。配置の間のプロセスの評価は、プロセスが、他ではなくある条件の下で最良の実務であることを示し得る。プロセスは、他ではなくある条件の下で最良の実務として利用可能とされ得る。プロセスが最良の成果を有することが確認された後も、プロセスが最良の実務として記憶されても、プロセスの監視を継続することが可能である。さらに、９２６において、報償は、配備または成功したオペレーションの１つまたは複数の段階と対応付けされ、組織によって提供される報償のモデルの中で適切ならば、提案者が報償を受ける。

図１０Ａ〜１０Ｃは、結果パターン曲線の実施形態のブロック図である。モデル化およびシミュレーションのために、および／または、検査の目的のために、結果パターンを分類することが可能である。潜在的な予測または検査比較のギャラリーの中で、選択的に各種の結果を提供することが可能である。一実施形態において、プロセス修正モジュールは予測として１つまたは複数の結果をユーザに提供することを可能とするためにユーザにギャラリーを提供することが可能である。ビジネスプロセスの異なる部分が異なる結果を有することを予測することが可能である。

データ点を入力するのではなく、ＢＰＯは、結果パターンのギャラリーの中から、予期される結果に最も近い視覚的線グラフを単に選択することによって結果を予測することが可能である。Ｓまたは学習曲線（S or Learning curve）１００２は、ある人が仕事について何か新しいことを学習するに連れて結果が急速に増加し、訓練が実務に入った後、しばらくの間、平らになることを表わす。

非準拠曲線（non-compliance curve）１００４は学習曲線１００２の逆を表わす。非準拠によって、突然に急速に成果が減少し、低い点において平らになることが予期される。機械起動曲線（machine start up curve）１００６は、機械がターンオンされたときのように、直ちにまっすぐに上昇を始める結果を表わす。機械停止曲線（machine shut down curve）１００８は、機械起動曲線１００６の逆であり、成果は鋭く下降する。

自動曲線（automated curve）１０１０は階段関数であり、学習曲線または機械起動曲線の特別な場合を与える。例は、突然にあるレベルの出力を与える新たな機械を導入している。逆自動曲線（reverse automated curve）１０１２は自動曲線１０１０の逆であり、直ちにより低い出力が達成される。例えば、結果の計量が特定のプロセスについての応答のための時間であるならば、より低い出力が望ましい結果であり得ることに留意すべきである。より低い結果は望ましい結果であり得る。

図１０Ｂは人間化曲線（humanized curve）１０１４を含み、人間化曲線１０１４は最大まで安定して上昇し、次第に弱くなることを表わす。逆人間化曲線（reverse humanized curve）１０１６は安定して減少し、最小レベルまで次第に弱くなることを表わす。例えば、ある人がダイエットを開始し、ダイエットの開始において多くの体重を落とし得る。続く期間において、体重の減少は次第に弱くなり、全く平らになり得る。

新たなプロセス曲線（new process curve）１０１８は、あるレベルの出力を有する新たなプロセスの開始を表わす。停止プロセス（stop process）１０２０は、結果のレベルからゼロへの突然の停止を表わす。熱中曲線（enthusiasm curve）１０２２は、一種の競争曲線を表わす。例えば、企業が新たな独自の商品を発表すると、しばらくの間、売り上げを押し上げる。しかし、新たな商品に競合企業が続くに連れて、売り上げは落ち込むことが予期される。逆熱中曲線（reverse enthusiasm curve）１０２４は、初期の落ち込みに上昇が続き、最終的に平らになることを表わす。

図１０Ｃは熱中撤退曲線（enthusiasm opt-out curve）１０２６を含む、熱中撤退曲線１０２６は、熱中曲線と同様な結果を表わすが、プロセスまたは努力が捨て去られ、最終的に落ち込みを引き起こす。顧客曲線（custom curve）１０２８は、ユーザが新たなパターンを設計することを可能とする。顧客曲線１０２８は、ユーザが曲線を定義するある点または線分を導入するラインツールを用いて生成することが可能である。曲線は線が描かれた後に編集することが可能である。

図１１は、ビジネスプロセスの分析手段の実施形態のブロック図である。ビジネスプロセス修正フレームワークとしてここで説明された変更管理プロセスは、分析的なビジネスプロセスを用いて自動化することが可能である。分析手段は、提案された変更の監視、評価、検査、配備において使用することが可能である。一実施形態において、配備は、結末の機能的な結果である。

分析手段は、良好な提案者、良好な提案がどこに由来するか、変更の目標が与えられたか否か、ある役割にある人が、変更についてある影響を与えることをいつ期待すべきかを識別することができる。また、分析手段は、ある時間枠内で組織的な変更が発生したか否かによって生成することが可能である。例えば、組織からの人は特定のレベルにおいて参加するように期待することが可能であり、レベルが達成されたかどうかを判定するために結果を分析することが可能である。データが分析され、使用されるビジネスプロセス、および分析手段によって使用する分析方法を可能な限り適合させるために、メタ分析が実行され得る。

他の分析手段は影響分析を含むことが可能である。評価および検査フェーズの間に、ユーザは、提案されたビジネスプロセスによって影響を受けるリソース、個人、資産への影響分析を知ることを望み得る。分析は、例えば、もう１つのプロセスによって使用された成果物を有するプロセスの外部に段階が除去されるならば、どのプロセスの変形が破壊されるかを判定するために分析を実行することが可能である。監視段階において、以前のプロセスと比較して新たなプロセスを使用することを開始した従業員の比率のような、ある分析手段を使用することが可能である。

また、分析手段は、撃ち放しメカニズムの重要な部分である。プロセスが、提案者または評価者によって設定されたあるパラメータに到達することに失敗すると、自動的に停止され、分析手段のフィードバックに基づいて再評価または拒否のために戻されることが可能である。

また、分析手段は、プロセスの有効性を示すことが可能である。例えば、データマイニング傾向分析は、新たなプロセスにおける成功要因と以前のプロセスとの間に相関関係が存在するか否かを示すことが可能である。従って、分析手段は、元のプロセスおよび新たなプロセスにおける参加者の間の関係を判定する重要な役割を果たすことが可能である。また、分析手段は、特定の従業員、部門全体、等に関する傾向を示すことが可能である。

定義された分析方法１１０２は、ビジネスプロセスの側面の解析的な分析を提供するために開始点を提供する。この方法は、分析の種類および目的に依存し、実装に固有である。ビジネスプロセスデータ１１０４は、分析されるビジネスプロセスから得られる情報であり、修正提案の主体である典型的なビジネスプロセスである。１１１０において、分析モジュールまたはエージェントは、定義された分析方法１１０２に照らしてビジネスプロセスデータ１１０４を分析する。分析出力１１２０は、ビジネスプロセスデータ１１０４における方法の実行の結果を表わす。

分析モジュールは、出力結果のメタ分析１１３０を提供する。メタ分析は、以前の分析、入手可能な外部情報、予期される結果との比較、等を説明することが可能である。メタ分析出力１１４０は、分析のためにプロセスの成果が既知の基準とどのように比較されるかの表示を表わす。１１５０において、メタ分析出力１１４０は、ビジネスプロセスを分析するための分析方法の定義を生成する分析エージェントに与えることが可能である。分析方法は、ビジネスプロセスの成果のさらなる分析において使用される定義された分析方法となる。従って、プロセスがより多くの回数においてより多くのデータとともに分析され、あるいは、より多くのプロセスが分析されるに連れて、分析が発展することが可能である。

図１２は、ビジネスプロセステンプレートとしてアドホックワークフローを記憶する実施形態のフロー図である。１２０２において、例えば、既存のビジネスプロセスが望まれる成果を提供するように見えないシナリオにおいて、ユーザはアドホックワークフローを生成することを決定する。１２０４において、システムは、アドホックワークフローが生成されるアドホック生成フレームワークを所定の場所に有することが可能である。ワークフローがテンプレートとして記憶されるように選択されるならば、一般に、フレームワークは、ワークフローの特定の段階の記憶および各段階のモデル化を可能とする。１２０６において、ワークフローがテンプレートとして記憶されるように選択されるならば、生成されたワークフローは、可搬性のあるビジネスプロセスの共通リポジトリとしてアクセス可能な既存のビジネスプロセスメタリポジトリに記憶される。

一実施形態において、１２０８において、システムは、記憶されたワークフローを既存のビジネスプロセスと比較する。例えば、目的に関連するワークフローと対応付けられたメタデータ、ワークフローの条件、パラメータ、等は、既存のビジネスプロセスの類似の要素と比較することが可能である。１２１０において、ワークフローが既存のビジネスプロセスと類似でないならば、１２１２において、ワークフローは利用可能なビジネスプロセステンプレートとして保存することが可能である。１２１０において、ワークフローが既存のビジネスプロセスと類似であるならば、１２１４において、類似の既存のビジネスプロセスへの提案された修正としてワークフローを提案するか否かを判定するためにユーザを促すことが可能である。１２２０において、ワークフローが修正として提案されないならば、１２１２において、ワークフローは利用可能なビジネスプロセステンプレートとして記憶することが可能である。１２２０において、ワークフローが修正として提案されるならば、１２２２において、システムは、提案されたビジネスプロセスの修正としてのワークフローとともにビジネスプロセス修正フレームワークを実行する。

ここで説明した以外に、本発明の技術的範囲を逸脱することなく、開示された本発明の実施形態および実装に各種の変形を行うことが可能である。従って、ここでの説明および実施形態は例示と解釈されるべきであり、限定の意味に解釈されるべきでない。本発明の技術的範囲は特許請求の範囲によってのみ判断されるべきである。

実行時コンポーネントおよび設計時コンポーネントを有するアプリケーションフレームワークの実施形態のブロック図である。 企業サービスアーキテクチャの実施形態のブロック図である。 システムアーキテクチャの実施形態のブロック図である。 ビジネスプロセス修正モジュールを有するユーザ機器の実施形態のブロック図である。 プロセス発展モジュールの実施形態のブロック図である。 プロセス修正モジュールおよびメタリポジトリを有するネットワークの実施形態のブロック図である。 ビジネスプロセスの修正を提案する実施形態のフロー図である。 提案されたビジネスプロセスの修正を評価する実施形態のフロー図である。 提案されたビジネスプロセスの修正を配備および監視する実施形態のフロー図である。 結果パターン曲線の実施形態のブロック図である。 結果パターン曲線の実施形態のブロック図である。 結果パターン曲線の実施形態のブロック図である。 ビジネスプロセス分析手段の実施形態のブロック図である。 ビジネスプロセステンプレートとしてアドホックワークフローを記憶する実施形態のブロック図である。

符号の説明

１００ 複合アプリケーションフレームワーク
１０２ 設計時コンポーネント
１０４ 実行時コンポーネント
１０６ メタデータ
１１０ プロセスモデラー
１１２ アクション
１１４ コンテキスト
１２０ ＵＩモデラー
１２２ ビュー
１２４ パターン設定
１３０ サービスモデラー
１３２ サービス
１３４ エンティティ
１４０ ジェネレータ
１５０ プロセスフレームワーク
１５２ 案内手順
１５４ 共通作業リスト
１５６ ワークフローインスタンス
１６０ ＵＩフレームワーク
１６２ ＵＩコンポーネント
１６４ ＵＩパターン
１６６ 動的ビュー
１７０ サービスフレームワーク
１７２ エンティティサービス
１７４ アプリケーションサービス
１７６ ＪＡＶＡ（登録商標）データオブジェクトサービス
１７８ 外部サービス
１８０ 企業基盤システム
１８２ データ
１８４ リモートファンクションコール
１８６ ウェブサービス
１８８ プロセスリポジトリ
１９０ プロセス修正モジュール

Claims (15)

1. 元のビジネスプロセスを記憶するビジネスプロセスメタリポジトリを提供し、前記ビジネスプロセスメタリポジトリがビジネスプロセスを複数のバックエンドシステムに利用可能とするために複数のバックエンドシステムからビジネスプロセスを集めるステップと、
   前記元のビジネスプロセスのフェーズのコンポーネントへの提案された修正を受信するステップと、
   前記複数のバックエンドシステムに利用可能な修正されたビジネスプロセスを生成するために、前記ビジネスプロセスメタリポジトリに前記提案された修正とともに前記元のビジネスプロセスのコピーを記憶するステップと、
   を有する方法。
2. 前記元のビジネスプロセスを記憶するビジネスプロセスメタリポジトリを提供するステップは、
   前記元のビジネスプロセスのオブジェクトを前記ビジネスプロセスメタリポジトリのオブジェクトと同期させるビジネスプロセスメタリポジトリを提供するステップをさらに有する請求項１に記載の方法。
3. 前記元のビジネスプロセスを記憶するビジネスプロセスメタリポジトリを提供するステップは、
   プロセス、前記プロセスと対応付けられたオブジェクト、前記オブジェクトと対応付けられたサービスを記憶するビジネスプロセスメタリポジトリを提供するステップをさらに有する請求項１に記載の方法。
4. 前記ビジネスプロセスメタリポジトリが複数のバックエンドシステムからビジネスプロセスを集めるステップは、
   前記ビジネスプロセスメタリポジトリが、顧客関係管理（ＣＲＭ）システム、人的資源（ＨＲ）システム、企業資源計画（ＥＲＰ）システム、または財務システムを含む２つまたはより多くのシステムのためのビジネスプロセスを集めるステップを有する請求項１に記載の方法。
5. 前記ビジネスプロセスメタリポジトリがビジネスプロセスを複数のバックエンドシステムに利用可能とするために複数のバックエンドシステムからビジネスプロセスを集めるステップは、
   前記ビジネスプロセスメタリポジトリが前記複数のバックエンドシステム内にテンプレートとして前記ビジネスプロセスを提供するために前記ビジネスプロセスを集めるステップを有する請求項１に記載の方法。
6. 前記ビジネスプロセスメタリポジトリが前記複数のバックエンドシステム内にテンプレートとして前記ビジネスプロセスを提供するために前記ビジネスプロセスを集めるステップは、
   複合アプリケーションフレームワークが複合プロセスを生成するように、前記複合アプリケーションフレームワークに前記ビジネスプロセスの１つのコンポーネントを提供するために、前記ビジネスプロセスメタリポジトリが前記ビジネスプロセスを集めるステップをさらに有し、前記複合プロセスは前記複合プロセスの１つのコンポーネントとして前記ビジネスプロセスの１つのコンポーネントを有する請求項５に記載の方法。
7. 元のビジネスプロセスを記憶するビジネスプロセスメタリポジトリを提供し、前記ビジネスプロセスメタリポジトリがビジネスプロセスを複数のバックエンドシステムに利用可能とするために複数のバックエンドシステムからビジネスプロセスを集める処理と、
   前記元のビジネスプロセスのフェーズのコンポーネントへの提案された修正を受信する処理と、
   前記複数のバックエンドシステムに利用可能な修正されたビジネスプロセスを生成するために、前記ビジネスプロセスメタリポジトリに前記提案された修正とともに前記元のビジネスプロセスのコピーを記憶する処理と、
   を含む処理を実行する機械となるように命令を与えるために記憶されたコンテンツを有する機械読み取り可能な媒体を含む製品。
8. 前記元のビジネスプロセスを記憶するビジネスプロセスメタリポジトリを提供する処理のためのコンテンツは、
   前記元のビジネスプロセスのオブジェクトを前記ビジネスプロセスメタリポジトリのオブジェクトと同期させるビジネスプロセスメタリポジトリを提供する処理のためのコンテンツをさらに含む請求項７に記載の製品。
9. 前記元のビジネスプロセスを記憶するビジネスプロセスメタリポジトリを提供する処理のためのコンテンツは、
   プロセス、前記プロセスと対応付けられたオブジェクト、前記オブジェクトと対応付けられたサービスを記憶するビジネスプロセスメタリポジトリを提供する処理のためのコンテンツをさらに含む請求項７に記載の製品。
10. 前記ビジネスプロセスメタリポジトリが複数のバックエンドシステムからビジネスプロセスを集める処理のためのコンテンツは、
    前記ビジネスプロセスメタリポジトリが、顧客関係管理（ＣＲＭ）システム、人的資源（ＨＲ）システム、企業資源計画（ＥＲＰ）システム、または財務システムを含む２つまたはより多くのシステムのためのビジネスプロセスを集める処理のためのコンテンツを含む請求項７に記載の製品。
11. 前記ビジネスプロセスメタリポジトリがビジネスプロセスを複数のバックエンドシステムに利用可能とするために複数のバックエンドシステムからビジネスプロセスを集める処理のためのコンテンツは、
    前記ビジネスプロセスメタリポジトリが前記複数のバックエンドシステム内にテンプレートとして前記ビジネスプロセスを提供するために前記ビジネスプロセスを集める処理のためのコンテンツを含む請求項７に記載の製品。
12. 前記ビジネスプロセスメタリポジトリが前記複数のバックエンドシステム内にテンプレートとして前記ビジネスプロセスを提供するために前記ビジネスプロセスを集める処理のためのコンテンツは、
    複合アプリケーションフレームワークが複合プロセスを生成するように、前記複合アプリケーションフレームワークに前記ビジネスプロセスの１つのコンポーネントを提供するために、前記ビジネスプロセスメタリポジトリが前記ビジネスプロセスを集める処理のためのコンテンツをさらに含み、前記複合プロセスは前記複合プロセスの１つのコンポーネントとして前記ビジネスプロセスの１つのコンポーネントを有する請求項１１に記載の製品。
13. 第１ビジネスプロセスを有する第１バックエンド企業システムと、
    第２ビジネスプロセスを有する第２バックエンド企業システムと、
    前記第１および第２バックエンド企業システムに結合された記憶装置と、
    を具備し、
    前記記憶装置は、前記第１および第２ビジネスプロセスを記憶し、かつ前記第１および第２ビジネスプロセスを前記第１および第２バックエンド企業システムに利用可能とするビジネスプロセスメタリポジトリを有するシステム。
14. 前記第１および第２バックエンド企業システムは互換性のないソフトウェアを実行し、
    前記記憶装置は、前記第１および第２バックエンド企業システムの両方においてインスタンス生成されることが可能な前記第１および第２ビジネスプロセスのバージョンを生成するために、前記第１および第２ビジネスプロセスの基本要素となるコンポーネントとしてのビジネスオブジェクトをさらに有する請求項１３に記載のシステム。
15. 前記第１および第２バックエンド企業システムは、顧客関係管理（ＣＲＭ）システム、人的資源（ＨＲ）システム、企業資源計画（ＥＲＰ）システム、または財務システムの中から選択される請求項１３に記載のシステム。

Images