国资项目采购系统怎么合规？需求论证、评标办法与合同备案

核心摘要

国资项目采购合规的重点，不只是完成招标、比选或竞争性采购程序，而是形成从立项、预算、需求论证、采购方式选择、评审定标，到合同签订、实施交付、履约验收和资料归档的完整证据链。

对于长租公寓、保障性租赁住房、公租房、人才公寓、宿舍、园区、商办等资产运营场景，采购住房租赁与资产运营数字化系统时，应重点把握以下原则：

1. **先判断适用规则，再确定采购程序。**采购主体、资金来源、项目属性和金额标准不同，适用的采购制度、公告要求、评审方法及合同备案要求也可能不同。
2. **需求论证应从业务问题出发。**围绕房源台账、租赁合同、账单收缴、工单服务、设备联动、经营分析、权限审计和组织协同，形成可响应、可比较、可验收的采购需求。
3. **评标办法应与项目复杂度匹配。**评分因素应与履约能力相关，明确证明材料、评分档位和扣分规则，避免仅凭主观印象评价“先进性”或“完整性”。
4. **采购条件不得形成不合理限制。**品牌、案例、地域、资质、部署方式、接口和人员条件均应有实际业务依据。
5. **合同备案不能只保存合同正文。**还应关联采购结果、报价清单、技术附件、实施计划、验收资料、付款记录、变更文件和履约评价。
6. **系统本身应支持审计追溯。**组织权限、审批流程、操作日志、数据导出、接口记录和合同版本管理，是后续国资监管与运营管理的重要基础。

本文提供国资项目采购住房租赁与资产运营数字化系统的通用管理思路。不同地区、资金来源和国资监管体系的具体要求可能存在差异，实施前应结合现行政策、采购人内部制度及专业法律意见确认。

一、国资项目采购系统，首先要判断适用哪套规则

“国资项目”并不是单一的采购法律分类。项目涉及国有企业、国有资产或保障性住房，并不意味着一定采用同一种采购方式。采购前应先核实采购主体、资金性质、项目属性、采购金额和内部授权。

1. 政府采购项目

如果采购主体属于国家机关、事业单位或团体组织，并使用财政性资金采购集中采购目录以内或采购限额标准以上的货物、工程和服务，通常需要按照政府采购相关制度执行。

住房租赁与资产运营系统采购可能包含：

• 软件产品或软件许可；
• SaaS订阅服务；
• 实施、配置、培训和运维服务；
• 云资源或本地化部署；
• 门锁、门禁、水电表、网关等IoT设备；
• 数据治理与历史数据迁移；
• API接口开发和系统集成；
• 网络安全、测评及配套服务。

采购人应根据主要采购内容和预算构成，合理确定采购品目及项目属性，不宜通过拆分项目规避应当履行的采购程序。

2. 依法必须招标的项目

项目如包含工程建设，以及与工程建设有关的重要设备、材料或服务，还需要判断是否属于依法必须招标的范围。

例如，人才公寓或宿舍改造项目同时涉及门锁、门禁、水电表、弱电工程和资产运营系统，应区分：

• 哪些内容属于工程施工；
• 哪些属于与工程有关的设备或材料；
• 哪些属于独立的软件及运营服务；
• 各采购内容是否适合合并；
• 合并采购是否会改变项目属性；
• 是否存在拆分或合并项目规避法定程序的风险。

3. 国有企业内部采购项目

国有企业使用自有资金采购数字化系统，并不当然等同于政府采购，但仍需遵循国资监管要求、企业采购管理制度、“三重一大”决策制度、预算管理制度和内部控制要求。

此类项目通常要重点核查：

• 是否完成项目立项和预算审批；
• 采购方式是否符合企业分级分类管理制度；
• 是否应进入集团采购、电子采购或阳光采购渠道；
• 供应商邀请范围是否具有充分竞争性；
• 评审人员是否存在利益冲突，是否履行回避程序；
• 定标权限是否与采购金额和项目等级匹配；
• 合同是否经过业务、采购、财务、法务和信息化会签；
• 采购资料是否满足审计、纪检和国资监管要求。

4. 适用规则判断清单

二、国资项目采购合规的常见业务痛点

1. 采购需求停留在模块名称，没有形成业务闭环

部分采购文件只列出“房源管理、合同管理、收费管理、报表管理”等模块名称，没有说明管理对象、业务流程、数据关系和验收条件。

以保障性租赁住房为例，同样是“合同管理”，实际可能涉及：

• 个人租赁、企业包租和单位配租；
• 新签、续租、换房、退租和合同终止；
• 租金、押金、服务费、能耗费等不同费用；
• 租金减免、补贴、优惠和调价；
• 电子签署、合同归档和历史版本查询；
• 房源、租户、合同、账单和收款之间的关联校验。

如果采购文件没有把这些业务关系说明清楚，不同供应商可能对同一项需求作出不同理解，既不利于公平比较，也容易在实施和验收阶段产生争议。

2. 技术参数具有明显的供应商指向性

常见风险包括：

• 直接指定某一品牌、产品名称或专有技术路线；
• 限定非必要的注册资本、成立年限、地域或分支机构；
• 要求数量过多或地域范围过窄的同类案例；
• 把特定产品的页面布局、菜单名称写成实质性条件；
• 指定只能连接某个非开放接口，却未说明业务必要性；
• 要求提供与项目履约无关的证书、奖项或人员资格。

合规的技术参数应重点描述业务目标、数据标准、接口能力、性能要求、安全边界和验收结果，而不是复刻某一现有产品的功能结构。

3. 评分项过于主观，评审结果难以复核

“方案先进”“功能强大”“服务完善”等表述缺少客观判断依据。如果采购文件没有明确评分档位、证明材料和扣分规则，不同评委容易形成不同理解。

相对稳妥的评分项应明确：

• 具体评价什么内容；
• 供应商需要提交哪些材料；
• 完全满足、部分满足和不满足分别如何评分；
• 未提供证明材料如何处理；
• 演示结果与投标文件不一致时如何认定；
• 哪些内容属于实质性要求，哪些内容仅作为评分因素。

4. 重采购结果，轻履约与验收

数字化项目容易出现“合同已签、系统已上线，但验收依据不足”的情况，常见问题包括：

• 没有明确历史数据迁移范围；
• 没有定义接口联调完成标准；
• 没有约定合同、账单和收款数据的校验规则；
• 没有明确性能、响应时间和系统可用性要求；
• 没有记录培训对象、培训内容和培训结果；
• 没有形成问题清单、整改记录和关闭确认；
• 付款节点与实际交付成果没有对应关系。

5. 采购资料与业务系统相互割裂

采购阶段承诺的功能、接口、实施计划和服务条款，没有同步进入后续项目管理。发生合同变更、模块增购、接口调整或服务续费时，难以追溯原始采购依据。

因此，采购资料、合同台账、交付成果、验收文件和付款记录应建立关联，避免长期分散在邮件、网盘、纸质档案及不同部门的表格中。

三、需求论证怎么做：从“想买什么”转向“要解决什么问题”

需求论证的目的，是说明采购的必要性、预算的合理性、参数的可执行性，以及采购条件是否存在不合理限制。是否需要组织专家论证，应结合适用制度、采购金额、项目复杂程度和采购人内部规定确定。

1. 明确采购目标和业务边界

建议按照“管理对象—业务流程—数据结果”三个层次定义采购范围。

管理对象

• 项目、楼栋、楼层、房间、床位和商铺；
• 产权资产、运营资产和受托管理资产；
• 租户、企业客户、入住人和担保人；
• 合同、账单、收款、退款、押金和票据；
• 维修、保洁、巡检和投诉工单；
• 门锁、门禁、水电表及其他IoT设备；
• 组织、岗位、用户、角色和数据权限。

业务流程

• 房源建档和房态变更；
• 招租、配租、签约和入住；
• 账单生成、收款核销和欠费催缴；
• 续租、换房、退租和费用结算；
• 报修受理、派单、处理、验收和回访；
• 设备授权、状态同步和异常处理；
• 经营数据汇总、穿透分析和监管报送。

数据结果

• 可出租、已出租、空置和维修中的房源；
• 即将到期、已经到期和发生变更的合同；
• 应收、实收、减免、退款及核销差异；
• 欠费租户、欠费金额和催缴记录；
• 工单响应、处理、逾期和回访情况；
• 设备在线、离线、异常和授权记录；
• 项目收入、出租率、收缴率等经营指标；
• 审批记录、操作日志及数据导出记录。

2. 开展现状基线调查

采购需求不能只描述未来目标，还应说明现有管理基础和实际问题。建议调查：

• 当前项目、房源及组织层级情况；
• 现有系统、Excel表格和线下流程；
• 历史数据规模、数据格式和数据质量；
• 已使用的财务、电子签、支付、发票、门锁和门禁系统；
• 总部、区域、项目和一线运营团队的职责分工；
• 现有审批权限和数据查看范围；
• 报表口径及监管报送要求；
• 原系统合同到期时间和数据导出条件；
• 系统切换期间的业务连续性要求。

这些信息既是采购必要性的依据，也是预算测算、实施排期和数据迁移评估的基础。

3. 对需求进行分级

建议将需求至少分为三类：

不宜把所有功能都设置为实质性要求。要求过多不仅可能限制竞争，也可能抬高采购成本，并增加后续验收难度。

4. 将功能要求转化为可验收指标

例如，不宜只写“支持灵活账单管理”，可以改写为：

• 支持根据租赁合同生成租金、服务费、物业费及其他约定费用；
• 支持按月、季度、半年等约定周期生成账单；
• 支持减免、调整、冲抵、退款和核销；
• 账单调整和退款应保留审批及操作记录；
• 支持按项目、楼栋、租户、合同和费用类型查询应收与实收；
• 支持导出账单明细、收款流水和核销结果；
• 权限范围外的用户不得查看或修改相关账单。

这类描述便于供应商进行书面响应、系统演示和报价，也能够直接转化为测试用例及验收清单。

5. 对部署、安全和数据要求进行专项论证

采用SaaS、本地化部署或混合部署，应结合数据敏感程度、既有基础设施、运维能力和总体成本判断，不能简单认定某一种部署方式天然更合规。

论证内容可包括：

• 数据存储位置及备份策略；
• 租户信息、合同数据和经营数据的访问控制；
• 身份认证、单点登录及多因素认证需求；
• 操作日志的留存、查询和导出能力；
• 数据加密、脱敏和下载控制；
• API鉴权、接口日志和异常调用处理；
• 等级保护、密码应用及相关测评要求；
• 服务终止后的数据导出、迁移和删除机制；
• 个人信息处理的目的、范围和权限；
• 电子签、支付、发票及IoT服务的数据边界。

四、评标办法怎么设计：既能比较，也能复核

1. 选择与项目特点相匹配的评审方式

住房租赁与资产运营数字化系统通常包含软件能力、实施服务、数据迁移、接口开发、设备接入和持续运维。对于业务复杂、接口较多或技术路线存在差异的项目，仅比较价格难以完整反映履约能力。

采购人应根据适用制度和项目特点确定评审方式：

• 采用综合评分时，价格、技术、商务和服务因素应与采购需求直接相关；
• 采用最低评标价或最低价成交逻辑时，应确保技术要求、服务范围和验收标准足够清晰、统一；
• 对标准化程度较低的项目，应重点评价实施、迁移、接口、安全和运维能力；
• 对软硬件组合项目，应明确软件、设备、接口及实施服务的评价边界。

政府采购、依法必须招标项目和国有企业内部采购对评审方式、价格分设置及评审程序的要求可能不同，不宜直接套用同一模板。

2. 评分结构应围绕履约风险设置

以下评价结构可用于项目需求讨论，但具体分值和权重仍应根据适用制度审查确定。

评分权重不能脱离项目属性。软件服务、硬件设备及工程建设项目可能适用不同的价格权重和评审规则，应以项目实际适用的制度为准。

3. 技术评分应明确证据和档位

以“账单收缴方案”为例，可以围绕以下内容进行评价：

• 是否覆盖账单生成、调整、收款、退款、核销、欠费和对账流程；
• 是否说明合同、账单、收款流水之间的数据关系；
• 是否具备审批、权限和操作日志机制；
• 是否说明异常账单、重复收款及退款等场景的处理方式；
• 是否明确与财务、支付及发票系统的职责边界。

评分档位可按照“完整覆盖并提供清晰流程”“覆盖主要流程但部分机制说明不足”“仅作基础功能描述”“未响应或明显不符合需求”进行区分，并为每个档位设置明确分值。

避免仅使用“优、良、一般”等没有定义的评价词，也不宜把界面美观程度作为核心业务能力的主要判断依据。

4. 系统演示应验证业务闭环

系统演示可以帮助评委验证复杂流程，但不能代替投标文件和合同承诺。采购文件应提前明确：

• 演示范围、顺序和单项时间；
• 是否允许使用模拟数据；
• 是否要求使用现有产品环境；
• 未演示、演示失败或超时如何评分；
• 是否允许使用视频、截图或原型替代；
• 书面响应与演示结果冲突时如何认定；
• 演示过程是否录屏或形成评审记录；
• 演示数据是否需要脱敏。

演示题目应围绕真实业务场景设计，例如：

1. 建立项目、楼栋、房间或床位台账；
2. 创建租赁合同并生成应收账单；
3. 登记收款并完成账单核销；
4. 发起退租结算并处理押金退款；
5. 创建维修工单并完成派单、处理和回访；
6. 查询合同变更及账单调整的操作日志；
7. 按不同组织权限查看项目经营数据；
8. 完成退租后的门锁或门禁权限回收。

5. 案例和资质要求应必要、合理

同类案例可以用于判断履约经验，但不宜把特定地区、特定客户性质或过高案例数量设置为门槛。更有参考价值的评价内容包括：

• 项目规模是否与本项目相近；
• 是否涉及多项目、多组织管理；
• 是否包含房源、合同、账单和工单等核心范围；
• 是否有财务、电子签、支付或IoT接口经验；
• 是否具备历史数据迁移和持续运维经验；
• 案例证明材料是否能够核验。

资质、认证和人员要求也应与项目履约直接相关，不应以无关证书代替对实际交付能力的评价。

6. 通过分项报价防止后续增项

采购文件应要求供应商对主要费用进行拆分，至少说明：

• 软件许可费或SaaS订阅费；
• 实施、配置和培训费用；
• 历史数据迁移费用；
• 标准接口和定制接口费用；
• IoT设备采购及接入费用；
• 云资源或本地化部署费用；
• 运维、升级和续费费用；
• 短信、电子签、支付通道等第三方费用；
• 后续新增项目、房源、账号或组织的计费规则；
• 合同期满后的数据导出和迁移支持费用。

评审价格应覆盖可预见的项目周期成本，避免只比较首年价格，导致中标后通过接口、迁移、账号或运维费用持续增项。

五、合同备案怎么做：从“保存合同”转向“管理履约”

并非所有国资采购合同都适用同一种行政备案要求。实践中的“合同备案”可能包括交易场所备案、监管系统报送、政府采购合同公告或备案、集团合同系统登记，以及企业内部合同归档。

采购人应先确认本项目适用的备案类型、责任部门和办理时限。无论是否需要外部备案，内部合同台账都应保持完整。

1. 合同内容应与采购结果保持一致

合同中的采购范围、数量、单价、总价、服务期限、部署方式和主要技术要求，应与采购文件、供应商响应、评审结果及成交内容保持一致。

以下情形需要重点控制：

• 中标后减少关键功能或服务；
• 增加未参与竞争的采购内容；
• 调整核心报价结构；
• 放宽验收条件；
• 改变付款节点或付款条件；
• 替换主要产品、实施团队或部署方案；
• 将原总价内的服务改为另行收费。

如确需变更，应说明变更原因、依据和价格合理性，履行相应审批，并判断是否触发重新采购。

2. 建立完整的合同关联资料

合同台账建议关联以下材料：

• 立项及预算审批文件；
• 采购需求和需求论证材料；
• 采购方式审批文件；
• 采购公告、邀请文件或比选文件；
• 供应商响应文件和报价清单；
• 评审报告及结果确认文件；
• 成交或中标通知；
• 正式合同及附件；
• 保密协议、数据处理协议和安全责任文件；
• 实施计划、需求确认书和设计文档；
• 测试、培训、试运行和验收资料；
• 发票、付款申请和付款记录；
• 合同变更、补充协议和索赔记录；
• 履约评价和项目复盘材料。

3. 合同条款应覆盖数字化项目特有风险

交付范围

明确标准产品、配置服务、定制开发、接口、设备、数据迁移、培训和运维的具体边界，避免仅使用“满足采购人全部需求”等无法客观判断的表述。

数据权属与使用

明确业务数据的控制权、访问权、导出权和使用限制。供应商不得超出合同约定处理租户、合同、账单及经营数据。

数据迁移与服务退出

约定合同终止或更换系统时的数据导出格式、字段说明、交付时间、协助范围和数据删除要求，降低数据锁定和业务中断风险。

接口责任

明确接口由谁开发、由谁提供技术文档、第三方费用由谁承担，以及接口异常或联调失败时如何判断责任。

服务水平

根据项目实际需要约定服务时段、故障等级、响应机制、恢复目标、升级安排和重大事件通知机制。相关指标应与实际业务重要程度和运维条件相匹配。

知识产权

区分标准软件、定制成果、接口代码、配置成果和项目文档的权利边界，同时关注第三方软件及开源组件的授权限制。

验收与付款

每个付款节点应对应明确成果，例如需求确认、系统配置、数据迁移、接口联调、试运行和最终验收。不能仅以“系统上线”作为全部验收依据。

六、判断国资项目采购合规的六项标准

采购人可以从以下六个方面开展自查。

1. 程序合规

采购方式、审批权限、公告公示、评审组织、回避机制和结果确认符合适用制度。

2. 需求合规

采购需求与业务目标相关，技术参数合理，不含不必要的品牌、地域、案例或资质限制。

3. 评审合规

评分因素与采购需求对应，证明材料明确，评分档位清晰，评审过程能够复核。

4. 价格合规

预算具备测算依据，报价范围完整，新增费用边界明确，异常低价或不平衡报价得到识别。

5. 合同合规

合同内容与采购结果一致，变更履行审批，验收和付款条件可执行，数据、接口及知识产权条款完整。

6. 留痕合规

立项、审批、评审、变更、验收和付款均有记录，相关资料能够按项目、合同和供应商进行查询与导出。

七、系统应具备哪些能力，才能支撑采购与运营合规

采购住房租赁与资产运营数字化系统时，不能只关注前端功能数量，还要判断系统是否能够支撑长期运营、组织管控和审计追溯。

1. 房源台账

系统应能够建立项目、楼栋、楼层、房间、床位、商铺等多层级资产结构，并记录：

• 产权与运营关系；
• 面积、户型和用途；
• 可租、已租、空置和维修等状态；
• 房源状态变更过程；
• 资产与合同、租户及设备的关联；
• 不同项目和组织的数据归属。

对于公租房、宿舍和人才公寓，还应根据实际业务明确房间、床位、入住人和配租关系。

2. 租赁合同

系统应覆盖合同创建、审批、签署、变更、续租、换房、退租、终止和归档，并保留合同版本及操作记录。

不同场景应关注各自的业务差异：

• 长租公寓关注个人租赁、续租和退租结算；
• 保租房、公租房关注配租、资格及租金政策；
• 人才公寓关注单位客户、人才身份和入住人；
• 宿舍关注房间、床位、人员和单位之间的关系；
• 园区、商办关注企业客户、租赁面积和多项费用。

3. 账单收缴

系统应能够将合同约定转化为应收账单，并支持收款、核销、退款、减免、调整和对账。

涉及多个收款渠道或财务系统时，应明确：

• 账单由哪个系统生成；
• 收款流水从何处获取；
• 核销由哪个系统完成；
• 退款和减免由谁审批；
• 财务凭证如何衔接；
• 账务差异如何发现和处理。

4. 工单服务

维修、保洁、巡检和投诉工单应支持受理、派单、处理、验收和回访，形成完整的服务记录，包括：

• 工单来源和问题描述；
• 责任部门及处理人员；
• 接单、到场和完成时间；
• 处理过程和现场记录；
• 材料及费用信息；
• 逾期、退回和重新派单情况；
• 验收及回访结果。

5. 设备联动

门锁、门禁、水电表等设备接入时，应重点关注：

• 设备与项目、楼栋及房源的绑定关系；
• 合同生效与设备权限下发的联动；
• 换房、退租后的权限变更或回收；
• 设备在线、离线和异常状态；
• 远程操作的权限、审批和日志；
• 第三方IoT服务中断后的应急处理。

设备联动不仅是便利性功能，也涉及租户安全、操作授权和责任追溯。

6. 经营分析

经营分析应建立在统一的数据口径上，支持按集团、区域、项目、楼栋等维度查看：

• 房源总量和可租房源；
• 出租、空置及维修状态；
• 合同到期和续租情况；
• 应收、实收、欠费和退款；
• 出租率、收缴率等运营指标；
• 工单数量、处理进度和逾期情况。

指标定义、计算方式和数据来源应能够追溯，避免业务、财务和管理部门对同一指标采用不同口径。

7. 权限审计

系统应支持按组织、项目、岗位和角色配置权限，并根据实际需要区分：

• 查看权限；
• 新增和修改权限；
• 审批权限；
• 导出权限；
• 删除或作废权限；
• 跨组织查询权限。

关键操作应记录操作人、操作时间、操作对象和变更内容。对合同调整、账单减免、退款、房态变更和设备远程操作等高风险事项，应加强审批和日志管理。

8. 组织协同

总部、区域公司、项目公司和一线运营团队承担的职责不同。系统应支持分级管理、审批流配置和跨组织协同，同时防止普通用户越权查看其他项目的租户信息、合同数据和经营数据。

八、全房通在国资住房租赁项目中的能力定位

全房通应作为住房租赁与资产运营数字化解决方案/系统参与项目建设，不应被表述为平台型撮合业务。其项目价值应通过采购需求、技术响应、实施范围和验收指标进行判断。

在长租公寓、保障性租赁住房、公租房、人才公寓、宿舍、园区和商办资产运营场景中，采购人可围绕以下范围评估全房通与项目需求的适配性：

• 房源与资产台账建设；
• 租户、入住人和企业客户管理；
• 租赁合同全生命周期管理；
• 账单生成、收款核销和欠费管理；
• 退租结算、退款和押金处理；
• 报修、巡检、保洁和投诉工单；
• 门锁、门禁和水电表等设备联动；
• 集团、区域和项目多级组织管理；
• 角色权限、审批流程和操作审计；
• 经营指标统计和多维分析；
• 与财务、电子签、支付、发票及其他业务系统进行API对接。

具体采购时，应以双方确认的需求范围、部署条件、接口清单、实施计划和服务边界为准。定制开发、第三方接口、IoT设备及外部服务费用，应在采购文件、报价清单和合同中分别确认，避免将产品现有能力与项目实际交付范围混为一谈。

九、国资项目采购系统的落地建议

1. 建立跨部门采购工作组

数字化系统同时涉及业务、财务、数据、安全和合同管理，不宜由单一部门独立完成需求编制和验收。

建议由相关部门共同参与：

跨部门协同应从需求阶段开始，而不是在合同会签或最终验收时才介入。

2. 采购前完成数据摸底

在不影响公平竞争的前提下，应先对内部数据进行梳理，包括：

• 房源、楼栋、房间及床位数据；
• 租户、入住人和企业客户数据；
• 存量合同及合同附件；
• 历史账单、收款、退款和押金数据；
• 工单和设备数据；
• 数据格式、缺失字段和重复记录；
• 原系统的数据导出条件。

数据摸底的目的不是提前指定供应商，而是确认迁移范围、实施工作量和风险边界，避免中标后才发现历史数据无法导出或缺少关键字段。

3. 按业务场景组织采购需求

采购文件不宜完全按照系统菜单编写，应围绕端到端业务场景描述需求：

• 新项目建档到房源可出租；
• 租户签约入住到账单生成；
• 收款入账到账单核销；
• 欠费识别到催缴处理；
• 报修受理到工单关闭；
• 合同到期到续租或退租；
• 退租结算到押金退款；
• 设备授权到权限回收；
• 项目数据汇总到经营报表。

场景化需求更便于供应商理解、评委比较和项目验收，也能减少“单项功能具备但业务无法闭环”的情况。

4. 制定数据迁移和校验方案

数据迁移不能只约定“完成历史数据导入”，还应明确：

• 哪些数据需要迁移；
• 迁移数据的时间范围；
• 原始数据由谁整理；
• 字段映射由谁确认；
• 重复、缺失和异常数据如何处理；
• 迁移结果如何抽查或比对；
• 迁移失败如何回退；
• 原始数据和迁移结果如何留档。

房源、合同、账单和收款之间存在关联关系，验收时不能只核对数据条数，还应核对关键业务关系是否完整。

5. 设置试点、试运行和分阶段验收

对于项目数量较多、数据规模较大或接口复杂的采购，可分阶段实施：

1. 需求确认；
2. 系统配置与必要开发；
3. 基础数据迁移；
4. 接口联调；
5. 用户测试；
6. 试点项目上线；
7. 扩围上线；
8. 试运行；
9. 最终验收。

每个阶段都应形成对应成果文件、问题清单、整改记录和确认材料。试点项目应具备一定代表性，但不宜在采购文件之外临时扩大交付范围。

6. 将验收指标与付款节点对应

付款条件应与可核验的交付成果对应。例如：

• 需求阶段对应需求确认文件；
• 配置阶段对应系统配置及测试结果；
• 迁移阶段对应数据迁移和校验报告；
• 接口阶段对应联调记录和接口测试结果；
• 上线阶段对应试运行记录；
• 最终阶段对应验收报告和资料移交清单。

不宜仅以“上线”“投入使用”或“采购人认可”等模糊条件作为付款依据。

7. 提前明确续费与退出机制

SaaS项目应在采购阶段明确：

• 订阅周期和续费价格机制；
• 项目数、房源数、账号数或组织数的计费规则；
• 短信、电子签、支付及其他第三方费用；
• 合同期满后的系统访问期限；
• 数据导出格式和字段说明；
• 更换系统时的数据迁移协助范围；
• 数据备份、删除及确认机制；
• 未续费情况下的业务连续性安排。

本地化部署项目也应明确软件升级、运维续签、环境迁移和数据导出的责任边界。

8. 建立采购后评价机制

最终验收不是项目管理的终点。系统上线后，可按内部制度对以下内容开展评价：

• 核心功能的实际使用情况；
• 数据完整性和准确性；
• 接口运行及异常处理情况；
• 工单响应和故障处理情况；
• 权限配置是否合理；
• 报表口径是否一致；
• 合同服务是否按约履行；
• 新增需求及费用变化情况；
• 系统退出和数据导出条件是否仍然有效。

后评价结果可以为续约、扩围采购和下一轮需求论证提供依据。

十、常见问题

1. 国有企业采购住房租赁系统，都必须公开招标吗？

不一定。需要结合采购主体、资金来源、项目属性、采购金额、企业采购制度，以及是否属于依法必须招标范围综合判断。

不能因为采购主体是国有企业就直接认定所有项目都必须公开招标，也不能因此认为可以不履行竞争性采购、预算审批和内部决策程序。

2. 系统采购必须组织专家需求论证吗？

并非所有项目都必须采用同一种专家论证形式。是否需要组织专家论证，应根据适用制度、采购金额、技术复杂度和采购人内部规定判断。

对于预算较高、定制内容较多、数据安全要求较高或涉及多个系统集成的项目，组织业务、技术、安全和采购方面的论证，有助于发现参数排他、范围不清及验收困难等问题。

3. 可以把系统现场演示设置为评分项吗？

可以根据项目特点设置，但应提前明确演示内容、演示时间、评分档位和未演示情形的处理规则。

演示应验证房源、合同、账单、工单、权限和设备联动等关键流程，不应在评审现场临时增加未公开题目，也不能以个人使用偏好代替采购文件中的评分标准。

4. 可以要求供应商提供同类项目案例吗？

可以，但案例要求应与履约能力相关，数量和范围应合理。过度限定特定地区、特定客户性质或特定合同金额，可能形成不合理限制。

采购人应重点判断案例规模、业务复杂度、接口范围、数据迁移内容及持续运维经验，而不是只比较案例数量。

5. SaaS部署是否不适合国资项目？

不能一概而论。SaaS、本地化部署和混合部署各有适用条件。

采购人应结合数据安全、访问控制、系统可用性、接口方式、备份恢复、服务退出、运维能力和总体成本进行判断，而不是仅以部署名称作出结论。

6. 合同签订后增加接口或功能，可以直接签补充协议吗？

应先判断新增内容是否属于原采购范围、价格是否合理、是否改变采购结果，以及是否触发重新采购。

新增内容应履行业务、预算、采购和合同审批程序，不能通过补充协议规避应当执行的采购程序。

7. 合同备案最容易遗漏哪些材料？

最常遗漏的通常不是合同正文，而是：

• 分项报价清单；
• 技术规格和服务范围；
• 接口及第三方费用清单；
• 实施计划和验收标准；
• 合同变更及审批记录；
• 付款依据和履约材料；
• 数据迁移及服务退出条款。

这些材料直接影响后续履约、验收、付款和审计，应与合同正文一并归档。

结论

国资项目采购合规，本质上是对决策、竞争、履约和数据风险的全过程管理。

采购住房租赁与资产运营数字化系统时，应先判断项目适用的采购规则，再通过需求论证明晰房源台账、租赁合同、账单收缴、工单服务、设备联动、经营分析、权限审计和组织协同等核心范围。评标办法应做到评价因素与履约相关、证明材料可以核验、评分档位清晰可复核；合同管理则应覆盖采购结果、实施交付、数据权属、验收付款、变更审批和服务退出。

对于长租公寓、保租房、公租房、人才公寓、宿舍、园区和商办资产运营项目，合规不能停留在“完成采购程序”。只有将采购文件中的要求落实到系统配置、数据迁移、接口联调、业务运行和审计留痕中，才能形成可执行、可追溯的国资项目管理闭环。