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

It’s SAP Upgrade Time! Do You Know Where Your Customizations Are? Part 3.

In my final post on this topic, I will discuss some of the techniques that I use to “discover” information about customizations in an SAP system, even in the absence of any documentation.  The information available to be discovered may include such details as the object name, object type, user name of the person who made the last modification, date and time of the last modification, usage statistics, where-used, and for code-based objects, even the versions and their code differences.

[Read more...]

SAP Go-Live Lessons Learned

In real estate the key factors in making the sale are location, location and location.  In an SAP project I’m coming round to believing that success requires testing, testing and testing.

A Short Selective Retrospective on Key Constituencies

All project events and project success stem from testing and testing well.  I’ve written about various types of testing before and how that can lead to some confusion because of issues with definitions.  Here I want to discuss some areas where testing really can make or break a project and ideas for how to minimize the chances of things turning out badly. [Read more...]

SAP Data Migration – Answering the Important Questions (Part 1)

It is data migration time on your SAP business project.  Whether your project is implementation, acquisition, or merger, the goal is pretty much the same: the seamless inbound acquisition of master and transactional data from one or more external data sources while ensuring that this activity has minimal impact on the rest of the business.  This is where we attempt to move years of neglected master and transactional data from a loosely structured, anything-goes legacy system into a very tightly integrated and highly structured SAP system.  You must consider the likelihood that the concept of master data management had not been invented yet when the legacy or source system providing your data was implemented.

How much data to move? How much data to leave behind? What to automate, and what to execute manually?  How to gracefully orchestrate and execute a data migration cutover from one system to another?  Where and how to fit the data migration plan into the overall business implementation plan?  How to continue to run the business during the data migration phase of the business project implementation? These questions are all part of the planning fun!

[Read more...]

SAP Upgrades, Solution Manager, Test Plans, and Testing

In this entry I’ll pull together a few threads from previous posts (testing, documentation, upgrades and offshore development) and throw in some Solution Manager (SOLMAN) functionality.  These pieces can be fitted together to help accelerate a project and testing preparation via use of the SAP Test Workbench.

Nowadays SAP wants you to use SOLMAN to manage your landscape and use it as the main conduit to interact with the mother ship in Walldorf.  Lots of SAP installations use SOLMAN as a way to generate developer keys and as a document repository: valid uses, but only a small fraction of the available functionality.  Let’s explore some more of that SOLMAN magic.
[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.

[Read more...]

Liveblogging SAP TechEd 09

Are you stuck in your cube while Bob from BASIS is heading to SAP TechEd 09 in sunny Phoenix?  Are you afraid that you’ll miss out on all the sun and fun?  While we can’t send the sun, we’ll try to bring you the fun.  DataXstream will be liveblogging at SAP TechEd 09.

Head over to live.dataxstream.com on Tuesday, October 13, 2009 to get up to second updates from the show.  We will be getting our liveblog on starting at 8am PDT (that’s 11am for you right-coasters) for the general keynote session.  We’ll also be liveblogging from SAP TechEd 09 Demo Jam at 8pm PDT on Tuesday.  The Demo Jam promises to be a great time, so plan to join us online after you put the kiddies to bed!

This is our first foray into liveblogging.  Hopefully it will go off without too many technical glitches.  We hope you’ll enjoy following the events with us!

SAP Testing Preparation – Due Diligence

This entry sounds like project management 101 and can be summarized as: don’t assume because when you do… and you know the rest of that one.  The trick is to uncover your implicit assumptions, the explicit ones are easier to identify, whereas the ones lurking in your subconscious may only want to come out when they can trip you up.

[Read more...]

SAP Testing Terminology – Common Understanding on Your Project is Crucial

There are many ways to start an argument on an SAP project and here’s another one to add to the list: define these terms – unit testing, system testing, integration testing, regression testing, scenario testing, end-to-end testing, end user testing, user acceptance testing, stress testing, load testing, performance testing, string testing, usability testing, security and authorizations testing, cut over testing, dry run testing, application testing, interface testing, day-in-the-life testing.  I probably missed a few testing types, but the point is there are many kinds of testing and the same testing may be referred to by different names.

[Read more...]