Turning OT data into insight means carrying a raw machine signal all the way to a decision, timestamping it, giving it context, computing a metric, and putting it in front of the person or system that can act. Stored tags are not insight. A historian full of readings nobody can interpret is a warehouse, not an answer.
Most plants already have the data. They have historians logging millions of tags, PLCs counting every cycle, sensors reporting every second. What they do not have is the bridge from that pile of numbers to a decision someone can make on shift. That bridge, context, computation, and delivery, is the hard part, and it is the part that decides whether all that collected data is worth anything. Collecting more tags does not close it; a bigger pile is still a pile. It is the same gap that produces manufacturing data silos seen from the OT side.
Why Isn't Stored OT Data the Same as Insight?
Because a stored tag is a fact with no subject. "Motor 7 drew 14.2 amps at 03:14" is true and useless on its own. You do not know what motor 7 was making, which order it was running, which shift was on, or whether 14.2 amps is normal for that job. The number is real. The meaning is missing. Insight is what you get when the number is connected to enough context that it can settle a question, and connecting it is work the historian was never built to do.
This is the trap of "we already collect the data." Collection is the easy 20 percent. A historian is very good at writing tags down fast and reading them back by time, and that is exactly where it stops. It does not know that motor 7 is on the bottleneck line, that the 14.2-amp reading coincided with a scrap spike, or that the same pattern preceded a failure last quarter. Those connections live in other systems and in people's heads, and until something joins them, the data sits in the warehouse gathering dust.
What Is a Data Historian, and Where Does It Stop?
A data historian is a system that logs plant tags, sensor values, machine states, counts, at high speed and stores them as time-series for later retrieval. It is excellent at its job: capturing a firehose of readings reliably and letting you pull back a trend for any tag over any window. Every serious plant should have one, and most do.
Where it stops is meaning. A historian stores that motor 7 drew 14.2 amps; it does not store that motor 7 runs the capper on line 3, that line 3 was making the export SKU, that the order was already behind, or that maintenance flagged the same motor last month. Those facts live in the MES, the ERP, the quality system, the maintenance log, and the memory of the operator who was there. The historian is a memory of what the machines did, not an understanding of what it meant. Turning its contents into insight requires joining it to everything the historian does not know.
It is worth being fair to the historian, because the point is not that it is the wrong tool. It is the right tool for one rung of the ladder, and it should stay. The mistake is expecting the next rungs for free. Plenty of plants bought a historian, watched the tags pile up, and waited for insight to appear, and it never did, because nothing above the historian was ever built. The tags are necessary. They are not sufficient. Treating "we have a historian" as "we have visibility" is one of the most common and expensive misreadings on the floor, and it is why data-rich plants can still run half-blind.
What Is the Context Gap?
The context gap is the distance between a raw tag and a judgeable fact. Closing it means attaching the who, what, and when to every reading: which asset produced it, which product and order were running, which shift was on. A value you can compare is worth a hundred values you cannot. "14.2 amps" tells you nothing; "14.2 amps on the capper while running the export SKU, versus a normal 11 amps for that job" tells you to go look. That attachment is the essence of contextualizing OT data.
The gap is hard for a mundane reason: the context lives in different systems than the signal, on different clocks, in different vocabularies. The traditional answer is ETL, periodically extract data from each system, transform it into a common shape, and load it into a warehouse to be joined. ETL works, but it is usually a batch, so the joined picture lags reality by hours, and it is brittle, breaking whenever a source system changes a field. The result is a warehouse that is great for last month's review and useless for a decision on this shift. Closing the gap in real time, not overnight, is what separates a report from an operating system.
How Do You Get From Raw Signal to Decision?
There is a ladder every useful piece of OT data has to climb. Skip a rung and the data never becomes insight.
- Signal. A sensor or machine produces a raw reading.
- Stored. The reading is timestamped and logged as a time-series, the historian's job, and where most plants stop.
- Contextualized. The reading is joined to the asset, product, order, and shift it belongs to, turning a number into evidence.
- Computed. The contextualized series is rolled into a metric people decide on, true OEE, a scrap rate, a trend slope, a cost per unit.
- Delivered. The metric reaches the right person in the right view, operator, supervisor, planner, leadership, at the moment it is useful.
- Acted on. A decision is made or an action is triggered, a work order, a reslot, a call, with a human able to approve it.
Why Do Most Analytics Projects Stall Here?
They stall because they treat the problem as a dashboard problem when it is a data-plumbing problem. A team builds a slick dashboard, points it at the historian, and discovers the numbers do not match the ERP, cannot be sliced by order, and go stale the moment a source system changes. The dashboard was the easy part. The context and the real-time joins underneath it were the hard part, and they were skipped.
The other reason is that the context lives partly outside every system, in binders and in the heads of senior operators. An analytics project that connects only the software captures a plant that is half-described, and half a picture produces half-trusted answers. This is why manufacturing analytics so often disappoints: the analysis is fine, but the foundation underneath it was never made whole.
There is a trust dynamic worth naming, too. The first time a new dashboard shows a number that disagrees with the figure a supervisor already believes, the dashboard loses, every time. People trust the source they have reconciled by hand for years over a slick screen that cannot explain where its number came from. So the bar for insight is not just accuracy; it is traceability. A useful answer has to be able to show its work: this metric came from these readings, on this asset, during this order, joined this way. Insight that cannot be traced back to its raw signal gets argued with instead of acted on, which is one more way analytics quietly dies on the floor. The fix is not a better chart. It is closing the context gap in real time and bringing the un-digitized knowledge into the same model, the job of a manufacturing operating system. A unified namespace is one clean way to feed it, and machine monitoring is one of the first payoffs once the ladder is climbed.
By the Numbers
The value of digital manufacturing is won or lost in what McKinsey calls the "last IT/OT mile", the connection between the floor's signals and the business systems that give them meaning, which is exactly the context gap described here (McKinsey & Company). And the barrier is not collection: U.S. Census Bureau surveys show advanced-technology adoption in manufacturing still trailing the broader economy, with disconnected data a recurring reason (U.S. Census Bureau, BTOS). Plants are data-rich and insight-poor. Where Harmony fits: Harmony is an AI-native operating system for manufacturing that connects machines, ERP/MES/QMS software, paperwork, and tribal knowledge into one real-time operational layer, contextualizes the signal, and turns it into live dashboards and approvable actions, no rip-and-replace. See how the phases climb the ladder or how CLS turned floor data into decisions.