What Is a Work Center Group? Machine Pools Explained

A work center group is a named pool of interchangeable machines that a routing step can target instead of a single machine: the planner routes "any member of MILLING," and on every scheduling run the engine picks the best member, weighing each machine's speed, setup time, and real-time availability under the group's selection strategy. It is the scheduling answer to a question every multi-machine shop has: "any of our three mills can cut this part, so why does the routing pin it to one?"

This is the APS industry's resource-group concept, and this entry is part of the EDGEBIC glossary; the broader dictionary lives in the manufacturing glossary.

The Problem Groups Solve

Before groups, a planner with three interchangeable-but-different mills had three unsatisfying options: pin each routing step to one machine (the others idle while jobs queue), hand-maintain the same alternate-machine list on dozens of routings (it drifts the first time a machine is added or retired), or model the trio as one work center with three instances (only correct when the machines are identical, sharing one calendar and one speed).

A group is the centrally maintained fix: define the pool once, bind any number of routing steps to it, and let the scheduler shop the pool on every run. Add a fourth mill to the group and every group-bound step in every routing considers it immediately, with zero routing edits.

How It Works

Each member row in a group carries its own scheduling knobs:

• Efficiency factor: a run-time multiplier against the step's base hours. 1.0 is the baseline, 0.5 runs the work twice as fast, 1.5 runs it 50% slower. The factor applies to run time only, never to setup, and is always computed from the planner-entered base hours, so it can never compound across reschedules.
• Setup override: a member-specific setup time replacing the step's default, for machines with simpler or harder changeovers.
• Primary flag and priority: at most one member is the designated primary; priority orders the rest.

The group itself carries a selection strategy:

One design rule keeps everything honest: a group has no capacity of its own. Only members hold hours. Any pool total a dashboard shows is a live sum of member capacity, computed for display, because a group that held capacity would let the scheduler book hours no physical machine backs.

A Worked Example: Three Mills, One Step

From the EDGEBIC by User Solutions documentation. Group MILLING, strategy earliest completion: Mill-1 (2015 Haas) at factor 1.0 as primary; Mill-2 (2024 DMG) at factor 0.5; Mill-3 (1998 Bridgeport) at factor 1.5 with a 0.25-hour setup override. A routing step at 0.04 hours per unit with 0.5 hours setup, order quantity 100:

All mills free Monday: Mill-2 projects Monday 10:30 against Mill-1's 12:30 and Mill-3's 14:15, so Mill-2 gets the job. Mill-2 booked until Wednesday: its projection slides to Wednesday morning, Mill-1's Monday 12:30 now wins, and the fastest machine loses to the available one. That trade is the entire point of capacity-aware pooling, and it is recalculated from live load on every run.

After actuals land: if the operator started the step on Mill-2 and a reschedule fires, the step stays on Mill-2 regardless of strategy, because started work keeps its machine. A not-yet-started step re-shops the pool against the new capacity picture, and any change is surfaced as a replacement indicator ("Replaced: Mill-2 → Mill-1") so nobody hunts for why the assignment moved.

How EDGEBIC Implements It

In EDGEBIC, a routing step's target can be a specific machine, a machine with listed alternates, or a group; binding to a group replaces any hand-maintained alternate list, since the group is the alternate list, maintained once. Under the hood, the engine expands the group just before machine selection into a nominal primary plus one candidate per remaining member, each carrying its own pre-computed effective hours, and the same battle-tested selection machinery that handles alternate work centers picks the winner. The group binding survives saving, snapshots, and reschedules, which is what makes re-shopping possible run after run.

Groups compose with the rest of the engine rather than competing with it: a member can be a multi-instance work center, a group-bound step can also carry an operator skill requirement (member selection then accounts for staffability, so a machine nobody qualified can staff loses its bid), and group-bound jobs are locked to their standard-engine result during mathematical optimization so the optimizer can never emit an invalid assignment. A group Resource Calendar shows the pool's summed capacity by day for load balancing at a glance. For where machine selection sits in the wider pipeline, see the scheduling engine guide; for the constraint-thinking behind pooling decisions, production bottleneck identification is the natural companion.