还记得去年ITgo发过的那篇《154亿日元打水漂！扒一扒日本通运系统开发失败背后的真相》吗？对，就是物流行业巨头--日本通运在“新·国际航空货物基干系统”开发上的惨败案件。
时隔一年半，这场原本旨在“提升全球业务运营效率”的合作，如今却在法庭上撕裂成了无奈的“原告”和”被告“，不仅给日本通运造成了沉重的财务打击，还让曾经的合作伙伴埃森哲陷入了风口浪尖。
那日本通运为何要索赔124亿日元？埃森哲又如何反驳？其他的外包合作失败案件有多少？未来的外包合作会走向何方？
今天小Go和大家一起就这场从合作走到124亿日元的法律诉讼，在技术与法律两个角度聊聊这场复杂的纠纷案背后的真相。最后谁会是赢家呢，其实谁都不是赢家！
１
简单回顾案件过程
➡2017年4月25日：日本通运启动“新·国际航空货物核心系统”开发项目，预计开发周期为3年4个月，计划于2020年7月25日前完成，总委托费用估算为123.44亿日元（不含税）。
➡2020年6月：埃森哲报告开发程序存在质量问题，导致测试进度延迟。
➡2020年12月：本应完成集成测试后期阶段“ITb”，但被要求推迟。
➡2021年7月：ITb的时间进一步被推迟到2021年11月底。
➡2022年2月4日：日本通运开始项目验收，比原计划延迟约一年，验收中发现大量缺陷。
➡2022年7月29日：在此之前日本通运进行了四次复检，但在第五次复检时依然发现许多缺陷。另外，三次手动测试中共检测到1418个缺陷。
➡2023年1月：日本通运决定彻底放弃该项目。
由于日本通运无法容忍进一步的延迟，暂停了验收工作，埃森哲那边又表示不再参与该项目。为了挽救项目，日本通运也试图将开发工作转交给其他供应商，但因缺陷过多，未能在合理的时间和费用内完成项目。
➡2023年7月：日本通运向东京地方法院提起诉讼，指控埃森哲未按合同完成开发，导致项目失败，要求赔偿124亿日元。
➡2024年10月：双方依旧在各种纠纷中。
２
法律上的核心争议点
在日本通运对埃森哲对簿公堂的过程中，有以下几个核心争议点：
01
合同履行
日本通运声称，埃森哲交付的系统质量严重不达标，没有完成验收工作，开发项目被迫中止，也就是系统未能按合同完成，违反了合同的基本义务。
日本通运提到的合同包括“应用程序开发”、“迁移专用功能的设计和测试”、“客户联动转换功能的开发至ITb阶段”，以及“LCL功能的开发至ITb阶段”这四项具体合同，总金额为35亿1253万9800日元。
日本通运要求赔偿与这些违约相关的其他损失和人力成本，总计约124亿9100万日元。
埃森哲则反驳称，他们已履行了以上四项合同的义务。因为合同要求的是「仕事の完成」（工作的完成），而验收程序与合同履行无关，是独立的程序，不应与是否履行合同挂钩。
埃森哲还认为，ITb阶段的「完成すべき仕事」（应完成的工作）是指根据双方同意的“场景”和“条件”进行的验证操作。
“场景”是指按照业务流程制定的系统确认单位，而“条件”是指根据场景要求使系统运行，从而验证细致的界面和报表的动态。
所以埃森哲表示，他们已经完成了所有场景和条件的验证，并修复了所有缺陷，提交了ITb阶段的成果物，不应被视为违约。
02
验收标准
在“交付”之后，日本通运与埃森哲与之间的争论点还在验收标准的不同。这里要提到一个「打鍵チェック」（打键确认）。
日本通运认为打键确认中发现的问题影响了合同的完成，属于验收的一部分，未整改前无法验收，并将其视为合同中的“缺陷”。
然而，埃森哲则认为打键确认是开发中的质量检查，与ITb成果无关，而是其他系统功能引起的，因此不应影响ITb合同的完成。
另外，埃森哲还指出，最初建议通过用户演示进行验收，但日本通运强烈要求自己的员工直接操作正在开发中的应用程序进行打键检查。
03
特殊验收方法
另一争议点在于验收方法。
日本通运希望通过实际操作约330个功能来进行验证，埃森哲认为这种类似用户接受测试的方式是过度的且不合理，大量问题的出现甚至导致延期就是源自该特殊验收方式。
但为了推进验收，双方达成条件性协议：日本通运撤回否认交付的主张，埃森哲同意对某些问题无偿处理，并接受日本通运的验收方式。
另外，关于验收文件的争议则集中在措辞上。最初日本通运提供的文件为“检验结束通知书”，后来在埃森哲要求下修改为“检验完成通知书”，埃森哲认为这一修改等同于日本通运认可了其履行ITb合同的义务，但日本通运拒绝提供正式合格证明，并解释付款仅为保留版权，而不是合同履行的证明。
３
其他外包合作失败案例
除了日本通运与埃森哲之间的诉讼案，再来看看以下几个外包合作失败案件：
NTT东日本 VS 旭川医大
2008年8月，为更新电子病历和医院系统，NTT东日本与日本IBM合作开发软件，但因接受近800个现场需求，导致项目延期。旭川医大因此解除合同，NTT东日本提起诉讼要求赔偿，而旭川医大反诉要求赔偿预期利润损失约14亿1500万日元。
野村证券 VS 日本IBM
野村证券委托日本IBM开发投资一任账户服务系统。项目于2010年启动，但到2012年8月因进度延误和质量问题，日本IBM警告项目面临风险。10月，IBM提出新的解决方案，但野村证券认为无法解决问题，随即终止合同并索赔36.15亿日元。日本IBM反诉，要求支付5.63亿日元的报酬及损害赔偿，但尚未有最终判决。
三菱食品 VS インテック
三菱食品与インテック之间的纠纷始于2014年，三菱食品委托インテック更新其企业间电子数据交换（EDI）系统，计划于2016年度前完成。然而，在项目过程中，三菱食品于2018年11月提起诉讼，指控インテック未能妥善解决开发中的问题，导致系统无法按时交付，因此要求赔偿，金额也高达129亿日元，但最终结果尚未公布。
文化シヤッター VS IBM
2015年1月，文化シヤッター委托IBM开发一套新系统，以提升其业务运营效率。然而，项目在执行过程中出现了严重的延误和技术问题。2017年11月，文化シヤッター最终对IBM提起诉讼，指控其未能按期交付符合要求的系统，并要求赔偿因项目延期和质量问题所造成的损失，金额高达20亿500万円日元，案件的结果同样在等待中。
スルガ銀行 VS IBM
2017年，スルガ銀行与IBM签订合同，委托其开发一套新系统以提升业务效率。然而，在项目执行过程中，スルガ銀行发现IBM未能按期完成开发，且交付的系统存在多个技术问题，严重影响了银行的业务。2019年，スルガ銀行因此对IBM提起诉讼，要求赔偿因项目延期和系统缺陷造成的损失，金额高达74亿日元，但尚未得出最终判决。
4
写在最后
黑格尔曾说：“历史总是以一种重复的方式呈现。” 的确，外包合作这件事情上，好像未能吸取以往项目的教训，导致重复相似的错误，所以下面的重要的几点会不会又是多余的：
首先，项目管理的关键性不可忽视。在关键阶段，进度审查和需求变更管理的执行不到位，导致双方沟通不充分，许多问题未能及时解决。核心问题（如排他控制）的讨论滞后，造成开发过程中的延误。此外，随着项目推进，双方信任减弱，进一步复杂化了项目管理。
其次，选择合适的外包合作伙伴至关重要。企业在签订合同时，除了关注对方的技术实力，还需确保合同中清晰规定双方的责任，这能有效降低未来法律纠纷和财务损失的风险。
最后，未来的外包合作将更加注重协作。双方都需要紧密规划与管理，透明沟通成为项目成功的基础。特别是在跨国业务的系统开发中，标准化的需求定义、风险管理和早期问题识别将显得尤为重要，以帮助企业更好地规避项目延误和法律问题。
END
ITgo技术者之家，持续关注在日IT人关心的各种资讯，打造在日技术者的专属社区。欢迎留言交流互动。
ITgo
