Running EDGEBIC Alongside Your ERP's Scheduling Module

You can run EDGEBIC alongside your ERP's scheduling module without turning either one off, provided one system is explicitly named as the source of executable dates for the floor. The ERP continues planning material, releasing orders, and holding the dates of record. The finite scheduler decides the sequence and tells you which of those dates the plant can actually hit.

EDGEBIC by User Solutions reads what the ERP holds through saved Excel, CSV, and database import masks and returns dates as Excel, which means coexistence is the default arrangement rather than a compromise. This post sets out the division of labor, the one rule that prevents two competing plans, and how to decide whether the ERP module eventually stays on.

Why the two do not actually compete

They answer different questions, and the difference is not a matter of quality.

Most ERP scheduling logic plans against infinite capacity. It asks when an order should start and finish given lead times, and it assumes the work center will accept whatever arrives. That is the right model for material planning, because purchasing needs a date long before anyone knows which machine will run the job.

Finite scheduling asks a narrower question: given real shift hours, real machine counts, changeover times, and every other open order competing for the same machines, when can this job actually run? That question has no useful answer until all the demand is on the table, which is why it belongs to a pass that runs after the ERP has decided what to make.

The general distinction is in finite versus infinite capacity scheduling. The practical consequence is that a shop under about 70 percent load will find the two systems mostly agree, and a shop above that will find they diverge sharply, because infinite capacity planning does not model a queue.

The division of labor

Nothing on that list requires the ERP module to be disabled. What it requires is that rows four through six are not answered by both systems at once.

The one rule: name the source of dispatch

Every problem in a two-system setup traces back to this being unstated.

When the floor receives one list, coexistence works. When two lists circulate, supervisors pick whichever supports the decision they already made, and both systems lose credibility at the same time. It costs nothing to name it and it cannot be fixed later without a visible reversal.

So say it explicitly, in writing, before the first parallel week: the floor works from the finite schedule, purchasing works from ERP dates, and revised dates flow from the schedule back into the ERP once a cycle. That single sentence resolves nearly every argument that follows.

What happens when the dates disagree

Disagreement is the useful output, not a defect. When the ERP promises a completion on the 14th and the finite schedule says the 19th, the finite schedule is reporting that the commitment is not achievable with current capacity. That is information three people can act on:

• The planner can resequence, since a different order at the constrained center may recover the date.
• The supervisor can add a shift or a machine at the center causing the delay.
• Sales can renegotiate the date with five days notice rather than five days late.

What none of them should do is average the two, or quietly pick the friendlier number. A date the plant cannot hit does not become achievable by being recorded.

The return trip for the revised dates is Excel: the job schedule exports as a workbook, the work center schedule exports the same way, and every report dialog exports to Excel or PDF. Those dates then go back into the ERP through the same date maintenance path your order process already uses. The detail is in exporting the EDGEBIC schedule back to your ERP.

The parallel period

Two to four weeks is enough, and the evidence to collect is specific.

1. Where the two plans disagree on a completion date, and by how much.
2. Which date the floor actually hit on each of those jobs.
3. How many work centers each plan implies are overloaded in the same week.

Run both against your busiest week rather than a quiet one, because a quiet week will show agreement and prove nothing. If the two agree under load, keep whichever is simpler to operate. If they disagree by days under load, the disagreement is the decision and a third week adds nothing.

During the parallel period the import routine is the normal one: products, work centers, routings, work orders, actuals, then run the scheduler. Nothing about running both changes the cadence, which is set out in the weekly import routine.

Whether to switch the ERP module off

Usually you do not, for a reason that has nothing to do with scheduling. Material planning runs off order dates, so turning the module off can disturb purchasing in ways nobody predicted. The common end state is that the ERP keeps planning material and holding dates while the floor works from the finite schedule, and the two stay connected by a once-a-cycle date update.

Two cases argue for switching it off. If the module produces dates that circulate and confuse the floor even after dispatch is named, removing the source is cleaner than repeatedly explaining it. And if the module was already abandoned in practice, with the real plan living in a spreadsheet, the migration is a different exercise entirely: migrating from an abandoned MRP scheduling module.

Why nothing is installed in the ERP

Worth stating plainly, because it is what makes coexistence low risk. The scheduler never authenticates against the ERP, nothing is installed in it, and no integration user is created. The interface is the export file, so adding a finite scheduler changes nothing about your ERP's configuration, upgrade path, or change control. If the parallel period ends with a decision not to continue, there is nothing to remove.

That is also why the same approach works whatever ERP you run. The architecture is identical for every system: export to file, import via mask, schedule, export the plan back. The reasoning is in why EDGEBIC connects to every ERP the same way.

Bring one week of open work orders and the dates your ERP currently promises to a working session. Comparing the two plans on your own data is the whole evaluation, and it usually takes an hour. The import layer is on the EDGEBIC ERP integration page, and the engine behind the finite plan is on the EDGEBIC product overview.