地图涉及多个部门时需要共同维护，否则会与现状脱节

概念解释

旅程从进店问询画到售后，维护权却只在体验组：门店改了接待话术、仓储改了截单时间，图上仍是旧交接。涉及多个部门的地图若没有共同维护，会在空间上与现状脱节——不是时间把它养旧，而是有管辖权的人从未把它当成自己的文件。共同维护指各段的负责人能改自己那一段、也必须看到与邻段的接缝，而不是把整张图外包给一个「用户体验」岗位。

机制

部门优化本地指标，变更通知走内部渠道，不会自动到达那张总图。体验组最清楚研究当时的观察，最不清楚邻部门上周上线的规则。单方更新会把别人的步骤画错，于是别人拒绝承认这张图，改回各自的局部流程图。拒绝之后，跨部门断裂重新变成口头传说。所有权若不按触点切开并写进职责，地图在组织里的地位就只是一张展示件：谁都可以引用，谁都不必对错误负责。

怎么研究

列出图上每一步的实际执行部门，对照该部门近一次流程变更是否写进了图。访谈各部门是否把这张图当作可改的工作文件，还是「体验团队的海报」。比较「单所有者」与「按段指定共同所有者并设接缝评审」两种安排下，图与现场规则的偏差步数。因变量包括未同步的变更数、部门拒认的步骤数、以及接缝步骤的权属是否明确。

边界

一张只覆盖单一团队可控范围的地图，不需要为形式拉上无关部门；硬拉会变成签名仪式。共同维护也不是把后台内部工序画进用户旅程——用户看不见的作业规程属于另一类图，这里要共管的是人实际穿过的那些段。外包供应商执行的触点若进了图，所有权要写到合同接口人，否则「共同」只发生在甲方内部，图仍会与现场脱节。

怎么落地

• 在图例旁做权属表：每一步对应执行团队与可修改的人；无主步骤不得上决策会。
• 邻接两段分属不同部门时，设接缝负责人，任何一侧变更必须通知对侧并改图。
• 禁止体验组代写其他部门的步骤；该段由该部门用自己的现行规则填写，研究只提供观察冲突。
• 抽查：拿一个最近的跨部门规则变更，看图上对应步是否已改。未改即视为脱节，暂停用该图做范围讨论。

延伸

• 同组：Q4.04.1 地图跨越触点呈现全过程 · Q4.04.2 需标注情绪与痛点的证据来源 · Q4.04.3 未经验证的地图是团队假设 · Q4.04.4 现状地图描述实际发生的过程，愿景地图描述期望的过程，两者不可混用 · Q4.04.5 颗粒度过细会淹没关键转折点，过粗会掩盖具体断点 · Q4.04.7 地图完成后若不更新，会逐渐偏离已变化的实际流程
• 相邻：Q4.05 服务蓝图 · Q4.17 研究发现的传达与落地
• 站内检索：cross-department journey ownership · shared journey maintenance · organizational drift of maps