ERP 实施 KPI：真正重要的 30 个指标

真正重要的 ERP 实施 KPI 是一小组指标：交付期间每周评审，hypercare 期间每天评审，每项都有指定的负责人。它们是进度符合度、成本偏差、范围变更、测试通过率、数据迁移准确率，以及最重要的用户采用率。下面是我使用的 30 个 KPI，分为交付阶段和上线后两类，附有公式和应触发行动的阈值。

本文写给项目总监、PMO 负责人和发起人，他们需要一份能在第 8 周而不是第 18 个月就发现问题的指导委员会汇报材料。

一位客户曾在 SAP 项目中新增了 73 项“小”变更。单独看，没有一项显得重要。合在一起，它们造成了五个月的延误。没有人跟踪范围变更的数量。（如果这听起来很熟悉，我那篇关于如何避免 SAP 项目范围蔓延的指南讲了相应的控制手段。）

另一位客户无视早期的进度预警，一个原定一年的项目用了十八个月。一家零售客户无视早期的预算预警，最后只能砍掉关键功能才得以完工。

这些失败并不罕见。这是团队跟踪了错误的东西，或者什么都没跟踪时会发生的事。

#	KPI	衡量什么	为什么重要
1	进度符合度	任务实际完成与计划完成的对比	连锁延误的第一个信号
2	成本偏差	按阶段对比实际支出与预算	在超支叠加之前发现它们
3	范围变更数量	已批准变更的数量和影响	失控的变更是超支最常见的原因
4	资源利用率	实际工时与计划工时；工作负荷平衡	负荷过重的人会在项目中途倦怠或离职
5	用户采用率	积极使用系统的目标用户占比	唯一能告诉您系统是否对业务发挥作用的指标
6	培训有效性	考核分数；已接受培训的用户占比	在上线之前就预示采用失败
7	数据迁移准确率	干净迁移的记录占比；错误率	新系统里的坏数据要花几个月才能清理
8	测试环境停机时间	测试系统中非计划停机的小时数	测试中的不稳定预示着上线时的不稳定
9	参与度得分	调查结果；关键会议的出席情况	在抵触情绪公开浮现之前的早期预警
10	风险解决率	按计划关闭的未决风险占比	衡量关闭，而不只是识别
11	合作伙伴绩效	交付物质量；里程碑达成率	早期交付物就延误的合作伙伴，几乎总会延误后面的
12	测试通过率	一次通过的测试用例占比	SIT 中低于 85% 通常意味着系统性问题，而不是随机的缺陷
13	变更请求周转时间	从提出请求到做出决定的天数	长长的队列预示着治理失灵
14	预算消耗率	支出与总预算的对比，对照已完成的工作	显示资金和进度是否同步推进
15	配置进展	已完成的计划配置项占比	这里的滞后会把测试和培训往后推

#	KPI	衡量什么	阈值或说明
16	系统可用性	上线后的正常运行时间	超过 99.9% 为良好；低于 99% 就成了用户信心问题
17	报表和仪表板速度	加载时间；刷新频率	如果经理们导出到 Excel，说明系统没有发挥作用
18	员工生产力	任务耗时与上线前基线对比	一家分销客户将审批自动化后，上线后每天多处理了 25% 的交易
19	首次联系解决率	首次联系即解决的工单	衡量 hypercare 的有效性
20	支持工单数量	未关闭工单；平均解决时间	第 30 天前后的激增，通常说明培训有缺口，而不是系统有缺陷
21	流程周期时间	订单处理、发票审批、关账周期	高管真正关心的结果
22	库存准确率	实物盘点与系统数量对比	上线后最直观的数据质量指标
23	订单履约率	新系统中按时履约的订单	对运营的直接影响
24	收入归因	与新能力相关联的收入变化	业务案例的长期证明
25	合规符合度	审计发现；监管问题	在财务、制药和受监管行业最为重要
26	预测准确率	预测与实际需求对比	显示计划功能是否被使用并被信任
27	用户满意度	可用性调查；关键用户的 NPS	讨厌系统的用户会自建变通办法
28	流程效率	每个流程的时间和成本与基线对比	向董事会证明投资的合理性
29	已实现的节省	实际节省与业务案例对比	CFO 会在 6 个月和 12 个月时来问
30	投资回报率	净收益除以总成本	通常在 12 个月和 24 个月时衡量

这些是大家问得最多的。

1. 进度绩效指数（SPI） = 挣值 ÷ 计划值。高于 1.0 表示提前，1.0 表示准时，低于 1.0 表示延误。
2. 成本绩效指数（CPI） = 挣值 ÷ 实际成本。高于 1.0 表示高效，低于 1.0 表示超预算。
3. 范围变更百分比 = (已批准变更 ÷ 初始范围项) × 100。低于 10% 影响很小；高于 20% 影响很大。
4. 用户采用率 = (活跃用户 ÷ 目标用户) × 100。前 90 天内高于 80% 为强；低于 60% 需要干预。
5. 数据迁移准确率 = (干净迁移的记录 ÷ 尝试迁移的记录) × 100。上线前高于 98%；低于 95% 应推迟切换。

SPI 和 CPI 来自挣值管理。只有“挣值”被诚实地度量，它们才有效：一个 90% 完成了三周的任务，并不等于完成了 90% 的价值。

没有评审节奏的 KPI 只是装饰。下面是应该建立的节奏。

1. 交付期间每周项目委员会进度、成本、风险、测试通过率、范围变更。关口 KPI 提交指导委员会
2. 第 1 至 30 天每日 hypercare 评审可用性、工单数量、各部门的采用情况
3. 至第 90 天每周采用度评审采用率、流程周期时间、工单类别
4. 第 6 和第 12 个月发起人与 CFO 评审生产力、已实现的节省、ROI

时间	KPI	评审人	它支撑的决策
交付期间每周	进度符合度、成本偏差、风险解决、测试通过率、范围变更数量	项目委员会	重新规划、升级或守住范围
每个阶段关口	配置进展、培训有效性、数据迁移准确率、合作伙伴绩效	指导委员会	通过、有条件通过或叫停
上线后头 30 天每天	可用性、工单数量和趋势、各部门采用情况	hypercare 负责人	现场支持和修复该投向哪里
每周，至第 90 天	采用率、流程周期时间、工单类别	项目委员会	复训、配置修复
第 6 和第 12 个月	生产力、已实现的节省、ROI、满意度	发起人与 CFO	业务案例签字确认、第二阶段范围

我的一位制药客户给每个里程碑都指定了一位负责人和一位备份。与它之前那次 SAP 尝试相比，它的进度符合度大幅改善。等到月度评审发现延误时，它已经是结构性的了。

关口决策应该基于证据，而不是基于日历。而且到上线后第三个月，变通办法已经成了习惯，所以采用度的窗口关闭得比大多数团队预期的更快。如果您的指导委员会需要重置，我在如何组建有效的 SAP 项目指导委员会中讲了怎么运作。

RISE with SAP 和 SAP GROW 项目带来了传统清单未涵盖的治理问题。有三项额外的度量会有帮助。

Clean Core 等级分布

SAP 现在把扩展按四个 Clean Core 等级分级，A 到 D。A 级只使用已发布的 API；D 级则不是 Clean Core。使用 SAP 推荐的 ABAP Test Cockpit 检查，跟踪各等级扩展的占比。

在 Public Edition 上，一切按设计都是 A 级。在 Private Edition 和本地部署上，任何 C 级或 D 级扩展都是债务，会在下一次升级时浮现。在 Realize 阶段，每周对照这一点审查新的扩展请求，并让某个人为每一项 C 级或 D 级的批准负责。

扩展位置已确定

公式：(已确定等级和位置的扩展 ÷ 待办事项中的扩展总数) × 100。目标是在 Explore 阶段结束时达到 100%。一个还没人给它定位的扩展，就是那个会在截止期限压力下变成传统修改的扩展。

与 SAP 关系的健康状况

在 RISE 项目上，每季度做一次定性评审，因为 SAP 运行基础设施和运维，也是交付的一部分。平台升级问题是否在约定的服务水平内解决？SAP 的成功评审是实质性的还是仪式性的？评分低通常预示着团队没有准备好的项目中途升级。

AI 对围绕指标的报告工作很有用。它不能取代评审。

1. Joule 与 SAP Cloud ALM。 SAP 已把 Joule 加入 Cloud ALM，团队因此可以用自然语言查询项目和运维数据，而不必手工制作每一份状态提取。
2. Power BI 中的 Copilot。 根据底层仪表板起草指导委员会材料的叙述性摘要。数据模型干净时效果最好。
3. 异常检测。 Power BI、Tableau 和 SAP Analytics Cloud 可以标记偏离常规模式的 KPI。适用于资源利用率、工单数量和范围变更率。不适用于自然波动很大的指标，例如每日订单数。

AI 解决不了的是政治层面的工作。仪表板可以把进度滑坡标红六周。如果指导委员会不采取行动，滑坡就会继续。

影响最大的 KPI 是用户采用率，也是大多数团队最后才衡量的一项。

我有一位制造业客户，他们的高管把所有数据都导出到 Excel。这是个巨大的警示信号。数据是有的，他们需要的仪表板却没有。我们修好了仪表板，决策时间缩短了一半。

一个技术上能运行、实际中却被绕开的系统，什么都没有交付。变革管理的研究也印证了这一点：Prosci 长期以来的研究发现，变革管理出色的项目，达成目标的可能性是变革管理糟糕项目的约七倍。

最好的 KPI 仪表板不是最完整的那个，而是指导委员会愿意看的最小指标集，每一行都有负责人，并且红灯连续两个周期不消时有相应的后果。大多数 KPI 项目失败，是因为跟踪了正确的东西，然后又无视了它们。如果数字已经是红色，该怎么办，请看让 SAP 项目回到正轨。

最重要的 ERP 实施 KPI 是什么？

用户采用率。技术上成功、却没人使用的实施，不会带来任何业务价值。其他 KPI（进度、预算、测试）保护的是采用的条件。采用率告诉您采用有没有发生。

从上线后第一周起，按部门跟踪它。某个团队的采用率低，通常指向培训缺口或流程设计问题，在 hypercare 期间还来得及修复。

ERP 实施 KPI 应该多久评审一次？

进度、成本和风险在交付期间每周评审，而不是在指导委员会上每月评审。阶段关口 KPI 在每个关口评审。运营 KPI 在上线后头 30 天每天评审，然后每周评审，直到第 90 天。

SAP UAT 的测试通过率多少算健康？

系统集成测试中一次通过率高于 85% 是健康的。低于这个水平，通常意味着流程设计缺口或配置错误，而不是孤立的缺陷。

如果进入 UAT 时低于 85%，请停下来修复根本原因。UAT 几乎不可能清理 SIT 遗漏的问题。

范围变更百分比超过 20% 对 ERP 项目意味着什么？

项目正在中途被重新设计。超支和延误变得很可能。

趋势比数字更重要。如果变更随着项目成熟而加速，而不是趋于平稳，说明治理正在失灵。每项获批的变更都需要有成本和进度影响说明。如果没有，范围就失控了。

RISE with SAP 项目有哪些特有的 KPI？

在标准的 30 项之外再加三项：扩展的 Clean Core 等级分布（A 到 D）、已确定等级和位置的扩展占比，以及每季度对与 SAP 关系健康状况的评审（升级问题、服务水平、SAP 成功评审的质量）。

如何计算 ERP 实施的 ROI？

ROI = (净收益 ÷ 总投资) × 100。净收益是可归因于系统的可衡量节省和收入增长，减去新环境的运行成本。总投资涵盖软件、实施、内部时间、培训、数据迁移和持续支持。

要保守。完整的收益很少在第一年到来。建立一个爬坡模型：第一年为稳态收益的 50%，第二年 80%，第三年起 100%。

ERP 实施预算超支的主要原因是什么？

未被跟踪的范围变更，因质量问题浮现得晚而远远超出计划的数据迁移，在测试中才发现的集成故障，以及启动太晚、推高上线后支持成本的变革管理。

每周成本偏差跟踪和正式的范围控制应对第一项。早期的数据质量评估应对第二项。用真实数据量做早期集成测试应对第三项。从一开始就做变革管理应对第四项。