Forecasting in the shadow of Excel:
|
| Prepared for | Person Three—VP Group IT, Data and Analytics Person Four—Operating Partner, Investor |
|---|---|
| Business owner | Person Five—SVP Sales (product owner) |
| Sponsors | Person Six—EVP Business Unit A | Person Seven—CFO |
| Prepared by | Person One | Person Two—Example Sender GmbH |
| Status | Draft for discussion |
The monthly rolling demand forecast works, but it runs on a shared Excel file. The process is slow, error-prone and gives limited visibility of risk, anomalies and bias—and the resulting volume forecast is the basis of the financial forecast. We propose a focused pilot: replace the collection step with a proper application, put an AI intelligence layer on top of the collected and historical data, and deliver in monthly increments starting at one plant. Two elements are worth noting for IT: the structured data collection is needed regardless of any later tool or platform decision, and the AI layer is designed to be reusable elsewhere through documented, AI-readable interfaces.
1. Starting point
The rolling forecast process was established in the first quarter of 2026 and has now run for roughly six monthly cycles. The process itself is accepted and working; the tooling around it is not.
- Forecast input is collected in one shared Excel file. With several users at once it becomes slow, and account managers overwrite each other’s rows.
- Consolidation is manual and repeated every month, which is where most of the effort and most of the errors sit.
- Forecast quality varies by person. Individual bias is visible—and predictably strongest during the budget season—but there is no systematic way to detect or challenge it.
- Customers’ own forecasts are sometimes implausible, and there is no mechanism to flag that before it enters the numbers.
- There is no consolidated orders-on-hand view. Plants A and B maintain their own dashboards; the other plants deliver Excel and PDF. Building one picture today means pulling from five sources.
- Reconciling the volume forecast with the EBITDA forecast consumes hours every cycle that should be spent with customers.
Today’s forecast is made on customer and product group level, with product subgroup added for the last two cycles. Mix effects—customer mix and product mix—leave a residual blur that limits how good the financial forecast can get.
2. Objectives
Two goals, in this order of visibility but of equal weight:
- Usability. Make the monthly forecast materially easier and faster to produce, with each account manager seeing only their own scope.
- Accuracy. Raise demand-forecast quality so it becomes a dependable basis for the financial forecast—including making bias and forecast error visible and measurable.
A secondary objective, and one the business rates highly: a single consolidated orders-on-hand view. If parts of that data already exist centrally, so much the better—it is a welcome addition rather than the driver of the project.
3. Scope
This is a demand-forecasting and commercial decision-support project. It is deliberately not a planning platform.
| In scope | Out of scope for now |
|---|---|
| Structured collection of the monthly volume forecast | Supply, capacity and inventory planning |
| AI-supported baseline forecast and anomaly detection | A full S&OP platform—the running S&OP initiative stays untouched |
| Forecast-quality, bias and accuracy reporting | Site selection and cross-plant load optimisation |
| Consolidated orders-on-hand view | Group-wide process standardisation across divisions |
| Documented interfaces for export and agent access | Replacing any existing system in a single step |
Why one business unit and not the group: the second unit needs to link demand with supply and capacity planning in order to steer site selection. Business Unit A cannot move products freely between sites, so demand forecasting alone already delivers the value. The second unit confirmed that the forecasting process itself does not transfer, while the AI capabilities are of clear interest.
4. Solution in three layers
It is worth being explicit that this is not “move an Excel file into a dashboard”. Three distinct layers sit on top of each other, and only the third is reporting.
Data collection and consolidation
Replaces the shared Excel file. Per-user scope and access rights, no overwriting, automated consolidation, full history. Input via a web front end, or via per-plant Excel templates that are uploaded and parsed—whichever suits the site. Where data can be read from existing systems, it is read rather than typed.
AI and mathematical intelligence layer
A statistical baseline forecast from history, order patterns and context; classification of combinations into stable and volatile; anomaly, outlier and bias detection; reason codes captured on every manual correction, which feed back into the next cycle. The estimate is that roughly 70 per cent of combinations can be confirmed against an AI baseline. The methodology itself is our IP and is treated as a closed component—but its outputs are transparent: it flags an issue, shows the evidence, proposes an action, and the user confirms, adjusts or explains.
Views, reporting and agent access
Role-specific views (account manager, regional sales manager, plant, management), forecast-accuracy and bias dashboards, the consolidated orders-on-hand view, Excel export, and an optional dashboard connection on the same data. In addition a documented API and an MCP endpoint, so licensed users of an approved agent can query the data in natural language and receive explanations.
5. Technical footprint
Deliberately small, and inside the client’s own environment. Nothing below is fixed—it is the intended shape, to be confirmed with Group IT.
- Hosting: a client-owned cloud tenant. No client data on our infrastructure beyond what is needed for development, under NDA and a data-processing agreement.
- Application: one custom web application, authenticated against the client’s identity, with role and site-level access rights.
- Storage: a small relational database in that tenant holding the collected forecast tables, the imported history and the reason codes. A working store for one process, not a second data warehouse.
- Integration: read-only access to source systems where available; file import where not. Outbound via API, Excel export and an optional dashboard connection.
- Agent interface: an MCP server with a documented API definition, so an approved agent can be connected as a client without opening the data to anything else.
On agents: the agent interface is designed as an option for those who have a licence, not as a dependency of the solution.
6. Data requirements
This is the section we expect to be most relevant for Group IT, and the one where we most want input. Our preferred path is to use data that already exists centrally, and to fall back on manual collection only where it does not. Manual collection is explicitly not a blocker for starting.
| Data object | Source today | First increment |
|---|---|---|
| Sales history and actuals by customer, product group, site | Controlling | One-off extract, then periodic refresh |
| Current monthly volume forecast | Shared Excel file | Entered in the application; the existing file’s fields define the input parameters |
| Orders on hand | Site-level dashboards, Excel and PDF elsewhere; possibly available centrally | To be assessed with Group IT—central source strongly preferred |
| Budget and prior-year figures | Controlling | Periodic extract |
| Customer, product and site master data | ERP—heterogeneous across plants | Minimum viable list for the pilot plant only |
| Business context (reasons, projects, one-off events) | In people’s heads and in email | Captured as reason codes and free text in the review step |
Two points we want to align on early:
- If a meaningful share of this data already exists centrally, the scope should shift accordingly—less collection, more AI enhancement on existing data. We would rather redefine the first increment than build a parallel store for data the client already holds.
- The ERP landscape is diverse and largely unharmonised. We therefore do not propose automated integration as a precondition; automation is added per source where it pays off, not up front.
7. AI, sovereignty and security
- Data stays with the client. Processing takes place in the client tenant. No forecast or customer data is sent to third-party AI providers as part of normal operation.
- No training on client data by us or by any external provider. Where a language model is used, it is used under an agreement that excludes training, in a European region—or as a local model where the data must not leave the machine.
- A lean, specialised algorithm rather than a general-purpose platform. The baseline and anomaly logic is deterministic and auditable in its behaviour; the methodology is our IP.
- Explainability by design. Every flag carries its evidence, every manual override carries a reason code, and both are stored. Users can ask why a proposal was made.
- Access control. Site- and role-level separation from the first increment, since plants do not see each other’s data today and should not start to.
- Human decision, always. The system proposes; the account manager decides. No forecast is submitted without a person confirming it.
8. Delivery approach
Monthly increments, not a big bang. The project runs alongside the live forecast cycle, so every increment is used in a real month rather than demonstrated in a test.
| 01 | Start at one plant—Plant A is the proposal, as the main hub. Data capture live, plus a dashboard fed from aggregated figures for the other plants. |
| 02 | Deliver a usable improvement each month, reviewed with the users who actually run the cycle. |
| 03 | Measure practical value against agreed indicators: time per cycle, error rate, adoption, forecast accuracy and bias. |
| 04 | Refine scope, granularity and data sources with the site. Determine how deep the forecast needs to go—subgroup or SKU level, consolidated back up to product group for the sales team’s review. |
| 05 | Extend to further plants only where evidence supports it. Stop-or-go after every cycle—no long commitment, and nothing built that has to be discarded if priorities change. |
The agile structure exists partly for exactly this reason: if a group-wide AI or S&OP direction consolidates elsewhere, the data collection and the interfaces remain useful and the project can attach to it rather than being thrown away.
9. Relation to other initiatives
- The S&OP pilot. Different scope: demand and supply, capacity and resource planning down to machine level. This project touches none of it and makes no claim on it. If that programme extends later, a documented demand-forecast source with an API is an asset to it, not an obstacle.
- Forecasting in the second unit. It keeps its own tools, data structures and planning initiatives. The forecasting process does not transfer; the AI capabilities may. A short, structured discovery is the sensible way to test that—and it is not a prerequisite for starting.
- Group AI agenda. The AI layer is built behind documented, AI-readable interfaces precisely so that a future group-level agent or assistant can query this process without a rebuild.
10. Team
A small, senior team—contracted and invoiced through Example Sender GmbH.
- Person Two—digital and AI strategist. Partnership, strategy and contract; delivered the keynote and ideation session from which this use case emerged.
- Person One—co-founder and CTO of a data company. Delivery lead; systems in production at several industrial groups.
- Other parties as needed—senior project manager, finance business partners in the network.
11. What we are asking for
A green light to start with the first increment—structured data collection at one plant, together with the AI intelligence layer—on a monthly stop-or-go basis.
Openness to reuse the AI layer elsewhere later, explored separately and at the group’s own pace. Not a condition of the start.
Concretely, the next steps as we understand them:
- This document plus the supporting material goes to Group IT for the intake, the security questionnaire and the AI-solution assessment. We will pre-fill both questionnaires and answer follow-ups directly.
- We prepare a field-level data requirement list, derived from the existing Excel file’s input parameters, so Group IT can identify what already exists centrally and what would remain to be collected.
- A short technical session with Group IT on source systems and access, including whether orders-on-hand data can come from a central source.
Nothing in this document implies that the architecture, data sources or deployment model are agreed. The demo shown is an illustrative concept, not a product. What we are asking to fix now is the direction and the first month—deliberately small, deliberately reversible.