Scoping a first analysis
The most common reason a first process mining analysis disappoints is not the tool or the data. It is scope.
Pick a process with three properties
Section titled “Pick a process with three properties”It runs often. Hundreds of cases in the period you can export, ideally thousands. A process that runs eleven times a quarter has no statistical shape to find.
It is mostly in one system. Every extra system multiplies the extraction effort and introduces identifier-matching problems. Order-to-cash in one ERP is a good first project; a customer journey spanning four systems and a call center is a second or third one.
Somebody is unhappy about it. Not because you need a complaint, but because you need someone who will act on the answer. An analysis nobody asked for produces an interesting deck and no change.
Turn “look at the process” into a question
Section titled “Turn “look at the process” into a question”Vague scope produces vague output. Compare:
Analyze the procurement process.
with:
Why do 15% of purchase orders take more than twenty days from request to approval, when the target is five?
The second names a population, a measure, a threshold and a gap. It tells you which case ID to use, which time window to export, and — critically — what would count as an answer.
Good first questions usually take one of four shapes: why is this slow?, why is this done twice?, why does this skip the control?, or why is this so different across teams/sites/regions?
Choose the case ID with the question
Section titled “Choose the case ID with the question”The case ID defines what “the process” means, so let the question pick it:
- “How long do customers wait?” → the order.
- “Where do parcels get stuck?” → the delivery.
- “Why are invoices paid late?” → the invoice.
If the honest answer is “the interesting part is how orders, deliveries and invoices interact”, note it and carry on with a single case for the first pass. Object-centric analysis handles it properly, and it is a better second analysis than a first one.
Set the time window deliberately
Section titled “Set the time window deliberately”Long enough to contain complete cases — several times the typical end-to-end duration — and recent enough that the process has not changed underneath you. If there was a system migration or a reorganization in the window, either exclude it or make comparing before and after the analysis itself.
Agree in advance what would change
Section titled “Agree in advance what would change”Before you look at anything, ask the process owner: if we find that X, what would you do? If there is no answer, you are producing a report, not an analysis. Better to find that out now than at the end.