Constraint-based planning builds a production plan around the real limits of machines, lines or materials, and commits only what the plant can deliver. Planners know the alternative well. A plan balances perfectly on Friday afternoon, then gets reshuffled by hand twice before Tuesday’s first shift. The numbers in it were all correct. The plan simply assumed capacity that was never there, at the one resource where it mattered most.
What Is Constraint-Based Planning?
Constraint-based planning schedules production against the real capacity of the limiting resource. Dates are committed inside that limit. Infinite-capacity planning, which many setups run by default, treats every resource as able to take any load the plan sends. Such a plan balances on a spreadsheet. Whether any single machine can deliver it goes unchecked.
Constraints come in three kinds here. Machines have a rated output per hour, and lines have an available calendar net of maintenance and changeovers. Materials bring a quantity on hand plus a date for the next lot. Any one of them can cap the plan.
Take a single 400-tonne press feeding three downstream operations, from welding through painting to assembly. The press can stamp 1,100 parts a shift. Downstream, welding can handle 1,400, painting 1,600 and assembly 1,500. Whatever the plan says, the plant ships at most 1,100 parts a shift, because that is all the press can feed. The press is the bottleneck. A feasible plan starts from its number and works outward.
Finite capacity planning is the general term for checking load against what a resource can do. The constraint-based version goes a step further, treating one resource as the pace-setter for everything around it.
What Does Your ERP Do With Capacity by Default?
Left at its standard settings, an ERP works back from each due date with fixed lead times and treats capacity as infinite. Capacity requirements planning then produces a load profile showing where a work centre is overloaded, and leaves the fix to a person. Nothing in that default asks whether the bottleneck can carry the week.
Finite scheduling modules do exist in the major ERP suites, and the logic is there to be switched on. In our implementation work, it is rarely configured, and the routing times and changeover data it needs are kept current even less often. Once that data goes stale, finite scheduling produces dates nobody believes. Planners drift back to the dispatch list.
So the document reaching the floor is usually a dispatch list, sorted by due date or by a priority flag. The press operator learns which job is most urgent. Whether the week’s jobs fit on the press at all never comes up.
Why Does an Infinite-Capacity Plan Fail Predictably?
An infinite-capacity plan is arithmetically consistent and physically unachievable at the same time. Failure comes where assumed capacity and real capacity separate, and that point is almost always the bottleneck. The first symptom is a growing expediting list with no single obvious cause.
Take one heat-treatment furnace that processes 6 batches a day. For one week, the plan loads it with 7 a day, because MRP released works orders on their planned start dates with no capacity check.
Day 1 ends with 1 batch waiting. Friday ends with 5 queued in front of the furnace. Five sets of machined, inspected parts now sit idle. Downstream, the grinding cell waits for parts that are stuck in the queue, so it looks underloaded while the furnace looks overloaded.
The following Monday, customer service starts calling. Three orders that depended on those 5 batches miss their ship dates. The expediting list grows, and each item on it looks like a separate problem. All of them trace back to one furnace planned at 117% of its real rate.
Basic queueing arithmetic backs this up. Under Little’s Law, average work in progress equals throughput times the average time a batch spends waiting and being processed. Hold the furnace at 6 batches a day while work keeps arriving, and the wait is the only term left to grow.
What Happens When Every Machine Is Loaded to Its Limit?
The opposite mistake causes similar damage from the other direction. Picture a detailed schedule where every work centre is booked right up to its calculated limit. No slack is left anywhere. One breakdown or one late delivery then ripples through the whole schedule, and planners re-plan every day.
Queueing theory explains it. John Kingman’s 1961 work on queues in heavy traffic underpins the standard result that waiting time climbs steeply as a resource nears full load. The usual approximation scales waiting with utilisation divided by spare capacity.
Put numbers on it. At 85% utilisation the ratio is about 5.7, while 95% gives 19. Same machine, same variability, and waits roughly 3.4 times longer for 10 points of extra loading. So a schedule that runs every machine at 95% on paper builds queues everywhere the moment anything varies. A 40-minute die change that runs to 90 minutes is enough. Jobs behind it move, the next work centre waits, and the plan for the following shift no longer matches the floor.
Pace comes from the bottleneck. The other machines exist to keep it fed, and they need some spare capacity to recover from variation. Loading a non-bottleneck to 100% only builds work in progress the bottleneck cannot use yet, while throughput stays where the constraint holds it. A simple guard costs almost nothing. Before material leaves the stores, set each line’s load for the week beside what the plan is about to send it. Material a line cannot use yet stays in the stores.
What Changes When the Plan Respects the Constraint?
Four things change when the plan is built around the constraint: feasibility, where the plan breaks, work in progress and delivery reliability. The table compares the two approaches on each, and the prose under it explains the difference on the floor.
| Dimension | Infinite-capacity plan | Constraint-based plan |
|---|---|---|
| Feasibility | Balanced on paper | Checked against the limiting resource before it commits |
| Where it breaks | At the bottleneck, discovered on the floor | Accounted for while the schedule is built |
| Work in progress | Grows as orders start on planned dates | Held near what the constraint can absorb |
| Delivery reliability | Unpredictable | Predictable within the constraint’s limit |
Feasibility
An infinite-capacity plan passes every check a spreadsheet can run. Totals add up and dates line up. A constraint-based plan adds one more test before publishing: can the bottleneck produce this load in this window? If the furnace can do 30 batches a week, a plan asking for 35 fails the test before anyone commits a date to a customer.
Where it breaks
Plans all break somewhere, and the difference is when you find out. An infinite-capacity plan breaks at the bottleneck, days later, on the floor. A constraint-based plan meets the same limit while the schedule is still being built, when moving an order costs a few minutes of planning time.
Work in progress
Orders started on planned start dates, whatever the bottleneck can absorb, pile up as work in progress. Recall the furnace, with 5 batches idle by Friday. A plan that respects the constraint starts work closer to the rate the bottleneck can process it.
Work in progress stays lower. Lead times stop stretching.
A consequence surprises supervisors. Under a constraint-based plan, some non-bottleneck machines will sit idle for part of the week. A welding cell that can do 1,400 parts a shift and is fed 1,100 runs at about 79%. That idle time is the slack that lets welding recover from a bad hour without starving the press. Filling it with extra work only adds parts the press cannot take.
Delivery reliability
Customers care about this row. A plan that promised capacity it never had produces dates that slip unpredictably. Built on the bottleneck’s real rate, the plan gives dates the plant can hit, within the limit that rate allows. An honest early answer on a date still beats a broken promise in week four.
Where Does Oritiq Fit in Constraint-Based Planning?
Oritiq is the decision layer above the ERP. Its constraint-based supply planning works from the real capacity of the constraint resources, meaning their machine hours, line availability and changeover time. Nothing is published until it passes a finite-capacity check, and a planner can still override the result where the floor needs it.
When demand runs past what the bottleneck can do, a planner can test an expedite or a resequence first and see which orders would move before anything changes. Within production and procurement execution, the constraint is sequenced to cut setups while customer priorities hold. Material release is simulated against each line’s load, which is the stores check described above. Customer dates come from capable-to-promise, so each one sits inside what the bottleneck can deliver.
FAQs on Constraint-Based Planning
1. What is constraint-based planning?
Planning production around the resource that limits output, starting from its real rate, such as 1,100 parts a shift on one press, and building the rest outward. Every date in the plan then sits inside what the floor can deliver, with the other machines loaded to keep that resource fed.
2. What is the difference between constraint-based planning and capacity planning?
Scope. Capacity planning checks load against capacity across every work centre and horizon, from yearly line decisions to weekly loading. The constraint-based approach is narrower. One resource that limits output is identified, and the schedule is built around its real rate, with the others treated as support.
3. What is an infinite-capacity plan, and why does it fail?
A plan that assumes every resource can absorb any load. On paper it balances, and on the floor it fails at the bottleneck. A furnace that can do 6 batches a day, loaded with 7, builds a queue of 5 by Friday, and the late deliveries follow a week later.
4. Can an ERP do finite capacity scheduling?
Yes, if configured. The major ERP suites offer finite scheduling modules. Out of the box, though, an ERP backward-schedules at infinite capacity, and the finite logic needs current routing times and changeover matrices before it gives dates anyone trusts. Without those, planners fall back to a 1-page dispatch list.
5. How is a bottleneck identified in constraint-based planning?
Compare each work centre’s real output rate with the load the plan puts on it, and the resource with the highest load relative to its rate is the bottleneck. On the floor, it is usually the machine with the longest queue in front of it and the most appearances on the expediting list.
6. Why is scheduling every machine to full capacity a problem?
Waiting time climbs steeply as a machine nears full load. Moving from 85% to 95% utilisation can make waits roughly 3.4 times longer. A schedule with no slack breaks on the first late delivery or long changeover, and the whole plan shifts with it.
7. How often should a constraint-based plan be updated?
Update it at each planning refresh, at whatever cadence the business plans to, so the schedule reflects what actually ran. Review the constraint itself whenever the product mix changes, since a new mix can move the bottleneck. A furnace capped at 6 batches a day this quarter may sit well below its limit next quarter.
What Should You Measure First?
Measure your bottleneck’s real output for the last four weeks, using production records. Leave the rated figure in the routing aside. Then set that number against what next week’s plan is asking for. If the plan asks for more, the gap will show up as late orders, whatever the dispatch list says.
Bring one week of your current schedule and the real output rate of its slowest work centre to a conversation about planning around it.
Book a demo with Oritiq built around your own bottleneck.