业务流程图的主要目的是梳理业务逻辑，明确角色、活动与协同关系，界定角色边界，以及识别业务流程产生的产物。通过可视化的方式，业务流程图帮助团队诊断业务问题，如流程目的是否清晰、流程是否简洁、各节点的价值是否明确等。此外，它还能促进流程的优化，例如去除冗余步骤、简化高频操作、整合依赖环节以及实现自动化。
业务流程图的目的、价值
梳理业务逻辑
要想了解业务是怎么运转的，我们得梳理业务逻辑，知道在整个业务中有哪些人或物参与了，他们分别做出什么行为，对于业务的价值是什么？总的来说，有以下三个方面：
角色、活动与协同关系：在这个业务中，包含哪些角色，生产者是谁？消费者是谁、渠道者是谁？他们的协同关系是什么？他们会做出什么活动？
角色的边界：不同角色间的边界在哪？只有确定了边界，我们才能更加明确不同角色间的权责义务、防止角色杂糅，不清晰
产物：角色自身、或者角色间的协同，会产出什么产物呢？
诊断业务问题
通过将业务流程复刻到一张流程图中，借助这张流程图思考，发现业务上的部分问题。
流程的目的是否清晰
流程是否简洁
各节点的价值是否明确
节点的活动或产物能否体现价值
注意：业务流程图只是作为发现业务问题的工具之一，不能指望通过这张图就能发现业务上的所有问题。
对应着以上几点业务问题，下一步可以进行分析优化：
使流程目的与业务目的对齐
去除多余的，重复的、矛盾的分支
去除无价值或重新设置该节点
数字化优化
以上，我们介绍了绘制业务流程图的目的及其所能带来的价值。
流程图的构成
流程图的基本要素和结构
在我们梳理业务逻辑时，我们需要知道角色、活动、协同关系以及产物。同样，在我们的流程图中这四个元素也是最基本的元素。
另外，在一个业务中，势必会存在一些分支或者需要规则判断的场景，所以结合实际业务场景，我们还需要另外两个要素：分支与规则。
分支：指的原本的主线流程在某个场景下，分成多条支线往下进行。比如我们在登陆网站时，网站会先判断账号是否存在，存在则进行登陆动作，不存在则会提醒用户账号不存在，引导用户重新输入或者注册账号。
规则：在我们整个流程中，想要流程顺畅的运转下去，就需要设置相关的规则，防止异常。比如我们在购物网站下单时，商家必须保证有库存，才能提供消费者下单，如果没有进行规则限制，就会出现买家下单后，没有商品发货的情况。
那么，以上元素在我们的流程图中用什么的形状表示呢？
开始/结束：表示流程的开始与结束，一个流程图中只有一个开始，但有多个结束。开始节点非常重要，有些同学在画流程图时，觉得开始节点画不画无所谓，是一个没有意义的节点。实际上，当你写下开始那个节点时，相当于画下一个边界点，业务的所有一切，都由此开始，面没有任何其他的活动了。结束同样如此，当下画下结束，这条流程到此即为终点。
流程/活动：角色所进行的活动。
连线：表示不同角色间的协同关系。
判断：对应流程某个节点下的场景判断，由此开始走向不同分支。
产物：表示角色进行活动后的产物
子流程：对于复杂的业务而言，在一张图中把所有流程画出，不够简洁也不方便阅读。所以我们会将一些子流程单独拎出来，放在另一张图，在原来的主图中使用子流程表示。
注释：对于一些规则或其他说明进行注释。
流程图的结构
流程图中大致包含三种结构：顺序结构、条件结构（又称选择结构）、循环结构。基本上大多数流程图都是由这三种结构组成的。
泳道图的形式
泳道图是流程图中的一种画法，是将流程图中的一些流程节点按操作角色的不同而划分。同时在竖向的基础上也可以添加横向泳道，以不同页面来给操作分类。对于涉及到多角色比较复杂的流程图来说，画泳道流程图会看起来更加清晰明了。
流程图的高阶结构
绘制业务流程图的步骤
绘制一份完善清晰的流程图，前提是需要你了解业务的。了解业务的最主要方式一般可以是通过访谈客户代表或者业务专家。但仅仅从内部业务人员访谈，更多是从本公司业务视角出发，这个视角下难免狭隘，也很容易被业务带着走。如果能够遇到优秀的业务人员，那么跟着业务走可以非常顺畅。如果遇到业务能力一般的人员，我们可能获取到错误或落后的信息，最终导致项目失败。所以在访谈前，我们也应该去看看行业分析报告，看一些专业的业务相关文章或书籍，这样我们就不会局限在本公司的业务内，能够站在更高的视角看待业务发展的阶段，与外界对比，处于什么位置，是否具备竞争优势。在访谈过程中，就可以逐步绘制业务流程图了,主要可分为三个阶段。
注意在这里我们说的是较为复杂的业务流程，使用的是泳道图。
一、绘制主体流程
通过与客户代表或者业务专家的访谈，完成流程主体的梳理。
方法采用“一听二问三确认”。
一听：先听客户代表或者业务方的介绍。听得过程中，要做到不打断，不陷入细节，以最简单的方式勾出主体脉络，即基本要素中的角色、活动、协作关系梳理出即可。其他的分支、交付物、异常、审批、规则统统都放一边。
举例：
二问：完成上一步后，就可以进行提问了。主要是沿着流程进行发问，重点放在分支、产物关系上。看看是否存在分支的情况，各协作之间是否有交付物。一边问，一边修正。
三确认：最后一步就是自己讲一遍流程，和客户代表或者业务专家进行最后的确认。至此完成主体流程的绘制。
二、 补充管理要素
完成主体流程绘制后，接下来就要放在管理要素上了，即异常、审批和规则。
首先，就‘异常“进行交流，主要的思考方向是：”是否存在完全不能够按照这个业务流程执行的情况，如果存在，应该如何处理？“ 弄清楚后，用文字或者另外的流程图来表示。（异常流程属于分支流程）
其次，就”审批“进行询问，关注点在”现在有哪些审批点？还有哪些环节需要增加审批点？需要增加什么样的审批？谁来审合适“。
最后，就是”规则“了，需要询问一下业务上有哪些规则，可以从行为规则和数据规则两方面进行交流。行为规则就是各角色之间协作或者角色执行活动步骤时需要遵循的规则，比如”只有体检医生，只对盖章的体检单进行体检“。数据规则就是指对交付物的一些格式、内容进行限制的规则了，比如”体检单上的金额取小数点后两位“。
至此完成管理要素的绘制。
三、流程的分析和优化
绘制完成后，只是准确的还原了业务上的流程。还需要进一步的进行分析和优化。
比较有效的方法就是站着用户的角度来体验整体流程，然后去发现不合理的问题，从而解决，问题可以从以下四个方面去寻找：
- 清除无效的环节：找到流程中不产生效能的、浪费的、低效的环节，然后想办法清除。
- 简化高频：对频率比较高的环节进行优化，使其效率提升。
- 整合依赖：将相互依赖的环节整合在一起，提高效率。
- 自动化烦琐：把人做起来麻烦的事让电脑来干，提升效率。
做完这三步，一份完整清晰的业务流程图就做完了。
把握流程图的颗粒度
画业务流程图经常会遇到一个问题，就是业务流程图究竟要画多细，也就是其颗粒度如何把握，太粗了说明不了问题，太细了会显得图很乱，容易看晕。
其实业务流程图是有三个层级的，层级不同，颗粒度不同，分别为组织级业务流程图、部门级业务流程图、个人级业务流程图。
- 组织级业务流程图：用于描述部门之间的业务协作关系，供决策层人观看，所以颗粒度只细化到部门即可。部门内的相关操作可以合并成一个。
- 部门级业务流程图：用于描述岗位之间的业务协作关系，供管理层人观看，颗粒度细化到岗位之间的操作。如果是业务流程分析，就应该在这个粒度上进行。
- 个人级业务流程图：用于描述一个岗位的具体操作流程，适合业务场景分析时使用。如果这个级别还比较复杂，可以在分解为子流程。
在判断流程图是否过细时，有两个重要的原则：一是看是否与协作相关；二是看是否为独立可汇报的工作单元。如果与协作无关或者不可独立汇报，那就是画的太细了（到个人级别了），需要合并（合并到部门级）。
举例：
把收费人员的收费流程和综合科医生的出具报告的工作流程都画出来了，但细分以下，这两个地方都不涉及到与其他部门协作的地方，而且不可以独立汇报（拿出其中的一个流程节点都不具备形成独立的汇报结果），所以这两个地方应该合并。合并后的结果见第二张图。
关注业务的边界
除此之外，我们还需要关注业务的边界。
有些同学在画流程图时，觉得开始节点画不画无所谓，是一个没有意义的节点。实际上，当你写下开始那个节点时，相当于画下一个边界点，业务的所有一切，都由此开始。前面没有任何其他的活动了。如果没画，前期我们就很容易偷懒，随意在前面增加节点，这样就导致了我们思维的混乱。
那是不是说，画下了开始节点，就不能再增加了呢？也不是的，在我们边梳理的过程中，肯定会出现遗漏的地方，但每一次加节点，都会让我们问问自己的内心：整个业务是从这里开始吗？此时通过开始节点，就会知道，可能业务有边界不清晰的问题了。
同样，结束节点也是如此。但结束节点可以有多个，开始节点只能有一个。
一个结束节点，表示该流程走到某个节点后，即结束，无后续动作。
开始与结束两个节点的绘制有利于边界的确定，同样不同角色间的协同也要注意边界，不能这件事A角色做B角色的事情，B角色又做角色。
那，又应该如何根据业务确定开始与结束边界呢？回归到我们最初绘制业务流程的目的，如果我们的业务只到了入职，那么在入职后就结束了。如果我们要了解到员工入职后的表现 ，那么需要包含后续的培训、工作表现等等环节。
关于边界有一个注意点：有时我们所做业务结束后或者开始前与其他业务有对接。那么这个时候可以将其他业务的活动也画进来，标记出哪些是自身业务，哪些是外部业务。如此，上游与下游的业务流程，就和我们的业务串起来了。即使我们不需要过于关注他们的业务，但这能让我们对业务有更加全面的认识，避免很多对接问题，还能站在更高的角度思考业务，而不仅仅顾着自己的一亩三分地。
绘制业务流程图常见的问题
产品经理在梳理业务时，经常会用到业务流程图。绘制业务流程图，是产品经理的基本功。
然而，由于缺乏正确的方法和足够的训练，不少产品经理绘制的业务流程图，存在一些问题。这些问题，严重影响了表达需求的质量和效率。下图是一个同事的作品：
这个流程图，主要有以下3个问题：
1. 难以理解
流程图的使用规则中，每一种图形，都有科学、约定俗成的含义，且被大家广泛接受。见到矩形，就知道这是操作；见到菱形，就知道这是逻辑判断；见到圆腰矩形，就知道是流程开始或结束；见到注释框，就知道这是对某个节点的注释说明······
绘制流程图时，应该准确使用图形，让读者用约定俗成的方式理解流程。
上图中，“OCR识别身份证”节点下方的信息采集内容清单，不是一个操作节点，仅仅是对“OCR识别身份证”节点的补充说明。应该改用“注释”来表达。
2. 遗漏关键节点
为了确保达成业务目标，业务执行过程中，存在一些必须要执行的任务，这就是关键节点。如外卖业务流程中，“骑手到门店取货”是一个关键节点。
业务流程图若缺少关键节点，无论是产品经理据此设计详细产品方案，还是研发据此开发功能，都可能会导致遗漏重要的功能模块。最终上线的产品，无法满足真实的业务需要。
上图中，身份证过期后，应该要先返回上传身份证页面，再重新上传身份证；缺少了重新上传身份证的关键节点，直接重新检验身份证有效期，必然会再次得到身份证过期的结果，如此，就进入了一个死循环：永远都是在检验同一个过期的身份证。
很明显，这个功能，必定无法解决身份证过期的问题。
后面的检验身份证真实性、人脸识别也存在同样的问题。
缺少关键节点的业务流程图，无法准确、完整地描述业务执行过程，最终导致产品缺少重要功能模块，无法满足业务。
3. 与实际情况不符
业务流程图要真实还原业务真实的执行过程。如果与实际情况不符，不仅会使团队不信任产品经理，还可能导致产品出现bug，引发严重的产品事故。
帐号登录流程中，若密码正确性校验的结果是“错误”，流程图的下一个任务节点，应该是“登录失败”，并提示密码错误。如果下一个任务节点是“登录成功”，则明显违背逻辑和常识。
当开发看到这样的流程图，必定会认为产品经理不专业，或者按自己的理解来完成开发。
最后上线的功能，要么提示登录成功，但实际上并没有登录成功；要么在密码验证失败的条件下登录成功，但这意味着不需要验证密码也能登录，造成严重的产品事故。
准确描述业务执行过程，是对业务流程图的基本要求。如果连实际情况相符都做不到，那就失去了存在的意义。
上图中，活体检测不通过的后续处理节点应该是“重新进行活体检测”。人脸比对不通过的后续处理节点应该是“重新对比人脸”。
但流程图中，后续处理节点都是“人脸识别失败”，这明显违背常识。
没有回复内容