Meet Krithika Bhat, Vice President of Oracle Applications Labs (OAL), and the organization within Oracle that implements applications for the company’s internal use. Her team focuses on bringing ERP and HCM initiatives to life for the entire company.
Krithika can be reached via LinkedIn.
I’ve been at Oracle for 21 years now and I’ve seen the company through many of our own transformations. Not least of these is the huge transformation we embarked on more than five years ago when we started our own journey to the cloud.
Our main drivers behind moving our business systems to the cloud probably echo a lot of what our customers and peers are facing. We needed internal systems to better support our digital transformation and have the flexibility to support varied and changing business models.
Oracle grows frequently via acquisitions, so our systems needed to be operationally agile and efficient enough to support all the new business models, employees, partners and customers coming in.
We needed a more efficient and faster way to access product innovations. An upgrade of an on-premises enterprise resource planning (ERP) system for a company of our size could take quite some time, and by the time we completed the upgrade, the solution could already be out of date!
Finally, we’re a little different from traditional IT departments in that Oracle Applications Labs is a part of our product development team. Therefore, we needed to go through the migration ourselves, so that we could share our process and methodology as a blueprint for our customers.
That’s enough about why we moved to cloud. Let’s talk about how we got started.
I cannot stress enough the importance of spending the time up front to get your foundational structures right. If you, like us, have multiple instances of data and multiple charts of accounts across all your global regions and business units, you may want to consider moving to a single chart of accounts.
Luckily, we had a very good baseline to start from. Prior to moving ERP to the cloud, Oracle had already centralized on a single global instance of Oracle E-Business Suite, on which all global processes operated. From there, the next significant foundational change we made was getting on a global chart of accounts. This really set the stage for all of the applications we migrated to the cloud.
I won’t mince words. This was not an easy foundational change to make and it was actually a process that we had started and stopped before in the past. But it needed to be done, and moving to Oracle Accounting Hub Reporting Cloud was the perfect time to make this change.
I would also strongly advise that, if you’re making this level of structural change, you must think ahead to other system migrations on your road map. I’ll give you an example. We knew we were going to move HR to the cloud first and that our financial applications would move later. We considered the foundational constructs that would be common to both, which made future implementations much easier.
We had an executive mandate to move to the cloud, so we had support from the very top. It was important, however, to line up champions at all levels. We had executive sponsorship from the lines of business, our chief accounting officer (CAO) and chief HR officer (CHRO).
Additionally, we partnered closely every step of the way with the global process owners—senior business leaders who actually owned the processes, such as the senior leader of the order-to-cash process who reports into the CAO. These champions are crucial as they understand the processes and can drive changes.
If you have a shared services team that does the transaction processing, I would suggest you bring them into the program right at the beginning.
Bi-weekly steering committee meetings were established with all of the above stakeholders so that we could make sure our executive leadership had full visibility to the program and provide guidance as needed.
Your organization’s path to the cloud will likely differ based on what you’re migrating—whether it’s applications, infrastructure or anything in between. It may also depend on your level of complexity. The type of application (whether mission critical or not) may also inform your path to cloud.
Because we’re a large, complex organization and because we’re talking ERP—a mission-critical system—we opted for a co-existence model. This meant we would have functionality in the cloud and on-premises for a period of time. We needed this incremental path in order to manage any potential risks of this change to our company.
[Editor's note: Full migration from Oracle E-Business Suite on premises to Oracle ERP Cloud is planned in the near term. We will have further updates in future editions.]
In addition to Oracle Accounting Hub Reporting Cloud, Oracle Talent Management Cloud was the first HR application we moved to the cloud; the sales organization was growing, and sales leaders needed a way to automate the talent review process. These early wins paved the way for the rest of our journey.
In summary, this incremental co-existence approach allowed us to demonstrate business value right at the outset—automating and improving processes in some cases, but at the same time reducing risk and helping us manage change. In addition, it meant that our IT and business teams were very familiar with the cloud solutions and operations in advance of the larger implementations.
As every program leader knows, it’s important to establish your success metrics right from the start. For us, success meant we had to migrate by a certain date. With a time-bound implementation, a line had been drawn in the sand, so we needed to move quickly.
The good thing about moving to a cloud model is that innovation is constant. It’s not like with an on-premises deployment where you need to get every feature and functionality into the application right from the start. With cloud, upgrades are rolled out almost constantly, so there is no need to try to get all the bells and whistles in one go.
We also configured Oracle ERP Cloud using the standard extensions available in our SaaS offerings. Where we have very specific requirements, we can build extensions with Oracle Platform as a Service.
Looking back, this process of moving to the cloud also gave us an opportunity to start fresh. We wanted to make sure that we weren’t porting existing processes to the cloud as-is, without figuring out as we went along if processes could be simplified or improved upon. We decided early on that our objective was not to rebuild our existing on-premises system, brick by brick and feature by feature. In fact, we opted not to do a map-and-gaps analysis with the existing Oracle E-Business Suite customizations, because it would be easy to fall in the trap of where we were—causing us to miss out on the future benefits of cloud. Just doing it the same way we always did it was not the way forward for us.
In my next blog post, we’ll talk about how we approached migrating data to the cloud and transitioning to production.