• 注册
    • 查看作者
    • 信息系统开发招标项目合同法律风险及争议解决

        电力招标采购网本文通过对信息系统开发项目存在的五类主要法律风险的描述, 介绍了实务中常见的与信息系统招标项目合同相关的法律风险。文章结合某企业系统开发合同仲裁案例, 对信息系统开发合同签约和履行过程中涉及的变更、延期、测试、验收、加价及履约能力等多种法律风险进行了重点分析, 并提出了风险防范及争议解决的相关建议。

        在“互联网+”时代, 随着企业大面积提升利用信息化水平, 以及各级政府和事业单位开发完善信息化管理系统的潮流, 近年来, 开发软件信息系统的招标采购, 不论在项目数量上, 还是在总体金额上, 均持续上升;同时, 招标采购信息系统的内容、范围和复杂程度, 也越来越高。相应地, 实务中陆续出现与信息系统招标项目合同相关的法律风险, 若无法通过协商解决, 则形成诉讼或仲裁案件。

        本文拟在简述相关法律风险的基础上, 述评某企业系统开发合同仲裁案例, 希望对相关合同风险管理有所启发。

        一、信息系统开发项目主要法律风险

        信息系统开发属于服务类项目。与提供保洁、印刷、物业管理、法律咨询、课题研究等传统的、成熟的服务类项目相比, 信息系统开发具有服务类项目所共有的专属性、定制性特点的同时, 还具有新型、复杂、金额大的特点, 这就决定了该类项目的招标采购及合同管理, 面临更大的挑战和风险。从项目招标采购及合同管理的进程看, 需要注意影响项目目标、进程和成本的五类主要法律风险。

        (一) 招标中标风险

        招标文件如果存在重大缺陷, 不论是项目用户需求和技术标准等实体内容, 还是投标人资格条件、评标方法和标准等程序规定, 都可能导致项目招标投标程序中出现质疑、异议、投诉、举报等情况而耽延预计进程, 浪费相关人力、财力和时间成本, 还可能埋下合同履行中费用损失和争议案件的风险。

        (二) 用户需求风险

        用户需求的不确定, 往往导致信息系统开发合同出现争议。对于招标人而言, 实务中经常出现在项目招标之初重视不足, 相关需求描述不够充分、具体, 到系统开发进展到较后期甚至进行功能测试阶段, 又提出大量修改或新增要求。如果用户需求早期不充分, 一方面, 可能影响系统架构的前期设计, 导致在后期看上去很微小的增改事项, 带来较高的技术挑战和软件开发工作量;另一方面, 还可能影响投入资源预估, 导致对项目进程的延宕和费用增加。

        对于开发商而言, 准确、全面识别用户需求, 并匹配相应的资源投入, 需要开发商不仅有计算机信息技术能力, 更要具备所开发信息系统的具体行业或领域的通识认知和必要经验。几乎每个信息系统开发项目合同均存在或多或少的需求调整, 开发商能否结合招标人的对口信息管理团队特点, 尽早、尽细确定需求范围, 是能否顺利履约的保障。

        (三) 开发商履约能力风险

        招标人能否以合理设定资格条件、采购需求、技术指标、合同条件开展招标, 并选择具有适合履约能力的开发商签约, 是项目成功的关键。实务中, 如果开发商履约能力强, 即便合同约定有不同含义的解释空间, 双方往往也能在系统成功投入使用的基础上继续合作, 协商解决费用索赔等问题。但是, 如果开发商不能及时、顺利完成系统开发和部署, 则双方很难有效地解决分歧。

        (四) 合同加价风险

        对很多采购单位来说, 信息系统开发费用预算相对固定, 很难轻易获得合同约定价格之外的增加。结合上述信息系统开发中需求变更频繁, 或者招标人占据合同管理优势的心态导致不注意按时支付等问题, 都可能造成开发商的费用索赔。此外, 招标人不及时支付合同费用, 还可能导致开发商获得对相应开发阶段资源投入迟延或不足的免责权利。

        (五) 争议案件风险

        信息系统开发合同主要由开发商的技术人员与招标人的信息管理部门人员负责执行, 往往注重技术而忽略合同具体约定, 例如需求和费用变更, 直到双方发生无法互动解决的分歧时, 才寻求合同法律救济。此外, 还存在双方发生无法协商的争议, 形成诉讼或仲裁案件时, 才发现自己认知的项目合同履行情况, 与其能够掌握的证据, 不一定能够形成必要的证明关系。换言之, 案件能否因履约的严谨性和证据而获胜, 往往也成为信息系统开发合同管理的法律风险。

        二、案情概要和争议焦点

        某企业招标后与中标的系统开发商签订合同, 履约中出现开发和测试延迟、费用索赔、验收未通过等问题, 招标人解除合同并驱逐开发商, 开发商向合同争议解决条款约定的北京仲裁委员会申请仲裁, 请求支付费用、违约金并赔偿损失, 招标人则针锋相对地提出仲裁反请求, 请求退还已付开发费、违约金并赔偿损失。案情和争议如下:

        (一) 案情简介

        开发商申请仲裁, 述称的案情要点为:

        1.经招标投标中标, 2016年7月21日双方签订合同, 约定招标人委托开发商为其“基于IP+IT的全业务管理系统”项目进行外包编码开发和测试、集成测试及上线工作。开发期限为自2016年7月5日起至2016年12月28日, 并具体约定了编码和单元测试、集成测试、试运行上线的开发进度计划, 以及验收标准。

        2.合同开发费用总计xxx万元, 分四期在合同签订后、编码和单元测试完毕、项目上线试运行以及试运行满3个月后的7日内, 分别支付40%、30%、25%和5%。除第一期价款外, 其余均未支付。

        年7月初, 开发商组建团队开始开发。10月, 项目团队进驻招标人现场开发。11月, 系统已经达到了编码和单元测试验收的标准。11月29日, 招标人制定了单元验收计划, 但未进行验收。招标人实际认可系统是合格的, 直接进入集成测试阶段。11月30日起每天发版, 开始集成测试。2017年2月4日, 招标人提出延长集成测试时间, 实际用户参与到集成测试中, 双方同意将集成测试时间推迟至2017年5月10日。

        4.系统开发过程中, 因招标人频繁变更需求, 导致开发进度比预计延迟。2017年3月31日, 招标人单方组织“集成测试验收”, 结论为“不通过”, 开发商不认可。2017年4月7日, 招标人通知解除合同, 并将开发商团队清离出场, 合同无法履行。

        5.开发商以源程序共享方式, 已将工作成果完全交付给招标人。

        开发商的仲裁请求是:

        1.解除合同。

        2.招标人支付尚欠合同约定开发费用xxx万元及新增需求部分开发费用698400元。

        3.招标人支付迟延付款违约金, 每日为迟延支付款项0.5%, 自应付之日2016年12月1日起至2017年5月31日催款函要求支付日止。

        4.招标人按照合同约定支付“协议总金额20%的违约金”xx万元。

        5.招标人支付开发商为本案支付的律师费xx万元。

        6. 招标人承担仲裁费用。

        对于开发商的仲裁请求, 招标人答辩称应予以全部驳回。其述称的案情要点为:

        1.招标人完全履行合同义务, 而开发商未能按照合同约定的时间节点交付开发成果, 构成根本违约。2016年7月, 招标人与开发商进行了需求确认和开发技术框架确认。开发商未按时完成单元编码和集成测试, 也未提供可以试运行上线的系统。直到2017年3月31日, 开发商仍未完成各模块的编码测试工作。

        2.开发商的违约行为系自身过错导致, 应当承担全部责任。开发商在投标和签约时未认真调研, 对涉案项目难度和复杂程度估计不足;在系统开发过程中, 软件开发人员配置不足, 工作时间不能保障;测试人员严重缺乏, 且对各个模块的编码进行大量的重复测试, 拖长整个开发周期。

        3.开发商缺乏项目管理经验, 开发阶段各种控制不到位, 项目流程混乱。由于软件开发的特殊性, 招标人在实际开发中对需求进行调整和细化在情理之中。

        4.开发商在整个系统开发过程中, 从未按照合同约定提出价格和/或时间的调整需求。

        5.招标人为开发该系统进行了大量投入, 包括资金、开发环境和大量项目管理人员及架构师、测试人员的支持。开发商违约严重影响招标人的软件系统规划, 系统上线后业务不能按照计划开展。

        招标人在上述答辩所述事实及理由基础上, 进一步提出仲裁反请求如下:

        1.开发商返还招标人已经支付的项目开发费用xx万元, 并支付协议总金额20%的违约金。

        2.开发商支付招标人为本案所支付的律师费xx万元。

        3.开发商承担本案仲裁费用。

        (二) 争议焦点

        双方当事人围绕仲裁请求和反请求是否成立, 形成了三个主要争议焦点:一是软件系统未按期完成开发、通过测试验收的原因及责任;二是招标人是否应就软件系统的需求变更增加开发费用;三是合同是否应予解除及相关后果处理。

        三、仲裁庭的审理意见

        仲裁庭结合双方的陈述和举证质证, 认定了相关事实, 对双方争议理由给出如下意见。

        (一) 关于软件系统未按期完成开发、通过测试验收的原因及责任

        开发商主张, 招标人频繁变更需求, 是导致软件系统开发拖期、未能通过测试验收的原因, 招标人应承担全部责任。开发商已经有数十个合同类似项目经验, 且投入超过预估两倍多的人力资源, 不存在招标人指责的问题。

        招标人主张, 开发商人员资质、人数、工作时间不足, 测试阶段还在做开发阶段工作, 且大量重复测试, 是导致不能按期通过验收的原因, 开发商应对此承担全部责任。招标人仅对系统需求进行了调整和细化, 而开发商未提出价格和/或时间调整。

        仲裁庭注意到, 第一, 合同约定招标人有权在履约期间调整和增加需求。如果致使开发商履约费用或时间变动, 将进行公平的调整。第二, 双方工作人员的多封电子邮件、微信记录等证据显示, 自合同签订到2017年3月期间, 招标人在不同业务模块下, 存在持续、频繁的需求调整和增加。第三, 2017年3月9日, 开发商发给招标人题为“后续开发工作量评估”的电子邮件显示:新需求和改进性需求还处于敞口状态;全部后续工作量评估约397人·天, 包括25%的新需求, 并建议将约100人·天的新需求和改进性需求留待后续开发;并分栏列示了模块、子模块、功能、类型、说明、工作量 (天) 、开发建议等内容。第四, 2017年3月17日, 招标人回复开发商邮件显示已经确认, 且附件中以“需求确认与档期建议”文件名另行制表, 将开发商绝大部分建议为下期开发的档期明确为当期, 并统计开发商新增工作量为289人·天。第五, 双方多封电子邮件显示, 系统存在账单报表无法测试、新问题增长很快、bug处理太慢等问题。开发商承认资源配置不足、前期对项目需求和整体工作量预估不足。

        仲裁庭认为, 一方面, 软件信息系统开发中, 需求方通常对签约时已经商定的需求进行后续的细化和调整, 合同中也约定了招标人具有变更需求的权利, 但是, 涉案合同的需求变更, 明显数量过大、周期过长, 超出了开发商应当预见的范围;另一方面, 信息系统开发合同履行中, 开发服务商对客户需求的适当管理, 是顺利履约的重要内容, 这也是开发商应适度承担的商业风险;而开发商在项目中未充分认识项目需求和招标人管理特点, 出现资源结构和投入不能有效匹配需求以及测试中不能快速解决bug等诸多问题。因此, 合同信息系统不能如约完成开发、通过测试验收, 系由双方原因竞合导致, 不能片面认定为单方责任。考虑到软件系统开发的周期及特点, 在需求边界不断修改的情况下, 开发商的开发计划和资源管理必然受到影响。同时, 本案履约中存在开发商人力资源投入不足、未能充分估计合同项下的客户需求变更风险的问题, 仲裁庭认为, 双方应共同承担相关责任;因任何一方均未能举证证明对方负有更大责任, 按照公平合理原则, 认定由双方对半承担责任。

        (二) 招标人是否应就软件系统的需求变更增加开发费用

        开发商主张, 招标人在8个模块中存在千余个新增内容和新增工作量, 应按照开发商汇总统计的465.6人·天, 乘以合同约定1500元的人天单价, 计算调增合同开发费用69.84万元。

        招标人主张, 招标人仅仅对需求进行了一般性变更, 未超出合同约定范畴;且即便个别需求构成新需求, 因开发商没有依据合同约定提出价格调整, 也不构成合同意义上的变更, 不应调增开发费用。

        仲裁庭认为, 第一, 合同约定了两种形式的需求变更:一种是在合同价款不变的情况下进行变更;另一种是随着需求变更的范围和数量调整合同价款。第二种情形需要在公平原则下调价。所以, 其他项目中变更需求而无须额外增加开发费用的惯例, 并不能当然作为招标人可以无限制免费变更需求的适当理由。第二, 双方认可的电子邮件和技术人员沟通记录显示, 招标人在本案软件系统开发、测试过程中, 存在数量明显过大、周期明显过长的需求变更, 且其中很多变更系新需求。招标人关于其需求确认与档期建议表不构成对开发商需求变更回复的主张不成立。招标人需求确认与档期建议表中, 确认开发商的具体工作量及总工作量 (289人·天) 。结合该表所属邮件正文中“已经与业务与软件团队共同确认”的说明, 可认定招标人确认了开发商增加的工作内容及工作量。第三, 鉴于招标人对于需求的变更是持续且随时进行的, 故开发商统一估算增加费用是合理的, 招标人确认的289人·天新增工作量, 可视为构成合同约定的变更。

        综上, 既考虑软件开发中一定范围内的需求调整不必然加价的惯例, 又兼顾开发商提出增加费用及招标人的回应, 仲裁庭认为, 可酌定开发费用增加40万元。

        (三) 合同是否应予解除及相关后果处理

        开发商主张, 双方已将集成测试时间推迟至2017年5月10日, 招标人无权擅自解除合同。项目系统已达到合同约定标准, 招标人拖欠第二期开发费超过30日构成根本违约, 开发商请求解除合同。招标人应支付全部开发费用及延期付款违约金和合同总金额20%的违约金。

        招标人主张, 开发商未能按合同约定完成项目, 构成根本违约, 招标人有权并且已经实际解除了合同。2017年5月10日的时间节点, 只是招标人给予开发商的宽限期。开发商所交付的系统中bug频出, 不能满足系统功能健全性和健壮性的高要求。开发商无权请求支付, 还应退还已收开发商费用, 并支付合同总额20%的违约金。

        仲裁庭认为, 第一, 2016年11月29日邮件证据不能证明开发商关于招标人已经认为系统达到验收条件的主张, 后续邮件虽然商议2017年5月整体测试, 但逻辑上无法反向推理出开发商的上述结论。第二, 开发商未证明招标人应支付第二期开发费用的日期, 相应地, 不应支持开发商以招标人拖欠第二期付款超过30日为由解除合同的请求。第三, 招标人直至2017年3月还在不断变更需求, 导致合同原定测试验收时间在事实上不具有可执行性, 双方就整体测试调整到5月10日达成了新的协议, 构成对原定时间节点的修改;招标人无权以开发商未能按照原定时间节点通过验收为由, 解除合同。第四, 涉案合同属于承揽合同, 招标人考虑自身较高的质量要求, 结合系统开发、测试及bug解决中开发商的问题, 有权依据《合同法》第二百六十八条的规定解除合同。第五, 因双方均确认合同无法履行, 双方该项争议实际上是针对导致合同解除的责任划分及后果承担问题。对于责任划分, 因招标人不断变更需求与开发商资源配置不足为共同原因, 仲裁庭认为以双方对半划分责任较为公平合理。对于后果承担, 考虑到软件系统并非有形财产, 双方均不易将本案软件系统形成可变现价值, 仲裁庭认为, 结合开发商已经投入人力、基本上完成软件系统的开发和数月测试工作的情况, 以及双方的责任划分, 按照公平合理原则, 应由招标人按照合同约定总价及新增的开发费用之和的50%, 支付开发商xxx万元开发费用;因招标人已经支付合同第一期开发费用xx万元, 招标人还需再支付开发商xx万元。至于双方当事人以对方根本违约导致己方享有合同解除权, 并相应要求对方承担违约金的主张, 仲裁庭认为, 均不应支持。

        四、裁决结果

        基于上述理由和意见, 仲裁庭裁决确认涉案合同已经解除;裁决招标人就解除合同应支付开发商xxx万元, 扣除已付费用后还需支付xx万元;裁决驳回双方其他仲裁请求和反请求;裁决双方对半承担仲裁费用。

        五、评价和总结

        虽然与动辄上千万的大系统项目相比, 上述案例涉案金额并不巨大, 但该案例较丰富地展现出信息系统开发合同签约和履行过程中, 涉及变更、延期、测试、验收、加价及履约能力等多种法律风险。双方当事人在案件中提交了包括招标文件、投标文件、开发合同、往来邮件、会谈记录、测试验收报告等数十份证据, 申请多名证人出庭作证, 并就多个同一事项陈述了完全相反的事实和观点。从上述案情和仲裁庭审理意见可以看出, 双方都未能较全面地证明己方的主张。依照法律规定和仲裁规则, 只能结合双方证据进行相关事实认定, 对争议问题作出判断和裁决。当事人如果寄希望于仲裁庭仅依据单方面陈述, 就支持己方的请求或反请求, 则必然会承受证据不足的法律风险后果。事实上, 经常直到发生争议仲裁案件时, 当事人才意识到法律风险管理的重要性。

        此外, 在项目招标及签约时, 当事人往往会怀着美好的愿望, 或主动或不自觉地忽略法律风险, 既不重视具体合同约定与项目风险管理的对应性, 又不严谨对待己方和对方履约的适当性, 还容易发生疏于证据形成和保管的问题。特别是在发生相关人员离职等特别情况时, 能否完整保管项目合同证据, 经常是双方发生争议时能否自行协商成功的基础, 更是发生仲裁或诉讼案件时能否胜诉的关键。

    • 0
    • 0
    • 0
    • 376
    • 请登录之后再进行评论

      登录
    • 做任务
    • 实时动态
    • 偏好设置
    • 单栏布局 侧栏位置: