What This Article Covers
- 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 as well as 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 the perspective of software vendors offering specific solutions to address MDM in roughly 2007. Software vendors offered a great deal of promises regarding how their solutions could help companies address the master data challenge. Examples of this are taken from an SAS paper on MDM.
- “Start small and build out as necessary for reduced risk
- Understand every aspect of your organization
- Improve customer experience and reduce costs
- Foster collaboration between IT and the business.
- 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 very clear that most of them did not have development teams that fully understood the multidimensional challenges of MDM. One of the other features of MDM software 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, and there are few successful MDM implementations. MDM has fallen to such a degree that searches into Google with MDM no longer return many 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
On several projects now I have observed an enormous amount of money spent on SAP’s MDM software. However, never on any of these projects have I observed any positive output from the MDM project for the client, or for the supply chain systems that I support. SAP MDM starts with a lot of 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 the focus being 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 as to the real issues around MDM. That is the need for discipline, to connection 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 in undermining the integrity of the system.
MDM is More About the Method
I have experience with maintaining master data and using a combination of 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. One thing that 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 weakness of SAP since its inception, and it seems unlikely they will add that functionality.
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 being 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, and 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 as been on developing software solutions to the master data problem. So 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 pickup 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, use of 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 the use of other words such as product hierarchy.
- While billing a lot of hours to clients for MDM, neither the major consulting companies nor the software companies seem interested in actually educating their clients as to 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 just means classification as a way 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, and 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 and critical to obtaining 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 and will not result in positive output for clients. If you want good master data for your system, you must simply ensure the following:
- You have or create an offline (non-operational) group that can evaluate requests for master data changes within the context of the overall system.
- 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 so that planned changes can be permeated 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 are offering is a quick fix, or 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 which may leverage some tools and that the tools – often spreadsheets or databases, may be changed depending on the preferences and skills of the company. The important features of a robust MDM approach would include the following:
- Role Assignment: The business has the domain expertise to know what many of the 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 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 say an inventory management specialist. Also, the business will often disagree to what different master data fields should be. That is 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 as to what the 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 quantity of the field can be determined through a negotiation between the interested groups. Once the disagreements between the business 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 with 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 the creation of 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 that it 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 why MDM can never be simply addressed through a software solution.
- Knowing the Right Systems to Use for MDM: SAP is not the best system to maintain as the system of record 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.
- 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 a tremendous number of dependencies that are 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 so that the creation of new transaction and master data objects is performed with high quality leading to very few errors.
- Field Logic and Interactions: Each field has a particular number of interactions with both application logic as well as other areas. What each field does as well as its interactions need to be documented? This can mean a table that shows the area along with a column for each field that it interacts with.
- 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 the configuration of foregoing objects. 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 from 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, to 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 for 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.
MDM is a combination of approaches that results in a better ability to leverage the capabilities within a system. 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.