Problems a CMMS solves (Part 2)

Part one covers operational problems: the ones you notice this week. These are the underlying ones, which take longer to hurt and cost a lot more.

They have something in common: none of them get fixed by working harder. They only get fixed by having recorded things beforehand.

1. Not knowing what each piece of equipment costs

The question that decides investments and that almost no company can answer: how much have we spent maintaining this machine.

Without that figure, the decision to repair again or replace gets made on intuition or available budget. With it, it gets made with the last few years’ cost in front of you.

What solves it. Making cost a consequence of the work instead of a separate calculation: time measured with a stopwatch inside the order and material consumed against the warehouse, hanging off the asset record.

And there’s an automation for the decision: an asset can carry its replacement cost and a warning percentage, and the system notifies you when accumulated repair spend exceeds it.

2. Not knowing which contract makes money

The same problem seen by client, and the one that surprises people most the first time.

There’s almost always a type of contract or job being sold below what it costs, and it’s been that way for years because nobody had the hours measured. It gets discovered with the hours-per-client report and the gap between estimated and actual time.

3. Knowledge that lives in two people

In almost every department there are two people who know what gets checked on each piece of equipment, where its documentation is, and what was done last time.

That’s not a team: it’s a dependency. And it gets discovered the day one of them retires, leaves, or goes on leave.

What solves it. Writing it down. Checklists by equipment family — what to check, in what order, with what reference values — defined in cascade by asset, model, subfamily, and family. It’s not a documentation project: it’s an afternoon per family.

4. Not being able to prove what was done

When a complaint, a claim, or an inspection comes in, what’s asked for isn’t an explanation: it’s a record with a date, an author, what was checked, and who signed off on it.

That can’t be manufactured afterward. Either it was recorded when it happened, or it doesn’t exist.

What solves it. Statutory maintenance — which isn’t a module, but the preventive maintenance mechanism using the checklist the regulation requires — rests on the history of orders, completed checklists, and documentation with its dates.

And one detail that breaks everything if it fails: if several people share one account, the record doesn’t identify anyone. That’s why in GMAO Cloud licenses are unlimited across all three plans.

5. Not knowing whether the plan is working

Having a preventive plan doesn’t mean it’s properly sized. In almost every facility, two opposite problems coexist: over-maintained equipment — reviewed too often and eating up hours without adding value — and equipment that breaks down between reviews.

Without history you can’t tell them apart, and frequency stays wherever it was set years ago.

What solves it. The anomalies-by-family report and the executed annual plan report. Several cycles without a single anomaly point to over-maintenance; breakdowns between reviews point to the opposite.

6. Depending on someone remembering

It’s the problem underneath almost all the others. A review that only lives on a calendar doesn’t protest when it doesn’t happen: it rolls over to next month and then to next year.

What solves it. Having preventive maintenance generate orders with an owner and a date, and doing it by checking beforehand whether the day is a holiday and whether that person is available.

7. Not being able to anticipate anything

Always working reactively, never seeing failures coming.

What solves it. Having checks record values instead of checkboxes. A checklist with a minimum and maximum turns a round into a time series, and a series lets you spot a trend. You don’t need sensors for that: you need to write down numbers instead of marking ticks.

And having usage-based wear measured with a counter that generates the order once its threshold is exceeded, instead of waiting for the calendar.

8. Findings that get lost

The quietest one. A technician notices something during a review, writes it as a comment, and nobody rereads the comments on closed orders.

What solves it. Making the anomaly an entity that turns into an incident with an owner and a date, or into an explicit decision to do nothing. If it gets logged and nothing happens, people stop logging it.

9. Information that can’t be shown

An underlying problem especially noticeable in service companies: the client asks, and the answer has to be pieced together.

How much has been done on their installation this year, what’s still pending, when the next visit is, where March’s report is. Each of those questions eats up someone’s time, and added together they’re a considerable chunk of the administrative workload.

What solves it. Letting the client see it themselves from their dedicated access: the status of their orders, downloadable reports, their assets, and their upcoming preventive visits on a calendar.

And if the system is billed per user, giving access to the whole client portfolio is a financial decision that usually doesn’t get made. It’s another example of how a pricing detail ends up determining which problems get solved and which don’t.

10. Systems that don’t talk to each other

Someone in the office typing into the ERP what a technician already wrote that morning. It’s work that adds nothing, introduces errors, and delays invoicing by several days.

What solves it. Having closed orders carry their hours and material straight into the billing workflow. In integrations you’ll find the scope of each connector, worth checking before assuming.

What they have in common

None of them show up in the first month. All of them depend on having recorded things beforehand. And none of them can be recovered retroactively: today’s orders can be logged tomorrow with some effort, but what happened last year, if it wasn’t written down, doesn’t exist.

That’s why the strongest argument for starting isn’t the savings: it’s that every month that passes is a month of data you’re never going to have.

If you want to see which of these eight affect you, you can request a demo on your own case.