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

Posted on October 21, 2016 by Andrew Campbell

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.

Posted on August 26, 2016 by Andrew Campbell

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.

Slide1

  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

Posted on June 1, 2016 by Andrew Campbell

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.

Slide1

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

When to do organisation design in operating model work

Posted on April 15, 2016 by Andrew Campbell

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 Design steps, Organisation model | 3 Comments

Capability Maps vs Process Maps: Horses for courses

Posted on April 14, 2016 by Andrew Campbell

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, Value chain | Tagged , , , , , , , , | 16 Comments

Peter Murchland on Operating Models

Posted on April 3, 2016 by Andrew Campbell

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.

“Purpose

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 steps | Tagged , , , , | 4 Comments

What is functional alignment in an operating model

Posted on February 21, 2016 by Andrew Campbell

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 functional alignment | Tagged , , , , , | Leave a comment

Tools for examining an existing or proposed operating model

Posted on February 15, 2016 by Andrew Campbell
Posted in Design steps, Design tools | Tagged , , , , , , , , , , , | Leave a comment

How to segment for value chain analysis

Posted on February 2, 2016 by Andrew Campbell

In both my consulting work and teaching, I am finding that good value chain analysis is the foundation of good operating model work.   Moreover, participants on my recent course – Designing Operating Models – voted “value chain mapping” as the best tool on the course.

But there is one tricky part in value chain analysis – segmentation.   Good value chain analysis involves doing a value chain for each segment being served.    But how to define a segment?   The idea is really about doing a value chain for each “offer” because each “offer” is likely to require a slightly different value chain to deliver.    So a good segmentation involves thinking hard about the different offers.   Let me give an example.

Ashridge Business School (now Ashridge Executive Education) has tailored offers (courses tailored for a particular company).  It also has open offers (standard courses anyone can attend).  It also has qualifications courses (like an MBA).    There is a research offer.  There is even a weddings offer in our beautiful house.   So clearly we need a value chain for each of these.    But is this enough detail.

Within “open courses” there is an operating model offer, a finance for non-financial managers offer, a marketing offer and so on.   Hence, at a more detailed level, it makes sense to do a value chain for each of these courses to see if there are significant differences and to assess where economies of scale lie.

But one can go into even more detail.  My course Designing Operating Models has different sessions taught by different faculty.  Maybe it is necessary to do a value chain for each of these – one for the value chain mapping session, one for the organisation modelling session, one for the whole day case study.  Typically, this level of detail is unhelpful.  But it is usually worth going down one level of detail below what seems useful to check that more insight is not available.

So my advice is to segment at multiple levels of detail.

The other segmentation issue involves different ways of segmenting the customer or consumer.   Ashridge could segment by country of nationality because we have participants from 50 or more countries.   For most countries we do not have any tailored offer.  But for the Middle East we do.  So it would be worth doing a value chain for the Middle East separate from other geographies.  If we thought that we wanted to offer something different in Asia, then we could also do an Asia or China value chain.

Another way of segmenting customers might be by industry.  But Ashridge does not have any industry specific offers.  So doing value chains by industry would not bring in any new insights to help with operating model decisions.

So the guiding thought about segmenting customers or consumers is to segment when there are differences in offer which are likely to require some differences in the value chain needed to deliver the offer.

In conclusion, value chain maps are about exposing the different activities that are required to deliver different offers.   Having laid out the differences it is then possible to decide where the differences are so important that the activities need to be kept separate, where there are economies of scale that need to be captured and where there are opportunities for synergy and linkage – centralise, link or separate (my CLS tool).

Posted in Value chain | 8 Comments

Value chain, capability chain or operating chain?

Posted on January 8, 2016 by Andrew Campbell

Over the last year I have been going round in circles in my thinking about language.   I am convinced that the best place to start when doing operating model work is with a stakeholder map that helps identify the stakeholders of the organisation being designed and helps clarify what is in scope and what is out of scope and where the hand-offs will be.

The second step is to create a high-level process map of the main operating activities needed to deliver value to each customer segment that the organisation is trying to serve.   Of course, if the organisation is an internal function or a government department or a charity, then the “customer segment” is a group of similar beneficiaries or stakeholders.

On my course at Ashridge Business School, I refer to this high-level process map as a “value chain map“: typically it is limited to 4-8 steps for each “value chain”; and the map includes a value chain for each “segment” the organisation is trying to serve.   It is then possible to compare across the “value chains” to identify steps that can be combined, need to be linked or need to be kept separate – my CLS tool (combined, linked, separate).  There are other things that can been done with the “value chain map”.  It can be used to highlight the sources of advantage.  It can also be used to identify problem areas.

I then use the value chain map to create an organisation model.   The basic idea is that each value chain is a “unit” (business unit) in the high-level structure and “combined” activities become central functions (either “shared services” or “core resources” or …).  If large numbers of steps are combined, the organisation becomes just one value chain, with each operating step reporting up to the top.  Using the organisation model, I then add in “support functions”, like Finance, HR, IT, Legal, Strategy, etc.   These two outputs – the value chain map and the organisation model – are the core visuals of the operating model.  Other visuals include a location map, a process and IT ownership map, etc.

This approach differs from the approach used in Business Architecture which starts with a capability map.   Trying to understand the differences between my approach and the capability map approach has been causing me to go round in circles.

I have concluded that there are very few differences, especially if I change my language from “value chain” to “capability chain” or even “chain of operating capabilities required to deliver value to the customer”.  The difference is that a value chain map only focuses on the “chain of operating capabilities”.  It does not include any of the support capabilities (like Finance or Legal) or management capabilities (like Strategy or Performance Management).    A capability map often positions these management and support capabilities at the top of the map and the operating capabilities lower down.  In contrast, the value chain map focuses 100% on the operating capabilities.

I then use the “organisation model” as the tool for adding in the management and support capabilities.  The power of this tool is that it helps define the role that these management and support activities take with regard to the operating capabilities: are they shared services or policy capabilities or championing capabilities or core resources?

In my not very humble view the “capability chain” plus “organisation model” approach has big advantages over the “capability map” approach:

  1. It ensures focus on the operating work of the organisation – what needs to get done to deliver value to the customers.  Capability maps often appear to give more focus on the support capabilities than on the operating capabilities, which potentially makes sense if you are coming from IT.
  2. It ensures that the model for doing the operating work – what is combined, linked and kept separate – is defined before attention is given to the support and management work.  This helps ensure that the support and management work is set up so that it supports the operating work rather than creating tensions with the operating work.
  3. It encourages the designer to think about how the different “capabilities” in the organisation are going to work together, something that seems to be missing in most capability maps.

The only disadvantage that I can detect is that the “value chain plus organisation model” approach introduces organisation structure into the thinking quite early on.  The “capability map” approach is more organisation structure agnostic.  I say more agnostic rather than completely agnostic because in practice most capability maps are influenced by the normal organisation structures: finance capabilities are typically lumped together under Finance and marketing capabilities under Marketing.

So this raises in my mind the question of whether I should refer to “value chain” or “capability chain”.   The phrase “value chain” works well for those who have been trained in strategy: in Michael Porter’s concept.  But it does not work well for Business Architects or Enterprise Architects, who like to talk about capabilities.  There are also many other communities, like HR, that like to convert strategy into capabilities requirements rather than value chains.   Of course it is not as simple as whether to refer to capability chains or value chains.   The lean community prefer terms like “process map” or “value stream”.

Maybe there is no solution to this language problem.  But recently I have been talking myself into using capability chain.

Comments welcome.

Posted in Capabilities, Value chain | Tagged , , , , , , , , , , , | 7 Comments