Operating models for continuous improvement: Part Two

In the Part One of this series, we looked at the concept of ‘adopt not adapt’ and the need for a mindful approach to application support when walking the path of continuous improvement. Now we’ll take a deeper look at some of the risks of not embracing an operating model to provide structure for ongoing operations.

For program teams caught up in the day-to-day demands of an Oracle Cloud Applications implementation, it can be difficult to take a step back and analyze what’s needed for the continuous improvement program to work. It is also challenging to understand what’s needed to both provide users with high-quality ongoing support and to take advantage of the new features offered in Oracle’s regular updates.

By the time your project goes live, all you have witnessed is an increase in cost and disruption to your business. You don’t start to realize any return on investment until after you’re live. But most organizations don’t recognize the importance of developing a cloud-aligned operating model until it is often too late to introduce one…

But if you don’t properly consider your Business As Usual (BAU) needs, or leave it too late to put a support structure in place prior to go-live, you’re at risk of entering the dreaded Circle of Doom below:

If you don’t fully understand the operational scope of your Oracle Cloud implementation, you can’t be clear about what you need to run your system effectively: the business processes involved; the roles required to operate the system; and the full range of systems and processes impacted by the move to Oracle Modern Best Practice.

It then becomes a struggle to get to grips with what’s needed to support the new system and its adoption. Without the right support to help users understand what they’re doing, or governance to guide decision making around how to adopt new functionality, systems start to degrade. Performance issues emerge as users find themselves unable to operate the processes as they’ve been designed. And lots of time is spent trying to fix issues and defects, which leaves little or no time to understand which building blocks are required to ensure the right support is in place.

It’s a vicious cycle that can result in new projects being initiated to review and reimplement features that simply weren’t originally fully understood and, as a result, haven’t been properly maintained. This is both unnecessary and expensive in terms of additional consultancy costs, lost revenue from poorly defined and unsupported processes, and loss of confidence from staff, suppliers and customers.

When implementing cloud products, it’s important to remember that you aren’t aiming for a steady state. Instead you want to see evolution and enhancement of your systems, processes and data quality. So it’s important to take time to understand what your ongoing support needs will be once you move into BAU.

Inoapps can work with you to define your Oracle Operating Model. We can help you establish what you need to support your Oracle Cloud solution, and if you have any skills gaps and upskilling needs. We can also assist with defining the processes and governance needed to ensure you get the most out of your Oracle investment.

In our next blog, we’ll explore what you need to think about when developing your Oracle Operating Model, and how to structure your analysis to fully understand the support needed to place you firmly on the road to continuous improvement.