Loss Event Management Use Case Design

This topic explains the Loss Event Management use case design.

Architecture Diagram

The following diagram shows the relationships between the applications in the Loss Event Management use case.

Download the source file of the diagram here: Loss Event Management Architecture Diagram

Note: Feeds that create Metrics from a metric library (either the Business Process or Risks) do not also create Risks records from the associated Risk Statement records. Business Asset Catalog objects and their associated assessments are not automatically scoped into Risk Project and must each be scoped in manually.

Applications

The following table describes the use case applications.

Application	Description
Contacts	The Contacts application serves as a central repository for contact information, is utilized across multiple areas of Archer, and contains information that is often leveraged by other use cases. Updates to a profile record within this application automatically propagate in any records with displayed contact information. Note: The Contacts application is included in the Enterprise Catalog package.
Loss Events	The Loss Events application allows you to respond to internal exposures and external events that present a financial risk to your organization. You can document, classify, and manage actual losses, near misses, and external comparable loss events if tracked by the organization and loss classification, capture event impacts, and perform root cause analyses and remedial activities. You can also relate loss events to statements of potential risk in the Risks application to quantify the likelihood and impact of a risk.
Loss Event Impacts	The Loss Event Impacts application records the loss incurred by any Business Unit across multiple organizations due to any Internal Event. As a Loss Event Owner or Impact Initiator, you can capture details such as the event that led to the Impact, loss amount, and the actions that the affected business unit has taken to address it. You can capture the required details and assign the record to the Impact Owner for reviewing these details and adding more information. Based on the approval rules set, approval workflow will be triggered once the Impact Owner submits the record.
Impact Approval Rules and Thresholds	The Impact Approval Rules and Thresholds application has 2 levels: Impact Approval Rules and Threshold. Impact Approval Rules: Enables the Ops Admins to define the Rule and Type (based on which the impact workflow will be initiated) for a Business Unit. Select a Default Owner. If no approver is found for the amount defined in the Impact or Threshold, the Default Owner becomes the approver. Thresholds: Defined to facilitate monetary range-based Approvals for a combination of Business Unit and Event’s Impact Type (as defined in the Level 1) so that the Impacts can be appropriately routed to the Approver.

Access Roles and Record Permissions

The following table describes the use case access roles and rights.

Access Role	Description
RM: Admin	This role serves as the administrator for the use case. (Risk Manager, Risk Manager Specialist)
RM: Executives	This role provides the appropriate access levels within the use case to the executives team (CFO, CEO, Controller).
RM: Manager	This role provides create, read, and update access to management stakeholders within the use case.
RM: Owner	This role provides create, read, and update access to business process owners within the use case.
RM: Read Only	This role provides read-only access for the use case.

Note: For detailed, page-level access rights, see the Data Dictionary.

The following table describes the specific roles (fields) within the Loss Event Management applications. These fields may correspond to different members of the team depending on the actual nature of the policies or standards. As part of the implementation process, these roles should be designated.

Role	Description
Business Unit Manager	Can be used to create loss events records and to accept or reject assessments and to create loss event impact record.
Business Unit Coordinator	Can be used to create loss events records and loss event impact record.
Risk Manager	Can be used to review and update loss events records or to reassign them to a Risk Specialist and to create loss event impact record.
Risk Specialist	Can be used to review and update loss events records.
Controller	Can be used to review, sign-off on, or reject loss events records that have exceeded thresholds.
CFO	Can be used to review, sign-off on, or reject loss events records that have exceeded thresholds.
CEO	Can be used to review, sign-off on, or reject loss events records that have exceeded thresholds.
RM Admin	Creates records for impact approval rule application. Note: Only RM Admin can add or modify the records. All the other roles of loss event application can only read the records of impact approval rule application.

Dashboards

The following table describes the use case dashboards.

Dashboard	Description
Executive Management	This persona-based dashboard is used by Controllers, CFOs, and CEOs to track risk exposure and review loss events that require executive sign-off.
Business Unit Manager	This persona-based dashboard is used by Business Unit Managers and Business Unit Coordinators to create new loss events, view unapproved loss events, and view loss events requiring executive review or sign-off.
Risk Manager	This persona-based dashboard is used by Risk Managers and Risk Specialists to view loss events awaiting review.

The following describes reporting limitations for each dashboard in this use case. Reporting limitations occur only when the user does not have the related use cases licensed.

Executive Management

The following table describes the reporting limitations of the Executive Management dashboard.

iView	Use Case Reporting Limitations
High Risks	Report is invalid.
Risk Approval Assessment Awaiting Review	Report is invalid.
Failed KRI	Report is invalid.
Failed KCI	Report is invalid.
Failed KPI	Report is invalid.
Likelihood Vs Impact Heat Map	All reports are invalid.
Risks Metrics Management	All reports are invalid.
Risks by BU and Rating	Report is invalid.
Risk Exposure	All reports are invalid.
Risk inventory and Top Down Risk Assessment	All reports are invalid.

Business Unit Manager

The following table describes the reporting limitations of the Business Unit Manager dashboard.

iView	Use Case Reporting Limitations
Business Unit Manager Quick Links	2 of 4 quick links are invalid.
My Upcoming metric	Report is invalid.
My Past Due metric	Report is invalid.
My Failed metric	Report is invalid.
All Risks	Report is invalid.
Not Rated Risks	Report is invalid.
Likelihood Vs Impact Heat Map	All reports are invalid.
Bottom-Up Risk Project Analysis	Report is invalid.
Risk Inventory for Business Unit Manager	All reports are invalid.
Key Indicator Summary	All reports are invalid.
Risk Self-Assessment Summary	All reports are invalid.

Risk Manager

The following table describes the reporting limitations of the Risk Manager dashboard.

iView	Use Case Reporting Limitations
Risk Manager Quick Links	4 of 5 quick links are invalid.
All Risks	Report is invalid
Open Risk Project	Report is invalid.
Failed KRI	Report is invalid.
High Risks	All reports are invalid.
Likelihood Vs Impact Heat Map	All reports are invalid.
Risks by Business Unit and Rating	All reports are invalid.
Risk Metrics Management	All reports are invalid.
Risk Inventory for Risk Manager	All reports are invalid.
Business Process by Risk Rating	All reports are invalid.
Bottom-Up Risk Analysis Reports	All reports are invalid.
Self-Assessment Status and Change Tracking	All reports are invalid.
Control Assessment Concerns	All reports are invalid.
Risk Remediation Plans	All reports are invalid.
Self-Assessments Awaiting Risk Manager Review	All reports are invalid.

Advanced Workflow

The following advanced workflow is applied to all loss events in the use case.

Task 1: Initial Loss Entry

The Business Unit Manager or Business Unit Coordinator first creates a Loss Events record corresponding to the losses that have occurred for the company. The Loss Events record is then enrolled in advanced workflow, and is assigned to the Risk Manager. The Risk Manager receives a notification, and the record progresses to the Review stage.

There can be multiple impacts to enter within the records. If you select ‘Has Multiple Impact’ = No, there is no change in the existing workflow. If you select ‘Has Multiple Impact’ = Yes, then from the initial review stage, the loss event workflow moves to “Pending Impact Approval” stage and waits until all the impacts are closed. The impact is closed when the record is either approved or canceled.

Once all the impacts are closed, based on the gross loss/threshold amount, the workflow is redirected to ‘Controller, CFO and CEO’ approver.

The Loss Event Impact application:Through the Loss Events, Event Impacts field, the BU Manager, BU Coordinator or Risk Manager creates an associated Impact record for the same BU or a different BU in the parent Loss Event. If there are more than 1 Business units, each 1 needs a separate impact. Once an Impact record is created and the mandatory fields are selected, the records waits for the parent Loss Event record to be submitted. Once the parent Loss Even record is submitted, the Impact record is sent to the Impact Owner for submission,

After the Impact owner submits the record, the workflow moves to the Approver or the Event Owner for approval.

Approval process in the Impact happens with the help of another application named the “Impact Approval Rules” (IAR).

Each IAR record can have n number of thresholds created by an RM Admin personnel. Each of the IAR record should have a unique BU and Type combination and it’s the sole responsibility of the RM Admin. So that only 1 rule satisfies an impact’s BU type and hence a unique owner is chosen.

When the impacts meet the criteria against any of the existing rules – The 2nd level threshold records of the individual IAR record is traversed, to match, the gross loss amount from the impact, to a unique threshold which has a matching min-max range. And the appropriate Approver field from the threshold is picked up as the Impact Approver.

If it fails – for the gross loss amount to fall in the range of the threshold of the matched rule- then the default owner from the rule is pulled into the impact as the Approver.

If there is no matching Rule – as that of the BU and Type of the impact, the Loss Event owner (that is, the creator of the Loss event is populated in the impact and acts as the Approver).

The Impact has 3 possible workflow stages after Submission from the Impact Owner:

1. Approved and Closed – the status of the impact is marked as Approved & Closed and the workflow ends.

2. Request more information – the impact is routed back to the impact owner and the workflow continues.

3. Canceled – the impact status is marked as Canceled and the workflow ends.

Note:  

1. The Impacts application has an Impact Owner field, who submits the Impact record, open for any of the Loss Event group to be picked up. It is the responsibility of the record creator to ensure that the Impact Owner belongs to the Impacted BU and hence to have the appropriate permissions.

2. Each of the impact approval rules need to have a unique BU and Type combination, and an RM Admin. This ensures that, when the impacts are met against the rules, only the appropriate approver is picked up.

3. Each of the thresholds within a rule must have unique minimum and maximum limits. That is, in case they are overlapping across the records, all the matching owners would be pulled into the impacts’ applications as the approver.

4. The rule status must be in 'Published' status for it to be eligible to be used by an impact.

Below is the Loss Event Management swimlane diagram that you can refer to.

Below is the swimlane diagram for Loss Event Impact that you can refer to.

Download the source file of the diagram here: Loss Event Management Swimlane Diagram

Task 2: Review Stage

The Risk Manager reviews and updates the loss event record. The Risk Manager provides Root Cause Analysis and ties the loss to an existing Risk. If the Risk Manager needs additional information, they can reassign the record to a Risk Specialist. The Risk Specialist then updates the record with the data required. Once all the data is entered by the Risk Manager or the Risk Specialist, the record is reassigned to the Business Unit Manager. The Business Unit Manager can then accept or reject the assessment. Once the assessment has been accepted, the record advances to Task 3: Check Threshold Stage.

Task 3: Check Threshold Stage

The assessment is checked against the threshold numbers for the Controller, the CFO, and the CEO in that order. The threshold numbers for the Controller are set in the Business Unit record. The threshold numbers for the CFO and CEO are set in the Company record. If the loss amount exceeds any of the thresholds set for those 3 personas, notifications are sent to the appropriate personas. If no thresholds were exceeded, the advanced workflow is complete, and the record exits the advanced workflow. If any of the thresholds were exceeded, the record progresses to Task 4: The Threshold Review Stage.

Task 4: Threshold Review Stage

In the Threshold Review Stage, the Controller, CFO, and CEO must review the record if the thresholds are exceeded. When the initial threshold is exceeded, the Controller must sign-off on the assessment. When the medium threshold is exceeded, both the Controller and the CFO must sign-off on the assessment. If the highest threshold is exceeded, the Controller, CFO, and CEO must sign-off on the assessment.

Any of these 3 personas can accept or reject the assessment that the Business Unit Manager submitted. If anyone rejects the assessment, the record is sent back to the Threshold Review Stage, and the Business Unit Manager must update the record again. Once all the appropriate personas have signed-off the assessment, the record exits the advanced workflow.