Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được giao làm BA cho một dự án nâng cấp hệ thống core banking của một ngân hàng. Bạn lao vào phỏng vấn người dùng, viết requirement, vẽ process. Mọi thứ trôi chảy cho đến tuần thứ tám, khi giải pháp gần xong, một ông Giám đốc Khối Tuân thủ (Compliance) mà bạn chưa từng gặp bước vào phòng họp và nói một câu lạnh người: "Cái này vi phạm quy định của Ngân hàng Nhà nước về lưu trữ dữ liệu giao dịch. Làm lại."
Tám tuần công sức bốc hơi. Vấn đề không nằm ở kỹ thuật phân tích của bạn — nó nằm ở chỗ bạn đã bỏ sót một stakeholder quan trọng. Đây là lỗi kinh điển và đắt giá nhất trong nghề BA: bạn không thể lấy requirement đúng nếu bạn không biết phải hỏi ai.
Theo nghiên cứu của PMI, các dự án có quy trình quản lý stakeholder bài bản hoàn thành đúng mục tiêu cao hơn đáng kể so với dự án bỏ qua bước này. Và bước đầu tiên — gốc rễ của toàn bộ Stakeholder Management — chính là nhận diện (identification): liệt kê cho đủ, cho đúng ai là người có liên quan trước khi bạn làm bất cứ điều gì khác. Bài này tập trung vào hai công cụ kinh điển và bổ trợ cho nhau: Onion Model của Ian Alexander (để không bỏ sót ai) và RACI Matrix (để làm rõ ai chịu trách nhiệm gì). Đây là nền móng; các bài tiếp theo (Power/Interest Grid, Salience, giao tiếp, đàm phán) sẽ xây trên nền này.
Khái niệm cốt lõi
Trước khi đi vào hai mô hình, cần phân biệt rạch ròi: stakeholder không chỉ là người dùng cuối. Theo BABOK v3, stakeholder là bất kỳ cá nhân hay nhóm nào có quan hệ với sự thay đổi, nhu cầu, hoặc giải pháp — họ có thể bị ảnh hưởng bởi giải pháp, ảnh hưởng đến giải pháp, hoặc đơn giản là có quyền lợi/quan điểm về nó. Một người gác cổng tuân thủ chưa từng dùng phần mềm vẫn có thể là stakeholder quyền lực nhất dự án.
Onion Model — củ hành của Ian Alexander
Onion Model hình dung stakeholder như các lớp của một củ hành, xếp từ trong ra ngoài theo mức độ gần gũi với giải pháp. Càng vào trong, càng tiếp xúc trực tiếp với sản phẩm; càng ra ngoài, ảnh hưởng càng gián tiếp nhưng không kém phần quan trọng. Bốn lớp chính:
- Lớp lõi (The Product / Our System): Đây là chính giải pháp — phần mềm, hệ thống. Không phải người, nhưng là tâm điểm để định vị các lớp xung quanh.
- Lớp 1 — Hệ thống đang vận hành (Containing System): Những người trực tiếp tương tác với giải pháp. Gồm hai nhóm con quan trọng: Normal Operators (người dùng vận hành hằng ngày, ví dụ giao dịch viên) và Operational Support (người hỗ trợ kỹ thuật, bảo trì, vận hành — admin, helpdesk, DevOps).
- Lớp 2 — Hệ thống rộng hơn (Wider System / The Containing Business): Những người hưởng lợi hoặc bị tác động nhưng không trực tiếp gõ phím vào hệ thống. Gồm Functional Beneficiaries (người hưởng kết quả đầu ra — ví dụ khách hàng nhận sao kê), Decision Makers (lãnh đạo phê duyệt), Sponsor (người tài trợ ngân sách), và Champion (người vận động ủng hộ dự án trong nội bộ).
- Lớp 3 — Môi trường rộng (The Wider Environment): Những bên bên ngoài tổ chức nhưng có quyền lực định hình giải pháp: cơ quan quản lý (NHNN, Bộ TT&TT), đối thủ cạnh tranh, đối tác, nhà cung cấp, và cả các nhóm "negative stakeholder" như hacker hoặc nhóm phản đối.
RACI Matrix — ai làm gì cho từng hoạt động
Onine Model trả lời câu "Có những ai?". RACI trả lời câu tiếp theo, sắc bén hơn: "Với mỗi việc cụ thể, ai đóng vai trò gì?". RACI là ma trận với các hoạt động/sản phẩm nằm ở hàng và các stakeholder nằm ở cột, mỗi ô điền một trong bốn chữ:
- R — Responsible (Người thực hiện): Người trực tiếp làm ra công việc. Phải có ít nhất một R cho mỗi việc.
- A — Accountable (Người chịu trách nhiệm cuối cùng): Người ra quyết định, ký duyệt, chịu trách nhiệm sau cùng. Quy tắc vàng: mỗi việc chỉ được có ĐÚNG MỘT chữ A. Hai A nghĩa là không ai thực sự chịu trách nhiệm.
- 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ụ: phải hỏi Legal trước khi chốt điều khoản hợp đồng.
- I — Informed (Người được thông báo): Người chỉ cần biết kết quả — giao tiếp một chiều, sau khi việc đã xong.
Hai mô hình bổ trợ nhau: dùng Onion để liệt kê đầy đủ stakeholder, rồi đưa danh sách đó vào RACI để phân vai trên từng hoạt động. Onion là chiều rộng, RACI là chiều sâu.
Tình huống thực tế
Ví dụ 1 — Ngân hàng VN triển khai eKYC (Onion Model cứu dự án)
Một ngân hàng cổ phần tầm trung tại TP.HCM (giả định là "VietBank Digital") khởi động dự án mở tài khoản online bằng eKYC. BA ban đầu chỉ vẽ lớp lõi và lớp 1: khách hàng, giao dịch viên hỗ trợ, đội IT. Khi áp Onion Model một cách kỷ luật, đội phát hiện ra hàng loạt stakeholder ở lớp ngoài bị bỏ sót:
- Lớp 3 (môi trường rộng): Ngân hàng Nhà nước với Thông tư về eKYC quy định ngưỡng giao dịch và yêu cầu xác thực; nhà cung cấp dịch vụ định danh điện tử bên thứ ba; Bộ Công an với cơ sở dữ liệu căn cước công dân để đối soát.
- Lớp 2: Khối Quản trị rủi ro (lo ngại gian lận tài khoản ma), Khối Pháp chế, và Marketing (muốn rút ngắn luồng đăng ký xuống dưới 5 phút để tăng tỷ lệ chuyển đổi).
Ví dụ 2 — RACI gỡ rối "ai duyệt BRD" tại một công ty Fintech
Một startup BNPL (mua trước trả sau) tại Hà Nội liên tục trễ deadline phê duyệt tài liệu. BA than rằng cứ gửi BRD đi là "rơi vào hư không": người thì bảo đợi sếp duyệt, sếp lại bảo "tôi tưởng team kỹ thuật chốt rồi". Nguyên nhân: không ai biết rõ vai trò của mình. Đội lập một RACI nhỏ cho deliverable "Phê duyệt BRD module chấm điểm tín dụng":
| Hoạt động | BA | Product Owner | Head of Risk | Tech Lead | CEO |
|---|---|---|---|---|---|
| Soạn BRD | R | C | C | C | I |
| Duyệt nội dung nghiệp vụ | C | A | C | I | I |
| Duyệt mô hình rủi ro | I | C | A | C | I |
| Chốt ngân sách | I | C | I | I | A |
Ví dụ 3 — Sai lầm "hai chữ A" tại dự án ERP của một chuỗi bán lẻ
Một chuỗi bán lẻ điện máy (giả định "MegaStore") triển khai ERP. RACI ban đầu ghi cả Giám đốc Vận hành và Giám đốc Tài chính đều là A cho hoạt động "Phê duyệt quy trình duyệt đơn mua hàng". Kết quả: mỗi khi cần quyết định, hai vị đùn đẩy nhau, mỗi người tưởng người kia chịu trách nhiệm cuối. Tiến độ kẹt ba tuần. BA phải họp lại để xác định: quy trình mua hàng thuộc thẩm quyền Vận hành — Giám đốc Vận hành là A duy nhất, Giám đốc Tài chính chuyển thành C (được tham vấn về hạn mức ngân sách). Bài học: quy tắc "một A duy nhất" không phải lý thuyết suông — vi phạm nó là tạo ra điểm nghẽn quyết định. Khi thấy hai A, hãy coi đó là báo động đỏ cần làm rõ ngay.
Hướng dẫn từng bước
Đây là quy trình nhận diện stakeholder bạn có thể áp dụng ngay cho dự án thật:
- Khởi động bằng Onion Model. Vẽ lớp lõi (giải pháp) ở giữa. Lần lượt brainstorm từng lớp ra ngoài: Lớp 1 (ai trực tiếp dùng/hỗ trợ?), Lớp 2 (ai hưởng lợi, ai phê duyệt, ai tài trợ?), Lớp 3 (regulator, đối tác, nhà cung cấp, đối thủ, nhóm phản đối?). Đừng đánh giá đúng/sai lúc này — cứ liệt kê hết.
- Dùng câu hỏi kích hoạt để không sót: Ai trả tiền? Ai dùng? Ai phê duyệt? Ai bị mất việc/thay đổi cách làm? Ai có thể nói "không"? Ai ở bên ngoài có quyền lực pháp lý? Mỗi câu hỏi thường lôi ra một stakeholder mới.
- Lập Stakeholder Register (sổ đăng ký): bảng liệt kê tên, vai trò/chức danh, lớp Onion, phòng ban, thông tin liên hệ, và ghi chú sơ bộ về quan tâm của họ. Đây là tài sản sống, cập nhật liên tục.
- Chuyển sang RACI cho các hoạt động/deliverable chính. Liệt kê các hoạt động quan trọng (lấy requirement, duyệt BRD, UAT, go-live…) ở hàng; stakeholder ở cột.
- Điền R, A, C, I theo thứ tự: trước hết tìm A duy nhất cho mỗi hàng, rồi đến R, rồi C, rồi I. Để trống ô nếu stakeholder không liên quan đến việc đó — không cần ép mọi người vào mọi việc.
- Soát ma trận theo hàng và cột. Theo hàng: mỗi việc có đúng một A và ít nhất một R chưa? Theo cột: có ai gánh quá nhiều A không (quá tải quyết định)? Có ai toàn chữ I (có thể không phải stakeholder thật sự)?
- Xác nhận lại với chính stakeholder. Gửi RACI cho họ review — chính họ phải đồng ý mình là A hay C. Phân vai mà không có sự đồng thuận thì chỉ là giấy tờ.
- Đặt lịch rà soát định kỳ. Stakeholder thay đổi: người nghỉ việc, tổ chức tái cơ cấu, dự án sang pha mới. Cập nhật Register và RACI ở mỗi cột mốc lớn.
Lỗi thường gặp & mẹo
- Bỏ sót stakeholder lớp ngoài. Lỗi đắt nhất. Mẹo: luôn tự hỏi "ai có thể nói KHÔNG với dự án này?" — regulator, legal, compliance, security thường nằm ở đây.
- Nhầm "người to nhất" với stakeholder duy nhất quan trọng. CEO không phải lúc nào cũng là người bạn cần hỏi requirement. Một giao dịch viên cấp thấp có thể nắm chi tiết nghiệp vụ mà sếp không biết.
- Hai chữ A trên một hàng RACI. Báo động đỏ về trách nhiệm. Luôn ép về đúng một A.
- Cả hàng toàn C và I, không có A hoặc R. Nghĩa là việc đó "vô chủ" — sẽ không bao giờ xong. Phải có người làm và người chịu trách nhiệm.
- Lạm dụng chữ C. Tham vấn quá nhiều người làm chậm mọi quyết định. Phân biệt rõ: người thật sự cần hỏi ý kiến (C) với người chỉ cần biết kết quả (I).
- Coi Stakeholder Register là tài liệu một lần. Mẹo: gắn việc review stakeholder vào ceremony có sẵn (đầu mỗi sprint, mỗi milestone) để không quên.
- Mẹo phân biệt C và I: hỏi "nếu người này phản đối, ta có dừng lại không?". Có → họ là C. Không, ta chỉ cần báo cho họ biết → họ là I.
Bài tập thực hành
Bài 1 — Vẽ củ hành: Chọn một dự án bạn biết (hoặc dùng tình huống "app đặt đồ ăn của một chuỗi cà phê VN muốn tự xây nền tảng giao hàng riêng"). Vẽ Onion Model đầy đủ bốn lớp, liệt kê tối thiểu 3 stakeholder cho mỗi lớp. Cố tình tìm ít nhất 2 stakeholder ở Lớp 3 (môi trường rộng) mà người mới thường quên.
Bài 2 — Lập RACI: Với cùng dự án trên, lập ma trận RACI cho 4 hoạt động: (1) Thu thập yêu cầu nghiệp vụ, (2) Phê duyệt thiết kế luồng đặt món, (3) Kiểm thử chấp nhận (UAT), (4) Quyết định go-live. Đảm bảo mỗi hoạt động có đúng một A.
Bài 3 — Soát lỗi: Đưa RACI của bạn qua bài kiểm tra: hàng nào có hai A? Hàng nào thiếu R? Cột nào của một người gánh quá ba chữ A? Tự sửa và ghi lại lý do mỗi lần sửa.
Bài 4 — Câu hỏi phản tư: Viết ra 3 câu hỏi bạn sẽ dùng để "moi" thêm stakeholder ẩn trong buổi họp khởi động dự án, dựa trên các câu hỏi kích hoạt ở phần Hướng dẫn.
Tóm tắt
Nhận diện stakeholder là bước nền móng của toàn bộ Stakeholder Management — sai ở đây thì mọi requirement phía sau đều chông chênh. Onion Model giúp bạn không bỏ sót ai bằng cách đi từ lõi (giải pháp) ra ngoài qua bốn lớp: người trực tiếp dùng/hỗ trợ, người hưởng lợi và phê duyệt, đến môi trường rộng gồm regulator và đối tác. RACI Matrix đi sâu hơn, làm rõ với mỗi hoạt động thì ai Thực hiện (R), ai Chịu trách nhiệm cuối (A — chỉ một), ai được Tham vấn (C), ai được Thông báo (I). Hai công cụ bổ trợ: Onion cho chiều rộng, RACI cho chiều sâu. Hãy nhớ ba quy tắc sống còn: đi đủ bốn lớp củ hành (đặc biệt lớp ngoài), mỗi việc đúng một chữ A, và coi danh sách stakeholder là tài liệu sống cần cập nhật liên tục. Ở các bài tiếp theo, ta sẽ học cách phân tích mức độ quyền lực và quan tâm của những stakeholder vừa nhận diện được — qua Power/Interest Grid và Salience Model.