This two-part series explores methods of actively evaluating risk as part of business processes, and incorporating elements of risk deterrence into business process models. In Part 1, we explored the context and precedents for our research. As we learned, achieving a stronger integration between risk analysis and process modeling promises to improve the quality of the modeled processes and increase the percentage of positive business outcomes those processes achieve. In this final part of the series, we will describe an innovative approach to incorporating risk management directly into business process models using the standard Business Process Model & Notation (BPMN), version 2.0.
Figure 1 provides an overview of the steps involved in the risk modeling technique described in this article.
Figure 1 Risk Modeling Technique
Figure 2 provides a reference model for the various components introduced by our technique. It is referenced as an example for the remainder of the article.
Figure 2 Risk Modeling Components – Overview
The following sub-sections address each of the steps of the technique in detail, as well as provide a “close-up” view of the areas of Figure 2 that correspond to each step.
Step 1: Identify and Organize Risks
A standard methodology for identifying and organizing the various risks (both threats and opportunities) should be employed in order to establish a baseline risk register. We prefer to use an activity-based methodology. By analyzing each activity of a business process, we are more likely to arrive at a comprehensive set of risks than by relying solely on a less structured method such as brainstorming. Of course, this is not to say that activity-based risk identification cannot be used in conjunction with other methods. The business process model could even act as a guide for a more focused brainstorming session.
Once risks have been identified, adopting zur Muellen and Rosemann’s approach of creating a Risk Structure diagram (discussed in Part 1 of this series) can help align the identified risks with the business model and determine which activities are susceptible to which risk events, a critical step in linking the Risk Pool to risk occurrences, described in a later section.
Step 2: Create the Risk Pool
Once the baseline risk register is complete, a Risk Pool is created in order to organize the identified threats and opportunities. As shown in Figure 2, threats and opportunities get their own Lanes within the Risk Pool; identified risks are modeled as Data Objects and can be color-coded either red (for threats) or green (for opportunities). Risk triggers are modeled as intermediate message send events that originate in the appropriate lane of the Risk Pool, and rely on the identified threat or opportunity as an Input Data Object. Figure 3 provides a detailed look at the Risk Pool and its contents.
Figure 3 Risk Modeling Components – The Risk Pool
Step 3: Model Risk Occurrences
Each risk trigger leads via a Message Flow to a corresponding intermediate message receive event following an Event-based Gateway within the business process. As shown in Figure 2, occurrences of both threats and opportunities can be reflected as events received after an Event-based Gateway.
Figure 4 provides a more detailed view of risk occurrences:
Figure 4 Risk Modeling Components – Risk Occurrences
Step 4: Incorporate Risk Recovery Strategies
Project Managers typically identify four major strategies for addressing Risk:
- Avoidance = Prevent the risk event from occurring by doing something less risky
- Transfer (a.k.a. Insurance) = Making the risk someone else’s problem
- Mitigation = Lessening the likelihood or potential impact of a risk event
- Assumption = Acceptance of the consequences should the risk event occur
The technique described in this article focuses primarily on the modeling of risk recovery strategies, that is, the sequence of activities that will occur following a risk event that interrupts the “normal” flow of the process. This technique does not provide a way of modeling risk transference or risk avoidance, since in these cases the risk would not be part of the business process anyway. It is also assumed that any risk mitigation activities would simply be modeled as normal activities in the business process, but this may be an area for future analysis.
More than one risk can share the same risk recovery strategy, identified in a Group construct in Figure 2. The activities and flow that follow the risk occurrence proceed in the same fashion as a non-risk event. Figure 5 provides a detailed view of several ways in which risk handling can be modeled.
Figure 5 Risk Modeling Components – Recovery Strategies
As illustrated in Figure 5, the three classifications of risk strategies that can be modeled using this technique are:
1. Unique Risk Recovery Strategy – Recovery strategy unique to a specific risk; note that a recovery strategy shared between more than one occurrence of the same risk is still considered a unique risk recovery strategy.
2. Shared Risk Recovery Strategy – Recovery strategy may be shared between occurrences of more than one risk.
3. No Recovery Strategy – Essentially dealing with the risk occurrence in a completely ad-hoc manner, or not at all.
Although Figure 5 presents a recovery strategy as a collapsed sub-process, it could just as easily be modeled as an expanded sub-process, a sequence of inline activities, or as a reference to a separate, off-page model.
Step 5: Verify Relationships
As should be apparent by now, the various elements used in this risk modeling technique can interact with each other in very straightforward or quite complex ways. In addition to the single risk, single trigger, single occurrence pattern (e.g. Threat 2), the following, more advanced scenarios are also possible:
- A single risk object having more than one trigger event (e.g. Threat 1)
- More than one trigger event leading to the same risk occurrence (e.g. Trigger Events 3 and 4)
If a risk occurrence is the result of more than one trigger event, the relationship between the triggers (and thus the original risk objects) must be identified. An inclusive gateway can be used to combine triggers using an AND relationship (all must occur); an exclusive gateway can be used to combine triggers using an OR relationship (any may occur). See Trigger Events 3, 4, 5 and 6 in Figure 2 for an example of these two variations.
The one restriction of this technique is that the one-to-many relationship between risk occurrences and trigger events must be unidirectional. In other words, although a single risk occurrence may “be caused by” more than one trigger event, a single trigger event should “cause” one and only one risk occurrence. Whether or not more than one risk object may share the same trigger event is an issue that requires further analysis.
Recruiting Process Example
In order to demonstrate these concepts as they apply to the modeling of risk in a “real world” scenario, a sample business process model was developed, which incorporates risk into a typical employee hiring process. Figure 6 below provides a sub-section of the diagram which focuses only on the portions of the model that reflect risk events and mitigation strategies.
Figure 6 Close-Up View of Risks in Employee Hiring Process Diagram
Conclusion
As this series of articles has demonstrated, evaluating threats and opportunities within the context of an organization’s business processes can yield valuable results. The specific modeling technique presented in this article forces business analysts and strategists to conscientiously think about risk while designing critical business processes, a practice that zur Muehlen and Rosemann observed has long been relegated exclusively to the discipline of Project Management. By modeling the findings using a formal notation such as BPMN 2.0, recovery strategies and opportunity response plans can easily be automated and incorporated into the organization’s broader processes.
This, in turn, exposes these threats and opportunities to the scrutiny of senior decision-makers. The result is a more complete picture of what the organization is actually up against in meeting the challenges of its market, and an increased likelihood of positive business outcomes due to conscientiously managing and proactively mitigating risks.
