The forecast is the problem
A regional FMCG enterprise running on SAP APO or its successor IBP is forecasting demand with a tool that was designed in a different decade for a different problem. The architecture is honest about what it does. It takes a historical time series, applies a model from a catalogue of statistical methods, and emits a forecast at a chosen aggregation level. For workloads where the demand shape is stable, the seasonality is well-understood, and the exogenous variables are minor, this works. For Middle East FMCG, almost none of those conditions hold.
The demand patterns at a major regional FMCG enterprise are driven by inputs the APO model cannot ingest in any structured way. Ramadan-shifted purchasing windows that move year on year. Public-sector salary cycles that pulse demand in 28-day rather than monthly buckets. Promotional calendars that compete with the enterprise's own promotions across the same retail accounts. Hyperlocal weather patterns that swing chilled-category demand by double-digit percentages in a single week. None of those are time-series features. All of them are causal inputs that show up in the forecast error.
The forecast error is the bill. Excess inventory in the wrong DC. Stockouts at the wrong accounts. Carrier costs to rebalance the network mid-week. Promotion accruals that overshoot. The categories where the enterprise is best instrumented are the ones where the forecast error is most expensive, because the volume is highest. A forecast that is two percentage points more accurate at SKU-account-week level is worth materially more than any of the AI add-ons SAP is currently pitching against the same data.
This piece is the working architecture for the alternative.
What "agentic forecasting" actually means
A demand forecasting agent is not a black box that emits a number. It is a structured pipeline that ingests inputs, applies a model, surfaces the rationale for the planner to inspect, and supports an override workflow that captures the planner's judgement back into the system. The agent does not replace the demand planner. It replaces the spreadsheet the demand planner has been using to override the APO forecast every Tuesday for the last six years.
The components of a working agent against an FMCG estate:
A data layer that ingests the enterprise's transactional history at SKU-account-day granularity, joined against the structured exogenous features the APO model cannot accept. Hijri calendar markers for Ramadan and the religious holidays. Public-sector salary disbursement dates by emirate. Public weather data joined against the relevant store catchments. Competitor promotion windows reconstructed from observed market data. National holiday schedules across the region. Each of those features lives as a column the model can read and a column the planner can interrogate.
A model layer that combines a classical baseline with a learned residual model. The baseline gives the enterprise a forecast that behaves predictably under the conditions APO already handles well. The residual model captures the systematic gap between the baseline and the actual demand, conditioned on the exogenous features the baseline cannot use. The two combined give the planner a forecast that improves on APO without losing the parts of APO's behaviour the planner has built trust in.
A reasoning layer that explains the model's output in language the planner can act on. When the forecast for a SKU-account-week is two standard deviations above the baseline, the agent surfaces the features driving the deviation. When it is below, the same. The planner spends time on the forecasts that warrant attention rather than reviewing every cell in the grid.
An override layer that captures the planner's adjustment, the reason, and the historical track record of similar adjustments. Over time the override layer becomes a structured input back to the model, weighted by the planner's accuracy on previous calls of the same shape. The institutional knowledge that has been living in the planner's head moves into the system.
What we keep from SAP
The new pipeline does not replace SAP. APO continues to handle the master planning workflow, the supply network design, the deployment optimisation, and the integration to the enterprise's transportation and warehouse systems. The new forecasting agent emits its forecast into APO at the same boundary APO already accepts. The downstream planning steps run unchanged. The auditor's view of the planning process is identical. The CFO sees the same numbers in the same place.
What changes is the input to APO. The forecast that drives every downstream calculation is materially more accurate against the SKU-account-week reality the enterprise actually runs.
The region-specific features the agent needs to handle
Three feature families dominate the residual model for a Middle East FMCG enterprise:
Ramadan and the religious calendar. The Ramadan-shifted purchasing window moves earlier each year by approximately 11 days. The pre-Ramadan stock-up, the in-Ramadan consumption pattern, the post-Iftar shopping pulse, and the post-Eid recovery are all distinct phases the time-series model treats as one block. Each phase has a different demand signature by category. A frozen-foods buyer behaves differently in pre-Ramadan week than a beverages buyer.
Salary cycles by emirate and by sector. UAE government salary disbursement follows a regulated schedule that pulses retail demand in predictable ways. KSA has a different schedule. Both shift the demand peak in modern-trade retail by several days around the calendar end-of-month. The aggregate effect at the monthly level is small. The per-week effect is large enough to drive the carrier planning decisions in the second half of every month.
Weather and ambient temperature. Chilled and frozen categories swing materially with ambient temperature outliers. Beverages, ice-cream, dairy, ready-to-eat — each has a distinct elasticity. The APO model cannot accept temperature as a structured input. The residual model treats it as a first-class feature, joined against the store catchment, and the forecast bends accordingly.
What the build looks like
A working version of this agent against a real FMCG estate takes approximately 14 weeks from kickoff to first production traffic. The phases:
Weeks 1 to 3 — discovery and the eval suite. Map the enterprise's existing forecast accuracy at SKU-account-week. Identify the categories with the largest absolute error. Build the eval suite that defines what "better" means against the existing baseline.
Weeks 4 to 7 — feature engineering and the baseline. Stand up the data layer. Build the exogenous feature pipeline. Train the baseline against historical data. Validate against the eval suite. The baseline alone usually improves accuracy by enough to fund the rest of the build.
Weeks 8 to 11 — the residual model and the reasoning layer. Train the residual model. Stand up the explanation surface. Validate against the eval suite. Show the demand planner the explanation surface and iterate on what makes the explanations actionable.
Weeks 12 to 14 — shadow run and handover. Run the agent in production but emit its forecast into a parallel APO instance. The enterprise's planners compare the agent's forecast against the existing forecast for one full planning cycle. The supply-chain leadership team decides which forecast goes to production based on the eval-suite numbers, not on intuition.
The team operating the agent after week 14 is the enterprise's own demand planning team plus the supply-chain data engineering function. The handover is the deliverable.
The saasinator perspective
A forecast accuracy improvement of two to four percentage points at SKU-account-week against the existing APO baseline is what we see in the engagements we run. The economic value of that improvement is the smallest line in the business case. The larger line is the planning team's productivity, because they spend their time on the forecasts that warrant attention instead of reviewing the grid. The largest line is the optionality that comes with owning the forecasting layer. The enterprise that owns the forecast can iterate on the model, swap the model, and extend the model into adjacent workflows without a vendor release cycle.
The vendor pitch for adding AI to APO via the SAP ecosystem is rational on the brochure. The architecture of that pitch is the same as every other vendor AI bundle. The model is the vendor's. The training data is the enterprise's. The economics flip in the enterprise's direction the moment ownership of the model becomes possible.
What to bring to the diagnostic
If you are operating a regional FMCG estate on SAP APO or IBP and the forecast accuracy at SKU-account-week is below what your supply-chain leadership team would call acceptable, the conversation worth having is which categories would move first. Bring three categories worth of historical forecast accuracy. Bring the existing planner override rate. Bring the eval definition the team currently uses, or the absence of one if there is no formal definition.
Book a diagnostic. Ten working days. We will tell you which category would gain the most from the new pipeline and what the 14 weeks would look like against your estate.