2.1 二级部门 KPI 解码流程

2.1.1 承接上级指标（红钉子）

二级部门首先需承接一级部门下发的 KPI 指标，这类指标属于 “红钉子” 指标，是考核的核心权重来源，在部门总考核权重中不得低于 60%-70% ，确保部门工作聚焦核心目标，不偏离战略方向。

承接过程中需对指标进行严格审视，明确指标的底线值、目标值和挑战值，避免模糊化表述，确保指标可衡量、可落地。例如华为终端软件部承接的 “鸿蒙 NEX 上市时间”“鸿蒙系统流畅度” 等指标，均为明确的红钉子指标，直接关联公司级战略意图。

2.1.2 自建 KPI 的生成逻辑

除上级下发的红钉子指标外，二级部门可根据实际需求生成自建 KPI，核心来源包括三类：

• 支撑红钉子指标达成的过程性保障要素，例如为实现 “研发效率提升 20%” 的红钉子指标，衍生出 “研发工具链效能提升” 相关过程指标；
• 部门自身短板补齐需求，如针对 “遗留代码 bug 多” 的问题，设立 “遗留代码重构率” 指标；
• 部门独特机会挖掘，如基于行业竞争态势，设立 “软件专家人才密度” 等能力建设类指标。

自建 KPI 需避免 “自嗨式” 设定，必须与公司级或一级部门目标存在强关联，无关联的自建指标应坚决剔除，确保指标体系的聚焦性。

2.1.3 构建部门平衡计分卡（BSC）

将上级下发 KPI 与自建 KPI 整合，按照平衡计分卡的四个维度（财务、客户、内部流程、学习与成长）进行分类梳理，明确每个指标的权重、计算方式和考核周期。

以华为终端软件部为例，其平衡计分卡包含：

• 财务维度：与公司营收、利润挂钩的间接指标；
• 客户维度：系统流畅度、用户体验相关指标；
• 内部流程维度：遗留代码重构率、编译效率等；
• 学习与成长维度：软件专家人才密度、技术培训覆盖率等。

2.1.4 指标向下拆分至三级部门 / 个人

若公司规模较大设有三级部门，二级部门需将自身 KPI 进一步拆解为三级部门的红钉子指标，形成完整的指标价值树；若无需设立三级部门，则直接拆解至个人层面。

拆分过程可借助 AI 工具（如 DeepSeek、豆包、GPT 等）辅助完成，例如输入 “华为手机销量指标拆解”，即可获得从公司到个人的完整拆解示例，确保拆解逻辑的合理性与准确性。

2.2 二级部门重点工作解码流程

2.2.1 承接上级重点工作并做 WBS 分解

二级部门需承接一级部门下发的重点项目，按照项目管理 WBS（工作分解结构）方法，将项目拆解为可执行的子任务，并明确每个子任务的时间节点（如 Q1-Q4 的阶段性目标）、交付物要求、预算分配和责任主体。

例如华为终端软件部承接 “鸿蒙原生 Mate70 首发” 项目后，拆解为 Q1 设计阶段、Q2 开发阶段、Q3 攻坚阶段、Q4 上线阶段，每个阶段均明确具体交付物（如设计方案、测试版本、正式版本等）。

2.2.2 自建重点项目的三大来源

自建重点项目与自建 KPI 逻辑同源，核心来源包括：

• 填补 KPI 达成缺口：为实现上级下达的 KPI，针对存在的能力或资源缺口设立项目，如为达成 “研发效率提升 20%” 目标，设立 “研发工具链效能提升项目”；
• 解决部门运营痛点：针对日常工作中的核心问题设立专项项目，如针对 “老代码 bug 多、维护成本高” 的痛点，设立 “技术债清洗专项项目”；
• 应对行业竞争挑战：基于竞争对手动态和行业发展趋势，设立前瞻性项目，如采购部门为保持竞争优势，设立 “供应商能力提升对标项目”。

自建项目需严格控制数量，避免 “多而不精”，同时需明确量化目标，例如 “编译加速工程项目” 需设定 “将编译时间缩短至 30 分钟” 的具体指标。

2.2.3 重点工作的审视与精简

将上级承接项目与自建项目整合后，需进行严格审视与精简：

• 剔除与战略目标无关联的项目；
• 合并重复或可替代的项目；
• 优先保留影响核心指标达成的 A 类项目，精简非核心的 B、C 类项目。

传统经营计划中常见的 “自下而上填项目” 模式，容易导致重点分散、资源浪费，而战略解码体系下的重点工作以 “自上而下为主、自下而上补充” 为原则，确保所有项目均围绕核心战略展开。

2.3 部门内部协同互锁机制

2.3.1 双源扫描识别协同需求

部门内部及跨部门协同需通过 “双源扫描” 方式识别关键节点，确保无遗漏：

• 从 KPI 扫描：分析实现本部门 KPI 过程中，哪些环节依赖其他部门支持，若其他部门掉链子将直接影响本部门指标达成，例如软件部 “系统流畅度” 指标依赖硬件部的散热控制能力；
• 从重点项目扫描：梳理重点项目执行过程中的前置条件和关键依赖，识别需要其他部门配合的卡点，例如软件部开发鸿蒙系统需硬件部提供原型机和产品定义书。

2.3.2 协同需求的谈判与确认

识别出协同需求后，需与相关部门进行正式谈判，明确责任边界和交付标准。谈判过程中需以公司级战略目标为最高准则，避免部门利益优先。

例如产品线与软件部的谈判中，产品线以 “Mate70 上市时间为公司顶层目标” 为由，要求软件部 9 月 1 日前完成版本封板，即使软件部存在数千个 bug 需要修复，仍需以公司战略为重，最终达成一致并明确责任。

2.3.3 固化协同矩阵与契约化

谈判达成一致后，需形成正式的协同矩阵，明确：

• 协同事项名称、需求部门、责任部门；
• 交付物、交付时间节点；
• 考核标准与责任追究机制。

协同矩阵是后续签订协同契约的基础，需确保所有协同事项均实现 “契约化管理”，而非依赖口头沟通或团队精神，避免后续推诿扯皮。例如软件部与硬件部签订的 “散热控制指标契约”，明确硬件部需达到的散热标准，未达标将直接影响硬件部考核。

2.4 二级部门绩效合同签订

2.4.1 预算拆解（前置条件）

若公司实行全面预算管理体系，在签订绩效合同前需完成预算拆解：

• 按照重点项目和 KPI 达成需求，分配相应的预算资源；
• 若预算与项目需求不匹配，需调整项目优先级，优先保障核心项目的预算支持；
• 无预算管理体系的公司，可简化此步骤，但需明确项目资源保障措施。

2.4.2 绩效合同的 “三件套” 核心内容

二级部门与一级部门签订的绩效合同包含 “三件套” 核心内容，总权重分配为：

• KPI 类指标：占比 60%，以平衡计分卡形式呈现；
• 重点项目：占比 30%，包含项目执行计划和资源锁定计划；
• 跨部门协同契约：占比 10%，明确协同事项的考核标准。

此外，合同中需增设 “否决项（红线指标）”，如安全事故、合规风险等，一旦触发否决项，部门考核将直接清零。

2.4.3 合同签订的仪式感与严肃性

绩效合同签订需注重仪式感，通过正式的签字流程强化责任意识：

• 二级部门负责人与一级部门负责人双向签字确认；
• 跨部门协同契约需相关部门负责人共同签字；
• 合同签订后需进行公示，确保全员知晓责任与目标。

合同签订后即具有 “军令状” 性质，后续需严格按照合同执行，避免中途随意调整目标或推诿责任。

2.5 三级部门及个人 PBC 解码

2.5.1 指标与重点工作的最终拆解

三级部门解码逻辑与二级部门一致，继续沿用 “俄罗斯套娃” 模式，将二级部门的 KPI 和重点工作拆解为三级部门的核心目标。若公司无三级部门，则直接拆解至个人层面，确保：

• 每个岗位的指标均能追溯至公司级战略目标；
• 每个重点项目均分解至具体的执行岗位；
• 拆解过程中需避免指标 “稀释”，确保每个岗位的目标都具有实质性意义。

2.5.2 个人 PBC 的四大核心模块

个人 PBC（个人绩效承诺卡）需承接部门级目标，核心包含四大模块：

• 结果性指标（权重 50%）：从部门 KPI 拆解而来的个人核心指标，需明确量化目标、底线值、目标值和挑战值，例如图形算法工程师的 “负责模块丢帧率”“算法平均渲染耗时” 等指标；
• 执行措施（权重 30%）：从重点项目拆解而来的个人具体任务，明确个人在项目中的角色、交付物和时间节点，例如 “参与动效引擎 2.0 算法重构，Q2 前完成核心代码编写”；
• 团队协同（权重 20%）：从跨部门协同契约拆解而来的个人协同责任，明确需支持的部门、协同事项和交付标准，例如 “配合硬件部完成原型机测试，提供算法优化建议”；
• 个人成长（不占考核权重）：针对个人能力短板的改进计划，如 “学习鸿蒙系统最新开发技术，Q3 前取得相关认证”，作为晋升和评优的参考依据。

个人 PBC 需通过主管与员工一对一沟通确定，确保员工理解目标意义、认可目标难度，避免 “单向下达”。

2.5.3 个人 PBC 的签订与宣贯

个人 PBC 签订后，需通过部门宣贯大会强化全员共识，宣贯内容需包含 “三部曲”：

• 讲形势：明确公司面临的市场环境和竞争压力，如 “Mate70 若不能搭载纯血鸿蒙上市，华为手机业务将遭受滑铁卢”；
• 讲战略：传达公司级和部门级战略目标，说明个人目标与公司战略的关联；
• 讲逻辑：解释个人 PBC 指标的由来和考核逻辑，让员工明白 “为什么要做”“做不好的影响”。

宣贯大会的核心是统一思想、凝聚共识，让员工从 “要我做” 转变为 “我要做”，增强目标认同感和执行动力。