Book a demo
Login
An asset hierarchy is a structured classification of physical assets that shows how sites, systems, equipment, and components relate to one another through parent-child relationships. It provides the organisational backbone for maintenance management, reliability analysis, cost tracking, asset performance reporting, and structured asset information management.
In asset-intensive industries such as oil and gas, chemicals, utilities, pharmaceuticals, mining, and renewables, an asset hierarchy must do more than organise equipment inside a CMMS. It must connect the physical facility represented in engineering data with the structure used to operate and maintain that facility.
That connection is critical during project handover. Engineering teams may identify equipment through tags and engineering systems, while operations teams may manage the same equipment through functional locations and asset records in SAP, IBM Maximo, IFS, or another Enterprise Asset Management (EAM) or CMMS platform.
A well-designed asset hierarchy provides a consistent structure between these different views of the same physical facility.
An asset hierarchy follows a tree structure, moving from broad organisational or physical levels at the top to individual maintainable equipment and components below.
A practical example for an onshore gas processing facility could be:
Each level has a parent-child relationship with the levels around it. The compressor belongs to the compression train, the train belongs to the gas compression system, and the mechanical seal belongs to the compressor.
The exact hierarchy varies between organisations and industries. What matters is that the levels are clearly defined, consistently applied, and detailed enough to support the organisation's maintenance, reliability, reporting, and information-management requirements.
A typical industrial asset hierarchy may include:
Not every organisation needs every level. A hierarchy should be deep enough to support useful maintenance and analysis without becoming unnecessarily difficult to govern.
Consider a maintenance engineer investigating repeated seal failures on a compressor.
Without a structured hierarchy, the engineer may see only an isolated equipment record.
With an asset hierarchy, the engineer can navigate:
Gas Processing Plant → Gas Compression System → HP Compression Train → Compressor K-1001A → Mechanical Seal
This context makes it possible to analyse maintenance history at the component level while also rolling information upward to the equipment, system, and facility levels.
The same principle applies to costs, failures, downtime, inspections, spare parts, and performance data.
A good asset hierarchy turns individual equipment records into a connected model of the physical facility.
This enables several important operational capabilities.
Maintenance activities can be assigned to the correct equipment or component while still retaining the context of the larger system it belongs to.
This makes maintenance history easier to retrieve and reduces ambiguity when multiple assets have similar descriptions.
Failures recorded against consistently classified assets can be compared across similar equipment and rolled up to subsystem, system, or facility level.
Reliability engineers can therefore identify whether a recurring problem is isolated to one component or indicative of a broader equipment or system-level issue.
Labour, materials, downtime, and maintenance costs recorded against individual assets can be aggregated through the hierarchy.
This allows organisations to answer questions such as which equipment, systems, or facilities are responsible for the highest maintenance expenditure.
The hierarchy also provides context for engineering documentation, equipment specifications, inspection records, certificates, and vendor information.
When those records are linked to the correct tagged equipment, users can navigate from the physical asset to the information required to maintain it.
These concepts are closely related, but they are not interchangeable.
An asset hierarchy describes the parent-child relationships between the different levels of a facility and its physical assets.
A functional location represents a location or functional position where equipment performs a function. This concept is particularly common in systems such as SAP.
A Master Tag Register (MTR) provides the authoritative list of tagged items and their identifiers used throughout engineering and asset information.
For example, an engineering team may identify a compressor as K-1001A in the Master Tag Register and on the P&ID. Operations must then ensure that the corresponding equipment record is associated with the correct functional position in the operational hierarchy.
This mapping is one of the most important connections between engineering information and maintenance data.
If the tag structure and operational hierarchy are not reconciled before handover, duplicate assets, missing records, incorrect parent-child relationships, and disconnected documentation can appear in the EAM or CMMS.
ISO 14224 is an important reference for equipment taxonomy and reliability and maintenance data in the petroleum, petrochemical, and natural gas industries.
Its taxonomy provides a structured way of moving from higher-level industry and installation context toward equipment units, maintainable items, and parts. This supports consistent equipment classification and makes reliability and maintenance data easier to compare and analyse.
For capital projects, ISO 14224 may be used alongside owner-specific asset structures, tag numbering conventions, functional location requirements, and information standards such as CFIHOS.
The objective is not simply to reproduce a standard hierarchy inside every system. It is to create a governed asset structure in which engineering, maintenance, reliability, and operations can consistently identify the same physical assets.
The asset hierarchy becomes particularly important when asset information is loaded into a CMMS or EAM system such as SAP, IBM Maximo, or IFS.
The hierarchy determines how users navigate assets and how maintenance information can be aggregated and analysed.
A correctly structured hierarchy supports:
This is why asset hierarchy design should not be treated simply as a CMMS configuration task. The underlying asset structure and identifiers originate much earlier in the asset lifecycle.
Start by determining what the hierarchy must support: maintenance, reliability analysis, reporting, cost allocation, regulatory requirements, or a combination of these.
Define each hierarchy level clearly before loading asset records.
Use approved P&IDs, equipment lists, the Master Tag Register, vendor data, and other controlled engineering sources to establish what equipment actually exists.
This is particularly important on capital projects, where the hierarchy may be created before the operating CMMS is fully populated.
Define rules for equipment names, tag numbers, equipment classes, hierarchy levels, and parent-child relationships.
The same physical asset should not appear multiple times under slightly different names.
Connect engineering tag identifiers to the corresponding operational asset and functional location structure.
This provides traceability from engineering documentation to the equipment that maintenance teams will eventually manage.
Check for:
Resolving these problems before migration is significantly easier than correcting thousands of asset records after go-live.
An asset hierarchy is not static.
Equipment is replaced, systems are modified, new assets are commissioned, and existing assets are retired or relocated. Clear change control should define who can create, modify, move, or retire asset records.
Several problems repeatedly undermine otherwise well-designed hierarchies.
Too many hierarchy levels. More detail is not automatically better. Excessive depth creates records that users cannot maintain consistently.
Too few levels. A flat equipment list makes system-level analysis and cost aggregation difficult.
Inconsistent naming and classification. Different names or classifications for equivalent equipment make cross-site reporting and reliability analysis unreliable.
Mixing functional and physical structures without clear rules. Location, function, equipment class, and physical containment are different relationships. Combining them inconsistently creates ambiguous hierarchies.
Duplicate and orphaned assets. An equipment item should have one authoritative identity and the correct parent relationship.
Building the hierarchy only during CMMS implementation. Waiting until operations to resolve engineering identifiers and asset relationships can turn the CMMS migration into a major data-cleansing exercise.
No governance after go-live. Even a perfect hierarchy will deteriorate if additions, replacements, relocations, and retirements are not controlled.
The asset hierarchy and Master Tag Register (MTR) should work together, but they answer different questions.
The MTR answers:
What tagged items exist, and what are their authoritative identifiers?
The asset hierarchy answers:
Where do those assets belong, and how do they relate to the rest of the facility?
Connecting the two gives each physical asset both a unique identity and operational context.
Below the equipment level, additional component detail may be captured through a Bill of Materials (BOM). Above and around it, hierarchy information provides the structure required by maintenance and Enterprise Asset Management (EAM) systems.
Together, these structures create a connected asset information model rather than a collection of unrelated spreadsheets and registers.
This is where Sharecat's perspective differs from a typical CMMS-first approach.
On a capital project, much of the information needed to create the operational asset hierarchy already exists before the facility enters operations. Tags are created during engineering, equipment data arrives from suppliers, documents are associated with equipment, and systems and subsystems are defined throughout design and construction.
If these relationships are not preserved, operations may receive thousands of records and documents without a reliable structure connecting them.
A successful document handover package therefore needs more than files. Asset identities, hierarchy relationships, equipment attributes, and document associations must remain connected as information moves from EPCs and suppliers into the owner-operator's operational systems.
Sharecat helps owner-operators and EPCs structure, validate, and preserve the asset information required to build a reliable operational hierarchy.
Rather than waiting until CMMS implementation to reconstruct asset relationships, Sharecat connects tag records, equipment data, supplier information, documentation, and hierarchy relationships during project execution.
This helps teams identify missing or inconsistent information before handover and provides a cleaner asset-data baseline for downstream systems such as SAP, IBM Maximo, and IFS.
The result is not simply a better hierarchy. It is stronger traceability between the asset as it was engineered, the information delivered with it, and the record operations will use throughout its lifecycle.
What is an asset hierarchy?
An asset hierarchy is a parent-child structure that organizes physical assets from higher-level sites, facilities, or systems down to individual equipment and maintainable components. It provides context for maintenance, reliability, cost, and performance data.
What is the typical asset hierarchy structure?
A practical industrial structure might be Site or Facility → Area or System → Subsystem → Equipment → Component. The exact number and definition of levels should reflect the facility and the organisation's maintenance and information-management requirements.
What is the ISO standard for asset hierarchy?
ISO 14224 is an important international standard for equipment taxonomy and the collection and exchange of reliability and maintenance data in petroleum, petrochemical, and natural gas industries. Organisations commonly combine its taxonomy with their own functional location, equipment classification, and asset-management requirements.
What is asset hierarchy in a CMMS?
In a CMMS, the asset hierarchy structures assets through parent-child relationships so maintenance teams can navigate equipment, create work orders, retrieve history, and analyse costs and reliability at different levels.
What is the difference between an asset hierarchy and an asset register?
An asset register records the assets an organisation owns or manages and their associated information. An asset hierarchy defines how those assets relate to one another within a structured parent-child model.
How deep should an asset hierarchy be?
Only as deep as necessary to support useful maintenance, reliability, cost, and reporting requirements. Component-level records are valuable when components require independent maintenance or failure tracking; unnecessary levels add administrative complexity.
When should an asset hierarchy be defined on a capital project?
Ideally during engineering rather than at the end of the project. Defining hierarchy requirements early allows tags, equipment data, supplier information, and operational requirements to be aligned before handover.
ISO
27001
Certified
