Top 5 Tips for upgrading customisations to R12

by Kenny Miller, Principal Consultant for Rocela

My colleague Ray Brown’s recent blog “Top 5 Tips for Oracle R12 Upgrade Success”  highlighted how the cost of upgrading customisations can be a significant proportion of the total cost of an R12 upgrade project.

This got me thinking about my own experiences with R12 upgrades. I doubt you’ll be surprised to learn that there is no “silver bullet” to provide an easy path for upgrading your customisations. There is no substitute for hard-work, and for approaching this work in a sensible and structured manner.

The key to success is having the correct resources available at the appropriate time in the project life-cycle, and accepting that considerable effort will be required from these resources. To help understand this better, I’ve put together my top 5 tips for upgrading customisations to R12:

1. Prepare

It’ll really help if you have some knowledge of R12. You can’t beat “hands-on” when it comes to learning, so consider installing a R12 Vision demo instance. Make sure it’s fully patched up, to get all the latest functionality and bug fixes.

Business and Super Users: Your business needs to understand how R12 functions; what’s new, what’s changed etc. This task is really part of the wider R12 project but, as we’ll see later, this knowledge is important when you review your current customisations.

I’d recommend starting with Oracle note 403349.1 which details all the Transfer of Information (TOI) content which Oracle has provided for R12. Another good resource is the Documentation Library, which for R12.1.3 is available here.

This is where having a R12 demo instance will help – it’s “play area” where you can try things out without the risk of hurting yourself!

Developers: Have a look at the usual suspects in the Documentation Library, but be aware that Oracle has started to move interface/API documentation to the “Integration Repository”. In R12, this is available in the “Integrated SOA Gateway” responsibility (see Oracle note 462586.1 for more details).

I’d also recommend the following material:

2. Quantify

If you haven’t already got one, then you’re going to need a list of all your customisations. Don’t under-estimate how long this might take to prepare – there are so many different ways to customise EBS, not all of which are obvious and easy to find. Most “mature” EBS systems have many hundreds of customisations.

I’ve done this for quite a few of our customer recently and, despite knowing what to look for, it still takes me between 3 and 5 days to complete.

3. Review

Eliminate: The easiest, and therefore cheapest, way to upgrade customisations to R12 is not to upgrade them at all! Eliminate any customisations that the business no longer needs, or those that can be replaced with new standard functionality.

This is why it’s so helpful that your business/super users “immerse” themselves in R12. Only with this knowledge can they properly understand the requirements for R12 customisation. If your organisation doesn’t feel confident enough to do this, then seek assistance. You really should avoid upgrading redundant customisations.

Prioritise: What is business-critical? What is not needed until the next year-end etc? It makes sense to focus first on the most important customisations.

4. Plan

To plan properly, you need to know how much effort is going to be required. This is a challenging task, even for those of us that have considerable experience with R12. You need to know R12 well before you can attempt this with any degree of accuracy.

It’s not just about estimating either – it’s also about establishing your approach and identifying the skillsets needed. For example, your custom Sales Invoice program is likely to upgrade with little or no rework, but your custom Payables BACS program will need to be completely redeveloped using BI Publisher.

R12 is not as different from R11 as you’d think, but it is different. The “devil is in the detail” and in this case the “detail” is the differences between R11 and R12.

5. Test

If ever there was a time to believe the old adage about “never being able to test enough” then this is it. Test, test, then test again.

Be comprehensive with your testing. If you use the Transaction Import interface then create invoices both for existing customers upgraded from R11, and with new customers created in R12. Test your redeveloped BACS program by paying invoices created in R11 and R12. I’m sure you get the idea.

Also be realistic with your testing. If you typically import 100,000 invoices at the month-end, then don’t test with 10,000 and assume that 100,000 will take 10 times longer.

Finally, be pragmatic enough to accept that no matter how much testing you do, there will always be something you miss. It’s called “sod’s law”.

Summary

Upgrading your customisations to R12 will be a challenge, but hopefully the tips above should help provide some direction. Be prepared to work hard, and get external assistance if required. Plenty of others have been there before you, so don’t be hesitate to take advantage of this experience.

Finally, 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.

Advertisements

Top 5 Tips for Oracle R12 Upgrade Success

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.

1. Planning

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.

 2. Licensing 

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!

3. Environment

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.

4. Customisations

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.

5. Testing

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.

Should I upgrade to Oracle R12?

by Brian Livingston, Senior Consultant

When Oracle announced that Premier Support for Oracle E-Business Suite R11i would end in Nov 2010, IT departments started wondering when they’d need to make the switch to R12.

Understandably, many simply delayed the decision, mostly to avoid perceived additional costs and disruption. But in a recent survey commissioned by Rocela, a whopping 65% of respondents advised that they’re considering, are upgrading or have already upgraded to Oracle R12.

So, why the sudden change of heart?

The risks of non-compliance

One key reason may be the legislative requirements for HRMS customers. Under “Sustaining Support”, these customers will only be provided with Severity 1 production bug fixes, and not legislative updates.

This means that any changes made by Inland Revenue around tax codes, National Insurance and the like can’t be reflected in the following tax year by older versions of Oracle software. It doesn’t take long to imagine the dramatic impact this could have on the compliance position of Payroll customers, leaving organisations at considerable risk.

Sharing the load

Aside from legislative hurdles, there’s also the significantly more compelling fact that Oracle R12’s shared services model of operation can actually drive cost savings and increase information quality. Centralising information through a shared service center can create a consolidated view of essential decision-making data, accessible globally.

Standardisation of common business practices also adds to the timeliness and accuracy of data. With consistent business processes throughout the enterprise, information can be gathered uniformly, with consistent quality.

Assess the benefits

The upgrade to Oracle R12 guarantees compliance with legislation, offers the unique opportunity to roll out new business processes and makes concepts such as shared services a reality.

The software’s functionality will also allow organisations to make better, smarter decisions, and will enable enterprises to become more competitive by increasing application performance. All these factors combined will deliver the most sought after business benefit: cost saving.

It’s no wonder that there’s an increase in upgrade activity, however many IT departments still view the process of upgrading to a new software platform as a complex and costly process.

This doesn’t have to be the case. Providing the right assessment process and partners are in place and able to offer tried and tested services to help you decide whether upgrading is the right move and what the implementation plan should be.

The best advice for enterprises is don’t get left behind – get smart about the R12 upgrade and find partners with the knowledge and expertise to help you make the right choice.

Finally, 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.

%d bloggers like this: