查看原文
其他

我看中台

刘言飞语 刘言飞语 2020-02-26

中台最近又成了比较热的话题,结合我对中台的认知,试图跟你回答下这些问题:1.互联网公司的中台到底是什么?2.中台有哪些类型?3.中台有哪些困境?4.互联网公司中台的现状 5.关于中台的建议



1

中台化据说是马云参观 Supercell 后在阿里巴巴提出的,要求“大中台、小前台”的模式。目标也很明确:小前台距离一线更近,便于快速决策、敏捷行动;剩下的交给支撑部门做。

 

Supercell 的中台化究竟是什么呢?

 

首先,Supercell 一直倡导“Less is more”的组织文化,整体公司员工数量保持在极度精简的水平,在去年底也没有超过 400 人,而 2018 年营业利润大约是 5.1 亿欧元(39 亿人民币)。在这样精英文化的氛围下,CEO Ilkka Paananen 力求员工不要被流程和管理机制束缚,给每个小团队足够的决策权。而且由于资源稀缺,每个小团队可以更加聚焦手中的资源,选择做最重要的事情。(Supercell 中的 cell 也是表达这个意思。)

 

(Supercell 的中台理念示意图)


这是组织中台化。 


组织中台化对游戏的价值显而易见。游戏本来是创意行业,把决策权给业务前台、中台结构放权、CEO 主要来完成大家资源的支撑和整合,是合理的。


其次,据说 Supercell 是一定程度上实现了技术中台化,即前台业务团队可以利用现有的各种技术模块,快速敏捷地试错。(这点待求证,毕竟游戏的复杂度很高,不知能中台化到什么程度。)

 

这是技术中台化


技术中台化的核心目的是成本。成本可以从两个维度看,一个是资源浪费方面的成本,即公司有三四个业务线都在做同样的事情了,那技术上实现能不能融合可复用的部分?另一个则是时间成本,即新业务能够足够敏捷地去使用既有的技术模块去做探索。


实际上,实现中台化的环境是相当苛刻的。连 Paananen 自己都说,他认为Supercell 的经验不是对所有公司都有效,有它自己的特殊性。他觉得 Supercell 的每个员工,都是能在外面成立公司自己当老板的,因此这种精英文化和中台化在公司得以保持。

 

 

2

反观国内的互联网公司,这几年都陆续提到了、或者在践行中台化。我了解到的许多中小企业,也在追随大公司的脚步,搭建中台能力。

 

不过中台化显然不是万能的提效方案,也不是适用于各种公司各种领域的。夸张点说,很多人口中所说的中台化,每个字儿看起来都一样,但压根都不是一件事情

 

除了刚刚提到了组织中台和技术中台,还存在数据中台和业务中台。我们按照难易程度倒序逐一论述。

 

其一,技术中台(基础服务中台)。

 

技术中台指的是将大家都通用的技术能力聚合到一起,由同一个团队负责,防止重复造轮子,是最容易实现的中台化。核心价值是降成本,刚刚提到了。

 

各公司的基础服务,以账号体系为代表,都已经是中台化的了。淘宝、天猫、飞猪等业务之间,快车、专车、顺风车等业务之间,美团外卖、酒旅、团购之间,必然要做打通。

 

其二,数据中台。

 

顾名思义,表面上数据中台是各业务的数据能够打通。不过在实际运用中,又分为多种。

 

基本的数据采集、数据仓库建立和数据分析能力的共享,其实是数据技术中台的范畴,是将做数据相关工作的技术团队整合,来支持各业务。核心价值是降成本。

 

各业务线的数据打通、数据共享和协同运用,则属于业务中台的范畴,是以业务目标牵头的(比如阿里的88VIP会员的前提就是用户数据打通)。

 

有时这两者是耦合在一起的,既有技术能力的共享,又有业务支撑。不过在国内数据分析的认知还比较浅(认为数据都是拉报表的),后者往往效果不佳。前者在不少互联网公司倒是确实落地了。


在有些公司,数据中台只是很粗浅地把数据整合到一起,并没有解决任何问题,或者让整合产生什么价值。阿里云中间件架构总监谢纯良曾经说过,许多公司的数据中台就是把数据加工成“大屏”,搞一个展示用的“大屏”就以为实现了中台。意思就是,数据中台如果不为业务服务,或者说为业务中台服务,那就没有价值。

 

其三,业务中台。

 

既然技术模块可以抽象出来复用,那业务模块是不是也可以?在淘宝时用过的营销策略,能不能直接挪到飞猪用?专车的策略能不能直接给快车用?这就是业务中台的概念。


很显然的,由于业务存在更高复杂度,因此难度更大。

 

业务中台是各大公司追求的最终效果:前台业务敏捷推进,后台业务稳固支持。不过真实情况往往事与愿违,难尽人意,真正做到业务中台运转良好的,很少见。

 

其四,组织中台。

 

组织中台刚刚讲 Supercell 时提到了,是嫁接在前三种中台基础上,再加入“放权机制”的中台结构。


阿里的中台业务支撑能力可以支持新的电商相关业务快速创新;字节跳动把增长能力中台化,头条的增长部队可以快速投入到抖音中去,甚至可以投入到海外各个国家各个产品;美团有试错小团队,会利用既有的技术能力、用户流量等资源快速试错,找到新的方向,包括外卖在内都是这样来的。


这些都是组织中台的体现。组织中台与其说是中台能力,倒不如说是内部创业的空间。它的核心价值应该在于“旧业务能否帮到新业务”,很考验组织能力。有的公司内部创业,封闭隔离,跟这个公司自己投资了个新团队,没啥区别。

 


3

中台的难点有几个关键矛盾:

  • 中台团队离业务远

  • 中台需求的优先级难排序

 

先说中台团队离业务远。

 

为什么中台化的难度是:技术-数据-业务-组织?因为越往后,越需要业务团队的介入,越要有业务认知才能做到中台。而中台团队,天然就是离业务远的。

 

各公司跟中台团队的协作,都存在很大的低效问题,一线的前台业务团队,要反复与中台沟通,才能讲清楚业务需求的背景,在大公司,跨部门协作都会徒增成本。另外对于中台业务团队来说,长期离业务很远,没有成长性,在判断需求时也不准确,很难获得前台业务团队的信任。

 

久而久之,就变成了中台团队纯支撑、被动接需求的状态,成为“鸡肋中台”。更大的问题在于,中台团队的价值就是整合需求、抽象能力的,在对用户和业务不够了解的前提下,这块就会做得特别吃力。如果是多个前台业务的需求有了冲突,中台团队未必能做好协调,多方要反复沟通扯皮。

 

针对这个问题,通常有两个解决方案:

 

第一,中台职责直接由最大业务方来担任。

 

像贝壳的中台模块,就是由二手房先行推进的;而大多数通用的乘客司机产品流程,在滴滴也都是快车先发起的。最大的业务方离业务足够近,能自己决策判断大多数需求,更加高效。

 

这样以来,就从“硬找一个中台团队来收集大家需求”变成了“老大哥发挥余热,把自己的能力共享出来”,具体要怎么用,仍然是各自团队来决策和执行。

 

第二,让中台团队做业务闭环。

 

这只适用于少部分情况,即中台业务本身可以自闭环。常见的比如各公司的账号体系(包括注册登录)、阿里的支付和订单流程、滴滴的地图和导航。这些业务与其它业务的关联度不大,可以解耦,可以自己完成从用户到业务的认知和决策,那就可以独立出来自己做,其它业务希望使用的时候,对接通用接口就可以了。

 

而大多数中台团队负责的业务不太容易自闭环。比如滴滴不同业务线的接单流程,就很难抽象出来让中台团队直接闭环自己做;或者像阿里不同业务线的商品部分、订单流程部分和支付部分可以抽象,但用户体验方面,不同前台业务差异太大,则很难抽象。

 

再说,中台需求的优先级难排序。

 

很现实的问题是,中台团队会面临无数的需求,要处理优先级问题。怎样处理,很难有标准。

 

你可以说,用业务指标即可,比如哪个前台业务方的需求能创造更大业务价值。这当然可以,但这有悖于前面提到的“中台化是为了前台业务更高效,尤其辅助创新业务”的作用。因为很简单,你的创新业务没几个用户的时候,就永远得不到中台支持,那还做个毛线。

 

结果往往就是,若严格按照量化收益来排序,小业务和创新业务的个性化需求永远排不上,最后就只能自己完成,又是在“去中台化”了。

 

这个问题暂时没有什么太好的解法。跟每个公司的人聊,几乎都会碰到,小业务或者边缘业务对中台业务部门的诟病,认为不够支持,需求都被堵死。除了自己做,只能寄希望于,自己需要的,中台部门恰好已经提供了。

 

 

4

各公司的中台化现状,基于我的访谈和了解,可以做一个简单的描述。

 

腾讯从大半年前提出中台化之后,已经由 TEG 牵头陆续实现底层技术的一些整合,以账户体系为主。数据的整合也在做了,不过应该更多类似数据仓库的建设这种底层整合。从业务中台来说,搜索、广告、信息流都在陆续整合,基本是钦定某家的方式,分别是浏览器、广点通、FCC(信息流与内容社区业务线) 牵头做。微信仍然是飞地,不受任何中台化影响,自给自足。

 

腾讯的难度应该是最大的,因为众所周知,山头林立,遍地赛马。一些新业务,无数团队都在做,而且是完全“去中台化”的方式在做。我有个朋友所在的团队,对内部严格保密地做新项目,怕被发现成了靶子,对外反倒是没有那么保密,很是魔幻。

 

阿里的业务中台化应当是做得最好的。网传的这张示意图较好地描述了阿里中台架构的情况。



中间的“业务平台”中,各中心(Center)承担自闭环的业务,是我前文中提到的对“离业务远”的第二个解决方案。由于电商环境下各环节的用户需求和体验都有较高相似度,且阿里的组织文化建设得足够高效,在阿里的中台部门不会存在太多“中台鸡肋”的情况,能够深入参与业务。

 

比如,阿里的用户中心( User Center )就是统一账户管理部门,负责用户画像、用户标签等一系列基础能力建设,同时也会负责前端体验(比如“我的淘宝”)。商品中心(Item Center)会负责商品详情页,既有后端的信息逻辑,也有前端的体验。不管是“我的淘宝”还是“商品详情”,中台部门都是提供一套完整的基础能力,由淘宝、天猫以及各种前台业务部门自己去个性化使用(可以简单理解成换皮)。

 

贝壳的中台刚刚提到了,是由二手部门牵头做,把二手和其他业务都面临的业务模块(房源管理、CRM系统、经纪人带看/跟进能力、合同签约等)抽象出来,提供给大家使用。中台部门没有单独拿出来,而是跟业务部门强耦合。

 

滴滴除了基础服务会有平台产品部和一些支持部门(基础信息、风控等),快车的不少业务模块就是实际上的中台(例如提供接单流程、营销工具)。网约车虽是核心业务,但与其它业务相对解耦(单车、代驾、顺风车、国际化、车服),对外中台化的模块不多,主要还是一些基础服务。

 

字节跳动的中台以用户增长(投放拉新为主)、技术(算法为主)和商业化(广告为主)三个部门为主,近期新增了直播中台。很明显的,这几块业务在各个方向业务上复用性比较强,业务独立性也足够。这样就能与阿里的中台类似,可以深入业务的同时保持中台的独立。头条的组织化极其看中效率,因此统一支持,效果俱佳。举个例子,用户增长团队是手握预算、以bp身份介入许多业务、有许多产品功能上的决策权的,这跟有的公司的用户增长其实就是市场投放而已,截然不同。

 

美团很少提到自己的中台战略或者能力。内部在搭建的主要也是基础服务中台和数据中台。对于业务中台来说,美团业务模式之间的差异性导致不太容易抽象(团购-外卖-酒旅-物流-新零售-单车-网约车)。不过美团的组织建设对新业务非常友好,每个新业务都是得到了老业务支持(当然前提是数据本身做得足够好)后生长出来的,无论是底层技术业务的支持,还是人力资源的支持,又或者是流量的支持。因此可以说美团具备一定的组织中台文化。

 

京东提出中台化后,也搭建了技术中台、数据中台,以及部分业务中台(比如搜索中台、营销中台)。从结构上跟阿里比较类似,不过相对低效一些,业务方与中台的协作不够顺畅,会出现前文提到的各种问题。

 

整体来说,各司的中台存在几个特征:

 

  • 基础服务(账号、支付、安全、风控等)能力的中台,相对都很完备。技术中台基本多多少少都在搭建了,渗透业务的程度各有不同。

  • 数据中台也大都在搭建中,不过还是侧重提供“采集、存储、取数”的能力,虽说降低了研发成本,但跨部门协作通常会增加协作成本;这样的中台,距离能提供业务决策洞察的数据中台,恐怕还比较远。真正一般数据分析的工作都是各业务内自己闭环,自己完成。

  • 业务中台视情况而定,有的公司业务之间天然不适合做中台化。对于适合的公司,最常见的方式,一种是难以解耦闭环的情况,就采用“老大哥”式的方法,由核心业务来提供支持,比如贝壳、滴滴;另一种是中台有机会掌握自己的业务,比如阿里的电商中台、字节跳动的增长中台。


 

最后,对于中台化的问题,说几个总结。

 

  • 中台化还是要遵循“具体问题,具体分析”的道理。没有放之四海而皆准的中台化策略,有的业务就不需要中台化,有的中台化反而会适得其反。有的公司压根就只有一个业务,或者有几个业务都没有重复造轮子的现象,那硬去学习阿里的中台,一定是东施效颦了。看阿里谢纯良的采访,包括我跟阿里的朋友了解到的,阿里的中台也是“痛极思变”的过程,在跌跌撞撞中成长的,不是老板一声令下就全部到位的。

  • 中台化的目标都是降低成本,分两种:第一,现存业务之间重复造的轮子合并,降低成本;第二,为某些业务尤其新业务提供能力,可以低成本快速试错。

  • 对于有的大公司,中台化不是个技术问题,反而变成了组织问题,就是各业务线要不要接受别人提供的东西,还是我就要自己做;以及对于新业务来说,能否得到老业务既有能力的支持。

  • 对产品经理和运营来说,一定要加入可以业务自闭环的团队,不要加入纯支撑的中台团队。离业务远会很容易成为“鸡肋中台”。比如在许多公司,基础服务的中台,压根是没有产品和运营这样的业务岗的,都是技术。

 

 

希望能帮到你。

 

 

参考:企业纷纷效仿阿里建中台,到底是盲目跟风还是不做会死?






    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存