业务流程图绘制规范

业务流程图绘制规范

目录

1 引言 (1)

2 范围 (1)

3 术语 (2)

3.1 业务流程图 (2)

4 约定 (2)

4.1 绘图工具 (2)

4.2 格式 (2)

4.3 命名规范 (2)

4.4 职能带排列顺序 (2)

4.5 开始与结束 (3)

4.6 处理进程与进程流 (3)

4.7 判断分支 (4)

4.8 数据与数据流 (4)

4.9 职能部门与进程、数据的关系 (5)

4.10 流程的层次与粒度 (5)

4.11 扩展 (6)

4.12 并行流程 (6)

4.13 其他 (6)

5 附录：业务流程图图例 (7)

1引言

本规范规定了绘制业务流程的具体标准和要求，便于交流和沟通。

2范围

本规范适用范围: 项目组成员

3术语

3.1 业务流程图

业务流程图（Transaction Flow Diagram,简称TFO），就是用一些规定的符号及连线来表示某个具体业务处理过程。业务流程图的绘制基本上按照业务的实际处理步骤和过程绘制。

4约定

4.1 绘图工具

采用MicroSoft Visio图形编辑工具软件。

4.2 格式

采用垂直跨职能流程图框架，基本流程图模板图符（图例见附录）。

4.3 命名规范

流程图的命名遵循“子系统名_功能名_流程名”的分层命名方法。

4.4 职能带排列顺序

业务流程涉及多个职能部门时，上级职能部门在右，下属职能部门在左。例：

4.5 开始与结束

4.6 处理进程与进程流

一个业务流程由若干处理进程首尾衔接组成。以一个矩形配以文字说明表示一个处理进程。

例：

处理进程的文字描述应尽量简练，最好以一个动词或动宾词组描述。

处理进程之间以带箭头的实线连接，形成进程流。连接线必须从一个进程开始，到下一个进程结束。

一个进程可以有多个入口，但应只有一个出口。

例：

4.7 判断分支

当一个流程在某一处理进程处根据不同条件发生分支时，需要以一个菱形符号来说明。菱形中的文字给出判断条件。菱形符号是二值判断符号，即判断结果有两个分支，一个是满足判断条件的流向，另一个是不满足判断条件的流向。分别在表示流向的箭头上注明“是”和“否”。

例：

如果发生多值判断分支，一般将其分解为几个二值判断分支的组合。

4.8 数据与数据流

在处理过程中涉及的数据依其存在形态可分为：

1

2

3

一个数据必须与一个相关的处理进程用一条虚线箭头连接起来。箭头的方向由数据的流向决定。如果是进程引用的数据（如查询数据、录入表单）则由数据指向进程；如果是进程产生或加工的数据，则由进程指向数据。

例：

数据流应自始至终伴随进程流演进。

4.9 职能部门与进程、数据的关系

在流程涉及多个职能部门时，流程的开始和结束都应在直接运行该流程的职能部门，流程图只包括组成本流程的进程，对属于相关职能部门但不属于本流程的进程则省略。而本流程所需的数据，从哪个部门产生或应发送到哪个部门，就放在哪个部门。例：

如上图，退税处理是计会部门的业务流程，因此开始和结束都在计会部门，所有处理进程也只涉及计会部门。虽然流程涉及的上下游部门包括涉税审批部门和国库，但流程图中并不涉及这些部门的处理进程，只是标明与这些部门的数据交换。

4.10 流程的层次与粒度

一个业务系统的全部流程应根据业务的规模进行分层。顶层流程着重说明各业务功能之间的联系；底层流程应遵循业务最小化原则，将一组相对独立、不可分割的进程定义为一个流程。一个流程图应尽量在一页中完成。

4.11 扩展

4.12 并行流程

如果一个流程在某一点无条件地分成两个以上的并行流程，则以并行符号（两条平行线）表示。

例：

4.13 其他

在个别情况下，为强调处理进程的某些特性，采用与普通进程（矩形符号）有别的特殊处理符号，如：

等。

5附录：业务流程图图例