Scaling AI in manufacturing: what changes at plant two?
The pilot reduced overtime at one factory. Before rolling it out, check whether the next plant has the same problem, the same data and enough savings to cover the work.
An AI application helps a packaging team find recurring faults. The team fixes them, overtime spending falls, and management wants to put the application in the other factories.
At the second plant, the fault records look familiar. The columns even have the same names. But a stop code includes events that the first plant records separately, and the supervisors have less time to investigate warnings.
Copying the software is straightforward compared with checking all of that. The question is whether it can help this plant enough to justify the cost of using it.
That's the difficulty with scaling AI in manufacturing. A successful pilot gives you a place to start. You still have to find out which parts of its success will travel.
What did the pilot actually prove?
Deloitte's 2026 manufacturing AI survey, covering more than 140 manufacturing organisations, reports that 84% see measurable AI value. Around one in five use cases has scaled consistently across sites or the enterprise.
These measure different things: finding value somewhere and repeating it elsewhere. An application that stays at one plant may still be worth having.
Take the packaging application. In our fictional example, Plant A cuts annual overtime and rework spending by €60,000. Support costs €12,000 a year, and the team can trace the spending reduction to the changes it made.
Plant B has shorter production runs. Its operators already catch some of the faults A needed help finding. Even with the same model, there may be less spending left to reduce.
Before putting A's saving into B's proposal, find out what B currently loses and what people there could do differently.
The same stop code can mean different things
At A, the label STOP means an unplanned breakdown. At B, it also includes planned changeovers.
An analysis copied from A could treat those changeovers as breakdown losses. The model would then be investigating a problem that the records have partly invented.
Start with a few events people remember. Compare the log with what happened on the floor, then agree which events belong together. Vrolen's downtime tracking guide covers how to define those records, including the difference between where a stop began and which machines it affected.
The same check applies to the action that follows a warning.
| At the pilot plant | Before using it at the next plant |
|---|---|
| A fault pattern appears in the records | Check that the same fault happens and is recorded the same way |
| A supervisor acts on a recommendation | Check who can act, including on nights and during short runs |
| Overtime and rework spending falls | Identify comparable spending that this plant could actually reduce |
| An operator checks doubtful recommendations | Allow time for that work and decide who handles an unresolved case |
| The application connects to the line's systems | Price the local connections and their ongoing support |
NIST's 2026 smart manufacturing roadmap identifies differences in industrial data and sensing and control systems as deployment challenges. A shared column name doesn't remove those differences.
What plant two does to the business case
Suppose the review puts B's annual spending reduction at €30,000. B also needs €30,000 of local setup, compared with €10,000 at A.
The shared application costs €40,000 to develop once. Both plants need €12,000 a year in support.
For this comparison, give each plant a full operating year after launch and charge setup against that year. The figures are fictional.
| Input | Plant A | Plant B |
|---|---|---|
| Annual overtime and rework saving | €60,000 | €30,000 |
| Annual support | €12,000 | €12,000 |
| Local setup, paid once | €10,000 | €30,000 |
| First-year balance before shared development | €38,000 | −€12,000 |
Including the €40,000 shared development cost, the two plants finish that first operating year €14,000 short of covering the project costs.
Copy A's saving and setup cost into B, though, and the proposal shows €36,000 left over. That is a €50,000 difference without changing anything about A's result.
Fictional two-plant example
Try the rollout with B’s numbers
Keep A fixed and change B's saving and setup cost. Compare that with copying A's assumptions.
Both plants: first operating year−€14,000After shared development and both setups.
Adding B: first-year balance−€12,000Assumes shared development is already paid.
Annual benefit and recurring support versus one-time spending, in euros. Hover, tap or focus a bar for its breakdown.
Plant A €60,000 + plant B €30,000.
How this is calculated
Each plant receives a full operating year after launch. Setup is charged once against that year. The saving represents reduced overtime and rework spending. The example excludes launch delays, tax, discounting, resale value and overlapping benefits.
| Measure | Plant A | Plant B |
|---|---|---|
| Annual cash reduction | €60,000 | €30,000 |
| Annual support | €12,000 | €12,000 |
| One-time local setup | €10,000 | €30,000 |
Shared development: €40,000, counted once. Combined first-year balance = annual cash reductions − €24,000 support − €40,000 shared development − €10,000 A setup − B setup. Combined recurring annual balance before new setup spending: €66,000.
The first-year shortfall doesn't automatically make this a bad investment. On these inputs, the plants together save €66,000 a year after recurring support. The decision also depends on how long the application remains useful, when the savings arrive and what further work it needs.
There is another distinction if A is already running and its development bill is paid. Adding B then means judging B's future saving against its additional setup and support. Don't charge B for the shared build all over again.
Here, savings mean expenses that fall. If the application instead releases staff time, the automation benefits note explains what has to happen before that becomes money the company stops spending.
Try it on B's difficult work
A test on B should include the conditions that differ from A: shorter runs, different products and shifts with fewer people available to act.
Run recommendations alongside the existing process first. Keep the recommendation, what the supervisor did with it and why. If the suggestion was correct but nobody could act before the run ended, the test has found something the rollout must solve.
For a change worth trying, agree how to check the result. Compare similar products and volumes, record other changes made at the same time, and look for the spending reduction the proposal depends on.
A low override count is a poor substitute for that review. An operator who stops a bad recommendation may be doing exactly what the process needs.
What should become easier at plant three?
After B, the team should know which code, data definitions and checks it can reuse. It should also have a more realistic estimate of the local work: connections, training, support and changes to the way people respond.
That is part of what I'm building Vrolen around: keeping the operating problem, the evidence, the proposed change and the result connected.
Before approving plant three, ask the team to show how B's actual result compared with its proposal. If B took twice the setup effort and delivered half the expected saving, that belongs in the next estimate, even if A remains a success.
Sources
- Deloitte. AI in Manufacturing 2026. Survey of more than 140 manufacturing organisations. Reported AI value and consistent scaling are different measures.
- NIST, 3 July 2026. 2026 Roadmap on Artificial Intelligence and Machine Learning for Smart Manufacturing. Industrial data and system differences.
Plants A and B, their results and costs are fictional. The comparison assumes a full operating year at each plant, no launch delay, no overlapping benefits, no tax or discounting, and spending reductions attributable to the changes. Calculation details are available below the interactive example.