Mở đầu — vì sao bài này quan trọng
Ở Bài 21, bạn đã học cách nhận diện (identify) các bên liên quan bằng RACI và Onion Model — tức là trả lời câu hỏi "Ai có mặt trong cuộc chơi này?". Nhưng nhận diện mới chỉ là bước một. Nếu một dự án có 30 stakeholder, bạn không thể đối xử với cả 30 người theo cùng một cách: gửi cùng một báo cáo, mời cùng một cuộc họp, dành cùng một lượng thời gian. Làm vậy bạn sẽ vừa làm phiền người không quan tâm, vừa bỏ rơi người đang nắm quyền sinh sát của dự án.
Bài 22 trả lời câu hỏi tiếp theo: "Trong những người đã nhận diện, ai quan trọng tới mức nào, và tôi nên dồn năng lượng quản lý vào đâu?". Đây chính là Stakeholder Analysis — phân tích bên liên quan. Một BA giỏi không phải người làm hài lòng tất cả mọi người; đó là người biết ưu tiên đúng người, đúng lúc, đúng liều lượng.
Trong bài này, chúng ta đi sâu vào hai công cụ phân tích kinh điển và bổ trợ cho nhau: Power/Interest Grid (lưới Quyền lực/Quan tâm, còn gọi là ma trận Mendelow) và Salience Model (mô hình Nổi bật của Mitchell, Agle & Wood). Lưới Power/Interest cho bạn một bức ảnh nhanh, dễ vẽ, dễ trình bày với sếp. Salience Model tinh vi hơn, giúp bạn xử lý những tình huống mà lưới 2x2 quá đơn giản. Nắm cả hai, bạn sẽ phân bổ thời gian, kênh giao tiếp và chiến lược can thiệp một cách có chủ đích thay vì làm theo cảm tính.
Khái niệm cốt lõi
Power/Interest Grid (ma trận Mendelow)
Power/Interest Grid là một ma trận 2x2, đặt mỗi stakeholder lên hệ trục dựa trên hai chiều:
- Power (Quyền lực): Khả năng của người đó tác động đến dự án — phê duyệt ngân sách, dừng dự án, thay đổi phạm vi, điều phối nguồn lực, hay vận động chính trị nội bộ. Quyền lực cao nghĩa là "lời nói của họ có sức nặng".
- Interest (Mức độ quan tâm): Mức độ kết quả dự án ảnh hưởng tới họ, và do đó họ chú ý theo dõi tới đâu. Người dùng cuối thường có interest rất cao vì hệ thống mới ảnh hưởng trực tiếp đến công việc hàng ngày của họ.
| Interest thấp | Interest cao | |
|---|---|---|
| Power cao | Keep Satisfied (Giữ hài lòng) | Manage Closely (Quản lý sát sao) |
| Power thấp | Monitor (Theo dõi, nỗ lực tối thiểu) | Keep Informed (Giữ thông tin đầy đủ) |
- Manage Closely (Power cao, Interest cao): Đây là nhóm quan trọng nhất. Họ vừa có quyền, vừa quan tâm sâu sắc. Ví dụ: Sponsor (nhà tài trợ dự án), Product Owner chủ chốt. Bạn phải làm việc chặt chẽ, mời họ vào các quyết định lớn, cập nhật thường xuyên, lắng nghe phản hồi nghiêm túc. Đây là nơi BA dồn phần lớn năng lượng.
- Keep Satisfied (Power cao, Interest thấp): Họ có quyền lực lớn nhưng hiện tại chưa chú ý nhiều tới dự án — ví dụ một Phó Tổng Giám đốc phụ trách mảng khác, hay Giám đốc Pháp chế. Nguy hiểm ở chỗ: nếu bạn để họ bất ngờ hoặc làm họ phật ý, họ có thể dùng quyền lực để cản trở. Chiến lược: giữ họ hài lòng, không làm phiền bằng tiểu tiết, nhưng cảnh báo sớm những gì chạm đến lợi ích của họ. Đừng để họ "nhảy" lên ô Manage Closely một cách tiêu cực.
- Keep Informed (Power thấp, Interest cao): Họ rất quan tâm nhưng ít quyền — điển hình là người dùng cuối, nhân viên vận hành. Họ là nguồn yêu cầu (requirements) quý giá và là người ủng hộ (hoặc phá hoại ngầm) khi triển khai. Hãy cung cấp thông tin đầy đủ, lắng nghe, để họ cảm thấy được tôn trọng. Họ có thể trở thành đồng minh giúp bạn thuyết phục nhóm Power cao.
- Monitor (Power thấp, Interest thấp): Nỗ lực tối thiểu. Theo dõi định kỳ phòng khi vị thế của họ thay đổi, nhưng đừng tiêu tốn nguồn lực. Ví dụ: một phòng ban chỉ bị ảnh hưởng gián tiếp.
Salience Model (mô hình Nổi bật)
Lưới Power/Interest có một hạn chế: nó bỏ qua yếu tố tính cấp bách và tính chính danh. Salience Model của Mitchell, Agle & Wood (1997) bổ sung bằng cách đánh giá mỗi stakeholder theo ba thuộc tính:
- Power (Quyền lực): Khả năng áp đặt ý chí lên dự án — giống chiều Power ở trên.
- Legitimacy (Tính chính danh): Việc họ tham gia/đòi hỏi có hợp lý, hợp pháp, đúng vai trò hay không. Ví dụ: cổ đông có tính chính danh đương nhiên; còn một nhóm cư dân khiếu nại có thể có hoặc không tùy bối cảnh.
- Urgency (Tính cấp bách): Yêu cầu của họ có đòi hỏi phản hồi gấp không, có nhạy cảm về thời gian và quan trọng với họ tới mức nào.
Nhóm tiềm ẩn (Latent) — chỉ có 1 thuộc tính, độ nổi bật thấp:
- Dormant (Ngủ đông) — chỉ có Power: có quyền nhưng chưa dùng vì chưa quan tâm hay chưa thấy cấp bách. Cần để mắt.
- Discretionary (Tùy nghi) — chỉ có Legitimacy: chính danh nhưng không quyền, không gấp. Ví dụ tổ chức từ thiện được công ty hỗ trợ.
- Demanding (Đòi hỏi) — chỉ có Urgency: liên tục kêu ca nhưng không quyền, không chính danh. Như "con muỗi vo ve" — phiền nhưng chưa nguy hiểm.
- Dominant (Chi phối) — Power + Legitimacy: có quyền và chính danh, là nhóm "chính thức" mà bạn không thể bỏ qua (ban lãnh đạo, cổ đông lớn).
- Dependent (Phụ thuộc) — Legitimacy + Urgency: chính danh và cấp bách nhưng thiếu quyền, phải dựa vào người khác để được lắng nghe (người dùng cuối khi xảy ra sự cố).
- Dangerous (Nguy hiểm) — Power + Urgency nhưng thiếu Legitimacy: có quyền, gấp gáp nhưng đòi hỏi không chính danh — có thể dùng biện pháp ép buộc, gây áp lực. Cần cảnh giác.
- Definitive: ưu tiên cao nhất. Phải phục vụ ngay và đầy đủ. Một Dominant stakeholder khi bỗng có yêu cầu cấp bách sẽ "thăng" lên Definitive.
Tình huống thực tế
Tình huống 1 — Dự án Core Banking tại một ngân hàng TMCP Việt Nam
Một ngân hàng thương mại cổ phần ở TP.HCM triển khai thay thế hệ thống core banking, ngân sách khoảng 8 triệu USD, kéo dài 18 tháng. BA dựng Power/Interest Grid:
- Manage Closely: Phó Tổng Giám đốc phụ trách Công nghệ (vừa duyệt ngân sách, vừa theo dõi sát từng sprint).
- Keep Satisfied: Giám đốc Khối Pháp chế & Tuân thủ — quyền rất lớn (có thể chặn go-live nếu vi phạm quy định Ngân hàng Nhà nước) nhưng interest hàng ngày thấp, chỉ quan tâm khi đụng đến compliance.
- Keep Informed: Hơn 400 giao dịch viên tại các chi nhánh — quan tâm cực cao vì hệ thống mới đổi toàn bộ thao tác nghiệp vụ, nhưng quyền cá nhân thấp.
- Monitor: Phòng Truyền thông nội bộ.
Tình huống 2 — Một startup giao đồ ăn ở Đông Nam Á và nhóm tài xế
Một nền tảng giao đồ ăn (tạm gọi "FoodNow") ra mắt tính năng tính phí ship động (dynamic pricing) theo giờ cao điểm. BA chỉ phân tích bằng Power/Interest Grid và xếp đội ngũ tài xế vào ô Keep Informed — interest cao, power thấp (từng cá nhân tài xế không quyết định được gì).
Nhưng khi tính năng ra mắt, vài trăm tài xế tự tổ chức trên các nhóm Facebook, đồng loạt tắt app vào giờ cao điểm và đăng bài lên báo. Lúc này, soi qua Salience Model, ta thấy bản chất đã đổi: tài xế ban đầu là Dependent (Legitimacy + Urgency, thiếu Power). Nhưng khi họ tập hợp lại và thu hút truyền thông, họ có thêm Power — chuyển thành Definitive stakeholder, buộc ban lãnh đạo phải họp khẩn và điều chỉnh chính sách trong 72 giờ.
Bài học: Power/Interest Grid chụp một khoảnh khắc tĩnh. Salience Model nhắc bạn rằng Urgency + Legitimacy có thể tạo ra Power khi nhóm yếu thế liên kết lại. BA cần lường trước kịch bản dịch chuyển này, đặc biệt với các nhóm đông và có khả năng tổ chức.
Tình huống 3 — Dự án ERP và một nhà cung cấp "Dangerous"
Một doanh nghiệp sản xuất ở Bình Dương triển khai ERP. Một nhà cung cấp phần mềm bên thứ ba (đối tác tích hợp) liên tục đòi mở rộng phạm vi tích hợp để bán thêm module, dù điều đó không nằm trong hợp đồng và không phục vụ mục tiêu dự án. Họ có Power (nắm know-how kỹ thuật quan trọng) và tạo Urgency (dọa chậm tiến độ nếu không chốt sớm), nhưng yêu cầu thiếu Legitimacy (không đúng phạm vi đã ký).
Theo Salience Model, đây là Dangerous stakeholder — Power + Urgency, thiếu Legitimacy. BA tham mưu cho PM: không nhượng bộ trước áp lực thời gian giả tạo, đưa Change Control vào (sẽ học kỹ ở Bài 31), và yêu cầu mọi mở rộng phải qua phê duyệt chính thức. Nhận diện đúng "Dangerous" giúp đội dự án không bị dắt mũi.
Hướng dẫn từng bước
Dưới đây là quy trình thực hành để phân tích stakeholder từ danh sách đã nhận diện ở Bài 21:
- Lập danh sách đầu vào: Lấy danh sách stakeholder từ Onion Model/RACI. Đảm bảo mỗi người/nhóm có tên rõ ràng và vai trò.
- Chấm điểm hai chiều cho Power/Interest Grid: Với mỗi stakeholder, cho điểm Power (1–5) và Interest (1–5). Dùng câu hỏi định hướng: "Người này có thể dừng/thay đổi dự án không?" (Power), "Kết quả dự án ảnh hưởng tới họ nhiều không?" (Interest). Nên chấm theo nhóm BA + PM để giảm thiên kiến cá nhân.
- Vẽ lưới và đặt từng người vào ô: Lấy mốc giữa (ví dụ ≥3 là "cao") để chia bốn ô. Ghi tên vào ô tương ứng. Dùng Miro, Lucidchart hoặc đơn giản là một slide.
- Gắn chiến lược cho từng ô: Manage Closely / Keep Satisfied / Keep Informed / Monitor. Với mỗi stakeholder quan trọng, ghi rõ kênh giao tiếp và tần suất (chi tiết về tailoring message sẽ học ở Bài 23).
- Soi lại bằng Salience Model với các ca khó: Với những stakeholder gây tranh cãi hoặc khó xếp, đánh giá ba thuộc tính Power/Legitimacy/Urgency (mỗi cái Có/Không) để xác định loại trong 7 nhóm. Đặc biệt chú ý các nhóm Dangerous, Dependent, và những ai có thể "thăng" lên Definitive.
- Dự đoán dịch chuyển: Tự hỏi "Điều gì khiến người này đổi ô?". Ghi chú các trigger (đổi sếp, sự cố, mốc go-live, áp lực truyền thông) để chủ động ứng phó.
- Ghi vào Stakeholder Register và rà soát định kỳ: Lưu kết quả vào sổ đăng ký stakeholder. Cập nhật ở mỗi milestone hoặc khi bối cảnh thay đổi đáng kể.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Power với chức danh. Một người có chức danh cao chưa chắc có quyền lực thực sự với dự án cụ thể của bạn; ngược lại, một chuyên viên kỳ cựu có thể có "quyền lực mềm" rất lớn. Hãy chấm Power theo ảnh hưởng thực tế lên dự án này, không theo sơ đồ tổ chức.
Lỗi 2 — Coi lưới là tĩnh và làm một lần rồi quên. Stakeholder dịch chuyển liên tục. Lưới làm ở tuần đầu sẽ lỗi thời sau ba tháng. Mẹo: đưa việc rà soát stakeholder vào checklist của mỗi mốc dự án.
Lỗi 3 — Bỏ rơi nhóm Keep Satisfied vì "họ ít quan tâm". Đây là cái bẫy kinh điển (như Tình huống 1). Power cao luôn nguy hiểm khi bị bất ngờ. Mẹo: thiết lập "cơ chế cảnh báo sớm" — chỉ liên hệ họ khi có gì chạm tới lợi ích của họ, nhưng phải liên hệ trước khi vấn đề nổ ra.
Lỗi 4 — Đối xử với người dùng cuối như nhóm Monitor. Họ thuộc Keep Informed/Dependent — quyền thấp nhưng là nguồn requirements và là người quyết định thành bại lúc triển khai. Bỏ rơi họ là tự chuốc lấy kháng cự (resistance) sau này.
Lỗi 5 — Chấm điểm một mình theo cảm tính. Thiên kiến cá nhân rất mạnh. Mẹo: chấm theo nhóm, và khi bất đồng, hỏi "Bằng chứng nào cho thấy người này Power cao?".
Mẹo nâng cao: Dùng màu sắc để biểu thị thái độ (ủng hộ/trung lập/phản đối) chồng lên lưới — ví dụ chấm xanh cho người ủng hộ, đỏ cho người phản đối. Một stakeholder ở ô Manage Closely mà màu đỏ chính là rủi ro lớn nhất cần xử lý ngay.
Bài tập thực hành
Bối cảnh giả định: Bạn là BA cho dự án ra mắt ứng dụng đặt lịch khám bệnh trực tuyến của một chuỗi phòng khám tư tại Hà Nội. Các bên liên quan gồm: (1) Tổng Giám đốc chuỗi phòng khám — duyệt ngân sách, kỳ vọng cao; (2) Trưởng phòng IT — triển khai kỹ thuật, theo sát; (3) Đội ngũ bác sĩ — lịch của họ bị hệ thống quản lý, lo ngại đổi thói quen; (4) Bệnh nhân/người dùng cuối; (5) Sở Y tế — cơ quan quản lý về dữ liệu y tế nhạy cảm; (6) Nhà cung cấp cổng thanh toán; (7) Phòng Marketing.
Yêu cầu:
- Chấm điểm Power (1–5) và Interest (1–5) cho cả 7 stakeholder và đặt họ vào Power/Interest Grid. Gắn chiến lược cho từng người.
- Với đội ngũ bác sĩ và Sở Y tế, hãy phân tích thêm bằng Salience Model (đánh giá Power/Legitimacy/Urgency) và xác định họ thuộc loại nào trong 7 nhóm.
- Đề xuất một kịch bản dịch chuyển: nêu một sự kiện có thể khiến một stakeholder đổi ô, và bạn sẽ phản ứng thế nào.
Tóm tắt
- Stakeholder Analysis là bước tiếp nối sau nhận diện (Bài 21): không chỉ biết "ai có mặt" mà còn biết "ai quan trọng tới đâu" để phân bổ năng lượng quản lý đúng chỗ.
- Power/Interest Grid (Mendelow) là ma trận 2x2 nhanh, dễ dùng, chia stakeholder thành bốn nhóm với bốn chiến lược: Manage Closely, Keep Satisfied, Keep Informed, Monitor.
- Salience Model (Mitchell, Agle & Wood) tinh vi hơn, dùng ba thuộc tính Power – Legitimacy – Urgency để tạo bảy loại stakeholder, đặc biệt giúp xử lý các ca động và các nhóm như Dangerous, Dependent, Definitive.
- Vị trí stakeholder luôn dịch chuyển: một thuộc tính được kích hoạt (urgency trong khủng hoảng, power khi nhóm yếu thế liên kết) có thể đổi hoàn toàn cách bạn phải ứng xử.
- Lỗi nguy hiểm nhất là bỏ rơi nhóm Power cao – Interest thấp; hãy luôn có cơ chế cảnh báo sớm cho họ.
- Kết quả phân tích cần lưu vào Stakeholder Register và rà soát ở mỗi mốc dự án — đây là đầu vào cho Bài 23 (tailoring thông điệp theo từng tầng) và Bài 26 (xử lý stakeholder khó tính).