With watsonx.governance ORM, you can connect use cases to business processes, enabling model risk to be tracked along with other operational risks across the enterprise.
You can use the sample watsonx.governance Operational Risk Management (ORM) workflows as delivered or modify them to meet your requirements. They can also be used as templates and learning tools for your own workflows.
The watsonx.governance ORM Master profile gives administrative access to the object types for operational risk management. The profile is similar to the OpenPages ORM Master profile, but includes the model risk object types to give ORM users an integrated view of operational risk and model risk. Use the watsonx.governance ORM Master profile when you want to do operational risk management tasks.
The sample workflows are enabled in fresh installations.
Action Item Approval workflow
When an action item is created, the Action Item Approval workflow starts automatically. An email is sent to the Action Item Assignee informing them that an action item is assigned to them. The due date for the task is set to 7 days before the action item’s Due Date. When an action item is complete, the assignee selects . The workflow completes the following actions:
- Copies the value in the Issue Owner field of the parent issue to the action item’s Issue Owner for Approval field.
- Sets the action item’s Status field to Awaiting Approval.
- Sends an email to the Issue Owner informing them that an action item is waiting for their approval.
The Issue Owner reviews the action item, and then approves or rejects the closure of the Issue. The due date for the task is set to the action item’s Due Date.
If the Issue Owner selects , the workflow completes the following actions:
- Sets the Status field to Closed.
- Sets the Approve Reject field to Approve.
- Sets the Actual Completion Date to today's date.
If the Issue Owner selects , the task is reassigned to the Action Assignee. The workflow completes the following actions:
- Sets the Status field to Open.
- Sets the Approve Reject field to Reject.
Finding workflow
The Finding workflow uses the Finding System Task view and depends on the default schema for Finding and related object types.
- The cancellation path
If a stage is declined, the workflow returns to the Finding Preparation stage. In your own workflow, you might choose this route or choose to go back to the immediately preceding stages. Plan the paths through the workflow in both a forward and backward direction.
- Task overrides
The task overrides for each stage define the Key Fields that are listed. The user guidance text is from the Task View itself. With this method, the Key Fields change with each stage and are specific to a stage.
Incident workflow
The Incident workflow moves an incident through an investigation and approval process.
When an incident is created, the Incident workflow starts automatically. The workflow sets an owner for each stage (primary owner, approver, and reviewer). It sets the due date based on discovery date and incident criticality.
Issue review workflow
In an Issue Management and Remediation (IMR) framework, you can effectively document, monitor, remediate, and audit issues.
Issues are items that are identified against the documented framework and are deemed to negatively affect the ability to accurately manage and report risk. In its lifecycle, an issue can have one of two states: Open or Closed.
When an issue is created, the Issue Review workflow starts automatically. The workflow sets the Status of the issue to Open and the Original Due Date to the due date that was entered when the issue was created. An email is sent to the Issue Owner, informing them that an issue is assigned to them. The due date for the task is set to 15 days before the issue’s Due Date.
To resolve the issue, the Issue Owner establishes and records the appropriate actions.
The Issue Owner can request a due date extension at any time during the issue lifecycle by setting the Requested Due Date and selecting . The Issue Approver is notified of this request by email. The approver can approve or reject the request. If approved, the issue’s Due Date is set to the requested due date.
The Issue Owner can submit the issue for review by selecting . The workflow completes the following validations:
- All action items under the issue are closed.
- The Issue Conclusion field is populated.
- The Issue Type field is populated.
If any of the validations fails, the workflow prevents the Issue Owner from submitting the issue for review. If all the validations pass, the Issue Approver is notified of the request by email. This task due date is set to the issue’s Due Date. If rejected, the Issue Owner is notified of the rejection by email. The Issue Owner can make updates and then resubmit the issue for review. If the issue is approved, the issue’s Status is set to Closed.
The issue can be re-opened by starting the Issue Review workflow.
KRI and KPI workflows
- KRI Value Creation
- This workflow creates KRI Value records and initiates workflows on the KRI Value for
collection.
This workflow is set to a schedule that runs daily on KRI records. When the KRI Status is
Active
and the Next Collection Date is equal to the day the schedule is run and the KRI Value Date is not equal to the day the schedule is run, a KRI Value record is created.In addition to creating the KRI Value record, the record is populated with values from the parent KRI, including Expected Collection Date, KRI Capturer, KRI Owner, Collection Status, Red Threshold, Yellow Threshold, and Value Date.
The KRI Value that is created by this workflow then enters the KRI Value Entry workflow.
- KRI Value Entry
- This workflow assigns KRI Values to users and provides a process for KRI Value approval.
This workflow auto-starts when a KRI Value record is created and is in a Status of
Awaiting Collection.
When the workflow is created, the KRI Value is populated with data from its parent KRI, including KRI Capturer, KRI Owner, KRI Value Red and Yellow Thresholds, Description, and whether approval is required. After you enter a value, you might need to click another tab and then return to the view to see the latest KRI or KPI values. - KPI Value Creation workflow and KPI Value Entry workflow
- These workflows are similar to the KRI Value Creation and KRI Value Entry workflows.
Risk and control self-assessment (RCSA)
- Risk & Control Self-Assessment (RCSA)
- This workflow can be used to establish, execute, and progress through a qualitative risk
assessment. The following steps are completed:
- A risk owner manually starts the Risk & Control Self-Assessment (RCSA) workflow.
- The risk owner performs an inherent risk assessment by identifying the inherent impact and likelihood.
- The risk owner performs a residual risk assessment by evaluating the residual impact and likelihood.
- The risk owner submits the RCSA for completion.
- Control Assessment
- A control assessment needs to be performed before the RCSA workflow can be complete. This
workflow can be used to progress through your control assessment. The following steps are completed:
- A control owner manually starts the Control Assessment workflow.
- The control owner performs the control assessment by evaluating the control design and operating effectiveness.
- The control owner submits the assessment for approval.
- The Control/Risk owner or RCSA coordinator can reject the control and send it back for review,
or approve and close, marking the control in
Approved
status.
Control testing workflows
- Create Test Result
- Perform Control Test
- Update & Review Test Plan
The Create Test Result workflow automatically creates a Test Result based on the schedule or frequency that is defined in the parent Test Plan. When the next due date comes for an active Test Plan, this workflow automatically creates a new Test Result, and populates it with test performer and test due date information from the parent Test Plan. With the Perform Control Test workflow, the test goes through its performance, review, documentation request (if required), and an issue is even automatically created if the test result has failed.
Loss Event Review workflow
The Loss Event Review workflow is similar to the configurable lifecycle for Loss Events.
- Different paths based on an amount value
The workflow provides different levels of approval (approval level 1 and approval level 2) based on the gross loss value of the loss event.
- Use of Preference objects
Approval level 1 and approval level 2 are retrieved from the Preference object. There are different approvers based on the division where the loss event occurred. Study this example if you want to learn more about how to implement a Preference object in workflows.
Questionnaire Assessment workflow
The Questionnaire Assessment workflow moves a questionnaire assessment through the information gathering, review, and approval stages.
Workpaper workflow
The Workpaper workflow uses the Workpaper System Task view and depends upon the default schema for Workpaper and related object types.
There are multiple types of Workpapers, for example Notification Letters and Test Evidence. However, the sample workflow is high level and not defined for one specific type. In the Workpaper workflow you create, you will likely define it for a specific type of Workpaper, in which case, you can choose to have separate workflows for each type or one workflow with separate branches with conditions that specify the type.
- Who can view the Actions button
The final two forward actions, Send for Review and Approve and Complete, are restricted to specific users, the preparer and the reviewer. These actions are displayed only to them. For all other users, there is no action on the Actions button. When you encounter a situation like this, you can add an explanation to the user guidance for the stage that explains why there is no option on the Actions button.