中台产品经理宝典
2021-02-04 23:28:08 21 举报AI智能生成
从业务建模到中台设计全攻略
作者其他创作
大纲/内容
写在前言
如何用最低的成本完成最多的产出？
中台战略
理解和掌握中台的设计理念
可复用的中台建设模型
MSS建设模型
从0-1搭建完整中台体系
业务中台+数据中台+技术中台
为啥中台概念突然火了？（why）
互联网发展趋势解读
互联网上半场
以消费互联网为代表
以日常生活为应用场景，为满足终端消费者在互联网中的消费需求而产生的互联网类型。
互联网下半场
美团2016年提出
2016年美团的掌门人王兴却首次在公开场合提出了美团要发展面向中小型企业用户的服务的“互联网下半场”的概念，并指出了美团的新发展方向：开始发力B端业务（B端英文全称为to Business，与之相对的C端英文全称为to Customer，B端业务指目标客户是企业或组织的业务，C端业务指目标客户是终端用户或消费者的业务）
面向企业用户
产业互联网更复杂
产业互联网无论是盈利效果、创新难度还是企业服务都比消费互联网的要复杂得多。以往在消费互联网中投入100元成本就能收获10元利润的局面，进入产业互联网就变成了投入1000元成本才可能收获10元利润的局面
产业发展视角：产业基本发展规律
三段式产业发展规律。
技术时代：产品宣传文案中主要渲染的是技术参数与首发内容。例如，16核处理器、后置四摄、可折叠屏幕等技术参数
产品时代：由追求行业第一变为追求谁家的产品更能让用户满意。
市场时代：强大的上下游议价能力。
当企业进入市场时代时，就意味着我们已经来到了本轮产业发展的最后一个阶段，而在接下来的发展中一定会有新的技术诞生从而将整个行业带入产业升级的进程。（如5G技术带来视频行业）
离我们较近的一次得到广泛应用的产业升级，应该是手机行业普及和进入4G时代。而这次的技术铺垫让市场诞生出了以抖音为代表的新的互联网巨头，也标志着互联网诞生了新的发展侧重方向——视频产业。
产品迭代视角：产品生命周期
生命周期图
引入期
产业中各企业都在以技术攻关为第一发展目标，一切的基础都建立在产品是否能产出
成长期
此时产品是用户导向的，企业会向纵深发展，将最新技术应用到各个人群，为各个细分用户群体进行量身定制
例如，以淘宝网、京东为代表的这类线上购物模式诞生后，在产品主导阶段，电商行业演化出了海淘电商、二手市场电商等企业，去满足技术时代被忽略的各种小群体。
成熟期
产品已经完成了缺失功能开发，进入迭代优化期（例如，此时在App的更新介绍中大多数描述都是关于性能优化和交互优化两个方面的）
从宏观角度来看，整个产业已经变成了市场为王的流量游戏，此时的新项目上马依靠的是原有渠道导流、大量级App换量等
举例来说，在互联网行业中衣食住行已经发展得相当成熟，此时如果想再次切入市场，唯一的玩法就只能是去寻找互联网流量巨头，依靠其进行导流。我们可以看到，早期的拼多多能异军突起，其中一个相当重要的原因就是它获得了微信这一应用的流量入口，
衰退期
新产品或替代品出现导致用户转向其他产品，用户量开始衰退，随之产品渐渐停止维护，产品开始走向死亡。
映射关系
子主题
分界线出现的原因
原因概述
消费互联网：在上半场诞生，之后进入市场时代，产品普遍步入成熟期，即将进入下半场。
产业互联网：新的发展领域，在整个市场上还不存在绝对巨头，市场处于技术时代，任意一家企业都有可能成为未来的巨头。
产业互联网：新的发展领域，在整个市场上还不存在绝对巨头，市场处于技术时代，任意一家企业都有可能成为未来的巨头。
分析
相对于消费互联网的增速变慢，此时再来看看巨头们所追捧的产业互联网，还是从产业发展规律与产品生命周期两个维度来看：其市场处于技术时代，其产品处于引入期与成长期，可以说具备标准的全新市场特征。
面对整个大环境的变化，对于以往都是在深耕消费互联网产业的企业来说只有3个选择：
与巨头继续在现有战场进行更惨烈的竞争。
在现有领域通过研发新技术去带来新一轮互联网发展。
去选择其他的产业新生方向（产业互联网），重新回到“刀耕火种”的阶段。
与巨头继续在现有战场进行更惨烈的竞争。
在现有领域通过研发新技术去带来新一轮互联网发展。
去选择其他的产业新生方向（产业互联网），重新回到“刀耕火种”的阶段。
当整个C端业务出现乏力时，面对选择，前几个选项所需要的时间与投入都比较大，且有着高风险，因此各大企业也不得不向产业上下游进发去选择新市场，这是一次能改变企业在行业内地位的机会，这也就是互联网下半场竞赛开启的原因。
互联网上半场业务模式：前后台业务模式
前台
也是企业真正与用户产生交互的部分
每个前台系统都是用户首先对一个产品整体建立认知与产生评价的地方
后台
后台系统主要指可以管理企业的核心资源（数据+计算）的系统，2部分
企业的内部资源管理系统
如订单管理系统（OMS）、企业资源计划（ERP）
为前台提供计算服务的基础平台
如数据压缩能力、并发等
其提供的服务都是不被普通用户所感知的
前后台交互模式
互联网下半场业务模式
特征1：以企业服务为业务核心对象
服务对象发生了巨大的变化，由原来的个人消费者变为一个个独立的企业主体
在上半场发展中，企业好比是在做增量市场
而在互联网下半场中，则变为主要去做存量老用户的信息化升级业务
通过互联网工具对传统非软件化企业或已经有薄弱信息化建设的企业进行升级改造。
互联网产品所提供的解决方案也从改善普通用户的日常衣食住行变为聚焦企业的生产经营活动，具体措施也就变为以提升企业运营效率和优化资源配置为核心和出发点的互联网应用和创新。
提升运营效率就是通过信息化帮助企业提高内部信息流转效率，将以往信息流转节点自动化或者创造更方便企业人员去处理的方式
企业内部审批管理，在传统的线下流程中，用户需要拿着材料去找到特定的节点人员进行签字。
优化资源配置主要是帮助企业进行生产成本管理，优化供应链体系
上半场，企业尤其是各大电商平台（如淘宝网、京东）根据自己的需要凭空创建出了一个全新的以线上订单为导向的供应链体系。这种新的供应链基本上重新构建了整个行业的交易效率，也借此为我们创造出了“双11”这类的购物狂欢节
与之对应的线下实体厂商的供应链在今天看来是相当低效的，因此下半场就是针对线下传统的供应链进行数字化赋能升级，互联网企业利用能够搭建高效率信息传递系统的优势去提升传统供应链的效率。
比如，供应链更加精准地反馈信息，根据原材料的实时库存量变化去智能预判产品产量变化，从而去辅助生产决策，应对订单的突然变化。
消费互联网面向C端消费用户，不断开拓互联网市场边界，以满足用户衣食住行的基本型需求为目的。
产业互联网面向以往市场中的存量客户，也就是企业主体，以产业端提升效率为目的。
产业互联网面向以往市场中的存量客户，也就是企业主体，以产业端提升效率为目的。
特征2：渠道中间商的新价值
在互联网上半场里，传统零售行业中冗长的销售链条一度是互联网企业口诛笔伐的重点对象
各个行业中的互联网巨头就通过“干掉”经销商与代理，将这些中间商的利润让给用户，从而完成了企业自身的用户群的快速聚拢
如果说上半场的商业模式是强调“颠覆”，通过搭建买方与生产方直接对接的平台，实现交易环节压缩并降低交易成本的
那么下半场的逻辑就变为“赋能”，互联网企业不再强调去中间化，
而转变为在不改变原有利益分配的结构下，建立起产业间各公司的关系从而进入企业的后端，为企业与供应链中的生产企业提供信息化服务，提高生产过程中的信息传输效率与产业内资源配置效率
而转变为在不改变原有利益分配的结构下，建立起产业间各公司的关系从而进入企业的后端，为企业与供应链中的生产企业提供信息化服务，提高生产过程中的信息传输效率与产业内资源配置效率
特征3：千人千面的业务
同样是关于订晚餐流程，虽然企业服务的决策者也对订餐流程没有概念，但是由于他掌管着众多员工，出于企业经营成本考虑，决策者肯定会选择最贴合自己企业的流程的服务。
这其实也就是我们做B端业务时很普遍的现状：面向企业的产品很难要求一家企业去修改内部的组织架构、人员分工、业务模式、规章制度来适应我们软件的流程与功能，否则企业肯定不会选择我们的服务。
在下半场我们进入了非标准化的互联网时代。
两者要素对比
既然业务特征已经发生了如此大的变化，那面对这种变革时企业自身的产品研发模式又会对应地发生哪些变化呢
中台概念是什么呢？（what）
为创新而生
2019年也被称为中台规模化元年
互联网新趋势下，原有前后台业务模式受到考验
中台并不是互联网企业在一开始就有的，而是基于“前台+后台”的架构演变而来的。
事实上前后台模式反而是公司最省时、省力的一种面向新业务场景的解决方案
为什么不用呢？原因就是业务的主要矛盾发生变化了，我们的产品由标准化产品变为以用户为单位的定制化产品，此时为了抢夺市场资源，每个定制化产品都需要快速迭代、落地终端。
前后台模式的根本弊病
产业互联网最显著的体现就是任意版本的功能生命周期缩短了
就像这个案例中由6个月缩短为2.75个月。可以想象，除了用户需求的变化越来越多，市场中同一行业的竞争者也越来越多。这些都逼迫着每家互联网企业不断去快速更新产品来更好地满足用户需求
暴露了前后台模式的根本弊病：响应速度太慢。
为什么慢？
子主题
在这样的架构下，每个项目的底层支撑部分都是独立建设的，但是实际上对于一个产品来说，用户真正能接触到的部分只是前台业务，如App、小程序、网站等
我们的一个电商网站由于用户前台需要组织各种新的销售方式（如拼团、一元购等），所以在每次活动页面开发的时候不仅需要前端重新设计页面，而且后台的服务接口与数据表都要重新设计。
对于现在的模式来说，各大公司需要的是一个最少改动底层或只开发上层就能应对绝大部分需求的新的解决方案
前后台模式下的发展瓶颈
是因为公司业务发展到某一阶段时，在推进多条业务线并行发展时遇到了瓶颈，此时为了解决如何继续朝前走的实际问题而不得不去探索前后台如何更便捷配合的新解决方案。
三点
（1）公司内外发展冲突
还拿前文的收银系统案例来说，在业务初期这个系统可能只面向餐饮行业，所以我们的收银系统都是依照餐饮业务场景进行设计的。但是随着企业市场的扩张，我们的这套系统需要面向零售行业进行推广。此时，我们要如何针对零售流程去改造收银系统？是一切都从零开始建设一遍，还是将原餐饮行业的收银系统剔除面向餐饮行业的特殊化功能后将剩余部分迁移过来进行二次开发？
这里还只涉及公司原有业务进入一个新的细分市场，而当我们需要同时投放多个市场时又要如何高效地进行呢？这种公司外部需要快速迭代而内部每次迭代都需要“伤筋动骨”的冲突是我们存在发展瓶颈的根本原因。
（2）“前台+后台”的齿轮速率匹配失衡
在前台业务不断变化的过程中，为了能予以支撑，后台必须提供对应的接口与进行数据持久化。
带来的矛盾就是：以往为了支撑前台越来越多的业务，后台在建设中不断通过模块化设计来追求服务稳定性，这种设计模式反而会导致系统越来越庞大，同时这样的后台变得越来越没法去快速响应前台业务调整所带来的改变
（3）公司内部的二次统一
众多管理学书籍都曾提到这样的一个概念：一个有战斗力的公司一定是二次统一的公司。
第一次统一是组织架构上的统一，这个统一在每一位新员工加入公司时就已经自动完成了，也就是大家都归属同一家公司。
第二次统一是指思考角度上的统一，大家能否不计较个人利益得失，从公司大局方向去思考，以集体的需求为统一出发点。
而第二次统一在企业刚组建完成时其实是自动具有的
最终会出现一个公司包含多条独立业务线的情况，
第二次统一就消失了，开始普遍出现组织行为学里非常经典的“屁股决定脑袋”的现象，也就是每个部门在决策时只会从本部门利益出发
换言之，如果出现一个能对公司有好处但对部门的关键绩效指标（KPI）没好处的事情，部门的负责人是绝对不会去做的。
这使得一些功能模块被不同事业部反复建设，当使用时还需要跨越多个部门去多次对接。结果就是，不仅无法快速完成产品迭代，还要耗费极大的开发成本。
中台的出现也可以说是互联网企业在管理学方面的集体提升。
中台解决方案定义
通过一个做菜案例读懂中台
子主题
子主题
采购--后台：回到研发流程上来看，负责买菜的人其实就是我们研发的后台人员，他们帮助我们解决基础的原料问题，可以让我们稳定不断地从外部获取材料，保证内部供给。
做菜--前台：而厨师是我们的一个个前台业务人员，他们要做的就是根据不同地区不同口味烹饪出对应的菜系。
做菜--前台：而厨师是我们的一个个前台业务人员，他们要做的就是根据不同地区不同口味烹饪出对应的菜系。
就可以将洗菜、切菜、配菜这些半成品的生产过程统一交给中台去完成，做菜的时候作为前台业务人员的“厨师”只需要告诉中台自己需要什么材料，当然这里的配菜小哥就是我们的中台，这样就大大加快了业务的完成速度。
有了中台之后，根据不同业务需求去使用中台生产的对应半成品进行二次加工。
站在架构的层面来看看中台对整个系统业务所起到的对接简化作用。
子主题
而后台的每一个模块都需要维持与前台业务的关联，并根据不同业务的前台特征去加入适配部分。这样造成的结果：[插图]后台的每一个模块都需要加入与前台适配的部分，从而大大增加了开发量。[插图]每个前端在启动时需要分别对接不同的后台模块，也加大前台启动时的工作量。[插图]当后台进行升级或架构调整时还需要考虑与前台的对接，并进行逐一的调整。
当我们引入中台后，让中台作为一个对接层，帮我们去统一对接前台的不同终端，同时对后台各个子系统进行统一的封装，让前台能无感知地使用各项服务而不需要单独设计通道，我们的系统也就简化
子主题
用一句话来概括中台模式：中台的核心本质就是向前台业务提供服务共享，目标是更好地支持前台业务方进行规模化创新或大规模试错，从而更好地响应市场需求
中台作为一种产品设计思路或系统架构思路，并不受限于公司的规模。理论上讲，任何一家即将或者正在面临业务高速增长状态的企业，都值得利用和借鉴中台的思路，将目前业务当中大量可复用的功能和场景进行梳理，为业务的高速增长做好准备。
中台解决方案的完整定义
中台解决方案=能力输出+标准化中间件
（1）第一部分：能力输出
对于一家企业来说，其能力可以包含多个维度，常见的例如计算能力、技术能力、业务能力、数据能力、运营能力、研发能力等
所谓“能力输出”就是要规划出什么是公司的核心竞争力，理清楚公司发展的战略目标与未来公司的主要业务会拓展到哪些方面，在这些业务层面中去提炼那些以共性存在并会在每个新开拓的业务中被不断使用的模块，，然后将其归类到中台中进行统一建设，而不是把所有能力都进行复用化。
中台的一个重要的意义：为不同的前台业务提供可以重复使用的能力，形成一次建设、多次使用。
举例
我们规划了公司的核心方向是视频方向，未来可能涉及的业务形态：[插图]在线视频。[插图]视频直播。[插图]短视频。
分析上面的业务形态后，我们不难判断出要抽取的基础模块包括：[插图]在线视频编辑。[插图]视频压缩。[插图]多人点播。[插图]视频断点续播。[插图]视频账户体系。
在完成这样的划分后，我们就可以通过中台去统一实现这几个通用模块了。
虽然这里在说中台要考虑复用性和扩展性，但是要考虑多少、考虑多深就是一个非常考验产品经理功力的地方了。
但是在具体的中台规划中我们会碰到很多这种复用范围大小的决策，此时我们必须按照公司的核心业务规划来严格定义中台的能力，避免在中台出现过度建设的现象。这里也用一句话来概括：可复用性和复用深度是衡量中台建设好坏的重要指标。
（2）第二部分：标准化中间件
需要将每个能力进行封装，形成统一的可供前台业务端快速使用的中间件。
这里的“统一”具体表现在如下的两个方面：[插图]不同终端中的叫法与含义。[插图]定义统一化的输入输出。
为什么要统一呢？
在以往的前后台模式中，同一家公司内的不同项目组（如直播项目组、短视频项目组等）各自为战的时候，经常会出现一个事物在不同项目中因为场景化的需求而出现多个称呼的现象。
原来不同项目组想要复用对方的模块时遇到的一个巨大的障碍，它导致无法快速对接，只能重新开发、重复建设
就拿现在任意系统中随处可见的“用户昵称”这个字段来看，在不同项目组的应用中可能叫“用户名称”“用户昵称”“称号”“化名”等；而在数据库中又可能有不同的字段名称，如“username”“UN”“name”等。
中台能为企业带来的价值
大幅降低软件开发的边际成本
我们介绍的中台模式就是标准的边际成本递减事件
[插图]基础设施的建设成本在后期可以通过大量的产品生成而逐渐摊平，让前期的投入成本无限趋近于零。[插图]中台其实也就是我们企业的基础设施，同样符合上述边际成本递减的经济规律。
体现在哪些方面
（1）提升内部服务的复用能力
（2）提供全局化视野和全量数据模式
主要是数据中台
（3）提升应用的TTM
产品从研发到推向市场所用的时间
我们在3个方向实现了统一
专用术语含义统一
结构化表达统一
业务身份统一
（4）统一用户感知
子主题
中台的核心目的就是降低成本与提高效率。
中台化浪潮
中台化的进程是受企业进入下半场业务所驱动的，所以对这一新工具的掌控的快慢将会直接决定企业在市场中竞争力的大小。
中台与产品微服务、SaaS的区别
产品微服务
子主题
这样的化大为小的思路在产品设计层面也是存在的，像公司随着业务线的发展，其产品内部的功能也会出现不同层级复用。因此我们在设计产品时就会将功能进行抽象并剥离出来，使之成为公共模块，以方便整条业务线调用，例如，审批模块、登录注册模块、个人信息编辑模块等。这种设计理念被称为产品组件化。
特点：
对业务进行分割、抽象，将整体业务划分为多个子模块。
每个子模块自成体系，可独立运行该部分业务的完整流程。
每个业务系统的每个服务都有一个通用的标准，输入、输出具有清楚定义的边界。
每个子模块自成体系，可独立运行该部分业务的完整流程。
每个业务系统的每个服务都有一个通用的标准，输入、输出具有清楚定义的边界。
中台与产品微服务的区别概括起来就是：产品微服务只是中台的实现手段之一但不是中台
SaaS
SaaS介绍
SaaS的英文全称是“Software as a Service”，中文翻译为“软件即服务”。
有SaaS前
软件商每次卖给用户的只是一张罐装好程序代码的光碟，用户在拿到该产品后需要在自己的电脑上进行安装使用
有故障的时候，这个时候就需要厂家进行售后维修。但是软件产品有它的特殊性，因为运行它的计算机载体不同，所以它所引发的故障和问题是不可控的，这也给厂家的售后带来了巨大的问题
有SaaS后
在互联网诞生之后，厂家为了给顾客更好的体验，不再将应用软件以光碟的形式让用户部署在本机上，而是统一部署在自己的服务器上，由厂家自己进行后续的升级维护，此时用户可以通过网页或者特定的客户端进行访问、完成服务，不用再担心软件的安装与售后，常见的钉钉就是一个标准的SaaS服务。
每位用户可以根据自己的实际需求，向这些SaaS软件厂商按照计算量与时间进行使用权的购买，用多少买多少。
SaaS其实就是一个服务需求方的成熟软件产品，它为顾客提供了完整的计算平台与客户操作终端，当然这里的终端可能是网页也可能是客户端。
和中台的区别
中台其实是帮助企业自身提高研发效率的工具，中台的目的是企业能快速进行一个产品的搭建，而不是给客户提供直接服务
用户：中台产品的用户是企业内部的业务人员
形式：中台为了能更好地为各个项目提供能力支撑，在企业内部提供的服务更多采用接口的形式而不一定有客户端。
什么企业需要中台
3个思考角度出发
（1）公司发展阶段
一类是初创企业，一切从零开始规划好；
另一类是业务线复杂的企业，一个企业在整个发展期间能做到多元化的业务，说明企业在核心业务上发展得比较成熟且产生了一定规模价值，此时开辟了新业务并将成功经验复刻到这些新业务上，从侧面也说明了这样的企业业务具有大规模性和高价值性。
另一类是业务线复杂的企业，一个企业在整个发展期间能做到多元化的业务，说明企业在核心业务上发展得比较成熟且产生了一定规模价值，此时开辟了新业务并将成功经验复刻到这些新业务上，从侧面也说明了这样的企业业务具有大规模性和高价值性。
（2）公司战略目标
是否愿意继续聚焦本行业？因为中台建设实际上是在企业级别进行资源与能力的共享，而如果未来业务点不是统一的，那么最终中台所共享的内容将无法发挥原本的作用，也就是指企业内部相同需求的受众太少
（3）公司业务线（最核心）
公司内是否已经沉淀了一定量级的IT资产？这里的资产可以是数据、业务流程、运营模式等
并且这些业务线的资产是否都被验证过？例如，电商平台都有自己的订单流程，那么该订单流程是否已经被验证是符合市场需求的最优解？如果是，可以构建中台，我们可以用这一套成熟的订单流程去承载不同的前台电商模式，如工厂模式、海淘模式、第三方入驻模式
如果这套流程本身还未成熟，业务线还在探索该流程是否能最快捷、最精准地描述订单流转体系，还需要时不时推翻重建订单流程，那么此时就没有必要将该业务线的资产归并到中台建设。
两种类型的企业需要
公司内部有多条产品线（比如电商平台）
整体业务逻辑庞大复杂。业务系统研发团队多达数百人，需求多，变化快，这时业务中台可以把系统和业务领域划分清楚，提高研发效率。
公司已经有一款功能成熟并开始盈利的产品
此时这款产品是被市场验证的，我们可以将该产品的成功经验提取出来、放入中台，使其成为公司中的“万能钥匙”。公司在发展新业务时，可以使用该中台服务提高项目的研发效率。
中台产品的发展趋势
Supercell：国内中台概念的启蒙导师
在国内，中台的架构应该算是起源于阿里巴巴集团的中台的架构
阿里巴巴集团的思想大程度上也是起源于阿里巴巴集团在2015年的一次商务拜访。当时阿里巴巴集团的一行高管率队前往位于芬兰赫尔辛基的Supercell游戏公司进行考察。
子主题
子主题
国内中台先驱者：阿里巴巴集团“小前台+大中台”
为了满足日益增长的两个巨头业务方（天猫和淘宝）的需求，在2009年一个名叫共享业务事业部的新部门便应运而生
在2010年诞生的聚划算业务，也被集团要求必须通过共享业务事业部接入阿里巴巴集团底层服务
2015年12月，阿里巴巴集团正式对外宣布新一轮组织升级，终于“中台”概念由阿里巴巴集团内部走向了大众的视野，阿里巴巴集团宣布内部形成“小前台+大中台”的架构。
“大中台”就是将提供统一服务的部门做大做强，让其负责更多的公共服务研发
而“小前台”就是让业务部门少研发，将技术团队变小，从而让更多的需求由中台去完成。这样就能在中台完成之后，将成果快速地共享给其他部门使用，从而实现一处研发、多处使用的高效研发目的。
子主题
伴随着中台架构确立，在阿里巴巴集团内部对业务的二次梳理也展开了，电商中各业务线的边界是什么？每个业务领域中的基础服务是什么？各服务要如何高效相互调用？不同职能团队的职能又该如何定义？
对这些问题的解答也让阿里巴巴集团形成了一整套标准体系——业务能力标准、对象定义标准以及中台化后的企业内部管理和运营方法，从而支持前台业务快速、低成本地创新。
子主题
这里整个体系共分为3层，
自下而上依次为：
[插图]基础服务：也就是技术层面，以高可用、异地多活为特征。
[插图]阿里中台：通过将原各条业务线中相同的模块抽象后得出的共享业务服务能力。
[插图]业务应用：通过调用中台服务，快速组装成的具体应用软件，也就是终端用户真正使用的产品，如淘宝网、天猫App、阿里巴巴App等。
自下而上依次为：
[插图]基础服务：也就是技术层面，以高可用、异地多活为特征。
[插图]阿里中台：通过将原各条业务线中相同的模块抽象后得出的共享业务服务能力。
[插图]业务应用：通过调用中台服务，快速组装成的具体应用软件，也就是终端用户真正使用的产品，如淘宝网、天猫App、阿里巴巴App等。
另一个巨头：腾讯的中台化历程
子主题
子主题
我们知道腾讯已通过组织架构调整的方式将整个集团的业务发展方向锁定到了B端市场上，希望通过为B端企业提供服务来在互联网下半场的浪潮中找到一个新业务增长点。
腾讯的动作便是通过建设开放中心从而服务众多细分领域的中小型企业，让腾讯自身成为这些企业的业务承接平台，以此通过先服务B端客户再间接获得C端用户
通过这样的业务布局，面对一个细分赛道众多的碎片化市场时，腾讯只需要做好对碎片化市场中的企业的服务——这一相对标准化的市场服务，而由这些平台上的企业去进行细分市场的占领。腾讯自身就像一根主动脉血管一样不断向周边的毛细血管输送养料，从而实现间接触达整个市场终端用户的目标。
要达成这一目的就要使得腾讯能将自身的内部能力向外输出，因此腾讯在内部通过成立技术委员会进行“开源协同”和“自研上云”这两大动作，来推动公司技术的整合
所以通过中台的统一化管理，腾讯能够快速将自身多年的发展中所积累下的经验与解决方案向外输出。从这次大会我们也可以看到，腾讯开放的中台能力包括数据中台和技术中台两部分：
[插图]数据中台分为用户中心、内容中心、应用中心。
[插图]技术中台分为通信中心、AI中心、安全中心。
[插图]数据中台分为用户中心、内容中心、应用中心。
[插图]技术中台分为通信中心、AI中心、安全中心。
中台产品的发展与演进
子主题
（1）第一个阶段：共享代码平台
让各条业务线的开发人员在开发公用模块时可以直接使用公共代码库中的代码。
登录注册功能、线上支付功能
（2）第二个阶段：共享服务平台
仅仅将代码进行复用还是不能大幅度地提高开发效率，因为面对不同业务时还需要将代码剥离原有业务、进行二次修改并重新调试
因此企业开始尝试将一些与业务耦合度低的基础服务（如消息推送、人机识别等）单独进行开发维护，让后面的产品线可以直接使用这些公共模块
如消息推送、人机识别等
（3）第三个阶段：共享能力平台
当下中台所发展到的阶段
将服务共享变为能力的公用，并将各业务数据进行了汇总。
开始思考是否也有办法将以往业务中的代码抽象、封装起来让别的终端使用。经过探索发现，可以以能力的形式，也就是将一个业务中的各个模块抽象为能力，将其提供给其他业务方
这样的好处是可以使公司中核心技术力量所设计实现的模块在公司各条业务线中得以应用，从而保证公司各条业务线中核心部分的体验能高度统一。这种方式也就实现了在业务相关性高的部分可以进行快速的复用。同时，我们可以将这种业务相关性高的部分在业务场景中的数据进行汇总，形成企业的统一的数据资源。
中台产品的正确分类
中台的核心本质就是向前台业务提供服务共享，也就是说中台其实是一个解决互联网企业内部运作问题的工具，因此中台的定义应该与企业的定义高度协调。
子主题
子主题
（1）技术中台
与平台化最大的不同就是会负责将企业内部各个成熟的功能模块代码进行封装，产出通用的技术工具以方便不同业务线直接调用
，如视频压缩SDK、IM（即时通信）SDK等
，如视频压缩SDK、IM（即时通信）SDK等
以制造一辆汽车为例，技术中台可以被理解为生产线上的各个机床，是一个生产工具，可以将后台通过原料生产出的可用业务耗材，如钢材、橡胶、玻璃等，生产成车门门框、座椅、轮毂、轮胎等通用中间件。
（2）业务中台
业务中台负责为公司的用户需求提供基础材料解决方案
业务中台从全局的高度出发，结合公司发展战略，有针对性地承接各条业务线的公用支撑服务，并根据不同业务场景下的需求，将已经“跑”通的前台业务流程封装成可直接使用的“半成品”
搭建整个公司可以用的会员中心、订单中心等
继续以汽车制造为例，业务中台相当于半成品生产线，通过将多个机床打包组成一条生产线，同时可以根据需要，将不同的零件拼成不同的半成品，如将车门门框加上侧窗组成车门。各个前台部门（如轿车组、SUV [运动型多用途汽车]组等）只需根据自己的需要，选择对应组件，拼装出整车，刷上油漆，印上自己的品牌标识，就完成了一辆车的生产。
（3）数据中台
数据中台帮助企业进行业务全生命周期中的数据管理，监测产品在各个状态下运行产生的数据，从而赋予一家公司数字化运营能力。
更重要的是，可以打破业务线的间隔，将不同业务线产生的用户数据汇聚至中台，形成“超级大脑”以进行决策。
在生产汽车流程中，作为企业负责人的我们需要去关注铁矿石采购量、花费金额、钢材生产量、转化率、车门门框成品率、各条产品线产量、库存量、最终销量等这一系列从生产到销售的数据指标，而数据中台就是将这一切汇总并显示的产物。
c端和b端各自需要的中台
互联网下半场的C端业务
互联网增长动力模型
子主题
投资人
一个产业的发展除了与产业内部的“自身造血”有关，产业外部的资金注入也是产业发展的一个非常重要的因素
子主题
网民数
一个产业的发展，其核心目的就是服务用户。因此产业发展的一般性规律就取决于用户数；只有用户多了，产业才可能发展得好
曾经有两次大的用户数暴增浪潮
。第一次是发生在2000年左右PC端用户的暴增浪潮
第二次互联网发展大浪潮——移动产业的飞速发展，2012年开始
科技发展
子主题
Gartner曲线是一条描述新技术产生后人们对其的预期随时间变化的曲线，通过这条曲线能很直观地看出整个市场对于该技术的关注热度变化趋势，以及该技术在某时间点的实际发展情况。
在图4-2中我摘取了5G技术在2019年的Gartner曲线中的具体情况。
5G在图中被该机构预测还需要2到5年才能真正成熟。
宏观背景
一方面是经济，一方面是政策。凡是政策指导的，或者说政策支持的，都是一个行业发展的非常重要的原因。
消费互联网市场为什么发展放缓？
子主题
流量红利衰退后的新发展趋势
目前企业应对策略可以分为以下两个方向
（1）精细化运营
长尾理论会成为互联网变革后消费业务的新核心增长点
子主题
大家之前所聚焦的都是如何不断扩大自身市场份额，是一种“跑马圈地式”的发展
对于用户声音，我们并不是全部接纳，而是挑出其中共性去采纳
毫不夸张地说，在这一发展时期，是我们对用户在进行反向筛选。
由于互联网用户增速处于一个高增长态势，此时新功能获取的新用户的数量是远远大于流失用户的，最后我们还是选择并做了视频功能
随着互联网用户数的减少，获取一个新用户的成本开始陡增，各大企业便开始更为注重自己的用户留存问题
要将以往没有满足其需求而流失的用户重新获取回来，去对这些曾经被我们视为小众群体的用户群发力
此时企业愿意为这些不同类型、不同偏好的用户去设计对应的功能，甚至会将以往非常小众的群体的需求也一并满足。在产品规划战略上就是将以往标准化的功能按不同的用户层进行单独设计，通过发展多样化的展现方式去获得这些互联网长尾流量。
举例：登录模块
最开始出现时只使用了账户密码
又推出了验证码登录模式
想用账户密码模式，也有用户想用验证码登录、指纹登录、微信第三方登录、QQ第三方登录、支付宝第三方登录等模式
入口端功能本身更带有拉新属性，因此各大企业将用户意见悉数保留，这也是为什么大家看到登录界面变得越来越“花哨”
子主题
（2）以创新驱动业务
当下C端业务已进入一个存量的时代
例如，一个新闻阅读用户在某一时间段选择了A头条去看新闻，此时作为竞争对手的B头条自然就少了一个用户
而在以往，面对这种用户量减少的情况，企业还能通过将新入网的用户引入自己的产品来弥补自己产品竞争力不足的缺陷
随着互联网人口增量的减少，这种路子也行不通了，整个C端市场变成了标准的零和博弈。
如果想在如此竞争激烈的市场中站稳脚跟，那么只有在行业中一方面稳定自己的用户，另一方面集中资源去进行业务创新，这就是当前的新发展趋势
在用户群体只能被勉强维持的状态下，也就是在企业收入可以精准地被预估出来的情况下，我们要如何保证低成本又高质量的创新呢
像前文我们举出的Supercell的例子，如果一个企业想要保持持续的创新能力，那么一方面它自身内部需要有能力快速应对市场需求并提出解决方案，另一方面要能保证用于创新的成本为最低。只有这样才能以最快的速度和最小的代价去验证市场，找出市场中这些小众群体真正需要的产品。
所以对于此时消费市场中的企业来说，中台建设这一主题在现阶段就变得至关重要了。
C端市场的中台建设目标：
1、为支持不同偏好的细分用户群体业务提供统一支持；
2、为快速创新、高频试错提供基础服务。
1、为支持不同偏好的细分用户群体业务提供统一支持；
2、为快速创新、高频试错提供基础服务。
B端业务复杂多变的共性
设计B端产品核心共性是5个要素
每一家企业都有自己的个性化需求。那么这种市场情况背后是否有什么不变的东西存在，而它能帮助我们在搭建软件系统的体系结构时去找到一些思考的“抓手”？
所有企业的决策人在最终决定是否要采购系统时其根本目的都是帮助企业更好地经营自己的业务，从而帮助企业创造价值。
维度一：为企业直接创造收益
维度二：提高企业内部运营的效率。
维度三：帮助企业更好地完成信息传播。
子主题
客户与交易行为的创新
互联网免费模式，就是我们将产品免费教给用户使用，再通过向第三方出售广告和用户，最终利用数据进行变现
客户与营销的联系
我们从直接向用户宣传产品的优势变为主动制造话题热点来引爆病毒式传销。
一家企业的基本运作逻辑就是不断处理这五者之间的关系，也正是因为如此，B端客户业务才会“千人千面”。因为每一家公司内部的客户、产品、营销、自身团队、交易行为这5个要素的组成都是不一样的，所以每一家企业的运作逻辑是独特的。
我们就发现企业核心的共性就是这5个要素。所以我们在设计系统的时候就应该从这五要素出发，帮企业更好地梳理企业自身与这些要素的关系来帮助企业完成价值创造。
如何衡量B端产品是否成功
两个误区
（1）唯日活论
B端的用户体量不会大
B端产品真正应该追求的是高净值客户而不是用户数量。
（2）虚荣指标
核心就是监控产品核心指标，将数据进行可视化展示，为产品提供有价值的信息反馈
有价值的信息反馈
哪些指标可能影响产品发展与盈利
哪些指标的改变可能让你的产品有更大的盈利
如果指标的数据分析最终不能指导产品负责人或开发者如何让产品达成商业目标，在阿利斯泰尔·克罗尔的《精益数据分析》这一书中，这类指标被起了一个专门的称呼——“虚荣指标”，也就是说它只能用于满足产品设计者的虚荣却带不来实际价值。
B端产品的唯一评价指标（ROI）
正确衡量产品好坏应该从营业收入、利润、ROI这几个方面入手，而这其中最重要的指标就是ROI
ROI
ROI就是在衡量我们投入成本开发某个B端产品后能否卖出软件、获得收益，并且收益大于成本。
子主题
这绝不意味着因为要控制成本就开始一味拒绝用户的需求，从理论上来说关于B端产品的终极目标是要做成能提供定制化服务的产品
什么是定制化服务呢？既然是B端服务，那么每一家企业用户都是独立的，所以每一个用户都应该有个性化配置软件的权利，这就是定制化服务。
而我们要做的就是全力去实现每一个商家的独立需求与个性化部分，而不应该像C端产品一样去规定用户应该怎么做才能完成目标
在成本可控的情况下，每一个功能都应该变得可配置。例如，有的客户想把按钮叫作“确定”，还有的客户想把按钮命名为“同意”，我们都应该去满足客户
而目前很多服务于B端商户的产品之所以卖不出去，就是因为企业还是以一种C端市场的方法去设计产品，并强迫商户根据其定好的路径去使用产品，那么商户凭什么要使用与自己工作流程差异巨大的产品呢？
面对B端客户时，对每一家的需求都应该去满足。我们要去定制化开发，只是在开发中要控制好每个开发功能的投入成本，力保每个新定制化的功能都能吸引客户并完成最终购买决策。
在做B端产品设计的时候我们应该掌握的是用户的思考模式，就是采用ROI思考导向法。
高昂的B端产品MVP尝试
在我们确定了根据ROI导向的思维模式去开发和推广市场后，新的问题出来了。有很多时候我们无法保证这个功能能否完全适配用户的需求
唯一的方法就是通过不断尝试找到每个类型的企业的偏好。而这里按照惯例，我们的核心试错方法是MVP模式。
问题：在MVP开发过程中，MVP模式耗时的最大症结就在于后端开发时间过于冗长。
子主题
这个现象其实也容易理解，对于后端模块开发，我们不仅需要完成业务逻辑代码的编写，还需要去考虑如何存储数据、如何完成数据读取等一系列的数据结构化管理工作，所以难免耗时比较长。
在C端市场，我们利用MVP模式进行市场尝试，尝试成功之后将产品推广到全市场，依靠用户规模来拉低我们的试错成本
在B端软件开发过程中，这种模式似乎出现了一点问题。因为就算你完成了市场验证，证明了这个模块是适用于这类型企业的，但是同类型的企业量是相当少的。不同类型企业的五要素关系不同，企业的组织形态就会千差万别。
B端中台建设目标：
1、为定制化产品研发提供统一支持
2、B端业务的低成本快速试错
1、为定制化产品研发提供统一支持
2、B端业务的低成本快速试错
怎么设计中台？（how）
中台全局建设路径概览
子主题
市场宏观认知
调研整个市场发展的现状与整个市场中用户需求的变化情况
需要找到企业现在与未来的核心方向，这个核心方向就是大家经常听到的“北极星指标”，也正是这个核心方向为我们奠定了整个企业的商业模式基础。
Part 1 企业外部调研
行业研究：（1）研究公司产品背后的细分行业现状是什么，公司整体业务在行业中所占地位，以及未来行业发展趋势是什么；（2）研究公司的目标市场是什么人群，基于什么场景，通过什么方式，解决什么问题。
子主题
Part 2 企业内部调研
商业模式：调研企业是如何达成商业目标的。
用户研究：汇总企业内部各业务线对中台的需求。
子主题
企业标准化
在企业标准化这个阶段中，我们需要对企业的各个业务执行环节进行程序化改造，将以往的混乱且松散的工作流程与口头交流反馈的模式进行梳理，从而权责清晰且每个执行环节都有可量化的指标，为中台的建设打下基础。
，很多时候企业建设的中台根本不能达到原来设想的效果，往往在企业内部出现的现象是中台建设一套、业务线自己建设一套，中台反而成了一个没有实际服务对象的额外产物。
很多时候前端业务线的工作本身就是非流程的，这里常见的就是一些公司中的运营岗与销售岗。
例如，销售拜访完客户，往往只简单反馈了最终结果，很多与客户访谈中的信息都丢失了，此时大家所有工作完全是按照速度优先的原则而进行。更有甚者在组织运营活动时，在成本统计流程中很多时候都不走系统，往往只在汇总时才手动形成一份成本开支报告并上传给领导。
员工不仅没有享受到原来信息化系统应带来的对工作的帮助，反而让信息化系统成为业务部门的一个额外工作任务。所以中台建设的前提就是梳理好这些问题，改变系统与业务对立的现状，真正发挥系统的价值。
从这个意义上来说：中台的建设肯定会是互联网企业内部的一次管理升级。中台建设不仅仅是建设一套系统，更重要的是通过系统的建设完成了企业内部的自我升级！
我们要确定整个中台为企业将提供哪些服务，从而明确中台的需求边界。
大体上，需求可以划分为业务需求与数据需求两部分：
业务需求。针对各个业务方提出的需求，中台产品经理要思考如何进行抽象与归类才能实现整体的业务目标，并以此得出统一的标准化能力，从而支撑若干个企业内部的业务方。
数据需求。依托于用户产生的数据进行分析，从中提炼出用户的真实反馈，来帮助业务端优化产品和提供更好的体验。
解决方案设计
核心是确定中台的以下两个关键模型
模型1：业务建模。业务建模主要通过上一步梳理出的标准业务流程模板，将企业中的各系统、各功能的运行所需的支撑能力确定下来，初步梳理出整个企业的中台通用模型，产出中台的基本能力框架。
模型2：特征列表。面对不同业务线的个性需求，要建立起特征列表去收集，在这些特征中分析共性部分进行建设，从而让中台尽可能多地服务不同业务线。
具体建设思路拆分为这5步：
核心场景剥离：将公司的整个业务进行分割，确定业务的核心场景与用户流程。
核心业务拆解：对每条业务线进行拆解，得到每条业务线在核心场景中提供的服务与对应的功能模块。
核心业务流程确定：对每条业务线进行拆解，得到每条业务线在核心场景中提供的服务与对应的功能模块。
基础服务确定：从核心业务流程向外剥离，将功能划分为基础服务与前台系统两部分，将中台与每个前台业务系统分割开。
[插图]中台能力输出：在确定好每个基础服务的边界后，我们需要对基础服务进行一些处理，以保证能力可以适配不同的业务前台需求，不会由于客户端不同导致前台业务无法使用，提升中台服务接入的兼容性与扩展性。
我们可以根据企业的现状选择中台方案的范围——是只建设业务中台方便企业组织研发，还是建设数据中台帮助企业进行高效率的数据化运营。
宏观市场探查
宏观市场分析
宏观市场定义
以一个企业所处的外部环境为研究对象，研究整个产业的变化对其中各个细分领域的企业会有哪些影响。
看一些外部事件会对我们的企业产生哪些影响
不能像负责单独产品线那样去进行市场上出现了哪些新的产品、竞争对手的产品又有了哪些新功能等这些只专注于产品设计层面的对比，而是要关注贸易战等外部事件对整个互联网产业会产生哪些影响。
两个方向
方向1：分析公司当前业务的前景
方向2：寻找下一个业务发展点。
最常见的做法就是业务多元化
腾讯是做聊天软件起家的，后面却扩展至视频、新闻、游戏、电商等众多行业；
做杀毒软件起家的360还去做了手机。
企业为了规避单一业务的风险而主动将自己的业务进行多元化，同时也可以规避整个行业的系统性风险。
我们要去研究未来企业如何发展才能赚钱，而在这些能赚钱的方向里，哪个又能赚大钱。
对中台建设起到两个作用
熟悉业务与行业基本玩法
例如，我们去做医药电商的中台产品经理，此时我们要思考企业应怎样完成电商的成交总额（GMV）指标。我们还能像以往的电商那样，去梳理爆款药品、向用户每天推送爆款药品活动、让用户购买时下最流行的药品吗？这显然是走不通的。
预判企业下一步的业务发展方向
最担心出现的情况就是当我们将某部分功能变为企业级的通用模块后，企业业务却转型了，原先的模块不再需要了
宏观市场分析通用框架
子主题
子主题
企业产业链分析
因为企业的业务发展都是在产业链上下游进行的，所以搞懂产业链也就为我们预判企业业务发展方向打下了基础
可以从企业经营的业务流程出发，一步步追溯在该行业中完整工作流程是什么样的。
举例
子主题
子主题
子主题
预判企业业务发展方向
预判未来企业业务会怎么发展，从而让中台在建设中可以根据企业的前进方向确定不同阶段的研发重心。
例如，作为一家电商平台，企业下一步的业务多元化战略会是选择涉足会员电商，还是要涉足直播带货模式？
方法1：判断产业链中是否有优势方向
对近期 IPO企业所在的行业与投融资焦点行业这两份名单进行交叉对比、得到结果。
每段时间的IPO名单都反映出这些企业的业务方向是受政策支持的
如果说IPO名单反映了政府对国家经济的宏观调控方向，那么投融资的焦点方向就代表了市场这只“看不见的手”根据资源配置理论所做的选择，那些在近期得到大量投资的企业背后的方向就是在市场视角中被认为有高价值的。
如果我们将这两个方向与我们行业价值链的各环节进行一次交叉对比，我们就能快速得到既受政策支持又受投资人（或者说受市场）追捧和青睐的业务
子主题
方法2：判断候选方向是否值得进入
判断该方向的投资回报率是否足够高
判断这个新业务方向是否值得我们进入，我们的核心方法就是判断市场集中度情况，如果目标方向中70%的市场份额已经被头部两到三家企业所占据，那么这个方向就属于高度饱和的方向。
方法3：对比国外同行业发展
很多（大部分）行业参考国外行业的当期状态，就能大概看到这个行业未来5年左右在国内会发展成什么样子
我们在互联网一些行业其实已经领先于国外的发展，比如扫码支付等，这些在国外确实没有什么参考
比如，国外的影视行业巨头Netflix公司出了一个新的互动剧系列，就是让用户可以自主选择剧情，帮助主角进行一个决策，如到底要走哪条分叉路，从而引申出新的剧情和支线。
宏观市场分析经验技巧
日常分析中肯定会遇到想要查某些数据却没有办法直接查到的情况
（1）近似替代+比例估算
一个行业中我们知道大概前20家企业的总收入，这个时候如果我们能推算出这些企业占整个行业的收入比例，我们只需要两者相除就能估算出整个行业的规模。
要查某个行业的总规模，但是可能我们找不到直接的数据，能查到的只有规模以上企业的收入数据。这时虽然它不是整个行业的总体规模数据，但我们在这种情况下可以去做一个近似的替代
（2）升维估算
我们要查一个行业的总体情况数据但没有办法直接查到，此时在只有细分领域数据的情况下我们还可以使用升维来估算
假设我们要统计全球电商的市场规模是多少，此时我们的估算逻辑就是先调查中国电商行业规模，再想办法查出中国市场占全球市场的比例，升维估算出全球行业的市场规模
对于中国电商行业规模的数据，我们可以在电商协会发布的行业报告等文件中去查找，这个时候再通过一些经验数据，比如说通过专家访谈所得出的中国电商规模占全球的比例，再通过简单计算就能得出全球市场的电商总规模了。
企业商业模式探寻
更重要的是我们要找到企业自身的商业模式运作流程，也就是中台的核心流程。
商业模式简单来说是企业创造价值、传递价值、获取价值的方式，它不仅包含了整个企业的盈利模式，还包含了对产品如何进行成本控制
子主题
子主题
子主题
中台用户研究
用户研究的目的是让产品经理在脑海中对产品的目标用户有非常具象和清晰的认识：我们都有哪些用户？他们各自是什么样的人？他们在各种产品面前会是什么样的反应？
子主题
中台用户研究行动点
业务完整流程各节点直接关系人：产品经理、运营经理。
业务支持研发人员：项目经理、架构师。
公司高层：CEO、CTO、业务线负责人。
业务支持研发人员：项目经理、架构师。
公司高层：CEO、CTO、业务线负责人。
针对一线业务运作流程人员的以业务熟悉为主题的访谈（这里优先选择在商业模式中处于关键环节的业务流程参与人员）。
针对业务支撑生产人员的以梳理现阶段IT资源为主题的访谈。
针对公司高层的以确定中台建设方向为主题的访谈。
针对业务支撑生产人员的以梳理现阶段IT资源为主题的访谈。
针对公司高层的以确定中台建设方向为主题的访谈。
子主题
本质就是在研究下面市场四要素的传导效应。市场四要素：宏观环境+行业动向+竞争对手的变化+用户需求发展
通过分析市场四要素，我们就能快速定位企业自身的商业目标达成主要受什么影响。
预建：业务标准化
企业在中台建造前要如何对公司内部的运营模式做一次效率升级，让业务标准化。
组织结构的中台化改造
子主题
在业务方的需求开始增加之后，各条业务线不断地向测试部门提交测试需求，此时出现的现象就是测试人员不得不在业务线之间不停地切换，而频繁切换部门会大大提升人员重新认知的时间成本，这样既不能保证测试质量又无法提高测试速度
子主题
此时我们也达成了将公共的底层技术能力研发与前台的业务逻辑研发分离的目的。这也就是标准的中台架构：让前台业务通过中台去接入各种公共服务。
[插图]前台业务研发人员：负责响应一线客户的需求，目标在于实现业务目标，较少考虑系统性能。[插图]中台研发人员：负责维护工具。有了这么一群专职的人员，就可以撇清烦琐的业务需求，每天的任务就是研究如何使用这些工具，使其性能最优化以提供给前台研发使用。[插图]后台研发人员：负责底层物理机器的管理与支持和技术架构选型的研发。
业务流程的中台化改造
就是将业务中我们要进行的各个环节找寻出来，从而将一个非常抽象的业务定义为由若干个标准动作加关键节点所组成的程序化流程
保证我们在设计中台的时候，能站在业务方的角度去考虑哪些核心能力是业务方所需要的。
业务抽象归类
泛产品架构
子主题
业务程序化
子主题
子主题
子主题
子主题
业务线的核心公式
想办法对这些业务进行量化，以便我们能把握住这些业务的核心。
假设我们要对地推人员的订单达成（以下简称“成单”）这一动作进行动态跟踪，那么要如何去拆分地推人员的成单指标呢？
地推人员的成单率=（客户线索数×转化率）/客群总数
成单率2.0=（A类客户线索数×A类转化率+B类客户线索数×B类转化率+C类客户线索数×C类转化率）/（A类客群总数+B类客群总数+C类客群总数）
子主题
设计成功中台的核心原则
原则1：独立的中台研发团队
兼任型研发模式最大的弊病就是当团队对业务进行抽象建模的时候，会无意识地参照当前团队业务进行设计，在中台建设中我们适当地参考当前业务线的发展是有必要的，但是如果完全根据某条业务线的需要去设计中台模块，就让中台丧失了本身的价值。
（1）必须有高管介入
一个成熟的中台团队应该采用这样的编制：
角色1——高管：负责中台大方向定义与公司内部资源协调。
角色2——中台产品经理：负责中台业务范围定义并确定项目演进方向。
角色3——中台技术人员：负责落地中间件服务的开发实现。
角色1——高管：负责中台大方向定义与公司内部资源协调。
角色2——中台产品经理：负责中台业务范围定义并确定项目演进方向。
角色3——中台技术人员：负责落地中间件服务的开发实现。
日常工作模式，
就是由一到两个产品经理带队进行全公司业务调研，
由高层参与进行障碍扫除，
再由独立的前端与后端开发人员进行中台产品的研发与迭代。
就是由一到两个产品经理带队进行全公司业务调研，
由高层参与进行障碍扫除，
再由独立的前端与后端开发人员进行中台产品的研发与迭代。
（2）与业务线建立沟通机制
对此我们可以使用周报汇报机制来实现沟通。周报以业务线新增需求与规划需求为核心内容，具体包含业务线当前周的版本计划、版本中的重要功能、下一阶段规划的功能3部分内容。
原则2：中台建设需求边界管理
划分出中台建设的3个方向
方向1：复用化
对于原来嵌入某个具体业务的模块，对其中的特殊部分（也就是原有的业务信息）进行剥离，使其变成一个公共的模块并且与业务没有任何关系。
方向2：标准化。
将剥离出来的模块与之前调用的业务线进行内部统一，使其变为多条业务线在操作同一事物。同一事物的名称、属性都能保持一致。
方向3：能力化/接口化
通过对剥离出来的模块进行设计，使其拥有接收外部输入信息与向外传送该模块计算结果的接口。通俗来说就是接口化。
确定需求大纲前的2个准备动作
业务需求与数据需求的边界
业务中台与数据中台的本质区别就是对同一个事物中的业务数据与描述数据分别管理。
中台建设中一个重要的原则就是要针对不同的模块分清楚业务数据与描述数据。
业务数据。
所谓业务数据就是指用户在使用系统时必须输入的信息和得到的信息。举例来说，在支付环节中每笔收入都会产生对应的现金流动，而此时收入数据就处于我们业务中台的需求范围。
描述数据
这类数据就是我们用来描述业务发展好坏的参照物。例如，对于企业来说，无论属于哪一个行业，市场评价其业务好坏的指标只有两个，那就是收入与净利润。
例如，在上面的例子中，在支付环节中我们的业务数据是收入；而在订单模块中我们的业务数据应该是用户所要购买的商品与下单数量、地址、送货时间等，而此时的收入数据又变为描述数据，用来描述订单这个模块的转化率的高低。
中台需求分析边界定义
两种思维方法
演绎法
演绎法又称自上而下分析法，是人们以反映客观规律的理论认识为依据，从符合该认识的已知部分去推演事物的未知部分的分析方法。
自上而下：通过分析现有公司内的业务与各个模块来向下拆分中台应该覆盖哪些内容。
缺点在于其时效性特别低且成本特别高，所以经常被称之为“后发式”的建设模式，即企业中的中台建设都是在进行第二遍的开发，
归纳法
归纳法又称自下而上分析法，是人们以一系列经验事物或知识素材为依据，从中寻找出其符合的基本规律，并假设同类事物中的其他事物也都符合这些规律，再利用这些规律去预测其他事物未来发展的一种认知方法。
自下而上：通过将现有业务中的各个模块进行不断归类来向上统一抽象出中台架构。
最适合企业在发展现有业务的同时去搭建中台的模式。这种模式不需要进行二次建设，节省了成本，因此绝大多数的企业在建设中台时都使用这种模式
现有业务的能力抽象
中台业务场景分析
对当前全公司的产品线做一个动态的产品画像，来判断目前各业务的核心价值在哪里。
对于任意一款产品，当我们站在战略层面去看时，其产品画像可以分为两个维度。
（1）各产品在产品线中的定位
前置条件，就是摸清楚公司当前的商业模式是如何落地实现的。
子主题
为了满足这种架构，我们需要对自己的产品线进行合理的规划，谈到产品线布局，这里我们就要提一个非常著名的三级火箭理论。
子主题
子主题
第一级，流量获取：通过给用户补贴抢占市场，建立起稳定的流量供给渠道。第二级，流量留存：将流量用户沉淀至可拓展的高频商业场景中，实现产品方向的演化。第三级，流量变现：推出核心付费环节，开始盈利。
举例360
第一级火箭：做了免费的安全套装。
第二级火箭：引导用户安装360浏览器。
第三级火箭：通过导航和搜索盈利变现。
举例微信
例如，微信在刚推出的时候，从某种意义上是以免费模式向旧时代产品——短信服务宣战，结果也很鲜明——微信以摧枯拉朽之势完成了主流通信市场的抢夺。而这个时候很多人开始担忧微信会不会收费，但实际上现在我们再来看，微信完全是将聊天功能作为火箭模型的第一级以获取与留存用户，而在朋友圈广告、支付等其他板块进行产品导流的。
举例蚂蚁森林
例如，支付宝推出蚂蚁森林板块，这一板块与支付宝的主营业务个人资金管理无关。但是这一板块却在很大程度上扩大了支付宝这个App的使用场景。例如，很多用户只将支付宝作为一个理财工具，所以会存在这样的现象——这群用户两到三天才会上线看一次自己的收益或者有些用户一个月才会上线一次去管理自己的资产。而一个C端产品如果不能让用户投入更多的时间在自己的平台上，那么就意味着用户不可能为这个平台带来很大的价值。但是支付宝通过蚂蚁森林这种随时随地都可以参与的游戏功能，将用户的低频操作（如资金管理、支付等）转换为了相对高频的操作。这样大大提高了用户的留存率与黏性，为应用内部其他部分的用户变现板块带来新的可能。可以说，蚂蚁森林这类的非支付业务板块就是支付宝整个火箭模型中的第二级火箭，用以流量留存。
子主题
（2）各产品的用户群情况
在不同的时期我们需要用户去做不同的事，产品刚上线时希望第一批用户尽可能多地使用产品并发现产品的问题，为后期大规模引进用户夯实基础，这里的核心指标就是产品体验度。而发展一段时间后有了足够的用户量，此时我们希望用户尽可能多地使用我们的付费服务，比如购买会员、点击广告等，从而达成我们的盈利目标，这里的核心指标就是付费。
用户的核心价值指标：核心价值指标=当前产品阶段识别+用户应达成目标
子主题
子主题
子主题
子主题
对陌生业务快速熟悉的方法：5W1H分析法
子主题
子主题
业务中台化抽象
深入各条业务线的内部去研究各个组成部分，也就是对每个产品的功能模块进行挨个拆解，从而得到我们公司的颗粒度最小的基础单元，为下一步中台业务数据模型提取做好准备。
因为在现在的公司中一个产品的各个模块实际上是由不同的团队进行研发并最终合并成一个App的
举例来说，在电商内部，为了实现用户去搜索商品这一个功能，背后至少需要有商品中心、搜索中心、订单中心、库存4个团队交织参与才能完成。
在中台建设里广泛存在这两个问题
添加的需求为了能适配不同的前端业务线，不能是具体的功能而应是能力
我们要将哪些功能添加到中台的需求池中，避免将中台建设为另一个“小后台”
解决问题的方法就是对各条业务线的功能进行拆解，拆解出一个个的能力
例如，对一个商品模块，我们可以拆解出商品品类管理能力、价格管理能力、商品标签管理能力这3个能力。
使用动作分析法来进行拆解工作
子主题
子主题
举例
子主题
子主题
下一步通过将各个节点中不同角色的输入、输出进行统一，我们就能很快找到整个系统中我们所需要提供的最密集的能力是什么
案例：地图应用抽象
中台方案框架
根据抽象结果代入到中台方案框架去生成适合自己企业的中台方案
子主题
子主题
将业务体系按照MECE（Mutually Exclusive Collectively Exhaustive）原则来划分一下
业务中台实战
企业架构
子主题
组成
（1）业务架构
我们公司的整个业务运转模式是什么
业务架构包含运营模式、组织结构、生产流程等内容
比如我们是一家饮料生产公司，我们是如何将水、糖等配料最终制作成一个带有包装并印有公司标识的饮料，并实现从工厂交付到用户手中的整个流程的。
（2）IT架构
IT架构就是指面对企业的业务架构，我们要如何联合这些信息化系统建立起一套标准的系统群去帮助企业实现更高效的内部管理运营，
企业用于建立企业信息系统的施工图纸
这里IT架构由数据架构、应用架构和技术架构3部分组成，通俗理解就是对应公司中的业务数据、前台产品与代码。
和中台的关系
本质上我们新建的中台属于企业架构中IT架构层面的产物，
之前划分出的数据中台、业务中台与技术中台对应企业架构里IT架构部分的数据架构、应用架构与技术架构，
之前划分出的数据中台、业务中台与技术中台对应企业架构里IT架构部分的数据架构、应用架构与技术架构，
子主题
中台系统在企业信息化中是承接前台应用与底层系统的重要桥梁，它的定位就是帮助前台业务封装底层系统接口并形成一个中间层
业务中台建设的启动
建设模式选择
分布替换式建设
对业务系统内的模块一次一个地进行改造重建，最终将所有综合架构实现中台化
优缺点
这种建设模式的好处是可以不断根据业务需要进行抽象
坏处也是显而易见的，就是整个业务中台完成建设的周期将比较长
现在很多启动中台建设的公司一般都选择了这种模式。
完整式建设
从企业中单独开始建设业务中台
先保留原有的业务系统并使其正常运行，再单独启动一个新的项目，逐步沉淀原业务系统中的代码与成熟业务，
在完成中台建设以后，保持业务前台不变，将中台作为一个新系统嵌入原有的IT架构，并让原来前台业务与后台的接口调用关系逐步由中台接替，来实现整个IT系统的改造。
优缺点
这种模式的好处是一切从零开始建设，对于中台研发人员来说可以快速完成代码实现而不需要去梳理其他业务代码
不过缺点是我们需要单独用一套系统从零翻新公司的所有项目，建设成本比较高。
中台用户优先级
子主题
判断中台需求优先级的基本规则
规则1：业务线优先
规则2：需求共性程度
业务中台建设路径
公司内电商业务分为多条业务线——海淘业务线、自营业务线与第三方商家业务线，此外有一家独立的线下体验中心
必须在以下两个层面完成统一性的整合
功能流程层面整合：定义三者业务的统一的业务模型。
业务数据层面整合：找出可以对通用模型进行业务描述的基本数据。
1、公司全景功能地图
将公司的各条业务线中的模块进行统一汇总，查看到底每条业务线有哪些模块，其业务线之间的重叠情况又是怎么样的
子主题
相似度=（相同输出通道数+相同输入通道数）/总通道数
我们计算出它们却是高度相似的，可以计入一次预复用。
所以根据这个公式，如果预复用超过两次就有一定的必要去考虑是否可以中台化，需要业务中台建设团队将其抽取出来进行统一维护。
子主题
2、核心业务流程抽象
如何根据现有业务建设一个通用模型，以便可以支持不同的前台
通用模型的建设在本质上是建设起全公司业务的一个通用流程，而不是简单地将业务线中的公共需求模块进行堆砌，也只有这样才能让中台的能力边界可控
通用模型的建设方法就是从企业的业务出发去设计一个大体的模块框架，其承载的是我们的核心业务流程。就像面对一棵大树一样，业务中台负责的只是整个躯干的维护，而具体的枝叶由各条业务线完成。
子主题
子主题
子主题
根据上面分析的业务流程，我们可以把商品查找、购买决策和售后管理这3个流程中的功能细分下来，得到标准业务框架，
子主题
可以梳理出4个我们公司中的核心能力，分别为用户中心、商品中心、交易中心、客服中心，
子主题
我们可以进一步将这些核心能力拆分为公共模块与功能点，得到1.0能力开发大纲
子主题
子主题
3、企业级数据模型搭建
完成了功能流程级的整合，我们的业务要怎么和你的中台挂钩呢？
要做的就是在数据层面上让各条业务线能接入中台
所谓企业级数据模型，是一个企业中的业务规则以及信息管理，
也就是说我们的一个完整业务（如下单流程、配送流程）可以被描述成需要用户输入哪些信息、确认哪些信息，并在什么样的信息筛选情况下，可以让用户完成一次业务活动。
也就是说我们的一个完整业务（如下单流程、配送流程）可以被描述成需要用户输入哪些信息、确认哪些信息，并在什么样的信息筛选情况下，可以让用户完成一次业务活动。
值得注意的是，这里和之前的不同，是不再以模块来看，而是看整个流程中用户的所有输入、输出信息。
接下来我们就将看似不同类型的业务场景抽象出一个通用的数据描述
子主题
收集完不同业务线的实体之后，我们便可以将其进行统一归类以便形成统一的对象
子主题
再下一步我们要做的就是搞清楚在日常业务中这些对象都是怎么联系身边的其他对象的
子主题
继续在这个数据对象通信图上进行整理，我们将各个对象主体之间在访问时需要传递的数据汇总一下，就得出了一个完整的企业级数据模型
子主题
子主题
进一步将这里的数据模型与之前标准业务模型拆解结果合并，就可以得出业务活动的本质就是：在什么样的场景下开始执行任务（事件），模块需要哪些数据（实体），依据什么样的顺序、规则进行处理，处理之后与哪些对象（实体）产生联系并产生了哪些数据。
4、业务中台中间件研发
中间件就是一个公用模块，能供不同的前台调用
为了使不同的业务线都能使用这个模块，我们要做的中间件研发的核心就是进行字段的剥离。
将原来前端业务线中的数据存储拆分为两部分：数据存储=通用数据（中台）+业务数据（前台）
所谓通用数据，就是指能客观描述对象的一个字段，也就是现实世界中能唯一确定这个个体的数据，例如会员模块的通用数据为用户姓名、身份证号、手机号、用户性别、ID、年龄等
而业务数据是指在各个前台里根据具体场景里的特殊化需求所定义的字段，如用户昵称、用户在本业务中的会员等级等。
在完成这样的数据分割之后，我们就可以将每次访问系统产生的数据分为两部分，
将通用数据存储在中台，
而将个性化的业务数据依旧存储在前台，形成数据分离存储的模式。
将通用数据存储在中台，
而将个性化的业务数据依旧存储在前台，形成数据分离存储的模式。
子主题
接下来我们就需要批量对原业务中的模块调用关系进行梳理，来规划出前台业务线与原后台的调用关系业务流
子主题
在有了调用业务流后，我们进行前台模块重构。
此时按照如下两个原则：
1、将公共字段统一汇总至中台。
2、前台业务只留存个性化部分。
1、将公共字段统一汇总至中台。
2、前台业务只留存个性化部分。
此时完成前台模块的输入、输出重新分离后，我们就得到了一个中台中间件，就可以开始让前台业务线通过这个中间件接入业务中台了
5、对接后台业务系统
先看一下我们现有公司中所有后台系统
子主题
第一步需要挨个梳理这些后台系统与原先业务系统的调用关系是什么
子主题
这里的3个业务前台都直接与后台系统关联，结果就是典型的底层系统既要处理繁杂的业务流程又要去管理与前台业务的对接
第二步就是将原来参与前台调用的数据通路转接至业务中台上，由业务中台实现前后台对接
子主题
我们就将业务中台成功插入了前后台之间，并在这两者之间建立起了一个封装层，使得后台无论有什么变动都不会影响到前台业务
同时也让后台系统不再管理具体业务，
例如对于后台WMS来说，不用再将商品区分业务方，它要做的就是忠实地记录商品进出库，无论是海淘还是自营的商品，对WMS来说都只是一个SKU，而将商品归属业务方的需求交由中台进行。
这样后台只负责处理底层逻辑，砍掉了多余的业务关联
6、业务中台的最终架构
子主题
在案例中，我们将整体业务中台系统定义为用户中心、商品中心、交易中心、支付中心、客服中心这几个大的通用模块
子主题
7、业务中台需求管理
子主题
当我们需要精准设计一个中台需求的时候，需要指出这个需求的哪几个关键要素？
对象
在中台需求设计中切记我们不能脱离需求对象，因为很多时候中台的需求都是为从不同业务线提炼出的通用角色而设计的，如果我们无法精确定位需求对象，做出来的功能就很难在不同业务线进行复用。
场景
明确该业务的使用范围，从而在中台建设时能清楚定义需求服务提供的能力边界。
原始需求
标准需求
技巧
业务中台需求鉴别
以下两种情况坚决砍需求
影响业务中台定位的需求
对于业务线中一些非常个性化的流程需求，当其明显与业务中台的核心定位相冲突（服务整个公司）时，我们要非常谨慎地进行思考
影响用户体验的需求
有时候我们设计的功能可能为整个系统的性能及效率带来一定的提升，但是如果这些需求依赖着非常高的用户学习成本，
我们应该放弃这样的系统需求，因为我们的产品所服务的是真正的用户，而非系统人员。
版本迭代计划安排
中台作为一个公司级的基础服务要注重稳定性，不能发布过于频繁
对于早期功能重构类的版本，为了能快速试错，可以适当提高发布频率
而在中台功能稳定后，我们需要考虑全公司的业务稳定性，此时需要尽可能在一个版本中上线多个功能，从而降低发布频率。
举例
在早期每两周发布一个小版本，在中后期稳定时每个月发布一个大的版本。
8、业务中台路线图
划分出3个版本
子主题
中台的接入分为3个阶段
我们将中台的接入也分为3个阶段：阶段一为流程验证期，阶段二为全面接入期，阶段三为运行迭代期
子主题
业务中台建设KPI
要有对应的指标去考核业务中台建设的成功与否
业务中台的效果验证性指标包含两个指标：模块复用率与业务开发TTM。
指标1：模块复用率
子主题
指标2：业务开发TTM
TTM（Time to Market），一般指产品上市周期。而在这里我们可以衍生一下TTM的定义：一个软件模块从立项研发到最终上线所需要的时间。
原模块研发所用人日-业务中台化研发该模块人日=节省的人日
总成本节省=（业务1节省开发成本+业务2节省开发成本+…）-业务中台开发成本-业务方迁移至中台成本-中台系统运维成本
数据中台实战
如何设计能监控整个业务体系的数据中台。
前言
子主题
正确的产品生产流程应该是我们在生产产品后，在市场的反馈下及时纠正我们的发展方向并完成迭代，从而尽量让更多的用户满意
子主题
而如果在初期不建立数据监控体系，公司的运作模型就会是畸形的，
一切投放用户市场的产品，都需要有来自市场反馈的声音，否则就是设计者在“自嗨”。
传统用户数据采集方式
子主题
数据中台就是将多条分散业务线的数据进行汇总从而进行整合使用的数据系统
子主题
通用的系统具体化思维方法
子主题
战略目标
数据中台建设总思路
要找一个【数据工具】来帮助我们去判读怎样的业务才是好业务
关于这里的工具，我们就需要用到【数据指标体系（指标+事件）】，而数据指标体系的意义就是让业务变得可评估、可对比与可拆解
而建立数据指标体系的最重要的前提就是找到整个公司的【核心指标】，也就是我们的业务目标
用来衡量产品/平台的前进方向的。
要设计一个靠谱的数据中台时，其成败的关键就是【数据指标范围选择的好坏】，只有真正选择出有参考价值的数据指标才能真正将产品变为闭环设计。
数据指标范围选择
子主题
选择一个合格的北极星指标
到底什么才是我们的业务核心
你最想让用户在你这儿干什么。
参考产品目标设计的经典思路
产品设计者必须弄清楚自己的产品与用户“博弈”的是什么。而这里的“博弈”指的就是用户的本质诉求与你提供的解决方案间的博弈。
从这3种博弈中我们只能选择一种作为本产品的核心价值，并在该方向上去发现我们的业务指标。
比如我们选定了注意力博弈，那么对于对应核心指标的选定，我们就应该围绕应用中最能吸引用户的指标。
举例来说，新闻资讯平台想让用户浏览阅读，视频网站想让用户看视频，而不是去商品比价或者搞什么视频评论等衍生需求。
在找到产品的核心价值后，接下来我们就要开始思考什么指标可以衡量其好坏
视频平台：关键视频播放次数。
社交应用：单用户日均发言数
社区平台：用户发帖数、回帖数。
电商平台：用户下单量、客单价。
举例
实际上商品、会员、订单、购物车、物流等这些模块在本质上都是在维护“货”和“人”这两个对象的关系。
到这儿我们也找到了数据中台基本的两类数据元素，后面所有的分析都要基于这两者，此时我们也称之为唯一关键指标（OMTM）。
对照电商内的功能可以发现，
1、对于“货”的管理实际上分品类管理与库存管理两个部分，
2、而对于人的管理在本质上就是在关注整个系统的销售额有多少。
1、对于“货”的管理实际上分品类管理与库存管理两个部分，
2、而对于人的管理在本质上就是在关注整个系统的销售额有多少。
所以在“战略目标”这里，我们就得出了这样的结论：要能展示“货”和“人”的发展情况，
子主题
拓展理解“货”和“人”
子主题
阶段目标
定义出这些数据指标体系需求具体要分为哪些部分，又要按什么样的阶段去分步达成
我们会将数据指标体系需求分为两部分：直接采集后的统计数据与特定事件分析结果数据。
1、统计数据
没有过多的运算逻辑，只需要基本的统计。我们将这类的数据称为数据指标。
梳理数据指标的步骤
1、指标建设：依据公司内不同层级人群的指标需求进行归类
层级一：战略指标
衡量公司整体业务的完成情况
选取与业务密切关联的，并且是整个行业中进行企业间对比、参考时所用的指标
在数量上，我们不要有过多的战略指标
拆分原则
能否涵盖整个公司的战略目标
举例
例如对于电商公司来说，战略指标可以分为GMV、用户数、总利润等这类企业的宏观数据
层级二：战术指标
公司中支撑这些战略目标的具体业务的进展情况
例如企业为了完成一级指标肯定会做出对应的业务部署，
如成立相应的业务线或成立相关的研发小组等。所以我们面对这里的指标就要去考量各业务线目标完成情况
如成立相应的业务线或成立相关的研发小组等。所以我们面对这里的指标就要去考量各业务线目标完成情况
拆分原则
能否反映公司战略目标的承担者（也就是各条业务线）的业务进展情况。
举例
以电商公司中的订单中心为例，这里的战术指标可以定义为总订单量（支付订单量+未支付订单量）、总订单支付金额。
层级三：行动指标
可以指导具体一线工作的人员（例如产品经理或运营经理）开展下一步工作的指标
拆分原则
能否帮助我们在第一时间发现具体业务环节所出现的问题
举例
还是以订单为例，行动指标可以选定为订单付款转化率、订单付款后取消率。
子主题
2、指标细分：进一步地完善和细化数据指标，从三个维度思考
维度1：业务目标
用户使用本产品的目的是什么？我们要给用户提供哪些服务？
举例
用户核心需求：寻找并购买目标商品。
维度2：实现方式
我们通过怎样的产品设计来达成上述目标？
举例
电商平台提供的功能：商品类目浏览、商品详情浏览、支付购买、物流配送等。
维度3：业务度量
我们用什么指标去考核这些产品功能是否达成对应的效果？
根据用户的行为事件将指标划分为过程类指标和结果类指标。
过程类
用于衡量用户在进行某个事件时的具体情况
关注用户在哪个环节出现了问题
举例：用户过程事件点击率、用户浏览页面深度。
结果类
用于衡量用户完成某个事件之后的效果，这类指标通常是后置的，也就是只能用来定性结果好坏
结果类指标更多是去监控整个业务的最终效果是否达到预期目标
举例：某类事件发生数、完成率等。
举例
过程类指标：商品浏览数量、页面跳转层级、订单触发率。
结果类指标：订单支付率、订单总数。
结果类指标：订单支付率、订单总数。
除此以外，其他客观条件维度
还需要结合不同的产品载体、设备终端、业务线等客观条件
举例
例如，对于订单这一指标，继续从如下几个维度拆解
子主题
子主题
一个好的指标应该满足这几个要求：可准确反映业务情况，数据易收集，准确度高。
2、事件分析
事件分析指对特定的用户行为进行过程化的分析，从而得出定性的结果去指导下一步中产品要怎么做。
从具体的监控系统实现角度来看，数据事件就是将前面的一堆数据指标按一定顺序进行组合所形成的一组数据指标
举例
例如用户注册转化事件，就是由登录界面的注册点击按钮触发次数、注册页面信息填写完成率、最终提交注册率3个指标按照点击流程组成的。
任何数据分析事件在本质上就是帮助决策者完成一个决策工具，需要建立起一个能帮助产品经理去决策当前产品发展到什么阶段了而下一步又要去做什么的工具
如何快速定位产品当前在市场中所处态势。（是什么）
如何找到当下产品中症结所在。（怎么了）
带领整个团队确定产品下一步应该怎么走。（怎么做）
如何找到当下产品中症结所在。（怎么了）
带领整个团队确定产品下一步应该怎么走。（怎么做）
产品数据分析思维流
子主题
执行战术
1、生命周期分析
举例
判断电商平台当下到底处于产品生命周期中的什么阶段
事件：判读产品当前态势
子主题
子主题
2、活动单元分析
事件：阶段中短板单元判断
子主题
3个态势中，各自的产品设计导向点
1.萌芽期：拉新
主要关注的就应该是各渠道质量
两个纬度
（1）关注点：自然量
（2）关注点：什么渠道的ROI最高
2.成长期：用户留存
偏重监控的指标是留存率
3.成熟期：关键指标转化
明确关键指标
不一定是每用户平均收入（ARPU）、流量转换
还可能是由于产品在其产品线中的位置而产生的模型
落实到产品操作动作流上
例如，在电商产品中用户的操作动作流：用户功能页浏览→进入含有付费入口的页面→进入付费页→付费页底部点击支付按钮→确认弹窗→跳转第三方结算/本产品中结算→付费成功状态提示。
对流程的每一步进行埋点，找出流失率最高的环节
事件动作拆分→漏斗模型检测。
3、用户态势分析
在定位产品态势与产品薄弱环节后，接下来的一步就是要面向我们现有用户群去进行产品设计了
找准用户的“七寸”
用户静态标签
用户的固有标签，如年龄、地区、性别、所在行业
因此在数据分析系统（也就是数据中台）里，我们必须能看到一些静态标签，如基础属性、设备、应用偏好等。
子主题
从图中直观来看，年轻人偏多，我们的产品设计导向就可以是视觉丰富化，使用较为绚丽的主色调，并适当搭配形体感丰富的交互从而增加产品的活力。而高学历（本科及以上）人群较多，也让我们在用户教育方面可以适当减少工作量，从而提供更为简洁的主要功能体验。
用户的产品使用习惯
用户群体使用产品的特征，如使用时间段集中在什么时间，偏好在什么网络下打开，平均使用时间长度有多少。
4、数据分析结论
事件分析汇总
子主题
围绕事件，对指标进行分析
子主题
解决问题
子主题
找到阶段目标
子主题
通用数据模型与指标
1.通用数据分析模型
（1）漏斗模型
子主题
漏斗模型的核心思想就是分解和归类量化。用于定位产品出现问题的环节
漏斗模型的转化率比较
数据怎么看
不能说某个环节的转化率最低，就一定是因为这个环节出现了问题
前后期对比
同期对比同行业数据
三个维度分析
纵向对比
与自己历史同期进行对比，这种对比适用于对某一流程或其中某个步骤进行改进或优化的效果监控
横向对比
通过将本产品与竞品的同一流程转化率进行横向对比，定位自己产品出现的问题。
来源分类
细分来源不同的客户类型在转化率上的表现从而完成客户群体划分，在日常分析中通常用于对网站广告或推广的效果的评价。
漏斗模型的漏斗颗粒度要如何定义
在实际的场景中同一款产品会有各种各样的用户类型，比如用户来自不同的区域，拥有不同的生命周期、不同的性别、不同的年龄，他们在漏斗中的表现通常是不一样的，这也就造成了用户漏斗中的转化率往往是有很大的差异的
因此我们需要将不同的人群拆分成一个个小的漏斗去逐一分析，一点点去分析结果。
（2）杜邦分析模型
子主题
定位了产品出现问题的环节，如何具体定位一个问题指标
杜邦分析法的最大意义——能够将问题定位得更加准确且具有可操作性。
杜邦分析法
杜邦分析法（DuPont Analysis）利用几种主要的财务比率之间的关系来综合地分析企业的财务状况
当核心指标发生变动时，将抽象的指标进行拆解，将大指标拆分成若干个底层应用中直接触达的动作，去看和核心指标相关的一些变动，从而去定位核心指标变动的原因
一般来说，我们可以将任意一个指标分为3类：核心指标、子指标（若干层级）、孙代指标（让抽象的指标与App中动作进行关联的指标）。
举例
电商类产品的核心指标就是成交金额，而当在我们某次日常运营活动投放后，产品的成交金额不升反而出现了下跌
核心指标拆分：销售额=付费人数×客单价
子指标拆分：付费人数=UV×付费转化率
也就是从流量（UV）、转化率和客单价3个方面来分析成交额的变化
比如UV继续拆解
子主题
最后和产品相关的是我们本次活动用户步骤与步骤奖励数这两个指标
定位问题
步骤1.核心指标拆分及版本对比
子主题
步骤2.子指标拆分及版本对比，
子主题
步骤3.孙代指标拆分及版本对比
子主题
在反复循环后我们可以得到数据结果分析
子主题
由于我们本次活动要求用户操作的步骤过多——长达7步，用户很大程度上不愿意参与本活动，导致了用户的流失与交易金额的下降。
解决方案
需要对活动进行修改，减少活动用户步骤或者增大奖励。
2.通用数据指标
数据中台1.0架构设计
数据监控后台
我们完成了这样的两步工作：
工作1：确立产品核心指标——“货”与“人”。
工作2：确立了阶段目标中的事件。
工作1：确立产品核心指标——“货”与“人”。
工作2：确立了阶段目标中的事件。
子主题
子主题
此时的1.0数据中台准确来说就是一个数据监控的后台
数据中台2.0架构设计
如何搭建面向所有系统的统一数据分析架构体系。
子主题
技术中台实战
技术中台体系架构
技术中台层级
子主题
举例
子主题
技术中台的原理
如何搭建
子主题
最上层是展现层
这里是我们的各条前台业务线，主要为移动端和PC端，由接口层直接访问技术中台。
中间层是接口层
负责提供统一的接口体系以完成展现层与服务层间的数据交互。
下层是服务层
包含3个部分，技术前台是对【业务中台】的技术实现，【技术中台】提供底层服务，技术后台提供直接访问底层硬件相关管理。
左侧是外挂系统
负责提供不同场景的系统与我们的系统的数据对接服务。
右侧是数据运营
负责提供数据分析服务，也就是我们的【数据中台】的技术实现
后记
产品人M-P能力模型
子主题
子主题
优秀的产品经理优秀在哪里
子主题
子主题
所谓产品经理的优秀，实质上就是掌握了M-P能力模型中偏市场层面的能力，能以大局观来看待整个产品的问题
子主题
要想成为一名优秀的产品经理，我们就要在掌握了需求生产（Product）能力后，不断地去学习和掌握市场（Market）层面的知识，使自己能以企业战略角度来思考问题并去解决极其抽象的问题，将问题拆解成不同的执行方案。
0 条评论
下一页
