An asset hierarchy is a parent-child structure that organises assets by site, system, and component, showing how each item relates to the others.
An asset hierarchy is a parent-child structure that organises assets by site, system, and component, so each asset record shows not just what an item is but what it belongs to and what belongs to it. A pump is part of a boiler, the boiler is part of a plant room, the plant room is part of a building. The hierarchy turns a flat list of equipment into a map of how the organisation’s kit actually fits together.
Why hierarchies exist
A flat register answers “what do we own?”. A hierarchy answers the follow-up questions:
- Impact - if this air-handling unit fails, which rooms and which equipment downstream are affected?
- Cost roll-up - what does the kitchen, as a whole, cost us in repairs each year, across every appliance in it?
- Findability - a technician sent to “Site B, plant room, boiler 2” navigates the tree instead of searching hundreds of records.
- Accountability - responsibility can be assigned at the right level, a site manager for the site, a department for its systems; see asset accountability.
The idea comes from maintenance management in heavy industry, but a shallow version of it helps any organisation with more than one location.
The typical levels
A widely used pattern has four levels, and most organisations use a subset:
- Site - the physical place: a building, campus, or branch.
- Area or system - a functional grouping inside the site: the kitchen, the CCTV system, the workshop.
- Asset - the trackable item with its own record, number, and label.
- Component - replaceable parts beneath an asset, worth listing only when you repair rather than replace.
A worked example
A small hotel might structure its register like this:
- Site: Hotel - the building itself
- System: Kitchen - holding the appliances: dishwasher, ovens, fridges, each its own asset
- Component: dishwasher heating element - listed because it is swapped, not the whole machine
- System: Security - the recorder plus each of the security cameras as individual assets
- System: Kitchen - holding the appliances: dishwasher, ovens, fridges, each its own asset
Now “what did the kitchen cost us last year?” is a roll-up, and “camera 6 is down” comes with its position in the system attached.
How deep to go
The classic mistake is over-nesting: a five-level tree that nobody maintains is worse than a two-level one that stays true. Go only as deep as the decisions you make - if you never repair below the asset level, skip components entirely. Movable assets complicate trees too: a drill that lives in three vans a week should hang off a home location, with its actual whereabouts handled by location tracking rather than by re-parenting it daily. In practice, many small organisations get the benefit of a hierarchy from two levels: in AMPthilly, for instance, category and sub-category fields plus a location per asset cover the site-and-system layers most teams actually use, without maintaining a formal tree.
Related terms
- Asset Record - the per-item entry each node of the tree points to
- Asset Location Tracking - the “where is it now” that complements the structure
- Movable Assets - items that belong to one node but roam across others
- Asset Accountability - assigning responsibility at the right level of the tree
- Tangible vs Intangible Assets - hierarchies mostly structure the tangible side