Self-assessment answers from Module 5
One. The supply netting formula is: net supply requirement equals demand minus existing supply (current inventory plus open purchase orders plus scheduled production). The computation must be idempotent so that re-running netting after a demand update updates planned orders in place rather than duplicating them. Non-idempotent netting produces a growing mess of duplicate orders that must be manually reconciled.
Two. The three assumptions are: demand is normally distributed (fails for intermittent and lumpy demand), lead time is constant or its variability is measured (often not tracked in ERPs), and the service level definition is clear (cycle service level, fill rate, and ready rate give different safety stock targets for the same percentage input).
Three. The reorder point is computed as average demand during lead time plus safety stock. If the reorder point is not updated when safety stock changes, replenishment will be triggered at the wrong time. If safety stock increases (demand variability went up) and the reorder point is not updated, replenishment triggers too late and you stock out. If safety stock decreases and the reorder point is not updated, you carry excess inventory.
Four. Gap analysis compares the supply plan (inventory plus open orders plus planned production) against the demand plan, per SKU per period, and flags where supply is less than demand. The timing of gap identification matters because a gap found 8 weeks before it occurs can be closed by expediting, rescheduling, or substitution. A gap found 2 weeks before can only be closed by expensive emergency expedite or by accepting the stockout.
Five. The quality of the demand plan determines the quality of the entire downstream supply chain because every supply decision is derived from the demand number. Supply netting computes requirements from demand. Safety stock is calibrated to demand variability. Reorder points are based on demand during lead time. Gap analysis compares supply against demand. If the demand plan is wrong, every downstream calculation is wrong.
If you got all five, continue.
What this module covers
This module covers scenario planning: the practice of modeling what-if scenarios to understand their impact on supply, inventory, and revenue, without disrupting the baseline plan. The module covers why scenario planning fails in most tools, the overlay approach that fixes it, how to compare scenarios, and how to promote a scenario to become the new consensus.
Why scenario planning matters
The demand plan and supply plan represent the most likely future. But the most likely future is not the only future. A major customer may reduce orders. A supplier's lead time may extend. A competitor may enter the market. A promotion may overperform or underperform. Each of these is a scenario that changes the demand or supply picture, and the planning team needs to understand the impact before it happens.
Scenario planning is the process of modeling these alternatives. The output is not a different plan. It is an understanding of the range of possible outcomes and the supply implications of each, so that when the scenario materializes (or does not), the team can respond quickly because they have already thought it through.
The value of scenario planning is not in the scenarios that come true. It is in the scenarios that do not. If you model a 30% demand drop and it does not happen, you have wasted 20 minutes. If you model a 30% demand drop and it does happen, you have saved 3 days of reactive planning, because the playbook is already written.
Why scenario planning fails in most tools
Most planning tools implement scenario planning as copy-and-edit. You create a scenario by copying the entire baseline plan, then editing the copy. The scenario is a second, complete plan table in the database.
This approach works for a single scenario at a single point in time. It breaks the moment 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 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.
The standard response is to rebuild the scenario. Copy the new baseline, re-apply your overrides, 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 copy-and-edit implementation makes it unmaintainable when the baseline changes weekly.
The overlay approach
The fix is to stop copying the baseline. 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 when 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. 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 codebase. It is a set of diffs against a base commit. When the base changes, the branch does not become stale. It applies the same 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 modeling 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. 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% 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 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, promotion 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.
How to compare scenarios
Scenario comparison is where the overlay approach pays off. Because all scenarios sit on top of the same baseline, the comparison is apples to apples. The comparison should cover:
Supply gap impact. How many SKUs have a supply gap in each scenario, and what is the total gap magnitude? This tells you which scenario creates more supply risk.
Inventory impact. What is the projected inventory position at the end of the horizon for each scenario? This tells you which scenario leaves you overstocked or understocked.
Revenue impact. What is the projected revenue for each scenario, compared to the baseline? This tells you the financial stakes of each scenario.
Working capital impact. What is the projected inventory value for each scenario? This tells you the cash flow implications.
The comparison should be presented as a table, not a chart. Charts are good for trends but bad for precise comparison. A table with one row per scenario and columns for each impact metric is the clearest format.
How to promote a scenario
Promotion is the act of turning a scenario into the new consensus plan. This should not be done lightly, because the consensus plan is what the business executes against. The promotion process should have three steps.
First, review. The scenario is presented to the planning team for review. The overrides are visible, the impact is visible, and the team can question or modify specific overrides.
Second, approval. The scenario is approved through the same S&OP gates as a baseline change (Module 4). Demand review if the scenario changes demand. Supply review if it changes supply. Executive S&OP if the financial impact is material.
Third, merge. The approved scenario's overrides are merged into the baseline. The overrides become the new baseline values for the affected SKU-weeks. The scenario itself is archived for audit purposes.
The merge should be atomic. Either all overrides are applied or none are. A partial merge leaves the plan in an inconsistent state that is hard to diagnose and harder to fix.
When to do scenario planning
Scenario planning is not a daily activity. It is a response to specific signals. The most common triggers are:
A major customer signals a change in ordering pattern. Model the change to understand supply impact before it happens.
A supplier signals a lead time change. Model the impact on safety stock and reorder points.
A competitor action changes the demand landscape. Model the upside and downside scenarios.
A new product launch creates demand uncertainty. Model ramp scenarios (fast, medium, slow) to ensure supply can scale.
A financial review requires understanding the range of possible outcomes. Model best case, base case, and worst case for the board.
The rule is: if the question is "what happens if X changes by Y%," scenario planning is the answer. If the question is "what is our forecast for next month," that is the baseline, not a scenario.
What to do next
This module covered scenario planning. Module 7 covers AI agents and human-in-loop: how AI can assist with the planning cycle, and what the human's role is when it does. Module 8 covers audit, compliance, and the board pack.
Before moving to Module 7, do this exercise. Think of one scenario that would be valuable to model for your business. Write down: what changes (demand, supply, or lead time), which SKUs are affected, what the magnitude is, and what decision the scenario would inform. If you cannot answer all four, the scenario is not well-defined enough to model. If you can, you have a use case for the next time you evaluate a planning tool's scenario capability.
Self-assessment
One. Why does the copy-and-edit approach to scenario planning fail when the baseline changes weekly?
Two. What is a sparse overlay, and how does it solve the maintenance problem?
Three. What are the three practical consequences of storing scenarios as overlays instead of copies?
Four. What four metrics should scenario comparison cover?
Five. What are the three steps of scenario promotion, and why should the merge be atomic?
Answers are in Module 7's introduction.