SAP

Balancing the Business Partner / Party Concept

Henrik Gabs Liliendahl2 Comments

Since the birth of this blog one of the key concepts that has been repeatedly visited is the business partner / party concept in Master Data Management (MDM). This concept is about unifying the handling of data about customers, vendors, contacts, employees and other real-world objects that are all legal entities. One of the first posts from 16 years back was called 360° Business Partner View.

Since then, the uptake for this idea has been greatly helped by all the major ERP vendors over the years, as they have adopted this concept in their newer data models.

This is true for SAP, where the business partner concept was introduced as an option in the old ECC system and now has become the overarching concept is the new S4 system. The concept in S4 is explained by SAP here.

Also, Microsoft has adopted a party concept in their D365 solution. This is explained here.

The Technical Balancing Act

While the data models have been twisted to reflect the business partner / party concept in principle, there are still some halfway solutions in force.

For SAP some examples I have come across are:

  • The hierarchy management is for some purposes better suited for the business partner layer and for other purposes better suited for the underlaying customer or vendor layers, which are still there.
  • A real-world employee has at least two business partner records to work properly. This became the standard in the newest versions of S4 as the unified option had multiple challenges.
  • The main SAP MDM add on (MDG) still has a customer workflow side (MDG-C) and a vendor workflow side (MDG-V).

The Business Balancing Act

Though the technical uptake is there, the business uptake is slower.

In all the SAP and D365 renewal projects I have been involved in, there were concerns from parts of the business side about aligning sell-side customer-facing processes and buy-side vendor-facing processes and thus harvesting any business benefits around a unified handling of the two most prominent entities in the business partner / party concept.

The main reasons for the unified approach are:

  • You will always find that many real-world entities have a vendor role as well as a customer role to you.
  • The basic master data has the same structure (identification, names, addresses and contact data.
  • You need the same third-party validation and enrichment capabilities for customer roles and vendor roles.

The main arguments against, as I have heard them, are:

  • I don’t care.
  • So what?
  • Well, yes, but that is a thin business case against all the needed change management.

What are the pros and cons that you have experienced?

SAP and Master Data Management

Henrik Gabs Liliendahl4 Comments

SAP is the predominant ERP solution for large companies, and it seems to continue that way as nearly all these organizations are currently on the path of updating and migrating from the old SAP version to the new SAP S/4 HANA solution.

During this process there is a welcomed focus on master data and the surrounding data governance. For the technical foundation for that we see 4 main scenarios:

  • Handling the master data management within the SAP ERP solution
  • Adding a plugin for master data management
  • Adding the SAP MDG offering to the SAP application stack
  • Adding a non-SAP MDM offering to the IT landscape

Let’s have a brief look into these alternative options:

MDM within SAP ERP

In this option you govern the master data as it is represented in the SAP ERP data model.

When going from the old R/3 solution to the new S/4 solution there are some improvements in the data model. This includes:

  • All business partners are in the same structure instead of having separate structures for customers and suppliers/vendors as in the old solutions.
  • The structure for material master objects is also consolidated.
  • For the finance domain accounts now also covers the old cost elements.

The advantage of doing MDM within SAP ERP is avoiding the cost of ownership of additional software. The governance though becomes quite manual typically with heavy use of supplementary spreadsheets.

Plugins

There are various forms of third-party plugins that help with data governance and ensuring the data quality for master data within SAP ERP. One of those I have worked with is it.master data simplified (it.mds).

Here the extra cost of ownership is limited while the manual tasks in question are better automated.

SAP MDG

MDG is the master data management offering from SAP. As such, this solution is very well suited for handling the master data that sits in the SAP ERP solution as it provides better capabilities around data governance, data quality and workflow management.

MDG comes with an extra cost of ownership compared to pure SAP ERP. An often-mentioned downside of MDG compared to other MDM platforms is that handling master data that sits outside SAP is cumbersome in SAP MDG.

Other MDM platforms

Most companies have master data outside SAP as well. Combined with that other MDM platforms may have capabilities better suited for them than SAP MDG and/or have a lower cost of ownership than SAP MDG. Therefore, we see that some organizations choose to handle also SAP master data in such platforms.

Examples of such platforms I have worked with are Informatica, Stibo STEP, Semarchy, Reltio and MDO (Master Data Online from Prospecta Software).

While MDO is quite close to SAP other MDM platforms, for example Informatica and Stibo STEP, have surprisingly very little ready-made capability and methodology for co-existing with SAP ERP.