How to run a business process audit

Start with the actual work

Trace one completed case from request to acceptance, including queues and corrections.

Choose a process with a clear start and finish

Pick a recurring outcome that matters to a customer or another team. For example, follow an accepted customer order until delivery is scheduled and confirmed. Define what starts the process, what completion means and which cases are included. Without those boundaries, a process audit can expand into an unmanageable review of the whole company.

Choose a recently completed case with records you can inspect. Record its type and circumstances so you do not silently treat an unusually easy or difficult case as normal performance. Later, compare several cases and include an exception.

Reconstruct the handoffs from evidence

For each step, record when work arrived, when somebody started it, when it left and what the receiving person needed. Separate active work from waiting. Use the actual request, handover message, system entry or acceptance record rather than relying only on a recollection of how the process should work.

Ask both sides of a handoff what ready means. Sales may regard an order as complete when the customer agrees; scheduling may still need an address, specification and delivery constraint. That mismatch is a candidate cause to investigate, not evidence that either team is careless.

Separate the symptom from the operating constraint

A queue shows where work waits. It does not establish why. Check missing inputs, approval requirements, conflicting priorities, capacity and corrections. Record repeated returns to the previous step, including the reason and the information needed to progress.

Consider whether a proposed improvement moves the delay elsewhere. Faster sales acceptance may increase an already constrained scheduling queue. Give one accountable person responsibility for the end-to-end outcome and agree which part of the flow they have authority to change.

Test one bounded improvement

Choose a change that addresses the observed cause: a clearer acceptance checklist, an agreed exception route or a capacity decision. State the owner, the cases it applies to and a review point before changing the process. Preserve required controls and specialist approvals.

Compare suitable cases before and after, including waiting, correction effort and outcome quality. A written process map is a deliverable; reduced waiting without additional errors is an operating result that needs evidence. The free Business Process Audit can help organise the questions, but its self-reported result is not an independent assurance opinion.

What the example does not establish

A single case is a starting point, not a representative performance baseline.

Look for a case that challenges your first explanation as well as one that supports it. Agree which part of the situation is observed, which is an assumption and which needs another person’s evidence. Keep any proposed change within the authority and commitments already in place.

How do you know whether a change helped?

Record the starting condition and a suitable review point before the change. Compare real cases with similar constraints, including exceptions and any extra work created elsewhere. Separate a prepared document, an implemented change and a tested operating result. If the evidence is incomplete, name the gap rather than treating it as success.