中台翻车纪实：员工转岗被裁，资源全浪费（上）
极客时间编辑部
讲述：丁婵大小：7.69M时长：05:36
你好，欢迎收听极客视点。
日前，数据产品 & BI 资深总监松子（李博源）在 InfoQ 分享了一个四年前的中台建设案例。作为国内早期进行中台实践的大厂，在 2016 年的短视频风口下投入大几百人组建业务中台，结果短短十几个月之后就被叫停，团队成员有人转岗，有人被裁，最后只保留了数据中台团队。希望这个中台翻车案例能让你看到失败经验，避免踩同样的坑。
为什么要进行中台化建设？
简而言之，组建业务中台的目标，是要完成一款短视频客户端的产研与推广，在推进过程中还需对内容进行相应配套，而内容生态是个非常复杂的单元。为了组建这个新的业务单元，经过大 HRG 的前后协调，从南方某事业群调来了产品线、审核线、技术线、BD 线、审核线；从北京某集团调来了产品线、算法线、审核线、BD 线等。
平台化解决了技术平台的问题，但每个单元业务的执行都要跨多个领域来完成，是一个比较复杂的生态协作问题。
此外，集团在内容生态方面较为薄弱，需要一个业务中台来支撑内容生态。但是好几个事业群都有类似的生态业务在运作，各自的生态又分别为各自客户端业务提供内容生产审核，账户体系、内容评定标准、奖励机制各不相同。具体到数据体系上，其中两个子集团或成为事业群的业务方都有各自的数据体系，造成的问题是：
账号没有打通，账号评估与分级体系不统一；
内容评定标准不统一、品类不统一、标签体系不统一、奖励机制各不相同；
不同子公司在审核的投入上都很巨大；
不同 BD 采购流程不通，或签约多个主体；
内容生态所涉及到的账户数据、图文、视频、粉丝互动、内容库、消费数据、内容审核等较容易整合并服务化。
从集团角度来看，这就形成了烟囱式的建设。每一个烟囱的能力直接决定了业务的发展速度与业务创新的成本，但实际上业务的快速更新与创新更需要像乐高一样的体系去快速搭建。结合内容生态这个业务来看，根基与出发点是偏业务型的中台建设。
缓慢的中台建设与快速变化的业务需求
偏业务型中台在建设中是有难题的，首先要服务好下游的内部业务方，其次还要完成对外部业务方的支撑，最后还需要完成自身建设。这个中台是要将原本分散在不同端内容生态上的业务逻辑进行重构，并整合类似的业务模块。自身建设含有产品建设、内部运营工具建设、对用户的运营工具建设，在资源有限的情况下，如何能做到这几个方向的平衡呢？
业务中台所服务的业务对象有几个，需要分别完成对端的业务支撑，对自身创作者与内容的支撑，完成自身建设。
在端的业务支撑上，需要服务好各个内容信息流下发端。比如一个集团内不同业务线各种含有信息流、内容频道的 App；再比如需要能够承接住端诉求的对应产品体系，由端去做各种垂直品类差异化运营所需的内容，商业化统一结算、类目统一化、标签统一化、评级体系统一化、端需求差异化与统一采购等，每一块的内容都会影响到端的下发以及端 App 本身指标以及内容消费指标。
在对创作者与内容的支撑上，需要完成自身的业务建设。把内容创作引入进来后需要从业务自身角度去维持这个账号的可持续创作能力和优质内容创作能力，不管是从产品角度提供创作辅导、创作工具赋能、数据工具分析，还是从运营手段提供奖励机制、激励机制、分润机制，都是出于“让这个创作者活着”的目的。
在自身建设上，除了上述产品外，还有标准化、组件化建设，以及支撑内部运营的工具建设。分别可以从内容引入、内容管理、内容消费以及数据体系建设上进行细化。
以上这些方向如果按照中台的角度来做拆解，还是需要一定节奏去建设与实施的。否则“产研运”再牛，也不能短时间内建设出来一套支撑各业务方的业务中台来。
中台的建设过程中节奏是最要命的。这其中有一个矛盾点，就是业务线在发展中是快速变化的，快速变化必然就会渴望得到各种资源支持。但是中台大部分是在缓慢建设与推进的，两者之间会产生诉求与承接能力不匹配的问题。如何做好平衡，就涉及到先做什么、后做什么的问题。
除了上述问题以外，导致这次中台建设失败的因素还包括团队、KPI 等问题，这将在下文继续分享，欢迎持续关注。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论