2023年产品经理的利器：业务流程梳理技巧

产品经理的利器：业务流程梳理技巧class="aligncentersize-fullwp-image-5788216"src="/wp-files/2023/03/KPIKqa5O8QU8Dhk4vYuO.png"alt=""width="900"height="420"/>

笔者在多年的工作中接触过许多产品经理，私以为产品经理的进阶之路可以简洁的划分为四个层级：初级（照葫芦画瓢实现功能点）、中级（前后端兼顾实现功能模块）、高级（拆解业务模式搭建产品架构）、顶级（规划商业模式），在中高级产品应当把握的技能模型里，流程梳理力量必不行少，它可以关心我们快速精确     地理解需求，还能清楚简洁地传达产品设计规律，为产品设计的产出做有力的支撑。

今日我们来聊一下：业务流程梳理究竟要梳理什么？为什么要进行流程梳理？怎么进行流程梳理？

一、梳理什么

最初开头学习流程梳理的时候，经常会遇到这样的问题：去网上找现成的流程图觉得很高级但是不理解为什么这样，就是所谓的“不明觉厉”；去看流程梳理的书籍又觉得冗长，无法抓住重点快速上手。

其实业务流程的梳理核心就是三个点：发觉需求点、拆解实现过程、产出流程图。

1.发觉需求

但凡产品设计，都是为了给某个群体实现某个目的，这里所说的“某个群体”就是指的需求方、“某个目的”就是指的产品功能，所以我们在产生梳理流程的念头的时候，就要先把上面这句话当做填空题答出来：为了给____实现_____。

这里要留意，产品人员往往不止负责一个模块，对接的同一个部门也不会只有一个业务岗位，所以这个填空题不是唯一的，在接收到了业务一套场景以后，我们可能会从一套场景中整理出多个“答案”，记录下这些答案，这就是我们要实现的需求。

2.拆解过程

依据第一步找到的答案，逐个梳理实际的业务实现方式，这个过程中要留意以下几点：

1）找业务规章

假如业务方已经有既定的线下流程，则可以进行人员访谈，获得的访谈结果再找业务链条上的每个角色去核对矫正，就能快速的得到一套业务规律；

假如业务方还没有线下流程，就需要我们自己去找一找有没有业务的管理规章规章，从中去查找核心的点，包括核心数据是什么、有没有审核环节、有没有特别处理机制等；

假如连内部的文档也没有，就只能到外部去收集调研，实际的用一用竞品，看看业内的处理流程，再梳理成自己的理解给到需求方进行矫正。

2）梳理流程的公式

在实际进行流程梳理的时候是有一套公式可以遵循的，由于流程是客观事物（人）受到肯定条件而产出肯定结果，所以每一个流程的环节的组成应当包含如下要素：人（或事物）+规章（或条件）+行为（或动作）。举个例子：

用户申请售后=注册用户（人）+名下有有效订单（规章）+提交售后（行为）；

客服处理售后=客服（人）+推断售后单据合理性+处理售后。

当然，在这个过程中条件还会区分不同推断结果，动作也需要依据条件区分状况，这就需要依据实际的业务状况一层一层逐步深化细化。

3.产出流程图

这一步单独拎出来是由于人在工作中往往想得多做的少，或者完善主义思想觉得想不清晰就不能动笔，这样会严峻影响工作效率。

这里建议大家觉得理解了80%的时候就可以开头试着画一画流程图，拿着画出来的流程图再去找业务沟通，究竟图形化的东西更简单让人理解，而且已有产出的基础上去修改，不但能让需求方更便利反馈，还能让我们后续的工作更明确，好推动。

二、实现中要留意的点

1.必要性

流程梳理睬关心我们提高工作效率，但不是每个需求都必需要进行流程梳理，实际工作中要依据产品的阶段、需求的大小、涉及到的业务范围等去综合考虑。一般来讲：

1）产品处于早期阶段，必要性比较高，一方面尽早为产品模块划分范围有利于后续需求的分类，另一方面早期文档作为组织过程资产有利于后加入人员对产品的快速熟识；

2）需求越大越有必要，需求涉及到的产品模块越多，越需要通过流程整理核心规律，便利开发和测试人员理解和实现；

3）业务范围越大越必要，有些涉及到多个业务方的需求，即便需求不大也需要梳理流程，便于厘清各个部门之间的职责，这也是出于对产品实现后的业务实际使用考虑。

2.层次和范围

我们看地图的时候，假如看全球级别的则能看到宏观的关联，但是看不到细节；假如看省市级别的则能看到细节，但是缺少了宏观的理解。画图也是一样假如我们将颗粒度掌握的比较粗糙，比如只表示部门之间的协同，就会忽视掉每个部门内部的流程，但是假如全部具体到每个部门内部的流程，就简单让人看晕了头。

为了能兼顾宏观和细节，我们有必要预备多套流程图：通过大的模块之间的流程展现宏观的需求范围（比如结构图）、再拆解每个模块内的流程分别的梳理和呈现（业务流程图），甚至可以针对一些流程中重要的要素再整理一套对应的状态变更的流程（状态图），全方位地展现业务规律。

3.人和角色

在实际的流程图制作过程中，常消失的一个问题就是角色的维度不全都，比如将某个环节的角色直接写成了某个人，由于在实际的业务调研中，有些角色的确只有一个人负责，而叙述流程的业务人员基于自己的阅历也会反复强调“到了那个环节就让XX处理”这样的业务场景，简单迷惑调研的人。

4.逆向场景

流程中的逆向场景是很简单被忽视的，在流程绘制的过程中，只要涉及到推断或审批的状况，就应当考虑被驳回的流程如何处理。逆向的流程中可能还存在循环的状况，假如遇到循环则需要考虑脱离循环的条件，避开让流程陷入“死循环”。

三、常用的图

当我们搜寻“流程图”的时候，网上可供参考和学习的类型有许多，这里简洁列举三种笔者在实际工作中最常用到的图形，实际上把握了这三种图形，就已经可以处理产品工作中大部分需要图形化示意的场景了。

1.业务流程图

产品最常用的流程图，用于描述角色之间的业务关系或者系统之间的信息流向，依据图形中维度的不同，可以用于业务需求收集阶段整理业务流程，也可以在产品设计过程中整理系统模块流程。

2.结构图

常规的结构图一般用于组织结构的表达，笔者在撰写中后台系统中结构层次比较简单的需求时，会借用此概念，用以自上而下的解释各层概念的调用关系。当然，这个也可以用来整理页面或者模块的结构。

3.状态图

用于表示一个要素的属性（网上常常称作“实体”）变化的状况，能够表达出变化的条件和每种条件下变化后的结构，梳理出状