Namche
Documents

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.

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.

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.

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.

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

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.