抽丝剥茧与聚沙成塔——数据中台产品的实践与总结

1 评论 2315 浏览 11 收藏 34 分钟

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 整理发布。

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

题图来自大会现场

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 谢谢分享,学习了

    回复