Downtime, and the reason a machine cannot give you

The situation

On 12 May two people at Sumilon are working hard on line 4, from the same correct data, on two different problems. Neither problem exists.

Arnel Bacalso has a maintenance report showing micro-stops on line 4 up 81.6% in a week. He has put two technicians on a thread-break investigation. Rowena Sabandal has an output report showing line 4 down 10.3%. She has put it down to the heavier brushed fleece in the new colour, which is a reasonable idea because that fabric genuinely does sew slower. She has changed the needle size and raised the presser-foot pressure on 18 machines.

By Friday, line 4 has lost 228 pieces and gained 61 damaged garments from the presser-foot change, and neither team has found anything. The cause was set on the previous Monday by a planner making a sensible decision that took under a minute.

A shift, seen as gaps

Start with what the pulse train looks like. This is machine 214's shift from lesson 1, sorted by the length of the gap between one burst of stitching and the next.

Stitching itself accounts for 53.1 minutes of the 570. Everything else is the 516.8 minutes above.

Read the top row first. 1,485 gaps under ten seconds are not downtime; they are the operation. A system that reports them as idle time is reporting that sewing a garment involves handling a garment. The most common single error in a first shop-floor deployment is a screen showing 90% idle and a management response to it.

Now read the bottom two rows. 13 gaps, 102.3 minutes, 17.9% of the shift. That is the whole prize. Everything a factory can act on in a machine-data programme is in those 13 events. And the machine's account of every one of them is identical: no pulses.

Six causes, one signal

A four-minute gap on machine 214 is:

• a bundle change that ran long
• a thread break with an awkward re-thread
• the operator away from the machine
• no work, because the previous operation has not delivered
• a machine fault waiting for a mechanic
• a quality check, an audit, or a supervisor's conversation

The pickup cannot tell them apart, and neither can any sensor on the retrofit list in lesson 3. Two of the six are the factory's fault, two are the planner's, one is maintenance's and one is nobody's. They call for four different responses. Without the cause, the 102.3 minutes is a number you can watch fall and rise and never act on.

So the cause has to come from a person, at a terminal, in the moment. That is course 24.1's subject. And this is where a machine-data programme walks straight back into the human-capture problem it thought it had escaped.

What a reason code costs and what it is worth

Sumilon's terminals ask an operator to code any gap over three minutes. Across 395 instrumented machines and 25 working days that is 128,375 events a month. Each one is an interruption asking to be explained.

The first configuration had 22 reason codes in a scrolling list. Month one:

• 29.4% of events were coded at all
• of those, 63% were coded "other"
• so a real reason existed for 10.9% of interruptions

Three of the 22 codes took 61% of all entries, and they were the three sitting at the top of the list before anyone scrolled.

The second configuration had 7 codes on physical buttons, chosen by a rule Rowena wrote on the whiteboard: a code earns its place only if the factory would do something different depending on the answer. "Waiting for work" sends the planner. "Machine fault" sends the mechanic. "No thread" sends the store. "Quality hold" sends the auditor. A code that names something true and changes nobody's behaviour is a keystroke you charge an operator for, several times an hour, forever.

Month three, on 7 buttons:

• 78.6% of events coded
• 19% coded "other"
• a real reason for 63.7% of interruptions

Nothing about the operators changed. The list did.

The mistake nobody made

Back to line 4, and the decision on Monday 8 May.

Cesar Longakit had a 2,400-piece top-up on FL-318 in three colours, and he needed the colours kept apart on the line. So he cut the bundle from 24 pieces to 8. It is a completely normal thing to do, it keeps the colours separate, and no supervisor on any floor would question it.

Here is what it did. At 372 pieces a machine-day, a 24-piece bundle means 15.5 bundle changes. An 8-piece bundle means 46.5. That is 31 extra bundle changes a machine-day, at 1.9 minutes each: 58.9 minutes, or 10.3% of a 570-minute shift. Across 18 operators, that is 17.7 machine-hours a day. Output falls from 372 to 334.

And now the two reports.

Maintenance's report. Every bundle change lands in the one-to-three-minute band. Sumilon's system classifies that band automatically as a micro-stop, and it labels a micro-stop a thread break, because that was true when the rule was written. The band went from 38 gaps a machine-day to 69, up 81.6%, and the report said thread breaks. Two technicians spent four days on it.

Rowena's report. Output fell 10.3%, which is a real fall from a real cause. But an efficiency report divides output by attended minutes and cannot see what the minutes went on. So extra handling looks exactly like a slow operator or a difficult fabric. The heavier fleece was a good idea. The needle change was a correct response to it. It did nothing, because the fabric was not the problem.

One cause, and neither report contains it, because no system on the floor records a bundle size.

The sting is in the classification rule. Before the change, 15.5 of the 38 one-to-three-minute gaps were already bundle changes. That is 40.8% of everything the factory had been calling a thread break, for the whole year the rule had been running. The rule did not become wrong in May. It was always wrong, and May only made it loud.

The fix cost nothing: the planner separated the three colours with coloured bundle cards and put the bundle back to 24. The bundle size had been doing a job that a piece of card does better.

Act as a production manager who has watched operators code downtime badly and knows the fault is in the list rather than in the operators. I want a reason-code set designed against action. Facts: factory [NAME], number of machines and operators [NUMBERS], garment and operations [DESCRIBE], the terminal or device operators use [DESCRIBE, INCLUDING WHETHER IT HAS PHYSICAL BUTTONS], the current code list [PASTE EVERY CODE], current coding rate and share coded as other [PERCENTAGES IF KNOWN], and any automatic classification rule that assigns a cause from the length of a stop [PASTE THE RULE]. Do the following. First, for every code on the current list, name the single action the factory takes when it is entered and who takes it. Where the action is the same whichever way the code is answered, or where there is no action at all, say so plainly. Second, propose a shortened list where every survivor earns its place by changing somebody's next action, and say what is lost by dropping each of the others. Third, tell me the minimum stop length worth coding at all, and justify it from the operation's own handling time rather than from a round number. Fourth, audit the automatic classification rule: list every real cause that falls inside each duration band, estimate the mix between them, and tell me under what ordinary change of plan the mix shifts. Fifth, tell me what the factory will now be blind to, as an explicit list, so I can decide whether I accept it. Sixth, write the exact wording for each button in the language my operators read, short enough to be read at a glance. Do not propose a code whose only purpose is reporting.