Industrial analytics projects in Australian mining, processing, manufacturing and energy rarely fail because the model is wrong. They fail underneath it: historian tags that were never reconciled, no asset context over raw signals, site definitions that disagree, and nobody owning the model after go-live. Fix those five conditions first and the analytics layer earns trust.
Key takeaways
- The most common failure is building analytics on historian tags that do not reconcile to the signed production report. The report wins every time.
- Without an asset model over raw tags, every question routes through one tag expert and self-service analytics quietly stops.
- Industrial analytics needs a named owner and a change process tied to plant changes, or it drifts into precise, wrong charts.
- Multi-site programmes fail on definitions (availability, delay, tonne) far more often than on technology.
- Start with one recurring decision, work back to the data it needs, and build the narrow view for that person first.
Why do industrial analytics projects fail so often?
Most projects turn on a single moment about six weeks after the first dashboard goes live. Someone from the plant compares the new availability figure with the monthly production report and finds a four per cent gap. The analytics team explains the difference correctly. It changes nothing, because the production report is the number finance signs and the board reads.
From that week the dashboard gets opened less. Within a year it is a renewal line item nobody can defend.
The model is usually the most competent part of the exercise. The failure sits in the data layer that was assumed to be sorted. Across our consultants' careers, including plant, production and reporting systems work in BHP, Rio Tinto and Senex Energy environments, the same five failure modes appear often enough to name.
The pattern is documented outside industry too. A Gartner survey published in October 2024 of more than 3,100 technology executives found only 48 per cent of digital initiatives meet or exceed their business outcome targets. BCG's 2020 study of 825 senior executives found 70 per cent of large digital change programs fall short of their objectives.
The cost is real. An ABB survey of 3,215 plant maintenance decision makers, published in 2023, put unplanned downtime at AUD $349,000 an hour for a typical Australian industrial business, against a global average of AUD $194,000. Analytics that reaches the supervisor making that call is worth a great deal.
Failure one: building on tags nobody reconciled
The most common failure is also the most avoidable. A team builds analytics directly on historian tags without first establishing that those tags produce a total anyone agrees with.
A historian tag is a raw measurement with a compression setting. Ask it for last month's tonnes and you get an integral that moves with the compression deadband, the interpolation method, how calibration gaps were handled and whether the query was time weighted. Two competent engineers can query the same tag and get different tonnages, and both can defend their working.
A model on top inherits every one of those choices silently. The first time anyone compares it with the reported figure, the gap is unexplainable to everyone who was not in the room when the query was written.
The production report wins, and it should. It is reconciled against despatch, inventory movements and a physical stock count. Until the measurements underneath go through a documented balance, an analytics project is building a second set of books.
The fix comes first: one agreed figure per measurement, produced the same way every period. Our piece on why SCADA, the historian and the ERP disagree on tonnes covers the method.
| Analytics first | Reconciliation first | Impact | |
|---|---|---|---|
| Starting point | Connect to historian, start modelling | Agree one number per measurement, then model | Defensible |
| First disagreement | Analytics layer loses to the signed report | Both come from the same reconciled source | No conflict |
| Audit position | Query logic lives in one person's notebook | Documented method, repeatable every period | Auditable |
| Typical outcome | Dashboard retired in year two | Figure becomes the operational reference | Durable |
Failure two: no asset context, so every question needs a translator
Raw historian tags are a flat namespace of cryptic names. A tag called CV104_WT_PV means something to the engineer who commissioned it and nothing to anyone else. There is no hierarchy and no way to ask "show me every weightometer on the secondary crushing circuit" without a person who already knows.
So every question routes through that person, and requests queue behind their other work. This is where self-service analytics dies. Nobody raises a defect; people simply stop asking.
The remedy is an asset model: a maintained hierarchy over the raw tags with structure, units, equipment types and relationships. In a PI environment that means Asset Framework templates built to survive plant changes, covered in our note on designing PI Asset Framework templates that last. In an AVEVA or Citect estate the same discipline lives in the equipment hierarchy and naming standard.
ISA-95, published internationally as IEC 62264, describes integration across levels from sensors to business planning. Asset context belongs in the middle, at the manufacturing operations layer. Skip it and you end up asking level four questions of level one data.
Failure three: nobody owns the model after go-live
An analytics model describes a plant at a moment in time. Then the plant changes: a screen is replaced, a circuit rerouted, an instrument moved, a reason code added, a line debottlenecked.
Each change invalidates a small piece of the model, and none triggers a review because the project closed. After two years the analytics layer describes a plant that no longer exists. The charts are precise and wrong, which is worse than visibly broken.
Delay accounting models decay the same way. Our guide to how Ampla delay accounting drifts from the plant it was built for describes the mechanism.
The answer: a named owner, an agreed response time, a change process that reaches the model whenever the plant changes, and periodic review against reality. Our view of what ongoing support and improvement should cover applies to analytics models as much as production systems.
Failure four: scoped as technology when the hard part is definitions
Analytics gets funded as a technology project. The hard part is almost never technical.
Take a group with three sites, each with its own acquisition and commissioning history. One excludes planned maintenance from availability, one includes it, the third excludes it only when the shutdown was in the annual plan. One records delays over two minutes, another uses five. One reports wet tonnes, the next dry.
Every definition is locally defensible. Aggregate them without agreement and the group number is meaningless, and site managers will work that out faster than the project team. Each site then goes back to its own figure.
Getting agreement is slow, political work. Scope it explicitly, give it time and give it a decision maker, or find out during user acceptance testing with no authority to settle it.
Your analytics output is not being used. Which problem do you have?
- Numbers disagree with the signed reportA reconciliation problem. Fix the measurement balance first.
- Every question needs the one tag expertAn asset context problem. Build the hierarchy over the tags.
- It was right at go-live, drifting nowAn ownership problem. Nobody maintains the model.
- Three sites will not accept the group figureA definitions problem. Agree the terms before the platform.
- Correct, agreed, and still nobody opens itAn audience problem. It was built for the wrong reader.
Failure five: the dashboard built for the steering committee
Most industrial dashboards are designed for the group that funded them: monthly, aggregated, colour coded against target. They answer whether things are broadly on track. Nobody acts on that answer.
The decisions that move an operation happen at 6am, when a supervisor picks which job the maintenance crew takes first, and at shift change, when a metallurgist adjusts a setpoint. They need fewer numbers, current data, their own equipment and enough context to act without opening three systems.
A committee dashboard gets opened twelve times a year. A supervisor view gets opened twice a shift and drives the change that eventually shows up in the monthly number. Build the second one first.
The reporting stack matters. Pointing a reporting tool straight at millions of raw historian events builds a slow second historian. Our note on getting historian data into Power BI covers the aggregation decisions that keep an operational view fast.
Where does AI genuinely help industrial analytics?
Machine learning on operational data has a real place, narrower and more useful than the marketing suggests.
- Anomaly detection on a named failure mode. A model trained on vibration, temperature and load across similar pumps can flag a developing bearing fault earlier than a fixed threshold. It needs a named failure mode, instrumentation that sees it and enough historical examples. See our piece on asset health for Australian mining operations.
- Classification. A model suggests a likely delay reason code from surrounding process conditions, and the operator accepts or overrides. See where a trained model beats hand-written delay rules.
- Alarm rationalisation. Finding chattering, duplicate and standing alarms is a clustering problem over historical alarm records. ANSI/ISA-18.2 (adopted internationally as IEC 62682) covers the alarm management lifecycle, and EEMUA 191 guidance treats an average below one alarm per operator per ten minutes in steady state as likely acceptable, and more than ten new alarms in ten minutes as a flood.
When should you not use machine learning on operational data?
- Numbers someone signs. Production figures feeding royalties, emissions data feeding a Safeguard Mechanism obligation and metal accounting feeding a financial close need a documented, deterministic method an auditor can follow.
- Data that does not reconcile. A model trained on disagreeing tonnes has learned the disagreement.
- Known physics. A mass balance beats a regression that approximates one: it is explainable and extrapolates correctly.
What does a successful industrial analytics project look like?
The projects that work start with one decision somebody makes repeatedly and work backwards to the data that decision needs.
- Name the decisionOne recurring call, one named person, one time of day
- List what they needThe few numbers that would change the call
- Trace each to sourceWhich system, which tag, which period, summarised how
- Reconcile firstAgree one figure per measurement before modelling
- Build the narrow viewFor that person, at that moment, nothing extra
- Assign the ownerNamed maintainer and a change process from day one
"Improve reliability" is not a decision. "At Monday planning, choose which four of eleven flagged work orders go into this week's window" is one, and you can work out exactly which numbers would change it.
Tracing to source is where surprises arrive, and week two is a better place to meet them than month six. Of four numbers a decision needs, it is common to find one exists nowhere, one is manually entered, one exists in two systems with different values and one is fine.
A narrow view for one decision can be delivered in weeks and judged honestly, because the test is whether the decision changed.
- Weeks 1-2Decision and source reviewName the recurring decision, trace every number it needs back to a system and a tag
- Weeks 3-6Reconcile the measurementsAgree one figure per measurement, documented and repeatable each period
- Weeks 5-8Asset contextBuild the hierarchy and templates so questions can be asked without a translator
- Weeks 9-12The narrow viewDeliver for the one role, at the one moment, and test whether the decision changed
- OngoingOwnershipNamed maintainer, change process tied to plant changes, periodic review against reality
- Time to first defensible numberWeeks, not quarters
- Arguments about whose figure is rightSettled once, documented
- Analytics questions needing the tag expertMost of them removed
- Model still describing the plant in year threeOnly if someone owns it
Where to start
If you have an analytics layer nobody opens, do not replace it yet. Work out which of the five failures you have, because each needs a different fix. A week of review settles it: compare the output with the signed report, count how many questions needed the tag expert last quarter, and check when the model was last reviewed against the plant.
If you are about to start, spend the first fortnight on the decision and the sources. The platform is easier to change later than a data layer built on unreconciled measurements. Where analytics serves several sites, read what a remote operations centre needs from the data layer.
How Solve8 can help
We build the data layer underneath industrial analytics for asset-heavy operators: reconciliation, asset context and the narrow operational view, then we stay on as the named owner if you want us to. See our mining, energy and manufacturing data work, our system integration and data and BI services, or talk to our team about reviewing the dashboards nobody opens.
