You are on page 1of 2

R12: Upgrade vs. Reimplementation INTRODUCTION This document discusses important r your project to move to Eupgrade or a reimplementation.

It nals in Oracles Product Develo the issues that your project team .

(Financials) considerations to make when determining whethe includes suggestions and advice from professio should consider when analyzing the two options

DEFINITIONS Lets start by distinguishing what we mean by the terms implementing and upgrading. If you adopt Release 12 by and implement it to reflect your enterprise structure and operating practices. Y ou then load any historical data from your legacy systems into your freshly Release 12 system using public interface tables and application programming inte rfaces (APIs) that Oracle provid your historical data into a format that is compatible with those public interfac es. If the legacy system from which yo the E-Business Suite, then your fresh implementation may be described as a reimpl ementation. 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 Release 12 software and use Oracle-supplied tools and scripts to transform your historical data in place to the new Release 12 process converts your existing setup to Release 12 reimplementation is not requi red. 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 reimplementation. A standard upgrade allows you to take advantage of supported t ools, scripts and documentation to move your historical data to Release 12. A reimplementation, on the other hand, allows you greater flexibility in your setup an supported public interfaces. It is a project that you would generally undertake with the support of a professional se would consider doing a reimplementation under circumstances such as: You wish to change configurations that are not easily changed, such as your char t of accounts definition, costing method, or calendar. ? Your enterprise has undergone significant change in the number and structure o f its business units and organizations since your original Oracle For example, you have grown through acquisition and you want to establish a new standard applications setup for all of your business units, running disparate application systems. In this case, you might choose to freshly implement Release 12, and then migrate historical data businesses, even if some of those businesses were running E-Business Suite. STANDARD UPGRADE EXAMPLE To crystallize the issues, lets look at the characteristics of a deploying compan y 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 a ccounts 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 12s centralized accounting architecture, ledger set architecture, multi-org access control features, centralized banking model, advanced global intercompany system

company must have all of the above characteristics to be able to do a standard u pgrade but well now go into some upgrade option more likely. In Release 12, Sets of Books have been replaced by Ledgers. Ledgers sharing the same chart of accounts, calen Sets which allow operations to be performed on multiple ledgers at the same time . These operations include viewing information, reporting, opening and periods, creating journal entries and performing allocations across ledgers. Thi s ability gives improved visibility and control across all ledgers Therefore, enterprises that have standardized on a single chart of accounts are in the best position to do a straight upgrade to benefits. Its most beneficial for the enterprise to have standardized business processes so that each ledger and operatin deploying company to do cross-ledger allocations or month-end journal entry crea tion, for example. Further, havin would allow single step actions with the use of Ledger Sets so closing the books could be done once per Ledge application instance. Enterprises that have implemented shared service centers to perform back-office functions for multiple operating units will Access Control features added throughout Release 12. A user who has access to mu ltiple operating units (OUs) w get to information in the correct OU. Multi-Org Access Control will allow them t o enter and access transactions in multiple OUs with a single REIMPLEMENTATION EXAMPLE Now lets take a look at an enterprise that would want to consider reimplementatio n 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 globa l business processes. 4. Maintain decentralized back-office functions but see value in moving to a sha red 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 impleme ntation of E-Business Suite. With Release 12s added features and centralized architecture, you may be able to eliminate many of the customi support your unique business processes. Furthermore, you might want to consider moving to a best practice imple vendor and even application instance. Much research has recently come out from v arious analysts indicating that layered benefits, not the least of which is tremendous costs savings. A single c hart of accounts will simplify reporting, giving you a global view of finally, centralized and standardized back-office functions can dramatically low er costs by removing redundancies and inefficiencies from giving you better information more quickly. Altogether, the benefits of moving t o a best practice implementation have are using.

You might also like