Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn là Technical BA tại một ngân hàng cỡ vừa. Ban lãnh đạo quyết định thay thế hệ thống Core Banking cũ kỹ chạy hơn 12 năm. Ngân sách dự kiến: 80 tỷ đồng. Ba nhà cung cấp quốc tế và hai nhà cung cấp trong nước đang chực chờ. Sếp quay sang bạn và nói: "Em chuẩn bị RFP đi."
Nếu bạn lúng túng không biết RFP là gì, bạn vừa đánh mất một trong những cơ hội lớn nhất để khẳng định vị thế của mình. Bởi vì trong những thương vụ mua sắm công nghệ lớn, người viết RFP chính là người định hình cuộc chơi: bạn quyết định nhà cung cấp phải trả lời điều gì, được chấm điểm theo tiêu chí nào, và cuối cùng ai thắng ai thua.
RFP (Request for Proposal — Yêu cầu đề xuất giải pháp) không phải là việc của riêng phòng mua sắm hay sếp. Phần "ruột" của RFP — yêu cầu chức năng, phi chức năng, kiến trúc, tích hợp, bảo mật, SLA — đều là sản phẩm của Technical BA. Nếu bạn viết yêu cầu mơ hồ, nhà cung cấp sẽ chào hàng mơ hồ, và bạn sẽ ký hợp đồng với một quả bom hẹn giờ. Bài này giúp bạn làm chủ quy trình đó.
Khái niệm cốt lõi
RFP là gì và khác gì với RFI, RFQ?
Trong mua sắm công nghệ, có ba "chữ R" mà bạn cần phân biệt rõ:
- RFI (Request for Information) — Yêu cầu thông tin. Đây là bước thăm dò thị trường. Bạn gửi cho nhiều nhà cung cấp để hỏi "Các anh làm được gì? Năng lực thế nào? Đã làm dự án tương tự chưa?" RFI dùng khi bạn chưa biết rõ thị trường có những lựa chọn nào.
- RFP (Request for Proposal) — Yêu cầu đề xuất giải pháp. Đây là bước nghiêm túc nhất. Bạn đã biết mình cần gì, và yêu cầu nhà cung cấp đề xuất một giải pháp cụ thể: kiến trúc, cách triển khai, lộ trình, chi phí, đội ngũ. RFP dùng khi bài toán phức tạp, có nhiều cách giải, và giá không phải yếu tố duy nhất.
- RFQ (Request for Quotation) — Yêu cầu báo giá. Dùng khi bạn đã biết chính xác cần mua gì (ví dụ: 200 license phần mềm X, hoặc 50 máy chủ cấu hình cụ thể), và chỉ cần so giá. Quyết định gần như hoàn toàn dựa trên giá.
Khi nào cần làm RFP?
Không phải mọi giao dịch đều cần RFP — vì RFP tốn 2–4 tháng và rất nhiều công sức. Bạn nên kích hoạt RFP khi:
- Giá trị mua sắm lớn. Ở Việt Nam, nhiều doanh nghiệp và đặc biệt là khu vực nhà nước quy định ngưỡng bắt buộc đấu thầu/RFP, thường từ 500 triệu đồng trở lên với gói công nghệ. Với khối nhà nước, Luật Đấu thầu còn quy định chặt chẽ hơn.
- Quyết định công nghệ trọng yếu. Core Banking, hệ thống CRM cấp doanh nghiệp, ERP, hệ thống thanh toán — những thứ mà nếu chọn sai sẽ "đóng đinh" công ty trong 5–10 năm.
- Bài toán có nhiều lời giải khả thi. Khi bạn có thể đi theo SaaS, on-premise, hay tự xây, và muốn nhà cung cấp đề xuất phương án tối ưu.
- Cần minh bạch và công bằng. RFP tạo ra "audit trail" — dấu vết kiểm toán — chứng minh quá trình lựa chọn khách quan, tránh tiếng "đi đêm" với nhà cung cấp.
Cấu trúc một RFP chuẩn
Một RFP đầy đủ thường gồm các phần sau, và Technical BA chịu trách nhiệm chính ở những phần in đậm:
- Giới thiệu & bối cảnh — Công ty là ai, vì sao cần dự án này, mục tiêu kinh doanh.
- Phạm vi công việc (Scope of Work) — Cái gì trong, cái gì ngoài phạm vi.
- Yêu cầu chức năng (Functional Requirements) — Hệ thống phải làm được gì.
- Yêu cầu phi chức năng (Non-Functional Requirements) — Hiệu năng, bảo mật, khả năng mở rộng, tính sẵn sàng.
- Yêu cầu kỹ thuật & tích hợp — Kiến trúc, API, dữ liệu, tích hợp với hệ thống hiện có.
- Yêu cầu triển khai & vận hành — Lộ trình, đào tạo, hỗ trợ, SLA.
- Tiêu chí đánh giá (Evaluation Criteria) — Cách chấm điểm đề xuất.
- Điều khoản thương mại & pháp lý — Giá, thanh toán, phạt, bảo hành.
- Quy trình & thời hạn nộp — Lịch trình, cách thức nộp, đầu mối liên hệ.
Ma trận yêu cầu (Requirement Traceability Matrix)
Đây là vũ khí của Technical BA. Thay vì viết yêu cầu thành đoạn văn dài, bạn lập một bảng mỗi dòng là một yêu cầu, có mã (REQ-001), mô tả, mức độ ưu tiên (Must / Should / Could — theo MoSCoW), và một cột để nhà cung cấp tự đánh dấu mức độ đáp ứng:
- F (Fully) — Đáp ứng đầy đủ ngay (out-of-the-box).
- C (Configuration) — Đáp ứng qua cấu hình.
- Cu (Customization) — Cần tùy chỉnh/code thêm.
- N (Not supported) — Không hỗ trợ.
Tình huống thực tế
Tình huống 1 — Ngân hàng TMCP và bài học "yêu cầu mơ hồ giết chết dự án"
Một ngân hàng thương mại cổ phần tầm trung tại TP.HCM (gọi tắt là NH Phương Đông trong ví dụ) cần thay hệ thống Loan Origination — khởi tạo và phê duyệt khoản vay. Technical BA viết yêu cầu thế này: "Hệ thống phải xử lý hồ sơ vay nhanh."
Ba nhà cung cấp đều trả lời "Đáp ứng đầy đủ". Đến khi triển khai, một nhà cung cấp hiểu "nhanh" là 30 giây/hồ sơ, ngân hàng kỳ vọng dưới 3 giây. Hậu quả: phải đàm phán lại, dự án trễ 4 tháng, phát sinh chi phí hơn 2 tỷ đồng.
Bài học: Yêu cầu phải đo lường được. Câu đúng phải là: "Hệ thống phải hoàn tất tính điểm tín dụng và trả kết quả sơ bộ trong vòng 3 giây với 95% hồ sơ, ở mức tải 500 hồ sơ đồng thời." Một con số cụ thể trong RFP đáng giá hàng tỷ đồng.
Tình huống 2 — Công ty bán lẻ chọn ERP và sức mạnh của tiêu chí có trọng số
Một chuỗi bán lẻ với 120 cửa hàng trên toàn quốc làm RFP chọn ERP, ngân sách 25 tỷ. Có ba nhà cung cấp lọt vào vòng cuối: một hãng quốc tế (SAP), một hãng khu vực Đông Nam Á, và một nhà tích hợp trong nước triển khai Odoo.
Ban đầu đội mua sắm muốn chọn theo giá — nhà cung cấp trong nước rẻ nhất (chỉ 14 tỷ). Nhưng Technical BA đã thiết kế ma trận chấm điểm có trọng số:
- Đáp ứng chức năng: 30%
- Năng lực tích hợp với hệ thống POS & kho hiện có: 20%
- Tổng chi phí sở hữu 5 năm (TCO): 20%
- Năng lực và kinh nghiệm đội triển khai: 15%
- Lộ trình & rủi ro triển khai: 10%
- Hỗ trợ & SLA: 5%
Bài học: Quyết định theo giá đơn thuần là cái bẫy. Tiêu chí có trọng số biến cuộc tranh luận cảm tính ("anh thích bên nào") thành quyết định dựa trên dữ liệu, và bảo vệ được bạn khi bị chất vấn về sau.
Tình huống 3 — Fintech và câu hỏi "demo có khớp lời nói không"
Một công ty fintech ví điện tử tại Hà Nội làm RFP tìm nhà cung cấp hệ thống phát hiện gian lận (fraud detection). Một nhà cung cấp ghi trong proposal: "Phát hiện gian lận theo thời gian thực bằng AI, độ chính xác 99%."
Technical BA không tin lời nói suông. Trong RFP, cô đã đưa vào một yêu cầu PoC (Proof of Concept): "Nhà cung cấp lọt vào vòng cuối phải chạy thử trên bộ dữ liệu giao dịch ẩn danh 1 triệu bản ghi do chúng tôi cung cấp, trong 5 ngày, và trình bày tỷ lệ false positive thực tế."
Kết quả: nhà cung cấp "99%" kia có tỷ lệ báo nhầm (false positive) lên tới 18% — nghĩa là cứ 100 giao dịch hợp lệ thì chặn nhầm 18, không thể chấp nhận. Một nhà cung cấp khác khiêm tốn hơn lại cho kết quả thực tế tốt hơn nhiều.
Bài học: Với hệ thống trọng yếu, đừng chấm điểm chỉ trên giấy. Đưa PoC hoặc scripted demo (kịch bản demo do bạn soạn, không để nhà cung cấp tự diễn) vào RFP để kiểm chứng năng lực thật.
Hướng dẫn từng bước
Dưới đây là quy trình bạn có thể áp dụng cho một dự án RFP từ đầu đến cuối:
Bước 1 — Xác định nhu cầu và phạm vi. Trước khi viết một chữ nào, làm rõ vấn đề kinh doanh cần giải quyết và ranh giới phạm vi. Họp với các stakeholder để chốt "in/out of scope". Đây là lúc dùng kỹ năng elicitation kinh điển của BA.
Bước 2 — (Tùy chọn) Phát RFI để thăm dò thị trường. Nếu bạn chưa rõ thị trường, gửi RFI ngắn cho 6–8 nhà cung cấp để lập danh sách rút gọn (shortlist) 3–5 bên có năng lực thực sự.
Bước 3 — Soạn yêu cầu. Đây là phần nặng nhất của Technical BA. Viết yêu cầu chức năng, phi chức năng, kỹ thuật, tích hợp dưới dạng ma trận yêu cầu có mã và mức ưu tiên MoSCoW. Mỗi yêu cầu phải SMART — cụ thể, đo được, có thể kiểm chứng.
Bước 4 — Thiết kế tiêu chí đánh giá và trọng số. Quyết định trước khi nhận đề xuất bạn sẽ chấm theo tiêu chí gì, trọng số bao nhiêu. Làm việc này TRƯỚC khi mở proposal để tránh thiên vị. Lập sẵn scoring sheet (bảng chấm điểm).
Bước 5 — Phát hành RFP và tổ chức Q&A. Gửi RFP cho các nhà cung cấp shortlist, kèm lịch trình rõ ràng. Tổ chức một buổi giải đáp (bidders' conference) để nhà cung cấp hỏi, và bạn trả lời công khai cho TẤT CẢ các bên để đảm bảo công bằng.
Bước 6 — Nhận và chấm điểm đề xuất. Mỗi thành viên hội đồng chấm độc lập theo scoring sheet, sau đó tổng hợp. Với hệ thống lớn, tổ chức PoC hoặc scripted demo cho 2–3 bên dẫn đầu.
Bước 7 — Shortlist, đàm phán và chọn. Lập danh sách 1–2 bên dẫn đầu, đàm phán thương mại và pháp lý, kiểm tra tham chiếu (gọi điện cho khách hàng cũ của nhà cung cấp), rồi ra quyết định cuối.
Bước 8 — Lập biên bản và trao thầu. Ghi lại toàn bộ lý do chọn để có audit trail. Thông báo cho cả bên thắng và bên thua. Chuyển sang giai đoạn ký hợp đồng và lập SOW (Statement of Work).
Lỗi thường gặp & mẹo
Lỗi 1 — Yêu cầu mơ hồ, không đo lường được. "Hệ thống phải thân thiện", "phải nhanh", "phải bảo mật" là những câu vô nghĩa với nhà cung cấp. Mẹo: mỗi yêu cầu phi chức năng phải có một con số gắn vào (thời gian phản hồi, số người dùng đồng thời, uptime 99.9%...).
Lỗi 2 — Sao chép tài liệu kỹ thuật của một nhà cung cấp vào RFP. Đây là cái bẫy tinh vi: nếu bạn copy mô tả tính năng độc quyền của hãng A, vô tình RFP của bạn "đo ni đóng giày" cho hãng A, các hãng khác không thể cạnh tranh. Mẹo: viết yêu cầu theo nhu cầu (what), không theo giải pháp của một hãng (how).
Lỗi 3 — Quá nhiều yêu cầu "Must". Nếu mọi thứ đều bắt buộc, bạn loại hết nhà cung cấp hoặc đẩy giá lên trời. Mẹo: dùng MoSCoW nghiêm túc — chỉ những gì thực sự không thể thiếu mới là Must.
Lỗi 4 — Tiêu chí đánh giá đặt ra sau khi mở proposal. Đây là cửa ngõ của thiên vị và tranh chấp pháp lý. Mẹo: chốt và ký duyệt scoring sheet trước hạn nộp.
Lỗi 5 — Bỏ qua TCO, chỉ nhìn giá mua ban đầu. Một giải pháp rẻ khi mua nhưng đắt khi vận hành (license năm, phí bảo trì 20%/năm, chi phí tích hợp) có thể tốn gấp đôi sau 5 năm. Mẹo: luôn yêu cầu nhà cung cấp báo TCO 5 năm, không chỉ giá mua.
Lỗi 6 — Tin lời nói trong proposal mà không kiểm chứng. Mẹo: yêu cầu reference check (gọi khách hàng cũ), PoC, và scripted demo cho hệ thống trọng yếu.
Mẹo vàng: Hãy nghĩ như một nhà cung cấp khi viết RFP. Tự hỏi "Nếu mình là bên bán, mình sẽ lách câu này thế nào?". Mỗi chỗ có thể lách được là một chỗ cần viết chặt lại.
Bài tập thực hành
Bài tập 1 — Viết lại yêu cầu mơ hồ. Cho ba yêu cầu sau, hãy viết lại cho cụ thể và đo lường được:
- "Hệ thống phải xử lý báo cáo nhanh."
- "Hệ thống phải bảo mật cao."
- "Giao diện phải dễ dùng."
Bài tập 3 — Quyết định loại tài liệu. Với mỗi tình huống dưới đây, chọn RFI, RFP hay RFQ và giải thích:
- Mua thêm 300 license của phần mềm văn phòng đang dùng.
- Tìm hiểu thị trường có những nền tảng e-learning nào trước khi quyết định.
- Thay thế hệ thống quản lý kho cho chuỗi 50 nhà thuốc, ngân sách 6 tỷ.
Tóm tắt
RFP là công cụ Technical BA dùng để biến một nhu cầu công nghệ phức tạp thành một cuộc lựa chọn nhà cung cấp minh bạch, công bằng và dựa trên dữ liệu. Hãy ghi nhớ:
- Phân biệt RFI (thăm dò), RFP (đề xuất giải pháp), RFQ (báo giá) và dùng đúng loại cho đúng tình huống.
- Kích hoạt RFP khi giá trị lớn (thường trên 500 triệu), quyết định trọng yếu, hoặc cần minh bạch.
- Phần "ruột" của RFP — yêu cầu chức năng, phi chức năng, tích hợp — là sản phẩm của bạn, và phải SMART, đo được, dùng ma trận yêu cầu với MoSCoW.
- Thiết kế tiêu chí chấm điểm có trọng số TRƯỚC khi mở proposal, và luôn nhìn TCO 5 năm thay vì giá mua ban đầu.
- Kiểm chứng năng lực thật qua PoC, scripted demo và reference check — đừng tin lời nói suông.