Guide · Foundational
A Process Map Is Not Organisational Truth
A process map can be clear, agreed and still wrong about how work happens.
Treat the map as a set of testable claims, not a certificate of truth.
A useful representation has limits
A diagram makes relationships easier to discuss. It selects boundaries, compresses detail and gives names to activities. Those are strengths, but they are also limits. An arrow between two teams can conceal waiting, rejection, informal approval and several different transfer mechanisms. A tidy visual does not establish which of those happens in a real case.
The question is not whether to use process maps. It is how to stop the representation acquiring more authority than its evidence supports. The map should help people investigate work, not become a reason to dismiss accounts that fail to fit it.
Contradictory accounts can both make sense
In an illustrative order process, sales may define completion as customer approval. Engineering may define it as release of a controlled specification. Operations may define it as receiving an actionable job. A workshop can produce agreement on the word “complete” without resolving these different meanings. Everyone leaves believing the diagram describes their own version.
Ask each team what the status means, which evidence they use and what decision it permits. Preserve those answers separately until the boundary is understood. A contradiction can expose an important dependency or a legitimate difference in scope. It is information, not merely an obstacle to consensus.
Claims need sources and tests
Translate significant parts of the map into claims. “Operations accepts a job only after specification release” is more useful than an unlabeled arrow. Record who supplied the claim, what scope it covers and what evidence could establish or challenge it. Sources may include observations, system events, messages and interview accounts.
A record is not automatically proof. A release timestamp may show when a field changed, not when the receiver saw it. A person’s recollection may explain a workaround but not how frequently it occurs. Assess relevance and limits explicitly. Where a repeatable check is possible, specify the rule and the data needed to run it.
Keep uncertainty in the model
Unexplored, captured, disputed, verified and proposed are meaningfully different states. Capturing an assertion does not verify it. Repeated agreement does not eliminate the need for evidence. A proposed future workflow should never silently replace the account of what currently happens. These distinctions let readers see where confidence is justified and where investigation is still needed.
Verification also has a scope and a date. A claim supported for one site, order class or period may not apply elsewhere. A system change can invalidate a previously reliable check. Keep enough provenance to explain why the model says what it says and enough version history to see when that account changed.
Current Truth is provisional
Brilliant Quest uses Current Truth for the best-supported, versioned account within a defined scope. The phrase does not mean permanent certainty. It means an account you can interrogate: what supports it, what contradicts it, what remains unexplored and when it was last checked.
This matters when the model becomes input to automation or an agent. The agent should not read every box as equally authoritative. A disputed handoff may justify a question, not an execution plan. An obsolete source may require a fresh check. The practical value of the map comes from keeping the relationship between representation and evidence intact as people use it to make decisions.
Questions worth asking
- What does this arrow actually claim?
- Which account conflicts with this one, and why?
- What evidence would make us revise the map?
Foundational explanation and illustrative examples. This article does not report findings from client engagements or establish a pattern in your organisation.