The scenario planning workflow everyone uses
Here is how scenario planning works in most planning tools. You have a baseline plan, say 5,000 SKUs across 13 weekly buckets. You want to model a scenario where a major customer reduces orders by 30% next quarter. You create a scenario, which the tool implements as a full copy of the baseline. You then edit the 150 SKU-week combinations that correspond to that customer's products, reducing the forecast by 30%. You run the scenario, see the supply and financial impact, and decide whether to act on it.
This works. It is also the wrong way to do it.
The problem is not the copy. The problem is what happens when the baseline changes. Two days after you built the scenario, the demand planner updates the baseline forecast for 800 SKUs based on new actuals. Some of those 800 SKUs overlap with your scenario. Your scenario is now stale. It was built against the old baseline, and the new baseline has different numbers for the overlapping SKUs. If you apply your scenario to the new baseline, you will get a different answer than the one you reviewed. If you do not apply it, your scenario is frozen in time and increasingly irrelevant.
Most tools handle this by telling you to rebuild the scenario. So you do. You copy the new baseline, re-apply your 150 SKU-week overrides, and re-run. This takes 20 minutes. You do it again next week when the baseline changes again. After three weeks, you stop doing scenarios because the maintenance cost exceeds the insight value.
This is why scenario planning fails in practice. Not because the concept is wrong, but because the implementation makes it unmaintainable.
The overlay approach
The fix is to stop copying the baseline. Instead, store the scenario as a set of sparse overrides on top of the baseline. The scenario is not a separate plan. It is a small set of "for SKU X in week Y, use value Z instead of the baseline value" instructions. When you run the scenario, the system takes the current baseline, applies your overrides, and computes the result.
The difference becomes obvious the moment the baseline changes. Your overrides are still valid. They are still "for SKU X in week Y, use value Z." The baseline value for SKU X in week Y may have changed, but your override replaces it regardless. You do not need to rebuild the scenario. You do not need to re-copy anything. The scenario automatically reflects the new baseline everywhere you did not override, and reflects your override everywhere you did.
This is how version control works in software engineering. A branch is not a copy of the entire codebase. It is a set of diffs against a base commit. When the base commit changes (someone merges a pull request), your branch does not become stale. It still applies your diffs on top of the new base. The same principle applies to planning versions.
What sparse overlays look like in practice
A scenario stored as sparse overrides is a small file. For a scenario that models a 30% demand reduction on one customer's products across one quarter, the override set is roughly 150 entries (SKUs times weeks). The baseline plan it sits on top of is 65,000 entries (5,000 SKUs times 13 weeks). The scenario is 0.2% of the data volume of the baseline.
This has three practical consequences.
Scenarios become cheap to create and maintain. You can maintain 20 scenarios simultaneously without storage or compute concerns. Each one is a small overlay. The baseline can update weekly and every scenario automatically reflects the update.
Scenarios become comparable. Because each scenario is a set of overrides against the same baseline, you can compare them side by side. Scenario A (30% customer reduction) and Scenario B (15% supplier lead time increase) can be run against the same baseline and their supply gap, inventory, and revenue impacts compared directly. With copy-based scenarios, the comparison is meaningless because each scenario was built against a different baseline snapshot.
Scenarios become promotable. When you decide to act on a scenario, you promote it to become the new consensus plan. With overlays, this means the overrides become the new baseline for the affected SKU-weeks. With copies, promotion means manually merging the scenario back into the baseline, which is error-prone and often skipped.
Why most tools do it the wrong way
The copy approach is easier to implement. A scenario is just a second plan table in the database. Every query that reads the baseline can read the scenario by swapping the table name. No overlay logic, no merge computation, no dependency tracking.
The overlay approach requires the system to compute the scenario on demand by merging the baseline with the override set. This is more work at query time. For a single scenario, the cost is negligible. For 20 scenarios compared simultaneously, the cost is real but manageable with modern compute. The engineering effort to build the overlay system is the real barrier. Most planning tools were architected with the copy model, and retrofitting overlays is a significant rewrite.
The tools that do scenarios correctly, and there are a few, tend to be newer architectures built on the overlay model from the start. They are not necessarily better at everything. But they are dramatically better at scenario planning, because they do not have the maintenance problem that kills scenario planning in every copy-based tool.
How to evaluate a tool's scenario capability
If you are evaluating planning tools and scenario planning matters to your business, ask three questions.
One. When I create a scenario, does the tool copy the entire baseline, or does it store only the differences? If copy, the tool has the maintenance problem. If differences, it uses the overlay model.
Two. When the baseline forecast updates, do my existing scenarios automatically reflect the update, or do I have to rebuild them? If automatically, overlays. If rebuild, copies.
Three. Can I compare multiple scenarios side by side against the same baseline, and are the comparisons valid? If yes, the tool supports overlay comparison. If the comparison requires exporting each scenario to a spreadsheet and reconciling manually, the tool does not support it.
Most vendors will answer "yes" to all three questions in the sales meeting. The third question is the one that separates genuine overlay support from copy-with-good-marketing. Ask for a live demo of comparing two scenarios against an updated baseline. If the vendor cannot do it in under two minutes, the tool does not have real overlay support.
The takeaway
Scenario planning fails in practice because most tools implement it as copy-and-edit, which is unmaintainable when the baseline changes weekly. The fix is sparse overlays, where a scenario is a small set of overrides applied on top of the current baseline, not a frozen snapshot of a past baseline.
If your planning tool copies the baseline to create scenarios, you will do scenarios for a month and then stop, because the maintenance cost will exceed the value. If your tool supports overlays, scenarios become a routine part of planning that adapts automatically as the baseline evolves. The difference is not a feature. It is an architecture.