How to evaluate mining maintenance and fault management software

Mining maintenance software should be evaluated against a real operating gap, not a feature count. The useful question is whether the product helps the crew preserve better fault evidence, make responsibility clearer and return a reviewable record to the maintenance process already used on site.

This checklist is for maintenance, reliability, operations, technology, cyber and procurement teams assessing fault management or field maintenance workflow software. It does not assume that the site needs to replace its CMMS or EAM.

1. Define the operating problem first

Name the exact point where information or responsibility is being lost. Examples include repeated fault discovery after shift change, weak equipment fault reports, evidence scattered across phones, unclear job ownership or reliability reviews that cannot drill back to the field work.

A product should be able to show how one agreed workflow changes that problem. If the evaluation begins with “digitise maintenance” or “add AI”, the scope is too broad to measure honestly.

2. Test whether maintainers can build the record in the field

Review the mobile workflow at the machine, not only the management dashboard. Check how quickly a maintainer can identify the asset, describe the symptom, add photos or readings, see required controls, record checks and leave a clear next action.

Look for structured capture without unnecessary administration. The field record must be useful to the person doing the work as well as the person reviewing it later.

3. Examine how fault finding is supported

If the product offers diagnostic intelligence, ask what information it uses, how source coverage is shown, what happens when the evidence is thin and where human verification remains required. Separate advisory fault diagnosis from predictive maintenance, condition monitoring and autonomous control.

Useful fault finding support should preserve the symptom, evidence, hypotheses, checks, findings, escalation and verification trail. It should not turn a generated answer into an approved work instruction.

4. Keep safety and operating authority explicit

Ask how task hazards, controls, acknowledgement gates, permits, isolations and stop conditions remain visible during the work. Confirm which site procedures and machine documents control the task and what the software does when a required state is missing.

A digital workflow can support the operating boundary. It does not replace authorised supervision, competent judgement or the site safety management system.

5. Distinguish job handover from shift handover

A single equipment fault moving from one maintainer to another is not the same record as a supervisor handing over the state of a shift. Test whether the product preserves both without losing the links back to the original fault, evidence and owner.

Review the recipient workflow as well as the sender workflow. A named recipient should be able to review the context, clarify the next action and acknowledge or decline responsibility under the agreed process.

6. Define the CMMS and EAM boundary

Establish which system owns asset master data, planned work, work orders, inventory and commercial records. Then define what the field maintenance layer captures, what it exports and what must return to the enterprise record.

File exchange, live connectors, write back and bidirectional synchronisation are different commitments. Require each one to be named, designed and approved rather than implied by an integration logo.

7. Validate low connectivity on the agreed devices

Do not accept a generic “works offline” statement. Test the supported device, the information prepared before loss of coverage, the actions available without a connection, the queue and replay behaviour, conflict handling, attachments and what the user sees when fresh data is unavailable.

The approved low connectivity workflow should be written into the pilot scope. Safety critical work must remain within the validated site and device boundary.

8. Trace reliability outputs back to their inputs

Ask which recorded events support measures such as fault frequency, time to repair, repeat fault patterns and asset history. Check what the product displays when an input is missing and whether a reviewer can drill from a measure back to the contributing work records.

Review export formats by use case. A CSV for analysis, a detailed PDF and a one page summary are not interchangeable, and none should be presented as a complete organisational backup unless that is genuinely the product contract.

9. Review the security and operating evidence

Confirm organisation boundaries, identity and access, data location, provider processing, encryption, retention, deletion, audit evidence, incident handling and the proposed support path. The answers should match the exact pilot scope and the product configuration being evaluated.

Procurement material should be versioned and reviewable. Marketing copy is not a substitute for architecture, data flow, control evidence and contractual terms.

10. Run a bounded operating pilot

Start with one site, one crew, one fleet or asset group and one maintenance workflow. Agree the baseline, measures, device and information boundary, responsibilities, support plan, stop conditions and decision criteria before the pilot begins.

The final review should show what changed, what did not, which records support the finding and what would be required for a wider rollout.

Buyer checklist

• Can a maintainer capture a useful fault record at the machine?
• Are evidence, hypotheses, checks and verification kept distinct?
• Does the safety boundary remain visible and controlling?
• Are job handovers and supervisor shift handovers handled separately?
• Is the CMMS or EAM ownership boundary explicit?
• Has low connectivity been validated on the intended devices and workflow?
• Can reliability outputs drill back to source records?
• Are security, data and provider claims supported by reviewable evidence?
• Does the pilot have a narrow scope, baseline and deliberate rollout decision?

Review where FaultPilot fits beside a CMMS or EAM, the security and procurement pathway and the structure of a 30 day operating pilot.