CMMS Software Problems: The 7 That Send Technicians Back to Paper, and How to Avoid Them

Why does the asset model get scoped wrong so often?

Because a work order looks like a ticket. Most software teams have built a ticketing system, so the first data model that appears is a table of tickets with a status, an assignee and a free text description, plus a lookup table of assets. It demonstrates well and it is wrong in a way that only becomes visible in month four.

Maintenance data is only valuable when it rolls up. A bearing failure has to count against the gearbox, the conveyor and the line above it, because the question you will eventually ask is not how many work orders the bearing generated, it is what the line costs you to keep running. That requires a parent and child hierarchy of site, line, machine and component, failure codes drawn from your own equipment rather than a generic list, and a rule for what happens to history when a component is swapped out. Get that wrong and every analysis afterwards is built on sand.

The second half of the same failure is preventive maintenance scoped as a calendar. Grease the packaging conveyor every thirty days sounds like a schedule and is actually a guess. In a heavy month it runs several times the hours it does in a slow month, so the same interval is dangerously long and wastefully short in different quarters, and you fund one mistake with the other.

The fix: make any prospective developer draw the asset hierarchy, the failure code taxonomy, the meter types and the component swap rule in the first meeting. A team that has built maintenance software sketches it from memory. Then define preventive maintenance triggers as usage based from the start, even if the meter readings begin as manual entries, so the model is right before the data source improves.

What goes wrong when you migrate the Excel registers and the paper history?

Spreadsheet asset registers migrate technically and fail semantically. Every plant named its equipment its own way, so the same pump type is three descriptions across three sites, asset numbers collide between plants, and the parts list carries the same bearing under four part numbers because four buyers ordered it from four suppliers. Import it as it stands and you get a network wide catalogue that cannot be searched, which means the technician in Dayton still cannot see the spare sitting in Louisville, which was the point of the project.

Paper history is the other trap. Everyone wants five years of work orders digitised and nobody costs it, because it is manual entry from three handwriting styles with missing dates and no failure codes.

The fix: normalise before you import, not after. Agree one naming convention and one part numbering scheme across sites, run duplicate detection on descriptions and manufacturer part numbers, and accept that this is a few weeks of somebody's time that belongs in the plan. For history, sample rather than transcribe: pick the critical assets where a rebuild or replace decision is coming, enter or scan and attach their history, and start everything else clean from go live. Any developer who does not put this plan in writing before contract has not done a migration in this category.

Why do the controls and purchasing integrations break after launch?

Controls integrations break on the shop floor rather than in the code. The programmable logic controller on the 1998 line has no ethernet port, so it needs gateway hardware with its own testing cycle. The historian tag naming was done by a contractor who left, so the tag that reads runtime hours on line three reads something else on line four. A controls engineer changes a tag during a shutdown and nobody tells the maintenance team, so a preventive maintenance trigger silently stops firing and the work orders stop appearing.

That last pattern is the dangerous one, because a preventive maintenance system failing loudly is an inconvenience and a preventive maintenance system failing quietly is a bearing.

Purchasing integrations break on process rather than on interface. Requisitions flow into the enterprise resource planning (ERP) system correctly, then a buyer edits the quantity or splits the order, and the receipt comes back against a line the maintenance system does not recognise. Crib counts and system counts drift apart within a month, and the crib card becomes the real record again.

The fix: monitor the data feed, not just the connection. If a meter that increments daily stops incrementing, raise an exception with an owner rather than assuming the machine is idle. Version tag mappings and treat a controls change as a change that requires maintenance review, because it is. On the purchasing side, reconcile received quantities back against the originating requisition and surface mismatches to the crib rather than to a log, and make barcode scanning of consumption faster than not scanning it, since that is the only way logging ever happens consistently.

What happens when the compliance evidence gap is not covered?

An inspection or a customer audit asks for three specific things: lockout tagout evidence for the last twenty jobs on that mixer, current calibration certificates for the gauges on line two, and proof that the contractor who serviced the ammonia system was qualified and insured on the day they did it. On paper that is a two day binder hunt with gaps you discover standing next to the auditor.

Generic maintenance software rarely closes this, because what it records is that a work order was edited by a user at a time. That is an audit trail, not compliance evidence. Electronic signatures, calibration management with certificate expiry and contractor credential tracking are premium modules where they exist at all, and when they are absent the evidence goes back into binders and inboxes even though you now own a system.

The fix: make the workflow enforce the requirement rather than record it afterwards. Lockout tagout steps become required checklist items that block work order closeout until signed. Calibration schedules carry the certificate as an attachment with expiry alerts and an automatic block on using an out of calibration instrument. Contractors work through their own portal, and an expired insurance certificate blocks assignment without anyone having to notice. Then design the export in the format your quality manager specifies during the build, because a competent developer asks what the auditor actually wants before writing code rather than after the visit.

Should you build custom or configure what you already own?

If you run one or two sites with fewer than about twenty technicians, standard assets and no controls integration, configure a subscription tool and stop reading. MaintainX or Limble will get you off paper in a week, and that outcome beats any architectural argument. Nobody should build software they do not need.

If you already own a tool and it is not working, be honest about which of two problems you have. If planners keep shadow spreadsheets because the tool cannot express your workflow, that is a product limit and configuration will not fix it. If nobody has cleaned the asset register or defined failure codes, that is an implementation problem and a new build will reproduce it faithfully at ten times the price.

Build when the constraints are structural: condition based triggers from your programmable logic controllers and historian that have sat on a vendor roadmap for years, multi site parts visibility that requires an enterprise tier plus consultants, compliance evidence in a format your auditor asks for and the tool cannot produce, or per seat costs at a headcount where the arithmetic has turned. At three hundred users, published list pricing on the mid market tools runs to a six figure annual bill for software you will never own, and against that a build you own outright pays back over a few years.

How do hidden costs get into the quote?

Offline mobile priced as a mobile app. Offline first with a real conflict resolution design, tested on both major platforms in actual dead zones, is a substantial piece of engineering, and it is the single feature that decides whether technicians use the system at all.

Controls integrations priced per system rather than per controller family. Old equipment needs gateway hardware, and every controller family has its own quirks and its own testing cycle on a line you can only touch during a shutdown.

Site rollout treated as deployment. Each site brings its own naming, its own crib, its own local practice and a fortnight of hand holding, and go lives staggered across ten plants is ten mobilisations, not one.

Data cleanup, as above. Weeks of somebody's time that never appears in a proposal.

Validation in regulated industries, which is a workstream with its own calendar.

From Digital Heroes delivery experience across more than two thousand projects, a focused first release covering work orders, an asset registry on your hierarchy, preventive maintenance scheduling, offline first mobile, migration of your spreadsheets and one priority integration runs $60,000 to $130,000 in 12 to 16 weeks. A full multi site platform adding networked inventory, control system feeds, contractor portals, compliance modules and cost analytics runs $150,000 to $400,000 phased over 6 to 12 months.

What separates a build that works from one that fails here?

Closeout under a minute. Photo capture, voice to text notes, parts scanned from the crib, and required fields limited to the ones you will actually analyse. Every additional required field is a small tax on data honesty, paid by the person least able to refuse it.

Offline behaviour designed rather than assumed. Ask exactly what happens when two technicians edit the same work order in a dead zone and both sync later. If the answer is not a specific conflict resolution design, technicians will lose data once and go back to paper permanently.

Pilot at one or two sites before the network. Live daily use at a pilot plant surfaces the workflow problems that no requirements workshop finds, and fixing them before rollout is the difference between adoption and a system people work around.

Cost analytics tied to the same hierarchy as the work orders, so downtime, labour, parts and contractor spend roll up to a true cost per asset and a repair versus replace threshold computes itself rather than being argued. Your floor is already producing this data. The build is what puts it in front of a decision.

Ownership in writing before signature: source code, database schema and documentation transferred to you at final payment. At Digital Heroes that is standard on every project, and a developer who hesitates on it is selling a subscription with extra steps.