家裝領域的BIM，面向的用戶對象是誰，解決什麼問題，如何才能落地執行……關于這些似乎每個公司都有各自的側重點和考量。而在落地的過程中，也總會遇到各種困難和問題，本文作為分享了自己對BIM在家裝領域落地的思考和做法，希望能給你帶來幫助。

今天要聊的話題呢，其實就是家裝領域中的BIM，怎麼說呢，其實行業内研究和發展了挺長時間的了，但是似乎一直沒有看到一些特别成功的東西出來，它面向的用戶對象是誰，到底解決什麼問題，能帶來什麼價值，到底怎麼才能落地執行，似乎每個公司都有每個公司的側重點和考量，并且每個公司對其的預期也不太一樣。

落地過程中呢，也總會遇到各種各樣的困難和問題，所以也衍生了一些很奇怪的現象，似乎是大家都認為家裝的未來在BIM，但是卻沒人知道為什麼在BIM，到底它有什麼用？它到底是不是一塊雞肋，食之無味，棄之可惜呢？

而對于我，作為一個運氣比較好一些，有幸落地過BIM，并且穩定運行了幾年的産品來說，也希望能通過自己對這件事情的分享，将自己對這件事情的思考和做法分享給大家，如果恰恰能夠給大家帶來一些新的思路和啟發的話，那就最好不過了。

一、什麼是BIM

BIM（Building Information Modeling）技術是一種應用于工程設計、建造、管理的數據化工具，通過對建築的數據化、信息化模型整合，在項目策劃、運行和維護的全生命周期過程中進行共享和傳遞，使工程技術人員對各種建築信息作出正确理解和高效應對，為設計團隊以及包括建築、運營單位在内的各方建設主體提供協同工作的基礎，在提高生産效率、節約成本和縮短工期方面發揮重要作用。——百度百科

BIM，建築信息模型（Building Information Modeling），其實是從建築領域來的。隻是說在家裝領域，室内設計也在行業内逐步的開始由2維的CAD繪圖，開始轉向3維的工具輔助設計，初期呢，其實隻是為了呈現設計效果，用戶可以直觀的感受自己未來的家會裝修成什麼樣子。

後來呢，因為天然是3維的設計，天然有一些數據化的内容，比如房屋戶型、空間、面積等信息，基于行業本身的數據化發展的進程，對于算量、計價等也逐漸有了自己的訴求，也就慢慢地開始有了家裝領域的BIM。其實，BIM自身在建築領域的定義，就已經決定了BIM未來是什麼樣子，隻是在不同的公司，也是各有側重，這個後續再慢慢細說~OK，大概了解了BIM的概念之後呢，我們就來看下BIM到底是個什麼樣的工具。

二、BIM是一個什麼樣的工具

這裡呢，也就簡單介紹一下，大家知道個前因後果，不做深入探讨和分析（因為一分析就又是一篇巨長巨長的文章了，後續有心情了再寫吧，咳咳）。在行業内，目前比較出名的幾個軟件工具，大概就要數酷家樂，三維家、每平每屋（原躺平）、打扮家等，以及貝殼旗下的一些自研BIM，如視的未來家之類的。這些工具中，酷家樂，應該是最廣為人知，因為它除了面向B端，也同時面向C端開放，這個原因，也促進了它本身的叠代和知名度。這些工具呢，因為側重方向不同，大概上能分為下面兩種：

我們來聊一下這些工具的類型，這些工具呢，首先肯定是一個設計工具。因為設計是整個家裝的上遊，沒有設計，就談不上後面的所有的算量、圖紙、交付之類的東西。所以，設計工具在之前一直是這類工具的核心，我不關心之後能不能實現，現在我得先要好看，是吧。所以最初的時候，大家的精力都會在這些工具如何才能更好的促進轉化上來。

慢慢地，開始有一部分企業開始思考，既然設計已經數字化了，那設計過程中到底用了哪些材料，材料用了多少，主材多少，輔材多少，這些用量是不是也可以數字化呢，如果這些量可以數字化，那是否意味着可以以BIM中的量為整個工程的計算依據呢？（要知道，現在整個行業大多數還在手扒CAD，拿計算器算量呢。）

因此慢慢地也開始出現了一些主打交付工具的工具，以算量為核心，主打所有的用量由系統計算得出，減少人工計算的誤差和偏差。當然，現在似乎每個工具都會有算量等負責交付的團隊，不過底層的不同，也必将會帶來上層的不同，某些時候底層結構的缺失，也會導緻某些算量完全無法計算。不過這些後續有機會再詳細聊好啦。

那對于BIM，它到底應該是個什麼樣的工具呢？

其實上面聊得已經比較清楚了，根據BIM本身的概念，還有家裝行業工具的發展軌迹，BIM的未來大概率上是以算量為核心的一套設計 交付的工具。也就是底層要按照能支持算量的結構搭建，而在應用層，也要能充分支持設計本身，做一個好的設計工具~

三、家裝業務存在的問題

在聊BIM能解決什麼問題之前呢，首先得先聊下在實際的家裝業務中存在哪些問題。一般情況下三大問題比較突出一些，分别是人員效率問題，材料成本問題，項目利潤問題。

為什麼說有這三塊的問題呢，我們分别來看下（這裡也就是簡單聊下BIM能解決的問題，不能覆蓋所有可能存在的問題）。

1. 人員效率問題

目前整個家裝行業的報價部分信息需要設計師手動計算和填寫，過程較為複雜，用量計算較多，時間消耗大約1-2小時。這還僅僅在報價，還有本身方案的溝通，圖紙的繪制等等。設計師是簽約的核心轉化成員，若系統能讓設計師的作業效率提升，也就意味着設計師會有更多的時間接待和轉化更多的客戶。

2. 材料成本問題

由于裝修過程中涉及的材料用量，是完全由人工計算然後錄入系統中的。在這個過程中，對于損耗的預估不同（比如A認為8%的損耗就夠，B認為需要12%）；對于自身利益的取舍（比如多下點材料，避免後期補貨）等等。

你會發現，同一個客戶，同一套方案，同樣的材料，不同的設計師肯定會報出不同的材料用量。而在某些極限情況下，可能還會存在60平米的屋子，下單200平米的地闆；有些工地會出現幾百個插座等等材料問題。材料成本極其不可控。即使很多企業中間還有一層中控進行審核，但是依然很難完全避免。而且材料在人工計算無法精準的基礎上，後期的退補貨也會較多，也會讓成本上升更多。

3. 項目利潤問題

在整個項目的利潤上，大多數項目的毛毛利潤率差不多在20%-30%，基本上都會是入不敷出的狀态，每年的現金流都很好，到年底一算賬，發現不賺錢。咳咳，在流量增量比較可觀的時候，可能問題都不太大，畢竟有很優質的現金流，但是一旦出現了增量減少的時候，如何精細化運營，在整個項目中盡可能的減少開支，節約成本就變成了一件很重要的問題。

四、BIM能解決的問題

那BIM能不能解決上面所說的問題呢，咳咳，估計大家用腳指頭都能想到了吧。嘿嘿，但是還不夠。在仔細研究了BIM工具之後，你會發現在報價層面、算量層面、體驗層面和圖紙層面都會有完全截然不同的體驗提升，而這整套體驗，其實帶來的是整個設計和交付行為的重大變革。

1. 報價層面

BIM本身作為3D的設計工具，戶型的結構，面積，空間信息，空間中的材料信息一應俱全，那麼完全可以從BIM工具直接生成用戶的報價單啊。對了，這裡多廢句話，現在家裝行業的報價功能設計的底層邏輯都是人如何在做報價的時候做的齊全還不缺項漏項。

所以所有的頂層設計都會圍繞這個底層邏輯在做，你不管看多少家報價體系，都在基于這個底層做事情。當我們接入3D設計工具的時候，是否可以換個視角，設計師是否可以不再做報價單了，而由系統來做。當視角不一樣的時候，你就會發現頂層設計就會變的完全不同了。咳咳，這裡就暫時不再延展開了。

還有就是，報價單是表格這件事情，咳咳，這個行業都幾十年了吧，這都2202年了，是否可以考慮換個形态，比如圖文或者什麼的。如何更清晰、易懂的向用戶傳遞裝修的基礎信息，其實可以換個角度來考慮。怎麼做，有多少困難，困難都如何解決，就先不聊了哈，廢話扯得有點多了，咳咳，勿怪勿怪。

2. 算量層面

BIM哎，3D設計工具哎，基本上都可以由系統直接計算所有材料用量了和施工用量了。由于完全依據系統規則生成，隻要設計方案是準确的，用量也自然會是準确的。完全可以屏蔽人為因素的影響。同時這些數據也完全可以用于後續的發包和下單（咳咳，當然，完全一點都不差也不現實，部分小的偏差，瑕不掩瑜，不影響大局）。

3. 體驗層面

BIM本身是3D設計工具，即方案完成後，用戶可以直接進行3D漫遊體驗，甚至可通過可穿戴設備進行VR體驗，所見即所得。再也不用全靠2D的圖紙想象了。未來你的家如何，是否讓自己滿意，完全可視可見。對于空間想象能力較弱的用戶，這簡直就是巨大的福音。

4. 圖紙層面

BIM本身也會根據設計師的方案生成全套的施工圖紙，可以節省很多CAD繪制的時間（這個根據工具的發展階段不同，有些工具支持，有些工具不支持，有些工具隻能支持部分）。

當這些層面都發生變化後，你會發現，這完全就是設計行為、報價行為、發包行為、結算行為等數據産生和傳輸行為的重大變革。設計不需要在CAD中進行，用戶無需靠自己腦補想象未來家的樣子，報價不用做了，系統一鍵生成，所有的材料用量根據系統規則生成，摒棄了人為因素帶來的偏差，施工圖紙自動生成，後續的發包，下單依據準确的用量進行，支付和結算也有了相應憑據。

五、家裝行業的産品分層

既然說BIM這麼好，到底好在哪裡呢，他在家裝整條業務線條中，到底處在什麼位置，有什麼重要作用呢？再聊位置的之前呢，先聊下整體的家裝業務吧，從産品底層來說的話，整體大概可以分為五層，分别為業務層、數據層、預算層、支付層、結算層。

五個層面分别面向不同的問題，提供各自的解決方案，家裝整體業務體系也基于這五層進行構建。

1. 業務層

業務層主要提供家裝全鍊條業務側解決方案，也是最重要的一層，所有的業務流程和邏輯都可以劃歸進該層。整體的結構基本包含以下部分：呼叫中心、銷售中心、客戶中心、智能交付中樞、合同中心，訂單中心，交付中心，供應鍊中心，财務中心，售後中心，智能設備中心等。基本涵蓋了家裝行業全鍊條的業務内容，所有的業務數據都在該層中處理。

（哈哈，此處也先賣個關子吧，内容暫時就都打碼了，後面應該會有個系列專門說業務層的所有框架和内容。應該是應該吧，但願不會再是兩年後了~ ）

2. 數據層

數據層主要指裝修項目中的施工數據、材料數據等信息，這部分信息既包括了用戶的報價，也包括了向下遊的各個端口的發包、訂單信息（業務層的業務數據在業務層處理，不在該層中處理）。該層面主要處理從設計開始的所有戶型和家裝全量數據，包括施工項目數據和材料數據，以及後期所有的變更數據，貫穿了家裝過程的始末，而這部分在大多數的公司和企業裡面，也是完全需要靠人來處理的。

所有用量的計算，報價的計算，施工過程中的變更，後期的退補貨，這也是鍊條中最難控制的部分。略微有點像那種，看起來每個地方都沒花什麼錢，但是就是錢都花完了的既視感。而作為BIM工具，也是在這層中發揮自己最大的價值，全部數據由BIM統一輸出，下遊依照上遊數據執行，從最大程度中規避過程中的數據風險。

3. 預算層

預算層主要用來衡量項目層面的預計收入、預計支出和預算毛利率。算是整體項目預算的最關鍵的部分了。這個項目到底能不能賺錢，能賺多少錢，毛利率多少，是否能覆蓋全部成本，我到底能不能盈利，這些問題，不能等到項目結束才知道，而要提前預測。

并且盡可能的讓決算與預算相接近，這種情況才能最大程度上節約成本，從而盈利。這部分主要涉及到項目内容、後台的成本構成，稅率關系等内容。需要依據數據層提供的數據進行準确預估。從而達到在項目未開始前，整體項目的收入、成本、增值稅、附加成本以及毛利率直接可預見。這層的準确性依賴于數據層的準确性，所以，能不能搞好數據層的數據，就決定了能不能搞好預算層的數據。

4. 支付層

支付層主要提供用戶支付的解決方案，包括微信支付、支付寶支付、POS機支付、現金收款、對公轉賬等等。支付鍊路橫跨整個用戶生命周期，特别是在家裝業務上，項目周期比較長，支付頻次（定金款、首期款、變更款、中期款、尾期款）比較多，支付金額比較大（大多數會超越在線支付單次5萬的限額），支付方式比較多變（在線支付、POS機支付、轉賬等），付款邏輯和場景也比較複雜，如何更好的處理用戶的支付場景，完美銜接自己的業務體系，就需要更多地花費一些心思。

這張圖呢，基本上介紹了這個行業支付這塊的關鍵信息，之後應該會有一片專門的文章說這塊，這裡就不一一展開了。至于裡面為什麼微信、支付寶既有線上支付，又有線下支付，這裡主要是區分是否能自動線上對賬的，如果能線上自動對賬，那就算線上，否則的話，即使支付了，也需要重新在線上認款到對應項目中，這個就算線下支付。

5. 結算層

這層相對下遊一些，也是狹義的結算，主要提供工程結算、供應商結算的解決方案，也就是主要解決如何向對應的服務者結算的問題。其實沒有太多需要說的，相對比較簡單，在上遊數據完備的情況下，相對比較好處理，隻需要按照結算規則、賬期和結算方式落地就行，大多數都是發起結算，審批結算，對賬，打款等。唯一需要考慮的是要盡可能多地覆蓋異常場景，這樣的話才會形成一個完整閉環，避免某些特殊情況的行為、支出、扣款等導緻系統無法進行正常結算。

六、BIM在家裝業務中的位置

上面已經清楚的講了五個層次的基本分法和概念，那麼BIM在整個業務中的位置就清晰可見了。BIM在數據層提供完整的、精确的原始數據，通過業務層産品規則（套餐規則）的轉化，形成面向用戶的報價單、變更單、同時形成面向施工方的發包單，面向供應商的發包單。貫穿全業務流程，為預算層、支付層和結算層提供準确和完善的數據支撐。

而這些單據，面向用戶的代表收入，面向服務商的代表支出，也就同時會産生預算單，也就意味着，在一個裝修項目開始的時候，就能很明确的知道項目的收入、成本、利潤率，從而為項目後續的進展提供準确的參考依據。

聊了這麼老久，終于可以開始聊一聊BIM到底是如何應用與實踐的了，咳咳，五千字才進入正題，不會被打吧~

七、BIM應用的框架結構

上面很詳細的聊了家裝業務的産品分層，并且也說明了在這套分層結構裡面BIM的位置，那麼BIM在整套業務體系裡面，到底如何規劃和落地呢。其實通過上面的這些内容，可以大概梳理出來，BIM在整個家裝業務體系中的數據流轉結構。

從BIM中獲取基礎數據，流轉至業務層的套餐規則中，進行轉化和輸出，輸出報價單和發包單。而銷售和成本直接的關系依靠底層數據進行拆分和關聯。從而将所有收入和支出引入财務體系，完成預算和決算。

八、BIM框架中的三大難題

在這套結構中，核心會存在三大難點問題：BIM的數據問題、報價規則和發包規則的抽象問題、銷售與成本之間的轉化關系問題，而這三個問題，恰恰也是整個系統結構流轉銜接的關鍵點，也就是說隻要能解決這三個問題，整體的産品方案就能落地。

那麼既然定位了核心問題，那麼接下來要做的就是一個一個解決掉它。

1. BIM的數據問題

BIM的數據問題，決定了BIM将向業務側傳遞什麼樣的數據，業務側需要接收什麼類型的數據。數據的格式如何界定，如何隔離BIM和業務體系，做到低耦合，同時通過數據通道相連。這裡面還需要解決兩個問題：BIM能提供的數據是什麼，業務側需要的數據是什麼格式的。

這裡就會涉及到兩部分，BIM能提供什麼類型的數據，而業務側需要什麼樣的數據。對于業務側需要什麼樣的數據，這裡解決不了，因為業務側需要什麼樣的數據，需要在抽象規則後才能知道。産品實現的過程是由底層數據到上層建築的過程，但是在産品構思階段，卻是由頂層結構拆分至底層數據的過程。

兩個完全相反，所以，這個問題會在下一個節點來說。這次我們就聊聊BIM能提供什麼類型的數據。至于BIM工具本身，就不多講了，一講起來就又是一篇長篇大論，等以後了，咳咳，我也不會寫，工具寫起來累人。。。雖然這裡不打算講BIM，但是你怎麼才能知道BIM能提供什麼樣的數據呢，那就需要小小的研究一下了，嘿嘿~

其實也不用研究得很細，就……把它整個功能結構扒下來，基本上你就能大概清楚他的數據結構和底層邏輯是怎麼處理的了，咳咳，是不是很簡單。

因為工具本身存在了前端應用的結構和管理後台，所以扒的時候不要漏了~前端結構主要用來了解基礎性質的原子數據，後端結構主要用來了解底層的數據支撐和結構，兩者都不可或缺。前端結構的數據和後端結構的數據如下圖，具體是哪一家的，就不做細說了，自己看吧。限于結構圖太……長了，所以隻截取一小部分。

所以，當你扒完BIM工具的整體結構之後，你就會發現，BIM本身提供的是原子化的數據，他可以提供你很精确的底層數據，比如戶型的面積，結構，每個空間的名稱，空間的長寬高，空間面積、空間周長，門的高寬厚等等原子數據，所以這些數據如何才能變成業務切實可用的數據，就需要依賴于業務側到底需要什麼樣結構的數據了。這就是我們下一個問題需要聊的了。

2. 規則的抽象問題

我們前面有聊到，BIM的數據經過規則的轉化之後，會轉化為報價數據和發包數據，一則面向于用戶進行報價，一則面向于下遊進行發包。所以，規則的抽象其實就是兩套規則的抽象。也就是産品報價規則和向服務者的結算規則抽象。

先聊報價規則吧，報價規則應該算是一塊最難啃的骨頭，因為這個領域，報價規則，那是手冊啊，厚厚一本……沒辦法，隻能采用老辦法，也是笨辦法，有可能也是最有效率的辦法，将整個手冊全部扒下來，然後從一堆規則中去提煉和抽象核心規則。産品手冊的規則一般包含幾個主要部分，分别是計價規則、主材配置、升級、限量規則、水電點位規則和個性化施工項目規則。

任何一個複雜的結構裡面，底層一定有一條或者幾條規則，是整個結構的核心，支撐着整個結構自由運轉。而我們要做的就是在複雜的、冗餘的、擁有極大幹擾的巨量因素裡面，去剖開表象，剝離出最本質的幾條規則。這也将會是我們突破的核心點，以點才能破面。

具體的過程我就不多描述了，如果感覺體會不深，咳咳，可以聯系我，我給你個手冊你自己剝離一下嘗試一下，不用擔心，不要錢，咳咳~

這裡就隻說結論了，在将所有的規則都扒出來之後，果然發現了最核心的一條規則，這條規則就是産品報價的核心：在XX空間下，XX 材料/施工項是标配的？還是升級的？還是加載的？行業内的同學會不會覺得跟自己現在做的好相似~雖然像，但好多事情差之毫厘……希望我的做法能對大家有一些新的啟發。

這裡簡單解釋一下，對于一般家裝行業套餐制公司，家裝的收費是按照房屋面積收費的，比如999元/平米，所以這裡的标配指的是不需要額外花錢的，包含在套餐内的。升級指的是不在套餐内，但是你可以補差價升級，比如你想用更好的地闆/瓷磚時，可以補一個差價。加載的話就是指套餐内完全不含，需要付全部費用購買的。

在這條規則之下，你會發現絕大多數的（80-90%）場景都能覆蓋，而且它也将直接決定業務需要的BIM數據是什麼格式的。

在這條核心規則的基礎上，并不是所有的規則都能滿足，所以還需要一批其他的特殊規則進行補充。包括水電點位規則，門的超高/超寬/超厚規則，垭口超厚規則，窗套超厚規則，地闆/鋁扣闆異形規則等等。而這些規則在一起将支撐整套報價體系自動生成。

報價規則抽象完了之後呢，就是如何抽象結算規則了，用來決定如何發包，這套規則比較簡單，核心其實就是售價和成本的問題，然後對于工程會有一些套餐包的計價，比如施工部分包給工人多少錢這樣，相對比較簡單一些。

3. 結算的轉化問題

最後來一下結算轉化的問題，這個東西主要界定銷售和成本之間的關系，看起來比較簡單，其實也的确比較簡單，咳咳~隻是會有一些特殊場景，所以會跟正常的通過SKU管理銷售和成本的關系不太一樣。舉個簡單的栗子大家就能明白了。

所以，看完上圖也就不難理解，為什麼需要獨立關系處理了吧，因為轉化關系并不完全是同一單位的數據轉化，而會是不同單位的數據轉化。聊到了這裡，大概就可以理解，為什麼在BIM應用的框架結構（不要問框架在哪？往上翻翻，咳咳~）中，會單獨拆出來三個庫來處理内容了吧。而對于倉儲，因為同樣涉及到了出入庫的内容和采購的内容并不一定是一一匹配的，所以也将倉儲的部分獨立拆分了庫，進行獨立管理。

九、BIM的落地産品方案

聊了這麼多，也說了這麼多問題如何解決，那麼到底實際的落地方案會是什麼樣子呢，會不會很好奇，以下将是重磅内容，哈哈，期待一下吧。上面聊了所有的框架、結構、要解決的問題、以及如何解決，那麼接下來就看看到底在系統中如何落地吧~

1. 功能結構圖

在開始落地之前呢，肯定還是要大概梳理下功能結構的，雖然上面其實已經聊得差不多了。

2. 數據流程圖

然後就是數據傳輸過程中的流程圖，用來更清晰地表現數據過程。

3. BIM的數據方案

上文已經界定了BIM需要提供的數據格式為，空間/施工項、材料/用量，那麼BIM工具就需要提供該種類型的核心數據，同時也需要提供BIM的基礎空間等信息數據。

1）基礎項目、方案數據

包含基礎的項目、方案信息、該戶型結構及基礎内容。

2）施工、材料數據

詳細的施工和材料數據信息，也是最核心的信息。業務規則将依據該部分内容進行相關報價數據和結算數據的生成。

4. 規則的抽象方案

規則的抽象核心是各種規則的提煉，上面核心規則和分支規則已經聊得差不多了，下面就是具體的産品方案。規則的抽象和提煉總共分為了8步，分别為：套餐規則管理、套餐商品管理、商品規則管理、附加規則管理、拆除包管理、水電包管理、補充報價管理、發包管理。

1）套餐規則管理

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部