Business process mapping: how to map a process before you automate it

What business process mapping actually produces

A useful map is not a flowchart of the ideal process. It is a record of the real one, including the workarounds nobody admits to in a meeting: the spreadsheet on someone's desktop, the WhatsApp group that confirms deliveries, the second system that only Karen can log into.

Each step on the map should carry four things:

• Trigger - what starts it. An email arriving, a form submitted, a weekly meeting.
• Owner - the role, not the person. Roles survive resignations.
• Output - what exists at the end that did not exist before.
• Wait - how long the work sits idle before the next step picks it up.

That last one is where the money is. Most business processes are mostly waiting, and waiting is invisible until you write it down.

The six steps

1. 01Pick one process and define its edges. Start where the trigger arrives and stop at a clean handover. "Order intake, from enquiry to confirmed works order" is a process. "Sales" is not.
2. 02Interview the people doing the work, separately. Two people doing the same job will describe two different processes. Both descriptions are true and the difference is the finding.
3. 03Draw the current state as it is, warts included. Boxes for steps, arrows for handovers, a note wherever information changes system.
4. 04Add times. Touch time (how long the work takes) and wait time (how long it sits). Estimates from the people doing it are fine; you are looking for orders of magnitude, not precision.
5. 05Mark the failure points. Where does work go back a step? Where does someone re-type something? Where does a customer chase?
6. 06Only then draw the future state - and mark which changes need software and which just need a decision.

A worked example: order intake

Here is a mapped order-intake process from a distributor's point of view - the current state, with times attached. The pattern repeats across almost every business we see.

Touch time across the whole process is under an hour. Elapsed time is four to five days. Nobody in that business is slow - the process is mostly waiting, and two of the waits are policy, not capability.

Automating the quote document would save twenty minutes. Moving the credit check to run automatically on order creation saves a day. The map is what makes that obvious, and it is why we insist on it before quoting any business process automation work.

Which notation should you use?

For most businesses: boxes and arrows on a whiteboard, photographed. Formal notation matters when the map has to be handed to someone who was not in the room, or when it becomes a specification.

Swimlanes are the sweet spot for most B2B businesses, because the delays almost always happen at the boundary between two lanes rather than inside one.

How do you know the map is finished?

When you can hand it to someone from another department and they can tell you, correctly, what happens to an order that arrives at 4:30pm on a Friday. If the map cannot answer edge cases, it is a diagram of the happy path and the software built from it will be too.

Two more tests. Every arrow has a named owner on both ends. Every system named on the map has a named source of truth for each field it holds - that second one is where integration work gets scoped, and where most double-entry hides.

Common mistakes

• Mapping the process you wish you had. Useful for training, useless for buying software.
• Mapping everything at once. Three well-mapped processes beat thirty sketched ones.
• Leaving out the exceptions. The exception is often 30% of volume, and it is always what breaks a new system in month two.
• Treating the map as the deliverable. It is an input to a decision, not a document to file.
• Doing it without the people who do the work. They will find the workaround you designed out, and they will be right to.

When mapping tells you not to build anything

Sometimes the map shows a standard process with standard steps and no unusual constraints. That business should buy a product, configure it well, and spend the money it saved on training. We would rather tell you that on the first call than nine months into a build.

Bespoke software earns its keep where the map shows something a product cannot represent: a quoting rule specific to your industry, a compliance record with a legal retention requirement, a scheduling constraint that comes from your plant rather than a textbook. If your map is unremarkable, buy. If it is not, see what a bespoke build involves.

If you work to a formal quality system, the process map is also the natural home for the documented information ISO 9001 expects you to keep about how work is planned and controlled - which means the effort is not wasted either way.