Bài 49 — Sourcing + Outsourcing trong DT

Mở đầu — vì sao bài này quan trọng

Khi dẫn dắt một chương trình chuyển đổi số (Digital Transformation — DT), bạn sẽ nhanh chóng đối mặt với một câu hỏi tưởng đơn giản nhưng lại quyết định cả thành bại: "Cái này chúng ta tự làm hay đi thuê ngoài?" Câu hỏi này xuất hiện ở mọi lớp — từ việc dựng đội kỹ sư phần mềm, chọn nền tảng CRM, đến việc ai sẽ vận hành hạ tầng cloud hay xây dựng mô hình AI.

Đây không phải câu hỏi kỹ thuật. Đây là câu hỏi chiến lược. Vì nếu bạn thuê ngoài (outsource) đúng phần, doanh nghiệp giải phóng được nguồn lực khan hiếm để tập trung vào thứ tạo ra lợi thế cạnh tranh. Nhưng nếu bạn thuê ngoài nhầm phần — đặc biệt là phần "lõi" định hình sản phẩm và trải nghiệm khách hàng — bạn sẽ dần đánh mất năng lực số vào tay đối tác, và mỗi lần muốn thay đổi lại phụ thuộc vào lịch của nhà cung cấp, giá của họ, và tốc độ của họ.

Tôi từng chứng kiến nhiều doanh nghiệp Việt "khoán trắng" toàn bộ app ngân hàng số hoặc sàn thương mại điện tử cho một công ty gia công, để rồi ba năm sau muốn tăng tốc thì không tài nào tuyển được người hiểu hệ thống của chính mình. Bài học ở đây rất rõ: sourcing và outsourcing không phải chuyện "tiết kiệm chi phí", mà là chuyện "kiểm soát năng lực". Bài này sẽ giúp bạn ra quyết định đó một cách có kỷ luật.

Khái niệm cốt lõi

Sourcing vs Outsourcing — phân biệt cho rõ

Sourcing là toàn bộ chiến lược về "chúng ta lấy năng lực và nguồn lực từ đâu để thực thi DT". Nó bao trùm nhiều lựa chọn: tự làm (in-house), thuê ngoài (outsource), thuê chuyên gia theo dự án (staff augmentation), hợp tác (partnership), hay mua nền tảng có sẵn (buy vs build).

Outsourcing chỉ là một nhánh trong sourcing — tức là giao một phần công việc cho bên thứ ba thực hiện. Đừng nhầm hai khái niệm này, vì sourcing rộng hơn và mang tính quyết định hơn.

Nguyên tắc vàng: Core vs Context

Đây là khung tư duy quan trọng nhất của cả bài, xuất phát từ ý tưởng của Geoffrey Moore.

• Core (lõi): là những hoạt động tạo ra sự khác biệt cạnh tranh, là lý do khách hàng chọn bạn thay vì đối thủ. Ví dụ: thuật toán gợi ý sản phẩm của một sàn TMĐT, trải nghiệm thanh toán một chạm của một ví điện tử, mô hình chấm điểm tín dụng của một ngân hàng số.
• Context (bối cảnh): là những hoạt động cần thiết để vận hành nhưng không tạo khác biệt — khách hàng không quan tâm bạn làm nó thế nào. Ví dụ: hệ thống email nội bộ, quản lý bảng lương, hạ tầng máy chủ vật lý, tổng đài cơ bản.

Nguyên tắc: Giữ Core trong nhà, thuê ngoài Context. Nghe đơn giản, nhưng ranh giới Core/Context của mỗi doanh nghiệp lại khác nhau, và nó dịch chuyển theo thời gian. Với một công ty logistics truyền thống, phần mềm không phải core; nhưng với một startup giao hàng công nghệ, thuật toán điều phối tài xế chính là core sống còn — không bao giờ được outsource.

Ma trận quyết định In-house vs Outsource

Bạn có thể dùng bảng sau như một khung tham chiếu khi cân nhắc từng thành phần:

Các mô hình sourcing phổ biến

• In-house (tự làm): tuyển và xây đội ngũ nội bộ. Kiểm soát cao, giữ được tri thức, nhưng chậm khởi động và tốn chi phí cố định.
• Traditional outsourcing (gia công trọn gói): giao cả một khối công việc cho vendor, thường theo hợp đồng cố định. Phù hợp với context, rủi ro cao nếu áp cho core.
• Staff augmentation (thuê tăng cường nhân sự): thuê kỹ sư/chuyên gia làm việc trong đội của bạn, dưới sự quản lý của bạn. Giữ được quyền kiểm soát kiến trúc và tri thức, linh hoạt tăng giảm.
• Managed services: nhà cung cấp chịu trách nhiệm vận hành một dịch vụ theo cam kết SLA (ví dụ: quản lý hạ tầng cloud, bảo mật, tổng đài).
• Buy (mua nền tảng SaaS): dùng sản phẩm có sẵn thay vì tự xây. Nhanh, rẻ với context; nhưng khó tùy biến với core.
• Strategic partnership / co-creation: cùng đối tác xây dựng năng lực mới, chia sẻ rủi ro và lợi ích.

Mô hình vận hành lai (hybrid) — thực tế nhất

Trong thực tiễn DT, hiếm khi bạn chọn thuần một mô hình. Cách tiếp cận trưởng thành nhất là hybrid: đội in-house nắm kiến trúc, sản phẩm, dữ liệu và các module core; đối tác bên ngoài đảm nhận phần context, phần khối lượng lớn, hoặc phần cần tăng tốc tạm thời. Một mô hình phổ biến ở Việt Nam là captive-lite: doanh nghiệp giữ một đội "hạt nhân" 15–30 người in-house để "cầm lái", đồng thời thuê thêm 50–100 kỹ sư từ đối tác gia công để "chèo".

Tình huống thực tế

Ví dụ 1 — Ngân hàng bán lẻ "khoán trắng" app và trả giá

Một ngân hàng thương mại cổ phần cỡ trung tại Việt Nam (gọi là Bank A) quyết định làm app ngân hàng số vào năm 2019. Để nhanh, họ ký hợp đồng trọn gói khoảng 40 tỷ đồng với một công ty gia công nước ngoài, giao toàn bộ: thiết kế, phát triển, cả logic nghiệp vụ lõi như onboarding eKYC và tính lãi. Đội IT nội bộ chỉ đóng vai "nghiệm thu".

App ra mắt đúng hạn và trông ổn. Nhưng vấn đề bắt đầu sau đó. Mỗi lần muốn thêm tính năng — ví dụ mở tài khoản tiết kiệm online — họ phải gửi yêu cầu, chờ báo giá, chờ vendor xếp lịch, trung bình 8–12 tuần cho một thay đổi mà lẽ ra chỉ mất 2 tuần. Tệ hơn, không ai trong nội bộ hiểu được kiến trúc hệ thống, nên khi đối thủ tung tính năng mới, Bank A luôn chậm chân 2–3 quý. Chi phí "thay đổi" tích lũy sau 3 năm còn cao hơn cả chi phí xây ban đầu.

Bài học rút ra: App ngân hàng số chính là core differentiator — nơi khách hàng cảm nhận thương hiệu số. Khoán trắng core cho vendor đồng nghĩa với việc thuê ngoài luôn cả năng lực cạnh tranh và tốc độ. Đúng ra Bank A nên giữ in-house phần kiến trúc, product và logic nghiệp vụ lõi, chỉ dùng vendor cho phần bổ trợ.

Ví dụ 2 — Chuỗi bán lẻ dùng hybrid đúng cách

Một chuỗi bán lẻ FMCG với hơn 500 cửa hàng (gọi là Retail B) muốn chuyển đổi số toàn diện: app khách hàng thân thiết, hệ thống đề xuất khuyến mãi cá nhân hóa, và nâng cấp hệ thống quản lý kho.

Họ phân loại rất tỉnh táo. Phần core — dữ liệu khách hàng, engine cá nhân hóa khuyến mãi, và app thương hiệu — họ xây một đội in-house 25 người, dẫn dắt bởi một Head of Product và một Lead Engineer tuyển từ một công ty công nghệ. Phần context — hệ thống ERP quản lý kho và kế toán — họ mua giải pháp SAP và thuê một đối tác triển khai. Phần cần tăng tốc — khi cần dựng nhanh nền tảng trong 6 tháng — họ thuê thêm 40 kỹ sư qua staff augmentation từ một công ty gia công trong nước, nhưng làm việc dưới sự chỉ đạo kiến trúc của Lead Engineer nội bộ.

Kết quả sau 18 tháng: chi phí thấp hơn phương án tự tuyển toàn bộ khoảng 30%, tốc độ ra tính năng nhanh gấp đôi Bank A ở ví dụ trên, và quan trọng nhất — tri thức về engine cá nhân hóa nằm trong nhà. Khi hợp đồng staff augmentation kết thúc, hệ thống vẫn vận hành trơn tru vì người in-house nắm rõ.

Bài học rút ra: Hybrid sourcing hiệu quả khi bạn giữ "não" (kiến trúc, product, dữ liệu) trong nhà và thuê "tay chân" bên ngoài cho khối lượng công việc. Vendor tăng tốc, nhưng không sở hữu tri thức lõi.

Ví dụ 3 — Startup fintech và bài toán "mua để nhanh, tự làm để giữ"

Một startup ví điện tử tại Đông Nam Á (gọi là Fin C) ở giai đoạn đầu cần ra mắt trong 4 tháng để kịp gọi vốn. Họ không đủ thời gian tự xây mọi thứ. Quyết định của họ: mua phần context (cổng thanh toán qua nhà cung cấp payment gateway, hệ thống KYC qua một SaaS bên thứ ba, hạ tầng trên AWS managed services), nhưng tự xây phần core — trải nghiệm chuyển tiền tức thì và ví tích điểm, vì đó là điểm khác biệt.

Đến khi đạt 2 triệu người dùng, họ nhận ra chi phí trả cho SaaS KYC tính theo lượt xác thực đã lên tới hàng trăm nghìn USD/năm, và nhà cung cấp không hỗ trợ đủ nhanh cho thị trường mới. Lúc này Fin C mới bắt đầu nội hóa (insource) dần phần KYC — thứ ban đầu là context nhưng khi quy mô lớn đã dịch chuyển thành core về mặt chi phí và trải nghiệm.

Bài học rút ra: Ranh giới core/context không cố định. Ở giai đoạn đầu, "mua để nhanh" là quyết định đúng để ra thị trường. Nhưng khi quy mô tăng, một số thành phần context có thể trở thành core và cần nội hóa lại. Chiến lược sourcing phải được xem lại định kỳ, không phải quyết định một lần.

Hướng dẫn từng bước

Đây là quy trình 6 bước để ra quyết định sourcing cho một sáng kiến DT cụ thể:

Bước 1 — Lập danh mục năng lực (capability inventory). Liệt kê mọi năng lực và thành phần mà sáng kiến cần: engineering, product, data, hạ tầng, bảo mật, vận hành. Đừng gộp chung "làm app" — hãy tách thành các module cụ thể.

Bước 2 — Phân loại Core vs Context. Với mỗi thành phần, hỏi hai câu: (a) Nó có tạo lợi thế cạnh tranh không? (b) Khách hàng có cảm nhận sự khác biệt không? Nếu cả hai đều "có" → Core. Nếu cả hai đều "không" → Context. Nếu ở giữa → đánh dấu để theo dõi.

Bước 3 — Đánh giá năng lực nội bộ hiện có. Bạn đang có đội ngũ nào? Thiếu kỹ năng gì? Tuyển được không, mất bao lâu? Điều này quyết định bạn có buộc phải thuê ngoài tạm thời hay không.

Bước 4 — Chọn mô hình sourcing cho từng thành phần. Áp ma trận: Core → in-house; Context phổ thông → buy/managed service; cần tốc độ ngắn hạn → staff augmentation; năng lực mới chưa rõ → partnership. Chấp nhận là một sáng kiến sẽ dùng nhiều mô hình cùng lúc (hybrid).

Bước 5 — Thiết kế cơ chế giữ tri thức (knowledge retention). Nếu dùng vendor, yêu cầu rõ trong hợp đồng: tài liệu kiến trúc, chuyển giao mã nguồn, quyền sở hữu trí tuệ (IP), và điều khoản "exit" — bạn có thể rời vendor mà không bị khóa chặt (vendor lock-in). Luôn cắm ít nhất một kiến trúc sư in-house vào mọi đội có vendor.

Bước 6 — Thiết lập quản trị và đánh giá lại định kỳ. Đặt SLA rõ ràng, KPI cho vendor, và lịch review sourcing 6–12 tháng/lần. Chủ động hỏi: thành phần nào đã dịch chuyển từ context sang core? Cái gì nên nội hóa lại?

Lỗi thường gặp & mẹo

Lỗi 1 — Outsource cả phần core để "tiết kiệm". Đây là sai lầm đắt nhất. Chi phí ban đầu thấp nhưng bạn mất kiểm soát năng lực cạnh tranh. Mẹo: trước khi ký, hỏi "Nếu vendor này biến mất ngày mai, chúng ta còn vận hành và phát triển được không?" Nếu câu trả lời là không cho một thành phần core — đừng outsource nó.

Lỗi 2 — Đánh giá vendor chỉ bằng giá. Giá rẻ nhất thường đắt nhất về lâu dài (chất lượng thấp, phải làm lại, khó bảo trì). Mẹo: đánh giá theo tổng chi phí sở hữu (TCO) qua 3 năm, gồm cả chi phí thay đổi và chi phí thoát.

Lỗi 3 — Không có ai in-house "cầm lái". Giao 100% cho vendor mà không có product owner và kiến trúc sư nội bộ dẫn dắt là công thức mất tri thức. Mẹo: luôn giữ vai trò "két đen tri thức" trong nhà, dù đội thực thi là bên ngoài.

Lỗi 4 — Bỏ quên vendor lock-in. Chọn nền tảng độc quyền không có đường thoát khiến bạn bị "bắt làm con tin" về giá. Mẹo: ưu tiên chuẩn mở, API rõ ràng, và đàm phán quyền sở hữu dữ liệu + mã nguồn ngay từ đầu.

Lỗi 5 — Coi sourcing là quyết định một lần. Ranh giới core/context dịch chuyển. Mẹo: đưa "review sourcing" thành nghi thức định kỳ trong quản trị DT, giống như review ngân sách.

Mẹo tổng quát: Với năng lực mới và chưa chắc chắn, hãy dùng công thức "outsource để học, insource để giữ" — thuê ngoài lúc đầu để tiếp cận nhanh chuyên môn, rồi chủ động chuyển giao và nội hóa khi năng lực đó chứng minh là core.

Bài tập thực hành

Hãy áp dụng ngay vào bối cảnh của bạn:

• Chọn một sáng kiến DT đang hoặc sắp triển khai ở tổ chức của bạn (ví dụ: app khách hàng, hệ thống phân tích dữ liệu, tự động hóa quy trình).

• Lập bảng phân loại với 3 cột: Thành phần | Core hay Context (kèm lý do) | Mô hình sourcing đề xuất. Liệt kê ít nhất 6 thành phần và điền đầy đủ.

• Xác định "két đen tri thức". Với mỗi thành phần bạn định outsource, ghi rõ ai trong nội bộ sẽ giữ tri thức và làm sao (tài liệu, review kiến trúc, quyền truy cập mã nguồn).

• Bài kiểm tra "vendor biến mất". Với mỗi thành phần core, tự trả lời: nếu vendor rời đi sau 12 tháng, bạn có tiếp tục vận hành và phát triển được không? Nếu "không", hãy đề xuất một điều chỉnh sourcing để giảm rủi ro.

• Tính TCO 3 năm cho một quyết định "mua SaaS vs tự xây" cụ thể, gồm cả chi phí thay đổi và chi phí thoát, rồi rút ra kết luận.

Tóm tắt

• Sourcing là chiến lược "lấy năng lực từ đâu"; outsourcing chỉ là một lựa chọn trong đó. Quyết định này mang tính chiến lược, không đơn thuần là tiết kiệm chi phí.
• Nguyên tắc vàng: giữ Core trong nhà, thuê ngoài Context. Core là thứ tạo khác biệt cạnh tranh; context là thứ ai làm cũng như nhau.
• Thực tế trưởng thành nhất là mô hình hybrid: đội in-house nắm kiến trúc, product, dữ liệu và module lõi; đối tác bên ngoài đảm nhận khối lượng, context, và phần cần tăng tốc.
• Ranh giới core/context dịch chuyển theo thời gian và quy mô — hãy review sourcing định kỳ, nội hóa lại khi cần ("outsource để học, insource để giữ").
• Tránh 5 cái bẫy lớn: outsource core, chọn vendor theo giá, không có người cầm lái in-house, dính vendor lock-in, và coi sourcing là quyết định một lần.
• Luôn thiết kế cơ chế giữ tri thức và đường thoát (exit) ngay từ khi ký hợp đồng — đó là tấm bảo hiểm cho năng lực số của bạn.