ProcessOn与流程图：梳理业务流程的用法

多数流程图的问题不在美观，在读不懂：谁做的、什么条件下走哪条分支、异常往哪退回，图上都没写。工具能解决画得快，解决不了想不清。用 ProcessOn 之前先把这三件事想明白，画出来的图才有用。

画不清，多半是层级没定

常见的错误是把不同粒度的动作放在同一张图里。左边是「提交申请」，右边是「点击保存按钮」，一个是业务阶段，一个是界面操作，混在一起读者无法判断该看哪一层。

正确的做法是先定这张图服务谁。给管理层看，画到阶段和责任人即可；给执行者看，要细到操作和判断条件；给开发看，还要标系统和数据流向。三张图可以同名，粒度必须分开。

粒度定了，节点数量自然收敛。一张图超过二三十个节点，读者的注意力就散了，这时候应该拆成主流程加若干子流程，用子流程节点跳转，而不是硬塞。

梳理业务的五个步骤

• 先列角色：把参与方写全，包括客户、供应商、系统，漏一个角色后面就要重画。
• 再写起点与终点：明确什么事件触发流程、什么状态算结束，避免图画到一半没边界。
• 按时间顺序铺动作：先不画判断，把主干动作从左到右排开。
• 补判断与异常：每个判断节点写清条件，每条异常分支写清退回哪里。
• 标注系统与单据：哪个环节在哪个系统里做、产生什么单据或记录。

第二步的边界最容易被跳过。没有明确终点，流程会一直延伸，最后画成一张包罗万象的图，谁都看不出关键路径在哪。

第四步决定图的实用价值。真实业务里，正常路径往往只占三成，剩下都是异常：材料不全、审批超时、金额超限。异常分支不画，图就只能当示意，不能当操作依据。

泳道图与判断节点的规范

泳道图解决的是责任归属。每个角色一条横道或竖道，动作落在谁的泳道里，就是谁负责。跨泳道的箭头表示交接，交接点最好标上传递物，否则读者不知道交出去的是什么。

判断节点用菱形，出口必须带条件文字。只画两条线不写条件，等于没画。条件写法要互斥且穷尽：是、否；或按金额分档，把区间写全，别留下无法判断的空白地带。

起止节点用圆角矩形或椭圆，不要和普通动作混用。回退箭头尽量少交叉，交叉多了可读性急剧下降，必要时用连接符断开，在另一处续上。

命名要统一。全部用动宾结构，或者全部用名词短语，不要一半「提交申请」一半「审批环节」。统一命名之后，图的节奏感会好很多，评审时也容易逐条对照。

还有一条常被忽略的规范：箭头方向尽量统一。左到右或者上到下，选一种贯穿全图，来回折返的箭头会让读者反复确认自己读到哪一步，评审时最费口舌。

协作、版本与导出

协作前先分工：一个人主笔结构，其他人只提意见。多人同时拖节点，图会变形，回退成本高。评审用评论功能挂意见，改完再关掉，比在群里发截图高效。

版本要留。业务流程会随组织调整而变，三个月后的图和现在的图差别可能很大。每次评审通过后另存一版，文件名带日期和版本号，出了问题能追溯是哪次改动引入的。

导出看用途。放进方案文档用图片，注意选足够的分辨率，缩放后文字不能糊；要给同事继续编辑，用工具自有格式或通用图形格式；要打印上墙，先确认页面尺寸和分页，跨页断在判断节点上最难读。

免费版通常有文件数量与协作人数限制，团队规模一大就会碰到上限。选版本前先算清同时在编的人数，以及历史文件要保留多少，别等图都存在别人账号里才发现迁移困难，具体额度以官网说明为准。

ProcessOn 提供的是画布和模板，流程本身对不对，取决于你有没有把角色、边界和异常想清楚。官方入口：ProcessOn官网。画完先让一个不熟悉该业务的人读一遍，他能顺着走通，这张图才算合格。