Operational Data for AI: ERP, WMS, IoT and Process Logs

By Tara Minh · Updated Oct 11, 2026

Operational data for AI is the record of what your business actually did and is doing right now: orders, stock moves, machine states, sensor readings and the timestamped events that show how work flowed. It lives in five kinds of system (ERP, WMS, MES, IoT sensors and event logs), and an AI model is only as useful as your ability to pull those sources together, line up their identifiers and trust their values.

This guide is for operations managers, COOs and process owners who have been asked to "do something with AI" and want to know what data that really takes. It explains what each source holds, how the sources differ in speed and structure, where integration breaks, and how to get a first use case running without a two-year data project. For the wider picture, start with the pillar guide to AI in operations management.

Key Facts

• A study based on interviews with 53 AI practitioners reported data cascades, the compounding downstream damage caused by data problems, at 92% prevalence (Sambasivan et al., ACM CHI 2021).
• The ISA-95 standard (also known as IEC 62264) places MES at level 3 and ERP at level 4, and focuses on the interface between those two levels (ISA).
• OPC UA is described by the OPC Foundation as platform independent, running from embedded microcontrollers to cloud servers, with signed and encrypted messages (OPC Foundation).
• MQTT, an OASIS standard approved in 2017, is a lightweight publish/subscribe protocol designed for machine-to-machine and IoT settings (OASIS).
• The same fact often lives in three systems under three names. Matching identifiers across them is usually the first real job, ahead of any model.
• Most operational AI use cases need only two or three sources joined well, not every system you own.

Why Operational Data Is Different

Customer-facing AI mostly works on text: tickets, emails, help articles. Operations AI works on a messier mix. There are structured transactions (a purchase order line), continuous measurements (a motor's temperature every second), and event trails (a work order moving from "created" to "released" to "complete"). Each arrives at a different speed, in a different format, owned by a different team.

That matters because the questions managers ask cut across those sources. "Why is this line late?" needs the order from ERP, the material status from the warehouse, the machine state from the floor and the changeover history from the log. No single system holds the answer, and an AI model can't conjure the join for you.

In ACE Framework terms, this is the Ingest step: getting data into a form a model can analyze. It sounds like plumbing because it is. It's also where most projects win or lose. The ACE Framework puts data first for exactly that reason.

The Five Core Sources

ERP: the system of record

ERP is where the business books its commitments. Sales orders, purchase orders, bills of material, inventory valuation and cost all sit here. For AI, ERP is the best source of "what was supposed to happen" and "what did it cost." It's rarely good at "what is happening right now on the floor," because it only knows what someone or something posted into it.

Typical ERP-driven AI uses are demand and supply forecasting, spend anomaly detection and exception prioritization (which late purchase orders matter most). The data is clean in structure but often dirty in meaning: item codes duplicated over the years, free-text fields used as workarounds, or a status that means different things to different plants.

WMS: where goods actually move

A warehouse management system records the physical truth of inventory: which bin, which pallet, which pick, which wave. Where ERP says you have 400 units, WMS says where they are and whether anyone has touched them since Tuesday. That makes WMS data the base for slotting analysis, pick-path optimization, labor planning and inventory accuracy checks.

The common gap is timing. WMS moves happen in seconds. ERP often learns about them in batches. If an AI model compares the two without allowing for that lag, it flags thousands of false differences. For a deeper look at supply chain uses, see the AI supply chain agent.

MES: the shop-floor ledger

A manufacturing execution system sits between the plan and the machines. It tracks work orders in progress, counts good and bad units, logs downtime and ties materials to finished lots. ISA-95, the standard behind this layered view, describes the interface between the manufacturing operations level and the business planning level (ISA). It's a useful mental model even if your vendor doesn't follow it exactly: ERP plans, MES executes, machines produce.

MES data feeds the use cases managers care about most: yield prediction, downtime root cause analysis and quality escape detection. Its weakness is manual input. Downtime reason codes chosen from a dropdown by a busy operator at the end of a shift are the classic example. "Other" becomes the biggest category and the model learns nothing.

IoT and sensor data: fast, noisy and plentiful

Sensors measure what systems can't infer: vibration on a bearing, temperature in a cold chain, pressure in a line, the position of a truck. The volume is large, the value per reading is tiny, and the meaning appears only in patterns over time.

Two standards show up often when you plan connectivity. OPC UA is a platform-independent architecture for exchanging data between industrial equipment and higher-level systems, with support for signing and encrypting messages (OPC Foundation). MQTT is a lightweight publish/subscribe messaging protocol built for machine-to-machine and IoT settings (OASIS). You don't need to be an expert in either. You do need to ask your engineers which one your equipment speaks, because it decides how hard the first connection is.

Sensor data supports predictive maintenance, energy optimization and anomaly detection. The anomaly agent pattern describes how a model watches these streams and raises a flag when something drifts. The same streams also feed digital twin simulations.

Event logs: the trail of how work flows

An event log records that a case (an order, a ticket, a work order) passed through an activity at a time, often with a person or system attached. Almost every workflow tool, ERP module and ticketing system writes one, whether or not anybody calls it that. Process mining takes these logs and reconstructs the real process, including the detours nobody drew on the flowchart. Read process mining for the technique and how AI extends it.

The minimum useful event log has three columns: a case ID, an activity name and a timestamp. Everything else (resource, cost, location) is a bonus. If you can't extract those three from a system, you can't mine it.

What Operational AI Needs From the Data

Different jobs need different things. This is a practical way to match use case to data before you commit budget.

Notice what the table shows. Each use case needs two or three sources, plus one stubborn requirement about identifiers or labels. Nobody needs a "single source of truth" to start. They need a few specific joins that work.

Where Integration Breaks

The same handful of problems appear in almost every operations data project.

Identifiers that don't match. The part is "AX-1042" in ERP, "AX1042" in the WMS and "1042-A" in the MES. A model can't learn from rows it can't link. Build and maintain a cross-reference (a master data mapping) before anything else.

Clocks that disagree. Time zones, daylight saving shifts, and machines whose internal clock drifted all corrupt sequence analysis. If two events appear in the wrong order, any cause-and-effect finding is wrong.

Different meanings for the same word. "Shipped" can mean picked, loaded, left the gate or invoiced. "Downtime" might include or exclude planned changeovers. Write definitions down and agree them with the people who own each system.

Latency and batching. Some systems stream, others export nightly. Decide what freshness each use case really needs. Forecasting can live on yesterday's data. A safety alert can't.

Missing history. Many shops overwrite state instead of storing change. If your system keeps only the current status, you can't train a model on how things got there. Start retaining history now.

Access and ownership. The data sits behind a vendor's API, an old database or a spreadsheet only one planner understands. Getting it out is partly technical and partly political.

Data Quality Problems That Quietly Sink AI

Poor data rarely announces itself. It shows up as a model that works in the demo and fails in week three.

The research on this is blunt. The authors of that study argue that data work is the most under-valued and de-glamorized part of AI (Sambasivan et al., ACM CHI 2021). Operations teams feel this directly, because the people who generate the data (operators, pickers, planners) are not the people who benefit from its quality.

The recurring quality issues:

• Completeness. Required fields left blank or filled with "N/A" and "TBD."
• Consistency. The same supplier spelled five ways, units mixed between kilograms and pounds.
• Accuracy. Counts posted late, inventory adjusted in bulk to hide variance.
• Timeliness. Records entered at the end of the shift from memory.
• Labels. Failure causes and downtime reasons chosen by habit, not fact.
• Drift. A process changed, a sensor was replaced or a plant added a product line, and the old patterns no longer hold.

You can measure where you stand with data readiness for AI.

How to Prepare Your Operational Data, Step by Step

1. Pick one decision. Name the specific operational decision you want to improve, such as "which late purchase orders do we chase first" or "which machines get maintenance this week." Data work without a decision turns into an endless cleanup.
2. List the sources that touch it. Usually two or three. Write down the system, the owner and how you can extract data (API, export, database view).
3. Map the identifiers. For each entity (item, location, machine, order, supplier), document how each system names it, and build a cross-reference table with a named owner.
4. Agree the definitions. Hold a short session with the owners of each system. Settle what "complete," "late," "downtime" and "shipped" mean, and record the answers.
5. Profile the data. Count blanks, duplicates, outliers and out-of-order timestamps. A one-page profile tells you quickly whether the use case is feasible.
6. Fix at the source where you can. Change the dropdown, add the required field, retire the duplicate item code. Fixing the input beats cleaning the output every month.
7. Land it in one place. Copy the joined data into a shared store (a warehouse, lakehouse or even a governed set of tables) so analysts and models read from one consistent copy and not from live production systems.
8. Pilot with humans in the loop. Let the model recommend and the planner decide. Review misses weekly and trace each back to a data cause or a model cause. The human-in-the-loop guide covers how to design that review.
9. Track a small set of data KPIs. Completeness, timeliness and mismatch rates, alongside the KPIs the use case is meant to move.
10. Add the next source only when the first join is stable. Expansion is where scope creep eats timelines.

A Hypothetical Worked Example

Say a mid-size distributor wants to cut stockouts on its fastest-moving items. This is an illustration, not a case study.

The team starts with ERP sales and purchase history plus WMS on-hand balances. Their first profile shows 6% of item codes appear twice with slightly different formats. They build a mapping table, merge the duplicates and agree that "available" means on-hand minus allocated, not on-hand alone.

With cleaner data, a forecasting model starts to rank items by stockout risk each week, and a planner reviews the top list. Event logs from the purchasing workflow later show that approvals sit for several days in one step, which explains many late orders more than the forecast does. The team now has two fixes: a better forecast, and a faster approval path. Neither required connecting every system. They needed two sources, one mapping table and one shared definition.

Common Pitfalls

Starting with a big data lake. Months of loading everything, no use case. Start from the decision and pull only what it needs.

Trusting the system of record blindly. ERP shows what was posted, not what happened. Cross-check against physical or machine data on a sample.

Ignoring the people who enter data. If the operator gains nothing from accurate entry, accuracy decays. Show them how the data is used and keep the entry effort low.

Cleaning once. Data quality is a recurring process with an owner, not a project with an end date. Assign a data steward per domain.

Skipping security and access control. Opening production systems to a new tool raises real risk. Use read-only access, least privilege and a review step. Log those risks in your AI risk register.

Letting the model act before the data is trusted. Recommendations first, automation later. The recommend, approve or automate framework shows where that line sits.

Who Should Own What

Operational data crosses departments, so ownership needs to be explicit. A workable split: the business owner of each process owns definitions and quality, IT owns extraction and storage, and a named data steward owns the cross-reference tables. Put one person in charge of the whole pipeline for the pilot. Without that, every problem becomes someone else's.

For how the data surfaces to decision makers, read about the AI operations control tower.

Where to Go Next

Pick one decision, list the two or three systems behind it and build the identifier mapping this month. That single exercise reveals most of what's hard about your data, and it's the foundation every later operational AI project will reuse.