SAP ECC迁移到S/4HANA：中东零售企业案例研究

这是我最喜欢的案例。一家知名的中东时尚与消费品零售企业，从SAP ECC 6.0迁移到了S/4HANA。它有约18,000名员工，在七个国家拥有1,200多家门店，电商渠道也在不断增长。它使用ECC已有多年，系统对象中有44%经过定制。我们选择了棕地转换加选择性重新设计。月结从一路拖到周末，变成了午饭前完成，定制代码也减少了近一半。

如果您运行着一套高度定制的ECC系统，正在琢磨其中有多少该带到新系统，这个项目就是这样回答这个问题的。

定制是一点一点积累起来的，每次都是为了一个紧急修复。到我们开始的时候，哪怕是很小的更新也有风险。集成很脆弱：财务上的一个小改动，就可能弄坏零售运营中的某个环节。业务想要灵活和速度。IT则被救火耗尽了精力。双方都承认，大家的劲没有往一处使。

我记得有一次会议，供应链团队承认他们几十份“关键”报表其实已经几乎没人碰了，说着还有点笑起来。把这些报表砍掉，既务实，又有种说不出的轻松。

ECC主流维护即将结束，是导火索。采用增强包6至8的SAP ERP 6.0将在2027年底结束主流维护（SAP News）。真正的驱动力更深一层。财务每个月结都要手工提取数据。门店需要的库存可视性，夜间批处理作业给不了。IT的大部分精力都耗在让定制代码活下去上。

SAP Readiness Check证实了我们的怀疑：这是一套高度定制的系统，前方有大量整改工作。简化项清单（Simplification Item List）显示，标准S/4HANA在哪些地方已经能做到ECC定制代码一直在做的事。财务发现，一些多年来一直在维护的定制报表现在已经多余。那次会议上，大家松了一口气，看得很明显。

单纯的技术转换，只会把问题往后推。完全的绿地重建，则会把十年积累下来、一直在运转的配置全部扔掉。棕地转换加选择性重新设计是一种平衡：稳固的保留，该清理的清理，只重建真正坏掉的部分。我写的ECC到S/4HANA迁移指南讲了如何权衡这几条路径。

单纯转换棕地转换加选择性重新设计完全绿地重建

保留的配置单纯转换全部保留，连问题一起棕地转换加选择性重新设计保留稳固的部分完全绿地重建一概不留，十年的积累被丢弃

44%的定制对象单纯转换原样带过去棕地转换加选择性重新设计逐个标记为淘汰、替换或改造完全绿地重建不带过去

这意味着什么单纯转换问题被一起搬到S/4HANA棕地转换加选择性重新设计该清理的清理，只重建坏掉的部分完全绿地重建每一个正常运转的流程都从头重建

挑战	我们的做法
44%的对象经过定制	业务和IT共同给每个对象打标签：淘汰、替换或改造；每个阶段设置质量关口
集成脆弱	回归计划覆盖POS、WMS、财务、HR和供应商门户；点对点连接改为采用SAP Integration Suite的模式
数据质量	每个职能设置带SLA的数据管家；每日跟踪缺陷；清洗在QA开始前完成
跨国家的采纳	按角色编写的岗位指南，上线前后的现场巡场，与真实工作任务挂钩的培训

大规模的定制代码

就绪度评估的结果起到了过滤器的作用。业务和IT坐在一起，给每个对象打标签。有些显然是多余的，比如没人记得运行过的报表。另一些支撑着真正独特的零售流程，需要认真重新设计。这逼着各团队做出决定，而不是一拖再拖。SAP Signavio帮助对照最佳实践定义新流程，smartShift负责自动化的代码扫描和低价值的修复，让资深人员的时间留给重新设计。我写的Clean Core指南讲了我如今如何对定制代码分类。

集成

ECC连接着销售点（POS）系统、仓库管理系统（WMS）、财务、HR和多个供应商门户。我们为所有这些连接制定了回归计划，并在每次重大配置变更之后都做测试，而不是只在最后测一次。夜间批处理作业在S/4HANA中必须跑得更快，否则仓库的晨间报表就出不来。

数据质量

重复的供应商记录和过时的主数据，把测试一拖再拖。解决办法是结构性的：每个职能设一名数据管家，并为问题解决设定SLA。如果数据在QA开始时还不干净，就退回给数据管家。临近切换时，我们端到端演练数据加载，并每天跟踪缺陷。这套简单的例行做法，效果比任何花哨的仪表盘都好，至今我还觉得有点意外。我写的SAP数据迁移为什么会失败一文讲了这种规律。

采纳

培训覆盖了26,000名员工。财务和零售运营的优先事项不同，这在一次早期工作坊上就暴露出来，也改变了培训的设计。临近上线、压力上升时，我们用了按角色编写的岗位指南和现场巡场。后来一位门店负责人说，那份两页纸的指南比任何一次全员大会都管用。我信她。

基于SAP Activate分阶段交付。 核心财务和供应链先迁移，HR和供应商门户随后，这样支持团队从不会不堪重负。每个环境只承担一项任务。沙箱环境验证路径并锁定范围。开发环境把传输请求打磨稳定。QA环境用真实的业务量运行，并调优作业。预生产环境是一次货真价实的彩排。部署日期与零售业的旺季和淡季相配合。

与业务一起测试。 财务和供应链负责人用真实的期末结账和促销周期来测试，脚本围绕业务实际编写，而不是围绕系统逻辑。夜间运行暴露了时序问题。我记得，在连续几周的挫败之后，第二次运行顺利通过，那位仓库负责人露出了笑容。

切换演练。 每一项任务都计了时，并被精简或合并。仅仅一次演练，就省出了几个小时，这是电子表格永远看不出来的。恢复方案印在一页纸的资料上，大家说，这份简单的清单比任何仪表盘都更能缓解压力。在更大范围推广之前，一次门店试点验证了POS和WMS的稳定性。

上线后支持（Hypercare）。 IT和业务共用一间作战室，SLA明确，每天更新行动记录。周末轮班，支持交接精确到分钟、有脚本可依。人们通常记住的是数字。我记得最清楚的，是第一个安静的夜晚。

财务结账。 团队说，月结现在午饭前就能完成，过去则会拖到周末。CFO最高兴的是，他拿到报表的速度快多了。一位财务负责人开玩笑说，这套系统终于“比咖啡机还快”了。这样的时刻建立起来的信心，比任何幻灯片都多。

定制代码。 减少了近一半，这降低了长期的支持负担，也降低了今后每次升级的回归风险。

报表与用户体验。 门店经理从旧的事务界面转到了SAP Fiori应用。培训时间缩短了，因为这些应用的使用方式符合人们的预期。一位经理说它“令人耳目一新”。

集成。 POS、WMS和财务之间的连接更稳定，夜间作业也更早完成。

并非所有方面都收效均等。有些团队在已有更好报表的情况下，仍然抱着旧报表不放。有些人觉得工作坊太长，演练太重复。事后回头看，这些环节恰恰就是安全网。

经验教训	发生了什么	下次我会怎么做
尽早对齐	在一次工作坊上，门店经理说他们的报表需求与财务截然不同。这个问题暴露得早，我们做了调整；若晚一些，就会在切换时爆发	在设计开始之前，安排结构化的对齐会议
从第一天就开始代码审查	有几个对象在临近上线时被迫在压力下返工	从启动阶段起就做出淘汰、替换或改造的决定
让数据成为业务的职责	重复的供应商记录拖慢了测试	在第一周就指定各职能的数据管家，并设定SLA
演练的次数要比感觉必要的更多	一次演练暴露了POS与WMS之间谁都没预料到的时序冲突	多规划几次演练；上线前的最后一次，应该让人觉得枯燥乏味

如果同样的项目放到今天再做，有三件事会不同。处于这种位置的大多数企业，现在会考虑RISE with SAP之下的S/4HANA Cloud Private Edition，而不是继续留在本地。淘汰、替换或改造的决定，会对照SAP的Clean Core A到D级别来框定。变更和部署跟踪会在SAP Cloud ALM中进行，因为Solution Manager 7.2将在2027年底结束主流维护。数据管家、演练、联合作战室和两页纸的指南，则会一模一样地保留下来。人的这一面，请参阅我写的SAP培训策略指南。

企业为什么要从SAP ECC迁移到S/4HANA？

2027年ECC主流维护结束，是导火索。更有力的理由在运营层面：实时报表、更快的结账，以及不必再把精力耗在维持定制代码和脆弱的集成上。在这个案例中，业务方想要实时的零售分析和更短的月结。

在这个案例中，SAP Readiness Check显示了什么？

它证实有44%的对象经过定制，其中许多已经多年没有使用。这改变了定制代码工作的组织方式：先淘汰，能用标准功能替代的就替代，只对真正有业务价值的部分做改造。简化项清单还显示出一批标准S/4HANA已使其变得多余的报表。

为什么选择棕地转换加选择性重新设计？

单纯的技术转换会把所有问题一并带过去，完全的绿地重建则会抛弃十年来一直在运转的配置。选择性重新设计保留了稳固的部分，在标准功能可以取代定制逻辑的地方用SAP Signavio定义新流程，并且只重建坏掉的部分。

数据清洗拖到太晚会怎样？

测试拖沓，演练失败，上线延期。在这个案例中，重复的供应商记录和过时的主数据，让测试磕磕绊绊了好几周。解决办法是每个职能设置带SLA的数据管家，并把数据清洗作为衡量项目健康度的一项指标来跟踪。

迁移期间是如何处理集成的？

先把每一条连接梳理清楚：POS、WMS、财务、HR和供应商门户。回归计划覆盖了所有这些连接，每次重大配置变更之后都做测试，在更大范围推广之前，一次门店试点验证了POS和WMS的稳定性。即便如此，一次演练仍然发现了POS与WMS之间谁都没预料到的时序冲突。

S/4HANA上线之后，好的Hypercare是什么样的？

IT和业务共用一间作战室，SLA明确，每天更新行动记录，问题快速关闭，而不是搁进待办积压里。按角色编写的指南和现场巡场，比正式培训更快地减少支持来电。周末轮班，并为交接编写脚本，避免团队累垮。