Written by Helene Abrams Tuesday, October 20 2009
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.
-
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.
-
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.
-
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.
-
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.
-
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).
-
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.
-
-
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 opportunity to make major IT decisions to live with for a long time. This is an advantage if you are not satisfied 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 undertake with the support of a professional services provider, such as Oracle Consulting."
-
-
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.
-
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.
-
| < Prev | Next > |
|---|
Related Articles
Related Pages
Enter your email address to sign up for our Newsletter
January Puzzle
A traveler gets lost on a deserted island and finds himself surrounded by a group of n cannibals.
Each cannibal wants to eat the traveler but, as each knows, there is a risk. A cannibal that attacks and eats the traveler would become tired and defenseless. After he eats, he would become an easy target for another cannibal (who would also become tired and defenseless after eating).
The cannibals are all hungry, but they cannot trust each other to cooperate. The cannibals happen to be well versed in game theory, so they will think before making a move.
Does the nearest cannibal, or any cannibal in the group, devour the lost traveler?
Solution
The short answer is the traveler’s fate depends on the parity of the group. If there is an odd number of canibals, the traveler will be eaten, but if there is an even number, the traveler will survive.
To prove this, we will consider small groups and use mathematical induction to explain the solution for larger groups.
Case n = 1: this is an obvious case. If there is one cannibal, the traveler will be eaten. It doesn’t matter that the cannibal will get tired because there are no other cannibals around as a threat.
Case n = 2: this is a more interesting case. Each cannibal wishes to each the traveler, but each knows he cannot. If either cannibal eats the traveler, then he will become defenseless and the other one will eat him. So each cannibal uses backwards induction to realize that the only strategy is to not eat the traveler. The hapless traveler finds a bit of luck, therefore, and actually survives.
Case n = 3: this is where the problem gets interesting. The best strategy is for the closest cannibal to make a move and eat the traveler. The cannibal will be defenseless after eating, but ultimately he will be safe. Why is that? The reasoning is due to induction: once the cannibal eats the traveler, the resulting situation has 2 unfed cannibals and the 1 defenseless cannibal. But as we just showed above, when there are 2 unfed cannibals, neither will make a move for fear of being eaten by the other! Thus the first cannibal to make a move will be safe as the remaining 2 cannibals block each other.
We can prove the higher cases using mathematical induction. If the number n is odd, then the closest cannibal can safely eat the traveler because the remaining number of unfed cannibals is even (and by induction, with an even number of unfed cannibals no one makes a move). If the number n is even, then no cannibal will eat the traveler, for if he did, the remaining number of cannibals would be odd, meaning he will get eaten by the induction hypothesis.
Success Tips for Oracle Project Management
- Create a standard for documentation at the beginning of your project, and hold team members accountable for completing documentation requirements as well as keeping them at and above the standards required.
- Before promulgating user documentation or training, it’s also a good idea to choose a representative from the among the business users base to review materials first.
- If you are not sure about the resources and budget required, obtain several estimates from people that have experience with the same size and scope of your project.
- Be explicit, before beginning the project, what internal resources are required for execution. This includes people, infrastructure, hardware, and software.
- Help the project champion understand the impact your project will have on the organization and how its successful completion will make him or her an internal hero or heroine for supporting it.
- Break up your project into smaller projects (try for projects that can be completed in 4-6 months, especially early on) to get success and demonstrate momentum.
- Make sure that your testing includes reports, upstream and downstream interfaces, customizations, enhancements, and workflows.
- Ensure that comprehensive transition reports and meetings between departing and incoming personnel are completed.
- Instead of spending time and resources implementing third-party reporting, consider consolidating multiple instances, moving to a global chart of accounts (CoA), and/or standardizing on a consistent calendar.
- Include governance, risk, and compliance management as part of the project plan.
- Finally, celebrate the successes. Too many projects focus on defects, failures, or small cost over-runs without looking at the big picture and what was accomplished.
The Analyst Corner
John Van Decker, Research VP of Gartner, states:
"A single chart of accounts allows consistency in financial reporting across the enterprise by standardizing on common metrics and reporting structures, reduces dependencies on a separate financial consolidation system, and significantly reduces the costs incurred with ongoing, complex conversions and translations."
