Three definitions of a customer, nobody able to decide
This retrospective perspective on 2019 was written and published in 2026. The group, names and figures below are fictional. They allow examination of data responsibility in a CRM and ERP programme without exposing a real CYTIZEN engagement. References appearing after 2019 are explicitly used as current context.
Lucie, the commercial director, counts 12,400 active customers in the CRM. Finance finds 10,900 in the ERP, while executive management receives a dashboard showing 11,600. Each team has a reasonable definition: an open opportunity, a recent invoice or a current contract. The data programme proposes a common dictionary. Debate moves towards wording while nobody knows which decision the indicator should support.
A data owner is more than the guardian of a definition. They must be able to agree a use, enforce the rule at creation, organise correction and handle exceptions. They do not own all the data in the legal sense. Their operational responsibility sits within business, security, data-protection and system mandates.
Start with the decision the data must serve
To prepare the commercial plan, Lucie wants to identify accounts with which the company can still work and those requiring reactivation. Finance wants to measure customers generating revenue over a period. These needs do not necessarily require the same indicator. Searching for a single “true” number can erase legitimate uses.
The programme therefore distinguishes commercially active customers, invoiced customers and contractually active accounts. Each measure specifies population, period, events and exclusions. A prospect is not transformed into an invoiced customer to satisfy reporting. Reconciliation explains differences rather than imposing a number that no longer answers any decision.
Executive management chooses the measure useful for its dashboard and requests a bridge between populations. The business owner accepts this rule. IT identifies where events are created and how identifiers link systems. The dictionary becomes a consequence of the choice of use rather than an abstract workshop preceding all responsibility.
Separate owner, steward and operator
The owner is accountable for the rule and its suitability for the intended use. The data steward coordinates controls, classifies defects and organises corrections. The operator creates or modifies information according to the rules. One person can fulfil several functions in a small team, but decisions remain distinct.
Lucie owns the commercial definition; finance owns the invoicing measure. The teams agree a matching identifier and treatment of disputed cases. The CRM manager can implement the control but cannot independently decide that a customer without a recent invoice must disappear from the portfolio. The ERP manager can explain the flow without becoming the owner of commercial policy.
The sponsor intervenes when a decision spans both departments. They validate a priority rule or two explicitly different measures. Without this mandate, the data steward receives defects but has no power to close the disagreement. The programme must provide a decision deadline and substitute contact so a significant defect does not remain suspended when an expert leaves.
A completed critical-data record
| Field | Agreed definition |
|---|---|
| Use | Commercial reactivation plan, rather than revenue publication. |
| Population | Existing customer accounts; prospects and internal entities excluded. |
| Rule | Account with a current contract or confirmed order within the defined period. |
| Source | Contract: contract reference repository; order: ERP; CRM holds the commercial view. |
| Identifier | Stable CRM-account / ERP-account mapping; documented exceptions. |
| Owner | Commercial department; finance/commercial decisions by a designated sponsor. |
| Controls | Missing identifier, duplicate, inconsistent date, expired contract not reflected. |
| Correction | At source by an authorised team; propagation into views verified. |
| Evidence | Sample of accounts with originating events and explanations of differences. |
| Limit | This definition replaces neither accounting rules nor retention obligations. |
A defect has a creation cause, not merely an incorrect row
The programme reconciles an account sample. One customer is created in the ERP from a form, then in the CRM from an email. The name differs slightly; no common identifier is transmitted. Two teams correct their screens, but the next order recreates the discrepancy. Cleansing addressed only the symptom.
The team follows creation: who receives the requirement, which data are available, which check is requested and which system assigns the identifier? It proposes a single creation rule or controlled mapping. Business teams validate impacts on their lead times and exceptions. Integration may be necessary, but the programme does not assume it will resolve a contradictory business definition.
Correction of existing data is organised separately from process change. Ambiguous cases are examined by authorised people; an automated merge must not combine two entities simply because their names resemble each other. Matching decisions are traceable, and a sample is checked after propagation into reports.
Define controls that trigger action
A quality rule contains a condition, population, frequency, owner and treatment. “Reliable data” is not a control. “Invoiced account without a CRM matching identifier, checked weekly” is one. The control specifies exclusions so the team does not repeatedly waste time explaining authorised cases.
Completeness is the number of relevant accounts with the expected field divided by the number of relevant accounts. Consistency examines relationships: an active contract with a past end date, an order linked to a closed account, or a correction not propagated. Uniqueness uses a defined comparison rule; it is more than counting identical names.
In the educational case, 40 of 2,000 accounts lack a mapping, or 2%. The steward classifies these defects by cause and impact. A single defect blocking a critical invoice may justify immediate action before the other 39. The overall measure helps prioritisation but does not replace examination of risk and the individual case.
Avoid local corrections that merely beautify reporting
The commercial department wants the committee dashboard corrected before Friday. It can annotate the measure and produce temporary reconciliation. It should not silently alter reporting to hide the discrepancy without correcting the source. Otherwise every month recreates the same conversation and the figure ceases to be explainable.
The owner chooses a published reference with its limitations. Differences are presented with their cause, approximate magnitude and work needed to close them. If temporary adjustment is essential, its formula, version and end date are documented. Someone else must be able to reproduce the calculation without consulting the colleague who invented it.
The programme retains definition changes. A figure rising from 11,600 to 12,100 may reflect improved quality, a new use or real activity. Comparing the values without a note would suggest growth that does not exist. History becomes a tool for interpretation rather than an embarrassment to delete.
Data belongs in business acceptance testing and operations
A migration addresses duplicates, missing fields and mappings. Acceptance testing also verifies what happens afterwards: customer creation, name changes, closure, new relationships between accounts and error correction. Controls are executed with teams that will operate the process rather than only the conversion team.
Support knows the rule owner and the steward responsible for the defect. The ticket contains the identifier, observed value, expected value, source, impact and date. A screenshot alone may show an error but does not identify which system needs correction. The procedure specifies who may modify data and how the result will be checked in dependent systems.
The end of the project does not mean the end of improvement. The owner reviews recurring causes, new uses and flow changes. If manual corrections do not fall after a new control, the team checks that the mechanism genuinely acts at creation. A control that detects without preventing or treating remains another queue.
Adapt responsibility to the nature of the data
In pharmaceuticals, data may contribute to traceability of a batch, equipment or quality operation. Correction rules must account for applicable requirements and approved procedures. A commercial owner does not decide how quality data are treated simply because they appear in their reporting.
In finance, accounting use may impose a specific definition and controls. Commercial measures remain useful, but their differences from accounts must be explainable. In manufacturing, an item or equipment reference may connect ERP, maintenance and site systems. An apparently secondary value may determine whether an intervention or order can be executed.
In customer relationships, personal data also require protection responsibilities, access rights and appropriate retention. Naming an operational owner does not replace those functions. The programme connects use, creation, correction and requirements rather than installing generic authority over everything labelled data.
The first result is a reproducible decision
Begin by choosing data that block a real use. Have five nominally correct cases and five defects described. Name the authority for the rule, the correction steward and the system where the event originates. Complete the record, execute a control and correct a defect through to propagation.
Lucie can then explain why her number differs from finance’s. She knows which accounts should be reactivated and which discrepancies remain unresolved. The dictionary is still useful, but now carries a mandate, a process and evidence. The data have received more than a name; they have people able to make decisions and ensure quality in everyday work.
Sources and method
These current official references illuminate quality dimensions, responsibilities and measurement. The framework published in 2020 and ownership model consulted in 2026 are guidance from after 2019, explicitly distinguished from the year studied. The narrative, record, control examples and thresholds are original. They replace neither accounting rules nor data-protection analysis.
- GOV.UK — Government Data Quality Framework, published in 2020, supplementary current guidance
- GOV.UK — Data ownership model, current reference consulted in 2026
- GOV.UK — How to set performance metrics for your service
Links verified on 4 October 2026. The scenarios and thresholds proposed in this dossier are educational; they describe neither a client engagement nor a result achieved by CYTIZEN.