Outsourcing bảo trì phần mềm là việc giao phần vận hành sau khi sản phẩm đã go-live — sửa lỗi, vá bảo mật, cải tiến nhỏ và giám sát hệ thống — cho một đội kỹ thuật bên ngoài. Đây là phần ít được nhắc tới nhất của vòng đời phần mềm, nhưng lại chiếm phần lớn tổng chi phí sở hữu.
Bài viết này trình bày phạm vi công việc thực sự bao gồm những gì, cách các nhà cung cấp báo giá năm 2026, những điều khoản SLA quyết định chất lượng, và một kế hoạch bàn giao 30 ngày có thể chạy mà không gây gián đoạn dịch vụ.
Những điểm chính
- Bảo trì là bốn loại công việc khác nhau, không phải một: sửa lỗi, thích ứng, hoàn thiện và phòng ngừa.
- Hãy lập ngân sách theo tỷ lệ chi phí xây dựng ban đầu — thông lệ phổ biến là 15–25% mỗi năm.
- SLA mới quyết định chất lượng, không phải đơn giá giờ công: mức độ nghiêm trọng, thời gian phản hồi và đường leo thang mới là thứ tạo ra khác biệt.
- Rủi ro nằm ở khâu bàn giao, không nằm ở việc viết code. Hãy dành 3–6 tuần chạy song song trước khi đội cũ rời đi.
- Công việc phòng ngừa là hạng mục rẻ nhất bạn từng duyệt, và cũng là hạng mục bị cắt đầu tiên.
Outsourcing bảo trì phần mềm thực chất bao gồm những gì
Tiêu chuẩn quốc tế cho mảng này, ISO/IEC 14764, chia bảo trì phần mềm thành bốn nhóm. Một hợp đồng outsourcing bảo trì phần mềm nghiêm túc cần gọi tên đủ bốn nhóm và ghi rõ ai trả tiền cho nhóm nào.
| Loại | Nội dung | Tình huống kích hoạt |
|---|---|---|
| Sửa lỗi (corrective) | Xử lý lỗi phát sinh trên môi trường thật | Báo lỗi, giao dịch thất bại, sự cố dừng dịch vụ |
| Thích ứng (adaptive) | Giữ hệ thống chạy được khi môi trường thay đổi | Nâng cấp hệ điều hành, trình duyệt mới, API thanh toán đổi phiên bản |
| Hoàn thiện (perfective) | Cải tiến nhỏ về tính năng và hiệu năng | Phản hồi người dùng, truy vấn chậm, yêu cầu báo cáo mới |
| Phòng ngừa (preventive) | Giảm nguy cơ hỏng hóc trong tương lai | Nâng cấp thư viện, refactor, bổ sung test |
Phần lớn tranh cãi bắt đầu từ đây. Khách hàng hiểu “bảo trì” là tất cả mọi thứ; nhà cung cấp lại chỉ báo giá phần sửa lỗi. Ghi đủ bốn nhóm vào phụ lục phạm vi công việc là cách rẻ nhất để tránh chuyện đó.
Những gì thường nằm ngoài phạm vi
Module mới, thiết kế lại giao diện, chuyển nền tảng và tích hợp với một đối tác thứ ba mới đều là dự án, không phải bảo trì. Chúng cần đi qua quy trình change request riêng, có ước lượng và tiến độ riêng.
Hợp đồng tốt sẽ đặt một ngưỡng — ví dụ mọi yêu cầu vượt 16 hoặc 24 giờ công sẽ ra khỏi gói retainer. Không có ranh giới đó, các yêu cầu nhỏ sẽ âm thầm ăn hết ngân sách hỗ trợ.
Vì sao các đội chọn outsourcing bảo trì phần mềm sau khi ra mắt
Đội xây dựng không phải đội phù hợp cho năm thứ hai
Kỹ sư làm sản phẩm có chi phí cao và muốn ra tính năng mới. Bắt họ dành một phần ba mỗi sprint để xử lý ticket từ hai năm trước là cách nhanh nhất để mất người. Bảo trì cần một hồ sơ năng lực khác: kỹ lưỡng, chú trọng tài liệu, quen làm việc trên code của người khác.
Tách hai vai trò này thường mới là lý do thật sự khiến doanh nghiệp chọn outsourcing bảo trì phần mềm. Đội nội bộ giữ lộ trình sản phẩm; đội bên ngoài giữ hệ thống chạy ổn định và hấp thụ toàn bộ luồng việc phát sinh.
Vá bảo mật là việc không bao giờ dừng
Lỗ hổng được công bố liên tục trên National Vulnerability Database, và phần lớn rủi ro trong OWASP Top 10 đi vào production qua những thư viện cả năm không ai nâng cấp.
Cái giá của việc bỏ qua không hề trừu tượng. Báo cáo Cost of a Data Breach 2024 của IBM ghi nhận chi phí trung bình toàn cầu cho một vụ rò rỉ dữ liệu là 4,88 triệu USD. Một gói retainer có rà soát thư viện hằng tháng là khoản bảo hiểm rẻ so với con số đó.
Phủ ngoài giờ hành chính
Nếu người dùng của bạn ở châu Âu hay Mỹ còn đội kỹ thuật thì không, vẫn phải có người trả lời lúc 2 giờ sáng. Một đội bảo trì phân tán biến việc đó từ nỗ lực cá nhân thành lịch trực — và đây cũng là lý do chênh lệch múi giờ, nếu tổ chức tốt, là lợi thế chứ không phải chi phí.
Chi phí outsourcing bảo trì phần mềm năm 2026
Có ba mô hình thương mại phổ biến. Các hợp đồng trưởng thành thường kết hợp hai mô hình đầu: một khoản retainer cố định bảo đảm sự sẵn sàng, cộng thêm quỹ giờ tính theo thực tế cho các yêu cầu cải tiến lớn hơn.
| Mô hình | Cách vận hành | Phù hợp khi | Cần lưu ý |
|---|---|---|---|
| Retainer hằng tháng | Phí cố định cho một gói giờ và một SLA cam kết | Sản phẩm ổn định, lượng ticket dự đoán được | Giờ không dùng hết bị hủy theo tháng |
| Time & materials | Trả theo số giờ làm thực tế | Lượng việc thất thường hoặc ít | Không có cam kết thời gian phản hồi nếu không mua thêm |
| Theo ticket / theo kết quả | Tính giá theo sự cố đã xử lý hoặc theo mức nghiêm trọng | Khối lượng lớn, phân loại rõ ràng | Dễ tạo động cơ đóng ticket thay vì xử lý gốc rễ |
Cách lập ngân sách phổ biến nhất là 15–25% chi phí xây dựng ban đầu mỗi năm. Một sản phẩm tốn 200.000 USD để làm sẽ cần khoảng 30.000–50.000 USD hỗ trợ hằng năm. Tăng tỷ lệ này với ngành có quản lý chặt và hệ thống nhiều tích hợp; giảm xuống với hệ thống nhỏ, ít người dùng, đã kiểm thử tốt.
Đơn giá thì khác nhau nhiều theo khu vực và cấp độ kỹ sư. Bảng giá outsourcing phần mềm Việt Nam 2026 của Tinasoft liệt kê các mức hiện hành cho kỹ sư hỗ trợ và phát triển, đủ để bạn đối chiếu bất kỳ báo giá nào nhận được.
Những khoản dễ bị bỏ sót
- Phụ phí trực 24/7 — phủ toàn thời gian đắt hơn đáng kể so với 8×5. Hãy xác định đúng nhu cầu thật.
- Môi trường và công cụ — môi trường staging, license giám sát và phút CI hiếm khi nằm trong giá chào ban đầu.
- Chuyển giao tri thức — tháng đầu là giai đoạn làm quen, năng suất thấp hơn. Đừng tin bên nào hứa ngược lại.
- Nợ kỹ thuật tích lũy — những lối tắt để lại làm chậm mọi ticket. Chúng tôi đã phân tích chi phí lũy tiến này trong bài về nợ kỹ thuật khi outsourcing phần mềm.
Những điều khoản SLA quyết định thành bại
Một SLA không định nghĩa mức độ nghiêm trọng chỉ là trang trí. Hãy mô tả các mức bằng ngôn ngữ nghiệp vụ — “không thanh toán được” dễ hiểu hơn “P1” — và gắn hai đồng hồ riêng cho mỗi mức: thời gian phản hồi đầu tiên và thời gian khắc phục hoặc có phương án thay thế.
| Mức | Ví dụ | Phản hồi đầu | Mục tiêu khắc phục |
|---|---|---|---|
| S1 — Nghiêm trọng | Dịch vụ dừng, thanh toán lỗi, dữ liệu có rủi ro | 15–30 phút, 24/7 | 4 giờ |
| S2 — Cao | Tính năng chính hỏng, không có cách thay thế | 2 giờ làm việc | 1–2 ngày làm việc |
| S3 — Trung bình | Tính năng suy giảm, vẫn có cách thay thế | 1 ngày làm việc | Bản phát hành kế tiếp |
| S4 — Thấp | Lỗi hiển thị, yêu cầu nhỏ | 2 ngày làm việc | Đưa vào backlog |
Còn ba điều khoản nữa nên tranh luận kỹ trước khi ký. Thứ nhất, ai là người phân loại mức độ — nên là khách hàng, và nhà cung cấp có quyền phản biện. Thứ hai, cách đo: hệ thống ticket là nguồn dữ liệu duy nhất, báo cáo gửi hằng tháng dù có ai hỏi hay không.
Thứ ba là điều khoản kết thúc. Ghi rõ thời gian báo trước, danh mục tài liệu bàn giao và khẳng định toàn bộ mã nguồn, thông tin đăng nhập, tài liệu thuộc về bạn. Việc kiểm soát truy cập và sở hữu trí tuệ cần được xử lý cẩn thận như trong hợp đồng phát triển — xem thêm bài về bảo mật khi outsourcing phần mềm.
Kế hoạch bàn giao 30 ngày cho outsourcing bảo trì phần mềm
Chuyển giao là chỗ các hợp đồng dạng này hay đổ vỡ. Vấn đề hiếm khi nằm ở code, mà ở bước triển khai không ai ghi lại và ở một người duy nhất biết vì sao cron job chạy lúc 03:07. Hãy coi bàn giao là một dự án có người chịu trách nhiệm riêng.
Tuần 1 — Kiểm kê
- Repository, nhánh, pipeline build và quy trình phát hành
- Các môi trường, tài khoản hosting, DNS, chứng chỉ và ngày hết hạn
- Dịch vụ bên thứ ba, license và ai đang đứng tên thanh toán
- Ticket đang mở và lịch sử sự cố 6–12 tháng gần nhất
Tuần 2 — Quan sát song song
- Đội mới quan sát đội hiện tại xử lý ticket thật
- Viết runbook cho năm loại sự cố xuất hiện nhiều nhất
- Rà lại giám sát và cảnh báo: cái gì kêu, kêu cho ai, và cái gì đang bị bỏ qua
Tuần 3 — Đổi vai
- Đội mới nhận ticket thật, đội cũ review từng thay đổi
- Đội mới tự thực hiện trọn vẹn một lần triển khai
- Diễn tập rollback ít nhất một lần trên môi trường không phải production
Tuần 4 — Chuyển giao có kiểm soát
- Bắt đầu tính SLA; đo thời gian phản hồi ngay từ ngày đầu
- Đổi toàn bộ credential và thu hồi quyền truy cập của đội cũ vào một ngày ấn định
- Thống nhất danh sách việc phòng ngừa cho quý đầu tiên
Nếu đội cũ không còn hỗ trợ được, hãy kéo dài tuần 1 thay vì rút ngắn tuần 3. Việc tìm hiểu một hệ thống không có tài liệu vốn chậm, và cố ép tiến độ chỉ đẩy phần chậm đó sang sự cố production đầu tiên.
Cách Tinasoft làm outsourcing bảo trì phần mềm
Tinasoft phát triển phần mềm từ Việt Nam từ năm 2018. Hiện chúng tôi có hơn 300 nhân sự, đã hoàn thành 300+ dự án cho khoảng 100 khách hàng tại Nhật Bản, Hàn Quốc, Úc, Singapore và châu Âu.
Bảo trì chiếm một phần lớn khối lượng công việc đó, vì phần lớn khách hàng ở lại với chúng tôi rất lâu sau bản phát hành đầu tiên. Tỷ lệ giữ chân nhân sự trên 90% là lý do thực tế giúp vẫn đúng những người đó trả lời được câu hỏi về hệ thống sau ba năm.
Các hợp đồng hỗ trợ của chúng tôi dựa trên một khung đơn giản: một đội có tên cụ thể thay vì hàng đợi vô danh, SLA bằng văn bản với định nghĩa mức độ thống nhất từ đầu, báo cáo hằng tháng về ticket – thời gian phản hồi – việc phòng ngừa đã làm, và một khoản retainer cố định kèm quy trình change request minh bạch cho phần lớn hơn.
Với đội cần cả hỗ trợ lẫn phát triển tiếp, cấu trúc này mở rộng thành một trung tâm phát triển offshore (ODC) riêng, nơi bảo trì và lộ trình sản phẩm nằm chung một hợp đồng.
Câu hỏi thường gặp về outsourcing bảo trì phần mềm
Chi phí bảo trì phần mềm mỗi năm khoảng bao nhiêu?
Hãy dự trù 15–25% chi phí xây dựng ban đầu mỗi năm. Retainer cho một ứng dụng doanh nghiệp nhỏ thường bắt đầu ở mức vài nghìn USD/tháng; hệ thống phức tạp, có ràng buộc pháp lý hoặc chạy 24/7 sẽ cao hơn nhiều. Xem bảng giá 2026 để biết mức hiện hành.
Có thể thuê bảo trì phần mềm do bên khác xây dựng không?
Có, và đây là tình huống phổ biến nhất. Điều kiện là phải có giai đoạn khảo sát nghiêm túc — thường hai đến bốn tuần đọc code, dựng tài liệu và lập bản đồ môi trường trước khi cam kết bất kỳ SLA nào.
Bảo trì và hỗ trợ khác nhau thế nào?
Hỗ trợ là cửa trước: tiếp nhận, phân loại và trả lời người dùng. Bảo trì là phần kỹ thuật phía sau: sửa, vá, nâng cấp và cải thiện mã nguồn. Hầu hết hợp đồng gộp cả hai, nhưng đây là hai bộ kỹ năng khác nhau và cần bố trí người khác nhau.
Giao bảo trì ra ngoài có làm mất quyền kiểm soát sản phẩm không?
Không, nếu hợp đồng được viết đúng. Giữ repository, tài khoản cloud và tên miền đứng tên công ty bạn, yêu cầu tài liệu là một hạng mục bàn giao, và quy định rõ quy trình kết thúc. Về nguyên tắc, nhà cung cấp phải luôn có thể thay thế được.
Hợp đồng bảo trì nên ký bao lâu?
Mười hai tháng là mức phổ biến, kèm thời gian báo trước 30–90 ngày. Kỳ hạn ngắn hơn thường không đủ bù chi phí làm quen cho cả hai bên; kỳ hạn dài hơn nên có điều khoản rà soát phạm vi, hiệu quả SLA và giá hằng năm.
Bắt đầu từ đâu
Outsourcing bảo trì phần mềm chỉ hiệu quả khi phạm vi gọi tên đủ bốn loại bảo trì, SLA định nghĩa mức độ bằng ngôn ngữ nghiệp vụ, và việc bàn giao được tổ chức như một dự án thay vì một email. Làm đúng ba điều đó thì phần còn lại chỉ là kỹ thuật thường ngày.
Nếu bạn đang lập ngân sách hỗ trợ sau go-live cho năm 2026, hãy bắt đầu bằng con số thật thay vì ước lượng. Xem bảng giá minh bạch 2026 → — trang này có sẵn form nhận báo giá, chúng tôi phản hồi trong vòng 24 giờ.
