即时通讯系统招标参数怎么写才不排他

即时通讯系统的招标文件,最容易出问题的地方往往不是预算,而是技术参数。预算写少了可以调整,工期写紧了可以商量,参数一旦写得有指向性,轻则被供应商质疑,重则修改文件、重新采购。

很多采购人以为,只要不写品牌名就不算排他。实际情况并非如此。 把某一款产品的专有功能、技术路线、参数组合或证明材料原样搬进招标文件,即使全篇没有出现一个品牌名,也可能形成排他。 即时通讯系统招标参数怎么写才不排他,关键不是删掉几个词,而是把“我想要某一家的产品”改写成“我的业务需要什么结果、如何验证”。

下面按适用规则、风险识别、需求调查、参数翻译、自检审查的顺序,给出一套可以直接用于招标文件编制的方法。

一、先分清这份参数受哪套规则约束

在动笔之前,先确认项目性质。政府采购项目、依法必须招标的项目和企业自主采购项目,适用的规则并不完全相同。

政府采购货物和服务,主要看《中华人民共和国政府采购法实施条例》第二十条。条文列了八种属于以不合理条件对供应商实行差别待遇或者歧视待遇的情形,其中与技术参数最直接相关的有三项:

  • 设定的资格、技术、商务条件与采购项目的具体特点和实际需要不相适应,或者与合同履行无关;
  • 采购需求中的技术、服务等要求指向特定供应商、特定产品;
  • 限定或者指定特定的专利、商标、品牌或者供应商。

依法必须招标的项目,还要看《中华人民共和国招标投标法》第二十条。条文明确,招标文件不得要求或者标明特定的生产供应者,也不得含有倾向或者排斥潜在投标人的其他内容。《中华人民共和国招标投标法实施条例》第三十二条进一步列出七种情形,包括设定的资格、技术、商务条件与项目具体特点和实际需要不相适应,以及限定或者指定特定的专利、商标、品牌、原产地或者供应商。

企业自主采购不当然适用上述法定招标规则,但公平竞争、可验证、可审计的原则同样适用。如果企业内部有采购管理制度、供应商库管理办法或集团招标规则,还要按内部规则执行。 先确认适用规则,再设计参数,可以避免把不同体系的要求混在一起。

如果是政府采购项目,《政府采购需求管理办法》(财库〔2021〕22号)值得重点看。它要求采购需求清楚明了、表述规范、含义准确;量化指标要明确等次,有连续区间的按区间划分等次;采购活动开始前要建立审查机制,重点审查技术要求是否指向特定的专利、商标、品牌、技术路线,评审因素是否具有倾向性。这些要求,正好对应本文后面要讲的写法。

二、即时通讯系统招标参数的排他性通常不藏在品牌名里

直接写品牌、型号、专利、原产地,当然是最明显的排他。但在即时通讯系统里,更常见的是几种不容易被发现的写法。

1. 把技术实现方式写成采购目标

例如要求“客户端必须采用 Electron + React 开发”。这句话没有品牌名,却把一个实现技术写成了准入门槛。除非采购人现有的运维体系、终端环境或二次开发能力确实要求某个技术栈,并且能说明理由,否则这类要求很容易把采用其他技术路线的产品排除在外。

同样的写法还有“必须支持特定私有协议”“必须采用特定架构”“必须提供与采购人现有 OA 绑定的原厂插件”。 采购目标是业务结果,不是实现方式。 技术路线可以作为了解产品的信息,不宜直接变成否决项。

2. 单项参数都常见,组合起来只剩一家

这是最隐蔽的一种。单看每一条,市场上可能有很多产品能满足;把十几条放在一起,交集可能只剩一家。例如同时要求万人级在线、百人音视频会议、特定国产数据库、特定国产 CPU、特定移动端系统、与现有 OA 的原厂插件、特定检测报告。每一条都有理由,合在一起却没有给其他技术路线留下空间。

判断这类风险,不能逐条看,要看整份参数的“交集”。一个实用的方法是: 把参数交给不熟悉项目的同事,请他指出至少三种不同的实现路径;如果只能想到一种,就要重新检查组合是否过窄。

3. 证明材料指定得太死

“必须提供指定检测机构出具的检测报告”“只接受官网截图”“必须提供特定认证证书”,这些要求看似是在提高证明力,实际上可能把有能力做产品的供应商挡在门外。证明材料应该服务于验证,而不是变成新的门槛。除法律法规明确要求外,一般应允许功能截图、产品文档、第三方检测报告、现场演示等多种方式中的一种或多种。

4. 星号条款过多

星号条款通常意味着不满足即否决。适度的实质性条款是必要的,但如果把界面细节、非核心功能、辅助能力都标成星号,供应商只要有一项不满足就会出局,竞争范围会被大幅压缩。 实质性条款只应该留给影响业务连续性、安全底线和核心体验的要求。

5. 资格条件和交付条件也会排他

技术参数之外,资格条件同样可能造成排他。例如限定特定行政区域或特定行业的业绩、要求本地分支机构、设置与履约无关的注册资本或认证、把交付周期压到只有现成产品才能完成。这些内容不属于技术参数,但在评审中产生的排除效果是一样的。

下表列出几种常见写法及其更中性的替代方向。

常见写法 可能的问题 更中性的问法
客户端必须采用 Electron + React 开发 把实现技术当成采购目标 客户端应支持 Windows、macOS、Linux 及移动端,在目标环境完成安装、登录、消息收发测试,技术栈不限
必须提供与现有 OA 绑定的原厂插件 指向特定产品生态 提供开放 API 或 Webhook,能与采购人现有 OA 完成待办推送和单点登录联调
必须提供指定检测机构的检测报告 证明方式单一,可能只有少数供应商能提供 提供功能截图、产品文档、第三方检测报告或现场演示中的一种或多种,除法定要求外不指定机构
所有参数均为星号条款 非核心功能变成否决项 只把影响业务连续性和安全底线的要求设为实质性条款,其余按量化指标评分
投标人须有 3 个本省政务案例 特定区域业绩与履约能力没有必然关系 要求同类项目案例,明确同类范围,不限定行政区域,数量按项目需要设置

排他性不是“参数高”的同义词,而是“没有必要、无法验证、只指向少数供应商”的组合结果。 高标准如果有项目依据、有验证方法、有多条技术路线可以满足,并不当然违规。

三、写参数之前,先做需求调查

很多排他性参数不是故意写出来的,而是从一家供应商的产品说明书里抄出来的。对方把功能名称、技术路线、性能数字写得越细,采购人越容易觉得“这就是我想要的”。但产品说明书回答的是“这家能做什么”,不是“项目需要什么”。

《政府采购需求管理办法》第十条允许采购人在确定采购需求前,通过咨询、论证、问卷调查等方式开展需求调查,了解产业发展、市场供给、同类项目历史成交信息以及后续运维等情况。面向市场主体开展调查时,选择的调查对象一般不少于 3 个,并应当具有代表性。第十一条还规定,1000 万元以上的货物、服务采购项目,3000 万元以上的工程采购项目,涉及公共利益或社会关注度较高的项目,以及技术复杂、专业性较强、需要定制开发的信息化建设项目等,应当开展需求调查。

即时通讯系统通常涉及组织架构、身份认证、网络边界、数据留存、移动办公和业务系统集成,属于技术复杂、专业性较强的信息化项目。即使金额没有达到强制门槛,做一轮需求调查也能明显降低后面的质疑风险。

调查对象不要只找一家。可以把同类单位的使用和运维人员、不同技术路线的供应商、行业专家或招标代理机构都纳入进来,分别了解:

  • 实际使用场景,是总部办公、分支机构协同、内外网隔离,还是移动办公;
  • 用户规模、峰值在线人数、消息和文件量级;
  • 现有 OA、ERP、邮件、目录服务等系统的接口条件;
  • 数据留存、审计、信创、行业监管等合规要求;
  • 预算范围、运维人力、迁移和旧数据处理的约束。

调查结束后,输出一份需求清单,写清每项需求的来源、使用场景、必要性和验证方式。 需求调查的目的是形成自己的需求,不是让供应商替自己写参数。

这里要澄清一个常见误区。法规要求的是需求调查对象一般不少于 3 个,并不是要求每条技术参数都有 3 家产品满足。反过来,即使有 3 家产品能满足,也不能证明参数一定没有指向性。真正要判断的是:这项要求是否为实现项目目标所必需,是否指向特定供应商或特定产品,是否给不同技术路线留下了竞争空间。

四、把即时通讯系统的业务需求翻译成中性参数

需求调查完成后,下一步是把“我们要什么”翻译成供应商能响应、评审能验证、不同产品能竞争的语言。可以按下面五步处理。

1. 先写场景和结果,再写指标

功能名称只是起点。真正有用的参数,要说清在什么场景下、完成什么动作、达到什么结果。例如:

  • 把“支持消息检索”写成“支持按关键字、时间范围、发送人、会话类型组合检索历史消息,检索范围受权限控制,在采购人给定的消息量级下响应时间不超过约定值”;
  • 把“支持音视频会议”写成“支持百人音视频会议、屏幕共享和分组讨论,在采购人网络环境下完成并发和弱网测试”;
  • 把“支持与 OA 集成”写成“支持单点登录和组织架构同步,支持将 OA 待办推送到指定用户或群组,提供接口文档、调用示例和联调支持”。

场景越具体,参数越不容易被某一家产品的功能名称绑架。

2. 用区间和等次代替唯一值

《政府采购需求管理办法》第九条要求,量化指标应当明确相应等次,有连续区间的按照区间划分等次。这条规则对即时通讯系统很实用。

不要直接写“支持 10000 人同时在线”这种从产品彩页上抄来的单点数字。可以改为按采购人的峰值在线人数、日活用户数、消息发送峰值提出容量要求,要求投标人提供容量测算依据和压测报告,并在 POC(概念验证)中验证。也不要只写“消息延迟不超过 100 毫秒”,而要同时写清测试环境、样本量、统计口径和失败判定方式。

没有测试方法的性能数字,既无法验收,也无法证明公平。 同理,可用性、故障恢复时间、扩容方式等指标,都应该附带统计口径和验证方法。

3. 按能力域组织参数

即时通讯系统的参数很容易写成一张长长的功能清单。更清晰的做法是按能力域组织,每个域先回答业务问题,再落到可验证的指标。下面这张表可以作为起草时的框架。

能力域 要回答的问题 中性写法方向
部署与数据边界 服务端、数据库、文件存储放在哪里,是否依赖公有云,是否支持内网或专网 明确部署位置、网络环境、数据备份与恢复方式,要求提供部署架构图和端口清单
消息与协作 单聊、群聊、文件传输、历史检索、多端同步、离线消息、音视频会议是否满足场景 按消息类型、并发规模、检索维度、终端类型和会议规模提出可测试要求
组织与身份 组织架构如何同步,账号如何开通、变更和停用,是否支持单点登录 要求支持目录服务同步、账号生命周期管理、单点登录和多级组织
集成与开放 能否连接现有 OA、ERP、邮件、告警和业务系统 要求提供 API、Webhook、机器人或应用中心等开放方式,并完成指定场景联调
安全与审计 传输和存储如何保护,权限如何控制,是否留痕,数据如何留存 按项目适用的安全要求写清身份鉴别、传输保护、存储保护、权限控制、审计日志和留存期限
客户端与信创 支持哪些桌面和移动端,是否适配采购人使用的国产软硬件环境 列出目标操作系统、CPU、数据库和终端组合,要求在目标环境完成安装、登录、消息收发和文件传输测试
性能与可靠性 能承载多少用户和消息,故障时如何恢复,如何扩容 按峰值在线、消息吞吐、响应时延、可用性和恢复时间提出要求,并要求压测或 POC 验证
运维与服务 如何部署、升级、监控、备份,出问题谁负责 明确部署方式、升级方式、监控告警、备份恢复、服务响应时间和验收标准

这张表不是固定目录,也不需要每个项目都写满。 只保留与项目目标直接相关的域,每个域下的参数都要能回答“为什么需要”和“怎么验证”。

4. 区分实质性要求、评分项和证明材料

《政府采购需求管理办法》第二十一条规定,对于采购需求客观、明确的项目,客观但不可量化的指标应当作为实质性要求,不得作为评分项;参与评分的指标应当是量化指标,评分项按照量化指标的等次设置不同分值。这条规则可以解决很多评审争议。

可以按三层来设计:

  • 实质性要求只放不满足就无法实现项目目标的内容,例如部署在指定网络、核心消息收发、权限隔离、数据留存底线;
  • 评分项放可以量化的性能、容量、兼容范围、服务响应时间,按等次设置分值;
  • 证明材料与参数一一对应,允许截图、文档、第三方报告、现场演示等多种方式,除法定要求外不指定检测机构。

不要把“界面美观”“体验好”“品牌知名度高”这类主观判断放进评分项。它们既难以客观评价,也容易成为倾向性的入口。也不要把所有参数都标成星号,星号越多,竞争越窄。

5. “或相当于”不是护身符

有些招标文件会写“参考某一品牌或相当于”,以为这样就不算指定品牌。这个写法并不能自动解决排他问题。如果后续参数仍然按参考品牌的特有功能、技术路线和证明材料来写,其他品牌即使名义上可以“相当于”,实际上也响应不了。

更稳妥的做法是先用功能和性能描述需求,不写参考品牌;如果项目确实需要引用参考品牌,要说明理由,提供可替代的实现路径,并确保后续参数没有复制某一品牌的专有特征。具体到政府采购项目,是否允许出现参考品牌、如何表述,还应结合适用法规和主管部门要求确认。

五、写完后用这张清单做一次排他性自检

参数起草完成后,不要直接发公告。可以先用下面这份清单逐项检查,再进入审查流程。

  1. 参数中是否出现特定品牌、型号、专利、商标、原产地或供应商名称?
  2. 是否把某一款产品的专有功能名、技术路线或架构写成了准入条件?
  3. 单项参数是否常见,组合起来是否只剩少数供应商能满足?
  4. 每条参数是否能对应真实业务场景,是否能说明必要性?
  5. 是否把非核心功能设成了星号条款或否决项?
  6. 评分项是否都是可量化指标,是否按等次设置分值?
  7. 证明材料是否指定了检测机构、证书类型或截图来源,是否允许替代方式?
  8. 是否设置了与履约无关的业绩、注册资本、本地分支机构等资格条件?
  9. 是否给潜在供应商留出了澄清、质疑和补充材料的渠道?
  10. 是否经过采购、业务、财务、法务或监督部门的审查,并保留了书面记录?

除了逐项检查,还可以做两个“换位测试”。一是让不熟悉项目的同事只看参数,请他说出至少三种不同的实现路径;如果只能想到一种,说明参数可能过窄。二是邀请不同技术路线的供应商按同一份参数匿名响应,看看是否只有一家能全部满足。POC 阶段则用真实场景验证,测试用例与参数一一对应,记录测试环境、步骤和结果,不要只看产品彩页。

《政府采购需求管理办法》第二十九条要求采购人建立审查工作机制,在采购活动开始前对采购需求和采购实施计划进行审查;第三十一条把“是否指向特定供应商或者特定产品”列为重点审查内容,包括技术要求是否指向特定的专利、商标、品牌、技术路线,评审因素设置是否具有倾向性。第三十二条还明确,参与确定采购需求和编制采购实施计划的专家和第三方机构,不得参与审查。 让写参数的人自己审查自己,很难发现问题。

如果收到供应商质疑,先核对三件事:这项参数是不是项目必需,有没有需求调查或论证依据;参数描述是否指向特定供应商或特定产品;证明材料是否只有少数供应商能提供。能修改的及时澄清或更正,不要为了维护原文件而强行解释。保留需求调查、论证、审查和答复记录,后面无论走到投诉还是监督检查,都用得上。

六、把参数落到产品上,以喧喧IM为例

参数写成中性语言之后,再看具体产品如何响应,顺序不能反过来。以喧喧IM为例,它是一款支持私有化部署的企业即时通讯系统,由禅道软件(青岛)集团有限公司研发,提供开源版和专业版两档。

如果把前面的能力域落到喧喧IM上,可以这样对应:

  • 部署与数据边界:服务端部署在采购人自有服务器或指定机房,支持内网访问,消息、文件和组织架构数据留在企业侧,具体部署方式可参考 私有化部署;
  • 安全与审计:通信全加密,服务端文件采用 AES 256 位加密存储,消息在数据库中加密存储,并提供 IP 登录限制、界面水印等管控能力;其中部分高级安全能力属于专业版范围,具体以 通讯安全页面和版本说明为准;
  • 客户端与信创:支持 Windows、macOS、Linux 及 iOS、Android 客户端,适配银河麒麟、统信 UOS、Deepin 等国产操作系统,以及申威、鲲鹏、飞腾、龙芯、海光、兆芯等国产 CPU,适配清单可查看 信创适配;
  • 集成与开放:提供开放 API、Webhook、单点登录、应用中心和机器人开发能力,可与禅道项目管理及现有 OA、ERP 等系统对接,具体接口方式可参考 灵活扩展;
  • 性能与协作:支持 10000+ 用户同时在线,音视频会议支持百人会议,架构轻量、部署简单,聊天、音视频、文件协同等能力保持完整,不是功能上的减配;
  • 版本选择:开源版提供核心功能,专业版面向信创、高级安全和完整企业级能力,差异可查看 版本与购买。

需要说明的是,这些是喧喧IM的产品能力,不是招标参数的模板。 一份合格的招标参数,应该让不同技术路线的产品都有机会响应,而不是把某一款产品的功能清单倒推成门槛。 具体项目是否适用,仍要以采购人目标环境中的测试结果、官方文档和合同约定为准。

七、常见问题

1. 只写功能、不写品牌,就一定不排他吗?

不一定。如果功能描述用的是某一款产品的专有名称,或者参数组合只有一家能满足,即使没有出现品牌名,也可能构成排他。判断标准不是“有没有品牌名”,而是“是否指向特定供应商或特定产品、是否为实现项目目标所必需、是否给不同技术路线留下竞争空间”。

2. 技术参数是不是必须三家满足?

法规要求的是需求调查对象一般不少于 3 个,并没有规定每条技术参数必须有三家产品满足。三家满足也不能证明参数没有指向性。反过来,如果参数确实必要、描述中性、验证方式合理,即使暂时只有少数供应商能响应,也不等于当然违规。具体判断仍要回到项目需求、市场竞争和适用法规。

3. 项目确实需要较高参数,算不算排他?

不当然算。高标准如果有项目依据、有预算和运维支撑、有明确的验证方法,并且市场上存在多条技术路线可以满足,可以是合理需求。需要注意的是,不能把“高”当成“唯一”,也不能用高标准掩盖指向性。必要时通过需求调查、专家论证和 POC 说明必要性和可实现性。

4. 可以要求私有化、信创和安全合规吗?

可以提出与项目相关的部署、国产化适配和安全合规要求,但要写清依据、适用范围和验证方式。私有化部署要说明数据边界和网络环境;信创要列出目标软硬件组合并要求实际测试;安全合规要求要与项目适用的法律法规、行业监管和密级相匹配。如果项目适用等级保护等制度,应按相应制度写清范围和验证方式。不要把特定认证写成所有项目的通用门槛,也不要在没有依据的情况下指定某一算法或某一机构。具体合规要求建议由法务、合规和行业主管部门共同确认。

5. 供应商质疑参数排他,采购人应该怎么处理?

先核对参数的必要性、指向性和证明材料,再决定是否澄清或更正。能用量化指标、区间、等次和多种证明方式解决的,优先修改;确实需要保留的,准备好需求调查、论证、审查和测试记录,说明理由。不要把所有质疑都当成恶意投诉,也不要在没有依据的情况下强行维护原参数。依法需要答复的,按规定的时限和程序处理。

参考资料

  • 《中华人民共和国政府采购法实施条例》第二十条,http://www.tmg.gov.cn/qczl/36t/twgk/199224.htm
  • 《中华人民共和国招标投标法》第二十条,https://ggzyjy.ahsz.gov.cn/fwzn/003014/003014001/20201108/27d96048-517f-49c6-9ad4-d70d2e36e32b.html
  • 《中华人民共和国招标投标法实施条例》第三十二条,https://www.luojiang.gov.cn/gk/xwzx/bmdt/1575619.htm
  • 《政府采购需求管理办法》(财库〔2021〕22号),https://czt.jl.gov.cn/zwgk/zzfg/202106/t20210618_1250331.html

立即开始,掌控您的企业沟通

私有化部署 · 全链路加密 · 信创全栈适配

直接下载体验 →
获取方案 获取方案
联系我们
社群交流