Seeing that a process is delayed is often easy.
A dashboard can show it.
A bottleneck analysis can show where waiting occurs.
The harder question is:
Why does this delay occur?
A three-day wait at an approval step does not necessarily mean the approving team is the cause of the problem.
Missing documentation, incorrect routing, poor data created earlier or an unnecessary business rule may simply become visible at the approval stage.
The difference between a symptom and a root cause
“This step is slow” is a finding.
“Why is this step slow?” is where the analysis begins.
Root cause analysis can be performed across dimensions such as:
- Product
- Transaction type
- Channel
- Customer segment
- Team
- User role
- Process variant
- Previous activities
- Rework
- Returns
- Workload
- Time period
The activity where a problem is most visible is not necessarily the activity where the problem originates.
Go deeper than average values
Average values can hide important differences.
A process's overall average duration may look normal while specific products, customer groups, variants or teams perform significantly worse.
It is therefore useful to compare problematic cases with healthy cases.
Process mining can perform this comparison using actual process paths.
Compare variants
Cases that breach SLA, for example, can be compared with cases completed within SLA.
Useful questions include:
- Which activities appear only in problematic cases?
- Which steps repeat more often?
- Which teams see more handoffs?
- Which data attributes are associated with delay?
- Which process path produces a higher error rate?
This approach can be more explanatory than looking for a root cause through a single KPI alone.
Take the “why?” question far enough
Root cause analysis often requires several layers.
For example:
Why was the case delayed?
It returned because a document was missing.
Why was the document missing?
It was not identified in the initial check.
Why was it not identified?
The check is manual and not standardized.
Why is it not standardized?
Different teams use different checklists.
At this point, the right intervention may not be giving the approval team more resources, but redesigning the initial control.
Good root cause analysis aims not only to close the current case faster, but to reduce the probability of the same problem recurring.
Correlation is not the same as causation
Seeing two variables appear together in a dataset is not, on its own, proof of causation.
A particular team handling longer-running cases does not necessarily mean that team is slow. It may simply be that the most complex cases are routed to that team.
Process context, segmentation and business knowledge should therefore be considered together.
Analysis must turn into action
Root cause analysis is not performed to produce a report.
A finding may:
- change the process design,
- move a control to an earlier stage,
- improve data quality,
- clarify responsibility,
- create a need for automation,
- change a business rule,
- surface a training need.
The same measures should then be compared before and after the intervention.
Root cause analysis is only complete once the resulting action actually changes process behavior.
← All articles