SAP Cutover Practice for Risk Reduction
SAP system upgrades, support packs, or data conversions into production can be a very stressful and time-consuming activity. A good way to remove some of the negativity and gain confidence is for a ‘SAP Cutover Practice’ activity. Although this does require additional hardware (at least temporarily), the benefits from this activity are well worth the cost.
SAP Upgrades & Offshore Resources
It looks like it is official: 2010 is the year of the upgrade. A little validation is good for my self-esteem. Now that’s out of the way and I’m polishing my attaboy trophy let’s get on with it.
In this post I’ll do a combined discussion about the use of offshore resources in an upgrade project as well as share some experiences working with remote resources. My colleague, Mike Salvo, has already discussed ABAP customizations in an upgrade in this post. Now that you’ve found these customizations, what do you do next? Actually Mike provides loads of good advice about what to do next in terms of sorting out what is in the overall pile of objects that need to be examined.
What I hope is that you have documentation related to these objects: information that tells you why they were created, what they do, where SAP functionality is deficient in the current release and how you worked around the shortcoming. This should be helpful in making the evaluation about whether you can remove a particular object or if you need to make sure it works in the new release in a way that satisfies your business and/or technical need.
I going to assume that you have been through the “bag of rocks” analysis described in Mike Salvo’s posts and now have a collection of pebbles, stones and boulders to work through. This is where you can make good use of offshore resources to help out: there’s a lot of discussion about the use of offshore resources and you can use them really well or really badly. Let me digress.
Read more
SAP Upgrades & Recycling Project Artifacts
In my previous post on SAP upgrades I discussed how to get started on your project and to determine whether you are doing (ahem!) just a technical upgrade or intend to venture into deploying additional standard functionality, too. In this post I’ll talk about how you can plan, anticipate and potentially accelerate some of the execution activities to verify the upgrade is working.
21 Things to Remember for Your Next SAP Upgrade
Is it time for your company to consider an SAP Upgrade?
The choice to upgrade your company’s SAP platform is a very important business decision. Many criteria need to be considered when determining if an SAP upgrade is the right move and, if so, what type of upgrade needs to take place (ECC 6.0, Enhancement Packs, etc.). A successful SAP upgrade requires the determination of your upgrade requirements, proper planning, and an assessment of technical and functional risk. Below is a sample of our SAP Upgrade Checklist white paper:
Determine Your Upgrade Requirements
- What are the business reasons for upgrading? Support from the business for an upgrade project is most important. If there are no business reasons for upgrading, then you should probably not do it. Included here are the business risks incurred by not upgrading.
- What are the technical reasons for upgrading? Included here are the technical risks incurred by not upgrading. (Posture increasing maintenance fees for old versions or complete support withdrawal as a business risk – not a technical risk.)
For the complete list, download the full white paper:
SAP Upgrade Checklist
Related Links:
It’s SAP Upgrade Time! Do You Know Where Your Customizations Are? Part 1.
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.
