房地产主数据管理全周期实践[转]

导读：全文共计1.9w字，预计阅读时间：50分钟。主要分为四个部分（房地产主数据管理、实施方法论、主数据清理以及日常运营）进行阐述，如有偏颇不足之处，还希望多多指导。

原创：成于念，赛助力 Lassiji 5月11日  https://mp.weixin.qq.com/s/Yi57Fub0-JjR3yXULsU2ZA

第一部分：房地产主数据管理

第一章：房地产主数据管理范围

房地产主数据管理范围是指在集团国内房产业务范围内，各个业务系统需要共享的“项目”相关基础信息，该部分数据具有较高的跨业务应用共享性，具体包括土地基础信息、项目基础信息、分期基础信息、楼栋基础信息、产品类型信息、装修标准信息等。

土地：集团通过招、拍、挂或者股权变更、勾地等方式获取的地块；

项目：1.以独资、收购、合作等方式获取的项目；2.开展开发建设活动的项目；3.房地产项目；4.对于收购项目，已光盘且工程款已清的也纳入主数据的管理范围；

分期：包括运营交付分期或者财务核算分期的概念；

组团：在城市居住区和居住小区设计中，将若干栋住宅集中紧凑地布置在一起，在建筑上形成整体的、在生活上有密切联系的住宅组织形式；

规划楼栋（工程楼栋）：包含纳入主数据管理范围的项目下对应的规划楼栋；

产品楼栋：纳入主数据管理范围的楼栋为一般分期下的产品楼栋，包括但不限于：公寓、写字楼、别墅、洋房、车位、地下室、厂房、仓库、孵化器、公共配套；

户：针对于整个房地产业务链，依据《房屋预售许可证》建立的户，包含了可售以及不可售部分的户；

装修标准：国内统一的装修标准：毛坯、装修

第二章：土地主数据

在讲土地主数据之前，需要先将土地的相关概念进行区分明确：

（1）生地。它是指可能为房地产开发与经常活动所利用，但尚未开发的农地和荒地，即待开发的国有土地，是离城镇较远、无市政基础设施、未开发利用的土地。

（2）毛地。它主要是指城市中需要拆迁而尚未拆迁的土地，即已有地上建筑物及附属设施的建筑物，将被改建的土地。

（3）熟地。它是指已完成市政基础设施建设的土地，达到“三通一平”或“七通一平”施工条件的土地。

（4）三通一平。它是指水通、电通、路通和场地平整。

（5）七通一平。它是指给水通、排水通、电力通、通信通、燃气通、路通、供热通和场地平整。

（6）宗地。它是地籍的最小单元，是指以权属界线组成的封闭地块。城市的土地，以宗地为基本单位统一编号，叫宗地号，又称地号。它有四层含义：区、带、片、宗，从大范围逐级体现其所在的地理位置。例如，B107-24这个地号表示B区第1带07片第24宗地。

（7）宗地图。它是土地使用合同书附图及房地产登记卡附图。它反映了一宗地的基本情况，包括宗地权属界线、界址点位置，宗地内建筑物位置与性质，与相邻宗地的关系等。证书附图即房地产证后面的附图，是房地产证的重要组成部分，主要反映权利人拥有的房地产情况及房地产所在宗地情况。

（8）项目地段。它是指根据项目所在地段的土地级别而划分的项目等级。

（9）土地级别。它是指根据土地使用价值及所处地段繁华程度的不同而划分的土地等级。目前，各地的标准不一。

（10）土地一级开发。它是指由政府或其授权委托的企业，对一定区域范围内的城市国有土地（毛地）或农村集体土地（生地）进行统一的征地、拆迁、安置、补偿，并进行适当的市政配套设施建设，使该区域范围内的土地达到“三通一平”“五通一平”或“七通一平”建设条件（熟地），再对熟地进行有偿出让或转让的过程。

清楚了对于土地的定义后，我们可以了解到在房地产整个业务链条中，实际在获取土地前就会进行投资分析对土地进行管理，土地获取后会继续进行立项管理。并且未来投后分析管理也可以按照土地的维度进行。

土地作为项目主数据的第一个数据项，也是最为重要的一个环节。实际上目前我们在去管理土地的过程中，在系统上有两种处理逻辑，会区分为实际获取地块以及虚拟地块，实际获取地块就有可能存在一个大地块或者若干小地块组合，那么将土地与项目进行关联的过程中，就会出现一个若干小地块对应一个项目，或者一个大地块按照明确的一期以及待规划分期的方式进行区分。

而主数据的管理维度需要明确，是按照实际拿地的地块进行土地主数据管理，还是按照虚拟的地块，方便后续投后分析的维度进行划分。

第三章：项目主数据

谈到房地产主数据定义，第一个应该就要说到项目主数据，项目定义在不同的行业均很常见，但差异较大，比如，我们常见的IT项目，也可以称之为一个项目，从PMP理论中是这样定义项目的，项目是有生命周期的组合工作，具备以下一些特征的均可称之为项目：

1. 有一个特点计划内要完成的具体目标

2. 有确定的开始和结束时间

3. 有经费限制消耗人力和非人力资源

其实说白了，项目就是为创造独特产品、服务和成果而进行的临时性工作。

房地产项目其实就是我们房地产开发过程中楼盘，小区，标准定义为：通过立项确认的，拥有同一个项目代码，围绕一块或多块土地开展的一系列开发活动总称。一个房地产项目可分多期进行开发。所以实际上了解房地产业务的人都可以清晰的知道，几乎所有地产业务工作都是围绕着项目来开展的，定义可一个项目也就框定了一群人，在一定期限和土地上，产出公司产品，达成盈利。

例如B企业是一家大型地产化主数据企业，在实施中首先需要明确数据OWNER，数据产生时点。一般项目最初的建立是从土地获取后，才真正进入房地产开发，所以项目主数据的OWNER一般设置为运营或者设计较为合理。在大运营的体系下，一般也可以以运营为数据OWNER，这样与实际业务体系有了合理的对接，这里考量点主要有几点：

第一、一般运营管控计划，会在整个项目获取后就开始，各业务部门陆续开展业务，所以一般获取后3天内建立项目，制定里程碑计划。

第二，大运营范畴下，运营属于统筹协调部门，需全盘考量项目，拉通各业务部门口径，故运营建立项目较为合理。

说到运营建立项目，一般土地获取后就紧张安排，比如B企业为3天，A房企控制为10天，这和集团业务管理节奏要求有关，开发节奏块的时候，这个时点要求短一些，开发节奏慢则可定长一些。B企业属于快节奏，而且还存在未获取提前建立项目的情况，这些都是基本已经拟定获取，为迎接市场环境，提前建立项目。

所以主数据项目的建立其实是以事实业务为依据的，定标准，各业务线条都需要按照规范执行。同时也要有特殊的场景满足业务需求。房地产业务主数据需要统一标准，唯一性、准确性、及时性。高识别，需要能够快速识别判断，项目名称，项目编码。

简而言之，房地产项目规则，首先立足标准，明确范围，明确定义，制定清晰的标准规则，范围上，如房地产，非房地产、商业、酒店板块等，只有划清楚范围，才能更容易识别，否则造成界限不清，导致主数据应用难以体现应有价值。

第四章：分期主数据

分期主数据从根本上理解，就是一个项目分多起开发，在每一期开发中有不同定义指标，比如我们的开发周期，整个项目持续的开发周期较长，可能四五年，这样的话，项目初期指定的计划指标有可能随着市场巨大的变化不在适用，市场快速的变化影到企业内部管控，外部应对，所以像这种持续时间比较长，项目体量比较大的情况，就会按照分期管控和开发。

分期划分的考量规则如下：

• 具有相同法人公司

• 具有相同利润中心

• 具有相同计税方式

• 双享跟投业务（基于净现金流、资金成本等考虑）

• 开发时间间隔（超过1年）

• 亦可基于拿地顺序、开发规模、政策要求等考虑

• 划分规则最终以四位一体会输出为准

以上的规则主要是基于业务应用，分期的划分实际上是一个管理的要求，正常来讲一个项目下包含多个分期开发，这是从交付周期角度去考量的。

第五章：楼栋主数据

房地产业务中对于楼栋的使用场景是非常多的，作为项目与具体房间承上启下的载体，楼栋管理的好坏直接影响整个项目。一般情况下，作为房地产主数据领域中对于楼栋的管理，主要分为两个维度：

1，物理楼栋（规划楼栋）：针对于房地产整个业务链，按照设计图纸上实际物理层级楼栋，或与申请工规证的报建图纸上的物理形态楼栋为主。物理楼栋解决了运营编制里程碑计划的问题，有利于运营条线按照物理楼栋进行计划管理以及工程巡检管理，同时作为物理楼栋的面积信息汇总能够有效的与项目进行勾稽校验。

2，虚拟楼栋（产品楼栋）：产品楼栋的维度则对于楼栋管理更加灵活，是按照产品类型的维度进行创建楼栋，这更有利于营销条线推货统计的开展，对于不可售的产品类型则选择剔除。但是往往容易出现部分的不可售的产品类型缺失，导致资产盘点流失。

值得注意的是，不管按照物理层级或者产品类型去创建楼栋，仍然会有一部分特殊类型往往会被遗漏。例如：地面车位这种产品类型，实际并不体现在楼栋层级，它并不含建筑面积，也不需要进行计划编制等业务。但是考虑到业务的完整性，还是建议通过建立虚拟楼栋的方式进行管理。

楼栋针对于物理或者产品类型两个维度进行管理，并非都是强制需要。例如，很多房企选择放弃对于物理楼栋的维护，而是通过产品楼栋上增加规划楼栋的标识形成批次，进行汇总。

也有房企选择只针对于物理楼栋进行维护主数据项，通过设计图纸以及报建图纸上的规划楼栋在系统录入，可以减轻一线业务人员录入的工作量，同时对于营销可售及不可售的需求，则下沉到房间层级，通过房间上的产品类型进行区分。

但是大多数的房企选择楼栋主数据的管理，都是结合物理楼栋和产品楼栋双管齐下，既解决了运营针对物理楼栋的计划编制和工程巡检还有标段采购等业务，同时也有利于营销针对可售的产品楼栋单独维护管理。

第六章：产品类型主数据

房地产中的产品类型也成为了业态，是用来区分房地产开发的不同类型产品的类别，一般实际中区分楼栋的分类比较简单，但对于行业内人士如按照功能区分：住宅、商业、厂房、公共配套粗放式的分类远远不能满足的业务管控要求，需要从多个维度细化产品类型，主要可以从三个维度来细化。

1、通过实际功能应用划分

可分为别墅、公寓、洋房等

2、按照楼层高度划分

低层、小高层、中高层、高层、超高层

3、按照楼体结构划分

可以分为砖木结构、砖混结构、钢混框架结构、钢混剪力墙结构、钢结构等。

对于房地产管理角度讲，更关注的是价值对比，通过对投入和产出的控制，实现利润分析最大化。所以产品类型的划分需要综合成本、销售、税费划分，便于精细化管控。将其组合，如下是某家房地产产品类型划分：

很多初入房地产行业的朋友会问，到底为何房地产企业内部管理需要将它划分为这个细度呢？主要原因如下：

产品类型细度核心点在于市场价值不一致，大类不用说，这是直观甚至是使用产权就能区分的，比如住宅和商业使用权限不一致，住宅为70年产权，商业为40年产权等，这样导致市场认可的价值不一样，就需要将其区分出来。对于洋房往细致了分如低层、中层、高层、超高层等，买过房子的朋友都知道，楼层的高度其实是影响房价的一个因素，同时也是影响建设成本的因素。所以将其细化出来，无非就是细化管理。每一类产品类型下的收入、成本、费用均能清晰的展现出来，这就是产品类型主数据细类的管理价值。

产品类型主数据值域表统一只是完成了第一步，已经形成主数据标准规范化，将投策、运营、成本、营销、财务多线条统一起来。看似简单的产品类型主数据统一，这其实背后牵涉的业务环节异常复杂，后面章节将深入剖析产品类型业务应用下的难点。

第七章：面积主数据

从标准定义来讲房地产面积数据不应该作为一个主数据项，因为从项目立项开始面积都在随着项目进度不断变化，颗粒度不断变变细。从项目立项开始，相应的面积指标随着设计图纸变化而变化，包括：强排方案版、投资定案版、规划设计版、施工证版、预测绘版、实测版。对应的面积指标非常之多，但可作为共性的面积指标数据主要有以下这些：

土地维度：土地面积（亩）、已开发占地面积（平方米）、建筑面积（平方米）、建筑面积（可售）（平方米）、计容建筑面积（平方米）、可售计容面积（平方米）、政府规划容积率、我司规划容积率。8个核心面积指标。

项目维度：项目占地面积（平方米）、建筑面积（平方米）、建筑面积（地上）（平方米）、建筑面积（地下）（平方米）、建筑面积（可售）（平方米）、建筑面积（可租不可售）（平方米）、建筑面积（不可租售）（平方米）、计容建筑面积（平方米）、不计容建筑面积（平方米）、车位数（个）、车位数（地上）（个）、车位数（地下）（个）。10个面积指标。

楼栋维度：总建筑面积、计容建筑面积 、可售面积、地上总建筑面积、地下总建筑面积、车位数（个）、套数（户数）。

户：建筑面积、套内面积、公摊面积。

这类面积属于使用最多的情况，可作为面积版本去定义和管理。面积的版本一般分为强排方案版、规划版、工规证获取版、预测报告版、实测绘版。面积的维度也是由粗到细的，强排和规划、到工规一般只能到项目和楼栋维度，预测实测阶段可到户维度。并且每个业务线条的管理维度有粗有细，如何将不同阶段和不同维度的面积统一起来呢，这是很多房地产面积管理的难点。有以下两种思路可以提供参考：

第一种方式，面积分阶段版本，最细及最新阶段的面积更新主结构的面积，原则上增加强制控制。如理论上项目的面积应该等于项目下所有楼栋的面积，但是一般情况下楼栋创建的时间又先后，在系统层面很难强制，但是如果我们巧妙地做一些提醒，效果会更好一些，项目的面积作为一个总数，建楼栋时不断做减法，当项目原先录入的面积小于实际面积时，就有了动力去更新项目面积，否则也建不了楼栋。

第二种方式，面积标准化，面积字段不纳入主数据架构，单独保留。按版本存储，不同的业务条线使用时根据阶段获取最新面积，每个版本作为历史版本仅作为参考，不再不统一。这样实际上认可了面积没有对错，只是版本不一致造成的差异，操作上简化，但是后期数据统一口径较难辨别。

当然无论采取哪种方式做面积主数据，都有利有弊，最终还是要结合企业的实际情况去规划，采用何种数据管理模式。

第八章：房间（户）主数据

房间作为房地产项目管理的最小颗粒度，承接了很多业务条线的实际业务。所以我们认为房间也是应该作为主数据进行管理。具体各个业务部门对于房间的使用场景如下

【运营条线】：可以将每一栋楼最早一户的合同交楼时间作为该栋楼的合同交楼时间，进行计划倒排和黑红黄底线预警。同时也能根据具体产品类型和户型面积段的户数和面积，进行供货结构的多维度统计分析。

而对于每一户（房间）的具体管控可以明细到：卫生间/阳露台——结构蓄水、门窗工程验收-洞口尺寸复核、门窗工程验收-门窗框填塞隐蔽验收、隐蔽验收-每户 卫生间沉箱回填、卫生间/阳露台防水验收、防水施工后蓄水试验、门槛石湿铺贴、每户饰面砖工程验收-墙砖弹线排版等管控动作。

【客服条线】：客服业务开展的颗粒度需要到户，具体需要具体每一户的基本信息，包括名称、街名路址、产品类型、装修标准、户型及户型图、合同交楼时间、面积信息等。

【营销条线】：需要对房间（特别是可售部分）进行全周期货量盘点、销控管理、价格管控、确认收入等。属于房间使用的核心部门。

【资产管理条线】：对于房间全集需要进行日常的资产盘点及盘活的工作，同时也要对房间的招商运营、租赁业务进行管理。

【财务条线】：需要对营销接收预收款数据生成单据和财务凭证：需要明细到房间，记录房间号、产品类型、装修标准、所属分期等信息。同时，通过房间收入信息的房间号、产品类型、装修标准、面积、所属分期等信息匹配明源成本分期、产品类型、装修标准、面积信息，计算结转成本数据，生成凭证。

对于将房间作为主数据项进行管理，我们同样归纳了两个方面的价值：

1、有利于房地产行业实现以客户为中心的竞争策略：通过户主数据打通，可以支撑大运营按照户的颗粒度进行计划、安全质量、客服等业务开展，实现精细化管理。

通过户主数据减轻录入户的工作量，保证房间录入的准确性和及时性，方便开展认购，签约等业务操作。

通过户主数据将资产数据统一实现销售、租赁与融资的信息对称，优化业务衔接。

2、有利于数据统一，协同共享，提效减负：实现项目域各层完成项目域：土地-项目-分期-产品类型-楼栋-户的全层级打通，维护到了户主数据颗粒度。

统一楼栋的可售不可售房间，实现户口簿的全集管理，保障了数据的整体性，有利于各下游系统的分发使用。

把户生成的系统作为唯一上游源头，保障了户的唯一性，杜绝一个户被各业务系统重复使用，同时也保障了及时性，有利于下游系统及时开展业务。

第二部分：房地产主数据项目实施方法论

第一章：主数据数据OWNER定义及处理原则

主数据应用上线后，我们会发现数据录入是一个简单的动作，但是同时也蕴含了很多管理上的道理以及规则。

在数据录入的过程中，需要和各业务部门以及系统协同工作，并且需要通过制定并且执行统一的基础数据标准和管理制度，将组织，流程和技术平台三者有机结合。

在一般情况下，在多个业务部门协同共享使用基础数据的时候。就会面临着，到底谁录入这个数据的问题。例如如果是交易数据（交易合同，成交价格）只是营销部门使用，必然是营销部门进行录入。

但是如果是基础数据（跨业务，跨系统，跨技术）的产品信息，除了营销部门使用，还有成本部门，采购部门，财务部门使用。那么就会出现，由谁去录入的问题，如果处理的不当就会出现部门之间相互推诿扯皮的情况发生。

1. “谁生产谁录入”原则

当各个业务部门需要使用某项基础数据的时候。如果采用谁生产谁录入的原则，优点是由于是生产该类数据的部门进行录入，在数据准确性上可以有充分的保障。

缺点是如果该类数据生产部门并不会直接使用或者根本不会使用，那么在录入及时性上可能会打折扣。

2. “谁使用谁录入”原则

如果采用谁使用该基础数据谁录入的原则，优点是由于使用业务部门对于数据的及时性要求较高，所以数据及时性可以保障。

但是由于该类数据的源头可能并不是生产的部门，那么需要先找到生产这类数据的部门进行沟通，沟通成本较高，且存在准确性，完整性的问题。

以上文说到的房间主数据生成为案例，一般情况下，房间作为房地产的产品，使用部门主要是营销部门，开盘认购签约等业务流程都需要使用到房间。

但是房间的资料信息一般情况源头是在设计部门。他们对于房间并没有太大的使用需求。这个情况下，如果选择“谁生产谁录入”房间资料，就可能存在录入时间节点不及时的问题，导致营销部门业务可能无法正常开展。

如果选择“谁使用谁录入”房间的原则，可以保障营销部门的正常业务开展。

但是要注意，对于营销部门不需要的一些房间，例如：不可售的公建配套，租赁商业的房间，可能存在缺失的情况，导致数据的完整性缺失。

数据的录入，必须要保障的三大原则：

• 及时性：如果数据录入出现了滞后，则会产生很多冗余的垃圾数据，系统将失去使用价值。

• 准确性：数据如果录入的失真，则系统会源源不断的产生错误数据，对于高层决策将带来很大的影响。

• 完整性：数据如果只是录入了一部分，或者缺失某些数据，可能暂时不会影响某一个业务部门的业务正常开展，但是站在高层的视角去看，数据的完整性无法保障，同样也影响高层决策，以及其他业务部门的业务开展。

面对共享的数据录入这类问题，源头录入放到某一个业务部门可能都面临着取舍，对应的处理原则都存在利弊关系。但是我认为同样也有解决办法，那就是业务驱动，制度保障，系统支持。

• 业务驱动

数据是核心业务实体的客观反馈，所以说数据服务受益最大的对象是相关的业务管理部门，任何原则也好方案也好，必须要紧密依托业务流程。

所以，数据录入的前提保障就是需要对应的受益方业务部门主导工作并执行。

例如对于房地产行业，营销售楼卖房是最关键的事项业务之一，所以尽可能的保障这一部分的业务开展，建议还是由营销去管理房间的信息。

• 制度保障

通过数据标准化制度管理。如何保障数据录入的及时性，准确性，完整性。

无论数据谁去录入，源头是哪个业务部门，都需要制度进行保障，要注意，没有制度保障的业务操作都是耍流氓。

• 系统支持

作为系统产品设计，以及项目需求解决方案。都要结合业务充分考虑到系统层面的支持，数据在系统层面除了解决便捷性之外。还要配合业务管理，配合制度手段。这样才能更好的落地执行。

例如上面说到的数据录入，通过系统逻辑校验，比方说数据的完整性如果没有通过，则系统校验数据无法审核通过。

这样就倒逼业务录入人员，强制要求他们在录入的过程中，保障数据的及时完整。如果数据是有一些证照作为录入的凭证，同样也可以利用RPA机器人自动录入，保障数据的准确性。

第二章：主数据与货值管理

随着社会不断发展，国家政策不断完善，宏观调控不断加强，房地产已经从黄金时代步入白银时代，随着拿地成本越来越高，这个时代更强调管控为王，只有通过内部的精细化管控企业才能提升利润，越来越多的企业在外部大市场环境影响下，倒逼企业自身需要不断提升管理水平、提升公司运作效率，同时对产品管理有了更高的要求，如对产品需要全周期掌控，这样能够不断提升产品品质，增强企业核心竞争力；把握全局，重点突击内部关键指标，成为企业管理效率提升的一个重要策略。

企业货值成为当下房地产企业迫切希望盘点清楚的一个核心指标，集团需要通过运营统筹规划，保障公司资产价值链各环节风险清晰可控、指标可量化，产品实现供销平衡，最大程度上保证企业以销定产。

货值管控其实就是综合化的管理过程，为了实现年度（战略）目标，通过对各个阶段的数据监控，辅助企业从拿地、融资、去化、回款等一系列动作进行精准决策、监控督办、参与执行的管理过程。货值管理按照房地产全周期的角度最早可以从拿地开始盘点，直到销售后转化成收入结束，基本贯穿了整个房地产开发过程，其中核心管控点在于项目开发过程中，如实有效呈现各阶段产品总价值，以便提供集团进行决策及有效应对市场环境变化。

货值的变化深层次反映的就是企业经营动作的变化，供货、定价、产品不同层面的市场变化 ，体现了以目标、开发、销售为的核心的管控指标下，整个企业运转变化。 通过货值管控，我们可以清晰理解定案承诺的 目标，掌握阶段中货值变化应该遵从动态曲线，围绕着一个有效的值波动，过程中可能会随着市场行情、定价、推货节奏会出现波动，但均在一个正常范围内波动，超过该范围就需要管理层重点关注，是否需要采取相应的应对策略。严格来讲货值动态波动曲线应该和价格波动曲线类型，但实际情况来看房产和一般的商品还是存在不一致，房地产更多受到政策及外部环境影响较大，其中细节不在此赘述。

货值完整性地讲其实可分为静态货值和动态货值，静态货值如前期的目标/规划版本统计出的货值，过了某个阶段就不再频繁变化。动态货值则是一个实时变化的值，按照销售口径可分为：已售货值和未售货值，完整的的货值应该为两个指标之和，从两个部分的货值占比可以预估出企业的经营状况，是采取何种管理手段，是需要加快工期开发、还是采取刺激销售、加快推盘策略。

货值的计算规则各企业大同小异，项目货值一般来讲均需要按照产品类型维度统计，更细的也会到楼栋维度，依赖的基础数据包括产品类型、楼栋、面积、价格等。计算规则依赖于最基础的货值=可售/建筑面积*价格，其中面积货量按照项目进度也分为了很多版本，方案版、施工图版、报规图版本、预测版本、实测版本。价格在不同的阶段也有不同的体现，如前期拿地预估均价、定案价格、预估售价、房源预售价、成交价等。在不同的业务主责环节中，投资、运营、成本、营销都在不同阶段有着各自的应用，在合适的节点获取合适版本的面积和价格是货值统计的一大难点。遇到不同阶段的面积搭配了不同阶段的价格，也是造成集团货值差异的一大原因，所以只有真正的区分好不同阶段基础数据应用，明确这个差异，各业务方达成共识，才能做到货值口径统一。

如果一家企业货值统计还存在不清晰、不准确、不及时的情况，说明这家房地产企业数据管理还有待提升。在日常工作下不断积累的基础数据，需要时时关注，定期优化梳理，搭建好稳定的基础数据，才能得到可靠的高阶核心指标数据。企业才能立足当下，谋划未来，让数据在企业管理决策中的体现出真正价值。

第三章：主数据与投后分析

投后分析即为投策后评估，是针对投资定案表确认的关键核心指标，完整链条是基于利润为核心及如下测算逻辑进行的：利润=收入-成本-费用-税金，在拿地是，我们会基于目标地块做利润预测，做可行性分析报告，这其中就涉及以上的各种核心指标。对于企业内部考核来讲，我们需要各部门共同协作，严格测算好收入、成本情况，在过程中和过程后对这些指标不断进行监控，优化管理策略，实现利润目标。

这里不得不说的就是我们指标的确定，各业务部分承诺影响利润的的核心指标均统一体现在定案表中，基于定案的指标，包含运营、商管、营销、财务、成本、设计以此为依据。过程中监控定案偏差分析和执行风险预警管理。

营销投资定案中的目标指标：定价底价，产品售价、产品的溢价率，预计总货值，预计签约货值。这些指标均可作为营销管理考核指标，针对项目的签约、回款、销售计划执行、开盘情况做对比分析。运营线条核心为计划节点包括方案报批时间、开工时间、开放时间、开盘时间、预计总货值、各年推货及销售节点，主要分析：实际里程碑完成时间，实际总供货。成本定案承责指标为目标成本底线，项目总成本、各业态成本。实际过程需要动态进行监控。财务指标为年化回报率、净利润、回正时间、融资计划。实际过程监控实际利润、实际回证时间。整个过程均基投资定案输出及接收。

如果要完成货值及投后分析，则需要完整准确的数据质量作为保障，接下来第三部分将详细介绍主数据清理工作内容。

第三部分：房地产主数据清理

第一章：数据清理前瞻

数据清理，即将不规范不合规的历史数据进行清洗，以达到业务需求的使用标准，是数据清理的目的。

主数据清洗顾名思义就是把历史的数据进行梳理，原来说不清楚的，不知所云的数据进行整理，重新给予业务价值定义。原先的数据没有按照一定规则录入的，要按照特定规则明确定义。

主数据清理主要一环制定清理方案，清理方案内容包含清理的目标，清理的范围、清理的原则。

其一，数据清理的目标，即为希望通过本次数据清理能够达到什么样的目标，实现哪些数据的标准化，清理主数据实现基础数据标准化及口径统一，为业务协同和统计分析自动化提供数据拉通基础。一般来讲主数据清理目标无非就是理清错综的交叉数据，去掉重复脏乱的数据，以此规范主数据，通过主数据拉通各系统间的业务数据基础。如指标拉通，业务数据提速，投后分析等进一步的数据分析需求，立足于业务需求点。只有明确需求点，才能往下拆分，形成数据清理的推动思路。

其二，清理的范围，在没有调研清楚业务需求的情况下，就很难说清楚我们的清理范围，未来我们标准化的数据应该如何。明确出清理范围才能最数据清理工作量进行评估，对数据清理中遇到的问题有个界线，否则未明确出范围对数据清理实际就是摸着石头过河，过程无法有效把控清理遇到的问题，无法有效处理的边界，这是数据清理的大忌。

其三，清理的原则，这是对整个数据清理达成的强规则作说明的，如，对房地产项目主数据进行清理，可以制定如下原则：

Ø  投资定案表与土地之间为一对一的关系；

Ø  土地与项目为一对一的关系；

Ø  项目与分期之间为一对多的关系；

Ø  分期与楼栋之间为一对多的关系；

Ø  分期与利润中心（账套）之间为一对一的关系；

Ø  楼栋与产品类型为一对一的关系；

Ø  利润中心（账套）与法人公司为多对一的关系

这样的原则明确后，我们同时还应当制定，以哪一个为基准去梳理，以核心业务关联的项为准，如以财务的核算、利润中心为基准，同时去满足以上的原则。这样整个数据清理的原则才算完整。

其四，数据清理标准，数据的标准更多的是基于未来数据方案已经明确

前提下需对历史数据也进行规范。所以清理的标准可以描述具体主数据项的字段定义，字段值域，这里的标准其实都是来源与未来方案及系统架构制定后，我们需要的数据标准。

数据清理很关键，无论是主数据的清理，还是业务数据的清理，都是对历史做一次梳理和总结。所以一般来讲对于历史清理的程度还是要取决于未来的应用价值，在数据清理中我们也会经常听到这样的声音，XX 数据已经很久远，项目人手已经不知去向，无法重现但是的情况，无法进行清理；XX 数据对系统业务数据改造量太大，不建议清理，所以清理过程中就会出现的妥协方案，这也不能说是不好的，毕竟数据清理是一个庞大的工程量。这其中涉及很大的效益问题，一味按照严格的方式，对历史的冲击很大，也是得不偿失。

其五，数据清理价值，这块其实很难说清楚，可能数据清理很多时候时候属于新系统上线之初，一种新的模式建立起来，这时候数据清理才有意义。因为对未来充满设想，未来的方向是什么样的，要实现的价值点是什么。这个要紧密的和管理变革一起，否则脱离业务的涉嫌其实纯粹是浪费资源。所以一个好的需求点是做数据清理最好的目标，可以随时纠正数据清理的方向，明白价值，既可以日数据清理有目标有方向，同时也能明确清理的底线，这很重要。因为清理的标准不同索要付出的成本是绝对不一样的。

数据清理是一件复杂且耗费体力的事情，要紧的还要领导重视，上传下达，人员配置至关重要，一般数据清理都是由基层的业务人员逐一完成的，因为只有他们最清楚数据的真实情况，同时安排熟悉的人做方法指引，上方明确清理的重要性和要求，下方则按质按量完成数据清洗。过程中配置好各方组织人员，包括问题解答，疑难讨论，指引传达，问题指引更新，最终达成数据清理价值目标。

基于数据治理与分析，数据清理其实是数据治理的第一步，几乎所有的数据清理都很难做到一次清理彻底，所以在这之前一定要划分清楚范围，切记喊口号，导致最终清理失败，做到不清楚的数据标记清晰，额外区分对待，清晰的数据严格把关，很多数据都是逐步发现，逐步清理，数据质量才能逐步提升的。

第二章：数据清理步骤

数据清理第一节讲清楚了，为何要做数据清理，清理的总体方针后，接下来就需要进一步，来细化工作，首先的弄清楚整个数据清理的事项有哪些，这一块包括了清理准备，实际清理步骤，清理验证，及清理后监控。每一块都有基本的事项需要去做，首先我们先来谈谈清理主要工作：

1、成立相关清理组织

数据清理实质上应该使用项目管理思维去做，成立相应的组织架构人员，包括清理统筹领导，项目经理，PMO，核心的业务对接人，系统对接人，清理执行人。

2、清理计划

制定清理计划，要充分评估清理数据量，清理难度，清理资源，制定核心里程碑节点，重点把握，同时需要定期和汇报领导。计划的价值主要在于跟踪和监控，了解项目最新情况，所以计划事项可粗可细，依据项目实际需要为准。但需要认清的是计划毕竟只是跟进工作的进度，是结果导向，不易花费过多精力和时间，否则导致本末倒置，重点还是应该放在数据清理实质工作上。

数据清理计划可如下：

序号	事项	主责组织	配合组织
1	成立历史数据清理专项工作小组	XX总
2	数据清理启动会	全体成员
3	历史数据清理方案及基础数据模板准备	方案牵头方
4	数据清理研讨会	业务清理执行层	业务、数管
5	区域上报清理方案、清理计划	区域业务牵头人	业务、数管
6	历史数据清理方案评审	业务中心	业务、数管
7	各业务中心发生分歧的，由领导组决策	决策组
8	数据清洗   – 业务系统主数据对应关系调整	区域业务牵头人
9	数据清洗 -   业务数据调整	区域业务牵头人
10	业务应用场景验证（如指标、双享、货值验证）	区域业务牵头人
11	区域签字确认	区域业务牵头人

3、清理方案制定

清理方案制定包含了前文提到的清理原则、目标、要求、清理验验收标准等，但更为核心的还有清理模板，清理指引文档。

一个完整清晰的的模板，对整个清理工作的成功与否有着决定性作用，清理模板制定包括了清理的表格字段有哪些，清理的字段的值域如何定，清理的数据的源从哪里来。比如下面这样的模板就很好：

数据清理模板配套着基础数据参考，这些数据清理基于数据标准规则制定，按照实际业务价值，应该明确哪些字段重点处理。模板建议尽量少的附件，切记多个文件表，最后造成清理执行中，业务混淆，增加清理过程的沟通成本。

4、清理启动会

清理启动会和意义和项目启动会是一致的，增加清理工作领导的认可度，组织层级中领导级别越高，对清理工作推动力越强，对后续清理越有利。在会中，可请业务职能线领导讲话，统一目标，统一步调。介绍清理的整体思路和方法，算是为整个数据清理做一个完整的开始。

5、清理工作开展

数据清理真正的内容就是处理垃圾数据，规范当前数据要素，主要分为主数据清理和业务数据清理，两者对于数据拉通缺一不可。

数据清理检查的方法可分为以下三种类型：

【残缺数据】：针对于必填字段信息存在缺失的情况，需要进行补录。这部分数据在清理的过程中是相对容易的，一般的操作方法还是基于系统的字段判断，将这部分残缺数据通过线下表格的方式导出，统一由业务人员进行补录后再次导入系统。但是这类残缺数据的清理过程中，还是会遇到一个情况。就是历史太久远，大家都不清楚数据去哪了。

【重复数据】：重复数据的处理在整个数据清理环节里面属于中等复杂。原因是如果系统间存在主数据编码或者有统一的标示，那么我们基于这类规划进行筛选，是很容易检查出各个系统的重复数据。然后人工判断保留哪一条。但是，绝大部分数据是没有这种唯一标示进行去重的，比方说A项目和A1项目通过业务确认，其实就是一个项目，只是名称的不一致。这类数据核对的工作量是非常大且困难的。所以核心还是要找到数据的唯一标示，如果名称不是唯一，那么例如土地地址，某些技术指标仍然是判断是否重复的条件。

【错误数据】：错误数据在整个数据清理工作中属于最难最重要的环节。对于错误的概念也是很难定义，某些数据在特定的时间段和特定的环节可能就是正确的数据，但是依然需要按照错误数据进行清理。同样的，错误数据也存在系统判断和人工判断。例如日期填写不正确，字符错误，数值范围不符合逻辑 （ 常识性规则、业务特定规则等）等都可以通过系统判断筛选。但是还有一部分业务数据只能通过人工判断，这部分的清理工作仍然占据了大部分数据清理时间。

基于发现的这错误数据，如果能形成一定的规则，则可通过系统数据辅助清理工具批量处理，比如：数据迁移工具，进行批量替换转换；数据审计平台通过检查报表的方式筛选问题数据，提高清理效率；数据清理工具，通过建立映射关系匹配多源系统的数据，减少业务数据调整的工作量。

业务人员清理过程中相应的指引解答是必要的，数据变化千千万，但是规则是统一的，系统的准入门槛需要明确。

6、数据清理核查

数据清理业务处理完成后，很多需要系统人员协助导入系统。一般数据清理的量比较大，另外一方面数据清理的标准是新的，这部分清理的数据需要区域和集团达成共识，业务认可才是意义的数据清理。所以，我们一般对于区域清理完成的数据，会有集团相应的人员统一进行核查，既要符合数据清理标准原则，同事检查数据是否有遗留，填写不规范问题。

这对于最终数据导入到系统中是非正常重要的，否则数据清理为检测数出错误，导入系统是发现翻入不了，就会耽误项目进度。

7、数据核查后业务领导确签

数据清理完成，业务领导签字是必不可少，非常重要的步骤，如果你不想未来数据应用中出现问题，无法解释，就需要权责明晰。就要安排职能线领导决策签字，一来可以让大家都重视数据效果，二来明确数据标准。能够将区域业务、系统建设方、职能线都在一个维度上，对后续的数据建设工作非常重要。

8、数据安排导入及修改

数据清理最终一步，则为数据系统导入工作。主数据的清理一般涉及各业务线条交圈，原来口径不一致的数据会出现拆分、合并情况，来实现一一对应。同时针对于原口径下的业务数据也需要拆分，重新划分。所以一般系统数据处理，需要先将主数据处理完成，接下在做业务数据调整，如财务调账，成本数据拆分等。

完整的数据拉通不仅需要主数据拉通，同时还需要业务数据拉通。所以这一点上对于很多企业实施是非常的困难的，这其中不仅涉及了大量清理的工作量，同时还涉及各方利益，是一个非常难以协调的事情，但往往能坚持到最后的企业，最终看到了数据横向的拉通。

第三章：数据清理后监控

数据清理后需要有相应的机制来监控数据效果，这里不仅不含了历史数据还包括新数据的监控。

监控新数据是否按照主数据规范进行录入和使用。

基本监控主要分为以下几种方式：

1、巡检分析报表

在基于数据中台大平台的基础下，数据监控变得现实。在数据中台抽取各系统使用的主数据做对比，包括数据，映射、调整。

数据的抽取存在很多规则与要求，因为每个系统的控制逻辑不一样。需要单独抽取，比如很多系统中保留的期初数据，状态、结构为无效的数据需要明确过滤逻辑，才能抓住数据本质，找出数据差异，并针对性行的进行修改，建立切实可行的长效机制，如下的巡检报表

①、主数据项目为所有项目全集 ； 

②、所有项目必须与主数据项目一一对应

③、分期产品类型的差异对比 ；    

④、分期与利润中心的完整性、一致性校验

⑤、楼栋是否拥有主数据编码 ；    

⑥、营销楼栋对应分期与主数据楼栋对应分期差异对比

⑦、主数据与投策土地一致性 ；    

⑧、土地与项目对应关系的完整性、一致性

如对于项目主数据，因为主数据的纳入的分为有限，对于财务核算来讲，项目被当做一个辅助核算字段即可，所以有一些虚拟的项目会属于财务单独管控的范围，这时候你很难将该部分都纳入到主数据管理范畴中，所以只能增加标签，将数据区分出来，在数据拉通过程，也并不需要这部分数据进行交互，系统也能够快速识别出来。

实现自动化的巡检规则后，可实现自动取数，自动发现问题，邮件发送提醒相关人员。同时针对问题数据需要及时处理，对于经常发生的问题要形成汇报机制，反馈至数据标准化委员会进行通报整改。

2、手动巡检报表

这方式的工作量比较大，但是效果要好一些。主要是为了前期数据上线后，规则未确定时，按月或按周导出各系统应用的主数据信息，进行人工核查，出现主数据应用不规范的问题马上整改，防微杜渐。将主数据的质量逐步提升起来。

3、业务场景验证

这方面可以从业务场景应用角度来检查，将数据应用放在第一位，基于业务需求场景，站在集团的角度将多职能线的数据组合，通过主数据进行拉通，如果在拉通过程中出现问题，基于验证的角度，就可以发现各系统全周期过程数据的问题。根据这些问题，制定相应的数据清理解决方案，进一步优化数据，完成数据质量升级。

 

第四部分：房地产主数据运营

第一章：搭建数据管理部门—持续进行数据分析运营管理

数据在各个企业集团的应用地位越来越重要，如何有效地利用企业经营过程中产生的数据，从海量的数据信息中提取出有用的模式并对其进行分期，挖掘，应用已成为大家的迫切需求。企业正不断将数据分析，数据挖掘视为重要部分，将数据转化为价值，提升企业的核心竞争力。

目前各大房地产企业现在逐渐的都成立了数据管理部门。常见的职能架构包括分散式架构（各产品线下单独设置数据管理岗位）和集中式管理部门（企业数据工作集中在一个中心部门）。按照数据的及时性，准确性，一致性的管理要求，集中式管理可以有效解决数据源和数据口径的一致性问题，因此这种模式在企业中较为常见。

同时，集中式管理在企业成立一个数据管理部门，也可以按照当下最流行的中台战略，将整个集团的运营数据能力，产品技术能力，对前台业务行为强力支撑。对于每个前端的事业部，或者产品线。数据管理部门作为中台，输出数据方案，数据分析，埋点，用户画像等等支持，源源不断的输送炮弹。

这个模式固然在当下固然非常流行，但是也有它自己的弊端。

首先这种集中式部门管理，属于弱矩阵的组织结构会导致数据管理人员出现多头领导的情况，在自己部门需要负责本部门的职责外，同时还需要作为中台对外输出，协助其他业务部门以及产品线进行数据工作。多头领导情况下，沟通渠道增加，各种事项增加，这样会导致以下几个连锁反应：

一，上级领导逐渐增加，导致整个组织架构显得有些臃肿。而实际项目经理更像一个协调者或联络员， 并不能完全按照自己的意图来规划和执行某个项目,需要通过协调,评价,经验来完成一个项目。导致整体的数据管理规划工作缺失。

二，重复工作增多，内耗严重。由于涉及了多条线的配合，以及本部门的工作，同样的工作计划，以及资源排布需要发给不同负责人，往往到最后作为中台的同事就这样每天疲于奔命的完成各项指定任务，实际工作反而没有时间安排。

三，沟通渠道增加，导致沟通成本上升，增加项目的整体风险。

而弱矩阵从弱到强，核心也是人的变化。数据管理岗是一个轴，对于这个轴，我们有理由有要求让他从弱到强，从而更好的避免工作陷入泥潭，从容应对。

一，提升整体的项目规划能力，将数据折现成为实际价值，需要整个部门所有人都有较强的项目规划能力。否则永远只能拆东墙补西墙，一个较强的数据管理者，应该像下棋一样，走一步想三步。这样整体的工作也会从被动转为主动，第二就是能够将诸多被动接受的事项进行优先级的排序，井井有条，稳步向前。

二，掌握抱大腿的套路，数据管理部门作为中台服务部门，是缺失业务部门的有利支撑的。当遇到数据问题或者争议时，往往陷入到无休止的会议争论中去。擒贼先擒王，辨析到底核心业务干系人是谁，将价值传递到位后，抱紧它的大腿。往往问题就可以迎刃而解。

三，赋予数据管理部门更多项目权力，特别是针对于跨项目使用的数据，以及核心数据的管理，数据分析。作为统筹方需要除了统筹的权利，还要有一定的决策权力，而对于一些简单的沟通协助工作，仍可以维持弱矩阵组织结构。简单来说，整个组织是“高耦合低内聚”的一种状态，同时每个人具备单兵作战指哪打哪的能力。

第二章：主数据运营保障措施-管理制度编写

数据标准管理在整个基础数据管理中至关重要，很多时候完成了基础数据平台的搭建，做了数据治理，并不意味着工作就完成了。

制定统一，规范，科学的基础数据标准，才是实现企业各部门间数据交换，资源共享和信息基础的前提保障。制定有效的标准并落地，这样才能最终保障企业各信息系统间数据交换的准确性与高效性，促进业务协同运作以及管理。

很多时候在一家企业，信息化中心是属于服务部门，服务部门偏弱势，而维护基础数据又是属于价值偏隐性的工作，大多数不被重视。

但是，作为基础数据的维护者，管理者，标准制定者。必须要主动，要强势，要有整体大局观。基础数据作为各业务中心的数据枢纽，必须是要通过业务进行驱动。但是大家众口难调，很多情况下站在自己部门的角度去分析数据处理逻辑，期望最大程度减轻工作量，但是却影响了其他部门的数据使用。

这个时候就需要基础数据敲敲黑板，统一一下标准规则了。

基础数据标准管理内容具体包括如下几点：

一、基础数据标准的制定

标准的制定有利于落地执行，所以当基础数据上线阶段，针对于数据标准的采集以及业务使用反馈情况，进行相应的标准分析，各使用方业务中心验证审批后进行发文执行即可。

标准管理制度应该包含且不局限于以下内容：总则，组织机构以及职责，管理要求，沟通机制，考核监督机制，附件等。

总则：概况性条文，描述本制度的适用范围，主数据管理的目标，范围，基本原则及要求等；

组织机构与职责：描述主数据管理的机构设置情况，包括决策机构，主管机构，专家服务机构，执行机构，运维机构及应用机构等，定义其相应的管理职责；

管理要求：详细规定信息化建设各阶段主数据管理的内容，要求及明确承担单位；

沟通机制：建立主数据管理过程中相关问题的日常沟通机制及信息共享平台；

考核监督机制：制定管理制度的考核指标，考核结果发布机制及监管单位，以及基础数据管理的奖惩机制等；

附件：例如基础数据项的编码，命名规则等。

二、基础数据标准宣贯培训

发布后，需要有针对性的进行培训，对标准进行宣贯推广。建议按照先集团各业务中心，再扩展到各区域。

很多企业只是将管理制度进行发文，但是却忽略了宣贯的重要性，如果有条件的情况下建议领导站台进行宣贯，配合多次业务培训，最终达到心照不宣的效果。

三、基础数据标准的完善

由于存在试运行，或者需求调整等情况发生。建议一定时间收集反馈意见，同步进行标准内容的修改和完善，修订评审后再次发布。

四、基础数据标准考核

光说不练嘴把戏，如何更好的将标准落地。离不开考核制度，建议针对于数据的及时性，准确性，完整性采取抽查的方式考核。

第三章：主数据管理的局限性

从主数据的概念定义上理解，主数据表示业务实体对象的基准数据以及其被引用的关联属性信息。例如每个人的身份证号码就是主数据编码，而对应的性别、年龄等就是属于被引用的关联属性信息。我们再进一步理解，在信息化领域对于主数据定义：对于某一个业务实体对象中，包含基础数据（静态或相对静态的数据）中被两个及两个以上业务系统共同使用的属性字段。这个定义是相对合理的，短期内也被各厂家推广使用，这也是目前国内主数据厂商对主数据的统一标准定义。

但是我们会发现，不少企业将主数据管理平台进行了推广和使用，还是没有从根本上解决数据质量的问题。反而投入的人力物力越来越多，收效甚微。

一、主数据静态性与动态性的悖论

前面讲到主数据的一个特征便是业务实体对象的属性字段是需要静态或者相对静态的。这实际上也是主数据的核心特征之一，如果要确保各个业务系统能够进行匹配拉通，那么对于业务实体对象的主数据定义必须是要静态的。例如我们每个人的身份证号码，它一定是不能随意更改，确保唯一性的。

但是在企业实际的发展过程中，特别是目前企业的转型的过程中，企业业务系统的新增和更换，原来被主数据厂商识别出来的主数据已经无法满足新的业务系统的上线需求，需要重新进行主数据的扩充识别和相关模型、流程等的变更操作，从而造成了主数据管理平台后期运维成本的居高不下，严重违背了实施主数据管理平台的初衷。

例如房地产行业从粗放型转为精细型管理的过程中，需要扩充主数据项。原本管理的维度可能是项目、分期、楼栋的维度，接下来需要对于每一户进行管理。那么实际上原本固定静态的主数据层级架构就会发生调整，在调整的过程中，我们可能会想当然的认为其实只是加一个”户”的主数据项，但是问题来了，增加一个主数据维度真的那么容易么？对于户的主数据属性字段、元数据管理的范围定了吗？不需要补充它的历史取值？不需要找业务部门的主管们讨论、协商？数据OWNER是谁？

我们会发现花了九牛二虎之力识别的主数据管理范围和主数据字段，没过多久就因为业务需求，场景变更进行了调整。我们所谓的主数据静态性并不是那么静态，甚至还具备动态性的特征。而主数据项的增减，以及对于主数据项的属性字段的扩充都无疑增加了额外的工作量。

我们了解到主数据的这个特征后会发现，随着企业的发展，业务场景越来越多样化，动态性的影响也会让我们对于主数据管理工作更加头疼。

二、主数据无法满足所有的业务场景

我们在做数据治理的时候往往会和主数据治理混为一谈，但是实际上这两者只是包含的关系。数据治理的范围应该是更为宽泛的范围，如果我们理解完成主数据平台搭建后，就能实现各个系统各个场景的数据拉通，实际上是有失偏颇的。

所以我们说业务场景数据管理和主数据管理是两个层面的问题。这两者的重要性没有高低之分，从数据治理的角度出发，如果我们无法管控业务场景数据，首先主数据管理将变成一件没有意义的事情，第二个问题就是业务场景的数据对现有业务以及未来数据中心的不会起到有效支撑。

例如在做房地产主数据管理的过程中，楼栋以及面积需要解决的问题其实无非就是：数据OWNER、录入时点、数据标准等问题。但是实际上管理了楼栋和面积也并不能解决货值管理的业务场景，对于业务数据和指标体系而言，主数据只是迈出了第一步，接下来业务场景数据管理才是最为关键的一步。

总之，主数据管理并不能辐射到系统所有的业务数据质量，同样主数据管理无法满足业务场景导致的数据治理障碍也越来越明显，所以可以判断的是，如果没有长远的规划，很多企业的主数据系统大多亡羊补牢甚至推倒重来会成为了主数据管理的一种常态。

三、主数据逐渐沦为赋码平台

企业在上主数据平台进行管理的初衷之一，就是寄希望于通过主数据拉通改善数据质量。但是目前绝大部分企业反馈的都是收效甚微，原因就是主数据管理作为多条线多部门协作的事情，从数据验证机制、巡检机制、管理规范、主责部门、录入依据等等环节上都体现了管理的难度。

主数据项的属性字段有没有维护，维护的质量怎么样，是主数据运维的核心。但是受限于上游系统，主数据真的能管理好么？还是逐渐沦为了各个业务系统赋码的一个平台。

任何产品平台我相信都会存在一些局限性，没有一味药可以治百病，核心还是要对症下药，搭配其他的管控机制以及治理方式，才能最终实现数据价值。