Production scheduling: write the constraints first

1. When the schedule does not stick, the algorithm is rarely the cause

The pattern repeats: the system produces a plan, the team leader glances at it, puts it aside and keeps scheduling from experience. Look closer and the problem is usually the input, not the solver. Missing operations in the routing, one average changeover time, no visibility of material readiness: with all three present, any schedule is a rehearsal.

• Incomplete routing: operations, work centres and standard hours are missing or no longer match the floor, so the schedule computes on assumptions.
• Changeover entered as a fixed number: switching products on the same machine varies widely, so the plan is re-sequenced again and again.
• Material readiness invisible: a job is scheduled for a date when a critical part has not arrived, and the plan collapses that morning.
• No agreed priority: delivery dates, customer tiers and bottleneck operations are ranked differently by different people, so the output is never accepted.

2. Write down the constraints in three tiers

Scheduling input falls into three tiers: hard constraints that cannot be broken, soft constraints that can be traded off, and data constraints that decide whether the plan can be trusted at all. Writing them separately means that when a plan is challenged, you can tell quickly whether the issue is a rule, a trade-off or a data problem.

3. Feed shop-floor data back into the schedule

A schedule is not a one-off calculation. Actual start, finish and downtime must flow back after release, otherwise the next run keeps computing on the previous assumptions and the deviation grows round after round. This is why scheduling usually shares one data path with equipment connectivity and OEE: state collection is what makes a plan verifiable.

• Lock the version on release: every change leaves one revision record, so later deviations can be traced to a source.
• Write back actual start and finish: when the deviation passes an agreed threshold, the next run adjusts its hour assumptions.
• Watch bottleneck equipment separately: downtime and changeover on the bottleneck are collected first, because the schedule is most sensitive there.

4. Roll out in three steps: executable, comparable, optimizable

Scheduling projects lose time when the first version tries to optimise. A steadier order is to make the plan executable, then hold it against the floor, and only then add optimisation targets; without the first two steps there is no baseline for comparing scenarios.

• Step one: replace manual sequencing with finite-capacity scheduling; the goal is an executable plan, not an optimal one.
• Step two: compare plan against actuals week by week and correct work hours, changeover times and material lead times.
• Step three: add optimisation targets such as changeover count and on-time delivery, and compare scenarios once the constraints are stable.

Each step keeps a rollback condition: if plan adherence stays below the agreed level for several weeks, return to manual sequencing in parallel, fix the constraint definitions, and only then continue, rather than adding more algorithm.