Master Data Management has a reputation problem. Every mid-market client we speak to has either bought an MDM tool that nobody uses, been pitched a two-year programme they cannot fund, or concluded the discipline is for large banks only. None of these is a sensible position.
What MDM is — minus the vendor layer
MDM is the discipline of agreeing, owning and maintaining the definitions of the handful of entities your business cannot afford to be wrong about. For most mid-market organisations, that is customer, supplier, product, employee, and — depending on sector — one or two domain-specific entities such as property unit for housing or policy-holder for insurance.
It is not a tool. It is not a hub. It can be run on five tables, a stewardship process and a monthly review. We have done this for clients between 200 and 5,000 staff. It takes a quarter to get started, not a year.
Why enterprise MDM projects fail in mid-market
- Over-specified hubs. Full survivorship, bidirectional integration, 60-rule match engines. Fine for a global bank; overkill for a specialty insurer.
- Stewardship with no teeth. A steward is named, but has no authority to make the business hold still while the definition is agreed.
- Tool before discipline. An MDM product is purchased before anyone agrees what "customer" means. The tool automates the confusion.
- No consumers. The golden record exists, but downstream systems never consume it. It becomes a parallel reality that argues with the source systems it was supposed to reconcile.
The pattern we use
Step 1 — pick the one entity that hurts most
For a housing association that is "property unit". For a specialty insurer, "policy-holder". For an accountancy firm, "client". Not all five. One.
Step 2 — agree the definition before the schema
A facilitated workshop — ninety minutes — with the business leaders who use the entity. Write down what a "customer" is, with edge cases and exclusions. Get it signed. Only then build the table.
Step 3 — build a minimum viable golden record
One table per entity, with a stable surrogate key, the agreed attributes, a confidence score per attribute, a lineage column, and a last-reviewed timestamp. This is a few hundred lines of dbt, not a six-figure licence.
Step 4 — agree the stewardship rhythm
A named steward per entity, a monthly review, an escalation path. We use a shared worklist — duplicates, conflicts, missing attributes — and a thirty-minute standing meeting with the business. If the business cannot send someone to that meeting, the programme pauses. That rule alone has saved two clients from a bad project.
Step 5 — force downstream consumption
Pick one consumer (a report, an integration, an application) and move it to the golden record. Measure the impact. Only then pick the second. Do not migrate every consumer in parallel; the golden record will wobble, and the business will lose trust.
When you need more than this
Genuine MDM platforms earn their keep in three places: very large enterprises with many source systems per entity; industries with strict survivorship regulation (life assurance, pharmacovigilance); and high-volume probabilistic matching (global retail). Outside those, the lightweight pattern is almost always enough.
Two of our current clients have sub-£250k total MDM spend — licences, implementation, stewardship — and are running three entities at maturity level 3. Neither could have afforded the tool the previous firm had proposed.
The cost of doing nothing
Clients who skip MDM accumulate a predictable set of costs: BI that disagrees with itself, customer experience damage from duplicate contact, onboarding errors, regulator queries that take three weeks to answer because the answer is scattered. These are not catastrophes; they are a gentle, persistent drag on operations. MDM pays for itself by removing that drag.