How to Run and Read an Optimization in EDGEBIC

Running the optimizer in EDGEBIC by User Solutions is three clicks and a decision: pick a goal, pick a time budget, press Run, then Accept or Discard what comes back. Nothing is written to the database until you Accept, and the proposal is never worse than the plan you already have. This walkthrough covers the run and, more importantly, how to read the result in about thirty seconds.

For what the goals mean, see optimizer goals and presets. For the whole feature, the optimizer guide is the pillar post, and EDGEBIC is the platform the optimizer sits beside rather than inside.

Before You Run

Step 1: Launch It

On the Drive Schedule tab, click Optimize Schedule, which switches you to the Optimizer tab. You can also open that tab directly.

The top of the tab carries the contract in one line: it will try many schedules and show you the best one, and nothing changes until you press Accept. That sentence is not decoration. It is the reason you can run this on a live plan in the middle of a shift without a change-control conversation.

Step 2: Pick a Goal and a Budget

Choose a goal in the dropdown. On-time first is the default and the right choice most days. Compare all goals opens the guide with the full description of each.

Then pick a time budget: 10, 30, or 60 seconds, defaulting to 30. A longer budget lets the optimizer evaluate more alternatives. It does not guarantee a better result, and it can never produce a worse one.

Click Run. The status shows that it is trying schedules. Cancel stops the run harmlessly, reporting that nothing was changed.

Step 3: Read the Result in Five Parts

When the run finishes, the comparison appears. Nothing has been saved. Read it in this order.

1. The verdict

One honest sentence. When the optimizer found something, it says what improved and confirms what it protected, for example: "This plan makes 1 more job(s) on time, reduces lateness by 4.7 hours. Nothing already started was touched."

When it did not, it says so plainly: "We tried 24 alternative schedules, your current plan is still the best," often with the nearest challenger and how far short it fell. That is a positive result, not an error: your plan survived a serious challenge. Why the optimizer returned the same schedule covers the three reasons it happens.

2. The badge

The badge is the certificate: how hard the answer is, in the strictest words the engine can honestly use.

The distinction between the first two rows is real and worth respecting: a search that tried many options is not the same claim as a proof. What the percentage means is covered in what an optimality gap is.

3. The KPI table

Four columns: Measure, Current, Proposed, Change. One row per metric, including late jobs, weighted lateness, makespan, setup hours when setup data exists, and plan changes when a committed plan exists.

The Change cell always spells out the direction in words as well as an arrow, for example "2 better" or "0.5 worse", so nothing depends on reading a color. A goal may accept a small loss on a minor measure to win a big improvement on the one you asked for, which is a feature of how goals are ranked rather than an inconsistency.

4. The move list

Headed "What changes", with one row per operation that actually moves: job, work center, current start, proposed start, and a short reason such as "starts 4.0h earlier". Operations that do not move are never listed, which is what keeps this a thirty-second read rather than a report.

If nothing moves, the list says so directly: your current plan stands.

5. The safety strip

Three fixed guarantees, always visible: nothing saved yet, completed work untouched, never worse than the current plan. Read them once, believe them, and stop worrying about running the optimizer on a live plan.

Step 4: Open Explain When You Need the Why

Explain opens a plain-language record in five sections:

• Goal: what you asked for.
• How we searched: how many alternatives, how long, and which ordering won, for example due-date order.
• Outcome: each measure before and after, plus the certificate line.
• What changes: the most significant moves written as sentences.
• What was protected: completed and in-progress work untouched, the never-worse rule, and that nothing was saved until a planner pressed Accept.

With the mathematical solver, Explain also lists locked jobs and the reason for each, such as multi-instance work center, parallel processing, or lot streaming. A locked job is reproduced exactly as the scheduler planned it and the others are optimized around it. That is a safety property rather than a shortfall, explained in locked jobs and the never-worse guarantee.

Copy puts the whole story on the clipboard, which is the fastest way to send a supervisor the reasoning behind a change they are about to see on the floor.

Step 5: Accept or Discard

Accept saves the proposal through the same pipeline as a normal scheduling run, with the same protections for recorded work. Every schedule view refreshes, and one audit record is written capturing the full explanation, the goal, the numbers, and the moves. You can find it later through the job's audit trail.

Discard drops the proposal. The database is byte for byte untouched.

If the world changed while you were reading, for example a colleague rescheduled or kiosk actuals landed, Accept refuses rather than overwrite. A banner appears saying changes arrived while you reviewed, with a Re-run button that solves again on the latest data. It is never a data-loss situation, because the proposal was only ever held on your screen.

One more property to know: a proposal lives only on that screen, in that session. Closing the application discards it, which is always safe because nothing was saved.

What Accept Actually Changes

A Worked Run, Start to Finish

Three scheduled jobs on Monday July 20, a Day Shift of 08:00 to 16:00, one machine each on Saw-1 and CNC-Mill-1:

The current plan runs the jobs in priority order. The first job's six-hour cut holds the saw all Monday morning while the mill sits idle until 14:00, the mill then backs up, and the third job ends up one day late.

Run with On-time first and a 30-second budget. With three jobs the search evaluates every ordering and finds the one where the short cuts go first so the mill never starves. The screen shows:

• Verdict: this plan makes one more job on time and reduces lateness by 4.7 hours, and nothing already started was touched.
• Badge: Best of 6 schedules tried in 2.1s. With the mathematical solver selected it would read Proven optimal in 2.1s: the same plan, plus the proof.

The move list has six rows. One of them moves the first job's mill operation later, from Monday 14:00 to Wednesday 08:00, and that job is still on time. Giving way is exactly the trade a scheduler working one job at a time can never see, and it is why reading the move list is worth the thirty seconds.

Press Accept and all three jobs show zero days late, with the audit trail recording why.

Choosing the Engine

Options, then Schedule, then Optimizer Engine. Multi-run search is the default. The mathematical solver adds the proof. Both honor every capacity constraint and both are clamped never worse, so switching is safe at any time. If the solver component is not installed in your deployment, the selection falls back to multi-run rather than failing, which is why a badge can still read "Best of N tried" after you selected the solver.

Where to Go Next

Optimizer goals and presets covers what each goal ranks, locked jobs and the never-worse guarantee covers the safety properties in detail, and optimizer usage mistakes collects the habits that waste runs. For the wider platform, start at the complete EDGEBIC guide or the how-to hub.