watsonx.governance ORM を使用すると、ユース・ケースをビジネス・プロセスに接続して、企業全体の他の運用リスクとともにモデル・リスクを追跡することができます。
サンプルの watsonx.governance Operational Risk Management (ORM) ワークフローをそのまま使用することも、要件に合わせて変更することもできます。 これらのサンプル・ワークフローは、独自のワークフローのテンプレートや学習ツールとしても使用できます。
watsonx.governance ORM マスター・プロファイルは、オペレーショナル・リスク管理のためのオブジェクト・タイプへの管理アクセス権限を付与します。 このプロファイルは、 OpenPages ORM マスター・プロファイルに似ていますが、ORM ユーザーにオペレーショナル・リスクとモデル・リスクの統合ビューを提供するモデル・リスク・オブジェクト・タイプが含まれています。 オペレーショナル・リスク管理タスクを実行する場合は、 watsonx.governance ORM マスター・プロファイルを使用します。
サンプル・ワークフローはフレッシュ・インストールで有効になっています。
アクション・アイテム承認ワークフロー
アクション・アイテムが作成されると、アクション・アイテム承認ワークフローが自動的に開始します。 アクション・アイテムの担当者に E メールが送信され、アクション・アイテムが割り当てられたことを知らせます。 タスクの期限は、アクション・アイテムの期限の 7 日前に設定されます。 アクション・アイテムが完了すると、割り当て対象者は を選択します。 ワークフローは、以下のアクションを実行します。
- 親の課題の「課題の責任者」フィールドの値を、アクション・アイテムの「承認のための課題の責任者」フィールドにコピーします。
- アクション・アイテムの「ステータス」フィールドを「承認待ち」に設定します。
- 課題の責任者に E メールを送信して、アクション・アイテムが承認待ちであることを通知します。
課題の責任者は、アクション・アイテムをレビューしてから、課題のクローズを承認または却下します。 タスクの期限は、アクション・アイテムの期限に設定されます。
課題の責任者が を選択すると、ワークフローは以下のアクションを実行します。
- 「ステータス」フィールドを「完了」に設定します。
- 「承認/却下」フィールドを「承認」に設定します。
- 「実際の完了日」を今日の日付に設定します。
課題の責任者が を選択すると、タスクはアクション担当者に再割り当てされます。 ワークフローは、以下のアクションを実行します。
- 「ステータス」フィールドを「未着手」に設定します。
- 「承認/却下」フィールドを「却下」に設定します。
結果ワークフロー
結果ワークフローは、「結果システム・タスク」ビューを使用し、結果および関連オブジェクト・タイプのデフォルト・スキーマに依存します。
- キャンセル・パス
ステージが辞退されると、ワークフローは「結果準備 (Finding Preparation)」ステージに戻ります。 独自のワークフローでは、このルートを選択することも、直前のステージに戻ることを選択することもできます。 ワークフロー内で前方向と後方向の両方のパスを計画します。
- タスクのオーバーライド
各ステージのタスクのオーバーライドは、リストされるキー・フィールドを定義します。 ユーザー・ガイダンス・テキストは、タスク・ビュー自体から提供されます。 この方式では、キー・フィールドはステージごとに変更され、ステージに固有になります。
インシデント・ワークフロー
インシデント・ワークフローは、調査と承認のプロセスを通じてインシデントを移動します。
インシデントが作成されると、インシデント・ワークフローが自動的に開始します。 ワークフローは、各ステージの責任者 (プライマリー責任者、承認担当者、およびレビューアー) を設定します。 発見日およびインシデント重大度に基づいて、期限を設定します。
課題のレビュー・ワークフロー
課題管理および是正 (IMR) フレームワークでは、課題を効率的に記録、モニター、是正、および監査できます。
課題は、文書化されたフレームワークに反すると特定されたアイテムで、リスクの的確な管理や報告を行う機能に悪影響を及ぼすとみなされます。 そのライフサイクルでは、課題は 2 つの状態 (未着手または完了) のうちの 1 つの状態であることが可能です。
課題が作成されると、課題のレビュー・ワークフローが自動的に開始します。 ワークフローは、課題のステータスを「未着手」に設定し、「元の期限」を課題の作成時に入力された期限に設定します。 課題の責任者に E メールが送信され、課題が割り当てられたことを知らせます。 タスクの期限は、問題の期限の 15 日前に設定されます。
課題を解決するために、課題の責任者は適切なアクションを設定して、記録します。
課題の責任者は、「要求された期限」を設定し、 を選択することで、課題のライフサイクルの任意の時点で期限の延長を要求できます。 問題の承認者には、この要求が E メールで通知されます。 承認担当者は要求を承認または却下することができます。 承認された場合、課題の期限は要求された期限に設定されます。
課題の責任者は、 を選択することで、課題をレビュー用に送信できます。 ワークフローは、以下の検証を実行します。
- 課題に基づくすべてのアクション・アイテムが完了している。
- 「課題の評価結果 (Issue Conclusion)」フィールドにデータが取り込まれている。
- 「課題の種類」フィールドにデータが取り込まれている。
いずれかの検証が失敗した場合、ワークフローは、課題の責任者がレビューのために課題を送信しないようにします。 すべての検証に合格すると、課題の承認者に E メールで要求が通知されます。 このタスクの期限は、課題の期限に設定されます。 拒否された場合、課題の責任者に E メールで拒否が通知されます。 課題の責任者は、更新を行ってから、レビューのために課題を再送信することができます。 課題が承認された場合、課題の状況は「完了」に設定されます。
課題を再度オープンするには、課題のレビュー・ワークフローを開始します。
KRI および KPI ワークフロー
- KRI値の作成
- このワークフローは、KRI 値レコードを作成し、収集のために KRI 値でワークフローを開始します。
このワークフローは、KRI レコードで毎日実行されるスケジュールに設定されます。 KRI ステータスが
「アクティブ」
で、次の収集日がスケジュールの実行日と等しく、KRI 値の日付がスケジュールの実行日と等しくない場合、KRI 値レコードが作成されます。KRI 値レコードの作成に加えて、レコードには、期待される収集日、KRI 収集者、KRI 所有者、収集状況、赤のしきい値、黄のしきい値、および値の日付を含む、親 KRI からの値が取り込まれます。
その後、このワークフローによって作成された KRI 値が KRI 値エントリー・ワークフローに入ります。
- KRI値エントリー
- このワークフローは、KRI 値をユーザーに割り当て、KRI 値承認のプロセスを提供します。
このワークフローは、KRI 値レコードが作成され、ステータスが
収集待ち
のときに自動開始します。 ワークフローが作成されると、KRI 値には、KRI キャプチャー・プログラム、KRI 所有者、KRI 値の赤と黄色のしきい値、説明、および承認が必要かどうかなど、KRI 値の親 KRI からのデータが取り込まれます。 値を入力した後、別のタブをクリックしてからビューに戻り、最新の KRI 値または KPI 値を表示する必要がある場合があります。 - KPI 値作成ワークフローおよび KPI 値エントリー・ワークフロー
- これらのワークフローは、KRI 値作成ワークフローおよび KRI 値エントリー・ワークフローに似ています。
リスクと統制の自己評価 (RCSA)
- リスク & 統制自己評価 (RCSA)
- このワークフローを使用して、定性的なリスク評価を確立、実行、および進行させることができます。 以下のステップが実行されます。
- リスク所有者は、リスク & 統制自己評価 (RCSA) ワークフローを手動で開始します。
- リスク所有者は、固有の影響と可能性を特定することで、固有のリスク評価を実行します。
- リスク所有者は、残余の影響と可能性を評価することによって、残余リスク評価を実行します。
- リスク所有者は、完了のために RCSA を送信します。
- コントロール・アセスメント
- RCSA ワークフローを完了するには、その前にコントロール評価を実行する必要があります。 このワークフローを使用して、コントロール評価を進めることができます。 以下のステップが実行されます。
- 統制活動の責任者は、統制活動の評価ワークフローを手動で開始します。
- 統制活動の責任者は、統制の設計と運用の有効性を評価することで統制活動の評価を行います。
- コントロール所有者は、承認のためにアセスメントを送信します。
- 統制活動/リスクの所有者または RCSA コーディネーターは、統制活動を拒否してレビューのために返送するか、承認して閉じることができます。これにより、統制活動に
「承認済み」
ステータスのマークが付けられます。
テスト・ワークフローの制御
- テスト結果の作成
- コントロールテストの実行
- 更新＆amp; テスト計画レビュー
「テスト結果の作成」ワークフローは、親テスト計画で定義されたスケジュールまたは頻度に基づいて、テスト結果を自動的に作成します。 アクティブなテスト計画の次の期限が来ると、このワークフローは自動的に新しいテスト結果を作成し、親のテスト計画からテスト実行者とテスト期限の情報を取り込みます。 「制御テストの実行」ワークフローを使用すると、テストのパフォーマンス、レビュー、文書要求 (必要な場合) が実行され、テスト結果が失敗した場合にも問題が自動的に作成されます。
損失イベントのレビュー・ワークフロー
損失イベントのレビュー・ワークフローは、損失イベントの構成可能なライフサイクルに似ています。
- 金額値に基づく異なる複数のパス
ワークフローは、損失イベントの損失総額値に基づいて、異なるレベルの承認 (承認レベル 1 および承認レベル 2) を提供します。
- 設定オブジェクトの使用
承認レベル 1 および承認レベル 2 は設定オブジェクトから取得されます。 損失イベントが発生した部門に基づいて承認者は異なります。 ワークフロー内で設定オブジェクトを実装する方法について詳しく学習するには、この例を参照してください。
アンケート評価ワークフロー
アンケート評価ワークフローは、情報収集、レビュー、承認の各ステージを通してアンケート評価を移動させます。
調書ワークフロー
調書ワークフローは、「調書システム・タスク」ビューを使用し、調書および関連オブジェクト・タイプのデフォルト・スキーマに依存します。
調書には、「通知文書」や「テストによる立証」などの複数のタイプがあります。 ただし、ワークフローのサンプルは概略的であり、1 つの特定のタイプには定義されていません。 作成する調書ワークフロー内では多くの場合、特定のタイプの調書に対してワークフローを定義します。この場合、タイプごとに別々のワークフローを作成するか、タイプを指定する条件を備えた別個の分岐を持つ 1 つのワークフローを作成するかを選択できます。
- 「アクション」ボタンを表示できるのは誰か
最後の 2 つの転送アクション ( 「レビュー用に送信」 と 「承認して完了」) は、特定のユーザー (作成者とレビューアー) に制限されます。 これらのアクションは、そのユーザーに対してのみ表示されます。 他のすべてのユーザーについては、「アクション」ボタンのアクションはありません。 このような状況が生成される場合、そのステージのユーザー・ガイダンスに、「アクション」ボタンにオプションがない理由の説明を追加することができます。