Top 5 lưu ý về dịch vụ doanh nghiệp khi thuê ngoài là danh sách mà đội ngũ Pumacode luôn mở ra trước mỗi buổi tư vấn. Chúng tôi đã ngồi ở cả hai phía bàn: có lúc là bên triển khai, cũng có lúc đứng ra giúp doanh nghiệp chọn nhà cung cấp. Càng làm nhiều, tụi em càng thấy phần lớn rắc rối không đến từ công nghệ. Nó đến từ những thứ không được viết rõ ngay từ đầu.
Có lần một anh CTO quen của bên mình kể lại chuyện ký hợp đồng gia công phần mềm hồi đầu năm. Báo giá ban đầu 180 triệu, nghe rất hợp lý. Đến lúc hệ thống chạy thật, đội anh phải chi thêm gần 300 triệu cho đủ thứ không ai nhắc trong báo giá. Anh bảo cái gọi là “giá tốt” hoá ra lại là cái bẫy đắt nhất anh từng dính. Chuyện này không hiếm chút nào.
Bài viết dưới đây gom lại năm điểm mà chúng tôi khuyên soi kỹ trước khi đặt bút ký: phạm vi viết được thành checklist, năng lực kỹ thuật có bằng chứng, điều khoản bàn giao, chi phí thật sau go-live, và SLA khớp với giờ vận hành của bạn. Nắm năm điểm này trước, bạn tiết kiệm được cả tiền lẫn thời gian về sau.
Vì sao bảng báo giá đẹp chưa nói lên điều gì
Câu khách hỏi chúng tôi nhiều nhất vẫn là: “Bên nào rẻ nhất thì chốt?” Với team tech nhỏ, đây thường là sai lầm tốn kém nhất. Báo giá chỉ là con số của hiện tại, còn hợp đồng là chuỗi quyết định kéo dài 6-12 tháng sau đó.
Khi chỉ nhìn giá, ba thứ hay bị bỏ qua. Thứ nhất là phạm vi bàn giao. Nhà cung cấp A báo 150 triệu cho “website bán hàng”, nhà cung cấp B báo 150 triệu cho “website bán hàng tích hợp cổng thanh toán và đồng bộ kho”. Nghe cùng một câu, khối lượng công việc có thể khác nhau gấp đôi. Thứ hai là trách nhiệm khi lỗi phát sinh. Bug sau go-live ba tháng ai sửa, sửa miễn phí tới bao lâu — không ai nói rõ thì đến lúc có lỗi, bạn lại phải trả tiền thêm. Thứ ba là chi phí ẩn lúc duy trì. Máy chủ, tên miền mail, phí API, bản quyền thư viện cộng lại mỗi tháng có thể vài triệu, và mấy khoản đó không bao giờ nằm trong báo giá ban đầu.
Cách lọc nhanh trước khi đi sâu: bạn gửi cho nhà cung cấp một khối lượng công việc ngắn, khoảng 1-2 tuần dev, rồi yêu cầu họ bóc tách thành checklist. Bên nào bóc được thành 8-15 dòng việc có input/output rõ là bên đó đã hình dung công việc thật. Bên nào chỉ ghi “thiết kế và lập trình” thì bạn biết mình đang nói chuyện với một đơn vị đứng ở tầm báo giá, chưa xuống tầm kỹ thuật.
Lưu ý 1 — Phạm vi dịch vụ phải viết được thành checklist kiểm chứng
Phạm vi công việc, tiếng Anh gọi là Statement of Work, nghe có vẻ giấy tờ hành chính nhưng thực chất là công cụ bảo vệ cả hai bên. Tiêu chí của chúng tôi rất gọn: mỗi đầu việc trong hợp đồng phải có input, output và người chịu trách nhiệm.
Ví dụ dễ hiểu. Đừng ghi “xây dựng module thanh toán”. Ghi thành: “Tích hợp cổng VNPay, đầu vào là tài khoản merchant của khách, đầu ra là luồng thanh toán chạy được trên môi trường staging, người chịu trách nhiệm là dev backend phía nhà cung cấp”. Khi đầu việc đã cụ thể như vậy, lúc nghiệm thu không còn chỗ để tranh cãi “cái này chưa tính” hay “cái kia ngoài phạm vi”.
Nhóm phù hợp nhất với cách này là team dev hoặc CTO nhỏ, chưa có quy trình mua sắm chuẩn hoá. Bản thân chúng tôi khi tư vấn cho các team dưới 10 người thường phải ngồi cùng họ hai buổi để làm rõ đầu việc. Sau đó họ tự viết được cho lần thuê thứ hai. Đây là lợi ích cộng dồn — làm kỹ lần đầu, lần sau nhẹ nửa công.
Cũng phải nói thẳng hạn chế. Hợp đồng càng chi tiết càng mất thời gian đàm phán, có khi kéo dài hai tuần. Với nhà cung cấp nhỏ dưới 5 người, họ không đủ nhân sự để cam kết ở mức chi tiết đó. Kinh nghiệm của chúng tôi: chấp nhận độ chi tiết tương ứng với giá trị hợp đồng. Hợp đồng dưới 100 triệu thì checklist cấp module là đủ. Hợp đồng trên 500 triệu thì phải bóc tới cấp chức năng nhỏ.
Nếu bạn đang cân nhắc thuê ngoài làm website, hãy đọc kỹ bảng khối lượng công việc trước khi ký, vì đây chính là chỗ phạm vi dễ bị mơ hồ nhất. Tham khảo thêm dịch vụ thiết kế website trọn gói cho doanh nghiệp để hình dung đầu việc chuẩn thường được chia thế nào.
Lưu ý 2 — Năng lực kỹ thuật: đòi bằng chứng, đừng nghe giới thiệu
Tiêu chí ở đây khác hẳn với nhìn vào số năm kinh nghiệm hay portfolio đẹp. Bạn cần hai thứ cụ thể. Một là tài liệu mẫu hoặc repo mà nhà cung cấp sẵn sàng cho xem trước khi ký. Hai là có người ngồi review được kiến trúc hệ thống hiện tại của bạn — không phải người kinh doanh, mà là kỹ thuật viên thật.
Nói rõ hơn về chuyện review kiến trúc. Nếu hệ thống của bạn đang chạy trên một nền tảng có sẵn, ví dụ một phần mềm quản lý doanh nghiệp đang dùng, thì nhà cung cấp mới cần hiểu cách hệ thống đó tổ chức dữ liệu trước khi đề xuất tích hợp. Bên nào ngồi vẽ ra giải pháp “tất cả làm từ đầu” mà chưa hỏi hệ thống hiện tại của bạn có gì, đó là dấu hiệu xấu. Họ đang cố bán lại đúng một sản phẩm mẫu của họ, không phải giải pháp cho bạn.
Team phù hợp với tiêu chí này là team đang cần tích hợp vào hệ thống đang chạy, chứ không phải làm mới từ số 0. Nhóm này thường có sẵn dữ liệu người dùng, có API nội bộ, có quy trình đang vận hành — nhà cung cấp mà không hiểu được bối cảnh đó thì tiến độ sẽ vỡ ngay tuần thứ hai.
Hạn chế thật: case study hầu như luôn được lọc. Bạn xem portfolio nhà cung cấp, thấy toàn dự án thành công — dĩ nhiên rồi, dự án thất bại không ai đăng. Muốn đánh giá đúng, bạn phải dành một buổi trao đổi kỹ thuật trực tiếp, tốt nhất là có mặt cả dev bên họ. Trong buổi đó bạn hỏi thẳng ba câu: hệ thống tương tự đã làm, các điểm nghẽn kỹ thuật gặp phải là gì, và lần này họ dự đoán nghẽn ở chỗ nào. Người làm thật sẽ trả lời rất cụ thể, người nói lại tài liệu sẽ trả lời vòng vo. Chúng tôi đã nhiều lần loại nhà cung cấp chỉ qua đúng buổi này.
Lưu ý 3 — Điều khoản bàn giao và quyền sở hữu kết quả
Tiêu chí này nghe khô khan nhưng lại dễ gây hậu quả nặng nhất: mã nguồn, tài liệu và tài khoản hạ tầng phải được chuyển giao cùng lúc với nghiệm thu, không phải sau tất toán. Nói cách khác, khi bạn ký biên bản nghiệm thu thì đồng thời bạn phải nắm trong tay mọi thứ cần để vận hành độc lập.
Tài khoản hạ tầng gồm những gì? Đơn giản là máy chủ, tên miền, cổng thanh toán, dịch vụ gửi mail và các tài khoản API bên thứ ba. Nếu những tài khoản này đăng ký dưới tên nhà cung cấp, bạn sẽ bị khoá chặt vào họ — đổi nhà cung cấp khác phải xin lại từng cái, mất cả tháng.
Nhóm phù hợp nhất với tiêu chí bàn giao rõ là doanh nghiệp không muốn bị trói vào một nhà cung cấp duy nhất. Điều này đặc biệt quan trọng với các bạn đang tìm hiểu gia công phần mềm cho người mới bắt đầu, vì lần đầu thuê ngoài thường chưa hình dung được việc bị phụ thuộc nó khó chịu thế nào cho tới khi thực sự phát sinh.
Hạn chế cần biết trước: một số nhà cung cấp chỉ bàn giao mã nguồn khi bạn tất toán đủ 100% giá trị hợp đồng. Cách này không sai về nguyên tắc bảo vệ họ, nhưng nó tiềm ẩn rủi ro cho bạn. Bạn nên ghi rõ từ đầu thời điểm chuyển giao. Cách chúng tôi thường đề xuất: bàn giao theo từng milestone, mỗi lần thanh toán một phần thì chuyển giao phần tương ứng. Đến lúc ký nghiệm thu cuối, bạn đã nắm 90% hệ thống trong tay rồi.
Lưu ý 4 — Chi phí thật: đừng bỏ qua phần sau khi go-live
Tiêu chí chọn ở đây rất rõ: yêu cầu nhà cung cấp đưa bảng chi phí tách riêng hai giai đoạn — giai đoạn xây dựng và giai đoạn duy trì 6-12 tháng đầu. Bảng đó là một tài liệu, không phải lời hứa miệng. Nếu nhà cung cấp từ chối đưa, đó là tín hiệu cần chú ý.
Nhóm phù hợp nhất là doanh nghiệp vừa và nhỏ, ngân sách phải duyệt theo quý. Khi bạn trình sếp một con số 200 triệu nhưng thực chi cả năm gấp rưỡi, lần sau xin ngân sách cho dự án khác sẽ khó hơn hẳn. Vì vậy việc tách chi phí không chỉ là vấn đề kế toán, nó là vấn đề uy tín nội bộ của người đề xuất dự án.
Hạn chế thật: nhiều nhà cung cấp không công bố giá bảo trì vì nó phụ thuộc quy mô, số lượng người dùng, mức độ phức tạp của hệ thống. Cách xử lý là bạn tự đặt kịch bản sự cố để ước lượng. Ví dụ: giả sử mỗi tháng có hai sự cố nhỏ mất hai giờ, một sự cố vừa mất nửa ngày, và mỗi quý có một sự cố lớn mất hai ngày. Cộng nhân với đơn giá theo giờ của nhà cung cấp, bạn có con số tối thiểu để dự phòng. Cách này không chính xác tuyệt đối, nhưng buộc nhà cung cấp phải trả lời bằng số thay vì “tuỳ tình hình”.
Bốn khoản dưới đây là chỗ chúng tôi thấy khách hay bị động nhất. Khung này không phải giá niêm yết, bạn nên dùng để đặt câu hỏi chứ đừng lấy làm con số chính xác áp lên mọi trường hợp.
- Phí khởi tạo: hỏi rõ bao gồm hạng mục nào, khi đổi yêu cầu giữa chừng tính thêm ra sao. Bỏ qua khoản này thì chi phí dễ đội lên gấp rưỡi đến gấp đôi dự kiến ban đầu.
- Phí duy trì hàng tháng: hỏi mức SLA phản hồi, khung giờ hỗ trợ, có bao gồm cập nhật bảo mật định kỳ không. Không hỏi thì xảy ra sự cố ngoài giờ là bị treo, không ai trực.
- Phí thay đổi phạm vi: đơn giá theo giờ hay theo gói, ai xác nhận khối lượng. Đây là nguồn tranh chấp phổ biến nhất mỗi khi khách muốn thêm tính năng nhỏ giữa dòng.
- Phí chuyển giao: có tính tiền tài liệu, đào tạo, hỗ trợ giai đoạn chuyển tiếp không. Bỏ qua thì bạn dễ bị động, không dám đổi nhà cung cấp dù không hài lòng.
Lưu ý 5 — SLA và kênh hỗ trợ phải khớp với giờ vận hành của bạn
SLA, viết tắt của Service Level Agreement, hiểu đơn giản là cam kết mức dịch vụ. Nó phải được ghi theo giờ cụ thể chứ không phải bằng những câu chung chung kiểu “trong ngày làm việc”. Tiêu chí chọn: nhà cung cấp cam kết thời gian phản hồi bằng con số rõ ràng, ví dụ “phản hồi ban đầu trong hai giờ đối với sự cố P1, trong tám giờ với P2”.
Phân loại sự cố P1/P2 cũng cần được định nghĩa ngay trong hợp đồng. P1 thường là hệ thống không truy cập được hoặc chức năng cốt lõi chết. P2 là lỗi ảnh hưởng một phần chức năng nhưng vẫn có cách dùng. P3 là lỗi nhỏ về giao diện, có thể chờ. Bên nào không phân loại mà cứ cam kết “hỗ trợ 24/7” chung chung thì gần như cam kết đó không có giá trị đo lường.
Nhóm phù hợp nhất với SLA khắt khe là hệ thống phục vụ người dùng ngoài giờ hành chính, hoặc có khách nước ngoài. Ví dụ team bạn có khách Mỹ, giờ cao điểm bên họ là tám giờ tối giờ Việt Nam. Nếu SLA chỉ ghi “hỗ trợ 8h-17h”, sự cố lúc chín giờ tối sẽ nằm chờ tới sáng hôm sau. Với hệ thống có giao dịch, chờ nửa ngày là mất doanh thu thật.
Hạn chế: SLA cao đi kèm phí cao. Nhà cung cấp phải trả lương cho người trực ngoài giờ, chi phí đó tính vào hợp đồng. Doanh nghiệp nhỏ không cần cam kết 24/7 cho mọi hệ thống. Chúng tôi thường khuyên phân tầng: hệ thống doanh thu thì SLA nghiêm, hệ thống nội bộ hoặc website giới thiệu thì SLA thường là đủ. Nếu đang triển khai các luồng tự động liên quan tới khách hàng, ví dụ luồng xử lý lead real-time từ website đến đội sale, thì SLA cần soi kỹ hơn mức thông thường. Sự cố ở khâu này ảnh hưởng trực tiếp tới chuyển đổi.
Bài học lớn nhất chúng tôi rút ra sau nhiều năm làm dịch vụ doanh nghiệp: nhà cung cấp tốt không phải là nhà cung cấp hứa nhiều nhất, mà là nhà cung cấp chịu nói rõ nhất những gì họ không cam kết. Khi một bên uy tín đưa hợp đồng, họ thường khoanh vùng trách nhiệm rất dứt khoát. Họ nói rõ hạng mục nào không nằm trong phạm vi, tình huống nào phát sinh phí, và cái gì họ không đảm bảo. Sự dứt khoát đó không phải là dấu hiệu họ yếu, mà là dấu hiệu họ đã làm việc này nhiều lần và biết chỗ nào dễ vỡ.
Ngược lại, một bên liên tục nói “cái đó dễ”, “không thành vấn đề”, “để bên em lo hết” mà không đưa ra giới hạn nào thường là bên chưa từng gặp sự cố. Lúc dự án bình yên thì mọi nhà cung cấp đều giống nhau. Khác biệt chỉ hiện ra khi có vấn đề, và lúc đó bạn mới thấy mình đã mua một cam kết hay mua một lời hứa.
Hai cái bẫy ít ai nhắc khi thuê dịch vụ doanh nghiệp
Có một cái bẫy mà chúng tôi thấy rất ít tài liệu tư vấn nhắc tới, nhưng lại khiến không ít khách hàng của mình mất thời gian: khoảng cách giữa người tư vấn và người làm. Trong buổi đàm phán, bạn gặp những người rất giỏi, nắm bắt nhanh, trả lời trôi chảy. Khi hợp đồng ký xong, dự án được giao cho một nhóm khác mà bạn chưa từng gặp. Chất lượng câu trả lời của nhóm mới có thể thấp hơn hẳn nhóm đàm phán, và bạn bắt đầu mất thêm thời gian giải thích lại những gì đã thống nhất.
Để tránh cái bẫy này, một số hợp đồng chúng tôi từng thấy có hiệu lực tốt: ghi rõ tên key person trong nhóm triển khai, và ghi rõ nếu thay người thì phải thông báo trước. Nghe có vẻ cứng nhắc, nhưng nó buộc nhà cung cấp phải phân bổ người ngay từ đầu chứ không phải chuyển dự án qua lại như trái banh.
Cái bẫy thứ hai liên quan tới dữ liệu. Rất nhiều doanh nghiệp nhỏ bàn giao dữ liệu khách hàng cho nhà cung cấp mà không kèm điều khoản nào về việc dữ liệu được dùng thế nào, lưu ở đâu, xoá khi nào. Với các dự án có yếu tố tích hợp trí tuệ nhân tạo, dữ liệu lại càng nhạy cảm. Bạn có thể tham khảo thêm cách thiết kế AI agent cho doanh nghiệp trong kiến trúc event-driven để hình dung mức độ dữ liệu mà một hệ thống tự động có thể chạm tới. Nếu bạn chưa chuẩn bị sẵn câu hỏi về dữ liệu, rất dễ bị cuốn vào tiến độ và bỏ qua phần này.
Bốn sai lầm lặp lại khi đánh giá nhà cung cấp
Chúng tôi ngồi lại nhiều lần sau mỗi dự án để ghi ra những lỗi mà đội mình hoặc khách hàng đã gặp. Mấy sai lầm dưới đây xuất hiện lặp đi lặp lại, kể cả với những team khá kinh nghiệm.
- Chốt hợp đồng dựa trên một buổi demo. Buổi demo là sân khấu — mọi thứ chạy trơn tru, mọi nút bấm đều hoạt động. Nó không cho bạn biết quy trình làm việc thực tế của họ diễn ra thế nào.
- Không ghi lại các trao đổi miệng về phạm vi. Ba tháng sau, không ai nhớ chính xác đã nói gì. Quy tắc đơn giản: sau mỗi cuộc họp, gửi lại một email tóm tắt 5-7 dòng.
- So sánh nhà cung cấp theo tổng giá. Báo giá 200 triệu và 150 triệu chỉ so được khi cùng một danh sách đầu việc. Nếu không chuẩn hoá, hai con số đó không cùng đơn vị đo.
- Chỉ gặp đội kinh doanh, không gặp người làm thật. Một buổi gặp 30 phút với dev phụ trách thường tiết kiệm được nhiều tuần rắc rối sau đó.
- Bỏ qua câu hỏi về dữ liệu. Dữ liệu khách hàng là tài sản, không phải thứ đương nhiên được dùng cho mọi mục đích. Hỏi rõ ngay từ đầu để tránh rắc rối về sau.
Cách chấm điểm nhà cung cấp trong 30 phút
Đây là quy trình chúng tôi dùng nội bộ khi cần so sánh ba đến năm nhà cung cấp cùng lúc. Lập bảng điểm theo năm nhóm lưu ý phía trên, mỗi nhóm cho trọng số tuỳ mức ưu tiên của doanh nghiệp. Ví dụ team đang tích hợp vào hệ thống có sẵn thì năng lực kỹ thuật trọng số 30%, còn team làm website mới hoàn toàn thì bàn giao và chi phí duy trì có thể có trọng số cao hơn.
Điểm quan trọng: dùng cùng một bộ câu hỏi cho tất cả nhà cung cấp. Nếu mỗi nơi bạn hỏi một kiểu, bạn sẽ thiên vị theo cảm tính — nhà cung cấp nào nói hay hơn trong buổi họp sẽ được điểm cao hơn một cách vô thức. Chúng tôi từng bị chính mình làm vậy, hồi mới tuyển nhà cung cấp lần đầu, và chọn phải đơn vị nói tốt hơn làm tốt.
Cuối cùng, yêu cầu một đầu việc nhỏ làm thử trước khi ký hợp đồng dài hạn. Đầu việc nhỏ có thể là dựng môi trường staging, hoặc làm một trang tính năng nhỏ. Chi phí bỏ ra ban đầu tuy nhỏ nhưng giúp bạn thấy được cách họ làm việc thật. Nếu làm thử mà chậm, đó là tín hiệu dự án lớn sẽ chậm theo đúng tỉ lệ đó.
Khi nào nên tự làm thay vì thuê dịch vụ doanh nghiệp
Thuê ngoài không phải lúc nào cũng đúng. Nguyên tắc chúng tôi thường đưa ra: phần việc lõi tạo lợi thế cạnh tranh nên giữ nội bộ, phần hỗ trợ mang tính chu kỳ nên thuê ngoài. Hiểu rõ ranh giới này giúp bạn dùng ngân sách hiệu quả hơn nhiều so với việc thuê tất cả.
Phần việc lõi nghĩa là gì? Là thứ mà khách hàng chọn bạn vì nó. Một công ty thương mại điện tử có thuật toán gợi ý sản phẩm riêng thì thuật toán đó là lõi, không nên giao cho người ngoài. Còn việc dựng website giới thiệu, cấu hình mail domain, thiết lập hạ tầng máy chủ — mang tính chu kỳ, ít thay đổi, thuê ngoài thường hiệu quả hơn. Chi phí tự làm những việc này thường cao gấp 2-3 lần so với thuê, chưa tính thời gian tuyển và đào tạo người.
Pumacode đã chứng kiến không ít trường hợp doanh nghiệp ký hợp đồng triển khai vài trăm triệu khi bản thân chưa xác định được mình cần gì. Ba tháng sau, dự án phải huỷ giữa chừng vì yêu cầu đổi liên tục. Trả cho một chuyên gia tư vấn 15-20 triệu để làm rõ yêu cầu trong hai tuần thường tiết kiệm được nhiều lần số đó.
Nếu bạn đang cân nhắc các giải pháp phần mềm quản lý để cùng vận hành với nhà cung cấp, xem qua các phần mềm quản lý doanh nghiệp miễn phí cho người mới khởi nghiệp để chọn công cụ theo dõi công việc phù hợp ngay từ đầu.
Câu hỏi thường gặp về dịch vụ doanh nghiệp
Dịch vụ doanh nghiệp cho team tech khác gì so với thuê freelancer?
Freelancer phù hợp với đầu việc nhỏ, độc lập, thời gian ngắn. Khi dự án vượt quá 1-2 tháng hoặc cần phối hợp nhiều người, freelancer thường gặp giới hạn về năng lực và tính liên tục. Một công ty dịch vụ có quy trình, có người thay thế khi ai đó nghỉ, và quan trọng hơn là có pháp nhân để bạn ký hợp đồng ràng buộc được.
Cần chuẩn bị gì trước khi yêu cầu báo giá dịch vụ?
Ba thứ tối thiểu: danh sách chức năng ở mức module, hệ thống hiện tại đang dùng gì, và ngân sách dự kiến. Nếu chưa có danh sách chức năng, ít nhất bạn phải mô tả được người dùng cuối sẽ làm gì trên hệ thống. Nhà cung cấp nhận được ba thông tin này sẽ báo giá sát hơn nhiều so với khi chỉ nghe mô tả chung.
Làm sao kiểm tra nhà cung cấp có thật sự làm được phần việc đã hứa?
Cách nhanh nhất là yêu cầu một buổi trao đổi kỹ thuật có