Explain SAP Master Data Governance (MDG) Basics in SAP

55 / 65

Integrationadvanced

SAP Master Data Governance (MDG) Basics

Centralized master data creation, validation, and distribution using SAP Master Data Governance workflows and data models.

Two records for the same customer, spelled slightly differently, in three systems. That is what MDG exists to prevent.

MDG is like a company's official records office that reviews and approves every change to a legal document (a birth certificate, a property deed) before certifying and distributing copies to every department that needs one, rather than letting each department maintain its own informally-updated copy that might quietly drift out of sync or contradict another department's version of the same record.

Key Concepts

The point is not distribution. Distribution mechanisms already exist. The point is that what gets distributed was validated and approved first.

Master data is created through a request, not directly.

    requester raises a change request
        |
    validation: completeness, business rules, duplicate check
        |
    approval workflow -- one or several approvers, depending on
                         which fields changed
        |
    activation
        |
    distribution to every consuming system

Nobody creates a customer by typing into a system. They ask, and the request is checked.

Duplicate detection is the capability that justifies it. MDG does fuzzy matching, not exact matching:

    existing:  "Bharat Electronics Ltd, Bengaluru"
    new:       "Bharath Electronics Limited, Bangalore"
    -> flagged as a probable duplicate

Exact matching finds nothing here, and these two records will now diverge forever — separate credit limits, separate payment history, two entries in every report.

Why duplicates are expensive, concretely. Automated three-way matching in procurement fails when the invoice references one vendor record and the purchase order another. Spend analysis under-reports, because one supplier appears as two. Credit exposure is understated for the same reason.

None of this produces an error. It produces quietly wrong numbers, which is worse.

Three operating modes.

    central governance  MDG is the only place data is authored;
                        everything else consumes
    consolidation       harmonise master data that already exists,
                        scattered across systems, into one clean set
    mass processing     bulk changes to data already governed

Consolidation is usually where a programme starts, because the mess exists before the governance does.

Distribution is the easy half. Approved records are sent out through standard mechanisms, commonly ALE and IDocs for SAP-to-SAP.

The distinction worth drawing in an interview. Reliable distribution moves data correctly and will distribute a duplicate just as faithfully as a good record. MDG's value is the workflow and validation in front of it. A landscape with excellent IDoc distribution and no governance simply propagates its bad data efficiently.

What the interviewer is probing.1. "What problem does MDG solve?" Probing: the purpose. Stalls: "Master data." Moves up: governed creation and change of master data with workflow, validation and duplicate checks, so quality is enforced before distribution.

2. "What is a change request?" Probing: the model. Stalls: "A ticket." Moves up: the staging object holding proposed changes through approval steps — nothing reaches the active area until it is approved.

3. "Hub or co-deployment?" Probing: the deployment choice. Stalls: "The same." Moves up: a central hub governs data for many systems and distributes it; co-deployment governs the local system only and is simpler.

4. "Why do data quality rules matter more than the workflow?" Probing: the practical insight. Stalls: "They do not." Moves up: approval without validation just moves bad data more slowly — the rules and duplicate checks are what change outcomes.