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

統合型プロセス・モデラーのための方法及び装置 Download PDF

Info

Publication number
JP2006512670A
JP2006512670A JP2004564686A JP2004564686A JP2006512670A JP 2006512670 A JP2006512670 A JP 2006512670A JP 2004564686 A JP2004564686 A JP 2004564686A JP 2004564686 A JP2004564686 A JP 2004564686A JP 2006512670 A JP2006512670 A JP 2006512670A
Authority
JP
Japan
Prior art keywords
modeler
business
processes
user
tool
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2004564686A
Other languages
English (en)
Inventor
レビン,アイザック・スティフィン
デゲンハート,ジョン・レックスフォード
スクリカー,アトゥル
ソーゾン,ピーター・エイ
Original Assignee
シーベル・システムズ・インコーポレーテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/334,953 external-priority patent/US7251787B2/en
Application filed by シーベル・システムズ・インコーポレーテッド filed Critical シーベル・システムズ・インコーポレーテッド
Publication of JP2006512670A publication Critical patent/JP2006512670A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B17/00Systems involving the use of models or simulators of said systems
    • G05B17/02Systems involving the use of models or simulators of said systems electric
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/10Requirements analysis; Specification techniques

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Automation & Control Theory (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

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

Description

本発明は、モデル化に関し、より詳細には、複雑なプロセスのモデル化に関する。
一般に、組織のエコシステム内でフォローされるプロセスは、ほとんどの事業環境において、種々の形態で記述される。このタイプのモデル化は、会社が事業にわたって統一性のあるプロセスを作成することを試みるため、ますます重要になりつつある。
例えば、ビジネス・アナリストは、VisioやiGrafxなどのツールを使用して、ビジネス・プロセスのためのプロセス・フローを作成することができる。しかし、こうしたプロセスを自動化するために、BizTalk又は同様なツールなどの、異なるツールを使用しなければならない。
しかし、こうしたプロセスを移管することは難しい。ビジネス・アナリストは、プロセスのステップのそれぞれが何を意味するかを開発者に説明しなければならない。そして、開発者は、自動化されたプロセスを作成し、自動化されたプロセスが、ビジネス・アナリストが概略を示したプロセスを実際にフォローするために他の社員によって使用される。このプロセスは、長くかつ複雑であり、情報伝達の誤りは再作業を生成し、それによって、実現が遅延する。
さらに、Siebelなどの一部の会社は、企業に最善のプラクティスを提供する場合がある。これらの最善のプラクティスは、種々のアクションについて、フォローされる自動化されたプロセスである。しかし、これらのプロセスは、顧客の要求に完全には合致しない場合があり、一般に、修正するのが難しい。
非技術系ユーザに設計アスペクトを、技術系ユーザに実装アスペクトを提供し、完全な実行可能プロセスを作成するように設計された垂直統合型プロセス・モデラーを備えるエンド・ツー・エンド・プロセス・モデラー。
本発明は、添付図面の図において、制限としてではなく、例として示され、図では、同じ参照数字は同じ要素を指す。
統合型プロセス・モデラーのための方法と装置が述べられる。プロセス・モデラーは、設計し、デバッグし、エンド・ツー・エンド・ビジネス・プロセスを展開する単一ツールを提供する。この文脈では、ビジネス・プロセスは、特定のビジネスの目標を達成するために編成され、構造化された一連の文書化された活動である。任意の特定の目標物を実行するのに多くのプラクティスが存在するため、特定のビジネス・プロセスの構造は、会社によって変わる場合がある。複数のサブ・プロセスからなる可能性があるビジネス・プロセスは、フロー図でグラフィカルに表され、第3者アプリケーションに及ぶ可能性がある。エンド・ツー・エンド・ビジネス・プロセスは、会社にとって主要なビジネス・プロセスであり、会社の法的境界の中や、外での複数の部門又は組織に及ぶ場合がある。エンド・ツー・エンド・ビジネス・プロセスはまた、自律的にか、エンドユーザによってのいずれかで実行する複数の相互接続したコンピュータ・システムとの対話を含む。エンド・ツー・エンド・ビジネス・プロセスは、通常、数分又は数秒ではなく、数時間、数日、数週間、又は数ヶ月にわたって発生する長期にわたるプロセスである。本発明は、こうしたエンド・ツー・エンド・ビジネス・プロセスだけでなく、より単純な基本ビジネス・プロセスの設計を可能にする。
エンド・ツー・エンド・ビジネス・プロセスを使用することによって、モデラーは、複数のプロセス・タイプ(例えば、事業、Siebel、統合、タスク)、ならびに、複数の役割(例えば、ビジネス・アナリスト、開発者)に及び、これらの構成要素間でのシームレスな移行を可能にする。
プロセス・モデラーは、ユーザ対話を含むプロセス・フロー(例えば、作成コール・リスト・タスク)を設計することが可能である。ユーザ対話の設計は、ユーザ・インターフェースや、特定のユーザから特定のタイプの入力を待つことを必要とするプロセス・ステップを含む。一実施形態の場合、非技術系及び技術系ユーザは共に、これらのユーザ対話フローを設計する可能性がある。プロセス・モデラーは、ユーザ対話ならびに他のアプリケーションとの統合を作成する能力を含む。
図1は、統合型プロセス・モデラーの一実施形態のブロック図である。プロセス・モデラー100は、どのタイプのインターフェースがユーザに提示されるかを判断するユーザ識別ロジック110を含む。ビジネス・アナリスト・インターフェース130は、新しいプロセスの設計や、既存のプロセスの編集を可能にする。開発者インターフェース160は、アナリストによって設計されたプロセスの実装及び統合を可能にする。
一実施形態の場合、ユーザ識別ロジック110は、ユーザ・タイプを識別するために、ユーザのログインとグループ・アソシエーションを使用する。別の実施形態の場合、ユーザは、自分の好みのインターフェースを選択することができる。別の実施形態の場合、モデラー100を利用することができる各ユーザは、ユーザ識別ロジック110に対して指定される。そのため、ユーザ・インターフェースを選択することに加えて、ユーザ識別ロジック110は、セキュリティ機能を提供する。これは、権限のないユーザが、任意のプロセスを変更するか、又は、新しくかつ不正なプロセスを作成することを防止する。
上述した、ビジネス・アナリスト・インターフェース130は、ビジネス・アナリスト又は同等な個人が、プロセスを作成することを可能にする。このインターフェース130はまた、ユーザがプロセスを編集し又は作成するため、「エディタ」と呼ばれる場合がある。「ビジネス・アナリスト」という用語は、企業による使用のために、プロセスを作成するように権限を与えられた個人のことを言う。一般に、こうした人は、エンジニア又はプログラマである必要はないので、したがって、非技術系ユーザと呼ばれるであろう。しかし、ビジネス・アナリストは、もちろん、プログラマであっても、又は、技術的に詳しくてもよい。「非技術系ユーザ」という用語は、ビジネス・アナリストが、プロセスを作成するか、又は、編集するためにプログラミングを知る必要がないことを規定するのに単に使用される。
このプロセスは、会社の内部又は外部で一定の手順を自動化するように設計される。プロセスは、例えば、売買要求を達成するプロセスである。この例は、本明細書全体を通して使用されるであろう。しかし、任意の手順が自動化されてもよいことが理解されるばきである。
一実施形態の場合、モデラー100は、最善のプラクティス・プロセスのライブラリ135へアクセスする。最善のプラクティス・プロセスは事前に定義されたプロセスである。一実施形態の場合、Siebelなどの会社は、そのクライアントに事前に定義された複数の最善のプラクティス・プロセスを提供する。これらのクライアントは、その後、最善のプラクティス・プロセスをカスタマイズし変更するために、ビジネス・アナリスト・インターフェース130を使用するか、又は、最善のプラクティス・プロセスを採用するように選択する。ライブラリ135は、ビジネス・アナリスト・インターフェース130に利用可能である。一実施形態の場合、最善のプラクティス・プロセス全体をインポートすることができることに加えて、ビジネス・アナリストは、ライブラリ135からサブ・プロセスを選ぶ場合がある。例えば、サブ・プロセスは、「スーパバイザによって確認される」。サブ・プロセスは内部に複数のステップを有する。例えば、確認することは、emailを送出すること、応答を待つこと、さらに、適切な応答が受信された場合、確認を通知することを含む。
ドリルダウン・ロジック120は、ビジネス・アナリストが、サブ・プロセスからステップへ進むことを可能にする。一般に、プロセスは、一連のステップとして示される。各ステップは、1つ又は複数のステップあるいはサブ・ステップを有してもよい。ビジネス・アナリストは、ビジネス・アナリスト・インターフェース130を使用して、プロセスからサブ・プロセスへ、サブ・プロセスからステップへドリルダウンする。ビジネス・アナリストに対して示される種々のユーザ・インターフェースが以下で述べられる。
ビジネス・アナリストがプロセスの設計を完了すると、ビジネス・アナリストは、チェックイン・ロジック140を使用して、プロセスをチェックインさせる。チェックインするということは、プロセスが完了したとの指示のことを言う。バリデーション・ロジック145は、プロセスが一定の基本的基準を満たすことを検証する。例えば、バリデーション・ロジック145は、各要素が少なくとも1つの他の要素に接続されていることを検証する。バリデーション・ロジック145はまた、明確な端点を持っていないコネクタが存在しないことを検証する。さらに、一実施形態の場合、バリデーション・ロジック145は、任意の「決定要素」が、2つの出力コネクタを有することを検証する場合があり、1つのコネクタがそれぞれの可能性のある結果をもたらす。バリデーション・ロジック145は、あるエラーが存在すると判断すると、プロセスをビジネス・アナリスト・インターフェース130に戻るように渡し、指示されたエラーを訂正することをビジネス・アナリストに通知する。一実施形態の場合、バリデーション・ロジック145は、任意のエラーにフラグを立てるか、又は、その他の方法で、何がなされる必要があるかに関する指示を提供する。
バリデーション・ロジック145は、エラーが存在しないと判断すると、プロセスを移管とフラギング・ロジック150に渡す。
移管とフラギング・ロジック150は、プロセスを、進行中のプロセスの集合体155に移管する。一実施形態の場合、実装を完了しなかったプロセスは、集合体155内に格納される。この集合体は、実装のために、開発者がアクセス可能であり、一実施形態の場合、さらなる編集のためにビジネス・アナリストがアクセス可能である。しかし、進行中のこれらのプロセス155は、一般に、会社がアクセス可能ではなく、使用されない。
一実施形態の場合、移管とフラギング・ロジック150はさらに、プロセスにフラグを立てる。フラグを立てることは、実装のための作業を必要とする各要素及び/又は各コネクタをマークすることである。一実施形態の場合、複数のタイプのフラグが存在し、各フラグは、行われる必要がある作業のタイプを指示する。例えば、フラグは、実行可能な意味付けについて、不十分な詳細が提供されたことを指示する。別法として、フラグは、特定の情報伝達が規定される必要があることを指示する。例えば、ビジネス・アナリストは、要素を「接触スーパバイザ」として規定するが、このタスクを達成する方法についての規定を提供しない。このフラグは、その後、適切な要素とコネクタ上で作業するために開発者によって使用される。プロセスのこのフラグを立てられたバージョンは、その後、集合体155内に格納される。
開発者は、開発者インターフェース160を通して進行中のプロセスを集合体155から集める。「開発者」という用語は、簡略化のために本明細書で使用される。「開発者」は、実行可能プロセスを作成することができる任意のユーザである。一般に、開発者は、プログラマなどの技術系ユーザである。開発者インターフェース160はまた、プロセスを実行可能プロセスに実装するのに使用されるために、実装インターフェース160と呼ばれる。
一実施形態の場合、プロセスは、実装のために、特定の開発者又は開発者のチームに割り当てられる。その場合、ユーザ識別ロジック110は、開発者が、特定のプロセスに対してアクセスする/作業するかどうかを制御する。
開発者160は、プロセスを実行可能にするために、プロセスを編集する。さらに、開発者は、ドリルダウン・ロジック120を使用して、使用される要素とサブ・プロセスを調べる。一実施形態の場合、開発者はさらに、ライブラリ135内で規定された既存のプロセスとサブ・プロセスにアクセスする。これは、以前に規定したステップとサブ・プロセスの再使用を可能にする。
統合ロジック165は、開発者が、プロセスを第3者のアプリケーションとソフトウェアを統合することを可能にする。例えば、統合ロジック165は、プロセスが、インターネットなどの外部データ源からデータを取得することを可能にする。例えば、在庫価格がインターネット源から取得され、このデータを、プロセス内で使用する。
開発者が、プロセスを使用可能にすることを完了すると、プロセスは、使用のために利用可能になる。一実施形態の場合、ビジネス・アナリスト又はスーパバイザは、最終的な承認を行わなければならない。一実施形態の場合、品質保証チームはさらに、プロセスに関して試験を実施する。プロセスが承認されると、プロセスを、企業内で実装できる。これは、プロセスが、種々のユーザに対して利用可能になっていることを意味する。一実施形態の場合、こうしたプロセスはさらに、ライブラリ135内に置かれて、プロセス内での種々のステップの再使用が可能になる。
こうして、本統合型プロセス・モデラー100は、ビジネス・アナリストが、プロセスを作成することを可能にし、開発者が、プロセスを実行可能にさせる。その結果得られるプロセスは、会社全体を通して使用できる。
図2は、統合型プロセス・モデラーを使用する一実施形態の概要フローチャートである。シーケンスはブロック210で開始する。ブロック215で、最善のプラクティス・プロセスが利用可能にされる。一実施形態の場合、最善のプラクティスはライブラリに格納され、使用し、編集し、又は、ステップを抽出するために利用可能である。
ブロック220で、シーケンスは、ユーザが編集するための最善のプラクティス・プロセスを選択したかどうかを判断する。選択した場合、ブロック225で、選択されたプロセスがユーザに示され、編集が使用可能にされる。一実施形態の場合、選択されたプロセスの高レベル図が表示される。ユーザは、その後、プロセスのステップのうちの任意のステップ、又は、プロセス内のサブ・プロセスのうちの任意のサブ・プロセスを編集する。ユーザが最小のプラクティス・プロセスを選択しなかった場合、シーケンスはブロック230へ続く。
ブロック230で、システムは、プロセス内に取り入れられた種々の手順とサブ・プロセスの作成と編集を可能にする。プロセスが選択されなかった場合、ユーザは、この時点で、まったく新しいプロセスを作成することを望む。この例におけるユーザは、プログラマ又は技術系ユーザである必要はない。むしろ、ユーザは、会社において、どんなタイプの手順が使用されているかを知っているビジネス担当者又は管理者であってよい。
ブロック235で、シーケンスは、ユーザがプロセスをチェックインさせたかどうかを判断する。チェックインするということは、ユーザがプロセスを編集することを完了し、プロセスが手放されてもよいことを指示する。一実施形態の場合、ユーザは、「使用可能にされるべき」ディレクトリなどの、特別な位置にプロセスを格納することによって、これを指示してもよい。ユーザがプロセスをいまだチャックインさせていない場合、シーケンスはブロック230に戻り、さらなる編集を可能にする。もちろん、ユーザは、不完全なプロセスを一時的に格納し、後でアクセスしてもよい。
ユーザがプロセスをチェックインさせた場合、シーケンスは、ブロック240へ続く。ブロック240で、シーケンスは、実行可能でないか、又は、十分に定義されていない、コネクタとステップを識別し、コネクタとステップにフラグを立てる。
ブロック245で、インプリメンタ、又は、技術系ユーザは、それぞれのフラグの立ったアイテムを完了するようにプロンプト表示によって指示される。インプリメンタは、一般に、進行中のプロセスの集合体からプロセスをチェックアウトさせることに留意されたい。フラグは、プロンプト表示してインプリメンタにプロセスを完了するように指示し、一実施形態の場合、完了のために行われる必要がある作業のタイプを識別する。
ブロック250で、シーケンスは、ユーザがプロセスをチェックインさせたかどうかを判断する。一実施形態の場合、技術系ユーザは、実装を完了すると、プロセスを再びチェックインさせる。一実施形態の場合、この例では、チェックインすることは、プロセスに対して品質保証/試験を実施すること、及び、管理者などの適切な個人から最終的な同意を得ることを含む。プロセスがいまだチェックインされていない場合、シーケンスはブロック245に戻り、さらなる編集が可能になる。
プロセスがチェックインされている場合、シーケンスは、ブロック255へ続き、完了したプロセスがユーザに利用可能にされる。これらのユーザは、例えば、プロセスを使用して、一貫性がありかつ完璧な顧客サポートを提供する顧客サポート要員である。一実施形態の場合、各プロセスは、特定の社員のグループを対象とし、一貫性があり、完全で、訓練するのが容易で、使用するのが容易なプロセスを生ずる。シーケンスは、その後、ブロック260にて終了する。
図3A、図3Bは、ビジネス・アナリストが、プロセス・モデラーを使用して、新しいプロセスを作成する一実施形態のフローチャートである。シーケンスは、ブロック310で開始する。この時、ビジネス・アナリスト又は権限のある社員がシステムにログインする。
ブロック315で、最善のプラクティス・プロセスが、ユーザに利用可能にされる。このライブラリは、ビジネス・アナリストがアクセス可能であり、既存のプロセスを最高性能を発揮するように調整する(tweak)こと、既存のプロセスに基づいて新しいプロセスを作成すること、あるいは、既存のプロセスからのステップ又はサブ・プロセスを単に使用することが可能になる。こうした再利用が可能になることによって、新しいプロセスの作成が大幅に簡略化される。
ブロック320で、シーケンスは、編集すべきプロセスを選択したかどうかを判断し、選択した場合、ブロック325で、選択されたプロセスがユーザに表示される。一実施形態の場合、選択されたプロセスは、高レベル・プロセスを示し、ドリルダウンによって達することができる複数のサブ・プロセスを含む。シーケンスは、その後、ブロック330へ続く。ユーザが、編集すべきプロセスを選択しなかった場合、シーケンスは、直接、ブロック330へ続く。
ブロック330で、実行可能状態(shape)を含むユーザ・インターフェースがユーザに表示される。こうしたディスプレイの例示的な実施形態は、図7に示される。
図7を見てわかるように、ツール・ボックス710は、プロセスとコネクタのセットを提示する。一実施形態の場合、ツール・ボックス710はさらに、付加的なスイム・レーンの作成を可能にする。スイム・レーン720は、種々のアクター又は種々のシステム間の識別を提供する。この役割に基づくビューでは、スイム・レーン720は、顧客、ブローカ、口座などのようなアクターを規定する。ビジネス・アナリストは、ツール・ボックス710を使用して付加的なスイム・レーン720を追加してもよい。図7を見てわかるように、プロセス730は、開始点、いくつかの要素740、いくつかの要素740間のコネクタ750を含む。見てわかるように、プロセスに付加することができる種々のタイプの機能又は要素は異なる形状を有する。一実施形態の場合、形状と色を使用して、種々のタイプの機能を識別してもよい。
ブロック335で、ユーザは、プロセスのライブラリ内のサブ・プロセスの既存のリストから既存のサブ・プロセス又はステップを選択することができる。これは、ユーザが、プロセスを新たに設計する代わりに、十分に機能するプロセスを挿入するだけであるため、実装を簡略化する。ユーザが挿入のためにサブ・プロセスを選択しなかった場合、シーケンスは、ブロック355へ続く。そうでない場合、シーケンスは、ブロック345に続く。
ブロック345で、サブ・セットのすべてを含むサブ・プロセスと要素は、指示された位置に挿入される。一実施形態の場合、サブ・プロセスが挿入されるべき位置を指示するためにユーザによってプレース・ホルダ挿入される。そのため、ユーザは、最初に、適切な位置にプレース・ホルダを置き、その後、プレース・ホルダの位置に挿入されるサブ・プロセスを選択する。
ブロック350で、ユーザは、プロンプト表示によって、挿入されたサブ・プロセスに適切に接続するのに必要とされる任意の接続を行うように指示される。各プロセスとステップは、プロセスのフローを提供するために、1つ又は複数の接続を有する。挿入されたサブ・プロセスは、一般に、少なくとも1つ、任意の数のコネクタを有する。ユーザは、プロンプト表示によって、これらのコネクタのそれぞれを接続するように指示される。一実施形態の場合、コネクタは、行われている接続のタイプを指示するタグ又はフラグを含む。シーケンスは、その後、ブロック355へ続く。
ブロック355で、ユーザは、1つ又は複数のステップ、接続、プロセス、プロセス内のサブ・プロセスすなわちサブステップを編集することが可能になる。
ブロック360で、シーケンスは、ユーザがドリルダウンすることを選択したかどうかを判断する。ドリルダウンは、プロセスの特定の要素を形成するサブ・ステップ/サブ・プロセスを示す。ユーザがドリルダウンを行う場合、ブロック365で、要素を形成するサブ・ステップ/サブ・プロセスと共にドリルダウンインターフェースが示される。図8A、8Bは、2つのレベルのドリルダウンを示す。
図8Aは、図7に示す「作成コール・リスト」プロセス・ステップをドリルダウンすることによって達したプロセス・コンフィギュレーション・インターフェースの一実施形態を示す。見てわかるように、プロパティ・ダイアログ・ボックス810は、ビジネス・アナリストにタスクの記述/定義を提供する。汎用タブ820が、タスクの基本的記述を提供する。割り当てタブ830は、このタスクを実施するために誰が割り当てられるべきかを決める。一実施形態の場合、これは、タスクがどのスイム・レーンを禁止するかを指示する。通知タブ840は、このタスクが実施される時に誰かが通知されるべきかどうかを指示し、一方、ページ・タブは、このタスクが、プロセス中のどこで起こるべきかを指示する。これは、タスクがさらされるページと条件を指示する。スレッド・バー860は、ビジネス・アナリストがいるプロセス内の場所を指示する。
図8Bは、タスクのコンフィギュレーションの一実施形態を示す。コンフィギュレーション・インターフェースは、2つのタブを含むツール・ボックス710を含み、1つのタブは、上記図8Aにも示されるビジネス・プロセス870用であり、1つのタブは、ここで示されるユーザ・インターフェース(UI)プロセス875用である。タスク・プロセス・コンフィギュレーション窓880は、タスク・プロセスをコンフィギュレーションするためのインターフェースであり、UIコンフィギュレーション窓890は、ページをコンフィギュレーションするためのインターフェースである。これは、一旦実装されると、プロセスを使用しているユーザに対して表示されることになるページである。ビジネス・アナリストは、UIを作成し、任意のアスペクトを指定する。一実施形態の場合、ビジネス・アナリストは、こうして作成されたユーザ・インターフェースをプレビューし、ユーザ・インターフェースを開始する。
図3に戻ると、ユーザが、ドリルダウンすることを選択すると、上述したページが表示される。シーケンスは、その後、ブロック355に戻り、ユーザが、サブ・ステップ/サブ・プロセスを編集することが可能になる。ユーザが、ドリルダウンすることを選択しなかった場合、シーケンスは、ブロック370へ続く。
ブロック370で、シーケンスは、編集が完了したことをユーザが指示したかどうかを判断する。ユーザは、一旦プロセスに満足すると、編集が完了したことを指示する可能性がある。ユーザがこれを指示しなかった場合、シーケンスは、ブロック355へ続き、ユーザが、ステップをさらに編集する/作成することが可能になる。もちろん、ユーザは、いつでもブロック340に戻り、付加されるサブ・プロセスを選択してもよい。こうしたフローチャートでは一般に当てはまるが、決定ブロックは、実際には、割り込みとして実装され、いつでも起こってよい。そのため、ユーザは、いつでも、サブ・プロセスを付加するように選択し、ドリルダウンするように選択し、又は、編集が完了していることを指示するように選択してもよい。
ユーザが、編集が完了していることを指示する場合、シーケンスは、ブロック375へ続く。ブロック375で、シーケンスは、すべてのブロックが、論理的に接続されている、例えば、すべてのブロックが少なくとも1つのコネクタに接続されているか、また、すべてのコネクタがあるブロックに結合している、例えば、接続されずにぶら下がっているコネクタが存在しないかどうかを判断する。一実施形態の場合、システムはさらに、プロセスが、適切に開始し、終了したことを検証する。これらの条件のいずれもが満たされない場合、シーケンスは、ブロック380へ続き、そこで、ユーザは、プロンプト表示によって、これらのエラーを訂正するように指示される。一実施形態の場合、フラグ又はタグは、訂正されるべきエラーのそれぞれを指示する。シーケンスは、その後、ブロック355へ続き、ユーザがプロセスを編集し、訂正することを可能にする。
ブロックが、適切に接続され、終了した場合、シーケンスは、ブロック385で終了する。一実施形態の場合、プロセスは、図4に述べる、フラギング・ロジックに送られる。
図4は、ビジネス・アナリストから実装エンジニアへの責任の移管の一実施形態のフローチャートである。シーケンスは、ブロック410で開始する。ブロック415で、チェックイン完了プロセスがビジネス・アナリストから受け取られる。もちろん本シーケンスはいつでも実行できる。一実施形態の場合、本シーケンスは、完了すると自動的に始動するが、まだ実装されていないプロセスは、ビジネス・アナリストから受け取られる。
ブロック420で、シーケンスは、最善のプラクティス・プロセスからではない要素が存在するかどうかを判断する。チェックイン・プロセスが最善のプラクティス・プロセスと同じである。この例では、定義上、最善のプラクティス・プロセスが既に実装されているため、実装は必要とされない。
新しい要素が存在しない場合、シーケンスは、ブロック425で、接続のうちの任意の接続が変更されたかどうかを判断する。各プロセスは、コネクタによって相互接続された複数の要素からなる。要素もコネクタも変更されなかった場合、実装は必要とされない。そのため、シーケンスは、直接、ブロック460へ進み、終了する。
ブロック420における要素か、ブロック425における接続のいずれかが変更された場合、シーケンスは、ブロック430へ続く。
ブロック430で、プロセスは全体が分析される。
ブロック435で、シーケンスは、任意の部分すなわち論理ステップが抜けているかどうかを判断する。ビジネス・アナリストは、エラー・チェック又はデータ・バリデーションなどのステップを考えることに失敗する。こうしたステップが抜けている場合、シーケンスは、開発者のために、抜けている要素とフラグを識別するためのブロック440へ続く。一実施形態の場合、抜けている部分/論理ステップを識別する汎用ノートが、プロセスに添付される。別法として、シーケンスは、こうした部分/論理ステップが挿入される位置においてフラグを付加する。部分/ステップが抜けていない場合、シーケンスはブロック445へ続く。
ブロック445で、ビジネス・アナリストによって付加された新しいステップ又は接続が識別される。一実施形態の場合、シーケンスは、全体のプロセスをステップごとにウォークスルーを行って、任意の新しいステップを識別する。一実施形態の場合、シーケンスは、最下位のドリルダウンレベルにおいてこのウォークスルーを実施する。
ブロック450で、シーケンスは、ステップ/接続が付加的な作業を必要とするかどうかを判断する。一実施形態の場合、シーケンスは、ステップ又は接続が、既存の最善のプラクティス・プロセスからインポートされる。インポートされる場合、シーケンスは、付加的な作業が必要とされないと判断する。ステップ/接続が新しく作成される場合、一実施形態の場合、付加的な作業を必要とするとしてステップ/接続が識別される。別の実施形態の場合、システムは、さらなる分析を実施して、新しく作成された接続/ステップが作業を必要とするかどうかを判断してもよい。一実施形態の場合、システムは、付加的な作業が必要とされるかどうかを判断するステップを実行しようと試みてもよい。特定のステップ/接続が、機能し/実装されているかどうかを識別する代替の方法が使用されてもよい。ステップが作業を必要とする場合、ブロック465で、ステップ又は接続にフラグが立てられる。一実施形態の場合、フラグは、ステップ/接続を実装するのに必要とされる作業のタイプを指定してもよい。例えば、フラグは、接続が、ウェブ・サービスなどの外部サービスとの統合を必要とすることを識別してもよい。
ブロック455で、シーケンスは、分析されるべきである任意のさらなるステップ/接続が存在するかどうかを判断する。さらなるステップが存在する場合、シーケンスは、新しいステップ/接続を識別するブロック445に戻る。さらなるステップが存在しない場合、フラグ立てシーケンスが完了し、ブロック460で、シーケンスが終了する。
図9は、フラグ立てが完了した後のプロセスの一実施形態を示す。見てわかるように、多数の要素740と要素750がフラグを立てられている910〜950。アイコン910〜950は、開発者に視覚フィードバックを提供し、異なるタイプの作業が行われる必要があることを意味する。一実施形態の場合、任意の形状が、形状に並んでアイコンを潜在的に有する。この例では、アイコン910〜950は、種々の形状で表記される。別の実施形態の場合、異なる形状を使用する代わりに、又は、使用すると共に、色、シンボル、又は、他の識別器が使用されてもよい。
図5は、実装エンジニアが、プロセス・モデラーを使用して、ビジネス・アナリストによって作成されたプロセスを使用可能にする、一実施形態のフローチャートである。シーケンスはブロック510にて開始する。一実施形態の場合、このシーケンスは、いまだ実装されておらず、ビジネス・アナリストによってチェックインされたプロセスが存在する時はいつでも利用可能である。
ブロック515で、フラグ立てプロセスがシステムから受け取られる。一実施形態の場合、開発者は、実装のためのプロセスを選択してもよい。一実施形態の場合、プロセスは、特定の開発者に割り当てられる。別の実施形態の場合、各プロセスは、優先度スタンプ又は同様な優先度の指示を有している。そのため、開発者は、プロンプト表示によって、最も緊急の又は最も高い優先度のプロセスを実装するように指示される。開発者は、ブロック515で、実装のためにプロセスをチェックアウトさせる。
ブロック520で、プロセスのシステム・ビューが表示される。図10Aは、開発者に示される、プロセスのシステム・ビューの一実施形態を示す。見てわかるように、スイム・レーン・ラベルは、プロセスのそれぞれを処理するシステムに対応するように変わる。一実施形態の場合、プロセス・モデラーは、技術的インターフェース・ディスプレイを自動的に導出し、各スイム・レーンは、非技術的インターフェース・ディスプレイを通してシステムを識別し、各スイム・レーンは、アクターを識別する。一実施形態の場合、この導出プロセスは、非技術的インターフェース内の機能ブロックを使用し、機能ブロックは、機能ブロックが関連するシステムを識別するように(色、形状などによって)フラグが立てられる。
一実施形態の場合、設計者は、統合サーバを通過するフローの部分を表示するかどうかに関する設計者の好みを設定してもよい。一実施形態の場合、システムは、ビジネス・アナリストによって提供される基本データから統合ステップを自動的に生成する。システムは、2つのステップの間のどこで統合サーバが必要とされるかを自動的に推論する。一実施形態の場合、システムはさらに、同期化ステップを表示してもよい。同期化ステップは、一貫性のある状態を保つために、統合サーバが種々のシステムのどこでデータを同期させるかを指示する。
一実施形態の場合、「顧客」スイム・レーンは、異なるタイプの「システム」である、例えば、設計者の制御下にあるシステムではないことを指示するために識別される。この図では、「システム」は、実際のシステムではなく、論理システム・タイプである。代替法では、実際のシステム(例えば、サーバ、Siebelシステム、SAPなど)が指示される。個別のスイム・レーンが、システムの特定の例を必ずしも指示しないことにも留意されたい。例えば、CRM(顧客関係管理)システムは、2つの個別のシステム、コール・センターとサービス機関である。開発者は、開発者のオプションによって、CRMスイム・レーンを複数のレーンに分離する。このタイプのシステムへの論理的分離は、開発者に対して、ビジネス・アナリストによって定義されたプロセスを実装するのに要求されることになるシステム・インターフェース要素を示す。
プロセスのシステム・ビューは、各スイム・レーンにおいて、異なるシステムを示す。システムは、Siebelシステム、第3者システム、インターネットなどの外部システムを含んでもよい。システム・ビューは、各ステップ及び接続について、どのシステムがステップ/接続を実施するかについての識別情報を提供する。
図5に戻ると、ブロック525で、シーケンスは、任意のアイテムが付加される必要があるかどうかを判断する。先に述べたように、移管/フラグ立てシーケンスは、論理的プロセス/ステップが抜けていることを指示する1つ又は複数のフラグを付加した。さらに、開発者は、プロセスを再調査する時に、付加的な要素が必要とされると判断する。必要とされる場合、ブロック530で、開発者は、プロンプト表示によって、付加的な要素を追加するように指示される。付加的な要素は、エラー訂正、チェック、認証、又は、任意の他の必要とされる要素である。
図10Bは、利用可能なプロセスのライブラリをブラウジングする開発者のための可能性のあるインターフェースの一実施形態を示す。プロセス・ツリー1030は、利用可能な種々のプロセス、及び、各プロセス内で利用可能なサブ・プロセス及びタスク/ステップを示す。プレビュー窓1040は、開発者が、プロセスを調べ、必要である場合、付加的な詳細を調べるためにドリルダウンすることを可能にする。開発者は、全体のプロセス又はサブ・プロセスを使用するか、又は、着想のためか、又は、特定の詳細のために、プロセス又はサブ・プロセスをデータ・マイニングするだけであってもよい。プロセス・リスト1035は、プロセスの現在の位置(複数可)及び任意のコメントを含む、ツリー1030の現在の分岐で利用可能であるプロセスのリストを提供する。
ブロック535で、シーケンスは、開発者が、詳細を付加し、ビジネス・アナリストによって定義された要素とコネクタを実装することを可能にする。識別された機能又はステップを実施するように要素を実装する技能は、開発者によって知られている技能である。本システムは、ビジネス・アナリストと開発者の間の機能/ステップ定義の移管が完全であることを保証する。
図10Cは、開発者のための、ユーザ・インターフェース・コンフィギュレーション窓の一実施形態を示す。見てわかるように、ツール・ボックス1050は、ビジネス・プロセス1060とユーザ・インターフェース・コントロール1065に加えて、データ・バインディング1070を含む。図10Dは、データ・バインディングの一実施形態を示す。データ・マッピング・インターフェース1080は、ページ・オブジェクト(コントロール)への、ビジネス・オブジェクトのドラッグ及びドロップ式データ・バインディングを可能にする。見てわかるように、種々のページ・オブジェクトは、特定のページ・オブジェクトを定義する時にさらなる作業が必要とされることを、上述のように指示するフラグ1090を有してもよい。
ブロック540で、シーケンスは、外部サービスが使用されるかどうかを判断する。外部サービスは、他のソフトウェア・アプリケーションによって、又は、インターネットなどのネットワークを通じてアクセス可能なサービスによって提供されるサービスである。プロセスによって使用される外部サービスが存在しない場合、シーケンスはブロック555にて終了する。そうでない場合、シーケンスはブロック545へ続く。
ブロック545で、統合シーケンスが使用可能にされる。統合シーケンスは、プロセスを実行するソフトウェア・アプリケーションと外部サービスの間の接続を可能にする。
図11Aは、統合シーケンスの一実施形態を示す。統合シーケンスは、外部システムからメッセージを受け取り、メッセージを共通オブジェクトに変換し、その後、共通オブジェクトを別のシステム表現に変換しそれを送出する。もちろん、統合シーケンスは、コンディション、フォーキング、ルーピング、その他同様なソフトウェア構成概念を含んでもよい。見てわかるように、スイム・レーン1110は、この例では、3つのアクティブなシステムを示す。3つのシステムは、外部サービス・プロバイダ1120、統合サーバ1130、プロセス・プロバイダ1140を含む。この例では、外部市場データ供給装置(feed)は、統合サーバに市場イベントを定期的に送出する。統合サーバ1130は、表現フィルタを使用する一実施形態の場合、データをフィルタリングし、データを、プロセス・プロバイダ1140によって受け取られるのに適した形態に変換する。
ブロック550で、開発者は、プロンプト表示によって、外部ソースを現在のプロセスと統合するために、ソース、フォーマット、トランスフォームを定義するように指示される。ソースは、外部プロセスのための位置とアクセス・モードを決める。フォーマットは、外部ソースをアドレス指定するためのフォーマット、及び、データが外部ソースから受け取られるフォーマットを識別する。そして、最後に、トランスフォームは、プロセスの固有のフォーマットから外部ソースのフォーマットへ、及び、その逆への変換を作成する。これらの要素がそれぞれ定義されると、開発者は、その後、ビジネス・アナリストによって定義された要素ごとに、外部ソースとの情報伝達を使用可能にする。シーケンスは、その後、ブロック555にて終了する。
図11Bは、エキスポート・オプションの一実施形態を示す。統合シーケンスは、第3者によって消費されるために、標準フォーマットで、ウィザード・エキスポート・プロセス定義と関連するメタ・データをエキスポートする。ダイアログ・ボックス1160は、エキスポートされる統合シーケンスを識別し、エキスポートのために、フォーマットの指定を可能にする。これは、統合シーケンスが、外部プログラムと関係者に利用可能になるため有用である。
上述のシーケンスは、ビジネス・アナリストによって定義されたプロセスを実装する。一実施形態の場合、品質保証(Q&A)手順は、プロセスを、開発者によって実装されたものとして認可する。さらに、ビジネス・アナリストは、実装されたプロセスを再調査し、検証するための1回又は複数回の機会が与えらる。プロセスが完全に検証されると、プロセスは、プロセスを使用することになる社員に利用可能になる。さらに、一実施形態の場合、プロセスは、将来のプロセスを構築する時の使用のために利用可能であるプロセスのライブラリ内に置かれる。
図6は、ビジネス・アナリストと開発者の特徴の間の一実施形態の比較を示す。モデラーの目的は異なる。ビジネス・アナリストの場合、モデラーの目的は、カスタマイズされたビジネス・プロセスを作成し、編集することである。開発者の場合、モデラーの目的は、ビジネス・アナリストによって作成されたビジネス・プロセスを実装する/使用可能にすることである。モデラーが統合型モデラーであることは、プロセスと要素の情報伝達は、ビジネス・アナリストと開発者の間で完全であることを意味する。さらに、開発者は、ビジネス・アナリストの作業を再作成する必要がない。従来のシステムでは、ビジネス・アナリストは、実装のために使用されないであろう、視覚プログラムでプロセスをしばしば作成した。これは、ビジネス・アナリストと開発者の間に、情報伝達ギャップならびに2重の労力を生じた。
事業プロセスのビューもまた、ビジネス・アナリストと開発者の間で異なる。ビジネス・アナリストは、各アクターがスイム・レーンを有する、役割に基づくビューを調べ、各要素又はサブ・プロセスは、1つのアクター又は複数のアクターと関連付けられる。これは、ビジネス・アナリストが、誰が各アクションを実施するかをはっきりと可視化することを可能にする。開発者は、一方、システムに基づくビューからプロセスを調べる。システムに基づくビューは、各システムを個別のスイム・レーンで示し、実装されなければならないことになるシステム間の各接続を開発者に示す。
開発者とビジネス・アナリストの間にさらに、ツール・セット識別が存在する。ビジネス・アナリストのツール・セットは、抽象概念が多く、複雑さが少ない、簡略化された、使用するのが容易なツール・セットである。開発者のツール・セットは、完全なツール・セットであり、要素の修正、及び、外部システムとの統合を可能にする。これらのシステムは、外部システム、又は、ビジネス・プロセスを提供するソフトウェア・アプリケーションと統合されたシステムである。
統合に関して、ビジネス・アナリストは、外部サービスの統合に関与する必要はない。むしろ、ビジネス・アナリストは、すべてのサービスが利用可能であり、プロセスによってアクセスされる可能性があると仮定してもよい。開発者は、一方、インターネットを含む外部システムとプロセスとの統合を使用可能にする統合ツールの完全なセットを受け取る。
見てわかるように、統合型プロセス・モデラーは、ビジネス・アナリストと開発者に異なるインターフェースを提供する。しかし、単一プロセス・モデラーの使用は、ビジネス・アナリストと開発者の両方にかなりの利点を提供し、ビジネス・プロセスを作成し、実装するための、より効率的なチームを構築する。
図12は、本発明と共に使用できるネットワークの一実施形態のブロック図である。ネットワーク1200は、会社内のイントラネット、インターネット、ケーブル接続、コンピュータ・システム内のバス、共有アプリケーション・バス、又は、同じか、又は、個別のコンピュータ・システム上に存在することができるソフトウェア・アプリケーションを結合する任意の他の手段である。
ビジネス・アナリストのシステム、プロセス・デザイナー1210が新しいプロセスを設計するために使用される。システムに結合された複数のプロセス・デザイナー1210が存在してもよいが、簡略化のために、ここでは1つのみが示される。一実施形態の場合、プロセス・デザイナー1210は、編集のために、プロセスの局所コピー1215を使用してもよい。別法として、プロセス・デザイナー1210は、ネットワーク1200を通じて、プロセスを編集するためのセキュアな位置を提供するサンド・ボックス1255にアクセスしてもよい。
最善のプラクティス・プロセスは、マスター・プロセス・リポジトリ155内で利用可能である。マスター・プロセス・リポジトリ155内のプロセスは、一実施形態の場合、事前に作成されたプロセスである。一実施形態の場合、最善のプラクティス・プロセスは、実装された、ビジネス・アナリストによって作成されたプロセスをさらに含んでいる。ビジネス・アナリストがプロセスをチェックインさせると、プロセスは、進行中のプロセスの集合体135に格納される。これらのプロセスは、開発者のシステム1220上で、開発者による実装を待つ。開発者は、集合体135から1つ又は複数のプロセスを取り出し、それらを実装する。開発者1220は、編集されるプロセス1225の局所コピーを有するか、Siebelシステム1250に接続された個別のサンド・ボックス1255を使用してもよい。
一実施形態の場合、品質保証システム1230は、実装されたプロセスの試験を可能にする。開発者、Q&A、ビジネス・アナリストがすべて、プロセスを認可すると、実装されたプロセスは、利用可能なプロセス集合体1250内に設置されることによって、利用可能になる。これらの利用可能なプロセス1250は、会社全体を通してプロセス・ユーザ1260によって使用されて、一定のプロセスが自動化され、会社全体を通して応答の統一性が生まれる。
上記要素は、「システム」として述べられるが、単一コンピュータ・システム上で実装されてもよいことに留意されたい。別法として、単一システムは複数のコンピュータにわたって分散してもよい。
図13は、本発明と共に使用できるコンピュータ・システムの一実施形態である。しかし、種々のシステム・アーキテクチャの他の代替のシステムが使用されてもよいことが、当業者に明らかになるであろう。
図13に示すデータ処理システムは、バス又は情報を伝達する他の内部情報伝達手段1315、情報を処理するための、バス1315に結合したプロセッサ1310を含む。システムは、情報及びプロセッサ1310によって実行される命令をを記憶するための、バス1315に結合したランダム・アクセス・メモリ(RAM)又は揮発性記憶デバイス1350をさらに備える。主メモリ1350はまた、プロセッサ1310による命令の実行中に、一時的変数又は他の中間情報を記憶するために使用されてもよい。システムはまた、スタティックな情報とプロセッサ1310用の命令を記憶するための、バス1315に結合した読み出し専用メモリ(ROM)及び/又はスタティック記憶デバイス1320、さらには、磁気ディスク又は光ディスク及びその対応するディスク・ドライブなどのデータ記憶デバイス1325を備える。データ記憶デバイス1325は、情報と命令を記憶するために、バス1315に結合される。
システムはさらに、コンピュータ・ユーザに情報を表示するための、バス1365を通してバス1315に結合した陰極線管(CRT)又は液晶ディスプレイ(LCD)などのディスプレイ・デバイス1370に結合される。英数字及び他のキーを含む、英数字入力デバイス1375が、プロセッサ1310に情報とコマンド選択を伝達するために、バス1365を通してバス1315に結合されている。付加的なユーザ入力デバイスは、プロセッサ1310に方向情報とコマンド選択を伝達するための、また、ディスプレイ・デバイス1370上でのカーソル移動を制御するための、バス1365を通してバス1315に結合した、マウス、トラックボール、スタイラス、又はカーソル方向キーなどのカーソル制御デバイス1380である。
任意選択でコンピュータ・システム1300に結合することができる別のデバイスは、ネットワークを介して分散システムの他のノードにアクセスする通信デバイス1390である。通信デバイス1390は、イーサネット(登録商標)、トークン・リング、インターネット、あるいは、ローカル又はワイド・エリア・ネットワークに結合するために使用されるデバイスなどの、多数の市販のネットワーク化周辺デバイスのうちの任意のデバイスを含む。通信デバイス1390はさらに、ヌル・モデム接続、無線接続機構、又は、コンピュータ・システム1300と外部世界の間の結合性を提供する任意の他の機構であってよい。図13に示すこのシステムの構成部品の任意のもの又はすべて、及び、関連するハードウェアは、本発明の種々の実施形態で使用されてもよいことに留意されたい。
特定の実施態様に従う種々の目的について、システムの任意のコンフィギュレーションを使用してもよいことが、当業者によって理解されるであろう。本発明を実施する制御ロジック又はソフトウェアは、主メモリ1350、大容量記憶デバイス1325、又は、プロセッサ1310に対してローカルに、又は、遠隔でアクセス可能な他の記憶媒体に記憶される可能性がある。
本明細書で述べるシステム、方法、プロセスは、主メモリ1350又は読み出し専用メモリ1320に記憶され、プロセッサ1310によって実行されるソフトウェアとして実装される。この制御ロジック又はソフトウェアはまた、コンピュータ読み取り可能プログラム・コードを埋め込まれているコンピュータ読み取り可能媒体を備え、大容量記憶デバイス1325によって読み取り可能で、プロセッサ1310が本明細書の方法及び教示に従って動作するようにさせる製造品目上に存在してもよい。
本発明はまた、上述したコンピュータ・ハードウェア構成部品のサブ・セットを収容する手持ち式又は可搬型デバイス内に埋め込まれてもよい。例えば、手持ち式デバイスは、バス1315、プロセッサ1310、ならび、メモリ1350及び/又は1325のみを収容するように構成されてもよい。本発明はまた、上述したコンピュータ・ハードウェア構成部品のサブ・セットを含む専用機器内に埋め込まれてもよい。例えば、機器は、プロセッサ1310、データ記憶デバイス1325、バス1315、及び、メモリ1350、ならびに、ユーザが基本的な方法でデバイスと通信することを可能にする小型タッチ・スクリーンなどの単に原始的な通信機構を含んでもよい。一部のデバイスでは、ユーザとの通信は、タッチに基づくスクリーン又は同様な機構によってもよい。
特定の実施態様に従う種々の目的について、システムの任意のコンフィギュレーションを使用してもよいことが、当業者によって理解されるであろう。本発明を実施する制御ロジック又はソフトウェアは、プロセッサ1310に対してローカルに、又は、遠隔でアクセス可能な任意の機械読み取り式媒体上に記憶される。機械読み取り式媒体は、機械(例えば、コンピュータ)によって読み取り可能な形態で、情報を記憶し、又は、伝送する任意の機構を含んでいる。例えば、機械読み取り式媒体は、読み出し専用メモリ(ROM)、ランダム・アクセス・メモリ(RAM)、磁気ディスク記憶媒体、光記憶媒体、フラッシュ・メモリ・デバイス、電気の、音響の、又は、他の形態の伝播信号(例えば、搬送波、赤外信号、デジタル信号など)を含む。
上記明細書では、本発明は、本発明の特定の例示的な実施形態を参照して述べられた。しかし、添付特許請求項に記載される本発明のより広い精神及び範囲から逸脱することなく、実施形態に対して種々の修正及び変更を行ってもよいことが明らかである。明細書及び図面は、したがって、制限の意味ではなく、例示の意味で考えられるべきである。
統合型プロセス・モデラーの一実施形態のブロック図である。 統合型プロセス・モデラーを使用する一実施形態の概要フローチャートである。 ビジネス・アナリストがプロセス・モデラーを使用して、新しいプロセスを作成する一実施形態のフローチャートである。 ビジネス・アナリストがプロセス・モデラーを使用して、新しいプロセスを作成する一実施形態のフローチャートである。 ビジネス・アナリストから実装エンジニアへの責任移管の一実施形態のフローチャートである。 実装エンジニアが、プロセス・モデラーを使用して、ビジネス・アナリストによって作成されたプロセスを使用可能にする一実施形態のフローチャートである。 ビジネス・アナリストと開発者の特徴の間の一実施形態の比較を示す図である。 ビジネス・アナリストに提示されるユーザ・インターフェースの一実施形態を示す図である。 ドリルダウンプロセスを示すユーザ・インターフェースの実施形態を示す図である。 ドリルダウンプロセスを示すユーザ・インターフェースの実施形態を示す図である。 プロセスのどのアスペクトが、実装作業を必要とするかを自動的に示す移管とフラグ立ての一実施形態を示す図である。 実装エンジニアのためのユーザ・インターフェースの実施形態を示す図である。 実装エンジニアのためのユーザ・インターフェースの実施形態を示す図である。 実装エンジニアのためのユーザ・インターフェースの実施形態を示す図である。 実装エンジニアのためのユーザ・インターフェースの実施形態を示す図である。 統合ビューの実施形態を示す図である。 統合ビューの実施形態を示す図である。 本発明と共に使用されることができるネットワークの一実施形態のブロック図である。 本発明と共に使用されることができるコンピュータ・システムの一実施形態のブロック図である。

Claims (37)

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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/334,953 US7251787B2 (en) 2002-08-28 2002-12-31 Method and apparatus for an integrated process modeller
PCT/US2003/025312 WO2004061815A1 (en) 2002-12-31 2003-08-12 A method and apparatus for an integrated process modeller

Publications (1)

Publication Number Publication Date
JP2006512670A true JP2006512670A (ja) 2006-04-13

Family

ID=32655210

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004564686A Withdrawn JP2006512670A (ja) 2002-12-31 2003-08-12 統合型プロセス・モデラーのための方法及び装置

Country Status (4)

Country Link
EP (1) EP1588349A4 (ja)
JP (1) JP2006512670A (ja)
AU (1) AU2003259807A1 (ja)
WO (1) WO2004061815A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008140135A (ja) * 2006-12-01 2008-06-19 Mitsubishi Electric Corp ワークフロー生成装置及びワークフロー生成方法及びプログラム

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002531890A (ja) 1998-11-30 2002-09-24 シーベル システムズ,インコーポレイティド クライアントサーバーアプリケーションにおける開発ツール、方法及びシステム
US7051319B1 (en) 2001-03-27 2006-05-23 Siebel Systems, Inc. Method, system, and product for upgrading software objects using inherency
US7117449B1 (en) 2002-12-31 2006-10-03 Siebel Systems, Inc. Method and apparatus to present an integrated process modeler
US7665063B1 (en) 2004-05-26 2010-02-16 Pegasystems, Inc. Integration of declarative rule-based processing with procedural programming
US8335704B2 (en) 2005-01-28 2012-12-18 Pegasystems Inc. Methods and apparatus for work management and routing
US8924335B1 (en) 2006-03-30 2014-12-30 Pegasystems Inc. Rule-based user interface conformance methods
US8250525B2 (en) 2007-03-02 2012-08-21 Pegasystems Inc. Proactive performance management for multi-user enterprise software systems
US8843435B1 (en) 2009-03-12 2014-09-23 Pegasystems Inc. Techniques for dynamic data processing
US8468492B1 (en) 2009-03-30 2013-06-18 Pegasystems, Inc. System and method for creation and modification of software applications
US8880487B1 (en) 2011-02-18 2014-11-04 Pegasystems Inc. Systems and methods for distributed rules processing
US9195936B1 (en) 2011-12-30 2015-11-24 Pegasystems Inc. System and method for updating or modifying an application without manual coding
US10469396B2 (en) 2014-10-10 2019-11-05 Pegasystems, Inc. Event processing with enhanced throughput
US10698599B2 (en) 2016-06-03 2020-06-30 Pegasystems, Inc. Connecting graphical shapes using gestures
US10698647B2 (en) 2016-07-11 2020-06-30 Pegasystems Inc. Selective sharing for collaborative application usage
US11048488B2 (en) 2018-08-14 2021-06-29 Pegasystems, Inc. Software code optimizer and method
US11567945B1 (en) 2020-08-27 2023-01-31 Pegasystems Inc. Customized digital content generation systems and methods

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04372686A (ja) * 1991-06-21 1992-12-25 Toyo Tanso Kk 膨張黒鉛シートの製造法
US6684388B1 (en) * 2000-08-22 2004-01-27 International Business Machines Corporation Method for generating platform independent, language specific computer code

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008140135A (ja) * 2006-12-01 2008-06-19 Mitsubishi Electric Corp ワークフロー生成装置及びワークフロー生成方法及びプログラム

Also Published As

Publication number Publication date
EP1588349A4 (en) 2008-06-18
EP1588349A1 (en) 2005-10-26
AU2003259807A1 (en) 2004-07-29
WO2004061815A1 (en) 2004-07-22

Similar Documents

Publication Publication Date Title
US7117449B1 (en) Method and apparatus to present an integrated process modeler
US7251787B2 (en) Method and apparatus for an integrated process modeller
US8543932B2 (en) Generation and testing of graphical user interface for matter management workflow with collaboration
JP4790837B2 (ja) ユーザのイベント処理を支援する方法及びそのためのコンピュータシステム
US5784583A (en) Intuitive technique for building graphical menus
JP2006512670A (ja) 統合型プロセス・モデラーのための方法及び装置
US20160170719A1 (en) Software database system and process of building and operating the same
US20070038963A1 (en) Methods and apparatus for process thumbnail view
US20100153150A1 (en) Software for business adaptation catalog modeling
US20050257136A1 (en) Methods and systems for animating a workflow and a project plan
US20100153149A1 (en) Software for model-based configuration constraint generation
US7469217B2 (en) Product toolkit system and method
WO2001055840A9 (en) Opportunity tracking information system
JPH11296544A (ja) 構造化データ管理システム及び構造化データ管理プログラムを記録したコンピュータ読み取り可能な記録媒体
US7251724B2 (en) Device environment configuration system and method, and data storage therefor
JP2005502928A (ja) トップダウン型のビジネスプロセスの定義付けおよび実行のための方法およびシステム
JP2007328792A (ja) ネットワークベースのプロジェクトスケジュールマネージメントシステムにおけるメンバースケジュールのプロジェクトスケジュールとの集約
CN111506304A (zh) 一种基于参数配置的流水线构建方法及系统
US7673286B2 (en) Architecture for converting control types in a data bound user interface
US11461218B1 (en) Analyzing user API usage from recorded API macros for software product improvement
US20060047723A1 (en) Custom database system and method of building the same
US7877283B2 (en) Multi-perspective business process configuration
US20070027909A1 (en) Methods and apparatus for comparison of projects
US20100011018A1 (en) Custom database system and method of building the same
US20090007157A1 (en) Mapping Data Sources to a Procedural API

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060620

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20080716