你好，這裡是BIMBOX。
今年為了讓更多的朋友把他們的經歷和思考講給大家聽，我們建立了BOX作者群，群成員和投稿的作者一起努力打磨出一篇好內容。實驗一段時間下來，我們覺得效果還不錯，因為大家在群裡是基於一篇文章深入討論，聊的東西就是有邊界的，而不是天馬行空想啥說啥，所以更能凝練一些精華出來。
今天給你捧出來的這篇分享，來自於我們的一位老朋友，上海水石建築規劃設計股份有限公司BIM中心負責人、上海BIM推廣中心專家庫成員，他的名字叫金戈，網名叫鐵馬，是不是很霸氣？
金戈在BIM行業摸爬滾打了十幾年，帶過團隊、做過諮詢、做過平臺研發、參編過上海BIM數據標準，在梅賽德斯奔馳中心項目、廣州地鐵總公司BIM諮詢項目、亞特蘭蒂斯水上樂園項目、北外灘改造等項目都留下了足跡，我們和他在線上和線下也都有過交流，經常討論的一個問題就是：BIM走了這麼多年，下一步數據和信息該往哪裡去？
這次，金戈就專門把他這些年的探索寫成一篇文章，在作者群裡改了三稿才最終分享出來，以下是他的分享。
2008年，我在上海世博會一個項目提供三維設計服務時，第一次聽到別人把三維模型說成了「BIM」。在這之前，我己經從事機電的三維設計多年了，一直不知道如何向別人介紹自己的工作。
2010年時，我第一次參加一個BIM活動，聽到大家在討論模型。我當時就提問：我已經能創建一個很好的模型了，後面需要做什麼呢？難道做個模型就是BIM嗎？當時，在場沒有人能答覆我。以後好多年，這個問題一直困擾著我。從此，我一直在探索一個問題：BIM的終極是什麼？該如何實現它？
2014年，我進入上海一家國企，系統地接觸了各種BIM資料，算是入了BIM的門，尤其是其中的歐美書籍和文獻，讓我受益匪淺。其中以下資料，我個人覺得非常有價值：
《BIM手冊》，寬泛定義了BIM的概念，以及未來發展。其中對未來發展的預判，放到現在幾乎全部都應驗了。例如：業主在合同條款中要求BIM；制定標準的工作在全面進行等。
《業主方的BIM》，制定了一個評分標準來說明企業引入BIM技術的深度，從技術、流程等6個角度，用定量打分的方式來分析。
《FM經理的BIM》，別被書名誤導，這本書不是講如何利用BIM來做運維，它通過很多案例來說明一個項目從施工延續到運維需要哪些事。
《BIM實施指南》，具體闡述了一個項目完整實施BIM的各種要素，雖然很多地方不適合中國國情，不過提供的思路很值得學習。
《BIM協作系統研究》，詳細介紹了BIM協同平臺應該具備的功能，以及美國市場上協同平臺的功能打分，對國內平臺開發很有價值。
《COBie應用指南》，這本書的價值在於讓我這樣的IT小白能明白COBie是什麼，它其實不是什麼高深的東西。
《ISO19650》，這本標準介紹了一種系統性實施BIM的路徑，有些東西和《BIM實施指南》想法是一致的，例如需求導向。每個項目業主確定需求了，然後根據需求展開BIM應用。但是，國內很多項目是沒有需求的，就是政策要求用BIM。
以上資料，我基本都翻了10遍以上，逐漸對BIM也有了越來越深的認識。建築工程的前輩希望能學習工業領域的三維設計方式，通過計算機技術，實現建築工程的虛擬建設，從而實現整個項目建設的可控，減少各種浪費。這個初心是非常美好的，還出現了下面這張流傳很廣的圖。
但是，在翻遍了國內外各種案例後，我發現這是個美好的夢。或者說，BIM還停留在理論階段。在實際案例中，我還沒見到一個項目能實現圖中所展示的：項目各方圍繞著BIM實現信息共享，從而提高項目質量等等。
應該說，很多項目實現了BIM的一部分，主要是幾何信息的優化，提高了設計圖紙的質量。在《BIM實施指南》中，詳細介紹了BIM常規的25個應用點，也很值得大家學習。
於是，如何實現BIM模型，特別是非幾何信息的共享，成為了我想要研究明白的題目。我走過的研究道路是下面這樣的。
第一步 創建數據標準
首先，什麼是非幾何信息？非幾何信息應該包括哪些內容？在幾乎所有國家的定義裡，BIM都應該包含幾何信息和非幾何信息。我們還是比較容易的應用了幾何信息，也帶來了一些價值。那麼非幾何信息呢？我很少看到有項目應用。
《COBie應用指南》裡有這麼幾句話：
COBie標準的目的是隨著工程進展，當項目團隊在創建數據時就以BIM為載體獲取它們，並在項目全周期內進行安全共享和更新。從承包商角度看，COBie就是將當前的紙質材料轉換成便於操作的在線數據。
在參考了COBie的相關資料後，我和我的團隊，自己編制了一份數據標準。其實所謂的COBie標準，就是一個獨立的、設施設備從設計到運維數據的結合。裡面包括命名、編碼、空間、價格、系統等等。
我們第一次編制的時候，把參數簡單的分為兩類：技術參數和非技術參數。
技術參數主要包括各種數值型參數，例如長度、寬度、高度、風量、水量等。
非技術參數主要包括各種文本型參數，例如設計人員、施工人員、維保人員、工藝工法、控制開關、聯繫電話等。
但是把這些參數隨意混雜到一起錄入到模型中，發現太亂了。
後來，我們做了改進，把所有數據分為8個大類，重新導入模型後，發現一下子清爽很多，就一直沿用到現在。這八個大類分別是：
身份參數 尺寸參數
設計參數 關聯參數
商務參數 產品參數
施工參數 運維參數
第二步 數模分離管理
有了一份可以用的數據架構後，怎麼和模型結合呢？
關於對數據的主流管理方式，我了解的就兩個，一個是老外提出的IFC標準，包括上海交大、清華大學等高校在研究。另外一個是黃強老師提出的P-BIM，一種基於資料庫的管理方式。我觀察這兩種方式目前都是在理論階段，市場應用還不夠成熟。
我們首先測試了一下IFC和Revit的聯動，把一個集合了多種構件的REVIT模型導出為IFC，再重新導入REVIT，發現各種數據丟失嚴重。在下面的圖裡，原來360個構件只剩下286個。
另外，一半模型的幾何數據可以編輯，一半模型無法編輯。幾乎所有模型的非幾何數據都有部分丟失，甚至全部丟失。
後來，我們把另外幾個BIM建模軟體生成的模型導出IFC，再導入REVIT。也出現類似的情況，幾何數據基本存在，但是無法編輯，非幾何數據大量丟失。
我們沒有很多IT人員，也不想花時間去研究到底是什麼原因導致了數據丟失。從應用的角度，我們認為IFC這條路暫時走不通。
那麼，我們該如何實現數據管理呢？帶著這個問題，我們開始研究各種資料。正巧，在《FM經理的BIM》這本書裡，有類似的文字提醒了我：
BIM的數據資料可以通過傳統資料庫的方式來管理。
既然IFC不行，我和團隊成員們開始嘗試數據和模型分開管理，我們暫且稱之為數模分離。而最簡單的資料庫就是EXCEL。
在討論這篇分享的時候，@小耳朵貓醬說了這麼一句話：
數模分離的本質就是，改變依賴模型帶數據的模式，把編碼作為掛接圖形的風箏線，獨立存儲和處理數據，並且可以通過工具，在輕量化Web/客戶端組裝。
我認為她的說法是對數模分離又專業又通俗的解釋。
確定了數模分離這個邏輯後，接下來就是大量試錯工作了。我們團隊開始大量測試各種BIM軟體，國內不行就找國外的。
2015年，我們找到了解決方法，可以實現把EXCEL表單中的數據批量導入模型。數模分離第一步，也就是線下表單和模型分開管理的路徑算是通了。但是，這還不夠，我們的目標是實現基於Web端的輕量化管理。
第三步 構件編碼
第三個問題接踵而來，那就是怎樣方便區分不同的構件類別。
2016年，我找到一份國標分類編碼的意見稿，裡面提到了各種ISO和OmniClass的編碼邏輯和元素表單，覺得可以利用一下。
學習下來，14號表和30號表比較接近。當時就先無腦直接抄了14號表。可是用下來，才發現問題沒那麼簡單。
首先，14號表是按照設計邏輯劃分的，分成了建築、結構、暖通、給排水和電氣。而我們的數據是全過程的，到了施工階段，要按照分部分項、以及WBS來劃分；而到了運維階段，是按照資產管理的角度來劃分，14號表就更不適用了。
另外，一些設備的劃分會混亂。例如泵，同樣一個產品既可以用在空調水泵，也可以用在給排水泵，會重複出現，這可是編碼的大忌。
在多次試錯後，我們放棄了14號表和30號表，按照我們自己的邏輯來進行編排，設備參數的管理能保持一致的，就歸為一類，編排的方式參考了國標的8位數字來寫。
但是，光是有分類編碼只能確定某一個構件的種類，無法定義它的唯一性。所以我們在分類編碼基礎上，又編制了構件編碼。比如下面這張圖，就是我們構件編碼的一個案例：
在圖裡，前面10位是分類編碼，是參考國標自己編寫的；後面的規格編碼是根據設備種類編寫的，位置碼主要包括樓棟號和樓層，最後是流水號。案例的這個編碼代表了：型號01的離心風機，布置在1號樓的屋頂層的第一臺。基本上可以實現每臺設備的唯一性，類似身份證號碼。
因此，我們從技術角度，實現了非幾何信息的批量處理，也和模型實現了對接。下一步就是如何能真正應用起來，把工作從線下搬到線上。
第四步 公共數據環境CDE
早在2015年時，《BIM協作系統研究》已經提到了這樣的話：
現有的協作依賴於電子郵件和文檔，而為了模型協作，需要一個複雜的公共數據環境（CDE）。CDE方便對模型數據執行協作操作，涉及用戶管理和支持用戶需求的功能。
而在最新的《ISO19650》中，對CDE有了更加清晰的介紹：
CDE 解決方案同時包含管理信息載體屬性和元數據資料庫的功能，也具備向團隊成員發布通知的功能，且能維護信息處理的審核軌跡。
第四個問題就到了如何創建CDE，解決非幾何信息的共享問題。
2019年，BuildingSMART大會在北京召開。我加了這次大會，結識了不少業內同行，也學習了不少最新的BIM知識和來自歐美的新技術。其中一款在線產品，讓我聯想到了CDE。
接下來的情況，又是老套路，不停的試錯。終於可以實現我心目中的CDE了。
在這個Web產品裡，可以實現分類編碼一鍵上傳，然後每個構件都可以分配到相應的編碼下面，掛接屬於它自己的一套數據標準。我們為每個構件編寫了詳細的數據標準，用戶可以在平臺裡直接調用設置好的構件。同時，所有項目參與方可以基於Web端，在線輸入每個構件需要的信息，也可以分享他人的信息。
至此，我們實現了從數據分類到數據標準，到數據共享的過程。
第五步 標準共享
一開始，我們是純從技術角度來探索幾何模型和非幾何數據的分開管理。但是到這一步的結果，為困擾我的兩個問題提供了新的解決思路。這兩個問題分別是：
BIM的本質是資源共享，可是很多公司都在分別建族，然後出現大量的重複勞動。
業主在要求項目交付模型的時候，無法明確交付模型攜帶的信息到底是什麼。
第一個問題，其實有不少人在做。網上可以搜索到很多類似的族庫共享網站，有些還在更新，有些已經逐漸隱退。我認為這些族庫軟體都比較相似，而且缺少對非幾何數據的管理能力。
第二個問題，目前我們沒有找到任何其他公開的產品能實現。
我們的計劃是，把所有能找的各個類別的族，都加載我們的數據標準，然後放到在線平臺，免費共享給大家。
基於以上共享的數據標準，各位BIMer就可以實現給業主交付攜帶數據的竣工模型了。
當然，企業也可以在這環境下定製屬於自己的編碼和標準構件庫。如此一來，可以保證企業所有項目的三維模型中，幾何構件和非幾何數據都保持一致。
第六步 數據可視化
我們在自己的兩個項目上測試了這條技術路徑，可以實現多種數據的快速整合。在有了數據之後，接下來就是給業主獻寶了。業主不可能在REVIT看數據啊，所以輕量化平臺又進入我們的研究範圍。
這個平臺需要具備最基本的兩個功能：一個是對幾何模型的輕量化展示，另一個就是對非幾何數據的展示。在對市場上主流輕量化平臺做了測試後，我們做出來了選擇。如圖所示，當我們點選某一個欄位，例如「廠商」，我們就能查看到某個廠商所有產品以及它們所在的位置。
第七步 數據分析
接下來是最高級的一步，就是數據分析。我們千辛萬苦去收集建築構件的數據，就是希望通過數據分析來優化我們的設計施工運維的各項工作。
萬裡長徵才剛開始。
在這個領域，幾乎沒有任何資料可以參考，只能靠我們自己摸索。其實單純的數據分析還是有軟體可以實現的，我們已經做了嘗試。但是，我們希望是一個基於模型的數據分析。在我們看各類數據分析圖的時候，能同步聯動我們的模型；當我們分析出來某個設備的問題時，能在模型上同步高亮顯示。
以上是我們團隊在非幾何數據管理這條路上的探索，結合我們的實踐，我再拋磚引玉補充幾個應用場景，給大家做一下參考。
比如，在項目結束時，交付一個含數據的竣工模型用於運維系統。
目前，我們和一家國有地產公司合作一個運維項目，後續還有八個類似項目都要上運維平臺。第一個項目做得很痛苦，因為當時各類設備的數據都沒有收集，後續通過總包和各個供應商去收集的時候，前前後後拖拉了好幾個月。如果把這些工作分配到各個供應商手裡，其實每家的工作量就不大了。但是，這就得要求業主在項目前期就要規劃好這個數據標準。
比如，生成集中採購清單。
因為每個設備構件都有空間和類型的屬性，業主在採購時，可以快速根據區域來形成明確的各類設備清單，也能看到每個設備所在的位置。
再比如，可以通過數據實現模型批量修改。
不管是在Excel表還是Web端，都可以對所有數據進行快速批量修改，其中也包括幾何數據。例如：兩個個房間的門，原來都是2米1寬，現在其中一個要改成1米8，只需要在表單裡批量修改，再刷新，模型也就會跟著修改好了。
最後，我想說說寫這篇分享的原因，還有我個人一路走來的感受。
在英國的BIM LEVEL 2中，對BIM的定義說的很清楚，就是需要同時共享幾何模型和非幾何數據。但是，我們目前能看到的所有BIM案例都是對幾何模型的應用，針對非幾何數據的應用幾乎沒有案例。
既然大家都說數據是未來，那我們就想試試看，能否摸到建築數據的門檻，看看裡面藏了什麼寶。
IFC可能會成為終極大BOSS，但是肯定不是現在。對於我們做工程的人來說，我們需要解決問題，而不是停下來等，所以我們會不停嘗試。也許，有一天IFC可以成熟應用，那我們還是會回到IFC這條路上來。當然，也許我們會在數模分離這條路上一直走下去。
現在大部分圈內人都認可BIM的本質是建築信息化。但是，很多人過於追求各種高大上的IT技術，而忽視了一件事。建築信息化是先有建築再有信息化。建築是本，信息化是術。所以，用什麼工具方法都不重要，重要的是解決建築的問題和業主的需求。
以上僅僅是一家之言，如果你也在摸索類似的方法，歡迎相互探討。
BIMBOX觀點
在BIM圈裡，談數據應用是一個很燙手的話題，談遠了不接地氣，談近了困難重重。首先在數據傳遞這一個環節，人們都沒有達成統一的想法。尤其是IFC這個領域，更是很多群裡聊起來就會爭論的東西。
有人覺得IFC是一條死路，應該早點拋棄另尋他路；也有人覺得IFC本身沒問題，有問題的是軟體；更有人覺得IFC和軟體都沒問題，有問題的是人的水平。這裡面不單單是技術之爭，也有商業之爭，甚至是信念之爭。
BOX對這件事的主觀態度今天不展開談，我們單說對金戈這篇分享的看法。
在這篇文章的初稿發布到作者群時，大家對IFC的未來也有一番爭論，但最終打動每個人的，還是金戈的一句話：「我們並沒有很多IT人才，IFC出現了問題，這是我面臨的實際情況，我暫時解決不了，但我不能等，得繼續往前走。」
最後大家的統一意見都是：無論每個人對IFC是什麼觀點，都支持金戈把自己最真實的探索經歷講給大家。
缺少IT人才，是國內很多企業的實際問題，但我們不能說，企業缺少IT能力，就別搞BIM了。行業裡有負責講故事的人，也有專門琢磨大問題的人，既有面對傳統問題的人，也有追求創新的人。每種人發表觀點，其實都是站在自己看待行業和世界的角度，追求一條可行的實施路徑，抓自己面前的那隻老鼠。
而我們最支持的是這樣一種人：他們有行動的勇氣，也有分享的善意，把事情做出來，再把自己蹚過的坑寫到文字裡講述給別人，這比簡單持有一個不容辯駁的理想要困難得多，也可敬得多。
金戈在和我們談到這件事的也說到，他更希望能通過這次分享聽到不同的聲音，甚至是反對的聲音，大家一起探討，怎麼能在需求的角度把數據的價值真的挖出來，而不是讓BIM一直站在翻模的戰壕裡空舉理想的大旗。歡迎你把你的思考寫下來，和我們一起聊聊。
有態度，有深度，BIMBOX，咱們下次見！
本期內容原作者：金戈本期內容探討人：@老孫 @小耳朵貓醬 @程旭 @VCTCN93 @熊仔 @開開本期內容讚賞金額50%歸作者金戈所有，剩餘一半作者群搶紅包，感謝大家支持