Design Principles that guide the design

Posted on November 9, 2015 by Andrew Campbell

I have already completed three blogs on the topic of design principles – design principles – how to get good ones, more on design principles and understanding design principles  .   But I was recently approached by my son, who is working for Accenture and wanted some guidance on design principles.  So let me try to summarize here most of what I know about design principles.

First, design principles are the first level of design work.   Whether you are designing an operating model, an organisation model or a new product, you need to start by defining what you are trying to do: what good will look like.   For example “the operating model must enable us to deliver to customers within 24 hours of receiving an order”.   Inevitably, there can be a confusion here between objectives/goals and design principles.  But the confusion is healthy.  The process of defining design principles is often also a process of clarifying the goals.

Second, there are multiple levels of design principles, as there are multiple levels of design work – rough sketch, blueprint, detailed specifications, etc.  It is important to know what level you are working at.  It is also important to understand the hierarchy of thought and priority that is provided by the levels.  So you need design principles at an appropriate level for each bit of design work you are doing.

Third at each level, developing design principles is a creative/design act rather than a linear progression.  Design principles cannot be created with a “paint by numbers” tool.  While there is a cascade of thought from high level design principles to lower level principles there is no one-to-one link between higher and lower levels: a principle at a lower level may be informed by multiple principles at a higher level.   For example,  “warehouses should be located so that all major towns can be reached within 4 hours” could be informed by needing to deliver within 24 hours, needing to keep costs down and needing to ensure drivers do no more than an 8 hour shift.

Fourth,  there is a difference between design principles and “requirements” or “customer needs”.   Design principles define which “requirements” or “needs” will be given priority and what implications this has for the design.   So design principles are “strategic”, meaning that they help you decide between alternative priorities and they are the first creative act because they start constraining the design choices.

Fifth, design principles can come from a variety of sources:

+ strategic objectives/goals (or higher level design principles),

+ constraints,

+ stakeholder requirements,

+ knowledge about the strengths and weaknesses of the “as is” situation …. if there is one, and

+ knowledge about which capabilities will be critical to success in the future .

I personally like to check my design principles against stakeholder requirements to make sure that I have not overlooked the needs of a stakeholder.  But, it is helpful to define a “mission” stakeholder for the design work: the primary beneficiary.  This stops the needs of less important stakeholders unbalancing the design.

Sixth, there is an art in writing design principles which starts with challenging any statement with three challenges

  • is there a choice being made between realistic alternatives? (Try the negative or lay out a scale and define where on the scale the principle is positioned.  Or try the Executive Attention test: will this design principle spark debate among those executives concerned about this bit of design? )
  • does the principle narrow the solution space? (What options is the principle excluding or steering you away from or towards?)
  • is it clear why this principle exists and is important? (How does it link to strategic objectives, constraints or stakeholder needs?  Ask the five whys.)

Time spent redrafting design principles or debating the meaning of design principles is rarely wasted.

Seventh, there is value in keeping the number of design principles at each level below ten.   The human mind can only juggle five or six or seven things at the same time, so a set of principles twice this number is less useful.  It is hard for a long list to influence the creative/intuitive act in a balanced way.   Limiting the number also helps force thinking about the “hierarchy of thought”.  As a colleague of mine likes to call it …. the Spice girls question ….”tell me what you want, what you really really want”.  So two or three design principles can be more useful than seven.

Posted in Design principles, Levels of design | Tagged , , , | 1 Comment

What is “architecture” in business design?

Posted on July 20, 2015 by Andrew Campbell

The IT community use the terms Business Architecture and Enterprise Architecture to describe the activity of “setting up” the business or the IT systems.   As a business strategist I have always found this language difficult.   I first came across it when asked to teach on a PA Consulting internal course called Business and Enterprise Architecture.  I was teaching organisation structure using ideas from my course Advanced Organisation Design.   I detected some discomfort about the name of the course, and after the first year, it was changed to Business Design.

Since then I have been in conversations about both Business Architecture and Enterprise Architecture with experts in both disciplines without really understanding what the term “architecture” refers to.   The building analogy is often used:  the “architect” produces the “blueprint” and external design.   But what is the equivalent in business terms.

In conversation with Peter Murchland, a business architect from Adelaide, he mentioned that Enterprise Architects are often referring to the “inanimate” when they think of architecture: the information architecture, the applications architecture and the infrastructure architecture, etc.

More recently I have been doing some thinking about different types of decisions.  Then it occurred to me that some decisions in business are “architectural”, meaning that they are hard to change and will influence other things for some period.  Other decisions are more day-to-day operational choices that impact the moment but do not constrain the choices that can be made tomorrow.

For example, where you locate is an architectural decision.  It has an impact on who you are likely to hire, and which customers you are likely to interact most easily with, and it is a decision that is not easy to change on a day-to-day basis.  So it is a “design” decision (or should I say “architectural” decision).   The organisation structure (whether to organise by country or by product line for example) is also a “design” decision because it has big knock on effects and is difficult to reverse.

In contrast, what job I give to Fred to do this afternoon is a day-to-day decision.  Which customer to visit tomorrow morning is a day-to-day decision.   Setting up a project team to discuss pay grades is a day-to-day decision: but, of course, the recommendation the project team makes about pay grades is a design or architectural decision.

So, my thought is this.   Some decisions need to be made in advance before an organisation can operate: what to do, where, with what equipment, with what kind of people, in what organisation structure, guided by which values, governed with what sort of processes, etc .  These are the design decisions or architecture of the organisation.  Once “set up” or “designed” most of the decisions that are then made are day-to-day.  But, if a subsequent decision is one that will be difficult to reverse or have significant knock on effects, it is a “design” decision and hence part of “architecture”.

Forgive me if this is all old hat – but I have found the distinction useful as I work on operating models.

Posted in Enterprise architects and operating models | Tagged , , , , | 4 Comments

Stakeholders and operating models

Posted on July 17, 2015 by Andrew Campbell

I had an insight as a result of a meeting with Angela Frith from Woolworths in Australia.  Angela was spending a couple of days with me to talk about operating models.   I was sharing my tools.   One tool, which I have blogged about, is a stakeholder map: an operating model is the operational engine that makes it possible to deliver value to and hence ensure engagement from stakeholders.   For a typical commercial business, the “active” stakeholders are customers, suppliers, investors and employees.  Being clear about who the stakeholders are and what “offer” is being made to each stakeholder is, in my view, an important starting point for an operating model.

I then explained that I normally start developing an operating model by drawing up a value chain map for each customer segment and or customer offer (for each product/market segment in marketing language).   Angela asked “but this is focusing mainly on the customer.  How do you think about the part of the operating model that delivers value to the other stakeholders?”   I waved my arms a bit and said some soothing words and we moved on.  But the seed had been planted.

Why does it seem to make sense to design the operating model with a focus on customers?  Why not design with a focus on shareholders or employees or suppliers?   Just asking this question helped because it seems self evident that one should start with customers: the people for whom the organisation exists.   Except that this is not really right.  Many organisations exist for the shareholders or for the senior employees … and farming cooperatives exist often to serve the suppliers.

Then Mark Lancelott (with whom I run the Designing Operating Model course) mentioned that Ives at Apple has said that when doing design work it is important to know which objective is the primary objective.

So my insight is this.  Yes do a stakeholder analysis.  Then decide which is the “primary” stakeholder for whom the work of the organisation is being done – normally the customer/beneficiary.  Then do a value chain/stream map of each segment of customer.  This forms the back bone of the operating model.   It is then important to add activities and even additional value chains to ensure that the organisation delivers value to each of its “supporting” stakeholders.  However, these additional design elements need to be aligned with the primary objective of the organisation rather than having a life of their own.

Let me give an example.  One of the value propositions to employees might be training.  It will be necessary to design an additional value chain around the delivery of training.  But this “supporting value chain” should reinforce not hinder the value chain aimed at customers.  So the content that is taught should be about how to deliver more value to customers, and the timing should be in a period when customer demand is low and ….

This might all seem rather obvious.  But let me assure you that being clear about the primacy of customers is helpful in the design process.

Moreover, it may also be helpful in distinguishing between strategy work and operating model work. Once one stakeholder has been chosen as the “primary” stakeholder, this stakeholder becomes the primary focus for strategy work (e.g. in a commercial business, which customer segments will we serve, what offer will we give to each and how will we gain advantage).  The organisation’s relationship and value delivered to the other stakeholders becomes something that is considered as part of operating model work rather than strategy work.  Of course if the relationship or value delivered is critical to competitive advantage it would be part of strategy work, but most categories of employees, suppliers and shareholders are not critical to competitive advantage and hence choices made in these areas are operating model choices rather than strategy choices.

You can probably see that I am struggling to distinguish between operating model choices and strategy choices … maybe a topic for a future blog.

Posted in stakeholders | Tagged , , , , , | 2 Comments

More about design principles

Posted on June 24, 2015 by Andrew Campbell

The more work I do on operating models and organisation structures, the more I focus on creating good design principles.  For example, at a recent workshop in Brisbane (just showing off that I have a global client base!), I spent a couple of hours with the group developing design principles towards the end of the first day of a two day workshop.  Overnight I worked on the wording and edited down the list to 6 or 7.  We then spent another hour, first thing, to get consensus and clarity …. before working on options.

So I was interested to come across an article by Marcia Blenko and colleagues from Bain & Co on design principles.   They argue that there are two sources of design principles:

– Strategy: “Design principles must specify strategic requirements that the operating model must support”.

– Current operating model: “They also pinpoint aspects of the current organization that could hinder the future strategy and therefore must change, as well as organizational strengths that should be preserved”.

They provide a list of places to look for design principles.  Under strategy, they suggest:

1. Ensure focus on …. areas of particular importance to the strategy such as growth areas or sources of advantage

2. Facilitate the making of ….. decisions that are important to the success of the strategy.  They may be about new product choices or pricing or which contracts to bid on.

3. Enable important …. linkages across geographies or functions or lines of business.  This could be about shared sales forces or coordinated product development or economies of scale in manufacturing.

4. They have a fourth item about capabilities, but, for me this is really a combination of the first three: a “capability” is normally a source of advantage that requires good decision making of a certain type and often involves complex links across the organisation.

Under operating model (they are a little biased towards organisation model), they suggest:

1. Reinforce ….. strengths such as “ability to get insights from being close to the customer” or “low cost from Asia sourcing”.   As you spotted, there is again an overlap with the idea of capabilities and sources of advantage.

2. Reduce …. weaknesses such as “poor customer service from overloaded call centres” or “high costs due to complex organisation structure”.

3. Clarify the role of the centre …. in leveraging expertise and scale and …. in adding value.  While I am a great enthusiast for “corporate centres that add value”,  I am not sure why the corporate centre gets special attention in this list, especially given point three under strategy above.  One of the outcomes of a good operating model is clarity about the role of all units in the structure.

Of course it is easy to critique the work of others, especially if one does not fully understand it!  But, my critique is meant to be a compliment: it is one of the better articles on design principles that I have read.

They go on to list some features of good design principles

1. They are grounded in facts

2. They pass the “dog food” test: meaning that they are not so general that they could equally apply to a dog food company (unless of course you are a dog food company!)

3. They are brief not more than 6 or 7 …. well occasionally stretching to 10.

Here again, I like the thoughts but feel there is more to say.  For example, design principles should constrain the design options: they should articulate a choice between alternatives that are reasonable.   So the negative of the design principle should make sense as well.  Let me illustrate this with an example from their text.

“ensure that how we go to market makes it easy for our distributors to do business with us”

The negative of this statement “ensure that how we go to market makes it difficult ….” makes no sense.  So what is a better statement?

“ensure that it is easier for our distributors to do business with us than with our competitors even if we need to add cost and investment in this area”

The negative here is more complex.  It could be “easier than we are now, but not as good as competitor A” or “.. only if it does not add cost or investment” or …. In other words, the negative has some meaning.

I am confident that this rewriting of the statement is what Bain consultants meant by the first statement … but it is always good to spell out the trade offs you are making and the level of ambition that you have.

Writing this blog makes me think that I should say more on design principles.  You can access what I have already said by clicking on “design principles” in the category navigation on the right or by following these two links
– Understanding design principles
– Design Principles: How do you get good ones

Posted in Design principles | Tagged , , , , , , | 1 Comment

Another operating model canvas

Posted on June 2, 2015 by Andrew Campbell

I came across the following article on a site called “Community” run by a consulting company called Dynalucid.  It uses the business model canvas as a starting point for creating an operating model canvas for a function like IT.  My version of an operating model canvas focuses just on the back end of the business model canvas.  But, as I reflected on this article, I realised that, when we do an operating model for a function, we need to think about the whole business model of the function.

Thank you to jordan.willms@gmail.com for alerting me to this article, and apologies to Dynalucid for copying it.

“An IT Operating Model can be defined as “the rationale of how the IT function harnesses processes, people, partners and assets in order to build a capability and culture that can create, communicate and deliver value to meet the needs of employees, partners and customers”.

The Operating Model and its capability is a system with every element impacting the other and therefore only truly makes sense as a whole. Visualisation enables simplification of the complexity. This opens up new insights, shared understanding and robust agreed design decisions that can be taken forward into transition and transformation.

The Operating Model Canvas is the Dynalucid operating model visualisation tool that enables Clients to describe, define, design, iterate and innovate around their current and future IT Operating Models.

Slide1

Top of Canvas

Across the top of the Canvas, we set out the purpose and vision for the Operating Model. This is the overarching ‘due north’ which informs the selection and configuration of all the other Operating Model elements.

Right Side of Canvas

The right hand side of the Canvas is focused on customers and the value proposition to them.

This is where insight, understanding and empathy with our customers (both internal and external) is investigated to understand existing communications, channels and relationships.

it is then possible to add the value adding products and services required to meet the specific needs of each segment.

As a result of delivering value, budget or revenue streams are returned which are also captured on the right hand side of the model.

Left Side of Canvas

On the left hand side of the Canvas is set out the capability required to create the specified value. Explored in more detail, one can see that capability is like an eco system made up of many interconnected elements such as roles, data, people and skills.

The three macro elements that make up capability are the internal function resources and assets, the key processes and IT partners.

All this capability requires investment, and the left hand side of the model is where major cost elements such are salaries and 3rd party contracts aree captured.

Foundation of Canvas

The foundation of the Canvas and of every Operating Model is passion and culture. Companies with well-aligned cultures are six times more successful as noted by Jim Collins in his bestselling ‘Good to Great’. The fact is that one can have the best processes and people with all the right skills but, without an enabling culture, this will not translate into the desired value.”

A couple of comments.   Putting “capabilities” in as a requirement before “value adding products and services” is attractive …. but, it raises all the issues I have with using capabilities and capability maps as a tool.   I prefer putting “processes” here …. what are the processes needed to deliver the “value adding products and services”.  Then the boxes supporting processes will be a range of things: the ILOS of my PILOS model.

I like “Vision and Purpose” as an addition as well as “Culture and Passion” as a foundation thought.  I also like the 3D design – treating costs and revenues as elements that run through the whole.    Of course, most internal functions do not have revenues, so maybe it should be “costs” and “KPIs” or just KPIs, if cost is one KPI!

Posted in OM frameworks, Operating Model Canvas | Tagged , , , , | 2 Comments

Wilson Perumal’s operating model?

Posted on May 19, 2015 by Andrew Campbell

If you have been reading this blog you will know that my definition of an operation model is PILOS – processes needed to execute the strategy, information systems needed to support the processes, locations and buildings to house the processes, organisation and people to do the work of the processes (I include goverance and culture under organisation) and suppliers and business partners needed to support the processes.

So I was interested to come across a similar definition from Wilson Perumal (apologies for edits).  Not sure about the visual!

“An operating model is  the coordinated collection of assets & capabilities, governance, vendors & partners, organization structures, processes and technology enablers a company uses to deliver its strategy.  Each of the 6 Operating Model Design Elements cover unique areas of a company’s operations, but must be considered together when designing an operating model.

Operating Model Design Elements

Assets & Capabilities

Company facilities (offices, factories/plants, warehouses, research labs, distribution centers, etc) that are owned/leased; patents and intellectual property used to generate revenue or manage operations; core, end-to-end capabilities required to succeed

Governance

Where & how operating decisions are made and who has the authority to make them; central v. local ownership; corporate policies establishing expectations for conduct and behaviors; audit & assessment functions ensuring compliance; performance reporting

Vendors & Partners

Skills, abilities and capabilities the company relies on outsiders to provide; insourcing v. outsourcing; supply chain partners used to provide raw materials and distribute finished goods

Organization Structures

Operating & reporting structures needed to deliver the strategy; assignments of roles, responsibilities and expectations to each employee; skills & abilities for employees required for each role; relationships between departments/functions/subsidiaries

Processes

Business and production processes used to manage the company and generate revenue; process design principles; metrics to monitor and ensure process control & performance

Technology Enablers

Internal technology capabilities needed to manage the business or generate revenue

Taken as a group, the 6 Operating Model Design Elements cover all aspects of a firm’s internal strategy and providing a robust means of linking its market strategy and its ability to execute. We have found that our clearer operating model definition not only helps companies design better operating models, but working through the 6 Operating Model Design Elements is also a useful tool in diagnosing operating model misalignment contributing to poor performance.”

Some quick comments:

1. Brand does not appear – but probably a part of “assets”.  It does not appear in PILOS either, and this is something I have been thinking about.

2.  Capabilities as separate from processes or people seems odd to me.  I prefer to integrate the concept of capability and process.   For example if a step in the process is “buy ingredients” then you need a capability “buy appropriate ingredients at good prices”.  I don’t see the benefit of separating these ideas.

3.  My SPACI model under organisation includes Structure, People, Accoutabilities and governance, Culture and Incentives.  The above model does not give much emphasis to Culture and Incentives.  The latter is definitely something you can design … I am never sure whether Culture is an input or an output.

4. Capabilities appears again under the last item “Technology enablers” which is a little confusing.  Why are Assets not Asset Enablers?

But, like all these frameworks, a useful contribution.

Posted in OM frameworks, Operating Model Canvas | Tagged , , , , | 2 Comments

Working on an operating model

Posted on May 6, 2015 by Andrew Campbell

In a recent LinkedIn discussion, Don Hutcheson raised the question of the role of organisation charts in Enterprise Architecture (which for me is just operating model work!)

There were some interesting responses, which stimulated me to add this post (edited here a little).

“I have been thinking about the models and frameworks and visuals that are most helpful to EA (or operating model) work.

1. The stakeholder map is my starting point. The map should explain what the “offer” is to each stakeholder group.

2. The next model I use is a process map (or value chain map or capability chain map). There are lots of terms for this tool that lays out the work that needs to be done.

3. The next is the organisation chart – although I prefer to turn the typical organisation chart into an organisation model – https://www.ashridge.org.uk/getmedia/e9dbb283-5a04-4079-981a-bda9a4fa9ffa/AOD_Organisation-Charts.pdf  Here I agree with Bruce that a 7S or Star Model approach is richer than a structure approach. The key however is to have a way of laying out the relationships between boxes in the chart, which is what the organisation modelling tool does.

4. I am currently working on a tool that combines the process map with the organisation chart to help highlight processes that cross organisation boundaries, areas where there are difficult links and parts of the organisation that need some separation from the whole

5. Next comes the software applications architecture (I am not sure I have a good solution for this)

6. Next comes the geographic map showing where everyone is located, what sort of properties they are located in and how different locations are linked.

7. Finally there is tool for identifying tricky stakeholder relationships and the type of agreements that are needed with each stakeholder type (but I do not have a good solution for this yet either)

I am working on these issues for my course Designing Operating Models http://www.ashridge.org.uk/dom. If anyone has contributions to make, you can come and help me teach the course … or I can credit your ideas, when I teach them.”

So let me encourage you to contribute here or email me directly at Ashridge.

Posted in Design tools | Tagged , , , , , , , , , , | 2 Comments

Why Design Thinking helps Operating Model work

Posted on April 11, 2015 by Andrew Campbell

I have been reading Jeane Lidtka’s book “Designing for Growth” and wanted to share some of her insights.   I also did Jeane’s on-line course – a Darden course with Coursera – which I highly recommend (well, I did not complete it .. but got a lot of value from it).

The trigger for work on operating models often comes from finance … the numbers are not good enough … or from lean analysis … there is waste in the processes … or from customers … they are complaining.   The mind set that these starting points create is a “fix it” mind set rather than a possibilities mind set.   The work starts out as a problem solving project rather than a opportunity exploration project.

This framing of operating model work is often reinforced by the tools that are used: value chain mapping, capability maps, process maps, organisation charts, etc.   These encourage an analytical orientation rather than a creative orientation.

Design thinking helps add an opportunity and creative orientation.   Here is how I think it does this.

  1. Design thinking starts with a search for deep understanding and inspiration. Instead of a value chain analysis, a designer would talk to customers and talk to employees and try to understand both the challenge and the opportunity at an emotional level as well as a financial or performance level.   Of course value chain mapping is useful, but it is more useful if accompanied by deep understanding.
  2. Designers collect anecdotes and stories and construct profiles of individuals more than they collect averages and aggregates or fill out spread sheets. They like to meet people, touch things, visit places rather than read reports.   Averages have their place but so do anecdotes.
  3. Designers are comfortable with prototypes and experiments.   They don’t need a business case to try something. They expect failure, knowing they will learn something that will help them later on.
  4. Designers are reaching for beauty as well as efficiency and effectiveness. They want to create something that touches the people who are part of it.  As Jeane’s design process points out, solutions should “wow” as well as “work”.
  5. Designers embrace uncertainty and insufficient information.   They look within themselves to fill the gaps in their knowledge: the unknown, unknowns.
  6. Designers do stuff more than they talk about stuff: they like to start on solutions early in the process.  They prefer prototypes to meetings.
  7. Designers like to visualize and to use visualisation as an aid to their thinking. This is not spread sheet visualisation. It is about “thinking with the hand as much as the mind”. It is about drawing something and sticking it on the wall.

My daughter is studying photography. I noted that her work book is as full of projects that did not work out as it is full of successful shoots.   The lessons she is learning from the failed projects are just as useful as those from the successful ones.   The mind set of ‘analyse the situation until you know what the right answer is’ is absent. She is encouraged to be inspired, to try things and to learn.

Of course, when we are doing operating model design work, we can’t experiment without concern about the cost, and we do have to come up with a solution that works.   But we are more likely to do this, if we approach the work as a design challenge as well as an engineering one.

Posted in Design tools | Tagged , , , , | Leave a comment

What is the right term for operational excellence?

Posted on March 18, 2015 by Andrew Campbell

I came across some interesting data from a report by PEX .   The PEX researchers spoke to 400 people in process or operational improvement rolls in July 2014.  One of the questions they asked was about terminology.  What is the term used in your organisation to describe operational excellence.   See answer below.  The measurement is % of people who mentioned a term … so I guess it should add up to 100%.  Sorry about the quality of the picture.

Slide1

Does this mean that we are all one big happy family despite calling ourselves by different names – no chance.   What it means is that this is a young, emerging field where there are lots of new ideas and tools and methods.  Along with these come new names and terms.  Until the innovation starts to slow down, I don’t see the current situation changing much …. and I don’t want the innovation to slow down.

So, I guess, we just need to be able to speak multiple languages (lean, agile, transformation, world class, business model, total quality, operating model, etc ) to be effective .

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

Capability chain – a combination of value chain and capability map

Posted on March 12, 2015 by Andrew Campbell

Those of you who have been reading my blog will know that I have been worrying away at the concept of a capability map.  Initially, as a business strategist, I could not really see the point of these time consuming maps, some of which extend to many pages of A3 sized paper.  They seemed to me to be second class organisation charts.  Second class because they defined the activities but not who reports to whom.

Over time I have understood more about capability maps and have almost arrived at a comfortable relationship with them.   I say almost because I am still a little skeptical.  So it is in this frame of mind that I am always on the look out for others worrying about the same issue.

William Ulrich and Jim Ryhne recently addressed this issue in an article published on the BA Institute website (standing for Business Architecture Institute).  In it they critique “business capability architecture”.

“Business Capability Architecture is positioned as a framework for interpreting and enabling business strategy and business initiatives. We believe that the concept of value delivery should be elaborated using value streams and value networks. These value oriented perspectives are linked to capabilities to articulate how those capabilities are used to deliver stakeholder value. If this value oriented perspective is ignored, the ability to leverage business capabilities is significantly sub-optimized.”

In other words they are saying that capability maps are more useful if they are integrated with value stream or value chain maps.

They give an example of what they unhelpfully call a Value Stream/Capability Cross-mapping Blueprint.

Slide2

I think I would call this a “capability chain” or “capability stream”: the mix between a value chain and a capability map.  Its strength is that it lays out the capabilities in the format of a value chain, similar to my idea in my previous post.  In fact I first coined the term “capability chain” in a session together with some PA Consultants at Henley Business School.  I am still not entirely sure whether laying the process out in this way is any more helpful than the normal ways of laying out value chains or value streams.  But I am sure that this puts capability mapping in its proper place – as a tool you use after you have done value chain mapping.

As the authors comment “Unless value streams are incorporated and tied to strategy, it will be difficult to see which capabilities are more important and which capabilities are less important in realizing a strategic objective. That this perspective is critical has been unquestioned since the publication of Porter’s work on competitive strategy.”

Posted in Capabilities, Value chain | 3 Comments