Quy trình chọn nhà cung cấp: từ RFI đến hợp đồng thử nghiệm
Sáu tuần của một quy trình chọn nhà cung cấp phần mềm: hồ sơ nào dùng ở bước nào, ai viết, ai chấm, biên bản hỏi đáp để làm gì, và hợp đồng thử nghiệm cần ghi gì để có kết luận.

Mục lục bài viết
Trả lời nhanh
Quy trình chọn nhà cung cấp phần mềm theo sáu tuần: phân biệt RFI, RFP và RFQ, thứ tự hồ sơ, vai trò hội đồng, biên bản hỏi đáp và điều kiện hợp đồng thử.
Quy trình chọn nhà cung cấp phần mềm chạy theo sáu tuần: xác định nhu cầu, gửi RFI để lọc danh sách, gửi RFP cho ba ứng viên, chấm điểm và phỏng vấn kỹ thuật, đàm phán trên cùng phạm vi, rồi ký hợp đồng thử nghiệm có sản phẩm bàn giao rõ ràng.
Tóm tắt nhanh
- RFI, RFP và RFQ không phải ba tên gọi của cùng một việc. RFI để lọc danh sách, RFP để so sánh phương án, RFQ chỉ dùng khi phạm vi đã cố định và chỉ còn thiếu giá.
- Giá trị của quy trình nằm ở thứ tự: gửi sai hồ sơ ở tuần đầu khiến ba tuần sau chỉ còn là đàm phán giá với những bên không phù hợp.
- Biên bản hỏi đáp là hồ sơ bị bỏ qua nhiều nhất, và cũng là hồ sơ ngăn tranh chấp hiệu quả nhất. Mọi câu hỏi và câu trả lời phải được gửi cho tất cả ứng viên như nhau.
- Hợp đồng thử nghiệm không phải bản hợp đồng chính thu nhỏ. Nó là một giai đoạn có sản phẩm bàn giao riêng và có điều kiện chuyển tiếp viết trước.
Ba loại hồ sơ và việc chúng thực sự giải quyết
Ba chữ viết tắt này hay bị dùng lẫn, và việc dùng lẫn gây ra một hệ quả cụ thể: bạn nhận được những bản trả lời không so sánh được với nhau.
RFI — Request for Information. Mục đích là mở rộng hiểu biết, không phải mua. Bạn gửi một bản mô tả ngắn về bài toán và hỏi thị trường có những cách giải nào. RFI dùng khi bạn chưa biết nên mua sản phẩm đóng gói, thuê phát triển riêng, hay tích hợp từ các hệ thống có sẵn. Đầu ra của RFI là một danh sách rút gọn, không phải một bản báo giá.
RFP — Request for Proposal. Mục đích là so sánh phương án. Bạn gửi phạm vi sơ bộ, yêu cầu phi chức năng có ngưỡng, và yêu cầu mỗi bên trả lời theo cùng một cấu trúc: cách hiểu bài toán, kiến trúc đề xuất, phân rã công việc theo giai đoạn, giả định và rủi ro, chi phí theo giai đoạn. Đầu ra của RFP là các bản phương án có thể chấm điểm.
RFQ — Request for Quotation. Mục đích là lấy giá khi phạm vi đã cố định. RFQ chỉ có nghĩa khi bạn đã có đặc tả đủ chi tiết để hai nhà cung cấp hiểu giống nhau. Gửi RFQ quá sớm là cách nhanh nhất để nhận những con số không so sánh được, vì mỗi bên tự điền phần rìa theo cách riêng.
| Hồ sơ | Câu hỏi nó trả lời | Khi nào dùng | Đầu ra | Sai lầm thường gặp |
|---|---|---|---|---|
| RFI | Thị trường có những cách giải nào? | Trước khi biết nên mua gì | Danh sách rút gọn ba đến năm bên | Biến RFI thành cuộc thi báo giá |
| RFP | Phương án nào phù hợp nhất? | Khi đã có phạm vi sơ bộ | Bản phương án chấm điểm được | Mỗi bên trả lời một cấu trúc khác nhau |
| RFQ | Giá của phạm vi đã cố định là bao nhiêu? | Khi đặc tả đã chốt | Báo giá so sánh được | Gửi RFQ khi phạm vi còn mơ hồ |
| Hợp đồng thử | Đội này có giao hàng được không? | Sau khi chọn được một đến hai bên | Sản phẩm chạy được trên phạm vi nhỏ | Không có sản phẩm bàn giao, chỉ có báo cáo |
Bảng này là toàn bộ logic của quy trình. Nếu bạn chỉ nhớ một dòng, nhớ dòng RFQ: gửi RFQ khi phạm vi còn mơ hồ sẽ tạo ra một cuộc đàm phán giá giả tạo, trong đó bên trả lời thấp nhất thường là bên hiểu phạm vi hẹp nhất.
Sáu tuần của quy trình
Lịch dưới đây là mốc tham chiếu cho một dự án cỡ vừa. Dự án nhỏ có thể nén còn ba tuần; dự án lớn có thể kéo dài, nhưng tỷ lệ giữa các bước nên giữ nguyên.
| Tuần | Hoạt động | Hồ sơ tạo ra | Người chịu trách nhiệm |
|---|---|---|---|
| Tuần 1 | Chốt bài toán, phạm vi sơ bộ, ngưỡng ngân sách | Bản mô tả bài toán một trang | Người chủ dự án |
| Tuần 2 | Gửi RFI, nhận phản hồi, lọc danh sách | Danh sách rút gọn kèm lý do loại | Người chủ dự án |
| Tuần 3 | Gửi RFP, mở kênh hỏi đáp | RFP và biên bản hỏi đáp | Người phân tích nghiệp vụ |
| Tuần 4 | Nhận phương án, chấm điểm độc lập | Bảng điểm có bằng chứng | Hội đồng ba người |
| Tuần 5 | Phỏng vấn kỹ thuật, kiểm tra bằng chứng | Biên bản phỏng vấn | Người phụ trách kỹ thuật |
| Tuần 6 | Đàm phán, ký hợp đồng thử nghiệm | Hợp đồng thử và kế hoạch đánh giá | Người chủ dự án và pháp chế |
Hai tuần đầu là phần bị cắt nhiều nhất khi có áp lực tiến độ, và cũng là phần quyết định chất lượng của bốn tuần sau. Nếu tuần 1 và tuần 2 bị nén thành hai ngày, tuần 4 sẽ chỉ còn là so sánh cảm tính giữa những bản phương án trả lời hai bài toán khác nhau.
Tuần 1 — Viết bản mô tả bài toán trước khi mở hồ sơ
Bản mô tả bài toán là hồ sơ duy nhất bạn viết một mình. Nó gồm bốn phần: hiện trạng bằng dữ kiện, trạng thái mong muốn bằng dữ kiện, phạm vi sơ bộ kèm mục "không bao gồm", và các ràng buộc đã biết như hạn chế hạ tầng, yêu cầu tích hợp, hoặc mốc thời gian không thể dịch.
Điều quan trọng là bản này phải viết xong trước khi bạn nói chuyện với nhà cung cấp đầu tiên. Viết sau khi đã nghe ba bên tư vấn, bản mô tả sẽ phản ánh từ vựng của bên nói chuyện với bạn nhiều nhất, và bạn mất khả năng so sánh độc lập.
Tuần 2 — Dùng RFI để lọc, không để chấm điểm
RFI nên ngắn. Ba câu hỏi là đủ: bài toán này thường được giải bằng cách nào, cách giải đó phù hợp và không phù hợp với loại tổ chức nào, và để đánh giá năng lực thì nên xin bằng chứng gì.
Câu hỏi thứ ba có tác dụng phụ đáng giá: nó cho bạn biết bên nào hiểu việc đánh giá là một phần của nghề. Bên trả lời "cứ tin chúng tôi" và bên trả lời "nên xin ba tài liệu sau" khác nhau về năng lực tự đánh giá, và sự khác biệt đó dự báo được cách họ xử lý vấn đề trong dự án.
Lọc danh sách xuống ba bên. Hai bên thường dẫn tới so sánh nhị phân; bốn bên trở lên làm việc chấm điểm nặng hơn giá trị nó mang lại.
Tuần 3 — RFP với cấu trúc trả lời cố định
Điểm quyết định của RFP là cấu trúc trả lời. Nếu mỗi bên tự chọn cách trình bày, bạn sẽ phải đọc ba tài liệu có ba logic khác nhau và không thể chấm điểm theo cùng tiêu chí.
Cấu trúc tối thiểu gồm năm phần, theo đúng thứ tự:
- Cách hiểu bài toán — nửa trang. Đây là phần dự báo tốt nhất về chất lượng của cả dự án.
- Kiến trúc và công nghệ đề xuất — kèm lý do chọn và lý do không chọn phương án thay thế.
- Phân rã công việc theo giai đoạn — mỗi giai đoạn có sản phẩm bàn giao và tiêu chí nghiệm thu.
- Giả định và phụ thuộc — những gì bên đó giả định là đúng, và điều gì xảy ra nếu giả định sai.
- Chi phí theo giai đoạn — không phải một con số tổng.
Phần 4 là phần phân biệt nhà cung cấp trưởng thành với nhà cung cấp chưa từng làm dự án khó. Một bản phương án không có giả định nào nghĩa là các giả định đang ẩn, và chúng sẽ hiện ra dưới dạng phát sinh chi phí ở tháng thứ tư.
Tuần 4 — Chấm điểm độc lập, họp sau
Hội đồng ba người chấm độc lập trước khi họp. Mỗi người ghi bằng chứng cho điểm mình cho. Khi họp, thứ tự trình bày nên là người ít kinh nghiệm nhất nói trước, để tránh hiệu ứng neo từ người có thâm niên.
Bộ tiêu chí và trọng số dùng ở bước này được trình bày trong chọn nhà cung cấp, cùng với neo điểm cho từng mức. Điểm quan trọng ở đây là tính kỷ luật: chấm trước, họp sau, ghi bằng chứng, không lấy trung bình để che chỗ lệch.
Tuần 5 — Phỏng vấn kỹ thuật và kiểm tra bằng chứng
Buổi phỏng vấn kỹ thuật không phải buổi thuyết trình thứ hai. Nó là buổi kiểm tra bằng chứng cho những điểm đã cho. Ba việc cần làm trong buổi này:
- Yêu cầu bên đó mở một tài liệu thật và giải thích nó, thay vì trình bày slide.
- Đặt một tình huống thay đổi phạm vi cụ thể và yêu cầu mô tả các bước xử lý.
- Hỏi về một dự án đã gặp vấn đề, và điều gì đã được thay đổi sau đó.
Việc thứ ba quan trọng nhất. Một đội kể được một câu chuyện thất bại có đầu có cuối là đội đã có quy trình rút kinh nghiệm. Một đội nói chưa từng gặp vấn đề là đội chưa từng làm dự án đủ khó, hoặc đang không trung thực.
Tuần 6 — Đàm phán trên cùng phạm vi, rồi ký hợp đồng thử
Trước khi đàm phán, đưa mọi báo giá về cùng một phạm vi. Bước này thường làm thay đổi thứ hạng: bên báo cao có thể đã bao gồm tài liệu, kiểm thử và bàn giao, trong khi bên báo thấp để những phần đó ngoài phạm vi.
Hợp đồng thử nghiệm cần bốn điều khoản: phạm vi giai đoạn thử, sản phẩm bàn giao của giai đoạn thử, tiêu chí đánh giá kết quả thử, và điều kiện chuyển sang hợp đồng chính. Thiếu điều khoản thứ tư, giai đoạn thử trở thành một dự án nhỏ không có kết luận, và bạn quay lại điểm xuất phát với ít ngân sách hơn.
Biên bản hỏi đáp: hồ sơ bị bỏ qua nhiều nhất
Trong mọi quy trình mua sắm có nhiều ứng viên, câu hỏi sẽ xuất hiện. Cách xử lý câu hỏi quyết định quy trình có công bằng hay không.
Nguyên tắc duy nhất: mọi câu hỏi và câu trả lời được gửi cho tất cả ứng viên, không nêu tên bên hỏi. Không có ngoại lệ. Nếu một bên được trả lời riêng, bên đó đang có lợi thế thông tin, và mọi so sánh sau đó mất giá trị.
Biên bản hỏi đáp có ba tác dụng:
- Công bằng. Tất cả ứng viên nhận cùng một tập thông tin, nên khác biệt trong bản phương án là khác biệt về năng lực.
- Truy vết. Khi có tranh chấp về phạm vi sau này, biên bản là bằng chứng về những gì đã được làm rõ trước khi ký.
- Chất lượng yêu cầu. Câu hỏi của các ứng viên thường chỉ ra chỗ mơ hồ trong chính yêu cầu của bạn. Những chỗ đó nên được sửa trong đặc tả, không chỉ được trả lời trong biên bản.
Một biên bản tốt có ba cột: câu hỏi, câu trả lời, và thay đổi tương ứng trong hồ sơ yêu cầu (nếu có). Cột thứ ba là cột hay bị bỏ, và nó là cột biến biên bản từ một tài liệu đối phó thành một công cụ cải thiện đặc tả.
Vai trò trong hội đồng và xung đột lợi ích
Ba vai trò tối thiểu, và mỗi vai trò có một thiên lệch cần được cân bằng.
| Vai trò | Quan tâm chính | Thiên lệch thường gặp | Cách cân bằng |
|---|---|---|---|
| Người chủ dự án | Tiến độ và kết quả nghiệp vụ | Ưu tiên bên cam kết tiến độ nhanh | Buộc mọi cam kết tiến độ phải kèm giả định |
| Người phụ trách kỹ thuật | Khả năng bảo trì và rủi ro kỹ thuật | Ưu tiên công nghệ quen thuộc với mình | Yêu cầu giải thích lý do chọn, không chỉ tên công nghệ |
| Người chịu trách nhiệm ngân sách | Chi phí tổng và dòng tiền | Ưu tiên báo giá thấp nhất | Đưa chi phí ba năm vào bảng so sánh |
| Người dùng đại diện | Tính dùng được hằng ngày | Ít tham gia, dễ bị bỏ qua | Bắt buộc có mặt ở buổi phỏng vấn kỹ thuật |
Thiên lệch không phải vấn đề đạo đức; nó là hệ quả tự nhiên của việc mỗi người chịu một loại trách nhiệm khác nhau. Vấn đề chỉ xuất hiện khi một thiên lệch không được đối trọng.
Về xung đột lợi ích, cần một quy tắc đơn giản và viết ra: người tham gia chấm điểm phải khai báo quan hệ cá nhân hoặc lợi ích tài chính với bất kỳ ứng viên nào. Khai báo không có nghĩa là bị loại khỏi hội đồng, nhưng nó phải được ghi vào biên bản.
Bộ hồ sơ nên có sau khi kết thúc
Một quy trình chọn nhà cung cấp kết thúc không phải bằng hợp đồng, mà bằng một bộ hồ sơ đủ để người khác hiểu vì sao quyết định đó được đưa ra. Bộ hồ sơ này có giá trị hai lần: khi dự án gặp vấn đề, và khi tổ chức mua sắm lần sau.
| Hồ sơ | Nội dung tối thiểu | Ai giữ |
|---|---|---|
| Bản mô tả bài toán | Hiện trạng, mong muốn, phạm vi, ràng buộc | Người chủ dự án |
| Danh sách rút gọn | Các bên được mời và lý do loại | Người chủ dự án |
| RFP và biên bản hỏi đáp | Yêu cầu gốc và mọi làm rõ | Người phân tích nghiệp vụ |
| Bảng điểm có bằng chứng | Điểm từng tiêu chí và bằng chứng kèm theo | Hội đồng |
| Biên bản phỏng vấn | Câu hỏi, câu trả lời, nhận xét | Người phụ trách kỹ thuật |
| Biên bản quyết định | Bên được chọn, lý do, điểm số | Người chủ dự án |
| Hợp đồng thử | Phạm vi, sản phẩm bàn giao, điều kiện chuyển tiếp | Pháp chế và người chủ dự án |
Bảng điểm có bằng chứng là hồ sơ quan trọng nhất và cũng là hồ sơ hay bị thay bằng một bản tóm tắt. Một bản tóm tắt chỉ có điểm số không giữ được lý do, và lý do mới là thứ giúp lần mua sắm sau tốt hơn.
Năm lỗi làm hỏng quy trình
- Mời quá nhiều bên. Mỗi bên thêm vào làm tăng khối lượng đọc và giảm độ sâu của mỗi lần đánh giá. Ba bên là điểm cân bằng.
- Gửi yêu cầu khác nhau cho từng bên. Khác biệt nhỏ trong bản yêu cầu tạo ra khác biệt lớn trong bản phương án, và bạn không còn so sánh được.
- Đàm phán trước khi chấm điểm. Đàm phán sớm biến cuộc trao đổi thành thương lượng giá và làm mất thông tin về năng lực.
- Không ghi lại lý do loại. Lý do loại là dữ liệu cho lần sau. Không có nó, tổ chức mua sắm lại từ đầu mỗi lần.
- Bỏ giai đoạn thử vì tiến độ. Giai đoạn thử là cách rẻ nhất để phát hiện vấn đề trước khi nó nằm trong hợp đồng lớn. Bỏ nó là chuyển rủi ro sang tháng thứ tư.
Cách đánh giá từng tiêu chí một cách định lượng được trình bày trong đánh giá nhà cung cấp. Cách phân biệt ba loại hình nhà cung cấp trước khi mời thầu được trình bày trong nhà cung cấp phần mềm là gì. Và các giai đoạn mà hợp đồng thử sẽ dựa vào được trình bày trong quy trình phát triển phần mềm là gì.
Câu hỏi thường gặp
Quy trình chọn nhà cung cấp mất bao lâu?
Với dự án cỡ vừa, khoảng sáu tuần từ lúc chốt bài toán đến khi ký hợp đồng thử. Dự án nhỏ có thể nén còn ba tuần nếu bỏ RFI và chỉ gửi RFP cho hai bên. Dự án lớn hơn thường mất tám đến mười hai tuần vì cần thêm thời gian đánh giá bảo mật và pháp chế. Điều không nên nén là tuần viết bài toán và tuần phỏng vấn kỹ thuật.
Có bắt buộc phải có RFI không?
Không bắt buộc. RFI cần khi bạn chưa biết thị trường có những cách giải nào, hoặc khi bài toán có thể giải bằng sản phẩm đóng gói thay vì phát triển riêng. Nếu bạn đã biết rõ cần phát triển riêng và đã có danh sách ba nhà cung cấp phù hợp, bỏ RFI và đi thẳng vào RFP là hợp lý.
Nên gửi RFP cho bao nhiêu nhà cung cấp?
Ba là số hợp lý cho hầu hết trường hợp. Hai bên thường dẫn tới so sánh nhị phân và bỏ qua việc đối chiếu với tiêu chí. Bốn bên trở lên chỉ nên dùng khi có người chấm điểm chuyên trách và phạm vi đủ lớn để khác biệt giữa các bên có ý nghĩa.
Hợp đồng thử nghiệm khác hợp đồng chính ở điểm nào?
Hợp đồng thử có phạm vi hẹp, thời hạn ngắn và một sản phẩm bàn giao kiểm chứng được, thường là một giai đoạn khám phá và đặc tả hoặc một nhát cắt dọc chạy được trên dữ liệu thật. Điều khác biệt quan trọng nhất là hợp đồng thử phải ghi rõ điều kiện chuyển sang hợp đồng chính, để kết thúc giai đoạn thử luôn có một kết luận thay vì một khoảng trống.
Cập nhật và kiểm chứng
Cập nhật tháng 10/2026. Nội dung phản ánh quy trình bốn chặng WinSell áp dụng — Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — và được rà soát theo thông lệ mua sắm phần mềm đang áp dụng. Bài viết không nêu giá dịch vụ và không sử dụng số liệu khách hàng của bất kỳ bên nào.
Nếu bạn đang chuẩn bị hồ sơ mời thầu và muốn một bên trả lời theo đúng cấu trúc RFP mô tả ở trên, xem dịch vụ xây dựng phần mềm theo yêu cầu của WinSell. Báo giá sau khi chốt phạm vi.
Cần một hệ thống chạy được, không chỉ một bài viết?
WinSell xây phần mềm theo yêu cầu và làm SEO/GEO cho chính sản phẩm đó. Phạm vi và báo giá được chốt sau bước khám phá.


