Work in process (WIP) is everything that has entered production but not yet left it: material between operations, parts waiting at machines, batches mid-route. WIP is not evil, some is structurally necessary, but every unit of it costs cash, occupies floor, ages toward rework, and, most expensively, slows everything down by standing in line.
The link is Little’s Law: average lead time equals average WIP divided by average throughput. A line finishing 100 units per day with 1,200 units on the floor has a 12-day lead time, by arithmetic, not by attitude. Cut WIP to 400 at the same throughput and lead time is 4 days. Nothing needs to move faster; there is simply less queue to wait behind. This is why lean systems attack WIP with pull systems and kanban: capping WIP is capping lead time.
The classic metaphor holds: WIP is water covering rocks. With three days of buffer before every operation, a machine can break for hours and nobody downstream notices, so the breakdown never becomes urgent enough to fix properly. High WIP masks unreliable equipment, long changeovers, unbalanced capacity, and quality escapes (a defect made on Monday surfaces at assembly on Thursday, three thousand units later). Lowering WIP deliberately, and fixing what it exposes, is how flow improvement actually proceeds.
A machining area holds on average 3,600 parts of WIP at an average accumulated cost of 45 per part: 162,000 of working capital parked between operations. Throughput is 600 parts per day, so by Little’s Law the area’s lead time is 6 days. A kanban cap and two changeover improvements cut average WIP to 1,500: lead time falls to 2.5 days, 94,500 of cash is released once, quality feedback loops shrink from days to hours, and expediting largely disappears because almost nothing is old enough to be late. Same machines, same people.
Zero is not the answer: variability demands buffers at constraints (protecting the bottleneck per the theory of constraints), and unstable processes need decoupling while they are stabilized. The honest sequence is: cap WIP where it is obviously excessive, watch what surfaces, fix that, lower the cap again. Tools like heijunka reduce the variability that made the buffers feel necessary.
Count it in units, hours of coverage, and cash, per area, trended weekly. Beware averages that hide a bimodal floor: one day of WIP at most stations and three weeks rotting before one problem machine is not two days of average WIP, it is a bottleneck with a museum in front of it. WIP aging, how long the oldest item has waited, exposes what the average conceals.
WIP piles up in front of unreliable and slow equipment, and that is the part Fabrico makes visible and fixable: real-time OEE shows which stations starve or block their neighbors, downtime coding shows why, and the CMMS turns the chronic offenders into scheduled reliability work. Fabrico does not track inventory positions or run your kanban loops; it removes the equipment reasons the extra WIP existed. EU-built, with EU data residency.
Accounting books it as an asset; operations should treat it as a cost with a purpose. The useful question is not whether WIP is good but whether each buffer is doing a job you can name, protecting a constraint, decoupling a batch process, or just hiding a problem nobody has fixed.
Start from current reality, not theory: measure current WIP and lead time, cap slightly below current average, and hold throughput. When flow stabilizes, lower the cap stepwise. The cap’s job is to surface the next problem at a rate you can absorb.
WIP is actively in the routing between start and finish. Semi-finished goods deliberately stored at a decoupling point, made-to-stock components awaiting final configuration, are strategic inventory with their own planning logic, not queue.
Want to see which machines your WIP is protecting? Book a Fabrico demo to watch real-time OEE expose the stations that make the buffers feel necessary.
Login
Blog