引言：

　　數字化轉型背景下，房地產企業雖然積累了多年的數據工作經驗，但內部多業務條線的交匯與外部運營環境的變化也帶來了不小的挑戰。數據資產作為企業生產環節必不可少的生產要素，已經具備相對完善的管理標準。本文就講討論研究房地產企業如何沉淀數據資產、輸出數據服務、建設數據消費場景。

　　企業數據資產盤點的三個核心目標，分別是：

　　1、建立企業級數據綜合治理體系

　　關鍵數據資產有清晰的業務管理責任

　　IT建設有穩定的原則和依據

　　業務人員有規范的流程和指導

　　2、建立“聯接共享”的數據底座

　　建設數據中心與數據主題聯接

　　實現數據的匯聚和聯接，打破數據孤島和壟斷

　　最終重建數據獲取方式和次序。

　　3、建立“自助消費”的數據服務

　　快速、安全、合規地獲取各種所需的數據

　　靈活、自主、自助地進行數據分析

　　打造從數據供應到消費的完整鏈條

　　帆軟啟城團隊建立了一套從管理思路到技術工具，再到頂層數據消費應用的，完善的閉環的數據綜合治理體系。

　　一、地產企業的數據資產化

　　1）現狀剖析

　　當前業務模式下，數據的生產和數據的消費兩者之間是相互割裂的。很多業務動作不斷地生產數據，同時不斷新建的業務終端也需要大量的企業級業務數據作為支撐。前者對應了不斷更新的數據資產，后者對應了層出不窮的數據需求。

　　兩者之間不斷升級的矛盾就導致企業出現了大量的人力物力的浪費——也就是重復造輪子。以某千億房企為例：某企業信息化終端建設的三通一購業務平臺，在建設之初需要若干的業務數據接口如房源信息、銷售日報等。如果分別對接的話，其產生的數據接口就會與之前分析報表端的接口產生重復建設的問題。不僅重復建設，同時也存在接口標準的問題等。

　　2）數據資產沉淀的工作框架

　　本文討論的數據資產沉淀工作涵蓋了以下幾項重點工作：

　　->業務拆解討論

　　->資產梳理認證

　　->邏輯模型補全

　　->建模綱領輸出

　　->物理模型輸出

　　->API接口輸出等

　　業務拓撲解構其核心是要將業務拆解到最細可控單元，保證每個業務環節都能獨立生產出具體的可衡量的業務數據，并且有相關的管理維度和數據應用維度。好比一個人的骨架，無論人的高矮胖瘦，身體總歸是207塊骨頭，這是不可能產生變化分割的。對于企業來講也是一樣，住宅地產開發商的核心業務就是房地產的投資、建設、運營、銷售，那銷售領域相關的核心業務動作(銷售方案、銷售預算等)一定是可以按“數據資產骨架”進行拆解細分的。

　　在這個業務拆解的工作過程中，我們也不能一味地憑外部公司的經驗去“盲人摸象”，更重要的是找準企業自身的業務發展動作——這就需要結合企業的報表資產工程，以企業的日常業務結果報告與資產梳理框架兩項映射，最終實現符合房企自身資產管理需求的成果產出。

　　3）數據資產的戰略布局

　　數據資產的梳理過程，在業務解構的這一步中，其實就已經從源頭上解決了數據的合規性問題。自下而上的資產組織結構，本身就是極具生命力的一種生產要素結構。

　　數據應用的上線效率，也由原先的一個月現在上升到一周，相關數據的API接口可以根據需求解析后的標準，直接復用或進行適當調整即可。同時這樣的模式也為數據工作拓寬了更大的想象空間，在業務革新的過程中擁有更多的容錯空間——可以先用沉淀下來的數據資產去嘗試不同的業務模型，再進行相應的決策。

　　二、數據服務化

　　1）數據資產服務化

　　數據服務化帶來了數據安全和應用效率上的提升，其歸根結底也就是數據一致性和數據服務敏捷性的體現。在數據資產沉淀與服務化輸出的過程中，保障“數出一孔”，提升數據的一致性。通過服務獲取數據的方式類似于“閱后即焚”，大部分情況下數據并不會在使用方的系統中落地，因此減少了數據“搬家”，而一旦數據的使用方并不擁有數據，就減少了向下游二次傳遞所造成的數據不一致問題。

　　數據消費者不用關注技術細節，可以滿足不同類型的數據服務需求。對于數據消費者而言，不用再關心“我要的數據在哪里”，例如用戶不需要知道這些數據來自哪個系統、哪個數據庫、哪個物理表，只需要清楚自身的數據需求，就能找到對應的數據服務，進而獲取數據。

　　數據服務一旦建設完成，并不需要按使用者重復構建集成通道，而是通過“訂閱”該數據服務快速獲取數據。面向一線業務人員提升數據敏捷響應能力，才能夠切實有效地幫助他們觸達數據的價值。同時服務化的窗口也能滿足用戶靈活多樣的消費訴求。數據服務的提供者并不需要關心用戶怎么“消費”數據，避免了供應方持續開發卻滿足不了消費方靈活多變的數據使用訴求的問題。

　　2）數據集服務化

　　數據集服務面向的終端消費，一方面是真實的人，一方面是IT系統。

　　面向IT系統的時候，需要按照相應規則制定好業務口徑與輸出邏輯。面向真實的人，需要更加嚴密、基礎型的數據資產準備包，即類似BI基礎數據包。

　　無論是數據資產服務還是數據集服務，都應被納入數據資產管理體系，確保數據供應方能夠準確、及時地了解“誰”使用了自己的數據，并且可以在數據服務建設中落實各種安全措施，確保數據使用的合規。核心數據資產認證后會按標準口徑和邏輯進行計算和數據結果輸出，如果有個性化的需求增加，可以通過API接口等方式進行響應。這從根本上改變了消費端要理解計算邏輯，輸出端要研究消費場景的問題。

　　3）數據服務的三個一

　　“三個1”是數據服務的整體目標，起點是需求方提出數據需求，終點為需求方拿到數據并可立即進行消費，具體衡量標準包括如下內容：

　　1天：對于已發布數據服務的場景，從需求提出到消費者通過服務獲取數據，在1天內完成。

　　1周：對于已進資產池但無數據服務的場景，從需求提出到數據服務設計落地、消費者通過服務獲取數據，在1周內完成。

　　1月：對于已結構化但未進資產池的場景，從需求提出到匯聚入湖、 數據主題聯接、數據服務設計落地、消費者通過服務獲取數據，在1個月內完成。

　　三、數據消費的場景化建設

　　1）場景的提取

　　數據消費場景的建設思路，是從真實的業務數據消費動作中，提取、提煉出來的�？傮w會分成以下幾步：

　　1.業務需求提出——需要明確業務需求的痛點和訴求點、明確業務的起止點

　　2.數據需求解析——將業務需求解析為具體的、可執行的、可衡量的數據指標，并設計好最終的業務分析報告模型

　　3.數據獲取——從數據集、數據服務端獲取數據，即數據服務的申請

　　4.數據服務提供——API接口接收請求后，根據數據資產管理規范向消費端提供數據服務

　　5.報告設計和展示——完成數據需求的開發和落地

　　2）自助式數據消費的場景建設

　　自助式數據消費場景在房企的業務線上出現很多，往往是以靈活多變的業務分析訴求結合復雜的業務分析框架的形態出現。此時需要依托數據資產框架建立的基礎業務數據包，為自助式BI分析提供堅實有力的服務支撐。

　　要真正實現自助式數據消費，必須做到以下三點：

　　1.通過拖拉拽實現單張報表的制作;

　　2.數據口徑統一的基礎上，單人單報表制作時間縮短80%;

　　3.報表中心的權限支持分級授權，實現對核心資產的多級引用，縮短數據稽核過程

　　以某千億房企的自助式BI分析建設為例，首先建立了營銷數據通用標準包——取自于營銷線數據資產輸入。然后在通用標準包的基礎上進行自助螺旋上升并進行多級授權下放，實現了不同層級不同權限，真正的千人千面。整個自助數據集創建過程清晰明了，從表字段到表處理每個步驟都可視化：

　　3）跨平臺、跨業務的數據消費場景

　　房企大本營、核心戰區的項目密度往往比較高，淡旺季的集中推盤所依賴的銀行按揭資源需求也相對集中。在此期間，業主、房企置業顧問、房企按揭專員、房企工程部、房企財務部、房企運營部、銀行客戶經理、銀行信貸專員、銀行信貸負責人等眾多角色，跨越組織邊界而共處于同一條流程之中。

　　過去大家不得不通過微信、打電話、excel統計等手工手段協作，效率低下，錯誤頻出，來回反復。在這樣的背景下，帆軟地產團隊提出應通過業務節點數字化管控，將每類角色的職能和流程緊密結合，進而落實銀企互聯、跨部門協作數字化應用。

　　以上可以歸納為一條橫跨不同辦公工具、不同業務系統業務節點的數字化流程：

　　1.業主可以使用微信，線上下單，預約銀行;

　　2.銀行可以使用釘釘，在線節點與審批;

　　3.置業顧問和按揭專員可以使用企業微信，在線處理流程業務;

　　4.財務和運營可以隨時進行放款效率分析、放款額度分析、回款預測，進而制定管理措施，落實貸款額度集中管理和現金流管理業務，省去圍繞樓棟，多部門的海量手工更新工作。

　　在該房企的項目實踐中，以數據資產為基石，提供數據服務接口，最終實現在極端時間內上線這樣一套流程管控場景，需要在業務管理和數據分析兩個節點之間建立暢通無阻的數據流轉，使放款額、放款進度、銀行剩余額度等數據可以應管理需要定時流入企業數據中心，進而自動生成確認放款統計表、待放款統計表、預告抵押登機統計表、審批通過統計表、需補件統計表等管理報表，并與管理駕駛艙的數據形成整合和聯動，而不是由業務反復手工導入導出進行匹配、核準。

　　結語：

　　數據資產深度參與到企業的業務生產環節，同時也會在每個重要的業務環節中通過業務活動被不斷更新。數據資產本身具備了極強的生命力和業務屬性，掌控企業自身的數據資產就猶如苦練內功一般，將會使得一個企業在多邊的外部環境中具備極強的競爭力。

　　數據資產與資金、勞動力、硬件工具等被一并列入生產要素范疇，也需要地產從業人員一并探尋研究，找出更適合自己企業的資產沉淀之路。

　　(本文僅代表作者個人觀點，其原創性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，請讀者僅作參考。)