| 5.中台建设路径 | 中台是企业信息化建设纲领 | | | |
| 市场宏观认知 | 企业外部调研（行业研究） | 行业高度进行业务规划 | |
| 对下一步业务的预判 | |
| 企业内部调研 | 商业模式、用户调研 | 避免成为业务线的外援开发团队 |
| 企业标准化 | 企业管理流程标准化（各业务执行环节程序化改造） | | |
| 各业务线执行环节有可量化的指标（透明化） | 案例：客户拜访 | |
| 中台建设是互联网企业内部的一次管理升级 | | |
| 梳理业务需求与数据需求 | | |
| 解决方案设计 | 业务建模 | 核心场景剥离 | |
| 核心业务拆解 | |
| 模块组合打包（功能合并、合集） | |
| 基础服务确定 | |
| 中台能力输出 | |
| 特征列表 | 建立特征列表 | |
| 分析共性部分 | |
| 7.业务标准化 | 组织结构中台化改造 | 独立中台研发团队 | | |
| 反例：矩阵组织架构 | 人员灵活调配，频繁切换业务组 | |
| 大大提升人员重新认知的时间成本 | |
| 中台团队 | 定位：公共事务研发 | |
| 中间件、自动化脚本、数据库查询等工具研发 | |
| 撇开繁琐的业务需求，专心研究技术平台、如何提高性能等 | |
| 前台团队 | 负责一线客户需求 | |
| 目标：实现业务目标 | |
| 较少考虑性能 | |
| 业务流程的中台化改造 | 产品经理 | 应站在公司角度对各条业务线进行一个标准化梳理 | |
| 做到对公司各项目心中有数 | |
| 业务抽象归类 | 泛产品架构分类（整改公司视为一个产品） | |
| 产品=产品主体+产品推广标准流程+运营后台 | |
| 运营后台=产品运营反馈循环+推广运营反馈循环 | |
| 业务量化 | 整个业务进行考核指标的设计 | |
| 实现数字化运营 | |
| 找到企业数据中台的监控目标 | |
| 9.现有业务能力抽象 | 各产品在产品线中的定位 | 流量获取 | | |
| 流量留存 | | |
| 流量变现 | | |
| 各产品用户群情况 | | | |
| 5W1H分析法 | 对象（What） | 6个问题梳理公司各产品功能矩阵 | |
| 目的（Why） | |
| 场景（Where） | |
| 时间（When） | |
| 用户（Who） | |
| 方法（How） | |
| 业务中台化抽象 | 拆解模块 | 拆解公司所有产品功能模块 | 提取共性 |
| 避免漫无边际地将各个应用任意需求加入中台 | |
| 站在全公司视角思考解决方案 | |
| 动作分析法 | 事件 | |
| 动作 | |
| 案例1：登录 | 事件 | 本人校验事件 |
| 个性化配置载入 |
| 进入页信息灌装 |
| 角色行为 | 登录用户 |
| 业务系统 |
| 动作 | 每一次操作 |
| 输入信息 |
| 点击按钮 |
| 案例2：地图应用 | 用户中心 | 高频模块剥离 |
| 位置管理 |
| 中台方案架构 | 中台立项 | | |
| 产品画像 | 最忌讳：成为业务线的外部中心 | |
| 排除大而全的设计 | |
| 通道设计 | 如何判断共性节点 | |
| 管道理论 | 统一各模块不同的输入、输出 |
| 建立起统一的向外通道 |
| 11.数据中台设计实战 | 闭环产品体系设计 | | | |
| 建立数据运营中心 | 公司级用户画像 | | |
| 整个公司的交易量变化 | | |
| 公司核心指标发展情况 | | |
| 横向纬度分析指标 | | |
| 数据采集埋点 | 粒度太细（资源消耗过大） | | |
| 粒度太大（无法具体定位问题） | | |
| 阶段目标 | 层级1：战略指标 | GMV、用户数、总利润 | |
| 层级2：战术指标 | 业务进展 | |
| 层级3：行动指标 | | |
| 指标体系 | OneData | 指标类名词规范 | |
| OneID | 打通用户体系 | 建立用户画像 |
| 数据监控 |
| 后记：优秀的产品经理是什么样的一群人 | M-P能力模型 | M（Market）部分：市场运作能力 | A.需求翻译 | 需求变为设计 |
| B.项目管理 | 按期交付 |
| P（Product）部分：需求生产能力 | C.市场推广 | 触达用户，占领市场 |
| D.商业变现 | 实现商业目标 |
| 能力层次 | 战略型 | ABCD | |
| 筹划型 | ABC | |
| 高级执行 | AB | |
| 低级执行 | A | |
| 优秀的产品经理 | 掌握了M-P模型偏市场能力 | | |
| 能以大局观看待整个产品 | | |
| 2.为创新而生：中台战略 | 2019中台规模化元年：腾讯、美团、字节跳动 | | | |
| 基于“前后台”架构演化而来 | 项目初期是较为省时、省事的一种架构 | | |
| 建设中不需要考虑系统的扩展性，有很大的自由度 | | |
| 反而节省研发人力 | | |
| 前后台模式的根本弊病 | 现有产品模式由：标准化产品变为以用户为单位的定制化产品 | | |
| 快速迭代、落地终端，软件生命周期变短 | | |
| 案例：电商APP版本迭代周期为6个月。而某AO系统每2个月一次大迭代 | | |
| 这样就暴露了前后台模式的根本弊病：响应速度太慢 | | |
| 生产流程:烟囱式架构 | 资源和信息孤岛 | |
| 大量底层支撑部分建设与等待时间：对用户而言为无效工作 | | |
| 用户能感知的在于前台，不为系统底层架构建设而买单 | | |
| 举例：新项目建设 | 前端重新设计界面 | |
| 后端重新设计服务接口与数据表 | |
| 新业务从底层工作开始，底层重复建设 | |
| 新的解决方案 | 最少改动底层或只开发上层从而满足绝大部分的需求 | |
| 前后台模式向下发展的瓶颈 | 公司内外发展冲突 | 公司外部需要快速迭代 | |
| 内部每次迭代都需要伤筋动骨 | |
| 前台+后台的齿轮速度匹配失衡 | 匹配新业务不断增加新模块，系统越来越庞大 | |
| 无法满足前台业务所带来的改版，无法按时上线 | |
| 公司内部的二次统一 | 管理性名言（战斗力、二次统一） | 组织架构统一 |
| 思考角度上统一 |
| 反例 | 每个产品线圈地为王 |
| 每个部门决策只从本部门利益出发 |
| 每个团队互相隔离、不同事业部重复建设 |
| 需要时跨部门多次对接 |
| 中台的出现可以说是互联网企业在管理学方面的集体提升 | | |
| 揭开中台神秘的面纱 | 做菜案例 | 对接简化作用 | |
| 前后台模式架构 | | |
| 中台业务架构 | | |
| 核心本质 | 前台业务提供服务共享 | |
| 目标 | 前台业务规模化创新 |
| 或大规模试错 |
| 高速增长的企业值得借鉴中台的思路 | |
| 中台解决方案的定义 | 能力输出 | 核心竞争力？战略目标 |
| 提炼共性模块 |
| 归到中台统一建设 |
| 为不同的前台业务提供可以重复使用的能力，形成一次建设、多次使用 |
| 将功能抽象为能力 |
| 避免过度建设 |
| 标准化中间件 | 定义统一化的输入与输出 |
| 统一通用属性 |
| 中台方案的威力 | 大幅降低边际成本 | 量产摊薄前期投入成本 |
| 提升内部服务的复用能力 | 公司核心力量聚集，覆盖全公司 |
| 进阶开发由公司技术带头人负责 |
| 最优解通过中台同步给全公司基础员工（技术中台） |
| 举例：数据库访问 |
| 统一管理 |
| 提供全局化视野和全量数据模式 | 公共数据池 |
| 提升应用的TTM | 统一各项目共有部分 |
| 统一用户感知 | 不同项目发展长短不一，品质不一 |
| 案例：不同项目的登录界面 |
| 不良现象 |
| 使用中台登录组件 |
| 4.C端和B端各需要什么样的中台 | C端业务 | 流量红利衰退 | | |
| 精细化运营 | | |
| 建设目标 | 满足细分用户的偏好 | |
| 快速创新、高频试错提供支持 | |
| B端业务 | 帮助企业更好地经营自己 | | |
| B端产品的两个误区 | 唯日活论 | 追求高净值客户，不是用户数量 |
| 虚荣指标 | 指标不能指导产品达成商业目的 |
| B端唯一评价指标 | 营业收入、利润 | |
| ROI（投资回报率） | |
| 个性化需求控制以ROI为导向 | |
| 功能可配置 | |
| MVP：低成本快速试错 | |
| 6.宏观市场探查 | 宏观市场分析 | 产品经理角色的转变 | | |
| 分析通用框架 | 宏观经济趋势（定性） | |
| 产业发展趋势（定性） | |
| 行业发展现状（定量） | |
| 中台用户研究（业务线人员） | 用户研究方法 | 用户访谈 | 和业务线产品、运营长时间深入交流 |
| 情景访谈 | 模拟真实用户某个场景 |
| 问卷调查 | 终端用户 |
| 研究行动点 | 圈定研究人员 | 产品经理、运营、项目经理、公司高层 |
| 设计研究问题的大纲 | 设计与未来中台使用者的对话 |
| 中台访谈计划表 | 第一轮：业务熟悉访谈 | 输出 |
| 第二轮：公司IT资源方法 |
| 第三轮：高层目标访谈 |
| 8.设计成果中台产品的核心原则 | 原则1：独立的中台研发团队 | 兼任的弊端 | 抽象层次和深度不够的问题 | |
| 无意识按照该产品线的业务进行设计，让中台失去意义 | |
| 高管的介入 | 协调各业务线放弃自己的部分利益 | |
| 打破原有的利益格局 | |
| 与业务线建立沟通机制 | 发现高频需求 | |
| 各业务线周报机制 | 当周的版本计划 |
| 版本中重要功能 |
| 下一阶段规划 |
| 原则2：中台建设需求边界管理 | 模块改造 | 复用化 | 剥离特殊部分 |
| 标准化 | 业务线统一操作对象 |
| 能力化 | 接口化 |
| 需求的边界 | 业务需求 | 输入、输出 |
| 数据需求 | 描述数据、评价指标 |
| 两种建设模式 | 自上而下 | 拆分中台 |
| 覆盖匹配各业务模块 |
| A系统的功能B系统可用 |
| 得出全量功能 |
| 改造B系统模块 |
| 自下而上 | 归类现有各业务系统的模块 |
| 向上统一抽象出中台架构 |
| 10.业务中台从0到1建设路径（解决方案） | 企业架构 | 管理业务生产各个要素之间的关系集合 | | |
| 分类 | 业务架构 | 运营模式 |
| 组织结构 |
| 生产流程 |
| IT架构 | 内部管理运营系统 |
| 数据架构 |
| 应用架构（产品） |
| 技术架构（代码） |
| 作用 | 部门配合统一协调 | |
| 决策依据 | |
| 创新 | |
| 提效 | |
| 降本 | |
| 企业架构与中台 | 属于IT架构层面的产物 | |
| 业务中台建设的启动 | 建设模式 | 分布替换式建设 | 对业务系统模块一个个改造 |
| 优点：逐步抽象 |
| 缺点：建设周期长 |
| 完整式建设 | 独立建设中台 |
| 启动新项目沉淀原有业务 |
| 业务系统前台保持不变 |
| 前后台接口调用替换为中台 |
| 优点：独立项目快速迭代 |
| 缺点：用一套系统翻新所有项目，建设成本高 |
| 中台用户优先级 | 第一层级 | 利润、市场占有率“双高” |
| 第二层级 | 利润低、市场占有率高 |
| 第三层级 | “双低”创新型业务 |
| 业务中台建设路径 | 公司全景功能地图 | 业务线+产品+功能 | |
| 功能相似度确定 | 通道数：模块的输入输出信息 | |
| 相似度=（相同的输入通道数+相同的输出通道数）/总通道数 | |
| 评价复用次数 | 复用次数高则中台化优先级高 |
| 核心业务能力抽象 | 通用流程而非业务线中的公共需求堆砌 | |
| 从企业的业务出发设计一个大体的模块架构 | |
| 提取公司级核心业务流程 | 电商平台案例 |
| 企业级数据模型搭建 | 业务线反馈：格式不一致问题.. |
| 抽象方法 |
| 去重 |
| 企业级数据模型案例 179 |
| 业务中间件研发 181 | 解决数据内容不一致无法统一存储的问题 |
| 字段剥离 |
| 对接后台业务系统 | |
| 最终架构 184 | |
| 中台需求管理 | 原始需求 |
| 关键要素 |
| 管理技巧 |
| 业务中台路线图 | 开发流程 |
| 对接流程 |
| 业务中台建设KPI | 指标1：模块复用率 | 复用率高的留在中台 |
| 复用率低的放回业务线（中台不再维护） |
| 指标2： 业务开发TTM | 软件从立项研发到上线的时间（成本） |
| 节省的开发人天=原模块研发所用人天-中台化研发该模块人天 |
| 被使用的产品越多，则节省的成本越多 |
| 总成本节省 = （业务1节省成本 + 业务2节省成本+…） – 业务中台开发成本 – 业务方迁移中台成本 – 中台系统运维成本 |
| 12.技术中台实战设计 | 技术中台体系架构 | 技术前台 | 核心价值体系在对业务逻辑的理解与实现上 | |
| 技术开发能力标准要求低 | |
| 技术中台 | 承上启下的中间层 | |
| 对下封装复杂的实现逻辑 | |
| 对上提供统一化工具 | |
| 技术能力标准要求高 | 性能调优 |
| 打磨技术工具 |
| 将技术能力和业务能力分离 | | |
| 技术中台原理 | 一个独立单元只完成一件事情 | | |
| 业务线切割后的事件已封装为服务单元 | | |
| 中台拓展、能力增多 | 业务线需要自主研发的就越少 | |
| 如何搭建技术中台 | SOA | 微服务 | 将业务拆分成独立的模块，每个模块独立上线运行 |
| 注册中心 | 统一管理微服务，向各业务线提供微服务模块运行信息与地址，动态获知服务的更新 |
| 部署运维 | K8S | |
| Docker | |
| 技术实现定义：中台实际就是将每一个复用的模块作为一个独立的应用进行开发与上线，再通过服务调度来实现复用 | | |