What the Optimizer Needs Before Its First Run

The optimizer needs exactly one thing to run: open manufacturing orders that are already scheduled, because it improves an existing plan rather than building one from nothing. In EDGEBIC by User Solutions the other three items on the checklist are optional, and none of your master data needs extra preparation beyond what the scheduler already required. A first run is close to risk-free, because nothing is written until you press Accept.

The checklist

That is the whole list. It is shorter than most people expect, and the reason is worth understanding.

Why there is no extra data preparation

The optimizer consumes the same plan the scheduler produced, from the same work centers, shifts, routings and orders. If your data was good enough to schedule, it is good enough to optimize. There is no separate model to populate, no optimization-specific field on a work center, and no configuration step between the two.

This surprises people who have used planning tools where an optimization module needed its own setup. Here the optimizer is a sidecar to the scheduler rather than a replacement for it, which is the design decision behind why the optimizer is a sidecar not a replacement.

The one thing that changes what the optimizer can do is a setup matrix, and even that is optional, applies per machine, and can be added long after your first run.

The two messages that mean a prerequisite is missing

There are no open manufacturing orders to optimize. Nothing is in scope. Either there are no open orders, or, far more commonly, the orders exist but have not been scheduled yet.

That second case catches people after an import, because an import feels conclusive. It is not: imports change data and never produce a plan. Imported sales orders appear as jobs ready to schedule and wait for someone to run the scheduler. The sequence is always import, then schedule, then optimize.

Least setup time is absent from the Goal dropdown. No sequence-dependent setup data exists. This is a data condition rather than a fault, and the goal appears automatically once a matrix is populated on any work center. Why the Least setup time goal is missing covers it.

Choosing the settings for a first run

Two controls, both with sensible defaults:

Goal. Leave it on On-time first. It protects delivery promises above everything else and is the right choice most days. There is a Compare all goals view if you want the full explanation of each, and switching costs nothing because you can run, look and discard as often as you like.

Time budget. Take the default of thirty seconds. Longer budgets let more alternatives be tried, which makes a no-improvement verdict a stronger statement, but thirty seconds is plenty to see whether the optimizer has anything to offer on your plant.

The engine choice in Options can wait. The default multi-run search reorders whole jobs regardless of which routing features they use, which makes it the broader of the two engines in practice.

Why a first run is safe

Three guarantees are printed on the screen as a safety strip, and they apply to the first run exactly as they do to the hundredth:

• Nothing saved yet. The proposal lives only on that screen until you press Accept.
• Completed work untouched. Recorded work is never moved.
• Never worse than your current plan. If no alternative beats your plan, your plan is the answer you get.

Nothing locks while the optimizer thinks, jobs and capacity stay as they are, and other people's views are unaffected because nothing has been written. Cancel stops a run harmlessly and says that nothing was changed. Closing the application discards an unaccepted proposal, which is always safe for the same reason.

So the practical advice for a first run is not about precautions. It is about picking a moment when you can spend a minute reading the result properly, since the review is the part that deserves attention.

What a good first result looks like

Two outcomes are both successes.

If the optimizer found an improvement, the verdict names the gain, a badge reports how the answer was reached, the comparison table shows each measure before and after with the direction spelled out, and the move list shows only the operations that actually move. Read the move list, then Accept or Discard.

If it did not, the verdict says your current plan is still the best after trying a number of alternatives, often with the nearest challenger and its margin. That is a positive finding: your sequencing was tested against a field of complete alternatives and held. When the optimizer says your plan is already the best makes the case for reading it that way.

Fitting it into the routine afterward

Once the first run is done, the habit is simple: run the optimizer after every meaningful scheduling run. It costs seconds, it is guaranteed non-destructive, and the one-job-at-a-time scheduler leaves reorderings on the table most days. Working the optimizer into your scheduling routine sets out where it fits in a week.

The takeaway

The only hard prerequisite for the optimizer is open manufacturing orders that are already scheduled, which is why the most common first-run message after an import is that there is nothing to optimize: imports never schedule. Everything else is optional, no extra data preparation is needed beyond what the scheduler required, and a setup matrix only adds a fourth goal. Take On-time first and the default thirty second budget, and trust the safety strip, since nothing is written until you press Accept. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with how to turn on the EDGEBIC optimizer and does running the optimizer disturb your plant.