如何绘制业务流程图

2024-04-27

1. 如何绘制业务流程图

流程图绘制的过程是这样的:
一、首先你需要明确你做的事情正常需要哪些步骤,这些步骤分出经过型行为与结果型行为。所谓经过型行为是指那些不直接产生结果,但必须要做的环节步骤。比如象你要驾驶一辆汽车到某地,那么你的第一步首先要坐到驾驶室里去,这一步骤不能直接让你到达目的地,但是你必须要做;结果型行为就是指那些可以产生结果,并对后面的选择产生直接影响的事情,比如继续上例中,第一部做到驾驶室之后的第二步,你需要把汽车发动起来,这就面临着两种可能的结果,其一是汽车顺利发动,你安全上路;另一种有可能是汽车出现故障,没能发动起来——这种情况下,你到达目的地的方法就必须要进行调整——或是更换交通工具,或是取消前往。
你要为这两种行为分别设计一个统一的图形,而后将这些图形按事情发展的顺序排列出来,图形中间写上步骤的行为名称。这个工作称作“逻辑路径设定”。

二、结果型行为的结果清单,能够让你继续按照正常顺序把事情进程做下去的结果,称之为“预期结果”,预期结果列入流程图的主路径中;而让你被迫改变进程顺序的结果,称为“意外结果”,意外结果可能会产生两种分支流程路径,其一是循环反复,即你需要回过头重新去进行主路径中曾经的步骤,这时你只要用另外的箭头把它们连接上就行了;还有一种是新的分支流程,即需要你采取另外的处理流程来达到目标,这有可能是一条完全的分支路径,即其之后的处理过程完全与主路径中设定的步骤无关,而直接达成目标;也有可能是部分分支路径,即经过几个新的步骤后,在某一环节上重新回到主流程的路径上;也有可能是要直接跳过中间的若干步骤。

三、连接各个进程步骤,用箭头连接成一条条完整的流程的路径,最后指向事务进程的重点,即你的任务目标。这样你就完成了你的流程图。

如何绘制业务流程图

2. 业务流程图的画法

你好,业务流程图其实很好绘制的,只要将中心主题确认后就好画了,下面将方法分享给你
打开画图工具,点击页面中央【立即体验】进入类型选择界面,点击左上角【新建文件】选择【流程图】进入在线绘制界面

画布四周有很多的工具栏,这些在绘制的过程中都是可以使用的,用鼠标点击左侧【基础图形】里面的任一图形将其拖曳至右边画布需要的位置即可
双击文本框即可对里面的内容进行添加,这时在右边出现的工具栏中将可以对文本的样式、排列及背景颜色根据自己的喜好进行设置

点击右上角【导出】在弹出的菜单栏中选择自己需要的格式进行导出即可
希望上述的方法可以帮助到你

3. 业务流程图的绘制

业务流程图的绘制是按照业务的实际处理步骤和过程进行的。业务流程图是一种系统分析人员都懂的共同语言, 用来描述系统组织结构、业务流程。基本符号及含义 如图所示

业务流程图的绘制

4. 如何绘制业务流程图

1. 业务流程图的“烹饪三部曲”


在绘制业务流程图前,思考如何精美,如何交互,使用什么工具,都不应该是重点。
真正重点的是将业务流程图的关键要素给搜集一番。请试图回答清楚以下几个问题,否则不要开始绘制流程图:
整个流程的起始点是什么?整个流程的终结点是什么?
在整个流程中,涉及到的角色都是谁?
在整个流程中,都需要做什么事情?(可是是一个会议,可以是一个任务)
这些会议和任务是可选还是必选的?
分别产出什么文档?
这有点像一个头脑风暴,能够帮助你将所需用到的原材料获取到,有了这些“米”和“水”,那就不愁去如何烹饪了。
在项目管理中,上个月,我们也试图给去规范化一个数据产品的设计开发流程。
这是一个数据产品的项目,而我们都不是对此很有经验的人。所以我们召集到所有相关的角色,组织了一次头脑风暴及卡片分类法的混合式应用。
让大家头脑风暴出自己认为在项目里必须的节点,如“需求调研”,“需求分析”,“kick off会议”,“PRD撰写及确认”,“数据评估”,“技术架构”,“DEMO绘制”,“指标算法定义”,等等。
在头脑风暴过程中,主持人将这些节点都写到白板上,等没有新的节点诞生后,大家一起对节点进行合并归类。之后呢?
将这些剩余下来的真正有价值的节点,撰写到即时贴上,开始进行排序。在排序过程中,可以由一个人先主导,他会按照自己的理解,将各个节点放到按角色排布的泳道中,并设计好先后的顺序。在他进行的过程中,其他人不断进行提问:“这项任务开始前,需要什么样的条件?”“这个任务是必须的吗?”然后一起调整先后顺序。直到最终没有人有任何重大的异议。
之后拍照留念。

5. 如何绘制业务流程图

 业务流程图的表达的6个关键问题
业务流程图的“烹饪三部曲”
  在绘制业务流程图前,思考如何精美,如何交互,使用什么工具,都不应该是重点。
  真正重点的是将业务流程图的关键要素给搜集一番。请试图回答清楚以下几个问题,否则不要开始绘制流程图:
  整个流程的起始点是什么?整个流程的终结点是什么?
  在整个流程中,涉及到的角色都是谁?
  在整个流程中,都需要做什么事情?(可是是一个会议,可以是一个任务)
  这些会议和任务是可选还是必选的?
  分别产出什么文档?
  这有点像一个头脑风暴,能够帮助你将所需用到的原材料获取到,有了这些“米”和“水”,那就不愁去如何烹饪了。
  在项目管理中,上个月,我们也试图给去规范化一个数据产品的设计开发流程。
  这是一个数据产品的项目,而我们都不是对此很有经验的人。所以我们召集到所有相关的角色,组织了一次头脑风暴及卡片分类法的混合式应用。
  让大家头脑风暴出自己认为在项目里必须的节点,如“需求调研”,“需求分析”,“kick off会议”,“PRD撰写及确认”,“数据评估”,“技术架构”,“DEMO绘制”,“指标算法定义”,等等。
  在头脑风暴过程中,主持人将这些节点都写到白板上,等没有新的节点诞生后,大家一起对节点进行合并归类。之后呢?
  将这些剩余下来的真正有价值的节点,撰写到即时贴上,开始进行排序。在排序过程中,可以由一个人先主导,他会按照自己的理解,将各个节点放到按角色排布的泳道中,并设计好先后的顺序。在他进行的过程中,其他人不断进行提问:“这项任务开始前,需要什么样的条件?”“这个任务是必须的吗?”然后一起调整先后顺序。直到最终没有人有任何重大的异议。
  之后拍照留念。
  

  然后可整理成电子文档,如project或者excel版本(使用excel做项目管理?) 
  

  但是,业务流程图和上述项目中的流程不太相同的是:
  项目中的各种活动节点有更宽泛的可配置性,任务A和任务B是否并行,还是串行,如果项目组成员达成共识,是可以调整,并且多做尝试的。所以可以用集思广益的做法去头脑风暴出一个暂定比较合理的流程。而业务流程图的梳理,有两种:
  一种是基于现实发生的业务流程如实反映。这显然不是你一个团队能够YY的结果。更需要走到现实环境中,去调研,去梳理,去确认。
  另一种是基于流程优化的方案,当你已经掌握了目前的流程现实如何运作时,基于分析,讨论,能够判断出流程中不合理的地方,给出一个更完善或者有更效率、成本更低的新的流程出来——或许你要求增加一个部门,或者你需要删减一个环节,或者中间的若干步使用新开发的系统去取代。
  总之,大多数时候,你要想做第二种流程图,必然要先将第一种给梳理出来。所以,第一种如实反映的流程图是躲不过的。既然如此,基于YY或者头脑风暴是不现实的。我们需要走到前线去,掌握现实中业务是如何运作的。而且很多时候,越细节越好。
  那怎么做呢?基于有限的知识与经验,我可以给如下建议:
调研——2.梳理呈现——3.评审确认三部曲,如图所示:

         

  2. 调研——问正确的问题,多问问题,多问几个人

  除了在本部分开始的那几个问题要顾及到,其实调研过程解决的仍然是who,what,why,how,以及where的问题:谁,在什么情况下,做了什么事情,这个事情需要什么前置条件,又输出了什么,这个事情在哪里完成的?搞明白这几个问题,我们的调研就可以圆满完成了。
  流程图的表现,要回答这几个问题:
  Who——谁?部门,角色,岗位
  What——什么事情?
  Where——在哪里做的?在我梳理的业务流程图上,where更多表示是文档还是各种系统,用来表示信息化的程度。比如当我们梳理中发现,有一项登记,是用excel而不是业务系统来进行的,那么在这里的where就可以表示为:excel文档。
  Document——那产生的这份文档叫什么名字?也写出来,代表有文件的传递,而以后要进行信息化的话,此份人肉文档也是需要被消除而被系统取代的。(相反,如果这项工作是在某个系统里操作的,where就可以写成“人事系统”,文档可以继续存在,即该系统中的表单名称:“员工登记表单”)
  Condition——条件。在这种条件下,下一个活动还能够继续,即用逻辑链接线的方式来表示一项活动的输入和输出,指向某个活动的箭头就表示此活动的前置输入条件。
  Dicision——决策。有些活动会产生一个条件判断,根据不同的判断结果从而走不同的分支流程。比如输入员工信息的时候,可以根据员工之前是否就职过,选择不同的流程,对于已经就职过的,选用之前的工号而不用生成新的工号。
  

  举个案例(如果不太恰当,请意会)。假设你受命要调研两家餐饮店的业务流程,目的是给他们提供性价比最高的点餐系统。
  在调研中:
  1. 你首先可以要求精通业务流程的人给你系统讲解一遍。
  2. 调研具体操作的人,来验证他给你讲解的是否全面和偏差。
  3. 实地观察和记录(花点时间走遍业务流程)
  三种方式相互结合使用。第一种方法可以让你首先建立一个系统观,了解大体枝干,但是很难切入到可能会出现问题的细节。第二种方法太依赖于问题的质量以及问问题的场景。有很多结论的不正确其实是因为问错了人或者问问题的方法不对。那么就需要借助第三种,在观察中再进行验证。
  比如,你现在找到了一个厨师:
  你主要负责做什么菜系?
  热菜。
  那菜单都是谁给你的?
  我们的服务员。
  她都怎么提供给你?
  她负责客人点菜后,然后手写一个单子,给我放到窗口上。
  单子上都会写什么?
  桌号,菜名等
  那如何客人点的是冷菜呢?
  恩,有复印本,直接拿一份给冷菜间。
  那你怎么开始工作呢?从洗菜到切菜,一直烹饪都是一个人吗?
  哦,不,我只负责烹饪。当接到菜单后,首先我的助理会进行择菜,刀工进行切菜,这样如果有几个菜就完全可以并行。
  当你们做好后呢?
  放到窗口,按铃,喊桌号和菜名,传菜员就会传菜。
  ……
  在这些问题中,就涉及到了“分单”,“切菜”,“择菜”,”烹饪”,“传菜”,“上菜”几个活动,也涉及到了“服务员”,“厨师”,“助理”,“刀工”,“传菜员”几个角色。几个活动的次序也比较清楚了。
  而另一家餐饮店的业务流程却是不一样的,你同样抓住一个厨师进行询问:
  要做什么菜,菜单是哪里来的?
  打印出来的。
  所有菜都会在这里打印吗?
  哦,只有热菜在这里打印出来,冷菜、酒水就会在冷菜间和酒水间打印出来。
  打印机是谁在操作的?
  没人操作,它会自动打印不同的单子给我们。
  ……下面的问题,可能厨师就不了解了,要问点菜员了。
  请问你是怎么点菜的?
  拿设备啊,客人点菜就按几下,确认就好了。
  之后呢?
  之后就可以将菜单打印出来。
  不同的菜系会在不同的烹饪间打印吗?
  是的,我们可以分单打印。是在这中心打印机里完成分单。
  然后,你可以继续调研烹饪后的传菜和上菜流程。
  3. 梳理并呈现

  你的调研和观察使你拥有了“烹饪”所需的原材料。
  角色:部门、岗位或人
  活动:做了什么事情
  次序:做这些事情的次序如何
  规则:什么情况下到什么事情
  还记得我们之前提过的流程图要素吗?回顾下:
  

  接下来的任务是不是很简单,对,就像填空题一样简单。将活动/事件按照一定的规则填到由部门和时间两条维度决定的框框里。
  这个阶段是paper work,你需要将调研阶段收集到的原材料用更直观明了的方式呈现出来。从而能够更好进行评审和确认。也为以后的流程评审和优化做准备。
  在刚开始,笔和纸的原始搭配仍然是最好的起步工具。你可以暂时忽略掉美观或者可复用的因素。但是当你对要呈现的流程已经有足够的信心时,就可以借助软件工具了。
  3.1 复杂流程的分解

  不可能将所有的活动都放到一张图里呈现。
  “业务流程是有层次性的,这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。这样一个层次关系符合人们的思维习惯,有利于企业业务模型的建立  企业部门之间的层次关系表。一般来说,我们可以先建立主要业务流程的总体运行过程(其中包括了整个企业的大的战略),然后对其中的每项活动进行细化,落实到各个部门的业务过程,建立相对独立的子业务流程以及为其服务的辅助业务流程。”
  ——引自《百度百科》 业务流程词条
  对于很多新人来讲,业务最难的在于划分业务流程图的层次上。
  首先,明确你要梳理的业务流程的范围——用大的粗略的关键节点,讲清楚这个业务流程范围中的故事,就是顶层业务流程图。你的顶层业务流程图是业务全局故事的简单表达,但是请注意这里的业务全局不见得是公司整体的业务全局,而是你界定好的业务范围。比如,下图是餐厅的日常运作流程图,若你界定的业务范围是面向顾客的点餐和结帐流程,那么这就是顶层业务流程图。但是若你界定的是整个餐厅的运作业务流程,那这显然还是一个子集——并没有包含餐厅的采购、供应商管理、一级库存管理等工作。
  
  

  其次,先从顶层的业务流程分解开始,由粗至细。顶层业务流程图的梳理原则:
  1. 界定范围内的业务全局故事。
  2. 包含该范围内的关键节点。并且,当被质疑说某某环节怎么不存在时,自己要清楚它在下一层分解中应该被包含在那个关键节点中。比如,赠送10周年优惠券,应该会在结帐节点分解中出现。而打印分单,会在点菜节点中分解。而准备儿童座椅应该是接待入座环节。
  3. 顶层流程图分解出来的关键节点未必都会细化分解下去,生成二级以及三级的流程图。这要看该节点涉及到的“活动”以及“角色”是否复杂。
  再看一个案例,对传统生产型企业的进销存主业务流程进行分解。橙色的代表被分解点,已经可以分解为四层。当我们分解到第四层,发现再往下去涉及到的活动和角色都已经很少时,就不必再分解了,而是可以将第四层的关键节点直接作为第三层业务流程的“活动”,而不是子流程图。
  当然,这是依赖于你梳理业务流程的目标。如果你偏偏是要对“打样”环节进行剖析优化,则还可以继续分解下去。
  

  这一步的工作会帮你建立出清晰的流程目录结构,如下图所示是摘选于刚完成的一个流程梳理的项目中的目录结构部分。可以看到全图即是顶层关键节点,作为老大,可能只要看这一层就够了。下面则会对顶层做更多细化拆解。
  “H3.样品认证”在顶层业务流程图中,仅仅是一个“活动”,而在自己细化的这一个层次中,则会包含详细的子活动一级参与者。
  

  3.2 流程图的常用图示
  

  我常用的就是前两行的“活动”,“判断”,“逻辑关系线”,“起始与终止”,以及第二行的“子流程”,和“文件/表单”。如果你不是符号控,我建议这几个就足够了。
  其中,“子流程”此图示就是可以帮助你将流程分解得到的子流程能够串联起来,比如,当在”A流程”中涉及到进一步需要分解的”A1.1流程”时,就可以在”A流程”中用子流程符号代表“A1.1”。然后你的读者就会明白要想进一步了解”A1.1″应该参考另外一个流程图。
  流程图的常用结构:
  

  给大家看一些案例:
  基本上包含大多数图示的流程图:
  

  
  只用到少数几个图示画的简单流程图(台湾人的文档中称为程序图——不过这里的程序不是指计算机程序,而是process,仅仅是体现任务之间的处理流程,所以使用极简单的符号也不为怪了):
  

  以上两个流程图案例,从符号的复杂程度上来讲,一个是完整流程图,一个是基本流程图,但是从表现形式来讲,都属于“泳道图”——Swimlane。这也是我们最常用的一种表现形式了。泳道图能够很好体现部门或者角色在流程中的职责以及上下游的协作关系。且流程图本身的标准容易掌握,达成共识也就更加容易。
  3.3 泳道图精要
  

  2大维度:一般泳道图的横向会作为部门或岗位维,当然也有例外,如上述案例中就是横的泳道。而纵向则做为阶段维——时间是从上到下发展的。如果复杂的泳道图,在任务分解上可以在阶段维里做一些划分,比如“采购”,“生产”,“销售”,”配送”等。
  活动流转:活动就像一个游泳员一样,游到不同的泳道中去执行任务。
  在上文中的软件推荐部分,我推荐过smartdraw工具,此工具还附带了泳道图的模板,大家比较更快能够上手:
  

    3.4 Do vs Donnot 业务流程图的注意事项!
  DO
  1. 让涉众参与,不要闭门造车
  业务流程图包含了你图上的各个参与角色代表,与他们适时确认事情的原本流程,禁止自己YY。
  2. 恰当的层次分解,不要将所有都铺到一张图上
  如上所示。
  3. 逐渐深入,先抓枝干
  切忌胡子眉毛一把抓。
  4. 流程一定有开始和结束
  切忌交付出来的流程图,让读者还来问你:流程的开始点是什么?用清晰的代表开始和结束的符号来完成第一步和最后一步。
  5. 编号,编号,编号
  这是让沟通效率更高的优化措施。当你有了编号系统,相当于对你的流程图都赋予了唯一识别身份证号。这比中文名称更有效。比如当我们完成了业务流程图后,负责业务流程规则审核和优化的部门能够清楚在邮件里传达:H5.1流程优化,大家就更明确指的是什么。
  DONNOT
  1. 自己YY应用的环节而不是现实中的环节
  2. 所有的环节都试图放到一张图上
  3. 一开始就陷入细节,胡子眉毛一起抓
  4. 流程很难让人分清楚从哪里开始,到哪里结束

  4. 评审及后续行动

  验证你是否做到了以上的DO,以及规避了Donnot的做法是什么?

  很好办,及时与各位进行评审。将各个涉众都叫到一起,给他们看你梳理出来的成果。

  这会发现一些有意思的事情,除了评审你的流程图是否符合现实外,也会评审目前的业务流程是否符合理想。不同的部门和岗位的代表会在这个评审中,确认当前,也会相互提出意见,甚至吵起来,这不失于做流程优化的一个很好的契机。暂且不表了。

如何绘制业务流程图

6. 如何绘制业务流程图

方法/步骤
>01
首先打开visio软件,在桌面双击软件快捷方式就可以打开或者在“开始—所有程序—Microsoft Office—Microsoft Visio 2010”打开,当然,版本不一定是2010版的,

>02
打开软件后,软件会首先让你选择一个模板,便于你绘画流程图。

>03
选择一个模板。在这里,我们暂且选择“基本流程图”为例子讲解。首先在“选择模板”处,选中“基本流程图”,在右边,点击“创建”,:

>04
“创建”后,我们就进入了工作空间,开始正式的绘画流程图,
>05
在窗口的左侧是各种各样的形状,便于选择流程图中会出现的各样图形。右侧的方格纸是我们的“画布”,我们可以很方便的将左侧的各种图形直接用左键拖拽到右侧的方格纸上,:

>06
如果我们要在这个框的基础上引出其他的框,我们只需将鼠标在该框上点击一下,然后将鼠标向上下左右四个方向移动,就可以看到一个浅色的箭头,并且显示出我们可能会用到的框,

>07
当然,如果没有出现你需要的流程图形状时,你同样可以直接从左侧拖拽,然后将对应的地方连接上线就可以了。

>08
如果需要调整图形的角度,可以将鼠标移动到该形状的上方,直到鼠标成为一个标有箭头的圆圈,此时你就可以按住鼠标左键并移动鼠标,直到调整到你想要的位置,

>09
当我们将所有的流程图画完之后,有时需要在某些框内写上文字,直接双击该框就可以输入文字了

7. 业务流程图该如何画了

你好,我最近一直在绘制不容类型的思维导图,我经常使用的方法是在线网站绘制的,下面酱方法和你说下:
1.浏览器中搜索进入到网站中,在网站中会有很多操作,我们可先对其进行熟悉,选择页面中央的立即体验就可以开始绘制了。

2.会自动跳转到在线编辑流程图的面板中,在绘制面板中是有流程图的基础图形和工具栏,以及编辑面板等。

3.首先是对流程图框架进行搭建使用,选择左侧的流程图图形对框架进行搭建使用。

4.框架搭建成功之后双击可以对里面的内容进行输入,双击流程图图形可以进行操作使用。 
5.需要对绘制的流程图进行丰富使用,保证用户体验度较高,点击流程图图形,在右侧的工具栏中可以选择设置流程图图形的背景颜色以及边框颜色。
6.绘制成功的流程图可以保存到该网站中以便后期进行编辑使用,但是要先对账号进行登录,QQ,微信,手机号这三种操作方法都可以。
7.还可以对绘制成功的业务流程图导出进行使用,在面板的右上方选择导出字样之后选择导出格式即可。
绘制完的效果图展示:

希望上述的方法可以帮助到大家!

业务流程图该如何画了

8. 如何绘制业务流程图

业务流程图的表达的6个关键问题
业务流程图的“烹饪三部曲”
  在绘制业务流程图前,思考如何精美,如何交互,使用什么工具,都不应该是重点。
  真正重点的是将业务流程图的关键要素给搜集一番。请试图回答清楚以下几个问题,否则不要开始绘制流程图:
  整个流程的起始点是什么?整个流程的终结点是什么?
  在整个流程中,涉及到的角色都是谁?
  在整个流程中,都需要做什么事情?(可是是一个会议,可以是一个任务)
  这些会议和任务是可选还是必选的?
  分别产出什么文档?
  这有点像一个头脑风暴,能够帮助你将所需用到的原材料获取到,有了这些“米”和“水”,那就不愁去如何烹饪了。
  在项目管理中,上个月,我们也试图给去规范化一个数据产品的设计开发流程。
  这是一个数据产品的项目,而我们都不是对此很有经验的人。所以我们召集到所有相关的角色,组织了一次头脑风暴及卡片分类法的混合式应用。
  让大家头脑风暴出自己认为在项目里必须的节点,如“需求调研”,“需求分析”,“kick off会议”,“PRD撰写及确认”,“数据评估”,“技术架构”,“DEMO绘制”,“指标算法定义”,等等。
  在头脑风暴过程中,主持人将这些节点都写到白板上,等没有新的节点诞生后,大家一起对节点进行合并归类。之后呢?
  将这些剩余下来的真正有价值的节点,撰写到即时贴上,开始进行排序。在排序过程中,可以由一个人先主导,他会按照自己的理解,将各个节点放到按角色排布的泳道中,并设计好先后的顺序。在他进行的过程中,其他人不断进行提问:“这项任务开始前,需要什么样的条件?”“这个任务是必须的吗?”然后一起调整先后顺序。直到最终没有人有任何重大的异议。
  之后拍照留念。
  

  然后可整理成电子文档,如project或者excel版本(使用excel做项目管理?) 
  

  但是,业务流程图和上述项目中的流程不太相同的是:
  项目中的各种活动节点有更宽泛的可配置性,任务A和任务B是否并行,还是串行,如果项目组成员达成共识,是可以调整,并且多做尝试的。所以可以用集思广益的做法去头脑风暴出一个暂定比较合理的流程。而业务流程图的梳理,有两种:
  一种是基于现实发生的业务流程如实反映。这显然不是你一个团队能够YY的结果。更需要走到现实环境中,去调研,去梳理,去确认。
  另一种是基于流程优化的方案,当你已经掌握了目前的流程现实如何运作时,基于分析,讨论,能够判断出流程中不合理的地方,给出一个更完善或者有更效率、成本更低的新的流程出来——或许你要求增加一个部门,或者你需要删减一个环节,或者中间的若干步使用新开发的系统去取代。
  总之,大多数时候,你要想做第二种流程图,必然要先将第一种给梳理出来。所以,第一种如实反映的流程图是躲不过的。既然如此,基于YY或者头脑风暴是不现实的。我们需要走到前线去,掌握现实中业务是如何运作的。而且很多时候,越细节越好。
  那怎么做呢?基于有限的知识与经验,我可以给如下建议:
调研——2.梳理呈现——3.评审确认三部曲,如图所示:

         

  2. 调研——问正确的问题,多问问题,多问几个人

  除了在本部分开始的那几个问题要顾及到,其实调研过程解决的仍然是who,what,why,how,以及where的问题:谁,在什么情况下,做了什么事情,这个事情需要什么前置条件,又输出了什么,这个事情在哪里完成的?搞明白这几个问题,我们的调研就可以圆满完成了。
  流程图的表现,要回答这几个问题:
  Who——谁?部门,角色,岗位
  What——什么事情?
  Where——在哪里做的?在我梳理的业务流程图上,where更多表示是文档还是各种系统,用来表示信息化的程度。比如当我们梳理中发现,有一项登记,是用excel而不是业务系统来进行的,那么在这里的where就可以表示为:excel文档。
  Document——那产生的这份文档叫什么名字?也写出来,代表有文件的传递,而以后要进行信息化的话,此份人肉文档也是需要被消除而被系统取代的。(相反,如果这项工作是在某个系统里操作的,where就可以写成“人事系统”,文档可以继续存在,即该系统中的表单名称:“员工登记表单”)
  Condition——条件。在这种条件下,下一个活动还能够继续,即用逻辑链接线的方式来表示一项活动的输入和输出,指向某个活动的箭头就表示此活动的前置输入条件。
  Dicision——决策。有些活动会产生一个条件判断,根据不同的判断结果从而走不同的分支流程。比如输入员工信息的时候,可以根据员工之前是否就职过,选择不同的流程,对于已经就职过的,选用之前的工号而不用生成新的工号。
  

  举个案例(如果不太恰当,请意会)。假设你受命要调研两家餐饮店的业务流程,目的是给他们提供性价比最高的点餐系统。
  在调研中:
  1. 你首先可以要求精通业务流程的人给你系统讲解一遍。
  2. 调研具体操作的人,来验证他给你讲解的是否全面和偏差。
  3. 实地观察和记录(花点时间走遍业务流程)
  三种方式相互结合使用。第一种方法可以让你首先建立一个系统观,了解大体枝干,但是很难切入到可能会出现问题的细节。第二种方法太依赖于问题的质量以及问问题的场景。有很多结论的不正确其实是因为问错了人或者问问题的方法不对。那么就需要借助第三种,在观察中再进行验证。
  比如,你现在找到了一个厨师:
  你主要负责做什么菜系?
  热菜。
  那菜单都是谁给你的?
  我们的服务员。
  她都怎么提供给你?
  她负责客人点菜后,然后手写一个单子,给我放到窗口上。
  单子上都会写什么?
  桌号,菜名等
  那如何客人点的是冷菜呢?
  恩,有复印本,直接拿一份给冷菜间。
  那你怎么开始工作呢?从洗菜到切菜,一直烹饪都是一个人吗?
  哦,不,我只负责烹饪。当接到菜单后,首先我的助理会进行择菜,刀工进行切菜,这样如果有几个菜就完全可以并行。
  当你们做好后呢?
  放到窗口,按铃,喊桌号和菜名,传菜员就会传菜。
  ……
  在这些问题中,就涉及到了“分单”,“切菜”,“择菜”,”烹饪”,“传菜”,“上菜”几个活动,也涉及到了“服务员”,“厨师”,“助理”,“刀工”,“传菜员”几个角色。几个活动的次序也比较清楚了。
  而另一家餐饮店的业务流程却是不一样的,你同样抓住一个厨师进行询问:
  要做什么菜,菜单是哪里来的?
  打印出来的。
  所有菜都会在这里打印吗?
  哦,只有热菜在这里打印出来,冷菜、酒水就会在冷菜间和酒水间打印出来。
  打印机是谁在操作的?
  没人操作,它会自动打印不同的单子给我们。
  ……下面的问题,可能厨师就不了解了,要问点菜员了。
  请问你是怎么点菜的?
  拿设备啊,客人点菜就按几下,确认就好了。
  之后呢?
  之后就可以将菜单打印出来。
  不同的菜系会在不同的烹饪间打印吗?
  是的,我们可以分单打印。是在这中心打印机里完成分单。
  然后,你可以继续调研烹饪后的传菜和上菜流程。
  3. 梳理并呈现

  你的调研和观察使你拥有了“烹饪”所需的原材料。
  角色:部门、岗位或人
  活动:做了什么事情
  次序:做这些事情的次序如何
  规则:什么情况下到什么事情
  还记得我们之前提过的流程图要素吗?回顾下:
  

  接下来的任务是不是很简单,对,就像填空题一样简单。将活动/事件按照一定的规则填到由部门和时间两条维度决定的框框里。
  这个阶段是paper work,你需要将调研阶段收集到的原材料用更直观明了的方式呈现出来。从而能够更好进行评审和确认。也为以后的流程评审和优化做准备。
  在刚开始,笔和纸的原始搭配仍然是最好的起步工具。你可以暂时忽略掉美观或者可复用的因素。但是当你对要呈现的流程已经有足够的信心时,就可以借助软件工具了。
  3.1 复杂流程的分解

  不可能将所有的活动都放到一张图里呈现。
  “业务流程是有层次性的,这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。这样一个层次关系符合人们的思维习惯,有利于企业业务模型的建立  企业部门之间的层次关系表。一般来说,我们可以先建立主要业务流程的总体运行过程(其中包括了整个企业的大的战略),然后对其中的每项活动进行细化,落实到各个部门的业务过程,建立相对独立的子业务流程以及为其服务的辅助业务流程。”
  ——引自《百度百科》 业务流程词条
  对于很多新人来讲,业务最难的在于划分业务流程图的层次上。
  首先,明确你要梳理的业务流程的范围——用大的粗略的关键节点,讲清楚这个业务流程范围中的故事,就是顶层业务流程图。你的顶层业务流程图是业务全局故事的简单表达,但是请注意这里的业务全局不见得是公司整体的业务全局,而是你界定好的业务范围。比如,下图是餐厅的日常运作流程图,若你界定的业务范围是面向顾客的点餐和结帐流程,那么这就是顶层业务流程图。但是若你界定的是整个餐厅的运作业务流程,那这显然还是一个子集——并没有包含餐厅的采购、供应商管理、一级库存管理等工作。
  
  

  其次,先从顶层的业务流程分解开始,由粗至细。顶层业务流程图的梳理原则:
  1. 界定范围内的业务全局故事。
  2. 包含该范围内的关键节点。并且,当被质疑说某某环节怎么不存在时,自己要清楚它在下一层分解中应该被包含在那个关键节点中。比如,赠送10周年优惠券,应该会在结帐节点分解中出现。而打印分单,会在点菜节点中分解。而准备儿童座椅应该是接待入座环节。
  3. 顶层流程图分解出来的关键节点未必都会细化分解下去,生成二级以及三级的流程图。这要看该节点涉及到的“活动”以及“角色”是否复杂。
  再看一个案例,对传统生产型企业的进销存主业务流程进行分解。橙色的代表被分解点,已经可以分解为四层。当我们分解到第四层,发现再往下去涉及到的活动和角色都已经很少时,就不必再分解了,而是可以将第四层的关键节点直接作为第三层业务流程的“活动”,而不是子流程图。
  当然,这是依赖于你梳理业务流程的目标。如果你偏偏是要对“打样”环节进行剖析优化,则还可以继续分解下去。
  

  这一步的工作会帮你建立出清晰的流程目录结构,如下图所示是摘选于刚完成的一个流程梳理的项目中的目录结构部分。可以看到全图即是顶层关键节点,作为老大,可能只要看这一层就够了。下面则会对顶层做更多细化拆解。
  “H3.样品认证”在顶层业务流程图中,仅仅是一个“活动”,而在自己细化的这一个层次中,则会包含详细的子活动一级参与者。
  

  3.2 流程图的常用图示
  

  我常用的就是前两行的“活动”,“判断”,“逻辑关系线”,“起始与终止”,以及第二行的“子流程”,和“文件/表单”。如果你不是符号控,我建议这几个就足够了。
  其中,“子流程”此图示就是可以帮助你将流程分解得到的子流程能够串联起来,比如,当在”A流程”中涉及到进一步需要分解的”A1.1流程”时,就可以在”A流程”中用子流程符号代表“A1.1”。然后你的读者就会明白要想进一步了解”A1.1″应该参考另外一个流程图。
  流程图的常用结构:
  

  给大家看一些案例:
  基本上包含大多数图示的流程图:
  

  
  只用到少数几个图示画的简单流程图(台湾人的文档中称为程序图——不过这里的程序不是指计算机程序,而是process,仅仅是体现任务之间的处理流程,所以使用极简单的符号也不为怪了):
  

  以上两个流程图案例,从符号的复杂程度上来讲,一个是完整流程图,一个是基本流程图,但是从表现形式来讲,都属于“泳道图”——Swimlane。这也是我们最常用的一种表现形式了。泳道图能够很好体现部门或者角色在流程中的职责以及上下游的协作关系。且流程图本身的标准容易掌握,达成共识也就更加容易。
  3.3 泳道图精要
  

  2大维度:一般泳道图的横向会作为部门或岗位维,当然也有例外,如上述案例中就是横的泳道。而纵向则做为阶段维——时间是从上到下发展的。如果复杂的泳道图,在任务分解上可以在阶段维里做一些划分,比如“采购”,“生产”,“销售”,”配送”等。
  活动流转:活动就像一个游泳员一样,游到不同的泳道中去执行任务。
  在上文中的软件推荐部分,我推荐过smartdraw工具,此工具还附带了泳道图的模板,大家比较更快能够上手:
  

    3.4 Do vs Donnot 业务流程图的注意事项!
  DO
  1. 让涉众参与,不要闭门造车
  业务流程图包含了你图上的各个参与角色代表,与他们适时确认事情的原本流程,禁止自己YY。
  2. 恰当的层次分解,不要将所有都铺到一张图上
  如上所示。
  3. 逐渐深入,先抓枝干
  切忌胡子眉毛一把抓。
  4. 流程一定有开始和结束
  切忌交付出来的流程图,让读者还来问你:流程的开始点是什么?用清晰的代表开始和结束的符号来完成第一步和最后一步。
  5. 编号,编号,编号
  这是让沟通效率更高的优化措施。当你有了编号系统,相当于对你的流程图都赋予了唯一识别身份证号。这比中文名称更有效。比如当我们完成了业务流程图后,负责业务流程规则审核和优化的部门能够清楚在邮件里传达:H5.1流程优化,大家就更明确指的是什么。
  DONNOT
  1. 自己YY应用的环节而不是现实中的环节
  2. 所有的环节都试图放到一张图上
  3. 一开始就陷入细节,胡子眉毛一起抓
  4. 流程很难让人分清楚从哪里开始,到哪里结束

  4. 评审及后续行动

  验证你是否做到了以上的DO,以及规避了Donnot的做法是什么?

  很好办,及时与各位进行评审。将各个涉众都叫到一起,给他们看你梳理出来的成果。

  这会发现一些有意思的事情,除了评审你的流程图是否符合现实外,也会评审目前的业务流程是否符合理想。不同的部门和岗位的代表会在这个评审中,确认当前,也会相互提出意见,甚至吵起来,这不失于做流程优化的一个很好的契机。暂且不表了。