Capacity Planning: Theoretical vs. Effective Capacity, Horizons & Why Most Plans Fail

What is capacity planning?

Capacity planning is the process of matching available production capacity — machines, labour, tools, materials — against demand over a defined horizon, so that orders can be committed to with dates that are actually achievable. In textbook form it is an optimisation problem. In a real plant it is a data problem: the plan is only as good as the capacity number that feeds it, and the capacity number that most ERP systems use is almost always too optimistic.

Having spent the last decade building the data pipeline between shopfloor machines and cloud systems, I see the same pattern at most customers before SYMESTIC goes live: the ERP capacity plan says the plant can produce X units per week, the actual output is 0.7–0.8 × X, and nobody is quite sure why the number is wrong. The planners blame the shopfloor; the shopfloor blames the plan; the truth is that the capacity figure in the planning system has never been reconciled against what the machines actually do.

This article looks at capacity planning from the angle that most glossaries skip: not the classical rough-cut vs. detailed taxonomy (though that is covered too), but the feedback architecture that separates a capacity plan that works from one that produces politely ignored Gantt charts. The lead time article covers the flow-time side of the same problem; this one focuses on the capacity side.

Theoretical vs. effective capacity — where most plans lose touch with reality

Every capacity plan is built on an assumption about how much a machine can produce in a given time window. That assumption is where accuracy lives or dies. Three capacity numbers matter, and most plants only explicitly track the first.

Most ERP planning modules are configured once, using a number somewhere between design and effective capacity, and then left alone. As the plant evolves — new products, new cycle times, new bottlenecks, deteriorating equipment — the gap between the configured number and the demonstrated number drifts. After two or three years the planning number has become a historical artefact. This is not a criticism of ERP; it is a description of what happens when no feedback loop exists to update the number. The OEE value on the shopfloor is the missing variable in that loop.

The three horizons of capacity planning

Capacity planning is not one activity — it is three, each with a different time horizon, a different granularity, and a different owner. Confusing them is one of the more common sources of dysfunctional planning.

Each horizon has its own failure mode. Strategic plans fail on optimism about demand. Rough-cut plans fail on stale productivity assumptions. Detailed schedules fail on the gap between planned and actual cycle time, setup time and downtime. The remedies are different for each — and the data each horizon needs is different. Strategic planning can tolerate monthly aggregates; detailed scheduling cannot tolerate anything above hourly resolution.

Finite vs. infinite capacity planning — the honest comparison

Classical MRP runs at infinite capacity: it assumes resources are available whenever the schedule says they should be. APS systems and modern MES scheduling run at finite capacity: they respect the actual availability of each resource. Neither is categorically better; each fails differently.

The hybrid approach is what most mature plants converge on, and it is architecturally the most interesting: rough-cut plans run at infinite capacity over months, detailed schedules run at finite capacity over days, and the feedback loop from execution (MES) to planning (ERP/APS) keeps the two consistent. Without that loop, the two layers drift apart — the rough-cut says "yes, we can do it," the detailed schedule says "no, we can't," and the planner becomes a negotiator rather than a planner.

The data problem: why most capacity plans are fiction

Over the last ten years I have connected around 15,000 machines to cloud systems. The single most common finding in the first month of live data is that the capacity assumptions in the planning system do not match what the machines are actually doing. Six reasons, in rough order of frequency:

Stack those errors and a plant can easily believe it has 30–50 % more capacity than it actually has. That is not a planning problem; it is a measurement problem. And it cannot be fixed with a better algorithm — only with better input data. The planning engine is not the weak link in most plants; the data feeding it is.

The feedback architecture — how MES, ERP and APS fit together

The technical answer to the data problem is straightforward but often poorly implemented. Four layers, four responsibilities, two feedback loops. The critical detail is that the loops must run at different frequencies — trying to push real-time data into the rough-cut plan creates noise; trying to update the detailed schedule weekly creates stale plans.

Loop 1 is fast: MES → APS, updated continuously, feeds real capacity into detailed scheduling. Loop 2 is slow: MES → ERP (weekly or monthly), updates the master capacity numbers used for rough-cut planning. The most common architectural mistake is collapsing both loops into one — either overwhelming the ERP with real-time noise, or starving the APS with weekly aggregates. Two loops, two cadences, two levels of aggregation.

Capacity planning failure modes — what to watch for

What an MES adds to capacity planning

The point is not that the MES becomes the planning system. The point is that the planning system, whatever it is, finally has reliable input data. The Meleghy rollout (6 months to 6 plants, bidirectional SAP integration with cycle mapping and schedule feedback) is a representative example: the capacity figures in SAP were reconciled against real machine cycles, and the planning quality improved as a direct consequence — not because the algorithm changed, but because the inputs finally matched reality.

FAQ

What is the difference between capacity planning and production scheduling?
Capacity planning asks "can we do it, and when?" — it compares aggregate demand against aggregate supply over a horizon. Production scheduling asks "in what order, on which machine, with which operator?" — it turns feasible capacity into an executable sequence. Capacity planning operates at weeks or months; scheduling operates at hours or minutes. They are related but not interchangeable, and a plant can be competent at one while being poor at the other. The common failure is to treat the ERP capacity plan as a schedule — it is not granular enough, and forcing it to act as one produces friction that both planners and operators learn to work around.

How does capacity planning relate to OEE?
OEE is the mathematical link between design capacity and effective capacity. Effective capacity equals design capacity multiplied by availability, performance and quality — which is exactly the OEE calculation. A plant that claims to plan at "85 % utilisation" without knowing its OEE is planning against an unknown. In practice, effective capacity for a line running at 60 % OEE is 60 % of design capacity — not 85 %, not 75 %, but 60 %. This is the reconciliation that most ERP systems never receive, and it is the single biggest reason capacity plans miss their numbers. Any serious capacity planning discussion starts with the real OEE of the bottleneck resources and works from there.

Is finite-capacity scheduling worth the complexity?
It depends on how variable the process is. For stable, high-volume, low-mix operations — classical series production with predictable cycle times — finite scheduling delivers modest gains over good infinite-capacity MRP with proper lead-time buffers. For high-mix, medium-volume operations with complex changeover matrices, shared bottleneck resources, and tight due dates, finite scheduling can deliver step-change improvements in on-time delivery and utilisation. The honest criterion is not "are we complex enough for APS?" but "can our current planning approach commit to dates we actually deliver?" If not, either the capacity data is wrong (fix that first) or the scheduling logic is wrong (finite scheduling may help). Skipping the data step and jumping straight to APS usually produces an expensive, finite-capacity plan that is wrong in a more sophisticated way.

How often should capacity master data be updated?
More often than most plants do it. The answer depends on how volatile the process is, but typical recommendations: cycle times re-baselined against measured data every 3–6 months; setup times every 3–6 months; OEE-based capacity factors every month. In practice, many plants review this data every 2–3 years, driven by an ERP project or an audit. That is far too infrequent for data that changes continuously on the shopfloor. The ideal architecture is an automated loop: MES measures, MES aggregates, MES writes back to ERP master data on a defined cadence — with human review, not fully automated overwrite. This closes the gap without creating new risks.

What is "capacity creep" and why does it matter?
Capacity creep is the gradual erosion of demonstrated capacity over time, driven by factors that individually are too small to notice: slightly slower cycle times as tools wear, slightly more frequent micro-stops as sensors drift, slightly longer changeovers as informal workarounds accumulate. Each of these might cost 0.5–2 % of capacity per year. Over three or four years, a plant can lose 5–10 % of its real throughput without any single event being the cause. Because it never shows up in a single monthly report — only in the accumulated gap between plan and actual — it is often explained away as "a bad quarter" or "a difficult product mix." The only defence is continuous measurement against a fixed baseline, which again is what an MES provides. Without that baseline, capacity creep is invisible until the plant can no longer hit its commitments.

Related: OEE · Lead Time · Cycle Time · Machine Downtime · SMED · Production Costs · Production Planning · MES

About the author

Mark Kobbert

CTO of SYMESTIC GmbH. Architect of the cloud-native MES platform since 2014. B.Sc. Business Informatics. Responsible for the microservice architecture on Microsoft Azure, IoT gateway integration and real-time data processing across 15,000+ connected machines in 18 countries. Writes about the technical layers behind a modern MES: cloud architecture, OPC UA, digital I/O gateways, ISA-95 integration and the IT/OT boundary. · LinkedIn