You already paid for the knowledge in your building. The problem is getting it back when you need it.
You’ve spent weeks preparing for a critical 20-person client meeting. The strategy is set, the slides are polished, and the team is ready. But two hours in, the conference room feels like a sauna.
The frustrating part: you had already paid to know this. The building had the warning signs days ago.
Complaints had been logged, work orders filed, and operational signals were already there. The knowledge existed, but when you needed to use it, you couldn’t get it back in one usable answer. It was scattered across systems, with no connected context to act on.
And sometimes the stakes are much higher. A rooftop air-handling unit may be failing while the zones below include exam rooms, critical workspaces, or temperature-sensitive storage.
Your question is not technical:
What is affected? How serious is it? And what do we need to do now?
Image Source: ONUMA Process Description
Your Building Has the Data. Can Your Team Use It Together?
Your building knowledge is an asset you have already invested in. You paid architects, engineers, contractors, controls vendors, operators, maintenance teams, and others to create it over years. It describes your rooms, equipment, systems, conditions, work history, and how those things relate.
But unlike most assets, you often can’t withdraw its value when you need it.
The information is scattered across different systems.
The room may be in one system, equipment in another, controls somewhere else, work orders in a separate application, and supplier information buried in PDFs or proprietary portals. Names and IDs don’t always match, and relationships known by one system may be missing from another.
When that happens, your people become the integration layer, searching, calling, comparing, interpreting, and sometimes re-entering connections by hand.
Then a new vendor arrives promising one application or a “single pane of glass.” But moving disconnected information into a new application can simply create a newer locked silo.
Your building data is an asset. Don’t deposit it in a wildcat bank.
Your building data shouldn’t raise the same questions. Know who created it, what it means, and make sure you can take it with you.
Who the heck is Adrian, and why should I trust him with my money?
We used to have this problem with money: value depended on who issued it and who trusted it. Building knowledge still works this way too often. Your building knowledge should not be proprietary currency. Image: Erie & Kalamazoo Rail Road Bank $5 note, 1853. Wikimedia Commons, public domain.
Your requirement should be different: consultants, vendors, and systems should work from the same building information about rooms, assets, identities, and relationships, and contribute what they know back into that shared context.
The goal is not one application that knows everything. It is connected building knowledge that survives the handoffs.
The knowledge exists. Your ability to retrieve, connect, trust, and reuse it usually does not.
You Already Paid for the Answer. Can Your Building Give It Back?
You should not need to know which application has the answer or manually connect information held by designers, controls, operations, maintenance, and suppliers. The same room and asset information, their identities, relationships, and history, should carry forward from discovery to action.
Here is what that looks like:
Image Source: ONUMA Process Description
| Your need | What your building should know | Team action | What you should require | Proof |
| Host the meeting | Best room, availability, capacity, AV, comfort, known issues | Select the room and check known risks | Room, schedule, systems, and work history share the same context | Right room selected with risks visible |
| Room is too warm | What serves the room, current conditions, complaints, work history | Diagnose the likely cause | Room, equipment, live conditions, and maintenance history are connected | Cause traced from room to system |
| Fix it before next week | What can be adjusted, repaired, replaced, or worked around | Choose the response and prepare the scope | Existing identities, relationships, and history carry into the work | Clear action based on trusted context |
| Replace equipment | Exact asset, location, what it serves, connections, required performance | Install and identify the replacement | New equipment inherits the existing building context instead of starting over | Physical asset and digital record agree |
| Commission and verify | Is it installed correctly, operating correctly, and reporting correctly? | Test, verify, and close the work | Performance and delivered information are checked against the requirement | Room works, data works, owner accepts |
The Hard Part Isn’t More Data. It’s Shared Meaning.
The hard part happens underneath: your teams and systems must agree that they are talking about the same rooms, equipment, identities, relationships, and operational signals.
The goal is simple: information about the same room, equipment, and relationships should mean the same thing wherever it appears.
At the PAE Living Building in Portland, Oregon, ONUMA provides spatial and asset context, BIMgenie connects work orders and field activity, and SkyCentrics provides live building-system data.
The products are not the point. The requirement is that independently developed tools work from, and contribute to, the same building context.
Suppose equipment serving your room needs to be replaced. Instead of reconstructing what exists from drawings, PDFs, schedules, and phone calls, the contractor receives a structured description of the asset, what it serves, and what the replacement must deliver.
Your building should be able to say:
- This is what exists.
- This is what you are changing.
- This is how it connects.
- This is what we expect back.
As the replacement comes online, its identity, connections, and expected operating signals are checked. Missing information or mismatched IDs can be flagged for review.
The physical installation and the information installation happen together: installed, identified, connected, and confirmed.
Image Source: ONUMA Process Description
Become the Building: Bring Your Problem, Your Team, and Your Tools
This same challenge is part of Mission 1 in the Become the Building BIMStorm.
Bring a real operating problem, the people who support it, and the tools they use, from operators and engineers to controls, work orders, digital twins, and AI.
The goal is not one perfect platform. It is to see whether your team and tools can work from the same building context from discovery to action.
Can they agree on the information describing the room, equipment, identities, and relationships, and pass useful context to the next team without reconstructing the building?
Bring the problem. Bring the team. Bring the tools. See whether the context survives the handoffs.
Try Mission 1: Keep People Comfortable →
Solve It Once. Don’t Reinvent It Building by Building.
What takes time is creating the pattern once. By working through identities, relationships, operational connections, requirements, and commissioning in a real building, your next installation, and your next building, should be faster to connect.
Applications, consultants, and vendors may change. You should not have to keep paying to reconstruct knowledge you already own.
That starts with you setting the requirement: use the same building context, contribute back to it, and carry it through operations, maintenance, replacement, and commissioning.
You should still be able to ask the simplest question:
“Is the room ready for our meeting?”
Tomorrow it may be a failing rooftop unit, a critical space at risk, or another business problem. The question changes. Your need does not:
Can I trust what my building is telling me in time to act?
The technology can support that. But you have to require it.
And that raises the next question for every consultant, integrator, software company, and technology provider you hire:
If you own your building’s knowledge, can you replace them without losing it?
Next Post: We Asked the Building: What Can Owners Actually Trust?
Automated Japanese Translation:
会議は来週。あなたの建物は、すでにあなたの知らないことを知っている。
あなたは、建物の中にある「知識」にすでにお金を払っています。問題は、それが必要なときに取り出せるかどうかです。
重要な20人規模のクライアント会議に向けて、何週間も準備してきました。戦略は決まり、スライドも仕上がり、チームの準備も万全です。ところが会議が始まって2時間もすると、会議室はまるでサウナのように暑くなってきました。
腹立たしいのは、この問題を知るための情報には、すでにお金を払っていたということです。建物には数日前から、その兆候が出ていました。
苦情はすでに記録され、作業指示も発行され、運用データにも異常の兆候が現れていました。
必要な知識は存在していたのに、いざ必要になったとき、それをひとつの使える答えとして取り出すことができなかったのです。
情報は複数のシステムに分散し、行動につなげるためのコンテキストが結び付いていませんでした。
そして場合によっては、事態はもっと深刻です。屋上の空調機が故障しかけていて、その下に診察室、重要な作業スペース、あるいは温度管理が必要な保管室があるかもしれません。
あなたが知りたいのは技術的なことではありません。
どこに影響が出るのか？ どの程度深刻なのか？ そして、今すぐ何をすべきなのか？
画像出典：ONUMA Process Description
あなたの建物にはデータがある。では、チーム全体で使えるだろうか？
建物に蓄積された知識は、あなたがすでに投資してきた資産です。
建築家、エンジニア、施工者、制御ベンダー、運用担当者、保守チームなどに、何年にもわたり対価を支払いながら作ってきたものです。
そこには、部屋、設備、システム、状態、作業履歴、そしてそれらがどのようにつながっているかという情報があります。
しかし多くの資産と違って、必要なときにその価値を引き出せないことがよくあります。
情報が複数のシステムに分散しているからです。
部屋情報はあるシステム、設備情報は別のシステム、制御データはまた別の場所、作業指示は別アプリケーション、メーカー情報はPDFや独自のポータルに埋もれているかもしれません。
名称やIDが一致しないこともあり、あるシステムでは分かっている関係性が、別のシステムでは欠落していることもあります。
そうなると、人間そのものが「統合レイヤー」になります。検索し、電話をし、情報を比較し、解釈し、ときには手作業でもう一度関係性を入力し直します。
そこに新しいベンダーが現れ、「すべてを一つのアプリに」「Single Pane of Glassを実現します」と提案します。
しかし、バラバラの情報を新しいアプリケーションに移しただけでは、単に新しい閉鎖型サイロを作ることにもなりかねません。
建物データはあなたの資産です。それを“ワイルドキャット銀行”に預けてはいけません。
建物データについても、同じことを問うべきです。
誰が作ったのか。何を意味しているのか。そして、必要になれば自分たちで持ち出せるのか。
「エイドリアンって一体誰なんだ？」
そして、なぜ私は彼に自分のお金を預けても大丈夫だと思えるのでしょうか？
かつてお金にも同じ問題がありました。価値は、誰が発行したのか、そして誰がそれを信用したのかによって決まっていました。建物の知識も、いまだに同じような状態にあります。あなたの建物の知識を「独自通貨」にしてはいけません。画像：Erie & Kalamazoo Rail Road Bank 5ドル紙幣、1853年。Wikimedia Commons、パブリックドメイン。
あなたが求めるべき要件は、別のものです。
コンサルタント、ベンダー、各種システムは、部屋、資産、ID、関係性についての同じ建物情報を使って仕事をし、自分たちが得た知識も、その共有コンテキストに戻していくべきです。
目指すべきなのは、すべてを知っている一つのアプリケーションではありません。
引き渡しや担当変更を越えて生き残る、つながった建物知識です。
知識そのものは存在しています。多くの場合、欠けているのは、それを取り出し、つなぎ、信頼し、再利用する能力なのです。
答えにはすでにお金を払っている。建物はそれを返してくれるだろうか？
答えがどのアプリケーションに入っているのかを、あなた自身が知っている必要はありません。
設計者、制御システム、運用担当者、保守チーム、サプライヤーが持つ情報を、手作業でつなぎ合わせる必要もないはずです。
同じ部屋、同じ資産、それらのID、関係性、履歴は、問題の発見から対応まで、一貫して引き継がれるべきです。
具体的には、こういうことです。
画像出典：ONUMA Process Description
| あなたのニーズ | 建物が知っているべきこと | チームの行動 | あなたが求めるべきこと | 証明 |
|---|---|---|---|---|
| 会議を開催する | 最適な部屋、空き状況、収容人数、AV、快適性、既知の問題 | 部屋を選び、既知のリスクを確認する | 部屋、スケジュール、設備システム、作業履歴が同じコンテキストを共有する | リスクを把握したうえで適切な部屋を選択できる |
| 部屋が暑すぎる | 何がその部屋を空調しているか、現在の状態、苦情、作業履歴 | 原因を診断する | 部屋、設備、リアルタイム状態、保守履歴がつながっている | 部屋から設備システムまで原因を追跡できる |
| 来週までに直す | 何を調整、修理、交換、または一時対応できるか | 対応方法を選び、作業範囲を準備する | 既存のID、関係性、履歴が作業に引き継がれる | 信頼できるコンテキストに基づいた明確な対応 |
| 設備を交換する | 正確な資産、場所、何をサービスしているか、接続関係、必要性能 | 交換設備を設置し、識別する | 新しい設備がゼロから始めるのではなく、既存の建物コンテキストを継承する | 実物の設備とデジタル記録が一致する |
| コミッショニングと検証 | 正しく設置され、正しく動作し、正しくデータを送っているか | テストし、確認し、作業を完了する | 性能と納品された情報の両方を要件に照らして確認する | 部屋が機能し、データも機能し、オーナーが承認する |
難しいのはデータを増やすことではない。意味を共有することだ。
本当に難しいのは、その下の部分です。
チームやシステム同士が、同じ部屋、同じ設備、同じID、同じ関係性、同じ運用信号について話していると合意できなければなりません。
目標はシンプルです。
同じ部屋、設備、関係性に関する情報は、どこに存在していても同じ意味を持つべきなのです。
オレゴン州ポートランドのPAE Living Buildingでは、ONUMAが空間と資産のコンテキストを提供し、BIMgenieが作業指示や現場作業を結び、SkyCentricsがリアルタイムの建物システムデータを提供しています。
重要なのは製品ではありません。重要なのは、別々に開発されたツールが同じ建物コンテキストを使い、そこに情報を返していけるという要件です。
たとえば、あなたの部屋にサービスしている設備を交換しなければならないとします。
図面、PDF、設備表、電話などを使って、現状をゼロから再構築するのではなく、施工者には、その設備とは何か、何にサービスしているのか、そして交換後に何を実現すべきなのかについて、構造化された情報が渡されます。
あなたの建物は、こう言えるべきです。
- これが現在存在しているものです。
- これを変更しようとしています。
- これが他のものとの接続関係です。
- これを結果として返してください。
交換設備が稼働し始めたら、そのID、接続関係、期待される運用信号を確認します。
不足している情報や一致しないIDがあれば、レビュー対象としてフラグを立てることもできます。
物理設備の設置と、情報の設置を同時に行うのです。設置し、識別し、接続し、確認する。
画像出典：ONUMA Process Description
Become the Building：問題を持ってくる。チームを持ってくる。ツールを持ってくる。
この同じ課題は、Become the Building BIMStormのMission 1でも扱っています。
実際の運用上の問題、その問題を支える人たち、そして彼らが使っているツールを持ち寄ります。
運用担当者、エンジニア、制御システム、作業指示システム、デジタルツイン、AIまで、すべてが対象です。
目標は、一つの完璧なプラットフォームを作ることではありません。
問題を発見してから行動に移すまで、チームやツールが同じ建物コンテキストを使って連携できるかどうかを確かめることです。
部屋、設備、ID、関係性を記述する情報について合意し、建物を毎回ゼロから再構築することなく、そのコンテキストを次のチームへ渡せるでしょうか？
問題を持ってくる。チームを持ってくる。ツールを持ってくる。そして、そのコンテキストが引き渡しを越えて生き残るか確かめる。
Mission 1に挑戦：
人々を快適に保つ →
一度解決したら、建物ごとにやり直さない。
時間がかかるのは、最初にそのパターンを作ることです。
実際の建物を使いながら、ID、関係性、運用接続、要件、コミッショニングを一度整理すれば、次の設備導入、そして次の建物では、もっと速くつなげられるはずです。
アプリケーション、コンサルタント、ベンダーは変わるかもしれません。
しかし、すでにあなたが所有している知識を再構築するために、何度もお金を払う必要はありません。
そのためには、オーナーであるあなた自身が要件を設定する必要があります。
同じ建物コンテキストを使うこと。
そこに新しい知識を返すこと。
そして、運用、保守、交換、コミッショニングを通して、そのコンテキストを維持し続けること。
それでも、あなたが尋ねる質問は、最もシンプルなものでいいはずです。
「会議の準備はできている？」
明日は、屋上設備の故障かもしれません。
重要なスペースが危険にさらされているかもしれません。
あるいは別のビジネス上の問題かもしれません。
質問は変わります。
しかし、あなたが必要としているものは変わりません。
行動するために必要なタイミングで、建物が教えてくれることを信頼できるか？
技術は、それを実現できます。
しかし、それを要求するのはあなたです。
そして、あなたが雇うすべてのコンサルタント、インテグレーター、ソフトウェア会社、テクノロジープロバイダーに対して、次の質問を投げかける必要があります。
建物の知識を本当にあなたが所有しているのなら、その会社を別の会社に替えても、その知識を失わずに済みますか？
