读书笔记《中台产品经理宝典》6-10章 刘天著

第6章 宏观市场探查

该文档主要讲述了中台MSS建设模型中市场宏观认知阶段的相关内容，包括宏观市场分析、企业产业链分析、企业商业模式探寻以及中台用户研究，具体如下：

1. 宏观市场分析：
   • 定义：以企业所处的外部环境为研究对象，研究产业变化对企业的影响，包括分析公司当前业务前景和寻找下一个业务发展点。
   • 中台出发点：帮助中台产品经理熟悉业务与行业基本玩法，预判企业下一步的业务发展方向。
   • 通用框架：借鉴麦肯锡的市场调查标准步骤，从宏观经济、产业、行业、价值链等层面进行分析，数据来源包括国务院、国家统计局、证监会等。

AI问答
如果我们对"宏观市场分析"下一个简单定义,就是:以一个企业所处的外部环境为研究对象,研究整个产业的变化对其中各个细分领域的企业会有哪些影响。
这句话的意思是，宏观市场分析主要关注企业所处的外部环境，通过研究整个产业的变化情况，来探讨这些变化对该产业中各个细分领域的企业所产生的影响。例如，分析贸易战等外部事件对互联网产业的影响，以及这些影响如何具体作用于产业内的各个企业，而不仅仅是关注企业产品设计层面的对比，如市场上出现的新产品或竞争对手产品的新功能等。

2. 企业产业链分析：
   • 产业链定义：企业生产经营活动相互关联，构成行业的价值动态体系。
   • 分析意义：为预判企业业务发展方向打下基础。
   • 预判企业业务发展方向的方法：判断产业链中是否有优势方向、判断候选方向是否值得进入、对比国外同行业发展。
   • 宏观市场分析经验技巧：近似替代+比例估算、升维估算。
3. 企业商业模式探寻：
   • 商业模式定义：企业创造价值、传递价值、获取价值的方式，包含盈利模式和成本控制。
   • 分析工具：商业模式画布，包括4个视角、9个模块，帮助直观描述商业模式。
   • 分析案例：以在线卖生鲜的A电商平台为例，分析其用户细分、价值主张、关键业务、核心资源、重要合作、用户关系、渠道通路、成本结构和收入来源。
4. 中台用户研究：
   • 目的：搞清楚当前中台服务的用户群体，为现有业务的快速迭代与用户多元化需求提供支持。
   • 方法：包括用户访谈（定性）、情景访谈（定性）、问卷调查（定量）。
   • 行动点：圈定研究人员范围，包括业务完整流程各节点直接关系人、业务支持研发人员、公司高层；设计研究问题大纲，包括高层对中台的了解程度、企业发展方向、是否支持中台建设及建设目的、公司信息化程度和部门对接情况等。
   • 全流程纪实：将用户访谈划分为针对一线业务运作流程人员、业务支撑生产人员、公司高层的三个层次的访谈，并制定访谈计划。
     中台访谈计划表.png

最后，通过分析市场四要素（宏观环境、行业动向、竞争对手的变化、用户需求发展），定位企业商业目标的影响因素，并根据访谈结果进入中台MSS建设模型的下一个阶段——企业标准化。

市场四要素.png

AI问答
如何圈定调研人员的范围与每次访谈的目标和产出?
这句话的意思是，在进行中台用户研究时，我们知道了怎样确定需要调研的人员范围，以及每次访谈的目标是什么，并且清楚每次访谈能够产生什么样的结果或产出。
具体来说，圈定调研人员的范围包括业务完整流程各节点直接关系人（如产品经理、运营经理）、业务支持研发人员（如项目经理、架构师）以及公司高层（如CEO、CTO、业务线负责人）。
每次访谈的目标和产出会根据不同人员层级而有所不同，例如针对一线业务运作流程人员的访谈以业务熟悉为主题，产出是业务线运作情况（标注核心环节）；针对业务支撑生产人员的访谈以梳理现阶段IT资源为主题；针对公司高层的访谈以确定中台建设方向为主题。

第7章 业务标准化

本章主要讲述了在建设中台前进行业务标准化的相关内容，包括组织结构的中台化改造、业务流程的中台化改造以及业务线的核心公式，具体如下：

1. 组织结构的中台化改造：
   • 许多公司在诞生初期采用矩阵组织架构管理员工，按职能分工的模式适合早期公司业务发展，但随着业务需求增加，会出现测试人员切换部门成本高、各业务线技术组件不同等问题。
   • 中台产品经理应建议调整组织架构，将职能部门划归到各业务线，明确前台业务和中台研发人员的分工，让中台团队负责公共事务研发，实现公共底层技术能力研发与前台业务逻辑研发的分离。
   • 依据中台建设，公司人员结构可分为前台业务研发人员、中台研发人员和后台研发人员。
2. 业务流程的中台化改造：
   • 业务抽象归类：将公司内不同业务按照泛产品架构进行映射归类，明确业务属性。泛产品架构将公司视为产品，由研发与市场协作形成，包括产品主体、产品推广标准流程和运营后台，运营后台包括产品运营反馈循环和推广运营反馈循环。
   • 业务程序化：针对不同类型业务进行标准化环节拆解，以某外卖商户接单系统推广为例，通过梳理地推和市场部工作流程，设计数据指标体系服务业务方，完成对公司业务体系的标准化梳理。
3. 业务线的核心公式：通过推广场景案例，将地推人员的成单动作拆分为公式，进而优化公式并得出对应优化方向，定位量化指标，为建设数据中台圈出指标寻找范围。

完成业务标准化意味着为制作“中台”准备好原料，接下来还需进行一些准备工作，下一章将讨论中台设计的相关核心原则。

第8章 设计成功中台产品的核心原则

主要内容是关于设计成功中台产品的核心原则，包括独立的中台研发团队和中台建设需求边界管理两个原则，具体如下：

1. 原则1：独立的中台研发团队
   • 中台产品研发不能由业务线部门兼任，否则会导致业务抽象深度不够，使中台丧失价值。
   • 成熟的中台团队应包括高管、中台产品经理和中台技术人员，其日常工作模式是由产品经理带队调研，高层参与扫除障碍，独立开发人员进行研发与迭代。
   • 中台团队组成必须有高管介入，以协调各业务线、破除建设阻力。
   • 各业务线必须与中台建设人员建立高效沟通机制，可通过周报汇报机制实现，以使中台团队掌握业务线变化，识别业务发展动向。

AI提问
如何建立一个高效的中台研发团队？
要建立一个高效的中台研发团队，可以参考以下几点：

1. 确保团队独立编制：中台研发团队必须拥有独立编制，不能由业务线部门兼任，以避免业务抽象深度不够的问题。
2. 团队组成合理：

• 高管介入：中台建设团队中必须有企业内部高管参与，负责中台大方向定义与公司内部资源协调，以破除中台建设过程中的阻力。
• 明确角色职责：团队应包括中台产品经理，负责中台业务范围定义并确定项目演进方向；中台技术人员，负责落地中间件服务的开发实现。

3. 建立沟通机制：各业务线与中台建设人员应建立高效的沟通机制，如采用周报汇报机制，以业务线新增需求与规划需求为核心内容，包括业务线当前周的版本计划、版本中的重要功能、下一阶段规划的功能等部分，使中台团队能及时掌握业务线的变化，识别业务发展动向，避免中台部门忽略前台一线业务中的诉求。

2. 原则2：中台建设需求边界管理
   • 中台建设的三个方向为复用化、标准化、能力化（接口化）。
   • 进行中台需求分析前需完成两个准备动作：
     • 明确业务需求与数据需求的边界，业务中台与数据中台的本质区别是对业务数据与描述数据分别管理，且两者可能随模块变化而产生属性互换，中台建设要针对不同模块分清业务数据与描述数据。
     • 明确中台需求分析边界定义，通常使用演绎法（自上而下分析法）和归纳法（自下而上分析法），由此衍生出自上而下和自下而上两种建设模式。自上而下模式能精准进行需求分析，但时效性低、成本高，被称为“后发式”建设模式；自下而上模式适合企业在发展业务的同时搭建中台，能节省成本，多数企业采用此模式。

AI提问
中台建设的三个方向为复用化、标准化、能力化（接口化）。
中台建设主要有三个方向。复用化指对已有的资源或功能进行重复利用，以提高效率和降低成本。标准化意味着制定统一的规范和标准，使中台的各项操作和流程具有一致性和规范性。能力化（接口化）则强调将中台的功能以接口的形式提供，便于与其他系统或模块进行交互和集成。

AI提问
复用化、标准化和能力化（接口化）的关系是什么？
复用化、标准化和能力化（接口化）在中台建设中是相互关联、相互促进的关系：
复用化是基础：通过对已有资源和功能的复用，能够减少重复开发，提高开发效率和资源利用率。例如，一个成熟的用户认证模块在多个业务系统中复用，无需每个系统都重新开发。
标准化是保障：它为复用化提供了前提条件。只有在统一的标准下，不同的模块和功能才能更容易地被复用。比如，制定统一的数据格式标准，使得不同系统之间的数据交换更加顺畅，从而实现复用。
能力化（接口化）是关键：它是实现复用化和标准化的重要手段。以接口的形式提供能力，使得其他系统能够方便地调用和集成中台的功能。例如，提供一个标准化的订单处理接口，其他业务系统无需了解内部实现细节，即可使用订单处理的能力。
复用化依赖于标准化和能力化（接口化）来实现，标准化为复用化和能力化（接口化）提供了规范和准则，能力化（接口化）则为复用化和标准化的落地提供了技术支持。三者共同作用，推动中台建设的高效和可持续发展。

AI提问
复用化和标准化的常见问题有哪些？
复用化常见问题：

• 模块适配性问题：复用的模块可能在新的业务场景中不完全适配，需要进行大量的修改和调整，从而降低了复用的效率和效果。例如，复用一个客户管理模块到新的电商平台中，但其数据结构和业务逻辑与新平台存在差异。
• 缺乏有效管理：没有明确的复用流程和管理机制，导致开发者不知道有哪些可复用的资源，或者在复用过程中出现混乱。
• 版本控制问题：复用的模块更新不及时，不同项目使用的版本不一致，可能引发兼容性问题。
  标准化常见问题：
• 标准制定不合理：标准未能充分考虑业务的多样性和复杂性，导致在实际应用中难以执行。比如，制定的数据格式标准过于严格，限制了某些特殊业务场景的需求。
• 标准更新不及时：业务不断发展变化，但标准未能随之更新，逐渐失去其有效性和适用性。
• 执行不到位：虽然有了标准，但在实际开发中，由于各种原因（如赶进度、个人习惯等）未能严格按照标准执行。
• 标准之间的冲突：不同部门或业务领域制定的标准可能存在冲突，导致在跨部门协作时出现问题。

AI提问
如何制定有效的复用流程和管理机制？
以下是制定有效的复用流程和管理机制的一些建议：
1. 明确复用目标和范围
- 确定哪些业务模块、功能或资源可以被复用。
- 设定复用的预期效果和指标，如提高开发效率的具体百分比、降低成本的具体数值等。
2. 建立复用资源库
- 对可复用的组件、模块进行分类和整理，建立详细的目录和说明。
- 为每个复用资源提供清晰的文档，包括功能描述、使用场景、接口规范等。
3. 设立评估和审批流程
- 在复用之前，对拟复用的资源进行评估，确保其满足新业务需求。
- 设立审批环节，由相关负责人对复用申请进行审核。
4. 制定复用的技术规范
- 规定复用资源的集成方式、技术架构要求等。
- 明确如何处理与新系统的兼容性问题。
5. 建立责任和激励机制
- 明确各个环节中相关人员的责任，确保流程的顺利推进。
- 对成功复用并带来显著效益的团队或个人给予奖励，激励复用行为。
6. 培训与沟通
- 开展关于复用流程和技术的培训，提高开发人员的复用意识和能力。
- 建立有效的沟通渠道，方便开发人员交流复用经验和问题。
7. 持续监控和优化
- 定期评估复用流程的效果，收集反馈意见。
- 根据实际情况对流程和管理机制进行调整和优化。
例如，一家软件开发公司在制定复用流程时，首先明确了常见的可复用模块，如用户登录注册、数据存储和检索等。建立了一个在线的复用资源库，开发人员可以方便地搜索和查看。在评估环节，由技术专家组成评估小组，对复用申请进行严格审查。同时，为鼓励复用，对成功复用并提前完成项目的团队给予额外的绩效奖金。通过持续的监控，发现某些模块的复用率较低，经过分析是文档不够清晰，于是对相关文档进行了优化和补充。
通过以上步骤和方法，可以制定出一套有效的复用流程和管理机制，促进中台建设中的资源复用，提高开发效率和质量。

最后总结了本章的两个知识点：独立的中台团队由公司高管、中台产品经理、中台技术人员三类角色组成；业务中台与数据中台的边界划分通常将业务的输入与输出项定义为业务数据，根据其是否衡量某一事物发展情况确定是不是描述数据。

AI提问
列举一些中台建设的失败案例
文档中提及了一些可能导致中台建设失败的情况，但未明确列举具体的失败案例，相关内容如下：

1. 很多公司的中台产品研发由业务线部门兼任，会导致在进行业务抽象建模时，无意识地参照当前团队业务进行设计，从而使业务抽象的深度不够，让中台丧失本身的价值。例如，某业务线负责在线音乐播放器平台研发，若由该业务线团队兼任中台研发团队，分析结果可能聚焦在音乐播放这一孤立出发点上，在业务形式拓展时，作为整个中台的前进方向则略显单薄。
2. 中台建设过程中可能会阻力重重，如各业务线人员需抽出时间与中台建设人员进行需求讨论，占用工作时间；中台建设会打破原有的利益格局，如账户体系归并可能导致各业务线中负责维护账户体系的相关人员去向问题，从而使一些因早期粗放式发展而冗余建设起来的事业部与其子部门的领导抵触中台建设。

第九章 现有业务能力抽像

主要讲述了现有业务的能力抽象相关内容，包括中台业务场景分析、业务中台化抽象、案例（地图应用抽象）以及中台方案框架，具体如下：

1. 中台业务场景分析：
   • 产品画像：
     • 各产品在产品线中的定位：通过三级火箭理论，将产品分为流量获取、流量留存、流量变现三个层级，以判断产品在产品线中的层级与所起的作用。
     • 各产品的用户群情况：从用户维度对产品进行快照，确定用户的核心价值指标，并通过新增用户数与用户流失数判断产品的用户量变化，以及用户所处的生命周期环节。
   • 5W1H分析法：通过对选定的项目、产品或流程从对象、目的、场景、时间、用户、方法这6个方面抛出一系列问题来进行主动思考，以快速熟悉业务场景。
   • 产品功能矩阵：通过对产品功能矩阵的分析，将功能分为核心功能、通用功能、其他功能和个性化功能，为评估中台需求优先级提供重要参考。
2. 业务中台化抽象：
   • 功能拆解：对各条业务线的功能进行拆解，以找到各个模块的共同之处，将共性部分提炼出来，避免在思考中台需求时漫无边际地将各个应用中的任意需求都加入中台规划。
   • 动作分析法：将任意模块拆分为某个人为了完成某个事件而需要在应用中做哪些动作，从而找到整个系统中所需要提供的最密集的能力。
   • 中台模块提取：以能为公司变现的业务模块作为中台优先归纳和剥离的对象，其他不同的业务线都应该向此类模块集中。

AI提问
在本章最开头我们分析出的业务线在整个公司商业模式中的地位就派上用场了,那些能为公司变现的业务模块应该是中合优先归纳和剥离的,随后其他不同 的业务线都应该向此类模块集中。至此,针对某一个具体场景的抽象方法我们就介 绍完了,接下来我们需要做的就是针对全公司的业务进行逐个分析。
这段话的意思是：在进行业务中台化抽象时，一开始分析出的业务线在公司商业模式中的地位具有重要作用。那些能够为公司实现盈利变现的业务模块，应当优先被归纳和剥离出来，放到中台进行统一管理。然后，其他不同的业务线也应该围绕这些能够变现的模块进行集中整合。到这里，关于某一个具体场景的抽象方法就介绍完毕了，接下来要对全公司的所有业务逐个进行分析。

3. 案例：地图应用抽象：
   • 产品画像分析：对地图类应用的产品线中各功能的地位和产品用户进行分析。
   • 节点拆分：以在线打车功能为例，按照动作拆分理论进行流程通用性抽象。
   • 节点信息流分析：对在线打车里的各事件节点信息流进行梳理，并归类统计各节点的信息项重叠次数，以确定公共模块。
4. 中台方案框架：
   • 中台立项：向公司高层申请中台项目的立项，根据“三级火箭”运作公式找到公司的商业运作方向，确定中台建设的目标和需求。
   • 产品画像：通过产品画像对公司的产品线与用户建立正确的认知，对产品核心方向进行规划，确定中台的需求范围模块。
   • 通道设计：将企业中的各业务线能力拆分成为节点，对节点输出的信息流进行归类，抽离共性节点，填充至需求表中，成为企业的公共服务，并按照MECE原则划分业务体系。

AI提问
三级火箭运作公式
       “三级火箭”运作公式是一种特定的运作模式或策略的表述。
       它通常指在某个领域或业务中，通过三个阶段或层次的有序推进和相互配合，以实现特定的目标或达成预期的效果。
       这三个阶段各自具有独特的功能和作用，且相互关联、协同运作，共同构成一个完整且有效的运作体系。

AI提问
管道理论
       就是将每个模块中各节点不同的输入、输出进行统一,汇聚成统一的出、入口,从而建立起统一的向外通道设计。
       管道理论是一种重要的中台分析方法论，其核心是将每个模块中各节点不同的输入、输出进行统一。具体来说，就是把各个节点多样化的输入和输出汇聚成统一的出口和入口，进而建立起统一的向外通道设计。
       通过这种方式，可以实现对各节点信息的有效整合和管理，提高中台的运行效率和协同性。

AI提问
MECE原则
       MECE原则是麦肯锡第一批女咨询顾问之一的芭芭拉·明托在《金字塔原理》一书中提出的重要原则。该原则的核心是在面对问题时，以相互独立、完全穷尽的分析方法来分析问题。具体要求是对一个问题找出所有构成因素，这些因素要相互独立且完全穷尽。
       例如，在分析突发的新增用户量下降这一问题时，根据MECE原则，首先要找到问题背后的构成因素（如渠道质量、投放事件、转化率等），并分析这些构成因素是否可以继续拆分。
在分析前要明确目的，选定目的再确定范围。例如，在中台产品设计中，对会员积分进行分析时，需要剥离过度的定义，若会员积分在系统中可以抵扣货币，具有双重身份，那么将会员资金账户划分为“会员在系统中获得的非货币价值奖励”和“货币奖励”就不满足MECE的“完全穷尽”原则，这样的拆分不是独立的。
       MECE原则为人们提供了一个极好的思考框架，就像在确定目的和范围的前提下进行拼图，每个小块图形既不相同又能一起拼成完整的一幅图。通过该原则，可以完成一个标准的业务拆分。

AI提问
如何在实际业务中应用 MECE 原则？
在实际业务中应用MECE原则，可按照以下步骤进行：
1 明确目的：在分析前一定要明确分析的目的，例如分析新增用户量下降的问题。
2 找出构成因素：找到与问题相关的所有构成因素，如新增用户量下降问题背后的渠道质量、投放事件、转化率等因素。
3 判断是否可拆分：分析找出的构成因素是否可以继续拆分。
4 按照原则分析：确保这些因素相互独立、完全穷尽。
       例如，在中台产品设计中，对会员积分进行分析时，要明确分析目的，剥离过度定义。若会员积分在系统中可抵扣货币，具有双重身份，那么将会员资金账户划分为“会员在系统中获得的非货币价值奖励”和“货币奖励”就不满足MECE的“完全穷尽”原则，这样的拆分不是独立的。
总之，MECE原则为业务分析提供了良好的思考框架，通过它可以更有效地进行业务拆分和问题分析。

第10章 业务中台从0到1建设路径

主要介绍了业务中台从0到1的建设路径，包括企业架构、业务中台建设的启动、建设路径、建设KPI以及总结，具体内容如下：

1. 企业架构：

   • 企业架构的定义：企业架构是管理业务生产各个要素之间关系的集合，分为业务架构和IT架构两大部分。业务架构指公司的业务运转模式，包含运营模式、组织结构、生产流程等内容；IT架构是面对企业业务架构，联合信息化系统建立起的标准系统群，由数据架构、应用架构和技术架构组成。
   • 企业架构的作用：包括创新、提效、降本，能帮助梳理企业内部业务流程和信息化程度，打通业务单元边界，避免系统重复开发。
   • 企业架构与中台：中台属于企业架构中IT架构层面的产物，中台系统在企业信息化中是承接前台应用与底层系统的重要桥梁。

2. 业务中台建设的启动：

• 建设模式选择：中台建设有分布替换式建设和完整式建设两种模式。分布替换式建设是逐步改造业务系统内的模块，实现中台化，周期较长；完整式建设是单独建设业务中台，完成后嵌入原有的IT架构，建设成本较高。
• 中台用户优先级：采用三层划分法将中台所服务的用户（各条业务线）分为第一层级业务线（产品利润增长率和市场占有率“双高”）、第二层级业务线（产品利润增长率低而市场占有率高）、第三层级业务线（产品利润增长率和市场占有率“双低”），确定需求优先级时优先响应第一层级业务线。
  中台用户划分

AI提问
中台用户的优先级
中台用户优先级通常采用三层划分法，具体如下：
一、层级划分
1. 第一层级业务线
产品利润增长率和市场占有率“双高”的产品线，如已盈利的主营业务。这是公司的主力业务线，业务流程真正跑通，能为公司带来大量利润。
2. 第二层级业务线
产品利润增长率低而市场占有率高的产品线，如已经牢牢把握市场且需要提升盈利能力的发展中业务。
3. 第三层级业务线
产品利润增长率和市场占有率“双低”的产品线，如起步相当长时间且无任何迹象的创新型业务。业务流程还未跑通，处于向盈亏平衡点探索的阶段。

二、优先级确定规则
1. 业务线优先
根据业务线所在层级来定义优先级，显然来自第一层级业务线的需求在优先级上高于其他两级业务线的需求。
2. 需求共性程度
包括多个细分的评估层次，如需求是不是核心流程需求，提出需求的是否具有可扩展性，其提出的需求有多少其他业务线也需要。
三、作用
中台建设团队在面对多方同时提出的需求时，可以优先响应与支持第一层级业务线，在这基础之上再去对其他业务线进行拓展，这样就能应对在中台建设过程中的先后缓急。

3. 业务中台建设路径：
   第一步 公司全景功能地图：绘制各条业务线内的功能矩阵，汇总得出公司级“产品模块全景地图”，通过统计各条业务线每周新增的模块开发内容来避免重复建设，并利用相似度计算公式判断模块是否应中台化。

AI提问
什么是“全景功能地图”？
一、绘制与汇总
1 绘制功能矩阵：按照特定分析方法绘制各条业务线内的功能矩阵，梳理出各业务线现有的功能模块。
2 汇总全景地图：在梳理功能模块的基础上继续汇总，得出由业务中台部门统一维护的公司级“产品模块全景地图”。该地图以“业务线+产品+功能”的形式完整记录一个模块，例如“海淘业务线+海淘购App+用户管理”等，通过它可以查看每条业务线的模块以及业务线之间的重叠情况。
二、避免重复建设
1 发现重复内容：在建设中台过程中，各业务线可能因封闭出现刚剥离某模块到中台后又新建重复模块的情况。通过统计各业务线每周新增的模块开发内容来更新全景地图，可第一时间发现重复内容。
2 判断模块复用：判断新模块是否归类到业务中台时，除判断其是否被市场用户接受外，还使用相似度计算公式判断。公式为“相似度 = (相同输出通道数 + 相同输入通道数) / 总通道数”，通道指模块的输入输出信息。若不同业务线的两个模块相似度高且预复用超过两次，就考虑中台化，由业务中台建设团队抽取统一维护。

第二步 核心业务流程抽象：以用户视角找到公司不同业务的使用流程，整合出通用业务流程，建立公司级核心流程地图和标准业务框架，梳理出核心能力及公共模块与功能点。

第三步 企业级数据模型搭建：进行企业级数据模型搭建，横向分析公司内所有业务发展情况，抽象出通用的数据描述，将不同业务线中的重复操作与重复对象进行统一，定义数据对象，得出完整的企业级数据模型。

第四步 业务中台中间件研发：研发业务中台中间件，将通用数据存储在中台，个性化的业务数据分离存储，梳理前台业务线与原后台的调用关系业务流，进行前台模块重构，让前台业务线接入业务中台。

数据存储
第五步 对接后台业务系统：梳理后台系统与原先业务系统的调用关系，将业务中台插入前后台之间，建立封装层，使后台系统不再管理具体业务。

业务中台的最终架构：定义业务中台架构为用户中心、商品中心、交易中心、支付中心、客服中心等通用模块，提供H5接入、API接入、SDK接入三种方式供前台业务线使用中台服务，并总结了中台通用模块范围表。

业务中台需求管理：将业务中台需求处理分为原始需求、标准需求、排期需求三个步骤，通过确定需求对象和场景将原始需求转换为可开发的标准需求，并介绍了业务中台需求管理的技巧，包括需求鉴别和版本迭代计划安排。

业务中台需求处理步骤

业务中台路线图：将业务中台版本规划分为1.0、2.0、3.0版本，依据路线图将中台接入分为流程验证期、全面接入期、运行迭代期三个阶段。

4. 业务中台建设KPI：
   指标1：模块复用率：用业务中台的各个模块被各条业务线所使用的次数除以业务中台各模块总使用次数计算模块复用率，复用率低的模块可放回对应业务线单独维护。

模块复用率=被各条业务线调用次数/业务中台各模块总使用次数

指标2：业务开发TTM：衡量中台作用可看前台业务线再开发对应模块时TTM缩短了多少，以及中台为企业带来的价值变化。

前台业务线开发节约时间

AI提问
业务中台建设的建设 KPI 是什么？
业务中台建设的建设KPI主要有以下两个指标：
指标1：模块复用率
计算方式：模块复用率是用业务中台的各个模块被各条业务线所使用的次数除以业务中台各模块总使用次数。
应用示例及决策：#例如在2018年建设业务中台时，统计各模块复用次数，像“注册/登录管理”复用次数较高，而“多账号绑定管理”复用率非常低只有7%，说明这个模块复用价值不高，可以放到对应的业务线中去单独维护，业务中台团队不再对其进行维护。

指标2：业务开发TTM
定义：TTM一般指产品上市周期，这里衍生为一个软件模块从立项研发到最终上线所需要的时间。
衡量中台作用：建设中台是为了缩短前台业务研发所用的时间，衡量中台的作用可以看在企业业务中台建设完成后，前台业务线再开发对应模块时TTM缩短了多少。
价值变化公式：总成本节省 =（业务1节省开发成本 + 业务2节省开发成本 + ……） - 业务中台开发成本。业务中台化后，被越多的前台业务接入则整体节省的成本越多，节省的是各产品线为重复建设所付出的成本。

5. 本章总结：
   • 知识点1：业务中台建设步骤：包括绘制全景功能地图、找到核心业务流程、搭建企业级数据模型、研发业务中台中间件、对接后台业务系统。
   • 知识点2：业务中台建设KPI：通过模块复用率、业务开发TTM两个指标考核中台模块建设的成功与否。