What is process mining, and what does it actually tell you?

Process mining reconstructs how a process actually runs by reading the timestamps your systems already record. Rather than asking people how work flows, it derives the flow from evidence — every case, every step, in the order it really happened.

What it produces is usually uncomfortable. The real process has more paths than anybody described, a significant share of cases take a route nobody designed, and the delays are in places other than where everybody assumed.

What we'll cover

• What it needs to work
• What it produces
• The variant explosion
• Conformance, and what deviation means
• Where the time actually goes
• The limits worth stating
• Turning a finding into a change
• Who appears in the data
• Getting the event log with CodeWords
• What to get right first
• Frequently asked questions

What it needs to work

Three columns, and if you have them you can begin.

A case identifier, tying events to a single instance — an order, a claim, a ticket.

An activity name, saying what happened.

A timestamp, saying when.

Anything else is optional and useful: who performed it, which system, which department, the value of the case.

The data usually already exists, scattered across the systems that touch the process — the CRM, the ticketing tool, the ERP, the approval system. Assembling it is most of the work.

The quality problems are predictable: clocks that disagree between systems, activities recorded at different granularity, cases that start in one system and are identified differently in another. Reconciling identifiers across systems is the single largest task.

What it produces

A discovered process model, derived from the log rather than drawn by anybody, showing the paths cases actually take.

Frequencies per path, so you can see that eleven per cent of cases take a route nobody had described.

Durations per step and between steps, which is the part that usually surprises.

Rework loops, where cases go backwards — returned, corrected, resubmitted — which are invisible in most process descriptions and are frequently the largest consumer of time.

Bottlenecks, identified by where cases queue rather than by where anybody believes the problem is.

A comparison against the intended model, which is conformance checking and is covered below.

The variant explosion

The first result almost everybody gets, and the thing that makes or breaks the exercise.

A "simple" process typically has hundreds of distinct paths. Every ordering difference, every optional step, every rework loop produces another variant.

A discovered model showing all of them is unreadable, which is why the first output is usually abandoned as noise.

Most variants are rare. A small number of paths cover the majority of cases, and the long tail is individually negligible.

Filter to the common paths first — the handful covering most cases — and look at the tail separately and deliberately.

The tail is not all noise. Rare variants include the genuinely exceptional cases and the ones where something went wrong, so it is worth examining even when it is not worth modelling.

Variation itself is a finding. A process with three hundred variants is a process without an agreed way of working, which is a more important discovery than any individual path.

Conformance, and what deviation means

Conformance checking compares the log against the intended model, showing where reality departs from design.

Deviation is not automatically a problem. A skipped step might be a shortcut that works, a control being bypassed, or a documented step that was never necessary.

Find out which before acting. Automating the documented process would eliminate a shortcut people rely on; enforcing it might reintroduce a delay somebody removed deliberately.

Undocumented steps are equally informative. Somebody added a check, a spreadsheet, or a second approval, usually to compensate for a real problem the design does not acknowledge.

Ask the people, having seen the data. The combination is much stronger than either alone: the log says what happens and the people say why.

Where the time actually goes

The finding that most consistently changes what teams do.

Waiting dominates. The sum of the steps is usually a small fraction of the end-to-end duration, and the rest is work sitting between them.

Handoffs are where cases queue, typically in somebody's inbox, with no visibility and no ageing.

Report time in step and time between steps separately. They are different problems — one is capacity or complexity, the other is attention — and a combined figure hides which you have.

Look at the distribution, not the mean. The median case and the worst decile behave differently, and the worst decile is what generates complaints.

Rework multiplies duration. A case that goes backwards once often takes several times as long as one that does not, and the rework rate is therefore a higher-leverage target than the step durations.

The limits worth stating

Being honest about these makes the results more credible rather than less.

It only sees what is logged. Work happening in email, in conversation, or in a spreadsheet is invisible, and that can be a large share of the process.

Timestamps record when the system was updated, not when the work happened. Somebody doing the work on Tuesday and recording it on Thursday appears as a two-day step.

It describes, it does not explain. The log shows that cases queue at approval; it does not say whether that is because approvers are busy, the request is unclear, or the policy is ambiguous.

Granularity is whatever the systems record. If a system logs one event for a sequence of five actions, those five are one step to the analysis.

It is a snapshot of the past. A process that changed three months ago is described by a year of log as though both versions were one process.

Turning a finding into a change

The part where most process mining exercises stop, having produced an interesting document.

Pick one finding, usually the largest queue or the highest rework rate, rather than trying to address the whole model.

Establish the baseline from the same log, so the before figure is derived the same way as the after figure will be.

Change one thing — a handoff notification, a clarified form, a routing rule — and measure the same metric again.

Automating the handoff is frequently the whole answer, since telling the next person immediately removes the queue without automating any of the actual work.

Re-run the analysis quarterly. Processes drift back, and a one-off exercise has a shelf life of a few months.

Who appears in the data

Event logs record who did what and when, which makes this an analysis with a people dimension whether or not anybody intended one.

Performer is an optional column and a consequential one. Including it enables useful analysis and creates an obvious temptation.

Analyse roles, not individuals. Where cases queue by role tells you about capacity; a ranking of people by case duration tells you who handles the hard cases.

Duration is confounded by difficulty. The person with the longest average handling time is frequently the one every difficult case gets routed to, and a naive reading penalises exactly the person you least want to lose.

Say what the analysis is for, in advance. A process study that turns into performance monitoring poisons cooperation for every subsequent one.

Check your obligations. In several jurisdictions, analysing employee activity data carries consultation and transparency requirements, and that is a question for whoever advises you rather than for the analyst.

Aggregate by default and drop to individual level only with a specific reason and a stated purpose.

Getting the event log with CodeWords

Assembling the event log from several systems is the bulk of the effort, and it is connective work rather than analysis. CodeWords connects to more than 3,000 integrations.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which systems hold events, how cases are identified in each, and where the combined log should land.
3. Describe the exceptions: a case identifier that does not match between systems, an event with no timestamp, a system that is unavailable.
4. Connect each source once and reuse the connections.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What to get right first

The case identifier, consistent across every system that touches the process. Everything else follows from being able to say that this event and that event belong to the same instance, and where identifiers differ between systems, reconciling them is the largest single piece of work.

Two habits make the difference. Filter to the common variants before showing anybody the model, since the full discovered model looks like noise and the exercise gets abandoned at that point. And report time between steps separately from time in steps, because the gap is usually the larger number and it is the one nobody measures.

Frequently asked questions

What data do I need to start?

A case identifier, an activity name, and a timestamp, per event. Most organisations already have all three scattered across their systems; assembling them and reconciling the case identifiers is the bulk of the work.

Why does the discovered model look like chaos?

Because a real process has hundreds of variants and the first output shows all of them. Filter to the paths covering most cases, and examine the long tail separately — the tail is informative but unmodellable.

Is a deviation from the documented process a problem?

Not necessarily. It might be a shortcut that works, a control being bypassed, or a step that was never needed. Find out which before acting, because automating the documented version could remove a workaround people depend on.

What does process mining usually reveal?

That most of the elapsed time is waiting between steps rather than doing them, and that rework loops nobody documented consume more time than anybody expected. Both are consistently surprising and both are actionable.

What can it not tell me?

Why. It describes what happened, not the reason, and it cannot see work that happens in email, conversation, or a spreadsheet. Pair the data with conversations rather than treating it as a complete picture.

Do timestamps reflect when work happened?

They reflect when a system was updated, which is not the same thing. Somebody doing the work on Tuesday and recording it on Thursday appears as a two-day step, so unusually long steps are worth checking before acting on.

How often should the analysis be repeated?

Quarterly, at least. Processes drift back towards their old shape, and a one-off analysis is a document with a shelf life of a few months rather than an ongoing capability.

Should the analysis include who performed each step?

It enables useful capacity analysis and it needs care. Analyse by role rather than by individual, since duration is confounded by difficulty — the person with the longest handling time is usually the one every hard case is routed to.

Are there obligations around analysing employee activity data?

In several jurisdictions, yes, including transparency and consultation requirements. It is worth raising with whoever advises you before the analysis rather than after, and saying in advance what the study is for.

Related reading

• Business process automation
• Data lineage
• Hyperautomation