Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa vẽ xong một quy trình phê duyệt hợp đồng tuyệt đẹp bằng BPMN: các task rõ ràng, gateway phân nhánh hợp lý, sequence flow mạch lạc. Bạn tự tin trình bày với ban lãnh đạo. Nhưng rồi một câu hỏi đơn giản khiến cả phòng họp im lặng: "Vậy ai chịu trách nhiệm cuối cùng nếu hợp đồng này sai?" Mọi người nhìn nhau. Phòng Kinh doanh nói "chắc là Pháp chế", Pháp chế nói "tụi tôi chỉ tư vấn thôi", còn Giám đốc thì tưởng người ký là người chịu trách nhiệm.
Đây chính là khoảng trống mà sơ đồ quy trình thuần túy không lấp được. BPMN cho bạn biết việc gì xảy ra và theo thứ tự nào, nhưng nó không trả lời rõ ràng câu hỏi quan trọng nhất trong vận hành: ai làm gì, và ai chịu trách nhiệm khi mọi thứ đi chệch hướng?
RACI matrix (ma trận RACI) chính là công cụ lấp đầy khoảng trống đó. Nó là một bảng đơn giản nhưng có sức mạnh chính trị to lớn: nó công khai, minh bạch hóa trách nhiệm của từng vai trò trong từng bước của quy trình. Khi một quy trình có RACI rõ ràng, không còn chỗ cho câu "tôi tưởng người khác làm rồi" — nguyên nhân số một của những quả bóng trách nhiệm bị thả rơi giữa các phòng ban.
Trong khóa học này, bạn đã học cách dùng Pools và Lanes (Bài 12) để biểu diễn participant trên sơ đồ. RACI là lớp bổ sung: trong khi Lanes nói "ai thực hiện activity nào", RACI đi sâu hơn để phân biệt giữa người làm, người chịu trách nhiệm, người được hỏi và người chỉ cần biết. Đây là kỹ năng nền tảng của một Process Analyst chuyên nghiệp.
Khái niệm cốt lõi
RACI là từ viết tắt của bốn loại vai trò gắn với mỗi hoạt động (activity) hoặc kết quả (deliverable) trong quy trình. Mỗi chữ cái đại diện cho một mức độ tham gia khác nhau.
R — Responsible (Người thực hiện)
Đây là người (hoặc nhóm người) trực tiếp làm công việc để hoàn thành hoạt động. Họ "xắn tay áo" thực thi. Một hoạt động có thể có nhiều người Responsible — ví dụ khi cả nhân viên thu mua và nhân viên kho cùng tham gia kiểm hàng nhập.
Câu hỏi để xác định R: "Ai là người thực sự đặt tay vào làm việc này?"
A — Accountable (Người chịu trách nhiệm cuối cùng)
Đây là vai trò quan trọng và dễ bị làm sai nhất. Accountable là người chịu trách nhiệm cuối cùng về kết quả — người mà cấp trên sẽ "gọi tên" khi việc thành công hoặc thất bại. Họ là người có thẩm quyền phê duyệt và ký xác nhận rằng công việc đã hoàn thành đúng chuẩn.
Quy tắc vàng, không có ngoại lệ: mỗi hoạt động CHỈ ĐƯỢC có duy nhất MỘT người Accountable. Nếu hai người cùng Accountable, thực chất là không ai Accountable — vì khi sự cố xảy ra, cả hai sẽ chỉ tay sang nhau. Đây là sai lầm kinh điển mà chúng ta sẽ phân tích kỹ ở phần sau.
Câu hỏi để xác định A: "Nếu việc này hỏng, sếp sẽ triệu tập ai đầu tiên?"
C — Consulted (Người được tham vấn)
Đây là những người được hỏi ý kiến trước khi ra quyết định hoặc trước khi hoàn thành công việc. Họ có chuyên môn, dữ liệu hoặc quyền lợi liên quan, nên cần được tham vấn. Điểm mấu chốt: Consulted là giao tiếp hai chiều — bạn hỏi, họ trả lời, và ý kiến của họ thực sự được cân nhắc.
Ví dụ: trước khi phê duyệt một khoản chi lớn, Phòng Pháp chế được Consulted để rà soát rủi ro pháp lý.
Câu hỏi để xác định C: "Trước khi làm/quyết, ta bắt buộc phải lấy ý kiến của ai?"
I — Informed (Người được thông báo)
Đây là những người được thông báo về kết quả sau khi công việc hoàn thành, nhưng không tham gia ra quyết định. Giao tiếp ở đây là một chiều — bạn báo cho họ biết, họ không cần phản hồi. Họ cần nắm thông tin vì công việc của họ phụ thuộc vào kết quả này, hoặc vì lý do báo cáo, giám sát.
Ví dụ: sau khi đơn hàng được duyệt, Phòng Kế toán được Informed để chuẩn bị ghi nhận công nợ.
Câu hỏi để xác định I: "Ai cần biết kết quả này đã xong, dù họ không tham gia làm?"
Cấu trúc của một ma trận RACI
Một RACI matrix điển hình là bảng hai chiều:
- Hàng (rows): liệt kê các hoạt động/bước trong quy trình — thường lấy trực tiếp từ các Task trong sơ đồ BPMN của bạn.
- Cột (columns): liệt kê các vai trò (roles) hoặc phòng ban tham gia. Lưu ý: dùng vai trò chức danh, không dùng tên người cụ thể — vì người có thể nghỉ việc, nhưng vai trò thì còn mãi.
- Ô giao nhau (cells): điền R, A, C, I hoặc để trống nếu vai trò đó không liên quan đến hoạt động.
| Hoạt động | NV đề xuất | Trưởng phòng | Phòng Mua sắm | Giám đốc TC | Kế toán |
|---|---|---|---|---|---|
| Tạo yêu cầu mua | R | A | I | ||
| Thẩm định nhà cung cấp | C | I | R/A | I | |
| Phê duyệt ngân sách | I | C | C | A/R | I |
| Ghi nhận công nợ | I | I | R/A |
Tình huống thực tế
Tình huống 1 — Quả bóng trách nhiệm bị thả rơi tại một công ty thương mại điện tử
Một sàn TMĐT tại TP.HCM (tạm gọi ShopViet, quy mô khoảng 400 nhân viên) gặp một sự cố nghiêm trọng: trong dịp sale 11/11, hệ thống cho phép bán một mẫu điện thoại với giá sai — niêm yết 2,9 triệu thay vì 29 triệu. Trong vòng 40 phút, hơn 1.200 đơn hàng được đặt, thiệt hại tiềm năng gần 32 tỷ đồng.
Khi truy ngược nguyên nhân, ban lãnh đạo phát hiện quy trình "Cập nhật giá sản phẩm khuyến mãi" có tới ba phòng cùng tham gia: Marketing nhập giá khuyến mãi, IT đẩy giá lên hệ thống, và Vận hành kiểm tra hiển thị. Nhưng không ai được chỉ định là Accountable cho bước "Xác nhận giá đúng trước khi lên sàn". Marketing nói họ chỉ nhập theo file Excel sếp gửi; IT nói họ chỉ đẩy đúng con số nhận được; Vận hành nói họ kiểm giao diện chứ không kiểm logic giá.
Diễn giải: Đây là một quy trình thiếu hoàn toàn vai trò A. Khi mỗi phòng chỉ là Responsible cho một mảnh nhỏ và không ai Accountable cho kết quả tổng thể, sai sót lọt qua mọi khe hở. Sau sự cố, ShopViet xây RACI cho toàn bộ quy trình pricing: bước "Phê duyệt giá cuối trước khi go-live" được gán A duy nhất cho Trưởng phòng Category Management, C cho Marketing và Finance, I cho IT. Họ cũng thêm một bước double-check bắt buộc khi chênh lệch giá vượt 50%.
Bài học: Một quy trình không có A rõ ràng ở những bước rủi ro cao là một quả bom hẹn giờ. RACI buộc tổ chức phải trả lời câu hỏi "ai gật đầu cuối cùng?" trước khi sự cố xảy ra, chứ không phải sau.
Tình huống 2 — Quá nhiều người Consulted làm tê liệt quy trình tại một ngân hàng
Một ngân hàng cổ phần (tạm gọi VietCredit Bank) triển khai quy trình phê duyệt khoản vay tín chấp cho khách hàng cá nhân. Trên giấy tờ, quy trình rất "cẩn thận": mỗi hồ sơ phải được tham vấn bởi 7 vai trò — chuyên viên tín dụng, trưởng nhóm, phòng thẩm định, phòng quản trị rủi ro, phòng pháp chế, phòng tuân thủ, và bộ phận chống rửa tiền. Tất cả đều được đánh dấu C.
Kết quả: thời gian xử lý trung bình một hồ sơ vay 50 triệu đồng kéo dài tới 9 ngày làm việc, trong khi đối thủ fintech chỉ mất 2 giờ. Khách hàng bỏ đi hàng loạt, tỷ lệ chuyển đổi rớt xuống dưới 30%.
Diễn giải: Khi rà soát lại RACI, nhóm tư vấn nhận ra phần lớn các C nên được hạ xuống thành I, hoặc loại bỏ hoàn toàn với các khoản vay nhỏ. Pháp chế và chống rửa tiền chỉ thực sự cần Consulted với khoản vay trên 500 triệu; với khoản nhỏ, một bộ quy tắc tự động (business rules) đã đủ. Sau khi tinh gọn RACI — chỉ giữ 2 vai trò Consulted cho khoản vay nhỏ và phân tầng theo hạn mức — thời gian xử lý giảm xuống còn 6 giờ.
Bài học: "Consulted" không miễn phí. Mỗi C là một điểm chờ, một vòng giao tiếp hai chiều có thể làm chậm cả quy trình. Một RACI tốt không phải là RACI có nhiều người tham gia nhất, mà là RACI tối thiểu hóa số người cần tham vấn mà vẫn kiểm soát được rủi ro. Hãy nghi ngờ mọi hàng có quá nhiều chữ C.
Tình huống 3 — RACI cứu một dự án chuyển đổi số khỏi xung đột phòng ban
Một doanh nghiệp sản xuất đồ gỗ xuất khẩu ở Bình Dương (khoảng 800 công nhân) triển khai hệ thống ERP mới. Quy trình "Xử lý đơn hàng xuất khẩu" liên quan tới 5 phòng: Kinh doanh, Sản xuất, Kho, Xuất nhập khẩu (XNK), và Kế toán. Trong ba tháng đầu, các phòng liên tục đổ lỗi cho nhau mỗi khi đơn hàng trễ tàu.
Process Analyst của dự án quyết định xây RACI cho từng bước. Khi đến bước "Xác nhận ngày tàu chạy và chốt lịch đóng container", lộ ra vấn đề: cả phòng Kinh doanh và phòng XNK đều nghĩ phòng kia là người chốt. Workshop xây RACI buộc hai phòng ngồi cùng nhau và thống nhất: XNK là A (chịu trách nhiệm về lịch tàu vì họ làm việc với hãng tàu), Kinh doanh là C (được tham vấn vì họ giữ cam kết với khách), Sản xuất và Kho là I.
Diễn giải: Bản thân buổi workshop xây RACI có giá trị lớn ngang với tài liệu kết quả. Việc ngồi lại điền từng ô R-A-C-I buộc các phòng phải đối thoại trực tiếp về những "vùng xám" mà trước đây họ ngầm né tránh. Tỷ lệ đơn trễ tàu giảm từ 18% xuống 4% trong quý tiếp theo.
Bài học: RACI không chỉ là tài liệu — nó là một công cụ điều phối tổ chức. Phần lớn giá trị nằm ở quá trình tranh luận để đi đến đồng thuận, chứ không chỉ ở cái bảng cuối cùng.
Hướng dẫn từng bước
Đây là quy trình thực tế để xây một RACI matrix gắn với sơ đồ quy trình của bạn.
Bước 1 — Lấy danh sách hoạt động từ sơ đồ BPMN. Đừng bịa ra hoạt động. Mở sơ đồ BPMN As-Is của bạn và liệt kê từng Task (và Sub-process quan trọng) thành các hàng. Lý tưởng nhất, mỗi Task trong BPMN tương ứng một hàng trong RACI. Tránh chia quá nhỏ (đừng đưa cả những thao tác li ti) hay quá to (một "Sub-process" chứa 20 việc thì RACI sẽ vô nghĩa). Mức activity là vừa.
Bước 2 — Xác định danh sách vai trò làm cột. Dùng chức danh hoặc tên vai trò, không dùng tên cá nhân. Lấy gợi ý từ các Lane trong sơ đồ BPMN của bạn — mỗi Lane thường là một vai trò. Giữ số cột vừa phải; nếu vượt quá 7-8 vai trò, ma trận sẽ khó đọc.
Bước 3 — Gán A trước tiên, cho từng hàng. Đây là bước quan trọng nhất. Với mỗi hoạt động, hãy hỏi: "Một và chỉ một người chịu trách nhiệm cuối cùng cho kết quả này là ai?" Điền A trước. Nếu bạn không thể chỉ ra duy nhất một A, đó là tín hiệu quy trình đang có vấn đề về trách nhiệm — phải làm rõ ngay.
Bước 4 — Gán R cho từng hàng. Hỏi: "Ai trực tiếp làm việc này?" Có thể có nhiều R. Trong nhiều trường hợp, người Accountable cũng đồng thời là Responsible (ghi A/R), điều này hoàn toàn bình thường với các công việc nhỏ.
Bước 5 — Gán C và I. Đi qua các cột còn lại. Với mỗi vai trò chưa được gán, hỏi: họ cần được tham vấn trước (C) hay chỉ cần thông báo sau (I)? Nếu không thuộc cả hai, để trống. Hãy keo kiệt với chữ C.
Bước 6 — Kiểm tra theo hàng (horizontal check). Mỗi hàng phải có đúng một A và ít nhất một R. Hàng nào có hai A trở lên: sửa ngay. Hàng nào không có R: ai sẽ làm việc này?
Bước 7 — Kiểm tra theo cột (vertical check). Nhìn dọc từng cột:
- Một vai trò có quá nhiều A? Có thể là điểm thắt cổ chai (bottleneck) — người này sẽ quá tải.
- Một vai trò toàn chữ I, không có gì khác? Có thể họ không thực sự cần trong quy trình này.
- Một cột trống hoàn toàn? Vai trò đó có thể loại khỏi ma trận.
Lỗi thường gặp & mẹo
Lỗi 1 — Có nhiều hơn một A trên cùng một hàng. Đây là sai lầm nghiêm trọng nhất. "Để cho công bằng" mà gán hai phòng cùng Accountable thực chất là xóa bỏ trách nhiệm. Mẹo: nếu hai bên thực sự không chịu nhường, hãy nâng A lên một cấp quản lý chung phía trên cả hai.
Lỗi 2 — Lạm phát chữ C (everyone is Consulted). Vì nể nang hoặc sợ bỏ sót ai đó, người ta đánh C tràn lan. Hậu quả là quy trình tê liệt (Tình huống 2). Mẹo: với mỗi C, tự hỏi "nếu không hỏi người này, điều tồi tệ nhất gì sẽ xảy ra?" Nếu câu trả lời nhẹ nhàng, hạ xuống I hoặc bỏ.
Lỗi 3 — Hàng không có A nào. Quả bóng trách nhiệm bị thả rơi (Tình huống 1). Mọi hoạt động phải có chủ. Không có ngoại lệ.
Lỗi 4 — Dùng tên người thay vì vai trò. "Chị Lan ký duyệt" — rồi chị Lan nghỉ thai sản, cả quy trình đứng. Luôn dùng chức danh: "Trưởng phòng Kế toán duyệt".
Lỗi 5 — Nhầm lẫn R và A. Người làm và người chịu trách nhiệm cuối không nhất thiết là một. Nhân viên soạn hợp đồng (R) khác với trưởng phòng phê duyệt và chịu trách nhiệm (A).
Lỗi 6 — RACI tách rời sơ đồ quy trình. Một RACI được xây từ trí tưởng tượng thay vì từ các Task BPMN thực tế sẽ nhanh chóng lỗi thời. Mẹo: gắn từng hàng RACI với một Task ID trong sơ đồ; khi quy trình đổi, RACI đổi theo.
Mẹo nâng cao — biến thể RACI. Khi cần chi tiết hơn, có thể mở rộng thành RASCI (thêm S — Support: người hỗ trợ nguồn lực cho R nhưng không trực tiếp làm) hoặc RACI-VS (thêm V — Verify và S — Sign-off). Nhưng đừng vội phức tạp hóa: với 90% trường hợp, bốn chữ RACI nguyên bản là đủ. Chỉ thêm vai trò khi tổ chức thực sự gặp vấn đề mà bốn chữ không mô tả được.
Bài tập thực hành
Hãy chọn một quy trình quen thuộc nơi bạn làm việc (hoặc dùng quy trình giả định "Xử lý yêu cầu nghỉ phép của nhân viên") và thực hiện:
- Liệt kê 5-7 hoạt động của quy trình thành các hàng. Ví dụ với nghỉ phép: Nhân viên tạo đơn → Quản lý trực tiếp xem xét → Phê duyệt → HR ghi nhận → Cập nhật lịch nhóm.
- Liệt kê các vai trò liên quan thành cột: Nhân viên, Quản lý trực tiếp, Trưởng bộ phận, HR, Kế toán lương.
- Điền RACI cho từng ô, áp dụng đúng thứ tự: A trước, rồi R, rồi C và I.
- Tự kiểm tra ngang: mỗi hàng có đúng một A và ít nhất một R không?
- Tự kiểm tra dọc: có vai trò nào quá tải (nhiều A), hay vai trò nào thừa (toàn I hoặc trống)?
- Câu hỏi phản tư: Có hàng nào bạn thấy khó xác định A duy nhất không? Đó chính là điểm yếu thực sự trong quy trình của bạn — hãy ghi chú lại để thảo luận với đồng nghiệp.
Tóm tắt
RACI matrix là công cụ phân định trách nhiệm gắn liền với từng hoạt động trong quy trình, lấp đầy khoảng trống mà sơ đồ BPMN thuần túy không trả lời được: ai làm, ai chịu trách nhiệm, ai được hỏi, ai được báo.
Bốn vai trò cốt lõi:
- R (Responsible) — người trực tiếp làm; có thể nhiều người.
- A (Accountable) — người chịu trách nhiệm cuối cùng; duy nhất một người mỗi hoạt động — đây là quy tắc bất khả xâm phạm.
- C (Consulted) — được tham vấn trước, giao tiếp hai chiều; hãy keo kiệt với vai trò này.
- I (Informed) — được thông báo sau, giao tiếp một chiều.
Quy trình xây dựng: lấy hoạt động từ Task BPMN, dùng vai trò chứ không dùng tên người, gán A trước tiên, rồi R-C-I, sau đó kiểm tra ngang và dọc, cuối cùng xác thực qua workshop. Khi làm đúng, RACI không chỉ là một cái bảng — nó là tấm bản đồ trách nhiệm giúp cả tổ chức ngừng thả rơi những quả bóng quan trọng.