Case Study: SAP MDG Architecture Design

This is the second article in a series of SAP MDG case studies. Please refer to my previous blog article that covers the first phase of this project as well as its background: 

http://simonsayssap.blogspot.com/2014/02/case-study-mdg-implementation-at-large.html

This article focuses on a very interesting aspect of this project – analysis and design of SAP “internal” architecture. By “internal” architecture I mean integration of MDG with SAP systems as well as decisions regarding internal MDG architectural alternatives.

MDG Architecture Related Challenges

As discussed in the Background section of the first case study article, this customer had a very complex SAP environment with multiple SAP systems.  

Internal integration included the consolidated central SAP ECC instance, another ECC instance that was left as a standalone and not integrated in the foreseeable future, SAP BPC system, SAP BW, SAP APO, and SAP SRM. The solution also needed to support an interim phase to integrate with the existing master data SAP ECC instance (eventually MDG was to replace this system).

In terms of functional scope, customer decided that MDG implementation would include all master data objects including: Finance (Company, chart of accounts, cost centers, and profit centers), Partner (both customer and vendor), and material master. Customer also needed to manage some non-standard SAP data that included custom tables related to tax jurisdiction data, as well as manage configuration data such as Company Code and possibly plant master.
 

MDG Hub vs. Co-Deployment Decision

The first important architectural decision was between Hub and Co-deployment. SAP supports both options in implementing MDG.  

Hub architecture is depicted in the following graphic.



 

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. 

 

The main benefits of the Hub deployment were identified as follows:

•  Flexibility to maintain separate upgrade and patching paths for MDG and ECC instances – MDG was a relatively new solution that may need to be upgraded and patched sooner and more often than the ERP portion of ECC;
• There was no need to do regression testing on ERP for every MDG upgrade and patch;
• Higher flexibility for integrating with separate systems;
• Easier to maintain reference/configuration data for different ECC transactional systems;
• Avoided the conflict between SRM Server and MDG business function activation for Supplier (SAP note 1491040) – it is highly recommended to check for other possible conflicts during your specific deployment;
• 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.

The main benefits of the Co-deployment architecture were identified as follows:

•  Higher maintenance of the additional ECC landscape in terms of:
• Security support
• Basis support
• Infrastructure support
• Additional hardware required
• Additional effort and complexity of maintaining synchronized configuration (IMG) environments between SAP ERP/ECC and MDG/ECC instances

This customer agreed with my recommendation implementing MDG in Hub architecture for the benefits presented above.

Interfaces Between SAP Systems

I recommended leveraging ALE interface technology for all interfaces between SAP MDG and other SAP systems including the legacy SAP ECC central master data system. ALE is a proven technology when it comes to interfacing SAP systems. This customer’s Basis support analysts had considerable experience implementing and supporting ALE interfaces.

I recommended interfacing other SAP auxiliary systems directly with the SAP ECC central instance. As depicted in the Hub chart above, these systems included SRM, BW, and APO. These systems were to be interfaced with SAP ECC using the core-interface (CIF) technology delivered by SAP for each system. Based on my experience, this is the most stable out-of-the-box way to interface these systems. This customer had considerable experience using and managing CIF interfaces.

The one exception was the new BPC (SAP BusinessObjects Planning and Consolidation 7.5, version for SAP NetWeaver). In previous version of BPC, SAP recommended to interface this system with SAP BW. In earlier versions, BPC gott its master data (e.g., cost center and profit center hierarchies) from SAP BW structures. However, in version 7.5 that this customer was implementing, BPC was able to maintain its own master data objects and had capability to support file transfer of master data from external systems directly into BPC. Initial discussion with customer finance business team and their BPC implementation partner favored interfacing SAP MDG directly with BPC in a unidirectional mode – i.e., master data would originate in SAP MDG and be transferred via file transfer interface to BPC. Please note, however, that this portion of implementation was not finalized while I was involved with this project.

Integration with SAP Solutions Manager ChaRM system was considered in support of management of configuration objects such as company code information. This interface is depicted in the chart below.

  

 

Please note that SAP does not support out-of-the-box interface between SAP MDG and Solution Manager/ChaRM. I designed custom interface using ChaRM’s interface with help desk systems.   

The information flow and process steps were designed as follows:

 

Internal MDG Architecture Decisions

SAP MDG supports two main modes of data movement from Staged to Active databases – SAP calls them Flex and Re-use modes.

 

Staged data is temporary data that MDG maintains during the change request (CR) governance process (i.e., when master data created or changed). When the master data is finalized, business users (typically Information Stewards) activate the data. When the data is activated, it is moved to the permanent Active database. Active database resides in separate MDG data tables in Flex mode and in standard ERP tables (e.g., the MARA table for material master) in Re-use mode (hence the name Re-use for reusing the ERP tables as Active database).

 

Re-use mode depicted in the following diagram.

 

 

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.

The benefits of Re-use mode were identified as follows:

• It was easier for users and support personnel to manage and query data in standard ERP tables that they were already familiar with;
• 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.

The benefits of Flex mode were identified as follows:

• MDG-F only supported Flex mode – setting Flex mode for other master data objects would provide consistency across MDG;
• 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.

Case Study: SAP MDG Implementation at a Large Diversified Chemical Company

Topic: Selection of Master Data Management Software

This is the first article in a series of articles about SAP MDG case studies. This article focuses on the early phase of software selection and proof of concept.
 

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.
 

SAP MDG Proof-of-Concept (POC) Phase

Prior to finalizing their decision, the customer wanted to do a proof-of-concept (POC) project to make sure that SAP MDG has the capabilities to address main business requirements. I recommend this approach for customers that have complex business processes and complex IT environments. For smaller customers with simpler business processes, I often recommend to go straight into pilot implementation, as a pilot MDG project may not be much more expansive than a POC.

 

The scope of this POC project included the following:

• Standard Vendor Master data model (out-of-the-box SAP MDG data model) with minor modification of adding one new SAP data element that was not in the standard data model and one custom data element;
• Standard Vendor Master BRF+ workflow with minor modification – one parallel approval process was added to demonstrate parallel work flow process;
• 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.  

Guidelines for Properly Customizing SAP ERP

In my previous blog article titled “The Dilemma to Modify or Not to Modify SAP”, I discussed the classical question whether it is appropriate to customize the SAP ERP system. By “customizing” I meant not just configuring the SAP ERP thousands of options/tables, but also making code changes via SAP’s built in allowable code modification techniques such as user-exists, enhancements, and BADIs. It is important, however, to follow a good methodology and use experienced consultants when customizing the SAP ERP system. In this article I provide some guidelines for properly customizing the SAP ERP system.

 

My conclusion in the previous article was that it is not always possible to change company’s business process to fit SAP, and indeed, it is not always appropriate. However, customization should be designed and done by the best SAP consultants who have both functional and technical knowledge of the system after a careful analysis of alternatives. It is interesting to note that in the survey I have done on LinkedIn SAP Network Global group, 76% of participants agreed that SAP could be modified. As of February 20, 2014, 39 participants answered the survey questions as follows:     

• 43% thought that SAP is designed to be modified
• 33% thought that SAP should be modified by experts only
• 17% thought that the business process should be modified to fit SAP    
• 5% thought that SAP should be only modified by SAP, AG
• 0% thought that SAP should never be modified

Before engaging in any SAP customization, I strongly recommend to thoroughly analyze alternatives that include the available SAP configuration options and possibility of changing the business process to fit the SAP process. This is easier said than done. In my experience, even SAP consultants with over 10 years of experience may not know all the available options to configure SAP (especially cross functional options).  

 

Most customers are reluctant to consider changing the business process that was used for many years. It is often difficult to determine whether this reluctance is a natural resistance to change (in which case, rigorous change management should be applied), or the business process in question gives customer a unique competitive advantage. In the previous blog article I referenced earlier, I gave two examples of case studies – one for when it was decided to modify the existing business process, and another for when SAP was customized successfully to preserve an existing process that provided that customer a unique competitive advantage.  

 

Once the decision is made to modify/customize SAP, I recommend following these guidelines:

• If extensive new functionality is required, check if another commercial application that already interfaces with SAP is available.   
• Consider developing the required functionality outside of SAP and integrating with source code using SAP’s integration technologies such as RFCs, BAPI calls, and/or use of IDOCs. Such an add-on custom developed application will be independent of SAP’s source code and should provide an effective path to patching and upgrading SAP. Another option is to develop a custom SAP application that calls on various SAP functions. This is more closely integrated with SAP, but may still minimize the impact on SAP’s source code.
• When customizing SAP, check whether customization options available as part of IMG for your specific purpose. For example, pricing functions allow creating complex pricing logic to be used as part of pricing procedures (both in SD and MM) and can be attached to pricing steps in pricing procedure.
• I recommend using BADIs, whenever possible. BADIs are mode modular and better “insulated” from SAP’s source code, and therefore, are less likely to impact the SAP source code and be impacted by future upgrades. However, BADIs may be more complex to implement and require developers familiar with SAP’s object oriented syntax. Also, the same feature that makes BADIs more modular makes them less flexible in terms of availability of in-program variables that may need to be read and changed during customization.
• The next preferred method is the use of Enhancements or user-exists (this is probably the most popular method). 
• SAP allows creating custom Enhancements in various places inside the source code as well as delivers standard Enhancements. Enhancements are function calls that are isolated from the source code and can be managed in a special Enhancement Project. In the previous versions of ERP, Enhancements were referred to as CMOD (for customer modification function) and SMOD (for SAP modification function). An enhancement can be activated and deactivated.
• User-exits are places in source code that are provided by SAP as forms (hence also referred to as form exists) – they are basically empty subroutines. Many user-exits are documented in the SAP IMG, or could be found by searching the source code with the word “USEREXIT”. An example of a user-exit is USEREXIT_PRICING_PREPARE_TKOMK – this exit allows to change the content of the TKOMP table before pricing procedure is executed.

In conclusion, SAP modification/customization should follow a very rigorous approach outlined in this article and led by the most experienced solution architects and consultants that have excellent cross functional knowledge and good understanding of the SAP development environment. Please do not hesitate contacting me for any questions on this subject.

 

The Dilemma to Modify or Not to Modify SAP

 

Ever since SAP introduced the R/3 (their modern ERP system), there has been an argument on whether it is proper to modify the core SAP ERP system or not. The old adage supported by many in SAP itself and many SAP consultants is that SAP ERP/ECC should not be modified – that customers always must modify their business processes to fit SAP processes (configuring SAP is ok, but customers should not customize SAP beyond the scope of standard configuration options). 



In my 24 years of implementing SAP ERP, I got convinced that all-or-nothing approach to SAP customization is wrong. The thinking that SAP has the “best-practice” for every single business process is impractical. If every company in the same industry implements exactly the same SAP “best-practice”, then how can companies compete and differentiate their products and services? Business processes, even within the same industry, are so diverse, that it is a bad idea to try to force all customers to implement standard SAP processes in every occasion.  

Besides, SAP ERP was designed to be customized without breaking the source code. SAP offers many capabilities such as user-exists, enhancement points, BADIs, BAPIs, requirements (ABAP code attached to conditions and access sequences designed to enhance their functions), and various calculation functions (ABAP code attached to pricing conditions and SD and MM pricing procedure designed to enhance standard calculations). The question, therefore, is not whether to customize or not, but when does it make sense to customize SAP versus modify the business process, and if customization is chosen, how to customize properly with minimum impact on future maintenance and upgrades.

Unfortunately, it is not possible to develop a clear prescription on when to customize SAP and when to modify the business process. It takes years of both SAP implementation as well as business process experience to help customers make the right decision. As an example for either case, please refer to the following two case studies (based on my recent SAP projects). In the first example, it was chosen to take advantage of standard SAP process, and in the second example to enhance standard SAP functionality.

One of my chemical industry customers organized their material supply area by implementing a work-in-process (WIP) warehouse with multiple bins. This design did not fit SAP’s WM material staging concept of organizing the supply areas by material and resource combination. SAP WM does not support bin level picking when staging materials for supply areas. Initially, this customer wanted to modify SAP to fit their bin level staging approach. After a detailed business process analysis, the team concluded that customer’s approach to managing their material staging was unnecessarily complex and required maintenance of a special WIP warehouse. Also, this approach caused errors in picking that could result in usage of wrong raw materials in the manufacturing process. Therefore, this customer agreed to reorganize its supply area to fit SAP’s expectation by resource and raw material and used standard SAP staging functionality.

Another process industry customer implemented SAP for one of their make-to-order (MTO) plants/product lines. Although pure MTO processes are not typical in the process/chemical industry (and not part of SAP’s best practices process industries template), this customer believed that their MTO focus provided them a unique competitive advantage. The characteristic of their MTO process were reflected in how they took orders, scheduled manufacturing, and mainly, how they packed products to order. They called this “custom-fill” process where they would package a product in custom fill quantities in a large number of different packages. For example, even when a 55 gallon drum could contain 300 pounds of one of their product, this company would package custom quantity/weight in the same 55 gallon drum as requested by their customers – e.g., 200 lbs one time, 150 lbs another, and 300 lbs another.

SAP was configured to support MTO production with strategy 50 with planning against independent requirements or reorder lead time (depending on material). This was not standard configuration used in process industries, but it still took advantage of standard SAP planning framework. Custom-fill functionality, however, required to enhance the standard SAP functionality.

As a start, in designing the custom-fill solution, I took advantage of SAP’s packing function. SAP packing can be setup to determine packing materials based on packing instructions and packing determination conditions. However, during packing determination in the sales order, customer service representative (CSR) needed to be able to overwrite the system proposed fill quantities with a custom quantity based on customer request (i.e., custom-fill). Initial fill quantity was proposed in the packing proposal based on master data maintained in the packing instruction. I designed an enhancement that replaced this proposed fill quantity with quantity entered by CSR before letting standard SAP re-execute the packing proposal and recalculate the number of packages required to satisfy the custom-fill quantity. This enhancement also made sure that CSR would not enter quantity greater than maximum possible for the package.

In addition, in standard SAP packing functionality, the system copies packing proposal from sales order into delivery. My customer needed to copy the packing proposal into their process order (since packing was done during manufacturing process). In support of this requirement, a BADI was developed as part of process order create/change transaction to copy the BOM components from the sales order packing proposal instead of from standard BOM master data. 

This company also needed in some instances to price packing materials. For this purpose, I added packing surcharge condition. One of the fields in the access sequence for this surcharge condition was packing material (material type VERP). However, standard SAP does not consider packing material during execution of pricing procedure in the sale order. To address this challenge, I activated a standard enhancement point that prepares pricing determination related data (KOMP data). I also created a pricing calculation function to convert the packing surcharge data from price per each package to price per order quantity (in this case always price per pound).

As shown by above examples, both approaches of modifying the existing business process and customizing SAP to fit the business process can greatly benefit SAP implementation. Both approaches require extensive expertise in both SAP as well as business processes involved. When dealing with complex SAP customizations, cross functional knowledge of SAP (i.e., of several SAP functions) as well as knowledge of SAP’s underlying development environment (e.g., ABAP, BADIs, BAPIs, IDOCs, BPM, etc.) is necessary to design effective solutions. Understanding of change management challenges is also highly desirable.

In the next blog articles, I will offer some considerations to how to determine when to customize SAP versus the business process and some guidelines to customizing SAP properly.

 

Search words: SAP, ERP, ECC, customizing, enhancement, solutions, SAP implementation