When a client calls to say the reports are wrong, the reports are almost never wrong. They are faithfully reporting a master file in which the same physical thing exists four times, one of those four is spelled differently, and two of them have no product category at all. The dashboard is not the defect. It is the first place the defect became visible.
The afternoon diagnostic
You do not need a tool or a consultant to establish whether you have a master-data problem. Export your item and customer masters and run five checks:
- Normalise names — lowercase, strip punctuation and spaces — and count exact collisions. Anything above 2% on customers or 5% on items is a live duplication problem.
- Count blanks in the fields your reporting groups by: category, brand, unit of measure, sales region, customer segment. Every blank is a row that quietly disappears from a grouped report.
- Count records with no transaction in twenty-four months. Above roughly 30% and your master file is an archive that everyone still searches.
- Check unit-of-measure consistency for the same item across entities or warehouses. Metres in one, yards in another, is how stock valuation drifts without anyone lying.
- Ask two departments to define one metric — "active customer" is a good one — separately, in writing. Compare.
Why it degrades
Nobody sets out to create eleven versions of a yarn count. Master data degrades because of a rational local decision made under time pressure: a salesperson needs to raise an order now, search does not find the item because the naming convention is not obvious, so they create a new one. Multiply by two years and four hundred users.
That means the failure is systemic, not individual, and the remedy is structural. Three things have to be true at once: creating a record correctly must be easier than creating a duplicate; the convention must be enforced by validation rather than by a memo; and someone specific must be accountable for the domain.
The sequence that works
01
Profile and quantify
Measure duplicate rate, completeness, validity and orphan records — and attach a cost to each defect class. "18% duplicate customers" is a statistic; "18% duplicate customers, which is why we cannot enforce credit limits" is a business case.
02
Write the standard before cleaning anything
Naming convention, mandatory attribute set, code structure, classification hierarchy, unit-of-measure rules. Cleansing without a standard produces a clean file that immediately begins degrading in a new direction.
03
Agree survivorship rules
When two records merge, which values win, and what happens to the transaction history? Decide the rule, then apply it. Deciding case-by-case across nine thousand records is how a cleansing project stalls at record four hundred.
04
Merge with a reversible audit trail
Every merge logged, every prior value retained. You will need to unwind one, and the ability to do so calmly is what keeps the business supporting the exercise.
05
Close the door behind you
Validation at entry, a request-review-approve workflow for new masters, a named steward per domain, and a monthly quality scorecard with a threshold that triggers action.
You probably do not need an MDM platform
At mid-market scale, dedicated master-data-management software is usually the wrong first purchase. Most organisations get further with ERP-native validation, a creation workflow and genuine stewardship than with a platform nobody has time to own. A tool enforces rules you have already agreed; it cannot produce the agreement. Buy it when domain count, volume or regulatory obligation genuinely justifies it — which for most mid-market companies is later than the vendor suggests.
The uncomfortable part
Master-data work is not delegable to a technology partner alone. We can profile, propose standards, prepare match candidates with confidence scores and build the workflow. What we cannot do is decide that these two customers are the same legal entity, or that this is the item code the business will use for the next decade. Those are business decisions, and the projects that succeed are the ones where a named person with authority makes them quickly.
That is the real reason to do this before an ERP migration rather than during it. Migration deadlines force those decisions to be made in a hurry, or not at all — and a defect carried into a new system is harder to see and more expensive to remove.
Written by the Techlyst Data Practice. If any of this describes your situation, a 45-minute consultation will tell you which phase you actually need — book one here.