Lesson 1 of 6
Why master data governance after go-live
11 min
Listen to this lesson
A transformation program spends months cleaning master data. Contoso's conversion fixed 640 customer inconsistencies before CVI, and Wave 2 is mapping, deduplicating and reconciling 1,946 Alternadores customers for its load in February 2027. Then the program ends, the migration team leaves, and data entry returns to daily business: dozens of people creating customers, suppliers and products under time pressure. Without a control, the clean state decays. SAP Master Data Governance (MDG) is SAP's control for that problem: master data is created and changed through governed processes, checked by rules, approved by the right people, and only then activated and distributed.
This course introduces MDG for process owners, key users and migration specialists. It assumes you know the business partner model and its roles from sap-xpr-201 and the basics of master data from sap-fnd-106. It does not teach MDG configuration in depth; the follow-on course sap-xpr-306 covers how to test an MDG implementation.
How clean data decays
Contoso saw this within two months of the conversion go-live. A review by Hannah, Contoso's new master data lead, found 37 new duplicate customers, 120 suppliers created without a purchasing organization view, and a dozen supplier bank changes that only passed dual control because the second approver approved in bulk. These figures are illustrative course data, but the pattern is common: the data rules from the migration had not become rules in daily data entry.
The governance styles MDG supports
| Style | How it works | Typical use | Contoso |
|---|---|---|---|
| Central governance | Create and change records through a change request with workflow, validation and approval before activation | New customers and suppliers, sensitive changes such as bank data | Business partners first, then products |
| Consolidation | Load records from several sources, match duplicates, calculate a best record, then activate | Acquisitions, data from other systems, data provider files | Customer contacts from the warranty claims app |
| Mass processing | Change many existing records in one governed process | Reorganizations, new payment terms, field clean-ups | Sales district reassignment for aftermarket customers |
| Data quality management | Define rules, evaluate active data, track scores, remediate | Ongoing monitoring of all governed domains | Migration rules turned into monitored rules |
| Federated governance | Several MDG instances each own part of the data, coordinated by a core data owner | Large landscapes with several ERPs and SaaS apps | Not needed today |
Where MDG runs
On SAP S/4HANA, MDG can be co-deployed, running in the same system that processes transactions, or deployed as a hub, a separate SAP S/4HANA system that only governs master data and distributes the golden record to client systems. Co-deployment avoids replicating data into the operational system, because the activated record is already there. A hub separates governance from operations and suits landscapes with many receiving systems. There is also SAP MDG, cloud edition, a SaaS product on SAP BTP, covered in lesson 6. Using MDG functions requires an MDG license; check your contract, including under RISE with SAP.
- Is one SAP S/4HANA system the main consumer of the data?Yes → co-deployment is the simpler start · No → consider a hub
- Do several ERPs or many SaaS apps need the same golden record?Yes → hub or federated governance · No → co-deployment
- Must governance upgrades be independent of the ERP?Yes → hub · No → co-deployment
- Is business partner the only domain for now, with SaaS preferred?Yes → evaluate the cloud edition · No → MDG on SAP S/4HANA
What MDG governs
MDG works on data models. SAP delivers models for the main domains, and customers can extend them or build their own for custom objects. The model decides which entities and attributes can be governed, which in turn decides what a change request can contain. A few practical consequences follow: a field outside the governed model cannot be changed through MDG and needs another control; an extension to the business partner (for example a Contoso-specific fleet size field) must be added to the MDG model as well as to the business partner, or it will be maintained outside governance; and every domain you add multiplies the workflows, rules and tests.
| Domain (SAP model) | Typical objects | Who usually owns it |
|---|---|---|
| Business partner (BP) | Customers and suppliers with their company code, sales area and purchasing views | Order-to-cash and procure-to-pay owners; finance for bank and tax data |
| Material / product (MM) | Product master with plant, sales and accounting views | Manufacturing, supply chain and product management |
| Financials (0G) | G/L accounts, cost centers, profit centers and hierarchies | Finance and controlling |
| Custom objects | Any object a customer models, such as a core agreement | The business owner of that object |
Delivered MDG domains and their typical owners. The scope delivered for EAM, retail and other areas depends on release.
What goes wrong in testing
- Testing MDG like a screen. Teams test that a request can be created and miss the routing, the rules and the activation into the operational record.
- Forgetting the people. Workflow tests run with one super-user who holds every role, so nobody notices that a real approver never receives the task.
- No baseline of data quality. Without a score before go-live of MDG, nobody can prove that governance improved anything.
What would you do?
Grace asks whether Contoso could simply add more mandatory fields and a weekly duplicate report instead of licensing MDG. Hannah has to answer in the steering group. What is the strongest argument?
- Migration cleans data once; governance keeps it clean in daily business.
- MDG styles: central governance, consolidation, mass processing, data quality management and federation.
- MDG on SAP S/4HANA runs co-deployed or as a hub; the cloud edition is SaaS on SAP BTP.
- Contoso co-deploys MDG in CMP: business partners first, then products.
Check your understanding · not graded
Lesson check
1. What problem is MDG primarily meant to solve after a migration?
2. Which MDG style changes many existing records in one governed process?
3. What is a key benefit of co-deploying MDG in the operational SAP S/4HANA system?
4. Why should data owners sign a quality baseline before MDG goes live?