Hitting the Reset Button for R12

The Upgrade vs. Reimplement Decision

By Helene Abrams

There are two paths for moving to a new release of an enterprise software package. The first is to use the vendor-supplied patches to upgrade the existing instance. The second is to start from scratch and reimplement. This paper explores the factors that influence whether an upgrade or a reimplementation is the customer’s preferred choice. First, some definitions:

Upgrade refers to the process of starting with an existing database instance and data, and then applying patches to get to a new release.

Reimplementation starts with a blank database that is installed and configured from scratch. Existing data is migrated into the new application instance after the configuration is complete.

This article looks at the decision points of Oracle E-Business Suite (EBS) customers as they evaluate whether they should reimplement or upgrade. Though EBS customers are taken as the example here, the decision is basically the same for any enterprise system.

1. Oracle E-Business Suite (EBS) R12 is a significant new version with valuable new features and capabilities.  Most people currently think some customers are forced to reimplement in order to take advantage of R12, but that other customers may be lucky enough to reap the new release benefits via Oracle’s upgrade process. 


2. Most EBS customers upgrade if given a choice because that is the path of least resistance.  Compared to reimplementation, it is simpler, uses fewer resources, will likely cost less, and the time-to-value is shorter.  We observe that software vendors usually make upgrades easier than starting from scratch, if they know how and can do so at an acceptable cost.  If not, individual customers shoulder the reimplementation burden.


3. We also observe that some customers’ business users and IT staff have been frustrated with their current EBS implementation and its restrictions.  They accept the requirement to reimplement as an opportunity to break with the past and get a clean start with Oracle.  Because it’s perceived as a requirement, they have an easier time justifying the additional expense, effort, and delay of putting R12 into production. 
   
   Nevertheless, reimplementation drains the business’s resources more than a typical major release EBS upgrade.


4. The organization’s Oracle specialists, consulting firms, and industry analysts should look at the current situation and re-think why they accepted that the new architecture required you to start over and reimplement.


5. The E-Business Suite 11i environment may have conditions that seem to require Customer reimplementation plus data migration.  An Oracle document, R12: Upgrade vs. Reimplement (Financials) clearly defines the terms and introduces some of the key factors.  These factors primarily focus on underlying infrastructure pieces of the applications that are very difficult to change once EBS is in production (i.e. Chart of Accounts, Calendar, Organization Units).


6. There are some reimplementation consequences in the areas of implementation, data history, disposition of the 11i instance, reporting, and business intelligence:


• You have to implement a fresh installation of R12.
• You are on your own to get your historical data from the legacy 11i instance into R12.
• You have to decide what history to load and what to do with the remainder.  You will need a policy for each different type of data.  The usual choices include most recent and current fiscal year, current year, and only open transactions. 
• Even though data conversion tools these days are powerful, and programmers in the global programming centers are inexpensive, dealing with data history will be a significant part of your reimplementation project.  It will cost money and require several iterations to get it right.
• You will keep the 11i instance in “legacy” mode.  Some call this a “sunset” instance.  It must be frozen and restricted to read-only access.  Even though the instance is read-only, there may still be associated maintenance, license, and support costs.
• You will devise reporting mechanisms to span the legacy 11i and operational R12 instances.  That includes translations, reconciliations, mappings, and external reporting environments.  Every time that access is required for the data in the sunset instance, it needs to be changed so that you can report on like things.  For example, if you change your chart of accounts in R12 and need to report on accounting entries that span both the 11i and R12 instances, you will need to translate the chart of accounts in 11i to match the new one in R12.  Sometimes this involves creating mapping tables, sometimes implementing and maintaining pointers and references to the old data, and most certainly includes some degree of reconciliation to make sure that the translation is accurate.
• If you have a business intelligence environment or data warehouse, you will make changes to incorporate the frozen legacy 11i and operational R12 environments.
7. Oracle’s description of R12 reimplementation comments on configuration setups and data migration: 

There is "greater flexibility in your setup and in how you migrate your historical data using supported public interfaces."
“Flexibility” here means you have another oppor­tunity to make major IT decisions to live with for a long time.  This is an ad­van­tage if you are not satis­fied with your 11i setups.  If you upgrade, Oracle maintains that you will have to live with your 11i setup.

Many tables do not have an API (Application Programmatic Interface) that allows you to bring data into EBS.  There are almost no formalized interfaces or extracts for getting the data out of the current 11i instance, meaning that there is no guarantee that you will get all the related data and load it in the right sequence to maintain the relational integrity. The translation scripts that you will use to change the data from your 11i instance into the format that you have defined as your target R12 instance are all custom-coded.
Oracle’s description concedes that reimplementation is more difficult, complex, and resource intensive compared to an upgrade.

"It is a project that you would generally un­der­take with the support of a professional services provider, such as Oracle Consulting."  

8. Customers now have a choice.  Available third party software allows you to make changes to the setups of the 11i Applications that you inherited.  This software allows you to change only the pieces of your EBS suite that no longer align with the business.  Not only can you retain more of your investment in the 11i instance, but you can also take advantage of Oracle’s upgrade software, for which you pay as part of Oracle Support.


9. The result is an R12 instance with all the desired target characteristics and all the historical data.  All the transactions in all subledgers reflect the new setup parameters.


• You have the same opportunity to change set­ups (flexibility) to define the target R12 instance as you would have if you were to reimplement.
• You would reduce the consulting services and the time required to run through several conference room pilots and make decisions all over again.
• Software allows the flexibility to change your mind – you can use software to make the changes you think will accurately reflect how you want to do business, then generate standard reports to see how your decisions impact your operations.
• Software generates the code automatically so that the resources you bring onto your project don’t have to worry about maintaining relational integrity.  You don’t have to worry about the skill level of the consultants and whether they have had experience with the modules in your environment in R12.
• You may be able to launch R12 and start capturing the business benefits from 1 to 2 quarters earlier.

 

eprentise is in the business of helping organizations that run Oracle E-Business Suite by providing transformation software. These customers have particular Oracle-related challenges when they “upgrade” their business at a macro level and want their Oracle instance or instances to follow and support the new “release” of the business. EBS’s strength is in running the business. The implementation of EBS is a model of the business’ organization and processes. EBS was not engi-neered to make it easy to change certain key aspects of the implementation — the model of the business — for a business “upgrade”.

The complexity of EBS meant that customers had few options other than reimplementing if they wanted to keep their systems aligned with the business changes. A series of reimplementations is not only costly, it is unnecessary.

eprentise Transformation software was architected from the ground up with the purpose of providing enterprise agility to organizations that rely on OEBS for their financials and day-to-day operations.

eprentise also works with System Integrators, Consultants, and Professional Service firms who help EBS customers.