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.
Ashridge on Operating Models 
Capability modeling is one of a number of tools used to inform the development of an enterprise transformation program. Any assessment of its appropriateness or effectiveness should incorporate elements of:
a) understanding the problem that needs to be solved
b) understanding the role and contribution of capability modeling in solving that problem (eg. the other steps / tools that may be used and the purpose of the use of CM in that context)
The discussion that Andrew and I are having on LinkedIn is part of a topic entitled “Exploring the use of the capability concept”, arising from a debate in a different group about the definition of capability where I made the point that it is necessary to understand the purpose of using the concept.
There are steps that I take preceding the use of capability modeling – exploring the business model and operating model of the enterprise. The capability modeling is undertaken to:
a) understand the capabilities needed to realise the intended business model and operating model
b) identify capability gaps (missing capabilities or immature capabilities requiring development)
as input into developing a program of initiatives to address the capability gaps.
The primary use of the capability assessment is to aid in:
a) understanding capability dependencies so that initiatives are formed taking account of these dependencies
b) prioritising the initiatives and timing of resolution of the identified capability gaps (as there are often too many things to do and insufficient capacity to address all the gaps at once)
Andrew indicated as part of his commentary that value chain maps are the best tool. The use and expression of value chains occurs in the preceding step (in my approach) of expressing the intended operating model for the nominated enterprise (whether the enterprise is that pursued by an organisation eg. ABS or an enterprise within the organisation such as marketing). If the latter, then it is important to understand the scope of the enterprise and the meanings being applied to key terms and concepts, as marketing means different things to different people, most typically distinguishing between market strategy (focused around determining combinations of customer / product / service to be pursued) and promotions (how products and services are communicated to develop sales).
It’s very common for people to confuse the ability to do, with the doing, when talking about and using Business Capabilities. As you say Peter, it’s primarily a strategic tool, to understand what capabilities an organisation requires to deliver its Business Strategy and Business Model, its products and services; and address any gaps.
Business Capabilities are realised through a set of resources – people (skills, knowledge and experience), technology, data/information, materials, location and processes. It is an emergent property of all these resources and their associated ‘resource capabilities’.
Business Capabilities are great for designing the logical design of these resources, e.g. Process building blocks, People Capability role definitions. But when it comes to designing the actual physical operating model, this should be against the products and services (E2E processes) that utilise instances of the Business Capabilities, and the resources themselves, using service design/OM design techniques, within the context of the capability-driven reference architecture.
Well and concisely expressed Tim, as always. Thank you.
Your first para is distinguishing between what (the ability) and how (the doing). I guess gaps can exist in the “architecture of the whats” and also in the “maturity” of the doing. But, in practice, I find that it is often hard to know whether some outcome is not being achieved because we have failed to define the capability with sufficient precision or whether we are executing it badly: it is normally a mix of the two, which is not easy to disentangle. If I write a sentence that is hard for you to understand, is it because I did not define the capability “easy to understand sentences management” well, or is it that I am not a very good writer?
Your second para is saying, I think, that you need an “operating model”, or at least what I think of as an operating model, for every capability. For me, this makes the word “capability” equivalent to “valued outcome” or “product/service” with regard to the operating model that enables it.
The last para, I found less easy to understand. The first sentence states that a capability architecture/map is “great for designing the logical design of these resources”. Maybe I need an example of what you mean by “logical design”; and maybe I need an example of how “business capabilities” aid with the creation of a “logical design”. I agree with the last sentence except for the final “within the context of the capability-driven reference architecture”. I find that I can design “the actual physical operating model” without this context. In other words, I can define an operating model for “writing a blog”, without developing a “capability-driven reference architecture” for “writing blogs”.
My worry, which is at the heart of this blog, is that, if I do develop a “capability-driven reference architecture”, it may bias my thinking (and the thinking of business and enterprise architects) about centralization/decentralization and standardization/localization as well as distract my focus (a little) from the operating value chains onto supporting capabilities (and, as Peter points out, these risks are much higher when the capability work is in the hands of the less experienced user). My other worry is that maybe I am missing something really valuable by not using capability maps and reference models.
Maybe this whole thread is therapy for my worries! I am certainly becoming less worried as I get input from people like you, Peter, Clive and others, who clearly do know what you are doing.
Andrew – “Your second para is saying, I think, that you need an “operating model”, or at least what I think of as an operating model, for every capability. For me, this makes the word “capability” equivalent to “valued outcome” or “product/service” with regard to the operating model that enables it.
Definitely not. Operating Models utilise capabilities.
Logical design helps you configure the enterprise’s resources in the most efficient and effective way. This is particularly true for Technology. A classic example is “Case Management”. In the physical design, there will be lots of examples of case management and the common nature of each instance is often missed. But an analysis of the capabilities required will identify what is common in each instance and what can be delivered through a common resource, e.g. Case Management technology that is then configured for each capability instance.
Tim; A good process practitioner often approach this the other way around, per your case management example. We actually go straight at the main process of the main type of case, and from there we investigate case variants. From the start we hypothesize that there is a shared process structure to it. As opposed to as you say, have lots of cases dont one does not understand to be connected and needing capability thinking to derive that there is a common structure.
Enterprise Architects aren’t often asked to define operating models, because the role “Enterprise Architect” is most often (incorrectly ?) used to mean an “IT architect across multiple capabilities”. I haven’t seen many comments by HR professionals, and HR is often the department charged with “organisation design”
Peter M’s approach is perfectly valid if you have already defined your product and the architect is then defining the processes for that product (and IT and information models), which is a more usual task for an Enterprise Architect. As an aside, Enterprise Architects will increasingly use the term ‘capability’ because that’s what’s defined in Archimate 3.0 at the strategy level.
I don’t think that there’s a “problem with capability maps”, it’s just that EAs need to get used to asking a different set of questions and driving a different set of outcomes to what they have traditionally been asked to do. As I’ve said before, EAs will soon need an MBA and an IT degree before they can call themselves “Enterprise Architects”
I agree that most EAs are not asked to define an operating model. That is partly because most EAs are actually EITAs and not architects of enterprises. More often CEOs, CXOs, and LOB Executives define the architecture of the enterprise, but they usually do it be defining the organisational structure, not the operating model. Andrew can offer insight into the type of people who attend his operating model design courses, which will shed some light on the growing cadre of people taking greater interest in operating model design. I can assure you that successful OMD goes well beyond the experience and capability of those in HR functions, too.
The approach that Interface Consultants adopts is not constrained by requiring products to be defined. It can be applied to and by a startup through to any size enterprise. Our approach is not exclusive to our organisation. I note that FromHereOn takes a very similar approach, as just one example.
At present, the onus is back on Andrew to better qualify the problem he sees, given that his current articulation is based on a false premise (that capability maps are and/or should be the starting point).
Peter, It has taken me a long time to reply to your helpful comments. I am beginning to better understand the differences in approach between EAs and Operating Model designers.
I like a value chain map because it helps me think about organisation. As an operating model designer, I want to be able to think about “what work needs to be done”, “who is going to do the work” and “how to organise these people”. I then turn my attention to issues such as “where will the work be done”, “what supplier relationships need to be set up” and “what information systems are needed to support the work”. A capability map is probably helpful when thinking about the last item because, developing one system to serve multiple activities (because they all involve the same capability), can save a lot of cost and effort. I will put my hands up and admit that my IT Blueprint tool is a pretty rough and ready tool and may not flush out as many opportunities for system sharing as a capability map.
As I now better understand, EAs are most interested in “what work needs to be done” and “what information systems are needed to support the work”. This could explain why a capability map has such prominence (I agree that it does not need to be the starting point) in EA work. “Who does the work” and “how these people are organised”, in my understanding of EA work, comes later, if at all. The danger, in my view, is that, when an EA does focus on people and organisation, the capability map “pollutes” wise thinking about these issues (note my deliberately provocative phrasing!).
Andrew, I will be responding in short bursts – when I am availed with time.
I am quite bemused by your rationale for liking a value chain. Why? Because they are all the reasons that I use a capability model. So … as we have identified previously, some of the differences seem largely to be semantic or to differences in assumptions about “what constitutes a capability” which will inevitably enhance or constrain the value that we can derived from a capability-based-view.
Or, to put it another way, a capability model is helpful when thinking about all the items you name, not just the item pertaining to information systems.
I will come back later to share some material from Peter Checkland in his works on Soft Systems Methodology which, in essence, helps in understanding that it is not possible to separate information, information systems and people – principally because people are the means by which meaning is applied to information – hence, when an information system is designed it is inextricably linked to people, teams, organisations.
If anything, it seems to be that you are encountering one of the most common problems arising from a reductionist, analytical approach where it is assumed that one can examine a part of a system and its design or its behaviour, when it can actually only be understood in terms of contribution to emergent outcomes from the whole.
A comment on the concepts “capability” and “process” as they pertain to the structuring of activities. The process perspective focuses on sequence of activities, and that sequence being the value creation sequence – like a project – just continuous. The capability perspective on activities focus on clustering activities as they relate to a specific activity, e.g. what is involved in “invoice management”. The latter perspective pulls those activities out of the overall value creation sequence of a company, and makes it hard to work with because reality do care about sequence.
Grungern, I fully agree with this thought. The capability perspective “pulls those activities out of the overall value creation sequence of a company, and makes it hard to work with because” in reality the sequence does matter. Of course, there are often good reasons for “pulling the activity out of the sequence”, but the default position should be to keep activities reporting to someone who is responsible for the whole sequence. Also, the capability perspective is only a perspective. It “pulls the activities out” for the purpose of analysis. They can still be put back in sequence when the organisation structure is chosen. But, my observation, like yours, is that the capability perspective leads to too much “pulling out” when the organisation structure is chosen.
Yes, you make an important distinction that I think is lost on some of those which are too hung up on capabilities. And that is that its fine to “pull out” activities in a capability oriented fashion for analysis. But if they miss the fact that those activities actually belong to some value creation sequence, they can get really lost. One hypothesis I have on why IT people often fall into this is that they live more in a world of apps having to talk with other apps, and that from their perspective – this is more like ping-pong between different nodes or events. But from a birds eye business perspective view, you see that what you thought where just an ability to talk between apps, actually has recurring pattern to it, some sequences. This lack of process understanding has gone so far that now we have a popular new technology called “process mining”. Such tools read through data-records and through algorithms draw up what the underlying processes actually are – the pattern. If one had been more process oriented from the start, one would know of these processes and had proactively captured data about their performance, instead of now reverse-engineering it. Although useful, such tools I feel is an example of where lack of process understand and orientation can lead to.
Grungern
This is where I part company with many EAs and where I challenge Andrew that he is dismissing the value of capability modeling based on misuse / poor use of capability modeling.
My starting point with anyone is to establish clarity around definition and use of “capability”. I help them understand that capability is “of something” ie. it is more like an adjective than a noun. We tend to treat it as a tangible entity when it is an abstraction of an entity. I suggest (as one cannot “force” anyone) they consider that the capability is of a “system”, whether that is a people based system, a technology based system or a combination. With the introduction of a systems-based-capability-perspective, one brings the process with the capability – and the capability becomes agnostic to any dimension of the system – people, process, information, asset, location, organisation – allowing one to test different assumptions or options in varying one or more dimensions. The process element means that one brings connection to supplying and consuming systems and processes. The systems view means that one brings system-in-focus and containing-system(s) considerations.
So, one is no longer simply “clustering” or “pulling out”, supposedly with impunity, but actually with high risk and cost because the options that might be considered for the plucked-out-capability will not take account of differing dependencies, whether in a horizontal or vertical direction.
The other “point” I would make here is that I strongly encourage qualification of the capability, at least in terms of whether it is the capability of a business system (social / people / human activity) or a technology based system. The former needs to precede the latter as it is the former that consumes / uses / derives value from the latter. (We all know the hazards of pursuing technology based capabilities without consideration of the purpose for which they are being used!)
Peter,
It sounds like you are taking a broader perspective than many EAs then which is good. I know that one can do exactly like Andrew and me do with process with capabilities, just using a different name. But, in order to do that, one must understand that in business, taking the value chain process perspective is to take THE systems perspective. The sequence of value creation is the most important and central feature of the very system of business. As long as one understands this and the related rules, one can call a process a capability and get great results. However, in my experience, most of those who drop the process focus for capability focus dont appreciate this and can get lost in complexity as they “dont see the path” though it (the value chain processes).
Hi Andrew,
Your absolutley right. The capability perspective “pulls those activities out of the overall value creation sequence of a company, but I dont think it makes it hard to work with because its horses for courses. Choose the right tool for the job. As Peter has said, in IT we use it primarily to surface IT systems, but it also serves as a container for process, organisation and a range of other related questions and concerns. In my current role I have to identify replicated capabilties across one of the largest organisations in Australia. Capabilty Mapping is a highly effective method to do this.
I currently have dozens of groups and business units who perform an aggregated capability like Media Production. Consider the number of technologies, platforms, processes and possible organisational issues I may have doing this on an international level. At the very highest level that set of capabilites from jounalism, media production, publishing, hosting, archiving can also provide valuable insights into Value Chains. If later I need to explore services, processes and organisational structures Ill use different tools. Its about the right tool for the right job and good tradesman in my view, know the difference.
Great comment Clive. It is about the right tool for the job. My view is that Capability Mapping is the wrong tool if you are doing high level operating model design. It is the right tool if you are trying to identify replicated capabilities, although even here I would caution users to first understand the value stream the capability is part of because this will help the judgement about whether the capability really is identical: media production management for TV is very different from media production management for radio or for advertising or for magazines; or at least there are parts of media production management that are different. Capability Mapping may also be the right tool for assessing gaps between “as is” and “to be” and for thinking through the connections for transformation planning. But, in my view it is a slightly dangerous tool for operating model design because it typically disconnects capabilities from their value streams. It also treats supporting capabilities, such as financial management or people services management, as equal in importance to operating capabilities such as sales management or production management. For me, the key is to get the design and organisation structure of the operating capabilities sorted first, and then layer on the supporting capabilities.
Let me explain why you need to understand how the operating capabilities are organized into a structure before you “layer on” (meaning start thinking about) the supporting capabilities. The reason is that a capability like “financial analysis management” is different if you are supporting a set of business units or a set of units in a matrix structure or a set of functions forming a single value stream. Of course there may be aspects of “financial analysis management” that are the same in all three contexts: all will need the ability to add up a column of figures; all will need to access transactions data. But, these are the commodity capabilities involved in “financial analysis management”. The critical capabilities are different. The same would be true of “strategy development management” or “people strategy management” or even “remuneration management”. Of course it varies. Some support capabilities do not differ depending on the organisation structure they are supporting: “payroll management” or “facilities management” are likely to be “replicated” capabilities in different organisation contexts. But many support capabilities are not “replicated” even though we may use the same words to describe them. At Ashridge Executive Education “course administration management” is different for an open course from a tailored course. An administrator, who tries to use the same processes and systems for both, under performs in one or both.
It’s about the “right tool for the job”.
So let’s discuss the criteria by which the tool is selected – this is the nub of the entire “debate”.
I will never be convinced by “I like this tool”. Please tell me the criteria that it satisfies better than other tools and consider the criteria where other tools may be better than the “tool you like”.
Andrew,
So many topics 😉
Yes, it is the wrong fit because ones about Structure (Capability), i.e. cataloging the parts, and the others the dynamics between those parts (form vs. function). People, execute one or more processes to deliver a product or service, often with a tool.
When we’re at Enterprise Level 1 its a bit of a semantic argument and most get to caught up in that IMO. Is Human Resource Management a Capability ? or aggregated Process? Well, That depends….. on what you do with it next, they can look the same. And most Operating Models on the surface look like Capability Blocks.
Are HRM’s major process parts of Payroll, Leave Management and so on Capabilities or processes? Same argument, what are you looking to do with this next? Org design, Service and Process workflow flow? or exploring further capabilities for maturity? As Peter has rightly asked, whats the criteria for using each, its a good point.
Knowing the parts though does help you to determine the design at each level of the Enterprise. Whether that’s Level 1 of Process (or Function), Organisation, or Product Parts knowing the parts helps enormously with Design. Provides a great tool for analysis, its the Business in parts.
I, like Deloitte, define big capabilities first and then move on to Organisation (Business Function) and Op Model Design (workflow) as taught by Rummler and Brache in Managing the White Space on the Org, Chart which stemmed from their work at Motorola (Six Sigma) and before them Deming (where SIPOC originated). Not much has really changed since then, i.e once you know how to classify the parts and layer them. So, what has changed is we’ve got a lot better at classifying the parts as evidenced by Cloud Architecture and the many company’s developing their own Business, Capability and Operating Models. The parts are now better understood.
My own view and model, which is reflected in Deloitte’s model below shows the relationships between the major building blocks. Its a good approach, it works. Are there other approaches, sure, so long as you can prove you have both horizontal and vertical integration and provide the metrics that measure the end to end value chain results es then its fine, although few really go there.
ps… I’m aware of the value stream capability specialisation’s required for different value chains, thanks for the perspective. Next ill define some of the criteria that I’m aware of for when to use each as Peter has suggested.
Deloitte’s view here ….
https://www2.deloitte.com/us/en/insights/focus/industry-4-0/reinvent-operating-model-digital-transformation.html?id=us:2sm:3tw:4di_gl:5eng:6di
Peter and Clive. Andrew and myself fully understand “the right tool for the job etc”. The whole point about both processes and capabilities is the study of work related to some outcome. If we study these concepts as per plain use, oxford dictionary, etc, it becomes clear that they are related but different. Process relates to work directly, and is in fact synonymous with work. Capabilities not so, but through ability realised through resources and a process using those resources. Process by its definition focus on sequence, capabilities not so, but rather its constituents. What many capability oriented thinkers dont appreciate is that one can talk about processes at many levels of abstraction, even for a whole company. You dont really need capability as a concept for the abstract and process for the detailed analysis of work, process can used for both. The crucial thing about process is its focus o sequence and transformation of inputs to outputs through activities performed by people or machines according to rules. Try talking to a process engineer in a chemical plant about skipping process and focusing more on capabilities.. Process as concept is the closest we get to physics in business, its the very structure that binds everything else though the complexity of value creation! Drop it at your peril ;-D
So rather then reinvent, I went looking for another view, one that resonates with my own of course, which I feel rings true on capabilities and when to use them. History for me is important to the extent that you can see where and how something has evolved, what its influences have been. That said theres always so much to learn. I quite like Tim Mannings view and summary on Business Capabilites which resonates with my own thinking, research and knowledge to date and where its come from. The current view on Business Capabilities has its roots in the Resourced Based View. An extract from Tims blog here…..
‘Enterprise Architecture. The link to Enterprise Architecture was originally made by Prahalad and Hamel in “The Core Competence of the Corporation” and in their well known book “Competing for the Future”. They argued that companies should develop a corporate-wide strategic architecture, that identifies which core competences to build; and their constituent technologies and other resources. Today, this approach can be seen through the use of Business Capability Modelling (BCM), which provides the principal link between strategy and operational design.’
Like Tim, I first identify enterprise capabilities that are required for a given business model. Next, I explore those capabiliites for a raft of reasons, some of which are identified in Tims blog, and I have included some of my own:
– Sourcing decisions
– Strategic Alignment and development
– Capability Maturity across capability elements and improvementc
– Investment Decisions
– Technology Asessement (across their life cycle). Many assessments here…..
– Merger, acquisition and demerger
– Process Analysis
– Organisational use and staff numbers
– Cost Analysis
– Value Chain and Value Stream analysis.
– Metrics Analysis and development, particulary across Value Chains
Article reference here.
https://design4services.com/category/methods/business-architecture/
Given more time, im sure id come up with more use cases. In the end, for me its simply a starting point. I always identify the biggest enterprise capabilites required first, and then analyse them in terms of the end to end value chains, if thats the focus. For Operationg model work, I move the capabilites onto a SiPoC model and then focus on Process as taught by Rummler and Brache which has its roots in W.E. Demings work and where the thinking for six sigma was born at motorolla.
This is a reply to Clive and Peter Murchland both of whom are very thoughtful on this issue.
First, Peter is right. It is a question of “right tool for the job”. As I am beginning to realize, I need to design an operating model (people, process, technology, etc) for each capability. In this context, a “capability” is a similar concept to the phrase “value proposition” or in more simple language “product/service”: a capability being the ability to create some valued outcome. With this understanding, a “capability map” is a way of breaking down the overall “value proposition” of the organization into sub “value propositions” or internal “value propositions”: the “ability to do something that is valued internally”. These internal “value propositions” or “capabilities” are each needed to create the overall, external “value proposition”.
Second, I agree with Clive about Tim Manning’s summary. But not with all of it. The way the word competence is used by CK Prahalad (sadly now dead) and Gary Hamel (with whom I had the pleasure of sharing an office at London Business School) is subtly different from the way capability is used in Business Capability Mapping. Gary and CK were thinking of capability as an activity rather than an outcome. They were thinking in a Porterian way about value chains, and were looking for competences that were core to commercial success in more than one value chain. Hence the title of their HBR article “the core competence of the corporation”, and their focus on multi-business corporations. In the years following this classic article, many companies tried to define their “core competences”, but found it difficult because there was no easy methodology for doing this. Despite their reference to Business Capability Modelling, it did not, in my judgement, prove to be a good tool for identifying “core competences”.
I now find that, by laying out the value chains and asking myself (or those involved) which steps in each chain, if done really well, are most critical to commercial success, I can then look across chains to see if there are “critical steps” that are “replicated” across multiple chains. These, or parts of these, “replicated critical steps” are the “core competences”. In this way, you can have “core competences of the corporation” or “core competences of the IT function” or “core competences of the Scottish operating unit”.
Another link worth making is with Porter’s “activity system”. This concept is similar to the core competence concept because it is about identifying the source of competitive advantage or excellence in a commercial organization. Porter considered this to be a nest of three or four or five “activities” that in combination create the advantage. So the advantage is as much about the interaction between activity as it is about the activity itself. When I was at McKinsey in Los Angeles 1980, we referred to this as an “organizational skill”, which I think came from work Tom Peters was doing, in San Fransisco, as part of his great book “In Search of Excellence”.
Andrew, In “Competing for the Future” Hamel and Prahalad did not think about capabilities in terms of activities, but as “a bundle of skills and technologies”.
The separation of ‘ability’ and ‘activity’ is fundamental to an understanding of Business Capabilities and their application to enterprise design. An activity utilises a capability created by a bundle of skills, technologies and other resources, frequently in multiple instances, across multiple business units.
Tim; an activity does not use a capability. A capability is made up of a recipe and resources to execute that recipe. The recipe is activities/process. Per plain English. E.g; the capability of pizza baking. There is a recipe (process) for how to do it, and it refers to resources like flour, water, salt, a bowl, a person. Or what about this do I misunderstand if you dont agree?
Since the last input by Grungren, I have been to New Zealand to see my grandson and give a lecture at Otago Business School in Dunedin. Now I am back at home with three children plus partners, plus another grandson – but no work! So possibly time for more discourse on this fascinating topic.
I would like to see Tim Manning’s response to grungren last post. I do find the following statements of Tim’s difficult
1. “Hamel and Prahalad did not think about capabilities in terms of activities, but as “a bundle of skills and technologies”. Clearly we are using the word activity differently. Because, for me, an activity is a “bundle of skills and technologies”. When I am doing the activity of making a pizza, it involves a bundle of skills, processes, technologies, etc. So, it seems there is a definition issue. As I understand it, the capability is “the ability to make a good pizza” and the activity is “pizza making”. Am I misunderstanding something here?
2. “Definitely not. Operating Models utilise capabilities.” The difficulty I have with this statement is that I see operating models as a Russian dolls. There is an operating model for the whole organisation, and one for the Australian business unit and one for the Group Finance function and one for the Treasury Dept in Group Finance and one for the Sales Function in the Australian business unit, etc. So, for me higher-level operating models utilize lower-level operating models. If instead I use the capability language, then I can have one capability for the whole organization e.g. Business School Management. This capability utilizes (or is made up from or consists of) lower-level capabilities e.g. undergraduate business education management, post-graduate business education management, etc …. as well as Group Finance Management and Group HR Management. Then at the next level down, undergranduate business education management utilizes (or is made up from), undergraduate student marketing management, undergraduate student selection management, etc. And Group Finance Management consists of Treasury Management and Financial Analysis Management, etc.
So for me a “capability” is the valuable outcome of a “bundle of skills and technologies”. An operating model is the design for how to utilize the “bundle of skills and technologies” to deliver the valuable outcome. Hence my view that you need an operating model for each capability: a high-level operating model for a high-level capability and a low-level operating model for a low-level capability.
A brief dip into this …
Firstly, there has been no doubt from the outset of my connection with Andrew that he and I make sense of things in different ways. So, some of this is about “different ways of making sense of things” and sometimes this means that we are placing subtley different meanings and significance on particular words, as Andrew is now exploring.
So … one contribution from my thinking processes and ways of making sense of things in this arena is that “capability” is an abstraction from what has the capability. It might be, for example, that Andrew and I both have an equivalent capability to make pizza – in which case, it is the same capability that can be interchanged – on the other hand, having Andrew fulfill the pizza making capability brings other capabilities that he has and that I don’t have – so we can make choices about how best to fulfill the need for a capability (including choosing whether to use a technology based capability, a human based capability, or a mixed capability.
(All that I have time for at present)
Back for a couple more minutes …
An important consideration in all of this is the following, I believe (until someone gives me a different way of making sense of this) …
Some of the terms we use – process, capability, activity – are deeply intrenched in our minds, and the “entrenchment” arises from the wide variety of ways in which the terms are interconnected to create the emergent properties of knowledge and understanding. For example, I might be highly resistant to Andrew’s conception of process – one of the reasons for this is the extent of brain rewiring that would be necessary in order to take on his conception and integrate it into the rest of “my thinking”. Hence, he may experience me as rejecting the term – when it is not really that I am or am wanting to reject it – there is just too high a cost in accepting it.
This where I have found it helpful to become a babelfish – so that I come to understand how Andrew conceives of and uses terms with requiring adoption and integration into my own conceptions, models, etc. So, I seek to hold multiple models and cross-reference them rather than being “forced” to adopt a single model – even when it is only a “reference model”.
Overall, I treat my own internal model as that which I maintain with the highest degree of integrity (and understanding) and I use it as a point of reference to others’ internal models, but I do not seek to impose my model on them – as that is virtually impossible, too onerous for them, and in fact, we benefit more from a diversity of models than from one, single, unified model.
Interested to hear how others operate in this space …
Peter, no surprise, I agree with your thinking on this,
One of the biggest flaws in my opinion is the thinking and teaching that stems from some circles is that Value Streams (which are aggregated Processes) somehow use Capabilities.
For me this is the same as saying an ‘Activity’ uses a Capability. So, I agree with Grungern on this point. It seems nonsensical that the activity part of the capability is pulled out, and now uses the capability? Isn’t that now a process view using a tool? Does the Organisational Business Units (and related skills) still sit inside these capabilities? Anyone who’s tried this in earnest knows the difficulty this mapping creates.
Capability Mapping is not the same and shouldn’t be used in my opinion for Operating Model Design specifically, as they are quite different views. That said, at the highest level they can appear to look much the same. And both these methods can be used to asses an organisation. However, mixing the methods just creates confusion and a lot more work. Capabilities are a great source of information and input into Op. Model Design.
In the end, what makes Capability Mapping so unique and useful, is that it places the parts under a microscope which enables the assessment of those parts related to the capability for various reasons. Say my capability is Media Production. My process capability might include graphic design, the tools include my Surface Pro and the Adobe Creative suite, a Camera and their used within a specified business Unit called A. In my Business I have 26 Business units A-Z. Each uses a different camera, different process and different technologies. Some use Microsoft, some use Apple, some use Adobe and so on. Capability Mapping is very useful for this level of assessment.
In other cases I might want to place the Capability parts under the microscope to analyse their competitive advantage. Maybe another supplier can provide me different technologies that are state of the art and are not easy to replicate.
I develop models and use them as baselines to test concepts, ideas and the organisations semantics. I use Capability Maps that include processes, specific Organisational Business Units alongside Asset Classes and other things like resources, money and consumables and so on to assess Capabilities. I classify every single item separately! And then configure the models, this is key!
Andrew, when I use the term ‘Activity’ it means only the activity part, not the tool or the person performing it (or their skills). Otherwise it conflates the issue. Some terms are an aggregation like Capability and Operating Model and we’d have to agree on the parts that we use to classify those larger parts. And this is actually one of the reasons why the Resource Based View of the firm was discontinued due to its complexity and lack of simple terms. So to use them in Op. Model design work and get that right…. hmmm why make a difficult job so much harder?
For Service Design, I continue to use Value Chains that cross Organisational Boundaries that unpack to Process models. Value streams feed the Value Chain (the end to end view). As you know, the only way to deliver service (and product) is via a process.
Peter and Clive, What wise and thoughtful contributions.
I agree with almost everything, and I only say almost because I know that I don’t fully understand all of the points you make … and hence there may be a disagreement lurking in the text!
However, as Clive points out, capability modelling or mapping has a particularly powerful use case: the uncovering of capabilities that are similar but are supported by different tools, technologies and processes in different parts of the organization. These are opportunities for best practice identification, simplification, standardization and potentially centralization. Also, as Peter has pointed out earlier in this thread, capability mapping is often clumsily used by enterprise architects.
My take aways from this enlightening engagement are:
1. As Peter points out, we each have tools that work for us. So we should beware attempts to impose.
2. As I have tried to point out, all tools and frameworks are liable to bring some bias to ones thinking (especially if used badly). My concern is that capability modelling, as I have seen it used, brings the bias of “best practice identification”, which on the face of it seems a good bias, but can lead to too much standardization and centralization. Also, again when used by less experienced hands, can confuse leaders because the language is not natural to the way they work. I should point out that value chain maps bring a bias of “organize by value chain unless ….”. When used by less experienced hands, this tool can also have downsides. So Peter’s advice that we should be familiar with more than one framework, to help us avoid these biases, is clearly correct.
3. As Clive points out, know what job each tool is particularly good at and beware using it for other jobs where its efficacy may be reduced, and its bias may be more problematic.
Thank you both.
One further comment. I have just come across this article describing the Enterprise Architect of the future (someone like Peter!). It is an Open Group article and is an easy read https://blog.opengroup.org/2020/02/26/the-future-enterprise-architect-2/#comment-18128. In the article value chains/streams are mentioned quite a few times, whereas capability models are not mentioned at all. Could this be the beginning of a turning point?