What Your ERP Export Cannot Tell You About the Floor

An ERP export carries the routing and the demand well and the capacity reality almost not at all: machine counts, shift coverage, sequence-dependent changeovers, machine pools, operator certifications, transfer batches, and which work centers are the real constraints usually have to be entered after the import. That is not a defect in your ERP. It is a consequence of most ERP routing logic planning against infinite capacity, where none of those seven fields would change the answer.

EDGEBIC by User Solutions imports what the ERP does hold through saved Excel, CSV, and database masks, then plans finitely against the fields the ERP does not hold. Knowing which is which before the first import saves a week of wondering why a plausible import produced an implausible schedule. The mirror image of this post, the fields the ERP must supply, is which ERP fields EDGEBIC needs to schedule.

The seven gaps, in order of impact

The first two carry most of the error. The remaining five are worth adding where they change the answer, which usually means at two or three work centers rather than all of them.

Gap 1: how many identical machines a center holds

This is the single most common cause of a first schedule that looks alarming. If the work center export has no machine count column, the value defaults to one machine per center, so a cell with four presses is modeled with a quarter of its capacity.

The arithmetic is direct. Four identical machines on an 8 hour shift hold 32 hours of capacity, not 8. A job needing 24 hours fits in a day. Modeled as a single machine it needs three days, and every downstream operation moves with it. Across 40 work centers the plan is systematically pessimistic in a way no single job explains, which is exactly what makes it hard to diagnose from the schedule.

Fixing it is an afternoon with a list of work centers and a supervisor. It is also the reason the machine count column belongs in the work center export permanently, even if you have to add it to the report by hand. The related trap, where the ERP holds two rows for what is really one cell, is covered in when two ERP rows map to one work center.

Gap 2: which shifts each center actually runs

Most ERPs hold one plant calendar. Real plants run a second shift on three cells, weekends on one, and a maintenance window on the bottleneck every Tuesday morning.

Shift assignment is per work center, which is what makes that describable. Set the standard pattern first, then override the exceptions, rather than trying to specify every calendar in advance. Where the ERP does hold a usable calendar it can be imported: see importing shift calendars and plant holidays.

The symptom of getting this wrong is subtle. The schedule is not obviously broken, it is just consistently a little late at the centers that really run longer than the model thinks, and consistently a little early at the ones that do not.

Gap 3: what a changeover actually costs

An ERP setup time is one number per operation. A setup family matrix says what the changeover costs going from what ran last to what runs next, which is a different quantity.

In a paint booth, white to light gray may be five minutes and black to white four hours. No single setup number describes both. The result of averaging them is a schedule that is wrong in both directions and a sequence nobody would choose.

Import the ERP's setup time as the baseline, because it is real and it applies when sequence does not drive the changeover. Then add a family matrix only where sequence genuinely matters, which in most shops is the paint line, the heat treat oven, or the extruder, and not the other thirty seven centers. The concept is in what a setup family is.

Gap 4: which machines are genuinely interchangeable

ERPs hold this thinly when they hold it at all: an alternate resource field, or a note on the operation naming a second machine. What the schedule needs is a pool with a speed factor per member, so an older machine that takes 40 percent longer is modeled as such rather than treated as equal.

The payoff is that a job can move to a free member instead of queueing behind a busy one, and the pool is re-shopped on every reschedule rather than pinned to whichever machine won the first time. Carrying whatever the ERP does hold is covered in mapping alternate work centers from your ERP.

Gap 5: who is certified to run what

Certifications usually live in HR records or on a laminated board, not in routings. That is fine for compliance and useless for planning, because a schedule that plans an Inconel weld on a shift when nobody certified is present is a schedule that will slip without warning.

Modeling operators and skills is worth doing where a certification is genuinely scarce. If three people can run every machine, skip it. If one person can do the aerospace welds, the schedule needs to know.

Gaps 6 and 7: overlap and constraints

Transfer batches let a downstream operation start once a first batch of pieces is physically available rather than waiting for the whole order. ERPs almost never model this, and the effect on lead time is large on long runs. The concept is in what a transfer batch is.

Which centers constrain is a flag rather than a field, and marking it changes how the plan protects that resource. Most shops know the answer already and have never written it down. If yours does not, the general method is in production bottleneck identification.

The order to fill them in

Do not attempt all seven before the first schedule. Import what the ERP has, run a schedule, and let it tell you where the model disagrees with reality.

1. Machine counts and shift patterns. Half a day, and most of the accuracy.
2. Run a schedule and compare it to what the shop actually does. Where it disagrees, one of the first two is usually wrong.
3. Setup families at the two or three centers where sequence drives changeover.
4. Machine pools where offloading is a real option.
5. Operator skills where a certification is scarce.
6. Transfer batches on the long runs.

Then confirm the result with your own actual hours rather than an estimate, which is one of the better reasons to import labor transactions early: importing ERP labor transactions as actuals covers that path. Those same hours are what let you test the routing standards themselves, which is the method in should you trust your ERP's standard times.

Why this is not a workaround

The division holds up because each system is holding the data it is in a position to keep correct. The ERP knows what was ordered, what it costs, and what the routing says. The floor knows how many presses actually run and which changeover is expensive, and that knowledge changes faster than any ERP master record. Deciding which system owns which field explicitly, rather than by accident, is the exercise in choosing the system of record for each scheduling field.

Bring a work center export and a supervisor who knows the floor to a working session. The gap between what the file says and what the supervisor says is usually the whole story, and it takes about twenty minutes to surface. The import layer is on the EDGEBIC ERP integration page, and the engine that uses these fields is on the EDGEBIC product overview.