SAP Updates – Why and How

Did you like our article?

Updates to SAP solutions are usually a headache for most businesses. First, the need to update is not acknowledged unless the versions are becoming totally obsolete. Second, an efficient methodology to manage these projects is not readily available, so they are often addressed as an upgrade project in an “old-fashioned” way (for example, from ERP 5.0 to ERP 6.0), with high costs, deadlines, and risks, although it is now unusual to find SAP solutions in very old versions.

We are not referring to platform updates (operating system or data engine), nor SAP Kernel updates, which are more technical and simpler, but to those known as updates or SAP Enhancement Packages (EHP) applications, and to the Support Package Stacks (SPS) applications, since at present and, most often, the two go hand in hand.

Why update SAP

In general, SAP recommends applying SPS every six months and EHP once a year, along with SPS. IT managers usually have a hard time justifying these projects to the business areas, due to the costs involved and the stress they pose to the organization. What are the rationales that validate these update cycles?

• New features. Each EHP provides a set of new Business Functions that can be activated and put to good use by the business, provided that an innovation or continuous improvement discipline is in place. Every client pays SAP a considerable annual amount to be entitled to these innovations and it is common-sense to make good use of them.
• More stability. Each SPS includes a large number of corrections for all bugs known up to the date of its release. By applying them, the client prevents each of these failures from occurring, with the consequent savings in costs associated with the impact of an incident, its diagnosis, and its correction.
• Better performance. Similarly, each SPS includes improvements and optimizations to SAP programs performance, which are the result of adjustments to the performance problems detected.
• More compatibility with new projects or developments = lower risk. In many cases it happens that, when starting a project, the client finds an incompatibility with the version in use, forcing an update before starting. This impacts on the original project by extending its deadlines and increasing its costs unexpectedly.
• Better maintainability. Sometimes, as a result of an incident or an enhancement, it becomes necessary to apply a SAP Note. When analyzing the note related to the (outdated) version of the system, it is discovered that three other notes must be applied as a prerequisite. When examining those three notes, maybe another 10 must be applied, etc. In extreme cases, the number of notes results in an effort equivalent to that of an update.

Since SPS and EHPs are massive updates, generally it is not a good strategy to make an analysis of the new functionalities when justifying the change to the business area. The best practice is to apply the updates unconditionally and execute a regression testing plan.

However, it may occur that the business has planned an improvement or specific project, and the update is then better justified, because there is a new functionality that applies to the request. In these cases, it is possible to use the SAP Innovation and Optimization Pathfinder application, which SAP makes available to its clients. (See more at https://bpi-discovery-proxy.cfapps.eu10.hana.ondemand.com/request/PAF/).

How to accomplish efficient updates

The previous arguments should suffice to justify a regular update of the SAP solution. However, the associated costs and efforts are still important, especially since this is a regular activity, that should be done at least once a year. As mentioned earlier, these are not upgrade projects like those that were done in the past, once every five years, for example, or even more (although some companies still regard these updates in the same way and postpone them as much as possible).

Consequently, it is reasonable to use a methodology that allows the reutilization of the products generated by the project, such as process documentation, test cases, etc., based on tools that automate or optimize the tasks associated with it. Such a methodology makes it possible to reduce costs, efforts, and impacts on the organization and thus, at the same time, becomes an additional way to justify periodic updates.

An optimized methodology

A methodology that optimizes update projects should consider the following elements:

• Use of SAP Solution Manager (SolMan), including tools such as SEA (Scope and Effort Analysis), SDA (Solution Documentation Assistant), BPCA (Business Process Change Analysis), CBTA, ChaRM (Change Request management), etc.
• Reusable documentation. The methodology should include the generation of process and test documentation that is reusable in subsequent updates. At a higher level, it is even possible to automate the tests, as long as the organization can uphold the required discipline.
• Project Roadmap in SolMan. The functionality of Project Roadmap makes it possible to follow the standard SAP update methodology, control progress and deliverables, etc.
• Correction management cycle supported by SolMan. The management of corrections generated from the tests can be treated with the same logic as in incident management, using SolMan’s ITSm functionality.
• On-demand consulting team. The consulting team to support the project can be available on demand for the most part, especially the more specialized and costlier consultants. In this way, the substantial costs of a dedicated team are not incurred for the entire duration of the project.

At Novis we have the responsibility of maintaining the SAP systems of more than 70 clients. As a result, we permanently handle a queue of update projects. This has compelled us to generate a recurrent process, with an optimized methodology, taking full advantage of the tools and practices that SAP makes available to its clients and partners.

Bonus Track: The “N-1” Patch Myth

Many clients apply the policy of upgrading to the penultimate (“N-1”) patch available. While this policy may be appropriate for operating systems or data engine patches, it is not suitable for SAP EHP or SAP SPS. If the latest SAP ERP EHP has been released more than two months ago, it makes no sense not to take the opportunity to upgrade to this last EHP. It could only be justified not to do so when there is a risk of a too recent EHP or SPS, that is, released less than a month ago.

At the other end, an EHP may have been released 9 or 10 months before the update time, in which case the risk of applying this EHP is practically zero, and in relation to the “N-1” patch, has significantly greater benefits.

Bonus Track 2: Migration to HANA and S/4HANA

Many clients consider migrating to HANA in the context of an update, as a prior step to the S/4HANA migration.

It is important to clarify that having an ERP in HANA, or in another data engine, makes practically no difference in relation to a subsequent S/4HANA migration project, whether it is a conversion or a reimplementation (Greenfield, Brownfield, Greenfield, or other migration).

Migrating to S/4HANA is a major project, where difficulties and efforts lie elsewhere. Therefore, unless you really want to exploit some of the benefits of an ERP (or other SAP Business Suite system) on HANA, this is not a reasonable justification.

In short, we do not recommend migrating to HANA if the only (apparent) benefit is moving towards a migration to S/4HANA. Nothing is gained. It should only be done if this renders benefits per se.

For more information on SAP updates and migrations to SAP HANA, we have prepared these three videos:

• Why update SAP? (6 minutes)
• Upgrade and migration to SAP HANA in one step (3 minutes)
• SAP upgrade and migration services (8 minutes)

We will be glad to be able to advise you on this or other subjects. Contact us.

Author: Glen Canessa

Related articles:

• Novis SAP Update Services
• SAP Security Notes – Keeping up to date