Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.109 người đã truy cậpPhiên bản 1.15.0
  1. /Rủi ro & thay đổi
  2. /Khi cả dự án dựa vào một nhà cung cấp duy nhất: …
Rủi ro & thay đổi· Domain: Sự không chắc chắn (rủi ro)

Khi cả dự án dựa vào một nhà cung cấp duy nhất: nhận diện và giảm rủi ro "khoá nhà cung cấp" (vendor lock-in)

Chọn một nhà cung cấp duy nhất giúp dự án nhanh và gọn, nhưng cũng tạo ra sự phụ thuộc: chi phí chuyển đổi cao, khó đàm phán, và rủi ro lớn nếu nhà cung cấp gặp sự cố. Bài viết giúp PM nhận diện các tầng phụ thuộc và chọn biện pháp giảm rủi ro phù hợp ngay từ giai đoạn mua sắm.

HP
Nguyễn Thu Hà, PMP
16/09/2026
5 phút đọc 0 0

Tình huống minh hoạ

Tình huống và số liệu dưới đây là giả định, dùng để minh hoạ.

Một công ty logistics triển khai hệ thống quản lý vận tải (TMS) dạng phần mềm dịch vụ (SaaS) của một nhà cung cấp nhỏ, giá cạnh tranh, tuỳ biến nhanh. Ba năm sau, hệ thống đã gắn với mọi hoạt động: điều phối xe, tính cước, xuất hoá đơn, kết nối với 12 khách hàng lớn.

Rồi một loạt sự việc xảy ra:

  • Nhà cung cấp thông báo tăng giá gia hạn đáng kể. Công ty muốn đàm phán nhưng nhận ra không có phương án thay thế khả thi trong ngắn hạn.
  • Khi yêu cầu xuất toàn bộ dữ liệu lịch sử để phân tích, nhà cung cấp chỉ cung cấp được file theo định dạng riêng, thiếu nhiều trường.
  • Các kết nối với khách hàng được xây bằng giao diện lập trình (API) riêng của nhà cung cấp; chuyển sang hệ thống khác nghĩa là làm lại toàn bộ.
  • Có tin nhà cung cấp đang được một đối thủ cạnh tranh của công ty mua lại.

Không có rủi ro nào trong số này xuất hiện trong sổ đăng ký rủi ro của dự án triển khai ba năm trước.

Khoá nhà cung cấp là gì

Vendor lock-in mô tả tình trạng khách hàng phụ thuộc vào một nhà cung cấp đến mức chi phí chuyển sang nhà cung cấp khác trở nên quá cao. Chi phí chuyển đổi không chỉ là tiền bản quyền mới, mà gồm cả chuyển đổi dữ liệu, làm lại tích hợp, đào tạo lại người dùng và rủi ro gián đoạn vận hành. Hiện tượng này đặc biệt phổ biến với dịch vụ đám mây và phần mềm có định dạng dữ liệu hoặc giao diện độc quyền.

Cần phân biệt hai khái niệm trong mua sắm:

  • Single sourcing: chủ động chọn một nhà cung cấp dù có các lựa chọn khác, để đổi lấy giá tốt, quan hệ chặt chẽ hoặc tốc độ.
  • Sole sourcing: chỉ có một nhà cung cấp duy nhất trên thị trường đáp ứng được yêu cầu.

Cả hai đều tạo ra phụ thuộc, nhưng single sourcing là một quyết định có thể cân nhắc lại, còn sole sourcing là ràng buộc của thị trường.

Phân tích theo PMBOK® Guide

Trong PMBOK® Guide, rủi ro liên quan đến nhà cung cấp thuộc phạm vi của cả quản lý rủi ro và quản lý mua sắm. Ấn bản 7 nhấn mạnh trong lĩnh vực hiệu suất Uncertainty rằng PM cần xem xét các phương án tạo khả năng phục hồi (resilience) và cân nhắc rủi ro ở mức tổng thể dự án lẫn mức lợi ích dài hạn.

Điểm đáng chú ý: nhiều rủi ro khoá nhà cung cấp không xảy ra trong vòng đời dự án, mà xảy ra trong giai đoạn vận hành sau đó. PM có trách nhiệm nêu chúng ra trong giai đoạn mua sắm và ghi vào kế hoạch chuyển giao, vì đó là lúc có nhiều đòn bẩy đàm phán nhất.

Các tầng phụ thuộc cần nhận diện

Tình huống liên quan

Rủi ro & thay đổiSự không chắc chắn (rủi ro)

Hai rủi ro cùng điểm 0,18 nhưng một rủi ro sẽ đến trong hai tuần: thêm tính cấp bách, độ gần và khả năng phát hiện vào phân tích định tính

Ma trận xác suất – tác động cho hai rủi ro cùng một điểm số, nhưng một rủi ro có thể xảy ra ngay tuần sau và gần như không phát hiện trước được. Bài viết hướng dẫn bổ sung các tham số như tính cấp bách, độ gần, khả năng phát hiện và khả năng kiểm soát để xếp hạng rủi ro sát thực tế hơn.

Ngày đăng: 29/10/2026Lượt xem: 0Bình luận: 0
Rủi ro & thay đổiSự không chắc chắn (rủi ro)

Dự phòng 10% "theo lệ": tính dự phòng cho rủi ro đã biết từ EMV của cả mối đe doạ lẫn cơ hội

Nhiều dự án cộng một khoản dự phòng 10% mà không ai giải thích được từ đâu ra. Bài viết hướng dẫn tính khoản dự phòng cho rủi ro đã nhận diện từ giá trị tiền tệ kỳ vọng (EMV), bù trừ mối đe doạ với cơ hội, và chỉ ra khi nào phép cộng EMV không còn đủ.

Ngày đăng: 22/10/2026Lượt xem: 0Bình luận: 0
Rủi ro & thay đổiSự không chắc chắn (rủi ro)

Có nên chi 150 triệu khảo sát địa chất trước khi chọn phương án móng? Tính giá trị kỳ vọng của thông tin hoàn hảo (EVPI)

Trước một quyết định có nhiều bất định, đội dự án thường muốn "tìm hiểu thêm" — khảo sát, làm mẫu thử, thuê chuyên gia. Nhưng thông tin cũng tốn tiền và thời gian. Giá trị kỳ vọng của thông tin hoàn hảo (EVPI) cho biết mức trần mà việc tìm hiểu thêm đáng được chi.

Ngày đăng: 16/10/2026Lượt xem: 0Bình luận: 0
Rủi ro & thay đổiSự không chắc chắn (rủi ro)

Sổ rủi ro mỗi tuần một dài nhưng rủi ro có giảm không? Theo dõi tổng phơi nhiễm bằng biểu đồ risk burndown

Báo cáo rủi ro thường chỉ đếm số dòng trong sổ, và con số đó chẳng nói lên điều gì. Biểu đồ risk burndown theo dõi tổng mức phơi nhiễm qua từng sprint hoặc từng tháng, giúp đội dự án và nhà tài trợ thấy rủi ro có thực sự được "đốt" đi hay không.

Ngày đăng: 10/10/2026Lượt xem: 0Bình luận: 0
TầngCâu hỏi kiểm tra
Dữ liệuCó xuất được toàn bộ dữ liệu theo định dạng mở, đầy đủ, khi nào cũng được không?
Tích hợpKết nối với hệ thống khác dùng chuẩn mở hay giao diện độc quyền?
Tri thứcAi hiểu cấu hình và tuỳ biến — chỉ nhà cung cấp hay cả đội nội bộ?
Hợp đồngĐiều khoản tăng giá, chấm dứt, chuyển giao khi kết thúc hợp đồng như thế nào?
Sự tồn tại của nhà cung cấpNếu nhà cung cấp phá sản, bị mua lại hay ngừng sản phẩm thì sao?

Các chiến lược ứng phó

Áp dụng các chiến lược ứng phó rủi ro tiêu cực quen thuộc:

  • Né tránh (avoid): chọn giải pháp dựa trên chuẩn mở, hoặc chia hệ thống thành các phần có thể thay thế độc lập. Chi phí ban đầu có thể cao hơn.
  • Giảm thiểu (mitigate):
    • Điều khoản hợp đồng bắt buộc xuất dữ liệu theo định dạng mở, có thời hạn và hỗ trợ khi chấm dứt.
    • Xây lớp tích hợp trung gian của riêng tổ chức thay vì để mọi hệ thống gọi thẳng API của nhà cung cấp.
    • Đào tạo đội nội bộ hiểu cấu hình, lưu tài liệu tuỳ biến.
    • Định kỳ thử xuất dữ liệu thật để chắc chắn quy trình hoạt động.
  • Chuyển giao (transfer): ký quỹ mã nguồn (source code escrow) — mã nguồn được gửi cho bên thứ ba giữ, và khách hàng được nhận khi xảy ra các điều kiện thoả thuận như nhà cung cấp phá sản hay ngừng hỗ trợ. Cần lưu ý: có mã nguồn chưa đồng nghĩa với có khả năng vận hành nó.
  • Chấp nhận (accept): với hệ thống ít quan trọng, chấp nhận rủi ro một cách có ý thức, ghi lại và có kế hoạch dự phòng sơ bộ.

Một chiến lược thoát (exit strategy) — kế hoạch chuyển sang phương án khác nếu cần — nên được lập từ đầu, kể cả khi nhiều khả năng không bao giờ dùng đến. Nó cũng gắn với kế hoạch kinh doanh liên tục (business continuity) của tổ chức.

Kết luận

Chọn một nhà cung cấp duy nhất không phải là sai lầm; nhiều khi đó là lựa chọn hợp lý. Sai lầm là chọn mà không nhìn thấy sự phụ thuộc đang được tạo ra. PM nên đưa các tầng phụ thuộc vào sổ đăng ký rủi ro ngay từ giai đoạn mua sắm, đàm phán điều khoản thoát khi còn đòn bẩy, và bàn giao cho đội vận hành cả hệ thống lẫn kế hoạch thoát.

Nguồn tham khảo

  • Wikipedia – Vendor lock-in (khoá nhà cung cấp, chi phí chuyển đổi)
  • Wikipedia – Single sourcing (chọn một nhà cung cấp trong mua sắm)
  • Wikipedia – Source code escrow (ký quỹ mã nguồn)
  • Wikipedia – Business continuity planning (kế hoạch kinh doanh liên tục)
#vendor-lock-in#rui-ro-nha-cung-cap#single-sourcing#source-code-escrow#Chiến lược thoát

Biểu mẫu tải về

  • Hướng dẫn quản lý rủi ro bị khoá vào nhà cung cấp đám mây (Chính phủ Anh)Hướng dẫn của GOV.UK về các dạng phụ thuộc kỹ thuật vào nhà cung cấp, khi nào chấp nhận được và cách theo dõi, lập kế hoạch rút lui (exit plan). Dùng làm danh sách kiểm tra khi đánh giá rủi ro vendor lock-in và soạn điều khoản chuyển đổi nhà cung cấp. Trực tuyến.gov.uk · 0 lượt mở
    Mở liên kết

Trắc nghiệm tình huống PMP

Câu 1/1
Dự án chọn một nhà cung cấp phần mềm nhỏ, duy nhất cho hệ thống lõi. PM lo ngại tổ chức không thể vận hành hệ thống nếu nhà cung cấp phá sản. Biện pháp nào sau đây là chiến lược CHUYỂN GIAO (transfer) rủi ro này?

Bạn chọn phương án nào?

Nhà cung cấp SaaS tốt nhất trong vòng đánh giá chỉ hỗ trợ xuất dữ liệu theo định dạng riêng. Bạn chọn cách nào?

Bài viết hữu ích? Chia sẻ cho đồng nghiệp nhé!

Đánh giá bài viết

Bình luận

Mục lục

Tình huống minh hoạKhoá nhà cung cấp là gìPhân tích theo PMBOK® GuideCác tầng phụ thuộc cần nhận diệnCác chiến lược ứng phóKết luậnNguồn tham khảoBiểu mẫu tải vềTrắc nghiệmBình chọn
Quảng cáoBộ đề thi thử PMP (mẫu)
Quảng cáoTemplate quản lý dự án (mẫu)