Do you need SAP MDG? An honest diagnostic before you decide

Governance is not a tool. It's a capability. 

This is where most evaluations go wrong. Governance gets treated as something you buy, when it's actually something you build — a set of decisions about who owns which data, what a complete record looks like, which rules are non-negotiable, and who approves what. 

SAP MDG doesn't make those decisions for you. It enforces them, at scale, consistently, with an audit trail. That's an enormous amount of value, but only once the decisions exist. Install a governance platform on top of an organisation that hasn't agreed what a customer is, and you have automated the disagreement. 

Put plainly: the tool runs the governance. It doesn't invent it. If nobody owns master data today, buying MDG won't create an owner — it will create an expensive system with no one to steer it. 

What you need before the tool 

A small dedicated team, or at minimum named owners per domain, with enough authority to say no. An agreed definition of your core objects. A rough sense of your current data quality — not a full audit, but an honest one. And a clear reason why the current way of working isn't sustainable. 

If you have those four things, a governance platform will multiply them. If you don't, it will expose their absence in an uncomfortably visible way. 

When SAP MDG is genuinely the right answer 

Assuming the groundwork exists, there are a few situations where MDG stops being one option among several and becomes the obvious one. 

You already run SAP 

The integration argument is not marketing. Master data governed in MDG sits in the same data model as the transactional system it feeds, using the same field definitions, the same check tables, the same customising. Nothing has to be translated or mapped at the boundary. Anyone who has maintained a middleware layer between a third-party MDM tool and an SAP backend knows exactly how much ongoing effort that boundary consumes — and how quietly it drifts out of sync. 

You don't run SAP ERP — and it can still make sense 

This surprises people. MDG can operate as a standalone governance hub, mastering records centrally and distributing them to whatever systems consume them, SAP or otherwise. The evaluation then comes down to whether the depth of its data model and rule engine justifies the licence against a lighter, more generic MDM tool. 

Sometimes it doesn't, and a simpler platform is the right call. But if your master data is genuinely complex — multi-plant materials, business partners playing several roles across legal entities — that complexity has to live somewhere. Generic tools tend to model it thinly, and the gap resurfaces later as custom development. 

You need to govern the process, not just the record 

This is the argument that gets least airtime and matters most. 

Master data governance is usually pitched as a data quality exercise: fewer duplicates, more complete records, better reporting. All true, all secondary. The real value is control over what the business is allowed to do. 

A purchase order should not be creatable against a supplier that hasn't cleared compliance checks. A sales order shouldn't be possible for a material that isn't released for that sales organisation. A material shouldn't reach a plant it was never extended to. Each of those is a governance decision expressed as a status on a master record — and enforced before the transaction, not discovered afterwards in an exception report. 

Framed that way, master data status becomes a control mechanism for the whole process chain. You're not cleaning data. You're defining what your organisation can and cannot execute. 

When the answer is no, or not yet 

There are situations where we say so directly. 

• Nobody owns the data. If master data is everyone's responsibility and no one's job, fix that first. It costs nothing and changes more than any tool. 

• The real problem is narrow. If eighty per cent of the pain comes from duplicate suppliers created because search is awkward, a governance programme is an expensive way to solve a findability problem. 

• The volume doesn't justify it. Governing a few hundred records created a year rarely warrants a platform of this weight. A clear process and a well-designed form may be enough for a long time. 

• There's no appetite for the rules. MDG works by making certain things impossible. If the organisation isn't ready to accept friction at creation time, the workflow gets bypassed and the investment is wasted. 

None of those are permanent verdicts. They're sequencing. Most companies that hear “not yet” from us are back within eighteen months, and the project goes better because the groundwork is there. 

The cost question, framed properly 

Cost comparisons in this space are usually misleading, because they compare the wrong things. 

Licence 

MDG typically carries a higher licence cost than a lightweight MDM tool, and a lower one than the large specialist platforms. But it's rarely a clean comparison: if you already hold SAP licences, part of the entitlement may be covered, and that changes the picture considerably. It's worth checking your existing agreements before assuming. 

Implementation 

This is where the real difference sits, and it runs in both directions. Implementing MDG on an existing SAP landscape is usually faster, because the data model, check tables and customising are already in place — you're configuring governance over structures that exist, not rebuilding them. Implementing a non-SAP tool into an SAP landscape is often cheaper to license and considerably more expensive to integrate, and that integration cost never fully goes away. 

The number that matters isn't licence or implementation in isolation. It's total cost over five years, integration and maintenance included — and, on the other side of the ledger, the cost of the transactions your current setup allows that it shouldn't. 

So how do you decide? 

Not from a vendor comparison chart. The useful sequence is narrower than that. 

Start with what actually hurts, in specifics: which records, which processes, which decisions go wrong and what that costs. Then establish whether you have governance capability today or need to build it. Then, and only then, ask which tool fits — by which point the question usually answers itself, because the requirements have become concrete. 

Skipping to the tool is what produces the pattern we see repeatedly: a well-configured system, a sound technical build, and an organisation that never adopted it because the groundwork underneath was never done.