鬼话连篇数据中台（二）：中台翻车的一次复盘与总结

翻车的一次复盘与总结"/>

鬼话连篇数据中台（二）：中台翻车的一次复盘与总结

在 InfoQ 公众号发的是浓缩版主题叫“中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费”，网站的完整体还是用老标题。文章大概在 7000 字左右，干货很多。

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

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

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

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

背景与起因

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

以为这个计划中的业务是涉及到很复杂人力调度，为了组建这个新的业务单元，经过大 HRG 的前后协调，从不同事业群选择了一些小伙伴加入了进来，分别从南方某事业群调来了产品 A 线、审核线、技术线、BD 线、审核线。从北京的某集团调来了 产品 B 线，算法线，审核线、BD 线。我自己呢做作为当时 BI 线从其他线进入了新的 BU 的。前后经历了多次碰撞以及共建后，顺利的召开了个一个声势浩大的启动大会。

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

新组建这个 BU，主要任务是要完成一款传奇的短视频客户端的产研与推广，在实际的执行过程中，受到历史包袱问题以至于这款客户端在很长的一段时间内一直承载长视频、动画的播放，需要在很短时间内向短视频信息流转变，结果就是这款 APP 的 90%长视频消费用户受到打扰逐步的在流失。产品运营各业务方就需要去考虑这个事情，结果如何在这篇文章是中不重要的，重要的是，要完善这款短视频，除了在完善必须的客户端外，还得配套有推荐引擎与内容库。在构建内容库就需要根据来源分为爬取或者是自生产，通过不断的完善内容创作生态来维持一个高质量的内容来源。如果要做内容创作生态，那更是一系列的业务链条需要建立。

在当时接触到的北方的某事业群、南方某事业群都分别有类似的生态业务在运作，南方某事业群有自己的图文内容生态，北方的某集团有自己的视频内容生态，各自的生态又分别为各自客户端业务提供内容生产审核等，帐户体系、内容评定标准、奖励机制各不相同。各自的数据体系，其中两个子集团或成为事业群的业务都是各自的数据体系，尤其是在帐户数据、图文、视频、粉丝互动、内容库的、消费数据上都在那时没有打通，还有蛮多其它的的问题像平台众多、模式相近、同质化严重、变现不足等，但是聚焦几个比较突出的问题分别是：

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

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

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

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

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

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