Drill and Blast Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the missing as drilled record happen so often?

Because design data and outcome data both already exist in digital form, and execution data does not.

The design comes out of a blast design package as a file. Fragmentation photographs come off a phone. Dig rate sits in the fleet management system and crusher power draw sits in the plant historian. A developer scoping this project sees two ends that can be connected with integrations and one middle that requires putting a tablet in a driller's hands in a pit with no coverage. The integrations are quotable. The tablet is a change management problem with an offline requirement, so it slides.

What gets delivered is a reporting layer that joins intent to result. It looks impressive and it cannot answer a single useful question, because everything that varies between the two lives in the gap. The design says eighty nine holes at one hundred and fifteen millimetres, eight and a half metres deep with two point six metres of stemming. Reality is a hole that hit a void at six metres, three collapsed overnight after rain, two redrilled four hundred millimetres off pattern because the rig could not track over a boulder, and four wet enough to need an emulsion rather than the planned dry product. Every one of those changes the energy distribution in the rock and every one of them is on paper.

The fix is to make execution capture the first release, not the last. Hole level records with designed and actual collar position, actual depth, water status, ground condition and a redrill link back to the original hole, captured at the rig, offline first, by the person who drilled it. Write the acceptance test into the scope: pick a pattern from last month, and the system must show which holes deviated from design and how. If a proposal leads with dashboards, it is a reporting project and the gap you are paying to close will still be there.

What goes wrong when the hole and deck data model is wrong?

This is the failure that forces a schema rebuild in month three, and it is entirely avoidable in the first hour of design.

The mistake is modelling a blast as one record with a total kilograms field. It feels reasonable, because that is how the explosives invoice reads and how most spreadsheets are laid out. It is wrong because a hole is decked. A single hole may carry a bottom charge of one product, an inert deck, a second charge of a different product and stemming, and the whole point of the exercise is to know where the energy sat in the column.

Once total kilograms is the unit, several things become permanently impossible. You cannot compute powder factor for the part of the bench that matters. You cannot reconcile a supplier invoice line to what physically went into the ground. You cannot vary charge by hole using drilling data, because there is nowhere to record the variation. And you cannot compare two patterns that used the same total product in different distributions, which is the comparison that actually teaches you something.

The right shape is straightforward and the developer should draw it before you sign anything. Design hole and actual hole as separate linked records. Decks as children of a hole, ordered, with a type and a length. Product consumption recorded at deck level and product agnostic, so an Orica product and a competitor's product occupy the same field. A blast identifier that propagates downstream to the muckpile, to the trucks loading from it and to the crusher feed window, because without that stamp the correlation between design and outcome cannot be computed even in principle.

Why do the rig, monitor and design package integrations break after launch?

Each of these is a different problem and teams routinely price them as one line called integrations.

Rig telemetry and measure while drilling channels come out of an original equipment manufacturer portal in that vendor's own format, and the join back to your hole record depends on your hole naming convention, which is yours alone. A mixed fleet makes it worse: high precision navigation on two rigs and nothing on the rest means half your holes have surveyed collars and half have an operator's estimate, and a build that assumes uniform data quality will silently treat both as equivalent.

Vibration monitors are usually a contractor's equipment producing reports rather than a data feed, and the useful thing is not the report. It is tying a reading to the blast that caused it automatically, which requires the monitor clock and the blast time to be reliable and reconciled. Clock drift on a field instrument is normal, and a build that matches on exact time will start missing associations within weeks.

The design package is the quietest failure. Round tripping a design without losing timing information takes care, and an export that drops delay assignments looks complete until someone tries to explain a result.

Protect yourself in three ways. Price each integration separately and name the vendor in the contract. Require a reconciliation report that lists holes with no telemetry match, blasts with no monitor reading and designs that failed to import cleanly, delivered to a named person. And insist that a failed match is visible rather than absent, because an empty field looks the same as a zero on every dashboard ever built.

What happens when explosives reconciliation and vibration evidence are left out?

These are the two most commonly deferred items and the two with external consequences.

Explosives are ordered, delivered, loaded and returned, and in most operations only three of those are written down. In the United States, federal explosives regulation requires licensed users to keep records of receipt, use and inventory of explosive materials, and magazine records are inspected. Your jurisdiction will have its own equivalent and you should confirm the specifics with a compliance specialist rather than a software vendor. Beyond the regulatory point there is a commercial one: without hole level consumption you cannot argue a month end invoice, so you pay what the supplier's system says.

Vibration is worse because it is adversarial and time critical. A neighbour calls about a blast, sometimes on a day you did not blast. What you need within a minute is the firing time, the measured peak particle velocity at the nearest monitor and confirmation that the design charge weight per delay was within your approved limit. Assembling that from a contractor's report takes days, and days is how a complaint becomes a regulatory matter.

The higher value half of this is preventive rather than evidential. A check that runs before the shot, flagging that a design exceeds your maximum instantaneous charge for the nearest sensitive receiver so the timing or decking is changed, is worth more than any report written afterwards. It is also cheap to build once the deck model exists, which is another reason the data model comes first.

Should you build custom or configure what you already own?

For a real share of sites the answer is configure, and we would say so before quoting.

If you are a single site running one explosives supplier's ecosystem end to end, with high precision drill navigation across the fleet and stable fragmentation, Orica BlastIQ inside that supply relationship will get you further faster than a custom project would. If design to as drilled quality control is genuinely the whole problem and you are willing to run its workflow, Maptek BlastLogic was built for exactly that and does it well. If you are already standardised on Hexagon MinePlan for planning, having blast live beside it is a reasonable answer and worth exploring before commissioning anything new.

It is also worth checking what your existing tools already do. Plenty of sites run capable packages at a fraction of their configured capability because the setup was done at commissioning and never revisited, and replacing a platform to obtain behaviour you had not switched on is an expensive lesson.

Build when two or more of these are true. You buy explosives from more than one supplier or intend to tender competitively and want a neutral consumption record. You run several sites or a quarry group where practice varies and group comparison is currently impossible. Your rigs, monitors and design package come from three vendors and the join is a spreadsheet. You have been asked to defend a vibration complaint and it took days. Or your improvement loop depends entirely on one superintendent's judgement, in which case the project is really knowledge capture and should be scoped as such.

How do hidden costs get into the quote?

Four items account for most of the overruns here, and all four are visible before kickoff if you ask.

Multi site rollout priced as a copy. Every site will insist its loading practice is the standard one, and reconciling those differences is negotiation before it is engineering. The second site costs more than people expect and the third costs less.

Integrations counted as one line. Rig telemetry, vibration monitors, a plant historian and a design file format are four separate problems with four different failure modes. Price them individually and name vendors.

The tablet application treated as a screen. Data entry has to survive gloves, dust and glare, which means large targets, two tap defaults and almost no free text. A capture app that fights the driller is abandoned within a fortnight and you are back on paper loading sheets with a system that now has holes in exactly the patterns that went wrong.

Analytics scoped before the record is trustworthy. Fragmentation prediction and dig rate models need a few hundred blasts of clean linked records before they mean anything. Buying them in the first release is paying for a curve fitted to noise.

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

Ask them to whiteboard the blast data model before you sign anything. Design hole and actual hole as separate linked records, decks as children of a hole, product consumption at deck level and product agnostic, and a blast identifier that propagates to muckpile, truck loads and crusher feed. A developer who models a blast as one record with a total kilograms field will rebuild the schema in month three at your expense.

Ask what they have integrated on a pit floor, by vendor name, and what broke. Rig telemetry, a vibration monitor, a plant historian and a design file format should each produce a specific story rather than a description of integration in the abstract.

Ask how the tablet behaves with no signal for a full shift and what happens when two people capture the same pattern. If duplicate reconciliation is an afterthought, your record will have gaps in the rushed patterns, which are the ones that went wrong.

Then sequence it to protect the budget: one site, the blast record itself, thirty blasts captured end to end before a single analytics screen gets built, because analytics on an untrustworthy record are worse than no analytics at all. Settle ownership of the code, the cloud accounts and the data in writing before kickoff. At Digital Heroes it is yours from the first commit. The whole point of this build is to stop your blast history living inside somebody else's platform, so accepting a new lock would defeat it.