Fixing the SAP Upgrade Process: Nine Best Practices

Joshua Greenbaum, Principal Enterprise Applications Consulting June 2009

EAC
2303 Spaulding Avenue Ber keley C A 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

josh @ eaconsult.com 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

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, industrywide 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 isnt 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 SAPs 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.

Copyright 2009 EAC

Fixing the SAP Upgrade Process

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

Copyright 2009 EAC

Fixing the SAP Upgrade Process

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.

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.

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

Copyright 2009 EAC

Fixing the SAP Upgrade Process

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. SAPs 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
Copyright 2009 EAC 4

Fixing the SAP Upgrade Process

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, its 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 desupport 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.

Copyright 2009 EAC

Fixing the SAP Upgrade Process

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.

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.

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 unacceptance 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

Copyright 2009 EAC

Fixing the SAP Upgrade Process

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 decisionmaking 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.
Copyright 2009 EAC 7

Fixing the SAP Upgrade Process

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 partners requirements can be a powerful incentive for a functional upgrade, even if there isnt 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 fullfledged 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.

Copyright 2009 EAC

Fixing the SAP Upgrade Process

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.

Copyright 2009 EAC

Fixing the SAP Upgrade Process

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 SAPs 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 Managers 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 Panayas value in the upgrade process is that Panaya takes the data about the customers 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

Copyright 2009 EAC

10

Fixing the SAP Upgrade Process

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.

Copyright 2009 EAC

11

Fixing the SAP Upgrade Process

The resulting combination of extensive upgrade impact analysis, paired with well-defined project process has helped Panayas 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. EACs 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.

Copyright 2009 EAC

12

Fixing the SAP Upgrade Process

! ! ! !

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

Copyright 2009 EAC

13

Fixing the SAP Upgrade Process

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 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. 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
Copyright 2009 EAC 14

SAP director explained. While we do the actual upgrade, everything stops.

Fixing the SAP Upgrade Process

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

Copyright 2009 EAC

15

Fixing the SAP Upgrade Process

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

Copyright 2009 EAC

16