Where spreadsheet scheduling runs out: when constraint-based scheduling is worth it

The schedule is built on Friday. Monday morning a machine breaks, a customer pulls a date forward, a material runs late. The spreadsheet opens again. Rows shift down, a few jobs swap places, a mould clash goes unnoticed. In the afternoon the floor calls.

Nothing is wrong with that spreadsheet. It has simply reached the end of what it can do.

A spreadsheet works right up until the constraints touch each other.

A spreadsheet is a good sequencing tool. You order jobs by date, sum up capacity, see the gaps. With a single constraint — say machine capacity alone — it does the job properly and cheaply. That is not something to look down on.

The difficulty starts when constraints link. A job can run only on certain machines. That machine needs a particular mould. That mould may be sitting in another job. The operator setting it up has to be qualified for the station. And the job has a due date. Pulling one job forward occupies the mould; an occupied mould pushes another job; the pushed job unsettles a due date; rescuing that date pulls a third job forward, and the chain restarts.

This is a combinatorial problem. As the number of jobs grows, the number of possible sequences grows far faster. A person cannot track that growth. Neither can a spreadsheet, because a spreadsheet shows what you typed into it — not the clash you did not type.

Trial-and-error replanning carries a cost nobody sees.

That cost accumulates in three places.

The planner's time. Every disruption means rebuilding the schedule by hand. The task usually falls to whoever knows the work most closely, and it takes much of that person's day.

A decision tied to one person. Why the schedule is arranged this way is rarely written down. The logic lives in that person's head. When they take leave, the schedule goes with them.

The alternative nobody saw. A hand-built schedule is the first one that works — not necessarily the most suitable one. Whether a sequence existed with fewer changeovers stays unknown, because no comparison was ever made. That loss does not appear as a mistake; it does not appear at all.

What a constraint model asks for.

Constraint-based scheduling is not magic. It asks you to write your rules down. The input is typically this.

Jobs and their routings. What steps each job passes through, in what order, and how long each step takes.

Resources and eligibility. Which machine can run which job. Which mould fits which machine. Which operator is qualified at which station. Shift calendars and planned maintenance windows.

Changeover times. The time lost moving from one job to the next. This is usually sequence-dependent: moving between two similar setups is not the same as moving to an entirely different one. This is often where scheduling produces the most value.

Due dates and priorities. Which dates are firm and which are flexible. What the cost of lateness is measured in.

The objective. What you are trying to improve: late jobs, total changeover time, or machine idleness. A model improves only what it is told to improve. That choice has to be made openly and written down.

Reading that list, the point becomes clear: the hard part is not the algorithm, it is writing the rules. Most companies already have the rules. They are just spoken, not recorded.

Once the rules are written, the model does not hand back one schedule; it hands back a choice among schedules that all obey the rules. What decides between them is the objective. When something goes wrong, the schedule is not rebuilt from zero — it is re-run against the same rules, with only the input changed. The planner's job shifts from dragging rows to keeping the constraints current.

Leaving the spreadsheet is often the wrong answer.

In these situations a spreadsheet is a sensible tool and should be left where it is.

When the constraints are few and do not interact. When the number of jobs in play fits in one person's head. When the schedule is built weekly and largely survives the week. When times and changeovers are not measured at all yet — a model does not invent data that does not exist; it only organises what it is given. And when the real bottleneck is not the schedule but material arriving late.

That last one matters. Scheduling does not solve a supply problem. A solution installed in the wrong place costs more than no solution at all: it spends the money and the trust.

When the switch pays for itself.

The line has been crossed once these signals start stacking up. The schedule is rebuilt from scratch more than once a week. Mould, machine or operator clashes are found on the floor rather than on paper, and regularly. Changeovers eat a serious share of available time. Due dates are promised to customers without anyone able to check capacity. And the person who builds the schedule cannot take leave.

One of these alone is not enough. Three at once means the problem is not how the spreadsheet is used — it is the spreadsheet.

Where to start.

By writing the constraints down. For one week, record why the schedule changed: one line per change. Breakdown, material, rush order, clash. That record answers two questions at once — which constraints are real, and how much time replanning actually consumes. Both are things companies discuss today by estimate.

At Miletus the work is built in this order: measure the constraints and the changeover times first, then build the model against that measurement. The model does not replace the planner; it shows alternatives that obey the planner's own rules. And the same measurement is what tells you the spreadsheet is still enough.