A Go-Live Cutover Plan for Your ERP and EDGEBIC

A go-live with EDGEBIC beside your ERP is a staged cutover, not a replacement: build the capacity model, import master data and orders, validate against a week that already happened, run both schedules in parallel for two to four weeks, then make the new one official when it stops needing corrections. The ERP keeps orders, inventory, purchasing, and financials throughout. What changes is where the dispatch list comes from.

EDGEBIC by User Solutions has been going live beside ERPs since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, the projects that go badly are always the ones that skipped the parallel run. The projects that go well end on a trust signal rather than a calendar date.

What a cutover here actually involves

It helps to be precise about the scope, because "go-live" carries a lot of baggage from ERP projects.

Nothing is installed in the ERP. No integration user or credential is created, so there is no permission surface to review. The interface is the export file, which is the whole point of the universal import method.

Stage 1: the capacity model, before any orders

Get this wrong and everything downstream looks fine and is wrong.

Build work centers with honest instance counts and real shift calendars. Instance count means machines a job could actually run on today, not machines that exist. Shift calendars mean the hours the center is genuinely available, including the weekend pattern and the plant holidays.

If your ERP has no resource master, build the list yourself. It is an afternoon, not a project, and the method is in building a work center list when your ERP has none.

Two habits pay off for years: number operation sequences in gaps of ten, and pick an identifier convention for work centers and products and write it down. Matching is case-insensitive but not space-insensitive.

Stage 2: master data in, four exports

Four exports carry a complete scheduling model, each through its own mask:

1. Items. Identifier, description, unit of measure.
2. Work centers. Identifier, instance count, default setup, efficiency, shift assignment.
3. Routings. One row per operation: end product, work center, sequence, run time, setup, queue time.
4. Open work orders. Product, quantity, order reference, dates.

Build each mask once by dragging your file's column headings onto the target fields. Mandatory fields are flagged, and the run refuses to start until they are mapped, so a half-built mask fails before it reads a row.

Two mask settings do most of the work at this stage: a conversion factor per numeric column, so minutes become hours with 0.016667 and a per-hundred standard becomes per piece with 0.01, and blank-cell preservation, so a partial refresh file keeps existing values rather than wiping them. The unit question is worth settling deliberately, and mapping your ERP's units of measure covers it.

Reconcile after every import rather than at the end. The import reconciliation checklist is six checks and takes ten minutes.

Stage 3: validate backward before planning forward

This is the stage most projects skip, and it is the one that earns the floor's trust.

Take a week that has already happened. Import the orders that ran, schedule them, and compare the result against what the shop actually did:

• Where the plan says a center had slack and the floor worked Saturday, the instance count or the shift hours are wrong.
• Where the plan shows a center swamped that nobody noticed, a routing is pointing at the wrong center.
• Where a job's hours are off by a clean multiple of 60, 100, or 1,000, a conversion factor is missing.

Each disagreement is a correction to the model, not an argument about the schedule. Most shops find three or four in an afternoon. That exercise converts the whole conversation from opinion into evidence, which matters enormously if a previous scheduling project produced dates the floor ignored.

Stage 4: the parallel run

Run both schedules for two to four weeks. The old method keeps producing the official dispatch list; the new one runs beside it and gets compared every week.

What to compare each Friday:

The parallel run ends on that last row. When two consecutive weeks pass with no correction that changes a promise date, the model has converged. That is a better end condition than a date on a plan, because it is the condition that actually predicts whether the floor will follow the schedule.

Stage 5: go-live, which is smaller than it sounds

Going live means three changes:

1. The dispatch list comes from the new schedule. Job View and work center schedule views export to Excel with colored cells and a legend sheet, and every report dialog exports to Excel or PDF using the column layout you saved.
2. Revised dates go back to the ERP through the date-maintenance path your order process already uses. There is no automated write-back, which keeps your ERP data under your team's control. The mechanics are in exporting the schedule back to your ERP.
3. The recurring rhythm becomes the routine. Export, import, schedule, export back. The weekly sync routine is the shape most shops settle on, and the nightly routine covers higher-frequency operations.

Work in progress needs no special handling. Imports never schedule anything, and completed work is never moved by a reschedule, so jobs already running carry on under the plan they started with.

Who owns which field, decided once

The one governance question worth settling before go-live: for each field that exists in both systems, which one wins.

• ERP owns order quantities, due dates, customer data, item identifiers.
• The scheduler owns instance counts, shift calendars, setup matrices, work center groups, and operator skills, because the ERP usually does not hold them at all.
• Shared, ERP-led are routing times, which originate in engineering and re-import cleanly whenever they change. The mechanics of that are in handling engineering changes with a routing re-import.

Write the split down. It prevents the slow divergence where somebody edits a routing in one system and nobody remembers which is current.

A realistic timeline

The documented benchmark in the User Solutions lineage compresses the first three phases hard: at Plastilite Corporation the ERP vendor itself recommended User Solutions scheduling, and the team went from first export to a complete optimized schedule with ERP integration in 5 days. The first week checklist follows that shape day by day.

Once live, the full engine applies: finite capacity across shifts and machine instances, work center groups, sequence-dependent setups, lot streaming with transfer batches, operator skills, and mathematical optimization with a proven optimality gap. The EDGEBIC product overview maps it, and the ERP integration architecture shows the layer that connects them.

Start the plan with your own data

Bring one week of real exports to a demo and do the backward validation live. It is the fastest way to find out how close your capacity model already is, and it is the step that decides how long the rest of the cutover takes.