Advanced planning and scheduling: modelling the constraint you actually have

First establish that you have a sequencing problem

Plants that miss dates often assume they need better scheduling when the actual cause is material arriving late, product structures that are wrong, or a quality loop that returns work unpredictably. A scheduling engine given unreliable inputs produces a precise plan for a factory that does not exist. Before investing, trace a sample of late orders back to what actually held them up. If most were waiting for parts, the fix lies upstream. If most were waiting behind another job on the same machine, or were stranded by a changeover somebody wanted to avoid, then sequencing is the constraint and a scheduling tool has something to work on.

The changeover matrix is where the model earns its money

On many processes the cost of a setup depends entirely on what ran before: light to dark, thin to thick, one alloy to another, allergen-bearing to allergen-free. Capturing that dependency is what allows a tool to build campaigns instead of merely queuing jobs, and it is the single richest source of value in most implementations. It is also tedious to collect, because the knowledge lives with a handful of experienced setters rather than in any document. Expect the first version to be wrong in places, and plan a route for setters to correct it, otherwise they will spend their time working around a sequence that ignores what they know.

Competing objectives have to be ranked by someone

A scheduler can favour due-date performance, or machine utilisation, or minimum changeover time, or low work in progress, but not all of them at once, and the mathematics will happily trade one against another without telling anyone. Left unstated, the ranking gets embedded in configuration by whoever set the parameters, and the plant then argues about outputs without realising the objective was chosen in a workshop months earlier. Making the ranking explicit and revisiting it when conditions change — a full order book calls for different behaviour from a thin one — is a management decision that belongs with operations leadership, not with the analyst maintaining the model.

A schedule republished every hour is not a schedule

Optimisation engines will regenerate on any change, and each regeneration can reshuffle work that has already been prepared, kitted or set up. Supervisors respond to that by picking a version and working from it regardless of later updates, which is a rational defence and the end of the tool's usefulness. Stability mechanisms matter more than solution quality: a horizon inside which the sequence is fixed, rules that prevent already-started work being moved, and a published cadence so everyone knows which version is current. A slightly worse schedule that people can rely on outperforms a better one that changes underneath them.

Who owns the sequence when reality intervenes

A machine breaks, a key operator is absent, an urgent order arrives from a major customer. Someone will change the sequence, and the question is whether they do it inside the system or on the floor. Overrides made in the tool preserve the model's view of consequences downstream; overrides made verbally leave the schedule showing a fiction within hours. The workable arrangement gives supervisors explicit authority to resequence within defined bounds while requiring that the change is entered, and treats repeated override patterns as evidence that the model is missing a constraint rather than as a compliance problem.

Frequently asked questions

Can we schedule finitely without replacing our planning system?

Usually yes, and that is the normal arrangement. The planning system continues to own orders, structures, stock and purchasing, while the scheduling tool reads open orders and resource data, produces a sequence, and writes dates back. The integration work is not trivial and the dependency runs deep: if order status in the planning system lags reality, the scheduler is optimising against yesterday. Confirming that status flows back promptly is a prerequisite worth testing before the tool is chosen.

How detailed does the resource model need to be?

Detailed enough to include whatever genuinely limits output, and no more. Modelling every machine when one furnace decides throughput adds maintenance burden without changing decisions. On the other hand, leaving out shared tooling, qualified operators or a fixture that only exists in one set will produce sequences that cannot physically run. A good test is to ask experienced supervisors why they would refuse a proposed sequence; each reason they give is a constraint the model probably lacks.

Why did our schedule stop being used after a few months?

The common pattern is erosion of trust rather than a single failure. Dates drift because job status is reported late, the model misses a constraint everyone on the floor knows about, or the sequence changes so often that preparing ahead becomes pointless. Once supervisors resume working from their own list, the data feeding the tool degrades further and the decline accelerates. Recovery means fixing the specific credibility gap people can name, not retraining them on a tool they have already judged.