企业官网建设流程全解析

简介：这份文档围绕腾讯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 三个角色的核心产出物分别是什么

先把三个角色用「产出物」定义清楚，比用「职能」定义更不容易扯皮。

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 表可以直接作为团队内部约定。

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 # 输出: status=responded, response="模板已返回，参数范围P6-P8" hr-cli request create --from HRBP --to SDC --type "批量入职" --count 20 hr-cli request status --id REQ-2024-002 # 输出: status=in_progress, completed=12/20

这段命令示意的是请求的创建和状态查询。参数说明：--from 和 --to 定义接口方向，--type 定义请求类型，--sla 定义响应时限，--count 定义批量数量。实际落地时可以用工单系统替代，关键是每个请求都有 ID、有状态、有归属。

注意：流程走查的目的是发现「谁在等谁」。如果发现某个环节经常卡住，先看是 SLA 不合理，还是权限没给够。

4. 三支柱落地时最容易踩的坑与排查方法

4.1 HRBP 变成传话筒的识别与纠正

HRBP 变传话筒的典型信号是：业务负责人提需求，HRBP 原话转给 COE；COE 返回方案，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 一份可以直接用的季度健康检查表

每季度花半小时过一遍下面这张表，比出了问题再救火省事。

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 表、请求模板三样。新人第一周就要走一遍模拟请求流程，知道找谁、怎么提、多久响应。

这一步做完，三支柱才算从「几个人的默契」变成「组织的习惯」。默契会随人走，习惯不会。

本文还有配套的精品资源，点击获取