Process Mining vs Asking People: What Event Logs Never Show You

Process mining is the practice of reconstructing how work moves through a business by reading the timestamps its software leaves behind, and the most useful process mining alternative is far older and far cheaper: asking the people who do the work how they actually do it.

Both are trying to answer the same question. Where does the time go, and why does this take eleven days when it should take two. They just disagree about where the evidence lives. Process mining says the evidence is in the systems. The other approach says the evidence is in people's heads, and that the systems only ever recorded the part somebody remembered to click.

Neither is wrong. But they fail in completely different places, and if you pick the wrong one for the shape of your business you will spend a lot of money confirming things you already knew.

What process mining is genuinely good at

Start with the case in its favour, because it is a real one.

If a process runs inside a single system, and every meaningful step in it creates a record, process mining will show you that process with a precision no interview can match. It will tell you the median duration of each transition. It will show you the variants, the eleven different paths a purchase order took through what your documentation insists is one path. It will find the rework loops, the cases that go back a step and then forward again, sometimes four times.

That last one matters. Rework is the single most expensive thing hiding in most operations and it is almost invisible from the inside, because to the person doing it, it is just Tuesday. Logs surface it immediately.

Process mining is also unarguable. Nobody defends their process against a timestamp. When you are trying to move a large organisation and there is politics in the room, evidence that came out of the system rather than out of a colleague's mouth is worth a great deal.

So if you are a bank, or a manufacturer, or anyone with a properly instrumented ERP that the work genuinely lives inside, mine it. This post is not for you.

What event logs never show you

Here is the problem. A log is a record of what a system was told. It is not a record of what happened.

Consider the gap. A salesperson marks a deal as Closed Won on the twelfth. The customer verbally agreed on the fourth. In between, someone chased legal twice, rebuilt the quote because the original had the wrong discount structure, and got the finance director to approve an exception over the phone. The log holds one event, on the twelfth. Eight days of real work left no trace at all.

That is not a bad CRM. That is what every CRM does, because software records state changes, and most work is not a state change.

Four things logs are structurally incapable of showing you:

The work that happens between systems. The spreadsheet on somebody's desktop that reconciles two tools that do not talk to each other. It is often the most important step in the process and it exists nowhere except one laptop.

Why. Logs give you sequence, never reason. You can see that a lot of onboarding cases skip step three. You cannot see that step three has been broken since a supplier changed their portal and everyone quietly agreed to work around it.

Waiting. The gap between two timestamps could be a queue, a holiday, a person who needed to think, or an email nobody replied to for six days. Those need completely different fixes and the log renders them identically.

Anything in a small business. This is the big one. Process mining needs volume. It is a statistical technique, and with thirty cases a month there is nothing to be statistical about. Most companies under a hundred people also run their work across a dozen tools plus email plus a lot of judgment, so there is no single log to mine even if you had the volume.

The process mining alternative that scales down

Asking people works precisely where mining fails. It needs no volume, no instrumentation, and no single system of record. It captures reasons, workarounds and waiting, because those are the things people actually talk about when you let them.

It has one obvious weakness, and you should hold onto it: people describe the idealised version. Ask how invoicing works and you will get the version from the induction pack. This is not dishonesty. It is how memory works, and it is why badly run interviews produce process documents that match the SOP and match nothing else.

The fix is in the question. Do not ask how something works. Ask them to walk you through the last time they did it, naming the specific instance, and then follow every hesitation. "And then I just…" is where the value is. The moment someone shortens a sentence is the moment they are skipping the workaround, and the workaround is the process.

The second weakness is cost. Interviewing thirty people properly is a week of somebody's life, plus the transcription, plus the synthesis, and that is before anyone argues about what the answers meant. This is exactly the cost that made discovery a consultant's job. It is also the part that has changed: abi. FDE runs those interviews with AI, by voice or by text, and builds the model from what people say, which removes the reason most small companies never did this at all.

What to do if you are under a hundred people

Ask. It is not a close call.

You do not have the case volume to mine, your work is spread across too many tools to have one log worth mining, and the expensive problems in a business that size are nearly always the ones that live in a person rather than a system. Single points of failure. Undocumented workarounds. Two teams doing the same thing in different tools because nobody ever compared notes.

None of those appear in a log. All of them come up in the first twenty minutes of an honest conversation.

The interesting variant is when two people describe the same process differently. That disagreement is more useful than either description. It usually means the process forked at some point and nobody noticed, and it is the fastest route to a real problem you can fix this month.

Where the honest answer is "both"

If you are large enough to mine, mine first, then interview the exceptions.

The logs will point you at the variants that look wrong: the cases taking three times the median, the paths that only appear in one region. Take that list into conversations with the people running those cases. The mining tells you where to look, the interview tells you why, and neither of them gets there alone.

The failure mode to avoid is spending six figures on mining a process that ten minutes of asking would have explained. It happens, and it usually happens because mining feels rigorous and asking feels soft. That instinct is backwards. A precise measurement of the wrong thing is not rigour.

Start with whichever method can see the work. For most companies, that is still a conversation.