Discover the conceptual architecture of SAP Master Data Governance (MDG) and its capabilities. Learn from a comparison of MDG and SAP NetWeaver Master Data Management (MDM) and then step through a use case scenario of maintained master data with MDG.
Key Concept
SAP Master Data Governance provides a strong master data governance capability for finance, supplier, and basic material data domains within SAP ERP Central Component (ECC). It is an embedded component of ECC that leverages the existing ECC functionality and minimizes the complexity of solution implementation and maintenance.
Master data management is the process of establishing common master data language across the enterprise. It ensures that the master data is validated against required quality checks, allows only authorized employees to approve data change requests, eliminates duplicates and dual maintenance, and synchronizes data across all systems in the enterprise landscape.
SAP provides two products to address enterprise master data management needs: SAP NetWeaver Master Data Management (MDM) and SAP Master Data Governance (MDG). I provide an overview of MDG, explaining its conceptual architecture and capabilities. I also compare MDG’s functionality with that of SAP NetWeaver MDM. A use case scenario helps you understand how MDG applies in the master data maintenance of a common SAP landscape. This article is designed for data management solution architects, MDG developers, and master data business process users.
Conceptual Architecture
The conceptual architecture of MDG can be categorized into four different layers (
Figure 1):
- Layer 1: This is the presentation layer of MDG that contains the data steward user interface. Business users maintain data in this layer.
- Layer 2: This is the transformation layer of MDG that contains the Business Rules Framework Plus (BRF+) and rule-based workflow (RBW) components. Master data business rules and governance workflow processes reside in this layer.
- Layer 3: This is the staging area of MDG that holds the data temporarily until all governance and compliance checks are completed and approved.
- Layer 4: This is the data replication layer of MDG that replicates the data from the staging area to the core tables in ECC, and to the other SAP and non-SAP systems.
Figure 1
MDG conceptual architecture
Capabilities
MDG features capabilities similar to other MDM systems, but tightly integrates with SAP environments. The advantages include faster and lower-cost implementations and reduced cost of maintenance while leveraging ECC functionality.
Data Objects
As of Q1 2012, MDG includes the following data domains or objects:
- Finance
- Chart of accounts
- General ledgers
- Cost center
- Cost center hierarchies
- Profit center
- Profit center hierarchies
- Companies
- Material
- Basic data
- Classification data
- Supplier
- Basic data
- Address data
- Business partner attributes
SAP announced it has a roadmap for introducing the customer domain and further enhancing the existing capabilities by the end of 2012.
Data Steward UI
Business users can maintain the master data in MDG using either SAP Business Client or SAP NetWeaver Portal data steward user interface. Developers can configure these components using Floor Plan Manager.
Data Governance Business Processes
Developers use rule-based workflow (RBW) templates to configure the MDG business process flows. RBW uses the Business Rules Framework Plus (BRF+) component as the configuration engine. Although the SAP Business Workflow is the foundation for the RBW, the look, feel, and configuration mechanism vary. SAP Business Workflow uses the drag-and-drop concept, whereas the RBW is a configuration setup using Excel-like templates. RBW not only supports the approval processes but also executes validations at defined steps.
Business Rules
One of the core advantages of MDG is the ability to leverage the existing logic in ECC. You can also use BRF+ to write custom logic and validation rules that are executed behind the screen or called by workflow.
Data Syndication
Initially, MDG stores data in a staging area. After authorized users apply required approvals, MDG distributes data to the core tables within ECC. You can also syndicate data from MDG to SAP and non-SAP systems by configuring Data Replication Framework Plus (DRF+). Various mechanisms exist to syndicate the data using DRF+:
- Web service
- Application Link Enabling Intermediate Document (ALE IDoc)
- Remote Function Call (RFC)
- File
MDM vs. MDG
Table 1 compares the features in MDM and MDG.
Table 1
SAP MDM vs. MDG comparison matrix
Use Case Scenario: Material Master Data Maintenance Using MDG
Consider a common scenario of an enterprise operating three SAP ECC systems, one for each of its three business units. ECC1 features the enhancement package (EHP) 5 upgrade, but the remaining two SAP ECC systems still contain EHP 4. In this scenario, you have an option to deploy MDG on ECC1 with EHP 5, or deploy a separate stand-alone ECC system with EHP 5. Based on the option selected, MDG on ECC1 or the stand-alone SAP ECC system becomes the central hub for all other ECC and non-SAP systems to receive master data.
As of Q1 2012 MDG offers only basic data and classification data in the material domain. You must maintain the remaining views in the local ECC system. Otherwise, the remaining material master data views, including MRP, costing, accounting, sales, and purchasing, in MDG require extensive customization for implementation.
The process flow diagram shown in
Figure 2 depicts a sample scenario to maintain material master data using MDG. It follows the actions of six users.
Figure 2
Material master use case scenario
MDG: Requestor
In this step you can see that the requestor logs on to the MDG UI and performs a search action to determine if the requested material exists in the database. If the requested material does not exist in the database, the requestor submits a request for new material creation. During this process, the requested material information is validated against the material master business rules configured in ECC and BRF+. This data is then stored in the MDG staging area. A workflow request is routed to the global master data user. The user requested only global material master data creation (i.e., basic data and classification information).
MDG: Global Master Data User
This user receives a workflow notification via email and logs onto the MDG UI. The user validates the request and updates the information (if required) and submits it for final approval to the global master data expert.
MDG: Global Master Data Expert
This person receives a workflow notification via email and logs onto the MDG UI. The expert validates and approves or rejects the request. Upon final approval in this step, material information is replicated from the staging area to the native ECC1, ECC2, ECC3, and other systems.
ECC1: Local Master Data User
This local master data user receives a workflow notification and logs onto the ECC1 system. The user reviews the global master data information and maintains the local master data. This completes the end-to-end scenario of material maintenance in ECC1.
ECC2: Local Master Data User
This local master data user receives workflow notification and logs onto the ECC2 system. The user reviews the global master data information and maintains the local master data. This completes the end-to-end scenario of material maintenance in ECC2.
ECC3: Local Master Data User
This local master data user receives workflow notification and logs onto the ECC3 system. The user reviews the global master data information and maintains the local master data. This completes the end-to-end scenario of material maintenance in ECC3.
Note
A master data maintenance scenario for suppliers and finance might be different compared with the material master. Because of more attributes and the localized nature of attributes, most of the views in the material master are maintained in the local ECC system. Most companies implement complete maintenance of supplier and finance domains within MDG itself and then replicate the complete set of master data records to local ECC systems.