Insights / Guide / Process diagnostics and business process evaluation
GuideHow to map a process in a day
Process mapping does not need weeks. A focused one-day session with the people who do the work can reveal most of the issues and produce a practical improvement list.
Process mapping has a reputation for being slow. Consultants interview dozens of people, draw detailed diagrams in specialist software and present a thick report weeks later. By then, the people who took part have forgotten what they said, and the energy for change has faded.
Process mapping does not need weeks. A focused session with the right people can reveal most of the issues in a single day. The map will not be perfect, but it will be accurate enough to show where time is lost, where errors arise and where people are frustrated. That is usually all that is needed to decide what to fix first.
This guide sets out how to prepare, how to run the day and what to do afterwards. It works for most operational and administrative processes, such as order to cash, procure to pay, customer onboarding, claims handling or employee joining.
Before the day
A day of mapping depends on a few hours of preparation. Skip it and the session will spend its first half arguing about scope.
- Define the process boundaries: what event starts it and what event ends it. For order to cash, it might start when a customer places an order and end when payment is received and matched.
- Agree the purpose: are you trying to reduce cycle time, cut errors, lower cost or improve customer experience? The purpose shapes which pain points matter most.
- Choose two or three real recent cases to follow, ideally one straightforward and one that went wrong.
- Gather any simple data available: volumes, typical cycle times, error or complaint counts.
- Book a room with a long wall, plenty of sticky notes and markers in at least three colours.
Appoint a facilitator who does not own the process. Their job is to keep the group moving, ask naive questions and make sure every voice is heard. A process owner facilitating their own process tends to defend it.
Gather the people who do the work
Include those at each step, not just their managers. They know the workarounds.
Managers can describe how a process is supposed to work. The people who do the work know how it actually works: the spreadsheet kept on the side, the colleague phoned when the system is wrong, the step skipped because nobody checks it. Without them, the map shows the official process, and the real problems stay hidden.
- Invite one person from each team that touches the process, chosen for their hands-on knowledge.
- Include someone who deals with the customer, internal or external, at the end of the process.
- Keep the group to around eight to twelve people, enough to cover the steps but small enough to work together.
- Invite the process owner or sponsor to open the day and return at the end, but not necessarily to stay throughout, since their presence can inhibit candour.
Set the tone early
Open the session by saying clearly that the aim is to improve the process, not to judge individuals. People will only describe workarounds and mistakes if they are confident that doing so will not be held against them.
Walk the flow end to end
Follow a real case from trigger to completion, noting handoffs, waits and rework.
Spend the morning building the map on the wall. Start with the trigger at one end and the outcome at the other. Then take the first real case and walk it through step by step, asking the person responsible for each step to describe what they do, what they need to start, and where the work goes next.
- Write each step on a sticky note in the same colour, using a verb and a noun, such as “check credit limit” or “raise invoice”.
- Arrange the steps in swim lanes, one row per team or role, so handoffs between teams become visible.
- Mark each handoff with an arrow, and note how the work is passed: email, system, phone, paper.
- Note the waits between steps, using the real case as a guide, and the approximate time each step takes.
- Mark loops where work goes back for correction or missing information.
After the first case, walk the second and third through the same map. Where they follow different paths, add the variations. The case that went wrong is especially useful, because it shows where the process breaks under pressure.
Consider a typical customer onboarding process at a business services firm. The map might show that a new customer’s details are entered three times in three systems by three teams, that the credit check waits in a shared inbox for up to four days, and that a quarter of new accounts go back to sales for missing information. None of this appears in the process document. All of it emerges within an hour of walking a real case.
Mark the pain points
Colour the steps that cause delay, error or frustration. These become your improvement list.
After lunch, give everyone sticky notes or dots in three colours, one each for delay, error and frustration. Ask them to mark the steps where they see each problem. Encourage people to mark steps outside their own area too, since downstream teams often feel the effects of upstream problems most.
Clusters of colour show where to focus. Then, for each cluster, ask the group three questions: what causes this, how often does it happen, and what does it cost in time, money or customer goodwill? Write the answers next to the cluster. Resist the urge to jump to solutions at this stage. Understanding the cause properly makes the solutions better.
- Delays often cluster at handoffs, approvals and shared inboxes.
- Errors often cluster where data is re-keyed or where information arrives incomplete.
- Frustration often clusters where people chase others for information or work around a system.
Prioritise and agree next steps
In the last part of the day, list the pain points and sort them by impact and ease of fixing. A simple two-by-two grid works well. Quick wins, high in impact and easy to fix, can often be done within weeks. Larger improvements need more analysis and investment, and may become projects.
Be honest about what the group can fix itself and what needs others. Some improvements, such as changing a template or agreeing a cut-off time between two teams, are within the room’s control. Others, such as a system change or a policy decision, need a sponsor’s support. Separate the two lists so that quick, local fixes are not held up waiting for larger decisions.
Before the group leaves, agree owners and dates for the top three to five improvements. Bring the process sponsor back to hear the findings and confirm support. Ending the day with clear commitments is what turns a workshop into change.
We had talked about the onboarding delays for a year. In one day, the people who did the work showed us exactly where the time went, and three fixes were live within a month.
Operations director, business services client
After the day
Photograph the wall before anything is taken down, and turn the map into a simple digital version within a few days. Share it with the participants and ask them to correct anything that is wrong. Keep the format simple: the aim is a shared picture, not a technical diagram.
Then track the agreed improvements. Meet briefly every two weeks with the owners to check progress. After a month or two, measure the same things you gathered before the day, such as cycle time and error rates, and share the results with everyone who took part. Seeing their input lead to visible change is the best way to secure their help next time.
Source: Intelliversal analysis.
