Sequence Optimization and Changeover

The Sequence Optimizer reorders operations on a work center to cut total changeover time, using the constraint types and changeover matrix you’ve set up (see Set Up Constraint Types, Product Attributes, and the Changeover Matrix). It’s a separate tool from finite scheduling: finite scheduling respects capacity, calendars, and due dates but doesn’t minimize changeover today; the optimizer minimizes changeover but doesn’t model capacity or calendars. Run whichever one — or both, in either order — your shop needs.

Two engines

• Quick Optimizer runs entirely inside Microsoft Dynamics 365 Business Central, no external service required. It groups orders by constraint profile and sorts by priority and due date — the always-available option.
• SmartFlow Engine is the optional cloud-based solver, enabled on the Setup page (Solver Enabled), for larger or more constrained sequencing problems. Which one actually answers a given run shows on the results panel as its branded name, so you always know which engine produced the sequence you’re looking at.

Running it

From the Scheduler’s Optimize Sequence action, pick the work center(s) you want sequenced and confirm. Each selected work center is optimized in turn, independently, using its own changeover matrix — not as one combined cross-work-center model. That distinction matters in a routed shop: optimizing your mixing line in isolation can produce a beautiful mixer sequence that dumps four batches on the oven at once. Optimize your actual bottleneck work center, review it, accept it, and then re-run the optimizer on the next work center downstream so it sees the updated upstream times — that re-run is what keeps a multi-stage routing honest under today’s per-work-center model.

Deselect a work center when it has no meaningful changeover (a manual inspection or hand-pack station), when its changeover costs are flat regardless of sequence, or when it’s scheduled by a process outside SmartFlow’s scope — a deselected work center keeps its existing order and runs first-in-first-out.

Review before you commit

Every run follows Propose → Review → Accept/Reject. The results panel shows the current sequence and the proposed one side by side as colored-circle diagrams — one circle per order, connecting lines showing the changeover cost between neighbors, colored from green (minimal) through amber and orange to red (high, or blocked). Click any circle for its detail: item, order number, work center, position in the sequence, run and setup time, and the attribute values driving its changeover cost. A constraint selector lets you view the same before/after picture through a different lens — by a specific constraint code, or by on-time delivery — with KPI badges (setup total, late orders, makespan) shown before → after for whichever lens you’ve picked.

If a run produces no measurable improvement for a work center, the panel says so plainly rather than presenting a no-op sequence as a win. Nothing writes back to your production orders’ starting date-times until you click Accept & Apply; Reject discards the proposal and leaves the current sequence untouched.

The changeover matrix, briefly

Setup and Product Attributes tell the optimizer what your shop tracks (color, allergen, flavor, or anything else that costs time to change over) and which items carry which values; the changeover matrix tells it how much each transition costs, from any value to any other. Matrices are almost always asymmetric — going from a light color to a dark one is often close to free, while the reverse demands a real flush — so fill in every cell deliberately, including the zero ones, rather than leaving a direction blank and letting it default to free. The full setup walkthrough is in Set Up Constraint Types, Product Attributes, and the Changeover Matrix.

Each constraint type also picks a Changeover Mode: Matrix is the traditional from→to lookup grid described above; Tag Based instead computes cost from which tags an item is removing going into the next job — useful for a constraint like allergen, where the cost is really driven by what has to be cleaned away, not by a fixed N×N table of every possible pairing.

Multi-work-center runs, in practice

Selecting several work centers in one Optimize Sequence run is a convenience for batch-running the per-work-center optimizer, not a single model that weighs every work center’s sequence against every other one at once. That’s why the acceptance order in Running it above matters: accept upstream, then re-run downstream, rather than accepting every work center’s result in one pass and assuming they’re mutually consistent. If a work center genuinely doesn’t need re-optimizing after an upstream change — nothing about its own changeover picture has moved — you can leave its prior result as-is and only re-run the ones that do.

Concepts behind this feature

Sequence-Dependent Setup: The Changeover Matrix Explained covers why direction matters, why savings compound across a shift, and the trap of optimizing sequence blind to due dates — worth reading before you tune the matrix for a shop where changeover and due dates genuinely pull against each other.