中台设计管理方法知识点学习笔记思维导图模板

概述

一句话讲解

汇总所有业务的数据运营能力、产品技术能力，快速支撑业务迭代更新，并且可以发展成独立运营的产品

现状

系统复杂，无法快速拿出产品方案

多重对接，沟通成本巨大

系统间耦合性较大，牵一发而动全身

特性

通用性

基于平台及行业角度，思考该中台业务的通用价值。例如订单导出功能，用户原始需求：快速导出数据，进行业务分析。但是站在平台角度，平台富有对用户数据保护的义务，因此需要考虑从数据及用户层面做权限控制；同时也考虑到商家不仅需要导出订单，后续可能导库存、商品及其他业务数据，因此需要考虑产品的通用性，以降低后续开发的成本。

结构化

将通用能力与业务场景进行解耦，实现“业务场景-通用能力”系统架构。

标准化

以接口化的形式赋能到外部的业务场景，供业务场景按照标准化的形式进行接入和开发，降低其他业务导出的开发成本

可拓展

从业务场景角度进行单独定制，以致于不会对其他业务场景产生影响，也提升了定制化需求的研发效率

设计方法论

业务抽象

需求分析

竞品分析

功能分析

业务分析

用户分析

方案设计

业务设计

架构设计

方案落地：项目管理与推进

上线运营：基于生命周期的产品运营

经典中台产品

中台组成

组织中台：研发实体中台前，要现在公司管理和组织结构中做出符合中台框架的调整类似于协调各部门的调度部门；

产品中台：基于业务进行模块化；

数据中台：建立跨平台数据体系和应用方法；

技术中台

服务中台：基于任务集合驱动的客户关系管理和服务体系；

阿里：小后台、大中台、小前台战略

华为：平台炮火支撑精兵作战战略

Supercell：中台概念最初实践者

业务抽象

需求分析

需求分析全景图

需求背景

干系人

最关键的干系人有哪些人？

干系人的关注点、担心点是哪些？

需要记录以下信息：所属部门、姓名、岗位角色、核心关注点、相关度、影响度

背景

解决什么问题？

创造什么机会

目标

实现什么目标

带来什么价值

评估需求

基本型需求：必须有的属性或功能

子主题

期望型需求：没有也可以正常开展业务

评估需求需要以下信息：所属部门、业务目标、需求类型、产品价值、技术成本、评估

业务分析

业务流程

正向流程

逆向流程

异常流程

业务规则

具体业务属性

操作限制

约束规则

业务场景

业务开展场景

业务操作流程

业务价值

用户价值

产品价值

商业价值

用户分析

确定用户

人群属性

规模属性

人群特点

用户目标

做什么事

怎么做

有那些满足方案

用户场景

用户在什么情况，什么环境下使用

子主题

功能分析

交互流程

业务、用户规模

服务方式

数据/监控

性能要求

分析流程

分销中台需求分析案例

需求、业务分析

干系人：老板CEO、各业务负责人、各业务产品

访谈内容： 1.代理人层级模式；2.代理发展方式；3.分销产品需求；4.业务模式特点；5.对接人。

机会： 1.70%的分销业务是相同的，只有30%的个性需求由各自业务特点决定；

问题： 1.代理人管理薄弱；2.没有很好的工具很好地帮助代理人转化客户；3.未被转化的客户不能很好管理追踪；

各分销业务架构、流程

用户分析

代理人群分析

痛点分析

渠道运营方分析

特点、痛点

确认分销业务目标及架构

1.分销业务统一管理、研发集中赋能、资源共享；

2.赋能各业务运营团队及代理人进行C端用户运营；

方案设计

架构设计

明确产品模式

明确中台核心模块

确定服务于前台哪些业务、系统

确定对前台业务、系统的服务方式

H5

前台业务可以直接使用的页面

API

直接传输相应的数据，供前台业务二次组装

SDK

需要原生app的场景下，进行封装

明确后台依赖或打通的系统、服务

底层系统

业务设计

功能模块拆解

目标产出

1.待设计的具体功能清单

2.功能-角色的对应关系，以便后续设计时，场景 / 权限明确

模块拆解的详细流程

明确大致系统

明确参与角色

拆解一级模块

细至二级、三级、四级模块

子主题

业务流程

基于业务活动、用户行为、系统交换设计

选择流程图描述方式

跨职能流程图、活动图

强调每个角色执行的活动

序列图

角色之间的协作、交互、先后顺序

勾勒流程主体

分工

服务开始到结束涉及的角色

活动

每个角色的活动内容

协作

串行、并行、异步

分支

不情况的处理过程

产物关系

协作涉及的工作表单、文档、物资

补充事中管控点

审核

控制风险的审核项

规则

各环节的相关规则

异常

特殊情况、系统异常、数据异常

分析执行中的监管需求

进度、效率

异常点监控

其他需求

如何搞定多个系统的交互逻辑

全局呈现、单个突破

重点关注扯皮或逻辑异常复杂的环节

灵活补位：产品、研发、项目经理均可能补位

产品原型

具体字段

显示文案

交互逻辑

业务规则

全局规则

内禀规则

交互规则

方案设计常见的坑

需求调研不彻底，返工成本较高 → 前期做好需求调研与分析，覆盖业务全部场景；

依赖关系定位不清 → 了解各业务逻辑，进行多轮评审

难以建立统一标准 → 制定人员轮岗方案和机制

3种典型中台设计场景的关键点

从0到1

产品内核

MVP：最小模型 / 基本模型

怎么确定最小模型：

1.是否缺少该系统就无法运转？

2.业务能否在该系统中运行？

3.有什么存在价值？

3个战略价值

公司的战略价值

部门的战略价值

产品本身的战略价值

开工条件

前置条件是否满足

产品设计、业务流程、业务模式、技术条件、业务资质

合作意愿

最有意愿加入、且有一定价值的业务方

从1到N

找准方向做强中台

目标

务实基础能力

查缺补漏

了解痛点、明确问题

助力研发效率

平台化

标准化

组件化

提升数据表现

收入指标

产品指标

技术指标

如何筛选需求和目标？

OKR方法：目标和关键结果

业务叫得最多

客户投诉最多

老板期望最高

产品价值最优

从N到1

挑战

各业务单元系统参差不齐

如

1.成熟系统不想被整合；

2.不成熟系统想借力；

3.未成立的业务需要提前预见

投入时间充分调研，保证业务场景分析全面，方案设计全覆盖

全面深入地梳理业务现状，找到有效的业务切入点

整合过程中，业务部门短期见不到改造收益

如

1.业务部门有接入成本，挤占了本可用于业务迭代的研发资源；

2.运营、业务系统需要一定的适应过程，业绩可能不升反降；

先整合不成熟、切换成本低的系统，逐渐整合成熟系统

前置考虑到整合、接入的成本，提前计划、备好资源，确保有效推进

业务场景窄、中台化成本高的业务，还回到业务系统中自行处理

流程

调研现状

快速输出简要系统分析报告

到底有多少套系统？为什么存在这么多套？

调研完整业务需求

对标现有系统，调研各业务真实需求和差异化需求，全面汇总

输出需求调研报告

对标行业标杆

成熟系统怎么做？可借鉴内容

输出竞品分析报告

深入梳理现有系统

详细分析每套系统，看每套系统业务、功能、表现成熟度

输出详细系统分析报告

产品方案设计

以其中一套系统为基础，升级改造

输出产品设计方案

项目推进策略

制定过渡方案、实施步骤

输出项目推进计划表

项目落地执行

逐步推进各业务系统单元废除老系统，切换新系统

研发进度排期

项目推进

挑战

从无到有，项目周期较长

涉及业务较多，任何一步的质量都非常重要

业务结构、人员复杂，沟通技巧、推进方法极受考验

方法

中台项目管理中的关键动作

启动

项目干系人识别

组织项目启动会

会前

为什么要做？

业务/系统现状分析：明确现有系统情况

痛点分析、机会分析：当前有什么痛点

市场/竞品分析：看看别人做得有多好

业务愿景/中台愿景/公司愿景：顺应大势，已经明确必须要做

具体怎么做？

业务目标、产品目标、产品架构、执行计划

会中

有谁参与？

业务干系人：产品负责人、业务负责人、业务侧研发负责人

产研测干系人：产品经理、研发

其他系统核心干系人：关联、依赖系统都产品经理和研发

会后

马上做什么？

阶段性目标（当前做什么）、启动会明确待办事项（下一步计划）

协作方式？

周初/周末项目例会、日报/周报进展、专题会

案例：分销中台项目启动会

当前业务现状及痛点：从客户（代理人群）分析来看、渠道运营分析，内部运营团队的分析，从外部用户，到内部团队的完整分析，提炼各自还没有被满足的需求，以及当前系统、业务运行中的不足，汇总出业务整体的痛点以及中台参与进来可以帮助大家解决什么问题

分销中台愿景：产品目标

分销中台产品规划：产品架构（大而全）、分阶段计划（3个阶段的分析，讲述完整的怎么做）

制定项目章程

证明项目的存在：明确工作目标、明确责任人、协同机制

以会员纪要的形式呈现，邮件、工作群组送达告知

每次形成新的共识，都需要进行更新

规划

项目路线图

以交付结果来倒退整体中间的过程

工作分解结构

原则：相互独立、完全穷尽

交付成果模式

交付成果：产品模块A+产品模块B+产品模块C

生命周期模式

生命周期：需求分析→产品设计→交付开发→测试→验收上线

案例：分销中台的按交付成果拆解：代理人管理、任务管理、订单跟踪、财务计算、平台运营分销中台的按生命周期拆解：需求调研、产品设计、系统研发、系统测试、业务接入

作用： 1.工作拆解全面，避免执行时有遗漏；2.找到负责人，确保有人负责；

定义

对项目团队为实现项目目标、创建可交付成果而需要实施的全部工作，进行全方位的层级分解

制定项目管理计划

项目进度计划（project）字段：编号、工作任务、负责部门、负责人、人员需求、工时、计划开始时间、计划完成时间

执行

组织项目团队

明确工作事项及负责人，通过启动会达成共识

找到人，参与项目，完成任务

疑难杂症攻克

需求不明确、逻辑走不通、研发卡壳

常见场景：1.产品需求文档评审时2.技术设计文档评审时3.研发执行阶段

1.快速拉会讨论，快速处理，甚至加班加点；

2.妥协，寻求替代方案，确保推进;

3.延期，下下策之选；

实施难度超出想象，工期延期

范围×质量=时间×成本

多（能否砍需求？）

快（能否延期）

好（能否精简、优化MVP）

省（能否协调增加资源）

合作团队研发延期或没有研发资源

1.尽早发现，尽早暴露；

2.强烈的信念和危机感去推动；

3.及时升级，必要时可以砍相应项目；

需求变更管理

判断标准：

只有影响项目成立、业务开展时才变更

a.不做，项目还能否顺利结项（项目顺利执行、业务顺利开展）

b.不得不变时：研发加班、加入或者项目延期

c.可变可不变：纳入需求池，下期再做考虑

监控

业务需求文档评审

1.目的：

规避业务需求变更风险，让产研测完整认识相应的业务

2.内容：

业务背景、业务流程、业务规则、业务场景、业务价值

3.重要点：

业务流程是否完整、闭环？是否具备开发条件和开发价值？

4.参与人员：

业务、产品、UED、项目经理

产品需求文档评审

1.目的：

产品设计是否满足业务需求（满足业务、满足研发）

2.内容：

产品设计思路、产品流程、产品规则

3.重要点：

是否满足业务诉求？是否满足开发条件？

4.参与人员：

业务、产研测、UED、项目经理（标准：往下2级前置）

技术方案设计评审

1.目的：

保证技术的设计思想对业务、产品设计是否正确

2.内容：

技术设计思路、系统流程、系统架构、数据库结构

3.重要点：

是否满足产品诉求？架构、逻辑是否合理？

4.参与人员：

产研测

测试用例评审

1.目的：

测试过程中是否覆盖所有业务场景

2.内容：

测试用例设计思路、测试用例list

3.重要点：

测试用例覆盖场景是否足够？测试条件是否满足?

4.参与人员：

产研测

项目专题会、周例会、日例会

UED探讨会、流程研讨会

监控执行过程中不同阶段遇到的问题

收尾

项目结项

上线公告

a.上线通告：周知类

项目简介、项目价值（对项目成员价值、对管理者的价值、对公司的价值）、核心功能、项目组成员、后续规划、特别鸣谢

b.上线通告：宣传类

项目文档

项目文档字段：项目基本信息：（项目名称、项目经理、项目级别、产品经理、项目归属部门、研发经理、需求所属业务部门、业务负责人、计划上线时间、实际开发时间、实际上线时间）项目期望目标实现程度：（期望目标、期望来源方、项目实现程度）项目里程碑完成情况：（里程碑（项目需求文档、页面设计制作、研发技术方案、部署测试环境、预发布、项目上线发布）、计划时间、实际时间、说明）ROI分析：（投入产出比、人天）项目遗留问题、风险项目团队评价：（项目目标清晰、交付过程是否符合标准、是否理解业务需求、最终产品是否符合项目预期、项目中的风险、问题是否被有效管理、变更是否得到有效控制、项目所需资源是否及时）经验分享、案例总结：（管理层面、业务层面、技术层面）业务验收意见：（项目预期是否准确？是否按期交付？交付过程是否规范？响应是否及时有效？团队能力、素质如何？沟通是否有效？）

项目复盘会

一般过程：

回顾目标（目的、结果、过程、事件）

分析原因（优点、不足）

提炼方法（好方法的坚持和推广、不足的规避和改进）

转化应用（接下来做什么？行动计划）

子主题

用5W1H做好沟通前准备（不在此展开多说，另开脑图讲解）

跨团队沟通的7大策略（不在此展开多说，另开脑图讲解）

七大策略：1.建立人脉；2.功其厉害；3.铁证如山；4.天时地利；5.借力使力；6.南门立木；7.步步为赢；

一个需求提出到产品设计、系统开发、测试并上线运行的全过程，也是使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程

产品运营

中台产品生命周期

系统建设期

存在问题

a.产品体验差、满足不了用户的全部业务需求，产品没人用；

b.产品体验虽好，用户还没感知到好处，产品没人用；

c.用户切换新系统有成本，导致产品没人用；

干系人

产品侧：

寻找中台MVP，快速验证、快速卡位

运营侧：

找到种子户，确保业务跑通

研发侧：

系统建设

工作核心

1.找一批种子用户（从不成熟系统切入 / 为成熟系统赋予新场景）；

2.通过种子用户获取资源，得到线上线下反馈，不断优化产品；

3.赢取更多业务方接入；

流程

找用户→学业务→刷好感→获取资源→沉淀能力→形成案例→更多用户

业务接入期

干系人

产品侧：

务实基础能力、提升运营、技术效率、提升数据表现

运营侧：

业务全面接入

研发侧：

功能迭代、前台业务接入

基本原则

1.业务的个性需求如果强依赖中台，中台应适当做一些定制化开发；

2.业务系统已经实现个性化需求，中台不一定要介入；

全面接入期

循序渐进、持续接入、不断迭代升级

基本原则

1、业务的个性需求如果强依赖中台、中台应适当做一些个性化开发

2、业务系统已经实现个性化需求，中台不一定要接入

如

1.部分业务需给同一产品配置不同价格，中台可以介入做；

2.以H5的方式服务前台，各业务要求的界面风格不一，可由中台配置UI；

成熟运行期

目标

业务全部接入，中台系统已实现规模化运行

方法

1.规模化运行：建立标准（技术标准、业务标准），建立机制（培训机制、准入机制）；

2.提高前台业务接入效率：模块化、组件化；

3.提高业务运营效率：数字化、智能化；

干系人

产品侧：

务实基础能力、提升运营、技术效率、提升数据表现

运营侧：

能力沉淀、建标准、提效率

研发侧：

功能迭代、架构升级

优惠券产品的规模化运营

业务背景

通用产品、使用频率高、调用系统较多，效率和安全问题待提升；

应对方向

建立前台接入标准、提升运营效率、提升业务安全；

解决方案：

1.建立接口介入标准（要求前台业务获取接口时，按中台制定的标准注册）；

2.建立运营标准（建立培训、考试机制，建立知识库，运营人员在线考试通过后获取相应权限）；

3.运营效率提升（打通多系统、多流程的协同壁垒，实现线上智能协同）；

4.系统智能化（个性化、精准化营销，优惠券精准投放）；

时间举例

系统建设期：6个月，从无到有、跑通流程

业务接入期：6个月，前台不断接入、持续推进、业务全部接入、实现去重

系统成熟期：6个月，系统标准化、组件化改造、业务、系统能力不断沉淀、高效运行、快速接入

案例

预约-预售平台完整生命周期

项目背景

如何像某手机厂商饥饿营销一样玩【新品首发】场景？如何通过预售提前锁定客户？

系统建设期

选取合适品类，预约免费种子用户；

在促销期间，选取合适品类，预售种子用户，提前锁定用户；

更多玩法落地（拼购）；

业务接入期

赢取更多品类参与该活动；赢得公司层面的使用；

成熟运行期

提升系统性能（全链路性能监控、架构升级）

机制建立（活动报备机制、培训机制）

组件化拆分（更多预约方式、更多预售方式）

智能化（全链路效果监控、预约-实际销量预测）

衰退期

玩法创新、稳定运行，少量投入

总结

系统建设期

找到业务方未被满足的业务场景、系统能力

寻找种子、跑通系统能力

业务接入期

中台系统不断迭代，逐渐接入全部业务场景

成熟运行期

建立标准、机制，保证业务规模化运行

组件化、智能化，提高前台业务接入效率、业务运营效率

未来与职业发展

如何判断公司具备建设中台的能力？

战略分析

4个维度：战略布局、核心竞争力、战术方法、业务方向

确定现阶段做与不做中台的利弊，明确公司做中台的目标：赋能业务or降本增效or跟风？

业务调研

明确业务单元，梳理业务价值链条，拆解各个业务系统，评估业务中台化的场景

思考问题：通过组件化、模块化、标准化、解耦等方式拆分系统和业务，再基于数据服务化的方式就一定能快速支撑前台业务的迭代更新吗？

数据调研

数据来源、分类管理，做好数据容量、频度、效率的评估，预测数据成长规模

技术调研

公司技术现状，提前了解技术落地、人员技术情况，规避技术风险

组织分析

组织架构分析，明确企业中台的目标与意义，重点取得高层共识，不单单是老板一人的同意

中台产品经理突破点

中台的精髓有3个东西：链接、组件化、数据

链接-沟通合作能力

无论中台前期发展还是后期的商业化发展，始终不能独立产生价值，必须链接上下游，赋能其他系统发挥更大的价值。

组件化-业务拆解能力

基于链接的基础上，进行最小单位地更多组合，为业务赋予更灵活地创新玩法

数据分析能力

由于覆盖全场景业务，数据更加全面，通过全局数据运算，使得业务运销更加精准化

最后一句话

若公司能力达不到（技术与制度架构），还有高层之间没有共同意识，请不要来这趟浑水，不然后续无力，经常背锅。