カスケード承認

レポート構造に基づくカスケード承認では、ユーザーの直属のマネージャーと上位レベルのマネージャーの承認が必要です。 必要な承認の数を決めるための、しきい値を設定するビジネスロジックを設定できます。

たとえば、経費報告にマネージャーの承認がなければ、経理部門は支払いを処理できません。 次の図に示すように、サブミットされた経費の合計額によっては、経費リクエストはシニアマネージャー、取締役、副社長の承認も必要な場合があります。 経費報告書が3000米ドルの場合、マネージャー、シニアマネージャー、ディレクター、VPのすべてが、レポートをレビューする必要があります。

レポート構造オプションを使うカスケード承認

Dev Studioでカスケード承認を設定するには、ケースライフサイクルにApprove/Reject ステップを追加し、Cascading オプションを選択します。 レポート構造に基づいてカスケード承認を設定するReporting structureオプションを選択します。

次の画像で「+」アイコンをクリックすると、承認オプションをカスケードするレポート構造の詳細が表示されます。

オーソリティマトリックスに基づくカスケード承認はレポート構造より柔軟です。 権限マトリックスモデルは、少なくとも1つのエンティティがレポート構造の外部にある、複数のエンティティからの承認を必要とするプロセスを設定するときに使用します。 一連のルールにより、承認チェーンがレポート構造の外部のエンティティ、ユーザー組織の内部および外部に転送されます。 

たとえば、次の図は、経理部門に対するレポート階層外の承認を必要とし、オーソリティマトリックスモデルを使用する経費報告書を示しています。

オーソリティマトリックスデータ構造の入力

オーソリティマトリックス権限マトリクスを使用したカスケード承認には、承認者を識別するデータ構造の設定が必要です。 承認リストから候補がなくなるまで、アプリケーションで承認ごとに構造を照会します。 Pega Platformでは、デシジョンテーブル、データページ、アクティビティ、データトランスフォームなど、データ構造に入力するいくつかの方法があります。

一般的なアプローチの1つは、承認レベルと対応する関係者を識別するためのデシジョンテーブルを設定することです。 アプリケーションにより、データ構造を入力するデシジョンテーブルが評価されます。 各行または各条件が満たされると、結果が承認者のリストに追加されます。 承認のアサインメントは、リストの表示順に承認者にルーティングされます。

次の画像に示されている経費報告の例では、デシジョンテーブルにより承認プロセスの各関係者が特定され、各関係者が承認するタイミングを決定する条件が示されます。 最初の条件は、経理部門が請求可能な経費を承認する必要があることを示しています。 次の3つのWhen条件は、経費の金額に基づいています。 コンサルタントが請求可能な時間を含む700米ドルの経費報告書を提出すると、アプリケーションでは、経理部門、コンサルタントのマネージャー、およびコンサルティング部門を統括する取締役からの3回の承認を受けるオーソリティマトリックスが作成されます。

オーソリティマトリックスオプションを使用したカスケード承認

Dev StudioのApprove/Reject ステップで、オーソリティマトリックスに基づいてカスケード承認を設定するCascading オプションとAuthority matrix オプションを選択します。

次の画像で「+」アイコンをクリックすると、承認オプションをカスケードするオーソリティマトリックスの詳細が表示されます。