【萬字長文】BIM在家裝領域的應用與實踐
家裝領域的BIM,面向的用戶對象是誰,解決什么問題,如何才能落地執行……關于這些似乎每個公司都有各自的側重點和考量。而在落地的過程中,也總會遇到各種困難和問題,本文作為分享了自己對BIM在家裝領域落地的思考和做法,希望能給你帶來幫助。
今天要聊的話題呢,其實就是家裝領域中的BIM,怎么說呢,其實行業內研究和發展了挺長時間的了,但是似乎一直沒有看到一些特別成功的東西出來,它面向的用戶對象是誰,到底解決什么問題,能帶來什么價值,到底怎么才能落地執行,似乎每個公司都有每個公司的側重點和考量,并且每個公司對其的預期也不太一樣。
落地過程中呢,也總會遇到各種各樣的困難和問題,所以也衍生了一些很奇怪的現象,似乎是大家都認為家裝的未來在BIM,但是卻沒人知道為什么在BIM,到底它有什么用?它到底是不是一塊雞肋,食之無味,棄之可惜呢?
而對于我,作為一個運氣比較好一些,有幸落地過BIM,并且穩定運行了幾年的產品來說,也希望能通過自己對這件事情的分享,將自己對這件事情的思考和做法分享給大家,如果恰恰能夠給大家帶來一些新的思路和啟發的話,那就最好不過了。
一、什么是BIM
BIM(Building Information Modeling)技術是一種應用于工程設計、建造、管理的數據化工具,通過對建筑的數據化、信息化模型整合,在項目策劃、運行和維護的全生命周期過程中進行共享和傳遞,使工程技術人員對各種建筑信息作出正確理解和高效應對,為設計團隊以及包括建筑、運營單位在內的各方建設主體提供協同工作的基礎,在提高生產效率、節約成本和縮短工期方面發揮重要作用?!俣劝倏?/p>
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. 業務層
業務層主要提供家裝全鏈條業務側解決方案,也是最重要的一層,所有的業務流程和邏輯都可以劃歸進該層。整體的結構基本包含以下部分:呼叫中心、銷售中心、客戶中心、智能交付中樞、合同中心,訂單中心,交付中心,供應鏈中心,財務中心,售后中心,智能設備中心等?;竞w了家裝行業全鏈條的業務內容,所有的業務數據都在該層中處理。
(哈哈,此處也先賣個關子吧,內容暫時就都打碼了,后面應該會有個系列專門說業務層的所有框架和內容。應該是應該吧,但愿不會再是兩年后了~ )
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)套餐規則管理
主要用來管理套餐的基礎計價規則,及相關內容介紹。
2)套餐商品管理
主要用來界定該套餐包含哪些商品。對于純粹的裝企來說,那就是包含所有內容。如果對于復合型企業來說,比如有自己的大店,有自己的電商,并且與家裝業務有明確區分的時候,這里可能需要額外的關注下。
3)商品規則管理
主要用來界定最核心的材料和施工項規則,即某個空間是標配的,升級的還是加載的。
4)附加規則管理
主要用來解決附加規則管理的問題。附加規則上文已經說的很清楚了,這里就不再贅述了。
5)拆除包管理
拆除包主要用來定義計價規則和收費內容。
6)水電包管理
水電包管理主要用來管理水電包的計價規則、水路點位規則、電路點位規則等。
7)補充報價管理
主要用來兼容部分無法在BIM工具中算量和計價的項目。比如我們之前對接的BIM工具不支持復式、別墅這種多層設計,那么一旦在實際過程中遇到該類戶型,就需要采用一些方式,兼容該類特殊設計。當然,既然作為一個入口,那么一些特殊場景內無法滿足的,都可以在這個入口兼容。
8)發包管理
發包管理主要用來管理施工部分的發包規則,其他材料部分,由關聯關系可以直接衍生,但是施工側會有一些獨立發包規則,因此需要獨立管理。
5. 結算的轉化方案
這個呢,其實就是3個基礎庫如何進行拆分轉化,其實沒啥太大難度,基礎庫需要區分一些類型和屬性,比如不同類型的施工庫和材料庫分開管理,結算庫里面要有稅率,庫存庫里面要有庫存等等,就不詳細贅述了。轉換公式里面有一些需要關注,比如一些基本參數,比如戶型面積、損耗系數、庫存的尺寸等等可以作為基礎參數進行定義。公式的本質是數學運算,所以能提煉的就盡可能提煉就好了。
6. 前端應用
三大問題解決了,數據可以傳輸了,規則也已抽象完成,轉化關系也已建立,那應用時是如何應用的呢。
1)獲取方案
在BIM工具中完成方案后,只需要一鍵獲取就可以了。
2)生成報價
獲取后呢,系統根據規則自動生成相應的報價和詳情。因為是圖文,所以也完全可以在手機上進行呈現,雖然表格呈現信息的組織性和邏輯性很好,但是可讀性并不太好,畢竟是給用戶看的,所以,看的爽和能看懂才是第一要素,其實也不用過于拘泥于之前的行業方式。因為報價單本身內容太多了,所以就不展示全部截圖了。
Web報價詳情
App報價詳情
3)生成發包、預算
根據轉化關系自動生成發包和預算,直接獲取所有項目的收入、成本和毛毛利率~
OK,整個項目上,基本上到此就打完收工了。至于變更怎么做,財務如何處理,這些地方按照自己的業務邏輯和規則處理就好啦~但是,但是,真的完了么?
十、PLAN B的必要性
在對接BIM的時候,一定要考慮的一個點,就是一旦BIM跪了,業務怎么辦?如果是三方的BIM,業務肯定不能一直等著三方BIM團隊來解決問題(你一個月沒法解決,難道我還能等你一個月么)。所以在架構上的拆分就很有必要了,BIM作為數據的輸入方,如果BIM一旦跪了,那么就需要有一個路徑將數據輸入這套體系。這就是PLAN B了,任何時候要給自己的業務體系留好后門,別過于受其他方掣肘。至于這個PLAN B是什么樣子的,既然你都看到了這里,應該就不用多說了吧,嘿嘿~
當然,這其實也是一個好事,當你考慮到這個點的時候,其實也意味著,你的業務體系就可以接多個BIM工具了,備胎多點,自己的業務體系就會越穩定~而且,你也不用擔心某個BIM忽然某天黃了,自己的業務就廢了~
當然,這里其實也拋出了一個問題,如果沒有BIM,這事能不能搞,能不能搞哩?
當然是廢話了,沒有BIM當然能搞拉,BIM的核心在于提供基礎數據,如果有一套體系可以脫離BIM提供基礎數據,是不是就……
這套體系是啥呢,可以自己想想,它的確存在且切實可行,并且我并不打算寫,哈哈~(主要是市場上BIM工具還挺多的,著實沒有必要~)
十一、數據的對接與維護
任何一個體系總要落地執行吧,所以業務體系和BIM工具,雙方數據的統一和維護就需要保持一致和統一。如果剛好你自己的公司就在搞BIM,那就最方便不過了,直接底層數據打通,用一套數據就好啦。
如果沒有自己搞BIM的這個實力,也沒關系,這也是件好事,就意味著你可以接市場上所有的BIM,畢竟備胎還是要多來幾個的,要不然一旦接的那個BIM工具黃了呢,咳咳~在這種情況下因為本身在兩套體系里面維護數據,為了確保數據在維護層面準確,可以建立一些數據維護的SOP,這樣就能很方便相關方維護相關數據啦~
十二、產品的培訓與使用
因為這種方式呢,其實跟設計師之前的處理行為截然不同,所以,培訓和使用過程必將面臨著巨大的難題。所以,公司上層的老板們要考慮好,這件事情到底能帶來什么,是否需要付出這種成本,收益到底如何。這將會是一個一把手工程,因為這個在執行層面會遇到極大的阻力。
拋個一定會出現的問題示例一下吧,咳咳。那就是一定會有人反饋,這個算的量不準啊~面積少了,面積多了,量少了,量多了~這種問題應該是最影響業務運行,也最容易讓人恐慌的了,所以這種問題,解決的方式也很簡單,拿到設計師原始量房圖,從每一條線開始核對戶型數據是否準確,從而解決面積誤差問題,這個問題很重要,因為涉及到了按平米計價。
對于用量問題,就是查看設計方案,去一點一點扣量是否準確,設計師的操作問題(比如某個地方忘記了鋪瓷磚),還是BIM工具問題(比如工具計算錯了用量),還是業務體系轉化的問題(比如轉化公式有問題),然后去解決對應問題。
(其實誤差的確天然存在,只要在合理可接受的范圍內其實就好~)
BIM工具的落地本來就是個全新的嘗試和變革,這個過程中會有各種各樣的困難和阻礙出現,所以最好有一個團隊可以持續性運營和解決出現的問題(當然,產品其實最合適,咳咳),需要持續一些時間,在走過最開始最艱難的時刻后,后續就會逐漸走的順暢。
十三、產品的效果和收益
體驗上,VR效果的所見即所得效果其實非常好,不過呢,也會遇到一些小小的問題,咳咳,就是用戶感覺太爽了,終于不用靠腦補來想象是什么樣子了,所以呢,用戶就很開心地期望這里換個瓷磚看看,那里換個地板看看,略微微地會影響一丟丟簽約轉化的時間。
時效上呢,因為不用再出報價單了,而且圖紙方面也不用獨立繪制了(部分圖紙),所以整體上大約能提升2-3小時的工作時效,設計師們終于可以有更多的時間接待更多的客戶了~結算的毛毛利潤率方面的,采用了該種方式的話,毛毛利潤率可以提升10%-20%。是不是感覺很震驚,這怎么可能,其實我也很震驚,不過這就是事實,所以,也可以看得出來,在之前的那種行為模式下,這個過程中到底有多少的額外支出~Emmm,就算你不相信,覺得提升不了這么多,提升個5%是否值得呢,如果按照一年營收10個億來算的話,這是多少錢來著,手指頭有點算不過來。。。
十四、最后想聊的幾個小點
第一呢,這一定是一個自上而下的過程,甚至可以說是一把手工程,有些事情是看見所以相信,有些事情是相信所以看見,所以,從上而下達成一致其實很重要。否則任何一丁點的困難都會成為這個事情失敗的原因。一件事情的成功,不僅僅取決于它的規劃,同樣也取決于它的執行。
第二呢,就是不要老路,新路一起并存,總覺得我額外提供一種新的方式來解決這個問題,但是我依然保留著老的路徑。這種情況下,根本不可能成功,因為沒有人會走新的路徑。這就像當年福特造汽車時,剛開始汽車速度還不如馬車的時候,那么他是要回去繼續做馬車呢,還是迭代和改造汽車?其實道理有點類似,在新的路徑上畫更多的時間和精力讓他更好用,更易用,而不是給大家一個老的路徑可以繼續使用。這樣鐵定大家都會回到老的路徑上去(當然,這個嘛,是個人看法,也不一定對)。
第三呢,有所選擇,有所放棄。如果你想滿足現在線下的規則中的每一個字,那我可以很負責任地告訴你,放棄吧~ 別搞了,因為絕對搞不定。所以,如何在線下運行的規則中,找到合理并且合適的規則,放棄掉一些不是那么合理和合適的規則就會顯得很重要。
這將會是一個艱難求索的過程,預祝各位能夠順利前行~
作者:趙晗;公眾號:腳量產品路
本文由 @趙晗 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
太強了,這得大半年以上的積累
哈哈,這是好幾年的積累~
不要老路,新路一起并存,有所選擇,有所放棄。
做選擇還是全都要,是一件挺難決策的事情。
很用心的文章,期待后期文章,填補里面的部分需展開的內容!加油
哈哈,多謝