Most plant floors have three or four operational systems running at once. A CMMS holds maintenance history. A historian or SCADA system holds sensor and alarm data. Shift output data usually lives in spreadsheets or a production reporting tool. These systems may have run for years, sometimes decades, and each holds years of records. They do not share information easily, and the people who need cross-system answers often cannot query any of them directly.
The usual label is the data silo problem, followed by a technology diagnosis: old systems, incompatible formats, limited APIs, and the IT/OT divide. Those constraints are real. But in the plants we have worked with, technology is rarely the main reason operational connections were not built. The main reason is that nobody created a shared use case for the people who need answers.
Why the Silos Exist
A CMMS is purchased to manage maintenance work orders and reduce equipment downtime. Maintenance makes the purchasing decision, then configures the system around its workflows. Access goes to maintenance technicians, leads, and the maintenance manager. Other roles are often left out because the CMMS was not purchased for them.
Controls engineers commission historian systems to record PLC sensor data and give process engineers tools for trend analysis. The access model follows that origin: process engineers and controls staff can run queries, while operations supervisors generally cannot. When the historian was commissioned, nobody was planning for a supervisor to run trend queries.
Production reporting systems are usually built by whoever needs a report at the time: a quality manager, plant manager, or operations director needing a weekly view. The result reflects the builder's information needs, not always the needs of operators and supervisors who would use the information during a shift.
Different functional groups purchased and configured each system for a different purpose, with a different access model. No integration project followed because no shared use case created enough reason to build one.
The IT/OT Divide Is Real but Often Overstated
Manufacturing data silos are often explained through the IT/OT divide. Information technology systems, including ERP, CMMS, and business applications, and operational technology systems, including SCADA, historians, and PLCs, use separate networks and governance. That separation matters for security and system stability. An IT network event should not reach a production control system, and connecting OT systems to corporate IT requires careful management.
But the IT/OT divide does not explain most of the integration gap we encounter. The CMMS usually sits on the IT network, and production reporting spreadsheets definitely do too. When two systems share that network and offer accessible APIs, their lack of connection is usually a prioritization issue, not an OT constraint.
The OT divide is a real constraint when historian and control system data must reach business network applications. For most plant operational data, it calls for careful architecture. It does not mean a connection cannot exist.
What Cross-System Questions Actually Look Like
Questions that cross system boundaries often guide the most immediate operational decisions. "Why did output drop on Line 2 last night?" requires production output data, historian data, and CMMS data. All three are necessary, and no single system can answer the question alone.
Cross-system causation questions about production events are exactly what most plants cannot answer quickly. The data exists, and the three systems are running and recording. But getting from "I need to know why Line 2 dropped" to "here is what the data shows" means moving through three systems and three access interfaces. The person asking often has direct access to none of them.
Shift supervisors and production managers pay the highest cost because they make operational decisions under time pressure. They need cross-system answers immediately but have the least infrastructure for getting them.
What a Connection Actually Requires
Connecting operational systems to answer cross-system questions is narrower than a full data integration or data lake project. It does not require migrating data, replacing an existing system, or making the CMMS and historian write to a shared schema.
It requires a read layer that queries each system through its existing API or connector, retrieves the relevant data for a question, and returns a combined answer. Most CMMS platforms have REST APIs. OSIsoft PI and Ignition have accessible data connectors. Production reporting exports in CSV can be read. The integration work is real, but its scope is bounded.
Tendrel uses a read-only layer that connects to each operational system through its available connector. When someone asks a question, it queries each system for the relevant data and returns a combined answer in plain language. Tendrel is not a data warehouse. It is a question-answering layer that works with the systems already in place.
The Organizational Barrier That Remains
Connecting the technology does not remove the organizational barrier. People still need a habit of asking the system before calling someone. If the current pattern is to call a process engineer with a production question, the query interface must be fast and accurate enough to become a better option than that phone call.
This is not a minor challenge. Manufacturing habits last because they were shaped by real experience on a specific floor. A query tool that returns slow or inconsistent answers will be abandoned quickly in favor of the phone call that people trust.
The data silo problem is real, and the technology to address it is available. The harder work is changing how people seek answers, something a read-only integration layer cannot do by itself. It can reduce enough friction to make that habit change possible. On a plant floor, a useful connection is one people can use before they pick up the phone.