THE PRODUCTION LINE CARD

$ production.py takt --demand 5000 --per week --hours-per-day 7.5 --days 5
takt time: 27.0 s a unit (0.450 min)
- available time: 7.5 h x 60 - 0 min breaks = 450 min a shift x 1 shift x 5 days = 2,250 min (135,000 s) a week
- demand: 5,000 units a week
- the line must finish one good unit every 27.0 s; at takt it makes 133.3 an hour.
formula: takt = net available time in the period / units demanded in the period
source: takt time as the Toyota Production System describes it: "the term given to a work-cycle that fulfils each customer's demand" (Toyota Material Handling Europe, Toyota Production System and what it means for business, 2010, p. 9)
limit: takt is set by demand, not by the machines; it assumes the demand is steady across the period and counts good units only. A line planned to run at exactly takt has no slack for stops, scrap or changeovers: plan the bottleneck below takt, or take those losses out of the available time.

$ production.py line stations-draft.csv --demand 5000 --per week --hours-per-day 7.5 --days 5
the line: 6 stations, takt 27.0 s
  station                work s  parallel      cycle s  idle s a unit  against takt
  load                     18.0         1         18.0           16.0  9.0 s spare
  print                    26.0         1         26.0            8.0  1.0 s spare
  cure                     34.0         1         34.0            0.0  OVER by 7.0 s   <- BOTTLENECK
  fold                     22.0         1         22.0           12.0  5.0 s spare
  inspect and refold       15.0         1         15.0           19.0  12.0 s spare
  bag                      12.0         1         12.0           22.0  15.0 s spare
- bottleneck: cure, 34.0 s a unit. The line can go no faster: it makes 105.9 an hour.
- in a week: 3,971 made at the bottleneck's pace, against a demand of 5,000 (available time 2,250 min).
- balance efficiency at the line's own pace: total work 127.0 s / (6 stations x 34.0 s) = 62.3%; balance delay 37.7%; 77.0 s idle across the line for every unit.
- against takt: total work / (stations x takt) = 78.4%
- minimum stations at takt: ceil(127.0 / 27.0) = ceil(4.70) = 5. A lower bound: task order and task sizes may need more.
- over takt: cure. Fix these first; time saved at any other station does not raise output.
formula: bottleneck = the largest station cycle (work / parallel machines); output = 1 / bottleneck cycle; balance efficiency = total work / (machines x cycle); idle a unit = parallel x cycle - work; minimum stations = ceil(total work / takt)
source: the standard line-balancing measures; the problem was first set out by Salveson, The Assembly Line Balancing Problem, Journal of Industrial Engineering 6(3):18-25 (1955); takt time as the Toyota Production System describes it
limit: a steady line with the times you give: averages hide spread, and a station whose times swing will starve or block its neighbours. Buffers, changeovers, scrap and breakdowns are left out (see oee); the minimum stations is a lower bound that ignores the order tasks must follow.

$ production.py loop --part "the inspect-and-refold station" --write loop-refold.md
# THE FIVE STEPS · a working checklist for: the inspect-and-refold station
Work them in this order. Do not skip ahead: the most common waste is making a step better that should not exist.

## [ ] 1. REQUIREMENT · make it less dumb, and name its owner
- The requirement as a number, with units and a date: ______
- Who owns it (a name or a role, never "the department"): ______
- Why it exists, in the owner's words: ______
- Is it still true? What happens if it is halved, or dropped? ______
- If it is a demand, its takt: `production.py takt --demand N --per week --hours-per-day H --days D`

## [ ] 2. DELETE · the part or the process
- List every part, step, move, wait, hand-off, check and form: ______
- Strike each one nobody can defend with a requirement and an owner.
- A safety step, guard, interlock, lockout, required inspection or rest break is never a candidate for deletion or speeding up here; changes to those go to a qualified safety engineer and the machine's maker.
- If nothing ever has to be added back, too little was deleted. What was added back, and why: ______

## [ ] 3. SIMPLIFY AND OPTIMISE · only what survived
- Find the bottleneck: `production.py line stations.csv --takt S`
- Split the losses: `production.py oee --planned … --downtime … --ideal-cycle … --count … --good …`
- Fix the bottleneck first: time saved at any other station does not raise output.

## [ ] 4. SPEED UP THE CYCLE · then prove it
- Time at least five runs before and five after, the same way: `production.py cycle before.csv after.csv`
- Lead time from work in progress: `production.py little --wip N --throughput N --per day`

## [ ] 5. AUTOMATE · last
- Only a step that survived step 2, was simplified in step 3 and was measured in step 4: ______
- Automating a step that should have been deleted is the most expensive mistake on this list.
- Write down the runs, the decision and its owner: ______

written: loop-refold.md
formula: none: an order of work, not a calculation; the numbers come from the other commands
source: references/THE-FIVE-STEPS.md (the five-step design process, its source named there once)
limit: a checklist, not a ruling: it does not decide what is safe to remove. Safety steps, guards and required checks stay; those questions go to a qualified safety engineer and the machine's maker.

$ production.py line stations-cut.csv --takt 27
the line: 5 stations, takt 27.0 s
  station      work s  parallel      cycle s  idle s a unit  against takt
  load           18.0         1         18.0           16.0  9.0 s spare
  print          26.0         1         26.0            8.0  1.0 s spare
  cure           34.0         1         34.0            0.0  OVER by 7.0 s   <- BOTTLENECK
  fold           25.0         1         25.0            9.0  2.0 s spare
  bag            12.0         1         12.0           22.0  15.0 s spare
- bottleneck: cure, 34.0 s a unit. The line can go no faster: it makes 105.9 an hour.
- balance efficiency at the line's own pace: total work 115.0 s / (5 stations x 34.0 s) = 67.6%; balance delay 32.4%; 55.0 s idle across the line for every unit.
- against takt: total work / (stations x takt) = 85.2%
- minimum stations at takt: ceil(115.0 / 27.0) = ceil(4.26) = 5. A lower bound: task order and task sizes may need more.
- over takt: cure. Fix these first; time saved at any other station does not raise output.
formula: bottleneck = the largest station cycle (work / parallel machines); output = 1 / bottleneck cycle; balance efficiency = total work / (machines x cycle); idle a unit = parallel x cycle - work; minimum stations = ceil(total work / takt)
source: the standard line-balancing measures; the problem was first set out by Salveson, The Assembly Line Balancing Problem, Journal of Industrial Engineering 6(3):18-25 (1955); takt time as the Toyota Production System describes it
limit: a steady line with the times you give: averages hide spread, and a station whose times swing will starve or block its neighbours. Buffers, changeovers, scrap and breakdowns are left out (see oee); the minimum stations is a lower bound that ignores the order tasks must follow.

$ production.py line stations-two-dryers.csv --takt 27
the line: 5 stations, takt 27.0 s
  station      work s  parallel      cycle s  idle s a unit  against takt
  load           18.0         1         18.0            8.0  9.0 s spare
  print          26.0         1         26.0            0.0  1.0 s spare   <- BOTTLENECK
  cure           34.0         2         17.0           18.0  10.0 s spare
  fold           25.0         1         25.0            1.0  2.0 s spare
  bag            12.0         1         12.0           14.0  15.0 s spare
- bottleneck: print, 26.0 s a unit. The line can go no faster: it makes 138.5 an hour.
- balance efficiency at the line's own pace: total work 115.0 s / (6 machines x 26.0 s) = 73.7%; balance delay 26.3%; 41.0 s idle across the line for every unit.
- against takt: total work / (machines x takt) = 71.0%
- minimum stations at takt: ceil(115.0 / 27.0) = ceil(4.26) = 5. A lower bound: task order and task sizes may need more.
- every station keeps takt; the bottleneck has 1.00 s of slack.
formula: bottleneck = the largest station cycle (work / parallel machines); output = 1 / bottleneck cycle; balance efficiency = total work / (machines x cycle); idle a unit = parallel x cycle - work; minimum stations = ceil(total work / takt)
source: the standard line-balancing measures; the problem was first set out by Salveson, The Assembly Line Balancing Problem, Journal of Industrial Engineering 6(3):18-25 (1955); takt time as the Toyota Production System describes it
limit: a steady line with the times you give: averages hide spread, and a station whose times swing will starve or block its neighbours. Buffers, changeovers, scrap and breakdowns are left out (see oee); the minimum stations is a lower bound that ignores the order tasks must follow.

$ production.py oee --planned 450 --downtime 52 --ideal-cycle-seconds 22 --count 900 --good 873
OEE 71.1% = availability 88.4% x performance 82.9% x quality 97.0%
- availability: run time 398.0 of 450.0 planned minutes (52.0 down)
- performance: 900 units x 0.367 min ideal = 330.0 min of ideal work in 398.0 min of run time
- quality: 873 good of 900 made (27 not good)
- where the 450.0 planned minutes went: 320.1 fully productive · 52.0 down (breakdowns, changeovers, waiting) · 68.0 slow running and small stops · 9.9 making units that were not good
- the largest loss: slow running and small stops, 68.0 min. Start there.
- check: good x ideal cycle / planned time = 873 x 0.367 / 450.0 = 71.1%
- a benchmark, not a target: the figures commonly quoted from Nakajima as world-class minimums for discrete manufacturing are availability 90%, performance 95%, quality 99%, OEE about 85% (Japan, 1970s). Many plants measure far lower; compare a machine with itself over time.
formula: OEE = A x P x Q; A = (planned - downtime) / planned; P = ideal cycle x count / run time; Q = good / count; the same as good x ideal cycle / planned time
source: Nakajima, Introduction to TPM: Total Productive Maintenance (Productivity Press, 1988; Japanese edition 1984)
limit: only as good as the ideal cycle time: set it to the machine's best rated or demonstrated speed, not the average, or performance hides the speed loss. Planned time leaves out time not scheduled. One machine or line, one period; it does not rank plants or people.

$ production.py cycle print-before.csv print-jig.csv
a column naming people (operator) was ignored: this machine measures stations and processes, never times or ranks individual workers.
before: 8 runs, median 26.35, range 25.8 to 27.2
after:  8 runs, median 24.1, range 23.5 to 24.8
(times in the file's own unit: seconds)
- median change: -2.25 (-8.5%)
- after runs faster than the before median: 8 of 8 (100%)
- a random after run beats a random before run in 100% of the 64 pairs (ties count half)
- Mann-Whitney U = 64, two-sided p = 0.0002 (exact)
VERDICT: FASTER. The drop is real by this test: median 26.35 to 24.1, 8.5% less. Check it against takt before calling it enough.
formula: medians and ranges of each set; U = pairs (before, after) where the after run is faster, ties half; share = U / (before runs x after runs); p from the exact distribution of U when there are no ties, else the normal approximation with tie correction
source: Mann and Whitney, On a Test of Whether One of Two Random Variables is Stochastically Larger than the Other, Annals of Mathematical Statistics 18(1):50-60 (1947)
limit: the runs must be timed the same way: the same start and stop points, the same product, the same conditions. Before and after also differ in time, so a warm machine, a new batch or a practised hand can move the times: this is not a randomised experiment. Five a side is the floor, not a good sample, and a real drop can still be too small to matter.

$ production.py cycle print-before.csv print-squeegee.csv
a column naming people (operator) was ignored: this machine measures stations and processes, never times or ranks individual workers.
before: 8 runs, median 26.35, range 25.8 to 27.2
after:  6 runs, median 26.3, range 25.7 to 26.8
(times in the file's own unit: seconds)
- median change: -0.05 (-0.2%)
- after runs faster than the before median: 3 of 6 (50%)
- a random after run beats a random before run in 57% of the 48 pairs (ties count half)
- Mann-Whitney U = 27.5, two-sided p = 0.6982 (normal approximation with tie correction)
VERDICT: NOT SHOWN. The difference sits inside the run-to-run spread. Treat it as no change yet: time more runs or make a bigger change.
formula: medians and ranges of each set; U = pairs (before, after) where the after run is faster, ties half; share = U / (before runs x after runs); p from the exact distribution of U when there are no ties, else the normal approximation with tie correction
source: Mann and Whitney, On a Test of Whether One of Two Random Variables is Stochastically Larger than the Other, Annals of Mathematical Statistics 18(1):50-60 (1947)
limit: the runs must be timed the same way: the same start and stop points, the same product, the same conditions. Before and after also differ in time, so a warm machine, a new batch or a practised hand can move the times: this is not a randomised experiment. Five a side is the floor, not a good sample, and a real drop can still be too small to matter.

$ production.py cycle print-before.csv print-ink.csv
a column naming people (operator) was ignored: this machine measures stations and processes, never times or ranks individual workers.
before: 8 runs, median 26.35, range 25.8 to 27.2
after:  3 runs, median 24.9, range 24.7 to 25.1
(times in the file's own unit: seconds)
- median change: -1.45 (-5.5%)
- after runs faster than the before median: 3 of 3 (100%)
VERDICT: NOT CALLED. Fewer than five runs a side (before 8, after 3). Time at least five each way, the same way, before calling any change real; ten a side is better.
formula: medians and ranges of each set; U = pairs (before, after) where the after run is faster, ties half; share = U / (before runs x after runs); p from the exact distribution of U when there are no ties, else the normal approximation with tie correction
source: Mann and Whitney, On a Test of Whether One of Two Random Variables is Stochastically Larger than the Other, Annals of Mathematical Statistics 18(1):50-60 (1947)
limit: the runs must be timed the same way: the same start and stop points, the same product, the same conditions. Before and after also differ in time, so a warm machine, a new batch or a practised hand can move the times: this is not a randomised experiment. Five a side is the floor, not a good sample, and a real drop can still be too small to matter.

$ production.py line stations-jig.csv --takt 27
the line: 5 stations, takt 27.0 s
  station      work s  parallel      cycle s  idle s a unit  against takt
  load           18.0         1         18.0            7.0  9.0 s spare
  print          24.1         1         24.1            0.9  2.9 s spare
  cure           34.0         2         17.0           16.0  10.0 s spare
  fold           25.0         1         25.0            0.0  2.0 s spare   <- BOTTLENECK
  bag            12.0         1         12.0           13.0  15.0 s spare
- bottleneck: fold, 25.0 s a unit. The line can go no faster: it makes 144.0 an hour.
- balance efficiency at the line's own pace: total work 113.1 s / (6 machines x 25.0 s) = 75.4%; balance delay 24.6%; 36.9 s idle across the line for every unit.
- against takt: total work / (machines x takt) = 69.8%
- minimum stations at takt: ceil(113.1 / 27.0) = ceil(4.19) = 5. A lower bound: task order and task sizes may need more.
- every station keeps takt; the bottleneck has 2.00 s of slack.
formula: bottleneck = the largest station cycle (work / parallel machines); output = 1 / bottleneck cycle; balance efficiency = total work / (machines x cycle); idle a unit = parallel x cycle - work; minimum stations = ceil(total work / takt)
source: the standard line-balancing measures; the problem was first set out by Salveson, The Assembly Line Balancing Problem, Journal of Industrial Engineering 6(3):18-25 (1955); takt time as the Toyota Production System describes it
limit: a steady line with the times you give: averages hide spread, and a station whose times swing will starve or block its neighbours. Buffers, changeovers, scrap and breakdowns are left out (see oee); the minimum stations is a lower bound that ignores the order tasks must follow.

$ production.py little --wip 1200 --throughput 1000 --per day
lead time 1.20 days = work in progress 1,200 / throughput 1,000 a day
- a unit that starts now waits behind about 1,200 others; at 1,000 finished a day, it comes out in about 1.20 days on average.
- to halve the lead time to 0.60 days at the same throughput, hold work in progress at 600.
formula: L = lambda W: work in progress = throughput x lead time, so lead time = work in progress / throughput
source: Little, A Proof for the Queuing Formula: L = lambda W, Operations Research 9(3):383-387 (1961), doi 10.1287/opre.9.3.383
limit: long-run averages of a stable system, all three measured over the same period and the same boundary (where a unit enters and leaves), in the same units. Throughput is the exit rate. It gives the average, not one job's lead time, and it says nothing about the spread.

$ production.py little --throughput 1000 --lead-time 0.25 --per day
work in progress 250.0 = throughput 1,000 a day x lead time 0.25 days
- that is the average number of units inside the boundary at any moment.
formula: L = lambda W: work in progress = throughput x lead time, so lead time = work in progress / throughput
source: Little, A Proof for the Queuing Formula: L = lambda W, Operations Research 9(3):383-387 (1961), doi 10.1287/opre.9.3.383
limit: long-run averages of a stable system, all three measured over the same period and the same boundary (where a unit enters and leaves), in the same units. Throughput is the exit rate. It gives the average, not one job's lead time, and it says nothing about the spread.

$ production.py wright --fit design-history.csv
fitted learning rate 87.8% (b = -0.1881): each doubling of cumulative units takes unit cost to 87.8% of what it was
- fitted cost of unit 1: 6.31 (in the units of your data)
- fit: 8 points, R squared 0.996 on the log-log line
formula: ln cost = ln first + b ln unit, least squares on the logs; rate = 2^b
source: Wright, Factors Affecting the Cost of Airplanes, Journal of the Aeronautical Sciences 3(4):122-128 (1936), doi 10.2514/8.155
limit: a straight line on log-log axes is assumed; a few early points move the fit a lot; batch averages fit the average form, not the unit form. Your history, your rate: it is not a promise about the next units.

$ production.py wright --first-cost 6.2 --rate 0.88 --units 5000 --target 2
learning rate 88.0%, b = log2(0.880) = -0.1844; the unit model: unit cost falls to 88.0% with each doubling of cumulative units
- unit 5,000 costs 1.29; the first 5,000 cost 7,897.86 in total, 1.58 each on average (in the units of --first-cost: money in your currency, or hours or minutes)
  unit       unit cost    cumulative average
  1               6.20               6.20
  2               5.46               5.83
  4               4.80               5.38
  8               4.23               4.89
  16              3.72               4.40
  32              3.27               3.93
  64              2.88               3.48
  128             2.53               3.08
  256             2.23               2.72
  512             1.96               2.40
  1,024           1.73               2.11
  2,048           1.52               1.86
  4,096           1.34               1.64
  5,000           1.29               1.58
- unit cost first reaches 2.00 at unit 462 (that unit costs 2.000; the one before, 2.001).
formula: unit model: cost of unit n = first x n^b, b = log2(rate); total = first x sum of k^b; average = total / n
source: Wright, Factors Affecting the Cost of Airplanes, Journal of the Aeronautical Sciences 3(4):122-128 (1936), doi 10.2514/8.155; Wright fitted the cumulative average; the unit form is the later one most planners use
limit: an observed pattern, not a law: cost falls only while people keep making and improving, and the rate is yours (Wright reported about 80% for airframe labour in his day). It applies to the labour and conversion cost that learning moves, not to bought-in materials; a pause in production loses some of it. No currency is assumed.