产品经理必备技能之业务流程图

业务流程图(TFD)是一种描述管理系统内各单位、人员之间的业务关系，作业顺序和管理信息流向的图表。

流程是为了达到特定的目标而进行的一系列有逻辑性的操作过程，它可以不规范、可以充满问题，但它确确实实存在着。只要有事情或任务，就会有流程的存在，将有一定规律的流程用图表表示出来可以让流程可视化，从而有利于流程的重组优化。

在工作中，我们常用到的流程图有：业务流程图、页面流程图和数据流程图。作为产品，经常谈的是业务流程图；作为交互设计师，则比较关心页面流程图；而作为系统分析师，数据流程图最关键。

业务流程图

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

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

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

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

首先将业务按阶段划分，比如电商类可以分为下单和支付，单车类可以分为提车、骑行和停车；

然后列出每个阶段参与的功能模块，比如下单阶段，就有商品查看、登录/注册、信息记录、个人中心等功能。

最后按照时间顺序，画出业务需求在各个功能模块之间的流转情况。

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

先思考主干流程，再思考分支流程，主干流程逻辑准确，分支流程全面无遗漏；

表达清楚后台产生的各种判断及相应的前端展示,这将作为接口设计的重要根据。

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

在这里插入图片描述

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

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

任务流程图

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

在这里插入图片描述

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

只展现用户的操作，不展现后台的判断；

只展现正常流程，不展现异常流程；

只可查看用户的工作流程，无法作为开发的参考。

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

1.业务流程图的两种图表类型

（1）管理业务流程图

我们现在所说的流程图其实是传统的管理业务流程图，包含基本流程图和跨职能流程图（泳道图）两种。以医院挂号流程为例。

在这里插入图片描述

基本流程图虽然明确地说明了整个流程，但却无法清楚地说明每步流程是由哪个角色负责的。为了有效表示各个流程是由谁来负责的，可以通过泳道流程图来实现，这样不仅体现了整个活动控制流，还能清楚知道各个角色在流程中所承担的责任。

管理业务流程图已基本能满足业务流程走向的表达，但在复杂的系统交互中，表达并发概念时，传统的管理业务流程图已无法表达，这就需要用到UML建模。

（2）UML活动图

UML中共定义了13种图，如下，其中用例图、活动图和顺序图用的比较多。

在这里插入图片描述

UML细分了各种图，分别在不同的角度来描述系统流程，在本质上，UML各种图均属于流程图。

其中UML中活动图同管理业务流程图类似可用于表示业务过程，唯一的区别是活动图支持并行行为。传统的流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环，各个处理过程之间有严格的顺序和时间关系；而UML活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程。

那UML活动图是如何来表示并发业务流程的呢？

UML活动图也可包含为基本活动图和泳道活动图，表达的方式与管理业务流程图差不多，但图例上稍有不同（图例区别可参考下方）。

在这里插入图片描述

同管理业务流程图一样，泳道让流程中个角色的分工一目了然。一个泳道表示流程内的一个角色，泳道内仅仅画出该泳道所表示角色完成的活动（判断，并行等可以画在任意泳道）。

总结：管理业务流程图或UML活动图均可以用来表达业务流程，具体使用哪种图来表达业务流程可以凭君喜好，但要遵循一定的符号结构，不要混搭。不过要表达并行行为的还是使用UML活动图吧。

2.两种流程图图例和结构 （1）管理业务流程图

管理业务流程图的常用符号如下，其基本结构包含：顺序结构、选择（分支）结构、循环结构。

在这里插入图片描述

在这里插入图片描述

（2）UML活动图

UML活动图的常用符号如下，其基本结构除了顺序结构、选择（分支）结构和循环结构外，还可能存在并发的事件流。在UML中，可以采用一个同步线来说明这些并行控制流的分岔和汇合。

在这里插入图片描述

同步线：分岔是有一个进入转换，两个或多个离开转换；而汇合则是两个或多个进入转换，一个离开转换。

在这里插入图片描述

3.如何绘制流程图？ （1）在开始绘制业务流程图之前需要先想清楚的2个问题：

1）所要描述的是哪一段业务流程？

在画流程图之前先确定业务流程起终点，是截取某一段业务进行详细描述，还是整体业务模块进行描述。不可能将所有的流程都放到一个图里展示，也不可能大而笼统不画出关键事件，要学会划分业务流程范围，把握粒度。

举例

还是以医院挂号看病为例，先挂号再看病。整个流程下来其实可以细分为两个流程，分别为挂号流程和看病流程；甚至粒度可以再细点，分为取小票流程、挂号流程、缴挂号费流程、排队看病流程等，但很明显，单独分析取小票流程和缴挂号费流程粒度过小，没有实际意义。

总结：可采用自顶向下，逐层分解的绘制方法。明确你要梳理的业务流程范围，首先列出流程中的关键事件，如医院挂号看病，挂号流程和看病流程便算是整个流程中的关键事件流程；再结合你分析的目的来判断是否需要再往下层进行分解，如取小票流程、挂号流程、缴挂号费流程、排队看病流程。如此例，层层向下分解，直到符合你要分析的目的，当目的是为了对某个业务流程进行优化时，则分解到对应流程即可，绘制出流程图后再进行分析。

2）所要描述的业务流程是否涉及到参与者？

涉及到参与者的业务流程使用泳道图来描述更简单明了。

举例

业务简要描述：数学老师让小丽帮忙把讲台上的写了名字的语文课本送给语文老师，语文老师接下后微笑着对小丽说谢谢。

分析：包含了数学老师、小丽、语文老师这三个参与者，此时用泳道流程图更合适。

（2）问题想明白了之后便可以对业务流程进行梳理，进而分解各个要素。

业务流程图有4个关键要素：执行操作、顺序、输入输出、规则；要更清楚的描述业务流程可以有参与者这一要素。

执行操作：执行了什么操作

顺序：操作产生的顺序

输入输出：发生操作的原因和结果

规则：操作产生的条件

参与者：谁参与了这个流程，可以是系统、可以是页面，也可以是用户

以上个例子为例进行分解：

业务简要描述：数学老师让小丽帮忙把讲台上的写了名字的语文课本送给语文老师，语文老师接下后微笑着对小丽说谢谢。

执行操作和顺序（含输入输出）：请求帮忙、接受帮忙、拿讲台上的语文课本、递交课本、接收课本、道谢

规则：必须是写了名字的语文课本

参与者：数学老师、小丽、语文老师

在这里插入图片描述

以上是明确给出了业务描述，按照步骤基本上便能画出业务流程图。在没有明确给出业务描述的情况下，对业务流程的梳理主要有两种方式：

1）深入现场调查，由工作人员介绍业务处理过程。

在这里插入图片描述

2）对现有业务流程的优化。当已经对现有业务流程熟悉时，通过讨论和分析，可梳理出业务流程，再通过优化现有流程中不合理的地方，从而给出一个更好的流程来。

（3）流程图规范

各图形形状/字号统一。如果各个图形形状大小/字号相差悬殊，这对于理解图形的人也是一种折磨，对于某个比较重要的流程可以使用颜色来区分其他普通流程（但颜色数量和种类不应太多，以免重点模糊），再在该重要的流程旁加上注释说明，就能将重点转达给对方。

流程名用动宾结构，如输入手机号。

流程均以开始框开始，以结束框结束。

流程图从左到右、从上到下排列。

流程线尽量不要交叉。