需要避免的 10 个 ERP 现代化错误

伤害最大的 ERP 现代化错误是战略性的，而不是技术性的：把上线当作终点，把遗留流程照搬进新系统，数据和变革工作启动太晚，把一切都建进 ERP，以及在没有五年模型的情况下签署许可证。它们很少实时显现。它们在上线之后才浮现，那时承诺的效率没有出现，变通办法又回来了。

本文写给正在规划或挽救 S/4HANA 或其他 ERP 现代化项目的 CIO、CFO 和项目总监。下面的每个错误都附有它在实践中的样子和修复办法，随后是一页纸的早期预警清单，以及 2026 年 SAP 的变化意味着什么。

我见过资金充足、团队经验丰富、顾问阵容齐全的项目，仍然没有达到预期。原因很少是系统本身。而是归属、集成规划，以及彼此决策相互依赖的团队之间的沟通出现了缺口。

1. 把上线当作终点

系统一上线，许多团队就以为重活已经干完。真正的压力恰恰从这时开始：日常运营、不断变化的需求和真实的用户行为，都在冲击设计。

我见过一些项目，指导委员会在上线后立即解散。六个月之后，采用率停滞不前，没有人负责待办事项。

修复办法： 为上线后的 6 至 12 个月提供有资金保障的治理期。延长指导委员会的授权。监控流程采用情况，而不仅仅是正常运行时间。设置带有指定负责人的上线后质量关口。

2. 不加反思地迁移遗留流程

我见过整条审批链被原样重建，即使其中一半的参与者与当前流程毫无关系。没有人问过这些步骤是否还需要。结果是一个现代的 ERP 在运行旧的工作流：一个更贵的、与原来一样的版本。

S/4HANA 版本的这个问题：自定义批处理作业原样从 ECC 搬过来，而它们依赖的表结构已经不存在。迁移在技术上是干净的。业务逻辑却坏了。

修复办法： 在构建之前重新设计流程。带着运营、财务和交付团队一起走一遍每个工作流，并质疑每一个步骤。

遗留领域	常见问题	应该怎么做
来自 ECC 的自定义代码	未使用的自定义代码被搬进 S/4HANA	运行使用情况分析和 SAP 的自定义代码检查；淘汰未使用的代码
旧工作流	在已经可以自动化的情况下重建审批流	与业务负责人一起重新审视；使用标准 Fiori 应用或 SAP Build Process Automation
非标准主数据	灵活的遗留设置无法通过 S/4HANA 校验	迁移前清理并统一，合适时使用 SAP MDG
基于遗留表的报表	直接访问表与 S/4HANA 的数据模型不匹配	在 CDS 视图上重建
隐藏的手工变通办法	上线后旁路流程重新出现	迁移前使用流程挖掘，并把缺口数字化

3. 数据迁移启动太晚

把坏数据搬进新 ERP，就像搬家时什么都不扔。杂物会跟着您走，一旦进入结构化的系统，就更难清理。

我曾见过一次上线失败，因为没有人发现一个核心数据集里的条目来自五个不同的业务单元，各有各的编码逻辑。技术迁移是正确的。数据却不可用。报表出错，用户失去信任，在运行中的系统里清理又花了几个月。

修复办法： 把数据做成一个由业务负责的工作流。指派流程负责人，而不只是技术顾问。在迁移开始之前决定哪些带过去、哪些归档、哪些重建。至少运行两次完整的模拟加载，附带加载顺序的依赖关系图，以及每次加载的明确回退办法。我那篇关于 SAP 数据迁移为何失败的文章讲得更深。

4. 把变革管理当作附带任务

常见的版本是：变革管理“已经处理过了”，意思是上线前有几页幻灯片、一次演示和一场培训。

人们抵触，并不是因为不喜欢变化。他们抵触，是因为没有人解释为什么要变、变化对他们有什么好处。他们只是刚好够应付检查清单地使用系统，然后回到电子表格。

通常的触发因素是进度压力：培训被压缩以挽回时间，用户在上线时不知所措，额外的 hypercare 比被砍掉的培训花得更多。

修复办法： 从一开始就给变革管理独立的预算、时间表和高级别负责人。尽早梳理角色，找出本地的推动者，并在技术里程碑之外跟踪采用度 KPI。我的变革管理计划指南列出了结构。

5. 围绕供应商路线图做规划

我见过团队把集成策略建立在供应商未来的版本上，结果该版本被推迟了 12 个月。在此期间，他们只能被迫搭建临时的变通办法，而这些变通办法变成了永久的。

供应商为广泛的客户群体制定路线图。您的业务很少是那个设计的中心。

修复办法： 把路线图当作输入之一。围绕今天已正式发布的能力来设计，在规划依赖新功能之前先在沙箱里测试，并把路线图带来的好处算作额外收益，而不是预算。

6. 没有遗留系统的停用计划

我曾见过一家公司每年花六位数的费用，让一个旧系统继续运行，只为六个每年要提两次报表的用户。没有人制定过停用计划。

修复办法： 从第一天起就把停用写进项目章程，让法务、合规和数据治理参与，而不只是 IT。在上线之前，就保留期限和归档方式达成一致，梳理并断开通向旧系统的每一个接口，并让一个团队负责把它关掉。

7. 低估集成的复杂性

集成失败时，业务部门比 IT 更早察觉，因为工作流是在生产环境里中途停下的，而不是在测试系统里。

常见的模式是：IT 和业务各自以为对方已经定义了集成需求。结果两边都没有。等缺口在测试中浮现时，已经没有时间重新设计。

修复办法： 在蓝图阶段就启动集成设计。定义每个场景、中间件、映射和消息量，并与业务确认每个接口是实时还是批处理。在上线前指定带 SLA 的接口负责人。对于新的 SAP 项目，中间件是 SAP Integration Suite；SAP PI/PO 在 2027 年底退出主流维护。

8. 以为 ERP 能处理一切

我参与过的项目里，团队因为不想引入 ServiceNow 这类外部系统，就把复杂的服务工作流（IT 工单、资产申请、升级路由）硬塞进 ERP。结果是到处都是自定义字段、手工变通办法，用户被困在一个始终不合适的流程里。

ERP 擅长结构化的、交易型的、以财务为锚点的流程。专用平台在 IT 服务请求、工作流编排和知识管理方面做得更好。

修复办法： 有意识地决定哪些东西不在 ERP 里构建。例外情况使用 SAP BTP 上的并行（side-by-side）扩展，交易核心之外的编排使用 ServiceNow 或类似工具。我那篇关于 SAP 与 ServiceNow 的 ERP 现代化的文章讲了这种拆分。

9. 低估长期许可证成本

我知道一个团队在第二年把许可证支出翻了一倍，因为它需要一个藏在更高级别许可证背后的单一功能。它的业务案例只对上线成本建了模。

ERP 许可证按用户、模块、交易和 API 使用量收费，无论您有没有规划，成本都会随业务规模增长。在 SAP 上，Digital Access 模式意味着第三方系统创建的单据可能带来原始商务模型中没有的许可证成本。在 RISE 和 SAP GROW 下，Full User Equivalent（FUE）的数量随采用度增长。

修复办法： 在签约前建立三到五年的许可证模型。把角色映射到许可证类型，按现实的采用曲线对 FUE 增长建模，在连接外部系统之前理解间接访问，并在上线后审计不活跃的用户。

10. 把 ERP 当作 IT 项目

最常见、也最具破坏性的模式。规划从 IT 开始，由 IT 主导，解决的是 IT 的问题。

我见过团队在纸面上完成每一个里程碑，业务却仍在问为什么没有任何好转的感觉。这通常意味着 ERP 是为昨天的流程构建的，设计里没有运营、财务或商务负责人。

修复办法： 从一开始就让商务、财务和运营的负责人进入指导委员会。把战略一致性写进章程，而不只是技术范围。在设计开始之前，用董事会层面的成果来检验项目目标。

每次指导委员会都用它。如果出现某个预警信号，指定的负责人就要汇报，直到它消失。

1. 章程归属与成本没有运营或财务负责人，没有五年许可证模型，没有停用日期
2. 蓝图流程与集成设计照搬今天的流程，接口仍未设计
3. 首次模拟加载数据还没有数据质量报告
4. 上线之后会发生什么上线后的 12 个月没有资金保障的治理

错误	早期预警信号	负责人
1. 把上线当作终点	上线后的 12 个月没有资金保障的治理计划	发起人
2. 照搬遗留流程	设计研讨会从“我们今天怎么做”的界面出发	流程负责人
3. 数据工作太晚	首次模拟加载之前没有数据质量报告	数据迁移负责人
4. 变革是附带任务	变革计划只是一份培训日历	变革负责人
5. 依赖路线图	某个设计决策在等待一个尚未发布的功能	解决方案架构师
6. 没有停用计划	章程中没有任何遗留系统的退役日期	PMO
7. 低估集成	蓝图结束时接口尚未设计	集成负责人
8. 让 ERP 包办一切	为非交易型工作流创建自定义对象	企业架构师
9. 许可证	业务案例中没有五年许可证模型	CFO
10. 只有 IT 的项目	指导委员会中没有运营或财务负责人	发起人

部署。 对于新的 SAP 项目，默认选择是基于 SAP Cloud ERP Private 的 RISE with SAP，或者对中型公司而言是 Public Edition（SAP Cloud ERP）上的 SAP GROW。新的本地部署已经很少见。ECC 客户面临的是主流维护于 2027 年 12 月 31 日结束，这缩短了用来修复错误 2、3 和 7 的时间。

Clean Core。 SAP 现在把扩展按四个 Clean Core 等级分级，从 A 级（只用已发布的 API，在 BTP 上并行扩展，或在系统内用 ABAP Cloud）到 D 级（不干净）。Public Edition 只允许 A 级，这迫使人们展开错误 2 背后的那场讨论。Private Edition 仍允许经典扩展，所以这种纪律必须来自治理。经典的自定义代码正是让每次升级成为一个项目的原因。我的 Clean Core 战略一文讲得更深入。

交付工具中的 AI。 Joule 现在已经出现在 SAP Cloud ALM 和 SAP Activate Roadmap Viewer 中，SAP Build Code 使用 Joule 进行扩展开发。请问问合作伙伴，AI 工具是如何体现在其费率表中的。如果没有，要么价格偏高，要么节省的部分进了他们的利润。

生命周期工具。 SAP Cloud ALM 是云项目的生命周期管理工具。Solution Manager 7.2 在 2027 年底退出主流维护，所以同时运行两者的环境需要一个迁移计划。

这十个错误没有变。变的是犯错的代价。在 RISE 项目上，Clean Core 决策、部署模式和 FUE 模型都在启动的头几周内确定。能够影响它们的窗口很短。

为什么 ERP 现代化在上线之后达不到预期？

大多数团队只规划到上线就停下了。没有人负责增强、反馈、流程纠正或待办事项。指导委员会在上线时解散，是最可靠的麻烦信号。从第一天起就为上线后 6 至 12 个月的治理提供资金。

把遗留流程照搬进新 ERP 有什么风险？

新系统继承了旧的低效，成本却更高。具体到 S/4HANA 迁移，为 ECC 的表构建的自定义代码和批处理作业往往无法运行，所以迁移在技术上可能是干净的，业务逻辑却是坏的。

糟糕的数据质量如何损害 ERP 现代化？

重复的供应商、不一致的主数据、遗留编码和不完整的记录，除非有人先清理，否则都会带进新系统。报表出错，用户不再信任数字，在运行中的系统里清理要花几个月。

为什么 ERP 项目中的变革管理常被低估？

因为它不像配置那样在项目计划里一目了然。高管们以为几场培训就够了。变革管理是在上线之前，让人们为日常工作中真正会发生的变化做好准备。像 WalkMe（现归 SAP 所有）这样的数字化采用工具有助于应用内引导，但它们不能代替对“为什么”的解释。

为什么遗留系统在 ERP 上线多年后仍在运行？

因为没有人计划关掉它们。所有人都专注于让新 ERP 上线，而旧系统因为合规、查阅或心理上的安心而继续保留。停用必须从第一天起就在范围之内，并让法务和合规参与。

RISE with SAP 和 Clean Core 如何改变这些错误？

在 Public Edition 上，Clean Core 规则使深度定制变得不可能，这迫使人们展开错误 2 背后的流程讨论。在 Private Edition 上，经典扩展仍然允许，所以 Clean Core 取决于治理。随着 PI/PO 维护结束，集成转向 SAP Integration Suite。许可证变成了 FUE 增长的问题。停用变得更加紧迫，因为并行运行遗留系统会在多年期订阅之上增加成本。