The person at the machine is the user, not the data source

A technician is standing in front of a stopped line with a tool in one hand. Anything that requires two hands, a stable network or a decision about which of eleven fields is the right one is a task that gets skipped — and skipped data is worse than no data, because a system full of half-true records is trusted.

The design rule we hold to is blunt: the field workflow decides the shape of the product, and the reports are derived from it. Not the other way round.

How systems drift into data entry

It usually starts with a reasonable request. A manager wants to know the failure cause for every breakdown, so a mandatory cause field is added. Then a category. Then a sub-category, a cost centre, a shift code. Each field makes sense in a meeting room. Together they turn a two-tap action into a form, and the technician learns to pick the first option in every list to get past it. The report now has a cause for every breakdown, and most of them are wrong.

Make the honest action the cheap one

Reporting a machine as running and writing the maintenance report are two different facts, and sharing one field between them forces a lie at three in the morning. When a line comes back up, the truthful action is “the machine is running” — the report is written when there is actually time to write it.

Keeping those separate is not a nicety. It is what makes the downtime figure real, the history readable and the technician willing to use the system at all. We explain the mechanics in breakdown reporting that does not slow the repair.

Five actions, not fifty

A technician needs a small set of actions to do the job: see their shift, take a job, wait or resume with a reason, report the machine running, and close out the report. A system that makes those five fast and obvious will be used. Everything else — planning screens, stock management, reporting — belongs to the people whose job it is, on their own screens. That is also how we train during a rollout: five actions first, everything else later.

Capture has to survive the building

Industrial sites have dead spots: the far end of a warehouse, a basement plant room, a steel-framed hall. If filing a defect requires a connection, the report is written later from memory or not at all. So in UR Maintain the report is stored on the device first and pushed when the plant is reachable — and when the plant refuses it, the device says so plainly instead of retrying forever. What offline should actually mean goes into the details.

Ask for data at the moment it exists

The cause of a failure is rarely known when the job is taken. It is known after the repair. A system that asks for the cause at the start gets a guess; a system that asks at closeout gets an answer. The same goes for parts used, follow-up work and temporary repairs. Timing the question correctly is worth more than making the field mandatory.

What a technician-first system looks like in practice

  • One tap to take a job, visible to everyone the moment it happens.
  • Big targets and short words on a phone screen, usable with gloves.
  • Waits with a reason, because “waiting for part” is information, not an excuse.
  • “Machine running” as its own action, separate from the report.
  • Work that survives a dead spot and says plainly when the plant has refused it.
  • The drawing and the part at the machine, reached from a QR label rather than a menu.

How to test it before you buy

Run one realistic breakdown through any system you evaluate, on a phone, standing up. Count the taps from “machine stopped” to “I own this job”. Count the fields that are mandatory before the machine can be reported running. Switch the phone to flight mode halfway and see what happens. Then ask a technician whether they would use it at three in the morning. Their answer is the most reliable predictor of data quality you will get.

What this costs the management view

Nothing, ultimately. Data that arrives because the workflow was good is data you can build decisions on — reliability figures like MTBF and MTTR included. Data that arrives because somebody was forced to type it into a form is a compliance artefact, and everyone involved knows it.

When you evaluate a CMMS, give the phone to a technician, not a manager, and watch which one finishes the breakdown flow first.