Kanban Pull System: Cutting-to-Sewing Handoff Guide

Walk into most cutting rooms at 10 a.m. and you will find the same scene. A wall of bundles stacked shoulder-high at the line head, more arriving on trolleys every twenty minutes, and a sewing supervisor who cannot tell you which bundle belongs to which line without unwrapping three of them first.

That pile is not a sign of a productive cutting room. It is a sign that cutting is pushing output at its own pace, disconnected from what sewing can actually consume. The cost shows up in three places: floor space tied up in bundles nobody is stitching yet, an hour a shift lost to operators and helpers searching for the right bundle, and a cutting room efficiency and marker planning report that looks excellent while the sewing floor starves on the wrong style mix. A kanban pull system fixes the handoff by letting sewing's actual consumption rate (not the cutting table's capacity) set how much gets cut and released.

Why Push Scheduling Between Cutting and Sewing Builds a Mountain of Bundles

Cutting is a batch process. A marker gets laid, plies get stacked, and the lay gets cut in one pass: the longer the lay, the better the fabric utilisation and the lower the cost per piece. That economics rewards cutting ahead, in big lays, whenever fabric and capacity allow.

Sewing is a flow process. A line consumes bundles one at a time, at a rate set by its standard minute value calculation, its manning, and how far into style learning it is. Early in a style, that consumption rate can be half of what it will be by week two. Push scheduling connects these two departments with no feedback loop. Cutting keeps producing at its own optimal batch size; sewing keeps consuming at its own variable rate. The gap between the two rates becomes physical inventory sitting at the line head.

The visible symptom (bundles piled to shoulder height) is not the problem. It is the readout of a rate mismatch that nobody is managing. A pull system replaces the readout with a control: sewing signals what it needs, and cutting responds to the signal instead of to its own schedule.

How Many Kanban Cards Do You Actually Need?

The number of cards in circulation is what sets your WIP cap: get this number wrong and you either starve the line or rebuild the mountain with laminated tickets on it.

The formula: Number of cards = (D × L × (1 + S)) / C

• D = average demand per period (bundles/hour), taken from actual sewing consumption, not the cutting plan

• L = replenishment lead time (hours): the time from card release to the replacement bundle arriving at the line

• S = safety factor (0.1–0.3), covering line stoppages, absenteeism and style-change variability

• C = container size (bundles per trolley or per cart)

Worked Example

A line consumes bundles at 14 bundles/hour. The cutting-room-to-line replenishment lead time is 3 hours. A safety factor of 0.2 covers normal disruption. Trolleys carry 12 bundles each.

Number of cards = (14 x 3 x 1.2) / 12 = 50.4 / 12 = 4.2, rounded to 5 cards

Five cards in circulation, each representing a 12-bundle trolley, caps total in-process inventory between the two departments at 60 bundles. That is the entire point: the card count is not a suggestion, it is a hard ceiling on WIP by design. Run this calculation per line, not per floor: a line running a simple basic tee and a line running a multi-panel jacket will have wildly different D and L values, the same kind of inputs that drive queuing theory for buffer sizing everywhere else on the floor.

What Must a Bundle Card Physically Carry?

Laminate the card. Number it. Put it in a colour that is not used anywhere else on the floor. The failure mode is almost never that the format was wrong: it is that cards got used as scratch paper and quietly disappeared from circulation within the first week.

Setting the WIP Cap: What Happens the First Week You Enforce One

The WIP cap is simply: number of cards × container size. In the worked example above, that is 60 bundles, no more, ever, between cutting and that line.

Day 1-2: cutting hits the cap and stops. The cutting team, used to running ahead, fills all five cards within a few hours and then has nowhere to put the next lay's output. This reads as a capacity problem. It is not. It is the system working exactly as designed, exposing capacity that was previously being converted into unusable inventory.

Day 3-4: card discipline breaks down. Someone cuts "just one more lay" without a card because the fabric is already spread. This is the point where the WIP cap either holds or the whole exercise reverts to push scheduling with laminated decoration.

Day 5 onward, if it holds: the real consumption rate becomes visible. Supervisors can see, for the first time, exactly how many bundles per hour the line is actually pulling, not what the plan assumed.

Field note: At a 12-line knits factory running a basic-tee program, the first week of a five-card pilot on one line produced 340 fewer cut pieces than the identical week a month earlier, and zero additional line starvation events. The cutting supervisor initially reported this as a problem in the daily meeting. It turned out cutting had been running roughly two days ahead of consumption for the prior six weeks, and the "shortfall" was simply that phantom lead evaporating.

The Metric Conflict That Kills Most Kanban Pull System Rollouts

A cutting supervisor's daily efficiency number is almost always output against capacity: pieces cut per day against installed cutting capacity. That metric rewards cutting ahead. It rewards big lays, continuous spreading, and never leaving a cutting table idle.

A kanban pull system asks that same supervisor to stop cutting the moment the cards run out, potentially with fabric still spread and a table sitting idle for the rest of the shift. Under the old metric, that is a bad day. Under the pull system's actual goal, it is the system working correctly. If you install kanban cards and leave the old output metric in place, you have built a system that punishes the person you need to comply with it.

The metric has to change before the cards go up on the wall, not after. Replace daily cut-piece output with a composite score: on-time bundle delivery against card pull signals, WIP-cap adherence, and shade/lot accuracy. Cut pieces per day still gets tracked, as a diagnostic, not as the number the supervisor is paid or praised against, which is really just factory KPI dashboard design applied to one stubborn metric.

Results: What an Eight-Week Rollout Actually Looks Like

Read that last row carefully. Cutting output dropped by 150 pieces a day, and that drop is the finding, not the flaw. Those 150 pieces a day were never becoming shipped garments any sooner. They were becoming WIP that sat, took up floor space, and created shading and traceability risk while it waited. The cutting room had been producing inventory, not product.

Implementation Checklist

• Calculate D (actual sewing consumption, not planned) for the pilot line

• Confirm L (true replenishment lead time, measured, not assumed)

• Set S between 0.1 and 0.3 based on line stability history

• Calculate card count and resulting WIP cap; round up, never down

• Design and laminate cards with style, size, shade band, lay number, ply range, quantity, card ID

• Change the cutting supervisor's metric before installing cards, not after

• Pilot on one line for a minimum of four weeks before floor-wide rollout

• Run a daily card count audit for the first three weeks

• Track WIP, search time, starvation events, and cutting output weekly

Final Word

A kanban pull system between cutting and sewing is not a card-printing exercise. The cards are the least important part of it. What actually moves the WIP number is a cutting supervisor who is no longer paid to cut ahead, and a factory willing to let a cutting table sit idle for an hour rather than build inventory nobody asked for. Get that right and the mountain at the line head stops rebuilding itself within a week of you tearing it down.