Skip to Content

Applies to:

SAP MDM 7.1

Summary:

Product Master Data Management has been well known as a solution to create single source of truth about Product Information across the enterprises. Although when Product MDM solution gets deployed, it hardly remains as pure Product MDM solution over the period of time. But rather it gets contaminated with non-master data components. Over the period of time organizations do not realize the degradation of the MDM solution in terms of expected value addition due to this non master data contamination.

It is critical that policy is clearly defined at the time of deploying Product MDM solution around the possible contaminations and how to safe guard the future. This document talks about as how SAP MDM can be used to support this objective by doing modular Product MDM solution.


Author: Ajay Vaidya

Company: Tata Consultancy Services

Date: October 2014

Author Bio:

Ajay has been associated with Tata Consultancy Services (world-leading information technology consulting, services organization). He is handling the responsibility of Head of Product MDM Practice in TCS.



Context

Product Master Data Management has been around for a decade now. Many organizations know the importance of Product MDM and many of them have realized the value over last decade.

Product MDM plays a key role in architectural building block for organizations enterprise architecture. This architecture building block has specific key role of managing and providing single version of truth about Product Master Data.

Although when the architecture comes to reality in terms of implemented systems and processes, the role of Product MDM gets compromised due to various environmental reasons. If proper care is not exercised, very soon over the period of time, the Product MDM solution loses its value as MDM and eventually creates data management challenges.


This paper talks about the challenges and how to manage these challenges or reduce the risk by using SAP MDM.

What is Product MDM and what it is not

Product MDM solution contribute tremendous value to organizations as long as it remains in it “pure form”. Product MDM solutions are supposed to provide single version of truth about Product Master Information across the enterprise.

It is implicit that Product MDM solutions handle “Master” data only. As a broad category, Master data is the one which is important across the organization, shared and used across the enterprise. Product “Transactional” and “Analytical” information do not qualify to be Master Information.

In any enterprise landscape, it is quite natural that transactional, master and all other types of information are present and required to perform specific set of objectives. Although it is necessary to have solution to keep distinction between master information and other types of information very clearly, not only in terms of identification but also in terms of management.

MDM Separation.jpg

Following diagram illustrates “a typical” logical view of the IT landscape. Product Master Data is decoupled from “Transactional” and any other data types. Product “Master Data” sits at the beginning of the information value chain. The information value moves from Product “Master data” to “Transactional Data” to “Analytical Data” to advanced analytics related data elements.

MDM Landscape.jpg

As illustrated, Master Data is decoupled from Transactional and Analytical data. Transactional applications consume Master data and generate Transactional Data. Whereas Analytical systems consume and aggregates Transactional Data along with Master Data as source of dimensions for analysis.


Challenges of mixing Product Master and Non Master Data

Broadly at the beginning of any Product MDM initiate, Master Data definitions are created. This process is complex and involves multiple stake holders to build consensus around common agreement on Product Master Information elements (data elements) and “context” for the usage of various Product Characteristics (attributes).

During this consensus building process it is natural that compromises are made on the “contextual” definition and usage of Product Master Data. Some of the compromises are:

  1. MDM simply acts as a system of reference. System of record would be some other source systems.
  2. Redundant characteristics / attributes are required to be maintained for simplicity of stake holders ease of use.
  3. Some key Master Data characteristics are not migrated to MDM due to complicated integration architecture. But typically these kinds of exceptions are resolved over the period of time and moved to MDM eventually.
  4. Non Master Data characteristics are maintained along with Master Data elements within MDM solution itself. This is like a cancer which spread unnoticed.

The forth aspect is more common to accommodate practical requirements, including inflexibility of existing IT landscape and budget constraints. In such cases architectural decisions are made by enterprise architects and MDM data stewards that MDM system will hold non Master Data characteristics only for certain period of time.

However almost in all cases, the time never comes in future when these non-Master Data elements are moved out of MDM systems. On the contrary, this non Master Data elements contamination goes on increasing over the period of time. At certain point in time, Product Master Data solution loses its value considerably. Subsequently it becomes challenge to manage Product MDM solution itself rather than focusing on providing value to business from Product MDM solution.

Following are some of the challenges organizations see when the Product MDM solution reaches to the limit of becoming invaluable due to contamination.

  1. Stake holders built up wrong expectations from Product MDM solution. For example, demands are made to create single version of truth which does not fall under the preview of MDM solution.
  2. Focus shifts to make Master Data solution into Transactional solution. For example, data steward efforts are spend in gathering, correcting and providing transactional information to various stakeholders and downstream systems.
  3. Key Master Data never remains current and updated. This creates further challenges in terms of organizational key operations including Sales, Order Management and fulfillment.
  4. Organization loses “trust” in Product MDM solution leading complete failure.

Modular Product Master Data using SAP MDM

Product MDM contaminations cannot be avoided. Therefore organizations need to prepare as how they handle the Product MDM solution. Decisions need to be made at the beginning on the policy of MDM solutions and scope. More important MDM solutions should be designed in such a way that in future Product Master Data contamination can be removed and decoupled from pure Product Master Data.

MDM Model.jpg

Above figure shows a simplified view. There are few core Master Data characteristics like dimensions, description, identification etc. Whereas some non-Master Data characteristics are considered like Sales Price (which is an extreme case of non-master data), Inventory status and Supplier status flag. These non-Master Data characteristics ideally should be maintained outside of MDM system. But practically these characteristics contaminate MDM system.

Separate out these characteristics in MDM data model representation as described. The core Master Data characteristics remain as part of core Product element. Whereas non Master Data characteristics are moved to AddOn data element. Also these two elements would have their own hierarchy elements to keep it distinct.

There could be and would be much more complicated Product data characteristic including complex relationships and multi occurring attributes and groups. For sake of simplicity only few simple attributes are considered for the example.

In future, over the period of time such AddOn elements can be removed all together without impacting the core Product data elements and other associated functionalities like syndication.

Following section shows the screen shots of defining these data elements in SAP MDM and generating export for the various downstream systems and stake holders. When AddOn elements are removed the core data elements and other supporting functions structure (like Syndication in this example) remains clean without impact.


SAP MDM defining modular Product MDM solution

This section illustrates simple configuration as one example of separating out the Product Master Data apart from non-Master Data elements. Primary reason for Product Master Data contamination is because of the critical Product data demands from downstream systems. Therefore this section also provides simple illustration of Product data syndication including Product Master Data and non-Master Data elements.

DM1J.jpg

Product MDM defines following components.

  1. Product : Primary Product information catalog
  2. ProductsAddOn : Product catalog to hold add on (non Master Data) information
  3. Categories : Primary Product hierarchy
  4. AddOnCategory : Flat hierarchy to hold AddOn Product information.

DM2J.jpg

Products element defines various Product Master Data characteristics and a reference to another catalog (ProductsAddOn) which holds non Master Data elements.

DM3J.jpg

ProductsAddOn element separates out non Master Data characteristics which are supposed to be removed from MDM in future. This separation helps to remove the non-Master Data elements with no or minimal impact.

Data1J.png

Each primary Product Master Data information has associated non Master Data information as well.

Both of this Product information can be syndicated together to various downstream applications and systems. For those systems and applications it is transparent as how the Product Information (both Master and Non Master) is modeled.

SY1J.jpg

For syndication, source Product Information is split across two distinct elements but for downstream systems it is a single set of information.

SY2J.jpg

For simplicity, Product Information is syndicated in terms of text flat file format in this example. As illustrated, the exported file contains all the Product information including Master and non-Master information. Downstream systems are unaware as how MDM solution is structured internally making it flexible to separate and remove non Master Information easily in future.


Summary

Product Master Data contamination is inevitable. Rather than waiting for the disaster to happen over the period of time when Product Master Data solution loses its value, organizations can take proactive steps to make modular architecture and design of the MDM systems. This enables to keep the MDM systems clean of non MDM information contamination and retain the value of the Product MDM solution.

SAP MDM provides ability to do modular MDM system design to make it flexible for such changes to be accomplished in future lifetime of the MDM solution.

Related Content

SAP MDM Console Guide

SAP MDM Data Manager Guide

Key Capabilities of MDM

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply