Look behind the curtain of process analysis | Root Cause Analysis with LANA Process Mining

As a LANA user you really have a relaxed lifestyle. The process analysis is a self-runner, so to speak, and with just one click, optimization potential is uncovered. But have you ever wondered what happens behind the scenes? How does LANA perform complex data evaluations, that would otherwise take weeks of manual work, within seconds?

No problem, I’ll explain it to you. In this article we are publishing previously top-secret information about our Machine Learning algorithm, responsible for the automated Root Cause Analysis. Let’s demystify the world of complex and confusing algorithms!

If you need an overview of what the LANA Root Cause Analysis can do, have a look at our article Using data to get to the bottom of process deviations.

The Root Cause Analysis uncovers the causes of process weaknesses and provides the user with data-based starting points for process optimization. It not only identifies responsible influencing factors, but also formulates precise rules that explicitly describe when and why the problem occurred.

But how does the automated Root Cause Analysis work? What happens in the seconds after the user has clicked on the light bulb icon? How is the algorithm able to perform weeks of manual work on complex data analysis in such a short time?

First of all, the main actor: The Root Cause Analysis is performed by our specially developed Machine Learning algorithm, which is based on the method of inductive machine learning. The ML-algorithm identifies relevant structures in the data and is responsible for establishing the rules — so-called classifiers — with the highest possible precision, coverage and predictive capability.

Don’t panic — we will clarify calmly what the terms mean in this context and why they are so important, step-by-step.

But first things first: Logically, the Root Cause Analysis is applied after the Performance or Conformance Analysis. These analyses are used to identify process vulnerabilities. As soon as the user selects a vulnerability to be investigated, they define the problem for the algorithm. Let’s imagine, for example, that the user wants to analyze a deviation that was detected using the automated target-actual comparison.

The problem is of a binary nature, i.e. a case or business transaction either shows a process deviation or it does not. Take the following example: The activity “Resolution and Recovery” in the displayed process model is either skipped or executed for a case. The same applies to other types of vulnerabilities, such as bottlenecks.

Then the fun begins: In the first step, the ML algorithm subdivides the entire dataset of a process according to this problem, i.e. into “deviant” or “not deviant”. It then analyzes the influencing factors or attributes that have been assigned to the classification “deviating”. The ML algorithm identifies significant patterns or regularities.

These can be influencing factors or combinations of influencing factors that correlate with the problem in various forms. The rules or classifiers are formulated on the basis of this information.

Are you still with us? Now we come to the next step: Here the “best” are selected from the determined rules, which are finally presented to the user. How exactly are the best rules selected? Good question. The approach is comparable to the decision tree procedure. This means that the rules are checked sequentially according to the characteristics of certain properties and classified on the basis of a decision rule. The aim is to classify the rules as significant or not significant.

So far, so good. The challenge lies in determining the decision rule, i.e. when a rule is classified as significant. To do this, we first clarify which requirements we have of a rule. The rules should apply to as many cases as possible, i.e. have high coverage, and be as precise as possible.

Yes, the elephant in the room is still the precision. We’re changing that now.

The precision of a rule defines how precisely the cause is described. Less precise rules tend to apply in many cases, while very precise rules tend to apply only in isolated cases. That wasn’t very helpful yet? Let’s give it a try with an example. The whole thing is quite intuitive: If a rule says that the costs per case are over one euro — but we know that the average costs per case are around 4000 euro — then the rule is very imprecise. Most probably, however, this rule applies to almost all cases and thus has a very high coverage. The opposite is also true. An optimal compromise must therefore be found.

The ML algorithm therefore has to determine the optimal threshold — the decision criterion — between a precise rule with low coverage and an imprecise rule with high coverage. Of course, there are also extreme cases where, for example, precision and coverage are both very high.

Let’s put a question to the audience: Who knows what kind of problem we’re dealing with here?

Yes, it is the good old optimization problem. The ML algorithm has to find the point that maximizes the precision and the coverage at the same time. Why is the determination of such a decision criterion so important?

For example, a rule that is very precise, but only applies to one case, provides the user with little information about their data or the cause of the problem. This only explains what caused the deviation in exactly this case. It is unclear whether the deviation was caused accidentally or whether there is actually a problem in the process or another problem. Therefore, only rules that are a combination of high precision and high coverage are displayed, so that the user is shown significant causes of the problem, from which they can derive concrete improvement measures.

Once the ML algorithm has solved the optimization problem, the significant rule can be presented to the user.

So much for the topic “automated Root Cause Analysis”. You’ve already forgotten half of it? No problem, here is the more reader-friendly short version:

If the user selects a vulnerability for the Root Cause Analysis, they provide the ML algorithm with a binary problem. The ML algorithm divides the process data accordingly, analyzes the relevant data according to patterns or regulations that represent the potential causes. On the basis of this information it then formulates rules. Within a classification procedure, the significant rules are determined from these rules. These rules are as precise as possible and apply to as many cases as possible. This provides the user with meaningful rules on the basis of which they can derive concrete improvement measures. In this way, the realization and the process itself can be improved systematically.

Sounds exciting? Here you can read more about the topic!

Originally published at lana-labs.com on October 11, 2018.