环球时讯 数据资产在地产行业的应用与实践
帆软 | 启城
联合创始人 印珂玮
引言：
数字化转型背景下，房地产企业虽然积累了多年的数据工作经验，但内部多业务条线的交汇与外部运营环境的变化也带来了不小的挑战。数据资产作为企业生产环节必不可少的生产要素，已经具备相对完善的管理标准。本文就讲讨论研究房地产企业如何沉淀数据资产、输出数据服务、建设数据消费场景。
企业数据资产盘点的三个核心目标，分别是：
1、建立企业级数据综合治理体系
-
-
- 关键数据资产有清晰的业务管理责任
- IT建设有稳定的原则和依据
- 业务人员有规范的流程和指导
-
2、建立“联接共享”的数据底座
-
-
- 建设数据中心与数据主题联接
- 实现数据的汇聚和联接，打破数据孤岛和垄断
- 最终重建数据获取方式和次序。
-
3、建立“自助消费”的数据服务
-
-
- 快速、安全、合规地获取各种所需的数据
- 灵活、自主、自助地进行数据分析
- 打造从数据供应到消费的完整链条
-
帆软启城团队建立了一套从管理思路到技术工具，再到顶层数据消费应用的，完善的闭环的数据综合治理体系。
一、地产企业的数据资产化
1）现状剖析
当前业务模式下，数据的生产和数据的消费两者之间是相互割裂的。很多业务动作不断地生产数据，同时不断新建的业务终端也需要大量的企业级业务数据作为支撑。前者对应了不断更新的数据资产，后者对应了层出不穷的数据需求。
两者之间不断升级的矛盾就导致企业出现了大量的人力物力的浪费——也就是重复造轮子。以某千亿房企为例：某企业信息化终端建设的三通一购业务平台，在建设之初需要若干的业务数据接口如房源信息、销售日报等。如果分别对接的话，其产生的数据接口就会与之前分析报表端的接口产生重复建设的问题。不仅重复建设，同时也存在接口标准的问题等。
图1 数据资产的集理存用享
2）数据资产沉淀的工作框架
本文讨论的数据资产沉淀工作涵盖了以下几项重点工作：
->业务拆解讨论
->资产梳理认证
->逻辑模型补全
->建模纲领输出
->物理模型输出
->API接口输出等
图2 数据资产沉淀框架
业务拓扑解构其核心是要将业务拆解到最细可控单元，保证每个业务环节都能独立生产出具体的可衡量的业务数据，并且有相关的管理维度和数据应用维度。好比一个人的骨架，无论人的高矮胖瘦，身体总归是207块骨头，这是不可能产生变化分割的。对于企业来讲也是一样，住宅地产开发商的核心业务就是房地产的投资、建设、运营、销售，那销售领域相关的核心业务动作（销售方案、销售预算等）一定是可以按“数据资产骨架”进行拆解细分的。
在这个业务拆解的工作过程中，我们也不能一味地凭外部公司的经验去“盲人摸象”，更重要的是找准企业自身的业务发展动作——这就需要结合企业的报表资产工程，以企业的日常业务结果报告与资产梳理框架两项映射，最终实现符合房企自身资产管理需求的成果产出。
3）数据资产的战略布局
数据资产的梳理过程，在业务解构的这一步中，其实就已经从源头上解决了数据的合规性问题。自下而上的资产组织结构，本身就是极具生命力的一种生产要素结构。
数据应用的上线效率，也由原先的一个月现在上升到一周，相关数据的API接口可以根据需求解析后的标准，直接复用或进行适当调整即可。
同时这样的模式也为数据工作拓宽了更大的想象空间，在业务革新的过程中拥有更多的容错空间——可以先用沉淀下来的数据资产去尝试不同的业务模型，再进行相应的决策。
二、数据服务化
1）数据资产服务化
数据服务化带来了数据安全和应用效率上的提升，其归根结底也就是数据一致性和数据服务敏捷性的体现。在数据资产沉淀与服务化输出的过程中，保障“数出一孔”，提升数据的一致性。通过服务获取数据的方式类似于“阅后即焚”，大部分情况下数据并不会在使用方的系统中落地，因此减少了数据“搬家”，而一旦数据的使用方并不拥有数据，就减少了向下游二次传递所造成的数据不一致问题。
数据消费者不用关注技术细节，可以满足不同类型的数据服务需求。对于数据消费者而言，不用再关心“我要的数据在哪里”，例如用户不需要知道这些数据来自哪个系统、哪个数据库、哪个物理表，只需要清楚自身的数据需求，就能找到对应的数据服务，进而获取数据。
数据服务一旦建设完成，并不需要按使用者重复构建集成通道，而是通过“订阅”该数据服务快速获取数据。面向一线业务人员提升数据敏捷响应能力，才能够切实有效地帮助他们触达数据的价值。同时服务化的窗口也能满足用户灵活多样的消费诉求。数据服务的提供者并不需要关心用户怎么“消费”数据，避免了供应方持续开发却满足不了消费方灵活多变的数据使用诉求的问题。
2）数据集服务化
数据集服务面向的终端消费，一方面是真实的人，一方面是IT系统。
面向IT系统的时候，需要按照相应规则制定好业务口径与输出逻辑。面向真实的人，需要更加严密、基础型的数据资产准备包，即类似BI基础数据包。
图3 数据服务化的价值输出
无论是数据资产服务还是数据集服务，都应被纳入数据资产管理体系，确保数据供应方能够准确、及时地了解“谁”使用了自己的数据，并且可以在数据服务建设中落实各种安全措施，确保数据使用的合规。核心数据资产认证后会按标准口径和逻辑进行计算和数据结果输出，如果有个性化的需求增加，可以通过API接口等方式进行响应。这从根本上改变了消费端要理解计算逻辑，输出端要研究消费场景的问题。
3）数据服务的三个一
“三个1”是数据服务的整体目标，起点是需求方提出数据需求，终点为需求方拿到数据并可立即进行消费，具体衡量标准包括如下内容：
- 1天：对于已发布数据服务的场景，从需求提出到消费者通过服务获取数据，在1天内完成。
- 1周：对于已进资产池但无数据服务的场景，从需求提出到数据服务设计落地、消费者通过服务获取数据，在1周内完成。
- 1月：对于已结构化但未进资产池的场景，从需求提出到汇聚入湖、 数据主题联接、数据服务设计落地、消费者通过服务获取数据，在1个月内完成。
图4 数据服务的“三个一”
三、数据消费的场景化建设
1）场景的提取
数据消费场景的建设思路，是从真实的业务数据消费动作中，提取、提炼出来的。总体会分成以下几步：
- 业务需求提出——需要明确业务需求的痛点和诉求点、明确业务的起止点
- 数据需求解析——将业务需求解析为具体的、可执行的、可衡量的数据指标，并设计好最终的业务分析报告模型
- 数据获取——从数据集、数据服务端获取数据，即数据服务的申请
- 数据服务提供——API接口接收请求后，根据数据资产管理规范向消费端提供数据服务
- 报告设计和展示——完成数据需求的开发和落地
2）自助式数据消费的场景建设
自助式数据消费场景在房企的业务线上出现很多，往往是以灵活多变的业务分析诉求结合复杂的业务分析框架的形态出现。此时需要依托数据资产框架建立的基础业务数据包，为自助式BI分析提供坚实有力的服务支撑。
要真正实现自助式数据消费，必须做到以下三点：
- 通过拖拉拽实现单张报表的制作；
- 数据口径统一的基础上，单人单报表制作时间缩短80%；
- 报表中心的权限支持分级授权，实现对核心资产的多级引用，缩短数据稽核过程
以某千亿房企的自助式BI分析建设为例，首先建立了营销数据通用标准包——取自于营销线数据资产输入。然后在通用标准包的基础上进行自助螺旋上升并进行多级授权下放，实现了不同层级不同权限，真正的千人千面。整个自助数据集创建过程清晰明了，从表字段到表处理每个步骤都可视化：
图5 自助式数据消费场景
3）跨平台、跨业务的数据消费场景
房企大本营、核心战区的项目密度往往比较高，淡旺季的集中推盘所依赖的银行按揭资源需求也相对集中。在此期间，业主、房企置业顾问、房企按揭专员、房企工程部、房企财务部、房企运营部、银行客户经理、银行信贷专员、银行信贷负责人等众多角色，跨越组织边界而共处于同一条流程之中。
过去大家不得不通过微信、打电话、excel统计等手工手段协作，效率低下，错误频出，来回反复。在这样的背景下，帆软地产团队提出应通过业务节点数字化管控，将每类角色的职能和流程紧密结合，进而落实银企互联、跨部门协作数字化应用。
图6 跨平台的按揭贷款云助手场景
以上可以归纳为一条横跨不同办公工具、不同业务系统业务节点的数字化流程：
- 业主可以使用微信，线上下单，预约银行；
- 银行可以使用钉钉，在线节点与审批；
- 置业顾问和按揭专员可以使用企业微信，在线处理流程业务；
- 财务和运营可以随时进行放款效率分析、放款额度分析、回款预测，进而制定管理措施，落实贷款额度集中管理和现金流管理业务，省去围绕楼栋，多部门的海量手工更新工作。
在该房企的项目实践中，以数据资产为基石，提供数据服务接口，最终实现在极端时间内上线这样一套流程管控场景，需要在业务管理和数据分析两个节点之间建立畅通无阻的数据流转，使放款额、放款进度、银行剩余额度等数据可以应管理需要定时流入企业数据中心，进而自动生成确认放款统计表、待放款统计表、预告抵押登机统计表、审批通过统计表、需补件统计表等管理报表，并与管理驾驶舱的数据形成整合和联动，而不是由业务反复手工导入导出进行匹配、核准。
结语：
数据资产深度参与到企业的业务生产环节，同时也会在每个重要的业务环节中通过业务活动被不断更新。数据资产本身具备了极强的生命力和业务属性，掌控企业自身的数据资产就犹如苦练内功一般，将会使得一个企业在多边的外部环境中具备极强的竞争力。
数据资产与资金、劳动力、硬件工具等被一并列入生产要素范畴，也需要地产从业人员一并探寻研究，找出更适合自己企业的资产沉淀之路。
