Changing (Enhancing) SAP Standard – The Way to Differentiate
Co-authored with Marc Cyr.
One of the topics we are consistently asked by our clients is about changing SAP Standard. How can we change SAP Standard? Are changes supported by SAP? Would changes be overwritten during an upgrade? As we all know, a successful consultant will start with “It depends” followed by a discussion in order to provide a helpful response. But in actual fact, the answer does depend on how the SAP Standard is being changed, what is the business value added by changing SAP Standard and what are the costs associated with making the change.
In this blog, we are going to answer these questions and also provide information about guiding principles for changing SAP Standard that we have developed over the past several years.
Before we start, we need to understand what is SAP Standard. SAP delivers various solutions to its customers to meet wide-range of common needs as SAP Best Practices. SAP customers can explore SAP Best Practices via SAP Best Practices Explorer* and deploy them without making changes (i.e. out-of-the box). These solutions are called SAP Standard (also referred to as ready to run).
*SAP Best Practices for SAP Solution Manager 7.2 processes cannot be explored in SAP Best Practices Explorer and must be downloaded to SAP Solution Manager 7.2 in order to explore. For more information about how to download SAP Best Practices for SAP Solution Manager 7.2 processes, please see our previous blog SAP SolMan 7.2 Insights… How to download SAP Best Practices Package (SAP BPP) for SAP SolMan 7.2 processes.
The SAP Standard solutions are based on industry standards. Most customers do not run SAP using SAP Standard to a tee. Why? Because SAP Standard by definition, is not a way to differentiate. In order to achieve a competitive advantage or to run a customer specific process to comply with policy and business demands, changing SAP Standard is the only choice. The good news is SAP provides different approaches to changing SAP Standard when there is a need to differentiate and a clear link to business value.
To understand the fundamental options available, we simply have to look at Change Request Management (ChaRM) process in SAP Solution Manager used to manage changes. In ChaRM, as part of the process flow, the Service Expert (Functional Analyst/Developer) creates a Transport Request when making a change. Without getting too technical, there are two types of Transport Requests:
- Customizing – used to manage Configuration changes; and,
- Workbench – used to manage Development changes.
|There are two approaches to making Configuration changes to SAP Standard:
And there are three approaches to making Development changes to SAP Standard.
Personalization of SAP Standard
Definition: Personalization of SAP Standard means adjusting SAP Standard to simplify and personalize user navigation: User Interface (UI) personalization to adapt the interface to user’s preference.
Impact SAP Standard Code? No. Personalization of SAP Standard does not impact SAP Standard code.
Overwritten during Upgrade? No. Personalization of SAP Standard is not overwritten during upgrade.
Example: Select a different skin for CRM UI.
Customizing SAP Standard
Definition: Customizing SAP Standard means adapting SAP Standard to meet customer specific requirements. What this means is the SAP Standard code is executed or ignored depending on the customizing performed. Configuration changes for customizing SAP Standard can be done via SAP Implementation Guide (IMG) or guided procedures provided by SAP.
Impact SAP Standard Code? No. Customizing SAP Standard does not impact SAP Standard code.
Overwritten during Upgrade? No. Customizing of SAP Standard is not overwritten during upgrade. However, it is a good practice to adjust customizing in the customer namespace to align with the latest version of SAP Standard introduced as part of the upgrade. In certain situations it is strongly recommended by SAP. This was a perfect example during SAP Solution Manager 7.2 upgrade – SAP KBA 2394599 (How to handle your Z transaction types after the upgrade to 7.2).
Example: Hide an existing field in the CRM UI.
Enhancement to SAP Standard
Definition: Enhancements are “hooks” provided by SAP for enhancing SAP Standard to extend the business logic that hasn’t been provided in the standard. SAP anticipates that companies will make use of these enhancements to address unique business requirements. Enhancements can be done with standard interfaces (BAdIs, customer exists) or without interfaces (implicit/explicit enhancements directly in the source code).
SAP Severity Level (indicates how far Development changes differ from SAP Standard on a scale from 1 to 5): 1
SAP Recommends: To use enhancement with interfaces as the preferred way of enhancing SAP Standard.
Impact SAP Standard Code? No. Enhancements to SAP Standard do not impact SAP Standard code.
Overwritten during Upgrade? No. Enhancements to SAP Standard are not overwritten during upgrade.
Example: Create a new field in CRM UI using Application Enhancement Tool (AET).
Definition: Custom code solutions are “bolt-on” solutions that are developed outside of SAP Standard to address missing functionality in SAP Standard. Custom code can be done independent of SAP Standard code (standalone solution in customer namespace) or with reference to SAP objects. The latter is not recommended by SAP. “SAP strongly recommends that you only reference SAP objects that are released for customers. Failure to do so can cause problems when updating your SAP software.”
SAP Severity Level (indicates how far Development changes differ from SAP Standard on a scale from 1 to 5): 5
SAP Recommends: To avoid custom code whenever possible in order to remain as close as possible to SAP Standard. Before developing a custom code solution, make sure that the requirements cannot be fulfilled by Customizing, Personalization or Enhancements.
Impact SAP Standard Code? No. Custom code solutions do not impact SAP Standard code.
Overwritten during Upgrade? No. Custom code is not overwritten during upgrade. However, any custom code with reference to SAP objects is overwritten during upgrade by new SAP objects delivered in the new release and will require adjustments during the upgrade.
Example: Create a new field in CRM UI using custom code.
Modification of SAP Standard
Definition: A change to SAP Standard code, logic and objects to meet business requirements. Modifications are the most expensive way to changing SAP Standard in terms of development and maintenance costs. Modifications can be done with tool that assist modification or without tool assistance. All modifications must be registered with SAP Software Change Registration (SSCR) application.
SAP Severity Level (indicates how far Development changes differ from SAP Standard on a scale from 1 to 5): 3
SAP Recommends: To avoid modification to SAP Standard wherever possible given the cost and risk involved. “Only perform modifications with the help of the modification assistant and when there is no other option. “
Impact SAP Standard Code? Yes. Modifications to SAP Standard impact SAP Standard code.
Overwritten during Upgrade? Yes. Modifications of SAP Standard are overwritten during upgrade by new SAP objects delivered in the new release. In order to retain the objects that have been modified in a previous release, modification adjustments are required in SPAU and/or SPDD during the upgrade.
Example: Modifying elements in the SAP Standard code for CRM UI.
The following order is recommended when selecting the approach for changing SAP standard (left to right).
When deciding to change SAP Standard, we must not lose sight of the inherent costs: one-time cost for development and yearly cost of maintenance; and how to efficiently and effectively manage Development changes. Remember, all changes to SAP Standard must be linked to business value. But these are the topics for another discussion that we will include in the next blog.
We are looking forward to your comments. If you want to follow us, you can find us on:
Marc Cyr LinkedIn