Wednesday, February 12, 2014

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

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.