How demand forecasting works inside Captia.ai
The module answers a very specific question: how much the plant will have to produce in each period of the requested horizon. It does not look at a physical signal, it looks at the work the factory is about to be asked for. Its raw material is therefore not a sensor but two sources that are rarely in the same place: the production history recorded in the platform and the order, backlog and commercial forecast data that live in the ERP and the MES.
The chain starts at integration. Captia.ai integrates through APIs with ERP, MES, CRM or SAP, and Captia Connect captures what happens on the floor at the edge over the protocols available in the installation (MQTT, OPC UA, Modbus TCP, Modbus RTU over RS-485, OpenWebNet, IEC 870-5-102, REST API, webhooks or CSV files), normalises it into time series and sends it with local buffering so a network drop does not open gaps in the history. The module works afterwards, on that consolidated history with homogeneous timestamps.
Processing has three movements. First it reconstructs actual past demand, which is not the same as past production: what was made is bounded by the capacity that existed, whereas what was asked for sits in the ERP. Second, it projects that demand over the horizon and the level of aggregation the decision requires: per plant, per line, per family or per SKU. Third, and this is where the useful work happens, it translates that projection into workload, because demand in units is not actionable until it becomes line hours, shifts and material.
The output lives inside the platform, not in a separate file: dashboards per asset, line, role or plant; rules and alerts when projected demand exceeds what the plant can serve; traceable events in the history; periodic reporting; and an API write-back to the ERP or the MES when the forecast has to land in the master plan. That write-back is the part most often forgotten when scoping the project, and the one that decides whether the forecast changes anything or stays as a chart.
| Layer | What it contributes | Where it lives |
|---|---|---|
| Input | Normalised production history plus orders, backlog and commercial forecast integrated from ERP and MES | Captia Connect (edge) and API integration in Captia.ai |
| Processing | Reconstruction of past demand, projection by horizon and aggregation level, and translation into workload | Demand forecasting module over the platform industrial models |
| Output | Dashboards, rules, alerts, events, reporting and API write-back to ERP, MES, CRM or SAP | Captia.ai, and the management system where planning happens |
It is worth separating it from its sibling module. The forecasting module projects the future evolution of a variable from its past behaviour, be it consumption, temperature or flow, and it is a generic time series capability. Demand forecasting is a bounded application of that capability with two distinctive traits: its target variable is not measured by a sensor but read from the ERP and the MES, and its output is phrased in the language of sizing. If the goal is to project a process signal, forecasting is the right module. If the goal is to know how many shifts to open next month, this one is.
Data requirements: what is needed before switching it on
The hard requirement, and the one that decides whether the project is viable at all, is integration with ERP and MES. Without it the module only sees past production, and past production is a censored answer: it does not record the order turned down for lack of capacity, nor the one served late, nor the one cancelled. A model trained only against production learns the limit of the factory rather than the demand of the market, and projects that limit forward. That integration is engineering work with a name of its own, described in the Captia Connect ERP integration service.
The second requirement is a stable, shared item master. If the ERP calls a product one thing and the MES another, and neither matches what the floor writes on the production record, there is no history to reconstruct: there are several short series for items the system believes are different. Reconciling codes, families and units of measure is not project preparation, it is the project.
The third is enough history for the pattern to be represented. Industrial demand almost always carries seasonality, and annual seasonality cannot be learned from less than one full cycle: several are needed to separate the season from the noise. The specific scope is set during the diagnosis, not by default, and it depends on the horizon to be covered.
The fourth is a record of exceptions. A promotion, a large customer shutting down, a range change or a new competitor entering are events that explain jumps in demand. If they are logged somewhere in the ERP, the module can treat them for what they are. If they are not, they remain unexplained noise and degrade any forward projection.
The fifth is the definition of the decision unit. Forecasting per SKU, per family or per line are different projects with different data requirements, and the choice is set by the decision to be taken, not by the ambition of the model. Forecasting at SKU level when the decision is about shifts adds error without adding information. The theory of why aggregation reduces relative error sits in the industrial forecast guide.
Industrial application cases
The most recurrent case is sizing shifts and staffing. The decision to open a third shift, hire temporary staff or stop a line is taken weeks in advance and almost always with the order backlog in hand and little else. A forecast that translates projected demand into the line hours required, and that raises a flag when those hours exceed installed capacity, changes the moment at which that decision is taken.
The second case is purchasing material with long lead times. When the lead time of a component exceeds the horizon of the firm backlog, the purchase is necessarily made against a forecast. Here the value of the module is not being right, it is making explicit which forecast the purchase is being made against and keeping a record in the platform of how that forecast evolves against what eventually happens.
The third is sizing finished goods stock in plants with irregular demand. Where variability is high, a forecast serves less to fix a figure than to size the buffer that absorbs the error, and to know for which SKUs that buffer is expensive and for which it is cheap.
The fourth is detecting deviation between forecast and actuals, which is where a forecast becomes a control tool rather than only a planning one. With rules and alerts in Captia.ai, a sustained deviation stops being discovered at the month-end review and becomes a traceable, dated event.
The fifth is the link with energy. A demand forecast is also a forecast of plant load, and therefore a natural input for the production and consumption optimisation module when the aim is to find the operating point that balances production and consumption.
How it is deployed in phases
Deployment follows the same phases as the rest of the platform, described in the industrial data platform hub, with one particularity: in this module the heavy lifting sits in the integration phase, not in the modelling one.
- Diagnosis. Which decision is to be improved, how far in advance it is taken today and on what information. From that come the horizon, the aggregation level and the periodicity, the three parameters that define the module.
- ERP and MES integration. Access to orders, backlog and item master, reconciliation of codes and units, and comparison against recorded production. This is the phase that decides feasibility and usually the longest one.
- Edge deployment. Captia Connect on the floor so actual production is recorded with homogeneous timestamps rather than depending on a manual record.
- Platform go-live. Demand and load dashboards per line or plant, users and roles, and the first capacity warning rules.
- Intelligence. With a consolidated history and enough context, the demand forecasting module is activated. Before this point it has nothing to work on.
- Operationalisation. Workflows, periodic reporting and API write-back to the ERP or the MES, plus continuous tracking of the deviation between forecast and reality, which is what keeps the module honest over time.
| Horizon | Decision it sizes | Data that constrains it |
|---|---|---|
| Short | Sequencing and line allocation within the plan already committed | Firm backlog from the ERP and actual machine state captured by Connect |
| Medium | Shifts, staffing and purchasing of material with lead times | Commercial forecast, seasonality in the history and supplier lead times |
| Long | Installed capacity, line investment and stock policy | Several cycles of history and the recorded exceptions that explain the jumps |
Limits and when it does not apply
This is worth stating plainly, because this is the module that generates the most badly framed projects. Demand forecasting does not apply, or adds little, in these scenarios:
- Without ERP or MES integration. This is the hard limit. With recorded production alone the module projects what the plant was able to make, not what the market asked for, and inherits any past capacity constraint as if it were demand. What is missing then is integration, not analytics.
- With few customers and project-based demand. If revenue depends on a handful of large, discrete contracts, demand is not a time series: it is a sequence of commercial decisions. There a conversation with the customer informs better than any model, and the module can only add historical context.
- Facing structural breaks. A range change, entry into a new market, a merger or the loss of a main customer invalidate the past as a reference. The module does not know what has not happened yet, and no technique fixes that.
- When the item master is not stable. If codes change, duplicate or do not match across systems, the history to be projected does not exist. Reconcile the master first, forecast afterwards.
- When the plant has no sizing margin. If shifts are fixed by agreement, the line runs at its limit and there is no purchasing decision to take, knowing future demand changes no action. It still helps justify investment, but not to operate.
- When the goal is to project a process signal. For a variable measured by a sensor, the right module is forecasting, not this one.
And two transversal limits. First: every forecast carries error, and the job of the module is not to remove it but to make it visible and stable so sizing decisions are taken knowing how much margin to leave. Second: the module evidences and proposes, it does not issue production or purchase orders on its own. Action is executed through the Captia.ai rules and workflows the team defines and supervises.