Learn how to structure asset registers and hierarchies: TAGs, levels, taxonomies, attributes, criticality, CMMS/EAM, BIM, COBie, data quality and governance.
Check it out!
An asset register is the information structure that identifies each relevant asset, describes its technical attributes, and places it within a hierarchy consistent with operations, maintenance, and lifecycle management. A useful register is not a list of equipment: it must make it possible to locate the asset, understand its function, relate it to systems and components, connect documents and history, and support decisions on maintenance, reliability, spares, risk, and renewal.
The asset hierarchy defines how facilities, systems, subsystems, equipment, and components relate to one another. There is no single universal tree applicable to every organization. The level of decomposition should respond to how the information will be used. An overly superficial register prevents analysis; purposeless granularity increases cost, duplication, and inconsistency.
What an asset register is and why it is decision infrastructure
In infrastructure-intensive organizations, many decisions depend on answering apparently simple questions: which equipment failed, where it is installed, which function it serves, which circuit supplies it, which procedure applies, which parts are compatible, what its criticality is, and which interventions have already occurred. When these answers depend on informal knowledge or several disconnected spreadsheets, maintenance loses traceability.
The register organizes the asset’s technical identity. It creates a common key for connecting inspections, maintenance work orders, drawings, manuals, tests, certificates, photographs, spare parts, failure events, and indicators. This connection is more important than the number of populated fields.
ISO 55001:2024 requires the organization to determine and manage the information necessary for the asset management system. This does not mean the standard prescribes a single asset-register model. Responsibility remains with the organization: define which data are necessary, at what quality level, at which level of the structure, and for which decisions.
Financial asset records and technical asset registers are not the same thing
Financial asset records typically address ownership, book value, cost center, administrative location, and depreciation. The technical asset register addresses function, engineering characteristics, interfaces, condition, maintainability, and operating history. The two may share identifiers and need to interoperate, but they serve different purposes.
A transformer, for example, may appear as a single financial asset. For maintenance, however, it may need to be related to the electrical system, substation, busbar, protection, ventilation, accessories, and inspection points. The accounting structure does not replace the functional structure.
| Dimension | Financial asset record | Technical asset register |
| Primary objective | Economic and accounting control | Operations, maintenance, reliability, and Engineering |
| Typical unit | Financial asset | Technically manageable system, equipment, or component |
| Attributes | Value, acquisition, depreciation, cost center | TAG, function, manufacturer, model, capacity, parameters, condition |
| Relationships | Administrative unit, owner | System, subsystem, location, power supply, redundancy, interfaces |
| History | Financial-asset movements | Failures, inspections, work orders, tests, changes, and interventions |
| Decision supported | Accounting and financial | Technical and lifecycle |
An asset should only become a maintenance object when there is a reason to manage it separately
Not every physical component needs an individual TAG. The criterion should be the need for a decision. If the component has its own plan, relevant history, risk, cost, spare, inspection, or traceability requirement, there is a case for identifying it separately.
Creating thousands of records for elements that will never be managed individually creates noise. The opposite is also problematic: grouping several critical pieces of equipment in a single record prevents identification of failures, resource consumption, and unit-level performance.
How to structure the asset hierarchy
Hierarchy is the representation of relationships among technical objects. In an industrial or building facility, a common structure may start from the project or site and descend through areas, systems, subsystems, equipment, and components. However, this sequence is only a reference model.
IEC 81346-1:2022 provides general principles for structuring systems and creating unambiguous reference designations. Its contribution is important because it separates structuring from the equipment’s simple name: an object may be viewed by function, product, location, and other perspectives without losing identity.
ISO 14224:2016, although specific to petroleum, petrochemical, and natural-gas industries, is a useful reference for how equipment taxonomy, attributes, failures, and maintenance can be standardized to enable reliability analysis. It should not be treated as a universal taxonomy for every sector, but it shows why classification consistency matters.
The diagram above represents a conceptual structure. The number of levels may be smaller or greater depending on complexity and management needs.
Functional and physical structures do not need to be identical
One cause of weak asset registers is attempting to represent all engineering relationships in a single tree. A physical equipment item may participate in a function, be located in a room, belong to one system, and receive power from another system. Forcing all of these relationships into parent-child relationships creates ambiguity.
The primary tree should have a declared logic. Additional relationships can be modeled through fields or links: supplied by, protects, measures, redundant with, controlled by, serves, installed in. This approach is closer to the reality of interdependent systems.
How to choose the level of decomposition
The right question is not how far we can decompose, but how far we need to decompose in order to decide and maintain. Granularity should reflect risk, maintenance, and information cost.
| Question | If the answer is “yes” | Implication for the register |
| Does the item have its own maintenance or inspection? | There is an independent activity | Consider an individual record |
| Does the failure need to be analyzed separately? | The history has analytical value | Create a traceable identity |
| Is there a specific spare? | Replacement needs to be planned | Link the part and compatibility |
| Is there a specific legal, standards-based, or safety requirement? | Evidence needs to be demonstrated | Maintain controlled attributes and history |
| Does the item have its own criticality or consequence? | Priority may differ from the assembly | Separate it for decision-making |
| Does the cost of maintaining the data exceed the benefit? | The record does not change any decision | Avoid artificial granularity |
TAG, code, name, and identifier: what each field should do
A TAG is a persistent technical identification of the object. The name may change to improve readability; the description may be expanded; the physical position may change. The identifier needs to preserve historical continuity when the same asset continues to exist.
A good TAG is unambiguous within the defined scope, readable, governed, and resistant to unnecessary changes. Avoid codes that embed so much meaning that any area or function change requires recoding the entire base.
A TAG should not replace attributes
A code such as BLD-A-QGBT-01-380V-1600A appears informative, but it mixes identity, location, type, voltage, and capacity. If capacity changes or the switchboard is relocated, the code becomes inconsistent. In many cases, it is better to keep a more stable identifier and store characteristics in dedicated fields.
Short name and technical description serve different purposes
The name should enable quick recognition, such as Main LV Switchboard – Block A. The description can detail function and scope. Characteristics such as voltage, rated current, manufacturer, and model should remain in structured attributes whenever analytical use is expected.
Which fields an asset register should contain
An initial register does not need to start with hundreds of fields. It should begin with a reliable minimum core and evolve as processes require additional data.
| Data group | Example fields | Decisions supported |
| Identification | ID, TAG, name, class | Traceability and search |
| Structure | parent, system, subsystem, location | Hierarchy and functional context |
| Engineering | manufacturer, model, capacity, parameters, drawing | Diagnosis, design, and specification |
| Operations | function, operating regime, redundancy, load, criticality | Risk and continuity |
| Maintenance | plan, interval, strategy, inspection points | Maintenance Planning and Control and execution |
| Reliability | failure modes, history, MTBF/MTTR where applicable | Analysis and improvement |
| Supply | spares, lead time, equivalents | Inventory and recovery |
| Documents | manual, drawing, certificate, report, procedure | Evidence and technical support |
| Lifecycle | installation, warranty, obsolescence, renewal | CAPEX and planning |
Mandatory fields should be few and justified. Making every field mandatory usually encourages fictitious entries simply to get past the screen.
How to create an asset-class taxonomy
When the current database contains duplicate TAGs, assets without functional relationships, scattered documentation, or histories that cannot be associated with the correct equipment, the problem is no longer merely registration-related: it compromises Maintenance Planning and Control, indicators, and technical traceability.
A class groups objects that share relevant characteristics. Classes make it possible to define sets of attributes, plans, and analyses without repeating configuration for each asset.
An electric motor and a circuit breaker do not need the same technical fields. The motor class may require power, voltage, speed, frame, and bearing; the circuit-breaker class may require rated current, interrupting capacity, protection unit, and mechanism.
The taxonomy should balance standardization and applicability. Classes that are too generic lose information; excessively specific classes cause the number of templates to explode.
Class, type, and model are not synonyms
Class represents a functional or technical category. Type may represent a variation within the class. Model is the manufacturer’s commercial designation. Mixing these levels makes it difficult to compare equivalent assets from different manufacturers.
How to connect the asset register to maintenance, Maintenance Planning and Control, and reliability
The register only creates value when it becomes the reference for operational processes. A maintenance work order should point to an identifiable asset or technical object; failure history needs to return to the same record; inspections and measurements should be comparable over time.
Without this, indicators aggregate events from different objects or lose events because teams enter free-form names. Pump 1, B-01, main pump, and PUMP-001 may represent the same equipment and generate four disconnected histories.
Data quality directly influences MTBF, MTTR, and backlog
If failures are not associated with the correct asset, MTBF loses validity. If the start and end of downtime are not recorded consistently, MTTR or restoration time becomes distorted. If work orders do not include an asset and criticality, backlog cannot be prioritized technically.
For this reason, the asset register is not system hygiene; it is a prerequisite for reliable indicators.
Asset register and criticality
Criticality may be an asset attribute, but it needs to result from a defined methodology. It should not be entered as the registrar’s informal opinion.
When relating criticality to the hierarchy, it is necessary to decide how to treat it across levels. A system may be critical because it serves an essential function, but not every component within it will have the same consequence. Automatically inheriting parent criticality for all children may overprioritize items. Ignoring system criticality may do the opposite.
Classification should be applied at the level where consequence and decision are analyzed.
Asset register, documentation, and technical configuration
Assets change. Equipment is replaced, circuits are rerouted, firmware is updated, protections are adjusted, and components are retrofitted. The register needs to distinguish object identity, current configuration, and change history.
When equipment is replaced by a new unit, the organization should decide whether to retain the same functional object with a new physical instance or create a new asset. This rule depends on what needs to be preserved in the history.
Physical replacement and functional continuity
In many environments, the functional position continues to exist even when the component is replaced. A useful concept is to separate functional position from installed equipment. This makes it possible to retain the Pump P-101A function and record which physical unit occupies the position over time.
This distinction is especially important for repairable assets, rotating spares, and equipment that moves among positions.
How to integrate BIM, COBie, CMMS/EAM, and the asset register
BIM and COBie can provide relevant information for operations, but a BIM model should not automatically be considered a ready-to-use operational asset register. Before import, it is necessary to define which objects will become manageable assets, which attributes are required, and how IDs will be maintained.
The CMMS/EAM normally becomes the system of record for plans, work orders, and maintenance history. BIM may remain the spatial and technical representation; GED/CDE the document repository; supervisory systems the operational source. Integration needs to avoid multiple competing sources for the same attribute.
A single source of truth does not mean one system for everything
Each domain may have an authoritative system. What matters is declaring which system is the master for each piece of information and how the other platforms synchronize with or reference the data.
Example: TAG and class may be mastered in the EAM; documents in the GED; coordinates and spatial location in BIM; process data in SCADA. The integration key makes it possible to retrieve the whole set without duplicating responsibility.
Data quality: completeness is not enough
A database may be 100% populated and still be poor. Quality involves correctness, consistency, currency, uniqueness, traceability, and fitness for use.
ISO 55013:2024 provides guidance on data management to support asset-management objectives and reinforces that data usefulness depends on context. For the asset register, this means quality should be measured by its effect on decisions, not by the volume stored.
Asset-register quality indicators
Useful controls include duplicates, assets without a parent, repeated TAGs, missing critical fields, broken document links, records without location, deactivated assets with open work orders, and divergence between field conditions and the system.
The goal should not be to fill everything in, but to reduce inconsistencies that compromise the technical process.
How to survey an asset register in existing facilities
Asset-register cleansing in existing facilities requires reconciliation of spreadsheets, documents, systems, and actual field conditions. For critical assets, physical validation prevents the organization from digitizing an outdated structure.
In brownfield environments, the database is rarely clean from the start. Outdated drawings, illegible labels, equipment replaced without document revision, and differing nomenclature are common. The survey should combine existing documentation with physical verification.
The process may begin with definition of scope and taxonomy, followed by document collection, import of existing databases, field inspection, reconciliation, and technical validation. Photographs and evidence help resolve discrepancies.
Do not digitize disorder
Migrating spreadsheets to a CMMS without cleansing merely turns inconsistency into digital inconsistency. Before final loading, it is necessary to deduplicate, normalize classes, resolve TAG conflicts, and confirm hierarchical relationships.
How to govern asset-register changes
When the register already exists but does not support plans, work orders, criticality, and indicators, the central issue is redesigning the information architecture and maintenance governance—not merely populating new fields.
A reliable database needs a change process. Who can create an asset? Who approves a TAG change? Who changes the class? Who retires an asset? How is a replacement recorded? What happens when a project hands over new equipment?
Without governance, quality deteriorates quickly after the cleansing project.
New-asset onboarding should start during design and handover
Operational information should not be reconstructed only after construction. Requirements for the asset register, TAGs, attributes, and documentation can be defined during design and incorporated into specifications and delivery criteria.
At handover, the asset register should be verified together with As-Built documentation, manuals, certificates, plans, and spares. This reduces the gap between implementation and structured maintenance.
Common mistakes in asset registers and hierarchies
The first mistake is confusing the number of records with maturity. The second is creating a hierarchy merely to reproduce an organizational chart or physical address. The third is allowing each team to invent its own naming and class standards.
Other recurring problems include frequent recoding of TAGs, duplication across systems, populating attributes without a source, absence of lifecycle status, and lack of linkage between the register and documentation.
A good register is smaller than an indiscriminate database but far more connected to actual processes.
How to structure an asset-register implementation or cleansing project
Implementation should begin with priority uses. If the objective is to structure Maintenance Planning and Control, assets included in plans and work orders have priority. If the objective is criticality and renewal, the structure needs to represent functions, systems, and consequences. If the organization intends to integrate BIM and EAM, IDs and synchronization rules need to be defined before loading.
A consistent sequence is:
- Define the objectives and decisions the register must support.
- Establish scope, hierarchy levels, and identity rules.
- Create the taxonomy of classes and attributes.
- Normalize existing databases.
- Physically validate a sample and critical items.
- Migrate and reconcile data.
- Integrate documents and systems.
- Define governance for creation, change, and deactivation.
- Measure quality and correct deviations.
Final considerations
The asset register and hierarchy form the information infrastructure on which maintenance, reliability, and asset management operate. The objective is not to produce an attractive tree in the system, but to establish identity, context, and relationships that make it possible to turn field events into history and history into decisions.
The best structure is the one that maintains enough information to manage risk, performance, cost, and lifecycle without creating purposeless administrative complexity. When hierarchy, TAGs, attributes, and governance are coherent, CMMS, BIM, inspection, Maintenance Planning and Control, and reliability analyses begin to share the same technical language.
Technical references
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 55001:2024 — Asset management — Asset management system — Requirements. 2024. Available at: https://www.iso.org/standard/83054.html.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 55013:2024 — Asset management — Guidance on the management of data assets. 2024. Available at: https://www.iso.org/standard/82455.html.
[3] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 81346-1:2022 — Industrial systems, installations and equipment and industrial products — Structuring principles and reference designations — Part 1: Basic rules. 2022. Available at: https://www.iso.org/standard/82229.html.
[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 14224:2016 — Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data for equipment. 2016. Available at: https://www.iso.org/standard/64076.html.
Frequently asked questions
It is the organized structure that identifies assets, records technical attributes, and relates each object to the hierarchy, documentation, maintenance, history, and lifecycle.
It is the structure that represents relationships among the project, areas, systems, subsystems, equipment, and components. It should be defined according to the decisions and processes the organization needs to support.
No. A component should be identified individually when there is a need for maintenance, inspection, history, risk, spares, cost, or specific traceability.
Financial asset records mainly support accounting and economic control. The technical register organizes function, engineering characteristics, relationships, maintenance, condition, and operating history.
Not necessarily. BIM can be an important source or representation of information, while CMMS/EAM typically controls plans, work orders, and history. The architecture should define the authoritative system for each data element and the integration keys.
No. There are principles and sector-specific references, but the level of decomposition and the tree need to be appropriate to the organization’s function, risk, and processes.
Additional technical resources
Related services
- Engineering Asset Management: asset register, criticality, lifecycle, and performance
- Maintenance Engineering: strategies, reliability, plans, and indicators
Related solutions
Core content on the topic
- CMMS: what it is, how it works, and integration with BIM and asset management
- ISO 55000 and Asset Management: principles, ISO 55001, and management system
