Development of a complementary framework for implementing asset register solutions

A correctly compiled asset register within an asset information management system (AIMS) provides the foundation for a successful asset data solution. The lack of correctly structured asset registers within organizations is acknowledged among research and communities of practice. A case study identified anomalies that emerge when using established standards, after which a comprehensive solution for hierarchies, naming conventions and attributes was offered. While standards such as BS ISO 1007 and ISO 14224 provide overarching solution principles, such provisions are not all-encompassing and exist across several sources, which makes the task of developing asset registers error-prone and laborious. Challenges associated with software applications were highlighted through combining personal industrial experience as well as consultations with the existing body of knowledge. Recommendations that enable successful deployment of AIMS, with emphasis on its accommodation of a reliable asset register were then proffered. Scalability was addressed which enables an asset register to expand. This study describes a novel and simplified approach embodied within a single document. Combining the prescriptions of this article with existing literature will ease the delivery of an asset register.


INTRODUCTION
The creation of asset registers is often overlooked at the project phase by owners and project stakeholders, although they are an essential component of an asset management solution.Data and information handover to the operations phase is left until the completion of the project phase and information is typically handed over in incorrectly structured formats.With this late delivery of unstructured data, it becomes very challenging for owners and asset managers to assess whether the information they need is present and correctly structured.In addition, the transfer of such data and information to the asset information management system (AIMS) is a costly and time consuming process, resulting in extended periods before optimal asset performance can be determined, as optimization decisions (e.g., maintenance, energy, safety) at the operations phase are delayed.Asset data forms the foundation of an effective asset management solution. 1An asset register is used to record all assets, their attributes, hierarchies, and other relationships between the assets. 2Asset data begins its life during the project stage and contributes immensely to good project management practice that emphasizes that a comprehensive set of data accompany assets during handover to operations.This should include the asset register being entered accurately into the appropriate systems such as a computerized maintenance management system (CMMS), enterprise asset management system (EAMS), or the asset management module of an enterprise resource planning (ERP) system. 3For this study, AIMS has been chosen as an umbrella term for the above systems.Before further exploring the issues and potential solutions in relation to compiling an asset register, it is important to first understand the general requirement and purpose for asset data.Asset data is used to support the practice of equipment maintenance.The importance of asset data has increased in line with the advancements in equipment maintenance practices.Mobley 4 categorized the generational shifts of equipment maintenance into four stages with the following description provided by Dinmohammadi et al. 5 on the second generation, which is most relevant to this article.The second generation, also known as diagnostic, was developed during the 1970s.In this generation, there was a focus on development of tools that allowed assessment of an asset's condition and identification of reasons for failure with the objective of preventing future equipment failures.With this approach, preventive maintenance activities are performed on a time-based frequency to minimize the impact of equipment wear.The second generation is the point where maintenance has evolved to become asset management and with this more strategic approach comes a requirement for appropriate data to support decision making. 6To properly understand asset management, it is useful to refer to the ISO 55000 standard which defines an asset as "an item, thing or entity that has potential or actual value to an organization" and asset management as involving "the balancing of costs, opportunities and risks against the desired performance of assets, to achieve the organizational objectives". 7he second generation is also the period when improvement of reliability becomes a desired output of maintenance.Reliability is defined as the "ability of an item to perform a required function under given conditions for a given time interval". 8,9In order to achieve continuous improvement (CI) in the area of reliability, we must learn from past failures.Labib 10 has investigated the subject of reliability and argued that organizations need to perform risk and reliability analysis in order to avoid disasters successfully.Key to the mission of CI is having robust data that informs.Another advantage of having data, when required, is the enabling of healthy asset management decision making which adds value, reduces cost, and minimizes waste. 11Too 12 has observed how decisions are derived from the condition and performance of assets and that methods for analyzing and integrating information are central to this process.
As the paper's primary focus is on static rather than dynamic asset data, it is useful to explain the difference between the two.According to Collins English dictionary, "dynamic" refers to "a process that constantly changes and progresses", 13 while "static" depicts "something that does not move or change". 13In the context of asset management, static data includes: the asset hierarchies; the applied naming convention; and attributes such as make, model and serial number.Dynamic data on the other hand includes: asset status; criticality ranking; run-hours; and number of cycles.Values for static data are fixed for the lifecycle of the asset while values for dynamic data can change or vary throughout the asset lifecycle.In an asset management context, static asset data is contained in an asset register.The approach to the management of asset data can be included in the practice of Configuration Management (CfM).According to ISO 10007:2017 Quality management-Guidelines for configuration management, configuration management is a management activity that applies technical and administrative direction over the life cycle of a product and service, its configuration identification and status, and related product and service configuration information. 14Haider and Koronios 15 further define CfM as a focus on "ascertaining, preserving, and sustaining a system's functional and physical attributes according to their design and operational requirements all the way through the lifecycle of system".An advantage of the CfM approach is that, during the life cycle of an asset, change management is a built-in process that controls the changes while ensuring consistency between such changes as well as their related documentation. 16A challenge associated with CfM, as suggested by Burgess et al., 17 is that it is considered a Cinderella discipline and suffers from a lack of recognition.Kidd 18 goes further to suggest that CfM is viewed as nothing more than "glorified change control or version management".
The asset data lifecycle model in Figure 1, is presented to illustrate the focus of this study within the broader context of the full lifecycle of asset data.It also displays how the initial life stage of asset data occurs outside of the AIMS.The culmination of the initial stage can be considered to have resulted in the creation of or addition to an asset register.Once the data is refined and inserted to the AIMS, it is then considered to have entered the more dynamic stage of its life.The focus of this study is on the early stage in the lifecycle of asset data namely, the period in which the asset register is created.Since the majority of work orders in an AIMS are written against an equipment (or asset record), then the asset register database is a core requirement, and is usually the first database created with an initial implementation of an AIMS. 19hen a work request is initiated (for either preventive or corrective maintenance activities), the system will first check the unique code of the asset from the asset register.Additionally, the asset register supports the generation of spare parts allocation, thereby providing answers to fundamental questions such as "where is it used?"(i.e., from a spare parts point of view) and "what does it consist of?"(i.e., from an asset point of view).
In addition to examining the available research papers, a trawl through the relevant standards and guidelines was performed.Table 1 provides a summary view of the gaps in relation to hierarchies, naming convention and static attributes.
The extensive review of asset data related standards revealed the availability of several sources of information that proffer some solutions for creating asset registers.However, there are no standards or guidelines among those reviewed that addresses all requirements in a holistic manner, thereby making the process of information gathering and subsequent implementation very laborious and time-consuming.Based on this premise, the following research questions have been formulated: 1. What are the technical limitations within the existing published standards and guidelines, which deal with asset data, in relation to providing guidance for implementing an asset register solution?2. Using the existing published standards and guidelines as a baseline, can additional guidance be developed to enable an asset register solution to be delivered?
In terms of research methodology, the available research papers were examined and in addition, the relevant standards and guidelines were delved into.This article contributes to a closing of the gap in relation to the guidance provided by relevant ISO standards and guidelines in the assembly of an asset register.The outcome of the case study, combined with other research findings are reviewed to identify commonly encountered challenges during the compilation of asset registers.The solutions which follow, will then feature a combination of data assembly, AIMS oriented and scalability suggestions.It is however crucial to note that the actual descriptions of the assets and their associated data used for this exercise has been completely anonymised due to strict data confidentiality agreements between the first author and the facilities management (FM) department of the case study.Additionally the solution, as deployed in a software application, cannot be displayed due to information security restrictions at the request of the organization.Irrespective of the aforementioned limitations, the current study adequately highlights the core challenges of implementing asset register as well as proffers holistic solutions through a systematic and practical approach.Hence, the remainder of the article is structured such that Section 2 contains the problem statement, Section 3 provides details of the chosen case study, while Sections 4 and 5 respectively describe the results obtained as well as the concluding remarks.

PROBLEM STATEMENT
The lack of correctly structured asset registers within organizations is a recognized issue among research and communities of practice alike.There are multiple standards and guidelines that can assist in addressing this challenge but there is no single source to help with delivery of a solution.In the United Kingdom (UK), the asset register is listed as a systems requirement during commissioning, training and handover, which forms part of the Government Soft Landings (GSL) initiative. 30One of the most important steps in the assembly of an asset register is to establish hierarchies, but why is this?2][33][34] Additionally, Whyte et al. 35 suggest that asset owners look to use information to achieve sustainable and safe performance throughout the life-cycle.As AIMS are central to achieving an asset data solution, it is important that their deployment is successful.McKay and Buzacott 36 have observed that companies need industrial strength information systems which deliver in an operations context, integrate with existing or new systems, and receive all necessary support.Kans 37 points out that data / information requirements of the AIMS should be ascertained concurrent to the functionality requirements.Wan et al. 38 have stated that information systems should deliver a method for timely exchange of information and knowledge which allows users to reuse lessons that were previously learnt. 39While these points highlight the importance of correctly set-up AIMS, there is much documented evidence on the associated challenges.A survey by O'Hanlon 40 showed that only 20% of respondents could describe their AIMS deployment as successful.Information quality is dependent on correctly captured and structured data.Tretten et al. 41 maintain that the risk for errors is increased when there is too much information, incorrect information, incorrectly grouped and/or located information.Yunusa-Kaltungo et al. 42 highlights that companies can encounter difficulty when analyzing asset performance trends due to inconsistencies in the form of captured data.Hence, a correctly implemented asset register is fundamental to delivering the requirements and answering these concerns.Finally, systematic evaluations of the standards and guidelines in specific case studies are still lacking and deserve noteworthy attention.This study proposes a methodology for the creation of asset registers by building on existing published standards and guidelines.

CASE STUDY-BASED DEMONSTRATION OF ASSET REGISTER ISSUES
This study aims to support asset management stakeholders (i.e., managers, engineers, technicians, asset owners, and project managers) with the task of creating asset registers using applicable standards and guidelines.This aim is investigated within the life cycle of static asset data.To achieve this aim, a case study driven methodology, which builds on ISO 14224, is proposed.ISO 14224 was selected due to the guidance it provides in relation to asset hierarchies and attributes.
Other relevant established standards and guidelines for the creation of an asset register were reviewed and their shortcomings are identified.The case study is an attempt at applying the guidance of ISO 14224 to a set of static asset data from the FM profession.The case study is designed to deliver the two-fold goal of assessing ISO 14224 and developing additional guidance that can be used to deliver specific owner requirements in the creation of asset registers.The article expands a theory based on a new methodological-theoretical approach and achieves this through testing existing guidance and then builds on this to provide an improved approach.A case study-based research fundamentally involves the analysis of data gathered from real-time operational scenarios from several sources of evidence that represent previous or current occurrence(s) within an organization. 42Owing to the specificity of the scopes of case study-based research works, they are capable of supporting the creation of detailed knowledge of the concepts investigated.Although some studies have questioned the reliability of generalizing findings obtained from case-study research, especially due to insufficient data heterogeneity. 43,44However, their ability to simplify the visualization of actual industrial experiences is often crucial for the representativeness of the results obtained from the analysis of complex concepts. 45,46The case study in this article is based on a real life challenge encountered during implementation of an asset register in a large European FM organization.The rationale for using real-life data is to provide an adequate test platform for the proposed framework so that conclusions drawn from this test can be easily transferred to real-life implementation of an asset register.The operation of this company involves delivery of national gas and water infrastructure and services.The company also provides dark fiber broadband infrastructure.The complexity of the operational challenges, especially from a FM perspective relates to having multiple sites, locations and business units.For one department to oversee this complex estate, a standardized approach is required so that the asset register structure can be seamlessly replicated from one site to another.While it was not possible to share the detailed solution, owing to confidentiality requirements, the framework proposed here was implemented and the outcomes with regards to data accuracy, ease and speed were compared to conventional approaches that were based on established standards alone.The case study demonstrated the proficiency of the proposed framework for alleviating some of the commonly encountered problems.The lessons learned and documented in this article can serve for others to address a similar challenge.Therefore, the current study initially uses a case study to bring to fore the inadequacy of the guidance provided by existing standards with regards to asset register compilation.While the sample data set used in the exercise was obtained from the FM profession, at a data level the problem revealed is industry agnostic.

Identifying hierarchy issues
Based on the outcomes of the comparative analysis conducted in Table 1, ISO 14224 offers superior and more encompassing guidance.Therefore, the selected case study will use ISO 14224 and apply its guidance in assembling data for an asset register.Although Uniclass 2015 also offered good guidance with regards to the naming convention, the authors have chosen not to utilize it due to it being revised on a monthly basis and therefore not guaranteeing consistency of approach.Three main figures (Figures 2-4) will be featured as part of the exercise.On the one hand, Figure 2 originates from an already published standard and primarily shows an example of how asset data is structured hierarchically in accordance with ISO 14224. 20Figures 3 and 4, on the other hand, were produced and populated during this study to depict some of the limitations of existing standards.The contents of Figures 2 and 3 are considered typical in the FM profession.9) represent asset data.In order to enhance visualization, Figure 4 provides sample representation of the data set used for the exercise, which were also structured according to the guidance depicted in Figure 3.The representation of data in Figure 4 provides evidence of suitability for a single asset.However, owing to the vertical layout, it visually suggests the following parent/child relationships: SS site is a child of BB business unit whereas in reality, a site can serve more than one business unit as can be seen in the case of AA and BB.Heating, ventilation and air-conditioning (HVAC) is a child of the third floor whereas in practice, HVAC exists on and serves all floors.The insertion of the sample asset data set into Figure 4 presents common issues that need to be resolved.Central to these issues is that the pyramid structure cannot effectively cater for multiple assets that have different attributes in the upper levels but the same, or similar, attributes in the lower levels.While we have presented this case from an FM perspective, the highlighted issue can also occur across any industry.Based on evidence from previous industrial experience of the lead author within pharmaceutical production sites, it is very common for two discreet business units to be owned by the same parent company.Hence, by revisiting the HVAC example which is present as a system across all sites in all companies, the asset data needs to be structured in such a way that it is possible to separate it for reporting purposes.

Asset identification
An asset register, whether it resides on paper, a spreadsheet or in an AIMS, requires that each asset has a unique identifier (ID).The function of the ID is to allow separation of assets for interrogation and reporting.The approach featured in this subsection, although commonplace has limitations.There is widespread use across all industries of smart or intelligent IDs for the purpose of naming assets.This involves basing the asset ID on the asset attributes but in a compressed format. 47The following points give an example of a smart ID in practice.There is a steam boiler in a utilities building on a manufacturing site in Cork, Ireland.The company is part of a multinational corporation.Based on this information, the boiler could have the following smart ID applied: IRL/CRK/UTIL/BLR.An argument can be made that placing a label on an asset with an inscription of the smart ID helps inform maintenance staff.However, its value is questionable as it informs a person with an engineering background they should already know (i.e., that they are situated in the utilities building in Co. Cork, Ireland).An additional case can be made that the use of smart IDs ease the searching for assets within the AIMS.However, a counter argument is that modern AIMS have much improved search and navigation functionality, resulting in the negation of this need.Additionally, recent and ongoing technological advancements have also led to the emergence of several systems that possess multifield search capabilities that support assets tracing based on their multitude of attributes.

Scalability
Weinstock and Goodenough 48 defined scalability as "the ability to handle increased workload without adding resources to a system".This definition relates to the characteristics of the actual information technology (IT) tool.The authors contend, while this is important when it comes to AIMS performance criteria, there are also measures that need to be taken with regard to the assembly of data that is inserted into the system.An effective approach to data structuring will aid in the delivery of scalability.In terms of smart IDs, when AIMS had limited capability in terms of database configuration, the concept had merit.However, now that AIMS have advanced, there are grounds to challenge the necessity of this approach and suggest that it hinders rather than helps scalability.The following scenario further highlights the limitations of the smart ID.By referring back to the case study whereby there are two steam boilers in a utilities building on a manufacturing site in Cork, Ireland (a company that forms part of a multinational corporation).The smart IDs for these boilers are IRL/CRK/UTIL/BLR1 and IRL/CRK/UTIL/BLR2 for the numbers 1 and 2 boilers respectively.IRL/CRK/UTIL/BLR2 has reached end of life and requires replacing.As the replacement will require a unique ID, should that now be called IRL/CRK/UTIL/BLR3?If so, there will be IRL/CRK/UTIL/BLR1 and IRL/CRK/UTIL/BLR3 but no IRL/CRK/UTIL/BLR2, which is not logical.IRL/CRK/UTIL/BLR2 cannot be reused as that will either result in the loss of data for the replaced boiler or have incorrect and obsolete data for the new boiler.By inserting a sample data set into a figure structured according to a published standard, it was revealed that the approach to hierarchies was not suitable for collective assets.In relation to asset IDs, a view was offered that the term "smart" may be a misnomer and that this approach actually presents limitations.Smart IDs were also shown to have a potentially negative effect on scalability.

DISCUSSION OF CORE FINDINGS
The second research question asked "Using the existing published standards and guidelines, can additional guidance be developed to enable an asset register solution to be delivered?"As observed in Figure 1, an asset register comprises of three components namely the hierarchies, naming convention and static attributes.Figure 5 illustrates how each of the proposed solution elements map to deliver the components of an asset register.This section details that there is great value in applying CfM practices to asset data throughout its life cycle, in the areas of hierarchies and static attributes.Once this is applied, the focus of this study will then shift toward how AIMS can aid the delivery of hierarchies, after which scalability measures are considered as part of the solution for the naming convention and hierarchies.

Configuration management
This subsection of the article describes, as well as illustrates, the outcomes of the test performed on the proposed framework using anonymised real-life data.Asset hierarchies for a single asset ISO 14224 is often considered the strongest standard and will be used as a starting point in the development of guidance for the hierarchies and attributes aspect of an asset register solution.The suggested solution advocates that each asset does not have a single hierarchy.It has instead multiple hierarchies such as business, location, system and asset.
In ISO 14224, this is alluded to when taxonomic levels are categorized but this study maintains that it needs more elaboration and definition.In Figure 6, the pyramid structure used in Figure 2 is converted to horizontal format, which better reveals the individual hierarchies.The reasoning for this conversion is based on the premise that asset registers start their lives out as raw data in spreadsheets with cleansing of asset data performed in the spreadsheet before bulk upload to the AIMS.When Microsoft Excel is being used to house the raw asset data, a horizontal format is essential as a spreadsheet is limited to 16,384 columns by 1,048,576 rows.As the number of asset attributes will certainly be less than the number of assets in an asset register, it is better to have the assets occupying rows and the attributes occupying columns.In addition, the Excel rows are numbered but the columns are not.Finally only columns are "filterable" in a spreadsheet so to interrogate an asset register by its attributes, rows must be used to house the data of each asset.Therefore, having assets entered on rows in spreadsheets means that they are in horizontal format.
The layout of Figure 6 allows us to view the various hierarchies associated with an asset without forcing parent / child relationships that cannot apply to multiple assets.Let us explore this approach in greater detail: • Business, location, system and asset are all separate hierarchies; • Company and business unit are part of the business hierarchy; • Site, building and floor are part of the location hierarchy; • System and subsystem form part of the system hierarchy; • Parent asset and asset are part of asset hierarchy; The fundamental outcome of this exercise is the decoupling of the various hierarchies.This implies that sites can serve multiple business units and systems can be domiciled on any floor.More importantly, reporting ability is greatly enhanced, thereby allowing for much improved filtering of asset data.The final point to note is that the solution is promoted not to dismiss the approach of published standards and guidelines but instead to augment them.Asset hierarchies for multiple assets While Figure 6 separated the various hierarchies and converted the layout from vertical to horizontal, the next challenge to address is how to deliver the solution for multiple assets.Figure 7 illustrates, through a practical application, how the solution provides structure for multiple assets.To illustrate this using Figure 7, the sample asset data set that was presented in Figure 4 is converted from a vertical to horizontal format, including the inclusion of an additional data set to help illustrate the solution.The various hierarchies from Figure 6 are overlaid on the sample asset data set.The SS site can now serve multiple business units (i.e., AA and BB) and HVAC can now exist on the second and third floors.Asset attributes are added for illustrative purposes.Normally these are stored within the AIMS asset form.A limitless amount of assets, with different hierarchical values, can be added as additional rows in a spreadsheet or AIMS table.The benefits of the proposed solution are industry agnostic.For example, a company has a fleet of offshore drilling units, with the fleet containing identical equipment such as condensate pump sets.By using the aforementioned approach, the condensate pump sets across the drilling units can be easily grouped for analysis, despite their different locations.

Virtual assets and static attributes
The concept of virtual assets is essential to help connect the various elements of an asset register.This is usually achieves by grouping assets at a collective level based on their functional outputs, which is vital for assigning relevant maintenance activities as well as reporting purposes.Examples of virtual assets are systems and subsystems, whereby HVAC and air conditioning respectively represent common examples of a typical system and its associated subsystem.In addition to hierarchy details, there are the other asset attributes to consider including manufacturer, model number, serial number, year of installation, asset status and criticality ranking.These need to be captured in the relevant fields of the asset form.

AIMS contribution
The earlier parts of this study already highlighted the importance of appropriate data handover to operations at the end of projects, including the asset register being incorporated into the AIMS. 3 The study will further explore what the AIMS needs to provide in terms of functionality, so as to adequately enable an asset data solution.The successful delivery of a solution is heavily reliant on the availability of a configurable AIMS.In terms of software-as-a-service (SaaS) applications, configurability has been described as a key foundation stone that allows a unique user experience to each customer. 49t is beneficial if the AIMS utilizes a relational database which would entail that such are constructed from tables of data elements (also referred to as relations).The application of a relational database implies that all types of asset data manipulation are possible. 20An example of this in practice is work order and asset tables sharing fields called "Site", which allows both tables to be interrogated based on the entered "Site" value.Having a hierarchical tree in each AIMS table is desirable as it allows swift drill down through the various hierarchies.It can also be considered a bonus if the hierarchical tree is configurable since multifield search capability in the tables allows multiple filters to be applied at once.Editable list view for columns in the various tables caters for analysis of asset data that can be adjusted when required.Additionally, advanced reporting functionality is key to enabling efficient access to the pertinent asset data.Another requirement is that it should be possible to report from all fields in the asset form.

Scalability measures
According to earlier findings by Tretten et al., 41 the likelihood of errors increases exponentially when there is information overload, incorrect information, incorrectly grouped or located information or various combinations of these factors.Of particular interest here is the reference to incorrectly grouped or wrongly located information since these can relate to scalability and will have significant impacts on the deployment of AIMS.However, accurate applications of CfM approach to asset data structuring is a possible remedy to such concerns.In an earlier study by Steenstrup, 50 it was revealed that the priorities of leading EAMS and CMMS service providers has been scalability, so as to accommodate the incessant growth of both users and assets.It can therefore be inferred that addressing system capabilities has been ongoing considerations for most AIMS vendors.The remainder of this subsection will further attempt to explain how scalability can be delivered through a combination of data structuring and AIMS functionality.

Functional location
Although the direct mentioning of AIMS vendors has been resisted in the article, there is one product of note that is hard to exclude.In terms of grouping related assets together, the SAP® Plant Maintenance (SAP PM) system offers a novel solution known as a functional location.Functional location, often abbreviated to FLOC, has been defined as "an organizational unit that is used to maintain the objects of a company as per the functional area, process-related or spatial criteria". 51For example, a steam boiler package appointed as a FLOC is allocated an asset ID.The components of the package such as the boiler shell, burner, header valve, safety valve, and blow down valve are pieces of equipment that exist as assets within the FLOC and each will have their individual IDs.The advantages of this approach is that if any combination of equipment is replaced in the steam boiler package, the FLOC remains as-is.The only time the FLOC will be retired is if the steam boiler package is no longer required.In a sense, the FLOC could be described as the equivalent of a virtual asset.This approach delivers scalability by reducing the changes required at a FLOC level.Any amount of equipment can be replaced at the various FLOCS in the asset register without the associated FLOCS being replaced.Asset history is perfectly preserved as the record of equipment that was replaced is retained with their statuses being changed from, for example, active to disposed.However, the downside of this approach is that not all AIMS are configured to accommodate the FLOC concept, which would alter the levels of experience by different clients, which could pose issues when a company decides to migrate from AIMS with FLOC functionality such as SAP PM to another AIMS where such functions are unavailable.

Selecting systems and subsystems for assets
A common cause of confusion when assembling an asset register is the selection and assignment of systems and/or subsystems.There can be a temptation to focus on just how an asset performs its function as opposed to what the function truly is.Let us consider an example of a chiller used for fan coil units.The chiller uses water, electricity and refrigerant but its function is to supply chilled water to cool air.Therefore, it is part of the HVAC system and air conditioning subsystem.Getting this aspect of an AIMS deployment right is essential to deliver scalability and should there be instances of wrongful allocation of systems or subsystems, the asset register will become tangled and inconsistent with engineering best practice.

Asset identification and other attributes
There are various ways for setting up asset registers and AIMS.It is therefore common practice for organizations to select an approach that works for their particular context.However, it is crucial to remain consistent to the selected approach as this will help ensure data integrity which is key to delivering scalability.In terms of assigning asset IDs, the provisions of Landsnet KKS Handbook, 52 an open source guide for asset codification has proven to be valuable and reliable.Its guidelines have been implemented across prominent and safety-critical sectors including nuclear; oil and gas; and power.Experience has also shown that other simpler approaches have provided comparable.It is crucial to note that when there is uncertainty regarding the data to be entered into fields or when it is difficult to obtain certain classes of data, there can be a tendency to enter a "N/A" value.This value should only be entered if the field is truly Not Applicable to an asset.
If widespread usage of this value is observed for particular fields, a question must be asked as to why the affected fields exist in the asset form.

Random asset IDs
Sections 3.2 and 3.3 already featured the main limitations concerning smart IDs.The smart ID approach, mentioned in Section 3.3, is more appropriate for the aforementioned FLOC concept.Should asset replacement occur, IRL/CRK/UTIL/BLR2 can remain and the equipment form that is attached to it can be changed to reflect the asset replacement.However, this would also hold true if the FLOC had a "nonsmart" or random asset ID.The concept of a random asset ID works on the basis that there is no intelligence in the asset ID with a random value used instead.The value can be alphabetic, numeric or alphanumeric, which can be generated by the AIMS or by the person responsible for data entry.The random ID offers the potential to record an unlimited amount of assets without having to apply any onerous decision-making regarding the ID.For visual identification, using the above example, the equipment can have a simple descriptive label attached such as "Boiler 2".Hence, the application of random asset IDs present a more scalable solution than using smart IDs.

Asset register granularity
A company must decide the lowest level of detail when building an asset register.This will vary depending on both a company's requirements and the resources available to perform the task.Once the lowest level of detail is decided, then anything below that becomes a component and is an inventory item.Coming to this decision on granularity is a key factor in delivering scalability which is also dependent on the level of consistency.Consideration must be given to the value attained from data gathering and in this respect, there is always a trade-off between effort invested in the data collection process and the benefits to be realized in relation to the particular requirements to define individual equipment class. 20t is often recommended to record assets down to the level of line replaceable unit (LRU).The Federal Aviation Administration (FAA) 53 defines LRU as the "lowest unit to be replaced within a system during site maintenance".This is the equivalent of a maintainable item, as illustrated in Figure 2, and which López-Campos et al. 54 describe as the most basic piece of equipment on which maintenance is performed.Using a pump set as an example, the pump and the motor would be listed as assets.However, the mechanical seal, impeller and cooling fan should be listed as components.In practice, during maintenance the pump or motor would be replaced but not the components listed above.A phased option could be considered during the creation of an asset register.The company may decide to initially collect high level information and then return later to collect the lower level information.The high level information could go as far as the subsystems for example, air conditioning.This should be sufficient for the assigning of routine maintenance activities, although the phased approach is a possible option if restricted by time and other resources.

CONCLUDING REMARKS
An asset is often described as anything that possesses value while asset management is the harmonization of all endeavors in the technical, administrative and managerial spheres to ensure that such assets are retained in a state of value-creation throughout their life cycles.The ability of any organization to sustainably achieve the prescriptions of asset management hinges on the quality and quantity of asset-related information it holds within its asset register.A company cannot understand its asset base unless structure is applied to the related data.The most fundamental asset data resides in the asset register and it is this that provides the building blocks of a successfully deployed AIMS.In that regard, the framework proposed here can simplify as well as ease the realization of such outcomes.Although there are some evidence of published standards that provide guidelines for the compilation of asset registers; particularly in the specific areas of hierarchies, naming conventions and asset attributes.However, none of such standards is all-encompassing, thereby requiring the consultation of incredibly large bodies of knowledge which in turn makes the process complex, error-prone and laborious, especially when dealing with large industrial plants.Rather than completely reinvent the wheel, the approach described here sits at a more granular level and provides guidance that adequately complements the prescriptions of already published standards so as to reduce the steepness of the learning curve.For instance, standards such as BS ISO 1007 and ISO 14224 already provide overarching principles for presenting a solution for hierarchies and static attributes.The current study however describes a novel approach that is embodied within a single document for addressing fundamental challenges that have continued to impede the optimization of AIMS.By combining the prescriptions of this article with those of already functional standards such as BS ISO 1007 and ISO 14224, it is envisaged that this will ease the delivery of a comprehensive and optimized solution for an asset register.
In order to ascertain the proficiency of the described solution, a generic sample of static asset data was assembled using CfM principles.The solutions presented here are the results of a radical approach in synthesizing processes from the maintenance engineering, quality management and computer science disciplines.Bringing the solutions to fruition ensures data is structured correctly and placed in an AIMS that is set up to perform.The ultimate value in the implementation of the proposed solutions involves the easing of asset data interrogation which provides input to decision making.Easing of the data interrogation workload will provide time and finance savings for companies that choose to adopt these measures.
Among recommended future works would be a thorough assessment of how to formally embed CfM practices into routine asset management practices.There is also scope to insert further guidance into the published standards and guidelines that feature structuring of asset registers, including considerations for taxonomy to classify the design of asset registers, based on different prioritized criteria.Getting this aspect of an AIMS deployment right, provides a solid bedrock upon which AIMS is built.A fully realized AIMS solution will in turn further promote delivery of an asset data solution.The importance of embedding scalability into the solution was also highlighted, which will ease the ability of organizations to incorporate new assets and asset-related information in the future.
Figure 3 also adopts the classification approach in Figure 2 but in the context of an FM asset.The following points explain how the hierarchy in Figure 3 is broken up into different data groups.Groups (1) & (2) represent business data; Groups (3), (4), & (5) represent location data; Groups (6) & (7) represent system data; and Groups (8) & (

F I G U R E 3
Taxonomy classification with taxonomic levels (FM asset example) F I G U R E 4 Taxonomy classification with taxonomic levels (using sample data set)

F I G U R E 5
Solution delivery model FM F I G U R E 6 Revised taxonomy classification with taxonomic levels (FM asset example) 4.1.1

Standard/guideline Brief description Hierarchies Naming convention Static attributes Comments on guidance limitations
featured in this standard is structured according to COBie guidelines.This lends a visually vertical structure which has the same limitations as previously mentioned regarding ISO 14224.Also in common with ISO 14224 is it difficult to identify this standard as having useful information in relation to asset data as it is titled "Guide for life cycle costing of maintenance during the in use phases of buildings".
Note: YES = substantive guidance is provided (not just examples of field values but information on how to populate fields).NO = substantive guidance is not provided.25778196, 2022, 6, Downloaded from https://onlinelibrary.wiley.com/doi/10.1002/eng2.12493 by University Of Portsmouth, Wiley Online Library on [07/11/2022].See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions)on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License 25778196, 2022, 6, Downloaded from https://onlinelibrary.wiley.com/doi/10.1002/eng2.12493 by University Of Portsmouth, Wiley Online Library on [07/11/2022].See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions)on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License Taxonomy classification with taxonomic levels (ISO 14224) 25778196, 2022, 6, Downloaded from https://onlinelibrary.wiley.com/doi/10.1002/eng2.12493 by University Of Portsmouth, Wiley Online Library on [07/11/2022].See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions)on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License