What Is the Critical Chain in Manufacturing Scheduling?

The critical chain is the longest sequence of dependent work through a plan once contention for shared resources is counted, not only the step-to-step precedence links inside a routing. Two operations with no routing relationship can still sit on the same chain if they both need the same machine, because one of them has to wait. The critical chain is the Theory of Constraints answer to the critical path, and on a real shop floor it is the honest number.

This entry defines the critical chain and shows how it behaves inside EDGEBIC by User Solutions. For the wider index of planning terms, see the manufacturing glossary, and for the philosophy it comes from, read what is the theory of constraints.

How it works

Start from what the critical path does. It traces the longest connected chain of must-follow steps through a routing and reports the earliest possible finish. It is a genuinely useful map of which delays are dangerous, but it carries a hidden assumption: that whenever a step is ready to run, a machine is free to run it. That assumption is infinite capacity, and it is false in every plant that shares equipment across jobs.

The critical chain removes the assumption. It asks two questions instead of one. First, what must follow what, which is the precedence structure the critical path already reads. Second, what else is competing for the same resource at the same hour, which the critical path never asks. Once contention is counted, the longest chain usually gets longer, and it often runs through pairs of operations that have no dependency link between them at all. They are joined not because one feeds the other but because they cannot both have the grinder on Tuesday.

That distinction changes where a planner should look. Under critical path logic you shorten the job by shortening a step on the path. Under critical chain logic you shorten the plan by relieving the resource the chain keeps returning to, which is the constraint. Adding speed anywhere else leaves the chain the same length.

The second half of the idea is what to do about variation. Critical chain practice does not pad each operation, because safety time buried inside individual estimates is invisible, gets spent early, and never accumulates into anything useful. Instead the safety is pulled out of the estimates and pooled into a small number of deliberately placed buffers that protect the chain as a whole. A few large buffers in the right places absorb far more variation than the same total hours scattered across every step.

A concrete example

Take the kitchen the book uses for this idea. A restaurant has one oven and every department shares it: the bread, the roasts, the gratins. Each dish has its own recipe with its own sequence of prep steps, and if you cost each recipe alone, every one of them fits comfortably in the service window.

Then dinner starts and none of them fit, because they all need the oven. The bread and the roast have no relationship in any recipe, yet one of them is waiting on the other. Trace the real longest sequence through the evening and it runs oven load to oven load, stitched together by contention rather than by any recipe. That is the critical chain: the single oven shared by all departments. The correct response is to give the oven a buffer, not every dish. Padding each recipe by ten minutes just makes the whole service later while the oven stays exactly as busy as it was.

How EDGEBIC uses it

EDGEBIC does not draw a labeled critical chain on the screen, and no post should tell you it does. What it does is more useful: it schedules on finite capacity, so the contention that defines the chain is placed as real time in the plan instead of being assumed away. Each work center gets available hours computed from its shift hours multiplied by its instances and its utilization percentage, minus holidays. Jobs then fill those hours one at a time. When two jobs both want the same bottleneck work center, the second one is booked into the next free capacity, and the waiting shows up on the Gantt as placed time. The dates you read already carry the chain's length.

The Theory of Constraints half is explicit. A work center can be flagged as the plant constraint through the Is_Bottleneck column of the work center import file, which is how that flag is set in the current release rather than on the work center edit dialog. Flagging it makes the constraint visible on the dashboards, and it is the prerequisite for anchor scheduling. To actually anchor a job you pin its bottleneck operation to a target date from the Workcenter Details tab using Set Anchor for Selected Jobs. Without an anchor date a job schedules plain forward even when a flagged bottleneck sits in its routing, so the flag alone is not the whole mechanism.

Once a job is anchored, the plan is built around the chain rather than around the job's release date. The anchor step is placed at its target time, the steps before it are scheduled backward so material arrives just in time, and the steps after it are scheduled forward from its completion. The pooled buffers go in around that split: a constraint buffer in front of the anchor, a feeding buffer on the step that feeds it directly, and a shipping buffer after it to protect the promise date. They are flat percentage sizings today, applied only when buffer calculation is enabled. Consumption based buffer health signals of the red, yellow, and green kind are a roadmap item, not something the current release reports.

For the operating rhythm this all serves, continue with what is drum buffer rope in manufacturing. For the precedence structure the chain is layered on top of, see what is a dependency graph in scheduling. And for the practical step of naming the constraint the chain runs through, read production bottleneck identification.