How Machine Pools Add Capacity Without Buying Machines

Machine pool capacity is the usable output you already own but cannot reach because your routings pin each operation to one machine. A work center group in EDGEBIC by User Solutions is a named pool of interchangeable machines that a routing step targets instead of a single work center, with the scheduler choosing the member on every run based on real load. The iron does not change. What changes is that a loaded machine stops queuing work while its twins sit idle.

This post is about the capacity outcome specifically. For the modeling choice itself, see work center groups explained. This post sits under the EDGEBIC results guide.

The Capacity You Are Hiding From the Scheduler

Most shops with several similar machines route every part to its "home" machine out of habit. Part A always runs on Mill-1, Part B always on Mill-2. It reads as organized. It is actually a capacity leak, because when Mill-1 is booked three days out, Part A waits three days even though Mill-3 is empty and can run it.

The scheduler cannot route around a queue it is not allowed to see. If the routing says Mill-1 and only Mill-1, then Mill-1 is the constraint for that part, full stop, regardless of what the shop floor could physically do. You are running a plant where the effective capacity is far below the installed capacity, and the gap is invisible because no report shows work that was never allowed to move.

What a Pool Actually Does

A work center group has three parts, and the behavior follows from them:

• The group carries a name (which shows on the routing step), an active flag, and a selection strategy.
• The members are the machines. Each membership row carries an efficiency factor (a run-time multiplier against the step's base hours), an optional setup override, a primary flag, and a priority.
• The binding is the routing step pointing at the group instead of one machine. Until it schedules, the step shows a pool badge with the member count. After it schedules, every screen shows the real machine the scheduler picked.

One rule makes the whole thing safe: the group holds no capacity of its own. Every hour lands on a member work center with that member's shifts, holidays, instances, and utilization percentage. The pool totals on the Resource Calendar are live sums of the member cells. That design is the safeguard, not a limitation, because a pool that carried its own hours would sell capacity no machine backs. See what a work center group is for the plain definition.

The Arithmetic on a Real Case

The documented three-mill example makes the capacity gain concrete. A pool of three mills runs 100 units at a base of 0.04 hours per piece. Because the members have different efficiency factors, the same 100 units require different run times on each:

When everything is free, the scheduler picks Mill-2 and the job runs in 2.5 hours. The interesting case is when Mill-2 is booked until Wednesday. A pinned routing would wait for Wednesday. The pool routes to the available member instead, and the job finishes Monday. See how a work center group shops a pool of machines for the selection logic.

The capacity was there the whole time. The pool is what let the scheduler use it.

Why This Reads as Capex Avoidance

When a plant is missing dates and every machine looks busy, the reflex is to buy another one. Sometimes that is correct. Often the busy machines are busy on paper because the routings force work onto them while interchangeable machines idle. Pooling those machines can recover the same output a purchase would, at the cost of a modeling change rather than a capital request.

The heritage line EDGEBIC succeeds shows the shape of the gain. Technical Glass Products recorded a 4% capacity increase alongside a two-week lead time reduction from scheduling discipline, not new equipment. A capacity increase of that shape comes from resources that stopped waiting, and a machine pool is one of the cleanest ways to make idle iron count. This is the same principle behind protecting the constraint to lift plant output.

Where a Pool Earns Its Place, and Where It Does Not

A pool is right when the same list of different-but-interchangeable machines appears on many routing steps. It is the wrong tool in three cases:

• Only one machine can genuinely do the work. Pin the step. A pool that lists a machine which cannot actually run the part is a lie the scheduler will believe.
• The machines are truly identical. If they share one shift calendar and one speed, model them as one work center with several instances instead. That is a simpler structure for the same behavior.
• The grouping is organizational. A department is a reporting rollup that the scheduler ignores completely. Grouping machines by department does nothing to routing.

Getting the choice right is most of the value, which is why the modeling comparison leads with it. For the underlying concept of why finite scheduling routes around load at all, see finite vs infinite capacity scheduling.

What Pooling Cannot Do

It cannot invent throughput that the machines cannot deliver. If all three mills are genuinely full, the pool schedules the work as early as the members allow and no earlier. It surfaces the real ceiling; it does not raise it.

It cannot make a slow member fast. The efficiency factor is honest about the 6.25-hour machine. Routing to it when the fast machine is busy is a trade: an earlier start on a slower run, and the scheduler makes that trade with the selection strategy you chose, not by pretending the machines are equal.

It cannot fix a routing that lists the wrong members. Membership is a claim that a machine can run the work. If that claim is wrong, the plan is wrong. Validate the pool the way you would validate any routing.

Want to know how much idle iron your routings are hiding? Bring your machine list and a month of orders to a demo and we will show where the pool would have routed work you are currently queuing.