ケースの特定

Pegaは創業当初から、ワークとデータの間に存在する関心の分離を認識する、ビジネスプロセスマネジメントのベストプラクティスに従ってきました。 PegaのEnterprise Class Structure（ECS）は、Work-クラスおよびData-クラスでこの区別を公式化しています。 Pegaでは、1つ以上のステージ（その中に1つ以上のワーク拡張フローがあります）に分割されたWork-Cover拡張ケースを使用します。 フローの目的は、Data拡張クラスを使用して実装されるビジネスデータの管理です。

Pega認定リードシステムアーキテクトのロールは、ソリューションを設計する場合に、ケース、ステージ、ステップ、プロセス（フロー）、サブプロセス（サブフロー）、データオブジェクト、子ケース（サブケース）、関連する兄弟ケース、コンポーネントなど、どのPega Platform™機能を使用するかを決定することです。 一部のアプリケーションでは、1つのケースタイプが1つの簡単なビジネスプロセスを表すため、簡単に特定できます。 しかし、他の状況では、耐久性のある堅牢なデザインを生み出すには、慎重な検討が必要です。 他にも、レポート、セキュリティ、ロック、拡張性、特殊性など、設計にはさまざまな要素があります。 デザインは、アプリケーションの基礎を構成するため、作成する前に、現在および将来の潜在的なすべての要件を慎重に検討してください。

ケースデザインは、アプリケーションのプロセスを特定することから始まります。 ケースタイプを特定する場合は、これらのケースタイプに対する特殊化のニーズを検討してください。 また、ケースデザインを実装する前に、将来の拡張性の要件を慎重に検討してください。 たとえば、Purchase Requestプロセスには、購入するアイテムのリストと各アイテムの数量を特定することが含まれます。 アイテムのリストを確認し、1人以上の承認者による承認のために転送されます。 次に、アイテムのリストを順番に並べます。 最終的に元の依頼者がアイテムを受け取ると、プロセスは完了します。

このビジネスプロセスを表現するために、次のいくつかのケースデザインを使用することができます。

• 行項目ごとのサブプロセスを使用した、全てのプロセス向けの単一のPurchase Request Case。
• 承認されると単一のPurchase Order Caseに切り替わる、最初のリクエストを集めたPurchase Requestケース。
• 行項目ごとのPurchase Order子ケースを使用した、最初のリクエストを収集するPurchase Requestケース。

何を実装するかの意思決定は、そのワークを実行するペルソナに依存します。 一部またはすべての行項目を精査する必要がある場合は、Divide and Conquerデザインパターンを使用するのが合理的です。 複数の人が並行してワークを実行することで、1人で各行項目を連続して見るよりも短時間で行項目のリストを処理できます。

提示されたすべてのソリューションは、最初は実行可能かもしれませんが、最適なソリューションでは、メンテナンスを最小限にするために、現在および考えられる将来の要件を考慮します。

ケースを特定する場合に考慮すべき基本的な質問は以下のとおりです。

• ケースには処理が必要な項目が表現されているか。
• ケース（プロセス）を複数のケースや子ケースに分割することにメリットがあるか、あるいは並列プロセス（並列フロー）で十分か。
• 追加ケースや子ケースが必要か。
• 子ケースを作成した場合、一般的なルールとして、主要なケースの処理は子ケースの完了に依存します。 これは本当か。
• レポートやセキュリティなど、ケースデザインを調整することでより簡単に実装できる現在または将来のその他の要件があるか。

すべての質問を慎重に検討してください。 状況によっては、追加のケースを必要とせず、かえってリソースの非効率的な使用や過度に複雑なソリューションになってしまう可能性があります。 ケースの作成には追加の処理が含まれるため、追加のケースを作成する正当な理由を常に確認してください。

Purchase Requestの例では、以下の点を説明しています。

• 個々の行項目タイプの承認に基づくセキュリティ要件がある場合は、個々の行項目の子ケースを使用してケースデザインソリューションを実装する必要がある場合があります。
• 行項目の処理に特別な要件がない場合は、サブプロセスを含むシンプルなソリューションが各行項目に適している可能性があります。
• Purchase Orderケースの追加は、その必要性が明示された要件（特別な報告要件など）がない限り、不要である可能性があります。

ケースの特定が簡単な場合もあれば、状況によってはケースやプロセスを追加した方が有利な場合もあります。 たとえば、顧客データやアカウントデータなど、ケース処理をサポートするデータが挙げられます。 データのケース処理で提供されるインフラ（承認プロセス、セキュリティ、監査など）を利用することが有利な状況では、データを直接更新するよりもケースを提供する方が適している場合があります。