最大程度促使合同履行,力破合同僵局——甲公司与乙公司软件开发合同争议仲裁案

来源:南京仲裁委员会

文章摘要
软件开发合同履行过程中常见“需求蔓延”现象,即开发周期内因委托方业务需求变更或技术认知深化导致开发范围持续扩展,最终陷入履行僵局。

软件开发合同履行过程中常见“需求蔓延”现象,即开发周期内因委托方业务需求变更或技术认知深化导致开发范围持续扩展,最终陷入履行僵局。仲裁庭一方面合理使用了软件开发纠纷中“最小可行产品”的司法认定标准,虽然交付的软件存在瑕疵,但尚不足以构成根本违约,为同类案件中的根本违约判定提供了可操作的审查要素,另一方面在受托开发方仍有意愿及能力履行义务的情况下,继续履行合同仍然可能实现委托方的合同目的,此时应尽量促使合同得到履行,有效平衡了守约方权益保护与社会资源节约的价值关系。本案的处理对规范技术服务领域的交易秩序、促进软件产业健康发展具有积极的指引作用。
基本案情
甲公司委托乙公司提供ERP系统非标软件开发服务,双方就此项目签署《产品销售合同》《实施合同》及《公有云服务合同》,其中《实施合同》对非标开发服务做了具体约定,并附有《工作任务书》,约定乙公司应结合甲公司的业务经营发展状况,提供软件应用于甲公司业务系统的实施服务,项目实施范围包括甲方公司各部门及其分支机构、关联公司。
合同履行过程中,双方制定了项目实施计划书,计划至2022年8月完成项目实施。乙公司按照计划出具《项目需求分析报告》及《业务解决方案》,但双方未就项目实施形成明确的需求清单。直至2022年11月,双方签署《项目上线运行报告》。甲公司因上线并未实际完成,仅支付了合同约定的部分上线费用。2023年2月起,乙公司就项目实施出现配合滞缓。2023年6月,双方就项目实施问题清单等四项验收前实施工作签订确认单,确定以上事项完成后项目即达成验收条件。此后,双方就确认单工作内容进行推进并多次沟通,至2023年12月,乙公司向甲公司反馈,根据甲公司最新反馈的问题清单,其中的功能修改需求等经研发评估需要50天,并同时催要剩余的上线费用。甲公司认为直到现阶段,项目上线仍未实质完成,并向乙公司发送律师函,催促其在规定期限内完成剩余实施工作。至此,双方陷入履行僵局。
后甲公司以乙公司根本违约导致合同目的不能实现为由,向南京仲裁委员会提出仲裁申请,要求解除案涉全部合同并由乙公司返还全部合同费用、赔偿损失。乙公司答辩认为案涉项目已达到验收标准,并提出反请求要求甲公司支付剩余实施费用。
仲裁过程
经审理,案件存在如下争议焦点:1.交付成果是否符合合同目的的认定标准;2.甲公司能否主张解除合同;3.乙公司主张的付款条件是否成就。仲裁庭认为:
(一)关于交付成果是否符合合同目的的认定标准的问题
仲裁庭注意到软件开发合同区别于普通承揽合同的技术特性。标准软件系统的二次开发本质上属于创造性智力成果的迭代升级,其验收标准具有显著的动态性和模糊性。对此,仲裁庭创新性地引入“最小可行产品(MVP)”理论,通过现场演示确认案涉软件已实现核心业务流程的运转,尽管存在数据逻辑整理、界面交互优化、辅助功能完善等改进空间,但鉴于系统已具备实际使用的基本条件,且乙公司有能力在后续履行中持续优化,故不宜机械适用《民法典》第五百六十三条认定根本违约。
本案证据也证明,案涉项目的实际实施进程虽然严重滞后于最初项目计划。但是本项目的顺利完成依赖于合同双方按各自的分工和责任积极配合,本案证据尚不能证明案涉项目实施推进严重滞后系乙公司单方原因导致。例如,在软件开发过程中,乙公司多次向甲公司反馈在“取数逻辑不清楚”“取数逻辑不确定”的情形下,研发时长会加长。甲公司却未采取合理方式来配合乙公司解决所反馈问题。仲裁庭认为,根据合同约定,甲公司有义务根据自己的实际业务管理流程和目的,及时提供并反馈系统研发基础信息。甲公司主张项目实施延迟应完全归责于乙公司,无充分的事实根据。
(二)关于甲公司能否主张解除合同的问题
《民法典》第五百六十三条第四项所规定的根本违约制度,其相应的合同解除权的行使应当受到严格限制。判断合同一方是否因履行缺陷而不能实现合同目的,应当均衡合同双方利益,并结合案件具体情况,考虑合同目的、因履行缺陷造成的实际损失以及履行期限对合同目的实现的重要性等进行综合判断。
首先,关于案涉合同目的的界定。根据双方签订的实施合同的附件工作任务书及项目启动会会议纪要、上线报告中均明确,案涉合同目的为“实现财务集团管控、从项目管理到财务业财一体化管控要求”。其次,综合本案证据可以认定案涉项目的工作任务已基本完成,上线报告及现场演示等均显示,乙公司所交付的系统平台包含了合同所约定的主要模块,且部分模块已进入正常使用状态。同时,甲公司陈述整个项目所涉及的各单位部门,需要实施的模块内容不同,实施阶段也有先后,相应实施计划亦反映这一状况,因此,亦不能因部分单位未实施或部分模块未实施,即认定乙公司构成根本违约。本案证据仅能证明由于乙公司交付实施的项目系统存在若干缺陷,项目整体实施尚未完成,使得甲公司尚未完整、全面地使用系统实现业财一体化管理的合同目标。但是,“尚未实现合同目的”不等同于“合同目的不能实现”,若双方继续履行合同,现有证据不足以证明甲公司签订合同时的合同目的不能实现。最后,仲裁庭认为,案涉合同的履行状况尚不符合《民法典》第五百八十条所规定的应当解除情形。且如果强令解除案涉合同,无论如何分配合同解除后的责任,对当事人均不公平。从维护交易秩序以及双方合法权益等方面考量,案涉合同不应予以解除。
(三)关于乙公司主张的付款条件是否成就的问题
庭审中,仲裁庭为查明案涉软件的完成情况,要求甲公司现场演示了案涉系统软件的使用情况,显示部分子模块无数据显示,未实施配置,部分子模块中部分表格数据混乱,存在计算错误、表格导出迟缓等问题。乙公司庭后补充提交案涉系统软件使用情况截图,显示截止2024年8月下旬,甲公司的某关联公司正常使用案涉系统软件,并实现协同办公的功能。仲裁庭认为,客观上乙公司所交付实施的项目系统存在个别子模块缺失、未配置,部分报表数据混乱、计算错误等缺陷,在此情形下,乙公司主张案涉项目已达到验收标准的主张,无法获得支持,相关款项的支付条件尚未成就。
最终,仲裁庭对甲公司的仲裁请求未予支持,并裁决甲公司支付上线节点完成后的费用,再通过释法明理,对乙公司其余实施费用应在验收完成后另行申请。
典型意义
随着技术服务的深入发展,我国越来越多的企业进行定制软件开发以提高经营效率、降低经营成本。同时因委托开发合同引起的纠纷也呈上升趋势。对于此类纠纷存在一些共性问题,可追溯为软件工程领域的“需求蔓延”现象,即在开发周期内因委托方业务需求变更或技术认知深化导致开发范围持续扩展,由于当事双方对开发成果的交付标准约定不明确、约定的付款义务与开发进度不匹配等,导致对开发成果的交付时间及是否符合交付标准等争议较大,极易形成履行僵局。
该案仲裁庭一方面合理使用了软件开发纠纷中“最小可行产品”的司法认定标准,通过现场演示确认案涉软件已实现核心业务流程的运转,作出了系统已具备实际使用的基本条件的判断,为同类案件中的根本违约判定提供了可操作的审查要素;另一方面对于如何破解合同僵局,尽量促使合同目的实现进行了有益的尝试。在受托方仍有意愿及能力履行合同的情况下,重新给予受托方一定时间来完成开发,等待验收条件具备后再另行请求支付剩余款项。这种的处理方式既维护了契约严守原则,又通过设置技术履约担保机制保障了委托方的合法权益,对防范化解软件开发合同纠纷具有指导价值,体现了技术服务领域争议解决机制的制度创新。
仲裁示范条款
Model Arbitration Clause
因本合同发生的或与本合同有关的任何争议,均提交南京仲裁委员会按照该会仲裁规则进行仲裁。
All disputes arising from or in connection with this contract shall be submitted to NanjingArbitration Commission for arbitration in accordance with its rules of arbitration.
补充仲裁协议
Supplemental Arbitration Agreement
双方因XX合同产生纠纷,现提交南京仲裁委员会,按照该会的仲裁规则进行仲裁。
The dispute arising from the XX contract between the two parties is now submitted to theNanjing Arbitration Commission for arbitration in accordance with its rules of arbitration.

技术驱动法律,专业成就未来