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 your people have 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.
That 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 every report, every workflow, every capital case, and every conversation with leadership for the next ten years. Nobody in that room knows it yet. I’ve seen this more times than I can count.
Why hierarchy compounds
Everything downstream 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.
So the call you make in year one limits how you can report in year five, what questions leadership can ask in year eight, and what investments you can defend in year ten. Almost nothing else in the program reaches that far.
Hierarchy is 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 bad hierarchy I’ve walked into falls into one of two patterns. They look like opposites. Over the long haul they hurt you the same way.
Failure mode 1: too granular
The over-built hierarchy tries to capture everything. Every component, every sub-component, every bolt and washer is a node in the registry. The intent is good (you want to track maintenance at the right level), but nobody can keep it up. 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 your people know that, they stop believing the reports.
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. Sure, it’s easier to maintain. It’s also useless for the decisions you have to make. When the chiller fails, your work history shows “HVAC” failures, which doesn’t help you identify root cause, prioritize replacement, or defend capital. You pay for that simplicity every time someone asks a question the hierarchy can’t answer.
The “three levels back” test
Here’s the test I use for granularity. Can you answer your three most common asset-management questions by going three levels back from the work order? If yes, you’re close. If you have to dig deeper, or you can’t find the level where the question lives, the design needs work.
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 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, and it only gets worse 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 prioritization. Mixing them together is a mistake I see all the time.
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 tearing up the hierarchy. You will need to, because criticality changes as regulations, mission, and risk tolerance shift.
What to do when you inherit a bad hierarchy
Most of you are here, and it’s the most painful spot to be in. 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. You’ll be tempted to start over. Starting over is usually a multi-year project nobody has the appetite to fund.
Three moves that work:
- 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 lets you ask the questions you 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. I’ve watched plenty of projects stall out trying 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 flows (how planners group jobs, how supervisors organize their week, how 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 won’t last. The first reorg breaks it. The first new VP wants to restructure it. The first software change makes the old template obsolete.
Design for the work. The work changes slowly and the org chart changes constantly. A hierarchy built on how the work flows will pay off for a decade. One built on the org chart will be broken before the rollout is finished! Who designed yours, and what was it built around? Can it answer the questions your leadership will be asking five years from now?
