Work Center Groups in EDGEBIC: Machine Pools for Planners

EDGEBIC by User Solutions gives you four different ways to say "any of these machines can run this operation," and choosing the wrong one is the most common modeling mistake in a multi-machine shop. A work center group is the newest and usually the right one: a named pool of interchangeable machines that a routing step targets instead of one machine, with the scheduler picking the member on every run based on real load. This post is about the choice itself, and about what changes on your floor once you make it.

If you want the plain definition first, read what a work center group is. If you already know and want the buttons, go straight to creating a group step by step. This post covers when a pool earns its place, and when it does not.

Four Ways to Model Interchangeable Machines

Every shop with more than one similar machine faces the same modeling question. EDGEBIC supports four answers, and they are not interchangeable with each other:

A fifth structure exists and does not belong in this list: the department. Departments in EDGEBIC are an organizational and reporting rollup. The scheduler ignores them completely, so grouping machines by department does nothing to routing. If you have been trying to make a department behave like a pool, that is why nothing happens when you run a schedule.

What a Group Is Made Of

A group has three parts, and understanding them makes every later behavior predictable.

The group itself carries a unique name (the name appears on routing steps, so MILLING beats Vertical milling machines, general purpose), an optional code for imports and reports, an active flag, and one selection strategy.

Members are the machines. Each membership row carries its own scheduling knobs:

• Efficiency factor: a run-time multiplier against the step's base hours inside this pool. 1.0 is baseline, 0.5 runs the work twice as fast, 1.25 runs it 25 percent slower. It applies to run time only and never to setup.
• Setup override: the setup hours used when this member runs the step, or blank to inherit the step's own setup time. A machine can run fast and still set up slowly, and the two knobs are independent for exactly that reason.
• Primary flag and priority: at most one member per group is the designated primary, and priority orders the rest and breaks ties.
• Active flag: an inactive member drops out of every bound step's candidate list on the next scheduling run, which is how you take a machine out of rotation for a retrofit without deleting anything.

The binding is the routing step pointing at the group instead of a machine. Until the step is scheduled it displays a pool badge showing the group name and its member count. After scheduling, every screen shows the real machine the scheduler picked.

One rule ties it together: a group has no capacity of its own. Every hour the scheduler books 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, and the resource calendar is where a planner reads that pool supply day by day. That design is not a limitation, it is the safeguard: a pool holding its own hours would offer capacity that no physical machine backs, and jobs would land "on the group" while the machines underneath were already full.

Groups, Instances, and Departments Side by Side

The two mechanisms compose rather than compete. A group member can itself be a multi-instance work center, so a pool of three cells where one cell holds two identical machines is modeled exactly as it sounds.

The Signals That You Need a Pool

Four situations tell you a group is the answer:

1. You are pasting the same alternate list onto a tenth routing step. That is the moment the maintenance cost of per-step alternates exceeds the cost of defining a pool.
2. You bought or retired a machine and had to hunt through routings. With a pool, that is one member row.
3. Your "identical" machines are not identical. Different vintages have different speeds, different fixturing, sometimes different shift patterns. Instances cannot express that; member factors and setup overrides can.
4. Work queues on one machine while a capable one idles. Pinning caused this, and capacity-aware pooling is the direct fix. A pooled step compares real projected finish times, so an available slower machine legitimately beats a faster machine that is booked until Thursday.

That last behavior is the whole point, and it surprises planners the first time they see it. There is nothing wrong with the schedule when the slower machine wins: waiting for the fast machine simply cost more than its speed saved. The full arithmetic is in how EDGEBIC picks the best machine in a pool.

When a Group Is the Wrong Tool

Pools answer "which machine". They do not answer anything else, and stretching them causes real problems.

Do not model people as a pool. A "Certified Welders" group is skill data wearing a machine costume. EDGEBIC has a separate labor dimension for that: skills, certifications, rosters, and time off, described in operator and skill scheduling. The two compose on the same routing step, where the group answers which machine and the skill answers which qualified person. Since the two features shipped together, member selection is even staffability-aware: a member whose shifts cannot be staffed for the step's skill loses its bid instead of winning on machine capacity and then sliding.

Do not bind a group to a step that also needs parallel processing. In this release a group-bound step is a normal sequential step. Dependent and independent parallel configurations stay per-step. The same applies to material steps, which point at a product rather than a machine.

Do not expect a group binding to coexist with hand-maintained alternates on the same step. Binding a step to a pool replaces its manual alternate list, because the group is the alternate list. Two competing sources of alternates on one step would have no defined meaning, so EDGEBIC picks one.

What Changes on the Floor

Master data edits never move a live schedule by themselves, and that is true here too. Adding a member changes nothing on the Gantt until you run Drive Schedule. On that run:

• Not-yet-started pooled operations re-shop the pool against the current capacity picture and can legitimately land on a different member than last time. When that happens the step carries a replacement indicator, so a supervisor asking "why is this on Mill-2 now" gets an answer on the screen instead of a shrug.
• Started and completed operations keep their machine. Recorded work is never moved by a reschedule, which is the same contract that protects every other actuals-bearing operation in the system.
• A deactivated member stops being considered from the next run onward, and work already running on it stays put.

That combination is what makes a pool safe to introduce mid-stream. You are not rewriting history, you are changing how future work gets shopped.

How to Tell a Pool Is Earning Its Place

Pools are cheap to create and easy to over-apply, so it is worth knowing what success looks like. Three signals, all readable on screens you already use:

Load evens out across the members. Open the Resource Calendar for the pool over a two-week window. Before pooling, one machine runs hot while its neighbours show white space. After a few scheduling runs, the members should be carrying comparable load on the days when work exists. If one member still takes everything, check whether the strategy is PrimaryFirst, whether the others are active, and whether their calendars actually cover the days in question.

Replacement indicators appear, and make sense. A pool that never moves a job between members is a pool doing nothing. Seeing a handful of steps carry a replacement indicator after a busy week means the engine is genuinely re-shopping against real load. Seeing dozens of them every run in a shop that values predictable routing is a hint to move that group to PrimaryFirst.

Maintenance stops being a hunt. The clearest signal is administrative rather than numerical: when a machine arrives or leaves, you edit one member row instead of searching routings. That was the reason to build the pool, and it is the reason it keeps paying after the novelty wears off.

Where Pools Sit in the Wider Engine

Once the scheduler resolves a pooled step onto a member, everything downstream behaves exactly as if the routing had always named that machine: finite capacity checks, multi-shift allocation, instance selection, holidays, and capacity overrides all use the chosen member's own configuration. Nothing about pooling relaxes a capacity rule.

The optimizer treats pools carefully. The default multi-run search re-runs the real scheduling engine for every candidate job ordering, so every candidate honors pools fully. The mathematical solver keeps pooled jobs exactly as the standard engine planned them rather than rearranging a feature it does not model natively, which is the same conservative rule described in locked jobs and the never-worse guarantee.

For the bigger picture of where machine selection sits between routings and the Gantt, the complete EDGEBIC guide walks the whole pipeline, and production bottleneck identification is the natural companion for deciding which pools are worth building in the first place. The mistakes that trip up new pools, from invented factors to deactivated groups, are collected in work center group mistakes.

Ready to build one? Contact US for a demo and bring the routing where the same three machines keep showing up.