如何绘制业务流程图模板.docx

怎样绘制业务步骤图

作者：Heidi格物志，公布于-7-11

图1：用即时贴和白板做简单步骤图
序言：最近一段时间，忙于整理业务步骤图，期间，相关步骤图绘制方法和工具也和内部团体和外部做了心得交流，恰好，个人生活也牵涉在买房，婚礼，户口迁移等步骤中。不知不觉，伴伴随实践和反思，个人所得系统知识趋于完整，今儿天气极好，坐在飘窗一隅，听着间或几声鸟鸣歌唱，偶然瞥一眼窗外遍地绿荫，真真认为是个写点什么日子。所以就整理成文，假如恰好对你有所帮助，那是真真好。
真实整理步骤牵涉到企业未公布计划，不好公开，所以在本文中会借助一个简单案例替换（这个案例呢，也就是计划写本文前30分分钟才想到，如有考虑不周，请各位见谅），不过仅传达概念和方法，倒也足够了。恩，甄環体告一段落，我们开始吧。
本文会包含几块内容：
1. 什么是步骤图？步骤图和其它图表（如线框图，概念图，架构图，用例图）有什么不一样？
2. 为何需要步骤图？
3. 步骤图分类？
4. 怎样绘制步骤图？
5. 步骤图绘制工具
视篇幅情况，会在行文时略加划分为系列，敬请关注并多多交流。
第一部分：什么是步骤图？
1. 定义
了解一个事情，我习惯从它定义开始。至于为何，能够参见我之前博客文章
我们因为厌恶十年教育，厌恶背多种定理和定义，所以我发觉生活中和工作中大家全部很讨厌给一个事情下定义和去参考定义。所以你会发觉大家在一起争吵得不可开交，仔细去听，原来是鸡同鸭讲，根本不在一个频道上。对于一个事情描述，没有一个共同语言，没有所谓术语。有定义很好办，你们共同引用一个定义，发觉定义有问题，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绘制线框图，所以也无须为了步骤图去学习新工具，完全能够用axureflow控件完成简单业务步骤图制作。而PD们则常见微软visio。
业务步骤图绘制步骤分享(二)

业务步骤图表示6个关键问题
接上篇《业务步骤图绘制步骤分享(一)》，本篇将对上篇中间第四部分——怎样绘制业务步骤图展开更多讨论。
原来写完上篇，我发觉没有太多必需单纯讨论这一部分内容，因为对于大家来讲，缺不是具体做法，而是做这件事情意义和目标性明确。一旦对这件事情意义和目标有深刻认同，那自然会产生较大动力去研究How这个层次所需方法和技能。时间管理也如此，很多时间管理技巧牛逼人未必能够把时间管理做到位，因为内心克服不了强大拖延症，而克服拖延很多时候是一个心理问题而不是技巧问题……咳咳，这不是在说我自己吗？
话又扯远了，扯扯扯回来啊。那么为何还专门狗尾续貂（恩，原文也不见得是貂，成语有限，临时凑合吧），又来这么一篇How枯燥乏味文章呢？因为在上篇文章后，Heidi确实在邮件里收到部分邮件，问询业务步骤图具体操作指南——这东西很好，这东西很有用，不过似乎上篇全部是讲“真实道理”，不过具体怎么做呢？我应该注意什么呢？……
所以，干脆也分享一下吧。但在书写过程中，我发觉一个大难题在于搜集整理出更生动易懂又经典案例。不能使用工作中实际案例，不过短时间又难以找到适宜。所以本人对这部分不太满意。也期望各位读到本文人，能够提供更多案例分享。
1. 业务步骤图“烹饪三部曲”
在绘制业务步骤图前，思索怎样精美，怎样交互，使用什么工具，全部不应该是关键。
真正关键是将业务步骤图关键要素给搜集一番。请试图回复清楚以下多个问题，不然不要开始绘制步骤图：
· 整个步骤起始点是什么？整个步骤终止点是什么？
· 在整个步骤中，包含到角色全部是谁？
· 在整个步骤中，全部需要做什么事情？（可是是一个会议，能够是一个任务）
· 这些会议和任务是可选还是必选？
· 分别产出什么文档？
这有点像一个头脑风暴，能够帮助你将所需用到原材料获取到，有了这些“米”和“水”，那就不愁去怎样烹饪了。
在项目管理中，上个月，我们也试图给去规范化一个数据产品设计开发步骤。
这是一个数据产品项目，而我们全部不是对此很有经验人。所以我们召集到全部相关角色，组织了一次头脑风暴及卡片分类法混合式应用。
1. 让大家头脑风暴出自己认为在项目里必需节点，如“需求调研”，“需求分析”，“kick off会议”，“PRD撰写及确定”，“数据评定”，“技术架构”，“DEMO绘制”，“指标算法定义”，等等。
2. 在头脑风暴过程中，主持人将这些节点全部写到白板上，等没有新节点诞生后，大家一起对节点进行合并归类。以后呢？
3. 将这些剩下下来真正有价值节点，撰写到即时贴上，开始进行排序。在排序过程中，能够由一个人先主导，她会根据自己了解，将各个节点放到按角色排布泳道中，并设计好前后次序。在她进行过程中，其它人不停进行提问：“这项任务开始前，需要什么样条件？”“这个任务是必需吗？”然后一起调整前后次序。直到最终没有些人有任何重大异议。
4. 以后拍照留念。

然后可整理成电子文档，如project或excel版本（使用excel做项目管理？）

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

2. 调研——问正确问题，多问问题，多问多个人
除了在本部分开始那多个问题要顾及到，其实调研过程处理仍然是who，what，why，how，和where问题：谁，在什么情况下，做了什么事情，这个事情需要什么前置条件，又输出了什么，这个事情在哪里完成？搞明白这多个问题，我们调研就能够圆满完成了。
步骤图表现，要回复这多个问题：
1. Who——谁？部门，角色，岗位
2. What——什么事情？
3. Where——在哪里做？在我梳理业务步骤图上，where更多表示是文档还是多种系统，用来表示信息化程度。比如当我们梳理中发觉，有一项登记，是用excel而不是业务系统来进行，那么在这里where就能够表示为：excel文档。
4. Document——那产生这份文档叫什么名字？也写出来，代表有文件传输，而以后要进行信息化话，此份人肉文档也是需要被消除而被系统替换。（相反，假如这项工作是在某个系统里操作，where就能够写成“人事系统”，文档能够继续存在，即该系统中表单名称：“职员记录表单”）
5. Condition——条件。在这种条件下，下一个活动还能够继续，即用逻辑链接线方法来表示一项活动输入和输出，指向某个活动箭头就表示此活动前置输入条件。
6. Dicision——决议。有些活动会产生一个条件判定，依据不一样判定结果从而走不一样分支步骤。比如输入职员信息时候，能够依据职员之前是否就职过，选择不一样步骤，对于已经就职过，选择之前工号而不用生成新工号。

举个案例（假如不太合适，请意会）。假设你受命要调研两家餐饮店业务步骤，目标是给她们提供性价比最高点餐系统。
在调研中：
1. 你首先能够要求精通业务步骤人给你系统讲解一遍。
2. 调研具体操作人，来验证她给你讲解是否全方面和偏差。
3. 实地观察和统计（花点时间走遍业务步骤）
三种方法相互结合使用。第一个方法能够让你首先建立一个系统观，了解大致枝干，不过极难切入到可能会出现问题细节。第二种方法太依靠于问题质量和问问题场景。有很多结论不正确其实是因为问错了人或问问题方法不对。那么就需要借助第三种，在观察中再进行验证。
比如，你现在找到了一个厨师：
你关键负责做什么菜系？
热菜。
那菜单全部是谁给你？
我们服务员。
她全部怎么提供给你？
她负责客人点菜后，然后手写一个单子，给我放到窗口上。
单子上全部会写什么？
桌号，菜名等
怎样客人点是冷菜呢？
恩，有复印本，直接拿一份给冷菜间。
那你怎么开始工作呢？从洗菜到切菜，一直烹饪全部是一个人吗？
哦，不，我只负责烹饪。当接到菜单后，首先我助理会进行择菜，刀工进行切菜，这么假如有多个菜就完全能够并行。
当你们做好后呢？
放到窗口，按铃，喊桌号和菜名，传菜员就会传菜。
……
在这些问题中，就包含到了“分单”，“切菜”，“择菜”，"烹饪"，“传菜”，“上菜”多个活动，也包含到了“服务员”，“厨师”，“助理”，“刀工”，“传菜员”多个角色。多个活动次序也比较清楚了。
而另一家餐饮店业务步骤却是不一样，你一样抓住一个厨师进行问询：
要做什么菜，菜单是哪里来？
打印出来。
全部菜全部会在这里打印吗？
哦，只有热菜在这里打印出来，冷菜、酒水就会在冷菜间和酒水间打印出来。
打印机是谁在操作？
没人操作，它会自动打印不一样单子给我们。
……下面问题，可能厨师就不了解了，要问点菜员了。
请问你是怎么点菜？
拿设备啊，客人点菜就按几下，确定就好了。
以后呢？
以后就能够将菜单打印出来。
不一样菜系会在不一样烹饪间打印吗？
是，我们能够分单打印。是在这中心打印机里完成份单。
然后，你能够继续调研烹饪后传菜和上菜步骤。
3. 梳理并展现
你调研和观察使你拥有了“烹饪”所需原材料。
· 角色：部门、岗位或人
· 活动：做了什么事情
· 次序：做这些事情次序怎样
· 规则：什么情况下到什么事情
还记得我们之前提过步骤图要素吗？回顾下：

接下来任务是不是很简单，对，就像填空题一样简单。将活动/事件根据一定规则填到由部门和时间两条维度决定框框里。
这个阶段是paper work，你需要将调研阶段搜集到原材料用更直观明了方法展现出来。从而能够愈加好进行评审和确定。也为以后步骤评审和优化做准备。
在刚开始，笔和纸原始搭配仍然是最好起步工具。你能够临时忽略掉美观或可复用原因。不过当你对要展现步骤已经有足够信心时，就能够借助软件工具了。
3.1 复杂步骤分解
不可能将全部活动全部放到一张图里展现。
“业务步骤是有层次性，这种层次表现在由上至下、由整体到部分、由宏观到微观、由抽象到具体逻辑关系。这么一个层次关系符合大家思维习惯，有利于企业业务模型建立 企业部门之间层次关系表。通常来说，我们能够先建立关键业务步骤总体运行过程（其中包含了整个企业大战略），然后对其中每项活动进行细化，落实到各个部门业务过程，建立相对独立子业务步骤和为其服务辅助业务步骤。”
——引自《baidu百科》 业务步骤词条
对于很多新人来讲，业务最难在于划分业务步骤图层次上。
首先，明确你要梳理业务步骤范围——用大粗略关键节点，讲清楚这个业务步骤范围中小说，就是顶层业务步骤图。你顶层业务步骤图是业务全局小说简单表示，不过请注意这里业务全局不见得是企业整体业务全局，而是你界定好业务范围。比如，下图是餐厅日常运作步骤图，若你界定业务范围是面向用户点餐和结帐步骤，那么这就是顶层业务步骤图。不过若你界定是整个餐厅运作业务步骤，那这显然还是一个子集——并没有包含餐厅采购、供给商管理、一级库存管理等工作。

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

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

3.2 步骤图常见图示

我常见就是前两行“活动”，“判定”，“逻辑关系线”，“起始和终止”，和第二行“子步骤”，和“文件/表单”。假如你不是符号控，我提议这多个就足够了。
其中，“子步骤”此图示就是能够帮助你将步骤分解得到子步骤能够串联起来，比如，当在"A步骤"中包含到深入需要分解"A1.1步骤"时，就能够在"A步骤"中用子步骤符号代表“A1.1”。然后你读者就会明白要想深入了解"A1.1"应该参考另外一个步骤图。
步骤图常见结构：

给大家看部分案例：
基础上包含大多数图示步骤图：

文档地址：http://www.ais.npic.edu.tw/ais/971%20materials/DfdSfPm_0724.pdf
只用到少数多个图示画简单步骤图（台湾人文档中称为程序图——不过这里程序不是指计算机程序，而是process，仅仅是表现任务之间处理步骤，所以使用极简单符号也不为怪了）：

以上两个步骤图案例，从符号复杂程度上来讲，一个是完整步骤图，一个是基础步骤图，不过从表现形式来讲，全部属于“泳道图”——Swimlane。这也是我们最常见一个表现形式了。泳道图能够很好表现部门或角色在步骤中职责和上下游协作关系。且步骤图本身标准轻易掌握，达成共识也就愈加轻易。
3.3 泳道图精要

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

3.4 Do vs Donnot 业务步骤图注意事项！
DO
1. 让涉众参与，不要闭门造车
业务步骤图包含了你图上各个参与角色代表，和她们适时确定事情原本步骤，严禁自己YY。
2. 合适层次分解，不要将全部全部铺到一张图上
如上所表示。
3. 逐步深入，先抓枝干
切忌胡子眉毛一把抓。
4. 步骤一定有开始和结束
切忌交付出来步骤图，让读者还来问你：步骤开始点是什么？用清楚代表开始和结束符号来完成第一步和最终一步。
5. 编号，编号，编号
这是让沟通效率更高优化方法。当你有了编号系统，相当于对你步骤图全部给予了唯一识别身份证号。这比汉字名称更有效。比如当我们完成了业务步骤图后，负责业务步骤规则审核和优化部门能够清楚在邮件里传达：H5.1步骤优化，大家就更明确指是什么。
DONNOT
1. 自己YY应用步骤而不是现实中步骤
2. 全部步骤全部试图放到一张图上
3. 一开始就陷入细节，胡子眉毛一起抓
4. 步骤极难让人分清楚从哪里开始，到哪里结束
4. 评审及后续行动
验证你是否做到了以上DO，和规避了Donnot做法是什么？
很好办，立即和各位进行评审。将各个涉众全部叫到一起，给她们看你梳理出来结果。
这会发觉部分有意思事情，除了评审你步骤图是否符合现实外，也会评审现在业务步骤是否符合理想。不一样部门和岗位代表会在这个评审中，确定目前，也会相互提出意见，甚至吵起来，这不失于做步骤优化一个很好契机。暂且不表了。