多个支持团队共同受理员工请求时，职责重叠和无人负责往往同时出现：一件事几个人都在跟，另一件事谁都不认领。用RACI明确分工，核心是把员工请求拆成可管理的支持事项，为每类事项逐项填写R、A、C、I四类角色，再经过评审、发布和定期复核，把矩阵变成可执行的分工约定。落地步骤为：界定支持事项清单、识别参与角色、逐项分配RACI、校验每项只有一个A、评审确认、发布到受理入口、按周期复核调整。
要点总览（TL;DR）
- RACI在内部支持中约束的是职责归属：R负责实际处理，A对结果最终兜底且每类事项只设一个，C在决策前提供意见，I在结果或关键节点被同步；它不替代工单流转和事件恢复流程。
- 落地步骤为：界定支持事项清单、识别参与角色、逐项分配RACI、校验每项只有一个A、评审确认、发布到受理入口、按周期复核调整。
- 支持事项的粒度以员工可识别的请求类型为单位，先控制在15至30类，覆盖大部分请求量，长尾事项归入“其他”并单独指定负责人。
- 填写时每行先定A再定R，最后补C和I；出现多个A时按结果由谁最终兜底保留一个，其余改为C或R，争议上移共同上级裁定。
- 矩阵要发布到员工实际发起请求的入口，并明确复核责任人与周期，才能从文档变成可执行的分工约定。
RACI在内部支持分工中解决什么问题
RACI是一张职责分配表，它回答的是“这件事谁做、谁最终负责、决策前问谁、结果通知谁”。在内部支持场景中，四个字母的含义需要落到员工请求的处理动作上，才能被各团队理解和执行。
| 角色 | 在内部支持中的含义 | 典型动作 |
|---|---|---|
| R（执行者） | 实际动手处理请求的人或团队 | 接单、排查、操作配置、回复员工 |
| A（最终负责人） | 对这类事项的结果最终兜底的人，每类事项只设一个 | 确认处理方案、决定升级、对结果签字 |
| C（被咨询者） | 在决策或处理前需要提供意见的角色 | 提供系统约束说明、安全合规意见、历史处理经验 |
| I（被通知者） | 结果或关键节点需要被同步的角色 | 接收处理完成通知、知晓变更影响 |
需要区分的是，RACI约束的是职责归属，工单流转和事件恢复流程解决的是请求如何被受理、分派、处理和关闭。两者配合使用：流程决定请求走哪条路径，RACI决定路径上每个环节由谁负责、出问题时找谁。矩阵填得再完整，也不能替代工单状态流转和升级机制。
RACI最适合的场景，是多个支持团队共同受理员工请求、事项边界容易模糊的时候。单一团队受理全部请求、职责天然清晰的小型组织，可以先从高频、跨团队的事项做起，不必一次覆盖所有请求类型。
第一步：界定支持事项清单
RACI矩阵的行是支持事项，行划分得是否合理，直接决定矩阵能否用起来。事项清单的输入是现有的工单分类、请求类型和历史受理记录，做法是把员工实际发起的请求归纳成稳定的类别，输出一份带字段的事项清单。
粒度判断有两个实用标准：如果一类事项经常需要拆给不同团队分别处理，说明粒度过粗，应拆成更具体的事项；如果两类事项的受理入口、责任团队和升级路径完全一致，可以合并，避免矩阵行数膨胀后无人维护。一般建议先控制在15至30类事项，覆盖大部分请求量，长尾事项归入“其他”并单独指定负责人。
| 字段 | 填写说明 | 示例 |
|---|---|---|
| 事项名称 | 员工能看懂的说法，避免内部术语 | 业务系统权限申请 |
| 触发场景 | 什么情况下员工会发起这类请求 | 新入职、转岗、临时项目需要访问 |
| 涉及团队 | 当前实际参与处理的团队 | 服务台、应用支持组、系统负责人 |
| 当前受理入口 | 员工现在从哪里提交 | 服务台电话、OA表单、邮件 |
| 月均请求量 | 用于排优先级，可估算 | 约80单 |
清单完成后，由服务台负责人组织一次快速核对，确认没有遗漏高频请求类型，也没有把同一件事拆成多行。这份清单就是后续填表的输入。
第二步：识别参与角色并统一角色口径
角色要按岗位或团队定义，不按个人姓名定义。用姓名填表，人员一变动矩阵就失效，也无法向新员工解释分工。常见角色包括服务台、一线支持、二线专业团队、系统负责人和业务接口人，各组织可按实际设置增减。
| 角色 | 职责定位 | 通常参与的事项 |
|---|---|---|
| 服务台 | 统一受理、初步分类、进度跟踪 | 全部事项的受理环节 |
| 一线支持 | 处理标准化、可重复的请求 | 账号开通、软件安装、基础配置 |
| 二线专业团队 | 处理需要专业技能的请求 | 网络、数据库、应用系统问题 |
| 系统负责人 | 对特定系统的变更和权限做最终判断 | 系统权限、配置变更、上线相关 |
| 业务接口人 | 代表业务部门确认需求和影响 | 涉及业务规则、数据可见范围的事项 |
角色清单确定后，与第一步的事项清单做一次对应：每类事项列出可能参与的角色，形成“事项—角色”对应表。这张表不必精确到RACI，只用于确认填表时不会漏掉关键角色，也为下一步逐项分配提供范围。
第三步：逐项填写RACI并校验唯一A
填写时按事项逐行推进，每行先确定A，再确定R，最后补C和I。先定A的原因是：最终负责人决定了这类事项的结果由谁兜底，R和C的分配都要围绕这个判断展开。判断依据可以问三个问题：这类事项处理失败时谁被追责、谁有权决定升级和例外处理、谁最了解这类事项的完整处理链路。
唯一A是硬性校验规则。逐行检查矩阵，一行出现两个及以上A时，按“结果由谁最终兜底”来判断保留一个，其余改为C或R；两个团队都认为自己是A且无法达成一致时，上移到共同上级裁定，裁定结果写入矩阵备注。跨团队事项中，A通常归口于对系统或服务整体负责的岗位，而不是处理量最大的团队。
另外两条原则帮助控制矩阵质量：R与A尽量分离，同一角色既执行又最终负责时，要确认是否有独立的复核机制；C和I的数量要控制，C过多会让决策变慢，I过多会让通知失去意义，每行C一般不超过两个、I按实际需要保留。
| 校验项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 唯一A | 每行有且仅有一个A | 按兜底责任保留一个，其余改C或R；争议上移裁定 |
| R存在 | 每行至少有一个R | 补充执行角色，或确认该事项是否应合并 |
| C数量 | 每行C不超过两个 | 合并意见来源，改为事后知会 |
| 角色覆盖 | 矩阵中的角色都在角色清单内 | 补充角色定义或修正填写 |
这一步的输出是填好的RACI矩阵初稿和一份校验记录，记录每处调整的原因，便于评审时解释。
第四步：评审确认与发布到受理入口
矩阵初稿需要经过相关团队确认，否则容易在執行阶段被推翻。评审参与方包括各支持团队负责人、服务台负责人和主要业务接口人，确认方式建议采用集中评审会逐行过表，重点确认A的归属和C的必要性，会议结论形成评审记录，有异议的行标注待定并指定裁定人。
发布位置要选在员工实际发起请求的地方：工单分类说明中标注每类事项的责任团队，受理表单中展示处理团队和预计响应时间，知识库的服务目录页面列出事项、责任团队和升级路径。发布内容至少包括事项名称、A所在团队、R所在团队和升级联系人，让员工提交请求时就能看到谁会处理、找谁催办。
矩阵发布后，工单分类与矩阵行保持一一对应，新增工单分类时同步更新矩阵，避免出现员工能提交但矩阵中没有对应责任人的事项。
在协作工具中承载这套分工时，可以把支持事项建成工单分类，把责任团队和升级路径写入分类说明，让员工提交时直接看到。ONES Desk 面向企业服务与协作场景，可用于内部支持等场景，支持自定义工单属性以适配不同收集场景，并支持集中管理工单状态、处理进度和责任分工；工单还可关联到 ONES Wiki 页面，便于把矩阵说明和服务目录沉淀为可查阅的文档。矩阵本身是否以原生模板形式提供，选型时可向厂商确认。
第五步：按周期复核与调整
RACI矩阵是活的分工约定，需要维护机制才能保持有效。复核分两类：常规复核按季度或半年进行，由服务台负责人牵头，检查矩阵行是否仍覆盖主要请求类型、A的归属是否随组织变化而失效；专项复核在触发条件下启动，包括组织调整、新系统上线、工单积压明显增加或转派异常增多。
| 复核类型 | 触发条件 | 责任人 | 输出 |
|---|---|---|---|
| 常规复核 | 每季度或每半年 | 服务台负责人 | 复核记录、调整清单 |
| 专项复核 | 组织调整、新系统上线、积压或转派异常 | 受影响事项的A所在团队 | 调整后的矩阵行与发布更新 |
调整完成后要同步三个动作：更新工单分类和受理表单中的责任团队信息、更新知识库服务目录页面、通知受影响的团队和业务接口人。调整记录保留变更前后对照和原因，便于后续追溯。
完整示例：一次员工账号权限请求的RACI填写
以“员工申请某业务系统权限”为例，演示从事项到矩阵的填写过程。该事项的触发场景是新入职、转岗或临时项目需要访问，涉及服务台、应用支持组、系统负责人和业务接口人。
| 角色 | RACI | 理由 |
|---|---|---|
| 服务台 | R | 受理请求、核对申请人信息、在系统中提交权限开通操作 |
| 应用支持组 | R | 执行具体权限配置，处理配置过程中的技术问题 |
| 系统负责人 | A | 对权限开放范围和合规性最终负责，例外申请由其审批 |
| 业务接口人 | C | 确认申请人的业务角色和数据可见范围是否合理 |
| 员工所在部门负责人 | I | 权限开通完成后知会，便于掌握团队访问情况 |
校验时检查该行只有一个A，即系统负责人；服务台和应用支持组同为R，分别承担受理和配置动作，边界在矩阵备注中写明。升级路径为：服务台在约定时限内未完成配置时，升级至应用支持组负责人；涉及敏感权限或例外开放时，升级至系统负责人审批。这个示例可以直接替换事项名称和团队名称，迁移到其他请求类型。
完成检查：矩阵是否可执行的判断标准
矩阵是否达到可执行状态，可以逐项核对以下清单。全部通过，说明分工已经落到可运行的程度；有未通过项，回到对应步骤补齐。
- 每类支持事项有且仅有一个A，且A所在团队确认接受该职责。
- 每类事项至少有一个R，R清楚自己负责的处理动作和完成标准。
- 每个角色清楚自己在哪些事项上承担R或C，角色清单与矩阵一致。
- 矩阵已发布到员工发起请求的入口，工单分类与矩阵行一一对应。
- 每类事项的升级路径已写明，员工和受理人员都能查到。
- 复核责任人和复核周期已明确，调整后的发布与通知动作已约定。
- 矩阵有版本或更新记录，能追溯每次调整的原因。
这份清单也可以作为季度复核的检查表使用，帮助团队在组织变化后快速判断分工是否仍然有效。
常见问题
支持事项清单应该拆到多细，才适合填RACI？
以员工能识别的请求类型为单位，用两个标准判断：一类事项经常需要拆给不同团队分别处理，说明粒度过粗，应拆成更具体的事项；两类事项的受理入口、责任团队和升级路径完全一致，可以合并。初期建议控制在15至30类，覆盖大部分请求量，长尾事项归入“其他”并单独指定负责人，避免矩阵行数过多后无人维护。
两个团队都认为自己是A，怎么处理？
先按“这类事项处理失败时谁被追责、谁有权决定升级和例外处理”来判断，保留一个A，其余改为C或R。如果两个团队仍无法达成一致，上移到共同上级裁定，裁定结果写入矩阵备注，并在评审记录中说明原因。跨团队事项的A通常归口于对系统或服务整体负责的岗位，处理量最大的团队更适合承担R。
矩阵发布后，新增工单分类时怎么保持同步？
把工单分类与矩阵行保持一一对应作为发布后的维护规则：新增工单分类时同步更新矩阵，明确该类事项的A、R和升级路径，再开放给员工提交。否则会出现员工能提交、但矩阵中没有对应责任人的事项。这项同步动作可以纳入季度复核的检查范围，也可以在服务台变更工单分类时作为前置条件。
组织调整后，RACI矩阵需要全部重做吗？
不必全部重做。组织调整属于专项复核的触发条件，由受影响事项的A所在团队检查相关行，重点确认A的归属是否随岗位变化而失效、R所在团队是否仍然承担实际处理动作。调整完成后同步更新工单分类和受理表单中的责任团队信息、知识库服务目录页面，并通知受影响的团队和业务接口人，保留变更前后对照和原因。
在协作工具中承载RACI分工，需要关注哪些能力？
关注三点：员工提交请求时能否直接看到责任团队和升级路径；工单分类能否与矩阵行对应并支持自定义属性；矩阵说明和服务目录能否沉淀为可查阅的文档。ONES Desk 面向企业服务与协作场景，可用于内部支持等场景，支持自定义工单属性以适配不同收集场景，并支持集中管理工单状态、处理进度和责任分工；工单还可关联到 ONES Wiki 页面，便于把矩阵说明和服务目录沉淀为文档。矩阵本身是否以原生模板形式提供，选型时可向厂商确认。
