5.10 多条价值流怎样知道同一件事发生了
一份合同完成签署后，销售在项目群里发了一句：“客户已签，可以启动。”
项目助理据此创建项目，财务从合同系统再次创建开票计划，客户成功又在自己的表格里建立客户记录。
一周后合同补充协议修改了付款节点。销售知道，项目和客户成功不知道，财务则在另一个群里收到消息。
公司不是没有通知，而是每条价值流都在重新解释同一件事。
我先区分通知和业务事件
“小林在群里说客户已签”是一条通知。
“编号为某项合同的指定版本已经由双方完成签署，并在某时生效”才是一项可以核对的业务事件。
事件说明已经发生的事实，不直接替所有部门决定下一步。项目收到后检查启动条件，财务准备相应付款计划，客户成功确认关系接手。
大家响应同一事实，但保持各自的责任。
共同事件要有权威产生者
我为“合同已生效”指定合同流程作为产生者。销售不能仅凭客户口头同意产生这个事件，项目也不能因为已经开会就反过来宣布合同生效。
事件至少携带：
- 客户和合同身份；
- 生效的合同版本；
- 发生时间；
- 已确认范围与负责人；
- 与验收、付款相关的关键节点；
- 原始记录位置。
下游可以补充自己的项目和财务事实，不能改写合同事件本身。
每个接收者只做自己有权做的动作
| 接收者 | 收到合同生效后做什么 | 仍然不能自动做什么 |
|---|---|---|
| 项目团队 | 检查启动门槛并准备交接 | 在客户条件缺失时宣布启动 |
| 财务 | 建立待确认的开票和付款计划 | 未经制度确认收入或收款 |
| 客户成功 | 指定关系负责人并接收客户目标 | 自行向客户承诺服务范围 |
| 经营分析 | 更新合同组合和未来现金观察 | 把合同额直接当成当期收入 |
AI 可以路由事件、整理上下文和提示未处理事项。正式状态仍由相应价值流负责人确认。
重复事件不能造成重复动作
系统连接不稳定时，同一个事件可能发送两次。
如果每次都创建项目或开票，公司会得到重复记录。工程师会使用事件身份和处理记录避免重复，FDE 则要写清业务上什么算同一件事。
合同版本不同，不是重复；同一版本因为重试再次到达，才是重复。
业务定义和工程处理缺一不可。
顺序错误也要提前考虑
有时“合同变更”比“合同生效”先到达某个下游系统，或者客户信息更新延迟。
接收者不能默默用到达顺序替代业务顺序。它要识别缺少的前置事件、暂时等待或请求重新同步。
涉及价格、范围和付款时，顺序不明确就停止相关动作并交给负责人。
我使用测试事件主动打乱顺序，确认系统不会把旧版本覆盖新版本。
下游失败时不能让上游假装全部完成
合同事件已经产生，项目系统却暂时不可用。
销售不需要撤销合同事实，但必须看见项目团队尚未接收。事件处理状态会显示哪些下游已经完成、哪些等待、失败原因和负责人。
恢复后可以安全重试，不能因为超时再创建一份项目。
这让跨部门交接从群里的“收到”变成可观察的处理事实。
我先选择少量真正共同的事件
不是每次字段变化都要通知全公司。
我先选择会改变多个价值流的重要事件：客户身份已确认、合同已生效、项目可以启动、客户完成验收、发票已开、付款已收到、客户负责人变更。
每个事件都回答：谁权威产生，携带哪些最小事实，谁需要接收，允许做什么，失败如何恢复。
事件太多会制造另一种噪声。只有真正改变下游工作时才值得成为共同事件。
我怎样验收跨流协同
我使用五种情况：
- 一次正常合同签署；
- 同一事件重复到达；
- 合同版本发生变化；
- 下游系统暂时不可用；
- 事件顺序被打乱。
业务人员判断各条价值流是否作出正确响应，工程师检查重复、顺序、重试和日志。
最终还要观察交接等待、重复记录、状态争议和遗漏通知是否减少。
我们最后只保留七个真正改变下游工作的事件
| 事件 | 权威产生者 | 主要接收者 | 下游不能自动推断 |
|---|---|---|---|
| 客户身份已确认 | 客户主数据与有权确认人 | 市场、销售、项目、财务 | 集团关系不等于同一签约主体 |
| 有效商机已形成 | 销售流程 | 售前、产品 | 不表示一定成交 |
| 合同已生效 | 合同流程 | 项目、财务、客户成功 | 不表示项目可启动或收入成立 |
| 项目可以启动 | 项目负责人 | 交付、客户成功 | 不表示客户已经上线 |
| 客户完成验收 | 客户与项目确认 | 财务、销售、客户成功 | 不表示款项已经到账 |
| 付款已收到 | 财务系统 | 销售、经营分析 | 不改写项目和客户价值结果 |
| 客户负责人变更 | 销售或客户成功确认 | 项目、支持、续约 | 旧联系人权限不能继续默认有效 |
“合同已生效”演练故意让同一版本重复到达、补充协议先于原合同到达，并让项目系统短暂不可用。重复只记录一次处理；乱序保持等待；项目失败不撤销合同事实，但销售能看见项目尚未接收。恢复后重试也不能创建第二个项目。
完整事件组合见 七个共同事件。这些事件和身份、权限、来源机制是多条价值流可能复用的共同能力，但不能因此同时启动所有项目。最后一篇把业务价值、依赖和同一批关键人员放进一张六个月组合路线：我怎样安排六条价值流的组合路线。