Process Mapping: As-Is vs To-Be, Step by Step (Full Example)
Process mapping is two maps, not one: how the work really happens today (as-is) and how it will work after the change (to-be). In this video I map a made-up online shop's returns process, find the 5 pain points that make it slow, apply 5 moves to fix them, and draw the to-be in BPMN, with the 5 mistakes to avoid.
Step by step
Process mapping is two maps, not one
- Process mapping means 2 maps. The as-is shows how work really happens today, mess included. The to-be shows how it will work after the change. The gap between them is your project. The example here is a made-up online shop with slow returns and angry customers.
Explain like I'm 5: the map app
- Think of a map app. It needs where you are now and where you want to go. The blue dot is the as-is, the pin is the to-be, and the route between them is the list of changes. Teams that skip the blue dot get a route that makes no sense.
Process modelling and process analysis (BABOK)
- The BABOK Guide has 2 techniques for this. Process modelling draws the events, activities, flow, decisions and roles, for the current or future state. Process analysis studies the model for gaps, root causes and options for change. This example uses BPMN, a standard notation for process maps.
Before you map: scope, people, evidence
- Prepare 3 things. Scope: one process, from the customer asking to return something to the refund. People: those who do the work, not just their manager. Evidence: real return emails, the spreadsheet and last month's times. Try sticky notes first, then draw it properly.
The vague request
- The request is vague: returns take forever, fix it. So check last month's numbers first. On average, a customer waits 16 days from return email to refund, and 1 in 5 returns ends with a complaint. Now you can measure it, but you still don't know why it's slow.
The as-is map, shape by shape
- Map it in 1 pool with 3 lanes: customer service, warehouse, finance. An email starts it, the agent checks the order and copies it to a spreadsheet, the parcel arrives, the warehouse inspects it. Gateway: item okay? Yes, finance waits for Friday's run and pays. No, it goes on hold.
Pain points 1-3: typing twice, hand-offs, waiting
- Walk the map again and mark the pain points. 1: typing twice, because the agent copies each return from an email into a spreadsheet. 2: hand-offs, because the warehouse tells finance by email and emails get missed. 3: waiting, because finance only pays refunds on Fridays.
Pain points 4-5: no owner, silence
- 4: a decision nobody owns, because damaged items sit on hold between the warehouse and customer service. 5: silence, because 0 steps tell the customer anything. Add numbers: copying takes about 5 minutes a return, the Friday wait adds up to 6 days, and damaged items sit for over a week.
Move 1: remove what adds nothing
- Move 1: remove steps that add nothing. For each task, ask who uses what it makes. Only finance reads the spreadsheet, to know what to refund. If the shop system keeps a return record, the copy step can go. Ask what breaks if you stop doing it tomorrow, not whether it can be removed.
Move 2: let the system do it
- Move 2: let the system do the boring part. The customer fills in a short website form: order, item and reason. The system creates the return record and emails the label straight away. The data is typed once, and agents can spend their time on the tricky cases.
Move 3: ask why before you change
- Move 3: ask why before you change anything. Finance pays on Fridays because refunds go in one batch, because each bank transfer once cost a fee. The bank stopped charging that fee 2 years ago, but nobody asked. The fix: pay each refund the same day the warehouse marks the item okay.
Move 4: give every decision an owner
- Move 4: give every decision an owner. The warehouse lead now decides on damaged items within 2 days: repair, swap or refuse the return. The customer hears the result. On the map, this is one task in one lane. When a question bounces between 2 lanes, ask who decides.
Move 5: keep the customer in the loop
- Move 5: keep the customer in the loop. Automatic messages send the return label, confirm the refund is paid, or explain the decision on a damaged item. Each one answers a question the customer would otherwise email about, so customer service gets fewer where-is-my-refund emails.
Worked example: the to-be map
- Same pool, new lanes: website, warehouse, finance. The form starts it, a service task creates the return and label, and a send task emails the label. The warehouse inspects the parcel. If okay, the system pays the refund that day. If not, the warehouse lead decides and the customer is told.
Build it in bpmn.io
- In bpmn.io, name the start event return form sent and use the wrench to make it a message start event. Add a task, create return and label, and make it a service task (gear). Add email label to customer and make it a send task (black envelope). Build the rest the same way.
As-is vs to-be: measure and confirm
- Compare the maps. As-is: a spreadsheet, a Friday wait, 2 email hand-offs and a dead end. To-be: one form, same-day refunds and an owner for every decision. The target is refunds in 5 days, not 16, and half the complaints. Play it back to the team, write up requirements and keep both maps on Confluence.
5 common mistakes
- 5 common mistakes: skipping the as-is, mapping what the manager thinks happens instead of the real work, adding too much detail, mapping only the happy path, and changing the drawing but not the work.
Recap
- To recap, prepare the scope, people and evidence, then map today honestly. Look for typing twice, hand-offs, waiting, decisions nobody owns and silence. Then remove, automate, ask why, give each decision an owner and keep the customer informed. Measure before and after, and play it back.
Common mistakes
- Skipping the as-is. Drawing the ideal process straight away can mean fixing problems nobody has and missing the real ones. Map today's process first, mess included.
- Mapping the manager's version. Managers may describe how they think the work happens. Watch the work, or map it with the people who do it.
- Mapping only the happy path. Include what happens when things go wrong. In this example, the dead end was hiding in the damaged item path.
- Putting too much detail on one map. If the map needs a magnifying glass to read, split it into smaller maps.
When a business analyst uses this
When a stakeholder says a process is too slow, a business analyst can run a workshop with the people who do the work and map the as-is using real data. Each gap between the as-is and the agreed to-be can then be written up as a requirement for sign-off.
Questions people ask
What is process mapping in business analysis?
It is drawing how a process works today and how it will work after a change, then studying the gaps. The BABOK Guide covers this through 2 techniques: process modelling and process analysis.
Why is process mapping important?
It shows where work really gets stuck, such as repeated typing, missed hand-offs and long waits. That helps you fix the real causes and compare the process before and after the change.
What symbols are used in process mapping?
It depends on the notation. In BPMN, circles are events, round-cornered boxes are tasks and diamonds are gateways, which often show decisions. Pools and lanes show who does the work.
