In the last chapter of "Workplace management," Taichi Ohno wrote that the standard time should be the shortest time. Typical industrial engineering adds many allowances instead of fixing problems.
Ohno is saying in the following way.
"Speaking of standards, time study is another thing everyone gets wrong. For example, people measure ten repetitions of a task and use the average value. I think this is the worst thing you could do. If you are watching a person doing something ten times, and if they are doing it differently each time, you should immediately correct them. Instead, people think, "That's not my concern. I just learned the symbols and how to use a stopwatch and I write things down. And after measuring ten repetitions, the standard time will be set as the average of the ten times." If you are going to take ten such unreliable measurements, you should choose the shortest time. Some say that is harsh, but what is harsh about this? The shortest time is the easiest method."
Ohno continues his explanation about why standard time should be the shortest time. It is one of the most crucial chapters in this book, and I highly recommend to re-read this chapter.
Ohno defines the minimum cycle time as the standard time. Any time above the standard time is called fluctuation or Mura. Mura's correct understanding is not just variation. It is a variation from the standard or the best condition. The critical question here is who is responsible for the fluctuation. Traditional thinking is saying operators should deal with variations since we are using the average time and allowances. Ohno is saying fluctuations are not the operators' responsibility. It belongs to the team leader (frontline management) and the help chain. The team leader should help and then eliminate the cause of variations. For example, if an operator is tired, the operator should call the team leader to rest.
There is still doubt inside this community about using the lowest time as standard time. These people develop new concepts like target cycle time or 20% below takt time rules ignoring Ohno's message. For those people, I usually use the clock to explain why their thoughts are wrong. For example, the second hand of a clock has 60 seconds standard time. We probably agree with this statement. Are that 60 seconds, average cycle time, or should we give some 20% margin of error? Some theorists will argue that there is a variance of microseconds, and it is average. But the allowed variations in operations are not that level. It is like 54 – 66 seconds are allowed. If there is such a strange device, we will immediately fix it. Such simple thoughts are the foundations of TPS. And to create the shortest time as standard condition, I recommend thinking about every input of man, machine, material, and method to have standard points – lines – area.
Another excuse for not using the lowest time as standard time is being "kind" to the operator. Ohno is not saying be strict to the operators. Set the best method as the standard. If any deviation happens, pull the andon, and the team leader immediately responds to help. This way, the operator doesn't waste time dealing with the problem. The responded team leader must work on that problem and resolving it. Otherwise, it has to deal with that exact problem again and again and waste its time. Those systems keep average cycle times and 20% rules, stubbornly holding the same issues inside a process. Which methodology is kinder to people? The truth is that the average or 20% rules are easy for the management and engineering for a short time. They push deviations to the shop floor, not necessarily defining or managing the points – lines – areas. The cost will increase long term since every source of variations leads to the adjustment of cycle time to expand.
The lowest time as standard time leads to Kaizen. When I implement a line with the shortest time as standard time, the line will explode with problems. For example, an operator might complain that the rack is too high. That "complain" is not a complaint. It is a hint to Kaizen. Immediately, I start working on the rack. I leave some materials near the workstation while working on the rack. Once build, I ask the operator to try and provide feedback. Almost every takt time, I get feedback from the line if I made good Kaizen or not. The objective of TPS is not necessarily to keep management & engineering comfortable. It is the opposite. It is to keep a sense of urgency so that we have to follow the standard or improve it. If a problem happens, help and then solve it; otherwise, it will happen again and stop the entire operations. This is why I firmly state that the starting point of Kaizen is to set the shortest time as standard time.