Fixing the SAP Upgrade Process - Nine Best Practices2go.panaya.com/.../images/Fixing_the_SAP_Upgrade_Process_Nine_Best...Fixing the SAP Upgrade Process: Nine Best Practices EAC

Joshua Greenbaum, Principal

Enterprise Applications Consulting

June 2009

Fixing the SAP Upgrade Process:

Nine Best Practices

EAC2303 Spaulding Avenue

Berkeley CA 94703

t e l 5 1 0 . 5 4 0 . 8 6 5 5

f a x 5 1 0 . 5 4 0 . 7 3 5 4

[email protected]

www.eaconsult .com

Table of Contents

Introduction: The Changing SAP Upgrade Landscape ..................................................... 1

The Case for the Technical Upgrade:

Keeping Up with Business and Technology Evolution...................................................... 3

The Case for the Functional Upgrade............................................................................... 6

New Approaches to Upgrade Process: The Panaya Solution ........................................ 10

Best Practices for Upgrade Success .............................................................................. 12

Conclusion: The Upgrade as a Competitive Weapon ..................................................... 16

Fixing the SAP Upgrade Process

Copyright 2009 EAC 1

Introduction: The Changing SAP Upgrade Landscape

While all enterprise software customers face the inevitability of upgrading their systems on a

periodic basis, many hesitate to follow the upgrade cycles recommended by their vendors. This

hesitancy comes from a number of factors, most of which boil down to an essential, industry-

wide truth: upgrades have historically been complex, time-consuming, and risky, and have often

defied attempts at cost-justification. And with upgrade failures making headlines with all too

much frequency – anything from complete business shut-downs to costly but eventually resolved

delays – this historical perspective isn’t without a rational basis.

With 20-plus years of market success, upgrade success has also improved dramatically, especially

in the SAP market; but while success is more attainable, efficiency is still elusive. SAP customers

continue to be challenged by the complexity, costs, and frequent delays in their upgrade projects

that become even more problematic in a difficult global economy.

The historically high degree of upgrade failure has also helped spawn not only a considerable

amount of wisdom about how to avoid disaster, but also a well-regarded set of tools and

technologies that have been instrumental in turning the tide towards greater success rates and

lower overall costs. This is no more the case than in the SAP market, where new best practices

and upgrade software have increasingly made upgrade success the norm, not an exception to the

rule.

This shifting upgrade landscape makes it imperative that SAP customers take a new look at their

upgrade plans and requirements, not just in terms of their ability to guarantee success, but also in

terms of their ability to make upgrades more comprehensive – and therefore more strategic and

cost-effective – than they have been considered in the past.

This is particularly germane when it comes to the relative value of technical and functional

upgrades. Many of SAP’s customers are in the process of planning or are contemplating a

functional upgrade to ECC 6.0 – or even Business Suite 7 – but are doing so with an easier and

less risky technical upgrade in mind. The more valuable functional upgrade is on few companies’

immediate to-do lists, despite changes in the market that make these upgrades less risky, easier to

manage, and less costly than ever before.



It’s time for that mindset to change. This white paper constitutes a call to action for the SAP

community to take a new look at the upgrade process in light of emerging best practices and new

technologies. This report offers both the reasoning behind taking this new look – including a

discussion of the value of both technical and functional upgrades – as well as a discussion of

some of the best practices SAP customers are deploying to enhance the value of their SAP

upgrades while lowering overall cost and risk.

This report is in five parts. The first discusses the components of the business case for

undertaking a technical upgrade. The second discusses the case for a functional upgrade. The

third section highlights a new approach to the upgrade process that can help streamline both

technical and functional upgrades. The fourth section describes some of the best practices for

upgrade success based on an analysis of upgrade success and failure in the SAP market. The

report concludes with a discussion of the competitive value of upgrades in the SAP market.



The Case for the Technical Upgrade:

Keeping Up with Business and Technology Evolution

There are a number of reasons why companies should undertake a technical upgrade of their SAP

system, most of which boil-down to a single essential rationale: technology and businesses

evolve, and companies need to maintain a technological infrastructure that can support that

change. There are many secondary reasons, including the fact that SAP, like all software vendors,

limits the number of years it will actively support a given version of its software. The basic notion

of upgrading to support technical and business evolution, however, is a factor behind all other

rationales for upgrading core enterprise software functionality like SAP.

Enterprise Applications Consulting (EAC) has identified five key drivers for a technical upgrade.

In most cases companies undertaking a technical upgrade justify the process by citing one or

more of these drivers, and in some cases all five are part of the rationale for the technical upgrade.

These technical upgrade drivers are:

Industry-driven Technical Innovation

Vendor-driven Technical Innovation

Business Event Requirements

Total Cost of Ownership Reduction

Version De-support

TECHNICAL UPGRADE

An upgrade intended to move the system onto the latest technology platform,

without implementing new functionality that would change user behavior or

business processes.



Industry-driven Technical Innovation

Business and technology evolution come together around three major overlapping issues, which

taken together begin building a strong case for undertaking a technical upgrade. Technological

evolution as it impacts the entire enterprise software market is the first major issue, and the

advent of service-oriented architectures (SOA) is a key example of a form of technological

evolution that drives large numbers of user organizations to consider upgrading their

technological infrastructures. Other industry-wide technological advances that drive upgrades

include Unicode support, enhanced Java support, and support for other key emerging or

established technologies.

Vendor-driven Technical Innovation

Vendor-specific technological evolution is another major issue in the case for the technical

upgrade. Companies like SAP invest heavily in the technological evolution of their customer

base, and during most major upgrade cycles SAP has considerable new technology to offer its

customers as a rationale for upgrading.

An excellent example of this is the Enhancement Packages that SAP has begun deploying with

ECC 6.0. Enhancement Packages are a technological advance that allows upgrades to take place

using a minimum of technical and human resources, significantly lowering the upgrade costs and

complexity needed to deploy a specific feature in the Enhancement Package. The technology

needed to deploy the Enhancement Packages requires a technical upgrade to ECC 6.0, whereupon

the base-level technology will be available to support subsequent upgrades using Enhancement

Packages.

SAP’s Switch Framework technology, which allows customers to selectively turn on and off

specific pieces of functionality within the Business Suite, is another major technological

enhancement that requires a technical upgrade, and therefore can be used to help justify such an

upgrade. Similarly, in any typical release, there are multiple technological enhancements to the

NetWeaver stack, APIs, user interface, internal development tools, and other technologies that

also help justify the need for a technical upgrade.

Business Event Requirements

The third major impetus for a technological upgrade comes from business events that precipitate a

change in the enterprise software infrastructure of a company. The most common of these events



is a consolidation or divestiture, where one company, and its IT system, either merge or are split

up into separate units, depending on the nature of the business event. In most cases, the preferred

best practice is to undertake consolidation and/or divestiture based on the latest version of the

enterprise system. This allows a considerable amount of the cleansing and rationalization that is

required by the new business event to be undertaken prior to going live with a single,

consolidated system or two or more newly divested systems. In either case, a “pre-emptive”

technical upgrade can provide an important interim rationalization step that ensures a higher

degree of success than would be possible if the upgrade were to take place after the merger or

divestiture had been applied to the IT system.

Total Cost of Ownership Reduction

Underlying these rationales is a potentially strong case for reducing total cost of ownership as a

result of the upgrade. Reducing TCO is rarely the main driver behind a technical upgrade – even

though an upgrade that rationalizes an overly-customized system, and in the process lowers the

burden of maintenance, can provide a significantly lower overall TCO.

Indeed, lower TCO can be a common result for a technical upgrade, and can be made up of

multiple components: Removing unused transactions, cleaning up custom code that was costly to

maintain or was running inefficiently, consolidating instances, and reducing hardware

requirements are some of the ways in which a technical upgrade can have a measurable impact on

TCO. In addition, a technical upgrade that unleashes major new technologies like SOA support

can deliver significantly lower costs, in the form of lower integration or maintenance costs, to the

company.

Version De-support

Finally, it’s important to note that, regardless of the many rationales for undertaking a technical

upgrade, many customers initiate this process due to the prospect that their version of R/3 will

soon no longer be actively supported by SAP. While many companies find upgrading due to de-

support to be more of a burden than an opportunity, these de-support upgrades, like any

successful technical upgrade, can show a positive net return to the company, provided the

upgrade is undertaken in a rational and cost-effective manner. The goal is to find the right tools

and methodology to ensure a positive outcome.



The Case for the Functional Upgrade

While there is a general consensus that a well-deployed functional upgrade can have a greater

overall business benefit than a technical upgrade, quantifying that business benefit is complicated

by the vastly different ROI and TCO calculus of a functional upgrade. This difference vis-à-vis

technical upgrades is based on an important underlying issue: There is usually a significant

change in the overall system use and number of users as a result of a functional upgrade, and that

increase in turn can lead to increased deployment costs and, often, hardware and license costs as

well.

Further complicating the business case for a functional upgrade are the changes in business

processes that often accompany this class of upgrade. These changes can increase user un-

acceptance and ancillary training costs, and often add a significant amount of time to the overall

upgrade process as well.

Finally, the changes in business process that a functional upgrade entails are often hard to

quantify in terms that fit easily into a typical ROI model. Part of this problem stems from the fact

that ROI models ideally need to compare a “before” state with an “after” state, something that is

hard to do when a new process is being implemented that has no analogous “before” state.

Similarly, line of business users may “know” they need new functionality in order to compete,

but they are often hard-pressed to cost-justify that knowledge in a classic cost-benefit analysis.

The other part of the problem is that many business process changes – such as regulatory or

compliance changes – have a “do or die” rationale behind them that renders ROI analysis

immaterial. A company that fails to upgrade to comply with Sarbanes-Oxley or BASEL II

FUNCTIONAL UPGRADE

An upgrade intended to extend the business process functionality of the existing

system. In most cases this involves the adoption of new business processes or the

automation of previously un-automated processes. A functional upgrade typically

increases the number of users of the system as well.



requirements will be regulated out of business, and no amount of ROI analysis will change the

need to effect an upgrade to support this class of function.

The more complicated rationales behind functional upgrades further impact the justification

process. Whereas technical upgrades are largely initiated by the IT department, functional

upgrades are best undertaken either as part of a line-of-business initiative or, at least, with the

active support of the line-of-business stakeholders who will be most impacted by the upgrade.

With these stakeholders hard-pressed to cost-justify their decisions, or left out of the decision-

making loop entirely, many companies end up limiting their overall upgrade efforts to a technical

upgrade, led by an IT department relatively well-versed in rationalizing upgrade projects. (See

Best Practices for Upgrade Success, below, for a discussion of how to bring these stakeholders

into the decision-making process.)

Despite the complexity of coming up with a firm cost-justification for an upgrade, EAC has

identified five key reasons why a company that has made a major commitment to SAP should

undertake a functional upgrade, and why line-of-business stakeholders should be among the most

active proponents of a functional upgrade. These reasons are:

Stop or Prevent Business “Pain.”

Support New Lines of Business or Business Initiatives.

Extend/Improve Existing Processes and Enhance Competitiveness.

Satisfy Regulatory Requirements.

Improve Efficiency and Fill in the White Spaces.

Stop or Prevent Business “Pain”

One of the most compelling reasons for a functional upgrade comes from the need to fix or

prevent a problem that is causing the loss of revenues, the destruction of customer, partner or

employee satisfaction, or is resulting in significant operational inefficiencies. Many of these

requirements come from the acknowledgment that key business processes are broken (customer

service or procurement are two common areas where process breakdown can occur) and can be

potentially fixed by deploying new enterprise software functionality. This class of problem often

has a cost or metric associated with it – lower customer satisfaction ratings, for example – that

can be applied to the cost-justification of a functional upgrade, even if a precise value of

improved customer satisfaction is hard to calculate.



Support New Lines of Business or Business Initiatives

Another compelling reason for a functional upgrade comes from the need to support a new line of

business or business opportunity that can only be undertaken using new enterprise software

functionality. Companies entering new geographies, launching major new product lines, opening

up new sales channels, or entering entirely new lines of business can benefit from an upgrade that

enables these new opportunities to be initiated based on the most efficient and competitive

processes and best practices. The business case for this kind of upgrade should be easy to build,

based on the overall business case used to justify the new initiative.

Extend/Improve Existing Processes and Enhance Competitiveness

The need to improve or extend existing processes due to changing business requirements also

offers a compelling rationale for an upgrade. A classic example comes from supply chain

management: a large OEM or channel master may make a change to how it manages its supply

chain by requiring new capabilities like RFID or vendor-managed inventory, and it becomes

imperative that its partners upgrade their functionality to follow suit.

In this case there is frequently a metric that can be used to justify this kind of upgrade: Avoiding

the loss of business due to a failure to comply with a partner’s requirements can be a powerful

incentive for a functional upgrade, even if there isn’t a net new revenue stream to justify the

upgrade expense. Other examples can result from advances in internal or industry best-practices

that incent companies to upgrade their enterprise software in order to improve competitiveness,

such as e-billing in the utility industry. The need to remain competitive can be a powerful

incentive for a functional upgrade, particularly if it is based on well-established best-practices.

Satisfy Regulatory Requirements

The need to satisfy new and emerging regulatory requirements has always provided a strong

rationale for upgrading, though in many cases, such as upgrades based on tax and payroll

regulation changes, the requirements have typically been fulfilled by technical rather than full-

fledged functional upgrades. Many new regulatory changes, however, including much of the new

and pending regulations for greenhouse gas emissions, as well as updated regulations in

pharmaceutical manufacturing and food processing, require functional upgrades that are often

substantial in nature. Regulatory requirements, as discussed above, have a built-in justification in

the form of penalties and legal sanctions for non-compliance.



Improve Efficiency and Fill in the White Spaces

The final rationale for a functional upgrade involves improving overall efficiency by filling in the

gaps in the enterprise software suite through a functional upgrade. This rationale turns out to be

the hardest to justify, in part because empirical measures of relative efficiency are complicated to

arrive at and relatively easy to refute. Another major problem with undertaking an efficiency

upgrade is that users tend to resist upgrades that remove them from the comfort of familiar

applications and processes solely for the sake of “efficiency.” This has often been the case with

customer relationship management software, for example. While the vice president of sales and

the CFO may be major proponents of advanced CRM systems, field sales staff has typically

inveighed against CRM solutions as a “waste of time,” preferring older technologies like

spreadsheets or even no technology at all. Nonetheless, efficiency upgrades do lend themselves to

both a robust cost-justification and stakeholder buy-in process, provided there is sufficient

groundwork done to help drive the process to success.

The most important part of a functional upgrade is that ideally it requires the involvement of the

line of business users who have the most to gain from this kind of upgrade. That ideal case is

usually not the case in practice, however: All too often the business stakeholders are not

participating sufficiently in the upgrade process to ensure that their needs are being met. Indeed,

EAC believes that one of the reasons that so few functional upgrades are taking place in the SAP

market today is due to this lack of engagement by the principal stakeholders with the most to gain

from a functional upgrade. Some of this is historic: SAP has traditionally focused its efforts – in

upgrades as well as across the board – on working with the IT department, and as such, line of

business stakeholders are not kept abreast of the latest in SAP functionality, and therefore are

unable to act as advocates for a functional upgrade.

While there are complex reasons for justifying either a technical or functional upgrade, it is clear

that the total cost and complexity of the upgrade has been a major factor – often a barrier – to

building an acceptable ROI case for an upgrade. The next section outlines a particularly efficient

new approach to both technical and functional upgrades that can greatly lower the total upgrade

cost, and thereby improve the ROI of any SAP upgrade.



New Approaches to Upgrade Process: The Panaya Solution

The case for justifying a technical or functional upgrade, as noted above, has been significantly

aided by the advent of new technology and solutions that help make the upgrade process

significantly more streamlined and efficient. SAP itself has improved its Solution Manager

software – which is SAP’s premier upgrade, lifecycle management, and support management

solution – in order to better assist customers in making their upgrades more efficient.

One of the offerings in the market that Enterprise Applications Consulting believes can be of

tremendous assistance in the quest for upgrade efficiency comes from a three-year old startup,

Panaya Inc. Panaya, based in Israel, has built an on-demand upgrade and lifecycle management

solution for the SAP market that can significantly streamline the upgrade process and make it

easier to achieve a positive ROI for most any of the upgrade rationales presented above.

Importantly, the Panaya solution can be used in conjunction with Solution Manager, and enhance

Solution Manager’s usefulness as well.

There are two main reasons that Panaya can have a significant impact on the cost and complexity

of an upgrade. The first is that, as an on-demand solution, there is no IT burden that must be

assumed in order to reap the benefits of using an advanced upgrade tool. Panaya is able to

improve the upgrade process by extracting a relatively small set of data from the system to be

upgraded – log files, configuration values, and custom code – and using that data to analyze and

help manage the upgrade process.

The second reason for Panaya’s value in the upgrade process is that Panaya takes the data about

the customer’s existing system and uses it to run a simulation of how that system would be

upgraded to ERP 6.0. The simulation, which runs in a cloud computing environment that is the

functional equivalent of a 100-server grid, produces a comprehensive picture of what needs to be

modified as part of the upgrade, what elements of the old system are no longer in use that can be

switched off in the upgrade, and what custom code can either be retired or must be rewritten

based on how well it matches with ERP 6.0 functionality.

This simulation is then fed into a planning module that breaks down the required changes into a

series of tasks that can then be rolled up into a comprehensive budget and project plan. (See

Figure 1.) Based on data accumulated from over 300 upgrades, the project plan is populated with



time and complexity estimates. Those estimates, when combined with data from the customer on

hourly costs, billing rates, and task prioritization, produce a comprehensive project plan and

budget that can be used to either drive the project internally or manage an external systems

integrator charged with the upgrade task.

Figure 1: Sample Panaya Upgrade Project Plan

Source: Panaya

Importantly, with an extremely comprehensive project plan on hand, monitoring the progress of

the upgrade becomes a much more streamlined process as well. Customers can use Panaya to

perform multiple analyses during the course of their upgrade, allowing them to monitor progress

and, as one Panaya customer told EAC, “make sure that when we are done with the upgrade we

are where we want to be.”



The resulting combination of extensive upgrade impact analysis, paired with well-defined project

process has helped Panaya’s customers reduce their total upgrade costs by 30 to 50 percent,

according to the company. Those cost reductions do not include the improved efficiencies in

systems management, lower maintenance costs, and even reduced license costs that can derive

from a well-implemented technical upgrade, nor do they reflect the business value to the SAP

user organization of bringing on board new functionality as part of a well-implemented functional

upgrade.

Best Practices for Upgrade Success

While a solution like Panaya can greatly streamline the overall upgrade process, a good tool by

itself will rarely have the desired impact unless an accompanying set of best practices are

implemented alongside the tool. Indeed, implementation failure generally takes place in the

absence of any direct technical problem with the software. In virtually every case of

implementation failure that EAC has analyzed, the failure could be traced directly to the people in

charge – be they in the internal IT department, or employed by an outside systems integrator –

and to the processes and best practices they either implemented poorly or failed to implement at

all.

This means that the two most important factors in upgrade success are people and process. That

in turn means having the best practices in place that can help guide people and process along the

road to success. EAC’s analysis of upgrade success and failure in the SAP market has yielded a

list of nine best practices that can go a long way towards guaranteeing success. When combined

with a solution like Panaya, these best practices can also help significantly lower the cost and

time needed to undertake a technical or functional upgrade.

The nine best practices are:

Get the stakeholders involved.

Document everything.

Simulate and test your upgrade.

Plan the upgrade well in advance.

Have a development freeze well in advance of the upgrade.



Do a technical upgrade first, but plan for the functional upgrade as well.

Implement as much standard functionality as possible.

Implement a third party solution that can help drive the upgrade process.

Implement Solution Manager (eventually).

Get the Stakeholders Involved

There is no greater requirement than stakeholder involvement in the success of an upgrade,

particularly if that upgrade is to include both a technical and a functional component. In

particular, this involvement has to be actively sought by all concerned. The IT department or

systems integrator that fails to deeply involve line-of-business stakeholders in the upgrade

process is courting disaster, because without these users’ input the system will likely not be

implemented in an optimal fashion. Similarly, the line-of-business stakeholders who avoid being

involved in the upgrade process – even if it is, for the moment, only a technical upgrade – are

guaranteeing that the likelihood that they will actually use the system the way it was implemented

will be low at best.

Document Everything

Every possible aspect of the existing implementation and the upgrade process must be

documented in order to maintain historical continuity throughout the lifecycle of the SAP system.

A considerable number of upgrade problems are the result of additions or modifications to the

system that were poorly or never documented, and for which there is no longer any institutional

memory regarding how or why the changes were made. This lack of documentation can be a

recurring issue throughout the entire lifecycle of the SAP system.

Simulate and Test Your Upgrade

One of the best things a company can do to ensure upgrade success is to test the upgrade

extensively during the upgrade process, as well as prior to go-live. Many companies accomplish

this through the use of a test sandbox, though this approach can add a cumbersome number of

iterations to the upgrade process.

Another approach, one that imposes a much lighter burden on IT, is to use a solution like Panaya

to simulate the upgrade and help manage the ongoing testing process. Panaya is particularly good



at streamlining the iterative testing that would be necessary in the sandbox approach and it

virtually eliminates the initial testing phase prior to code changes.

Plan the Upgrade Well in Advance

This is a best practice that is often implemented only after a company has had a bad experience

with an overly rapid upgrade process. Fundamentally, the longer the time window for managing

the upgrade, the lower the risk and the shorter the upgrade switchover will be. This early planning

is key to ensuring that upgrade-related interruptions are minimized. As the SAP director at an

SAP customer site told EAC: “SAP is our core system,” the

SAP director explained. “While we do the actual upgrade,

everything stops.”

Have a Development Freeze Well in Advance of the Upgrade

Another common problem that is relatively easy to avoid is

scope creep in the upgrade process. One way this occurs comes

from allowing development changes to be implemented as the

upgrade is taking place. While it would appear to be a common

sense problem that is easy to ignore, the reality is that too many

upgrade teams engage in a tug of war with development over

what can and cannot be done during the upgrade planning

window. While it is possible, with considerable effort, to

continue SAP system development during an upgrade process, the result is invariably more

complexity and more unexpected problems.

Do a Technical Upgrade First, but Plan for the Functional Upgrade as Well

While there are a number of compelling reasons for the strict separation of technical and

functional upgrades in the actual upgrade process, planning for both during the initial planning

phase is an extremely helpful activity regardless of the gap between the completion of the

technical upgrade and the start of the functional upgrade. In part, doing this two-part planning can

help fulfill the requirement for stakeholder involvement, and it will also help these stakeholders

stay in the loop as the technical upgrade groundwork proceeds.

Having some if not all of the functional upgrade specifications in mind as the technical upgrade

unfolds can also help ensure that the upgrade does not run out of steam once the technical phase

Early Planning for

the Upgrade is

Essential:

“SAP is our core

system,” an SAP

director at a major

SAP customer site

explained. “While

we do the actual

upgrade,

everything stops.”



is done. “In our last upgrade, we neglected to plan follow-on projects” for the functional upgrade,

an IT director at an SAP customer told EAC. “We focused so much on the technical upgrade,

when we were done with that we just stopped upgrading.”

Implement as Much Standard Functionality as Possible

This is an old admonition that has historically fallen on deaf ears in part because SAP R/3 lacked

built-in functionality required by some customers, and in part because many customers believed

that following their specific business practices was more important than implementing the ones

already built into SAP. This prejudice towards home-grown business practices – especially ones

that are non-strategic in terms of efficiency or competitive value – must be reassessed in light of

both the extended functionality in ERP 6.0 as well as the increased cost burden that custom

software guarantees, especially during upgrades.

Implement a Third Party Solution that Can Help Drive the Upgrade Process

Most successful implementations analyzed by EAC have deployed one of several third party

solutions to assist in managing the upgrade process. Some of these are deployed on site, while

others, like Panaya, are deployed in an on-demand manner. Regardless of which third party

solution is selected, the essential issue is ensuring that the upgrade methodology is supported by a

strong tool that can provide the necessary level of granularity and upgrade management to

accomplish the task.

Implement Solution Manager (Though Not Necessarily Before Your Current Upgrade)

Solution Manager has a number of key features that can help not just with implementations and

upgrades, but with on-going maintenance as well. Indeed, Solution Manager is becoming a

requirement for companies on Enterprise Support, as Solution Manager has a number of features

that help streamline the support and maintenance of ERP 6.0 and Business Suite 7. EAC believes

that companies in the process of an upgrade to ERP 6.0 should complete that upgrade without

Solution Manager, but then place Solution Manager high on their implementation priority list

post-upgrade.

While there is no guarantee that these best practices by themselves will yield a positive upgrade

process, the ability of companies to significantly improve on the historical track record of

expensive and time-consuming upgrades is well within reach. Combining these best practices



with a solution like Panaya further helps guarantee success at a significantly lower total cost and

with a much more rapid timetable.

Conclusion: The Upgrade as a Competitive Weapon

While the tendency is to view upgrades as a necessary evil in the enterprise software market, the

reality is that upgrades can be an important part of a company’s overall competitive profile. This

happens ideally in the case of a functional upgrade, though it can also be the case with a technical

upgrade that unleashes a capability, such as Unicode support, that in turn helps open up new

markets and opportunities.

This capability for competitive excellence can be even more readily unleashed when the upgrade

process is managed in an efficient and cost-effective way. This process can therefore be part of a

strategic plan to be reliably undertaken without the threat of cost overruns or scheduling

problems. Driving upgrades based on accepted best practices is one approach; the addition of

applying a solution like Panaya to this enlightened view of the upgrade process produces even

better results.

EAC believes that lessening the total cost and complexity of all upgrades – both technical and

functional – will lower the barriers to the functional upgrades that have been more elusive in the

SAP market than is warranted by the potential competitive value they provide. This opening up of

the functional upgrade opportunity, particularly in light of the new functionality in ERP 6.0 and

Business Suite 7, will provide further leverage to companies’ investments in SAP software for

many years to come.

Documents

Fixing the SAP Upgrade Process - Nine Best Practices2go.panaya.com/.../images/Fixing_the_SAP_Upgrade_Process_Nine_Best...Fixing the SAP Upgrade Process: Nine Best Practices EAC