GMTC全球大前端技术大会(北京站)门票9折特惠截至本周五,点击立减¥480 了解详情
写点什么

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

2020 年 4 月 17 日

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

这是一个四年前的中台建设案例。作为国内早期进行中台实践的大厂,最终也没有逃开失败的结局。


正值 2016 年“直播元年”,在短视频风口上,国内某大集团开始调动各业务线的精兵强将,组建新的业务单元,以“业务中台”的形式集合公司力量,想要迅速占领行业高地。


公司对这个“业务中台”的投入也是实实在在的:产研七十人左右,运营六十多人,数据团队几十人,采购团队四十多人,审核团队几百人…前后涉及大几百人。


然而在短短十几个月之后,这个“业务中台”就宣布被撤,团队成员有人转岗,有人被裁,最后只保留了数据中台团队。


这个直播项目最终不声不响地逐步淡出了大家的视野,并没有激起短视频内容生态上任何水花。


四年后,在“中台”风盛行的今天,这个项目的重要参与成员,从不同角度对这个项目进行了“复盘”。


起因:想在风口上进军短视频

大约在 2016 年的秋天,某产品线负责人对我说:“有一个关于短视频的创业项目,很有意思,要不要考虑加入?” 那年被称为”直播元年“,短视频平台逐渐兴起,并以不可阻挡之势发展着。集团想在”短视频赛道”发力,觉得努力一下可能会做出不错的成绩。大家也都觉得这个事情很靠谱,这在当时是个不错的方向,只不过需要新建一个独立 BU 来运作。


这个新业务单元的目标,是要完成一款传奇短视频客户端的产研与推广。此外在推进过程中还需对内容进行相应配套——而内容生态恰好是个更加复杂的单元,要涉及到很复杂的人力调度。为了组建这个新的业务单元,经过大 HRG 的前后协调,从不同事业群选择了一些小伙伴加入进来:从南方某事业群调来了产品线、审核线、技术线、BD 线、审核线;从北京某集团调来了产品线、算法线、审核线、BD 线…


人员调齐后,经过多次碰撞,公司召开了一个声势浩大的启动大会,希望大家尽快完成目标并占领行业高地。


过程中前前后后投入了大几百人的资源,但这个中台项目并没有很好地推进下去,仅仅经过十几个月,业务单元就被分拆了。项目也不声不响地淡出大家的视野,并没有为企业的内容生态形成强力壁垒。这是为什么呢?结合当时的笔记和现在的思考,我总结出了一些关键点。


为什么要进行中台化建设?

从当时的条件与思考来看,平台化解决了技术平台的问题,但是每个单元业务的执行都要跨多个领域来完成,复杂度会随之升级。比如说淘宝的宝贝,商品发布规则、交易规则、营销规则散落在各个系统中,进行一个动作时,无法做到靠一个人就能说清楚全局。结果就是一个需求要评估一个月,开发需要几天,测试又需要几天,这已经不是一个流程能够解决的,是一个比较复杂的生态协作问题


  • “大中台”的概念就是从较为复杂的协作生态上来纵向地从服务链路来做资源整合,技术中台注重能力沉淀与整合,业务中台注重链路、效率、成本、流程优化。业务中台在我的眼里变成了规则引擎执行者与定制化服务输出方,规则的输出通过对数据的控制来进行。

  • 大企业的很多业务在最初都会经历疯狂的扩张过程,在这个过程中由于各个 BU 自我闭环,导致大厂内部存在着很多重复造轮子的工作。比如同样在内容领域,独立 BU A 做了一款 App ,独立 BU B 做了一款 App,都有很多详细功能。但是这些功能在内部的必要性又没有那么强,继续做存在着人力成本的浪费。这个时候我们会通过一个抽象出来的公共业务模块去单独处理。


虽然这个集团是某体系当中的巨无霸,但是在内容生态这块其实还是较为薄弱的,需要一个业务中台来支撑内容生态。当时的情况是:好几个事业群都有类似的生态业务在运作。比如南方某事业群有自己的图文内容生态,北方某事业群有自己的视频内容生态,各自的生态又分别为各自客户端业务提供内容生产审核,帐户体系、内容评定标准、奖励机制各不相同。具体到数据体系上,其中两个子集团或成为事业群的业务方都有各自的数据体系,造成的问题是:


  • 账号没有打通,账号评估与分级体系不统一;

  • 内容评定标准不统一、品类不统一、标签体系不统一、奖励机制各不相同;

  • 审核问题,但凡做内容必须有审核,不同子公司在审核的投入上都很巨大;

  • 采购问题,不同 BD 采购流程不通,或签约多个主体;

  • 内容生态所涉及到的帐户数据、图文、视频、粉丝互动、内容库、消费数据、内容审核等较容易整合并服务化。



从集团角度来看,这就形成了烟囱式的建设。每一个烟囱的能力直接决定了业务的发展速度与业务创新的成本,但实际上业务的快速更新与创新更需要像乐高一样的体系去快速搭建。结合内容生态这个业务来看,根基与出发点是偏业务型的中台建设。实际上我们可以通过一点接入、多点分发的方式来支撑各端业务,做好内容生态供给。在建设过程中对信息、标准、帐户、数据做一系列打通,将业务流、内容流、分发流、数据流、商业流这些相近的单元进行业务中台化。


未决的问题:中台的 KPI 谁来背?

几个月后,领导提出了一个问题:“这个业务中台的考核目标是什么?”


这块业务是做内容生态、创作者生态,但是当时只有创作、内容生产、内容审核、内容库等等从内容维度的奖励,没有内容的出口。面向 C 端的出口都在其他 BU,那这个中台业务如何进行考核?考核指标该如何制定?


  • 要从规模、品质、活跃、消费、互动、收益这六个维度定义十几个指标吗?

  • 要从月/日均活跃账户数量、月/日均账户生产文章数量,再加上账号内容在端的月/日均播放量、阅读量等等维度进行考核吗?


无论从哪个角度来看,都感觉不太合适。这些指标都受到端的影响,没有一个指标仅仅跟中台业务本身相关联。比如有的人提到既然是围绕创作者的生态,那就只看创作者、内容生产就好了,但实际上每一部分都有成本,如果生产出来的内容在不同端效果很差,到底是用户画像的问题,还是算法的问题,还是内容质量的问题?各个业务都要承担 KPI,自然就会打架。


另外,以前各端的创作者奖励相当于成本,现在因为都归到中台来承担了,从财务角度只看到成本,那收益和利润该如何算呢?因为出口在各端,不同端的信息流中商业化收入会算到各端业务侧,在内容商业化探索上,也没有想象得那么容易。


缓慢的中台建设与快速变化的业务需求

偏业务型中台在建设中是有自己难题的,首先要服务好下游的内部业务方,其次还要完成对外部业务方的支撑,最后还需要完成自身建设。这个中台是要将原本分散在不同端内容生态上的业务逻辑进行重构,并整合类似的业务模块。自身建设含有产品建设、内部运营工具建设、对用户的运营工具建设,在资源有限的情况下,如何能做到这几个方向的平衡呢?


业务中台所服务的业务对象有几个,分别完成对端的业务支撑,对自身创作者与内容的支撑,完成自身建设。


在端的业务支撑上,需要服务好各个内容信息流下发端。比如一个集团内不同业务线的各种含有信息流、内容频道的 App;再比如需要能够承接住端诉求的对应产品体系,端自己去做各种垂直品类的差异化运营所需的内容,商业化统一结算、类目统一化、标签统一化、评级体系统一化、端需求差异化与统一采购…每一块的内容都会影响到端的下发以及端 App 本身指标以及内容消费指标。


在对创作者与内容的支撑上,需要完成自身的业务建设。 把内容创作引入进来后需要从业务自身角度去维持这个账号的可持续创作能力和优质内容创作能力,不管是从产品角度提供创作辅导、创作工具赋能、数据工具分析,还是从运营手段提供奖励机制、激励机制、分润机制,都是出于“让这个创作者活着”的目的。



在自身建设上,除了上述产品外,还有标准化、组件化建设,以及支撑内部运营的工具建设。分别可以从内容引入、内容管理、内容消费以及数据体系建设上进行细化。



以上这些方向如果按照中台的角度来做拆解,还是需要一定节奏去建设与实施的。否则“产研运”再牛,也不能短时间内建设出来一套支撑各业务方的业务中台来。


中台的建设过程中节奏是最要命的。这其中有一个矛盾点,就是业务线在发展中是快速变化的,快速变化必然就会渴望得到各种资源支持但是中台大部分是在缓慢建设与推进,两者之间会产生诉求与承接能力不匹配问题。这块如何做好平衡,就涉及到先做什么、后做什么的问题。


现在市面上对于中台的所有文章千变一律都是在讲概念,讲蓝图,有没有经过实践验证呢?成功的概率到底有多大、 每一步该怎么走?


避免不了的“失败”结局

十几个月后,因为项目建设不尽人意,我们的项目组被拆。回顾那一年的外部大环境,在这个领域很多公司都是快速崛起与布局,而我们这个中台项目却在当时形势一片大好的情况下失败了。这是为什么呢?


前面我们从矛盾论的角度、因果角度、建设角度做了不同维度的复盘。今天回过头再看,还有几方面原因:


  • 数据团队需要在几个业务团队中寻找一个平衡点。

  • 人的因素——想法太多,都想驱动这个中台。

  • 人员能力问题:做中台的难度与做普通产品相比,有量级的差异。能力不足,真的搬不动这块石头,还砸了所有人的脚。

  • 中台建设是一种思考方式,但是在过程中因为各有所需,变成了“脚痛医脚、头痛医头”的传统方式。原本想象的是一条线到头的建设,实际上是多条线交织成一个复杂网状,成为了比较难以拆解的问题(表象看是一个资源问题)。具体中台该达成什么目标,承担哪些职能, 还是需要慢慢沉淀、迭代。

  • 流程的问题,太多太长。

  • 其它。


资源问题我相信是所有管理层最关心的问题了。在这个项目中,包含了七十左右的产研、六十多位运营、几十位数据人员、四十多位采购 BD,以及大概几百人的审核团队。如果算上流动,前后大概有好几百人。


“业务中台”项目被拆之后,产品转岗了,大部分运营被裁了(只留了小部分运营), 但保留了较为完整的数据团队。因为数据业务的独特性适合中台化,且是“主动建设”,所以一直跑在业务前面,并强化了核心资产、应用模式、核心业务模型和纵向场景。但我们这个切入点很好的业务单元,经过很多人的努力,结局却是说撤就被撤了,非常值得回味…


原文链接


鬼话连篇数据中台(二):中台翻车的一次复盘与总结


作者介绍


松子(李博源),自由撰稿人,数据产品 & BI 资深总监。个人公众号:songzi2016。


2020 年 4 月 17 日 17:1632225

评论 7 条评论

发布
用户头像
这一篇是经过小编改变的简化版,更详细分析版本https://www.infoq.cn/article/3tbJZ8aS5pYdWYX5bBfg
2020 年 12 月 30 日 22:32
回复
用户头像
一看就没做过中台
2020 年 12 月 30 日 15:52
回复
用户头像
文章看似写了很多,感觉啥用也没有,没有一个清晰的目标,仅仅是记账
2020 年 05 月 01 日 23:58
回复
用户头像
感觉这篇文章就是在尝试回答你的问题。
中台建设前必须想清楚的四个问题
https://time.geekbang.org/column/article/140068
2020 年 04 月 21 日 14:30
回复
用户头像
关于KPI的问题,中台本身可以是服务化的,对其他业务模块收费,独立结算。业务模块就会衡量使用这个中台是不是合算。

2020 年 04 月 20 日 09:53
回复
用户头像
员工被裁啊
2020 年 04 月 19 日 13:33
回复
用户头像
必须实现抽象的业务描述语言,才能把业务和实现分离,达到中台化目标
2020 年 04 月 18 日 19:53
回复
没有更多了
发现更多内容

对话声网 Agora 首席科学家钟声 :声网的未来规划和人才建议

小诚信驿站

采访 调查采访能力考核

《采访彩食鲜 CTO 乔新亮:IT 团队从 100 到 10000 的管理心得》(采访提纲)

程序员历小冰

调查采访能力考核

浅谈JVM和垃圾回收

SH的全栈笔记

Java JVM JVM虚拟机原理 垃圾回收算法

为什么我愿意持续做这样一件看似没有价值的事情

leoay

坚持 持续写作 长期价值

奇绩创坛2021秋季创业营开始报名

奇绩创坛

NIST发布酒店业网络安全指南

Machine Gun

网络安全 信息安全 WEB安全

精通比特币:为什么它对自由、财务和未来至关重要(上篇)

CECBC区块链专委会

比特币

翻译:《实用的Python编程》09_03_Distribution

codists

Python

使用Agora SDK开发React Native视频通话App

声网Agora

RTC React Native 声网 RTE

如何从零开始学Python:(3)划重点:使用IDLE创建列表时需要注意的地方

广之巅

Python 四月日更

python 变量作用域和列表

若尘

变量 Python编程 作用域

简单了解InnoDB底层原理

SH的全栈笔记

MySQL 数据库 innodb

融合趋势下基于 Flink Kylin Hudi 湖仓一体的大数据生态体系

Apache Flink

flink

为什么微服务一定要有 API 网关?

xcbeyond

微服务 api 网关 4月日更

关于数字人民币、加密货币,央行前行长周小川、副行长李波博鳌论坛发声

CECBC区块链专委会

数字货币

深入理解Java虚拟机-HotSpot

华章IT

Java JVM 虚拟机

百度大脑3月新品推荐:EasyDL视频目标追踪全新发布

百度大脑

百度大脑 EasyDL

直击灵魂!阿里技术官甩出内部爆款性能优化实战笔记,理论实战一键搞定!

Java王路飞

Java spring 程序员 架构 面试

Python 爬虫实战(一) 爬取自如网租房信息

U+2647

python 爬虫 四月日更

朱嘉明:算力产业正面临着一个十年的长周期

CECBC区块链专委会

数字经济

架构实战营 模块2 课后作业

༺NPE༻

【AI全栈二】视频流多目标多类别无延迟高精度高召回目标追踪

cv君

人工智能 AI 目标检测 视频跟踪 综述

Lombok初始使用及遇到的问题

风翱

lombok 4月日更

推进智慧城市建设 博睿数据亮相长三角城市数字化转型高峰论坛

博睿数据

数字化转型高峰论坛

IPFS矿机投资靠谱吗?IPFS挖矿可靠吗?

投资矿机v:IPFS1234

IPFS矿机投资靠谱吗 IPFS挖矿可靠吗

斗智亦斗棋,零售云市场的“楚河汉界”突围赛

脑极体

一种提升流媒体服务DSS的IO并发性能方案

Changing Lin

签约计划 4月日更

【提纲】专访融云CTO杨攀 | 技术型人才的自我修炼

Python测试开发

调查采访能力考核

浅谈在探索数分之路上的“数据思维”论述

小飞象@木木自由

数据分析 数据分析体系 数据思维 数据分析方法论

面试4轮字节Java研发岗,最终拿下Offer(原题复盘)

码农之家

编程 程序员 互联网 面试 字节

Excelize 2.4.0 正式版发布, 新支持 152 项公式函数

xuri

GitHub Excel 开源项目 Go 语言 Excelize

中台翻车纪实:一年叫停,员工转岗被裁,资源全浪费-InfoQ