Every operating model engagement I've worked on begins with a process map, usually already in existence, showing how work is intended to flow through the organisation. In my experience, these maps are reliably optimistic — describing the process as designed, not as it actually operates day to day.
The gap between the two becomes visible the moment you ask a specific question a process map can't answer: for this specific decision, who actually had to say yes before it happened? Process maps describe activity. They rarely capture the informal approval that genuinely determines whether something moves forward — the person whose sign-off isn't in any documented workflow but whose disapproval would quietly stop the process anyway.
Decision maps, built by tracing specific real decisions rather than documenting intended workflow, surface this gap directly. They frequently reveal that the actual approval chain is shorter, longer, or entirely different from what the process map describes — and that difference is exactly where operating model redesign needs to focus.
I've seen redesigns that carefully rebuilt a process map without ever building the corresponding decision map, and the results consistently disappoint: the new process looks cleaner, and the same informal approval bottleneck that existed before persists, quietly, underneath the new documentation.
Any operating model diagnostic that starts and ends with process mapping is diagnosing the visible layer of the problem and missing the layer that actually determines whether work moves quickly or slowly through the organisation. Decision maps are more uncomfortable to build, because they surface informal power that nobody wants named explicitly — and they're the map that actually matters.