September 8, 2011 Leave a comment
by Ray Brown, Rocela Project Manager
As one of Rocela’s Project Managers who is currently managing several clients through their Oracle R12 upgrade, I have developed a deep understanding of the challenges and successes, pitfalls and quick wins of an Oracle R12 Upgrade.
Making the decision to upgrade is an important step and can truly enhance how you operate and perform as a business. Get the implementation of this wrong and you will endure business disruption, process inefficiency and low return on investment.
So, what can you do to make the transition go smoothly? Well, there are a number of elements you need to take into account.
Here are my top tips that should help you through the process.
Plan! Plan! Plan!
Yes, I know we all do it, but you need to ensure you create a sound plan and get buy-in from all areas of the business. Having a ‘project kick-off’ meeting to gather maximum momentum from the beginning is a good starting point.
Ensure plans cover all the following areas:
Hardware delivery times (if new hardware is being deployed): Many an upgrade project has been delayed from the start when hardware wasn’t commissioned in time
Internal IT resources: Even if the upgrade is making use of existing hardware IT support will still be required to install new operating system patches and packages, to make disk space available and to secure backups at key points in the projects
Software release: Agree up-front exactly what version will be installed and to what patching level. Unless the version has just been released by Oracle then it’s certain to be the case that various later security patches, roll-ups and key bug fixes will be available and should be applied up-front to reduce the likelihood of errors being encountered during testing
External resource: If upgrading using consulting support then make sure that you understand clearly the scope of the services they are providing and ensure that any remaining tasks are assigned to internal resources.
Internal resource: Planning internal resource for an upgrade can be one of the most difficult takes because it usually has to be fitted around users day-to-day work commitments and take into account holidays and busy periods such as month or year-ends. Clearly planning what internal resource is required and when makes securing the resource from the relevant management in the business much easier.
Upgrading Oracle E-Business Suite introduces opportunities and risks with regard to Oracle software licensing. It’s an opportunity to review and streamline the hardware architecture, with a possible reduction in technology licensing.
It’s also a point where customers overlook the licensing implication of changes they make, which can lead to nasty (and expensive) surprises if audited by Oracle. In particular if you’re deploying new hardware then make sure that you don’t exceed your technology licensing (bearing in mind such complications as processor minimums and core multipliers) and don’t assume that just because you’re reducing the overall number of processors deployed that you can’t still get problems.
Also be careful when making use of new technologies (such as BI Publisher) or Oracle E-Business Suite modules that you’re not getting into a situation where additional licenses need to be purchased. Oracle licensing is a complicated area so if unsure then take professional advice!
I would always recommend that the correct level of hardware is available during the upgrade project – duration can vary from project to project (3 – 12 months). It’s likely that additional instances will be required as 11.5.10 and R12 systems will be running simultaneously.
So, consider sourcing additional hardware (even temporarily if required) to accommodate this. Before starting the project it’s essential to do an environment review to confirm that the hardware you have will cope both with the project and with eventual production use of R12. Creating an environment plan as part of the project kick-off is a good idea.
There may be far more customisations in your system than you are aware of. A good idea is to thoroughly review the customisations in advance and carefully question whether they are required.
Consider whether there is functionality within in Oracle R12 which supersedes these customisations and review your existing documentation to understand what customisations you have. Unfortunately in some cases, this can highlight the lack of documentation!
Conducting this review prior to the upgrade ensures that you have reasonable customisation estimates in place as input to your plan. Don’t be surprised if the cost of upgrading customisations is a significant proportion of the overall project costs.
It is of upmost importance to ensure the appropriate amounts of testing are scheduled in your project plan. Utilise previous scripts if they are available (if they’re not then plan in the creation of test scripts early in the project) and get the business units involved in testing.
Have a team ready to do some high level testing of key processes immediately following the 1st iteration upgrade. Check standard screens and reports still perform in the same manner as in your current release and there is no impact on performance.
How can you make it easier?
Upgrading is always a substantial project, but talking to an experienced Oracle specialist or taking into account some of the tips above can make the difference between a successful project with return on investment and a failed project requiring unbudgeted cost to resolve.
We have just recently added a new case study to our website on Oracle R12 Upgrades – you can read this here. We hope you find it interesting.