Most organizations will upgrade if possible, since that is the easiest path for enterprise software product upgrades. However, there are a number of factors, including the new Financials architecture and concerns about product quality, that have led many to decide to reimplement or to delay. With the introduction of eprentise software, you can eliminate obsolete fundamental setup configurations and multiple instances as reasons that lead organizations to select reimplementation. If you like what R12 offers and you want to save time, money, and resources on the transition, you can combine eprentise Transformation software with Oracle® upgrade to upgrade EBS 11i instances to a single global instance of R12.
The transition from 11i to R12 is a high-stakes major initiative for any E-Business Suite (EBS) customer. We have observed that companies plan the transition for approximately a year, then set budgets, line up resources, and do the work over one to two years. Projects may cost in the range of several million dollars to tens of millions and are often proportional to the size and complexity of the business. We believe E-Business Suite 11i customers can upgrade instead of reimplement, shorten the time-to-value at a lower cost, and provide a better R12 result for both the Business and IT. Why reimplement?
As customers look at whether they should reimplement or upgrade, these are some of the decision points that they are considering.
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. EBS customers with brand new implementations are not impacted by the transition complexities.
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.
Your 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.
Your 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. Our Decision Factors – 11i to R12 table below lists the conditions, including ones that are strong indicators for reimplementation, according to Oracle.
Here 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 data 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.
You will devise reporting mechanisms to span the legacy 11i and operational R12 instances. That includes translations, reconciliations, mappings, and external reporting environments.
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 provides no such opportunity for change within R12.
There is little to gain from custom historical data migration across the numerous EBS tables compared to the controlled historical data migration performed by Oracle’s upgrade process.
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.”
You now have a choice. Despite the conditions that apparently require reimplementation, consider eprentise Transformation software plus Oracle upgrade:
Use eprentise software to:
Transform the fundamental setups of your 11i instance(s) to eliminate the reimplementation conditions.
Adjust or re-do any unsatisfactory setups.
Transform the 11i data to reflect the removal of reimplementation conditions and new setups.
Consolidate 11i instances as required so there is only one instance to upgrade.
Run the Oracle upgrade.
With this R12 transition approach, you retain more of your investment in the 11i instance. You 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 setups (flexibility) to define the target R12 instance as you would have if you were to reimplement.
You can choose to bring all historical data or select subsets from 11i.
eprentise Transform plus Oracle upgrade is cheaper, faster, and better than Customer reimplementation plus data migration.
You will likely reduce the consulting services required.
You may be able to launch R12 and start capturing the business benefits from 1 to 2 quarters earlier.
We need to know more about your situation before we can talk about transition cost savings.
We understand that if your organization has already made a decision and you have started the reimplementation project, you may be reluctant for your people “to get distracted” by a new idea, even if there could be potential material savings or faster time-to-value. Would it be distracting to look for several hundred thousands of dollars savings?
One way to discover if eprentise plus upgrade would be better for your organization is to invest about six person days of your R12 program management team and IT financial analysts’ time with us. They may already have analyzed R12, collected your business users’ requirements, and inventoried what needs to change from 11i to R12. What is the state of their reimplementation estimates for resources, costs, and schedule? The more detailed, the better.
Within two weeks, we can deliver a preliminary proposal of how you could use eprentise Transformation software to upgrade to R12, how long it would take, and what it would cost.
Conclusion
It is important to keep the upgrade vs. reimplementation discussion in the context of the overall transition to R12. First understand what the R12 target needs to be. Compare that to the 11i instance(s). Itemize and inventory everything that needs to change. Then consider how you would make each change via upgrade (with eprentise Transformation software plus Oracle upgrade), and via reimplement (implement it and migrate your historical data). A parallel analysis considers everything in the 11i instance(s) that does not need to change on the path to R12. What do you not need to touch if you upgrade? What do you need to replicate anew if you Reimplement? What extra historical data that is supposed to be unchanged must be managed and migrated if you reimplement? There will be other project components impacted by the 11i to R12 transition, virtually everything that touches the E-Business Suite. Some are mostly independent of the upgrade vs. reimplementation decision, such as reports and interfaces. Another set of items will be dependent, such as what happens in the Business Intelligence environment.
When planning the transition to R12, focus on the components that are dependent on the specific transition methods. Cost/benefit and resource expenditure analyses will assist in your transition planning, specifically aiding you in deciding which method will be best for your organization’s adoption of R12 and the new features that come along with it.
No comments:
Post a Comment