The Repository That Answers Nothing
Ask most operations leaders how many process maps their organisation holds and you will get an estimate, never a number. Hundreds, probably. Spread across Visio files, SharePoint folders, a BPM tool somebody bought three reorganisations ago, and a handful of laminated printouts still pinned to a wall in a regional office. Every one of those diagrams was drawn in good faith. None of them was drawn to connect to the next one.
That is the actual state of process documentation in most large organisations: extensive, sincere, and structurally inert. Ask a simple cross-functional question, such as which processes depend on a system that is about to be decommissioned, and the answer requires a person, not a query. Someone has to open dozens of files and trace the relationship by hand, because no relationship was ever recorded between the files in the first place.
Why Drawing More Diagrams Does Not Fix It
The instinctive response to gaps in process documentation is to commission more mapping. It rarely closes the gap it was meant to close, because the gap was never a mapping problem.
Visio and Lucidchart make it fast to draw a process. Neither makes it possible to ask a question that spans several of them. A diagram describes its own boundary and stops there by design. Add a hundred more diagrams and you have a hundred more boundaries, not a single structure that connects them. At enterprise scale, the volume of maps becomes evidence of the problem rather than a solution to it.
The other instinctive response is to buy an enterprise architecture platform. LeanIX and Ardoq are genuinely useful tools, and they model something real: the IT landscape, its applications, and the integrations between them. What they do not model is execution reality. They will not tell you who owns a process, what sequence it runs in, or which control was written to catch it when it fails. Procuring an EA tool to answer a process visibility question produces a detailed map of the wrong territory.
What an Architecture Actually Requires
An enterprise process architecture is not a bigger diagram. It is the layer that sits above the diagrams already drawn: the record of how one process connects to the next, to the systems it depends on, to the documents that describe it, and to the controls written to govern it. A process map shows one process. An architecture shows how every process relates to every other one, and lets that structure be queried rather than only viewed.
Building it does not start with a blank page. It starts by reconciling what already exists: matching process maps, RACI matrices, SOPs, and system inventories against a common set of identifiers, so the same process described in three different tools resolves to one connected entity instead of three disconnected records. From there, the reconciled processes are organised into a hierarchy, typically L0 value chains down to L3 tasks, with each level connected to the owners, systems, and controls attached to it, not just to the level above and below. The final step is governance: ownership assigned and kept current, and the model enriched with risk and control context, so the structure stays answerable rather than becoming another document that goes stale the day it is finished.
What Changes for the Organisation
Do not create hundreds of diagrams. Create a structured model of the enterprise. The distinction determines whether a change-impact question takes an afternoon of manual tracing or a single query, and whether an audit finding gets evidenced from a governed structure or reconstructed under deadline pressure from whatever documentation someone can locate in time.
The maps an organisation already holds are not wasted effort. They are the raw material an architecture is built from, not a separate exercise that competes with it. The question worth asking is not whether to map more of the organisation. It is whether the maps already drawn can answer a question that spans more than one of them, and what it would take to make sure they can.