Building Information Modeling (BIM) has largely replaced CAD as the software platform of choice for building design and construction, and facility managers understandably want to leverage the spatial and equipment information in BIMs for high-performance and sustainable building operations and maintenance. However, extracting information from BIMs for import into FM software systems or synchronizing BIMs with FM software for “real time” access to model data remains more dream than reality.
Has the promise of BIM for life-cycle facility management been overhyped? Yes and no. BIM technology is capable of meeting facility managers’ facility information needs. With more information, it is easier to create action items and prioritize sustainability goals. But the business practices of design and construction do not yet harness BIM’s information management capabilities. Facility managers — with only an arm’s-length relationship to BIM technology — are often stymied in recommending improvements in facility information deliverables. They remain on the receiving end of the “data dump” at project closeout, now delivered in an unmanageable array of electronic data file formats.
Simply put, facility managers do not receive complete, structured asset data from BIMs because they cannot articulate their asset data requirements in the language of BIM. Meanwhile, capital projects managers and design and construction teams — lacking detailed, prescriptive requirements for asset data delivery — can only guess at the scope, syntax, and format of the information that facility managers require. Advancements in technology can’t fix this problem; business practices need to catch up with the technology.
Facility managers must acquire the ability to express their facility information requirements in the language of BIM and confirm that their information deliverable requirements are being met. A systematic process of shifting BIM to facility management remedies these root causes of the information exchange problem. A BIM to FM process builds upon these familiar contract requirements for BIM-based projects to optimize BIM for operations and maintenance. The elements of the process are straightforward: specify, compile, validate, deliver, and apply. The first step, specify, is foundational; the success or failure of the entire process depends on it.
Creating a facility information specification
The product of the first step in the process is a Facility Information Specification (FIS): a detailed, prescriptive specification of the precise information needed by facility managers to operate and maintain a facility throughout its useful life. An FIS consists of four parts: Scope; Naming Conventions; Electronic Data Format Requirements; Document Format, Content, and Naming Requirements.
Preparing an FIS requires time and effort, but once an FIS has been created for one project, it is easily adapted for future projects with minimal effort. The facility management team prepares it, then the Capital Projects team integrates it into the RFPs for design services and into construction specifications as part of the required submittals. The design and delivery team is thus conditioned to the facility information needs of facility management even prior to their selection for the project.
The scope of a Facility Information Specification consists of two parts: 1.) a list of the building elements (floors, rooms/spaces, zones/wings) and asset types (fixed or moveable equipment) that you want to track in your FM/O&M software for space management and operations and maintenance; and 2.) the specific pieces of information (data fields) to collect for each building element or asset.
A handy guide for deciding what facility information to collect is the Construction-to-Operations Building Information Exchange (COBie), a constituent element of the National BIM Standard – US (NBIMS-US). COBie is designed to facilitate electronic information exchange between software applications, yet its value for contractually defining, in plain English, the required scope of facility information deliverables is often overlooked. COBie can serve as a checklist for defining the scope of information to be included in an FIS whether or not a facility management team requires electronic data to be submitted in a COBie-compliant format. Prescriptive, proprietary facility information requirements for every building element or asset type can be documented in a simple table, schedule, or spreadsheet, or by using the COBie Handover Template.
Asset types: Building elements and equipment
What types of building elements (fire doors, smoke vents, light fixtures) and equipment (air handlers, pumps, valves) should be tracked? The types of assets currently tracked in an FM software database for existing facilities is a good starting point. However, if a proposed new facility differs substantially from any existing facilities, that asset type list may be incomplete. Before design has begun on a new building, it is easy for facility management teams to overlook building elements or assets that may later be regarded as critical. Fortunately, a comprehensive list of building elements and equipment is freely available: OmniClass Table 23 — Products. OmniClass is developed and maintained by the Construction Specification Institute and is a constituent element of both COBie and NBIMS-US.
Both the OmniClass Number as well as the OmniClass Title (description) should be included in an FIS. Both Uniformat and Masterformat are integrated into OmniClass (Tables 21 and 22, respectively) so tracking the OmniClass Number for all asset types will harmonize a proprietary FIS with these industry standards, which are supported by many software applications. If facility information will be required to be delivered in COBie-compliant format, creating a proprietary Asset Type Table from OmniClass Table 23 has the added advantage of correctly populating required data fields in the COBie Asset Type data table. A column containing a unique alphanumeric code (e.g., AHU, PMP, TNK) for each asset type (which corresponds to COBie Type Name) should be added to the proprietary Asset Type Table.
With the list of asset types defined, the data fields required for each asset type (e.g., Manufacturer, Model Number, Serial Number, Installation Date) must be specified. Only the information actually needed for FM/O&M should be specified; the requirements vary by asset type. For critical assets, the model number and serial number may be important. For “commodity” assets (assets that are largely interchangeable and can be purchased from any supplier), the generic information (Asset Type Name, Description, and OmniClass number) may be sufficient.
For each asset type, the documents to be delivered (e.g., drawings, parts lists, owner’s manuals, warranties) must be specified. Document requirements, like data requirements, may vary by asset type. How are documents different from structured data to be submitted in named data fields? Structured data can be imported directly into the facility management database as discrete elements of editable, searchable data records; documents are attached to those records and accessed as needed for space management and operations and management.
Practical Considerations for Using BIM for FM
Establish Uniform Naming Conventions to Best Use BIM for FM
USGBC Perspective: USGBC Works Toward Seamless Integration of Rating Systems
