It’s important to keep your SAP system in tip top condition and one of the many ways to do this is to keep up to date with patch levels and support packages. In the ideal world a software patch or even a support pack or support pack stack update does no more than increase the stability of your environment and perhaps improve performance.
Life has been perhaps made a little easier with more automation of the patching regimen.
For some time now, SAP customers have been able to use the maintenance Optimizer with SAP Solution Manager.
This means that when you kick off with a system maintenance cycle, the Maintenance Optimizer can read the data from the specified product version, and suggest files and systems for maintenance updates. SAP provide a good reference note on this Note 1024932 - Maintenance Optimizer: Collective Note and you can read more about the maintenance optimizer at http://service.sap.com/solman-mopz Often the suggestion will be to apply a support package stack.
Support package stacks are a combination of support packages and patches which were tested together by SAP, and whose implementation SAP recommends, or possibly even requires. These shouldn’t be confused with Enhancement Packages which bring additional functionality or features to your SAP environment.
43% survey respondents implement complete support package stacks
A recent survey shows that the most dominant correction implementation policy among SAP customers by Panaya Inc in 2009 in a SAP Support Costs Survey indicated that 43% of the survey respondents are implementing complete support package stacks which of course means a great many more changes to the SAP environment than simply implementing a few notes.
You could deduce that an Enhancement Package could bring significant changes to your environment but you would be forgiven for thinking that a patch or support package only fixes problems.
Unfortunately that is the ideal scenario and not necessarily reflective of the reality in that sometimes those who support a given solution component or technology need to do a major rewrite of a component to introduce stability or to fix a design flaw.
Under such circumstances the results for the recipient of the patch can sometimes be less than ideal. Some patches close exploit vulnerabilities or change behavior in the software that prevents things like transaction recordings from working at all whereas in the past they may have worked satisfactorily but not perfectly. In some instances you may even land up with some SP stack mismatches as is demonstrated by the HCM wiki on the topic: http://wiki.sdn.sap.com/wiki/display/ERPHCM/ or unwanted side effects of notes contained in Support Packages which you can review a report of at https://service.sap.com/side-effects : this is one of the resources you should be reviewing as part of your testing efforts before going live with a change.
So we come to the current challenge that I see in some customer environments. How does your business stack up relative to these statistics?
Lately I have seen a number of Winshuttle customers apply support patches, packs and stacks to their systems and found that they have broken some of the recordings and even API distillations that they have come to rely on to keep the lights on in their business.
In these belt-tightening times there are few businesses that can afford the luxury of dozens of data entry personnel if they can achieve the same results more effectively and efficiently with a transaction recording and that is why they have deployed them. Sure, they could have some ABAPer develop and LSMW to do some of these things but then every time they have an unexpected error or need a change the cash register chimes as they pay consultant or service dollars to do an investigation or make the change when they could easily make the change themselves without technical assistance.
Support packages require extensive testing
As Panaya points out, implementing support packages requires extensive testing and also some level of code freeze throughout the implementation project, it inevitably presents a disruption to the IT project plan. Organizations find it difficult to frequently stop everything they are doing and shift their focus to support package implementations but regrettably this is critical to being successful and avoiding work stoppages.
You’re once again encouraged to test exhaustively in dev or QA, any changes that you make to your SAP system and patches and support packs should not be given any less attention than enhancements to your SAP environment.
It is understandable that sometimes you might need to fast track a particular change in your environment and that perhaps that change needs to be put into effect without a complete understanding of all the minutiae of the changes but that should be the exception rather than the rule.
I’ve said it before and I will say it again, there is no good replacement for a proper inventory of your core business processes and the technologies that you use to support those. This is especially true if your business has a set of active business unit application development initiatives. It is incumbent on IT to be aware of these BUAD’s and it is crucial that business make sure that IT is aware what the importance is of these artifacts.
Documenting them well, understanding who owns them and how they are supported is key to maintaining business continuity. Diligence should be the watchword for all those working in an SAP environment that knows that changes are headed for their productive systems if they want to minimize the effects of all those butterflies.
