ケースライフサイクルの設計
Pega Platform™では、ケースライフサイクル設計モデリング手法がサポートされています。ビジネスユーザーはこのモデルを利用することで、思考と同じ流れでケースを参照し、操作することが可能になります。各ケースライフサイクルには、ステージ、プロセス、ステップがあります。
たとえば、Onboardingケースタイプのケースライフサイクルで人事、設備、IT部門が新入社員の出勤初日に設定を行うとします。
Pega Platformでは、複雑な業務や特定のニーズに対応するために、ステージ、プロセス、ステップのさまざまなタイプや設定がサポートされています。
次の画像では、「+」のアイコンをクリックすると、Onboardingケースライフサイクルの詳細が表示されます。
次の表では、ケースライフサイクルのさまざまなコンポーネントについて説明します。
| コンポーネント | 目的 |
|---|---|
| Createステージ |
ケースライフサイクルの最初のステージはCreateステージで、緑色のバーで示されます。Createステージには、ユーザーがケース作成時に初期データを入力するためのプロセスとステップが含まれます。 Createステージは、ケースライフサイクルから削除したり、位置を変えたりすることはできません。Createステージは名前を変更できます。Createステージを含むケースには、ケース作成時にケースIDが割り当てられます。 |
| Createプロセス |
デフォルトでは、CreateステージにはCreateプロセスが含まれていますが、ビジネスニーズに合わせて変更できます。チャネルに依存しないCreateプロセスにはCollect informationステップのみ含めることができます。 Createプロセスは条件付きで開始するように設定できます。たとえば、Digital Messengerチャネルを作成し、チャネル固有のCreateプロセスを設定します。ユーザーがDigital Messengerアプリを使用している場合にのみプロセスを開始するように設定します。 |
| プライマリステージ |
プライマリーステージとは、期待される成果が得られるステージのことです。ケースタイプのプライマリーステージを特定するために、以下の点を考慮してください。
ケースライフサイクルの中で、プライマリーステージから逸脱しないで、ケースが進む道はプライマリーパスと呼ばれます。 Onboardingの例でのプライマリステージは、Verification、Pre-arrival Setup、Setup、Onboardingです。 |
| Collect informationステップ |
Collect informationステップは、ユーザーのアクションや入力を必要とするステップです。 Collect informationステップは、ケースライフサイクルに緑色のアイコンで表示されます。 Collect informationステップはよくアサインメントやタスクと呼ばれます。 |
| 並列プロセス |
2つ以上のプロセスがあるステージでは、通常、プロセスは順番に実行されます。2つ以上のプロセスを互いに独立して開始し完了できる場合は、それらを並列プロセスとして設定できます。ケース処理中には、どちらのプロセスでもアクティブな割り当てとして実行できます。 Onboardingの例には、設定済みのノートパソコンを新入社員に提供するCreate IT Setupプロセスと、新入社員にオフィスをアサインするCreate Facilities Setupプロセスが含まれています。これらのプロセスは任意の順序で実行でき、両方が完了するとステージが進行します。 ヒント:Createステージでは、標準プロセスを並列プロセスとして設定することもできます。 |
| Automationステップ |
Automationステップはシステムによって実行されるステップで、ケースライフサイクルでは黄色のアイコンが表示されます。Automationステップでは、メールの送信、PDFファイルの作成、指定された時間の待機、ケースのステージの変更が可能です。 Onboardingの例では、Automationステップを使用して、却下されたIT設備をプライマリーパスに戻し、ウェルカムパケットメールを新入社員に送信し、従業員の新しい上司とチームにさまざまな種類の通知を送信します。 |
| オルタネートステージ |
オルタネートステージは、プライマリーパスからの逸脱を処理するステージです。オルタネートステージはオプションで、ネガティブな完了ステージを表したり、例外処理に使用し、ケースはプライマリーパスに再投入できるようにします。 Onboarding例のケースのプライマリーパスでIT設備の選択が承認されると、ケースはVerificationステージに進みます。ただし、「IT setup」の選択が却下された場合は、Approval Rejectionオルタネートステージに進み、「IT setup」の選択を変更できます。 |
| Resolutionステージ |
Resolutionステージは赤色のバーで示され、ケースライフサイクルの最後のケースの動作を定義します。Resolutionステージは、ステージの終わりにケースライフサイクルが終了することを示します。 すべてのケースタイプには、少なくとも1つのResolutionステージが必要です。ビジネスプロセスに別のパスを定義した場合、1つのケースタイプに複数のResolutionステージを含めることができます。この例では、Onboardingケースライフサイクルには、VerificationステージとApproval Rejectionステージの2つの解決ステージがあります。 |
ステージ遷移
ケースライフサイクルを設計するときは、ケースがどのように1つのステージから次のステージに移行するかを検討します。
次の画像で、「+」アイコンをクリックして、ステージコンテキスチャルプロパティペインで使用できる遷移オプションの詳細を確認してください。
オートメーションによるステージ遷移
Change Stageオートメーションステップを使用して、ケースを特定のステージに自動的に移行させます。このタイプの設定が最も効果的なのは、オルタネートステージへの移行とそのステージからの復帰を自動化する場合です。
Onboardingケースの場合、Change StageオートメーションをApproval Rejectionオルタネートステージに追加します。IT setupの選択が変更されたら、次にVerificationステージに進むようChange Stageステップを設定します。
ステップ移行
ケースライフサイクルを設計するときは、ケースが、どのように1つのステップから別のステップに移行するかを検討します。デフォルトでは、実行時にSubmitをクリックしてケースを次のステップに進めます。次の図は、左にApp Studioのプロセス設定、右に実行時のステップを示しています。
App Studioのプロセスでは、実行時にPrevious ボタンを表示するAllow users to go back to the previous Stepオプションを有効にできます。次の図は、左にApp Studioのプロセス設定、右に実行時のステップを示しています。
次の問題に答えて、理解度をチェックしましょう。