Processes · diagnostics · implementation
How to audit
a business process
A useful audit explains not only where a deviation occurred, but why the working system reproduces it again. To do that, you need to walk the actual route, compare actions with data and translate findings into managed changes.
Anton Konnov · 9 August 2026 · 8 min read
Starting point
Define the subject before you start looking
The phrase "check the department" is almost always too broad. It is better to select a cross-functional outcome: a fulfilled order, a closed month, an approved purchase or a handled customer inquiry. That gives you a beginning, an end, an outcome owner and the opportunity to see hand-offs between functions.
Before interviews, it is useful to record the management question: what decision the audit stakeholder needs to make. This keeps the work from becoming a catalogue of complaints.
Preparation
What to gather for one route
Name one end-to-end route and gather material on that route only. Below is a starting list to adapt to the process boundaries. It is not a certification or internal-audit standard, nor an exhaustive checklist.
Question and boundaries. The management decision to be made, the event that triggers the process and what ends it, the customer of the result and who owns that result.
Current rules. The procedures, forms and templates in use now, and who actually owns each stage.
Example operations. Several real cases: ordinary ones completed on time; delayed ones or ones returned for rework; exceptions. Choose them to cover the variants that matter to the question, not to reach a number.
Event trail. What already exists in systems, email and logs: when an item was received and became complete, when clarification was requested, when it was assigned, when work started and finished; statuses, returns and their reasons; the source, version and owner of each extract.
Before comparing durations, agree what each timestamp means: "received" in one system and "registered" in another may be different events. Where evidence is missing, record the gap rather than reconstructing events from memory.
No documents are needed for a first enquiry: a description of the symptom, the route boundaries and the information available is enough.
Six steps
From fact to change plan
Boundaries and output
Define the triggering event and completion of the process, the customer of the outcome, the owner and the readiness criterion. Everything that does not affect this outcome remains outside the boundaries — for now.
Actual route
Walk several real examples through documents, systems and communications. A policy document shows the intended process; a specific order or transaction shows how work actually happens.
Roles and hand-offs
Record not only operators, but also points of wait, return, manual approval and change of ownership. It is at the interfaces between departments that deadlines and information are most often lost.
Data and metrics
Compare management reporting with primary events. It is important to distinguish between working time and wait time, a one-off deviation and a repeating pattern, and a symptom and its root cause.
Causes and target model
For material gaps, determine the mechanism: a rule, an incentive, a data shortfall, a capacity constraint or a system defect. Then describe the roles, scenarios, controls and requirements of the target process.
Priority and implementation
Separate quick organisational measures, systemic changes and hypotheses that require a pilot. Every action must have an owner, a deadline, an acceptance criterion and a way to verify the result after launch.
Working deliverables
What should remain after the audit
As-is map
Steps, roles, systems, documents, expectations and return points.
Cause register
Facts, frequency, consequences and links to the management question.
To-be model
Target route, ownership, data, controls and automation requirements.
Implementation plan
Priorities, owners, pilots, acceptance criteria and monitoring.
Example
From a delay to a testable cause
A hypothetical example, not a real client case. In purchase request approval, delayed requests are often seen to be returned for clarification. A single such case does not prove the cause, let alone show that an employee was negligent.
Observation. Delayed requests are returned for clarification, but it is not yet known what actually sets them apart from ordinary ones.
What to compare. Selected delayed and ordinary requests: the completeness and version of each request on submission, timestamps, hand-offs between roles and exceptions.
Hypothesis. Intake requirements, or ownership at the point of hand-off, are unclear. Alternatives remain open: queueing and capacity limits, or system faults.
What would confirm or refute it. If returns trace back to the same missing information and waiting builds up after a hand-off with no owner, the hypothesis gains support. If ordinary requests are just as incomplete, or delays arise in a queue or from system faults, this hypothesis alone is insufficient: alternatives and combinations of causes need to be checked.
What the audit records. The finding, its source, the degree of uncertainty and the owner of the next step.
The next decision stays bounded. If the comparison supports the hypothesis, clearer intake requirements and a named owner for clarifications can be tested on part of the flow, comparing turnaround, returns and output quality against the baseline under comparable workload. If it does not, the next hypothesis is tested, and systems are not changed on a guess.
Common mistake
Automating before diagnosing
An ERP, CRM or a new report will not fix unclear ownership and contradictory rules. If you transplant a historical process into a system first, the organisation will get the same losses — only faster and more expensive.
Technology requirements should be defined only after the target scenario, the required data and the success criteria are clear.
Walk through the process
Let's start with one problematic route
We will define the boundaries, participants, available data and the format of an initial diagnostic.