AI Demand Forecasting in Manufacturing: From a Better Forecast to a Better Production Plan

A production forecast can look reasonable at the end of the year while the factory spends the year fighting it. Purchasing expedites material. Production reshuffles work. Customer service explains another delay. Each team sees part of the problem, but the planning meeting may still begin with a reassuring aggregate number.

AI demand forecasting in manufacturing is useful when it helps people make better decisions before those costs accumulate. A more sophisticated forecast is only one part of that work. The business also needs current information, a feasible production plan and people who can act on exceptions.

In Embiggen X’s French-language webinar, Camille Sickert discusses this challenge with Stéphane Fallet and Nicolas Souvlakis. Their conversation moves from the hidden cost of static forecasts to the practical question of how to test AI in a real operation. This English article develops those ideas into a planning framework. The examples and checklists below are editorial illustrations, not reported customer results.

01 Watch the webinar

Watch “IA dans l’industrie suisse: Optimiser la planification coûte cher” below. The recording is in French; this article provides an English explanation. Local transcript timestamps may differ slightly from the YouTube edit.

The discussion covers why a forecast becomes outdated, what information a manufacturer already has, how an AI assistant can support a planner, and how to compare a small pilot with the existing process. Its central question is practical: which planning decision could your team improve without trying to rebuild the whole business first?

02 Why an accurate total can still produce an expensive plan

Imagine a manufacturer expecting demand for 400 units over four weeks. Its plan assumes 100 units each week. Actual demand is 160, 120, 80 and 40 units. Both totals equal 400, but the first two weeks require more product than the plan supplies. Depending on starting inventory and capacity, the team might face shortages, overtime or expensive changes to the schedule.

This is an illustrative example, not a forecast-error calculation or a claim about a customer. It shows why a correct total does not establish that the forecast was useful at the time decisions had to be made. The period, product family and lead time used to judge performance must match the decision the forecast supports.

The webinar opens with another source of cost: information changes after a forecast is made. A new order arrives, a machine becomes unavailable or a supplier revises a delivery. A forecast that was defensible yesterday may no longer support today’s production priorities. Better visibility matters only if it arrives before the team loses its opportunity to respond.

Start by following one recent disruption through the business. What changed? When did someone first know? When did planning see it? Which commitments were already fixed by then? Those questions reveal whether the immediate problem is forecasting, information delay, capacity or decision ownership. Buying a forecasting model before answering them can leave the real constraint untouched.

03 Separate demand forecasting from production planning

Demand forecasting estimates what customers are likely to need over a defined horizon. Production planning decides how to respond within material, equipment, labour and delivery constraints. A forecast can inform that plan without making it feasible.

For example, a stronger demand signal does not create an available machine slot. A plausible prediction of next month’s orders does not resolve a supplier’s minimum order quantity. And a lower average error does not tell a planner which customer commitment to protect when two jobs compete for the same resource.

Make the decision explicit before choosing the technology. “Improve forecasting” is too broad for a first project. “Help the planner compare feasible schedules for one product family after a supplier delay” names an event, a user, a bounded process and a decision. It also identifies information the solution must have beyond historical sales.

Forecasting research provides a useful discipline here. Hyndman and Athanasopoulos recommend evaluating predictions on data not used to fit the model and comparing them with simple benchmark methods. Their discussion of prediction intervals also makes uncertainty visible rather than presenting one number as certain. These principles help test a forecasting component; they do not, by themselves, prove that the resulting production decisions are better. Forecasting: Principles and Practice

04 Connect the information needed for one decision

In the webinar, Nicolas challenges the assumption that a manufacturer must have perfectly structured information before it can begin. Relevant context may already exist in ERP records, spreadsheets and documents. The first task is to locate the information required for a specific process and decide whether it can be used reliably.

That does not mean data quality stops mattering. Reading a spreadsheet or extracting a delivery date from a PDF is different from knowing that the date is current, approved and attached to the correct order. An assistant that combines two incompatible product identifiers can produce a polished explanation of the wrong situation.

For a first planning use case, inventory these sources:

• Order history and open orders, with cancellations and unusual demand identified.
• Available inventory and committed stock, using agreed definitions.
• Supplier lead times and delivery updates, including who maintains them.
• Production capacity, planned downtime and relevant scheduling restrictions.
• Planner knowledge about exceptions, customer priorities and decisions that need approval.

Record the owner, update frequency and known limitations of each source. Ask which information is authoritative when records disagree. Define what the assistant should do when a critical input is missing: flag the gap, request confirmation or decline to recommend a change. Silently filling a missing value is a poor substitute for an agreed operating rule.

Our DataCore product page explains the connected-data part of Embiggen’s approach. For this article’s planning framework, the important principle is narrower: connect the evidence needed for the chosen decision and retain a way to trace it back to its source. Integration scope and access still need assessment.

05 Treat the AI assistant as a new planning colleague

Nicolas uses a helpful analogy in the webinar: consider the assistant a new employee. It may help organise information quickly, but it still needs to learn the organisation’s vocabulary, constraints and expectations. The analogy is a way to design onboarding, not evidence that a system understands the business like a person.

A useful first assignment could be preparing an exception brief. Following a delivery change, the assistant gathers affected orders, identifies which inputs are uncertain and presents options for the planner to review. Each option should explain its assumptions and the constraints it respects. The output should make the next discussion easier, rather than require the planner to reverse-engineer a recommendation.

Give that assistant a written job description. Specify which sources it may read, which decisions it may recommend and which actions it cannot take. Identify who checks its work and how an error is reported. Changing a production order, notifying a customer or committing to a supplier should require whatever authorisation the business has defined for that action.

Feedback also needs a mechanism. When a planner rejects a recommendation because of a missing constraint, record the reason and update the relevant rule or configuration through a controlled process. Do not assume that the model automatically learns from every correction. Whether feedback changes future behaviour depends on how the system is built and maintained.

06 Keep the planner responsible for the trade-offs

The webinar frames AI as support for the planner rather than a reason to remove the role. The work may shift from gathering and reconciling information towards coordinating decisions across purchasing, production and customer-facing teams. That shift is useful only if the planner can inspect and challenge the recommendation.

Consider two feasible responses to a late component. One preserves a major customer’s delivery but requires a schedule change. The other avoids disruption on the line but delays that customer. The assistant can assemble the evidence and show the consequences that its inputs allow it to calculate. Management priorities, relationships and exceptions still need an accountable decision-maker.

A practical review should ask three questions: which inputs support this option, which constraints were applied, and what has been left out? If the system cannot answer, apparent speed may create extra checking work. Measure that checking effort as part of the pilot, rather than treating the time needed to generate an answer as the whole benefit.

Give planners an explicit route to disagree. Capture overrides and the reasons behind them without treating every override as a failure. Sometimes the model missed something; sometimes the operating rule changed. Both are valuable evidence about what the system needs before its scope expands.

07 Start with one product family and a parallel test

Stéphane recommends understanding the operation before implementing a first use case. Observe how an actual planning decision moves between people and systems. Find the spreadsheets that sit beside the ERP, the approvals that happen informally and the exceptions that make a supposedly standard process different in practice.

Then select a product family or decision with a manageable boundary. Look for a recurring planning problem, accessible evidence and an owner who can assess the result. A pilot covering every site and every product is difficult to diagnose. A demonstration on a perfectly clean but unrepresentative sample can be equally misleading.

Nicolas describes a six-to-eight-week parallel test as an example in the discussion. That is not a universal implementation timeline. Data access, integration, operational complexity and how often the decision occurs all affect what can be learned in a given period. A process with very few relevant events may need a different evaluation design.

In a parallel test, the existing process remains responsible for operations while the proposed assistant prepares recommendations for comparison. Record what information was available at the decision time. If you later evaluate the assistant using facts that only became known afterwards, you are giving it an advantage the planner did not have.

Keep a decision log: the situation, baseline response, assistant recommendation, reviewer comments and observed outcome. Where recommendations were not implemented, distinguish a proposed benefit from a realised result. A plausible alternative schedule is not proof that the business would have achieved the projected saving.

08 Measure business outcomes alongside forecast quality

Agree success criteria before the pilot begins. Otherwise, a persuasive demonstration can become the success criterion after the fact. Choose a small set of measures that reflect the original problem and can be collected consistently.

• Forecast performance at the product level and horizon used by the planning decision.
• Time from receiving an exception to preparing a reviewed response.
• Review effort, including time spent correcting or investigating recommendations.
• Schedule changes, expedites or service outcomes relevant to the chosen use case.
• Missing-data incidents, constraint violations and reasons for planner overrides.

These are candidate measures, not a promise that all will improve together. Faster decisions may require more review initially. A service improvement may involve an inventory trade-off. Define which outcome matters most and which guardrails must not deteriorate, then have the appropriate business owner agree to those choices.

Maintain a clear comparison. Use the same definitions and comparable cases, and document changes in demand, staffing or supplier performance that could explain the result. A short pilot can provide useful operational evidence without proving a general causal claim or a return that will hold across every product family.

The expansion decision should therefore be specific: does the evidence justify using this assistant for this process under these controls? If yes, extend deliberately. If not, decide whether the problem is input quality, the recommendation logic, integration, adoption or the use case itself.

09 Give the pilot a business owner

The closing discussion returns to management responsibility. Planning affects service, working capital and production commitments, so the project needs someone who can resolve trade-offs across departments. IT and data specialists are essential partners, but they cannot decide those business priorities alone.

Name an operational owner who understands the decision, a technical owner responsible for access and reliability, and a sponsor who can resolve competing priorities. Include the planners who will use the system when defining the scope and evaluating outputs. Their participation should begin before the interface is finished.

Also decide who maintains the process after the pilot. Product codes change, suppliers change and old exceptions become new rules. A recommendation system without maintenance ownership can gradually diverge from the business it is meant to support. Review responsibilities, escalation routes and permission boundaries should survive the initial project team.

For the broader management question, see why enterprise AI transformation needs leadership ownership. This webinar’s contribution is to bring that principle down to a concrete planning decision that can be observed, tested and improved.

10 Questions before you start

Do we need to replace our ERP?

That should not be the default assumption. First identify the information and decision support missing from the current workflow. The assessment may reveal a connection, reporting or planning gap that can be addressed alongside existing systems. Feasibility depends on access, integration and the process itself.

Can AI work with spreadsheets and PDFs?

These can be useful inputs, but format compatibility is only the beginning. Check extraction quality, definitions, freshness and permissions. A document that can be read is not automatically a dependable source for a production decision.

Will an AI assistant replace our planner?

The approach discussed in this webinar keeps the planner involved in reviewing options and coordinating action. Design the pilot around a specific task and measure the review work as well as the analysis it saves. Do not infer a staffing outcome from a successful demonstration.

What should we test first?

Choose a recurring, bounded decision where the current difficulty and its consequences are visible. One product family affected by supplier delays is an example, not a universal recommendation. Start with the operational problem you can observe and measure.

11 Choose the decision before the model

The strongest starting point for AI demand forecasting in manufacturing is a question your team already needs to answer: what should we change when demand, supply or capacity moves? Work backwards from that decision to the required information, constraints and authority.

A useful first project makes those connections visible. It helps the planner examine options sooner, keeps assumptions open to inspection and produces evidence that management can use to decide what comes next. A better forecast matters when the operation can turn it into a better response.

Discuss one planning workflow with Embiggen X and assess what a bounded test would require.