BPMN协作模型：人工流程、技术流程与记录性流程三泳道示例

延续[[一体化模型的力量从流程金字塔到房子拒绝业务模型与技术模型分离]]的”房子”结构，业务模型被拆成人工流程模型和技术流程模型两种：人工流程完全由人处理和控制，技术流程由软件（如工作流引擎）处理，二者经常相互触发——人工操作者点击任务列表按钮能触发一段技术流程，技术流程也可能因需要人工介入而创建人工任务。BPMN支持在同一张大图（协作模型，collaboration model）里同时建模所有这些流程，本质上每个流程仍是独立创建的，只是画在一张图上并用消息流表达彼此的通信关系，图中每个矩形容器叫作”泳道”（pool），每个泳道是一条完整的流程、代表整体业务流程的一个具体视角。以用户入网协作模型为例：顶部泳道是人工流程，描述办公室职员如何执行审批（能清楚看出批准信是手动发送的，因此不能被纳入自动化流程，即使这未必是最高效的做法，也如实反映了现实，同时兼具工作说明的作用）；底部泳道是CRM系统的技术流程，但只是用于记录（CRM本身并没接工作流引擎），了解这些幕后细节有助于设计好中间的可执行流程（例如可以看到CRM已经发过欢迎邮件，就不需要在别处重复发一次）；中间泳道才是真正跑在工作流引擎上的可执行流程，因为只有它是唯一需要被精确描述的（其余泳道都只是给人看的记录，内容可以更自由、只需着重体现整体交互）。协作模型的强大之处在于展示不同执行者（人、工作流引擎、其他软件组件）如何互动，但要注意它通常不是学BPMN的第一步，而且与持续保持更新的可执行流程不同，协作模型在系统生命周期内很少被更新，主要价值发挥在设计阶段。

结构图：

flowchart TB
    subgraph P1["泳道1: 人工流程(办公室职员审批)"]
        A1[收到申请] --> A2[人工审批] --> A3[手动发送批准信]
    end
    subgraph P2["泳道2: 可执行技术流程(工作流引擎)"]
        B1[启动入网流程] --> B2[消息:等待审批完成] --> B3[继续后续步骤]
    end
    subgraph P3["泳道3: 记录性技术流程(CRM系统,未接工作流引擎)"]
        C1[创建用户] --> C2[已发送欢迎邮件]
    end
    A2 -.消息流.-> B2
    B1 -.消息流.-> C1
    C2 -.已完成,无需重复发邮件.-> B3