Part 1 Intro to Demand Forecasting in Dynamics 365 Supply Chain Management - TechTalk

Summary (TechTalk Part 1: Intro to Demand Forecasting in Dynamics 365 Supply Chain Management)

What demand forecasting is (and why it’s useful)

Demand forecasting predicts future demand for products/services to support:

• Revenue estimation
• Strategic and operational planning

Key benefits discussed:

• Reduce buffer inventory and cash tied up in on-hand inventory
• Avoid costs from unexpected demand (e.g., expediting procurement/production)
• Support make-to-order by reducing sales-order-to-delivery time (ordering/making earlier for long-lead items)
• Improve global capacity planning by analyzing demand over larger time windows
• Prevent stock-outs (especially important in retail to avoid lost sales)

High-level system architecture

Forecasting in Dynamics 365 Supply Chain Management uses:

• Dynamics 365
• Azure Machine Learning
• Azure Data Lake

Conceptually:

• The “Dynamics” part triggers modeling
• The “Azure” part performs statistical/time-series forecasting

Core time-series forecasting concept used

Dynamics/Azure Machine Learning uses time series forecasting based on historical demand patterns.

Forecast components:

1. Trend (up/down direction)
2. Seasonality (repeating spikes/patterns; may be quarterly/annual, etc.)
3. Error/Noise (random variation not perfectly explained)

How Dynamics evaluates and compares forecasting models

When generating a forecast:

• Dynamics builds the model using a subset of historical demand
• It keeps remaining points to evaluate accuracy

Accuracy metric:

• MAPE (Mean Absolute Percentage Error) compares actual vs forecast values
• Guidance:
  • MAPE ~20 or less is considered “pretty good”
  • Lower is better (e.g., 10 is “even better”)

Notes:

• Dynamics does not expose the raw underlying equation
• It provides forecast outputs, confidence intervals, and traceability

Forecast “granularity” and dimensions

Forecast results are generated per granularity attribute—a unique combination of enabled forecast dimensions.

Mandatory dimensions:

• Company
• Site
• Allocation key (item allocation key)

Optional additional dimensions may include:

• country/region, state
• customer group/account
• warehouse inventory status
• item number
• product dimensions (size/color/style/configuration)

Key impact explained:

• Running forecasting at a detailed level and aggregating may produce different results than forecasting directly at a less detailed level.

Major forecasting algorithm parameters in Dynamics (used by Azure/R)

Parameters highlighted include:

• Time series model choice:

  • ARIMA, ETS, STL
  • combinations such as ETS+ARIMA, ETS+STL
  • All: tests all options and selects the lowest MAPE (can take longer)

• Minimum / Maximum forecasted value:

  • clamps predictions within allowed bounds (e.g., avoid values above a max)

• Missing value substitution:

  • handles gaps in history (e.g., interpolation vs 0; recommended default often 0)
  • scope can be global vs specific granularity attribute/date range (recommended global)

• Confidence level (1–99):

  • controls confidence interval band size in the outputs
  • affects how the forecast is presented more than the mean forecast quantity

• Seasonality hint:

  • interval length for repeating seasonality
  • example: quarterly pattern → monthly buckets → set hint accordingly

• Trend vs seasonality relationship:

  • additive: seasonality magnitude independent of trend
  • multiplicative: seasonality magnitude scales with trend
  • none/auto options (auto recommended if unsure)

• Test set size percentage:

  • portion of history reserved for accuracy testing (example: 20%)
  • tradeoff: enough data for reliable MAPE vs performance

Implementation guidance / best practices highlighted

• Test and retest: tweak parameters and compare outputs/MAPE
• Include a data scientist (or statistical background) to reduce issues like flat forecasts
• Dynamics UI parameters aren’t the full set of R parameters:
  • if defaults aren’t sufficient, review R package parameters (noted as part of future tech talks)
• Data requirements:
  • historical horizon should be at least 2× the forecast horizon
  • include at least two cycles of seasonality if applicable

Dynamics 365 setup required (before the Azure modeling)

Key setup items include:

• Forecasting unit:

  • requires unit conversions to generate forecasts

• Forecast strategy for transaction history:

  • options include manual/copy historical vs Azure machine learning (focus of the session)
  • older “Azure machine learning classic” was mentioned as deprecated

• Forecast dimensions tab:

  • configure granularity via company/site/allocation key plus additional dimensions

• Item allocation keys:

  • group items to improve forecast generation performance (parallel-style processing)
  • allow different algorithm settings per allocation key

• Forecast models:

  • track multiple forecast sets (system-generated vs customer/sales/team-provided)

• Outlier removal queries:

  • remove anomalous demand events (e.g., one-time huge order)

• Intercompany planning groups:

  • define forecast sequence (downstream first, upstream later)

• Master plan tie-in:

  • choose how forecast is used to satisfy demand during planning

• Forecast reduction method:

  • define how to reduce forecast when real orders/transactions arrive (periodic/real-time/fixed percentage, etc.)

End-to-end forecast generation process (demo walkthrough)

1. Ensure historical demand exists (use data migration if needed via historical external demand).
2. Generate forecast: “Generate statistical baseline forecast”
   • set:
     • historical horizon (e.g., ≥ 2 years for a 1-year forecast)
     • forecast horizon (e.g., 12 months)
     • bucket size (day/week/month)
     • optional freeze time fence
3. Review outputs: “Adjusted demand forecast”
   • forecast lines shown per granularity
   • confidence interval displayed based on confidence level
   • traceability:
     • historical values used
     • system forecast vs manually edited values (edited row bolded)
   • example noted:
     • when little/no history exists, forecasts may default to minimum (e.g., value of 1)
4. Authorize/publish forecast to system for planning use.

Q&A highlights from the session

• Grouping items to reduce granularity

  • remove item number from dimensions and forecast at allocation key level (already part of required setup)

• SKU retirement / supersession

  • no native item supersession
  • workaround: export old item history, transform to align with the new SKU, then re-import

• Seasonality on a weekly basis

  • depends on data volume/gaps; deep granularity may lack sufficient data

• Where does country/region come from?

  • needs follow-up (speaker wasn’t sure from memory)

• Use sales forecast vs statistical generation

  • manual forecast lines can be entered (e.g., UI/Excel) and differentiated by forecast model; can later be edited

• License/cost questions for Azure ML component

  • Azure costs are on the customer’s Azure subscription
  • no extra D365 licensing required specifically for forecasting generation
  • compute cluster running the R script is a major cost driver (Azure pricing estimator can help)

• Can forecasts be updated/re-generated?

  • yes; regenerate at any time (e.g., quarterly or after management changes) and override published forecasts

• Can Dynamics use external factors beyond historical demand?

  • not natively; forecasting here is time-series based on historical demand only
  • extensibility exists but requires partner/customization to become multivariate

• Add more forecast dimensions in code?

  • described as “mission impossible” / not straightforward—would require UI/code/enumeration changes

---

Main speakers / sources

• Ann Krupke — Senior Fast Track Solution Architect (Microsoft)
• Nikhil Paldicar — Fast Track group (Microsoft)
• Toby James — Fast Track group (Microsoft)
• Andre Garmash — Senior Software Engineer, Product team (Demand forecasting)
• David — Moderator (introduced session; also TechTalk host)
• Microsoft Azure Machine Learning + R “forecast” package — referenced as the forecasting engine/tooling behind the scenes