How to work with someone who does not understand operating models?

Today I was asked an interesting question.  How can one engage senior managers in the importance of doing operating model work?   My answer was that this is the wrong question, and I gave the analogy of a carpenter.   If someone needs the help of a carpenter, they do not want the carpenter to try to persuade them of the importance of understanding the grain of the wood or the importance of measuring twice and cutting once, or even of the superiority of a tungsten tipped chisel versus a normal chisel.  They want the carpenter to fix the door or make the cabinet.

So, what does this mean for someone who is good at operating model work, who is approached by, for example an operations director for some help.

First, I would try to understand what help the operations director thinks he (or she) needs (if any).   How does he perceive his problems or challenges or opportunities?   From his perspective what is he trying to do; what does he think is getting in the way; and why does he think he needs some help?

Lets say that the answer to this is that he wants to review the degree of centralisation of powers (decision rights and controls) and of certain capabilities because he thinks it might save cost and raise quality.

I would then construct a work plan including some diagnostic and some facilitation and some analysis of options designed to help him answer the question he wants answered.

However, as part of my diagnostic, I would put together the current operating model for his area – a stakeholder analysis, the value propositions for his core stakeholders, the value chains that deliver these value propositions, a value chain map, an organisation model and an Operating Model Canvas.  This might be no more than one day’s work laying it out at a high level, but is likely to take some elapsed time to collect the information needed.   I would then use this understanding of the current operating model to think about the changes that he is trying to make and the ambitions he has, and note how many different parts of the Operating Model Canvas any changes are likely to need to “touch”.  In other words, I would try to understand and consider the whole system.

I would then work up some options that address his primary concern.  I would then engage him (and others in Operations) to see which options they think will be effective and why.   At this point, I might start to feed in some of my thoughts about other parts of the operating model that might need to change in order to make each option work.

Assuming there is a favoured option, I would then try redesigning the whole operating model (so far as I think it needs to be changed) to ensure that the whole system will support the proposed change.

Then I would make a recommendation that, alongside the change he is focusing on (e.g. greater centralisation of engineering), he should probably also be thinking about other changes that will support it (such as, changes in structure, changes in people models, changes in location,  involvement of new suppliers, additional IT systems, changes in the management processes he uses to run the function).

In other words,  I would not try to get him to define the brief as an operating model project unless he wants to; and I would not try to get him to define the phrase “operating model” along the lines of my definition unless he wants to; but I would use my knowledge of operating models and my toolbox to ensure that the final recommendation involves all the changes needed in the system he is running to give the best chance of achieving what he is trying to achieve.

I would hope that the experience would help him (or her) see the benefit of thinking about and communicating his operating model – rather than just focusing on some part of the whole that needs to change.

Posted in change, Design steps, Getting a brief from the client, Getting started, operating model, Operating Model Canvas | Tagged , , | 2 Comments

Eleven visuals that communicate an operating model.

As some of you may know, I am writing a book on operating models, which will probably be called “Operating Model Canvas” – to connect with the “Business Model Canvas”.  I am also making this the center piece of my course Designing Operating Models.  

So here is something I have been working on for the book – the eleven visuals.  After all, one of the definitions for the word model is “a visual way of displaying how something works” (this blog has been updated a little from four days ago – so some of the comments may not fit the text exactly – but please comment).

So here is my current list – and a visual showing how all these visuals fit together! The visual in the middle is the operating model canvas (POLISM – Processes, Organisation, Location, IT, Suppliers and Management System).  I don’t yet have pictures of all the other visuals – but it is coming.  When you look at the framework in the middle try to work out where the P or O or L fit!  The little icon symbols, if you can see them, might help.

Comments please.


  1. Stakeholder Map: this is helpful in clarifying what is inside the operating model and what is outside the operating model and the type of relationships that exist with those outside (see comments – Richard is suggesting that something richer is needed here)
  2. Value Chain Map: core visual that shows the operating work that needs to be done to deliver value to the beneficiaries of the operating model.  Vital tool for clarifying sources of excellence and problem areas.  Also vital for thinking about where similar activities/capabilities should be combined, linked or kept separate.  Helpful for thinking about in-sourcing and outsourcing, and hence good to link with the stakeholder map. (See comments – Alex is suggesting an additional cost waterfall chart)
  3. Organization Model: converts the value chain map into an organization structure, and provides a framework for adding all the supporting functions and capabilities into one picture.
  4. People Models: outlines the people model (who we want, what we offer them, what career path, what culture) for each skill group that is critical to the organization’s success
  5. Decision Grid: lists the ten or twenty major decisions that the organization makes and defines the role of each organization unit in making these decisions using RACI or RAPID
  6. Process Ownership Grid: combines the organization model and the value chain map into a table so that it is clear which operating processes touch multiple organizational units, where there are likely to be difficult working relationships between organizational units and which organizational unit(s) own(s) each process (or part of process).
  7. IT Blueprint: using the process ownership grid, it is possible to mark on the table what applications are needed to support each process, whether the application is bespoke or a standard module and whether the application is owned by IT or the owner of the process.  There are many uses of the phrase IT Blueprint.  This is a particularly high level use of the term.
  8. Supplier Matrix: summarizes the outsourcing and in-sourcing choices and identifies which suppliers need to be treated as business partners rather than transactional suppliers
  9. Locations Footprint: displays the geographic locations or building layouts showing where work is done, why it is done in that location and what assets are needed to support the work
  10. Management Calendar: displays the annual (or periodic) rhythm of strategic planning, budgeting, target setting, business reviews, people reviews, continuous improvement processes and other systems that run the organization.
  11. Scorecard: displays the tool that managers will use to assess progress. Typically includes vision, mission and values statements, a list of projects and a list of KPIs with red, orange and green lights against each item.  (see comments – Peter points out that “projects” are an optional part of the scorecard)

What do you think?  Any thoughtful comments will be rewarded with “contributing author” status in my book (three contributing authors so far!).

Posted in Design tools, Operating Model Canvas, Operating model visuals | Tagged , , , , , , , , , , , | 26 Comments

From strategy to success: the role of operating models

I was looking at the Wilson Perumal website today.  This consulting company has some useful blogs … and thirteen on operating models.   I particularly liked one titled “Are you overlooking an essential part of your strategy”

The article states “When most people think of strategy, or the allocation of scarce resources, they focus on the external strategy—which customers to serve in what markets with what portfolio of products at what price points and with what supporting service levels. However, equally important, but often overlooked, is a company’s internal strategy or Operating Model—the coordinated collection of business & production capabilities, organization structure, assets, people, technology, partnerships and governance used to effectively deliver the market strategy.”

The article then includes an exhibit showing the role of an operating model in the journey from strategy to excellent outcomes.


This exhibit got me thinking.  Is operational excellence all you need to turn “Sound Strategy” (a good market strategy and a good operating model) into “Leading performance”.    My conclusion is no.

My reasoning is as follows.  When you have a new strategy, you need to develop a new target operating model to deliver the strategy.   I agree that both of these are needed for a “Sound Strategy”.  I also agree that too little attention is given to the target operating model in most strategy processes.   But even with a “Sound Strategy” you still only have a set of ideas and plans on paper.  To create the target operating model, you need a transformation process, consisting of a set of projects that will convert your current operating model to the target.

Once you have implemented the new target design, you have not yet implemented the strategy.  All you have done is set the organisation up so that it has the structure and capabilities and processes and …. that it needs to implement the strategy.  You still need to run the organisation well (“Operational Excellence”) to deliver the strategy.

In other words,  I don’t think Wilson Perumal have got this quite right.  My equations would be

Market Strategy + Target Operating Model = Sound Strategy

Sound Strategy + Excellent Transformation = Sound Organisation

Sound Organisation + Operational Excellence = Excellent Performance

What do you think?  Please comment.



Posted in change, Design Elements, operating model, Strategy, Uncategorized | Tagged , , , , | 7 Comments

When to do organisation design in operating model work

I was discussing my last post about capability maps with David Winders and we got into a discussion about the timing of work o organisation structure.  David was explaining that one of the benefits of capability maps is that it keeps the analysis and discussion away from organisational structure.   This makes it possible to engage all the senior people in the work without the inevitable posturing for power.

I pointed out that good value chain maps do the same job.  They focus people’s attention on the work that needs to be done not the organisational units who will do the work.

But, David then said that he likes to leave work on organisational structure to last in his operating model projects, whereas I like to do this thinking straight after value chain thinking.  So my model POLIST (son of PILOS) – has Processes first and Organisation second.   Interestingly, David’s model CCPPOLDAT (Customer, Channel, Product, Process, Organisation, Location, Data, Application, Technology) also has organisation after process.  But, in practice, he likes to leave work on organisation as late as possible to allow as much engagement as possible.

I am sharing this because I have not thought deeply about the order in which I do things.  Hence David’s comments caused me to stand back and wonder whether he is right.   I recognise the politics that surface as soon as you start talking about organisation.  But I have usually found that my organisation modelling tool and the 9 tests of good design are powerful enough to cut through the politics.  Also, “I” in POLIST, standing for IT and other Links, cannot be addressed fully without knowing what the organisation structure is: after all the links that need to be addressed are those that cut across the organisation structure.  So, the value of doing structure early is that these linkage issues are exposed early.

However, I could do work on Location and Suppliers and People Model (a part of organisation) and some IT issues before focusing on structure.  So I am interesting in trying this out.

Posted in Uncategorized | 3 Comments

Capability Maps vs Process Maps: Horses for courses

Those who have been following this blog will know that I have devoted four or five entries to the issue of capability maps. Mainly because I have not seen the need for them and because they can obscure the core operating processes and give too much prominence to the support processes.

So I thought I would share an excellent comment on this topic from David Winders. In 2009, he wrote an article “Capability Frameworks”  from which I have stolen some choice paragraphs and added some of my own text and edits. In other words the text in inverted commas is 85% David and 15% me. Apologies David, if I have inadvertently subverted your meaning, but I thought you were making some great points with two excellent examples (one of course is now no longer topical!)

“In nearly every encounter with fellow business architects the subject of capability frameworks seems to come up in discussion. In nearly every case, people are trying to establish their understanding of this approach and seeking to get further information or comfort from discussion with an outsider who might have the answer.

I have concluded that we need to recognise the differences between capability frameworks and process architectures and understand where they add value and where they don’t. We need to perhaps use more concise language that is business-focused and be aware that different disciplines use conflicting terms like “business services” creating unnecessary confusion. I would suggest that “business building block” is better than the ambiguous term “capability” to describe a portion of the business that delivers something, but with reference to the capability in the name of the building block.

Capabilities focus on outputs whilst processes are concerned with actions. In financial services a high-level process architecture often looks nigh on identical to a high-level capability model. Hence, in a process dominant sector like financial services, people look at capability models and say “what is the point?” Apart from a slightly different naming convention – process is verb-followed-by-noun (Make Payments) whilst capability is often noun-followed-by-verb, (Payment Making) – there is little difference between the two.

A possible reason for the convergence of process and capability models maybe due to reluctance to define capabilities. If you ask people in an organisation steeped in delivery, particularly in a high volume processing area, they are often more focused on what their department does day to day than what the department delivers to a customer. If you ask what the capabilities are, you universally will get a list of processes. It is quite difficult to ask people to forget how they do things, and think about what the deliverables are instead, and what the outputs mean to customers or the rest of the organisation’s value chain.

Military enterprise architectures MODAF/DODAF do give special focus to capability frameworks, as the military is more interested in what it can achieve than in designing repeatable activities in the form of processes; from an architecture perspective the capability of a platoon or a gun is more important than how it is deployed in the process of executing a particular battle (the process view).

A topical subject at the moment (2009) is the 65th anniversary of the allied DDay landings in Normandy, where the capabilities of “Fuel Supply” and “Stores and Provisions Supply” were provided through the technologies of pipeline under the ocean (PLUTO) and floating harbours (Mulberry Harbour). There was a process content in these “Overlord” capabilities: they were part of the DDay process.  But military people doing architecture work are interested in their capabilities to support and maintain mechanized divisions in the field of combat (for example gallons per day or tons per hour).

Like so many things, there is a danger that we get too intellectual about the techniques, tools and language we use. There are situations where the capability language and focus will be most helpful, and others where the process language is likely to be more useful. The only real guide is that it must be appropriate for the audience that receives it. It may well be academically interesting for us in business architecture to have these debates but what value does this add to the business that pays the bills?”

So maybe I should stop my agonising about capability maps?   But, there is some value in discussing tools.  If we use the best tools, we are likely to do good work.  David’s point is that it is horses for courses.   Tools should be chosen to suit the situation.

Posted in Capabilities, Design tools, Enterprise architects, Processes | Tagged , , , , , , , , | 16 Comments

Peter Murchland on Operating Models

I have just come across an article Peter Murchland wrote on LinkedIn giving his definition of an operating model.    I have copied chunks of his text because he provides a different perspective to my PILOS model (which is about to become POLIST!).  Peter takes more of a systems perspective and emphasizes elements like “resource management” and “development management” that I give little time to.   As you will see “operations management” is only one of four systems in Peter’s model, whereas I focus on operations management and treat the other systems as secondary issues.

As I have explained before, there is real value in exploring other people’s frameworks, because it helps make you less confident in your own framework and hence less likely to stick to it when circumstances call for something different.


The primary purpose of an operating model is to express the means by which an organisation:

  • pursues its enterprise
  • realises its goals and aspirations
  • achieves and sustains viable operation

Enterprise system

There are four key systems forming the expression of any enterprise-as-system that I consider:

  1. Operations management system
  2. Resource management system
  3. Governance and management system
  4. Development management system

For many years, I have only addressed systems 1 to 3.  Typically, I have not addressed the development management system, because:

  • I was usually part of this system
  • the development management system was usually embedded in the other systems

However, with the increasing degree of change, I am finding that more enterprises are recognising the development management system as a distinct system. This can be seen in John Kotter’s article – Accelerate! – where he outlines the case for a dual operating system.  It can also be seen in the increasing profile of Program Management in enterprises and in enterprises where they have established a Chief Operating Officer and a Chief Change Officer.

Operations system

This system is the core system which produces the products and/or services of the enterprise.  It is most commonly represented as a value stream, reflecting the core capabilities by which the enterprise transforms inputs into outputs and delivers value to its customers and consumers.

This system may also include support systems which are not part of the primary value stream.  These may be systems which require specialist capabilities and are required by different systems in the value stream and deliver internal products and services beyond those provided as part of resource management.

Resource management system

This system manages each of the resource types required for successful operation of the enterprise.  At a minimum, this will encompass:

  • Human resource management
  • Financial management
  • Information management

It may also include:

  • IT management
  • Asset management
  • Procurement, contract and materials management
  • Record management

Governance system

All enterprises require governance and management.

With respect to governance, I have drawn on the Tricker Model which is one of the models covered within the Company Directors Course run by the Australian Institute of Company Directors.  By drawing on this model, I know that there are many Directors and Boards who will be familiar with the model and therefore comfortable with the subsystems that I include:

  • Accountability and reporting
  • Strategy
  • Policy
  • Performance reporting
  • Strategic risk management

To date, I have not modeled the management system.  It seems to be adequately covered by the management embedded in each of the systems that I consider. I have included reference in this area – governance and management – to allow for inclusion of additional capabilities that become evident and require attention beyond those evident in all other areas.

Development system

This system supports the development of an enterprise and effects change in any of the systems.  Change may derive from strategy, as the means by which strategy is executed, or from individual systems as part of continuous improvement.  It includes:

  • Architecture management
  • Program management
  • Project management
  • Change management
  • Program and project support

I view change through a lifecycle lens taking change from idea to realisation. Key steps include:

  • Initiative formation
  • Investigation
  • Acquisition
  • Design, build and test
  • Implement
  • Review and close”

So what is my (Andrew Campbell’s) reaction to this “system view” of an operating model.   First, of course an operating model is a system, so aren’t all frameworks “system views”?  I was brought up on the 7S framework, which I think of as a “system view”.

Second,  I prefer to deal with the development system as an after thought.  It is hard enough designing a good operating system, let alone designing an operating system that is simultaneously evolving to something different.  I agree that organisations need the ability to redesign themselves, but, in practice this happens through transformation projects rather than through a development system (I write these words timidly because I am not very confident I am right).

Third,  I don’t find the idea of a resource management system very helpful.   Each step in the value chain will have resources and will need to manage them to execute its work.  So I see resource management as part of operations.   Also, Peter comments that the operating system can include support systems.   I consider HR and Finance and IT as support functions that run support systems rather than as resource managers.  I know that quite a few frameworks distinguish resources from processes or organisation, but I am not sure this is helpful.

Third, Governance is a topic that I subsume under “organisation”.  Interstingly, Peter does not place decision authorities under governance (in fact he does not seem to have a place for decisions authorities), which for me is the core of governance.  On the issue of performance management, I have found it necessary to add “Management Rhythm” to cover the planning, decision making and performance management processes used to run the organisation … which clearly has an overlap with governance.   But also has an overlap with the project management element of Peter’s “Development management system”.

Conclusion:  There are lots of ways of slicing the cake.  As long as you are aware of two or three ways in which people like Peter and me slice the cake, you should feel confident slicing it your own way because you are unlikely to miss out anything important.


Posted in Design Elements, operating model, What to design | Tagged , , , , | 4 Comments

What is functional alignment in an operating model

I have cut and pasted below a bit of an interview by Martha Heller of CIO with Jim BuBois, CIO Microsoft.  I hope I am not transgressing copyright!   But what Jim says is such a good example of IT being fully linked into the business operating model I could not miss the opportunity of adding to my blog.  Apologies for edits and comments.

“Martha Heller: How has your IT operating model changed during the last five years?

Jim DuBois: We used to think in terms of projects and applications, and now we think in terms of service offerings. Each service offering represents all of the technology investments that support an end-to-end business process, like lead generation or customer support. Conversations about IT used to be disconnected from conversations about our business. Now, we are able to talk about which investments will improve our service offerings.

Take marketing, [for example]. Marketing manages a lot of activities that generate demand for our products. Whether they are campaigns, events, or different ways to engage with customers, we can track those activities to learn which drive legitimate sales opportunities. All of the investments we make in marketing automation should, in some way, increase the volume or quality of (our marketing) leads.

We no longer ask, “How available is a particular application?” or “Was the project on time?” Now we measure, “Did we add capabilities that made the service offering better?” (Meaning, I think, did we add capabilities that made our marketing more effective?)

Heller: Moving from traditional IT to a service offering model requires a major mindset shift in IT. How did you make that happen?

DuBois: Historically, IT did what the business wanted (it) to do. But with analytics tools, and especially with big data, IT now sees end-to-end across the company more cleanly than most departments, so we are able to say, “I understand that you want to make this technology investment to make a process better, but this investment actually won’t help because of bottlenecks that are happening elsewhere in the company.” (Great example of IT seeing the whole operating model and help identify where investment will make a difference, rather than just serving its different functional customers.)

Because IT can see so much, it is our responsibility to influence investment priorities, not just execute on priorities set by our internal business partners. We used to reward IT employees based on whether they delivered a project on time and whether the business was happy with what IT did. But we found that making business partners happy did not always mean that we were doing the right thing at the company level (meaning the right thing at the level of the company’s overall operating model).

Back to the marketing example, my team now gets measured on whether they increased the volume and the quality of leads, not on whether they delivered what marketing asked them to do. That has been a real cultural change.”

These comments by DuBois provide a perfect illustration of the benefit of having an operating model that is shared by all the functions.  IT can then help decide what is most likely to improve the overall operating model.  HR and Finance can do the same.  Rather than each function working in its silo, responding to others so that it meets its own internal performance metrics.  All functions should be working off the same set of operating metrics for the overall operating model and trying to figure out what they can contribute to achieve these higher level metrics.

So IT should be thinking about what we can do to help generate more and better quality sales leads – maybe a new application for marketing, maybe a better link between sales and marketing or maybe a better way of measuring quality of sales lead or …   But HR should also be thinking about how to help generate more and better quality sales leads – maybe better training for marketing staff, maybe enabling career moves from sales to marketing and back, maybe changes to the recruitment processes for marketing staff or …   And Finance should also be thinking about how to help generate more and better quality sales leads – maybe supporting an increase in the budget of the marketing function, maybe changing the comparative benchmarks used to assess marketing effectiveness,  maybe providing marketing with more analytical support or …

If all functions understand the process for developing sales leads and its importance in the overall operating model, they can focus on their role in helping make this process effective …. then you really have a shared operating model and the sort of functional alignment that is missing in most organizations.

Posted in Alignment, Capabilities, operating model, Processes | Tagged , , , , , | Leave a comment