-
行业资讯
INDUSTRY INFORMATION
导读：研发用OKR、职能用KPI，表面看是集团绩效改革中的分类管理，实际落地却常常演变成目标对不齐、评分难比较、结果难应用。本文面向集团CHRO、HRD、绩效负责人及业务管理者，围绕混合考核为何卡住这一问题，分析OKR与KPI背后的管理哲学冲突，并提出分层分类、动态衔接的绩效治理框架。
2026年前后，集团型企业的绩效改革进入一个更复杂的阶段。一方面，组织需要用OKR支撑研发创新、产品探索和战略突破；另一方面，财务、人力、法务、运营等职能条线仍需要依靠KPI维持稳定交付、风险控制和经营秩序。于是，研发OKR与职能KPI混合考核，成为不少大型企业看似合理的选择。
但从行业实践看，这套设计经常在落地后暴露出矛盾：研发团队认为OKR被拿去做了刚性奖惩，失去了鼓励挑战的意义；职能团队认为KPI承担了大量保障性工作，却难以在跨部门协同中被看见；集团HR夹在中间，既要统一绩效制度，又要面对不同业务单元对公平性的质疑。
如果结合德勤、麦肯锡等机构近年来关于绩效管理、组织效能与人才管理趋势的公开研究，可以看到一个共同判断：绩效改革越来越不只是考核表单的优化，而是组织目标、激励机制、数据系统和管理文化的重构。本文要回答的问题是：为什么一个看似逻辑自洽的设计——研发用OKR鼓励创新，职能用KPI保障执行——在集团绩效改革中反复卡壳？
一、现象诊断：混合考核的“三重卡点”
集团绩效改革中，OKR与KPI混合考核的困难并不集中在某一个表单或流程节点，而是同时出现在目标、评分和结果应用三个层面。只要其中一个环节被强行拼接，后续环节就会连锁变形。
1. 目标对齐失灵：挑战性目标与确定性指标之间出现断档
在集团场景中，战略目标通常需要向事业部、部门、团队和个人逐层分解。问题在于，OKR与KPI对目标的理解并不相同。OKR强调方向性、挑战性和探索空间，适合研发团队在不确定环境下寻找突破；KPI强调确定性、可量化和可交付，适合职能部门围绕既定职责提供稳定保障。
矛盾往往出现在跨部门协同项目中。例如，一个集团推进新产品平台建设，研发团队的Objective可能是提升平台核心能力，Key Result可能围绕技术性能、用户体验或版本迭代展开；而法务、采购、人力、财务等职能部门承担的是合规审查、供应商评估、人才配置、预算控制等工作。这些工作对项目成功至关重要，却未必能直接转化为研发OKR中的Key Result。
于是，目标分解表面上完成了，实际却出现两类断档：一类是纵向断档，即集团战略落到研发和职能时使用了不同语言，无法追溯到同一战略意图；另一类是横向错位，即研发目标需要职能配合，但职能KPI并不对研发目标负责。长此以往，跨部门协同就容易变成各守各的指标，而不是共同服务一个战略结果。
表格1：OKR与KPI混合考核的核心张力来源
| 维度 | OKR（研发导向） | KPI（职能导向） | 混合张力 |
|---|---|---|---|
| 目标设定 | 挑战性、方向性 | 确定性、可量化 | 对齐失灵 |
| 评分逻辑 | 0.7分即优秀 | 满分达标 | 体系割裂 |
| 结果应用 | 鼓励试错、弱挂钩 | 奖优罚劣、强挂钩 | 应用冲突 |
| 管理哲学 | 发展导向 | 控制导向 | 哲学冲突 |
2. 评分体系割裂：OKR与KPI难以放进同一把尺子
混合考核的第二个卡点，出现在绩效评分阶段。OKR的评分逻辑并不等同于KPI达成率。较经典的OKR实践中，0.7分左右往往意味着目标设定具有挑战性且实现程度较好；如果长期满分，反而可能说明目标不够有挑战。KPI则相反，它以目标值、达成率、权重和扣分项为基础，通常默认满分或高分对应高绩效。
当两套逻辑进入同一场绩效校准会议，管理者很快会遇到比较困境。研发团队拿着0.7分的OKR说明自己完成了高难度突破，职能团队拿着95%或100%的KPI达成率说明自己稳定交付。若强行归一化成同一绩效等级，就容易出现苹果与橘子式的比较：看起来都是分数，背后的含义却不同。
更复杂的是，集团绩效往往还存在强制分布、预算约束和晋升名额限制。评分一旦进入资源分配环节，原本用于复盘和学习的OKR分数就可能被改造成奖惩工具。研发团队会因此降低目标挑战性，职能团队则会更倾向于选择可控、可量化、低风险的指标。混合考核本意是兼顾创新与执行，结果却可能诱发更保守的目标设定。
3. 结果应用冲突：鼓励试错与奖优罚劣发生直接碰撞
绩效管理最终会影响薪酬、奖金、晋升、调岗和人才盘点。只要结果应用没有重新设计，OKR与KPI的冲突就会在利益分配阶段集中爆发。研发OKR强调挑战和试错，意味着目标天然具有不确定性；职能KPI强调稳定和合规，意味着指标达成通常更可预测。
如果企业简单地把OKR分数和KPI得分放入同一薪酬奖金模型，就可能造成两种不公平感。研发人员会认为自己承担了更高不确定性，却因为挑战目标未完全达成而在奖金上吃亏；职能人员则会认为自己长期保障经营秩序，却在组织叙事中被视为不够创新。两类群体都可能感到被低估，只是理由不同。
从管理机制看，目标对齐失灵会导致评分难以解释，评分难以解释又会加剧结果应用争议。混合考核的真正难点不在于OKR和KPI能不能同时存在，而在于企业是否建立了一套能够解释差异、承认差异并治理差异的绩效逻辑。
二、根因剖析：为什么“分类考核”逻辑会失灵？
研发用OKR、职能用KPI的分类考核并非没有道理，但它容易把部门边界误认为管理边界。真正决定考核范式的，不只是部门名称，而是工作性质、协同方式、价值归因和组织权力结构。
1. 管理哲学的深层冲突：发展导向与控制导向并行，需要边界设计
OKR与KPI背后承载的是两套不同的管理哲学。OKR更接近发展导向，关注成长、探索、内在动机和组织学习；KPI更接近控制导向，关注结果、效率、责任落实和外在激励。两者并非天然对立，但如果缺乏边界设计，就会在同一组织中互相削弱。
从组织行为学角度看，自我决定理论强调个体的自主性、胜任感和关系连接对内在动机的重要性。OKR之所以适合研发、创新和战略探索，正是因为它为员工保留了一定自主空间，使团队能够围绕方向性目标开展试验。而KPI强调明确责任、稳定交付和结果约束，更适合流程清晰、产出可定义、风险可控制的工作。
问题在于，不少集团在推行混合考核时，只做了制度层面的划分，却没有回答三个关键问题：哪些工作可以容忍失败？哪些工作不能容忍失败？哪些结果应当强挂钩薪酬，哪些结果更适合作为复盘和发展依据？如果这些边界不清晰，OKR会被KPI化，KPI也会被迫承担创新评价功能，最终两者都失去原有优势。
适用条件也需要说清楚。对于高度合规、风险外溢明显的岗位，如财务结算、法务审核、数据安全、薪酬发放，过度使用OKR可能带来责任模糊；对于基础研究、新业务孵化和产品创新，过度使用刚性KPI则可能压缩探索空间。分类考核不是把工具贴到部门上，而是把管理假设匹配到工作场景中。
2. 跨部门协同中的价值归因黑洞：保障性贡献难以被看见
集团组织中，很多价值不是由单一部门独立创造的，而是在跨部门协同中形成的。研发团队的成果看起来更容易被产品版本、技术指标、用户数据或商业结果呈现；职能部门的贡献则常常是保障性、预防性和间接性的。例如，法务提前识别合同风险，人力及时补齐关键岗位，财务优化预算安排，采购确保关键资源按期到位，这些动作未必能被直接写成研发KR，却会深刻影响项目成败。
这就是混合考核中常见的价值归因黑洞。研发OKR往往围绕业务突破表述，职能KPI往往围绕本部门职责表述，两者之间缺少一套共同定义贡献的机制。结果是，职能部门在跨部门项目中投入大量时间，却难以在自己的考核体系中获得充分体现；研发团队则可能认为职能流程拖慢进度，双方在绩效语境中形成对立。
平衡计分卡的启发在于，组织目标可以从财务、客户、内部流程、学习成长等多维度展开，而不是只盯着单一结果。对混合考核而言，关键不只是把研发和职能的指标放在一张表里，而是为跨部门协同建立价值链视角：哪些活动创造直接业务价值，哪些活动降低风险，哪些活动提升组织能力，哪些活动改善长期效率。
如果没有这类归因框架，集团层面的绩效校准就会依赖管理者主观判断。主观判断不是完全无效，但在奖金、晋升和资源配置中占比过高时，会放大部门话语权差异。强势业务部门更容易把贡献叙事讲清楚，后台职能则容易被压缩为成本中心。
3. 组织权力结构与认知惯性：绩效改革改变的是资源分配规则
绩效改革很少只是HR部门的专业项目。它会改变目标设定方式、评价话语权、奖金分配逻辑和人才流动规则，因此天然会触及组织权力结构。研发OKR与职能KPI混合考核之所以卡住，一个现实原因是各方对改革的收益和风险判断并不一致。
HR部门通常希望通过统一制度提升集团治理能力；业务负责人更关注考核是否影响团队士气和项目推进；职能部门则担心自己的保障性工作被边缘化；员工关心的是最终奖金、晋升和评价公平。各方都能提出合理诉求，但如果没有共同的绩效治理框架，这些诉求就会在校准会议和结果应用阶段集中碰撞。
认知惯性也值得关注。研发负责人未必天然理解OKR，有些人会把OKR当作另一种KPI，只是换了表述方式；职能负责人也未必排斥变化，但他们更习惯用稳定、可控、可证明的指标保护团队利益。当考核方式改变意味着资源分配规则改变时，既得利益方倾向于维持原状并不意外。
因此，混合考核的困境，表层是工具问题，中层是流程问题，深层是组织逻辑问题。只调整评分表、权重和系统字段，难以解决管理哲学、价值归因和权力结构的冲突。真正有效的改革，需要先承认这些冲突存在，再把冲突纳入治理设计。
三、破局路径：构建“分层分类、动态衔接”的绩效治理框架
破解混合考核为何卡住，关键不在于在OKR和KPI之间二选一，而在于让两套范式在同一战略语言、同一价值逻辑和同一数据底座上运行。分层分类、动态衔接，是从工具拼接走向绩效治理的可行路径。
1. 分层：战略层统一，执行层分化
集团绩效改革首先要解决语言统一问题。战略层可以采用战略地图、平衡计分卡或其他战略解码工具，将集团目标拆解为业务增长、客户价值、运营效率、组织能力、风险控制等关键维度。无论研发还是职能，都应从同一个战略源头获得目标，而不是各自从部门职责出发单独设计指标。
执行层则可以保留差异。研发团队在基础技术研究、新产品探索、平台能力建设等场景中，以OKR为主更符合不确定性特征；职能团队在薪酬核算、合规审查、财务结算、流程运营等场景中，以KPI为主更便于责任落实。关键原则是：上层统一语言，下层灵活表达。
这里需要特别避免一种误区：为了统一管理，把所有部门都压成同一套KPI，或者为了体现创新，把所有岗位都改成OKR。前者会削弱探索性工作，后者会模糊确定性职责。更稳妥的做法，是在战略层明确共同目标，在执行层允许不同范式，但要求每个目标都能追溯到集团战略、部门责任和个人贡献。
例如，集团战略目标是提升新产品商业化效率。研发团队可以设置围绕技术成熟度、产品迭代速度、关键功能验证的OKR；法务部门可以设置合同审查周期、重大风险识别率、关键项目响应时效等KPI；HRBP则可以围绕关键岗位到岗、研发人才保留、团队能力建设设置混合型目标。不同表达背后服务的是同一战略意图。
2. 分类：按工作性质而非按部门划分考核范式
比研发等于OKR、职能等于KPI更有效的方式，是按工作性质分类。因为同一个部门内部也可能同时存在探索型、执行型和混合型工作。研发部门中的基础研究与版本交付不同，HR部门中的战略组织诊断与薪酬核算不同，法务部门中的重大交易风险方案与常规合同审核也不同。
按工作性质分类，可以减少部门标签带来的误判。探索型工作通常目标不确定、路径不确定、结果存在试验性，适合OKR为主；执行型工作目标明确、流程稳定、产出可量化，适合KPI为主；混合型工作既有探索要求又有交付约束，可以采用OKR+KPI组合，并通过里程碑、贡献度和关键节点进行衔接。
表格2：按工作性质选择考核范式的实践矩阵
| 工作性质 | 典型场景 | 推荐考核范式 | 衔接机制 |
|---|---|---|---|
| 探索型 | 基础技术研究、战略规划 | OKR为主 | 目标翻译为KPI锚点 |
| 执行型 | 薪酬核算、合规审查 | KPI为主 | 关键节点对齐OKR周期 |
| 混合型 | 产品交付、HRBP业务支撑 | OKR+KPI混合 | 季度OKR复盘→年度KPI校准 |
这张矩阵的价值在于，它把绩效工具选择从组织边界拉回工作机制。对于HR负责人而言，改革前可以先盘点岗位和任务类型，而不是直接按部门分配考核工具。对于业务负责人而言，这种分类能够解释为什么同一团队内部有人使用OKR，有人使用KPI，有人使用混合模型，从而降低公平性质疑。
边界同样重要。工作性质分类需要一定管理成本，如果企业规模较小、岗位边界简单、业务模式稳定，过于复杂的混合模型可能得不偿失。集团型企业之所以更需要这一框架，是因为其业务单元多、协同链条长、岗位类型复杂，简单二分法难以覆盖真实组织场景。
3. 动态衔接：建立OKR与KPI的“翻译机制”
分层和分类解决的是结构问题，动态衔接解决的是运行问题。没有衔接机制，OKR与KPI仍然会在不同周期、不同口径和不同会议中各说各话。实践中，可以围绕目标翻译、周期衔接和结果融合三类机制展开。
第一是目标翻译。OKR中的Key Result需要被转化为跨部门可理解的KPI锚点。例如，研发团队的KR是提升某项系统能力，职能部门可以围绕资源到位率、风险审核时效、关键人才配置周期等设置对应KPI。翻译不是把OKR简单改写成KPI，而是识别不同部门对同一战略目标的贡献位置。
第二是周期衔接。OKR常按季度复盘，KPI常按年度考核。如果两个节奏互不关联，季度复盘无法影响年度评价，年度评价也无法反哺目标调整。更可行的安排是：季度OKR复盘识别目标进展、协同问题和资源缺口；年度KPI校准吸收季度复盘信息，把长期交付、阶段贡献和协同质量纳入评价。
第三是结果融合。绩效校准阶段可以引入贡献度评估矩阵，将OKR进展、KPI达成、协同贡献、风险承担和长期价值放入同一讨论框架。权重不宜一刀切，而应由工作性质决定。探索型工作可以提高OKR进展和学习价值权重，执行型工作可以提高KPI达成和风险控制权重，混合型工作则需要兼顾里程碑交付和目标突破。
图表1：分层分类、动态衔接的绩效治理框架
从大型科技集团的实践经验看，真正有效的混合考核往往不是制度文件写得更复杂，而是把几个关键动作做实：战略解码会议是否有业务和职能共同参与；跨部门目标是否能找到责任链；季度复盘是否影响年度评价；校准会议是否能解释不同分数背后的工作性质差异。没有这些动作，混合考核只是两套工具并行；有了这些动作，绩效管理才可能成为组织协同机制。
四、数字化支撑：让混合考核从“两张皮”到“一张网”
混合考核要从制度设计进入组织行为，最终离不开数字化系统的支撑。系统不是替代管理判断，而是让目标、流程、数据和结果在同一平台上可追溯、可解释、可校准。
1. 数据模型统一：让OKR与KPI能够被关联，而不是被拼接
很多企业的绩效系统看似同时支持OKR和KPI，实际只是把两套模块放在同一个入口下。研发团队在OKR模块里维护目标，职能团队在KPI模块里填写指标，到了校准和奖金计算阶段，再由HR手工汇总。这种做法难以支撑真正的混合考核，因为数据模型本身没有打通。
更有效的数据模型，需要围绕目标、指标、评分、结果四个层级统一建模。OKR中的Objective可以与集团战略主题关联，Key Result可以映射到阶段性成果、关键里程碑或KPI锚点；KPI中的指标、目标值、权重和达成率，也应能够追溯到对应的战略目标或跨部门项目。这样，系统才能回答几个管理问题：某个战略目标由哪些部门共同承担？某个研发KR需要哪些职能KPI支撑？某个绩效结果背后的数据链是否完整？
从数据治理角度看，统一模型还能减少绩效校准中的解释成本。管理者不再只看到孤立分数，而是能够看到目标来源、过程进展、协同节点和结果应用之间的关系。对于集团企业而言，这种能力尤其重要，因为组织层级越多，目标在传递过程中越容易变形。
2. 流程引擎柔性化：支持不同考核范式在同一周期中协同运行
OKR和KPI的流程节奏不同。OKR通常强调设定、对齐、追踪和复盘，周期更短，反馈更频繁；KPI则强调下达、监控、评估和反馈，周期更稳定，结果更刚性。如果绩效系统只能按单一流程运行，就会迫使一种范式服从另一种范式。
柔性流程引擎的价值在于，它允许企业按角色、部门、岗位、工作性质配置不同流程，同时在关键节点上实现统一管理。例如，研发团队可以按季度完成OKR复盘，职能团队可以按月度或年度监控KPI，集团HR可以在统一校准节点调取双方过程数据。流程差异被保留，但治理节点被打通。
这类能力对混合考核尤为关键。因为绩效改革的风险往往不是制度没有写清楚，而是流程执行后留下大量灰色地带：目标调整是否留痕，跨部门协同是否确认，复盘意见是否进入年度评价，校准依据是否可追溯。系统如果不能承接这些管理动作，混合考核就容易退回线下会议和人工协调。
3. AI辅助目标拆解与校准：提高一致性，但不能替代管理责任
AI在绩效管理中的应用，首先可以用于目标拆解和对齐缺口识别。系统可以基于集团战略、部门职责、历史目标和项目计划，辅助生成目标建议，提示OKR与KPI之间可能存在的断点。例如，某个研发KR需要法务、采购或HR支持，但相关职能部门未设置对应指标，系统可以提示目标链条不完整。
其次，AI可以用于绩效校准支持。它可以汇总过程数据、目标调整记录、协同反馈和历史评分分布，为管理者提供校准建议，帮助识别评分偏差、异常波动和评价口径不一致。但需要强调的是，AI只能提供分析辅助，不能替代管理者对工作复杂度、风险承担和组织贡献的判断。尤其在涉及薪酬、晋升和人才决策时，企业仍需保留清晰的责任主体和申诉机制。
图表2：支撑混合考核的数字化系统四层架构
数字化不是混合考核的装饰项，而是必要条件。没有统一数据底座和柔性流程引擎，混合考核会停留在制度文件层面；有了系统支撑，企业才可能把战略目标、部门协同、绩效复盘和结果应用连接成一张可治理的网络。
红海云总结
回到开篇提出的问题，研发OKR与职能KPI混合考核为何卡住，并不是因为OKR或KPI本身失效，而是因为组织在分类考核的表层逻辑下，回避了管理哲学冲突、价值归因难题和权力结构博弈。对2026年推进集团绩效改革的企业而言，红海云认为，更值得关注的是绩效治理能力，而不是单一工具选择。
可执行的改革建议包括：
- 先定义容错边界和激励逻辑：区分哪些工作适合鼓励挑战，哪些工作必须稳定达成，避免把OKR做成刚性KPI，也避免让KPI承担探索性目标。
- 按工作性质选择考核范式：不要简单套用研发等于OKR、职能等于KPI的部门划分，应围绕探索型、执行型、混合型任务建立考核矩阵。
- 建立OKR与KPI的翻译机制：通过目标翻译、周期衔接和结果融合，让不同范式能够进入同一绩效校准框架。
- 把跨部门贡献纳入评价链条：对保障性、预防性、协同性贡献建立可记录、可复盘、可讨论的归因机制。
- 选择能够承接异构考核的数字化平台：绩效系统需要支持统一数据模型、柔性流程引擎和AI辅助校准，使混合考核从制度设计进入日常管理行为。
绩效改革的真正考验，不是写出一套更复杂的制度，而是让制度逐步成为组织的行为习惯。混合考核的落地，需要治理思维，也需要能承接治理逻辑的数字化基础。
