Sales has asked for a date, or asked to bring an order forward, and the production planner has to answer today. The planning tool, a spreadsheet or the ERP’s calendar, shows a gap on the filling line on Thursday afternoon. The gap looks like room, and the easy answer is yes.

This is production scheduling as the planner meets it: can the job go in without making another promise impossible? A schedule is feasible only when three things agree: the material is available to start, the constrained resource has enough usable time, and the sequence chosen does not spend that time on changeovers. A gap on a calendar is none of those. It is a space where nothing has been written yet.

Capacity is usable time at the constrained resource

Most plants have one resource that sets the pace: a filling line, a machining centre, a press, an oven. Capacity is the usable time that resource has in the period being planned. Headcount does not measure it, and neither does the shift length. An eight-hour shift with an hour of planned maintenance, a cleaning routine and an operator who also covers goods-in for half an hour has about six usable hours, and the plan should be built against six. The calendar shows eight, and a tool that offers a gap without doing that subtraction is offering time that does not exist.

Changeover is capacity consumed by sequence

Between two jobs the machine may need cleaning, a tooling change or a temperature change, and the time depends on which two jobs they are. Switching between two products in the same family may cost nothing; switching between families may cost an hour. The same set of jobs in a different order can need a different total, which is why adding durations is the wrong arithmetic. The question to ask of any proposed sequence is what the sequence costs, and the answer comes from a changeover matrix, the table of times between every pair of product families.

Material gates the start

Material availability decides when a job can begin, and has no effect on how long it runs. An idle machine with material still awaiting acceptance in goods-in cannot start, and a plan that assumes it can will be right about the duration and wrong about the finish. Received and accepted are different states, and our procurement software guide explains what accepted means; here it is enough that the schedule should look for accepted material before it offers a start time.

Six hours, two jobs and an urgent request

The example that follows is illustrative. One constrained machine has six usable hours left in the shift. Two jobs are due today. Job A needs four hours of run time and job B needs two. On a list of durations they fit with nothing to spare. The machine needs a one-hour changeover between the product families A and B belong to, and no changeover between jobs in the same family.

A then B is four hours, plus one for the changeover, plus two: seven. B then A is two plus one plus four, also seven. One of the two commitments cannot finish today whichever way round they run, and the planner should know that before the shift starts, while there is still time to tell the customer, and not at hour six when the next shift has its own work.

Then an urgent job C arrives. It needs one hour of run time and belongs to the same family as A. Sales wants it first. C then A is one hour, no changeover, then four: five hours, leaving one, which is not enough for B’s two. B moves to tomorrow in full. Keeping B in the day by running B then C then A is two plus one plus one plus four, eight hours, two more than the shift has.

The urgent job did not create time. It decided that B moves, and the only reason C was affordable at all is that it shares a family with A and so cost no changeover.

Material changes the answer once more. If C’s material is held in goods-in awaiting acceptance until mid-shift, the machine starts A, C follows A with no changeover, the total is still five hours, B still moves, and the floor’s instruction is A then C. Real plants add operator availability, tooling, quality holds and several resources on top of this; the shape of the reasoning is the same.

A requested date and a feasible finish

The planner’s job is to say which of two dates they are quoting. The requested due date is what the customer wants. The feasible finish is what the material, the resource time and the sequence together allow. In the example, B’s requested date is today and its feasible finish is tomorrow, and the honest answer to sales is the second one with the reason attached.

A proposed plan and a released instruction

The floor should be working to one released sequence. When the planner tries C then A, or B then C then A, those are proposals, and a proposal that has not been accepted must not appear on the floor as the live instruction. If it does, an operator sets up for C while the material is still in goods-in, or a supervisor sees two versions of the afternoon and picks one.

Release is the moment a proposal becomes the instruction. Before it, the planner can try sequences freely. After it, the sequence changes only when a new version is released, and whoever accepted the trade-off is recorded against it. What makes a released job ready to run, and how progress against it is proved, belongs to our production control guide; this article stops at the point of release.

What priority costs

Priority is a trade. When an urgent job is added to a full resource, something moves, and the planner needs to see what before agreeing: the displaced commitment named, with its customer and its new feasible finish, next to the proposal that displaces it, and a check on whether a different sequence changes the changeover arithmetic enough to save it. In the example nothing saves B today. Knowing that before the shift lets someone with the authority to move that customer’s date make the decision, instead of the floor making it by default at hour six.

What to ask of production scheduling software

Many ERPs plan against infinite capacity by default. The system accepts a due date, works backwards from it, and places the work on the resource without checking whether the resource has the time or whether the sequence costs anything. That is where the gap on the calendar comes from. Finite capacity scheduling means the software checks resource time and sequence before it accepts a date, and tells the planner when the date cannot be met.

Whether a tool does this comes down to a few questions. Does it know the changeover matrix, or only job durations? When a job is inserted, does it show which orders are displaced and their new finish? Does it distinguish a proposed plan from a released one, so the floor sees only the released version? Does it check material availability before offering a start time? Can the release policy, for example who must accept a change that moves a customer date, be changed without rebuilding the schedule?

When a simpler answer is enough

A stable operation with few product families and rare changeovers may not need any of this optimised. It needs disciplined release, so the floor works to one sequence, and reliable inputs, so material and resource time are known before the shift.

If the business already has an ERP or a specialist finite-capacity scheduler that models the changeover matrix and material gates well, and the floor trusts its output, that system should keep doing the calculation. The remaining work is the approval and release workflow around it: who proposes, who accepts a displaced commitment, and how the released version reaches the floor. Our ERP and MES guide covers which system should own which job.

Where Keel fits

Keel is an operations platform shaped around how a business plans and releases work. For the planner in the example, that means the proposed sequence, the constraints it was checked against and the commitment it displaces sit in one place. When the planner proposes C then A, the screen shows B moving to tomorrow and the reason; when a supervisor accepts that, the acceptance is recorded with their name. The floor sees one released sequence, and it changes only when a new version is released. When the business changes its release rule, say by requiring a supervisor to accept any change that moves a customer date, the rule and the planner’s screen change together.

Keel supports tailored operator tools, workflows that combine human steps with processing, and business rules expressed in code. The capacity arithmetic, the changeover rules, the material check and the versioning of plans would all need to be implemented for this business, or integrated from a specialist scheduling system that already does the calculation, and then tested against real shifts. Keel is not a finite-capacity optimiser and does not ship a scheduling board. Keel leads the implementation and agrees the handover with your team.

Keel is not the answer when an ERP or advanced planning tool already models the constraints well and the floor trusts what it produces, or when the operation is simple and stable enough that discipline about release matters more than software. Keel is the right conversation when the planning-to-floor workflow, the release policy and the operator experience need to be the business’s own and need to keep changing, often around an existing scheduler rather than instead of it.

To work through this with one of your own resources, bring one constrained machine, its changeover assumptions and one recent decision to move a job, and talk to Keel about planning and release. We can look at which planning and release responsibilities a Keel implementation should own, and whether Keel fits at all.