reduce the pain of erp upgrades with better...

Enterprise Strategies Report

June 2007

As corporations become more dependent on their ERP systems, they struggle to strike the right balance between regularly updating the software and minimizing cost and disruption to the business. This Report offers advice on how to develop and communicate a practical upgrade strategy and then build an effective process for maintaining your ERP asset.

by Jim Shepherd

Reduce the Pain of ERP Upgrades With Better Planning

Acronyms and Initialisms

COE Center of excellence

ERP Enterprise resource planning

ROI Return on investment

© Copyright 2007 by AMR Research, Inc.

AMR Research® is a registered trademark of AMR Research, Inc.

No portion of this report may be reproduced in whole or in part without the prior written permission of AMR Research. Any written materials are protected by United States copyright laws and international treaty provisions.

AMR Research offers no specific guarantee regarding the accuracy or completeness of the information presented, but the professional staff of AMR Research makes every reasonable effort to present the most reliable information available to it and to meet or exceed any applicable industry standards.

AMR Research is not a registered investment advisor, and it is not the intent of this document to recommend specific companies for investment, acquisition, or other financial considerations.

This is printed on 100% post-consumer recycled fiber. It is manufactured entirely with wind-generated electricity and in accordance with a Forest Stewardship Council (FSC) pilot program that certifies products made with high percentages of post-consumer reclaimed materials.

The BottomLine

Enterprise Strategies Report | June 2007 �© 2007 AMR Research, Inc.

Reduce the Pain of ERP Upgrades With Better Planning by Jim Shepherd

The key to minimizing the pain of ERP upgrades is to have both a long-term ERP

lifecycle strategy and a comprehensive tactical plan for the actual upgrade project.

In many organizations, the ERP system has become the application support for the majority of business processes and the repository for the corporation’s most sensitive data. As these systems become more important and pervasive, there are often conflicting opinions about

how they should be maintained and updated. This is no longer a technical decision that can be made by the IT department or dictated by the software vendor’s release schedule. ERP upgrades are now important enough that senior management needs to fully under-stand both the timing and project plan.

This Report offers guidance on developing an overall corporate strategy for maintain-ing an ERP system by providing practical advice for planning and managing an ERP upgrade project. Here are some of the areas that will be addressed:

• Why companies should periodically upgrade their ERP systems

• Defining the strategy and timing for ERP upgrades

• Consensus building and communicating the ERP strategy

• How to justify the cost and resources required for an ERP upgrade

• Creating a project plan for a successful upgrade

• Organization and governance options

• Resources, services, and tools available for upgrades

It is vital that the company develops a strategy for how often the software and underlying technology will be updated so that the entire organization can plan and budget for the inevitable costs and disruptions. Because upgrades are periodic events, it is also important to create a repeatable process as well as a set of tools and skills to ensure the projects can be executed efficiently while minimizing any risk to the organization.

ExecutiveSummary

Enterprise Strategies Report | June 2007 � © 2007 AMR Research, Inc.

Why companies need to upgrade their ERP systems

Most organizations are realizing the ERP system is not just a key part of their IT strategies, but one of their most important and sensitive corporate assets. ERP systems should have at least a 15- to 20-year useful life, but over that time they will need to be maintained and enhanced to protect their value and serve the changing needs of the business.

Other capital assets that corporations own, such as buildings, vehicles, or equipment, need regular maintenance, but they don’t typically require large-scale upgrades. Software-based assets like ERP systems have some unusual characteristics:

• They can deliver long lifecycles, but they’re subject to rapid technical obsolescence because of the volatility of the underlying software and hardware technology.

• This technological instability and the complexity inherent in millions of lines of computer code tend to result in surprisingly poor quality by the standards of other highly engineered products.

• Most companies pay 17% to 22% of the original software license price per year in order to gain access to bug fixes, legal changes, and technical and functional enhancement releases.

These factors alone would suggest that companies need to plan for periodic updates just to ensure the reliability of mission-critical applications. Perhaps even more important is the role that upgrades play in adding new functionality, improving business processes, and extending the deployment of ERP suites.

In the last few years, we have seen a best practice evolve in which companies use the upgrade project as a focal point for a whole series of related improvements. At a minimum, this is an excellent time to consider implementing new capabilities and refreshing the technology environment, but it is often combined with other business and IT initiatives. Corporations moving from decentralized environments to shared-services functions or global integrated structures typically upgrade their ERP systems as a part of the consolidation effort. Upgrades are also an excellent time for companies to evaluate their IT portfolios and look for opportunities to eliminate custom software, unneeded modifications, and even third-party or legacy systems in order to simplify their environments and lower costs of ownership.


Defining an ERP upgrade strategy

It is very important that a company’s management team and board of directors understand the nature of ERP systems so that they can appreciate the importance of having a long-term upgrade strategy. It is quite possible for organizations to squander their investments and shorten the asset life by failing to invest in periodic upgrades of their business systems. At the same time, AMR Research frequently sees companies that seem to be in constant upgrade mode because they are simply reacting to a variety of internal and vendor-driven imperatives and deadlines.

A proper upgrade strategy should span a minimum of five to seven years and consider a number of different factors. The first issue, of course, is your company’s commitment to the software package. If there are plans to replace the current system in the next two or three years, it rarely makes sense to invest in an upgrade project, regardless of the vendor’s support policy. Even if the vendor plans to end support of the product or version, it would still be less expensive to pay for extended maintenance or a third-party support contract.

Assuming that your company intends to keep the software, it should spend some time developing a strategic plan for the timing and frequency of upgrade projects (see Figure 1). The rate of change in the business and the software vendor’s approach to new-release timing generally determines the frequency of upgrades. Very aggressive companies may plan upgrades every two-to-three years if their business environments are quite volatile and they have an ERP vendor like Oracle with relatively rapid release cycles. In other cases, we may see large, global companies choosing a much more conservative five- to six-year upgrade pattern because they consider the cost and risk to be high relative to the benefits. This decision about upgrade frequency must ensure that the company stays within the bounds of the vendor’s support and maintenance policy. Running the organization’s most critical business processes on unsupported software is too risky to be acceptable to most boards of directors.


Once the upgrade frequency is determined, the specific upgrade projects can be scheduled by looking for windows of opportunity or particular business requirements. As shown in Figure 1, the upgrade timing needs to be shifted in order to accommodate other constraints or incentives:

• Related business initiatives

• Software release schedules

• Upgrade infrastructure like servers, databases, and middleware

• Requirements for new software functionality

• Availability of critical internal IT or user resources

• Attractive go-live windows, like three-day weekends

• Unacceptable go-live periods during busy seasons or fiscal quarter ends

ERP Upgrade Schedule

2006 2007 2008 2009 2010 2011 2012

Significant businessinitiatives

Vendor releaseschedules

Planned infrastructure

updates

Vendor supportpolicies

Demand fornew functionality

Technologyrequirements

Resource andbudget constraints

Release 6.0 Release 8.0

DurationScheduled A

ctivity

Figure 1: ERP upgrade strategy example

Source: AMR Research, 2007


Consensus building and communicating the ERP strategy

One of the most critical reasons to create an ERP upgrade strategy is to facilitate the buy-in and involvement of the rest of the organization. Like successful implementations, ERP upgrades require the active participation and support of many parts of the company. One of the main causes of resistance to upgrades is they often come as a surprise, with management and business leaders feeling like they are being blackmailed by the software vendor or their own IT departments. Developing a strategy document that explains the reasons why periodic upgrades are necessary and lays out the time frames of the next several projects will encourage an internal dialog and allow for financial and resource planning.

An ERP upgrade strategy must be actively sold to the organization. Unlike ERP prac-titioners, most people don’t understand why something that costs so much to buy and deploy needs to be changed and upgraded every few years. It may appear the company is paying a lot of money to fix things that weren’t done right the first time. A key part of the upgrade strategy process is getting a critical mass of employees to understand ERP upgrades are a normal part of the product lifecycle.

ERP systems are typically implemented in phases over several months or several years. The phases may represent groups of modules, business units, geographic locations, or some combination of all three. The ERP upgrade strategy needs to be positioned as a continuation of that approach, with new phases every three to five years that respond to inevitable changes in the business requirements and incorporate improvements in tech-nology. The important thing is to help everyone understand that the purpose is to allow the company to have a modern, up-to-date information system without having to buy a new one every few years. ERP upgrades may seem expensive, but they are much less expensive than replacement projects.

Justifying the cost and resources required for an ERP upgrade

A formal ERP upgrade strategy helps to prepare the organization, but in most cases each upgrade project will require its own justification. Preparing a formal business case for an ERP upgrade is challenging and can sometimes take longer than the actual project. Part of the problem is that companies are accustomed to creating justifications for tangible capital equipment. They tend to approach the upgrade justification by trying to find enough cost savings to fund the project and provide the appropriate ROI. While there are often potential cost savings from improved processes or IT portfolio rationalization, much of the justification for an upgrade must be based on opportunities and risk avoidance. While these soft benefits may not fit neatly into an ROI calculation, it is very important to quantify them and include them in the justification.


The process of creating the justification should start by listing each element that might be included in the project: the sponsor or beneficiary and what the potential value is to the corporation (see Table 1). This list then becomes a working document that is used to socialize and scope the project. Tasks and features get added or subtracted from the list, and sponsors must get involved in supplying the detailed requirements and benefits. At the same time, the IT department needs to develop a cost estimate for the upgrade project that includes any anticipated software and hardware investment, external IT services, and internal personnel costs.

The ERP vendors can provide a great deal of assistance in developing an upgrade justifica-tion but we find that most customers are hesitant to get them involved. The vendors are always very interested in getting their users to move to the next release, and they invest a lot of money in creating tools and programs to facilitate the process. On their own or in conjunction with their user groups, they gather comprehensive data on customer upgrade experiences, which is very helpful in creating a cost estimate and timeline for the project. The vendors also compile guides to the new technology and functionality features of the release. These release notes or delta comparisons to your current release are a good starting point for creating the benefits side of the justification.

Table �: Proposed scope for upgrade project


Project Element Internal Sponsor Potential Value

Consolidation of nine divisional instances into one centralized global instance

CEO, CFO, VP of Sales

$6,600,000

Upgrade to Release 7.5 CIO, Director of COE $730,000

Replace existing custom configuration system with Advanced Configurator 3.0

VP of Sales, VP of Engineering, CIO

$1,250,000

Deploy electronic batch record and electronic signature capability to all plants

VP of Manufacturing, VP of Quality

$900,000

Implement treasury management CFO $1,400,000

Replace database servers and upgrade SAN

CIO $600,000


The most difficult part of the justification tends to be assigning a monetary value to the opportunities and risks. The opportunities are generally associated with business capabili-ties supported by the new release (or could be implemented during the upgrade project) that are not available with the current system or are viewed as inadequate. The groups within the organization that understand the need for these new features are the ones that can develop estimates of potential value. These may be related to better efficiency, faster response to change, competitive threats, new business models, or improved processes. With a little creativity, however, they can all be assigned cost or revenue values.

Risk mitigation is nearly always a part of the rationale for ERP upgrades, but companies struggle to find a way to include it in a financial justification. The easiest area to quantify tends to be vendor support costs. Most companies recognize they can’t afford to be running their business on unsupported ERP software, and nearly all the vendors specify support windows for each release. A typical vendor policy might be to provide standard maintenance for five years from the release date and then charge a premium for the next two or three years. At that point, most vendors will continue taking your maintenance fees, but they stop providing bug fixes, legal changes, and technology compatibility. Avoiding the maintenance premiums alone can be a significant savings, but staffing internally or paying consulting fees to support old releases is very expensive.

Another significant area of risk is technological obsolescence. Hardware, operating systems, and databases tend to evolve faster than ERP systems, so companies that fail to upgrade their applications can easily find themselves unable to capitalize on the benefits of newer and more cost-effective technology. ERP releases that are only four or five years old may not be compatible with the latest infrastructure, and the software vendors have little incentive to update old releases. The monetary value of this risk increases dramatically if the company faces capacity constraints related to transaction throughput or data volumes. In some cases, upgrading may be the only way to ensure critical functions like order processing are not degraded. The upgrade also may allow IT to add needed capacity at a much lower cost.

The best practice in building an ERP upgrade justification is to make the benefits-and-opportunities list as long as possible. There is a tendency to look for the silver bullet—an item so compelling that it will justify the entire project—but in most cases it simply doesn’t exist. The best upgrade projects provide value to lots of parts of the organization and incorporate improved processes, new functionality, and updated technology. It is more work up front to gather the necessary information and coordinate all the interested parties, but it results in a better justification and broader support for the project.


Creating a project plan for a successful upgrade

A project plan for an ERP upgrade should look like a condensed version of an ERP implementation plan, since the essential steps are the same. In most cases, though, the duration and resources required will be reduced. Regardless of how narrow the scope is for an upgrade project, it always needs a formal project plan and a project team. The project should have a governance structure in place and management oversight with specific milestone dates, metrics, and change management. Companies that take a casual approach to upgrades or simply dump the project in the lap of the IT depart-ment will increase the risk of business disruption and jeopardize the expected benefits.

Jan. Feb. Mar. Apr. May Jun. Jul. Aug. Sep. Oct. Nov. Dec.

Planning

Design

Development

Prepare for cutover

Final go live and production support

Figure 2: Typical ERP upgrade timeline


The key activities in an ERP upgrade include the following:

Planning

• Determine what organizational changes, business process improvements, and technol-ogy updates are in scope for the project.

• Evaluate the existing application portfolio to determine if there are any existing applications that can be eliminated or replaced by functionality in the ERP system.

• Create a formal project plan and establish an upgrade project team.

• Identify and secure any necessary resources.


Design

• Train the project team on new release functionality and technology.

• Modify existing business processes slated for improvement and design any new processes.

• Evaluate existing modifications to see if they are still needed.

• Configure new applications and develop any new reports.

• Redesign any integration software or procedures that may be affected by the upgrade.

• Evaluate system infrastructure, perform sizing analysis, and determine required upgrades.

Development

• Develop any necessary data migration scripts and clean up any affected data.

• Establish a test system that runs new software against a representative data set.

• Create or revise documentation and education materials.

• Evaluate regulatory or validation requirements.

• Revise and extend existing test scripts.

Prepare for cutover

• Develop cutover sequence, intermediate check points, and recovery options.

• Perform comprehensive integration and functional testing.

• Schedule super-user walk-through of all key business processes.

• Conduct stress tests to identify any performance issues.

• Train any users that will be affected by new or changed functionality or processes.

• Perform a technical upgrade rehearsal using the “sandbox system.”

Final go-live and production support

• Upgrade production system to new release.

• Conduct performance measurements and do any necessary tuning.

• Monitor user and help-desk activity to identify required follow-up employee training.

• Evaluate process changes and new functionality where adjustments are needed.

• Conduct a post go-live project assessment to look for ways to improve the next upgrade project.

Enterprise Strategies Report | June 2007 �0 © 2007 AMR Research, Inc.

Organizational and governance options

There are organizational and governance requirements for a successful ERP upgrade project, but in many companies, permanent structures can be readily adapted. A manage-ment steering committee should be responsible for approving the project plan, allocating the necessary resources, and monitoring performance against the identified milestones. Any changes to the project’s scope or timing must be approved by the steering committee because they will inevitably impact both budget and resource availability. This body also resolves any conflicts with other activities or issues associated with organizational or business process changes.

The project team needs to be cross-functional, with representation from the major busi-ness functions, affected geographies, and the IT department. Ideally, the project leader should not be someone from the IT organization because it is very important to send the message that the ERP upgrade project is a business process improvement activity, not an IT exercise. In situations where the company has decided to use external consulting or technical resources, they should be embedded in the project team parallel or reporting to internal personnel.

Companies that have an existing ERP competency center or center of excellence (COE) frequently choose to have that organization run the upgrade project. It typically has many of the right ingredients to drive a successful project, including functional expertise, busi-ness process knowledge, technical skills, and experience with project management, change management, and employee training. For companies that don’t have a permanent COE, the upgrade project may be an ideal time to establish one since there is strong correlation between COEs and the value derived from the ERP system.

Resources, services, and tools available for upgrades

Over the past 25 years, ERP software has grown into a $28B per year market that serves hundreds of thousands of companies worldwide. This success created a parallel market of companies that provide tools and services to help implement, manage, and upgrade ERP systems. Companies evaluating or planning ERP upgrades should take the time to famil-iarize themselves with the resources available from the ERP vendors and their partners. In many cases, these resources can significantly lower the cost, minimize the risk, and reduce the impact on key internal personnel. There are hundreds of methodologies, sizing analyzers, testing tools, data management utilities, and consulting services proven to deliver excellent ROI investment, but are chronically underutilized.

Enterprise Strategies Report | June 2007 ��© 2007 AMR Research, Inc.

Companies should first look to the ERP vendors. In most cases, the vendors have comprehensive information available to help companies evaluate upgrades. This will generally include release notes, comparisons to prior releases, and tools to estimate the cutover times, database sizes, and processor impacts of new releases. Many of the vendors also have standardized upgrade methodologies, such as the Oracle Upgrade Assistant or SAP’s ASAP for Upgrades, which include sample project plans, procedural guides, and other tools to facilitate the project.

ERP vendors also offer a variety of specialized consulting services to help. These may start with two- or three-day onsite evaluations to help identify business opportunities from an upgrade that may be followed up by a project to build a financial justification. The ERP vendor’s consulting arms will generally offer project assistance or specialized expertise for the upgrade project. In some cases, these upgrade services can be delivered from a remote site. Lawson, for instance, claims that upgrade services may be as much as 30% less expensive when they are sourced through its Global Solution Centers.

A wide variety of software tools have been developed to assist companies with ERP upgrades. Here are some of the most popular categories and vendors:

Release and customization analysis tools

These products compare your existing ERP system to a specified new version and identify changes, modifications, and potential problem areas. Since customizations and testing are among the most time-consuming and expensive parts of an ERP upgrade, these tools can easily pay for themselves in a single project.

• IntelliCorp—LiveCompare

• Intelligroup—Uptimizer

• Compuware—SAP Functional Realization

• Wipro—1Up

• Hewlett-Packard (HP)—Mercury Deployment Manager

Enterprise Strategies Report | June 2007 �� © 2007 AMR Research, Inc.

Testing and test management tools

Experienced ERP customers always single out testing as the most difficult aspect of upgrade projects. Determining what to test, developing and maintaining test scripts, and administering the multiple rounds of integration and performance tests are extremely challenging. While ERP vendors provide some support for testing, we recommend that companies invest in comprehensive testing software to support both upgrade projects and routine software patching.

• Wipro—PowerAn

• AutoTester—AutoTester ONE

• HP—Mercury LoadRunner; Mercury QuickTest Professional

• Genpact—Appready

• Compuware—QACenter

Data management tools

One of the keys to successful upgrade projects is the creation of sandbox systems, test systems, and quality assurance systems that can be used for a variety of activities during the upgrade projects. In order to be useful for testing and training, these systems need to be populated with current production data, with all the complex relationships intact. Specialized data management tools provide the select, extract, and load software to clone and move master data or transactional data between ERP instances.

• Gamma Enterprise Technologies—InfoShuttle

• SymSoft—Gold Client

• IntelliCorp—DataWorks

• Compuware—File-AID

In addition to the ERP and tools vendors, hundreds of consulting and IT services firms offer ERP upgrade services. Almost any firm that does ERP implementations will also do upgrade projects for the services, ranging from full turnkey projects to staff augmen-tation and specialized expertise. The largest global firms, like IBM, Accenture, Deloitte, and BearingPoint, tend to have specific service offerings for SAP and Oracle upgrades. Smaller firms, such as Wipro, Intelligroup, and Ciber, also offer comprehensive upgrade services and a variety of tools and templates. In addition to global and local consulting firms, there are thousands of experienced contractors frequently used on upgrade proj-ects. For companies that are comfortable running their own projects, contractors are a relatively inexpensive way to temporarily add staff with specific skills and expertise.

Enterprise Strategies Report | June 2007 ��© 2007 AMR Research, Inc.

Not a necessary evil

ERP upgrades are an essential process that helps organizations derive greater value from their ERP software and prolong the useful life of this very important asset. Companies need to recognize the importance of upgrades and develop an appropriate strategy for them that aligns with the realities of their IT and business environments. This strategy is vital because ERP upgrades can be expensive and disruptive, and the business needs to be able to plan, budget, and coordinate these projects with other activities and initiatives.

Actual projects to upgrade an ERP system need to be treated as smaller versions of an implementation project rather than just another IT program. Many of the methodologies, processes, and governance structures required for an effective ERP implementation should be employed as an upgrade project, albeit on a smaller scale. Most organizations have the resources and skills necessary to run an upgrade project, but the quality of planning dis-tinguishes truly successful upgrades. Defining the scope, determining the project tasks, securing the resources, and preparing the organization are all planning activities that can shorten the duration, lower the cost, and minimize the risks of an upgrade.

Too often we see companies underestimate the level of effort and the broad impact of an ERP upgrade. These projects can potentially affect most of the critical business processes and a high percentage of employees. They need to be planned for very carefully and deserve significant management attention.

At the same time, both users and the vendor community are improving this process. The products are more easily upgraded, and there is a wide range of tools and services to assist. The emergence of the option to do a true technical upgrade followed by gradual adop-tion of new functionality revolutionized the ERP upgrade process. We now see even large companies with massive ERP deployments able to periodically upgrade their systems in an orderly way with very little trauma. These organizations generally have long-term ERP strategies with standardized upgrade processes and the discipline to develop very detailed project plans.

We don’t expect to see a time when users will welcome ERP upgrades, but we believe that we will reach a point where they can be treated as routine business activities. As users develop their ERP lifecycle skills and vendors move closer to the goal of zero downtime upgrades, we hope to reach a point where ERP upgrades can be seen as simply another component of the continuous business process improvement program rather than a major company event.

Research and Advice That Matter

Founded in 1986, AMR Research provides

subscription advisory services and peer

networking opportunities to operations

and IT executives in the consumer products,

life sciences, manufacturing, and retail

sectors. We are the No. 1 research firm

focused on the intersection of business

processes with value chain and enterprise

technologies.

AMR Research has published more than 15,000

pieces of research. Grounded in industry and

business process expertise, our analysts deliver

independent, leading-edge research on

established and emerging technologies.

This analysis is supported by the best research

data in the industry, expert-led Peer Forums,

and daily interaction with our members,

the most comprehensive community of

practitioners in the industry.

More information is available at

www.amrresearch.com. Your comments are

welcome. Reprints are available. Send any

comments or questions to:

AMR Research, Inc.

125 Summer Street

Boston, MA 02110

Tel: +1 (617) 542-6600

Fax: +1 (617) 542-5670 AMR-R-20456

This is printed on 100% post-consumer recycled fiber. It is manufactured entirely with wind-generated electricity and in accordance with a Forest Stewardship Council (FSC)

pilot program that certifies products made with high percentages of post-consumer reclaimed materials.

reduce the pain of erp upgrades with better...

Documents