江苏龙网

  1. 首页 > 人文 > >

中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费

中台建设是一种思考方式 ， 但是在过程中因为各有所需 ， 变成了“脚痛医脚、头痛医头”的传统方式 。 原本想象的是一条线到头的建设 ， 实际上是多条线交织成一个复杂网状 ， 成为了比较难以拆解的问题（表象看是一个资源问题） 。作者丨松子（李博源）
策划|Tina
这是一个四年前的中台建设案例 。 作为国内早期进行中台实践的大厂 ， 最终也没有逃开失败的结局 。
【中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费】正值2016年“直播元年” ， 在短视频风口上 ， 国内某大集团开始调动各业务线的精兵强将 ， 组建新的业务单元 ， 以“业务中台”的形式集合公司力量 ， 想要迅速占领行业高地 。
公司对这个“业务中台”的投入也是实实在在的：产研七十人左右 ， 运营六十多人 ， 数据团队几十人 ， 采购团队四十多人 ， 审核团队几百人...前后涉及大几百人 。
然而在短短十几个月之后 ， 这个“业务中台”就宣布被撤 ， 团队成员有人转岗 ， 有人被裁 ， 最后只保留了数据中台团队 。
这个直播项目最终不声不响地逐步淡出了大家的视野 ， 并没有激起短视频内容生态上任何水花 。
四年后 ， 在“中台”风盛行的今天 ， 这个项目的重要参与成员 ， 从不同角度对这个项目进行了“复盘” 。
1
起因：想在风口上进军短视频
大约在2016年的秋天 ， 某产品线负责人对我说：“有一个关于短视频的创业项目 ， 很有意思 ， 要不要考虑加入？”那年被称为”直播元年“ ， 短视频平台逐渐兴起 ， 并以不可阻挡之势发展着 。 集团想在”短视频赛道”发力 ， 觉得努力一下可能会做出不错的成绩 。 大家也都觉得这个事情很靠谱 ， 这在当时是个不错的方向 ， 只不过需要新建一个独立BU来运作 。
这个新业务单元的目标 ， 是要完成一款传奇短视频客户端的产研与推广 。 此外在推进过程中还需对内容进行相应配套——而内容生态恰好是个更加复杂的单元 ， 要涉及到很复杂的人力调度 。 为了组建这个新的业务单元 ， 经过大HRG的前后协调 ， 从不同事业群选择了一些小伙伴加入进来：从南方某事业群调来了产品线、审核线、技术线、BD线、审核线；从北京某集团调来了产品线、算法线、审核线、BD线......
人员调齐后 ， 经过多次碰撞 ， 公司召开了一个声势浩大的启动大会 ， 希望大家尽快完成目标并占领行业高地 。
过程中前前后后投入了大几百人的资源 ， 但这个中台项目并没有很好地推进下去 ， 仅仅经过十几个月 ， 业务单元就被分拆了 。 项目也不声不响地淡出大家的视野 ， 并没有为企业的内容生态形成强力壁垒 。 这是为什么呢？结合当时的笔记和现在的思考 ， 我总结出了一些关键点 。
2
为什么要进行中台化建设？
从当时的条件与思考来看 ， 平台化解决了技术平台的问题 ， 但是每个单元业务的执行都要跨多个领域来完成 ， 复杂度会随之升级 。 比如说淘宝的宝贝 ， 商品发布规则、交易规则、营销规则散落在各个系统中 ， 进行一个动作时 ， 无法做到靠一个人就能说清楚全局 。 结果就是一个需求要评估一个月 ， 开发需要几天 ， 测试又需要几天 ， 这已经不是一个流程能够解决的 ， 是一个比较复杂的生态协作问题 。
“大中台”的概念就是从较为复杂的协作生态上来纵向地从服务链路来做资源整合 ， 技术中台注重能力沉淀与整合 ， 业务中台注重链路、效率、成本、流程优化 。 业务中台在我的眼里变成了规则引擎执行者与定制化服务输出方 ， 规则的输出通过对数据的控制来进行 。
大企业的很多业务在最初都会经历疯狂的扩张过程 ， 在这个过程中由于各个BU自我闭环 ， 导致大厂内部存在着很多重复造轮子的工作 。 比如同样在内容领域 ， 独立BUA做了一款App ， 独立BUB做了一款App ， 都有很多详细功能 。 但是这些功能在内部的必要性又没有那么强 ， 继续做存在着人力成本的浪费 。 这个时候我们会通过一个抽象出来的公共业务模块去单独处理 。
虽然这个集团是某体系当中的巨无霸 ， 但是在内容生态这块其实还是较为薄弱的 ， 需要一个业务中台来支撑内容生态 。 当时的情况是：好几个事业群都有类似的生态业务在运作 。 比如南方某事业群有自己的图文内容生态 ， 北方某事业群有自己的视频内容生态 ， 各自的生态又分别为各自客户端业务提供内容生产审核 ， 帐户体系、内容评定标准、奖励机制各不相同 。 具体到数据体系上 ， 其中两个子集团或成为事业群的业务方都有各自的数据体系 ， 造成的问题是：
账号没有打通 ， 账号评估与分级体系不统一；
内容评定标准不统一、品类不统一、标签体系不统一、奖励机制各不相同；
审核问题 ， 但凡做内容必须有审核 ， 不同子公司在审核的投入上都很巨大；
采购问题 ， 跟BD采购流程不同 ， 或签约多个主体；
内容生态所涉及到的帐户数据、图文、视频、粉丝互动、内容库、消费数据、内容审核等较容易整合并服务化 。
从集团角度来看 ， 这就形成了烟囱式的建设 。 每一个烟囱的能力直接决定了业务的发展速度与业务创新的成本 ， 但实际上业务的快速更新与创新更需要像乐高一样的体系去快速搭建 。 结合内容生态这个业务来看 ， 根基与出发点是偏业务型的中台建设 。 实际上我们可以通过一点接入、多点分发的方式来支撑各端业务 ， 做好内容生态供给 。 在建设过程中对信息、标准、帐户、数据做一系列打通 ， 将业务流、内容流、分发流、数据流、商业流这些相近的单元进行业务中台化 。
3
未决的问题：中台的KPI谁来背？
几个月后 ， 领导提出了一个问题：“这个业务中台的考核目标是什么？”
这块业务是做内容生态、创作者生态 ， 但是当时只有创作、内容生产、内容审核、内容库等等从内容维度的奖励 ， 没有内容的出口 。 面向C端的出口都在其他BU ， 那这个中台业务如何进行考核？考核指标该如何制定？
要从规模、品质、活跃、消费、互动、收益这六个维度定义十几个指标吗？
要从月/日均活跃账户数量、月/日均账户生产文章数量 ， 再加上账号内容在端的月/日均播放量、阅读量等等维度进行考核吗？
无论从哪个角度来看 ， 都感觉不太合适 。 这些指标都受到端的影响 ， 没有一个指标仅仅跟中台业务本身相关联 。 比如有的人提到既然是围绕创作者的生态 ， 那就只看创作者、内容生产就好了 ， 但实际上每一部分都有成本 ， 如果生产出来的内容在不同端效果很差 ， 到底是用户画像的问题 ， 还是算法的问题 ， 还是内容质量的问题？各个业务都要承担KPI ， 自然就会打架 。
另外 ， 以前各端的创作者奖励相当于成本 ， 现在因为都归到中台来承担了 ， 从财务角度只看到成本 ， 那收益和利润该如何算呢？因为出口在各端 ， 不同端的信息流中商业化收入会算到各端业务侧 ， 在内容商业化探索上 ， 也没有想象得那么容易 。
4
缓慢的中台建设与快速变化的业务需求
偏业务型中台在建设中是有自己难题的 ， 首先要服务好下游的内部业务方 ， 其次还要完成对外部业务方的支撑 ， 最后还需要完成自身建设 。 这个中台是要将原本分散在不同端内容生态上的业务逻辑进行重构 ， 并整合类似的业务模块 。 自身建设含有产品建设、内部运营工具建设、对用户的运营工具建设 ， 在资源有限的情况下 ， 如何能做到这几个方向的平衡呢？
业务中台所服务的业务对象有几个 ， 分别完成对端的业务支撑 ， 对自身创作者与内容的支撑 ， 完成自身建设 。
在端的业务支撑上 ， 需要服务好各个内容信息流下发端 。 比如一个集团内不同业务线的各种含有信息流、内容频道的App；再比如需要能够承接住端诉求的对应产品体系 ， 端自己去做各种垂直品类的差异化运营所需的内容 ， 商业化统一结算、类目统一化、标签统一化、评级体系统一化、端需求差异化与统一采购......每一块的内容都会影响到端的下发以及端App本身指标以及内容消费指标 。
在对创作者与内容的支撑上 ， 需要完成自身的业务建设 。 把内容创作引入进来后需要从业务自身角度去维持这个账号的可持续创作能力和优质内容创作能力 ， 不管是从产品角度提供创作辅导、创作工具赋能、数据工具分析 ， 还是从运营手段提供奖励机制、激励机制、分润机制 ， 都是出于“让这个创作者活着”的目的 。
中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费
文章图片
在自身建设上 ， 除了上述产品外 ， 还有标准化、组件化建设 ， 以及支撑内部运营的工具建设 。 分别可以从内容引入、内容管理、内容消费以及数据体系建设上进行细化 。
中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费
文章图片
以上这些方向如果按照中台的角度来做拆解 ， 还是需要一定节奏去建设与实施的 。 否则“产研运”再牛 ， 也不能短时间内建设出来一套支撑各业务方的业务中台来 。
中台的建设过程中节奏是最要命的 。 这其中有一个矛盾点 ， 就是业务线在发展中是快速变化的 ， 快速变化必然就会渴望得到各种资源支持 。 但是中台大部分是在缓慢建设与推进 ， 两者之间会产生诉求与承接能力不匹配的问题 。 这块如何做好平衡 ， 就涉及到先做什么、后做什么的问题 。
现在市面上对于中台的所有文章千变一律都是在讲概念 ， 讲蓝图 ， 有没有经过实践验证呢？成功的概率到底有多大、每一步该怎么走？
5
避免不了的“失败”结局
十几个月后 ， 因为项目建设不尽人意 ， 我们的项目组被拆 。 回顾那一年的外部大环境 ， 在这个领域很多公司都是快速崛起与布局 ， 而我们这个中台项目却在当时形势一片大好的情况下失败了 。 这是为什么呢？
前面我们从矛盾论的角度、因果角度、建设角度做了不同维度的复盘 。 今天回过头再看 ， 还有几方面原因：
数据团队需要在几个业务团队中寻找一个平衡点 。
人的因素——想法太多 ， 都想驱动这个中台 。
人员能力问题：做中台的难度与做普通产品相比 ， 有量级的差异 。 能力不足 ， 真的搬不动这块石头 ， 还砸了所有人的脚 。
中台建设是一种思考方式 ， 但是在过程中因为各有所需 ， 变成了“脚痛医脚、头痛医头”的传统方式 。 原本想象的是一条线到头的建设 ， 实际上是多条线交织成一个复杂网状 ， 成为了比较难以拆解的问题（表象看是一个资源问题） 。 具体中台该达成什么目标 ， 承担哪些职能 ， 还是需要慢慢沉淀、迭代 。
流程的问题 ， 太多太长 。
其它 。
资源问题我相信是所有管理层最关心的问题了 。 在这个项目中 ， 包含了七十左右的产研、六十多位运营、几十位数据人员、四十多位采购BD ， 以及大概几百人的审核团队 。 如果算上流动 ， 前后大概有好几百人 。
“业务中台”项目被拆之后 ， 产品转岗了 ， 大部分运营被裁了（只留了小部分运营） ， 但保留了较为完整的数据团队 。 因为数据业务的独特性适合中台化 ， 且是“主动建设” ， 所以一直跑在业务前面 ， 并强化了核心资产、应用模式、核心业务模型和纵向场景 。 但我们这个切入点很好的业务单元 ， 经过很多人的努力 ， 结局却是说撤就被撤了 ， 非常值得回味......


    推荐阅读


    上一篇：为什么说2020是科技并购好时机？

    下一篇：「国际」够直白，白宫训斥美国之音：怎么能发肯定中国抗疫的新闻！