For many organizations, the completion of a construction project marks the beginning of an equally important phase: operating the building efficiently over the next 20, 30 or even 50 years.
By that point, a considerable amount of digital information has already been created. Owners may receive native BIM models, IFC files, CAD drawings, asset registers, operating manuals, spreadsheets and technical documentation. On paper, it can look as though everything required for successful building operation is already available.
Assets may still need to be identified, documents assigned to the relevant equipment, naming conventions for rooms and technical assets standardized, and missing information completed. A simple question such as “which equipment is installed here, and where is its maintenance documentation” can require information from several sources.
The problem is therefore rarely a lack of data. It is that information created for planning and construction does not automatically have the structure required for long term operation.
So which data formats and structures are typically transferred into operations, and what actually helps once the building is in use?
Which Building Data Models Are Used at Handover?
The answer is not as simple as choosing between IFC, Revit, CAD or another format. Each serves a different purpose throughout the building lifecycle.
A typical handover can include:
- native authoring models, such as Revit files;
- IFC files for open data exchange
- DWG or other CAD drawings
- COBie datasets
- Asset registers, sometimes maintained in spreadsheets
- PDF documentation such as operating manuals, certificates and inspection reports
- Metadata describing spaces, building components and technical assets
- Information already maintained in CAFM, CMMS, ERP or other operational systems
Each source represents a different aspect of the building.
A native Revit model retains the structure and detail of its authoring environment, while IFC provides a standardized structure for exchanging selected model information independently of the original software.
CAD (Computer Aided Design) drawings, commonly provided as DWG files, remain particularly relevant across existing building portfolios. They provide floor plans and other graphical information, but generally do not contain the same object based structure as a BIM model.
Asset data and metadata provide another layer, including equipment identifiers, classifications, technical properties, manufacturer information and spatial assignments. These may originate in a model or be maintained separately in asset registers, databases or spreadsheets. COBie (Construction Operations Building information exchange) is a standardized schema for handing over structured facility and asset information. It can support operational processes without requiring the complete graphical model, but it does not replace that model or cover every type of operational information.
No single source therefore has to contain everything. What matters is knowing what information each source provides and whether that information can be used in the operational processes that follow.
More Data Does Not Mean Better Operational Data
A detailed model can contain thousands of objects and properties. But not all of them are equally relevant once the building enters operation.
For many operational tasks, the exact geometry of every component is less important than questions such as:
- Where is the asset?
- What exactly is installed?
- Which system does it belong to?
- Who manufactured it?
- When does it need to be maintained?
- Which documents belong to it?
Consider an air handling unit. Its model may contain numerous design parameters that were important during planning and construction. For operation, the facility team may primarily need its unique asset ID, exact location, manufacturer and model, relevant technical properties, maintenance requirements and associated documentation.
Asset identifiers should be aligned across the relevant model, documentation and operational system. Where identifiers are missing or inconsistent, they may need to be reconciled and mapped between sources. Its location should connect it to the correct building, floor and room, while its technical relationships may place it within a particular system or subsystem. Structures such as building → floor → room → asset or technical system → subsystem → component make these relationships easier to navigate.
The same principle applies beyond maintenance. Space management may depend more on room numbers, areas, usage and occupancy, while portfolio level Corporate Real Estate Management (CREM) may require information about buildings, spaces, areas, utilization and other real estate characteristics.
What should ultimately be transferred depends on the processes the information needs to support. Detailed models and geometry are therefore not unnecessary. Visual and spatial information can be extremely useful when locating equipment or understanding how objects relate to their surroundings. At the same time, transferring every available model element and parameter adds little value when much of that detail has no role in the processes that follow.
A useful operational dataset combines the right level of geometry, structured object information, attributes and relationships for its intended purpose. These elements can come from different sources, depending on the information required.
How Do Different Data Sources Come Together in Operations?
The different information sources do not disappear when construction ends. A Revit model may remain relevant for future modifications. IFC can be used when information needs to be moved between systems. CAD drawings may remain the most practical reference for certain areas, while structured asset information feeds operational applications.
The practical question is therefore how to work with these sources without forcing everything into a single format.
For anyone working with building information, spatial context can provide the link between them.
A maintenance technician, property manager or other building professional does not necessarily need to know which file originally contained the information. They need to find the relevant asset or space, understand what it is and access the information they need.
For example, selecting a pump in its location could provide access to its technical data, maintenance information and associated documentation, regardless of where those individual pieces of information originated.
This is the principle behind speedikon VIP, which brings information from different sources into a shared spatial context. The original representations can remain available while the information is related to the physical building and the assets within it.
The goal is therefore not to create one universal data format. It is to make the right information accessible, understandable and useful in the context in which it is needed.
The right data model depends on the processes it needs to support. If you are reviewing how building information is transferred into operations, we would be happy to share our experience.
