Mở đầu — vì sao bài này quan trọng
Khi bạn còn là một Product Owner ở giai đoạn đầu sự nghiệp, quyết định "tự xây hay đi mua" (build vs buy) thường khá đơn giản: bạn ước lượng vài tuần công sức của đội kỹ thuật, so sánh với giá thuê bao của một công cụ SaaS nào đó, rồi chọn phương án rẻ hơn. Nhưng khi bạn bước lên vai trò Senior PO hay Head of Product trong một tổ chức lớn, cùng một câu hỏi đó bỗng biến thành một quyết định chiến lược nhiều lớp, kéo theo ngân sách nhiều năm, biên chế nhân sự, ràng buộc pháp lý, rủi ro vận hành và cả chính trị nội bộ.
Đây chính xác là loại tình huống mà kỳ thi PSPO III và thực tế công việc cấp cao đòi hỏi bạn phải lập luận chặt chẽ. Một quyết định build vs buy sai ở quy mô doanh nghiệp không chỉ làm trễ một sprint — nó có thể khóa chặt tổ chức vào một hướng đi suốt 3–5 năm, tiêu tốn hàng chục tỷ đồng, hoặc tạo ra "nợ kiến trúc" mà người kế nhiệm bạn phải gánh chịu. Bài học này giúp bạn nâng cấp tư duy từ "phép tính chi phí của startup" lên "khung quyết định chiến lược của lãnh đạo sản phẩm". Đây là chủ đề riêng của Bài 54 — chúng ta sẽ không bàn về build vs buy như một quyết định kỹ thuật đơn lẻ, mà như một bài toán phân bổ năng lực và quản trị rủi ro ở tầm tổ chức.
Khái niệm cốt lõi
Build vs Buy ở doanh nghiệp khác gì so với startup
Ở startup, build vs buy gần như chỉ là bài toán tốc độ và tiền mặt. Ở doanh nghiệp lớn, phương trình thay đổi căn bản vì hai vế của nó mang ý nghĩa hoàn toàn khác:
- Quyết định "Buy" = bước vào bộ máy mua sắm (procurement). Mua một giải pháp ở doanh nghiệp không phải là điền số thẻ tín dụng. Nó kéo theo đấu thầu, đánh giá nhà cung cấp (vendor assessment), thẩm định bảo mật và pháp lý, đàm phán hợp đồng, điều khoản SLA, thỏa thuận xử lý dữ liệu (DPA), và đôi khi cả phê duyệt từ hội đồng. Một thương vụ mua phần mềm có thể mất 3–9 tháng từ lúc khởi xướng đến lúc ký.
- Quyết định "Build" = cam kết biên chế và đầu tư nhiều năm. Tự xây không chỉ là chi phí phát triển ban đầu. Bạn đang ký vào một cam kết duy trì đội ngũ, vận hành, bảo trì, vá lỗi bảo mật, và tiến hóa sản phẩm đó trong nhiều năm. Một hệ thống "xây xong" không bao giờ thực sự xong — nó trở thành một khoản nợ vận hành thường trực trên bảng cân đối năng lực của tổ chức.
Khung Core vs Context của Geoffrey Moore
Công cụ tư duy mạnh nhất cho quyết định này là khái niệm Core vs Context của Geoffrey Moore. Hãy phân biệt:
- Core (lõi): Những năng lực tạo ra lợi thế cạnh tranh khác biệt, là lý do khách hàng chọn bạn thay vì đối thủ. Đây là nơi bạn nên tự xây — vì nếu mua, bạn chỉ có thứ mà ai cũng mua được.
- Context (ngữ cảnh): Mọi thứ cần thiết để vận hành nhưng không tạo khác biệt — kế toán, chấm công, gửi email, quản lý kho. Đây là nơi bạn nên mua, vì tự xây những thứ này chỉ làm bạn phân tán nguồn lực khỏi phần lõi.
Bốn lăng kính đánh giá: TCO, Time-to-value, Strategic control, Risk
Một quyết định build vs buy ở tầm lãnh đạo cần được soi qua bốn lăng kính:
- TCO (Total Cost of Ownership — tổng chi phí sở hữu): Không chỉ giá mua hay chi phí dev ban đầu, mà toàn bộ chi phí trong vòng đời 3–5 năm: license, vận hành, tích hợp, đào tạo, di trú dữ liệu, chi phí thoát (exit cost).
- Time-to-value (thời gian tạo giá trị): Mua thường cho giá trị nhanh trong vài tuần; xây có thể mất nhiều quý. Trong thị trường cạnh tranh, sự chậm trễ này có giá rất đắt.
- Strategic control (kiểm soát chiến lược): Bạn có muốn phụ thuộc vào lộ trình của nhà cung cấp không? Nếu họ tăng giá gấp đôi, đóng cửa, hoặc bị đối thủ của bạn mua lại thì sao? Đây là rủi ro vendor lock-in.
- Risk (rủi ro): Rủi ro vận hành, bảo mật, tuân thủ, và rủi ro thực thi (đội của bạn có đủ năng lực xây không?).
Lựa chọn thứ ba: Build-on-platform và Partner
Tư duy lãnh đạo trưởng thành nhận ra rằng build vs buy không phải nhị phân. Có một phổ rộng:
- Buy thuần: Dùng SaaS có sẵn.
- Build-on-platform: Xây phần lõi khác biệt của bạn lên trên một nền tảng mua sẵn (ví dụ xây logic nghiệp vụ riêng trên hạ tầng cloud, hoặc tùy biến trên một platform có API mở).
- Partner / co-development: Hợp tác cùng nhà cung cấp để phát triển giải pháp đo ni đóng giày.
- Build thuần: Tự xây từ đầu.
Tình huống thực tế
Ví dụ 1 — Một ngân hàng Việt Nam và bài toán hệ thống Loan Origination
Một ngân hàng thương mại cổ phần cỡ vừa tại Việt Nam (gọi là Ngân hàng A) đứng trước quyết định: hệ thống xử lý hồ sơ vay (Loan Origination System — LOS) của họ đã lỗi thời. Hai lựa chọn đặt ra: mua một nền tảng LOS quốc tế với chi phí license khoảng 25 tỷ đồng cho 5 năm cộng phí triển khai, hay tự xây với một đội 15 kỹ sư trong 18 tháng.
Head of Product đã làm điều mà một PO non kinh nghiệm bỏ qua: bà phân tách hệ thống thành các thành phần. Phần "quy trình thẩm định tín dụng theo khẩu vị rủi ro riêng của ngân hàng" chính là core — đây là lợi thế cạnh tranh, là thứ giúp họ duyệt vay nhanh hơn và an toàn hơn đối thủ. Còn phần quản lý tài liệu, workflow phê duyệt, tích hợp e-KYC thì là context — ai cũng cần và không tạo khác biệt.
Quyết định cuối cùng là build-on-platform: mua một nền tảng LOS làm khung xương cho phần context, nhưng tự xây mô hình chấm điểm tín dụng và rule engine khẩu vị rủi ro lên trên. Kết quả: thời gian triển khai rút từ 18 tháng dự kiến (nếu build thuần) xuống còn 9 tháng, đồng thời giữ được "bí quyết" thẩm định trong tay mình thay vì giao cho nhà cung cấp.
Bài học: Đừng quyết định build vs buy cho cả một hệ thống lớn. Hãy mổ xẻ nó thành các thành phần, xác định đâu là core đáng tự xây, đâu là context nên mua. Quyết định thông minh nhất thường nằm ở mức thành phần, không phải mức hệ thống.
Ví dụ 2 — Một sàn TMĐT Đông Nam Á tự xây hệ thống đề xuất sản phẩm
Một công ty thương mại điện tử khu vực Đông Nam Á (tạm gọi ShopGo) cân nhắc cho hệ thống recommendation engine — bộ máy gợi ý sản phẩm. Có sẵn nhiều giải pháp SaaS với chi phí khoảng 8.000 USD/tháng. Đội kỹ thuật ước tính tự xây mất 6 kỹ sư trong 8 tháng.
Nhìn bề mặt, mua rẻ hơn và nhanh hơn rõ rệt. Nhưng Head of Product đặt câu hỏi chiến lược: "Khả năng gợi ý đúng sản phẩm cho đúng khách hàng — đó có phải lợi thế cạnh tranh cốt lõi của chúng ta không?" Câu trả lời là có. Ở một sàn TMĐT, mỗi phần trăm tăng tỷ lệ chuyển đổi từ gợi ý tốt hơn có thể tương đương hàng triệu USD doanh thu mỗi năm. Quan trọng hơn, dữ liệu hành vi mua sắm của khách hàng là tài sản chiến lược — đẩy nó cho nhà cung cấp SaaS để "huấn luyện mô hình của họ" đồng nghĩa với việc tiếp sức cho một bên thứ ba có thể phục vụ cả đối thủ.
ShopGo chọn build, dù chậm và tốn hơn ban đầu. Sau hai năm, recommendation engine tự xây đóng góp khoảng 22% doanh thu qua các gợi ý, và quan trọng là họ kiểm soát hoàn toàn thuật toán, dữ liệu và lộ trình cải tiến.
Bài học: Khi một năng lực vừa là core (lợi thế cạnh tranh) vừa gắn với tài sản dữ liệu chiến lược, "đắt hơn và chậm hơn" của phương án build vẫn có thể là quyết định đúng. TCO thấp không phải lúc nào cũng thắng — kiểm soát chiến lược và giá trị dài hạn mới là điều quyết định.
Ví dụ 3 — Tự xây hệ thống nhân sự: một sai lầm phổ biến
Một tập đoàn sản xuất tại Việt Nam (gọi là Tập đoàn B) có đội IT nội bộ khá mạnh đã quyết định tự xây hệ thống quản lý nhân sự (HRMS) thay vì mua một giải pháp như SAP SuccessFactors hay một sản phẩm nội địa. Lý do: "Đội mình giỏi, mua thì tốn license, mà nhu cầu của mình đặc thù."
Ba năm sau, hệ thống tự xây trở thành gánh nặng. Mỗi khi luật lao động hay quy định bảo hiểm xã hội thay đổi, đội IT phải dừng các dự án tạo doanh thu để cập nhật phần mềm chấm công và tính lương. Hai kỹ sư chủ chốt nghỉ việc, mang theo hiểu biết không được tài liệu hóa. TCO thực tế cao gấp ba lần ước tính ban đầu, trong khi nếu mua, nhà cung cấp đã tự lo việc tuân thủ pháp luật và cập nhật.
Bài học: Quản lý nhân sự là context điển hình — cần thiết nhưng không tạo lợi thế cạnh tranh cho một công ty sản xuất. Tự xây context vì "đội mình giỏi" là một cái bẫy: nó khóa năng lực kỹ thuật quý giá của bạn vào việc bảo trì thứ mà thị trường đã giải quyết tốt và rẻ hơn. Năng lực kỹ sư là nguồn lực khan hiếm nhất — hãy dồn nó vào phần core.
Hướng dẫn từng bước
Đây là quy trình ra quyết định build vs buy ở tầm doanh nghiệp mà bạn có thể áp dụng:
- Phân tách bài toán thành các thành phần (decompose). Đừng hỏi "xây hay mua hệ thống này?". Hãy chia hệ thống thành các năng lực thành phần và đánh giá từng phần riêng. Hầu hết quyết định tốt là quyết định lai (hybrid).
- Phân loại Core vs Context cho từng thành phần. Đặt câu hỏi: "Năng lực này có phải lý do khách hàng chọn chúng ta không?" Nếu có — đó là core, nghiêng về build. Nếu không — đó là context, nghiêng về buy.
- Tính TCO trên vòng đời 3–5 năm, không chỉ chi phí năm đầu. Với phương án buy, cộng cả license, phí triển khai, tích hợp, đào tạo, và chi phí thoát. Với build, cộng cả chi phí vận hành, bảo trì, bảo mật, và chi phí cơ hội của đội kỹ sư.
- Lượng hóa time-to-value và chi phí của sự chậm trễ. Mỗi tháng chậm có giá bao nhiêu? Trong thị trường biến động nhanh, một giải pháp mua cho giá trị tháng thứ hai có thể thắng một giải pháp xây hoàn hảo ở tháng thứ mười.
- Đánh giá rủi ro chiến lược và vendor lock-in. Nếu mua: chi phí chuyển đổi khi muốn rời nhà cung cấp là bao nhiêu? Họ có nắm dữ liệu của bạn không? Lộ trình của họ có thể đi ngược lợi ích của bạn không?
- Kiểm tra năng lực thực thi (build capability). Đừng giả định đội bạn xây được. Hỏi thẳng: chúng ta có giữ được nhân tài để duy trì hệ thống này 5 năm không? Nếu không, build là một lời hứa không thể giữ.
- Cân nhắc phương án thứ ba: build-on-platform hoặc partner. Mua phần context làm nền, tự xây phần core lên trên. Đây thường là điểm cân bằng tối ưu.
- Trình bày quyết định bằng ngôn ngữ kinh doanh. Khi đưa lên hội đồng hay ban lãnh đạo, hãy nói về TCO, lợi thế cạnh tranh, rủi ro và time-to-value — không nói về stack công nghệ.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ so sánh chi phí năm đầu. Đây là sai lầm phổ biến nhất. Build trông rẻ vì bạn chỉ nhìn lương dev của năm đầu, quên đi 4 năm bảo trì phía sau. Mẹo: luôn dựng bảng TCO 5 năm cho cả hai phương án.
Lỗi 2 — Bỏ qua chi phí cơ hội của đội kỹ sư. Mỗi kỹ sư bạn giao đi xây phần context là một kỹ sư không được làm phần core tạo lợi thế cạnh tranh. Năng lực kỹ thuật là nguồn lực khan hiếm nhất, không phải tiền.
Lỗi 3 — "Đội mình giỏi nên tự xây được." Năng lực xây ban đầu không phải vấn đề; năng lực duy trì mới là. Mẹo: hỏi "ai sẽ bảo trì cái này trong 5 năm?" trước khi quyết build.
Lỗi 4 — Tự xây phần core nhưng vô tình giao bí quyết cho vendor. Một số quyết định "buy" vô tình đẩy dữ liệu hoặc logic cạnh tranh ra ngoài. Luôn hỏi: dữ liệu và lợi thế của chúng ta có rời khỏi tầm kiểm soát không?
Lỗi 5 — Coi build vs buy là quyết định một lần. Bối cảnh thay đổi. Một thứ hôm nay là context có thể thành core ngày mai (và ngược lại). Mẹo: đặt lịch xem lại các quyết định lớn mỗi 12–18 tháng.
Mẹo quản trị lock-in: Khi mua, luôn đàm phán điều khoản xuất dữ liệu (data portability), tránh phụ thuộc API độc quyền sâu, và ước lượng chi phí thoát ngay từ đầu. Một hợp đồng tốt là hợp đồng bạn có thể rời đi.
Bài tập thực hành
Hãy chọn một hệ thống hoặc năng lực thật trong tổ chức của bạn (hoặc một tổ chức bạn biết rõ) và thực hiện các bước sau:
- Phân tách: Liệt kê 4–6 thành phần năng lực của hệ thống đó.
- Phân loại Core/Context: Với mỗi thành phần, ghi rõ là core hay context và giải thích trong một câu tại sao.
- Dựng bảng TCO 5 năm: Lập hai cột — Build và Buy — và liệt kê mọi hạng mục chi phí trong 5 năm cho ít nhất một thành phần. Đừng quên chi phí vận hành, bảo trì, đào tạo và chi phí thoát.
- Đánh giá rủi ro: Với phương án buy, ước lượng mức độ vendor lock-in (thấp/trung bình/cao) và chi phí chuyển đổi. Với build, đánh giá rủi ro năng lực duy trì.
- Đề xuất phương án lai: Hãy thử thiết kế một phương án build-on-platform — mua phần nào, tự xây phần nào — và lập luận tại sao nó tốt hơn cả build thuần lẫn buy thuần.
- Viết một đoạn 150 từ trình bày quyết định của bạn bằng ngôn ngữ dành cho ban lãnh đạo (nói về giá trị kinh doanh, rủi ro, TCO — không nói về công nghệ).
Tóm tắt
Ở tầm doanh nghiệp, build vs buy không còn là phép tính chi phí đơn giản như ở startup. "Buy" nghĩa là bước vào bộ máy mua sắm với đấu thầu, hợp đồng và lock-in; "Build" nghĩa là cam kết biên chế và đầu tư nhiều năm, kèm gánh nặng bảo trì thường trực.
Khung tư duy cốt lõi là Core vs Context: tự xây những gì tạo lợi thế cạnh tranh, mua những gì chỉ cần thiết để vận hành. Hãy soi mọi quyết định qua bốn lăng kính — TCO vòng đời 3–5 năm, time-to-value, kiểm soát chiến lược và rủi ro — thay vì chỉ nhìn chi phí năm đầu.
Quyết định trưởng thành nhất hiếm khi là nhị phân. Hãy phân tách hệ thống thành thành phần, chọn build cho phần core, buy cho phần context, và thường xuyên nghiêng về phương án build-on-platform để vừa nhanh vừa giữ được lợi thế. Cuối cùng, nhớ rằng năng lực kỹ sư — không phải tiền — là nguồn lực khan hiếm nhất của bạn; hãy dồn nó vào nơi tạo ra khác biệt thật sự cho khách hàng.