数字政府系列：数字政府建设中的项目变更争议

引言

在《数字政府系列：“无缝对接”争议及标准化建设问题》中，我们介绍了在“数字政府”项目建设中新旧供应商通信协议不一致引起纠纷的案例，强调了健全行业标准的迫切需要。本期我们将继续围绕数字政府项目的争议，介绍因项目建设需求不明确，建设过程中业主需求蔓延、变更幅度过大、成本失控所引起的争议。我们将分析引发这类争议的原因，并结合我们的观察提出可能解决路径。

一、问题

数字政府项目一般被认为是信息系统集成项目的一种，是为了满足政府管理的需要，将各子系统在物理上或功能上连接起来汇集成一个系统，通过对软件、硬件与通信技术的整合，帮助政府部门解决信息处理问题。

长期从事系统集成业务的从业者均有共识，即政府部门的信息系统建设项目中总是充满“变数”。如何在长达数年的信息系统建设中处理项目变更，无论是采购系统的政府部门，还是系统集成商、开发特定系统模块的软件服务商，又或者是为项目提供硬件的生产商、经销商，都是不小的挑战。

因为信息系统集成项目建设的特点，项目变更本身并不罕见。虽然并不至于都最终影响交付验收，但如果变更是因为关键性的系统需求不明确引起，就可能导致系统需要大幅度调整、导致开发成本失控，最终甚至出现验收不通过、延期交付等风险。

因此，理解导致变更纠纷的原因，在项目建设前就做出预先约定和安排，在项目出现变更时加强管理就显得十分必要。

二、发生项目变更纠纷的原因及表现形式

在我们处理的项目和争议中，因变更产生争议的项目表面上大多是因为需求不明确引发的，而更深层的原因是需求的形成过程不规范，需求发生变更时的处理方式不规范。

相比而言，信息系统集成项目中软件层面的需求变更显得更加频繁，因此我们以信息系统集成项目最常见的软件需求变更为例，说明此类纠纷的具体表现形式。

1. 确认需求难

2021年4月30日，财政部颁布的《政府采购需求管理办法》对于政府采购过程中的如何确认采购需求、制定采购实施计划做出了规定，也是此类项目的主要参考依据之一。该办法中所称“需求”是对政府采购项目需求的统称，包括“技术要求”和“商务要求”，并规定“采购需求应当清楚明了、表述规范、含义准确”。

本文在讨论系统集成项目的需求变更时所称“需求”相比该等规定会更加具体，指的是用户提出的、需要信息系统解决的实际适用场景中的具体问题，“这个问题可能是使用软件的人的任务中的一个自动化部分，或是支持委托开发软件的组织的业务过程，或修正当前软件的缺点，或是控制一个设备等等”[1]。比如，核酸采样过程中允许志愿者通过自己的账户登陆检测信息平台，然后通过志愿者自己的个人手机可以逐个扫描试管、居民核酸检测码，并将扫描后的数据录入至信息平台，这一过程就可以被视为是对一个或一系列需求的具体实现。

在项目建设过程中，确认需求远比上述描述内容看起来要困难。软件工程师/需求工程师等专业人员要通过专业的工具和方法，使得用户对信息系统的诉求能够被尽可能清楚地、无歧义地、可量化地表达。

比如在某项目的药物销售监管的系统中，用户提出了希望系统能够每月自动生成一份月报，汇总各单位销售某种药物的数量、价格等信息，以辅助主管部门的监管需要。但用户的这种期望还不具体，还不能被认为是可以进行开发的需求。所以，工程师将做进一步的细化，比如：（1）在每个月的最后一个工作日下午五点三十分之前，系统要生成当月的月报；（2）系统需要从销售药物时所采集信息中（如生产厂商、批准编号、生产日期、价格、数量、开具处方的医生姓名、处方编号、结算方式等），只提取其中的价格、数量信息，并进一步以表格、图示形式呈现，生成一份可供打印的报告；（3）生成报告后系统可以提供用户主动下载，或系统通过邮件向相关人员推送等方式发送月报。

这种从用户的期望变成需求的过程，如果只是依赖用户自己是无法完成的。因为大多数时候用户不是从事软件开发、系统集成的专业人士，也缺乏必要的知识和能力以准确表达他们对系统的需求。同时，用户的组织可能很大，有众多的部门、处室，他们的需求很多时候也不尽相同等等。这些限制都增加了确认需求的难度。

2. 处理需求变更难

需求难以确认至少还是技术性的问题，在反复沟通协商的情况下，软件工程师们也总有方法能够明白用户的目的和意图。但更困难的是，即便知道了用户真正的需求，在有限的资源情况下，能不能控制成本以保障项目基本的利润呢？

在我们实际经办的案件或项目中，就曾出现过类似的争议。该政府部门在采购有关信息系统时，主要参照其他地市、省份同类系统的经验，希望借此机会优化行政管理及审批流程，提高效率。但是在进行招标前，该部门没有实际向内部具体业务处室进行需求调研，项目验收时又将具体处室作为验收的第一道环节。这导致在项目已经实际启动后，供应商已经按照招标确定的系统功能完成开发，但具体业务处室不认可其工作成果、要求变更，否则拒绝配合项目验收。从业务维系的角度，供应商最终做出妥协，在不变更项目整体预算的情况下完成了变更部分的开发，项目也因此推迟了验收时间，项目整体利润大幅下降。

三、现行作法及风险

1. 确定需求的过程不规范、事先拟定的需求过于笼统

政府采购项目要求采购需求明确，这对具体负责采购的政府部门提出了很高的要求。无论是实际采购的政府部门或其他服务机构，目前都无法在招投标之前完成对于所有数字政府建设需求的调研、分析，并形成系统性的系统设计成果，就更加无法全面设置采购需求。

面对这一客观需要，部分政府部门为了简化采购流程、部分集成商为保障项目整体利润，在实践中逐渐凸显出几方面的问题：（1）诱发一些不甚合规的作法、部分供应商“提前进场”，进行所谓“标前引导”；（2）对于“提前进场”的供应商而言，项目还没有招标确认实际建设单位，就要耗费大量的时间和人员投入进行需求调研，这在经济上也是不现实的，所以需求调研的质量难以保证；（3）在考虑项目建设的方案时，“提前进场”的供应商为了给未来的项目变更留下空间，往往在需求描述上也倾向于笼统表述。但正如前文所述，笼统的需求其实是把“双刃剑”，会对项目后续开发建设埋下隐患。

2. 处理变更的合同履行机制不够完善

需求不明确是导致智慧政府项目变更争议的一部分原因，还有一部分原因是对于项目变更的管理不够完善。这主要体现在合同约定层面没有平衡双方权利义务关系、没有对用户提出变更的要求做必要的限制，比如每一次的变更是否有必要，是不是影响系统运作的重要功能，如果变更导致的成本浮动经评估后过大是不是就不应当进行变更；以及没有事先约定处理项目变更的合理机制，用户或者供应商都没有设置必要的权限，没有明确谁可以提出变更诉求，以什么方式提出变更诉求，这些机制的缺失导致用户总是以项目最终不同意验收为要挟逼迫供应商同意和配合。

四、解决思路和建议

1. 对用户而言，要重视和规范需求调研活动

如前所述，数字政府项目建设中需求明确是避免项目变更争议的主要手段。故对用户而言首先需重视需求调研的重要性，并在现有规定下通过规范的程序开展需求调研活动。

《政府采购法实施条例》第十五条第二款规定“除因技术复杂或者性质特殊，不能确定详细规格或者具体要求外，采购需求应当完整、明确。必要时，应当就确定采购需求征求相关供应商、专家的意见。”《政府采购需求管理办法》第十条第一款也规定“采购人可以在确定采购需求前，通过咨询、论证、问卷调查等方式开展需求调查，了解相关产业发展、市场供给、同类采购项目历史成交信息，可能涉及的运行维护、升级更新、备品备件、耗材等后续采购，以及其他相关情况。面向市场主体开展需求调查时，选择的调查对象一般不少于3个，并应当具有代表性。”

根据上述规定，如果有关数字政府项目根据政府采购程序确定集成商，且在相关数字政府项目在没有先例可供参考、技术标准等也不明确时，可以通过前述法律规定开展调研活动，明确采购部门的需求。这相比“提前进场”等变通做法能够更好地确认需求，也有助于更加公平合理地设定技术要求、商务要求。

2. 对用户和集成商而言，完善合同约定，平衡双方的权利义务

前文强调的是系统集成类项目中需求的重要性，而引导和确认需求本就是合同双方双向而行的合同义务，只是单纯依靠项目验收为节点的项目管理方式明显是不现实的，也无法保障项目建设质量。我们理解核心有以下机制能够使需求更加明确和有序并尽可能避免争议：

（1）在不同阶段对需求的明确程度设置不同的标准，尊重系统开发的客观规律

前文主要强调了通过合理方式在数字政府项目采购前确认需求的重要性，也介绍了需求确认过程的主要难点，但在具体项目中我们理解要尊重系统需求开发的客观规律，在项目不同阶段对需求设置不同的标准、由浅入深、从原则到具体，并明确合同双方对于需求明确所应承担的义务。

《政府采购需求管理办法》第九条第二款就规定，对于采购需求虽然要“清楚明了、表述规范、含义准确”，但对于创新性较强、缺乏先例的项目，也可以只是“说明采购标的的功能、应用场景、目标等基本要求，并尽可能明确其中的客观、量化指标。”换言之，采购人要在采购时仅要明确其采购的是什么（WHAT），但并不一定要明确供应商应当通过何种方式实现其要求（HOW）。

在具体合同设置上，用户在采购过程中确定的需求可以制定《需求说明书》等文件，该等文件可以作为采购时的技术要求，其更加侧重于用户对系统“功能、应用场景、目标等基本要求”。更进一步的，集成商在被选定后，还需要针对《需求说明书》制定更加明确的技术方案，有些被称为《开发需求和规格》等，其主要内容包括了可交付物列表、交付进度和里程碑、验收和交验标准等，该等文件是对用户制定《需求说明书》的细化，并将在用户确认后作为合同履行时的主要依据。

还是以前文提及的药物销售月报为例，要求系统形成月报可以被理解为是用户对于系统功能的要求，这一部分由用户自己明确和说明；而基于这一要求细化为月报的具体发送时间、所汇总数据的类型、报告的具体形式和取得方法就应由集成商进行明确，同时集成商还需要考虑诸如数据接口、网络环境等其他因素并制订可操作的开发计划。

我们理解这种区分不同阶段的特点，由用户和集成商按照不同的需求表达标准明确需求，相比试图一蹴而就在项目最初就确定全部需求，更加符合此类项目开发建设的特点，也能够更好地避免争议。

（2）强调用户自身的责任，促进用户与系统集成商之间的沟通

在很多项目中，我们发现无论是合同约定还是具体履行，双方都十分关注集成商履行合同的情况，比如是否及时反馈并做出调整等，但是对于用户自身合同履行情况却关注较少，在合同约定时也相对比较笼统。除去谈判地位本身的影响外，我们理解这当中也是对于用户在系统开发过程中所起到的作用认识不足导致的。

因此，我们也建议集成商在协商此类项目时，可以考虑用户在诸如需求确认、需求调整的事项上设置具体的履行期限、并需要按照事先约定方式由享有权限的代表或监理反馈诉求等，且如果用户出现延误或违约，集成商应该有权利要求延长项目的完成时间，付款节点应视延误程度考虑是否延后，集成商有权要求用户支付增量成本和费用等。通过这种更加平衡的合同权利义务关系，保障项目的正常推进。

3. 对集成商而言，要关注《政府采购法》修改，调整自身业务模式、适应制度变革

目前《政府采购法》正在进行全面的修订，其中征求意见稿中有不少新规定正在结合诸如智慧政务领域做特别的细化规定。（参见本系列专题文章：《数字政府系列：简评新<政府采购法（修订草案征求意见稿）>对“数字政府”项目采购及建设的重要影响》）

对于参与数字政府建设项目的各厂商而言，未来减少大包大揽、强调专业化分工应成为趋势，同类采购的专业程度和精细化程度也会不断提升。因此，对集成商而言需要关注立法变化、提前布局、调整自身业务模式，以适应新的政府采购制度、保障自身的竞争力。

数字政府建设仍然是未来很长一段时间引领数字化转型的重要内容，如果能够从已有的数字政府建设经验中吸取经验并进行改进，促进更加公平的竞争环境，进而引导市场更加良性的发展，无疑对于更广泛范围内的数字化转型有重要意义。

 扫码下载文章