实例解析业务流程图与产品流程图 分析业务流程图

这篇文章的目的很简单：通过电商的实例，将业务流程图和任务流程图之间的关联和区别以及在产品中的应用，讲解清楚。

流程和流程图

首先来看流程的定义：

《牛津词典》里，流程是指一个或一系列连续有规律的行动，这些行动以确定的方式发生或执行，促使特定结果的实现； 而国际标准化组织在ISO9001：2000质量管理体系标准中给出的定义是：“流程是一组将输入转化为输出的相互关联或相互作用的活动”。

由上面的两个定义，我们可以提炼出流程不可或缺的因素：对象、输入、动作、输出。

• 对象就是执行人，也就是产品中的用户；
• 输入可以理解为前提、前置条件；
• 动作，就是产品中的操作，可以是点击、输入，等等；
• 输出，可以理解为结果、动作的目的。

需要说明的是：

1. 产品工作中，输入和输出的形式并不局限，可以是事件，也可以是动作；
2. 在思考输出时，也不能仅仅考虑用户端的输出结果，同时要思考后台可能产生的输出（比如数据的变化）；
3. 在相连的环节中，通常上一个环节的输出即为下一个环节的输入。

明确了流程的定义和要素之后，顾名思义，流程图就是将流程表达清楚的图形，流程图只要表达清楚一件事：什么对象在什么前置条件下执行了什么操作，产生了什么结果。

流程图的制作方法和工具，已经有很多的介绍，这里不赘述。产品工作中常用到业务流程图和任务流程图，下面将通过实例讲述我所理解的两种流程图的联系和区别。

业务流程图

业务流程图的作用是表达清楚业务需求在产品线的各个阶段中在各个功能模块之间的轮转。

通常情况下，一个业务需求不仅仅对应一个功能需求，而是由多个功能需求组成的，举例来说：业务需求是注册，那么功能需求就包括填写信息的正则校验，验证码的生成与校验，注册协议查看（和勾选），此外，后台还要有账户生成与信息记录的功能，需要手机注册的还要有短信的发送与验证功能（邮箱注册同理）。

可见，业务需求要求概括精炼，功能需求要求详细具体。一个业务需求通常涵盖多个功能需求，涉及前端展示、后台记录等多个部分，所以业务流程图通常复杂详细，尽量能够涵盖各种异常情况（每种异常情况都有相应的前、后台解决方案）。

业务流程图的绘制思路一般是：

• 首先将业务按阶段划分，比如电商类可以分为下单和支付，单车类可以分为提车、骑行和停车；
• 然后列出每个阶段参与的功能模块，比如下单阶段，就有商品查看、登录/注册、信息记录、个人中心等功能。
• 最后按照时间顺序，画出业务需求在各个功能模块之间的流转情况。

为了输出一份完整的业务流程图，一般有两个原则：

• 先思考主干流程，再思考分支流程，主干流程逻辑准确，分支流程全面无遗漏；
• 表达清楚后台产生的各种判断及相应的前端展示,这将作为接口设计的重要根据。

下面以电商购物的实例，绘制一份业务流程图

一个完整的电商购物流程，通常包含两个阶段，五个部分，两个阶段就是下单和支付，五个部分是用户、交易、账号系统&个人中心、支付系统和CRM系统，如果仅仅从用户角度出发，很难考虑到后台各种判断和操作，那样就变成了任务流程图，而这个图中包含了购物流程的用户操作、前端展示和后台判断，体现了实现购物业务所需要提供的功能和各部门的支持，在这个图中也能看出所需要的接口和数据。

业务流程图应该是拿到业务需求（或BRD）后，首先输出的文档，而且并不是一成不变的，会在对业务需求或者BRD的多次讨论中不断补充完善，最后成为整个项目的标杆文件，在构建技术架构和技术分工时，将其作为主要参考。所以，绘制业务流程图时，一定要逻辑清晰，不能遗漏任何一个重要部分。

任务流程图

任务流程图表达的是用户在执行某个具体的任务时的工作流程。任务流程图可以理解为一个简化版的业务流程图，只有主要的操作步骤，通常在写用户体验报告时，利用任务流程图表达页面流转和主要操作，同样以电商购物为例：

由上可见，相比于业务流程图，任务流程图的特点是：

• 只展现用户的操作，不展现后台的判断；
• 只展现正常流程，不展现异常流程；
• 只可查看用户的工作流程，无法作为开发的参考。

不管是绘制业务流程图还是任务流程图，重点都应放在逻辑关系上，而不是图形本身的细节。说到底，流程图只是帮助我们更好地进行分析思考的工具，能够画出逻辑清晰的流程图，不一定对每个模块都了如指掌，但如果流程图逻辑混乱、含糊不清，那么肯定要反思是不是对业务需求或者功能需求的理解不清晰。作为刚入门的新手，结合思维导图，经常分析产品的业务流程和任务流程，对提高逻辑感和产品思维，还是很有帮助的。

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