Business process mapping
Business process mapping turns a process into a model that can be tested. It records the inputs, decision points, controls, dependencies, outputs and verification steps that determine how the work is produced. The useful version is built bottom-up from evidence the organisation already holds, usually timesheets and operational data, rather than from workshops alone. The result is a map whose every step can be assessed, and whose findings can be argued in commercial terms.
What is business process mapping?
A process map is not a drawing of what people say they do. It is a model of how the work is actually produced: what enters the process, what is decided within it, which controls apply, what the process depends on, what leaves it, and how the output is verified.
The test is whether the model can be interrogated. Given a map, you should be able to ask where a delay accumulates, which step a control actually sits on, and what would happen downstream if a step were removed. A map that cannot answer those questions is a picture, not a model.
Why start with timesheets and operational data?
Workshops record intent. Timesheets record effort. Operational data records the artefacts that effort produced. Taken together across projects and over time, they connect tasks to processes and to the measures the business already reports against.
That connection matters more than resolution. A finding expressed as hours against a chargeable code will be recognised by the people who have to act on it. A finding expressed only as a swimlane will not.
The data rarely arrives clean. Part of the mapping work is reconciling what the timesheet says against what the operational record shows, and the disagreements between the two are often the first findings.
What has to be in the map for it to be testable?
- the inputs, and where each one comes from;
- the decision points, and who holds each one;
- the controls, and the step each control sits on;
- the dependencies, on systems and on people;
- the outputs, and who consumes them; and
- the verification steps, and what each one would catch.
Anything that cannot be located on that list is not yet mapped. That includes the steps performed outside the system of record, which are common, and which are usually where the rework sits.
Why map the whole rather than run a pilot?
A review of one process finds what is wrong with that process. A review of the whole finds the overlaps: the same data, the same controls and the same decision points recurring across functions, where one piece of work resolves several objectives at no additional cost.
Those crossovers are invisible from inside a single process, and they are usually where the largest gains are. A pilot chosen for convenience tends to optimise a stretch of work that a wider map would have retired. Mapping is therefore hierarchical and holistic: the whole first, at a coarse resolution, then depth where the map shows that depth is worth buying.
How detailed should a map be?
Deeper than the process owner expects, and shallower than a systems analyst would like. Resolution is bought where the map suggests something is hiding: a step with a wide spread in the time it takes, a control with no evidence of ever having fired, a handover between two functions that neither of them describes the same way.
Everywhere else, coarse is sufficient. A uniformly detailed map of an entire operation takes longer to produce than the findings are worth, and it ages badly. The point of the map is not completeness. It is to be accurate at the places where a decision will be taken.
What happens once the map exists?
Every step is assessed against the strategy and the deliverables, and marked retire, automate, assist or person. Retire is considered first, because a step that comes out does not need to be built. More often than not, the gain is in fewer steps rather than in new software.
The assessed map becomes the diagnostic, and the diagnostic becomes a roadmap prioritised by commercial value, feasibility, data readiness, governance requirements and delivery complexity.
Common questions
-
What is process mapping?
Recording how a piece of work is actually produced, in a form that can be tested: the inputs, decision points, controls, dependencies, outputs and verification steps. Process mapping and business process mapping describe the same activity. The second phrase simply names the setting.
-
What is the difference between a flowchart and a process map?
A flowchart shows sequence and branching. A process map adds the inputs, controls, dependencies, outputs and verification that let you test what would happen if a step changed. A flowchart is a picture of a process. A map is a model of it.
-
What is L1, L2 and L3 process mapping?
A convention for depth. Level 1 names the process at the level of a business function, level 2 breaks it into sub-processes, and level 3 into the individual steps a person or a system performs. The convention is useful for agreeing scope. It is not an instruction to take everything to level 3, which usually costs more than the findings are worth.
-
What is an example of process mapping?
A periodic reporting cycle, mapped from the point at which data arrives to the point at which a person signs: which systems it passes through, where it is re-keyed, which checks apply, which exceptions are chased, and who consumes the output. Each of those is recorded as a step with its inputs, its controls and its verification.
-
What are the seven steps of the business process?
There is no universal set of seven. Frameworks number the stages differently, and the number is a presentational choice rather than a finding. What matters is that every step in your process is identified from evidence and given an explicit assessment, however many that turns out to be.
-
What data do we need before mapping can start?
Timesheets and operational data across projects over time, at sufficient resolution to understand the tasks, the processes and their context. Perfect data is not required. Incomplete data is itself a finding, and it is recorded as one.
-
How long does business process mapping take?
It is done inside a Discovery, which typically runs for three to six months, and closer to three where strong operational data already exists. Mapping is the first part of that work, not the whole of it.
-
What if the map disagrees with how the process is documented?
That is a common and useful result. The documented process is a control artefact. The mapped process is what the evidence shows. The gap between them is reported, because it usually indicates either a control that is not operating or a step that has quietly been retired already.