The Effective Use of Simulation with TOC. Part 3 – Predicting Future Bottlenecks
Predicting the future is always a bit dicey, as any weatherman will tell you. But we can usually give the customer a “directionally correct” answer that will help managers make decisions. The effect of a standard “fix” is estimated, usually in terms of a percentage impact improvement. The bottleneck is determined, and engineer running the analysis chooses a fix (speed, downtime, rework, etc.) and then the analysis is run again. In some cases, this process can be automated, and is fairly quick to run. The result of this analysis is an ordered list of workstations that will become bottlenecks in the future, and the number of iterations that it will take to reach the target throughput.
If a particular workstation is predicted to the bottleneck consistently, then we call this workstation a persistent bottleneck and a full time throughput improvement team should be assigned to it. Another possibility is that the bottleneck tends to stay in one area or department. This is often a great time to bring in a lean team to work in this area. They can set up a process to work on improving the performance of these workstations before they become bottlenecks.
One of the problems that this type of analysis can uncover is when the number of iterations to reach the target throughput is exceedingly high. In most of the organizations I worked in, the effective duration to find and fix a particular problem was a week (although it was as small as a shift during launches). If the analysis run above tells the organization that it will take 100’s of iterations to make rate, the implication is that the system will not hit rate for years. If this is true, its time to reevaluate the current strategy. A change to the process may now be evident – adding buffers, a parallel machine, etc. – are types of changes that are not really fixes, since they often involve significant investment.
Let’s say the customer is torn between either adding buffers, which can be done quickly and cheaply, or adding a new machine in parallel to a persistent bottleneck, which will take longer but will have an immediate, significant impact. A simulation analysis can be run for both these situations. In the first, the buffers are added, and the process of finding & fixing bottleneck is added to the simulation. In the second, the process of finding and fixing goes on until the machine is installed, the new machine is then added to the model, and then the finding and fixing continues. It’s now a simple matter of comparing the financial impact on the bottom line for both scenarios.
Knowing the number of iterations, and thus the approximate length of time before the system makes rate, can also be an important communication tool for managers to senior management. It provides a realistic estimate of duration, and can be a lever for manager to help justify any additional help they need to speed up the implementation.
It will also demonstrate how variation will play a role in the implementation process. A Throughput curve for the system at the current stage of implementation may show that the probability of making rate is 10%. In the past, if the plant hit target on Monday, senior management would expect the rate to be hit everyday from that day forward – just do Tuesday what you did Monday. Now, they should understand that the implementation is on target, and the hit rate will improve consistently over time. (Although educating top management is usually the toughest assignment for those trying to improvement throughput!)
In the next blog, I’ll take a look at using simulation and TOC for designing new systems.
