What does updating SAP systems mean? This question is being asked very frequently when I start SAP sales meeting with a customer. When it comes to implementation of such huge information system that affects almost all business processes in a company it’s a reasonable question what to do in case of software error or law and regulations changes. You can’t fix it like fueling your car or inflating tires. It just time that would cost you money and it’s better to be prepared.

I can confirm SAP AG issues updates regularly. For main functionality, I’d say monthly or every two months. So, to prevent you from quick decisions, I can say you’ll be safe with vendor service and timely updates. There are some rules to follow to make your life easier but we’ll cover this later. I’m more in SAP HCM area so could lose some details in update processes, so don’t judge me harshly.

Types of SAP updating

Updates are different. As a rule in IT we used to think of updates as a bug fixing in software, new legal requirements. It’s some sort of a package that’s being installed into the system and everything starts working smoothly as it supposed to work. It’s semi-true for SAP. One side it’s a package that fixes and updates something, another side is a complex process that usually involves a lot of people and takes months to accomplish. Business customers wait for one-click install, IT nerds demand months of testing, acceptance and rollback plan signed by the business owners. Why? Let’s figure it out.

The smallest unit to update the system called note. It’s a small fix or manual or recommendation from the vendor how to fix an error or implement a change. A note can be manually downloaded from SAP Marketplace Portal, can be automatically applied to your system (when prerequisites are fulfilled) and error will be gone. Usually, note contains text description part, causes, steps to solve the issue. If an error occurred in ABAP code note contains a piece of ABAP code to change. The system does changes by itself. These notes could be rolled back.

Some notes contain step by step manual what to do, what records to create, what rules to change to fix the error or update tax tables. These notes with manual part are usually can’t be rolled back by the system.

You can download note manually, or within SNOTE transaction or from SUM (Software Update Manager). Choose a note by its number, the system downloads it, read the description, and apply it with a button. The system performs all needed checks and corrections, dependency management.

Notes are installed into Development system within your landscape. The system saves them into transport requests and transport along the route. There are notes with XML files, templates, XSLT and other support docs that are needed to be implemented manually. It means you need to apply only these files (usually upload in a specific transaction) to each system in a landscape. If you install the whole support package there is no need to do this.

When they meet a critical number of notes SAP releases support package. These packages could be installed by system administrators only. Support packages not only large units with hundreds of notes but also a tree of dependencies that could be installed in a queue altogether. Let’s say you want to update only Finance Module, but when you build the stack of support packages SAP throws you a couple more packages from Basis, ABAP or Logistic modules. It happens because of dependencies and can increase update time. You need to take this into account. Sometimes it’s even worse when some support package requires you to update system Kernel that wants to update your database and so on.

You can’t rollback support packages. Once installed they’re forever there, that’s why you need a good plan and to backup the whole system before you start. It’s not a joke.

Planning updates

Once you have installed support package into development system you need to test it with your support team. You need to have a test plan. There are a number of test scenarios you should have in your company, I’ll share my thoughts with you in some next articles. Before that, you need to think about test tools and procedures. When developer tests its solution in development system he reviews only a small part of the process. Then key-users test solution in Test or Quality system. They need to reviews all the processes within your company as even small update can affect some leaves of your process tree. And only then you move support package to the Production system. And it’s the easiest scenario cause sometimes you need to stay with release approach, change management procedures, pre-live systems, a number of test cycles including workload test.

I recommend using automated test tools to save your time and money of potential business loss. There are a number of tools freeware and paid where the most known is HP Quality Center that is integrated with SAP Solution Manager and eCATT which comes with SAP and absolutely free. We recommend to start with eCATT and automate main business processes with regression testing when system repeats all main test scenarios, business processes and verifies the output. It’s free and very powerful when you know how to manage it.

Besides the legal updates and bug-fixing, there are two more update classes which enrich the system with a new functionality. These are AddOns and EhP (Enhancement Package). First one is a complete specific business solution that is activated after installation. Like a new module we just brought to a system. AddOns usually have own documentation, own IMG tree and it can’t be rolled back.

EhP is a more complex and flexible solution. It’s much like AddOn, but when you install it, it’s off by default. You need to go to a special transaction to activate just one of a number of business functions within one EhP stack. It could be a new functionality, new user interfaces for mobile/portal apps, new localization. In other words, something useful that improves user experience but not necessary to run your SAP system. These business functions are great in that they are reversible sometimes. It means you can activate and deactivate some of them if you’d like to. When you plan your releases and upgrades it’s a good idea to have your system updated and you can even install EhP package without letting users know.

Recently, more and more functions appear in EhP, and AddOn is used for third-party solutions that are installed in addition to SAP.

And there is a change of versions of the whole system. It used to be R/2, R/3, 4.0, 4.5, 4.6, 4.7, 5.0, 6.0, S4/HANA – the whole generations where something was changed globally.

Updates themselves are free of charge while you pay for Support to SAP. It usually 18-22% annually of your contract. When you change global version there could be additional charges to move to the cloud, new database or something like that how it happens now when you move to HANA.

Don’t forget, the more often you update the system the easier it would be to support SAP and implement new functionality. And it actually doesn’t affect how much ABAP code do you have. There is what I name ‘Clever ABAP’ which fits well into the system and doesn’t bother you in updates. I’ll tell you about this in a while.

The most important part of my speech: the more backups, the more you’ve tested, the fewer issues you’ll have. On time backups have saved a lot of vacations…