By Edris Yaghob//5 min read
Master data is not your first move
When two systems cannot agree which customer is which, someone always proposes a master data program. The first move is smaller, faster, and usually enough: a matching procedure with an owner. Here is the order that works.
Two systems, one customer, two IDs. Sales pulls a report on ACME Industries from the CRM. Finance pulls one from billing. Different totals, same company, and nobody is wrong. The systems just cannot agree which record points to which customer.
Someone says the sentence you already know is coming: we need master data management.
Sometimes they are right. Almost never are they right about the timing.
What the MDM proposal skips
An MDM program is a system answer to what starts as an agreement problem. Before any tool can master your data, someone has to decide: which system holds the trusted record, how records in the other systems match to it, what happens when a match cannot be found, and who owns the matching when the business changes.
Notice what those four questions are. Not technology. Decisions. And here is the uncomfortable part: if your organization cannot answer them on one page, an MDM tool will not answer them either. It will implement your confusion at enterprise scale, on an enterprise license, over eighteen months.
Buying a tool to escape a decision does not cancel the decision. It postpones it and adds a vendor.
I have watched this order fail in large organizations more than once. The program starts with the platform, burns its first year on integration, and arrives exhausted at the exact questions it could have answered in a workshop in week one.
The first move that actually works
Start with a matching procedure. One page. Which system is canonical for this entity. How the others resolve to it. What the fallback is when resolution fails. Who owns the answer. Named person, not a committee.
That is it. No platform, no program, no steering group. A team with that one page can reconcile the ACME numbers next week, because the argument was never about technology. It was about nobody having decided which record wins.
Then run it for a quarter. The procedure will teach you things no requirements workshop can: how often matches fail, which entities actually hurt, where the volume is. That evidence is what a real MDM business case is made of, if you turn out to need one at all.
Master data, if your organization is large enough to need it, is a downstream step. It automates a matching agreement that already works. It cannot create one.
How to tell if this is your problem
One diagnostic question: if I look up this thing in two systems, do they connect through a shared ID, or only by name?
If only by name, you have an identification gap. And notice what it is not. It is not a data quality problem, both records are correct. It is not a definition problem, everyone agrees what a customer is. No data quality rule and no glossary entry will touch it. The gap is procedural, and it needs a procedural fix.
The harder part
The procedure is one page, but the page needs agreement from people who do not report to you. The CRM owner, the billing owner, IT. Each has a system they believe should be canonical, and none of them feels the reconciliation pain as sharply as the analyst matching records by hand every month end. Getting them to one answer is the actual work, and it is where most stewards stall, because they have no structure for the conversation.
That is the moment enabledat is built for: it surfaces the open questions as a scaffold, the owners work through them together, and the matching procedure falls out of the answers, with a name on it.
Decide first. Automate second. Most organizations discover the deciding was the whole job.