Panaya

Going Beyond the SAP Upgrade Clichés
By guest author Jon Reed
Download the PDF version of this article

There is now a body of wisdom about SAP upgrades. For SAP users, that doesn't necessarily make SAP upgrades any easier. For those companies seeking advice on a move to ERP 6.0, there is plenty of advice for the taking. The problem is that most of this advice, as truthful as it is, has reached the point of cliché. In this piece, we'll move beyond the clichés with 49 SAP upgrade do's and don'ts grounded in customer stories.  

But there's a lot more to a successful upgrade than plugging away with some common sense principles and hoping for the best. To get a sharper view of what separates a successful SAP upgrade from a not- so-successful one, I compiled the advice of industry analysts, project advisors, upgrade consultants, and SAP users who presented at trade show sessions after upgrading. What I learned during my interviews and research surprised me, contradicting some of my previous assumptions about SAP upgrades.

I. Do's and Don'ts: Vendor Selection and Pre-Launch Planning

Don't: Assume that your SAP experience means that the SAP upgrade process can be handled solely in-house.
Do: Treat the SAP upgrade as a whole new implementation. Re-evaluate technical needs, skills requirements, and the extent of system customization.

Don't: Simply award the upgrade to the firm that did your last big project.
Do: Conduct a thorough evaluation process of possible consulting partners. Bring in two or three vendors and ask them to walk you through their SAP upgrade methodology.

Don't: Make the mistake of assuming that a consulting firm with prior upgrade experience will be the right fit for your company's upgrade.
Do: Choose a consulting partner that has experience and customer references in your particular industry and your version of SAP.
Customer lesson: Prior to beginning their upgrade, Kraft Foods asked implementation partners IBM and EDS to "own" the implementation with them and assume collective responsibility for its success.

Don't: Upgrade just to avoid extended maintenance fees from SAP.
Do: Establish business drivers for the SAP upgrade, such as: instance and database consolidation (goal: cost savings) or improved CRM functionality (goal: top line growth).
Customer lesson: Indesit, an international consumer appliances company, justified their SAP upgrade with the goal of increased visibility in their global supply chain to reduce the cost of raw materials and pursue new markets.

Don't: Plan a "functional" and technical upgrade at the same time. Even with a purely technical upgrade, there are plenty of changes in user experience to anticipate.
Do: Ensure that even a technical upgrade has business drivers to justify it. Also: once you do the technical upgrade, be on the lookout for "low hanging functional fruit" that could be enabled by new functionality (such as a new built-in report or a new checkbox to automate a workflow step).
Customer lesson: Florida Crystals did a technical upgrade to ERP 6.0 with dodging extended maintenance as one reason, but they also wanted to consolidate databases and get onto a platform where they could consider Duet, SAP Interactive Forms by Adobe, and Blackberry integration via SAP CRM.

Don't: Assume that you will have to pay a conventional billing arrangement for SAP upgrade support.
Do: Consider a bid from at least one fixed cost/fixed time SAP upgrade provider - there are now experienced firms out there who will provide this option.

II. Do's and Don'ts: Technical Upgrade Considerations

Don't: Stress over the NetWeaver Java stack if you are an old-fashioned SAP ABAP shop. ERP 6.0 ships with the NetWeaver ABAP stack; most users can just start with that. You do not have to run the NetWeaver Java stack during or after your upgrade.
Do: Plan on installing the NetWeaver Java stack if you want access to Adobe Document Services functions. Most companies that handle regulatory filing issues through SAP have to install the NetWeaver Java stack; SAP is now typically handling regulatory filing functions via Adobe Document Services.

Don't: Be intimidated by the Unicode conversion process. Unicode conversions are not incredibly difficult, but they are time and resource intensive.
Do: Convert to Unicode during your initial upgrade. Some advise to wait on Unicode conversion, but there are good reasons to move to Unicode during the initial technical upgrade. Wade Walla of group:basis points out one very good reason to move to Unicode prior to ERP 6.0: once you move to ERP 6.0, the SAP database is 50 to 100 percent larger, creating a lot of additional Unicode work. Also: the word on the street is that SAP support is smoother for customers running ERP 6.0 with Unicode.

Don't: Cross your fingers on SAP's recommended system requirements.
Do: Take the opportunity to move to the 64 bit hardware SAP recommends; this will be important to your future SAP systems enhancements.

Don't: Upgrade until you catch up on your support packs and OSS notes for your 4.x environment.
Do: Ensure that you are running the latest version of Solution Manager prior to upgrading. Waiting on updating Solution Manager will simply cause technical and training issues down the line.

Don't: Assume that your custom code and interfaces will work in ERP 6.0, even if they were built using established user exits. They will not.
Do: Test all used custom code and third party interfaces in a sandbox or (better) with an upgrade simulation software that can save you a lot of time.
Bonus: Seize the opportunity to reduce redundant (or no-longer-relevant) custom objects during the upgrade process. You can even start cleaning your code well before the upgrade.
Customer lesson: Agilent began their SAP upgrade with 14,000 customized objects. After the upgrade, they were able to reduce that amount to 7,000.

Don't: Plan an SAP upgrade without a proper environment for user testing.
Do: Make sure that your new upgrade environment mirrors your existing environment, with sandbox, development, QA, and production systems.
Customer lesson: Florida Crystals was running three separate "clustered" 4.x SAP instances. They needed to duplicate this clustered environment in their testing system in order to ensure a smooth cut over.

III. Do's and Don'ts: Upgrade Skills and Training

Don't: Assume that internal employees with expertise in 4.x systems will be able to lend a useful hand on an ERP 6.0, without prior training on new tools like Solution Manager.
Do: Conduct an in-depth skills "gap analysis" to determine which skills you can source in-house and when you will need outside expertise. Note: quality SAP service firms can provide an "SAP skills matrix" to evaluate SAP upgrade skills needs. The human resource aspects of an SAP upgrade can also be managed using SAP's Talent Management functionality within SAP HCM. Solution Manager's OCM (Organizational Change Management) toolkit is another way to identify upgrade skills gaps and plan for change management initiatives.

Don't: Cross your fingers and hope that a bit of internal training will be sufficient for those in lead roles needed for the upgrade.
Do: Bring in outstanding consultants in specialized areas that are integral to your SAP upgrade.
Customer lesson: Kraft Foods supplemented their internal team with "All Stars" in key areas tied to the success of their upgrade, such as: Netweaver technical, Unicode conversion, new GL configuration, and BI upgrades.

Don't: Let your users dip their toes in your development box and call that "user training."
Do: Provide a complete sandbox (separate from the development and QA servers) and involve your users in that sandbox, testing it in their job area. Create a tight feedback loop to incorporate user sandbox concerns and address the bugs they identify during sandbox time.

Don't: Fall into the trap of counting on outsourced Basis support alone to handle your upgrade. Do: Manage your outside Basis vendor carefully. Get your Basis vendor to provide a separate quotation for the upgrade with milestones, delivery dates, resources, and methodology. Upgrades require extra resources beyond your usual day-to-day support. It's ideal to have at least one on-site Basis expert to support the technical upgrade.

Don't: Wait until hands-on upgrade training to address change management issues with users.
Do: Begin change management sessions as early as possible, allowing users to engage in a dialogue about their day-to-day job role changes. Give them a forum to provide feedback on new business processes or reporting structures. By the time actual training begins, users should have worked through their questions and embraced their new roles, so that the focus of the training is simply on questions like "Where did the ‘approve purchase order' field go?" or "Can I adjust the colors on my new GUI?"

Don't: Alienate experienced users by forcing them into time-consuming and unnecessary classroom sessions.
Do: Be aware that skills planning will determine which users will have only minor changes in their SAP system usage experience. For example, when transitioning from 4.7 to 6.0, many users will only experience minor GUI-like changes to their day-to-day work (particularly in the case of a purely technical upgrade). In these situations, immersion classroom training may be excessive. Instead: save money and improve user morale by creating online "finger-point training" which allows seasoned users to quickly identify the GUI changes that impact their roles.

Don't: Overpay outside firms for generic one-size-fits-all training and documentation.
Do: Innovate and create role-based training and documentation that is designed with your company's business processes in mind.

Don't: Assign responsibility for change management and upgrade training to the IT department.
Do: Create an internal change management and training team, one that has a reasonable budget as well as executive involvement and buy-in.

Don't: Become overly dependent on a consulting partner for upgrade training needs.
Do: Build an internal "Center of Excellence" and evolve your company into a "learning organization" that takes advantage of the increase in virtual SAP events and online education, such as SAP's new Learning on Demand web site. Create a "mentoring environment" inside your company that extends beyond company walls. Employees with well-developed social networks in their area of SAP specialization will be a greater asset to your team during and after the upgrade.

Conclusion
SAP upgrades are not for the faint of heart. One expert told me that an SAP upgrade was like giving your SAP system a heart and lung transplant. For such an important operation, we need to draw on the lessons of those who have taken that bold journey and come out the other side. I hope that this collection of upgrade do's and don'ts went beyond the upgrade clichés and gave you specifics that will make a real difference in your success.

Author Bio
Jon Reed, JonERP.com, Twitter: @jonerp
Jon Reed is an independent SAP analyst and SAP Mentor who writes on SAP skills and market trends. Recently, Jon was recognized as a Top Contributor for the SAP Community Network 2008-2009 in the Business Process Expert Category. Jon is the driving force behind JonERP.com, an interactive web site that features Jon's SAP Career Blog and his podcasts for SAP professionals. Jon has been publishing SAP career and market analysis for almost 15 years, and he is the author of the SAP Consultant Handbook. Jon serves as a "PAC Fellow" with PAC's SAP Services Research Program, and he is a frequent contributor to PAC's "Feeding the SAP Ecosystem" blog.

Many SAP experts provided insights to this piece, but Jon Reed would like to extend a special thanks to Wade Walla of group:basis for his above-and-beyond feedback on this article.

About Panaya
Established in 2006, Panaya Inc. provides software tools that save SAP customers up to 50% of their software upgrade and maintenance costs, while minimizing risks and proving a clear ROI. Provided as Software as a Service (SaaS), Panaya's SAP environment simulation shows which custom SAP programs will break as a result of an upgrade, explains how to fix them, derives the most efficient test plan and calculates the required budget and resources for the project.

SAP is a registered trademark of SAP AG. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world.