From process map to a decision
You have imported the log and discovered a model. This page is about the gap between having a diagram and having something worth saying.
The map is not the finding
Section titled “The map is not the finding”A discovered process map is compelling and slightly dangerous: it looks authoritative, and people will draw conclusions from its shape alone. Its shape is a function of two things you control — the case ID and the simplification threshold — and one you do not: what the source system happens to log.
So treat the model as a way to generate questions, not as the answer.
A reading order that works
Section titled “A reading order that works”Start with the happy path. Follow the thickest route end to end. Ask the process owner whether it matches what they think happens. Where it does not, you already have a conversation worth having.
Then look at what loops. Backward arrows are rework — something was done again. This is usually the most valuable thing on the diagram, because rework is unambiguous waste and normally fixable without redesigning anything.
Then look at what is skipped. A path bypassing a step everyone believes is mandatory is either a legitimate exception nobody documented, or a control that is not working. Both are findings; they go to different audiences.
Then look at what you did not expect to see at all. Activity names nobody mentioned in the workshop are often the manual workaround holding the process together.
Simplify to read, then look at what you hid
Section titled “Simplify to read, then look at what you hid”Real logs contain rare behavior, and showing all of it makes an unreadable diagram. Raise the noise threshold until the common case is legible — then explicitly go back and look at the behavior you filtered out. The 2% you removed can be the entire point: an exception path, a control bypass, a category of case nobody knew existed.
Keep both versions. Re-running with a different threshold creates a second model beside the first rather than replacing it, so you can show the clean picture and still answer “what did you leave out?”
Distrust these three patterns
Section titled “Distrust these three patterns”They usually indicate a data problem rather than a process problem:
- Everything appears parallel — timestamps are too coarse to establish order.
- Hundreds of activities — the activity column contains identifiers, not labels.
- Any activity can follow any other — the case ID is not identifying a single journey. Often a sign the data is genuinely object-centric.
What a finding looks like
Section titled “What a finding looks like”A finding names a population, quantifies a gap, and points at a cause:
18% of purchase orders return to Request approval at least once. Those cases take a median of 11 extra days. In 70% of them, the first submission was missing a cost center.
That is actionable. “There is a lot of rework in approvals” is not, and neither is a screenshot of the map.