Thuê Ngoài Phát Triển Phần Mềm: Chọn Mô Hình, Tính Chi Phí Và Chọn Đối Tác 2026

Một giám đốc doanh nghiệp sản xuất gọi báo giá phần mềm quản lý kho ở ba nơi. Ba con số trả về lệch nhau tới mấy lần. Không nơi nào sai, chỉ là mỗi nơi hiểu “phần mềm quản lý kho” theo một phạm vi khác nhau, và không ai hỏi lại cho rõ trước khi ra giá.

Đó là điểm vỡ quen thuộc nhất của việc thuê ngoài phát triển phần mềm tại Việt Nam. Vấn đề hiếm khi nằm ở năng lực kỹ thuật của bên nhận việc. Nó nằm ở chỗ hai bên chưa thống nhất được làm gì, đo bằng gì và ai quyết cái gì.

Nói đơn giản: thuê ngoài phát triển phần mềm là việc bạn giao một phần hoặc toàn bộ công việc xây dựng phần mềm cho một đơn vị bên ngoài, thay vì tự tuyển và nuôi đội kỹ thuật trong công ty. Nghe thì đơn giản, nhưng bên dưới nó là bốn mô hình hợp tác khác nhau, ba cách tính tiền khác nhau, và một loạt điều khoản mà nếu bỏ qua thì đến lúc bàn giao mới phát hiện ra là mình không sở hữu chính hệ thống mình vừa trả tiền.

Bài này viết cho người đang phải ra quyết định đó: chọn mô hình nào, tiền đi đâu, kiểm chứng đối tác thế nào, hợp đồng phải chốt gì, và vì sao nhiều dự án thuê ngoài vẫn vỡ dù cả hai bên đều có thiện chí. Savvycom làm việc này từ năm 2009 cho khách hàng tại Việt Nam, Nhật Bản, Hàn Quốc, Thái Lan, Úc và Mỹ, nên phần lớn ví dụ trong bài lấy từ dự án thật, kèm phạm vi cụ thể.

1. Thuê ngoài phát triển phần mềm là gì và khác gì mua phần mềm có sẵn

Thuê ngoài là bạn trả tiền cho một đội bên ngoài để họ xây hoặc vận hành phần mềm theo yêu cầu của bạn. Mua phần mềm có sẵn là bạn trả tiền thuê bao để dùng một sản phẩm đã được xây cho hàng nghìn công ty khác. Chọn sai giữa hai hướng này là khoản lãng phí lớn nhất và cũng dễ tránh nhất.

Ranh giới thực ra khá rõ. Nếu việc bạn cần làm giống với phần lớn doanh nghiệp khác, chẳng hạn kế toán, chấm công, gửi email marketing, thì gần như chắc chắn đã có sản phẩm sẵn rẻ hơn nhiều lần so với việc tự xây. Ngược lại, nếu quy trình của bạn là thứ tạo ra lợi thế cạnh tranh, hoặc đặc thù đến mức không phần mềm sẵn nào chịu uốn theo, thì tự xây mới đáng.

Có một trường hợp thứ ba hay bị bỏ qua: bạn đã mua phần mềm sẵn nhưng cần nối nó với hệ thống khác, cần một lớp giao diện riêng, hoặc cần chuyển dữ liệu cũ sang. Đây là phần việc thuê ngoài hợp lý nhất, vì phạm vi hẹp và kết quả đo được ngay.

Một cách hỏi nhanh trước khi quyết: nếu ngày mai đối thủ của bạn cũng mua đúng phần mềm đó, bạn còn lại lợi thế gì? Câu trả lời cho biết nên mua hay nên xây.

2. Khi nào nên thuê ngoài và khi nào không nên

Thuê ngoài hợp lý khi bạn cần năng lực kỹ thuật mà việc tuyển và giữ người trong nước không đáp ứng kịp, khi khối lượng công việc có lúc lên lúc xuống, hoặc khi bạn cần đi nhanh hơn tốc độ xây đội nội bộ. Nó không hợp lý khi bạn chưa biết mình muốn gì.

Ba tình huống thuê ngoài thường mang lại kết quả tốt:

• Bạn cần chuyên môn không có sẵn trong công ty. Một ngân hàng có đội IT mạnh về vận hành nhưng chưa từng làm ứng dụng di động cho khách hàng cuối. Tuyển và đào tạo mất một đến hai năm. Thuê một đội đã làm việc đó nhiều lần thì rút xuống còn vài tháng.
• Khối lượng công việc không đều. Giai đoạn xây dựng cần mười người, giai đoạn duy trì chỉ cần hai. Nuôi mười người quanh năm để dùng hết công suất trong sáu tháng là cách đốt tiền chậm.
• Bạn có hạn chót thị trường không dời được. Một đối tác đã cam kết ngày tích hợp, một mùa bán hàng sắp tới, một quy định sắp có hiệu lực. Đội bên ngoài đã có sẵn quy trình và nguồn lực nên bắt đầu triển khai nhanh hơn.

Và ba tình huống nên dừng lại trước khi ký:

• Bạn chưa mô tả được kết quả mong muốn bằng lời của chính mình. Nếu bạn chưa nói được “hệ thống này phải giúp giảm thời gian xử lý một đơn hàng từ X xuống Y”, thì mọi báo giá bạn nhận đều là phỏng đoán. Nên bỏ tiền cho một giai đoạn khảo sát ngắn trước, thay vì ký cả dự án.
• Không ai bên bạn có thẩm quyền chốt yêu cầu hằng tuần. Đây là nguyên nhân làm chậm dự án nhiều hơn cả năng lực lập trình. Đội bên ngoài dừng chờ quyết định, đồng hồ vẫn chạy, tiền vẫn tính.
• Phần mềm đó chính là sản phẩm cốt lõi và bạn định giao trọn gói mãi mãi. Thuê ngoài để khởi động thì tốt. Nhưng nếu đây là thứ nuôi sống công ty, sớm muộn bạn vẫn cần người trong nhà hiểu nó tường tận. Hợp đồng nên có điều khoản chuyển giao ngay từ đầu.

Một điểm cần nói thẳng: nếu doanh nghiệp bạn chỉ cần số hóa vài biểu mẫu và luồng duyệt đơn giản, các nền tảng dựng ứng dụng không cần lập trình hiện nay đủ dùng, và bạn không cần thuê một công ty phần mềm. Việc thừa nhận điều đó tiết kiệm cho bạn nhiều hơn bất kỳ mẹo đàm phán nào.

3. Bốn mô hình thuê ngoài và cách chọn đúng mô hình

Có bốn cách hợp tác phổ biến: trọn gói theo dự án, đội chuyên trách theo tháng, bổ sung nhân sự, và trung tâm phát triển riêng. Chọn giữa chúng không dựa vào ngân sách mà dựa vào hai câu hỏi: phạm vi công việc của bạn đã đứng yên chưa, và bên bạn có ai đủ sức chốt yêu cầu mỗi tuần hay không.

Hai mô hình đầu chiếm phần lớn hợp đồng tại Việt Nam. Mô hình thứ ba phù hợp với doanh nghiệp đã có khối công nghệ riêng. Mô hình thứ tư, thường gọi là ODC, là mức cam kết cao nhất và cũng cho hiệu quả cao nhất khi đủ khối lượng việc; nếu bạn đang cân nhắc hướng này, bài offshore development center là gì phân tích riêng cách vận hành và điểm hòa vốn của nó.

Sai lầm hay gặp là chọn trọn gói cho một sản phẩm còn đang tìm hướng. Bạn ký một phạm vi cố định cho thứ mà chính bạn còn chưa chắc, rồi mỗi lần thay đổi lại phải đàm phán. Sau ba bốn lần như vậy, quan hệ hai bên chuyển từ hợp tác sang phòng thủ, và chất lượng đi xuống theo.

4. Chi phí thuê ngoài phát triển phần mềm được tính thế nào

Có ba cách tính tiền: một giá cho một phạm vi đã chốt, tính theo thời gian làm việc thực tế, và tính theo tháng theo từng vai trò trong đội. Khoảng giá trải rất rộng vì phụ thuộc vào vai trò, thâm niên và độ phức tạp nghiệp vụ. Con số chỉ chốt được sau khi khảo sát, và bất kỳ ai báo giá chính xác trước khi hỏi kỹ đều đang đoán.

Những khoảng trên là mức tham khảo cho thị trường Việt Nam, không phải báo giá. Chênh lệch giữa cận dưới và cận trên rất lớn, và đó là thực tế của ngành chứ không phải cách tránh trả lời câu hỏi: một lập trình viên mới vào nghề và một kiến trúc sư giải pháp mười năm kinh nghiệm không thể cùng một mức.

Điều thực sự đẩy chi phí lên thường không phải số lượng tính năng. Bốn thứ sau đây tốn tiền hơn hầu hết doanh nghiệp dự tính:

• Tích hợp với hệ thống cũ. Nối phần mềm mới vào một hệ thống lõi mười năm tuổi, tài liệu thiếu, người viết ra nó đã nghỉ. Đây là hạng mục hay vỡ dự toán nhất.
• Chuyển dữ liệu cũ sang hệ thống mới. Dữ liệu thật luôn bẩn hơn dữ liệu mẫu. Việc làm sạch và đối chiếu thường chiếm nhiều thời gian hơn phần lập trình.
• Yêu cầu bảo mật và tuân thủ. Ngành tài chính, y tế hoặc hệ thống xử lý dữ liệu cá nhân đòi hỏi kiểm thử, ghi vết và quy trình duyệt chặt hơn, kéo theo thời gian và chi phí.
• Đổi yêu cầu sau khi đã chốt phạm vi. Đây không phải lỗi của bên nào, bởi thị trường thay đổi là điều bình thường. Nhưng nếu đã ký trọn gói thì mỗi lần đổi là một lần đàm phán.

Ngoài giá xây dựng, còn hai khoản hay bị quên khi lập ngân sách: chi phí hạ tầng vận hành hằng tháng, và chi phí bảo trì sau bàn giao. Phần mềm không phải tài sản mua một lần. Nó cần cập nhật thư viện, vá lỗi bảo mật và sửa lỗi phát sinh, và khoản này nên được ghi vào ngân sách năm ngay từ đầu thay vì phát hiện ra sau sáu tháng.

5. Kiểm chứng đối tác: bảy thứ nên xem trước khi ký

Hồ sơ năng lực nào cũng đẹp. Thứ phân biệt đối tác làm được với đối tác chỉ bán được là khả năng trả lời cụ thể về những dự án đã hỏng và cách họ xử lý. Bảy điểm dưới đây kiểm chứng được bằng một buổi làm việc, không cần chờ đến lúc ký.

1. Dự án đã làm trong đúng ngành của bạn. Không phải để đẹp hồ sơ, mà vì nghiệp vụ ngân hàng, y tế hay logistics có những ràng buộc mà đội chưa từng làm sẽ mất vài tháng để hiểu, và bạn là người trả tiền cho vài tháng đó.
2. Người sẽ thực sự làm dự án của bạn. Đề nghị gặp trưởng nhóm kỹ thuật, không chỉ gặp bộ phận kinh doanh. Câu hỏi tốt để hỏi: dự án gần nhất của anh chị trễ hạn vì lý do gì và đã xử lý thế nào.
3. Cách họ ước lượng công việc. Đối tác đưa ra một con số tròn trịa ngay trong buổi đầu là dấu hiệu xấu. Đối tác tốt sẽ hỏi ngược lại nhiều câu, và thường đề xuất một giai đoạn khảo sát có phí trước khi cam kết con số cuối.
4. Quy trình kiểm thử và bàn giao. Ai viết kịch bản kiểm thử, bạn nghiệm thu theo tiêu chí nào, lỗi sau bàn giao được sửa trong bao lâu và miễn phí đến khi nào.
5. Cách họ giữ người. Đội thay người liên tục thì tri thức dự án mất theo. Hỏi thẳng: tỷ lệ nghỉ việc năm ngoái thế nào, và nếu người chủ chốt rời đi thì bàn giao ra sao.
6. Chuẩn bảo mật đang áp dụng. Chứng nhận là một phần, nhưng quan trọng hơn là cách họ trả lời câu hỏi cụ thể: mã nguồn của tôi nằm ở đâu, ai truy cập được, nhân viên rời công ty thì quyền truy cập bị thu hồi trong bao lâu.
7. Khách hàng cũ nói gì. Xin liên hệ của một khách hàng đã kết thúc hợp đồng, không chỉ khách đang dùng. Cách một đối tác chia tay nói lên nhiều điều hơn cách họ chào hàng.

Nếu bạn cần một điểm khởi đầu để lập danh sách rút gọn, bài top 10 công ty outsourcing công nghệ tại Việt Nam tổng hợp các đơn vị lớn trong nước kèm thế mạnh từng bên, còn bài 10 tiêu chí lựa chọn đối tác IT outsourcing đi sâu hơn vào phần chấm điểm khi bạn đã có vài lựa chọn để so.

6. Hợp đồng cần chốt gì trước khi ký

Năm điều khoản quyết định việc bạn có thực sự sở hữu thứ mình trả tiền hay không: quyền sở hữu mã nguồn, phạm vi và cách xử lý thay đổi, tiêu chí nghiệm thu, trách nhiệm về dữ liệu cá nhân, và điều kiện dừng hợp tác. Thiếu điều khoản cuối là lý do nhiều doanh nghiệp bị kẹt với một đối tác không còn phù hợp.

• Quyền sở hữu mã nguồn và tài sản trí tuệ. Ghi rõ toàn bộ mã nguồn, tài liệu thiết kế và tài khoản hạ tầng thuộc về bạn sau khi thanh toán đủ. Ghi rõ cả phần thư viện mã nguồn mở được dùng và giấy phép của chúng, vì có loại giấy phép ràng buộc cách bạn thương mại hóa sản phẩm về sau.
• Phạm vi và cơ chế xử lý thay đổi. Không hợp đồng nào giữ nguyên phạm vi đến cuối. Thứ cần chốt không phải là "sẽ không đổi" mà là "đổi thì xử lý theo quy trình nào, ai duyệt, tính tiền ra sao".
• Tiêu chí nghiệm thu. Viết bằng câu kiểm chứng được, không viết bằng tính từ. "Hệ thống chạy mượt" không nghiệm thu được. "Trang danh sách đơn hàng tải xong dưới 2 giây với 10.000 bản ghi" thì có.
• Bảo mật và dữ liệu cá nhân. Từ ngày 1/1/2026, Việt Nam áp dụng Luật Bảo vệ dữ liệu cá nhân thay cho nghị định cũ. Nếu hệ thống của bạn xử lý dữ liệu khách hàng, hợp đồng cần nêu rõ bên nào là bên kiểm soát dữ liệu, đối tác được xử lý dữ liệu tới đâu, dữ liệu lưu ở đâu và xóa thế nào khi kết thúc.
• Điều kiện dừng và bàn giao. Báo trước bao nhiêu ngày, bàn giao gồm những gì, đối tác hỗ trợ chuyển giao trong bao lâu. Điều khoản này ít khi dùng đến, nhưng lúc cần thì nó là thứ duy nhất bảo vệ bạn.

Một mẹo nhỏ có giá trị lớn: yêu cầu quyền truy cập kho mã nguồn ngay từ ngày đầu, kể cả khi bạn không đọc được code. Việc mã nguồn được đẩy lên kho của bạn hằng ngày, thay vì nằm ở máy đối tác đến lúc bàn giao, loại bỏ gần như toàn bộ rủi ro tệ nhất.

7. Vận hành để dự án không vỡ tiến độ

Phần lớn dự án thuê ngoài trễ hạn không vì lập trình chậm mà vì vòng phản hồi chậm. Đội bên ngoài gửi bản chạy thử, bên bạn hai tuần sau mới xem, phản hồi lại thì công việc đã đi tiếp. Nhịp làm việc rõ ràng quan trọng hơn công cụ quản lý dự án.

Bốn việc nên thiết lập ngay tuần đầu:

• Một người chịu trách nhiệm bên bạn. Người này không cần biết lập trình nhưng phải có quyền quyết định và trả lời trong vòng một ngày làm việc. Đây là yếu tố ảnh hưởng đến tiến độ mạnh nhất trong toàn bộ danh sách này.
• Chu kỳ bàn giao ngắn. Hai tuần một lần có bản chạy được để xem, thay vì chờ đến cuối dự án. Bạn phát hiện hiểu sai sớm, và sửa sớm luôn rẻ hơn.
• Một chỗ duy nhất để ghi yêu cầu. Yêu cầu trao đổi qua tin nhắn riêng, họp miệng và email lẫn lộn là nguồn gốc của phần lớn tranh cãi về phạm vi sau này.
• Số đo trước khi bắt đầu. Ghi lại hiện trạng: một đơn hàng đang xử lý mất bao lâu, mỗi tháng tốn bao nhiêu giờ công. Không có đường cơ sở thì đến lúc nghiệm thu không ai chứng minh được dự án có hiệu quả hay không.

Khoảng cách địa lý và múi giờ ít gây vấn đề hơn nhiều người lo. Vấn đề thật nằm ở chỗ hai bên hiểu khác nhau về cùng một câu yêu cầu. Biện pháp khắc phục ít tốn kém nhất là đề nghị đội bên ngoài mô tả lại yêu cầu bằng ngôn ngữ của họ trước khi bắt tay vào triển khai.

8. Năm lý do khiến dự án thuê ngoài thất bại

Dự án hỏng hiếm khi vì một sự cố lớn. Nó hỏng dần qua những quyết định nhỏ ở giai đoạn đầu, và đến lúc nhìn ra thì chi phí sửa đã cao hơn chi phí làm lại.

1. Chọn theo giá thấp nhất. Báo giá thấp bất thường thường đến từ việc hiểu phạm vi hẹp hơn thực tế. Phần chênh sẽ quay lại dưới dạng phụ lục, hoặc dưới dạng một sản phẩm phải viết lại sau một năm.
2. Không ai bên trong đủ hiểu hệ thống. Giao hết cho đối tác và không cử ai theo sát, đến khi cần đổi đối tác thì không ai giải thích được hệ thống hoạt động ra sao.
3. Yêu cầu viết bằng tính từ. "Giao diện thân thiện", "hệ thống ổn định", "chạy nhanh". Ba cụm này không nghiệm thu được, và chúng là nguồn gốc của những cuộc tranh cãi kéo dài lúc bàn giao.
4. Bỏ qua giai đoạn khảo sát. Muốn tiết kiệm vài tuần đầu, ký thẳng vào phần xây dựng. Rồi mất vài tháng ở giữa dự án để làm đúng việc lẽ ra nên làm ở đầu.
5. Không có kế hoạch cho ngày sau bàn giao. Hệ thống lên chạy, đối tác rút, không ai được đào tạo vận hành, không ai theo dõi lỗi. Sau vài tháng hệ thống bị bỏ, và khoản đầu tư mất trắng.

Điểm chung của cả năm: đều xuất phát từ việc muốn đi nhanh ở đúng những khâu không nên nhanh.

9. Savvycom làm việc này thế nào

Savvycom nhận các dự án phần mềm, dữ liệu và AI cho doanh nghiệp tại Việt Nam và các thị trường APAC, Nhật Bản, Hàn Quốc, Úc, Mỹ từ năm 2009. Cách làm quen thuộc là bắt đầu bằng một giai đoạn khảo sát có phạm vi rõ, chốt số đo trước khi xây, rồi mới cam kết con số cuối.

Ba ví dụ dưới đây khác nhau về mô hình hợp tác, nên đọc để thấy cùng một nhu cầu có thể giải bằng những cách rất khác nhau:

• Ngân hàng với 192 chi nhánh cần hiện đại hóa ứng dụng cho khách hàng. Bài toán không nằm ở giao diện mà ở hệ thống lõi cũ và lượng dữ liệu phải chuyển sang nền tảng mới mà không được gián đoạn giao dịch. Cách giải là tách hệ thống thành các phần độc lập và đưa lên từng giai đoạn thay vì chuyển đổi một lần. Chi tiết trong case study ngân hàng số tại Campuchia.
• Nền tảng bảo hiểm số cần giữ nhịp ra mắt tính năng đã cam kết với đối tác. Vấn đề của RAB là lịch phát hành không dời được, trong khi năng lực kỹ thuật cho một mảng cụ thể chưa đủ. Cách giải là bổ sung đúng phần năng lực còn thiếu và cho đội dự án vào guồng cùng quy trình sẵn có của khách. Chi tiết trong case study RAB InsurTech.
• Doanh nghiệp logistics ngập trong việc rà soát hợp đồng thủ công. Mỗi hợp đồng phải đọc tay để rút ra điều khoản, thời gian dài và dễ sót. Cách giải là để máy đọc và trích xuất trước, chuyên viên chỉ duyệt phần máy đánh dấu nghi ngờ. Kết quả sau 3 tháng: thời gian rà soát giảm khoảng một nửa, độ chính xác trích xuất đạt 95%. Chi tiết trong case study AI phân tích hợp đồng logistics.

Điểm chung của ba dự án không phải công nghệ. Cả ba đều bắt đầu bằng việc viết ra bài toán của khách bằng ngôn ngữ nghiệp vụ, kèm số đo hiện trạng, trước khi bàn đến giải pháp kỹ thuật.

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

Thuê ngoài phát triển phần mềm có rẻ hơn tự tuyển đội nội bộ không?

Rẻ hơn ở giai đoạn xây dựng và khi khối lượng công việc không đều, vì bạn không gánh chi phí tuyển dụng, đào tạo và duy trì đội khi việc ít. Nhưng nếu phần mềm là sản phẩm cốt lõi chạy dài hạn nhiều năm, tổng chi phí sở hữu thường nghiêng về đội nội bộ.

Mã nguồn thuộc về ai sau khi dự án kết thúc?

Thuộc về bên thuê nếu hợp đồng ghi rõ như vậy và bạn đã thanh toán đủ. Đây là điều khoản phải kiểm tra trước khi ký, không mặc định. Nên yêu cầu thêm quyền truy cập kho mã nguồn ngay từ ngày đầu dự án thay vì chờ tới lúc bàn giao.

Một dự án phần mềm thuê ngoài mất bao lâu?

Một ứng dụng gọn với phạm vi rõ thường mất khoảng ba đến sáu tháng từ khảo sát đến bản chạy thật. Hệ thống doanh nghiệp có nhiều tích hợp và chuyển đổi dữ liệu thường từ sáu tháng trở lên. Giai đoạn khảo sát ban đầu chiếm vài tuần nhưng quyết định phần lớn tiến độ về sau.

Làm sao biết báo giá nhận được là hợp lý?

So sánh phạm vi trước, so sánh giá sau. Yêu cầu mỗi bên liệt kê rõ hạng mục, số người, thời gian và giả định họ đang dựa vào. Hai báo giá lệch nhau nhiều lần thường không phải vì giá mà vì hai bên hiểu công việc khác nhau.

Doanh nghiệp nhỏ có nên thuê ngoài phát triển phần mềm không?

Nên, nếu việc cần làm là đặc thù và không có sản phẩm sẵn phù hợp. Nếu chỉ cần số hóa vài biểu mẫu và luồng duyệt đơn giản, các nền tảng dựng ứng dụng không cần lập trình sẽ rẻ và nhanh hơn nhiều so với việc thuê một công ty phần mềm.

Bước tiếp theo cho doanh nghiệp của bạn

Nếu bạn đọc đến đây và trong đầu đã có một hệ thống cần xây hoặc một mảng việc kỹ thuật đang thiếu người, việc đáng làm tiếp không phải là gọi báo giá ngay. Hãy viết ra ba thứ trước: hệ thống này phải giúp thay đổi con số nào, hiện trạng con số đó đang là bao nhiêu, và ai bên bạn sẽ là người chốt yêu cầu mỗi tuần. Có ba thứ đó rồi thì mọi báo giá bạn nhận mới so sánh được với nhau.