Beyond DBR - the need for basic data
My experience at GM has colored my view towards Drum-Buffer-Rope. We often used the basic methods in the Goal to help find the first set of “obvious” bottlenecks in a plant (although they were rarely obvious to the plants themselves). Fairly quickly, however, the ability to use these methods become obsolete, and our correlation between improving a station and improving overall throughput began to drop.
GM has the advantage, however, of using C-More, a tool that will take a very basic set of data and tell you the location of the bottleneck. Accurate and fast, the first versions of this tool were not a simulation, but an algorithm that quantified the impact, in JPH, of the bottleneck.
The need for data drove us to design a very basic template for the PLC (programmable logic controller) programs that run the workstations. Over time, we found we only needed a small set of data from each workstation to drive C-More accurately. Armed with this information, we then used the TIP (Throughput Improvement Process) to begin the process of improvement. Focusing this process on our most profitable products generated a lot of revenue for GM, and when I left, there were no plants that could not make the enough products to meet demand.
The difference between most of the other TOC efforts to improve throughput and the one we used in GM is the data and analysis part. I became a strong believer in the leverage this data has on improving the organization, now and in the future. But I do not get the impression that others in TOC world value this data, perhaps for many valid reasons. Perhaps the difference in viewpoint can be attributed to how a vehicle assembly plant is different than most other manufacturing plants:
Buffer Sizes - Certainly assembly plants, with their small buffers for vehicles (think of the space 10 full size SUV’s consume), are different than the buffers for say, camshafts and pistons. These smaller buffers can lead to more starving and blocking than the large ones that can be used in other manufacturing plants. However, between major departments, there can be hundreds of vehicles being stored in overhead or storage buffers. The amount of time blocking and starving occurs from these buffers can usually be used to determine in which department the bottleneck is currently located.
Balanced Cycle Times - The emphasis in lean manufacturing on getting balanced takt times also makes finding the bottleneck without data difficult. Balanced workstations cycle times means that it takes a long time to refill a buffer after a long downtime occurrence.
Uneven schedules & work practices – Working through lunch & breaks, overtime, stripping lines at the end of a shift, etc., are just a few of the work practices that fill or empty buffers and change the dynamics of blocking and starving. The reasons these practices are used are not to make more jobs overall, but to improve other, local, measures for a group or department.
Large number of workstations – in a typical assembly plant department, there are hundreds of workstations. Given the other factors listed above, this also hinders rapid identification of the bottleneck.
So, data collection became a way of life in GM, resulting in the formation of its own group and a dedicated implementation team. I firmly believe that it can play a role in a plant that matches some of the conditions listed above, or in a mature DBR process that is beginning to doubt the location of their bottleneck.
The down side usually given is the time and cost to install, but common templates and the small amount of data required did not make that an issue for GM. Typically, the installation process began while the Goal methods were being implemented, so that by the time the bottleneck became harder to find, C-More could use the data from the recently installed system to accurately locate it.
For plants in this situation, I think there are solutions available today in the market that can do just as good a job (or better!) than what we developed at GM. But before I get to that part of the blog, I’d like to hear other viewpoints. What do you think?
Kevin
