CONWIP: One Card Cap to Control Your CPG Line's WIP and Lead Time
CONWIP: One Card Cap to Control Your CPG Line's WIP and Lead Time
It's Monday at 6 a.m. MRP has just dumped a week's worth of orders onto the floor. The blending crew starts everything it can, filling backs up behind them, pack is drowning in half-finished pallets by noon, and by Wednesday nobody can tell you when a given order will actually ship. Work-in-process (WIP) has piled up across every station, lead times have ballooned, and your day is now firefighting.
That's the failure mode of a push system: production orders are scheduled and material is pushed into the line whether or not the line is ready for it. A pull system flips the trigger — the start of each new job is triggered by the completion of another at the end of the line (Wikipedia: CONWIP). The question every scheduler eventually asks is: how do I actually cap WIP instead of just wishing it were lower? CONWIP is the simplest answer.
What CONWIP actually is
CONWIP stands for Constant Work In Process. It's a pull-oriented production control system that puts a fixed number of "cards" — release authorities — into circulation across the entire line. The rule is brutally simple:
- No part is allowed to enter the front of the line without a card.
- When a finished part is completed at the last workstation, its card is transferred back to the first workstation.
- That returned card authorizes a new part to be released into the sequential route.
Because the number of cards is fixed, the total WIP on the line is constant by construction (Wikipedia: CONWIP). A unit can't go in until a unit comes out. That's the whole mechanism.
CONWIP is often described as a kind of single-stage Kanban system — a hybrid push–pull system. The critical difference from classic Kanban: Kanban maintains tight control by putting individual cards at each workstation, while CONWIP uses only one set of system cards to manage total line WIP. That makes CONWIP easier to implement and adjust, because you're tuning one number instead of balancing card counts at every station (Wikipedia: CONWIP).
Why a WIP cap controls lead time
If you've read the Little's Law piece, this is the payoff. Little's Law says:
Lead time = WIP ÷ Throughput
Rearrange that and the implication is direct: for a given throughput, if you cap WIP, you cap lead time. A line running at a steady output rate with 40 units of WIP has exactly twice the flow time of the same line running at 20 units. Uncontrolled WIP is uncontrolled lead time.
CONWIP is the operational lever that makes Little's Law work for you instead of against you. Cap the cards, and you cap the numerator. That turns lead time from a number you measure after the fact into a number you set in advance — which is exactly what you need to make schedulable, believable promises to the front of the plant and to customers.
This is also the counterweight to the utilization trap: chasing 100% utilization by shoving more work in only inflates queues. CONWIP refuses the extra work at the gate.
CONWIP vs. Kanban vs. DBR vs. push
All of these except push are WIP-controlled line production systems, and such systems are mathematically equivalent to tandem queues with finite buffers under a blocking policy (Onyeocha et al., ScienceDirect). They differ in where the control lives.
| System | Control lever | Best when | WIP ceiling? |
|---|---|---|---|
| Push (MRP) | Schedule dates | Never really controls WIP | No |
| Kanban | Card per station | Stable, repetitive demand; many cards to tune | Yes, per station |
| DBR | Release paced to the bottleneck drum | One dominant, stable bottleneck | Yes, rope-length |
| CONWIP | One line-wide card pool | Single routing, easiest to run/adjust | Yes, line-wide |
The evidence matters here. Spearman and colleagues (1990) used simulation to compare CONWIP, Kanban, and push, and found that CONWIP can achieve a lower WIP level than Kanban (Wikipedia: CONWIP). You get tighter WIP control with less administrative overhead than card-per-station Kanban.
CONWIP and Drum-Buffer-Rope are cousins. DBR ties release to the beat of a specific bottleneck; CONWIP caps total WIP regardless of where the constraint sits. If your bottleneck wanders — a common reality when SKU mix shifts — a line-wide WIP cap is often more robust than a rope anchored to one machine.
Setting the card count — the practical math
The card count is your WIP cap, so sizing it is the whole game. A workable starting point:
- Find the bottleneck rate — the throughput of the slowest station in units per hour.
- Measure the raw process time — how long one unit takes to traverse the whole routing with no waiting (the critical-path processing time).
- Multiply bottleneck rate × process time to get the minimum WIP needed to keep the bottleneck fed. That's your theoretical floor.
- Add a buffer for variability — the more variable your process and arrivals (see Kingman's equation), the more cards you need to avoid starving the bottleneck.
- Iterate on the floor. Run it, watch the line, and adjust weekly.
The trade-off is symmetric and unforgiving:
- Too few cards → the bottleneck starves, and you lose throughput you can never get back.
- Too many cards → you've rebuilt the WIP mountain and lengthened lead time, defeating the point.
What does a well-tuned system look like? A simulation study of a multi-CONWIP system for bicycle-chain production found that a Kaizen multi-CONWIP configuration improved average lead time by up to 42.8%, and a bottleneck-based multi-CONWIP reduced WIP volume by over 50% versus the plant's existing production system (Jaegler et al., ScienceDirect). Those are the magnitudes a disciplined WIP cap can unlock — not guaranteed on your line, but they show the size of the prize.
CONWIP on a real CPG line — a worked cycle
Picture a single-routing beverage line: blend → fill → pack → palletize. Say you've sized the cap at 8 cards.
- Eight batches' worth of authority is loose in the line. Blending can start a new batch only when it holds a free card.
- A pallet completes at palletize. Its card is pulled and walked (physically or in the scheduling system) back to blending.
- That returned card authorizes blending to release the next batch — and only then.
Here's what this prevents: without the cap, blending and fill run flat-out while pack lags, and half-finished product stacks up between fill and pack — a WIP mountain that clogs floor space, hides quality problems, and lengthens every order's lead time. With CONWIP, fill physically cannot get eight batches ahead of palletize. The queue between stations is bounded. Flow stays smooth.
The multi-SKU wrinkle: shared vs. dedicated cards
A standard CONWIP system shares a single card pool across all product types (Wikipedia: CONWIP). Simple, but it doesn't distinguish a fast-moving flagship SKU from a slow tail item — any card can pull any product.
Duenyas (1994) proposed a dedicated card-control policy that segments cards by product, making the line behave like a multiple-chain closed queuing network (Wikipedia: CONWIP). Dedicated cards give you more control over the mix at the cost of more cards to manage.
Crucially, CONWIP controls how much enters, not what order. It coexists cleanly with a fixed run sequence. Pair it with an EPEI production wheel or sequence-dependent changeover ordering to decide the sequence, and let the card loop govern release timing. Add heijunka leveling on top and you smooth the mix and cap the WIP.
Where CONWIP struggles
CONWIP is not universal. Be cautious when:
- Routings diverge wildly. CONWIP assumes a single, roughly common route from front to back. If SKUs take radically different paths through the plant, a single card loop loses meaning.
- You're deep make-to-order with huge variety. High routing variety undermines the shared-card model; you may need dedicated cards or a different mechanism entirely.
- The bottleneck is unstable and undersized. Because WIP-controlled systems behave like finite-buffer tandem queues with blocking (Onyeocha et al.), a poorly placed cap can create upstream blocking or downstream starvation faster than you expect.
If your line has one dominant routing — as most CPG fill/pack lines do — none of these usually disqualify you. They're guardrails, not stop signs.
Implementation checklist for schedulers
- Pick the routing. Identify the single dominant flow (blend → fill → pack → palletize).
- Measure throughput and process time. Get the bottleneck rate and the raw traverse time. Your OEE-based schedulable run rate is the honest throughput number to use.
- Set an initial card count using bottleneck rate × process time, plus a variability buffer.
- Run and observe. Is the bottleneck ever starved (too few cards)? Is WIP creeping back up (too many)?
- Adjust weekly. Move the count by one or two cards at a time and watch the effect on lead time and starvation.
- Combine with leveling and time fences. Use heijunka to smooth the mix and time fences to keep the release sequence stable inside the frozen zone.
Key takeaways
- CONWIP is input control. It governs the release authority at the front of the line — a different lever than DBR (paces to the bottleneck), heijunka/EPEI (level the mix), or Little's Law (predicts lead time).
- A fixed card count = a constant WIP = a predictable lead time. That's the direct Little's Law payoff.
- It's simpler than Kanban — one system-wide card pool instead of station-by-station cards — and simulation shows it can hold WIP lower than Kanban.
- Size the cap carefully: too few cards starves the bottleneck, too many rebuilds the queue. Start from bottleneck rate × process time and iterate on the floor.
If you've already got Little's Law, the utilization trap, and DBR in your toolkit, CONWIP is the piece that actually enforces the WIP number on the floor — one card at a time.
Sources
More from the journal
Johnson's Rule: Sequence Your Mix-and-Pack Runs to Shrink Total Makespan
On a two-stage CPG line, finish time isn't the sum of run times — it's the makespan. Johnson's rule re-orders the same jobs to finish the whole set sooner, with zero new equipment. Here's the algorithm, a worked mix-to-pack example, and the CPG fine print.
OTIF Starts on the Line: Scheduling to the Must-Arrive-By Date
OTIF is a retailer-compliance scorecard that grades whether you delivered the right product, in full, on the must-arrive-by date. It's a scheduling problem before it's a logistics one — here's how to build a schedule that survives it.
SMED Changeover Reduction: Convert Internal Setup to External and Break the 10-Minute Barrier
Most schedulers optimize the order of changeovers. SMED shrinks the duration of each one. Here's how to measure a changeover correctly, separate internal from external setup, and convert the two into smaller, fresher production runs.