Most companies struggle with building a good asset register to support the asset information requirements, and subsequently the organizational information requirements for the company.
It's therefor very important to consider how you build up an asset register and asset structure, i.e what questions about asset performance, cost, reliability, etc, you need to find an answer to. And how to use the different types of objects in a CMMS or EAM asset register to store information in a way that is easy to manage, easy to maintain, and gather only the informationen needed to be able to answer those questions.
In an asset register, division is made between location/ function, physical assets, items and spare parts. On top of that some asset information requirements can also be answered with the help of information in job plans, work instructions, failure codes, inspection forms, or other related documents and drawings/models that link information to specific location/function or physical asset in the asset-register.
The most important part is to have a common structure to organize all assets; an asset hierarchy (including location and/or function hierarchy as well as equipment hierarchy) and a joint naming/identification scheme.
This will help people find the right asset in the register, and be fundamental to collecting and rolling up information about performance, reliability, cost, etc, to different levels. What those levels in the asset hierarchy are is individual to each and every organization based on the organizational information requirements and subsequent asset information requirements.
A key factor to consider is the need to actually register data about a physical asset or whether it is sufficient to just follow the function the asset performs.
Most importantly is to register data about the physical assets in the asset register where the physical asset itself is sometimes moved from one location to another, these should be specifically noted as rotating assets, and the physical assets that are critical to the organizations goals or has high costs associated with the asset, and for example if decisions on repair or replacement need to be considered.
In the same way, you need to consider whether you have traceability requirements at an individual level for a the physical assets sub- assemblies (creating an equipment hierarchy; ie the motor in a pump). Is there a need to follow a sub-assemblies as a unique individual when it is moved from being part of one asset to another, or in the same way as the asset itself - that it is cost-driven sub-assembly with its own decision points regarding exchange vs repair.
Or is it enough for the sub-assembly to be recorded as a spare part, or maybe there is no need to record the sub-assemblies at all in the asset register. Could it be that a job instruction for the preventative maintenance on the pump to "check motor" is enough to answer the information requirements we have. In other organizations maybe there is a need to record not only the motor as its own individual, but the motors sub-assemblies or spare parts aswell. It all depends how you use it, replace it, how much cost is involved, and therefore how important it is to the organization as a whole.
An attempt should be made to minimize (within the above limits) the number of physical assets that are established in the assets register. By doing this, the asset register becomes easier to manage and also leads to better and more accurate information for analysis and decision-making.
A classic misstake is to create all objects that have a label in a drawing or in a model as an object in the asset register. There is very rarely value in separately recording details at such a low level, or separately analyzing costs / performance for objects at those levels. Thus, the "digital copy" of your plant or infrastructure should not be an accurate 1:1 representation of the physical world down to the nuts & bolts level, but be recorded in the asset register based on a traceability perspective at the functional level.
Location and/or Functional level traceability:
The location and/or functional level is usually recorded as a hierarchy from the entire organisation down to the specific locations where asset are being used, and/or down to the level of specific functions the asset should perform. Some organisation use just a location based hierarchy, other just a function based and some combine them into a location & function based hierarchy with identifiers for what aspect the specific hierarchy level represents.
What type of functions, systems and assets that need to be in the asset register should be defined in asset management plans by the responsible asset manager.
The functional hierarchy will help you locate the assets in the asset register, for example to add work orders or link drawings, show on maps, etc. It will help you roll up cost for a specific function/location, it will help you store failure codes that should be used, and also store information about responsibilities for that specific function/location. I.e any information that is static for a specific function / location regardless of the actual physical asset should be stored on a these objects. It will save time when physical assets are changed/replaced and it will be easier to manage and keep this information correct.
A good CMMS / EAM-system will keep a record of work orders both on the location / function and on the asset that was related to that location/function at the time.
Equipment-level traceability:
Figure 1: Example 1, Asset "Pump 00001".
An asset or sub-assembly can also be linked to one or more defined spare parts / items.
An example here could be a pump, where the entire pump is seen as an asset with asset-number PU00001. To this you can record sub-assemblies (assets) and/or spare parts. A spare part does not have unique traceability but you can still follow up that a part has been changed and that a new motor is in the pump.
Figure 2: Breakdown example 2, "Pump 00001", yellow is assets, green is spare-parts.
Similarly, the same pump PU00001 can instead be registered as an asset with individual sub-assemblies (assets).
Figure 3. Breakdown example 3, "Pump 00001", yellow is asset (and asset as sub-assemblies), green is spare part.
Here, the engine is instead a sub-assembly, i.e. its own unique asset that you can follow as a unique engine throughout the life cycle - that it is this particular engine that you have taken out, sent on service and put back in another pump.
Again, the traceability needs of the company for follow-up and analysis are the deciding factor, as well as the relationship between cost to keep the information against the usefulness of the information.
A simple pump can then be just a single register post "Asset", or 4 assets with 8 spare parts, or a single asset but still 8 spare parts. There is of course even more options how to register this single pump in an asset register - but you get the idea.
Each sub-assembly level of an asset costs money to manage, as the information about every unique asset / sub-assembly need to be kept up to date throughout its life cycle. Generally, the total cost of managing assets increases with the depth of the equipment hierarchy as shown in the following picture, assuming that the basic cost (cost factor x 1.0) is the cost of just keeping track of the functional/location hierarchy to the level needed.
Figure 4. Cost Factor, Taken from Fundamentals of Asset Management (US Government Environmental Protection Agency and SIMPLE, Sustainable Infrastructure Management Program Learning Environment)
Traceability at spare part level
Spare parts are usually at the lowest level in the hierarchy and often do not have as much information attached to them. Generally, a work orders cannot be directly linked to a spare part, but the work order is linked to the asset where the spare part is included. However, you can still follow up on how many spare parts you replaced in an asset, whether it was new or used, when the replacement took place and its cost. But you do not follow the spare parts as unique individuals.
There are advantages to using spare parts instead of sub-assemblies:
• The asset register often becomes more consistent and easier to maintain / manage.
• The asset structure will be easier to navigate as it will not be as deep.
• It will thus be easier to find the right asset to link actions to.
• This leads to information about work is linked to the correct asset in the asset register, which is critical for follow-up and analysis.
Conclusion
Start with developing a asset structure and a naming scheme to use before populating the asset register with objects ans information.
The fewer instances of objects, and as little information you can have, and still answer the important questions about the assets you have the better. So next step; define what questions you need an answer to.
This will make the asset register easier to use; it will be easier find the right asset to record important information to, it will be easier to get the right data out from the register about performance and cost etc, it will be better requirements to external contractors what information that need to be handed over to the asset register, and it will also be cheaper to maintain the asset register in itself and making sure it's up to date and fit for purpose.
Sources;
The Nordic Tribe - Asset Management & BIM Consultants
SIMPLE - Sustainable Infrastructure Program Learning Environment (Cost Factor)