How to prepare data for industrial AI

Preparing data for industrial AI is what determines whether an initiative can move from pilot to operational capability. Most industrial AI initiatives do not stall because of model choice. They stall because the company has not prepared the data needed to support a real operating decision. Before discussing copilots, predictive models or automation layers, it is worth checking what data exists, where it lives, who owns it and how reliably it reaches the business.

Preparing data for industrial AI does not mean launching a huge abstract data program. It means making the right operational sources usable for a specific use case, reducing noise, aligning identifiers and connecting systems such as ERP, CRM, MES and BI with clear intent. That preparation is what turns an AI pilot into something that can scale.

Without prepared data, the use case does not hold

When an industrial company says it wants AI, the practical question is not which model it wants. The practical question is which decision it wants to improve. If the data is late, duplicated or impossible to relate across systems, AI will only accelerate an existing coordination problem. That is why data preparation has to start with operational discipline, not technology theatre.

This is closely related to data governance in industry: without ownership, baseline rules and traceability, the initiative rests on weak information. But preparing data for AI goes one step further and translates that governance logic into an execution checklist for a concrete use case.

Which data for industrial AI should be reviewed before launch

There is no need to inventory the entire company on day one. The useful move is to identify the minimum sources that support the decision in scope and confirm that they can work together with enough structure and context.

• ERP: product masters, orders, supplier data, costs and administrative traceability.
• CRM: opportunities, installed base, complaints, account history and demand signals.
• MES or plant systems: production output, downtime, scrap, cycle times, incidents and shift data.
• BI and reporting: management KPIs, dashboard definitions and the historical metrics already used for decisions.
• Complementary sources: maintenance, quality, SCADA or sensor data when the use case genuinely depends on them.

The key is to verify whether those sources share identifiers, time windows and business rules that can be reconciled. If a product, work order, machine, lot or customer cannot be linked across systems, that foundation matters more than the algorithm.

What level of data quality is actually required

The answer depends on the use case, but industrial environments still need a practical minimum. Data must be complete enough, consistent enough and contextual enough to support action. Perfect datasets are rare; usable datasets are the real target.

• Completeness: critical fields cannot be systematically empty.
• Consistency: the same asset, product or customer should not appear under incompatible labels across systems.
• Time traceability: timestamps must allow teams to reconstruct sequences and compare events reliably.
• Appropriate granularity: a monthly KPI may help leadership, but it is rarely enough for operational intervention.
• Business context: records should include status, unit, cause and ownership where that affects the decision.

If the company is still clarifying where AI can create value, it also helps to review how industrial AI turns operational data into business results before collecting more data than the use case needs.

How to connect ERP, CRM, MES and BI without creating more noise

Useful integration for AI is not about dumping everything into a new platform. It is about building the smallest governable flow that supports the use case in scope. In many industrial companies, the mistake is trying to solve total architecture before proving practical value.

1. Define one operational question, such as predicting delays, prioritising maintenance or detecting quality drift.
2. Select only the tables, events and KPIs needed to answer that question.
3. Normalise the identifiers that matter most: product, work order, machine, customer, lot or shift.
4. Align update frequencies so the systems are not compared on incompatible time horizons.
5. Document baseline business rules and exceptions before automating decisions.

This approach keeps the project grounded and avoids turning industrial AI into a generic digital transformation promise. If the foundation is fragmented, AI will inherit that fragmentation.

What should not be automated yet

Some warning signs show that the company is not ready for operational AI yet:

• The KPI to improve is still debated internally.
• Critical decisions still depend on manual spreadsheets with conflicting versions.
• There is no clear owner for the source data.
• Historical records are too short or too noisy for the intended decision.
• Plant data and business systems are only loosely connected.

In that situation, the right move is to stabilise structure and quality first. Early automation often creates more correction work than real operational value.

Minimum checklist before moving into a pilot

1. There is a prioritised use case with an owner and a clear success measure.
2. The required ERP, CRM, MES and BI sources are identified.
3. Critical identifiers allow records to be linked across systems.
4. Data quality is good enough for the target decision.
5. Known gaps, assumptions and business rules are documented.
6. The team knows what it should not automate yet.
7. Someone is responsible for keeping the data usable once the pilot enters operations.

Preparing data for industrial AI is not administrative overhead. It is how companies reduce friction, narrow the problem and avoid letting integration kill the initiative. If you want to assess this from an industrial technology perspective, you can review the positioning of Vicente Millán.