You get to the point where the case for MDM is undeniable. Duplicate vendors generating double payments. Product descriptions that don't match between the ERP and the website. Reporting that shows different totals depending on which system you ask. You know something needs to change.
Then someone asks: “Where do we start?” And it stalls.
Most organizations have data problems in every domain at once. Suppliers, products, customers, cost centers — all messier than they should be. That makes prioritization genuinely hard, and it's why MDM projects sometimes spend the first three months in workshops debating scope rather than fixing anything.
Three questions to ask first
Score each domain against these three questions. The one that gets yes on all three is where you start.
1. Which domain is causing the most visible, expensive pain right now?
Finance is getting duplicate invoices because the same supplier exists under three different names. That is concrete, expensive pain with a clear business cost. Not “which domain has the most records” or “which has the most potential.” Which one is breaking something today.
2. Is there a clear owner?
Not “IT” and not “everyone.” One person, one team, with the authority to define what the data should look like and the accountability when it's wrong. No owner, no governance program — just a cleanup project that falls apart the moment someone asks a difficult question about a record. The data ownership problem has to be settled before governance can function.
3. Can you build a governance model in 60–90 days?
Governance means: defined validation rules, a clear approval process, named stewards, and a single authoritative home for the data. If you can get all of that in place in three months, the scope is right. If scoping conversations are already running to six-hour workshops with no clear resolution, the domain is too large or too politically contested for a first deployment.
Suppliers almost always win
Apply those three questions to most mid-market organizations and suppliers come out on top more often than not. The reasons aren't complicated.
The universe is finite and knowable. A typical organization has 200–2,000 active suppliers, not millions. That's a manageable first scope. Compare it to customer data, where the record count alone is an order of magnitude larger.
Finance already feels the pain. Duplicate vendor payments. Wrong payment terms. Unvalidated bank accounts. These are expensive problems that a CFO will fund a solution for. Getting budget for supplier governance is an easier sell than getting budget for “data quality improvement.”
Procurement is the natural owner. They manage supplier relationships. They understand which fields matter. They have the authority to define onboarding requirements and the incentive to keep the list clean. The governance conversation with procurement is straightforward: here are the rules, here is the queue, here is who approves what.
The data structure is not complicated. Company name, registration number, address, payment terms, spend category. A flat or lightly hierarchical model you can design, validate, and populate in a few weeks — not months.
The first real MDM deployment at most organizations is supplier master data. Not the most exciting domain. Just the one where the scope is manageable, the owner is willing, and the finish line is visible.
When products are the right starting point
Products are the right first domain under two conditions: the business runs on product data, and someone with genuine authority over the product catalog is willing to own governance.
Manufacturing, retail, distribution — in those industries, product master data is where the real pain sits. Descriptions that don't match between ERP and website. Missing technical attributes that delay order fulfillment. A category hierarchy that nobody agrees on. If any of that sounds familiar, products might be your domain one.
It's also more complex to model. A product has a hierarchy (category, subcategory, SKU), multiple attribute sets depending on product type, and relationships to other entities like brands and suppliers. Getting that data model right takes longer than a flat entity with twenty fields. And there is almost always a political problem layered on top: marketing, logistics, and finance all claim ownership of product data. Three departments, three sets of rules, three separate approval concerns.
If you go with products first, narrow the scope. One product category, one mandatory attribute set, one owning team. Not the full catalog. The goal in the first 90 days is to prove the governance model works for one slice. Expand from there.
When cost centers work
Cost centers are the right first domain when a reporting project is the trigger. Finance has just discovered that the cost center hierarchy in the ERP and the hierarchy in the BI tool are six months out of sync and the board's quarterly numbers don't reconcile. That is an MDM problem, even if nobody is calling it that.
The advantage: finance already has the authority to define what the structure should look like, and they have the most obvious incentive to get it right. The data model is simple — code, description, parent node, responsible owner. Unlike supplier or product data, there is rarely a debate about who approves changes.
The limitation: the governance use case is narrower. Once cost centers are governed, the next logical step is a different domain. Cost centers rarely generate the organizational momentum that supplier or product governance does. Useful starting point for a finance-led initiative; harder to parlay into a broader MDM program.
Why customers should wait
Customer master data looks like the most important domain. It's also the hardest to govern first.
Volume is the first problem. A typical B2C company has hundreds of thousands of customer records. You cannot run record-by-record stewardship at that scale. The governance model for customers requires automated validation, exception-based review, and periodic reconciliation across systems. That is more complex to design than a supplier approval workflow, and harder to get right without any prior governance experience.
GDPR adds another layer. Customer records carry erasure requests, consent obligations, and access controls that go beyond standard permissions. Getting data governance right while also satisfying privacy compliance is a bigger project than it looks from the outside.
Sales, marketing, support, billing — all of them maintain some version of the customer record. Agreeing on a single source of truth takes political capital that is hard to spend on a first deployment.
Customers should be governed eventually. But the governance model you build for suppliers will make you better prepared when you get there. Start where you can get a clean win. You'll tackle customers in better shape.
What “done” looks like for domain one
Before you move to domain two, four things need to be true:
A governed list. Every entity in the domain meets the validation rules you defined. No grandfathered records quietly bypassing the standard.
A working approval process. New records and significant changes go through review before they go live. The approval workflow separates governance from cleanup.
An audit trail. You can answer “who changed that, when, and why?” for any record in the domain. Without a complete history, you cannot investigate problems or demonstrate compliance.
At least one downstream consumer. The ERP, the BI tool, an integration — something reads from the governed master and the old copy is either retired or clearly flagged as secondary.
Not “better data.” A governed process that prevents the domain from decaying back to where it started. Once that works, the conversation about domain two is a lot easier to have.
Ready to govern your first domain?
Primentra runs on SQL Server. Configure entities, validation rules, and approval workflows for your first domain in a day — no consulting engagement, no six-month implementation. The 60-day trial includes everything.