Mining Operations Software Problems: The 7 That Cost Real Tonnes, and How to Avoid Them

Why does the optimiser get scoped before the reconciliation spine?

The demo that wins the internal argument is always the one with the map, the trucks moving, and an algorithm reassigning haulage when the crusher goes down. It is a genuinely good demo. It is also the wrong first release for almost every mid sized operator, and this is the single most common scoping failure in the category.

An optimiser is arithmetic on top of data. If your load counts, your scale tickets and your survey volumes still live in three systems with three timestamps and no shared identifier for a load, the optimiser is making decisions on inputs nobody trusts. The dispatcher notices within a fortnight, goes back to the whiteboard, and the project is dead while still technically live.

The correct first object is the material movement event: one record with one identifier, written the moment a load leaves the loader, carrying source pit, bench and blast block, destination, operator, truck, timestamp and estimated tons from the loader payload scale. Scale tickets attach by truck plus time window, survey volumes by stockpile entity and date range. Once that spine exists, reconciliation becomes a live variance the dispatcher sees the same shift rather than a forensic exercise at month end.

The practical test for your scope: can the first release tell you which day, which pit, which shift and which truck opened the gap? If not, you have bought a nicer whiteboard. Build the spine first and refuse the optimiser in phase one.

What goes wrong when scale ticket and production history is migrated?

Every operator wants their history in the new system so variance trends and failure patterns have depth from day one. Three things reliably break.

The first is the ticketing source. A DOS era ticketing package that the vendor stopped patching years ago may have no export worth the name, which means a database dump or a serial port read off the indicator head. That is real work, it is doable, and it needs to be assessed before anyone quotes rather than discovered in month three.

The second is stockpile identity. Historical tickets reference stockpiles by whatever name the scale operator typed, and the same pile appears as four different strings across two years. Survey records reference the same pile by a different convention entirely. Migrating without reconciling those names produces a variance history that looks like chaos and teaches you nothing.

The third is bucket factors and density assumptions. Old production numbers used factors that were correct at the time and have since drifted, so a straight migration of tonnage figures imports errors as facts. Migrate the underlying counts and weights, keep the applied factor as a dated field, and recompute rather than importing conclusions.

The sequencing that works is to migrate one year, reconcile it against what the operation reported to its royalty holders and its accountants, and only then load the rest.

Why do telematics and scale integrations break after launch?

The mixed fleet is the thing that keeps costing money after go live. Cat, Komatsu, Volvo, a couple of Doosans and two Hitachi excavators means four telematics portals, four data models, and four sets of fault codes that do not mean the same thing. VisionLink has an application interface. KOMTRAX has a more limited one. The 2011 Volvo has a wire.

The break after launch is rarely the connection. It is an interface version or authentication change at the manufacturer, a machine sold with its feed going quiet while the equipment record stays open, or a replacement hour meter resetting to zero so the maintenance schedule computes a service interval thousands of hours in the past. That last one is how a truck goes 140 hours past a service window while the dashboard shows compliant.

On the scale side the equivalent failure is the indicator head. A serial read is fragile to a hardware swap, and a scale house that upgrades its software will change a ticket format overnight.

Three defences are worth building. Normalise everything into one equipment record with one hour meter, one fuel burn and one fault stream, so a source change is a mapping problem rather than a schema problem. Alert on silence: a feed that stops reporting is more dangerous than one reporting wrong values, because nothing looks broken. And treat a meter reset as an event requiring a human decision rather than an arithmetic surprise.

What happens when MSHA recordkeeping is not modelled properly?

An inspector arrives unannounced and asks for pre shift examination records for the last ninety days on a specific highwall. Under 30 CFR Part 56 you are required to have them, examined and recorded before miners begin work, with hazards noted and corrective actions documented. If your system treats an examination as a document rather than as a legal record, you cannot produce a continuous chain and the conversation goes badly. A 104(d) order is not a fine, it is a shutdown.

Generic inspection tools produce ninety PDFs. They do not know what a working place is, they do not check whether the examiner's certification is current, and they cannot show hazard noted, hazard corrected and hazard verified as one linked sequence. They also cannot tell you that a record was created at 8:40 for a six o'clock shift from the car park.

Model the domain properly and this stops being fragile. Examinations tied to your actual working places, geofenced so a record cannot be created outside the pit boundary, tied to an examiner whose certification status is checked before signature is allowed. Hazards as tracked objects with an owner, a due date and escalation to the superintendent past twenty four hours.

The adjacent gap operators forget is intake. MSHA correspondence, third party inspection reports and blast records arrive as scans, and if they land in a shared drive folder rather than as structured records with cited standards and abatement deadlines, the compliance calendar exists only in one person's head.

Should you build custom or configure what you already own?

Two shapes of operation should not build, and both are common.

If you run a single pit with under twenty pieces of mobile equipment, one scale house, one commodity, and a plan that changes quarterly, a competent scale package plus SafetyCulture iAuditor plus your original equipment manufacturer's portal plus a good bookkeeper will run that operation properly. Spending ninety thousand dollars to replace that stack is not a return, it is a preference.

If you are a large single site open pit with eighty or more trucks and a mine plan that looks like the textbook, Wenco and Modular Mining DISPATCH were built for you. They work, the assignment logic assumes the shape of mine you actually run, and rebuilding them is vanity. Buy one, deploy it properly, and put the custom money into the integrations around it.

The build case sits in the middle and it announces itself as a group of signals rather than one. Your reconciliation gap has stayed above three percent for two straight quarters and nobody can explain it. You run more than two pits or more than one commodity, so a single site data model fights you. More than thirty percent of outbound tonnage moves on trucks you do not own. Your plan changes weekly because you are chasing spec, a customer or a wet season. And one superintendent or dispatcher with a decade of tenure holds spreadsheets that are load bearing for the whole operation. That last signal is the honest one, and the right time to start is eighteen months before he retires, not after.

How do hidden costs get into the quote?

A focused first release covering dispatch capture, the material movement spine, ticket reconciliation and pre shift examination records runs 60,000 to 130,000 dollars over 12 to 16 weeks in Digital Heroes delivery experience. A full platform adding telematics normalisation, maintenance automation, grade control integration, hauler commercial flows and forecasting runs 150,000 to 400,000 dollars phased over 6 to 12 months. The overruns come from four places.

Distinct telematics sources are the first. Each one carries its own authentication model, its own idea of a machine hour and its own fault taxonomy, so the fourth original equipment manufacturer costs almost as much as the first.

Scale house access is the second. If the ticketing package has no interface and the answer is reading a serial port off a Rice Lake or Cardinal indicator head, that is a genuine engineering task and it belongs in the quote rather than in a change order.

Offline is the third and it is the one most underestimated. A pit with no signal below the second bench is not an edge case, and offline means local write, queued synchronisation and an explicit conflict resolution policy, not caching.

Regulatory and commercial surface is the fourth. Part 46 versus Part 48 training records, state reclamation reporting, and royalty calculations for several mineral rights holders each add real scope. Survey package integration is its own item, because Deswik, Surpac and Vulcan export differently and block model work is harder than it looks from outside.

What separates a mining build that works from one that fails?

Ask a developer to model a material movement event on a whiteboard, cold, in the first meeting. If they cannot explain why a load has a source bench, a destination that might be a stockpile or a crusher, an estimated payload from a loader scale and a separate confirmed weight from a static scale, and why those numbers legitimately disagree, they will build you an attractive application that reproduces your current reconciliation gap.

Ask what they have actually integrated, by name. VisionLink, KOMTRAX, AEMP 2.0 feeds under ISO 15143-3, Rice Lake or Cardinal indicator heads, Sage 100 Contractor, Viewpoint Vista. A general integration claim means the surprises arrive in month five with your budget spent.

Ask how they handle offline, and listen for local write, queued sync and a named conflict policy rather than reassurance.

Ask how the dispatcher's screen will look, and be suspicious of anything that does not resemble his whiteboard. Adoption in a dispatch trailer is a design constraint, not a training problem. Every reassignment should write a record with a reason code, which is how you eventually answer why loader utilisation is 61 percent when the supplier model says 78.

Then settle ownership in writing before the first invoice. The repository, the schema and every row should be yours, with direct access rather than escrow arrangements. Renegotiating after a developer holds four hundred shifts of your production and safety records is not a negotiation. At Digital Heroes the client owns the code and the data from the first commit.