|
If you run plant, fleet, or fixed assets in a machinery-intensive business, you almost certainly already have a CMMS. Scheduled maintenance, work order history, an asset register — that ground is well covered, and covered well, by tools built for exactly that job.
So when we built AssetDriver, we didn't build another one of those.
The gap a CMMS leaves behind
CMMS platforms are built around the asset: what it is, when it's due for service, what's been done to it. That's the right structure for planned maintenance. But it's the wrong structure for a different question, one that most teams end up answering in a spreadsheet, a OneNote page, or someone's memory:
Why is this happening, and what are we doing about it?
A CMMS will tell you a pump failed on three separate occasions this year. It's rarely built to help you see that all three failures traced back to the same root cause, or that a symptom logged by a field engineer in March was an early warning for the failure in June. That's not a criticism of CMMS tools — it's just not the problem they're solving. Root cause, recurrence, and cross-asset patterns need a different kind of record.
What FRACAS actually means in practice
FRACAS — Failure Reporting, Analysis, and Corrective Action System — sounds like defence-industry jargon, but the idea is simple: every fault, near-miss, or anomaly gets logged as an event in its own right, with enough structure to analyse afterwards. Not just "what broke," but symptom, diagnosis, root cause, who found it, what was done, and whether it actually got resolved or just patched.
Done properly, this turns a pile of incident reports into something you can query: which asset types fail most often, which root causes recur across sites, which symptoms reliably precede a failure. That's the layer AssetDriver is built around.
Where AssetDriver actually sits
AssetDriver isn't trying to replace your CMMS, your compliance tracking, or your asset register. It sits alongside them, doing one job well: capturing and analysing the fault and observation history that those systems typically aren't built to hold onto.
A few things that fall out of that focus:
Event-anchored, not asset-lifecycle-anchored. Every record — a fault, a field observation, a flagged anomaly — is captured on its own terms, then linked back to the asset it concerns.
Not every record is a breakdown. AssetDriver also captures proactive observations and flagged anomalies that get reviewed and cleared with no action needed — which matters if you want the system to help you catch problems before they become failures, not just log them after the fact.
Your own isolated database. Each client gets a dedicated Azure SQL database, hosted on AssetDriver's own environment by default — genuine data separation, with a transfer path into your own tenant later if you want to bring it in-house.
Customisable, not off-the-shelf rigid. Terminology, fields, and workflow adapt to how your team actually talks about faults — whether that's "issues," "insights," or "interventions."
The short version
AssetDriver: the Issue Management System with driven analytics for faults and FRACAS — hosted and customisable. It's not a CMMS replacement. It's the layer that tells you why things keep failing, sitting on top of whatever you're already running.
If that gap sounds familiar, we'd be glad to walk you through it.
Recent Posts
