Start with one domain, one authoritative source, and four weeks. Week one picks the domain and writes down which system wins today. Week two loads the real data and records what breaks. Week three writes rules for those failures and nothing else. Week four hands the result to one downstream system. Everything else waits.
That is not the advice you will find elsewhere, and the gap is worth explaining before you commit a month to it. If you are still working out whether you have a master data problem at all, the plain-English explanation and the two-minute test come first. This post assumes you have decided, and the only question left is what you do on Monday.
Why the standard advice stalls
Search for how to get started with master data management and the first page of results repeats itself. Establish a clear vision. Assess organizational readiness. Identify business drivers. Build a governance framework. Assign owners, stewards, and sponsors. Align stakeholders. Plan for change management. Then, somewhere around step seven, pick a tool.
None of it is wrong. It is written by and for enterprise MDM vendors whose customers have a programme office, a steering committee, eleven source systems, and a budget that has to survive a board review. In that world, the readiness assessment is the thing that stops a two-year programme from failing in month eighteen.
Apply it to a company with four thousand supplier codes, two people who care, and a SQL Server, and it does something specific and destructive: it puts three months of documents in front of the first real record. Efforts that stall at that stage rarely get cancelled outright. The sponsor changes role, the workshop series runs out of momentum, and the spreadsheet is still there a year later. The alternative is to make the first month produce something a person can look at.
Week 1: pick one domain, and name the system that wins
One domain, not a domain model and not a roadmap of domains. The right one is usually where the pain is loudest and the row count is smallest: cost centres, plants, payment terms, units of measure, product classifications. A few hundred to a few thousand rows, owned by a department you can get into one meeting.
Customer is the domain most teams reach for first and the one most likely to stall, because it spans the most systems and the most opinions. It is a good second domain and a punishing first one. How to pick your first MDM domain works through the trade-off properly.
The second half of week one takes fifteen minutes and gets skipped. Write down, in one sentence, which system is authoritative for that domain today. Not which one should be. Which one is. If the honest answer is a spreadsheet on a finance share, write that. You need a baseline you can compare against in week two, and you need everyone to have seen the same sentence. The distinction between the system that creates a record and the systems that merely hold a copy is the whole subject of system of record versus system of reference.
By Friday you should have two sentences on one page. That is the whole deliverable, and it is not a charter.
Week 2: load the real data, badly, on purpose
The instinct here is to model first: sit down with the business, agree the attributes, design the hierarchy, then load clean data into a clean structure. It sounds responsible and it costs three weeks, because you are designing against what people remember about the data rather than what is in it.
Do the opposite. Export the domain from the source system, load every row and every column as it stands, and then read it. The list of things that go wrong is your requirements document, and it is more honest than any workshop output because nobody had to remember anything.
What tends to surface in the first pass: the same supplier under eleven spellings, a free-text Notes column carrying three different facts that should be three attributes, dates stored as text in two formats, a code that was retired and then reissued to something unrelated, and a mandatory field that is empty on a third of the rows. Every one of those is a decision someone has to make, and now you have the actual list instead of a hypothetical one. The initial data load covers the mechanics, and the duplicates question covers what to do with the eleven spellings.
Count the failures before you fix any of them. That number is your baseline, and in three months it is the only evidence you will have that the project did anything. Measuring master data quality goes into which counts are worth keeping.
Week 3: write rules only for what actually broke
Week three is where scope creep arrives wearing a lanyard. Having seen the mess, the natural response is to write a complete validation ruleset, every field constrained and every format enforced. Resist it. A ruleset built from imagination is a ruleset nobody can maintain, and half of it will fire on rows that were fine.
The test we use: if you cannot name the row that broke, you do not need the rule yet. Every rule in month one should trace to a specific failure from week two. Aim for a set two people can keep honest without a document, which in practice means a dozen or so rules rather than a hundred. Data quality rules for master data has the patterns worth reaching for first.
Hierarchies belong in this week too, but only the ones week two proved exist. If cost centres roll up to departments and the roll-up was already implied by a naming convention, model it. If somebody wants a second hierarchy for reporting that nobody currently maintains, write it on the month-three list. Master data hierarchies explains why the second one is where the difficulty lives.
Week 4: give it exactly one consumer
Master data that nothing downstream reads is a spreadsheet with better manners. The fourth week exists to change that, and it is the week most first attempts never reach, because weeks one to three expanded to fill the month.
Pick one downstream system. One view or one export, one schedule, one consumer who will notice if it stops. It does not have to be the important system. A reporting model that three analysts use is a better first target than the ERP, because the failure mode is a wrong chart rather than a blocked purchase order. Getting master data into downstream systems and the integration patterns cover the shapes this can take.
Up to that point the project is an IT initiative with a data steward attached. The first time an analyst opens a report and sees a correction someone made that morning already in it, master data becomes something the business can watch move, and you stop having to argue for the second domain.
What to skip in month one
This is the half of the plan that gets pushback, so it is worth being precise about what “skip” means. None of these are wrong. They are all early, and doing them early is how the month gets spent on documents.
The governance one is the argument you will actually have, usually with someone who has read that governance must come first. The honest version is that governance describes decisions about data that already exists somewhere governable. Write it in month three and it documents what the first domain taught you. Write it in week one and it documents what you assumed. If you have no dedicated governance function at all, data governance without a dedicated team is the version that fits a two-person operation, and what a data steward actually does is worth reading before you write the job description.
The decision the four weeks is really for
Somewhere in week two or three you will hit the question that decides the shape of the next year: do you build this on the database you already have, or buy something. Doing the four weeks first means you answer it with a real list of requirements rather than a vendor's feature matrix.
Build looks cheap and stays cheap for exactly as long as the model is flat. The second hierarchy, per-attribute permissions, an audit trail somebody has to query during an audit, and an approval step are each individually reasonable and collectively a product. Build versus buy walks through where that curve bends, and the implementation styles matter here too, because a registry and a full centralized hub are very different amounts of work.
If you do end up evaluating tools, run the four weeks inside the trial rather than alongside it. A proof of concept built on invented data proves the vendor can demo. One built on the export from week two proves something about your data. How to run an MDM proof of concept is that argument in full, and master data management without consultants covers what the four weeks look like when there is no implementation partner in the room.
What month two looks like
Assume the four weeks worked and one domain is live with one consumer. The failure mode now is not technical. It is that attention moves on, nobody maintains the rules, and the data drifts back to where it was. That decay is measurable and faster than most people expect, and we wrote about how far master data drifts in four months when nobody is watching it.
Month two is the second consumer, the governance you can now write from evidence, and the boring habit of rerunning week two's failure count. The first 90 days after go-live is about that stretch specifically, and it is the part nobody plans for. If you are wondering whether any of this scales to an organization your size, the mid-market gap is the wider version of the argument.
Frequently asked questions
How do you start with master data management?
Start with one domain, one authoritative source system, and four weeks. Week one picks the domain and writes down which system is authoritative today. Week two loads the real data and records what breaks. Week three writes validation rules only for the failures week two produced. Week four sends the result to one downstream consumer. Governance charters, stewardship models, and the second domain come after.
Which data domain should you start with?
The one with the loudest pain and the smallest row count. Cost centres, plants, payment terms, units of measure, and product classifications are usually a few hundred to a few thousand rows and cross fewer political boundaries. Customer is the most commonly attempted first domain and the most commonly abandoned, because it spans the most systems and the most departments.
Do you need a data governance programme before starting MDM?
No. Governance describes decisions about data that already exists somewhere governable. A charter, a stewardship model, and a policy set written before a single record is under management produce documents nobody can test against anything. Load one domain first, then write the governance the first four weeks proved you need.
How long does an MDM implementation take?
For one domain in a mid-market organization, a working first domain takes about a month and a stable one takes a quarter. Enterprise multi-domain programmes run in quarters or years, but that timeline comes from the number of domains, source systems, and approval boundaries rather than from the software. The first domain tells you which of the two you are actually running.
Do you have to buy MDM software to start?
Not for week one or two. A database, an export, and a query will get you through the load and the failure count. The build-or-buy question tends to answer itself in week three, when hierarchies, per-attribute permissions, an approval step, and an audit trail turn a table into a product someone has to maintain.
Run the four weeks on your own data
Primentra installs on a SQL Server you already run, and the 60-day trial is long enough to do the whole month and then argue about it. Load the export from week two and see what the failure count looks like.