Every automation project I have been involved in that ran into serious trouble had one thing in common: the organisation tried to automate a process it did not fully understand.
This sounds like an obvious mistake. And yet it is remarkably common. The logic seems reasonable at the time: we know roughly how the process works, the vendor has done this before, and we can sort out the details during implementation. What this logic misses is that the details are the process. The workarounds, the exceptions, the informal fixes your team has built up over years, these are how things actually get done. Ignore them in the design, and you will encounter them, hard, after go-live.
Process mapping, done properly, is the most valuable thing you can do before any technology implementation, automation project, or operational improvement programme. Here is how I approach it.
Start with the right question
The wrong question is: "What is the process?" The right question is: "What actually happens?"
These sound similar. They are not. Every organisation has a documented process, a procedure, a flowchart, an SOP. And then there is what actually happens, which diverges from the documented version in ways that are sometimes minor and sometimes fundamental.
I always start by asking people to walk me through what they do on a typical day, step by step, without referring to any documentation. Then I compare what they describe to what the documentation says. The gaps between the two are where the interesting information lives.
Talk to the people doing the work, not just their managers
Managers know the process as it should be. The people doing the work know the process as it is. Both perspectives are valuable. But if I had to choose one, and in practice I never do, because I always talk to both, I would start with the people doing the work.
They know which steps take longer than anyone admits. They know which approval is always given automatically, making it a pointless delay. They know which exception happens three times a week but is not in any procedure. They know who the real bottleneck is, even when the org chart suggests someone else should be.
These conversations are most productive when people feel safe being honest. I always make clear at the start that I am not looking for problems to blame on individuals, I am looking for problems in the system. The distinction matters, and people can usually tell whether you mean it.
Map the exceptions, not just the happy path
The happy path is what happens when everything goes right. It is usually well understood, often documented, and almost never where the real complexity lives.
The real process is the full path: what happens when a customer order is incomplete, when a supplier is late, when a quality check fails, when the person who normally handles an approval is on leave. These exceptions, the ones that people handle by gut feel, by calling the right person, by working around the system, are the parts of the process that will break most visibly after you implement a new tool.
When I map a process, I explicitly ask: "What can go wrong at this step? And what do you do when it does?" The answers to those questions usually reveal as much about the process as everything that came before them.
Document what you find, literally
Process mapping has a reputation for producing beautiful diagrams that nobody reads. I prefer a simpler approach. A table, sometimes. A written narrative, often. A diagram only when the visual representation genuinely adds clarity to something that cannot be conveyed in words.
Whatever format you use, the output needs to answer four questions for each step in the process: who does it, what triggers it, what they actually do, and what happens next. If you cannot answer all four questions for a step, you do not yet understand it well enough.
I also document what I call the friction points, the steps where things regularly go wrong, take longer than they should, or require judgment calls that are not documented anywhere. These are the steps that will cause the most problems if you automate without first addressing them.
"Automating a broken process makes it break faster. Fix the process first."
Use the map to make a decision, not just a document
The purpose of process mapping is not to produce a map. It is to inform a decision: should we automate this process as-is, redesign it first, or automate a different version of it?
Some processes should be automated largely as they are. They are working reasonably well, the automation will speed them up without changing their fundamental logic, and the edge cases are manageable.
Some processes should be redesigned before any automation happens. The current process has accumulated workarounds and complexity that will make any tool built on top of it fragile. Automating it now would be expensive and would produce something that needs to be redone in two years.
And some things that look like processes are not really processes at all, they are a series of individual judgement calls that vary by person, situation, and context. Trying to systematise or automate these is usually the wrong objective. Understanding them more deeply often reveals either that the judgement calls are more consistent than they appear (in which case systematisation is possible) or that the variation exists for good reasons (in which case the goal should be to support the judgement, not replace it).
When to bring in outside help
Process mapping is something your team can do. But there are two situations where an external perspective adds significant value.
The first is when the process involves multiple teams or functions that do not have a shared view of how the process actually works. An external person can gather perspectives from all sides without being perceived as taking anyone's position.
The second is when you are too close to the process to see its problems clearly. If your team has been doing something the same way for five years, the workarounds feel normal and the friction feels inevitable. Someone who is seeing the process for the first time will notice things that insiders have stopped noticing.
In both cases, the value of the external perspective is not that the outsider knows more. It is that they see differently.
If any of this resonates with a challenge you are facing, I would be happy to have a direct conversation. No commitment, no agenda.