您的浏览器不支持JavaScript!

第24章 - 提案请求和竞争性谈判

附录 D:质量 IT RFP 的内容

部分 部分 内容描述

1

简介

提供问题陈述,并且必须足够详细,以便供应商了解推动 RFP 的业务问题以及可能导致问题的技术问题。

2

提案说明和管理

包含供应商为提交可接受的提案必须遵守的所有管理要求和信息。本节包括采购的基本规则,从提交 RFP 到授予合同,并应包含以下类型的信息:

  • 是否以及何时举行提案前会议
  • 采购周期的相关日期
  • 准备和提交提案的要求(即《弗吉尼亚州法典》的要求以及提案协议)
  • 如何评估提案
  • RFP 单一联系人姓名和联系信息
  • 何时、何地、向谁提交提案
  • 供应商充分响应所需的其他信息

如果说明不完整或不清楚,供应商可能会忽略关键会议或里程碑。一些供应商可能将缺乏质量指导视为项目团队薄弱或项目存在冲突的标志,这可能会导致主要行业供应商不提交提案。如果供应商未能遵守 RFP 的管理要求,则可能导致提案被拒绝。本节应提供响应 RFP 的明确规则,并让供应商了解不遵守这些规则的处罚。

3

提案格式

提供有关如何格式化和装订提案以及所需媒体(即硬拷贝、CD 等)的详细信息。如果要单独提交各个提案部分(即技术部分、成本部分、编辑部分等),则最好添加一个表格来显示这些部分。本节不应与2节中的提案说明重复或冲突。

4

现状

准确描述机构的组织背景和项目当前的业务和技术环境,以便供应商能够有效、准确地提出解决方案来适应或修改该环境以满足新的要求。当前业务环境的描述应包括所有受影响的当前业务服务和流程的用户和受益者。当前技术环境的描述应该是一个清晰的定义,包括所有当前正在使用的硬件和软件,可以用来或应该用来满足项目要求的内容,以及当前与其他现有系统/平台和/或应用程序的接口。工作流程和应用程序界面可以用视觉效果来呈现。

5

功能和技术要求

提供功能和技术要求以及足够的信息,以使供应商了解问题并准备完整而坚定的提案。该概述应解决当前的业务应用和技术环境(硬件、软件、通信)。建议机构不要使用“必须”和“应该”的技术要求,而是允许供应商提出如何解决问题的建议,作为基于解决方案的提案的一部分。技术和功能要求部分包括供应商必须回答的问题,例如:

  • 关键成功因素
  • 当前系统的功能规格
  • 预计系统的功能规格
  • 性能规格
  • 服务水平期望
  • 硬件要求(如果强制性要求)
  • 软件需求
  • 安全和数据保护要求
  • 通信要求(如果是强制性的)
  • 测试要求
  • 他们的解决方案是否符合(或能够符合)VITA安全、数据标准和企业架构以及IT可访问性/ 508合规性ITRMPSG

项目管理要求规定了管理和实施项目的条件。本节应根据项目的复杂性和任务关键性,向供应商提供制定项目计划、风险缓解计划或其他管理计划所需的信息,涵盖项目的需求定义、实施、安装、测试、培训、维护和其他阶段。拟议的项目计划保证供应商拥有成功履行合同所需的资源。项目管理计划通常包含以下内容:

  • 人员配备需求
  • 场地准备职责
  • 交货和安装时间表和计划
  • 系统验收测试要求
  • 系统维护要求
  • 系统培训要求
  • 文件要求

机构应该记住,供应商有可能满足技术要求,但无法满足管理要求,这从他们对本节的回应不佳或不充分可以看出。管理部分将有助于区分管理能力成熟或不成熟的供应商。

您可以要求供应商确定与 RFP 和期望项目目标相关的所有假设和任何潜在风险;和/或要求他们详细描述类似的项目以及他们如何解决在履行职责过程中出现的问题以使客户满意。

6

清晰明确的绩效衡量标准和执行规定

符合《弗吉尼亚州法典》第2 .2- 4303.01条所定义的“高风险”的 IT 招标和合同必须包含清晰明确的绩效衡量标准和执行条款,包括供应商不履约情况下的补救措施。

使用以下工具来了解更多有关明确、独特的绩效衡量标准和执行条款(包括补救措施)的信息:

         重大 IT 采购、高风险 IT 采购和

         1 . 委托采购 

         2 . 绩效指标工具

 

7

供应商简介

要求供应商描述其业务和专业资格并提供参考。应该要求他们提供有关其公司和财务状况以及可作为其专业表现和诚信参考的客户的详细信息。以下示例是本节中通常需要的内容:

  • 供应商的公司历史、组织结构、位置和业务规模状况(即 DSBSD 认证状况,如果适用)。
  • 供应商提供该类型解决方案或产品的一般背景经验和能力
  • 供应商与任何拟议合作伙伴/分包商/制造商之间的关系描述(如果有),以及这种关系持续了多长时间
  • 有证据表明供应商拥有履行合同所需的技术、运营和管理技能、人员和财务资源以及可行性
  • 当前安装的相同/类似产品、系统或
  • 具有类似项目、配置和/或应用并能提供参考的客户名称,包括联系人姓名和电话号码。
  • 供应商资质,包括简历、公司简介和业务
  • 供应商提供服务的通常方法,包括工作计划的描述、要使用的方法以及项目交付物/时间表的样本时间表

8

SWaM 部分

要求供应商提供“供应商采购和分包计划”,其中说明供应商预计直接与分包商一起履行合同要求的总体承诺百分比。此外,还要求供应商提供其在履行合同时预计使用的所有分包商的清单。分包商名单应指定 SWaM 业务的分包商以及非 SWaM 业务的分包商。如果供应商DOE预计在履行合同时不会使用分包商,则要求供应商在回复中说明这一事实。

9

定价信息

指定供应商如何提供定价信息,并提供详细的格式供他们在制定价格提案时遵循。指示应足够清晰,以确保可以在平等的基础上比较价格提案。为了便于比较,请考虑提供一个示例电子表格,将所提议的系统分解为如下几个部分:

  • 系统软件
  • 应用程序开发软件
  • 安装
  • 维护
  • 培训
  • 文档
  • 项目管理
  • 独特的硬件或软件集成
  • 许可费(持续)

包括定价计划/方案作为如何提交提案价格的示例。如果总价定价不利,则使用定价方案来获取未知数量或小时数的价格。要求列出经常性费用和非经常性费用的明细。定价计划应与交付成果挂钩,并且必须与招标中规定的付款方式一致。

查看定价表时,请注意涉及一次性成本与经常性成本的定价。软件包的初始价格是一次性成本;年度维护和软件许可费用是经常性成本,必须确定这些成本才能确定项目的总生命周期成本。定价通常不是授予合同的唯一决定因素,但应该用来打破两个具有同样优秀的技术和管理提案的供应商之间的平局。

对于复杂的项目,您还可以要求供应商提交里程碑定价计划,其中可以应用保留百分比,并在最终发票最终验收后支付。这可以激励供应商,并在最终验收延迟或出现问题时为机构提供保护。如果供应商不履行合同,它还可以使合同在任何里程碑更容易地分割。

10

代理标准协议(即合同模板)

包含拟议的合同模板,其中有保密协议、保密性、数据保护和安全要求、担保、许可协议要求和其他法定、法律和 IT 特定条款和条件,或可能需要的任何联邦流程条款。应要求供应商在拟议的合同模板上划出红线,以突出显示他们不能同意的所有例外情况。供应商此时不应该对责任条款进行划界。

他们可以在以后的谈判中首次提出问题或意见。在提案评估期间确定关键问题,因为可能会选择不接受该机构合同的供应商。

11

供应商部分(可选)

允许供应商包含他们认为相关的信息,尽管 RFP 中没有要求或请求。他们还可以讨论与 RFP 和他们的提案相关的潜在问题。例如,供应商可能有超出 RFP 范围的额外产品特性需要展示,或者提供买方未曾预料到的独特解决方案,或者为 RFP 中出现的其他供应商未考虑到的问题提供解决方案。即使该特定供应商的DOE没有获胜,问题的解释和潜在的解决方案仍然值得考虑。

12

附录

包含大量但相关的信息,例如网络图、技术需求研究、项目计划大纲和其他详细信息。示例包括:

  • 带有统计信息的电子表格
  • 通信网络图纸和
  • 当前列表
  • 标准内使用
  • 暂定项目计划
  • 合同模板
  • 小型企业分包计划表
  • 供应商填写的州公司委员会表格,注册在

然后,供应商可以获得该信息,但DOE不会分散 RFP 叙述部分的注意力。 注意:告诉供应商他们在制定提案时是否必须使用此信息。


关键词或常用术语查找手册。