Bài 11 — Stakeholder analysis và RACI

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

Bạn đã có một project charter rõ ràng, một business case thuyết phục và một SIPOC đẹp đẽ. Nhưng tôi muốn nói thẳng với bạn một sự thật mà ít sách Lean Six Sigma nào dám nhấn mạnh đủ mạnh: phần lớn các dự án LSS thất bại không phải vì thiếu công cụ thống kê, mà vì thiếu sự ủng hộ của con người. Bạn có thể tính Cpk đến năm chữ số thập phân, nhưng nếu trưởng phòng sản xuất không tin vào dự án, hoặc nếu giám đốc tài chính không biết mình đang được kỳ vọng phê duyệt ngân sách, thì giải pháp của bạn sẽ chết yểu ngay tại bàn họp.

Đây chính là lý do giai đoạn Define không chỉ dừng ở việc định nghĩa vấn đề, mà còn phải định nghĩa ai là người liên quan, họ nghĩ gì, họ có quyền lực đến đâu, và ai chịu trách nhiệm về cái gì. Hai công cụ trung tâm của bài học hôm nay — Stakeholder Analysis (phân tích các bên liên quan) và RACI matrix (ma trận phân vai trò trách nhiệm) — chính là tấm bản đồ chính trị và bản đồ trách nhiệm giúp bạn lái con tàu dự án qua những vùng nước ngầm nguy hiểm nhất.

Nói cách khác: Stakeholder Analysis giúp bạn trả lời câu hỏi "Tôi cần thuyết phục ai và bằng cách nào?", còn RACI giúp bạn trả lời "Khi việc này cần làm, ai là người bấm nút?". Bỏ qua hai công cụ này, bạn đang đặt một dự án kỹ thuật vào tay may rủi chính trị. Một Green Belt giỏi không chỉ là người giỏi số liệu — mà là người biết đọc con người.

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

Stakeholder là ai?

Stakeholder (bên liên quan) là bất kỳ cá nhân hoặc nhóm nào có thể ảnh hưởng đến dự án hoặc bị dự án ảnh hưởng. Lưu ý cả hai chiều: có người tác động vào dự án (giám đốc cấp ngân sách), có người bị dự án tác động (công nhân phải thay đổi quy trình làm việc). Cả hai đều là stakeholder, và bạn bỏ sót nhóm nào cũng nguy hiểm.

Trong một dự án LSS điển hình tại doanh nghiệp Việt Nam, danh sách stakeholder thường gồm: Champion/Sponsor (lãnh đạo bảo trợ dự án), Process Owner (người sở hữu quy trình bị thay đổi), đội dự án (Green Belt, Black Belt, thành viên), nhân viên tuyến đầu (người thực thi quy trình hằng ngày), khách hàng (nội bộ hoặc bên ngoài), các phòng ban liên quan (IT, Tài chính, Nhân sự, Mua hàng), và đôi khi cả công đoàn hay cơ quan quản lý.

Stakeholder Analysis — ma trận Power/Interest 2×2

Công cụ kinh điển nhất là ma trận Power/Interest (Quyền lực / Mức độ quan tâm), còn gọi là ma trận Mendelow. Ta phân loại từng stakeholder theo hai trục:

• Power (Quyền lực): Người này có khả năng tác động đến số phận dự án đến mức nào? Họ có thể dừng dự án, cắt ngân sách, hay điều người không?
• Interest (Mức độ quan tâm): Người này quan tâm đến kết quả dự án đến mức nào? Dự án thành hay bại có ảnh hưởng trực tiếp tới họ không?

Từ đó ta có bốn ô và bốn chiến lược ứng xử tương ứng:

Hãy hiểu rõ từng ô vì đây là trái tim của công cụ:

• Manage Closely (Quyền lực cao + Quan tâm cao): Đây là những người quan trọng nhất — Champion, Process Owner. Bạn phải gặp họ thường xuyên, báo cáo tiến độ, lắng nghe phản hồi, đưa họ vào quyết định lớn. Họ là đồng minh hoặc kẻ phá hoại tùy cách bạn đối xử.
• Keep Satisfied (Quyền lực cao + Ít quan tâm): Ví dụ giám đốc tài chính bận trăm việc, nhưng một chữ ký của họ có thể chặn dự án. Đừng làm họ khó chịu, đừng bắt họ đọc 30 trang báo cáo, nhưng phải đảm bảo họ luôn "ổn" với dự án. Báo cáo ngắn gọn, đúng trọng tâm tài chính.
• Keep Informed (Quyền lực thấp + Quan tâm cao): Thường là nhân viên tuyến đầu — chính những người sẽ vận hành quy trình mới. Họ không cắt được ngân sách của bạn, nhưng họ có thể âm thầm "phá" giải pháp bằng cách không tuân thủ. Hãy cập nhật thường xuyên, lắng nghe, biến họ thành người đồng hành.
• Monitor (Quyền lực thấp + Ít quan tâm): Theo dõi tối thiểu, đừng tốn quá nhiều năng lượng, nhưng đừng quên — vì vị trí của stakeholder có thể dịch chuyển khi dự án tiến triển.

Một điểm tinh tế mà mentor nào cũng phải nhắc: vị trí trên ma trận không cố định. Một công nhân hôm nay "ít quan tâm" có thể nhảy lên "quan tâm cao" khi nghe tin quy trình sẽ thay đổi. Stakeholder Analysis là tài liệu sống, cần rà lại ở mỗi phase của DMAIC.

RACI matrix — phân vai trò trách nhiệm

Nếu ma trận Power/Interest là bản đồ chính trị, thì RACI là bản đồ trách nhiệm. RACI là viết tắt của bốn vai trò gán cho từng đầu việc/quyết định trong dự án:

• R — Responsible (Người thực hiện): Người trực tiếp làm việc đó. Có thể có nhiều R cho một việc.
• A — Accountable (Người chịu trách nhiệm cuối cùng): Người "chịu đầu" nếu việc đó hỏng, người có quyền phê duyệt. Quy tắc vàng: mỗi việc chỉ được có ĐÚNG MỘT chữ A. Hai chữ A nghĩa là không ai chịu trách nhiệm thật sự.
• C — Consulted (Người được tham vấn): Người được hỏi ý kiến trước khi quyết định — giao tiếp hai chiều. Ví dụ chuyên gia kỹ thuật, pháp chế.
• I — Informed (Người được thông báo): Người chỉ cần được báo kết quả — giao tiếp một chiều.

Bảng RACI thường có đầu việc/quyết định ở các hàng và stakeholder ở các cột, mỗi ô điền R/A/C/I (hoặc để trống nếu người đó không liên quan đến việc này).

Sự kết hợp đẹp đẽ là: Stakeholder Analysis cho bạn biết cách giao tiếp với từng người, còn RACI cho bạn biết vai trò chính thức của họ trong từng hoạt động. Hai công cụ bổ trợ nhau hoàn hảo trong giai đoạn Define.

Tình huống thực tế

Tình huống 1 — Nhà máy điện tử FDI tại Bắc Ninh giảm tỷ lệ lỗi hàn

Một nhà máy lắp ráp linh kiện điện tử vốn FDI tại KCN Quế Võ, Bắc Ninh, khởi động dự án Green Belt nhằm giảm tỷ lệ lỗi mối hàn (solder defect) từ 4.200 DPMO xuống dưới 2.000 DPMO. Green Belt là một kỹ sư trẻ tên Tuấn, rất giỏi kỹ thuật.

Tuấn lập ngay danh sách stakeholder và xếp lên ma trận Power/Interest:

• Manage Closely: Giám đốc sản xuất (Champion) và Quản đốc xưởng SMT (Process Owner) — quyền lực cao, quan tâm cao vì KPI lỗi hàn ảnh hưởng trực tiếp tới họ.
• Keep Satisfied: Giám đốc tài chính — quyền lực cao (duyệt mua máy AOI mới) nhưng ít quan tâm chi tiết kỹ thuật.
• Keep Informed: 40 công nhân vận hành máy hàn — quyền lực thấp nhưng cực kỳ quan trọng, vì chính họ phải tuân thủ thông số nhiệt mới.
• Monitor: Phòng Nhân sự.

Diễn giải: Ban đầu Tuấn định bỏ qua nhóm công nhân vì "họ chỉ làm theo lệnh". May là người mentor Black Belt chỉ ra: chính nhóm Keep Informed này sẽ quyết định việc giải pháp có "sống" được không. Tuấn tổ chức họp ngắn 15 phút mỗi đầu ca để giải thích vì sao đổi thông số, lắng nghe phản hồi. Kết quả: công nhân phát hiện một nguyên nhân Tuấn không ngờ — bàn gá bị xê dịch ca đêm. Dự án về đích ở 1.850 DPMO.

Bài học: Nhóm quyền lực thấp nhưng quan tâm cao (Keep Informed) thường nắm tri thức vận hành thực tế. Bỏ qua họ là tự bịt mắt mình.

Tình huống 2 — Ngân hàng VPBank rút ngắn thời gian phê duyệt khoản vay

Một chi nhánh ngân hàng tại TP.HCM (gọi giả định là VPBank chi nhánh Q.1) chạy dự án LSS giảm thời gian phê duyệt vay tín chấp từ trung bình 5,2 ngày xuống 3 ngày. Đây là dự án dịch vụ, đụng tới nhiều phòng ban: Quan hệ khách hàng (RM), Thẩm định tín dụng, Pháp chế, và Vận hành.

Vấn đề nảy sinh ngay tuần đầu: hai phòng đổ lỗi cho nhau về việc "ai phải kiểm tra hồ sơ pháp lý". Green Belt quyết định lập RACI matrix cho quy trình phê duyệt:

Diễn giải: Khi RACI được dán lên tường phòng họp, mọi tranh cãi tan biến. Hóa ra trước đó cả Thẩm định lẫn Pháp chế đều nghĩ mình là người "kiểm tra pháp lý cuối cùng" (hai chữ A ngầm) nên cùng chần chừ chờ bên kia. RACI làm rõ Pháp chế là A duy nhất cho bước này. Riêng bước "Quyết định phê duyệt" cũng chỉ có một A là Trưởng phòng Tín dụng. Thời gian phê duyệt giảm xuống 2,9 ngày sau ba tháng.

Bài học: Phần lớn chậm trễ trong quy trình dịch vụ đến từ mơ hồ về trách nhiệm, không phải thiếu nỗ lực. RACI là liều thuốc trực tiếp cho căn bệnh "hai chữ A" và "không có A nào".

Tình huống 3 — Bệnh viện tư cải thiện luồng tiếp nhận bệnh nhân ngoại trú

Một bệnh viện tư tại Hà Nội triển khai dự án giảm thời gian chờ khám ngoại trú. Green Belt là điều dưỡng trưởng. Cô lập Stakeholder Analysis và nhận ra một stakeholder dễ bị bỏ quên: các bác sĩ chuyên khoa — quyền lực rất cao (họ có thể từ chối thay đổi lịch khám), nhưng ban đầu ít quan tâm vì nghĩ "đây là việc của điều dưỡng".

Diễn giải: Bác sĩ rơi vào ô Keep Satisfied. Nếu xử lý sai — bắt họ dự họp dài, làm phiền — họ sẽ phản kháng và dìm dự án. Green Belt chọn cách báo cáo cực ngắn: mỗi tuần một email một đoạn, kèm một biểu đồ thời gian chờ. Khi thấy con số cải thiện, một số bác sĩ tự nguyện chuyển sang ô Manage Closely vì bắt đầu thấy lợi ích cho chính phòng khám của mình.

Bài học: Đối với nhóm Keep Satisfied, "ít hơn là nhiều hơn". Tôn trọng quỹ thời gian của họ, và để chính kết quả lôi kéo họ quan tâm hơn — đừng ép.

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

Bước 1 — Liệt kê toàn bộ stakeholder (brainstorm rộng). Cùng đội dự án động não: ai ảnh hưởng, ai bị ảnh hưởng? Đừng lọc vội. Dùng câu hỏi gợi mở: "Ai duyệt ngân sách? Ai vận hành quy trình? Ai nhận đầu ra? Ai sẽ khó chịu khi ta thay đổi?". Liệt kê cả phòng ban hỗ trợ (IT, HR, Mua hàng).

Bước 2 — Đánh giá Power và Interest cho từng người. Cho điểm đơn giản Cao/Thấp trên hai trục. Tránh tranh cãi tiểu tiết — quan trọng là xếp đúng ô, không phải đúng tuyệt đối.

Bước 3 — Đặt từng stakeholder vào ma trận 2×2 và gán chiến lược: Manage Closely / Keep Satisfied / Keep Informed / Monitor.

Bước 4 — Lập kế hoạch giao tiếp (communication plan) cho từng nhóm: tần suất, kênh (họp, email, dashboard), người phụ trách, thông điệp chính. Đây là sản phẩm đầu ra thực sự của Stakeholder Analysis — không chỉ là cái bảng đẹp.

Bước 5 — Liệt kê các hoạt động/quyết định chính của dự án (các hàng cho RACI). Ví dụ: thu thập dữ liệu, phê duyệt giải pháp, triển khai pilot, cập nhật quy trình.

Bước 6 — Điền RACI cho từng ô. Đi từng hàng, hỏi: Ai làm (R)? Ai chịu trách nhiệm cuối và phê duyệt (A)? Ai cần tham vấn (C)? Ai cần thông báo (I)?

Bước 7 — Kiểm tra quy tắc: mỗi hàng đúng một chữ A; không hàng nào toàn C và I (phải có người làm); không cột nào toàn A (một người ôm hết là nghẽn cổ chai).

Bước 8 — Xác nhận với chính các stakeholder. Đừng tự gán vai rồi giấu đi. Gửi RACI cho họ duyệt — sự đồng thuận lúc này tránh được tranh cãi về sau. Rồi rà lại cả hai công cụ ở mỗi phase DMAIC.

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

• Coi Stakeholder Analysis là việc làm một lần rồi quên. Sai. Vị trí stakeholder dịch chuyển liên tục. Rà lại ở mỗi cổng phase.
• Bỏ sót nhóm quyền lực thấp. Công nhân, nhân viên tuyến đầu thường bị xem nhẹ, nhưng họ là người "sống chung" với giải pháp. Bỏ qua họ = giải pháp không bền vững (sẽ ảnh hưởng tới giai đoạn Control sau này).
• Gán hai chữ A trong RACI. Đây là lỗi phổ biến nhất. Hai A nghĩa là trách nhiệm bị chia đôi và không ai thực sự chịu. Luôn ép về đúng một A.
• Một hàng toàn C và I, không có R. Mọi người được hỏi, được báo, nhưng không ai làm. Việc sẽ trôi nổi mãi.
• Một cột dày đặc chữ A. Một người (thường là Process Owner) ôm hết phê duyệt — họ trở thành nút thắt cổ chai. Phân quyền hợp lý.
• Nhầm Consulted với Informed. C là hai chiều (hỏi ý kiến TRƯỚC), I là một chiều (báo SAU). Nhầm lẫn khiến chuyên gia bị bỏ qua hoặc bị làm phiền vô ích.
• Mẹo của mentor: Với nhóm Keep Satisfied, gửi báo cáo "một màn hình" — họ chỉ cần thấy xu hướng và rủi ro tài chính. Với nhóm Manage Closely, gặp mặt định kỳ và để họ tham gia quyết định để tạo cảm giác sở hữu. Và luôn nhớ: dự án LSS là 80% con người, 20% công cụ.

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

Hãy chọn một quy trình bạn đang biết rõ (ở công ty bạn, hoặc một quy trình giả định như "xử lý khiếu nại khách hàng" của một chuỗi cà phê).

• Liệt kê tối thiểu 6 stakeholder cho một dự án LSS cải thiện quy trình đó. Ghi rõ vì sao mỗi người là stakeholder (ảnh hưởng hay bị ảnh hưởng).
• Vẽ ma trận Power/Interest 2×2 và đặt 6 stakeholder vào đúng ô. Với mỗi người, viết một câu mô tả chiến lược giao tiếp (tần suất + kênh).
• Lập RACI matrix cho ít nhất 5 hoạt động chính của dự án. Kiểm tra: mỗi hàng có đúng một A? Có hàng nào thiếu R? Có cột nào quá nhiều A?
• Tự phản biện: Stakeholder nào dễ bị bạn bỏ sót nhất? Nếu người đó "phá" dự án vào phút chót, hậu quả là gì, và bạn sẽ phòng ngừa thế nào?

Hãy viết ra giấy hoặc bảng tính — chính việc bị buộc phải gán đúng một chữ A cho mỗi hàng sẽ dạy bạn nhiều hơn cả lý thuyết.

Tóm tắt

Trong bài này, chúng ta đã đi qua hai công cụ "mềm" nhưng quyết định sống còn của giai đoạn Define:

• Stakeholder Analysis với ma trận Power/Interest 2×2 giúp bạn phân loại các bên liên quan thành bốn nhóm — Manage Closely, Keep Satisfied, Keep Informed, Monitor — và chọn chiến lược giao tiếp phù hợp cho từng nhóm. Nhớ rằng vị trí stakeholder luôn dịch chuyển, và nhóm quyền lực thấp thường nắm tri thức vận hành quý giá.
• RACI matrix (Responsible, Accountable, Consulted, Informed) gán vai trò rõ ràng cho từng hoạt động. Quy tắc vàng: mỗi hoạt động đúng một chữ A; tránh hàng không có R và cột quá nhiều A.

Cả ba tình huống — nhà máy điện tử Bắc Ninh, ngân hàng tại TP.HCM, bệnh viện tư Hà Nội — đều cho thấy cùng một chân lý: dự án LSS thành hay bại phần lớn nằm ở việc bạn quản lý con người tốt đến đâu, chứ không chỉ ở chất lượng phân tích thống kê. Hãy biến hai công cụ này thành thói quen ngay từ ngày đầu của mỗi dự án, và bạn đã loại bỏ được nguyên nhân thất bại phổ biến nhất của Green Belt.