ISO14224

1. 1 of 7
Asset Hierarchy and the Link to Reliability Improvements
James Kovacevic; MMP, CMRP, CAMA
Principal Instructor at Eruditio, LLC
jkovacevic@eruditio.com
The asset hierarchy is often thought of as just a way to organize assets, so they are easy to find in the
CMMS. While a well-structured asset hierarchy does make work management easier, it is much more
than that.
The asset hierarchy, when well conceived and utilized, will ensure that the right reliability and costing data
can be extracted from the CMMS. This enables more than just micro-improvements in reliability involving
a single asset but instead enables macro views of reliability and cost trends across the entire
organization. This is the type of information savvy maintenance managers, and reliability engineers need
to drive sustainable and cost-effective improvements.
For example, when assets are set up in the hierarchy with classes and sub-classes with failure codes, a
reliability engineer can quickly identify trends across the entire site related to lubrication or can dive into
lubrication related issues specific to centrifugal pumps, or lubrication issues related to centrifugal pumps
in a specific process area. Imagine having all of the information at your fingertips, with minimum effort.
Setting Up the Asset Hierarchy
Setting up an asset hierarchy to support these types of activities requires forethought and planning, but
by following some guidelines, any organization can be set up for success. The best guideline available is
ISO14224:2016 Petroleum, petrochemical and natural gas industries -- Collection and exchange of
reliability and maintenance data for equipment. While this standard was designed for Petroleum,
Petrochemical and Natural Gas industries, it is the defacto standard for every other industry. ISO 14224
is the defacto standard for a reason, that reason is simple. It defines all of the requirements to capture,
classify and use maintenance and reliability data at the macro and micro levels.
While ISO14224:2016 is an ISO standard, organizations should develop their internal standard, based on
their business needs, and organizational constraints, using ISO14224 as a reference. The asset
standard identifies how all assets will be categorized, described, and the specific data required for each
asset class. This is vital, as not all assets warrant the collection of specific data, reducing the burden of
the setting up of the hierarchy. A typical asset standard should include at a minimum;
• A taxonomy for the naming of all levels of the asset hierarchy, ranging from the Business level,
down to the maintainable item.
• A list of standard equipment classes and types needs to be defined and loaded into the CMMS.
e.g., Pump, Centrifugal.
• A list of required information for each asset by class and type.
• An asset numbering system.
With the standard developed, the hierarchy can be established. The hierarchy is a systematic
classification of business units, processes, systems and equipment into generic groups based on upon
various factors such as location, use, etc. The standard hierarchy is broken down into nine levels.
The first five levels represent a high-level categorization that relates to industries and plant application
regardless of the equipment involved. The hierarchy is set up this way because equipment can be used in
many different industries. Also, it is vital to have the unique operating context of the equipment for the
various reliability and maintainability analysis. The first five levels include;

2. 2 of 7
• Level 1 – Industry (Natural Gas)
• Level 2 – Business Category (Upstream)
• Level 3 – Installation Category (Drilling)
• Level 4 – Plant / Unit Category (Platform A2109B)
• Level 5 – Section / System (Compression)
Levels 6 to 9 are related to the equipment with further division diving deeper into the equipment in a
parent-child relationship. The remaining levels are;
• Level 6 – Equipment Class (Pump)
• Level 7 – Subunit (Lubrication)
• Level 8 – Maintainable Item (Gearbox)
• Level 9 – Part (Bearing)
It is important to note that in some instances there is no need to dive deeper than level 6, and in other
instances, it is vital to dive down to the individual part level. This distinction should be based on the
needs of the organization, the level of reliability required, and the ability of the organization to analyze and
act on the data. Also, the higher levels of the hierarchy (levels 1-5) can be adjusted based on the
industry the organization operates in. However, those higher levels must standardize across the entire
organization to reap the most benefits.
Once all of the this has been mapped out, the hierarchy can be established in the CMMS, and with the
hierarchy established in the CMMS, the equipment (and lower levels) can be set up.
Setting Up Assets in the Hierarchy
With the asset hierarchy completed, the assets can now be created in the hierarchy. However, it is not
as easy as just putting the equipment in the hierarchy. As with spare parts, there needs to be a defined
taxonomy to govern how equipment is classified, named and where the data goes into the hierarchy.
Without diving into a complete taxonomy, the following should be identified and addressed both in the
hierarchy and during the data collection activities;
• A naming convention for the equipment. This may be the part class and type, followed by some
additional information
• Equipment boundaries. This identifies where a specific equipment class ends and the next
equipment begins. (e.g., the pump, power transmission components are included, but the driver
(motor) is not included in the pump equipment class)
• Equipment numbering system
• A complete list of equipment attributes defined by the equipment class and type (e.g., GPM,
Voltage, HP, etc.)
• A list of required operating attributes (e.g., Criticality, P&ID Number, etc.)
• A list of required manufacturer data (e.g., serial number, model number, date of manufacturing,
etc.)
• Purchase cost
• Date installed
• Technical documents and drawings
• Any other information as defined by the organization
Also, the various sub-assemblies and Bill of Materials need to researched, developed and cleansed to the
appropriate taxonomy (Asset or Spares). Once all of this data has been collected, it needs to be
validated and uploaded into the CMMS.

3. 3 of 7
In the end, all assets should have the following information capture at the equipment level (level 6 in the
taxonomy). This data set consists of;
• Classification Data which includes location, systems, etc.
• Equipment Attributes which include the manufacturer design characteristics
• Operational Data which includes the operating mode, criticality, operating environment, etc.
Having all of this data in the CMMS allows the reliability to slice and dice the equipment to establish
macro trends, especially when combined with failure codes.
Building the Failure Codes
As assets are categorized, the failure code library can be developed and linked to the specific asset
classes/sub-classes. This ensures that only relevant failure codes are displayed for the assets, improving
the adoption of failure data collection.
According to ISO14224, what information should be collected to facilitate defect elimination? Well, it all
starts with the asset hierarchy and linking the class-specific failure codes to the assets. Assuming that
the hierarchy is correct, the information that should be collected is as follows;
• Failure Mode
• Failure Mechanism
• Failure Cause
• Failure Consequence
• Failed Component
• How Failure Was Detected
• Condition of Equipment at Point of Failure
• Breakdown Time
• Repair Time
So how do we make the collecting of failure data easy? We need to build a failure code library based off
of the asset classes and sub-classes defined in the asset standard. Let’s take a look at two examples;
Motor
Part / Component Damage Cause
Contact, Electrical Bent General Design Related
Open Circuit Improper Capacity
Burned/Scorched Improper Material
Cracked/Shattered General Fabrication Related
Oxidized Fabrication Error
Pitted Installation Error
Short Circuit General Ops / Maint Related
Tracked (Ionized)
Operating Specifications
Exceeded
Loose connections Operating Discrepancy
Contaminated Maintenance Discrepancy
Other Elec (Detail reqd in text field) Expected Wear and Tear
Starter Open Circuit Management Override
Burned/scorched Documentation Error
Cracked/Shattered Device Communications
Deteriorated Common Cause

4. 4 of 7
Pitted Combined Causes
Seized Utility Levels (Voltage/Pressure)
Short Circuit Other (Detail required in text field)
Intrinsic (elec/Inst) Unknown
Tracked (Ionized)
Loose connections
Other Elec (Detail reqd in text field)
Breaker
Sensor, Speed
Wire/Cable
Pump, Centrifugal
Part / Component Damage Cause
Bearing Fluting General Design Related
Corroded Improper Capacity
Cracked/Shattered Improper Material
Spalled General Fabrication Related
Brinelled Fabrication Error
Looseness Installation Error
Pitted General Ops / Maint Related
Seized Operating Specifications Exceeded
Deformed Operating Discrepancy
Other Mech (Detail reqd in text
field) Maintenance Discrepancy
Shaft Bent Expected Wear and Tear
Corroded Management Override
Cracked/Shattered Documentation Error
Clearance Device Communications
Pitted Common Cause
Seized Combined Causes
Scored Utility Levels (Voltage/Pressure)
Fatigued Other (Detail required in text field)
Deformed Unknown
Other Mech (Detail reqd in text
field)
As you can see, only parts associated with a motor, or a pump, centrifugal is available as a part or
component. Once the part is selected, only damage related to that specific part is available. This
approach reduces the opportunity for incorrect data to be entered as well, gaining buy-in and support
from the technicians. It is in the author’s experience that a generic list of part and damage codes leads to
technicians not seeing the value of collecting failure data or providing meaningful data.
To develop a failure code library, specific to asset class/sub-class, it requires a team approach and use of
multiple tools;
• Failure Mode Effect Analysis (FMEA) is a step-by-step approach for identifying all possible
failures in an asset or process. FMEA identifies some specific items which can be used to
develop the failure codes;

5. 5 of 7
o Failure Modes are the way in which something might fail. Failure modes typically include
three key components; Part, Problem, and Cause.
o Effects refers to the consequences of those failures, and allows the organization to
determine if the failure mode is worth preventing.
• Reliability Centered Maintenance (RCM) is a process to ensure that systems continue to do what
their user require in their present operating context. RCM includes a FMEA within its process,
along with a decision tree to guide the decision making around the types of activities which will be
performed. Since RCM includes the use of an FMEA, failure coding can be easily extracted from
the failure mode.
• Data mining is another approach in which organizations can mine their work order data to extract
the part, problem, and cause from each corrective and breakdown activity. This failure modes
can then be used to develop the failure coding.
Regardless of the approach used to develop the failure coding, it needs to be specific to the asset
class/sub-class and the organization. Often times, organizations look to purchase a standard failure
code library, and while it can save some time, it needs to be reviewed, validated and refined to meet the
needs of the organization.
Macro Trends in Reliability
With the asset hierarchy built and relevant failure data collected, trends can be established across asset
classes, similar processes, etc. These macro trends enable reliability improvements to be implemented
across larger swaths of assets, providing rapid improvements in reliability.
The macro trends be looked at a variety of different ways;
• Part: What parts are failing across the organization? If bearings are failing, is it a supplier quality
issue, installation issue, or something else? We may be able to combine this with cause code,
but not always.
• Problem: Are we experiencing issues with erosion, or corrosion? Is there an issue with the
incorrect material being specified or used?
• Cause: Installation errors prevalent? If so, is there an alignment standard and is it being used?
• Process/Location: Is there an increase of corrosion related failures in a specific area or process?
Was there a material change, manufacturing parameters change, or a crew change?
• Class: Why are pumps gearboxes failing across the organization? Did the organization change
the supplier, or was a new maintenance plan adopted?
• Sub-Class: Why are the centrifugal pumps failing at a higher rate than the other pumps? Do we
have an issue with cavitation or purchasing pumps without the right specifications?
Using the failure data, along with the asset hierarchy, reliability engineers can quickly identify the trends
that need to investigated and corrected. Without the asset hierarchy and the process related data, the
reliability engineer will struggle to determine if the failure is a process related item, or an asset related
problem. Without the failure coding, the reliability engineer will not be able to identify the specific issues
in the assets or processes.
Diving into the Trends
Without a proper asset hierarchy, any organization will struggle to get meaningful and actionable data
from their CMMS to drive reliability. By combining the asset hierarchy, asset data, and the failure coding,
reliability engineers can dive into the solving the problems. Failure coding on its own will not provide the
root cause to the failures or incidents. The failure codes and trends identify and quantify the scope of the
issues, but then reliability engineers need to use their other tools to determine the root cause(s) and
develop cost effective solutions to eliminate them.

6. 6 of 7
A typical reliability engineer will use one of the 10 tools of root cause analysis to investigate and solve the
issue. The ten Root Cause Analysis include;
• Design and Application Review
• Change Analysis
• 5-Why
• Fault Tree
• Logic Tree
• Sequence of Events
• Event and Casual Factor Analysis
• Ishikawa (Fishbone)
• FMEA
• FMECA
For example, if the macro trends points to a large proportion of the failures being caused by lubrication
related issues, is that enough for the reliability engineer to solve the problem? No, it is not. The reliability
engineer will need to use a fault tree or similar tools to dive into the causes of the lubrication related
failures, and determine what needs to be done to prevent. In order to solve the issue and impact the
macro level issues that are occurring, the reliability engineer need to dive down past the human level and
into the systemic or latent issues. If the reliability engineer targets a specific mechanic, that issue will
likely re-occur with other mechanics, and hence the problem is not really solved.
A systemic issue is a problem or change in company policy or procedures that affects, or has the
potential to affect a process or practice. Solving a systemic issue will have a wide impact on the
organization and will target the wider issue such as poor lubrication practices. It may be caused by, but
isn’t limited to, one or more of the following:
• a system change
• a policy or procedure change
• a lack of policy or procedure
• a lack of clear regulatory guidelines
• regulatory non-compliance
A latent issue goes past the systemic issues, and instead focuses on issues such as the organizational
culture. While a latent issue would be much more difficult to solve, it would have a much wider impact on
the organization, such as professionalizing maintenance.
Implementing the Changes
Changing the Asset Hierarchy usually occurs during a new CMMS implementation. However, many
organizations do not have that opportunity and have to make the changes with a live CMMS. Changing
the asset hierarchy with a live CMMS is not a simple task, but it can be accomplished. There are a few
primary approaches to making the change to a live CMMS;
• Building a second hierarchy in the CMMS while the original is being used is risky. It offers an
opportunity for staff to start using the new hierarchy before it is finalized. However, it does enable
the staff to see the hierarchy and provide feedback. Once the second/new hierarchy is finalized,
then the old hierarchy is de-activated.
• Build the new hierarchy offline and make the change during a scheduled outage. This approach
will prevent tampering with or using the new hierarchy before it is ready, but can shock the staff
when they first see it.

7. 7 of 7
Even with the asset hierarchy well defined and failure codes built out by asset class/sub-class, there is
still a risk of not having the data to drive reliability. Why? It all comes down to people. We still need the
frontline staff to capture the appropriate failure data for the reliability engineer to use. Enabling the
frontline staff to capture the data easily can be broken down to a few key items;
• Keep the failure data lists simple by keeping the lists short. If a technician has to scroll through
page upon page, they will likely not pick the appropriate selection, and pick one that is
convenient. This is why failure codes need to be defined by class/sub-class and setup in the
CMMS.
• Make the data entry easy by deploying mobile solutions or at a minimum, having computers
strategically located through the facility.
• Train the frontline staff on the reasons why the failure data needs to be collected, and
demonstrate the value of the data. If the frontline staff do not see the data being used, they will
stop providing the quality data that the reliability engineers depend on.
Once all of the data has been collected, the organization actually has to use the data to identify large
trends. It is only when the trends are identified and investigated will the link between asset hierarchy and
reliability become apparent and benefit the organization. Making the change in asset hierarchy and
failure data is not an easy task, as is most change, but it is vital for organizations to systematically
eliminate losses and drive improved performance.
Keywords
asset hierarchy, failure codes, failure modes, CMMS, asset data, failure data, ISO14224,