全球骨科医疗器械企业Zimmer Biomet把德勤告上了法庭，索赔至少1.72亿美元，约合人民币11.5亿元。

按原告的说法，这个项目最初的合同金额约6900万美元，实施过程中累计产生了51份变更订单，最终支付费用涨到约9400万美元，比最初高了36%。系统上线后，订单履约、产品配送、开票全部出问题，公司一度“几乎无法运转”。

德勤否认相关指控，认为Zimmer Biomet没有按合同程序就违约问题作出适当通知，部分问题也由客户自身造成。案件目前仍在诉讼程序中，责任如何划分还要等法院进一步厘清。

但法律结论可以等，实施细节等不了。做了二十年数字化落地，我更想说的是另一件事：这个项目为什么会在几年后演变成一场诉讼？

一、51张变更单，没有一张是荒唐的

很多人看到51张变更单，第一反应是：客户是不是被骗了？被忽悠着不断加钱？

恰恰相反。每一张变更单都有人签字、有人评估、有人批准。Zimmer Biomet有法务、有采购、有指导委员会、有CIO，纸面上每一步都合规。

但起诉状里有一句话很重：这2300万美元的变更费用，本来不需要。如果德勤一开始就把项目范围和复杂度摸准，这51张单子根本不会存在。

ERP项目最反常识的一个事实是：失败往往不是某个环节出了错，而是几百个各自看起来合理的决定，累积成了灾难。

每一次变更都是“合理的”——又一个变更单、又一次修订日期、又一次指导委员会对“剩余缺陷可控”的确认。签字的人当时都觉得没问题。

那问题出在哪？出在每一张单单独看都合理，但没有人统计过这个“合理”累积起来是什么。

这是我做了这么多年项目最怕的一件事。变更单数量本身就是一个健康度指标。超过十几张，说明前期的范围界定已经崩了。变更不是项目的一部分，变更是需求没想清楚的症状。

二、真正的坑：执行的人，也是验收的人

这个案子最值得研究的，不是51张变更单，是付款结构。

公开披露的信息显示，这个项目的费用安排有相当一部分是与日历日期挂钩的，不是与可衡量的业务成果挂钩的。里程碑付款参照的是“完成百分比估算”，不是经过确认的交付物。

读懂这句话的意思：只要时间在走，钱就在付。至于系统做没做出来、长没长出来，不影响付款节奏。

更麻烦的是角色重叠。在这个项目里，德勤同时扮演了四个角色：系统的设计者、配置者、项目管理者、进度评估者。

它自己评估自己的进展，然后自己宣布系统可以上线了。

Zimmer Biomet有指导委员会、有CIO，但这个治理层没有权力推翻德勤的“就绪评估”，合同里也没有赋予它这个权力。

这就意味着什么？意味着即使德勤完全胜任、完全诚实，一个执行了9400万美元项目的实施方，也很难独立地对自己的就绪评估说“不”。

执行与验证合一，验证功能就消失了。本该由独立方承担的角色，被一个无法承担它的位置占据了。

这是所有ERP项目通病的制度根源，但很少有企业能在事前看清。

三、“先上线再说”，是行业里最贵的五个字

上线前到底发生了什么？

2024年7月4日，这个项目在多次延期后上线了——而且只在北美。原计划覆盖的拉丁美洲，并没有如期上线。

上线时，缺陷还没修完。Zimmer Biomet后来指控德勤当时把这些问题的严重性淡化了，说成“S/4上线后的典型小插曲”，会随时间自行解决。

这种话术，做过项目的人一听就知道是什么分量。“典型小插曲”这五个字，是把话说死的信号。

结果呢？上线几个月后问题恶化，公司在2024年第三季度几乎无法运转：不能出货、不能收货、不能开票、出不了最基本的销售报表。全球供应链被打断，医疗器械发不出去，医生的手术用不上。

Zimmer Biomet总法律顾问Chad Phipps说了一句话，那句话的分量比任何数据都重：德勤的做法不仅严重扰乱了公司的业务，也把患者护理置于风险之中。

一家给全世界医生做人工关节的公司，卡在了自己的ERP上。这不是效率损失，这是行业红线。

对应到国内，我见过一模一样的场景：上线前关键缺陷清单还挂着三十多项，某个领导说“先上，缺功能上线后再补”，三个月后数据对不上，客户投诉堵到客服电话打不通，最后只能退回新旧系统并行。

退回去的成本，是当初坚持的三倍。

四、问题不是上线那天开始的

把这个案子的时间线往回倒，会看到几个特别典型的节点。

签约时，德勤承诺“最少定制”能按期按预算上线。

真正有经验的实施方，在没做详细调研之前，不会承诺“最少定制”。这句话本身就是个信号。

范围从北美加拉美，悄悄缩到了只做北美。

目标改了，但没有人重新算预算和工期。这在项目里叫“静默的范围削减”，是后期失控的伏笔。

51张变更单在累积，但没有人看这个趋势。

每一次都有充分理由，每一次都签了字，每一次单看都正常。

上线日期被日历锁死，而不是由就绪度决定。

不是“系统准备好了所以上线”，而是“必须在某一天之前上线”。

上线时，缺陷被描述成“典型小插曲”。

这一步最致命。

因为问题会被层层包装。为什么要包装？因为每个人的局部利益是一致的：项目经理希望按期上线，延期要向公司交代；实施顾问希望尽快推进，驻场成本在涨；业务部门希望新系统快点带来好处；高层希望年底看到成果。

所有人都知道有问题，但没有人有权力、也没有勇气把问题摊在桌上。

于是那句话就出来了：“这些缺陷应该不影响上线。”一旦这句话被默认通过，后面所有的工作就变成了填坑、救火、事后补救，成本失控只是时间问题。

数字化项目最怕的从来不是出问题，是问题被包装到没人看得清真相。

五、企业能记住的四条

第一，上线放行权必须在业务负责人手里，而且写进合同。

不要让实施方独家决定何时上线。Zimmer Biomet踩的最大的坑就是这个——治理层有牌子，没有牙齿。

第二，把变更单数量当成项目健康度的公开指标。

建议在项目例会上固定看一个数：累计变更金额占总合同额的比例。超过15%，立刻升级管理。这个数字骗不了人。

第三，把“先上线再说”变成制度性的拒绝。

设一个硬标准：核心场景的缺陷未关闭，不允许上线。谁签这个字，谁承担后果——不是签字仪式，是真担责。

第四，选型看团队，不看品牌。

德勤是全球四大，Zimmer Biomet和它合作了25年。但这不影响对方派一支流动频繁、以离岸团队为主、现场管控薄弱的执行队伍。起诉状里还提到，团队人员流动频繁，导致项目从头到尾没有一支稳定、合格、连续的实施团队。

真正要问的是：这个团队做过我们这个行业的同类项目吗？他们派谁来？驻场的是哪些人？签完合同之后会不会换人？换人怎么交接？

如果对方答不上来，问题其实已经回答了。

写在最后

这个案子现在还在纽约州最高法院，2026年10月进入证据开示阶段，责任怎么划分要等法院结论。德勤否认了全部指控，主张Zimmer Biomet没有按合同程序及时通知违约，并在2025年11月提交了驳回动议。

法律的事交给法官。但结构性的教训不需要等判决。

我们做数字化项目，最容易犯的错，是把“项目按时上线”当成目标。

真正的目标，是上线之后那个系统真的在干活。

十一亿人民币买到的教训，说到底就一句话：任何让你在“再等等”和“承认不行”之间做选择的时候，都选承认不行。

因为“再等等”的代价，从来不是等。

你们公司的ERP或数字化项目，是甲方冲进度，还是乙方冲签约？变更单最多的时候，累计占合同额多少？上线的时候，是按就绪度放行的，还是按日历放行的？欢迎在评论区聊聊。

阅读原文：点击这里​