Mark and I had a really strong group for our operating models course last week. So we learnt as much as they did. We had the chief executive of a business, a consultant from Capgemini, another from Grant Thornton, a business architect, a head of HR services, a head of organisation and operating model design and so on.
The experience caused my mind to go into overdrive …. and I think I may have solved something that I have been wrestling with for years (well for 18 months!). The issue is about the sequencing of operating model work. My thoughts are much stimulated by Jonathan Hammond from Knadel, who made a presentation to the group towards the end of the first day. My idea is this.
Start with a value chain map – that shows the core work of the organisation and whether it is one value chain or multiple value chains, and, if it is multiple value chains, where there are overlaps and common steps.
Then create an organisation model: an organisation chart with relationship information on it, laid out in a particular format. See article at www.ashridge.org.uk/aod.
Then expand the organisation model into a “capability map” or “work to be done map” by identifying the work to be done in each box of the organisation chart. Initially start at quite a high level of detail, but more detail may have to be added as you get to the next step.
Then overlay onto this map the software applications that are needed to support the “work to be done” and draw on the data flows between software applications. It is usually useful to add onto the map the suppliers and customers and any other stakeholders to whom or from whom there are data flows.
This final map then contains, at a high level, value chain thinking, organisation structure thinking and software applications thinking. Jonathan showed us an example of this, which keeps coming into my mind. Of course it is much too complex for an executive committee – but it did seem to capture most of the important stuff.
From here the work can focus on a variety of things. It could focus on people: what sort of people are needed, how will they be motivated and developed, etc. It could focus on locations and assets: where will the work be done, what infrastructure or other assets are needed to support the work. It could focus on suppliers and business partners: who will the suppliers be, what will we do and what will they do and what terms will be in the contracts with them.
If you are doing an “as is” or a “to be” operating model, getting to the final map should take weeks rather than months. At a very high level, it should be possible to complete the value chain map, organisation model, organisation/capabilities model and capabilities/applications model in a day, if you have the right people in the room. As you add more detail, start to wrestle with differences of opinion and seek to gain the involvement and understanding of a larger group, the time grows exponentially. So it may take three months to get down to the fourth or fifth level of detail.
So then my remaining issue is how to represent the operating model to an executive committee. This is where the Operating Model Canvas comes in. I blogged about this some months ago, but have done very little work on it since. The benefit of the OMC is that it captures the value chain map (under “activities”) and the organisation model (under “organisation”) and still has space for thoughts about people, IT systems, locations, buildings, other assets and suppliers.
I feel as though the holy grail is within sight! But I need to blog on how to convert strategy into something useful for those doing operating model work and the Operating Model Canvas.
Ashridge on Operating Models 
Andrew
It sounds like you are broadly describing the work / approach that I take in developing an operating model or capability model.
Points of similarity include:
a) starting with value chain(s) / business model(s)
b) identifying points of commonality or interaction between the value chains
c) developing a capability model which brings in the necessary strategic functions and resource management functions
Whereas you describe the second step as applying an organisation model, I move to the capability model, avoiding organisation structure thinking until the capability model is developed and validated, and enabling consideration of capabilities which might be externally sourced versus those which need to be internally managed.
It sounds like the rich composition of your last group was valuable in bringing the different perspectives that are needed to have a fully fledged and effective approach which will address the varying interests of key stakeholders in developing any future intended operating model for an enterprise,
Yes Peter you are probably right. I am still in two minds about where to do organisation modelling work. Maybe it comes second when you are doing an “as is” and later in the process when you are doing a “to be”. In practice I note that most capability maps group capabilities together in ways that feel like organisation structures … but without having done an organisation model.
The bit I still haven’t figured out is where the links between capabilities are created. This connects with the “send an invoice” discussion we had in the LinkedIn group on consulting.
Aren’t the links created by the value chain that chains capabilities together ? The information / data that flows over those links can then be modelled as an Information Architecture and the capabilities documented with a SIPOC.
Once that value chain of capabilities is created then it’s an arbitrary split as to where to put the organisational boundaries. Organisational interfaces cause tension so then it’s a trade off between creating organisations that can be sized as manageable chunks and keeping the number of interfaces low.
The links I am thinking about are more strategy links than capability links. So that the capability “send and invoice” is executed completely differently if your strategy is customer intimacy than if your strategy is operational efficiency. I am not sure where that thinking gets into the operating model work.
After you’d defined your value chain I would document the business design using the Business Motivational Model. In that, I’d define HOW I wanted a capabily to operate by injecting BusinessPolicy into the motivational model. That Policy then influences the Strategy and (in BMM v1.1 extension) the Policy governs Business Process. So, architecturally, I’d be able to show that I wanted a capability (OK, a Business Process) to operate in a particular way (customer intimacy rather than operational efficiency)
Practically, I’d probably just review all of the BusinessPolicy and turn them into a set of Principles for when I was writing the processes.
This sounds good – but, not being familiar with BMM or Business Policy (in the way you are using the term) I am not sure if I understand. Is there any way you can explain this without the jargon.