Checklist thuê đội gia công phần mềm nội bộ: 12 câu hỏi

#Chọn vendor không chỉ là chọn báo giá thấp nhất

Một phần mềm nội bộ thường bắt đầu bằng câu rất đơn giản: “Team đang làm việc này trên Excel, làm một app cho đỡ thủ công được không?” Sau vài cuộc gọi, brief biến thành dashboard, phân quyền, import dữ liệu, thông báo, báo cáo, tích hợp và hàng chục ngoại lệ.

Rủi ro lớn không nằm ở việc vendor đắt hay rẻ. Nó nằm ở lúc ký mà chưa rõ thứ gì được bàn giao, ai sở hữu mã nguồn, dữ liệu chạy ở đâu và ai xử lý khi quy trình đổi sau vài tháng. Bài này dành cho SME đã quyết định thuê đội bên ngoài làm phần mềm nội bộ. Bạn có thể mang nguyên checklist vào các cuộc gọi, chấm từng vendor theo cùng tiêu chí rồi mới so giá.

Nên đọc nếu: bạn cần hệ thống cho sales, vận hành, back office hoặc dashboard nội bộ và đang lấy từ hai báo giá trở lên. Bỏ qua nếu: bài toán chỉ là một automation hẹp. Trong trường hợp đó, dịch vụ gia công công cụ AI hoặc POC nhỏ có thể phù hợp hơn dự án phần mềm đầy đủ.

#Khi nào thuê ngoài hợp lý hơn kéo team nội bộ làm?

Team nội bộ hiểu nghiệp vụ và thay đổi nhanh, nhưng có thể đang bận roadmap khác hoặc thiếu năng lực cho loại hệ thống cần build. Thuê ngoài hợp lý khi bạn cần đưa một quy trình đã khá rõ vào vận hành trong thời gian giới hạn, đồng thời vẫn muốn sở hữu kết quả sau bàn giao.

Trước khi tìm vendor, kiểm tra ba điều: có owner nội bộ đủ quyền quyết định workflow; có người dùng thực tế sẵn sàng phản hồi hằng tuần; và vấn đề có thực sự cần phần mềm riêng hay chỉ cần sửa quy trình/automation trước. Nếu cả ba chưa rõ, dự án dễ biến thành “làm theo yêu cầu” liên tục.

#Bốn câu hỏi về vấn đề và scope

#1. Vấn đề kinh doanh nào bản đầu tiên phải giải quyết?

Đừng bắt đầu bằng danh sách màn hình. Hãy bắt đầu bằng một kết quả có thể quan sát: giảm thời gian đối soát đơn, bỏ nhập cùng một dữ liệu ở ba nơi hoặc giúp quản lý nhìn thấy tình trạng lead trong ngày.

Yêu cầu vendor viết lại vấn đề bằng ngôn ngữ vận hành và xác nhận với người dùng. Nếu họ chỉ lặp lại tính năng bạn nêu mà không chỉ ra outcome, scope vẫn chưa được hiểu.

#2. Ai dùng, ai duyệt và ai chịu trách nhiệm dữ liệu?

Cùng một chức năng có thể khác rất xa giữa nhân viên, trưởng nhóm và admin. Danh sách vai trò cần ghi mỗi vai trò xem gì, sửa gì, duyệt gì và có thể export gì. Đây không chỉ là UX; nó quyết định phân quyền, audit log và cách xử lý khi nhân sự thay đổi.

#3. Phạm vi bản đầu tiên loại trừ điều gì?

Scope tốt luôn có phần không làm. Bản đầu có thể chỉ hỗ trợ một chi nhánh, một loại biểu mẫu, import từ file chuẩn và chưa tích hợp kế toán. Điều đó không làm dự án yếu hơn; nó làm việc nghiệm thu được.

Yêu cầu vendor đưa danh sách ngoài phạm vi và cách xử lý change request vào proposal. Nếu không, hai bên có thể cùng tin rằng một tính năng “rõ ràng phải có” nhưng chưa hề được tính trong giá.

#4. Dữ liệu cũ sẽ được xử lý ra sao?

Phần mềm mới không tự sửa dữ liệu cũ. Hỏi rõ dữ liệu import từ đâu, ai làm sạch, định dạng file thế nào, bản ghi trùng xử lý ra sao và có cần chạy song song hệ thống cũ không. Đây là phần hay phát hiện muộn nhưng có thể quyết định ngày go-live.

#Ba câu hỏi về cách đội đó delivery

#5. Sáu tuần đầu trông như thế nào?

Bạn không cần ép mọi dự án phải xong trong sáu tuần. Nhưng vendor cần mô tả được vài tuần đầu sẽ tạo ra bằng chứng gì: workshop nghiệp vụ, prototype, backlog ưu tiên, môi trường test, luồng đầu tiên chạy được hay UAT.

Mốc delivery tốt có đầu ra kiểm được, không phải chỉ là “đang phát triển”. Ví dụ: tuần 2 chốt workflow và prototype; tuần 4 có bản test với phân quyền cơ bản; tuần 6 UAT cho nhóm người dùng. Mốc có thể khác, nhưng cách đo phải rõ.

#6. Khi thay đổi yêu cầu, hai bên quyết định bằng cách nào?

Thay đổi là bình thường vì người dùng nhìn thấy phần mềm mới biết mình cần gì. Cần biết ai đánh giá tác động, thay đổi được ghi ở đâu, có ảnh hưởng timeline/chi phí không và ai có quyền duyệt.

Tránh hai cực: “cái gì cũng thêm miễn phí” làm dự án trôi, hoặc “cái gì cũng báo giá lại” khiến team ngại phản hồi. Một change log nhẹ, có người quyết và có trade-off rõ thường đủ cho dự án SME.

#7. Chất lượng được kiểm tra trước UAT thế nào?

Hỏi vendor về test ở đúng phạm vi: phân quyền, dữ liệu lỗi, luồng quan trọng, thiết bị/mobile nếu người dùng cần và tình huống thao tác bị gián đoạn. Bạn cũng nên chốt tiêu chí UAT: việc nào phải pass để nghiệm thu, lỗi nào vào backlog và thời hạn sửa lỗi sau launch.

#Ba câu hỏi về ownership và bảo mật

#8. Ai sở hữu mã nguồn, tài khoản cloud và dữ liệu?

Câu này cần câu trả lời bằng văn bản. Nếu hợp đồng nói bạn sở hữu code nhưng repository, domain, database hoặc tài khoản deploy hoàn toàn thuộc vendor, việc chuyển giao vẫn khó.

Checklist bàn giao nên có repository, tài khoản hosting, database, cấu hình được chuyển qua kênh an toàn, tài liệu và danh sách dịch vụ bên thứ ba. Vendor có thể vận hành cho bạn, nhưng quyền kiểm soát cần thuộc công ty bạn.

#9. Phân quyền và dữ liệu nhạy cảm được thiết kế thế nào?

Nêu loại dữ liệu thật: thông tin khách, giá bán, hợp đồng, dữ liệu nhân sự hay số liệu tài chính. Vendor không thể thiết kế phù hợp nếu họ chỉ nghe “dữ liệu nội bộ”.

Câu trả lời cần có user role, quyền export, audit log cho thao tác nhạy cảm, backup và cách thu hồi quyền khi nhân sự nghỉ. Với workflow AI hoặc automation, bài AI không hiệu quả: 5 lý do SME hay gặp cũng chỉ ra vì sao owner vận hành quan trọng hơn demo.

#10. Nếu vendor dừng hợp tác, team khác tiếp quản được không?

Hệ thống nội bộ thường dùng lâu hơn hợp đồng build ban đầu. Hỏi cách code được tổ chức, tài liệu nào được bàn giao, môi trường test có tồn tại không và team mới cần gì để tiếp quản.

Yêu cầu một buổi handover, sơ đồ hệ thống, hướng dẫn deploy/rollback, danh sách integration và backlog còn lại. “Code rõ ràng lắm” không phải câu trả lời đủ.

#Hai câu hỏi về vận hành và tổng chi phí

#11. Sau launch, ai nhận lỗi và SLA là gì?

Không cần mọi SME có hỗ trợ 24/7. Nhưng cần biết đường báo lỗi, giờ phản hồi, ai phân loại mức độ và lỗi nào là bug hay yêu cầu mới. Hỏi thêm về backup, monitoring và quyền truy cập production: nếu job import thất bại hay API bên thứ ba đổi, ai thấy trước khi người dùng báo?

#12. Tổng chi phí trong 12 tháng gồm những gì?

Giá build chỉ là một phần. Yêu cầu tách phí discovery, thiết kế/build, hạ tầng, license bên thứ ba, migration dữ liệu, bảo trì và change request. Nếu có AI/API, quote cần nêu giả định usage và cảnh báo chi phí.

Quote cao hơn nhưng có handover, monitoring và bảo trì có thể so sánh tốt hơn quote thấp nhưng mọi chi phí phát sinh nằm ngoài. Mục tiêu không phải ép giá xuống mà là không bị bất ngờ sau khi ký.

#Red flags khi đọc proposal

Dừng lại và hỏi lại nếu proposal có những dấu hiệu sau:

• Liệt kê nhiều màn hình nhưng không có outcome, vai trò người dùng hoặc acceptance criteria.
• Hứa timeline rất nhanh nhưng không có workshop, prototype, test hoặc UAT.
• Nói “bảo mật chuẩn” mà không mô tả phân quyền, backup, log hay loại dữ liệu bảo vệ.
• Không ghi quyền sở hữu code, tài khoản deploy và tài liệu bàn giao.
• Giá “trọn gói” nhưng không liệt kê integration, migration dữ liệu và hỗ trợ sau launch.

Một red flag không tự động loại vendor. Nhưng nếu họ không thể trả lời cụ thể sau khi được hỏi, rủi ro delivery là có thật.

#Scorecard so sánh ba vendor

Đừng chấm vendor chỉ bằng cảm giác từ buổi pitch. Dùng cùng scorecard, chấm 1–5 và ghi bằng chứng từ proposal hoặc call.

Điểm số không thay thế cho thẩm định, nhưng buộc các bên dùng cùng tiêu chí thay vì chỉ nói “bên này có cảm giác tốt hơn”.

#Một scope sáu tuần thực tế nên có gì?

Không nên hứa số tuần cứng khi chưa discovery. Nhưng với một quy trình nội bộ hẹp, scope gọn thường có: một workflow chính đã xác nhận; vai trò/phân quyền cơ bản; một hoặc hai integration cần thiết; dữ liệu mẫu và quy tắc import; môi trường test, UAT nhóm nhỏ, checklist launch; và backlog rõ những thứ chưa làm ở bản đầu.

Nếu vendor hứa một hệ thống “all-in-one” trong cùng khoảng thời gian mà không cắt phạm vi, hãy yêu cầu họ chỉ ra phần nào là prototype, phần nào chạy production và phần nào thuộc roadmap.

#Cần người thứ hai đọc scope trước khi ký?

Bạn có thể mang brief hoặc proposal vào cuộc trao đổi ngắn. Benocode Team sẽ chỉ ra phần scope thiếu, câu hỏi chưa có câu trả lời và chỗ nào cần tách POC khỏi production. Mục tiêu là để bạn hiểu thứ mình đang mua, không phải ép bạn thay vendor.

Nếu bài toán cần hệ thống nội bộ với Next.js, Postgres hoặc automation đi kèm, xem dịch vụ gia công phần mềm. Với use case hẹp có AI/automation, dịch vụ công cụ AI có thể là điểm khởi đầu nhỏ hơn.

Mang proposal vào để rà scope →

#FAQ

Tôi có cần viết tài liệu yêu cầu hoàn chỉnh trước khi gặp vendor không?

Không cần tài liệu dài. Bạn cần mô tả quy trình hiện tại, người dùng chính, đầu ra mong muốn, dữ liệu liên quan và ngoại lệ quan trọng. Vendor có thể giúp chuyển thành scope, nhưng owner nội bộ vẫn phải quyết ưu tiên.

Nên chọn fixed price hay time and materials?

Với phạm vi bản đầu rõ, fixed price giúp dự trù tốt hơn. Với discovery hoặc bài toán còn nhiều ẩn số, time and materials có thể trung thực hơn nếu có cap, review định kỳ và change log.

Phần mềm nội bộ có cần thiết kế mobile ngay không?

Chỉ khi người dùng thực sự thao tác trên điện thoại. Nếu quản lý xem dashboard còn nhân viên xử lý dữ liệu trên desktop, hãy tách hai nhu cầu. Responsive không đồng nghĩa với tối ưu mọi thao tác trên mobile.

Vendor có nên được quyền giữ hạ tầng để hỗ trợ nhanh hơn không?

Vendor có thể vận hành hạ tầng theo hợp đồng, nhưng quyền sở hữu và quyền truy cập khẩn cấp cần rõ. Công ty bạn nên kiểm soát tài khoản gốc, billing và cách chuyển giao nếu hợp tác kết thúc.

Tôi đã có team dev nhỏ, có nên thuê ngoài toàn bộ không?

Không nhất thiết. Một mô hình tốt là team nội bộ giữ owner nghiệp vụ, review kiến trúc và nhận bàn giao; vendor tăng tốc phần thiếu năng lực hoặc thời gian. Đừng để team nội bộ đứng ngoài hoàn toàn.