大厂中台翻车实录：失败告终，数百人团队说撤就撤

2016年，短视频热浪开始袭来，笔者所在集团也提出了入局短视频赛道，做业务中台化的决策。然而在组建数百人团队、投入大量资源后，这项中台建设项目还是以失败告终。

继《鬼话连篇数据中台（一）：透过中台看数据中台》后，这是该系列的第二篇，从另一个角度看来也算非常特别的一篇，这是一个不是那么成功的业务中台建设实际案例的回顾，改为独立篇章。

春节前与上个 BU 的成员聚会时还是回顾这个中台建设的话题，就是“开局一条狗，装备全凭抖”，这块业务算很好的业务中台建设的切入点，但是经过很多人努力去建设，结局就是说撤就被撤了，是什么问题引起的？在整个文章中会逐渐稍微展开分享一下的。

另外自己以往写文章都是偏数据产品、BI 类，第一次来写业务类的文章，对于自己来讲也算是一个小的挑战。

ps：关于各种中台的定义还是一如既往的不给出定义，因为定义都已经满天飞，大家要系统化了解中台这个方向还是去看其他文章。

01 背景与起因

大约在 2016 年的秋天，集团某业务线的产品负责人说：“有一个很有意思创业项目，具体的是关于 是关于短视频的创业项目，考虑加入吗？” 经过更详细的了解后得知：这位产品线负责人与事业群头头一起勾兑提到“短视频赛道”可以做，努力一次，可能在短视频赛道上做出蛮不错的成绩的。一群人多次合计了下都觉得这个事情蛮靠谱的，在当时是个不错的新方向选择，但是呢需要构建一个新独立的 BU 来运作这个事情。

由此由一个多国部队组成的新业务线就宣誓成立，提出的口 是 4 月份上线，7 月份 DAU 3 千万，潜台词是我们财大气粗，不需要考虑成本与投入，完成业务目标与占领行业就可以。

新组建这个 BU，主要任务是要完成一款传奇的短视频客户端的产研与推广，在实际的执行过程中，受到历史包袱问题以至于这款客户端在很长的一段时间内一直承载长视频、动画的播放，需要在很短时间内向短视频信息流转变，结果就是这款 APP 的 90% 长视频消费用户受到打扰逐步在流失。

各自的数据体系，其中两个子集团或成为事业群的业务都是各自的数据体系，尤其是在帐户数据、图文、视频、粉丝互动、内容库的、消费数据上都在那时没有打通，还有蛮多其它的的问题像平台众多、模式相近、同质化严重、变现不足等，但是聚焦几个比较突出的问题分别是：

账 体系问题，账 没有打通、账 评估与分级体系不统一；

内容评定标准不统一、品类不统一、标签体系不统一、奖励机制各自执行；

采购问题，跟 BD 采购流程不同，或签约多个主体；

现在回顾一下，这块是很明显需要进行业务中台化，因为可以围绕统一的一点接入多点分发的方式来支撑各端的业务，做好内容生态供给。在建设过程中这个中台是需要拉通各种信息、标准化建设、帐户、数据等一系列的打通，就是业务流、内容流、分发流、数据流、商业流的这些相近业务中台化。

但是，结局为什么会做的比较偏向了呢？这个中台化业务，最终不声不响地逐步淡出了大家的视野，而没有在内容生态这条线上形成有着强力壁垒的根据地。这又是为什么呢？

02 中台的考核目标是什么

在当时冬天，某次内容生态业务会时老板问小班委一个问题：

期间，对于这个问题，自己经过思考后认为的答案是（这段是整理来自我当时的回答笔记）。

企业在业务不同阶段业务会疯狂的扩张的，那在业务疯狂扩张的过程中由于各个 BU 业务自我闭环，导致大厂内部存在着很多重复造轮子的工作。

怎么理解重复造轮子呢，就是独立 BU 做了一款 APP A 、独立 BU B 做了一款 APP B，这里面做了一个功能相似功能，但是这在功能在内部是的必要性没有那么强，如果继续搞存在着人力成本的浪费。这个时候我们会通过一个公共抽象出来的业务模块去独立处理。（ps 现在看来肤浅多了）结合内容生态这个业务来看，有几个点想法分别是：

1. 这块内容业务的根基与出发点定位的是中台性质，是偏业务型的中台建设

这些都是内容生态的基础功能，通过对于平台的这些基础功能再加上较为复杂的抽象业务和业务逻辑来进行控制的，这些都是在业务内做了较为深层次的固化，从集团角度来看形成了烟筒式的建设。每一个烟筒的能力直接决定了业务的发展速度与业务创新的成本，业务的快速更新与创新需要一个像乐高一样的体系去快速搭建。

比如我是一个厨子我要做披萨，全程我可以自己做，但是非常麻烦，我有三个方案：

方案一，别人提供厨房、炉子、煤气，我使用这些基础设施，用自己的披萨皮来烤披萨。

方案二，有人提供披萨饼皮，只要把自己的配料洒在饼皮上，让别人帮忙烤出来就行了。也就是说，我要做的就是设计披萨的味道（海鲜披萨或者鸡肉披萨），别人提供平台服务，让我把自己的设计实现。

方案三，别人直接做好了披萨，不用我自己的介入，到手的就是一个成品。我只需要做的就是把它卖出去，最多再包装一下，印上自己的 Logo。

这个烤批萨随着生态的复杂度、业务的复杂度、系统复杂度的升级，平台化解决了技术平台的问题，每个单元业务的执行都要跨多个领域来完成。

比如说淘宝的宝贝，商品发布规则、交易规则、营销规则散落在各个系统，进行一个动作时没有一个人能说清楚全局，做一个需求结果要评估 1 个月，开发几天、测试几天，效率太低，这已经不是一个流程能够解决的，是一个比较复杂的生态协作问题。

2. 作为业务中台承担的 KPI 是什么？

一个业务型中台如何考核呢？考核指标该如何定义呢？

从衡量这个生态该如何定义指标呢？比如从规模角度、品质角度、活跃、消费、互动、收益在这六个维度定义十几个指标吗？

从月日均活跃账户数量、月日均账户生产文章数量，再加上账 内容在端的月日均播放量以及阅读量，账 内容在端的月日均播放量以及阅读量超过十万的内容数量 ?

无论从那个角度看来，都略感不太合适，这些指标都受到端的影响，没有一个是完全因为这个中台业务能完全起到作用的指标。

但是呢，每一块都是要成本，生产出来的内容下发有问题，在不同端消费很差，或许是引出的供需不匹配的问题，因为这个供需不匹配到底是算法的问题还是内容质量问题、还是标签的问题、还是在下发侧的 C 端画像刻画问题，这是一个链条的问题，因为都同属于业务都要承担 KPI，自然这个 KPI 将会打架。

3. 中台拉通各种标准各大金主业务线是否认这个玩意，也就是说这个业务板块如何有话语权，还是做背后的默默无闻的奉献者

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

从内容生态来看在子公司、放眼集团，个人认为是一个很好的切入点，集团是某体系的巨无霸，在内容生态这块一般，是需要一个具有支撑内容生态的一个业务中台来支撑的。

所以在自己眼里这个内容生态中台：

内容生产与管理的组合、也是内容生态一堆规则的执行者，这些能力是面向组件化的设计与面向点的集成。

是一个集成化的解决方案，有平台、数据、接口规范、系统规范，包含解决信息呈现，快速匹配，解决供需撮合机制。

也是业务支撑、能力应用、能力运营、能力管理、协调能力、配置管理的体现。

其余的剩下的应该就是与各个业务团队进行共建的了。

回到烤披萨的这个小案例，从简单的烤批萨到中台级烤批萨，会忽略一个很重要的因素，那就是随着烤批萨生态的复杂度、烤披萨上下游产业的复杂度、工艺复杂度不断的提升，自己的流程、工艺、边界都在发生变化，随设时间的沉淀，中台的建设也会要逐步的去迎合与能够快速去支撑这些变化，否则中台的建设将会影响到未来业务的变化。

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

偏业务型中台在建设中是有自己的难题的，首先要服务好下游的内部业务方，其次要完成对自己中台的所服务的外部业务对象的支撑、最后还需要完成自身的建设。

这个中台是要将原有分在不同端的内容生态这块的业务逻辑重构，并整合类似的业务模块。

自身建设含有产品建设、内部运营工具建设，对用户的运营工具建设，在这个资源是有限的情况下，如何能做到这几个方向的平衡呢？

1. 端的业务支撑

需要服务好各个内容信息流下发端，比如一个集团内不同业务线的各种含有信息流、内容频道的 APP ，在这里大概只列举几条：

能够承接住端诉求的对应的产品体系；

适合短的内容采购等一系列的问题；

端自己去做各种垂直品类的差异化运营所需的内容；

商业化统一结算。

每一块的内容都会影响到端的下发以及端 APP 本身指标以及内容消费指标。如果没有这些内容出口端，内容中到底做什么呢， 所以有句话必须得服务好！！！

2. 服务好用户

具体来讲从产品角度会有：

比如内容覆盖、账 拓展；

入驻体验、信息合规；

内容同步工具、生产工具、促产工具；

内容分发分析、收益结算等；

商业化统一结算。

从自身业务的账户角度、内容角度分别又是两部分内容：

帐户级别：账 信息结构化与归一化，质量、品类、试运营、账 体系、星级评价体系、管控方面等。

内容级别：内容识别、价值认定、管控等方面。

如果在从运营角度分类还有：

账 的分层运营、头部账 的差异化运营、优质与高潜账 挖掘；

激励体制、收益策略等；

活动与培训体系；

区等。

如果分解得更完全还会有很多内容与工作去做：

自身建设：

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

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

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

写到这里偶尔提一下，现在市面上对于中台的所有文章千变一律的都是在讲中台的概念，讲中台蓝图，有没有经过是实践验证呢？如果按照那些去实施成功的概率到底有多大？ 每一步该怎么走。

04 失败的原因

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

回顾那一年的外部大环境，在内容这个领域很多公司是快速崛起与布局，为什么当时的这个中台会在一形式大好的情况下，失去了这个阵地呢。在规划中要进行中台化的关键要素团队都拆解到了，为什么还会黯然失色了呢？

前面我们从矛盾论的角度、因果角度、建设角度，对这个业务做了不同角度复盘。在今天，总结来看还有几方面：

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

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

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

中台建设是一种思考方式，但是在过程因为各有所需，变成了脚痛医脚、头痛医头的传统估计的一条线到头的建设，多条线交织成一个复杂 状比较难以拆解的问题（表象看是一个资源问题），具体中台达成什么样子，承担哪些沉淀， 还是要慢慢迭代的。

流程的问题，太多过长。

其它。

05 为什么保留了数据团队

为了码字而写的一段，有人问我为什么数据团队是基本保留了下来，总结下来有这么几点：

独特特性就适合中台化；

主动建设、跑在业务前面，盘与梳并行，强化核心资产，沉淀应用模式、核心业务模型和纵向深化场景；

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

展开详细讲一下：

在数据的建设阶段除了考虑基础的要整合原有不同端的数据外，还在中台业务还没有摸清自己打法时要主动一些，带着个责任“让业务看的更加清晰”去做的，在短时间内快速的去建立衡量业务的全链路的关键指标漏斗体系外，还需要做异动分析，全局 ROI 、局部 ROI 、类 ROI 还有动态 ROI 都是要去主动建设。

在数据体系建设上，我们需要思考整合不同端外，还需要按照分析的主题域去做整合。 但是还必须站在中台角度去思考我数据该如何平躺能够提供中台能力的服务，还有建设进度如何。

比如在数据标准上从整合角度、管理角度、消费角度如何做到闭环，分别从数据安全、数据标准上做了什么，从策略角度的制定、推进、信息畅通，从接入标准、开发标准上也做了大量工作。

在数据对业务的模型抽象上，从分析的角度供求关系角度抽取了大量的高阶模型与可落地的分析模型。

偏流量方面的分析模型，一堆指标如何关联行程一个可视化的分析图，每一实体中有哪些分析要素，

内容创作的这个复杂分析模型。

在内容创作与信息流商业化分析模型。

拿着这些模型，一个业务、分析比较很清晰的就能看到自己看什么、上下游该研究谁，该如何分析。

比如从数据指标与分析角度快速去建立关键指标到拆解分析指标的体系，比如下面样例，周活做拆解，会拆解为周发文不同频次的监控。

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

当然了，我自身还是 BI 与数据产品领域，那段时间的做业务与数据价值积累，也让自己在内容生态与信息流这个业务领域变的很熟悉，学会了很多有意思分析思维。

06 小结

一个业务型中台尤其是背着考核指标的中台该如何去建设，节奏是什么、中台的几个显著特性优先建设哪一个呢都是需要待考虑的问题，而且最难解决的一点就是关于对中台的认知问题、人的因素问题、流程因素、问题都是需要去重点思考的，当然了还有一点该选择什么关键指标最为考核指标与观察指标都是势在必行的。

相关阅读

鬼话连篇数据中台（一）：透过中台看数据中台

题图来自 Pexels，基于 CC0 协议