流程图绘制经验分享

评审及后续行动
• 验证是否做到了以上的DO，以及规避了Do not • 不同部门和不同岗位间必然的积极的争吵， 益于流程优化
梳理呈现
• • • • • • • 调研后获得的输出： 角色：部门、岗位或人 活动：做了什么事情 次序：做这些事情的次序如何 规则：什么情况下到什么事情 六要素回顾 Paper work
复杂流程的分解
• 不可能将所有的活动都放到一张图里呈现。 • “业务流程是有层次性的，这种层次体现在由上 至下、由整体到部分、由宏观到微观、由抽象到 具体的逻辑关系。这样一个层次关系符合人们的 思维习惯，有利于企业业务模型的建立 企业部门 之间的层次关系表。一般来说，我们可以先建立 主要业务流程的总体运行过程（其中包括了整个 企业的大的战略），然后对其中的每项活动进行 细化，落实到各个部门的业务过程，建立相对独 立的子业务流程以及为其服务的辅助业务流程。”
泳道图
为什么需要业务流程图
• 流程图可以提供一种简单扼要的“缩略俯瞰图”，帮助观 众快速了解业务如何运转。它包含了几个关键词：谁，什 么时候，在什么条件下，做了什么事情，输入什么，输出 什么，输出给谁……
• 与系统流程不同，业务流程更关注于业务本身如何运作， 讲的是业务故事，包含的是业务规则。而系统流程则是满 足业务流程，实现部分流程或全部流程的信息化和系统化。
如何绘制业务流程图
• 做流程图本身也有流程。 • 调研：如何快速的了解业务运作真相。 • 梳理与呈现：能否快速将调研得到的文字和问题， 快速转化为业务流程图？业务流程图的标准图示 是什么？怎么评价一个业务流程图的好与坏？ • 评审与确认——能否真正让业务流程图反映现实 中的业务？ • 归档维护——流程不断变更，业务流程图如何快 速响应？
BPC三部曲
调研
• • • • 问正确的问题，多问问题，多问不同的人 1.Who——谁？部门，角色，岗位 2.What——什么事情？ 3.Where——在哪里做的？在梳理的业务流程图上，where更多表示 是文档还是各种系统，用来表示信息化的程度。比如当我们梳理中发 现，有一项登记，是用excel而不是业务系统来进行的，那么在这里 的where就可以表示为：excel文档。 • 4.Document——那产生的这份文档叫什么名字？代表有文件的传递， 而以后要进行信息化的话，此份人肉文档也是需要被消除而被系统取 代的。（相反，如果这项工作是在某个系统里操作的，where就可以 写成“人事系统”，文档可以继续存在，即该系统中的表单名称： “员工登记表单”） • 5.Condition——条件。在这种条件下，下一个活动还能够继续，即用 逻辑链接线的方式来表示一项活动的输入和输出，指向某个活动的箭 头就表示此活动的前置输入条件。 • 6.Dicision——决策。有些活动会产生一个条件判断，根据不同的判 断结果从而走不同的分支流程。
关于流程图的标准化
• 关于流程图的标准化，并不是强制的，事实上，我们见过很多种类的 流程图，只要能够传递明白任务和次序其实已经归类于流程图了。如 下面的图:
流程图的分类
• 常见的流程图有业务流程图，系统流程图， 数据流程图，页面流程图。
区别
• • • • • • • • 先是有一个业务需求和业务目标，也即我们的愿景是什么？（战略） 然后就诞生了我们需要分解出什么样的任务，如何执行战术？（战术） 然后就诞生了需要架构什么部门，岗位去分工协作？（组织架构） 然后就诞生了不同的部门在协作完成某件任务时的业务流程？（业务 流程） 业务流程基本稳定后，往往会考虑优化效率，所以会诞生出系统来支 持流程，减少人肉环节，促进数据采集（系统愿景） 为了设计这个系统，需要思考什么功能能够取代某个环节的人肉工作 （功能需求，系统流程） 系统开发的过程中需要考虑各种数据的读写与传递。(数据流程) 不管是怎么样的功能最终都会以界面的方式呈现，设计师们会关注用 户在系统里的任务流，行为路径，让用户完成任务更加高效愉悦。 （页面流程）
流程图绘制经验分享
• • • • 什么是流程图？ 流程图的分类？ 为什么我们需要流程图？ 如何绘制流程图？
什么是流程图？
• 流程：是指特定主体为了满足特定需求而进行的 有特定逻辑关系的一系列操作过程，流程是自然 而然就存在的。但是它可以不规范，可以不固定， 可以充满问题。所以就会造成看似没有流程。 • 图：是将基本固化有一定规律的流程进行显性化 和书面化，从而有利于传播与沉淀、流程重组参 考 • 从定义可以看出，只要有事情和任务，流程就会 有，但是并不是所有的流程都适合用流程图的方 式去表现，适合用流程图去表现的流程是一定程 度固定的有规律可循的。
• 1. 界定范围内的业务全局故事。 • 2. 包含该范围内的关键节点。并且，当被质疑说某某环节怎么不存在 时，自己要清楚它在下一层分解中应该被包含在那个关键节点中。比 如，赠送10周年优惠券，应该会在结帐节点分解中出现。而打印分单， 会在点菜节点中分解。而准备儿童座椅应该是接待入座环节。 • 3. 顶层流程图分解出来的关键节点未必都会细化分解下去，生成二级 以及三级的流程图。这要看该节点涉及到的“活动”以及“角色”是 否复杂
• 分解到第四层，发现再往下去涉及到的活动和角色都已经 很少时，就不必再分解了，而是可以将第四层的关键节点 直接作为第三层业务流程的“活动”，而不是子流程图。 • 这是依赖于梳理业务流程的目标。如果偏偏是要对“打样” 环节进行剖析优化，则还可以继续分解下去。
流程图常用图示
流程图常用结构
Do vs Don’t 注意事项
ห้องสมุดไป่ตู้
开始做流程图的前提：
• 能够完整且清晰的回答如下所有问题： • 整个流程的起始点是什么？整个流程的终 结点是什么？ • 在整个流程中，涉及到的角色都是谁？ • 在整个流程中，都需要做什么事情？（可 是是一个会议，可以是一个任务） • 这些会议和任务是可选还是必选的？ • 分别产出什么文档？
• PMP中的各种活动节点有更宽泛的可配置性，任 务A和任务B是否并行，还是串行，如果项目组成 员达成共识，是可以调整并且多做尝试的。所以 可以用集思广益的做法去头脑风暴出一个暂定比 较合理的流程。而在BPC中，有两种情况: • 一种是基于现实发生的业务流程如实反映。这显 然不是一个BPC团队能够YY的结果。更需要走到 作业环境中，去调研，梳理和确认。 • 另一种是基于流程优化的方案，当你已经掌握了 目前的流程如何运作时，基于分析，讨论，能够 判断出流程中不合理的地方，给出一个更完善或 者有更效率、成本更低的新的流程出来——或许 你要求增加一个部门，或者你需要删减一个环节， 或者中间的若干步使用新开发的系统去取代。
•
•
•
业务流程重组（Business Process Reengineering）：存在的业务流程并未是合理的， 有可能是参与的多个角色习惯了某种做法，有可能是变革尚未影响到末端的操作，也 有可能缺乏对于运行中的业务流程问题的洞察以及强有力的变革推动——因为要推动 业务流程变革，不是某个部门的事情，而是需要流程中各个部门的通力配合。 更多时候，业务流程优化是自上而下的，但是boss未必对实际运作的业务流程那么心 知肚明，业务流程图能够很好去表现这个“运作模型”。通过看业务流程图，找关键 节点的人访问，能够直接切入：为什么要这么做，为什么不这么做？从而探索出更深 层次的问题，而不是问：你们现在在做什么？ 通过调研，分析业务流程图，引入更多角色，能够分析出目前业务流程的问题：缺失， 重复，风险，效率等等。从而制定相应的优化方案。
• • • • • • • • • • • DO 1. 涉众参与，不要闭门造车，禁止YY 2. 恰当的层次分解，不要将所有都铺到一张图上 3. 逐渐深入，先抓枝干，切忌胡子眉毛一把抓 4. 流程一定有开始和结束符号 5. 编号 DO NOT 1. 自己YY应用的环节而不是现实中的环节 2. 所有的环节都试图放到一张图上 3. 一开始就陷入细节，胡子眉毛一起抓 4. 流程很难让人分清楚从哪里开始，到哪里结束
流程图的六大要件
• 参与者(who)：谁在这个流程中？可以是系统，可以是个打印机，更 多的指什么角色——一般是有某种工种的人。比如客服同时有小A和 小B两人，但是若他们的工作性质完全一样，那么在流程图里只需要 写一个客服角色就可以了。 • 活动(what)：做了什么事，比如策划，设计，礼包配置等活动。 • 次序(when)：这些事情发生的前后顺序如何，哪个任务是其他任务的 前置条件？比如客人不下订单，就不会产生订单处理的活动。 • 输入(input)：每项活动开始取决于什么样的输入物或数据，比如物流 部门开始备货打包时，需要拿到具体的订单信息。 • 输出(output)：每项活动结束后，会输入什么样的文档或数据传递给 下一方，比如财务部设置好礼品卡兑换号段及相应金额后会传递给技 术部作为开卡的依据。 • 标准化(standard)：采用一套标准化的符号用以传递你的流程图，从 而使受众更快明白。
• 所以业务流程是所有环节的前置条件——软件需求分析， 信息系统建设也会先进行业务流程的梳理。
• 流程图能够提供一种快速了解业务如何运作的视图，通过业务流程图， 新员工能够快速明白业务的最终目标是什么，中有哪些角色在参与以 及他们的职责，以及彼此之间的联接。 • 除了培训新员工，在员工轮岗、调职场景中，员工也需要业务流程图 参考，明白新的工作内容如何开展，以及自己所处的位置，自己的上 游是谁，下游是谁，自己需要交付的工作内容是什么。
• • •
信息系统的一项任务就是解放员工的手脚，取代一些重复的人力劳动工作。系统上了 之后，不是说业务流程不需要而是经过了一些调整，其中某个参与者变成了系统，或 手持设备，或打印机而已。 那么在做系统的功能设计和系统流程设计时，是不是必须先要了解目前业务是如何运 作的呢？从而更好分析分析，更好说明系统在什么环节取代了什么类型的人肉工作？ 所以我们看到的PRD往往也会先以业务流程图开始说明，而叙述一个系统建设的好处 时，也可以用以前的业务流程与系统上了之后的业务流程进行对比。根据分析，将愿 景中的新的业务流程图背后需要系统的功能点撰写清楚。