Purpose of the Module
The Risk Module helps you identify, describe, and evaluate risks. From these assessments, you can derive and implement appropriate countermeasures. Additionally, the module enables easy management of risks to facilitate regular reassessments.
Approach
The Risk Module follows the continuous improvement model. The process repeats at regular intervals. A risk passes through several statuses:
- Risk draft
- Managed risks
- Discarded risks
Risks in Draft Status
These drafts can be created by any user. Once a risk occurs in your daily work, you should add it to the module with its baseline data, risk name, description of cause and impact, affected area, and information circle. You can also link the risk to a Q.wiki process to draw direct conclusions about related risks from the documented process.
Managed Risks
These risks are managed by the risk manager. Once a new risk is submitted, it is the risk manager's task to review it initially, complete any missing information, and prepare the risk for the next risk round.
Risk rounds should occur regularly and serve to discuss, evaluate, and decide on appropriate measures to reduce risk impact. These meetings typically take place with an interdisciplinary group of managers. Each risk is assessed across three dimensions: severity, occurrence probability, and detection probability. The characteristics of these dimensions are defined in an individual evaluation schema. Multiplying these three dimensions yields the Risk Priority Number (RPN). The RPN indicates how critical a risk is. Critical risks must be assigned measures to reduce the RPN. As long as a risk's RPN exceeds your defined threshold, it will be reviewed again in the next risk round.
Discarded Risks
These risks have no relevance, have been submitted twice, or have become non-critical through ongoing risk management.
Module Elements
A single risk in the Risk Module is divided into three sections:
- Risk information (risk data, description of cause and impact, risk source)
- Risk evaluation
- Measures to reduce risk
Risk Information
This section includes risk data, the description of cause and impact, and the link to a Q.wiki process. In addition to the baseline data, you can activate the Protected Risk visibility control in the page header. This restricts access rights to the QMGroup and the selected information circle.
Evaluation
Here you'll first find the individual risk evaluation schema. You can access it via a link to a separate Q.wiki page and consult it at any time for each risk. Below that, you evaluate the three risk dimensions:
- Severity: The more severe the risk's impact, the higher you should rate this dimension.
- Occurrence Probability: The more frequently the risk occurs, the higher you should rate this dimension.
- Detection Probability: The harder the risk is to detect upon occurrence, the higher you should rate this dimension.
It is also possible to accept risks with a low RPN. If you distinguish between different types of risks—for example, IT security risks, process risks, business risks, or environmental risks—you can differentiate them here.
Measures
A task management system is implemented here that allows you to define measures to reduce risk impact. Measures can be assigned to individuals and given deadlines for completion. Use this module in regular risk rounds to track what has happened since the last round and define new measures if needed to further reduce the RPN.
Rights Management
In the Roles tab of the configuration, you define which users act as risk managers. Add this group of people to the QMGroup role. Risk managers, along with the information circle, are authorized to view risks. Additionally, risk managers can view and edit all protected risks where they are not part of the information circle. Risk managers also manage submitted risks so they can be discussed in risk rounds.
By default, the Risk Module is configured for maximum transparency, allowing every user to view and edit all risks and content. You can activate visibility control for individual risks in the page header via Protected Risk, which restricts access rights to the creator, information circle, and QMGroup of that particular risk.
Required Adjustments Before Production Use
The baseline configuration of this module requires at least two adjustments before you can use it in production:
- Define the circle of risk managers: Open module settings > Roles tab > Add users to the
QMGrouprole - Define the module from which Q.wiki links are allowed: Open module settings > Data and Views tab > Risk data content block > Q.wiki Link field > Select the process module
Before using the module, you should develop your own risk evaluation schema. Define the three RPN dimensions and differentiate the levels of the 10-point scale so that a shared understanding of the scale develops during risk evaluation. Additionally, you should determine a critical RPN threshold above which measures to reduce risk must be implemented.
This necessary organizational groundwork should not be underestimated or neglected. Our consultants with years of experience are happy to support you in implementing and individually configuring the module.
Evaluation Schema
Severity
| Rating | Impact | Financial Loss |
|---|---|---|
| 10 | Endangers company or people without warning | > 200% EBIT |
| 9 | Endangers company or people with warning | > 200% EBIT |
| 8 | Very high | > 100% EBIT |
| 7 | High | > 50% EBIT |
| 6 | Moderate | > 10% EBIT |
| 5 | Low | > 5% EBIT |
| 4 | Very low | > 1% EBIT |
| 3 | Minimal | > 0.1% EBIT |
| 2 | Negligible | < 0.1% EBIT |
| 1 | None | ~ 0 |
Occurrence Probability
| Rating | Probability | Error Rate |
|---|---|---|
| 10 | Constant occurrence | Every process run / Company: hourly |
| 9 | Constant occurrence | Every 2nd–10th process run / Company: daily |
| 8 | Frequent occurrence | Every 11th–20th process run / Company: weekly |
| 7 | Frequent occurrence | Every 21st–40th process run / Company: monthly |
| 6 | Occasional occurrence | Every 41st–100th process run / Company: quarterly |
| 5 | Occasional occurrence | Every 101st–200th process run / Company: annually |
| 4 | Occasional occurrence | Every 201st–400th process run / Company: annually |
| 3 | Rare occurrence | Every 401st–1,000th process run / Company: rare |
| 2 | Rare occurrence | Every 1,000th–2,000th process run / Company: rare |
| 1 | Almost never occurs | > 2,000th process run / Company: never |
Detection Probability
| Rating | Detection | Probability |
|---|---|---|
| 10 | Event is not detected (before full damage occurs) | ~ 0% |
| 9 | Event may not be detected (before full damage occurs) | ~ 30% |
| 8 | Event is detected with low probability (before full damage occurs) | ~ 40% |
| 7 | Event is detected with low probability (before full damage occurs) | ~ 50% |
| 6 | Event could be detected before full damage occurs | ~ 60% |
| 5 | Event could be detected before damage occurs | ~ 70% |
| 4 | Event is detected with good probability before damage occurs | ~ 80% |
| 3 | Event is detected with good probability before damage occurs | ~ 90% |
| 2 | Event is almost certainly detected before damage occurs | ~ 95% |
| 1 | Event is certainly detected before damage occurs | ~ 100% |
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article