Innovations in SAP Master Data Governance 7.0

Note: If you are new to SAP MDG, you might want to read my blog post on the Enhancement Package 6 version of SAP Master Data Governance first. That blog post provides an overall introduction to SAP MDG. This post here focuses solely on the additional value provided by release 7.0. There is also a blog
post on SAP MDG 6.1.

 

Introduction

 

SAP Master Data Governance (SAP MDG) offers governance applications for master data domains like Financials, Supplier, Customer, and Material, all tailored for centralized data maintenance. With these applications, you can manage master data that is ready to use within SAP environments, but also beyond.

 

We have just recently released the latest version SAP MDG 7.0 into Ramp-Up shipment in November 2013. We allow installation of SAP MDG 7.0 on top of Enhancement Package 6 for SAP ERP 6.0 as well as on top of Enhancement Package 7 for SAP ERP 6.0. For existing installations of SAP ERP 6.0 EhP6 or SAP MDG 6.1, this means that you do not need to upgrade to any higher Enhancement Package, but can just upgrade to SAP MDG 7.0 in that system.

 

SAP MDG 7.0 ships enhancements for SAP MDG for the mentioned master data domains, this time with a special focus on Financials. It also provides improvements of the MDG Application Foundation, allowing for the extension of standard content and the creation of governance processes for your custom objects.

 

What is new in SAP MDG 7.0?

 

Release 7.0 of SAP MDG focuses on three things. Firstly, it provides a more flexible MDG Application Foundation that allows for refined control in the governance processes, leading to more flexibility and higher efficiency in the business. Secondly, it provides better usability through additional role-based Work Centers and improved user interfaces across the various master data domains and for custom objects. Thirdly, it gives you the option of using SAP HANA for advanced duplicate detection and search, and it provides matching and cleansing capabilities.

 

As with every release, with SAP MDG 7.0 we have improved MDG’s core capabilities. The MDG Application Foundation has been enhanced, for example to allow for parallel change request processes on different parts of the same master data object, or for a more flexible “Edition” management. The already very broad out-of-the-box delivery for SAP MDG’s master data domains has been enhanced even further. The domains of Material, Supplier, and Customer master data were already considerably enhanced in SAP MDG 6.1. While these three have been extended even further in SAP MDG 7.0, a special focus has been put on the Financial master data domains. See below for further information.

 

Figure 1: The business consistency check has found issues, when trying to change a material master record

 

In SAP MDG 7.0, the mass data import has also been improved, in particular for loading data into MDG’s “flexible mode” models, like for financial master data and custom objects. The integration scenarios have been enriched, for example for exchanging customer master data with SAP CRM, or for distributing SAP Configuration data that is managed in custom-built MDG objects and processes.

 

In addition, investments have been made to help companies increase their reach with SAP MDG across their enterprise. SAP MDG now allows for data cleansing through merging and correcting duplicate business partners. The usability has also been further improved: for example, now there are dedicated role-based Work Centers for Accounting, Controlling and Consolidation data, as well as improved user interfaces for the maintenance of financial master data and custom objects. And there is a dedicated user interface for multiple-record processing with a first focus on material master data. Also, there are out-of-the-box governance processes for the generic SAP Business Partner. That means in addition to Supplier and Customer that were provided earlier, companies can now also govern the central data of different types of SAP Business Partners. SAP MDG 7.0 also supports the usage of SAP ERP Document Management System for attachments to material master data.

 

Let us have a more detailed look at some of these enhancements.

 

Further data model extension for all domains, but especially for financial master data

 

SAP MDG 6.1 already contained a substantial increase of the data model scope provided by SAP MDG out-of-the-box. In SAP MDG 7.0, this has been extended even further. For example, the material data model now covers close to 400 attributes across basic and classification data, logistics data dependent on organizational units, as well as valuation and costing. For material, similar to the extended supplier and customer models, we would expect that by far the most SAP standard attributes you may want to put under central governance are readily available in SAP MDG now, and only few would have to be added using SAP MDG’s extensibility capabilities.

 

As mentioned above, a special focus was on extending the financial master data domains. This refers to both the introduction of new master data objects (like financial reporting structures) and broader coverage within the already delivered data models (like enhanced address and communication data for companies, cost center, or profit centers).

 

Figure 2: Extended out-of-the-box data model coverage in SAP Master Data Governance 7.0

 

More flexible foundation for higher business efficiency and refined process control

 

As mentioned above, the Master Data Governance Application Foundation is the framework underneath all MDG applications, which allows extending the MDG standard content as well as building self-defined master data objects and the corresponding governance processes. To use MDG for custom objects, you use the framework to define the appropriate data models, and then generate the staging area and user interfaces based on these models. Then you define the appropriate workflows and the roles that will provide access to the user interfaces. You can use the Data Replication Framework (DRF) to distribute the data that has been maintained. You can build your own validations, or extend existing ones based on the Business Rules Framework (BRF+). Finally, there are also Business Add-Ins (BAdIs) provided to include custom ABAP code into MDG’s processes.

 

Whenever we in SAP development make additional investments in the Application Foundation, the main focus is on extensibility, flexibility, usability, and ease of consumption. That means that we want to allow companies to create very flexible governance processes, with role-based user interfaces, but with very reasonable implementation efforts. Let us discuss some of such new capabilities in SAP MDG 7.0. In particular, we will cover the more flexible Edition management and Parallel Change Requests.

 

The new flexible Edition management has four key capabilities that define its business value: an easier and more flexible scheduling of changes, a very intuitive access to the different states of master data valid in certain timeframes, better transparency of past and planned changes, and a more granular control over replication timing.

 

With the improved concept, you can now use and combine as many editions as you need, and you can also reschedule planned changes across Editions.

 

Figure 3: Overlapping Editions and the resulting validity of the master data managed in these Editions

 

The simple example above shows how several open Editions can handle the same objects. When you create or change an account, the valid-from date of the Edition defines the valid-from date of the change. The valid-to date is defined by the “next change” (i.e. in a later Edition) of the same account. See “Account A” in Figure 3. If there is no future planned change, the valid-to date is unlimited – see “Account B”. You can reschedule open change requests with the related inactive data to another edition. This is useful, for example, when you want to release an Edition, but not all related change requests have yet been approved and activated. See “Account D” in Figure 3.

 

A new search parameter (“valid on”) allows you to very intuitively search and display master data with the status it had or will have on a certain date. And when displaying any change request in an Edition, the user will now get full transparency about other (planned) changes: the system shows the next already planned and approved change of the same master data object and allows the user to directly jump to it. It also provides a link to any pending change that has not been approved yet. Finally, you can now decide which replication timing is allowed for each Edition: replicate all approved change requests together with the Edition, replicate each change request separately and immediately when approved, or let the user decide for each change request whether it shall be replicated immediately or held back and replicated together with the Edition.

 

The new flexible Edition management is used by SAP MDG for Financial Data, but can also be used for (time-dependent) custom objects if they are modeled using the Flexibility Option of the MDG Application Foundation.

 

SAP MDG 7.0 now also supports Parallel Change Requests. Let me explain what we mean by that using a simple example: You decide you want to produce a certain product in an additional factory. Accordingly, the product manager requests the extension of a material master for that additional plant. The gathering of the required data and the approval are handled in an MDG change request that involves several colleagues and some manual processing steps. The whole change request process might perhaps take a week or two to complete. During that time, a change of the packaging requires an urgent update to logistics data to make sure the material can still be correctly shipped from all other plants.

 

Without parallel change requests, you would have to update the logistics data in the same change request that is already blocking other changes to this product. You would therefore not be able to approve and activate these changes before being ready to approve and activate the complete changes, including the data for the additional plant. Typical consequences: urgent changes are either delayed manually “enforced” without governance, or mixed with other changes – resulting in trade-offs between agility to respond to business needs and enforcing governance.

With parallel change requests now being enabled, you can create a second dedicated change request for the urgent change in the logistics data. The already started plant-extension can be carried out as planned. Both change requests can be independently processed and approved. This enables customers to respond to business needs as they occur, while still keeping the governance processes in place.

 

Figure 4: Executing multiple-change requests for the same object in parallel allows for more agile governance

 

Please note: Without parallel change requests, it also is possible to have one change request with sub-workflows (several simultaneous work items). This is useful if more than one group of processors needs to work on the change request simultaneously, for example one group to add financial data and one group to add logistics data – but both of them are working on the same request. The fundamental difference is that, as long as this is one change request, there will only be one final approval and the final activation will activate all data. With parallel change requests, each change request and its scope is activated individually.

 

Of course, when creating parallel change requests on the same master data object, you still want to avoid conflicting changes to the same master data attributes. The good news is that the system will prevent these. This is provided in two ways – once during design-time and once during run-time: At design-time, you define the scope of a data model that can become part of a certain change request type. However, these data models may still contain identical attributes in multiple change request types. (For example, there might be different change request types for “creating a new material” containing all attributes, as well as for “extending a material to a new plant” containing just the plant-dependent attributes, and for “changes togeneral material attributes” containing just those.) At run-time, the system will prevent you from creating a change request that contains attribute sets that are already contained in another open change request. For example, this means when there is one open change request adding a new plant A, you can still create a new change request to change general data or to add another plant B, but you cannot create a change request that would change data for plant A for this material. This blocking of certain parts of a master data object by a change request is referred to as “interlocking”. For the more technical readers, I would like to add that interlocking is done per entity (not per entity type or attribute).

 

There are more enhancements to the MDG Application Foundation in SAP MDG 7.0, like for example an improved mass data import into objects created with the MDG Flexibility Option. It would go beyond the scope of this blog to mention all of them. I will just discuss the enhanced usability in single-object processing in the context of financial data below, and multi-record processing will be explained in the context of material data.

 

Many companies use the MDG Application Foundation to build governance processes for Reference Data. That is data with a harmonized definition and aligned values across the complete company, very similar to master data. But reference data sometimes needs to be compliant with external standards (such as ISO). It is often referenced by diverse master data and processes. It may be simpler in structure, lower in volume, and less frequently changed than master data. Often, reference data is stored as SAP Customizing Data. These are, for example, country code, currency code, material group, plant, location, payment terms, purchasing organization, and so on. SAP MDG 7.0 provides many improvements that support projects in creating governance processes for reference data. These processes are defined using SAP MDG Custom Objects. The new user interface for Custom Objects (and Financials), which we will discuss in more detail below, provides enhanced usability and configuration options. The new data import I just mentioned above for Custom Objects – built using the Flexibility Option – allows for enhanced monitoring, scheduling and usability compared to the file upload. The flexible Edition management provides a more intuitive access, transparency about changes, and control of the replication timing. In addition, there are improved capabilities for replication of reference data that is SAP customizing. All this will help MDG customers build governance processes for reference data with a low implementation effort.

 

Let me also mention one additional important concept of SAP MDG again: search as a starting point for most activities. When we talk to users of SAP MDG, most of them start many tasks with a search. Obviously, you want to avoid creating duplicates when creating a new object. Hence you first search whether it already exists by entering a few attributes in the MDG search screen. If you find the object, you might want to change it. MDG provides the link to do so. If you do not find it, you might want to create it. And when you select that button, for example to create a new supplier, MDG will take the information from the search screen and prepopulate the fields in the change request. There is no need for the user to retype the information they already entered before. You can also search and then select multiple entries in the result list and trigger a mass change for all selected objects. You can start a change request to block objects, or to mark them for deletion. You can access all past changes to an object with the change log, or look at the objects replication status in the Data Replication Framework (DRF), and (re-)start the replication if necessary. All this is possible directly from the search result screen. The search screen can now also be configured in the Floorplan Manager and personalized by the users.

 

Figure 5: The search result screen can be used as a starting point for many activities

 

Better usability for all standard and custom-defined master data objects

 

Given the now broader scope in the financial domain, with SAP MDG 7.0 the structure of the role-based Work Centers for this domain has been redesigned. We now provide separate dedicated roles and Work Centers regarding governance for Financial Accounting, Controlling, as well as Consolidation master data. The Work Centers provide easy access as well as better transparency in the respective areas. The menus now also follow the approach of using Business Activities to determine the right change request type for the user interaction. This is the same concept as introduced earlier in the Business Partner and Material domains. Since the new structure contains suiting templates for authorization roles, you can also grant users more granular authorizations.

 

Figure 6: Role-based Work Center for Financial Accounting governance – one of the three new Work Centers

 

With SAP MDG 7.0 for Financial Data, there are also new user interfaces for single-object maintenance. These new user interfaces allow for easy personalization and flexible configuration. For example, you can configure specific user interfaces for each workflow step or each processor. You can use context-based adaptation (CBA) to provide dynamic user interfaces that change at run-time dependent on attribute values like change request type or object type. The same user interface flexibility had been introduced with Enhancement Package 6 for the Customer, Supplier, and Material domains, and is now newly available for financial master data and Custom Objects designed with the MDG Application Foundation. Additionally, a G/L Account and the related Company Codes can now be maintained in one process step, similar to the Financial Reporting Structure and the related FRS Item. For business partners, customers, and suppliers, it is now also possible to create an organization and contact persons in one step and in the same change request. You can now also generate an IBAN from already provided bank details or, the other way around, generate bank details after entering the IBAN.

 

Newly with this release, there is also a merge functionality for customers and suppliers. Whenever a user identifies potential duplicates in a search result list, or when the system identifies them in a duplicate check during change request processing, the user can create a Cleansing Case that contains all potential duplicates. Using an underlying change request, this cleansing case can be processed by an expert to merge the data from all duplicates into one target record. Then, the changes can be approved – typically by a second person. A typical flow might be: create a new cleansing case, search and assign potential duplicates, check the details of the potential duplicate records, identify one target record, decide which potential duplicates to keep in the cleansing case and which to mark as “not duplicates”, start cleansing, and create a change request. During the cleansing step, the expert will browse through the superset of all data from all duplicates and will decide which parts of which duplicate will be taken over into the target record and which will be dropped.

 

Another usability improvement that I want to mention is the new Multi-Record Processing. This feature enables you to change multiple master data objects simultaneously in one single user interface. You can select multiple materials from a search result screen, and then start the multi-record processing. This will create a change request in the background to fully integrate this maintenance into your governance processes. In a tabular maintenance screen, you can then change all these materials at the same time. For example, you can directly change values in single table cells, or attributes can be changed to the same value across several selected materials at once. You can also copy a value from one material to other selected materials. In order to select the materials in the table that should be maintained together, the system for example offers an automatic selection of all materials with a certain value in a certain attribute. There is also a search and replace function to change values across several materials. All changes you have already done since opening the maintenance screen are highlighted in one color. All saved changes or changes that users have already done before in the same change request are highlighted in a different color. The user interface is, of course, built using the Floorplan Manager for ABAP WebDynpro. It therefore also allows for easy configuration to your users’ needs.

 

Figure 7: Multi-record processing – change many materials simultaneously in one user interface

 

You have probably already heard of the side panel concept in SAP applications. This is a great way of providing users with additional context when working in an SAP MDG user interface. The side panel is an area attached to the right-hand side of the standard screen where the company can configure additional context information. The users can then open / expand this area at any time. The side panel interacts with the main screen and will, for example, dynamically display information about the current supplier or material that the user is changing in the main screen. For example, you might want to display a list of all open purchase orders with a certain supplier that the user currently wants to mark for deletion. The side panel is a very open concept, where typically our customers themselves define the information to be displayed. This is easily possible, since new demand by the business for additional context information does not require any changes to the MDG processes or user interfaces. Instead, the small information snippets can be built separately and just attached to the screens side panel. SAP also delivers some side panel content as Business Context Viewer (BCV) CHIPs that can be attached to SAP MDG screens. For example, newly with SAP MDG 7.0, we deliver a sales overview that displays all sales orders created for the current material, a production overview that shows production orders created for the current material, a purchasing overview that displays purchase orders created for the current material, and a CHIP that displays all changes against the active material that are proposed by the current MDG change request. Again, these are just examples. Typically, companies will add to them and create their own.

 

Figure 8: Sample side panel content delivered with SAP MDG 7.0

 

Faster search with SAP HANA, duplicate detection, and multi-attribute drill-down

 

SAP MDG 7.0 can either be installed on top of Enhancement Pack 6 (EhP6) or Enhancement Pack 7 (EhP7) for SAP ERP 6.0. If it is installed on EhP7, it can run on SAP HANA as primary database. In any case, regardless of the Enhancement Package SAP MDG is installed on, an SAP HANA database can always be used side-by-side to SAP MDG. You would then set up near real-time replication of the information from MDG’s primary database into SAP HANA in order to make use of the information in SAP HANA.

 

Figure 9: If installed on EhP7 for SAP ERP 6.0, SAP MDG 7.0 can run on SAP HANA as primary database

 

Once the MDG information is contained in SAP HANA – as said as the primary database or using replication – you can use SAP HANA’s capabilities for duplicate-detection and similarity-ranked search. This search method comes in addition to other options like plain database search or Enterprise Search / TREX. SAP HANA fuzzy search allows for both, free-style Google-like search with search terms as well as attribute-based search with dedicated thresholds for each attribute. SAP HANA calculates a similarity rank for all search hits and allows you to sort the result by a weighted score across all attributes. This is very helpful in the MDG search application as well as when integrating it within MDG processes for duplicate detection. Based on the high detection quality of SAP HANA fuzzy search and matching, this will even better prevent the creation of duplicates. The calculated similarity score helps the user identify and sort potential duplicates.

 

When your master data is stored in SAP HANA, you can also make use of HANA being an in-memory column-based database. Column-based means that you can easily access all different values of a master data attribute, like for example all states in a selected country in all your customer’s addresses. This is how the SAP HANA database works: there is a column dictionary that lists all different values for an attribute, and the single entries point to this dictionary. Since this dictionary is even in memory, you can access this information in virtually no time. This allows you to first display all attribute values of all of your master data. It also allows you to slice and dice, that is drill-down and filter by attribute values extremely fast. SAP MDG 7.0 provides you with a dedicated application to do exactly this. In the multi-attribute drill-down based on SAP HANA, you can filter and analyze the intrinsic structures in your master data. For example, you can easily find attribute values that need company-wide harmonization. Let us assume that you find 62 different values in the attribute State for customers in the US. There must obviously be spelling mistakes for some of these US states since only 50 exist.

 

This is a completely different approach to searching master data. The users will actually find instead of search, since the system only displays all existing attributes and objects. There is no need for guessing, you simply find what is there. This drill-down search can even be combined with fuzzy search. That means that users can enter a search term that will filter the total master data based on similarity thresholds. The users can then slice and dice all the remaining master data along its attribute values.

 

Figure 10: Multi-attribute drill-down based on SAP HANA in SAP MDG 7.0

 

Outlook and broader context

 

This concludes my post on SAP MDG 7.0 capabilities. Please expect moreto come in future releases. As mentioned earlier, we will continue to further extend the standard scope for SAP MDG’s master data domains in the future. Usability is always a key theme for us. This will also be supported by additional investments in SAP MDG’s Application Foundation regarding extensibility and flexibility, while at the same time always driving ease of implementation. We will continue to invest in analytical capabilities and integration with SAP’s Information Management and Information Governance portfolio. Also, SAP HANA will help us provide additional innovative capabilities.

 

We see a trend to exchange master data information between business partners via business networks. Together with SAP’s acquisitions of Ariba and hybris, we have additional opportunities to help automate the provisioning and the consumption of master data between companies. Especially in the area of Consumer master data, the integration of information from social networks is also a trend we see and we intend to support in the future. And just to also mention Cloud here: SAP MDG supports the trend towards Cloud-based applications already today: MDG integrates with Cloud-based applications, for example by provisioning master data into the Cloud. And SAP MDG can, of course, also be consumed from the Cloud, for example via the SAP HANA Enterprise Cloud.

 

You might also want to revisit my earlier posts that are linked above. There I describe how the focus of SAP MDG is on comprehensive master data ready for use in business processes, through ready-to-run governance applications for specific master data domains. I also describe how SAP MDG allows for custom-defined master data objects, processes, and user interfaces, and how it can distribute master data to SAP and non-SAP systems. I also explain in detail how SAP MDG is an important part of SAP’s Information Management portfolio, and how you would want to combine MDG with additional tools like the SAP Information Steward for monitoring of master data quality in all relevant systems and correction in SAP MDG, or like SAP Data Services for data quality services, validations and data enrichment.

 

You can find more information about SAP MDG on the SAP Master Data Governance page on SCN.