What to put on an asset register

Everything in a maintenance system hangs off the asset register. Work orders point at it, history accumulates against it, documents are filed on it. Get it wrong and every other record inherits the problem — which is why it is worth an hour of thought before anyone starts typing.

The good news is that the list of fields that genuinely earn their place is short. The bad news is that two of them are the ones people rush.

The identifier problem

Every asset needs a name that is unique, stable, and says something to a person standing in front of it. These pull in different directions, which is why so many registers end up with "Chiller 2".

"Chiller 2" fails on all three. It is not unique across sites, it stops being true the day Chiller 1 is replaced, and it means nothing to an engineer who has never been there. A serial number is unique and stable but unreadable and often unreachable without a ladder and a torch.

What works is a code you assign, carried on a label on the machine. Something short, sequential and meaningless — AST-0142 — with the manufacturer, model and serial recorded as separate fields underneath. The code identifies, the serial proves, the model explains. Asking one field to do all three is what breaks registers.

The fields that earn their place

• Asset code — yours, labelled on the machine, never reused.
• Manufacturer and model — what it is, so a manual can be found and a part cross-referenced.
• Serial number — what proves it is this one, for warranty and for the manufacturer's own recall and bulletin lists.
• Category — chiller, AHU, boiler, pump. This is what makes the register answerable as a question rather than readable as a list.
• Location — the site, precisely enough that a stranger arrives at the right building.
• Access — how to physically reach it. See below; this is the one that is always skipped.
• Customer or department — who owns it and who is billed for it.
• Quantity, if you are registering a bank — six identical rooftop units on one plant deck are more usefully one record with a count than six near-identical records nobody keeps straight.

The access note is the field that pays for itself

An address gets an engineer to the car park. What costs a visit is everything after: which roof, which plant room, whose key, whether there is a permit to work, whether the hatch needs two people, whether the ladder is on site or in the van, and who to ring when the gate is locked.

This is institutional knowledge in the worst sense — it lives with whoever went last. It is also three sentences of typing. A register with a good access note on every asset saves more engineer-hours than any other field on this page, and it is the one most likely to be left blank because it does not look like data.

What not to put on it

• A free-text site nickname on every row. If the location is recorded properly, a hand-typed label repeated on forty assets is forty chances to disagree with itself.
• Anything derivable. Age from install date, next service from last service — compute it, do not store it, or the two will drift.
• The full spec sheet. Refrigerant charge, electrical characteristics and dimensions belong in the manual attached to the asset, not as forty fields that are blank on nine assets in ten.
• Anything nobody has ever asked for. Every optional field is a column of nulls that makes the useful ones harder to see.

How to start without a year of data entry

The commonest way an implementation dies is a decision to import everything first. Eight thousand assets arrive from a spreadsheet, nobody has used the system, the data is a year stale before the first engineer opens it, and it becomes something people work around.

A better order: register the twenty machines you are called to most, properly and completely. Add every other asset the first time someone is sent to it — the engineer is standing in front of it with a phone, which is the cheapest moment the data will ever be captured. Within a season the register covers the work you actually do, which is the only part that matters.

The measure to watch is not how many assets are on the register. It is what share of your call-outs land on one that is already there.

How Repair Control models it

A machine carries an asset code, name, manufacturer, model number, category, a unit count for banks of identical kit, an access note, and its customer. Location is a Google place identifier with a cached address and coordinates, so assets at one site share a location precisely rather than through a nickname typed forty times — and a pin an admin drops by hand is never re-geocoded over. Parts and documents hang off the machine, as does every dated visit.

There is no serial number field. The asset code is the identifier, and a serial today has to live in the machine name or on a document attached to it. Given what is written above, that is a gap rather than a design decision, and it is better said here than discovered on the third asset.

Each asset also carries a coverage figure — how well documented it is — so the machines nobody has written up stop being a surprise. Next: what a CMMS is, or how to write a work order against one of these once it exists.