跨部门协作中责任悬空，往往源于先分部门、后议事项。更稳妥的顺序是先把协作拆成可验收的交付物，再用责任矩阵为每项交付物指定唯一负责人，接着把交付要求写成含质量门槛和验收人的约定，最后通过启动、执行、验收三个节点让约定真正运行。本文给出一套可直接套用的责任矩阵、交付要求字段和完成检查清单。
要点总览（TL;DR）
- 责任划分从交付物开始：先把协作拆成可验收、可交接、单一归属的交付物，再谈谁负责。
- 用责任矩阵为每项交付物锁定唯一最终负责人（A），执行人、被咨询方、被通知方按需设置，避免全员参与。
- 交付要求字段化：内容范围、格式、质量门槛、时间点、提交方式、验收人，质量门槛写成可判断的条件。
- 按启动、执行、验收三个节点明确各角色的输入、动作、输出与完成标志，让约定真正跑起来。
- 首次协作后用检查清单逐项核对，并复盘更新矩阵中角色不清、门槛模糊的条目。
先定交付物，再定责任人：跨部门责任划分的起点
责任划分的起点是交付物，部门职能只是背景信息。跨部门协作出现推诿，常见原因是讨论停留在“市场部负责推广、产品部负责需求”这类职能分工上，而没有人说清楚这次协作到底要交出什么、交给谁、什么算合格。以交付物为单位划分责任，每个事项都有明确的产出和接收方，责任才有附着点。
拆解交付物时，可以按三个标准判断粒度是否合适：可验收，即接收方能够依据明确条件判断合格与否；可交接，即交付物能够从一方完整转移到另一方，不依赖交付方的持续在场；单一归属，即每项交付物对应一个主要产出方，避免多人共同“负责”同一件事。粒度太粗会出现“一份方案”这类无法验收的条目，太细则会退化成任务清单，失去协作层面的意义。
常见的拆错方式是按部门分工直接列责任，例如“技术部提供技术支持”“运营部配合活动”，这类表述没有说明支持的形式、时间和接收对象，执行时容易悬空。另一种是把多个部门的共同产出写成一项交付物，结果谁都认为对方在推进。遇到这种情况，应继续拆分，直到每项交付物都能落到一个主要产出方。
完成这一步的产物是一份跨部门协作交付物清单，至少包含四列：交付物名称、来源部门（主要产出方）、接收方、验收标准初稿。验收标准初稿可以先用一句话描述“接收方拿到后能做什么”，后续在交付要求中细化。
用责任矩阵锁定每个交付物的角色
交付物清单确定后，用责任矩阵把每项交付物对应的角色固定下来。RACI 是常用的四类角色划分：R（执行人）负责实际完成工作；A（最终负责人）对结果负责并拥有决定权；C（被咨询方）在过程中提供专业意见；I（被通知方）接收进展和结果信息。跨部门场景中，可以根据协作复杂度简化，例如只保留负责人、执行人和知会方三类，但“每项交付物只有一个最终负责人”这条规则应当保留。
唯一负责人是矩阵的核心规则。若一项交付物出现两个 A，遇到分歧时无人能拍板；若没有 A，则出现问题时找不到承担责任的人。A 不一定是动手做事的人，但必须是对交付结果签字确认、能够调动资源解决阻塞的人。R 可以有多个，但应明确各自负责的部分。
C 和 I 的使用需要设边界。C 适用于其意见会实质影响交付质量的角色，例如法务对合同条款、财务对预算口径；I 适用于只需要知晓结果、不需要参与过程的角色。把无关人员全部列为 C，会导致每个决策都要多轮征询；把应该被咨询的角色只列为 I，则可能在验收阶段才发现方向错误。
矩阵按交付物逐行填写，建议字段包括：交付物名称、A（姓名与岗位）、R（姓名与岗位）、C、I、职责说明。填写时常见的错误包括：把部门名称填进角色栏而没有具体到人；同一人同时担任 A 和 R 却不说明决策与执行如何区分；C 栏列出整个部门。下面是一个填写示例：
| 交付物 | A（最终负责人） | R（执行人） | C（被咨询方） | I（被通知方） |
|---|---|---|---|---|
| 季度销售数据报表 | 销售运营经理 | 数据分析专员 | 财务BP、区域销售负责人 | 销售总监 |
| 报表口径说明文档 | 财务BP | 数据分析专员 | 销售运营经理 | 销售总监 |
矩阵填写完成后，应组织一次简短的角色确认，让每个 A 明确自己签字确认的范围，让 C 明确需要在什么时间点给出意见。确认记录本身也是一份可追溯的协作依据。
把交付要求写成可验收的约定
责任矩阵回答“谁负责”，交付要求回答“交成什么样算合格”。口头承诺容易在验收时产生分歧，把要求字段化可以让双方在开始前就对齐判断标准。每项交付物建议填写以下字段：内容范围、格式、质量门槛、时间点、提交方式、验收人。
质量门槛是最容易写虚的字段。“数据准确”“内容完整”“格式规范”这类形容词无法直接判断，应改写为可检查的条件。例如把“数据准确”写成“报表数据与财务系统当期数据逐项核对一致，差异项需附说明”；把“内容完整”写成“覆盖约定的五个分析维度，每个维度至少包含一项结论和一条建议”。质量门槛写得越具体，验收时的争议越少。
变更与延期也需要在约定中写明处理路径。可以约定：交付内容或时间发生变更时，由 A 发起变更说明，写明变更原因、影响范围和新的时间点，经接收方确认后生效；预计延期时，R 在约定时间点前告知 A 和接收方，说明原因和补救安排。没有这条约定，延期往往变成事后解释。
交付要求与责任矩阵需要对应起来：每项交付物在矩阵中有一行角色，在交付要求中有一份字段说明，两者使用同一交付物名称，验收人通常就是接收方中承担确认职责的人。这样在验收阶段可以直接按字段逐项核对，而不必重新讨论标准。
角色分工与各环节交付物
责任矩阵是静态的角色表，协作真正跑起来还需要在启动、执行、验收三个节点上明确各角色做什么、交出什么。下表按节点列出输入、动作、输出与完成标志，可作为协作过程中的对照依据。
| 节点 | 角色 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|---|
| 启动 | 协作发起方 | 协作背景、目标、涉及部门 | 编写协作说明，拆解交付物清单，起草责任矩阵 | 协作说明、交付物清单、责任矩阵初稿 | 各交付物的 A 确认接受角色 |
| 启动 | 各交付物 A | 责任矩阵初稿 | 确认职责范围，指定 R，提出 C 和 I 名单 | 确认后的责任矩阵 | 矩阵中每项交付物角色齐全且唯一 A |
| 执行 | 执行人 R | 交付要求说明 | 按约定推进，遇到阻塞及时上报 | 过程进展、阶段性产出 | 按时间点提交或提前发出延期说明 |
| 执行 | 最终负责人 A | 进展信息、阻塞上报 | 协调资源处理阻塞，审批变更 | 阻塞处理记录、变更说明 | 阻塞有明确处理结论，变更经接收方确认 |
| 验收 | 验收方 | 交付物、交付要求说明 | 按质量门槛逐项核对，给出通过或退回结论 | 验收结论、退回意见 | 结论明确，退回意见指向具体字段 |
| 验收 | 最终负责人 A | 验收结论 | 对退回项安排整改并重新提交 | 整改后的交付物 | 验收方确认通过 |
三个节点中，启动阶段的对齐最容易被省略。发起方把协作说明和责任矩阵初稿提前发出，让各 A 在正式开工前确认角色，可以避免执行到中途才发现某项工作无人认领。验收阶段的退回意见应指向交付要求中的具体字段，而不是笼统评价，这样整改才有明确方向。
当协作事项需要在工具中持续跟踪时，责任矩阵和交付约定可以承载为工作项：每项交付物对应一个工作项，负责人字段对应 A，参与人对应 R 和 C，验收状态对应验收结论。ONES 提供统一的需求池、工单与任务看板，可实时同步状态与信息，便于跨角色追溯交付进展；其项目制管理方式支持对里程碑和交付物进行管控，适合需求明确、交付周期固定的协作场景。工具承载的是规则运行后的状态记录，规则本身仍需在启动前定义清楚。
示例：一次跨部门数据报表协作的责任与交付约定
以下示例为演示情景，用于说明方法如何落地，可根据实际组织调整。背景：销售部门需要在季度经营会前拿到一份区域销售分析报表，数据来自销售系统，口径需与财务对齐，报表由数据分析团队制作，销售运营团队负责验收。
第一步拆解交付物。协作产出被拆为三项：区域销售数据报表、报表口径说明文档、经营会汇报要点。每项交付物标注来源部门、接收方和验收标准初稿。例如报表的验收标准初稿为“覆盖五个区域，数据可与财务系统核对，经营会可直接使用”。
第二步填写责任矩阵。报表的 A 为销售运营经理，R 为数据分析专员，C 为财务BP和各区域销售负责人，I 为销售总监；口径说明文档的 A 为财务BP，R 为数据分析专员，C 为销售运营经理；汇报要点的 A 为销售运营经理，R 为销售运营专员。三项交付物各自只有一个 A，角色不交叉重叠。
第三步写交付要求。以报表为例：内容范围为五个区域的销售额、回款、客户新增与流失；格式为 Excel 明细加一页汇总；质量门槛为各区域数据与财务系统当期数据核对一致，差异项附说明，汇总页每个区域至少一条结论；时间点为经营会前三个工作日；提交方式为共享目录加邮件通知；验收人为销售运营经理。口径说明文档同样按字段填写，质量门槛写为“每个指标注明取数来源、计算方式和适用期间”。
第四步运行与验收。执行过程中，数据分析专员发现某区域回款数据存在系统延迟，按约定在时间点前向 A 发出延期说明，A 与验收方确认后将该项数据标注为“待补”，其余部分按期提交。验收时销售运营经理按质量门槛逐项核对，发现汇总页缺少两个区域的结论，退回并要求补充；补充后再次验收通过。整个过程的责任归属、变更处理和退回意见都有记录，可作为下次同类协作的参照。
完成检查：责任与交付约定是否真的落地
机制是否建立，可以用一份检查清单逐项核对。以下条目适用于一次跨部门协作启动后、首次交付验收前后的自查。
- 交付物清单中的每一项都有明确的接收方和验收标准初稿，没有“配合支持”这类无法验收的条目。
- 责任矩阵中每项交付物只有一个 A，A 已确认接受该角色，R、C、I 均具体到人。
- C 的名单经过筛选，只包含意见会实质影响交付质量的角色；I 只包含需要知晓结果的角色。
- 每项交付物都有字段化的交付要求，质量门槛写成可判断的条件，验收人明确。
- 变更与延期的处理路径已写入约定，包括由谁发起、向谁确认、何时告知。
- 启动阶段各 A 已完成角色确认，确认记录可查。
- 验收结论明确为通过或退回，退回意见指向具体字段。
- 首次协作结束后进行了复盘，对矩阵中角色不清、门槛模糊的条目进行了更新。
检查中发现的问题应当回到对应环节修正：交付物拆解不清就重新拆分，角色重叠就调整矩阵，门槛写虚就改写交付要求。责任与交付约定不是一次写完的文档，而是在每次协作后逐步校准的管理依据。
常见问题
跨部门协作中，一项交付物由两个部门共同产出，责任怎么定？
共同产出通常意味着交付物拆得不够细。建议继续拆分，直到每项交付物能落到一个主要产出方，再为每项指定唯一的最终负责人（A）。如果确实无法拆分，可以约定由其中一方担任 A，另一方作为执行人或被咨询方，并在职责说明中写清各自负责的部分和确认方式。两个 A 并存会让分歧无人拍板，应尽量避免。
责任矩阵用完整 RACI 还是简化版更合适？
取决于协作复杂度和参与方数量。参与方多、意见会实质影响交付质量的场景，完整 RACI 能把咨询和知会分开，减少无效征询；参与方少、流程简单的协作，可以只保留负责人、执行人和知会方三类。无论哪种版本，每项交付物只有一个最终负责人这条规则都应保留，否则矩阵就失去了锁定责任的作用。
交付要求写好了，执行中还是出现延期和返工，问题通常出在哪？
常见原因有三类：质量门槛仍停留在形容词层面，验收时双方理解不一致；变更与延期的处理路径没有写进约定，延期变成事后解释；启动阶段省略了角色确认，执行到中途才发现某项工作无人认领。可以回到对应环节修正：把门槛改写为可检查的条件，补充变更发起与确认的约定，并在开工前让各 A 确认职责范围。
责任矩阵和交付约定需要放到协作工具里吗？
当协作事项需要持续跟踪、参与方较多时，把每项交付物承载为工作项会更便于追溯：负责人字段对应 A，参与人对应执行人和被咨询方，验收状态对应验收结论。ONES 提供统一的需求池、工单与任务看板，可实时同步状态与信息，便于跨角色追溯交付进展；其项目制管理方式支持对里程碑和交付物进行管控，适合需求明确、交付周期固定的协作场景。工具承载的是规则运行后的状态记录，规则本身仍需在启动前定义清楚。
一次协作结束后，责任矩阵还需要维护吗？
需要。首次协作结束后建议做一次简短复盘，重点看三类条目：角色重叠或空缺的、质量门槛在验收时产生争议的、变更处理没有走约定路径的。把复盘结论回填到矩阵和交付要求中，下次同类协作可以直接复用。矩阵是逐步校准的管理依据，一次写完就不再更新，容易与实际情况脱节。
