Capacity-Constrained Resource (CCR) §

Concept: Vocabulary that names a phenomenon.

A resource whose capacity is tight enough that the planning system must monitor it, protect its sequence, and keep enough slack around it to prevent it from becoming the system constraint.

Also known as: capacity-constraint resource.

A capacity-constrained resource (CCR) is the resource a planner watches even when the plant’s official constraint is somewhere else. It has enough average capacity to keep up, but too little slack to ignore. One bad setup sequence, a product-mix shift, or a local-efficiency rule that fills its queue can make it the next thing that stops flow.

Context §

The CCR concept sits between Constraint and the production-control patterns that use it: Drum-Buffer-Rope, Simplified Drum-Buffer-Rope, Constraint Buffer, and Buffer Management. The distinction matters because the shop floor often has several resources that look stressed. Only one of them, or sometimes one interactive pair, is the system constraint. The others may still deserve active monitoring because their protective capacity is thin.

In full DBR, the drum may be the constraint or the CCR that protects the constraint’s flow. In S-DBR, the market is usually treated as the primary constraint, while the CCR is watched through planned load and Buffer Management rather than scheduled in detail. Those are different planning choices, but they share one diagnostic rule: don’t let “busy” become a synonym for “constraint.”

The TOCICO Dictionary defines a CCR as any resource likely to compromise organizational throughput if its capacity is not carefully managed. The Goal introduces the idea through Stacey Potazenik’s discovery that the same six or seven non-bottleneck work centers kept creating holes in the buffers. Srikanth’s TOC Handbook chapter turns that observation into a production-control rule. Compare required load with available capacity, measure queues in hours of work, and treat the tight resource as a control point rather than as one more ordinary work center.

What It Is §

A CCR is a capacity-risk resource. It is not simply a resource with a long queue, and it is not automatically the system constraint. It is the resource whose remaining slack is small enough that ordinary variation can consume it. When that happens, the resource stops being a managed risk and starts behaving like a constraint.

Three parts of the definition carry the weight.

First, the resource is capacity-limited relative to demand over a specific horizon. In Srikanth’s worked DBR example, resource R1 requires 2,260 minutes of processing time in a 2,400-minute week before setups, maintenance, and disruption are considered. That 94 percent processing load leaves only 6 percent for everything that isn’t producing the week’s required units. It may be enough if the schedule is disciplined. It won’t be enough if local policies create avoidable setups or pull work into the wrong sequence.

Second, the resource affects system throughput through dependency. A CCR upstream of the constraint can starve it. A CCR downstream of the constraint can block shipment. A CCR used several times in a re-entrant route can distort the whole planned load even when no single visit looks dangerous. The question is not whether the resource is important in isolation; the question is whether its delay reaches the system’s protected flow.

Third, the resource is managed through capacity awareness, not through local utilization. A CCR driven to 100 percent utilization on a departmental efficiency measure loses the protective capacity that made it manageable. The TOC move is almost the opposite. Monitor the load, protect the right sequence when sequence matters, let Buffer Management set priorities at execution time, and add capacity only when repeated readings show that exploitation and subordination are no longer enough.

How It Is Measured or Recognized §

Start with load against available capacity. Count the work that must pass through the candidate resource inside the planning horizon, convert it to hours or minutes of resource time, and compare that load with the resource’s usable capacity. A resource loaded to 94 percent before setups is a CCR candidate. A resource loaded to 45 percent may still be noisy, politically visible, or locally important, but it isn’t a CCR unless the load calculation is wrong or the route dependency is being missed.

Then read the queue in hours, not pieces. A queue of 40 small parts can be less dangerous than a queue of three jobs that each need six hours on the same machine. Srikanth’s V-plant discussion uses the largest in-process queue measured in hours of work for that resource as the practical signal. The measurement keeps the planner from being fooled by visual inventory.

Buffer Management supplies the execution signal. Repeated red-zone events that trace to the same resource, recurring holes in the constraint or shipping buffer, or due-date misses after that resource’s disruptions all point to CCR risk. Stacey’s observation in The Goal is exactly this pattern: the same work centers weren’t bottlenecks, but their sequencing became important enough that material management had to keep finding and prioritizing the work held there.

In S-DBR, planned load is the recognition surface. The planner doesn’t publish a detailed CCR schedule, but still maintains a running total of accepted orders’ required CCR time. If a new order pushes the planned load past the safe-date boundary, the due date moves or capacity must be added. The CCR is being managed precisely because it isn’t allowed to surprise the market commitment later.

Why It Matters §

The CCR concept gives the practitioner a third bin. Without it, every tight resource is either “the constraint” or “not the constraint.” That binary is too crude for real plants. A heavily loaded resource that is not yet the system constraint can still destroy due-date performance if the plant treats it like an ordinary non-constraint.

The concept also prevents an expensive misread of the Five Focusing Steps. If a team labels the CCR as the system constraint, it may elevate the wrong resource and leave the true constraint untouched. If it ignores the CCR because “only the constraint matters,” it can let the CCR become the new constraint through avoidable sequencing, setup, or release-policy errors. The disciplined reading is narrower: exploit and subordinate around the system constraint, and monitor CCRs closely enough that they don’t become interactive constraints.

This is why CCR language appears throughout DBR and S-DBR. Full DBR may schedule the CCR as the drum when an internal capacity limit controls the flow. S-DBR may refuse detailed CCR scheduling while still monitoring planned load against it. Constraint buffers, shipping buffers, and Buffer Management all depend on knowing which resource deserves protection and which resources should simply follow the release rule.

For certification-track readers, the distinction is also a vocabulary test. “Constraint,” “bottleneck,” “drum resource,” and “CCR” are neighboring terms, not synonyms. A practitioner who can sort them correctly can explain why a busy machine is watched but not elevated. The same practitioner can explain why another resource is subordinated to it, and why a third resource is allowed to sit idle without apology.

Common Misunderstanding §

“A CCR is the same as the constraint.” Sometimes the CCR is the active internal resource the drum schedules, but the terms do different work. Constraint names the factor that currently limits the system relative to its goal. CCR names a capacity-tight resource that can compromise throughput if it isn’t managed carefully. In market-constrained S-DBR, the market can be primary while the CCR remains secondary and monitored.

“The busiest resource is the CCR.” It may be. It may also be busy because batching policies, end-of-month behavior, poor release discipline, or local-utilization measures have filled it with the wrong work. The load must be read in hours of required work against usable capacity, and the diagnosis must be checked against buffer behavior.

“Every CCR needs a detailed schedule.” Full DBR schedules the drum when sequence and capacity require it. S-DBR usually monitors planned load and lets Buffer Management set execution priority. The dividing line is practical: sequence-dependent setups, tight internal constraints, and complicated routing make detailed scheduling more valuable; stable flow and market-driven commitments usually make planned-load monitoring enough.

“The CCR should run at 100 percent.” That is the Efficiency Trap in TOC vocabulary. A CCR needs high productive use, but it also needs enough protective capacity to absorb normal variation, urgent red orders, and short-term demand changes. Driving it to full local utilization can make the department’s report look better while making the system less reliable.

“Once named, the CCR stays fixed.” Product mix, demand, routing, downtime, staffing, and setup policy can all move CCR risk. A mature implementation expects the CCR reading to change and uses Buffer Management, planned load, and the Five Focusing Steps to notice the change before it becomes a missed shipment.

Related Articles §

Sources §