July 10, 2026

Why more operational data is making mineral processing harder to manage

Mineral Processing
Data Analytics
Operational Technology
Insight

Processing facilities have more sensors, dashboards, and monitoring platforms than ever before, and yet operations teams are still asking the same questions they were a decade ago.

The problem isn’t the data. It’s the layer between the data and the decisions.

The data paradox in mineral processing

Mineral processing operations have never had access to more data. Over the past fifteen years, the industry has invested significantly in data capture infrastructure – sensors, process historians, SCADA systems, OEM monitoring platforms, laboratory information management systems. That investment has largely delivered what it promised: data is being generated at unprecedented volumes.

And yet operations teams across the industry are still struggling to answer basic operational questions quickly. Shift supervisors are pulling numbers from three different systems. Metallurgists are reconciling figures in spreadsheets. Plant managers are reviewing reports that were accurate six hours ago.

The data exists. The problem is that it doesn’t reach the people who need it, in the form they need it, at the time they need it.

"The industry has solved the data capture problem. It hasn't yet solved the insight problem."

Steven Cohen

This is the tension we see playing out consistently across mineral processing facilities – in Australia, in North America, and across the 55-plus countries Mipac has worked in. It’s not a local problem or a scale problem. It’s a structural one.

FEATURED IN MINE MAGAZINE

Mining’s data problem: why more information is making operations harder to manage, not easier

This article draws on a wider conversation between Mipac’s Steven Cohen and Brian Forrester, published in the July 2026 edition of MINE Magazine. The full interview covers where facilities waste the most operational effort, the organisational questions worth asking before the technical ones, and what good looks like in practice.

Why operational data fails to reach the people who need it

The root cause is fragmentation – and it’s largely the product of how processing facilities have grown.

Most facilities don’t build their data infrastructure from scratch. They accumulate it. An OEM platform here, a historian upgrade there, a new SCADA screen added during a capacity expansion. Over ten, fifteen, twenty years, this organic growth produces a technology environment that nobody designed as a whole – and that shows.

Multiple platforms, no single picture

A typical processing facility might have four to six separate monitoring platforms running simultaneously. OEM tools built to serve the equipment vendor’s own monitoring and support needs. A process historian that holds the raw data but requires specialist knowledge to interrogate. SCADA systems that provide real-time visibility but limited analytical capability. Laboratory systems operating in their own silo.

None of these platforms were designed to talk to each other. None of them were built to serve the operator at the front line who needs a clear picture of circuit performance at the start of a shift.

The ownership gap

There’s an organisational dimension to this that often goes unexamined. In most of the facilities we work with, nobody owns the operational data layer. Not in the way that someone owns the SCADA, or owns the process historian.

OEM platforms aren’t going to self-integrate into a facility’s broader operational picture – that’s not what they were built for, and it’s not in the commercial interest of the vendor to enable it. The integration work needs an owner inside the organisation. And in most facilities, that owner doesn’t exist.

This is an organisational problem as much as a technical one. And it’s why technology alone rarely solves it.

What this looks like in practice

Consider a base metals concentrator operating across multiple processing circuits. The facility has invested in instrumentation and monitoring systems over many years. Individually, each system functions as intended.

But here’s what the operations team is actually dealing with: the flotation circuit is monitored through an OEM platform that the process engineering team can access, but that operators on shift can’t easily interrogate in real time. The crusher and mill performance data lives in the historian, which requires a specific login and familiarity with the query interface. Laboratory results – the feed grades, concentrate assays, and tailings figures that determine whether the circuit is performing – come through a separate system on a different update cycle.

When the metallurgist sits down to prepare the morning review, they spend the first hour reconciling figures across all three. By the time the report reaches the plant manager, the most recent data point is already several hours old.

When something goes wrong – a drop in recovery, an unexpected change in feed characteristics – piecing together what happened and why can take hours. The data exists. It just doesn’t exist anywhere useful.

"The most visible waste is manual data reconciliation: time spent reconstructing the past rather than managing the present."

Steven Cohen

This is a composite picture, but it’s a familiar one. The specific systems vary. The symptoms don’t.

What a well-integrated operational data environment actually looks like

The most important thing to understand is what a well-integrated data environment is not. It’s not a data lake. It’s not a single-vendor platform replacement. And it doesn’t require ripping out existing infrastructure.

The most effective approaches create a connective layer across existing systems – bringing data together without replacing the systems that generate it. The goal is a single operational view: process performance, equipment health, and quality data in one place, structured around how the operation actually runs.

Contextualisation over aggregation

There’s a meaningful difference between a system that aggregates data and one that contextualises it. Aggregation gives you everything. Contextualisation gives you what matters.

A well-designed operational data environment doesn’t present all information equally. It surfaces anomalies. It structures data around the decisions people actually need to make. What does an operator need to know at the start of a shift? What does a plant manager need for a morning review? What does the metallurgist need to diagnose a recovery problem quickly?

The system should answer all three questions – differently, for each audience – from a single underlying data environment.

A practical diagnostic

A useful starting point is a question we often ask facilities early in an engagement:

Can your operators answer the ten most important operational questions for their shift without leaving one screen?

If the answer is no, that’s the integration problem made concrete. The follow-up question – why not? – usually maps directly to where the gaps are.

From there, the practical work is straightforward to scope, even if it isn’t always simple to execute: identify where data lives, who owns each system, what decisions each audience needs to make, and what information those decisions require. Most facilities have never done this audit. It’s the prerequisite for everything else.

Frequently asked questions

Why do mineral processing facilities struggle with operational data despite significant technology investment?

Most facilities have invested heavily in data capture - sensors, historians, SCADA, OEM monitoring platforms - but these systems were built independently and don't share a common data model or interface. The result is fragmentation: data exists across multiple platforms that operators can't easily access or reconcile in real time. The gap isn't in data generation; it's in the integration and contextualisation layer that turns data into actionable operational insight.

What is the difference between a data lake and a decision-support environment in mineral processing?

A data lake stores large volumes of raw operational data in a central repository, making it accessible for analysis - but typically requiring specialist skills to query and interpret. A decision-support environment goes further: it contextualises data, surfaces anomalies, and presents structured information tailored to the decisions specific roles need to make, from shift operators to plant managers. The distinction matters because most processing facilities need the latter, not just more storage.

How long does it typically take to integrate operational data systems in a mineral processing plant?

The timeline depends heavily on the number of existing systems, the quality of available data, and whether integration is being retrofitted into a running facility or designed into a new one. Brownfield integration - the most common scenario - is more complex because systems have grown organically over years and often lack standardised data structures. A realistic scoping and design phase typically takes four to eight weeks; implementation varies by scope, but targeted integration projects can deliver initial operational visibility within three to six months.

What operational data should mineral processing facilities prioritise integrating first?

The highest-value starting point is typically the data that directly drives recovery and throughput decisions: process performance indicators (feed rate, grind size, reagent dosing), real-time equipment health signals, and laboratory assay results. These three data streams - process, equipment, and quality - form the core of most operational decisions. Integrating them into a single view, accessible to operators and metallurgists in real time, addresses the majority of manual reconciliation effort and decision latency.

What is the biggest organisational barrier to better operational data integration in mining?

The most consistent barrier we observe is the absence of a clear internal owner for the operational data layer. OEM platforms, SCADA systems, and process historians each have an owner - but nobody is responsible for how data flows between them and how it reaches operational decision-makers. Without that ownership, integration remains a retrofit problem rather than a managed capability. Assigning clear accountability for the operational data environment is often the most important organisational step a facility can take before any technology investment.

Talk to Mipac about your operational data environment

If your operations team is spending time reconciling data that should already be integrated, or if you’re making decisions with information that’s hours out of date, we’d like to understand the specifics of your environment.

Mipac works with mineral processing facilities to close the gap between data infrastructure and operational decision-making – without replacing the systems already in place.

Interested in reading more articles on operational excellence in mineral processing

Why more operational data is making mineral processing harder to manage

Enter your details to receive our newsletter