2016年，短视频热潮袭来。 笔者所在的团队也加入了短视频赛道，做出了业务中台湾化的决策。 但在组建数百人的队伍并投入大量资源后，这个中台建设项目以失败告终。

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

春节前和前BU成员聚会的时候，还是回顾了这个中台建设的话题。 就是“开拓一只狗，装备都在发抖”。 这个业务是很好的业务中台建设的切入点，但是很多人努力去建设，结果最终被撤掉了。 是什么问题引起的呢？ 在整篇文章中一点一点地展开和共享。

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

ps :对于各种中台的定义依然不给出定义。 定义已经满天飞了，大家要么系统化地理解中台这个方向，要么去看看其他文章。

01背景和契机是2016年秋天左右，集团某主干业务线的产品负责人说：“有一个很有趣的创业项目。 具体来说，关于短视频的创业项目，你在考虑参加吗？ ”。 经过仔细调查，该产品线负责人表示，可以和事业集团的头儿一起“开短视频赛道”，只要努力一次，就可能在短视频赛道上取得相当好的成绩。 小组多次合计，认为这件事相当可靠，在当时是个不错的新方向选择，但为了运营这件事需要构建新的独立的BU。

由于该计划中的业务涉及非常复杂的人力安排，为了组建这个新的业务单元，经过大HRG的前后调整，从不同的事业群中选择了一些合作伙伴参与，从南方某事业群中选择了产品A线、审核线、技术线、BD线、BD线。 已向北京某集团订购产品B线、算法线、审核线、BD线。 我自己当时作为BI线从其他线进入了新BU。 经过前后冲突、共建，声势浩大的启动大会顺利召开。

据此，由多国部队组成的新业务线宣誓成立，4月上线，提出了7月份Dau将达到3千万人的口号。 潜台词是，我们的财政粗糙，不需要考虑成本和投资，完成业务目标和占领行业就可以了。

新成立这个BU的主要任务是完成传奇短视频客户端的研发和推广。 在实际运行过程中，由于受到历史的负担问题，该客户端长期承载着长视频、视频的播放，需要在短时间内过渡到短视频客户端的信息流，从而导致该APP 90 %的长视频消费者受到干扰并逐渐丢失

运营产品的各运营商都需要考虑这件事。 结果，在这篇文章中怎么做并不重要。 重要的是，要完成这个短视频，除了必需的客户端外，还必须配套推荐引擎和图库。 构建图库需要根据来源进行爬网或自生产，不断完善内容创作生态，以维护高质量的内容来源。 要做好内容创作生态，需要构建一系列的商业链条。

当时接触的北方某事业群、南方某事业群都有类似的生态业务在运营，——南方某事业群有自己的图文内容生态，北方某集团有自己的视频内容生态，每个生态都有各自的客户端业务内容

每个数据体系，其中两个子集团或业务集团组成的业务都是各自的数据体系，尤其是在账号数据、图文、视频、粉丝互动、图库、消费数据方面，目前并不陌生。 虽然还存在平台多、模式接近、同质化严重、变现不足等其他诸多问题，但重点分别是：

账号问题、账号不通、账号评价与等级体系不统一； 内容评定标准不统一、种类不统一、标签体系不统一，奖励机制分别落实；审核问题，制作内容需要审核，有些子公司在审核上的投资很大。 采购问题与BD采购流程不同，或者签约多个主体； 内容生态账号数据、图文、视频、粉丝互动、图库消费数据、内容审核等易于整合服务化。 现在回想起来，这显然需要进行业务中的台湾化。 因为可以以统一的一点为中心访问多点分发方式，支撑各端的业务，进行内容的生态供给。 在建设过程中，这个中台需要打通各种信息、标准化建设、账户、数据等一系列的贯通，就是在业务流、内容流、分发流、数据流、业务流这些相近的业务中台湾化。

但是，终究为什么要做偏方的事呢？ 这个台湾化事业，最终不声不响地逐渐淡出公众的视野，但在内容生态这条线上并没有形成一个有着强大屏障的根据地。 为什么会这样呢？

02中台的考核目标是什么？ 当时冬天，在一个内容生态业务会的时候，上司向小班委员会提出了问题。

“我们的业务是内容生态、创作者生态，但我们生产创作者、内容、内容审核、图库、内容奖励，没有内容出口。 向C方的出口都在其他BU。 这个中台业务该怎么办？ 我们的审查目标是什么？ ”

其间，对于这个问题，我按照自己的想法回答了((这部分是我当时的回答笔记的整理)。

企业在业务的各个阶段业务都会疯狂地扩大。 它是在业务疯狂扩张的过程中，由于各BU业务自我封闭，大工厂内部存在很多制造车轮的工作。

要理解如何制作车轮，就是独立BU制作APP a，独立BU制作APP b，其中制作了功能相似的功能，但这在功能上内部并不是很有必要，如果继续做的话会造成劳动力成本的浪费。 此时，我们通过公共抽象的业务模块独立处理。 ( ps现在看起来很肤浅)结合内容生态这项业务来看，有几个想法。 分别是：

1 .该内容业务的基础和出发点是中台性质，偏业务型中台建设在内容生态系统中。 在创作者、创作者、入住者、生产、分发者、最终用户看来，对于该项业务的生态，中间内容生态是非常重要的业务平台，内容生产、内容提供、内容分发、内容制作激励、内容制作

如果是与信息流相关的APP方，或者是嵌入页面的一方，则都与内容相关。 这些各方的信息流来源都基于自己的业务平台的建立，许多业务的构成形式也通过不同的业务平台串联在一起，业务平台包括创造者的部署、管理、审核、机器识别、内容质量、可

这些都是内容生态的基础功能，在平台的这些基础功能的基础上，加上更复杂的抽象业务和业务逻辑进行控制，这些在业务内得到更深层次的固化，从群体的角度看是烟囱式的建设。 每个烟囱的能力直接决定着业务的发展速度和业务创新的成本，业务的快速更新和创新需要快速构建轻松高一的体系。

比如我用厨师做披萨。 全程可以自己做，但是很麻烦。 我有三个方案：

方案一，请人提供厨房、火炉、煤气。 我用这些基础设施，用自己的披萨皮烤披萨。 方案二、有人提供披萨皮。 把自己的配料洒在皮上，让他烤一下就行了。 也就是说，我做的是设计披萨的味道，别人提供平台服务，让我实现自己的设计。 方案三、别人直接做披萨，没有我自己的干预，拿到的就是成品。 把它卖掉，最多包装一下，印上自己的标志就行了。 这种烤披萨随着生态的复杂性、业务的复杂性、系统复杂性的升级，平台化解决了技术平台的问题，各单元业务的执行需要跨多个领域进行。

比如淘宝宝贝，产品的发布规则、交易规则、营销规则都分布在各个系统中，没有一个人能在做一个动作的时候把整体说清楚。 要做出一个需求结果就要评估一个月，开发几天，测试几天，效率太低了。 这已经不是一个过程就能解决的了，而是一个比较复杂的生态合作问题。

2 .作为业务中台承担的重要绩效指标是什么？ 业务型中台怎么审查？ 评价指标应该如何定义？

从测量这个生态开始该如何定义指标呢？ 例如，规模观点、质量观点、活跃度、消费、互动、收益在这六个维度上定义十几个指标？ 从这一角度来看，除了每月每日活动账户数、每月每日账户生产文章数之外，账户内容的每月每日播放量和阅读量、账户内容的每月每日播放量和阅读量超过10万的内容数量略有下降这些指标都受到边缘的影响，没有一个指标能让这个中台业务完全发挥作用。

例如，既然是围绕创作者的生态环境，也有人只看创作者、内容生产就可以了。

但是，每一张都要花费成本，生产的内容的分发存在问题，不同的地方消耗量差。 或者，可能是引出的供需不匹配的问题。 这个供求不匹配是算法的问题，内容的质量的问题，标签的问题，发布方的C端的图像描绘的问题，是链条的问题。 因为在同一个业务上承担着重要绩效指标，所以这个重要绩效指标当然会吵架。

3 .中台通过各种标准的各大金主业务线，是否否认这一点，也就是这个业务板块是如何有发言权的，还是背后默默奉献者

激励和成本问题，以前各端创作者激励机制都相当于成本部分，但都归中台承担，所以在财务上只能看到成本。 收益利润该怎么计算呢？ 创造的直接经济价值是什么？ 由于出口在各自的一端，所以在不同端的信息流中将商业化收入计算在各自端的业务端。 我在内容商务方面探索了一些，但是没有想象中那么好。

“大中台”的概念是从比较复杂的合作生态出发，纵向从服务链路进行资源整合，技术中台比能力沉淀和整合更重要，业务中台更注重链路、效率、成本、流程的优化。 业务的中台在我眼里是规则引擎的执行者和可定制的能力服务的输出目的地，规则的输出是通过数据的控制进行的。

从内容生态来看，如果着眼于子公司、集团，我个人认为是个好切入点。 集团是一个体系的巨无霸，内容生态一般需要支持内容生态的业务中台。

所以，在我看来，这个内容的生态中台：

内容生产和管理的组合既是内容生态规则的执行者，这些能力又是面向组件的设计和面向点的集成。 一个包括平台、数据、接口和系统规范的集成解决方案，包括信息呈现、快速匹配和供需中介机制。 也是业务支持、能力应用、能力运营、能力管理、协调能力、配置管理的体现。 剩下的应该是和各业务团队共同建设的。 回到烤披萨的这个小盒子里，从简单的烤披萨到中台水平的烤披萨，忽略了一个重要因素。 它随着匹克生态的复杂性、匹克上下游产业的复杂性、技术的复杂性不断提高，自身的工艺、技术、边界都在发生变化，随着时间的推移，中台的建设也能逐步应对、快速支撑这些变化。 否则，中台的建设将影响未来业务的变化

当时，刚接触这项业务的人也很喜欢，本质上应该会是非常好的内容业务型中台吧。 对内容创作者来说，从一点到多点访问和分发，对这个业务型中台的体系构筑也使用了非常有趣的方法。 另外，该业务是数据体系的有力支撑，在生态供需平衡、失衡分析、时序供需变迁方面也是很好的参照物。

03缓慢的中台建设和快速变化的业务需求偏业务型中台在建设中存在自己的难题，需要先服务下游的内部业务方，然后完成对自己中台所服务的外部业务对象的支持，最后完成自己的建设。

这个中台，是再构筑本来分成不同端的内容生态这个商务逻辑，统合类似的商务模块。

自有建设包括产品建设、内部运营工具建设、针对用户的运营工具建设，在这一资源有限的情况下，如何平衡这些方向呢？

业务中台提供服务的业务和对象分别有几个作用。 分别是完成端到端的业务支撑、完成自身创作者和内容支撑、完成自身建设。 让我们分别展开看看。

1 .端业务支持需要在每条内容信息流下提供发端服务。 例如，一个集团内不同业务线的各个信息流，包括内容通道的APP，在这里列举几个：

各端对该中端办公室的需求分为几个方面：适合自身端的高质量、丰富的可分发图库，以及适合自身端内容消费的创作者部署和端对端内容审核效率等适用于购买短内容等一系列问题； 对于自己做各种垂直类别差异化运营所需内容的创作者，各种各样的评价通过商业化进行统一结算。 每个块的内容都会影响端分发和端APP自身的指标以及内容消费指标。 如果没有这些内容的出口，内容中会做什么呢？ 所以，有一句话必须要好好服务。

2 .为用户服务中台的一个特点是需要完成自身的业务建设，其业务对象是谁呢？ 可以说是To内容制作者的业务。

引入内容创作后，从业务本身的角度来看，需要保持该账户的可持续创作能力。 优秀的创作能力无论是从产品的角度提供创作指导、创作工具的授予、数据工具的分析，还是提供运营手段的奖励机制、激励机制、分润机制，都是让这个创作者活下去的唯一目的。

具体地说，从产品的角度来看：

例如，内容浏览、账户的放大； 入驻体验、信息合规内容同步工具、生产工具、生产促进工具内容发布分析、收益结算等商业化批量结算。 从自己业务的账户角度、内容角度分别是两个部分的内容：

客户级别：账户信息结构化和规范化、质量、类别、试运营、客户体系、星级考评体系、管理方面等。 内容层面：内容感知、价值认定、规制等方面。 从运营的角度分类如下

客户分层运营、头部客户差异化运营、优质和高潜在客户挖掘； 激励体制、收益战略等活动和培训体系、社区等。 再完全分解的话，有很多内容和工作。

自身建设：

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

这些方向如果按中台角度分解，还是需要按照一定的节奏来建设和实施。 否则，即使“产研运”再生产牛，也不可能在短时间内建成支持各业务方的业务中台。

中台的建设节奏最艰难，存在一个矛盾的——业务线在发展中快速变化，快速变化必然需要各种资源的支持，而中台大部分建设都在缓慢建设和推进，两者之间会出现诉求和接受能力的不匹配。 在现有业务台湾化的过程中需要达到这一平衡，涉及不同的问题先做什么，后做什么。

写到这里偶尔会提到，现在市场上所有关于中台的文章都是一律讲中台的概念。 我在说中台的蓝图。 有实践验证吗？ 按照它们实施成功的概率到底是多少？ 每一步怎么走？

04失败的原因我相信资源问题是所有管理层最关心的问题。 该项目包括约70人的产研、约60人的运营、数十名数据员工、约40名BD采购以及约数百人的“审核”团队。 算上移动的话，前后应该有几百人吧。

“业务中台”项目拆除后，产品转岗，大部分运营得到配合，但保留了相对完整的数据团队。 数据业务的独立性适合台湾化，是“积极的建设”，所以走在业务的前列，强化核心资产、APP模式、核心业务模式、纵向场景。 但是，我们这个切入点很好的业务单元经过很多人的努力，最终还是说撤了。 很有味道……

回顾那一年外部的大环境，在内容这个领域很多公司都在迅速崛起和布局，为什么当时的这个中台以很棒的形式失去了这个阵地呢？ 既然计划中必须推进台湾化的重要要素团队都被拆除了，为什么会黯然失色呢？

以前，我们从矛盾论的角度、因果的角度、建设的角度，从多个角度再现了这项工作。 今天，总结起来，有几个方面。

数据团队需要在几个业务团队中取得平衡。 人的因素、想法太多了，想动这个中台。 人员能力问题，制作中台的难度与制作普通产品相比，有订单上的差异。 能力不足，真的搬不动这块石头，毁了所有人的脚。 中台建设是一种思维方式，但在这个过程中各有需要，形成了一条腿疼、头痛、头痛的传统猜测底线。 多条线交织在一起成为复杂、网状且比较难以分解的问题。 具体中台达到什么样的姿态，承担什么样的沉淀，还是要慢慢重复。 过程问题，太多了。 其他。

05有人问为什么数据团队要保留为码字写的一段，为什么数据团队基本上要保留，总结起来有以下几点。

独特的特性适合台湾化的积极在业务前建设、跑、梳并行，强化核心资产，沉淀应用模式、核心业务模式和纵向深化场景； 数据团队需要在几个业务团队中取得平衡。 让我详细谈谈：

在数据建设阶段，除了考虑整合基础现有的不同基层数据外，还必须在中台业务还没有掌握自己的做法时积极行动。 负责任地为了“让业务看得更清楚”而进行。 除了建立短时间内快速测量业务全链路的关键指标漏斗体系外，还需要进行交易分析。 全局ROI、本地ROI、类ROI、以及动态ROI都要积极建设。

在数据体系的构建中，我们既需要考虑整合不同的终端，也需要根据分析的主题域进行整合。 但是，站在中台的立场上，必须思考我的数据应该如何提供能够提供中台能力的服务，以及建设的进度如何。

例如，数据标准中如何从集成的角度、管理的角度、消费的角度实现闭环，分别从数据安全、数据标准做了什么，从战略的角度制定、推进、信息的便利化、访问标准、开发标准也做了很多工作

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

分流的分析模型，可视化了很多指标如何与行程相关的分析图，每个实体都有哪些分析要素，内容被创作出来，这种复杂的分析模型。 通过内容创建和信息流商业化分析模型。 拥有这些模型，一个业务，分析清晰，就能看到自己看什么，上下游应该研究谁，应该如何分析。

例如，从数据指标和分析的角度，快速建立从关键指标到分析指标的体系。 例如，在下面例子中，当分解周活时，被分解为对周发文的不同频率的监测。

数据团队需要在几个业务团队中取得平衡。

当然，我自己还在BI和数据产品领域，做了那个时间的业务和数据价值的积累，在内容生态和信息流这个业务领域熟悉了自己，学到了很多有趣的分析思考。

06如何建设一个业务型中台，特别是背负考核指标的中台，节奏是什么，中台的一些显著特性应该优先建设哪个，都是需要考虑的问题。 而最难解决的地方是对中台的认知问题、人的因素问题、过程因素、问题需要重点思考。 当然，应该选择哪个重要指标的最重要的考核指标和观察指标也是必要的。

阅读相关怪谈连篇数据中台(一)通过中台查看数据中台

作者：松子(李博源)，自由撰稿人，数据产品BI资深总监。 从2000年开始在数据领域，网络数据考古学家一个人经历了网络古生代、中生代、今生世代。 作者公众号： songzi2016。

这篇文章发表了@松子是原创的，每个人都是产品经理，未经许可禁止转载

标题来自Pexels，基于CC0协议