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

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

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

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

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

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

背景与起因

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

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

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

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

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

• 账号体系问题，账号没有打通、账号评估与分级体系不统一；
• 内容评定标准不统一、品类不统一、标签体系不统一、奖励机制各自执行；
• 审核问题，但凡做内容必须有审核，不同子公司在审核的投入上都很巨大；
• 采购问题，跟BD采购流程不同，或签约多个主体；
• 内容生态所涉及到的帐户数据、图文、视频、粉丝互动、内容库的、消费数据、内容审核等较容易整合并服务化。

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

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

中台的考核目标是什么

在当时冬天，某次内容生态业务会时老板问小班委一个问题，“这块业务是做内容生态、创作者的生态，但是咱们只有创作者、内容生产、内容审核、内容库、内容的奖励，没有内容的出口，面向C端的出口都在其他的BU。我们这个中台业务该做怎么？我们的考核目标是什么？”

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

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

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

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

在内容的生态系中，从创作者、入住、生产、下发、端消费来看，这个业务的生态来讲，中间内容生态是一层非常关键的业务平台，内容生产、内容提供、内容投放、内容创作激励、内容归一化、内容数据反馈闭环。

只要是涉及到信息流类的APP端或嵌入页面、都会涉内容这块，这些各个端的信息流的来源都是基于自己的业务平台的建立，很多业务的组成形式也是通过不同的业务平台进行串联的，在业务平台中包含了 创造者引入、管理、审核、机器识别、内容质量、内容层次化管理、优质内容管理、内容标签丰富度、资金与分润等更多的基础平台来做管理。这些呢都是内容生态的基础功能，通过对于平台的这些基础功能再加上较为复杂的抽象业务和业务逻辑来进行控制的，这些都是在业务内做了较为深层次的固化，从集团角度来看形成了烟筒式的建设。每一个烟筒的能力直接决定了业务的发展速度与业务创新的成本，业务的快速更新与创新需要一个像乐高一样的体系去快速搭建。

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

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

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

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

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

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

其次 作为业务中台承担的KPI是什么？

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

• 从衡量这个生态该如何定义指标呢？比如从规模角度、品质角度、活跃、消费、互动、收益在这六个维度定义十几个指标吗？
• 从月日均活跃账户数量、月日均账户生产文章数量，再加上账号内容在端的月日均播放量以及阅读量，账号内容在端的月日均播放量以及阅读量超过十万的内容数量 ?

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

比如有的人提到既然是围绕创作者的生态那就，那就只看创作者、内容生产就好了，但是呢，每一块都是要成本，生产出来的内容下发有问题，在不同端消费很差，或许是引出的供需不匹配的问题，因为这个供需不匹配到底是算法的问题还是内容质量问题、还是标签的问题、还是在下发侧的C端画像刻画问题，这是一个链条的问题，因为都同属于业务都要承担kpi，自然这个kpi将会打架。

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

奖励与成本的问题，当以前各端的创作者奖励机制相当于成本部分，因为都归到了中台来承担了，从财务角度只看到了成本，那收益利润该如何算呢？创造出来的直接经济价值是什么？因为出口在各端，不同端的信息流中商业化收入会算到各各自端的业务侧，在内容商业这块探索了一些但没有想象中那么好。

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

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

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

• 内容生产与管理的组合、也是内容生态一堆规则的执行者，这些能力是面向组件化的设计与面向点的集成。
• 是一个集成化的解决方案，有平台、数据、接口规范、系统规范，包含解决信息呈现，快速匹配，解决供需撮合机制。
• 也是业务支撑、能力应用、能力运营、能力管理、协调能力、配置管理的体现。
• 其余的剩下的应该就是与各个业务团队进行共建的了。

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

当时刚接触这块业务也是特别喜欢，从本质上说将会建立成为一个非常好的内容业务型中台，对于内容创作者来讲，一点接入多点分发，在这个偏业务型中台的体系建设上也是用了一些蛮有意思的方法,而且这块业务是数据体系的强力支撑、对与在生态的内的供求平衡、偏移平衡分析、时间序列供求与变迁份都是很好的参照物。

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

偏业务型中台在建设中是有自己的难题的，首先要服务好下游的内部业务方，其次要完成对自己中台的所服务的外部业务对象的支撑、最后还需要完成自身的建设。这个中台是要将原有分在不同端的内容生态这块的业务逻辑重构，并整合类似的业务模块。自身建设含有产品建设、内部运营工具建设，对用户的运营工具建设，在这个资源是有限的情况下，如何能做到这几个方向的平衡呢？业务中台所服务业务与对象来讲分别有几个角色，分别是完成对端的的业务支撑、完成对于自身创作者与内容的支撑、完成自身建设，分别展开来讲一下：

端的业务支撑：

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

• 各端对于这个中台的需求分为几方面，适合自己端的高质量、丰富度的可下发内容库，以及、符合自己端内容消费的创作者引入以及从端上来的内容审核效率等，消费数据；
• 能够承接住端诉求的对应的产品体系；
• 适合短的内容采购等一系列的问题；
• 端自己去做各种垂直品类的差异化运营所需的内容；
• 不同端对于创作者的星级评价；
• 商业化统一结算。

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

服务好用户：

这个内容中台的特点之一需要完成自身的业务建设， 那个业务对象是谁呢？可以说是一个To 内容创作者的一个业务。

把内容创作引入进来后需要从业务自身角度去维持这个账号的可持续创作能力，优质内容创作能力，不管是从产品角度提供 创作辅导、创作工具赋能、数据工具分析，还是从运营手段的奖励机制、激励机制、分润机制都是唯一的目的让这个创作者活着。

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

• 比如内容覆盖、账号拓展；
• 入驻体验、信息合规；
• 内容同步工具、生产工具、促产工具；
• 内容分发分析、收益结算等；
• 商业化统一结算。

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

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

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

• 账号的分层运营、头部账号的差异化运营、优质与高潜账号挖掘；
• 激励体制、收益策略等；
• 活动与培训体系；
• 社区等。

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

自身建设：

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

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

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

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

失败的原因

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

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

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

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

• 数据团队需要在几个业务团队中寻找一个平衡点。
• 人的因素，想法太多，都想驱动这个中台。
• 人员能力问题，做中台的难度与做普通产品相比，有量级的差异。能力不足，真的搬不动这块石头，还砸了所有人的脚。
• 中台建设是一种思考方式，但是在过程因为各有所需，变成了脚痛医脚、头痛医头的传统估计的一条线到头的建设，多条线交织成一个复杂网状比较难以拆解的问题（表象看是一个资源问题），具体中台达成什么样子，承担哪些沉淀， 还是要慢慢迭代的。
• 流程的问题，太多过长。
• 其它。

为什么保留了数据团队

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

• 独特特性就适合中台化；
• 主动建设、跑在业务前面，盘与梳并行，强化核心资产，沉淀应用模式、核心业务模型和纵向深化场景；
• 数据团队需要在几个业务团队中寻找一个平衡点。

展开详细讲一下：

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

• 在数据体系建设上，我们需要思考整合不同端外，还需要按照分析的主题域去做整合。 但是还必须站在中台角度去思考我数据该如何平躺能够提供中台能力的服务，还有建设进度如何。
• 比如在数据标准上从整合角度、管理角度、消费角度如何做到闭环，分别从数据安全、数据标准上做了什么，从策略角度的制定、推进、信息畅通，从接入标准、开发标准上也做了大量工作。
• 在数据对业务的模型抽象上，从分析的角度供求关系角度抽取了大量的高阶模型与可落地的分析模型。
  • 偏流量方面的分析模型，一堆指标如何关联行程一个可视化的分析图，每一实体中有哪些分析要素，
  • 内容创作的这个复杂分析模型。
  • 在内容创作与信息流商业化分析模型。

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

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

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

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

小结

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

写在结尾：

这一篇初稿写完蛮早，但是迟迟没有发出来。 疫情中也让身边每个人或多或少的改变，自己也在其中。 变成什么样子呢，变的更懒了，一个月下楼2次，还是在大肆采购生活必需品时才下楼。 同时呢，生活上也失去了应有的自然节奏，简直是相差6个小时时差。在这个期间自己只做了一件事情，就是把从业以来到现在所有的事情完整的回忆了一遍，结论是什么呢，“再彪悍的人生也不如二B过的岁月” 。

在写这一篇时想了好几个题目， 是按照第一篇的体态继续写下呢，还是换种口味。在第一篇有不少的读者提出些感兴趣的问题，原计划想在这篇去做回答，但是呢在完善这一篇的主体结构时发生了点些变化。之前构思时是在“深入聊一下透过平台角度看数仓”这个角度的问题，同时回答一些比较热的问题。改变是因为回忆引起的，自己经历过一个业务中台，在目前看来不算是成功一个业务中台，但是非常值得回味，考虑再三还是分享一个不算成功的业务中台建设建设。在写这个业务时也是去掉了很多内容，写了几个关键点，有点仓促，欢迎交流。下一个篇章还是回归到传统的数据中台角度。

作者简介： 松子（李博源），自由撰稿人，数据产品 & BI资深总监。