Operations guide
Software Selection for Facilities, Workplace and Corporate Real Estate
For Facilities, workplace, CRE, IT, procurement and operations leaders
Evidence checked · Guide updated
Built-environment technology decisions span buildings, asset data, service teams, enterprise systems and operational technology. A defensible evaluation starts with the outcomes and operating boundary, then tests data, integration, migration, resilience, implementation and lifecycle evidence against the sites that will actually use the system.
This guide explains buyer questions and evidence expectations. It does not certify a product, declare a vendor compliant or treat protocol support as proof of end-to-end interoperability. Jurisdiction, estate risk and deployment context can change which requirements are material.
Define the decision boundary before the shortlist
IWMS, CAFM, CMMS, EAM, workplace experience, building management and digital-twin products overlap but are not interchangeable. State the outcomes, sites, asset classes, workflows, users and systems of record in scope. Keep genuinely different alternatives separate where one aggregate score would hide a material gap.
Turn operating reality into acceptance evidence
Model planned and reactive maintenance, space and lease processes, contractor access, compliance records, mobile work, reporting and local exceptions. For each critical requirement, define the evidence expected: configured demonstration, reference architecture, contract commitment, test result or production reference. A vendor response is evidence of an assertion, not independent proof of the outcome.
Prove interoperability at version and workflow level
Ask for the exact standards, API versions, objects, fields and directions supported. BACnet can provide a common building-automation protocol, while IFC provides an open data model for built assets; neither label by itself proves semantic completeness, bidirectional workflow support or interoperability with a buyer's implementation. Test identity, mapping, error handling, retry, latency and ownership across every material interface.
Treat migration as a controlled workstream
Inventory asset hierarchies, identifiers, locations, documents, maintenance history, classifications and retention needs before pricing migration. Require trial loads, exception reports, reconciliation thresholds, cutover sequencing, rollback and named ownership for data cleansing. Preserve the source-to-target mapping so later teams can distinguish migrated history from newly created records.
Test operational-technology resilience and security
NIST SP 800-82 Rev. 3 is final guidance for operational technology, including building automation, physical access control and environmental monitoring. The September 2026 Rev. 4 material is an initial public draft, not final guidance. Use these sources to frame asset inventory, segmentation, remote access, monitoring, recovery and fail-safe questions, then apply accountable organisation-specific security and safety review.
Price implementation, support and lifecycle
Compare site discovery, configuration, commissioning, integration, devices, training, change, support and internal resource costs as well as licences. Record lifecycle commitments for release cadence, supported deployment models, API deprecation, export rights, service ownership, escalation, end-of-support notice and an exit plan. Test how critical workflows continue during network, cloud, device or supplier failure.
Separate generally available capability from roadmap
For each material capability, record whether it is generally available, beta, announced or retired, with the applicable edition, region and deployment model. Roadmap statements should remain attributable vendor assertions unless contractually committed and independently evidenced. Recheck status before approval and again at implementation gates.
Questions buyers ask
Practical questions, bounded answers.
Can we compare IWMS, CAFM, CMMS and EAM options in one decision?
Yes when the decision boundary and requirements make the alternatives genuinely comparable. Keep category differences visible and do not let an overall score conceal a missing maintenance, property, workplace or asset-management capability.
Which systems should remain the source of truth?
Name the authoritative system for people, identity, assets, locations, leases, finance, work orders and documents. Then define which system may create, update or only read each record, including conflict and reconciliation rules.
Does support for BACnet or IFC prove interoperability?
No. Confirm the applicable version, profile or model view and test the required objects, properties, mappings and workflows. Protocol or format support is a useful starting claim, not proof that two configured systems will exchange the right data reliably.
How should we test migration quality?
Use representative data, including poor-quality and exceptional records, in at least one trial migration. Agree reconciliation measures, error ownership, acceptance thresholds and rollback before cutover.
What should work during an outage?
Identify safety-critical and operationally critical workflows, then test local control, cached data, manual procedures, queueing, recovery and reconciliation for the relevant network, cloud, device and integration failure modes.
How do we assess implementation and support?
Ask who owns discovery, configuration, integrations, commissioning, training, defects and upgrades at each site. Validate resource assumptions, escalation paths, service windows, release dependencies and evidence from comparable operating contexts.
What lifecycle evidence belongs in the contract?
Material API, export, support, security-notification, deprecation, end-of-life, transition-assistance and data-return commitments should be specific enough to verify. Roadmap promises that remain non-contractual should stay labelled as vendor assertions.
How do we use standards without overstating compliance?
Apply the version, scope and status that fit the decision. Distinguish final standards from drafts, and use them to define questions and test evidence. A reference to a standard does not by itself certify the product or make it suitable for a particular estate.
Evidence and standards context
Sources, status and scope.
Source status describes the cited material, not a vendor or product certification. Confirm the applicable version, jurisdiction and implementation context for each decision.
US National Institute of Standards and Technology · Final guidance · September 2023
Operational technology security guidance covering building automation, physical access control and environmental monitoring among other OT systems.
US National Institute of Standards and Technology · Initial public draft · 21 September 2026
Draft update with expanded building-automation coverage. It is not final guidance; NIST lists comments as due by 30 November 2026.
ASHRAE · Published, continuously maintained standard family · Current source checked 7 October 2026
Vendor-independent building-automation communications standard, also published as ISO 16484-5. Buyer testing is still required for the selected devices, objects and workflows.
buildingSMART International · Final ISO standard · IFC 4.3.2.0; ISO 16739-1:2024
Open built-asset data model. Software support is version- and model-view-specific; the next major IFC version remains under development.
International Organization for Standardization · Published standard; revision in development · 2018; amended 2024
Facility-management system requirements. It is not a software interoperability standard or proof that a product is suitable for a buyer's operating context.
Need to apply this to a real decision?
Move from general guidance to a governed decision context.
PROVE TDI structures the requirements, evidence, alternatives, uncertainty and accountable conclusion for a specific enterprise technology decision.