主数据的实践和思考

主数据是指公司的核心业务对象数据，对于公司的大多数主数据，虽然可能存在不一致，但大多时候问题并不严重，因为如果不一致问题已经严重影响到了生产，业务肯定是要强力介入并进行解决的，比如立个项，主数据的大多数问题在业务从0到1的建设过程中就已经基本解决了。

因此，数据治理要解决的主数据问题，大多是业务当前还能容忍，但长远来讲成本可能很高的问题，也就是重要而不紧急的事情，考虑到各个部门屁股决定脑袋的特点，主数据存在着天然的驱动力不足的问题。

相对来说，IT部门是有解决主数据问题的动力的，作为业务的支撑部门，IT部门有责任为了确保数据一致性临时做大量的补偿工作，让很多主数据问题看起来不那么严重，业务部门有时候能够容忍，不是说能容忍不一致，而是能容忍不从根子上解决问题，但IT部门一般没有能力去彻底解决问题。

那么谁最会考虑这种重要而不紧急的事情呢，谁又会考虑这种全局和局部的问题呢，显然是公司的管理者。因此，主数据的业务驱动一定首先来自公司管理者，只要管理层不觉得痛，跨领域的长期积累的主数据问题就很难实质性解决。

大多是公司管理者在处理跨领域事情的过程中感觉到的，比如发现业务和财务口径不一致，前端和后端数据不一致等等，这些不一致必须对公司决策和生产经营产生了实际的影响，这个影响持续存在且在不停刺激着管理者的神经，比如每个月都来一次，这个时候公司管理者才会真正重视，想着如何去解决问题，毕竟跨领域协调对他来讲也是件成本很高的事情。

《华为数据之道》提到过其做数据治理的起因，就是因为发现财务数据不一致已经影响到了管理层的决策判断，华为CFO后来还成为了企业的数据责任人，因为CFO是感觉到最痛的人。

当然如果主数据问题已经严重影响到了某个部门的业务拓展，部门也会跳出来主动解决主数据的问题，但其获得的支持是有限的，一方面只是他自己感觉到了痛，另一方面在落地执行的时候，部门会天然倾向只解决自己的问题，甚至跟其他部门有冲突。别人来跟我讲主数据的经验，我一般都会问参加过几次管理层的会议，主数据的工作保障机制如何，比如联席会的频次是多少，以此来评估靠谱程度，我不知道还有什么其他更好的办法来解决驱动力的问题。

业界一般有三种组织模式，第一种是由主数据利益最相关的业务部门主导建设，第二种是企业级数据管理组织主导建设，第三种是IT部门主导建设，正好我三种模式都碰到过。

第一种模式是以本部门的利益为核心来推动的，虽然已经获得了公司名义上的支持，但很难平衡好全局利益，跨部门协调难度很大，甚至会受到很大的阻力，一般很难彻底解决问题，至少周期会非常长。

第二种模式是比较推荐的模式，即通过企业级数据管理组织来牵头建设，由于相对中立，因此更有可能把控好全局利益，跨部门协调难度相对较小，但一般企业很难有这个条件和意识去建立这种企业级的数据治理组织，即使勉强建立了也缺乏专业人才的保障，比如对于业务和IT理解非常有限，因此存在眼高手低的问题。

第三种模式是IT部门主导，但这也是无奈之举，也是最不推荐的，一般只能做一些主数据的修补工作，除了继承第一种模式的弊端外，还面临业务驱动不够，只能解决局部问题的挑战，现在很多IT部门强调往业务多走一步，情况会好很多。

针对第二种模式，可以做适当的改良，即企业级数据管理组织不要搞所谓的虚拟组织或者东拼西凑成了杂牌军，而是在IT部门的数据管理团队上升级而成，然后补充重点业务领域的人才，当然还是会碰到主数据专业人才缺乏，专业领域业务理解不够等问题，但至少是相对理想的模式，比如华为就建立了企业数据管理部这种实体的组织。

一般会设置公司领导小组，组长由管理层担任，副组长由各部门的数据责任人担任，领导小组负责主数据项目总体工作推进，制定总体工作思路和目标，协调各部门间项目推进过程中遇到的问题，确保项目的顺利执行。

领导小组一般会下设工作小组，工作小组组长一般由企业数据管理组织的相关负责人担任，成员包括企业数据管理组织人员及各领域的数据专员，负责主数据项目的具体实施，开展相关能力建设和运营。

根据自己的经验，一般会设置几个专业组协同推进，以下是一个示例供你参考：

业务需求组：负责主数据相关业务流程梳理和业务管理规范的制定，明确主数据需求

系统架构组：负责主数据系统整体架构的设计，确保架构合理、满足各域生产应用需要

平台建设组：负责推进主数据系统建设工作，实现主数据库、对外数据服务、数据稽核等关键能力

数据架构组：负责推进各领域系统现有主数据的整合，形成一份统一的公司标准主数据

各领域改造组：负责本领域系统的改造工作，确保与主数据系统的顺利对接

主数据项目很怕雷声大雨点小，别看大家面上喊得很凶，但一旦要落实到具体工作上，谁都不太愿意接这烫手的山芋，因为不确定性很强。

主数据涉及很多部门的利益，需要能给出权衡利弊的方案，把事情放到台面上来摆事实、讲道理说清楚，所谓的全局利益最大化很难一句话讲清楚，这个就需要有相应的工作机制保障，否则可落地性存疑，以下是一些做法：

主数据变动涉及多个部门，牵一发动全身，对于业务的影响是很大的，当真正要建立一个主数据系统的时候，必须清楚的知道主数据的变更（新增，读取，删除等）会影响哪些业务流程和角色，这些业务流程承载在哪些系统上，这些系统的哪些数据会受到影响，这些系统的上下游哪些系统和数据接口也会受到连带影响，这样才能大致确定主数据变更的业务影响范围。

当然确定业务影响范围还是远远不够的，还需要在业务流程梳理清楚的基础上，分析清楚哪些业务流程的哪些环节需要进行变更，比如基于主数据的要求进行数据录入的规范，这样才能明确具体的系统改造需求。

要进行业务流程的梳理需要各部门的积极配合，但每个业务部门对业务流程进行梳理也是存在挑战的，一方面没有专门管流程的人，另一方也不知道梳理的方法，这些都是需要主数据项目团队协调资源去攻坚解决的，华为有独立的流程和质量管理部这种组织来保障流程，但大多数企业没有这么理想化的组织，必须临时搭班子推进，因此能做主数据的组织还需要是个学习型的组织，能够快速学习新的东西，因为不可能每个事情都能马上找到外部资源。

业务流程梳理完后，我们至少需要得到下面一张汇总表格，如图一所示，然后里面的每个流程都要有详细的说明，如图二所示：

主数据架构有两种主要类型，一种是强管控，即中央集权型，主数据的编码、更新、分发等所有流程全部强管控，这样主数据系统的话语权最大，业务价值最大，具备长久的生命力，但是这种方式涉及面非常广，侵入生产系统，实施难度最高，我们采用的就是这种，如下图所示：

国内很多企业的主数据工作落在OLAP团队，由OLAP团队来实施这种强管控的主数据架构挑战会比较大，因为这类主数据系统本质上是OLTP系统或者是横跨OLAP和OLTP的，对于一致性、实时性、可用性和连续性要求非常高，这些却不是传统OLAP团队所擅长的，但数据治理只有从源头抓起才能彻底解决问题，因此也是机遇和挑战并存。

主数据架构还有弱管控的类型，即用信息分发型的建设方式，这样入侵性比较小，我只管发布命令就行了，其他的你们看着办，如下图所示：

这种方案我其实不太推荐，因为即使开始的时候数据一致性能勉强保证，但可持续性很差，还不如平时打打补丁，做个转换器来得灵活。

现在很多企业由于有集团和子公司的二级组织架构，集团在集中化过程中需要先做一个主数据系统，但一开始又不可能一捅到底，因此采取了这种折中的方案，但我觉得这种主数据只是集团层面的主数据系统，子公司很难享受到多少主数据的福利，究其根本，还是由于组织架构割裂造成的，毕竟集团和子公司是两个法人实体，除非系统全部集中化建设。

可以看到，最终其实还是组织架构决定系统架构，组织的存在形式就限制了你主数据能达到的高度，这也是没有办法的事情，因此企业数据治理一定要优先解决组织的问题。由于主数据项目还没完成，因此我们也是走一步看一步，临时写下这点感想，但随着工作的推进，相信会越来越清晰。