Connecting AI to the shop floor of operations
How to make AI work with your operation's real data, WMS, TMS, Zendesk, shift spreadsheet, and sensor, choosing the right path by the data's format and connecting safely.
You ask AI why the distribution hub has had a line since seven in the morning. It answers with an analysis full of pretty logistics jargon. And made up. AI never opened your WMS or the dock occupancy sensor, so it guesses a plausible cause.
You ask which route has the worst cost per delivery this month. AI opines "probably the longest one", without ever having seen your cost per route spreadsheet. The real culprit was a short route with rework, hidden in a column it didn't even know existed.
You ask whether the SLA promised in the customer's contract matches the internal operational SLA. AI confidently answers that the two are the same, without having cross-checked the running text contract against the per shift targets spreadsheet. The contract promised 24 hours; the real internal target, hidden in a separate tab, was 30.
You ask whether you can promise 24 hour delivery in the year end campaign. AI says yes, with the same confidence as always, without ever having looked at the hub's capacity dashboard for that period. The campaign's promise was going to blow up exactly during peak week, which AI never read as a real occupancy sensor.
You ask AI to cross-reference overnight shift absenteeism, which lives structured in the time clock system, with the scheduling policy, which is running text. It hands back an answer full of shift management jargon, but treated the policy as a spreadsheet and the time clock data as if it needed a meaning based search. The shift with the most absences got lost in the confusion, because neither source was read the right way.
You ask AI which driver app feature most reduces dock dwell time, cross-referencing the app's structured event log with the research report in PDF full of heat map charts. It hands back a nice looking number, but read the PDF as running text and lost the heat map, and treated the log as if it needed meaning based search instead of aggregation by time window. The real bottleneck was in a time band it never summed correctly.
You ask AI to explain why the SLA promised to a big account isn't being met, cross-referencing the TMS export, rows and columns, with the signed contract, running text. It hands back a consultant style answer, but treated the TMS as text to search by meaning and the contract as a spreadsheet, missing the holiday exception clause. The real bottleneck was in the clause, hidden in a contract it never read by meaning.
You ask AI why dock 4 at the distribution center has had a line since seven in the morning, and feed it, all at once, the WMS export (rows and columns, each pallet's position), the shift spreadsheet the supervisor fills in by hand, and the dock occupancy sensor, which sends a signal every thirty seconds. It hands back a pretty answer, but scrambled all three: treated the WMS as text to search by meaning, treated the shift spreadsheet as if it were as clean and structured as the system, and treated the sensor as if it were a fixed thirty row table, without aggregating anything. The real line came from a ten minute spike in the sensor, right at the time the shift spreadsheet (filled in by hand, with one cell out of format) recorded the team changeover, information the WMS had no way of knowing. Wrong data format, wrong diagnosis: a structured system calls for reasoning over the schema, a shift spreadsheet calls for normalization before you calculate anything, a sensor calls for windowed aggregation, not all three treated the same way.
You ask AI to list which cold chambers had cold chain rupture risk this month, cross-referencing the continuous temperature sensor log with the food safety procedure, running text. It hands back a generic list, but treated the sensor as a fixed spreadsheet instead of aggregating by window, and missed short spikes that crossed the threshold for a few minutes. The real risk was in a ten minute window it never aggregated.
You ask AI to find which service in the routing system causes the most slowness, cross-referencing the structured monitoring log with the incident report in PDF full of latency charts. It hands back a guess with the air of someone who understands infra, but treated the log as text to search by meaning and the PDF as a simple spreadsheet, losing the chart. The service that kept freezing was in a table in the report it never read as an image.
You ask AI to find where the driver gets stuck most in the delivery confirmation flow, cross-referencing the app's structured usage data with the research report in PDF full of heat map charts. It hands back a UX cliche, but treated the app usage as running text and the PDF as a spreadsheet, losing the heat map that showed the real friction point. The step where the driver actually got stuck disappeared because neither source was read the right way.
You ask which hub should get the next automation investment. AI hands back a pretty answer that cross-references data from two different systems any old way: it treated the WMS export as text to search by meaning, and the capacity report in PDF as a simple spreadsheet, losing the table. The hub that actually needed it most was hidden in a table it never read as an actual image.
Notice something: the problem is almost never that AI is bad at math. The problem is that it's answering off the top of its head, without ever having opened YOUR shop floor of operations. It's like hiring the best operations manager on the market, sitting them in your office, and never giving them access to your WMS, your TMS, the cold chamber sensor. They'll talk a good game and get it badly wrong, because they're guessing. Connecting AI to your operation's real data is exactly what pulls it out of the generic. Except connecting it wrong is worse: either it leaks sensitive shop floor information, or it scrambles three different data formats together and hands you a diagnosis that looks certain and matches nothing.
The core idea of this lesson. AI only really delivers when it works WITH your operation's real data, and the FORMAT of the data decides the path. A structured system (WMS, TMS, Zendesk) often doesn't even call for vector search: AI reasons over the schema and the statistics. A shift spreadsheet looks structured, but it's messy, kept by hand, and needs normalization before any calculation. A sensor is continuous data: it's not text to search by meaning, nor a fixed table to sum, it calls for aggregation over a time window. And before anything else comes the security question: what can leave the shop floor of operations, and what can't.
01The data's format decides the path
The first thing that changes everything is to stop treating "my operation's data" as a single thing. There's no single path to connect AI to your factory or distribution floor. What exists is the data's format, and the format dictates the road.
Think of three natures of data that live in every operation. There's the structured system, which lives in rows and columns: the WMS export, the TMS table, the Zendesk report. There's the shift spreadsheet, which looks structured but is kept by hand by supervisors, with merged cells, free text in the notes column, a format that changes from shift to shift. And there's the sensor, continuous data: cold chamber temperature, a machine's cycle time, a vehicle's location in transit, a signal every second or every minute.
These are three different natures, and each calls for a different tool. Trying to force all three down the same path is mistake number one. The @datasciencebrain study hits exactly this note: the data's format decides the memory architecture, not the other way around.
02Structured system: WMS, TMS, and Zendesk almost always call for reasoning over the schema
Here lives the most common mistake of someone who just learned RAG: thinking ALL data needs to become vector search. It doesn't. And in operations this is especially true, because a good chunk of what you use every day already lives structured, in rows and columns, inside the WMS, the TMS, or Zendesk.
When the data is a WMS export with pallet positions, or a TMS table with time per route stage, AI gains almost nothing from turning every cell into a coordinate of meaning. What it needs is to understand the STRUCTURE: what the columns are, what each one means, the total row count, the sum of each column, the range of values. Instead of "searching for similar snippets", it reasons over the schema, over the statistics, and over a sample of representative rows.
Think about the practical difference. To answer "which dock has the longest wait time today", AI doesn't need a fuzzy semantic search. It needs to look at the WMS table, sort by the wait time column, and read the first row. That's reasoning over structured data, not vector search. It's cheaper, more accurate, and doesn't run the risk of the search pulling up the wrong dock.
03Shift spreadsheet: looks structured, but it's deceiving
Now the format that most deceives people who work in operations. The shift spreadsheet DOES have rows and columns, so it seems like the same thing as the WMS export. It isn't. It's filled in by hand by different supervisors, on different shifts, under time pressure, and that leaves marks: a merged cell that breaks the column reading, a note written as free text where there should be a fixed code, one shift that logs the time as 07:00 and another that logs "seven in the morning".
If you treat the shift spreadsheet as if it were as clean as the WMS, AI will calculate on top of a structure that doesn't really exist, and the result comes out wrong without warning you. The right path is to first ask AI to NORMALIZE: identify where the structure breaks, standardize the time format, separate the free text from the fixed data, and only then reason over the normalized table. It's an extra step the shift spreadsheet demands and the WMS doesn't, and skipping that step is where the diagnosis starts to lie.
04Sensor: continuous data calls for a window, not RAG and not line by line
Here comes the third format, the one that looks least like the other two: the sensor. Cold chamber temperature every thirty seconds, a machine's cycle time per unit, a vehicle's location every minute. It's not text to search by meaning, because it has no semantic meaning at all, it's just numbers over time. And it's not a fixed table to sum row by row, because an isolated reading almost never tells the story: what matters is the pattern over a window.
Throwing a raw sensor stream at AI, question by question, point by point, is expensive and it's noise. Nobody decides anything by looking at an isolated temperature reading at 2:32:12 PM. The right path is to aggregate first: the hourly average, the shift's peak, the deviation from normal, how many times the signal crossed the safety threshold. Only once it's aggregated into windows does AI interpret it with meaning, and what it hands you back becomes a decision, not pretty noise.
05Security: what doesn't leave the shop floor of operations
Everything up to here is about making AI get it right. Now the point that, in operations, can take you down: what leaves your factory or distribution floor and goes outside.
The moment you connect AI to your operational systems, answer this before anything else: can this data leave? Some data can go to a cloud model without a problem. And some data can't leave under any circumstances: real time location of high value cargo in transit, exclusivity contract terms with a carrier, WMS access tokens, customer data that lives inside the TMS. Sending that outside without thinking isn't optimization, it's a leak.
The same three layers of protection from the lesson on connecting financial data apply here, just applied to the operational shop floor. Anonymization: strip out identifiers before sending, swap a vehicle's license plate for a code, aggregate whatever can be aggregated. Choosing where it runs: sensitive cargo location data may call for a local model or a closed environment, not the public cloud. Gateway: the gate between you and the model, blocking whatever can't pass through and logging everything that did. It's not bureaucracy, it's what separates "I used AI on my WMS" from "I leaked my most valuable cargo's route to a third party without noticing".
Do it now
Take a real case from your operation where AI answered off the top of its head and got it wrong, or where you haven't even tried using AI yet: your real task.
- List 3 data sources that would contain the right answer (WMS or TMS export, shift spreadsheet, sensor log).
- For each source, classify the FORMAT: structured system, shift spreadsheet kept by hand, or continuous sensor.
- Mark the path for each one: a structured system leads to reasoning over the schema, a shift spreadsheet leads to normalization before calculating, a sensor leads to windowed aggregation.
- Do the security check for each source in one line: can this data leave the shop floor of operations? Does it need anonymizing? Does it run in the cloud or does it call for a closed environment?
- Point out which of the three sources is the most sensitive and write, in one sentence, what the gateway should block on it.
You've just designed the connection between your shop floor of operations and AI, through the right path, with the security gate in place.
Practice
1. You need AI to answer 'which dock has the longest wait time today' from the WMS export. What's the most suitable path?
2. Why does throwing a temperature sensor's raw signal, point by point, straight into a question for AI usually give a bad answer?
For the board
On the diagnosisit is guessing because it never opened your WMS, your TMS, your sensor.
On formata structured export calls for reasoning over the schema, not vector search.
On sensorscontinuous data calls for a window. Reading point by point is noise; aggregating is what becomes a decision signal.
Thanks for the feedback. It helps sharpen the next lesson.