Beruflich Dokumente
Kultur Dokumente
software. I am writing this review based on my experience implementing SAP MDG, some experience
implementing SAP Netweaver MDM, as well as helping many customers to implement master data
governance and data quality processes, policies and organizational structures. I have over 22 years of
experience helping customer to implement SAP ERP and other tools such as APO. Please note that
the focus of this article is on MDG EhP 6.1. SAP has released MDG EhP 7.0 version, but as of
publication of this article, this version was just released to general availability on May 19, 2014.
Many potential customers are still confused between the two SAP master data management products
MDG and MDM. Although recently SAP released Enterprise MDM bundle that includes both
products as well as other add-ons such as Data Services and Information Steward, these two master
data software packages have different focus areas and strengths.
To understand the differences in capabilities between SAP MDG and MDM, I suggest to closely
referring to the following SAP chart.
As the chart shows, SAP MDG is related to central creation of master data, and MDM to
consolidation of master data. The main purpose of MDG is to help organizations to create data and
MDM to help syndicate/synchronize master data.
What is the difference between the two functions? To take advantage of key MDG strength, it should
be implemented as the system that most master data is originated from SAP MDG must own the
creation process of master data. Since SAP MDG is closely integrated with SAP ERP master data,
this implies that your SAP ERP system should be the system of record of your master data.
In contrast, MDMs focus is on synchronizing or syndicating separate systems with master data
maintained separately in the different business systems. The purpose of MDM is to help integrate the
master data and make sure that data attributes in common have the same values. Data syndicator
system must have strong match-and-merge functions with ability to match data records automatically,
identify differences, combine data records based on pre-defined rules, and refer exceptions to manual
match-and-merge processing. This functionality is lacking in MDG EhP 6.1 (some SAP publications
claim improved match and merge in EhP 7.0, but I have not had a chance to test this function first
hand).
Master data creation system must have strong workflow and data validation capabilities to support
creation of complex master data objects by various functions within your organization. The definition
of data governance is both management of the business process that supports creation and change
of master data within organization as well as application of automated and manual data validation and
enrichment rules. SAP MDM lacks strong workflow and validation functions, SAP MDG has them.
SAP ERP master data is very complex. It is important for a company that implemented SAP ERP to
maintain quality of its master data to assure effectiveness of its ERP environment. Creation of SAP
ERP master data typically involves many people working for many departments. SAP ERP lacks the
functionality to help companies coordinate the creation of master data, validate it and approve it. For
years, large companies developed workarounds to help them manage SAP master data. SAP MDG,
therefore, filled an important gap in the traditional SAP ERP landscape.
This does not mean that SAP MDG should only be used for managing SAP ERP master data. It has
excellent replication and integration capabilities to integrate and distribute data to other systems.
However, when designing the process of integrating with external systems, it is important to
remember that SAP MDG should ultimately own the master data and act as the originator/creator of
data. It should not be implemented in a role of data syndicator.
One of the best strengths of SAP MDG is that it is based on SAP ECC platform and leverages existing
SAP ECC technologies such as IMG, ABAP workflow, BRF+, and Web Dynpro. It is an advantage for
customers who already use SAP ECC they have to learn fewer new technologies, and they can
leverage to a greater extend their existing IT analysts, developers, and external support partners.
Another important MDGs strength is its close integration with SAP ERP master data. In Reuse mode,
SAP MDG can easily update the SAP ERP master data and refer to this master data during the
processing of master data change requests (SAPs term for workflow transactions for creating and
changing master data). In Flex mode the relationship is more complex and requires more complex
data replication and load settings. Still, since MDG supports SAP ERP data models out-of-the-box, it
is relatively simple to setup MDG to update the SAP ERP master data. The same holds true for
implementing MDG in a co-deployment mode versus the Hub mode (i.e., in co-deployment mode is
simpler from integration perspective). For more detailed information on MDG implementation options,
please refer to other MDG related articles in my blog.
Based on my experience with multiple MDG implementation projects, SAP MDG (EhP 6.1) is a stable
product and, once implemented, works well. It has sufficient out-of-the-box functionality to allow
companies implement quickly some basic functions for governing SAP ERP data. It supports decent
customization options allowing to customize the data model, workflows, user interfaces (UI), data
validation rules, and to implement more complex data quality and data quality analytics leveraging
additional Data Services and Information Steward software. As stated before, it also has good data
replication capabilities supporting all of SAP ECC replication options using Web services, ALE, RFC
or flat file. Additional replication functionality is available with Data Services (for complex data
transformation and validation) and SAP PI (SAPs EAI software).
SAP MDGs main weakness is in complexity of its design SAP, AG does not make the most intuitive
easy to setup products, and MDG is not an exception. For example, SAP chose to implement a new
concept of Entity Types with four different setup options instead of leveraging the existing SAP data
dictionary based on a standard relational database technology. An Entity Type can represent a single
data element or a group of data elements that share properties (similar to a table in relational data
dictionary). In my opinion, this technological concept is a little cumbersome to implement and not
intuitive.
Another example is BRF+ technology. BRF+ is a nice tool that allows to setup business rules to run
workflows and validation processes using tables instead of programming, but to configure BRF+, an
analyst must setup three tables and in many cases know how to activate the update BADIs (BADIs
are SAPs object oriented functions).
The most complicated part of SAP MDG is in the relationship between UI, workflow and data model
as demonstrated by the SAPs chart below.
In more complex cases, analyst implementing MDG must be familiar with all four technologies, SAP
Web Dynpro programming or/and Floorplan Manager (SAP graphical UI tool that allows creating
sophisticated UI, but is not very simple to use). This complexity should not surprise anyone already
using SAP ECC. SAP ERP, for example, has more than 3,000 tables with hundreds (or maybe even
thousands) of configuration tables/options.
In conclusion, SAP MDG EhP 6.1 is a very good product for customer already committed to SAP ECC
environment. Its functionality is long overdue to help companies manage their SAP ERP master data.
SAP MDG can effectively integrate with non-SAP systems, but it should be implemented in a role of
central data creator system not data syndication system. SAP MDG can be enhanced by integrating
SAP Data Services and Information Steward for added data validation, enrichment, and data quality
monitoring functions.
Please note my extensive SAP ERP, SAP MDG and data quality experience. You are welcome to
contact me if you have any questions or are looking for a senior consultant to help you with your SAP
implementation and SAP system management needs. this blog is to share my extensive experience
in implementing SAP software for the benefit of end-users and consulting professionals.
Consistent with my approach you get the straight truth with no sales spin about real-world SAP
challenges and solutions! Reading my blog you will learn about creative tailored approaches that
helped many customers implement, uCase
Project Background
This customer currently has an extensive SAP environment that consists of several SAP ECC
instances, SAP BW, SAP APO, SAP SRM, SAP BOBJ BI, as well as various other SAP and non-SAP
software tools. This customer also has a central SAP ECC instance for master data management and
integrated Lotus Notes work flow and collaboration system in support of its data governance
processes. Customer is in the process of integrating several of its SAP instances into one SAP ECC
instance.
Customer wanted to consider replacing its ECC based master data instance and its Lotus Notes
based governance system with an off-the-shelf master data management tool. Customer was
confused, however, about the various master data management and EIM offerings from SAP.
Solution
The following explanation of the different SAP tools helped this customer to focus on SAP MDG as the
proper solution.
There are some overlapping capabilities between SAP MDM and MDG. By all accounts, MDG is the
tool that SAP is planning to develop and support into the future and MDM is being sunset. However,
MDM still has an advantage in match-and-merge area, and MDG is stronger as a central master data
governance system especially, when there is a need to govern SAP ERP master data.
Match-and-merge is functionality needed to match master data maintained in multiple systems,
harmonize it, and then syndicate the master data back to those systems. Therefore, typically MDM is
better used when there is no one system is the source of master data -- there are multiple systems
that own the same master data and the main functionality of MDM system is to help synchronize this
data.
Please note that SAP MDG EhP 7.0 offers an enhanced data matching and cleansing capabilities
using SAP Hana. This functionality seems to enhance fuzzy match, but it remains to be seen if it is
cable to execute an effective match-and-merge function as described here.
MDG's strength is in its ability to govern master data by being the central system to do this. Data
governance has two important components -- managing work flow and managing the quality of data.
MDG can distribute the data to other systems as needed (and it has excellent integration capabilities
through DRM), but it should be the central source for data creation or at least for enforcing data and
business standards and quality standards.
Data Services is an ETL tool. I call it ETL+, because SAP Data Services has excellent capabilities not
only to move data from one source to another, but also to improve data quality in the process and to
clean data. Data Services is not an alternate tool to MDG and MDM, it is a complementary tool. Data
Services can be used effectively in many scenarios to integrate data between MDG and external
system (with exception of SAP ERP), for data validation (e.g., address validation) in real-time
integrated mode with MDG, and for data cleansing (real-time or batch).
Information Steward is from the same package as Data Services and uses some of the same routines
(e.g., profiling). The main focus of Information Steward is on monitoring data quality. It is also a
complementary tool to MDG and MDM. It is possible to setup data quality dashboards and monitor
whether actual data quality conforms to standards. Information Steward can also manage meta-data
in an enterprise. This functionality is less applicable to ERP data (since meta-data is well defined
within ERP data dictionary), but is very important to help manage meta-data in different business
intelligence and data warehouses.
Based on these definitions, this customer selected to implement SAP MDG EhP 6.1 (EhP 7.0 was not
available at the time) integrated with SAP Data Services 4.1 and Information Steward 4.1.
No integration with SAP ERP system was implemented, but output data from MDG was
exported for review after activation;
Standard MDG data and process monitoring analytics and KPIs were used to demonstrate
MDG master data governance monitoring capabilities.
After successful completion of this POC, the customer was satisfied that SAP MDG was able to
address its business requirements and replace the central ECC based master data system as well as
Lotus Notes based governance.
In the next article I will describe some of the MDG EhP 6.1 architectural decisions that were made
during the initial phases of MDG implementation.
pgrade, and address many other SAP challenges effectively based on their unique business
requirements.
Sunday, February 16, 2014
In this architecture, MDG is setup as a standalone SAP ECC instance. It interfaces with other SAP
ECC instances via ALE interfaces (for reasons discussed later in this article).
Co-deployment architecture for this customer is depicted in the following chart.
As shown in this chart, in this option, MDG is co-located with the central SAP ECC instance.
There was no need to do regression testing on ERP for every MDG upgrade and patch;
May be easier to support dynamic business environment of mergers and divestments; and
SAP strongly recommended the Hub approach for large enterprises and complex landscapes.
Security support
Basis support
Infrastructure support
Please note that SAP does not support out-of-the-box interface between SAP MDG and Solution
Manager/ChaRM. I designed custom interface using ChaRMs interface with help desk systems.
The information flow and process steps were designed as follows:
In this mode, once the data is activated by a step in the change request (CR), the data is moved
directly into the Active database which is the SAP ERP standard master data tables. Re-use mode
can be implemented for both Hub and Co-deployment implementation alternatives.
Re-use mode simplified integration did not require secondary messages for updating ERP
tables;
Re-use mode potentially minimized interface errors (fewer interface messages); and
Re-use mode had lower data storage usage (since data was stored in fewer tables throughout
the system).
Flex mode is depicted in the following diagram.
In this mode, Activation of the data moved the data into internal MDG Active database tables
(separate from ERP data dictionary tables). Then the data has to be replicated into the ERP master
data tables or into other external systems. This is typically done using the MDG DRF (data replication
framework) functionality. This mode is also supported in both Hub and Co-deployment.
It is important to note that in MDG EhP 6.1, MDG-F was supported only in Flex mode. It was
explained to me that the reason for this was the implementation of MDG editions (or affectivities) for
financial objects in SAP ERP that did not support this function.
Flex mode provided decoupling between the MDG Data Model and ERP data
dictionary e.g., not every customer enhancement to the MDG data model required
modification to the ERP data dictionary;
Therefore, Flex mode would provide added flexibility to integrate with multiple
SAP and non-SAP systems;
This approach would allow for more effective debugging of update errors
(eliminating possible interface issues between systems);
Update of MDG ECC ERP tables could be turned off at any time with no impact to
MDG environment.
Ultimately, it was recommended and decided to implement MDG in dual mode Flex mode for
financial data and Re-use mode for partner and material data. This approach was to be evaluated
after completion of the initial testing and prior to go-live.
In the next article I will discuss architecture decisions with external systems.