First, What is Master Data
Once the explosion of SAP ERP occurred and there were numerous business technology systems managing all aspects of the modern company. An emerging concept began, the system performance is only as good as the data that gets pumped through it. There are a few different analogies but I like to think of the body analogy. If all the aspects of a companies business software landscape make up the body, the blood that is required to pump through to all the different functions is the data. If the data is bad the whole system begins to crumble similar to how a body can’t function without blood.
The success or failure of a business technology landscape hinges on the quality of it’s data, in particular its master data. What exactly is master data? The concept is that there are different categorizations of data that exist in ERPs
- Reference Data (fairly static and infrequently changed. In an SAP concept reference data requires a transport to move from dev systems through to prod systems)
- Examples: Organizational Structures of ERP (Company Codes, Sales Organizations, Purchasing Organizations), Key Fields that categorize data (Material Types, Customer Account Groups, Vendor Account groups), Drop down values for fields (list of countries available, payment terms)
- Master Data (relatively static but subject to change more frequently than reference data. Master data is usually used in business transactions that occur frequently such as sales orders/purchase orders. This data does not get transported from a development system to a quality system. Instead it is maintained directly in each environment)
- Examples: Material Data, Customer Data, Supplier Data, Profit Centers, Cost Centers
- Conditional Data (More subject to change and links existing master data)
- Examples: Purchase Info Record (Linking Material & Supplier), Customer Material info Record (Linking Customer & Material), Pricing Condition Records (based on existing data determining the pricing on documents)
- Transactional Data (typically not reused, used for a single business transaction, uses data from existing master data & conditional data)
- Examples: Sales Orders, Sales Contracts, Purchase Orders, Purchasing Info Records, Planned Independent Requirements
Now let’s focus in on that master data, which is customer/suppler/material as the key objects in a typical company. If there is a mistake on this data it is used throughout the entire ERP system incorrectly. For example, every sales order that has a customer address that is incorrect could be disastrous in terms of shipping product to the wrong location. Imagine your material has the wrong material resource planning settings, this could lead to supply shortages impacting your business. To add to the complexity, usually there is no single person in an organization that can provide all the data needed to create a new material, supplier or customer. The data for each of these objects is categorized under different functions such as sales related data, purchasing related data, planning related data, financial related data etc. This requires multiple users to go in an update the data to finalize the master data. Now let’s get into how this problem was historically handled.
SAP Data Management & MDG History
This problem of having a complex master data object that required multiple business units to talk to eachother to create led to unharmonized processes that were prone to incomplete data being created in the system. Additionally, there were usually multiple ERPs managing a business such as one per business unit or perhaps one per region leading to potential overlap in master data that was shared. The first wave of master data tools focused around the problem that there needed to be a single consolidated view of a businesses customers/suppliers/materials that could be used to feed reporting apps for example. Additionally, some applications needed a unique set of master data. This led to the emergence of master data tools related to consolidation.
Master data consolidation was the concept of ingesting data from disparate sources, standardizing the data, de-duplicating the data, providing a mapping of which products are the same but in different systems (key mapping) and allowing a rich database of clean data to be used by other applications
The emerging tool was actually not an SAP tool but a tool by a company A2I that wasn’t built on the underlying programming language of SAP (ABAP) and was initially more of a product content management tool. SAP purchased this company an integrated it into the SAP Netweaver products and marketed this tool as SAP Netweaver MDM. The primary purpose of MDM initially was a consolidation engine which allowed key mapping, de-duplication, cleansing, enriching data & allowing distribution of the cleansed data.
SAP Netweaver MDM also emerged with a product that allowed central master data creation & distribution which was the emerging trend that instead of cleansing data on the backend there should be a single global system that manages master data on the front end and delivers clean harmonized data to all systems that need master data. This concept is where a new product SAP MDG shined.
SAP MDG was a native ABAP program that was developed by SAP as the next generation of data management. The SAP MDG tool called SAP Master Data Governance is unfortunately actually a master data management tool. However the MDM name was taken which is my guess for why it is marketed as MDG. SAP MDG solved the typical MDM problem of data creation centrally
How did MDG Solve the problem of central data creation?
The typical concept of central data creation is that there would be a separate flexible database that you would model as a collection of the requirements of all the downstream systems that needed data. You would make master data forms that a user can fill out along with workflow capability to go to the various departments that need to fill in master data. After all the data was populated it would be syndicated to the downstream systems that needed the data.
The key issue, is that now you have two versions of the truth for your data needs. You have a separate database that has it’s own rules for what is mandatory, and the available checks for the master data vs your downstream application which could lead to failures. For example, if in a downstream system if you populate the country field the region field is mandatory but in your MDM system you missed this check (since it was recently implemented on the target system) then you would have failed master data. The system where checks and validations for master data are stored & your initial application for master data creation are in a constant need of being in synch. Then you have to build interfaces and tools and manual processes to make sure whenever you change a data requirement in a target system, that change gets developed on your MDM system.
Especially with a growing presence of companies that relied mainly on SAP application (which have a lot of complex and not easily understood data validations) it became a lot of effort to spin up MDM applications that could centrally manage and distribute this data.
Along came SAP MDG , this tool in theory can be used to create new flexible MDM objects (although not as easy as other MDM tools) it’s main focus and solution is that since it is a native SAP product it built functionality in which it reuses the data model of the standard SAP application & it imports all the same checks and validations as the standard application.
The beauty of MDG is the following
- The list of required/optional/display fields in the underlying SAP application natively are read by SAP MDG in it’s staging area tables. So if you change a required field in your SAP, immediately it is a required field in MDG. No more mismatches (When MDG is deployed on top of your SAP or S4 which is a topic of another discussion)
- The drop down values available for fields in your fields in your underlying SAP application automatically show in your SAP MDG application. For example, if you add a new payment term to SAP automatically in SAP MDG staging tables when you go to add a payment term that new value is available
- Since MDG sits right on top of SAP there is no interface to activate the master data, There is a staging area where there is a workflow and users can update the master data and once the activation button is set the system automatically creates the record through native code and not an interface.
The drawbacks of SAP MDG
- Since it’s native SAP built, the same complication of screen and fields that users face in SAP is there in MDG. There isn’t much of a more user friendly limited form based screen like you create on native MDM applications. It is possible to remove fields from the screen and adapt it but it isn’t super user friendly to do so
- Adding custom fields to MDG isn’t as simple as other native MDM applications where everything is a custom field. Here because there is the integration with the underlying application it is a bit more complex when you’re designing custom fields
- If you want the SAP to be a true hub application that feeds multiple systems including non SAPs, users need to be very familiar with the SAP screens and concepts in order to manage data for other applications.
- If you want SAP MDG to be the hub you also lose a lot of your native synchronization with the underlying SAP since you will want two SAP systems, one system that is just the MDG and one system that actually manages your operations (more on this when we get to MDG architecture options). This means you need to keep two SAP systems in sync now to get those same native SAP benefits