Upgrades and R12

In most situations we suggest that customers change their COA in 11i and go into production prior to the upgrade. Alternatively, the COA change can be the first step in the upgrade project, or the last.

We will evaluate with you the comparative level of effort and elapsed time to use eprentise for a consolidation, split, or reorganization compared to your R12 upgrade. In most situations, we suggest these paths:

• Consolidate 11i instances, then upgrade the single consolidated instance.
• Upgrade to R12, then split the instance into two R12 instances. However in some situations an M&A transaction may force a timetable where the split must be done first, and then later the two parties each have to upgrade.
• When eprentise will be used to reorganize and transform the data in a single instance, the sequence depends on whether the reorganization or the upgrade provides the most value to the business. Most eprentise reorganizations will be smaller in scope than an upgrade, easier to test, and quicker to get into production.
  • If one provides significantly more value, then do that first, put it into production, and do the other later. If there’s a new functional module in R12 that you need, that might be an argument to upgrade before reorganization. In most cases a reorganization will be much less effort and take less time than an R12 upgrade.
  • If you have the resources and the timing works, it’s feasible to do both in a single production release. During development you still do one after the other in sequence, but perhaps you can have just one testing cycle.

We look at the expected work effort and elapsed time to complete the two alternatives. The first option has one consolidation and one upgrade project. The second option has two upgrade projects and then a consolidation project, so it is likely to require more work. Using eprentise to consolidate 11i instances or R12 instances is about the same level of effort. It would also take longer if the two upgrades are done one after another instead of in parallel.

There are other considerations.

• Upgrading to R12 is largely related to keeping up technically with Oracle’s releases. The business reasons for an upgrade are usually related to needing the new accounting methods and new module functionality not present in 11i. R12 introduces Ledgers, Ledger Sets, and Subledger Accounting Methods. Setting up and staffing shared service centers is easier.
• Most companies delay the upgrade, since it’s a lot of work without a lot of business benefit, and they want to wait until R12 is stable. Also, many of the advantages of R12 are meaningful only if you have a single instance.
• Users test the consolidation transformation on a familiar release. By using eprentise before upgrading, you are able to isolate the impact of consolidation changes without introducing the complexity of a new release, new functionality in new modules or new features in existing modules, and different business processes.
• Consolidating to a single instance has business benefits regardless of the release you’re on. We believe (a) a company can estimate the business benefits with a small amount of financial analysis, and (b) the benefits will be significantly more than the combined technical and business benefit of an R12 upgrade on multiple instances.
• In summary, even though R12 is more stable than a year ago, we still suggest consolidate then upgrade as the sequence of choice.

eprentise and FlexField have no impact on normal E-Business Suite operations, patches, or upgrades.