Shared data needs shared rules.
A customer, item or location can mean different things to different teams. One application may store a legal entity while another stores a trading relationship. A stock value may include quantities that another process cannot sell. Without agreed meaning, synchronization can distribute inconsistency more efficiently.
We begin with that process rather than a company-wide cleanup. If units of measure are causing purchasing errors, the review follows supplier packs, item records, receipts and the integration mapping. The result needs one approved meaning and a way to keep later changes consistent.
Put ownership around the information.
| Data responsibility | What to make explicit |
|---|---|
| Definitions | Describe the business meaning, required fields, identifiers and permitted values. Make important differences between systems visible in the mapping. |
| Stewardship | Assign a person or team to resolve questions of correctness. Technical validation can identify a problem, but business ownership is needed to decide the right value. |
| Quality controls | Choose checks that protect the process: completeness, uniqueness, valid references, consistency and timeliness. Define what happens when a record fails a check. |
Build quality into the flow of work.
- 01
Profile the current state
Inspect representative data and identify patterns of missing, duplicate or inconsistent information. Link each issue to the process it affects.
- 02
Agree the rules and owners
Document authoritative sources, matching criteria and correction responsibilities. Resolve ambiguity before embedding a transformation in an integration.
- 03
Introduce proportionate controls
Validate at the point where information is created or changed where possible. Route exceptions to an accountable owner rather than allowing silent defaults to hide the problem.
- 04
Review and maintain
Track recurring causes and update rules as the business changes. Retire obsolete values and guidance through a controlled process that considers downstream dependencies.
A correction needs a route back to every affected system.
Suppose a supplier sells by carton while inventory is held by unit. Correcting one item field will not resolve the issue if the purchasing integration still applies the old conversion. The change needs to reach the source record, mapping and open transactions that depend on it.
A useful rule identifies the business owner, the evidence for the correction and the downstream checks. That is a more workable starting point than a large data dictionary with no connection to the errors people are trying to resolve.
Getting started with data ownership
- Can duplicates be removed automatically?
Some matching rules may be reliable enough for controlled automation, while uncertain cases need review. Define identifiers, confidence and the consequences of merging or changing records. Preserve relationships and history, and confirm approval before consequential cleanup actions.
- How is this different from data migration?
Migration prepares information for a specific move or cutover. Governance defines how the information remains correct and accountable during ordinary operations. A migration can establish useful rules, but those rules need owners and controls after the project ends.