Operationally intensive enterprises
A decision layer over operational and financial data
What it takes to move an organisation from good reporting to decisions that are made from evidence rather than from the spreadsheet somebody built the night before.
Capability pattern. This page describes how a class of problem is handled and does not describe a specific client engagement.
- Setting
- Operationally intensive enterprises
- Capability
- Owned decision layer
- Compounding asset
- Semantic layer and reference data
- Common blocker
- Unresolved counterparty identity
- Updated
The mandate
Turn a well-run reporting estate into an intelligence function that produces judgments the organisation can act on and defend.

The situation
This pattern recurs in organisations that have done the data work properly. There is a warehouse, it is well run, reporting is reliable, and the most consequential decisions are still being made from a spreadsheet assembled overnight by whoever understood the question. That is not an engineering failure. The warehouse was built to answer questions whose shape was known in advance, and the decisions that matter are the ones whose shape was not.
Operationally intensive sectors reach value fastest here because their decisions are frequent, measurable and expensive to get wrong. Mining, energy, logistics, healthcare and manufacturing all generate large volumes of operational signal that never meets the financial picture, and the gap between those two views is usually where the recoverable value sits.
What was built
- 01
An explicit semantic layer
Definitions, entity resolutions and business rules moved out of tribal knowledge and report queries into a versioned, tested repository the organisation controls.
- 02
A counterparty and customer spine
Resolved identity across systems, with match confidence recorded, so that questions crossing source systems can actually be answered.
- 03
External signal integration
Public registry, enforcement, trade and where relevant public-ledger data joined at the counterparty rather than the transaction.
- 04
Confidence-carrying outputs
Derived conclusions that carry the uncertainty of their inputs as a field rather than as a footnote lost in summarisation.
How it was approached
Start with the twelve figures that appear most often in executive papers and write a tested definition for each. That exercise alone typically surfaces two or three cases where two functions have been reporting the same label from different logic, which is both an immediate fix and the argument for continuing.
Reference data is the one place we argue for structural investment ahead of a specific use case, because the return compounds and no individual use case will ever justify building it alone. Everything else should be pulled into existence by a live question.
The technology was never the constraint. The constraint was that nobody owned the sentence at the end of the analysis.
The operating model is mostly people, and only one of the four roles is an engineer. Someone frames the business decision as an answerable question. Someone interrogates the data and holds the definitions. Someone owns identity and confidence. And someone senior enough carries a contested conclusion into a room where it will be argued with. Organisations that staff those four produce intelligence with modest tooling; organisations that buy sophisticated tooling without them produce dashboards.
Outcome
- Executive figures resolving to tested definitions in a repository the organisation controls.
- Questions that cross source systems becoming answerable, because identity is resolved.
- Conclusions that carry their own confidence, so decisions inherit uncertainty rather than hiding it.
- Decisions made from the intelligence function rather than from an overnight spreadsheet.
Capability transferred
- The semantic layer, versioned and owned, with tests the organisation runs.
- Reference data ownership sitting with a named function.
- Four staffed roles covering framing, analysis, identity and carrying the conclusion.
Methods
- Semantic layer engineering
- Entity and counterparty resolution
- External signal integration
- Confidence propagation