fixing the sap upgrade process - nine best...
TRANSCRIPT
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
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.
Fixing the SAP Upgrade Process
Copyright 2009 EAC 2
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.
Fixing the SAP Upgrade Process
Copyright 2009 EAC 3
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.
Fixing the SAP Upgrade Process
Copyright 2009 EAC 4
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
Fixing the SAP Upgrade Process
Copyright 2009 EAC 5
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.
Fixing the SAP Upgrade Process
Copyright 2009 EAC 6
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.
Fixing the SAP Upgrade Process
Copyright 2009 EAC 7
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.
Fixing the SAP Upgrade Process
Copyright 2009 EAC 8
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.
Fixing the SAP Upgrade Process
Copyright 2009 EAC 9
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.
Fixing the SAP Upgrade Process
Copyright 2009 EAC 10
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
Fixing the SAP Upgrade Process
Copyright 2009 EAC 11
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.”
Fixing the SAP Upgrade Process
Copyright 2009 EAC 12
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.
Fixing the SAP Upgrade Process
Copyright 2009 EAC 13
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
Fixing the SAP Upgrade Process
Copyright 2009 EAC 14
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.”
Fixing the SAP Upgrade Process
Copyright 2009 EAC 15
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
Fixing the SAP Upgrade Process
Copyright 2009 EAC 16
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.