梅西夺冠啦！！！ 我有个心结，就是自己当年在负责报表取数的时候，额外做了一些创新工作，包括研发了个逻辑回归模型，热火朝天的搞了指标标准化，但大多无疾而终，我一直认为是人员能力不够造成的。

近些年自己一直负责数据变现、数据治理的相关工作，对于组织的力量有了一定的认识，近一段时间正好在做数据团队架构优化的事情，突然想到当初的失败可能跟能力无关，而跟当时的分工有关，因为无论是数据挖掘、指标标准化都是非常专业的工作，让半路出家的报表取数团队兼职去做，不仅缺乏资源，而且存在自相矛盾的地方。

康威定律说得好：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的讲：产品必然是其（人员）组织沟通结构的缩影，凸显组织架构的重要性，大到公司，小到数据团队。

近几年随着数字化的兴起，数据团队融入了更多的职责，不仅包括了传统的报表、取数及数据挖掘，还包括数字化支撑、数据中台还有数据治理等等，我不仅需要去解决数据团队分工的历史问题，还要做好新老职责的融合，挑战还是很大的，突出表现在以下三个方面：

1、数据治理职责和数据管理职责的冲突

一般数据团队做的工作无非就是数据采集、处理、建模、开放、应用和变现，外加数据质量管理，元数据管理等保障型工作，我们可以把这些活动统称为数据资产管理活动。

但数据治理与其性质完全不同，数据治理即对数据资产管理行使权力、控制和共享决策（规划、监测和执行）的系列活动，涉及到顶层设计、组织优化、建章立制或者监督控制等等，数据治理相当于将监督和执行的职责分离了，一个常见的类比是将数据治理等同于审计，数据治理制定管理数据资产的规则，数据资产管理活动则执行这些规则。

但我们还是擅长于去做一些生产型的数据工作，因为一直是这么过来的，真要搞数据治理，还是觉得如履薄冰，即使已经干了2年。我们会犯很多的错误，就比如当初报表团队给自己定个指标标准然后自己执行这种做法，就像孙悟空给自己套个金箍然后念紧箍咒一样滑稽。

即使数据治理好不容易起步了，但如何防止数据治理和数据管理活动搞成两张皮，如何确保在生产流程中发挥出真正的作用，都存在巨大的不确定性。

2、数据中台沉淀和数据快速开发的矛盾

数据中台的核心在于数据资产模型能力的沉淀，讲究的是共享复用，这意味着在做需求的时候必须进行灵魂三问：

，你现在做的模型跟以前做的那些中台模型是什么关系？

第二，你能不能复用这些中台模型？

第三，如果不能，能不能沉淀成中台模型？

为了达成这灵魂三问，数据团队就会面临一个两难抉择：如何一方面快速满足数据需求，另一方面又要能沉淀数据资产？

如果数据团队安排同一拨人去做需求开发和模型管理，意味着自己跟自己打架，模型复用和沉淀往往成为牺牲品。

如果拆分成两拨人去做，就会带来职责边界不清、沟通成本提高、模型团队成就感不足等问题，需求开发团队会说，我做的都是应用模型，跟你中台无关，中台团队想着既然没有需求，那就自力更生创造几个，但产出的东西大多没什么卵用，中台就这样成了皇帝的新装。

3、数据团队核心能力认识上的模糊不清

当前业界对数据团队核心能力的认知是不一致的，无论是算法能力、数仓建模、报表取数、平台建设、数据产品、数据变现、数据服务等等，认知的不同导致了不同的数据团队的组成架构。

比如我们数据仓库时期会认为报表取数重要，因此会设立报表取数组，但搞了半天会发现没啥沉淀，成就感普遍不足；数据中台时期会认为数据建模很重要，因此设立了数据中台组，但会感觉模型没价值出口；数据治理时期新增了数据治理组，然后又会发现落地很困难。

那么，数据团队到底哪些能力是为核心的呢？哪些能力需要为其单独设立小组？哪些能力又是适合放在一起的呢？我们需要找到答案。

为了解决以上三个核心问题，我这里给出了一种数据团队架构的方案，即分为三个组，分别为数据治理和变革项目组、数据中台组及数据服务组，它们相对独立，但又相互促进，也会相关牵制，力求达到"数出一孔"的目标，各个组的具体职能如下：

1、数据治理和变革项目组

（1）负责数据规范标准制定

（2）负责数据生产的检测、评估和执法

（3）负责企业级数据平台的建设和运营

（4）负责变革项目

2、数据中台组

（1）负责数据中台的数据采集

（2）负责基础模型和融合模型的建设运营

（3）负责数据中台的运维

3、数据服务组

（1）负责内外部的数据需求管理，包括报表、取数、标签、接口、应用模型等

（2）负责前台类应用和产品建设运营

下面我具体讲讲这么设置的原因。

首先讲数据治理和变革项目组，以下简称数据治理组，有三个驱动力让我决定成立这个小组：

1、驱动力：三权分立

当前数据已经成为重要的生产要素，是企业数字化转型的基础，而大多企业都还存在数据架构落后、数据盘点不足、数据贯通不畅、数据开放不够等问题，这些问题只有通过企业数据治理才能解决，包括组织架构的调整，制度规范的建立，流程的优化重构等等，考虑到数据治理无法一蹴而就，因此成立独立的数据治理组来解决是必要的。

数据团队虽然规模不大，但到了一定阶段还是要像政府治理一样，走向三权分立的架构，即司法权，立法权和行政权的相对独立，数据治理组负责相关规范标准的制定，数据中台组、数据服务组等执行这些规范标准，数据治理组还需要对执行情况进行监督考核，从而确保规范标准的落地。

数据治理是非常专业的工作，难度很大，但价值巨大，因此不要搞什么兼职，即使是个技术规范，也要专人专职，如果你不希望把规范扔抽屉里的话。我以前一直以为定个规范啥的是小事，这在认知上就已经错了。

很多数据团队没有企业级数据治理的职能，但即使从数据团队本身发展的角度来讲，也需要建立独立的数据治理组。数据团队特别需要一个能贯通前后端（从数据需求、开发、测试再到数据运维）的治理组织来统筹推进一些事情，如果说企业的数据治理是大循环，那么数据团队通过数据治理让自己运作的更高效就是小循环，在治理别人之前，我们先得治理好自己，这就是孔子的“己所不欲，勿施于人”，也是塔勒布“非对称风险”的精髓。

2、第二驱动力：变革驱动

但规范标准从制定到执行是个复杂的过程，需要人们改变行为和互动方式，甚至改变原有的生产关系，因此受到的阻力会很大，只有依托变革项目才能把这个事情真正做起来，就拿ETL的治理来讲，必须有变革项目组牵头，打穿所有的数据专业，说服所有的利益方，辅以系统化的培训，对ETL的相关规范、流程和IT上进行大幅的变更才能落地。

3、第三驱动力：工具护航

但这里还有两个问题需要解决：一是规范标准很容易和实际生产脱节，造成两张皮现象。二是变革项目组的不稳定性也使得项目所取得的成果很容易功亏一篑，我们以前搞元数据管理就深受其害。

因此我做了一个改变，就是将企业级平台和工具的建设职能放到了数据治理和变革项目组，这样就比较容易把规范标准的要求嵌入到平台工具中，从而确保执行到位，也能具备一定的可持续性。

以前我想当然的把平台工具建设的职能放到了数据中台组，但后来发现效果不好，数据中台组虽然可以提出很好的需求，但不代表具备建设能力，无论是专注力，全局性都差了很多。

我希望数据治理和变革项目组既能站得高看得远，又能不脱离实际，这个组对人员的综合素质要求很高，大多应来自项目经理和数据管理者，自己犯愁的也是这个。

其次讲数据中台组。

数据中台这个词近几年越吵越邪乎，但没有人能给出一个确切的定义，我对数据中台组的定位有两个，一个是数据能力中心，另一个是数据运营中心。

1、数据能力中心

对于传统企业来讲，很多数据工作是外包的，我不否认外包可以为企业打造核心能力，比如平台和工具，但其范围是有限的，而且往往是暂时的，没法形成竞争性优势，因为其它企业完全可以COPY。

多年的实践告诉我们，数据团队的核心竞争力就是业务+数据+技术的结合能力，那么这个能力具体指什么呢？《未来十年，数据团队核心的能力到底是什么？by 大鱼先生    》对此做了详细的阐述：

"数据团队真正需要的是一只数据模型产品经理队伍，能够以业务对象为核心（不局限于领域）来进行数据模型产品的构建，能够为业务提供端到端的数据服务支撑，能够解决跨领域数据模型构建过程中出现的数据标准、数据质量、数据整合等问题，他们是公司数据资产的真正代言人，能力要求远远超越了传统的数据建模师。"

"数据团队要围绕业务对象进行组织的变革，也业务对象为核心进行人员职责的重新划分，如果公司有100个核心业务对象，那么也许数据团队需要50个产品经理，每个产品经理负责2个，这些产品经理为公司的数据资产整体负责，他们代表了数据团队的核心竞争力，独一无二。"

我在10年前曾经喊出"数据建模核心能力自我掌控"的口号，当时针对的是大数据对外合作期间数据字典竟然成了某合作伙伴的私有资产的不合理现象，然后希望所有的数仓建模工作都由自己搞定，当然这种做法现在看来是片面的。

我们现在需要做的，就是梳理出公司为核心的业务对象，然后逐步攻关，考虑到人力资源的限制，先期会挑选地址、家客、资源等部分核心业务对象进行自我掌控的尝试，然后慢慢拓展范围。

那么，何谓自我掌控？

假如你是公司“物资”这个业务对象的产品经理，那么围绕“物资”你要建立一套贯通上下游的模型体系和数据标准，所有涉及物资的数据需求都应该由你端到端负责实现，任何涉及物资的业务流程变动，系统变动，数据变动，你都要能与时俱进的进行模型的同步变更，你是公司里懂物资的人，无论是在业务上，系统上还是数据上。

2、数据运营中心

数据的采集、运维和建模到底要分开还是合并已经吵了很多年了，我现在的倾向是合并，原因有三个：

、与OLTP团队不同，对于数据团队来讲，数据质量在运维体系中举足轻重，但数据质量的核查和提升大多需要建模人员的介入，而连续性要求则相对较低，在数据团队大*发展时期，为了减少沟通成本，运维和建模合并有合理之处，当然运维失去独立性可能不利于暴露问题，但总体上利大于弊。

第二、在数据建模中往往需要去采集数据，特别是业务对象建模往往需要理解源端的各类数据，这使得数据采集和数据建模耦合度很高，我们的数据模型产品经理在建模的时候，一定是要自己去理解源端系统的数据然后推动采集并完善元数据，这个不能假手于人，因此，采集和建模的人员进行整合也是合适的。

第三、随着数据编织技术等的兴起，数据采集现在越来越自动化了，比如我们90%的数据可以实现一键采集入湖，未来采集、建模和运维的边界会越来越模糊，那么相关职能放在一起就可以减少扯皮。

但数据中台组还有个老问题就是数据模型沉淀缺乏足够的业务驱动力，因为前端的数据服务组完全可以绕过"中台三问"另起炉灶，他们会说迫于业务的需求压力只能这么做，即使这些压力不总是存在，我这里有三个策略：

、数据采集需求由于要通过统一的ETL工具进行，因此很容易进行刚性管控，数据服务组的需求如果涉及数据采集，必然会流转过来，数据中台组可以基于新采集的数据来提供更好的模型。

第二、数据运维中会暴露大量的数据问题，由于与建模人员同属一个组织，这些数据问题很容易传递到中台模型人员那里去优化解决，我认为，一个数据团队至少要有30%的需求是自己提给自己的，否则技术负债会越来越多，但传统的数据团队架构很难做到这一点，大家都习惯围着业务转以致失衡，但站在公司全局利益角度出发，砍掉业务部门30%的需求来换取长远能力的提升，这个买卖应该做。

第三、数据治理组作为顶层设计者，有权力去规范和监督数据服务组"中台三问"的执行情况，这对数据服务组就是个约束。

解决了数据中台组的业务驱动力问题，理解清楚了核心能力的本质，我们才能真正的沉淀有用的数据能力，而不要让数据中台成了皇帝的新装，华而不实。

后讲数据服务组。

数据服务组是面向终用户的，我有三个管理原则：

、按照垂直业务条线进行专业服务的支持，每个业务条线只有的一个角色进行需求对接，类似销售的职责，比如市场人员提了一个数据开放需求，即使这个开放需求涉及到数据采集，那么也需要由数据服务组的需求人员统一进行对接，然后由他去协调数据中台团队进行支持，这样做，一方面管理简单，确保业务能找到对的人，另一方面也有利于提升数据服务组自身的业务能力。

第二、每个需求人员要负责所有类型的数据需求，包括报表、取数、模型、标签、开放、应用等等，因为各种类型的数据需求往往是有关联性的，比如业务人员取了几次数，就有可能要做一张报表，也可能希望固化成一个模型，如果分开支持，那么效率就下降了。

第三、数据服务组要背负相关的业务指标，无论是需求及时率，准确率等等，但数据服务组不能越界对数据中台的模型进行任何的变更，数据服务组对数据中台组依赖度的增加有利于各专业的协同和能力的沉淀，当然，数据服务组要对数据中台组、数据治理组具有考核权，这样大家就成了一个利益共同体。

很多偏前端的应用，比如自助取数、手机经分、财务分析平台、满意度分析平台等等，考虑到业务相关性比较大，因此会把这些应用的建设权放在数据服务组，但会碰到与数据中台组、数据治理和规划组如何协同的问题，比如自助取数用到的模型很多都是数据中台组提供的。

华为公司提出了服务化的解决方案，即中台能力团队把数据封装并且开放出来，前端团队进行编排以灵活的满足业务需要，这个方案看似很完美，但现实中要落地还是挺有挑战，一方面业务规模不够大，封装的收益不高，另一方面数据能力的封装难度很高，灵活度是大问题，OLTP衍生出来的API理念其实很难直接套用到OLAP领域，因为数据的维度是无限的，而OLTP领域抽象的API却是非常有限的，量变引起了质变，不能一概而论。

后，我希望三个小组是个有机的整体，相互之间的关系总结为三点：

、数据治理和规划组负责建章立制，其他组按照要求执行，考虑到"两张皮"问题，数据治理和规划组一方面要承担平台工具的建设职责来强化执行，另一方面需对执行情况进行监督考核；

第二、数据中台组基于数据治理和规划组的要求（自上而下）、数据服务组的需求（自下而上）及自身运维暴露的问题三驱动来进行核心能力的沉淀和运营；

第三、数据服务组承担考核的指标，基于垂直业务线进行需求管理，并且依托于其它两个组提供的平台和数据能力来提升效率，并对其它组进行支撑能力的考核。

当我刚设计完这个架构时，还是挺激动的，因为能回答自己前面的三个问题，当然这个架构对其它数据团队来说，可能并不适用，因为大家要回答的问题不一样，但我还是要把自己的思考过程写下来，这个可能对大家更加有用。

如果你读到了这里，一定理解了其中的精妙之处，请分享给有需要的人吧，因为当初自己网上到处找数据团队分工的文章而不可得，现在想来也有很多同仁跟我有一样的诉求吧。