Discuss business intelligence, integration, compliance and a host of other SAP-related topics – implementation, best practices and resources to negotiate the world of SAP better!


July 4, 2019

Moving to S/4HANA - What've you thought about MDG?

Metaphorically speaking, if digital core of S/4HANA is the nerve center of the enterprise then what is data? 

Answer-Nerve. Nerve needed to keep business process running in the enterprise within and across its organs (within digital core and across applications involved in the solution).


Good quality master data gives a solid foundation to a successful S/4HANA implementation. Further to propel enterprise throughout the lifetime it is critical to ensure consistent, current and relevant data supply and usage. Ensuring good quality master data can prove to be a keystone habit that can initiate a chain of positive outcomes for years to come.

If we analyze business processes running in today's enterprise (ECC) we will find these biggest challenges among other

  1. inaccurate or inconsistent data (example - inaccurate supplier master data in case of Procurement and Sourcing)
  2. Lack of Data ownership and process governance - questions such as who will manage, what data, and when
  3. Absence of data trace-ability and analytics
  4. Data not harmonized / information stored in multiple information systems

SAP MDG can help you overcome these data challenge associated with Business Partner, Supplier, Customer, Material and other domain specific solutions. Examples in Financials are CoA, G/L Account, Profit center, Cost Center etc. and Enterprise Asset Management (EAM) Via MDG Solution extension from Utopia along with SAP MDG's extensible application framework. SAP MDG act as "Single Source of Truth" for Master Data which provides centralized governance to keep one version of data flowing across the enterprise.  Capabilities in these data domains to author, collaborate between data owners and achieve highest data quality by using cleansing of data are important ones. You can take advantage of master data consolidation framework from MDG which provides an ability to identify, match and merge records and to create best record. Mass processing functionality helps you in handling bulk changes in much simpler and efficient way.


Inbuilt Data Replication framework (DRF) help you replicate data from MDG to other downstream SAP or Non SAP applications. Standard out of the box rule based workflow templates are available. Also ready to use integration with Business rule Framework (BRF+) helps setting up varied validation and derivation rules.

SAP NW MDM is on its way to sun set as per SAP's roadmap. NW MDM is a java based tool and SAP MDG is a business suit component of SAP S/4HANA which is on ABAP stack. We have observed that customers are moving from NW MDM to MDG as a preferred master data governance solution.There is no direct migration from SAP NW MDM to SAP MDG. The framework is completely different and there are no re-usable components between the two solutions. 

Standard data Migration approaches to be used to migrate data from NW MDM to MDG. Depending upon complexity, volume, target system etc. considerations ETL tool can be decided. What is important here is to identify which of these applications are playing source system role for initial data load to MDG in your target system landscape. 

There can be different starting points for Customers who wish to use SAP MDG in their target S/4HANA system landscape. Some of these are mentioned in picture below.


With S/4HANA, customers use Standalone Deployment or Co-deployed on S/4HANA deployment options for SAP MDG. Each deployment option has its own advantages. A careful evaluation need to be done prior to deciding on strategy.


MDG Hub deployment:

In this deployment, the standalone S/4HANA (or Suit on HANA system) is used for the activation of business suite component - MDG. This refers to the centralized HUB mode for the master data creation. This deployment is usually preferred option in case of heterogeneous environment where there is no single global system which can be representative of the entire set of systems.

The MDG hub will be the central system as "Single Source of Truth" where organization will have the Cleansed, harmonized and consolidated reference data and master data from the system landscape. Pros and cons of MDG Hub deployment are summarized as follows



MDG upgrade is not dependent on Global ERP upgrade

A separate HANA database and system  for MDG is required

Decoupled from Global ERP system maintenance cycles

Data migration to MDG hub from source systems is required (Initial data load at the time of implementation)

Allows fresh start with cleansed data (No prerequisite to cleanse data in downstream application first before implementing MDG)

Configurations needs to be migrated from Global ERP. Further, it is required to be maintained in sync (ongoing Customizing Synchronization)

Co-deployed Mode:

In co-deployed mode, MDG is activated on S/4HANA system itself. This option is well suited in simple system landscape involving an S/4HANA system and few downstream applications which receive their data from the former. S/4HANA system will have the global set of the reference data for the entire landscape receiving data.

Co-deployment option will bring benefits of out of box reports and analytics capabilities. The upgrade will happen hand-in-hand with S/4HANA system but customer can take advantages of integrated data models. Below table gives Pros and Cons of this mode.



No separate System (Hardware) for SAP MDG required.

MDG upgrade will be dependent on S/4HANA system

No replication of master data to S/4HANA (No cost of implementation and monitoring of replication interfaces)

Additional efforts needed to cleanse and consolidate existing data

No separate HANA DB required for search & Duplicate check


No additional Data migration to MDG, since it gets data from S/4HANA 


Lastly, these three important aspects you need to consider as well -  

SAP MDG product versions and availability SAP MDG is a business suite application and can be activated on SAP S/4HANA or SAP ECC. There is a product availability matrix provided by SAP to decide applicable version as per the current version of SAP ECC or S/4HANA.

Reporting or analytics for MDG: SAP MDG in any deployment option has 2 types of reporting associated with
  • In-built standard MDG Change Request based Analytics- This requires the standard BI content activation within MDG system which would enable MDG Change request based analytics activated. Out of the box MDG analytics offer reporting based on time and status of Change Requests
  • Reporting capability based on HANA analytics - MDG reports can be designed and modeled using HANA Analytics. HANA Analytics requires additional software component.

Integration scenarios for MDG: MDG as a business suit component offers Web Services which can be consumed by the inbound interfacing system to trigger change request in MDG. Outbound system integration - MDG offers services in form of Data Replication Framework (DRF) which uses the standard ALE functionality of S/4HANA. It also offers outbound web services. When MDG is on S/4HANA system it can replicate all the data to the active table in S/4HANA system. Thereafter, the standard integration methods of  S/4HANA can be leveraged (Point-to-Point or Middleware based).

Co-Author : Amit Patil (

June 21, 2019

Historic Data - Carry what you need in S/4HANA

Customers in their digital journey with S/4HANA are often perplexed on various questions pertaining to historic data. Such as how much history data is needed in future system? History data required at all in future system or only open transaction data will suffice? What are different ways to carry historic data from legacy system to future system? etc.


In S/4HANA there are various opportunities to elevate current processes to next-generation processes. As we can imagine with popular examples of next-generation processes in front of us such as automatic invoice matching, predictive maintenance, managing stock in transit historic data is very essential. In this example of automatic invoice matching process utilizes artificial intelligence to automate the invoice to payment matching. AI uses matching criteria by learning from the historical financial clearing information. If sufficient history is not available, automation will not work as expected. Therefore, you need to transition history data to your new system to take full benefit from day 1 of operation in new system or wait for couple of years till sufficient history builds up in the new system.  

Running current processes in new system after transformation may need historic data, too. This can be further supported by process or compliance constraints. Service history, Spare Part consumption, and historic consumption data for forecast are few examples of processes which require history data. 


While data is important and its importance is growing in digital world where this enterprise asset is often regarded as 'new gold' or 'new oil', it is also important to know what are the options available. Here are the options -


  1. Open/Current Transaction Data in S/4HANA and keep legacy ERP on in read-only mode: In this option only open and current transaction data is migrated to Target system. Often we have history data belonging to these open transactions which we still need to be migrate. Example invoices already posted, partial good receipt against a Purchase order, delivery already made for an open Sales order. Data migration to S/4HANA can be handled using data migration tools which work in S/4HANA. Normally there is no impact on project timeline with this approach. This process has basic requirement on data reconciliation.

Users can be granted a read-only only access to refer any historic data they may need. Legacy system can be re-platformed to cheaper hardware to save cost.

  1. Open/Current Transaction Data and entire History Data in S/4HANA :  In a Hybrid or new implementation project, where open and current transaction data plus entire transaction data history migration to target system is required, customer need to get specialized Service for required tool and knowledge to achieve this. The historical data for entire duration (all fiscal years) belonging to the considered business can be part of scope. (E.g. - All closed Sales Orders, 5-10 years old  Projects/Sales Contracts etc.). Complexity in migration and data reconciliation will grow with differences in process design (process dissimilarity) in source and target system. Testing scope will be higher in this case.

Note: In case of System Conversion, Software Update Manager tool takes care to convert the legacy data in place during S/4HANA conversion.     

  1. Open/Current Transaction Data and Selective History Data in S/4HANA: Open and current transaction data plus selective data such as time sliced History (for example 2 or 3 fiscal years of data). The historical data for desired duration belonging to the considered Business is migrated. (e.g. open sales orders plus all closed Sales Orders within last 2-3 fiscal years.). Such project require deep knowledge of data models of source and target system, relationship and dependencies between different business objects in the scope. This scenario requires high level of alignment between various domains (finance, logistics) to give business rules for selection of data to minimize risk of data inconsistencies in migrated data. It will add to data reconciliation effort mainly. 
  2. Open/Current Data in transaction system and History Data in data retention solutions: Open and current transaction data is migrated to target system. Whereas, the historical data (complete or selective) belonging to the considered Business is migrated to inexpensive data retention platform. Example - Open sales orders in this example will be migrated to S/4HANA and all closed sales orders will be accessible from data retention platform). Archive technologies such as system decommissioning solution can be used on current ERP to make a snapshot available to access history data from an inexpensive platform. Alternatively, Business Data Warehouse can be leveraged. This reduces data foot print in target system and at the same time makes history data available to users on a data retention Platform.

March 29, 2017

Transform the way you Standardize Material Number

The Material Number you use in your SAP ERP system is arguably one of the most important data element as it goes on for years. Years and decades passes and depending upon type of material there are hundreds or thousands of documents created - Purchase Orders, Production orders, Sales Orders, Deliveries, Material Documents etc. What would you do when you need to rename keys for several Material masters? Whatever be the reason - be it due to a new deployment planned for MDM or MDG system, or simply because you want the Material key to speak for itself with new intelligent naming or decide to standardize the use of material keys to match with a buyer company post an M&A, or you were using less digits earlier and now want to add a couple more in the alphanumeric key.


Companies have tried methods to overcome the problem, albeit the solution have proven to be sub-optimal.

For example , a lesser known method that is in use is based on Supersession of parts. For example - You have a Material Number 'A' for which you want a new number key 'B' to be used going forward. In such case a new Material Master is created with new Number Key 'B'. The relationship is maintained in Material Masters for substituted and superseded material. The whole process of new number key replacing old material number may take some time. For this, the older Material's stock need to get exhausted and it should not be purchased or sold any longer. Easy as it may sound, there are some disadvantages such as when you have to analyze you always have two Material Numbers to look at and consolidate for any reporting or analysis on historic data. Plus, certain enhancements are required in application such as in Material Requirement Planning to execute runs on new Material Number.


This could be a nightmare for companies with long historical usage of material to work with multiple keys for one material number, not to mention confusion this will add when working with other stakeholders like customers and suppliers in the ecosystem.


Material Number Rename Solution using SAP Landscape Transformation 2.0 (LT 2.0) provides a cleaner and efficient way to handle this requirement. We can perform the conversion/Rename of material number in SAP system based on 1:1 material rename mapping (old Part number: New Material number). This tool driven transformation takes care of changes in customizing data, master data and transaction data for each material rename that is needed.


As a pre-requisite, it is important to identify all the Material numbers which require renaming. You can combine this activity with identifying materials which are no longer needed and are obsolete. Material Numbers which need standardization are listed, whereas, non-active material masters can be discussed for archiving or Status change.

Next, a standard naming for Material need to be decided. This new naming should be intelligent nomenclature that your team of experts decide with the objective to provide solution to original problem that triggered this requirement of renaming.

Data conversion/renaming of Material Number is handled in systematic way in SAP system using SAP LT2.0 licensed software procured and installed. SAP LT2.0 assists with useful system analysis. Analysis include runtime analysis to estimate time required to run conversion or downtime required; Analysis to identify hard coding of old Material number in ABAP objects etc. After analyzing the impact and resolving any actionable tasks in ABAP or in customization, test conversions are carried out in test environment using the material mappings. Success is verified using Standard reports which are run before and after the conversion of material number rename. After repeating the testing in SIT and UAT phases the data conversion is performed in production system generally over a weekend.

Most important benefit that you get using SAP LT2.0 driven Material Number Rename is that the system after conversion is in a state that end user feel as if system always had the new Material number key in usage. In customizing data, master data, open transaction data, and historic transaction data everywhere new material key reigns. Old key is replaced completely. During the conversion, it is possible to save original material number key in 'Old Material Number' field in Basic data view of material master. This facilitates the search of Material Master using old Material key. 


Take the right step by choosing tool driven SAP Transformation Services by Infosys in your data harmonization needs.    

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter