Lean6Sigma and operating models

I was stimulated by a LinkedIn discussion about how to ensure the customer is part of thinking about waste.  The answer of course is obvious – the customer is at the heart of all judgments about waste.  If an activity does not contribute to the value proposition that the customer is receiving, it is waste.  If the activity costs more than the benefit that the customer gets it is waste.

This then caused me to reflect on how to make some of these judgments especially in situations where the customer does not pay for the service being provided: a common situation between internal functions or in public sector activities and charities.  Here all of the tools of marketing and product development and service design need to be brought to bear: focus groups, indifference curves, observation, surveys, enthnography, etc.  Which is one of the reasons for the Lean guidance “Go to Gemba”.

I then began to consider what factors other than judgments about “customer value” and “cost” should influence judgments about waste – and where “strategy” comes into the equation.

Strategy defines who the target customer is and what needs of these customers are being addressed and what needs are not being addressed.  If Lean work is done without defining in advance who the customer (or beneficiary) is and which of these peoples’ (or organisations’) many needs are being addressed, it is easy for the work to lose direction.

But I also realized that there is another constraint on judgments about waste – the operating model.  Whether you consider the operating model to be part of strategy or not, it is still something that needs to be decided before work on lean process design begins.   The operating model is the collection of processes, types of people, organisation structures, IT systems, locations, suppliers and management systems chosen as the best means of delivering the value proposition.   When “leaning” each process, black belt experts need to consider how that process fits into the larger operating model and avoid eliminating activities that may not deliver to the customer of the process, but may be important to the integrity of the larger operating model.

In practice, this is achieved by recording the “stakeholders” of the process – not just the customer; and recognising that the process must deliver value to all of its stakeholders.  As a result, an activity in the process may be necessary even though it does not deliver value to the “customer”: it may be delivering value to another stakeholder.

A simple example is the annual report that companies produce.  This adds no value to customers – but is required by law, and adds value to shareholders and debt holders and those who make contracts with the company.

Posted in Lean, Op Excellence and Op Model, stakeholders | Tagged , , , , , , | Leave a comment

People Models

One of the problems I have been working on is a way of thinking about people models.  I have had two stimuli.  First my son worked for Mark Warner (the holiday company) one summer and I was amazed to learn that he was paid almost nothing (€50 per week) and that his minimum wage was made up with the cost of his accommodation and benefits, such as use of facilities.  Yet there were three people applying for every job and he loved his experience working with Mark Warner:  he also did a winter season with them.   This seemed to me to be an interesting people model. 

My second stimulus was that operating model work is about making choices.  So I began to lay out the choices that are made for different people models.  Choices about the sort of people to be hire – skilled or unskilled, motivated by money or by meaning, etc.  Also choices about the offer to these people – full time or part time work, above average or below average pay, etc. 

This thinking evolved into a four column format for laying out a people model.  I have since thought that maybe it should be a two column model.  But here is the four column version.


Lets start with the first column: the type of people that you want to hire into the skill group.  Each item involves making a choice.  “Contract” is about the type of contract that these people want.  “Location” is about where the people live.  The next exhibit shows the choices made by McDonald’s for staff in restaurants and Eden McCallum for consultants. 


There are different ways of laying out these choices.  The above is a crude Powerpoint with a misspelling of McDonald’s!   But the next visual shows a more attractive display of a skill group with three roles in it. 


A similar analysis and series of choices can be made for the “value proposition” to the people you have decided you would like to attract. 


And for the column “career path”


The last column on “culture” is more difficult to boil down into a few choice areas.   This of course is also true of the first three columns.  There are many choices that are not represented.  But the cultural values column is particularly difficult to illustrate in terms of simple choices.  So instead, I attach my summary of the people model for Mark Warner (my views not an official Mark Warner document!).


In developing this tool, I also realised that it makes little sense to create a people model for a company.  People models need to be created for important skill groups within a company.  yes a company may have an overall employer brand.  But it will not have only one people model.


Posted in People model | 3 Comments

Organisation charts as organisation models

Posted in Organisation model | Leave a comment

Value chains, IT4IT and reference models

I have recently had a most rewarding exchange with Mark Smalley, who is part of a group working on IT4IT (this includes an information architecture to help IT tools interact with each other and a reference model – “an IT value chain” – that will help leaders of IT functions create their IT operating models).  Of course, once my book on operating models – Operating Model Canvas – is available in March, IT leaders can use it instead!

The issue we were debating is whether a reference model should have one value chain or many (and if many – how many).  The IT4IT reference model only has one value chain – Strategy to portfolio (plan), Requirement to deploy (build), Request to fulfill (deliver), Detect to correct (run) – all aimed at one value proposition “efficiency and agility”.


Mark was explaining that this is a useful starting point for any IT team, who will then need to develop this value chain or define additional value chains as they work on their operating model.  I was expressing discomfort because I feel that a reference model for IT should show the model of a typical IT function, not a generic model that could be applied to any function that builds and runs solutions for organizational needs.  I suggested that the IT4IT reference model should have different value chains for the different categories of service that an IT function provides – ERP related, desk top related, communications related, etc.

This led Mark to ask a very difficult question.  If you go beyond one value chain, how do you know when to stop?  Do you create a separate value chain for every application?  “Revisiting your concern about IT4IT not distinguishing between IT’s different services, it seems a bit like saying that a publisher’s process model doesn’t distinguish between its different publications. Or Zara and its products. While the services and products differ, surely the process / value chain is more or less the same?”

Here is my response (with a few edits and improvements) – comments welcome.

“I also understand the point you make about Zara or a publisher.   But, it is here that my strategy knowledge is helpful.

If you take Ashridge Business School, there are multiple levels at which you can think about value chains

Highest level – market segment – open courses, tailored courses, qualifications courses, weddings, conferences, etc
Middle level – type of course – for example within open courses there are finance courses, strategy courses, marketing courses, etc
Lower level – type of session – for example within a course, there are sessions on different topics given by different lecturers

We could do value chains for all of these levels, or we could try to do just one value chain for the whole of Ashridge.  At the lowest level we would probably have over 1000 value chains.   So the issue is how do we decide what level is useful for helping translate strategy into operating model design?

The answer lies in the degree to which value chain activities need to be combined or kept separate organisationally for the purposes of delivering the value.  This in turn depends on the economies of scale from combining activities across value chains and the degree to which the value propositions for different services differ. We can easily see that you would not want the same people designing a wedding as designing a finance course.  We would probably not even want the same people doing the admin for both.  But we could probably have the same waiters for both.  In other areas, there are plenty of opportunities to combine without loss of unique value proposition: it will be OK to use the same marketing, admin staff and class room and even some lecturers on a finance course and an economics course.

With a knowledge of business schools, if I was doing a reference model for business schools, then I would distinguish between the value chains for executive open, executive tailored, MBA, undergraduate, conferences and community events.  Conveniently this is six value chains: a manageable number.  In my experience, it is usually helpful to start with a small number (but often more than one).  Why these six, because there is enough difference in the value propositions to cause large parts of the value chains to need to be kept organizationally separate (and the economies of scale are not large enough to demand combination).   I observe that one of the problems that many business schools have is a failure to distinguish organizationally between executive open and executive tailored, and I presume that this is because they have not done separate value chains for each and so do not fully understand the different skills involved.

As you can see the judgments I am making depend on a good deal of strategic knowledge about the differences between different value propositions, the skills required and the likely size of the benefits from economies of scale.  Unfortunately, I don’t think there is a way round this, and, as a strategist, I feel that trying to get round this will cause loss of connection with the business.

This is my point about a reference model for IT.  There is enough difference in the value propositions between, for example, ERP related, desk top related and communications related (and no dominating economies of scale) that these value chains should be  considered separately when translating IT strategy into an IT operating model (ITOM).  Not all IT teams will decide to keep them separate.  But many will, and it is important that the team thinks long and hard about whether to do so or not. The IT4IT reference model does not help them to do this.  In fact it infers that creating separate organizational units within IT to pursue separate value chains is probably not the right answer.”

Mark was gracious enough to respond: “Point taken Andrew, and I think that I’ll modify my ITOM presentation to accommodate this aspect. Thanks. I’ll also share it with the IT4IT forum”.

There is a lesson from this exchange that is relevant for any operating model.  Start by thinking about the customer segments and the value propositions.   Then develop value chains for each value proposition that you consider may be different enough to warrant some separation of delivery capabilities from the other value propositions. (But keep to a handful of value chains, at least to start with, because otherwise you will be come overwhelmed.) Only then think about what activities along the value chain to combine across value chains.  If it is obvious that all of the activities should be combined across the value chains you have defined because there are economies of scale and little difference in value proposition elements, then you are working at too low a level of detail.

What do you think?

Posted in Enterprise architects and operating models, Value chain, Value proposition | Tagged , , , , , , , , , | 3 Comments

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 Design steps, Getting a brief from the client | 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 | 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 Design steps, Strategy | Tagged , , , , | 7 Comments