The role of operations in strategy

I recently enjoyed an article by Kevin Laczkowski and colleagues at McKinsey titled “Seeing your way to better strategy”.  It argued for four lenses to help you “see your way” forward – Financial, Market, Competitor and Operating Model. The thought behind these lenses is that, by doing some focused thinking around each lens, you will develop better strategy.

I recently enjoyed an article by Kevin Laczkowski and colleagues at McKinsey titled “Seeing your way to better strategy“. It argued for four lenses to help you “see your way” forward – Financial, Market, Competitor and Operating Model. The thought behind these lenses is that, by doing some focused thinking around each lens, you will develop better strategy.

While this is not the first of these kinds of articles (see David Collis’s “Can you say what your strategy is?”), it is the first one to include “operating model” as one of the perspectives.  Unfortunately, in the article, the operating model perspective is allocated little more than a paragraph, and, in my opinion, says little of note.  So, I thought I would improve on it. 

First let me summarize the other three lenses.  The financial lens is about using financial analysis to understand if the strategy is ambitious enough: will it justify the current share price, will it deliver top quintile performance compared to peers, will it outperform the do-nothing-new option? Can we afford it?

The market lens is about granular analysis of where growth and profits are now and will be in the future: which segments, which countries, which channels, which adjacencies?  Is the strategy exploiting these trends with an appropriate balance between reliable profits and more risky opportunities?

The competitor lens is about advantage. What gives advantage in each market and how well placed is our company? Will the strategy deliver improvements in our advantage? How much change will be needed for us to gain sustainable advantage in each of the markets we are targeting?

The operating model lens is about implementation.  Has the organization committed sufficient resources and capabilities given the strategy’s challenges?  And also, is the organization designed in a way that will accommodate the new activities or new capabilities required by the strategy?

So, let me explore this lens in a little more depth.  For most companies, the current operating model acts as a constraint on strategy.  New opportunities typically require new capabilities, which in turn depend on a new operating model.  It is only once the new capabilities have been developed – the operating model has been transformed – is it possible to use the new capabilities to exploit the new opportunities. Often, the transformation is not achieved or not even planned and the operating model fails to deliver the new strategy.

The operating model lens encourages strategists to think about the transformation that may be required, whether it is realistic and, if so, whether sufficient planning and resources have been or will be allocated. 

How does a strategist make this assessment?  First, the strategist needs to understand the current operating model and the value propositions it is capable of delivering.  The Operating Model Canvas is an excellent tool for doing this (see

The strategist can lay out, on one page, the current value propositions and the processes, people, information systems, locations, suppliers, management meetings and scorecards that enable the organisation to deliver these value propositions.  If the strategy involves either delivering some new value propositions or delivering similar propositions to new market segments (as most strategies do), the strategist can assess how much transformation is needed: whether new processes, people, information systems, locations, supplier relationships, management meetings or scorecards will be needed and how much the existing ones will have to change. 

Using the Operating Model Canvas, the strategist can assess the size of the transformation required and the likelihood that the needed changes will be made successfully. If the likelihood of successful transformation is low, a wise strategist will want to reconsider the strategy or ensure that the leadership team have the commitment and the resources that will improve the odds.

The Operating Model Canvas is a high-level tool.  In places where more detail is required, the Canvas is supported by further tooling:

The operating model lens is asking whether the organization has or is likely to be able to put in place the people, structure, information capabilities, supplier relationships and management systems that will enable it to successfully implement the strategy?  In my experience, successful strategies are not primarily about finding exciting new business opportunities.  Successful strategies are about matching opportunities with capabilities, and ensuring that the result leads to an advantage over competitors.  This means understanding the current operating model well, understanding what changes are realistic and understanding the competitor benchmark that must be exceeded. 

Posted in Uncategorized | 1 Comment

Comparing McKinsey’s procurement framework with the Operating Model Canvas

I have been reading a McKinsey article on procurement, titled “A next generation operating model for source-to-pay”, authored by Samir Khushalani and Edward Woodcock

At the centre of the article is a “honeycomb” framework (see exhibit). 

So I thought I would try to link this framework with the Operating Model Canvas (see exhibit).

The value capture and value sustainment parts of the McKinsey framework seem to address the Processes or Value Delivery Chain middle arrow of the Canvas:  

  • Translate business strategy into procurement strategy working with colleagues from outside the function to ensure alignment
  • Manage categories both by managing the suppliers and by influencing colleagues
  • Contract with suppliers based on the category strategy, McKinsey’s “Source to Contract” step
  • Place and expedite purchase orders with suppliers and receive and qualify goods (or enable colleagues to do so). This is McKinsey’s “Procure to Invoice” step
  • Process and pay invoices, McKinsey’s “Invoice to Pay” step
  • Manage supplier relationships

Because the function is Procurement, the Supplier box in the Canvas becomes incorporated into the value chain: much of the value chain is about choosing suppliers, developing contracts with suppliers and managing relationships. 

The McKinsey honeycomb’s outer ring broadly aligns with the other elements of the Operating Model Canvas:

  • The Suppliers box in the Canvas has already been covered in the value chain
  • The Organisation box is covered by “Organisation” and “Capabilities and Culture”
  • The Information box is covered by “Data & Analytics” and, to some degree, “Digital”
  • The Management System box is covered by “Governance”

This leaves three issues for discussion.  The “Processes” element of the McKinsey framework is one of these. The article explains “In a next-generation operating model, processes are not only harmonized across business units and geographical regions but also employ category-specific solutions that streamline approval processes for the user journeys associated with a particular channel and category.”  In other words, McKinsey’s “Processes” element appears to be about “value chain mapping” drawing value chains for each category. This tool helps organization designers decide what parts of the value chain should report to categories, and hence potentially be different for different categories, and what parts should report to central functions within Procurement. For example, the first step – “procurement strategy” – could report centrally and the last step – “manage supplier relationships” – could report to the category managers. “Invoice to Pay” would typically report centrally, but there might be category specific elements in the process.  “Manage categories” would report to the category manager, and might be very different for different categories. 

The second issue concerns the Locations box in the Canvas.  It does not seem to be represented in the McKinsey framework.  This is surprising.  Location of staff is an important issue in designing the operating model of the procurement function. It is important to decide which staff should be located near suppliers, which staff located near other internal functions and which staff need to be collocated to smooth collaboration within the function.

The third issue concerns “Digital” in the McKinsey framework.  As the article states, “Advanced procurement organizations are increasingly making use of automation technologies to eliminate unnecessary manual work from transactional processes. Digital approaches can also enhance user experiences by making access to procurement services easier and more intuitive.” Does the Operating Model Canvas need another box for Digital?

My answer is no, for the same reason that the Operating Model Canvas did not include a box for technology.   The middle arrow in the Canvas is about the work steps and the machinery and technology needed to execute these work steps.  The Information box is about the information systems needed to support these work steps (and the management system).  Digitization is muddying this distinction. Digitization means that a number of work steps will be done by computers. The temptation is then to see these steps as being part of the Information box rather than the middle arrow. The same confusion is happening inside organizations wrestling with whether digitization should be led by the IT function or by a separate team.  What is important is that all operating model designers recognize that there are two very different tasks – digitizing the work steps and providing information systems.  Because some of the skills sets are similar and the need for collaboration between the two tasks is high, many have chosen to have both tasks led by the IT function.

So where have we got to?  First, McKinsey’s honeycomb framework is very similar to the Operating Model Canvas, although it may overlook the locations issue. 

Second, while the article claims to describe “A next generation operating model” for Procurement, in fact it just raises some issues that operating model designers should consider when designing future operating models.  It provides a value chain and makes some interesting observations about what activities in the value chain will need to change in the future and how priorities might be redistributed.  It emphasizes the influence digital will have on these value chains and suggests that “category specific” value chains may also be part of the future.

But the article does not provide an organization structure or suggest what sort of information support is needed or how to resolve the locations issues or how to define those suppliers that need to be managed through collaborative agreements or what type of management calendar or scorecard is suitable for running the next generation procurement function.  If McKinsey was using the Operating Model Canvas as its framework for operating model work, all of the above questions would have been top of mind and the authors might have more fully delivered on the article’s promise.

Third, the honeycomb framework attempts to address the issue of value creation, distinguising between “enabling”, “capturing” and “sustaining”. I have been wrestling with how to link value to operating models for my course Designing Operating Models. It is easy when working on an operating model for a business because revenues can be offset against costs, and , as with lean analysis, “waste” or “lack of value” is any cost that does not deliver more than its weight in “value”. However, retaining a focus on “value” when doing an operating model for a function like Procurement is harder. McKinsey’s ideas have got me thinking … which will hopefully lead to a future blog.

Posted in Operating Model Canvas, Procurement operating model | Tagged , | 2 Comments

How to identify use-cases for new technology

James McGovern asked an interesting question on LinkedIn: “What Methodology Should BA Use to Determine Applicable Blockchain Use Cases For Their Organization?”  In this sentence, BA means Business Architecture rather than British Airways!  It got me thinking – what methodology should operating model analysts use to determine what technology is used to execute any work in the organization.

My first reaction was that this is not a question that is addressed in operating model work.  When doing an operating model design for a restaurant, we do not decide what type of cooker is used by the chef or what type of lighting is used in the restaurant entrance.  These are level three or four decisions (level 1 being design principles and level 2 being a high-level operating model design).  But, I then began to think some more.

Operating model work involves deciding what sort of people you need to do the work, what sort of information support the work needs, where the work will be done, what external suppliers or partners are needed and how the work will be governed.  The answers to all of these questions depend at least in part on the technology that is used.  If an accounting ledger is kept in a large book with each entry hand written, you need different people, different IT support, different suppliers and different governance processes than if the ledger is held on a blockchain. In other words, once you have defined the work that needs to be done – the value chain needed to deliver a particular value proposition – you also need to decide, in broad terms, the technology that will be used to do the work in order to be able to address all the other operating model questions.

You may not need to decide what type of cooker the chef uses, but, if the cooking only involves microwave ovens, you will need a different kind of chef and different suppliers, than if the cooking involves Cordon Blue cuisine.  To give one more example, if you are designing an organization to make holes, you need to know whether the technology you will use is picks and shovels, a mechanical digger, a drill or dynamite before you can design an operating model.

This raises the question of whether this “high-level” technology choice should be part of strategy or part of operating model design.  Should the operating model designer say, “I know you want to make a hole, but until you tell me what technology you want to use, I can’t design an operating model for you”; or should the designer say “I know you want to make a hole, tell me a bit more about the type of hole you want and I will tell you what technology is most suitable and give you an operating model design as well”.  Personally, I think the latter is more practical, if only because, in operating model work, it is hard enough getting the client to give a clear articulation of the strategy, let alone getting clarity about technologies. 

Putting my academic hat on, though, I think the answer to the riddle is dependent on whether the technology choice is a source of advantage/excellence or not.  If it is, then it should be defined in the strategy.  If not, it can be left to the operating model designer.

So we come back to James’s question “what methodology should operating model designers use to choose technologies for doing the work?”  The answer, as with most operating model design, is to ask those who know.  Find an expert at “making holes of this kind” and ask him or her what is the best technology, what kind of people are needed to use this technology, etc.  When a new technology comes along, like blockchain, ask someone who understands the technology to explain what the technology is good at doing, and then consider each “work step” to assess whether the technology is likely to significantly improve the cost or quality or speed or … of the work step.

Posted in Technology and operating models, Uncategorized | Tagged , , , | Leave a comment

Comparing Agile and Cross-functional Teams

I was reading a McKinsey interview with the head of the Rijksmuseum on the subject of Agile. For some time now, since a conference I ran in July on Agile and New Forms of Organisation, I have been trying to get clear in my mind what the difference is between “agile organisation” and “cross-functional teams”. This interview helped me clarify a couple of points. Cross-functional teams have been a feature of organisation since the 1960s, when Boeing first developed a new aeroplane using a multi-functional approach.  This successful experience was documented by Jay Galbraith, who called it a “matrix structure”.  It was one of the first documented uses of matrix organisation ideas: in Boeing’s case a function/project matrix. So what is new/different about Agile compared to cross-functional teams?   Here is my list
  1. Agile team members are allocated to the agile team full time.  Many cross-functional project teams are part time.  Of course, many, like the Boeing example, are also full time (at least for a number of years).  Just to confuse us all, some people call teams with part-time members “agile” teams.
  2. Agile requires a fully defined mission for the team.  It also gives freedom for the team to “self-manage” in delivering the mission.  Project teams will typically have objectives, but often not as much care is taken in defining the mission of the team, and less commitment is given to ensuring the team has freedom to work in whatever way they like.
  3. Agile typically requires co-location of the team.  Cross-functional, project-team members often remain located in their function but come together for joint activities.  Co-location is believed to be an important part of agile because it produces better communication (essential to self-management), more commitment and more speed.
  4. Agile typically involves using many of the methods of ‘scrum’, like backlogs, sprints, stand up meetings, visible progress displays, etc.  Project teams, at least historically, involved few standard ways of working, and project management typically uses a “waterfall” approach.
  5. An agile team needs a “product owner”, the person in the team who prioritizes the backlog and does other “team-leader like” roles.  A cross-functional project team has a team leader, whose role is typically broader and less well defined.
  6. An agile team is expected to produce intermediate outputs and trial these outputs with the beneficiary/customer it is serving.  The concept of “minimum viable product”, from Lean Start Up thinking is important here.  Agile teams are expected to generate trial outputs quickly and expose them for comment and reaction.  Project teams, more typically work in a “waterfall” approach, only exposing their output towards the end of their work.
  7. An agile team is a permanent part of the organization.  Whereas a cross-functional project team is typically expected to have a limited life, often months not years.  However, many people use “agile” to refer to temporary teams, and because organizations change fairly frequently few agile teams stay the same for more than a year or two.
  8. Organisations with many agile teams (such as Spotify), typically call these teams “squads” and group them into “tribes” to help manage coordination between “squads”.  The functions are called “chapters”.  Organisations with many project teams may have a “project office” to coordinate “multiple workstreams”, as, for example, in post-merger integration projects.
In summary, some cross-functional project teams (those with long time horizons, well defined missions, clear team member roles, scrum working practices, sensitivity to their customers, etc) are very similar to agile teams.  But the typical cross-functional project team has important differences from the strictly applied agile team. This raises the question of what is the same between agile teams and cross-functional project teams.
  1. Both types of team have members drawn from different functional disciplines, and the functional disciplines are still responsible for the capabilities of their people.  This is the matrix element.
  2. Both types of team have defined objectives and are expected to deliver within set time frames.
Both are ways of breaking down the functional silos that stultify organisations.  But “agile” is also associated with speed, customer-orientation and higher levels of motivation and engagement.
Posted in Agile and operating models | Tagged , , , , | 1 Comment

Yet another operating model framework

At the risk of driving you all mad with different frameworks, I recently came across the following from Adrian Pedroi of Turner & Townsend:

What do I like about this?  It incorporates “values, mission and strategy”, which is, of course, the starting point for all operating model work.  It has more of a focus on people than most models.  I particularly like the visuals against this part of the framework, which seem to give extra focus on individuals and on relationships.  Those who have been on my course Advanced Organisation Design will know that my definition of good organisation is “capable people working well together”.   I also like the balance of service, process and people, clearly the three most important ingredients in an operating model.

Where might I criticize?  The framwork separates ‘services’ from strategy, which feels odd to me because I think the decision about what services or products to offer and which customers to serve is the guts of strategy work.  This framework does give emphasis on services (or what the Operating Model Canvas calls “value propositions”).  In other frameworks, this is often presumed rather than explicit.  However, the customer or beneficiary is presumed (I assume part of strategy) rather than explicit.  As I have often commented, a way of keeping the customer front of mind is helpful when doing operating model work.

My other criticism is that the processes bucket is a catch all for a lot of stuff.  This has the advantage of keeping the framework down to three, but the disadvantage of mixing a lot of different stuff together under this bucket.  It also means that location and suppliers are probably given less attention when teams are using this framework.

I have always been a bit uncomfortable with people, process and technology, the classic framework used by Business and Enterprise Architects. I have also criticized the Business Model Canvas categorization of Key Partners, Key Activities and Key Resources.  This Turner & Townsend framework is, in my view stronger than both. Like the BMC it has a focus on services.  But its language and focus on people is much better than the BMC’s unfortunate ‘resources’.  The bundling of process and technology together may not be so mad in an RPA world where most process work is done by technology.

As always there is something to learn from everyone’s frameworks.

Posted in OM frameworks | Tagged , , , | 3 Comments

BCG’s Agile Operating Model Framework

I am always interested in the frameworks used by consultancies because they are working regularly with clients, and, hence, should be learning the most about how to do operating model work.  So I eagerly read a BCG article by Miquel Carrasco, Kyle Peters and Peter Geluk on agile operating models for government.

The article argues that government should adopt agile methods, but without giving any compelling example or anecdotes.  The main point of interest is the framework that they called “BCG’s Agile Operating Model Framework” – see below

My immediate interest was to compare it with the Operating Model Canvas to see if I could learn anything.  First, there are a good many overlaps.  “Processes” is the same although the visual in their processes box does not look much like a process.  “Structure”, “Culture and behaviour” and “Leadership and talent” overlap with “Organisation” in the Canvas. Although the emphasis on leadership is interesting.   “Technological enablers” covers the same ground as “Information” in the OMC.  “Measurement framework” is similar to “Scorecard”.

This leaves “Governance and funding” which appears to overlap partially with “Management Calendar” in the OMC.  But the focus on funding is clearly different.   Thinking about this, funding is a major issue in government as it is in charities.  So special attention on this topic seems sensible.  The link with governance also makes sense because the funding comes from the government.  However, the wording in the article does not throw much light on this category: “Organizations should move to a more flexible, capacity-based funding approach, with regular reevaluation of initiatives to ensure that they are on track and merit continued funding.”

The final box in the BCG framework is “Purpose, strategy and priorities”.  This has some connection to the “Value Proposition” and “Customer” parts of the Canvas.

What is interesting is that “Location” and “Suppliers” are not part of the BCG framework.  Given that one of the core ideas in agile working is the bringing together of cross functional capability into a single location so that they can work closely together, the absence of location in an agile framework feels like an omission.  Furthermore, since agile is about moving fast, government departments are likely to need to work with suppliers who are more used to reacting in a few days rather than a few months.  So some attention to Suppliers would also seem important to designing an agile approach.

As is normal, when comparing frameworks, there is something to learn and something to teach.  BCG’s attention to leadership is worth thinking about.  As the authors point out, in an agile environment, leaders need to be good at articulating purpose and constraints, assembling teams and then giving teams the freedom to act.  Not a natural style in government.  But one that is well articulated by Stephen Bungay in The Art of Action.

More broadly almost every new operating model requires changes in leadership behavior.  So maybe the “Organisation” box in the Operating Model Canvas, should include special attention on the leadership behaviors needed to make the new model work.  Some of this is captured in “Management Calendar”, but more thought about leadership behavior is probably warranted.

BCG’s focus on funding is also worth attention.  In a commercial organization the funding issue is part of the business model, and hence excluded from the operating model thinking.  But in government, the distinction between business model and operating model is less useful.  Hence it may make more sense to blend the two as BCG appears to do.

On the teaching side, BCG might benefit from adding location and suppliers to their framework. They also lack any concept of customer or beneficiary in their framework.  No doubt this is included in their “Purpose, strategy and priorities” space, but, even in government, it is important to keep a focus on who the beneficiary is.

Posted in Agile and operating models, OM frameworks | Tagged , , , , , | Leave a comment

One of the problems with capability maps

Last evening I was with Alan Crawley of Optima Partners (specialists in marketing function transformation) talking about marketing operating models.  A most stimulating discussion.   Parallel to this I have been in a LinkedIn discussion with Peter Murchland about capability maps.  In it we were using marketing as an example, or, as a capability map would call it, “marketing management”.

I started the dialogue with Peter like this “I find a capability such as “marketing management” is a dangerous abstraction because “marketing management of a restaurant” is a very different capability from “marketing management of a toothpaste” which is a different capability from “marketing management of a consulting service”. Yet I have never seen a capability defined with this degree of specificity.

The dialogue then focused on the marketing challenges of Ashridge Business School where we have tailored courses, open courses, qualifications courses, weddings and research outputs such as books and articles.  I was suggesting that these may all be different kinds of marketing capability, but capability mapping does not make it easy to consider these differences because all of these types of marketing would be captured under the term “marketing management”.

Peter commented, “Taking one line of investigation, where I use APQC Process Classification Framework as an indirect path to capabilities (which surround processes), process 3 is Market and Sell Products and Services.

This is composed of:
3.1 Understand markets, customers and capabilities
3.2 Develop market strategy
3.3 Develop sales strategy
3.4 Develop and manage marketing plans
3.5 Develop and manage sales plans

This would indicate that the marketing capability can be considered to comprise three capabilities:
a) Market assessment
b) Market strategy
c) Marketing planning

We could then consider each of these capabilities (and associated processes). For example, market strategy relies upon:
i) Value proposition development
ii) Pricing strategy development
iii) Channel strategy development

(Note: this decomposition does not yet address the differences you have highlighted)”

This response seemed to illustrate the problem of a capability approach rather well.  The issue that seems to me most important in this part of the Ashridge Business School operating model is relegated to a note in brackets at the end of Peter’s analysis.

Peter’s follow on comment tried to address “the differences you have highlighted”.

When I look at the different types of marketing you have nominated, several considerations come to mind:
a) what are you encompassing within “marketing” – the market strategy element or the promotional element – two quite distinct activities
b) there may be distinct differences that emerge in dealing with products versus services
c) the differences may be addressed through the competencies of one individual performing the entire marketing function (in which case it is a moot point and unnecessary level of detail to accommodate in the capability model)”

I quote Peter because I consider him to be a high quality thinker and enterprise architect.  But I can’t help feeling that he is being held back by his capability view of the enterprise.

I shared this feeling.  “Peter, your responses most perfectly illustrate why I am uncomfortable with a capability approach. While you are thinking “marketing capability” or “marketing function” and breaking the capability down into level two and three capabilities. I am thinking, should we consider marketing a tailored course to be the same capability as marketing a wedding or a research paper? I am thinking, do I need five “marketing functions”, one for each line of business, or one function for all of ABS? If I have one marketing function should it be organized into market assessment, market strategy and market planning teams or into tailored, open, qualifications, weddings, and research teams? These questions are all best addressed with a value chain map (rather than a capability map) as the starting point.”

I continued, “I feel that starting from a capability view of the world (one that does not have 1000 different kinds of marketing capability) is a handicap. I feel you are trying to do an operating model for a sport, starting with terms like “ball contact management”. Whereas first you need to know whether you are playing tennis or hockey or rugby, because “ball contact management” is a completely different activity in these three sports.”

I am sure the dialogue will continue – I have had previous interactions with Peter on this topic.  You can follow along here – although you may need Peter to approve your membership of the group.

Posted in Capabilities | Tagged , , , , | 30 Comments

Value Chain Maps

Over the years, I have become convinced that a value chain map is a more powerful and more easily accepted starting point, both in consulting and teaching, for operating model work (compared, for example, to a capability map).  This blog explains what a value chain map is.

A Value Chain Map is a high-level process map or value stream map: the term value chain coming from the strategy literature – Michael Porter.  I prefer the term value chain because it reminds me that we are trying to link operations to strategy.  But any other term is acceptable so long as the tool does the same thing.

To create a Value Chain Map, you first need to identify the different “value propositions” (the products or services) that the organization provides.  Ashridge Business School provides tailored courses for executives, open courses, qualifications courses, research papers and books and even weddings using our beautiful building.  An HR function might provide talent development, recruitment, remuneration and organisation development services.  A factory might produce standard products and specials.

Figuring out the best way of defining the value propositions is not a trivial task (see separate blog). Should I think of Ashridge as offering courses, research papers and weddings, or should I think of Ashridge as offering open courses, tailored courses, qualifications courses, etc, or should I think of Ashridge as offering finance courses, marketing courses, leadership courses, etc, or should I think of Ashridge as offering 1 day courses, 2 day courses, 3 day courses, etc?   The answer should come from the strategy: how does the strategy chunk up Ashridge’s different services into groups/segments/offers and how does this link to the way Ashridge thinks about its customers ?  If the strategy is silent on this issue, it is probably better to work on strategy than on operating models.

Armed with a way of defining the value propositions, lay out the high-level process steps needed to create each value proposition.  So for “tailored courses” the steps (the value chain) would be

  • Market to companies
  • Design courses for prospective clients
  • Agree terms and contract with the client
  • Deliver course
  • Invoice and collect money
  • Follow up with the client

It is helpful to keep the number of different value propositions and the number of steps in each high-level process to less than seven (aggregate if needed).  The reason is that you need to be able to hold the whole Value Chain Map in your head at one time; and a matrix of 36 (6 value propositions with 6 process steps each) is about the maximum you can cope with.  It is always possible to go into more detail later, as needed.

When you have done high-level process steps for each value proposition, you can then create a Value Chain Map.   Draw the process steps as chains of chevrons along the horizontal, placing different chains above or below each other.   Then arrange individual process steps into columns of like capability.  So that, in the Ashridge example, the “design” activity in each chain sits in one column and the “deliver” activity sits in another column, etc (see exhibit 1).

Exhibit 1

Once created, additional information can be added to the value chain map (see exhibit 2).

  1. Identify which chevrons in each chain are critical success factors as opposed to commodity factors for delivering the chain’s value proposition.
  2. Identify in which chevrons the organization currently has difficulties or is under performing. For these problem chevrons, it is often helpful to go to the next level of detail: breaking the chevron down into five or so more detailed chevrons and considering where the problem is at the next level of detail.
  3. Identify how the organization’s costs or headcount divides amongst the chevrons.

Exhibit 2

However, the main benefit of the Value Chain Map is that it provides a visual background for considering organization structure.  The people doing the work in each chevron of the map could report in two ways: along the value chain to someone responsible for ensuring that the total value chain delivers the value proposition; or within a vertical column to someone responsible for a single capability across all the value chains.  So, the people doing course design for open courses at Ashridge, could report to the head of open courses or to the head of course design for all types of courses.

Fortunately, there is a rule of thumb to help you decide which way the people should report.  The rule says that the default reporting line should be along the value chain (the design people for open courses should report to the head of open courses), unless significant improvements can be made to the value proposition by reporting in a different way.  In other words, report along the value chain unless reporting by capability significantly lowers cost or significantly improves the value delivered.

The reason for this rule of thumb is that it is easier to create the value proposition and adjust it to match changing customer preferences, if all of the people doing the work for this value proposition report to one person and are focused only on delivering this value proposition to this customer type.  The rule of thumb means that the onus is on those who want to organize by capability to create a convincing business case.  If in doubt, report along the value chain.

The wonder of the Value Chain Map is that it gives a visual representation on one page, of the core work that needs to be done to deliver the products or services; and it provides the platform for thinking about organization structure.  With a picture of the core work of the organization and how this work should be structured, you are already half way to an operating model.

Posted in Value chain | Tagged , , | 17 Comments

A KPMG framework

As readers of this blog will know, I am always interested in other frameworks (other than the Operating Model Canvas) because it is often possible to learn something or to see the same issues from a new perspective.

So here is a KPMG framework that I extracted from a document on LNG operating models (liquid natural gas).  Unfortunately the resolution of the exhibit is poor, so I will explain.  In the coloured column the top dark blue box says “Financial ambition” and the bottom dark blue box says “Measures and incentives”.  The three slightly lighter shades of blue are bracketed as “Business Model” – Propositions, Markets, Customers and channels.  The four

even lighter blue boxes are bracketed as “Operating model” – Core business processes; Operational and technology infrastructure; Organizational structure, governance and risk controls; People and culture.  The other two columns are “Key questions” and “Accelerators”.

So what?   First there is nothing in this categorization of business model and operating model that is different from Operating Model Canvas.  But a couple of points are worth noting.  First, the term business model is used to refer only to the front end of the Business Model Canvas.  In other frameworks, such as PA Consulting’s framework, this is referred to as “customer model” or “value proposition model”.  Business model includes customer model and operating model. So readers should be aware of the different ways different consultants use the term business model.

Second, in the operating model categories there is one for “Operational and technology infrastructure”.  This combines digital and mechanical machines and applications, which seems odd for LNG companies who have drilling rigs and IT systems. It also makes me think that the Operating Model Canvas lacks a good place for thinking about things like drilling rigs.  When they come up, I typically think of them as part of the “core processes” and also think about them again when considering locations.  But this framework gives them a bit more status.

Third, the KPMG framework has a box for “Organisational structure, governance and risk controls” and a separate box for “Measures and incentives”.  This seems a very odd split.  The question in the next column against measures and incentives is “Do you have the right metrics to incentivize the organization for end-to-end business optimization?” which is a pretty odd question, but makes me feel that this should be part of the organization box.

In the Operating Model Canvas the split is between the design of the organization – structure, people, incentive systems, culture, decision rights, etc – and the management system needed to run the organization – planning, budgeting, targeting, performance management, risk management and continuous improvement – and the scorecard that tells leaders whether they are on track. I think this is a cleaner split.

The word governance, however, has always given me difficulties in this context.  For a project, governance refers to the steering group and the design authority that the project needs to work with.  For an organization it is partly the decision rights and committees, which I think of as part of organization design, but it is also the planning, budgeting and risk processes that I position as part of the management system. So the word governance cuts across different categories in the Operating Model Canvas. As a result, I have started avoiding the word where possible, yet its usage is growing and may be confusing people rather than enlightening them.

Last point, I was intrigued by the other two columns – Key questions and Accelerators.  What is attempted here is to list the key questions for an LNG company in the current market and also the levers that managers might use to accelerate future performance.   I like the idea very much – but I did not feel that this list of questions and accelerators quite delivered.  Either it is too long so not honing in on the real insights or it is not based on good insights.  Questions like the “Are you able to respond to changing demands?” or “How are you monitoring risk and evaluating new risks?” left me flat.  I was equally unmoved by the text in the Accelerators column “5. Unit cost competitiveness.  Challenge complacency and bring insights from downstream business with a relentless focus on asset performance through lower capex and opex as well as maximum possible throughput.”

But I am determined to have a go at this format for a business I know well to see if it can be made to deliver something more dramatically insightful, as I tried to do on pages 144 and 145 of Operating Model Canvas.

Posted in Business model, OM frameworks | Tagged , , , , , , | 1 Comment

Operations Strategy Matrix and Operating Model Canvas

Last week I spoke at an interesting conference hosted by Loughborough.  It was to discuss their approach to operating model work – SOMS – standing for Service Operating Model Skills.  Also speaking were two consultants from OEE, who have partnered Loughborough on the SOMS framework: Martin and Vishnu.  This blog is about one slide that they showed which got me thinking.

The slide was a version of this matrix from the Slack and Lewis text book “Operations Strategy” third edition 2011, Prentice Hall.  The left side of this matrix is “Performance objectives” which leads to “market competitiveness” on the right side.   The bottom axis is operational “Decision areas” leading to “Resource usage” at the top of the matrix.   The boxes in the matrix are used to layout the main elements of the operations strategy or operating model.

This matrix is familiar.  But, for some reason, the way it was presented by Martin and Vishnu, using a case study of a bank, got me thinking in two ways.  First, if instead of “Performance objectives” we use “Value proposition”, the matrix would have the same focus as the Operating Model Canvas.  I will come back to this.   Second, if instead of “capacity”, “supply network”, “process technology” and “development and organization”, we use POLISM – processes, organization, location, information, suppliers and management system – the matrix then has the same decision areas as the Operating Model Canvas.

So the big thought going through my head: is the Operating Model Canvas, just a reinvention of the Slack/Lewis operations strategy matrix?  The answer seems to be yes.  So the next question: is the Operating Model Canvas superior and if so why?

I have little doubt that the POLISM categorization of operations decisions is superior: more strategic, more complete and more managerially friendly.  It does not include capacity, in terms of numbers of people or size of machines.  But, for me, the sizing issue is a second order issue.  First you define the operations strategy. Then, given the strategy and the plans for the next period, you decide how much capacity to build for the next period? (I should point out that under the broad heading of capacity Slack and Lewis, include location and buildings, so it is close to the L in POLISM)

Where the Slack/Lewis approach may be superior is in the way it lays out “performance objectives”.  The Operating Model Canvas has “value proposition”.  But does not sub-divide the concept of value proposition in any structured way.  So I have spent a couple of days trying different ways of laying out a value proposition using a similar format.  See a couple of attempts below.  The first is for my course Designing Operating Models (see  The second is about Test Equipment

My conclusion is that one row should be devoted to describing the product/service: is it a piece of test equipment or a management course?  The rest of the rows should describe the main features of the value proposition, particularly those that are expected to give advantage (the USP) (coloured in reddish orange).  If POLISM is put along the top axis, the bottom axis can then be used to summarize the aspects of the “operations strategy” that are most important to each of the elements of POLISM: the words that you might expect to find on an Operating Model Canvas.   If you have used the Operating Model Canvas tool, you will know that you should describe on the Canvas, (in addition to the value chains and the org chart) those aspects of operations that are most important to delivering the value propositions: exactly the same thought as the descriptions in the Slack/Lewis matrix.

So the Slack/Lewis format allows a more fined grained presentation of the value proposition, and hence a more fine grained connection between the value proposition and  POLISM.  Worth thinking about.  I will include it in my next course on Designing Operating Models and see how the participants like it.

Of course the Slack/Lewis format has other weaknesses.  It does not lay out the value chain. Hence my lettering in the top left box of the examples (my attempt to lay out a value chain in a very small space!)   As a result, the Slack/Lewis format does not visually show that the OLISM parts of POLISM exist to help make the P of POLISM (the bit that creates the value proposition) work.

But, as I keep repeating in this blog series, it is always worth understanding other people’s frameworks because most will have a dimension that is better than your own model.

Posted in OM frameworks, Operating Model Canvas, Value proposition | Tagged , , , | 14 Comments