FabTime Cycle Time Tip of the Month #4: Use a Greedy Policy when Loading Batch Tools

Welcome to the 4th installment of FabTime’s cycle time tip of the month mailing list. Because the full FabTime newsletter is currently sent only every other month, I am sending these quick cycle time improvement tips on the off months. I hope that whether you use FabTime’s reporting software or not, you find these tips useful.

Today’s tip is about loading batch tools such as furnaces. Here we are talking about tools that can process more than one lot at a time, where the process time is independent of the number of lots.

Tip: Use a greedy policy when loading batch tools.

The challenge with batch tools comes when the tool is available and has some lots ready to be processed, but not enough lots to fill the batch. It’s not uncommon to a have a policy to wait until a full, or near-full, batch is available. The problem with this is that if the utilization of the tool, after adjusting for average batch size, is low or moderate, running full batches hurts cycle time.

The Problems with A Full-Batch Policy: Running full or near-full batches on lightly loaded tools hurts cycle time in two ways.

1. Lots can wait in queue a long time to form the batch, adding to their queue time. (A full- or near-full-batch policy is the only case we know of in which the cycle time operating curve is U-shaped, as shown above.)
2. The batches that are sent downstream will be larger and less frequent than necessary, contributing to downstream arrival variability. As regular readers know, this arrival variability will increase cycle time at downstream steps.

The Argument for A Greedy Policy: A greedy policy, in contrast, says “If there are any lots to be processed, go ahead and start the batch.” It can be shown (see Issue 9.03 and the graph above) that a greedy policy yields much lower average cycle time per visit for lightly loaded tools. For more heavily loaded tools, a full or near-full batch is usually available. Even if an occasional batch is run with a smaller load size, by the time that batch finishes, a full load will be waiting. These tools, even under greedy policy, end up running mostly full batches anyway. The operating curves converge. The greedy policy is robust, working well at any utilization. The full batch policy only works well for heavily loaded tools. This makes a greedy policy a safer choice in an environment with product mix changes.

Most fabs don’t plan to run full batches on lightly utilized tools. The problem comes when a tool WAS heavily utilized and was operated with a full batch policy. Then the product mix changes and the utilization drops for that tool, but the loading policy for the tool remains unchanged. This is where you can end up with a higher cycle time than necessary. See the 50% utilization point in the graph above – the cycle time is about 20% higher for the full batch policy (red curve) and the downstream arrival variability will also be higher.

Caveats and Conclusion: There may occasionally be cases where a full batch policy is necessary for cost or process reasons. There may also be situations on the floor where it’s worth waiting for another lot that is expected to arrive soon (see Issue 3.8). Imagine that the next lot is expected to arrive in five minutes, and the process time is 24 hours. But in general, it’s safe to run a greedy policy for your batch tools, and likely to improve overall cycle time in your fab.?

To subscribe to receive these cycle time tips, and FabTime's longer cycle time management newsletter, visit https://FabTime.com and click the red "Subscribe to Newsletter" button. Subscribers can access the past newsletter issues referenced above. Thanks for reading!