Get Ready for SAP Enhancement Packages (2): The differences between enhancement packages and release upgrades
The nature of implementing an enhancement package (EHP) is significantly different from a release upgrade, even though both types of projects also have some common characteristics. It is worthwhile to look at the details of this comparison. Oversimplifying the implementation of enhancement packages leads to unrealistic expectations and unwanted surprises during your implementation project.
With SAP Enhancement Packages, new functions can only be configured, realized and used AFTER the corresponding business function has been activated. This is the most obvious difference between EHP and release upgrade, In other words: All new functionality is hidden behind switches and remains invisible for end-users until you explicitly request to use it. This allows you to separate more strictly between the installation on one hand and the configuration (after the activation) on the other hand.
Lets look at these two steps – installation versus activation – and frame the differences as well as the similarities. The following graphics will help you visualize this explanation.
Partial Installation – A technical upgrade to a new release always means that the coding of all software components is completely replaced – also those objects that might not have been changed since the source release. With SAP Enhancement Package, typically only subsets of software components are touched. The ones that are replaced depend on the functional enhancements that you want to use afterwards. The clearly recommended path is to FIRST select the new functionality of your interest, and SECOND to install only the relevant parts that your selection requires. Please note that this option is designed to leave your system as stable as possible. If you prefer not to use this option, that’s absolutely fine provided that you are willing to accept longer installation times and potentially more objects coming up in the SPAU transaction. (SPAU is the transaction that brings up modifications that you had included in those ABAP objects that are now being updated.)
Delta Update Procedure – For each updated software component, only sublets of objects are replaced. The others are not touched in order to ensure maximum stability of your solution.
Strict development rules – Table splitters and data migrations are strictly forbidden. Applying these principles when developing SAP enhancement packages for SAP ERP means the risks of installing updates are kept to a minimum. No upgrade customizing is necessary after the installation unless new functionality is switched on.
All these aspects relate to new functionality that comes with enhancement packages. Please be aware that you can also install corrections along with the enhancement packages. The methodology concerning corrections has not changed. Therefore, the pure installation of an enhancement package still requires testing activities – even if no business function has been activated yet.
Installation Tools – A common practice of both these scenarios, upgrades and enhancement packages, is the fact the installation procedure can be executed with the transaction ‘SAINT’, just in case you are familiar with this one. For SAP Enhancement Packages, the better way to install is using the ‘SAP Enhancement Package Installer’ which drastically reduces the technical downtime.
To summarize, the aspects explained above reduce hardware costs, lower risk and manual efforts, accelerate the installation of new functionality, and reduce efforts for modification adjustment if compared with a technical upgrade project. The overall installation effort including regression testing is approximately as high as moving on to another Support Package Stack.
Shorter innovation cycles – Once the SAP enhancement package is installed, each business function may be activated separately and as needed by the operating departments. This enables the IT team to schedule new implementations in smaller steps that are easier to handle. Comparatively, temporary peaks of IT projects – as were needed for upgrade projects – are spread into a more even workload and a more constant risk distribution over the time.
Predictable changes – The good thing is – for every business function activated, you will know the affected business processes. This is documented in standardized test case descriptions.
Limited testing – The testing scenarios described in the standard test cases should be included in your end-user test before you go-live with the selected functionality. You may want to use these as testing templates as a baseline for custom test cases which describe custom business processes. It is NOT necessary to do another regression test (across all critical business processes of that system) at that point. It is NOT necessary to make another modification adjustment.
Stability for non-affected end-users – The activated functionality will bring up new fields, reports, business processes, IMG settings, etc… only within the described, limited operational areas of the activated business function. Other end-users, not in these limited operational areas, will not realize any system changes. Thus, allowing them to continue their work without any disruption.
Now you should have the right expectations towards implementing an SAP enhancement package. Please let me know your questions, comments, and what else you are interested in. Your feedback is more than welcome!
Best regards, Doris.