In short: Supply chain scenario planning only changes decisions when the financial consequence lands in the same session as the volume comparison. Most systems cannot manage that because a scenario is implemented as a full copy of the plan, which makes each one slow enough to schedule rather than run live. Financial measures have to be declared in the model and derived from the plan, so that margin and cash move when volume moves. The step that usually breaks is committing the winning scenario back into the operating plan, which by hand takes days and introduces errors.
Ask most planning teams whether they do scenario planning and the answer is yes. Ask what a scenario produces and the answer is usually a volume comparison, with the financial consequence worked out separately by someone in finance about a week later.
By then the decision has been made, and the finance number is documentation rather than input.
A scenario that is worth running has to reprice the whole plan at once: volume, revenue, margin, service and cash moving together, because those are the dimensions the decision trades between. Getting that is partly a modelling question and mostly an architectural one.
Why full-plan scenarios are usually slow
The reason most systems cannot do this in a meeting is that a scenario is implemented as a copy.
Duplicate the plan, apply the change, recalculate everything, compare. On a plan with millions of cells and derived measures across several dimensions, the copy is expensive in memory and the recalculation is expensive in time. Three scenarios become a batch job, and a batch job cannot be run while people are talking.
Two changes make the difference, and they are worth understanding because they determine what is possible rather than what is configured.
Store a scenario as an overlay rather than a copy. A scenario holds only the cells that differ from its parent. Reads walk the scenario, then its ancestors, then the base. Writes land in the leaf. The memory cost of a scenario becomes proportional to how much it changed rather than to the size of the plan, which means a scenario touching four hundred cells costs almost nothing regardless of how large the plan is.
Recompute only what the change touched. When a cell is edited, the cells that need recalculating are those downstream of it in the dependency graph of measures, and only for the coordinates affected. Everything else is unchanged and does not need to be looked at. Add a cutoff so that when a recomputed value equals its previous value within tolerance, propagation stops there rather than continuing to fan out.
The scale of the difference is worth working out, because it explains why this reads as a technical footnote and behaves as a hard constraint on the meeting.
Take a plan of 500 items across 60 locations, weekly for a year, carrying a dozen measures. That is 500 times 60 times 52 times 12, or a little under nineteen million cells. A copy-based scenario duplicates all nineteen million whether it changed four hundred cells or four hundred thousand, so three scenarios cost fifty-six million cells before anyone has computed anything. Overlay storage for the same three scenarios, each touching four hundred cells, costs twelve hundred cells and some index. The ratio is close to fifty thousand to one, and it is the reason one architecture can hold a dozen live scenarios in a session and the other has a governance process for creating them.
Recomputation runs the same way. An edit to four hundred base cells propagates to whatever depends on them: six derived measures at the same coordinates, then the aggregates up four levels of hierarchy. The affected set is on the order of ten thousand cells, against nineteen million in the plan. Recomputing what changed rather than everything is a factor of about two thousand, and the cutoff on unchanged values takes another slice off that, because most of the fan-out above a small edit resolves to the same number it held before.
Together these turn a scenario from a batch job into an interactive operation. That is the whole difference between scenario planning as a preparation activity and scenario planning as something that happens in the room.
The measures have to be declared in the model
The second requirement is that financial measures are derived from the plan rather than calculated alongside it.
Revenue is units times price. Margin is revenue minus units times cost. Those relationships should exist once, as declarations in the model, so that every scenario applies them automatically and nobody can produce a scenario where the margin was computed differently.
The failure mode when they are not declared is specific and common. The formulas live in a spreadsheet, or worse, in two spreadsheets maintained by different people, and two scenarios turn out to have used different price assumptions. The meeting then spends its time reconciling the scenarios rather than choosing between them.
There is a fast diagnostic for whether the declarations exist. Ask two people to build the same scenario independently from the same brief, then compare the margin line rather than the volume line. If the volumes match and the margins differ, the financial relationships are living outside the model and every scenario comparison you have run has been between two arithmetics as well as between two decisions.
There is an arithmetic detail underneath this that causes more trouble than it should. When a scenario adjusts an aggregate and the change is apportioned to lower levels, the parts have to sum to the rounded total exactly. Independent rounding of each part produces a drift, the drift shows up as a total that does not tie, and a total that does not tie destroys confidence in the whole model. The largest remainder method fixes it, and it needs to be in the apportionment everywhere rather than in some code paths. It is the same apportionment rule Alexander Hamilton proposed for allocating seats in the US House in 1792, which is a long-settled problem borrowed rather than a modelling trick, and the fact that it keeps getting reinvented badly in planning systems is a reasonable thing to raise with a vendor.
What makes a scenario set useful
Three scenarios chosen well are worth more than twelve chosen badly, and the choosing has a pattern.
One should be the current plan, unchanged. Without a base case in the same units on the same screen, the comparison is against a remembered number, and remembered numbers are wrong.
Each should isolate a decision rather than a forecast. A scenario asking what if demand is ten percent lower is a sensitivity, and it is useful for stress testing and does not tell anyone what to do. A scenario asking what if we shift eight percent of volume to the European pool is a decision, and the output is actionable.
They should differ on the dimension being traded. If all three scenarios improve margin and worsen service by similar amounts, they are the same scenario at different intensities. The set is informative when the options differ in kind: one protects service at a cost, one protects margin at a service cost, one changes the timing.
Once the engine is fast, the failure changes shape and the discipline has to change with it. Four drivers examined at three levels each is eighty-one combinations, and a system that can produce all eighty-one before lunch will be asked to. A room cannot compare eighty-one of anything, so what arrives at the review is eighty-one results and a slide showing the three somebody picked, which is a worse process than the slow one because the selection now happens off-camera. The discipline that holds is to vary one driver per scenario and to state which one, so that the difference between any two scenarios has a single cause the room can argue about.
Pierre Wack, writing about the Shell scenario work in Harvard Business Review in 1985, made the point that the value of the exercise lay in changing how decision makers understood the forces acting on the business, rather than in producing a more accurate view of what would happen. That holds precisely for a planning cube. A scenario that only produces a number has done the cheap half of the job. The half worth having is that somebody leaves the room understanding that margin in this business is more sensitive to mix than to volume, or that the constraint moves from the plant to the port above a certain level, and those are conclusions about structure that survive long after the particular numbers are stale.
Committing the winner
The step that most often breaks is the last one. A scenario wins in the review, and then somebody has to transfer it into the plan by hand, which takes days and introduces errors.
The scenario should be committable directly, promoting its overlay into the base plan, with the change recorded. Two properties matter for that to be trustworthy.
The diff has to be inspectable before commit: which cells change, by how much, and what the aggregate effect is. Committing something whose full footprint nobody has seen is how a scenario intended to adjust one region quietly changes a global assumption.
The concrete version of that failure is worth recognising, because it is common and it is slow to surface. Somebody builds a scenario by editing a national total, the system apportions the change down to region and item, and the apportionment writes over cells where a regional planner had entered a manual override the previous week. The scenario wins, gets committed, and the overrides are gone. The symptom arrives about seven days later as a planner saying their numbers changed and they did not change them, which is the least useful bug report in planning because by then several other things have also happened. The protection is a diff that separates cells the scenario set explicitly from cells it set by apportionment, and flags any apportioned cell that is overwriting a manual entry. Those two categories carry completely different risk and most diff views show them identically.
And it has to be reversible, with the previous version retained and restorable. Plans get committed and then contradicted by news two days later, and the ability to roll back is what makes people willing to commit at all.
What scenarios cannot do
A scenario computes the consequence of an assumption. It does not tell you whether the assumption is right, and the quality of the decision is bounded by the quality of the assumptions rather than by the sophistication of the model.
This matters because a fast scenario engine makes it very easy to generate a large number of precisely computed answers to poorly framed questions. The discipline that keeps it useful is naming the assumption behind each scenario, with an owner, and reviewing afterwards which assumptions held. Without that, the scenario capability becomes a way of producing more confident-looking numbers rather than better decisions.
There is also a limit on how far a full-plan reprice extends. Second-order effects that fall outside the model are not in the answer. A price scenario reprices volume and margin correctly and does not model a competitor's response, and a supply scenario reprices cost and service and does not model the customer relationship consequence of a late delivery. Those belong in the discussion as stated judgements rather than being assumed absent because the model did not mention them.
Start by timing how long it currently takes to produce three financially complete scenarios. If the answer is measured in days, the constraint is architectural and no amount of process redesign will bring the decision into the room.