📡 第七章 网络硬件设备的选购要点
📄 一句话概括

RFI 问「市面上有什么」,RFP 问「谁能按我的需求做、怎么做」。 跳过 RFI 直接发 RFP,最常见的后果是:需求里写的参数,市场上根本没人做。

📝 本节和前面几节的关系

07.02 写的是「我要什么」,这一节讲「怎么把这份需求发出去、怎么收回来」。 RFI 与 RFP 是两道不同的闸门:一道收窄「可能性」,一道收窄「承诺」。

一、三份文件的分工

采购流程里其实有三份文件,很多人只记得 RFP:

文件 回答什么问题 谁写给谁 时机


RFI 市面上有什么、大致什么水平 买方问多家 最前 RFP 谁能按我的需求做、怎么做 买方问多家 中间 RFQ 具体这批货多少钱 买方问选定者 最后

三份文件的差别在「约束的紧密度」:RFI 最松(只要方向)、RFP 最重(要方案与承诺)、 RFQ 最硬(型号、数量、交期、价格)。

所以顺序不能颠倒: 先知道「有哪些可能」,才能写「要求哪个」;先知道「谁能做」,才谈得上「多少钱」。

二、RFI 该问什么

RFI 的目的只有两个:摸清市场,收窄范围。 所以它不该问价格,也不该要求详细方案。

一份 RFI 通常包含:大致规模与场景、关键功能点、期望的部署形态、时间窗口。 然后请对方回答「你能覆盖哪些、你的典型客户是谁、有哪些做不到」。

「有哪些做不到」这一问最有价值: 愿意说「这个我们做不了」的厂商,比全答「可以」的厂商可靠得多。

三、RFP 该写什么

RFP 是「要件」,它要能当合同附件用。 所以它至少包含五块: 需求清单(带必选与可选的标记)、验收标准、交付时间表、服务与响应要求、报价要求。

「验收标准」是 RFP 里最容易被写虚的一块: 「系统运行稳定」不是标准,「连续 30 天无 P1 故障」才是。 写不出验收标准,说明需求还没想清。

常见错误是「跳过 RFI 直接发 RFP」: 比如写「48 口万兆 PoE++,整机功耗小于 100 瓦」——这两条本身就冲突。 结果收到的全是「无法满足」,白花三周。

四、时间线怎么排

按周排一遍,才知道这件事要占多少人力:

阶段 周数 并行


需求梳理 2 周 — RFI 3 周 可与需求梳理部分重叠 RFP 4 周 — 评标与澄清 2 周 — RFQ 与合同 2 周 —

串行合计 13 周;需求梳理与 RFI 并行能压到 11 周左右。

这张表还有一个用处:它让「为什么这么慢」变得可解释。 跳过前面两步省下的三周,会在「评标时发现没人做得了」时加倍还回来。

五、动手 Demo:RFI、RFP、RFQ,三份文件什么时候用

这段把三份文件的分工与关键差别列出来,再排一遍按周的时间线,看「跳过 RFI」到底省不省时间。

rows = [
    (u"RFI", u"市面上有什么、大致什么水平", u"买方问多家", u"最前"),
    (u"RFP", u"谁能按我的需求做、怎么做", u"买方问多家", u"中间"),
    (u"RFQ", u"具体这批货多少钱", u"买方问选定者", u"最后"),
]
for a, b, c, d in rows:
    T([a, b, c, d], [0, 0, 0, 0])

实跑输出:

--------------------------------------------------------------------
RFI、RFP、RFQ,三份文件什么时候用
--------------------------------------------------------------------
**选型不是「找三家比价」这么简单。**
**在比价之前,得先搞清楚「市场上有哪些东西能满足我」。**

  文件     回答什么问题                   谁写给谁         时机
  -----------------------------------------------------------------
  RFI      市面上有什么、大致什么水平     买方问多家       最前
  RFP      谁能按我的需求做、怎么做       买方问多家       中间
  RFQ      具体这批货多少钱               买方问选定者     最后

**三份文件的差别在「约束的紧密度」**:
  RFI 最松:只要方向,不要方案细节,目的是「知道有哪些可能」。
  RFP 最重:需求、验收标准、时间表都写清,对方要给方案与承诺。
  RFQ 最硬:型号、数量、交期、价格,基本是商务动作。

**一个常见错误是「跳过 RFI 直接发 RFP」**,**后果是需求里写的参数,市场上根本没人做。**
  比如写「48 口万兆 PoE++,整机功耗小于 100 瓦」——这两条本身就冲突。
  发出去之后收到的回复全是「无法满足」,白花三周。

**按周排一遍时间线**:

  阶段           周数     并行
  ------------------------------------------------
  需求梳理       2 周     —
  RFI            3 周     可与需求梳理部分重叠
  RFP            4 周     —
  评标与澄清     2 周     —
  RFQ 与合同     2 周     —

**合计 13 周,中间没有重叠的话。**
**而实际上需求梳理与 RFI 可以并行,能压到 11 周左右。**

**这条 Demo 真正想说的是**:
  这三份文件不是流程装饰,它们把「我不知道要什么」逐步收敛成「我知道买什么」。
  跳过前面两步,省下的时间会在「评标时发现没人做得了」时加倍还回来。

三份文件不是流程装饰:它们把「我不知道要什么」逐步收敛成「我知道买什么」。

注意 RFI 与 RFP 的答题人不同:RFI 可以由销售答,RFP 必须由售前工程师答。 如果一场 RFP 答疑里坐的全是销售,这份 RFP 大概收不到有用的答案。

最后一句:这套流程的价值不在「合规」,在「让需求在写代码之前就暴露矛盾」。 「48 口万兆 PoE++ 且整机 100 瓦」这种矛盾,早发现只花一天,晚发现要改方案。

30 秒实验

  1. 翻一份你见过的招标文件,找找它有没有「验收标准」这一节。
  2. 把「系统运行稳定」改写成一条可验收的标准。
  3. 想一想:为什么 RFI 阶段不该问价格?

常见误区

  1. 以为 RFP 就是报价单。RFP 要方案与承诺,价格是 RFQ 才谈的。
  2. 以为跳过 RFI 能省时间。省下的三周会在评标阶段加倍还回来。
  3. 以为验收标准可以写虚。写不出可验收的标准,说明需求还没想清。
自测三问(点开对答案) 1. RFI、RFP、RFQ 各自回答什么问题? —— RFI 问市面上有什么,RFP 问谁能做、怎么做,RFQ 问这批货多少钱。 2. RFI 里最有价值的一个问题是什么? —— 「有哪些做不到」——愿意说做不了的厂商比全答可以的更可靠。 3. 为什么 RFP 的验收标准不能写虚? —— 它是合同附件,写虚了既无法验收也无法追责,等于没写。

下一节:选定厂商之后,怎么比价——RFQ 与到岸总价。

相关笔记