Start with the decision that has to be made

Consider an importer deciding whether to redistribute vehicles between dealers. The decision may depend on available stock, customer orders, vehicles in transit, demonstrator status, ageing and expected arrivals. All of those data points can exist and still leave the allocation decision exposed if the business does not know which source governs a conflict, how fresh the position needs to be or who can release an exception.

A morning stock refresh may be perfectly usable for an evening allocation when little changes during the day. The same refresh becomes risky when dealers can sell, reserve or swap vehicles throughout the day and the cost of allocating against an outdated position is material. The important requirement is therefore the condition of the information at the moment of decision, given how quickly the underlying state can move and what an error would cost.

This is why a decision-to-data map is more useful than another inventory of reports. It starts with the outcome the business owns, then works backwards through the information, controls and authority required to reach it reliably.

Decision ownership and data ownership solve different problems

The current UK Government Data Ownership Model is explicit that data ownership is a business responsibility. It gives data owners accountability for the meaning, quality and management of their domain, while data stewards handle day-to-day governance activity and custodians implement technical requirements in the systems that hold the data.

That structure is important because the owner of a data domain and the owner of a business decision are often different people. A vehicle-data owner may protect definitions and source integrity across the company, while a regional commercial leader owns the allocation decision. A customer-data owner may govern consent and customer definitions, while a retention leader owns the intervention and its outcome.

The operating boundary should therefore be explicit. The person accountable for the business decision sets what the information must achieve for that decision: the required freshness, completeness, tolerance and exception response. The data owner decides how those requirements are met consistently across the enterprise, which source is authoritative and how stewards and custodians implement the controls.

This division keeps business requirements close to the outcome without fragmenting enterprise data governance into local definitions and local source hierarchies.

Quality should be defined against the decision

The UK Government Data Quality Framework describes quality as fitness for purpose and recognises that different uses can require different levels of quality. That matters because a generic target such as “95% complete” tells management very little until the consequence of the missing five percent is understood.

A financial close may require reconciliation and auditability. A lead-routing decision may need speed, completeness and a reliable territory assignment. A dealer-stock redistribution decision may need current availability and a clear distinction between free stock and units already committed to customers. A network-investment decision may tolerate older data while requiring consistency over several periods.

The same principle applies to latency. A daily refresh can be sufficient for one decision and too slow for another. The requirement should be set from the moment the decision is made, the volatility of the underlying state and the cost of acting on stale information. That is more useful than treating refresh frequency as a measure of quality in itself.

Management can then focus effort where failure changes an outcome. A missing value that has no effect on the current decision deserves different treatment from one that creates an incorrect vehicle allocation, breaks a customer commitment or delays a material commercial approval.

Decision-led governance still needs enterprise consistency

A decision-led model can go wrong if every team is allowed to define its own source hierarchy or reinterpret shared data. The UK ownership model addresses this through enterprise data ownership, common definitions, business rules and authoritative sources.

Those enterprise controls should remain stable. Local variation belongs where the decision genuinely differs: how current the data needs to be, what tolerance is acceptable, which fallback is permitted and how quickly an exception must be resolved. The commercial team should not create its own definition of a customer or vehicle simply because it needs a faster decision.

This boundary also makes the relationship between process owners and data owners clearer. The business can define what the process needs, while the data model protects integrity and reuse across processes. That prevents decision-led governance from becoming another route to duplicated logic.

Exceptions reveal which mechanism is actually broken

Routine reporting often looks clean because the normal path works. The more useful test is what happens when a decision cannot proceed.

Suppose the allocation team sees one stock status in the dealer system and another in the wholesale system. Or a pricing meeting starts before a margin input has refreshed. Or a warranty case has complete technical evidence but still waits because the authority to proceed is unclear. Each case may be labelled as a data problem, yet the required intervention is different.

When the source data is wrong, quality is the intervention. When the information reaches the decision too late, latency is the intervention. When systems conflict, source authority is the intervention. When the evidence is available but nobody can release the decision, decision rights are the intervention.

This diagnostic is useful because it stops every blocked decision being pushed into a generic data-quality backlog. It identifies whether management needs to improve the data, change the timing, clarify the enterprise source or change who has authority to act.

Reconstruct ten decisions from last month

A practical way to test the model is to avoid starting with a large governance redesign. Take ten material decisions from the previous month and reconstruct what actually happened. They might include allocation, pricing, warranty approval, lead routing, customer retention, inventory transfer or another recurring decision that materially affects revenue, working capital, customer commitments or operating flow.

For each decision, identify who owned the outcome, which data was used, which source was authoritative, how fresh the information needed to be, what tolerance was acceptable, which exception occurred and who had the authority to resolve it. Then compare the intended governance with the route the decision actually took.

The business decision owner should commission this mapping because the requirement begins with the outcome. Data owners, stewards and custodians should be involved because the solution still has to preserve enterprise definitions, controls and technical integrity.

After ten decisions, recurring patterns usually become visible enough to act on. A repeated source conflict points towards data ownership. Repeated waiting for a refresh points towards latency. Repeated escalation without a clear release authority points towards decision rights. The map gives management a concrete basis for deciding which governance change will improve execution.