Asset Tagging - Tracking the Duty of an Asset not the Product

by Iain Miskimmin

When we talk about asset information requirements we talk about the pieces of information we need to answer critical questions throughout the life-cycle of a “thing”.

There will be databases, documents, drawings, metadata, spreadsheets, 3D/4D/5D models and all number of pieces of information generated in many forms before we know what physical thing or product is going to fulfil that role.

We identify this virtual need and the space it occupies with a unique identifier that will help us link every instance of the asset at every stage and in whatever form it appears.

This unique identifier is called an asset tag, and it is associated with the “Duty of the Asset”.

This Duty, is the specification of what the thing needs to achieve. During the early phases of a project we know very little about what we require, but there will be critical questions that need answering with information generically defined in our AIR but attached to a specific instance.

Strategy

When we are thinking about the overall Strategy we will need to generate information on a facility level to ensure what we are creating provides the social, environmental and economical outcomes desired. In infrastructure these tags will typically be for hubs or connectors.

Concept

During the concept phase, we may just know that a structure is required in a specific location, but we have no idea of its make-up or design. Thus it is essential that we start tracking the fact that there is a need for a structure here, and pursue the questions that need to be answered. By acknowledging this, we can/should assign an asset tag at Entity level. 

Design

When we get to the Design phases, we will know much more about the make-up of the structure and be able to tag an asset down to Element level, thus providing that unique ID for each individual asset down to the maintainable level. (i.e. a window rather than the glass, sealant, hinges, locks etc.)

Construction

All the tags starting from Facility, through Entity and down to Element should be related in a hierarchy to show how assets are associated with each other and their breakdown structure.

Finally, when we arrive at construction we will have built up a set of performance requirements (the duty of the asset) and we can use this information to go and purchase a product to fulfil that role. 

Asset Register

The asset tags at various levels have appeared in all the documents, drawings and models during this build up, but the most important place for them to be is in the asset register.

This register of assets needs to be accessible from every information creating, gathering and consuming system used in the Project Information Model (PIM), ensuring the “things” mentioned in all these sources of information are linked back to the relevant asset tag. This enables us to have all the information required to answer our critical questions throughout the life-cycle.

This asset register will not only contain information about the duty of an asset, but eventually it will include information on similar products which can fulfil that need, along with all the information about the physical thing.

My advice here is to never lock this register away in a CAD package and restrict its access to a small percentage of your team. Data is for databases so that it can be analysed, reported and linked rather than duplicated.

Temporary works

We need to treat our temporary works the same way we treat our permanent assets. I am not suggesting that we tag every piece of scaffolding, but we are recommending that it is broken down into “supporting service” level, where each temporary works element supports a maintainable asset.

We should record these the same way in every drawing, document or model and ensure that they appear in the asset register to help answer any critical questions. Bear in mind that if they are abandoned in place, they will need to be handed over just like any other permanent asset.

Naming convention

There are two polarised views on how we should deal with an asset tagging strategy. One view is that the tag should contain useful information about the asset - the other view is that it should just be a unique ID that means nothing, because all the information is kept in the asset register/ database.

If you wish to put meaning into the name, then I recommend the following:

Location (Facility code) – Functional grouping code – Function – Unique numerical number.

This will allow you to understand how assets relate to each other and the function they play without needing to delve into the asset register/ database.