Process Mining Before Automation: What It Actually Tells You

Automation projects fail in a predictable way. Someone maps the process in a workshop, everyone agrees the map is correct, a bot or a flow gets built to match it, and then it breaks on contact with the real work. The map was never wrong on purpose. It just described the process people believe they follow, not the one their systems actually recorded. Process mining closes that gap. It reads the timestamps your CMMS and ERP already write, and reconstructs the process as it truly ran, case by case. This is an explainer on what that reconstruction tells you, what it costs, and how to get most of the value without buying anything.

What an event log actually is

Process mining is not AI magic and it is not modelling. At its core it needs exactly three columns pulled from your operational systems.

• Case ID → the thing that flows through the process. A work order number. A purchase requisition. A single invoice. Everything that happens to that one case shares its ID.
• Activity → the step that happened. "Work order created", "Assigned to technician", "Purchase order approved", "Invoice matched". These are usually the status values or transaction types your system already stores.
• Timestamp → when that step happened, to the minute or second. This is the column everyone underestimates, and the one everything depends on.

That is an event log. One row per event, thousands of events per case type, ordered by time. Give a process mining engine those three columns and it will draw you the real process graph without anyone describing it. A purchase-to-pay log looks the same in shape: the case is the requisition or PO, the activities are raise, approve, receipt, invoice, match, pay, and the timestamps come out of the ERP transaction history. The technique does not care whether the source is maintenance or finance. It only cares that each event names a case, an activity, and a time.

What a real event log looks like

Here is a single work-order case as it comes out of a real CMMS with its purchasing steps pulled from the connected ERP. One case ID, nine events, two source systems stitched together on the shared work order number.

Read the timestamps, not just the steps. The physical repair took three hours and twenty-five minutes on 9 March. The case took nine days. Almost all of that elapsed time sits in the gaps between rows: waiting for approval, waiting for parts, waiting for a supervisor to close it. Multiply that single case by ten thousand and you have your process. Process mining is what turns that pile of rows into a picture.

The happy path against the long tail

The first thing a process mining tool produces is a variant analysis. A variant is one distinct path through the process, one exact sequence of activities. The tool groups every case by its path and ranks the variants by frequency. This is where the flowchart on the wall meets reality, and usually loses.

That last line is the point. Across the operators I have looked at, the single documented happy path accounts for well under half of actual cases, often between a third and forty percent. The rest scatter across hundreds of variants that no one designed and no workshop would ever have drawn. If you automate only the happy path, you have automated the minority of your volume and left the expensive, messy majority untouched.

Three findings automation alone never gives

Automation tools are good at doing a known step faster. They are blind to the shape of the process around that step. These three findings come out of process mining reliably, and out of a bot deployment never.

1. Rework loops

A case that reaches "completed" and then returns to "in progress" is rework. On a variant map it shows as an arrow that flows backwards. You cannot see rework from a single case because it looks like normal activity, but in aggregate it is unmissable: a fat backward arrow carrying fifteen percent of your volume through the same step twice. Automating the step does nothing about the loop. Finding the loop tells you the real problem is upstream, usually a bad handover or missing information at intake.

2. Approval ping-pong

Approve, reject, amend, resubmit, approve again. Each hop looks legitimate in isolation. On a process graph it is a visible cycle between the requester and the approver, and process mining will tell you exactly how many cases loop, how many times, and how many days each loop adds. This is the finding that most often changes a policy rather than a system, because the fix is usually an approval threshold or a mandatory field, not a bot.

3. Waiting time between activities, not inside them

This is the finding that pays for the whole exercise. When people picture slow processes they picture slow steps: a task that takes too long to do. But in almost every operational process, the time lives in the gaps between activities, not inside them. Look back at the sample log: the work took three hours, the case took nine days, and every extra day sat idle between two rows. Process mining measures those gaps precisely, because it has the timestamp on both ends. Automation makes a step faster; it does nothing for a case sitting in a queue for four days waiting for the next person to pick it up. If you do not know where the waiting is, you will automate the three-hour step and wonder why the nine days did not move.

The honest cost and prerequisites

Dedicated process mining platforms are genuinely powerful and genuinely expensive. The category leader, Celonis , is enterprise-priced and sold as a platform commitment, not a tool you buy for one process. Microsoft has folded a capable version into Power Automate, documented in the process mining overview , which lowers the entry cost if you are already on the Microsoft stack. Either way, the licence is the smaller problem.

The real prerequisite is clean timestamps. Process mining is a data project wearing an analytics costume. Before the tool produces anything trustworthy you need every relevant status change stamped at the moment it happened, a stable case identifier that survives across the CMMS and the ERP, and consistent activity names rather than free text. Most operators fail the first test. If your team closes work orders in batches, or backdates approvals, or logs "done" a week after the fact, no platform can rescue the analysis. Spend the money on timestamp discipline first and the tooling second.

The poor man's version

You do not need a six-figure platform to find your rework loops and your waiting time. Most operational systems already keep a status-history table, one row per status change, which is an event log by another name. A patient analyst with SQL and Power BI gets an operator around eighty percent of the insight for the cost of a few days of work.

Point your query at the status-history table. It usually carries columns close to these:

• wo_id → your case ID
• status_code → your activity
• changed_at → your timestamp
• changed_by → your resource
• prev_status → useful for spotting backward moves

From there, three queries do most of the work. Order the rows by wo_id then changed_at and use a window function to compute the gap between each event and the one before it (LEAD or LAG over changed_at); average that gap per pair of consecutive statuses and you have your waiting-time map, the exact between-activity delays. Count cases where status_code returns to a value it already held and you have your rework rate. Concatenate the ordered status sequence per wo_id into a single string, then GROUP BY that string and count, and you have a rough variant analysis, your happy path against your long tail. Push those three result sets into Power BI, which is exactly the muscle covered in my Business Central and Power BI guide, and you have a working process map that answers the questions that matter.

It is not as pretty as Celonis and it will not do conformance checking or predictive next-step modelling. But it will show you where the time goes, and for deciding what to fix first, that is the whole game.

When full tooling is justified

Here is the rule I use. Buy a dedicated process mining platform when three things are true at once: you have several high-volume processes to analyse, not one; your timestamp data is already clean enough to trust; and you intend to monitor those processes continuously, not run a one-off diagnostic. Continuous conformance checking against thousands of cases a day is where the platforms earn their price, and where SQL and Power BI genuinely fall short.

If instead you have one process, questionable timestamps, and a one-time question of "why is this slow", a platform purchase is consultancy theatre. It produces an impressive dashboard, a large invoice, and the same three findings you would have reached with a week of SQL. The tool did not create the insight; your event log did. Prove the value on the cheap version first. If it tells you nothing, the expensive version will tell you nothing more expensively. If it tells you plenty, you now have the business case to scale up, and you will know exactly which processes deserve it.

Whichever route you take, the sequence is the rule that matters: see the process as it truly runs, then decide what to automate. Doing it the other way round, as the majority of automation programmes still do, is how you build a fast, reliable bot for a process that should not exist in that shape at all. If you want the wider view on choosing and scoping automation, my workflow automation buyer's guide covers the decisions around this one, and my piece on automating work-order intake and triage is the natural first target once the mining has shown you where the pain actually sits.