title: "Cách xử lý các bên liên quan (Stakeholder Management): Khi khách hàng có quá nhiều "sếp" chỉ đạo trái ngược nhau"
series: "Thư viện Kỹ năng BA·PO·EA: 45 Bài học Thực chiến"
part: "Phần 2 — Kỹ năng Thực chiến"
skill_number: 30
audience: "BA, PO, EA & vai trò làm việc trực tiếp với khách hàng"
reading_time: "10 phút đọc"
tags: ["stakeholder-management", "power-interest-grid", "BA", "quan-ly-cac-ben-lien-quan", "facilitation"]

Cách xử lý các bên liên quan (Stakeholder Management): Khi khách hàng có quá nhiều "sếp" chỉ đạo trái ngược nhau

Bạn đã bao giờ rơi vào cảnh sáng nhận yêu cầu từ Trưởng phòng IT, chiều nhận yêu cầu ngược lại từ Trưởng phòng Kinh doanh, rồi tối muộn nhận thêm một email "góp ý" từ Phó Tổng phụ trách vận hành — cả ba đều nói họ là người quyết định cuối cùng? Nếu câu trả lời là có, bạn không đơn độc: đây là tình huống gần như chắc chắn xảy ra ở bất kỳ dự án nào có từ hai phòng ban trở lên tham gia. Vấn đề không phải là ai đúng ai sai, mà là bạn — người ở giữa — không có bản đồ để biết nên nghe ai, nghe đến đâu, và im lặng với ai.

🎯 Kỹ thuật cốt lõi: Ma trận Quyền lực – Quan tâm (Power-Interest Grid)

Đây là công cụ kinh điển trong quản trị dự án, nhưng phần lớn người dùng nó sai vì chỉ vẽ ra một lần rồi bỏ ngăn kéo. Cách dùng đúng là xem nó như một "bảng điều phối sống", cập nhật theo diễn biến dự án.

Nguyên lý: mọi stakeholder (bên liên quan) đều có thể định vị trên hai trục:

• Trục Quyền lực (Power): Người này có khả năng ảnh hưởng đến quyết định, ngân sách, phạm vi, hoặc thành/bại của dự án đến mức nào? (Có thể duyệt/chặn ngân sách? Có quyền ký nghiệm thu? Có thể rút nhân sự?)
• Trục Quan tâm (Interest): Người này bị ảnh hưởng bởi kết quả dự án đến mức nào, và họ đang thực sự để tâm đến nó đến đâu? (Công việc hàng ngày của họ thay đổi ra sao? Họ có đang theo sát từng buổi họp không?)

Giao nhau tạo thành 4 ô, mỗi ô một chiến lược khác nhau:

Cách dùng tổng quát để áp cho tình huống của chính bạn:

1. Liệt kê hết — viết ra mọi cá nhân/phòng ban có dính dáng đến dự án, kể cả người bạn nghĩ là "không liên quan lắm".
2. Chấm điểm 2 trục — cho mỗi người một điểm Quyền lực (1-5) và một điểm Quan tâm (1-5), dựa trên bằng chứng thực tế (ai ký hợp đồng, ai duyệt ngân sách, ai từng phát biểu trong họp) chứ không phải cảm tính chức danh.
3. Định vị lên ma trận — đặt từng người vào 1 trong 4 ô.
4. Thiết kế chiến lược tương tác riêng cho từng ô — tần suất họp, kênh liên lạc, mức độ chi tiết thông tin, ai cần đồng thuận trước khi triển khai.
5. Cập nhật lại mỗi giai đoạn — vị trí của một người có thể dịch chuyển (ví dụ: một Trưởng phòng vốn ở ô "Giám sát" có thể nhảy sang "Quản lý sát sao" khi dự án động chạm trực tiếp đến KPI phòng họ).

Điểm mấu chốt: ma trận này không phải để phân biệt đối xử, mà để phân bổ năng lượng có giới hạn của bạn đúng chỗ — thay vì cố gắng làm hài lòng tất cả mọi người ở mức độ như nhau, một việc chắc chắn thất bại khi có nhiều "sếp" đối lập.

Bối cảnh (Situation)

Tình huống dưới đây là minh hoạ tổng hợp từ các dự án CNTT thường gặp tại Việt Nam, không phải case cụ thể của một công ty có thật.

Chị H., BA của một công ty triển khai hệ thống quản lý đơn hàng (order management) cho một doanh nghiệp phân phối bán lẻ vừa và lớn, bước vào tuần thứ ba của giai đoạn khảo sát yêu cầu (requirement gathering). Dự án có ba phòng ban phía khách hàng cùng tham gia: phòng IT (chịu trách nhiệm tích hợp hệ thống), phòng Kinh doanh (người dùng cuối chính, quan tâm tốc độ xử lý đơn), và phòng Vận hành kho (quan tâm quy trình đối soát tồn kho).

Vấn đề bắt đầu lộ rõ khi chị H. đưa ra bản đặc tả quy trình duyệt đơn hàng (order approval flow) để lấy ý kiến. Trưởng phòng IT khăng khăng đòi tự động hoá 90% bước duyệt để giảm tải hệ thống và đơn giản hoá tích hợp. Trưởng phòng Kinh doanh phản đối gay gắt, nói rằng đội sales cần quyền can thiệp thủ công ở mọi bước để linh hoạt với khách VIP. Trưởng phòng Vận hành kho thì lại yêu cầu thêm một bước kiểm tra tồn kho bắt buộc mà cả hai bên kia đều cho là "làm chậm hệ thống không cần thiết".

Ba chỉ đạo, ba hướng khác nhau, và cả ba đều gửi email trực tiếp cho chị H. với dòng chữ tương tự nhau: "Bên tôi làm việc trực tiếp với sếp lớn, đề nghị làm theo hướng này."

Thách thức (Task)

Cái khó của chị H. không phải là kỹ thuật — quy trình nào cũng làm được về mặt hệ thống. Cái khó nằm ở chỗ: không ai trong ba người trên nói rõ ai mới thực sự là người ký duyệt cuối cùng, và bản thân chị H. cũng chưa từng ngồi lại để xác định điều đó một cách chính thức.

Nếu chị H. chạy theo từng người một, sửa đặc tả theo yêu cầu của người vừa gặp gần nhất, sẽ xảy ra hai hậu quả: (1) tài liệu đặc tả bị đảo chiều liên tục, mất uy tín với cả ba phòng vì ai cũng thấy ý kiến của phòng khác "được ưu tiên hơn" tại một thời điểm nào đó; (2) dự án trễ tiến độ vì vòng lặp duyệt-sửa-duyệt lại không có điểm dừng, bởi không có tiêu chí nào để biết khi nào đặc tả được coi là "chốt".

Nguy hiểm hơn, nếu để leo thang tự nhiên, ba trưởng phòng có thể mang mâu thuẫn lên thẳng cấp Giám đốc, khi đó câu chuyện sẽ biến từ "vấn đề nghiệp vụ" thành "vấn đề chính trị nội bộ", và công ty triển khai (bên chị H.) dễ bị quy trách nhiệm là "không kiểm soát được yêu cầu" — trong khi bản chất là khách hàng chưa thống nhất nội bộ.

Hành động (Action)

Chị H. dừng việc phản hồi từng email riêng lẻ và dành nửa ngày để xử lý bài toán ở tầng cấu trúc, theo các bước sau:

Bước 1 — Liệt kê toàn bộ stakeholder liên quan đến quy trình duyệt đơn, không chỉ ba người đang lên tiếng. Chị H. thêm vào danh sách: Giám đốc vận hành (người sẽ ký nghiệm thu cuối), một nhân viên sales kỳ cựu hay được tham vấn không chính thức, và bộ phận kế toán (bị ảnh hưởng gián tiếp bởi thời điểm ghi nhận đơn hàng).

Bước 2 — Thu thập bằng chứng, không suy đoán, để chấm điểm hai trục. Chị H. kiểm tra lại: ai là người ký hợp đồng dự án (Giám đốc vận hành), ai có ngân sách để yêu cầu phát sinh thêm hạng mục (Giám đốc vận hành và Trưởng phòng IT), ai chỉ đưa ý kiến nhưng không có quyền chặn tiến độ (nhân viên sales kỳ cựu). Việc này chị H. làm bằng cách xem lại văn bản uỷ quyền dự án (project charter) đã ký ở giai đoạn kick-off, chứ không dựa vào ai nói to hơn trong họp.

Bước 3 — Vẽ ma trận thực tế:

• Quản lý sát sao: Giám đốc vận hành (quyền lực cao — người ký cuối; quan tâm cao — trực tiếp chịu trách nhiệm với ban lãnh đạo về dự án này).
• Giữ hài lòng: Trưởng phòng IT (quyền lực cao vì nắm hạ tầng và tích hợp, nhưng thực ra không quá quan tâm đến chi tiết nghiệp vụ duyệt đơn — điều họ cần là hệ thống ổn định, dễ maintain).
• Thông báo đầy đủ: Trưởng phòng Kinh doanh (quan tâm rất cao vì ảnh hưởng trực tiếp công việc hàng ngày của đội sales, nhưng quyền lực quyết định về kiến trúc quy trình thực ra thấp hơn Giám đốc vận hành).
• Giám sát: Trưởng phòng Vận hành kho và kế toán (quan tâm và quyền lực đều ở mức vừa phải với riêng quy trình duyệt đơn, dù họ quan trọng ở các hạng mục khác của dự án).

Bước 4 — Thiết kế lại cách tương tác cho từng ô, thay vì đối xử như nhau:

• Với Giám đốc vận hành: chị H. đặt lịch một buổi trao đổi 1-1 riêng, mang theo bản so sánh ba phương án (của IT, Kinh doanh, Vận hành kho) kèm phân tích được-mất, và xin quyết định làm "trọng tài" chính thức.
• Với Trưởng phòng IT: gửi tóm tắt ngắn về hướng đi cuối cùng kèm lý do, không mời họp thêm trừ khi có thay đổi ảnh hưởng đến kiến trúc hệ thống.
• Với Trưởng phòng Kinh doanh: tổ chức một buổi riêng để lắng nghe kỹ lo ngại về tính linh hoạt cho khách VIP, ghi nhận rõ ràng bằng văn bản, và cam kết đưa ý kiến này vào bản trình lên Giám đốc vận hành — dù quyền quyết định không nằm ở họ, họ cần thấy tiếng nói của mình được xử lý nghiêm túc.
• Với Trưởng phòng Vận hành kho và kế toán: gửi email cập nhật định kỳ, không cần họp riêng trừ khi phương án cuối ảnh hưởng trực tiếp quy trình của họ.

Bước 5 — Đưa vấn đề lên đúng người có quyền lực cao nhất để chốt, thay vì để nó trôi nổi giữa các trưởng phòng ngang cấp. Chị H. trình bày với Giám đốc vận hành ba phương án dưới dạng bảng so sánh (mức độ tự động hoá, tác động đến tốc độ xử lý, rủi ro tồn kho), đề xuất một phương án trung dung (tự động hoá 70% bước duyệt, giữ điểm can thiệp thủ công cho đơn giá trị cao, thêm bước kiểm tra tồn kho nhưng chạy song song thay vì tuần tự để không làm chậm hệ thống), và xin quyết định cuối cùng bằng văn bản.

Kết quả (Result)

Giám đốc vận hành đồng ý với phương án trung dung sau một buổi trao đổi, và quan trọng hơn — quyết định được ghi thành văn bản gửi cho cả ba trưởng phòng, nêu rõ đây là quyết định cấp quản lý dự án, không phải ý kiến cá nhân của BA. Nhờ vậy, khi Trưởng phòng Kinh doanh còn muốn phản đối thêm một lần nữa sau đó, họ phản đối với cấp trên của mình chứ không còn gây áp lực trực tiếp lên chị H. nữa.

Tiến độ khảo sát yêu cầu được chốt đúng hạn, thay vì kéo dài thêm ít nhất một tuần như xu hướng ban đầu. Tài liệu đặc tả không còn bị đảo chiều liên tục.

Điều chưa hoàn hảo: quy trình song song kiểm tra tồn kho về sau khi triển khai thực tế phát sinh một số trường hợp race-condition (tranh chấp dữ liệu) hiếm gặp giữa bước duyệt và bước trừ kho, phải vá thêm ở giai đoạn UAT (kiểm thử nghiệm thu). Chị H. cũng thừa nhận nếu vẽ ma trận này ngay từ tuần đầu tiên của dự án — thay vì đợi đến khi mâu thuẫn bùng lên — có thể đã tránh được cả tuần tranh cãi qua lại giữa ba phòng.

📋 Áp dụng ngay

• Ngay khi dự án có từ 2 phòng ban khách hàng trở lên, dành 1-2 giờ đầu tiên vẽ ma trận Quyền lực-Quan tâm cho toàn bộ stakeholder, dựa trên văn bản uỷ quyền/hợp đồng, không dựa vào chức danh hay ai nói to nhất.
• Với mỗi stakeholder ở ô "Quản lý sát sao", chủ động đặt lịch trao đổi riêng định kỳ thay vì chỉ gặp khi có vấn đề.
• Khi hai stakeholder cùng quyền lực cao đưa chỉ đạo trái ngược, đừng tự đứng ra làm trọng tài — tìm người có quyền lực cao hơn cả hai để chốt, và luôn yêu cầu quyết định bằng văn bản.
• Cập nhật lại ma trận mỗi khi dự án chuyển giai đoạn lớn (khảo sát → thiết kế → triển khai), vì vị trí của một người có thể dịch chuyển.
• Với stakeholder ở ô "Thông báo đầy đủ", luôn ghi nhận ý kiến của họ bằng văn bản trước khi trình phương án lên cấp cao hơn — họ cần cảm thấy được lắng nghe dù không có quyền quyết định cuối.

💡 Bài học đúc rút (Key Takeaway): Khi khách hàng có nhiều "sếp" chỉ đạo trái ngược nhau, việc bạn cần làm không phải là làm hài lòng tất cả, mà là vẽ rõ ai thực sự có quyền quyết định, thuyết phục sâu đúng người đó, và biến những chỉ đạo trái chiều thành một cuộc tranh luận có trọng tài — thay vì để nó đổ hết áp lực lên vai bạn.

🔗 Kỹ năng liên quan

• Sử dụng dữ liệu để đàm phán — kỹ thuật trình bày phương án bằng dữ liệu mà chị H. dùng khi trình Giám đốc vận hành.
• Cách xử lý Scope Creep (Phình to phạm vi) — khi yêu cầu trái chiều giữa các stakeholder kéo theo phạm vi bị phình to.
• Cách nói "Không" một cách chuyên nghiệp — kỹ năng cần khi phải từ chối yêu cầu của một stakeholder quyền lực thấp hơn để giữ đúng quyết định đã chốt.

Bài trước: Sử dụng dữ liệu để đàm phán · Bài tiếp theo: Tư duy TCO (Total Cost of Ownership)