Process mining: deciding what to automate before automating

Process mining rebuilds how a process actually runs from the records your systems already produce. Instead of asking people how they work, it observes what happened: every step, its duration and its detours. It exists so the decision about what to automate rests on evidence rather than on intuition.

Below: what it needs to start, how it differs from an interview-based survey, what it usually finds, how findings become decisions, and when it is not worth doing.

The conversation about automation almost always starts at the end: somebody proposes a candidate process and the debate moves to tooling. The problem is that the candidate is usually chosen for visibility — the one that complains loudest, the one closest to the committee — rather than for real cost.

Process mining inverts the order. Before proposing anything, it reconstructs the process as it actually happens from the trace the systems leave: what happened, in what order, how long it took and how often it had to be repeated. No workshop is required and nobody has to remember anything.

What it needs to start

Less than people assume. Three fields per event are enough: a case identifier, an activity name and a timestamp. With those the flow can be rebuilt. Most case-management, ticketing and ERP systems produce them without anybody having asked.

What does require attention is the quality of those records. If the timestamp is written when somebody closes the case rather than when the step happens, the analysis measures the moment of data entry, not the moment of work. That distinction decides whether the result is useful or decorative.

How it differs from an interview-based survey

A survey by interview produces the process the organisation believes it has. It is a legitimate source and captures intent, rules and known exceptions. But it describes the main path, because that is the one people remember.

Process mining produces the process the organisation executes, including the variants nobody documented. It is common to find the intended path explains half the cases and the rest spreads across dozens of distinct routes. That dispersion, measured, is the strongest argument available for redesigning before automating.

The two techniques complement each other: the data says what happens, the interviews say why. Running only one of them produces a familiar failure: a beautifully evidenced map of a process nobody can explain, or a well-explained process that does not match what the systems recorded.

What it usually finds

Three findings recur with a frequency that no longer surprises. The first is rework: steps executed more than once on the same case, almost always because information upstream was incomplete. They show up immediately and are usually the fastest saving.

The second is waiting. When you measure the time between activities rather than the time of activities, the diagnosis changes: the process is not slow because the work takes long, but because the case spends days waiting for somebody to pick it up.

The third is exception paths that stopped being exceptions. A route created for a rare case that today explains a large share of the volume, uncontrolled and unowned.

From finding to decision

A process map changes nothing on its own. What turns the analysis into a decision is putting a cost on each detour: how often it occurs, how much time it consumes and what that time is worth. Rework appearing in 40 % of cases sounds serious and may not be if it costs two minutes; a wait appearing in 5 % may be the most expensive thing in the process if it stalls the case for a week.

Out of that quantification come three separate lists, and it is worth not mixing them: what automates as it stands, what has to be redesigned first because automating it would entrench an error, and what is left alone because the volume does not justify touching it. The third list saves the most and never appears in a proposal.

The variant map, and why it unsettles people

The most immediate output is a picture of every distinct route cases actually took. In a process the organisation describes in six steps, it is normal to find forty or fifty variants, and the first reaction in the room is usually that the data must be wrong.

It is not. What the map shows is that the six-step description was the intended path, and that the organisation has been absorbing the difference through people who know what to do when a case does not fit. Those people are the process, and none of it is written down.

That reframes the automation question usefully. The variants are not noise to be eliminated before automating: some encode real business distinctions that deserve to stay, and others are accidents of who handled the case. Separating the two is a conversation with the team, and the map is what makes it concrete rather than theoretical.

When it is not worth doing

When the process has low volume, the answer comes from looking at twenty cases by hand. When the records carry no reliable timestamp, the analysis inherits that defect. And when everybody already knows what needs fixing and the obstacle is the decision rather than the diagnosis, measuring again only postpones the work.

It is also worth saying the other way round: in large operations, with several systems and high volume, it is the cheapest way to avoid automating something that should not have been automated.

What it cannot tell you

Worth stating plainly, because the technique is often sold as more than it is. The logs record what a system was told, not what happened around it. A case that sat for three days because the customer had not sent a document looks identical to one that sat because nobody picked it up, and the difference matters entirely.

It also sees only the systems that log. Work done in spreadsheets, over messaging or on paper is invisible, and in most administrative processes that is a meaningful share. A map that shows a clean handoff between two systems may be hiding a person who reconciles them by hand every morning.

Neither limitation makes the technique less useful; both make it incomplete on its own. The reading that holds is the map alongside a handful of conversations with the people in it, which is also considerably cheaper than trying to instrument what is currently invisible.

How it fits with the rest

The natural output is a prioritised list of candidates with measured cost, which is exactly what a process automation assessment delivers. From there come the cases that move to automation and those that need a redesign first.

The business case is calculated with local costs: an hour of manual work saved is not worth the same in Bogotá, in Mexico City, or at a European head office, and borrowing the figure from a foreign case study distorts the entire priority order.

Frequently asked questions

What data do I need for process mining?

Three fields per event: a case identifier, the activity name and a timestamp. Most case, ticketing and ERP systems already record them. What matters is that the timestamp corresponds to the work happening rather than to data entry.

Does it replace interviews with the team?

No. The data says what happens and how often; interviews say why and what rules sit behind it. A diagnostic using only one of the two sources is incomplete.

Is it useful if the process crosses several systems?

That is where it contributes most. A process contained in one system is usually understood without help; one crossing three or four is precisely the one nobody sees whole, and the one that accumulates waiting between systems.

How long does an analysis take?

Extracting and cleaning the records usually takes longer than the analysis. With available and reliable data, weeks; with data that has to be reconstructed, the reconstruction sets the timeline rather than the technique.

What does it typically find?

Rework from incomplete upstream information, waiting between activities that dominates the total elapsed time, and exception paths that quietly became a large share of the volume.

When should I not bother?

Low volume, unreliable timestamps, or when the obstacle is the decision rather than the diagnosis. Measuring again when everyone already knows the answer only postpones the work.