跨部门协调推不动时，先别急着换人或加会。把“推不动”拆成可观察的停滞症状，再按“事项是否清晰—接口是否明确—权限与资源是否到位—优先级是否冲突—信息是否可见”五个入口逐层排查，用会议纪要、交接记录、阻塞时长等证据验证每个假设。多数停滞来自责任边界模糊、优先级不一致或信息不透明，排查清楚再安排处置，才能避免反复救火。像ONES这类协作平台可在进展记录与接口交接环节提供支撑，本文重点讲排查与处置路径。
要点总览（TL;DR）
- 跨部门协调推不动时，先把“推不动”拆成事项停滞、接口停滞、决策停滞三类可观察症状，用记录表固定卡点部门、停滞天数和当前状态。
- 按“事项清晰度—接口明确度—资源到位度—优先级一致性—信息可见度”五个入口逐层排查，每个入口都配可核验证据，先排事项与接口，再排资源与优先级。
- “对方不配合”只是假设，用访谈、记录回溯和会议纪要核对三种方式交叉验证，没有证据的假设只作为待验证项保留。
- 处置对准根因做最小必要调整：重写交付物、指定接口人、升级资源、形成优先级书面共识、建立统一进展与阻塞记录。
- 用事项流转时长、阻塞持续天数、接口交接按时率验证恢复，并把本次根因沉淀为接口约定或流程规则，减少同类停滞复发。
先确认卡住的是哪一类停滞
“推不动”是一种感受，排查的第一步是把它变成可以记录的事实。同样一句“这个事推不下去”，可能指向三种完全不同的停滞：事项本身没有定义清楚，谁都不知道交付什么；部门之间的接口断了，交接没有责任人也没有时限；或者决策权不在执行层，需要更高层级拍板。三类停滞的处置方式不同，混在一起讨论只会让会议变成互相解释。
建议先用一张简单的记录表把症状固定下来。记录时只写可观察的事实，不写判断和评价，例如“市场部6月3日提交的活动方案，产品部至今未反馈排期意见，已停滞9个工作日”，而不是“产品部不配合”。
| 事项 | 卡点部门 | 停滞天数 | 当前状态 | 停滞类型 |
|---|---|---|---|---|
| 活动方案排期确认 | 产品部 | 9个工作日 | 已提交，待反馈 | 接口停滞 |
| 数据口径统一 | 财务部、运营部 | 15个工作日 | 两方各持一版口径 | 决策停滞 |
| 客户资料交接 | 销售部 | 4个工作日 | 交接清单未确认 | 事项停滞 |
这张表的作用是划定排查范围。本篇讨论的是部门之间的接口与协作问题；如果停滞发生在业务产品研发链路的固定环节，或涉及供应商与外部伙伴，排查逻辑另有侧重，不在本次范围内。记录表填完后，通常能看出停滞集中在哪几个接口、持续了多久，这决定了后续排查从哪一层切入。
按五个入口逐层排查原因
排查顺序建议从事项定义开始，逐层向外。先排前两层，可以避免把管理问题误判成人员态度问题：很多“对方不配合”，实际是对方不知道要交付什么、交给谁、什么时候交。
入口一：事项目标与交付物是否清晰可验收
验证证据：找到最初的立项说明或任务描述，看是否写明了交付物形态、完成标准和验收人。如果三个人对“完成”的理解不一致，说明事项定义本身有问题。可核验的做法是请每个参与方用一句话复述自己要交付什么，复述不一致即为证据。
入口二：部门接口的责任人与交接标准是否明确
验证证据：查交接记录和会议纪要，确认每个交接环节是否有指定接口人、约定的交接时限和交接内容清单。常见证据是“邮件发过去了但没人认领”，或“交接靠群里喊一声”。接口没有责任人，事项就会停在两个部门之间的空隙里。
入口三：权限、预算、人力等资源是否到位
验证证据：核对对方给出的具体理由是否指向资源约束，例如排期已满、预算未批、缺少审批权限。注意区分“没有资源”和“资源被更高优先级占用”，前者需要调配，后者属于优先级问题。
入口四：各部门优先级与考核目标是否冲突
验证证据：对照各部门当期的目标与考核项，看被卡事项在对方清单里排第几。如果对方的核心考核与本事项无关，推进缓慢就有结构性原因，靠催办解决不了。
入口五：进展与阻塞信息是否对相关方可见
验证证据：检查进展是否有统一记录，阻塞是否被明确标注并通知到相关方。信息只存在于个别人的记忆或私聊里，其他部门就无法判断这件事是否还活着、卡在哪里。
| 排查入口 | 要回答的问题 | 可核验证据 |
|---|---|---|
| 事项清晰度 | 交付物和验收标准是否一致 | 任务描述、各方复述记录 |
| 接口明确度 | 谁接、何时接、接什么 | 交接记录、会议纪要 |
| 资源到位度 | 权限、预算、人力是否具备 | 对方书面理由、排期表 |
| 优先级一致性 | 本事项在对方目标中的位置 | 部门目标与考核清单 |
| 信息可见度 | 进展与阻塞是否被记录和通知 | 进展记录、阻塞标注 |
用证据区分假设与真实原因
排查中最容易犯的错误，是把第一个听起来合理的解释当成结论。“对方不配合”是一个假设，不是原因。每个入口都可能对应若干原因假设，排查的任务是为每个假设找到支持或排除的证据，并把结论和依据一起记录下来。
验证方式主要有三种：一是访谈，分别找接口双方各问一遍同一件事，比对说法差异；二是记录回溯，翻查邮件、会议纪要和交接记录，看事实发生的时间线；三是会议纪要核对，确认当时的决议是否写清、是否有人认领。三种方式交叉使用，比单方面陈述可靠。
排除顺序建议先排事项与接口，再排资源与优先级。原因在于：事项和接口问题属于可以通过澄清和约定直接修复的，成本低、见效快；如果先跳到资源和优先级，容易在还没确认基本定义的情况下就升级冲突。信息可见度放在最后排查，因为它常常是其他问题的放大器，而不是源头。
| 原因假设 | 验证证据 | 排除结论 |
|---|---|---|
| 交付标准不一致 | 各方复述记录出现三种说法 | 成立，需重写交付物定义 |
| 接口无人认领 | 交接记录中无指定接收人 | 成立，需指定接口人 |
| 对方人手不足 | 对方排期表显示同期三个高优项目 | 部分成立，属优先级冲突 |
| 对方态度问题 | 访谈与记录均未发现拒绝配合的证据 | 排除，不作结论 |
记录排除结论时，要写清依据来源和时间。没有证据的假设只作为待验证项保留，不写进结论，也不作为评价某个部门的依据。这一步做扎实，后续处置才有针对性，也避免在跨部门沟通中引发新的对立。
针对根因安排处置动作
排查结论不同，处置动作也不同。处置的原则是对准根因做最小必要调整，涉及变更责任人、流程或升级时，先与相关方沟通并形成书面记录，避免单方面变更引发新的接口摩擦。
- 事项不清：重写目标、交付物与验收标准，请各参与方确认后作为后续判断完成的依据。风险边界是重写范围要收敛在原事项内，避免借机扩大需求。
- 接口不明：指定每个交接环节的接口人和备份人，约定交接时限与交接内容清单。调整接口人前先与双方负责人沟通，防止出现“被换掉”的误解。
- 资源不足：把资源约束的具体证据整理后，升级到有调配权的层级决策。升级材料写事实和选项，不写对部门的评价。
- 优先级冲突：拉齐双方目标，明确本事项在各自清单中的位置，形成书面共识。共识要写明取舍，例如“本季度优先保障A，B顺延至下季度”，避免口头承诺。
- 信息不透明：建立统一的进展与阻塞记录，明确谁更新、多久更新一次、阻塞向谁升级。记录口径要在团队内事先约定，否则各写各的仍然对不上。
| 根因 | 处置动作 | 责任人 | 完成时限 |
|---|---|---|---|
| 交付标准不一致 | 重写交付物与验收标准并确认 | 事项发起人 | 3个工作日内 |
| 接口无人认领 | 指定接口人与交接时限 | 双方部门负责人 | 本周内 |
| 优先级冲突 | 拉齐目标并形成书面共识 | 共同上级或项目负责人 | 下次例会前 |
| 信息不透明 | 建立统一进展与阻塞记录 | 项目协调人 | 1周内 |
在信息可见与接口交接环节，可以把事项状态、阻塞原因和责任人集中记录在统一的工作项中，让各部门看到同一份进展。ONES的工作项状态与阻塞记录可用于承载这类信息，具体配置方式按团队实际流程确定。工具承担的是记录和呈现，根因判断和处置决策仍需由人来完成。
验证恢复并防止再次卡住
处置动作落地后，需要判断协调是否真的恢复，而不是靠一次会议上的表态。可用的验证指标包括：事项从提交到接收的平均流转时长是否缩短、阻塞持续天数是否下降、接口交接按时率是否提升。指标口径要在团队内事先约定，例如“按时”指在约定时限内完成交接并留下记录，避免事后各说各话。
恢复验证建议设一个观察周期，例如两周或一个完整的交付节点，在周期结束时对照处置前的记录做比较。如果流转速度没有改善，说明根因判断可能有偏差，需要回到排查入口重新核对证据，而不是加大催办力度。
复发预防可以从三方面入手：在关键接口设置定期同步，明确同步频率和参与人；为阻塞设置升级路径，写清什么情况下、在多长时间内升级到哪一层；把本次排查出的根因沉淀为接口约定或流程规则，例如交接清单模板、验收标准写法、优先级冲突的裁决方式。这些规则在下一次类似事项启动时直接套用，能减少同类停滞的重复发生。
- 观察期内事项流转时长是否回到约定水平
- 阻塞是否在约定时限内被记录并升级
- 关键接口是否按约定完成交接并留痕
- 本次根因是否已写入接口约定或流程规则
常见问题
排查时对方部门始终不愿提供排期和理由，怎么继续推进？
先回到可核验的记录，不依赖口头说明。查交接记录、会议纪要和邮件，确认本事项是否正式提出过、对方是否被明确告知交付要求与时限。如果记录显示事项从未正式交接，问题在接口环节，先补上书面交接再谈排期。
如果记录完整而对方仍不回应，把事实整理成简短材料，写明事项、停滞时长、已尝试的沟通方式和当前影响，提交给双方共同上级或项目负责人协调。材料只写事实和需要的决策，不评价部门态度，这样更容易推动对方给出明确答复。
五个入口排查下来发现多个原因同时存在，先处理哪一个？
按修复成本和依赖关系排序。事项定义和接口责任通常可以由当事部门直接澄清和约定，成本低、见效快，优先处理；资源和优先级问题往往需要更高层级决策，放在其后；信息可见度问题常是其他问题的放大器，可在前几项有结论后一并建立记录机制。
如果多个原因互相牵制，例如优先级冲突导致资源无法到位，就先处理优先级，把取舍写成书面共识，再据此调配资源。一次只推进一到两项处置，避免同时变更过多环节导致新的混乱。
事项已经停滞很久，重新排查会不会让相关方觉得在翻旧账？
把排查定位成恢复推进的准备，而不是追责。沟通时说明目的是确认卡在哪里、需要什么支持才能继续，请对方补充自己视角的事实和约束。记录表只写可观察事实，例如提交时间、待反馈状态和停滞天数，不写评价性描述。
排除结论也要留有余地：证据不足的假设标为待验证，不作为对部门的判断。这样既拿到排查所需信息，也降低对方的防御心理，后续处置动作更容易被接受。
处置动作落地后，观察多久才能判断协调已经恢复？
建议设一个与交付节奏匹配的观察周期，例如两周或一个完整交付节点，周期太短看不出流转变化，太长则问题可能再次积累。周期结束时对照处置前的记录比较三项指标：事项从提交到接收的平均流转时长、阻塞持续天数、接口交接按时率。
指标口径要事先约定，例如“按时交接”指在约定时限内完成并留下记录。如果指标没有改善，回到排查入口重新核对证据，确认根因判断是否偏差，再调整处置，而不是单纯加大催办力度。
跨部门协调中哪些情况不适合用这套排查方法？
这套方法针对一般部门之间的接口与协作停滞。如果停滞发生在业务产品研发链路的固定环节，排查要结合需求、排期和交付流程的具体节点；如果涉及供应商与外部伙伴，还要考虑合同约定、验收标准和外部沟通机制，排查逻辑另有侧重。
涉及组织架构调整、考核制度变更等超出单个事项范围的问题，也不适合在事项层面排查解决，需要由有相应权限的层级统一决策。判断标准是：问题能否通过澄清事项、约定接口或调配资源在现有流程内解决。
