中台的困境​及破局思考

前台,平台,中台的定义&区别

没有对错,只有选择

前些年,阿里比较强调中台的建设,希望大力投入资源去建设中台,以便能够高效解决众多不同业务的共性,底层的效率问题。这两年不怎么提这个概念了,因为很多时候大家也会比较担心中台可能会带来更多的沟通成本,或者是担心中台不太能适应业务定制化的场景需要额外的开发代价和成本。

业务前台

一般情况下,我们认为业务前台就是具体针对业务的产研。这样的团队对最终的业务指标负责,比如说商业化的收入,大搜索/推荐的流量,增长的日活等。

业务前台很多时候会快速的针对业务的特点去做定制,他们会为了探索更好的模式,快速的进行尝试,甚至不断地调整方向,以最快的速度以及最好的投入产出比去推进项目。

平台

平台一般是解决某个部门的共性问题所建立的团队,他们会去解决BU内部相似的问题,以便产出能够在BU内部为多个业务所使用,其目标解决BU级别的共性问题,提升BU的整体效率。例如某个应用的UGC可能涉及到评论, 或者其他用户反馈, 此时审核平台都需要统一支持审核需求。

中台

中台则是解决大型企业各个部门甚至是不同子公司的共性问题而设立的团队,他们的目标是对更底层的基础设施进行抽象,以期望这些设施能够在各个子公司都能够进行复用,提升公司OR集团的整体效率。

图:业务前台,平台,中台区别。一般平台+某个使用该平台较多的业务前台会由同一人来负责,这样的组织叫做L形组织,如红框部分。

各自解决的问题

前台业务,就是解决具体的业务问题,他是高度定制化的,需要快速进行模式的尝试。如果需要,整体的业务模式都可能很快进行调整。它解决的是模式问题,所以其特点就是高度定制,快速试错。

而平台和中台更多的解决的更大范围的是效率问题,他们的出发点是希望在进行模式探索的时候,能够将平台或者中台当做乐高或者积木组件,能够快速的去组建新的探索模式。

但很多时候,事与愿违:中台做了之后,前台业务不愿意用,经常出现的情况有两种:

  1. 要么就是前台业务,觉得中台根本就不理解业务,很多功能都不支持,如果需要在中台中去加定制的逻辑,中台不愿意或者需要的开发成本比较高,开发周期比较长,业务前台觉得还不如自己去开发来的快,效果更好。

  2. 另外一种就是前台业务,在初期的时候觉得中台能解决一切问题,等在使用的时候发现不是那么回事,就会觉得中台做的比较烂,以后就再也不用了。

导致以上两种情况的原因,是因为中台不是万能的,它所解决的问题是有一个边界的,不属于这个边界之类的问题状态是不能很好支撑的,但是业务方并不太理解。所以中台以及平台一定要定义好自己的边界,有所为,有所不为,并且需要让业务方尽早知道这一点。

中台注定难做

绩效评估体系的‘锅’

以我的经验,中台注定非常难做。搜推广这样的前台业务,或者大数据平台dmp这样的平台系统我都做过。这一点我体会比较深一些。最直接的感受就是:平台OR中台,真心难做!

原因很简单:公司是非常强调投入产出比的组织,很多时候,对于产出的衡量,更偏向于业务指标。因为业务指标更客观,更容易和公司的目标绑定。但中台最终对公司业务目标是间接关系,产出内容就不太容易客观的衡量。这就导致从绩效评估体系的角度就天然重视前台业务。

前台业务比较像球场上的一个前锋,而平台中台更像是一个后卫。我们可以清晰的衡量一个前锋进了多少球,但我们很难衡量一个后卫对进球的贡献;同时,从另一个角度,我们经常听说某某明星球员转会会费高达XX亿,这样的明星绝对是一个前锋,很少听说一个后卫有天价的转会费用。

例如,数据平台产生的数据用到业务当中,结合业务的策略OR算法上线,如果运气比较好:上线效果比较好,有可能业务会认为是自己算法做得比较好,并不一定会认为说数据有多牛逼;但反过来,如果策略效果不好,很有可能会认为是数据质量比较差,这是经常发生的情况。

所以经常发生的情况,就是要么别人不用中台,要么用了之后觉得中台不好用。

所以中台很难做,也很难成功。平台则比中台容易做那么一丢丢,该有的困难也都有。

目标不一样,不相为谋

业务前台和中台的目标,一般情况下也大相径庭,这就导致两种团队一般都互相不待见。可以认为,业务前台有自己非常清晰,并且压力很重的业务指标,这是他们的KPI,必须要完成。

而中台则会从集团或者公司的角度去考虑整体的效率最大化,整体的效率最大化并不代表单独各自业务的效率最大化,也许业务前台自己搞更快并且效果更好,或者他们单独搞会有更高更快的投入产出比,能更快的达成自己的KPI。这就会导致前台业务没有动力去用中台,或者支持中台。

什么时候可以做中台

那什么时候可以做中台呢?我看到的比较令人沮丧的现象是:没有什么时候是适合做中台的,直接上来就定位是做中台的团队都死掉了。

那是不是没有成功的中台呢?也不是,也有一些成功的状态存在,很多都是先应用于某个特定的场景去认真打磨,并且相对是比较定制化的,刚才这个业务当中用的比较好,在逐渐将可能的通用组件抽象出来,支撑其他的业务。比如阿里的语雀。相当于中台都是在不知不觉中做成的。

平台成功的关键:L形组织

一般成功的中台都是首先依附于某一个比较重要,比较大的业务,先把这个业务支撑好,并且可能存在比较多的定制证明效果和收益,之后再视情况,将通用的部分抽出来作为平台或中台,只有这样的方式才可能成功。

而很多时候,中台的负责人也需要是某个业务的负责人,这样中台才有优化的目标和动力, 有很多公司强调的L形组织,一竖就是具体的被支撑的业务,一横则是平台,这个平台先支持一竖,之后再进行应用的拓展。这样的组织形式也简称一横一纵。

什么是好的平台?

以我的经验来看,平台首先要在一个比较重要核心业务中体现出来它的价值,这个时候只能说这个中台做的还行,而如果这个中台能够支撑两个及其以上的不同核心业务,并能拿到收益,这个平台就算是成功了,而且在其他的类似业务当中去推进的时候就会很迅速,很容易,因为之前的两个成功案例都可以拿出来证明中台的有效性以及更容易让用户理解中台功能的边界。

就类似于公司销售去售卖自己公司产品的时候, 如果有一两个成功的样板,则客户会更容易理解产品, 以及更容易说服客户。

这里也有一个有意思的现象:做平台或者中台的同学, 无论是产品还是技术, 都需要承担起一部分销售和售后支持的工作。

只有变化才是不变的

那是不是所有的公司都不需要做中台呢?

这是一个比较有意思的问题:当阿里不再强调中台的时候,我看腾讯却组建了比较多的中台团队,腾讯之前一向是一个个独立的小团队,作为业务前台进行快速独立的尝试闻名的,这其中包含了非常多的重复造轮子的工作。

是不是觉得比较搞笑?

这也是个哲学问题,包括公司的组织形式,你是以游击队非正规军的模式作战,还是以集团正规军的模式去进行组织,是没有统一的标准答案的,需要在不同的情况,不同的阶段,不同的大环境之下去进行调整和选择的。

没有对错,只有选择

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注