简介这份PDF资料系统梳理腾讯人力资源与组织管理体系的整体框架适合HR从业者、企业管理者以及研究互联网组织变革的读者。内容从使命、愿景与价值观切入重点阐述COE、SDC、HRBP三支柱的职责划分与协作关系并回顾1998年至今的人力资源体系演变涵盖招聘调配、薪酬福利、腾讯学院、企业文化与员工关系等模块帮助理解腾讯如何将“员工是第一财富”落实到具体管理制度中。同时资料还呈现了招聘体系框架、渠道全景图和战略聚焦方向可系统把握HR如何承接公司战略。资源为单个PDF文档大小约1.29MB便于阅读与收藏。目前已有69人学习下载。通过这份资料可以快速掌握腾讯HR三支柱的运作逻辑、各阶段HR角色变化以及面向业务的一站式HR解决方案设计思路对搭建或优化企业人力资源组织架构具有直接借鉴意义。1. 为什么一句“腾讯人力资源与组织管理体系”值得反复读如果把公司比作一套软件腾讯这套人力资源管理机制就是它的“操作系统”。大多数技术团队只关注业务代码和服务器扩容却忽略了人力资源的调度、晋升和绩效反馈才是真正决定产品迭代速度的底层逻辑。腾讯的 HR 体系没有停留在“发工资、办入职”的行政层而是用三支柱模型把制度设计、业务支持和流程执行拆成了三条流水线再配合职级双通道和九宫格绩效让几万人的组织依然能保持小团队那样的反应速度。对 IT 从业者来说理解这套体系不是为了背概念而是为了在设计 HR 系统和做组织分析时知道字段背后为什么是“这个口径”、报表为什么要按“这个纬度”切。接下来从骨架、数据模型、绩效落地和系统外挂四个层面把它讲透。2. 骨架先立住腾讯人力资源与组织管理体系的三大支点2.1 三支柱COE 定规则、HRBP 下沉、SSC 提效率腾讯人力资源管理最常见的公开表述是“三支柱模型”COECenter of Excellence专家中心、HRBPHuman Resource Business Partner人力资源业务伙伴、SSCShared Service Center共享服务中心。这套结构不是腾讯原创但腾讯在落地时强化了“COE 做产品、HRBP 做销售、SSC 做客服”的类比让各部门边界非常清晰。COE 负责定规则例如薪酬体系、绩效制度、干部选拔标准。它产出的是一份份政策和测算模型而不是跑腿执行。HRBP 则直接嵌入到事业群贴近产品和技术团队负责把 COE 的制度翻译成业务语言同时把业务侧的痛点反馈给 COE。SSC 承担的是重复度最高的流程比如入转调离、考勤核算、社保公积金、劳动合同尽量用线上化系统自动处理让前两个角色腾出手来思考。我一般会建议刚接触这套体系的人先画一张职责切分表把“谁定标准、谁执行标准、谁兜底处理异常”列清楚。2.1.1 三支柱的职责切分支柱核心职责主要产出物对应信息系统COE制度设计、薪酬对标、绩效政策、人才标准政策文档、调薪包、胜任力模型HRBI 看板、薪酬计算引擎HRBP业务诊断、团队建设、员工沟通、组织调整建议组织诊断报告、继任计划、离职分析员工关系管理、协作平台SSC流程执行、数据维护、合规审核入转调离流程、工资单、社保台账核心人事系统HRIS这张表能直接用来对号入座排查问题。比如业务负责人投诉“招人慢”如果制度没问题那么瓶颈大概率在 HRBP 的岗位画像不清或者 SSC 的审批流卡在某个环节而不是 HR 不努力。2.1.2 三支柱如何借力数据系统三支柱运转顺畅的前提是数据能按需流动。COE 调薪时需要全公司薪酬分位值HRBP 做诊断时需要本业务线的流失率和绩效分布SSC 则是所有数据的录入入口。这三类需求对应的数据库访问模型完全不同COE 偏聚合查询HRBP 偏带权限的明细查询SSC 偏写入和更新。所以做 HR 系统时不能只建一张员工大表给所有人用而要通过数据仓库分层把贴源层、汇总层和应用层拆开这是把人力资源管理制度变“活”的关键。2.2 职级双通道专业线与管理线不再抢一把椅子很多互联网公司都在讲“双通道”但真正执行到位的并不多。腾讯的职级体系在设计上尽量弱化“只有升管理才算晋升”的路径依赖。管理线负责带团队、定方向、做协调专业线负责攻坚技术难题、建标准、带徒弟。两条线在薪资带宽上对齐避免出现“专家不如组长”的倒挂。2.2.1 职级序列与带宽公开资料中常见的是将职级分为 P 序列专业和 M 序列管理P 序列再按岗位族细分比如技术族、产品族、设计族。职级带宽通常是指同一级里的薪资浮动范围例如 P5 的带宽可能跨 30%目的就是给绩效优秀但短期没有晋升机会的人保留调薪空间。带宽设定如果太窄队伍很快就出现“升职才能加薪”的挤压太宽又会让职级信号失真隔壁项目组的 P6 可能比这里的 P7 还强。2.2.2 晋升标准怎么写才可执行一个常见误区是把晋升标准写成“有良好沟通能力、具备技术领导力”这类修饰语。在腾讯这类体系里晋升评审更看重“可举证的行为”。比如对于技术专家标准可能是“在复杂项目中定义架构方案并推动跨团队落地解决至少一个影响线上稳定性的关键问题”。每个候选人都要准备具体的案例材料评审委员按标准打分。IT 系统在这部分的支撑重点是物料管理把晋升申請表、案例附件、评委评分、答辩视频统一归档并且把评委给出“通过”的理由沉淀到知识库作为后续校准的样本。2.3 为什么这套体系能兼容“产品优先”的互联网节奏传统制造业的人力资源体系强调岗位等级和控制而互联网行业强调响应速度和创造力。腾讯这套体系好就好在“制度稳定接口灵活”。职级是稳定的坐标系保证长期公平但业务组织可以短期按项目重组HRBP 跟着业务走SSC 不跟着业务走。这样一来当一个新项目要在一周内组队时HRBP 能从人才池里快速捞人COE 只需要调整基础规则SSC 则按既定流程处理调入调出不消耗业务过多的精力。这种“平滑的组织伸缩”能力正是这套管理体系能支撑大公司保持产品迭代速度的原因。3. 把它变成数据资产腾讯人力资源与组织管理体系的建模与透视3.1 组织数据模型的四张主表要把任何一套 HR 体系落地成系统第一步都是建表。腾讯这套体系虽复杂但抽象成数据模型并不难。我一般会从四张主表开始组织单元表、员工表、绩效评定表、职级变动表。下面给出简化的 MySQL 建表语句字段比实际项目要精简但关系能立住。-- 组织单元表 CREATE TABLE org_unit ( unit_code VARCHAR(16) PRIMARY KEY, -- 组织代码 unit_name VARCHAR(64), -- 组织名称 parent_code VARCHAR(16), -- 父级组织代码NULL 表示根组织 org_type ENUM(BU,BG,Team), -- 组织类型 create_time DATETIME, -- 创建时间 status TINYINT DEFAULT 1 -- 1 有效0 解散 ); -- 员工主档表 CREATE TABLE employee ( emp_id VARCHAR(20) PRIMARY KEY, emp_name VARCHAR(50), job_level VARCHAR(10), -- 职级如 P6 job_family VARCHAR(20), -- 岗位族如 技术-后端 unit_code VARCHAR(16), -- 所在组织外键到 org_unit manager_id VARCHAR(20), -- 直属上级 emp_id hire_date DATE, -- 入职日期 status ENUM(active,resigned) ); -- 绩效评定表 CREATE TABLE perf_score ( emp_id VARCHAR(20), review_cycle VARCHAR(20), -- 如 2024H1 perf_score DECIMAL(3,1), -- 绩效评分 potential DECIMAL(3,1), -- 潜力评分 judge VARCHAR(20), -- 评定人 PRIMARY KEY (emp_id, review_cycle) ); -- 职级变动表 CREATE TABLE job_change ( emp_id VARCHAR(20), old_level VARCHAR(10), new_level VARCHAR(10), change_date DATE, reason ENUM(promotion,demotion,transfer) );这里的核心设计思路是“组织”和“员工”不混在一张表里。组织是一个独立实体可以随时调整汇报关系而员工挂在组织代码下这样在做组织调整时不需要改员工主档只需改 org_unit.parent_code 或 employee.unit_code。绩效和职级变动单独成表是为了保留历史轨迹才能回答“哪些人连续两个周期绩效上升”这类问题。3.2 SQL 透视职级分布和组织活力有了这些表第一个值得分析的指标是“职级分布”。一家健康的互联网公司职级分布不应该是金字塔更不可能是倒金字塔。用下面这条 SQL 就能快速看分布SELECT job_level, COUNT(*) AS active_count, ROUND(AVG(DATEDIFF(CURDATE(), hire_date)/365), 1) AS avg_tenure FROM employee WHERE status active GROUP BY job_level ORDER BY job_level;说明job_level 字段是字符串如果是 P5、P6 这类编码直接按字典序排序可能得到 P10 排在 P2 前面的问题。可以在排序里加一个附加字段保存职级数值例如 grade_num INT或者用表达式把字符转成可排序数字。avg_tenure 是一个重要信号如果 P7 以上的平均司龄不到两年说明晋升偏快或外部挖人占比过高长期来看组织稳定性存疑如果 P6 的平均司龄很高但没有流动则要注意是不是存在晋升瓶颈。再看组织单元的人效可以按一二级部门汇总人数和绩效分布SELECT o.unit_name, COUNT(e.emp_id) AS emp_count, ROUND(AVG(p.perf_score), 2) AS avg_perf FROM org_unit o LEFT JOIN employee e ON o.unit_code e.unit_code AND e.status active LEFT JOIN perf_score p ON e.emp_id p.emp_id AND p.review_cycle 2024H1 GROUP BY o.unit_code, o.unit_name;这里的关键是 JOIN 维度。很多 HR 表最容易踩坑的是“员工当前组织”和“员工历史组织”混淆。如果只取当前组织会丢掉员工之前在其他部门的表现数据导致绩效的历史对比失真。所以我在实际建模时会在员工表里加一个 current_home 概念同时用单独的组织履历表记录每次调入调出的起止日期统计时才不会漏算。3.3 用 Python 模拟晋升通道与人才供给SQL 只能看现状如果想回答“明年哪些层级会有缺口”需要做简单的人才供给模拟。我一般会用一个很轻量的 Python 模型按历史晋升率和离职率做蒙特卡洛模拟来看未来一年职级人头的变化。3.3.1 晋升概率模型假设每个职级的晋升概率服从指数衰减层级越高晋升概率越低。可以用 numpy 做随机抽样import numpy as np import pandas as pd # 职级与基准晋升概率实际项目中用历史数据拟合 levels [P5, P6, P7, P8] promo_prob {P5: 0.30, P6: 0.20, P7: 0.10, P8: 0.05} def simulate_promotion(year_count10000): results [] rng np.random.default_rng(2025) for _ in range(year_count): path [] level P5 total_years 0 while level ! P8 and total_years 10: path.append(level) if rng.random() promo_prob[level]: level levels[levels.index(level) 1] total_years 1 results.append(total_years) return np.percentile(results, [25, 50, 75])这个模型假设晋升事件按年独立发生实际情况当然会有“窗口期”效应——比如一年只有一次晋升评审没赶上就只能等明年。这个模型的意义在估算不同层级晋升到目标层级的时间中位数比如 P5 到 P7 可能 50% 的人需要 4 年那么在做每年校招需求时就要提前补足这个可能流失的人头。3.3.2 预测未来三年各职级人数在晋升模型基础上叠加离职抽样就能得到一个简单的队列状态流转def simulate_headcount(start_headcount, years3, sample1000): rng np.random.default_rng(7) roll {P5: 0.15, P6: 0.12, P7: 0.08, P8: 0.04} # 年离职率 result {y: {} for y in range(years 1)} all_hc pd.DataFrame(start_headcount, index[0]) for y in range(years): new_hc {} for lv, count in all_hc.iloc[-1].items(): remain 0 for _ in range(int(count)): if rng.random() roll[lv]: remain 1 new_hc[lv] remain # 内部晋升从下级取人加上来 for n, lv in enumerate(levels[1:], start1): up all_hc.iloc[-1][levels[n-1]] * promo_prob[levels[n-1]] new_hc[lv] up new_hc[levels[n-1]] - up all_hc pd.concat([all_hc, pd.DataFrame([new_hc])], ignore_indexTrue) result[y1] new_hc return result注意上面的代码为演示逻辑做了简化没有做向上取整和人数不能为负的约束。实际项目中我会用 SciPy 的 rvs 函数生成离散分布而不是用 for 循环逐个抛硬币效率会高很多。这个模拟跑出来如果某个职级在第三年出现负向缺口就要提前启动晋升通道拓宽或外部招聘计划。4. 绩效、潜力与人才盘点九宫格怎么落地4.1 九宫格的构成与判定规则腾讯这套体系里人才盘点最常用的是“九宫格”。横向是“绩效”即本周期目标完成情况纵向是“潜力”即未来两三年能否承担更大职责。每个格子对应的管理动作完全不同例如高绩效高潜力的超级明星要重点给机会低绩效低潜力的要果断优化而中绩效高潜力的要防止因暂时没出成绩而被误杀。给出一张策略对照表绩效 \ 潜力高中低高重点培养、加速晋升加强保留、扩大职责跟进行动、限期改进中加速发展、给予曝光稳定发挥、关注激励关注观察、明确差距低调整岗位或职责观察验证、设定目标淘汰或转岗这张表的关键不只是“怎么分格”而是分格之后要有对应的动作。比如“高潜低绩”这个格子多数公司会误判为“绩效差就是能力差”。但腾讯这类体系更倾向先看潜力因为低绩效可能是新换了方向、老板给了一个更难的目标这种情况下要拉长观察窗口而不是一刀切淘汰。4.2 用 Python 实现九宫格判定当绩效和潜力评分数值化之后九宫格判定就是一段很简单的逻辑函数def pigeonhole(perf_score, potential_score): # 假设评分范围 1-5 perf_level 高 if perf_score 4.5 else (中 if perf_score 3.5 else 低) pot_level 高 if potential_score 4.0 else (中 if potential_score 3.0 else 低) grid { (高, 高): 重点培养, (高, 中): 加强保留, (高, 低): 跟进行动, (中, 高): 加速发展, (中, 中): 稳定发挥, (中, 低): 关注观察, (低, 高): 调整岗位, (低, 中): 观察验证, (低, 低): 淘汰或转岗 } return grid[(perf_level, pot_level)]注意评分阈值不能写死在代码里应该做成配置项。不同 BG 的业务节奏不同比如新业务的第一版可能绩效分数普遍偏低如果统一用全公司阈值就会误伤那批从 0 到 1 的开拓者。我习惯把阈值放在一张 config 表里每次盘点前由 COE 确认后再跑分。4.3 人才盘点的时间轴与校准会九宫格不应该是 HR 关起门来单独打分。常见做法是“年中看潜力年末看绩效”每年至少组织一次正式的盘点校准会。会议流程一般是业务负责人先给本部门员工初排格子HRBP 提供员工过去两年的绩效趋势和离职风险提示然后所有参会者一起过名单。校准会最大的价值是消除评分偏差。例如 A 总监对下属偏严打平均分只有 3.0B 总监偏松平均分 4.2如果不做校准B 部门的人在九宫格里就会全部偏上。这时 HRBP 要出示部门的绩效率分布要求各负责人在初评时控制比例。这一步放在系统里就是“校准记录表”。每个员工在九宫格里的格子变更都要留痕记录是“维持原格”“上调”还是“下调”以及原因。这个数据在未来做晋升评审和继任者计划时非常关键比单独看某一个周期的绩效分要准确得多。5. 站在 IT 视角把腾讯这套体系“外挂”到自己的管理系统里5.1 权限模型谁可以看哪个部门的数据复制一套制度不难难的是让制度对应的数据安全落地。在人力资源体系里最典型的需求是HRBP 只能看自己负责组织的员工明细COE 可以看全公司的聚合数据但不能看具体某个人这个月拿了多少奖金。用 RBAC 模型可以这样抽象CREATE TABLE role_permission ( role_code VARCHAR(20), -- hrbp, coe, ssc perm_type ENUM(raw,aggregate), org_scope VARCHAR(16), -- 限定到哪个部门NULL 表示全公司 field_mask VARCHAR(255) -- 屏蔽字段如 salary_level );权限不是“能不能打开页面”而是“能打开到第几层”。我一般会加一层行级权限过滤在查询 SQL 里自动拼接上 HRBP 的 org_scope避免某个爱写复杂 SQL 的同事把部门字段挖出来。5.2 组织健康度巡检脚本的复用技巧最后给一个很实用的技巧把腾讯这套体系的核心指标做成一个组织健康度巡检脚本。它可以定期跑一遍输出一份 Markdown 报表包含职级分布、司龄中位数、绩效校准差异、高潜人数占比。这里最值得复用的是“异常阈值”设计。例如如果某重点业务线的“高潜力”员工占比低于 5%脚本就输出告警提示可能需要重新审视人才密度。具体实现时我会把指标定义放在独立配置文件中每次分析只运行一个入口函数。这样做的好处是当公司组织架构调整后不需要改 Python 代码只需要调整 org_unit 表的父子关系巡检脚本就能自动适应新架构。人力资源管理体系从来不是一张固定的流程图而是组织的“运行时环境”能让它持续进化的恰恰是这套数据化、可校验的外挂机制。本文还有配套的精品资源点击获取
