RACI
RACI matrix
针对具体任务分别约定执行、最终负责、咨询和告知角色，并核对权限、容量与实际接受状态。
当交付跨角色协作，大家对谁做、谁对结果负责、先问谁和通知谁理解不同时使用。按任务列行，再约定R执行、A最终负责、C咨询和I告知；本页每行采用一位A以明确最终归属，可有多个R。
稳定的任务与交付、角色及权限记录、实际工作关系、需要的咨询和信息，以及各方接受和可用情况。
逐交付的RACI草案、责任空缺与权限问题、沟通触发和待确认安排。
先理解，再动手
使用步骤
每行一项交付，按R执行、A最终负责、C咨询、I告知逐项对应。本页采用一位A，可多R；审批权另核实，空缺、容量与当事人接受状态都须保留。
- 01
把工作拆成可检查的交付，固定任务编号和完成范围。
- 02
核对角色与真实权限，先确定谁能对每项结果最终负责。
- 03
逐行约定R、A、C、I；多R时明确协调方式，按本页规则每项一位A。
- 04
补充咨询与告知的触发、渠道和需另行审批的事项，检查各角色负荷。
- 05
请当事人确认并保留草案状态；范围、人员或权限变化后复查，不替他人承诺。
A不自动等于每一步的审批动作；审批权限须另有依据。R可多人，R/A可同人，但本页约定每项一位A。没有C或I可以明确写无，不为填满矩阵凑人。表中分工不代表本人接受、资源可用或已有授权；重叠、冲突和空缺需对话确认。
看清框架结构
从一份空白提纲开始
复制到你的文档，填入真实的业务事实与判断。
查看空白提纲
RACI · 空白提纲 什么时候用：当交付跨角色协作，大家对谁做、谁对结果负责、先问谁和通知谁理解不同时使用。按任务列行，再约定R执行、A最终负责、C咨询和I告知；本页每行采用一位A以明确最终归属，可有多个R。 需要准备：稳定的任务与交付、角色及权限记录、实际工作关系、需要的咨询和信息，以及各方接受和可用情况。 预期产出：逐交付的RACI草案、责任空缺与权限问题、沟通触发和待确认安排。 使用边界：A不自动等于每一步的审批动作；审批权限须另有依据。R可多人，R/A可同人，但本页约定每项一位A。没有C或I可以明确写无，不为填满矩阵凑人。表中分工不代表本人接受、资源可用或已有授权；重叠、冲突和空缺需对话确认。 工作问题： 期望结果： 已有证据与假设： 未知项与下一项核查： 填写说明：每行一项交付，各角色按相同顺序填写；保留稳定编号。 1. 任务： 填写说明：逐行写执行角色；可有多人，须确认协调与投入。 2. 执行 R： 填写说明：本页逐行写一位最终负责角色，不自动等同所有审批动作。 3. 最终负责 A： 填写说明：逐行写需征询意见的角色，无则写无；触发时间另记。 4. 咨询 C： 填写说明：逐行写需收到信息的角色，无则写无；按实际需要同步。 5. 告知 I： 填写说明：说明交付范围、审批依据、分工与接受状态。 6. 范围权限与状态： 填写说明：说明多R协调、C/I触发、容量与角色确认，保留未知。 7. 沟通容量与复查： 检查清单 □ 任务和角色逐行对应，本页每项有一位A，多R有协作说明。 □ 审批权限另有依据，C/I的触发和无参与项明确。 □ 接受状态、容量和变更复查可见，草案没有变成已获授权。 考虑下一个框架 甘特图: 责任与投入已由当事人确认后，用甘特图复查逐人容量和任务依赖；责任明确不意味着原日期自动可行。 https://bizthinkframe.com/zh/frameworks/gantt-chart BizThinkFrame · https://bizthinkframe.com/zh/frameworks/raci-matrix
跟着案例走一遍
虚构教学案例给五项试点准备交付约定责任草案
组织、人物、数据和结果均为虚构，仅用于说明框架用法。
背景与问题
虚构教学案例：松桥预约服务准备一项试点。共同底稿 F0 中，W0 同一队列有100个符合纳入条件的请求、60个确认预约、其中48个完成服务，观察均已结束。未来试点、人员投入与本页安排均未获批准或执行。
负责人被写成所有事项的审批人，联合演练也只写了开发，遗漏运营参与与角色确认。
手头有哪些材料
- F0交付A口径、B配置、C操作单、D联合演练、E试点决定，与甘特图任务编号一致。
- F0区分负责人协调与发起人试点决策权限；本表分工尚待本人确认。D需开发与运营各4小时，不是两人合计4小时。
如何使用这个框架
- 沿用A至E编号，把试点决定本身列作独立交付。
- A至D拟由负责人对结果最终负责，E按F0由发起人最终负责，负责人只准备E的材料。
- D保留开发和运营两个R，核对每人4小时；不是把责任均分后无人协调。
- C与I按每项信息需要分别列出，在检查前征询，在状态或决定变化时告知；具体渠道仍待约定。
- 保留责任草案、接受状态和容量未知，计划逐人确认后维护。
形成五行责任草案，明确D的多R与E的决策归属；没有把负责人变成所有事项的审批人，也未获得角色承诺。
每行一位A是本页的责任约定；D可有开发和运营两个R。所有分工待接受，C/I具体渠道待约定，发起人尚未批准试点。
填字母之前先核对三个条件
交付物跨多个角色、需要分清谁执行、谁对结果负责、谁提供意见、谁接收更新时，可以起草RACI。每行写一个可检查的产物。“运营”是角色，“C：可供联合复核的演练检查单”才是交付物。边界和验收条件没明确，字母并不能解决分工。
三种情况先暂停：讨论中交付范围还在变化，某人答应准备材料，其他人却理解为负责运营服务；实际权限有争议，A格不能创造采购、发布或政策审批权；拟执行者没有核对容量。表格填满、工时没确认，仍然只是草案。
本整理单每行用一个A，允许多个R但要写清协调方式；实际安排允许时同一人也可以同时R/A。C和I不必凑齐，不需要就写“无”。征询名单很长却没说需要什么、何时回复，同样会阻碍推进。触发点和渠道与字母一起记录。
先补当前缺少的协作产物
RACI表达拟议职责安排，不能替代排程、相关方调查或决策证据。哪一种缺口阻碍共识，就先解决哪一项。
| 方法 | 回答什么 | 仍需独立确认 |
|---|---|---|
| RACI | 每项产物谁执行、负责、提供意见、接收更新 | 权限、接受状态与可用容量 |
| 利益相关者分析 | 谁受影响、谁的意见或权限有关 | 实际联系及有记录的决定权 |
| 甘特图 | 依赖任务怎样排进人员容量与日期 | 分工接受状态与现实容量 |
| 决策矩阵 | 哪些可行方案符合约定偏好 | 谁能批准哪段范围 |
完整推演：A–E交付物与权限记录逐行对应
延续上方Pinebridge虚构准备案例。F0记录一批观察期完整的W0：100个合格请求、60个确认预约，其中48个服务完成。这些数只是已有教学基线，不说明未来试点已发生、改善或获批。五项交付物仍是A口径、B配置、C检查单、D联合演练、E试点决定。
逐行看原分工，不把一个角色笼统指定为整个项目的负责人。A拟由分析员执行，B由搭建者执行，C由运营执行，三行A均为负责人Lead。D由搭建者和运营共同执行，Lead对结果负责并协调。E由Lead准备决定材料，Sponsor依据F0对试点决定负责。权利来自F0，而不是表里的字母自动授予。
全部分工尚未接受。D中搭建者、运营各需4小时，合计8人小时；不等于日历上演练必然持续8小时，也不证明两人能同时提供4小时。排程仍需依赖和容量核查。下表是确认议程，不是已经联系过谁的记录。
| 交付物 | 拟R / A | 成为约定前要问什么 |
|---|---|---|
| A 口径 | 分析员 / Lead | 包含哪些定义和验收检查 |
| B 配置 | 搭建者 / Lead | 配置范围与权限覆盖什么 |
| C 检查单 | 运营 / Lead | 什么条件算可供联合复核 |
| D 联合演练 | 搭建者＋运营 / Lead | 各4小时是否可用，何时、如何协调 |
| E 试点决定 | Lead / Sponsor | 请求什么决定，F0给了哪些权利 |
把草案变成一次真实确认
可以这样发起拉通：“D目前拟由搭建者和运营共同执行，各4小时，Lead协调。请确认范围和容量，或说明冲突。拟在相关检查前征询意见，状态或决定变化时同步；具体渠道还需约定。”这是在请求确认，没有假装对方已同意。
原C/I对应关系保留：A征询运营、告知Sponsor；B征询分析员、告知运营；C征询搭建者、告知分析员；D征询分析员、告知Sponsor；E征询分析员和运营、告知搭建者。逐项确认检查前到底需要什么意见、哪些状态变化需要通知。被告知者不能悄悄变成审批人，被征询者也不能直接变成已接受的执行者。
每条实际回复带交付物ID、接受范围、容量、条件和未解决事项。“能复核，不能搭建”就原样保留差别，修改提议后再排程。范围、人员或权限改变时，重开受影响行及依赖日程。复查只有在真实回复支持的部分，才可称为职责约定更清楚；它仍不证明试点成功或基线改善。
检查你的思考
再问自己几个问题
- 这项交付到底是谁做、谁对结果最终负责？
- 这里的A是否真的拥有相应权力，哪项审批仍须另查？
- 多R怎样协调，C/I什么时候参与，分工是否已被本人接受？
完成前的检查清单
- 任务和角色逐行对应，本页每项有一位A，多R有协作说明。
- 审批权限另有依据，C/I的触发和无参与项明确。
- 接受状态、容量和变更复查可见，草案没有变成已获授权。
框架参考
参考资料说明框架定义与适用范围，不验证虚构案例的结果。