Your First Cloud ERP or Fusion Implementation

Let’s take a hypothetical scenario: You’re called into your manager’s office and told you are implementing Oracle Fusion on a Software as a Service (SaaS) model. The contracts have been signed, the environment is on order and you are booked on Cloud training starting Monday.

Training passes and before you know it you receive your first email entitled “Welcome to OracleCloud” from Oracle Cloud Admin.

Things have gotten very real, very quickly.

So …. what next?

You check your inbox and already you have a second email from Oracle Cloud Admin, almost identical to the first ….. but now you’ve got your second environment.

You may have implemented Oracle E-Business Suite (EBS) before so understand the process and the AIM documentation underpinning it. After your Cloud training you understand that the terminology has also moved on. Fusion SaaS has become Cloud ERP or HCM Cloud depending on your implementation footprint; perhaps you’re doing both and now you use Oracle Unified Method (OUM).

Let’s take a step back and understand what the reality of this situation you now face is….

Oracle Cloud is a hosted environment, although in this case, it is hosted by Oracle. You can implement Fusion in the Cloud or on premise, but the vast majority of projects are Cloud-based.

Commercially you are looking at contracts using the terminology of “Subscriptions” rather than “Licenses”. That’s where the significant savings (Op Ex vs Cap Ex) and reduced Total Cost of Ownership (TCO) comes from. My first Fusion client delivered a saving of approximately 30% in their annual IT spend by moving their ERP to the Cloud.

Already you have two Cloud environments, one is defined as “Stage” and the other as “Production” and in the world of Cloud, they are no longer referred to as environments, they’re “Pods”.  My client’s subscription was for the standard Oracle packaged offering of x2 Pods – Staging and Production.

In addition, you plan to run a number of Conference Room Pilots (CRP’s); which are now referred to as Functional Prototypes (FP’s).  Again just some terminology revisions, nothing you shouldn’t be able to handle.

… but have you really thought this through?

What follows is “the benefit of hindsight view” of how my client went live on Cloud ERP with Financials and Procurement, as an early adopter, and how we managed our Pods to support this significant accomplishment.

The implementation was based upon an iterative approach utilising the Cloud business flows published by Oracle which we intended to run through in FP1. Out of FP1 we would record and progress any concerns with a view to running FP2 just four weeks later. The client had agreed to adopt the Fusion business processes and to revise their business processes to fit with the Cloud software where necessary. Customisation was not to be entertained; remember this was December 2013 so before of the opportunities of Oracle’s PaaS were available.

Our initial build and FP’s took place in our Staging Pod. I wanted to keep our Production Pod completely clean until such times as we had confirmed all the set-ups and were ready to commence the production build.

I undertook my initial build using a shared Financials and Procurement Business Unit (BU). As one might imagine, in any early implementation issues were encountered, alternate configuration options were built, matters were tested and solutions evaluated. Some issues required SR’s with Oracle Support and investigation and resolution activities ensued. All with a view to the successful testing of our initial configuration at FP1.

FP1 ran with lots of discussions, possible revisions noted and some SR’s were raised. SR’s not just with regard to the operation of the software, but also for clarifications of what was and wasn’t allowed in an Oracle Cloud environment.

Out of FP1 came a number of additional activities undertaken in our Staging Pod as we looked at potential alternate configurations, investigated issues, clarified functionality and readied ourselves for FP2.

FP2 was also to be run in our Staging Pod so, post FP1, some housekeeping was required in order to isolate our FP2 activities and data from the myriad of activities associated with FP1.

If I was to list the activities undertaken in our Staging pod, at a high level by the end of FP2, they would look like:

1. Sandpit/Play area as we tested the Cloud functionality
2. Alternate configurations assessed in a number of areas – e.g. procurement approval hierarchies within AMX
3. As issues were identified SR’s were raised, investigated and resolved – as an SR test environment
4. For the execution of FP1 (CRP1)
5. For the execution of FP2 (CRP2)

In addition, the environment was also used for data load and migration activities:

6. Supplier loading activities
7. Open Invoice load testing
8. Open PO load testing
9. GL history load activities

As well as the development and testing of our reporting solution utilising the new reporting tools of OTBI, Account Monitor, etc …. So, it was also used for:

10. Report development and testing

In addition, given the complexities of the activities above, we wanted a robust documentation of the ensuing solution given there was now significant redundant configuration/data in our Staging Pod so the options around copying Cloud environments/configuration, whilst of interest, were ill suited to this particular scenario.

Once our Financials and Procurement solution was fully documented, I wanted to mitigate any risk of potential error in this documentation impacting our Production build so created another shared Financials/Procurement BU using our configuration documentation as the primary basis for that build. Again, all in the Staging Pod.

Whilst following such a risk averse approach, a purist might wish to point out that my initial build was for a single shared BU whereas now I had two. Such a criticism is fair as my multiple BU approach now resulted in the occasional SR where the behaviours of the system differed with single or multiple BU’s. SR’s were raised, matters resolved but the risk of any documentation error sullying our production build was mitigated.

In addition, in the run-up to go-live, we also ran the following activities in our Staging Pod:

11. Build revisions/additional BU’s using our set-up documentation in preparation for the production build
12. UAT
13. User training
14. Interface Testing
15. Data Conversion Testing

Patching

With Cloud, your environment is patched every month by Oracle. Staging is patched over the first weekend of the month and Production on the third weekend.  As such, you have a two week window of opportunity in which to identify any possible issues caused by the patch application before the same patch is applied (again by Oracle) to your Production pod. Remember, this activity happens every month of the project, not just when you go-live so you need to schedule your activities accordingly and plan for the loss of system access on the patching weekend and the ensuing regression testing activity. So staging was also used for:

16. Patch application and regression testing activities

As you can imagine, doing all of the above in a single environment created a number of challenges and required a resourceful approach to the resolution of each. Nothing detailed above was insurmountable, but planning for and procuring additional Pods, albeit for short periods, might have eased the process.  A point for consideration here is that there is a trade-off between the potential benefits of additional Pods, even for limited periods of time, versus any attached costs.  Pods are not free.

There were periods when performing a number of activities in the same environment was challenging but with clear communication across the project team any ensuing issues were kept to a minimum and were carefully managed as and when they occurred.

In August 2014, we successfully went live of R7 Cloud ERP.

Lessons learned?

Having successfully made the transition from running Oracle EBS to running Cloud ERP, there are a number of matters you need to carefully consider to ensure that successful outcome:

• Cloud is a re-implementation. Cloud ERP is NOT EBS but your EBS experience is just as applicable with the new product as it was for EBS. Remember Cloud may be a new product but you are still implementing an ERP.
• With Cloud, you are looking at minimal or no customisation and the adoption of standard processes.
• Enhancement Requests (ER’s) can result in changes to standard Oracle product. During our implementation we raised some and they were included in the Oracle product in a matter of months (and before go-live).  Each ER needed a strong business case in support of it but the overhead of creating that is minimal when measured against the improved functionality achieved.
• Where you have a number of competing activities happening in the same environment – this will naturally create some tension across the implementation team, and here costing for and securing additional Pods might mitigate issues encountered. However, having a single staging pod DID drive project communication and collaborative behaviours, albeit out of necessity but the global team pulled together successfully.

Ultimately, our Production build was clean and robustly documented but primarily it worked.

Nothing above constitutes “rocket science”, it’s merely the application of existing ERP experience to the world of Cloud ERP resulting in a successful go-live and ultimately a referencable client.

Job done!

Next Steps …. With Claremont

All of this experience is now reflected in the approach and services offered by Claremont’s team and our associated Managed Service. Our unique approach isn’t just for the Cloud implementation, but carries forward into the all-important realms of production running where we can provide a comprehensive support service. For example, we can help you to identify and adopt new features in the regular product releases, provide training for these features, support the monthly regression testing required of Cloud, and much more to help you maximise your investment in Oracle technology. We can do this on your behalf thereby freeing your Finance and IT staff to concentrate on adding value to your business rather than looking after the provision of your ERP.

Unlike many other organisations, Claremont has real world experience of successful implementation of Cloud ERP and HCM Cloud, and an impressive service-focused heritage in supporting a portfolio of Oracle managed services clients. You are not alone.