Getting Started with the Root Cause Analysis: Interpretation of the Analysis Results
The larger a company, the more complex the processes. Intransparency is apparently pre-programmed and the gap between imagination and reality of process implementation is widening. Companies do not exhaust the process potential, because many weak points remain undiscovered.
What helps at this point? Six Sigma? Lean Management? Continuous Process Improvement? Known methods in process management – which, however, are not able to solve the core problem: A lack of transparency and undiscovered process weaknesses. Process Mining is the solution. Automated data-driven process analysis, transparency and immediate identification of vulnerabilities.
LANA Process Mining uncovers optimization potential, from performance weaknesses to problematic process deviations. These are important insights, but they are often not sufficient to derive concrete improvement measures. For this purpose we have developed the automated Root Cause Analysis.
It shows the users the causes of the problems directly, enabling them to derive concrete starting points for process optimization. The Root Cause Analysis not only identifies influencing factors that are responsible for a certain deviation. It also presents precise rules that explicitly describe when and why the problem occurred.
But let’s start from the beginning. A user selects a vulnerability within the process for the Root Cause Analysis and thus defines the problem. For example, a process deviation that was identified on the basis of the automated target-actual comparison.
The example data is an extract from the ticket system of a call center that provides IT support for customers. The classification specifies for which system the customer needs help. The attribute “Country” defines the associated location of the call center.
If we take a quick look at the results of the Root Cause Analysis in our example, we can see how many cases are categorized as “affected” in addition to the user-defined problem. Here there are 365 of a total of 2,000 cases.
The next section lists the identified rules. Under “coverage of affected cases” you can see for how many of the affected cases this specific rule applies. In other words, how large is the proportion of cases with the selected deviation for which the corresponding rule applies? The higher the percentage, the more meaningful the rule is.
The first rule indicates that in all 365 cases in which the activity “Resolution and Recovery” was omitted, the costs exceed 6,124 Euros. As soon as the costs in a case are higher than 6,124 Euros, this process deviation is always present. Conversely, the activity “Resolution and Recovery” is not omitted in any case whose costs are less than 6,124 Euros. In these cases, this process deviation never occurs.
The latter statement is quantified in the column “Affected cases contained in rule“. This provides information on the percentage of cases actually affected to which this rule applies. In this case, the percentage is 100 percent.
Let’s take a look at the second rule: In 328 of 365 cases where the step “Resolution and Recovery” was skipped, the classification corresponds to the attribute “Mail“. We can see this from the first two columns.
Now for the third column. Here we see all cases with the classification “Mail” from the entire data set. This deviation occurs in 54 percent of these cases, i.e. the activity “Resolution and Recovery” is missing in 54 percent of the cases classified as “Mail“.
This information is also useful for forecasting purposes. The higher this percentage, the higher the rule’s forecasting capability. This means that if this rule applies to any business transaction, then the probability that the selected process deviation will occur is higher. If we were to select any case classified as “Mail“, the process step “Resolution and Recovery” would be skipped with a 54% probability.
But how exactly do these rules help the user optimize their processes?
If we look at the rules in a practical way, we see two patterns. First, the associated costs for this deviation are always above average – at least over 30 percent. The average cost per case is 4,268 Euros. The user therefore knows that there is potential for cost savings in these cases and that improvement measures make sense. Secondly, these process deviations mostly occur in cases classified as “Mail“. Almost two thirds of these are in Germany and about one third in the Netherlands.
Thus the user has concrete indications, especially with the last three rules. The support personnel in Germany and the Netherlands are often not in a position to offer a solution to problems with the mail system. In further analysis steps, the user can now check, for example, whether the personnel at these locations is overloaded. If there are no logistical problems, other measures such as employee training can be considered.
In short, the identified rules apply to a significant number of cases and describe the relevant causes of weak points. So now we know what the results of the Root Cause Analysis are and how we interpret them.
Sounds exciting? We have much more in stock!
By booking a product demo with us, you will not only learn about the Root Cause Analysis. We’ll show you the entire LANA Process Mining package: from data extraction to dashboard creation.