Your SCADA system is running a historian. It's collecting tag data, storing it, making it available for trend views and alarm analysis. It's doing its job.
So why can't your process engineer get the answer she needs without asking someone to pull a report? Why is the maintenance manager still working from spreadsheets? Why does it take a week to answer a question that should take an hour?
The data is there. It's just not accessible to the people who need it.
This is the two-job problem.
What a SCADA historian is actually designed to do
A SCADA historian exists to support operations. It stores tag values at high frequency so operators can review recent history, investigate alarms, and monitor process behaviour in real time. The data model is built around tags. The access model is built around the control system.
This works well for what it was designed for. When an operator needs to understand what happened in the last four hours, a SCADA historian is exactly the right tool.
But "what happened in the last four hours" is a different question from "how has this process trended over the last six months." And "what's the yield variance between the morning and afternoon shift" is a different question again. So is "can I correlate this batch parameter with our quality rejection rate for the last 200 batches."
These are analytical questions. They require longer time horizons, cross-system context, and access from tools that engineers and analysts actually use. Tools like Excel, Power BI, Python, and Grafana. Not the operator screen with a SCADA historian which typically stores data for a couple of weeks max.
Two jobs, two different requirements
The tension is real and well-documented. Industrial data was historically consumed by engineers and maintenance crews. Now it's needed by IT, financial teams, supply chain, equipment providers, and management. All of them working outside the OT environment, in different tools, with different expectations.
IT/OT convergence is partly about resolving exactly this gap: operational technology generates the data, information technology needs to act on it. Bridging that gap requires data to move from the OT world into tools and systems that the IT world can consume.
Most SCADA historians are not designed for this. They're designed for the first job: operational access, high-frequency storage, tag-based retrieval from within the control system. Asking them to also serve as the analytics layer for the whole organisation is asking them to do a job they weren't built for.
What good looks like
The answer isn't to replace your SCADA historian. It's to not ask it to do both jobs.
A dedicated industrial data platform sits alongside your SCADA system. It collects the same data — or more of it, from more sources — and stores it in a way that's optimised for the second job: long time horizons, cross-source context, open interfaces. Engineers query it in Grafana. Analysts query it from Excel. Data scientists query it from the Jupyter Notebooks. At the plant level, it connects to your MES, your ERP, your lab data, your quality system. The SCADA historian keeps doing operational access. The data platform handles the analytics layer.
This is increasingly the architecture pattern in process manufacturing. IT/OT convergence research from Artefact describes historians as essential for "historical analysis, continuous improvement, and AI applications" but only when the data is structured and accessible outside the OT environment.
The Ignition angle
If you're running Ignition by Inductive Automation, this distinction is particularly relevant. Ignition's built-in historian, the Core Historian, introduced in 8.3 and backed by QuestDB, is a fast, well-designed operational historian. It's excellent at the first job.
Ignition also went a step further than most SCADA platforms: with Ignition 8.3, they introduced a public API that allows module developers to implement their own historians. They explicitly made Ignition a platform for building historians, not just a platform with a historian. That's a significant philosophical choice — one that acknowledges that different use cases call for different tools.
Ignition integrators in the community have been exploring exactly this. Jasper Louage of Mustry Solutions has published a walkthrough showing how an external historian module connects to Ignition 8.3, collecting tags configured in Ignition Designer and making them available in a purpose-built industrial data platform. The setup video is worth watching: Factry Historian Ignition module — setup walkthrough.
The two-job problem isn't a criticism of SCADA historians. It's a structural observation about what different parts of your organisation need from production data and why the answer is usually two purpose-built tools working together, not one tool stretched beyond its design.
Factry Historian is an open industrial data platform for process manufacturers. It connects to your existing OT infrastructure, including Ignition, and makes production data accessible to the whole organisation. See how it works.
.png)
.png)
