Welcome back this series about organisational problem-solving. In this second part we will examine a simple problem, that is built on a classic illustration of the 5 Whys technique from the first book about the Toyota Production System [1], but in this series extended, to be able to deepen our problem-solving understanding.
When we have a problem, we must first, as stated before, always ask why we have the problem, otherwise we can never reach the root cause(s) to the problem. The reason for this is that we seldom have the root cause(s) directly, meaning that our problem is only included in one or more chains of symptoms that originate from the root cause(s). If we only try to solve the problem directly, what to do, it means that we are trying to fix a symptom in the part of the system where we found the problem. And in a complex system, like our organisation, this will inevitably lead to sub-optimisation of the whole due to the parts’ interdependencies, which is very different from production processes, where sub-optimisation easier can be avoided*. Unfortunately, there are many techniques that try to solve a problem directly, and one of the more famous ones is the SCQA (Situation – Complication – Question – Answer) technique, but any technique that does not ask why we have a problem in an organisation, will sub-optimise. The reason for sub-optimisation is simple; the problem must be a symptom, because if the problem was an organizational root cause, it is just to dissolve it, and the SCQA technique or any other problem-solving technique were never needed or even considered in the first place. And if we look into complexity theory it states; any intervention with a complex system generates unintended consequences. This means that a symptom is not only insolvable, it creates unintended consequences too, which really explains the term “sub-optimisation”.
Generally speaking, since problem-solving are within our nature, it is very easy to start to solve a problem before asking why, or asking why too few times and then never have the chance to reach the root cause(s).
As stated earlier in the series, we sometimes need to take care also of what to do if we for example got oil on the floor, or people have been sick of stress. And if there is some severe accident, we of course take care about the what first of all. The emphasize on the why first is only because it is too easy to do the what early in the process, and then forget to ask why.
A fuse blew – an example [1]
A machine stops because the fuse blew. The engineer changes the fuse and reports to the supplier delivering all their material, that they are selling lousy fuses, and they need to make them better by starting to do an analysis to find the root cause(s), otherwise no more fuses will be bought. The engineer starts up the machine, but the same scenario happens again within 5 seconds. The engineer starts to think that maybe it is not the fuse and goes to the machine, but cannot see anything wrong and changes the fuse again, now angrier at the supplier. Same scenario again, and so far, it looks like this:
The engineer now looks more thoroughly at the machine and finds out that there is too little oil for lubrication of a bearing. Already stressed about the machine standing still, the supplier is contacted again about their lousy oil, they should do another analysis. The engineer then put on some more oil to lubricate the pump, changes the fuse, and then starts the machine again. Since the machine does not stop directly, the engineer is happy and starts some other work. But, after one hour the machine stops again. We have the following scenario so far:
The engineer realises that there must something else that is wrong with the machine and starts to check where the oil comes from, which is from a pump that apparently is generating too little oil. Once again, the supplier is contacted, this time about their lousy pump and that they need to do another analysis to find other root cause(s). The pump is changed, the bearing lubricated, the fuse is changed and the machine is started and is not stopping on the whole day. The engineer is happy and now sure that this was the problem. But after one month the machine stops again, and more thorough this time, the engineer notices that the pump has worn shaft, he calls the supplier and complain about the bad quality of the shaft of the pump and that they should be happy about this information, changes the pump and the fuse, puts on some oil on the bearing and starts the machine again. After another month the machine stops again. We so far have the following scenario:
The engineer digs deeper into the problem with the pump and realises that the pump gets a worn shaft because scrap metal comes into the pump. For the fourth time, the engineer requires that the supplier makes an analysis, this time on their scrap metal prevention system, because the engineer has followed the maintenance instructions properly. The engineer changes the scrap metal prevention system, changes the pump and the fuse, lubricate the bearing and restarts the machine. We got the following total scenario for the problem with the machine:
The engineer is happy since the problem to why the machine stopped has been found; it was due to the scrap metal prevention system.
This was all for this blog post, and in the next blog post in this series, we will continue at the supplier, now having many root causes analyses to take care of.
C u then.
*In Lean production, the processes are situated in a long chain with clearly specified handovers at every takt time, which means that a process can, due to the repetitions, optimise itself as long as the handover specification is followed. See also this blog post for a detailed explanation of problem-solving in Lean Production.
References:
[1] Ohno, Taiichi, Toyota production system: beyond large-scale production. Portland, Or: Productivity Press. ISBN 0-915299-14-3.