系统流程图用来说明系统内外的组件怎样配合完成一项任务：由什么触发，经过哪些处理，读取或写入什么数据，最终得到什么结果。绘制时先限定一项任务与系统边界，再按实际流转连接组件；只有模块名称和相邻关系，还不足以说明一件事怎样完成。
用墨刀流程图搭建时，可以先放处理节点与连线，再补数据名称、条件和失败去向。它适合产品、业务与研发一起走读方案，尤其适合发现跨系统交接中没有说明白的地方。
系统流程图、系统架构图和业务流程图别混在一起
系统架构图帮助读者认识系统由什么构成；业务流程图更关注谁先做什么；系统流程图则把一次任务如何经过组件、程序或数据存储讲清楚。它们可以互相补充，不需要把所有信息都塞进同一张图。
| 图表 | 重点 | 订单场景中的例子 |
|---|---|---|
| 系统架构图 | 组件与依赖关系 | 订单服务、库存服务、仓储系统有哪些联系 |
| 业务流程图 | 角色与工作步骤 | 销售确认订单，仓库安排发货 |
| 系统流程图 | 处理与输入输出的具体流转 | 订单通过校验后请求占用库存并生成出库任务 |
| 数据流程图 | 数据的产生、加工和存储 | 订单资料如何进入处理并写入记录 |
先向读者说明本图要回答什么。如果只是介绍产品模块，使用结构图更清楚；如果要评审一项跨系统功能，再选择系统流程图。更广泛的图表选择可参考产品经理常用图表。
从已有模块图中选出一条要说明的任务
图中列出了采购、仓库、销售、财务等管理模块，可以帮助确定系统范围。若要进一步解释“订单确认后怎样进入发货”，需要从这些模块中挑出参与者，并把动作、数据和结果补上，而不是给所有模块互相画线。
为这次绘图先写一句范围说明：“从订单确认开始，到仓储系统收到可执行的出库任务结束；不包含配送签收与财务结算。”这样，后续讨论发现相关问题时，就知道是本图遗漏还是另外一张图的范围。
列出参与者、输入和最终结果
以一套用于讨论的订单协作方案为例，参与者包括订单界面、订单服务、库存服务与仓储系统。具体系统怎样拆分，需要由项目团队确定；这里重点是让每次交接都有清楚含义。
| 参与部分 | 本次接收什么 | 本次返回或产生什么 |
|---|---|---|
| 订单界面 | 用户确认操作 | 订单确认请求、处理结果展示 |
| 订单服务 | 订单号与确认请求 | 校验结果、库存占用请求、订单状态 |
| 库存服务 | SKU、数量与订单标识 | 占用成功或不可满足原因 |
| 仓储系统 | 已确认的出库任务资料 | 任务接收结果或失败信息 |
输入写到足以理解规则即可，详细字段可另放接口说明。不要把箭头只标成“调用接口”：写成“请求占用SKU与数量”，业务人员也能看懂它的目的。
先画正常路径，再画判断与失败去向
- 用户确认订单，界面发送请求，并显示正在处理，避免持续重复提交。
- 订单服务检查订单是否处于可确认状态，以及必要资料是否齐全；不满足时返回明确原因。
- 校验通过后，向库存服务请求占用所需数量。
- 库存占用成功后，更新订单状态，再按约定方式通知仓储系统创建出库任务。
- 仓储系统返回接收结果，订单侧显示任务已受理或等待后续处理。
正常路径只是骨架。库存不足时应回到什么页面，订单状态有没有改变；库存已占用但仓储任务接收失败时，是重试、人工处理还是取消占用，都需要由团队选定，不能在图里默默跳到“结束”。
网络超时尤其需要单独讨论：没有收到响应，不等于对方没有处理成功。图中可以增加“查询处理结果”或“进入待核对状态”等分支，但不能简单把所有超时都画成重新创建任务，否则可能产生重复动作。
在画布里整理系统关系与文字
先摆放节点，再连接主路径。把同一系统的处理放在相邻区域，并在边界处写清请求与返回；根据节点数量选择从左到右或从上到下的阅读方向，尽量保持一致。
- 节点名称写动作加对象，例如“校验订单状态”，不要只写“订单系统”。需要时，在区域标题注明所属系统。
- 判断框写具体条件，例如“库存占用成功？”，出口分别标明结果。
- 数据存储与处理节点采用不同图形，让读者分得清“保存在哪里”和“做了什么”。
- 异常分支尽量靠近发生位置，标出回退、等待或人工处理的终点。
- 同步请求、异步通知如果同时存在，在线旁标明方式或提供图例；仅用不同颜色不够清楚。
完成后再统一主题、字号和间距。文字较长时应拆分动作，而不是把整段说明缩成难以阅读的小字。跨系统消息先后非常复杂时，可以为这段单独增加时序图，不必让主图变成密集的连线网。
让一次请求完整走过成功与异常
评审时把同一订单从头走到尾，分别试库存充足、库存不足、重复确认、仓储返回失败和响应超时。对每种情况，至少回答三个问题：用户此刻看到什么，系统记录是什么状态，下一步由谁处理。
比如重复确认不能只靠前端按钮禁用解释，后台如何识别同一请求也要由研发确认；取消订单时能否释放已占用库存，则要与取消范围和仓储状态一起讨论。这些决定确认后，再写回流程图的对应节点，避免结论只停留在会议记录里。
交付时保留可编辑文件，并在图旁注明任务范围、涉及系统与尚未进入本期的分支。需要放进PRD或汇报时，再导出相应图片。系统流程图真正有用的标志，是另一位同事能沿着它解释一次处理如何完成，也能说清失败以后怎么办。
