Scheduling around a bottleneck machine

Three schedules, and the floor follows none of them

A typical plant runs three schedules at once. The ERP produces one from infinite-capacity logic and standard times that were entered when the machine was new. The planner keeps a real one in a spreadsheet, built from experience and phone calls. The supervisor runs a third one, which is whatever is hot this morning. All three are updated daily. None of them agrees with the others, and the honest version of what happened is only knowable afterwards from the machine data.

Adding an optimizer to that situation usually produces a fourth schedule. The instinct is to reach for better mathematics, and better mathematics is available and cheap. But the reason the first three disagree is not that anyone computed badly. It is that the inputs are wrong, the real constraints are undocumented, and the plan moves faster than people can act on it. Fix those and a fairly simple scheduler outperforms a sophisticated one fed fiction.

Find the constraint from data, and expect it to move

Ask five people which machine is the bottleneck and you will get three answers, all sincere. The loudest machine, the oldest machine and the actual constraint are frequently different machines.

The empirical version is straightforward. Over several weeks, measure how much work is waiting in front of each work centre, how much of the scheduled time each one is actually producing, and where jobs spend their time between release and completion. The constraint is the resource with a persistent queue in front of it and high utilization of its available time. Everything else has idle time, and idle time on a non-constraint is not a problem to be solved — it is the slack that lets the constraint stay fed.

Two findings are common enough to expect. The first is that the constraint moves with product mix: an aluminium week and a steel week can put the queue in different places, so measure by mix rather than in aggregate. The second is that the constraint is not a machine at all. It is often a person — the only certified welder, the only programmer who can write for that control — or a fixture that exists in twos, or an outside process with a fixed weekly truck. When the constraint is a person or a tool, no amount of machine scheduling helps, and the honest recommendation may be to certify a second operator rather than to buy software.

The order of payoff, and it is not the order people buy in

There are four levers here and they are usually pulled in exactly the wrong sequence. Ranked by return on effort, they are: control the release of work, sequence the constraint sensibly, manage the buffer that protects it, and only then improve the optimization.

Release control is the free one. Most plants release work to the floor when the paperwork is ready, which means the floor is loaded far beyond what the constraint can consume. That extra work in process does not increase output — the constraint's rate sets output — but it does lengthen every queue, and queue length is what turns into lead time. The relationship is arithmetic: for a stable process, work in process equals throughput multiplied by cycle time, so if throughput is capped by the constraint, doubling the work on the floor simply doubles how long a job takes to get through it.

The remedy is to release material at the rate the constraint consumes it, with a fixed offset that gives the earlier operations time to deliver. In the theory-of-constraints vocabulary this is the rope: the constraint is the drum that sets the beat, a time buffer protects it, and the rope ties release to consumption. It requires no software, it can be run from a whiteboard, and in our judgment it is the single largest improvement available to a plant that has never done it. It is also unpopular for a week, because a floor that has always looked busy will look less busy, and someone will need to explain that a queue is not the same thing as output.

Sequencing: the trade-off that has no universal answer

Once release is controlled, the next question is what order to run on the constraint, and the tension is between changeovers and dates.

Group similar jobs — same material, same color, same tooling, ascending gauge — and you avoid setups, which on a constrained machine is pure additional capacity. Group too aggressively and jobs at the back of a campaign go late, because the customer who ordered the unusual color waits for the next campaign. Neither extreme is right, and the balance depends on your margin structure, your customers' tolerance and how punitive your late fees are.

The useful move is to make that trade-off explicit rather than emergent. A scheduler is expressing a policy: how much lateness is one hour of setup worth. Write that number down, let the planner change it, and show what happens to the schedule when they do. A tool that lets an experienced planner see the consequence of a policy is worth more than a tool that hides the policy inside an objective function nobody can inspect.

The data the math needs, and what your ERP actually holds

Every scheduling engine needs five inputs, and most plants have accurate versions of one or two.

The setup matrix deserves its own paragraph because it is the one nobody has and everybody needs. Sequence-dependent setup means the changeover cost depends on what ran before, and a single average setup time throws away exactly the information that makes sequencing worth doing.

You can usually recover an approximation without a stopwatch study. Take machine state history, find every transition from one part number to another on the constraint, and take a robust statistic — a median, not a mean, since interrupted setups produce outliers — of the gap between the last good cycle of one part and the first good cycle of the next. That gives a matrix that is imperfect and far better than one number. Show it to the setup crew before using it. They will correct several cells immediately, and that conversation is worth more than the data cleaning.

The constraints nobody wrote down

This is where implementations actually fail. A scheduler produces a plan that is infeasible for reasons the model never knew, the floor overrides it twice, and by the end of the month everyone is back on the spreadsheet.

The undocumented constraints are always specific and always known to somebody. There are two fixtures, so two of those jobs cannot run at once. Only one operator is certified on that machine and they work days. The furnace is uneconomic below a certain load, so it waits for a full basket. That customer will not accept an early delivery, so building ahead is not a solution. The tool goes out for regrind and comes back in a week. Second shift does not run on Fridays in summer. The seals for that job have a cure time before the next operation. Two of these jobs are for the same customer and must ship together.

None of that is in the ERP. All of it is in the heads of three people, and the way to get it is to sit with the planner for two days and ask, of every job they move by hand, why they moved it. Each answer is a rule. Some become hard constraints in the model, some become soft preferences with a weight, and some turn out to be habit rather than requirement — which is itself a valuable finding.

Do this before selecting a tool, not after. It also gives you a real requirement to evaluate software against, which is the difference between a demo and an assessment.

Stability beats optimality

Rescheduling on every event feels like the modern answer and is usually a mistake. A plan that keeps changing cannot be prepared for: material is staged, tooling is pulled, operators are assigned, and every change wastes some of that preparation. In materials planning this churn has a name — nervousness — and it is a known cost of frequent replanning rather than a novel discovery.

The pattern that works is a frozen window plus scheduled recomputation. Inside the freeze — commonly a shift or a day, and you should set it to the time it takes to prepare work — the sequence does not change except for genuine emergencies, and emergencies are logged as exceptions so you can count them. Beyond the freeze, the plan is advisory and everyone knows it. Recompute on a fixed cadence, plus on real trigger events such as a constraint breakdown or a hot order, and where two plans score nearly the same, prefer the one closer to the plan already published.

Then measure schedule adherence and treat it as the primary health metric of the whole system. A plan followed 90% of the time creates more output than a theoretically better plan followed 60% of the time, and adherence tells you which one you have.

What the solver actually needs to be

For a single constraint with sequence-dependent setups and a few hundred jobs in the horizon, this is a well-understood problem and good open tooling solves it. Constraint programming solvers are a natural fit because the awkward rules — this and that cannot overlap, this needs that operator, this must follow that by at least four hours — are expressible directly rather than being contorted into a linear formulation.

Two practical notes. Give the solver a time budget and take the best answer it has at the end; a schedule that is a few percent from optimal and arrives in thirty seconds beats a proven optimum that arrives after the shift started. And start it from the current published plan, so it prefers to keep what is already staged.

Whether you need any of this is a separate question. If the constraint runs a handful of long jobs a week, a planner with a spreadsheet and a good sequencing rule will get most of the available benefit. Solvers earn their place when the combinatorics genuinely exceed a person: many short jobs, a large setup matrix, several interacting resources, and a horizon long enough that greedy choices compound.

How you will know whether it worked

• Constraint utilization during scheduled time — the only utilization figure that maps to shipments
• Setup hours per week on the constraint — the direct measure of whether sequencing is helping
• Work in process in front of the constraint — should fall and stay fallen after release control
• Buffer status — how often the constraint came close to starving, in zones rather than a number
• Schedule adherence — did the plan get followed, tracked separately from whether it was good
• On-time delivery and lead time spread — the outcomes the customer feels
• Expedite count — the honest measure of how often the system was overridden

Take a baseline of all seven before changing anything. Skipping the baseline is the most common reason a project that worked cannot prove it worked, and an improvement nobody can demonstrate does not get funded a second time.

The mistakes we see

• Optimizing a machine that is not the constraint — produces inventory, not shipments
• Feeding the model standard times built for costing — costing standards and physical run times are different numbers with different purposes
• One average setup time — which throws away the only information sequencing can act on
• Rescheduling continuously — nobody can prepare for a plan that keeps moving
• Modeling only the machines — when the real constraint is a person, a fixture or an outside process
• Buying the tool before interviewing the planner — the requirement lives in the moves they make by hand
• No baseline — so the result is a matter of opinion afterwards

Where this does not work

Two honest exclusions. In a true job shop, where routings are drawn per order and half the work is new, scheduling software has thin data to stand on and the higher-value problems are usually quoting accuracy and capacity visibility — knowing what you can promise before you promise it. Start there.

And in a well-balanced line with no dominant constraint, the drum-buffer-rope framing does not apply cleanly. The constraint wanders, and the useful work is variability reduction and flow rather than sequencing. A scheduler installed on such a line tends to chase a constraint that has already moved.

Bottom line

Find the constraint from queue and utilization data rather than opinion, and re-check it by product mix. Control release to the constraint's rate before buying anything, because it is free and it is the biggest single lever. Recover a real setup matrix from machine history and have the setup crew correct it. Spend two days with the planner writing down the rules that exist only in their head. Freeze the plan long enough for people to prepare, prefer stability over marginal optimality, and measure adherence as the health of the system. The solver is the last thing to worry about, and by the time you get to it, it will be the easiest decision you make.

Frequently asked questions