In my last post I explained the basics of the bucket brigade as a self-organizing manufacturing line. The key to making this system work is the process for handing over the part to the next worker. An unsuitable hand-over could mean lots of waiting time for the workers. Hence, I would like to go into more detail on how to do the hand-over of the part.
The hand-over process can happen when the subsequent worker walks back along the line or when the preceding worker moving forward catches up with the subsequent worker. Let’s look first at the easier case of walking back.
As part of the rules of a bucket brigade, a worker without a part has to walk backward until he meets the preceding worker. In the example picture, the blue worker walks backward until he meets the gray worker at process 3. The blue worker then takes over the part from the preceding gray worker.
Ideally, the preceding gray worker just completed a part at process 3 that can be handed over. The succeeding blue worker would then process this part at station 4. This would be the perfect situation.
In reality, however, the gray worker may not yet have completed the part at his station. Now you have two options. First, the blue worker could simply wait until the gray worker completes the part, and then take over the part. This would obviously include waiting time. Hence, a short cycle time would keep this waiting time short, whereas a longer cycle time would create quite a bit of waste by waiting.
Alternatively, especially for longer cycle times, it is also possible for the blue worker to take over the part from the gray worker while the part is still in the same process. However, this is risky. The hand-over process now also requires additional information. What work in the current process is already completed, and what still has to be done? There is a higher risk of the blue worker overlooking a step in the process, believing that the gray worker has already done that.
Moving forward along the line should always be with a part. The blue worker in the image moves from station to station together with a part. It is possible that at one point the blue worker will catch up with a subsequent worker (gray in the image). In this case the blue worker has to wait until the gray worker completes his process and moves forward.
Again, we have waiting times. The blue worker cannot hand over the part to the gray worker until the gray worker himself gets rid of his part (by giving it to the next subsequent worker or at the end of the line). I repeat, the part can only be handed over if the subsequent worker gets rid of his part and is ready to walk backward.
This problem of waiting for the next worker depends heavily on the work speed. Where is your bottleneck? If your bottleneck is at the end of the line, all workers have to wait for the subsequent worker, and you will have lots of waiting times. The image below shows a possible worst case. All other workers have to wait for the last worker to finish his process, before the workers can move forward.
Why Not Just Use Buffer Inventory?
All the above examples have no buffer inventory between the processes. This is intentional. It may be tempting to use a similar system with buffers in between, but … don’t. The animation below is an extreme case, where the last worker has a problem. The first worker slowly builds up a lot of inventory in the line.
After the last worker has solved his problem, the first worker would have to wait for the entire time until the last worker has completed all material. Overall, a very inefficient system if you add inventory.
Naturally, in the above case the first worker would not wait forever, but would maybe make himself more useful. But this would be either a more complex standard (not good) or a non-standardized and hence chaotic and random action (also not good).
It may be possible to have a working bucket brigade using buffer inventories, but I believe it will be difficult. There are lots of things to take care of to make this work, and there is a risk of the result being worse than a normal balanced flow line.
Here are some examples of bucket brigades. The first one is a training example from the Universidad Tecnológica de Pereira, where they assemble Lego pieces.
The second example is from the food industry, where food is prepared in front of the customer at Chipotle and Subway.
A bucket brigade works best for short cycle times; otherwise you will have either lots of waiting times or potentially tricky in-process hand-overs. The two example videos above both have rather short cycle times in the range of one to five seconds. In fact, many bucket brigade examples are manual pick-and-place or commissioning tasks, where each process is merely a quick handling of a part. However, there are also some examples of more complex bucket brigades (e.g., a wire harness with a cycle time of around one to two minutes).
A bucket brigade should have an increasing process speed (or worker speed) along the line to avoid workers getting stuck behind a slow process (or worker). Hence, the bottleneck should be at the beginning of the line.
And, unless you really know what you are doing, avoid using buffer inventories. They can create situations with extremely long waiting times.
Overall, the bucket brigade is a possibility for handling variable workloads in some situations. If a bucket brigade does not work for your case, you may simply do a proper line balancing, or think about a pearl chain (where you sequence products with different workloads to have an overall balanced workload).
I hope you enjoyed the post (especially the animations – they are quite a bit of work to do!). Now go out, carry the bucket forward, and organize your industry!