A building can be handed over with a detailed BIM model and still leave its operations team searching for the right equipment record.
The switchboard is visible in the model. Its approved specification sits in a submittal. The serial number is in a contractor’s spreadsheet. Commissioning results are in a PDF. The maintenance team gives it another ID. Months later, an alarm arrives under a name that matches none of them.
Each record may be correct. The connection between them has failed.
That is the handover problem owners should be asking BIM teams to solve.
One asset, several identities
Consider an electrical switchboard in a hospital. During design, it is a BIM object with a location and performance requirements. During procurement, it becomes a selected product and an order. During construction, it becomes installed equipment with a serial number. After commissioning, it becomes an asset that supports critical services.
An operator needs to move across those records without guessing which item is which. If a fault occurs, they need to know where the switchboard is, what it supplies, which documentation applies, what work has already been done, and who is responsible for the next action.
A model that preserves only its shape and design label cannot answer those questions reliably.
This is why I see asset identity as the real bridge between BIM and operations. The BIM object does not need to remain unchanged forever. Equipment is substituted, moved, repaired and replaced. Its identity and history need to remain traceable through those changes.
A useful industry signal
In September, Eaton announced Workbench 360 as part of its expanded collaboration with Autodesk. Eaton describes it as a way to bring electrical equipment information, engineering expertise and project visibility into workflows involving Revit, Forma and Tandem. The stated aim is to maintain context as a project moves from design through construction into operations. That is an announced product direction; it should not be read as proof that every handover problem has already been solved in practice.
The direction matters because equipment information is created by different parties at different times. Designers know the required function. Manufacturers know the product. Contractors know what was installed. Commissioning teams know what was tested. Operators learn how the asset performs.
No single party holds the complete record at the start. The handover process has to assemble and verify it.
Open approaches such as COBie have addressed the need to deliver usable equipment information alongside geometry for years. buildingSMART’s Asset Operations Handover work extends that focus across building and infrastructure use cases. The existence of an exchange format, however, does not settle which data an owner needs, who checks it, or how it stays current after handover.
Design for the operator’s question
An owner can make the requirement concrete by starting with a question: If this asset fails, what must the team be able to find and decide?
For a critical switchboard, the answer may require five connected records:
- Identity: A stable owner asset ID, linked to design references, product details and the installed serial number.
- Place: Its verified location, including building, floor, room and any useful GIS or campus reference.
- Purpose: The systems and services it supports, including upstream and downstream dependencies.
- Evidence: Approved submittals, installation checks, commissioning results, manuals and later inspections.
- Action: The alarm, work order, responsible team, intervention and verification that the issue was resolved.
These links turn a model element into an operational asset record. They also expose gaps early. If the installed equipment differs from the design selection, the record should show the approved change. If its location changes, the operational location should be updated. If a sensor is connected, the team should verify that its data points refer to the correct physical asset.
Without those checks, a digital twin can display live information while associating it with the wrong piece of equipment.
Make handover a series of checks
Waiting until project closeout to gather asset data puts pressure on teams to reconstruct decisions made months earlier. A more useful approach is to check the record as the asset progresses.
At design approval, confirm which objects require an operational record and what information the owner needs. At product selection, link the approved equipment to the design requirement. At installation, verify location and serial number. At commissioning, attach test results and resolve differences. Before acceptance, test whether the operations team can find the asset and complete a real task using the delivered information.
The test is practical: Can a facilities engineer identify this equipment from an alarm, locate it, see what it supplies, retrieve the correct instructions and record the intervention?
A successful file transfer is only one part of that test. The operator must be able to use the information in their maintenance and response workflow.
Owners also need a rule for what happens next. Assets are replaced. Rooms are repurposed. Control points change. Someone must own updates to the asset record, with a way to retain the previous state and the evidence behind each change. Otherwise, the handover starts becoming stale on its first day.
Where geospatial context adds value
Inside a building, BIM gives the asset a precise design and construction context. Across a campus or infrastructure network, an operator may also need to understand geographic exposure and service dependencies.
A switchboard might serve a hospital wing, depend on an upstream substation, and sit in an area exposed to flooding. A maintenance decision becomes more urgent when those relationships are visible. The same principle applies to pumps, air-handling equipment, utility valves and other assets whose failure affects people or services beyond the room where they sit.
This is a useful role for integrating BIM, GIS, IoT and work management: connect the installed asset to its location, dependencies, observed condition and response history. The value comes from a better decision and a verifiable action, not from placing every data source on one screen.
