Process mapping: how to map a process step by step

Process mapping is one of the first tools I reach for when something in a department is “not working” and nobody can say exactly where. My experience of running operations departments is that a well-made process map shows more in a few days than many weeks of discussion in meetings. On one condition: it has to show reality, not how the process looks according to the procedure. Below I describe how to map a process step by step, without special tools and without unnecessary theory.

What a process map is and when it pays off

A process map is a simple drawing that shows what happens from the moment something enters the company (an order, a complaint, an invoice, a leave request) to the moment the customer receives the result. It shows the steps, decisions, handovers between people and departments, and the places where a case simply sits.

Business process mapping pays off especially when a process runs through several departments, when turnaround time keeps growing despite a similar number of cases, when the same errors keep coming back, or when you are planning automation or a new system. In the last case the map is practically mandatory. Without it, it is easy to transfer into the system steps that should not exist at all.

Step 1: choose one process and set its boundaries

The most common mistake at the start is trying to map “all of logistics” or “all of sales”. That kind of map never gets finished. Choose the one process that gets in the way the most, and before you draw the first step, answer a few questions. What event triggers the process? How will you know the case is closed? What is the input and what is the output? Who is the customer of the process, internal or external? Who is responsible for the process? If the last question gets several names, or none, you have your first finding from the mapping.

It is worth writing the boundaries down very specifically. “Order handling” is too broad a label. “From the order arriving by email to the delivery date confirmation being sent to the customer” is a process that can be mapped in a few days.

Step 2: talk to the people who do the work

The manager knows how the process should work. The person who performs it every day knows how it really works: where you have to phone because something is missing in the system, which spreadsheet is kept on the side and why some cases come back. That is why I invite above all the people doing the work at each stage of the process to the interviews, and treat managers as one source among several, not the only one.

I hold the conversations individually or in small groups, with no line managers in the room. I ask about the latest specific case, not about the process in general: “Let's take yesterday's order. Where did it come from and what did you do first?” The story of a specific case reveals exceptions and workarounds that nobody will mention when asked about the rules.

Step 3: see the process where it happens

Interviews alone are not enough. It is worth seeing the work where it takes place, in other words going to the gemba: sitting next to the person taking orders, following a document through the office or goods through the warehouse. On site you see things nobody mentions because they have become normal: several systems open at once, data being retyped from emails, notes stuck to the monitor, a pile of cases “to be clarified”. An hour of observation often corrects what I heard in the interviews.

Step 4: record steps, decisions, handovers and waiting

I mark several kinds of element on the map. Steps, meaning activities carried out by a specific person or system. Decisions, meaning the points where the process branches. Handovers, when a case changes owner, because that is where things most often get lost. Queues, meaning the moments when nothing happens because the case is waiting in an inbox or for approval. Finally, exceptions and rework, meaning the loops in which a case goes back to an earlier stage.

The last two are the most important and the most often left out. Procedures describe the path of a case when everything is in order. The map also has to show what happens when it is not.

Step 5: measure step time and lead time

For each step I record two times: how long the work itself takes and how long the case waits before the next step. The total from input to output is the process throughput time, or lead time. In office processes the work usually makes up a small part of that time, and the rest is waiting. The proportions depend on the process, but the difference almost always surprises a team that has so far judged the process by how busy it is.

The measurement does not have to be laboratory grade. An estimate from the interviews, checked against a dozen or so real cases, for example using dates in the system or in the mailbox, is enough.

Swimlane or simple flow

A simple flow, meaning steps laid out one after another, is enough when the process takes place within one team. When it runs through several departments, a swimlane map works better: each department or role has its own lane, and the steps are placed in the lane of the person who performs them. You can see at once how many times a case jumps between departments and where it waits on those jumps.

The tool is of secondary importance. The best first maps are made on a wall with sticky notes, because anyone can walk up and move a step. Later they can be transferred to Miro, Visio or Excel. BPMN notation is useful when the map is going to be used to implement a system, but at the diagnosis stage it gets in the way more often than it helps, because the team starts discussing symbols instead of the process.

AS-IS and TO-BE: an honest picture first, then the design

The AS-IS map shows the current state as it is, including the workarounds and makeshift fixes. It is tempting to start fixing straight away and draw the “how it should be” version, but that strips the map of its value. If the team does not recognise its everyday work on the map, it will not believe in the changes that follow from it either.

Where to look for waste

On the finished AS-IS map I look for a few typical problems. Waiting: long gaps between steps, especially before approvals. Double entry: the same data retyped into two systems or into a spreadsheet. Unnecessary approvals: signatures that protect nothing, because the approver has no information to check anything against. Rework: loops in which a case comes back because something was missing at the input. I mark each such place on the map, for example with a red sticky note.

Designing the TO-BE

The TO-BE map is the process once those problems have been removed. I design it together with the people who do the work, starting with simple questions. Which step can be removed? Which can be merged with another? Where can completeness be checked at the input to avoid rework later? Who should make the decision so that the case does not wait? Only at the end do I ask what is worth automating. A good TO-BE version is realistic: it can be implemented with the current team and the current systems, perhaps with one or two changes, rather than only after replacing all the software.

The most common process mapping mistakes

Mapping the ideal instead of reality. A map copied from the procedure looks tidy and reveals nothing. If there is not a single rework loop on the map, someone has probably drawn the process from memory rather than from observation.

Too much detail. A map with hundreds of steps is unreadable and nobody will use it. At the first level a picture of the whole process is enough, and the detail is worked out only where the problem lies.

No owner. If nobody is responsible for the process, nobody will implement the TO-BE version. The map ends up in a presentation and that is where it ends.

A map in a drawer. A map that does not lead to decisions and actions has cost the team time and trust. At the next attempt people will be less willing to talk honestly about their work.

What to do after mapping the process

The map is the start of the work, not its result. After it I settle four things. First, responsibility: who performs, who approves, who is consulted and who is informed. The RACI matrix is the tool for this, and I describe it in the article on the RACI matrix. Second, metrics: two or three indicators that will show whether the process is improving, for example lead time and the percentage of cases sent back for rework. I write more about choosing them in the piece on operational KPIs. Third, quick wins that the team can introduce immediately, with no budget and no changes to the systems. Fourth, a 90-day plan for the changes that need more work, with an owner and a deadline against every action.

Quick wins matter for more than the results. They show the team that the time spent on mapping has turned into a concrete change, and they build trust ahead of the harder decisions.

Checklist

Before you consider the mapping complete, check that:

• the process has a recorded start, end, input, output and customer,
• it is clear who owns the process,
• interviews have been held with the people doing the work at every stage, not just the managers,
• the process has been seen on site, not just discussed in a meeting,
• the map shows decisions, handovers, waiting, exceptions and rework,
• the steps have work and waiting times against them, and the lead time for the whole process has been calculated,
• the AS-IS map shows reality, not the procedure,
• the places where waste occurs are marked,
• the TO-BE version was created together with the team and can be implemented,
• RACI, KPIs, quick wins and a 90-day plan have been agreed on the basis of the map.

Where to start

Choose one process, set its boundaries and arrange a few conversations with the people who perform it. That is enough to get started. If you would rather go through it with someone from outside, we can help as part of an Operational Scan: one process, up to five interviews, AS-IS and TO-BE maps, RACI and KPIs, and a 90-day plan, in no more than 10 working days. We describe the broader scope of our work on the Operations optimisation page. If you would like to look at the process yourself first, use the free AI process X-ray.