中台与数字化转型(三):如何进行B端业务调研及避坑指南

10 评论 9647 浏览 20 收藏 12 分钟

编辑导语:在产品设计开始前,产品经理常常需要做业务调研,但是在业务调研过程中,会遇到很多问题,导致后续步骤无法顺利推进。作者从实践中总结出了一套如何进行B端业务调研的方法论以及一份避坑指南,供大家参考。

在中台产品经理面试的过程中,我经常会问“如何做业务调研?”很多产品经理对这个问题的回答特别简单:找相关的业务部门,了解具体流程,然后设计产品。甚至有些产品经理说,“业务不太懂产品,我们调研比较少,都是我们自己找竞品对照”,这些回答是典型不重视业务调研的表现。

所谓业务调研,是对业务的全过程进行还原,并进行需求和痛点的挖掘过程。所以业务调研是B端产品经理了解业务最重要的环节。业务调研不充分会带来以下问题:

  • 需求挖掘不深入,设计出的产品业务不想用
  • 产品上线,场景缺失严重,业务不闭环
  • 多次轮番调研,业务不耐烦,折腾人
  • 好不容易上线产品,老板不看好
  • 都是点状需求,看不到业务价值

可见业务调研不充分,危害极大,严重时会出现方案汇报不通过而导致项目中止情况。

那么如何组织一场体系化的业务调研,作者在实践中总结一套调研方法论,供大家参考:

一、根据项目大小确定调研组合

我们把调研分为四种类型:高层调研,业务调研,专题调研和补充调研。

  • 高层调研:老板为什么启动这个项目,项目的战略意义和老板的期待
  • 业务调研:按照业务模块或部门,调研具体的业务场景,业务流程,业务规则
  • 专题调研:业务调研过程中,遇到复杂问题或跨部门决策问题,则需要启动专题讨论
  • 补充调研:产品设计过程中,发现之前业务逻辑了解不够细致,需要启动小范围或一对一的补充调研

根据项目大小的不同,确定调研组合:

(1)企业级战略项目,老板也特别重视,那么首先要做高层战略调研。了解老板为什么启动这个项目,项目的战略意义和老板的期待。

(2)如果是企业在实际经营过程中,启动的专项项目。比如OMS,OA,SCRM项目,则重点调研业务需求方即可,无需做专门高层调研,给高层做汇报即可。

(3)项目调研过程中,遇到复杂问题或跨部门决策问题,特别是涉及到财务,审计,审批等多方决策。则需要启动专题调研。

二、调研方法论:调研六部曲

根据项目的大小确定调研的类型和层级后,可以按照:确定调研干系人、输出调研计划、拟定调研提纲、组织专题调研、输出调研纪要和调研汇报6部曲进行完整的业务调研。

1. 联系核心干系人,进行粗调研

每个项目都有项目的发起方,一般都要“IT方接口人+业务方负责人”组成,和相关负责人商量如何进行业务调研,共同确定所需要调研的业务部门,同时取得他们的配合。

业务的核心干系人,主要包括:B端业务线负责人,C端业务线负责人,财务负责人等。

首先利用1-2天,联系到项目核心干系人,进行粗调研,了解大概业务需求,该业务主要涉及的部门和主流程,和核心干系人共同制定调研计划。输出:会议纪要+业务L1级主流程+调研主计划

2. 输出调研主计划

按照第一轮粗调研过程中输出的L1级业务流程,梳理所涉及的业务部门,按业务场景或部门,梳理调研计划。调研计划主要包括:调研模块,调研主题,日期,时间,调研参与人,产出物,调研进度。

业务调研主计划模板

3、拟定调研提纲

根据调研计划,拟定调研大纲,把调研主线细化,深入。调研大纲主要根据业务场景先梳理checklist。调研大纲目的:①发给业务,让他们提前准备相关材料。②按照大纲进行逐个调研,避免出现业务场景遗漏和偏差。

高层调研调研大纲:

  • 了解为什么老板会启动这个项目;
  • 这个项目对集团战略的意义是什么;
  • 老板对这个项目的期待是什么;
  • 这个项目上线,老板希望达到的效果;
  • 若这一期项目结束,后面运营策略是什么;

业务调研大纲:

  • 业务所涉及的相关名称及概念的定义;
  • 业务相关的主流程是怎么样的;
  • 流程相关业务是如何管理的;
  • 每个业务场景所涉及规则,场景,子流程;
  • 业务状态流转流程;

(需要模板可留言)

4、深入业务调研

拟定调研提纲以后,开始按调研计划进行调研。调研的主要内容包括:

  • 业务类型:部门主要有哪些岗位,各岗位主要工作是什么?
  • 业务规则:各岗位的工作流程和业务规则
  • 涉及系统:所涉及的业务系统有哪些,每个系统做哪些操作
  • 业务痛点:工作过程中有哪些业务痛点(痛点是指业务抱怨比较多的地方,一般是对已有功能的重构机会)
  • 业务频率:各业务的操作频率,每小时一次,一天一次,一周一次,一个月一次,还是突发才会处理,突发频率大概怎么样?(操作频率决定后面场景实现的优先级)
  • 部门规划:部门未来一段时间,(短期,中期,长期)有没有规划,主要规划是什么?
  • 数字化需求:对数字化建设,有哪些建设需求(需求指没有实现的功能,是对新功能发掘机会)

根据以上调研大纲,从业务类型,到流程,规则,都有了很清晰的梳理,基本能够很全面的了解现在业务现状。同时针对现有的业务现状和未来规划,再挖掘需求和痛点,这样保证产品需求来源于业务,避免了产品实现过程中业务说没有业务价值的问题。

同时,通过对业务操作频率的分析,来判断需求场景实现的优先级,对中台建设的分步实施提供指导:哪些场景可以先实现,哪些场景可以后实现,哪些场景可以先不实现,业务手工去操作。

5、输出调研纪要(含业务流程)

调研纪要的输出,主要包括:调研基本信息,名称解释,业务流程,业务规则,待办事项to do list等5个部分组成。(需要模板可留言)

6、汇报调研总结

整个调研结束,需要输出调研总结报告,同时需要向业务各方及领导进行调研汇报。
调研汇报目的:进行调研复盘总结,确认业务需求,确定项目边界(哪些本期项目实施,哪些在其他项目解决),确定需求优先级(哪些先解决,哪些后解决)

四、调研过程中踩过的坑

1. 如何让业务方配合?

业务愿不愿意配合,取决于这件事情对他的价值。正常两种解决模式:行政命令和说服诱导。行政命令就是搞定他老板,让他老板支持这个项目。说服诱导就是先不要提工作,先告诉他这个项目成功给他带来的价值是什么,让他看到希望。

2. 如何挖掘到业务痛点?

我们一般把需求分为痛点和新需求,痛点一般指现有业务在运行,但业务诟病很多,需要改正的。新需求是由于业务发展需要而新增的需求。

3. 调研的痛点是不是都要解决?怎么分优先级

需求是否都解决,根据项目的边界,确定哪些需要本次项目解决,哪些是其他项目解决,比如业务需求调研中,会产生很多报表需求,审批的需求,那就要单独立报表项目或OA项目来解决。
参考业务操作频次和闭环逻辑来确定需求的优先级,划分大闭环和小闭环。保障项目交付一定是业务闭环的。这样确定项目迭代周期和优先级,哪些第一迭代完成,哪些第二迭代完成。

4. 调研过程中经常出现分歧和沉到细节讨论里面怎么办?

调研过程中,如果遇到细节问题,不要过多对细节问题进行讨论,后面可以组织专题讨论。如果遇到争议的问题,也组织相关方专题讨论,专题讨论过程中,同时约上争议方共同的领导参与。如果讨论不出结果,可以由共同领导拍板,而不至于讨论无结论状态。

5. 调研中很多细节,当事人不在怎么办?

调研过程中遇到需要提供补充材料的,需要在会议纪要中列出待办清单,待办清单中明确具体的责任人和关差时间。

 

作者:布衣;中台产品总监,B端产品专家。

本文由 @布衣 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Pexels,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
1人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 老大,求个模板,谢谢!

    来自广东 回复
  2. 大佬,求模板

    回复
  3. 大佬,求模板

    来自上海 回复
  4. 求模版

    来自广东 回复
  5. 求模版

    来自北京 回复
  6. 老大,来个模板吧。网盘OK,加微也OK的(wx:zrb2004)

    来自浙江 回复
  7. 俺也想求个模版,感谢大佬🙏🙏🙏

    来自北京 回复
  8. 大佬,来个模板 球球了。在线文档 网盘都可以

    来自山东 回复
  9. 👍🏻👍🏻👍🏻👍🏻👍🏻

    回复
    1. 大佬,来个模板 球球了。在线文档 网盘都可以

      来自山东 回复