Almost every master data governance programme I have seen produces a document first. It is usually a good document. It names the domains, it names the owners, it defines what a valid supplier record contains, and everybody in the steering group signs it.
Then somebody pastes four hundred rows into a spreadsheet-fed load at four on a Friday, and not one line of that document is consulted. It could not be. It is a PDF on a shared drive, and the load talks to a table.
That gap is the whole subject. The policy is the easy half.
What master data governance actually is
Master data governance is the set of rules and ownership that decides what a shared record is allowed to say, together with the machinery that enforces those rules at the moment the record is written. Four parts, and every one of them has to exist somewhere a machine can reach:
- One named person per domain who decides. A person, not a committee that meets monthly.
- A statement of what a legal value looks like, written so that the database can refuse an illegal one.
- A list of which changes need a second pair of eyes before they land, and whose eyes.
- A history of who changed what and what it was before, readable by whoever has to explain it later.
Write those four into a document and you have described governance. Put them where the write happens and you have it.
The test that settles it
Take a supplier VAT number in the wrong format. Now try to get it into your master data five ways: type it into the screen, paste a block of rows, import a file, let the overnight job load it, and post it through the API.
Count how many routes refuse it. In most estates the answer is one, because the check was written by the person who built the screen, in the language the screen is written in. The other four routes reach the same table and never render it. More on that in garbage in, garbage out.
A governance programme that scores one out of five on that test has a policy, not a control. And the four unguarded routes are the ones carrying the volume, which is where the damage lives.
Why SAP is the first answer, and why it is often the wrong one
Search for master data governance and SAP owns the first result. That is not an accident: SAP Master Data Governance is a real product with a real installed base, and inside an SAP-centric estate it is a sensible choice.
It assumes SAP is the system of record. That assumption is doing a lot of work. If your suppliers are created in a procurement tool, enriched in SAP, referenced by a warehouse system and reported out of a SQL Server warehouse, then putting governance inside one of those five applications gives that application authority it has not earned. The first acquisition, and you have two of them.
Shared data needs a home that belongs to no single application. That is the argument for a dedicated master data system, and it is the same argument whether the system is SAP MDG, Profisee, Semarchy or ours.
Three failures that look like governance
The committee as a workflow step. A change waits for a monthly meeting. People need the supplier on Tuesday, so they create it somewhere else and reconcile later. The committee is now generating the duplicates it was formed to prevent.
The quality dashboard. A number goes up and down on a slide every month. Nobody disputes the number, and nothing about the process changes, because measuring a problem is not an intervention. A dashboard tells you the rate. A rule changes it.
Everything is an approval. Route every field change through a reviewer and the reviewer stops reading within a fortnight. Approval is an expensive control and it should be spent where a wrong value is expensive: bank details, tax identifiers, the fields that move money. Not on a description field.
Start with one domain
Pick the domain that causes the most arguments. It is nearly always supplier or product, because both are created by several teams and consumed by everybody. Then do four small things:
- Name one owner. A person, not a department.
- Write five rules, not fifty. The five that would have caught last year's worst mistakes.
- Put approval on the two or three fields where a wrong value costs money.
- Turn on history and check that a non-technical person can read it.
Then leave it alone for a quarter and count what the rules refused. That number is the business case for the second domain, and it is a far better argument than the maturity model in the appendix.
What governance cannot do
No rule catches a value that is wrong and plausible. A supplier bank account that is correctly formatted, passes the checksum, and belongs to a fraudster passes every automated check anyone can write. That is not a tooling gap. It is the edge of what a rule is, and it is why the owner exists.
What the machinery buys you is that the owner's attention goes to the plausible-but-wrong cases instead of being spent on missing VAT numbers and duplicate codes. That is the whole return.
Common questions
We already have a data governance policy. Is that not governance?
It is the half that is easy to produce. The other half is machinery: a rule that refuses the value, an approval that blocks the change, a history that says who did it. A policy nobody can enforce is a description of the behaviour you wish you had.
Is this the same as data quality?
Overlapping, not the same. Data quality measures how wrong the data is. Governance decides who is allowed to make it wrong and what happens when they try. You can measure quality forever without improving it, which is what most quality dashboards do.
Do we need a governance committee?
You need a named owner per domain. A committee that meets monthly cannot approve a supplier change on Tuesday, and if it tries, people route around it. Committees are useful for deciding policy and useless as a step in a workflow.
How long before this shows a result?
The first refused bad value shows up on day one, because the rules run on the routes that carry volume. A change in a report takes a quarter, because the bad rows already in there do not fix themselves. Do not promise the second thing to get budget for the first.
Related reading: data governance vs master data management, and governing data without a dedicated team.
Run the five-route test on your own data
In Primentra the rule lives with the entity, so typing, pasting, importing, the scheduled load and the API all hit the same gate. Ownership, approval and history come with it. Runs on your own SQL Server, deploys in a day, €7,500 per year flat with a 60-day trial.