Asset registers: what to capture and what to skip
Over-specified registers never get finished. Under-specified ones cannot answer questions. The useful middle is narrower than it looks.
The asset register is the foundation everything else attaches to, which is why so many implementations stall there. A team sets out to capture forty fields per asset, gets through the first site, and never returns.
Capture these, without exception
- A unique reference that is physically on the asset — a tag, a plate, a sticker someone can read.
- Asset class, because scheduling and reporting group by class, not by individual.
- Location, and a record when location changes.
- Criticality tier, which drives everything about how the asset is maintained.
- Commissioning date, for age-based analysis you will want in two years.
Capture these when they are cheap
Make, model, serial number, capacity, and any licence or certification with an expiry. Take them if they are on the nameplate while you are standing there. Do not launch a project to find them.
Skip these until something needs them
Full technical specifications, drawings, purchase price and depreciation, warranty small print. Each is genuinely useful in a specific scenario and none is needed to run maintenance. They can be added to an asset that already exists; they cannot justify delaying the register.
The reference is the part that matters
Everything else can be corrected later. A reference that does not exist on the physical asset breaks the link between the work and the record, permanently, and no amount of data quality effort recovers it. If you get one thing right, tag the asset.
Finish a site before starting the next
A complete register for one site is immediately useful. Four half-registers are not useful at all, and the half that is missing is always the half you need.
Related reading
Make good practice the default, not the effort
SaharaDesk turns these habits into workflow — thresholds that apply themselves, registers that stay honest, records that survive turnover.