如何想方设法持续提高企业对⽤户的响应⼒才是建设背后最核心的逻辑，更好服务前台规模化创新，进而更好响应服务，不管是中台还是平台能够有显著成效就好。

不管是传统企业还是互联网企业，因为企业的发展速度、形态与数据量等都不同，在开始进行中台转型时会从不同的接入开始切入。

关于数据中台的对话：

场景一：

发生在上周周末，与一个公司的老板对话。

老板开门见山提了一个问题：“想问一个问题， 我想搞一个数据中台。”

我惊了一下问到：“啥？搞数据中台？没烧坏吧？”

“那想搞这个这个数据中台的目的是啥？是要支撑业务，还是在融资上搞啥？”

“现在这个中台很火啊，我们也想搞一下。搞个数据中台、再搞个运营中台，未来面向xxx这个群体，就是一个 SaaS。”

“你真有钱，其它中台不好说。但是数据中台我认为就公司目前的这个业务情况，还在初级阶段，业务一直在快速奔跑，组织结构还没成为业务发展的瓶颈。

另外，从中台的难度上来讲，在产品、架构规划等方面强调的是服务、组件化、业务抽象等方面，其天然的起点已经比普通业务形态与产品有数量级的差异。

业务的快速频繁变化，如何让中台来做沉淀？当心中台的不完善拖累业务，搬不动这块铁，把自己砸晕了。

个人建议，抛开所有概念，就围绕自己要解决的问题，解析出适合自己的商业模型到分析模型，再围绕分析模型来看如何做埋点与数据拼图，用数仓的方式，数据平台的实施来做支撑。”

老板： “那你帮我出一个方案吧。”

“我#￥%……&*（）——”

场景二：

发生在一个数据群。

一个同学问：“什么是中台，什么是数据中台呢，我看的一脸懵逼。”

“我们公司要招中台产品经理了，都是来干嘛的呢？”

“我看了很多材料，还是没懂啥叫中台，最近有个公司出了一本数据中台的书，买来再看看。”

然后呢，再过几天，在不同的群不同的场合，类似的很多关于数据中台的对话将继续神话般勾兑着。

中台的建设是一个复杂的系统工程，正如某大神说的“中台的建设要想比较成熟且有体系至少要三年以上时间，是要分阶段去实施的”。

中台的实施在现阶段只能是摸索、实践，因为大家对中台的理解是根据所处的当下环境与状态而进行思考的。

现在，中台的实施将会在做事的方式、思维的高度、系统框架方面有所改变。但是，实际上很多打着“中台”这个词，在按照技术组件、技术产品或一个技术平台的的方式在实施，只是“被”成为了中台。

总结自己2019年半年职业生涯，中旬离开一家“大航母”后，这半年也是在跟中台打交道，并且到现在也是在尝试去推动一个数据中台化。其中遇到了各种有意思的问题，期间花了漫长时间来盘点问题并尝试寻找一种适合的演进方案。

那我能在这里做点什么呢？

一般一上来就喊中台化的基本入不敷出，不是人员投入问题、就是实施方向以及定位到底是什么。

但是，有的企业用演进的办法来做实施是个非常不错的选择。

那成功与失败的关键要素是什么呢？是认知的因素？还是人的因素？还是组织因素？还是期望与落差的因素？标准的中台是什么样子？

我们如何衡量是在做中台而不是在做平台？做中台从具体事情层面来讲，有哪些维度？该如何落地？

现在中台的书已经有好几本，网上的各种文章有很多，或多或少都有在回答“中台”的相关问题，我在后面的篇章也会逐渐展开讲我所理解的这些问题。

伴随着业务的多元化发展，公司各部门纷纷建设各自的业务系统，在产生大量的系统、功能与应用重复建设的同时，也导致了系统之间的数据处于未能及时打通的割裂状态。大量的数据被阻断在了不同的系统中，就像一个又一个的‘堰塞湖’，可能满足了单一的业务场景，却阻塞了企业数据资产的全链路管理，使得企业数据难以被全局规划与定义，这就是数据中台应运而生的源动力。

首先，数据中台是根据企业的实际情况所打造的数据产品与实施方案的结合物，它可以融合企业内外数据，打破数据隔阂，解决企业面临的数据孤岛、数据标准不一致等问题。其次，又是一种战略选择与运营解决方案，是一套行之有效的数据运营机制。

这段话是来自一篇科普文章，在行家的眼里看会怎么样呢？

我特别想问问这个作者，企业级数据集成、数据仓库、数据平台的定位什么。

透过数据中台看数据平台

我在写这个小标题的时候，内心是纠结的，一直在想如何系统化说明数据中台、数据平台的的相似性与区别呢？

我总结了一些维度，比如复用性、资源整合、能力沉淀，按照业务横向相关联，把数据做深度整合并最终沉淀为公共的数据服务能力等。

但是，我发现每一篇文章，每一个定义都是非常随性，没有本质上显著的区别，难道在平台的实施中直接换个词就能成为数据中台？

开始老板给了非常高期望，希望花一年时间投入三五十个研发、十几个数据产品经理就能完成中台的建设？到头来不断降低的预期、难以忍受的产出与不成正比的投入，最终会怎么样呢？

能力沉淀，这个相对来稍广泛一点、数据的接入能力、计算能力、存储能力、业务支撑能力、展现能力都算在能力沉淀中，只有想不到没有做不到。

一般的平台化是因为业务需求繁多、响应及时要求高，需要平台，因为企业的业务发展也是成生物生态的特点。平台化也是需要降低成本、提升效率，并快速支撑与响应业务，但是平台的边界非常清晰与管理很规范。

比如，在实施平台后，可以实现柔性的支撑业务，能解放技术同学并发精力，投入到稳定行、高性能、技术改造等一系列的其它重要事情上；并能提高人效，降低公司成本。

比如，平台化后对业务分治与归口的管理，业务边界变得更加清晰，归口管理使得各团队对自己业务管理更规范与高效，避免了一件事情找半天没人理，需要更多的PMO与建立更多的流程与规章制度保障工作。读到这里是不是有些读者已经意识到什么了，后续再展开讲。

总之，平台化是在业务层面、功能层面、接口层面、应用层面去做具体的落地。

回归数据体系建设，企业的一个营销方案可能需要几个礼拜到几个月，是企业为中心，生产为向导的模式。但是，现在变为市场为中心，又再变为客户 & 用户为向导的持续规模化。

企业的业务响应能力和规模化的创新能力，是区别于传统企业与互联网企业的综合能力的。企业拥抱这样的变化就意味着业务必须逐步完全信息化，对客户的触达方式也极具的缩短，中间所有的数据记录模式也发生信息化的变化。

业务数据结构变化，由传统企业的单纯文本，结构化数据转为非结构化的声音、视频、日志、定位信息等。所以，需要数据处理的技术架构、产品架构、甚至相关的组织结构也是不同。

在这种平台结构下构建起来的数据平台，是企业数据体系建设的基础， 搜集好的数据需要产生价值。数据的搜集、存储、显示、产生价值是一个链路，相辅相成的。一个公司如何想实施好一个数据体系，是需要从数据、产品、工具、技术、应用等多个角度，来共同实施与落地才能完全做好的。

数据平台这个词本身含有平台，平台这个词内部的含义已经包含组件化、服务化、系统化。建设数据的主要目的就是屏蔽数据异构性、构建统一的数据源，这个不管是在数仓、还是在数据平台都是必须要做的基本任务之一。

与大家一起拆解2个内容：

平台中的关于组件、服务与系统化：数据域的建设分为内容建设、工具建设与内容价值探索，其中工具体系化建设是数据平台的基石，内容透过工具把价值提现出来，工具如何构建与联合将会将会发挥出不同的价值来。

例如，以前我们的ETL过程、数据工具、调度工具、元数据工具、指标字典、库表字典、数据质量等一系列工具是一个个的工具产品，每一个工具产品解决的是特定领域的问题。

比如，指标字典是解决公司离线级别指标管理与指标口径管理问题，或者是可以增加在线指标的配置管理。库表字典，有的公司如果是数仓主导可能就是给自己服务，里面就是针对数仓的表做查询；如果把业务系统库表整合进来，那就是面向其它技术群体等一款小的服务产品。

有人说，这个属于元数据的范畴，我把一个数据地图做扎实做透了，把库表字典、指标字典里面的所有元数据通过有机的关系整合起来查询多好，并且可以提供对外的查询服务；或者是在某个流程中，比如ETL的过程、调度的过程随时随地可以查询相关的信息与影响多好。

举的这个例子中，单个工具与单个工具耦合性很差，缺少相互联合作用的功能。现在，有不少公司在做产品时往往都是一个个的工具独立的存在，说是成为一个平台，但是更多的仅是个工具。从架构与定位上来看，仅仅是打通一些点，无法联合起来形成一个工具体系提供丰富的不同场景应用。

这个小案例就思考到了组件化、服务化这几方面，来做规划与设计。

关于统一，不管是在工具建设、内容建设中不可避免的要去面对多个业务线、多个业务系统来做数据等整合，可能会涉及不同的内容需要“归一化”、“统一”。

我们要统一的建模、统一的开发、建立统一的标准，所谓的统一就是做数据必须要去完成的一个使命。

数据仓库本身具备的一个责任之一就是数据整合，屏蔽数据的异构性，完成对不同术语的统一。如果拿到中台的这个ID统一，本质上只不过是数据仓库、数据平台本身所必须的职责之一。

下图是比较久远的一个数据项目的目标，感觉与现在有多大的差异性？

但服务的范围不同了，就像APP日志采集一样，埋点统一也是流量必须要做的事情。

（图例是在 12 年前一个项目中项目模块介绍）

强大数据中台是每个企业的梦想

每个企业都梦想要一个非常强大数据平台或中台，对企业内部提升运营效率、决策效率、在线精准，对外支撑各种场景应用。

从实施角度、管理、面对客户上总结为：

• 在实施上，想把数据来龙去脉梳理特别清楚，把数据加工、存储、分析、建模等与数据有有关的所有事情都可以轻松的解决。
• 在管理上，想有一个可以管理一切的入口，把一切的数据、口径、项目、工程等都管理起来。
• 面对客户，想让客户可以一站式在这个平台上获取到任何想要的东西，并可以获取到足够的数据应用能力。

为了这个愿望，大部分的数据人朝着这个终极目标去努力，但是到头却发现，这个泥潭越陷越深。大家都在泥潭中不停挣扎，需要面对天天变化的业务与严重不规范的数据结构、确定什么样的数据源，数据的含义是什么，数据的上下文是什么。数据质量令人头痛，还面临业务数据中元数据的丢失、业务文档基本没有，问了一圈还没人知道等各方面的问题。

个人相信，以上提出来的这些问题，不管是数据仓库、数据平台、数据中台都是要帮助企业达到这些目的的手段，而不是目标的本身。以用户为中心的持续规模化创新，是数据体系建设的核心目标。

企业有成千上万，不同企业发展不同阶段，对于上数据建设的意愿度与驱动力也是不同的。有的企业还在准备上马数据仓库，有的已经建立自己比较完善的数据平台，而大厂、准大厂已经数据中台化，也或是走在中台化的路上。

当还在为在实施数据仓库、一套BI的时候，当还在努力为了数据平台而在投入资源实施时，风起了数据中台。不管三七二十一，抢先发布博人眼球甚是“高大上”全套解决新概念。

随着阿里的中台战略对外宣传与更加的火热起来，到现在各种培训都来了，如“中台产品经理”、“实施中台战略”、“如何实施中台”，甚至在一些数据产品经理群里还会有招聘数据中台产品经理。

相信每位老板、每位数据建设者在面对数据仓库、数据平台、数据中台这个宏大的多概念混洗在一起时，会是怎么样一种万马奔腾的心情。在实施的过程中到底使用什么方法论？仓库、平台、中台到底有什么区别？

我们先回到企业上数据的基本上来，企业到底要一个什么样的数据管理体系，到底要什么样的功能？为了解决什么问题？需要根据什么原则去设计与实施？

笔者特别赞同一句话：“资源整合，降低成本，同时探索新的商业应收模式”。其中要求，不管是在平台阶段、数据中台阶段都是要必须去满足。

在这个干中台的不如讲中台的时期，希望不要继续误导企业上什么平台。其实，中台到底是什么并不重要，这只是一个概念。每个公司有每个公司的方法，如何想方设法持续提高企业对⽤户的响应⼒才是建设背后最核心的逻辑，更好服务前台规模化创新，进而更好响应服务，不管是中台还是平台能够有显著成效就好。

自己也看了很多，但是也没把中台这个概念想得特别清晰。其实不用纠结概念，还是那句话“中台是什么并不重要，每家公司要找到适合自己的方案并推进落地”。

在上面开篇时提到了企业上数据需要解决的问题与面临的困难，那该用什么方案去实施？现在数据这几种方案有什么异同点？

一个企业构建一个数据平台，是否已经标志着企业的数据应用能力就完全上一个新的台阶呢？或许不是绝对，与一些企业管理者沟通起来得到的信息就是成本太高，如何节省成本？

回顾为什么会提到这个问题，不管是传统企业还是互联网企业，因为企业的发展速度、形态与数据量等都不同，在开始进行中台转型时会从不同的接入开始切入。像接触几家家企业实施一样，还是处在数据仓库的时代，不停无限满足业务的统计、看数需求，就要尝试开始数据中台转型。

一个业务成熟、相似并行业务较多的企业、数据体系成熟的公司往中台转型将会是更简单一点。在一些业务的单一模式，业务变化还非常迅速、不停试错的时候，是在想不到有什么能力可以往中台上去做沉淀，不如先搞平台来做支撑。

在写这个系列时，我的观点是非常明确的：我不反对中台这个概念，反而认为中台是很有必要的，“随着时间的沉淀，中台会逐渐的沉淀出来”。

作者：松子（李博源），自由撰稿人，数据产品 & BI 资深总监。2000 年开始数据领域，互联网数据考古工作者一枚，经历了互联网古生代、中生代、今生代。作者公众号：songzi2016。

本文由 @松子 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议