SAP Master Data Governance on SAP S/4HANA FAQ

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Yes.

Yes. SAP MDG on SAP S/4HANA uses SAP HANA's fuzzy search functionality. It allows a “google-like search” for master data.

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.

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.

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.

Mass changes are supported of course. It can be done for thousands or even millions of master data records.

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.

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.

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.

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.

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.

As of SAP S/4HANA 2023, SAP Master Data Governance (SAP MDG) on SAP S/4HANA offers two different modes of using MDG processes: The standard delivery option of SAP MDG known as “SAP Master Data Governance” is referred to as “classic mode in SAP Master Data Governance”. The second mode is “cloud-ready mode in SAP Master Data Governance”, which is an alternative to classic mode in SAP MDG. See the description of cloud-ready mode and classic mode in the SAP Help Portal, and see the detailed comparison of cloud-ready mode and classic mode.

Cloud-ready mode in SAP Master Data Governance strictly follows clean core principles. Extensions can only be done through well defined, upgrade-stable interfaces in a cloud-compliant way.

As of today, cloud-ready mode is applicable for business partner (incl. customer and supplier) data. Product data is planned according to information on SAP Roadmap Explorer.

Both classic mode and cloud-ready mode are based on the SAP S/4HANA data model for business partner (incl. customer and supplier).

Cloud-ready mode in MDG is one consistent common framework for all MDG scenarios. It enables new apps in newest SAP Fiori design system for:

• Central governance (single processing and mass processing
• Consolidation

Data quality management apps can be used seamlessly in cloud-ready mode and classic mode.

The coexistence of classic mode and cloud-ready mode is possible for central governance (typically for a transition phase). This means that when cloud-ready mode in MDG is switched on, central governance in classic mode can still be applied in parallel. However, this means that during that time, different UIs and workflow-inboxes are applied. Consolidation requires the use of the new app. And mass processing is also based on the new app for central governance. Data quality management processes do not require new apps.

Yes. Cloud-ready mode is available for the business partner domain as of today. This means, that you must decide whether to use cloud-ready mode or classic mode for this domain, while other master data domains run on classic mode.

A: Yes, this can be done, but for now only in BUT000, for other tables it is planned.

B: Only DQM rules (no BadI or old BRF+ rules) can be used.

C: This still supported. There is no difference in DQM between classic mode and cloud-ready mode.

No.

Not yet, but, this feature is on the roadmap.

There are only limited capabilities for now (mandatory state can be set in general). Dependent on the workflow steps, such settings are not possible for now, but on the roadmap.

Processes created in cloud-ready mode cannot be finalized in classic mode apps. They must be re-created.

No, SAP BTP is only required for workflow, attachments and for address validation (if SAP Data Quality Management, microservices for location data is used).

The data model can be extended in cloud-ready mode using SAP S/4HANA key user extensibility for fields. Node extensibility is a roadmap topic.

The cloud-ready mode of SAP Master Data Governance allows the optional usage of SAP Build Process Automation, SAP Document Management Service, and SAP Data Quality Management, microservices for location data. The usage of these services is not included in the license for SAP Master Data Governance. As such, these services need to be licensed separately, for example by using a Cloud Platform Enterprise Agreement (CPEA).

The process monitoring, using the Process Path Overview app, is only provided for visualizing cloud-ready processes, which is not available for classic mode. This is independent of the process analytics app Master Data Process Overview for Business Partner. Both can be used in parallel.

The process analytics apps for MDG domains are not planned to be deprecated. These apps can still be used after switching on cloud-ready mode.

Yes. You can use the Configure Matching app (already available for classic mode). Most of the fields are configurable and weighting and fuzziness are supported.

Users can adjust the process templates (created in MDG Customizing) and optionally assign workflows per process step. These workflow definitions are managed in BTP Business Application Studio (BAS). 

The data replication is based on the replication set-up of SAP S/4HANA. It is not triggered by the workflow.

The process templates are preselected based on the types of data sources: either for business partner or for business partner plus relationships.

Yes. This can be done like in classic mode.

Up to now, you must use two different import apps for BP and for BP relationships. Planned to be harmonized in one unified app.

Yes. SAP S/4HANA key user extensibility (Custom Fields app) provides these fields in the common replication protocols.

Yes. All sub-nodes and leaves are included.