JP2006512670A - 統合型プロセス・モデラーのための方法及び装置 - Google Patents

Abstract

非技術系ユーザに設計アスペクトを、技術系ユーザに実装アスペクトを提供し（５２０）、完全な実行可能プロセスを作成する（１６０）ように設計された垂直統合型プロセス・モデラーを備えるエンド・ツー・エンド・プロセス・モデラー。

Description

本発明は、モデル化に関し、より詳細には、複雑なプロセスのモデル化に関する。

一般に、組織のエコシステム内でフォローされるプロセスは、ほとんどの事業環境において、種々の形態で記述される。このタイプのモデル化は、会社が事業にわたって統一性のあるプロセスを作成することを試みるため、ますます重要になりつつある。

例えば、ビジネス・アナリストは、ＶｉｓｉｏやｉＧｒａｆｘなどのツールを使用して、ビジネス・プロセスのためのプロセス・フローを作成することができる。しかし、こうしたプロセスを自動化するために、ＢｉｚＴａｌｋ又は同様なツールなどの、異なるツールを使用しなければならない。

しかし、こうしたプロセスを移管することは難しい。ビジネス・アナリストは、プロセスのステップのそれぞれが何を意味するかを開発者に説明しなければならない。そして、開発者は、自動化されたプロセスを作成し、自動化されたプロセスが、ビジネス・アナリストが概略を示したプロセスを実際にフォローするために他の社員によって使用される。このプロセスは、長くかつ複雑であり、情報伝達の誤りは再作業を生成し、それによって、実現が遅延する。

さらに、Ｓｉｅｂｅｌなどの一部の会社は、企業に最善のプラクティスを提供する場合がある。これらの最善のプラクティスは、種々のアクションについて、フォローされる自動化されたプロセスである。しかし、これらのプロセスは、顧客の要求に完全には合致しない場合があり、一般に、修正するのが難しい。

非技術系ユーザに設計アスペクトを、技術系ユーザに実装アスペクトを提供し、完全な実行可能プロセスを作成するように設計された垂直統合型プロセス・モデラーを備えるエンド・ツー・エンド・プロセス・モデラー。

本発明は、添付図面の図において、制限としてではなく、例として示され、図では、同じ参照数字は同じ要素を指す。

統合型プロセス・モデラーのための方法と装置が述べられる。プロセス・モデラーは、設計し、デバッグし、エンド・ツー・エンド・ビジネス・プロセスを展開する単一ツールを提供する。この文脈では、ビジネス・プロセスは、特定のビジネスの目標を達成するために編成され、構造化された一連の文書化された活動である。任意の特定の目標物を実行するのに多くのプラクティスが存在するため、特定のビジネス・プロセスの構造は、会社によって変わる場合がある。複数のサブ・プロセスからなる可能性があるビジネス・プロセスは、フロー図でグラフィカルに表され、第３者アプリケーションに及ぶ可能性がある。エンド・ツー・エンド・ビジネス・プロセスは、会社にとって主要なビジネス・プロセスであり、会社の法的境界の中や、外での複数の部門又は組織に及ぶ場合がある。エンド・ツー・エンド・ビジネス・プロセスはまた、自律的にか、エンドユーザによってのいずれかで実行する複数の相互接続したコンピュータ・システムとの対話を含む。エンド・ツー・エンド・ビジネス・プロセスは、通常、数分又は数秒ではなく、数時間、数日、数週間、又は数ヶ月にわたって発生する長期にわたるプロセスである。本発明は、こうしたエンド・ツー・エンド・ビジネス・プロセスだけでなく、より単純な基本ビジネス・プロセスの設計を可能にする。

エンド・ツー・エンド・ビジネス・プロセスを使用することによって、モデラーは、複数のプロセス・タイプ（例えば、事業、Ｓｉｅｂｅｌ、統合、タスク）、ならびに、複数の役割（例えば、ビジネス・アナリスト、開発者）に及び、これらの構成要素間でのシームレスな移行を可能にする。

プロセス・モデラーは、ユーザ対話を含むプロセス・フロー（例えば、作成コール・リスト・タスク）を設計することが可能である。ユーザ対話の設計は、ユーザ・インターフェースや、特定のユーザから特定のタイプの入力を待つことを必要とするプロセス・ステップを含む。一実施形態の場合、非技術系及び技術系ユーザは共に、これらのユーザ対話フローを設計する可能性がある。プロセス・モデラーは、ユーザ対話ならびに他のアプリケーションとの統合を作成する能力を含む。

図１は、統合型プロセス・モデラーの一実施形態のブロック図である。プロセス・モデラー１００は、どのタイプのインターフェースがユーザに提示されるかを判断するユーザ識別ロジック１１０を含む。ビジネス・アナリスト・インターフェース１３０は、新しいプロセスの設計や、既存のプロセスの編集を可能にする。開発者インターフェース１６０は、アナリストによって設計されたプロセスの実装及び統合を可能にする。

一実施形態の場合、ユーザ識別ロジック１１０は、ユーザ・タイプを識別するために、ユーザのログインとグループ・アソシエーションを使用する。別の実施形態の場合、ユーザは、自分の好みのインターフェースを選択することができる。別の実施形態の場合、モデラー１００を利用することができる各ユーザは、ユーザ識別ロジック１１０に対して指定される。そのため、ユーザ・インターフェースを選択することに加えて、ユーザ識別ロジック１１０は、セキュリティ機能を提供する。これは、権限のないユーザが、任意のプロセスを変更するか、又は、新しくかつ不正なプロセスを作成することを防止する。

上述した、ビジネス・アナリスト・インターフェース１３０は、ビジネス・アナリスト又は同等な個人が、プロセスを作成することを可能にする。このインターフェース１３０はまた、ユーザがプロセスを編集し又は作成するため、「エディタ」と呼ばれる場合がある。「ビジネス・アナリスト」という用語は、企業による使用のために、プロセスを作成するように権限を与えられた個人のことを言う。一般に、こうした人は、エンジニア又はプログラマである必要はないので、したがって、非技術系ユーザと呼ばれるであろう。しかし、ビジネス・アナリストは、もちろん、プログラマであっても、又は、技術的に詳しくてもよい。「非技術系ユーザ」という用語は、ビジネス・アナリストが、プロセスを作成するか、又は、編集するためにプログラミングを知る必要がないことを規定するのに単に使用される。

このプロセスは、会社の内部又は外部で一定の手順を自動化するように設計される。プロセスは、例えば、売買要求を達成するプロセスである。この例は、本明細書全体を通して使用されるであろう。しかし、任意の手順が自動化されてもよいことが理解されるばきである。

一実施形態の場合、モデラー１００は、最善のプラクティス・プロセスのライブラリ１３５へアクセスする。最善のプラクティス・プロセスは事前に定義されたプロセスである。一実施形態の場合、Ｓｉｅｂｅｌなどの会社は、そのクライアントに事前に定義された複数の最善のプラクティス・プロセスを提供する。これらのクライアントは、その後、最善のプラクティス・プロセスをカスタマイズし変更するために、ビジネス・アナリスト・インターフェース１３０を使用するか、又は、最善のプラクティス・プロセスを採用するように選択する。ライブラリ１３５は、ビジネス・アナリスト・インターフェース１３０に利用可能である。一実施形態の場合、最善のプラクティス・プロセス全体をインポートすることができることに加えて、ビジネス・アナリストは、ライブラリ１３５からサブ・プロセスを選ぶ場合がある。例えば、サブ・プロセスは、「スーパバイザによって確認される」。サブ・プロセスは内部に複数のステップを有する。例えば、確認することは、ｅｍａｉｌを送出すること、応答を待つこと、さらに、適切な応答が受信された場合、確認を通知することを含む。

ドリルダウン・ロジック１２０は、ビジネス・アナリストが、サブ・プロセスからステップへ進むことを可能にする。一般に、プロセスは、一連のステップとして示される。各ステップは、１つ又は複数のステップあるいはサブ・ステップを有してもよい。ビジネス・アナリストは、ビジネス・アナリスト・インターフェース１３０を使用して、プロセスからサブ・プロセスへ、サブ・プロセスからステップへドリルダウンする。ビジネス・アナリストに対して示される種々のユーザ・インターフェースが以下で述べられる。

ビジネス・アナリストがプロセスの設計を完了すると、ビジネス・アナリストは、チェックイン・ロジック１４０を使用して、プロセスをチェックインさせる。チェックインするということは、プロセスが完了したとの指示のことを言う。バリデーション・ロジック１４５は、プロセスが一定の基本的基準を満たすことを検証する。例えば、バリデーション・ロジック１４５は、各要素が少なくとも１つの他の要素に接続されていることを検証する。バリデーション・ロジック１４５はまた、明確な端点を持っていないコネクタが存在しないことを検証する。さらに、一実施形態の場合、バリデーション・ロジック１４５は、任意の「決定要素」が、２つの出力コネクタを有することを検証する場合があり、１つのコネクタがそれぞれの可能性のある結果をもたらす。バリデーション・ロジック１４５は、あるエラーが存在すると判断すると、プロセスをビジネス・アナリスト・インターフェース１３０に戻るように渡し、指示されたエラーを訂正することをビジネス・アナリストに通知する。一実施形態の場合、バリデーション・ロジック１４５は、任意のエラーにフラグを立てるか、又は、その他の方法で、何がなされる必要があるかに関する指示を提供する。

バリデーション・ロジック１４５は、エラーが存在しないと判断すると、プロセスを移管とフラギング・ロジック１５０に渡す。

移管とフラギング・ロジック１５０は、プロセスを、進行中のプロセスの集合体１５５に移管する。一実施形態の場合、実装を完了しなかったプロセスは、集合体１５５内に格納される。この集合体は、実装のために、開発者がアクセス可能であり、一実施形態の場合、さらなる編集のためにビジネス・アナリストがアクセス可能である。しかし、進行中のこれらのプロセス１５５は、一般に、会社がアクセス可能ではなく、使用されない。

一実施形態の場合、移管とフラギング・ロジック１５０はさらに、プロセスにフラグを立てる。フラグを立てることは、実装のための作業を必要とする各要素及び／又は各コネクタをマークすることである。一実施形態の場合、複数のタイプのフラグが存在し、各フラグは、行われる必要がある作業のタイプを指示する。例えば、フラグは、実行可能な意味付けについて、不十分な詳細が提供されたことを指示する。別法として、フラグは、特定の情報伝達が規定される必要があることを指示する。例えば、ビジネス・アナリストは、要素を「接触スーパバイザ」として規定するが、このタスクを達成する方法についての規定を提供しない。このフラグは、その後、適切な要素とコネクタ上で作業するために開発者によって使用される。プロセスのこのフラグを立てられたバージョンは、その後、集合体１５５内に格納される。

開発者は、開発者インターフェース１６０を通して進行中のプロセスを集合体１５５から集める。「開発者」という用語は、簡略化のために本明細書で使用される。「開発者」は、実行可能プロセスを作成することができる任意のユーザである。一般に、開発者は、プログラマなどの技術系ユーザである。開発者インターフェース１６０はまた、プロセスを実行可能プロセスに実装するのに使用されるために、実装インターフェース１６０と呼ばれる。

一実施形態の場合、プロセスは、実装のために、特定の開発者又は開発者のチームに割り当てられる。その場合、ユーザ識別ロジック１１０は、開発者が、特定のプロセスに対してアクセスする／作業するかどうかを制御する。

開発者１６０は、プロセスを実行可能にするために、プロセスを編集する。さらに、開発者は、ドリルダウン・ロジック１２０を使用して、使用される要素とサブ・プロセスを調べる。一実施形態の場合、開発者はさらに、ライブラリ１３５内で規定された既存のプロセスとサブ・プロセスにアクセスする。これは、以前に規定したステップとサブ・プロセスの再使用を可能にする。

統合ロジック１６５は、開発者が、プロセスを第３者のアプリケーションとソフトウェアを統合することを可能にする。例えば、統合ロジック１６５は、プロセスが、インターネットなどの外部データ源からデータを取得することを可能にする。例えば、在庫価格がインターネット源から取得され、このデータを、プロセス内で使用する。

開発者が、プロセスを使用可能にすることを完了すると、プロセスは、使用のために利用可能になる。一実施形態の場合、ビジネス・アナリスト又はスーパバイザは、最終的な承認を行わなければならない。一実施形態の場合、品質保証チームはさらに、プロセスに関して試験を実施する。プロセスが承認されると、プロセスを、企業内で実装できる。これは、プロセスが、種々のユーザに対して利用可能になっていることを意味する。一実施形態の場合、こうしたプロセスはさらに、ライブラリ１３５内に置かれて、プロセス内での種々のステップの再使用が可能になる。

こうして、本統合型プロセス・モデラー１００は、ビジネス・アナリストが、プロセスを作成することを可能にし、開発者が、プロセスを実行可能にさせる。その結果得られるプロセスは、会社全体を通して使用できる。

図２は、統合型プロセス・モデラーを使用する一実施形態の概要フローチャートである。シーケンスはブロック２１０で開始する。ブロック２１５で、最善のプラクティス・プロセスが利用可能にされる。一実施形態の場合、最善のプラクティスはライブラリに格納され、使用し、編集し、又は、ステップを抽出するために利用可能である。

ブロック２２０で、シーケンスは、ユーザが編集するための最善のプラクティス・プロセスを選択したかどうかを判断する。選択した場合、ブロック２２５で、選択されたプロセスがユーザに示され、編集が使用可能にされる。一実施形態の場合、選択されたプロセスの高レベル図が表示される。ユーザは、その後、プロセスのステップのうちの任意のステップ、又は、プロセス内のサブ・プロセスのうちの任意のサブ・プロセスを編集する。ユーザが最小のプラクティス・プロセスを選択しなかった場合、シーケンスはブロック２３０へ続く。

ブロック２３０で、システムは、プロセス内に取り入れられた種々の手順とサブ・プロセスの作成と編集を可能にする。プロセスが選択されなかった場合、ユーザは、この時点で、まったく新しいプロセスを作成することを望む。この例におけるユーザは、プログラマ又は技術系ユーザである必要はない。むしろ、ユーザは、会社において、どんなタイプの手順が使用されているかを知っているビジネス担当者又は管理者であってよい。

ブロック２３５で、シーケンスは、ユーザがプロセスをチェックインさせたかどうかを判断する。チェックインするということは、ユーザがプロセスを編集することを完了し、プロセスが手放されてもよいことを指示する。一実施形態の場合、ユーザは、「使用可能にされるべき」ディレクトリなどの、特別な位置にプロセスを格納することによって、これを指示してもよい。ユーザがプロセスをいまだチャックインさせていない場合、シーケンスはブロック２３０に戻り、さらなる編集を可能にする。もちろん、ユーザは、不完全なプロセスを一時的に格納し、後でアクセスしてもよい。

ユーザがプロセスをチェックインさせた場合、シーケンスは、ブロック２４０へ続く。ブロック２４０で、シーケンスは、実行可能でないか、又は、十分に定義されていない、コネクタとステップを識別し、コネクタとステップにフラグを立てる。

ブロック２４５で、インプリメンタ、又は、技術系ユーザは、それぞれのフラグの立ったアイテムを完了するようにプロンプト表示によって指示される。インプリメンタは、一般に、進行中のプロセスの集合体からプロセスをチェックアウトさせることに留意されたい。フラグは、プロンプト表示してインプリメンタにプロセスを完了するように指示し、一実施形態の場合、完了のために行われる必要がある作業のタイプを識別する。

ブロック２５０で、シーケンスは、ユーザがプロセスをチェックインさせたかどうかを判断する。一実施形態の場合、技術系ユーザは、実装を完了すると、プロセスを再びチェックインさせる。一実施形態の場合、この例では、チェックインすることは、プロセスに対して品質保証／試験を実施すること、及び、管理者などの適切な個人から最終的な同意を得ることを含む。プロセスがいまだチェックインされていない場合、シーケンスはブロック２４５に戻り、さらなる編集が可能になる。

プロセスがチェックインされている場合、シーケンスは、ブロック２５５へ続き、完了したプロセスがユーザに利用可能にされる。これらのユーザは、例えば、プロセスを使用して、一貫性がありかつ完璧な顧客サポートを提供する顧客サポート要員である。一実施形態の場合、各プロセスは、特定の社員のグループを対象とし、一貫性があり、完全で、訓練するのが容易で、使用するのが容易なプロセスを生ずる。シーケンスは、その後、ブロック２６０にて終了する。

図３Ａ、図３Ｂは、ビジネス・アナリストが、プロセス・モデラーを使用して、新しいプロセスを作成する一実施形態のフローチャートである。シーケンスは、ブロック３１０で開始する。この時、ビジネス・アナリスト又は権限のある社員がシステムにログインする。

ブロック３１５で、最善のプラクティス・プロセスが、ユーザに利用可能にされる。このライブラリは、ビジネス・アナリストがアクセス可能であり、既存のプロセスを最高性能を発揮するように調整する（ｔｗｅａｋ）こと、既存のプロセスに基づいて新しいプロセスを作成すること、あるいは、既存のプロセスからのステップ又はサブ・プロセスを単に使用することが可能になる。こうした再利用が可能になることによって、新しいプロセスの作成が大幅に簡略化される。

ブロック３２０で、シーケンスは、編集すべきプロセスを選択したかどうかを判断し、選択した場合、ブロック３２５で、選択されたプロセスがユーザに表示される。一実施形態の場合、選択されたプロセスは、高レベル・プロセスを示し、ドリルダウンによって達することができる複数のサブ・プロセスを含む。シーケンスは、その後、ブロック３３０へ続く。ユーザが、編集すべきプロセスを選択しなかった場合、シーケンスは、直接、ブロック３３０へ続く。

ブロック３３０で、実行可能状態（ｓｈａｐｅ）を含むユーザ・インターフェースがユーザに表示される。こうしたディスプレイの例示的な実施形態は、図７に示される。

図７を見てわかるように、ツール・ボックス７１０は、プロセスとコネクタのセットを提示する。一実施形態の場合、ツール・ボックス７１０はさらに、付加的なスイム・レーンの作成を可能にする。スイム・レーン７２０は、種々のアクター又は種々のシステム間の識別を提供する。この役割に基づくビューでは、スイム・レーン７２０は、顧客、ブローカ、口座などのようなアクターを規定する。ビジネス・アナリストは、ツール・ボックス７１０を使用して付加的なスイム・レーン７２０を追加してもよい。図７を見てわかるように、プロセス７３０は、開始点、いくつかの要素７４０、いくつかの要素７４０間のコネクタ７５０を含む。見てわかるように、プロセスに付加することができる種々のタイプの機能又は要素は異なる形状を有する。一実施形態の場合、形状と色を使用して、種々のタイプの機能を識別してもよい。

ブロック３３５で、ユーザは、プロセスのライブラリ内のサブ・プロセスの既存のリストから既存のサブ・プロセス又はステップを選択することができる。これは、ユーザが、プロセスを新たに設計する代わりに、十分に機能するプロセスを挿入するだけであるため、実装を簡略化する。ユーザが挿入のためにサブ・プロセスを選択しなかった場合、シーケンスは、ブロック３５５へ続く。そうでない場合、シーケンスは、ブロック３４５に続く。

ブロック３４５で、サブ・セットのすべてを含むサブ・プロセスと要素は、指示された位置に挿入される。一実施形態の場合、サブ・プロセスが挿入されるべき位置を指示するためにユーザによってプレース・ホルダ挿入される。そのため、ユーザは、最初に、適切な位置にプレース・ホルダを置き、その後、プレース・ホルダの位置に挿入されるサブ・プロセスを選択する。

ブロック３５０で、ユーザは、プロンプト表示によって、挿入されたサブ・プロセスに適切に接続するのに必要とされる任意の接続を行うように指示される。各プロセスとステップは、プロセスのフローを提供するために、１つ又は複数の接続を有する。挿入されたサブ・プロセスは、一般に、少なくとも１つ、任意の数のコネクタを有する。ユーザは、プロンプト表示によって、これらのコネクタのそれぞれを接続するように指示される。一実施形態の場合、コネクタは、行われている接続のタイプを指示するタグ又はフラグを含む。シーケンスは、その後、ブロック３５５へ続く。

ブロック３５５で、ユーザは、１つ又は複数のステップ、接続、プロセス、プロセス内のサブ・プロセスすなわちサブステップを編集することが可能になる。

ブロック３６０で、シーケンスは、ユーザがドリルダウンすることを選択したかどうかを判断する。ドリルダウンは、プロセスの特定の要素を形成するサブ・ステップ／サブ・プロセスを示す。ユーザがドリルダウンを行う場合、ブロック３６５で、要素を形成するサブ・ステップ／サブ・プロセスと共にドリルダウンインターフェースが示される。図８Ａ、８Ｂは、２つのレベルのドリルダウンを示す。

図８Ａは、図７に示す「作成コール・リスト」プロセス・ステップをドリルダウンすることによって達したプロセス・コンフィギュレーション・インターフェースの一実施形態を示す。見てわかるように、プロパティ・ダイアログ・ボックス８１０は、ビジネス・アナリストにタスクの記述／定義を提供する。汎用タブ８２０が、タスクの基本的記述を提供する。割り当てタブ８３０は、このタスクを実施するために誰が割り当てられるべきかを決める。一実施形態の場合、これは、タスクがどのスイム・レーンを禁止するかを指示する。通知タブ８４０は、このタスクが実施される時に誰かが通知されるべきかどうかを指示し、一方、ページ・タブは、このタスクが、プロセス中のどこで起こるべきかを指示する。これは、タスクがさらされるページと条件を指示する。スレッド・バー８６０は、ビジネス・アナリストがいるプロセス内の場所を指示する。

図８Ｂは、タスクのコンフィギュレーションの一実施形態を示す。コンフィギュレーション・インターフェースは、２つのタブを含むツール・ボックス７１０を含み、１つのタブは、上記図８Ａにも示されるビジネス・プロセス８７０用であり、１つのタブは、ここで示されるユーザ・インターフェース（ＵＩ）プロセス８７５用である。タスク・プロセス・コンフィギュレーション窓８８０は、タスク・プロセスをコンフィギュレーションするためのインターフェースであり、ＵＩコンフィギュレーション窓８９０は、ページをコンフィギュレーションするためのインターフェースである。これは、一旦実装されると、プロセスを使用しているユーザに対して表示されることになるページである。ビジネス・アナリストは、ＵＩを作成し、任意のアスペクトを指定する。一実施形態の場合、ビジネス・アナリストは、こうして作成されたユーザ・インターフェースをプレビューし、ユーザ・インターフェースを開始する。

図３に戻ると、ユーザが、ドリルダウンすることを選択すると、上述したページが表示される。シーケンスは、その後、ブロック３５５に戻り、ユーザが、サブ・ステップ／サブ・プロセスを編集することが可能になる。ユーザが、ドリルダウンすることを選択しなかった場合、シーケンスは、ブロック３７０へ続く。

ブロック３７０で、シーケンスは、編集が完了したことをユーザが指示したかどうかを判断する。ユーザは、一旦プロセスに満足すると、編集が完了したことを指示する可能性がある。ユーザがこれを指示しなかった場合、シーケンスは、ブロック３５５へ続き、ユーザが、ステップをさらに編集する／作成することが可能になる。もちろん、ユーザは、いつでもブロック３４０に戻り、付加されるサブ・プロセスを選択してもよい。こうしたフローチャートでは一般に当てはまるが、決定ブロックは、実際には、割り込みとして実装され、いつでも起こってよい。そのため、ユーザは、いつでも、サブ・プロセスを付加するように選択し、ドリルダウンするように選択し、又は、編集が完了していることを指示するように選択してもよい。

ユーザが、編集が完了していることを指示する場合、シーケンスは、ブロック３７５へ続く。ブロック３７５で、シーケンスは、すべてのブロックが、論理的に接続されている、例えば、すべてのブロックが少なくとも１つのコネクタに接続されているか、また、すべてのコネクタがあるブロックに結合している、例えば、接続されずにぶら下がっているコネクタが存在しないかどうかを判断する。一実施形態の場合、システムはさらに、プロセスが、適切に開始し、終了したことを検証する。これらの条件のいずれもが満たされない場合、シーケンスは、ブロック３８０へ続き、そこで、ユーザは、プロンプト表示によって、これらのエラーを訂正するように指示される。一実施形態の場合、フラグ又はタグは、訂正されるべきエラーのそれぞれを指示する。シーケンスは、その後、ブロック３５５へ続き、ユーザがプロセスを編集し、訂正することを可能にする。

ブロックが、適切に接続され、終了した場合、シーケンスは、ブロック３８５で終了する。一実施形態の場合、プロセスは、図４に述べる、フラギング・ロジックに送られる。

図４は、ビジネス・アナリストから実装エンジニアへの責任の移管の一実施形態のフローチャートである。シーケンスは、ブロック４１０で開始する。ブロック４１５で、チェックイン完了プロセスがビジネス・アナリストから受け取られる。もちろん本シーケンスはいつでも実行できる。一実施形態の場合、本シーケンスは、完了すると自動的に始動するが、まだ実装されていないプロセスは、ビジネス・アナリストから受け取られる。

ブロック４２０で、シーケンスは、最善のプラクティス・プロセスからではない要素が存在するかどうかを判断する。チェックイン・プロセスが最善のプラクティス・プロセスと同じである。この例では、定義上、最善のプラクティス・プロセスが既に実装されているため、実装は必要とされない。

新しい要素が存在しない場合、シーケンスは、ブロック４２５で、接続のうちの任意の接続が変更されたかどうかを判断する。各プロセスは、コネクタによって相互接続された複数の要素からなる。要素もコネクタも変更されなかった場合、実装は必要とされない。そのため、シーケンスは、直接、ブロック４６０へ進み、終了する。

ブロック４２０における要素か、ブロック４２５における接続のいずれかが変更された場合、シーケンスは、ブロック４３０へ続く。

ブロック４３０で、プロセスは全体が分析される。

ブロック４３５で、シーケンスは、任意の部分すなわち論理ステップが抜けているかどうかを判断する。ビジネス・アナリストは、エラー・チェック又はデータ・バリデーションなどのステップを考えることに失敗する。こうしたステップが抜けている場合、シーケンスは、開発者のために、抜けている要素とフラグを識別するためのブロック４４０へ続く。一実施形態の場合、抜けている部分／論理ステップを識別する汎用ノートが、プロセスに添付される。別法として、シーケンスは、こうした部分／論理ステップが挿入される位置においてフラグを付加する。部分／ステップが抜けていない場合、シーケンスはブロック４４５へ続く。

ブロック４４５で、ビジネス・アナリストによって付加された新しいステップ又は接続が識別される。一実施形態の場合、シーケンスは、全体のプロセスをステップごとにウォークスルーを行って、任意の新しいステップを識別する。一実施形態の場合、シーケンスは、最下位のドリルダウンレベルにおいてこのウォークスルーを実施する。

ブロック４５０で、シーケンスは、ステップ／接続が付加的な作業を必要とするかどうかを判断する。一実施形態の場合、シーケンスは、ステップ又は接続が、既存の最善のプラクティス・プロセスからインポートされる。インポートされる場合、シーケンスは、付加的な作業が必要とされないと判断する。ステップ／接続が新しく作成される場合、一実施形態の場合、付加的な作業を必要とするとしてステップ／接続が識別される。別の実施形態の場合、システムは、さらなる分析を実施して、新しく作成された接続／ステップが作業を必要とするかどうかを判断してもよい。一実施形態の場合、システムは、付加的な作業が必要とされるかどうかを判断するステップを実行しようと試みてもよい。特定のステップ／接続が、機能し／実装されているかどうかを識別する代替の方法が使用されてもよい。ステップが作業を必要とする場合、ブロック４６５で、ステップ又は接続にフラグが立てられる。一実施形態の場合、フラグは、ステップ／接続を実装するのに必要とされる作業のタイプを指定してもよい。例えば、フラグは、接続が、ウェブ・サービスなどの外部サービスとの統合を必要とすることを識別してもよい。

ブロック４５５で、シーケンスは、分析されるべきである任意のさらなるステップ／接続が存在するかどうかを判断する。さらなるステップが存在する場合、シーケンスは、新しいステップ／接続を識別するブロック４４５に戻る。さらなるステップが存在しない場合、フラグ立てシーケンスが完了し、ブロック４６０で、シーケンスが終了する。

図９は、フラグ立てが完了した後のプロセスの一実施形態を示す。見てわかるように、多数の要素７４０と要素７５０がフラグを立てられている９１０〜９５０。アイコン９１０〜９５０は、開発者に視覚フィードバックを提供し、異なるタイプの作業が行われる必要があることを意味する。一実施形態の場合、任意の形状が、形状に並んでアイコンを潜在的に有する。この例では、アイコン９１０〜９５０は、種々の形状で表記される。別の実施形態の場合、異なる形状を使用する代わりに、又は、使用すると共に、色、シンボル、又は、他の識別器が使用されてもよい。

図５は、実装エンジニアが、プロセス・モデラーを使用して、ビジネス・アナリストによって作成されたプロセスを使用可能にする、一実施形態のフローチャートである。シーケンスはブロック５１０にて開始する。一実施形態の場合、このシーケンスは、いまだ実装されておらず、ビジネス・アナリストによってチェックインされたプロセスが存在する時はいつでも利用可能である。

ブロック５１５で、フラグ立てプロセスがシステムから受け取られる。一実施形態の場合、開発者は、実装のためのプロセスを選択してもよい。一実施形態の場合、プロセスは、特定の開発者に割り当てられる。別の実施形態の場合、各プロセスは、優先度スタンプ又は同様な優先度の指示を有している。そのため、開発者は、プロンプト表示によって、最も緊急の又は最も高い優先度のプロセスを実装するように指示される。開発者は、ブロック５１５で、実装のためにプロセスをチェックアウトさせる。

ブロック５２０で、プロセスのシステム・ビューが表示される。図１０Ａは、開発者に示される、プロセスのシステム・ビューの一実施形態を示す。見てわかるように、スイム・レーン・ラベルは、プロセスのそれぞれを処理するシステムに対応するように変わる。一実施形態の場合、プロセス・モデラーは、技術的インターフェース・ディスプレイを自動的に導出し、各スイム・レーンは、非技術的インターフェース・ディスプレイを通してシステムを識別し、各スイム・レーンは、アクターを識別する。一実施形態の場合、この導出プロセスは、非技術的インターフェース内の機能ブロックを使用し、機能ブロックは、機能ブロックが関連するシステムを識別するように（色、形状などによって）フラグが立てられる。

一実施形態の場合、設計者は、統合サーバを通過するフローの部分を表示するかどうかに関する設計者の好みを設定してもよい。一実施形態の場合、システムは、ビジネス・アナリストによって提供される基本データから統合ステップを自動的に生成する。システムは、２つのステップの間のどこで統合サーバが必要とされるかを自動的に推論する。一実施形態の場合、システムはさらに、同期化ステップを表示してもよい。同期化ステップは、一貫性のある状態を保つために、統合サーバが種々のシステムのどこでデータを同期させるかを指示する。

一実施形態の場合、「顧客」スイム・レーンは、異なるタイプの「システム」である、例えば、設計者の制御下にあるシステムではないことを指示するために識別される。この図では、「システム」は、実際のシステムではなく、論理システム・タイプである。代替法では、実際のシステム（例えば、サーバ、Ｓｉｅｂｅｌシステム、ＳＡＰなど）が指示される。個別のスイム・レーンが、システムの特定の例を必ずしも指示しないことにも留意されたい。例えば、ＣＲＭ（顧客関係管理）システムは、２つの個別のシステム、コール・センターとサービス機関である。開発者は、開発者のオプションによって、ＣＲＭスイム・レーンを複数のレーンに分離する。このタイプのシステムへの論理的分離は、開発者に対して、ビジネス・アナリストによって定義されたプロセスを実装するのに要求されることになるシステム・インターフェース要素を示す。

プロセスのシステム・ビューは、各スイム・レーンにおいて、異なるシステムを示す。システムは、Ｓｉｅｂｅｌシステム、第３者システム、インターネットなどの外部システムを含んでもよい。システム・ビューは、各ステップ及び接続について、どのシステムがステップ／接続を実施するかについての識別情報を提供する。

図５に戻ると、ブロック５２５で、シーケンスは、任意のアイテムが付加される必要があるかどうかを判断する。先に述べたように、移管／フラグ立てシーケンスは、論理的プロセス／ステップが抜けていることを指示する１つ又は複数のフラグを付加した。さらに、開発者は、プロセスを再調査する時に、付加的な要素が必要とされると判断する。必要とされる場合、ブロック５３０で、開発者は、プロンプト表示によって、付加的な要素を追加するように指示される。付加的な要素は、エラー訂正、チェック、認証、又は、任意の他の必要とされる要素である。

図１０Ｂは、利用可能なプロセスのライブラリをブラウジングする開発者のための可能性のあるインターフェースの一実施形態を示す。プロセス・ツリー１０３０は、利用可能な種々のプロセス、及び、各プロセス内で利用可能なサブ・プロセス及びタスク／ステップを示す。プレビュー窓１０４０は、開発者が、プロセスを調べ、必要である場合、付加的な詳細を調べるためにドリルダウンすることを可能にする。開発者は、全体のプロセス又はサブ・プロセスを使用するか、又は、着想のためか、又は、特定の詳細のために、プロセス又はサブ・プロセスをデータ・マイニングするだけであってもよい。プロセス・リスト１０３５は、プロセスの現在の位置（複数可）及び任意のコメントを含む、ツリー１０３０の現在の分岐で利用可能であるプロセスのリストを提供する。

ブロック５３５で、シーケンスは、開発者が、詳細を付加し、ビジネス・アナリストによって定義された要素とコネクタを実装することを可能にする。識別された機能又はステップを実施するように要素を実装する技能は、開発者によって知られている技能である。本システムは、ビジネス・アナリストと開発者の間の機能／ステップ定義の移管が完全であることを保証する。

図１０Ｃは、開発者のための、ユーザ・インターフェース・コンフィギュレーション窓の一実施形態を示す。見てわかるように、ツール・ボックス１０５０は、ビジネス・プロセス１０６０とユーザ・インターフェース・コントロール１０６５に加えて、データ・バインディング１０７０を含む。図１０Ｄは、データ・バインディングの一実施形態を示す。データ・マッピング・インターフェース１０８０は、ページ・オブジェクト（コントロール）への、ビジネス・オブジェクトのドラッグ及びドロップ式データ・バインディングを可能にする。見てわかるように、種々のページ・オブジェクトは、特定のページ・オブジェクトを定義する時にさらなる作業が必要とされることを、上述のように指示するフラグ１０９０を有してもよい。

ブロック５４０で、シーケンスは、外部サービスが使用されるかどうかを判断する。外部サービスは、他のソフトウェア・アプリケーションによって、又は、インターネットなどのネットワークを通じてアクセス可能なサービスによって提供されるサービスである。プロセスによって使用される外部サービスが存在しない場合、シーケンスはブロック５５５にて終了する。そうでない場合、シーケンスはブロック５４５へ続く。

ブロック５４５で、統合シーケンスが使用可能にされる。統合シーケンスは、プロセスを実行するソフトウェア・アプリケーションと外部サービスの間の接続を可能にする。

図１１Ａは、統合シーケンスの一実施形態を示す。統合シーケンスは、外部システムからメッセージを受け取り、メッセージを共通オブジェクトに変換し、その後、共通オブジェクトを別のシステム表現に変換しそれを送出する。もちろん、統合シーケンスは、コンディション、フォーキング、ルーピング、その他同様なソフトウェア構成概念を含んでもよい。見てわかるように、スイム・レーン１１１０は、この例では、３つのアクティブなシステムを示す。３つのシステムは、外部サービス・プロバイダ１１２０、統合サーバ１１３０、プロセス・プロバイダ１１４０を含む。この例では、外部市場データ供給装置（ｆｅｅｄ）は、統合サーバに市場イベントを定期的に送出する。統合サーバ１１３０は、表現フィルタを使用する一実施形態の場合、データをフィルタリングし、データを、プロセス・プロバイダ１１４０によって受け取られるのに適した形態に変換する。

ブロック５５０で、開発者は、プロンプト表示によって、外部ソースを現在のプロセスと統合するために、ソース、フォーマット、トランスフォームを定義するように指示される。ソースは、外部プロセスのための位置とアクセス・モードを決める。フォーマットは、外部ソースをアドレス指定するためのフォーマット、及び、データが外部ソースから受け取られるフォーマットを識別する。そして、最後に、トランスフォームは、プロセスの固有のフォーマットから外部ソースのフォーマットへ、及び、その逆への変換を作成する。これらの要素がそれぞれ定義されると、開発者は、その後、ビジネス・アナリストによって定義された要素ごとに、外部ソースとの情報伝達を使用可能にする。シーケンスは、その後、ブロック５５５にて終了する。

図１１Ｂは、エキスポート・オプションの一実施形態を示す。統合シーケンスは、第３者によって消費されるために、標準フォーマットで、ウィザード・エキスポート・プロセス定義と関連するメタ・データをエキスポートする。ダイアログ・ボックス１１６０は、エキスポートされる統合シーケンスを識別し、エキスポートのために、フォーマットの指定を可能にする。これは、統合シーケンスが、外部プログラムと関係者に利用可能になるため有用である。

上述のシーケンスは、ビジネス・アナリストによって定義されたプロセスを実装する。一実施形態の場合、品質保証（Ｑ＆Ａ）手順は、プロセスを、開発者によって実装されたものとして認可する。さらに、ビジネス・アナリストは、実装されたプロセスを再調査し、検証するための１回又は複数回の機会が与えらる。プロセスが完全に検証されると、プロセスは、プロセスを使用することになる社員に利用可能になる。さらに、一実施形態の場合、プロセスは、将来のプロセスを構築する時の使用のために利用可能であるプロセスのライブラリ内に置かれる。

図６は、ビジネス・アナリストと開発者の特徴の間の一実施形態の比較を示す。モデラーの目的は異なる。ビジネス・アナリストの場合、モデラーの目的は、カスタマイズされたビジネス・プロセスを作成し、編集することである。開発者の場合、モデラーの目的は、ビジネス・アナリストによって作成されたビジネス・プロセスを実装する／使用可能にすることである。モデラーが統合型モデラーであることは、プロセスと要素の情報伝達は、ビジネス・アナリストと開発者の間で完全であることを意味する。さらに、開発者は、ビジネス・アナリストの作業を再作成する必要がない。従来のシステムでは、ビジネス・アナリストは、実装のために使用されないであろう、視覚プログラムでプロセスをしばしば作成した。これは、ビジネス・アナリストと開発者の間に、情報伝達ギャップならびに２重の労力を生じた。

事業プロセスのビューもまた、ビジネス・アナリストと開発者の間で異なる。ビジネス・アナリストは、各アクターがスイム・レーンを有する、役割に基づくビューを調べ、各要素又はサブ・プロセスは、１つのアクター又は複数のアクターと関連付けられる。これは、ビジネス・アナリストが、誰が各アクションを実施するかをはっきりと可視化することを可能にする。開発者は、一方、システムに基づくビューからプロセスを調べる。システムに基づくビューは、各システムを個別のスイム・レーンで示し、実装されなければならないことになるシステム間の各接続を開発者に示す。

開発者とビジネス・アナリストの間にさらに、ツール・セット識別が存在する。ビジネス・アナリストのツール・セットは、抽象概念が多く、複雑さが少ない、簡略化された、使用するのが容易なツール・セットである。開発者のツール・セットは、完全なツール・セットであり、要素の修正、及び、外部システムとの統合を可能にする。これらのシステムは、外部システム、又は、ビジネス・プロセスを提供するソフトウェア・アプリケーションと統合されたシステムである。

統合に関して、ビジネス・アナリストは、外部サービスの統合に関与する必要はない。むしろ、ビジネス・アナリストは、すべてのサービスが利用可能であり、プロセスによってアクセスされる可能性があると仮定してもよい。開発者は、一方、インターネットを含む外部システムとプロセスとの統合を使用可能にする統合ツールの完全なセットを受け取る。

見てわかるように、統合型プロセス・モデラーは、ビジネス・アナリストと開発者に異なるインターフェースを提供する。しかし、単一プロセス・モデラーの使用は、ビジネス・アナリストと開発者の両方にかなりの利点を提供し、ビジネス・プロセスを作成し、実装するための、より効率的なチームを構築する。

図１２は、本発明と共に使用できるネットワークの一実施形態のブロック図である。ネットワーク１２００は、会社内のイントラネット、インターネット、ケーブル接続、コンピュータ・システム内のバス、共有アプリケーション・バス、又は、同じか、又は、個別のコンピュータ・システム上に存在することができるソフトウェア・アプリケーションを結合する任意の他の手段である。

ビジネス・アナリストのシステム、プロセス・デザイナー１２１０が新しいプロセスを設計するために使用される。システムに結合された複数のプロセス・デザイナー１２１０が存在してもよいが、簡略化のために、ここでは１つのみが示される。一実施形態の場合、プロセス・デザイナー１２１０は、編集のために、プロセスの局所コピー１２１５を使用してもよい。別法として、プロセス・デザイナー１２１０は、ネットワーク１２００を通じて、プロセスを編集するためのセキュアな位置を提供するサンド・ボックス１２５５にアクセスしてもよい。

最善のプラクティス・プロセスは、マスター・プロセス・リポジトリ１５５内で利用可能である。マスター・プロセス・リポジトリ１５５内のプロセスは、一実施形態の場合、事前に作成されたプロセスである。一実施形態の場合、最善のプラクティス・プロセスは、実装された、ビジネス・アナリストによって作成されたプロセスをさらに含んでいる。ビジネス・アナリストがプロセスをチェックインさせると、プロセスは、進行中のプロセスの集合体１３５に格納される。これらのプロセスは、開発者のシステム１２２０上で、開発者による実装を待つ。開発者は、集合体１３５から１つ又は複数のプロセスを取り出し、それらを実装する。開発者１２２０は、編集されるプロセス１２２５の局所コピーを有するか、Ｓｉｅｂｅｌシステム１２５０に接続された個別のサンド・ボックス１２５５を使用してもよい。

一実施形態の場合、品質保証システム１２３０は、実装されたプロセスの試験を可能にする。開発者、Ｑ＆Ａ、ビジネス・アナリストがすべて、プロセスを認可すると、実装されたプロセスは、利用可能なプロセス集合体１２５０内に設置されることによって、利用可能になる。これらの利用可能なプロセス１２５０は、会社全体を通してプロセス・ユーザ１２６０によって使用されて、一定のプロセスが自動化され、会社全体を通して応答の統一性が生まれる。

上記要素は、「システム」として述べられるが、単一コンピュータ・システム上で実装されてもよいことに留意されたい。別法として、単一システムは複数のコンピュータにわたって分散してもよい。

図１３は、本発明と共に使用できるコンピュータ・システムの一実施形態である。しかし、種々のシステム・アーキテクチャの他の代替のシステムが使用されてもよいことが、当業者に明らかになるであろう。

図１３に示すデータ処理システムは、バス又は情報を伝達する他の内部情報伝達手段１３１５、情報を処理するための、バス１３１５に結合したプロセッサ１３１０を含む。システムは、情報及びプロセッサ１３１０によって実行される命令をを記憶するための、バス１３１５に結合したランダム・アクセス・メモリ（ＲＡＭ）又は揮発性記憶デバイス１３５０をさらに備える。主メモリ１３５０はまた、プロセッサ１３１０による命令の実行中に、一時的変数又は他の中間情報を記憶するために使用されてもよい。システムはまた、スタティックな情報とプロセッサ１３１０用の命令を記憶するための、バス１３１５に結合した読み出し専用メモリ（ＲＯＭ）及び／又はスタティック記憶デバイス１３２０、さらには、磁気ディスク又は光ディスク及びその対応するディスク・ドライブなどのデータ記憶デバイス１３２５を備える。データ記憶デバイス１３２５は、情報と命令を記憶するために、バス１３１５に結合される。

システムはさらに、コンピュータ・ユーザに情報を表示するための、バス１３６５を通してバス１３１５に結合した陰極線管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）などのディスプレイ・デバイス１３７０に結合される。英数字及び他のキーを含む、英数字入力デバイス１３７５が、プロセッサ１３１０に情報とコマンド選択を伝達するために、バス１３６５を通してバス１３１５に結合されている。付加的なユーザ入力デバイスは、プロセッサ１３１０に方向情報とコマンド選択を伝達するための、また、ディスプレイ・デバイス１３７０上でのカーソル移動を制御するための、バス１３６５を通してバス１３１５に結合した、マウス、トラックボール、スタイラス、又はカーソル方向キーなどのカーソル制御デバイス１３８０である。

任意選択でコンピュータ・システム１３００に結合することができる別のデバイスは、ネットワークを介して分散システムの他のノードにアクセスする通信デバイス１３９０である。通信デバイス１３９０は、イーサネット（登録商標）、トークン・リング、インターネット、あるいは、ローカル又はワイド・エリア・ネットワークに結合するために使用されるデバイスなどの、多数の市販のネットワーク化周辺デバイスのうちの任意のデバイスを含む。通信デバイス１３９０はさらに、ヌル・モデム接続、無線接続機構、又は、コンピュータ・システム１３００と外部世界の間の結合性を提供する任意の他の機構であってよい。図１３に示すこのシステムの構成部品の任意のもの又はすべて、及び、関連するハードウェアは、本発明の種々の実施形態で使用されてもよいことに留意されたい。

特定の実施態様に従う種々の目的について、システムの任意のコンフィギュレーションを使用してもよいことが、当業者によって理解されるであろう。本発明を実施する制御ロジック又はソフトウェアは、主メモリ１３５０、大容量記憶デバイス１３２５、又は、プロセッサ１３１０に対してローカルに、又は、遠隔でアクセス可能な他の記憶媒体に記憶される可能性がある。

本明細書で述べるシステム、方法、プロセスは、主メモリ１３５０又は読み出し専用メモリ１３２０に記憶され、プロセッサ１３１０によって実行されるソフトウェアとして実装される。この制御ロジック又はソフトウェアはまた、コンピュータ読み取り可能プログラム・コードを埋め込まれているコンピュータ読み取り可能媒体を備え、大容量記憶デバイス１３２５によって読み取り可能で、プロセッサ１３１０が本明細書の方法及び教示に従って動作するようにさせる製造品目上に存在してもよい。

本発明はまた、上述したコンピュータ・ハードウェア構成部品のサブ・セットを収容する手持ち式又は可搬型デバイス内に埋め込まれてもよい。例えば、手持ち式デバイスは、バス１３１５、プロセッサ１３１０、ならび、メモリ１３５０及び／又は１３２５のみを収容するように構成されてもよい。本発明はまた、上述したコンピュータ・ハードウェア構成部品のサブ・セットを含む専用機器内に埋め込まれてもよい。例えば、機器は、プロセッサ１３１０、データ記憶デバイス１３２５、バス１３１５、及び、メモリ１３５０、ならびに、ユーザが基本的な方法でデバイスと通信することを可能にする小型タッチ・スクリーンなどの単に原始的な通信機構を含んでもよい。一部のデバイスでは、ユーザとの通信は、タッチに基づくスクリーン又は同様な機構によってもよい。

特定の実施態様に従う種々の目的について、システムの任意のコンフィギュレーションを使用してもよいことが、当業者によって理解されるであろう。本発明を実施する制御ロジック又はソフトウェアは、プロセッサ１３１０に対してローカルに、又は、遠隔でアクセス可能な任意の機械読み取り式媒体上に記憶される。機械読み取り式媒体は、機械（例えば、コンピュータ）によって読み取り可能な形態で、情報を記憶し、又は、伝送する任意の機構を含んでいる。例えば、機械読み取り式媒体は、読み出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュ・メモリ・デバイス、電気の、音響の、又は、他の形態の伝播信号（例えば、搬送波、赤外信号、デジタル信号など）を含む。

上記明細書では、本発明は、本発明の特定の例示的な実施形態を参照して述べられた。しかし、添付特許請求項に記載される本発明のより広い精神及び範囲から逸脱することなく、実施形態に対して種々の修正及び変更を行ってもよいことが明らかである。明細書及び図面は、したがって、制限の意味ではなく、例示の意味で考えられるべきである。

統合型プロセス・モデラーの一実施形態のブロック図である。 統合型プロセス・モデラーを使用する一実施形態の概要フローチャートである。 ビジネス・アナリストがプロセス・モデラーを使用して、新しいプロセスを作成する一実施形態のフローチャートである。 ビジネス・アナリストがプロセス・モデラーを使用して、新しいプロセスを作成する一実施形態のフローチャートである。 ビジネス・アナリストから実装エンジニアへの責任移管の一実施形態のフローチャートである。 実装エンジニアが、プロセス・モデラーを使用して、ビジネス・アナリストによって作成されたプロセスを使用可能にする一実施形態のフローチャートである。 ビジネス・アナリストと開発者の特徴の間の一実施形態の比較を示す図である。 ビジネス・アナリストに提示されるユーザ・インターフェースの一実施形態を示す図である。 ドリルダウンプロセスを示すユーザ・インターフェースの実施形態を示す図である。 ドリルダウンプロセスを示すユーザ・インターフェースの実施形態を示す図である。 プロセスのどのアスペクトが、実装作業を必要とするかを自動的に示す移管とフラグ立ての一実施形態を示す図である。 実装エンジニアのためのユーザ・インターフェースの実施形態を示す図である。 実装エンジニアのためのユーザ・インターフェースの実施形態を示す図である。 実装エンジニアのためのユーザ・インターフェースの実施形態を示す図である。 実装エンジニアのためのユーザ・インターフェースの実施形態を示す図である。 統合ビューの実施形態を示す図である。 統合ビューの実施形態を示す図である。 本発明と共に使用されることができるネットワークの一実施形態のブロック図である。 本発明と共に使用されることができるコンピュータ・システムの一実施形態のブロック図である。

Claims (37)

1. 非技術系ユーザに設計アスペクトを、技術系ユーザに実装アスペクトを提供し、完全な実行可能プロセスを作成するように設計された垂直統合型プロセス・モデラーを備えるエンド・ツー・エンド・プロセス・モデラー。
2. 前記設計アスペクトは、プロセスを設計するるための第１のツール・セットを備える請求項１に記載のエンド・ツー・エンド・プロセス・モデラー。
3. 前記第１のツール・セットは、役割に基づくビューで前記実行可能プロセスを表示する請求項２に記載のエンド・ツー・エンド・プロセス・モデラー。
4. 前記実装アスペクトは、前記プロセスを実行可能にするための第２のツール・セットを備える請求項１に記載のエンド・ツー・エンド・プロセス・モデラー。
5. 前記第２のツール・セットは、システムに基づくビューで前記実行可能プロセスを表示する請求項４に記載のエンド・ツー・エンド・プロセス・モデラー。
6. 事前に設計された複数の最善のプラクティス・プロセスをさらに含み、前記最善のプラクティス・プロセスは、設計される前記ビジネス・プロセスのための基本として前記非技術系ユーザによって使用可能である請求項１に記載のエンド・ツー・エンド・プロセス・モデラー。
7. 前記非技術系ユーザが前記ビジネス・プロセスを処理する時に、前記非技術系ユーザから前記技術系ユーザに前記ビジネス・プロセスを移管するための移管ロジックをさらに備える請求項１に記載のエンド・ツー・エンド・プロセス・モデラー。
8. 作業を必要とする、前記ビジネス・プロセス内の要素を識別するための検出器をさらに備える請求項７に記載のエンド・ツー・エンド・プロセス・モデラー。
9. 前記要素は、ロジック・ブロックを備え、かつロジック・ブロック間のコネクタのうちの１つ又は複数を備える請求項８に記載のエンド・ツー・エンド・プロセス・モデラー。
10. 前記技術的インターフェースが、それぞれが機能性の原始のセットである個々のステップを示すようにドリルダウンする請求項１に記載のエンド・ツー・エンド・プロセス・モデラー。
11. 前記複雑な実行可能プロセスの前記設計は、ユーザ対話を必要とするステップを含む請求項１に記載のエンド・ツー・エンド・プロセス・モデラー。
12. ユーザ対話を必要とする前記ステップは、前記非技術系ユーザ又は技術系ユーザによって設計されることができる請求項１１に記載のエンド・ツー・エンド・プロセス・モデラー。
13. 前記複雑な実行可能プロセスの前記設計は、他のソフトウェア・アプリケーションの統合をさらに含む請求項１１に記載のエンド・ツー・エンド・プロセス・モデラー。
14. エンド・ツー・エンド・プロセス・モデラーであって、
    複数の事前定義された最善のプラクティス・プロセスと、
    非技術系ユーザが、基礎となるコードとプロセスを理解することなく、ビジネス要求に合致するように最善のプラクティス・プロセスを変更することによって、ビジネス・プロセスを設計することを可能にするエディタと、
    前記非技術系ユーザによって行われた変更によって必要とされる、前記基礎となるコードとプロセスに対する任意の変更を実装するための、技術系ユーザのために設計された実装インターフェースとを備えるエンド・ツー・エンド・プロセス・モデラー。
15. 前記エディタは、前記複数の最善のプラクティス・プロセスからの事前定義された機能性をさらに含み、前記事前定義された機能性は、前記ビジネス・プロセス内に挿入するために前記エディタが利用可能である請求項１４に記載のエンド・ツー・エンド・プロセス・モデラー。
16. 前記ビジネス・プロセスは、ユーザ対話を必要とするステップを含む請求項１４に記載のエンド・ツー・エンド・プロセス・モデラー。
17. ユーザ対話を必要とする前記ステップが、前記エディタ又は前記実装インターフェースを使用することによって設計される請求項１６に記載のエンド・ツー・エンド・プロセス・モデラー。
18. 前記実装ツールは、前記ビジネス・プロセスを外部システムと統合するための統合ツールをさらに含む請求項１４に記載のエンド・ツー・エンド・プロセス・モデラー。
19. 前記外部システムは、第３者プロバイダによって提供される請求項１８に記載のエンド・ツー・エンド・モデラー。
20. 表示し、編集するために、サブ・プロセスへドリルダウンし、かつ、サブ・プロセスのステップへドリルダウンするためのドリルダウン・ロジックをさらに備える請求項１４に記載のエンド・ツー・エンド・モデラー。
21. 完了したビジネス・プロセスを前記非技術系ユーザから受け取り、実装のために、前記完了したビジネス・プロセスを技術系ユーザに渡すチェックイン・ロジックをさらに備える請求項１４に記載のエンド・ツー・エンド・モデラー。
22. 実装のために前記技術系ユーザの注意を必要とする、前記完了したビジネス・プロセス内の要素にフラグを立てる移管とフラギング・ロジックをさらに備える請求項２１に記載のエンド・ツー・エンド・モデラー。
23. 前記フラギング・ロジックは、作業を必要とする要素とコネクタにフラグを立て、前記フラグは、前記要素又はコネクタを実装するために行われるべき作業のタイプを表す請求項２２に記載のエンド・ツー・エンド・モデラー。
24. 編集のために前記技術系ユーザに利用可能な、進行中のプロセスの集合体をさらに含み、前記非技術系ユーザによって仕上げられた完了したビジネス・プロセスは、前記集合体の中に入れられる請求項２１に記載のエンド・ツー・エンド・モデラー。
25. プロセス・モデラーであって、
    非技術系ユーザ用に設計され、ビジネス・プロセスの作成及び編集を可能にする第１のツール・セットと、
    技術系ユーザ用に設計され、前記技術系ユーザが前記ビジネス・プロセスを実装することを可能にするように設計された第２のツール・セットとを備えるプロセス・モデラー。
26. 前記第１のツール・セットは、役割に基づくビューで前記ビジネス・プロセスを表示し、一方、前記第２のツール・セットは、システムに基づくビューで前記ビジネス・プロセスを表示する請求項２５に記載のプロセス・モデラー。
27. 管理者用に設計された第３のツール・セットをさらに備え、その第３のツール・セットが、概観機能を提供し、かつ、複数のビジネス・プロセスをリンクする能力を提供する請求項２５に記載のプロセス・モデラー。
28. 前記ビジネス・プロセスの前記設計は、ユーザ対話を必要とする工程を含む請求項２５に記載のエンド・ツー・エンド・プロセス・モデラー。
29. ユーザ対話を必要とする前記ステップが、前記第１のツール・セット又は前記第２のツール・セットを使用して設計される請求項２８に記載のエンド・ツー・エンド・プロセス・モデラー。
30. 前記ビジネス・プロセスの前記設計は、他のソフトウェア・アプリケーションの統合をさらに含む請求項２８に記載のエンド・ツー・エンド・プロセス・モデラー。
31. プロセス・モデラーであって、
    ビジネス・プロセスを設計する設計ツールを備え、前記ビジネス・プロセスはコネクタによって接続された複数の要素を含み、要素は複数のサブ・プロセスを含み、
    プロセスの種類にわたってドリルダウン、サブ・プロセスを示すために使用されるドリルダウン・ロジックを備えるプロセス・モデラー。
32. 前記ドリルダウン・ロジックは、高レベル・プロセス定義から実行可能な原始ステップまで、プロセスの種類にわたってドリルダウンすることをさらに含む請求項３１に記載のプロセス・モデラー。
33. 前記設計ツールは、役割に基づくモデルを使用して前記ビジネス・プロセスを表示する第１のツールを備え、前記役割に基づくモデルは、役割に従って、前記ビジネス・プロセスのステップを分離する請求項３１に記載のプロセス・モデラー。
34. 前記設計ツールは、システムに基づくモデルを使用して前記ビジネス・プロセスを表示する第２のツールを備え、前記システムに基づくモデルは、システムが前記ステップを実装することに従って、前記ビジネス・プロセスのステップを分離する請求項３３に記載のプロセス・モデラー。
35. 前記ビジネス・プロセスの前記設計は、ユーザ対話を必要とするステップを含む請求項３４に記載のエンド・ツー・エンド・プロセス・モデラー。
36. ユーザ対話を必要とする前記ステップは、前記第１のツール又は前記第２のツールによって設計されることができる請求項３５に記載のエンド・ツー・エンド・プロセス・モデラー。
37. 複雑な実行可能プロセスの前記設計は、他のソフトウェア・アプリケーションの統合をさらに含む請求項３５に記載のエンド・ツー・エンド・プロセス・モデラー。

Images