Most asset-management decisions are reversible. You can swap vendors. You can re-tune a criticality threshold. You can adjust a PM cadence next quarter and nobody will lose sleep. But the asset hierarchy, how you structure, group, and label the assets in your registry, isn’t one of those decisions. Once it’s in place and the organization has built a year of work orders, reports, and capital decisions on top of it, restructuring it is brutal. So most organizations don’t. They live with whatever they started with, sometimes for a decade or more.
Which makes the asset hierarchy the most expensive twenty-hour decision in asset management. The team that sketches it on a whiteboard in week three of an implementation is locking in a structure that will shape every report, every workflow, every capital case, and every conversation with leadership for the next ten years. Most of the time, nobody in that room knows that yet.
Why hierarchy compounds
Every downstream artifact in asset management inherits the hierarchy. Work orders attach to assets in the registry. PMs roll up by parent location. Cost reports aggregate at the level your hierarchy supports. Criticality models classify against the hierarchy. Capital plans group at hierarchy levels. Even your KPIs, PM completion rate, mean time between failures, deferred maintenance backlog, are reported at whatever rollup levels your hierarchy provides.
That means a hierarchy decision in year one constrains how you can report in year five, what questions leadership can ask in year eight, and what investments you can defend in year ten. Few other decisions in the program have that kind of reach.
Hierarchy isn’t just an organizing structure. It’s the question template for every report you’ll ever generate. If the hierarchy can’t answer the question, the report can’t either.
The two failure modes
Almost every poorly designed hierarchy falls into one of two patterns. They look opposite, but they cause similar long-term pain.
Failure mode 1: too granular
The over-built hierarchy tries to be comprehensive. Every component, every sub-component, every bolt and washer is a node in the registry. The intent is good, you want to be able to track maintenance at the right level, but the practical result is that nobody can maintain it. New equipment gets installed and never gets registered correctly. Old equipment gets retired but the records linger. Within a few years, the hierarchy doesn’t match the field. Once that’s established, every report carries doubt.
Failure mode 2: not granular enough
The under-built hierarchy lumps too much together. The whole HVAC system is one asset. The whole substation is one node. This is simpler to maintain, but it’s useless for the decisions you actually need to make. When the chiller fails, your work history shows “HVAC” failures, not useful for identifying root cause, prioritizing replacement, or defending capital. The simplicity tax compounds every time someone tries to ask a question the hierarchy can’t answer.
The “three levels back” test
A useful litmus test for hierarchy granularity: can you answer your three most common asset-management questions by going three levels back from the work order? If yes, the granularity is roughly right. If you need to dig deeper, or if you can’t find the level where the question lives, the design needs adjustment.
The three questions are usually:
- What did this asset cost us last year? Cost rollup, you need a node that captures the relevant grouping (an air handler, a pump, a chiller), not just the whole system.
- What’s the failure history of this asset class? Reliability rollup, you need to be able to look across similar equipment, which means the hierarchy has to support a sensible class grouping.
- When does this asset need to be replaced? Lifecycle rollup, you need the level at which renewal decisions actually get made, which is rarely the whole-system level and rarely the bolt-and-washer level.
If your hierarchy can answer those three questions cleanly, it’s probably right. If it can’t, you have a structural problem that won’t get better with time.
The criticality dimension
Hierarchy and criticality are related but separate. The hierarchy organizes assets by what they are and where they live. Criticality scores them by consequence of failure. Both feed into prioritization, but conflating them is a common mistake.
The right pattern is to let the hierarchy carry structural information (system, sub-system, asset, sometimes component) and let criticality be its own attribute (high/medium/low, or numeric scoring) applied to the asset records. That way, you can re-tune criticality without re-architecting the hierarchy, which matters because criticality changes as regulations, mission, and risk tolerance shift.
What to do when you inherit a bad hierarchy
This is the most common scenario, and the most painful. The hierarchy you have was designed years ago by people who are no longer there, the rationale is undocumented, and changing it would invalidate years of work history. The temptation is to start over. The reality is that starting over is usually a multi-year project nobody has appetite to fund.
Three pragmatic moves that work in this situation:
- Map the hierarchy you have to the hierarchy you wish you had. Build a mapping table. You can keep the old structure as the system of record while reporting at the new structure’s levels. It’s ugly but it works, and it buys you the ability to ask the questions you actually need to ask.
- Restructure one piece at a time. If a particular system or area is the most painful, restructure just that one. Don’t try to do the whole portfolio. The asset-management world is full of stalled projects that tried to fix everything at once.
- Make the rule going forward. Any new asset gets added at the right level, with the right structure, even if the legacy assets stay where they are. Over time, the new structure becomes the majority and you can phase out the old.
The one principle that survives every reorg
If a hierarchy is designed around the way the work actually flows, the way planners group jobs, the way supervisors organize their week, the way capital decisions get made, it survives reorganizations, leadership changes, and software migrations.
If a hierarchy is designed around an organizational chart, a budget code structure, or a vendor’s default template, it doesn’t. The first reorg breaks it. The first new VP wants to restructure. The first software change makes the old template obsolete.
Design for the work, not for the org chart. The work changes slowly. The org chart changes constantly. The hierarchy you build on the slower-changing foundation will compound in your favor for a decade. The one you build on the faster-changing foundation will be broken before the rollout is finished.
