Table of Contents

“Process audit” is a vague phrase, so it’s worth saying exactly what I mean by it. Otherwise everyone pictures something different, and one of us ends up disappointed.

Week one: trace, do not survey

The first week is spent following individual units of work end to end. One patient from booking through to payment posted. One order from placement through to delivery and any subsequent return. One candidate from application through to their ninety-day mark.

Not a sample. Not an average. Individual cases, traced through every system and every person that touches them.

This is deliberately inefficient-looking. The reason for it is that aggregate reporting is structurally bad at showing where processes break between teams. Each department’s summary can look acceptable while the transfers between them are failing. A trace makes the transfers visible because you are physically following the work across them.

Typically five to ten traces. By the third or fourth, the same friction points start recurring, which is the signal that the sample is adequate.

Week one, in parallel: ask what people work around

Every process that is failing somewhere has an informal correction sitting next to it. A spreadsheet somebody maintains privately. A standing call that exists to catch what the system misses. One long-tenured person everyone routes exceptions through.

These workarounds are the most efficient available map of where the process breaks. They were built by people who felt the failure directly and had to solve it with no budget. Finding them is largely a matter of asking, in a way that clearly is not looking for someone to blame, what people do when the normal path does not work.

Week two: reconcile the numbers

Before analyzing any reported gap, confirm the gap is real. Get the actual formula behind each metric (numerator, denominator, window, exclusions) from each group producing it. Recompute on a single definition. See how much of the difference survives.

Some portion of variance regularly turns out to be definitional. That is worth knowing before anyone builds a plan to close a gap that is partly an artefact.

What comes out of it

A written finding with, at minimum:

• The traced process as it actually runs, which is usually not the documented process
• Where work stops moving, with the cost of each stall quantified where the data supports it and marked as unquantified where it does not
• Which problems are inside a department and which are between departments, because the fixes are different
• What I would do first, and roughly what it would cost
• What I could not determine, and what would be needed to determine it

That last item matters. An audit that reports total confidence across the board has usually not looked hard enough.

What it is not

It is not a benchmarking exercise against industry averages. Those are available, cheap, and mostly not actionable at the level of a specific operation.

It is not a software recommendation. Sometimes the answer involves new tooling, but arriving at that conclusion in week two is a sign the audit was skipped rather than performed.