Is a Standard Definition for Moves Possible?

By Jennifer Robinson

Although every fab seems to define moves differently, we believe that a consistent industry definition offers value. While fabs are unlikely to change existing definitions, we propose a clear, supplemental metric: value-added completes.

Over the 30+ years that I’ve been working with fabs, one thing that has become clear is that even the most seemingly simple topic is likely to become complex once you dig into it. A notable example of this is moves. Every fab tracks moves as a core manufacturing metric. The very first chart included in FabTime was a Moves Trend chart. We all know what moves are.

But do we?

When we talk about moves, are we talking about the same thing? And if we’re not talking about the same thing, how can we make comparisons across fabs?

What is a move?

“Move” is presumably short for “move out,” which is a transaction logged to an MES when a lot has finished processing on one tool and is ready to be transported to the next tool. This sounds straightforward. However, when we dig in, various questions arise.

Does a move have to include a tool, or should we include things like visual inspections, where only an operator is needed?
Does a move have to be a value-added step? (And what does value-added mean?)
What about steps like inspections that are only done on some lots? You can skip them. It’s more efficient to skip them. But there are reasons to do them. Should you count the ones you do as moves?
What about rework? Are rework operations moves?
What about fabs that track moves at a higher level, for a group of operations (like stage moves in Promis)? Are those moves?
What transaction should we use to designate the move? Typically, there is a track out transaction that is automatically recorded by the tool in more automated fabs or manually logged as a move out by an operator in less automated fabs. Some fabs, just to keep things interesting, have a mix of more and less automated tools.
- What if the lot is still stuck on the port of the previous tool? It completed the operation and may have been automatically logged as track out even though it's still sitting on the port of the previous tool because no one has physically moved it yet. Was that a move?

As we work to integrate the FabTime reporting module into the INFICON Smart Manufacturing suite, we’ve had occasion to validate the move numbers displayed for the same demonstration data in the FabTime system and the Factory Dashboard (formerly called FPS Dashboard). We also have a history of matching move numbers between FabTime and Factory Dashboard for joint customers that pre-dates INFICON’s acquisition of FabTime. Matching these numbers isn’t as straightforward as we might prefer, because of the above questions. Let’s explore this further.

Why is it important to have a good definition for moves?

We need a good definition for moves because:

People use them to compare across fabs. A move isn’t necessarily the same thing in different places. This renders comparisons invalid.
No matter how many other metrics are put in place, operators on the floor usually pay close attention to move targets. This is because moves give instant recognition of activity (vs. cycle time and outs, which are lagging indicators).
How we define moves affects how we measure cycle times at the step level, which in turn drives how much we’re able to improve. The more granular the move, the more information we have about queue time vs. process time at individual tools.

Our definition should comprehend whether a move is value-added because:

If people in the fab are focused on total moves and we successfully reduce non-value-added activities, the total number of moves will decrease. This may make people uncomfortable, unless they have access to a move-related number that increases due to these efforts.
If we’re not using a good definition for moves, operators can end up incentivized to make poor choices in the fab. For example, if the non-value-added moves are the easier moves, and they count, why wouldn’t operators focus on those? This is less of an issue for more automated fabs, of course, where the scheduling system sets the plan.

For these reasons, we as an industry need a clear and consistent definition structure for moves that can be used within and across fabs to facilitate tracking and improving fab performance. We’ve been working with a team of INFICON customers and engineers to provide that structure, and we are sharing our recommendations here.

How have Factory Dashboard and FabTime historically defined moves?

The Factory Dashboard (AKA FPS) team always had a structured definition for moves, as shown below, while FabTime has been a bit more flexible depending on the needs of the customer.

In Factory Dashboard:

“Step completes” are recorded for each completed step that includes a tool visit.
“Skips” are recorded for completed steps that do not have a tool associated with them (like visual inspections).
“Logical Moves” are the sum of step completes and skips but are not prominently used as a metric in Factory Dashboard. The lot is moving logically from one step to the next.
“Oper moves” or “Stage moves” are recorded when a small grouping of contiguous steps is completed. This group of steps can be called an operation (Workstream) or a stage (PROMIS) or whatever that site prefers.

In FabTime:

Moves are the same as Factory Dashboard step completes (recorded at the level of a single step, not grouped), except that skips can also be treated as moves in FabTime if the customer chooses (this is site-configurable).
Stage moves in FabTime are essentially the same as Factory Dashboard oper moves. The customer can have a flag e.g., FabTime.StageOut, which is set to “Y” when a FabTime move is also a stage move. This lets the customer report those higher-level stage moves as well as the more detailed step-level moves.
Operation in FabTime is always a single step, though some customers only report stage moves. Customers can also include a flag denoting that a step is value-added. In this case, non-value-added moves can be excluded.

Each of these frameworks is reasonable. Each has been used in dozens of fabs over the years. But they are indisputably different.

Schematic showing how moves are defined in Factory Dashboard and FabTime.

What did our customers say about this?

Faced with definitional differences, we did what we always do. We asked our customers what they think. While we will of course maintain confidentiality of individual customer responses, here are some things we learned:

One company uses “move” for a group of steps, defined as a value-added operation (series of sub-steps). They don’t count any metrology steps as moves, because they don’t want to incentivize over-inspection.
A couple of companies use both completes (which must be done on a tool) and logical moves (which don’t require a tool), as defined in Factory Dashboard. But for one of them, completes must be value-added. The other just requires that completes be on a tool.
Another company uses completes as defined in Factory Dashboard, but they call that moves. This metric can include non-value-added steps, but they also use a stage move that must be value-added.
Another company just says that if a step is completed on a tool (including metrology tools), then it’s a move.
One site counts everything except rework, even staging operations, as moves, but then designates a separate financial move that accounts for added value.
Another mostly uses stage moves but sometimes uses the moves as defined in FabTime, with no differentiation for value-add.

In summary: it’s complicated. Some companies use step moves, and some use stage moves. Some require a tool to be included and some don’t. Some look at whether steps are value-added, and some don’t. Some use multiple definitions of things related to moves for different purposes (moves vs. completes vs. stage moves vs. financial moves, etc.).

About all we can reliably conclude is that:

A stage move is generally a group of steps; and
A complete usually requires a tool.

What about rework?

Rework adds another layer of complexity to move definitions. Some people treat rework steps as moves because the operators are doing the work. Some don’t, because these steps aren’t value-added. Sometimes it depends on whether the rework occurs during the same shift as the original move. In FabTime, all moves that take place within a rework loop have a rework flag. Any moves chart can be filtered to display all moves, non-rework moves only, or rework moves only. For example, the chart below, from our FabTime demo server, is filtered to only show rework moves.

Example of a Moves Trend chart filtered to only display rework lots.

How should we record moves if we care about improving cycle time?

Tracking moves as completes (one step completed on a tool) is best for analyzing operation cycle time. Stage moves can be useful for comparing fabs (if the stages are defined consistently), but they don’t tell us which tools are accruing queue time. For that, we need to track the move in and move out at each tool. (Even then there are possible further levels of detail, which we will address another time.)

Tracking logical moves that don’t include processing at a tool could be helpful for highly manual fabs. For understanding cycle time, it’s better to track these as additional steps rather than lumping the time in with, say, queue time for a tool. For instance, if there’s a visual inspection prior to a step that takes place on a tool, and there’s a wait for the technician who can do the visual inspection, it’s more informative to capture that separately from the subsequent queue time for the tool itself. Maybe the capacity of the tool is fine, but production is gated by a lack of technicians to do the visual inspection. The more information we can gather about the causes of delay, the better positioned we’ll be to make improvements.

On the other hand, when it comes to metrology steps that can be skipped and aren’t done on every wafer, we agree with our customer cited above that including these as moves can lead to poor incentives. If you can do a quick track in and track out of a metrology step, and get credit for an easy move, that can incentivize doing too many inspections. For cycle time we need the granularity of the individual step moves. However, including them for non-value-added steps can lead to artificial inflation of move numbers.

To understand cycle time, we need to track moves at each tool.

So how can we define moves in a way that lets us compare across fabs, but also gives different fabs the flexibility that they need

After working with many fabs over the years and discussing moves definitions recently within INFICON and with INFICON customers, our metrics alignment team has concluded that very few fabs are going to be willing to redefine moves for their site. Changing the definition of something so fundamental to fab culture is a non-starter.

That said, we believe it’s worth adding a supplemental move metric that is defined the same way for all fabs and thus allows for benchmarking across fabs. We propose:

Value-Added Complete: A lot moves logically from one step to the next AND is processed on a tool AND value is added. Since value is not added by doing rework (we would like to disincentivize doing extra rework), rework steps are not value-added completes.

For an existing FabTime or Factory Dashboard customer to display value-added completes, they would need to add a “value-added” yes or no flag to each step (if not already included). This could be done programmatically via a set of rules. The rules could be something like “everything that isn’t a rework step or an inspection step that requires a tool is a value-added step.” With such a flag in place, it would be possible to filter existing FabTime moves charts or Factory Dashboard completes to display value-added completes. Value-added completes could then be used to benchmark across fabs and across companies, and to measure improvement progress.

Conclusions

In our experience, the most widely used metric in most wafer fabs is moves. Moves tell us whether a fab is on pace to meet overall throughput goals, and whether individual areas, operators (sometimes), and shifts are ahead or behind. Despite the ubiquity of “moves” as a metric, however, we’ve observed that all moves are not created equal. Differences exist between fabs regarding whether moves must be done on a tool, must be value-added, can include rework steps, and can (or must) include groups of steps. These differences make it impossible to compare performance across fabs with any degree of accuracy.

Because fabs are accustomed to their own move definitions, we do not believe it feasible to ask for broad change. We do, however, believe that a new move-related metric, one that is clearly defined and consistent across companies, will be a useful addition to the fab metrics toolkit. We thus propose that in addition to measuring moves the way they always have, fabs should also start measuring value-added completes. Value-added completes are transactions in which a lot moves logically from one step to the next, is processed on a tool, and has value added.

Acknowledgements

Many thanks to the INFICON internal metrics team as well as the customer representatives who have been generous with their time and opinions as we’ve worked through questions about moves and other metrics. Special thanks to my co-leader on the metrics team, Paul Campbell, whose consulting experience informs this article.