Asset tracking, and what people usually mean by it

Asset tracking means three different things, and buying software for the wrong one is a common and expensive mistake. Work out which of these is your actual problem before you look at a single product.

Problem 1: we cannot find things

Portable equipment that moves and goes missing: medical devices, tools, laptops, test equipment, trolleys. This is a location problem, and it is the one where tags, scanning at checkpoints and sometimes RFID pay off.

The measure that tells you this is your problem: how long it takes to locate a specific item, and how often a scheduled check is missed because the item could not be found.

Problem 2: we cannot maintain things properly

Fixed plant that stays where it is, but whose history, schedule and documents are scattered. This is a maintenance record problem, and it is solved by a code on the machine and jobs filed against equipment rather than against buildings.

Problem 3: we cannot account for things

Finance needs a register with values, depreciation and a yearly verification. This is a fixed asset accounting problem, and it usually belongs in the finance system rather than in a maintenance product.

Why the distinction matters

Products are built for one of the three and adapted to the others. Buying a location tracking system to fix a maintenance record problem gives you a map of where things are and no service history. Buying a maintenance system to satisfy finance gives you a register finance will not accept.

The overlap that is real

Problems 1 and 2 genuinely combine in hospitals, universities and anywhere with a large population of portable equipment on a schedule. There, knowing where a device is and what it needs are the same question, and a product that separates them will not work.

Start by writing the question down

One sentence: "we cannot answer X about our equipment". Then check that each shortlisted product answers that sentence in a demo, with your own equipment. Most disappointing purchases in this category were solving a well-implemented version of somebody else’s problem.