01 · Purpose and boundaries
Purpose and boundaries
Generic Pull System is not a universally standardized lean label. Here GPS means a general pull and work-in-process authorization design: work enters a defined system only when an explicit demand or capacity signal authorizes it. The label varies across training programs. The operating rules matter more than the acronym.
Pull connects production or work release to downstream need. It differs from simply starting everything on a forecast or dispatch list and hoping queues remain manageable. Define what is pulled, by whom, at what boundary, in what quantity, and with what priority. Pull does not remove the need for forecasting, staffing, purchasing, or planning; it changes the authorization of execution within a selected scope.
02 · How the method works
How the method works
Define the system boundary and completion condition. For a parcel flow, completion might be verified dispatch, rather than merely packing. Select an authorization unit such as order, tote, pallet, or equivalent work content. A count of orders can conceal large differences in effort, so check mix.
Choose the control structure. A supermarket kanban replenishes specific stocked items after withdrawal; cards are associated with item quantities and loops. CONWIP, constant work in process, limits the total work inside a broader boundary: completion returns an authorization token for another job, often selected from a backlog. A CONWIP token is not automatically an item-specific replenishment kanban.
Set an initial limit from observed throughput, lead-time aims, resource behavior, and variability. Define release priority, blocked-work treatment, token movement, quality holds, and exception permissions. Start conservatively enough to protect flow, then learn. A lower limit can expose interruptions but may starve a constraint if variability and replenishment time are ignored.
03 · Worked logistics example
Worked logistics example
Fictional WestChannel handles a single family of similar parcel orders. It completes 40 orders per hour over an eight-hour operating day. Under push release, average work in process is 200 orders. With a stable boundary and consistent averages, Little's Law gives an average flow time of 200/40 = five operating hours.
The team pilots a CONWIP-style GPS with 120 authorization tokens between picking release and verified dispatch. Each completed order returns one token. The next eligible order is released from a priority-controlled backlog. Held orders retain tokens so their presence remains visible; an exception owner resolves them rather than quietly releasing replacement work.
If throughput stays at 40 orders per hour and average WIP is 120, average flow time would be three operating hours. The pilot records 39 orders per hour and average WIP of 117, also giving three hours. Service improves for normal orders, but two export holds consume tokens long enough to require a separate approved readiness gate before entry.
04 · Interpretation and decisions
Interpretation and decisions
The initial estimate does not guarantee the resulting throughput. Too little WIP can leave workers or the constraint without ready work. Too much WIP lengthens queues. Compare throughput, service distribution, starvation, blocked work, and workload mix while tuning the limit.
The 39-order pilot rate is slightly below the baseline and needs investigation before rollout. If incomplete export work caused the loss, a readiness gate may recover output without increasing WIP. Do not claim that Little's Law proves a cause; it relates stable long-run averages under a consistent boundary. Orders waiting outside the controlled system remain part of customer lead time even when internal flow time improves.
05 · Common misapplications
Common misapplications
A board displaying work is not necessarily pull. If new jobs enter without authorization, the board merely visualizes push. Likewise, adding cards while permitting unlimited emergency release abandons the limit. Define emergency priorities within a governed rule.
Do not confuse total WIP control with stock replenishment. A returned CONWIP token may authorize a different item from the one completed; item-specific kanban typically authorizes replenishing the withdrawn item. Avoid removing held work from WIP counts to make metrics look better. Track backlog and customer time separately so delay cannot be hidden just outside the boundary.
06 · Advanced adaptation
Advanced adaptation
For mixed work, use family-specific lanes or weighted tokens when a count-based cap is misleading. Weighting adds complexity and should reflect meaningful work content, not false precision. Reserve capacity for high-priority work only where customer requirements justify it.
A hybrid system can use CONWIP across order processing and supermarket replenishment for packing materials. Define the interface: an order token authorizes processing, while a material withdrawal signal authorizes stock replacement. Digital signals need unique identities, duplicate protection, reliable status transitions, and an outage procedure. Tune the system through observed starvation and queue behavior rather than copying another site's token count.
07 · Implementing and sustaining the change
Implementing and sustaining the change
Introduce generic pull system (gps) within a clearly named operating boundary. Identify the product family, shift, equipment, and handoffs affected; record what happens immediately before and after that boundary. A change that improves one task while exporting its delay to another department has not established an improvement. Agree who can stop the trial, who handles exceptions, and which customer commitment takes priority when the normal rule cannot be followed.
Establish a baseline from actual work rather than a single demonstration. Include normal variation in order mix, replenishment timing, staffing, and workload. Keep the denominator visible: minutes per order, defects per shipment, or completed lines per available hour answer different questions. Record the workload and conditions alongside each observation so that a quiet trial period cannot masquerade as better performance. Observe the process with the people who do it; their explanation of interruptions often changes the proposed design.
Start with a reversible pilot large enough to expose handoff problems. Explain the expected mechanism before launch: which action changes, which delay or failure it removes, and which result should respond. Train all affected shifts and support roles using the same operating definition. During the pilot, capture exceptions as information about the design. Do not conceal them through unofficial stock, unrecorded overtime, or a specialist who quietly repairs every failure.
Review customer service, safety, quality, work content, and inventory together. A faster average with more severe late orders may be unacceptable; a lower inventory level with repeated emergency deliveries may have displaced the cost. Investigate variation before declaring success. If the expected mechanism does not appear, revise the design or return to the baseline rather than defending the idea. A promising observation is a reason to test more conditions, not proof that every operating context will behave identically.
After a successful trial, make the new rule part of daily work. Give an accountable owner responsibility for the operating standard, change control, training, and periodic review. Specify the abnormal condition that requires escalation and the person who responds. Check whether the improvement remains effective when a trained colleague is absent or demand changes. Sustain the mechanism through routine management and learning; documentation is useful only when it describes the process people actually follow.
Connections
Related methods and phase use
Placed under Improve because of the outcome it supports. Use the method in other phases when its purpose and assumptions fit the work; the phase list is a guide to selection, not a compulsory sequence.
Sources
Professional foundations and further reading
The explanation and fictional teaching examples are written for LeanTrainingLab. Linked primary sources provide professional foundations; example values and local conventions are stated in the guide. The accepted toolset draws on Six Sigma+Lean Toolset, second edition (Lunau, editor; Springer, 2013). No book text or examples are reproduced here.