Scheduling a Shop That Runs Two ERPs

When one shop floor is served by two ERPs, you still build one capacity model: one work center list, one calendar, one plan, fed by a separate set of import masks per source system. The machines do not care which system placed the order, and two schedulers would each believe they owned the same mills, so both plans would look feasible and neither would be.

EDGEBIC by User Solutions has fed schedules from mixed system landscapes since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, multi-source shops are common enough to have a settled pattern. This post covers it: why one model is the only correct answer, the three problems that need solving before the first import, and the routine afterwards.

How shops end up here

Four situations account for nearly all of them:

• An acquisition where the acquired business stayed on its own system but its work runs through your plant.
• A division on a legacy system that nobody has had time to migrate.
• A parallel migration, where old and new run side by side for a quarter.
• A contract manufacturing arm on a separate system from the branded business.

The first three are usually temporary and often last years. The fourth is permanent by design.

The file interface is why this works at all

The integration method does not change: export to a file, import through a reusable mask, schedule, export dates back. A mask remembers one file shape, so a second source simply means a second set of masks. Nothing is installed in either ERP, no connector has to support both, and neither system needs to know the other exists.

That is the practical consequence of the approach described in why EDGEBIC connects to every ERP the same way. A universal import layer treats a second source as another Tuesday.

This is a different problem from one ERP exporting several plants, which is covered in handling multi-plant ERP exports. There, one system speaks for many sites. Here, many systems speak for one site.

Problem 1: identifier collision

Products and work centers match on the identifier, case-insensitively. So part 1000 from one system and part 1000 from another become one product, holding one routing, and every job from either business schedules against whichever routing was imported last.

Nothing errors. The counts look clean. The plan is fiction.

Prevent it with a namespace applied in each export before the file reaches the mask:

Do it in the saved report or view so every export from that system carries the prefix automatically, rather than in a step someone performs by hand. The identifier discipline generally is in keeping product masters in sync.

Apply the same thinking to job numbers, so a job reference is traceable to the system that issued it. Conventions are in keeping job numbers aligned between ERP and EDGEBIC.

Problem 2: work centers must not be namespaced

This is the exception, and getting it backwards is expensive.

A machine shared by both businesses is one machine. Give it one work center record. If each system's export creates its own copy, the capacity splits: two records with, say, four instances between them, each looking half empty while the real cell is full. Every promise date built on that picture is wrong in the optimistic direction.

So:

• Shared machines: one record, named once, mapped from both systems' exports to the same identifier.
• Genuinely separate cells: separate records, which is just ordinary modeling.

Normalize the work center name in each mask so both systems' spellings land on the same record. Watch the auto-create behavior while you do it: the routing import creates any work center a file names that does not exist, so a spelling variant from the second system silently produces a second, empty center. Sorting the work center list by shift assignment groups those orphans, which is check one on the import reconciliation checklist.

Problem 3: double-counted demand

If both systems can issue a work order for the same physical job, that job books capacity twice, and a machine reads full while the floor stands idle.

The fix is organizational and it needs to be written down: agree which system owns which demand. Usually by business unit, sometimes by product family, occasionally by order number range. Then filter each export to its own slice.

Check it weekly during any period of change: total open jobs in the plan should equal open jobs in system A plus open jobs in system B. A gap in either direction is worth chasing the same day.

The conventions can differ, and that is fine

Two systems will disagree about almost everything, and the mask absorbs it, because conversion and shaping are per column and per mask:

Name the masks so nobody has to guess: Weekly Routings (System A) and Weekly Routings (System B) beat two masks both called Routings.

One calendar, always

Shifts and plant holidays describe the building, not the paperwork. There is one calendar, authored locally, and neither ERP should be mapped onto it. That is already the standing rule, since no ERP models a plant calendar at the grain a scheduler needs, and it becomes non-negotiable with two sources. The reasoning is in should you import your ERP's manufacturing calendar, and the wider field ownership map is in choosing the system of record for each scheduling field.

The daily routine with two sources

Barely longer than with one:

1. Export from system A, run its masks, read the counts.
2. Export from system B, run its masks, read the counts.
3. Reconcile per source: Created versus Reused should look sane for each independently.
4. Run the scheduler once, over the combined load.
5. Export dates back to each system in the format that system's process expects.

Step 4 is the point of the whole exercise. One run, one plan, one truth about what the mills are doing on Thursday. The rhythm is in the weekly ERP sync routine, and the return trip is in exporting the EDGEBIC schedule back to your ERP.

Reading the counts per source

Keeping the masks separate gives you a diagnostic that a merged file would hide. A high Created count on system B's routine product import points at system B, not at your data generally: usually a prefix that changed, a trailing space, or a column that shifted one position. Per-source counts turn a vague problem into a located one.

The slower drift checks belong in a monthly ERP to EDGEBIC data audit, which is worth running per source during any parallel period.

If one of the two is on its way out

A parallel migration is a special case of this pattern with an end date. The retirement side of it is covered in what changes in EDGEBIC when you replace your ERP: the model survives, the masks get rebuilt, and identifier continuity is the whole risk.

What one model buys

With both businesses' work in one plan, the engine can do what it exists for: load every machine to its real finite capacity across shifts and instances, re-shop work center groups on every reschedule, apply sequence-dependent setups, overlap steps with transfer batches, and produce a plan through mathematical optimization with a proven optimality gap. Crucially, it can show which business's work is displacing which, which is a conversation two separate plans can never support. The EDGEBIC product overview maps the engine, and the ERP integration architecture shows the import layer both sources share.

Bring an export from each

Export one week of work orders from each system and bring both to a demo. Mapping two sources into one model takes under an hour, and seeing the combined load on your shared machines is usually the moment the case makes itself.