·
8 min
Material or Business Partner: where SAP MDG projects really get hard
Material and Business Partner look like the same kind of problem. They aren't. One is a fight over agreement, the other over definition — and planning them the same way is why MDG projects slip.
Most SAP MDG programmes cover Material and Business Partner. Most of them are planned as if these were two instances of the same task: model the object, define the rules, build the workflow, repeat.
They aren't the same task. They get hard in completely different places, for completely different reasons, and the effort that made the first domain succeed is often the wrong effort for the second.
The mistake that sets projects back
A team finishes Material. It went reasonably well. The blueprint took longer than planned but the design held, the workflow works, the business adopted it. So Business Partner gets scoped by analogy: similar duration, similar team, similar approach.
Then the first workshop happens and someone asks what a business partner actually is. Three hours later there are four incompatible answers in the room and no decision. That question never came up for Material, because everyone already knew what a material was.
That's the difference in one sentence: in Material you're negotiating who controls the data. In Business Partner you're negotiating what the data even represents.
Material: the fight is over what “common” means
Material data splits cleanly in two. There are basic fields shared across the whole group, and there are fields that belong to a specific plant, sales organisation or company code. The technical split is obvious. The organisational one is not.
Common data belongs to the group, not to the plant
This is where Material projects lose their weeks. Basic data has to be agreed by everyone — every plant, every company, every country. And each of them has spent years treating those fields as theirs, because in practice nobody stopped them.
Asking a plant to accept a group-wide definition of a material type, or a base unit of measure it didn't choose, isn't a data modelling exercise. It's a negotiation about autonomy, and it goes exactly as slowly as that sounds. The technical work is trivial; getting the agreement is not.
One hierarchy, not four
Classification and hierarchies deserve special mention, because this is where the negotiation becomes explicit. Sales wants a hierarchy that reflects how they sell. Marketing wants one that reflects how they position. Purchasing wants one that reflects how they buy. Each is legitimate on its own terms.
But governed master data needs one hierarchy, maintained once, that everyone lives with. Deciding whose logic wins — or designing a structure that serves all three without becoming unusable — is one of the hardest conversations in the whole programme, and it cannot be delegated to IT.
Units of measure, quietly
Base units and alternative units with their conversion factors look like a configuration detail until they aren't. They propagate into pricing, planning, logistics and stock valuation. Get them wrong at group level and the error surfaces months later, in a place nobody connects back to master data.
And then the local data, which really is wide
Once the common layer is agreed, the plant and sales-organisation data arrives, and here the breadth is real. What matters is that the rules aren't uniform: a production plant, a distribution centre, a sales-only company and a financial entity need genuinely different fields, with different mandatory logic.
The design instinct should be to simplify — govern less, not more — with one non-negotiable premise: whatever you leave out must not stop the transactional process from working for that specific entity. A rule that's elegant at group level and blocks a plant from issuing goods is not a good rule.
Business Partner: the fight is over what a BP even is
Business Partner has fewer fields than Material. It's still usually the harder domain, because the object itself is contested.
Ask ten people, get ten answers
Try it in a workshop. Is a business partner the entire corporate group, including every tax ID it holds in every country? Is it one BP per country, with a hierarchy linking each local entity to a global parent? Is it the legal entity? Is it the individual store?
Retail makes this vivid. A large chain with hundreds of outlets: one BP for the brand, one per legal entity, or one per store? Each store has its own delivery address, sometimes its own ordering behaviour, sometimes its own invoicing. If the answer is one BP per store, you've effectively decided that a business partner is a delivery address rather than an organisation — which is a defensible choice, but a choice with consequences that reach into pricing, credit management and reporting.
So what counts as a duplicate?
The definition question immediately produces a second one. If the same corporate group exists as five BPs across five countries, is that duplication or correct modelling? If a customer appears twice with two delivery addresses, is that one record with two addresses or two records?
Most organisations end up accepting deliberate duplication along one axis — usually country or legal entity — while forbidding it along others. That's a reasonable outcome. What isn't reasonable is discovering the rule halfway through building the duplicate check, which is when it's usually discovered.
Roles: one entity wearing several hats
Only once the object is defined can roles be assigned. And the same partner is frequently a customer and a supplier at once, sometimes a competitor as well.
For teams migrating from separate Customer and Vendor masters, this is the conceptual break. The data model handles it. The organisation often doesn't: two different departments have maintained that partner independently for years, with different data, different processes and different ideas of who owns it. The model has to support the overlap, and so does the governance process — including who approves what when a record carries both roles.
Company code and sales area: same fields, different worlds
Then Business Partner meets the same problem Material had, from the other side. Company code and sales area data uses the same fields everywhere, but the values and rules shift by country: fiscal and legal requirements, payment terms, withholding, commercial agreements, local reporting obligations.
It looks like one design. It's really as many variants as you have countries with meaningfully different rules, and it needs to be treated that way in the plan.
Two domains, two kinds of difficulty
Material is a problem of agreement. The object is understood; the difficulty is getting many entities to give up local control over shared fields, and then handling genuine breadth in the local layer.
Business Partner is a problem of definition. Once defined, the rest follows reasonably well — but that definition is a business decision with commercial and legal consequences, and it can't be resolved in a technical workshop.
They need different people in the room. Material needs plant and supply chain representation with authority to concede. Business Partner needs commercial, legal and finance early, before a single field is modelled.
What this means for planning
Practically: don't size the second domain from the first. Budget definition time for Business Partner as a distinct phase rather than folding it into blueprint, and expect the local-variation work in Material to be wider than the field list suggests.
The reassuring part is that the platform isn't the constraint. MDG scales to whatever model you land on — one BP per group or one per store, one hierarchy or a controlled few. What determines whether the project runs to plan is how early those decisions get made, and by whom.
Planning an MDG programme across Material and Business Partner? At JA2E we help define the model before building it — the definitions, the hierarchies, the role logic and the local variation — and then implement it. Start with an assessment and we'll tell you honestly where the hard parts sit in your case.