MDM #9. Why Enterprise MDM Governance Fails After Go-Live — and How to Make Ownership Real
Enterprise MDM governance often looks strongest on the day it is designed.
The governance council has been named. Data Owners and Data Stewards appear in the organization chart. RACI matrices have been approved. Workflow roles exist in the MDM platform.
Then the system goes live.
A country organization requests an exception to a global customer standard.
Two business units disagree about whether two supplier records represent the same legal entity.
A product attribute fails repeatedly, but nobody wants to change the upstream process that creates the error.
A Data Steward can identify the problem but cannot compel the business function to resolve it.
At this point, the real governance model becomes visible.
MDM governance is not proven by the existence of governance roles. It is proven by what happens when people disagree about data.
That is why I would not begin a governance review by asking whether an organization has Data Owners, Data Stewards and governance councils.
I would begin with a harder question:
Who can actually make a decision when an important master-data issue crosses organizational boundaries?
Governance usually fails at the point of decision
Most mature organizations understand the vocabulary of data governance.
They know that business ownership matters.
They establish stewardship roles.
They create councils, policies and escalation paths.
Yet governance can still become ineffective after go-live because the formal structure does not match the organization's real decision-making structure.
Consider a global supplier standard.
The policy says a common supplier classification should be used worldwide.
A local business unit argues that its classification is required for an existing process.
The Data Steward identifies the inconsistency.
The MDM team explains the global standard.
The local team refuses to change.
Who decides?
If the answer is unclear, the problem is not primarily data quality.
It is governance authority.
This distinction is important because no workflow engine can compensate indefinitely for unresolved decision rights.
A Data Owner title is not the same as ownership
One of the most common governance weaknesses is assigning the title Data Owner without defining what the owner is actually authorized to decide.
A Data Owner may appear responsible for customer, supplier, material or product data while being unable to:
- approve or reject a global definition,
- require a business unit to correct a recurring process problem,
- resolve conflicting regional requirements,
- prioritize remediation work,
- approve exceptions to a standard, or
- accept residual data risk.
When that happens, ownership becomes ceremonial.
I would therefore define ownership through decisions rather than job titles.
| Governance question | What real ownership should clarify |
|---|---|
| Definition | Who approves what the master object and its critical attributes mean? |
| Standard | Who can establish or change an enterprise rule? |
| Exception | Who can approve a justified deviation from the standard? |
| Risk | Who can accept a known data-quality risk? |
| Remediation | Who can require corrective action from the process creating the defect? |
If the organization cannot answer these questions, assigning another Data Owner will not solve the governance problem.
A Data Steward should not become the enterprise repair desk
Stewardship is often where governance problems become operationally visible.
SAP's Master Data Governance documentation describes the Business Partner Data Steward role as being assigned to a user responsible for master-data quality and provides authorizations for activities involving processing and replication of master data.
SAP Help Portal — Master Data Governance for Business Partner: Data Steward
That operational role is important.
But stewardship becomes unhealthy when the organization treats stewards as the people who repeatedly clean problems created elsewhere.
For example:
An upstream process creates incomplete supplier records.
The quality rule detects the problem.
The steward manually corrects the records.
The business process does not change.
The same defect appears again next month.
The steward corrects it again.
The quality dashboard may show successful remediation.
The governance model has not solved the cause.
I would expect a mature stewardship function to distinguish between:
- record correction — fixing an individual data defect, and
- root-cause governance — changing the rule, process, interface or ownership condition that keeps creating the defect.
Without the second activity, stewardship can become permanent manual compensation for weak upstream processes.
The governance council can easily become a reporting meeting
Another familiar pattern occurs at the governance council.
The agenda contains data-quality scores, project updates, policy changes and open issues.
Everyone receives information.
Very few decisions are made.
A useful governance council should not exist simply because data governance frameworks recommend one.
It should handle decisions that cannot reasonably be resolved inside one function or domain.
I would therefore judge a council by questions such as:
- What decisions are explicitly reserved for this council?
- Which issues should never reach the council because they belong to normal operations?
- Who has voting or final decision authority?
- How are unresolved decisions escalated?
- Are previous decisions recorded and reusable?
- Can the organization see whether an issue was actually closed?
If every disagreement requires a senior governance meeting, the model is too centralized.
If serious cross-functional disagreements never reach a decision forum, the model is too weak.
Good governance places decisions at the lowest level that has both the information and authority required to make them.
RACI is useful — but it is not enough
A RACI matrix can show who is Responsible, Accountable, Consulted and Informed.
That is valuable for designing operating roles.
But a RACI often becomes ambiguous when the actual problem is a contested decision.
Suppose a global product attribute must have one standard definition.
Three functions disagree.
All three are listed as Consulted.
The Data Owner is Accountable.
Does the owner have authority to impose the final definition?
Can a region appeal?
What evidence is needed for an exception?
Who decides if the exception creates downstream risk?
Those questions require a decision-right model, not only role allocation.
A practical way to add this dimension is to define, for each important governance decision:
| Decision element | Question |
|---|---|
| Proposer | Who can propose a new standard or change? |
| Evidence | What information is required before a decision? |
| Decision maker | Who has final authority? |
| Exception authority | Who may approve a deviation? |
| Escalation | Where does a deadlock go? |
| Record | Where is the decision and rationale retained? |
The goal is not bureaucracy.
The goal is to stop the same fundamental disagreement from being renegotiated every time it appears.
A good quality score can still hide a governance problem
Data-quality metrics are essential, but they need business context.
Imagine a dashboard showing:
Customer Master Completeness: 98%
That appears excellent.
But what if the missing 2% is concentrated in a tax identifier required for a major market?
Or suppose:
Supplier Duplicate Rate: 0.5%
Again, the number appears small.
But what if the duplicates are concentrated among the company's highest-spend suppliers?
A governance team therefore needs to move beyond aggregate quality scores and ask:
- Which data elements are critical?
- Which business processes depend on them?
- Where is the defect concentrated?
- What risk does the defect create?
- Is the trend improving?
- What is repeatedly causing the issue?
The purpose of a quality metric is not to demonstrate that data is “green.” It is to help the organization decide what requires action.
Business and IT need one governance chain
MDM governance often breaks down because business governance and technical governance are designed separately.
The business decides definitions and policy.
IT manages systems and integrations.
That division sounds logical, but master data crosses both.
A change in a supplier definition may affect:
- MDM validation rules,
- ERP configuration,
- interfaces,
- analytics,
- APIs,
- security or privacy controls, and
- downstream business processes.
The business decision therefore needs a technical implementation path.
Likewise, a technical limitation may constrain what governance policy can realistically require.
This is why governance works better when there is a visible chain from:
If one link is missing, governance can exist in documentation without consistently affecting the data itself.
Technology permissions are not the same as governance authority
Modern governance platforms increasingly provide detailed role and permission structures.
Microsoft Purview, for example, separates permissions at organizational, catalog and governance-domain levels, with roles for governance domain ownership, data product ownership, stewardship and other functions.
Microsoft Learn — Data Governance Roles and Permissions in Microsoft Purview
These capabilities are valuable because governance responsibilities can be implemented more precisely in the platform.
But a permission model cannot decide the organizational question on its own.
A user can have permission to approve something without having legitimate business authority to make the decision.
Conversely, an executive may have organizational authority but no appropriate operational role in the platform.
The technology role and the business decision right should reinforce each other, but they are not the same thing.
Governance has to survive organizational change
An MDM governance model can work well initially and weaken after a reorganization.
A Data Owner changes jobs.
Two business units merge.
A regional process becomes global.
A system owner changes.
A new acquisition introduces another source of master data.
If governance roles are attached only to named individuals, they can disappear when those individuals move.
I would therefore anchor governance first to organizational roles and decision responsibilities, then assign people to those roles.
For example:
“Jane owns supplier data.”
More durable design:
“The Global Procurement Process Owner approves enterprise supplier-classification standards and exceptions that affect procurement policy.”
The named person may change.
The governance responsibility remains.
How I would test whether governance is real
I would not begin with a governance maturity questionnaire.
I would select one difficult master-data issue from the last several months and reconstruct what actually happened.
For example:
Who first detected the problem?
Who understood the business impact?
Who proposed the solution?
Who had authority to decide?
Did anyone challenge the decision?
Where was the exception or rationale recorded?
Was the root cause corrected?
Could the organization make the same decision faster the next time?
This exercise often reveals more than the governance organization chart.
If the issue moved repeatedly between teams, remained unresolved for months, or depended on executive intervention for a routine decision, the governance model probably needs adjustment.
AI makes accountability more important, not less
As MDM platforms add AI-assisted matching, classification, rule recommendations and stewardship support, some manual work can be reduced.
But automation introduces another governance question:
Who is accountable for an automated master-data decision?
Suppose an AI model recommends merging two customer records.
For a high-confidence case, automatic processing may be appropriate.
For an ambiguous case involving important customers, human review may be required.
The governance model should therefore define more than who approves traditional workflow requests.
It should also define:
- which decisions may be automated,
- where confidence thresholds apply,
- which cases require human review,
- who may override an automated recommendation, and
- how the rationale and audit trail are retained.
AI can change how master-data decisions are executed. It does not remove the need to decide who is accountable for the outcome.
My practical takeaway
Enterprise MDM governance usually does not fail because nobody created a governance framework.
It fails when the framework cannot make ordinary decisions reliably after go-live.
A Data Owner without authority is only a title.
A Data Steward who repeatedly fixes the same defects is compensating for a process problem.
A governance council that only reviews dashboards is a reporting forum.
A RACI without clear decision rights can still leave conflicts unresolved.
A quality score without business context can create false confidence.
And a platform role does not automatically create legitimate organizational authority.
The most useful test of MDM governance is therefore simple: when an important data decision becomes difficult, can the organization identify who decides, make the decision, implement it and avoid reopening the same issue repeatedly?
If the answer is yes, governance is becoming operational.
If the answer is no, adding more committees or roles is unlikely to be enough.
Sources & Further Reading
- SAP Help Portal — Master Data Governance for Business Partner: Data Steward
- SAP Help Portal — Roles for Business Partners in Data Quality Management
- Microsoft Learn — Data Governance Roles and Permissions in Microsoft Purview
The decision-right model, governance tests and operating recommendations in this article are Digital Future & Strategy's practitioner interpretation of enterprise MDM governance. They are not SAP or Microsoft governance methodologies. Role design, escalation rules and decision authority should be adapted to each organization's business model, regulatory environment, data domains and organizational structure.
Reviewed: September 2026
Global MDM Strategy Series
Part 2 — MDM on the Ground
MDM #8. When Enterprise MDM Goes Off Track — Five Early Warning Signs
MDM #9. Why Enterprise MDM Governance Fails After Go-Live — and How to Make Ownership Real
MDM #10. Why Master Data Derails SAP S/4HANA Migration — and What to Fix Before Cutover
Previous: When Enterprise MDM Goes Off Track — Five Early Warning Signs
Next: Why Master Data Derails SAP S/4HANA Migration — and What to Fix Before Cutover
Comments
Post a Comment