中台产品经理宝典：从业务建模到中台设计全攻略

刘天

内容简介

• 业务中台+数据中台+技术中台

第1章 互联网颠覆变革的出现

• 创新是唯一的出路，淘汰自己，否则竞争将淘汰我们。

1.1 互联网的上半场与下半场

• “消费互联网”下一个定义了：以日常生活为应用场景，为满足终端消费者在互联网中的消费需求而产生的互联网类型。
• 产品为王的时代。此时市场中各个企业的竞争就变为用户体验、满意度与口碑方面的角逐了，而谁能给用户带来更好的使用体验，谁就能占领市场。
• 在本阶段大家比拼的就是用户体验与差异化，谁能准确把握市场对热水壶的体验痛点，谁就能拥有市场。当然这个时代也是我们产品人的黄金时代。
• 由追求行业第一变为追求谁家的产品更能让用户满意。
• 演化为企业自身的市场运作与产品分发能力的比拼。此时行业中谁能铺货到更多渠道、品牌运作方面能让更多消费者熟知、拿下更多订单，谁就能成为市场的巨头。
• 上半场互联网在当下的产业发展阶段中实际上已经进入了市场时代并即将迎来新的技术变革，而此时我们面对的是一个市场相对饱和又缺乏创新的互联网环境。
• 产品生命周期（Product Life Cycle，PLC）
• 每个项目已经有可供参考的投资回报率（ROI）标准
• 其市场处于技术时代，其产品处于引入期与成长期，可以说具备标准的全新市场特征。
• 马太效应的体现：强者愈强，弱者愈弱
• 消费互联网：在上半场诞生，之后进入市场时代，产品普遍步入成熟期，即将进入下半场。[插图]产业互联网：新的发展领域，在整个市场上还不存在绝对巨头，市场处于技术时代，任意一家企业都有可能成为未来的巨头。

1.2 互联网上半场明星：前后台业务模式

• 每个前台系统都是用户首先对一个产品整体建立认知与产生评价的地方。
• 由后台提供能力与计算，前台将后台的计算结果进行封装，并以图形的形式展示给用户，让用户能更容易地使用公司提供的服务来解决个人需求。

1.3 互联网下半场业务模式特征

• 特征1：以企业服务为业务核心对象
• 由原来的个人消费者变为一个个独立的企业主体。
• 在上半场发展中，企业好比是在做增量市场，通过不同维度的商业创新将越来越多的用户、资源吸入互联网产业，整个业务形态就是在努力扩大互联网用户规模占市场总体用户规模的份额
• 而在互联网下半场中，则变为主要去做存量老用户的信息化升级业务
• 具体措施也就变为以提升企业运营效率和优化资源配置为核心和出发点的互联网应用和创新。
• 优化资源配置主要是帮助企业进行生产成本管理，优化供应链体系
• 消费互联网面向C端消费用户，不断开拓互联网市场边界，以满足用户衣食住行的基本型需求为目的。 产业互联网面向以往市场中的存量客户，也就是企业主体，以产业端提升效率为目的。
• 特征2：渠道中间商的新价值
• 这种局面就是因为传统渠道方依仗着控制了互联网企业还无法下沉到的市场，要求实体厂商进行利润保护。
• 出于企业经营成本考虑，决策者肯定会选择最贴合自己企业的流程的服务。
• 面向企业的产品很难要求一家企业去修改内部的组织架构、人员分工、业务模式、规章制度来适应我们软件的流程与功能
• 就面向企业用户来说，我们的业务更多是需要贴合每个企业的流程进行定制化的服务。
• 将产品与服务标准化后进行大规模推广，从而让用户所付出的人均成本得以摊薄到几乎为零。
• 表1-1 消费互联网与产业互联网对比

第二篇 剖析：中台到底是什么

• 中台就是前台业务交互单元的“航空母舰”，它以聚合的方式帮助前台快速匹配所需的能力与资源，进而实现针对用户需求变化的敏捷响应。

2.1 中台规模化元年

• 字节跳动内部将中台分为用户增长（以投放拉新解决方案为主）、技术（以算法解决方案为主）、商业化（以广告解决方案为主）和直播中台这4个部门。
• 2019年也被称为中台规模化元年

2.2 下半场对原研发模式的考验

• 事实上前后台模式反而是公司最省时、省力的一种面向新业务场景的解决方案
• 我们的产品由标准化产品变为以用户为单位的定制化产品，此时为了抢夺市场资源，每个定制化产品都需要快速迭代、落地终端。
• 功能生命周期，也就是单一功能从研发上线到再次迭代的时间。
• 前后台模式的根本弊病：响应速度太慢。
• 这样导致在公司内不同的项目不共享资源，更不能互相访问调用资源，这样的项目就像烟囱一样树立在公司内，每个项目变为一个个的资源孤岛和信息孤岛。
• 因为真正应该快速迭代的功能核心只在于前台部分，只有这样用户才能感知到，用户是不可能为你的系统底层架构建设而买单的。
• 各大公司需要的是一个最少改动底层或只开发上层就能应对绝大部分需求的新的解决方案。
• 这种公司外部需要快速迭代而内部每次迭代都需要“伤筋动骨”的冲突是我们存在发展瓶颈的根本原因。
• （2）“前台+后台”的齿轮速率匹配失衡
• 所以从这个角度来说，中台的出现也可以说是互联网企业在管理学方面的集体提升。

2.3 揭开中台神秘的面纱

• 有了中台之后我们的前台业务就可以去快速完成迭代，不需要每个服务都要求后台从0到1开始提供，而是根据不同业务需求去使用中台生产的对应半成品进行二次加工。
• 当我们引入中台后，让中台作为一个对接层，帮我们去统一对接前台的不同终端，同时对后台各个子系统进行统一的封装，让前台能无感知地使用各项服务而不需要单独设计通道，我们的系统也就简化成了如图2-7所示的这个样子。
• 中台的核心本质就是向前台业务提供服务共享，目标是更好地支持前台业务方进行规模化创新或大规模试错，从而更好地响应市场需求。
• 中台解决方案=能力输出+标准化中间件
• 虽然这里在说中台要考虑复用性和扩展性，但是要考虑多少、考虑多深就是一个非常考验产品经理功力的地方了。
• 可复用性和复用深度是衡量中台建设好坏的重要指标。

2.4 中台解决方案的威力

• 中台的核心价值之一就是可以大幅降低软件开发的边际成本。
• 边际成本指的是每一单位新增的产品所带来的总成本增加量部分。
• 中台模式就是标准的边际成本递减事件
• 基础设施的建设成本在后期可以通过大量的产品生成而逐渐摊平，让前期的投入成本无限趋近于零。[插图]中台其实也就是我们企业的基础设施，同样符合上述边际成本递减的经济规律。
• （1）提升内部服务的复用能力
• （2）提供全局化视野和全量数据模式
• 而中台这一工具可以让各个业务的数据都沉淀在同一套中台服务中，让数据可以打破项目隔离变为一个企业中可以被复用的资源，并且通过各个项目的资源形成一个公共数据池，方便进行全局的决策。
• 中台的另一个重要的可感知作用就是能缩短企业的TTM，所谓TTM（Time to Market）就是产品从研发到推向市场所用的时间，对于企业来说这个时间当然是越短越好。
• 在竞争日趋激烈的互联网行业中，如何低成本又快速地完成业务创新去占领市场是每个企业所追求的方向，而

本章总结

• 中台的核心目的就是降低成本与提高效率。

3.1 中台与产品微服务、SaaS的区别

• “微服务”一词最早是在开发人员的代码实现层面提出的，其目的是解决公司内部业务日趋复杂化后代码量指数上升所带来的高维护成本问题
• 为了方便代码维护与避免一个模块出故障导致整个系统都无法运行的局面，开发人员将功能按模块进行封装，组成一个个小的独立单元让它们独立运行
• 这种设计理念被称为产品组件化。
• 产品微服务只是中台的实现手段之一但不是中台
• SaaS的英文全称是“Software as aService”，中文翻译为“软件即服务”。
• 此时每位用户可以根据自己的实际需求，向这些SaaS软件厂商按照计算量与时间进行使用权的购买，用多少买多少。
• 中台其实是帮助企业自身提高研发效率的工具，中台的目的是企业能快速进行一个产品的搭建，而不是给客户提供直接服务。

3.2 什么企业需要中台

• 一般建设中台的只有两类企业：一类是初创企业，一切从零开始规划好；另一类是业务线复杂的企业，一个企业在整个发展期间能做到多元化的业务，说明企业在核心业务上发展得比较成熟且产生了一定规模价值，此时开辟了新业务并将成功经验复刻到这些新业务上，从侧面也说明了这样的企业业务具有大规模性和高价值性。
• 表3-1 中台可行性评估自查表

3.3 中台产品的发展趋势

• 这里所谓的“大中台”就是将提供统一服务的部门做大做强，让其负责更多的公共服务研发；而“小前台”就是让业务部门少研发，将技术团队变小，从而让更多的需求由中台去完成。这样就能在中台完成之后，将成果快速地共享给其他部门使用，从而实现一处研发、多处使用的高效研发目的。
• 整个架构以阿里云平台为技术中台，向上对共享业务事业部提供支撑，而再由共享业务事业部中的八大公用服务向前台业务提供统一的能力输出。
• 业务能力标准、对象定义标准以及中台化后的企业内部管理和运营方法，从而支持前台业务快速、低成本地创新。
• “而这里要把握一个度——你怎么样真正让这个中台能够横向服务好每个业务，而不是变成一个障碍性的枢纽，这是最难的。”
• 从上面这段话里我们能很直观地识别出它对中台价值的定义，就是为企业提高生产效率。
• 腾讯的动作便是通过建设开放中心从而服务众多细分领域的中小型企业，让腾讯自身成为这些企业的业务承接平台，以此通过先服务B端客户再间接获得C端用户。
• 数据中台分为用户中心、内容中心、应用中心。 技术中台分为通信中心、AI中心、安全中心。

3.4 中台产品的发展与演进

• （1）第一个阶段：共享代码平台
• （2）第二个阶段：共享服务平台
• （3）第三个阶段：共享能力平台

3.5 中台产品的正确分类

• 企业生命活动=经营+投资+融资
• 业务中台负责为公司的用户需求提供基础材料解决方案
• 数据中台帮助企业进行业务全生命周期中的数据管理，监测产品在各个状态下运行产生的数据，从而赋予一家公司数字化运营能力。更重要的是，可以打破业务线的间隔，将不同业务线产生的用户数据汇聚至中台，形成“超级大脑”以进行决策。

本章总结

• 中台更适合两类企业使用：1.公司内部有多条产品线；2.公司做相似行业的外包项目。

4.1 互联网下半场的C端业务

• 聚焦到消费互联网产业，这些驱动因素可以总结为4个大类，分别是投资人、网民数、科技发展和宏观背景
• 在我们的产品新增用户数开始趋近停止增长的背景下，以往那种不按正常商业逻辑进行运作的发展模式已经走到头了，此时最重要的任务就是在最短的时间内设计一整套低耗高产的解决方案，来保证企业能应对日渐严酷的市场，可以说这就是消费互联网企业所应对的最大挑战
• 如果你想让游戏的日活跃用户（DAU，以下简称“日活”）的数量超过100万人，那么新用户次日留存率应该大于40%，7天留存率和30天留存率分别大于20%和10%”。
• 但是随着互联网用户数的减少，获取一个新用户的成本开始陡增，各大企业便开始更为注重自己的用户留存问题。
• 在存量市场，能让企业活下去的唯一方法正是创新，也就是不断给用户带来新的产品体验从而让用户留存到我们自己的平台
• C端市场的中台建设目标：为支持不同偏好的细分用户群体业务提供统一支持；为快速创新、高频试错提供基础服务。

4.2 B端业务复杂多变的共性

• 都是帮助企业更好地经营自己的业务，从而帮助企业创造价值。
• 维度二：提高企业内部运营的效率
• 维度三：帮助企业更好地完成信息传播
• 任意一家企业通过生产经营来获得价值的过程，实际上就是对5个关键要素进行整合而产生价值的过程，
• 因为每一家公司内部的客户、产品、营销、自身团队、交易行为这5个要素的组成都是不一样的，所以每一家企业的运作逻辑是独特的。
• B端产品真正应该追求的是高净值客户而不是用户数量。
• 因此对于B端产品来说，正确衡量产品好坏应该从营业收入、利润、ROI这几个方面入手，而这其中最重要的指标就是ROI。
• 从理论上来说关于B端产品的终极目标是要做成能提供定制化服务的产品。
• 在做B端产品设计的时候我们应该掌握的是用户的思考模式，就是采用ROI思考导向法。
• MVP（Minimum Viable Product）又称最小化可行产品
• 在MVP开发过程中，MVP模式耗时的最大症结就在于后端开发时间过于冗长
• 表4-2 中台期望建设目标汇总

本章总结

• 互联网下半场C端市场中台建设目标[插图]为支持不同偏好细分用户提供统一支持。[插图]快速创新，为高频试错提供基础服务。

第5章 中台全局建设路径概览

• 当下企业所面临的最大挑战就是要如何进行精细化运营与产品创新
• 中台的天生属性就是将企业的复用生产能力进行聚合，从而快速产出产品。
• 从建设周期来看，整个企业内部的中台化可以分为3个阶段：市场宏观认知（概括为Market）→企业标准化（概括为Standard）→解决方案设计（概括为Solution）。

5.1 市场宏观认知

• 行业研究：（1）研究公司产品背后的细分行业现状是什么，公司整体业务在行业中所占地位，以及未来行业发展趋势是什么；（2）研究公司的目标市场是什么人群，基于什么场景，通过什么方式，解决什么问题。
• 因此我们在中台各版本的规划中必须优先从企业的商业目标出发去建设、汇总抽象能力，避免让中台沦为各条业务线的外援开发团队。

5.2 企业标准化

• 中台的建设肯定会是互联网企业内部的一次管理升级。中台建设不仅仅是建设一套系统，更重要的是通过系统的建设完成了企业内部的自我升级！

5.3 解决方案设计

• 具体建设思路拆分为这5步：[插图]核心场景剥离：将公司的整个业务进行分割，确定业务的核心场景与用户流程。[插图]核心业务拆解：对每条业务线进行拆解，得到每条业务线在核心场景中提供的服务与对应的功能模块。[插图]模块组合打包：将各条业务线中相同类型的业务功能整理成一个功能合集。[插图]基础服务确定：从核心业务流程向外剥离，将功能划分为基础服务与前台系统两部分，将中台与每个前台业务系统分割开。[插图]中台能力输出：在确定好每个基础服务的边界后，我们需要对基础服务进行一些处理，以保证能力可以适配不同的业务前台需求，不会由于客户端不同导致前台业务无法使用，提升中台服务接入的兼容性与扩展性。

本章总结

• 中台MSS建设模型 企业中台建设分为3个阶段，具体为：市场宏观认知（概括为Market）→企业标准化（概括为Standard）→解决方案设计（概括为Solution）。

6.1 宏观市场分析

• 以一个企业所处的外部环境为研究对象，研究整个产业的变化对其中各个细分领域的企业会有哪些影响。
• 方向1：分析公司当前业务的前景。
• 我们要去研究未来企业如何发展才能赚钱，而在这些能赚钱的方向里，哪个又能赚大钱。
• 预判企业下一步的业务发展方向。
• 看趋势（宏观经济）→看产业（是否高增长）→诊行业（首次公开募股[IPO]/投融资+进入难度+发展阶段+国外趋势）→选价值链（服务、研发、渠道）。

6.2 企业产业链分析

• 快速确定行业分工的工具——三分法模型，在这个模型中任何一个行业都可以被拆分为基础服务、平台、渠道分发3个部分。
• 第一个我推荐的方法就是通过对近期 IPO企业所在的行业与投融资焦点行业这两份名单进行交叉对比、得到结果。
• 因此，如果我们将这两个方向与我们行业价值链的各环节进行一次交叉对比，我们就能快速得到既受政策支持又受投资人（或者说受市场）追捧和青睐的业务
• 方法2：判断候选方向是否值得进入
• 如果目标方向中70%的市场份额已经被头部两到三家企业所占据，那么这个方向就属于高度饱和的方向
• 方法3：对比国外同行业发展
• （1）近似替代+比例估算

6.3 企业商业模式探寻

• 商业模式简单来说是企业创造价值、传递价值、获取价值的方式，它不仅包含了整个企业的盈利模式，还包含了对产品如何进行成本控制。
• 图6-8 商业模式画布
• 我们为哪类人群提供服务/产品？（Who）[插图]我们具体提供什么服务/产品？（What）[插图]我们要怎么提供服务/产品？（How）[插图]我们要怎么通过这些服务/产品赚钱？（Money）
• 物理维度：地区、城市规模、人口密度、气候等。[插图]人口维度：年龄、家庭规模、家庭周期（单身、已婚、丧偶等）、性别、年收入、职业、受教育程度、宗教、种族、国籍、社会等级等。[插图]信息化维度：线下流程阶段、线上流程阶段。
• 假设我们要开发一款社交软件，首先我们要了解为哪类目标群体提供服务（用户细分），再确定他们的核心需求（价值主张），思考这款软件如何能被他们发现并使用（渠道通路），在用户开始使用软件后我们要怎么实现盈利（收入来源）以及与他们保持什么样的关系（用户关系），凭借什么特殊优势保证我们的这款软件的特殊性不会被竞争者超越（核心资源），为了达成这个目标我们需要采取什么活动（关键业务），最后能支持这个商业模式的合作方都有谁（重要合作），在整个计划开始前我们需要预估整个流程的综合成本会是多少和是否有盈利的可能性（成本结构）。

6.4 中台用户研究

• （1）用户访谈（定性）
• [插图]业务完整流程各节点直接关系人：产品经理、运营经理。[插图]业务支持研发人员：项目经理、架构师。[插图]公司高层：CEO、CTO、业务线负责人。
• 图6-11 中台访谈计划表
• 市场四要素：宏观环境+行业动向+竞争对手的变化+用户需求发展

7.1 组织结构的中台化改造

• 前台业务研发人员：负责响应一线客户的需求，目标在于实现业务目标，较少考虑系统性能。  中台研发人员：负责维护工具。有了这么一群专职的人员，就可以撇清烦琐的业务需求，每天的任务就是研究如何使用这些工具，使其性能最优化以提供给前台研发使用。  后台研发人员：负责底层物理机器的管理与支持和技术架构选型的研发。

7.2 业务流程的中台化改造

• 业务流程的中台化改造实际就是将业务中我们要进行的各个环节找寻出来，从而将一个非常抽象的业务定义为由若干个标准动作加关键节点所组成的程序化流程。
• 对公司的各条业务线都进行一个标准化的梳理
• 产品=产品主体+产品推广标准流程+运营后台运营后台=产品运营反馈循环+推广运营反馈循环
• 所谓推广标准流程指我们将以往推广人员自由发挥的推广动作进行规范，让推广动作就像安装说明书一样在进入每一个新市场时能按部就班地进行。

7.3 业务线的核心公式

• 地推人员的成单率=（客户线索数×转化率）/客群总数

本章总结

• 泛产品架构 这个架构就是将整个公司视为一个产品。 产品=产品主体+产品推广标准流程+运营后台 运营后台=产品运营反馈循环+推广运营反馈循环

8.1 原则1：独立的中台研发团队

• 兼任型研发模式最大的弊病就是当团队对业务进行抽象建模的时候，会无意识地参照当前团队业务进行设计，在中台建设中我们适当地参考当前业务线的发展是有必要的，但是如果完全根据某条业务线的需要去设计中台模块，就让中台丧失了本身的价值。
• 在中台建设团队中必须有企业内部高管的参与。
• （2）与业务线建立沟通机制
• 具体包含业务线当前周的版本计划、版本中的重要功能、下一阶段规划的功能3部分内容。

8.2 原则2：中台建设需求边界管理

• 方向1：复用化。对于原来嵌入某个具体业务的模块，对其中的特殊部分（也就是原有的业务信息）进行剥离，使其变成一个公共的模块并且与业务没有任何关系。方向2：标准化。将剥离出来的模块与之前调用的业务线进行内部统一，使其变为多条业务线在操作同一事物。同一事物的名称、属性都能保持一致。方向3：能力化。通过对剥离出来的模块进行设计，使其拥有接收外部输入信息与向外传送该模块计算结果的接口。通俗来说就是接口化。
• 业务中台与数据中台的本质区别就是对同一个事物中的业务数据与描述数据分别管理。
• 中台建设中一个重要的原则就是要针对不同的模块分清楚业务数据与描述数据。
• 第二种自下而上的建设模式可以说是最适合企业在发展现有业务的同时去搭建中台的模式。这种模式不需要进行二次建设，节省了成本，因此绝大多数的企业在建设中台时都使用这种模式。

9.1 中台业务场景分析

• 产品线（Product Line），指的是为达成企业某一目标的多个相关需求解决方案组成的集合，产品线可以是由多个产品组成的，也可以是由多个功能模块组成的
• 第一级，流量获取：通过给用户补贴抢占市场，建立起稳定的流量供给渠道。第二级，流量留存：将流量用户沉淀至可拓展的高频商业场景中，实现产品方向的演化。第三级，流量变现：推出核心付费环节，开始盈利。
• 精细流量运营的首要出发点也是满足用户在核心价值场景的多选择性
• 核心价值指标=当前产品阶段识别+用户应达成目标

9.2 业务中台化抽象

• 在中台建设里广泛存在这两个问题：[插图]添加的需求为了能适配不同的前端业务线，不能是具体的功能而应是能力。[插图]我们要将哪些功能添加到中台的需求池中，避免将中台建设为另一个“小后台”。
• 所谓动作分析法，就是将任意模块拆分为某个人为了完成某个事件而需要在应用中做哪些动作。
• 下一步通过将各个节点中不同角色的输入、输出进行统一，我们就能很快找到整个系统中我们所需要提供的最密集的能力是什么。
• 那些能为公司变现的业务模块应该是中台优先归纳和剥离的，随后其他不同的业务线都应该向此类模块集中。

9.4 中台方案框架

• 管道理论，就是将每个模块中各节点不同的输入、输出进行统一，汇聚成统一的出、入口，从而建立起统一的向外通道设计
• MECE原则的核心就是让我们在面对问题时要能以一种相互独立、完全穷尽的分析方法来分析问题。

10.1 企业架构

• 企业架构就是一种管理业务生产各个要素之间关系的集合
• 业务架构包含运营模式、组织结构、生产流程等内容
• 这里IT架构由数据架构、应用架构和技术架构3部分组成，通俗理解就是对应公司中的业务数据、前台产品与代码。
• 作用1：创新。企业架构帮助我们梳理了企业内部的业务流程与目前整体业务的信息化程度，从而使我们可以轻松掌握公司内全局资源的分布，来帮助快速实现业务推进。[插图]作用2：提效。经过设计的企业架构能打通各业务单元边界，使得部门间的流程可以充分融合。[插图]作用3：降本。在系统增减决策中，参照企业架构可以避免系统的重复性开发，从而充分利用现有系统资源。
• 中台系统在企业信息化中是承接前台应用与底层系统的重要桥梁，它的定位就是帮助前台业务封装底层系统接口并形成一个中间层。

10.2 业务中台建设的启动

• 分布替换式建设：是指我们对业务系统内的模块一次一个地进行改造重建，最终将所有综合架构实现中台化。这种建设模式的好处是可以不断根据业务需要进行抽象，而坏处也是显而易见的，就是整个业务中台完成建设的周期将比较长。而现在很多启动中台建设的公司一般都选择了这种模式。

10.3 业务中台建设路径

• 相似度=（相同输出通道数+相同输入通道数）/总通道数
• 通用模型的建设在本质上是建设起全公司业务的一个通用流程，而不是简单地将业务线中的公共需求模块进行堆砌，也只有这样才能让中台的能力边界可控。
• 所谓企业级数据模型，是一个企业中的业务规则以及信息管理，也就是说我们的一个完整业务（如下单流程、配送流程）可以被描述成需要用户输入哪些信息、确认哪些信息，并在什么样的信息筛选情况下，可以让用户完成一次业务活动。
• 有关抽象的方法，我们可以采取向下兼容，也就是将每个实体所涉及的字段与调用操作去重后全部放入抽象出的对象。
• 业务活动的本质就是：在什么样的场景下开始执行任务（事件），模块需要哪些数据（实体），依据什么样的顺序、规则进行处理，处理之后与哪些对象（实体）产生联系并产生了哪些数据。
• 数据存储=通用数据（中台）+业务数据（前台）
• 技巧2：版本迭代计划安排

10.4 业务中台建设KPI

• 业务中台的效果验证性指标包含两个指标：模块复用率与业务开发TTM。
• 模块复用率的计算是用业务中台的各个模块被各条业务线所使用的次数除以业务中台各模块总使用次数。
• TTM（Time to Market），一般指产品上市周期。而在这里我们可以衍生一下TTM的定义：一个软件模块从立项研发到最终上线所需要的时间。
• 总成本节省=（业务1节省开发成本+业务2节省开发成本+…）-业务中台开发成本-业务方迁移至中台成本-中台系统运维成本

本章总结

• 完整的业务中台建设步骤，分别是绘制全景功能地图（梳理业务线功能现状）、找到核心业务流程（不同业务线中的统一流程）、搭建企业级数据模型（业务数据化）、研发业务中台中间件（分布式存储模式搭建）、对接后台业务系统。

第11章 企业业务指南针：数据中台设计实战

• 如果你不能衡量它，那么你就不能有效增长它。
• 所谓的闭环产品体系设计，简单来说就是将产品研发与市场反馈相关联，并按照市场需求的方向进行迭代推进。
• 一切投放用户市场的产品，都需要有来自市场反馈的声音，否则就是设计者在“自嗨”。
• 数据中台就是将多条分散业务线的数据进行汇总从而进行整合使用的数据系统

11.1 战略目标

• 数据指标体系（指标+事件），而数据指标体系的意义就是让业务变得可评估、可对比与可拆解。
• 要设计一个靠谱的数据中台时，其成败的关键就是数据指标范围选择的好坏，只有真正选择出有参考价值的数据指标才能真正将产品变为闭环设计。
• 产品设计者必须弄清楚自己的产品与用户“博弈”的是什么。而这里的“博弈”指的就是用户的本质诉求与你提供的解决方案间的博弈。

11.2 阶段目标

• 一般来说，我们会将数据指标体系需求分为两部分：直接采集后的统计数据与特定事件分析结果数据。
• 层级一：战略指标
• 结果类指标更多是去监控整个业务的最终效果是否达到预期目标，而过程类指标则关注用户在哪个环节出现了问题。
• 事件分析指对特定的用户行为进行过程化的分析，从而得出定性的结果去指导下一步中产品要怎么做。

11.3 执行战术

• （2）关注点：什么渠道的ROI最高
• 漏斗模型的核心思想就是分解和归类量化。
• 杜邦分析法（DuPont Analysis）利用几种主要的财务比率之间的关系来综合地分析企业的财务状况。

11.5 数据中台2.0架构设计

• 业务口径就是指不同人员对于同一事物的数据描述方式。
• 在One Data整个方案体系里，共分为数据规范定义体系、数据模型规范设计、ETL规范研发3类。
• （2）指标维护的统一管理

本章总结

• 数据中台建设分为两个大步骤：数据分析体系搭建与多条业务线接入。[插图]数据分析体系搭建：北极星指标确定，统计数据类指标确定，数据事件确定。[插图]多条业务线接入：底层多条业务线的数据源接入，打通数据流通，建立数据参考系，提供多样式的数据输出。

12.1 技术中台体系架构

• 技术中台类似一个承上启下的中间层，对下封装复杂的实现逻辑，对上提供统一化的工具。

12.2 技术中台的原理

• 让一个独立单元只完成一件事情。

12.3 如何搭建技术中台

• 部分模块的故障不会导致整个系统的崩溃
• SOA实际上就是将各个模块划分为独立单元去独立运行，从而保证整个系统的安全
• 中台实际就是将每一个复用的模块作为一个独立的应用进行开发与上线，再通过服务调度来实现复用。
• 对微服务最简单的理解就是把系统按照不同的业务对象，根据提供的服务拆分成一个个大小合适并且可以独立部署的模块，每个模块相互独立但又可以任意组合从而形成可复用的架构。

产品人的通关之路：M-P能力模型

• 产品经理是对一个产品从想法诞生到需求制作，再到市场推广，再到商业变现的全流程的管理者。
• M部分——市场运作能力C.市场推广：如何让产品进入市场去触达目标用户，并形成规模乃至占领市场。D.商业变现：设计一个怎样的变现渠道，用什么方式，针对什么样的人群，以什么样的计费模式去完成我们的一个商业目标。P部分——需求生产能力A.需求翻译：通过上面这个案例，我们也能理解到这个能力其实就是能将一个庞大且抽象的需求去逐步拆解并且增添内容，直至其变成一个可以执行落地的App的能力。B.项目管理：用最简单的一句话概括就是产品经理能够保证需求在任何状态下都能被按时交付。

优秀的产品经理优秀在什么地方

• 所谓产品经理的优秀，实质上就是掌握了M-P能力模型中偏市场层面的能力，能以大局观来看待整个产品的问题。
• 要想成为一名优秀的产品经理，我们就要在掌握了需求生产（Product）能力后，不断地去学习和掌握市场（Market）层面的知识，使自己能以企业战略角度来思考问题并去解决极其抽象的问题，将问题拆解成不同的执行方案。