StratChat 11 Feb 2021: Operating Models
StratChat is a weekly virtual networking event for anyone with an interest in developing and executing better business strategies. It is an informal community-led conversation hosted by StratNavApp.com. To sign up for future events click here.
StratChat is conducted under Chatham House Rules. Consequently, the summary below is presented without any attribution of who said what. As such, it is an agglomerate of views - not necessarily just those of the writer or indeed of any one individual.
On 11 February 2021, we talked about Operating Models.
Working on the business
Most people work in the business. They have a specific role. They are allocated specific resources. They can collaborate with other people. But those people are also operating in the business. The business has a specific shape, with defined boundaries.
When doing business strategy, we work on the business. We consider the shape and structure of the business. We look at its boundaries and how it interacts with the external world. And then we propose changes to that.
(Working on the business is not the role of business strategists alone. It is also what every CEO and leader should do. There is a significant overlap between the role of the business strategist and CEO/leader in this regard.)
Operating models provide us with a framework for understanding the internal and external shape of the business. They are a tool for working on the business rather than in it.
One of the simplest ways of doing this is to:
- Describe the Current Operating Model (or COM) and analyse its strengths and weaknesses relative to the opportunities and threats that the business faces.
- Design a Target Operating Model (or TOM) which is an improvement on the COM given the aforementioned analysis.
- Do a gap analysis between the two.
- Develop a programme of work to close those gaps.
Some frameworks for operating models
People, Process and Technology
One of the simplest ways of describing an operating model is to consider the people, processes and technology that make it up.
That can be considered reasonably comprehensive:
- People: all the human elements of the organisation.
- Technology: all of the non-human elements of the organisation.
- Process: all of the interactions between these elements.
However, useful as this is, at some point, it becomes too simplistic to solve real problems.
Andrew Campbell, from Ashridge Business School developed the POLISM model in an attempt to plug that gap.
You can read more about it in his book Operating Model Canvas.
It puts process, in the form of Value Delivery Chain(s), at the heart of model. It also clearly connects it to the Value Proposition(s) which the operating model delivers to the customers/beneficiaries.
The Business Model Canvas
The leftmost three sections of the Business Model Canvas represent the operating model with the broader business model. These are:
- Key Partners
- Key Activities (representing processes)
- And Key Resources (which might be considered a proxy for technology).
This representation within the broader context is useful. However, like the People, Process and Technology model, it might be considered too simplistic for many purposes.
We talked about the Business Model Canvas at a previous StratChat.
The Enhanced Business Model Canvas
In response to this, Campbell et al, replace the original Key Partners, Key Activities and Key Resources in the Business Model Canvas with the POLISM model.
This results in an Enhanced Business Model Canvas. It offers, perhaps, the best of both worlds.
Porter's Value Chain
Porter's Value Chain is perhaps the grandfather of much of the thinking that followed.
It still has a place, though. In particular, it reminds us to consider not just the core processes, but also the necessary supporting processes. These invariably include finance and HR. But there may be a range of other supporting processes depending on the nature of the business.
CCPPOLDAT is an acronym that stands for:
As with the Business Model Canvas, you can see how the POLDAT describes the operating model, whilst the CCP brings broader context. It should also be noted that the POL in POLDAT and POLISM are the same.
As with most models, there are countless other variations. Many consultants would much rather create their own, even if the changes were mainly cosmetic, than admit they were using someone else's work!
The frameworks, of course, are only a means to an end. In strategy, we may need to work on any part of the organisation. But simply talking about the organisation as a whole feels to complex. So we use the models to break it down and sequence the order in which we tackle things.
Much depends on the context. The nature of the problem we're trying to solve for. It is unlikely that any one model, or order in which we approach it, will be best in all circumstances.
Probably the biggest risk is that we use the frameworks as a basis for establishing workstreams. This is particularly problematic with simple structures like People, Process and Technology. There is a risk you end up with three workstreams: the HR director pursuing a people agenda, the Operations director undertaking some form of BPR and the IT director upgrading technology, with no linkages between the three or with any form of an overarching strategy.
Setting the context
Before designing an operating model, it is important to be clear on what the business strategy is. The operating model delivers the business strategy.
This includes being clear on who the customer is, and what the value proposition is.
Many internal and support functions struggle to articulate this. Job/role descriptions seldom define who the customer is. Who uses the output of the function/process? To whom is it valuable?
Once you've defined that, it becomes much easier to specify what work is required to produce that output. This leads you to a consideration of process. The other elements of the operating model can then be addressed around the processes, as indicated in the POLISM model.
More important than the order in which you approach different elements is that you end up with an aligned and integrated answer. Operating model development is often iterative. That is you may have to revisit and redesign each element several times as you work towards aligning them all with each other.
Focusing on the work that is needed to achieve the output/outcome is also important in that it frees you from the existing structure and the way the work has been done historically. This is necessary if you are to have any hope of coming up with a better answer than the current structure and vested interests implies. It allows you to step outside of working in the organisation to work on the organisation.
The Business Architecture Guild attaches business capabilities to the value delivery stages. The business capabilities reinforce the importance of outcomes. They provide a container into which you can subsequently add the people, technologies, information etc. need to achieve those outcomes. For example, if you need a capability to dig holes, then you can choose to fulfil that either with lots of people with spades or with few people with industrial diggers (depending on a more detailed understanding of the requirements and other circumstances).
The whole of the operating model exists to support the organisation's ability to add value. This includes not just the core functions like manufacturing, marketing and sales, but also the supporting functions like finance, HR and even secretarial, reception and cleaning teams.
Each function should be specifically tailored around the organisation's value chain and strategy. If it is not, then, arguably, it would be better outsourced to someone who specialises in the capability.
Napoleon is reputed to have said "An army marches on its stomach" (source). Related saying include "to stop the army, kill the cook", and "amateurs talk tactics, and professionals talk about logistics".
All of these highlight the crucial nature of support. Its team to focus on high profile attention-grabbing functions like sales and marketing. These often appear to be the visible heroes of an organisation. But they would not succeed without the aligned backing of the support functions at every step along the journey.
Operating model work reminds us that we must focus on the whole organisation, not just its most visible parts.
Who is the customer?
Before we design an operating model it is important to understand the customer and their needs. As a result, many operating model conversations start with a conversation about who the customer is.
It's a simple question, but not easily answered. It is very rare that you can walk around and organisation and get a consistent answer from everyone you speak to.
If one takes a value chain perspective, you might ask, is the customer:
- the end consumer of the product or service,
- the person you sell it to - the next organisation in the overall value chain - for example if you wholesale your product to a retail distributor, or manufacture parts for an assembler, or
- the next internal department within the organisation along the value chain.
Or, perhaps we have to consider that a single organisation can have:
- multiple different types of customers,
- multiple segments within those types of customers,
- and that even seemingly identical customer can want different things at different times.
All of this needs to be taken into consideration. If designing a standardised operating model for a single uniform customer was not hard enough, designing one around multiple types of customers is much harder!
We'll be trying to unpick and answer some of those questions at next week's StratChat. Why not find out more and sign up to join us.