In my last post on this topic, I discussed two negative effects of customizations in an upgrade project – risk and cost. I also discussed an obvious reason to eliminate unnecessary customization – the mitigation of risk and cost.
In this post, we will look at some of the customization areas which add risk and the cost to an upgrade project.
1. Direct Modifications to SAP Standard Objects
Direct modifications to SAP standard objects bear the highest risk. During the upgrade, these modifications will be lose–either because they will be overwritten by their respective upgraded SAP standard objects; or because these objects no longer exist and are not used by standard SAP in the upgrade system.
Typically, there are two reasons for performing direct modifications to SAP standard objects:
- The application of authorized individual OSS corrections to fix problems.
- Direct customer modification to provide business process enhancements.
1.1. Application of Individual OSS Corrections and Support Packs
Individual OSS corrections are patches supplied by SAP to fix recognized problems with SAP objects. Sometimes, individual OSS correction instructions are included and delivered within a specific level of support packs. That means that applying support packs to the specified level will apply the desired correction, and manual intervention is not needed. Sometimes OSS correction instructions are not yet included in any specific level of support packs, and these will need to be applied either manually or with the SAP Note Assistant.
It is important to carefully analyze the validity range of an OSS note to determine both how it was applied in the legacy system, and how it is to be applied in the upgrade system. This analysis will help determine how far to patch the upgrade system to make sure that the desired corrections are included in the upgrade system. Any needed correction that exists at a patch level beyond the highest patch level in the upgrade system will need to be addressed manually or with the SAP Note Assistant.
The decision of which support pack levels should be applied to the upgrade system must be made carefully. One approach is to apply the highest level of support packs that are available. The rationale for applying the latest available support packs is to insure that the most recent problem fixes are applied to the upgrade system. This is a two-edged sword, as the most recent support packs may also introduce other problems into the upgrade system.
1.2. Direct Customer Modification of SAP Standard Objects to Provide Business Process Enhancements
Direct modifications of SAP standard objects to provide enhancements are most costly and bear the highest level of risk. While direct modifications of SAP standard objects may have been technically expedient at the time of implementing the enhancement, they will always require additional work effort and analysis at upgrade time to determine:
- Whether or not the functionality provided by the enhancement is still required by the business.
- Whether or not the functionality provided by the enhancement is already included in the upgrade system as standard SAP. You will need the help of functional subject matter experts here.
- Whether or not the modified SAP object still exists in the upgrade system.
- How to move these required enhancements into the customer namespace, using the SAP preferred enhancement procedures. Moving these types of enhancements to the customer namespace also moves them from the very costly and highest risk category to a lower cost and lower risk category.
2. Custom Interfaces
Custom interfaces are loaded with opportunity for high upgrade risk. Take, for example, the SAP standard IDOC Basic Type, which was copied as the baseline for an enhanced customized basic type containing additional custom segments and fields. In the upgrade system, a new version of this SAP standard IDOC Basic Type may now contain additional segments and fields.
Likewise, the associated standard processing module for that standard basic type, which was copied as the baseline for an enhanced processing module to handle the custom segments and fields of the enhanced custom basic type, may also have changed in the upgrade to accommodate the new standard IDOC version.
So, in the upgrade system, especially if you need to implement the new upgrade IDOC version, it may be necessary to start with the new standard basic type and standard processing module, and reapply the customizations.
3. ABAP Code Objects
Of all customized objects discovered in most SAP systems, ABAP Code objects are the most numerous. These objects include classes, methods, function modules, report programs, dialog programs, and include files which support the all of the other ABAP object types.
At greatest risk are the SAP standard ABAP code objects which were modified directly in the SAP namespace; and those that were copied into the customer namespace and subsequently modified. This is because the standard SAP code objects may have changed in the upgrade. These changes can range anywhere from simple error corrections to complete process and code redesigns. In these instances, each modified object must be compared to its counterpart in the upgrade system to determine its existence, and the nature and extent of what might have changed. If the customization is still needed in the upgrade system, and to stay current with the enhanced standard code, it is probably best to start with the upgrade standard code and reapply the customizations.
ABAP code objects that were developed entirely in the customer namespace (not copied from standard SAP code) are usually low on the risk ladder. Problems occur when data selected by these objects has moved elsewhere or behaves differently in the upgrade system, when ABAP constructs used are now obsolete in the upgrade system, or when standard called functions are changed in the upgrade system.
Ultimately, the business must decide why SAP standard code was directly modified, why SAP standard code was copied into the customer namespace and modified, why custom code was developed entirely within the customer namespace, whether or not any of these modifications are needed, and how they might be implemented differently in the upgrade system. This evaluation presents another opportunity to remove some rocks from the customization rock bag.
4. Automated Standard SAP Transactions
Custom ABAP programs which automate standard SAP transactions bear an above-average risk. This is because the behavior of some SAP transactions may have changed in the upgrade. These changes can be manifest in the functional performance of the transaction, the technical location and existence of data fields on screens, screen field properties, IMG configuration specific to the transaction, the transaction code associated with the transaction, or even the existence of the transaction or an equivalent in the upgrade system. The nature and the extent of the changes to the transaction in the upgrade system will determine the amount of effort needed to automate it.
Also, if an “old” SAP transaction has been replaced by a “new” upgraded equivalent, it is usually wise to make the change to the new transaction at upgrade time. At some point in the future, the “old” version of the transaction will become obsolete and no longer useable or supported.
5. Data Dictionary Customizations
Many customizing projects within SAP require the storage and manipulation of data that is not included in the standard SAP dictionary. One way in which these requirements can be addressed is by building complete custom transparent tables and data structures. Another way is by adding append structures and append fields to existing standard SAP tables. With either approach, it is always an excellent idea to evaluate the need to move these customizations into the upgrade; and another opportunity to lighten the customizing bag of rocks.
6. Customer and User Exits
Customer and user exits are provided by SAP as the SAP-approved mechanism for enhancing standard functionality. Enhancements performed within these boundaries are guaranteed by SAP to bear low technical risk in an upgrade situation. While SAP guarantees that the custom code will arrive technically intact in the upgrade system, functional analysis must still be performed to determine the continued need for the enhancement in the upgrade system.
Any enhancement implemented in a customer or user exit that is either functionally covered or determined to be unnecessary in the standard upgrade system should be retired. This is consistent with the goal of lightening the load in the bag of rocks. Since a customer or user exits may implement several different enhancements, take extra care to make sure that only the right code or other objects are retired.
7. The Environmental Effects – Operating System Change
OK, changing the operating system during an upgrade project is not customization of SAP objects. But it does add risk and cost to the project.
If the upgrade operating system changes from UNIX to Windows or vice versa, then any ABAP program or interface which reads or writes a data file to an operating system folder must be changed. The changes needed to these ABAP programs are very narrow in scope, and reflect the manner in which the operating system specifies its file paths. Additional BASIS work, such as determining the proper file system authorizations, may also be needed.
Using the SAP logical file name facility can help enormously by removing the need to make changes to hard-coded file names and path names in many different ABAP programs.
Share Your Experience
At the top of this post, I stated that I would discuss some of the customization areas which add risk and cost to an upgrade project. I look forward to hearing from our readers to reply to this post with their own experience with customizations, how they were handled, and how this affected an upgrade project.
In my next post on this topic, I will reveal some of the techniques I use to “discover” customizations, even in the absence of documentation.
[Editor’s Note] This blog is the second of a multi-part series: