我曾经写过 2025 年全球广受关注的两个著名 ERP 失败案例，《企业该为ERP花多少钱》《华为投入数千人斥资近百亿才换掉甲骨文ERP，为什么这么难？》，除了这两个案例外，去年还有三个广受关注的 ERP 失败项目。
一、 魁北克汽车保险局(SAAQ)
魁北克汽车保险局（SAAQ）是加拿大魁北克省的公共服务机构，负责加拿大法语区这个省份数百万人的驾照发放、车辆登记及道路安全管理，其职能大致相当于中国的交管局和车管所。
2022 年，SAAQ 启动了数字化转型项目，计划把过去使用了几十年、运行在 IBM大型机上的驾照和车辆管理系统，升级到现代化架构，将原本高度依赖线下窗口办理的几十项服务，包括驾照申请/续期、车辆转让、事故理赔等，迁移至云端，在手机上办理。
这项数字化转型计划的核心项目称为 SAAQClic，主要围绕驾照管理业务。SAAQ 的 IT 部门选择了 SAP ERP软件作为核心平台，而实施商则是IBM 在加拿大法语区专门从事系统集成咨询的全资子公司 LGS 。
SAAQclic的前端是一个驾驶员线上服务门户，后端则打通车辆登记、驾驶员资格、财务结算、身份验证等多个数据库。项目从 2021 年开始实施，到 2023 年初上线，系统无法正常运作，不仅线上平台瘫痪，公民到驾照办事大厅排队10小时仍无法处理业务。
这种混乱引发了当地严重的社会不满和政治危机，为此魁北克政府两次撤换了SAAQ的负责人。2025 年魁北克反腐败小组（UPAC）介入调查，在审计机构公开听审回以及后续发布的报告中，披露项目预算从最初的5亿加元，一路飙升至11亿加元。
为何建设驾照管理系统选型了 SAP ERP 软件成为公众质疑的焦点，SAAQ 管理层解释是，当时认为自己不仅仅是发驾照的部门，而是一个处理海量交易、涉及大量资金流转（保费、罚金、税费）的综合性服务机构。SAP 是全球最强ERP软件，其财务模块极其严密，实施稳定的软件风险最小，可以支撑未来数十年不再进行大规模重构。
听证会最终审查，认定各方责任是：
甲方（SAAQ）：
上线决策失误：无视技术专家的分批上线建议，为了赶在财年完成“数字化转型”业绩，强行要求 2023 年 2 月全模块上线，没有严格测试，又没有准备任何备用回滚方案。
系统架构方案：在SAP 上线同时，SAAQ 强制推行新的“政府数字身份验证”，导致大量公民因无法注册账号而无法办理业务，周边系统问题导致 了SAP 系统无法正常运行。
项目管理混乱：项目过程中，SAAQ 内部缺乏专业人员来判断实施方案对错，不断变更需求，导致 SAP 系统的定制化开发不断蔓延。
乙方（IBM LGS 和SAP）：
工时压缩：IBM LGS在竞标阶段砍掉了大量预估工时，导致项目后期为了赶进度，不得不压缩测试时间。
顾问资源：为了维持利润率，IBM LGS在项目后期撤走了资深架构师，替换为缺乏大型政府项目经验的初级顾问。现场顾问资源只负责沟通和界面美化，而把大量开发工作放到了印度的离岸外包中心。
测试马虎：在 2023年上线前的评审中，未能明确警告 负载测试仅覆盖了预期峰值的 30%，而是带病交付，以获取阶段性付款。
SAP 软件适配性：软件公司方SAP在方案架构中，用SAPERP的标准功能来硬套SAAQ的业务，导致大量二次开发。在上线后，未能解决定制化开发带来的系统性能问题。
在审计结束后，魁北克政府于 2025 年底采取了以下措施：
无限期暂停与 IBM LGS 在该项目上的后续服务合同。
建立外部监督委员会：任何超过 5000 万加元的政府IT 项目，必须接受第三方独立审计，而非仅仅听取咨询公司的汇报。
部分功能退回：针对自身业务，SAAQ 被迫重新启用了部分基于 IBM 主机的旧系统功能，以缓解 SAP 系统的计算压力。
这个项目也成为 2025 年全球最著名的一个 IT 治理灾难案例。
二、南非SPAR超市集团
跟加拿大 SAAQ 远在万里之外的、南非最大的超市集团 SPAR 在完全同一时间，即 2023 年 2 月，也上线了 SAP 系统。新系统在随后两年里引起的混乱，导致公司 CEO和CIO 先后被董事会开除。
SPAR 集团是从欧洲发源的自愿批发零售模式，即各家零售商店自愿加盟、从而达到零售供应链整合的优势的一种“邦联制”连锁零售。
SPAR 在中国也有布局，山东的家家悦、湖南的步步高都曾是 SPAR 全球网络的中国区域特许经营机构，这两家的 ERP 系统都是早些年我在 IBM 工作时带领的团队实施的。
然而SPAR 南非就没有这么幸运了。
SPAR 南非通过 6 个庞大的分销中心（DC）向数千家独立经营的超市配送商品，过去各分销中心运行的是定制化开发的老旧系统，管理层希望通过实施在全球零售企业有广泛应用的 SAP S/4 HANA 及其零售行业解决方案，通过业务流程、信息系统、业务数据的标准化，以提升采购议价能力和物流效率。
项目实施商是行业第一大厂埃森哲（Accenture），咨询费投入约4000 万美元，此外还付给 SAP 数千万美元的软件使用费。新系统系统计划在其夸祖鲁-纳塔尔省（KZN）分销中心进行试点上线，这是 SPAR 南非最大的物流枢纽，处理着高频的生鲜与干货周转。
第一阶段：设计与蓝图（2021年- 2022年）
在埃森哲的主导下，项目进行了长达两年的蓝图设计和上线准备，现在来看，方案上存在着两个巨大缺陷：
1、商业模式差异化：咨询团队试图用SAP系统的标准零售运营流程，来取代SPAR南非特定的经营模式，例如独立店主灵活的信用账期和阶梯折扣。SAP的标准零售方案是匹配沃尔玛这类全直营强管控的连锁零售模式，而SPAR是不同于这种零售模式——这让我想到了十多年前，国内服装企业一窝蜂上 SAP和 Oracle 的零售ERP走了不少弯路，实际上中国服装企业的商业模式和欧美有很大区别，跟 SPAR 南非遇到的情况几乎一样。
2、技术架构方案：SPAR物流中心每日处理数百万次的拣货指令，系统架构在设计时未能充分考虑高并发下的吞吐压力。我当年在国内几家大型零售企业实施 SAP ERP 时，正值新零售兴起，如何实现 ERP、电商平台、订单交付和仓库物流系统对接，确实需要对系统架构的深入认知。
第二阶段：试点上线（2023年2月）
尽管内部对业务蓝图方案以及上线计划存在疑虑，SPAR仍决定在2023年2月在KZN配送中心进行“大爆炸式”（Big Bang）切换——即直接关停旧系统，全面启用SAP。
上线第一天，系统直接瘫痪；由于SAP的仓库管理模块（WM）与分拣叉车系统的集成出现延迟，订单无法正确指引分拣员；配送中心出现了仓库有货，但系统显示零库存的奇观。
第三阶段：项目叫停（2024年- 2025年）
到2024年，混乱不仅没有平息，反而从业务端蔓延到了财务端。系统无法准确计算促销返利和配送费，导致SPAR各家加盟店店主收到的发票错误百出。
2024财年，SPAR宣布因SAP系统问题导致利润损失16亿兰特（约8500万美元）——这已经远超实施费的开支，随之导致股价下跌。
2025年，SPAR正式宣布暂停在南非其余5个配送中心推广SAP，而KZN的项目则维持使用SAP，继续修复和维护；同时，多套系统运行给SPAR带来更高的IT开支。
三、澳大利亚Metcash集团
Metcash是澳大利亚最大的零售批发和零售运营集团，从事食品、酒类、五金的零售批发，并且自有运营多家超市、五金、酒类的连锁零售品牌。
2020年Metcash决定启动数字化转型，用新一代的云平台ERP系统来替换由NCR提供、已经运行了二十多年的批发和零售核心业务管理系统。当时的CEO和董事会决定投入9000万澳元（约合4亿人民币），用3年的时间来完成这次企业转型，转型的咨询及实施合作伙伴是毕马威（KPMG），同时又聘请了普华永道（PWC）作为实施监理方。
项目被命名为“地平线”（Project Horizon）。2021年初在咨询公司总体规划结束后，开始了ERP软件选型，SAP和微软Dynamic 365（微软的ERP产品）两家开展了激烈竞争。最终，过去在Metcash酒类业务有良好使用的微软ERP，凭借其整合Azure云服务的优势以及激进的销售策略，获得了合同。
随后就出现了数字化转型经典的灾难。
项目开始一年半后，预估结束的实施成本几乎翻倍至1.9亿澳元，到2022 年6 月发布年报时，这个数字化转型项目的危机对股东们全面爆发。随后，这项业务转型的预估完成成本飙升至2.9亿澳元，原定于 2023 年 12 月完工的目标，现在预计要推迟到 2025 年或更晚。
2022 年年中，Metcash 董事会解雇了启动这个项目的原 CEO，并从南非最大的零售批发企业挖来一位CEO。
新CEO上任后，最重大的动作就是对ERP进行铁腕整治，将项目管理收回内部，止损并大幅降低了支付给外部顾问的咨询费；最终，KPMG 和 PWC 双双出局，内部实施的监理方也换成了德勤。
Metcash 聘请了一位外部专家Bob McKinnon 开的独立咨询公司，进行问题诊断，并作为顾问指导后续实施。此人曾经在澳大利亚四家最大的银行做过 CIO，退休后被认为是企业 IT 管理的专家。
专家在 2023 年向 Metcash 董事会提出了一份独立报告，其内容可以说是数字化转型和 ERP 实施的经典，包括：
1. 实施总体策略
项目最初试图用一套单一的ERP方案架构，覆盖食品、酒类、五金这三大完全不同的业务，忽略了不同业务之间的业务流程差异。例如食品批发需要高周转率，而五金建材则是低周转业务，两者的供应链规则、促销逻辑和库存特征完全不同。为了适配软件，牺牲了业务竞争力。
2. 软件产品问题
微软当时急于在企业级市场与SAP正面硬刚。虽然Metcash在新西兰的酒类业务中成功应用了微软D365，这让管理层产生了误判，认为它可以扩展到业务复杂的澳洲总部。McKinnon指出，当时D365甚至没有集成定价引擎，这对于处理复杂促销和返利的批发商来说是致命的缺环。
3. 项目治理
项目缺乏“一把手工程”的机制。项目的汇报路径从最初直接向集团CEO汇报，一路降级到战略总监，最后降级到食品业务CEO汇报。关乎全集团业务命脉的转型项目，竟然缩在了一个业务部门内部。这种治理结构的崩塌导致项目失去了跨部门协调的权威。
4. 外部依赖
项目现场最多有200多名KPMG顾问，Metcash将设计和构建权完全交给了外部，缺乏ownership。McKinnon发现三大业务支柱从未真正认领这个项目，他们认为这是IT部门和咨询公司在并行地“做实验”，而不是在真正改变业务。
5. 低估复杂性
最初的蓝图设计过于理想化，缺乏对现状的深入研究。Metcash的业务分布在全澳各州，各地的仓库管理系统、供应商门户、甚至是针对同一供应商的贸易条款都是碎片化的。McKinnon发现，蓝图设计低估了对碎片化业务流程进行标准化、统一化的系统开发以及管理变革的复杂度。
新 CEO就重构解决方案架构跟董事会达成了共识，尽管业务部门反映新系统不好用，尤其是财务部门认为认为新系统跟原系统并没有任何改进，不过由于新型技术的应用，仍有部分模块获得了业务部门的认可，例如供应链计划管理和自动补货系统部分实施了 Blue Yonder（原 JDA，参见《ERP和供应链软件 ｜ 松下收购JDA，下一家是谁》）。
董事会对技术供应商微软也表示了足够的包容和支持，强调要继续战略合作关系。使得项目没有彻底终止，而是经过优化后，继续进行。
这三个案例对中国企业的数字化转型和 ERP 实施都有非常重要的启发。每个 ERP 项目都是管理变革项目，如何做好业务转型管理以及复杂 IT 项目的交付管理，也是很多中国企业所欠缺的能力。
果总在中国有二十多年的数字化转型、架构规划咨询，以及大型ERP 项目管理经验，如果你的企业遇到上述的实施问题，我也可以提供项目风险去除的诊断咨询，即这种模式的服务《管理老钱风 ｜ 高价值ERP咨询长得啥样》。