Knowledge Base

Why Factory AI Fails Without Connected Operational Data

DBR77 Team7 min read

On this page

Factory AI fails without connected operational data because a model can only rank, predict or recommend from what it can see. In most plants the facts it needs sit in separate systems, with different machine IDs, missing stop reasons and no record of what people did afterward. Before AI can help, a plant needs trusted machine events, a shared model of assets and orders, closed records of actions, and a route that brings each recommendation back to a person who can act on it.

The AI budget is often spent before anyone checks the data, and the model gets blamed for a problem upstream.

Why AI pilots in plants stall

The failure rate is high across industries. A 2024 RAND study based on interviews with 65 AI engineers and researchers notes that, by some estimates, more than 80% of AI projects fail, twice the rate of IT projects without AI. One of the five root causes it names is that the organization lacks the data needed to train an effective model, and 30 of the 50 industry interviewees described persistent data quality problems.

Gartner makes a similar point from the data side. It predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data, and 63% of organizations either do not have, or are unsure if they have, the right data management practices for AI.

In a plant, a data scientist typically gets a one-time export: sensor values from one system, work orders from another, scrap from a spreadsheet. The model scores well on that history, then goes live and changes nothing, because live data does not match the export and the output lands in an email nobody owns.

A model on exported vibration data flags compressor 2 for bearing wear.

Comparison of one compressor bearing warning handled by a model on exported data and by a connected flow

Five kinds of data operational AI needs

Operational AI needs to know what a value belongs to, what people did about it, and what happened next.

Data typeExampleWhere it often lives todayWhat fails without it
Machine eventsStates, counts, stop reasons, condition valuesPLC, SCADA, a separate IoT toolThe model sees numbers but not stops or causes
ContextAsset ID, work order, product, material lot, shift, roleMES, ERP, spreadsheetsA warning cannot be tied to an order or a batch
Actions and outcomesWork orders, inspections, non-conformances, closure notesCMMS, quality forms, paperThe model never learns which advice worked
PlanSchedule, changeovers, material availabilityAPS, ERP, the planner's own fileA good fix is suggested at the worst time
Know-howSOPs, maintenance logs, past root causesShared drives, binders, people's headsAnswers are generic, not about your plant

Label quality matters as much as volume. In a Chalmers study of raw OEE data from 23 companies and 884 machines, almost half of recorded losses could not be classified because loss categories were missing or poorly described. A model trained on "unknown" learns nothing useful. For which machine signals are worth collecting in the first place, see What Data to Collect from Machines.

Why the flow matters more than the volume

Many plants answer the data problem with a data lake, which helps reporting but collects data without returning a decision to the floor. Operational AI needs a loop: event in, recommendation out, a person accepts or rejects it, the action is recorded, and the result comes back as new data.

Illustrative example: a plant runs four air compressors. A predictive model, built on exported vibration data, flags compressor 2 for bearing wear and sends a weekly PDF to the maintenance manager. The CMMS is a separate system, so nobody links the warning to a work order. A technician replaces the bearing on Thursday during a planned stop and writes "noise, replaced bearing" on paper. Three weeks later, nobody can say whether the model was right, early or lucky, and trust in it drops.

In a connected flow, the same warning opens a recommendation tied to the asset ID. A planner approves it as a work order, the technician closes it with findings and a photo, and the closure returns to the model as a labeled outcome. The model is the same in both versions, but only the connected one receives labeled outcomes it can learn from.

A readiness test for one line

Run this yes or no test on one line before you buy or build any AI.

  1. One asset list. The same machine has the same ID in machine data, maintenance and production.
  2. Stops have reasons. "Unknown" is a small share of downtime minutes, and the reason list has been stable for weeks.
  3. Events carry context. A stop or a defect can be tied to an order, a product, a material lot and a shift without a manual lookup.
  4. Actions are closed in a system. Work orders and quality actions have a closure record with what was done, not only a status.
  5. Someone owns each output. Every type of recommendation has a named role that receives it and a time to respond.
  6. There is a way back. The result of an action is stored where the model can read it.

If four or more are "no", spend the next quarter on data and flow, not models. Often the fastest route is to connect existing systems; How to Unify MES, WMS, QMS and CMMS Without Replacing Everything shows how.

How this works in DBR77 IRIS

DBR77 IRIS runs production, maintenance, quality, warehouse and planning on one shared data model, so machine events, orders, inspections and work orders are already linked when AI reads them. Machine data comes from DBR77 IIoT: incoming telemetry is checked against defined schemas and normalized, devices are attached to stations, and IRIS CMMS maps each station to its asset.

The IRIS assistant works from that shared record. It answers questions from live plant data and from knowledge bases built from your machine documentation, maintenance history, processes and products, and every number in an answer comes from a tool that read your data. Data & AI recommendations show the basis for their score, a person decides what happens to each one, and IRIS records the outcome of those that are applied. Where failure history is thin, DBR77 DT can generate simulated data. Once this base exists, What AI Can Really Do in Factory Operations Today sets out what AI can and cannot do.

FAQ

Do we need a data lake before we start with AI?

Not for operations. Operational AI needs connected live events, context and closed actions on the lines where you want results.

How much history does a model need?

It depends on the use case. Ranking open issues or answering questions from SOPs can start with little history. Predicting rare failures needs labeled examples, which is why closure records matter from day one.

Can we use the data we already have?

Usually yes, once it is linked. Most plants have the raw data; what they lack is one asset ID, clean reasons and closure records.

Does our data have to leave the plant?

Not if your policies forbid it. IRIS can run in a private cloud or in your own data center, and in SaaS each factory's data is kept separate. Agree during the pilot where the language model behind the IRIS assistant runs.

Conclusion

Before you fund a model, run the six-point readiness test on one line. If four or more answers are "no", spend the next quarter connecting existing systems, cleaning up stop reasons and closing actions in a system. Then give every type of recommendation an owner and a way back, so the model learns from what people did.

Sources