Week 20: The Process Map Nobody Wants to Draw — And Why It Changes Everything
The Process Map Nobody Wants to Draw — And Why It Changes Everything
I'm going to describe a scene you've probably lived through. If you've ever been part of a process mapping exercise, you'll recognise it instantly.
A cross-functional team is in a room. Whiteboard on the wall. Sticky notes in hand. Someone has drawn a rough "start" box on the left and an "end" box on the right. The task is simple: map the current process. As it actually is. Not as it should be. Not as the procedure says. As it actually happens, step by step, from trigger to completion.
The first fifteen minutes go smoothly. The opening steps are usually clear. Something arrives — an order, a request, a signal — and someone does something with it. The sticky notes go up. People nod. This is the easy part.
Then it gets interesting.
Around step five or six, someone says, "Well, that depends." Depends on what? Depends on the product type. Depends on the customer. Depends on whether Sarah is working that shift. Depends on whether the system is running slowly that day.
The process map, which was a neat linear flow three minutes ago, starts branching. Decision diamonds appear. Exception paths multiply. Someone draws a loop back to step three with a sticky note that says "rework." Someone else adds a path that goes to a completely different department that nobody in the room had thought to invite.
And then the moment I wait for. The moment that makes the entire exercise worthwhile.
Someone stares at the wall, reads through the sticky notes, and says: "Wait — are we really doing that?"
That sentence. Right there. That's when improvement begins.
I've facilitated process mapping sessions in more than forty organisations over twenty years. At Shell, at Johnson Controls, at KCA Deutag, at consulting clients across energy, manufacturing, finance, and government. And that moment — the moment of collective recognition that the process contains steps nobody can justify — happens every single time.
Not sometimes. Every time.
It happens because processes accumulate waste the way houses accumulate clutter. Slowly, invisibly, one step at a time. A workaround that was temporary in 2014 becomes permanent by 2016. A sign-off that was added after an audit finding in 2018 stays long after the auditor has moved on. A handoff between departments exists because two systems couldn't talk to each other eight years ago, but now they can, and nobody noticed.
The waste is hiding in plain sight. Everyone walks past it every day. And nobody sees it because nobody ever draws the full picture.
Let me tell you about the process mapping exercise that taught me more than any other.
This was at Shell. A finance operation. Part of a larger deployment that eventually touched twelve thousand FTEs. We were mapping the procure-to-pay process across a shared services centre. Not a manufacturing process. Not a production line. A finance process — purchase orders, invoicing, payment processing.
The team in the room included finance analysts, procurement specialists, a system administrator, two team leaders, and the operations manager. Eight people. All of whom worked in or around this process every day.
I asked them to map the current state. As-is. No aspirations. No improvements. Just: what actually happens when a purchase order enters the system and eventually becomes a payment?
It took three sessions. Each session was three hours. Nine hours to map a single process.
Not because the process was complicated by design. Because the process had become complicated through accumulation.
When we finished, the map covered an entire wall. One hundred and forty-seven steps. One hundred and forty-seven individual activities between "purchase order created" and "payment processed."
The room was silent when we stepped back and looked at it.
One hundred and forty-seven steps.
Here's what we found.
Twenty-three of those steps were manual data transfers — someone copying information from one system into another because the systems weren't integrated. This was a well-funded operation with modern ERP infrastructure, but the process had developed workarounds from the pre-integration era that nobody had removed.
Seventeen steps were approval and sign-off loops. Multiple levels of approval for transactions that, when we analysed them, were below the threshold that required any approval at all. The approvals had been added over the years in response to specific incidents, but the policy thresholds had changed, and nobody had updated the process.
Eleven steps were rework loops — points where errors were caught and sent back for correction. When we traced the root causes of the errors, most of them originated in the manual data transfers. The process was creating errors in step twelve and catching them in step thirty-one, nineteen steps later. The entire rework loop existed because of waste created earlier in the same process.
And then there was my favourite discovery. Step eighty-nine. A printed report that was generated every Wednesday, placed in a physical folder, and delivered to an office on the third floor. The team lead who generated the report had been doing it for six years. Every Wednesday. Without fail.
I asked who received the report.
Nobody knew.
We traced it. The office on the third floor belonged to a manager who had left the company two years earlier. The folder was being delivered to an empty desk. Every Wednesday. For two years.
When I told the team, one of the analysts laughed. Then she stopped laughing and said: "What else are we doing that nobody needs?"
That's the question. That's always the question.
The reason process mapping is so powerful — and the reason most organisations resist it — is that it makes the invisible visible. And the invisible is almost always embarrassing.
Nobody wants to discover that they've been generating a report for an empty desk. Nobody wants to admit that a process they own has forty steps that add no value. Nobody wants to stand in front of a wall of sticky notes and confront the fact that years of "we've always done it this way" has produced a system that is grotesquely wasteful.
But that discomfort is the point. The discomfort is where improvement lives.
I have never — not once in twenty years — facilitated a current-state process mapping exercise that did not reveal significant waste. Not incremental waste. Significant waste. Steps that could be eliminated entirely. Handoffs that existed for no reason. Approvals that served no purpose. Rework loops that existed because the process itself created the errors it was trying to catch.
The average process, when mapped honestly, contains thirty to fifty percent non-value-adding activity. At Shell, across the broader finance transformation, the number was closer to forty percent. Four out of ten steps in the process existed to serve the process, not the customer.
Here's why teams resist this exercise.
First, it takes time. Real process mapping — not the simplified version that fits on one slide — takes hours. Sometimes days. For a complex cross-functional process, you need multiple sessions with multiple teams. In organisations where everyone is already overwhelmed, carving out that time feels impossible.
Second, it requires honesty. Process mapping only works if people describe what actually happens, not what the procedure manual says should happen. And in most organisations, the gap between the two is significant and uncomfortable. Admitting that you've been working around a broken step for three years, or that an approval loop everyone hates is actually your responsibility, requires a level of psychological safety that many teams don't have.
Third, it creates accountability. Once you've drawn the process and identified the waste, someone has to do something about it. And that means someone has to change something. Which means someone has to admit that the current way — their way, in many cases — isn't good enough.
I've had people tell me to my face that they don't want to map the process because they already know it's broken and they don't want to be the one who has to fix it.
At least they were honest.
But here's the other side of that equation.
Every major improvement I've been part of started with a process map. Every one. The billion dollars in documented savings at Shell didn't come from theory. It came from teams standing in front of walls of sticky notes, finding the waste, and eliminating it.
At Johnson Controls, we mapped the complaint resolution process in one EMEA region and found that the average customer complaint passed through eleven people before someone actually resolved it. Eleven. The customer didn't need eleven people. They needed one person with the authority to act. We redesigned the process. Complaint resolution time dropped by sixty percent.
At KCA Deutag, we mapped the rig mobilisation process — the sequence of activities required to prepare a drilling rig for a new contract. The team initially told me the process had about thirty steps. When we mapped it honestly, it had ninety-two. A third of them were waiting steps — waiting for approvals, waiting for information, waiting for equipment that hadn't been ordered because someone was waiting for an approval.
In every case, the map was the breakthrough. Not because mapping is magic. But because mapping forces an entire team to look at the same picture at the same time and collectively confront what they've been living with.
There's a specific technique I use that makes this exercise more effective.
I don't let the team map the process from a conference room. I make them walk it. Physically follow the work as it flows through the organisation. Stand at each workstation. Watch each handoff. Time each step. Talk to the person doing it.
At Shell, during the finance process mapping, I took the team out of the meeting room and walked them through the actual flow. They followed a purchase order from intake to payment. They stood at each desk. They watched each data entry. They timed each approval loop.
It took an entire day. And it changed the team's understanding more profoundly than any slide deck or training session ever could.
Because when you're standing next to someone who is manually copying data from one screen to another — tab, click, type, tab, click, type — for the fortieth time that morning, you don't need a consultant to tell you that's waste. You can see it. You can feel it. And you can't unsee it.
The process map nobody wants to draw is the current state. The one that shows how things actually are, not how they should be.
And it changes everything because it creates a shared understanding of reality. Not one person's perspective. Not the manager's version. Not the procedure manual's version. The collective, honest, uncomfortable reality of how work actually flows through the organisation.
Once you have that, improvement becomes obvious. Not easy, but obvious. You can see the waste. You can see the rework. You can see the steps nobody can explain. And you can start removing them.
Without it, you're improving a process you don't understand. And that's not improvement. That's guessing.
So here's my question: when was the last time your team drew the process as it actually is? Not as it should be. Not as the procedure says. As it actually happens, every day, step by step.
If you haven't done it recently, you're working blind. And the waste you can't see is costing you more than you think.
If you want the professional templates to run current-state mapping, value stream analysis, and process improvement workshops the right way, the CI Mastery Toolkit has twenty-five ready-to-use templates that cover exactly this. Find it at stormholt.org/products/ci-mastery-toolkit.
New to Stormholt? Start here — it locates your stage in minutes.
Building capability? Stage III — Skill — the tools, the courses, the simulations.