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.