Messier Dowty - R12 Upgrade Experience
22/09/2009 by Simon Tomey.
| Upgrading to R12 (rather than re-implementing) seemed rare, so it’s great to hear of Messier Dowty’s experience. This was particularly interesting as they upgraded from 11.5.9. Here are the notes I took. |
 |
Background to Messier Dowty and the upgrade
- If you’ve ever flown then you’re life has depended upon them (they make landing gear).
- EBS is a core application, has 150 customisations and needs to be available 24/7 (thus have RAC).
- They chose Oracle Consulting to perform the upgrade.
- They were on 11.5.9 (which left premier support in June 08).
The upgrade experience:
- Preformed after four trials (they hoped for only three).
- End to end testing was made difficult because of the way R12 handled prior processes. Some transactions also got “stuck” in interfaces.
- Testing was made difficult because when the DBA started all concurrent processes (as he was supposed to do) it changed the status of all transactions.
- Go-live happened over a three day weekend. Users were kicked off at 4pm on Thursday then were able to get back on Monday morning.
- Achieved 98% availability.
- Changes in the GL tables mean that sub ledger detail reporting doesn’t work properly (suggestion from the floor to use BIP data templates see http://blog.belife.co.uk/2009/08/03/data-templates/).
Particular issues to consider if going from 11.5.9 to R12
- Various modules don’t upgrade very well. This includes Sub Ledger Accounting, EBus Tax and payments.
- Sub Ledger Accounting descriptions didn’t work.
- E Bus tax doesn’t work in the same way as an implementation when you do an upgrade. They needed one full time person just to look after this area. Tax groups were a particular issue.
- Intercompany invoices didn’t work because of a security issue (relating to a change from 11.5.9 to 11.5.10) and they had to do a customisation
Lessons learned:
- Use of Oracle Consulting allowed direct access to the support and development teams, who made special changes for Messier Dowty for Supply chain issues which could have otherwise prevented go-live.
- Beware of API’s – they might look like they are working but deeper investigation is required
(Leicestershire Council had a similar experience - see lessons learned at http://blog.belife.co.uk/2009/07/16/upgrading-to-oracle-financials-r12-at-leicestershire-county-council/)
- Plan your testing with respect to prior processes and transaction status. Test as much as you can. Even very obvious things can get missed.
- MOAC* isn’t optional. You’ll need to configure it.
- If you’re going from 11.5.9 to R12 beware of a number of changes from 11.5.9 to 11.5.10 which won’t be well publicised/well known for the R12 upgrade path. These could get overlooked and trip you up
- An upgrade is perceived as much cheaper than a re-implementation.
- Many users will comment “It’s blue”!
Get the slides here http://www.ukoug.org/calendar/show_presentation.jsp?id=10096
Note * MOAC:
IF you don’t know what MOAC is then (I quote) “Multi-Org or multiple organization access (MOAC) is basically the ability to access multiple operating units from a single application responsibility. In Release 11i, when one had to enter or process data for multiple operating units, one had to login to different responsibilities because each responsibility could only access one operating unit…In Release 12 … [you can] create a Security Profile and assign as many operating units as you required.” see http://oracler12.blogspot.com/2007/01/moac-whats-buzz-all-about.html.