Manufacturing's AI Problem Is Not What You Think

The operations VP had a confident answer when I asked about their data situation: “We are on SAP. Everything is in SAP.”

I walked the shop floor for two hours before the formal kickoff. Four CNC machines running lights-out. A quality inspection station where a technician recorded dimensions on a clipboard and then entered them into a spreadsheet at the end of her shift. A maintenance board on the wall - a literal whiteboard - with scheduled PM dates for eight pieces of equipment. A conveyor that had been down for 45 minutes that morning, cause undetermined, now running again. None of it logged anywhere.

“Everything is in SAP” is the manufacturing version of “our CRM is our brain.” It is true for one slice of the operation. It is false for the slice where most AI value actually lives.

Two Worlds That Do Not Speak to Each Other

Manufacturing operations run on two fundamentally separate data environments. Understanding this is the prerequisite for any AI conversation in a manufacturing context.

The IT World: ERP and Business Systems

This is where “everything is in SAP” is actually true. The ERP - SAP, NetSuite, Epicor, Infor - contains order management, inventory records, procurement, financials, HR, and production scheduling. These are the business systems, and they run on standard IT infrastructure: servers, cloud instances, network connectivity, modern APIs.

SAP is the dominant ERP in mid-large manufacturing. It has robust API connectivity via RFC (Remote Function Call) and REST APIs. The data is rich and comprehensive for the business layer. SAP’s integration complexity is real - implementing new connections typically requires certified SAP developers and change management that touches multiple modules - but the underlying API capability is there.

NetSuite (Oracle) is common in mid-market manufacturing, particularly for companies that grew through acquisition. It offers SuiteScript and REST API access. Reasonably connectable for standard objects like items, orders, and inventory transactions.

Epicor is popular in job-shop and discrete manufacturing environments. REST API is available and functional. Documentation quality varies by module, but the connectivity exists for the major data objects.

Fishbowl is the outlier in this tier - popular with smaller manufacturers as a QuickBooks-adjacent inventory and manufacturing system, but its integration capabilities are significantly more limited than the enterprise ERPs. If you are on Fishbowl, your Systems layer assessment will surface meaningful connectivity constraints.

All of these systems have one thing in common: they contain what the business has decided to record. And in manufacturing, that rarely includes what is actually happening on the shop floor in real time.

The OT World: Shop Floor and Machine Data

OT stands for Operational Technology - the systems that run the physical production environment. PLCs (Programmable Logic Controllers), SCADA systems, CNC machines, industrial sensors, quality control equipment. These systems speak their own languages: OPC-UA, Modbus, MQTT, EtherNet/IP.

OT networks are often physically and logically separated from IT networks - sometimes intentionally air-gapped for security and safety reasons, sometimes simply because they were installed by different people over different eras and never connected. The machine that costs $2 million does not have a REST API. It has a PLC that speaks Modbus and was last configured in 2014.

MachineMetrics and Plex represent the newer generation of OT data connectivity tools - IoT-native platforms with modern APIs that can pull data off machines and make it accessible to business systems. If you have deployed one of these, you have made a meaningful investment in bridging the OT/IT gap. Most manufacturers have not, or have deployed them in limited portions of the facility.

The result is what I call the two-world problem: the ERP knows the production schedule, but not whether the machines are running on time. The shop floor knows what is actually happening, but that knowledge is in PLCs and clipboards, not in any system the ERP can query.

Why This Kills Every AI Project

Predictive maintenance is the AI capability manufacturers most commonly want. The pitch is compelling: AI analyzes machine performance data, identifies patterns that precede failures, and alerts maintenance teams before unplanned downtime occurs. Unplanned downtime in manufacturing typically costs $2,000-$10,000 per hour depending on the operation. Preventing even a few events per year justifies significant investment.

The problem: predictive maintenance requires continuous machine performance data - vibration readings, temperature, cycle counts, current draw, error codes. This data comes from the OT world, from sensors and PLCs attached to the machines. If that data is not being collected, transmitted off the machine, stored somewhere accessible, and timestamped consistently - the AI has nothing to analyze.

In the facilities I audit, machine data capture ranges from comprehensive (large, modern facilities with full IIoT deployments) to essentially zero (older operations where maintenance decisions rely entirely on technician experience and the maintenance whiteboard). The median is somewhere in between: some machines have data available, most do not, and the data that is available is often inconsistent in format and not connected to anything.

Here is the finding that manufacturing owners find most uncomfortable: the AI deployment is not the project. The OT/IT integration is the project. Predictive maintenance AI is a six-month effort once the data infrastructure is in place. Getting the data infrastructure in place - deploying sensors, connecting PLCs to a data collection layer, normalizing the data format, building the pipeline from the shop floor to a system the AI can read - is often a 9-18 month project depending on facility complexity.

The audit’s job is to tell you that before you sign an AI contract, not after.

Scheduling AI: The Same Gap, Different Manifestation

Production scheduling optimization is the second most common AI request from manufacturing operations. The appeal: AI considers machine capacity, order priority, material availability, and changeover times to generate an optimal daily schedule.

The ERP contains order data and inventory levels. It may contain machine capacity in broad terms. It does not typically contain real-time machine status, actual changeover times by product combination (versus the theoretical times someone estimated when the system was set up), or unplanned downtime history in a structured format.

The gap means scheduling AI works from assumptions, not from actuals. If the ERP says Machine 3 has 8 hours of available capacity today, and Machine 3 has been running at 75% efficiency for the past month due to a calibration issue that nobody documented in any system, the AI schedule will be wrong. Not because the AI is bad - because the input is wrong.

The process map in the AI audit traces production scheduling from order entry through to floor execution. It documents at each step: where does the data come from, how current is it, who captures it and where, and what happens when actuals diverge from planned (which they always do). The divergence handling is almost always manual, ad hoc, and undocumented.

The Data Layer Reality Check

When I complete a manufacturing AI audit, the data and systems assessment covers six specific dimensions.

ERP data completeness. What percentage of production orders have accurate bill-of-materials data, accurate routing information, and accurate standard cycle times? In most manufacturers I audit, there is meaningful drift between the “official” data in the ERP and what the floor actually runs. This drift compounds over time.

Machine data availability. Which machines have sensors or PLCs that output readable data? What protocols? Is the data being collected or just available? Is there a historian (a time-series database for machine data) already in place, or would implementing one be a new deployment?

Quality data structure. Where are quality inspection results recorded? If they are in a spreadsheet or on paper, that is a data gap. Quality data is one of the richest inputs for process optimization AI - but only if it is structured and timestamped and associated with specific production runs.

Maintenance history. Is there a CMMS (Computerized Maintenance Management System)? If so, is it current? What percentage of maintenance work orders are actually recorded in it versus handled informally? Many manufacturers have a CMMS that was set up years ago and drifted away from actual use.

OT/IT connectivity status. Is there any existing bridge between the shop floor systems and the ERP or business data environment? What protocols and middleware exist? What is the network architecture between OT and IT zones?

People knowledge. What does the maintenance manager know that is not in any system? What does the master scheduler carry in their head that the ERP does not capture? This is the qualitative dimension of the audit - identifying where tribal knowledge represents a single point of failure and a data collection gap simultaneously.

What the Priority Matrix Reveals

For manufacturers, the priority matrix almost always produces the same top item: get basic machine data off the shop floor before anything else.

This does not have to be a full IIoT deployment to start. The practical starting point is usually a focused deployment on 3-5 critical machines - the ones whose downtime is most expensive, the ones whose scheduling constraints most frequently cause bottlenecks. Getting cycle counts, run states (running/idle/down), and basic fault codes off those machines into a simple historian costs $15,000-$40,000 depending on machine age and protocol. That is a lot less than the AI project that cannot run without it.

The second priority for most manufacturers: CMMS utilization. If a CMMS exists, enforce data entry discipline with the maintenance team. If one does not exist, implement a simple one (eMaint, Limble CMMS, or Fiix are all connectable and appropriate for mid-size operations). Every work order that goes into the CMMS is data that a predictive maintenance AI can eventually learn from.

Bridging the OT/IT Gap With Modern IIoT Tools

Modern IIoT tools like MachineMetrics are worth mentioning here. If you are evaluating a new deployment, MachineMetrics specifically is designed to pull data off machine controllers via standard protocols and expose it via modern APIs. It is a real bridge between the OT world and the IT world, and it is what the AI blueprint will recommend as the data collection layer if you are starting from scratch on machine connectivity.

The AI blueprint in a manufacturing audit does not promise you predictive maintenance in 90 days. It tells you what the path to predictive maintenance looks like, what it costs, what needs to happen in sequence, and what you can start doing now while the foundational work is underway.

For a framework on assessing readiness before formal engagement, the AI readiness audit guide walks through process, data, team, and budget dimensions that apply across industries. For companies running distribution alongside manufacturing operations, the AI audit for logistics and freight covers how the OT/IT data gap shows up differently in transportation and warehouse contexts.

Frequently Asked Questions

We have SAP S/4HANA - does that mean our data layer is ready for AI?

S/4HANA is a modern ERP and it does have better native analytics and some AI-adjacent features compared to older SAP versions. But the ERP being modern does not address the OT/IT gap. S/4HANA can tell you production schedule adherence after the fact - it cannot tell you in real time that Machine 3 has been idle for 40 minutes due to a tooling issue unless someone enters that information. The shop floor data collection layer is a separate project regardless of which ERP you run.

Our maintenance team says they do not need AI - they know these machines. Should I push back?

This reaction is common and worth taking seriously rather than dismissing. Experienced maintenance technicians genuinely do carry knowledge that AI cannot yet replicate - intuitions about machine sound, vibration feel, patterns that are hard to quantify. The right frame is not “AI replaces your expertise” but “AI handles the data-tracking work so your expertise can focus on actual diagnosis.” The AI flags anomalies in the data. The technician decides what those anomalies mean. If the maintenance manager is resistant, the audit process includes a stakeholder interview that surfaces what they actually need - which is often better data access, not AI overlaid on top of their current workflow.

What is a realistic timeline from an AI audit to a working predictive maintenance system?

Honest answer: 12-24 months for a manufacturer starting from a typical baseline. The audit itself takes 3-4 weeks. The OT data collection deployment (sensors, historian, normalization) takes 3-9 months depending on facility scope. Data accumulation for meaningful pattern detection takes at least 6-12 months of clean data. The AI model training and integration is then a 2-3 month project on top of that. Vendors who promise predictive maintenance results in 60 days are either working with a facility that already has comprehensive machine data (rare) or overpromising.

We have already bought an AI tool for production scheduling - can the audit help us make it work?

Yes. The audit will assess what data the tool needs versus what your current systems actually provide. It will identify the specific gaps causing the tool to underperform and produce a remediation plan with sequencing. Often the tool is perfectly capable - it is running on incomplete ERP data, missing real-time machine status, or using standard cycle times that no longer reflect actual floor performance. Fixing those inputs is usually faster than replacing the tool.

Is it worth doing an AI audit before we have upgraded our ERP?

If an ERP upgrade is already planned and imminent (within 6 months), it makes sense to coordinate the audit timing so the new system’s data structure is part of the assessment. If the ERP upgrade is a 2-3 year horizon item, do the audit now - the findings may influence how the new ERP is configured and what data standards you establish for the new implementation. Many AI readiness gaps in manufacturing are not ERP gaps anyway - they are OT/IT gaps and process discipline gaps that persist regardless of which ERP you run.