Handling Engineering Changes With an ERP Routing Re-Import

To push an engineering change from your ERP into EDGEBIC, re-import the routing for the affected products: the routing import wipes and recreates each product's step list per run, so the new method replaces the old cleanly, while every job already scheduled keeps the frozen routing snapshot it was planned with. That separation is what makes engineering changes safe to import on any day of the week, including the middle of a busy one.

EDGEBIC by User Solutions has handled routing revisions this way since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, the requirement is always the same: the new method must reach the plan without disturbing what is already running.

What an engineering change actually changes

An engineering change order can touch a routing in several ways, and they behave differently on import:

The common thread: the data changes on import, the plan changes only when you schedule. The universal import method keeps those two acts separate deliberately.

Why re-import beats hand editing

It is tempting to make a small change directly in the routing designer, and for a one-off correction that is fine. For an engineering change that originated in the ERP, re-importing is better for three reasons:

• The ERP stays the master. Hand editing creates a divergence that nobody documents and the next nightly import silently overwrites.
• The wipe-and-recreate behavior makes it idempotent. Running the same routing file twice gives the same result, so a repeated or partially-completed import is never a problem.
• The chain is rewired automatically. Pass two of the routing import sorts steps by sequence and wires 10 to 20, 20 to 30, and the terminal step to the finished product. A hand-inserted step needs those links set manually.

The one rule that matters: keep a product's steps together

The routing import wipes and recreates a product's steps once per run. That is what makes re-imports safe, and it is also the one behavior that will bite you if you split a product across two files.

If product BRK-200 has ten steps and you import five of them in one run and five in another, the second run's wipe deletes the first run's five. You end up with half a routing and no error message, because both runs did exactly what they were told.

So: export whole products. Filtering the export down to only the changed products is fine and often sensible. Filtering down to only the changed steps is not.

Numbering that survives an insert

Number operation sequences in gaps of ten. When engineering adds an operation between 20 and 30, it becomes 25 and nothing else renumbers.

That habit matters more than it sounds, because renumbering every downstream operation makes the change look far bigger than it is. It also breaks any cross-reference your shop keeps between an operation number on a traveler and the same number in the ERP. The routing versus operations mapping guide covers the column-level detail.

Controlling when the change takes effect

There is no effectivity date on the routing itself. You control the cut-in point through two levers, and between them they cover the real cases:

Lever one: when you import. Nothing changes until the file lands. If the change should not apply until next month, import next month.

Lever two: which jobs you reschedule. After the import, jobs already planned keep their snapshots. New work orders pick up the new method as they are scheduled for the first time. So the default behavior is a natural phase-in: existing commitments run the old way, new work runs the new way.

To pull the change forward onto a job that is planned but not started, reschedule that job. To hold a job on the old method, leave it alone. Jobs that have already started are protected either way, because completed work is never moved by a reschedule.

The three cut-in patterns shops actually use

Phase in on new orders. Import the change, reschedule nothing. Old jobs finish the old way, new jobs use the new method. Lowest disruption, and correct when the change is an improvement rather than a correction.

Immediate for all unstarted work. Import the change, then reschedule the open jobs on that product. Correct when the change fixes a quality or safety problem and the old method should not be run again.

Immediate for everything, including started jobs. Import, reschedule everything on the product, and accept that started jobs continue from where their actuals left off using the new remaining steps. Correct when the change is mandatory and mid-job. Use it sparingly, because it moves promise dates on work already committed.

What to check after the re-import

Engineering changes are the case where the import reconciliation checklist earns its keep, because a routing re-import can succeed with fewer steps than you expected and never say a word about it.

1. Step count. Open the changed product in the routing designer and count. A step that quietly vanished usually means a filter on the export dropped a row.
2. Chain continuity. Every step connected, terminal step ending at the finished product.
3. New work centers. The routing import auto-creates any work center it names that does not exist. A change that moves an operation to a new machine will create that machine as an empty center with no shifts and no instance count. Configure it before scheduling, or it plans against defaults.
4. Hours on one job. Add setup plus run time times quantity across the new steps and compare against the schedule.

Where the change shows up in the plan

Once rescheduled, the new routing feeds the full engine: finite capacity across shifts and machine instances, work center groups that re-shop the machine pool on every reschedule, sequence-dependent setups, lot streaming with transfer batches, and mathematical optimization with a proven optimality gap. If the change moved an operation onto a tighter machine, the effect on promise dates is visible immediately rather than three weeks later. The EDGEBIC product overview maps the engine and the ERP integration architecture shows where the routing import sits.

Fold it into the routine

Engineering changes do not need their own process. Add them to the recurring import rhythm you already run: routings refresh on whatever cadence your engineering department actually changes them, which for most shops is weekly rather than nightly. The weekly sync routine has the order of operations, and the nightly routine post covers the higher-frequency case.

Try it with a real change

Take a routing your engineering team revised recently, export both versions, and bring them to a demo. Watching the old method schedule, then re-importing and watching the new one, makes the snapshot behavior concrete in about five minutes.