中台设计管理
2019-12-09 11:11:52 56 举报
AI智能生成
中台设计管理
作者其他创作
大纲/内容
项目推进
挑战
从无到有,项目周期较长
涉及业务较多,任何一步的质量都非常重要
业务结构、人员复杂,沟通技巧、推进方法极受考验
方法
中台项目管理中的关键动作
启动
项目干系人识别
组织项目启动会
为什么要做?
业务/系统现状分析:明确现有系统情况
痛点分析、机会分析:当前有什么痛点
市场/竞品分析:看看别人做得有多好
业务愿景/中台愿景/公司愿景:顺应大势,已经明确必须要做
具体怎么做?
业务目标、产品目标、产品架构、执行计划
有谁参与?
业务干系人:产品负责人、业务负责人、业务侧研发负责人
产研测干系人:产品经理、研发
其他系统核心干系人:关联、依赖系统都产品经理和研发
协作方式?
周初/周末项目例会、日报/周报进展、专题会
马上做什么?
阶段性目标(当前做什么)、启动会明确待办事项(下一步计划)
案例:分销中台项目启动会
当前业务现状及痛点:
从客户(代理人群)分析来看、渠道运营分析,内部运营团队的分析,从外部用户,
到内部团队的完整分析,提炼各自还没有被满足的需求,以及当前系统、业务运行中的不足,
汇总出业务整体的痛点以及中台参与进来可以帮助大家解决什么问题
从客户(代理人群)分析来看、渠道运营分析,内部运营团队的分析,从外部用户,
到内部团队的完整分析,提炼各自还没有被满足的需求,以及当前系统、业务运行中的不足,
汇总出业务整体的痛点以及中台参与进来可以帮助大家解决什么问题
分销中台愿景:产品目标
分销中台产品规划:产品架构(大而全)、分阶段计划(3个阶段的分析,讲述完整的怎么做)
制定项目章程
证明项目的存在:明确工作目标、明确责任人、协同机制
以会员纪要的形式呈现,邮件、工作群组送达告知
每次形成新的共识,都需要进行更新
规划
项目路线图
工作分解结构
原则:相互独立、完全穷尽
作用:
1.工作拆解全面,避免执行时有遗漏;
2.找到负责人,确保有人负责;
1.工作拆解全面,避免执行时有遗漏;
2.找到负责人,确保有人负责;
制定项目管理计划
执行
组织项目团队
找到人,参与项目,完成任务
疑难杂症攻克
需求不明确、逻辑走不通、研发卡壳
1.快速拉会讨论,快速处理,甚至加班加点;
2.妥协,寻求替代方案,确保推进;
3.延期,下下策之选;
2.妥协,寻求替代方案,确保推进;
3.延期,下下策之选;
实施难度超出想象,工期延期
范围×质量=时间×成本,
多(能否砍需求?)
快(能否延期)
好(能否精简、优化MVP)
省(能否协调增加资源)
多(能否砍需求?)
快(能否延期)
好(能否精简、优化MVP)
省(能否协调增加资源)
合作团队研发延期或没有研发资源
1.尽早发现,尽早暴露;
2.强烈的信念和危机感去推动;
3.及时升级,必要时可以砍相应项目;
2.强烈的信念和危机感去推动;
3.及时升级,必要时可以砍相应项目;
需求变更管理
判断标准:
a.不做,项目还能否顺利结项(项目顺利执行、业务顺利开展)
b.不得不变时:研发加班、加入或者项目延期
c.可变可不变:纳入需求池,下期再做考虑
a.不做,项目还能否顺利结项(项目顺利执行、业务顺利开展)
b.不得不变时:研发加班、加入或者项目延期
c.可变可不变:纳入需求池,下期再做考虑
监控
业务需求文档评审
1.目的:规避业务需求变更风险,让产研测完整认识相应的业务
2.内容:业务背景、业务流程、业务规则、业务场景、业务价值
3.重要点:业务流程是否完整、闭环?是否具备开发条件和开发价值?
4.参与人员:业务、产品、UED、项目经理
2.内容:业务背景、业务流程、业务规则、业务场景、业务价值
3.重要点:业务流程是否完整、闭环?是否具备开发条件和开发价值?
4.参与人员:业务、产品、UED、项目经理
产品需求文档评审
1.目的:产品设计是否满足业务需求(满足业务、满足研发)
2.内容:产品设计思路、产品流程、产品规则
3.重要点:是否满足业务诉求?是否满足开发条件?
4.参与人员:业务、产研测、UED、项目经理(标准:往下2级前置)
2.内容:产品设计思路、产品流程、产品规则
3.重要点:是否满足业务诉求?是否满足开发条件?
4.参与人员:业务、产研测、UED、项目经理(标准:往下2级前置)
技术方案设计评审
1.目的:保证技术的设计思想对业务、产品设计是否正确
2.内容:技术设计思路、系统流程、系统架构、数据库结构
3.重要点:是否满足产品诉求?架构、逻辑是否合理?
4.参与人员:产研测
2.内容:技术设计思路、系统流程、系统架构、数据库结构
3.重要点:是否满足产品诉求?架构、逻辑是否合理?
4.参与人员:产研测
测试用例评审
1.目的:测试过程中是否覆盖所有业务场景
2.内容:测试用例设计思路、测试用例list
3.重要点:测试用例覆盖场景是否足够?测试条件是否满足?
4.参与人员:产研测
2.内容:测试用例设计思路、测试用例list
3.重要点:测试用例覆盖场景是否足够?测试条件是否满足?
4.参与人员:产研测
项目专题会、周例会、日例会
收尾
项目结项
上线公告
项目文档
项目复盘会
一般过程:
- 回顾目标(目的、结果、过程、事件)
- 分析原因(优点、不足)
- 提炼方法(好方法的坚持和推广、不足的规避和改进)
- 转化应用(接下来做什么?行动计划)
用5W1H做好沟通前准备(不在此展开多说,另开脑图讲解)
跨团队沟通的7大策略(不在此展开多说,另开脑图讲解)
产品运营
中台产品生命周期
系统建设期
- 产品侧:寻找中台MVP,快速验证、快速卡位
- 运营侧:找到种子户,确保业务跑通
- 研发侧:系统建设
业务接入期
- 产品侧:务实基础能力、提升运营、技术效率、提升数据表现
- 运营侧:业务全面接入
- 研发侧:功能迭代、前台业务接入
成熟运行期
- 产品侧:务实基础能力、提升运营、技术效率、提升数据表现
- 运营侧:能力沉淀、建标准、提效率
- 研发侧:功能迭代、架构升级
举例子
案例:
- 系统建设期:6个月,从无到有、跑通流程
- 业务接入期:6个月,前台不断接入、持续推进、业务全部接入、实现去重
- 系统成熟期:6个月,系统标准化、组件化改造、业务、系统能力不断沉淀、高效运行、快速接入
系统建设期
存在问题:
a.产品体验差、满足不了用户的全部业务需求,产品没人用;
b.产品体验虽好,用户还没感知到好处,产品没人用;
c.用户切换新系统有成本,导致产品没人用;
a.产品体验差、满足不了用户的全部业务需求,产品没人用;
b.产品体验虽好,用户还没感知到好处,产品没人用;
c.用户切换新系统有成本,导致产品没人用;
工作核心:
1.找一批种子用户(从不成熟系统切入 / 为成熟系统赋予新场景);
2.通过种子用户获取资源,得到线上线下反馈,不断优化产品;
3.赢取更多业务方接入;
1.找一批种子用户(从不成熟系统切入 / 为成熟系统赋予新场景);
2.通过种子用户获取资源,得到线上线下反馈,不断优化产品;
3.赢取更多业务方接入;
流程:
找用户→学业务→刷好感→获取资源→沉淀能力→形成案例→更多用户
找用户→学业务→刷好感→获取资源→沉淀能力→形成案例→更多用户
全面接入期
基本原则:
1.业务的个性需求如果强依赖中台,中台应适当做一些定制化开发;
2.业务系统已经实现个性化需求,中台不一定要介入;
1.业务的个性需求如果强依赖中台,中台应适当做一些定制化开发;
2.业务系统已经实现个性化需求,中台不一定要介入;
成熟运行期
目标:
业务全部接入,中台系统已实现规模化运行
业务全部接入,中台系统已实现规模化运行
方法:
1.规模化运行:建立标准(技术标准、业务标准),建立机制(培训机制、准入机制);
2.提高前台业务接入效率:模块化、组件化;
3.提高业务运营效率:数字化、智能化;
1.规模化运行:建立标准(技术标准、业务标准),建立机制(培训机制、准入机制);
2.提高前台业务接入效率:模块化、组件化;
3.提高业务运营效率:数字化、智能化;
案例:优惠券产品的规模化运营
业务背景:通用产品、使用频率高、调用系统较多,效率和安全问题待提升;
应对方向:建立前台接入标准、提升运营效率、提升业务安全;
解决方案:
1.建立接口介入标准(要求前台业务获取接口时,按中台制定的标准注册);
2.建立运营标准(建立培训、考试机制,建立知识库,运营人员在线考试通过后获取相应权限);
3.运营效率提升(打通多系统、多流程的协同壁垒,实现线上智能协同);
4.系统智能化(个性化、精准化营销,优惠券精准投放);
业务背景:通用产品、使用频率高、调用系统较多,效率和安全问题待提升;
应对方向:建立前台接入标准、提升运营效率、提升业务安全;
解决方案:
1.建立接口介入标准(要求前台业务获取接口时,按中台制定的标准注册);
2.建立运营标准(建立培训、考试机制,建立知识库,运营人员在线考试通过后获取相应权限);
3.运营效率提升(打通多系统、多流程的协同壁垒,实现线上智能协同);
4.系统智能化(个性化、精准化营销,优惠券精准投放);
案例:预约-预售平台完整生命周期
项目背景:如何像某手机厂商饥饿营销一样玩【新品首发】场景?如何通过预售提前锁定客户?
系统建设期:
成熟运行期:
系统建设期:
- 选取合适品类,预约免费种子用户;
- 在促销期间,选取合适品类,预售种子用户,提前锁定用户;
- 更多玩法落地(拼购);
成熟运行期:
- 提升系统性能(全链路性能监控、架构升级)
- 机制建立(活动报备机制、培训机制)
- 组件化拆分(更多预约方式、更多预售方式)
- 智能化(全链路效果监控、预约-实际销量预测)
总结
系统建设期
- 找到业务方未被满足的业务场景、系统能力
- 寻找种子、跑通系统能力
业务接入期
中台系统不断迭代,逐渐接入全部业务场景
成熟运行期
- 建立标准、机制,保证业务规模化运行
- 组件化、智能化,提高前台业务接入效率、业务运营效率
未来与职业发展
如何判断公司具备建设中台的能力?
战略分析
4个维度:战略布局、核心竞争力、战术方法、业务方向
确定现阶段做与不做中台的利弊,明确公司做中台的目标:赋能业务or降本增效or跟风?
业务调研
明确业务单元,梳理业务价值链条,拆解各个业务系统,评估业务中台化的场景
思考问题:通过组件化、模块化、标准化、解耦等方式拆分系统和业务,
再基于数据服务化的方式就一定能快速支撑前台业务的迭代更新吗?
再基于数据服务化的方式就一定能快速支撑前台业务的迭代更新吗?
数据调研
数据来源、分类管理,做好数据容量、频度、效率的评估,预测数据成长规模
技术调研
公司技术现状,提前了解技术落地、人员技术情况,规避技术风险
组织分析
组织架构分析,明确企业中台的目标与意义,重点取得高层共识,不单单是老板一人的同意
中台产品经理突破点
纵观整个脑图,中台的精髓有3个东西:链接、组件化、数据
链接-沟通合作能力:
无论中台前期发展还是后期的商业化发展,始终不能独立产生价值,
必须链接上下游,赋能其他系统发挥更大的价值。
无论中台前期发展还是后期的商业化发展,始终不能独立产生价值,
必须链接上下游,赋能其他系统发挥更大的价值。
组件化-业务拆解能力:
基于链接的基础上,进行最小单位地更多组合,为业务赋予更灵活地创新玩法
基于链接的基础上,进行最小单位地更多组合,为业务赋予更灵活地创新玩法
数据分析能力:
由于覆盖全场景业务,数据更加全面,通过全局数据运算,使得业务运销更加精准化
由于覆盖全场景业务,数据更加全面,通过全局数据运算,使得业务运销更加精准化
最后一句话
若公司能力达不到(技术与制度架构),还有高层之间没有共同意识,
请不要来这趟浑水,不然后续无力,经常背锅。
请不要来这趟浑水,不然后续无力,经常背锅。
概述
一句话讲解
汇总所有业务的数据运营能力、产品技术能力,快速支撑业务迭代更新,并且可以发展成独立运营的产品
现状
系统复杂,无法快速拿出产品方案
多重对接,沟通成本巨大
系统间耦合性较大,牵一发而动全身
特性
通用性
结构化
标准化
可拓展
设计方法论
业务抽象
需求分析
竞品分析
功能分析
业务分析
用户分析
方案设计
业务设计
架构设计
方案落地:项目管理与推进
上线运营:基于生命周期的产品运营
经典中台产品
阿里:小后台、大中台、小前台战略
华为:平台炮火支撑精兵作战战略
Supercell:中台概念最初实践者
业务抽象
需求分析
需求分析全景图
需求背景
干系人
最关键的干系人有哪些人?
干系人的关注点、担心点是哪些?
目标、背景
评估需求
确认业务目标
业务分析
业务流程
业务规则
业务场景
业务价值
用户分析
确定用户
用户目标
用户场景
功能分析
交互流程
业务、用户规模
服务方式
数据/监控
性能要求
分析流程
分销中台需求分析案例
需求、业务分析
干系人:老板CEO、各业务负责人、各业务产品
访谈内容:
1.代理人层级模式;
2.代理发展方式;
3.分销产品需求;
4.业务模式特点;
5.对接人。
1.代理人层级模式;
2.代理发展方式;
3.分销产品需求;
4.业务模式特点;
5.对接人。
机会:
1.70%的分销业务是相同的,只有30%的个性需求由各自业务特点决定;
1.70%的分销业务是相同的,只有30%的个性需求由各自业务特点决定;
问题:
1.代理人管理薄弱;
2.没有很好的工具很好地帮助代理人转化客户;
3.未被转化的客户不能很好管理追踪;
1.代理人管理薄弱;
2.没有很好的工具很好地帮助代理人转化客户;
3.未被转化的客户不能很好管理追踪;
各分销业务架构、流程
用户分析
代理人群分析
渠道运营方分析
确认分销业务目标及架构
1.分销业务统一管理、研发集中赋能、资源共享;
2.赋能各业务运营团队及代理人进行C端用户运营;
2.赋能各业务运营团队及代理人进行C端用户运营;
方案设计
架构设计
明确产品模式
明确中台核心模块
确定服务于前台哪些业务、系统
确定对前台业务、系统的服务方式
H5
API
SDK
明确后台依赖或打通的系统、服务
业务设计
功能模块拆解
目标产出
1.待设计的具体功能清单
2.功能-角色的对应 关系,以便后续设计时,场景 / 权限明确
2.功能-角色的对应 关系,以便后续设计时,场景 / 权限明确
模块拆解的详细流程
明确大致系统
明确参与角色
拆解一级模块
细至二级、三级、四级模块
业务流程
选择流程图描述方式
跨职能流程图、活动图
序列图
勾勒流程主体
分工
活动
协作
分支
产物关系
补充事中管控点
审核
规则
异常
分析执行中的监管需求
进度、效率
异常点监控
其他需求
如何搞定多个系统的交互逻辑
重点关注扯皮或逻辑异常复杂的环节
灵活补位:产品、研发、项目经理均可能补位
产品原型
具体字段
显示文案
交互逻辑
业务规则
全局规则
内禀规则
交互规则
方案设计常见的坑
需求调研不彻底,返工成本较高 → 前期做好需求调研与分析,覆盖业务全部场景;
依赖关系定位不清 → 了解各业务逻辑,进行多轮评审
难以建立统一标准 → 制定人员轮岗方案和机制
3种典型中台设计场景的关键点
从0到1
产品内核
MVP:最小模型 / 基本模型
3个战略价值
公司的战略价值
部门的战略价值
产品本身的战略价值
开工条件
产品设计、业务流程、业务模式、技术条件、业务资质
合作意愿
最有意愿加入、且有一定价值的业务方
从1到N
目标
务实基础能力
了解痛点、明确问题
助力研发效率
提升数据表现
如何筛选需求和目标?
业务叫得最多
客户投诉最多
老板期望最高
产品价值最优
从N到1
挑战
各业务单元系统参差不齐
投入时间充分调研,保证业务场景分析全面,方案设计全覆盖
全面深入地梳理业务现状,找到有效的业务切入点
整合过程中,业务部门短期见不到改造收益
先整合不成熟、切换成本低的系统,逐渐整合成熟系统
前置考虑到整合、接入的成本,提前计划、备好资源,确保有效推进
业务场景窄、中台化成本高的业务,还回到业务系统中自行处理
流程
调研现状
到底有多少套系统?为什么存在这么多套?
调研完整业务需求
对标现有系统,调研各业务真实需求和差异化需求,全面汇总
对标行业标杆
成熟系统怎么做?可借鉴内容
深入梳理现有系统
详细分析每套系统,看每套系统业务、功能、表现成熟度
产品方案设计
以其中一套系统为基础,升级改造
项目推进策略
制定过渡方案、实施步骤
项目落地执行
逐步推进各业务系统单元废除老系统,切换新系统
0 条评论
下一页