0，什麼是“打通”？
回答這個問題並不容易，因為這需要小心謹慎的定義問題中所包含的各種基礎概念。而對於傳統建築業來說，這實在是太麻煩了，新詞、舶來品、新概念太多，還有很多思想是有悖於國內傳統認知的。我們先約定：未經定義，不討論。這樣就會減少很多爭議。所以本文打算僅討論這個問題本身。
那麼，到底這個打通是一個什麼樣的對象呢？是像拳頭打穿牆體嗎，是海底隧道被貫通嗎，還是深圳到香港的通道變得快捷了?為了定義這一因素，我們必須要藉助其他相關因素才能得到很好的定義。
接下來，我們按照主謂賓、定語修飾語等等的語法因素，來逐一討論這個問題。
1，什麼和什麼打通？
在BIM+FM這一表述中，BIM代表了建築業（的計算機技術），FM代表了物業設施管理行業（的計算機技術），隱含著的兩個計算機技術，簡單來說就是軟件，經常會被省略掉。FM的軟件相對比較容易明確，傳統的CAFM或新潮的IWMS；而建築行業的軟件可就不容易歸納了，花樣繁多，難於在此一一探討，我們暫且拿兩個比較有代表性的來討論吧，一個是設計建模軟件revit，一個是施工管理信息系統vico軟件。
如果問題簡單到只是：在revit/vico和某種CAFM/IWMS之間對接數據，就像前述的那樣，那麼顯然，已經打通了！
除了軟件之外，如果這兩個對象還有其它的所指，比如兩個公司的打通或某種神秘的關係的打通，也暫且不在本文討論之列，本文只打算討論可以被定義的。
2，打通什麼？
承接前述的定義，兩個軟件之間的打通（對接，導數據，互通，信息協作），我們可以先簡單定義為：一個軟件將數據送到另外一個。或者再複雜一點：兩個軟件之間可以互相調取對方的數據。但無論如何，在兩個軟件之間通的對象只能是數據，即使是某個有形的三維構件形體，它在軟件中也只能是一堆數據。當我們把電腦關掉的時候，軟件會把所有的三維模型摺疊好，收到櫥櫃裡面去，即將數據保存到某個數據庫中。
那麼，問：經常會有信息的說法是怎麼回事？信息和數據有何不同？
在本文的討論中，兩者是一回事。只是在建築業的專業角度來看，所有的數據都是某種專業信息；而從IT的角度來看，任何信息都是數據而已。我們暫不考慮“數據-信息-知識-智慧”這一序列，雖然這是一個能夠更好的區分數據與信息的思考角度，但不適用於本討論。
這只是定義了一小部分，因為本問題還會衍生出許多問題：FM需要BIM提供什麼數據？哪些數據是有用的？需要的數據沒有怎麼辦？前面錄入的數據錯誤怎麼辦？
於是我們還需要更多的定義。
3，誰來打通？
無論是建築業還是FM，帶有主語的討論都是最有價值的，失去了主語，討論將很容易變得離散。在房地產開發項目中通常會有多方參與，構成一個圍繞特定項目的項目協作團隊，這包括開發商、設計公司、施工單位、監理公司、諮詢公司等等；而運營則較為明確，有兩種可能的主語，即自用物業的FM管理方，與公共物業的物業管理公司（或開發商旗下的物業部門），儘管國內尚無FM專業可言，但由於BIM的風潮引入，使得一批先知先覺的朋友在研究BIM+FM的時候遇到了FM，而少有人去研究BIM+物業這個組合。
但是不幸的是，國內目前所見聲稱打通了BIM+FM的案例，可能都還沒有見到FM、更別說理解了，因為隨處可見的乃是物業
4，打通了多少？
這是一個由問題2衍生出來的問題，即如果只是數據對接，那麼數據導出可能會出現成功率，比如99%的成功率，這既有可能是100次中出現了1次錯誤，也有可能是指100條數據中有一個是錯誤的，錯誤的原因和表現暫且不談。如果較真的追究這個成功率的數字的話，那還需要進一步定義：數據是什麼？是按字節計算，還是一條屬性（實質為一個特定字段的一個特定記錄），還是一個編碼。
至此，我們已經遠離建築業的專業領域，而進入到一個由計算機專業、企業管理（之FM）、項目管理、ERP等領域複合而成的一個新的領域，我們暫定其名為BIM+FM。以我的研究所見，這個領域也許並不存在什麼高深莫測的神秘知識，所缺乏的是作為一個單個的探索者而言，其所涉領域之大，難以窮盡，更不用說吃透之後再將它們整合起來了。這實在是力不能支，這是不折不扣的行業級的BIM應用，需要的是一大批人的兩兩信息協作，而不是單靠一個人去研讀資料。這還僅僅是理解這些內容，還談不上為客戶定製解決方案呢！
5，打通了有什麼用？
這才是問題的關鍵！為何要討論打通，原因是打通了會產生某種較高的附加值，從而令客戶買單！
如果是在為一個並不存在的主語服務，或者使用了一個自己也不清楚的軟件（的名字），甚或只是聲稱自己具備某種能力，也許能夠一時的忽悠客戶、得到訂單，但那決不可能變成穩定的商業模式。
6，打通的衍生問題
至此，我們只算是討論了整個問題的一小部分，而且僅僅是定義。如果我們還想搞出解決方案，那則根本不是本文所能完成的，目前在國內，我相信也極少有人可以做得到。因為我們至少還會遇到下列更為複雜的問題：
（1）倘若選擇的FM軟件不是CAFM/IWMS系統，而是單機版的小軟件，甚或自行開發，那又將會是完全另外兩個天地。即使是大型系統，由於FM專業尚未被很好的建立，軟件廠商很難於銷售，如今年在國內產生的有史以來最大的一宗CAFM採購案例中，大型軟件廠商就是如此，I記公司不知道應該如何選擇何種軟件來匹配客戶需求，O記公司的人居然都不知道自家還有此類產品。而這些大型軟件公司的銷售人員對企業管理信息化領域已經算是諳熟資深了。
（2）單機版的FM軟件在國外軟件行業正在行將消失，如Autodesk曾經推出的FM-desktop（我們遵照Autodesk內部習慣簡稱為FMD），Manageengine曾經推出的Facility-desk。這兩款軟件實則C/S結構，由於數據庫市場的變遷，純以單機版軟件內嵌數據庫的做法已經不再。大型系統如ARCHIBUS至今仍然保留有古老的C/S結構的產品與B/S並列銷售一樣，因為他在北美地區的確是有一定的客戶群的。但是，前兩者後來在全球市場上已經消失，雖然曾經推出過中文版，在中國市場上還未來得及產生過銷售記錄。
那麼國內有沒有小型的FM軟件呢？完全是空白。倒是如果考慮到物業領域，物業軟件有一大批，約有數千種，主要是以小區物業管理為對象開發的系統、單機版軟件。
（3）自行開發看似更能夠貼近客戶的需求，但實則難度更大。有兩個國內的實例可以說明問題，十年前我在某金融行業的業主方選購ARCHIBUS時，IT部門就進行過自行開發還是採購成熟軟件的對比研究，僅ARCHIBUS的三個功能模塊（空間，維修，資產。當時的模塊劃分與今日不太一樣，大致上相當於今天的5-7個模塊），就需要一個不小的團隊開發上三年。最近幾年有大型連鎖店總部委託開發了一套FM系統，耗費將近千萬，卻只實現了一小部分滿意的功能，即報修維護管理。
（4）自行開發期間遇到的麻煩問題不一而足，尤其是需求工程這一關就極難越過。以我曾經經歷過的一個國內的大型交通樞紐項目的BIM+FM開發為例，最初開發團隊的當事人對客戶的管理組織架構和運行流程無法很好的理解，而客戶方又需要進行進一步的優化，理由很簡單：如果不能產生優化，那要這些新技術幹嘛。而需求工程的源頭恰又在與組織架構與業務流程，這是管理信息系統的普遍規律。這個規律非常不同於工程技術領域的單機作業（單兵作戰），這種規律的探尋和付諸實施都不是工程技術人員所能夠完成的，必須要有足夠強的企業管理的背景知識。無需求，無開發，此項目梳理過的需求（已經被規整過，成為解決方案的雛形了）如下：
這種架構的思想不僅來源於企業管理（中的FM），還需要將工程技術與信息化技術（尤其是BIM技術）都納入進來，統籌考慮。僅僅對這種結構思想的理解就已經是非常困難的事，更何況去實施。
既然已經談到了組織架構與業務流程，那我們就再往前走一點吧，那就是：FM專業本身到底是什麼？
7，FM是什麼？
無論我們站在全生命週期的宏觀角度，還是建築項目的實施過程，甚或是一個BIM+FM項目的角度，最終都會遇到這樣一個不可逾越的問題，那就是：FM到底是什麼？
首先被建築領域所公認的理解是指運營階段。在全生命週期角度來看運營是最為漫長的使用階段，對於建築項目來說那是終極目標，對於BIM+FM項目來說那可是客戶、是預算。比如說數據，運營的數據多從建設過程繼承而來，在運營過程中設施工程師查看一臺設備的數據，也就是那些設計參數、屬性等等，似乎都是建設過程中所能蒐集到的，幾乎看不到任何技術含量；可能不同的只是，運營所需要的信息分類方式不是施工歸檔的那樣，那是按照建築工程的規律而做的分類。
那麼看起來答案是具有普遍意義的，也就是前述的功能模塊圖表可以適用於大部分的客戶嗎？錯，全錯！這張圖僅適用於這家特定的客戶，是完全的定製化的個性化的。而且這張圖是在溝通過程中被修訂了無數個版本中的版本之一。圖中的任何一個小格子都有著深切的涵義，全部都是直接指向這個特定客戶的特定的管理需求的。
在FM非常成熟的國家的確是有著比較普遍的規律的，比如美國的教育領域，有著幾萬家教育機構，但凡有著一定空間規模的機構都會有一個FM經理，他們的需求非常接近，那真的可以被歸納為一個體系，從而為之定製開發某種通用型的管理系統，這就是為何美國盛產FM軟件公司的最終原因——單一成規模的市場。這在國內還是一個看似遙不可及的夢想，國內的市場還處於“前FM時代”。
至此，我們所探討的打通BIM與FM的問題已經完全的進入到FM的管理世界了，這不僅告別了建築業的技術語境，也完全沒有了IT的影子，更不用說BIM了。
8，FM與BIM的數據關係是怎樣的？
經歷了FM的管理世界，再來談與BIM要打通的CAFM/IWMS就有現實意義了，因為這些軟件系統本來就是FM管理體系的信息化。CAFM中的數據就是FM管理作業的數據，按照問題2的定義，互通的內容就是數據的互通，那麼我們將會遇到大量的具體的問題，如：
若FM工程師想要添加一個構件，比如是當時施工模型裡面沒有的一個新採購的設備，他要在BIM模型中添加這個構件嗎？還是在CAFM數據庫中添加即可？或兩邊都添加？或一邊添加同步到另外一邊？或分別添加然後在鏈接起來？等等。
又如：他如果要修改一個構件的屬性信息，將要在Revit這邊修改，還是在CAFM那邊修改？要構造一個新的中央數據庫嗎？或是一個由兩者共同管轄的同步的數據庫？
又如：建築構件門類複雜多樣，而每類屬性大異，門窗的十幾條屬性與空調風口的幾十條屬性存在很大差異，這在revit這樣的軟件中可見一斑，因此這類軟件都構造了龐大的構件分類編碼體系，如UniFormat、MasterFormat和Omniclass三個內置到revit軟件的常見體系。那麼，之於完全沒有這些編碼體系的中國來說，需要構造一個新的體系嗎？
顯然，若無分類體系將構件對象進行分門別類的處理，那數據庫將會糟糕到什麼程度：一個新增的構件的屬性條目（數據庫字段）將會高達數千！
現在，為了解決一個數據的添加或修改問題，我們又徑直走到了構件分類法（本體論）的領地。研究這類作為行業級的宏觀但又極為枯燥的分類編碼方法，所需背景知識已全然不再是建築工程師、設計師、軟件工程師之中的單一背景所能涵蓋的了，僅僅理解就成為很大的問題、遑論構造一個體系？
內中的理解問題就像前述的軟件功能結構一樣，拿掉一個小框框、或改一個名字，可以嗎？會出什麼問題？有什麼影響嗎？這些問題甚至於沒有答案，至少在個人級和團隊級應用的層面上沒有答案可言，這至少要在行業級層面上才有答案可言。在這個意義上，BIM+FM無疑是行業級的應用。
