How a Work Center Group Re-Shops Machines on a Reschedule

A work center group step keeps its pool binding after the first schedule, so a reschedule can re-shop the machines rather than being locked to whichever one it resolved to. EDGEBIC by User Solutions re-resolves not-started group operations against the whole pool on every reschedule, while started and completed operations keep the machine they actually ran on. This is what makes a machine pool a pool over time: the flexibility does not evaporate the moment the first plan is built.

A work center group is a named set of interchangeable machines that a routing step can target instead of a single machine. On the first schedule, the engine explodes the group into candidates and resolves one member. The interesting question is what happens next, when conditions change and the plan is rebuilt.

Intent versus outcome

The key design choice is that a group step stores two different things at once: the intent and the outcome. The intent is the pool binding, the fact that this step may run on any member of the group. The outcome is the member it actually resolved to on the current schedule.

After scheduling, every screen shows the outcome, the real machine, so a planner sees "this ran on Mill-2," not "this ran on some pool." But underneath, the step still carries the group binding. That binding is what a reschedule reads. If the engine threw the binding away and kept only the resolved machine, the step would be permanently pinned to Mill-2, and the pool's entire value, the freedom to re-shop when the situation changes, would be gone after one run.

Keeping both means display is honest and re-shopping is possible. You see the machine that was chosen, and the engine remembers it was a choice.

What re-shops and what does not

On a reschedule, EDGEBIC treats the operations of a group step according to their state:

• Not-started operations re-shop the pool. The engine re-explodes the group and re-resolves the member by the pool's strategy against current conditions. If a different member is now the better fit, the operation moves there.
• Started or completed operations keep the machine they actually ran on. Started work is historical fact, so it is never re-shopped. A resource-locked guard ensures an in-progress operation stays matched to the machine it started on, so the floor is never asked to move a job that is already running.

This split is the same discipline that governs the rest of rescheduling, where completed work is preserved and only the remaining work is replanned. The pool flexibility applies precisely to the future part of a job, never to what has physically happened.

When a not-started operation does move to a different member, the change surfaces through the normal replaced-machine indicator, shown as "from Mill-2 to Mill-1," so a planner can see exactly what re-shopped and infer why. Nothing moves silently.

A worked example: a pool across two reschedules

Take a step routed to a milling pool of Mill-1 and Mill-2, shopped by earliest completion. A job needs 10 hours on that step.

First schedule. Both machines are lightly loaded. The engine resolves to Mill-2 because it happens to finish soonest, and the plan shows the operation on Mill-2.

A week later, before it starts. A batch of higher-priority work has landed on Mill-2, filling its near-term capacity. The plan is rebuilt. Because the step still carries the pool binding, the not-started operation re-shops: Mill-1 now offers the earlier completion, so the operation moves to Mill-1. The replaced-machine indicator reads "Mill-2 to Mill-1." The pool did exactly what a pool is for, it absorbed the load shift by moving work to the freer machine.

Later still, mid-run. Suppose instead the operation had already started 4 hours of its 10 on Mill-1 when the reschedule fires. Those 4 hours are historical and stay on Mill-1. The engine only re-resolves the remaining 6 hours, and the resource-locked guard keeps that remainder on Mill-1 too rather than yanking a running job to another machine. Re-shopping resumes only for operations that have not begun.

Same step, same pool, and the behavior differs entirely based on state: freely re-shopped before it starts, pinned to reality once it does.

Why this is the right behavior

The alternative, pinning a group step to its first resolved machine, would quietly defeat the reason to use a pool at all. Pools exist to give the schedule slack: when one machine gets busy, work flows to another. That benefit is worth the most precisely on reschedule, when the situation has changed since the original plan. Discarding the binding would make a pool behave like a single machine after day one.

At the same time, letting a reschedule move started work would corrupt actuals and confuse the floor. So the rule is asymmetric on purpose: future work re-shops freely, in-progress and completed work stays put. That mirrors how EDGEBIC treats the whole reschedule, where a job resumes from where actuals left off and only the unstarted remainder is replanned.

There is one honest guardrail worth knowing. If a pool ends up empty or unknown at schedule time, for example because every member was deactivated, the step is left unexpanded and flagged with a diagnostic warning rather than silently scheduled on a wrong machine. Failing loudly is deliberate: a visible warning is better than a plan that quietly put work somewhere it cannot run.

For the initial explosion and the strategy that picks a member, see how a work center group shops a pool of machines, and for choosing a pool versus a manual alternate, when to use a machine pool versus an alternate work center. The complete scheduling engine guide places re-shopping in the full reschedule pipeline, and finite versus infinite capacity scheduling covers why pool flexibility matters when capacity is tight. To watch your own pools re-shop against changing load, explore the EDGEBIC engine or bring your data to a demo.