企业系统持续变化中反复出现的八类失败：机理与有公开记录的案例

先说结论

• 六十余年来，企业系统在持续变化中的失败以相似的方式反复出现；本文把有公开记录的案例按机理归为八类：宣传先于能力，知识、规则与主数据的维护成本，标准内核与企业自身做法冲突，终端用户开发的静默错误，变更与部署失控，缺少主人、组织未随之改变，长周期累积的复杂度，责任无法转移。
• 在本文看来，八类里只有第一类与生成能力直接相关；其余几类落在规则维护、口径核对、部署复核、系统的主人与责任上，大模型降低了把意图变成可执行变更的成本，这几类机理大多仍然适用。
• 本文不引用行业失败率：常被引用的失败率数字，定义与统计方法受到过有据的质疑；列举案例时只引用处罚书、财报、调查报告等具体记录里的机理。
• 评估一个方案，可以拿这八类逐条对照；我们为制造企业做定制交付时，也拿这八类对照自己的方案。

本栏目《企业系统交付之后如何持续变化：六十年理念谱系与教训》梳理了六十余年来反复出现的一条主张：交付后的系统必须持续变化，最好由使用方身边的人来改。本篇换一面，整理同一时期反复出现的失败。

下面按机理归为八类，每类举几个有公开记录的案例作佐证。案例的全部细节以所引的处罚书、财报、调查报告与报道为准；本文自己的判断集中放在倒数第二节，并标明为观点。

一、宣传先于能力，会造成怎样的失败？

The Last One 在 1981 年宣称生成无缺陷的程序 [1]。MD Anderson 与 IBM 合作的 Watson 肿瘤项目投入约 6,200 万美元，2016 年终止时未用于患者治疗 [2]；STAT 依据 IBM 内部文件报道，该系统给出过「不安全且不正确」的治疗建议，训练依赖少量假设病例与少数专家的偏好 [3]。2025 年，主打「用 AI 构建应用」的 Builder.ai 进入破产管理程序，此前已有报道称其平台严重依赖人工工程师 [4]。

二、知识、规则与主数据的维护成本有多高？

XCON 的规则每年约半数要改 [5]；第一代专家系统在知识边缘骤然失效 [6]。维护机器学习系统也有同类问题：Sculley 等人 2015 年指出，真实系统常常承担巨大的持续维护成本，并点名边界侵蚀、隐藏反馈回路与数据依赖等来源 [7]。

三、标准内核与企业自身做法冲突时，会出什么问题？

FoxMeyer 在 1990 年代中期上线 SAP R/3 与自动化仓储，1994 年 R/3 每晚只能处理约 1 万张客户订单，原大型机系统为 42 万张；公司于 1996 年申请破产 [8]。据媒体报道，Lidl 的 SAP 项目 2018 年叫停，症结之一是 Lidl 按进价管理库存，标准零售软件按售价 [9]。SAP 2025 年的扩展分级把修改标准代码与隐式增强列为「不推荐」一级 [10]。

四、终端用户自己开发的工具，会出哪些静默错误？

Panko 汇总的七次实地审计中，较近期、方法总体更好的几次在至少 86% 的被审表格里发现了错误，而且多数审计只统计实质性错误 [11]。摩根大通 2013 年的内部工作组报告记录，一个在电子表格里运行的新风险价值模型，把本应除以平均数的地方除以了和，很可能把波动率压低了一半 [12]。2020 年，英格兰公共卫生署因使用旧版 .xls 格式的行数上限，有 15,841 例阳性结果没有进入每日报告 [13]。2025 年 Stack Overflow 调查中，66% 的开发者把「差一点对、又不完全对」的 AI 答案列为最大的困扰 [14]。

五、变更与部署失控会造成什么后果？

Hershey 在 1999 年 7 月启用新的集成信息系统，此后在返校季与万圣节的发货旺季出现订单履约问题，当季净销售额低于上年同期 [15]。Knight Capital 在 2012 年的一次部署中，技术员手工部署时漏掉了 8 台服务器中的 1 台，部署也没有第二名技术员复核，被复用的旧标志位激活了停用多年的代码；SEC 处罚书记载，约 45 分钟的错误交易最终造成超过 4.6 亿美元的亏损 [16]。2025 年，一位用户在代码冻结期间使用 Replit 的编码代理，代理删除了生产数据库，生成了约 4,000 条虚构记录，并声称无法回滚，事后发现回滚可用 [17]。

六、系统缺少主人、组织未随之改变，会怎样？

Gantt 与 Nardi 发现，只有部分组织把本地开发者正式化，给予认可、时间与资源 [18]。Forrester 记录的困难几乎都与人有关：没有时间、一次性推给所有人会失败、有教练带着做的小组成功率明显更高 [19]。模型驱动工程的实证研究同样把成败归到组织因素 [20]。昆士兰州卫生部薪酬系统的调查报告写道，这次替换应列入该国公共管理失败的前列，「可能是最严重的一次」[21]。

经济学家阿格拉沃尔、甘斯和戈德法布在《权力与预测》里给这一类补了一条解释 [30]。一套新系统改变的，常常是「谁看见什么、谁决定什么」；失去决定权或收入的一方会抵制，而且往往正是现有体系里说话算数的人。书里的例子是一家录像带租赁连锁：总部看清了订阅模式的好处，但订阅会削掉加盟店占总收入四成以上的滞纳金，加盟店反对，董事会最后换掉管理层、退回原来的模式。书里还有一个说法：组织里的规则是互相咬合的，只把其中一条换成新系统的决定，其余规则会把它的效果抵消掉。

七、复杂度为什么会在长周期里累积？

Lehman 在 1980 年就把它写成定律：程序在持续变化中复杂度递增，除非专门投入去维持或降低 [22]。今天的基准同样显示，智能体在长周期、多版本的演化任务上仍然吃力 [23][24]。

八、责任能不能转移给系统？

2024 年 Moffatt 诉加拿大航空案中，航空公司主张聊天机器人是独立的法律主体、应为自己的话负责，不列颠哥伦比亚省民事裁决庭没有采纳这一抗辩，认定公司对网站上的全部信息负责 [25]。《权力与预测》的看法与此一致：机器按事先写进去的判断行事，写进这些判断的人才是真正做决定的人，责任也应落在人身上 [30]。Knight 的处罚书同样把部署与控制的责任落在公司身上 [16]。由系统主导流转的设计是否会变成规训与控制，可参见 Suchman 与 Winograd 1993–1994 年的往来文章 [26][27]。

为什么失败率数字本身不可靠？

常被引用的 Standish CHAOS 1994 年数据称项目成功率只有 16%。Eveleens 与 Verhoef 用 1,211 个真实项目的数据检验其定义，认为这些定义有误导性、片面，产出的数字没有意义 [28]。Hammer 与 Champy 1993 年「50% 到 70% 的再造未达预期」的说法，作者当时就称之为不科学的估计，Hammer 后来又说再造并没有固有的成功率或失败率 [29]。所以本文列举案例时，只引用处罚书、财报、调查报告等具体记录里的机理，不引用行业失败率。这一点对乐观与悲观的说法同样适用。

以下是本文的观点

第一，多数失败的直接原因不在「写」这一环。 八类里，只有第一类与生成能力直接相关；其余几类落在规则维护、口径核对、部署复核、系统的主人与责任上。大模型降低的是把意图变成可执行变更的成本，这几类机理大多仍然适用。

第二，评估一个方案，可以拿这八类逐条对照。 我们为制造企业做定制交付时，也拿这八类对照自己的方案。 它宣称的能力有没有可查的记录？规则和主数据增长以后由谁维护？与企业自己的做法冲突时改哪一边？业务人员做出来的东西出错时，谁能发现？部署有没有第二个人复核，能不能退回？系统的主人是谁，有没有时间？多年累积的复杂度由谁清理？出了错谁负责？

参考来源