Without naming names, I'm going to talk about a rather ridiculous situation that helps highlight the difference between efficiency vs effectiveness and why flow isn't enough. It concerns computing.
In this company, they have their own data centre which is full of custom built racks. These racks exist because that's the way they have done it but rather than being the standard 19" rack, these are a non standard sized and turn out to be slightly smaller. This unfortunately means that normal servers can't be racked but nevertheless the company has a solution. They buy relatively standard servers, they remove the shell and drill new holes into the body in order to fit it into the rack. Now users in the company can request compute resource but what's of interest here is the issue of when capacity is nearly reached. An order is made, new servers arrive in goods in, the shells are removed and new holes are drilled to modify the servers and then they are mounted. I've drawn the process in figure 1.
Figure 1
Now looking at this process, we find the mechanism of removing the shell and drilling holes (i.e. Modify) to be quite time consuming. It is also occasionally imprecise causing issues mounting the servers and waste. It is also bottlenecked by there being a limited number of people who are any good at doing this. Bizarrely metalwork is actually not a core competency of system admins. So we can propose any numbers of mechanisms to improve the efficiency of this process even to the point of automation with robotics if the scale demands it.
However, I want to take a mapping view and show the same flow. When using maps, on the evolution axis then I tend to use activities (i.e. genesis to commodity) but do remember you can map practices (novel, emerging, good, best) and data (un-modelled, divergent, convergent, modelled) on the same axis. All of these components share the same characteristic changes as they evolve.
In our process then order components and goods-in are fairly widely understood and established. The modify server (despite there being a guide written on how to do this) is fairly unusual and a newly employed system admin will probably have little idea on how to do this. Of course, even racking a modified server is reasonably straightforward. Hence I've provided a rough map of the above in figure 2. However I've also marked on a view as to where compute, racks and the practice of mounting a server are in the market.
Figure 2
What should be obvious is that we're trying to make Flow 1 efficient when it is in fact an ineffective process. The only reason why we're doing this is because of our use of custom built racks in a world where racks are standardised. If we use standard racks then the modification process goes away and mounting becomes vastly more standard. However, if we look up the value chain then compute has become far more of a utility and if we take advantage of this then flow 1 is simply replaced by an API call (flow 2).
In the case of the above, the company shouldn't even own compute but should be using a public cloud service. It certainly shouldn't be investing in robotics to automate a process of customising standard servers to fit into custom built racks in order to make an ineffective system more efficient.
A map gives you two main axis. The first is position based upon a chain of needs relative to an anchor of visible user need. The second is movement (i.e. how things change, evolution). Within maps you have flows but mapping makes it much more obvious when you're trying to optimise and make efficient a highly ineffective flow. Of course, many of you are familiar with compute and would claim it would be obvious not to do this. But if I made a map of World Perception Systems or a Trading Ledger then you might not be so familiar. In which case, I suspect you might fall into the trap of optimising and making more efficient the wrong flow. I suspect this because I see it all the time. Endless efforts in corporations to make the wrong thing more efficient.
You can't also just say, well that company should be asking - "how does this process help us?" - as the executive don't understand the inner workings of systems and the people involved in the process believe it's the right way. They're proud of their environment and have all the usual symbols of inertia. It's not that they're daft but instead they believe that what they're doing is right - it's what they've always done and they've invested considerable personal time and effort making it better. Of course, making it more efficient would help the company hence investing in robotic automation sounds "sensible". I can easily build a case for this as daft as it sounds (and it is daft).
Showing them a map, even with just pointing out the change if you start using more commodity components such as standard racks (see figure 3) rather than focusing on making an existing process efficient exposes the assumptions and workings of a company.
Figure 3.
Once you've explained that, it becomes far easier for people to make the leap towards not having racks at all (i.e. flow 2). I mention this because people often tell me about the importance of removing bottlenecks and ensuring efficient flow. I happen to think such techniques for value stream analysis are reasonably important but you have to be really careful that you're not making the wrong thing efficient. It's not enough to just look at flow (as in figure 1), you need to consider how evolved the components are (e.g. fig 2 and 3).
Which is why I always recommend you start with a map.
You can't also just say, well that company should be asking - "how does this process help us?" - as the executive don't understand the inner workings of systems and the people involved in the process believe it's the right way. They're proud of their environment and have all the usual symbols of inertia. It's not that they're daft but instead they believe that what they're doing is right - it's what they've always done and they've invested considerable personal time and effort making it better. Of course, making it more efficient would help the company hence investing in robotic automation sounds "sensible". I can easily build a case for this as daft as it sounds (and it is daft).
Showing them a map, even with just pointing out the change if you start using more commodity components such as standard racks (see figure 3) rather than focusing on making an existing process efficient exposes the assumptions and workings of a company.
Figure 3.
Once you've explained that, it becomes far easier for people to make the leap towards not having racks at all (i.e. flow 2). I mention this because people often tell me about the importance of removing bottlenecks and ensuring efficient flow. I happen to think such techniques for value stream analysis are reasonably important but you have to be really careful that you're not making the wrong thing efficient. It's not enough to just look at flow (as in figure 1), you need to consider how evolved the components are (e.g. fig 2 and 3).
Which is why I always recommend you start with a map.