Cách tự ước lượng ngân sách hệ thống nội bộ trước khi đi hỏi giá

Ngân sách của một hệ thống nội bộ không được quyết định bởi "số màn hình" hay "số chức năng", mà bởi 5 biến số: độ phức tạp luồng nghiệp vụ (kèm ngoại lệ), mức độ tích hợp, hiện trạng dữ liệu, độ phức tạp phân quyền, và mức cam kết vận hành. Tự ước lượng được 5 biến số này trước khi đi hỏi giá, bạn sẽ so sánh được các báo giá trên cùng một hệ quy chiếu — thay vì hoang mang giữa những con số chênh nhau 3–5 lần.

TL;DR (Executive Summary)

  • Bài toán: Báo giá phần mềm nội bộ chênh nhau 3–5 lần mà doanh nghiệp không có căn cứ so sánh, vì yêu cầu được mô tả bằng "số màn hình" thay vì các biến số thật sự tạo ra chi phí.
  • Giải pháp: Khung 5 biến số chi phí + ma trận cắt scope + checklist chuẩn bị trước khi gửi yêu cầu báo giá (RFQ).
  • Kết quả: So sánh báo giá táo-với-táo, phát hiện báo giá rẻ do thiếu hạng mục, và cắt scope chủ động thay vì bị cắt chất lượng ngầm.

Tôi làm Delivery Manager 14 năm, ngồi ở cả phía lập báo giá lẫn phía thẩm định báo giá. Điều ít người nói thẳng: phần lớn báo giá chênh lệch không phải vì vendor này đắt hơn vendor kia, mà vì mỗi bên đang định giá một sản phẩm khác nhau — được suy diễn từ cùng một bản yêu cầu mơ hồ.

"Ngân sách phần mềm" — định nghĩa lại từ góc delivery

Định nghĩa phổ biến: ngân sách = số tiền trong hợp đồng xây dựng. Định nghĩa đúng từ hiện trường:

Ngân sách phần mềm = Tổng chi phí sở hữu (TCO) trong vòng đời hệ thống — gồm xây dựng, vận hành, chỉnh sửa theo nghiệp vụ thay đổi, và chi phí thoát (exit cost) khi cần thay thế.

Theo kinh nghiệm các dự án tôi trực tiếp delivery, chi phí vận hành + chỉnh sửa trong 3–4 năm đầu thường ngang với chi phí xây ban đầu. Một báo giá xây rẻ nhưng khóa bạn vào chi phí chỉnh sửa đắt (hoặc vào tình trạng lệ thuộc một cá nhân duy nhất hiểu hệ thống) là một báo giá đắt.

Khung 5 biến số chi phí

Biến số Câu hỏi tự trả lời Tác động ngân sách
① Luồng nghiệp vụ + ngoại lệ Có bao nhiêu luồng? Mỗi luồng có bao nhiêu ngoại lệ "thỉnh thoảng mới xảy ra"? Lớn nhất — ngoại lệ là nơi chi phí ẩn náu
② Mức độ tích hợp Phải nói chuyện với những hệ thống nào đang chạy? Chúng có API không? Tích hợp với hệ cũ không API có thể đắt hơn cả tính năng chính
③ Hiện trạng dữ liệu Dữ liệu cũ nằm ở đâu (Excel, phần mềm cũ)? Sạch chưa? Có phải migrate không? Migrate dữ liệu bẩn là hạng mục bị bỏ quên nhiều nhất
④ Phân quyền Bao nhiêu vai trò? Có phê duyệt nhiều cấp? Có dữ liệu chỉ một số người được thấy? Mỗi tầng phê duyệt là một tầng logic + test
⑤ Cam kết vận hành Hệ thống dừng 1 ngày thì thiệt hại gì? Ai hỗ trợ khi lỗi lúc 8h tối? Quyết định hạ tầng, monitoring, SLA — phần báo giá rẻ hay lờ đi

Cách dùng: trả lời 5 câu hỏi này bằng văn bản trước khi gặp bất kỳ vendor nào. Bản trả lời đó chính là phụ lục của yêu cầu báo giá — và là thước đo để mọi báo giá phải quy về cùng phạm vi.

Vì sao "số màn hình" là thước đo sai?

Hai hệ thống cùng 10 màn hình có thể chênh nhau 5 lần chi phí: một bên là CRUD nhập–xem dữ liệu, một bên có luồng phê duyệt 3 cấp, đồng bộ tồn kho thời gian thực và migrate 5 năm dữ liệu Excel. Vendor báo giá theo màn hình hoặc chấp nhận mô tả theo màn hình mà không hỏi thêm về ngoại lệ nghiệp vụ — đó đã là một tín hiệu về độ trưởng thành quy trình của vendor.

3 bẫy báo giá rẻ

  1. Báo giá theo happy path — chỉ tính luồng xuôi, toàn bộ ngoại lệ nghiệp vụ ("nếu khách trả hàng một phần thì sao?") thành phát sinh tính thêm sau. Phần ngoại lệ này thường chiếm 30–50% khối lượng thật.
  2. Bỏ trống hạng mục dữ liệu — "đưa dữ liệu cũ vào" nghe đơn giản nhưng dữ liệu Excel 5 năm không chuẩn hóa là một dự án con. Báo giá không có dòng migrate dữ liệu = quả bom hẹn giờ ở tháng cuối.
  3. Không có chi phí sau bàn giao — không nói gì về bảo hành, thời gian phản hồi khi lỗi, chi phí chỉnh sửa nhỏ. Giá xây rẻ đổi lấy thế độc quyền hét giá ở giai đoạn vận hành.

Ma trận cắt scope — khi ngân sách không đủ

Khi ước lượng vượt ngân sách, đa số doanh nghiệp cắt sai: giữ nguyên số tính năng, ép giá xuống — kết quả là chất lượng bị cắt ngầm (bỏ test, bỏ xử lý ngoại lệ). Cách cắt đúng là cắt theo ma trận:

Nghiệp vụ cốt lõi Nghiệp vụ phụ trợ
Tần suất cao Làm đủ chiều sâu (cả ngoại lệ) Làm bản tối giản
Tần suất thấp Làm bán tự động (người + công cụ) Cắt — để ngoài hệ thống

Nguyên tắc: cắt chiều rộng (số nghiệp vụ), giữ chiều sâu (độ hoàn thiện của nghiệp vụ cốt lõi). Một hệ thống làm 3 nghiệp vụ tử tế tạo ra giá trị thật; một hệ thống làm 10 nghiệp vụ nửa vời tạo ra 10 chỗ để công việc tắc lại. Trước khi cắt, cũng nên tự hỏi câu gốc: nghiệp vụ này có cần phần mềm may đo không, hay SaaS có sẵn là đủ?

Checklist trước khi gửi yêu cầu báo giá

Câu hỏi thường gặp

Doanh nghiệp không có người IT thì tự ước lượng kiểu gì?

Khung 5 biến số được thiết kế để trả lời bằng ngôn ngữ nghiệp vụ, không cần kiến thức lập trình: bạn chỉ cần mô tả luồng công việc, ngoại lệ, dữ liệu đang nằm đâu. Phần quy đổi sang độ phức tạp kỹ thuật là việc của vendor — nhiệm vụ của bạn là đảm bảo mọi vendor nhận cùng một bản mô tả đủ chi tiết để không ai được quyền "hiểu theo cách rẻ nhất".

Nên dành bao nhiêu phần ngân sách cho dự phòng?

Với hệ thống nội bộ có migrate dữ liệu cũ hoặc tích hợp hệ thống đang chạy, mức dự phòng hợp lý theo kinh nghiệm của tôi là 15–25% trên chi phí xây. Quan trọng hơn con số là quy tắc dùng: dự phòng chỉ giải ngân cho ngoại lệ phát hiện muộn, không phải cho tính năng mới nghĩ ra giữa chừng — tính năng mới phải đi qua vòng ưu tiên hóa riêng.

Nếu anh/chị đang cầm trong tay vài bản báo giá chênh nhau nhiều lần và chưa biết tin bản nào, hoặc muốn kiểm tra xem bản mô tả yêu cầu của mình đã đủ chặt chưa, có thể tham khảo cách tôi tiếp cận web app và hệ thống nội bộ, hoặc gửi bài toán cho tôi. Tôi thường phản hồi các case phù hợp với chuyên môn và quỹ thời gian hiện tại.