在中高级产品应该掌握的技能模型里，流程梳理能力必不可少，它可以帮助我们快速理解需求，还能清晰简洁地传达产品设计逻辑，为产品设计的产出做有力的支撑。那么，业务流程到底要梳理什么呢？怎么进行流程梳理？一起来看一下吧。
笔者在多年的工作中接触过很多产品经理，私以为产品经理的进阶之路可以简单的划分为四个层级：初级（照葫芦画瓢实现功能点）、中级（前后端兼顾实现功能模块）、高级（拆解业务模式搭建产品架构）、顶级（规划商业模式），在中高级产品应该掌握的技能模型里，流程梳理能力必不可少，它可以帮助我们快速准确地理解需求，还能清晰简洁地传达产品设计逻辑，为产品设计的产出做有力的支撑。
今天我们来聊一下：业务流程梳理到底要梳理什么？为什么要进行流程梳理？怎么进行流程梳理？
最初开始学习流程梳理的时候，常常会遇到这样的问题：去网上找现成的流程图觉得很高级但是不理解为什么这样，就是所谓的“不明觉厉”；去看流程梳理的书籍又觉得冗长，无法抓住重点快速上手。
其实业务流程的梳理核心就是三个点：发现需求点、拆解实现过程、产出流程图。
但凡产品设计，都是为了给某个群体实现某个目的，这里所说的“某个群体”就是指的需求方、“某个目的”就是指的产品功能，所以我们在产生梳理流程的念头的时候，就要先把上面这句话当做填空题答出来：为了给____实现_____。
这里要注意，产品人员往往不止负责一个模块，对接的同一个部门也不会只有一个业务岗位，所以这个填空题不是唯一的，在接收到了业务一套场景以后，我们可能会从一套场景中整理出多个“答案”，记录下这些答案，这就是我们要实现的需求。
根据第一步找到的答案，逐个梳理实际的业务实现方式，这个过程中要注意以下几点：
1）找业务规则
如果业务方已经有既定的线下流程，则可以进行人员访谈，获得的访谈结果再找业务链条上的每个角色去核对矫正，就能快速的得到一套业务逻辑；
如果业务方还没有线下流程，就需要我们自己去找一找有没有业务的管理规章规则，从中去寻找核心的点，包括核心数据是什么、有没有审核环节、有没有异常处理机制等；
如果连内部的文档也没有，就只能到外部去收集调研，实际的用一用竞品，看看业内的处理流程，再梳理成自己的理解给到需求方进行矫正。
2）梳理流程的公式
在实际进行流程梳理的时候是有一套公式可以遵循的，因为流程是客观事物（人）受到一定条件而产出一定结果，所以每一个流程的环节的组成应该包含如下要素：人（或事物）+规则（或条件）+行为（或动作）。举个例子：
用户申请售后=注册用户（人）+名下有有效订单（规则）+提交售后（行为）；
客服处理售后=客服（人）+判断售后单据合理性+处理售后。
当然，在这个过程中条件还会区分不同判断结果，动作也需要根据条件区分情况，这就需要根据实际的业务情况一层一层逐步深入细化。
这一步单独拎出来是因为人在工作中往往想得多做的少，或者完美主义思想觉得想不清楚就不能动笔，这样会严重影响工作效率。
这里建议大家觉得理解了80%的时候就可以开始试着画一画流程图，拿着画出来的流程图再去找业务沟通，毕竟图形化的东西更容易让人理解，而且已有产出的基础上去修改，不但能让需求方更方便反馈，还能让我们后续的工作更明确，好推进。
流程梳理会帮助我们提高工作效率，但不是每个需求都必须要进行流程梳理，实际工作中要根据产品的阶段、需求的大小、涉及到的业务范围等去综合考虑。一般来讲：
1）产品处于早期阶段，必要性比较高，一方面尽早为产品模块划分范围有利于后续需求的分类，另一方面早期文档作为组织过程资产有利于后加入人员对产品的快速熟悉；
2）需求越大越有必要，需求涉及到的产品模块越多，越需要通过流程整理核心逻辑，方便开发和测试人员理解和实现；
3）业务范围越大越必要，有些涉及到多个业务方的需求，即便需求不大也需要梳理流程，便于厘清各个部门之间的职责，这也是出于对产品实现后的业务实际使用考虑。
我们看地图的时候，如果看全球级别的则能看到宏观的关联，但是看不到细节；如果看省市级别的则能看到细节，但是缺少了宏观的理解。画图也是一样如果我们将颗粒度控制的比较粗糙，比如只表示部门之间的协同，就会忽略掉每个部门内部的流程，但是如果全部详细到每个部门内部的流程，就容易让人看晕了头。
为了能兼顾宏观和细节，我们有必要准备多套流程图：通过大的模块之间的流程展示宏观的需求范围（比如结构图）、再拆解每个模块内的流程分别的梳理和展现（业务流程图），甚至可以针对一些流程中重要的要素再整理一套对应的状态变更的流程（状态图），全方位地展示业务逻辑。
在实际的流程图制作过程中，常出现的一个问题就是角色的维度不一致，比如将某个环节的角色直接写成了某个人，因为在实际的业务调研中，有些角色确实只有一个人负责，而讲述流程的业务人员基于自己的经验也会反复强调“到了那个环节就让XX处理”这样的业务场景，容易迷惑调研的人。
流程中的逆向场景是很容易被忽略的，在流程绘制的过程中，只要涉及到判断或审批的情况，就应该考虑被驳回的流程如何处理。逆向的流程中可能还存在循环的情况，如果遇到循环则需要考虑脱离循环的条件，避免让流程陷入“死循环”。
当我们搜索“流程图”的时候，网上可供参考和学习的类型有很多，这里简单列举三种笔者在实际工作中最常用到的图形，实际上掌握了这三种图形，就已经可以处理产品工作中大部分需要图形化示意的场景了。
产品最常用的流程图，用于描述角色之间的业务关系或者系统之间的信息流向，根据图形中维度的不同，可以用于业务需求收集阶段整理业务流程，也可以在产品设计过程中整理系统模块流程。
常规的结构图一般用于组织结构的表达，笔者在撰写中后台系统中结构层次比较复杂的需求时，会借用此概念，用以自上而下的解释各层概念的调用关系。当然，这个也可以用来整理页面或者模块的结构。
用于表示一个要素的属性（网上经常称作“实体”）变化的情况，能够表达出变化的条件和每种条件下变化后的结构，梳理出状态图方便我们在产品设计时全面的考虑每种状态下的场景，也方便开发对要素进行理解和实现。
市面上的流程图还有很多种类型，特别是UML模型中，包含了很多现成的流程图规范，感兴趣的朋友可以查阅资料深入学习，但是要注意的是“学以致用”，在实际的工作中使用和学习效率会更高。
本文由 @梦溪 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。