Lessons · Lesson 6 of 6
- 01 · What a sewing machine actually reports
- 02 · Three layers, and what each one is for
- 03 · Retrofitting: the sensor decides the question you can ask
- 04 · Downtime, and the reason a machine cannot give you
- 05 · The integration nobody budgets: one bundle, five names
- 06 · The count that drifts, and the hour a week that catches it
The count that drifts, and the hour a week that catches it
Detect a one-directional bias in an inferred count before it becomes a shipment, and judge a sensor programme by the decisions it changed rather than by the numbers it produced.
Lesson 6 of 6 · 17 min
The situation
18 July, five days before the ship date on purchase order BW-77412. Frances Oldbury at Brackwater has the container booked. The execution layer says 94,110 of 96,000 pieces are made, so the last 1,890 are a day and a half of work.
Rowena walks the floor and counts. Packing has 86,720. The sewing floor is holding 1,240. The factory has 8,040 pieces to make, not 1,890, and it has five days.
Nothing broke on 18 July. The gap had been opening since February, at a rate small enough that no report ever showed it.
Why nobody saw it
| Week | System says made | Packed | Gap | Gap as a share of the report |
|---|---|---|---|---|
| 4 | 18,420 | 17,980 | 440 | 2.4% |
| 8 | 41,660 | 39,910 | 1,750 | 4.2% |
| 12 | 68,240 | 63,890 | 4,350 | 6.4% |
| 16 | 94,110 | 86,720 | 7,390 | 7.9% |
Now look at why that table alarmed nobody who saw it. A gap between production and packing is exactly what work in progress looks like. FL-318 ran on four lines at 372 pieces a line-day. The floor normally carries about four days of goods between the last sewing operation and a packed carton, which is roughly 5,952 pieces. At week 12 the gap was 4,350, which is less than normal work in progress. A merchandiser glancing at it would conclude the floor was running lean.
The gap only becomes a fact when the order finishes and work in progress has to go to zero. It never did.
Final reconciliation, on 18 July:
- reported made: 94,110
- physically packed: 86,720
- physically on the floor: 1,240
- therefore actually made: 87,960
- overstated by 6,150 pieces — 7.0% of everything that existed
There are two causes, and both were met earlier in this course. 1,704 pieces are the re-cut bundles from lesson 5 that were opened and never voided. The remaining 4,446 are the cycle-count bias from lesson 1: the thread chain, test stitches, repairs and a constant taken from a size M sample, building up at 5.1% of true output for twenty-three weeks.
What it cost
| USD | |
|---|---|
| Five days of overtime across four lines to close the gap | 4,986.36 |
| Brackwater's late-delivery clause, 3% on the 24,000 pieces that shipped late | 6,444.00 |
| Total | 11,430.36 |
Air freight was priced and refused. The delivery went six days late by sea, which is why the number is as small as it is. A buyer with a fixed date for putting the range in the shops would have made it much larger.
The reconciliation, and why an hour is enough
The protocol Sumilon now runs takes one supervisor, one hour, once a week:
- Pick one line and one hour, both at random.
- Count by hand every good garment that leaves the last sewing operation in that hour.
- Read the system's count for the same line and the same hour.
- Write both numbers, the difference and the date in a book. Do nothing else.
48 hours a year at USD 5.90 an hour is USD 283.20. Against USD 11,430.36 on one order, that is a return of forty times. And the same kind of error would have been caught on every order after it.
The reason it works is worth understanding, because it looks too crude to work. A hand count taken for an hour has real error of its own: a part-bundle at the boundary, a miscount, a repair counted twice. Call it 3% either way. But the error in the count is random and the error in the system is not. Average four weekly counts and the sampling error falls to about 1.5%, while a bias of 7.0% that always pushes one way does not fall at all. Within a month the bias stands more than four times clear of the noise. One count settles nothing. Four settle it.
Then the correction. Machine 214's constant went from 641 cycles a garment to 711.7. The sewn length was re-derived from the production garment in the running size mix, plus measured chain and repairs. The same shift that had been reported as 418 pieces now reports 377, against 372 counted. The error goes from 12.6% to 1.4%, and no hardware changed.
Did the programme pay?
Sumilon spent USD 329,014 over three years on 412 machines. That is USD 266.19 a machine a year, or USD 0.067 a garment on the factory's own volume: 0.75% of an FOB price of USD 8.95. FOB is the price of the goods loaded on board at the port of export.
It was sold on five things. Judge each by whether a decision changed.
| What it was sold on | Did a decision change? |
|---|---|
| Live output per line | No. The hand-written hourly board was already within 2% and hourly is fast enough for the decision it feeds |
| Operator efficiency league tables | No, and withdrawn — it ranked people on an inferred count |
| Machine utilisation | No. At the needle times in lesson 3 the number cannot be managed |
| Downtime by cause, once the codes were cut to seven | Yes — operation 88 was starving the finishing end |
| Operation-level cycles read against the routing | Yes — line balancing, one operator moved on most lines |
The two that changed a decision are worth USD 50,438 and USD 17,457 a year, on the factory's contribution of USD 1.18 a piece. That is USD 67,895 against an annual programme cost of USD 109,671.33. A ratio of 0.62. On those two findings alone the programme does not pay.
It reaches break-even only when you add the thing nobody sold and nobody costed: the weekly hand count, which caught the same kind of bias on four later styles for an estimated USD 41,900. That brings it to USD 109,795 against USD 109,671.33, a ratio of 1.001.
That is inside the error of every input. So the honest conclusion is not "it paid". It is this: it neither paid nor lost, and the case for keeping it rests on the findings it can still make next year, not on this arithmetic. That is a real answer and a defensible one. "It paid for itself" would not have been.
Prompt · Judge a sensor programme by the decisions it changed
Before signing a machine-data quotation, and at the end of the first year, when somebody is about to claim it paid for itself.
Act as a factory financial controller who has no stake in whether the answer is yes or no, and who will not accept a benefit that cannot be traced to a decision somebody actually made differently. I want a machine-data programme judged honestly. Facts: factory [NAME], machine count by class [LIST], how many can be instrumented and how many cannot [NUMBERS], quoted programme cost line by line [PASTE THE QUOTATION], actual cost line by line if the programme has run [PASTE IT], annual output in pieces [NUMBER], average selling price and contribution per piece [AMOUNTS], and the promises the programme was sold on [LIST THEM AS THEY WERE WRITTEN]. Do the following. First, restate the cost per machine per year and per piece produced, and as a share of the selling price. Second, take every promise in turn and ask one question of it: did a decision change, and can you name the decision, the date and the person? Mark each promise as CHANGED A DECISION, NO CHANGE, or WITHDRAWN, and refuse to count a benefit you cannot name a decision for. Third, value only the promises that changed a decision, showing the arithmetic in pieces before money. Fourth, give me the ratio of annual value to annual cost on those alone, and say plainly whether the programme pays on them. Fifth, list separately any avoided losses, state that they cannot be proved, and show me the ratio with and without them. Sixth, identify which single input the conclusion is most sensitive to and tell me what would change the answer. Seventh, if the ratio lands near one, say so and refuse to round it into a verdict. Recommend on the findings still available next year instead. Name every assumption in a list at the end.
AI can make mistakes — check anything you act on.
Check yourselfYour system's cumulative output has been running 5% above packed output all season. Your production manager says that is just work in progress. How do you settle it without waiting for the order to finish?Show the answer
Count the floor. Work in progress is a physical thing. Walk the line, count what is between the last sewing operation and the packing table, and compare it with the gap. If the gap is bigger than what is standing there, the difference is not work in progress and never was. It takes an afternoon, and it is the only test that separates the two explanations before the order ends.
Course 24.3 takes the numbers this course has made trustworthy and decides what is worth putting on a screen. Course 24.6 asks the question one level up: whether a factory should start a programme like this at all, and in what order.