图1：用即时贴与白板做的简单流程图
前言：近来一段时间，忙于整理业务流程图，期间，关于流程图的绘制方法和工具也与内部团队和外部做了心得交流，恰好，个人生活也牵涉在买房，婚礼，户口迁移等流程中。不知不觉，伴随着实践与反思，个人所得的系统知识趋于完整，今儿天气极好，坐在飘窗一隅，听着间或几声鸟鸣歌唱，偶尔瞥一眼窗外的遍地绿荫，真真觉得是个写点什么的日子。所以就整理成文，如果恰好对你有所帮助，那是真真好的。
真实整理的流程牵涉到公司未公布的计划，不好公开，所以在本文中会借助一个简单的案例替代（这个案例呢，也就是计划写本文前30分分钟才想到的，如有考虑不周，请各位见谅），但是仅传达概念和方法，倒也足够了。恩，甄環体告一段落，咱们开始吧。
本文会包含几块内容：
1. 什么是流程图？流程图和其他图表（如线框图，概念图，架构图，用例图）有什么不同？
2. 为什么需要流程图？
3. 流程图的分类？
4. 如何绘制流程图？
5. 流程图绘制工具
视篇幅情况，会在行文时略加划分为系列，敬请关注并多多交流。
第一部分：什么是流程图？
1. 定义
了解一个事情，我习惯从它的定义开始。至于为什么，可以参见我之前的博客文章http://heidixie.blog.sohu.com/161709085.html
我们因为厌恶十年教育，厌恶背各种定理和定义，所以我发现生活中和工作中很多人都很讨厌给一个事情下定义以及去参考定义。所以你会发现很多人在一起争吵得不可开交，仔细去听，原来是鸡同鸭讲，根本不在一个频道上。对于一个事情的描述，没有一个共同的语言，没有所谓的术语。有定义很好办，你们共同引用一个定义，发现定义有问题，OK，去补充这个定义，并扩展到更多的人群。当然，任何事情过犹不及，我们相互提醒吧。
那什么是流程图呢？说文解字是一种了解定义的好方法。流程图=流程+图，如下图：
图2：流程图的定义
流程：Flow,是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程，流程是自然而然就存在的。但是它可以不规范，可以不固定，可以充满问题。所以就会造成看似没有流程。前不久，团队每个人对接一个业务团队去调研流程，反馈给我的流程有一些缺失。询问时，负责人反馈给我的答复是：这一块业务他们没有流程。其实严格意义上讲，业务已经开展，不可能没有流程，只是说没有固定的流程或者你调研的对象也讲不清楚。
图：Chart 或者 Diagram, 是将基本固化有一定规律的流程进行显性化和书面化，从而有利于传播与沉淀、流程重组参考。
从定义可以看出，只要有事情和任务，流程就会有，但是并不是所有的流程都适合用流程图的方式去表现，适合用流程图去表现的流程是一定程度固定的有规律可循的，流程中的关键环节不会朝令夕改的。
2. 流程图与其他图表的对比
工作中我们还用到或听到很多其他类型的图表，比如交互设计师们经常说的线框图(Wireframes)，信息架构图或站点地图(Site
Map)，，开发工程师们经常说的用例图(Use Case)或E-R图。这些不同的图表要表达的内容有何种差异呢？简单做个对比，如图
图3：流程图VS其他常用图表
如果要串到某一个项目来说，可以理解成：
用例图（Use Case）：
表现了一个角色在系统里要完成的活动是什么，比如用户这个角色与ATM取款机的交互过程中，用户需要完成的活动有存钱，取钱，查询等。而存钱这个活动再可以进一步细分为插卡，输入密码，输入金额，ATM吐钞，用户收款，退卡等活动。用例图可以不考虑用户动作的前后次序，而仅仅提取一些关键的动宾短语，映射出系统应该满足的功能点。常用用例图的人是产品经理和开发工程师。
流程图则表示用户每一个活动的前后次序，比如用户必须要先插入银行卡，才能够输入密码，且流程图必须直接表现出各种异常判断，比如当密码错误时，出现什么提示，密码输入错误超过多少次时，出现什么提示和动作。常用流程图的人是产品经理，设计师，或者任何需要讲述业务如何运作的人。
信息架构图,站点地图(Site Map)：
表现为了做一个这样的系统，功能与内容的展现层次是什么，比如用户一进去后，欢迎页面的导航如何设计，是否直接出现取款，存款，查询，或者还有别的导航？常用信息架构图的是设计师。但是常用组织架构图的是HR。
线框图（Wireframe）：
将具体每个界面的内容布局和权重表达出来，且标注出一些交互细节的设计，比如当密码错误后，如何提示下一步动作。常用线框图的人是设计师。
实体关系图(E-R图):
则是数据库架构的工作，表示一个业务系统或场景中的实体时间的关系，比如储户与银行卡的关系是归属1对多，通过开卡事件产生关联。一般来讲，用矩形来表示实体，椭圆标识这个实体的属性，比如储户这个实体的属性有：姓，名，手机号码，住址等。而银行卡的属性有：开户行，开户名称，银行卡号等。
以上的这些图表各自都有领域的专家，我这里就不班门弄斧了。
那么流程图要体现出他的差异定义，要素是什么？总结出了流程图的6大要素，希望大家能够记住，这6个要素可以在以后的文章里不断回顾，你也可以拿来判断你所看到的流程图是否专业。
图4：流程图6大要素
参与者：谁在这个流程中？可以是系统，可以是个打印机，更多的指什么角色——一般是有某种工种的人。比如客服同时有小A和小B两人，但是若他们的工作性质完全一样，那么在流程图里只需要写一个客服角色就可以了。
活动：做了什么事，比如点餐，结帐等活动。
次序：这些事情发生的前后顺序如何，哪个任务是其他任务的前置条件？比如客人不结帐，就不会产生送他优惠卡的活动。
输入：每项活动开始取决于什么样的输入物或数据，比如做饭的师傅开始做菜时，需要拿到具体的点菜单。
输出：每项活动结束后，会输入什么样的文档或数据传递给下一方，比如师傅做好菜后，如何让负责传菜的人知道菜已经做好？
标准化：采用一套标准化的符号用以传递你的流程图，从而使受众更快明白。
关于流程图的标准化，并不是强制的，事实上，我们见过很多种类的流程图，只要能够传递明白任务和次序其实已经归类于流程图了。如下面的图：
但是若在一个公司的环境下，你的流程图的受众又非常多的话，采取标准化的符号会带来很多交流上的好处，总之你懂的。
第二部分：流程图的分类？
常见的流程图有业务流程图（Transaction Flow）, 页面流程图（Page
Flow）。
在工作中，作为UED，你可能会发现PD经常谈的是业务流程，而作为交互设计师，我们更多产出的是页面流程图。页面流程图和业务流程图到底有什么关系呢？
先有谁，其次再有谁呢？
先讲个故事：假设你的梦想是开个中高档的全国连锁餐馆，那么首先你想到的应该不是如何去选址，而是将为何要开连锁餐馆这件事情，以及你的定位，核心竞争力想清楚。是快餐，还是点餐，是连锁还是加盟？定位于社区还是繁华商圈？是川菜还是江浙海鲜？是面向中老年还是年轻人？是家庭主题还是动漫主题？竞争对手是谁？需要什么样的投资？可能的风险是什么？这些都想清楚了，问题都有答案了，所谓战略层要清晰了吧。然后假设你现在分析来分析去，与主要投资方决定了一个方向：面向年轻人的时尚动漫茶餐厅，连锁，但是先在杭州开始第一家，选址定位于年轻人约会，扫街的地域，比如风景区，著名商圈，电影院旁…………等等等等，那么接下来呢？
接下来就是想办法让这些实现吧？那么需要做什么事情呢？选址？拉投资？搞装修？选餐饮菜单？雇佣员工？每一步怎么去做，时间点是什么？等等的任务拆解以及计划，就需要到战术层了。
这些事情的执行，总是需要请人的吧？先是核心团队分工去部署各项建设任务，当餐厅开设起来后，就需要组织稳定的运营团队，如服务、卫生、厨房、采购、人事等等，厨房里面还得分工，白案，热菜，冷菜等等吧？每个部门需要设置管理层以及汇报关系吧？所以你的组织结构就诞生了。
那具体每种角色是如何顺畅合作完成日常稳定的以及突发的各项任务呢？比如，当顾客上门时，谁去引导客人入座，谁去点菜，怎么将点菜的讯息迅速传递到厨房，并分发到酒水间、冷菜间、热菜间？并保证客人尽快能够吃到所点的菜？你必须要考虑各种人员的协作流程，优化效率，所以业务流程就出现了。
人肉运营了一段时间，没有借助任何点餐系统，你发现也还可以。客人点菜时，服务员手抄写下客人的要求，因为有复印纸，所以服务员能够将副本送入厨房，同时写下餐桌号码。厨房规模较小，负责分配任务的员工看下菜单，分别往冷菜处的黑板上写下需要他们处理的，以及跑到热菜区的黑板上写下待处理的菜品，以及去酒水间报下品名即可。可是随着经营的扩大，以上的人肉方式出现了很多问题，首先，手抄效率太低，顾客频繁换菜，响应来不及，手抄出错，导致经常报错菜。厨房很混乱，不得不多招了几个人专门跑堂。而一旦顾客要加菜，撤菜就更麻烦了，需要找出他们当时点的菜，再进行人工的批注和修改，同时要修改厨房后端的各个黑板……
所以你们想要开发一套智能系统，取代很多人肉工作，你们请了系统开发团队，他们经过评估，判断从点菜开始，一直到传菜都可以用系统解决。手持终端，能够快速传递顾客点菜需求到打印机，打印系统能够根据顾客点菜的类型进行自动的分单打印，所以热菜间看到自己的热菜菜单，冷菜间看到自己的冷菜菜单，而酒水间看到酒店菜单。当他们准备完毕后，送出，传菜员可以根据菜名与打印出来的单据进行传菜并根据顾客的点菜小票进行核对。这套系统同时必须配备结算系统，将最终确认掉的菜单及消费价格传递到结算前台，收银员能够快速进行操作。
这套系统最终是需要展现出来的，那么手持终端的界面如何设计？服务员能够用更少的点击完成一个菜的点餐吗？结算中心的界面如何设计？
通过以上的故事，是不是更明白从战略、战术、业务流程图到页面流程图的关系了？总结下：
先是有一个业务需求和业务目标，也即我们的愿景是什么？（战略）
然后就诞生了我们需要分解出什么样的任务，如何执行战术？（战术）
然后就诞生了需要架构什么部门，岗位去分工协作？（组织架构）
然后就诞生了不同的部门在协作完成某件任务时的业务流程？（业务流程）
业务流程基本稳定后，往往会考虑优化效率，所以会诞生出系统来支持流程，减少人肉环节，促进数据采集（系统愿景）
为了设计这个系统，PD需要思考什么功能能够取代某个环节的人肉工作（功能需求，系统流程）
不管是怎么样的功能最终都会以界面的方式呈现，设计师们会关注用户在系统里的任务流，行为路径，让用户完成任务更加高效愉悦。（页面流程）
当然，除了业务流程，系统流程，页面流程，还有数据流程被人关注。
我们平时工作中，还会经常听人谈到泳道图啊，任务流程图啊等等概念，究竟是神马关系呢？
图5：流程图的分类
本文着重于上述流程中的“业务流程图”——并会分享如何绘制泳道图——也即是PD们最多使用，技术们最多参考，UED们最多看到的流程图。
本来在第四部分会对泳道图的图示以及绘制方法、原则做更详细的说明，但是看目前的篇幅情况，预计会放到下篇，所以先在这里简单说明下吧。
在工作中，我们经常能够看到两种业务流程图，从表现形式来看，一种很好区分，俗称为“泳道图”的它，在样子上也确实像个泳道，可以有横向的泳道，也会有纵向的泳道。泳道图在某些文档里会被称为“以活动为单位的流程图”，浮在泳道中的都是一个个活动。
另外一种类型是以部门和岗位为单位的流程图，下图中的圆形就代表一个个部门或岗位。矩形代表活动。这种流程图关注事情如何完成的逻辑，但是在体现各个部门的责任上比较弱。如果是某个岗位的人来看，很难像泳道图那样一眼就能看到自己部门的职责和任务。所以现在用得比较少。
再回过头来说泳道图，泳道图有几个关键点：两大维度，活动流转，流程要素。我们会在以后详解。
第三部分：为什么需要业务流程图？
流程图可以提供一种简单扼要的“缩略俯瞰图”，帮助观众快速了解业务如何运转。它包含了几个关键词：谁，什么时候，在什么条件下，做了什么事情，输入什么，输出什么，输出给谁……
与系统流程不同，业务流程更关注于业务本身如何运作，讲的是业务故事，包含的是业务规则。而系统流程则是满足业务流程，实现部分流程或全部流程的信息化和系统化。
所以业务流程是所有环节的前置条件——软件需求分析，信息系统建设也会先进行业务流程的梳理。
下面表现了业务流程图是如何在三个主要场景中发挥作用的：
1. 员工培训
图6：流程图的应用场景之一：培训
在此场景中：流程图能够提供一种快速了解业务如何运作的视图，通过业务流程图，新员工能够快速明白业务的最终目标是什么，中有哪些角色在参与以及他们的职责，以及彼此之间的联接。
除了培训新员工，在员工轮岗、调职场景中，员工也需要业务流程图参考，明白新的工作内容如何开展，以及自己所处的位置，自己的上游是谁，下游是谁，自己需要交付的工作内容是什么。
2：流程优化与重组
图7：流程图的应用场景之二：流程优化
业务流程重组（Business Process Reengineering）的存在可以明确反驳：存在即合理。事实上，存在的业务流程并未是合理的，有可能是参与的多个角色习惯了某种做法，有可能是变革尚未影响到末端的操作，也有可能缺乏对于运行中的业务流程问题的洞察以及强有力的变革推动——因为要推动业务流程变革，不是某个部门的事情，而是需要流程中各个部门的通力配合。
更多时候，业务流程优化是自上而下的，但是老板们未必对实际运作的业务流程那么心知肚明，业务流程图能够很好去表现这个“运作模型”。通过看业务流程图，找关键节点的人访问，能够直接切入：为什么要这么做，为什么不这么做？从而探索出更深层次的问题，而不是问：你们现在怎么做？
通过调研，分析业务流程图，引入更多角色，能够分析出目前业务流程的问题：缺失，重复，风险，效率等等。从而制定相应的优化方案。
3：信息化的基础/p>
图8：流程图的应用场景之三：信息化基础
正如上文所述的餐馆梦想的案例，信息系统的一项任务就是解放员工的手脚，取代一些重复的人力劳动工作。系统上了之后，不是说业务流程不需要而是经过了一些调整，其中某个参与者变成了系统，或手持设备，或打印机而已。
那么在做系统的功能设计和系统流程设计时，是不是必须先要了解目前业务是如何运作的呢？从而更好分析分析，更好说明系统在什么环节取代了什么类型的人肉工作？
所以我们看到的PRD往往也会先以业务流程图开始说明，而叙述一个系统建设的好处时，也可以用以前的业务流程与系统上了之后的业务流程进行对比。根据分析，将愿景中的新的业务流程图背后需要系统的功能点撰写清楚。
第四部分：如何绘制业务流程图？
首先绘制业务流程图本身有没有流程？一定是有的。在软件工程学里听说一句话叫：万物皆对象。那么在流程学里，万事皆流程。吃饭难道没流程吗？就吃饭的动作而言，就有流程：拿筷子——夹菜——入口——咀嚼——吞咽。
有不少同学在这一部份很快想会问一个问题：Heidi，请介绍画流程图的工具吧？
我个人是工具派，从不否认人工欲善其事，必先利其器的道理。好的工具本身就是一名好的老师，除了技能，也能够教会我们一些理论与理念，这些理念也是“器”中很重要的一部分。其次才是具体的工具应用技能。所以我并不建议直接跳转到工具应用。对于初学者而言，笔与纸永远是最好的入门工具，因为你无需和任何一个陌生的软件较劲。
那么，绘制业务流程图有没有可遵循的流程呢？我建议可以从下面4步着手。
1. 调研
如何快速了解业务运作真相？有没有调研的技巧放送？
2. 梳理与呈现
能否快速将调研得到的文字和问题，快速转化为业务流程图？
业务流程图的标准图示是什么？
怎么评价一个业务流程图的好与坏？
3. 评审与确认——能否真正让业务流程图反映现实中的业务？
4. 归档维护——流程不断变更，业务流程图如何快速响应？
这些将会在下篇《业务流程图的绘制流程分享(二)》详解。
第五部分：绘制工具？
如果不搞工具研讨会的话，这部分比较简单.
Windows: 线下工具大家常用的就是下面三个：
小的流程图用用PPT就够了，完了就导出图片或截图。交互设计师们因为常用axure绘制线框图，所以也不必为了流程图去学习新的工具，完全可以用axure的flow控件完成简单的业务流程图的制作。而PD们则常用微软的visio。
业务流程图绘制流程分享(二)
业务流程图的表达的6个关键问题
接上篇《业务流程图绘制流程分享(一)》，本篇将对上篇中间的第四部分——如何绘制业务流程图展开更多讨论。
本来写完上篇，我发现没有太多必要单纯讨论这一部分内容，因为对于很多人来讲，缺的不是具体的做法，而是做这件事情的意义以及目标性的明确。一旦对这件事情的意义和目标有深刻认同，那自然会产生较大的动力去研究How这个层次的所需方法和技能。时间管理也如此，很多时间管理技巧牛逼的人未必能够把时间管理做到位，因为内心克服不了强大的拖延症，而克服拖延很多时候是一个心理问题而不是技巧问题……咳咳，这不是在说我自己吗？
话又扯远了，扯扯扯回来啊。那么为何还专门狗尾续貂（恩，原文也不见得是貂，成语有限，暂时凑合吧），又来这么一篇How的枯燥乏味的文章呢？因为在上篇文章后，Heidi确实在邮件里收到一些邮件，询问业务流程图的具体操作指南——这东西很好，这东西很有用，但是似乎上篇都是讲的“真实的道理”，但是具体怎么做呢？我应该注意什么呢？……
所以，干脆也分享一下吧。但在书写过程中，我发现一个大难题在于收集整理出更生动易懂又典型的案例。不能使用工作中的实际案例，但是短时间又难以找到合适的。所以本人对这部分不太满意。也希望各位读到本文的人，能够提供更多案例分享。
1. 业务流程图的“烹饪三部曲”
在绘制业务流程图前，思考如何精美，如何交互，使用什么工具，都不应该是重点。
真正重点的是将业务流程图的关键要素给搜集一番。请试图回答清楚以下几个问题，否则不要开始绘制流程图：
- 整个流程的起始点是什么？整个流程的终结点是什么？
- 在整个流程中，涉及到的角色都是谁？
- 在整个流程中，都需要做什么事情？（可是是一个会议，可以是一个任务）
- 这些会议和任务是可选还是必选的？
- 分别产出什么文档？
这有点像一个头脑风暴，能够帮助你将所需用到的原材料获取到，有了这些“米”和“水”，那就不愁去如何烹饪了。
在项目管理中，上个月，我们也试图给去规范化一个数据产品的设计开发流程。
这是一个数据产品的项目，而我们都不是对此很有经验的人。所以我们召集到所有相关的角色，组织了一次头脑风暴及卡片分类法的混合式应用。
- 让大家头脑风暴出自己认为在项目里必须的节点，如“需求调研”，“需求分析”，“kick off会议”，“PRD撰写及确认”，“数据评估”，“技术架构”，“DEMO绘制”，“指标算法定义”，等等。
- 在头脑风暴过程中，主持人将这些节点都写到白板上，等没有新的节点诞生后，大家一起对节点进行合并归类。之后呢？
- 将这些剩余下来的真正有价值的节点，撰写到即时贴上，开始进行排序。在排序过程中，可以由一个人先主导，他会按照自己的理解，将各个节点放到按角色排布的泳道中，并设计好先后的顺序。在他进行的过程中，其他人不断进行提问：“这项任务开始前，需要什么样的条件？”“这个任务是必须的吗？”然后一起调整先后顺序。直到最终没有人有任何重大的异议。
- 之后拍照留念。
然后可整理成电子文档，如project或者excel版本（使用excel做项目管理？）
但是，业务流程图和上述项目中的流程不太相同的是：
项目中的各种活动节点有更宽泛的可配置性，任务A和任务B是否并行，还是串行，如果项目组成员达成共识，是可以调整，并且多做尝试的。所以可以用集思广益的做法去头脑风暴出一个暂定比较合理的流程。而业务流程图的梳理，有两种:
- 一种是基于现实发生的业务流程如实反映。这显然不是你一个团队能够YY的结果。更需要走到现实环境中，去调研，去梳理，去确认。
- 另一种是基于流程优化的方案，当你已经掌握了目前的流程现实如何运作时，基于分析，讨论，能够判断出流程中不合理的地方，给出一个更完善或者有更效率、成本更低的新的流程出来——或许你要求增加一个部门，或者你需要删减一个环节，或者中间的若干步使用新开发的系统去取代。
总之，大多数时候，你要想做第二种流程图，必然要先将第一种给梳理出来。所以，第一种如实反映的流程图是躲不过的。既然如此，基于YY或者头脑风暴是不现实的。我们需要走到前线去，掌握现实中业务是如何运作的。而且很多时候，越细节越好。
那怎么做呢？基于有限的知识与经验，我可以给如下建议：
1. 调研——2.梳理呈现——3.评审确认三部曲，如图所示：
2. 调研——问正确的问题，多问问题，多问几个人
除了在本部分开始的那几个问题要顾及到，其实调研过程解决的仍然是who，what，why，how，以及where的问题：谁，在什么情况下，做了什么事情，这个事情需要什么前置条件，又输出了什么，这个事情在哪里完成的？搞明白这几个问题，我们的调研就可以圆满完成了。
流程图的表现，要回答这几个问题：
- Who——谁？部门，角色，岗位
- What——什么事情？
- Where——在哪里做的？在我梳理的业务流程图上，where更多表示是文档还是各种系统，用来表示信息化的程度。比如当我们梳理中发现，有一项登记，是用excel而不是业务系统来进行的，那么在这里的where就可以表示为：excel文档。
- Document——那产生的这份文档叫什么名字？也写出来，代表有文件的传递，而以后要进行信息化的话，此份人肉文档也是需要被消除而被系统取代的。（相反，如果这项工作是在某个系统里操作的，where就可以写成“人事系统”，文档可以继续存在，即该系统中的表单名称：“员工登记表单”）
- Condition——条件。在这种条件下，下一个活动还能够继续，即用逻辑链接线的方式来表示一项活动的输入和输出，指向某个活动的箭头就表示此活动的前置输入条件。
- Dicision——决策。有些活动会产生一个条件判断，根据不同的判断结果从而走不同的分支流程。比如输入员工信息的时候，可以根据员工之前是否就职过，选择不同的流程，对于已经就职过的，选用之前的工号而不用生成新的工号。
举个案例（如果不太恰当，请意会）。假设你受命要调研两家餐饮店的业务流程，目的是给他们提供性价比最高的点餐系统。
在调研中：
- 你首先可以要求精通业务流程的人给你系统讲解一遍。
- 调研具体操作的人，来验证他给你讲解的是否全面和偏差。
- 实地观察和记录（花点时间走遍业务流程）
三种方式相互结合使用。第一种方法可以让你首先建立一个系统观，了解大体枝干，但是很难切入到可能会出现问题的细节。第二种方法太依赖于问题的质量以及问问题的场景。有很多结论的不正确其实是因为问错了人或者问问题的方法不对。那么就需要借助第三种，在观察中再进行验证。
比如，你现在找到了一个厨师：
你主要负责做什么菜系？
热菜。
那菜单都是谁给你的？
我们的服务员。
她都怎么提供给你？
她负责客人点菜后，然后手写一个单子，给我放到窗口上。
单子上都会写什么？
桌号，菜名等
如何客人点的是冷菜呢？
恩，有复印本，直接拿一份给冷菜间。
那你怎么开始工作呢？从洗菜到切菜，一直烹饪都是一个人吗？
哦，不，我只负责烹饪。当接到菜单后，首先我的助理会进行择菜，刀工进行切菜，这样如果有几个菜就完全可以并行。
当你们做好后呢？
放到窗口，按铃，喊桌号和菜名，传菜员就会传菜。
……
在这些问题中，就涉及到了“分单”，“切菜”，“择菜”，"烹饪"，“传菜”，“上菜”几个活动，也涉及到了“服务员”，“厨师”，“助理”，“刀工”，“传菜员”几个角色。几个活动的次序也比较清楚了。
而另一家餐饮店的业务流程却是不一样的，你同样抓住一个厨师进行询问：
要做什么菜，菜单是哪里来的？
打印出来的。
所有菜都会在这里打印吗？
哦，只有热菜在这里打印出来，冷菜、酒水就会在冷菜间和酒水间打印出来。
打印机是谁在操作的？
没人操作，它会自动打印不同的单子给我们。
……下面的问题，可能厨师就不了解了，要问点菜员了。
请问你是怎么点菜的？
拿设备啊，客人点菜就按几下，确认就好了。
之后呢？
之后就可以将菜单打印出来。
不同的菜系会在不同的烹饪间打印吗？
是的，我们可以分单打印。是在这中心打印机里完成分单。
然后，你可以继续调研烹饪后的传菜和上菜流程。
3. 梳理并呈现
你的调研和观察使你拥有了“烹饪”所需的原材料。
- 角色：部门、岗位或人
- 活动：做了什么事情
- 次序：做这些事情的次序如何
- 规则：什么情况下到什么事情
还记得我们之前提过的流程图要素吗？回顾下：
接下来的任务是不是很简单，对，就像填空题一样简单。将活动/事件按照一定的规则填到由部门和时间两条维度决定的框框里。
这个阶段是paper work，你需要将调研阶段收集到的原材料用更直观明了的方式呈现出来。从而能够更好进行评审和确认。也为以后的流程评审和优化做准备。
在刚开始，笔和纸的原始搭配仍然是最好的起步工具。你可以暂时忽略掉美观或者可复用的因素。但是当你对要呈现的流程已经有足够的信心时，就可以借助软件工具了。
3.1 复杂流程的分解
不可能将所有的活动都放到一张图里呈现。
“业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。这样一个层次关系符合人们的思维习惯，有利于企业业务模型的建立
企业部门之间的层次关系表。一般来说，我们可以先建立主要业务流程的总体运行过程（其中包括了整个企业的大的战略），然后对其中的每项活动进行细化，落实到各个部门的业务过程，建立相对独立的子业务流程以及为其服务的辅助业务流程。”
——引自《百度百科》 业务流程词条
对于很多新人来讲，业务最难的在于划分业务流程图的层次上。
首先，明确你要梳理的业务流程的范围——用大的粗略的关键节点，讲清楚这个业务流程范围中的故事，就是顶层业务流程图。你的顶层业务流程图是业务全局故事的简单表达，但是请注意这里的业务全局不见得是公司整体的业务全局，而是你界定好的业务范围。比如，下图是餐厅的日常运作流程图，若你界定的业务范围是面向顾客的点餐和结帐流程，那么这就是顶层业务流程图。但是若你界定的是整个餐厅的运作业务流程，那这显然还是一个子集——并没有包含餐厅的采购、供应商管理、一级库存管理等工作。
其次，先从顶层的业务流程分解开始，由粗至细。顶层业务流程图的梳理原则：
- 界定范围内的业务全局故事。
- 包含该范围内的关键节点。并且，当被质疑说某某环节怎么不存在时，自己要清楚它在下一层分解中应该被包含在那个关键节点中。比如，赠送10周年优惠券，应该会在结帐节点分解中出现。而打印分单，会在点菜节点中分解。而准备儿童座椅应该是接待入座环节。
- 顶层流程图分解出来的关键节点未必都会细化分解下去，生成二级以及三级的流程图。这要看该节点涉及到的“活动”以及“角色”是否复杂。
再看一个案例，对传统生产型企业的进销存主业务流程进行分解。橙色的代表被分解点，已经可以分解为四层。当我们分解到第四层，发现再往下去涉及到的活动和角色都已经很少时，就不必再分解了，而是可以将第四层的关键节点直接作为第三层业务流程的“活动”，而不是子流程图。
当然，这是依赖于你梳理业务流程的目标。如果你偏偏是要对“打样”环节进行剖析优化，则还可以继续分解下去。
这一步的工作会帮你建立出清晰的流程目录结构，如下图所示是摘选于刚完成的一个流程梳理的项目中的目录结构部分。可以看到全图即是顶层关键节点，作为老大，可能只要看这一层就够了。下面则会对顶层做更多细化拆解。
“H3.样品认证”在顶层业务流程图中，仅仅是一个“活动”，而在自己细化的这一个层次中，则会包含详细的子活动一级参与者
3.2 流程图的常用图示
我常用的就是前两行的“活动”，“判断”，“逻辑关系线”，“起始与终止”，以及第二行的“子流程”，和“文件/表单”。如果你不是符号控，我建议这几个就足够了。
其中，“子流程”此图示就是可以帮助你将流程分解得到的子流程能够串联起来，比如，当在"A流程"中涉及到进一步需要分解的"A1.1流程"时，就可以在"A流程"中用子流程符号代表“A1.1”。然后你的读者就会明白要想进一步了解"A1.1"应该参考另外一个流程图。
流程图的常用结构：
给大家看一些案例：
基本上包含大多数图示的流程图：
只用到少数几个图示画的简单流程图（台湾人的文档中称为程序图——不过这里的程序不是指计算机程序，而是process，仅仅是体现任务之间的处理流程，所以使用极简单的符号也不为怪了）：
以上两个流程图案例，从符号的复杂程度上来讲，一个是完整流程图，一个是基本流程图，但是从表现形式来讲，都属于“泳道图”——Swimlane。这也是我们最常用的一种表现形式了。泳道图能够很好体现部门或者角色在流程中的职责以及上下游的协作关系。且流程图本身的标准容易掌握，达成共识也就更加容易。
3.3 泳道图精要
- 大维度：一般泳道图的横向会作为部门或岗位维，当然也有例外，如上述案例中就是横的泳道。而纵向则做为阶段维——时间是从上到下发展的。如果复杂的泳道图，在任务分解上可以在阶段维里做一些划分，比如“采购”，“生产”，“销售”，"配送”等
- 活动流转：活动就像一个游泳员一样，游到不同的泳道中去执行任务。
在上文中的软件推荐部分，我推荐过smartdraw工具，此工具还附带了泳道图的模板，大家比较更快能够上手：
3.4 Do vs Donnot 业务流程图的注意事项！
DO
1. 让涉众参与，不要闭门造车
业务流程图包含了你图上的各个参与角色代表，与他们适时确认事情的原本流程，禁止自己YY。
2. 恰当的层次分解，不要将所有都铺到一张图上
如上所示。
3. 逐渐深入，先抓枝干
切忌胡子眉毛一把抓。
4. 流程一定有开始和结束
切忌交付出来的流程图，让读者还来问你：流程的开始点是什么？用清晰的代表开始和结束的符号来完成第一步和最后一步。
5. 编号，编号，编号
这是让沟通效率更高的优化措施。当你有了编号系统，相当于对你的流程图都赋予了唯一识别身份证号。这比中文名称更有效。比如当我们完成了业务流程图后，负责业务流程规则审核和优化的部门能够清楚在邮件里传达：H5.1流程优化，大家就更明确指的是什么。
DONNOT
- 自己YY应用的环节而不是现实中的环节
- 所有的环节都试图放到一张图上
- 一开始就陷入细节，胡子眉毛一起抓
- 流程很难让人分清楚从哪里开始，到哪里结束
4. 评审及后续行动
验证你是否做到了以上的DO，以及规避了Donnot的做法是什么？
很好办，及时与各位进行评审。将各个涉众都叫到一起，给他们看你梳理出来的成果。
这会发现一些有意思的事情，除了评审你的流程图是否符合现实外，也会评审目前的业务流程是否符合理想。不同的部门和岗位的代表会在这个评审中，确认当前，也会相互提出意见，甚至吵起来，这不失于做流程优化的一个很好的契机。暂且不表了。
|
