Introducing Central Governance of Master Data

Objective

After completing this lesson, you will be able to explain the concept of central governance of master data

Govern Product Master Data

Master Data Governance for Product Master Data enables you to monitor and control the creation, editing, and deletion of product master data.

The figure Sample Workflow for Material Creation/Change shows a simplified sample workflow for material creation or change.

This graphic shows a simplified sample workflow for material creation or change. The first step involves a business user who triggers the change request, followed by a Master Data Specialist reviewing the change request. The request is further sent back to the business user who triggered the change/creation request to make any final changes. Once confirmed, the specialist approves the change request.

The material creation/change request workflow is triggered with the business user raising a change request. The request is then sent to the master data expert (usually the Master Data Steward) who reviews the change request and then sends it back to the business user to make any further changes. Once the business user confirms the changes, the request is then sent back to the master data expert for final approval. Post this approval, the system updates or creates the appropriate material master data record.

Data maintenance activities are bundled in change requests. A change request is linked to a workflow. The workflow can either be linear or distributed. The standard SAP Business Workflow is enhanced with a rule-based engine, therefore, changes in responsibilities and in processes can be reflected immediately and with ease.

Key Processes for Product Master Data

Searching for a material

The figure Search Functionality shows the search functionality for Product Master Data.

This graphic shows the steps involved in the search functionality for Product Master Data. The process begins with the search for material in the active area, followed by a search in the staging area, you can also use Fuzzy search. Post that save and load the search criteria, then trigger the change request and now you can select records from the displayed list for processing.

Processing Product Master Data often starts with searching or requesting for a product.

To search for a product, SAP Master Data Governance offers the following options:

Users can search for products that are stored in the active or inactive area (staging area)
Search criteria combines product attributes and classification
Search uses SAP HANA-Based Search, Enterprise Search, or alternative search providers
The user can start a change request for single or multi-record processing directly from the results list

Performing a duplicate check

Creating or requesting a new material can lead to poor data quality if the system does not check for existing duplicates. A duplicate check improves the data quality and the decision and business process quality in the connected systems.

The figure Duplicate Check shows the steps where a duplicate check is performed.

This graphic shows the steps where a duplicate check takes place - Duplicate check is carried out during search, within change request, and during change request approval processing.

A basic duplicate check is offered to avoid the creation of already existing products. The information about potential duplicates is provided when checking or submitting the change request. You can switch it on or off per workflow steps.

Deleting a material

Once a product is outdated, you must delete it.

The figure Delete Material shows the main steps during the deletion process of a material.

This graphic shows the main steps involved during the deletion of a material - starting from selecting a material to be deleted, followed by maintaining change request details, and finally setting the deletion flag and submitting the changes.

The system creates a change request for deleting the chosen material. The change request then enters the appropriate workflow and once approved, the material is deleted from the active area (if not limited by any other business rule). No remote checks about the reuse of the material are made.

Processing of multiple records

The Multiple Record Processing functionality enables you to create, edit, or delete several master data records at the same time. This functionality is recommended for processing a small number of records and cannot be considered as a replacement for the Mass Change functionality.

The figure Multiple Records Processing shows the main process steps for processing multiple master data records.

This graphic shows the main process steps for multiple records processing, starting from Searching of material, followed by selecting multiple material records that need to be updated, and finally activating the change request.

Parallel Change Requests

Since the change requests are not connected, you can process several change requests for the same business object separately. You can activate or reject one change request independently from the process results of the other change requests. Therefore, you must process related entity data in a single change request. Changes to a business object through one change request are not visible to the other change requests for the same business object.

The following figure shows the possibility of maintaining one material master data in parallel change requests.

This graphic shows the possibility of maintaining one material master data in several parallel change requests.

You can edit the business data of one business object in several parallel change requests with a special change request type, which has to be configured in the customizing. The figure above shows several parallel change requests maintaining different entities for the same material.

For each parallel change request, you must configure the scope at the entity type level to define which parts of a business object can be edited with a certain change request type.

Govern Business Partner Data

Master Data Governance for Business Partner enables you to monitor and control the creation, editing, blocking, and deletion of Business Partner master data.

A typical workflow starts with a user creating or changing data and submitting the change request. A master data expert then reviews the change request. In an additional step, the initial user makes any further changes, if required, and finally, the master data expert approves the change request. As a result, the system updates or creates the appropriate business partner master record.

The figure Govern Business Partner - Change Request Types illustrates the main change request types for a Business Partner.

This graphic illustrates the main change request types for a Business Partner: Create, Change, Block/Unblock, Set Flag for Deletion are examples of such change requests.

The main change request types are as follows:

Create: Business Partner, Customer, or Supplier does not exist for processing
Change: A search is successful, but the data is incorrect
Block or Unblock: Business Partner, Customer, or Supplier is no longer relevant for processes
Set Flag for Deletion: Business Partner, Customer, or Supplier must be deleted in the next archiving run

SAP Business Partner: Roles

The following figure depicts the different roles of an SAP Business Partner.

This graphic lists the different roles of Business Partners, for example, Customer, Prospect, Contact Partner, Supplier, Bidder, etc.

Master data governance provides a directory of Business Partners (organizations, persons, groups of persons). This directory contains data primarily used for identification (for example, name, address, ID numbers, and so on). The master data governance objects like Customer and Supplier are based on this directory and offer seamless integration with customer and supplier-specific data.

The next figure explains the Integrated Object Model for SAP Business Partner.

This graphic outlines the Integrated Object Model for SAP Business Partner. The key concepts are: General Data, Relationships, Roles, and the Usage. General Data consists of core attributes and business attributes from other applications. Business Partners are connected to each other with the help of relationships that define the type of business connection between Business Partners. This structure is useful in suite external applications across industries.

The Entity type Business Partner is a generic application for business partner management (maintaining organizations, persons, and groups of persons).

Integrated Object Model: Solutions for Customer, Supplier, and Business Partner Fundamentals

The following figure explains the Business Partner Data Model including the subsets for customer-specific data and vendor-specific data.

This graphic shows the Business Partner Data Model including the subsets for customer-specific data under MDG for customers, and vendor-specific data under MDG for suppliers.

All solutions use the SAP Business Partner as a central anchor for identifying data.

A single Business Partner represents Business Partners that are both customers and suppliers.

Business Partner Governance is the basis for:

Customers limiting their governance scope to Business Partner data only
Solutions only being based on SAP Business Partner (for example, Service Industries)

The transition from Business Partner Governance to Supplier Governance/Customer Governance is possible without disruption.

Customer/Vendor Integration (CVI)

When you create a customer or supplier, SAP Master Data Governance always creates a Business Partner.

Business Partner/customer/vendor data are partly redundant (name and address data). The customer and vendor data are synchronized with central business partner data using CVI. When you save the newly created or changed Business Partner, the corresponding customer and vendor master data tables are updated automatically.

Customer/Vendor Integration partner data contains:

Business Partner data
Customer data
Vendor data

Govern Financial Master Data

Master Data Governance for Financial Master Data

Master Data Governance for Financials (MDG-F) is an application to govern the maintenance of financial master data centrally. It provides central steering and control mechanisms independently of local or centralized execution. Master data records can be created, completed, or changed in a staging area, following a distributed step-by-step way, before making the records available to the connected business applications. The next figure depicts how to centrally govern your financial master data and distribute it to connected business applications.

This graphic shows how to centrally govern your financial master data and distribute it to connected business applications.

Main Action Areas for Financial Master Data

The figure explains the main action areas for financial master data.

This graphic illustrates the main action areas for Financial Master Data.

Centrally managed financial master data with SAP Master Data Governance:

Ensures consistent financial master data across the entire organization
Provides collaborative and traceable execution of changes for compliance requirements
Supports excellent financial processes: accurate reconciliation and timely group closing
Ensures high-quality master data and provides a single version of the truth

Master data governance provides adjustable data models, the appropriate architecture, processing environment, and usability that enables end-to-end central governance from search to replication.

Watch the video to understand the process framework for SAP Master Data Governance for Financials.

Editions

The next figure Editions shows the different availability dates of editions for financial master data.

This graphic shows the different availability dates of editions for financial master data - Changes collected for release at a dedicated valid-from date and Ad-hoc changes to be executed immediately, using any open edition.

Editions are used to control the validity of a change. In the edition, planned change requests for creating new data or changes to existing data are collected and released collectively at a certain date. Time-dependent objects (profit or cost center) automatically inherit the valid-from date from the edition's valid-from date.

The difference in the activation of financial master data compared to product master data or business partner master data is that the financial master data is not activated immediately. For financial master data, a two-step activation process has been established:

Cover the creation or maintenance of financial master data in a change request and release it.
Release the edition to which the change request belongs.

Log in to track your progress & complete quizzes