扫码咨询
时间：2020-04-14 来源：人人都是产品经理(业界动态)
2016年，短视频热浪开始袭来，笔者所在集团也提出了入局短视频赛道，做业务中台化的决策。然而在组建数百人团队、投入大量资源后，这项中台建设项目还是以失败告终。
继《鬼话连篇数据中台（一）：透过中台看数据中台》后，这是该系列的第二篇，从另一个角度看来也算非常特别的一篇，这是一个不是那么成功的业务中台建设实际案例的回顾，改为独立篇章。
春节前与上个 BU 的成员聚会时还是回顾这个中台建设的话题，就是“开局一条狗，装备全凭抖”，这块业务算很好的业务中台建设的切入点，但是经过很多人努力去建设，结局就是说撤就被撤了，是什么问题引起的？在整个文章中会逐渐稍微展开分享一下的。
另外自己以往写文章都是偏数据产品、BI 类，第一次来写业务类的文章，对于自己来讲也算是一个小的挑战。
ps：关于各种中台的定义还是一如既往的不给出定义，因为定义都已经满天飞，大家要系统化了解中台这个方向还是去看其他文章。
大约在 2016 年的秋天，集团某业务线的产品负责人说：“有一个很有意思创业项目，具体的是关于 是关于短视频的创业项目，考虑加入吗？” 经过更详细的了解后得知：这位产品线负责人与事业群头头一起勾兑提到“短视频赛道”可以做，努力一次，可能在短视频赛道上做出蛮不错的成绩的。一群人多次合计了下都觉得这个事情蛮靠谱的，在当时是个不错的新方向选择，但是呢需要构建一个新独立的 BU 来运作这个事情。
因为这个计划中的业务是涉及到很复杂人力调度，为了组建这个新的业务单元，经过大 HRG 的前后协调，从不同事业群选择了一些小伙伴加入了进来，分别从南方某事业群调来了产品 A 线、审核线、技术线、BD 线、审核线。从北京的某集团调来了 产品 B 线，算法线，审核线、BD 线。我自己作为当时 BI 线从其他线进入了新的 BU 的。前后经历了多次碰撞以及共建后，顺利地召开了个一个声势浩大的启动大会。
由此由一个多国部队组成的新业务线就宣誓成立，提出的口号是 4 月份上线，7 月份 DAU 3 千万，潜台词是我们财大气粗，不需要考虑成本与投入，完成业务目标与占领行业就可以。
新组建这个 BU，主要任务是要完成一款传奇的短视频客户端的产研与推广，在实际的执行过程中，受到历史包袱问题以至于这款客户端在很长的一段时间内一直承载长视频、动画的播放，需要在很短时间内向短视频信息流转变，结果就是这款 APP 的 90% 长视频消费用户受到打扰逐步在流失。
产品运营各业务方就需要去考虑这个事情，结果如何在这篇文章是中不重要的，重要的是，要完善这款短视频，除了在完善必须的客户端外，还得配套有推荐引擎与内容库。在构建内容库就需要根据来源分为爬取或者是自生产，通过不断的完善内容创作生态来维持一个高质量的内容来源。如果要做内容创作生态，那更是一系列的业务链条需要建立。
在当时接触到的北方的某事业群、南方某事业群都分别有类似的生态业务在运作——南方某事业群有自己的图文内容生态，北方的某集团有自己的视频内容生态，各自的生态又分别为各自客户端业务提供内容生产审核等，帐户体系、内容评定标准、奖励机制各不相同。
各自的数据体系，其中两个子集团或成为事业群的业务都是各自的数据体系，尤其是在帐户数据、图文、视频、粉丝互动、内容库的、消费数据上都在那时没有打通，还有蛮多其它的的问题像平台众多、模式相近、同质化严重、变现不足等，但是聚焦几个比较突出的问题分别是：
现在回顾一下，这块是很明显需要进行业务中台化，因为可以围绕统一的一点接入多点分发的方式来支撑各端的业务，做好内容生态供给。在建设过程中这个中台是需要拉通各种信息、标准化建设、帐户、数据等一系列的打通，就是业务流、内容流、分发流、数据流、商业流的这些相近业务中台化。
但是，结局为什么会做的比较偏向了呢？这个中台化业务，最终不声不响地逐步淡出了大家的视野，而没有在内容生态这条线上形成有着强力壁垒的根据地。这又是为什么呢？
在当时冬天，某次内容生态业务会时老板问小班委一个问题：
“这块业务是做内容生态、创作者的生态，但是咱们只有创作者、内容生产、内容审核、内容库、内容的奖励，没有内容的出口，面向 C 端的出口都在其他的 BU。我们这个中台业务该做怎么？我们的考核目标是什么？”
期间，对于这个问题，自己经过思考后认为的答案是（这段是整理来自我当时的回答笔记）。
企业在业务不同阶段业务会疯狂的扩张的，那在业务疯狂扩张的过程中由于各个 BU 业务自我闭环，导致大厂内部存在着很多重复造轮子的工作。
怎么理解重复造轮子呢，就是独立 BU 做了一款 APP A 、独立 BU B 做了一款 APP B，这里面做了一个功能相似功能，但是这在功能在内部是的必要性没有那么强，如果继续搞存在着人力成本的浪费。这个时候我们会通过一个公共抽象出来的业务模块去独立处理。（ps 现在看来肤浅多了）结合内容生态这个业务来看，有几个点想法分别是：
在内容的生态系中，从创作者、入住、生产、下发、端消费来看，这个业务的生态来讲，中间内容生态是一层非常关键的业务平台，内容生产、内容提供、内容投放、内容创作激励、内容归一化、内容数据反馈闭环。
只要是涉及到信息流类的 APP 端或嵌入页面、都会涉内容这块，这些各个端的信息流的来源都是基于自己的业务平台的建立，很多业务的组成形式也是通过不同的业务平台进行串联的，在业务平台中包含了 创造者引入、管理、审核、机器识别、内容质量、内容层次化管理、优质内容管理、内容标签丰富度、资金与分润等更多的基础平台来做管理。
这些都是内容生态的基础功能，通过对于平台的这些基础功能再加上较为复杂的抽象业务和业务逻辑来进行控制的，这些都是在业务内做了较为深层次的固化，从集团角度来看形成了烟筒式的建设。每一个烟筒的能力直接决定了业务的发展速度与业务创新的成本，业务的快速更新与创新需要一个像乐高一样的体系去快速搭建。
比如我是一个厨子我要做披萨，全程我可以自己做，但是非常麻烦，我有三个方案：
这个烤批萨随着生态的复杂度、业务的复杂度、系统复杂度的升级，平台化解决了技术平台的问题，每个单元业务的执行都要跨多个领域来完成。
比如说淘宝的宝贝，商品发布规则、交易规则、营销规则散落在各个系统，进行一个动作时没有一个人能说清楚全局，做一个需求结果要评估 1 个月，开发几天、测试几天，效率太低，这已经不是一个流程能够解决的，是一个比较复杂的生态协作问题。
一个业务型中台如何考核呢？考核指标该如何定义呢？
无论从那个角度看来，都略感不太合适，这些指标都受到端的影响，没有一个是完全因为这个中台业务能完全起到作用的指标。
比如有的人提到既然是围绕创作者的生态，那就只看创作者、内容生产就好了。
但是呢，每一块都是要成本，生产出来的内容下发有问题，在不同端消费很差，或许是引出的供需不匹配的问题，因为这个供需不匹配到底是算法的问题还是内容质量问题、还是标签的问题、还是在下发侧的 C 端画像刻画问题，这是一个链条的问题，因为都同属于业务都要承担 KPI，自然这个 KPI 将会打架。
奖励与成本的问题，当以前各端的创作者奖励机制相当于成本部分，因为都归到了中台来承担了，从财务角度只看到了成本，那收益利润该如何算呢？创造出来的直接经济价值是什么？因为出口在各端，不同端的信息流中商业化收入会算到各各自端的业务侧，在内容商业这块探索了一些但没有想象中那么好。
“大中台”的概念就是从较为复杂的协作生态上来纵向的从服务的链路来做资源整合，技术中台是重于能力沉淀与整合，业务中台是注重链路、效率、成本、流程的优化。业务中台在我的眼里变成了规则引擎执行者与可定制化能力服务输出方，规则的输出是通过数据的控制来做进行。
从内容生态来看在子公司、放眼集团，个人认为是一个很好的切入点，集团是某体系的巨无霸，在内容生态这块一般，是需要一个具有支撑内容生态的一个业务中台来支撑的。
所以在自己眼里这个内容生态中台：
回到烤披萨的这个小案例，从简单的烤批萨到中台级烤批萨，会忽略一个很重要的因素，那就是随着烤批萨生态的复杂度、烤披萨上下游产业的复杂度、工艺复杂度不断的提升，自己的流程、工艺、边界都在发生变化，随设时间的沉淀，中台的建设也会要逐步的去迎合与能够快速去支撑这些变化，否则中台的建设将会影响到未来业务的变化。
当时刚接触这块业务也是特别喜欢，从本质上说将会建立成为一个非常好的内容业务型中台，对于内容创作者来讲，一点接入多点分发，在这个偏业务型中台的体系建设上也是用了一些蛮有意思的方法, 而且这块业务是数据体系的强力支撑、对与在生态的内的供求平衡、偏移平衡分析、时间序列供求与变迁份都是很好的参照物。
偏业务型中台在建设中是有自己的难题的，首先要服务好下游的内部业务方，其次要完成对自己中台的所服务的外部业务对象的支撑、最后还需要完成自身的建设。
这个中台是要将原有分在不同端的内容生态这块的业务逻辑重构，并整合类似的业务模块。
自身建设含有产品建设、内部运营工具建设，对用户的运营工具建设，在这个资源是有限的情况下，如何能做到这几个方向的平衡呢？
业务中台所服务业务与对象来讲分别有几个角色，分别是完成对端的的业务支撑、完成对于自身创作者与内容的支撑、完成自身建设，分别展开来讲一下：
需要服务好各个内容信息流下发端，比如一个集团内不同业务线的各种含有信息流、内容频道的 APP ，在这里大概只列举几条：
每一块的内容都会影响到端的下发以及端 APP 本身指标以及内容消费指标。如果没有这些内容出口端，内容中到底做什么呢， 所以有句话必须得服务好！！！
这个内容中台的特点之一需要完成自身的业务建设， 那个业务对象是谁呢？可以说是一个 To 内容创作者的一个业务。
把内容创作引入进来后需要从业务自身角度去维持这个账号的可持续创作能力，优质内容创作能力，不管是从产品角度提供 创作辅导、创作工具赋能、数据工具分析，还是从运营手段的奖励机制、激励机制、分润机制都是唯一的目的让这个创作者活着。
具体来讲从产品角度会有：
从自身业务的账户角度、内容角度分别又是两部分内容：
如果在从运营角度分类还有：
如果分解得更完全还会有很多内容与工作去做：
自身建设：
除了上述产品的一堆内容外，还有标准化、组件化的建设，支撑内部运营的工具建设，分别可以从内容引入、内容管理、内容消费、以及数据体系建设分别去细化。
以上这些方向如果按照中台的角度来做拆解，还是需要一定节奏去建设与实施的。否则“产研运”再牛，也不能短时间内建设好一套支撑各业务方的业务中台来。。
中台的建设节奏是最要命的，有一个矛盾点——业务线在发展中是快速变化的，快速变化必然就会有需要强烈渴望得到各种资源支持，但是中台在建设大部分是在缓慢建设与推进，两者之间会产生诉求与承接能力的不匹配问题。对于现有业务进行中台化的过程中这块如何做好平衡是必须的，就涉及到不同问题先做什么，后做什么。
写到这里偶尔提一下，现在市面上对于中台的所有文章千变一律的都是在讲中台的概念，讲中台蓝图，有没有经过是实践验证呢？如果按照那些去实施成功的概率到底有多大？ 每一步该怎么走。
资源问题我相信是所有管理层最关心的问题了。在这个项目中，包含了七十左右的产研、六十多位运营、几十位数据人员、四十多位采购 BD，以及大概几百人的审核团队。如果算上流动，前后大概有好几百人。
“业务中台”项目被拆之后，产品转岗了，大部分运营被协解（只留了小部分运营）， 但保留了较为完整的数据团队。因为数据业务的独特性适合中台化，且是“主动建设”，所以一直跑在业务前面，并强化了核心资产、应用模式、核心业务模型和纵向场景。但我们这个切入点很好的业务单元，经过很多人的努力，结局却是说撤就被撤了，非常值得回味…
回顾那一年的外部大环境，在内容这个领域很多公司是快速崛起与布局，为什么当时的这个中台会在一形式大好的情况下，失去了这个阵地呢。在规划中要进行中台化的关键要素团队都拆解到了，为什么还会黯然失色了呢？
前面我们从矛盾论的角度、因果角度、建设角度，对这个业务做了不同角度复盘。在今天，总结来看还有几方面：
为了码字而写的一段，有人问我为什么数据团队是基本保留了下来，总结下来有这么几点：
展开详细讲一下：
在数据的建设阶段除了考虑基础的要整合原有不同端的数据外，还在中台业务还没有摸清自己打法时要主动一些，带着个责任“让业务看的更加清晰”去做的，在短时间内快速的去建立衡量业务的全链路的关键指标漏斗体系外，还需要做异动分析，全局 ROI 、局部 ROI 、类 ROI 还有动态 ROI 都是要去主动建设。
在数据体系建设上，我们需要思考整合不同端外，还需要按照分析的主题域去做整合。 但是还必须站在中台角度去思考我数据该如何平躺能够提供中台能力的服务，还有建设进度如何。
比如在数据标准上从整合角度、管理角度、消费角度如何做到闭环，分别从数据安全、数据标准上做了什么，从策略角度的制定、推进、信息畅通，从接入标准、开发标准上也做了大量工作。
在数据对业务的模型抽象上，从分析的角度供求关系角度抽取了大量的高阶模型与可落地的分析模型。
拿着这些模型，一个业务、分析比较很清晰的就能看到自己看什么、上下游该研究谁，该如何分析。
比如从数据指标与分析角度快速去建立关键指标到拆解分析指标的体系，比如下面样例，周活做拆解，会拆解为周发文不同频次的监控。
数据团队需要在几个业务团队中寻找一个平衡点。
当然了，我自身还是 BI 与数据产品领域，那段时间的做业务与数据价值积累，也让自己在内容生态与信息流这个业务领域变的很熟悉，学会了很多有意思分析思维。
一个业务型中台尤其是背着考核指标的中台该如何去建设，节奏是什么、中台的几个显著特性优先建设哪一个呢都是需要待考虑的问题，而且最难解决的一点就是关于对中台的认知问题、人的因素问题、流程因素、问题都是需要去重点思考的，当然了还有一点该选择什么关键指标最为考核指标与观察指标都是势在必行的。
作者：松子（李博源），自由撰稿人，数据产品 & BI 资深总监。2000 年开始数据领域，互联网数据考古工作者一枚，经历了互联网古生代、中生代、今生代。作者公众号：songzi2016。
本文由 @松子 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Pexels，基于 CC0 协议
全国免费咨询热线
400-6909-800
长春市西安大路150号金色华尔兹大厦2栋1门1202室
400-6909-800 / 0431-81719000
kefu@0431cn.com
