What’s the difference between Master Data Management (MDM) and Master Data Governance (MDG)?
Master Data Management defines the discipline and approach of managing master data in a company. SAP Master Data Governance relates to SAP’s product portfolio for master data management as outlined in the MDG documentation landing page. This FAQ page specifically relates to SAP Master Data Governance on SAP S/4HANA.
Please note that there is an extra page for FAQs about the complementary SAP Master Data Governance, cloud edition.
Sometimes you might see the term MDG-M or MDG-S, etc. These are just acronyms for the product name “SAP Master Data Governance for Materials” = MDG-M or “SAP Master Data Governance for Suppliers” = MDG-S. Other acronyms can be MDG-F (financials), MDG-C (customers), MDG-EAM (Enterprise Asset Management), MDG-CO (customer specific objects), MDG-RFM (Retail and Fashion Management). The MDG key functionalities are workflow-based master data creation, master data distribution to SAP and Non-SAP Systems, mass changes, duplicate checks, data quality monitoring, rule mining, workflow monitoring and master data consolidation.
What’s the difference between Master Data Integration and Master Data Management?
Master Data Integration is about distributing master data based on SAP One Domain Model for a harmonized view across all applications in hybrid landscapes. Companies expect a broad domain coverage for end-to-end process integration. According to the SAP integration strategy for hybrid and cloud landscapes, this is planned to be provided by SAP Master Data Integration services.
Master Data Management ensures sustained high quality for trusted master data across the enterprise. Companies prioritize quality for selected domains according to business needs. According to the SAP strategy, this is provided by SAP Master Data Governance.
See also the
SAP Community blog post that deals with this question.
Is there roadmap information available about SAP Master Data Governance on SAP S/4HANA?
Roadmap information for all MDG deployment options is available on the
SAP Roadmap Explorer. For details about SAP Master Data Governance on SAP S/4HANA 2023, see this
blog post.
What is SAP MDG from a technical perspective?
SAP MDG is technically based on a SAP S/4HANA system or alternatively on an SAP ERP system (SAP ECC). That means many standard functionalities of an SAP S/4HANA or SAP ERP system is being reused by SAP MDG, e.g. user and authorization concepts, operational aspects like high availability and security, customizing (i.e. configuration of the system), user interface technologies (SAP FIORI) etc. Master data functionality can be activated and configured in these systems. Please note that activation requires an SAP MDG license. According to SAP’s S/4HANA strategy, continued innovation on SAP Master Data Governance on SAP S/4HANA has outpaced the developments made for the product version on SAP ERP.
Is SAP MDG a dedicated separated system?
SAP MDG can be deployed in 2 ways: “co-deployment” and “hub deployment”.
Co-deployment: SAP MDG functionality is activated in a system that is also being used for transactional processes like order-2-cash or procure-2-pay.
Hub deployment: SAP MDG is deployed on a dedicated SAP S/4HANA instance which only runs master data processes. SAP MDG Hub will distribute master data to all other systems in the system landscape. This means all master data objects are stored several times: SAP MDG stores the “golden record” and transactional systems (=client systems) stores a local instance of this golden record to run processes locally.
What master data objects does SAP MDG support out-of-the-box?
SAP MDG supports the following objects out of the box, i.e., staging tables, user interfaces, validations and distribution capabilities are available for them. All standard content can be adapted to a customer’s specific need. Customer specific fields and segments can also be added to these standard data models. Even customer specific master data objects can be managed in MDG. The SAP MDG framework offers this option by standard (“Custom Object”).
- Material master with basic data incl. classification, documents, plant, sales, storage location warehouse and valuation data
- Financial master data: G/L accounts, chart of accounts, company, financial reporting structure, Cost Element, Cost Element Group & Hierarchy, Cost Center, Cost Center Group & Hierarchy, Profit Center, Profit Center Group & Hierarchy, Internal order, Consolidation Unit, Consolidation Group & Hierarchy, Consolidation Characteristic, Item & Hierarchy, Breakdown Category, Breakdown Category Set, Cause for Submission, Transaction Type, Business Partner with relationship, role, bank details, identification, address and tax numbers
- Customer incl. general data, sales area and company code specific data
- Supplier incl. general data, purchasing org. and company code specific data
- Enterprise Asset Management objects: Functional Location (Floc), Equipment Master, Task List (General, Equipment, FLoc), Bill of Material for Material, Equipment, Floc and WBS, Measuring Point, Maintenance Plan and Maintenance Item, Work Center, Object Link, Object Network, Service Master.
- Retail and Fashion Management: Retail Article with basic and classification data, purchasing info record, purch.org. / vendor /site information, logistics specific data like stores, distribution center, listing, sales org. and PoS data.
What user interfaces can be used with SAP MDG?
SAP MDG comes exclusively with web user interfaces based on SAP Fiori and Web Dynpro (ABAP). There is no SAP GUI based user interface. Users just logon to their Fiori Launchpad and are able to search for master data and request new master data or changes. As SAP MDG re-uses the same authorization concepts as SAP S/4HANA or SAP ERP users can only see and manage master data they’re authorized for.
Can business users change settings of maintenance workflows?
Workflows are defined in advance by administrators in implementation project. Usually a maintenance workflow is the result of a longer discussion with all stakeholders, i.e. there should usually be no need for frequent changes of these workflow templates. (That’s the “Governance” part in Master Data Governance). Changes to the workflow definition need to be implemented in development system and tested in Q&A landscape before it can be used in production. Nevertheless, SAP MDG workflows can be setup in a very flexible way based on rules. These rules allow workflow processing based on e.g. the workflows priority, the requesting user group, the type of master data object, etc. Each field in a master data change request form can be used to control the workflows behavior.
Can workflow execution be based on rules?
Yes. SAP MDG workflows are rule based. Rules are defined in Business Rules Framework plus (BRFplus) which is an integral part of SAP S/4HANA and SAP ERP and it is integrated out-of-the-box into SAP MDG. These rules allow a flexible setup of master data workflows. Each field entry in a change request form can be used to control and change workflow behavior, e.g. you can trigger additional approval steps in case sensitive data fields has been changed like bank data. Or select the correct approvers depending on the requested plant ID or account groups.
Is it possible to process workflow branches in parallel?
This is possible, especially if e.g. plant specific data of a material need to be enriched in parallel. SAP MDG allows such maintenance concepts to users without blocking of each other.
Is it possible to assign also user groups to workflow tasks instead of single users?
SAP MDG workflows are technically based on SAP Business Workflow. Therefore, they offer the same capabilities. This includes assignment of user groups, single users, roles or even positions defined in SAP Org. Management.
Can we process more than one master data record in a workflow?
SAP MDG can process one master data record with certain sub segments (plants, company codes etc.) in one workflow, e.g. a material record with 4 plant segments. These workflows are called single maintenance workflows. In multi-record processes several master data records can be processed in the same Change Request. To ease maintenance the UI is then table based. The maximum number of records can be limited in customizing, e.g. to 40 or 50 records. This should prevent creation of very large change requests that can’t be handled by users anymore.
Additionally, also mass change workflows are available to change even millions of master data records. This option is usually available for master data stewards, not directly for common business users.
Can we add attachments and comments to a workflow?
Documents, links and comments can be added to the Change Request header. They are usually relevant for the next users processing the workflow. At the end of the workflow these attachments are usually discarded. In addition, documents can also be assigned to the master data object itself. At the end of the workflow these documents are stored in a DMS system and an archive link will be created. These documents are still available after the workflow has been finalized, they are stored with the active master data record.
What if a workflow task will be declined by a user?
The workflow behavior can be configured to your needs. Usually a rejected task will be sent back to the previous user. Adding a comment resp. reason is mandatory in SAP MDG standard if a task will be declined. This can be changed in configuration. If required also other users can be notified in addition e.g. the initial requestor.
Can we integrate external services into the workflow?
External services can be integrated flexibly to the workflow. Duplicate checks are integral part of SAP MDG and there are also standard integrations for address and compliance checks (sanction party, PEP, etc.). Besides this enrichment services are available to complement records with additional information like e.g. DUNS.
How can we monitor the workflow?
Each user can access the “My Change Request” app where all change requests of a user are listed. Filters can be applied to see e.g. change requests that has been started by the user, that need to be processed by a user etc.
Overall monitoring is possible with graphical dashboards and SAP FIORI tiles based on real-time data. The responsible user can monitor duration of a workflows subdivided into e.g. master data objects and change request types (creations, updates). Overdue workflows can be identified as well. Monitoring dashboard can be configured flexibly e.g. to identify all Change requests exceeding a certain time limit.
Can we integrate external user groups into the master data workflow, e.g. for self-service tasks of customers or suppliers?
SAP MDG is a pure internal application that should not be accessible from outside. To give access to external users, dedicated applications are available like SAP SAles Cloud or SAP Ariba. Both applications offer self-service scenarios for customers resp. suppliers with all necessary functionality to manage external users, their passwords and access rights.
Example: If a new customer registers as a prospect, master data will be stored first in the CRM or webshop application. In a second step, customer data is handed over to SAP MDG where all follow-up process steps are executed (address checks, duplicate checks, merge, etc.). In the meantime, the customer can go on with its process in CRM, place an order etc. There is no need to wait for the SAP MDG workflow. As soon as a customer changes master data in SAP Sales Cloud the changes will also be handed over to SAP MDG, will be checked there and can then be distributed to any other application in the system landscape. The same concept is valid for supplier records created in SAP Ariba.
How will users be notified about new workflow tasks?
There are several options that can be used individually, in combination or all of them at the same time:
Users receive notifications in their “my Change Request” SAP FIORI app where all master data related workflows are listed.
Users receive notifications in their standard SAP Inbox where all other workflow tasks besides master data workflows are also listed.
Email notification with some descriptive information of the task.
All 3 options allow direct access to the workflow task that need to be processed by the user.
Can we integrate compliance checks (e.g. sanction party lists, PEP) into the workflow?
Yes. SAP MDG offers prebuild integration capability for SAP Business Partner Screening which is part of “SAP Business Integrity Screening”. Besides this SAP MDG offers enrichment spots to integrate any other screening application into SAP MDG.
Where is master data persisted during workflow?
Master data is stored in staging tables during workflows. At the end of the workflow master data records are transferred from staging tables to the normal master data tables of SAP S/4HANA or SAP ERP. From there master data distribution will be triggered.
What technics are used to distribute master data?
In general master data can be distributed via SOAP service, ALE/Idoc, RFC and csv file. Distribution can be setup directly or mediated via an EAI middleware. Distribution is rules-based, e.g. only materials with plant x will be distributed to a certain system. Frequency of distribution can also be defined for each receiving system individually. During the distribution process key mapping and value mapping tables are processed to read/create/update key and value mappings.
See also the SAP Community blog post that deals with this question related to upcoming options.
Do we have to start master data workflows always in SAP MDG?
No. Workflows can be triggered either manually by users in SAP MDG or via API or SOAP service. Workflows for financial master data like G/L accounts, cost centers or profit centers are usually triggered initially in SAP MDG. Whereas customer master data records usually start their life in a CRM application, suppliers probably in SAP Ariba. Master data records are then handed over to SAP MDG where the master data workflow is triggered automatically.
Can we derive standard field values in SAP MDG workflows?
Yes. Many customers already implemented program logic in their existing ERP application to e.g. automatically derive plant specific field values or even create all plant segments automatically. SAP MDG with its integrated Business Rules Framework plus (BRFplus) supports this as well. In BRFplus decision tables, all the field contents will be defined that should be derived automatically. If a SAP MDG workflow is processed, these decision tables are read by SAP MDG and the field values are defaulted automatically. Depending on SAP MDG’s configuration business users can change derived default values or not. Business users can even change the decision tables in BRFplus by themselves. These decision tables can be downloaded to MS Excel, users change content in Excel and upload it again to BRFplus. Please keep in mind that this should be done in a development system first because testing is usually required. Nevertheless, upload into production system is also possible.
Can business users define and change default values?
Decision tables in BRFplus can be changed by authorized users directly in SAP MDG resp. BRFplus. They can also be downloaded to Excel, be changed there and uploaded back again to BRFplus. Additionally, SAP MDG offers personalization capabilities. Each user can define a default value for certain fields. As soon as the user access a SAP MDG web UI, his personal default values are prefilled. A user can also change these values again.
Can we automatically derive plant specific values of material records to avoid maintenance of all plant specific fields manually by the user?
Yes, this is possible. Therefore, BRFplus decision tables are used. All field values that need to be derived automatically are defined there. If an SAP MDG workflow is executed these field values are derived and defaulted in SAP MDG's change requests automatically.
Can we execute checks and validations in SAP MDG workflows?
Yes. If you create a master data record in a standard SAP S/4HANA (or SAP ERP) application, many checks and validations are executed in background, e.g. displaying or hiding of fields depending on the selected material type, validity of reconciliation accounts or payment terms depending on the selected company code etc. All these validations are defined in customizing settings of the standard SAP S/4HANA or SAP ERP system and in SAP MDG they all are reused out-of-the-box. Additional checks and validations relevant for SAP MDG can be defined in BRFplus. Warning and error messages can be assigned flexibly. For each workflow step in MDG administrators can define which validations need to be executed.
Can we configure duplicate checks based to our individual needs?
Yes. SAP MDG allows to define several matching strategies. A matching strategy defines the fields that should be considered for matching. For each field the weighting and fuzziness can be defined. All fields with their individual weightings create the overall score.
Is fuzziness supported by the duplicate check and search engine?
Can we have a google-like search to search for master data?
Yes. SAP MDG on SAP S/4HANA uses SAP HANA's fuzzy search functionality. It allows a “google-like search” for master data.
Can we distribute master data only to SAP applications or can we also send records to Non-SAP applications?
SAP and Non-SAP systems can be defined as client systems of SAP MDG. They can be connected directly or mediated via an EAI application. From a technical perspective SOAP, ALE/IDoc, RFC and csv-based distribution is supported by SAP MDG.
How can we manage master data distribution if receiving systems are configured differently?
SAP MDG uses key and value mapping functionality to overcome such differences. Even if the local system uses different identifiers for e.g. payment terms, account groups, plants, material types, etc., SAP MDG stores all the mappings for each receiving system. If a golden record has been changed in SAP MDG, the distribution process will execute the mappings for each receiving system. Therefore, the client system receives a master data update containing only field values that can be processed by the client system. In case a new record will be distributed from SAP MDG to a client system and the client system uses internal number assignments, the new local number will be sent back to SAP MDG to update SAP MDG's keymapping table automatically. However, these mappings need to be created initially during the SAP MDG project.
Are user authorizations considered during master data maintenance?
Yes. As SAP MDG is based on SAP S/4HANA or SAP ERP the same concepts regarding authorizations are re-used in SAP MDG. If users don’t have appropriate authorizations to display e.g. materials of a certain material type or plant segment, they can’t display or maintain material master with this material type or plant segment.
Can we do mass changes in SAP MDG?
Mass changes are supported of course. It can be done for thousands or even millions of master data records.
Is it possible to extend existing products and business partners with new data (e.g. additional address, new plant, new tax number?
Existing products and business partners can be extended using the Fiori app “MDG, Mass Processing”. The file upload feature in Mass Processing allows you to insert new rows in existing tables. There is an FAQ document with details for the file handling.
Can we use spreadsheets to upload master data into SAP MDG?
Yes. Master data records can be downloaded from SAP MDG into an Excel file. Uploading Excel files to SAP MDG consolidation is also possible. The Excel file need to follow a certain structure, a template excel file is available as well.
How does a typical master data project look like?
Master data projects usually have 2 phases:
•Phase 1: “Make It Clean”
•Phase 2: “Keep It Clean”
SAP MDG is the tool of choice for phase 2 “Keep It Clean”: It ensures that only master data of adequate data quality reach the system landscape. An important prerequisite is, that SAP MDG starts with correct and harmonized master data. This cleansed and harmonized master- data basis will be created in phase 1 “Make It Clean”. That means all existing master data stored in client systems need to be checked, corrected, enriched, harmonized and deduplicated. If this has been done a golden record will be created, i.e. key and value mappings will be created. These Golden Records will then be uploaded to SAP MDG as an initial data load, all key and value mappings are stored in SAP MDG mapping tables. This is the point in time when SAP MDG takes over the governance. In general there is no standard approach for phase 1 as each customer situation, customer requirements and system landscape is different. In simple cases manual cleansing and migration into SAP MDG is feasible. In very complex cases (many SAP and Non SAP systems, millions of master data records with poor data quality) a dedicated migration project is required supported by specialized tools like SAP Advanced Data Migration (SAP ADM) and SAP Data Services (SAP DS) to create a solid master data basis for phase 2.
Can I proactively control the quality of master data with SAP MDG?
Yes, SAP MDG offers you the possibility to define and detect business rules. These rules can be used in data quality analyses and results can be visualized in dashboards. These rules can also be applied in master data maintenance processes. If quality defects are detected in analyses, follow-up workflows can be triggered to seamlessly remediate erroneous data. This is available for product and business partner data (incl. customer, supplier) and custom objects.
Does it add value to integrate with SAP Information Steward to control the quality of master data?
Starting with SAP Master Data Governance on SAP S/4HANA 1809, MDG offers in-built and fully comprehensive data quality management features for rule management, data quality analysis and remediation related to Product data. With SAP Master Data Governance on SAP S/4HANA 1909 the domain coverage was extended to Business Partner data and custom objects.
DQM use cases for this target scope do not require integration with SAP Information Steward. For details, see this SAP Community
blog post.
