Process Mining Before Automation: Two Weeks of Waiting-Time Notes Beat a Platform Licence

The artifact you need is a waiting-time log, not a process map

Before you automate a process, you need a record of where its units of work sit still. You do not need process-mining software to produce that record. One person, two weeks and four columns of notes will give you something more useful than a licensed platform, because a platform can only describe the part of the process your systems already timestamp.

Two weeks of one person writing down, for each unit of work, when it arrived, who touched it and how long it waited will contradict what everyone in the room believes about the process, and that contradiction is the entire value of doing it before you spend anything.

I have run this exercise four times, twice before a build and twice to explain why a build had already gone wrong. The second kind is more expensive, and it is what the two weeks prevent.

Why does process mining describe a different process than the one you have?

Process mining has a data requirement worth stating plainly: a case identifier, an activity name and a timestamp, one row per event. Where that log exists, mining works well. Where it does not, no licence creates it — you build it, which is a data engineering project with a timeline of its own.

The deeper problem is what a log can represent. Waiting is not an event. It is the absence of events between two timestamps, so every platform infers it, and the inference is only as complete as the instrumentation. Steps inside a transactional system get stamped. The approval living in an email thread, the call to credit control, the spreadsheet that exists because the system report is wrong — none of these produce an event. In the processes I have recorded, stamped steps accounted for a minority of elapsed calendar time; the rest sat in queues between systems, where nobody's tool is watching. A map built from logs shows you the ERP's opinion of your process, and that opinion is usually the flattering one.

A third cost hides in the business case. The licence is the visible line; extracting the log and reconciling it against what actually happens is the hidden one, done by the same people you were going to ask to document the process anyway.

What does the two-week exercise actually look like?

Choose the unit of work first, and choose it narrowly: one invoice, one claim, one order, one candidate submission. A unit that can be counted and followed is the basis of the exercise. Then follow forty consecutive instances and write down four things for each.

• The arrival timestamp, and the event that started the clock. Be precise about whose clock it is — the customer's, the system's, or the department's.
• Every handoff: who released it, who received it, and when. Names, not roles.
• Elapsed hours in each state, with a separate column for time waiting on an external party: a bank, a supplier, a customer.
• Touch minutes: time a person was actually working on the unit.

Record waiting in hours, not days. Days hide a three-hour queue and a three-day queue behind the same word, and the difference decides whether the delay is a staffing problem or a scheduling one. Use names rather than roles, because role names conceal that two of the four approvers are one person wearing two system logins.

Watch the work; do not interview about it. Asked to describe a process, people describe the official version — the one written for the auditor, with the exception handling filed off. Sit beside the desk, or in the queue view, and note what happens when a unit arrives incomplete. Forty instances is enough to see a distribution and to catch a detour that recurs in one case in five. It is not enough to size a once-a-quarter exception, and you should not pretend otherwise.

The exercise has one failure mode: it inflates into a documentation project. Keep it small enough to finish before anyone can argue with it.

What does the record usually contradict?

The disagreements are consistent in shape. These numbers come from one invoice-approval process I recorded at a mid-size distributor, using their own work items rather than interviews; the pattern repeats across the others, not the figures.

The last row matters most, because it changes the size of the prize. A process reported at 1,400 units a month is often closer to 1,100 units of genuine work plus a rework loop, and automation applied to the happy path without fixing the bounce automates the wrong half.

How do you turn the record into a decision finance will accept?

Use Little's Law, which is standard queueing theory rather than a vendor benchmark: average work in progress equals throughput multiplied by average lead time. At 1,400 units a month — about 64 per working day — and a median lead time of 5.2 working days, roughly 333 units are in flight at any moment. That explains to a COO why the team feels overloaded even after headcount was added, and it is arithmetic you can redo from your own record in a minute.

Then separate the two purchases: they come out of different budgets, and finance will fund one far more readily than both.

Touch time is labour. In the invoice process above, median touch was 14 minutes across four people, which at 1,400 units a month is about 327 hours, or just over two full-time equivalents of attention. If automation drafts the decision and a reviewer commits it in four minutes instead of fourteen, you recover roughly 230 hours a month, not 327 — the review step is now the constraint, which is why the first version should end with a person pressing a button.

Elapsed time is the customer's experience, and it is not labour. Halving the queue behind the credit check shortens the cycle by days while removing almost no touch time. It is a smaller saving on the P&L and often a larger one commercially, and the record is what lets you name which one you are buying instead of letting the vendor imply both.

The cost of the exercise is arithmetically boring, which is the point. Ten working days at six hours a day is 60 hours. At a loaded RMB 30,000 a month for an operations analyst — my own figure from Shenzhen hiring I have been part of, and one you should replace with your payroll number — that is around RMB 11,000 for the record, before any software is discussed.

Once the record exists and shows two or three candidate steps, the next decision is not technical. It is how to choose which process to automate first when the record contradicts the nomination, and it should be made against written criteria rather than against whichever stakeholder was most recently frustrated.

When is process-mining software actually the right purchase?

Often, and the conditions are specific rather than philosophical.

The two are not rivals. The handwritten record is the cheapest way to answer one question — where does this process actually lose calendar time — and a platform is the right tool for monitoring variance across many processes over years. Buying the second before doing the first is how organisations end up with an accurate map of a process that was never the constraint.

What the record cannot tell you

Four honest limits, and they should be written on the same page as the findings.

Rare paths stay hidden. Forty consecutive units will not contain the exception that arrives twice a year, and rare paths are often the expensive ones, so a low-frequency high-cost branch needs its own search through returns, complaints or credit notes.

Time is not correctness. The log measures how long units wait and how long people touch them. It says nothing about error rates, and those need a separate count — rework, returns, re-opened tickets — pulled from a different source.

Watching changes behaviour. People work differently when someone is timing them, and the effect lands mostly on touch minutes rather than waiting hours, so treat touch time as an upper bound and waiting as the more reliable figure.

One fortnight, one team, one period. A quiet fortnight is not a month-end close, and a head office is not a branch. Sample a normal period deliberately, or sample the worst one on purpose, and say which you chose.

The record is also the baseline you will be graded against

The reason to do this before spending is not diligence for its own sake. It is that a baseline has to exist before the change, and a baseline reconstructed afterwards is a negotiation rather than a measurement. When the automation is live and someone asks whether it worked, the two-week log is the only artifact that predates the vendor conversation, the build and the reorganisation, and it costs less than a licence renewal. So start small and start Monday: one unit of work, one person, forty consecutive cases, four columns. If the record turns out to confirm everything the process owner already believed, you have lost two weeks and gained a baseline. In the four times I have run it, it has never once come out that way.