Master data management strategy: a roadmap that does not stall

The same customer exists three times in the CRM, under a different name in the ERP, and with a stale address in the support system. Every department is partly right and none holds the truth. Master data management fixes this structurally, but the projects that try often stall on scope. This article covers the business case for MDM, the four ways to implement it, and a roadmap that ships instead of stalling.

What master data is, and why it drifts

Master data is the set of core, long-lived entities a business runs on: customers, products, suppliers, employees, locations. These entities change slowly but are used by almost every system, and that combination is exactly what makes them drift. Because many systems hold the same entity, they diverge: an address updated in one place and not another, a product renamed in the catalog but not in reporting.

Without a layer that reconciles them, the number of conflicting versions grows with every system added. The result is not abstract. It is invoices sent to the wrong address, the same customer contacted twice by different teams, and analytics that disagree depending on which system fed them.

The business case: the cost of not having it

MDM is easy to postpone because its absence has no single owner. The costs are distributed and therefore invisible until totaled.

• Operational errors: wrong deliveries and invoices from inconsistent customer or product records.
• Wasted spend: duplicate marketing to the same person counted as three, or procurement that misses volume discounts because one supplier looks like four.
• Lost trust in reporting: when two dashboards disagree because they resolved the same entity differently, decisions slow down and the data team spends its time reconciling instead of analyzing.
• Compliance exposure: GDPR rights of access and erasure require finding every record about a person. Triplicate customer records make complete fulfillment impossible to guarantee.

Framed this way, MDM is not a data-team nicety. It is the removal of a tax the whole organization pays.

The four implementation styles

How deeply MDM reaches into the system landscape is set by its style. Four are established, and they trade effort against control.

Registry. The MDM system stores only cross-references and match results; the data stays in the source systems. Lowest effort, delivers a unified view for analysis, changes nothing in the sources.

Consolidation. Data is copied into a central hub and resolved into a golden record, typically for reporting. Sources are untouched; the hub is the truth for analytics.

Coexistence. The golden record is maintained centrally and synchronized back into the source systems, which stay writable. More effort, in exchange for consistent operational data, not just consistent reports.

Centralized (transaction hub). Master data is authored only in the MDM system and consumed everywhere else. The strongest control and highest consistency, and the largest change to existing processes.

The common mistake is starting with the most centralized style because it promises the most control, and underestimating how much process change it forces. The right style is the least invasive one that meets the requirement.

A roadmap that ships

MDM programs stall for one reason above all: they try to master every domain, in every system, before anything goes live. The alternative is a domain-by-domain roadmap.

1. Pick the domain that hurts most. Usually customer, because its errors are the most visible and the most expensive. One domain, not all of them.
2. Define the golden record for it. Agree the matching rules, the merge logic, and survivorship (which source wins when they conflict). These are business decisions, made with the domain, not the tool.
3. Choose the lightest style that works. Often consolidation first, to prove value on reporting before touching operational writes.
4. Assign stewardship. Named domain experts who adjudicate matches and own the rules. Without them, the tool automates bad decisions.
5. Prove it, measure it, extend. Show the reduction in duplicates or the audit made possible, then apply the same pattern to the next domain.

This sequencing is why MDM is best treated as part of a broader data governance program rather than a standalone tool purchase: the golden record depends on the ownership and quality practices governance provides.

Failure patterns

From the field, the patterns that stall MDM strategies:

1. Boil the ocean. Every domain at once, so nothing reaches production.

2. IT without the business. No stewards, so match and survivorship rules encode guesses instead of domain knowledge.

3. Most centralized by default. A transaction hub where consolidation would have proven value first, maximizing process disruption up front.

4. Survivorship left vague. No agreed rule for which value wins, making merges arbitrary and untrusted.

5. One-time dedupe. Merging duplicates once without changing the process that creates them, so they regrow immediately.

Talk through your MDM strategy

DNA Solutions helps European enterprises build master data management that ships: the business case, the golden record, the right implementation style, and a domain-by-domain roadmap anchored in stewardship and governance. Whether the same customer lives in your systems five times or a GDPR request cannot be answered with confidence, we start with the domain that costs the most and prove the pattern before extending it. Talk to us.