软件开发供应商招标RFP清单：需求、评分与合同条款

软件开发招标清单（RFP）应在供应商回复之前写清问题、功能与非功能需求、安全与数据要求、商业条款和评分办法：按加权标准打分而不是事后争论，核查推荐人而不是相信案例研究，签任何预算合同之前先做一个短的付费试点。

软件开发RFP应包含哪些内容？

这份文档的作用，是让回答可以比较。供应商只能回应你写下来的东西；一份只描述愿景、再问个价的RFP，会招来一堆听起来都很棒、却彼此无法对照的方案。功能内容、限制条件和评分规则必须在第一份回复到达之前定死，否则评审就会变成一场关于标准的谈判。

还有一个能省下几个月的次序问题：RFP不是你发现自己需要什么的地方。需求来自内部工作——流程负责人描述业务实际怎么跑、财务说明什么必须对得上、每天用系统的人指出现在的痛点在哪。这项工作慢，而且牵涉内部立场，发生在任何供应商参与之前。把它外包给第一个上门的团队，最后拿到的是用那家供应商的产品语言写成的需求，于是其他每一份方案看起来都不合适——不是因为真的不合适，而是基准围着其中一个投标人写的。

还有一组常被混淆的区分，涉及三份文件。RFI是问市场有什么：篇幅短，排在需求之前，不约束任何人。RFP是针对已定义的需求和已公布的评审办法征求方案。RFQ是在明确范围的基础上问价格。范围还不存在就先发RFQ，是最常见的把三个含义完全不同的数字摆在一起比较的方式。

一份完整的RFP能做到、而残缺版做不到的五件事：

• 定义问题，而不是方案。 “把月度合并报表的编制时间从几天缩短到约定的若干小时”是问题陈述；“给我们建一个数据仓库”只是方案猜测，可能根本解决不了问题。


• 把需求和偏好分开。 决定通过与否的硬性项、决定排名的优先项，以及不决定任何事情的锦上添花项。只有这个区分清楚，供应商才会认真回应。


• 写明限制条件。 必须集成的既有系统、必须迁移的数据、审计与保存义务、上线窗口、由谁签字批准。


• 事先公布评审办法。 加权标准、谁来评审、需要什么证据，以及落选供应商何时收到自己的得分摘要。


• 设定流程日期。 提问截止、澄清窗口、提交截止、评审周期、决策日期。没有日期的流程，吸引来的是本来就忙的供应商。

RFP文档结构模板

功能性与非功能性需求

功能性需求描述系统做什么：哪些流程、面向哪些角色、产出什么。非功能性需求描述它做得怎么样，而这一类最常被遗漏——然后在后面被昂贵地强制执行，或者干脆没有执行。

多数B2B项目值得明确写出来的：

• 性能。 给定负载下的响应时间，针对真正要紧的操作：订单录入、报表生成、月末结账。


• 可用性。 业务需要多高的可用率、维护窗口，以及系统宕掉时怎么办——只有目标数字而没有可接受停机时间的描述，算不上需求。


• 恢复能力。 用大白话写清RTO和RPO：故障后业务多久恢复、最多可以丢多少工作量。这两个数字要进评审，而不只是写进合同。


• 审计追踪。 谁在何时改了什么、保留多久、谁能调阅——凡是资金、库存或个人数据流转的地方尤其如此。


• 无障碍与易用性。 谁在用、用什么设备、用什么语言；仓库操作不了的系统，评分再高也没有落地。


• 集成与数据。 哪些系统对接、数据朝哪个方向流、每个实体的主记录由谁负责。

安全与合规问询清单

安全最好用“必须附证据的问题”来问，而不是一个是或否的勾选项。值得写进去的有：

• ISO/IEC 27001 —— 供应商是否持有认证，认证范围覆盖到哪里？只覆盖销售组织、不覆盖交付团队的证书，说明的问题很具体。


• 安全开发 —— 安全在设计、代码评审和测试中处于什么位置；依赖组件和漏洞处理是否已是例行工作。


• OWASP Top 10 —— 面向网页的组件是否纳入供应商的检查清单；这是一个具体、可以回答的问题。


• 访问控制 —— 谁能接触你的环境和数据、权限如何授予与回收、有哪些日志。


• 数据保护义务 —— 适用时的KVKK与GDPR；谁是控制者、谁是处理者，数据处理协议对分包处理者和泄露通知写了什么。

商业条款与SLA

要求供应商按你能比较的结构报价：包含什么、单独计费什么、变更如何计价。一个背后没有范围的单一数字，无法与另一个单一数字比较；成本与定价模式页面解释了常见结构，以及每种结构引出的问题。

SLA需要与需求同等的精度。可用率百分比只有配上测量方法、排除项和补救措施才有意义；响应时间只有配上严重等级定义和工作时段才有意义。要求每家供应商在SLA内部定义这些术语，而不是接受一页没有定义的百分比。

软件开发供应商评分矩阵

一份可直接套用的模板。下面的权重只是示例——按你自己的优先级设定，合计保持100。在任何人打分之前，先把1分、3分、5分的含义定下来，而不是等争论开始之后。

两条纪律让这张表真正起作用。先独立打分、再讨论，这样第一个自信的声音不会定下调子。每个分数记一行理由——收到带原因的得分摘要，供应商接受结果的程度会高得多，而你自己的团队半年后也解释得清楚。

第三条纪律是“谁来打分”。评审组应当包括将与这个结果共事的人——流程负责人、对数据负责的人，以及设有安全或财务职能时的相关人员——而不只是采购。评审组只给自己能判断的东西打分（方案的结构、销售团队的顺滑），把不能判断的（集成方案是否真的适配现有系统）推迟出去，评审就会悄无声息地失败。一个有权说“这套东西和我们现有的系统跑不到一起”的技术人员，省下的成本超过任何折扣。

权重本身也值得再提醒一次：它是一份对供应商可见的优先级声明。如果安全占5%、价格占30%，认真的安全型供应商会注意到，你的团队在签合同时也会注意到。为了填表而匆忙定下的权重，在会议室之外的人眼里就是真理；定一次就要由决策者在场定，改动也走同样正式的程序。

推荐人核查与付费试点

案例研究是营销，推荐人核查是证据。有效的通话很短，问发生过什么，而不是交付了什么：项目收尾了吗、范围改过什么、实际上是谁在团队里、如果重来会怎么做、还会不会与这家供应商再合作一次。过去时和具体回答才是信号。

要求提供一个在规模和复杂度上与你相近的项目推荐人，而不是供应商最得意的作品——一个预算两倍于你的旗舰实施，学不到“你的规模下团队如何行事”。而且要自己去核实：供应商提前打过招呼的联系人是证言，不是推荐人；有用的通话是客户当场才知道你在问什么的那种。

接着做一个短的付费试点，它检验的是任何推荐人都无法回答的部分：当需求并不完整时，这个团队和你的人怎么共事。试点设计的规则同样值得事先定好：真实工作、书面验收标准、中途改一次需求、事先约定的决策规则。IT外包页面对试点设计有更详细的讨论。

必须核对的合同条款

• 知识产权转让 —— 代码、文档及其衍生物的权利自创造之时起转归你，而不只是在尾款付清时。
• 数据所有权 —— 数据始终是你的；供应商的权利仅限于交付所需。
• 验收 —— 验收的含义、由谁宣布，以及未通过时的处理流程。
• 变更控制 —— 范围变更如何提出、计价、批准；没有它，每一次变更都会变成争议。
• 退出与移交 —— 结束时的源代码、权限、文档和协助；供应商更换时知识如何转移。
• 代码托管 —— 当业务连续性依赖供应商持有的组件时，供应商无法继续运营怎么办。
• 责任限制 —— 上限、除外事项以及哪些没有投保；读它要和读价格一样仔细。
• 终止 —— 通知期、终止后的义务，以及数据返还或删除流程。

常见问题解答

该先发RFI还是RFP？

市场不清楚或问题还没成形时用RFI——你问的是有什么、多少钱。需求和评审办法已经定义好时用RFP；发得太早，只会把需求梳理的工作搬进每家供应商的方案里，用他们的用词和他们的优先级。

应该邀请几家供应商？

少到你能认真读完每一份方案、打完每一个推荐人电话。多数评审超过一小撮就开始掉质量；由一份RFI、一次筛查通话和一个同类参考项目建起来的候选名单，通常比一长串知名名字更有用。

权重怎么定？

从你的优先级出发，在看到任何方案之前定，并由将与结果共事的人共同认可。常见的失败是所有项等权，那等于说什么都不比别的更重要；如果价格或风险对你占主导，权重就该说出来。

价格要不要打分？

要，但作为其中一个加权项，且范围先固定，而不是让价格决定整个评审。背后没有范围的价格分，奖励的是假设工作量最少的供应商；先给需求定价，再就同一件东西比较总价。

安全回答怎么打分？

看证据，不看语气。三档就够：没有立场（1）、制度有描述（3）、认证范围已核实且安全开发有描述并提供证据（5）。供应商没有证书时，问有哪些等效的书面控制——带文档控制的诚实“没有”，好过无法核实的“有”。

RFP发出后还能改需求吗？

提交之前可以——但要把变更告知所有人。提交之后，只能通过所有投标人都收到的正式澄清来改；悄悄为一家供应商改需求，会毁掉整个流程赖以成立的可比性。合同之后，那就是变更控制存在的意义。

来源与标准

• ISO —— ISO/IEC 27001（信息安全管理）的发布机构；依赖之前请确认现行版本和证书覆盖范围。
• OWASP —— 本页引用的Top 10网页应用安全风险清单的发布机构。
• 评分矩阵的原则来自公开的RFP模板实践；表中权重是供修改的示例，不是推荐。本页是采购指引，不是法律建议，WorldwideTradeX 不主张任何认证或审计资质。

相关页面

软件开发 · 土耳其IT外包 · 成本与定价模式 · IT审计与咨询 · 索取报价