IT‑IS‑Networking
Projects › Local government — asset management

Automated Asset Tracking Program

Nine years carrying the asset tracking agenda across two titles, argued on billing accuracy rather than loss prevention — and ending in a position and a scoped proof of concept rather than a deployment.

The City’s property record was built by hand. Staff traveled to each location once a year, confirmed the equipment was still in use, and scanned a property inventory decal. Departmental chargebacks were calculated from the asset management system, and that system was refreshed only by the annual audit.

An inventory that is correct one day a year produces billing that is wrong the other 364. That was the case that moved the work forward, and it is a better case than the one usually made. Asset tracking is normally sold on loss prevention, which is hard to size and easy to dismiss. Billing accuracy is neither.

It ran from an objective written into a manager’s performance plan in 2007, through a line on the technology research slate as Technology Officer in 2008 and a scoped single-building pilot proposal, to a status request in 2014. Nine years, two titles, and the business case never changed.

The tracking layer should ride the infrastructure the organization already owns

Passive tags are cheap and need no battery, but they are read only where a reader has been installed — so coverage across roughly 200 locations, including more than twenty libraries and more than sixty fire stations, becomes a capital program in readers. Active tags carry a battery and announce themselves to wireless access points already in place, which turns coverage into a question about existing wireless rather than a new build.

Three scenarios pulled in different directions, and that was the design problem:

  • The courthouse already had dense wireless coverage, which made wireless-based location the candidate for evidence tracking.
  • Fire and rescue cannot have a fixed reader at a scene, so the proposal was to put a wireless router on the apparatus and let it read the tags — which only works with tags that transmit.
  • Locating equipment across 200 sites continuously, rather than confirming it once a year, is a coverage problem before it is a tagging problem.

This is recorded as the position the evidence supports rather than as a documented decision, because no single message in the record states the passive-versus-active choice in those words.

A proof of concept written to test the assumption, not the product

Fifty to two hundred devices, information technology equipment only, run on demonstration hardware from the wireless manufacturer and the tag vendor — to determine whether the current infrastructure was sufficient. The enterprise rollout was deliberately held as a separate decision, to be informed by the result.

That is the distinction worth keeping: the question was not whether the product worked, which the vendor would answer, but whether the estate already standing could carry it, which only the organization could.

It was framed throughout as an add-on feeding the enterprise asset management platform — which is also the system that drove the chargebacks. So the tracking layer, the system of record and the billing model were one chain rather than three projects.

The record ends with a status request in November 2014, and the annual decal-based inventory continued in parallel throughout. No deployment. What survives is the position and the scope, which is what nine years of carrying an agenda through two titles actually produces when the funding never arrives.

Outcome

An architecture position on tags and coverage, and a proof of concept written to test the infrastructure assumption rather than the product.