Vì sao 70% dự án IT thuê ngoài thất bại? Góc nhìn DM
- Bài toán: Phần lớn dự án IT thuê ngoài thất bại không vì kỹ thuật mà vì trách nhiệm bị đứt gãy giữa các bên.
- Giải pháp: Truy nguyên 3 điểm đứt gãy — tam giác truyền đạt, bẫy "làm đúng yêu cầu", và thiếu accountability end-to-end.
- Kết quả: Giải pháp là tìm một "Single Point of Accountability" chịu trách nhiệm xuyên suốt.
Câu trả lời ngắn: Phần lớn dự án IT thuê ngoài thất bại không phải vì team yếu kỹ thuật, mà vì trách nhiệm bị đứt gãy khi yêu cầu đi qua chuỗi khách hàng → sale → BA → dev: mỗi khâu hiểu lệch một chút, và cuối cùng không ai chịu trách nhiệm cho kết quả end-to-end. Lời giải không nằm ở việc thuê coder giỏi hơn, mà ở một "Single Point of Accountability" nối liền các khâu.
Đã bao giờ bạn thuê một team Dev ngoài (Outsource) làm một hệ thống với giá rất hời, mọi thứ trong buổi họp Kick-off đều hoàn hảo, nhưng đến lúc nhận sản phẩm thì... "Đây không phải thứ tôi muốn!"?
Nếu bạn đã từng, thì bạn không cô đơn. Theo các báo cáo trong ngành (như báo cáo CHAOS Report của Standish Group và nghiên cứu từ McKinsey), có tới gần 70% các dự án phần mềm thuê ngoài gặp vấn đề: trễ hạn, vượt ngân sách, hoặc sản phẩm làm ra không thể sử dụng vào thực tế kinh doanh.
Với 14 năm kinh nghiệm làm Delivery Manager và BrSE cho thị trường Nhật - Việt, tôi đã chứng kiến vô số "vết xe đổ". Bài viết này không nói về code, mà nói về sự đứt gãy trách nhiệm — căn bệnh ung thư của các dự án Outsourcing.
Trước khi đọc tiếp: thất bại đôi khi bắt đầu từ quyết định gốc — có thực sự cần xây không? Nếu chưa chắc, hãy đọc SaaS hay phần mềm may đo? Khung quyết định Build vs Buy trước.
TL;DR (Executive Summary)
- Bài toán: Phần lớn các dự án IT thuê ngoài (outsourcing) thất bại không phải do năng lực kỹ thuật yếu kém, mà do trách nhiệm bị đứt gãy giữa các bên trong quá trình truyền đạt yêu cầu.
- Giải pháp: Nhận diện 3 điểm đứt gãy cốt lõi: tam giác truyền đạt (Khách hàng - Sale - BA - Dev), bẫy "chỉ làm đúng yêu cầu" và sự thiếu hụt trách nhiệm tổng thể (end-to-end accountability).
- Kết quả: Để khắc phục, doanh nghiệp cần tìm một "Single Point of Accountability" (Đầu mối chịu trách nhiệm duy nhất) để đảm bảo giải pháp kỹ thuật bám sát mục tiêu kinh doanh xuyên suốt dự án.
1. Tam giác "Truyền đạt" đứt gãy: Khách hàng → Sale → BA → Dev
Quy trình điển hình của một Agency truyền thống thường diễn ra như thế này:
- Bạn nói chuyện với bạn Sales (rất giỏi ăn nói, hứa hẹn mọi thứ).
- Sales truyền đạt lại cho BA (Business Analyst).
- BA viết tài liệu và ném cho team Dev (những người chỉ biết gõ code).
Vấn đề ở đây là gì? Trò chơi "Tam sao thất bản". Người viết code không hiểu mục tiêu kinh doanh của bạn. Người làm kinh doanh (bạn) lại không được nói chuyện trực tiếp với người giải quyết vấn đề kỹ thuật. Kết quả là hệ thống tạo ra đúng theo từng chữ trong tài liệu, nhưng lại sai hoàn toàn về mặt logic vận hành thực tế. (Tham khảo thêm bài viết của tôi về cách thoát khỏi bẫy phụ thuộc nhân sự khi làm hệ thống nội bộ). Riêng với dự án offshore Việt – Nhật, trò tam sao thất bản còn bị khuếch đại bởi khác biệt văn hóa — tôi đã phân tích kỹ trong bài vì sao "chất lượng Nhật" không tự tái hiện ở team offshore Việt Nam.
2. Bẫy "Làm đúng yêu cầu" thay vì "Giải quyết vấn đề"
Trong mô hình gia công phần mềm truyền thống (nhất là thị trường Offshore), các công ty thường tính tiền theo "Man-month" (số giờ công). Khẩu quyết của họ là: "Khách bảo gì thì làm nấy, không làm dư, không cãi lại".
Điều này nghe có vẻ ngoan ngoãn, nhưng nó giết chết dự án của bạn. Vì bạn là chuyên gia trong ngành của bạn, chứ bạn không phải chuyên gia làm phần mềm. Đôi khi thứ bạn yêu cầu (chẳng hạn: Tôi muốn 1 hệ thống AI phân tích dữ liệu kho) không phải là thứ bạn thực sự cần (Bạn chỉ cần 1 đoạn code tự động hóa AI kéo dữ liệu từ Google Sheet sang Zalo mỗi sáng).
Một Delivery Manager giỏi phải biết cách nói "Không" với khách hàng, và đề xuất giải pháp đơn giản, rẻ tiền hơn nhưng đạt được 100% mục tiêu kinh doanh.
3. Không có ai chịu trách nhiệm "End-to-End" (Accountability)
Đây là lý do lớn nhất. Khi dự án thất bại:
- Dev đổ lỗi cho BA viết document không rõ ràng.
- BA đổ lỗi cho Sales hứa hão với khách.
- Sales đổ lỗi cho Khách hàng thay đổi yêu cầu liên tục.
Trong một dự án, nếu không có một người duy nhất đứng ra đập bàn nói rằng: "Dù lỗi của ai, tôi là người chịu trách nhiệm cuối cùng đảm bảo phần mềm này phải giúp công ty tăng doanh thu", thì dự án đó cực kỳ rủi ro.
Giải pháp: Tìm kiếm "Single Point of Accountability"
Thay vì nhồi nhét một team chục người rời rạc, mô hình hiệu quả nhất cho các dự án SME là tìm một Full-stack Delivery Manager:
- Người có thể ngồi cà phê với bạn để phân tích Business Model.
- Người tự tay phác thảo kiến trúc hệ thống (System Architecture).
- Người trực tiếp gõ những dòng code quan trọng nhất.
- Và là người DUY NHẤT bạn nắm áo khi hệ thống có lỗi.
Đừng mua số lượng nhân sự. Hãy mua sự cam kết ra kết quả.
Trong các dự án offshore Nhật – Việt, vai trò này thường được kỳ vọng ở BrSE — nhưng không phải BrSE nào cũng gánh nổi: tôi đã phân loại rõ trong bài BrSE là gì, khác gì một "thông dịch viên giỏi IT". Còn nếu bạn đang ở khâu chọn đối tác, hãy dùng bộ 5 trục đánh giá vendor offshore trước khi ký, hoặc tự kiểm tra độ phức tạp dự án để có bản mô tả yêu cầu (RFQ) chuẩn mực.
Nếu bạn đang băn khoăn về một hệ thống IT đắt đỏ nhưng chưa rõ hiệu quả, hoặc dự án hiện tại đang bị "kẹt" không thể launch được, cứ gửi bài toán hệ thống — tôi sẽ phản hồi nếu case phù hợp với chuyên môn và quỹ thời gian.
Câu hỏi thường gặp
Vì sao dự án IT thuê ngoài hay thất bại?
Lý do gốc thường không phải kỹ thuật mà là sự đứt gãy trách nhiệm khi yêu cầu đi qua chuỗi khách hàng - sale - BA - dev. Mỗi khâu hiểu lệch một chút, và cuối cùng không ai chịu trách nhiệm cho kết quả end-to-end.
"Single Point of Accountability" nghĩa là gì?
Là một người hoặc vai trò duy nhất chịu trách nhiệm cho kết quả cuối, từ hiểu bài toán kinh doanh tới giải pháp chạy được. Vai trò này nối liền các khâu để ngăn việc "làm đúng yêu cầu nhưng sai vấn đề".