Review of SAP MDG Software

The purpose of this article is to review the strengths and weaknesses of SAP MDG 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, MDM’s 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 MDG’s 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 (SAP’s 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 (SAP’s EAI software).

SAP MDG’s 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 SAP’s object oriented functions).

The most complicated part of SAP MDG is in the relationship between UI, workflow and data model as demonstrated by the SAP’s 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.

Case Study: Custom SAP Make-to-Order Packing Solution

This case study is based on one of my projects for a medium size multi-national chemical product company.  The significance of this case study is that it demonstrates how SAP ERP (ECC 6.0) can be properly customized to fit client’s business requirements by leveraging existing SAP functions enhanced with custom code.  This is also an interesting and detailed overview of a make-to-order packing solution designed for a chemical industry business process.

Background

This chemical industry customer implemented SAP for one of their plants/business 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 make-to-order (MTO) focus provided them a unique competitive advantage. Their MTO process was reflected in how they took orders, scheduled manufacturing, and mainly, how they packed products to order. They called this a “custom-fill” process where they package a product in custom fill quantities offering a large number of different container types and sizes. For example, 55 gallon drum could contain 300 pounds of one of their product; they would package different quantities in the same 55 gallon drum per order from their customers – e.g., 200 lbs. one time, 150 lbs. another time, and 300 lbs. yet another time.

Production Planning Solution

SAP supports various variations of the MTO process. By selecting Strategy group 50 in the material master record (MRP view) for the finished material, SAP triggers a MTO process of the finished product and a make-to-stock (MTS) production of the intermediate material. This fit well with my client’s requirements. They would plan the production of the bulk material to stock and then only execute the final packaging operation to order.
As an example, please refer to the following graphic that depicts the bill-of-material (BOM) structure with related material master parameter settings.

As indicated, material 99043347 was assigned Strategy group ‘50’ and Consumption mode ‘2’ (controls how independent requirements are consumed by sales orders) in the material master. Its BOM could contain the bulk material and the necessary packaging material. However, in this case (for reasons to be explained below), its BOM contained only the Bulk material 99043346. Therefore, physically there was no difference between the two materials. The only difference was that the finished material was assigned to the packing operation in routing and was produced to order (i.e., its production was triggered only when a sales order for this material was created). Bulk material was produced to stock.

The production of Bulk material was triggered by Independent Requirements maintained for the finished materials. Finished products were planned by either using a forecast, based on knowledge of the sales people, or a combination of forecast tool output and knowledge. This plan was then copied into SAP Independent requirements in monthly buckets. MRP would then develop production orders for bulk materials based on these independent requirements for the finished materials. Once sales orders were entered for the finished material, they would consume independent requirements (i.e., be confirmed against independent requirements). Process orders were created for each sales order of the finished material (sales order and item numbers were referenced on the process order header data).

Packing Solution in SD

MTO planning requirements were addressed with standard SAP MTO functionality. Satisfying the Custom-fill packing requirement was not that straight forward. SAP has packing functionality. The system allows for packing of materials in a sales orders, production/process order and delivery documents. This packing can either be manual by manually selecting a packing material (material type VERP) and assigning a required packing quantity, or this process can be automated via a packing proposal.

First, SAP requires creating packing instructions -- master data records that capture the relationship between packing material and finished material (or any material type that can be sold). An example of a packing instruction is shown in the following screen shot.


In this example a finished material (990433067) was assigned to 5 gallon plastic pail packing material (91008375) in this packing instruction. As you can see, target quantity of 4 pounds was specified. It was also possible to specify other optional parameters. Packing instruction can contain multiple packing materials (item category P) and packed materials (item category M). However, I typically advise to create a packing instruction for each packing material to capture all relationships with finished materials (i.e., in this case 91008375 will contain a list of all finished materials that could be packed in this pail).

Packing instruction can be automatically proposed in a sales order, delivery or production/process order by a packing proposal. Packing proposal is determined by implementing a typical SAP access sequence. In this case, my client needed to select packing instructions based on type of transportation and generic package type specified in the sales order. In SAP several parameters could represent either variable. For various reasons, it was chosen to select Shipping type and Special processing indicator (both fields are available on sales order item detail shipping screen) – both parameters could be customized in IMG.

In order to be available to the access sequence table, both fields needed to be part of allowable data dictionary fields for the packing condition tables. Special processing indicator field was not on a list of allowable fields. For this reason, the allowable field table needed to be extended with a custom Include to add the additional field. This modification is allowed by SAP.

Two access sequences were configured in support of automated selection of packing instructions as follows:

 

1. Material/Ship type/Spec ind/Ship to

2. Material/Ship type/Special ind

 

To support this functionality master data tables must be maintained. The master data table for the second access sequence is shown in the following screen shot.

Material 99043367 in the table is the finished material (i.e., the material sold in the sales order document). Special processing indicator represents a generic container size – in this case, a 55 gallon drum, and Ship type represents the type of shipping mode – in this case “CC” that stands for Common Carrier (other ship types were Air freight, UPS ground, UPS air, and Sea). Once SAP matched all these parameters in the sales order, it would select Packing instruction 1321 that pointed to packing material 91008375 and target quantity of 4 pounds.

The first access sequence is similar to the second with only the addition of Ship to party (i.e., Ship to customer number). The purpose of the first access sequence is to support customer preference. The first access sequence will be selected first by the system. If no data was matched, then SAP would attempt to match data in the second access sequence. Therefore, if a customer suddenly has a new packing material preference, my client only had to add the first access sequence and it would override in effect the previously setup default for just this customer.

The result of this packing proposal is seen in the following SAP’s packing screen shot (the same screen is available in the sales order and delivery transactions – product/process order use a different packing screen).  

 

The first challenge was that when a packing proposal was use, SAP would not allow changing target quantity. Business requirement was to allow customer service to change the target quantity based on their customer preference. For this purpose we developed an enhancement function to replace the target quantity read from the packing instruction record when a customer service user entered a different partial quantity that was less than the target quantity in the packing instruction, larger than the minimum quantity in the packing instruction, and less than the total order quantity.

SAP then calculated the number of packages required as well as quantity per package as shown in the screen shot below.

Another important requirement was to provide ability to price certain packing materials for certain customers.  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).

Packing Solution in PP-PI

SAP’s functionality allowed for this packing proposal to be copied into the delivery document (or to be executed in delivery as a new proposal). The business process assumption that SAP made was that packing is done by the shipping department prior to delivery. My customer, however, packed its products in their productions as one of productions operations.

SAP supported the execution of packing proposals as part of the process order. However, it did not support the copy of packing proposal from a sales order into production/process order (even for MTO linked process orders). Also, packing proposal was kept as a separate record and did not impact the process order BOM list and was not considered for material costing. Therefore, a different solution needed to be developed to address this business requirement.

Instead of executing the standard SAP packing functionality in PP, it was chosen to copy packing materials into process order as components by developing another enhancement. This enhancement function was placed after SAP source code that copied BOM into the process order. The enhancement function read the handling unit tables (where packing information was kept in SAP). Please note that each packing material was also setup as a kit and had other components attached to it (such as lid, main container, labels, etc.). The results of this enhancement in a process order are shown below.

Summary and Conclusion

This article presented a creative solution in response to a chemical industry company’s make-to-order packing business process requirement (referred to as “custom-fill”). It showed how standard SAP ERP functions were leveraged and then enhanced with allowable SAP enhancement technologies to develop the required functionality.

It is important to emphasize that although these enhancements did not impact core SAP source code, the added functions would not be automatically added during upgrades. Also, SAP would not support the new functionality. For these reasons, the benefits of every such enhancement must be thoroughly analyzed prior to implementation. In this case, I helped my client to weigh the cost of developing the enhancement, total-cost-of-ownership (TCO), and potential risk against the impact of using standard SAP functionality and adapting the business process to SAP. Since this process was considered an important competitive advantage by my client, management decided to go ahead with its implementation.

Thank you for reading this article.  I also suggest to read the related article about guidelines for properly customizing SAP:
http://simonsayssap.blogspot.com/2014/02/guidelines-for-properly-customizing-sap_12.html

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