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.
