In short: Material requirements planning assumes infinite capacity, so it will schedule 14,000 hours into a week holding 12,000 and carry on without comment. A constrained solve starts from the same requirements, adds resource limits, and either produces a feasible schedule or states clearly which requirement it could not meet. Rough-cut and detailed models should share one constraint set, because two different models of the same plant is a common and expensive failure. A plant running at sixty per cent utilisation does not have a capacity problem, and constrained planning earns its keep only where sequencing decisions carry consequences.
Material requirements planning has a design assumption that everybody knows and almost nobody accounts for. It assumes infinite capacity.
Explode the bill of materials, offset by lead times, generate planned orders. At no point does the calculation ask whether the plant can run what it just scheduled. If week 39 needs 14,000 hours on a line that has 12,000 available, MRP produces the plan anyway and moves on.
What happens next is familiar in every manufacturing business running this way. A scheduler opens the plan on Monday, finds three weeks that do not fit, and spends the day resequencing in a spreadsheet. The published plan and the executed plan diverge immediately, and by Thursday nobody upstream knows what is actually going to be made.
The plan was correct in its arithmetic and answered a question that omitted the constraint.
What a constrained solve is doing differently
A finite capacity plan starts from the same requirements and adds resource limits, then finds a schedule that satisfies both or tells you clearly which requirement it could not meet.
The core of it is lot sizing under capacity. Given demand per period, a setup cost, a holding cost and a capacity limit per period, decide how much to make in each period. Unconstrained, this is the classic dynamic lot sizing problem, solved exactly by Wagner and Whitin in Management Science in 1958 with a dynamic program that runs in polynomial time. Add a capacity limit and the problem becomes NP-hard, which is why practical implementations use heuristics rather than exact optimisation.
The usual construction runs in three stages. Start with lot-for-lot, making exactly what is needed when it is needed. Combine adjacent lots where doing so saves more in setup cost than it adds in holding cost, which is the Silver-Meal rule from 1973 and its relatives. Then repair the capacity violations by moving production earlier or later, choosing the moves that cost least in marginal holding.
Build-ahead is usually cheaper than deferral, because holding cost for a few weeks is generally smaller than the cost of missing a customer date. The repair step is where the interesting trade-offs live and where a good implementation earns its keep, since there are usually several ways to fix an overload and they have quite different costs.
Below the weekly planning level sits the sequencing problem, which is different in kind. Given a set of jobs each requiring operations on specific machines in a specific order, find a sequence that minimises makespan or lateness. This is job shop scheduling and it is genuinely hard. The practical approach constructs an active schedule using dispatching rules, shortest processing time, earliest due date, critical ratio, and then improves it with a local search that swaps adjacent operations on the critical path. That construction goes back to Giffler and Thompson in 1960 and the improvement heuristics to the 1990s, and the combination is what sits underneath most commercial schedulers.
Sequence-dependent setup times matter here more than most people expect. If changing from product A to product B costs forty minutes and B to A costs ten, the sequence is a real cost driver and a scheduler that ignores it will produce a plan that loses hours a week to avoidable changeovers.
The size of it is easy to check. A line running eight products a week with an average changeover of 35 minutes gives up about four and a half hours to setup. Reorder those eight with a sequence-aware rule, take a third off the setup total, and you get back an hour and a half a week, or around 80 hours a year. On a line whose usable week is closer to 50 hours than to 80, that is a week and a half of capacity found for nothing. The prerequisite is a changeover matrix rather than a single average setup time in the routing, and most plants have the average. Building the matrix is a fortnight of watching the line with a stopwatch, and it is the input that decides whether sequencing is worth optimising at all.
Rough-cut and detailed should share a constraint set
A common failure is having two different models of the same plant.
The S&OP cycle runs a rough-cut capacity check at a monthly or family level to sanity check the plan. The factory runs a detailed schedule at a weekly or daily level with real routings. These are usually built by different people in different tools with different data, and they disagree.
When they disagree, the monthly plan is signed off as feasible and the weekly detail proves it is not, which is discovered too late to change anything commercial. The organisation learns that the S&OP number is aspirational and stops treating it as a commitment, and once that happens the cycle has lost its point.
The fix is to run both from one constraint set at different resolutions. Same capacities, same calendars, same routings, aggregated for the rough-cut and expanded for the detail. Then a rough-cut pass that says feasible means something, and any divergence is a data problem in one place rather than a permanent disagreement between two models.
The check that tells you which of the two you have is quick. Take last quarter's signed-off rough-cut plan and the detailed schedules that were actually built against it, aggregate the detailed hours up to the rough-cut's periods and resource groups, and compare them line by line. A consistent gap in one direction means the two models disagree about capacity, which is one correction in one place. A gap that changes sign from month to month means they disagree about the routings, which is harder, because no single adjustment fixes it. Most businesses have never run this comparison, and the reason the S&OP number drifts loose from execution is usually sitting inside it.
Making the trade-off legible
The most useful output of a constrained solve is the priced alternatives at each violation.
A week that overloads a line by fourteen percent has several fixes. A weekend shift at overtime rates. Building two weeks early and carrying the stock. Splitting the order to a co-packer at a higher unit cost and a later delivery. Moving a lower-priority order out and accepting the service consequence. Each of these has a cost that can be computed, and the right one depends on numbers rather than on habit.
Put numbers on that week and the ranking stops being a matter of taste.
The line is short 2,000 hours against a requirement of 14,000 and a capacity of 12,000. It runs at 60 units an hour, so 2,000 hours is 120,000 units, and the product costs 4.00 to make.
A weekend shift at an 18 per hour premium over standard covers the 2,000 hours for 36,000, and it depends on three crews agreeing to work.
Building two weeks early carries 480,000 of stock for two weeks. At a 20% annual carrying rate, 3,692.
A co-packer takes the 120,000 units at a premium of 0.35 a unit, or 42,000, and delivers a week later than the plant would have.
Moving out a lower-priority order for 120,000 units carrying 1.10 a unit of contribution, delayed by two weeks with an estimated 15% chance the customer walks, has an expected cost of 19,800.
Build-ahead wins by an order of magnitude, and in most plants the reflex is overtime. The sensitivity is worth having too. Build-ahead cost scales linearly with how early you build, so eight weeks ahead is 14,769 and it stays cheapest, and the constraint that eventually binds on it is warehouse space or shelf life rather than money.
When those options appear with their costs attached, the decision takes minutes and can be delegated. When they do not, it goes to whoever has been there longest and they choose the option they chose last time, which is often the expensive one because expediting is the reflex.
The other output worth insisting on is a constraint explanation. When a line lands late, the plan should say which specific machine, material or crew caused it. Without that, a planner faced with a late order has to reverse engineer the solve, and in practice they will simply override it, which puts you back where you started with an infeasible plan and no record of why.
The format is worth specifying rather than leaving to the implementation. For a late line, the useful record names the resource that saturated, the period in which it saturated, the competing orders that consumed it, and the earliest date the line could have been met had that resource been free. Four fields. A planner holding those four can decide in under a minute whether to argue with the plan or accept it.
Data that has to be right
Three inputs cause most of the failures, and all three are usually wrong in the same direction.
Capacity is not a nameplate number. The usable capacity of a line is the theoretical rate multiplied by realised efficiency, minus planned maintenance, minus changeovers, minus the shifts you do not actually staff. Businesses routinely load plans against the nameplate and then wonder why the plan never executes. Measure actual output per available hour over a year and use that.
Routings drift. The standard time in the routing table was accurate when it was set. Products get reformulated, lines get modified, and nobody updates the master data because nothing breaks immediately. Compare standard times against actuals for a sample and you will usually find a systematic gap.
The measurement is a scatter of standard time against actual run time per order over a quarter, with a 45 degree line drawn across it. Points scattered around the line mean the routings are noisy and unbiased, which a planning system can absorb. Points sitting consistently above it mean the standards are optimistic by something close to a fixed factor, and the honest correction is to rescale the routings rather than to carry the gap as a permanent overload the scheduler works off by hand every week.
Calendars are the boring one that breaks everything. Shift patterns, holidays, planned shutdowns, and the fact that a maintenance window is not capacity. Most infeasible plans I have seen traced back to a calendar that had not been updated rather than to anything in the optimisation.
Where finite capacity planning is the wrong answer
If your plant is running at sixty percent utilisation, capacity is not your constraint and the effort belongs elsewhere. Constrained planning earns its keep when utilisation is high enough that sequencing decisions have consequences, and the threshold where that starts to bite is usually somewhere above eighty percent, depending on variability.
If the real constraint is material rather than machine time, a capacity solve will produce feasible-looking plans that fail on supply. The constraint set needs to include material availability, or the exercise is answering the wrong question with impressive precision.
There is also a stability consideration that gets underweighted. A solver that finds a slightly better schedule every time it runs will produce a different plan each week, and a plan that changes constantly is worse operationally than a marginally suboptimal plan that stays still. Freeze windows and change penalties belong in the correct problem statement rather than being a compromise against it, and a system without them will be switched off by the people who have to execute it.
Start by measuring realised capacity against what your planning system thinks it has. That comparison alone frequently explains the gap between the plan that gets published and the one that gets built.