In September 2016, I presented at Claremont’s breakfast briefing – “Oracle ERP Cloud: Lessons Learnt from Trailblazers”. As Claremont’s ERP Capability Lead and having completed two successful Cloud ERP projects (both referenceable), I offered my “Insider’s Top 10 Tips to Successful Cloud ERP Implementation”.
COTS = “Commercial off the Shelf” – aka “vanilla” or “Out of the Box” (OOTB)
A key benefit of Oracle’s Cloud ERP, is that it’s a SaaS offering and for any customer this means employing configuration rather than customisation to shape their new system.
You know I like a good analogy. The best way to describe your Cloud Journey is to think of it like a train journey. You arrive at the station and board the train as a passenger, not as the train driver; that is Oracle’s job. Oracle have the system development experience and have made a significant investment in Cloud as their strategic destination.
With Cloud, there is very limited customisation available. I know this can take some time for people to get their heads around but there are significant benefits to such an approach. These benefits include an easier implementation, much easier upgrades and reduced system costs given Oracle take care of the hardware and associated maintenance within your monthly subscription.
As with any IT implementation, it’s important that all your stakeholder’s really understand the new system and how it will work for your business. In the “New World” of Cloud, this is much easier than it is in EBS.
Gone are the days of having to trawl through a huge library of PDF docs for every release. With Cloud all documentation is available on-line. Having web based resources means that all content is current, updated and accessible. Therefore, there’s no excuse for not swotting up on these critical resources:
MOS
Oracle Docs
OER
Oracle’s website
As with any project, planning and communication is key to success. However, my experience implementing Oracle SaaS projects has taught me that there are two key factors which help determine that Cloud success;
(a) Having a designated solution architect/lead consultant who understands the business, the Cloud technology and the approach to the implementation.
(b) Both Cloud ERP projects, I’ve been involved in, have had very strong client side leads. These individuals have been able to drive through the business and process changes that need to happen for a SaaS project to be successful.
Also, remember to maintain a realistic expectation of what is possible within the time frame and the project scope.
Managing change and customer expectations when implementing any project like is vital to its success. However, the “elephant in the room” for Cloud projects is that Cloud is always a re-implementation.
Re-Implementing means that you can keep the “good bits” pre Cloud ERP, however, it’s a great opportunity to look again at previous architectural decisions, to cleanse the data and have a fresh start. The baby doesn’t have to exit with the bath water and the customer doesn’t necessarily have to have been on EBS!
As with any relationship, treat everyone else as you wish to be treated. A cliché I know but it’s important to keep promises and keep Oracle “on side” to position your project to make best progress. Oracle are there to help you succeed but you need to play by the “Oracle rules” and be easy to deal with, so take time to understand the Oracle support processes and how best to engage with them.
In the “new world of Cloud” Oracle have created a number of new roles designed to ensure the long term success of Cloud projects. These new roles include Implementation Success Managers (ISM’s) and Customer Success Managers (CSM’s). It’s essential to engage with your ISM early and throughout the whole project to ensure that you have the best support from Oracle. Personally, I had a call with mine every Monday morning and used them as a point of escalation when necessary.
In addition, when it comes to getting your project live and across the line the Critical Accounts Management service is very useful and someone again who you need to request and get to know. They are an invaluable point of contact for progressing issues and making things happen. Again, I used this service in both of my Cloud projects.
For me, this was one of the biggest learnings from my projects.
Service requests (SR’s) are raised through MOS (My Oracle Support) and are your primary method of communication with Oracle’s technical teams. It’s important to ensure that you have a robust process in place to ensure SR’s are managed correctly and efficiently. Having lots isn’t necessarily a bad thing, it just means they take significant time to manage.
Closely monitor your SR’s daily, it should be morning and night if you want everything to move efficiently. Don’t be that person who says ‘Well… in EBS it … works that way’. This isn’t EBS and I can promise you, you’ll do little for your cause if this is how you approach Cloud SRs.
The product isn’t EBS.
Cloud Apps vs the next EBS release are, of course, very different products. EBS supports customisation but the expanding functionality and modular footprint in Cloud offers a different way of meeting a business’ functional requirements.
Cloud has a much shorter implementation cycle than a traditional EBS project. Remember, that train analogy… minimising customisation options and adoption of leading business processes available allows for time and money savings. Improvement in functionality “just happens” when Oracle upgrades your pods!
Now you’re a Cloud customer, quarterly patches will be a big part of your life as patching has just moved to a quarterly calendar. Plan for these and make sure you take advantage of new and improved functionality when it comes out either in the quarterly patches or, more likely, in the release upgrades twice a year. It won’t configure itself so you need to make provision to implement new functionality.
The implementation team is made up of both
(a) Client side resources, and
(b) Consulting team resources
It’s critical that the client’s Subject Matter Expert (SME’s) are embedded within the project throughout and empowered to make decisions if you want to achieve that shorter implementation.
As I’ve mentioned before, the regular patches and upgrades will continue and need to be managed post go-live. It is key that you think about who and how these will be managed… perhaps look at whether your implementation partner can become your support partner on-going?
For your Pods (think environments), you need to consider: how many, what for, who uses them, when do I need more/less, etc…. Make sure you establish the necessary processes and procedures to support this.
Obviously it’s difficult to manage a number of competing activities happening in the same environment. On my latest project, I used x3 pods, two staging pods where one was used for FP1 and the other for FP2 & UAT and one Prod pod.
The “good old days’ of x10+ on-premise test environments on a large ERP project are gone, unless of course you need them and if you do Oracle will be happy to spin them up (but obviously not FoC).
Oracle Cloud ERP supports modern businesses requirements. Although there are lots of similarities with EBS, remember that Cloud is a different product and requires a new approach where customisation is possible but discouraged. It requires a new mindset.
Opening communication amongst the project team is critical to your success. It’s important to adopt a realistic timeframe and maintain realistic expectations throughout the duration of the project.
However, it’s not just about the implementation. it’s not just you and Oracle, but rather, you, Oracle and an implementation partner able to work with you beyond “go-live” to exploit the continually improving functionality and expanding footprint of Cloud ERP. After all, you want to take advantage of this as that’s why you went Cloud in the first place!
Here at Claremont we have that experience, the knowledge to support your Oracle Cloud ERP project beyond the initial implementation and to support your Oracle Cloud journey long term.