RACI矩阵在评审或执行中暴露职责冲突，通常不是填表不认真，而是矩阵本身存在设计缺陷。常见问题集中在：同一活动出现多个A、关键活动缺少A、审批与执行混为一人、R与C边界不清导致咨询泛滥、用部门名代替角色、活动颗粒度失衡，以及编完即归档不再维护。判断依据很直接：矩阵能否对每项活动回答“谁最终拍板、谁动手、谁必须被咨询、谁只需知情”，冲突发生时能否定位到具体单元格。
要点总览（TL;DR）
- RACI矩阵的常见设计缺陷集中在七类：同一活动多个A、关键活动缺少A、审批与执行混淆、R与C边界不清导致咨询泛滥、用部门名代替角色、活动颗粒度失衡、矩阵与真实权限脱节且编完即归档。
- 判断依据是矩阵能否对每项活动回答谁最终拍板、谁动手、谁必须被咨询、谁只需知情，以及冲突发生时能否定位到具体单元格。
- 排查按先结构后一致的顺序：先逐行统计A的数量，再核对角色名称能否指派，再看R/C/I分布，最后对照真实决策记录与一次已发生的冲突。
- 修正要按缺陷类型分别处理：多A收敛为唯一A，缺A补位，审批角色从执行中拆出，C设定必须咨询的条件，活动行按可验收交付物重切。
- 修正后用一次真实评审走查验证，并以无A活动数、多A活动数、C占比和未同步单元格数作为验收指标，配合定期复核防止复发。
症状与范围：职责冲突在矩阵里长什么样
职责冲突在会议桌上往往表现为争论，在矩阵里则表现为某个单元格写错了、写重了或写空了。把现象归位到单元格，是判断设计缺陷的第一步。以下对照表列出四类高频症状及其对应的矩阵位置。
| 症状表现 | 常见发生场景 | 对应单元格问题 |
|---|---|---|
| 同一活动多人拍板，意见不一致时无法收敛 | 方案评审、上线决策、变更审批 | 同一行出现两个及以上A |
| 活动推进到一半无人认领，或互相等待 | 跨部门交付、接口联调、文档定稿 | 该行缺少A，或A写在模糊角色上 |
| 审批人与执行人互相扯皮，审批说“我只是签字”，执行说“审批没给方向” | 质量门禁、发布审批、预算审批 | 审批角色与执行角色混填，A与R错位 |
| 每个决定都要拉一群人会签，决策周期拉长 | 需求确认、设计定稿、对外承诺 | C列过密，咨询对象缺少条件约束 |
需要区分两类问题：矩阵本身写错属于设计缺陷，修正对象是矩阵；矩阵写对但执行中没人按它行事，属于执行走样，修正对象是执行习惯与评审纪律。两者的排查入口不同——前者查单元格内容，后者查实际决策记录与矩阵的偏差。本文讨论前者。
范围上，本文只讨论角色职责设计，包括A/R/C/I的分配、角色命名、活动切分与维护机制。单任务派工、人员技能匹配、绩效归属等话题不在本文展开。
常见缺陷清单与判断依据
把评审和执行中反复出现的冲突归纳起来，RACI矩阵的设计缺陷大致有七类。每一类都可以用矩阵内容本身核对，不需要等到冲突发生才被发现。
| 缺陷类型 | 典型表现 | 判断依据 | 主要影响 |
|---|---|---|---|
| 同一活动多个A | 一行里两个部门负责人都标A，或“项目组”和“产品部”同时为A | 逐行统计A的数量，大于1即为缺陷 | 决策无法收敛，冲突时无人最终负责 |
| 关键活动缺少A | 只标了R和C，没有A；或A只写在会议主持角色上 | 逐行检查A是否为空，或A是否指向无决策权角色 | 活动无人拍板，推进停滞或反复升级 |
| 审批与执行混淆 | 审批人标为R，执行人标为A；或一人同时承担审批与执行且未区分 | 核对A是否对应最终决策权，R是否对应实际动手 | 审批流于形式，执行缺少授权依据 |
| R与C边界不清 | C列几乎每行都有多个部门，咨询缺少触发条件 | 统计C的占比，检查每个C是否有“必须咨询”的理由 | 咨询泛滥，决策变慢，责任被稀释 |
| 用部门名或岗位名代替角色 | 写“研发部”“质量岗”“相关方”，无法对应到具体人 | 检查每个角色名能否落到可指派的个人或明确岗位 | 矩阵无法执行，冲突时找不到当事人 |
| 活动颗粒度失衡 | 一行装下“完成产品上线”多个交付物；或拆到“发送会议邀请”这类无法独立指派的程度 | 检查每行是否对应一个可交付、可验收的成果 | 责任范围过大或过碎，A和R都难以界定 |
| 矩阵与组织实际权限不一致 | 矩阵写A是某岗位，实际决策由上级拍板；编完归档不再更新 | 对照近期决策记录与评审纪要，核对矩阵与实际权限的偏差 | 矩阵失去权威性，执行时被绕过 |
这七类缺陷中，前两类直接破坏“唯一拍板人”原则，是优先级最高的排查对象；审批与执行混淆、C泛滥影响决策效率；角色命名与颗粒度问题影响矩阵可执行性；权限不一致与编完即归档则决定矩阵能否长期有效。判断时不必追求一次查全，先处理会导致冲突无法收敛的缺陷。
逐项排查：从假设到证据的核对顺序
排查时把每条缺陷当作待验证的假设，用矩阵内容和执行记录取证，避免凭印象下结论。建议按以下顺序推进，先查结构性问题，再查一致性问题。
第一步，查A列。逐行统计每项活动的A数量，标记出零个A和多个A的行。这一步只做计数，不做判断，先把问题行筛出来。对于多个A的行，记录每个A对应的角色及其实际权限来源。
第二步，查角色有效性。把矩阵中出现的所有角色名列出，逐一确认能否对应到具体的人或明确岗位。出现“相关部门”“项目组”“接口人”这类无法指派的名称，标记为待规范化。同时核对同一角色在不同行是否用了不同叫法。
第三步，查R/C/I分布。按列统计R、C、I的密度，重点看C列是否存在整列空白或某几行C过多。C过多的行，逐条追问“不咨询会导致什么后果”，答不上来的即为可降为I的候选。
第四步，对照实际决策记录。抽取三到五项近期发生过的活动，调取对应的评审纪要、审批记录或决策邮件，核对实际拍板人是否与矩阵中的A一致。偏差集中出现在哪些行，说明矩阵与真实权限脱节。
第五步，回溯一次真实冲突。选一次评审或执行中已经发生的职责冲突，把冲突双方在矩阵中的位置标出来。如果冲突无法在矩阵内定位到具体单元格，说明矩阵缺少对应活动行或角色定义，属于结构性缺失。
取证方式上，抽样活动适合快速覆盖，回溯真实冲突适合验证矩阵的解释力，访谈当事人适合补充矩阵之外的隐性分工。三者结合，能区分“矩阵写错”和“矩阵没被执行”两类问题。
按缺陷类型修正矩阵
修正动作要与缺陷类型对应，避免一刀切地重写整张矩阵。以下对照表给出每类缺陷的处置方式和需要注意的风险边界。
| 缺陷类型 | 修正动作 | 风险边界 |
|---|---|---|
| 多个A | 确定唯一A，其余角色降为C或R；若确需共同决策，拆成两个活动行分别设A | 降级前与相关方确认，避免把实际决策人降成咨询对象后决策仍绕开矩阵 |
| 缺少A | 为每行指定唯一A，优先选择对该活动结果承担最终责任的角色 | 不要把所有空缺A都填给项目经理，需按活动性质分配 |
| 审批与执行混淆 | 拆出审批角色，明确其落在A（对结果拍板）还是C（提供合规意见）；执行角色保留R | 审批与执行由同一人承担时，需在矩阵中注明并说明补偿控制 |
| C泛滥 | 为每个C设定必须咨询的条件，如涉及接口变更、合规风险、预算超限；其余改为I | 降为I前确认该角色确实只需知情，避免遗漏必要的风险输入 |
| 角色名称模糊 | 统一到可指派的角色，如具体岗位加姓名，或明确到唯一责任岗位 | 角色规范化需与组织实际任命一致，避免矩阵角色与任命脱节 |
| 颗粒度失衡 | 按交付物重切活动行，一行对应一个可验收成果；过细的行合并到上级交付物 | 重切后需重新核对A/R分配，避免切分导致责任真空 |
| 权限不一致 | 以实际决策记录为准修正A，或推动实际权限向矩阵靠拢 | 涉及权限调整时需上级确认，矩阵修改不能替代正式授权 |
修改前保留旧版矩阵，记录每处变更的原因和确认人。评审中临时改口径容易引发新的争议，变更应走一次简短的确认流程，让受影响的角色知悉。修正完成后，矩阵应能对每项活动给出唯一A，并让C的出现有明确条件。
验证修正效果与防止复发
修正后的矩阵是否可用，要用一次真实评审或执行走查来验证。选取一项近期有争议的活动，按新矩阵推演一遍：能否在矩阵内找到唯一拍板人，执行人是否明确，被咨询方是否有条件约束，知情方是否只需接收信息。如果冲突仍无法定位到单元格，说明修正未覆盖该场景，需要补充活动行或角色定义。
可以用几个可核对的指标衡量修正效果：无A活动数应为零，多A活动数应为零，C的占比控制在合理范围并有条件说明，变更后未同步的单元格数为零。这些指标适合在矩阵评审时逐项过一遍，作为验收依据。
防止复发依赖维护机制。矩阵应随组织调整、流程变更和职责转移同步更新，明确维护责任人和评审时点，例如每季度或每次重大流程变更后复核一次。把矩阵与工作项、评审流程关联，让角色定义在执行中可被引用，能减少矩阵与实际执行脱节的情况。在ONES中，工作项可以承载活动与交付物，评审流程可以记录决策与知会记录，矩阵中的角色定义由此有了可对照的执行痕迹；具体承载方式需结合团队现有流程配置确认。
维护机制的关键是让矩阵成为可查、可改、可追溯的工作文档，而非一次性交付物。每次职责冲突发生后，回看矩阵对应单元格是否需要修正，把冲突转化为矩阵迭代的输入，缺陷才会逐步收敛。
常见问题
矩阵里同一活动出现两个A，评审时双方都不肯让步，应该怎么处理？
先确认两个A是否真的都拥有最终决策权。常见情况是其中一个实际只提供专业意见，应降为C；另一个才是对结果负责的人。如果确实需要两个角色共同拍板，说明这一行装了两个不同的决策事项，应拆成两个活动行，各自设唯一A。处理时保留旧版矩阵并记录变更原因，避免在评审现场临时改口径引发新争议。
矩阵写对了，但执行中大家还是绕过它，这算设计缺陷吗？
这属于执行走样，修正对象是执行习惯与评审纪律，而非矩阵内容。判断方法是抽取几项近期活动，对照评审纪要和审批记录，看实际拍板人是否与矩阵中的A一致。如果矩阵本身正确而执行偏离，需要把矩阵嵌入评审流程和决策记录中，让角色定义在执行时有据可查；如果偏差集中在某些行，则说明这些行的角色定义与真实权限脱节，仍需回到矩阵修正。
C列填了很多部门，怎么判断哪些咨询是必要的？
逐条追问“不咨询会导致什么后果”。能对应到具体风险的，例如接口变更、合规审查、预算超限，保留为C并写明触发条件；答不上来的，改为I。C过多会拉长决策周期并稀释责任，但降级前要确认该角色确实只需知情，避免遗漏必要的风险输入。修正后C的出现应当有明确条件，而非默认每行都挂几个部门。
活动颗粒度切到多细才算合适？
以一行对应一个可交付、可验收的成果为准。像“完成产品上线”这类包含多个交付物的行，应拆分为开发完成、测试通过、发布上线等独立活动；像“发送会议邀请”这类无法独立指派的动作，应合并到上级交付物中。重切后需要重新核对每行的A和R分配，避免切分造成责任真空或同一角色在多个行重复承担A。
矩阵修正完成后，多久复核一次比较合适？
复核时点可以绑定组织与流程的变化，例如每季度例行复核一次，或在组织调整、重大流程变更、职责转移后即时更新。每次职责冲突发生后，回看对应单元格是否需要修正，把冲突作为矩阵迭代的输入。维护责任人和评审时点应事先明确，否则矩阵容易再次回到编完即归档的状态。
