采购询价跨公司流转，BPMN消息流和顺序流该怎样连？

BPMN中的顺序流表示同一参与方内部接下来做什么，消息流表示不同参与方之间交换什么。先确定参与方边界，再选线条：同一池内的步骤用顺序流连接，即使跨过泳道；不同池之间用消息流表达通信，不能用顺序流把两家公司的过程串成一条。

以采购询价为例，采购与财务可以是采购方池中的两个泳道，供应商则是另一个参与方。使用在线流程图工具整理时，先摆好这两个池，通常比画完全部任务后再补边界更容易发现误连。

先问“谁的过程”，再问“谁负责这一步”

池用于表示参与方，泳道用于整理同一过程里的职责或类别。二者不是大小不同的部门框。部门通常可以画成泳道，但不应仅凭组织名称决定：你是在描述同一个过程内的交接，还是两个独立参与方之间的协作？

本例只研究一轮询价：采购方整理需求、确认预算、发出询价、接收报价，最后完成报价比较；不展开签约、付款和交货。供应商对外接收询价并返回报价，其内部由谁计算价格、经过几级审批，采购方未必知道。

询价案例中的边界与连线

关系	本例如何划分	采用的表达
采购人员整理需求，交财务确认预算	采购方同一池，两个泳道	顺序流跨泳道连接内部步骤
采购方向供应商发出询价单	两个独立参与方、两个池	消息流标记“询价单”
供应商返回报价	从供应商池回到采购方池	另一条消息流标记“报价单”
采购方收到报价后比较价格与交期	采购方池内继续处理	顺序流连接接收与比较步骤

顺序流使用实线与实心箭头；消息流使用虚线、起点空心圆和终点空心箭头。更重要的是语义：前者不能越过池的边界，后者不能连接同一池内的两个对象。具体连接规则见OMG BPMN 2.0.2规范的泳池与消息流章节。

画一轮询价：内部顺序和两次通信分开

先把采购方池画完整。上方泳道标“采购”，下方标“财务”；从左到右安排以下步骤：

1. 开始：询价需求已确认。
2. 采购：整理规格、数量和期望交期。
3. 财务：确认本轮询价的预算口径。
4. 采购：发送询价单。
5. 采购：接收报价单。
6. 采购：比较价格、交期与报价条件。
7. 结束：完成本轮报价比较。

这些节点之间使用顺序流。采购把材料交给财务，以及财务确认后回到采购，都是同一过程中的职责交接，不需要另画跨参与方的消息。

再在下方放一个“供应商”池。如果本次只需表达采购方能看到的通信，可以保持供应商池为空，不填内部任务，这就是黑盒池；Camunda的参与方建模说明也用隐藏对方内部过程的方式处理这类边界。由“发送询价单”向供应商池边界连接消息流“询价单”；再由供应商池边界向“接收报价单”连接消息流“报价单”。黑盒不是不知道就随便画，而是明确本图不描述对方内部过程。

不要把“发送询价单”直接连到“比较报价”。发送完成不等于报价已经收到；接收这一步必须有明确位置。在BPMN中，接收任务或适当的消息捕获事件可以表达等待外部消息；Camunda的BPMN入门说明也将过程顺序与等待事件区分开。

如果需要与供应商共同讨论其内部工作，再把黑盒展开为“收到询价—编制报价—发送报价—结束”。此时把两条消息流分别连接到相应接收、发送位置。不要一边保留黑盒边界上的通信，一边再画含义相同的任务间通信，否则读者可能以为发生了两次发送。

两边都有自己的过程顺序。采购方发送消息，不意味着它能替供应商启动任意内部步骤；供应商完成某个任务，也不意味着采购方自动知道结果。把通信点画出来，恰好能让团队发现“等谁回应”这类流程依赖。

三种误连，分别错在什么地方

错误一：用实线从“发送询价”跨池连到“编制报价”

这会把供应商工作误画成采购方内部的下一步。修正时，先恢复两边各自的顺序，再用消息流连接发送与接收位置。若并不知道供应商如何处理，直接保留黑盒池和往来消息，不必编造一条供应商内部流程。

错误二：采购和财务分了泳道，就用虚线互发消息

在本例中，泳道只是同一采购过程里的分工。将“整理需求→确认预算”改成消息流，并不能表示“跨部门更正式”；它改变了线条的含义。修正为跨泳道顺序流即可。现实中发过一封邮件，不代表在当前建模边界下必须画成BPMN消息流。

错误三：从“预算是否满足”网关直接向供应商发消息

网关负责路由，不承担发送询价的动作。如果后来需要增加预算判断，应在“满足”分支后放“发送询价单”任务，再从任务连接消息流；“不满足”分支则留在采购方内部，按约定调整需求或结束。不要让一条虚线同时代替判断、发送和对方接收。

判断某条线是否合理时，可以先把它读成一句话：“这个步骤结束后，我们接着做……”通常是在说内部顺序；“我们向另一方发送……”通常是在说通信。读不通时，先核对过程边界和任务含义，而不是只替换箭头样式。

消息写清内容和归属，图才适合拿来讨论

“发送信息”“返回结果”过于笼统。给消息明确名称，并补一张小清单，写清它属于哪一轮询价。以下字段是这次业务设计的约定，不是仅画一条线就会自动具备的系统功能。

采购询价的两类往来消息

消息	从哪里到哪里	需要共同确认的内容
询价单	采购方“发送询价单”→供应商	询价编号、规格、数量、期望交期、回复期限
报价单	供应商→采购方“接收报价单”	对应询价编号、报价版本、价格口径、交期、有效期限

例如，询价编号RFQ-024对应第二版报价，不能因为供应商相同，就把它接到RFQ-025的比较环节。评审时把询价编号和报价版本写在两端旁边；系统如何关联、校验和处理重复消息，交由后续实现设计确认。

还要单独标出本图未覆盖的情况：供应商不回复、报价需要澄清、收到过期版本。本轮图只画正常的询价与答复，不意味着这些情况不存在。若业务要求到期后继续推进，就要明确超时条件和后续动作，再扩展等待路径；不能假设一条消息流会自行处理超时。

在Boardmix中整理这张图时，先放两个池和采购方的两个泳道，完成池内任务，再补消息连线与名称。把三种误连作为小的对照区域放在图旁，评审者能直接指出哪条边界或哪次通信需要调整。需要从既有结构起步，可查看BPMN流程图模板，但要按本例参与方重新检查每一条连接，不能只替换任务名称。

最终检查不必数图形多少：沿采购方顺序能否走完一轮询价，发出的询价在哪里被接收，报价回来后从哪里继续，未知的供应商内部过程有没有被画成已知事实。图形表达和执行模型是不同交付；业务图通过讨论，不等于已完成工作流引擎配置或部署。