R12: Upgrade vs.

Reimplementation (Financials)
INTRODUCTION
This document discusses important considerations to make when determining whethe
r your project to move to E-Business Suite Release 12 should be a standard upgra
de 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 i
mplement it to reflect your enterprise structure and operating practices. You th
en load any historical data from your legacy systems into your freshly-implement
ed Release 12 system using public interface tables and application programming i
nterfaces (APIs) that Oracle provides. Generally, you use custom scripts to tran
sform your historical data into a format that is compatible with those public in
terfaces. 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 t
he Release 12 software and use Oracle-supplied tools and scripts to transform yo
ur historical data in place to the new Release 12 data model. The standard upgra
de process converts your existing setup to Release 12 reimplementation is not re
quired.
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 reimple
mentation. A standard upgrade allows you to take advantage of supported tools, s
cripts and documentation to move your existing Release 11i setups and historical
data to Release 12. A reimplementation, on the other hand, allows you greater f
lexibility in your setup and in how you migrate your historical data using suppo
rted 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 char
t 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 busin
esses, 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 compan
y who would most likely choose to do a standard upgrade to Release 12. Such a co
mpany 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 12 s centralized accounting architecture, global tax engine, new ledger an
d ledger set architecture, multi-org access control features, centralized bankin
g 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 Set
s which allow operations to be performed on multiple ledgers at the same time. T
hese operations include viewing information, reporting, opening and closing peri
ods, creating journal entries and performing allocations across ledgers. This ab
ility gives improved visibility and control across all ledgers assigned to a led
ger set. Therefore, enterprises that have standardized on a single chart of acco
unts 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 crea
tion, for example. Further, having a single global instance of Oracle applicatio
ns would allow single step actions with the use of Ledger Sets so closing the bo
oks could be done once per Ledger Set rather than closing each Set of Books on e
ach 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 al
low them to enter and access transactions in multiple OUs with a single responsi
bility.
REIMPLEMENTATION EXAMPLE
Now let s 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 12 s added features and centralized architecture, you may be able to
eliminate many of the customizations your enterprise has had to cultivate in ord
er to support your unique business processes. Furthermore, you might want to con
sider moving to a best practice implementation in order to centralize on a singl
e 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 c
an dramatically lower costs by removing redundancies and inefficiencies from you
r 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 issu
es 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.