How to Understand Master Data Management for SAP

Executive Summary

• What Drove an Investigation into Master Data Management Solutions.
• What are the Common Problems with Master Data Management Solutions?
• Why do Some Vendors go to Such Lengths to Prevent People from Seeing the Solutions on their Websites?

What is MDM?

Master data management or MDM describes the approach for maintaining the master data of a system. SAP is made up of configuration and master data, which together form the body of the implementation. Master data exists whether transactions are processed by the application or not. Master data management is a combination of several areas of expertise, ranging from business logic to data management to specific tool knowledge. And this is one of the issues with mastering MDM in that it takes multiple people with different skills. MDM can be seen as the matrix organization of capabilities.

The History of Master Data Management Solutions

Master data management goes back to the beginnings of software. However, the topic became prominent from software vendors offering specific solutions to address MDM in roughly 2007. Software vendors offered many promises regarding how their solutions could help companies address the master data challenge. Examples of this are taken from a SAS paper on MDM.

1. “Start small and build out as necessary for reduced risk

2. Understand every aspect of your organization

3. Improve customer experience and reduce costs

4. Foster collaboration between IT and the business.

5. Gain a deeper, more complex view.”

The problem with MDM software is that it does not have a history of delivering what it says it does. In fact, from evaluating various MDM solutions, it was obvious that most of them did not have development teams that fully understood the multidimensional challenges of MDM. One of MDM software features is that it imposes its overhead onto a company, and many of the MDM applications have not been particularly impressive. SAP also offers MDM software. However, after a brief period where it was relatively prominent and received a great deal of marking a push by SAP, along with the rest of the software vendors and the MDM software market, there is now much less emphasis on MDM are few successful MDM implementations. MDM has fallen to such a degree that searches into Google with MDM no longer return any results for “master data management” as they would have several years ago, but now return results for “mobile device management,” a new hot technology.

The Problem with MDM Projects

I have observed an enormous amount of money spent on SAP’s MDM software on several projects now. However, never on any of these projects have I observed any positive output from the MDM project for the client or the supply chain systems that I support. SAP MDM starts with many promises but then seems to fade away, and then the project is left with the same MDM problems as it always had, but with less money to fix the real issue. Furthermore, the term MDM is now being used as a band-aid on projects instead of focusing on the basic blocking and tackling of master data.

Where is the Education on Master Data?

I also find it quite surprising how little the major consulting companies and SAP seem to be educating clients about the real issues around MDM. That is the need for discipline, to connect accountability to responsibility, and to refrain from practices that, while they feel good in the short-term (such as making master data changes in response to operational needs), end up undermining the integrity of the system.

MDM is More About the Method

I have experience maintaining master data and using a spreadsheet for analysis and mass update function in SAP to permeate the changes I want through the system. This type of work does not appear to require a software solution. SAP needs to add, which would allow me to understand better what master data is in the system, is better tools for querying. However, that is a long-term ERP weakness since its inception, and it seems unlikely they will add that functionality.

Misapplied Software

Another issue with SAP MDM is it is misapplied. SAP MDM was designed to synchronize master data for two SAP ERP systems, but that is not how it is proposed to clients (because this is a much smaller potential customer base). I have written more on this topic at this link.

How to Undermine Master Data

There is a phenomenon, which I have observed on projects for some time now. This is the trend of Master Data Management or MDM for short. Now master data has been around since the beginning of computers. Most companies do not manage their master data very well, or should I say invest anywhere near as much in it as they do in either application integration or new software implementation. The new focus has been on developing software solutions to the master data problem. All the major vendors have an MDM solution, although the most popular of the MDM tools is SAP’s MDM.

Strangely, no one seems to either know or point out that SAP MDM is designed to synchronize master data between two ERP instances, and it not a “generalized MDM solution.” There must be a magazine that all the MDM consultants subscribe to because MDM consultants seem to have agreed that they will use a few proven techniques:

• Categorize things as “MDM.” This gives a certain sage quality to the consultant. Executives have also begun to pick up this habit, and in meetings, as soon as an item has been identified as MDM, there is a bit of an implied understanding that it is all taken care of. After all, the MDM project will handle that.
• Repeat the word “taxonomy” as frequently as possible. For an unknown reason, using the word taxonomy has a strange hypnotic effect on clients that makes them want to give money to consultants. Unknown to many, the term taxonomy means (the branch of science concerned with classification). However, clients will not pay as much for using other words, such as product hierarchy.
• While billing many hours to clients for MDM, neither the major consulting companies nor the software companies seem interested in actually educating their clients about the basic blocking and tackling of master data management. This, I believe, is rooted in their message that MDM is about software. Plus, neither consulting companies nor software companies want to discuss the most political aspects of master data management, such as who will be locked out of the update of objects. Why, when you can show a demo of how your software can clean up address fields?

Using a word that means classification to impress clients shows how bankrupt current MDM consulting is. Should vendor and consulting company MDM be Confused with Real MDM? In a word, no. Master data management itself is no joke. While it may be simply a way to make a fast buck for consulting companies that have every intention of wasting client’s money, it is crucial to obtain correct output from computer systems. However, the approach taken by the major vendors and their large consulting companies (which serve as nothing more than representatives of the major software companies) to try to propose a software approach to the master data management problem is completely counterproductive. It will not result in positive output for clients. If you want good master data for your system, you must ensure the following:

• You have or create an offline (non-operational) group that can evaluate requests for master data changes within the overall system context.
• Periodically review your master data and make sure things like lead times reflect the reality of the business.
• Have mass change capability within the master data team to permeate planned changes through the system.
• Have a well thought out permissions model that strongly aligns responsibility and accountability
• Continually perform housekeeping on your system and archive objects that no longer need to be in the production system.

Emphasizing the Right Things for Master Data

The best analogy I can come up with is that master data management requires investment and constant vigilance. Thus it is similar to exercise. What that major software vendors offer is a quick fix, a diet pill, or infomercial exercise equipment. Clients should not allow themselves to be deluded by IBM, Accenture or SAP, or any other company attempting to sell in a major MDM project or application. No particular tool is needed for MDM.

How to Improve MDM

What was missed by software vendors is that MDM is less about a particular tool than about a process that may leverage some tools. The tools – often spreadsheets or databases, may be changed depending on their preferences and skills. The important features of a robust MDM approach would include the following:

1. Role Assignment: The business has the domain expertise to know what many master data fields should be. They do not have all of the expertise, as is often conjectured, because there are some master data that requires particular expertise that does not exist in the business at the particular company. A good example of this is some of the master data parameters for the supply chain. In a supply chain setting, a lot size or safety stock can be set “locally” that is set only considering the implications on the particular product and location or can be adjusted according to the overall number of product locations in the system. Therefore a company may have an overall inventory value that seeks to maintain, and setting inventory parameters individually may cause the company to exceed this stock cap. The business certainly knows what these fields should be better than IT, but that does not mean that they know better than an inventory management specialist. Also, the business will often disagree with what different master data fields should be. The answer depends on the person queried and in what area of the business the person works. So in the example of lot sizes, it’s incomplete to state that “the business knows” what the right value is for, say production or ordering lot size, because inventory management and manufacturing will most often come to different conclusions best lot sizes are. In these situations, the lot size field can be assigned to inventory management or allocated to manufacturing, or determination of the field’s quantity can be determined through a negotiation between the interested groups. Once the business’s disagreements are put to one side, the next important topic related to role assignment is who provides the input versus who makes the change. In some cases, such as creating purchase orders, the users create the purchase order. However, a purchase order — as with all transactional objects, calls upon stored master data (and often manually entered master data) to complete its fields. In other cases, such as with creating new master data objects, such as with vendors, the new provider may be created by an IT resource but with input from a business resource. The fact that assignments of new master data creation cannot directly be assigned to one group and crosses over into different people and departments in the business and between business and IT overall is one of the complicating factors in master data management. This is just one example of why MDM can never be addressed through a software solution.
2. Knowing the Right Systems to Use for MDM: SAP is not the best system to maintain as the record system for all master data. For instance, the BOM in SAP does not include all of the fields that make up the BOM or many of the revisions to the BOM – these are better managed in an external system, often a BOM management system.
3. Documenting the MDM Change and Update Dependent Logic: Master data, particularly in a system as complex as SAP is that, is dependent upon other master data. When a new transactional object or master data object is created, there are many dependencies required to be respected. A failure to recognize these dependencies will lead to errors that will plague a company with constant issues. Too often, fixing these issues is performed in isolation and done after the problem arises without developing a systematic approach to documenting the master data logic. The creation of new transaction and master data objects is performed with high quality leading to very few errors.
   1. Field Logic and Interactions: Each field has a particular number of interactions with both application logic and other areas. What each field do, as well as its interactions, need to be documented? This can mean a table that shows the area and a column for each field that it interacts with.
4. An Intelligent Creating Process: SAP contains many areas of master data maintenance within its applications. However, to leverage this functionality, planning must be performed to determine both what to use and how to train those to use these features properly. For instance, templates can be created for both transaction and master data objects that allow new objects to leverage foregoing objects’ configuration. The following provide specific examples of this functionality.

This is the create PO transaction. Within this transaction, one can save and load from a template. Each of these templates has different fields populated with various values. Creating a template is a great time-saving activity, which also increases data quality.

Here are the fields that auto-populate when one chooses from a template. Understanding the business settings can help determine how many PO templates should be created.

Planning Reference Objects

This same copy ability applies to sales orders, materials, etc.… When an object is created based on another object, this paper will refer to this as the reference object. Therefore to gain efficiency and quality, it is necessary to plan out the reference objects. SAP can allow any number of reference objects.

Mass Review and Update

One problem that companies get into is only updating master data for individual items. This can be done quickly, but it often prevents them from seeing the overall picture and how the values hang about one another.

For instance, changing lot size on a product/location by product/location basis. SAP has a transaction, which allows for data to be both reviewed and updated as a table rather than updating items “one at a time.”

MASSD is a transaction that allows you to view and change fields in spreadsheet format.

The fields from a master data category can be brought up into the view to be changed. Values can be found, and things like blanks can be filtered.

Conclusion

MDM is a combination of approaches that result in a better ability to leverage a system’s capabilities. MDM is not on a particular method or tool and is integrated across the organization. Because of the multidimensional aspect of MDM, it is easy to underestimate the challenges of MDM. I have never seen a company get MDM completely right; it is more accurate to say that corporations reside on a continuum from quite poor MDM to reasonably good MDM. The most important aspect to mastering MDM is understanding its multidimensional nature and addressing MDM in a multifaceted way.

References 

https://www.sas.com/content/dam/SAS/en_us/doc/factsheet/sas-master-data-management-105360.pdf