The changeover the plan cannot see

Monday morning, a press shop. The plan for the week was released on Friday and it is a good plan: every order in a slot, every slot adding up. The first job runs clean. The second job needs a different die, and the die is on the other press, where it will stay until a job finishes on Tuesday.

The setter does what setters do. He pulls a third order forward, one whose die is on the rack, and runs that instead. By ten o’clock the week is a different week from the one in the plan, and the planner finds out at the Wednesday meeting, when a customer date that was comfortable on Friday has quietly become impossible.

Nobody made a mistake. The planner sequenced correctly against what the system told her. The setter made the only sensible call available to him. The customer was given a date in good faith.

The cause is one assumption buried so deep in the plan that nobody sees it any more: that a changeover costs the same whatever you are coming from and whatever you are going to. On most floors it does not. Going from a light product to a heavy one on the same machine might be twenty minutes; the reverse might be two hours, because the machine has to be cleaned, recalibrated and trialled. The plan holds one number. The floor lives with a matrix.

Where the plan and the floor part company

The changeover depends on the previous product, not on the next one. A routing lists a setup time per operation, as if the operation existed on its own. On the floor the cost of starting a job is mostly the cost of ending the one before it: the colour that has to be flushed, the fixture that has to come off, the temperature that has to come down. The same job is cheap after one neighbour and expensive after another, and a plan that cannot express that is sequencing blind.

The tooling is somewhere else. A die, a fixture, a mould, a set of change parts. The plan assumes it is available because it exists. The floor knows it is on another machine, in the toolroom for repair, or in a cabinet that only one person has the key to. A changeover that cannot start is not a long changeover; it is an order that moves without anybody deciding to move it.

The crew is not interchangeable. A changeover run by the setter who has done it two hundred times is a different event from the same changeover run by somebody covering a shift. The floor knows which shift to put a difficult job on. The plan does not know there are shifts.

The real time is never written down. The machine stops, the changeover happens, the machine starts. What gets recorded, if anything, is the standard. The true duration, with the search for a missing clamp and the two trial pieces that went in the scrap bin, disappears the moment the first good part comes off. So the standard is never corrected.

The floor resequences and the plan does not hear about it. When the setter pulls an order forward he is doing the right thing. The problem is that the plan still thinks the original sequence is running, and every date downstream is now calculated from a fiction. The gap surfaces at the weekly meeting, by which time the week is half gone.

What to do instead

Record the changeover as it actually happens. Most machines already show when they stop and when they start producing good parts again; that is the changeover, measured, without anybody filling in a form. Where the machine says nothing, a scan or a tap on a tablet at the start and end is enough. Read from the equipment, never written to it.

Keep the number per transition, not per operation. From product A to product B on machine 3. After a few months of real data the matrix fills itself in, and the gaps are the transitions you have never run, which is itself useful to know before you quote a date that depends on one.

Let the plan see the tooling and the crew. A die that is mounted on another press is a constraint, not a footnote. So is a changeover that only two people can do. These are facts the floor already holds; the plan just needs to be able to hold them too.

Let the system propose a sequence and show its cost. Given real transition times, working out the order that wastes the least of the week is arithmetic, and a machine should do the arithmetic. What it hands the planner is a sequence, the changeovers it implies, the dates that follow, and which constraint drove each choice. Where it cannot see something, it should say so.

The planner decides. The planner knows the customer who will accept a day’s delay and the one who will not, the setter who is off next week, the trial that has to be squeezed in. The system prepares; the person releases. We have written before about why the system should prepare the decision, not make it, and changeovers are where that pattern earns its keep, because the cheapest sequence on paper is rarely the one the floor can run on Tuesday.

A test you can run this week

Take one machine and one week. For every changeover, note three things: what ran before, what ran after, and how long the machine was between the last good part of one and the first good part of the next. Use the machine’s own stop and start times where it has them; a watch otherwise.

At the end of the week, put those durations next to the setup times in your routings. If the real numbers cluster around the standard, your plan is seeing the floor and this is not your problem. If they scatter, and the biggest ones follow particular pairs of products, you have found the changeover the plan cannot see, and you have the first row of the matrix that will fix it.

A date built from a sequence the floor can actually run is what MESCATOR exists to produce: real changeover times read from the machines, held on the works order, and a proposed sequence a planner confirms. It sits next to the question of materials, which one missing screw can answer badly, and the broader argument that a date from standard times is a guess. More on the MESCATOR homepage.