INTRODUCTION This document discusses important considerations to make when determining whether your project to move to E-Business Suite Release 12 should be a standard upgrade or a reimplementation. It includes suggestions and advice from professionals in Oracle’s Product Development organization that will help you to understand the issues that your project team should consider when analyzing the two options. DEFINITIONS Let’s start by distinguishing what we mean by the terms “implementing” and “upgrading.” If you adopt Release 12 by implementing, you install the Release 12 software and implement it to reflect your enterprise structure and operating practices. You then load any historical data from your legacy systems into your freshly-implemented Release 12 system using public interface tables and application programming interfaces (APIs) that Oracle provides. Generally, you use custom scripts to transform your historical data into a format that is compatible with those public interfaces. If the legacy system from which you migrate your historical data is an earlier release of the E-Business Suite, then your fresh implementation may be described as a “reimplementation”. If you are moving from an existing release of Oracle E-Business Suite to Release 12, you can adopt Release 12 by upgrading. With this alternative, you install the Release 12 software and use Oracle-supplied tools and scripts to transform your historical data in place to the new Release 12 data model. The standard upgrade process converts your existing setup to Release 12 – reimplementation is not required. BASIC CONSIDERATIONS If you are moving from an existing release of Oracle E-Business Suite to Release 12, you need to consider whether to perform a standard upgrade versus a reimplementation. A standard upgrade allows you to take advantage of supported tools, scripts and documentation to move your existing Release 11i setups and historical data to Release 12. A reimplementation, on the other hand, allows you greater flexibility in your setup and in how you migrate your historical data using supported public interfaces. It is a project that you would generally undertake with the support of a professional services provider, such as Oracle Consulting. You would consider doing a reimplementation under circumstances such as: You wish to change configurations that are not easily changed, such as your chart of accounts definition, costing method, or calendar. Your enterprise has undergone significant change in the number and structure of its business units and organizations since your original Oracle implementation. For example, you have grown through acquisition and you want to establish a new standard applications setup for all of your business units, which are currently running disparate application systems. In this case, you might choose to freshly implement Release 12, and then migrate historical data from your existing businesses, even if some of those businesses were running E-Business Suite. STANDARD UPGRADE EXAMPLE To crystallize the issues, let’s look at the characteristics of a deploying company who would most likely choose to do a standard upgrade to Release 12. Such a company would most likely: 1. Run a single global instance of Oracle applications 2. Have a single chart of accounts or is satisfied with their current chart of accounts 3. Use standardized business processes with minimal customizations 4. Run shared service centers for back office functions Enterprises with all of the above characteristics can most readily benefit from Release 12’s centralized accounting architecture, global tax engine, new ledger and ledger set architecture, multi-org access control features, centralized banking model, advanced global intercompany system and so on. This is not to say that a company must have all of the above characteristics to be able to do a standard upgrade – but we’ll now go into some of the reasons why each of the above makes the upgrade option more likely. In Release 12, Sets of Books have been replaced by Ledgers. Ledgers sharing the same chart of accounts, calendar and period type can be combined into Ledger Sets which allow operations to be performed on multiple ledgers at the same time. These operations include viewing information, reporting, opening and closing periods, creating journal entries and performing allocations across ledgers. This ability gives improved visibility and control across all ledgers assigned to a ledger set. Therefore, enterprises that have standardized on a single chart of accounts are in the best position to do a straight upgrade to Release 12 and to see immediate benefits. It’s most beneficial for the enterprise to have standardized business processes – so that each ledger and operating unit has unified procedures. This would allow a deploying company to do cross-ledger allocations or month-end journal entry creation, for example. Further, having a single global instance of Oracle applications would allow single step actions with the use of Ledger Sets – so closing the books could be done once per Ledger Set rather than closing each Set of Books on each application instance. Enterprises that have implemented shared service centers to perform back-office functions for multiple operating units will immediately see the benefit of Multi-Org Access Control features added throughout Release 12. A user who has access to multiple operating units (OUs) will no longer have to switch responsibilities or ‘hats’ to get to information in the correct OU. Multi-Org Access Control will allow them to enter and access transactions in multiple OUs with a single responsibility. REIMPLEMENTATION EXAMPLE Now let’s take a look at an enterprise that would want to consider reimplementation in order to move to Release 12. Such a company would most likely: 1. Run multiple instances of Oracle applications and would like to consolidate. 2. Have multiple charts of accounts and would like to move to one. 3. Use disparate business processes and see the benefit in having standard global business processes. 4. Maintain decentralized back-office functions but see value in moving to a shared services model. 5. Have many customizations and understand that R12 could eliminate some of them. This type of implementation would benefit from moving to a best-practice implementation of E-Business Suite. With Release 12’s added features and centralized architecture, you may be able to eliminate many of the customizations your enterprise has had to cultivate in order to support your unique business processes. Furthermore, you might want to consider moving to a best practice implementation in order to centralize on a single ERP vendor and even application instance. Much research has recently come out from various analysts indicating that that standardizing on a single ERP vendor has multi-layered benefits, not the least of which is tremendous costs savings. A single chart of accounts will simplify reporting, giving you a global view of your business. And finally, centralized and standardized back-office functions can dramatically lower costs by removing redundancies and inefficiencies from your business processes and giving you better information more quickly. Altogether, the benefits of moving to a best practice implementation have inherent value – no matter what ERP system you are using. SUMMARY In summary, it is our hope that this paper helps you understand some of the issues that you should consider when designing your migration to Release 12 so that your enterprise will get the most out of its E-Business Suite deployment now and going forward.