Process Mining Fundamentals
Your flowcharts describe the process you wish you had. Your event logs describe the one you actually have - and the gap between them is where every improvement hides.
Walk into almost any operations review and you will find a process map on the screen. It is tidy. Boxes flow left to right, decisions branch politely, the happy path glows. Everyone nods. And almost none of it is true.
This is not because people lie. It is because process maps are built from memory and intention, and both are unreliable narrators. We remember the path we designed, not the 14% of cases that took a detour. We describe our own step and assume the handoffs work. We document last year's process and forget that three workarounds have since calcified into standard practice. The map is an honest account of how we believe work flows. The trouble starts when we manage the belief instead of the reality.
The instrument we were missing
Every modern system is a diligent, tireless scribe. Each approval, posting, status change, and ticket update is written to a log with a timestamp and an actor. Your ERP knows precisely how long every purchase order waited for sign-off last quarter. Your ticketing system knows exactly how many incidents bounced between two teams before resolution. This record has existed for years. What was missing was an instrument to read it as a process rather than as a pile of rows.
Process mining is that instrument. Give it an event log - at minimum a case ID, an activity name, and a timestamp - and it reconstructs the process as it genuinely happened, across every case, with no interviews and no assumptions. It is the difference between asking a department how they think work flows and watching forty thousand cases flow with your own eyes.
Three questions, endlessly useful
The whole discipline rests on three questions. What does the process actually look like? That is discovery: an algorithm draws the model directly from the log, no human sketching required. Where does reality break the rules? That is conformance: replay the real cases against the model you intended and measure exactly where, how often, and how badly they diverge. How do we make it better with what the data shows? That is enhancement: layer timing, frequency, and bottleneck information onto the model until the expensive parts of the process light up.
These questions are deceptively plain, but they dismantle the most common organizational fictions. "We always get a second approval on large orders" survives exactly until the log shows it was skipped on eight thousand of them. "The delay is in fulfillment" survives until the performance map reveals the cases were actually sitting in an approval queue for two days. Evidence ends arguments that opinion could only prolong.
From pretty diagram to hard decision
The risk in process mining is falling in love with the picture. A discovered model is genuinely striking the first time you see it - and a discovered model is not the deliverable. The deliverable is a ranked, sized list of things to do.
Discovery hands you variants: the distinct end-to-end paths cases take. The single most clarifying statistic in many projects is that 80% of cases follow five paths while the rest scatter across three hundred. That number reframes a "process" as what it often is - a thin spine of order surrounded by improvisation. Conformance hands you deviations, each one a sentence you can take to an owner: this control was skipped on these cases, and those cases had triple the dispute rate. Performance analysis hands you bottlenecks and rework loops, each with a duration and a frequency, which together convert neatly into hours and money.
That conversion is what gets work funded. "This step runs twenty-four thousand times a year, takes six minutes, and never branches" is an argument no workshop guess can match, because every number is traceable to data that already exists.
The honest engine behind automation
Process mining has surged precisely as organizations pour money into automation, and the two belong together. The classic robotic-process-automation failure is pointing a bot at a process nobody actually understood; the bot faithfully reproduces a broken, exception-riddled flow and then breaks every time reality deviates. Process mining is the antidote. It tells you which steps are genuinely high-volume, uniform, and rule-based - the steps worth automating - and it tells you how much of the real caseload a bot would actually cover before a human has to step in. You automate the path the data shows, not the path the manual describes.
The same logic makes process mining the natural partner of process mapping. Mapping captures intent; mining captures behavior; the space between them is the backlog. Run both and you stop guessing how wide that space is and start measuring it.
A discipline, not a dashboard
A few cautions keep this honest. A polished model built on a dirty log is more dangerous than no model at all, because it looks authoritative - so the unglamorous work of profiling and cleaning the event log is not optional. And because logs often carry employee identifiers, it is tempting to rank people by speed; resist it completely. That instinct poisons trust, invites gaming, and usually breaks data-protection law. The target is the process, not the person at the desk.
Done with that discipline, process mining changes the texture of operational work. The map on the wall stops being a comforting fiction and becomes a hypothesis you can test every week against what your systems already recorded. You stop managing the process you wish you had, and start improving the one you actually run.
No comments:
Post a Comment