Mapping the competitive landscape

A business is a living thing.  It consists of a network of people, a mass of different activities, practices and data along with reserves of capital including financial, physical, human and social.  It consumes, it produces, it grows and it dies.  We often attempt to understand a business through the use of box and wire diagrams whether business process maps or IT systems diagrams or … choose your poison. However, these diagrams whilst great at making connections between things do little to help us determine user needs, how things change and how we should manage them.

To make matters worse, the box and wire diagrams often have implicit information embedded in the terms and acronyms we use.  This makes them unintelligible to the uninitiated. Try asking someone from the business to decipher a diagram full of labels such as ERPM, BIM, PIMS and task management modules.  Or ask your long suffering IT folk to make sense of Ship Call Reports, Energy Balance, GAP adjustments or Peaking Inventory Projections.  Alas, within most organisations you have disparate groups with their own worldview based upon box and wire diagrams with their own terminology.  Is it any wonder that discussions between those groups are rife with alignment and translation issues?

To emphasise this point, I’m going to use a simple box and wire diagram (figure 1) for an unspecified process from which I have removed the terms - only some of you would have known what they meant anyway.  I’ll ask a few basic questions of the reader.

Figure 1 – A box and wire diagram of an unknown process

Questions 

1. Which components in the above diagram identify user needs and whatever is produced?
2. Component E was outsourced to a third party resulting in a high cost overrun and poor delivery. 
• Can you give an explanation as to why?
• Would you recommend the outsourcing of component F?
3. It has been recommended that A, B, C and F use a cloud provider. Do you agree?
4. It has been recommended we adopt Six Sigma throughout the project. Do you agree?

I’ll now convert the above diagram into a map.  This is simply done by first arranging the items in order of a value chain from the visible user needs to the invisible components consumed and them mapping each component on how evolved it is.  See Figure 2.

Figure 2 – A Map view of an unknown process

From the above it becomes far easier to answer the above questions.

Answers

1. Components B and C are high up the value chain and likely to represent the actual user need and what is produced from the process.
2. On outsourcing
• Component E is at an early state of evolution and hence is unlikely to be suitable for outsourcing as no economies of scale or standardisation exists. 
• Component F being more of a commodity is highly suitable for outsourcing.
3. Component A, C and F being more of a commodity are likely to be suitable for provision by a cloud provider. Component B is not.
4. The process consists of multiple components at different stages of evolution and hence a one size fits all method is inappropriate. In this case: -
• Components B & E are likely to be suitable for Agile, In-House development.
• Components A, C and F are likely to be suitable for highly structured methods such as Six Sigma and use of outsourcing.
• Component D is suitable for using an off the shelf product.

The diagrams (the box and wire versus the map) are of the same process with no labels but the mapping view provides far more situational awareness and enables conversations on what matters and how things should be treated. Of course, adding labels adds further context as more data is always better.

A case in point is when you add data on competitors' value chains. For example figure 3 is a comparison between one company (let us say you, represented by vertical blue lines) and competitors (represented by horizontal red ones).

Figure 3 - Box and Wire comparison of competitors

Now at best, from the diagram above you can see that you're doing something called component B which the competitors are not. Maybe it's a differential, maybe it's a wasted activity? It is difficult to tell.

Now if you map both and compare (see figure 4) then a different story emerges.

Figure 4 - Mapping comparison of competitors

From the above, it is clear that component B is something novel and likely to be a potential differential. But equally there is differences in components D, E, F.  In component D you seem to be using a product whereas competitors are custom building systems - this is likely to be an area of efficiency for you. But in components E and F then you seem to be behind the game and likely to be creating a source of inefficiency.

With a mapping view, I can :-

1. Determine what is likely to be suitable for outsourcing or insourcing
2. Determine what should be built with agile, or bought off the shelf or driven by a six sigma approach
3. Identify areas of efficiency, inefficiency and differential and what is suitable for cloud.

The above however is simply standard housekeeping stuff and the real power of mapping isn’t alignment and management methods but in understanding economic patterns and strategic gameplay. Mapping provides a mechanism for common understanding in an organisation and learning of such patterns.

I've been using mapping for over eight years (since the first maps of Fotango) with exceptional success and during that time I've discovered and tested many different economic and strategic patterns. At its heart, mapping simply provides a view of the chess board - you still have to learn how to play the game and unfortunately I can't condense eight years of experience into a single blog post.

However, I do run one day workshops for the members of LEF (a private research group of large companies) and occasionally I talk about these methods in public.  An hour long video covering some of the topics can be found here and also, for those willing for a more deeper dive then this uncompleted (but useful) series of post will help.  You can always come and find me at OSCON (the greatest conference in the world) which is the one place I almost always attend or alternatively you can search through this blog.

To give you an idea of the scope of mapping, the workshops cover such themes as -

• Beginner - value chains, principles of evolution, the practice of mapping, changing characteristics, management methods, comparison to competitors and basic housekeeping.
• Novice - co-evolution, inertia, componentisation, creative destruction, manipulation of markets and exploiting economic cycles (peace, war, wonder)
• Apprentice - Open as a weapon, constraints, different forms of ecosystems,  exploitation of ecosystems, the role of marketing, organisational evolution, culture vs strategy and structure.
• Practitioner - Dark arts, evolutionary flow, profiles, common strategic plays and counter plays, gameplay, prediction and weak signals.

... beyond this, it boils down to experience and developing lots of it. However, that's the point of this post, mapping is not a discrete thing but a journey just like learning to play a game of chess. Of course,  as with chess it always helps to start by looking at the board first! Also, as with chess then I'm afraid you have to learn to play the game and you can't farm this off to someone else.

Strategic gameplay is complex and it doesn't fit into a nice 2x2 diagram. There is a great wealth of patterns to be learnt, understood and applied if you can embrace the complexity of what is competition or as I like to call it, organisational warfare.  As with any competitive engagement, maps and situational awareness are critical to the outcome.

Once you start to get to grips with this, how to manage an environment, how to exploit it, how to deal with uncertainty and the arsenal of tools you can deploy then you can learn to play a good game.

Oh, and before you say 'it's an IT' thing and that you work in business ... well, I developed the technique when I was CEO of a Canon subsidiary to cope with competition and the world of change that I was experiencing.  I happen to use examples of IT companies because they generally seem to play a better game. These days I use the techniques in a wide variety of industries and governments from giants to start-ups.

As a rule of thumb, many organisations I meet have two apparent problems which threaten their future livelihood. The first problem is called 'IT' and it often suffers from a range of difficulties from single size methods to excessive reliance on outsourcing to alignment issues. The second and usually more fatal problem is called 'The Business' and it often suffers from a range of difficulties from inertia to poor situational awareness to lack of strategic gameplay to inability to identify value. Alas, there seems to exist a tendency to always point the finger at 'IT'.

In reality the problem is the division itself, an artificial construct of how we organise by type. In the past, I've found the way of solving this problem was to get rid of the construct but that's another post for another day.