中台产品经理课程思维导图模板_ProcessOn思维导图、流程图

目的

根据自身所在公司情况，产出完整的中台调研报告

深入认识中台产品并结合公司实际情况进行一些深入思考和分析

学习提要

主讲内容

中台的概念与定义，挑战与困难

中台的工作方法与实战案例

中台建设非常重要的可行性分析，竞品调研，需求和业务的调研

中台产品跨体系/跨职能的多部门项目沟通与协作技巧

不讲内容

Axure/Visio等具体工具的操作

问卷设计，流程/原型绘制等产品经理基本功

非产品经理岗位（如项目经理，UED，运营）的工作开展

学习提示

用辩证与发展的眼光看中台

重规划与经验的总结，轻战略与人事的谋划

课程中的内容，观点，仅代表讲师个人

一、中台产品概述

中台到底是啥？

案例：中央厨房

中台的意义与价值

降本增效

比人眼中的中台

案例：电商产品的前/中/后台划分

前台应用

中台赋能

后台支撑

中台类型

业务中台

技术中台

数据中台

组织中台

算法中台

搜索中台

……

众说纷纭的中台

阿里巴巴中台

京东的中台

王建（ThoughtWorks）对中台的解读

王欣（贝格罗欣）对中台的理解

数据中台火了

数据中台演进四阶段

数据库阶段，主要是OLTP（联机事务处理）的需求

数据仓库阶段，OLAP（联机分析处理）成为主要需求

数据平台阶段，主要解决BI和报表需求的技术问题

数据中台阶段，通过系统来对接OLTP（事务处理）和OLAP（报表分析）的需求，强调数据业务化的能力。

数据智能深度报告，看清数据中台与业务中台的未来

课程中的“中台”定义

为了提炼各个业务线的共性需求，

并将这些打造成平台化，标准化，组件化的系统能力，
然后以接口或服务的形式提供给前台各业务单元使用，

可以使产品在研发迭代，创新拓展的过程中研发更灵活，业务更敏捷，

最大限度的减少“重复造轮子”，“烟囱式系统”的，

KPI项目，组织架构或设计思维

中台能帮我们解决什么问题？

痛点一：企业前方市场与企业内部支撑的冲突

痛点二：前台与后台的冲突

痛点三：大企业的通病（各占山头、重复建设）

产品经理遇到【中台】时的挑战

业务驱动-->产品驱动，支持思维-->主导思维

"眼观六路，耳听八方"，考验需求调研的方法与宏观的业务架构

“手上无粮”，更考验做事的“艺术”

不仅要考虑中台化的系统设计，还要考虑中台化的运营机制

中台项目中遇到的困难与挑战

前期规划

可用资源很有限

整合已有业务的系统模块

从0到1构建中台系统

中台需求不明确

业务场景不聚焦

服务于多个业务，某一业务需求放在其他业务内可能会出现冲突或矛盾

中期建设

产品规划难度大

系统解耦的难度

多业务需求的复杂性

业务逻辑强相关

需要考虑已知的业务状态

还要规划未来业务的发展

后期接入

整合内部阻力大

补充资料

阿里中台到底长啥样？

数据中台，下一个平台型创业机会

从滴滴出行业务中台实践聊聊如何构建大中台架构

腾讯要如何做产业互联网？两个字：生态

有赞周凯：美业连锁面向经营目标的中台思维

中国联通总部集中CRM系统与ESS系统界面划分

如何理解Supercell与美军的中台

《企业IT架构转型之道》

supercell组织灵活，鼓励试错

supercell强大的中台

二、中台实践策略

中台建设过程中的共性问题

从0到1阶段

中台产品该如何确认功能的边界

如何确定哪些功能要做？哪些功能不做？

从1到N阶段

中台产品的迭代目标是什么？

需要有明确的攻坚方向，勿忘中台建设的核心目标

从N到1阶段

如何让各业务接入中台？

纠正误区：认为各业务接入“中台”，一定是在中台完善之后再进行

从0到1阶段

早期产品的设计思路

产品架构：往大的地方想

公司级大项目，覆盖场景广，业务多

落地执行：从小的地方做

找好切入点，从实际角度思考，优先【业务可用】

最优策略：MVP最小可行产品

价值

快速战略卡位

快速满足业务

尽早建立规范

筛选哪些需求应纳入中台MVP中

产品内核

中台成立的最小模型/最基本元素
KONA模型中选择【基本型需求】

系统角度：没它，系统就无法运转？

业务角度：没它，业务能否在中台开展？

公司角度：没它，中台是否还有存在价值

案例：MVP电商中台

商品，订单，账户

线下完成：支付

战略价值

先做什么，对公司/部门/产品价值最大？

开工条件

中台产品交付设计/研发前，所需的前置条件是否被满足？

产品设计

业务流程

业务模式

业务资质

技术条件

合作意愿

最有意愿首先加入，且有一定价值的业务方

案例：分销平台的中台MVP

哪些是产品最基础的模块？【产品内核】

广告主入驻

分销产品管理

代理渠道管理

订单数据统计

分销佣金清算

分销佣金结算

上游：分销产品的接入选择【战略价值&开工条件】

消费贷

现金贷

App下载

财富

保险

电商产品

下游：现有渠道接入选择【合作意愿】

校园站

农村站

旅游站

消费贷（自有渠道）

现金贷（自有渠道）

案例：支付中台的从0到1

MVP支付中台的“产品内核”

支付，退款

交易，账户，渠道

从1到N阶段

确定1到N的产品目标是什么？

夯实基础能力

核心功能，关键业务需求还缺什么？

推荐OKR工作方法

关键目标拆解，关键成果拆解

案例：触达系统的从1到N

助力运营效率

案例：线上自主解除实名认证&销户

案例：优惠券实时运营控制台

助力研发效率

平台化

系统集成/统一，减少重复开发

标准化、组件化

支持前台系统灵活调用

产品化，商业化

支持对外输出

案例：促销系统组件化

提升数据表现

产品质量量化

收入指标

GMV，毛利，客户覆盖率，市场占有率

产品指标

用户停留时长，转化率，跳出率，留存率，UV，PV

内部效率(技术指标)

需求响应速度，系统服务客户数，节约的人力成本(时间/人数)

接口调用量，服务响应速度，成功数，bug数

案例：触达系统验证的技术指标

如何筛选需求？

业务叫的最凶

客户投诉最多

老板期望最高

产品价值最优

案例：支付中台的从1到N

总目标

沉淀增强支付能力

提供人力效能

夯实基础能力

新增风控模块

新增收银台，网关，路由，营销，运营

助力运营效率

中台新增运营后台，按需增加运营权限，让运营快捷查询支付问题

助力研发效率

支付系统组件化

支付服务，红包服务，提现服务，担保支付服务，优惠券服务

接入流程标准化

出具规范的接入文档，包括接入流程，接口规范，案例说明

提升数据表现

业务目标

接入的业务数量

支付转化率是否提升

技术目标

支付成功率是否提升

业务接入耗时是否缩短

从N到1阶段

主要问题

多个业务接入中台的问题

中台调研立项时就应考虑，识别风险并采取措施

从N套系统合并到1套系统的主要挑战

各业务单位系统与运营机制层次不齐

整合过程中/过程后，业务部门短期往往“得不偿失”

案例：页面数据采集系统整合

1、调研现状（进行摸底）

系统分析报告（简）

2、调研完整业务需求

需求调研报告

3、对标行业标杆，竞品分析

竞品分析报告

4、深入梳理现有系统

系统分析报告

5、产品方案设计

产品设计方案

6、项目推进策略

项目推进规划

7、项目落地执行

研发进度排期

案例：营销系统整合

子主题

“交出来”“还回去”的判断标准

系统覆盖的业务场景过窄，不可复用

中台产研来做，成本反而更高

三、中台的调研与分析

什么时候才能开始建设中台？

不取决于公司的大小

只取决于是否需要快速扩张

如何进行调研，产出中台调研报告呢？

目前企业是否适合进行中台能力建设？

竞品企业是否有相关的中台系统建设？具体是如何执行的？

各业务线的需求是什么？哪些是个性需求?哪些是共性需求？

目前业务情况是如何的？未来接入中台会遇到的问题有哪些？

第一步：可行性分析

学习内容

判断公司目前的情况适合不适合做中台

判断公司目前的情况做中台带来的价值，值不值得去做

业务背景分析

明确公司是否适合中台建设

对于目前业务处于极速扩展阶段的企业更适合中台建设

如何进行

一、业务规划与发展战略是否适合中台建设？

公司战略规划

紧缩收拢？

平稳过度？

快速扩张？

老业务的扩张

在老业务上衍生出来的新业务？

全新领域的新业务的扩张

二、业务模式是否可以快速复用？

能够复用是基础

“快速”是前提

案例：支付中台

三、业务之间是否存在共性需求？

有没有有价值的共性需求？

可以是提供基础服务的中台系统

用户系统

账号系统

也可以是跟业务强相关，重要的，核心的中台系统

风控系统

仓储系统

商品系统

只考虑“适不适合”，不考虑“值不值得”

业务价值分析

中台“值不值得做”

1、用户价值

能够给用户带来什么样的好处？

能够满足用户什么需求？

能够为用户解决什么样的痛点？

2、产品价值

能对产品的各项指标产生怎样的影响？

留存/日活/转化率/……

3、商业价值

这个项目能否给公司挣到钱？挣多少钱？/省多少钱？

未来的商业潜力有多大？

具体业务指标

业务类指标

销售额，DAU，市场占有率

提升效率/降低成本类

降低人力成本，提高运营效率

系统类

事故率，接口调用时长

第二步：竞品调研

中台竞品调研的痛点

中台成熟较晚，可借鉴的对象很少，不知道调研谁

不知道调研什么产品

中台大多对内服务，外界很难看到全貌，尤其是背后的逻辑

无法直接接触产品

即使找到调研对象，由于业务逻辑不同，系统逻辑不同，所能获取信息有限，

中台产品“门道”在深处

中台竞品调研的基本流程

竞品调研流程

目的

认识

充分理解产品

还原

分析，归纳

创造

得出结论，明确动作

报告

竞品调研的价值

学习优点

通过竞品分析，加深行业知识，分析优缺点，找到可借鉴的地方

改进功能

针对性分析竞品（业务流程，交互设计，功能架构）竞品怎么做-->我们该怎么做

研究战略

分析对手的战略方向&核心竞争力，明确自己在市场上的竞争力和增长点

设定分析框架

产品体验

交互体验

页面UI

功能点调研

业务流程

功能框架

产品调研

业务形态

需求场景

数据表现，功能迭代，运营路径

市场调研

行业现状/市场前景

竞品调研三大痛点的解决方法

看不见

从【人】和【事】的角度选好竞品

从【人】

自己

上级领导

从【事】

标杆，同行，异业

摸不着

四诊会参

“望”

有目的的观察，阅读

看新闻i，看友商动态

看友商员工/大牛分享的文章

关注友商每Q财报

看友商招聘岗位，

“闻”

听“声音”，“闻”气味

参加行业峰会

听友商大牛分享

参加友商组织的展会活动

“问”

寻找直接干系人或间接干系人

问友商

问友商上下游

问咨询公司

找茬问对方客服

“切”

上手体验友商产品

全流程、全方位体验友商产品

正向，逆向，异常操作

玩不透

练

勤学，勤问

案例

案例1：阿里账号体系调研

案例2：平安金管家代理人端的功能学习

第三步：需求分析

课程目标

让中台产品经理在了解目前各业务线逻辑的情况下，挖掘所涉及业务线的各项需求，做好后期中台方案设计的基础

中台产品经理与其他产品对需求分析的不同点

中台需求的提出者并非直接业务的干系人

“中台化”往往只是个愿景，需求很难明确（甚至提出者自己也不清楚要什么）

中台化项目动辄覆盖公司大部分业务，任何一处疏漏，都是在给自己“埋雷”

需求背景分析的关键步骤

1、需求干系人分析

为什么要强调【需求干系人分析】？

需求提出方!=系统使用方

除了对接老板，还要对接业务负责人

一句话需求/愿景

通过业务干系人学习业务知识，探索业务需求

部门需求/意愿参差不齐

全面识别干系人并了解干系人背景

识别&获取需求干系人的一般方法

初始需求来源

干系人选择策略

1、业务负责人直接提出

直接对接业务负责人

2、业务部门接口人提出

先访谈接口人，然后再访谈业务负责人

3、业务部门的经理提出

有机会直接访谈总经理，没机会让总经理指定对接人

4、自己的上司直接提出

访谈上司，通过项目范围再延展到其他干系人

5、业务部门向自己的上司提出

直接访谈上司，只与上司对话，由上司对外对话

先访谈上司，通过上司获取业务对接人

先访谈上司，通过其他渠道获取业务对接人

6、事业部CEO或公司CEO提出

有机会，直接访谈CEO

没有机会访谈CEO，寻找业务干系人

识别&获取需求干系人的基本原则

看组织架构

问身边熟系的人

问自己的上司

问业务部门负责人

/2、目标/愿景访谈

如何访谈，有什么访谈策略？

从问题的角度看，目前系统有什么问题，该如何改进？

从机会的角度看，目前市场有什么新机会？该如何拓展？

从【问题】出发的访谈策略

起因

访谈策略

外部触发

参观考察

分享考察后的收获

竞争对手动向

竞品分析

热点与新技术趋势

分享理解

政策变动

政策解读

内部提出

公司战略

分享战略

业务运行

了解业务运行情况

系统运行

了解系统运行情况

从【机会】出发的访谈策略

机会场景

访谈策略

新业务

追标杆：行业标杆在发展过程中有的和借鉴点

赛同行：同行竞争者有的和借鉴点

借它业：其他行业有何借鉴点

新技术

新技术带来哪些新机会？

当前新技术应用有何借鉴点？

新技术能够解决哪些当前无法解决的业务问题？

新场景

客户群体有了哪些新变化？

业务范围是不是有了新变化？

公司战略重心是不是发生了变化？

决策层，管理层是否出现了新人群？

/3、整理干系人关注点

整理干系人关注点表格

所属部门、姓名、岗位角色，核心关注点，相关度，影响度

评估需求的必要性

两个维度

产品价值

技术成本

需求类型

基本型需求

产品“必须有”的属性与功能

期望型需求

没有可以正常开展业务，有了更好

需求评估，确定业务目标优先级

所属部门，业务目标，需求类型，产品价值，技术成本，评估结果

4、评估需求优先级并确定业务目标

5、评估立项

案例一

某金融公司账号体系

项目背景，

需求来源

第一轮干系人访谈--我的上司

第二轮-消费金融业务负责人A总

第三轮-支付业务负责人A总

第四轮-风险业务负责人A总

第5轮-其他业务负责人A总

干系人分析

干系人需求评估

业务目标确认

准备材料&项目立项

案例二

分销中台项目

需求源起

一句话需求

干系人分析

访谈各业务分销业务形态

具体的业务流程理解

提炼分销架构

第一轮访谈：摸清现在都有哪些分销业务？搞清当前分销业务是什么流程

第二轮：访谈CEO的业务目标/业务期望

整理CEO的关注点

第三轮：落实CEO的业务预期

各业务线业务负责人访谈

代理人群分析

渠道运营方分析

分析业务痛点分析

分析业务目标

分销业务解决方案概览

分销中台项目执行计划

第四轮：想CEO汇报，确分销中台业务目标与产品方向

第四步：业务分析

业务分析是中台调研中比较关键的步骤，是最终产出中台设计方案的基石

1、业务流程分析

中台不仅关注“信息”的传递，还需关注“商务运转规则”，物流模式和资金流

l流程是什么？

流程分析的价值

子主题

业务角度常见的【四流】

商业流

主要是买卖的流通过程

信息流

商品及交易信息的流程

物资流

主要是物资（商品）的流通过程

资金流

货币的流通过程

业务流程分析方法

1、选择流程图描述方式

跨职能流程图/活动图，序列图

2、勾勒流程主体

分工，活动、协作，分支，产物关系

3、补充事中管控点

审核，规则，异常情况

4、分析执行中的监管要求

案例：分销中台项目--商业流程实例

案例：电商用户购物流程--信息流示意，物资流示意，资金流示意

案例：线上冲印项目的业务流程分析

1、我司向供应商发起采购，并签订采购合同

2、供应商发货到我司库房，库房盘活上架

3、商品系统上架，用户线上交易流程

4、照片冲印

5、照片冲印后配送

6、用户不满意，要退货

7、平台与供应商按成交量结算

2、业务场景分析

新闻六要素（也就是记叙要素）：时间、地点、人物、事件的起因、经过、结果。即五个“W”和一个“H”　即Who（何人）、What（何事）、When（何时）、Where（何地）、Why（何因）、How（如何）。

业务场景分析六维度参考

时间

早/中/晚

地点

室内/室外，公司/家里

人物

儿童/青年/老年，新用户/老用户

起因

因为什么原因

主动/被动

经过

经过什么方式

PC/H5,App，微信小程序，内部/外部登录

结果

达到什么结果

调战略、做动作，娱乐/效率

案例：短信系统业务场景分析

案例：用户回流场景分析

3、业务规则分析

业务规则是业务逻辑的细新颗粒度，也是中台产品最耗神的环节

规则分类

1、全局规则

与所有用户而不是特定用例相关

例如：用户操作，埋点，风控安全

2、内禀规则

业务本身具备，不因外部交互而改变

每个订单至少1个商品，身份证号码15-18位，邮政编码6位

3、交互规则

产生与用例场景中

必填信息，身份合法校验，业务流转规则等

获取方法

1、全局规则

由业务特点，应用环境，行业规定，法律规章等

由经验丰富的业务负责人，产品经理，研发人员等总结

2、内禀规则

对每个具体业务的属性进行罗列，找出他们的规则

主要来自业务执行者

3、交互规则

与多业务部门讨论，结合系统设计提出

主要源自业务提出者，业务管理者，产品经理，UI/UE

示例

1、全局规则

登录校验

访问权限

数据统计

2、内禀规则

上传照片的大小要求（100*100，350*350等）

手机型号选择（16G，32G，64G等）

开通钱包必须要实名认证

3、交互规则

哪些信息必填/非必填？

支付金额超出限额怎么办？

提交文件超出限额大小怎么办？（比如限制5M）

反面案例：分销中台项目需求分析遇到的坑

四、中台产品设计

中台产品设计的框架步骤

1、明确产品模式

产出一张中台设计模式图，帮助产品经理向业务，产品，研发，领导等种种角色汇报时，说明“中台产品”到底长啥样

2、逐个模块拆解

产出一套拆解到二级（三级）功能的功能细目，完善并明确你的系统方案

3、详细功能设计

产出对中台产品中（往往逻辑较为复杂）的功能描述---通过流程，原型，规则三者共同描述清晰每个功能

中台产品设计与一般系统的方案设计区别

1、覆盖的业务场景多，一旦返工，成本较高

2、既要考虑当前业务的复用，还要预见未来业务场景

3、业务“紧急”VS业务“重要”，中台产品经理需要“有主见”

1、明确产品模式

产品模式

（这个中台产品）到底长什么样，能帮助哪些业务/系统，提供什么能力，解决什么问题

有哪些功能？

服务于哪些系统？

依赖于哪些系统？

如何设计产品模式

明确中台产品核心模块（一级即可）

如：电商的-商品系统，用户系统，订单系统，支付系统

2、服务于前台哪些业务/系统？

3、对前台业务/系统的服务方式？

H5页面

前台业务直接使用的“页面”

SDK

需要原生App的场景下，可通过sdk封装

API

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

4、后端依赖/打通哪些系统或服务？

例如：CRM，OA，底层系统

一句话明确产品模式

xxxx中台系统，有（哪些中台模块），通过（哪些服务方式）服务于（哪些前台业务/系统）

这需要依赖/打通（哪些后台系统或服务）

中台产品架构图

xxxx中台系统

前台应用

服务方式

中台系统以及模块

后台系统或服务

案例：电商中台产品模式

前台应用

火车票，机票，房地产，家电

服务方式

H5，API，SDK

中台系统

商品系统，用户系统，订单系统，支付系统

后台服务

采购系统，财务系统，仓储系统，大数据

2、逐个模块拆解

逐个模块拆解

具体功能清单

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

角色

在系统之外与系统交互的某人或某物

模块拆解的详细流程

1）明确大致系统

2）明确参与角色

3）拆解一级模块（通过【角色-用例】关系）

4）细化至二级/三级/四级……模块

案例：分销中台项目

角色:B2P2B2A2C

广告主

平台运营方

代理运营方

3、详细功能设计

产出

中台产品设计方案的PRD

把功能描述清楚

1、梳理产品流程

业务流程梳理方法

/2、绘制原型，明确交互

显示字段

显示文案

交互逻辑

/3、明确产品规则

全局规则+内禀规则+交互规则

中台产品需求说明文档PRD

业务背景

需求概述

需求详述

补充：如何搞定横跨多个系统的交互逻辑

表现形式

时序图

跨职能流程图

全局呈现，单个突破

中台产品设计中遇到坑

业务需求调研不彻底

【对业务】需求调研务必完善，切勿心存侥幸

依赖关系定位不清

【对底层】适当深入底层，避免简单透传

统一标准难建立

【对中台】抓大放小，明确主要矛盾

五、中台项目推进

子主题

中台项目管理的五大过程

项目启动过程

项目规划过程

项目执行过程

项目监控过程

项目收尾过程

中台项目管理的关键动作

小结

用“六何”分析法沟通

5W1H分析法（“六何”分析法）

1、Why（何因）

首先思考原因：

为什么要沟通？（目的）

沟通的真正原因是什么？（背景）

希望得到什么（获得资源/改变观点/解决投诉/...）？(结果)

2、What（何事）

明确要做什么（需求调研、方案宣讲、进度汇报、处理投诉）？

提前思考：

我们到底谈什么？

我需要讲什么？

他们需要了解什么？

3、Who（何人）

对不同的人，选择不同的沟通策略：

与谁进行沟通？

4、Where（何地）

谁是主战场？
业务需求阶段：去业务部门的地盘儿开会，“上门服务”
研发阶段：坐守产品研发的主战场
谁的地位高？
谁求谁？谁需要？谁受益，谁受害？
为什么要在这个地方？换个地方行不行？

5、When （何时）

选择前先思考：
在什么时间沟通？为什么要在这个时间沟通？能不能换个时间？

6、How（何法）

如何传递信息？
如何安排我要表达的观点？
如何才能预期效果？
凡事预则立，不预则废。

跨团队沟通的7大策略

1、创建并培养你的关系网

创建并培养你的关系网络

与你可信赖或依赖的人

与关键人物建立信任

1、如何找到关键人物，培养关系网络？

工作场合

换位思考，多提建议，真诚帮助

非工作场合

个人兴趣爱好
礼尚往来

2、倡导益处

3、收集证据

4、考虑环境因素

5、取得第三方参与

6、鼓励对方参与

7、策划小的胜利

案例

六、中台产品运营

中台产品的“生命周期”

1、系统建设期

2、全面接入期

3、系统成熟期