“这个数不对”之后最常见的下一句是“那不是我负责的”。数据质量的坑，八成不是技术问题，是责任真空：谁录入、谁把关、谁来定口径，全靠默认。这篇用 RACI 矩阵把 5 个最容易扯皮的数据事项落到具体岗位，每个事项明确 R（负责执行）、A（最终把关，有且只有一个）、C（提供咨询）、I（事后知会）四类角色。
核心方法
RACI 的用法要点有三条。第一，A 角只能有一个。A（Accountable）是最终为此负责、并有权签字的人，多个 A 等于没有 A；R（Responsible）是具体干活的人，可以有多个。第二，R 和 A 尽量分属不同岗位，负责录入的人不能同时对自己录入的数据做最终把关。第三，填岗位不填人名。矩阵挂在知识库里按岗位填写，人名会随组织变动失效，岗位不会；当前任职者另外在台账里登记。下面这张矩阵覆盖电商与跨境团队最常起争议的 5 个事项，可以直接套用。
| 数据事项 | R 负责（干活） | A 把关（签字） | C 咨询（提供口径 / 工具） | I 知会（被告知） |
|---|---|---|---|---|
| GMV 口径定义 | 运营主管 | 财务负责人 | 数据 / IT | 全体报表使用人 |
| 库存准确率 | 仓库主管、物流专员 | 供应链负责人 | 数据 / IT、运营主管 | 财务、采购 |
| 费用归集规则 | 财务专员 | 财务负责人 | 数据 / IT、各业务主管 | 业务负责人 |
| 退款口径 | 客服主管、运营主管 | 财务负责人 | 数据 / IT | 投放负责人 |
| 渠道归因 | 投放负责人 | 业务负责人 | 数据 / IT、运营主管 | 财务、客服主管 |
实践要点
- R 负责：谁产生数据谁负责录入质量。运营主管管 GMV 口径的执行，仓库主管管库存准确率，源头错了后面再准也没用。
- A 把关：业务负责人对关键指标口径签字。GMV、退款、费用归集三项由财务负责人把关，因为最终要对账。
- C 咨询：数据 / IT 提供口径说明与工具支持，但不替业务做决定。IT 的角色是“说清楚怎么算”，不是“决定怎么算”。
- I 知会：报表使用人对异常有知情与反馈渠道。口径变更、异常修复后，必须通知到 I 列的岗位。
- 一个事项一张口径卡：矩阵里的每一行单独配一张口径卡，写清公式、数据来源、变更记录。矩阵负责“找人”，口径卡负责“说理”。
- 每季度复核一次：组织架构和分工会变，矩阵至少每季度过一遍，岗位名称与实际不符的当场改。
怎么用起来
第一步，先把团队近半年为数据吵过架的事项列出来，通常能列 5-10 条，挑最痛的 5 条建第一版矩阵。第二步，逐条填 R / A / C / I，争执不下的当场由业务负责人拍板，不要拖。第三步，把矩阵挂进公司知识库，并在数据异常 SOP 里引用它——异常发生时按矩阵找人，而不是临时拉群问。第四步，给每个 A 角配一张口径卡，把签字过的公式固化下来。
边界与常见坑
适用于 20 人以上、职能有明确分工的团队；10 人以下的初创团队往往一人身兼数职，R 和 A 很难分开，建议只保留 A 角。常见的坑：一是一个格子塞太多岗位，C 列填了五个部门，咨询变成会签，一件事卡两周——C 列建议不超过 3 个；二是A 角空缺或只填部门名，“财务部”不是 A 角，“财务负责人”才是；三是矩阵做完就束之高阁，日常找人还是靠喊，解决办法是把 R/A 字段直接嵌进异常工单模板。另外，RACI 解决的是责任划分，不能替代数据标准本身——如果 GMV 该怎么算从没定义清楚，R 和 A 都填上了也还是会各说各话。
分类：实施 / 检查清单 ｜ 完整方法论与配套模板随项目交付，可联系获取。