Afternoon With ACES - Follow Up: 10 Years Cloud Implementations - What Did We Learn?

Hey Thomas and Lee - thanks for the ACE to ACE discussion yesterday. I found it very interesting and congratulate you for pulling it off in spite of the main presenter (Andrew) being a no-show.   Key topics of interest for me were:

• 1.What have you learned in the 10 years of Oracle Cloud implementations? What are you doing differently and what are you doing the same? Lee seemed to say his methodology is including more "requirements" analysis again versus initially "there is only one way".
  
• 2.What is different in your methodology and approach about implementing EBS R12 versus Cloud SAAS? I heard that a key difference is the easier application access (no Java and VPN struggles). I would love to hear more about methodology, preparation, user satisfaction etc....

Good Questions - Thinking Hard

In the beginning of ERP, when we first started, ERP was new. No one really knew what they could do or more importantly, what they wanted. So, we would spend weeks, and sometimes even months, creating a requirements document, to baseline what they needed / wanted in a system. I was somewhat of a fan of that because as a consultant, it did give a clear target at which to shoot and something to measure. The drawback was, the customer didn't get to see software for a long time after the project had started.

In the early 2000s or so, Oracle came out with RapidStart (or a similar name) which offered completed setup documents and scripts to test the setups based on those documents so that the customer could get to the software sooner, but, the system may not have been as close to what they wanted.

The evolution of that approach was the Oracle Accelerators. A set of questions that looked like business questions that could be 'transformed' into setup steps to configure the application more tailored to what the customer may want, but still generic enough to get it set up quickly. It came with a really nice set of business process flows and test scripts to serve as the baseline for what the instance could do. From my perspective, this was the beginning of solutions-driven requirements gathering. Let us show you what the system can do, and then you tell us what more you want. The consultant was then not starting from a blank piece of paper, but instead was only solving for the delta.

For most of my consulting life, except for a stint with the Big Four, I have worked at boutique firms. We tend to see more projects as they are smaller and faster than what the Big Four usually see. To be certain, Lee and I worked on large, multinational, multi-pillar projects, and those projects were run very traditionally, get the requirements, then configure, etc. But for the smaller ones, we used this solution-driven approach and for the most part, it worked and still works great. Let the software, out-of-the-box, unadulterated by the burden of heavy customization show the customer the leading way to process a transaction.