Process Mapping: How to Map Work as It Really Happens

To map a business process as it really happens, follow one real piece of work from the moment it arrives to the moment it is finished. Talk to every person who touches it, watch them do it, and write down each hand-off, wait, workaround, and piece of rework you find. The SOP tells you what the process is supposed to be. The map should tell you what it is. The rest of this process mapping guide covers how to do that well.

The gap between the SOP and the map is the point of as-is process mapping. Every business has steps nobody documented, documented steps nobody follows, and a spreadsheet somewhere that holds the whole thing together. A map drawn from the procedure manual will miss all three, and those are usually where the time goes.

Why the SOP is the wrong starting point for process mapping

Standard operating procedures are written once, by someone who knew how the process was meant to run at the time. Then the business changes. A new system arrives, a key person leaves, a customer complains and a check gets added. The people doing the work adapt. The document does not.

Read the SOP before you start, because it tells you what management thinks happens. Then put it away. If you interview people with the SOP on the table, they will describe the SOP back to you, partly out of politeness and partly because admitting to a workaround feels like admitting to breaking a rule.

Start with one process and fix its edges

Pick a single process and decide exactly where it starts and where it ends. "Sales" is not a process. "From a customer accepting a quotation to the invoice being sent" is. Without fixed edges the map keeps growing until it covers the whole company and explains nothing.

Name the trigger (what event starts the work) and the outcome (what "done" looks like to the customer or the next team). If two people disagree about either, write both down. That disagreement is often your first finding.

Who to interview

Talk to the people who do the work, not only the people who manage it. Managers know the intent of a process. The people doing it know the reality. You want both, but the second group is the one most maps leave out.

• Everyone who touches the work at each step. Not one representative per department. Two people in the same role often do the same job differently, and that difference matters.
• The person who fixes the mistakes. Every process has someone downstream who catches errors and quietly corrects them. They know where the process breaks better than anyone.
• The person who receives the output. Ask the next team what arrives incomplete, late, or in the wrong format.
• Whoever covers during leave. They had to learn the process from scratch, so they know which parts only exist in one person's head.
• A recent joiner. They have not yet stopped noticing the odd parts.

How to run the conversations

Ask about the last real case, not the general case. "Walk me through the last order you handled" gets a far more honest answer than "how do you handle orders?" The general question produces the ideal version. The specific one produces the version with the quick check with accounts in the middle of it.

Where you can, sit with the person while they do the work. Ask them to share their screen or show you the register. People skip steps when they describe a task because those steps have become automatic. They do not skip them when they perform it.

Then ask what happens when it goes wrong. What do you do when the information is missing? Who do you ask? What happens if that person is away? The exception paths are usually where most of the effort sits, and they never appear in the SOP.

Make it clear early that the map is about the process, not about individual performance. If people suspect the exercise will be used to judge them or cut jobs, you will get a tidy, sanitised version and the map will be useless.

What to capture at each step

For every step, record:

• Who does it, by role and by name.
• What triggers it and what the person needs before they can start.
• Which system, form, file, or paper register is used.
• What decision, if any, is made, and on what basis.
• What is produced and who it goes to next.
• How long the work takes, and separately, how long the item waits before anyone picks it up.
• Any workaround: a private spreadsheet, a WhatsApp group, a note on a desk.

The split between work time and wait time is the most useful thing you will collect. Do not rely on people's estimates for it. If your systems record when an item was created, approved, or updated, pull those timestamps for a sample of real cases. Memory is a poor guide to how long something sat in a queue.

Where the delays hide

Delays rarely sit inside a step. They sit between steps. Look closely at these places:

• Hand-offs. Every time work moves to another person or team, it waits in someone's queue. Count the hand-offs. A process with many of them is slow even when every individual is quick.
• Approvals. An approval that takes a minute to give can take days to obtain if the approver is busy or travelling. Ask when each approval was introduced and whether anyone has ever said no.
• Batching. Work that is collected and processed once a day or once a week waits for the batch, whether or not anyone decided it should.
• Missing information. Work that arrives incomplete gets sent back. Each loop adds a full round of waiting.
• Re-keying. The same data typed from one system into another, often by someone whose real job is something else.
• One person. A step that only one person can do becomes a queue whenever they are busy, sick, or on leave.

Drawing the map

Keep the format simple. A swimlane process map, with one horizontal lane per role and the steps flowing left to right, is enough for almost every business process. Sticky notes on a wall work well for the first draft because people will move them and argue about them, which is what you want.

Mark wait time between steps as clearly as the steps themselves. Flag every rework loop, every re-keying point, and every workaround in a different colour. A clean, attractive map that hides those is worse than an ugly one that shows them.

Check the map against reality

Before you use the map, test it. Walk the people you interviewed through it and ask what is missing. Then take a handful of real, completed cases and trace each one through the map step by step. If a case took a route the map does not show, the map is wrong. Fix it before anyone makes decisions from it.

How to use the map

The map is a diagnosis, not a plan. The temptation is to take it straight to a software vendor and ask them to automate it. That turns every redundant step and every pointless approval into code, where it becomes harder to remove.

Instead, go through the map step by step and ask:

• What would break if this step disappeared?
• Is this step here to catch an error that an earlier step created?
• Could this decision be made earlier, or by the person already holding the work?
• Could this approval become a rule, such as a spending threshold?
• Where is the same information entered twice?

Fix the design first. Then decide what to automate, starting with the steps that are frequent, rule-based, and stable. Our guide on what to automate first covers how to choose.

Keep the original map. It is your baseline. Six months after the change, you will want to show what the process looked like before, and nobody will remember accurately.

Yoddha Lab carries out process audit and mapping, and redesigns business processes, as part of its business process reengineering work in Kathmandu, Nepal, from the first interviews through workflow automation and systems integration. See our business process reengineering service or talk to our team about the process that is slowing you down.