Q4.05.3blueprints for cross-department problem location设计研究
适合跨部门问题的定位
别名: 蓝图跨部门定位 · 服务问题定位 · 单部门蓝图误用
概念解释
问题已经能被一个团队在自己的界面里复现和修好，再画一张全公司蓝图，是把手术做成阅兵。服务蓝图适合的是跨部门问题定位：失败的责任或原因不落在单一格子里，需要把多个团队的时间线叠在同一张图上才能看见是谁的缝、哪一次写回、哪一班次。定位不等于开出解决方案，更不等于要重做组织架构；它先回答「这件事卡在哪两个职责之间」。
机制
跨部门问题的特征是局部看来都「没做错」：零售按库存显示可售，仓储按截单已关单，客服按系统状态说无法改。每一方的局部证据都成立，冲突只在对齐之后出现。蓝图提供对齐的公共纸面，让争论从「你们态度不好」转到「这一列上两格互相否定」。若问题始终能在一个代码库、一个职场里关闭，公共纸面没有对手，画了也没人来对格。工具的成本在协调，不在绘图软件。
怎么研究
用一组已知的跨团队事故与一组单团队缺陷，看蓝图是否只对前者改变归因——从「界面文案」改到「两格冲突」。记录参与对格的部门数、对齐所耗的日历时间，以及定位之后是否仍需要该图来监督修复。若画完没有任何归因移动，说明选错了对象。因变量包括归因是否跨过部门边界、定位后的修复所有者是否可点名。
边界
战略愿景工作坊用蓝图讲「未来我们如何协作」，那是愿景道具，不是问题定位；不要用定位标准去要求它。监管或安全审查需要的是控制清单，蓝图可以附属，但不能替代。创业团队五人共用一个群，口头对齐比蓝图快，强行画层会变成表演。定位完成后，若修复只涉及一个系统的一个开关，后续跟踪不必继续维护整张蓝图。
怎么落地
- 开画前用一句话检验：「这个失败能否由一个团队关单？」能，就不要上蓝图。
- 把冲突双方的现行规则写成上下两格，用一次真实事件的时间戳去对；对不上的那一列就是定位对象。
- 定位输出应是「缝的名称 + 双方规则 + 建议的唯一所有者」，而不是一张装饰性全景。
- 修复任务写给被点名的所有者；蓝图存档为定位证据，不必作为日常看板，除非缝还在裂。