Buffer Management in Theory of Constraints: Protecting Throughput From Disruption

Buffer management is the Theory of Constraints method for protecting the constraint from disruption by releasing work early enough that it is always waiting when the constraint needs it, then watching how much of that lead time each job has used. The buffer is a length of time, not a pile of parts. The monitoring tells you when to chase a late job and, over weeks, which recurring disruptions deserve a permanent fix.

The reason is arithmetic. Plant output cannot exceed what the constraint produces, so a minute the constraint spends starved or blocked is sellable output that can never be recovered, as explained in manufacturing throughput and production flow rate. This post covers how to size a buffer, run its three zones, and turn the signals into improvement. It sits inside the Theory of Constraints and pairs with drum buffer rope, which is the scheduling system the buffer plugs into.

A Time Buffer Is Not a Pile of Inventory

Most plants already have inventory in front of their slowest machine, and most of it protects nothing. A stack that grew because upstream stations outrun the constraint is a symptom of uncontrolled release, not a buffer.

A TOC time buffer is the interval by which you release material ahead of the moment the constraint is scheduled to need it. If the paint line is scheduled to start a job at 14:00 and the buffer is 180 minutes, the job is released at the first operation at 11:00. K. J. Youngman, in his drum-buffer-rope guide, puts it plainly: the buffer is concerned with time and not quantity, and a heap of work in front of the constraint is a common misunderstanding of it.

Two consequences follow. The buffer is measured from release (the gating operation) to the constraint, not just the safety margin at the end, and since net processing time is usually minutes while queue time is hours or days, most of the interval is waiting. And because it is a time, a buffer can shrink without anyone removing parts: cut the interval, release later, and lead time and work-in-process fall together. Jobs waiting in front of the constraint are what a healthy buffer produces, an effect to monitor, not a quantity to top up.

Stock buffers also exist in TOC, mainly for raw material and make-to-stock finished goods. This post covers the time buffer at a production constraint.

Why the Constraint Is the Thing You Protect

Goldratt and Cox made the idea famous in *The Goal*, and it is usually summarized this way: time lost at the bottleneck is lost for the entire system, while time saved at a non-bottleneck adds no output. The logic is simple. Upstream stations have spare capacity by definition, so a stoppage there is usually made up by running faster afterward. The constraint has no spare capacity.

A constraint loses time in two directions. Starved, it waits for material because something upstream stopped, ran late or sent bad parts. Blocked, it holds finished parts with nowhere to put them because the next station is down or full. The discipline is the same for both: a small, controlled amount of work waiting in front of the constraint, and room after it so its output always has somewhere to go.

Upstream disruptions are the larger concern because they are frequent and random: a jam on a cutting station, a late forklift, a missing label roll. Any of them can cost the constraint a quarter hour if nothing is waiting. The buffer converts that lost time at the constraint into slightly longer waiting at a non-constraint, where waiting is cheap.

This only works if upstream stations really do have more capacity than the constraint. TOC practitioners call that margin protective capacity. Lisa Lang, a TOCICO certified expert, offers 25 to 30 percent at non-constraints as a starting rule of thumb, nothing more. Without it the buffer drains after a disruption and never refills, and no buffer size will rescue the schedule. To confirm which resource is the constraint, start with bottleneck elimination strategies or the bottleneck calculator.

How to Size a Buffer

There is no formula that gives the correct buffer. Every number here is a starting point to be corrected by data. A 2003 paper in the *International Journal of Production Research* by Yuan, Chang and Li notes that TOC leaves the optimal size undetermined and argues that accurate, prompt monitoring matters more than a precise initial figure.

The starting rule: half of current lead time

The most widely repeated starting point is to take the current release-to-constraint lead time and halve it. K. J. Youngman's guide gives an example of an 18-day lead time becoming a 9-day buffer, and Chandrark Karekatti, writing in Apparel Resources, applies the same rule to a sewing plant, cutting a six-day traverse time to three. For plants that cannot measure lead time, Karekatti offers an alternative: three times the back-to-back time a work order would take if nothing delayed it, estimated by the planners who expedite orders.

Half works as a first guess because current lead times are mostly queue time created by releasing too much work too early. It is still a guess. A plant with very reliable upstream processes may start lower, and one with long transport times or erratic suppliers may start higher.

Adjust from data, not opinion

After a few weeks of tracking, adjust using what jobs actually did. Two published heuristics make usable trial triggers:

• Lisa Lang's guidance for the Velocity Scheduling System is that a healthy buffer enters the red zone about 5 percent of the time. Much more often means the buffer or the protective capacity is too small. Never turning red means there is more protection than needed.
• A 2012 University of Pretoria study by Shevon Delport built buffer dashboards in Excel for one company. Four consecutive periods in green meant the buffer was too large, three in red meant too small, and the buffer changed by 20 percent either way. That is one study, a trial setting and not a standard.

Whichever trigger you use, change one buffer at a time, by a modest step, and wait long enough to see the effect.

Buffer Zones: Green, Yellow and Red

To make a buffer actionable, divide its length into three equal zones. Per the TOC dictionary entry on buffer management, the first third is green, the second third is yellow and the last third is red. Zones are slices of elapsed time, not areas of floor. With a 180-minute buffer, a job is green for the first 60 minutes after release, yellow to 120 and red to 180.

The aim is that work reaches the constraint's queue while its order is still in the yellow zone. Karekatti puts it as most orders finishing within the first two thirds and waiting in front of the constraint for the rest. Penetration is the share of the buffer already used when the job reaches the constraint, or its current share if it has not yet arrived.

Rule of thumb for the floor: a job that is not at the constraint's queue when the red zone begins gets located, tagged and moved.

What to do in each zone

Green (0 to one third used). Do nothing special. Expediting green jobs is the most common way buffer management breaks down, since it pulls attention from jobs at risk.

Yellow (one third to two thirds used). Check that the job is where the plan says. The supervisor confirms material is available and the right station has the job in its queue. Do not intervene in the process unless you already know of a problem.

Red (the final third). Find the job and help it. Locate it physically, mark it (a red tag works), move it ahead of other jobs at each station, and ask what is holding it. Overtime, splitting a lot or borrowing an operator is justified here. Some practitioners add a fourth state for a job still missing when the constraint needs it; always record its cause.

Penetration also sets priority: if two jobs wait at a non-constraint, run the one that has used more of its buffer, not the one that arrived first.

Monitoring Penetration

The simplest metric is percent of buffer consumed: minutes since release divided by buffer length. A job released 130 minutes ago against a 180-minute buffer is 72 percent consumed, so it is in red.

The TOC dictionary entry lists four jobs for buffer management: ranking work by penetration, flagging orders to expedite, feeding back to planning when buffers need changing, and identifying the main causes of delay. The first two happen every shift, the last two weekly or monthly.

A workable routine: list every released job not yet at the constraint, sort by percent consumed, walk the red ones to find where each is and why it is late, and record the reason code before the shift ends while people remember.

Review at fixed times, such as shift start and mid-shift, by one named person, often called the buffer manager. If everyone is responsible for the buffer, nobody is.

Reason Codes and the Pareto of Disruptions

Chasing late jobs protects this week's throughput; learning why they are late protects next year's.

Every time a job enters yellow or red, write down why. A short, fixed list keeps the data usable: material not available, upstream machine down, changeover overran, quality hold or rework, operator absent, transport delay, paperwork missing. Keep an "unknown" code too, so that unknown becomes a number and a target.

The TOC dictionary entry says records of which work areas cause holes in the red zone should direct continuous improvement. Lang describes the monthly routine: run the reasons through a Pareto analysis to find the biggest obstacles to flow, then use lean or Six Sigma tools to reduce or remove them. Every removed disruption reduces variability, so the buffer needed shrinks and lead time shortens. That loop makes buffer management more than firefighting, and it uses the same ranking logic as the loss prioritization framework.

Count events and minutes. A cause that happens four times and costs 15 minutes each matters less than one that happens twice and costs 90.

A Worked Example With Numbers in Minutes

The numbers below are hypothetical, chosen to keep the arithmetic easy. A plant's constraint is a powder-coat oven that cures one rack of 40 parts every 12 minutes. The release-to-oven lead time for a typical job is currently 360 minutes.

Sizing. Using the half-of-lead-time start, the buffer is 360 ÷ 2 = 180 minutes. Each zone is 180 ÷ 3 = 60 minutes. A job needed at the oven at 14:00 is released at 11:00. At 12:00 it enters yellow, at 13:00 it enters red.

What an idle oven costs. If a starved oven loses 30 minutes, that is 30 ÷ 12 = 2.5 racks, or 100 parts, that the plant never makes.

Two weeks of tracking. The buffer manager logs 80 jobs. 62 reached the oven's queue within 120 minutes (green or yellow) and 18 took longer, entering red. That is 18 ÷ 80 = 22.5 percent in red, far above Lang's 5 percent benchmark. The reason codes for those 18 events:

• Material shortage from a supplier: 7 events
• Press changeover overran: 5 events
• Weld fixture breakdown: 3 events
• Rework after inspection: 2 events
• Operator absent: 1 event

The Pareto reads like this. Material shortages are 7 of 18, or 39 percent. Adding changeover overruns brings the total to 12 of 18, or 67 percent. Adding weld fixtures reaches 15 of 18, or 83 percent. The plant fixes the first two.

Acting on it. The team moves the supplier's delivery window earlier and sets a minimum on-hand level for the three items behind every shortage. On the press, they apply setup reduction to the changeover that overran its 25-minute standard. After four more weeks, the red rate falls to 6 of 80, or 7.5 percent.

Adjusting the buffer. At 7.5 percent, still above 5, the team holds the 180 minutes for another cycle. If the rate reaches 5 percent or less and the oven never starves, a trial cut of 20 percent, to 144 minutes, is the next step, removing 36 minutes of work-in-process age per job. If the oven starves after the cut, they go back up.

Physical Forms of a Buffer

All three forms need a release time on each job and a way to see percent consumed.

A marked floor space. Paint or tape out the area immediately in front of the constraint, with spots for a fixed number of jobs. Size it from the constraint's rate: if a healthy queue holds about the last third of the buffer, which is 60 minutes of oven work at 12 minutes a rack, five rack spots cover it. Zones are about time since release, not location, so color-coding the spots misleads; the tag on the job carries the zone. Empty spots at the constraint while jobs sit in red upstream are the visual alarm.

A kanban-like card count. Each job carries a card marked with the release time and the time it enters yellow and red. The cap on cards in circulation limits releases, as in the core principles of kanban. Unlike standard kanban, the card encodes time, so the board shows what to chase, not just what to make.

A software queue. A shared list from the MES, ERP or even a spreadsheet, showing each open job, release timestamp, buffer length, percent consumed and zone, sorted by penetration. Software makes reason codes and the monthly Pareto easy, but without accurate release and arrival scans it produces confident wrong answers. In any form, the signal must be visible at the constraint and the release point.

Limits and Failure Modes

• A buffer that is too big hides problems. Extra time absorbs every disruption silently, so nothing turns red and nobody investigates. Lead time and work-in-process stay high. If the buffer never leaves green for many weeks, test a smaller one.
• A buffer that is too small starves the constraint. Frequent red entries and a waiting oven are the sign. Raise it, and check protective capacity upstream, which a larger buffer cannot replace.
• Buffers in front of non-constraints. Piling work before every machine for safety lengthens lead time without protecting throughput, because only the constraint needs the protection. Assembly points where a constrained part meets a free-flowing part, and the shipping date, can warrant their own time buffers, but make each a deliberate choice.
• Disruptions at the constraint itself. A buffer protects against upstream variability. It does nothing for breakdowns, long changeovers or quality losses on the constraint machine. Those are direct throughput losses, found by tracking the six big losses there and checked with the OEE calculator.
• A moving constraint. If the constraint shifts with product mix, the buffer must move with it, or the plant must decide where it wants the constraint to live.
• Chronic problems treated as random. If the same cause fills the red zone every week, that is a defect in the system. Fix it, do not buffer it.
• Weak data. If release times are guessed or arrivals logged at the end of the day, penetration numbers are fiction. Set up a simple scan or sign-off first.

Buffer management also fits poorly in operations with no stable constraint, and on flow lines with so little variability that a few units of work-in-process already protect it.

A Starter Checklist for Monday

1. Confirm the constraint. Use the oven, press or cell that is actually limiting plant output, not the one that is loudest.
2. Measure the current release-to-constraint lead time over two weeks.
3. Set the starting buffer at half that lead time, written down as an assumption, and split it into three equal zones.
4. Choose the physical form (floor space, cards or software) and put a release time on every job.
5. Name one buffer manager and set fixed review times each shift.
6. Define the action per zone: nothing in green, confirm in yellow, locate and expedite in red.
7. Create 6 to 8 reason codes plus "unknown" and log one on every yellow or red entry.
8. Check protective capacity at the stations feeding the constraint.
9. After two to four weeks, run a Pareto by event count and minutes, fix the top two causes, and only then revisit the buffer length.

Frequently Asked Questions

What is the difference between a buffer and safety stock?

Safety stock is a quantity of goods held against variation in demand or supply, monitored by units on hand. A TOC time buffer is an interval of lead time that governs when work is released to protect a constraint, monitored by how much of that time has been used.

How big should the buffer be?

There is no correct size in advance. A common starting point is half of the current release-to-constraint lead time, then adjust from penetration data. Some practitioners aim for red about 5 percent of the time. Treat both as trial values.

Do I need software to run buffer management?

No. A whiteboard, cards with release times and a daily walk are enough to start. Software helps once there are many jobs or several constraints.

Should every machine have a buffer?

No. The time buffer protects the constraint and, in some designs, assembly points and the shipping date. Buffers before every machine add lead time and work-in-process without adding throughput.

What if the constraint is the market and not a machine?

Then there is no production constraint to protect, and effort at a machine will not raise sales. The buffer that matters is the shipping buffer protecting delivery dates, and improvement work moves to demand and quoting.