On Friday afternoon, the new scheduling prototype produces an apparently excellent plan. Machine time is used efficiently, two jobs finish before their deadlines, and the solver reports that every constraint has been met. By Monday morning, a supervisor has found a problem: the machine cannot be prepared for the second job when the schedule says it should start.
Consider a small, illustrative version of the incident. A machine is available from 8:00 a.m. to 4:00 p.m. Job A needs two hours. Job B also needs two hours, but running B after A requires a 30-minute setup performed by a qualified technician. B must finish by 3:00 p.m. The prototype schedules A from 8:00 to 10:00 and B from 10:00 to noon. It has recorded processing times and due dates, but not the setup requirement or the technician's availability.
The technician cannot arrive before noon. The model's neat schedule is therefore impossible. Once the missing facts are included, a workable plan is A from 8:00 to 10:00, an idle interval until noon, setup from noon to 12:30, and B from 12:30 to 2:30. B still meets its deadline. The corrected plan merely looks less impressive on a machine-utilization chart.
The numbers and circumstances here are invented to explain a modeling failure, not to describe a 4colors customer project. The distinction they expose is real: a solver can be completely correct about the problem it was given and still produce the wrong decision for the operation.
The new model needs not only an extra half-hour in a sequence but a link between that interval, the machine, and a qualified technician's calendar.
The constraint nobody thought to write down
The Friday model omitted what experienced planners knew without thinking: some transitions need a particular person, that person has other commitments, and machine availability does not imply setup availability. A schedule's feasibility depends on all three. The new model needs not only an extra half-hour in a sequence but a link between that interval, the machine, and a qualified technician's calendar.
This is why the difficult part of a scheduling project often begins before any sophisticated search. Machine capacities and job durations are easy to export. Informal rules usually appear in the explanation of why a seemingly legal assignment would never be made. A supervisor may say that the line can run a product but cannot switch to it on the night shift. A warehouse manager may know that material marked as ordered will not be ready at the start of the shift. Each fact changes the set of feasible plans.
Asking planners to inspect real past schedules, including disrupted ones, is more revealing than collecting a list of idealized constraints in isolation. A useful question is not simply whether the algorithm's schedule looks good. It is what would stop each operation from happening at the specified time.
What a score can conceal
Suppose the corrected model now accounts for setup and technician availability, but its only objective is to minimize machine idle time. It might delay an urgent job or produce an undesirable sequence to keep the machine occupied. The rules would be respected, and the objective might improve, yet the plan could still be economically worse.
The problem is different from the missing technician. In the first case, the model's definition of a valid schedule was incomplete. Here, a feasible schedule is being evaluated against the wrong priorities. Production teams need to distinguish nonnegotiable requirements from preferences that can be traded: delivery commitments, setup costs, overtime, work in progress, and stability of a published plan. Sometimes several objectives should be ranked rather than hidden inside one unexplained weighted score.
The planner's role also changes from checking whether a chart is visually tidy to examining what the algorithm assumed.
There is an important reward in making these distinctions explicit. A disagreement between production and sales may reveal that a deadline is a firm customer commitment, not merely a desired date. What looked like a mathematical modeling detail becomes an operational decision the organization can settle.
Monday happens every week
A prototype is usually tested on a fixed set of inputs. The live operation is not fixed. Technicians become unavailable; machines fail; material deliveries slip; jobs arrive after the plan has been published. A solution process that takes hours to rebuild the model whenever this happens may succeed as a demonstration and fail as a daily tool.
An operational system therefore needs more than a search algorithm. It needs current inputs, explicit constraint definitions, useful results before a decision deadline, and a way to revise the plan without unnecessarily overturning work already started. Reoptimization can use a previous solution as a starting point where the interface supports it, but protecting completed work and other fixed commitments must be modeled as actual requirements.
The planner's role also changes from checking whether a chart is visually tidy to examining what the algorithm assumed. Why is this machine idle? What would change if a technician arrived earlier? Is the improvement worth the additional overtime? A system that can answer such questions invites scrutiny. One that hides its rules encourages people to rebuild the schedule elsewhere.
The lesson of the idle machine
The half-hour setup is not the entire story. The larger discovery is that utilization, feasibility, operational value, and adoptability are separate properties of a plan. A good optimization project connects them: the data must describe the work, the model must describe what is possible, the objective must describe what matters, and the surrounding workflow must make the answer usable.
The Friday plan was better only inside an incomplete mathematical world. The Monday plan, with its apparently wasted two hours, is the one that can actually be executed. That is the standard against which optimization has to be judged.