Planning is a hierarchy, not a single decision
Ask a logistics manager "what is your supply chain plan?" and the honest answer is that there is no single plan. There is a stack of plans, made by different people, on different cycles, at different levels of detail, each one operating inside the boundaries set by the plan above it. A network-design decision made once every few years sets the physical shape the business has to work within for the next several years. A monthly production and procurement plan sets aggregate volumes the business has to work within for the next few months. A daily schedule and an individual order confirmation operate inside whatever room those higher-level plans left them.
This is the single most useful mental model for understanding how the rest of this Knowledge Base's planning-related articles fit together, because most of them are not competing descriptions of "how to plan a supply chain" — they are descriptions of different levels of the same hierarchy, each solving a genuinely different problem with a genuinely different time horizon, data granularity and owner. Once you can place an article correctly on this map, the rest of the site's planning content stops looking like a list of disconnected topics and starts looking like one coherent system.
The three horizons
Nearly every planning framework in supply chain management — however it labels the layers — separates decisions into three broad horizons, distinguished by how far ahead they look and how much detail they carry.
| Horizon | Typical timeframe | What it decides | Where it lives on this site |
|---|---|---|---|
| Strategic | Multi-year | Number, location and role of facilities — the physical shape of the network | Supply Chain Network Design |
| Tactical | Rolling months | Aggregate volumes, workforce and capacity commitments ahead of firm orders | Master Planning, fed by Demand Planning |
| Operational | Days to weeks | Specific, executable actions — what runs on which line, what to order when, what to move where, what to promise whom | Production Planning & Scheduling, MRP, Transport Planning, ATP |
At the strategic end, network design decides where distribution centres, plants and cross-docks sit, which markets each facility serves, and roughly what capacity each one needs — a decision horizon measured in years because moving a warehouse or opening a plant is slow and expensive to reverse. In the middle, master planning takes that fixed network as a given and decides, on a rolling monthly cycle, how much aggregate volume to produce, procure and move across it — using the output of demand planning as its input, because you cannot commit capacity against demand you have not first estimated. At the operational end, several distinct plans turn that aggregate commitment into specific, executable detail on a short cycle: production planning and scheduling decides what actually runs on which line on which day; MRP decides exactly when each component must be ordered or released so it arrives just in time to feed that schedule; transport planning decides how the resulting goods actually move; and available-to-promise decides, order by order, whether and when a specific customer's specific request can be confirmed against everything already committed.
Why not just plan everything, in full detail, right now?
A reasonable first question is why any of this layering is necessary at all. Why not simply build one master plan, at full SKU-and-customer-and-day detail, covering the next three years, and be done with it? Two separate problems rule that out, and it is worth being precise about which is which, because they call for different responses.
The first is a computational problem. A business with even a modest range of products, sold to a meaningful number of customers, through a handful of facilities, generates an enormous number of individual source/make/deliver decisions once you multiply SKUs by customers by days by locations. Planning all of that in full detail, simultaneously, for a multi-year horizon is not a matter of "it would take a bit longer" — the combinations genuinely explode beyond what any planning process, human or algorithmic, can usefully hold and solve at once. This is precisely why optimisation approaches that work well at one level of detail become impractical at another, and why real planning systems deliberately decompose the problem instead of attacking it whole.
The second, more fundamental problem is that the detail simply does not exist yet — and no amount of forecasting effort will manufacture it reliably. Nobody can tell you which exact SKU a specific customer will order on a specific Tuesday three years from now, because that decision has not been made by anyone yet, including the customer. A forecast at that level of granularity would not be a weak estimate; it would be closer to a guess dressed up as a number. What genuinely can be estimated with useful accuracy at a long horizon is a much coarser quantity — total demand for a product family, or a market, or a region, over a month or a quarter — because the individual noise of thousands of unmade customer decisions tends to average out at that level of aggregation even though no single one of them is predictable. This is the same underlying statistical logic that makes safety stock pooled across a wider base more efficient than the same protection held item-by-item, and it is why forecasting at the wrong level of aggregation is one of the classic causes of distorted, amplified demand signals moving up a chain.
The planning hierarchy is the practical answer to both problems at once. Each level deliberately works at the coarsest level of detail that is still useful for the specific decisions it needs to make — no finer, because finer detail at that horizon would be either infeasible to compute or fictional to forecast — and then hands a narrower, more certain, more detailed problem down to the level below it. Network design decides shape, not daily volumes. Master planning decides aggregate monthly volumes, not which SKU ships to which customer on which truck. Scheduling and ATP decide exactly that, but only a few weeks or days out, once the individual customer orders that made the earlier aggregate forecast unnecessary have actually arrived.
The planning grid: horizons crossed with SCOR's process categories
A second, complementary way to organise the same set of decisions is to cross the three time horizons against the classic process categories familiar from the SCOR framework — Source (procuring inputs), Make (producing or assembling) and Deliver (moving and distributing finished goods to customers). Laid out as a grid, with horizon on one axis and Source/Make/Deliver on the other, nearly every cell in that grid corresponds to a specific, named planning task — and, not coincidentally, to one of the other execution-pillar concept articles already on this site.
| Horizon | Source | Make | Deliver |
|---|---|---|---|
| Strategic | Network design — where facilities, suppliers and distribution points sit relative to one another | ||
| Tactical | Master planning — aggregate monthly procurement, production and distribution volumes, driven by the demand forecast | ||
| Operational | MRP — exact order/release timing per component | Detailed scheduling — what runs on which line, in which sequence | Transport planning plus ATP — moving goods and confirming individual orders |
Reading this grid, it becomes clear that most of the site's execution-pillar concept articles are not a random assortment of topics — they are the specific cells of one underlying map, each one written up in the depth it deserves on its own page precisely because each cell is a genuinely distinct planning problem, with its own methods, data and typical owner in the organisation, even though every cell is connected to its neighbours above, below and beside it.
Coordination runs both ways: top-down constraints, bottom-up feasibility
It is tempting to picture this hierarchy as a one-way waterfall — strategy flows down to tactics, tactics flow down to operations, end of story. In a well-run planning process it is not one-way; coordination has to run in both directions, and a hierarchy that only works top-down is not actually functioning as a hierarchy, it is just a chain of instructions that eventually breaks.
Top-down is the more intuitive direction: a higher level sets a constraint or a target that the level below must plan within. Master planning, for example, commits to an aggregate monthly production volume for a product family, based on the demand forecast and available capacity at that level of aggregation. Detailed scheduling then has to fit that committed volume into specific days, specific shifts and a specific sequence of jobs on the shop floor — it does not get to simply re-decide the monthly total; that decision has already been made a level up, and its job is to execute inside that envelope as efficiently as possible.
Bottom-up is the direction that gets neglected far more often, and it matters just as much. A lower level sometimes discovers, once it gets down to real operational detail, that the higher level's plan genuinely cannot be executed as given. When that happens, the mismatch has to be surfaced and fed back up to trigger a re-plan — it must not simply be silently absorbed, worked around, or hidden by whoever discovered it, because silent absorption at the operational level is exactly how a business ends up missing commitments that, on paper, "the plan" said were achievable.
A concrete worked example makes this vivid. Suppose master planning commits to producing 40,000 units of a product family next month, based on a straightforward capacity calculation: available machine-hours divided by average run-rate per unit. Detailed scheduling then sits down to actually sequence real jobs, real SKUs and real changeover requirements onto real machines for that month — and discovers that, because several different SKUs within that family have to run on the same line and each changeover between them eats several hours of downtime, the achievable output once real changeover time is subtracted is closer to 34,000 units, not 40,000. That is not a scheduling failure to be quietly worked around by cutting corners on maintenance or overtime — it is a genuine capacity infeasibility that master planning's coarser, changeover-blind calculation could not see. The correct response is for that 34,000-unit ceiling to flow back up as feedback, prompting master planning to either accept the lower volume, reduce the number of distinct SKUs scheduled in that period to cut changeovers, add a shift, or adjust the sales-facing commitment before customers are promised goods that cannot actually be produced. This same interplay between an aggregate commitment and the true minute-by-minute capacity constraint is the everyday subject matter of Sales & Operations Planning, which exists in large part to be the forum where exactly this kind of top-down/bottom-up reconciliation happens on a recurring monthly cycle, rather than being discovered as a crisis after the fact.
Where this leaves the individual customer order
The whole hierarchy exists, ultimately, to answer one recurring operational question reliably: can we promise this specific customer this specific quantity by this specific date? Available-to-promise is the mechanism that answers that question at the moment an order actually arrives, by checking the request against everything the levels above it have already committed — the aggregate volumes master planning approved, the detailed schedule that translated those volumes into specific production dates, and the inventory and transport capacity available to fulfil and move the order once it exists. A fast, trustworthy ATP answer is only possible because so much of the harder, coarser-grained planning work has already been done well in advance, at the levels above, precisely so that the operational level does not have to re-solve the whole supply chain from scratch every time a customer places an order.
This is also why a business that treats order promising as a purely local, operational function — disconnected from what master planning actually committed to, or from what the network was designed to support — tends to either over-promise (confirming orders the supply chain genuinely cannot fulfil) or under-promise (sitting on real available capacity because nobody at the operational level can see it). Both failure modes are, at root, hierarchy failures: a break in the top-down/bottom-up link this article has been describing, not a flaw in the ATP logic itself.
A map for exploring the rest of this Knowledge Base
If you have read several of the site's other planning-related concept articles and wondered how they relate to one another, the short answer is that this article is the relationship — each of the following pages is one level, or one cell, of the same hierarchy described above, written up in its own depth because each one is a genuinely distinct planning discipline in its own right:
- Supply Chain Network Design — the strategic, multi-year decision about where facilities sit
- Demand Planning & Forecasting Techniques — the estimate that feeds every level below it
- Master Planning — the tactical, rolling-month aggregate volume and capacity commitment
- Sales & Operations Planning (S&OP) — the recurring process that reconciles top-down targets with bottom-up feasibility
- Production Planning & Scheduling — the operational Make-side detail
- Material Requirements Planning (MRP) — the operational Source-side detail
- Transport Planning — the operational Deliver-side detail
- Available-to-Promise (ATP) — where an individual customer order meets everything committed above it
- The SCOR Model — the Source/Make/Deliver process language used to build the grid above
Frequently asked questions
Is the planning hierarchy the same thing as S&OP?
No, they are related but distinct. The planning hierarchy is the overall structure of decisions at different horizons — strategic, tactical, operational. S&OP is a specific recurring process, usually monthly, that operates at the tactical level and exists specifically to reconcile the targets that level sets with the feasibility feedback coming up from operations, keeping the hierarchy's top-down and bottom-up flows genuinely connected rather than drifting apart.
Why can't a smaller business skip the tactical level and go straight from strategy to daily scheduling?
A very small operation can sometimes get away with an informal, lightweight version of the tactical level rather than a full formal process, but it rarely disappears entirely. Without some mid-term aggregate commitment step, capacity and procurement decisions end up being made reactively, order by order, which tends to produce exactly the volatility and last-minute scrambling that a tactical plan exists to prevent — it just happens implicitly and badly instead of explicitly and well.
What happens if a lower level's feasibility problem is not fed back up?
The higher level continues operating on a plan that is no longer accurate, and commitments made against it — sales promises, customer delivery dates, downstream procurement — are quietly built on a foundation that will not hold. The mismatch does not disappear; it resurfaces later, usually as a missed delivery or an unplanned expedite, at a point where it is far more expensive and disruptive to fix than it would have been if the feedback loop had worked when the problem was first discovered.
Does every business need all three horizons formally documented?
The underlying decisions exist in every business that plans ahead at all, whether or not they are written down and labelled as "strategic," "tactical" and "operational." Larger, more complex operations benefit from making the hierarchy explicit — with named processes, owners and cycles for each level — because informal versions tend to blur the boundaries and lose exactly the top-down/bottom-up coordination this article describes.
How does the SCOR model relate to the planning hierarchy?
SCOR supplies the process-category axis — Source, Make, Deliver, and so on — used to build the planning grid in this article. The planning hierarchy supplies the other axis: the time-horizon dimension that SCOR itself does not fully specify. Crossing the two produces the grid of specific planning tasks this article maps out.