It’s SAP upgrade time! Do you know where your customizations are? Part 1.
On several occasions, I have been engaged on projects with statements of work containing some or all of:
HELP! We need to upgrade our SAP system, and we do not know what has been customized, and our original implementation partner has been gone for over several years, our several enhancement partners are also long gone, best-practice controls were never implemented, we have no documentation, and we need all of our customizations, whatever they are and wherever they are, to behave correctly in the upgrade system.” (And I’m sure that you can add to this list!!!).
At the time of initiating the engagement with a client, how this happens and why this happens is not important. What is important is that there can be an assessment of the risks, an evaluation of the costs, and an understanding that it may be possible to significantly determine the extent of the customizations, even without documentation. The customization discovery process, then, becomes a matter of knowing how and where to look.
Early in the process, I remind my clients that customizations are expensive to create, expensive to maintain, and expensive to upgrade. I like to use the analogy that custom objects are like a bag of rocks which you must drag forward with you into each upgrade. Of course, if we can empty some of the rocks from the bag (i.e. eliminate unnecessary customizations), then the dragging becomes less labor intensive, the upgrade risk is decreased, and the upgrade cost is lowered.
To assist with emptying the customization rock bag, I start with the concept of custom object usage. It’s always eye-opening for a client to discover that those “must-have” and “can’t go live without” custom reports, custom data tables, custom transactions, etc., have not been used in a very long time. The concept of “very long time” varies for each customized object because some business processes are exercised only quarterly, semi-annually, or annually. Even more disconcerting to the client is the knowledge that they were expensive to design and build, and continue to be expensive to maintain and support. And now, even if we have to stop and briefly analyze whether or not they should be brought into the upgrade system, here they are again exacting yet another cost.
Another way to empty rocks from the bag is to show that the standard upgrade system is already enhanced to include the desired customized function. The functional subject matter experts from the business should be adept at doing this. In fact, they may have already done this exercise as the formulation of the business case for doing the upgrade in the first place.
Yet another way to empty rocks from the bag is to show that the enhancement embodied by the customization was present in the legacy system all the time; and is likewise already included in the upgrade system. Maybe it was not recognized, maybe it could have been implemented via configuration, and maybe it was just too easy to throw it over the wall at programming, rather than figure out all of those configuration switches and table values. Whatever the reason, here we are, and there is a better, less risky and less costly way to do it within the standard SAP system.
Custom Object Upgrade Risk Assessment
It is expected that SAP will have enhanced its standard processes in the upgrade system, and that these enhancements may alter the behavior of, or render any customization obsolete.
Custom object upgrade risk assessment is merely a probability that a custom object will or will not perform correctly when migrated to the upgrade system. It embodies the reality that some customizations performed in the legacy system will fail to work at all in the upgraded system; some will transfer, but will require additional work effort to adapt them to the new upgraded environment; and some will migrate cleanly with no additional work effort needed.
There are no guarantees. Even a simple report with a seemingly low risk assessment will fail in the upgraded system if the data being reported changes location, format, or function in the upgraded system. And it may silently fail in the very sinister way of appearing to work correctly while, unbeknownst to the user, actually reporting incomplete or incorrect results. It is imperative, then, to exercise all customizations in the upgraded system with staged data, test scripts, and comparison of actual results to expected results, to make sure that they continue to perform as expected.
Read the Full White Paper: SAP Upgrade Customization Analysis
Please fill out the form below to receive access the whitepaper. The whitepaper.pdf document will be sent to the Email address provided below. This paper looks further into some areas of object customization and discuss their relative risk and cost impact on an upgrade project. In the meantime, please feel free to reply to this post to share your own unique experiences with customization discovery and upgrade risk.
Related Posts
SAP Upgrade Project Management Considerations
SAP Upgrade Project Plan
SAP Upgrade Checklist
