Earliest Start vs Earliest Completion Machine Selection

When a routing step can run on more than one machine, whether through a hand-configured alternate list or a work center group, EDGEBIC by User Solutions picks the member using one of three strategies: earliest completion, which finishes the step soonest; primary first, which prefers a designated machine and falls back only when it cannot serve; and earliest start, which begins the work soonest. The strategy is a property of the pool, applied every time it is shopped, and the choice between them is a real decision because starting soonest and finishing soonest are not the same thing. The most instructive case is when earliest start and earliest completion disagree, because that reveals what each one actually optimizes.

Both a work center group and an alternate list hand a set of candidate machines to the same resolver, described in how a scheduler chooses between alternate machines and how a work center group shops a pool of machines. The resolver's job is to pick one. The strategy tells it how.

Three questions, three strategies

Each strategy answers a different question about the pool.

• Earliest completion. "Which member finishes this step soonest?" The resolver computes each candidate's projected finish, using that member's own speed and setup, and picks the smallest. This is the usual default because it directly minimizes the step's finish, which usually helps the job finish sooner too.
• Primary first. "Can my preferred machine do it?" The resolver tries a designated primary member first and only reaches for another when the primary cannot serve. This suits a shop with a machine it trusts and others as backup.
• Earliest start. "Which member can begin soonest?" The resolver picks the member that can start the work at the earliest moment, prioritizing getting the work moving over how long it then takes.

Each membership carries its own speed factor and its own setup, computed from the base hours, so the resolver always compares real per-machine numbers rather than a scaled approximation. That the speed factor scales run time but not setup is covered in how efficiency scales run time but not setup.

Where earliest start and earliest completion diverge

On a lightly loaded pool where every machine is free, the three strategies often agree, because the freest machine is also the one that starts and finishes soonest. The interesting behavior appears under load, when the fast machine is busy and a slower one is free.

Earliest completion looks at the finish. It will accept a later start on the fast machine if that machine's speed still makes it end first. Earliest start looks at the start. It will take the slow machine that is free now, because it begins the work sooner, even though it finishes later.

There is a subtlety in earliest start that sharpens the divergence: it compares start availability at day granularity. A member that can begin today is treated as starting sooner than one that can only begin tomorrow, regardless of the finish. So under earliest start, a machine available today wins over a faster machine that has to wait until tomorrow to start, even when the faster machine would have finished the step first. That is not a flaw; it is the strategy being literal about what it optimizes, which is the day the work can move.

A worked example: fast-but-busy versus slow-but-free

Take a step needing 10 base run hours, shopped across two members of a pool.

Mill-A, factor 0.6 (fast), is booked until tomorrow morning. Its run for this step would be 10 x 0.6 = 6 hours. If it starts tomorrow at 08:00, it finishes tomorrow at 14:00.

Mill-B, factor 1.2 (slow), is free today at 13:00. Its run would be 10 x 1.2 = 12 hours. Starting today at 13:00 on an 08:00-to-16:00 shift, it works 3 hours today and 9 tomorrow, finishing tomorrow at 17:00, rounded onto the next open slot.

Now apply each strategy:

• Earliest completion compares finishes: Mill-A ends tomorrow 14:00, Mill-B ends tomorrow 17:00. Mill-A wins, because its speed beats its later start.
• Earliest start compares start days: Mill-B can begin today, Mill-A only tomorrow. Mill-B wins, because it gets the work moving a day sooner, even though it finishes later.
• Primary first, if Mill-A is the designated primary, tries Mill-A and uses it as long as it can serve within the horizon, so it picks Mill-A regardless of Mill-B being free today.

Three strategies, potentially three different winners, on the same pool and the same step. None is wrong. Each is right for a different objective.

Choosing the strategy

The strategy should match what the pool is for.

Reach for earliest completion when the shortest finish of the step is what matters, which is most of the time, especially when the step is on or near the job's critical path and finishing it sooner pulls the whole job in. It rewards speed honestly.

Reach for earliest start when getting work moving is the priority, for instance to keep material flowing and avoid a pile-up in front of a downstream station, or when you would rather see a machine start now than sit idle waiting for a faster one. Just know that it can pick a slower machine, and that its day-granular comparison means a same-day start beats a faster next-day one.

Reach for primary first when you have a preferred machine, better tooled, better understood, or cheaper, and you want work concentrated on it, accepting a wait for the primary over spreading load across the pool.

Whichever you pick, the chosen machine is scheduled with its own real speed and setup, and on a reschedule a not-yet-started step re-shops the pool and the strategy runs again against current load. Because there is no random tie-breaking, the same data and the same strategy always produce the same pick, so a choice that surprises you is always explainable by the strategy and the state of the pool.

Machine selection sits alongside the other multi-machine tools in the scheduling engine guide, and the trade-off between a pool and a single alternate is covered in when to use a machine pool versus an alternate work center. The reason honest per-machine numbers matter at all is the same reason behind finite versus infinite capacity scheduling. To set a strategy on your own pools and watch it pick against your real load, explore the EDGEBIC engine or bring your data to a demo.