Why we built a Findings system, not another CMMS
CEO & Data Architect
If you run plant, fleet or fixed assets in a machinery-intensive business, you almost certainly already have a CMMS. Planned 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 | Findings, we didn’t build another one.
The gap a CMMS leaves behind
A CMMS is 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. It’s the wrong structure for a different question, one 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 three times this year. It’s rarely built to show you that all three failures traced back to the same root cause, or that a symptom a field engineer noted in March was an early warning of the failure in June. That’s not a criticism; it’s just not the problem a CMMS is solving. Root cause, recurrence and cross-asset patterns need a different kind of record.
The finding is the record
That different kind of record is the finding. A finding is anything that deserves a closer look: a fault, a field observation, an analytics-flagged anomaly, an inspection result. It gets captured as an event in its own right, with enough structure to analyse later. Not just “what broke,” but the symptoms, the diagnosis, the root cause, who raised it, what was done, and how it ended.
This is the idea behind FRACAS (Failure Reporting, Analysis and Corrective Action System). It sounds like defence-industry jargon, but the principle is simple: if every finding is recorded consistently, a pile of incident reports becomes something you can query. Which asset types fail most often. Which root causes recur across sites. Which early symptoms tend to come before a failure.
Where AssetDriver | Findings sits
AssetDriver | Findings doesn’t replace your CMMS, your compliance tools or your asset register. It sits alongside them and does one job well: capturing, investigating and closing out findings — the history those systems aren’t built to hold.
A few things follow from that focus:
Finding-first, not asset-first. Every finding is captured on its own terms, then linked to the asset it concerns.
Not every finding is a fault. Some are reviewed and cleared with no action needed, or closed as no fault found. Recording those outcomes matters: it’s how you stop chasing the same false alarm twice, and how the system helps you catch problems early rather than only logging them afterwards.
Work orders when they’re needed. Where a finding does need action, work orders can be raised and managed directly, or passed into the CMMS you already run.
Your own isolated database. Each client gets a dedicated Azure SQL database, hosted in our environment by default, with a transfer path into your own tenant if you later want to bring it in-house.
Fits how your team talks. Terminology, fields and workflow adapt to your language, whether you call them findings, issues or interventions.
The short version
AssetDriver | Findings isn’t a CMMS replacement. It’s the layer that tells you why things keep failing, and what was done about it, sitting alongside whatever you already run.
If that gap sounds familiar, we’d be glad to walk you through it.