BIM大忽悠

BIM 大忽悠

作者 數碼阿叔 / 柏基建築師  壬辰年荷月發佈於新浪博客

【前言】

“ 那是個最美好的時代，也是個最糟糕的時代；
  那是充滿智慧的時代，也是遍地愚昧的時代；
  那是光明和煦的季節，也是黑暗陰冷的季節；
  那是洋溢希望的春天，也是令人失望的冬天；
  我們不顧一切的奔向天堂，卻在不知不覺中滑向地獄。”

這是狄更斯同志寫在其《雙城記》書中的開篇文，在這裡我借來用一下，《雙城記》描述的故事背景是二百多年前的法國大革命時期，本文跟那些陳年往事無關，我們的背景是當今的「建築信息大革命」時代。今朝是個最美好的時代，因為很多人用上了 “建築信息模型化”(BIM)；今朝也是個最糟糕的時代，因為還有些人成天搞的那 BIM 卻是淪為 “忽悠”。或許是無心、或許是有意，總是因為有人忽悠，就會有人當上冤大頭，有人看得透徹，但也有人被賣了還搞不聆清自己傻在哪裡，今朝還真是充滿智慧的時代，同時嘛！就像狄更斯同志寫下的，也是個遍地愚昧的時代…。在 BIM 尚未成熟到用上了就能令我們能奔向天堂的今天，說起來即使不用或誤用也不會讓我們滑向地獄。雖然大多數人做得心誠意正，但俗話說："林子大了什麼鳥都有"，總是會有一些大小忽悠在建築圈子裡打轉轉搞七搞八。

BIM 這個名詞究竟代表了哪些東西，眾人的理解不同，原本就帶點爭議性，有人把它說得鋪天蓋地的複雜，也有人將它認知為就那麼一個三維模型唄！然而，就跟上館子吃飯一樣，您要的是全餐、套餐、單點，還是整了二兩生煎包外帶，吃進肚子裡都是不一樣的。其實 BIM 這東西早先沒有，也不是某人或某機構獨創的發明，而是外國建築行業面向蛻變需求，結合電腦發展的能效提升過程，逐漸積累的結果。但是 BIM 的存活是離不開電腦的，並且還得是高性能電腦，昔日當電腦硬體的運算能效尚未達到一定水平之前，相應軟體的發展也無從達標，BIM 也就不可能出現。BIM 被建築業界有系統實際應用的歲月，並沒有那些急於推展和推銷者宣稱的那麼久，也沒那麼多，就算在外國也從未普及到家家流水、戶戶垂楊的地步，有很大比例的建築業者也還掙扎於用與不用之間，我們切莫迷於少數幾家同行的成功案例，而一廂情願的認為外國在 BIM 上已經普及應用了。一路下來就算是摸著石頭過河，洋人比我們先摸了好幾年，走得比我們遠，現在我們挨蹭著、跟隨著、學著做也算是不錯，總能從裡面汲取些許好處。

說白了在 2008 年以前，咱們這裡只有少數幾位先知預見了這個大未來，在為 BIM 的科普化應用奔走呼籲。有幾家軟體供應商開始營銷這類軟體，也許還有幾個機構注意到了 BIM，開始進行評估研究。加起來一共有多少，扳著指頭能數得出來。除此之外，當時建築圈子裡大多數同行正埋首搞設計搞施工，操勞於討生活，誰都沒功夫搭理那個遠在天邊的玩意兒。不惟互聯網上尚未出現專門討論 BIM 的論壇、博客之類，那時就連 Ecotect 也還姓 "S"，還沒有入贅到 "A"  家，何來拿三維信息模型操作建築性能分析模擬之說，倒是很早就有同行在用 SketchUp 建模搭配 Ecotect 4.5 進行建築性能模擬分析。

但是 2008 年以後就不一樣了，隨著電腦軟硬體達到了 BIM 應用所需要的基本效能要求，加上互聯網的快速傳播擴散，很快的 BIM 就變成了國內建築業界的香餑餑，許多原本了無聲息的建築相關業者，此刻紛紛冒出來宣稱咱家已經搞了若干若干年 BIM，不然就說咱家的產品原本就是 BIM，或者宣稱咱家好幾年前早就把 BIM 用在建築項目上了….等等，似乎重演了寒武紀物種大爆發的場景。是否為無源之水、無根之木，其實也不必著心去探究，總是許多人上了馬，日後能走得遠一點比較重要。

何來忽悠？如果您感覺這事有點懸。那就先去瞭解一下 BIM 的一些特點，看看這東西跟您眼下手裡正在用的 CADD 有什麼不一樣的地方，且看下面這段文字：

“建築信息模型 (Building Information Modeling, BIM)，是以建築工程項目的各相關信息數據作為模型的基礎，進行建築模型的建立。它具有可視化、協調性、模擬性、優化性和可出圖性五大特點。”

相對於大家認知的傳統 CADD 而言，至少 BIM 的信息數據、三維模型載體、可視化、協調性以及模擬性等等這些部份，在傳統的二維 CADD 應用中是比較不足或匱乏的。那麼不論您是自學還是花錢上培訓班，用上了 M/R/A 字頭的軟體就算是 BIM 了嗎？非也，恐怕還有更多您得學會的東西藏在 BIM 這個名詞背後。拿那些軟體工具去構建三維模型不是什麼難事，學會操作也不很費勁，但是眾所周知的，BIM 至少不是某個單一軟體，用它也不該僅僅整了個三維模型出出圖就算了事。BIM 是一系列的應用過程 (Process) 和優化的工作流程 (Workflow)，建模不是設計或施工程序的 Ending，而是要拿信息模型做為整個項目建設的樞紐，有效管理著項目建設的整個流程。

如果一味四處宣稱自己在建設項目裡運用 BIM 獲得了多大多大的效益云云，實際上對於建築信息、整合、協作、模擬、實施準則、管理、數據交換與傳遞等等卻都搞得七零八落、殘缺不全，沒法完全涵蓋上述那五項基本特點，您說這能算是沒有忽悠的成分在裡面嗎？不論是個人、機構、或是項目團隊，在宣稱自己具備十足的 BIM 競爭能力之前，是不是先搞清楚自己的 BIM 能耐 (BIM Capability) 和 BIM 成熟度 (BIM Maturity)，先給自己在市場裡做好正確的空間定位，再來談其它的。

說到當前建築圈子裡有些人在搞 BIM 忽悠，講真話必然讓人聽了不爽，數碼阿叔我也沒有 "一根竹竿撂倒一船人" 的壞心眼，請諸位先進幸勿對號入座，在把槍口朝向我之前，我們可以看看搞 BIM 的洋大人怎麼說。就在去年 (2011) 夏天，澳大利亞有一位 Bilal Succar 同志他寫了一篇很有意思的文章，放在他自己的 "BIM Thinkspace" 網站上。這篇文章的名字叫做《Understanding BIM Wash》，中文意思是 "理解 BIM 的忽悠"，文中對於國外建築圈子裡應用 BIM 的忽悠情況做了直白的介紹。
我花了一點時間把這篇文章改寫成中文，以附註的方式加上一點點我個人的看法，在這裡分享給眾 BIMer 們。

【原帖】

理解 BIM 的忽悠
Understanding BIM Wash

作者：Bilal Succar

"BIM Wash" [1] 這個名詞，形容對 "使用" 或 "交付" 建築信息模型產品或服務提出誇大其辭的 (有時指欺騙性的) 的主張 (能力和取費)。一個犯了 BIM Wash 的單位通常會透過其旗下的工作人員、網站、項目提交以及營銷宣傳材料，對其 BIM 能耐 (BIM Capability) 提出逾越本分的取費要求。

就像之前鬧騰了多時的什麼 "綠色XX"，因為市場的過度需求而出現 Green Wash 一樣。當今由於許多人認識到 BIM 工具和工作流程的價值高，加上許多業主要求把三維模型作為項目提交文件的一部分，與日俱增的需求使得 BIM Wash 在市場中得以順利崛起。

BIMwash 則是一個新近創造的單一術語，跟前述 BIM Wash 的意思是相同的。有少數的 BIM Wash 活動可歸因於圍繞 BIM 一詞本身的混亂，可能不是故意的，甚至在一定程度上無害的。然而，其他的活動更多是故意欺騙。許多是嘗試去出售尚未開發出來、或者遠低於客戶期望的 BIM 服務，這是千真萬確的事。

建築項目實施過程中，位於客戶端的業主必須聘請服務供應者 (建築師、工程師、承包商...) 從事專業服務，如果某些服務供應者是 "假冒成 BIM 專家" 的 "BIM 忽悠"，則將對業主造成問題。實際上這些 "BIM 忽悠" 對服務供應者本身也形成問題，它們的活動等於攪渾了一池水，讓人分不清孰是孰非，這對那些投入了很多時間、金錢和精力，致力發展 BIM 能耐並且磨煉 BIM 交付成果的真正 BIM 服務供應者將是非常不公平。

※ 數碼阿叔註解：偽冒的成本是很低的，獲益卻很高。假冒成XX專家的個人、顧問或機構他們總是會想著，先把服務機會搞上手，之後嘛…"腦袋過了身子大概也過得去"，接下去就拿這些建設項目來練兵唄！且戰且走，萬一捅出了什麼樓子，那時生米早已煮成了熟飯，至多不濟拍拍屁股走人，賺了銀子也賺了經驗 (即使是失敗的經驗)。其實這種事情屢見不鮮，因而建築圈子裡就會經常聽到「如果早知道…那我就會…」的說法，說這種屁話的多半是位於客戶端的業主，如果不是人品問題、不是帶有想佔便宜的貪嗔癡，當然不會做錯選擇而在事後發出悔恨的抱怨，有錢難買早知道嘛。然而經由偽冒和誇大其辭去拿項目確實是不應該的，也不能當成市場潛規則來對待，因為就是這種忽悠存在，擾亂了市場秩序和行情，受害的不是單一個案而是整個建築圈子。

定義 BIM 忽悠 (Defining BIMwash)

BIMwash 這個名詞源自於 Whitewash，這個 Whitewash 原意是指「一種廉價的白色塗料或石灰粉塗層，用於快速給各種各樣的表面抹上一層均勻整潔的外表」(※ 咱們稱為 "四白落地")。比喻為 "粉飾太平"，意味著 "掩飾或隱瞞罪惡、罪行、醜聞或假借...偏頗的數據表現，以求開脫"。(見 Encyclopaedia Britannica 大英百科全書 2003 年版)

※ 數碼阿叔註解：Wash 用在這裡並沒有對等的中文詞匯，但是卻有個流行語可以傳神的描述這種行為:「忽悠」，因此把 BIMwash 稱之為 "BIM忽悠"，確實恰如其分。

從本質上講，BIM 忽悠是企圖遮掩其缺陷 (對 BIM 的無能)，同時對 BIM 能耐 (Capability) 或認證 (Credentials) 提出了一種不正確的說法。我們運用更能衡量它的定義來看，所謂 "BIM 忽悠" 就是：

"BIM Claim < BIM Competency"

對 BIM 的主張 (BIM Claim)[2]，逾越了其實際的 BIM 應用能力 (BIM Competency)[3]。
也就是說，BIM 忽悠 (BIMwash) 存在於「當個人、單位或項目團隊等對其基於 BIM 的主張(能力表述和索求的報酬)[4]，明顯高過以其實際能力交付結果所應得的報酬時 」。這個公式意味著為了要能準確的衡量 BIMwash 的行為，首先必須搞清楚什麼是 "BIM 應用能力" (BIM Competency)。

理解 BIM 應用能力 (Understanding BIM Competency)

"BIM 應用能力" (BIM Competency) 這個名詞，指的是可交付一整套 BIM 服務的能力和它們相應的要求。所謂 "勝任 BIM" (BIM-Competent) 它是一種標簽，可以適用在不同的規模上，包括面向個人 (建築師、工程師、項目經理等...)、單位、或者項目團隊。

※ 數碼阿叔註解: Competency 這個字本身具有 "競爭力" 的含義，表示跟其他同等級個人 (或單位、團隊) 之間就某項工作技巧、熟悉情況、知識含量等等的程度差別。因此把 BIM Competency 稱為 "BIM應用能力" 似乎比較妥當，有別於 "BIM能力" 這種比較含混不清的說法。並且在英文中 Competency 應用能力、Capability 能耐、Ability 能力，三者各有所指，不要搞混了中文的意義。

• 「勝任 BIM 的個人」(BIM-Competent Individual) 是指擁有足夠 BIM 的技能、知識和經驗的個人 (Individual)。例如能勝任 BIM 的工程師，並非僅僅利用 Revit、DP 或 Tekla 等軟件工具去產生 "富含數據" 的三維模型而已，而且還能適時的進行各種工作，並且遵循高標準交付成果。

• 「勝任 BIM 的組織」(BIM-Competent Organization)[5]是指一貫交付全系列高品質 BIM 成果與服務的組織 (或稱機構、單位)。注意所謂 "一貫交付" 指的不是 "能夠交付" [6]，這裡強調的是持續的工作狀態。勝任 BIM 的組織並非僅僅是掛靠著一些能勝任 BIM 的個人，而是以他們為核心，圍繞他們提供充足而全面的管理制度、實施準則、和應有的工作支持。

•  「勝任 BIM的項目團隊」(BIM-Competent Project Team) 是一個有組織的協同工作群體，除了包含能勝任 BIM 的個體以外，還 "已經具備" (※注意原文是指從過去就具備) 必要的成功實踐經驗，通過共同的實施準則、協作制度 (Collaborative Systems) 與優化的工作流程，聯手交付全系列 BIM 服務 / 成果。

※ 數碼阿叔註解: 由此看來，想要成為應用 BIM 的適任者，除了具備完整的應用理論知識，首先得熟悉建模軟件操作，必須清楚瞭解現有的軟件功能到底能做到什麼程度，只動嘴不動手是不行的。並且如果僅僅是利用軟件工具產生信息不足或者不帶信息的三維模型，那麼甚至連 "勝任BIM" (BIM-Competent) 的條件都搆不上。
"Competent" 這個字包含了 Qualified (勝任、合格、熟手) 以及 Capable (能幹、得力) 這樣的的含義，指的是具備了常態性操作的熟練和足夠的實務經驗。因此 BIM-Competent 跟 BIM-Ready (備便使用 BIM) 兩者有本質上的差異，最大的差別在實務經驗的磨練上，舉凡從書上學到的、別人分享的那都不叫經驗，一切都得自己下功夫親身歷練，涓滴積累，才能算是 BIM-Competent。

言歸正傳，使用上述有組織的 "尺規"，我們簡要地探討幾種典型 "對 BIM 服務提出不合理的主張" 或稱為 "BIM 忽悠" 的原型。

(一) 個人的 BIM 忽悠 ( Individual BIMwash)

個人 (Individuals) 的服務對象通常是組織或項目團隊，個人對其 BIM 應用能力提出不合理的主張 (※宣稱的能力與報酬)，這在招聘過程中是普遍存在的。個人到那些需要某種 BIM 應用能力的機構去求職時——可能宣稱自己具有優秀的 BIM "技能" 或顯著的 BIM 工作經驗。這些主張在求職者提交的簡歷中或招聘機構的推介中都看得到、或在面試室的範圍內不厭其煩的聽得到。對於這樣的主張，接下來可能被證明真的是物有所值，但往往不是，有許多最終被證明是充斥著雕蟲小技和不準確性。
那些位於 "BIM 忽悠" 接收端的項目領導人往往事後能作證說，在招聘過程中聲稱他/她精通 BIM 的這樣一個新兵，上崗之後竟然是效率低下，甚至使得整個團隊在交付成果的關鍵階段[7]因此被逼著拖慢了進度。

(二) 組織性的 BIM 忽悠 (Organizational BIMwash)

組織 (Organization, 或稱為機構、單位)，再延伸即為項目團隊 [8]。這類忽悠者在想要贏得(或滿足) 客戶時，以及想要爭取新的項目或合作夥伴時，可能會宣稱他們具有優越的 BIM 應用能力，這類主張在那些市場營銷材料 (包括網頁、簡報、能力陳述…等等) 裡特別盛行，尤其是在那些項目意見書裡，"BIM" 這個名詞已遭大客戶鬆散的嵌入招投標的要求或類似的文件中，也因此給出了需求性。
在數不清的情況裡，那些公開宣稱他們 "BIM的領導地位" 和 "優越的 BIM 能耐" 的組織，已經證明其常常是缺乏基本架構去交付一種合理品質的 BIM 產品[9]或服務[10] 。

(三) BIM忽悠的其他犯行者 (Other perpetrators of BIMwash)

除了服務提供商 (Service Providers)[11]之外，典型的核心人物——BIM 忽悠，還以下列的面貌出現[12] ：

• 軟體開發者和他們的經銷商們，誇大特定工具的好處，或聲稱他們的產品是 "一個全方位的 BIM 解決方案"。
• 要求提供 BIM 產品/服務的客戶/業主們，他們可能還不明白，等到交付給了他們以後，他們得到的並不包括妥善的運用和維護的內部能耐。
• 通過諮詢者的 "BIM 忽悠"，以及在 BIM 實施過程上誇大他們服務影響的顧問們。

BIM 忽悠的四個級別 (The four levels of BIMwash)

並非所有的 "BIM 忽悠" (BIMwash) 都具有相同的力度。輕微形式的不合理 BIM 主張，在一定程度上可以是無害的，而其他可就算是惡意的和破壞性嚴重的。為了幫助打擊 BIM 忽悠，得要辨別它的四個不同層級 [13]：

第 1 級：混亂或非故意的 BIM 忽悠
 (Level 1: CONFUSION or Unintentional BIMwash)

不理解 BIM 的過程與協議，或者認為 BIM 就跟 CAD 差不多，對基本模型交換和以模型為基礎的協作觀念混淆不清，甚至把模型伺服器(Model Server)跟檔案伺服器 (File Server) 或文件管理系統 (Document Management System) 都混淆在一起，搞不聆清。
那些尚未理解 BIM 概念的多層含義的人，可能會在無意中混淆他們自己、他們的客戶、以及項目的合作夥伴 (見下圖 1)。

圖 1、BIM 忽悠的第一級，X 和 Y 混淆不清

第 2 級：經驗不足或低等程度的 BIM 忽悠
 (Level 2: INEXPERIENCE or Low-Level BIMwash)

當 BIM 交付的結果跟設計要求之間兜不攏時，或者僅有某些 BIM 交付結果 (容易實現的) 與設計要求之間的連結能被理解時，此刻 "BIM 忽悠" 就因經驗不足而表現出來。
他們經常顯現出來的是把很基本的 BIM 交付結果 (諸如協調一致的圖紙或者以模型為基礎的衝突檢測) 當成是尖端的創新而全力推展。

由於缺乏實踐經驗，對這類 BIM 應用者而言，BIM 就像一座冰山，BIM 的要求/可交付結果只有很小一部分看得到，而大部分仍然隱藏在表面以下(見圖 2)。
這種缺乏經驗，在一個過度樂觀的營銷部門的手中，就會生成顯著的 "BIM 忽悠"。

BIM 忽悠的第 2 級，看到了少許，沒看到的更多

(BIMwash Level 2, seeing SOME and missing MANY)

※ 數碼阿叔註解：當前有些單位運用那些三維建模軟件的目的，可能僅限於根據完稿的二維施工圖紙建立三維模型，然後利用軟件經由三維模型進行衝突檢測了事。從實用層面來看，的確獲得了減少錯誤的效益。但是操作那些三維建模軟件跟應用 BIM 是兩碼事，運用的目標以及深度、廣度皆有所不同，不宜混為一談。如果據以宣稱自己這是應用 BIM 的實踐項目，未免……

第 3 級：誇大其辭或稱中等程度的 BIM 忽悠
 (Level 3: EXAGGERATION or Mid-Level BIMwash)

這一級是指他們的 BIM 應用能力 (BIM Competencies) 實際上是存在的，但是蓄意推進到遠超過他們實際的能力水平。就好像講述一個真實的故事中，還特別穿插一些好萊塢特效在上面 (見圖 3)。
說一個誇大其辭的例子，在一個全國性的實踐項目中，通過其對 BIM 能耐的陳述、網站或博客等等宣傳手段，聲稱擁有豐厚的 BIM 應用能力，實際上他們卻是個只做過少數項目的地方性團隊，僅能部份達成指標。

BIM 忽悠的第 3 級，膨風到不成比例

(BIMwash Level 3, blowing things out of proportion)

第 4 級：錯覺或稱嚴重的 BIM 忽悠
(Level 4: ILLUSION or Severe BIMwash)

這是當 BIM 競爭能力的故事等同純屬虛構時。這種類似於印度寶萊塢電影中的情節 (所有的歌曲和舞蹈都是豐富多彩的，並且把場景表現得很有趣)，但實際的故事中從來沒有、並且可能永遠不會是真實的！
當一個 pre-BIM 服務供應商冒充能高度勝任 BIM 的專業者，競標成功並且獲得一個規定要用 BIM 的大型項目[14]，在 “BIM 忽悠” 的錯覺下，真實的能耐和嚴重的無能是難以區分的。

BIM 忽悠的第 4 級，推展不存在的東西！

(promoting what does not exist!)

(Deception 欺騙 / Misrepresentation 誤傳)

總結 (In Conclusion)

就像在此之前的 "綠色忽悠" (Greenwash) [15] 一樣，"BIM 忽悠" (BIMwash) 預計會在市場裡增殖擴散，這主要是由於要求以 BIM 交付結果的大客戶數量爆增。在缺乏獨立評估/認證的情況下，給了 "BIM 忽悠" 們絕好的機會，藉著運用「對 BIM 能耐的創造性說詞」，讓那些實際上得來不易的真正 BIM 應用能力變得難以區分真假，使得建築市場發生扭曲。因此，要檢測出 "BIM 忽悠" 首先重要的一步是要認清它的搞法，才能循跡叫他們現形。作者 (Bilal Succar ) 在未來的 BIM 文集裡，將描述幾種方法跟它鬥爭，並且就長遠而言——抵消 BIMwash。

原帖註解

[1] 本博客文章是在澳大利亞的 RTC 於 2011年 發佈 BIMwash 參考資料的延伸。根據收到的反饋評論，這個主題涵蓋了兩三個帖子。
[2] BIM 的主張 (BIM Claim) 是個人、單位或項目團隊選擇公開標識其 BIM 應用能力的程度。
    (※ 這裡說的 "主張" Claim，指的是宣稱的工作能力和因此等價要求的報酬)
[3] BIM 應用能力 (BIM Competency) 是結合了 BIM 能耐 (Capability) 和成熟度 (Maturity) 的一個術語。
    BIM 應用能力可以用於描述個人、單位以及項目團隊。
[4] 如果 BIM 的主張 < BIM 的應用能力，則錯過了市場機遇！
[5] 這也適用於組織 (單位) 和群組 (一個組織內的小的群體)。
[6] BIM-勝任 (BIM-Competent) 組織和BIM-備便 (BIM-Ready) 組織之間有一個重要的區別，BIM-備便組織是那些有能耐交付高品質的BIM產品/服務，但尚未獲得必要的實踐經驗。
[7] 雖然個人的 BIM 主張很容易檢測，提供招聘/面試是 BIM 的主管，仍然常見的是招聘機構不評估應徵者的 BIM 應用能力 (BIM Competency)，他們應該越嚴格越好。
[8] 例如：兩個或兩個以上的組織，聯合提交一個項目的標書或參賽作品。
[9] 採樣的準則：協調良好的基於物件的模型，免於建模誤差，可施工性，必要數據的豐富程度，按正確的詳細等級建模，優化模型大小/性能，在一致/標準的基礎上的命名架構......等等。
[10] 採樣的準則：架構良好的 BIM 執行計劃，由知識淵博的高級工作人員推動，以及清楚的認識到 BIM 在可適用的標準和合同承諾裡的優勢和局限性......等等。
[11]  AEC 的服務供應商是指那些向客戶提供設計和施工服務的：建築師、工程師、承包商、項目經理等等。
[12] 作者故意留下了一個國際小組，積極推動解決幾乎所有行業毛病的 BIM 方法......你能辨識該群組？
[13]  BIM 忽悠的級別係用作一種能耐和成熟度 (Capability Maturity) 度量標準，同時在描述BIM忽悠行為的混合情況時使用 BIM 忽悠的型態。
[14] 這是個真實的例子。
[15] 綠色忽悠 (Greenwash) 是對環保認證提出的不合理主張 (能力宣稱與取費)。

(全文完)

BIM反思錄(四)

作者：數碼阿叔/柏基建築師，歲次壬辰年良月寫於台北
本文原發表於作者的新浪博客，2012-10-15

人不為己，天誅地滅

　　這一集我們繼續討論關於美國那件涉及BIM的索賠案，這一集主要關注保險公司為什麼要迴避審判？不當和解會造成什麼樣的後果？我故意用了一個跟BIM扯不上邊的標題，假如您覺得這個標題很聳動，您是正常的，因為我們和社會大眾都一樣，經常會習慣於積非成是的想法，其實“人不為己，天誅地滅”這句話並不是為我們心底那份“利己”的念頭做開脫，這句話正確的含義是“一個人如果沒能做好自己份內該做的事情，那麼他將無法見容於這個社會。”如何？這個說法令您覺得好過一點吧。

　　其實，在人類的心裡，“利己”的考量永遠先於“利他”，這也就是達爾文先生在其進化論中昭示 “物競天擇，適者生存”的微言大義。利己是人的本性，同時也是競爭的原力。在我們的生活中、工作中它總是若隱若現，不時的左右我們的判斷與決定。例如早年我們都有強行過馬路的經驗，四下看看，管他紅燈綠燈，湊夠一撮人就可以開步走了，如果有大媽大爺帶頭，那就更顯得理直氣壯。想一想，利之所趨，讓我們很容易追隨著別人的行為做同樣的事，而罔顧可能發生的結果。有位好朋友說這個索賠議題是在炒冷飯，然而比起骨灰級的柯林斯柱式，這碗飯還不算太冷。即使原先那篇敘述得不清不楚的博文意在嘩眾取寵，但凡是走過必留痕跡，在案例敘述中明確指出設計團隊的MEP設計師應用了BIM，他在裡面做了什麼我們不知道，可是在這個專案裡，資訊共享了沒有？如何協同工作的？專業整合做到了沒有？這些BIM的要素似乎都沒能達標，能明確知道的只是設計方與施工方在工作中的缺陷引發了建築爭議，保險業者的做法衝撞了既有的行業責任界線，從某個層次來說，這都是基於利己生成的結果。

　　前面說過整個事件導因於“在施工過程中，當承包商組裝到大約70%的管線時，佈設的管線已經超出了悶頂的範圍。”　換句話說，還有30%的管線裝不進天花板(吊頂)裡面。

　　這時承包商為了要解決問題將面臨抉擇，第一個方式是把天花板的預定高度降低，擴大悶頂的淨高，使得悶頂裡能容納剩餘30%的管線，可是這樣做有現實的困難，天花板高度降低了，室內空間的淨高度跟著變矮了，很可能影響到天花板下方空間的適用性，甚至可能使得室內淨高度不符合建築規範的要求，並且業主也不可能答應這麼做。另外一個解決方式就是把已經安裝好的管線全都給拆下來，按照事後他才知道的特別安裝順序重新佈設，這麼做一拆一裝之間不但承包商得憑空多花一筆拆除費和安裝費，同時拆除過程中還會造成部分材料與半成品的損耗，重新佈設管線也耗掉工程完工期限，承包商將因此蒙受返工與誤工的雙重損失。並且承包商如果主動這樣做，無異承認了自己施工不當，使得他將獨自承擔所有的損失，因此必須另闢蹊徑以求自保。

　　最後承包商選擇了看起來對他最有利的辦法，一狀將業主告上法庭，理由是他認為這份施工圖顯然不合於工程常規致使他裝不進全部管線，同時提出數百萬美元的索賠要求，要求業主賠償這個部份誤工和返工的損失。業主對此傻眼之餘當然很生氣，於是轉而起訴了建築師，因為施工圖是建築師提供的，所以向建築師要求賠償。由於建築師投保了專業責任保險(PLI)，這下子出險了，因此輪到這家XL保險公司上場，處理索賠談判事宜。

　　對這個案例，保險公司的Lewis只說那棟建築物現在已經完工並且啟用了，基於為客戶保密的義務，他們拒絕透漏更具體的情況，也不願意說出當事人的姓名。保險公司這個做法完全正確，稍有法律知識的人都不會為此責怪保險公司不肯明示這件索賠案的細節，如果他們說了反而是犯法的行為。

　　Lewis說：「這是個非常高價的索賠談判。」而XL保險公司對這件索賠官司並未進行審判的程序，由於保險公司認為這種牽扯到BIM所招致的爭議事件，沒有任何先前的判例可供援引，任何陪審團可能都很難理解BIM這玩意兒究竟在工程案件中扮演的角色與過程，並且難於對此做出正確判斷(※其實說穿了，保險公司心裡沒底，擔心的是最終做出對其不利的判決)。因此在對審判結果無從預期掌握的心態下，保險公司選擇了他們最擅長的做法，居中穿梭調解搓圓仔湯，促成以金錢賠償為和解條件，做為裁決的依據，目的是把他的損失減到最小。數百萬美元的賠償金額由建築師、MEP工程師以及承包商分攤，各方分攤的另一層意思是各方都承認自己有過失，協議按照過失的比例分別攤付，讓承包商得到據以拆卸重新安裝的返工損失金額。這裡有件事得注意，保險公司處理索賠官司的做法乃基於風險管理的原則，並不是以澄清事實真相的是非曲直為出發點，而是以自己出險的金錢損失最少為目標。

　　迴避審判過程就意味著沒有從法律層面去界定事件中各當事人的責任與對錯，保險公司選擇以調解成金錢分攤賠付，更是一種和稀泥的處理方式。雖然對當事人是解決了自身問題，但是從旁觀者的立場，我們仍然要追索發生問題的人為原因，以及這個案例產生的後續影響。我們是大陸法系的國家，實施的是罪刑法定主義，法院按照具體的法令條文做為裁判的依據。而美國是海洋法系的國家，法庭會援引判例做為裁判的依據。這個首件涉及BIM的官司裁?的結果形成了判例，對於其後該州的其他類似案件都會造成一定程度的影響。

　　那麼我們從專業的角度來看，整個案件的徵結在哪裡？首先，保險公司的Lewis說：「問題在於溝通不足，設計團隊從未跟承包商談及安裝順序，並且承包商的經驗不夠老練，沒有在事先理解以一個特定的順序去裝配管件的重要性。」這是從保險公司的角度說事，這句話本身就存在很大的問題，溝通不足如果指的是設計團隊從未告知承包商關於管線排佈得非常緊密(※是否確實異於正常的排佈方式)這個事實，這能不能歸責於設計團隊我們等會兒再討論，至於安裝順序，如果設計方的施工圖上未指明管線高程，那就完全是承包商的責任。

　　在咱們這裡，工程發包決標後，有個程序叫做“技術交底”(註：這是大陸規定的程序)，通常會有一場碰頭會，與會的包括設計團隊的各專業負責人與施工單位的各個技術負責人，就設計內容進行說明與釋疑。我不清楚在美國依照他們的工程慣例如何辦理，假如這個案例也舉辦過類似的技術交底，設計方有足夠的機會在交底時知會施工方所謂“管線排列得極為緊密，必須按照特定的順序安裝”這回事。然而即使設計方真的沒說或者沒機會說，那麼他們就該為此擔負責任嗎？我認為未必！至少施工方在技術交底之前得把圖紙吃透，通常交底會上應該有會有不少問題提出來，要求設計方解釋，或者基於施工安裝的便利而要求調整，再不然軟磨硬泡的要求更改些材料廠牌、施工做法等等。如果您參加過這類技術交底會，在這個行業裡待得夠久，您可曾見過有哪一次施工方的項目經理會大剌剌的拍胸脯說一切都沒事，大家就等著去蹭會後那頓酒菜的？

　　在美國與加拿大境內執業的建築師通常會為建築案件編訂建造與施工規範(Specs)，或者使用Masterspec標準規範，就合同各方在專業上的權責義務做出規定。例如對於應用Masterspec規範的建築師而言，在Masterspec第01 31 00節“Project Management and Coordination”(專案管理與協調)的敘述中，要求總承包商/分包商必需製作“Coordination Drawings”(※指的是結構機電設備整合圖)做為資訊提交的載體，交付給建築師/工程師核查。這樣的要求旨在界定設計與施工的責任範圍，跟是否應用BIM毫無瓜葛，在施工階段跟工程施作相關的建造手段(Means)、施工方法(Methods)、施工安全(Safety)和施作順序(Sequencing)都不屬於設計建築師的管轄權責。建築師把施工圖說(包含建築、結構、MEP、HVAC…等等)提交給業主，業主據以把建築專案發包給承包商，承包商基於其專業能力，把這些施工圖說整合成為直接用於施工的製造與安裝圖說(Shopdrawing)和跟時間、成本相關的計畫，在DBB交付模式下遊戲規則就是這麼玩的。

　　換句話說，本案的承包商按照成規應該在動工前對各專業施工圖紙進行套繪整合，在製作“機電整合界面圖”(Combined Service Drawing, CSD)、“結構機電整合界面圖”(Structural , Electrical and Mechanical, SEM)及“施工界面協調計畫”(Coordinate Installation Program, CIP)這些過程中就會很清楚的覺察這個客觀的事實，難以按照設計團隊提供的施工圖紙要求，把管線全都裝進悶頂裡。接下來正常的處理程序當然是利用“資訊徵詢函” (Request For Information, RFI)把問題回饋給業主，由業主要求設計團隊澄清或者進行調整修正(※RFI並沒有固定形式，可以利用文件、Email、電話甚至當面傳達意見或徵詢，只要能留下證據進行事後追?即可)。但是本案的實際狀況又如何？承包商因何底氣十足的按照自己的想法悶著頭往下幹，終致發生裝不下全部管線的困境。這是一連串巧合和疏忽造成的意外，還是另有原因，保險公司不說我們無從得知其詳，我們只能從善意第三者的角度做出合理的推測。

　　會出現裝不下的結果顯然承包商沒有事先對本案做過“結構機電設備整合”(管線整合)，但是我認為任何承包商都不會大而化之到跟自己的鈔票開玩笑，我們不能一言以蔽之的跟著說什麼“承包商的經驗不夠老練”這種貽笑大方的外行話。各層管線的安裝高程從何而來，沒有CSD/SEM可是承包商的底氣來自哪裡，最有可能的是設計方提供的那種經由BIM建模軟體所生成MEP施工圖紙的內容，跟他們習用的整合圖類似，讓承包商誤以為設計方已經正確完成了“管線整合”的任務，自己揀個便宜就直接根據設計方的圖紙上馬施工。到現在為止有件事我一直憋著沒說，在保險公司對這個案例的敘述中，Lewis曾說過一句話：

“管線在模型裡裝得下，可是在現實中卻裝不下。”

(原文為“Everything fit in the model but not in reality.”)

　　在我看來，這正是整個事件的關鍵所在。我們做個情境模擬，這個案例是在大學裡的一座生命科學樓，供做教學、研究、實驗等等用途，假設還包含了一些實驗室(※有沒有我不知道)，那麼管線與管道系統就不僅止於給水、排水、電力、弱電、空調、消防、保安監控等等基本管線那樣單純，可能還包含其他特殊管線。當然除了幹管還有支管與設備裝置，以及數不清的吊架，各管線系統的佈設肯定變得比較複雜。

　　身為設計團隊中的MEP設計師，運用BIM建模軟體構建了MEP模型，您說這模型都建好了，他們會不會接著進行“干涉檢查”(interference checking)或者通俗說的 “碰撞檢測” (clash detection)，應該是肯定有的，許多人應用BIM的目的不就是為了這個麼？如果干涉檢查只相對於結構模型以及其它MEP模型相互間做了幾何碰撞(硬碰撞)的檢測，確認了這些管線、管道沒有跟結構樑柱衝突的地方，各管線、管道相互也不存在衝突的地方。然而這就夠了嗎？顯然是不夠的，各管線之間應該保留多少間距？這可是由MEP設計師所設定的，管線間距的決定除了規範的要求以外，更需要考量施工時的吊裝搬運、人員近接操作空間、安裝進出順序、日後維修保養人員近接檢修空間….等等，都需要把這些必不可少的空間需求轉化成各處不同的管線間距。並且，沒有預設高程如何構建管線模型？又怎麼進行干涉檢測？

　　假如MEP設計師不具備足夠的工程現場經驗，甚至沒見過管線管道在現場實際怎麼進行分層佈設、安裝銜接的全過程，那麼僅憑著想當然爾的認知去設計管線、管道，除非悶頂空間裡的高度能夠容得下跑馬，否則很容易出現本案例中Lewis所說的“管線在模型裡裝得下，可是在現實中卻裝不下”這樣的結果(※其他的技術性經驗我就不說了，否則這篇博文可能會寫不完)。正因如此，即使設計階段已經做過了管線整合，到了施工階段還是得由施工單位主導，根據每個專案實際的需要再正正式式的進行管線整合，製作CSD/SEM的程序是必不可少的過程，也是施工單位責無旁貸的責任。說到這裡，再回頭看看這個案例發生的過程，您該有點輪廓了吧？

　　保險公司表示他們一直提醒身為設計工作者的客戶，別摻和到建造手段(Means)、施工方法(Methods)、施工安全(Safety)和施作順序(Sequencing)的範疇裡面去。但是對於這個案例，由於保險公司刻意迴避審判而以調解賠償來化解訴訟，卻因此創下了設計團隊對Means、Methods及Sequencing這些不屬於其責任範圍的部分擔負了責任並且賠償的先例，這讓人覺得保險公司只求利己的做法造成了一個很不好的後遺症，這也是原先那兩篇博文在專業網站上貼出以後造成設計與建造業者激烈反彈的主要原因，這個案例的結果違反了美國建築行業一直堅守的原則(※其實也是咱們這裡設計與施工的責任分界)。BIM其實是一種協同作業的過程，鼓勵專案的各參與方進行相互溝通、協調以及提出建議，但是在這個案例中，空頂著BIM的光環卻沒有發生那些該有的效益。

　　寫到這裡您該發現這個項目建設的進行過程中，在BIM的應用上就只有設計團隊在唱獨角戲，即使運用所謂BIM軟體構建了三維模型甚至做了管線整合，最終僅僅落得生成二維施工圖紙，交付給不具備BIM應用能力的承包商，還捅出了摟子。專案建設的其他參與者諸如業主、承包商甚至運營管理單位都跟BIM沾不上邊兒，沒有業主與承包商就BIM的協同支持與合作，BIM的效益就只發生在設計團隊的內部而已，頂多還饒上生成了讓投標者難以質疑的標書與明細表，其餘整個就是傳統的專案建設操作型態(※這也跟當前咱們這裡的建築案件遇到的情況有些神似)。那麼擔任施工安裝的承包商又如何？到目前為止我們是假設承包商的專業施工能力沒有問題，所謂“沒有三兩三，哪敢上梁山”，應該不是個二楞子。但是如果承包商真的沒有套繪CSD/SEM圖紙，那是不可原諒的失誤，因為管線、管道的詳細製造圖紙又是根據什麼製作出來的？這可百分之百是承包商的責任範圍。但是如果真做了CSD/SEM，必然在動工前就會發現那“特殊安裝順序”的情況，也就不可能出現管線、管道只有70%裝得進悶頂空間的低級錯誤。對於這樣的矛盾存在，您想想，這當中是不是有人沒講真話。

　　寫這篇博文的目的不在於指手劃腳的對當事人指述誰是誰非，也沒有預設立場的為哪一方翻案。我們藉由一些合理的假設，討論設計單位與施工單位在專業上應有的做為，希望能拿這個案例的教訓做為我們日後的借鑒。從這裡也能看出應用“專案整合交付”(Integrated Project Delivery, IPD)交付模式的好處，設計、發包、建造不再以前後串列的方式的進行，而是成為重疊互補的進程。在設計階段就邀集業主、未來施工階段的各工種承包商與安裝承包商甚至運營單位加入，藉由他們提供的經驗與實踐需求，先完成管線整合以後再生成施工圖紙，這才是真正能避免返工誤工以及獲得提升工程效率的積極做法。再做最後一個假設，假如當初這個案例用的不是DBB(設計-發包-建造)交付模式，而是採用IPD交付模式進行，您認為結果會是如何？

　　BIM反思錄就寫到這裡暫時擱筆，隨著BIM的風潮與相關技術的不斷引進，潮起潮落的過程中，在那片新舊思維交替的潮間帶，還有很多值得討論的材料，日後有機會我們再繼續研討。BIM的應用自成體系，絕非買回軟體學會建模就能那麼簡單的切入現有規制當中並且運作無礙。推動BIM普及化，不能只一味訴求BIM的光明遠景而避諱討論它跟現實間的衝突與矛盾，否則難保不會歧路亡羊不知伊於胡底。子曰：「以不教民戰，是謂棄之。」我們真該用心為BIM應用的深度和廣度規劃出完整的路線圖做為發展方向的指引，軟土深掘才能讓BIM在這個國度裡真正的落地生根。

BIM反思錄(三)

作者：數碼阿叔/柏基建築師，歲次壬辰年良月寫於台北
本文原發表於作者的新浪博客，2012-10-11

從美國首件涉及BIM的訴訟案談起

　　在美國有一所大學興建一座生命科學樓(life-sciences building)，在施工過程中發生了訴訟案件。工程發生訴訟不稀奇，但由於這個案例涉及到建築師與MEP工程師等所組織的設計團隊在設計過程中應用了BIM，並且成為美國首次因為BIM招致索賠的案例，所以在美國建築行業中格外引起注意。在敘述事件的整個經過之前，我們先說說結論。事過境遷後，涉及這個事件理賠的保險公司Randy Lewis先生說了下面這段話：
“The creators of BIM claim its use reduces risk, and indeed it can—like any other tool, if it is used right. If you don't use BIM correctly, you can get into trouble.”

我把他的意思試譯成中文，可以這麼說：
“應用BIM創建模型的人宣稱用它能減低工作中的風險，如果能正確的運用它，事實上就跟其他任何工具一樣，的確能減低風險。但是如果你運用BIM的方式不當，那麼你就會惹上麻煩。”

　　首先披露這個訊息的是在2011年5月，由Nadine M. Post女士在Engineering News-Record網站上發表的博文：名稱叫做《虛擬設計與施工的警示故事》
"A Cautionary Digital Tale of Virtual Design and Construction"
http://enr.construction.com/buildings/design/2011/0523-acautionarydigitaltale.asp　

接著很快的Architectural Record網站轉載了這篇文章，把標題改成了：
《BIM訴訟提供了警示性故事》"BIM Lawsuit Offers Cautionary Tale"
http://archrecord.construction.com/news/2011/05/110519-BIM-Lawsuit-1.asp

　　如果各位BIMer有興趣，不妨到上述兩處鏈接的地址去看看文章後面的那些評論(comments)，參與評論的都是身處第一線的設計與施工的從業人員，其言辭赤裸裸的沒有經過任何化妝，雖然他們中間許多並非BIM軟體的用戶，但是面對建築行業原則的堅持，其激昂的程度不亞於咱們的微博，扣除習慣於閱後沉默飄過不留鴻爪的大多數瀏覽者，這個案例受到美國建築業界重視的程度可見一般。當今世道混沌，廣告包裝鋪天蓋地，BIM和號稱total solution的建模軟體之間究竟誰在綁架誰，確實還說不清道不明。我們整天看到的是宣稱BIM能做這樣、能做那樣的種種說法，但是那些雲裡霧裡的東西可曾真的在你的工作電腦中出現過並且為你所用？凡我BIMer同志們真該多關注行業基層的真正聲音。

　　那篇博文的內容根據的是保險業者的說法，敘述索賠的原因以及解決的經過，說是對其他使用BIM的設計工作者而言是個具有警示作用的案例。文章發表以後受到美國建築業界的矚目，在兩處網站上都產生廣泛的迴響，合計出現了將近150條的評論，其中大部份評論都不認同保險公司迴避審判的搗漿糊(和稀泥)做法。保險公司基於自身利益輕率的妥協，協商的結果使得建築師、MEP工程師和承包商一起分攤了承包商在工程施作上的索賠金額，開啟了建築師與MEP工程師對原本屬於承包商責任範圍的“Means & Methods”(建造手段及施工方法)擔負了責任的判例，其影響會是深遠的。

　　整個事件發生的經過在那篇博文中敘述得很簡略，並且是從保險公司的角度來說事，因此難保有些真實的情況因為立場的關係而遭到忽視或隱匿。

　　涉及這個案例的建築物是美國一所大學新建的一棟生命科學樓，當事人包括業主(那所大學)、設計建築師(以及MEP工程師)、承包工程施工與安裝的總承包商等，當然還包括一家保險公司。保險公司是一家名叫XL保險公司的丹佛分公司，它們對領有證照的建築師與工程師提供“專業責任保險”(Professional liability insurance, PLI)。透露這個案例部份情節的正是這家保險公司裡負責預防損失與客戶教育部門的副主管Randy Lewis。

　　發生問題的原因和處理過程聽起來並不曲折，在施工過程中，當承包商組裝到大約70%的管線時，佈設完成的管線已經超出了“悶頂”(Plenum，指天花板上方直到上層樓板底的空間)的範圍，換句話說剩下30%的管線裝不進天花板(吊頂)裡面。承包商因此一狀將業主告上法庭索賠，業主轉而起訴了建築師，打官司啦！於是這家XL保險公司上場，處理索賠談判事宜。而保險公司對這件索賠官司處理方式是迴避了審判的程序，居中穿梭調解，達成以金錢和解收場做為裁決的根據。至於最後解決的條件，據說是一筆金額相當大的賠償金，共計數百萬美元，由建築師、MEP工程師以及承包商分攤。

　　承包商為何要提告？這是個好問題，那家保險公司並沒有說明原因，不過我們用膝蓋想也能想得出一個大概。按圖施工是承包商的責任，空間用完了還剩下30%的管線該怎麼辦？降低天花板？恐怕業主和建築師都會跟他翻臉。那麼把已經安裝好的那70%管線都拆下來重新安裝？那可是一大筆費用不說，耽誤了工期還得罰款。當然損失最小的方式就是選擇控告業主，我按照你發包給我的圖紙施作，管線裝不進你指定的悶頂空間裡，你得賠償我的返工和誤工的損失。最終這個問題是怎麼解決的，我猜想應該是拆下已經安裝好的管線重新佈管，否則這個官司也打不起來。如果承包商沒犯錯，那麼是誰犯了錯？

　　雖然這在美國只是個民間常見的民事索賠官司，也不涉及什麼公共危險問題，通常民事索賠官司在保險公司介入下絕大多數也都是以和解收場。然而這個案件比較特別，它是美國第一件涉及BIM應用的訴訟案件，因此倍受建築業界的重視。根據保險公司的說法，事件的導火線在於建築師與其MEP工程師運用BIM三維模型完成佈設MEP管線工作，而且在發包時，建築師並未告知承包商，這些管線排列得非常緊密(原文為“extremely tight fit”)，施工時必須遵循特定的安裝順序(原文為“a very specific installation sequence”)施作安裝。並且保險公司事後表示：

——“應用BIM創建模型的人宣稱用它能減低工作中的風險，事實上就跟其他任何工具一樣，如果能正確的運用工具，的確能減低風險。但是如果你運用BIM的方式不得當，那麼你就會惹上麻煩。”

　　保險業者說得很簡略，但是我們從建築專業的角度來看，所有的說明中並沒有對幾個重要的問題點有所澄清：
(1) 為什麼要迴避審判？不當和解會造成什麼樣的後果？
(2) 為什麼管線無法全部安裝進悶頂空間裡？設計團隊為什麼沒有向承包商做技術交底？
(3) 所謂將管線“排佈得極為緊密”是什麼意思？設計團隊是否具有足夠的工程現場實務經驗，真正瞭解管線間必須保留的間距？另外，保險業者說必須遵循“特定的安裝順序”，何謂特定的安裝順序？
(4) 整合管線該由誰做？這個案例中到底有沒有做過“機電整合界面圖”(Combined Service Drawing, CSD)、“結構機電整合界面圖”(Structural , Electrical and Mechanical, SEM)及“施工界面協調計畫”(Coordinate Installation Program, CIP)？這些都不是BIM時代才有的新東西，實際上所謂CSD/SEM已經使用不下數十年了，只是以往是利用二維圖紙透過人工計算操作，即使其精確度不及當前利用三維模型操作，但是無損其在工程中的必要性。

　　對於上述這些問題，我們得仔細掂量一下厲害關係。莫道這樣的場景日後不會發生在你我的身邊，由於專業知識的不對等，以往不論設計方或施工方在工程中捅出了摟子，因為業主方大多對工程技術不那麼在行，比較容易唬弄一下遮掩過去，反正一切現場解決，業主方即使不高興也多半摸摸鼻子罵兩聲就算了，不會認真追究。但是到了BIM時代，業主方不懂沒關係，花錢找一家懂得BIM的諮詢公司來代替業主管理專案進行，不但設計方與施工方憑空多出來一個婆婆管，而且在建築資訊模型下，一個蘿蔔一個坑，任何錯漏碰缺恐怕都無所遁形。原先施工方在圖紙與實做數量中間能沾點便宜的灰色地帶，也因為貫徹4D和5D而…沒了！利潤透明化將導致利潤緊縮，使得施工方將更加計較圖紙的錯漏和工期。見葉落而知秋意，您保證日後咱們這裡不會同樣出現訴訟的情景嗎？

下一篇博文我們將接續討論這個案例，為什麼要迴避審判？不當和解會造成什麼樣的後果？請繼續關注：BIM反思錄(四)《人不為己，天誅地滅》

BIM反思錄(二)

BIM反思錄(二)
作者：數碼阿叔/柏基建築師，歲次壬辰年良月寫於台北
本文原發表於作者的新浪博客，2012-10-9

人無遠慮，必有近憂

　　話說當前興起了一股“建築資訊模型化”(BIM)的風潮，被說成是建築業界的一次產業革命，當然也有人硬要說成是第三次工業革命，並且不加入BIM的行列就將被淘汰。(好吧！那麼在第二次的時候淘汰了誰？)　今天能跟BIM沾親帶故的各款應用軟體也如同雨後春筍般冒將出來，賣軟體的不住伸手四下招徠，訴說著俺才是老字號，一面比劃著建築世界未來的美景。變革肯定是有的，但並非起於一夕之間，而是隨著時間牽拖而漸進生成，說它是個願景也好。固然建築界中不乏冷漠以對者，他們面對任何變革的態度都依然故我，照例老神在在、不為所動。但是的確有許多建築業者看出其中的巧妙端倪而跟著上馬，他們面向BIM的態度則各有不同，其中有立馬撂了舊挑子義無反顧大幹快上的，也有那種摸著石頭過河邊走邊試深淺的，當然也有像在公園裡模仿人家打太極拳雖有形卻無神的，總是建築界中應用BIM的從業人員日漸增多，搞設計的、搞施工的、搞運營的、甚至搞投資的都有。在軟體商營銷策略的巧妙包裝下，讓已經上馬的業者咸認為有了BIM以後，就如同曾國藩在日記裡說的一樣，“從前種種，譬如昨日死；以後種種，譬如今日生也。”用上了BIM就像是走上了充滿陽光的康莊大道，但在現實中真的是如此順風順水嗎？

　　在BIM問世之前，我們使用二維CADD少說也超過了20年光陰，甚至在CAD出現之前，趴在圖板上以手工製圖經歷的年代更為久遠，二維設計和CAD真的有如推銷BIM軟體那些人所說的那麼不堪嗎？如果真是，那麼今天城市中滿坑滿谷的高樓大廈又是怎麼蓋起來的？那些房屋可曾缺隻胳膊斷條腿的嗎？實際上，二維設計載體經過多年的應用已經發展得非常成熟，並且在建築市場上早已形成了完整的運作與規範體系，相關的產業鏈之間也擁有公認的遊戲規則。如果說今天BIM的介入，搞出這種三維模型相對提升了整個專案建設的效率和品質，這一點是讓人肯定的。然而設計載體工具驟然改變，勢必衝撞既有的規制，這一點也是不容否認的。

　　當今電腦軟體與硬體的性能不斷更新，有效的實現了三維模型應用，原先存在設計人腦海中的設計構思，被移植到電腦的虛擬環境中，經由視覺化出現在顯示器螢幕上，開啟了工作整合、實時分享與協同工作的門戶，BIM帶來的真正效益在於協同工作(collaboration)提升效率而不是免除錯誤。但是人的思維終究跟不上電腦的處理速度，人很快就在大鯨魚式的應用軟體裡失卻完全掌控的能力，按下了鍵盤後，除了顯示器畫面上的改變以外，恐怕很少人清楚的知道，以自動化之名，電腦在台前幕後究竟還幹了哪些你所不知道的事情，迷信軟體萬能的後果是難以預料的。

　　在設計過程中，透過人機界面往返操作，真正改變的是這個建築案件的設計內涵。如果使用者因為迷於絢麗的軟體功能而操作失當或失格的時候，引發的問題可能比想像中更大。電腦對操作者是忠實的，默默執行命令不會偷懶犯錯，它只會在承受不了折騰的時候自殺(當機給你看)，頂多順便毀掉正在折磨它的那個三維模型。會犯錯的是驅策它的人類，人類的心智很容易被自我認同所蒙蔽，所謂“明足以察秋毫之末，而不見輿薪”。不論是輔助設計還是整合施工，如果建築工作者本身在建築上的專業基本功不足、現場實務經驗不豐，不能期望在有了電腦和BIM加持以後，就能搞出不帶“E&O”(錯誤和遺漏)的圖紙來，相反的在圖紙中可能夾藏的是自己難以覺察的深層次設計失誤。換句話說，建築工作者本身在專業水平上的能力不足和誤判，會因為使用了BIM而不由自主的曝露出來。

　　說到這裡，可能有些本著BIM至上的朋友已經按捺不住，準備把槍口指過來:「我們是搞設計的耶，要求我們具備施工層級(Construction-Caliber)的專業經驗太過份了吧？」 但我即使中槍也不得不說的是，即使你的專業水平能動手畫出一棟建築的各層平面圖和各向立面圖，但你需要的是能夠獨力畫出整棟建築從基礎到屋頂包含施工做法大樣的1/10或1/20比例外墻剖面圖(※請注意：我指的是要能符合1/10或1/20所必需具備的詳細內容)，並且要畫得跟現場實際施工結果同樣正確無誤。如果您沒本領獨力做到這一點，那麼給您BIM軟體你照樣構建不出正確的模型來。在三維虛擬環境下操作建築設計，不論您使用的是哪一路三維軟體，過程就跟在真實世界裡蓋起一棟房屋所面臨的狀況一樣，從基礎墊層一路往上直到屋頂避雷塔尖，從整體結構骨架到內外飾面細節，即使拱券山花也一樣都不能少，想要做到這些靠的是深厚的現場實務經驗積累，這是單從書本上學不到的。會建模跟會運用模型操作設計是兩碼子事，搞建築設計的如果沒有親自在工程現場待過，切切實實的“跟過”建造與安裝的全過程，您說自己設計的東西都能一筆不改的順利蓋得起來，恐怕只有您自己會相信。因而建築設計者不要把責任都推到結構或MEP設計師身上，說他們做出來的結果跟您預想的差異很大，建築設計者要有足夠的專業判斷能力，預先給結構與MEP保留出足夠的空間尺度，合理的容納結構構件與MEP管線設備，絕對不能只顧自己耍得清爽，而把那些崎角旮旯的殘餘空間丟給結構與MEP設計師說 :「就這些了，拿去湊合著用吧!」

　　應用三維軟體操作設計跟昔日運用二維軟體的實質過程天差地別(※我說的是構建三維模型“操作設計”，不是指看著畫好的二維施工圖建立三維模型那種抄圖建模的做法)。今天建築業界在某些業者急於圈地佔領市場的心態下，造成部份使用者迷信BIM這類三維軟體已經自動化到無所不能，形成了“過度期望”(Excessive expectations)和“過度自信” (Overconfidence)的迷思，以致於看起來完整的模型中卻可能潛藏著無法順利施工的隱患，而在設計當時操作設計者甚至無從判別施工可行性。模型裡的失誤，帶動信息的失準，生成二維施工圖紙的可操作性可能還比不上往昔應用CAD的年代。

　　設計載體的差異，衝撞既有的建築體制和行業遊戲規則是必然的，不容否認，當前從建築規範、管理體制到建築專案中的角色權責，林林總總都是以往基於二維設計載體(CADD與手工製圖)的運用所制訂的。今天大家都很自豪已經進入了BIM時代，是否該平心靜氣的思考一下為何要應用BIM，我們的設計與施工體制架構該怎麼因應BIM的需要而做最佳化的調整。

　　由於建築業界對BIM能耐(Capability)和成熟度(Maturity)的認知還缺乏足夠的機會去養成和磨練，對於拿三維建築資訊模型做為載體，跟現行基於二維載體的規制間存有多少窒礙與齟齬，在我們浮躁的奔往雲端的途中，甚至還沒有足夠的時間去做有系統的審視，我們建立的模型究竟是不是放諸四海皆準的建築資訊模型，還是僅止套用可視化之名做為視覺展現的三維模型。別跟我說應用在三維設計中的模型不需要精細化，不包含細節的模型必然有所欠缺或失準，如果一味削足適履的去迎合軟體性能的不足而自我設限，那麼您根本搞不清楚您的模型裡究竟缺少了些什麼？細節不足的設計在工程進行中的引爆點在哪裡？也別跟我說當前大家都還習慣於“現場調整”的那套說法，如果把這些歷史遺留的現象當成是職業上的必然，那麼應用BIM就只是個形式，比誰把氣球吹得更大。

　　BIM必須搭配適當的交付模式才能見其所長，不可諱言的，當前我們絕大多數的建築案件還是在運用傳統的“設計-發包-興建”(Design-Bid-Build, DBB)交付模式，業主分別跟設計方與施工方訂立合約，業主跟設計方之間既是合作者又是合約對造關係，設計方跟施工方之間也沒有相互依存的關聯。DBB交付模式在國內外都運用了很多年，順利執行完成的案例也多得不勝枚舉，雖然規制本身具備正面的價值，但由於在DBB交付模式下各參與方各據立場，缺乏相互信賴的基礎，在工程責任的制約下，各方也缺乏相互支援的動力。如果設計方(或施工方)讓業主產生了過度期望而忽略自己的作為能力不足，就可能導致自己惹上災難性的後果。

　　於是現今許多人開始大力提倡“專案整合交付”(Integrated Project Delivery, IPD)這種新的專案交付模式(※又是從外國引進的)，把業主、設計、施工、運營各方以及BIM一起綁進專案的設計過程中，說是成敗功過大家都有份，希望能藉此一舉解決往昔那些“無休止的設計變更、錯誤與誤差、工期拖沓冗長、生產效率低下、協調溝通緩慢、工程費超支…”等等問題，並且高調宣稱它是個完美的解決方案。的確，根據外國對IPD的定義和作法，其效益要比DBB模式相對高出不少，然而IPD要成功的實踐，參與者各方的心態能否捐棄私心，化小我為大我，能在工作上配合無間是左右其成敗的關鍵。所謂“一方水土養一方人”，這也跟各地區由來已久的建設習性、運作慣例、甚至行業潛規則都有著密切的關聯性，在外國能成功的實施不代表在咱們這裡必然行得通。(※還是那句老話，切莫拿極少數成功的案例當成業界普遍性的表現)

　　IPD說穿了這是統一陣線的做法，看起來似乎是形成了雨露均霑的利益共同體，然而私底下還是各有盤算，參與方各自都想多得些銀子，別人多賺了可不會分點給你，自己的那一份是賺是賠還得自己下功夫，實際上既是合作又是對立的業態本質並沒有改變多少。假如設計方或施工方在BIM應用中達不到原先向業主宣稱的天大效益，或者工程中出現了任何非預期的技術失誤或財務困頓致使中間有人掉鏈條或者扯後腿，誰也無法保證屆時IPD會不會半路散架子，各參與方之間會不會因此而興訟索賠。

　　別以為我只是嚇唬您，晚近就有一件在DBB交付模式下跟BIM有關聯的索賠案例，雖然發生的地點在美利堅國，但誰也不知道什麼時候我們的身邊也會出現相同的情景。有句話說“人無遠慮，必有近憂”，因此即便是未雨綢繆，我們也要仔細探討一下這個被稱為BIM索賠案首例的前因與後果，做為推展BIM應用的借鏡。

※未完待續：BIM反思錄(三)《從美國首件涉及BIM的訴訟案談起》

BIM反思錄(一)

BIM反思錄(一)
作者：數碼阿叔/柏基建築師，歲次壬辰年良月寫於台北
本文原發表於作者的新浪博客，2012-10-8

相濡以沫，不如相忘於江湖

　　當我們討論一個行業的業態的時候，應該關注的是行業裡普遍性的狀況，而不是僅拿少數企業的特別表現來說事。刻意突顯少數特別案例的成功而忽略行業普遍性的表現，只會遮掩行業真正的樣貌，對行業的整體發展和提升並沒有助益。今天我們建築業界面向BIM最大的問題是把少數個別企業的實踐嘗試宣揚成普遍性的業態水平，造成許多企業急於仿效別人外在的靚麗表現，卻忽視其內在實力的成長歷程，導致看起來光鮮亮麗的績效背後可能隱藏著見不得光的缺憾。雖然BIM的實施導則正在制訂中，當前業界裡各搞各的也沒有什麼共識和一致性的遊戲規則，但是重點在於這個行業所涉及的業主、設計、施工、運營維護等等諸多企業他們的心裡除了願景之外，是否同時擁有激情和使命感，準備好如何面對即將到來的變革沒有。BIM不是其中哪一個角色就能獨力撐得起來的，如果老想著讓別人走在前面披荊斬棘而自己跟在後面揀現成的便宜，那麼BIM在我們這裡將是沒有明天的。

　　當BIM介入建築行業運作的時候，原先存在於項目建設各階段間各自為政的藩籬無可避免的要被打開了，為了好好伺候這個建築資訊模型，讓它能有效的貫穿項目建設各個階段，包括業主、設計、施工以及運營管理等各參與方都得多做好多工作，延伸到原先不屬於他(或者說曾經遷延躲避)的工作領域。模型只是被動的資訊載體，BIM把各參與者變成用線繫在一起的螞蚱，任誰都單個兒蹦不開，唯有溝通…再溝通、協調…再協調，以及一起面對永遠解決不完的問題，這才是BIM實踐精神的所在。BIM猶如一條船，各個參與者都是不可或缺的槳手，船要航行得順利，有賴於各個參與者之間結合成團隊並且無私的協調合作(Collaboration)。今天眼看有些設計方把建立的模型捂著不交付給施工方，完工時施工方也沒有竣工模型傳交給運營方，仍然拿著二維圖紙甩給接棒的下一手。沒有開放的心態，名義上應用了BIM，實際上所幹的事跟往昔二維CAD時代沒什麼分別，從專案建設的角度來看，用兩套規則做同一件事，能說BIM帶來的效益是多麼優越嗎？是故“相濡以沫，不如相忘於江湖！”

然而，BIM絕不是安裝了軟體立刻就擁有的技能，也不是僅僅學會了建模就此蛻變成風生水起的實踐者。如果你只是想拿BIM急功近利的當成搖錢樹去賺取些機會錢，那麼在當前混沌的建築圈子裡的確可以撈到一點銀子，但是誰都看得出來這不是天長地久的買賣。如果你想拿它做為跟你建築本業一世相伴的實戰工具，那麼應用BIM的過程就會如同一條蜿蜒的長路，並非像某些推銷廣告中所訴求的那樣簡單而優雅。建築這個行業中除了業主肯定能發財以外，施工方玩得挺好的也能得些小財。至於設計方，那是個為人作嫁的角色，沒有人能經此發家致富，但是在BIM的應用中設計方卻得付出最多，所以未來還得下多少功夫才能步上正軌，如人飲水冷暖自知。在你能一拍腦袋之前，你將面對的是“理想太豐滿，現實很骨感”。

Expectation to SketchUp

作者：數碼阿叔/柏基建築師，歲次壬辰年七月寫於台北

緣起
2012年7月10日Trimble SketchUp團隊受SketchUpBBS論壇的邀請，首度訪問中國上海、武漢、廣州三個城市，除了考察參訪以外，SketchUpBBS在三個城市各安排一場跟中國SketchUp使用者面對面的技術交流研討會。7月10日在上海外灘的遊艇俱樂部舉行的研討會，從下午13:30開始一直到晚上10:00結束。
SketchUpBBS一共準備了27個議題，含括了對SketchUp在各專業領域的應用，以及使用者對SketchUp未來走向BIM的看法與期待。筆者身為SketchUpBBS論壇的資深會員，特別為此提出對SketchUp的期望做為研討議題，議題的原文如後。

Expectation to SketchUp

By Paul Pai, Architect in Taiwan,  SketchUpBBS Member: digitalarch (數碼阿叔)

● SUBIM = SketchUp + Plugins
    I have been using SketchUp as our primary design tool for 10 years (since 2002).  As an architect, I have been hoping the SketchUp team comes up with a Ruby plug-in that supplies comprehensive BIM functionalities.

我把SketchUp做為主要設計工具已達10年(始自2002年)。從一個建築師的角度，我希望SketchUp開發團隊能發展出Ruby外掛插件，賦予SketchUp完整的BIM功能。

〖說明〗
Despite of the fact that some people, due to unfamiliarity to SketchUp or other reasons, think SketchUp is only capable of conceptual design, many architects and designers like us have already been using SketchUp for the stage of schematic design and design development. With the help of LayOut of other CAD software, we can also produce construction document with SketchUp. In fact, SketchUp has always been the primary design tool, rather than just a sidekick.
In recent years, Building Information Modeling (BIM) is flourishing, forming a revolutionary wave in the architecture industry, and the China market will not be an exception. The China government is already on its way to settle down regulations for BIM implementation, and BIM may become a requirement in 2 years. With the raising of BIM, the BIM-based softwares will become the mainstream tools in the industry, and SketchUp can not be absent. We hope that the value of SketchUp can be extended to support BIM implementation.
However, it does not mean SketchUp needs to change its core functionality for BIM. We hope that SketchUp Pro can be enhanced to provide BIM functions via Ruby plug-ins, to keep the flexibility.

雖然有些建築業者、學者和軟體供應商，由於對SketchUp的功能一知半解或者基於其他目的，仍然堅持SketchUp僅能應用在建築概念設計(Conceptual Design)上。但是這些年來建築行業中的確有許多建築師和設計師不這麼認為，他們除了把SketchUp用在概念設計階段，還延伸到方案設計(Schematic Design)和深化設計(Design Development)階段，並且運用SketchUp搭配LayOut模組或其他CAD軟體，去完成建築施工圖說(Construction Document)。事實上SketchUp一直是許多建築設計工作者的主要設計工具(而不是製圖工具)

近年，建築資訊模型化(Building Information Modeling, BIM)在建築業界被炒得火熱，形成全球性的變革浪潮。當前中國的建築業界也無可避免的身處其中，推想在可預見的未來，基於BIM的建模軟體勢將成為建築行業的主流工具，政府正在制定BIM的實施標準，兩三年後可能會要求建築行業必須把BIM應用在工作中。我們不想SketchUp在這場變革中缺席，或者被摒除在主流設計工具之外，期待SketchUp的開發團隊能把SketchUp的功能擴展到BIM的領域，使我們能繼續把它應用在建築生命週期的各個階段。

全世界使用SketchUp的設計師數目可能超過了百萬以上，雖然其中大多數是在跟建築相關的專業領域裡，然而SketchUp是個面向多種設計專業的三維設計軟體，用在各種不同專業的設計師手中都是為人稱道的設計工具。因此我們認為不必為了BIM而更改SketchUp既有的核心程式，保持它與生俱來的高效率操作性，繼續讓SketchUp跟設計師的思維能同步運行比什麽都重要。我們的建議是強化SketchUp Pro版的功能，經由Ruby插件來賦予SketchUp完整的BIM功能，由使用者自己來決定怎麼有效的使用它。

● Building Information Modeling
    In our interpretation, a BIM model satisfies the following two criteria:
1. It must be an object-oriented, three-dimensional representation of a building.　
2. It must consist of some additional information about the objects beyond the  graphical properties.

我們認知，所謂BIM模型需要具備下面二個特徵：
1. 它必須是一種基於物件導向、以三維表示的建築物。
2. 模型物件的屬性中必須包含圖形以外的特定建築資訊。

〖說明〗
SketchUp has leveraged the advantage of geometrical faces to the maximum. We can create a detailed skyscraper model in less than 100 kilobytes, as it only consists of the visual information of the building exterior.
However, when it comes to practical architecture design, there are three essential criteria to satisfy:

1. Architectural Object: These visual elements have to be grouped into architectural    objects, such as predefined walls, windows, etc.
2. Data Association: Each object has to associate to its material and physical   properties. For example, given a wall object, we need to keep track of its materials of construction, strength, weight, noise rate, heat transfer rate etc.
3. Calculation and Query: In the later stages of design, we have to do aggregated    calculation and object query based on these properties. For instance, we may need to sum up the total volume of walls of a certain material, or to retrieve a list of objects that involve the use of a certain material in the model.

The challenge is, SketchUp model elements are not object based at the core. When we use push/pull function to generate a "wall", instead of a real wall object, it just creates 6 faces visually shaped like a wall. In addition, we also need to keep track of the physical properties of the wall, such as its materials of construction, strength, weight, noise rate, heat transfer rate etc.

With the current SketchUp. A possible way to work around is to support the object model via the use of Dynamic Component, and put the material information in Component attributes. However, with this approach, we will stuck at the stage that requires data manipulation.

We don't have a solid solution on how we can achieve the requirements yet. A wild guess could be handling the data externally by a 3rd party program, with Dynamic Component providing callbacks upon model changing and API for making changes　back to SketchUp, so that the state of both sides can be synchronized via a plug-in as a bridge. In this way, SketchUp probably doesn't have to change much, while users can pick up their own backend BIM implementations.

SketchUp在三維模型上極致發揮了幾何面的效益，我們可以構建一座百米高樓的模型，看起來精緻得栩栩如生，卻只有一層薄薄的外殼表皮，內部空空如也。整個模型檔案的大小可能不到100 Kb，在Google Earth上你總會發現滿是這種型態的模型。否則如果拿那種動輒超過數百Mb的三維資訊模型栽在GE上，我不相信Google Earth還跑得動，更別說拿來利用3D模型做什麽GIS定位了。

但是在實際的建築設計應用中，需要構建的設計模型並非僅僅是一層薄薄的外殼表皮或者粗略的體塊。我們的模型包含了建築物內外部所有的建築構件，從樑、柱、牆體、樓板、屋頂、門窗、樓梯、欄杆…等等，甚至包含建築設備的細節，同時在模型的面(face)上也賦予了適當的表面紋理(texture)，通常我們不是僅只簡單的使用顏色(Color)，而是使用真實的材料紋理圖像(texture image)。

一向以來，經由SketchUp建立模型不是運用所謂"基於物件"(Object-based)的方式，也就是說在建模的過程中並非運用"牆"命令去創建一堵牆，或者運用"柱"命令去創建一根柱子。說得清楚一點，例如我們在SketchUp裡利用"Push/Pull"命令拉伸出一堵牆，實際這堵牆只是由6個面(Face)連接成"牆的形狀"，除了視覺上的主觀認知以外，在模型的數據庫(database)裡並不記錄或生成什麽跟這堵"牆"(Wall)相關聯的性質(properties)。即使你選取了這堵牆，你也無法得知牆體的構造材料、強度、重量、隔音率、熱傳透率和耐火時效等等特性。

原因是這堵牆的性質此刻並不是一個"物件"(Object)，可是當我們把它定義成動態組件(Dynamic Component)以後，它就具有了物件的性質。實際上當前那些所謂基於物件的件的BIM建模軟體所建立的模型構件(Model Elements)，骨子裡也都是些組件(Components)和組裝件(Assemblies)，利用相同的方式由程式建立，並附加了許多預設的屬性值和相應的編碼。我們可以從另一個角度來看，SketchUp的動態組件功能很大程度的能滿足這種需要，但是得預設一些必要的屬性欄位和內容，這些屬性值也就是這個模型構件所攜帶的建築資訊。在接下去的設計、施工以及使用階段中，我們適當的提取這些資訊，有效的用於設計、模擬(simulation)、分析(analysis)、乃至於估算、排程等等，這樣就能符合建築資訊模型化BIM的目的要求。

● Object-based Model Element
    We hope, via plug-ins, we can create architectural objects (like wall, column, beam, slab, roof, window, door, etc.) directly in SketchUp, while assigning each model element a global unique object identifiers (OID) with a naming convention based on the classification given by UnitFormat II and MasterFormat.

我們期望，經由插件能在SketchUp裡直接建立"建築物件"(例如：牆體、柱、樑、樓板、屋頂、窗、門…等等)。對於Model Element賦予"全球唯一物件識別碼"(global unique object identifiers, OID)，並且參照AIA E202-2008 BIM Protocol Exhibit的要求，運用UniFomat II和MasterFormat對物件進行分類和命名。

  ● Query and List　
    It would be great if SketchUp provides a constraint query/listing function, so that user can retrieve target elements or aggregated values from the model. (For instance, the count of windows of a specific type, or the total area of building exterior tiles.)　

建議SketchUp能提供查詢和輸出明細表的功能，使得使用者能從明細表進行計算和估價。
(例如：計算模型裡某型窗戶的數目，或者統計所有貼磁磚外牆的面積等等)　

● Import / Export IFC file
    As the members of consulting team may use different software, we hope SketchUp can supply import/export functionalities from/to IFC file format, so it would be easier to communicate with other software.

設計顧問團隊的成員可能使用不同的軟體，我們期望SketchUp提供導入和導出IFC格式的功能，以利於跟其他軟體進行溝通。

● LayOut
    We hope we can insert Microsoft Excel file (perhaps .xlsx) into LayOut, in addition to Skp, image, plain text and RTF text.

對於LayOut模組，除了可以插入Skp模型、Raster Image、Plain Text和RTF Text等文件格式以外，我們建議能增加插入Excel表格(例如.xlsx試算表)的功能。

〖說明〗
The feature of Scene (Page) is one of the best features in SketchUp, regarding to BIM design. In many other BIM softwares, only a few fixed views are provided, so that users are forced to work on model from restricted viewpoints. Unlike those softwares, in SketchUp, user can freely decide the view, and freely orbit and zoom in/out the scenes. These scenes correspond to the drawing sheets in the old 2-dimensional CAD design methodology and serve as pivots to create different architectural documents. For example, to create a Construction Document, a SketchUp user would import the scenes into LayOut, set up print size, add a frame, legends, text comments, and eventually turns it into a formal document.

As LayOut can be used to create such documents, there is a common demand to enhance it to work with data tables and charts. Therefore we are also looking forward a possibility that LayOut can integrate with Excel.

往昔建築界應用二維CAD表達設計內容，不惟圖形數目很多，並且每個圖形(Drawing file)就只對應一張圖紙(Sheet)，個別製圖和改圖的過程中容易造成遺漏和各圖面內容不一致。
晚近，當所謂BIM建模軟體出現以後，在軟體供應商的一再宣傳下，眾多使用CAD的設計師驚喜的發現，BIM建模軟體在三維模型上預設了能對應平面、立面、剖面等等的各種"視圖"(View)，使用者可以從任一個視圖去修改模型，想當然爾其他視圖中顯示的內容也跟著改變。從這些視圖導出二維設計圖紙自然避免了圖形內容不一致的錯誤，減少了更改設計時的工作量，實際上也成為許多設計師改用 BIM建模軟體製圖的動機。
然而這種被說成史上初見的好功能，對於SketchUp的使用者來說，並沒有引起什麽刺激和興奮。因為"視景"(Scene / Page)頁面從多年前就始終是SketchUp固有的功能，每個設計師在工作中都會創建多個不同角度和觀視範圍的視景，並且在編輯過程中可以任意的環視(Orbit)和縮放(Zoom)操作視景。真正的三維設計軟體是能讓設計師按照自己的思維自由操控模型，而不是勉強自己去適應軟體程式設計者的操作想法，或者只能在固定比例的視景中工作。如果在應用三維設計過程中，設計師還是以傳統製圖習慣在平面視景上工作，那又何能算是三維設計呢？

SketchUp輸出二維圖紙(drawing sheet)的方式，和那些BIM建模軟體採用的方式有所不同，SketchUp並非從模型的視圖(View)直接輸出二維圖紙，而是透過LayOut模組操作。設計師完成精確的模型細節以後，從模型中把需要的"視景"(Scene)分別導入到LayOut裡，設定圖紙大小、加上圖框、尺寸標註、文字註解等等，最終輸出建築施工圖。
關於製作建築施工圖說(Construction Document)，除了應用到圖形、圖像和文字說明以外，設計師還會應用到各種表格和明細表類，諸如面積表、門窗清單、工程材料清單、估價表等等，因此很需要LayOut能具備插入Excel試算表的功能。

● "Partial" X-Ray Mode
    We hope there is a "partial" X-Ray mode that transparentize only user-selected objects.

我們期望SketchUp的X光模式能針對使用者選取的物件顯示成透明或不透明。

〖說明〗
In the process of architecture design with BIM, it is often necessary to view only the objects of a certain types. In the X-ray mode of SketchUp, we can make all the faces semi-transparent, but there is no way to keep a group of objects opaque and the others transparent. It will be great if, perhaps in a new X-ray mode, user can select the objects he wants to keep opaque and show the texture, and leave others transparent.

開啟SketchUp既有的X光模式以後，模型中所有的表面(face)都顯示成半透明狀態，讓我們能透視到原先被表面遮蔽的模型內部，並且可以選取到位於內部的構件進行某些編輯。SketchUp的X光模式是全域性的，它無法只針對某些部份顯示成透明，換句話說，也無法讓某些部份維持原先顯現表面材質的不透明狀態。

當詳細的模型構建完成以後，有些模型構件會隱蔽在模型內部，例如被澆灌在混凝土樑柱內部的鋼筋，或者被封閉在管道井內部的管線等等。在實際應用中，我們有很大的機會需要把場景切換成可以透視到建築構件內部的狀態，方便經由視覺回饋檢查那些被遮蔽的物體，然而在SketchUp既有的X光模式下內外部都變成了透明狀態，反而不利於看清楚位於內部的物體。

因此我們需要增加一種新的X光模式，讓使用者能選擇那些部份顯示成透明(例如上圖中樑柱混凝土部份)，而其餘的部份(例如樑柱內部的鋼筋)維持不透明狀態，並且顯現出其表面材質。

● SketchUp can do more than visual representations.
     SketchUp不僅僅用於視覺表現。

    Model creator: digitalarch,  SketchUpBBS member,  2008

● Our members have done more.
     我們的會員已經做得更多。

   Model creator: zfbim,  SketchUpBBS member,  2009

    Model creator: zfbim,  SketchUpBBS member,  2009

● The Future:        
    • Visualization　
    • Integration　   
    • Coordination　
    • Construction　
    • Maintenance

Trimble SketchUp團隊首次參訪中國紀實 (2012年)

作者：數碼阿叔/柏基建築師，歲次壬辰年七月寫於台北

Trimble SketchUp團隊首次參訪中國紀實 (2012年)

SketchUp目前是全球最受歡迎的3D設計建模工具，截至2011年統計全球已經有3000萬的使用者。也成為中國建築規劃設計行業裡使用率最高的三維應用程式，可以說是每個專業設計師必須掌握的設計工具。

2012年４月26日，Trimble公司宣布從Google手中購併了SketchUp和其開發團隊，這是自從2000年SketchUp正式發表以來的第二次被購併，上一次是2006年3月Google購併SketchUp和研發它的@Last公司。對SketchUp而言，經過兩次購併並非其命運多舛，而是因緣際會的提升了功能和擴大了使用層面。

2006年Google購併了SketchUp以後，除了發行SketchUp Pro專業版之外，為了Google Earth建模的需求，另外發行了免費版的SketchUp，使得SketchUp在全球快速的普及開來。SketchUp的專業版由於價廉物美，在世界各地被設計師廣泛採用，做為三維設計的首選工具，也讓被CAD糾葛不清許多年的"設計"和"製圖"正式的劃清了界線。以往許多設計師拿SketchUp操作三維設計，接著利用CAD輸出二維圖形，等到SketchUp專業版提供了LayOut模組以後，將二維圖形鏈接在三維模型上，跟著模型同步更新，實際上消除了以往運用CAD輸出二維圖形時個別修改圖面的問題。

市面上跟設計相關的應用程式很多，在網際網路上的諸多討論中，從一些使用者表達的意見中可以發現，有的軟體被使用者認為好學易用，有的卻受到的批評多於讚美，甚至有人認為像是被軟體發展商綁架了不得不用，為何會有差別？人的因素，也是軟體的因素。有些人操作軟體工作時，只知道遵循軟體開發者的思維，舉凡軟體現有功能涵蓋不到的，就認為是使用上的禁區，這是人的因素。軟體的操作方法和過程是由其編程者建立的，而有些軟體的界面複雜，加上編寫程式界面者的操作思維未必適合使用者既有的思維習慣，造成使用者必須改變自己去適應軟體。因此一個應用程式好不好用，使用者和軟體本身都負有一定的責任。大家都知道這個世界上從來沒有出現過功能完備並且無缺點的應用程式，應用程式本身是否能適應其目標市場的真正需要，得看應用程式的界面是否貼近使用者原生的習慣，以及具有足夠的開放性，讓使用者能根據個別的需要去增減或訂製操作功能，真的不需要軟體發展商去越俎代庖。

SketchUp本身的核心程式很小，不挑電腦硬體的等級，唯一比較奢侈一點的要求就是得配上一塊中階以上能有效支援OpenGL的好繪圖卡，用來運行其實時著色顯像的操作要求。SketchUp內建了Ruby API，讓使用者能根據自己的需求寫出擴充或延伸功能的外掛插件(Plugins)。Ruby是個開放原始碼的程式語言，是可以自由取得的免費軟體工具，也不需要再另外購買昂貴的SDK進行程式編譯。Google不斷在完善SketchUp的Ruby API(應用程式界面)，所以這幾年下來使用者和第三者團體不斷的開發出各種功能的插件，迄今已經有了八百多個插件，其中大部分可以讓使用者免費下載使用。跟市面上其他套裝軟體相比，SketchUp無疑更貼近讓使用者按照需求個別訂製功能的目標。Google公司購併SketchUp以後的另一個作為，就是創造了世界上最大的3D Warehouse模型庫，這是個公用模型庫，讓使用者自由上傳與下載分享模型，磁吸效應吸引了許多建築構件與設備製造商，構建了攜帶其產品資訊的SKP模型，上傳到這個模型庫裡提供選擇採用，儼然取代了傳統的廣告與服務通路。

從2012年6月1日起，SketchUp正式成為Trimble系列的一員，Trimble公司成立於1978年，總部設在美國加利福尼亞州桑尼維爾市，共有3600名員工分佈在全球18個國家。同時也是著名的BIM軟體Tekla的供應商，Tekla本身在全球擁有5000多家客戶，跟Trimble的工程預算、專案管理和BIM-to-Field，加上新加入的SketchUp，未來將整合成完整的AEC應用串列。

受SketchUp中國官方合作論壇SketchUpBBS的邀請，Trimble的SketchUp團隊中主要成員於2012年7月10日首度訪問中國。作為主辦方的SketchUpBBS論壇除了安排參訪活動以外，並在上海、武漢、廣州三個城市各舉辦一場面向SketchUp與BIM的設計師論壇，讓來訪的SketchUp團隊成員們跟各地前來的設計師們面對面的研討和技術交流，了解SketchUp在中國的應用現況，以及其未來發展的方向，尤其中國眾多使用者對於未來促使SketchUp走向BIM的期待。

此次來參訪的SketchUp團隊主要成員包括：
Product Manager (產品經理) John Bacus
Global Channel Manager (全球通路經理) Steven Dapkus
Global ATC Manager (全球ATC教育訓練經理) Shara Rice
China Program Manager (中國項目經理) Sophie Feng

SketchUp團隊在中國的活動內容如下：
(1) 7月10日在上海外灘遊艇俱樂部，由SketchUpBBS舉辦 "Better SketchUp, Better Design" 技術交流研討會，一共準備了27個議題，請來二位精通SketchUp的博士使用者做同步口譯。
(2) 7月12日在武漢，上午訪問華中科技大學中國首屆BIM工程碩士的教學點，下午在武漢大學由SketchUpBBS和渲影公司共同舉辦武漢設計師技術交流研討會。
(3) 7月13日在廣州大學由優比建築諮詢有限公司和SketchUpBBS共同舉辦技術交流研討會，內容包括BIM戰略專家何關培先生介紹中國關於BIM標準制訂情況和中國BIM發展需求狀況。SketchUp團隊向中國客戶演講了"SketchUp in U.S, Past and Future", "Welcome aboard SketchUp ATC"等主題。

在7月10日上海的交流研討會中，SketchUpBBS的會員鍾凡(zfbim)先生就其多年應用SketchUp在MEP方面進行BIM化的研究心得進行報告。
在7月13日廣州的交流研討會中，SketchUp團隊提出美國知名的Turner Construction公司，他們自行開發Ruby外掛插件把SketchUp應用在建造施工管理過程中的案例，顯示SketchUp具有足夠的潛力，利用插件增益其功能，在設計與施工的過程中達成建築資訊模型化Building Information Modeling的應用要求。

Turner Construction公司的案例見SketchUp官方博客：
http://sketchupdate.blogspot.tw/2012/01/sketchup-pro-case-study-turner.html
http://sketchupdate.blogspot.tw/2012/02/pro-case-study-turner-construction-and.html
http://sketchupdate.blogspot.tw/2012/02/pro-case-study-safety-training-with.html

千江有水千江月

作者：數碼阿叔/柏基建築師，歲次壬辰年二月寫於台北

千江有水千江月

Building Information Modeling (BIM)，在臺灣被譯成「建築資訊模型化」，在大陸被譯成「建築信息模型」。不管怎麼說，這個由洋人搞出來的東西，這幾年傳到咱們中土以後，對這裡開始產生重大的影響，稱它為一次「建築革命」並不為過。相對於30年前甩開圖板搞設計拿CADD取代傳統手工製圖的過程，說起來那次引進CADD軟體和電腦工作，並沒有改變傳統的觀念和做法，不論從二維演繹三維的建築設計方法、二維圖紙表達的內容等等都跟沿用了百年的手工製圖表達方式相同，僅只把手工換成電腦而已。然而這次引進BIM，則將對建築行業影響深遠，不論在東西方，這都是建築行業無法逆轉的進化進程，其結果將是一次跟物種演化同樣的結果——優勝劣敗，最終必然會淘汰掉一批閉關自守的或跟不上革新步伐的建築從業者。

那麼BIM究竟是什麼？我們不妨從這些角度看：
【應用BIM的目標】：在建築生命週期的各個階段，以三維模型做為載體，實施資訊傳承，對建築物進行最佳化的處置。(※講得白話一點就是要省錢、按時完工、提高品質啦！)
【BIM的載體】：電腦生成的三維模型(※建築構件要符合組件化的特別要求，例如牆、柱、樓板、門窗…等等)
【BIM的本質】：嵌附在模型上的"建築資訊"(包括各階段幾何的和非幾何的資訊)
【BIM的工具】：電腦和能建立這種建築資訊模型的建模工具軟體，以及延伸作業與協同作業所需要關聯性軟硬體。

說實在的，推動BIM出力最多的其實是幾個外國的軟體發展商，在經過多年努力的研發和整合後，把原先的CAD蛻變成為所謂的「BIM建模工具軟體」，自動化了許多關聯性的功能，形成一種特別的軟體體系。為了推銷他們的軟件，花了不少銀子鋪天蓋地的來這裡做宣傳，在推銷軟體的同時也把BIM的概念順利導入古老的東方，給這裡開啟了新的思維，衝擊了原先沿用已久的建築規制。

能建立「建築資訊模型」的建模工具軟體？這東西引起了很大的關注，許多人都在審視自己用得順風順水的工具軟體到底算不算是這種類型的軟體。當然為了商業利基，只要經營的項目能跟BIM沾上點邊兒，有些軟體公司也紛紛響應，宣稱自己的軟體原本就是BIM軟體，只是以往沒使用這個名詞而已。這倒也無可厚非，世上從不存在完美的軟體，只要對BIM的應用有利，怎麼個說法都行。但是，對於軟體的使用者來說可就不一樣了，假如只建立了三維模型，卻不帶有必要的建築資訊，或者嵌附了資訊但在專案中卻從未萃取和使用資訊，那麼硬要拗成「我做的這專案是BIM」，說得過去嗎？

不可諱言的，在建築生命週期的各個階段對建築的設計、施工乃至於運營管理的各操作過程中，要處理各種三維模型、二維圖形這些設計載體、Data base以及各階段knowledge management都是令人煩心的事情。因此對於用做基本載體的三維模型能不能快速而有效率的創建起來，並且能夠即時的派上用場，對於整體的效率而言是至關重要的。
竊以為，做為一個每天都要使用的工具，其先決條件是「好學易用」，讓使用者能隨心所欲的駕馭工具，而不是被工具綁架，像上了賊船般被工具處處牽著鼻子走。市面上各個BIM建模工具軟體究竟好不好用，我不表示意見。而關於SketchUp的易用性，我拿一個真實的故事來說明。

2011年底，在臺北市東區的世貿中心正舉辦資訊電腦展覽，這是電腦人年度的盛會，參觀者眾，軟硬體廠商幾乎傾巢而出。我的朋友柯先生代理SketchUp銷售與教育訓練多年，循例在會場設置了展位推銷這個軟體。當他正在電腦前向參觀者演示SketchUp的時候，有一對年輕的夫妻帶著一個年紀約五歲的小女孩經過附近，小女孩一眼看到監視器上的畫面，就笑顏逐開甩著長長的馬尾蹦蹦跳跳的奔了過來，
稚嫩的嗓音說:『草圖大師，我也會！』
他的父親跟過來對她說:『妳不要亂說，那是給設計師設計房子用的！』
小女孩說:『人家才沒有亂說，幼稚園的老師有教，我們常常在玩草圖大師畫房子的遊戲！』
面對這位可能是年紀最小的使用者，柯先生覺得有趣，把畫面調成三維視景，順手把滑鼠遞給了小女孩。小女孩惦起腳尖，按著幾乎跟她手掌一般大的滑鼠，眼神專注盯著螢幕熟練的操作起來，推拉出牆壁、門窗…不一會兒就有模有樣的畫出一座有著紅瓦斜屋頂白石牆的童話式房子來。
扭頭對她的父親說:『你看吧！我沒騙你吧？』……
過後，當柯先生向我轉述這件事的時候，我由衷的佩服這間幼稚園的老師們，除了每天要穿著白雪公主那種蓬蓬的長裙照料這群猢猻之外，還能細心的想到拿SketchUp直觀的視覺回饋能力來訓練這些娃娃眼睛、手指跟大腦間的知覺協調和對形狀邏輯的認知反應。

這也就是SketchUp能進入到每位設計師電腦裡的底層原因，幾乎全圖像化的操作界面，極少的操作命令，實時顯現形體表面和擬真的材質(不必再經過Render過程)，順應人類視覺印象的三維透視視景，藉此操作者能利用直觀的視覺回饋把想到的、看到的即時體現在三維模型上，這才是真正的所見即所得。致使SketchUp成為極有效率的三維建模工具，當然也是首選的設計工具，說它就像設計師手中握的那支鉛筆，誠不誣也。

雖然當初原始開發SketchUp的@LAST公司可能只是想著拿這個軟體用於量體組合的概念設計，但是SketchUp的巨大潛能使得使用者們不斷自行發展出外掛的插件延伸它的功能，建築行業裡的使用者根本不滿足於只拿它做初期的概念設計，很早就開始運用SketchUp從建築概念設計一直做到詳細設計的階段，原先還需要轉換到CAD軟體下出圖紙，等到Google公司接手之後給SketchUp附加了LayOut模組，為用戶解決了出圖問題，使用者在LayOut裡設定好圖框，把SKP模型的視景「鏈接」到LayOut上，形成出圖所需要的平立剖面和詳圖等二維圖形，對模型所做的任何修改都會關聯性的反應在LayOut的頁面中。

接著，我們談談SketchUp官方跟BIM之間有些什麼瓜葛呢？
話說2009年3月，網際網路上披露了Google公司的Aaron Stein先生和John Bacus先生兩人間的一段電話訪談。Aaron Stein先生在Google公司裡負責的是公關的業務，而說起這位約翰巴卡斯大爺，在SketchUp圈子裡可是個響噹噹的人物，他是Google公司裡負責開發SketchUp的產品經理(SketchUp Product Manager)。在這次訪談中包含有他們間幾句重要的對話：

AFR: "LayOut2 is really touching on the the fringe of a CAD program and SketchUp Pro 7 with its new Dynamic Components is bringing sophisticated parametrics to 3D form making. And now you can add meta data to objects. Whether you want to admit it or not you are evolving SketchUp Pro 7 into a building information modeling system (BIM). Is this Google's back-door approach to entering the BIM market?"
『LayOut 2算是真正搆上了一個CAD應用程式的邊，並且SketchUp Pro 7挾著新的動態組件把先進的參數化帶進3D造形，現在你可以把原型數據加進物件裡面。不管你是否接納這個說法，你正把SketchUp Pro 7演變成「建築資訊模型化」(Building Information Modeling, BIM)的系統。Google是否在背地裡設法進入BIM市場？』

JB: "We have always said we had no intention in going head-to-head with anybody in the CAD or BIM market. We are not trying to be another BIM. What we want to do is build on our strengths in conceptual design and modeling."
『我們一直說，我們沒打算跟任何人在CAD或BIM市場上拼刺刀，我們並不試圖變成另一個BIM，我們想做的是在概念設計(Conceptual Design)與建模(Modeling)上建立我們的力量。』

AFR: "Can't third-party developers start building out tools that bring architectural BIM functionality into the SketchUp 7 eco-system? Already we are seeing energy analysis tools compatible with SketchUp models. All you need now is a space object."
『難道第三方開發者不能為此開發出工具程式，把建築的BIM功能帶進SketchUp 7生態系統中嗎？我們已經看到能量分析工具跟SketchUp模型相容了，現在所有你所需要的是個空間物件。』

……………………..(節錄自ZFBIM在SketchUpBBS論壇裡的帖子)

先說說2009年3月訪談當時的時空背景，那時SketchUp 7版剛上市不久，在它的Pro專業版中首次增加了"動態組件"(Dynamic Component, DC)模組，它運用了Web Dialog的技術開發界面，能以參數化(Parametric)的方式操控模型，使用者可以經由DC給模型物件設置屬性，當然更可以利用開放的Ruby API介面開發出外掛的插件(Plugins)，用於給模型物件嵌附特定的屬性內容(幾何性的和非幾何性的)，也就是所謂的"資訊"(Information)。許多SketchUp的使用者在此看到了陽光，因此在訪談中Aaron Stein有此一問。

按照John Bacus的說法，明確的否定了讓SketchUp走向"建築資訊模型化" (Building information modeling, BIM)的可能性。在列強環伺爭相搶食BIM大餅的時刻，Google公司小心翼翼的對SketchUp畫地自限，想避免去跟那些號稱BIM的軟體發生頭頂頭、拼刺刀的白刃戰。在市場定位上他們打算把SketchUp局限在佔領概念設計與建模市場的制高點，這種商業經營的心態我們可以理解，可能當時他們還沒意識到從他們手裡創造出來的SketchUp潛能有多巨大，當然另外一種可能就是他們愛惜羽毛，不願意陷進開發BIM應用程式的泥淖中，如果在軟體半生不熟、處處蟲孔的時候就迫不及待的推上市場搞錢，既對不起SketchUp的千萬使用者，也壞了他們老谷家的名聲。

這檔事就此結束了嗎？ 沒有！
到了2011年11月10日，在上海舉行了一場「2011中國谷歌SketchUp Pro研討會」，當然這次研討會老谷家的巴大爺也來啦！那天下午我看著咱們SketchUpBBS的老大在現場透過微博直播研討會的內容，巴卡斯大爺利用一系列燈片向與會者展示SketchUp Pro的諸多應用。其中有一段內容是這樣的：

「There are over 2 milloin "3D experts" using SketchUp every week.」
「Is SketchUp Pro BIM?」
「BIM is a process of design(設計), analysis(分析), communication(溝通) and validation(驗證).」
「…just what SketchUp Pro does best.」
「Single-model BIM.」
「Federated Models.」
「One model=one tool」
「The right tool for the job.」

對比之前他所說的：『…BIM？咱老谷家不淌這渾水！…』
何以才三年不到的光陰，巴卡斯大爺竟然態度丕變，對於拿SketchUp Pro用做"BIM工具"變得這麼底氣十足？

不奇怪！有道是：「台上唱戲的耍賴不唱，台下看戲的不依不饒，自己粉墨登場」。
大家都知道SketchUp具有開放介面Ruby Extension，在這方面Google的度量很大，不但持續開發也完全公開Ruby API所有能應用在SketchUp上的Method和Class。SketchUp不缺的就是在世界各地都擁有自願為它進行插件程式設計的好手，並且粉絲們提供的插件其中大部份都是免費自由流通的，這讓SketchUp的延伸功能與時俱進。

由於SketchUp在建築圈子裡被廣泛使用，市場占有率不斷擴大，眼看如火如荼的利基，這幾年中許多大型的軟體先後主動的對它伸出手，提供了銜接介面，甚至內建直接讀取SketchUp模型格式的功能，使得基於SketchUp建模的應用領域急速的擴大。下面這些是眾所周知能夠支援SketchUp延伸應用的軟體：

[ NREL/DOE OpenStudio ]
(由美國能源部國立再生能源實驗室發行的專用插件，把SketchUp做為EnergyPlus的圖形驅動介面，EnergyPlus是做什麼用的，瞭解HVAC專業的人都很清楚)
[ IES VE-Ware ]建築性能模擬
(IES plug-ins to SketchUp, Integrated Environmental Solutions, global thought leaders in measurable sustainability, whole-building annual energy and carbon usage tool. )
[ Synchro ]
(4D Solution for project production planning, scheduling, resource management and comprehensive virtual 4D construction simulation.直接讀取SketchUp的SKP模型 )
[ Modelur - Parametric Urban Design for SketchUp ]
(參數化城市規劃設計)
[ Technion Suntools SketchUp Plug-in ]
(日照模擬插件)
[ Trelligence Affinity ]
(seamlessly fits into common project workflows through seamless integration with key BIM, design, and sustainability analysis tools, including SketchUp )
[ D-Studio XD Virtual Builder ]
(4D Virtual Builder for Sketchup is a part of the full xD Virtual Builder product line. A software family to integrate and synchronize all technical project data into one BIM model, ready for analysis, reporting, monitoring)
[ Inglobe Augmented Reality Systems ]
(With AR-media Plugin, Google SketchUp users are allowed to visualize their 3D models using Augmented Reality directly in the real physical space which surrounds them. AR-media allow companies, organizations and people to interact in novel as well as more efficient and natural ways as to satisfy their needs through the sharing and exchange of information)
[ gModeller for Google SketchUp ]
(gModeller is an energy analysis plugin for Google SketchUp)

[ Onuma System ]
(Open Architecture,提供Onuma SketchUp Plug-in透過其BIMXML導入/導出SKP模型)
[ IFC2SKP for SketchUp ]
(works inside SketchUp and has the ability to load IFC data from popular BIM applications)
據悉把SketchUp的SKP模型轉換成IFC格式的插件SKP2IFC目前正在開發中。
[ Navisworks ]干涉檢查軟體，接受SketchUp的模型。
[ ECOTECT ]很早就被用來做建築性能模擬，利用3DS或DXF轉換模型格式。
[ 3SKENG ]專用於SketchUp的三維配管插件和組件庫。
…………………………..等等。

除此之外，當然還包括Google自家的Google Earth以及世界最大的模型庫3D Warehouse等。這其中包含了專案排程(project schedule)模擬軟體直接把SketchUp推向4D的領域；
從可視化的角度，SketchUp很早就結合了多種Renderer (渲染器)軟體生成Photo-realistic級的模型場景圖像，靜態的和動態的。也早就跨進Virtual Reality的領域，而且是real-time immersive reality (實時身歷其境)，把豐富的圖像用在對設計內容的展現和解說程序中。

至於SketchUp究竟是不是BIM？

有些人對此說得斬釘截鐵：『SketchUp不是BIM！』其中包括國外一些大佬級的BIM先行者，有的是所謂BIM軟體公司，他們把SketchUp的用途定位在僅限於設計初期的概念設計工具。當然，還有Google那位巴卡斯大爺說:『SketchUp就是BIM！』，孰是孰非？

我的看法是，這是立場問題和私心問題，跟是非對錯無關。如果從當前這些BIM建模軟體的立場來看SketchUp而宣稱SketchUp不是BIM，這就是一個前提失格的偽命題，自己本身不是SketchUp的使用者，甚至對SketchUp的命令操作都弄不清楚的人，即使是專家學者也沒有資格去評斷SketchUp的是非，更無由僅憑一些初級操作者的圖片和自以為是的想像就推定SketchUp在建築專案裡的用途。

平心而論，如果按照那些所謂BIM軟體公司給BIM設定的「操作方法」來做些比對，當前版本的SketchUp其本身的顯性功能確實未達到跟它們一樣的整合性效能，但是這不代表未來永遠做不到，在眾多Ruby程式設計者的努力下，也許就在不久的將來我們會看到另一番氣象，也許出現的是由一系列插件集成的「SU-BIM」。SketchUp是個泛用型的建模軟體，被廣泛應用在許多跟設計、製造相關的行業裡，Google永遠不會把SketchUp改造成只用於建築的整合型軟體。許多在BIM建模軟體裡整合成自動組織運行的邊際功能，SketchUp經由不同的插件加持同樣做得到。相比之下，猶如自動排檔汽車跟手排檔汽車之別，自動排檔車駕駛起來很舒適，但是一級方程式(Formula 1)賽車為什麼都是手排檔呢？這跟專業攝影師永遠不使用照相機的全自動(Auto)功能是同樣的道理。

在東方的學習體制下，我們習慣於遇事先選邊站，習慣於依附所謂權威觀點，總認為教科書和操作手冊上寫的都是對的，認為那些專家學者的言論都是不容置疑的，認為外國的做法都是先進的，我們似乎已經失去自我成長和思維創新的能力。如果我們缺乏「雖千萬人吾往矣」的勇氣，缺乏「橫眉冷對千夫指」的氣魄，遇事總拿「人云亦云」這種最廉價的方式營造自己的觀點，那麼我們永遠跳不出別人設置好的窠臼。今天我們以義無反顧的心態追隨外國建立的BIM運行環境，想要快速的跟外國的作法接軌，卻只願意付出最少的代價——「複製和模仿」，藉此就想跟外國並駕齊驅。在急於師夷之長的時候，我們是不是忽略了什麼？外國那些BIM操作模式原先並不存在於我們沿用多年的專案建築架構中，一成不變的直接套用進來，真的適合我們的水土嗎？我們在地(Local)的特質又在哪裡？我們真該適時停下來好好思量一下，今天我們對BIM的認知和期待，究竟是自己的思維還是軟體公司的思維。

最後，對於在建築專案裡應用BIM的實施目標，數碼阿叔我還是要重複一次我個人說法：
『在建築生命週期的各個階段，以三維模型做為載體，實施資訊傳承，對建築物進行最佳化的處置。』
所謂「條條大路通羅馬」，只要能有效率的完成建築專案，達成在建築生命週期的各個階段進行最佳化處置的目的，運用什麼樣的軟體工具並沒有非我不可的必然性，運用當前的BIM建模工具是一種選項，即使運用SketchUp也是一種選項，除了真正的參與者(stakeholder)之外，圍觀的第三者無由對此指手畫腳。如果硬說只有白貓捉到的才叫做老鼠，黑貓捉到的只能算是嚙齒類動物，你認為這樣合適嗎？

我所期望的是，今天你我都站在這場真正建築革命的風頭浪尖上，如何禦風而行。如何以開闊的心胸迎向改革的挑戰，為我們建築環境的未來走出一條我們自己的路。沒有人能肯定當前市面上的BIM建模軟體就是建築行業演化的唯一解決方案，因此不要把心思老放在「你是、我不是」的這些枝微末節上，畢竟——

「千江有水千江月，萬里無雲萬里天」
.