Pilbara operations moved their decisions into remote operations centres years ago, which means the data is already centralised. What often did not follow is a shared model, so answering one question across several mines, a rail network and a port still takes a person and a spreadsheet.
Our principal consultant spent 18 years on operational data projects for BHP, Rio Tinto, Senex Energy and Mackay Sugar, delivered while working with previous consulting employers. Those companies are not Solve8 clients.
Operations measured across networks of mines, rail and ports.
Throughput questions cross every boundary in the chain, and each link counts a tonne at a different moment. Reconciling that is a definition exercise before it is an integration exercise.
High-resolution process history where reporting has to satisfy plant, commercial and regulatory audiences that do not share a period or a unit definition.
Autonomous fleets and centralised control generate more operational data than the reporting built around them anticipated. What is usually missing is context.
Edge aggregation and buffering for assets that are not always reachable, decided at design time rather than after a year of gappy history has accumulated.
Centralising data is not the same as being able to ask it one question.
When several operations grew their own historians, each developed its own tag naming, its own idea of what counts as a delay, and its own boundary for a shift. Pulling all of it into one place does not resolve any of that. It just puts the disagreements in the same database.
The consequence shows up in group reporting, where a network-wide figure needs someone to reconcile per-site conventions every period. That person becomes the model, which works until they take leave.
A shared asset model is what removes the manual step, and it is worth more at this scale than at any other, because the reconciliation cost multiplies by the number of sites.
For operational data work, usually not, and much of the sector already runs this way. Pilbara mining has spent fifteen years moving decisions off site into remote operations centres in Perth, which means the data is already centralised and reachable. Historian modelling, reporting and integration happen wherever the data is, which is often Perth. Where a site visit genuinely adds something, we go to site. We would rather tell you a trip is unnecessary than bill you for one.
Scale and federation. A single operation can span several mines, a rail network and a port, each with its own historian and its own conventions, and the interesting questions cross those boundaries. When one site calls a delay a different thing from the next one, a network-wide answer needs either a shared asset model or a person to reconcile it by hand every time. The second option is what most sites are actually doing.
We work with the data those systems produce rather than with the control systems themselves. Autonomous fleets and remote operations centres generate a volume and variety of operational data that outpaces the reporting built around it, so the common gap is context: knowing which asset a record belongs to, what state it was in, and how that lines up with the production figure someone is being measured on.
It constrains where processing happens rather than whether the work is possible. Remote and intermittently connected assets need aggregation and buffering at the edge, with the centre receiving summarised data and reconciling later. That is a design decision to make early, because retrofitting it after a year of gappy history means deciding what to do about the gaps, and there is rarely a good answer.
Our principal consultant spent 18 years on operational data and reporting projects for BHP, Rio Tinto, Senex Energy and Mackay Sugar, delivered while working with previous consulting employers. That work included mining operational data systems and large-scale data platform delivery. Those companies are prior project experience through those employers and are not Solve8 clients.
Scoped work starts from around $3,500 for a focused assessment, for example reviewing why two sites report the same metric differently and what it would take to align them. Larger programs are quoted after scoping, because the cost depends on how many systems and sites hold part of the answer.
That is the symptom worth starting from. Tell us which metric it is and we will scope what aligning it would take.