SAP MDG

MDG provides governed processes for master data: request-and-approve workflows for creating/changing key master data, validation and duplicate checks, data quality rules, and central governance with distribution to connected systems. It tackles the master-data quality problems that undermine ERP.

• Governed workflows for master-data change.
• Central governance with a single source of truth.
• Validation, duplicate checks, data quality.
• Distribution/replication to connected systems.

The capability people underuse is data replication. MDG is not only a workflow; it distributes the approved record to every system that needs it, with filtering so each receives only what is relevant. In a landscape with several ERPs, that distribution is frequently worth more than the approval process itself, because it is what makes one source of truth real rather than aspirational.

The difference between maintaining master data and governing it is a workflow, and the shape is worth knowing.

A change request is raised rather than a record being edited. It carries a type, which decides the workflow, and the proposed values.

Validation and enrichment run against the request. Duplicate checks, completeness rules, external data lookups such as address validation or a tax number check. This is the stage that catches the duplicate before it exists rather than after.

Approval routes to whoever owns that data. A material's accounting view goes to finance, its sales view to sales, and the request can require several approvals in sequence or in parallel.

Activation writes the record to the active area, and only then does it exist for transactions.

The key architectural idea is the staging area. A request in progress lives separately from live data, so half-approved records never appear in a purchase order. That is what makes governance possible without blocking the business.

Replication then distributes the approved record to the systems that need it, which is the other half of MDG's job: one governed source, many consumers.

Half an hour on a system with MDG configured, and it makes the difference from ordinary maintenance obvious.

1. Raise a change request to create a supplier. Notice you are filling a request, not a master record.
2. Submit it. Validation runs, and a duplicate check compares against existing partners.
3. Look for the supplier in the ordinary transaction. It is not there, because the request is in the staging area.
4. Approve as the finance approver, then as the purchasing approver. Watch the request move through its steps.
5. After final approval, activation writes the record. Now it exists, and it can be used on a purchase order.
6. Check the change request log. Who asked, who approved, what changed, when. That audit trail is most of why MDG is bought.

MDG integrates across the landscape, governing master data centrally and replicating it to S/4HANA and other systems. Because poor master data breaks every process built on it, MDG is increasingly important and a valuable specialisation for data-focused consultants.

The deployment question is where MDG runs. Co-deployed means it runs inside the S/4HANA system it governs, which is simpler and ties them together. Hub deployment means a separate system governs several, which suits a landscape with more than one ERP and adds replication to maintain. That choice follows from how many systems need the same data rather than from preference. See SAP master data for what is being governed.

• How often records are created. A business creating five materials a month does not need a workflow engine. One creating five hundred, across three teams, does.
• What a mistake costs. A wrong bank detail on a supplier is expensive and occasionally fraudulent. A wrong description on a stationery item is not.
• How many systems consume the data. One system can govern itself with discipline. Four systems need a source of truth, and that is the strongest argument for MDG.
• Which domains. Supplier, customer, material and finance are the standard ones, and implementing all four at once is a programme rather than a project.

Learn MDG through its core processes, its master data and configuration, and its integration with the rest of the SAP landscape. Hands-on practice cements it.

MDG is one answer to master data quality and it is not the only one, so it is worth knowing the alternatives before recommending it.

Discipline and ownership. A named owner per object, a documented standard and a periodic review catches a surprising amount, and it costs configuration effort of zero. For a small landscape creating few records, this is genuinely sufficient.

Workflow in the core. Standard workflow can route a material creation for approval without a separate product, which covers the approval requirement and not the staging, validation or replication.

Validation rules and field status. Making fields mandatory, restricting values and adding checks prevents a class of error at entry, cheaply.

A cleansing project. Where the problem is the data that already exists rather than what is being created, governance does not help and a one-off cleanse does.

MDG earns its place when several systems consume the same data, when the volume of change is high enough that manual review does not scale, and when the audit trail is a requirement rather than a nicety. Recommending it for a landscape with one system and ten materials a month is an expensive way to solve a discipline problem.

Governance is bought to improve data quality, and quality has to be measured or the programme cannot be judged.

Completeness. What proportion of records have every field the business needs, per domain. Easy to measure and usually the first thing to improve.

Duplicates. How many real-world entities appear more than once. Harder to measure and the most expensive to leave.

Validity. Values that conform to the rules: real tax numbers, valid addresses, plausible bank details.

Timeliness. How long from a request being raised to the record being usable. This is the number the business actually feels, and a governance process that is thorough and slow gets routed around.

The last one is worth watching most carefully during a rollout. If creating a supplier takes four days, people will find a way to buy without one, and the spend leaves the process entirely. A dashboard covering all four, reviewed monthly, is what keeps governance honest about its own cost.

• Learning features, not the end-to-end process.
• Ignoring integration with finance and neighbouring areas.
• Skipping master data/configuration the process depends on.

• Governance with no owner per field. The workflow routes somewhere and nobody knows why they were asked.
• Approval steps that everyone rubber stamps. That is process cost with no control.
• Implementing MDG to fix data that needs cleansing first. Governance stops new problems and does not repair old ones. See Ariba and SuccessFactors for cloud products with their own master data.

• Rolling out every domain at once. Supplier, customer, material and finance are four projects, and doing them in sequence means the first one teaches you something before the second starts.

Raising a request is the easy half, and designing the change request types, validations and approvals for a real domain is the part you do in the course.

The measure that keeps governance honest is how long a request takes from raised to usable. A thorough process that takes four days will be routed around, and the spend leaves the system entirely.