What flowcharts can’t do, but BPMN can
How simplified, compact process maps make consensus easy – but control impossible.
A few years ago, at the start of a process documentation engagement, we received a dump of the client’s previous process work. It was substantial – somebody had clearly put time into it. It included a full mapping of the company’s sales processes, built during a half-day workshop with senior sales leaders the year before.
One of these mapped processes, “Manage Sales Teams,” was described in exactly three tasks:
“Review activities of the sales representatives (ongoing, on demand).”
“Prepare and conduct sales team meeting to review activities.”
“Define actions (including owner, deadline, etc).”
It was not wrong. A person managing a sales team does, at some point, review what the reps are doing, talk about it in a meeting, and derive actions from the conversation. The diagram captured these things.
But it captured nothing else.
No target setting, no training, no task coordination, no strategy development, no account distribution, no regional segmentation, no performance criteria. The highly complex work of organizing dozens of teams of regional sales representatives across a whole continent, with different portfolios, different maturity levels, and different degrees of needing to be managed, had, in all seriousness, been reduced to: look at what they do, talk about it, decide what to do next.
Absurd.
The diagram described the process the way you might describe getting across a city: head north, turn east, walk until you’re there. Technically not wrong. But try actually getting from A to B with it.
When we began engaging with the sales leaders to map their actual work, all the stuff beyond those three banal steps, the response was almost uniform: “We already did this in that workshop last year. Now you want to do it again, but slower? No. Just make this executable in our CRM, and we’ll do the rest.”
This reaction was honest, and common.
The sales leaders were not being difficult. From their perspective, the process had been documented: They had participated in a workshop with a well-known firm, they had agreed on a diagram, and the diagram had been signed off on. Anyone now asking them to do it again was, at best, overeager.
What they did not yet see was that the agreement they had reached in that half-day workshop was an agreement at altitude, far away from operative terrain. At thirty thousand feet, “manage sales teams” looks like three activities, and nobody disagrees – because there is nothing specific enough to disagree about.
But the moment you descend to where the work actually happens, the agreement evaporates.
With this team, it evaporated fast. Minutes into their first mapping session with us, it became clear that almost every sales leader had their own sales team management practice, most of them fundamentally different from each other. On top of that, about three quarters of them were unaware that the organization actually had a detailed set of sales team management criteria, built during a long forgotten MBB engagement, designed specifically for ongoing sales steering. These had been delivered a few years ago and then quietly ignored, because they had never trickled down to the level at which the actual work happens. Because they, too, were too general.
Our mapping sessions with these sales leaders were long and contentious. We are now, some years later, on good terms with them, they now get what we had to do. But in the early weeks, we were seen as manufacturing unnecessary work and ignoring the obvious fact that “this had already been done.”
It had not been done. What had been done was the easy part.
There is a pattern here: the higher the abstraction level of a process diagram, the easier it is to reach agreement, and the less that agreement is worth. A diagram with three activities can be signed off on in an afternoon, because there is nothing in it to push back on. The abstract diagram did not resolve the hard questions, but simply hid them in generalizations before anyone could notice them.
I have written elsewhere about “truce documentation”: the maps that emerge from workshops where a team, through exhaustion, or conflict aversion, or facilitator passivity, documents not the process as it runs but the process as it can be agreed on without an argument. The three-activity sales map is a close relative, but the mistake that was made is slightly different: Truce documentation happens when the room avoids the conversation. What happened here is that the room had the conversation at the wrong altitude, and then mistook the map for the territory.
These two failures are siblings:
One is social: the team avoids the contentious points.
The other is structural: the abstraction removes the contentious points before anyone has to face them.
Both produce diagrams that look finished, but are not.
There is a cybernetics principle (“Ashby’s law”) that applies here: a controlling system needs to be capable of having more possible states than the system it controls. If your map of a process has three activities, you are equipped to steer three activities. If the actual process has thirty, but your map still has three, the actual process escapes your control. The instructions did not fail – they were never built for the territory. The simplified map gave a confident, incorrect account of what the job requires.
This is the real cost of abstraction in process documentation:
Not inaccuracy. But misplaced confidence.
The false feeling you’re aware of every factor.
I’m not advocating to always map a process down to the task level. It is crucial, instead, to match the resolution of a process map to the needs of the audience it is made for. From our experience, there’s at least four different audiences for process diagrams, each demanding something the previous one did not. Most diagrams we encounter are built for the first, and frustrate everyone by being useless for the next three.
The first audience is a meeting: a set of people who need a shared picture to have a productive conversation. Here, reducing sales leadership to a Deming Cycle is not only acceptable, it may simply be the only viable approach. A whiteboard sketch or a PowerPoint slide serves this audience fine. The trouble starts when the rough picture is mistaken for a complete one. The three-activity sales map worked for the half-day workshop. It could not work for anything that came after.
The second audience is the team that has to take responsibility for the process. This is where the gap between an illustrative flowchart and a formalized process diagram becomes most clear. A flowchart is a photograph of a key. A formalized notation is the actual key. One can be studied and understood, the other actually opens a door. An experienced team might read the simplified diagram and mentally fill in the blanks, the parts it omits, but this only works out as long as every reader fills in the same things (they never do).
At this level, the diagram has to take positions, and the positions are specific. In BPMN, there are at least four kinds of forks in a workflow: an exclusive choice, a parallel join, an inclusive gateway, an event-based split. Each has different consequences for who waits, who proceeds, and who is accountable when something goes wrong. This audience, the people structuring and doing everyday operative work, needs all of these details. A high-level flowchart cannot provide them.
The third audience isn’t people, but the system that the process will run on. BPMN 2.0 is not the most popular process notation because it is a good drawing format, but because it is an XML standard: underneath the graphical representation of a process is structured, machine-readable and executable code that a piece of software can read as a sequence of instructions and act on directly. It can instruct a CRM or workflow engine what to do. The sales leader I mentioned, the one who said “just make this executable in our CRM”? He was asking for exactly this, and did not know the three-activity diagram could not get there. A task named “review activities” means nothing to a piece of software; it needs to know what is reviewed, by whom, against which criteria, in what sequence, and with what exceptions.
The fourth audience arrived recently and nobody was planning for it: the AI agent. The same structural precision that makes a BPMN file executable by an ERP also makes it legible to a large language model. An agent can read the XML, understand the underlying process’ structure, autonomously identify which steps are candidates for automation, and ask sensible questions about handoffs. This turns boring, precise, sometimes resented process notation into AI gold; you’ll never forget the first time you input a core process XML into an LLM and see it reinvigorate a corporate unit. Structured process documentation is what autonomous systems thrive on: business objects with states, owners, verbs, history, and permissions, instead of long-winded narratives with loose ends.
Most organizations have all of their processes in first-audience flowcharts, so they can talk about them in meetings. They haven’t yet experienced maps that can feed the next three: how consultancy projects improve when the flow of tasks is transparent, how systems implementation speeds up when the mapping is done in machine readable form, and how AI tools turn from brilliant strangers to trusted colleagues when they know, precisely, how work works.