CONWIP vs. Kanban: How Constant Work-in-Process Scheduling Works
A cabinet manufacturer running six work centers had a problem that's common on mixed-model production floors: work-in-process piled up in front of the finishing station no matter how carefully the schedule was built upstream. Switching from a traditional push schedule (release material based on due date) to CONWIP, Constant Work In Process, capped the total number of jobs allowed on the floor at once. WIP in front of finishing dropped by roughly a third within two months, without touching staffing or equipment.
What CONWIP actually controls
CONWIP is a pull-based production control method that caps the total amount of work-in-process allowed across an entire production line, using a fixed number of authorization cards (physical or digital). A new job can only start once a finished job exits the line and frees up a card. That single constraint, total WIP stays constant, is what gives the system its name and its main benefit: flow time through the line becomes far more predictable, because the amount of work competing for capacity at any moment is bounded.
This differs from a traditional push system, where the schedule releases new work based on due dates or forecasted demand regardless of how much work is already sitting on the floor. Push systems are easier to plan on paper but tend to let WIP balloon whenever any single work center falls behind, which is exactly the finishing-station bottleneck the cabinet manufacturer above ran into.
CONWIP originated from research at IBM and the University of Wisconsin in the late 1980s, targeted originally at semiconductor fabrication, an industry where routings are long, variable, and touch dozens of process steps. It later spread into general discrete manufacturing and job shops because the same core problem, unpredictable WIP inflating flow time, shows up anywhere routings vary significantly between products.
CONWIP vs. Kanban: the difference that matters
Kanban and CONWIP are both pull systems, and the terms get used almost interchangeably in casual conversation, but they control WIP differently:
| Kanban | CONWIP | |
|---|---|---|
| WIP control point | Between every pair of workstations | Across the entire line, from release to completion |
| Card count needed | One card loop per stage, can mean dozens across a line | One global card loop for the whole routing |
| Best fit | Repetitive, stable product mix | Mixed-model or job-shop routings where each product visits different stations |
| Setup complexity | Higher. Every station needs its own card count tuned. | Lower. Only one system-wide WIP cap to calibrate. |
The practical takeaway: Kanban tends to work better on a line with a stable, repetitive product mix, where every unit follows roughly the same path through the same stations. CONWIP tends to work better in a job shop or mixed-model environment where products take genuinely different routes through the floor, because it only requires managing one WIP cap for the whole line instead of tuning card counts at every single workstation.
Some plants run a hybrid of the two: CONWIP to cap total WIP entering the line as a whole, with a smaller Kanban loop layered on top of the two or three stations where local sequencing genuinely matters, usually the final assembly and packaging stages closest to the customer-facing due date. This tends to show up in plants that started with Kanban, hit the card-count management burden as their product mix widened, and added a CONWIP cap rather than ripping out the existing Kanban loops entirely.
How CONWIP shows up inside an ERP's production module
Most mid-market ERP systems don't ship with a native CONWIP toggle the way they might for basic MRP. Instead, CONWIP gets implemented as a WIP cap applied against the work order release function. Configuring it typically means:
- Setting a maximum work order count (or maximum total value/hours) that can be simultaneously released to the floor at once.
- Configuring work order completion to automatically trigger the release of the next queued order. This is the electronic equivalent of a card returning to the front of the line.
- Building a dashboard or report that shows current released WIP against the cap, so schedulers can see at a glance whether the line is running at its authorized ceiling.
Some ERP vendors expose this through a "constrained release" or "pull sequencing" setting inside the manufacturing execution or shop floor control module; others require it to be built as a custom business rule on top of standard work order fields. It's worth asking specifically about this during an ERP evaluation if CONWIP is part of the target production model, since "we support pull production" in a sales deck often just means basic Kanban card printing.
Setting the WIP cap correctly
The single most common mistake in a CONWIP rollout is setting the cap too high, which defeats the purpose. If the cap is high enough that it's never actually binding, the line behaves exactly like the push system it replaced. A workable starting formula, adapted from queueing theory: divide the line's target throughput rate by its historical average flow time, then round to a whole number of jobs. If a line needs to complete 40 units a day and average flow time through the whole routing is half a day, that points to a WIP cap in the neighborhood of 20 units, not the 60 to 80 units of work commonly sitting on a comparable push-scheduled floor. From there, most implementations dial the number up or down by 10 to 15% every two to three weeks based on observed flow time and bottleneck utilization, rather than trying to compute the correct number analytically on day one.
Measuring whether CONWIP is actually working
Once a WIP cap goes live, three metrics tell you whether it's calibrated correctly. Flow time variance should drop first and fastest, usually visible within two to four weeks, since that's the direct effect of bounding WIP. Throughput should hold steady or improve; if throughput drops after implementing a cap, the cap is very likely set too low and is starving downstream stations of work. On-time delivery should improve over a longer horizon, typically eight to twelve weeks, as more predictable flow times let planners quote more accurate delivery dates to customers. A production floor that sees flow time variance drop but throughput also drop has overcorrected the cap and needs to raise it, not abandon the approach.
A rollout checklist
- Baseline current average WIP, flow time, and throughput for at least four weeks before implementing a cap, so there's a real number to compare against.
- Set the initial cap using the throughput-over-flow-time formula, then treat it as a starting hypothesis, not a fixed number.
- Review the cap every two to three weeks against the three metrics above for the first quarter.
- Train schedulers explicitly on the rule: no new work order releases until a card frees up, even when a customer is pushing for expedited treatment. The discipline is what makes CONWIP work, and it's also the first rule that gets broken under pressure.
When CONWIP is the wrong tool
CONWIP assumes a relatively stable routing and a production environment where the entire line, not individual stations, is the meaningful unit of control. It tends to underperform in two situations: environments with extremely high product-mix variability, where a single global WIP number doesn't reflect wildly different processing times per product, and environments with a single obvious, permanent bottleneck, where a simpler drum-buffer-rope approach focused just on that bottleneck's schedule is easier to manage and gets most of the same benefit with less system overhead.