2.2 业务流程建模 (BPMN)
一句话
BPMN 的价值不是 “画得好看”，而是把流程变成可解析、可计算的结构：一旦有了节点与依赖，就能算出 “关键路径、卡在哪、要加几个人”——而不是靠开会吵 “到底哪个环节慢”。
核心元素（只用得起这五类）
| 元素 | 作用 | 建模时的坑 |
|---|---|---|
| 事件（Event） | 开始/结束/中间（超时、消息） | 忘建 “异常结束”，流程没有失败路径 |
| 任务（Task） | 用户任务 / 服务任务 / 人工审批 | 把 “系统动作” 画成用户任务，责任不清 |
| 网关（Gateway） | 排他（XOR）/ 并行（AND）/ 包容（OR） | 并行分支忘了汇合（join），下游重复执行 |
| 泳道（Lane） | 谁负责（部门/系统） | 泳道按组织画，跨部门协作点看不清 |
| 消息流（Message Flow） | 跨池通信 | 与顺序流混淆，画成 “跨部门直接连线” |
实测 A：解析 BPMN，检查泳道与孤儿活动
本机解析一份 4 泳道、6 任务的采购流程 XML：
| 泳道 | 活动数 | 活动 |
|---|---|---|
| 客户 | 1 | 提交订单 |
| 销售 | 2 | 锁库存、审核信用 |
| 仓储 | 2 | 拣货、打包 |
| 财务 | 1 | 开票 |
| 孤儿活动（不在任何泳道） | 0 | — |
“孤儿活动” 是最常见的建模缺陷：任务画了、却没人负责——上线后就会出现 “这一步到底谁做” 的扯皮。
实测 B：关键路径告诉你该优化哪
同一流程，各任务时长（分钟）+ 并行分支在 “拣货” 前汇合：
| 任务 | 时长 | 最早开始 | 结束 |
|---|---|---|---|
| 提交订单 | 3 | 0 | 3 |
| 锁库存 | 5 | 3 | 8 |
| 审核信用 | 20 | 3 | 23 |
| 拣货 | 10 | 23 | 33 |
| 打包 | 8 | 33 | 41 |
| 开票 | 5 | 41 | 46 |
关键路径 = 46 分钟，其中 “审核信用” 占 43%；把它压到 5 分钟，整条链路降到 31 分钟（−33%）。而 “锁库存 5 分钟” 压到 1 分钟，对总时长毫无影响——它不在关键路径上。
# 关键路径 = 依赖链上 “时长之和” 的最大值
def cp(n):
return dur[n] + max([cp(d) for d in deps[n]], default=0)
这就是流程建模的实用价值：优化只对关键路径有效，其他优化是白花钱。
反模式
| 反模式 | 后果 |
|---|---|
| 画流程图但从不解析（纯图片） | 无法算路径/瓶颈，只能开会吵 |
| 并行分支不汇合 | 下游重复执行，数据翻倍 |
| 只画 “正常路径” | 异常/超时/取消没有建模，上线即救火 |
| 泳道按组织架构画 | 组织调整流程图作废 |
| 任务粒度到 “点击按钮” | 图有几百个节点，没人看得懂 |
| 流程与系统实现两张皮 | 图上 5 步，系统里 12 个接口 |
三条铁律
🔑 流程要可解析；图片不算模型。
🔑 优化只对关键路径有效；先算再改。
🔑 异常路径必须建模（超时、取消、补偿），否则流程只在 PPT 上成立。
自检
Q1 为什么 “优化锁库存” 对总时长没用？
▸ 答案：因为它在非关键路径上：与 “审核信用” 并行，且只花 5 分钟，结束时间（8 分钟）远早于信用审核（23 分钟）。缩短它不会让下游提前开始，只有缩短关键路径上的任务（信用审核）才会改变总时长。
Q2 并行网关忘记 “汇合（join）” 会发生什么？
▸ 答案：因为两条分支都会继续往下走，下游任务被执行两次：一次来自分支 A，一次来自分支 B。表现为 “重复下单/重复发货”。BPMN 里必须用并行网关的 join（等所有入边）来同步。
Q3 “孤儿活动” 为什么是建模缺陷？
▸ 答案：因为泳道代表责任归属：活动不在任何泳道，意味着没人负责。上线后这一步要么被漏掉（流程卡住），要么被多个部门重复做（冲突）。检查方法就是 “所有任务/事件是否都被某个泳道的 flowNodeRef 引用”。
Q4 BPMN 与 “状态机” 该怎么选？
▸ 答案：多角色、跨部门、有并行分支用 BPMN（它擅长表达 “谁在什么时候做什么”）；单实体生命周期（订单状态流转）用状态机更清晰。两者可以共存：BPMN 描述业务流程，状态机描述单个实体的状态约束。
Q5 关键路径和 “瓶颈” 是一回事吗？
▸ 答案：不完全。关键路径是时长最长的那条依赖链，瓶颈通常指 “资源利用率最高/排队最长的环节”。关键路径上的任务一定是 “影响总时长” 的，但瓶颈可能在非关键路径上（如某个共享资源被多条分支争用）。分析时两者都要看。
Q6 流程建模要多细？
▸ 答案：细到 “能算出关键路径并指认责任人” 即可：通常 5–15 个活动。细到 “每个按钮” 会失去可读性，粗到 “接单→发货” 又算不出瓶颈。粒度判据是 “这一步是否对应一个明确的角色 + 可估的时长”。
Q7 流程模型怎么和系统边界对上？
▸ 答案：把 “服务任务” 映射到系统能力（见 2.1 业务能力地图），把 “用户任务” 映射到操作界面或人工工单。映射完检查：每个服务任务是否都有系统承接、每个跨泳道连线是否都是集成点——这些集成点就是系统边界。