Process mining: the real map, not the one quality drew

Process mining starts from an uncomfortable idea: the process written in the quality manual and the process that actually happens every day are not the same thing. The first one has six tidy steps. The second has those six, plus four shortcuts someone invented in 2019, two loops back to the previous step, an email to a supplier that appears in no diagram, and a parallel spreadsheet maintained by one person who has been with the company for eight years. When an organisation tries to automate without seeing that second version, it automates a fiction.

That is what process mining solves: reconstructing the real flow from the traces the work itself leaves in your systems. Every time someone creates an order in the ERP, approves it, edits it or closes it, a record is written with an identifier, an activity and a timestamp. With enough records you can draw the process exactly as it happens, variants, waits and loops included.

This guide covers what data you actually need, what this technique finds that an interview never will, what it costs to set up and — most importantly for a mid-sized company — when it isn't worth it and you are better off spending a morning watching how the team really works.

What is process mining and how is it different from a flowchart?

A flowchart is a statement of intent: somebody sat down, asked around and drew how the process should work. Process mining is a forensic reconstruction: it starts from the data that was recorded and shows what actually happened, in what order, and how long each hop took.

The raw material is an event log. It is a table with three minimum columns:

| Column | What it holds | Example | |---|---|---| | Case ID | What identifies one complete run of the process | Order no., case no., invoice no. | | Activity | The step that was executed | "Order created", "Approved by purchasing", "Received at warehouse" | | Timestamp | When that step happened | 2026-03-14 09:41 |

That is enough to draw a process. If you also have a fourth column with the resource (who or which system executed the step) plus some business dimension (amount, customer, site, product type), the analysis goes from interesting to actionable: it stops being "there are delays" and becomes "the delays concentrate in orders above €5,000 at the Valencia site".

The three questions the technique answers, in this order:

• Discovery. What does the real process look like, with all its variants?
• Conformance. Where does reality diverge from the written procedure or the contract?
• Enhancement. Where is the lost time, the rework and the bottleneck that costs most?

What does it find that an interview doesn't?

Interviews are essential for understanding the why, but they have three well-known blind spots. People describe the happy path, forget the shortcuts they have already normalised, and are never good at estimating durations. Process mining is strongest precisely there.

The number of variants. This is the figure that surprises everyone in the first results meeting. A purchasing process with one path in the manual typically shows between 40 and several hundred distinct variants in the data. Not all of them matter: usually a handful of variants covers most cases and the rest is a very long tail of exceptions. That tail is exactly what breaks an automation designed only for the happy path.

Invisible rework. Loops of the "approved → sent back for review → approved" kind. Nobody reports it as a problem because each round trip costs ten minutes; in aggregate it can be the department's single largest consumer of time.

Waiting versus working. This distinction changes conversations. A case can have an eleven-day cycle time of which two hours are actual work. If management believes the problem is a slow team, the data reframes the discussion: the problem is that the case spends nine days waiting for a signature.

Control breaches. Orders reaching goods-in without having passed approval, discounts applied above the authorised limit, steps executed by the same user who was supposed to supervise them. This is conformance analysis, and it is usually the finding internal audit cares most about.

If the project ends with a beautiful map and no decision taken, it failed. The useful deliverable is not the diagram: it is the short list of what changes, who changes it, and how it will show up in the metric.

What data do you need and where does it come from?

This is 80% of the real effort in a project, and it is worth saying before anything gets signed. Extracting the event log is classic data engineering, not magic.

Where it comes from. Modern ERPs and CRMs keep history or audit tables that work almost directly. In older systems you have to reconstruct events from date fields scattered across the main table: `created_date`, `approved_date`, `shipped_date`. It works, but with a limitation you have to accept: if a field gets overwritten, the history is lost and the loops back become invisible.

The problems that always appear. Worth anticipating, because they are what pushes the calendar:

• Uneven granularity. One system logs "Order modified", another details which field changed. You have to pick a common level and group.
• Timestamps with a date but no time. If you only have the day, the ordering of steps within the same day is ambiguous. Sometimes that's fine; for analysing short waits, it isn't.
• The case isn't unique. One order splits into three delivery notes and two invoices. You have to decide the unit of analysis before extracting anything, and that is a business decision, not a technical one.
• Work that happens outside the system. If supplier negotiation runs on email and phone, the log shows a four-day gap with no explanation.
• Personal data. The log records who did what and when — that is employee data. It carries GDPR and employment-relations implications best resolved up front, not when someone from the works council asks.

On volume: you don't need the entire history. For a first analysis, six to twelve months of closed cases is usually enough, as long as it includes both peak and low season. More data doesn't improve the diagnosis, it only makes extraction more expensive.

How do you run the first analysis, step by step?

A well-scoped first case takes six to eight weeks. If someone offers a twelve-month plan to "roll out process mining across the company", they are selling a licence, not a diagnosis.

| Phase | What happens | Rough duration | |---|---|---| | 1. Pick the process | One only, high volume, acknowledged pain, and a system that logs events | 1 week | | 2. Define case and activities | What counts as one run and how steps are named; agreed with the business | 1 week | | 3. Extract and clean | Source queries, name harmonisation, handling incomplete cases | 2-3 weeks | | 4. Analyse | Variants, waiting times, rework, conformance | 1-2 weeks | | 5. Decide and measure | Short list of changes, owner and control metric | 1 week |

Two criteria for picking the process in phase 1. First, volume: with 300 cases a year there is no statistics worth the name, and a conversation solves it better. Second, somebody has to hurt with it today; without acknowledged pain the findings never turn into decisions. Typical candidates in a mid-sized company are purchase-to-pay, order-to-cash, customer onboarding, claims or incident handling, and returns.

And one criterion for phase 5 that separates a report from a project: every finding must leave the room with an owner and a metric. "Cut approval waiting time on orders under €1,000 by removing the double sign-off, owner purchasing, measured by monthly average approval time" is actionable. "Optimise the approval flow" is not.

What is it for before you automate?

This is the application with the clearest return and the reason the technique shows up in any process automation conversation.

The failure pattern is well known: an automation tool gets bought, the happy path gets built, and once in production it turns out the happy path covers 55% of cases. The remaining 45% goes to an exception queue handled by the same team as before, and the savings evaporate. It is the same story anyone tells who has watched an RPA bot break three months in.

Process mining gives you three things before a line of code is written:

• The real coverage your automation will have. If the top three variants are 78% of cases, that is the honest ceiling of the project, and that number is what you use to decide whether it pays.
• Where the time actually is. Sometimes the slowest step is not the one you were about to automate. Automating a two-minute step inside a process with a six-day wait changes nothing.
• Which exceptions to design for from day one, instead of discovering them in production.

It is also useful afterwards: if the event log stays alive, you can compare the process before and after the change and check whether the improvement really happened. That connects directly with measuring ROI without back-of-the-napkin estimates.

When is it not worth it?

Saying so saves money, so here is the full list. There are four situations where the analysis doesn't hold up.

Low volume. Processes with a few dozen cases a month. The pattern is clearer from a conversation with the two people who run them.

The process leaves no trace. If half the work happens in email, on the phone and in local spreadsheets, the event log will have so many gaps that the map misleads more than it clarifies. The correct sequence here is the reverse: first move the process into a system, then mine it.

You already know what the problem is. If everyone in the company points at the same bottleneck and the fix is obvious, spending two months proving it with data is a luxury. Fix it and measure afterwards, if at all.

Nobody has the authority to change the process. This is the most common reason projects get abandoned and it has nothing to do with the technique. An analysis without a sponsor ends up as a shared PDF nobody opens — the same fate as data catalogues without an owner.

On tools: there are specialised commercial platforms, modules inside BI suites, and open libraries. For a first diagnosis, an open library on top of the extracted event log answers 90% of the questions and lets you decide with evidence whether the annual licence pays off. Doing it the other way round — buying the licence and then looking for a process to justify it — is how the projects that get dropped in year two usually start.

Frequently asked questions

What's the difference between process mining and task mining?

Process mining reconstructs the flow from the records left by business systems: ERP, CRM, case management. Task mining observes what the user does on their own machine, click by click, to capture detail the system never logs. The second gives more detail, but it means monitoring workstations and requires a prior conversation with the team and with employee representatives.

How much does a first process mining project cost?

The bulk of the cost is not the tool, it is extracting and cleaning the event log. A first diagnosis on one scoped process sits in the range of a six-to-eight-week data project. If the ERP already keeps usable audit tables it drops considerably; if events have to be reconstructed from legacy systems it climbs.

Do I need a commercial platform to start?

Not for the first analysis. With the event log extracted and an open library you can answer the discovery and timing questions. A commercial platform pays off when the analysis becomes continuous, with several live processes and business users querying on their own.

Is this a way of monitoring employees?

That is not its purpose, and framing it that way is the fastest route to a blocked project. The analysis is about the process, not about people: the healthy practice is to aggregate by role or team rather than by user, document the purpose, inform staff, and restrict access to individual-level detail.

If you have a process everyone knows is slow but nobody can point to where, process mining is how you stop arguing from intuition. In the audit we start by looking at what your systems actually record, because that determines whether the analysis is viable or whether the data needs tidying first; and if you'd rather talk it through, let's talk for half an hour and we'll tell you whether your case holds up to this approach or is better solved with something cheaper.