中台,简单说!

公司有中台很久了,突然想写一篇文章聊聊笔者自身对中台的定义和看法,也供大家讨论讨论。

一、什么是中台

现在有很多关于中台的解释或定义,也把中台划分了几个种类,分别是:

  • 业务中台:提供一些复用服务,如用户中心、订单管理等
  • 数据中台:提供数据分析能力,解决数据分析相关的难题等
  • 应用中台:提供一些基础应用,如消息推送,短信发送等
  • 算法中台:提供一些算法能力,如证件识别算法
  • 研发中台:提供一些部分技术和后台支撑,例如代码测试、代码发布等系统
  • 技术中台:提供一些基础设施资源、例如数据存储、计算、网络等,是较为底层的技术。
  • 组织中台:提供或协调一些组织资源,例如资源调度、资源协调、风险把控等

每个种类都有大厂(阿里巴巴、腾讯、京东、平安等)图例来解释他们的中台的样子,但是这样对于产品新人或想要了解中台的人比较困难,因为大厂的图例都是依据各自企业的业务、架构等形态来画的,带有明显的企业烙印,如果不了解企业业务或其组织架构就比较难理解。

笔者从自己经历中总结了中台,并给出了一个定义:

1
中台是一个能共享、共用、连接、服务企业各能力的“中间商”。

二、中台能做什么

既然是“中间商”,且起到支撑作用,那应该具有共享、共用、连接、服务的属性。因此从这四个方面阐述中台的作用。

1.共享

企业不同业务或不同部门可以通过中台来共享各类资源和数据,例如业务数据、用户数据等。数据数据后,小到一个功能的开发需求的分析,大到企业战略的制定,都可以从中台获取数据并分析,获取决策的数据支撑。

目前最广泛共享的是用户相关的数据。企业一般以手机号作为唯一标识来确认用户,一个手机号一个用户,其他的设备号等都是辅助来确认是不是一个用户。企业各业务的用户数据最终在中台都根据手机号来存储。

2.共用

企业可以通过中台来共用各类基础设施和服务,例如登录服务、消息推送服务、短信发送服务、代码发布服务务、运维服务、iT支持服务等。

通过消息推送案例阐述下共用:

一般小型企业可能就一个业务,因此做一个推送服务根据自身业务和用户群体来做消息推送的功能,或者直接用第三方的消息推送服务,这样做的好处是节省开发成本和时间,同时由于业务不大,不需要太多复杂的功能,如果用第三方也能满足需求。 但是对于大中型企业,业务多且分散于不同部门(事业线或事业部),各方可能都有开发团队,那如果每个团队都自己做一套消息推送服务就会特别浪费企业资源,但是由一方开发后其他方使用又不能满足其他方的个性化需求,另外成本如果核算等也是一个问题,因此放到一个独立的团队来开发消息推送基础功能,各业务团队在基础功能上开发个性化功能,那就大大减少资源的浪费,同时也能让业务减少在这方面的时间消耗,放更多的精力的在业务发展上。

再详细说下消息推送服务基础服务和个性化的区别,以订单发货提醒为例,中台提供各类消息推送通道(push、短信、邮件等)以及是否要消息推送和通知的判断,由业务方自行去对接需要消息推送的通道,有的业务只要push,有的业务短信也需要。对接后再满足条件时候进行消息推送即可。

以上说明就可以看出中台的演变过程(随着企业发展必然会有一些功能可以集中到某一个团队开发)以及中台的作用。

3.连接

中台可以作为是一个通道,可以打通不同业务、部门、后台之间的业务壁垒,方便企业整合业务,方便不同业务之间的互相赋能,实现1+1>2的增长。

试想下此场景:当A业务发现某用户群的特征非常符合B业务的目标用户,想进行业务合作的尝试,如果业务之间各自独立,没有打通的地方,那就需要新对接(例如联合登录),等待上线可能是1-2周后,热头劲都过来,而且上线运营后数据也不方便统计和分析;如果业务之间有打通(共用了登录模块,共享了数据),那就能立即上线运营,同时能多维度的统计和分析数据。

4.服务

既然是“中间商”,笔者认为就应该有“服务意识”,支撑好前台业务发展,为各业务发展提供有利帮助。

三、要不要做中台

关于要不要做中台,很多文章都进行了说明,本文不再细聊,而是给出几个关键词供产品新人或想要了解中台的同学进行思考和讨论:

  1. 业务数量:业务数量和团队数量两者之间相辅相成,业务少,团队少,开发相同功能的机率也小。
  2. 企业规模:企业规模越大,业务越多,开发团队越多,共用的功能也就会越多;反之则少。
  3. 营收:如果要设立中台,就需要供养单独的团队,且这个团队不直接贡献营收;
  4. 发展瓶颈:如业务发展到一定规模,发现业务之间有壁垒,打通后可产生更多效益,是不是应该考虑设立中台进行数据等的打通呢?