Should We Be Looking at Queue Time Sub-States as an Analog to OEE?

This topic is long overdue

There is no question that GOOD information in this area would be useful in determining where resources could be better used to service bottleneck equipment. The danger is applying it to all equipment. This scatter-gun approach tends to create lots of busy-work for supervisors and others and has absolutely no effect on (or detracts from) what really matters, i.e. the elevation and exploitation of bottlenecks to create more throughput.? I once saw this analysis done manually on one particular tool. The end results was considered a great success, though I considered it a complete failure. The tool was not a bottleneck and all it achieved was to divert resources to get lots to a bigger queue at the next tool.

Except for lots on hold (slows progress in the queue) or lots with elevated priority (speeds progress in the queue), it seems like all other reasons impacting a lot's time-in-queue are more related to process equipment and could be better described and analyzed with attributes or sub-states attached to the equipment state (i.e., "No Operator" attached to a "STANDBY" state). If I were to Pareto queue time sub-states across LOTS and find that "No Operator" is the biggest queue time impact, I still have to determine the specific equipment/process steps where "No Operator" occurred.? It's at the equipment level where I can attack the problem...nothing I can do with the lots themselves to improve the situation so might as well start with a Pareto of equipment state attributes/sub-states to evaluate factors slowing down the queue.

It's an interesting idea, but it is a bit fraught with pitfalls.? There is difficulty in properly attributing a specific portion of queue time to a sub-state from those proposed.? "Spitballing" this may lead to a skewed picture of what is is actually happening during queue time while creating the false sense of certainty.? If this were the caset it would ultimately result in worse decisions rather than better.?? A simple example of my concern: If three tools are qualified to run a lot, six lots are in queue for the same operation and one of the tools is down for planned maintenance, what does the queue substate of each lot fall under??? * Since one tool is down, do some or all of these lots get put into the "availability" bucket??? * Does all of the queue time get put into that bucket or just a part of it??? * Is redundancy really the issue, as that would seem to imply more tools are needed?? There is an expected queue time for a fab at a given level of loading and product mix.? How would this factor into this kind of sub-state recording if at all??? * Operations can often be deactivated on a tool though the tool is still qualified.? Would such a case fall under tool qualification or redundancy?? What if the tool with the deactivated operation were down for unplanned maintenance?? ? All this isn't to say it's not worth doing, just that there needs to be a very clear-eyed understanding of the limits of how much can be accurately attributed to one of the causes.? My suggestion would be to limit these substates to only those that lend themselves to a high degree of certainty in attribution.? For example, if a tool is waiting to be loaded, a lot is available to be processed, but the lot has not been loaded, that would fairly clearly fall under the operators category.? You might consider collapsing some of the remaining categories and/or creating new ones as it may be too hard to clearly attribute any distinct portion of the wait time to either "availability" or "redundancy."?? Within our fab, FabTime is very much used for decision-support lending data and clarity to proposed changes.? That being the case, we want that data to be as unassailable as possible.? I'd much rather take the conservative approach of saying "we know this much, but the rest can't be clearly attributed to a single cause" than to take what amount to guesses that could lead to the wrong conclusions.?? My $0.02

Yes but for some older fabs with semi automation, these sub-states data collected might not be accurate or useful, especially if it's 100% rely on human to make selection of the sub-states. I just don't want to see these sub-states become some sort of reasons codes. I've seen this happened in one of the factories I'm supporting.