Top Travel Tips for Your Cloud ERP Implementation
Any Oracle implementation is a journey of discovery; there are some sights you expect to see but often the reality of the journey is much more than what was detailed in Lonely Planet or in the contract with your Implementation Partner. This is where you can often really benefit from the services of a local guide who is comfortable with the new environment, knows the terrain and is able to react accordingly rather than your reliance on taking your own copy of a travel guide with you.
Having worked as Financials Lead on a UK Council’s successful leading edge Oracle Cloud ERP implementation at R7 I am now implementing Oracle’s Cloud ERP footprint for a UK Insurance company at R10. The following are a series of top tips based on my experience of both of these Cloud implementations, as well as extensive experience of implementing OracleERP globally over the last 20 years.
1. Do your homework
Oracle has invested a phenomenal amount of effort in the production of a raft of cloud material. There is a lot of collateral available on the following sites; you should take the time to look at and digest it and don’t attempt to treat this implementation as another flavour of Oracle E-Business Suite; Cloud is different and making this realisation up from is essential for any successful implementation. The following websites should be bookmarked and regularly visited by the entire implementation team:
Just because you move to the Cloud you still interact with Oracle through MOS and SRs. In addition, MOS also holds all the details for most Cloud issues and resolutions much as it does for other Oracle products.
A great site for detailed explanations for product functionality across ALL Oracle products and services – user and implementation guides are no all web-based rather than the pdfs used before in the world of Oracle E-Business Suite.
The home for the latest documentation as well as versions of all of the File Based Data Import tools – there are versions of documents and loaders across all of the various Cloud Releases – you can’t just use the one you used last time – they are now release specific.
2. Take care with the details of what you book
When your Pods (environments) are provisioned and the welcome mails are issued to your identified key users – choose one user from the business and one from your implementation partner and take care to detail each party’s e-mail addresses accurately. The welcome mails, URLs and initial passwords are issued to these e-mail accounts so recording them accurately is critical to an efficient project take off.
3. Check your ticket details carefully
When your Pods are provisioned you will be allocated a new Cloud-specific Oracle Customer Support Identifier (CSI) from Oracle Cloud Admin and this CSI is critical given most, if not all, of your interaction with Support will be via an Oracle Service Request (SR).
Make sure your identified administrator for your Cloud CSI is familiar with the operation of MOS and knows how to approve assignments to the CSI. Assignment to the Cloud CSI is critical for each member of your Implementation Team in a similar manner to which tickets and visas are essential for air travel. My Oracle Support (MOS) is where your team raise, respond to and monitor all SR progress.
4. Plan your journey
Moving to the Cloud is always a re-implementation of your existing ERP/HCM system(s). Given this opportunity you don’t just need to consider the iterations of testing and prototyping you will need to go through but you also consider what will happen to your legacy systems and data when you transition to the Cloud.
So consideration of what happens to your historic transactions; the level of granularity you really require to keep. Whether you wish to replicate this history in the Cloud or just create
an archive of your data. The decommissioning of the legacy applications may well be an integral part of the business case supporting any Cloud Implementation.
You need to consider whether to and, if applicable, where you will archive this data, what its format should be and how frequently this data might need to be interrogated.
Remember, given Cloud ERP is a re-implementation there may well be Chart of Account design improvements and/or mapping consequences to consider and these should be discussed with the business in advance of any project kick-off.
Given your Cloud implementation is a re-implementation rather than an upgrade this affords you a great opportunity to objectively re-evaluate the design of your existing system design and architecture; e.g. Is your Chart of Accounts and Multi Org structure still relevant for today’s business reality? Are all those segments/locations really still needed? Can they be combined? What about the order? What about the size? Keeping similar values might ease any mapping but ask yourself do you really need more GL history than an opening TB at go-live?
Securing an archive of your legacy data and migrating only critical data should be your aim so the loading of just your open transactions only using the Excel based loaders should be your goal.
5. Your journey to the Cloud could be direct but needn’t necessarily be – a number of routes and stop-over options are available and should be considered
You needn’t put everything in the Cloud straight away – you could look to moving particular ERP/HCM systems or applications as and when. You might consider a co-existence strategy where particular applications move to the Cloud and others remain on-premise or hosted.
You might even want to experience the power of some of the Cloud Reporting Tools but from your existing R12 Oracle E-Business Suite system. This could be possible through the installation of Fusion Accounting Hub Reporting Cloud Service (FAH) as an initial step on your own Cloud journey.
All of the above travel options are available. However, to ensure your journey is successful the creation of a tailor made journey plan, fully cognisant of your existing systems and travel requirements, is essential.
6. Consider the level of travel insurance required
Consider carefully what documentation will be required to support your Cloud implementation. This will be driven to some extent by the complexity of the footprint being implemented and the extent of Business Process re-engineering likely to occur.
But the following should be there as a minimum:
• Application Configuration documents.
• Design and Architecture documents.
• Testing strategy, scenarios, conditions and forecast test results. • Conversion design documentation detailing assumptions
and tools to use.
• Cut-Over Strategy documents detailing activities and
7. Be aware of when “Peak Period” is and plan appropriately; planning and booking early is key
Remember, there are a great number of organisations undertaking their own Cloud journeys and yours is but another one. This might be your journey of a lifetime but any trip through any airport illustrates there are a great number of individuals on similar journeys. As such, when you schedule operations such as Production to Test (P2T) copies of your pods or test to test (T2T) copies you need to plan these sufficiently in advance such that the dates you want are available; remember you are but one of a
number of passengers on this journey so having a “strop” at the airline desk isn’t necessarily helpful for anyone. Forward planning and securing your desired flight times is key.
8. Your Cloud journey is “long haul” so choose an airline with a reputation for quality service
Moving to the Cloud is engaging in a long term relationship, not just with Oracle but with your Managed Services Partner. This is an important differentiator with anything Cloud based and needs to be carefully considered in the selection of your implementation partner.
You need to consider therefore what their approach will be to: • Monthly patching of each of your pods.
- Bi-annual upgrades to new releases of Cloud ERP/HCM.
- The implementation of new functionality or bug fixes within
the monthly patching cycle or the bi-annual release upgrades.
- Regression testing approaches for ALL of the above.
- Remember, this is a long term relationship which extends way
beyond the implementation project itself.
9. Unplanned excursions are not necessarily bad
Not all trips are planned – make provision and leave budget for unplanned activities – managing your SRs is a critical activity for any successful Cloud implementation and should be an identified project activity from the kick off.
If your project is of a significant size it is likely that the upgrading of your Pods to the next release will occur at least once during the execution of your project. Again, provision for such upgrades, as well as for any identified regression testing activities, should be made from the outset and be reflected in your pod management strategy. The copying of configuration from one Pod from one to another can only be undertaken
if both Pods are at the same patching level so consideration of patching cadence and even requesting weekly patching at critical periods should be considered and if deemed necessary scheduled with Oracle Cloud Operations.
Remember your Test and Development Pods are normally patched on the first weekend of the month, your Production Pod is patched on the third weekend of the month.
10. Remember to enjoy the journey
Your Cloud implementation will afford you the opportunity to interact with new technologies and tools as well as to update your systems for the realities of today’s business challenges. This isn’t likely to be a journey you make frequently, especially if you are moving from an On-Premise to a SaaS operating model. As such, take the time to enjoy the experience and to embrace the opportunities it affords.
As a Managing Consultant and Capability Lead, Patrick is primarily responsible for the provision of Cloud ERP solutions to our clients. Patrick was the Financials Lead on the first UK Cloud ERP and SCM implementation (R7), which culminated in a successful go live in 2014.
Facts and Figures
- example one 35%
- example two 57%
- example three 70%
- example four 86%
- example five 68%