企业数据治理团队手臂伸得太长，这很危险 by 傅一平

经过多年的数据治理实践，业界已经充分认识到，仅仅依靠技术部门来推动和开展数据治理工作是无法取得成果的，原因在于数据治理涉及企业各部门的业务和资源，只有来自更高层管理者的驱动力，建立自上而下的跨部门跨条线的组织体系，才能保证企业内部的高效协作。

下图是一张通用的企业数据治理组织框架，大多现实中的企业数据治理组织都可以与其映射，我看了华为数据之道的组织，也看了很多央企的，都不出其右，如果你的企业需要建立企业数据治理组织，可以参考这张图，然后结合实际进行裁剪。

如上图所示，很多公司也建立了企业级的数据归口管理部门，理论上，这个归口管理部门是不干“实事”的，主要负责制度、流程、规范、标准、考核等工作，其一般职责包括：

（1）贯彻落实决策层各项决策部署，行使日常数据治理工作管理职责。

（2）负责基于战略制定数据治理规划，并报决策层批准、发布。

（3）负责制定数据治理年度投资计划和工作计划。

（4）负责制定、修订和发布数据治理相关管理办法、实施细则和业务指导书，构建公司数据治理制度体系。

（5）负责制定数据标准并进行监督，规划、构建和管控企业的数据架构，识别并建立主数据应用管理机制，制定数据质量管理要求并进行问题指导和协调。

（6）负责组织制定数据安全基础策略，构建企业级数据安全管控体系，配合监督和审计。

（7）负责受理跨部门、跨机构或重要的数据需求，组织开展数据需求的评审、实施和成果交付工作。

实践证明，完全不干“实事”的数据管理部门生存空间比较小，危机感挺强，除非有一把手的鼎力支持，大致有三个原因：

第一、数据治理本质上是为了保障数据管理活动的顺利进行，理论上不直接产生业务价值，这让数据治理团队有显性化成绩的压力

第一、数据治理在大多企业里算是新鲜事物，大家对其价值的认可需要时间，光是理解数据治理这个概念就挺费解

第三、数据治理团队建的章立的制落地挑战很大，因为制度规范的执行需要流程的保障，但要改变流程又是何其艰难，容易形成“两张皮”现象

很自然的，这些被赋予使命的企业级数据管理组织除了干建章立制的工作，也希望增加数据管理活动的职能，比如搭平台，汇数据，做模型，搞服务，甚至还希望做些数据应用创新，这个时候，如果没有找准自己的定位，就容易跟领域级的数据管理组织产生职责上的冲突，也就是“与民争利”。

关于这一点，我们可以从华为公司数据管理部的发展困境看到些端倪：

华为数据管理组织体系由两层构成：企业级的公司数据管理部，以及各个功能部门下的领域数据管理部，公司数据管理部代表公司制定数据管理相关的政策、流程、方法和支撑系统，制定公司数据管理的战略规划和年度计划并监控落实。建立并维护企业信息架构，监控数据质量，披露重大数据问题，建立专业任职资格管理体系，提升企业数据管理能力，推动企业数据文化的建立和传播。

公司数据管理部挂在公司流程IT部门之下，在过去十几年中，先后归属不同的二级部门，包括IT架构与规划部、信息技术部、企业架构部等。从中可以看出，数据管理部跟周边如何有效协同的问题，一直没有找到最佳答案。

数据管理部要扩大数据工作的“势力范围”，有两个方向。一方面是向业务延申，另一方面就是向IT延申，许多领域数据管理部之所以能够存活下来，被迫向非数据管理专业工作延申，例如管管部门KPI等，但公司数据管理部这条出路行不通，即使是指标本身也有业务行管部门负责，没有机会介入。

那么向IT部门延伸如何呢？华为数据管理部门成立以来，跟IT部门之间的分工与协作也一直并不顺畅。数据看不上IT部门的”脏活累活“，IT部门看不上数据人员的能力。

空降的企业数据管理组织如果只做建章立制的工作，容易脱离业务，而一个脱离业务很久的组织，其建的章立的制能否接地气存疑。因此，企业级数据管理组织的职能最佳构成形式应是虚实结合的，要有机会负责具体的数据管理活动，企业数据治理组织人才的培养也需要实践的土壤。

那么，企业级数据管理组织的实体职能跟领域级数据管理组织的实体职能边界能够区分清晰吗？

理论上我们可以说，让企业级数据管理组织去干企业级的数据管理工作，领域级数据管理组织去干领域级的数据管理工作，但这个领域级和企业级的区别到底在哪里呢？

有人马上会想到，数据中台总应该归属企业级数据管理组织负责建设吧，但如果数据中台仅指狭义的数据模型能力，那么这句话并不完全正确，因为领域级数据管理组织也可以作为数据中台模型的建设一份子，数据中台并不是企业级数据管理组织的专属物，甚至可以这么说，领域级数据管理组织甚至比企业级数据管理组织更适合建设数据中台，因为它们更贴近业务，只是共享模型的驱动力少了点而已。

而企业级数据管理组织的优势应该是建立模型的运营规范，然后让各领域的数据管理组织参与到这个生态中。

那么，到底哪些实体的数据管理职能应该放在企业级数据管理团队呢？

这个问题困扰了我很久，然后华为数据管理部发展的一段历程提醒了我。

“2011年左右，华为数据管理部提出”抓两头，推中间“的工作策略。“两头”包括主数据和数据仓库，“中间”指业务交易系统。主数据影响范围广，一旦出问题，各个业务交易系统的数据质量都受影响。而且，主数据管理需要推动协调各个业务部门配合，在IT方面的”技术含量“并不高，IT部门巴不得有人接走。

数据仓库直接支持公司各类分析报告，管理层更容易感知到数据质量的好坏。并且数据仓库是一个轻功能重数据的IT系统，称之为”数据密集型“系统。当时，华为数据管理部已经按照这个思路开始工作布局，同时2011年开始参与公司EDW的重构工作。”

虽然华为数据管理部因为一些意外的变故，没有实现以上的夙愿，但他们这个”抓两头，推中间“的工作策略还是很有启发意义的。

关于企业级数据管理团队的实体职能，我觉得需要遵循三个原则，即集约原则、互补原则及孵化原则。

原则1：集约原则

就是企业级数据管理团队统一做这个事情的价值已经超过了各领域数据管理团队分头做的价值（含灵活性），这个跟企业当前的数据管理发展阶段有关，如果企业刚刚开始搞大数据，那么这个集约化原则估计就不太适用

原则2：互补原则

就是企业级数据管理团队不是去跟领域数据管理团队抢活干的，而是去做对整个企业有全局价值但领域数据管理团队不太愿意干或者干不动的事情，因为领域一般是屁股决定脑袋的，只会围绕着自己领域KPI转，只会做对领域性价比高的事情，这是由它的生态位决定的，没法改变

原则3：孵化原则

很多企业的一些领域数据管理能力很弱，甚至没有，这个时候企业级数据管理组织可以暂时承担起这些领域的实体数据管理职责，但还是要清楚，只有领域自己的数据管理组织起来了才是最优的解决方案，因此企业数据管理团队要全力帮助领域数据管理组织的成长，最后如果能移交领域数据管理的职能，就算成功了

基于这三个原则，容易推测出企业级数据管理组织最适合做的五项数据管理工作：

1、打造统一的数据治理平台，无论是元数据管理平台、主数据管理平台、数据标准管理平台或者开发管理平台等等，集约化的可能性都比较大，企业数据管理团队的本职工作是数据治理，工欲善其事，必先利其器，如果连自己的数据治理平台都无法集约化，那有点说不过去

2、打造统一的数据底座，也就是数据仓库或数据湖（不含中台模型），通过提供数据湖底层平台、制定入湖的统一标准及实现企业各域数据的统一标准汇聚，可以最大化发挥集约的价值

3、所有涉及跨领域的数据、模型等构建工作，如果这些工作的跨领域属性特别大，任何一个相关领域的数据管理者都已经无法有效支持企业级应用要求的时候，那么企业级数据管理组织应该去补位。

主数据就是特别好的一个例子，因为主数据一般横跨多个领域，但各个领域其实都不太愿意去干又脏又累的主数据，比如人员主数据，这个时候企业数据管理组织需要去补位，特别是当数据的一致性已经积重难返的时候。虽然主数据可能归属于某个特定领域管理，但并不意味着这个领域有能力、有意愿去解决其他领域在应用主数据时碰到的问题

4、很多数据模型或数据技术研发通用性较强，但对于企业资源的消耗特别大，当这些模型和技术的业务属性不是特别大的时候，让企业级数据管理组织去承担研发任务是可以的，这遵循了补位的原则

5、如果企业某个领域需要从无到有建设自身的数据管理组织，企业级数据管理团队应该先顶上去，利用其沉淀的数据管理经验为该领域提供支撑，这样可以让该领域尽快享受到企业已经达到的数据支撑水平，而不是从0到1，企业数据管理团队也有责任、有义务为领域提供数据管理培训服务，直到该领域能够独当一面，这遵循了孵化原则

企业级数据管理团队的构建对任何企业都是一种挑战，但这种组织很容易走向两个极端，一种是团队成员都是空降而来，职责是纯管理型的，不那么接地气，另一种是团队由实体组织升级而来，虚实的职责都有，但职责定义不清，甚至与领域发生冲突，产生“与民争利”的现象。

我这里尝试给出一种解决方案，希望对你有所启示。

点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！