Key takeaways
Short answer: Kanban and CONWIP are both pull systems that cap work in process, but they cap it at different scopes. Kanban limits inventory between each pair of consecutive steps, with a replenishment signal at every stage. CONWIP — Constant Work In Process — limits the total work in process across the entire line with a single global cap: a new unit is released into the line only when a finished unit comes out. Kanban controls locally and finely; CONWIP controls globally and simply. For the basic pull signal, see andon vs kanban.
Kanban is a pull system that limits work in process between each pair of steps using signals — a card, bin, or electronic trigger — at every stage. Each step is authorised to produce only when the downstream step has consumed something and signalled for replenishment, so inventory is capped at each link in the chain. The result is fine-grained, local control: every buffer between two steps has its own limit, and the whole line is regulated link by link. Kanban's strength is that precision — you control the inventory at every point — and its tight coupling to real downstream demand. Its cost is complexity and rigidity: every product and every link needs its kanban setup, which can become cumbersome with high product variety, since each part number effectively needs its own loops and cards.
CONWIP — Constant Work In Process — is a pull system that caps the total work in process across the whole line with a single global limit, rather than controlling each link separately. The rule is simple: the total number of units in the line is held constant, so a new unit is released into the start only when a finished unit exits the end. One global signal governs the whole line. Within that cap, work flows through the steps without a per-link limit. CONWIP's strengths are simplicity and flexibility: there is one number to manage rather than many, and because the cap is on total WIP rather than on each product's links, it handles product variety and changing mix far more gracefully than kanban. Its trade-off is less granular control — it does not pin the inventory at each specific point the way kanban does.
The core distinction is the scope of the cap. Kanban controls WIP locally — a separate limit between every pair of steps, signalled stage by stage. CONWIP controls WIP globally — one cap on the total in the line, releasing new work only as finished work leaves. Both are genuine pull systems (work is pulled by consumption, not pushed by schedule), and both cap WIP, which is what delivers short lead times and exposed problems. But kanban achieves it with many local limits, CONWIP with one global limit. That difference drives their trade-offs: kanban gives finer control at the cost of more complexity, CONWIP gives simpler management and better variety-handling at the cost of less granular control. They are two designs for the same goal — bounded, pulled flow — at different levels of granularity.
A line has five steps. Under kanban, each of the four gaps between steps has its own WIP limit and signal: step two may build only when step three pulls, and so on, with cards at every link — four separate controls, finely regulating inventory at each point, but needing a kanban setup for each product across each link. Under CONWIP, there is one rule: keep at most, say, ten units in the whole line, so a new unit enters only when a finished unit exits. One number governs everything; within the line, units flow without per-gap caps. If this plant runs many different products, CONWIP is far easier — one global cap accommodates the changing mix, whereas kanban would need loops and cards for every part at every link. If it runs a few stable products and wants tight inventory control at a specific bottleneck, kanban's local precision may be worth the complexity.
Favour kanban when you run relatively few, stable products and want fine, local control of inventory — especially to protect a specific bottleneck or where the buffer at a particular link really matters. Its per-link precision is valuable when the product mix is steady enough that maintaining all those loops is manageable. Favour CONWIP when you have high product variety, a changing mix, or simply want a simpler system to manage — its single global cap handles variety gracefully and is far less work to maintain, because there is one number rather than a web of cards. Many real implementations blend ideas — a global CONWIP cap with some local controls at critical points. The choice turns on product variety and the value of local precision versus the cost of managing it.
Both kanban and CONWIP cap work in process, and capping WIP is what makes losses visible — the same dynamic that links pull systems to OEE. With bounded WIP, a downtime event on one machine quickly propagates rather than being hidden in a pile of inventory, making the loss impossible to ignore and driving improvement, exactly as in push vs pull production. Both systems also depend on reliable equipment: a tight WIP cap is unforgiving of an unreliable machine, because there is little buffer to absorb a stoppage. So good OEE — high availability — is part of what lets either pull system run with low WIP without constant starvation. The pull design and the equipment reliability work together.
Fabrico measures the equipment reliability that determines how tightly you can cap work in process under either system. Low-WIP pull — whether kanban or CONWIP — is unforgiving of downtime, so Fabrico's live OEE and downtime data shows whether your equipment is dependable enough to run lean, and where the losses are that force larger buffers as insurance. By improving availability behind the scenes, it lets you tighten the WIP cap safely. Book a demo to see the reliability your pull system depends on.
Kanban limits work in process between each pair of steps, with a signal at every stage. CONWIP (Constant Work In Process) limits the total WIP across the whole line with a single global cap, releasing new work only when finished work leaves. Kanban controls locally; CONWIP controls globally.
Yes. CONWIP is a pull system — work is released into the line only when a finished unit exits, so production is pulled by completion rather than pushed by a schedule. It caps total work in process globally rather than link by link as kanban does.
CONWIP tends to be better with high product variety or a changing mix, and when you want a simpler system to manage. Its single global cap handles variety gracefully and needs only one number, whereas kanban requires loops and cards for each product across each link.
Kanban suits relatively few, stable products where you want fine, local control of inventory — especially to protect a specific bottleneck or where the buffer at a particular link matters. Its per-link precision is worth the added complexity when the product mix is steady.
Both cap work in process, which makes losses visible by letting downtime propagate rather than hide in inventory — driving OEE improvement. Both also depend on reliable equipment, since a tight WIP cap is unforgiving of stoppages, so good availability supports either pull system.
Login
Blog
