Supply chain science

1. 1Measure the true limiting rate first. Take the base rate and subtract the detractors (downtime, setups, breaks/lunches). The punch press falls from 2 parts/hour to an effective 1.43. The rate you plan around is the effective one, never the nameplate or overtime rate.
2. 2Name the boundary the cap covers: one station and its inbound stock point, or a line of linked processes. A cap counts all work between the release point and the exit, so the boundary decides what is counted.
3. 3Write the cap as an explicit number of units (or cards, or slots). Passage logic: the benefit comes from the cap on WIP, not from how it is enforced. Space limits and overload stops in an MRP shop already act as caps, but they are implicit and unset on purpose. Replace them with a deliberate number.
4. 4Choose the enforcement mechanism that fits your floor: kanban cards, marked floor or rack space, or a gate on actual releases. Any of these works if it ties a new release to a completion, so that work enters only when status says there is room.
5. 5Keep the release trigger separate from the order type. A pull system can authorize releases to fill stock voids, but it can just as well release work already tied to a customer order. Decide make-to-order or make-to-stock separately; the cap does not decide it.
6. 6If you run MRP, do not let planned order releases convert one-for-one into actual releases. Add a rule that holds a release when the system is at its cap. This is how MRP users add a pull element to a push system.
7. 7Set the cap below the level that keeps the bottleneck from starving and above the level that lets cycle time balloon. Start conservatively, because the system is less sensitive to an error in a WIP level than to an error in a release rate. Then tighten step by step.
8. 8As WIP falls, expect problems that inventory used to hide to surface (quality, workpace, outages). Absorb them with a deliberate capacity buffer rather than by raising the cap. Toyota's 4-hour PM periods between shifts doubled as overtime capacity when a shift fell short.

Take the punch press from the passages. Detractors cut its base rate of 2 parts/hour to an effective 1.43. Under push, if you release at 2/hour regardless of state, the press cannot keep up and WIP climbs steadily. If you release at exactly 1.43/hour, the outcome becomes unpredictable. A long outage (the plots show one near day 20 and another near day 40) sends WIP up, and with no slack capacity it stays high. In theory WIP would grow without bound over an infinite run. The push fix in the passage is to release at 1.167 parts/hour (28/day), which is 82% utilization, and WIP stays consistently low. A pull version removes the need to guess that rate perfectly. You set a WIP cap and release a part only when one leaves, so during an outage releases stop on their own and the backlog cannot grow past the cap. The passage does not give a cap value for this press. You would pick one, observe, and tighten it, which is safe because pull is less sensitive to a WIP-level error than push is to a release-rate error. The 82% figure also shows the trade-off, since you deliberately leave about 18% of capacity as slack.

• If releases are timed by a schedule or forecast and ignore what is already in the system, then you run push. Add a status-based stop with an explicit cap.
• If the current WIP limit is a side effect of floor space or system overload, then treat it as an unmanaged cap. Replace it with a set number you can adjust.
• If the release rate you planned equals or exceeds the effective capacity, then WIP will build or become unstable. Lower the rate or cap, and expect cycle time to rise sharply as utilization nears 100%.
• If someone says pull means make-to-stock, then separate the two decisions. The cap governs release; the order type is chosen independently.
• If WIP is low but equipment utilization is very low, then the system is not lean. Capacity is the over-sized buffer, so do not cut the cap further.

• Setting the cap against nameplate capacity. The tell is that the cap is never hit during good weeks, and WIP still balloons after every outage.
• Calling an MRP shop pull because the floor overloads. The tell is that releases stop only when the floor is already jammed, and nobody can state the WIP limit.
• Treating pull as make-to-stock and stocking everything. The tell is that customer-specific work is refused entry to the pull loop, or builds inventory nobody ordered.
• Cutting the cap to expose problems without adding a capacity buffer. The tell is chronic shortfalls against the quota and constant firefighting, with no recovery time like Toyota's PM periods.
• Treating low WIP as the only goal of the cap. The tell is that inventory looks good while capacity or time buffers have grown huge.

• ▸Process or line covered: name the start and end of the boundary the cap counts.
• ▸Base rate (units/hour): the nameplate rate before detractors.
• ▸Detractors: list downtime, setups, breaks/lunches that reduce the rate.
• ▸Effective rate (units/hour): the base rate net of detractors. This is the real capacity.
• ▸Current release rule: schedule-driven, MRP, or status-based? State what stops a release today.
• ▸Explicit WIP cap (units/cards/slots): one number, with the date it was set.
• ▸Enforcement mechanism: kanban cards, floor space, or a release gate; who triggers the release.
• ▸Order type in the loop: make-to-order, make-to-stock, or both. Note this is independent of the cap.
• ▸Review log: date, WIP seen vs. cap, problems exposed, capacity buffer used, and the cap change decided.

1. 1Name the trade-off before choosing a position. Inventory close to the customer delivers fast but is inflexible, because stock at one site cannot fill demand at another. Centralized or generic stock is flexible but may be far from demand. Write down which of speed or variety your value proposition rewards.
2. 2Classify every part or product by volume, demand variability and cost. Per the Multi-Echelon Inventory Location principle, low-volume, high-variability and/or high-cost items belong at a central (high) level. Low-volume-variability-free, low-variability and/or low-cost items belong at a local (low) level. Run the classification item by item, not for the whole line.
3. 3Where stocking at more than one level makes sense, assign a role to each level. In the spare-parts example, a small stock at the customer site covers quick emergency repairs, and the distribution center holds stock to replenish the sites. Size both using supplier lead times, shipping times between levels and customer expectations, not only demand statistics.
4. 4Locate the I/O interface by testing the two opposing forces. Long production lead times push the interface toward the customer for responsiveness. High product proliferation pushes it toward raw materials for pooling efficiency. Mark where each force sits for the product family.
5. 5Draw the flow as stages (for example refrigerator, cooking, assembly, packaging, sales). Mark which stages are make-to-stock (maintaining specified stock levels) and which are make-to-order (triggered by customer orders). The boundary is your I/O interface.
6. 6Identify what buffers the variability you removed from inventory. Variability is buffered by inventory, capacity and time. If you move the interface toward raw materials, budget extra capacity (faster cooking/assembly equivalent) and accept longer delivery time. Verify the physical design (layout, material handling, process speed) makes the make-to-order stage fast enough.
7. 7Set safety stock for each stocked point with the base-stock logic. Safety stock rises with target fill rate and, at high fill rates, with the standard deviation of demand during replenishment lead time. Pooling demand at a common stock point reduces the total buffer needed for the same performance.
8. 8Apply different positions to different products. Stock only the high-volume items at the downstream interface and make the rest to order from generic stock. Revisit when the product line grows or mix shifts.

McDonald's and Burger King show the interface moving. McDonald's holds finished hamburgers on a warming table. Everything upstream of the table is make-to-stock, and everything downstream is make-to-order. Standard burgers leave fast (speed via proximity), but a special request such as extra pickles must be made from scratch and is delayed, so the system has to steer customers toward standard products. Burger King has no warming table. Only raw materials in the refrigerator are stocked, so everything beyond them is make-to-order. Inventory is generic and pooled, so any variant can be built, giving variety but slower delivery. To keep waits tolerable, Burger King likely needed more production capacity than McDonald's and substituted time and capacity buffers for inventory buffers. By the 1990s the McDonald's line was too large to stock on the warming table. It stocked only popular items such as Big Macs and Quarter Pounders, which also turn over fast and spoil less, and made low-volume items such as Filet-o-Fish to order. General Motors used the same split for Cadillacs: the few configurations making up 70 percent of demand were stocked in regional distribution.

• If a part is low volume, highly variable in demand and/or costly, then stock it centrally. If it is low-variability, low-cost and/or high-volume, then stock it locally.
• If production lead time is long relative to what customers tolerate, then move the I/O interface toward the customer. If product proliferation is high, then move it toward raw materials and hold generic stock.
• If the line has both a few high-volume items and a long tail, then stock the high-volume ones at the downstream interface and make the tail to order, as McDonald's and GM did.
• If you move the interface upstream to gain variety, then budget capacity and accept time as buffers, and confirm the process is physically fast enough to make make-to-order tolerable.
• If emergency response matters and the item is also pooled centrally, then hold a small local stock and a central replenishment stock rather than choosing one level.

• Applying one interface position to the whole product line. The tell: popular items are slow and stocks of the long-tail items spoil or sit idle, as in the McDonald's line growing too large for the warming table.
• Pooling everything centrally for efficiency while ignoring lead time and customer expectations. The tell: low inventory but missed delivery-time expectations.
• Stocking finished goods close to the customer for speed while variety expands. The tell: special requests are delayed and the system pushes customers toward standard products.
• Removing inventory buffers without adding capacity or time buffers. The tell: long waits at the make-to-order stage, because variability always gets buffered by something.
• Setting stock at multiple levels from demand variability alone, ignoring supplier lead times, inter-level shipping times and customer expectations. The tell: levels that look optimal on paper but stock out at emergencies or oversupply one site.

• ▸Product/part family: name the item or group being positioned.
• ▸Volume, demand variability, unit cost: record each as low/high to classify the item.
• ▸Indicated stocking echelon: central or local, per the Multi-Echelon Inventory Location rule.
• ▸Production lead time vs customer tolerance: state both, to judge the pull toward the customer.
• ▸Proliferation level (number of variants): state it, to judge the pull toward raw materials and pooling.
• ▸Proposed I/O interface: name the last make-to-stock stage and first make-to-order stage.
• ▸Buffer substitution plan: list the capacity and time buffers replacing inventory removed.
• ▸Safety stock target: state target fill rate and standard deviation of demand during replenishment lead time.
• ▸Multi-level roles: describe the small local stock and the central replenishment stock, with lead and shipping times.

1. 1Map who holds the overstock risk and who holds the understock risk today. For each product, write down which firm eats unsold units and which firm eats lost sales. The principle says local optimizers suboptimize the system when risk falls disproportionately on one party, so the lopsided spot is where the contract work starts.
2. 2Predict the local behavior the imbalance produces. A party that bears all overstock risk orders conservatively and runs short. A party that bears all understock risk builds buffers. Write the predicted order or stocking behavior in one sentence per party before you design any term.
3. 3Define the global target. Name the system outcome you want (e.g., more units on the shelf when customers arrive, so fewer lost sales) and the party whose decision has to change to reach it. Judge every contract term against whether it moves that party's local optimum toward the target.
4. 4Pick the contract form that moves the risk to where it is cheapest to hold. The four forms are buyback, revenue-sharing, quantity flexibility and sales rebate. Choose the one that lowers the cost of the decision-maker's risky choice (ordering deeper, stocking more) without exposing the other side to a new lopsided risk.
5. 5Check that both sides come out better off, not just the system. In the Blockbuster case the contract worked because the studios and the rental stores each gained. Model each firm's profit under the old and new terms. If one party loses, the contract won't be signed or won't hold.
6. 6Test whether the changed decision happens. Compare what the decision-maker would order or stock under the new terms with what the global target requires. A contract that shifts risk but leaves the order quantity unchanged has redistributed money, not aligned decisions.
7. 7Pilot in a limited market and measure on system metrics. Blockbuster used test markets before rollout. Track availability to customers, volume sold or rented, and each party's income, not only the buyer's purchase cost.
8. 8Back the contract with visible service commitments. Blockbuster paired its revenue-sharing contract with the 'Guaranteed to be There' campaign, so the new risk allocation reached customers as better availability.

Blockbuster and the movie studios (the one contract case in the passages). Rental stores found tapes costly to buy, so they bought fewer copies. Customers often could not find a title in stock, and rentals and income were lost. A revenue-sharing contract fixed this. The tape cost to the store fell, and the studios took a share of rental income. Stores bought more tapes, customers were more likely to find them in stock, and more rental income was generated. The studios gained from the greater number of tapes purchased plus their share of rental income. The stores gained from the lower tape cost and the larger number of rentals. Blockbuster launched campaigns such as 'Go Away Happy' and 'Guaranteed to be There'. Test markets showed as much as a 75 percent increase in rental revenue. A year later its market share had risen from 25 to 31 percent and its cash flow by 61 percent. The share gain equaled the entire share of its number-two rival, Hollywood Entertainment. Both firms were better off, and the store's ordering decision moved toward what the system needed.

• If one party bears nearly all of the overstock or understock risk, expect it to under- or over-order. Design a contract that moves part of that risk to the other party.
• If a contract helps one party's profit but makes the counterparty worse off, don't expect it to hold. Rework the terms until both gain, as in the Blockbuster case.
• If a proposed term does not change the decision-maker's order or stocking choice, it only moves money. Drop it or redesign it.
• If a contract has not been tested, run a limited-market pilot first and judge it on system results (availability, volume, both parties' income).
• If a supplier has no incentive to challenge your forecast, as Cisco's contract manufacturers did not, treat the contract as missing a risk-sharing and information mechanism, and add one.

• Optimizing one firm's cost. The tell: the buyer's unit price drops but order quantities and in-stock rates don't move.
• Leaving risk lopsided after renegotiation. The tell: the same party still absorbs the write-offs or the lost sales, and its ordering behavior is unchanged.
• Skipping the counterparty's economics. The tell: the supplier declines, or accepts and then under-delivers, because the new terms leave it worse off.
• Mistaking a push-driven build-up for a pricing problem. In Cisco's case, component orders followed forecasts with no cap on inventory, and a $2.25 billion write-off followed the bust. The tell: inventory grows at every tier because no one has an incentive to limit orders or challenge the forecast.
• Rolling out without measuring system outcomes. The tell: success is reported as purchase savings and no one tracks availability, volume or the other party's income.

• ▸Product / relationship: name the item and the two parties.
• ▸Overstock risk holder today: who absorbs unsold units, and how.
• ▸Understock risk holder today: who absorbs lost sales, and how.
• ▸Predicted local behavior: what each party will order or stock given this risk split.
• ▸Global target: the system outcome wanted and the decision that must change to reach it.
• ▸Candidate contract form: buyback, revenue-sharing, quantity flexibility or sales rebate, with a one-line reason.
• ▸Risk moved, from whom to whom: what changes under the proposed terms.
• ▸Profit check for each party (old vs. new): confirm both gain; if not, note the rework.
• ▸Decision-change test: the order or stocking quantity expected under the new terms versus the target.
• ▸Pilot and measures: test market chosen, plus availability, volume and each party's income to track.

1. 1Compute utilization at every station before touching anything: utilization = rate in / capacity, where capacity = (1/process time) x availability. Availability = MTTF / (MTTF + MTTR). Use effective capacity, not nameplate. The station with the highest utilization is the bottleneck and the first place queues form.
2. 2Write cycle time as waiting time + process time, and use CT = VUT + T to split queueing delay from processing delay. If waiting dominates, the problem is coordination between arrivals and processing, not process speed.
3. 3Rate the two drivers separately. For V, check the CV of interarrival times and the CV of effective process times. Effective process times include setups, failures, operator speed, entity variety and quality problems. Observed CVs run from 0 to 10 or more. For U, note that the factor scales with 1/(1 - u) and goes to infinity as u approaches 100%.
4. 4Check the Little's Law consistency: WIP = TH x CT. Use it to convert a measured queue length into a delay, or the reverse. If the numbers disagree, the process is not stable or the data is wrong.
5. 5Trace variability upstream. At moderate utilization, departure variability is a weighted sum of arrival variability and process variability. List failures, setups, batching and idling policies at upstream stations, because they reach downstream stations as uneven arrivals.
6. 6Rank the levers: (a) lower utilization at the bottleneck, (b) cut variability, starting with sources at the bottleneck and then upstream sources that feed it, (c) smooth the bursts by reducing setups, speeding repairs, and changing batching and scheduling. Variability reduction pays most at high-utilization stations.
7. 7Check batching. The smallest stable batch size may be greater than one. Beyond that, batching delay rises roughly in proportion to batch size, so do not enlarge batches to save setups without pricing the delay.
8. 8Choose the buffer explicitly. Variability is buffered by inventory, capacity, or time. If you do not choose, queue-driven WIP and long cycle times become the buffer. Where the bottleneck floats with product mix, cap WIP rather than leave loops uncoupled, since an uncapped queue grows without limit.

The source describes a two-station electronics line fed at 10 jobs/h. Station 1 (Inspect) is an automated machine with a 5.1 min process time, MTTF of 200 h and MTTR of 8 h. Availability = 200/208 = 0.962, so capacity = (1/5.1) x 0.962 = 0.188 jobs/min = 11.3 jobs/h, and utilization = 10/11.3 = 88.4%. Station 2 is a manual operation at 5.7 min per job, so capacity = 10.5 jobs/h and utilization = 95%. Station 2 is the bottleneck. Jobs spend about 6 h there with about 60 jobs queued, against about 3 h and 30 jobs at station 1. The surprising result comes from cutting station 1's repair time from 8 h to 4 h. Station 1 falls to 1.3 h and 13 jobs, as expected. Station 2 also falls from 6 h to 3 h and from 60 jobs to 30, although nothing at station 2 changed. The reason is that station 1's long repairs created departure variability that arrived as uneven flow at the already-hot bottleneck. The lesson is that variability reduction at a nonbottleneck can relieve the bottleneck's queue.

• If utilization is above roughly 90% and the queue is growing, then lower utilization first (add capacity, cut effective process time). Waiting grows nonlinearly as utilization approaches 100%, so small changes there matter most.
• If a station is the bottleneck and its CVs are high, then attack variability at that station first. High V is most damaging where U is high.
• If a downstream station queues heavily and an upstream station has failures, long setups or batch releases, then fix the upstream source. Variability propagates as uneven arrivals.
• If a proposed batch size is larger than the minimum stable size, then count the extra delay, which rises roughly in proportion to batch size, against the setup savings.
• If the bottleneck moves with product mix and WIP is uncapped, then impose a physical or logical WIP limit. Otherwise queueing becomes extremely sensitive to utilization.

• Judging a station only by its own process time or speed. The tell: a station with modest utilization shows long queues because its arrivals come in bursts from upstream.
• Treating nameplate capacity as real capacity. The tell: computed utilization looks comfortable, but downtime from failures and repairs pushes true utilization near the bottleneck level.
• Spending improvement effort only on the bottleneck's own process. The tell: the bottleneck queue stays high while upstream failure and setup variability goes untouched, as when halving station 1's repair time halved station 2's wait.
• Assuming queueing grows linearly with load. The tell: a planned small volume increase at about 90% utilization produces a disproportionate jump in waiting time and WIP.
• Creating waves voluntarily through batch-and-run scheduling or staffing policies that periodically idle operations. The tell: queues appear in surges, like a stadium parking lot after the game, rather than steadily.

• ▸Station name: the process being diagnosed.
• ▸Arrival rate (jobs/h): average rate in, measured over a stable period.
• ▸Effective capacity (jobs/h): (1/process time) x availability, with MTTF and MTTR stated.
• ▸Utilization (%): arrival rate / capacity; flag the highest as the bottleneck.
• ▸CV of interarrival times: low, moderate or high, with its main source (upstream failures, batching, scheduling).
• ▸CV of effective process times: low, moderate or high, with its main source (setups, failures, operator speed, entity variety, quality).
• ▸Measured WIP and cycle time: check WIP = TH x CT, and split cycle time into waiting and process time.
• ▸Upstream variability sources feeding this station: list each with the planned fix (reduce setups, speed repairs, change batching).
• ▸Chosen buffer and WIP cap: state whether variability is absorbed by inventory, capacity or time, and the WIP limit if any.

1. 1Map the line and mark the bottleneck. Compute each station's capacity after detractors (downtime, setups, breaks, yield loss) and take the lowest as the bottleneck rate BNR. Test each station's rate against its true limiting rate, not a one-shift or historical-average 'capacity'. If conditions such as yield or product mix vary, the bottleneck can float, so mark every station that can become the bottleneck.
2. 2Read the capacity buffer at each station as 1 minus utilization u, where u = arrival rate / true capacity. The punch press has capacity 1.43 parts/hr. A release rate of 1.167 parts/hr gives u = 82%, so an 18% capacity buffer. A release rate equal to capacity gives zero buffer, and no real system sustains that.
3. 3Read the inventory buffer as average WIP at and in front of each station, and as total line WIP. Compare it to the critical level BNR × RPT. This is the WIP at which the best-case line just reaches BNR (best case: TH ≤ min{WIP/RPT, BNR}, CT = max{RPT, WIP/BNR}).
4. 4Read the time buffer as the waiting time that exceeds raw processing time. Use WT = V × U × T and CT = VUT + T at the station. Waiting time is what the variability looks like once inventory and capacity are used up.
5. 5Check how the three buffers trade off against each other. Because the U factor is proportional to 1/(1−u), moving utilization from 82% toward 100% inflates waiting time nonlinearly. Do not extrapolate from two nearby data points. Record whether the line's variability is landing on WIP, on idle capacity, or on customer lead time.
6. 6Cut the amount of buffer you need before you add any. First, reduce V, especially at the bottleneck, where V and U interact most strongly. Second, add flexibility, since flexibility reduces the buffering required. Third, pool variability sources so they share one buffer. Fourth, consider pull, which gets more throughput for the same average WIP and tolerates WIP-level errors better than push tolerates release-rate errors.
7. 7Place any buffer you still need adjacent to the bottleneck. With identical nonbottleneck stations, the largest drop in WIP and cycle time per unit of added nonbottleneck capacity, or per unit of added WIP buffer space, comes from the process directly before or after the bottleneck.
8. 8Set stock buffers by service target. In a base stock system, safety stock rises with the target fill rate and, at high fill rates, with the standard deviation of demand during replenishment lead time. Record the resulting buffering state and re-measure it whenever mix, yield, or demand variability changes.

IBM's Procoat operation (raw circuit boards, early 1990s) had Expose as the bottleneck at about 2,900 boards/day. Raw process time through Coating, Expose, Develop, Bake and Inspect was about half a day, and WIP averaged about 1,500 boards. The best-case benchmark gives critical WIP = BNR × RPT = 2,900 × 0.5 ≈ 1,450 boards. Best-case CT = max{0.5, 1,500/2,900} ≈ 0.52 day, and TH ≤ min{1,500/0.5, 2,900} = 2,900/day. So the inventory buffer sat right at the level where a perfectly smooth line would hit full bottleneck rate. Yet the line had serious throughput problems and the plant paid an outside vendor for capacity. That points to variability consuming the buffers: with little capacity slack at Expose and no extra WIP, every disruption turned into lost throughput. This is my inference. The passage excerpt ends before giving Procoat's actual throughput or the fix. The buffering-state reading says to measure the actual TH and CT against this best case, locate the variability (V) at or near Expose, and either reduce it or add capacity or buffer next to the bottleneck, rather than pay for outside capacity.

• If a station's utilization is near 100%, treat its capacity buffer as gone. Expect variability to appear as WIP and waiting time that grows nonlinearly, and lower u or cut V there first.
• If you have a choice of where to add one unit of capacity or WIP space, put it directly before or after the bottleneck, not at a distant station.
• If a buffer could be replaced by flexibility (cross-trained labor, flexible resources) or by pooling several variability sources into one shared buffer, do that first, because both reduce the total buffering required.
• If the strategy weights speed and service over cost, accept more inventory or capacity buffer. If it weights cost, push toward variability reduction and a smaller time buffer. Decide this explicitly rather than let the buffers form by default.
• If the target fill rate is high or the standard deviation of lead-time demand rises, raise safety stock accordingly. If the part is low volume, highly variable or costly, stock it centrally. If it is low variability or cheap, stock it locally.

• Counting one buffer only (e.g., WIP) and missing that the same variability is showing up as idle capacity or longer lead time. The tell: WIP is cut but cycle time or utilization worsens elsewhere.
• Claiming a line runs at 100% or 120% of capacity. The tell: 'capacity' is a shift, staffing level or historical rate, not the true limiting rate. Real output cannot equal or exceed true capacity.
• Extrapolating waiting-time effects linearly. The supermarket going from 30 to 29 cashiers raised waits from 4 to 4.5 minutes, but 1/(1−u) behavior means the next cut will not add only another half minute. The tell: a plan that assumes equal steps for equal staffing cuts.
• Spreading buffer evenly or adding it where it is easiest. The tell: added WIP space or capacity at stations far from the bottleneck produces little change in WIP or cycle time.
• Fixing the bottleneck once and assuming it stays fixed. The tell: yield or mix changes and a different station, e.g. station 3 when yield improves, starts accumulating queue.

• ▸Station / role: name the station and mark whether it is the bottleneck, a candidate floating bottleneck, or a nonbottleneck.
• ▸True capacity (per hr/day): rate after downtime, setups, breaks and yield loss, not nominal or shift-based.
• ▸Arrival/release rate and utilization u: arrival rate divided by true capacity.
• ▸Capacity buffer: 1 − u, with a note on whether it is being eroded.
• ▸Inventory buffer: average WIP at the station, and line WIP versus BNR × RPT.
• ▸Time buffer: average waiting time WT and ratio WT/T; use VUT to see how much is V versus U.
• ▸Variability source and V estimate: where processing or arrival variability comes from (outages, setups, mix, batching).
• ▸Flexibility / pooling options: cross-training, shared resources or shared buffers that could cut required buffer.
• ▸Buffer position check: distance of any added capacity or WIP space from the bottleneck, and the decision (add adjacent to the bottleneck, or reduce V first).
• ▸Strategy fit: whether the buffer mix matches the cost / speed / service priority, and the date to re-measure.

1. 1Compare variability level by level. Pull order history at retail (consumer sales), distributor, and manufacturer for the same product and period, and compare their variability (as in the source's Figure 9.6: steady retail, highly variable at the top). Variability that grows going up the chain is the signature. The source's footnote warns that aggregated industry data can hide it, so test within your own firms.
2. 2Label every upstream order spike as one of four causes: batching, forecasting, pricing, or gaming. Ask of each spike: was it a lot-size order, a safety-stock add-on to a forecast, a promotion buy-forward, or an inflated order during a shortage? One spike can have more than one cause.
3. 3Test batching first. Check whether retailers order from distributors in lots, and distributors from the manufacturer in even larger lots. If so, smooth consumer demand is being turned into lumpy manufacturer demand. Lower the cost of placing an order (EDI), and consolidate multiple products onto one truck so full-truck economics survive with smaller lots (third-party logistics can help).
4. 4Test forecasting. Check whether each firm forecasts from the orders of the firm below it and adds its own safety stock. If so, each level's spike is larger than the one beneath it, and dips are amplified the same way. Fix it with a common demand dataset at all levels: sell-through data in contracts (as IBM, HP, and Apple require from resellers), or vendor-managed inventory (as P&G controls Pampers from 3M to Wal-Mart).
5. 5Shorten replenishment lead time. Safety stock rises with lead time, so shorter lead times cause less amplification of demand spikes. Reduce variability, apply postponement, and eliminate waste to get there.
6. 6Test pricing. Identify spikes that coincide with promotions or anticipated promotions, when customers buy forward. Move toward everyday low pricing. Use activity-based costing to expose inventory, shipping, and handling costs of promotions that traditional accounting hides, which supports the case for stable prices.
7. 7Test gaming. Check whether shortages are allocated in proportion to quantities on order, and whether excess orders can be cancelled when the shortage ends. If so, customers have an incentive to exaggerate. Allocate scarce supply by past sales, and restrict order cancellation.
8. 8Re-measure after each change, and keep the fix tied to its cause. A fix that does not match the diagnosed cause leaves the amplification in place. Because all variability must be buffered, measure success by the buffering (inventory, capacity, time) you no longer need.

The source describes a retail-to-manufacturer chain (Figure 9.6) where retail orders are quite stable while the manufacturer sees highly variable demand. Take the four causes in turn. Batching: customers buy small quantities, retailers order from distributors in lots, and distributors order from the manufacturer in even larger lots, so smooth demand becomes lumpy. Forecasting: a retailer sees a small spike and orders slightly more to cover anticipated demand plus safety stock. The distributor forecasts from that order and adds its own safety stock, so the order is larger again, and the manufacturer sees an amplified spike. The same happens in reverse for a dip. For the remedy, the source cites real practice: IBM, HP, and Apple require sell-through data from resellers, and P&G controls Pampers inventory from supplier 3M to customer Wal-Mart, so demand data is shared automatically and inventory can be pooled across levels. Pricing and gaming get their own fixes: everyday low pricing, and allocating shortages by past sales with restricted cancellation.

• If order variability grows at each step up the chain but consumer demand is steady, then work through the four causes (batching, forecasting, pricing, gaming) before adding buffers, because the amplification is created by ordering behavior.
• If every firm forecasts from the orders of the firm below it, then share one set of demand data (sell-through data, or VMI in an interfirm chain), because independent safety-stock additions compound.
• If large lots are driven by truckload economics, then let multiple products share the truck (via a third-party logistics company) and cut order cost with EDI, rather than shrinking lots alone.
• If spikes line up with promotions, then move to everyday low pricing and use activity-based costing to show the hidden inventory, shipping, and handling cost of promotions.
• If shortages are allocated in proportion to orders and cancellations are free, then allocate by past sales and restrict cancellation, because exaggerated orders appear exactly when demand is high.

• Judging amplification from industry-aggregate data only. The tell: the aggregate looks flat while your own manufacturer-level orders swing widely. The source notes aggregated data does not rule out strong amplification within individual firms.
• Fixing one cause and ignoring the others. The tell: you cut lot sizes but still see spikes at promotion dates or during shortages.
• Each tier forecasting from the tier below's orders instead of end-customer demand. The tell: spikes grow larger at each level, and dips deepen the same way.
• Optimizing truckload transportation cost while ignoring batch size. The tell: full-truck orders keep arriving as lumpy demand upstream. Mixed-product trucks keep transport cost low with smaller batches.
• Promotions justified by traditional accounting. The tell: the promotion looks profitable, yet inventory, shipping, and handling costs never appear in the case. Activity-based costing exposes them.

• ▸Product / supply chain levels: list retail, distributor, and manufacturer for the product you are examining.
• ▸Order variability by level: record the variability of orders at each level for the same period and note whether it rises going upstream.
• ▸Batching evidence: note lot sizes at each level and whether orders are truck-driven.
• ▸Forecasting evidence: note whether each level forecasts from the orders below it and adds its own safety stock; record whether sell-through data is shared.
• ▸Pricing evidence: list promotions and the order spikes that follow or precede them.
• ▸Gaming evidence: note how shortages are allocated, whether cancellations are allowed, and any order inflation in shortages.
• ▸Lead time: record replenishment lead time at each level and the planned reduction.
• ▸Countermeasure chosen per cause: EDI or mixed trucks; common data or VMI; everyday low pricing; allocation by past sales or restricted cancellation.
• ▸Re-measured variability by level: record the post-change variability and the buffer reduction.

1. 1Fix the boundary first. Name the entity (part, loan application, job, transaction) and the start and end events of the system. Cycle time is the time an entity takes to traverse the system, including rework, restarts from yield loss, and other disruptions. Do not drop rework from the clock.
2. 2Separate manufacturing cycle time (time in the system) from customer lead time (time between order placed and order received). Decide which one you are measuring and label every number with it. Little's law addresses manufacturing cycle time only.
3. 3Compute the baseline from Little's law: CT = WIP / TH. Take average WIP and average throughput over a long enough window that the process is stable. Little's law holds only over the long term, for a stable process. Use the same units for WIP (physical or dollars) on both sides of any comparison.
4. 4Benchmark against the two bounds. Best case: CT = max{RPT, WIP/BNR}. Worst case: CT = WIP × RPT. RPT is raw process time and BNR is the bottleneck rate. Place your measured CT between them. A value near worst case signals heavy variability, batching, or disruption, not a lack of capacity.
5. 5Locate where the time sits. Because "where there is WIP there is cycle time," walk the routing and find the stations where WIP piles up. Those stations are where the waiting is.
6. 6Decompose waiting at each pile-up with the queueing principle, WT = V × U × T. V is variability, U is utilization, T is average effective process time. Check which factor is out of line: a station near 100% utilization, high variability, or a long effective process time.
7. 7Check for batching delay. If items are processed or moved in batches (for example, full truckloads only), inventory and cycle time rise in proportion to batch size. Try smaller batches, but note that the smallest batch size that yields a stable system may be greater than one.
8. 8Pick the lever by where the constraint sits. For capacity or buffer space on non-bottleneck stations, add it at the process directly before or after the bottleneck first. That position gives the largest drop in WIP and cycle time. Then re-measure WIP and TH and recompute CT. If TH is held constant, any WIP reduction must show up as a CT reduction.

The source gives one concrete case: a plant that ships to a warehouse only in full truckloads. Finished goods inventory builds at the plant while trucks wait to fill, and warehouse stock is high because of the bulk shipments. By Little's law, more inventory at constant throughput means longer cycle time at both locations. If the plant shares trucks across products so each product ships in partial loads, stock falls at both sites, and the time an item spends in each falls with it. The numbers below are illustrative arithmetic, not from the source. Suppose a line holds 60 jobs (WIP) at 12 jobs/day (TH). CT = 60/12 = 5 days. Suppose RPT is 1 day and BNR is 15 jobs/day. Best-case CT = max{1, 60/15} = 4 days. Worst-case CT = 60 × 1 = 60 days. At 5 days the line sits close to best case, so the remaining gain is small unless WIP falls. If the same line ran at 30 days, you would look for batching delay and high-utilization queues, not for more capacity. Either way, you would look at the stations holding the WIP.

• If you want to cut cycle time and throughput must stay constant, then cut WIP. Little's law makes them one program, so do not fund separate WIP and cycle time initiatives.
• If a station's utilization is approaching 100%, then expect cycle time to rise sharply there. Lower utilization or variability at that station before touching anything else.
• If inventory builds because items move or process in batches, then shrink the batch toward the smallest size that keeps the system stable. Delay grows proportionally with batch size.
• If you have limited capacity or buffer space to add on non-bottleneck stations, then place it directly before or after the bottleneck. That position gives the largest WIP and cycle time reduction.
• If measured CT is far above the best-case bound max{RPT, WIP/BNR}, then treat variability, batching, and disruptions as the cause and look for them at the WIP pile-ups.

• Quoting customer lead time as manufacturing cycle time (or the reverse). The tell: the number includes order-entry or delivery delay, or it ignores what the customer actually sees.
• Applying CT = WIP/TH to an unstable or short window, such as a ramp-up week. The tell: WIP is trending up or down and the computed CT does not match tracked entity times.
• Excluding rework, restarts, or disruptions from the clock. The tell: the reported CT is close to raw process time but entities visibly loop back.
• Chasing 100% utilization to look efficient. The tell: WIP and waiting at the station grow faster than output as utilization nears full, and CT rises sharply.
• Averaging away variability when diagnosing delay. The tell: average process times look fine, yet waits are long. The queueing term WT = V × U × T shows that variability and utilization drive the wait, not process time alone.

• ▸Entity and boundaries: name the entity and the start and end events. Say whether rework and restarts are included.
• ▸CT type: manufacturing cycle time or customer lead time.
• ▸Average WIP and unit: the long-term average, in physical or dollar units, over a stable window.
• ▸Average TH: entities per time unit over the same window.
• ▸Computed CT = WIP/TH: record the result and the time unit.
• ▸RPT and BNR: raw process time and bottleneck rate, used to compute best case max{RPT, WIP/BNR} and worst case WIP × RPT.
• ▸Gap to bounds: position of measured CT between best and worst case, with a one-line reading.
• ▸WIP pile-up stations: list stations in order of WIP held, with utilization (U) and a V rating for each.
• ▸Batching check: current batch or move size, whether it can be reduced, and the minimum stable size.
• ▸Action and re-measure date: the one lever chosen (WIP cut, batch cut, capacity or buffer next to the bottleneck) and the date to recompute CT.

1. 1Define throughput as good units only. Count nondefective entities per unit time (tons of steel per day, cars per shift, customers served per hour). Exclude anything that must be reworked or remade. Set one counting point and one time window and hold them fixed.
2. 2Compute station capacity as base capacity minus detractors. Take the rate under ideal conditions, then subtract losses from failures, setups, rework and operator unavailability. Do this for every station in the flow.
3. 3Find the bottleneck rate (BNR). In a routing, capacity is constrained by the constituent stations, so the slowest station caps the flow. Record BNR and the raw process time (RPT), which is the total process time with no waiting.
4. 4Set the ceiling from the Capacity principle. Long-run throughput is strictly below capacity, so never plan output equal to or above BNR. Compute utilization as arrival rate divided by capacity (ARATE/PRATE) and treat values near 100% as a warning.
5. 5Bound throughput for your current WIP level with the Best Case formula: TH ≤ min{WIP/RPT, BNR}. If WIP/RPT is below BNR, WIP is limiting throughput. If BNR is lower, the bottleneck is limiting it, and more WIP only adds cycle time.
6. 6Track TH and WIP on a regular schedule and derive cycle time from Little's law, CT = WIP/TH. Throughput is directly related to revenue and WIP needs only a periodic systemwide count, so this is cheaper than tracking cycle time per entity.
7. 7Spend improvement effort on bottleneck capacity first, then on variability. Variability in arrivals and process times causes queueing (VUT equation), and queueing wait grows sharply as utilization nears 100%. The system buffers it with inventory, capacity, or time.
8. 8Check for pull. At the same average WIP, a pull system achieves higher throughput than a push system, and it is less sensitive to WIP-level errors than push is to release-rate errors. Cap WIP rather than setting a release rate if you want stable throughput.

The punch press in the source stamps 2 parts per hour at base rate, but availability is 90%, so 1 hour in 10 is lost to downtime. Lost output is (0.1)(2) = 0.2 parts/hour. Capacity is therefore 0.9 × 2 = 1.8 parts/hour, or equivalently 2 − 0.2 = 1.8. By the Capacity principle, long-run throughput of this press must be strictly below 1.8 parts/hour. Suppose it is the bottleneck of a line and the true rate of good parts is 1.5/hour. Utilization is 1.5/1.8 ≈ 83%. Count only nondefective parts in that 1.5. If WIP averages 30 parts, Little's law gives CT = 30/1.5 = 20 hours. Pushing the release rate toward 1.8/hour moves utilization toward 100%. The VUT equation then predicts waiting time rising sharply, so WIP and cycle time balloon while throughput gains stay small.

• If a proposed throughput target is at or above bottleneck capacity, then reject it, because output cannot equal or exceed capacity. Raise capacity (cut detractors or add rate) first.
• If measured TH is well below BNR and WIP/RPT is also low, then WIP is starving the line. Increase WIP toward the point where WIP/RPT reaches BNR.
• If TH is already near BNR and WIP keeps rising, then added WIP only adds cycle time. Cut WIP back and work on the bottleneck.
• If you need nonbottleneck capacity or buffer space, then place it directly before or after the bottleneck, where the WIP and cycle-time reduction is largest.
• If throughput is unstable under a release-rate (push) policy, then switch to a WIP cap (pull). It delivers higher throughput at the same WIP and tolerates WIP-level errors better.

• Counting defective or reworked units as output. The tell: reported throughput exceeds what customers receive, or the same entities are counted twice.
• Planning at 100% of capacity or base rate. The tell: the plan ignores detractors like downtime, setups and rework, and queues and cycle time grow while throughput lags the plan.
• Raising WIP to chase throughput after the bottleneck is saturated. The tell: WIP and cycle time climb while TH is flat near BNR.
• Improving a nonbottleneck station. The tell: the local station shows better numbers but system throughput does not move.
• Computing WIP, TH and CT over inconsistent definitions or boundaries. The tell: Little's law (WIP = TH × CT) fails to reconcile.

• ▸Flow and counting point: name the flow and the exact point where good units are counted.
• ▸Time window: state the unit of time and the averaging period (e.g., per shift, per day).
• ▸Station base rates: list each station's rate under ideal conditions.
• ▸Detractors per station: list downtime fraction, setups, rework, operator unavailability, with the rate lost to each.
• ▸Station capacity: base capacity − detractors, per station; mark the lowest as BNR.
• ▸Raw process time (RPT): total process time through the flow with no waiting.
• ▸Current WIP and good-unit TH: measured averages; add CT = WIP/TH.
• ▸Best-case bound: min{WIP/RPT, BNR}; note whether WIP or the bottleneck is limiting.
• ▸Utilization (ARATE/PRATE) at bottleneck: flag if near 100%, and note the chosen action.

1. 1Fix the unit first: measure inventory in dollars, not pieces. WIP can be counted in physical units or financial units (dollar value of entities in system), and dollars let you add dissimilar items into one figure. Little's law then reads dollars = dollars/day x days.
2. 2Compute the baseline from two numbers you already track. Use average WIP in dollars and throughput as cost of goods sold. Inventory turns = TH (annual COGS) / WIP (average dollar inventory); higher is better, the operational analogue of ROI.
3. 3Cross-check cycle time without time-stamping entities: CT = WIP / TH. For assemblies where entity tracking is impractical, dollar WIP divided by COGS throughput still gives a consistent cycle time. Hold TH constant, and any WIP reduction is a CT reduction, so run one program, not two.
4. 4Classify the dollars by type: WIP, cycle stock, safety stock, congestion stock, anticipation stock. Focus on cycle and safety stock first, because anticipation stock (aggregate planning for long-term demand fluctuation) is less ubiquitous.
5. 5Rank items by annual dollar usage (ABC). Class A (first 5-10% of items, 50%+ of dollars) gets individual attention and sophisticated tools. Class B (next 50-70% of items) gets sophisticated tools without individual intervention. Class C (remaining 20-40%) is kept simple, erring toward ample stock when a cheap part is operationally critical (the fuse).
6. 6Find where the dollars pile up. 'Where there is WIP there is cycle time,' so look at the locations in the flow where WIP accumulates. Per the Buffer Position principle, the biggest WIP and cycle-time gains from added nonbottleneck capacity or buffer space come at the process directly before or after the bottleneck.
7. 7Cut investment structurally, not by decree. Use the buffering principles: pool variability into a common buffer, add flexibility, and stock high-variability, low-volume, or high-cost parts centrally and low-variability, low-cost parts locally. Replace push with a WIP cap (CONWIP is a viable pull system) to hold WIP at a target.
8. 8Re-measure after each change and check that throughput held. Safety stock rises with target fill rate and demand variability over replenishment lead time, so a lower inventory dollar figure that comes with a worse fill rate has only moved cost elsewhere.

The source's Little's law example uses accounts receivable. A firm bills an average of $10,000 per day and customers take 45 days on average to pay. Working in dollars, TH = $10,000/day and CT = 45 days, so average WIP (outstanding receivables) = $10,000 x 45 = $450,000. The same arithmetic applies to physical inventory: dollar WIP = COGS per day x days in system. If you cut cycle time from 45 to 30 days at the same throughput, the tied-up capital falls to $300,000, which is exactly what the CT = WIP/TH rearrangement implies (this $300,000 case is an illustration built on the passage's figures, not from the source). Turns follow from the same inputs: annual COGS divided by average dollar inventory.

• If you know any two of WIP, CT, and TH, then compute the third with Little's law instead of measuring it directly; dollar WIP over COGS throughput is a valid cycle time.
• If an item is Class A (top 5-10% of items, 50%+ of dollar usage), then manage it individually with sophisticated tools; if Class C, then keep the policy simple and hold ample stock when the part is operationally critical.
• If WIP is piling up at specific stations, then target those locations for cycle time work, and add capacity or buffer space adjacent to the bottleneck first.
• If a part is low volume, high demand variability, or high cost, then stock it centrally; if low volume with low variability or low cost, then stock it locally.
• If you must cap inventory investment and capacity is only an estimate, then control WIP (pull/CONWIP) rather than release rate, because WIP is observable and pull tolerates errors in the WIP level better than push tolerates errors in release rate.

• Reading a low inventory figure as success: dollars fall but throughput or fill rate fell too. Tell: turns improve while shipments or service drop; the Little's law relationship only holds as 'good' when TH stays constant.
• Overestimating capacity when setting push release rates, so inventory builds with no extra throughput. Tell: queues swell when the line is full while it starves at other times; detractors (failures, setups, operator outages, quality) were overlooked.
• Spreading effort evenly across all items. Tell: planners spend equal time on Class C fuses and Class A items, while a few items carry over half the dollars.
• Running separate WIP-reduction and cycle-time-reduction programs. Tell: two teams, two metrics, same stations; Little's law says they are one effort.
• Cutting safety stock without regard to variability and fill-rate targets. Tell: stockouts on high-variability or long-lead-time parts after a blanket reduction, because safety stock rises with target fill rate and lead-time demand variability.

• ▸Scope (line, plant, warehouse, or network): state the boundary so WIP, TH, and CT are in consistent units.
• ▸Average inventory in dollars (WIP): average dollar value held across the scope, from periodic systemwide counts.
• ▸Annual cost of goods sold (TH): throughput expressed as COGS per year.
• ▸Inventory turns: COGS divided by average dollar inventory.
• ▸Implied cycle time: dollar WIP divided by COGS per day.
• ▸Inventory mix by type: dollars in WIP, cycle, safety, congestion, and anticipation stock.
• ▸ABC split: share of items and share of annual dollar usage in Class A, B, and C.
• ▸Bottleneck-adjacent accumulation points: stations where WIP piles up, with dollars at each.
• ▸Target change and constraint: target dollar WIP or turns, with the throughput and fill rate that must hold.

1. 1Define the metric per item before you tune anything. Choose one of two forms: fill rate (share of demand met on time from stock) or lead-time performance (share of orders delivered within the quoted lead time). Write down which form each product family uses. Service level is an outcome metric, so it cannot be managed until it is defined.
2. 2Tie the target to your value proposition. Speed and service are positions on an efficient frontier, and you pick where to sit (Grainger sells short lead times and small orders at a price premium; its suppliers sell bulk at lower cost). Set the fill-rate target the strategy implies, then design the system to deliver it at the lowest cost on the frontier. A high-cost, low-service result is off the frontier and is not competitive.
3. 3Name which buffer carries the variability. Variability is absorbed by some combination of inventory, capacity, and time. For stocked items, service is bought with inventory. For quoted-lead-time items, it is bought with capacity or with time (a longer quote). Record the mix for each family so you know what you are paying for.
4. 4For made-to-stock items, set stock with a base stock logic. Safety stock rises with the target fill rate and, at sufficiently high fill rates, with the standard deviation of demand during the replenishment lead time. Estimate that standard deviation over the full replenishment lead time, not over a review period. Late or erratic supplier deliveries lengthen and widen that lead time and push the stock requirement up.
5. 5Locate stock by item type. Hold low-volume, high-variability, and/or high-cost parts at a central (high) level. Hold low-volume, low-variability, and/or low-cost parts at a local (low) level. This buys the same service with less total inventory.
6. 6Pool before you add stock. Combining variability sources onto a common buffer cuts the total buffering needed for a given service level. If physical centralization costs you speed, use virtual pooling: let an information system share inventory across facilities so stock stays local and pooled. The distribution-center example shows this. Overnight shipping makes inter-facility transfers about as fast and cheap as shipments from the center, so the same inventory spread across facilities makes parts more likely to be in stock.
7. 7Place the inventory/order interface by trade-off. Long production lead times push the interface toward the customer for responsiveness. High product proliferation pushes it toward raw materials for pooling efficiency. Decide per product family where the push-to-pull boundary sits and what service form (stock fill or quoted lead time) follows from it.
8. 8Plan demand at the right level. Demand at upper levels is more variable than at retail because of batch ordering, forecasting errors, promotions, and customer gaming. Compute your safety stock from the variability your node actually sees. Where possible, drive upstream stock from retail-level demand rather than from the orders amplified through the chain.

Grainger is a service-level strategy in practice. It makes nothing, and its suppliers could sell the same products at a lower unit cost. Customers still buy from Grainger because it ships small orders with short lead times, while suppliers require longer lead times and bulk purchases. The service level is the product, and the price premium pays for it. The logistics system matches this: Grainger inventories products in warehouses and focuses on efficient order fulfillment, so the buffer is inventory. The suppliers' systems focus on production efficiency and make and ship in large batches, so their buffers are time and batch size. Applying the steps: the metric is on-time fill from warehouse stock, the target is set by the speed-for-premium promise, and stock is held where low-volume, high-variability, or high-cost items can be pooled centrally. Each decision traces back to the same strategic choice. A fast-moving, low-variability item is the opposite case. It can sit locally, with a much smaller central safety stock.

• If the target fill rate rises, then expect safety stock to rise too, and by more once demand variability during replenishment is high. Price that increase before you promise the target.
• If a part is low volume, high variability, or high cost, then stock it centrally. If it is low volume, low variability, or low cost, then stock it locally.
• If service is short on locally held stock but centralizing would slow delivery, then pool virtually through an information system rather than adding stock at each site.
• If production lead times are long, then move the inventory/order interface toward the customer. If product proliferation is high, then move it toward raw materials. If both hold, then decide which dominates for that family and accept the trade-off.
• If upstream demand looks far more variable than retail sales, then check for batch ordering, promotions, and forecasting error before raising safety stock.

• Quoting a service target with no defined metric. The tell: sales, planning, and operations each report a different 'service level' for the same item.
• Sizing safety stock on average demand and ignoring the standard deviation over replenishment lead time. The tell: stockouts cluster on volatile items and on items with unreliable suppliers.
• Buying service with local inventory everywhere. The tell: inventory investment climbs while stockouts persist on slow, volatile items that should be pooled centrally.
• Setting stock from amplified upstream orders. The tell: order patterns at the top are far lumpier than retail sales and stock levels swing with promotions.
• Pursuing a high service level at high cost and low efficiency, below the efficient frontier. The tell: a competitor matches your service at lower cost, because they have chosen a better design rather than a different strategy.

• ▸Product family and strategic role: state the value proposition it supports (speed, service, variety, cost, quality).
• ▸Service metric form: fill rate from stock, or within quoted lead time. Pick one.
• ▸Target level: the number the strategy implies, with the owner who approved it.
• ▸Primary buffer: inventory, capacity, or time. Note what you are paying with.
• ▸Replenishment lead time and its demand standard deviation: record both and the data period used.
• ▸Supplier delivery reliability: note on-time problems that lengthen or widen replenishment lead time.
• ▸Stocking location: central or local, justified by volume, demand variability, and cost.
• ▸Pooling option: physical, virtual, or none, with the transfer speed and cost that make it viable.
• ▸Inventory/order interface position: state lead time versus proliferation reasoning.
• ▸Demand source used for planning: retail-level data or upstream orders, and any bullwhip distortions noted.

1. 1Define the system boundary first. The source defines a supply chain as a goal-oriented network of processes and stock points, judged in business terms, usually long-term profitability. Draw the network of processes and stock points you are costing and name the objective (profit, or cost at a required service level). Without a boundary, you will count one party's savings as system savings.
2. 2Split the cost into the construct's components: buffering cost, holding cost, ordering cost, and lost sales. Then split buffering into the three forms the Variability Buffering principle names: inventory, capacity, and time. Price each in the same unit (per period) so they can be added. Take the prices from your own accounting, because the passages supply none.
3. 3Locate the variability that drives the buffering. The Bullwhip principle says demand variability rises toward the manufacturing level because of batch ordering, forecast errors, promotional pricing, and gaming. List which of these four operate in your chain, and log the variability at each stock point separately.
4. 4Measure the flow baseline with Little's Law (WIP = TH × CT) and the best-case bound (TH ≤ min{WIP/RPT, BNR}; CT = max{RPT, WIP/BNR}). Record bottleneck rate, raw process time, and current WIP. This tells you how much WIP is needed for throughput and how much is just queue that adds cycle time and holding cost.
5. 5Price the trade-off at the margin. Each added unit of buffer (WIP, safety stock, capacity) buys protection against starvation or stockout and costs holding or capacity money. Safety stock rises with the target fill rate and with the standard deviation of demand during replenishment lead time. So raise the fill-rate target only while the lost-sales cost avoided exceeds the added holding cost.
6. 6Test structural levers that cut total buffering before adding any buffer. (a) Pool variability into a common buffer. (b) Add flexibility. (c) Place stock by part type: low-volume, high-variability, or high-cost parts go central, and low-variability, low-cost parts go local. (d) Set the inventory/order interface close to the customer when lead times are long, and close to raw materials when product proliferation is high. Re-run the ledger for each option.
7. 7Where buffer space or capacity must be added at a flow, put it directly before or after the bottleneck. The Buffer Position principle says this location gives the largest drop in WIP and cycle time per unit added.
8. 8Check the result at the whole-chain level. If different firms or departments each optimize a local objective, the Risk Sharing Contracts principle says the system is generally suboptimized because risk falls disproportionately on one party. Compare the sum of local costs with the system cost, and if they diverge, evaluate a risk-sharing contract.

The source's own WIP-buffer illustration shows the trade-off in one step. A production process fed by an arrival process holds 10 minutes of WIP. It starves only if it completes 10 minutes more work than arrives in an interval. Raise the arrival rate so WIP is 11 minutes, and starvation now needs an 11-minute overrun. Starvation falls and utilization rises. But more entities wait, so WIP and cycle time rise, which Little's Law (WIP = TH × CT) ties together. The extra minute of buffer therefore reduces the cost of lost output and increases the cost of holding WIP and waiting time. To get total system cost, you price the avoided starvation, the extra WIP, and the longer cycle time in the same unit, and you add the extra minute only if net cost falls. The source gives no prices, so you must supply them. Next, test whether pooling or placing the buffer at the process directly before or after the bottleneck gives the same protection with less total buffering.

• If you can buy the same service level by pooling variability or adding flexibility, do that before adding inventory, capacity, or time, because both reduce the buffering required.
• If a part is low-volume, high-variability, or high-cost, stock it centrally. If it is low-volume-variability and low-cost, stock it locally.
• If lead times are long, move the inventory/order interface toward the customer. If product proliferation is high, move it toward raw materials.
• If you are raising the target fill rate, expect safety stock to rise with it, and with demand variability over the replenishment lead time. Stop when the extra holding cost exceeds the lost sales avoided.
• If each partner's local optimum differs from the system optimum, treat it as a risk-allocation problem and test a risk-sharing contract before adding more buffer.

• Counting only holding cost and ignoring lost sales and capacity or time buffers. The tell is that inventory falls and service complaints or expediting rise, so total cost does not fall.
• Optimizing one party's cost. The tell is that a supplier or retailer reports savings while the combined chain cost is flat or higher and one party bears the demand risk.
• Setting a high fill-rate target without recomputing safety stock. The tell is inventory climbing faster than service improves, because safety stock rises in both fill rate and lead-time demand variability.
• Adding buffer or capacity at the wrong place in the flow. The tell is that WIP and cycle time barely move, because the largest gain comes from the process directly before or after the bottleneck.
• Treating upstream order variability as real demand. The tell is manufacturing orders swinging more than retail sales (the bullwhip effect), driving excess buffers upstream.

• ▸System boundary and objective: list the processes and stock points included and whether you maximize profit or minimize cost at a stated service level.
• ▸Inventory buffer cost per period: holding cost of safety stock and WIP at each stock point.
• ▸Capacity buffer cost per period: cost of the capacity held in reserve.
• ▸Time buffer cost per period: cost of the cycle-time and lead-time delay you carry (use CT = WIP/TH from Little's Law).
• ▸Ordering cost per period: ordering or setup cost across the chain.
• ▸Lost-sales cost per period: margin lost from stockouts at the current fill rate.
• ▸Variability source and size: which bullwhip drivers (batching, forecast error, promotions, gaming) apply, and the demand standard deviation over lead time.
• ▸Lever tested (pooling, flexibility, stock location, I/O interface position, buffer position, contract): describe it and its new cost in each category above.
• ▸Net change in total system cost: new total minus current total, split by party, to show whether any partner bears disproportionate risk.

1. 1Define capacity per station before computing anything: capacity = base capacity minus detractors. Take the base rate under ideal conditions, then subtract lost output from failures, setups, rework and operator unavailability. A punch press with a base rate of 2 per hour and 90 percent availability has a capacity of 0.9 x 2 = 1.8 per hour.
2. 2Find the arrival rate into each station, not the line's input rate. Where yield loss, fallout or rework routings exist, stations see different volumes. Multiply the release rate by the fraction of entities that reach each station, and count revisits for rework.
3. 3Compute utilization per station as arrival rate into the station divided by station capacity. Use processing times that already include all relevant detractors.
4. 4Rank stations by utilization. The bottleneck is the station with the highest utilization, which is not necessarily the slowest process. Name it and record its utilization.
5. 5Set the line's capacity as the input rate that drives the bottleneck's utilization to 100 percent. This is the reciprocal of its effective process time, adjusted for the share of volume it sees. Treat this figure as a ceiling that output can never equal or exceed (Capacity principle).
6. 6Choose a release rate and a utilization ceiling together. Cycle time rises sharply as utilization approaches 100 percent, because the queueing delay WT = V x U x T grows with the utilization factor. Cap each station at a stated limit. Motorola's wafer fabs used 75 to 85 percent.
7. 7Re-run the calculation whenever yield, product mix or routings change. If yield loss falls, downstream stations get busier and the bottleneck can move. If conditions vary over time, track more than one station as a candidate bottleneck.
8. 8Hold the release rate steady when cycle times spike. Do not add overtime and then drop back to releasing at theoretical capacity once things recover. That re-creates the cycle.

The source's line has four stations. Jobs enter at 1 per minute, and 50 percent drop out after station 2. Process times are 0.7, 0.8, 1.0 and 0.9 minutes at stations 1 to 4. Stations 1 and 2 see 1 job per minute, so utilization is 1/(1/0.7) = 0.7 at station 1 and 1/(1/0.8) = 0.8 at station 2. Stations 3 and 4 see only 0.5 per minute because of the yield loss. Station 3 runs at 0.5/(1/1) = 0.5 and station 4 at 0.5/(1/0.9) = 0.45. Station 3 is the slowest process, but station 2 has the highest utilization at 0.8, so station 2 is the bottleneck. The line's capacity is the input rate that puts station 2 at 100 percent, which is 1/0.8 = 1.25 jobs per minute. Any input above that overloads station 2. Releasing at 1.25 would still be a mistake, because output cannot reach capacity and cycle time would blow up. If yield improves enough, station 3 becomes the bottleneck.

• If a line has yield loss, rework or revisits, then compute utilization from the arrival rate at each station, and do not name the slowest process as the bottleneck.
• If any station's utilization is at or above 100 percent, then the release rate is infeasible: cut releases or add capacity. Output cannot equal or exceed capacity.
• If the system is complex and variable, then size capacity so utilization stays under a set limit, as Motorola did at 75 to 85 percent, and accept the cost of the excess capacity.
• If yield, mix or routings change, then recompute every station's utilization, because the bottleneck can move or float between stations.
• If cycle times balloon and overtime is being used to recover, then lower the release rate to a level below capacity, so you don't release back at theoretical capacity when the crunch ends.

• Naming the slowest station as the bottleneck. The tell: station 3 is slowest at 1.0 minute, yet station 2 is busiest at 0.8 utilization because station 3 sees only half the volume.
• Quoting an arbitrary 'capacity' and then claiming 120 percent utilization. The tell: the baseline is one shift, normal staffing or a historical average rather than the true maximum average rate.
• Using base rate and ignoring detractors. The tell: a press rated at 2 per hour is planned at 2 per hour when it delivers 1.8 after downtime.
• Loading the line to 100 percent to maximize efficiency. The tell: WIP and cycle time climb steeply, then overtime is called in.
• Treating the overtime cycle as a one-off. The tell: after the recovery, management vows 'not to let that happen again' but releases are aimed right back at theoretical capacity.

• ▸Station name: label each station or server group in the routing.
• ▸Base rate (per time unit): the process rate under ideal conditions.
• ▸Detractors: lost output from downtime, setups, rework and operator unavailability, as a rate or as a fraction.
• ▸Effective capacity: base rate minus detractors.
• ▸Release rate into the line: the planned jobs per time unit entering the first station.
• ▸Fraction reaching this station: the share of entities left after yield loss, plus any revisits.
• ▸Arrival rate into station: release rate x fraction reaching the station.
• ▸Utilization: arrival rate divided by effective capacity.
• ▸Utilization ceiling and status: the maximum you allow (for example 75 to 85 percent), then mark OK or over.

1. 1Pick one station and define its two variability sources: interarrival times (time between entities arriving) and effective process times (time from when an entity is ready, no longer behind others, until it is complete). Keep them separate.
2. 2Measure interarrival times with a stopwatch at the station entrance. Log the gap between each arrival and record simultaneous arrivals (two customers in one car) as zero.
3. 3Measure effective process time as everything that extends completion once the entity is ready: failures, setups, operator breaks, waiting for the operator to finish other duties. Do not log only the actual processing time.
4. 4For each series, compute the mean and standard deviation, then divide the standard deviation by the mean to get the CV. The result is unitless, so you can compare arrivals with process times, or one station with another.
5. 5Classify each CV: substantially below 1 is low variability, roughly 0.75 to 1.33 is moderate, and substantially above 1 is high. A CV near 1 is the Poisson signature of many independent customers (toll booths, 911 calls, bank customers).
6. 6Check the shape, not only the number. Low-CV arrivals are smooth and regular (CV 0.07). High-CV arrivals are bursty (CV 2). Find what causes the bursts, such as vendor quality, scheduling policy, or upstream stoppages.
7. 7Feed the CVs into the queueing principle, WT = V × U × T. Variability enters through V, utilization through U, and average effective process time through T. This shows how much queue time variability costs at your current utilization.
8. 8Decide how to buffer what you cannot remove. Variability will be buffered by some combination of inventory, capacity, and time. Name which of the three your system is paying with now, and use pooling or flexibility to shrink the total buffer needed.

The source's blood-donation clinic shows why you measure effective process time rather than raw process time. Cycle time is the whole visit: queue, blood draw, everything. Process time is only the minutes spent giving blood. Effective process time also includes any time the nurse spends cleaning the space, replenishing materials, or handling other duties before or during your donation. Operationally, 20 minutes donating and 10 minutes waiting on the nurse plus 10 minutes donating are identical. If a donor waits through a long cleaning cycle before starting, that donor's effective process time is far longer than the donors before. The clinic's effective process times can therefore be highly variable even when actual donation time is fairly uniform. For arrivals, the source contrasts a CV of 0.07 (smooth) with a CV of 2 (bursty). The assembly-line case sharpens this: cars arrive every 58 seconds, then a quality shutdown opens a 30-minute gap. Against the 58-second norm, that gap is the variability. The principles say the result is more waiting through V, and that the waiting grows sharply as utilization nears 100 percent.

• If you hear a station is running at 100 percent of capacity, then treat the claim as wrong. Real systems contain variability, so long-term utilization never reaches 100 percent. Ask what arbitrary baseline 'capacity' was measured against.
• If releases equal true capacity, then expect unpredictable WIP: long calm periods, then rapid buildup after a failure. Set the release rate below true capacity, with detractors included.
• If CV is near 1 and arrivals come from many independent customers, then assume Poisson arrivals. Spend effort on process-time variability and utilization instead.
• If effective process time CV is high but raw process time is uniform, then attack the detractors (downtime, setups, breaks, waiting on the operator) rather than the core task.
• If variability cannot be reduced, then choose the buffer deliberately: inventory, capacity, or time. Combine variability sources into a shared buffer (pooling) or add flexibility to reduce the total buffering required.

• Measuring only actual processing time and calling it process time. The tell: the station's measured CV is low, yet queues and cycle times are long and erratic.
• Treating a high CV as a single number to cut rather than finding its source. The tell: the same bursts recur because the upstream cause (vendor quality, scheduling, a shutdown) is untouched.
• Planning at 'capacity' based on an arbitrary baseline (one shift, a historical average rate). The tell: reports of 120 percent of capacity, or WIP trending steadily upward.
• Releasing work exactly at true capacity. The tell: two runs of the same system produce very different WIP histories.
• Ignoring the utilization interaction. The tell: a modest rise in load produces a disproportionate jump in WIP and cycle time because cycle time rises sharply as utilization approaches 100 percent.

• ▸Station name and scope: the single process being measured.
• ▸Interarrival time log: raw gaps from stopwatch observation, with simultaneous arrivals recorded as 0.
• ▸Interarrival mean, standard deviation, and CV (SD ÷ mean).
• ▸Effective process time log: time from 'ready' to 'complete', including failures, setups, breaks, and waiting on the operator.
• ▸Effective process time mean, standard deviation, and CV.
• ▸Classification of each CV: low (well below 1), moderate (about 0.75–1.33), or high (well above 1).
• ▸Identified causes of bursts or long times: vendor quality, scheduling policy, upstream stops, detractors.
• ▸Current utilization and average effective process time T, for use in WT = V × U × T.
• ▸Buffer in use: inventory, capacity, or time, plus the planned action (reduce source, pool, add flexibility).

1. 1Classify the operation first. If entities are processed together and the time is roughly the same for one or many (a furnace load, a forklift move), it is simultaneous batching. If entities are processed one at a time between setups (paint colors, copy jobs), it is sequential batching. The classification decides where the capacity gain comes from.
2. 2Name the source of efficiency. The passages give three: setup avoidance (a changeover done at the start of a batch), pacing improvement (extraneous motions that drop away after a few repetitions, like hidden setups), and simultaneous processing (a batch takes as long as a single unit). If you cannot name one, the batch is not buying capacity.
3. 3Compute capacity as a function of batch size. Simultaneous: batch size divided by the fixed cycle time. Sequential: batch size divided by the time for one batch (setup plus processing every unit). Treat setups as detractors that cut the effective rate, as the passages do for setups, downtime and breaks.
4. 4Find the smallest stable batch. Compute utilization as arrival rate divided by capacity. The Capacity principle says output cannot equal or exceed capacity, so the batch size must give utilization strictly below 100%. The Batching principle warns this smallest stable size may be greater than one.
5. 5Add margin above that minimum. Cycle time rises sharply as utilization nears 100% (Utilization principle), and queueing wait scales with variability times utilization times process time. A batch that is only just stable still produces long waits.
6. 6Price the delay of the larger batch. The Batching principle says delay due to batching eventually increases proportionally in batch size. At a given arrival rate, entities wait for the batch to form and then wait out the batch. Compare candidate sizes on both utilization and delay.
7. 7Choose the size between the stability floor and the point where proportional delay outweighs the capacity gain. Do not simply maximize the batch.
8. 8Check the result with Little's Law (WIP = TH × CT). A bigger batch raises cycle time at the same throughput, so the WIP it implies must be physically and financially tolerable.

The passages give a foundry heat-treating operation that needs 3 hours whether the furnace holds one wrench or a hundred. This is simultaneous batching. With a batch of 1, capacity is 1 wrench per 3 hours (0.33/hr). With a batch of 100, capacity is 100/3 = 33.3/hr. Suppose, as an illustrative assumption not in the source, wrenches arrive at 5 per hour. A batch of 1 gives utilization of 5 / 0.33 = 1,500%, so the system is unstable and WIP grows without bound. A batch of 15 gives capacity 5/hr, utilization exactly 100%, which the Capacity principle says cannot be sustained. So the smallest stable batch is above 15, which is far greater than one, as the Batching principle states. A batch of 20 gives capacity 6.67/hr and utilization of 75%. A batch of 30 gives 10/hr and 50% utilization, but at 5 arrivals per hour it takes 6 hours to accumulate a load versus 4 hours for 20. The batch of 30 buys lower utilization at the cost of delay that grows in proportion to batch size. The choice sits between 20 and 30 and depends on how much cycle-time penalty the system can bear.

• If utilization at batch size 1 is at or above 100%, then batching is required for stability, so find the smallest batch with utilization clearly below 100% rather than the largest feasible one.
• If the batch size you are considering gives utilization near 100%, then add margin. Cycle time rises sharply near full utilization, so a barely stable batch will still queue badly.
• If utilization is already comfortably low, then do not enlarge the batch. Delay grows in proportion to batch size and the capacity gain no longer pays for it.
• If the gain comes from setup avoidance or pacing improvement, then check that the setup or extraneous motion is really being removed. If the gain is simultaneous processing, then check that batch time really stays flat as the load grows.
• If a stable operation shows rising cycle time after a batch size increase, then use Little's Law to confirm the WIP increase and consider stepping the batch back.

• Treating bigger as always better because setups drop. The tell: capacity numbers improve while cycle time and WIP climb, since delay rises in proportion to batch size.
• Assuming batch size 1 is the default, or the ideal. The tell: the station is overloaded with growing WIP, yet nobody has checked whether the smallest stable batch is greater than one.
• Sizing the batch to exactly 100% utilization. The tell: the arithmetic says capacity equals arrivals, yet queues keep growing. Real systems contain variability, so output never equals capacity.
• Using a nominal capacity that ignores detractors. The tell: the plan is based on a base rate, and actual output falls short because setups and downtime were not subtracted.
• Mislabeling the batch type. The tell: a simultaneous operation is analyzed with a setup formula, or a sequential one is assumed to take the same time for any size, so predicted and actual capacity diverge.

• ▸Operation and batch type: name the step and mark it simultaneous (processed together) or sequential (one at a time between setups).
• ▸Efficiency source: record setup avoidance, pacing improvement, or simultaneous processing, plus the evidence.
• ▸Arrival rate (entities per unit time): the long-run rate of entities reaching the step.
• ▸Time per batch: for simultaneous, the fixed cycle time; for sequential, setup time plus processing time for every unit in the batch.
• ▸Candidate batch sizes: list three or more sizes to compare, starting with 1.
• ▸Capacity at each size: batch size divided by time per batch, net of detractors.
• ▸Utilization at each size: arrival rate divided by capacity. Mark any size at or above 100% as unstable and any near 100% as too tight.
• ▸Batch-formation delay at each size: time to accumulate one batch at the arrival rate. Note that it grows in proportion to size.
• ▸Selected size and rationale: the smallest size with comfortable utilization margin, plus the Little's Law WIP check (WIP = TH × CT).

1. 1Inventory every buffer you hold, by type: inventory, capacity, time. The Variability Buffering principle says variability is always absorbed by some combination of the three, so a buffer you have not listed is still being paid for somewhere.
2. 2For each buffer, write down what it protects: which entity, station, flow, or demand type. A buffer that protects exactly one of these is specialized. Mark it as a candidate for flexibility.
3. 3Look for places where the same buffer could cover more than one source of variability. Inventory example: stock that can satisfy more than one type of demand. Capacity example: capacity that can shift from one process to another. Ask what would have to be true for it to float.
4. 4Find the point where specialization happens and ask whether it can be pushed later. Benetton's pattern is the model: hold generic undyed sweaters and make them specific (dyed-to-order) only when demand shows its color.
5. 5For inventory, decide where it sits using the multi-echelon rule. Low-volume, high-variability, or high-cost parts go to a central level. High-volume, low-variability, or low-cost parts stay local.
6. 6Check the flexible design against lead time and proliferation. Long production lead times pull the inventory/order interface toward the customer for responsiveness. High product proliferation pulls it toward raw materials for pooling efficiency. Choose the interface position that balances these two forces.
7. 7Cut the specialized buffers to match the new flexible one. Flexibility reduces the buffering required, so the saving only appears when you remove the redundant stock or capacity. Keep the service level you had before as the test.
8. 8Where a buffer stays capacity or WIP space in a line, place it directly before or after the bottleneck, where the Buffer Position principle says it does the most good. Revisit as the strategy shifts, as Peapod's move from localized pick-and-pack to central automated warehouses shows.

Benetton makes sweaters in many colors. If it dyed every sweater in advance, it would need a separate stock for each color, and each stock would have to cover that color's own demand swings. Instead it produces undyed sweaters and dyes them to order. The generic stock now covers demand for any color, so it floats to wherever demand appears. Less of it is needed to reach the same service as stock held as dyed sweaters. Bell & Howell applies the same logic to spare parts for its mail sorting machines. It holds them at a central distribution center instead of at each customer site across the United States. Repair demand at any site can draw on the shared stock, so less centralized stock is needed to hit the service achieved with localized parts. In both cases the buffer is still inventory. What changed is that it is no longer tied to one color or one site. The passages give no unit counts, so the saving is stated only directionally: less stock for the same service.

• If a part has low volume, high demand variability, or high cost, then stock it centrally so one buffer covers many locations. If it has high volume, low variability, and low cost, then keep it local.
• If production lead times are long and customers need fast response, then place the inventory/order interface close to the customer. If product proliferation is high, then place it close to raw materials to pool across variants.
• If demand differs by type (color, site, product) and you hold a separate buffer for each, then look for a generic form that can be specialized later. Specialize as late as you can.
• If a buffer is stuck at one station and cannot be shifted, then ask whether capacity (for example a worker who can move between processes) can substitute for stock. Move buffers that must stay put next to the bottleneck.
• If you adopt a flexible buffer, then reduce the specialized buffers it replaces. Otherwise you pay for both and see no gain.

• Pooling stock without making it truly interchangeable. Tell: the central stock exists, but shortages still occur by type or location while other stock sits unused.
• Centralizing everything regardless of part characteristics. Tell: low-variability, cheap, high-volume parts are held far from demand, adding delay and little pooling benefit.
• Ignoring lead time and responsiveness when moving the interface toward raw materials. Tell: inventory fell, but customers now wait too long for items that are made to order.
• Adding flexibility but leaving the old buffers in place. Tell: total inventory or capacity is unchanged or higher, and the claimed savings never show in the numbers.
• Treating flexibility as one-time and fixed. Tell: the buffer design still reflects an old strategy after the business has moved from convenience to cost competition, as Peapod's did.

• ▸Buffer name and type: label it inventory, capacity, or time.
• ▸What it protects now: list the specific entity, station, flow, or demand type.
• ▸Specialization point: state where the buffer becomes specific, such as dyeing or local stocking.
• ▸Flexible alternative: describe the generic stock or shiftable capacity that could serve several demands.
• ▸Part attributes: record volume, demand variability, and cost to set central versus local.
• ▸Lead time and proliferation check: record whether long lead time or many variants should move the interface.
• ▸Where the flexible buffer sits: name the location or echelon, and for line buffers the position relative to the bottleneck.
• ▸Specialized buffers to reduce: list what you will cut once the flexible one is in place.
• ▸Service level before and after: write the target and the observed result to confirm the same service.

1. 1Check the principle's preconditions before you use it. It is stated for a flow with a fixed arrival rate, identical nonbottleneck processes, and equal-sized WIP buffers in front of all processes. Write down which of the three your line violates. Where it departs from them, treat the result as a starting hypothesis to test, not a rule.
2. 2Find the bottleneck. It is the station with the lowest capacity, where capacity = base capacity − detractors (for example downtime). Compute capacity net of detractors. The punch press at 2 parts/hour with 90% availability is really 1.8/hour, and ranking stations on nameplate rate misplaces the bottleneck.
3. 3Map the flow in order and label each station by distance from the bottleneck: the bottleneck, directly before it, directly after it, and further away. Buffer position is measured against this map, not against the plant layout.
4. 4Treat WIP as a time buffer. Express each queue as minutes of work it represents. A station starves only if it outpaces arrivals by that many minutes. This gives you a common unit for comparing buffers at different stations.
5. 5Rank candidate additions of nonbottleneck capacity or buffer space by position. The principle says the largest drop in WIP and cycle time comes from the station directly before or after the bottleneck. Put the first unit there before spreading anything to stations farther away.
6. 6Decide whether to add capacity, buffer space, or both. The principle gives the same positional answer for both, so use cost and feasibility to choose, not position. Remember the Variability Buffering principle: variability is buffered by some combination of inventory, capacity, and time, so a cut in one buffer shows up as an increase in another.
7. 7Verify with Little's law (WIP = TH × CT). With throughput held constant, a WIP reduction must come with an equal-proportion cycle time reduction. Measure WIP and CT before and after the change. 'Where there is WIP there is cycle time,' so the stations where WIP piles up are where to look first.
8. 8Repeat the logic at network scale. The same positional question applies to stock points in a supply chain (central vs. local stocking, and where the inventory/order interface sits). Apply those principles there, and do not carry the line-level adjacency rule over unchanged.

The passages give no numeric buffer-position case, so this example is illustrative, built from the Buffer Position principle and its stated assumptions; the stations and 'unit' increments are hypothetical, not from the source. Take a five-station serial line with a fixed arrival rate. Station 3 has the lowest net capacity (base rate minus detractors such as downtime), so it is the bottleneck. Stations 1, 2, 4 and 5 are identical, and each has the same-sized WIP buffer in front of it. You have one unit of extra nonbottleneck capacity, or one unit of buffer space, to place. The principle says it will cut WIP and cycle time most at station 2 or station 4, the stations directly before and after the bottleneck, and least at stations 1 and 5. The usual instinct is to add buffer at the end of the line or at the entry point. Applying the principle puts it next to the bottleneck instead. You then confirm with Little's law: if throughput is unchanged, a drop in average WIP shows up as a proportional drop in cycle time (CT = WIP/TH). If the measured improvement is smaller than expected, check whether the line's stations are really identical, because the principle's guarantee depends on that.

• If you have one unit of nonbottleneck capacity or WIP buffer space to add, then place it at the station directly before or after the bottleneck, not at the line's ends or at distant stations.
• If stations are not identical or buffers are not equal-sized, then treat the adjacency rule as a hypothesis and test it, because the principle is only stated for the identical, equal-buffer case.
• If WIP is piling up at a specific location, then start your cycle time improvement there: with throughput constant, WIP and cycle time fall together.
• If you cut buffer in one place, then ask what replaces it (capacity or time), since variability must be buffered by some combination of inventory, capacity, and time.
• If the problem is stocking across a supply chain, then use the stocking-location principles: low volume, high demand variability, or high cost parts go to a central level, and low volume, low variability, or low cost parts go local. Long production lead times pull the inventory/order interface toward the customer, and high product proliferation pulls it toward raw materials.

• Misidentifying the bottleneck by using nameplate rates instead of capacity net of detractors like downtime. The tell: the buffer you added sits next to a station whose measured queue stays small while another station's queue keeps growing.
• Spreading buffer evenly because it feels fair. The tell: every station gets the same extra space and WIP and cycle time barely move, while the stations beside the bottleneck are still starved or blocked.
• Applying the adjacency result outside its conditions (non-identical stations, unequal buffers, variable arrival rate). The tell: the measured gain at the 'right' station does not match the prediction.
• Treating buffer position as a standalone fix and ignoring that buffers substitute for one another. The tell: WIP falls but customer lead time or lost capacity rises elsewhere.
• Running separate WIP-reduction and cycle-time-reduction efforts. The tell: two programs with two sets of metrics on the same stations, though with throughput constant the two are the same lever.

• ▸Station sequence: list stations in flow order, one per line.
• ▸Net capacity per station: base rate minus detractors (e.g., base rate × availability).
• ▸Bottleneck station: the lowest net capacity; note the margin to the next-lowest.
• ▸Distance from bottleneck: label each station before, after, or number of steps away.
• ▸Assumption check: arrival rate fixed? nonbottleneck stations identical? buffers equal-sized? Answer yes/no for each.
• ▸Current WIP at each station: express in units and in minutes of work.
• ▸Candidate addition: capacity unit or buffer-space unit, with cost per unit.
• ▸Chosen placement: station adjacent to the bottleneck (or reason for deviating if an assumption failed).
• ▸Before/after check: record WIP, throughput, and cycle time; confirm WIP = TH × CT holds.