如何绘制业务流程图模板Word文件下载.docx

如何绘制业务流程图模板Word文件下载.docx

《如何绘制业务流程图模板Word文件下载.docx》由会员分享，可在线阅读，更多相关《如何绘制业务流程图模板Word文件下载.docx（31页珍藏版）》请在冰豆网上搜索。

流程图和其它图表（如线框图,概念图,架构图,用例图）有什么不同?

2.为什么需要流程图?

3.流程图的分类?

4.如何绘制流程图?

5.流程图绘制工具

视篇幅情况,会在行文时略加划分为系列,敬请关注并多多交流。

第一部分:

什么是流程图?

1.定义

了解一个事情,我习惯从它的定义开始。

至于为什么,能够参见我之前的博客文章

我们因为厌恶十年教育,厌恶背各种定理和定义,因此我发现生活中和工作中很多人都很讨厌给一个事情下定义以及去参考定义。

因此你会发现很多人在一起争吵得不可开交,仔细去听,原来是鸡同鸭讲,根本不在一个频道上。

对于一个事情的描述,没有一个共同的语言,没有所谓的术语。

有定义很好办,你们共同引用一个定义,发现定义有问题,OK,去补充这个定义,并扩展到更多的人群。

当然,任何事情过犹不及,我们相互提醒吧。

那什么是流程图呢?

说文解字是一种了解定义的好方法。

流程图=流程+图,如下图:

图2:

流程图的定义

流程:

Flow,是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程,流程是自然而然就存在的。

可是它能够不规范,能够不固定,能够充满问题。

因此就会造成看似没有流程。

前不久,团队每个人对接一个业务团队去调研流程,反馈给我的流程有一些缺失。

询问时,负责人反馈给我的答复是:

这一块业务她们没有流程。

其实严格意义上讲,业务已经开展,不可能没有流程,只是说没有固定的流程或者你调研的对象也讲不清楚。

图:

Chart或者Diagram,是将基本固化有一定规律的流程进行显性化和书面化,从而有利于传播与沉淀、流程重组参考。

从定义能够看出,只要有事情和任务,流程就会有,可是并不是所有的流程都适合用流程图的方式去表现,适合用流程图去表现的流程是一定程度固定的有规律可循的,流程中的关键环节不会朝令夕改的。

2.流程图与其它图表的对比

工作中我们还用到或听到很多其它类型的图表,比如交互设计师们经常说的线框图（Wireframes）,信息架构图或站点地图（SiteMap）,,开发工程师们经常说的用例图（UseCase）或E-R图。

这些不同的图表要表示的内容有何种差异呢?

简单做个对比,如图

图3:

流程图VS其它常见图表

如果要串到某一个项目来说,能够理解成:

用例图（UseCase）:

表现了一个角色在系统里要完成的活动是什么,比如用户这个角色与ATM取款机的交互过程中,用户需要完成的活动有存钱,取钱,查询等。

而存钱这个活动再能够进一步细分为插卡,输入密码,输入金额,ATM吐钞,用户收款,退卡等活动。

用例图能够不考虑用户动作的前后次序,而仅仅提取一些关键的动宾短语,映射出系统应该满足的功能点。

常见用例图的人是产品经理和开发工程师。

流程图则表示用户每一个活动的前后次序,比如用户必须要先插入银行卡,才能够输入密码,且流程图必须直接表现出各种异常判断,比如当密码错误时,出现什么提示,密码输入错误超过多少次时,出现什么提示和动作。

常见流程图的人是产品经理,设计师,或者任何需要讲述业务如何运作的人。

信息架构图,站点地图（SiteMap）:

表现为了做一个这样的系统,功能与内容的展现层次是什么,比如用户一进去后,欢迎页面的导航如何设计,是否直接出现取款,存款,查询,或者还有别的导航?

常见信息架构图的是设计师。

可是常见组织架构图的是HR。

线框图（Wireframe）:

将具体每个界面的内容布局和权重表示出来,且标注出一些交互细节的设计,比如当密码错误后,如何提示下一步动作。

常见线框图的人是设计师。

实体关系图（E-R图）:

则是数据库架构的工作,表示一个业务系统或场景中的实体时间的关系,比如储户与银行卡的关系是归属1对多,经过开卡事件产生关联。

一般来讲,用矩形来表示实体,椭圆标识这个实体的属性,比如储户这个实体的属性有:

姓,名,手机号码,住址等。

而银行卡的属性有:

开户行,开户名称,银行卡号等。

以上的这些图表各自都有领域的专家,我这里就不班门弄斧了。

那么流程图要体现出她的差异定义,要素是什么?

总结出了流程图的6大要素,希望大家能够记住,这6个要素能够在以后的文章里不断回顾,你也能够拿来判断你所看到的流程图是否专业。

图4:

流程图6大要素

参与者:

谁在这个流程中?

能够是系统,能够是个打印机,更多的指什么角色——一般是有某种工种的人。

比如客服同时有小A和小B两人,可是若她们的工作性质完全一样,那么在流程图里只需要写一个客服角色就能够了。

活动:

做了什么事,比如点餐,结帐等活动。

次序:

这些事情发生的前后顺序如何,哪个任务是其它任务的前置条件?

比如客人不结帐,就不会产生送她优惠卡的活动。

输入:

每项活动开始取决于什么样的输入物或数据,比如做饭的师傅开始做菜时,需要拿到具体的点菜单。

输出:

每项活动结束后,会输入什么样的文档或数据传递给下一方,比如师傅做好菜后,如何让负责传菜的人知道菜已经做好?

标准化:

采用一套标准化的符号用以传递你的流程图,从而使受众更快明白。

关于流程图的标准化,并不是强制的,事实上,我们见过很多种类的流程图,只要能够传递明白任务和次序其实已经归类于流程图了。

如下面的图:

可是若在一个公司的环境下,你的流程图的受众又非常多的话,采取标准化的符号会带来很多交流上的好处,总之你懂的。

第二部分:

流程图的分类?

常见的流程图有业务流程图（TransactionFlow）,页面流程图（PageFlow）。

在工作中,作为UED,你可能会发现PD经常谈的是业务流程,而作为交互设计师,我们更多产出的是页面流程图。

页面流程图和业务流程图到底有什么关系呢?

先有谁,其次再有谁呢?

先讲个故事:

假设你的梦想是开个中高档的全国连锁餐馆,那么首先你想到的应该不是如何去选址,而是将为何要开连锁餐馆这件事情,以及你的定位,核心竞争力想清楚。

是快餐,还是点餐,是连锁还是加盟?

定位于社区还是繁华商圈?

是川菜还是江浙海鲜?

是面向中老年还是年轻人?

是家庭主题还是动漫主题?

竞争对手是谁?

需要什么样的投资?

可能的风险是什么?

这些都想清楚了,问题都有答案了,所谓战略层要清晰了吧。

然后假设你现在分析来分析去,与主要投资方决定了一个方向:

面向年轻人的时尚动漫茶餐厅,连锁,可是先在杭州开始第一家,选址定位于年轻人约会,扫街的地域,比如风景区,著名商圈,电影院旁…………等等等等,那么接下来呢?

接下来就是想办法让这些实现吧?

那么需要做什么事情呢?

选址?

拉投资?

搞装修?

选餐饮菜单?

雇佣员工?

每一步怎么去做,时间点是什么?

等等的任务拆解以及计划,就需要到战术层了。

这些事情的执行,总是需要请人的吧?

先是核心团队分工去部署各项建设任务,当餐厅开设起来后,就需要组织稳定的运营团队,如服务、卫生、厨房、采购、人事等等,厨房里面还得分工,白案,热菜,冷菜等等吧?

每个部门需要设置管理层以及汇报关系吧?

因此你的组织结构就诞生了。

那具体每种角色是如何顺畅合作完成日常稳定的以及突发的各项任务呢?

比如,当顾客上门时,谁去引导客人入座,谁去点菜,怎么将点菜的讯息迅速传递到厨房,并分发到酒水间、冷菜间、热菜间?

并保证客人尽快能够吃到所点的菜?

你必须要考虑各种人员的协作流程,优化效率,因此业务流程就出现了。

人肉运营了一段时间,没有借助任何点餐系统,你发现也还能够。

客人点菜时,服务员手抄写下客人的要求,因为有复印纸,因此服务员能够将副本送入厨房,同时写下餐桌号码。

厨房规模较小,负责分配任务的员工看下菜单,分别往冷菜处的黑板上写下需要她们处理的,以及跑到热菜区的黑板上写下待处理的菜品,以及去酒水间报下品名即可。

可是随着经营的扩大,以上的人肉方式出现了很多问题,首先,手抄效率太低,顾客频繁换菜,响应来不及,手抄出错,导致经常报错菜。

厨房很混乱,不得不多招了几个人专门跑堂。

而一旦顾客要加菜,撤菜就更麻烦了,需要找出她们当时点的菜,再进行人工的批注和修改,同时要修改厨房后端的各个黑板……

因此你们想要开发一套智能系统,取代很多人肉工作,你们请了系统开发团队,她们经过评估,判断从点菜开始,一直到传菜都能够用系统解决。

手持终端,能够快速传递顾客点菜需求到打印机,打印系统能够根据顾客点菜的类型进行自动的分单打印,因此热菜间看到自己的热菜菜单,冷菜间看到自己的冷菜菜单,而酒水间看到酒店菜单。

当她们准备完毕后,送出,传菜员能够根据菜名与打印出来的单据进行传菜并根据顾客的点菜小票进行核对。

这套系统同时必须配备结算系统,将最终确认掉的菜单及消费价格传递到结算前台,收银员能够快速进行操作。

这套系统最终是需要展现出来的,那么手持终端的界面如何设计?

服务员能够用更少的点击完成一个菜的点餐吗?

结算中心的界面如何设计?

经过以上的故事,是不是更明白从战略、战术、业务流程图到页面流程图的关系了?

总结下:

先是有一个业务需求和业务目标,也即我们的愿景是什么?

（战略）

然后就诞生了我们需要分解出什么样的任务,如何执行战术?

（战术）

然后就诞生了需要架构什么部门,岗位去分工协作?

（组织架构）

然后就诞生了不同的部门在协作完成某件任务时的业务流程?

（业务流程）

业务流程基本稳定后,往往会考虑优化效率,因此会诞生出系统来支持流程,减少人肉环节,促进数据采集（系统愿景）

为了设计这个系统,PD需要思考什么功能能够取代某个环节的人肉工作（功能需求,系统流程）

不论是怎么样的功能最终都会以界面的方式呈现,设计师们会关注用户在系统里的任务流,行为路径,让用户完成任务更加高效愉悦。

（页面流程）

当然,除了业务流程,系统流程,页面流程,还有数据流程被人关注。

我们平时工作中,还会经常听人谈到泳道图啊,任务流程图啊等等概念,究竟是神马关系呢?

图5:

流程图的分类

本文着重于上述流程中的”业务流程图”——并会分享如何绘制泳道图——也即是PD们最多使用,技术们最多参考,UED们最多看到的流程图。

原来在第四部分会对泳道图的图示以及绘制方法、原则做更详细的说明,可是看当前的篇幅情况,预计会放到下篇,因此先在这里