中台产品经理实战(12):中台建设的三大误区
自从阿里的数据中台获得成功后,国内企业纷纷仿效。但是,中台建设并非易事,在实际实施的过程中会有很多看似不起眼的因素会影响最终效果。本文给大家分享了中台建设中常见的3大误区,一起来看看~
近期很有幸受邀去某公司内部参与了他们中台架构的评审。整个流程简单来说就是由各个产品线的负责人对自己所负责的内容的近期产品版本进行规划,以及配合公司的中台战略进行宣讲自己的所负责模块的中台化。
但是很不凑巧的是,在这次评审中我听到了要建设不下十个中台,几乎负责每一个模块线的人都在谈要建设自己模块的中台。
例如搜索中心要做搜索中台,财务中心要做财务中台,商品中心要做商品中台等等。我当时听完就很震惊,这样的中台设计完全是撕裂了中台原有的概念。
然而这只是开始,在我听完整场中台架构的评审后,只能说这家公司的中台战略对中台这一概念本身存在着三个非常大的误区,我来一个一个谈。
误区1:服务中心=中台
我来谈第一个误区,就是这家公司中的产品负责人把只能算是服务中心的一项项基础服务称之为了中台。
所谓的服务中心就是指:我们将某一项在公司内部多条业务线都有相同或类似需求的服务抽取出来作为一项公共服务开放给不同的事业线。
例如在一家电商内部,如果我们存在着多个电商模式,那么此时我们对于基础的订单,商品,会员这三项服务都有共性的需求。无论我们的业务到底是海淘电商,还是自营电商。还是拼团电商等。那么此时我们就有了三个服务中心分别是商品中心,订单中心以及会员中心。
而不同的服务中心朝上聚合便得到了我们的业务中台。所以在这我们也得到了业务中台的一个定义:就是了将各个跑通并且验证过的具有复用性的业务组件抽取出来组成的一个业务半成品解决方案聚合中心。
因此也就是说,一家公司内部只会有一个业务中台,而业务中台内部架设着各种不同的基础服务。而任意基础服务都是中台的一个服务单元,负责解决各自不同的业务场景。
误区2:瘸腿的中台
第二个我在这次评审中发现的误区就是,这家企中台方案只有能力复用,而没有一个通用的接入方案,从而硬生生将火车变为了用马拉火车的奇观。
例如商品服务中心,如果要从一个普通的产品线内部的商品管理模块,抽象为中台的服务中心,那么并不是简单的将商品中心的读写接口开放出来就算完成了。
中台建设了复用之外,更重要的是我们提供一套接入解决方案,这个部分才是最重要的。我们需要有一套通用的总线机制,也就是建设一个企业内部的信息高速公路大家都走国道,又快又统一(有点类似于研发在微服务里ESB总线机制)。
具体说来也就是要解决如下几个问题:
- 业务线想要使用商品服务的功能是否只需要对接很少的接口就能完成数据传输?
- 对接的成本是否小于业务线自研一套商品管理模块的成本?
- 服务中心是否提供自动适配终端的功能?
- 开放商品服务的商品服务中心是否将周边的功能全部完善?例如商品采购数据统计、上下架数据统计。
从而让接入方能够只需要简单对接完成,就可以拥有一套完整的SPU/SKU管理、数据分析功能。
也就是在我的《中台产品经理宝典》一书中提出的中台建设的另一个重要部分就是中台输入,输出的“管道”定义,只有这样才能称之为中台内部的一个服务中心。
误区3:兼职的中台建设团队
在我听到各个产品线的产品经理在宣讲自己服务中心(他们眼中的中台)的规划时。我发现还有一个特别严重的问题,就是他们虽然认知到了自己搭建的模块是给公司各个不同的事业线团队提供服务的。
但是这些中台服务中心建设团队都是在现有业务团队中兼任的建设团队。
例如,由位于前台消费者电商业务团队负责整个公司的商品服务中心的搭建,从而使整个公司无论是在采购系统、仓库系统、商城系统都只有一套SPU/SKU以及后台采购分类。
然而在他介绍自己的中台规划的时候,我完全没有听到考虑其他业务线的效率提升。
而是优先以保障他们团队所需要的运营策略为主,强制要求其它接入商品中台的业务团队去兼容他的业务操作流程。
在评审中间就有其他业务部门提出了相关的质疑,负责大客户采购电商的部门人员直接指出他所设计的商品中心字段完全是按照消费者电商业务运营团队所需要而定制的。而他还需要例如商品采购返点这样的字段。
此时这位商品中心的产品经理给出了答案,是要求他兼容他的中台商品服务,也就是对于用不着的字段不用填(用不着的必填项填写一个默认值)。如果自己有需要的字段在自己的系统内部再单独开发。
那么我想说这样的设计就会使其他部门,如大客户采购电商部门的人员开发成本变得非常高。也让这边的运营效率变得急速下降。
用数字来看就是他们优先保证了自己业务团队便捷性,他百分百还原了自己的业务团队运营动作,而不管这个时候给其他业务团队带来运营效率下降50%乃至更多。
这也就是经常我们听到的一句话:两个80%要远好于50%+100%
理论上来说一个好的中台应该是平衡各个业务线。既不会让某个业务线的效率下降了特别多,也不会让某个业务线的效率百分百被还原,那么就失去了中台的作用和意义。
所以总结下来中台建设千万不能让一个部门兼任要有独立的建设团队,否则无可避免的他会优先以他所在的部门的需求进行考虑。
最后
在时下越来越多的公司开始认识到中台的价值,并想要去进行中台建设,这是一件好事代表企业开始重视企业内部运营效率提升了。
那么希望所有从事与中台建设或者规划的人员能清楚地认识到中台的本质是为企业提升效率而生的一个产物,不能再以狭隘的产品线各自为战的局面去思考问题。
对中台与高阶产品经理必备技能业务建模感兴趣的朋友千万不要错过我的新书《中台产品经理宝典》!
点击链接购买:https://item.jd.com/12888374.html
#专栏作家#
三爷,微信公众号:三爷茶馆,人人都是产品经理专栏作家。《中台产品经理宝典》一书作者,曾任万达高级产品、MBA特约讲师、独立创业者,现某支付公司产品线负责人,拥有多款集团项目从零到一经验并带领实现商业化布局。
本文原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
专栏作家
三爷,微信公众号:三爷茶馆,人人都是产品经理专栏作家,2019年年度作者。《中台产品经理宝典》作者,原万达高级产品、MBA特约讲师、独立创业者,现叮咚买菜B端产品线负责人,拥有多款集团项目从零到一经验并带领实现商业化布局。
本文原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议。
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
有中台实际案例吗
三爷,你好,看完你的文章感受颇多,看完后有一些疑问,在“误区3:兼职的中台建设团队”中,提到的商品服务中台关于字段的问题,单从数据考虑, 如果说商品数据的相似度80%以上,我理解的也确实是通过必填和选填来做区分最好,因为这样开发效率高。还是说应该在设计的初期,就将使用角色区分开来,通过选择不同的角色,去显示相关的数据输入,以数据角色为主体将角色中原本就不应该展示的数据去掉,从而来提高操作效率?
感觉是中台不会某个业务线100%的需求,只抽通用的部分