Almost every master data programme that gets into trouble was, at some point, on schedule. The platform was chosen, the environments were built, sources were loading. Then adoption stalled — not because anything broke, but because the business looked at the golden record and decided it did not describe reality closely enough to act on.
That failure is rarely technical. It traces back to a small number of decisions taken very early, when the cost of getting them right was lowest and the attention on them was thinnest.
The golden record gets defined by the source, not by the consumer
The most common starting point is the data that happens to be available. Someone loads the CRM, then the ERP, and the model grows outward from whatever those systems contain.
The problem is that nobody asked what the record is for. Which decisions depend on it? Which downstream systems consume it, and what do they actually need to be correct? Without that, survivorship gets configured for every attribute equally, because there is no basis for saying one matters more than another.
Start from consumption. If the record exists to support credit decisions, then the tax identifier and the registered address carry weight that the marketing preference flag does not. That ordering tells you where to spend match-tuning effort and where "good enough" is genuinely good enough.
Trust hierarchy gets treated as a technical setting
Trust scores decide which system wins when two disagree. That is a commercial judgement about which part of the organization is authoritative for which fact — and it is almost always configured by whoever is closest to the tool.
The result is predictable. Six months later, a business owner sees a record where their system lost, escalates, and the programme discovers there was never an agreement to point back to.
Get the trust hierarchy agreed and written down before configuration, with named owners per attribute. It is a slow conversation and it is much slower to have afterwards.
Match rules ship on vendor defaults
Every MDM platform arrives with sensible starting rules. They are starting rules.
Tuning means assembling a labelled sample — pairs a human has judged as matches or non-matches — and measuring precision and recall against it. Without that, you have opinions about match quality, not evidence.
The asymmetry matters here: over-matching is far more damaging than under-matching. A missed duplicate is an inconvenience someone eventually notices. A wrongly merged pair of customers surfaces as one person seeing another's data, and it destroys confidence in the entire dataset in a way that is very hard to recover.
Stewardship is sized to the queue, not to the team
The last one is the quietest. Configuration determines how many records fall below the auto-merge threshold and land in a human queue. If that volume exceeds what the stewardship team can clear, the backlog grows indefinitely.
To everyone downstream, an unworked backlog is indistinguishable from bad data. The platform is functioning exactly as designed and the outcome is still failure.
Size the thresholds against real capacity. If the team can work 60 tasks a day, the configuration has to produce something close to 60 tasks a day — or the team has to grow before go-live, not after.
What this looks like done properly
None of this is exotic. It is four conversations, held early, with the right people in the room:
- What decisions does this record serve, and which attributes carry them?
- Who is authoritative for each attribute, and do they agree?
- What are our measured precision and recall, on a sample we labelled ourselves?
- How many stewardship tasks per day can we actually clear?
A programme that can answer those four questions before configuration begins is not guaranteed to succeed. But it will not fail in the way most of them do.
VYLQORA implements and rescues master data programmes on Reltio and Informatica MDM. If any of the above is uncomfortably familiar, start a conversation.
Written by VYLQORA. Have a view, or a problem this touches? Start a conversation.