Machine learning forecasting in Dynamics 365 Supply Chain

Demand forecasting in Dynamics 365 Supply Chain Management runs as an Azure Machine Learning service that consumes historical demand data and produces statistical forecasts at item, item-warehouse, item-customer, or item-allocation-key granularity. Done right, it replaces manual planner spreadsheets with a baseline forecast that planners adjust rather than generate. Done badly, it produces numbers nobody trusts and gets switched off in month two.

Architecture. The flow is one-way push, batch:

1. F&O exports demand history (sales orders, transfer demand, configurable filters) to Azure storage.
2. Azure ML reads the data and runs the configured algorithm.
3. The forecast result is imported back into F&O as a baseline demand forecast.
4. Planners review, accept, or override forecasts in F&O.

The Azure ML side is operated by Microsoft as part of the SCM service — customers don't manage the model, but they configure parameters that affect the algorithm choice.

Algorithms available.

• ARIMA — autoregressive integrated moving average; strong for stable demand with trends.
• ETS — exponential smoothing; strong for seasonality.
• STL Decomposition — separates trend/seasonality/residual; good visibility for planner trust.
• Forecasting Tree — non-parametric tree model for complex patterns.

The service runs all algorithms and picks the best by error metric (typically MAPE or RMSE) per item-location combination. Customers can override.

Parameters that matter.

• Forecast horizon — how many periods ahead.
• Forecast frequency — daily, weekly, monthly buckets.
• Historical horizon — how much history to consider.
• Confidence threshold — minimum confidence required to use the forecast; below that, fall back to a heuristic or planner manual.
• Missing value substitution — zero-fill, average-fill, interpolation.
• Outlier removal — Z-score threshold for outlier elimination.

Outlier handling is the most under-considered parameter. A pandemic-driven spike, a one-off bulk order, or a stockout disrupting normal demand all corrupt the history; outlier removal cleans them up before the algorithm sees them.

Granularity. Forecasts can be at:

• Item only.
• Item + Site.
• Item + Site + Warehouse.
• Item + Site + Allocation Key — for downstream allocation across DCs.

Finer granularity = more accuracy potential but more data sparsity per series. Items with low volume at a granular level produce noisy forecasts; aggregate higher.

The planner override pattern. F&O presents forecasts in the Demand Forecasting Workspace. Planners can:

• Accept the ML number as-is.
• Multiply by a percentage (sales sees a 10% promotional lift coming).
• Hard-override a specific period (a known one-time order).
• Replace with a manual forecast entirely.

Best practice: ML produces the baseline, planners add the intelligence ML doesn't have. The override audit trail records who changed what and why.

Forecast accuracy. Standard KPIs:

• MAPE — mean absolute percent error.
• Bias — systematic over- or under-forecast.
• WAPE — weighted absolute percent error (weighted by volume so big items count more).

Track accuracy by item, by category, by planner-overridden vs ML-baseline. The accuracy report is the credibility tool — without it, planners revert to spreadsheets.

Integration with master planning. Once the forecast is accepted, it flows into the demand side of master planning (or Planning Optimization). Master planning consumes forecasts plus sales orders, runs supply suggestions (purchase, transfer, production), and creates planned orders. Forecasts beyond the firmed horizon drive long-lead procurement; sales orders inside the firmed horizon drive short-term operations.

Forecast consumption. When a real sales order lands in a forecast period, the forecast is consumed by the sales order — net demand becomes max(forecast, actual). Configurable consumption rules govern this; tuning matters in fast-cycling businesses to prevent double-counting demand.

Common pitfalls.

• Garbage historical data. Returns, cancellations, and inter-company transfers polluting the sales history → wrong forecast. Clean the input.
• Granularity mismatch. Item-level forecast at the SKU but planning at the family level; reconcile.
• One-time events not flagged. A massive promotional event one year ago that won't recur is treated as a normal high-demand pattern; outlier removal must catch it.
• No accuracy tracking. Without it, planners stop trusting the system; ML becomes shelfware.
• Algorithm choice locked in. Different item categories need different algorithms; let the service pick per-series.

Operational reality. ML forecasting is a tool, not a replacement for planning judgement. The teams that get value from it use it as the conversation starter, not the answer.