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.
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.
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.