当前位置:主页 > 交互设计 >

在写完30万字的中台100讲后再来谈谈中台

发布日期:2021-05-14 19:49   来源:未知   阅读:

  最近在我写完中台100讲(《中台产品经理宝典》一书+中台实战30讲)的内容后,我终于有空在我的公众号上去回答和接受邀请去往很多企业参与中台方案的评审。

  在这将近一个多月的沉淀与走访中,让我对中台这个概念在一线战场使用的人群中有了新的了解,也正是如此我决定再写一篇中台本质探索的文章,来对近期我遇到的中台高频疑问进行一个梳理。

  最近关于中台争议最大的一个消息,莫过于张勇近期在阿里内网发布的一段话,大概意思如下:“张勇对目前阿里的中台建设并不满意,他直言道现在阿里的业务发展太慢,要把中台变薄,变得敏捷和快速。”

  而这段话在流出后,被自媒体一番加工后变为了阿里开始要拆中台,于是乎很多人阅读完这些文章后,也开始说中台已经成为被阿里抛弃的产物。

  那事实真的是这样吗?这里我想说其实这些自媒体其实已经从中台的概念源头出现了理解偏差。

  也就是说如果有人认为中台是一个具体的产物或一个系统,那么此人对中台概念已经产生了相当大的误区。

  基于这个错误的认知,加上市场一些SaaS企业的恶意炒作,在市场中很多IT企业主就产生了这样的认知:

  企业主的决策认知:我要降低成本 = 所以要上中台系统 = 我不清楚中台是什么,我也没有能力自研 = 我要去买一个中台系统。

  大家试想下,无论是之前的某酒厂的中台失败案例,还是某电商的3千万的中台流产项目,这背后其实都是这样的企业主在把中台与一套神奇系统画等号后,进行的一系列错误决策。

  这里我想说:中台概念其实只是一种设计思路,本质来说就是当企业发展到一定规模后,一次企业内部改建。

  众所周知在互联网公司内部的产品其实都是为企业业务所服务的,在很多时候产品的建设都需要优先满足于业务的需求。

  因此在很多公司中,会出现为了追风口赶业务新产品会在现有产品基础上进行临时搭建,快速拼凑出一个临时产品。

  违建虽然在一定程度上临时满足了我们的需求,但是他给整座大楼带来了安全隐患,会影响到楼层的稳定性,同时也将原有的楼层主体进行了破坏。

  而且更重要的是这种临时建筑由于没有进行全局的设计,只是在现有的结构基础上临时拼凑出来的,就会导致其自身的使用性能与使用体验远低于正常水平。

  所以很多时候,在新业务发展到一定时间后,我们都会选择重构来为新业务重新设计产品。因此中台这个概念,本质上就是一种企业内部全产品线的一次改建方案,具体来说分为两点:

  第二点这里我再举个不怎么正确但是很好理解的例子,就是当我们需要再开发一个新的商城时,在公司内部我们可以选择把做的最完整那条业务线的PRD与代码拿过来,此时我们就有了个现成的商城。

  当然为了让一份PRD与代码可以全公司复用,我们在设计时就需要尽可能的抽象,比如在某业务线中设计的入库模块,他们根据业务需要在入库类型中定义了海淘商品入库单、残次品退货入库单两种类型。

  但是大家试想,如果在新的业务中,商城中不涉及海淘的业务,那么在拿到这个业务线的代码时,就会觉得这里的入库单还需要二次开发。所以我们在将自己的代码交给别人复用时,我们应该先将自己业务的逻辑剥离掉。

  比如这里,我们就应该将海淘商品入库单、残次品退货入库单进行业务剥离,得出抽象后的入库单与退货入库单两种原子组件。

  当然这里的例子不是很正确,只是为了帮助大家理解。在实际的中台抽象中我们需要大量的建模,原子组件定义等等,这里我就不展开详述了,感兴趣的可以去看看我的《中台产品经理宝典》一书。

  当我以外部专家身份,参与了多家企业的中台方案评审后,再来看这个问题,我的答案就是:中台产物其实就是六个字,“下定义、给标准”。

  当有多个业务线都存在同一事物时,我们要通过中台的改建将这些不同的事物进行统一化。例如在电商中,一提起指标,在不同业务线中就变得五花八门。

  例如毛利、核心用户群,每个业务线都有自己的定义,而我们要做的就是要给这些不同业务线都有而又定义不同的事物一个标准的定义。

  当然这里的定义我们不能一味地为了大而全就把所有的业务概念进行统一,就像上文提到的核心用户群,在不同的业务线中确实是存在不同的定义:

  此时这样的定义可以看出存在明显的业务诉求,因此我们应该保留而不需要中台进行统一定义。

  除了要对企业内部同一事物进行下定义外,在很多时候我们还会遇到,很多业务线确实对同一事物有个性化的需求。

  例如订单中心,由于各个业务线的业务模式不同,我们最终落地的订单就会有对应的业务场景所需的功能嵌入。

  此时进行中台化,我们要做的内容就是对这些订单定一个标准,告诉各个业务线你的订单生成逻辑需要有什么样的标准、什么样的数据格式、业务线的个性化需求插入方式。这样当我们去统计各个业务线的订单时,我们就有了一套标准的订单格式。

  这样在中台看到的订单,就不会存在有的订单是10个字段,有的是15个字段;存储的信息范畴也不同,有的存储商户ID,有的存储商户CODE等等。

  本质上中台让各个业务线的订单创建流程、字段数、存储格式上都有了一套标准。

  最后,中台并不是一个具象化的系统,而是企业内部进行信息化自我升级的一次改建工程。

  因此中台要能够顺利的完成企业内部的建设与实施,所必经之路就是要对企业内部的业务与信息化有充分的调研,在此基础上以强定制化的方式给出适合本企业的中台解决方案。

  最后的最后,说一句会触动现在市面上很多软件服务公司利益的大实话:任何企业都绝不可能凭空给出一招鲜吃遍天的通用中台解决方案或软件。

  三爷,微信公众号:三爷茶馆,人人都是产品经理专栏作家,2019年年度作者。《中台产品经理宝典》作者,原万达高级产品、MBA特约讲师、独立创业者,现叮咚买菜B端产品线负责人,拥有多款集团项目从零到一经验并带领实现商业化布局。

  嗯,同意,和我理解的一致,在我刚接触数据中台的时候以为是一整套成熟的解决方案去解决企业的数据问题,可是后面进一步研究发现,数据中台其实是一个过程的最终输出的产物,重要的不是数据中台本身,而是过程,也就是说数据中台是一种思维方式,以数据治理为基准的思维方式,每个企业实际环境不一样,所以数据中台的建设也不会一样。

  听到很多言论说在中国程序员是吃青春饭的,那么产品经理呢,也吃青春饭吗?

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。