关于中台,我的几点思考

3 评论 2504 浏览 19 收藏 10 分钟

各行业兴起的中台热潮趋于平淡,但还有公司在不停上线相关项目。本文从中台目的和潜在应用、笔者了解的国内中台情况、主导中台搭建的部门和大概率失败的情况和大家一起讨论,期望能为中台和搭建中台的小伙伴提供一定的思路。

一、中台目的和潜在应用

首先明确的是不管公司大小,大家都有构建中台的权利。有人会说小公司没有足够的资本支撑中台的运作,这个说法陷入中台要大到包含全部业务而忽视中台核心目的的处境中。

在谈中台目的和潜在应用之前,我们来重复下其起源:Supercell,一家400人的芬兰游戏公司,5-6人就能完成一款游戏开发。阿里巴巴15年参观并宣传后,中台正式登入国内互联网人的眼球而得以迅速发展。Supercell快速开发的原因在于其将美术、数值等具备模块开发内容集成在一个单元,使其具有超强的复用性,而中台则是互联网人赋予具有复用性工作模块的方法论名称。

因此,中台目的是将业务模块化以便快速应用,而具有模块化业务的部门\公司都可以开发自己的中台。但是上马中台业务前,需考量下是否有业务可以模块化,如:互联网公司H5页面开发、游戏公司建模、销售公司用户操作平台。。。

在这留个疑问:是不是中台一定要集成在一个操作系统(平台)中呢?

二、国内中台情况

在写这篇文章前笔者认为阿里和头条的中台应该是国内做的最好的公司(理由等下列举)。但是近日《阿里中台搞了3年,搞砸了?》曝出后留下个悬疑,毕竟互联网公司换帅多半是管理层对于业务不满的最直接原因。言归正传,根据国内互联网公司近几年产出,谈谈个人对当下国内中台的几种情况:

1. 阿里巴巴中台

阿里巴巴访问Supercell后,2015年在国内首先提出中台概念,当然这不是认为阿里巴巴中台做得好的原因。

不知正在浏览这篇文章的你是否记得2018年的双11,阿里系APP彼此联动导流,笔者当时在预售期下载了十几个阿里系APP拿到100多红包,相当于不到10块/活跃用户(非常划算!!!)。

引流形式简单粗暴,每个APP上均有一个H5,H5的任务分为完成本APP活跃任务和下载阿里系APP两种类型,完成相关任务后即可领取红包。数据效果可以看当时APPSTORE的排行榜,阿里系十几个APP均位列苹果商店免费榜TOP30。试想如果没有中台业务支撑,十几个APP的开发协调、数据打通需要多久才能完成呢?

这种以活动驱动搭建的中台我们可以称之为活动型中台

至于阿里换帅,或许是中台在惊艳的18年双11后未能有超越性的应用?抑或是学钉钉重新创业?或许只有当事人才能知晓了!

2. 头条系中台

字节跳动以数据驱动发家,而数据无疑是互联网公司的核心(不接受反驳),字节跳动在数据的基础上所做出的业绩在此不表。笔者表一表自己认为头条系中台做得好两个原因:

1、与阿里双11红包相媲美或更上一层楼的头条系春节红包,和阿里系APP联动相同的套路,不同的是每年春节都让大家玩得很嗨~

2、近年来经常性听到头条又发布了某个领域的APP,多闪、飞聊、aikid、goodkid …… 这么频繁的发布产品, 不管是HR、亦或是程序、营销等等,哪个环节不需要强大的控制和数据能力呢?据此是不是可以推断头条系内部有个产品中台呢?(阿里换帅有没有这个原因呢?)

而以产品驱动搭建的中台我们可以称之为产品型中台。

3. 腾讯中台

目前对于腾讯的中台介绍大部分是开放能力赋予腾讯生态的第三方,腾讯内部也成立了技术委员会来筹备中台。但通过和腾讯内部人沟通,目前中台仅局限在六个事业群里,功能也没有想象中的丰富多彩,比如微信用Excel处理数据(19年的时候),当然举例不是为说腾讯的Excel。

不知各位看官是否对前几年被热炒的微信“敏捷开发”有印象,张小龙说的是有点子就要快速去尝试,再根据结果决定停止还是继续扩大规模尝试。试想一款日活10亿的APP,哪一个快速尝试的想法不需要交互、用研、开发、策划、运营等岗位的参与呢?那我们就假设微信内部在阿里提出中台概念前已经有了一套类似中台的机制吧。

以模块化迭代驱动搭建的中台我们可以称之为模块型中台

三、到底哪个部门主导中台

说到哪个部门来主导搭建公司级的中台,有跟进过的小伙伴估计会有各种讨论出来,如产品经理、程序、数据管理、运营……反正各个岗位都想获得主导权,毕竟国情和权力都会让其投放在放大镜下。接下来我们举例来讨论下各个部门主导搭建的情形:

假设场景:只有运营面向用户,其他岗位均支持运营。产品经理服务于运营的工具搭建、数据管理服务于运营的提单数据处理,程序完成运营或产品相关需求。(为最大化展示利弊,场景完全虚构)

  • 产品经理:由于我们是负责工具功能的搭建必然由我们主导搭建,为此产品开始设计、数据管理输出数据、程序开发……轰轰烈烈搞了半年中台后运营的同学没法用。
  • 数据管理:我们拥有最全的数据理所应当主导,同时由于具有一定代码能力自己开发了一套中台……但无应用场景,然后开始重新找运营获取场景,并对中台用上了手术刀。
  • 运营:我有场景,有数据应用,任何自己在SQL里操作数据这不就是中台了嘛…….新入职的员工看的一脸懵逼。

从上面场景哪个岗位最适合来做主导呢?笔者觉得主导还是由产品经理来主导,但是其中应该首先结合运营的业务场景来做决定,开发设计过程中让运营全程跟进参与。

这里留个假设:中台的搭建必然需要复合型的人才。如前文所述,整个搭建过程中必然出现产品经理不清楚运营诉求或者要求运营给出价值体现的情况,网络上流传了千年的运营、产品经理和程序互撕的传说,在涉及0到1的中台搭建不见得会和平!

四、大概率失败的中台

简要列几个个人看法吧:

  1. 单纯为了做中台的中台,整个中台没有业务目的、没有目标导向。
  2. 将原有该做的系统包装成中台强行和中台结合,同时不断想往上增加不实用的功能。
  3. 为做中台将原有不相干的系统、权限等强行整合为一个系统,这个失败概率不一定大。但其中的风险控制不仅要重新投入大量资源(有人必然有风险),还要承担权限设计导致未来出现的风险呢。到时谁来承担呢?

小结

做中台一定有业务驱动,可模块化的业务均能设计为中台。同时大而全的中台也不要强求哦!最后祝各位中台人一切顺利吧。

 

本文由 @逗逗一世 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
2人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 请问作者大大,中台是否应该过多参与业务侧目标设定?我们现在有很明显的问题暴露出来,就是业务侧提过来的一些强势的创新需求,因为没有参考的数据以及上线之后的效果保证,中台这边领导都不建议产品去做,但是业务侧明确必须要做,小产品夹在中间很为难

    回复
    1. 1、这个要看对业务侧KPI是否能够起到影响,比如功能只是单纯提升人效而对业务价值无影响则不用参与指标
      2、业务侧的新需求其实可以用让业务侧的demo来进行验证或者业务侧提需的场景通用性怎样来判断

      回复
    2. 好嘞~谢谢~

      回复