RACI矩阵编制完成后，在评审或执行中暴露职责冲突，通常指向两类缺陷：角色缺失，或审批与执行混淆。判断时逐行核对每项活动是否至少有一个R（执行）和一个A（问责），再检查批准、放行、验收等决策动作是否被错误地写成R。本文给出从症状识别、证据验证到修正与复发预防的完整路径，适用于已编制RACI、正在排查职责冲突的团队。
要点总览（TL;DR）
- 判断角色缺失，逐行核对每项活动是否至少有一个R和一个A；只有A没有R说明执行主体缺位，只有R没有A说明结果无人负责。
- 判断审批与执行混淆，看批准、放行、验收类活动是否被写成R，执行类活动是否被写成A，以及同一人兼任A与R且涉及放行时是否缺少独立复核。
- 结论不能只看矩阵表面，需用矩阵文本、评审记录、交接记录三方对照，区分填写遗漏与职责确实无人承担。
- 修正按先补角色、再拆审批与执行、最后同步记录的顺序进行；涉及已生效流程或对外承诺时先备份原矩阵并取得相关角色确认。
- 修正后用一次真实评审或执行走查验证R/A/C/I完整性，并把角色完整性检查纳入例行评审以防复发。
症状与范围：RACI矩阵在评审和执行中暴露哪些冲突
RACI矩阵在纸面上填满字母，并不等于职责已经清晰。评审或执行中出现的冲突，往往可以归入两类症状。第一类是角色缺失：某项活动在矩阵中有A但找不到R，任务布置下去无人认领；或者有R却没有A，执行者完成产出后无人拍板，事项停在半途。第二类是审批与执行混淆：批准、放行、验收等决策动作被写成R，执行动作被写成A，导致同一个人既操作又拍板，缺少独立复核。
两类症状的表现形式不同，判断入口也不同。角色缺失看的是每行字母是否齐全、承担者是否真实存在；审批与执行混淆看的是字母与动作性质是否匹配，即决策权与操作权是否落在同一角色身上。实际冲突中两者可能同时出现，例如某活动只有A没有R，同时这个A还兼任了审批与执行，需要分别核对、分别修正。
本文的范围限定在角色职责设计：判断矩阵中R/A/C/I的配置是否完整、审批与执行边界是否清晰，并给出修正与验证方法。单任务负责人如何分配、具体由谁承担更合适，属于任务分配与责任管理；人员技能是否匹配、资源如何配置，属于资源技能与匹配管理。这两类问题不在本文展开，但判断角色缺失时，需要把“矩阵填写遗漏”与“职责确实无人承担”区分开，后者会牵出人员配置问题，应转交相应管理环节处理。
原因假设与排除证据：角色缺失怎么判断
角色缺失的判断从一个基本假设出发：每项活动至少应有一个R和一个A，C与I按沟通与知情需要设置。逐行核对时，缺失的组合对应不同的职责问题。只有A没有R，说明问责有人、执行主体缺位，活动无法落地；只有R没有A，说明有人干活但无人对结果负责，验收和放行环节容易悬空；C或I缺失，则意味着关键协作方或知情方被漏掉，评审时容易出现信息不对称引发的争议。
核对不能只看矩阵表面。填写遗漏与职责确实无人承担，在矩阵文本上可能呈现相同形态，需要引入评审记录和交接记录做三方对照。评审记录能反映讨论中是否有人提出“这件事谁来做”的疑问，交接记录能反映任务是否真的流转到了某个角色手中。若矩阵缺R但交接记录显示有人实际承接，倾向填写遗漏；若矩阵缺R且评审与交接中都无人认领，则职责确实无人承担的可能性更高。
| 假设 | 矩阵文本信号 | 需调取的证据 | 倾向结论 |
|---|---|---|---|
| 填写遗漏 | 某行缺R或A，但相邻活动有相近角色 | 评审记录中的补充说明、交接记录中的实际承接人 | 补填字母并确认承担者 |
| 职责无人承担 | 某行缺R或A，且无相近角色可对应 | 评审中无人认领的记录、交接停滞或退回记录 | 需明确承担角色，可能涉及人员配置 |
| C/I漏设 | 协作方或知情方未出现在矩阵中 | 评审中信息不对称引发的争议记录 | 补充C或I并说明沟通节点 |
验证顺序建议先看矩阵文本找出所有缺R、缺A的行，再对照评审记录确认这些行是否被讨论过，最后用交接记录判断实际执行是否发生。三方证据一致时结论较可靠；证据冲突时，以实际交接记录为主要依据，因为它反映真实的任务流转，矩阵文本和评审记录都可能停留在计划层面。
原因假设与排除证据：审批与执行混淆怎么判断
审批与执行混淆的判断，核心是看动作性质与RACI字母是否对应。批准、放行、验收属于决策动作，对应A（问责），由对结果最终负责的角色承担；完成活动产出属于执行动作，对应R（执行）。当矩阵把“批准上线”写成R，或把“编写方案”写成A，就出现了错位信号：决策被降格为操作，或者操作被抬升为决策，职责边界随之模糊。
更隐蔽的情况是同一人同时承担A与R，且该活动涉及验收或放行。此时矩阵表面完整，每行都有R和A，但决策与操作由同一角色完成，独立复核缺失。判断这类情况，需要看该活动的实际交接与评审记录：产出是否经过另一角色的检查，放行决定是否有独立于执行者的确认记录。若评审记录显示验收环节由执行者自行确认，或交接记录中没有第三方复核痕迹，混淆的可能性就较高。
| 假设 | 矩阵文本信号 | 需调取的证据 | 倾向结论 |
|---|---|---|---|
| 审批被写成R | “批准”“放行”“验收”类活动标注为R | 评审记录中对该活动决策人的讨论 | 审批权归属需重新确认 |
| 执行被写成A | “编写”“制作”“实施”类活动标注为A | 交接记录中实际完成产出的角色 | 执行主体与问责主体需分离 |
| A与R同一人且涉及放行 | 同一角色同时出现在R与A列 | 验收记录、复核签字、评审中的独立确认 | 需补充独立复核角色 |
验证时把矩阵中所有涉及批准、放行、验收的活动单独列出，逐条检查其R与A是否由不同角色承担，再对照实际记录确认决策是否真的经过独立确认。矩阵文本、评审记录与交接记录三方一致指向同一角色既执行又放行时，可以判定存在审批与执行混淆；若记录显示存在未写入矩阵的复核人，则问题更可能是矩阵未及时更新，修正方向是补录而非拆分角色。
按请求提供处置步骤：修正矩阵与职责边界
确认缺陷后，修正按先补角色、再拆边界、最后同步记录的顺序进行。补齐缺失R或A时，先明确该活动的产出是什么、由谁完成、由谁对结果负责，再把对应角色填入矩阵；若评审与交接记录显示已有实际承担者，优先补录该角色，避免制造新的职责真空。补齐后检查C与I是否覆盖了评审中提出疑问的协作方和知情方。
拆分审批与执行时，把批准、放行、验收类活动从R列移到A列，并为执行动作保留独立的R角色。若原矩阵中同一人同时承担A与R且涉及放行，需要指定一名不参与执行的复核角色承担A，或在该活动下增设独立的验收节点。拆分后逐一确认每个决策动作都有明确的问责人，每个执行动作都有明确的承接角色。
修改前需要确认停止点：当矩阵对应的流程已经生效，或涉及对外承诺（如交付节点、上线计划、合同义务）时，先备份原矩阵版本，并取得受影响角色的确认后再改动。修正完成后，同步更新评审记录与交接记录，使记录中的角色与新版矩阵一致，避免出现矩阵已改、记录仍旧的两套口径。
- 备份原矩阵，标注修改日期与修改人。
- 逐行补齐缺失的R与A，核对C与I的覆盖范围。
- 将审批类活动归入A，执行类活动归入R，检查是否存在同一人兼任且涉及放行。
- 为涉及放行的活动指定独立复核角色或验收节点。
- 取得受影响角色确认后发布新版矩阵。
- 同步更新评审记录与交接记录中的角色信息。
在矩阵需要多人协同维护的场景中，可以把每项活动的R/A/C/I作为工作项的角色字段管理，评审结论和交接确认记录在同一处留痕，修改时能直接对照历史版本。ONES支持在工作项中配置角色字段并关联评审与交接记录，适合把矩阵修正与记录同步放在一条流程里完成；具体字段配置方式以团队实际使用的版本为准。
验证与复发预防：修正后如何确认恢复
修正后的验证，选一次真实的评审或执行走查即可。走查时逐行检查R/A/C/I是否完整，重点看此前缺失的行是否已有明确承担者，审批类活动的A是否与执行类活动的R分离。走查结束后对照交接记录，确认任务确实流转到了矩阵中标注的角色，审批与放行环节留有独立确认的痕迹。
验证通过的标准可以设为三条：每行至少一个R和一个A；涉及批准、放行、验收的活动由不同于执行者的角色承担A；评审与交接记录中的角色与矩阵一致。三条同时满足，说明修正已生效；任一条不满足，回到对应行继续排查，不急于发布新版。
复发预防依靠检查点机制。矩阵每次变更时，设置一道复核检查：新增或修改的活动是否补齐R与A，审批与执行是否仍由不同角色承担，C与I是否随协作关系变化更新。把角色完整性检查纳入例行评审议程，每次评审开始前用几分钟核对当期涉及活动的字母完整性，比事后追查冲突成本更低。矩阵版本与评审记录保持同步更新，也能让下一次判断有据可查。
常见问题
矩阵每行都填了字母，为什么评审时还是出现职责冲突？
字母填满只说明格式完整，不代表职责配置正确。常见情况是同一人同时承担A与R且该活动涉及放行，矩阵表面齐全，但决策与操作由同一角色完成，独立复核缺失；另一种情况是审批动作被写成R，执行动作被写成A，字母与动作性质不匹配。判断时需要把涉及批准、放行、验收的活动单独列出，逐条检查R与A是否由不同角色承担，再对照验收记录和评审记录确认决策是否经过独立确认。
矩阵缺R，怎么区分是填写遗漏还是真的没人负责？
看实际任务流转。若矩阵缺R但交接记录显示有人实际承接了该活动，倾向填写遗漏，补录该角色即可；若矩阵缺R且评审中无人认领、交接记录出现停滞或退回，则职责确实无人承担的可能性更高，需要明确承担角色，可能牵出人员配置问题。三方证据冲突时，以交接记录为主要依据，因为它反映真实的任务流转，矩阵文本和评审记录都可能停留在计划层面。
审批人同时是执行人，一定算混淆吗？
要看该活动是否涉及验收或放行。日常执行类活动中，同一人既操作又对结果负责，在团队规模较小、风险较低的场景下可以接受。但涉及批准上线、对外交付验收、合同放行等决策动作时，执行者自行确认放行会缺少独立复核，属于需要修正的混淆。修正方式是指定一名不参与执行的复核角色承担A，或在该活动下增设独立验收节点，并在记录中留下确认痕迹。
修正矩阵时，哪些情况下不能直接改？
当矩阵对应的流程已经生效，或涉及对外承诺（如交付节点、上线计划、合同义务）时，先备份原矩阵版本，并取得受影响角色的确认后再改动。直接修改可能导致流程执行与矩阵口径不一致，对外承诺的责任人也会出现争议。修正发布后，同步更新评审记录与交接记录中的角色信息，避免矩阵已改、记录仍旧的两套口径。
修正后怎么确认职责冲突真的解决了？
选一次真实的评审或执行走查，逐行检查R/A/C/I是否完整，重点看此前缺失的行是否已有明确承担者，审批类活动的A是否与执行类活动的R分离。走查后对照交接记录，确认任务确实流转到矩阵标注的角色，放行环节留有独立确认痕迹。验证标准可设为三条：每行至少一个R和一个A；涉及放行的活动由不同于执行者的角色承担A；记录中的角色与矩阵一致。三条同时满足才算修正生效。
