Finite capacity scheduling: planning against limits the plant actually has

Why infinite loading keeps producing plans nobody can run

Backward scheduling from a due date with unlimited capacity puts hours where they are convenient rather than where they can happen, so several jobs are assigned the same machine in the same window. The plan looks tidy in aggregate and disintegrates at the work centre. Supervisors then reintroduce the missing constraint by hand, which is finite scheduling done informally and inconsistently. The argument for formalising it is not sophistication; it is that the sequencing decision gets made once, visibly, using the same rules each time, instead of being remade every morning by whoever is on shift.

The master data bar this discipline sets

A finite schedule is only as good as its inputs, and it will surface every stale one. Run rates must reflect measured output including minor stoppages, not brochure figures. Setup times must include fetching tooling, fitting, first-off and approval, and where setup depends on the previous job the sequence relationships have to be captured. Calendars must deduct breaks, planned maintenance, training and known absence. Alternate routings must be flagged with their real rate penalty. Committing to this data maintenance is a standing cost, and a plant unwilling to fund it should stay with informal sequencing rather than build a precise model of a factory that does not exist.

Modelling only the resources that genuinely constrain

Modelling every work centre finitely is a common way to fail, because each additional modelled resource multiplies the data maintenance burden and the chances of a spurious bottleneck. Start with the resources that actually limit output: the constraint machine, the shared oven or paint line, a skilled operator group, a set of fixtures. Treat the rest as effectively unlimited and let the floor manage them. Review the list when the mix shifts, because a resource that had slack under last year's mix may now be tight. The test for including a resource is whether its unavailability has ever forced a delivery to move.

What to do when the schedule says the order will be late

Finite scheduling earns its cost at this moment. The system says a promised order cannot be produced in time, and someone must act: authorise overtime, split the batch, move work to a slower alternate route, buy the part outside, or tell the customer. The failure pattern is treating the message as a system complaint and overriding it, which converts an early warning into a late surprise. Route these exceptions to a daily review with the authority to spend money, and record which lever was pulled. Over time the record shows whether the plant is short of capacity or short of discipline.

Keeping the model honest as the plant changes

Every improvement, new tool, retrained operator and rebuilt machine changes the numbers the schedule relies on, and nobody's job description says to update them. Assign the maintenance of routings and setup data to a named owner and give them a trigger list: engineering change, new product, equipment modification, sustained variance between planned and actual run time. Periodically sample high-runner items and compare scheduled duration against recorded duration. Where the gap is systematic rather than random, the master data is wrong, not the floor. A model left unmaintained slowly reverts to being ignored, and the informal sequencing quietly returns.

Frequently asked questions

Do we need finite scheduling if we already schedule the bottleneck by hand?

Not necessarily. A single stable constraint scheduled carefully by an experienced person often outperforms a poorly maintained model. The case for formalising grows when the constraint moves with the product mix, when several resources interact through shared tooling or labour, when the person doing it by hand is a single point of failure, or when the plant needs to answer delivery questions consistently rather than from one individual's memory.

How do we handle unplanned downtime in a finite schedule?

Two mechanisms. Build an availability allowance into the resource calendar so the model does not assume perfect running, and define a rescheduling trigger for events large enough to matter. Small stoppages should be absorbed by the allowance rather than causing a reissue. Large events should force a review that reconsiders sequence and commitments. Without both, the schedule either flatters the plant continuously or thrashes every time a machine coughs.

What is the first thing to fix if the finite schedule is not trusted?

Setup time, almost always. It is the field most often entered once when the routing was created and never revised, and it is the field with the largest effect on a sequence-sensitive schedule. Time a sample of real changeovers end to end, from the last good part of the previous job to the first good part of the next, and compare with the recorded figure. Correcting that one field usually restores more credibility than any other single change.