附耳细听，到处都在喊中台，似乎不知道中台就差了意思，张嘴闭嘴说中台才算OG老炮儿。

但是，时至今日，中台仍然是一个被定义中的概念，大家对这个词汇都有感觉，但又很难具象与明确出来。

说起中台的意义，笔者认为在于：快速的响应需求，整合资源，在复用原有能力的同时，发现新机会。

关于中台的实际落地，有这样的分类：技术中台、业务中台、组织中台，或者直接分为：业务中台与数据中台。

本文将简单剖析一下数据中台，并尝试着明确数据中台到底需要什么样的产品经理。

到底，什么是数据中台？

首先，数据中台是为了汇总与融合企业内的全部数据（甚至企业外的数据），打破数据隔阂，解决数据标准与口径不一致的问题。

举个例子，多个系统中都有“包子”这个字段，但定义不同：

• A：有皮有馅就是包子；

• B：有荤有素就是包子；

• C：吃了解饿就是包子。

不同定义的最终产物是：同样的“包子”，却有不同的指代物。

这就是数据标准与口径的不一致的弊端，也正是数据中台需要解决的问题。

解决了上述问题，做好了数据治理后，数据中台还需要成为对外提供统一的数据服务接口的数据集成平台。

在这个过程中，不断完善的数据体系，会不断的丰富各类场景所需的数据。

这也是数据中台都在推行 One Data（一个数据管理体系），One ID（打通的用户体系），One Service（一个服务平台）的原因。

再举个例子，公司多个系统或产品都有用户“石头”的使用记录：

• A-租房App：石头最近在关注北京海淀区的房子；

• B-求职App：石头最近投递了海淀多家公司的岗位；

• C-外卖App：石头点餐配送地址都在朝阳。

根据上述内容，如果数据的打通的，且遵循One ID（其实就算注册账号不同也有很多办法来进行关联判断），我们得出的结论是什么？

大致的结论：石头计划从朝阳跳槽到海淀，正在找海淀的房子。

我们可以再细致一点：根据石头点餐的习惯，可以判断ta的日常饮食习惯，结合石头浏览的租房内容可以判断ta的消费档次，再结合投递职位的薪资，我们可以计算出ta的基本收入……

然后呢？一个完整的用户画像跃然纸上。

但是，数据融通带来了新的问题：数据隐私。

从技术层面来看，数据中台是“数据仓库与数据服务中间件”的组合，因为海量的数据，所以需要分布式计算平台和存储平台，而且技术是中性的，没有善恶。

从数据应用来看，数据中台汇聚了企业内外部的各种数据，除了企业自身数据，还有大量的用户数据，根据这些内容去挖掘商机是企业商业化的有效途径，但“隐私”的门锁，握于谁手？

数据中台的价值是从正规渠道获取数据，应用到阳光下，数据资产是黑是白，就在于此。

但，不可否认的是：数据中台极具使用价值。

在极具价值的数据中台里，产品经理会扮演什么的角色呢？或者说，数据中台到底需要什么样的产品经理？

通过数据中台项目内容与最终输出物来看，数据中台需要的产品经理分为两类：数据产品经理与数据平台产品经理。

关于数据产品经理，知乎大V何明科大大有这样的描述：

简单说，数据产品经理既要完成数据体系设计，让原本无序或庞杂的数据变得“规矩”，又要根据业务场景的变化，不断调整项目内容，推进项目进度。

不得不说，在推进数据中台项目的过程中，开发难度所带来的压力，要远小于数据资产的盘点与整合。

以“包子”的内容为例，数据产品经理需要给“包子”明确出最终的定义，并让各个系统执行。

问题在于：不同的系统归属于不同的部门，你凭什么让别人配合，甚至修改人家用了很久的系统，而且修改内容可能并不会给所属部门带来直接的收益，直白说，这样的工作内容不在KPI范围内。

怎么办？

数据产品经理就像一个“天条”的制定者，却没有执行天条的权力。

如果项目有一把手坐镇，倒可以“挟天子以令诸侯”，但其中苦楚，不足为外人道也。

所以数据中台需要更具沟通能力的数据产品经理，能够在与多个业务线，需求、背景、想法各不相同的相关方一起，推动完成相关功能的实现，有效的达成沟通目的，这一点，不仅重要，而且很重要。

结合数据中台的特性，我们发现：

数据中台的数据产品经理，需要不计一地一城的得失，得有战略思维，也需要缜密的逻辑思维能力。

数据中台所含数据内容庞杂，数据来源之多，远胜单业务线的数据体系，如何完成这一庞大数据体系的设计，是个极大的考验。

数据产品经理，作为数据建设的推动者，需要强大的战略思维和逻辑思维能力，不仅可以判断出当下业务当中的关键流程，更可以不受限于现有业务规模，理解业务接下来的发展方向，做好数据体系扩展性设计。

数据产品经理的基本能力当然更不能丢，业务逻辑梳理、维度指标体系设计、数据建模、数据可视化设计等等。

归纳一下数据产品经理的技能点：

• 语言：SQL、R语言、Python等；

• 可视化工具：Tableau、FineBI、Cogons等；

• 硬实力：熟悉Hadoop集群，数据挖掘与数据分析；

• 软实力：沟通、行业认知、深度思考。

需要说明一下，数据产品经理不是数据分析师。

简单来说，数据分析师更多的是在解决业务线具体的问题，而数据产品经理是在进行业务抽象，通过产品化的方式输出数据。

数据平台产品经理，就是广义上的产品经理，只不过这些产品经理在做数据类产品的相关设计。

他们天天与数据打交道，但不用进行数据分析与数据体系设计。

他们的工作是为数据分析师与数据产品经理打造更多的平台工具，然后把数据分析的成果通过产品化的方式展示给用户。

前者包括：调度平台、实时处理平台、Hadoop生态组件等。

后者包括：可视化报表平台、BI系统、移动BI系统、用户画像平台等，如果有面向用户或者To B的需求，还可以打造如淘宝指数、百度指数这类的数据产品。

浩瀚的数据宛若汪洋，数据产品经理给这片汪洋制定了“洋流与风向”等“天条”规则，但是出航远行还是需要一艘巨舰方舟，这样才能更快的到达各个目的地，数据平台产品经理就是这样一艘方舟的打造者。

数据平台产品经理这位“方舟”打造者，是在用产品化的方式，让内外用户更便捷的使用与查看数据。

所以数据平台产品经理，在满足广义产品设计能力的基础上，还需要以下能力：

• 数据可视化能力，了解数据平台功能框架基本逻辑；

• 具备基本的SQL能力，了解数据生命周期；

• 权限设计能力，尤其是数据权限的管控设计能力；

• 野望，要有平台商用的野望，并做好准备。

数据平台的起点是企业内部应用，商用也可能只是发展进程中的一站。但过程中，数据平台产品会历经很多“磨难”，比如：内部推广的压力、业务方对数据资产价值的质疑，商用的切入点难以找寻……

耐得住寂寞，有大刀雕花的技巧，才会水到渠成。

数据平台产品经理与数据产品经理在工作的分界线，存在融合，存在很多的交集。不少公司是将两个岗位进行了二合一，一人分饰两角，这倒也未尝不可。

有个前提，数据产品经理更侧重数据体系的建设，而数据平台产品经理更侧重工具与平台的设计，这一点值得了解。

至于数据中台对人才的需求标准，仁者见仁，智者见智吧。

可能中台是“新贵”，数据中台是“风口”，除了尚未解答的数据隐私问题（可能短时间也难以找到答案），还有一件事需要大家了解。

搜索内容是大把的培训机构在追风口，各种数据类岗位的培训广告赫然在列……

说句实话，虽然数据相关的岗位薪酬不错，但是数据相关的岗位需求量真的很小。

理论上说，中台是一种产品设计思路，或者系统架构思路，并不受限于公司的规模。

但是小公司没那么多的数据，不大不小的公司有第三方的数据工具，大公司呢，往往很难通过培训公司，培训一下就可以拿到offer。

所以，与其急于求成，倒不如按照数据岗位的技能要求，不断的淬火打磨。

路漫漫其修远兮，产品经理将上下而求索。