Anaplan Forecaster launched in October 2025 as the next generation of PlanIQ, Anaplan's machine-learning forecasting capability. It trains faster, supports a wider set of algorithms, and is built around explainability for planners rather than for data scientists. It is also easy to misuse: point it at bad history, skip the backtest, and you will get a confident-looking forecast that the business quietly ignores. This tutorial is about avoiding that.
From PlanIQ to Forecaster
If you used PlanIQ, the shape of the work is familiar: you supply historical actuals (and optionally related drivers), configure a forecast, and import the result back into a planning module. What changed:
- Algorithms. Forecaster evaluates a broader library of statistical and machine-learning methods and selects per series, so intermittent, seasonal, and trend-driven items can each get a different model.
- Speed. Training and forecast generation are substantially faster, which makes weekly or even daily reforecasting practical.
- Explainability. Forecaster exposes which drivers and which components (trend, seasonality, driver effects) contributed to a forecast, in terms a demand planner can read.
- Migration. PlanIQ forecast actions are not converted automatically. You recreate them in Forecaster, run both in parallel, compare, and retire PlanIQ.
Step 1: Prepare the history
Forecaster learns from what you give it. Spend most of your effort here.
Structure. Build a dedicated history module with exactly the dimensions you want to forecast at (for example Product x Location x Week). Do not forecast at a level finer than you plan at; aggregate first.
Depth. Two full years of history is the practical minimum for seasonal series; three is better. Shorter series will be forecast, but mostly by simple methods.
Cleanliness. Remove or flag one-off events that will not recur (a warehouse fire, a one-time bulk order). A common pattern is a Cleansed Actuals line item:
Cleansed Actuals = IF Exclude Period? THEN Adjusted Actuals ELSE Actuals
where Exclude Period? and Adjusted Actuals are planner inputs in an Inputs module. Forecast from Cleansed Actuals, never from raw.
Gaps and zeros. Decide what a zero means. A zero because the product was not yet launched is not the same as a zero because nobody bought it. Trim series to start at first sale:
First Sale Period = FIRSTNONBLANK(Actuals, TIME.Period)
In History? = ITEM(Time) >= First Sale Period
History for Forecast = IF In History? THEN Cleansed Actuals ELSE BLANK
(Use the function names your model supports; the point is to make the series start explicit.)
Step 2: Add drivers, carefully
Drivers (price, promotion flags, holidays, temperature, marketing spend) can improve a forecast materially, with two conditions: you must have driver values for the future periods you are forecasting, not only for history, and the driver must plausibly cause demand rather than merely correlate with it. A promotion calendar is a good driver. Last month's sales of a competitor product is usually not, because you will not have next month's value.
Keep drivers in their own module dimensioned identically to the history module, and include a Boolean per driver so planners can switch them in and out of the forecast configuration without rebuilding it.
Step 3: Configure the forecast action
In the Forecaster configuration you choose the history source, the forecast horizon, the drivers, and the output destination. Three decisions matter most:
- Horizon. Forecast only as far as the business will act on. An 18-month horizon for a weekly replenishment model is wasted computation and misleading precision.
- Granularity. Forecast at the level where the series are stable and disaggregate in the model using a profile. Forecasting every SKU-store-week directly is rarely best.
- Selection. Let Forecaster choose the algorithm per series for the first pass. Override only where the backtest tells you to.
Step 4: Backtest before you believe anything
Backtesting means holding back the most recent periods, forecasting them as if they were unknown, and measuring the error against what actually happened. Forecaster supports this directly; do it for every material series before the forecast goes anywhere near a plan.
Bring the backtest output into a module alongside actuals and compute accuracy yourself so the metrics match what your business already uses:
Abs Error = ABS(Backtest Forecast - Actuals)
Abs Pct Error = IF Actuals <> 0 THEN Abs Error / Actuals ELSE 0
MAPE (summary) = Abs Error[SUM] / Actuals[SUM] -- weighted, in an Outputs module
Bias = (Backtest Forecast - Actuals)[SUM] / Actuals[SUM]
Look for bias first (systematic over- or under-forecasting), then error. A forecast that is 12% wrong but unbiased is usually more useful to a supply chain than one that is 9% wrong and always high.
Step 5: Read the explainability output
Forecaster's explainability tells you, per series, how much of the forecast is baseline level, trend, seasonality, and each driver's effect. Use it in three ways:
- Sanity checks. A large positive effect from a driver that the business does not believe in is a flag, not a discovery.
- Planner trust. Show planners the decomposition for their top twenty items. A forecast that can say "this is up 15% because the promotion calendar has two events next month" gets adopted; a black box does not.
- Driver pruning. Drivers that contribute nothing across the board should be removed. Fewer drivers means fewer future inputs to maintain.
Step 6: Embed the forecast in the plan
The forecast should land in the planning model as a baseline, with a governed override on top:
Statistical Baseline = (imported from Forecaster)
Planner Override = (input, blank by default)
Final Forecast = IF ISNOTBLANK(Planner Override) THEN Planner Override ELSE Statistical Baseline
Override Flag? = ISNOTBLANK(Planner Override)
Keep the three numbers (baseline, override, final) as separate line items forever. They are the raw material for the next step.
Step 7: Measure forecast value added
Forecast value added (FVA) answers the only question that matters: is each step of the process making the forecast better? Compare, over a rolling window, the accuracy of:
- A naive forecast (same as last year, or last period),
- The Forecaster baseline,
- The final forecast after overrides.
If Forecaster is not beating naive for a series, turn it off for that series. If overrides are making the forecast worse (this is common), show the planners the evidence and tighten the override process. Put the FVA comparison on a New UX page and review it monthly. This single page does more for forecast quality than any algorithm choice.
Where Forecaster will not save you
Sparse, intermittent demand with a few sales a year; brand-new products with no history; and series with structural breaks (a price-model change, a lost major customer) are all places where Forecaster will produce a number and the number will not be worth much. Use analog-product profiles for new products, consensus input for intermittent items, and be prepared to reset history after a structural break.
If you want help with Forecaster enablement, migration from PlanIQ, or setting up FVA tracking, see our AI-Powered Planning with Anaplan Intelligence service.