01Data Model, Taxonomy & Asset Hierarchy
Define the data dictionary, asset classes, functional locations, parent-child relationships, statuses, mandatory fields, naming rules and evidence levels.
The structure may follow Group > Entity > Site > Building or Area > System > Asset > Component. It is tailored to the assignment’s purpose and is not presented as a universal model.
02Legacy Data Cleansing & Fieldwork Preparation
Consolidate existing lists, standardise formats, profile fields, detect duplicates and prepare field inventory routes.
Data from the Accounting Fixed Asset Register, ERP, CMMS/EAM, technical lists, drawings, SOV and project records remain identified as separate sources.
03Physical Verification & Asset Tagging
Locate and observe in-scope assets, read nameplates and collect the agreed identifiers, quantities, statuses and evidence.
QR codes, barcodes, RFID or other tagging media are used only where the mandate, environment, security and operating conditions permit.
A tag supports identification. It does not prove legal ownership, accounting recognition or fitness for service.
04Asset Characterisation & Hierarchy
Document the required attributes: function, manufacturer, model, serial number, capacity, location, parent unit and lifecycle status.
Condition remains a first-level visual observation unless further investigations are expressly included. It is not an operational test or a diagnosis of integrity, safety or compliance.
05Reconciliation & Exception Management
Reconcile field reality with the different source systems, preserve historical identifiers and classify discrepancies.
Each match may be one-to-one or require mapping.
- one accounting entry to one physical asset
- one accounting entry to several items of equipment
- several entries to one installation
- a field asset with no identifiable source record
- a source record with no asset located
06Master Asset Register & Data Governance
Produce the structured, reconciled Asset Register for the agreed scope, with quality indicators, import mappings and an exception register.
The assignment also defines responsibilities, controls and update triggers so that the register does not become obsolete after fieldwork.