Asset reliability
MTBF and MTTR by machine, downtime and interventions by asset. The basis for deciding between repairing and replacing.
Feature
Reports don’t fix poor logging
Worth saying up front: a beautiful dashboard built on work orders that say "checked and working" still tells you nothing. What makes a report useful happens months earlier, in how work orders get closed.
What indicators are measured in maintenance?
The usual ones are four. MTBF, mean time between failures, says how long a piece of equipment holds up before it breaks down again. MTTR, mean time to repair, how long it takes to bring it back into service. Preventive compliance, what percentage of what was planned actually got executed. And cost per asset, how much each piece of equipment has cost so far between labor and materials. From these you decide what matters: whether the preventive plan is working, which equipment is worth replacing, and which contract is profitable.
Why reports go unused
Not because they’re missing. Because nobody believes them.
- Hours get logged at the end of the week, so the cost per job is an estimate.
- Half the staff works under the same account, so the per-technician report means nothing.
- Work gets booked to the site and not to the equipment, so there’s no cost per asset.
- Work orders get closed without a downtime cause, so you can’t analyze what fails and why.
- Every report has to be built by exporting to a spreadsheet and cross-referencing by hand.
What reports exist
More than sixty, grouped by the question they answer.
Costs
Cost by asset, by client and by period, with labor and materials broken out. And profit by client, which tells you which contract pays off.
Preventive compliance
Annual plan, preventive hours by month and maintenance log by equipment. What was planned against what actually got done.
People and shifts
Hours by technician and by month, non-productive hours, shifts, absences and a summary by team lead. With its shift map when there are routes.
Materials and inventory
Materials consumed in work orders, valued inventory, asset movements between sites and batch traceability.
By client and by site
Work orders by client and by trade, incidents by store and their evaluation. The report handed over in the follow-up meeting.
Dashboard
The overview for the day to day: what’s pending, what’s been closed and what’s off from plan.
Quality and anomalies
Anomalies detected during inspections, diagnostic and repair reports, satisfaction surveys and a log of user actions.
Shall we look at it with your way of working?
Leave your details and we will get in touch to see whether we fit. No commitment, no lock-in period.
What you see is what comes out
Every report can be filtered by client, site, asset, technician, type of work and period, and exported exactly as it appears on screen: spreadsheet, CSV, JSON or XML. It sounds like a detail and it’s what decides whether a report actually gets used. When what gets downloaded doesn’t match what was on screen, everyone ends up rebuilding the analysis by hand in a spreadsheet, and from there the system stops being the source of truth. For anyone who hands reports over to their clients, it’s also the difference between prepping the monthly meeting in ten minutes or in half a day.
What this isn’t
GMAO CLOUD ships a broad catalog of reports with filters and export, plus a dashboard. It is not a business intelligence tool, and we won’t say it is: if you need to cross maintenance data with production and purchasing data in a model of your own, the sensible move is to pull it into whatever tool you already use for that, which you can do through the public API or through export. What the product does cover, and covers well, is the day-to-day operational question and the monthly committee one.
Frequently asked questions
Which report is worth having in the first month?
Just one, and a very simple one: which work orders are open and since when. It’s the one that shows, all at once, whether the team is logging their work, whether the loop actually closes, and whether something is stuck waiting on a part or an approval. Everything else — costs, reliability, comparisons between sites — needs history, and asking for it before you have it just produces charts nobody can interpret.
How often should you check the reports?
Less often than people usually plan for at the start. Maintenance indicators move slowly, and checking them every week produces noise that gets mistaken for a trend and decisions made on variations that mean nothing. A monthly review of the operational side — plan compliance, open work orders, old pending items — and a quarterly one of the structural side — cost per asset, repeat failures, reliability — covers practically every real decision.
Why don’t my reports match what the team perceives?
Almost always because the source data is incomplete, not because the report is wrong. Work orders with no type, hours logged from memory at the end of the week, or materials nobody deducts produce flawless-looking charts that don’t describe reality. When a report is surprising, the first thing to check is always where its data comes from.
Does it calculate MTBF and MTTR?
Yes, they’re two of the available reports and they’re calculated from logged work orders. Their reliability depends on interventions being closed against the correct asset and with real times.
Can I know what each client costs me?
Yes. Hours, materials and travel are broken down by client, site and asset, and there are cost and profit-by-client reports. That’s what lets you know which contract is profitable.
Can reports be exported?
Yes, to spreadsheet, CSV, JSON and XML, and what gets exported is exactly what’s on screen, with the same filters and the same columns.
Can I build my own dashboards?
The product ships a broad catalog of reports with filters and a dashboard, but it isn’t a business intelligence tool. If you need a model of your own, the data can be pulled into your tool through the public API or through export.
How long until there’s useful data?
Activity reports are useful from the first month. Reliability ones need history: until there’s a full breakdown cycle per piece of equipment, MTBF doesn’t say much. That’s why it’s worth logging properly before you need the data.
What question can’t you answer today?
Bring it to the demo. We’ll see if a report answers it and, more importantly, what would need to be logged for the answer to mean anything.