Migrating Work Center Groups to EDGEBIC

Migrating work center groups to EDGEBIC means creating each pool by hand and then binding routing steps to it, because groups are not one of the import entity types. In EDGEBIC by User Solutions the efficient sequence is to import your routings with their existing alternate lists first, so the plant schedules correctly straight away, and then consolidate the lists that repeat across many steps into groups. Consolidation is a deliberate swap: binding a step to a group replaces that step's own alternate list.

What a group replaces

In most systems being retired, machine flexibility is expressed one step at a time. If three mills can do a job, all three get listed on every step that needs milling. The information is correct and completely duplicated, which means it drifts the first time someone edits one copy and not the other thirty-nine.

A work center group holds that knowledge once. The step points at the pool, and the scheduler picks a member at planning time. The migration question, then, is not really "how do I move my groups across" but "which of my repeated alternate lists deserve to become one pool".

Import the routings first

Groups cannot be imported, but nothing about them blocks a go-live, so do not let modeling decisions gate the data load.

Bringing routings in with their alternate lists intact gets you a schedulable plant on the normal import order, the same way migrating alternate work center routings describes. Groups then become an improvement you make on a working system rather than a prerequisite.

Creating the pool

Groups live on the Workcenter tab, which carries three inner tabs: Workcenters, Workcenter Groups, and Resource Calendar. Select Workcenter Groups and add a group.

Saved groups appear in the list with a member count, starting at zero. A group with no active members cannot be scheduled, so members are the next step rather than an optional extra.

Pick the selection strategy from how your old system behaved. If it always tried a designated machine first and only spilled to others when that one was busy, PrimaryFirst reproduces that and you flag the designated machine as Primary. If it effectively chased whichever machine would finish soonest, EarliestCompletion is the match, and it is the default.

Adding members and their knobs

Add or Remove Members opens a checklist of every work center. Check the machines in the pool. A machine may belong to several groups at once, and machines already used elsewhere are noted rather than hidden, which is useful when a single mill sits in both a roughing and a finishing pool.

Each member row then carries the settings that make the pool realistic. Edit them in the grid and click Apply on the row.

• Factor is a run-time multiplier for that machine within that group. Effective run hours are the step's base hours times the factor, so 1.0 is baseline, 0.5 is twice as fast and 2.0 is twice as slow. It is never applied to setup time.
• Setup Override sets the setup hours used when that member runs the step. Blank means inherit the routing step's own setup time. It is independent of the factor, so a machine can run fast and still set up slowly.
• Primary marks the machine PrimaryFirst tries first. Only one member per group can hold it; ticking a second unticks the first.
• Priority breaks ties, lower first, and decides the fallback primary if no member is flagged.
• Active unchecked drops the machine from every group-bound step's candidate list on the next scheduling run, while operations already started on it stay put.

Take care with the factor during migration. It expresses relative speed for this class of work inside this pool. A machine that is slower at everything should carry that in its own work center configuration instead, or you will end up describing the same slowness twice. The factor from base rule is the one to keep in mind.

Binding the steps

On the BOR tab, open the step's work center selection popup from the button next to the work center field. It offers three choices: Workcenter, Product, and Work Center Group. Choose Work Center Group and pick the pool. The list shows active groups that have at least one active member, and hovering a group previews its members and their factors.

Each binding replaces that step's manually configured alternates. Work through the steps deliberately rather than in bulk, and leave any step unbound where a hand-picked list really does differ from the pool.

Verifying the consolidation

After binding, schedule and check which machine each group-bound step actually landed on, then compare against what your old system would have chosen for the same work. Two migration errors show up immediately. If everything piles onto one machine, check whether a stray Primary flag plus PrimaryFirst is overriding the load balancing you expected. If a pool seems to have vanished from the picker, check that the group is Active and has at least one active member.

Pair this with the load check from migrating capacity and utilization settings, because a pool's behavior depends on its members' capacity being right first. Once the pool exists, how to see a work center group's pooled load reads the group row on the Resource Calendar as a live sum of its member machines.

The takeaway

Migrating work center groups to EDGEBIC is a hand-build rather than an import: load the machines and routings through the Workcenter and BOR masks, then create each pool on the Workcenter Groups inner tab, add members with their Factor, Setup Override, Primary, Priority and Active settings, and bind the routing steps that should shop the pool. Remember that binding replaces a step's own alternate list, that a planner's manual pin still wins and survives reschedules, and that a group needs at least one active member to schedule at all. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with how a work center group shops a pool of machines and an EDGEBIC migration checklist.