Skip to content

HR 三支柱为什么失灵

2026/05/22

HR 三支柱为什么失灵

人在回路中|HR 三支柱为什么失灵

V03 HR 三支柱接口断裂图

本文是《人在回路中 Human in the Loop》系列第 3 篇。

HRBP 这根中柱,我坐过

HRBP 这根中柱,我坐过。

不是在旁边看过。

是真的坐在那个位置上,每天把一堆脏兮兮的信息翻来翻去。

老板说战略。

一线听见的是任务。

一线说卡点。

老板听见的是理由。

HRBP 夹在中间,表面上叫“服务业务”,实际上干的是一件更苦的活:把老板的意图翻成岗位动作,把一线的抱怨翻成组织问题,把人的情绪翻成管理信号,再整理成一份一号位能看、敢签、愿意拍板的判断。

所以我一直不太喜欢“服务业务”这个说法。

太轻了。

HRBP 真正吃饭的手艺,不是笑脸、沟通、写材料。

是判断翻译。

这四个字不好听,但真实。

它要求你知道老板到底怕什么,也知道一线到底卡在哪。你要听得懂业务里的火气,也要知道哪些火气只是情绪,哪些火气背后是岗位设计、流程设计、激励设计出了问题。

我以前最有体感的时刻,往往不是正式汇报。

是会后。

老板刚在会上说完一段很漂亮的话,业务负责人点头,员工也点头。

散会以后,走廊里就会有人拉住你,小声说:

“这事儿真要这么干吗?”

这一句话,比会议纪要值钱。

因为它说明组织里有一个判断没有被说出来。

老板以为命令已经传达。

中层以为自己已经理解。

一线其实还在等一个更具体的答案。

HRBP 的价值,就在这种缝里。

不是把话传过去,而是知道这条缝到底是信息缝、责任缝、能力缝,还是一号位自己没有讲清楚。

过去这件事值钱,是因为材料太散。

会议纪要里有一点。

邮件里有一点。

访谈里有一点。

绩效记录里有一点。

项目复盘里有一点。

还有一大堆东西,不在系统里,在走廊、饭桌、会后那两分钟里。

HRBP 的价值,就是把这些碎片装进脑子,揉一揉,滤一滤,最后变成老板能听懂的一句话:

这不是人的问题。

这是组织的问题。

AI 进来以后,麻烦来了。

不是因为 AI 一下子能替掉 HRBP。

没那么简单。

真正麻烦的是,AI 不需要完整替掉 HRBP,就能先把 HRBP 最常见的半边工作打折。

收集。

整理。

转述。

归纳。

写初稿。

这些动作,过去靠时间、关系和文字能力慢慢攒。现在一批 1on1 记录可以被归类,一堆邮件可以被总结,几十份项目复盘可以被抽模式,多个部门反馈可以先压成一张冲突地图。

过去一个 HRBP 慢慢攒一个月的判断素材,现在几个小时就能端上桌。

桌子上有材料。

但材料不是判断。

这就是第 3 篇要拆的事。

AI 不是把 HR 三支柱一脚踹倒。

它更像把灯打开。

灯一亮,大家突然看见:很多公司所谓的 HRBP,本来就不是组织诊断师,只是高级转述员。

这话不好听。

但一号位要听。

因为接下来真正被重写的,不是 HR 部门那张组织架构图。

是公司里的判断链。

谁收信号?

谁做诊断?

谁给结论定价?

谁签字?

谁兜底?

如果这些问题没有重新设计,三支柱保不保留,名字改不改,都只是换一张名片。

Ulrich 不是错了,是接口旧了

讲三支柱,要先把话放平。

Ulrich 不是错了。

也没必要踩。

1997 年,Dave Ulrich 出版 Human Resource Champions。那本书真正有分量的地方,不是给 HR 圈发明几个黑话,而是把 HR 从事务处理往价值创造上推了一步。

后来大家熟悉的三支柱,就是沿着这套语言长出来的:

共享服务中心接标准服务。

专家中心做政策和专业方案。

业务伙伴贴近现场,把组织判断带回业务。

站在 1997 年,这个设计不土。

它很先进。

因为大组织当时真的有一个难题:HR 如果天天被考勤、薪酬、入离调转、流程问询淹没,就别谈什么业务伙伴。专业要集中,服务要标准,现场要有人贴近,这个分工解决的是当时的真问题。

但它有一个默认前提。

组织里的判断,主要靠人搬运。

政策由人写。

流程由人跑。

业务信号由人带回来。

组织判断由人整理。

责任也由人承担。

三支柱本质上不是三根柱子。

它是一套“人怎么在组织里搬运判断”的接口。

问题出在这里。

2026 年,接口还在,电流变了。

标准服务不再只靠共享服务团队跑,AI 工作流可以直接处理大量高频请求。

专业政策不再只躺在专家中心的 Word 文档里,它会被写进提示词、规则文件、系统权限、Agent 边界和审计条件。

业务伙伴也不再是判断流动的单一路径,因为 AI 已经可以参与会议纪要、访谈整理、绩效文本、岗位材料和业务复盘的初步归纳。

所以我不认为第 3 篇是在批判 Ulrich。

不是。

这篇真正想说的是:

Ulrich 当年解决的是人的协作接口。

AI 进来以后,工作被拆成任务、判断、责任、监督和回滚。

原来的柱子不会立刻倒。

但每根柱子下面的承重逻辑已经换了。

很多公司谈三支柱反思,还是停在 HR 圈内部:

HRBP 太虚。

COE 太远。

SSC 太机械。

这些批评都没错。

但它们批的是“三支柱运行不好”,不是“三支柱前提变了”。

这两个问题不一样。

运行不好,可以改流程、换负责人、调汇报线。

前提变了,就要重新问:判断从哪里来,谁先处理,谁复核,谁对结果负责,出错以后怎么回滚。

Ulrich 后续研究也没有停在 1997 年。本库事实表已经标过,Ulrich 这条线后来一直在往 outside-in、价值创造、组织能力这些更外部化的方向走。

所以公开写法要克制。

不是“Ulrich 过时了”。

而是“很多公司仍在用简化版三支柱,处理一个 AI 已经参与判断流动的新现实”。

这才是反向引用的要点。

尊重根系。

但不跪在根系下面。

房晟陶、Ulrich、Wulf,这些都是根系、地图、参照物。

J叔要做的,是把这些根系接到今天老板桌上的问题:

AI 进来后,公司里的判断链到底怎么重写。

SSC 不是没了,是被重新定价了

三支柱里,最先被 AI 咬到的是 SSC。

但这句话别按老方式听。

很多人一听 SSC 被 AI 打到,就马上想:

共享服务中心是不是要没了?

不一定。

我反而觉得,SSC 是三支柱里最容易被重定价、也最容易先找到新位置的一根。

原因很简单。

SSC 本来就是标准化、流程化、高频事务的集中处理层。它存在的意义,不是保留人工动作,而是把组织里重复、稳定、可规则化的 HR 服务做成规模化交付。

AI 来了以后,被拿走的不是 SSC 的价值。

被拿走的是 SSC 过去不得不用人完成的一堆低价值动作。

IBM AskHR 是一个很好的参照。

IBM 官方 AskHR 案例里,AskHR 覆盖 80 个国家和多个业务单元,2024 年处理 210 万次员工对话,约 94% 的员工查询实现自动化。IBM Consulting 的数字交付团队还把一万多个 HR 流程重构为 70 多个工作流,服务交付效率提升 40%。

这组数字不要只当成“机器人客服很厉害”。

那就看浅了。

它真正说明的是:SSC 的底层任务换形态了。

以前共享服务中心的能力是:

有人接。

有人查。

有人办。

有人回复。

现在同一套能力被压缩成了知识库、意图识别、流程编排、权限调用、异常升级和服务监控。

SSC 不再只是共享服务。

它开始变成 AI 工作流编排层。

这个变化,比“少几个 HR 行政岗”重要得多。

媒体报道里有 IBM HR 岗位被替代的说法,但公开正文不能把它当 IBM 官方公告。即使不写这个数字,只看 IBM 官方口径,也足够说明一件事:

HR 高频服务正在从人工工单中心,变成自动化工作流中心。

这对一号位的要求变了。

过去你看 SSC,主要看响应时效、服务满意度、流程合规、成本控制。

现在你看 AI 化 SSC,要问的是另一组问题:

哪些请求可以自动完成?

哪些请求要升级给人?

知识库错了谁修?

服务质量下降到什么阈值触发回滚?

这些不是传统 SSC 主管的手艺。

这更像产品运营、流程治理和责任链设计。

所以 SSC 的危险,不是它被 AI 吃掉。

真正危险的是,公司把 AskHR 这类东西当“客服机器人”采购。

那就完了。

你买到的还是一个工具。

只有当一号位把它当成工作流编排层,重新定义自动处理、人工升级、责任归属和服务质量阈值,SSC 才算完成 AI 时代的重定价。

Klarna 的客服回潮也给这层提了个醒。

高频服务能自动化,不等于复杂问题可以没有真人出口。

AI 能跑量,组织还要设计升级路径。

SSC 的新工作,不是守住每一张工单。

而是设计哪一类工单不该再由人守,哪一类工单必须把人接回回路里。

这一层想明白,SSC 就不是三支柱里先死掉的那根。

它是先换价签的那根。

COE 不是写得更快,是写得能执行

COE 这根柱子的变化,比 SSC 更隐蔽。

大家第一反应通常是:

LLM 能写政策初稿了。

能做制度对标了。

能帮我改一版绩效方案了。

所以 COE 的一部分专业工作会被替代。

这当然会发生。

但这只是皮。

COE 真正被改写的,不是“谁来写政策初稿”,而是“政策以什么形态存在”。

过去 COE 的产出,大多是制度、流程文件、模板、手册、培训材料。

放在网盘里。

放在 OA 里。

放在 SharePoint 里。

放在知识库里。

它们默认是一份文档。

AI 进来以后,文档不再是政策的最终形态。

政策开始进入提示词、权限、校验规则、系统动作和 Agent 边界条件。

员工不是先读完制度再行动。

员工是在流程里被规则约束,在工具里被提示,在异常里被升级,在审计里被追踪。

这就是 COE 更深的变化:

政策承载介质从 Word 文档,迁移到可执行规则。

比如差旅政策。

过去 COE 写一份制度,员工报销时看不看、理解错没错、审批人松不松,很多时候靠后端补救。

AI 进入以后,差旅政策可以直接变成填写表单时的提示、异常金额的拦截、自动解释的规则、需要人工审批的升级条件。

政策不再只是“规范”。

它变成流程里的判断节点。

再比如绩效政策。

过去 COE 定义绩效周期、评分规则、校准机制。

AI 进入以后,会议纪要、项目复盘、目标变更、跨部门协作反馈,都可能被纳入绩效材料。

这时 COE 要回答的就不是:

绩效制度怎么写?

而是:

哪些材料可以被 AI 汇总?

哪些判断不能自动进入评价?

员工有没有申诉权?

AI 生成的绩效摘要谁复核?

这时候,COE 的专业性反而更重要。

只是它不再表现为写一份漂亮制度。

它要把制度拆成边界、规则、权限、例外和回滚。

我自己做 Meta_J 的时候,对这一点很有体感。

过去组织治理像写手册。

现在更像写规则文件、提示词、Hook、Skill 和审稿门禁。

这不是把管理写得更玄。

恰恰相反,是把过去藏在经验里的判断,变成可触发、可检查、可复盘的规则。

哪些断言必须回源。

哪些敏感信息必须脱敏。

哪些内容不能只过格式门禁。

哪些事实必须标注媒体边界。

这些东西如果只写在一份“注意事项”里,就没用。

它要进入流程。

进入检查。

进入版本。

进入责任。

这才是 COE 的新位置。

不是写得更快。

是写得能被执行。

所以 COE 没有被 LLM 简单替掉。

被替掉的是“政策初稿生产者”这一层。

留下来的,是 AI 治理规则设计师:他要决定政策如何进入系统,如何进入提示词,如何进入工作流,如何在出错时被追责和回滚。

如果 COE 还把自己的成果理解成一份 Word,它会越来越边缘。

如果 COE 能把自己的成果改写成规则、边界和可执行协议,它就不是被 AI 挤走。

它是被 AI 逼到真正该站的位置上。

HRBP 剩半个,这半个反而更贵

SSC 换了价签。

COE 换了承载介质。

最后剩下 HRBP。

这根中柱最难受。

因为 HRBP 的存在依据,恰好是“判断必须靠人在人和人之间流动”。

业务现场的信息太碎。

老板的意图太隐。

员工的情绪太杂。

组织里的真实问题,很少直接写在系统字段里。

所以过去需要 HRBP 在中间做判断翻译。

AI 进入以后,这个依据被抽掉了一半。

会议纪要可以被整理。

访谈可以被归类。

绩效材料可以被总结。

岗位画像可以被生成。

员工反馈可以被聚类。

过去 HRBP 靠时间、关系和文字能力积累出来的一大块工作,会被 AI 大幅折扣。

这不是 HRBP 没了。

但 HRBP 确实只剩半个。

被打折的半个,是判断翻译器。

收材料。

整理表达。

转述信息。

写汇报。

做初步归纳。

留下来的半个,是组织诊断师。

判断这些材料背后的组织问题,到底在哪里。

这两个角色听起来相近,实际差很远。

判断翻译器回答的是:

业务在说什么?

老板该听什么?

组织诊断师回答的是:

这件事为什么反复发生?

背后到底是岗位、流程、激励、能力、文化,还是一号位意图不清?

判断翻译器靠勤奋和关系,可以做得不错。

组织诊断师不行。

它要求你有组织模型,有业务理解,有人性判断,也有证据纪律。

AI 可以把材料端上桌。

但材料不是结论。

AI 可以告诉你,五个部门都在抱怨流程慢。

但它不能替你拍板:流程慢,到底是权责设计错了,审批机制错了,还是一号位没有给出清晰优先级。

这就是 HRBP 新半边的价值。

我更愿意把它叫:

组织诊断师。

判断溢价定价师。

组织诊断师负责判断问题在哪一层。

判断溢价定价师负责判断哪些人类判断还值得买,哪些判断可以交给 AI 预处理,哪些判断要保留人工最终裁决。

Wulf 等人在 2025 年 arXiv:2507.14034 里给过一个人机协作光谱,里面有 HITL 和 HOTL。放到 HRBP 这里,术语不是重点。

重点是 HRBP 要知道自己站在哪个回路里。

AI 不确定时,谁接回来?

AI 更自治时,谁在旁边监督?

AI 生成判断时,谁决定它能不能进入正式流程?

如果 HRBP 还把自己理解成“业务伙伴”,这个词会越来越空。

贴近业务只是位置。

不是价值。

AI 进来以后,近不近已经不是核心。

核心变成:你能不能设计人和 AI 的判断边界,能不能知道哪类判断要人审,哪类判断可以机器先跑,哪类判断出错后责任归谁。

这也是我自己简历反复改的原因。

我越来越不愿意把自己写成传统 HR,或者传统组织发展。

因为三支柱之后的位置,已经不是“我懂 HR 管理”。

而是:

我能把组织问题拆成岗位、流程、知识、责任、治理五层,并且知道 AI 进来后哪一层该重写。

对 HRBP 来说,这不是单纯坏消息。

坏消息是,靠转述吃饭的半个自己,越来越不值钱。

好消息是,真正能诊断组织、定价判断、设计人机回路的半个自己,变得更值钱。

所以 HRBP 的未来不是继续贴业务。

新 HRBP 要站的是判断位置:

谁做判断。

谁复核判断。

谁承担判断。

谁为高价值判断付费。

写到这里,三支柱崩塌已经不是 HR 模型问题了。

它变成了一号位的岗位价值重估问题。

别让 HR 自己改 HR

到这里,三支柱的三根柱子都变了。

SSC 没有简单消失。

它被重定价为 AI 工作流编排。

COE 没有简单被 LLM 替掉。

它的政策承载介质,从文档迁移到规则、提示词、权限和系统边界。

HRBP 也不是没了。

它被打折的是判断翻译那半边,留下来的是组织诊断和判断定价那半边。

这不是 HR 部门的灾难。

这是 HR 这个职能的协议层重写。

所以一号位千万别把这件事丢给 HR 自己改。

HR 自己改 HR,很容易改成三件事:

换组织架构图。

改岗位说明书。

重新做一轮能力模型。

这些动作不是没用。

但如果只做到这里,还是在旧接口上修补。

房晟陶、左谦、樊莉在《首席组织官——从团队到组织的蜕变(第2版)》里,把组织能力写成一组能力要素组合:正式组织、人才、文化、工具/设备/AI、流程/机制/系统和其他特别要素。

我这里不展开这套体系。

一笔带过。

因为本篇不是要靠谁背书。

但这个口径有用:AI 不应该只躺在工具采购清单里,它已经进入组织能力公式。

这就把问题从 HR 部门内部,推回一号位桌上。

原来 SSC 承担的高频服务,哪些要变成 AI 工作流,哪些必须保留人工出口?

原来 COE 写的政策制度,哪些要从文档迁移到提示词、规则、权限和审计里?

原来 HRBP 做的业务伙伴工作,哪些只是判断翻译,哪些才是真正值得保留的人类组织诊断?

这些问题答不出来,三支柱就算重新画一遍,也只是换名片。

而且这种换名片,最容易制造一种假进展。

汇报里看起来有动作。

架构图更新了。

岗位名称更新了。

能力词典更新了。

大家还会开几场 workshop,拍几张合照,写一份“AI 时代 HR 转型路线图”。

但一到真实业务现场,问题还是原来的问题。

员工问政策,系统答错了,没有人知道谁修。

业务要用 AI 做绩效摘要,没有人敢说哪些材料不能进评价。

老板想压掉一层流程,没有人能说清楚压掉以后责任谁接。

这不是 HR 不努力。

这是问题已经越过了 HR 的单部门边界。

AI 把服务、政策、判断都拆开了,签字权却还留在旧组织图里。

这才是最别扭的地方。

答得出来,下一刀就会更深。

因为岗位一旦被重写,雇佣契约也要重写。

你过去买一个 HRBP 的时间,是在买他开会、沟通、写材料、跑流程。

AI 进来以后,会议纪要、材料整理、初步分析被折扣掉。

剩下的组织诊断判断,应该怎么定价?

你到底在买人的哪一部分判断?

按什么价格买?

出了错谁负责?

这就是下一篇《新劳动契约》要拆的事。

这一篇先停在这里。

HR 三支柱不是要不要保留的问题。

它原来承载的服务交付、政策承载和判断流动,已经被 AI 拆开重新分配了。

一号位如果还让 HR 自己在旧图纸上修修补补,那就不是转型。

那叫装修。


继续读

也在做类似的事? 欢迎找我 →

J叔

J叔

订阅 J叔内参

只发值得复盘的 AI 组织、Agentic Engineering 和内容建设笔记。不灌水。

HR 三支柱为什么失灵 | J叔内参