★ FEATURED ARTICLE 从需求评审会出来我经常感叹如果每个业务方都愿意把流程画成一张图再说事会议时间至少能砍掉一半。刚接手某跨部门系统的需求梳理时我几乎每周都要参加各种评审而大部分争论最后都会落到同一个问题——你说这个环节有风险到底是从哪一步开始不对的没人能指出来因为每个人脑子里跑的流程都不一样。这种场景做过需求分析的人应该都不陌生。流程图就是把各人脑中的流程拉到同一张纸上的工具。它不需要花哨也不讲究艺术感本质上是回答三件事这件事从哪里开始、经过哪些环节、最终到哪里结束。当这三点被画清楚业务用例里的角色分工、异常分支、节点顺序就不再是口头约定而是白纸黑字。这篇是流程梳理系列的第十篇专门聊业务用例视角下的流程图怎么画、怎么用、怎么在评审会上不被人问住。适合读这篇文章的人有三类。刚入门的需求分析师或产品经理需要把业务流程梳理清楚却不知道从哪下笔经常跟业务方开会对需求的老手想借流程图降低沟通成本带项目或带团队的管理者需要用标准化图形统一团队认知。不管你是哪一类我尽量少讲理论多讲实操把我画过上百张业务流程图踩过的坑一并写进来。1. 业务流程图到底在解决什么问题1.1 流程图的本质不是画图而是达成沟通协议很多人一提到画流程图第一反应是该用哪个工具马上打开绘图软件开始拖拽形状。这是本末倒置。流程图本质上是业务团队之间达成的一种沟通协议——把不可见的逻辑变成可见的图形让所有人对同一件事产生同样的理解。它跟文档的区别在于文档依赖语言而语言天然有歧义图形依赖拓扑关系每个节点和箭头的位置都传递确定的信息。所以画图之前必须先想清楚我给谁看要传递什么结论这张图画完之后要推动什么决策在业务用例场景里流程图通常服务于两类读者。第一类是业务自己他们用图确认流程是否和真实运作一致第二类是技术团队他们用图确认系统需要支撑哪些节点、哪些判断条件。同一张图要同时兼顾这两类读者并不容易所以画图时宁可少画细节也不能画错结构——结构错了评审会上第一个拍桌子的往往是业务方这点我见得太多了。1.2 三个核心价值统一认知、定位问题、留下基线流程图的第一个价值是统一认知。实际业务中一线执行、部门主管、后台专员对同一流程的理解往往存在偏差平时看不见一旦出了故障就互相甩锅。把流程画出来之后分歧会立刻暴露在节点和箭头上这时候讨论的就不再是我觉得应该是怎样而是图上这一步到底对不对。有一次项目组争论订单取消后库存到底要不要立即释放开发说业务没提过业务说这是常识一张流程图摆出来大家才发现这个判断节点根本不存在问题瞬间从扯皮变成了补规则。第二个价值是定位问题。我见过不少项目运营反复反馈系统经常卡单技术人员排查很久找不到原因。后来把下单流程整体铺开问题根本不在系统而在库存校验之前多了一个人工确认环节——这个环节从未出现在需求文档里是业务方自己加的。流程图画出来之后这类影子环节无处遁形。肉眼找不出的瓶颈、死循环、灰色地带在图上往往一眼可见。第三个价值是留下基线。任何人做流程优化都要先有一个现状基线作为参照。没有流程图的组织每次优化都是一场争论因为没有共同参照物。有了基线图你可以直接标注当前单均耗时5天其中等待占3天下一次优化就有了衡量标准优化前后对比也有了依据。这件事听起来简单但能做到的团队并不多大部分团队都是出了问题才想起画流程图。1.3 一张图要服务四种角色阅读重点完全不同画流程图的时候心里要装着四种角色的阅读习惯。业务人员重点看流程是否符合实际操作习惯关心每个环节的前置条件和产出物产品经理关注边界和异常分支因为需求文档里的规则要靠流程图来补全开发人员关心决策节点和状态跳转这直接影响代码里的分支逻辑和状态机设计测试人员则把流程图当作用例设计的起点每个分支至少对应一条测试用例。一张合格的流程图必须让这四种人都能快速找到自己关心的信息。这也是我一直强调的画图不是画给自己看的而是画给所有参与者看的。2. 画图之前先吃透符号体系看懂和画对是两回事2.1 五个基础符号90%的业务流程图只需要这些流程图有国际通用的符号规范不同绘图工具的图形样式略有差异但语义基本一致。日常业务用例不需要记全套掌握五个基础符号就能覆盖绝大多数场景。圆角矩形开始和结束。一张图只能有一个开始节点结束节点可以有多个但别画了开始忘了结束这是新手最常见的疏漏。直角矩形处理或业务操作。表示一个具体动作比如核对订单信息发送通知。动作标签必须是动词短语不能只写一个名词写订单不如写审核订单。菱形判断或分支。表示需要决策的节点至少引出两条带条件的出口通常写是/否或通过/不通过。箭头流向。表示流程推进方向箭头上要写清流转条件或产物这是整张图信息密度最高的地方。波浪底矩形文档或单据。表示流程中产生的纸质或电子凭证例如采购申请单订单确认书。此外还有数据库符号圆柱形表示数据存储以及子流程符号带双竖线的矩形表示被展开的细节流程。这两个符号在偏系统的流程图里也常见业务用例如果牵涉系统交互建议掌握。2.2 连接线才是质量关键箭头必须回答什么条件下流转很多新手画的流程图形状全对但整张图让人看不懂问题基本出在连接线上。连接线不是简单地把两个节点连起来就完事它必须回答一个问题上一步到下一步的条件是什么。举个例子提交报销单到财务审核这条线如果不写任何条件看上去所有单据都会直达财务但实际流程可能是金额小于500元的直接由财务审核金额超500元的必须先经部门负责人审批。这个判断不画出来流程图就是失真的。正确的做法是在箭头上标注流转条件必要时用括号补充说明例如标明通过驳回金额≤500元。如果一个节点引出的出口超过三个建议停下来重新梳理结构——业务逻辑很少天然需要三岔以上的决策出现这种情况通常是决策条件没有拆干净把多个判断挤进了一个菱形里。2.3 四大禁忌大多数人栽在第一和第四条第一把动作画进判断框。菱形里写查询库存是不对的查询是操作应该用矩形菱形里应该写库存是否充足。第二一张图出现多个无编号的开始节点。多起点意味着流程边界不清读者会困惑到底从哪条路进来。第三反向箭头满天飞。流程主体应该保持单一推进方向回退比如审批驳回可以用一条较短的返回线画在空白区域不要穿插主线。第四有形状没文字。一张只有形状没有任何说明的图等于没画每个节点都要有清晰的动作标签。3. 业务用例里最高频的五种流程图实战形态3.1 订单处理流程先画主路径再补异常分支订单处理几乎是每个带交易属性的系统都要梳理的流程。以某自营商城的订单履约为例流程主干通常是用户提交订单 → 校验库存 → 锁定库存 → 用户支付 → 支付回调 → 订单推送至仓库 → 发货 → 确认收货。这中间至少有三个决策节点库存是否充足、支付是否成功、是否存在超时取消。库存不足时要走补货提示或预购分支支付超时要走关闭订单分支发货后还有可能发生用户拒收或物流退回。把这些分支完整画出来订单状态机的设计就有了依据。我梳理这类流程时有一条经验先把最顺利的主路径画出来再逐条补异常分支。主路径保证图的结构清晰异常分支保证图的完整性。很多流程图画到最后像蜘蛛网就是上来就画异常主次颠倒最后连自己都看不懂。先主后支画完主路径后在每个节点问一句这里失败了怎么办问题自然浮出水面。3.2 审批流必须区分会签和或签审批流是另一类高频场景几乎每家公司都有报销、请假、立项这类需要多级审批的业务。拿报销审批举例典型流程是员工提交申请 → 直属主管审批 → 财务复核 → 出纳付款 → 员工确认收款。其中主管审批和财务复核两个节点都需要画驳回出口驳回后流程回到提交人处修改后重新提交。画审批流有个关键点必须区分会签和或签。会签指所有审批人都同意才能继续或签指任意一人同意即可。图上要明确表达这种区别否则开发同学默认做成任意一人审批通过等上线之后业务方才发现规则不对。我建议在审批节点下方用注释文字写明会签需全员通过或或签任一通过即可这个信息对技术实现来说比节点本身重要得多。3.3 客户投诉处理流程图画完会暴露出大量规则缺口客户投诉流程特别能体现流程图的暴露问题价值。标准流程是客服受理 → 登记工单 → 初步分类 → 分派责任部门 → 调查核实 → 给出处理方案 → 用户确认 → 结单。分类这个节点至少有三种出口产品类、物流类、服务态度类分别流向不同部门。用户确认也有两条出口满意则结单不满意则升级或重新处理。这类流程画完最常被问的问题是如果责任部门7天没回复怎么办这正是决策点和异常分支的价值所在——流程需要定义超时分支比如超过3个工作日自动升级到主管。画流程图的本质工作就是帮业务方把那些应该存在但没人写下来的规则补出来。如果你画的流程图在评审会上没有引发任何那如果……怎么办的追问多半是漏了几条分支。3.4 新员工入职流程最需要泳道图的场景入职流程看起来简单但涉及部门众多最适合用泳道图。角色至少包括HR、用人部门经理、行政IT和员工本人。主线是发放offer → 提交入职材料 → HR建档 → 开通系统账号 → 领取办公设备 → 部门入职培训 → 设定试用期目标 → 试用期评估。这个流程里最容易画漏的是交接点比如设备领取必须等账号开通培训必须等材料审核完成这些前置依赖关系就是箭头上的流转条件。有次评审会上我发现行政认为工位安排在offer发放时就该同步进行HR认为入职当天才通知行政这个信息差直接导致新员工入职第一天没有工位。原因就是流程图里没有把offer发放到工位准备之间的虚线依赖画出来。泳道图的价值在这里体现得淋漓尽致每个角色对自己负责的节点一目了然跨部门交接点也没法躲。3.5 项目交付流程阶梯式回退结构要控制回退线项目交付流程偏工程化通常包括需求收集 → 可行性评估 → 方案设计 → 开发 → 测试 → 验收 → 上线。它和前面几类最大的区别是每个阶段都设有关卡评审评审不通过要回到上一阶段。因此项目交付流程图往往是阶梯式回退结构画的时候要把回退路径控制在主线附近不要横穿整个图面。比较好的做法是把回退条件写清楚比如评审未通过返回方案设计同时让回退线尽量短、尽量靠边避免干扰主路径的可读性。4. 从需求到成图六步画出可落地的业务流程图4.1 边界先行先确定起点和终点画图的第一个动作不是打开软件而是先写两行字流程从哪里开始到哪里结束。很多新人拿到需求就开始画最后图画到一半发现业务方自己都没想清楚边界。拿售后流程举例如果起点定在用户提交售后申请那么用户在App里浏览售后规则就不该出现在图里如果终点定在退款到账那么用户再次购买也不该画进来。边界模糊是返工率最高的原因开工前花五分钟把边界明确下来能省下后面数小时的改图时间。4.2 列出所有参与角色在画泳道之前先列角色清单。角色不等于具体的人而是职责的集合。比如财务审核是一个角色出纳付款是另一个角色哪怕实际由同一个财务人员完成画图时也建议分开因为职责分离是很多业务风控的基础分开画才能让系统设计时区分权限边界。列角色时用一个简单问题校验即可这个角色在这个流程里有至少一个动作吗如果只有名字没有动作直接删掉。4.3 先画主路径再补分支把所有角色放进泳道后从开始节点出发先画出最顺利的主路径——即没有异常、没有驳回、没有等待的理想路径。主路径通常占整张图面积的六到七成。画完后回头在每个节点上问一句话这一步如果失败了怎么办每问出一个异常就往主路径旁边补一个分支。这个顺序保证了画图过程本身就是在做需求分析而不是简单的图形翻译。4.4 决策节点单独梳理流程里每个菱形都要单独确认判断条件。判断条件必须能被客观验证不能是感觉差不多看情况。例如库存是否充足是客观的产品质量是否合格就必须明确合格标准比如以检测报告判定结果为准。否则菱形画出来也没用开发实现不了测试也没法设计用例。判断条件是业务规则的落点画图时最花力气的地方应该在这里而不是在形状的美观上。4.5 绘制与排版把复杂图拆成一页纸排版原则只有一个让读者在10秒内找到主路径。我的做法是从上到下走主流程左右两侧放分支例外节点标签控制在十个字以内箭头上的说明文字放在线条上方且保持同一方向所有形状大小尽量一致。实在信息太多就拆图把异常分支单独画成一张子流程图主图里用子流程符号代替。一个模块如果超过15个节点读者大概率已经失去耐心了拆分不是偷懒而是对读者的负责。4.6 评审验证图不是画完就算完画完图之后至少要过两遍。第一遍自查逐条路径从开始走到结束确认每条都能走通没有断头路。第二遍拉上业务方走查让业务操作人员逐节点确认你是不是真的这样做。评审会上最有效的追问其实只有一句从我标出的这个节点走到下一个节点你实际会怎么操作业务方只要能在图上一一指出来这张图基本就过关了。如果能顺手让技术同事看一眼决策节点的定义是否足够严谨那就更稳了。5. 工具选型不同场景下怎么选最顺手5.1 三类工具的定位差别市面上的流程绘制工具大致分成三类我用自己的使用场景说说差别。工具类别典型能力适合场景主要局限办公套件内置绘图基础形状、画布、导出图片单机出图、放进方案文档协作和版本管理弱在线协同绘图工具实时协作、评论标注、模板库团队评审、多人共创部分高级功能收费专业建模工具流程规则库、仿真分析、资产管理企业级流程资产统管学习成本和单价高怎么选我的建议是单人快速出草图用第一类三四个人协作评审用第二类整个公司要做流程资产库、需要沉淀上千条流程规则时再考虑第三类。不要把工具当目标多数时候我们需要的只是把图画出来让大家看清楚而不是追求工具的高级功能。5.2 新手选型的三条参考标准第一看能不能导出图片和PDF这决定了评审材料怎么做。第二看模板库够不够丰富尤其是带泳道的模板能省不少起步时间。第三看有没有评论和标注功能我在协作时最依赖的不是画图本身而是让业务方直接在图上圈出哪里不对。至于价格免费的方案基本够用等团队用起来觉得吃力再考虑付费方案。5.3 模板素材的正确打开方式模板的作用是给第一次画某类流程的人一个起点而不是让你被模板束缚。我的操作方式是从模板里挑一个结构最接近的先只改节点名称不动布局跑通之后再按实际流程增删分支最后才重新排版。倒过来做的人很容易在第一步就花大量时间调整格式最后图没画完时间全耗在拖框上了。记住模板是脚手架不是最终形态。6. 常见问题与排查技巧实录6.1 一张病症速查表画完照着查一遍我把画业务流程图常见的坑整理成一张速查表大家画完可以逐条对照基本能做到自检过关。症状典型原因处理办法线条交叉纵横分支过多且没有规划走向拆分子流程或调整泳道方向有开始没有结束只关注主干忘掉收口从终点节点反推检查判断条件语义模糊没有细化业务规则与业务方逐条确认可验证条件角色泳道空置多画了没有动作的角色删掉该角色回退线横穿全图主线与异常流混在一起把回退线移到图面空白区域标注用语不一致团队没有统一术语表建立流程术语和命名规范6.2 评审会上被问住的三个高频问题画过流程图的应该都有体会辛苦画完评审会上总有人提出你完全没想到的问题。最典型的是下面三个。第一如果这一步失败了会怎样这说明异常分支不完整直接补一条失败分支。第二这个节点实际由谁负责说明责任角色不清晰用泳道重新标一遍。第三这个流程和系统里的实际状态流转一致吗说明图和实现层脱节了需要拉上开发一起对状态流转。这三个问题我每次评审前都会主动问自己一遍答得上来再上会能省掉很多现场尴尬。6.3 我踩过的坑过度建模与流程碎片化最后聊两个我亲身踩过的坑。第一个是过度建模。初期画流程图时我总想把所有细节都塞进去结果一张图画了三十多个节点线条密得自己都看不清。后来学乖了第一版只画核心主线和高风险分支细节放到子流程或注释里。第二个是流程碎片化。同一业务被拆成好几张互不关联的图用户操作被割裂在不同图里评审时每个人都只看到自己负责的那一小段跨环节问题反而被掩盖。现在我习惯给同一业务域做总图子图的层级结构总图展示主流程子图展开关键细节这样既有全局又有局部。画了上百张业务流程图之后我的体会很简单流程图的难从来不在工具也不在标准化而在于你能不能把业务里那些默认大家都懂的潜规则一个个挖出来放在台面上。每一次画图本质上都是一次需求澄清。所以如果有人问我这张图什么时候算画完了我的答案永远是当没有任何一个参会者说这儿应该是这样的吧的时候。最后再分享一个小技巧画完一张业务流程图试着让一个完全没参与过这个业务的新同事照着图走一遍流程他每卡住一次图上就多一个需要补充的说明。这一招比任何自查都管用。
阅读完成 · 觉得有帮助？
