Mining operations software: one record for pit, haul, stockpile and fuel
Mining operations software, as Mirage builds it, is an operational layer that connects what a mine already runs on, the ERP, the GPS and dispatch platform, the fuel system, the maintenance system and the spreadsheets and WhatsApp groups that still carry real data, into one record of extraction, hauling, stockpiles, equipment, fuel and maintenance per shift. Nothing is replaced; the layer is built around how the mine actually operates. At Transwin, five such systems run in production across 550 trucks and more than 100 machines.
The problem
Mining operations frequently depend on combinations of ERP systems, Excel, WhatsApp, GPS platforms, paper processes and specialised software that were never built to talk to each other. Production, equipment and fuel data end up scattered across tools that do not share a common record, and the shift report is rebuilt by hand every morning.
What we deploy
A custom operational layer covering whichever parts of the mine need connecting: extraction, loading, hauling, stockpiles, equipment, production, fuel, maintenance and reporting. It integrates the systems you already run rather than forcing the operation into another generic ERP, and gives a structured home to the processes that still live on spreadsheets or paper.
The records a mine runs on, and where each lives today
The first week of a deployment is spent writing this table for your mine. The pattern repeats: every record exists, in a different tool, keyed by a different name for the same truck or the same stockpile.
| Record | Usually lives in | What the layer does |
|---|---|---|
| Shift plan: faces, loaders, trucks, targets | A spreadsheet, a whiteboard, the dispatcher's head | Captured once per shift, becomes the plan every actual is compared with |
| Loads and trips | GPS platform, loader counters, a tally sheet | Reconstructed from telematics and weighbridge data, matched to the plan |
| Tonnes moved, by material and destination | Weighbridge tickets, truck factors, the morning report | Reconciled between tickets, trip counts and payload; stockpile balances updated |
| Stockpile levels | A monthly survey and an estimate in between | A running balance from inputs and outputs, corrected at each survey |
| Equipment status and hours | Maintenance system, operator pre-start sheets, WhatsApp | One status per asset per hour: working, standby, down, with the reason |
| Fuel issued | Pump controller, fuel cards, a logbook | Reconciled per tank and attributed per machine, per shift |
| Work orders and breakdowns | CMMS, if used; a phone call otherwise | Downtime events linked to the asset and the shift, written back to the CMMS |
| Costs | The ERP, a month later | Cost per tonne and per hour per asset, from the records above |
Inputs, outputs, systems
| Reads | Produces | Connected through |
|---|---|---|
| GPS and telematics from trucks, loaders and auxiliary equipment | Trips, cycles, queue and idle time, utilisation per asset | Telematics provider API or export |
| Dispatch assignments and shift plans | Planned versus actual per shift, per face and per loader | Dispatch system or the shift sheet as it exists |
| Weighbridge tickets and payload data | Tonnes by material, source and destination; stockpile balances | Weighbridge software or the Mirage weighbridge module |
| Fuel transactions, tank levels, deliveries | Consumption per machine and per tonne; tank variances | Fuel system or the Mirage fuel module |
| Work orders, breakdowns, inspections | Availability and downtime per asset, with the cause | CMMS or maintenance module of the ERP |
| Costs, assets, contracts from the ERP | Cost per tonne, per hour and per asset, written back for reporting | ERP connector (SAP, Oracle, Microsoft Dynamics, Sage and others) |
| Field reports, pre-start checks, WhatsApp and paper | Events attached to the right asset and shift; a form where the paper was | Mobile forms, email or chat export, as the team already works |
How it works
This is where forward-deployed engineering matters most. Mirage engineers spend time understanding how the mine actually operates (the shift structure, the dispatch process, which parts still run on paper or WhatsApp, which ERP modules are trusted and which are bypassed) before building anything. The system is then built around that reality: pulling data from the existing GPS and dispatch, fuel and maintenance systems, and providing a structured layer for the processes that currently run on spreadsheets or paper.
Each shift closes with one record: what was planned, what was moved, by which assets, with how much fuel, and what stood still and why. Exceptions, a face under target, a loader waiting for trucks, a machine down for the third time this week, reach the shift supervisor during the shift, not in the morning report.
Operational interface
- Mine map with extraction areas and equipment
- Pit-to-stockpile material flows
- Production and tonnage by shift, against plan
- Equipment utilisation and availability
- Fuel per machine and per tonne
- Operational events and exceptions, with their evidence
How do you choose between a mining ERP, a fleet management system and an operational layer?
| Mining ERP module | OEM fleet management system | Custom operational layer | |
|---|---|---|---|
| Built around | Finance, procurement, assets | One manufacturer's fleet and its dispatch | How your mine runs, across every system |
| Covers | What is keyed into it | Trucks and loaders with the OEM's units | Pit, haul, stockpile, fuel, maintenance, field reports, whatever carries data |
| Mixed fleets, paper, WhatsApp | Not its job | Partly, if other units are added | Yes: that is the gap it is built for |
| Replaces | The previous ERP | Spreadsheets for dispatch | Nothing: it connects what is there |
| Fits when | The problem is accounting and procurement | One OEM fleet, dispatch is the problem | Several systems and processes that do not share a record |
How it is deployed
Forward-deployed: engineers on site, through the shifts, before anything is built. The proof of concept usually joins one month of shift plans, telematics and weighbridge tickets for one pit, so the mine sees its own planned-versus-actual before any commitment.
- First reply
- Within two business hours, from an engineer.
- Proof of concept
- On your own data (a telematics export, a transaction log, weighbridge tickets, dispatch records), one week after the first meeting.
- Pilot
- Fixed price, on one site or one fleet, with Mirage engineers deployed with your team. You can stop after it.
- Production
- The first workflow runs in 4 to 6 weeks. A system that spans several sites or a lot of field equipment is scoped at the first meeting and can take longer.
- After go-live
- Mirage operates, monitors and improves the system in production; your team keeps the decision on every exception. More than 200 systems have been connected so far.
- Price
- An annual subscription priced by volume after the pilot, from $10,000 to launch and $1,000 a month, quoted in the first conversation.
Transwin, a Moroccan operator with 550 trucks and more than 100 machines, started with one document workflow and now runs five systems in production, fleet and fuel among them, with 12% lower fleet diesel consumption published in its case study. Mining is offered internationally; the named references today are Moroccan operators.
FAQ
See what Mirage can run in your operations
Get a custom automation plan
Tell us where your operations lose time. We send back a written plan: which workflows are worth automating, what a deployment looks like on your systems, and the shortest path to production. No commitment.
Prefer to talk it through? Book a call