Evaluate demand-planning software with constrained depot replenishment

An accurate forecast can still produce an impossible replenishment plan

A distribution team forecasts demand for two depots and has enough information to identify a likely shortage. The planning demonstration allocates every available unit. Yet one depot cannot receive its assigned quantity within the required period.

The forecast and the replenishment plan answer different questions. The forecast estimates demand. The operational plan must also respect stock, lead time, receiving capacity and the organisation’s allocation policy. A software evaluation should test that connection explicitly.

The best starting point is one real planning decision with authorised historical data. Ask the supplier to show the assumptions, proposed quantities and unresolved constraints. A polished aggregate chart is not evidence that the depot can execute the resulting plan.

Separate the layers of the planning model

Define the demand unit, location and time bucket. A weekly forecast in cases cannot be compared directly with a receiving limit in pallets without a controlled conversion. Likewise, a monthly total can hide a daily capacity conflict.

The Microsoft Dynamics 365 — Demand planning overview describes forecast review, scenario analysis, versioning and aggregation or disaggregation capabilities. Those are useful demand-planning functions to evaluate. They do not by themselves prove that a particular implementation solves depot receiving or transport-capacity constraints.

Identify where each operational constraint is applied. It may reside in the planning product, an ERP module, a transport system or a controlled planner review. The evaluation should show the full decision path rather than assume all constraints are native to one application.

Keep confirmed inputs separate from provisional assumptions. A forecast run should remain reproducible after the live records have changed.

Illustrative depot test: unused stock and unmet demand can coexist

Assume a fictional source has 500 usable units available for the planning period. Depot A needs 300 units and Depot B needs 300 units. Total demand is 600 units, so supply alone creates a shortage of 100 units.

Depot B can receive only 150 units during the relevant period. Under the example policy, Depot A receives its full 300 units and Depot B receives 150. The feasible movement total is 450 units, leaving 50 units at the source and 150 units of unmet demand at Depot B.

The 150-unit shortfall includes the 100-unit supply shortage plus another 50 units that cannot be received within the period. Reporting only “500 units allocated” would conceal the capacity problem.

The retained 50 units may be useful in a later period or another approved plan. The evaluator should see that option as a separate scenario with its own timing, not as a claim that the current period’s demand has been met.

Test how the system explains a recommendation

A planner should be able to trace a proposed transfer back to the demand version, available-stock calculation, capacity limit and policy used. If the explanation is simply “the optimiser selected it,” the business cannot assess whether the decision reflects its priorities.

Ask what happens when an input changes. If Depot B gains an approved receiving window, the plan may become more feasible. If the source stock is placed on hold, the allocation must be reconsidered. The system should show the affected quantities and commitments.

Keep planner overrides visible. An override can be appropriate when new evidence is not yet represented in the model, but it needs a reason, owner and scope. It should not silently become training history that the next forecast treats as ordinary demand.

The evaluation should also distinguish requested, approved, ordered and received quantities. A proposed replenishment is not an actual receipt, and an accepted plan does not establish that the carrier has capacity.

Compare spreadsheet planning, native modules and an integrated model

A controlled spreadsheet can work for a limited number of depots and products where the planner understands the constraints. Its weakness is preserving versions, dependencies and consistent units as the network grows.

An ERP or demand-planning module may provide useful forecasting and review capabilities. Test its actual configuration with the depot scenario, including the handoff to inventory and transport decisions. Avoid purchasing on the assumption that a feature name covers every operational constraint.

An integrated planning model is justified when repeated cross-system reconciliation consumes substantial effort or creates execution errors. It should make assumptions and infeasible demand visible, not hide them behind a single recommended number.

Compare the options using identical inputs and an agreed expected result. The 450-unit feasible movement and 150-unit unmet demand provide a concrete test for the illustrative scenario.

Review forecast quality without losing the operational question

Assess forecast performance using data that would have been available at the planning date. Compare like periods and locations, and preserve the baseline method. A demonstration that uses later actuals as inputs cannot establish prospective forecasting performance.

Separate forecast error from execution shortfall. Depot B’s inability to receive 300 units does not mean its demand forecast was wrong. Likewise, a transport delay should not automatically be treated as a change in customer demand.

Track planning effort, unresolved constraints and the proportion of proposed quantities that require manual repair before execution. These measures complement forecast error and show whether the planning process is useful to the depot teams.

Avoid declaring a universal improvement from a small sample. A bounded replay can identify fit and weaknesses; sustained performance needs an agreed evaluation across relevant demand conditions.

Make failure and recovery observable

Test missing capacity data, a late stock correction and inconsistent units. The system should identify the uncertainty and route it to the responsible owner rather than default to unlimited capacity or available stock.

If the planning service is unavailable, retain the last approved plan and its assumptions for controlled review. Do not treat it as automatically current. The planner must consider changes that occurred after its approval.

On recovery, compare the new proposal with the existing approved orders and transfers. Re-running a model should not create a second set of commitments for quantities already released.

For a focused software assessment, prepare one constrained depot scenario, a baseline forecast and the execution records needed to judge feasibility. The result should explain where each constraint is enforced and which handoffs need improvement.

Demand planning becomes operationally valuable when the team can see what is expected, what is feasible and what remains unserved. A software demonstration should make all three visible.

Next actions

1. Define the depot decision, units and planning periods before selecting features.
2. Replay demand against usable supply and actual receiving constraints.
3. Trace recommendations through approval and execution without double counting.
4. Compare forecast quality and plan feasibility as separate evaluation outcomes.