A demand-planning project often starts with a request for a tool: replace spreadsheets, improve forecasts or automate consolidation. These are legitimate objectives. They do not yet explain which decisions the business should be able to make once the solution is live.
Our view is that this is a business planning question before it becomes a modelling exercise. The business process organises the decision; scoping defines how it should work; EPM provides a shared environment to compare options, approve a plan and track outcomes. Designing these separately risks delivering a model that calculates correctly while teams make their real decisions elsewhere.
Start with the decision the forecast must support
Consider a fictional example that we will follow throughout. A business is preparing a promotion for one product family. Sales expects demand for 12,000 units next month. Operations estimates it can deliver 11,000 with the resources available. Finance needs to assess the implications for revenue, costs and the budget.
The question is not which function has the “right number”. Expected demand, feasible supply and financial targets describe different things. The decision is whether to scale back the promotion, defer some sales or secure additional resources. Each option needs explicit assumptions, constraints and someone accountable for carrying it out.
This is how demand planning fits into the broader sales and operations planning process, or S&OP: the forecast informs a decision rather than completing the process. Anaplan’s S&OP guide separates demand, supply and finance reviews before executive decisions.
For the project, we would therefore start with the path this promotion must take to approval, not a dashboard inventory. Who proposes the volumes? Who checks feasibility? Who assesses additional capacity costs? Who resolves competing functional objectives?
Scoping turns the process into project decisions
Suppose Sales works by customer and week, Operations by SKU and site, and Finance by product family and month. Moving everyone into the same platform does not automatically reconcile these views. The project must define their mapping, the information exchanged and the point at which an assumption becomes a commitment.
Scoping establishes a sufficiently precise agreement between business and IT to build the solution. We recommend working through a real planning cycle, using the files, data and meeting records already in use. This helps distinguish missing data, an undefined business rule and unassigned decision ownership. They can look similar on a screen but require different remedies.
| Business activity | Scoping decision | What EPM must support |
|---|---|---|
| Sales proposes a promotion. | Which products, customers and periods? Who explains and approves the demand assumption? | A baseline and a promotional scenario, each with explicit assumptions. |
| Operations checks feasibility. | Which source owns inventory and capacity data? When is it refreshed? | Comparison of demand and availability at the required granularity, keeping unmet demand visible. |
| Finance compares options. | Which net prices, costs and period-allocation rules apply? | Financial translation of volumes and an explanation of differences between scenarios. |
| Leadership decides and teams execute. | Who approves, by when, and how does the approved plan reach execution? | An identifiable approved version, decision traceability and the required downstream data transfer. |
This is not a shopping list of features. It shows how a scoping decision becomes a model rule, access permission, interface or control. If nobody owns changes after the monthly review, adding an approval button will not establish that authority.
Granularity follows the same logic. A monthly family-level view may support a revenue discussion but miss a shortage on a particular SKU in the promotion week. Retain the detail that changes the decision, then define its aggregation for Finance. Modelling everything at the lowest possible level is not inherently better scoping.
EPM connects plans without replacing every system
Enterprise Performance Management has a practical role here: connect operational assumptions to financial forecasts so teams can work with consistent scenarios. The promotional assumption should remain traceable from units to revenue and cost implications, without being re-entered and reinterpreted at every handover.
Importantly, the 1,000-unit supply gap is not automatically permanent lost revenue. Customers might accept later delivery, switch products or cancel. Scoping must establish which assumptions to use, and the model must expose them. Promotional prices and exceptional sourcing costs also need to be distinguished from normal trading conditions. The model’s value lies in explaining the differences, not merely producing a total.
Connecting operational and financial plans is central to Anaplan’s Integrated Business Planning positioning. SAP’s S&OP offering also emphasises scenario comparison and financial implications. These approaches inform the business objective; they do not require every activity to run in one application.
An existing forecasting engine or production-planning tool may remain the right place for its calculations, with results connected to EPM. In the proposed scope, the ERP remains the transactional and execution system of record. A supply chain planning solution such as SAP IBP and an EPM platform are not interchangeable categories: their respective roles depend on business needs, the existing landscape and verified capabilities.
The consultant must therefore define the boundaries as well as the connections. Which system calculates what? Who owns each input? Which version is transferred, how often, and what happens if a load fails? Otherwise, “connected planning” can still depend on manual reconciliation.
Make the first release narrower, not disconnected
This does not require a programme covering every product and entity from day one. Our promotional example could begin with one family, one market and one planning cycle. It should nevertheless connect the commercial proposal to approval and distribution of the agreed plan.
Our recommendation is to reduce business coverage rather than break the decision chain. Delivering only Sales input while indefinitely postponing financial reconciliation may leave the original problem unresolved. A limited but cross-functional release tests the handovers before the model expands.
At the end of scoping, the sponsor should be able to approve a brief covering that cycle, its owners, data, interfaces, exclusions and resource assumptions. If capacity data availability remains uncertain, the investment decision must acknowledge that dependency. A focused prototype may help resolve it, but cannot replace data ownership.
Acceptance must show that the business can make the decision
Acceptance should replay the scenario used in scoping. Sales enters promotional demand of 12,000 units; Operations exposes the 11,000-unit limit; Finance compares options under the agreed rules; the decision-maker approves a scenario. Teams must then find the correct version and understand what changed from the baseline.
Test the conditions that make this cycle fragile: an unmapped product, stale capacity data, a change after approval or the move into the next month. Working screens and formulas are necessary, but insufficient. The solution must support the process when information is missing or a decision is challenged.
Measure both forecast quality and the ability to act on it. Review preparation time, cross-functional rework and approval turnaround complement accuracy measures. Establish targets against the current process rather than a vendor’s or integrator’s generic improvement promise.
We see this as making a business planning process executable, not simply deploying a demand model. Scoping connects business ambition to solution decisions; EPM supports that agreement through successive planning cycles.
Key takeaways
- Start with the business decision: a forecast should support trade-offs between demand, capacity and financial objectives.
- Scope before modelling: agree ownership, business rules, data and the level of detail the decision requires.
- Give EPM a clear role: connect assumptions and compare their implications without automatically replacing existing tools.
- Narrow the scope, not the process: the first release should connect the commercial proposal to an approved plan.
- Test the ability to decide: validate a complete cycle, its exceptions and its use by the teams, not just its calculations.
Preparing a similar project? Start with one planning cycle and a decision that is difficult today. Polygon can support project scoping and subsequent EPM implementation. Continue with first go-live trade-offs.
