Migrating Alternate Work Center Routings to EDGEBIC

Migrating alternate work center routings to EDGEBIC means importing the primary routing through the mask, then rebuilding the alternate and parallel work centers on each step inside the routing designer. In EDGEBIC by User Solutions, the two-pass routing import carries the operation sequence and the primary work center for every step. The fallback and parallel machines are configured per step afterward, where you set each alternate's speed factor and priority and the designer can validate them. The backbone migrates as data; the flexibility is rebuilt where it can be checked.

Two layers to a flexible routing

A routing with alternates has two layers. The first is the backbone: the ordered operations and the primary work center for each. The second is the flexibility: the backup machines, the parallel machines, and the rules for when each is used. These two layers migrate differently, and understanding the split is the whole of this task.

The backbone imports cleanly through the standard routing mask, the same way any basic routing moves into EDGEBIC. The flexibility layer is configured after the import, in the routing designer, because that is where EDGEBIC can validate each alternate against the work centers that actually exist.

Import the primary path first

Start with the primary routing. The two-pass import brings in each product's operation sequence and the primary work center per step, wiring the step order automatically. This is your foundation. Every alternate you add later hangs off one of these steps, so the steps must exist first.

Confirm the primary routings scheduled correctly before you touch alternates. A routing that does not plan on its primary machines will not plan any better with backups added, so fix the backbone first.

Rebuild alternates on each step

With the primary routing in place, open the routing in the designer and add the flexibility per step. EDGEBIC gives you two distinct tools, and choosing the right one matters.

Alternate work centers. A fallback the engine uses when the primary has no capacity. For each alternate you set two things: the speed factor, which adjusts the run time if the machine runs at a different rate, and the priority, which tells the engine which backup to try first. A backup that runs twenty percent slower carries a factor that gives it more time, so the schedule reflects the real speed of whichever machine gets the job.

Parallel work centers. Machines that run at the same time on the same operation. Independent parallels split the load to finish faster; dependent parallels run in lockstep with a parent machine for synchronized operations. Parallels add throughput rather than fallback flexibility.

You pick the type per step, so one routing can have a plain step, a step with two alternates, and a step with parallel machines, each configured to match how the shop actually runs.

Consider a work center group instead

Before you hand-build alternates on dozens of steps, ask whether the machines are actually a pool. If the same three interchangeable machines back each other up across many routings, a work center group is a cleaner model than a manual alternate list on every step.

A group is a pool of interchangeable machines that the engine re-shops on every reschedule, picking the best available member by the group's strategy. You define the pool once and point routing steps at the group, rather than repeating a primary-plus-backups list on each step. A manual alternate list is the right tool for a one-off fallback that does not generalize; a group is the right tool for a shared pool.

One rule to remember: a step uses either a work center group or a manual alternate list, not both. The group is the alternate list when you use it. Deciding group versus manual alternate per situation keeps the model clean and is worth doing deliberately during the migration rather than reproducing an old system's structure by reflex.

Validate the flexibility

Once alternates and parallels are configured, test that they behave. The check is straightforward: load the primary machine on a step to capacity, schedule a job that needs it, and confirm the engine moves the job to the alternate with the correct adjusted time. If the alternate never gets used, its priority or its work center reference is likely off. If it gets used but the dates look wrong, check the speed factor.

For a work center group, schedule enough work to exceed one member's capacity and confirm the engine spreads the load across the pool. This load-first validation is the same principle used when validating a migrated schedule against RMDB: trust the behavior only after you have watched the engine do the thing the setting was supposed to enable.

The takeaway

To migrate alternate work center routings to EDGEBIC, import the primary routing and its work centers through the two-pass mask, then rebuild the flexibility per step in the routing designer, setting each alternate's speed factor and priority. Choose a work center group when the same machines form a shared pool, and a manual alternate when a fallback is a one-off, but never both on one step. Validate by forcing the primary to capacity and confirming the engine reaches for the backup. See the platform on the EDGEBIC overview, read the upgrade path on the RMDB to EDGEBIC guide, and pair this with moving your RMDB routings into EDGEBIC.