聊透中台,到底什么是中台
大约从去年年底开始,中台的概念开始被广泛讨论。
但与此同时,关于中台究竟是什么,却是众说纷纭。引用王健老师在《当我们谈中台时,我们在谈些什么| 白话中台战略》一文中提到的关于中台的一些理解,就能看出一些端倪。
在有些人眼里:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。
在有些人眼里:中台就是微服务业务平台,像最常见的什么用户中心,订单中心,各种微服务集散地,人们都叫它“业务中台”。
在有些人眼里:中台应该是组织的事情,在释放潜能:类似于企业内部资源调度中心和内部创新孵化组织,人们叫它“组织中台”。
这些理解都对,但也都有不够准确或不够完整的部分。中台,作为一个还在被定义当中的概念,正处在一个大家都有感觉,但又难以被定义的状态。而且可预见的是,这种相对模糊的状态可能还要维持相当长的一段时间。
与此同时,在查阅了大量资料、并与京东等大厂的中台相关负责人沟通后,我们发现,目前行业内对于中台讨论的视角还是多偏于战略或组织架构层面,而中台更多是因为公司业务在发展到某一阶段时,遇到瓶颈与障碍后,为解决实际问题而提出的解决方案。
虽然基于战略的角度去看,确实能够让大家视野开阔,从更高维度理解中台。但战略是基于实际业务而制定的,如果撇开业务去空谈,就如同空中楼阁,还是无法了解中台到底是什么。
接下来,我们将会站在实际业务的角度,探讨一下中台的“前世今生”,以及如果想要成为一个中台产品经理,你应该具备哪些能力。
01 为什么需要中台?
市面上讲到中台,一定会提到两个例子,一个是13年马云参观supercell,然后在15年确定了阿里的中台战略;另一个是华为的中台战略转型,也就是那句著名的“让听得见炮火的人指挥战斗”。
这似乎会给大家一个错觉,似乎中台是一种自上而下的战略选择。老板觉得中台好,所以要搭建中台。
不过,现实情况,或许与绝大多数人想象不太一样,中台的产生,并非完全是自顶向下的战略设计,也并非是为了追随某种行业风口,而是随着公司业务高速发展、组织不断膨胀的过程中暴露的种种问题需要被解决。而这时,中台的概念恰好对应了这个问题,所以大家接受了中台。
过去几年中,借着移动互联网的红利,许多公司都高速发展,进行大规模业务拓展,业务拓展的速度足够快,对公司自然是好事,但是随着而来的问题就是,公司内部出现了大量的重复建设和资源浪费的现象。
阿里的共享服务部发展历程就是如此。
公司刚开始只有淘宝,后来意识到B2C模式的业务也会是电商领域重要的组成部门,所以出现了天猫,随着天猫的不断发展,逐渐独立成一个部门,但是这两套都包含订单、商品、库存、价格、仓储、物流等基本业务系统。这两个系统互相独立,各自运行。
等到10年左右,阿里开始上线1688、聚划算等业务的时候发现,这些业务针对的领域虽然各不相同,但是他需要用到的系统功能也高度类似,主要也是订单、商品、库存、价格、仓储、物流等系统。如果这些新业务的系统也都要全部重新开发一遍,这无疑是很大的资源浪费。明明既有的系统调整一下就可以满足新业务的需求,为什么还要继续开发新系统呐?
在这个大的背景之下,阿里内部将共享服务部的职权不断提升,统一将各个业务业务部门重复使用,反复建设的功能和系统统一规划和管理。
![](https://pic1.zhimg.com/80/v2-7440efc0ee5430b973f66e6bdb5d8f2f_720w.jpg?source=1940ef5c)
其实,很多公司的中台部门,或者平台业务部门的出现都有类似的背景和情况。
比如说,滴滴在15年末开始启动自己的中台战略,这与滴滴当时的业务发展阶段也是相关的。
2015 年末,滴滴在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。
这些业务虽然会有一些差别,但是核心系统和流程都是类似的。如果各自独立开发,也会出现各种各样的问题。
比如说,开发成本过高,滴滴旗下的每个业务,其实都是可以单独支撑起一家公司的,如果每个业务都独立做到极致,那么开发成本和人力成本就会非常巨大,而如果为了控制成本,就把系统的建设放缓,则意味着,无论是核心系统本身的质量,还是对外的用户体验都不太好。
在这样的背景下,滴滴也开始考虑将诸多业务,以及各个城市的系统统一规划,统一建设,提升服务前台的能力。
其实,刚刚我们提到的,以及许多正在实践中台业务的公司,都有类似的问题,这些问题,大约会是两类——
一类是,许多业务需求或功能需求高度类似、通用化程度很高,但是由于没有专门的团队负责规划和开发,大量的系统重复开发、重复建设,导致复用性低、效率低、产研资源浪费、用户体验不统一。
另一类是,早期业务发展过程中,为了解决一些当下的业务问题,垂直的、个性化的业务逻辑与基础系统耦合太深,由于没有平台性质的规划,横向系统之间、上下游系统之间的交叉逻辑也非常多,这样导致在新业务、新市场的拓展过程中,系统没法直接复用,甚至没法快速迭代。
这两类问题,在软件开发领域,有专门的名称,叫做“重复造轮子”和“烟囱式架构”。这两类问题本质上是企业在发展过程当中,为了解决当下的业务问题,快速上线了很多功能,而欠下了许多技术债,当企业进入成熟期之后,发现这些问题的存在,严重影响了企业的运行效率和运营成本。
如何能够机制化,产品化地解决这些问题,能够更好地通过产品的形式,将企业内部具有很强的通用性的数据、功能、产品甚至经验进行统一规划和开发,进而更好地帮助前台业务部门更多地关注业务,提高业务运营效率,进而提升企业竞争力,是企业开发中台的基本出发点。
现阶段,大多数提出中台战略或是建设大中台的公司,大多都有类似的困境。业务高速发展多年,许多问题积重难返或者大量在解决“重复造轮子”的问题,中台这个概念,很多情况下是因为契合了大公司业务的发展的情况,而被大家广泛认可。
02 中台能解决什么问题?
前面的内容,我们大致介绍了中台要解决的问题。这给我们一种感觉是,中台是只有大公司才能做的事情,因为毕竟只有大公司在会有这种多条业务线,需要大量通用功能的场景,也只有只有大公司有能力拿出如此大的资源打造个中台。
现实情况也如我们所说,很多公司的中台业务,实际业务发展到一定阶段,进入一个瓶颈之后,为了能够应对接下来的问题,才一点一点从内部开始推动解决之前的问题。
但这其实只是中台建设的一个层面。
中台作为一种产品设计思路,或者系统架构思路,并不受限于公司的规模,理论上讲,任何一家即将或者正在面临业务高速增长的状态时,都很值得利用和借鉴中台的思路,将目前业务当中大量可复用的功能和场景进行梳理,为业务的高速增长做好准备。
这在中小公司当中,是有现实意义的。
对于很多中小公司,当他们走出生存困境,进入到高速发展阶段时,会遇到很多的问题,但大概率会遇到的一个问题是,过往的业务模型,产品能力很有可能没法完全承接住大规模用户增长带来的压力。
而当你具体到每个用户的时候,你又能发现,他们遇到的问题你之前都遇到过,只不过,因为一下来的太多,你没法像过去一样提供达预期,甚至超预期的服务时,对方就会产生不满。
这也是为什么许多公司会生于拉新,死于留存的一个原因。
很多公司在这个阶段的选择都是为了临时解决一个问题,快速上线一个功能,也不是不可以,只不过,很有可能你的解决方案会不断带来新的问题,最后陷入到功能太过复杂,以至于积重难返的地步。
所以,在有可能的情况下,公司将一些大概率长期有价值的功能,专门模块化,进行开发和优化,确保即使业务规模进一步扩大,也能够满足业务需求。甚至,随着能力或方法论的不断优化,甚至有可能某一天成为整个行业的方法论。
这个过程,就很像是在高速飞行过程中修飞机一样。一方面,机翼已经千疮百孔,摇摇欲坠,另一方面,发动机还在运转,你还能往前飞,但你知道,如果再进入到下一场战斗,你不见得还能确保飞机不会坠落,所以,必须抢在下一次战斗前把飞机修好。
随着业务的发展,你对飞机的要求,也不仅仅是修好,可能会希望,能够提前预防一些问题。或者,知道你的飞机哪里战斗力最强,就把哪里做到最好。或许,就能够回避之后的一些问题。
这或许是中台这个概念,对于中小公司内部产品规划的一个启发。
当然,需要提示的一点是,对于中小公司而言,中台的理念不见得是单独拉几十人搭建一个中台产研团队,可以将一些关键流程先行标准化,把一些反复出现的场景当中的解决方案进行沉淀,部分需要产品化的功能先行产品化,可能对于一家业务刚刚开始起步的公司来说,就已经很重要了。
03 中台产品经理的挑战
之前的内容,我们其实花了很大的篇幅来讨论,为什么会有中台,中台解决怎样的问题,以及中台适用怎样的场景。
但是,具体到业务场景当中,中台产品经理又在做什么事情,解决怎样的问题?如果想要成为一名优秀的中台产品经理,又会遇到怎样的困难和挑战?
我们采访了一些大公司的中台部门之后,会发现,中台产品经理面对很多挑战,其中,最主要要是最困难的挑战,主要集中在这样两个方面。
一方面,是思维的差异。
很多产品经理并不是从一开始就从事中台相关的事宜,也不是一开始就有中台这样的定位。更多情况下,他们是从前台业务部门,或者以业务为导向的产研部门转型到中台产研部门。
这时,其实要面临很大的思维方式、做事方法的转变。
在业务部门或者以业务为导向的产研部门,最核心的目的就是达成业务目标,要求你速度足够快、功能高效地解决当下的业务问题,当前业务发展的效率是最关键的。
至于说,这个功能将来有没有可能适用于别的场景,有没有可能解决别的问题,这个问题实在是没那么重要。
但是,对于中台不能如此。
对于中台产品经理来说,必须思考的问题是,这个功能在现在或者将来能满足多少业务场景?如果将来有新的业务出现,是不是能够复用?或者说,需要做多大的调整才可以复用?甚至于,这个功能有没有可能对外输出,提供SaaS化的服务。
这些问题,是中台部门需要思考的问题。这是思维上的差异。
另一方面,是环境的变化。
当你在业务部门的时候,响应业务是相对轻松的。但是,在中台部门,响应多个业务,就没有那么轻松了。
就拿需求调研为例。在业务部门或以业务为导向的产研部门的时候,你只要和对接的业务人员沟通清楚需求就OK了,毕竟,你只要了解这一个或对应的多个部门的业务需求即可,业务目标相对比较明确。
但是,当你需要响应多个业务部门的时候,就没有那么容易了。
你会发现,同样一个需求,A部门的流程和B部门流程完全不同,或者,流程是相似的,但到具体细节的时候,却有很大差异。
更可怕的是,同样一个问题,由于业务的发展阶段不同,对于问题的态度也全然不同:有的部门业务已经非常成熟,自己流程也很清晰,所以不太希望你来调整他们现有的流程;但是,有的部门还处于探索期,还没有遇到你提出的问题,可能压根就不理你。这时,对于中台产品经理的挑战就非常大。
他们可能会将大量的精力耗散于不同部门之间的沟通协调,反复对同一个需求进行确认,很长时间没有明显突破。这个时候,就要求中台产品经理有很强的沟通、协调和协作能力。
并且,因为他们接下来要做的解决方案,是要服务于多个业务。这个时候,需要中台产品经理有很强的逻辑思考能力,看到不同需求之间的共性需求,并提炼出一个产品化的解决方案。
甚至于,对于一些尚未遇到这个问题的业务部门,可能还要帮他们前置地思考解决方案。
这又很要求产品经理的逻辑思考和抽象思考能力。
既需要沟通协作的软技能,又需要逻辑抽象的硬思考,这可能才是中台产品经理最有挑战的地方。
虽然有挑战,但是也不见得没有方法。对于中台产品经理来说,刚刚我们提到的内容,也只是帮助中台产品经理,对于中台产品这个岗位所要面临的挑战和工作,能够有一些初步框架性的理解。
但是,在实际业务场景当中要解决的很多复杂问题,受限于篇幅,我们还没有详细讨论。
对于中台产品而言,他们的能力要求其实跨越非常大。一方面,需要极强的逻辑思维和战略分析能力,能够看到业务当中的关键流程,理解业务接下来的发展方向,并将其转化为产品功能,与研发一起实现。另一方面,又需要极强的沟通和交流能力,能够在与多个业务线,需求、背景、想法各不相同的相关方一起,推动完成相关功能的实现。
这背后,是技术,也是艺术。
某种意义上,能够掌握掌握这两种似乎有些对立思维,并能够灵活运用,可能距离成为一个优秀的中台产品经理,就不太远了。