RACI矩阵：区分执行、最终负责、征询与知会

会上说人人负责，工作结束时却找不到能够确认结果的人；另一种情况是任何细小问题都要等待领导签字，执行者几乎没有判断空间。责任不清和批准过多，看起来相反，却都可能来自角色作用没有被区分。RACI矩阵帮助团队把执行、最终负责、提供意见与接收信息分别写清。

知行社为教练家整理RACI在跨部门协作中的应用。四个字母分别对应Responsible、Accountable、Consulted和Informed，本文用执行责任、最终负责、征询意见和知会表达。它是责任分配的表达方式，需要配合工作定义、正式授权与信息安排使用，不是仅填字母就能提高效率的保证。

先解释四种作用的工作含义

R代表实际完成工作的人或角色。若需要多位执行者，应说明分工与整合方式，不能把几个人都写上R以后就认为工作会自然合起来。执行者需要任务边界、必要输入和资源条件，单个字母无法提供这些信息。

A代表对该项结果承担最终责任的角色。企业可以约定其包含批准或接收责任，但不能默认所有A都具有任意预算、合同或专业批准权。具体权限仍来自组织授权。A与R可以由同一角色承担，但需要符合工作风险及独立审查要求。

C代表在行动或决定前需要征询意见的角色。意见需要被真正接收和处理，不是将对方列进抄送名单。征询可以提供专业判断、使用条件或影响说明，意见不自动等于最终决定，遇到冲突仍需明确正式取舍入口。

I代表需要获知进展或结果的角色。知会通常是信息送达安排，不要求其参与每一步决定。明确什么变化需要通知、通过哪个入口、是否需要确认接收，避免通知范围越扩越大，每个人反而无法辨认与自己有关的信息。

每行先选一个明确的结果

RACI的行可以是成果、活动或决定，但同一份矩阵尽量保持适当一致。把“整个项目”与“发一封邮件”混在一起，层次差异过大，难以判断责任。优先选择容易产生交接或权限争议的工作，再按需要展开。

例如“批准培训材料”和“实施培训”是不同工作。前者需要内容与适用性判断，后者需要现场组织与实际执行。若合为一行，A究竟对内容批准还是对活动实施负责，成员可能各自理解。必要拆分能让作用明确，但不必为每次点击都创建责任行。

结果需要有完成标准。若一项工作写为“与客户沟通”，无法确定什么时候完成，可以改成“确认客户上线条件并形成有效记录”。随后核对谁执行、谁接收最终结果、哪些专业意见必须先取得，以及谁需要知会。

用单一A减少最终责任歧义

在一般团队应用中，每行设置一个清楚的A，是帮助减少最终责任歧义的设计原则。这里强调的是单一可识别的接收点，不是宣称所有制度场景都只能有一个批准角色。若法规、合同或组织安排要求多层批准，必须沿用相应要求。

复杂事项可以拆开不同决定，例如业务批准、专业审核和正式验收各自成行，或在工作说明中列出批准链。这样既保留必要责任，也避免用一排A掩盖谁在什么条件下最终接收什么结果。

出现无人愿意承担A时，先检查权限与支持，而不是要求成员更加主动。有的人可以执行，却不能批准；有的人名义上负责，却无法影响关键资源。需要由正式管理角色确认安排，教练不能通过主持讨论自行赋予权限。

同样，A不能成为包办全部细节的理由。执行者在已有授权内可以判断，C提供必要输入，A接收最终责任。若A要求所有日常动作都请示，检查是风险需要还是信任和边界不清，再由正式角色调整授权。

R的分工需要能够真正拼合

多个R适用于确有共同执行需要的工作，但应说明各自负责部分、交接和整合责任。否则每位执行者都可能完成局部内容，最终无人形成可接收成果。把“大伙共同完成”转成具体工作关系，才有实际意义。

只有一个R也不自动表示工作合理。这个人可能缺少必要技能、信息或时间，继续核对资源。RACI可以提示责任结构，不能代替能力支持、任务估算和实际负荷管理。管理者需要回应成员提出的条件限制。

R与A之间约定何时需要报告、什么变化需要重新决定。执行者发现输入不完整时应知道向谁提出，A也需要及时接收，而不是到最后验收时才发现全部问题。报告机制应与任务风险相称，避免每个小动作都变成审批手续。

C应有意见入口和回应安排

减少不必要的C，能让决定更集中，但删去必要专业角色可能造成更大损失。判断依据是这项工作需要什么信息，而不是谁在组织中更有影响力。技术、使用、维护和受影响群体的意见可能不同，必须考虑具体事项。

征询请求说明问题、可参与范围、材料和最迟反馈时点。若对方不回应，先确认请求送达与资源条件，再根据正式安排决定怎样继续。不能偷偷把沉默视为同意，也不能无限等待，让一项意见请求变成没有期限的否决权。

收到意见之后说明如何处理。采用、部分采用、暂缓或未采用都可以有理由。对于必须满足的专业条件，不应只当作可选择建议；对于偏好差异，不能假称具有强制效力。必要时让有权限的角色判断其性质和取舍。

I应获得足够且适时的信息

知会对象需要知道与其工作有关的变化，不一定需要全部过程材料。通知可以包含有效结果、影响、接续动作和提问入口。信息太多会造成寻找成本，太少则让接收者无法安排下一步，按实际用途决定详略。

重要变化如果需要接收者采取行动，不能只靠群发邮件证明已经通知。设置适当接收确认，说明谁核对遗漏。若对方需要参与决定，其作用可能应调整为C或其他正式角色，不把知会名单当作参与承诺。

保密资料按组织要求控制范围。RACI中的I不是自动获得所有客户信息的许可。为不同角色提供完成工作所需的信息，同时维护有效版本，避免同一个决定在不同通知里出现矛盾表达。

虚构案例：服务上线审批为何不断返工

以下为教学虚构。一个企业服务团队准备上线新套餐，产品、销售、客服和运营都被写为“共同负责”。产品完成说明，销售开始对外沟通，客服发现例外服务不在现有能力范围内，运营则认为上线时间还没有正式批准。

团队教练邀请成员拆成套餐范围确认、服务说明制作、例外接收安排和上线批准等工作。每行先写结果与标准，再填角色。这样“共同负责”被拆成不同作用，而不是直接选一个部门承担所有问题。

产品承担说明制作的R，业务负责人承担范围确认的A，客服和运营在服务条件形成前提供C，销售在有效范围确认后获得I。涉及客户承诺的正式沟通另列工作，避免销售把知会信息直接理解为可以自行改变服务条款的授权。

团队发现例外接收安排没有可用负责人，于是暂不将该项标成已经落实。有权限的管理者确定接收角色与支持条件，随后才形成有效矩阵。教练支持作用澄清，不替管理者签署上线批准。

用下一次演练核对，客服能够说明何时提供意见，销售能找到有效版本，但上线批准仍依赖一个未完成的专业检查。团队保留这一条件，调整安排，没有用矩阵齐全证明项目已经可上线。案例展示RACI如何揭示责任缺口，不代表所有服务项目都采用同样角色配置。

在工作坊中先讨论理解，再填字母

准备两三个容易产生争议的任务，让各角色先独立说明自己认为谁执行、谁最终负责、谁应被征询和知会。对比差异时问依据什么有效约定，不以多数票决定权限，也不让职位最高的人未经核对替所有人承诺。

教练帮助成员区分“不知道谁负责”和“知道但没有资源”。前者可能需要澄清，后者需要真实管理取舍。若工作坊只完成表格，没有处理关键限制，矩阵会把问题隐藏得更整齐，而无法改善协作。

确认后的矩阵需要由有关角色正式接收。对于未决格保留状态和决定入口，不能为了交付一张漂亮表格临时填入人名。若授权安排尚未获得批准，说明何时可以形成有效版本和此前如何处理工作。

修改矩阵时检查对真实工作的影响

新成员加入、范围改变或项目进入下一阶段，都可能改变RACI。更新不是简单增加一列，把每项工作都标上I。先核对新角色为什么需要参与、拥有何种权限和接收什么结果，再决定作用。

某个C转成R，意味着实际工作量与责任发生变化；某个A更换，意味着最终接收入口变化。这些变化需要资源与信息交接，不能只修改文件。由负责维护者通知相关角色，保存当前有效版本和必要的变更理由。

不要为每次临时帮助修改全部矩阵。成员可以在边界清楚的情况下互相协助，关键责任变化才进入正式更新。临时代理若涉及批准或持续承担工作，则需要确认范围和期限，避免帮助者在无意中接收长期责任。

让矩阵服务工作，而非替代判断

RACI不能涵盖所有伦理、专业和组织要求。遇到高风险例外，要使用适当制度与专业判断，不能因为格子写着某个人负责就认为其他角色没有必要报告。也不能用“我是I”作为忽略已知重大问题的理由。

定期用实际交接检验矩阵：执行者有没有获得必要输入，A是否及时接收决定，C的意见是否在适当时点进入，I是否能够安排后续工作。关注这些行为，比统计RACI填满比例更有价值。

知行社建议教练家读者先选一项经常返工的工作，明确结果与权限，再共同确认四种作用。好的RACI让执行者能够执行、负责者能够接收、意见进入判断、信息支持接续，而不是让每个人忙于证明自己对应哪个字母。