Upgrading your SAP System – Pitfalls and Processes for Success

Why Upgrade?

What compels a firm running multiple versions and multiple products of SAP to upgrade its ERP and other usage types? The (not always) obvious reason is the need for new functionality, which can better support company business needs and help them thrive in an ever growing competitive landscape. Basically, they want their business to run better than other businesses in their market. So a brief note on the release strategy for SAP applications, which follow a “5-1-2” maintenance concept: “5″ years of mainstream maintenance; “1″ year of extended maintenance at an additional two percent of the maintenance fee; and finally, “2″ years extended maintenance at an additional four percent fee. Not cheap, but it may be cheaper than a big upgrade project. After that, if you still don’t want to let go of the SAP release, there is always customer-specific maintenance, which is expensive.

I am sure that most of the decision makers are not aware of this information, and that is why I’m  writing this post.  SAP customers need to know of the additional investment they would have to make to keep their SAP system, running status quo.  I would encourage you, and your bean counters, to do the math on considering your SAP installations. After that, I am sure you would be compelled to focus on the upgrade (if not now, when?).

New Functionality

The main reason for upgrading has almost always been the additional functionality.  There are other reasons as well, like instance consolidation, virtualization, and requirements based on hardware, software and O/S.  Every SAP release brings new features, challenges and opportunities.  The need to upgrade is mostly driven by business needs, which in turn require new functionality in your SAP environments.  This empowers your company by transforming your processes and moving your company to higher levels of efficiency, richer reporting with new and improved analytic tools like BIA and HANA, and ability to make timely and informed business decisions.  The choice must be made whether to implement and develop the new functionality or perform an upgrade. This is not always an easy evaluation and the amount of customizing you do will certainly drive this decision.  This is the so-called “solution gap” and you have to ask, is the solution gap large enough to justify the SAP release upgrade?  And since SAP upgrades are time consuming and usually complex, is it worth investing time, money and resources to address this solution gap with an upgrade?

Yesterday’s Technology

SAP systems need to be constantly customized and enhanced in order to support evolving business needs. The time will come when the installed instances will no longer be able to suit your needs.  Staying on the same release is unsustainable from an infrastructure point of view as you will be required to stay on older hardware, software, and O/S.  If you have systems with many external touch points, it becomes more difficult over time to keep these working, especially if you are running much older SAP software. [Read more...]

SAP Data Migration – The Data Migration Plan (Part 2)

If you are responsible for the success of data migration, you will want to build a detailed plan that will walk you through all of the three phases of data migration: pre-data migration preparation, the data migration itself, and post-data migration cleanup.  I like my data migration plan to contain detailed steps that ensure that I don’t forget anything.  Each step lists a specific named responsible person along with their area of responsibility and contact information.  Unless I am responsible for executing the task myself, I prefer the named person to be a client employee (i.e. the business owner of the process) rather than a project consultant.    This is where the responsibility should be, and it requires that the business process owners actually participate in the activity rather than sit on the sidelines and watch.

[Read more...]

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...]