HR三支柱职责边界与协作接口：COE、HRBP、SDC落地实践指南

简介这份文档围绕腾讯HR三支柱模型展开系统梳理COE专家中心、HRBP人力资源业务伙伴与SDC共享交付中心三者的分工逻辑与落地路径适合HR从业者、组织发展研究者及备考人力资源相关认证的读者参考。内容从腾讯2010年设立SDC的背景切入详解COE如何站在战略前沿提供政策与工具支撑、HRBP如何深入事业群参与业务会议并输出定制化方案、SDC如何通过区域共性解决方案、E-HR信息化与基础人事运营三大机构实现标准化交付还结合招聘场景说明三方协同流程并总结SDC约120人规模下的职责覆盖原则与用户体验特色。资源包为1个docx文档约220KB结构紧凑、干货密集便于快速通读与收藏查阅。目前已有1225人学习下载适合希望理解大型企业HR架构转型、借鉴三支柱协同机制的读者深入研读。1. 从一份被反复转发的文档说起HR三支柱到底在分什么工很多技术管理者第一次接触 HR 三支柱不是因为人力资源课程而是因为自己团队要招人、要定级、要调薪时突然发现对接的 HR 换了好几个角色有人负责跟你聊业务目标有人负责发 offer 走流程还有人负责设计职级体系。这三类角色就是 COE、HRBP、SDC。腾讯这套三支柱模型被反复讨论核心不在于名词而在于分工边界谁定规则、谁贴业务、谁跑交付。搞不清这条线就会出现 HRBP 变成传话筒、COE 方案落不了地、SDC 被当成万能客服的局面。这篇不聊组织架构图而是把三支柱拆成可落地的职责、协作接口和判断标准适合正在搭 HR 体系的技术负责人、HR 从业者以及需要和 HR 高频协作的团队 leader。2. COE、HRBP、SDC 的职责边界与协作接口怎么划2.1 三个角色的核心产出物分别是什么先把三个角色用「产出物」定义清楚比用「职能」定义更不容易扯皮。角色全称核心产出物服务对象时间尺度COECenter of Expertise制度、标准、工具包HRBP、管理层季度到年度HRBPHR Business Partner业务侧 HR 解决方案业务负责人、员工周度到季度SDCShared Delivery Center标准化交付结果全员日度到周度COE 产出的是「规则」比如职级体系、薪酬带宽、绩效模板HRBP 产出的是「方案」比如某个业务线要不要扩编、某个团队怎么调结构SDC 产出的是「结果」比如入职办完了、社保交上了、工资发对了。提示判断一个 HR 岗位属于哪根支柱看他的产出物是规则、方案还是结果比看 title 准得多。2.2 三者之间的请求与响应接口三支柱能不能跑起来取决于接口是否清晰。常见做法是把接口定义成「请求-响应」模式类似微服务之间的调用。# HR三支柱协作接口示例简化 interfaces: - name: hrbp_to_coe request: 业务线需要定制化激励方案 response: COE提供可选方案模板参数范围 sla: 5个工作日 - name: hrbp_to_sdc request: 本月该业务线入职30人 response: SDC完成入职办理并回传状态 sla: 入职当日完成 - name: sdc_to_coe request: 某流程异常率超过阈值 response: COE评估是否调整规则 sla: 按季度评审这段配置说明的是HRBP 向 COE 要的是「方案模板和参数范围」不是让 COE 直接出终稿HRBP 向 SDC 要的是「执行结果」不是让 SDC 自己判断该不该招。SLA 是接口能否稳定的关键没有 SLA 的接口最后都会变成口头催促。2.3 边界模糊时最容易出现的三种误用第一种HRBP 越界做 COE 的事自己给业务线定薪酬规则结果和其他业务线打架。第二种COE 直接指挥 SDC绕过 HRBP导致业务侧不知情。第三种SDC 被要求处理非标问题比如「这个员工的特殊情况帮我通融一下」一旦开口子标准化就崩了。避免这三种误用的办法是任何跨支柱请求都走固定入口。COE 的规则变更走 HRBP 收集需求SDC 的异常升级走 HRBP 判断是否转 COE。入口固定了责任才固定。3. 用一套最小配置把三支柱协作跑起来3.1 定义角色权限矩阵落地第一步不是招人而是把权限矩阵写出来。下面是一份可以直接改的权限矩阵示例。# 角色权限矩阵R负责 A审批 C咨询 I知会 permission_matrix { 职级体系设计: {COE: R, HRBP: C, SDC: I}, 业务线扩编申请: {COE: C, HRBP: R, SDC: I}, 入职办理: {COE: I, HRBP: A, SDC: R}, 薪酬调整: {COE: R, HRBP: A, SDC: I}, 社保缴纳: {COE: I, HRBP: I, SDC: R}, } def check_permission(task, role, action): 检查某角色在某任务上是否有指定权限 return permission_matrix.get(task, {}).get(role) action # 示例检查HRBP能否负责扩编申请 print(check_permission(业务线扩编申请, HRBP, R)) # True这段代码的逻辑是每个任务只有一个 R负责避免多头负责审批权 A 通常给 HRBP 或业务负责人COE 在规则类任务上是 R在执行类任务上只是 I。参数说明task 是任务名role 是角色action 是权限类型。实际使用时可以把这份矩阵落到 OA 或 HR 系统里用系统卡权限比靠人记靠谱。3.2 用 SLA 表约束响应时间接口定义了还得有响应时间。下面这张 SLA 表可以直接作为团队内部约定。请求类型发起方响应方响应时间升级路径规则咨询HRBPCOE3 个工作日COE 负责人方案定制HRBPCOE5 个工作日HR 总监批量入职HRBPSDC当日SDC 主管异常个案SDCHRBP1 个工作日HRBP 负责人规则变更COEHRBP按季度HR 委员会SLA 的关键不是数字多精确而是「超时后往哪升级」写清楚。没有升级路径的 SLA超时了也没人管。3.3 一次完整的协作流程走查以「某业务线要新增 20 个编制」为例走一遍完整流程。第一步业务负责人向 HRBP 提出扩编需求HRBP 收集业务数据。第二步HRBP 向 COE 请求编制测算模板和薪酬带宽参考。第三步COE 在 SLA 内返回模板和参数范围。第四步HRBP 结合业务实际形成方案提交业务负责人和 HR 负责人审批。第五步审批通过后HRBP 向 SDC 发起批量入职请求。第六步SDC 按标准流程办理回传状态。# 用命令行模拟一次请求流转示意 hr-cli request create --from HRBP --to COE --type 编制测算 --sla 5d hr-cli request status --id REQ-2024-001 # 输出: statusresponded, response模板已返回参数范围P6-P8 hr-cli request create --from HRBP --to SDC --type 批量入职 --count 20 hr-cli request status --id REQ-2024-002 # 输出: statusin_progress, completed12/20这段命令示意的是请求的创建和状态查询。参数说明--from 和 --to 定义接口方向--type 定义请求类型--sla 定义响应时限--count 定义批量数量。实际落地时可以用工单系统替代关键是每个请求都有 ID、有状态、有归属。注意流程走查的目的是发现「谁在等谁」。如果发现某个环节经常卡住先看是 SLA 不合理还是权限没给够。4. 三支柱落地时最容易踩的坑与排查方法4.1 HRBP 变成传话筒的识别与纠正HRBP 变传话筒的典型信号是业务负责人提需求HRBP 原话转给 COECOE 返回方案HRBP 原话转回业务。整个过程 HRBP 没有加工。识别方法看 HRBP 提交给 COE 的请求里有没有业务侧的数据和判断。如果只有「业务说要招人」没有「业务当前人效、缺口测算、优先级」那就是传话筒。纠正方法要求 HRBP 的请求必须附带业务数据包。常见做法是定义一个最小数据包模板包含业务目标、当前编制、人效数据、缺口分析四项。没有这四项COE 可以拒收。4.2 COE 方案落不了地的三个原因第一个原因方案没有参数范围只有原则。比如「薪酬要体现激励性」这种话没法执行。第二个原因方案没有考虑业务差异一套规则套所有业务线。第三个原因方案没有配套工具HRBP 拿到后不知道怎么用。排查时问三个问题这个方案有没有可调参数有没有区分业务场景有没有配套模板或计算工具三个都否方案大概率落不了地。4.3 SDC 被非标需求拖垮的止损方式SDC 的命脉是标准化。一旦开始接非标需求效率会快速下降。止损方式是设「非标需求入口」所有非标需求不直接进 SDC先到 HRBP由 HRBP 判断是否值得转 COE 变成新规则。# 非标需求过滤逻辑 def route_request(request): if request.is_standard: return SDC elif request.has_business_justification: return HRBP # HRBP判断是否转COE else: return REJECT # 无业务理由的非标需求直接拒 # 示例 print(route_request({is_standard: False, has_business_justification: True})) # 输出: HRBP这段逻辑的核心是非标需求必须有业务理由否则直接拒。参数说明is_standard 标识是否标准需求has_business_justification 标识是否有业务合理性说明。实际使用时可以把这段逻辑做成工单系统的路由规则。4.4 用数据验证三支柱是否真的在运转验证指标不用多三个就够HRBP 请求的 COE 响应及时率、SDC 标准需求占比、业务负责人对 HR 服务的满意度。及时率低于 80%说明 SLA 或 COE 产能有问题标准需求占比低于 70%说明非标需求在侵蚀 SDC满意度低于基线说明接口有问题。提示这三个指标按月看趋势比看单月绝对值更有意义。趋势恶化时先查接口再查人。5. 把三支柱协作固化成可复用的检查清单5.1 一份可以直接用的季度健康检查表每季度花半小时过一遍下面这张表比出了问题再救火省事。检查项判断标准不达标时的动作接口 SLA 达成率≥ 80%重谈 SLA 或加 COE 产能HRBP 请求数据完整率≥ 90%拒收不完整请求SDC 标准需求占比≥ 70%收紧非标入口COE 方案配套工具率≥ 80%方案必须带模板才发布业务满意度不低于上季度访谈业务负责人定位问题5.2 用一次复盘会定位接口瓶颈复盘会只问三个问题本季度哪个接口超时最多超时的请求有什么共同特征下季度改 SLA 还是改流程三个问题问完瓶颈基本能定位。# 从工单系统导出超时请求示意 hr-cli report timeout --quarter Q3 --group-by interface # 输出: # hrbp_to_coe: 12次超时, 平均超时2.3天 # hrbp_to_sdc: 3次超时, 平均超时0.5天 # sdc_to_hrbp: 8次超时, 平均超时1.1天这段命令的作用是按接口分组统计超时次数和平均超时时长。参数说明--quarter 指定季度--group-by 指定分组维度。拿到结果后优先处理超时次数多且平均时长高的接口通常是 hrbp_to_coe 这类需要 COE 深度参与的接口。5.3 把接口约定写进新员工入职材料三支柱协作能不能持续取决于新人是否知道接口在哪。常见做法是把接口约定写进 HR 团队新员工入职材料包含权限矩阵、SLA 表、请求模板三样。新人第一周就要走一遍模拟请求流程知道找谁、怎么提、多久响应。这一步做完三支柱才算从「几个人的默契」变成「组织的习惯」。默契会随人走习惯不会。本文还有配套的精品资源点击获取