Skip to Content
Author's profile photo Former Member

MDM: Expectations v/s Realities

Master Data Management as a concept has existed as long as the ERP market or even before. The concept has been to help efficiently manage transactional and reporting functions within an application by having a separate repository for master data. The master data function gets called dynamically within the execution of a transaction.

This concept has evolved over the years, due to complexity of businesses and hence the IT Systems that are required to support it. In recent years the concept is gaining maturity by looking at Master data as a function to feed systems enterprise wide, not ERP alone. Hence MDM is now being viewed as a de-coupled application from the ERP applications.


Many vendors, some niche and other ERP vendors, have products to address this space. Though Gartner has reported the relative capability across various products in the ‘Magic Quadrant’, Consultants and Clients alike, are aware that none of the products have matured enough to warrant the name of ‘MDM Package Solution’. The products are still in the form of a tool/platform and a basic framework over which clients are expected to build a custom solution. Depending on what the client wants to achieve, the solution build up can be as expensive as a custom solution on any other platform.


SAP’s MDM product addresses master data across the enterprise like Material, Vendor and Customer. It also has certain content that is much suited for an SAP environment, hence there is good amount of data modeling effort that can be saved if the company has a SAP based landscape. These are some of the key differentiators for SAP MDM against other contemporaries.

The other features, like de-duplication, merging, harmonization etc are also part of the Product offerings.


However, the above alone does not make the offering a rich or a mature one. Today, the companies need to orchestrate and manage master data as a central application to the Enterprise. This needs a robust, user friendly and configurable package with a host of functionalities. The requirement from the Industry is the following:

  • User friendly screens
  • Complex validations that may need to be called from other applications
  • Easy to configure and
  • Manage workflows for data approval


What can SAP do to meet the above requirements with the current MDM package?

  • SAP needs to bring the Key components of Enterprise Portal and MDM together. This would mean that the configuration of screens and fields should be in sync and should not appear as two disjoint applications.
  • Since the companies preferring SAP MDM are predominantly SAP shops, SAP needs to have EP-MDM ready for an SAP landscape. The lead time to configure and set up a Central master data management should come down drastically. This will increase the adoption and usability of SAP MDM
  • SAP has tried to merge BO with SAP MDM, but these again should not be viewed and communicated as two different components. This should be communicated and projected as one single component. Currently there is a lot of confusion on what is the ETL recommended, is it of BOBJ or SAP MDM? These confusions in messaging adds to the reluctance in adoption
  • Workflow is a major component of central master data management. The workflow in some cases can be as complex as running across SAP MDM and SAP ECC or other SAP applications. This can be done using the new BPM, but this again needs to be offered as a part of the product.


SAP needs to work on maturing the product to make it a robust single unit, than expect customers to work on multiple components such as BPM, EP, Webdynpro and MDM to put up a MDM Solution. Essentially, the concept can be borrowed from ECC, where-in you have; Transactional processing UI; Configuration and Developer workbench. The skills required for the same are Functional and ABAP technical and it is easy to implement and use.

The skills required for setting up the current MDM solution –using number of SAP components- are too many and can act as a big entry barrier for larger customer adoption.


SAP needs to put in a lot of resources and get this going fast before customers start looking at other products to meet their MDM needs. Most of the vendors are just catching up and faster they move the larger the pie of the market they will acquire.

 Historically SAP has developed a number of products and matured it quickly to gain market share. The more recent example being CRM. I would still place my bets on SAP maturing the MDM solution to the leadership space of the Magic Quadrant.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Hi Ravi, Good Blog about MDM Realities, And I agree still SAP MDM needs to be matured to fit many real business requirments. In my project many extra buttons are pressed to enrich attribute for one record in Portal.
      Author's profile photo Former Member
      Former Member
      Author's profile photo Former Member
      Former Member
      I think SAP has a long way to go before MDM is anything like a mature product. The UI, functionality and integration with R/£ are three areas they should look at.

      What I've never understood is why we even consider taking data out of our ERP system in the first place.

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Robert, In very complex landscapes the dependency of enterprises on ERP alone is around 30%-40%. Sometimes even less. In such cases both from an IT landscape optimization perspective as well as from Consistency of Information perspective it makes sense to delink master data from ERP. This is the next level of maturity from an organization point of view. The first phase i.e. 90's saw an adoption of ERP, In this phase ERP was used for reporting as well. In the next phase early 2000 we saw reporting moved out for better analytics. The next phase is expected to be to move out master data. All this is to enable enterprise level consistency and reliability of information flow.