Trả lời nhanh: khi nào nên mua, khi nào nên thuê làm?
Quy tắc ngắn gọn: nếu quy trình không tạo ra lợi thế cạnh tranh (kế toán, email, chấm công), hãy mua phần mềm có sẵn và điều chỉnh quy trình theo phần mềm. Nếu quy trình chính là điểm khác biệt của doanh nghiệp, hãy cân nhắc thuê làm hoặc tự xây phần lõi đó. Phần lớn doanh nghiệp rơi vào giữa hai cực, nên lựa chọn thực tế thường là kết hợp.
Cách phân loại này dựa trên lập luận “utility vs strategic” của Martin Fowler: điều phân biệt hai loại là chức năng nghiệp vụ bên dưới có phải yếu tố khác biệt hay không. Fowler cho rằng với chức năng tiện ích, nên mua gói phần mềm và điều chỉnh quy trình theo nó; còn với chức năng chiến lược, dùng cùng phần mềm với đối thủ sẽ hạn chế khả năng tạo khác biệt. Ông cũng lưu ý chỉ một số ít dự án thực sự mang tính chiến lược.
Blog công nghệ của Chính phủ Anh (GOV.UK) đi cùng hướng: điều quan trọng nhất là giải pháp chạy được và đáp ứng nhu cầu người dùng; yêu cầu phổ biến như email thì nên mua, còn công cụ gắn với năng lực cốt lõi thì có thể tự xây.
Bốn lựa chọn: SaaS, cấu hình/low-code, phần mềm theo yêu cầu, kết hợp
“Tự xây hay mua” thực ra không chỉ có hai đáp án. Có ít nhất bốn hướng, và mỗi hướng đặt rủi ro, quyền kiểm soát ở một chỗ khác nhau.
| Hướng | Phù hợp khi | Đổi lại |
|---|---|---|
| Mua SaaS có sẵn (off-the-shelf) | Quy trình phổ biến, không tạo khác biệt; cần dùng sớm | Doanh nghiệp theo lộ trình sản phẩm của nhà cung cấp; khả năng tùy biến giới hạn; phụ thuộc điều khoản dịch vụ |
| Cấu hình / low-code trên nền tảng | Cần điều chỉnh biểu mẫu, quy trình duyệt, báo cáo nhưng logic không quá phức tạp | Phụ thuộc nền tảng; cấu hình phức tạp dần trở thành “mã” khó bảo trì |
| Phần mềm theo yêu cầu (custom) | Quy trình là lợi thế cạnh tranh, hoặc không có sản phẩm nào phù hợp | Doanh nghiệp chịu trách nhiệm vận hành, bảo trì, bảo mật dài hạn, dù tự làm hay thuê ngoài |
| Kết hợp (hybrid) | Phần tiện ích mua sẵn, phần lõi tự xây, nối với nhau qua API | Cần năng lực tích hợp và quản trị dữ liệu giữa nhiều hệ thống |
Bẫy tùy biến gói phần mềm
Fowler chỉ ra một sai lầm phổ biến: mua gói phần mềm cho chức năng tiện ích rồi chi rất nhiều để tùy biến, điều ông cho là lãng phí không kém. Trong bài “Package Customization”, ông lưu ý vấn đề thường bùng phát khi nhà cung cấp nâng cấp và phần tùy biến bị vỡ, nên khả năng nâng cấp cần được coi là yêu cầu bắt buộc khi chọn gói phần mềm.
Kết hợp là lựa chọn mặc định của nhiều doanh nghiệp
GOV.UK nhắc đến cách tiếp cận kết hợp: xây một số thành phần để giảm số nền tảng phải dùng, hoặc thuê chuyên gia xây cho mình. Ở doanh nghiệp Việt Nam, mô hình hay gặp là dùng phần mềm kế toán, hóa đơn điện tử, email có sẵn, rồi xây phần mềm riêng cho quy trình đặc thù và tích hợp các hệ thống qua API.
Bảng tiêu chí ra quyết định
Hãy chấm từng tiêu chí cho từng phương án. Không có công thức chuẩn; mục đích là để vận hành, tài chính và kỹ thuật cùng nói rõ giả định của mình.
| Tiêu chí | Câu hỏi cần trả lời | Nghiêng về mua | Nghiêng về thuê làm / tự xây |
|---|---|---|---|
| Mức độ khác biệt | Quy trình này có làm doanh nghiệp tốt hơn đối thủ không? | Không, ai cũng làm giống nhau | Có, đây là cách chúng tôi cạnh tranh |
| Độ phù hợp | Sản phẩm có sẵn đáp ứng bao nhiêu phần nhu cầu cốt lõi mà không cần tùy biến? | Đáp ứng phần lớn; chấp nhận đổi quy trình | Phải tùy biến sâu mới dùng được |
| Tổng chi phí sở hữu (TCO) | Đã tính đủ các thành phần chi phí trong suốt vòng đời chưa? | Chi phí thuê bao dự đoán được, ít chi phí vận hành | Chi phí tùy biến và nâng cấp gói phần mềm vượt chi phí tự làm |
| Thời gian ra giá trị | Cần dùng được trong bao lâu? | Cần dùng ngay | Có thể triển khai theo giai đoạn, bắt đầu từ bản tối thiểu |
| Tích hợp | Phải kết nối với những hệ thống nào? Có API, webhook, xuất dữ liệu không? | Sản phẩm có API và kết nối sẵn với hệ thống hiện có | Cần luồng dữ liệu đặc thù mà sản phẩm không hỗ trợ |
| Quyền kiểm soát dữ liệu | Dữ liệu lưu ở đâu, xuất ra được định dạng nào, ai truy cập? | Nhà cung cấp cho xuất dữ liệu đầy đủ, định dạng mở | Yêu cầu kiểm soát dữ liệu chặt mà SaaS không đáp ứng |
| Phụ thuộc nhà cung cấp (lock-in) | Chuyển sang giải pháp khác sẽ khó và tốn kém đến mức nào? | Có lối ra rõ ràng, chuẩn mở | Mọi lựa chọn mua đều khóa chặt vào một nền tảng |
| Năng lực đội ngũ | Ai sẽ quản lý, vận hành, giám sát giải pháp lâu dài? | Không có đội kỹ thuật nội bộ | Có hoặc sẽ xây năng lực kỹ thuật, hoặc có đối tác dài hạn |
Các thành phần của tổng chi phí sở hữu
Tiêu chuẩn dịch vụ của GOV.UK yêu cầu đội dự án hiểu tổng chi phí sở hữu của công nghệ và giữ khả năng lựa chọn khác trong tương lai. Khi so sánh, hãy liệt kê đủ các khoản sau cho cả hai phương án, thay vì chỉ so giá mua ban đầu:
- Bản quyền hoặc thuê bao, và cách tính khi người dùng, dữ liệu tăng.
- Triển khai: cấu hình, chuyển đổi dữ liệu, đào tạo.
- Phát triển và tùy biến, kể cả công sức nội bộ.
- Tích hợp với hệ thống hiện có và bảo trì kết nối.
- Hạ tầng, giám sát, sao lưu, bảo mật.
- Bảo trì, nâng cấp, sửa lỗi trong suốt vòng đời.
- Thay đổi quy trình và năng suất giảm khi chuyển tiếp.
- Rút lui: xuất dữ liệu, chuyển đổi, chạy song song khi thay hệ thống.
Không thể thuê ngoài rủi ro
GOV.UK nhấn mạnh: dù chọn hướng nào, tổ chức không thể thuê ngoài rủi ro và cần đủ nguồn lực, hiểu biết để quản lý sản phẩm lâu dài. Vì vậy tiêu chí “năng lực đội ngũ” cần được đánh giá trung thực.
Câu hỏi cần hỏi nhà cung cấp
Câu trả lời cho các câu hỏi này nên được ghi vào hợp đồng, không chỉ trong bản chào giá. Xem thêm từng giai đoạn của một dự án trong bài quy trình phát triển phần mềm theo yêu cầu.
Khi mua SaaS hoặc nền tảng low-code
- Chúng tôi có thể xuất toàn bộ dữ liệu ở định dạng nào, bao lâu một lần, có mất phí không?
- Có API công khai không, giới hạn gọi API ra sao, tài liệu có đầy đủ không?
- Dữ liệu được lưu ở đâu, ai trong phía nhà cung cấp có quyền truy cập?
- Chính sách thay đổi giá, thay đổi tính năng và thông báo trước như thế nào?
- Khi chấm dứt hợp đồng, dữ liệu được giữ bao lâu và xóa ra sao?
- Phần cấu hình, quy trình, biểu mẫu chúng tôi tạo trên nền tảng có xuất ra được không?
Khi thuê làm phần mềm theo yêu cầu
- Ai sở hữu mã nguồn, tài liệu thiết kế, tài khoản hạ tầng sau bàn giao?
- Có dùng thư viện, framework độc quyền của bên làm không? Giấy phép thư viện mã nguồn mở là gì?
- Chúng tôi có quyền truy cập kho mã nguồn trong suốt dự án không?
- Đội khác có thể tiếp nhận và phát triển tiếp hệ thống không? (Danh mục bàn giao chi tiết có trong bài quy trình phát triển phần mềm theo yêu cầu.)
Quyền sở hữu mã nguồn và tài sản trí tuệ
Luật Sở hữu trí tuệ Việt Nam (văn bản hợp nhất 11/VBHN-VPQH năm 2022) có hai điều liên quan trực tiếp. Theo khoản 2 Điều 39, tổ chức, cá nhân giao kết hợp đồng với tác giả sáng tạo ra tác phẩm là chủ sở hữu các quyền tại Điều 20 (quyền tài sản) và khoản 3 Điều 19 (quyền công bố tác phẩm), trừ trường hợp có thỏa thuận khác. Theo Điều 41, tổ chức, cá nhân được chuyển giao một, một số hoặc toàn bộ các quyền đó theo thỏa thuận trong hợp đồng là chủ sở hữu quyền tác giả.
Luật số 131/2025/QH15 sửa đổi Luật Sở hữu trí tuệ, có hiệu lực từ 01/4/2026, không sửa hai điều này nhưng sửa khoản 1 Điều 22: chương trình máy tính được bảo hộ như tác phẩm văn học, dù ở dạng mã nguồn hay mã máy, và tác giả với chủ sở hữu quyền tác giả có quyền thỏa thuận bằng văn bản về việc sửa chữa, nâng cấp chương trình.
Cụm từ then chốt là “trừ trường hợp có thỏa thuận khác”. Quyền với mã nguồn, thư viện có sẵn của bên làm, tài liệu thiết kế và dữ liệu đều được xác định theo thỏa thuận trong hợp đồng; hãy ghi rõ cả quyền sửa chữa, nâng cấp sau bàn giao và nhờ luật sư rà soát trước khi ký.
Với SaaS, doanh nghiệp thường chỉ nhận quyền sử dụng, không sở hữu mã nguồn. Điều cần giữ chặt là quyền với dữ liệu của mình; GOV.UK khuyến nghị luôn kiểm soát đầy đủ mọi dữ liệu mình lưu trữ.
Chiến lược rút lui: lập kế hoạch từ ngày đầu
Theo hướng dẫn của GOV.UK, lock-in là khi việc chuyển sang công nghệ hoặc nhà cung cấp khác trở nên khó, mất thời gian và tốn kém không tương xứng. Không phải phụ thuộc nào cũng xấu: đôi khi giá trị của dịch vụ lớn hơn rủi ro, nhưng cần tính trước cách đổi nhà cung cấp và khi nào phải đổi. Với SaaS, nên chọn sản phẩm dùng chuẩn và định dạng mở để xuất dữ liệu được; một nguyên nhân phổ biến khác của lock-in là thiếu người có kỹ năng.
- Ghi rõ trong hợp đồng: định dạng xuất dữ liệu, thời hạn hỗ trợ chuyển đổi khi chấm dứt.
- Định kỳ thử xuất dữ liệu thật, không chỉ tin vào tài liệu.
- Với phần mềm theo yêu cầu: giữ mã nguồn trong kho do doanh nghiệp kiểm soát, có tài liệu triển khai và kiến trúc.
- Giữ tài khoản hạ tầng đám mây, tên miền, chứng thư số đứng tên doanh nghiệp.
- Thiết kế tích hợp qua API, tránh để logic nghiệp vụ nằm rải rác trong cấu hình khó di chuyển.
- Bảo đảm có ít nhất một người phía doanh nghiệp hiểu hệ thống đủ để giám sát nhà cung cấp.
Quy trình 5 bước để ra quyết định
Nếu chọn xây phần lõi, kiến trúc cần đủ chắc để không phải viết lại khi doanh nghiệp lớn lên; xem bài hệ thống SaaS chịu được tăng trưởng. EYC phát triển phần mềm theo yêu cầu và sản phẩm SaaS, trong đó có Early Years Circle cho giáo dục mầm non; vì vậy chúng tôi có lợi ích liên quan khi bàn chủ đề này. Thông tin về dịch vụ xem tại trang phần mềm và SaaS; phạm vi, quyền sở hữu mã nguồn và hỗ trợ được xác định theo thỏa thuận trong hợp đồng.
- Vẽ sơ đồ quy trình hiện tại và nhu cầu người dùng; có thể dùng cách vẽ sơ đồ quy trình trước khi tự động hóa.
- Phân loại từng phần: tiện ích hay chiến lược. Theo Fowler, nên nghiêng về giữ nhóm chiến lược nhỏ.
- Khảo sát sản phẩm có sẵn cho phần tiện ích; thử dùng không tùy biến trước.
- Chấm điểm các phương án bằng bảng tiêu chí, liệt kê đủ thành phần TCO và kế hoạch rút lui.
- Bắt đầu nhỏ: một bản tối thiểu hoặc một giai đoạn thí điểm, rồi mở rộng khi có dữ liệu thực tế.
Câu hỏi thường gặp
Nên thuê làm phần mềm hay mua phần mềm có sẵn?
Nếu quy trình phổ biến và không tạo lợi thế cạnh tranh, mua phần mềm có sẵn thường hợp lý hơn. Nếu quy trình là điểm khác biệt hoặc không có sản phẩm phù hợp, hãy cân nhắc thuê làm phần lõi. Trên thực tế, nhiều doanh nghiệp chọn kết hợp: mua phần tiện ích, xây phần lõi.
Thuê công ty làm phần mềm thì ai sở hữu mã nguồn?
Theo khoản 2 Điều 39 Luật Sở hữu trí tuệ, bên giao kết hợp đồng với tác giả là chủ sở hữu quyền tài sản và quyền công bố tác phẩm, trừ trường hợp có thỏa thuận khác. Vì vậy quyền với mã nguồn được xác định theo hợp đồng; cần ghi rõ và nhờ luật sư rà soát.
Tổng chi phí sở hữu phần mềm gồm những gì?
Gồm bản quyền hoặc thuê bao, triển khai, tùy biến, tích hợp, hạ tầng, bảo trì và nâng cấp, thay đổi quy trình, và chi phí rút lui khi thay hệ thống. Chỉ so giá mua ban đầu thường làm phương án “rẻ” trông rẻ hơn thực tế.
Low-code có thay được phần mềm theo yêu cầu không?
Low-code phù hợp với biểu mẫu, quy trình duyệt, báo cáo có logic vừa phải. Khi logic phức tạp, cấu hình có thể trở nên khó bảo trì và phụ thuộc nền tảng, lúc đó nên đánh giá lại.
Làm sao tránh bị khóa chặt vào một nhà cung cấp phần mềm?
Chọn sản phẩm dùng chuẩn và định dạng mở, ghi rõ quyền xuất dữ liệu trong hợp đồng, thử xuất dữ liệu định kỳ, giữ mã nguồn và tài khoản hạ tầng đứng tên doanh nghiệp.