The Routing Says Eight Cavities. The Mould Has Run Four Since March.

A mould with eight cavities has been running on four since a repair in March. Everyone on the floor knows. The routing in the system still says eight, so every plan built from it assumes twice the output that exists, every quoted lead time is derived from a capacity the factory does not have, and every cost per unit is understated by the same factor.

Nobody hid this. It was simply never anybody's job to change a record in a system when a physical thing changed on a machine, and there is no moment at which the divergence announces itself. The consequence is not a wrong report — it is that the schedule stops being believed, and once the floor is sequencing work by its own judgement, the planning system is a data-entry obligation rather than an instrument. Fixing it means treating the routing as a live description of the machine, with a named owner and a trigger on every physical change, and building the plan against real constraints rather than against infinite capacity.

Below, in order: the four ways a routing drifts away from the machine, why the changeover sequence is usually the largest single lever on a factory's output, and what finite capacity has to mean before it is worth buying.

The four drifts

Physical change. A cavity blocked, a head removed, a line running at reduced speed pending a part. The machine's capability changes and the record does not. This is the commonest one and the easiest to fix, because it is a process gap rather than a modelling problem: a maintenance event that changes capability has to raise a task against the routing, and somebody has to own closing it.

Silent improvement. The opposite case, and it is real. A process is improved, cycle time falls, and the routing is never updated because nothing broke. The factory then under-promises, over-costs, and cannot explain why its efficiency figures are consistently above target. Good news does not generate a corrective action, which is precisely why it persists longer.

Product change without routing change. A specification is altered, a material is substituted, an operation is added at the customer's request — and the routing that describes how to make it stays as it was. This is the same failure as an uncontrolled change to the bill of material, and it is dealt with in why a bill of material needs versions and an effective date.

Optimistic commissioning. The routing was set from the machine's rated output rather than from an observed run. The factory has therefore never once hit its standard, and the standard was never achievable. This one poisons the variance figures too, because everything appears unfavourable and the numbers are dismissed wholesale.

Only the first of the four looks like a problem when it happens. The other three look like nothing at all, which is why a routing review has to be a scheduled event rather than a response.

Changeovers are where the capacity actually is

In most discrete and process factories, the sequence in which work runs affects total output more than the speed of any machine — and the sequence is usually decided by whoever is on the phone.

The classic example is colour. Running black before white means a long clean; the reverse is short. Multiply by every changeover in a week and you have a large number of hours that exist or do not depending on an ordering decision made informally. The same shape applies to grades, gauges, materials and anything with a purge, a clean-down or a setup that depends on what ran before it.

Making this a system property rather than a personal skill needs two things, and they are separable.

Changeover cost has to be modelled as a function of the transition, not as a constant on the operation. The cost of moving from A to B is not the same as B to A, and a system that carries one setup time per product cannot express that. This is a modelling requirement most standard systems meet only partially, and it is worth establishing early whether yours does.

The sequencing decision has to be visible and overridable. A factory will not, and should not, accept a black box that issues an order it cannot argue with. A proposed sequence with the reasoning shown, that a planner can override with a recorded reason, is used. One that cannot be overridden is bypassed, and then the plan and the floor diverge permanently.

There is a third, human point. The person who currently holds the sequencing knowledge is usually very good at it, and any system that appears to replace them will fail politically before it fails technically. The honest framing is that the system holds the routine cases so that their attention goes to the exceptions, which is also true.

What finite capacity has to mean

"Finite capacity scheduling" is sold as a feature and is usually bought without anybody asking what the plan would be constrained by. Four inputs decide whether it produces something usable:

Real routings, as above. A finite plan built on wrong standards is a precise answer to the wrong question, and it is more dangerous than infinite capacity because it looks authoritative.

Real availability. Shift patterns, planned maintenance windows, and the machine that is down. If planned maintenance is not in the calendar as unavailable time, the plan will schedule straight through it and then blame the floor for the miss — which is one of the arguments in treating maintenance as a production constraint rather than a cost centre.

Real constraints beyond the machine. Labour with the right skill, tooling that is shared between machines, a curing or drying step that occupies space rather than a work centre. A plan that only knows about machines will be defeated by the one mould shared between two presses.

A planning horizon somebody actually believes. Most factories can plan a week well and a quarter badly. Producing a detailed twelve-week schedule that is wrong from week three teaches everyone to ignore all of it, including the accurate part.

Get those four and the plan is worth arguing with. Miss any of them and you have bought a more expensive way to produce the same list.

The maintenance nobody budgets for

Routings need an owner and a review cycle, in the same way master data does. Concretely:

• A named owner per product family, usually production engineering rather than planning, because the owner has to be able to say what the machine does.
• A trigger from maintenance: any work order that changes a machine's capability raises a routing review task. This is one integration point and it closes the largest of the four drifts.
• A quarterly observed run on a sample of routings — actually standing there with a stopwatch on one operation per family per quarter. It is unglamorous, it takes a morning, and it is the only thing that catches silent improvement.
• A rule that a routing change is recorded with a reason, so that next year somebody can tell whether the standard moved because the process changed or because a target was missed.

None of that is software. It is the operating discipline the software depends on, and it is the part that is missing in almost every factory where the planning module is described as having failed.

The broader sequence this fits into — what to establish first, and which decisions foreclose others — is set out in what a manufacturing implementation has to get right and in what order. And if the symptom you recognise is that nobody trusts the schedule, that is worth treating as a data problem before treating it as a planning-software problem, because replacing the planner over wrong routings reproduces the same result at greater cost. Establishing which of the two you have is a short piece of work and it is where an independent read of the system usually starts.