Operating models for continuous improvement: Part Three

In Part Two of this series, we examined the risks and pitfalls associated with waiting too long to  develop an operating model for the support and continuous improvement of your Oracle Cloud Applications. Here in Part Three, we’ll look at the building blocks you need to put in place to develop a model that works for your business.

The foundation of a strong operating model is a systematic approach to data gathering to help you understand your ongoing support needs after you complete your implementation and move into business as usual (BAU). This lets you identify where you have skills gaps and what you need to do to fill them. It also gives you the information to define the governance needed to get the full benefits of continuous improvement.

In this blog post I’ll focus on the activities to complete and the data to gather to design and deliver an operating model that helps you get the most from your Oracle Cloud Applications after you go live.

Operating model design: key steps

The following diagram shows the steps to take to design your operating model and ensure it’s supported by an effective change management journey:

Research and analysis

Research and analysis are key to change management and organizational redesign. To properly understand who and what you need to support your new system, you need to understand what it does and what roles are required to operate it.

Start by mapping the to-be business processes required to run your operations, along with the system roles needed to complete each one. This allows you to identify where you already have resources in place to complete those processes and which departments are involved. This also lets you identify gaps. Or if the focus of work has shifted—for example, new automation functionality meaning you’ve moved from data entry and manual admin to data quality and value-added tasks.

Once you understand the operational scope of your system, your next step is to complete a business impact analysis. This will help you understand:

• What’s changing in your organization because of the process redesign
• Who is affected
• What the benefits are
• What challenges need to be addressed

You then use the data captured in this analysis to build a stakeholder profile and define the key messaging for different stakeholder groups. This lets you perform message segmentation and targeted communications to address specific stakeholder needs and interests.

This also feeds into the learning needs analysis, which lets you scope out training and communications to help your people understand how their ways of working will be changing.

Continuous improvement

Along with informing your communication and training approach, these activities help clarify your ongoing support needs once you move to BAU. To get to this point, you need to consider the roles, responsibilities and tools required to provide that support.

This involves a review of program team members, current support team structures and helpdesk models, and may require some team restructuring or role reassignment.

You’ll also need a strong system and master data governance in place to control the solution so it continues to meet your changing business needs. Regular software releases include mandatory and optional changes to functionality. With each release, you need to make sure you know:

• What the changes are
• How they work
• How they’ll impact people and other systems
• How you can optimize their use

For this you’ll need expertise of both the system and its design, and from your business—as  your team is best placed to know what’s needed to support their own performance. As mentioned in Part One of this series, cloud applications differ from on-premises systems in that you can’t just have new core functionality built to spec. Key staff will need to evaluate new, optional functionality for each new release to decide if it meets business needs or provides new opportunity. This means ongoing collaboration between system support teams and business process experts and needs to be built into those roles and your governance model.

Once you’ve pulled together the data and analysis detailed above, you have what you need. You can now clearly define and design how your operating model will look and the people you need to maintain and improve your Oracle Cloud Applications in the future.