02/23/2009 by Dieter Steiger
The new concept of the Enhancement Packages (EhPs) from SAP is ingenious from a technical perspective. It’s actually too bad that SAP, the supplier par excellence for business software, has taken so long to create this software logistics concept. Based on the time and effort they’ve put in, any SAP CIO can tell you what this gap in the framework has cost customers. Yet it’s not quite as cut and dried as suggested in the Inside IT article entitled “No More Tedious Upgrades” dated February 4, 2009. The way Roche’s CIO Jennifer Allerton is quoted, one might be led to believe that specialists are no longer need for upgrades. Allerton explained to the Wall Street Journal that Roche had completed four complete upgrades in the last year, which required a team of 15 specialists. She believed that the new Business Suite would enable the company to avoid having to carry out upgrades. And this is a deadly fallacy.
There’s no doubt that from a software logistics perspective, SAP did its homework. But this perspective is restricted primarily to the impact of changes only within the scope of standard SAP software functions. Customer-specific modifications and integrations are not considered. Can you name a large-scale customer that has not carried out massive modifications on it system, expanded it, and integrated it into its application environment? By the way, this is not unusual for SAP. Even in regard to the innovations pertaining to the Solution Manager and the Transport Management System, the problem is always only perceived from the software manufacturer’s viewpoint. The customer’s environment remains the customer’s problem. “Switch technology” that forms the basis of the EhPs can also be used when customers want to expand the SAP standards themselves; however, ABAP developers first have to learn new development methods to suit this purpose.
Accordingly, the EhP concept does not pertain to customizing or modified functions in actual customer SAP environments. However, this is typically where customers put most of their money when they implement SAP. Change impact analyses for EhP activations remain absolutely necessary. SAP assistance tools will not be able to accomplish these in the future either. In fact, they will continue to require, and all the more often, the utilization of tools developed by specialized companies such as IntelliCorp or Panaya.
Differences between Implementing EhPs and Traditional Upgrades
a) When installing new and upgraded SAP functions on the SAP platform
EhPs can be installed at any time, although the physical effort remains the same. However for the users, activating new functions and thus the customization of business processes is no longer directly time-dependent on solely installing the new functions on the SAP platform.
b) When activating the new and upgraded SAP business functions for users
In a separate step from the technical aspects of installing new functions, activating them can be done for users at any time, supposedly in a dynamic manner also for sub-functions of the SAP release.
However, this dynamic holds hazards. Just as in upgrades, it is critical when preparing EhPs to be activated to gather additional requirements of the newly provided functionalities. This is necessary to analyze the effects of activating new functions provided by SAP on the configured basis as well as on changes being made to the system that stem from projects and support change requests.
By means of such analyses, the impact level of activating individual EhPs and necessary preparatory and post-activation tasks, such as test activities, can be determined. This will clearly reveal how much time and effort was needed to import individual EhPs.
The flexible and dynamic activation of individual “business switches” is all the more reason to require an impact analysis. First, it is exceptionally helpful, when thanks to analysis tools, it already becomes clear which transactions contained in an EhP are actually implemented in a company. Based upon the business user expectations generated by SAP marketing, the customer’s SAP competence center has to comprehensively analyze these transactions in a time-flexible manner for the EhPs to be activated. Then pre- and post-processing measures for activation can be initiated on short notice in a systematic manner.
Most SAP customers have experienced the effects, regardless whether they stem from upgrades or now from “activating EhPs.” The fully implemented application portfolio is repeatedly upgraded so that the new technical functions based on old technical operating modes can be maintained, instead of actively managing only the delta between old and new functionalities (documentation, tests, etc.), not to mention that one can access information from previous application changes.
The only real fix remains to invest in a sustainable SAP Application Lifecycle Management solution to support the competing implementation of SAP initiatives and SAP operations.
Summary: SAP Enhancement Packages as a Panacea
The considerable amount of time required to identify, implement, and test new and customized business functions still remains the same even with EhPs, and is perhaps even slightly more due to the flexible, step-wise activation that businesses find appealing.
Due to the newly provided business functionality, available in whole or in parts, the impact analysis has become more complex and certainly more time-consuming.
Now that the technical installation of EhPs has become time-independent, time can be gained in the provision of sub-functions. This time savings must absolutely be re-invested in the impact analysis and the corresponding flexible pre- and post-processing so as not to incur the risk of quality-related problems in production that could result in production stoppages. As a result of this time-independence and the growing complexity in the system itself, the time and effort required by lifecycle management tends to increase if anything. The assumption that thanks to EhPs, one can save on resources needed for managing changes to the SAP system quickly proves to be a fallacy.