RFP (Request for Proposal) phần mềm là hồ sơ doanh nghiệp gửi cho nhiều nhà cung cấp để mời họ đề xuất giải pháp, cách triển khai và giá cho một nhu cầu phần mềm cụ thể. Khác với một lời nhờ báo giá qua điện thoại, RFP buộc mọi bên trả lời trên cùng một khung: cùng phạm vi, cùng giả định, cùng mẫu bảng giá, cùng tiêu chí chấm. Nhờ vậy, bên mua đặt các hồ sơ cạnh nhau mà so được, thay vì so một báo giá 300 triệu đồng "đã gồm mọi thứ" với một báo giá 900 triệu đồng thật ra gồm cả chuyển đổi dữ liệu, đào tạo và ba năm bảo trì.
Một RFP tốt thường có chín phần: bối cảnh doanh nghiệp, mục tiêu kinh doanh, phạm vi, yêu cầu chức năng, yêu cầu phi chức năng, yêu cầu tích hợp và dữ liệu, yêu cầu về đội dự án và cách làm việc, mẫu bảng giá, cùng tiêu chí và lịch đánh giá. Phần dưới đây đi qua từng phần, cách phân biệt RFP với RFI và RFQ, cách viết sao cho nhà cung cấp giỏi muốn trả lời, và những lỗi khiến cả quy trình mất hai tháng mà vẫn không chọn được ai.
RFI, RFQ và RFP khác nhau thế nào
Ba loại hồ sơ này thường bị dùng lẫn. Thực ra chúng phục vụ ba giai đoạn khác nhau của cùng một quá trình mua sắm, và chọn sai loại là nguyên nhân phổ biến nhất của báo giá không so được.
| Loại hồ sơ | Mục đích | Khi nào dùng | Đầu ra mong đợi |
|---|---|---|---|
| RFI – yêu cầu thông tin | Tìm hiểu thị trường có những giải pháp, cách tiếp cận nào | Khi bạn chưa rõ nên mua gói có sẵn hay đặt làm, chưa biết giới hạn khả thi | Danh sách nhà cung cấp tiềm năng, khoảng giá thô, các phương án kiến trúc |
| RFQ – yêu cầu báo giá | So giá cho một thứ đã định nghĩa rõ | Khi hàng hoá chuẩn hoá: bản quyền phần mềm, thiết bị, gói dịch vụ có đặc tả cố định | Bảng giá theo đơn vị, điều kiện giao hàng và thanh toán |
| RFP – yêu cầu đề xuất | Mời đề xuất giải pháp cho một bài toán có nhiều cách giải | Khi cần nhà cung cấp tư vấn cách làm, ước lượng công sức, chịu một phần rủi ro thiết kế | Giải pháp, kế hoạch, đội dự án, giá theo cấu trúc định sẵn |
Quy trình hợp lý với dự án vừa và lớn là RFI trước, rút gọn danh sách còn ba đến năm nhà cung cấp, rồi mới phát RFP. Gửi RFP cho mười lăm công ty là tự làm khó mình: không ai đủ thời gian đọc kỹ mười lăm hồ sơ dày, còn nhà cung cấp giỏi thấy tỷ lệ thắng thấp thì trả lời qua loa hoặc từ chối. Với khu vực công, trình tự và hình thức lựa chọn nhà thầu do pháp luật đấu thầu quy định riêng; doanh nghiệp nhà nước cần đối chiếu văn bản hiện hành trước khi áp dụng khung trong bài.
Chín phần của một RFP phần mềm
Bối cảnh và hiện trạng. Doanh nghiệp làm gì, quy mô người dùng, chi nhánh, hệ thống đang chạy, quy trình hiện tại đau ở đâu. Nhà cung cấp không biết bạn đang dùng Excel cộng một phần mềm kế toán cài máy thì không thể ước lượng phần chuyển đổi dữ liệu.
Mục tiêu kinh doanh đo được. Không phải "hiện đại hoá quản lý" mà "giảm thời gian chốt sổ cuối tháng từ tám ngày xuống ba ngày" hay "nhân viên kho xuất hàng không cần in phiếu". Mục tiêu này về sau thành thước đo nghiệm thu giá trị.
Phạm vi trong và ngoài. Liệt kê rõ phân hệ nào thuộc dự án và phân hệ nào không. Dòng "ngoài phạm vi" thường tiết kiệm nhiều tranh cãi hơn cả trang "trong phạm vi".
Yêu cầu chức năng. Viết theo nghiệp vụ, đánh số, gắn mức ưu tiên. Bảng yêu cầu nên để nhà cung cấp trả lời từng dòng: có sẵn, cấu hình, phải phát triển thêm, không đáp ứng.
Yêu cầu phi chức năng. Số người dùng đồng thời, thời gian phản hồi, sẵn sàng hoạt động, bảo mật, sao lưu, ngôn ngữ, chạy trên điện thoại hay không.
Tích hợp và dữ liệu. Hệ thống nào phải nói chuyện với nhau, dữ liệu cũ bao nhiêu năm, bao nhiêu bản ghi, ai làm sạch.
Đội dự án và cách làm việc. Yêu cầu nêu tên vai trò chủ chốt, kinh nghiệm, phương pháp quản lý, tần suất báo cáo, nơi làm việc.
Mẫu bảng giá bắt buộc. Tách bản quyền, phát triển, triển khai, chuyển đổi dữ liệu, đào tạo, hạ tầng, bảo trì từng năm. Không cho trả lời bằng một con số tổng.
Tiêu chí chấm và lịch trình. Công bố trọng số, hạn nộp câu hỏi, hạn nộp hồ sơ, ngày trình bày, ngày quyết định. Minh bạch tiêu chí giúp nhà cung cấp tự loại nếu không hợp.
Viết phần yêu cầu sao cho nhà cung cấp trả lời được
Lỗi phổ biến nhất của RFP do doanh nghiệp tự soạn là yêu cầu viết theo giải pháp thay vì theo vấn đề. "Hệ thống phải có nút xuất Excel ở mọi màn hình" là một giải pháp; vấn đề thật có thể là "kế toán cần đối chiếu số liệu với ngân hàng mỗi ngày". Khi bạn nêu vấn đề, nhà cung cấp giỏi có cơ hội đề xuất cách tốt hơn, chẳng hạn đối soát tự động qua kết nối ngân hàng. Khi bạn nêu giải pháp, bạn chỉ nhận lại đúng thứ mình nghĩ ra, với cái giá của người làm theo đơn.
Lỗi thứ hai là yêu cầu không kiểm chứng được. "Giao diện thân thiện", "tốc độ nhanh", "bảo mật cao" đều không thể nghiệm thu. Đổi thành: "nhân viên bán hàng mới hoàn thành tạo đơn sau tối đa hai giờ hướng dẫn", "95% thao tác tra cứu trả kết quả dưới hai giây với 200 người dùng đồng thời", "mật khẩu băm một chiều, có xác thực hai lớp cho tài khoản quản trị". Một mẹo nhỏ: với mỗi yêu cầu, tự hỏi "đến ngày nghiệm thu, mình sẽ kiểm tra điều này bằng cách nào". Không trả lời được thì viết lại.
Lỗi thứ ba là mọi thứ đều "bắt buộc". Một RFP 400 dòng yêu cầu toàn mức cao nhất khiến không nhà cung cấp nào đáp ứng trọn, và bạn mất công cụ để phân biệt họ. Dùng ba mức như bắt buộc, nên có, mong muốn, và giữ phần bắt buộc ở mức tối thiểu để vận hành được. Bài viết riêng về cách viết yêu cầu phần mềm trên cùng chuyên mục đi sâu hơn vào kỹ thuật này.
Mẫu bảng giá: chỗ RFP thắng hay thua
Hai báo giá chỉ so được khi cùng cấu trúc và cùng giả định. Vì vậy phần giá của RFP nên là một bảng do bên mua soạn sẵn, nhà cung cấp chỉ điền. Các dòng tối thiểu gồm: bản quyền hoặc phí thuê bao theo năm; công phát triển theo phân hệ; công triển khai, cấu hình; chuyển đổi dữ liệu; tích hợp từng hệ thống; đào tạo; hạ tầng nếu nhà cung cấp lo; bảo hành; bảo trì và hỗ trợ cho năm thứ hai đến năm thứ năm; đơn giá ngày công cho yêu cầu thay đổi phát sinh.
Dòng cuối cùng hay bị bỏ quên nhưng quan trọng bậc nhất. Thực tế hầu như dự án nào cũng phát sinh thay đổi, và đơn giá phát sinh mới là nơi nhà cung cấp bù lại phần giảm giá lúc đấu thầu. Một hồ sơ chào thấp hơn đối thủ 20% nhưng đơn giá ngày công phát sinh cao gấp rưỡi có thể đắt hơn sau năm đầu.
Cuối cùng, yêu cầu ghi rõ giả định đi kèm giá: số người dùng, số chi nhánh, khối lượng dữ liệu, số vòng chỉnh sửa giao diện, bên nào cung cấp máy chủ. Giả định khác nhau là lý do số khác nhau; buộc ghi ra thì bạn mới chuẩn hoá được trước khi chấm. Thói quen tốt là quy đổi mọi hồ sơ về tổng chi phí năm năm, gồm cả chi phí nội bộ của bạn như nhân sự tham gia dự án.
Tiêu chí chấm và trọng số tham khảo
Công bố tiêu chí trong RFP giúp nhà cung cấp tập trung vào điều bạn quan tâm. Trọng số dưới đây là ví dụ giả định cho một dự án phần mềm quản lý vừa; mỗi doanh nghiệp nên tự điều chỉnh, và quan trọng là chốt trước khi mở hồ sơ, không chỉnh sau khi đã thấy giá.
| Nhóm tiêu chí | Trọng số ví dụ | Cách đánh giá |
|---|---|---|
| Mức đáp ứng yêu cầu nghiệp vụ | 30% | Chấm từng dòng yêu cầu, kiểm lại bằng buổi trình diễn theo kịch bản của bạn |
| Năng lực và kinh nghiệm | 20% | Dự án tương tự, gọi điện cho khách hàng tham chiếu, hồ sơ nhân sự chủ chốt |
| Phương pháp triển khai | 15% | Kế hoạch, quản lý rủi ro, cách chuyển đổi dữ liệu và đào tạo |
| Kiến trúc, bảo mật, khả năng mở rộng | 10% | Câu trả lời phi chức năng, buổi làm việc kỹ thuật |
| Tổng chi phí năm năm | 20% | Quy đổi về cùng giả định, gồm phát sinh dự kiến |
| Điều khoản hợp đồng đề xuất | 5% | Sở hữu mã nguồn, bảo hành, cam kết dịch vụ |
Nhiều doanh nghiệp đặt giá ở trọng số 50% hoặc hơn. Cách đó khuyến khích chào thấp rồi bù bằng phát sinh, đúng điều mà tài liệu về mua sắm công nghệ đã cảnh báo từ lâu. Khi giá chiếm phần lớn, hãy ít nhất đặt ngưỡng điểm kỹ thuật tối thiểu: hồ sơ không đạt ngưỡng thì không mở phong bì giá.
Quy trình phát RFP và đánh giá trong tám tuần
Một khung thời gian thực tế cho dự án vừa, giả định đã có danh sách rút gọn từ bước RFI:
- Tuần 1–2: nhóm dự án nội bộ gồm đại diện nghiệp vụ, CNTT, tài chính soạn RFP; lãnh đạo duyệt mục tiêu và ngân sách trần.
- Tuần 3: phát RFP kèm thoả thuận bảo mật; mở kênh hỏi đáp bằng văn bản, câu trả lời gửi chung cho mọi nhà cung cấp.
- Tuần 4–5: nhà cung cấp chuẩn bị hồ sơ; bên mua chuẩn bị kịch bản trình diễn dựa trên ba đến năm tình huống nghiệp vụ thật.
- Tuần 6: nhận hồ sơ, chấm độc lập theo tiêu chí đã công bố, mỗi người chấm riêng rồi mới họp hợp nhất.
- Tuần 7: buổi trình diễn theo kịch bản của bạn, không theo bài thuyết trình soạn sẵn của nhà cung cấp; gọi khách hàng tham chiếu.
- Tuần 8: đàm phán với một hoặc hai nhà cung cấp dẫn đầu, chốt phạm vi, giá, điều khoản; thông báo kết quả cho các bên còn lại.
Hai bước hay bị cắt để kịp tiến độ là kênh hỏi đáp chung và buổi trình diễn theo kịch bản. Cắt kênh hỏi đáp thì mỗi nhà cung cấp hiểu yêu cầu một kiểu; cắt kịch bản thì bạn chấm kỹ năng thuyết trình chứ không chấm phần mềm.
Câu hỏi thường gặp
Doanh nghiệp nhỏ mua phần mềm vài chục triệu đồng có cần RFP không?
Không cần một RFP đầy đủ. Với gói có sẵn giá thấp, một bảng so sánh ba nhà cung cấp theo mười yêu cầu chính, cộng dùng thử và hỏi khách hàng đang dùng là đủ. RFP đáng công khi dự án có phần phát triển riêng, tích hợp nhiều hệ thống hoặc chi phí năm năm đủ lớn để sai lầm gây thiệt hại đáng kể.
Có nên công bố ngân sách trong RFP?
Có hai trường phái. Công bố khoảng ngân sách giúp nhà cung cấp đề xuất giải pháp đúng tầm và loại bớt hồ sơ không thực tế, nhưng làm giá hội tụ về sát trần. Không công bố thì so được giá thật hơn nhưng dễ nhận đề xuất lệch xa nhau. Cách dung hoà phổ biến là nêu quy mô dự án và thứ tự ưu tiên, giữ ngân sách cho vòng đàm phán.
Ai nên soạn RFP, bộ phận CNTT hay nghiệp vụ?
Cả hai, với người chịu trách nhiệm chính là chủ dự án phía nghiệp vụ. CNTT viết tốt phần phi chức năng, tích hợp, bảo mật nhưng thường không nắm hết ngoại lệ trong quy trình. Nghiệp vụ biết việc nhưng hay viết theo thói quen của hệ thống cũ. Một chuyên gia tư vấn độc lập có thể giúp chuẩn hoá, miễn là không có quan hệ lợi ích với nhà cung cấp tham dự.
Có nên dùng RFP mẫu tải trên mạng?
Mẫu hữu ích để không bỏ sót đề mục, nhưng bảng yêu cầu chép nguyên từ mẫu thường dài, chung chung và không phản ánh nghiệp vụ của bạn. Nhà cung cấp nhận ra ngay và trả lời bằng mẫu tương ứng. Hãy dùng mẫu làm danh mục kiểm tra, còn nội dung yêu cầu phải viết từ quy trình thật và các tình huống thật của doanh nghiệp.
Nhà cung cấp hỏi xin gặp riêng trước khi nộp hồ sơ thì xử lý thế nào?
Có thể gặp để họ hiểu bối cảnh, nhưng mọi thông tin làm thay đổi cách hiểu yêu cầu phải được ghi lại và gửi chung cho tất cả. Nếu không, quy trình mất công bằng và nhà cung cấp bị bất lợi có lý do khiếu nại. Một số doanh nghiệp tổ chức một buổi giới thiệu chung cho mọi bên thay vì gặp riêng từng bên.
Sau khi chọn, RFP và hồ sơ dự thầu có giá trị gì với hợp đồng?
Nên dẫn chiếu cả hai làm phụ lục hợp đồng, kèm thứ tự ưu tiên khi mâu thuẫn. Như vậy những cam kết nhà cung cấp đưa ra trong hồ sơ, như tính năng có sẵn, nhân sự chủ chốt, thời gian phản hồi hỗ trợ, trở thành nghĩa vụ chứ không chỉ là lời chào hàng.