Note: The risk app presented in this article has been created based on the default app template of the app generator. The apps created with the app generator can be customized to meet individual requirements. This guide describes the basic functions of the standard app template.
Aim of the app
The application is used to identify risks, describe and evaluate them. From this, suitable measures can be derived and initiated. In addition, the application makes it easy to manage risks in order to facilitate regular reassessments.
The risk app is based on the continuous improvement model, which is why the procedure is repeated at regular intervals. A risk passes through several statuses in the app:
- Risk Draft
- Managed risks
- Discarded risks
Risks in risk draft status
These drafts can be created by any user in the app at any time. As soon as a risk occurs in everyday work, it should be included in the app with its framework data, risk name, description of cause and effect, affected area and information circle. It is also possible here to link the risk with a process from Q.wiki in order to be able to draw conclusions about accompanying risks directly from the documented process.
These risks are managed by the risk manager. As soon as a new risk is submitted, it is his task to sift through this risk for the first time, complete missing information and prepare the risk for the next risk round.
Risk rounds should be held on a regular basis and are used to discuss and evaluate managed risks and decide on appropriate actions to reduce the impact of the risk. These meetings usually take place in a circle of interdisciplinary managers. Each risk is evaluated in three dimensions, significance, probability of occurrence and probability of detection, with the characteristics of the dimensions to be defined in an individual evaluation scheme. These three dimensions multiplied together result in the risk priority number (RPN). The RPN is the indicator of how critical a risk is. Critical risks are to be documented with measures to reduce the RPN. As long as a risk has an RPN above the specially defined threshold, it is considered again in the following risk round.
These risks have no relevance, have been submitted twice, or have become non-critical through continuous risk management.
A single risk is divided into three blocks in the risk app:
- Risk details (risk data, description of cause and effect, risk source).
- Evaluation of the risk
- Measures to reduce the risk
The risk data, the description of cause and effect as well as the linkage of the risk to a process from which the risk arises fall under information on the risk. In addition to the framework data, the visual protection Protected risk can be activated here in the document header. Then access rights are restricted to the QMGroup and the selected information group.
Under Assessment, the individual risk assessment scheme can be found first. This is accessed via a link to a separate Q.wiki page and can be read at any time in any risk. Below this, the three risk dimensions are assessed:
- The more severe the impact of the risk, the higher the importance dimension is to be rated.
- The more frequently the risk occurs, the higher the probability of occurrence dimension is to be rated.
- The more difficult the risk is to detect when it occurs, the higher the probability of detection dimension is to be rated.
In addition, it is possible to accept risks with a low RPN. If different risks are considered, for example IT security risks, process risks, business risks, environmental risks, these can also be differentiated here.
Under Measures, task management is implemented, which makes it possible to define measures to reduce the impact for the risk. Measures can be assigned to persons and deadlines can be defined by when the measures must be implemented. This area is used to track what has happened since the last round in the regular risk rounds and defines new measures as needed to further reduce the RPN.
The Roles tab of the configuration defines which users or groups are assigned to the Risk Manager role. These role owners are, in addition to the information circle, authorized to view risks. In addition, risk managers can also view and edit all protected risks for which they are not part of the information circle. Furthermore, risk managers control submitted risks so that they are discussed in the risk round.
Additionally, the risk app is designed for maximum transparency by default, allowing any user to view and edit all risks as well as content. A view protection can be activated for individual risks in the document header via Protected Risk and restricts access rights to the creator, information circle and QMGroup of the respective risk.
No mandatory customizations to the application are required in the risk app and it is ready for immediate use.
Before using the application, a custom risk schema should be developed. For this purpose, the three dimensions of the RPN would be defined and the levels of the 10-point scale would be delineated from each other in such a way that a common understanding of the scale emerges during the risk assessment. In addition, a critical RPN should be determined, above which measures to reduce the risk are applied.
Tip: The empirical value is an RPN of 125.
This necessary organizational preparatory work should not be underestimated or neglected. Consultants with many years of experience will be happy to assist with the introduction and individual configuration of the app.
Risk Assessment Scheme
Endangerment of the company or people without warning
> 200% EBIT
Danger to the company or people with advance warning
> 200% EBIT
> 100% EBIT
> 50% EBIT
> 10% EBIT
> 5% EBIT
> 1% EBIT
> 0,1% EBIT
< 0,1% EBIT
Probability of occurrence
every process run / company: hourly
every 2nd-10th process run / company: daily
every 11th-20th process run / company: weekly
every 21st-40th process run / company: monthly
every 41st -100th process run / company: quarterly
every 101st - 200th process run / company: annually
every 201st-400th process run / company: annually
every 401st-1,000th process run / company: infrequent
every 1000th-2,000th process run / company: rare
Almost never occurs
> 2,000th process run / company: never
Probability of detection
Event is not detected (before full damage occurs)
Event may not be detected (before full damage occurs)
Event is detected with only small chance (before full damage occurs)
Event is detected with only a small chance (before full damage occurs)
Event could be detected before full damage occurs
Event could be detected before damage occurs
Event is detected with good chance before damage occurs
Event will be detected with good chance before damage occurs
Event is almost certainly detected before the damage occurs
Event is detected with certainty before the damage occurs
Was this article helpful?
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
We appreciate your effort and will try to fix the article