2020年9月12-13日，人人都是产品经理举办的【 2020杭州产品经理大会】完美落幕。拥有14年IT相关工作经验，12年产品经理工作经验的SHEIN首席产品架构师@翟锦修，他带来的分享主题是《抽丝剥茧与聚沙成塔-数据中台产品的实践与总结》。

我今天要讲的主题是抽丝剥茧与聚沙成塔，是一个比较偏干货的内容，就是数据中台的产品实践与总结。

一、解构数据中台

我们先看一下搜索的百度指数：

这个词很好玩，很多年以前我们没有人去关注数据中台这种东西。差不多2018年的年初吧，那时候还在谈做业务中台、做订单、做购物车。

2019年我在广州的演讲当中，就专门讲了交易平台应该是什么样子的、它的典型构型是什么样子的、应该怎么去构建、需要什么样的产品经理。

当时特别火，很多人听完了之后觉得这是一个特别好的方向。

那么，这么多人去搜索中台，就证明它让大家很关心，或者大家都很注意这件事情，它是个热词。

但是那么多人搜索也代表另外一件事情，就是它其实做的不好。如果大家都会做或者一做就成，你也不可能天天去搜它，所以它就是一个高不可攀的、大家关注的热点。

1. 灵魂三问

说来说去就是灵魂三问，这就是我今天演讲要回答大家的问题：

1. 这是个什么东西？他到底解决什么问题？
2. 我们公司可以推行这个产品吗？有哪些前置条件？
3. 我应该如何学习这方面的知识？需要掌握什么样的能力？

一谈到数据中台，我们就会看到这些名词。

我进入数据中台产品的契机，是原来在苏宁易购的时候去主持了公司数据中台的一个建设。

其实我们做的时候不是从这么高大上的角度出发的，它是一个业务系统，要来解决业务上的诉求、要来解决企业的问题，那企业会碰到什么问题呢？

我们先来看一个简单的问题：请计算一下今年我们的库存周转率是什么样的？

这个指标在每一个财务上都要体现，根据库存周转率，要去确定要不要做清仓、要不要减少供货、要不要提升促销的频次，这么简单的一个数能不能特别简单的呈现在我们眼前：告诉我到今天为止，某商品的库存周转率是多少。

把它算出来不就好了吗？

——算不出来。

因为这个公式还挺复杂的，如果你要算一个库存的周转天数，你需要用365天去除以库存的周转次数，如果用库存的周转次数来求这个值，你需要用这一段时间的总销售额除以你的平均库存；如果你要去算平均库存，你需要以这段时间的最初的期初库存加上期末的库存去除以2。

难吗？

正常计算机一算，马上就能算出来这个结果。

但其实很难，因为它有很多的逻辑。

当一个公司做的足够大的时候，它的业务形态就会变得很复杂。一千亿级的销售规模的公司，甚至是几千亿销售规模的公司，你的业务形态中就会有各种各样的要素。

比如说：你要算一个销售额，那还没有完成退货周期的、大家还可以退货的商品，这种算不算？

——不知道。

如果是货到付款的算不算？

——不知道。

他的下单支付里用了优惠券的那一部分算不算？

——不知道

这些都要去考虑，你考不考虑会退货这个数据？你考不考虑在途数据？一般这个事情只要一吵，那大家就会提出各种各样的设想。

财务部门有一套计算标准叫财务口径，仓储部门提出一套计算标准叫仓储口径，再来一个运营口径，再来一个IT口径。然后大家开始讨论，按照我的来计算我这个值应该是什么？按照他的来计算那个值应该是什么？

所以往往都得这么讲，这个数据是基于运营口径统计出来的，如果不服就找运营，就这么一个结果。

所以就会形成这么一个情况：A部门有自己的口径，B部门有自己的口径，C部门有自己的口径，集团那边也有集团的口径啊，整个公司有公司的口径。

这时候老板提了个诉求，我们要通过一个叫推荐的系统，把库存周转天数和库存周转率比较差的商品做一下清仓，大家开始吵，到底按照谁的口径去统计库存周转率第一的。

然后在中间伴随着程序员同学的bug，比如：财务的这个数据统计虽然科学，但是系统不行，经常统计错误，我们还是相信运营的吧，这种情况也是会有的。

企业到一定规模，这个需求就会变得很复杂，一些很简单的事情就很难再去做了。

从我本人的经历而言，我曾经在一个国内前五的互联网公司里面亲眼看到，董事长站在台上号召大家一切以数据说话之后，我们在一年之内，可以为不同的角色去做数千张报表，因为我们有数千位研发人员，他们可以不停的去立项目，不停的开发各种报表。

所以我们在整个体系中，就做了一个特别简单的需求：能不能让运营总监、财务总监和仓库总监每天看的GMV这个值是一致的？

就这么一件事就需要IT副总裁站出来去抓，怎么抓呢？每天核对数百张报表，你们是不是一样的？谁不一样？当天承认错误，拿回去改。

其实把数据对起来这件事很容易，毕竟你可以牺牲一个IT副总裁。

2. 数据的性质

1）统一性

比如：统计口径一致、系统逻辑一致、管理流程一致……

2）安全性

就是除了统一性之外，还有安全性的问题。

数据会不会泄露？会不会没有权限的人看到了他不该看的数字？会不会出现数据的敏感度问题？比如你在查询用户的交易数据的时候，看到了他的收货地址或者电话号码，那这个很危险了。

3）时效性

我不光能看到，我还能准时的看到。比如说我做一个按小时计算的销售规模的统计，你两天之后让我看到有什么意义吗？

4）可靠性

最后一个就是必须高并发高可用，还必须有好的质量控制，数据要是对的，而且还不能坏；当出现问题时，我还能追踪到问题在哪：到底是业务系统那边做错了，还是数据仓库清洗的有问题，还是指标统计逻辑有问题。

5）灵活性

那么多的指标，那么多的报表，那么多的服务能不能不写代码？我就配一下就可以了，这叫灵活配置。

3. 数据中台的定义

数据中台的本质，就是数据统计和应用分散的情况下，他通过建立统一的数据指标服务体系，结合业务安全风控的相关诉求，完成数据的采集、清洗和建模的行为，并提供准确与及时的数据服务，以满足企业不断变化的数据统计与数据应用的需求。

数据统计是在报表上看这些数据，如果我在一个系统当中使用数据做判断，那就是数据需求。比如说我在商品销售的排行榜上观察转化率、库存情况，那就是在业务流程当中去使用数据。

这些东西说起来都是高大上的，翻译成大白话其实就是一句话：把数据及时的统计清楚，别泄密，别出乱子。

这并不是数据中台的全貌，但肯定是它的需求、来源和驱动力。

4. 什么样的企业需要数据中台

数据中台这件事情要从三个问题做解释：

1. 公司有没有数据分散化的痛点？
2. 有没有长期的、大量的、时限性的、不断迭代的数据统计和数据应用的需求？
3. 在数据统计和应用上，对安全、风控、稳定性有没有诉求？

如果你是一个小公司，不小心出现了数据泄漏，可能不会受到什么追溯；但是如果你是一个有影响力的公司，一旦出现这种问题，面临的就是各地的诉讼风险。

作为一个数据中台系统的负责人，你肯定要保证这个系统的安全性与稳定性，也要保证风控的合理性。我肯定不会把会造造成诉讼风险或者消费者投诉风险的数据，泄露给不该看的人。

数据中台很难开发，他需要投入大量的人力和时间。

如果公司很穷，虽然我对这个事情很需要，但是没有钱开发，这是不可能的。所以，硬功夫一定要有好——对于老板来说，人民币要准备好；对于产品经理来说，需求你要判断好。

5. 几种常见的中台

中台其实有很多，包含数据中台、交易中台、营销中台、AI中台、内容中台、供应链中台、技术中台等等。这个年代是个中台泛滥的年代，好不容易把中台的概念讲清楚了，然后又有人喊我们要去中台化。

我们作为产品经理或者作为一个IT人，自己心里面要明白一切的产品是为需求服务的，只要这个需求是存在的、合理的、企业需要的、用户有诉求的，你不要去管现在市场上怎么说，就把它给做好，要独立的判断，形成独立的独立人格。

常见的中台有很多种，但是它们互相之间没有什么关系。它们除了思想是相同的，都在打通烟囱状的结构，做统一的管控和统一的体系。除了这个以外，其他的没有什么相同的地方。

二、项目实践总结

1. 抽丝剥茧

1）为什么要抽丝剥茧？

我们来举个例子：当你去建设数据中台的时候，就觉得这个事情很简单啊，不就是把数据统计清楚吗？把报表是怎么做的、把产品设计文件拿过来看一眼。

看完一遍之后呢，你会面临一个纷杂的情绪：同样的指标，有同词不同意；有同意不同词；还有互相包含，就是我的这个指标当中有你的一部分，你的指标中有我的一部分啊；还有风马牛不相及但是却出现在同一个报表上——这都是有可能的。

面对这个庞大的体系，让你把数据中台做出来。其实搭建的时候，我们就有一个扪心自问的过程：我们到底从何下手？从哪里开始建？

我自己的思考就是，我觉得我们其实可以忽略那些乱七八糟的东西，也可以忽略那些高大上的概念，回归到本质，我们就是为了指标服务的，所以我需要问清楚一个问题：什么是指标？它应该如何被解释？

你看抽丝剥茧，咱们去分析一下这个指标，这个业务到底是怎么回事。产品经理不是要做需求调研吗？不是要做产品规划吗？那你指标的核心逻辑到底是啥？

来看一个指标：我们要统计美国市场的ROMWE品牌，在2020年6月在APP上的有效订单支付金额是什么——这就是个需求。

它由有四个条件组成：美国市场、ROMWE品牌、2020年6月份、app上，限定了这个值的区域和范围。我要统计这个值，前面四个条件在过滤这个数值的大小，我们管这个叫维度。

美国的市场就是区域维度，ROMWE品牌就是品牌维度，2020年6月份就是时间维度，APP就是销售渠道的维度。

你可以用这个维度，你也可以换别的维度。

比如：你把美国市场换成欧洲市场，你把2020年6月份换成2020年5月份，维度值是可以调整的，但是维度是这个指标是必须存在的。当你取消那个维度之后，这个指标的颗粒度就会变粗。

比如：你不统计美国市场，统计全部市场，颗粒度就会变粗。

然后下面我要统计有效订单支付金额，就是我们要统计的数据，这个就叫度量。

我悟出了一个真理：原来指标就是有维度和度量组成。

我们可以给指标下个定义：指标呢就是描述一个数据统计业务的最小单元。我们用这个例子来解释了，但是我们发现它不全面，还有别的问题，因为有一个新的需求会产生。

我们要统计美国市场的ROMWE品牌在2020年6月份APP上的平均客单价。这个数据是统计不出来的，你的业务系统中没有任何一个数据在解释平均客单价是多少。

它需要有两个指标来计算：就是美国市场ROMWE品牌，2020年6月份在APP上的有效付款金额除以有效订单数，这两个一除就有了。结果发现不对，这个指标应该分两种，一种是直接统计出来的；另一种是计算出来的。

这个被计算出来的指标特别有意思，我们会发现它的维度是受限于它的子指标的维度的，也就是你要拿美国市场的ROMWE品牌2020年6月份在APP上的平均的有效付款金额，去除以同样这个维度的客单价，在订单数你才能得出一个正确的客单价。

如果把这两个换了，比如你拿美国市场的去除以欧洲市场的，就不知道算了个啥。

再往下，我们又发现了新的规律。统计指标、统计口径被搞定了，维度我们也清晰了，但是我发现维度之间有上下级的关系，叫上卷下钻，什么意思呢？

按照刚才那个有效订单支付金额这件事情，我们统计一下美国市场ROMWE品牌2020年6月份在APP上的有效订单金额，这是最粗的，但是我也可以把它变得细一点。

我按照商品品类做汇总：比如我一共有80个商品品类，我就有80笔数据。

因为每个商品品类都可以汇总一个有效订单支付金额，再细一点，按照商品来汇总，那我就有50万条记录；再再细一点，按照订单维度来汇总，如果你有1000万张订单，那你就会产生1000笔数据，从而知道每张订单的有效支付金额是多少。

2）什么是指标？

说了这么多，我们来回答一个问题：什么是指标？

指标，就是一个数据统计的最小逻辑单元，它分成单一指标和衍生指标，衍生指标有一个或多个单一指标的计算得来。指标有维度和度量组成，需要注意的是，衍生指标的维度来源于组成其单一指标的维度的交集。

单一指标需要经过数据统计的前置筛选，才能在逻辑上成立；衍生指标没有自己的统计口径，其统计口径寄生于组成其的单一指标身上。

然后指标的维度存在上卷下钻的关系，这个关系是在业务逻辑层面上的。如果上卷下钻没有业务意义，它绝对不存在；但是从维度表上只要有关系的，都可以上卷下钻。

今天的议题是产品经理的新可能，我们可以回到公司的战略层，回到企业发展的战略上去思考问题，这是一种新可能；但是我们也可以到逻辑层去总结事物的规律，通过架构规划、模型规划、业务建模规划的方式，快速的帮企业解决问题，也是一种新可能。

所以我认为作为一个产品经理而言，抽丝剥茧、总结规律、还原本质的能力，是最核心的能力。衡量一个产品经理是否优秀的标准，并不是你PRD写出花来或者原型图画出什么样，而是否能够解构问题、还原本质、找到规律、寻找最优解。

去建设最优解、发展规律，那就应该有一套方法论——我该怎么去找到规律、怎么去发展、怎么去找到这个细节，需要这三段论：Jump In 、Jump Out、Jump In.

2. 三段论

1）第一段：Jump In

要深入细节，全面观察；窥斑见豹群，准确推演；还原场景，寻找规律；交叉验证，排除杂音。

这一段其实就是场景与调研的Jump In，如果你去做一个像指标这样简单的业务，没有足够的沉入，没有足够的专心，你做不好的。

所以要沉的够深，要足够的信心，要扎得够狠。要跳出细节，回归本质，用上帝视角做敏感的洞察思维，大胆假设总结规律。

2）第二段：Jump Out

等你跳出来了，觉得大方向上没有问题，不要轻易下结论，还要再跳回到那些纷杂的细节当中，去一个一个的验证你总结出的规律是不是适用，要保持一颗谦卑的心。

当发现这些规定不适用的时候，就要大胆的扇自己的脸，我错了，我要改。

3）第三段：Jump In

其实就是场景与验证的Jump In，需要回归到细节，做仔细的核对，小心的求证，严格的论述；要对场景进行理清，一定不要有遗漏，要及时的调整，要迭代更新。

所以，用思维去击穿复杂的逻辑，抽丝剥茧，发现问题的本质，这是一种需要被加强的能力。

这就是在当下产品而言，就是为什么B端产品、AI产品、策略产品、中台产品这些厚重的领域，成为当下的产品经理热门的原因，就是因为它对能力跟素质有新的挑战，不是大家能轻易适配的岗位。

物竞天择，适者生存，市场规律就是供给多了，需求就容易满足；供给的少，自然价位就高。所以你要去做那个供给少的环节，成为这个行业当中比较少见的人，而不是成为普遍的人。

3. 聚沙成塔

1）指标设计器

当你把一个东西解构的足够深的时候，你会面对一堆的需求碎片。

如何去构建一个数据中台？

给大家的奉劝是，不要贪大求全，先找到离你逻辑最近的那一步，叫第一层立足点。找逻辑点的时候，我们发现指标尤其是单一指标，其实非常简单。

如果大家是成熟的产品经理，脑子里面能想出这个页面长什么样子。

2）建模工具

我们可以通过建模的方式，使数据库的表可以支撑指标设计，一个表结构其实就是一个星星一样的结构。

这是第二层，我们又做了一个塔。如果指标可以配置，就必须配置好对应的模型数据，否则指标就是无根之树。

3）加速层

我们需要搭一个链路，首先我们要把模型设计器的信息同步到加速层，把指标设计器产生的信息同步到指标服务层，由加速层的实际的物理数据向指标服务层进行。

4）数据仓库

我们既然解决了数据的模型层、物理层，还有个问题：数据的源头从哪来？

这个就很简单了，我们把它架到数据仓库上面，从数据仓库中把数据提炼出来，送到这几层进行服务——这个就是聚沙成塔的最后一层，我们要找到回归我们业务链路的那个连接点。

5）管理系统的搭建

模型管理系统，要通过建模来设定星状模型，去选择加速引擎，选择宽表的建设方案，并且让加速引擎去正确的执行。因为加速里面的执行有很多细节的配置，都要在这个模型管理系统里面去进行参数配置。

那下面就需要建设数据仓库，数据仓库就多了，我需要建设数据的质量系统，需要建立原数据管理平台啊，对业务员数据、技术员数据进行口径上的统计，进行数据的存储等等。

当你去把核心逻辑抽象出来的时候，随着一段一段的扩展，终于你离开了逻辑回归到了用户，你在想谁要使用这套系统，业务流程应该怎么开展？他们基于这个核心业务应该搭建什么样的机制？

你看聚沙成塔了，它不再是沙，它变成了物理上可见的建筑，可以遮风挡雨。

6）支撑系统

当你搞定了业务的时候，你会再去外展一层支撑平台。它跟业务没有关，但核心逻辑有关，它提供的是系统的、高可用、高并发和高保障性。

它对数据的质量负责、对数据的追踪负责、对数据服务的可靠性负责，这是一定要做的。

我们回到聚沙成塔这件事，聚沙成塔其实就是从碎片化的需求当中，结合公司的内外部资源，将产品体系一点一点的拼装起来的过程，以满足业务诉求。

我们聚沙成塔的核心是用上帝视角来来审视整个产品生态，区分层次，层层的去做业务建模和抽象。

三、数据中台的道与术

1. 道

1）懂得布局

回想过去的一年，我们做了很多翻译官的事情，把业务的需求传递给开发，把开发的困难传递给业务；还是传声筒，把老板的压力传递给下面，再把下面的反抗力传递给老板。

但是如果你想真正的成为产品经理，上述的抽丝剥茧和聚沙成塔，才是你们强大的武器。有一个专门的词叫产品规划，有一种专门的能力叫产品架构能力。

所以，当下顶着产品经理和产品总监头衔的人不一定在干这件事，有可能干的是上面的事，他被别人定义成为一个执行工具。只有那些在真正的抽象逻辑、定业务、承担责任的人才是。

又回到刚才的灵魂三问：我应该如何学习这方面的知识、掌握上面的能力？

我的方法论可以总结为三个字，叫：时、势、事。

就是你要在正确的时间、在正确的趋势下去，用正确的方式去推动一个产品的发展。如果你的公司对这个事情没有需求，你要不要储备这样的知识？

要的，那只是时机未到。

不谈这件事，不是企业没有需求，是你没到那个时候，那到那个时候怎么办呢？

赵本山说过了，你不是改变大局的人，你需要等待时机。如果我们时机到了，是不是就可以推动这件事情往前走呢？

——也不是，你要营造趋势。

要让所有的协同者，跟你接触的人都认可这套理论，形成合力、达成共识。凝聚力是非常重要的，大家都认可这个方法，认可这个方向、认可这套理论，大家就可以解决各种各样的问题。

很多事情不是做不好，是不想做好。只要你想做好，你有一百种方法把问题解决；如果你不想做好，对于一个问题，你有一百种理由说不可以，这就是势的作用。

所以你要学会利用势能营造这个趋势，让大家认为这是正确的方向，正确的目标，最优解。

再往下就要考验你办事的能力，你要用一种成熟的项目方法论，稳定、安全、极致、快速的建设正确的系统。只要你在推动一个项目发展的情况下出现了问题，大家就怀疑你是不是对的、时机是不是合适，理论是不是合适，你会受到质疑。

2）懂得平衡

我们永远站在技术、商业和体验的三者之间，我们为用户争取用户体验，包含内部用户和外部用户，我们为公司争取商业利益，同时我们也消耗着技术资源，提升着系统的技术难度。

但是一定要有一个平衡点，这个平衡点就是最优解。我刚才讲的那一切都可以忘掉，那都不是你的方案。回到你的环境当中，如果你要推这个系统，你要这三个点中寻找一个平衡。

所以回到方法论就是要找到平衡点，也许你的平衡点一脚站在了技术。实事求是才是最重要的，没有完美的方案，只有产品方案上相对的平衡。

2. 术

1）项目建设方法论

在术方面你要明白一件事，建设类似于中台这样的系统，稳定永远压倒一切，安全永远压到一切，比解决几个漂亮的逻辑要重要的多。所以你一定要学会瀑布式的建设和敏捷迭代的相结合，又快又要好。

任何时候都要有plan B，不能影响到线上业务。

最后一个就是，你要舍得在抽象和论证上花时间，抽象清晰，仔细验证。

2）练好基本功

你要能够想透一段逻辑、画好一个流程、做好一个原型、写好一篇PRD、开好一个评审会，做好一次项目迭代，如果你连这个都做不了的话，就不要侃侃而谈什么战略和规划。

所以，仰望星空是很重要，但是脚踏实地的去完成一件事情更加重要，自身的功夫要不断的修炼。

我已经做产品十七年了，但是我还会画原型，还会做PRD，这是你最基础的能力，就好像一个架构师永远不会离开代码一样，一个高级的产品人才永远不会离开一线的逻辑。

2020产品经理大会预告

2020产品经理大会全国巡回现已开启，广州、上海、北京三城同步预售，与一线产品操盘手们一起，聚焦于探索产品经理与技术、体验、创意、产业、B端的连接，发现更多产品经理的新可能！

戳此链接或点击图片，了解大会详情：http://996.pm/M0d06

相关阅读

从系统观到商业观：产品经理的修炼感悟

像经营品牌一样，经营自己的职业生涯——这是2020对产品经理最想说的话

交易平台，究竟应该如何设计？

选择创业，如何走好创业的每一步

疫情之下，新旅游的破局增长

本文为【2020杭州产品经理大会】现场分享整理内容，由人人都是产品经理运营 @Emily 整理发布。

未经许可，禁止转载，谢谢合作

题图来自大会现场