Given some of the comments on my last post on "Why Agile, Lean and Six Sigma must die" ... I thought I'd take some time to clear up another misunderstanding in the difference between position, flow and movement.
Let us assume you've examined a line of business, starting from the point of user needs and developed a value chain. I'll assume you've also mapped this over evolution. Beyond the obvious of breaking down a system into components and the interfaces between them then there are three things to consider.
Position : the position of components simply relates to how things are connected and how visible they are to the user need. The value chain itself is a chain of needs i.e. this needs that etc. At the top of the value chain these needs are exposed as meeting user needs (i.e. customers) and can often be expressed in terms of the customer journey. This doesn't mean the lower components aren't essential but a user who wants a cup of tea doesn't care about the power provider you use to boil the water. They only care about a piping hot cup of tea.
Flow : whenever you look at a map (an example is provided in figures 1 & 2) then there are multiple flows within the value chain. These flow can cover things such as information, risk, finance and materials. Sometimes one flow is more viable than another and financial models based upon flow can be developed (see figure 3). Sometimes a flow may be inefficient because it'll have bottlenecks and improvements can be made. There's all sorts of important things to be consider from inventory to capacity to variability and time.
Figure 1 - A flow within a value chain (a TV company)
Figure 2 - Another flow within a value chain (a TV company)
Figure 3 - Analysis of a flow.
Movement : Understanding position and flow is a good start but unfortunately value chains aren't static, they evolve. Fortunately the process of evolution is fairly well defined across activities, practices, data and knowledge and there are many common economic patterns, weak signals and gameplay which can be used to anticipate and manage this. There's however little point in understanding the value chain and managing the flow efficiently if you are treating most of the components as custom built when the market treats them as commodity. You have to accept that everything in your value chain will evolve (i.e. move across the map) and therefore you might be efficiently managing the flow in your value chain but at the same time being ineffective because you're treating components in the wrong way.
Understanding position and flow is critical for efficient provision of an in-situ situation however understanding movement and position is critical for strategic gameplay, anticipation and effectiveness.
To give an example of this, I'll use the box and wire diagram from the previous post (figure 4). Do remember that box and wire diagrams (IT systems diagrams, Business Process Maps, Value Stream Maps etc) all have their purpose but they only show you connectedness of components (not necessarily even position relative to the user) and can only be used to analyse flow.
Figure 4 - A typical box and wire
Looking at the box and wire above. The questions you need to ask are :-
Looking at the box and wire above. The questions you need to ask are :-
a) I outsourced B and it was a disaster. Why was it a disaster?
b) Should I outsource A?
c) What components are most directly visible to its consumer?
d) What methods (i.e. doctrine) should I use for each component? Agile, Six Sigma or Lean?
Now, whilst I can't answer these question, I can examine different flows in the box and wire (e.g. the one I've highlighted in blue is C, F, D, A). I can look at it for bottlenecks and mechanisms to improve efficiency and certainly if I have multiple box and wire diagrams then I can look for duplication. But of course, I don't know whether one of those components is representing the visible user need and hence I don't know the travel of flow towards the user unless I add arrows. I also don't know how evolved those components are i.e. if the duplicated components are suitable for provision as platform components?
Exactly the same diagram is provided in figure 5 below but in this case I've added movement represented by an evolution axis. I can now not only examine the flow but answer all the above questions. I can even anticipate how things will change (I've added some lines for competition effects but in reality all components are likely to be moving).
Figure 5 - A map of the same process
With multiple maps I can remove bias in treatment (people custom building what is a commodity) and find not only duplication but identify those components suitable for provision as a platform.
Furthermore using the above map I can identify where we will have inertia, potential threats from disruption that can be anticipated, co-evolution of practice and even repeatable mechanisms for how I can manipulate the market (i.e. organisational learning). I can determine the appropriate methods both project management and purchasing and even determine appropriate structure. See the previous post for help on some basics or this post for a general introduction to the technique.
Hence with the above map, I can anticipate a future state (figure 6).
Figure 6 - Future State
Hopefully I won't have done the daft thing of outsourcing B but instead I will have moved from using an Agile approach to using Lean to build it (assuming I'm the one building). As for component C, then I'd probably be looking to build that as a utility service for others (ideally with a six sigma style approach) or use some sort of cloud service. With component F then I'd be anticipating to outsource it along with the hopefully already outsourced A.
I still have the same flow C, F, D, A (along with the other flows in the diagram) but the characteristics and the manner in which this flow is provided has evolved. If I'm stuck making the flow efficient using C, F, D all as products (as it used to be) then as efficient as I am, I'm likely to be outcompeted by the market. I can also see from the map that I don't really have anything differentiating me from others, so I'll probably be taking a few gambles to create components that meet others needs built on the components that I already have.
Gamble? Did I say gamble? Yes ... alas with a map, there are some things you can plan but a lot of spaces in which you have to experiment. Remember that evolution axis is determined from ubiquity vs certainty and the uncharted spaces are not only rare ... wait for it ... they're uncertain (see figure 7). Of course, that doesn't mean we can't mark on a map that we suspect something is over there in the uncharted space (a gut feel, an intuition etc). We might even give it a name, we just don't know what it really is yet or even if it'll be successful. Of course, if it is then over time it'll become more defined, it'll become more certain ... you get the picture.
Figure 7 - Plan vs Experiment.
Anyway, the point of this post is rather simple. Position and Flow can only get you so far - even if I've build a customer journey between high level needs. If you really want to learn strategic play and to become efficient and effective then you're going to need to understand Movement (i.e. how things evolve).
Remember ALL maps are imperfect and they are simply communication tools used to describe an environment. They enable collaboration, communication and gameplay but you still have to apply thought. These maps are by no means the ideal way of visualising, they are more like Babylonian clay tablets as opposed to ordinance survey. Mapping business is a field in its infancy but even these are better than no maps.
However, trying to describe an environment based upon position and flow and not allowing for movement prevents you from determining direction and applying any concept of strategic manoeuvring for both yourself and opponents. Unfortunately these box and wire concepts are exactly what most company strategy is built upon normally mixed in with SWOTS, meme copying and other story telling devices.
I cannot emphasise enough how fsck'd your company is if you come up against a player that knows what they're doing when you're trying to use old approaches. I've seen examples of vendors who've taken a beating with Government in the recent past and still haven't clocked why. This is only going to get worse for those companies if they don't adapt, focus on user needs, sell components appropriately and don't try the old "outsource everything" game. I know many departments that are getting better at situational awareness and gameplay. The days of Government being a soft touch are slowly (very slowly) disappearing.