Best upgrade practices for adopting Oracle E-Business suite – R12.1.3

INTRODUCTION

This blog describes major upgrade areas to consider in determining whether an upgrade is appropriate for your Organization. It also offers practical advice from Oracle support, consulting and development Organization on how to do a R12 upgrade. This blog tells you “things you need to do” before and after R12 upgrade project.

Why Upgrade?

There are many compelling reasons for upgrading your EBS version such as:

• Unlocking new mature functionalities to keep your organization well positioned to meet business objectives.
• Staying current with the highest and latest levels of the product support. The extended support to R11.5.10.2 is ending on December, 2014.
• Upgrade allows you to see best performance and usage of enhanced features like functional capabilities, technical infrastructure etc. which enables you to increase application’s efficiency for your business.

[Refer Oracle Applications Documentation Resources Release 12 Note 394692.1] For more detailed information of finance and procurement upgrade impacts, see Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12.

The Upgrade phases

An upgrade is similar to implementation; however upgrade can be more efficient than implementation as it leverages earlier implementation efforts and business processes. Also, upgrade can be executed within existing change management system by your organization.

Below graphic presents the standard upgrade phases at a high level:

Upgrade – Best Practices

This section describes R12 best practices for pre and post upgrade and testing activities.

Pre Upgrade Best Practices

• Evaluation:Before initiating upgrade, it is important to thoroughly evaluate the new release to confirm the capabilities and enhancements which will provide expected benefits and justified returns from the upgrade to the business. Information on release notes can help in determining what exactly will change in newly upgraded system along with the new features. [Refer Oracle note 461705.1 which provide a consolidated view of information you may need for an upgrade project]
• Planning: Asuccessful upgrade begins with a crystal clear definition of project scope and detailed project plan. Though R12 has new significant changes in data model and functionality specifically in financial modules, defining realistic schedule for upgrade project considering implemented modules in R11, integration with other third party systems and respective development, expected new modules to be introduced in R12, end user training and their confidence to go with R12, any change in terms of hardware or operating system or merging multiple instances into one single global instance should be considered while planning the project scope and timelines. You may separate such activities as a separate project than upgrade to minimize the risk. Though standard upgrade moves you from R11 to R12 with same setups and functionality with additional and default functionality about tax, sub-ledger accounting, still you have option to implement new functionality at desired time.
• Data validation approach: Aminimal upgrade requires some functional setups which come by default like Trading Community Architecture (TCA) for customer/ supplier data, payments and E-business tax. If you have inconsistencies within R11 setups, then you should resolve them before R12 upgrade. You can run “Accounting Setup Manager Pre-upgrade Diagnostics” report to view R11 setup for financial modules, through you can identify setups that are potentially problematic. Also, results of standard reports from each module would also help to know successful upgrade – the reports have to run before and after upgrade as well.
• Technical Iterations: Executing technical upgrade is critical initial phase. A best approach would suggest at least three iterations. The first iteration may be taken up to identify hurdles/ issues throughout upgrade (including functional/ technical configurations and testing activities). The second would be taken up to minimize issues which are identified within first iteration and further UAT activities. The third iteration would be taken up to identify exact down time (including all end to end activities) and help for Production upgrade. Capturing regular backups throughout the upgrade process would be enabling you to restore the environment to a specific point rather than re-initiating the entire process.

Fall-back planning : Approaching towards production stage upgrade, fallback planning is most essential and important. You can have multiple modes of backup which are capableenough to restore immediately and enable end users to work on. One round of resting on restoring the environment is recommended.

Pre-requisites: You can start the upgrade post completing month end activities, clearing all interfaces and posting all journals to General Ledger, closing all sub-ledger/ ledger periods. All such activities (including DBA, functional and technical) have to be sequentially listed down with

• priority, navigation, activity owner, specific notes (if any) and respective estimated time against the activity. Many of such activities can be done in parallel mode to minimize upgrade time. Closure of major service requests prior to upgrade is highly required. Allocation to appropriate owners to activities and involvement of respective business users to their activities is most important for this project. Running of key reports before and after upgrade is one of the important activities in terms of data verification and reconciliation.
• Cook-Book concept: Cook-Book includes end to end activities along with various phases which are sequentially listed down.Each activity should have respective owner, activity duration, activity sequence, activity mode (parallel/ standalone). Building and maintaining ‘Cook-Book’ is a proven concept which requires experienceto minimize cutover time, avoid last minute surprises and a very successful upgrade project.

A detailed, well planned and coordinated production upgrade is important in successful upgrade and minimizing risk factors.

Below is high level pictorial view of Cook-Book:

End User Training: Organize key user training and make them familiar to R12 environment, new features and functionalities. Prepare training documentation and update user guide to reflect changes in both functionality and business processes.

Post Upgrade Best Practices

At cutover, the final “Production” upgrade pass is completed.

• Smoke Testing: Formulate robust testing strategy with required testing rounds, team involvement with overall performing to see end to end testing of all business scenarios. In addition to CRP testing to validate setups, ensure that you do full functional testing with business users. Testing should be guided by detailed test scripts in advance along with enough time to complete end to end scenarios.
• Data Reconciliation: Running Oracle’s standard reporting from each module (based on each and every operating unit implemented) and mapping the outputs with R11 instance reports is standard approach of data reconciliation. Majority of reports are from financial modules which need to run and validate.
• Hand hold Period: Keep your key project members in place at least for successful closure of first financial period within new R12 environment to increase end user confidence level. Consider doing a mock period closing at least 5 days before the actual close. The team can monitor the R12 environment, logging the service requests (if required). Re-examine user roles and responsibilities due to change in business processes introduced in R12. For example, global process owners reviewed R12 process changes with business users and redefined roles and responsibilities accordingly.

Conclusion

Oracle R12 has been adopted by many enterprises across the globe and is well accepted as the most reliable, stable from the family of Oracle EBS suite. Thus it is crucial for existing 11i users or may be older versions to consider future business process alignment, scalability and lowest TCO while mapping to Oracle R12 and eventually Fusion Application.

Oracle is committed to supporting customer investments in technology platforms for applications as well as certified infrastructure products (hardware, operating systems, databases and middleware). Details can be accessed at the following location: Lifetime Support Stages for Your Oracle Products