Mở đầu — vì sao bài này quan trọng
Có một sự thật ít ai nói với bạn khi mới lên vai trò technical leadership: một phần rất lớn trong tổng chi phí kỹ thuật của công ty không nằm ở lương kỹ sư, mà nằm ở các hợp đồng vendor — nhà cung cấp bên thứ ba. Đó là hoá đơn AWS mỗi tháng, là Datadog, là Sentry, là GitHub, là Twilio, là một cái ERP đắt đỏ mà ba năm trước ai đó ký hợp đồng, giờ không ai dám gỡ.
Ở nhiều startup Việt Nam mà tôi từng làm việc, chi phí vendor SaaS và hạ tầng cloud chiếm 25–40% ngân sách engineering. Vấn đề là những quyết định này thường được đưa ra vội vàng: một bạn engineer thấy tool hay, đăng ký thẻ tín dụng công ty, và sáu tháng sau nó trở thành một phần không thể tháo rời của hệ thống. Đến khi bạn muốn đổi, chi phí chuyển đổi (switching cost) cao đến mức bạn bị "khoá cứng" — đó chính là vendor lock-in.
Là tech lead, bạn không phải nhân viên mua sắm. Nhưng bạn là người hiểu rõ nhất hệ quả kỹ thuật của một lựa chọn vendor: nó ảnh hưởng đến kiến trúc, đến tốc độ dev, đến khả năng thoát ra sau này. Nếu bạn không có một khung đánh giá vendor rõ ràng, bạn sẽ hoặc là mua nhầm (tốn tiền vô ích), hoặc là bị khoá (mất khả năng đàm phán và linh hoạt). Bài này cho bạn một quy trình đánh giá vendor có kỷ luật, và một cách nhìn tỉnh táo về lock-in — biết khi nào lock-in chấp nhận được, khi nào phải tránh bằng mọi giá.
Khái niệm cốt lõi
Vendor management là gì trong bối cảnh engineering
Vendor management là toàn bộ quá trình lựa chọn, đàm phán, tích hợp, giám sát và (khi cần) thoát khỏi các nhà cung cấp bên thứ ba mà đội kỹ thuật phụ thuộc vào. Nó không chỉ là "mua tool". Nó là quản lý một mối quan hệ có ràng buộc tài chính và kỹ thuật kéo dài nhiều năm.
Vendor của một đội engineering thường rơi vào các nhóm: hạ tầng cloud (AWS, GCP, Azure), công cụ quan sát (Datadog, New Relic, Grafana Cloud), CI/CD (CircleCI, GitHub Actions), giao tiếp (Twilio, SendGrid), thanh toán (Stripe, VNPay, MoMo), và các SaaS nội bộ (Jira, Notion, Figma). Mỗi loại có mức độ "dính" khác nhau vào kiến trúc của bạn.
Bốn trục đánh giá một vendor mới
Khi cân nhắc một vendor mới, tôi luôn đánh giá theo bốn trục, và tuyệt đối không bỏ trục nào:
Functionality (chức năng). Nguyên tắc thực dụng của tôi: vendor phải đáp ứng ít nhất 80% yêu cầu bạn cần ngay bây giờ, và khoảng 50% những gì bạn dự đoán cần trong năm tới. Vì sao không đòi 100%? Vì không sản phẩm nào khớp hoàn hảo, và nếu bạn chờ 100% bạn sẽ không bao giờ quyết. Nhưng nếu chỉ đáp ứng 60% hiện tại, bạn sẽ phải viết quá nhiều code "vá" xung quanh nó — và đống code vá đó tự nó trở thành nợ. Con số 50% cho tương lai giúp bạn tránh chọn một tool "hết đất phát triển" ngay khi công ty lớn lên.
Pricing (giá và tổng chi phí sở hữu). Đừng bao giờ nhìn giá niêm yết hàng tháng rồi nhân lên. Hãy tính TCO (Total Cost of Ownership) trong 3 năm, bao gồm: phí license/usage, chi phí tích hợp ban đầu, chi phí đào tạo đội, chi phí vận hành, và — quan trọng nhất — chi phí thoát ra. Hãy hỏi thẳng về enterprise discount: hầu hết vendor SaaS đều có mức giá niêm yết cao hơn 20–50% so với giá họ sẵn sàng ký nếu bạn cam kết theo năm hoặc mua theo volume.
Reliability & Support (độ tin cậy và hỗ trợ). SLA họ cam kết là bao nhiêu (99.9%? 99.99%?), và quan trọng hơn: khi họ vi phạm SLA thì bạn được gì — chỉ là credit hoàn tiền hay có gì thực chất? Kênh support ra sao, có hỗ trợ theo múi giờ của bạn không? Một vendor Mỹ hỗ trợ chỉ giờ hành chính EST có thể là ác mộng cho đội ở Việt Nam khi sự cố xảy ra lúc 2 giờ chiều giờ ta.
Lock-in risk (rủi ro bị khoá). Đây là trục hay bị bỏ quên nhất. Câu hỏi cốt lõi: nếu một năm nữa tôi muốn rời vendor này, việc đó khó đến mức nào? Dữ liệu của tôi có export được ra định dạng chuẩn không? API có tuân theo chuẩn mở không hay là proprietary? Tôi có phải viết lại bao nhiêu code?
Hiểu đúng về vendor lock-in
Lock-in là mức độ bạn bị phụ thuộc vào một vendor đến nỗi việc chuyển đổi trở nên tốn kém hoặc bất khả thi. Nó có nhiều dạng:
- Data lock-in: dữ liệu của bạn nằm trong định dạng độc quyền, khó export.
- API lock-in: bạn viết code gọi thẳng API riêng của vendor, rải khắp codebase.
- Skill lock-in: cả đội chỉ biết công cụ của vendor này, đổi sang cái khác phải đào tạo lại.
- Contractual lock-in: hợp đồng ràng buộc nhiều năm với phí phạt khi rời sớm.
Nguyên tắc "thoát có kế hoạch" (exit strategy)
Với mọi vendor quan trọng, hãy trả lời được câu hỏi này trước khi ký: "Nếu vendor này tăng giá gấp đôi, hoặc phá sản, hoặc bị mua lại rồi đóng cửa — kế hoạch B của tôi là gì?" Nếu bạn không có câu trả lời, bạn chưa sẵn sàng để phụ thuộc vào họ ở mức đó. Đây không phải sự bi quan, mà là quản trị rủi ro cơ bản.
Tình huống thực tế
Tình huống 1 — Startup fintech ở TP.HCM và cái bẫy observability
Một startup fintech tôi tư vấn (gọi là công ty A, khoảng 30 kỹ sư) chọn Datadog làm nền tảng observability từ những ngày đầu. Datadog cực kỳ tốt — dashboard đẹp, APM mạnh, tích hợp nhanh. Đội yêu nó. Vấn đề: mô hình giá của Datadog tính theo host và theo lượng log/metric ingest. Khi công ty tăng từ 20 lên 150 microservice trong 18 tháng, hoá đơn Datadog nhảy từ 3.000 USD/tháng lên gần 22.000 USD/tháng — tương đương lương của mấy kỹ sư senior.
Khi họ muốn giảm chi phí bằng cách chuyển một phần sang Grafana + Prometheus tự host, họ phát hiện ra: hàng trăm dashboard, alert, và cả đoạn code instrumentation đều gắn chặt với API riêng của Datadog. Migration ước tính mất 4 tháng của 2 kỹ sư. Họ bị API lock-in mà không hề nhận ra khi ký.
Bài học: Với các vendor tính giá theo mức tăng trưởng (usage-based), hãy mô phỏng hoá đơn ở quy mô gấp 5–10 lần hiện tại trước khi cam kết. Và ngay từ đầu, hãy cô lập việc tích hợp qua một lớp trừu tượng (ví dụ dùng chuẩn OpenTelemetry thay vì gọi thẳng SDK Datadog) để giảm API lock-in. Con số nhỏ hôm nay dễ trở thành con số khủng khiếp ngày mai.
Tình huống 2 — Sàn thương mại điện tử và bài toán build vs vendor cho tìm kiếm
Một sàn TMĐT tại Đông Nam Á (công ty B) cần chức năng search. Đội định dùng Algolia — một vendor search-as-a-service tuyệt vời. Tech lead lập bảng đánh giá bốn trục. Functionality: Algolia đáp ứng 95% nhu cầu hiện tại, và có đủ tính năng cho năm tới — đạt. Pricing: mô hình tính theo số record và số request; với 2 triệu sản phẩm và traffic mùa sale, TCO 3 năm ước tính khoảng 480.000 USD. Reliability: SLA 99.99%, support tốt — đạt. Lock-in: index và ranking config đều là proprietary, nhưng dữ liệu nguồn nằm ở database riêng nên vẫn export được.
Điểm quyết định là ở TCO. 480.000 USD trong 3 năm khiến họ dừng lại. Họ đàm phán: cam kết hợp đồng 2 năm để lấy enterprise discount, kéo được giá xuống gần 30%. Song song, họ thiết kế lớp search abstraction — code business không gọi thẳng Algolia mà gọi qua interface SearchProvider nội bộ. Nhờ vậy, hai năm sau khi họ quyết định chuyển 70% traffic sang OpenSearch tự vận hành cho phần không cần tính năng cao cấp, họ chỉ mất 3 tuần thay vì vài tháng.
Bài học: Đàm phán enterprise discount là chuyện bình thường, đừng ngại. Và abstraction layer là "bảo hiểm chống lock-in" rẻ nhất bạn có thể mua — chỉ vài ngày công thiết kế ban đầu, đổi lại sự tự do khổng lồ về sau.
Tình huống 3 — Vendor nhỏ phá sản và bài học về rủi ro nhà cung cấp
Một công ty SaaS B2B (công ty C, đội 15 người) dùng một startup nhỏ nước ngoài cung cấp dịch vụ gửi email transactional vì giá rẻ hơn SendGrid 40%. Mọi thứ ổn trong một năm. Rồi startup đó bị mua lại, và bên mua thông báo đóng dịch vụ trong 60 ngày. Đội C không có kế hoạch B, dữ liệu template và log gửi mail nằm hết bên vendor. Họ phải làm migration khẩn cấp trong áp lực, suýt gián đoạn email giao dịch cho khách hàng — thứ mà một công ty B2B tuyệt đối không được để hỏng.
Bài học: Rủi ro vendor không chỉ là giá và tính năng, mà còn là sự tồn tại của vendor. Với vendor nhỏ hoặc mới, hãy đánh giá độ ổn định tài chính của họ, và luôn có kế hoạch thoát. Tiết kiệm 40% không đáng nếu nó đặt cả dòng email của bạn vào tay một startup có thể biến mất sau một đêm. Với những chức năng thuộc "đường sống" của sản phẩm, hãy ưu tiên vendor có vị thế vững, dù đắt hơn.
Hướng dẫn từng bước
Đây là quy trình đánh giá một vendor mới mà bạn có thể áp dụng ngay:
Bước 1 — Xác định rõ nhu cầu và tiêu chí "must-have" vs "nice-to-have". Viết ra danh sách yêu cầu trước khi xem bất kỳ sản phẩm nào. Phân biệt rạch ròi cái bắt buộc phải có với cái chỉ là mong muốn. Điều này chống lại việc bị "mê" bởi tính năng hào nhoáng mà bạn không thực sự cần.
Bước 2 — Lập shortlist 2–3 ứng viên và chấm theo bốn trục. Đừng chỉ đánh giá một vendor duy nhất — bạn sẽ không có điểm tham chiếu. Chấm Functionality (80% hiện tại / 50% tương lai), Pricing (TCO 3 năm), Reliability & Support (SLA, kênh hỗ trợ, múi giờ), Lock-in risk (export dữ liệu, chuẩn API, chi phí thoát).
Bước 3 — Tính TCO 3 năm một cách trung thực. Gồm license, tích hợp, đào tạo, vận hành, và chi phí thoát. Mô phỏng chi phí ở quy mô gấp nhiều lần hiện tại nếu là mô hình usage-based.
Bước 4 — Làm PoC (proof of concept) có giới hạn thời gian. Đừng quyết trên slide bán hàng. Cho đội tích hợp thử trong 1–2 tuần với dữ liệu thật. Nhiều vấn đề chỉ lộ ra khi chạm tay vào.
Bước 5 — Đàm phán. Hỏi về enterprise discount, cam kết theo năm, điều khoản SLA, và — quan trọng — điều khoản thoát: dữ liệu export thế nào, có phí phạt rời sớm không, thông báo trước bao lâu.
Bước 6 — Thiết kế abstraction layer trước khi tích hợp sâu. Với mọi vendor quan trọng, đặt một interface nội bộ ở giữa code của bạn và SDK của vendor. Đây là hàng rào chống lock-in.
Bước 7 — Ký, giám sát định kỳ, và đặt lịch review. Mỗi 6–12 tháng, rà lại: vendor này còn xứng đáng không? Chi phí có phình ra không? Có lựa chọn tốt hơn không? Đặt reminder trước ngày gia hạn hợp đồng ít nhất 60 ngày để có thời gian đàm phán lại.
Lỗi thường gặp & mẹo
Lỗi: Chỉ nhìn giá tháng đầu, bỏ qua đường cong chi phí. Vendor usage-based rẻ khi bạn nhỏ và đắt kinh khủng khi bạn lớn. Luôn mô phỏng ở quy mô tương lai.
Lỗi: Không ai "sở hữu" vendor. Khi mỗi engineer tự đăng ký tool bằng thẻ công ty, bạn có "shadow IT" — hàng chục subscription trùng lặp, không ai theo dõi. Mẹo: có một danh sách vendor trung tâm và một người chịu trách nhiệm rà soát.
Lỗi: Gọi thẳng SDK vendor rải khắp codebase. Đây là con đường nhanh nhất đến API lock-in. Mẹo: luôn có abstraction layer cho vendor cốt lõi.
Lỗi: Ký hợp đồng dài hạn quá sớm. Cam kết 3 năm để lấy discount lớn nghe hấp dẫn, nhưng nếu nhu cầu thay đổi bạn bị kẹt. Mẹo: với vendor chưa chắc chắn, chấp nhận giá cao hơn để giữ hợp đồng ngắn hạn/linh hoạt trong năm đầu.
Lỗi: Quên điều khoản thoát khi đàm phán. Ai cũng tập trung vào giá và tính năng, ít ai đọc kỹ điều khoản chấm dứt. Mẹo: hỏi thẳng "nếu tôi muốn rời, dữ liệu tôi lấy ra thế nào, mất phí gì" trước khi ký.
Mẹo vàng: Phân loại vendor theo mức độ "đường sống". Vendor cốt lõi (thanh toán, hạ tầng chính) — chọn kỹ, ưu tiên độ ổn định, luôn có kế hoạch B. Vendor phụ trợ (tool nội bộ) — có thể linh hoạt và rẻ hơn vì đổi dễ. Đừng dùng cùng một mức độ cẩn trọng cho mọi thứ; điều đó lãng phí thời gian.
Bài tập thực hành
- Audit vendor hiện tại. Liệt kê tất cả vendor/SaaS mà đội bạn đang trả tiền (hoặc một đội giả định). Với mỗi cái, ghi: chi phí tháng, mức độ "đường sống" (cốt lõi/phụ trợ), và mức lock-in (thấp/trung/cao). Bạn sẽ ngạc nhiên về những gì tìm thấy.
- Chấm điểm bốn trục. Chọn một vendor bạn đang cân nhắc (ví dụ đổi từ vendor A sang B). Lập bảng chấm theo bốn trục: Functionality, Pricing (TCO 3 năm), Reliability & Support, Lock-in. Cho điểm và ra quyết định dựa trên bảng đó.
- Viết exit plan. Chọn vendor quan trọng nhất của bạn. Viết một đoạn ngắn trả lời: "Nếu vendor này tăng giá gấp đôi hoặc đóng cửa trong 90 ngày, tôi sẽ làm gì?" Nếu bạn không viết nổi, đó là tín hiệu bạn đang có rủi ro chưa được quản lý.
Tóm tắt
Vendor management là một kỹ năng leadership thực thụ, không phải việc hành chính. Là tech lead, bạn cầm chìa khoá quyết định phần chi phí kỹ thuật lớn nhất mà nhiều người không để ý. Hãy đánh giá mọi vendor mới theo bốn trục: Functionality (đáp ứng 80% nay, 50% năm sau), Pricing (TCO 3 năm chứ không phải giá niêm yết, và luôn đàm phán discount), Reliability & Support (SLA và múi giờ hỗ trợ), và Lock-in risk (export dữ liệu, chuẩn API, chi phí thoát).
Về lock-in: nó không xấu tự thân, xấu là khi bạn trượt vào nó vô thức. Chấp nhận lock-in một cách có ý thức, cô lập tích hợp bằng abstraction layer, và luôn có exit strategy cho vendor cốt lõi. Phân loại vendor theo mức độ đường sống để dành sự cẩn trọng đúng chỗ. Cuối cùng, đặt lịch review định kỳ — vì một quyết định vendor đúng hôm nay có thể trở thành gánh nặng sau hai năm nếu không ai để mắt tới.