October 14, 2011 Leave a comment
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:
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:
- “Planning Your Oracle E-Business Suite Upgrade from Release 11i to Release 12.1” (Oracle note 987516.1).
- “Oracle E-Business Suite Development & Extensibility Handbook” by Anil Passi and Vladimir Ajvaz.
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.
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.
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.
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”.
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.