Your first manufacturing AI pilot should start on the shop floor

A small AI pilot can still test the wrong problem. Limiting the budget helps, but it does not tell you whether the proposed workflow reflects how your factory actually operates.

In Episode 2 of AI in Swiss Industry, Camille Sickert asks Stéphane Fallet what the smallest useful test would be for a company that wants to explore AI without taking too much risk. His answer connects two practical ideas: choose a precise use case that the team can control from beginning to end, and visit the operation before designing it.

Watch the published short on LinkedIn. French recording; English article.

01 Observe the work before choosing the model

A process map shows the intended workflow. Discovery checks what happens when that workflow meets an ordinary working day.

Follow a production-planning decision from its trigger to its outcome. A buyer may keep a separate supplier update. A planner may override a lead time because the system value is stale. A production manager may know that a nominally available machine cannot perform a particular operation. Each detail changes what a useful assistant would need to know.

Stéphane describes an on-site discovery involving two or three engineers over one to three weeks. That is his description of an approach in the webinar, not a fixed requirement or delivery commitment for every company. The duration should depend on the process, access and people involved.

The underlying principle also appears in the Lean Enterprise Institute’s definition of genchi genbutsu: confirm understanding through direct observation where the work happens. Applying that principle to AI means checking the information and decisions behind a proposed use case before investing in its automation.

Discovery should produce a decision map, a list of information sources, named owners and a record of the workarounds the pilot must account for. It may show that a clearer rule or a data correction is more useful than an AI model. That is a useful finding, not a failed AI project.

02 Define one complete decision

“Improve production planning” is too broad for a first pilot. “Help the planner review orders affected by a confirmed supplier delay” gives the team something concrete to test.

Specify the trigger, inputs, output and person who acts. The trigger might be an updated delivery date. Inputs could include affected purchase orders, usable inventory and the current production schedule. The output could be a list of orders requiring attention, with the assumptions behind each proposed option. The planner remains responsible for changing the schedule.

This is what controlling a use case end to end means in practice. It does not require connecting every system in the company. It requires following one selected problem far enough to know whether the output helps the person who must resolve it.

Write down exclusions as carefully as the task itself. The first version might prepare options but never issue purchase orders, change customer commitments or write to the ERP. Those boundaries reduce the number of consequences that must be controlled during the test.

For the earlier step of selecting a problem, see our AI opportunity assessment. The pilot brief begins once the team has a candidate worth investigating.

03 Separate a demonstration from an operational test

A demonstration shows that a system can produce an appealing answer for selected inputs. A pilot examines whether that answer remains useful under representative working conditions.

Include the cases that make the job difficult: incomplete records, conflicting dates, a changed order and a constraint known only to another team. A system that recognises missing information may be more useful than one that confidently fills the gaps.

Check each part of the proposed workflow separately. Did it identify the affected orders? Did it use information available at the decision time? Did its explanation match the calculation? Could the planner understand what still needed confirmation? A persuasive summary cannot compensate for an infeasible plan.

Also compare the proposal with a simpler alternative. If an existing report and a clear escalation rule solve the problem, that is the relevant benchmark. The pilot should establish the value of the additional capability, including the effort needed to maintain it.

04 Build a baseline the team can trust

Before the test, document how the selected decision is handled now. Record what information people gather, where delays occur, how much review is needed and how the decision is eventually applied.

Choose measures that reflect the use case. For a supplier-delay assistant, useful observations could include missed affected orders, recommendations needing correction, time spent assembling the evidence and time spent reviewing it. Track preparation and review separately so that a faster first answer does not conceal more checking later.

Where operational outcomes matter, identify how they will be measured and what else can influence them. A missed delivery can depend on inventory, staffing or a later disruption. It should not automatically be attributed to the recommendation alone.

Agree on the comparison before seeing results. Use the same definitions and comparable cases for the existing process and the proposed workflow. Preserve the information available at the time rather than giving the new system hindsight that the original planner did not have.

A small sample may reveal obvious problems without establishing a reliable business case. Report that distinction. Finding a missing capacity constraint is valuable evidence for another iteration, even when there are not yet enough cases to estimate a durable benefit.

05 Keep the first test reversible

For an initial decision-support pilot, a practical option is to run the proposed workflow alongside the existing process. The assistant prepares its output while the authorised team continues making operational decisions.

Restrict access to the information the task requires. Use approved environments, define who can inspect the output and establish what happens when the input is incomplete. If the test must change a live system, assess that authority separately rather than treating it as a routine extension of a read-only demonstration.

The NIST AI Risk Management Framework is a voluntary resource for considering trustworthiness throughout AI design, development, use and evaluation. For this pilot, the practical application is to identify consequences before deployment and give someone responsibility for managing them. Using a framework does not itself certify the pilot as safe.

An explicit stop condition makes the boundary usable. The team might stop the trial if an output exposes information to the wrong role, repeatedly omits a critical constraint or cannot be traced to its input records. Define how the normal process continues if the trial is paused.

06 Shorten the learning loop

Stéphane’s second operational recommendation is to reduce the time between the first iteration and checking whether it works and adds value. That does not mean rushing past the work needed to evaluate it.

Start with a narrow output that can be reviewed. For example, first test whether the assistant identifies the affected orders correctly. Then assess whether it can assemble the relevant constraints. Only after that should the team invest in more elaborate option comparison or execution features.

When a reviewer rejects an output, record why. A stale stock figure calls for a different fix from an invalid scheduling rule. A poor explanation may require a presentation change rather than a new prediction model. Classifying the problem keeps the next iteration focused.

Retest the case that exposed the issue, together with other representative cases. A correction is useful when it improves the workflow without breaking something else. A single improved demonstration is not enough to establish that.

07 Decide whether to expand, revise or stop

The pilot should end with a decision, not merely a presentation. Compare the observed results with the acceptance criteria, including the review burden and unresolved risks.

Expand when the team has evidence that the workflow is useful and knows what maintaining it requires. Revise when a specific, addressable problem limits value. Stop when the use case is poorly chosen, the required evidence is unavailable or a simpler solution is preferable.

Before expansion, name the operational owner and the people responsible for data quality, support and changes. A workflow that only its original developer understands is not ready to become an everyday dependency.

For the planning example, the next step might be another product family or a wider set of disruptions. Change one meaningful boundary at a time so the team can understand what caused the next result. Success in one process does not establish suitability across the factory.

08 Questions before your first AI pilot

What is the smallest useful test?

One recurring decision with defined inputs, a reviewable output and a named owner. It must be narrow enough to control and complete enough to show whether the output helps someone act.

Do we need a complete data transformation first?

Start by checking the data required for the chosen decision. Some problems can be addressed within that scope; others reveal dependencies that must be resolved first. Neither assuming all data is ready nor demanding a company-wide overhaul is a substitute for that check.

How long should it take?

Agree on a timebox that includes access, implementation and enough representative cases to evaluate the result. The webinar favours a short feedback loop, but it does not establish one universal pilot duration.

What should we bring to the first conversation?

Bring a recent decision that was difficult to resolve, the records available at the time, the people involved and the outcome. That gives discovery a concrete starting point.

Explore our method or book an AI assessment to identify a bounded test grounded in how your operation actually works.