Asset Hierarchy Design for CAFM and EAM

The asset hierarchy is the skeleton of any CAFM, CMMS, or EAM system. It determines what you can report on, how costs roll up, how work orders flow, and whether your data still makes sense five years from now. Most implementations get it wrong on the first try. This guide is how to get it right.

Why the hierarchy matters so much

Every transaction in a CAFM/EAM system attaches to the hierarchy somewhere. Work orders point to assets. Assets live in locations. Costs roll up through the tree. Reports filter by branches of the tree. If the tree is wrong, everything downstream is wrong.

A well-designed hierarchy answers questions like: "What's the total maintenance cost for Building 3 last year?" or "Which chillers are costing us the most per run-hour?" A bad hierarchy leaves you exporting data to Excel to answer the same questions.

The standard hierarchy structure

The proven structure for campus-style and multi-site operations is six levels deep:

Not every installation needs all six. Industrial sites may skip "Floor" and go straight to Zone. Retail chains may flatten Building-Floor-Room into a single Store level. But most multi-building operations need the full six-level structure.

The Position vs Asset distinction (this is the big one)

The single most important design decision is separating Position from Asset. Get this wrong and you cannot track equipment replacements properly, which makes warranty tracking, replacement history, and location-based cost reports impossible.

Why this split matters:

• Replacement history: You can see that Chiller Bay 3 has had 4 chillers over 20 years.
• Location cost tracking: Total maintenance spend on "Chiller Bay 3" persists across equipment changes.
• Warranty isolation: Warranty belongs to the asset (the specific serial number), not the position.
• Vacant positions: You can have a position with no current asset (equipment removed, awaiting replacement).
• Planned decommissioning: When an asset is retired, its maintenance history stays with the asset, while the position continues accumulating new history.

What each record should contain

The replacement scenario (the payoff of this design)

When a chiller gets replaced, here is what happens in a well-designed system:

1. Position "Chiller Bay 3" stays exactly as it was.
2. Old asset "Chiller-01" is marked Decommissioned. Its maintenance history remains linked to it.
3. New asset "Chiller-07" is registered, linked to Position "Chiller Bay 3".
4. New warranty and serial info attached to Chiller-07. Future work orders go to Chiller-07. Position-level cost report now shows all historical and current costs.

In a badly designed system (assets without positions), you either lose history or end up with a messy "Chiller-01 (old)" / "Chiller-01 (new)" naming hack that breaks every report.

Asset classification (on top of the hierarchy)

Separate from the location hierarchy, assets need a classification hierarchy, a taxonomy that groups assets by type. The standard three-level structure:

This taxonomy drives:

• Maintenance strategies (all chillers use the same PM template)
• Standard checklists (by asset type)
• Failure codes (appropriate problems/causes by category)
• Reporting groupings (cost by asset class)

Typical top-level classes:

• HVAC: Chillers, AHUs, FCUs, Ductwork
• Electrical: MDB, DB, UPS, Generators, Transformers
• Mechanical: Pumps, Motors, Compressors
• Fire: Fire Pumps, Sprinklers, Alarm Panels
• Plumbing: Tanks, Piping, Fixtures
• Vertical Transport: Lifts, Escalators

Asset criticality (the fourth dimension)

Every asset needs a criticality rating independent of its classification. A pump in a critical chilled-water loop is more critical than the same pump model in a decorative fountain. Standard levels:

Criticality drives PM frequency, SLA priority, resource allocation, and spare-parts inventory policy.

Naming and coding conventions

• Use structured codes, not free-text names. BLD03-FL02-AHU-01 is more powerful than "AHU on 2nd floor, Building 3".
• Embed hierarchy in the code when helpful. Makes filtering and parsing straightforward.
• Keep codes short but meaningful. Field technicians scan these on phones.
• QR codes on every asset. Pair the code with a physical QR tag for mobile scanning.
• Document the scheme. New users need to understand it on day one.

Common hierarchy design pitfalls

Conclusion

Your asset hierarchy is a long-term decision. It will outlive the vendor, outlive the implementation partner, outlive the users who designed it. Get the big structural decisions right, six-level location tree, Position vs Asset separation, clean classification taxonomy, consistent coding, and you'll have a foundation that supports whatever the next 10 years demand.

Get it wrong and you'll find yourself three years in, explaining to the CFO why maintenance cost reports don't match finance, why warranty claims keep getting missed, and why the next system migration is twice as expensive as it should be.