透过数字化转型再谈数据中台（四）：数据中台不是买来的，是干出来的

作者 松子（李博源）

作为一个数据架构师，对一家企业进行数据规划与建设时，是要思考企业的大数据该如何建设。需要从企业阶段现状、诉求、组织结构、数据基础、数据应用能力现状等多方面来思考架构的规划、落地、执行、落地节奏等。同样的，面对“数据中台”的规划建设，企业不同阶段对数据诉求差异性很大，必然导致数据建设、实施策略差异也很大。

企业的成长

企业的变革是受到市场竞争、外部变化、顾客诉求等多种条件作为催化剂，发生的一种自我成长。很多诞生于互联网的企业在上述条件的催化下，通过缩短产品的生命周期来提升对用户的黏性以及商业化变现能力，过程中企业必须迅速的成长与壮大，才会逐渐拿到更大的用户量与市场份额。传统企业无论在成长速度、规模化速度比起互联网企业是较缓慢的，在数字化转型的今天，很多数字化的能力都是从互联网企业先发起变革并逐渐渗透传统的不同各行业。

● 一般的企业成长阶段：

● 高速扩展型

这种企业互联网企业、含有互联网基因的企业，或者是信息化、数字化程度比较高公司（非绝对）。

数据在业务成长下扮演的角色

在这个企业的这个过程下数据扮演什么角色呢？

● 企业的第一阶段，企业的业务是从0到1的，对标着竞品、头部、靠老板的直觉快速成长。这个阶段的企业是能认清自己的方向，但是不完全知道路该怎么走。企业会尽量完善地搜集数据，这些数据上仅对运营起帮助，不指导战略。

● 这个过程是让减少运营的错误，但不能用来找方向，只是让管理层多做“对”的决定；初创企业的内部比较杂乱，资金、人员、技术等都比较薄弱，管理也还没有真正的形成，但是其业务目标是非常明确的。

● 这个阶段数据团队除了主动去构建准确反应业务的指标之外，还需要做好拆解业务接下来一些可能的方向。这个阶段很多都是在基建工作，比如埋点的设计、中间层设计，快速部署一些报表体系，还要整理数据的各种日报等，业务上的各种转化漏斗等。

● 比如在业务原型或内测阶段，数据团队除了构建基本的数据体系外，还可以主动分析竞品或相似App挖掘里面的功能思考点为什么这么做，如何用指标体系来度量。

● 该图左侧是3月初的版本，灰色部分是关键指标以及待拆解指标，右侧是3月底上线后已经拆解后的关键指标。（这个方向的会归类在从BI角度思考业务领域）

● 阶段二，企业知道路上有些步子是对的，有些步子是错的，能渐渐地去掉错误的，集中精力坚持做正确的事情。公司发展动力是上下互动的，这个阶段要总结出大量的“错”、大量的“对”。此时业务可能出现四处乱抓、投石问路、打法不清晰、看不清楚现状、增长遇到瓶颈问题。

● 此时数据精准化，数据之间有了关系，数据担当的角色由点连为线以及面；让管理层q“我有什么，我要什么，我该放弃什么”，如何知道要坚持一些东西放弃一些东西呢，那是因为知道某些业务之间有内在联系，这些联系是需要通过分析与挖掘大量数据来把成果最大化。

● 案例之一我在去年分享的一个系列文章《带你轻松遍历用户生命价值与流失挽救（上）：流量下的价值套路》，已经把这个阶段做的事情总结了一些。关于用户的投放、承接、促活这个方向的数据上做的比较体系化、深度分析的一些内容会在以后做分享。

● 阶段三，成熟业务上已经具备护城河，并持续性各种创新，全力保高速增长。这个阶段开始除了关注内部数据外，也得重点关注外部与行业等各种数据，为业务探索距离天花板还有多大的空间，为公司下一步战略找到出路(挖一个小坑，后续会有小文章单独讲)。

透过一个产业互联网企业来探查数据中台的发展

考究“数据中台”的来龙去脉，会发现跟企业自身的阶段、业务组织复杂度以及数据组织多样性、企业业务视角有很大关系的。”数据中台“这个词是从消费互联网企业被提出扩散到各行各业，这次我用一个面向汽车生活的产业互联网企业来做案例稍微展开分享一下。

回顾面向汽车生活的产业互联网企业的成长历史：

● 公司创业时一直聚焦在汽车的品牌消费、车主服务、生活服务、渠道服务。

● 第二年的业务模式发展到售后维修，连锁增加到几千个，服务的客户量增长近百万人次。

● 第三年开始公司在车这个领域做的很不错，于是开始尝试二手车买卖、新车买卖、移动出行、数据化服务等创新业务。

● 第四年时公司形成了有七个独立BU，其中四个是独立的BU、三个创新业务的BU，简单的画图更加直观的看出这家企业的业务与内部组织结构的简单发展

业务的高速发展，会掩盖各种问题。当发展遇到瓶颈时必然需要各种自我调整找到第二增长点：

不停地尝试新的商业模式，给业务带来快速试错与调整，必然就影响到产研、运营的快速适应与变化。一个业务启动后首当其冲的是运营，需要使用人肉顶上去的方式作战，随后产研落地稍微有点滞后性做产品的迭代与上线。

● 业务的快速发展，从之前单一的业务逐步到现在的多业务，并在新的业务上做大量的尝试与新的变化，独立业务的BU分别成立。这种组织上的横向扩展必然带来的问题是：产品线比以往更宽，客户群体的增加也促使企业提供形式不同的、内容更丰富的业务与服务模式，这种情况下，IT建设必然是BU与BU、子公司与子公司之间各自为战。

● 商业模式在不停的快速尝试，每一个涉及到的系统都需要去做补丁。不停的升级，所带来的问题就是产品系统一直采用单个应用实现这种方式，Case by Case的考虑实现，通过一个规划的IT应用来满足响应的业务功能。这种case by case实现方式是可以简单粗暴快速实现支撑业务需求，纯属堆积。但是随着业务复杂度提升、业务变革速度加快，需求实现难度与后期维护成本显著加大。

业务场景下的数据建设

互联网企业比起传统企业来，其业务特点是通过互联网这个渠道跳过很多环节，直接面对最终用户提供产品化、服务化的场景应用。此类企业在业务复杂度、业务成长/复杂度、数据增长规模，会在某个阶段出现爆发式增长。另外在业务快速发展的阶段，内部业务组织结构基本是业务自治为主。

经过快速的信息化建设后，企业很容易形成业务数据孤岛现象。企业为了提升运营效率而进行精细化运营，需要对数据孤岛整合打通，数据价值通过各种数据产品透传给用户。比如，业务的初期，商品、供应链、BD市场，某些运营部门会构建自己的数据分析系统，当跨业务部门进行数据分析应用时，需要跨各类业务系统或数据系统。为了消除数据孤岛，需要一个职能更大数据团队组织来保证并约束个独立BU的数据相关建设。这里面必须包含采集规范、设计规范、模型规范、指标规范等，为了减少重复建设，会利用一些工具化的措施，尽可能地整到一起来做研发与部署运维。

随着企业数据应用能力提升，大数据知识的普及、平台化、工具化更加完善，大数据在建设、使用上的门槛会更低。企业提供的各类丰富的分析、取数的数据产品，能让用户简单上手的可以使用。

当功能更丰富了后，用数据的分析师、运营或产品，他们往往不知道数据的口径与来源，加工数据的不知道业务含义。不同部门口径又都不一样，有的从交易来、有的从账务来。这里数据使用与数据加工上就出现了”断层”。

有时在层级与功能部门前边也可能存在一个断层，对数据价值的内在衡量是不一样的。角色不一样，对于数据价值的的看法也就不同。

一些使用数据的分析师、运营或产品会自己参与到从数据整理、加工、分析阶段。当数据平台变为自由全开放，使用数据的人也参与到数据的体系建设时，基本会因为不专业型，导致数据质量问题、重复对数据浪费存储与资源、口径多样化等等原因。

数据上逐渐凸显的问题与解决

因为企业业务快速发展，在这个阶段，内部业务组织结构基本是业务自治为主，所成立内部小的业务或技术职能组织优先服务自身业务。

● 例如虚拟车企的第三个阶段，公司形成了有七个独立BU，其中四个是独立的BU、三个创新业务的BU，从集团角度来看目前只有一个大数据架构团队提供服务集群等。各业务线又要满足自己的各种数据上的需求，独立BU或业务线都会纷纷构建自己的数据团队，来满足自身需要。

● 从集团的角度整理来看，企业在后期转型中，为了创新、引流，同样遇到了需要面对很多数据上的问题。

● 数据重复建设与复用问题

● 企业完整的用户资产问题

● 多套日志采集标准问题

● 各种工具重复建设

● 数据重复建设问题

● 多套标签体系问题

● 多套用户ID问题

● 其它业务的多ID问题

● 数据质量问题

● 管理层上报的一些指标口径问题

● …

● 其它的一些问题

各种问题与很多企业遇到的数据建设问题基本是一致的，这里不一一列举了。原有的各业务线建立自己的数据团队是为了更好的服务于自己的业务线，但从集团的角度来看需要更多的业务联动、创新联动、引流联动数据的打通势在必行。所以集团开始规划从资源等各方面进行整合建设，一般的数据平台到数据中台有两种合并方式：

● 底层大数据基础技术的合并

● 数据内容建设、数据工具、数据应用上的合并

一般情况下，从难易度以及成本考虑是先进行第二种的合并，再来进行第一种的内容、工具、应用上的整合，当然这个过程是一个渐变的过程，不是一步到位的。

笔者自己经历过几个从0到1的合并的案例，基本都是要经历1-2年为大阶段，才能达到一个稍微成熟的阶段。

从底层开始的合并之路

原有多个业务线都有自己的独立计算存储以及数据组织结构，通过三个阶段的来做整合与合并。

● 第一个阶段，计算能力、数据存储、调度的迁移与整合。此时的各业务线数据团队的组织结构还是比较独立的(如下图所示)。

● 第二个阶段也是周期最长，各种苦活、脏活、累活层出不穷，也是实施过程中最难的部分，数据模型不停的重构。人员、数据内容(ID Mapping、主题域合并、公共主题域设计)、工具化、运维工具、开发工具、资产工具的整合，初步的统一对外服务。这个阶段的融合是对数据架构能力、数据产品规划能力、数据模型的统一设计能力都非常有挑战性(如下图所示)。

● 归一：可以从一个更大企业的视角来看这个数据平台是属于统一数据采集、统一的模型、统一的各种id归一化等。

● 整合：提供了企业级的主题域规划、数据资产管理、运维管理、开发管理。

● 在服务层：有统一的各种数据引擎等。

● 对外上：提供各种灵活的多租户工具集来做数据加工、运维管理、灵活的数据出口配置。

● 小的挑战：

● 如何整合与支撑好大业务线的数据团队原有的工作内容，工作如何分配。

● 业务线数据团队如何与中台的数据组织结构进行统一协调管理、分头协作。

● 各种规范化如何落地实施。

● 如何调整响应速度。

第三个阶段，比较成熟的阶段，从被动到主动（或许自己把这个成熟阶段定义比较高）。数据团队除了要数据产品功能本身的建设，还得考虑在数据内容与价值的传递上如何让用户更加方便使用，最最主要的如何能够快速对业务线做出该有的响应。

数据内容建设、数据工具、数据应用上的合并

比如子公司A是老牌的业务线，子公司B是新兴的业务线，合并自然是以A业务的数据平台为基础，B业务人员资源往A团队合并，最后形成C图。

合并之后可以分为四层以及两个闭环：

● 最下层是不同独立业务线的数据源，可以统一数据采集的标准化等，配置一致化的数据采集传输中线。

● 第二层是传统意义的数据仓库范畴，数据的统一整合存储的地方。比如数据存储、统一ID、数据公共主题域、各种标准化的内容（以及其他与数据模型、数据仓库范畴有关的内容）。

● 为了配合数据存储、管理、加工这个体系化过程，企业需要一个开发、治理、管理的工具体系，比如数据管理管理、数据治理、数据地图、数据开发工具、数据运维工具这个系列。

● 第三层是原有分散在独立BU的一些面向数据价值、分析挖掘使用的工具体系，被集成到一起后需要从集团的视角来对不同业务BU的数据使用做支撑。

● 比如原有报表平台、自助sql查询平台是来分别来自于业务A、B的，但是整合到这里后，需要从更多的抽象、公共特性的使用和管理上去做改造。

● 比如原有的画像从用户生命周期、范围都是原有业务A的用户，此时业务B、业务C也有自己的用户群体，应该整合到一起。从集团的视角来讲，原有的每个App都要去拉新，需要花费三份同样的钱，此时整合到一起是否可以做内部引流等。

● 比如在流量方向，可以在用户拉新、承接、促活等业务上，结合用户生命周期、用户价值贡献度，用户价值变迁，用户流失等等，对用户群体细分与试验找到增长点。

● 比如在对内容上，可以结合内容类目，动销分析，从群体到个体的价值消费进行各种增长分析等。

● 推荐、算法研究、精准营销push，都是类似的道理，可以在精准营销上增加很多全局观的矩阵式数据分析与打法。

● 最上一层就是面向不同业务线的比较独立的应用，这块可以是由在业务线垂直数据团队来使用下层的很多工具来做快速构建。

所以，在企业级合并中，需要围绕着新的数据主题域做设计，建设更好的公共主题域来支撑各种应用，里面的视频的统一标签、统一的用户id，更为完全用户画像都是需要建立的。这里面在工具方向、开发工具方向、运营工具方向上，报表平台、指标体系很多都是需要重新建设，方便为广泛的群体用户所使用。

小结

数据本身具备一个天然特性，就是能一次采集广泛使用，也就是自身就带着共享与服务的特点，恰恰又踩到了”中台”词的复用、服务的特点。“数据中台”的建设，先要满足数据仓库的建设职能，其次要建设数据平台该有的职能，再次是根据企业组织复杂、数据诉求现状、数据多组织问题来做资源优化与整合，提升数据复用率与数据整合度，最后是需要在内容建设、工具化建设、持续化的业务场景支撑。

数据中台的这种组织形式是数据建设分久必合的一种结果，有利于资源整合与复用节省成本。作者也见过一家多年企业的数据中台有几百人的规模，但是整体数据的能力却不好做评价。企业发展过程中所带来的组织、业务膨胀与复杂化，流程变长从而构建出来的各种壁垒，数据团队内部各种壁垒也蛮有意思，可以抽丝剥茧的去分析与思考。

相关文章：

透过数字化转型再谈数据中台（一）：关于数字化转型的几个见解

透过数字化转型再谈数据中台（二）：唯一性定理中的数据中台

透过数字化转型再谈数据中台（三）：一文遍历大数据架构变迁史

参考文章：

车品觉《数据扮演的三种角色》：

http://blog.sina.com.cn/s/blog 5025e3880100mq5n.html

作者简介：

松子（李博源），BI&数据产品老兵一枚，漂过几个大厂。2016年到现在持续输出原创内容几十篇，《中台翻车纪实》、《从数据仓库到大数据，数据平台这25年是怎样进化的》、《数据产品三部曲系列》等系列有思考深度的文章。