Purchasing and warehouse teams use different names for one material. An analyst proposes merging similar records, but one appears in open orders and the other has a different unit. In this illustrative example, the decision starts with record meaning, not a merge button.
Separate decisions from routine checks
For the dataset, agree who owns field definitions, change rules and permitted exceptions. Assign daily quality work separately: investigating discrepancies, collecting evidence and preparing proposals. IT implements the agreed rules and operates the system.
This is a proposed responsibility model, not a mandatory organization chart. One person may hold several roles with allocated time, access and authority. Consequential changes may need independent approval.
Check consequences before changing records
Compare identifiers, units, open orders and operational history. Similar names justify investigation, not automatic merging. Consider every system consuming the records.
Decide which record remains authoritative, how references move and how an incorrect merge can be repaired. If historical documents must retain old values, record that as a specific implementation requirement. A general promise of a single source of truth cannot replace it.
Define the boundaries of three roles
| Role | Decision or action | Outcome |
|---|---|---|
| Data owner | Approve a rule or exception | A clear condition for change |
| Quality lead | Collect and validate grounds | A substantiated proposal |
| IT team | Implement and test the workflow | Controlled change and history |
The matrix needs an exception path. When owners disagree, the team must know who decides and which operations can continue in the meantime.
System configuration makes the agreement operational
Change forms, permissions, checks and logs should reflect agreed roles. In Intecracy Group implementations, Digital Line defines requirements before assessing a specific product. A log does not automatically make history immutable or data correct.
AI may propose similar records or extract document values. A proposal still needs a source and validation. Model confidence is not authority to modify reference data.
Start with one dataset
- Choose reference data with visible operational problems.
- Define key fields and their consumers.
- Assign rule ownership and daily validation.
- Test a normal change, a conflict and error correction.
Questions and answers
Do we need a dedicated data-quality job?
Not always. You need explicit responsibility, allocated time and access to the decision owner. A job title alone does not provide them.
Must all reference data move into one system?
First agree meaning, sources and exchange rules. The architecture can remain distributed if ownership and changes are controlled.