Framework RACI: Ma trận Trách nhiệm — Giải quyết triệt để vấn đề "Ai làm việc gì?"

9 giờ tối thứ Sáu, một launch bị trễ vì thiếu nội dung landing page. Trưởng phòng Marketing khẳng định: "Tôi tưởng bên Product viết, vì brief kỹ thuật là của họ." Product Manager phản pháo: "Tôi chỉ duyệt nội dung, viết là việc của Content team chứ." Content Executive ngơ ngác: "Chưa ai giao task này cho em cả, em tưởng anh Product tự viết vì đây là sản phẩm mới hoàn toàn." Ba người, ba cách hiểu, một việc bị rơi — không phải vì ai lười, mà vì không ai thực sự sở hữu nó.

Đây không phải chuyện hiếm. Trong hầu hết các đội ngũ vận hành nhanh, việc bị rơi giữa các khe (dropped between the cracks) không đến từ thiếu năng lực hay thiếu thiện chí, mà từ một lỗ hổng âm thầm hơn nhiều: mơ hồ vai trò (role ambiguity). Khi một task có 3 người "liên quan" nhưng 0 người chịu trách nhiệm cuối, tốc độ đội ngũ tự động chậm lại — không phải vì việc khó, mà vì mọi người phải mất thời gian đoán, hỏi lại, chờ xác nhận, rồi vẫn làm sai người.

RACI — Responsible, Accountable, Consulted, Informed — là công cụ già dặn nhưng vẫn là một trong những cách nhanh nhất để dập tắt kiểu hỗn loạn này. Nó không phải triết lý quản trị cao siêu; nó là một bảng kẻ ô đơn giản, nhưng nếu làm đúng, nó buộc cả đội phải trả lời rành mạch một câu hỏi mà rất nhiều tổ chức Việt Nam né tránh: "Nếu việc này thất bại, ai là người chịu trách nhiệm cuối cùng?"

Bản chất của RACI — Vì sao một ma trận đơn giản lại quan trọng đến vậy

RACI là một ma trận phân định vai trò trách nhiệm (Responsibility Assignment Matrix), gán cho mỗi đầu việc/quyết định một trong bốn vai trò rõ ràng:

• R — Responsible (Người thực thi): người trực tiếp làm ra output. Có thể có nhiều R cho một việc.
• A — Accountable (Người chịu trách nhiệm cuối): người ký duyệt, chịu trách nhiệm về kết quả trước cấp trên/tổ chức. Bắt buộc và chỉ được có đúng một A cho mỗi việc.
• C — Consulted (Người được tham vấn): người có ý kiến chuyên môn cần hỏi trước khi quyết, thường là two-way communication (hỏi — trả lời).
• I — Informed (Người được thông báo): người cần biết kết quả sau khi việc xong hoặc quyết định được đưa ra, one-way communication, không cần phản hồi.

Bản chất sâu xa của RACI không nằm ở việc "điền bảng cho đẹp", mà ở nguyên tắc cốt lõi: mỗi đầu việc chỉ có duy nhất một Accountable. Đây chính là điều giải quyết tận gốc vấn đề "tưởng người khác làm" — vì khi trách nhiệm cuối được chỉ đích danh một người, không còn chỗ cho sự mơ hồ về việc ai là người phải đứng ra nếu deadline trôi qua mà việc chưa xong.

Vì sao nó quan trọng cho hiệu suất đội ngũ? Ba lý do:

1. Giảm ma sát ra quyết định. Không cần họp lại để hỏi "ai duyệt cái này" — ma trận đã trả lời sẵn.
2. Giảm việc rơi giữa các khe. Mỗi task luôn có ít nhất một R xác định — không còn khoảng trống không ai nhận.
3. Giảm xung đột ngầm. Nhiều mâu thuẫn nhóm thực chất là mâu thuẫn vai trò bị che giấu dưới vỏ bọc mâu thuẫn tính cách. Làm rõ RACI thường làm giảm hẳn số lần "chỉnh nhau" trong họp.

RACI không thay thế được năng lực chuyên môn hay văn hóa tin tưởng, nhưng nó dọn sạch một loại nhiễu rất tốn thời gian: nhiễu do không biết ai là ai trong một quy trình.

Khung mô hình: 4 vai trò, 1 nguyên tắc bất di bất dịch

Nguyên tắc trung tâm của RACI có thể tóm trong một câu: Nhiều Responsible được, nhưng chỉ một Accountable.

Đây là bảng mô tả đầy đủ 4 vai trò và cách phân biệt trong thực tế:

Điểm dễ nhầm nhất: R và A có thể là cùng một người (với việc nhỏ, người làm luôn chịu trách nhiệm cuối), nhưng A không bao giờ được bỏ trống và không bao giờ được để nhiều hơn một A. Khi một dòng trong ma trận có 2 chữ A, đó là dấu hiệu chắc chắn của xung đột thẩm quyền sắp xảy ra — về bản chất, tổ chức đang nói với hai người: "cả hai anh chị đều phải chịu trách nhiệm", điều mà trong khủng hoảng thực tế luôn suy biến thành "không ai chịu trách nhiệm cả" vì mỗi người đều nghĩ người kia sẽ xử lý.

Phân tích theo 5W3H1R: Xây ma trận RACI cho một dự án/quy trình

Why — Tại sao phải xây RACI

Pain point phổ biến nhất trong các đội ngũ tăng trưởng nhanh là: càng nhiều người tham gia một dự án, càng nhiều việc rơi vào vùng xám "ai đó sẽ làm". Hậu quả cụ thể: deadline trôi vì chờ duyệt không rõ ai duyệt; một quyết định bị đảo ngược vì người tưởng mình có quyền quyết hóa ra chỉ nên được tham vấn; nhân sự giỏi nản lòng vì làm xong việc rồi bị "vượt mặt" bởi một quyết định khác từ người không ai biết là có thẩm quyền. RACI tạo giá trị bằng cách biến "trách nhiệm ngầm hiểu" thành "trách nhiệm viết ra giấy, cả đội cùng thấy" — giảm thời gian họp để làm rõ ai làm gì, tăng tốc độ ra quyết định, và là cơ sở minh bạch để đánh giá hiệu suất cá nhân theo đúng phần việc họ thực sự sở hữu.

What — Bản chất và nội dung của một ma trận RACI

Một ma trận RACI là bảng hai chiều: hàng là các đầu việc/quyết định/giai đoạn của quy trình, cột là các vai trò/cá nhân tham gia; giao điểm mỗi ô ghi một trong bốn ký tự R/A/C/I (một ô có thể để trống nếu người đó không liên quan đến việc ở hàng đó).

Phạm vi áp dụng (scope in):

• Dự án có nhiều phòng ban/cá nhân tham gia (ra mắt sản phẩm, chiến dịch marketing, triển khai hệ thống mới).
• Quy trình lặp lại thường xuyên gây tranh cãi về vai trò (quy trình duyệt chi, quy trình xử lý khiếu nại khách hàng, quy trình release phần mềm).
• Giai đoạn bàn giao giữa các nhóm (handoff) — nơi việc dễ rơi nhất.

Phạm vi không nên áp dụng (scope out):

• Task cá nhân đơn giản, một người làm từ đầu đến cuối, không cần phối hợp.
• Không dùng RACI để thay thế mô tả công việc (job description) toàn diện — RACI chỉ áp cho một việc/dự án cụ thể, không phải toàn bộ vai trò của một vị trí.
• Không dùng như công cụ "đổ lỗi" hồi tố sau khi sự cố xảy ra — RACI phải được thống nhất TRƯỚC khi dự án chạy.

Thành phần cấu thành một ma trận RACI hoàn chỉnh:

1. Danh sách đầu việc/quyết định chính (activities) — chia nhỏ đủ để mỗi dòng có thể gán vai trò rõ ràng, nhưng không vụn tới mức thành checklist thao tác.
2. Danh sách vai trò/cá nhân tham gia (thường 4-8 cột, quá nhiều cột là dấu hiệu dự án cần chia nhỏ).
3. Ký hiệu R/A/C/I tại từng giao điểm.
4. Ghi chú xử lý ngoại lệ (escalation path) khi có bất đồng giữa A và C.

Output cụ thể: một bảng RACI được cả đội đồng thuận, gắn kèm dự án/quy trình, được review lại mỗi khi phạm vi dự án thay đổi đáng kể hoặc nhân sự chủ chốt luân chuyển.

Who — Ai thực hiện, ai hưởng lợi (RACI cho chính việc xây RACI)

Vận dụng chính khung RACI cho hoạt động "xây ma trận RACI":

Người hưởng lợi trực tiếp: chính các thành viên thực thi (R) — vì họ biết chính xác phạm vi việc mình cần làm và không phải chịu trách nhiệm ngoài phạm vi; và Accountable — vì họ có công cụ để yêu cầu tiến độ đúng người thay vì hỏi cả nhóm.

Where — Diễn ra ở đâu, hệ thống nào

Trong vận hành thực tế, ma trận RACI nên sống ở nơi cả team truy cập thường xuyên: tài liệu dự án dùng chung (Google Docs/Notion/Confluence), gắn link ngay trong kênh chat dự án, và lý tưởng nhất là được nhúng vào công cụ quản trị công việc để mỗi task tự động hiển thị ai là R/A.

Trong bối cảnh module Quản trị nhóm của Intelligence Hub (SellersStar), RACI nên là một thuộc tính gắn liền với từng dự án/quy trình được cấu hình trong hệ thống: mỗi đầu việc (task/milestone) có trường "Accountable" bắt buộc phải điền đúng 1 người trước khi task được kích hoạt, và trường "Responsible/Consulted/Informed" hiển thị ngay trên thẻ công việc để bất kỳ ai mở task cũng thấy vai trò của từng người liên quan mà không cần hỏi lại. Phạm vi áp dụng ban đầu nên là các dự án liên phòng ban (cross-functional) và các quy trình vận hành lặp lại có lịch sử tranh cãi vai trò, trước khi mở rộng ra toàn bộ dự án.

When — Khi nào bắt đầu, khi nào áp dụng, nhịp lặp lại

Thời điểm bắt đầu: ngay tại buổi kick-off dự án, trước khi phân task đầu tiên — không phải khi dự án đã chạy được vài tuần và bắt đầu có xung đột (lúc đó RACI dễ bị hiểu nhầm thành công cụ quy trách nhiệm cho lỗi đã xảy ra).

Dấu hiệu kích hoạt (khi nào chắc chắn cần RACI dù chưa có kế hoạch từ đầu):

• Một việc đã bị "rơi" ít nhất một lần vì hai bên đều tưởng bên kia làm.
• Dự án có từ 3 phòng ban trở lên tham gia.
• Có lịch sử tranh cãi về ai có quyền quyết cuối trong một loại quyết định lặp lại.

Nhịp lặp lại: review lại ma trận mỗi khi có thay đổi lớn về phạm vi dự án, khi nhân sự chủ chốt (đặc biệt là A) nghỉ việc/luân chuyển, hoặc định kỳ theo chu kỳ sprint/quý đối với các quy trình vận hành thường trực (không phải dự án có điểm kết thúc).

How — Quy trình xây ma trận RACI (các bước đánh số)

Bước 1 — Liệt kê đầu việc/quyết định chính.
Đầu vào: phạm vi dự án, kế hoạch/roadmap sơ bộ. Hoạt động: Trưởng dự án cùng các trưởng nhóm liên quan liệt kê toàn bộ đầu việc/quyết định lớn (không vụn tới mức thao tác hàng ngày, không gộp tới mức một dòng chứa cả chục việc khác nhau). Đầu ra: danh sách 8-20 đầu việc/quyết định theo trình tự dự án.

Bước 2 — Liệt kê vai trò/cá nhân tham gia.
Đầu vào: sơ đồ tổ chức dự án. Hoạt động: xác định ai thực sự chạm vào dự án này — tránh đưa vào những vai trò "cho có" không thực sự tham gia. Đầu ra: danh sách cột (4-8 vai trò/cá nhân là lý tưởng; nhiều hơn nên tách dự án con).

Bước 3 — Soạn nháp ma trận (draft) với 1 người chủ trì.
Đầu vào: hai danh sách ở Bước 1-2. Hoạt động: Trưởng dự án điền nháp từng ô R/A/C/I dựa trên hiểu biết ban đầu về năng lực và thẩm quyền của từng người/nhóm. Đầu ra: bản nháp RACI v0.

Bước 4 — Kiểm tra nguyên tắc "1 Accountable duy nhất" cho từng dòng.
Đầu vào: bản nháp v0. Hoạt động: rà từng dòng, nếu có 2+ ô ghi A, chủ trì phải buộc chọn một người chịu trách nhiệm cuối và chuyển người còn lại thành C hoặc R. Nếu có dòng không có A nào, phải bổ sung ngay — không được để trống. Đầu ra: bản nháp v1 tuân thủ nguyên tắc 1-A.

Bước 5 — Họp thống nhất cùng các bên liên quan.
Đầu vào: bản nháp v1. Hoạt động: trình bày ma trận trong buổi họp có mặt đại diện các nhóm, hỏi trực tiếp "anh/chị có đồng ý với vai trò được gán không?" — đây là bước quan trọng nhất để tránh RACI trở thành áp đặt một chiều. Ghi nhận các điểm bất đồng và xử lý ngay tại chỗ. Đầu ra: bản RACI được xác nhận (v-final) và danh sách các điểm còn tranh cãi cần escalate lên cấp cao hơn.

Bước 6 — Công bố và gắn vào công cụ làm việc.
Đầu vào: bản RACI v-final. Hoạt động: đăng lên kênh chung, gắn vào tài liệu dự án hoặc công cụ quản trị công việc (Jira/Trello/module Quản trị nhóm), đảm bảo mọi task được tạo ra tham chiếu đúng người R/A tương ứng. Đầu ra: RACI trở thành tài liệu sống, dễ tra cứu bất cứ lúc nào có tranh cãi vai trò.

Bước 7 — Review định kỳ và cập nhật khi có thay đổi.
Đầu vào: RACI hiện hành + biến động nhân sự/phạm vi. Hoạt động: mỗi khi có thay đổi lớn (nhân sự A nghỉ việc, dự án mở rộng phạm vi, phát sinh đầu việc mới chưa có trong ma trận), tổ chức một buổi cập nhật ngắn theo đúng Bước 3-5 thu gọn. Đầu ra: bản RACI phiên bản mới, có version log để truy vết thay đổi.

How Much — Nguồn lực cần thiết

Về thời gian: một buổi xây dựng RACI cho dự án cỡ trung bình thường cần một buổi họp kick-off (có thể lồng ghép trong buổi kick-off dự án sẵn có, không cần buổi riêng), cộng thêm thời gian chuẩn bị nháp trước đó của Trưởng dự án. Về công cụ: không cần phần mềm chuyên dụng — một bảng tính hoặc tài liệu chia sẻ là đủ ở quy mô nhỏ; ở quy mô tổ chức, nên tích hợp vào công cụ quản trị công việc/module Quản trị nhóm để RACI gắn liền với từng task thay vì nằm rời trong một file tĩnh dễ bị quên cập nhật. Về ngân sách: hoạt động này gần như không phát sinh chi phí trực tiếp, chi phí thực sự là thời gian họp và kỷ luật duy trì cập nhật — đây mới là phần dễ bị bỏ quên nhất.

How Long — Bao lâu thấy kết quả

Tác động tức thời (ngay sau khi công bố): giảm rõ rệt số câu hỏi "ai làm việc này" trong kênh chat dự án — thường thấy trong tuần đầu áp dụng.

Tác động trung hạn (4-8 tuần): giảm số lần việc bị trễ do chờ duyệt sai người hoặc chờ xác nhận vai trò; các cuộc họp bắt đầu ngắn hơn vì không cần dành thời gian làm rõ ai chịu trách nhiệm.

Tác động dài hạn (1-2 chu kỳ dự án, tức vài tháng): RACI trở thành phản xạ mặc định khi khởi động dự án mới, và trở thành cơ sở tham chiếu công bằng khi đánh giá hiệu suất — vì mỗi người được đánh giá đúng trên phần việc họ thực sự được giao là Responsible/Accountable, không bị đánh giá oan vì việc của người khác.

Risk — Rủi ro tiềm ẩn và biện pháp khắc phục

Framework áp dụng ngay: Bảng RACI mẫu cho một dự án ra mắt tính năng mới

Có thể copy khung này và điền trực tiếp cho dự án của bạn:

Cách đọc nhanh: cột là người/nhóm, hàng là đầu việc, mỗi hàng chỉ có đúng một A. Khi in ra dán ở kênh chat dự án, bất kỳ ai thắc mắc "việc này ai lo" chỉ cần nhìn bảng thay vì hỏi cả nhóm.

Case Study Việt Nam (minh họa điển hình)

Đây là case minh họa điển hình, không phải số liệu của một công ty cụ thể nào — dùng để hình dung cách RACI vận hành trong bối cảnh doanh nghiệp Việt.

Một công ty thương mại điện tử quy mô vừa chuẩn bị ra mắt tính năng "Live Shopping" — cần phối hợp giữa đội Sản phẩm, Kỹ thuật, Marketing, Vận hành kho, và CSKH. Trước khi có RACI, buổi họp kick-off kết thúc với một danh sách việc chung chung: "Marketing lo truyền thông, Kỹ thuật lo hệ thống, CS lo hỗ trợ khách". Hai tuần trước ngày ra mắt, nhóm phát hiện chưa ai chuẩn bị kịch bản xử lý khi đơn hàng live bị lỗi thanh toán — Marketing tưởng Kỹ thuật đã có sẵn quy trình fallback, Kỹ thuật tưởng CS sẽ tự xử lý khi phát sinh, còn CS thì chưa từng được thông báo về tính năng này ở mức chi tiết để chuẩn bị kịch bản.

Trưởng dự án (một PM) họp lại toàn đội, dùng đúng quy trình 7 bước ở trên: liệt kê lại toàn bộ đầu việc theo mốc thời gian, xác định 5 nhóm tham gia, và quan trọng nhất — với riêng đầu việc "xử lý lỗi thanh toán trong live", ban đầu bản nháp có cả Kỹ thuật và CS đều được đánh dấu A. PM buộc phải quyết: Kỹ thuật là A (vì họ là bên duy nhất có thể sửa lỗi hệ thống), CS chuyển thành R cho phần giao tiếp với khách hàng trong lúc chờ xử lý, và cả hai cùng được đánh dấu là bên phải phối hợp trực tiếp (không phải chỉ Informed cho nhau). Sau khi ma trận được thống nhất và dán lên kênh chat dự án chung, đội chỉ mất một buổi để rà lại toàn bộ các đầu việc còn thiếu người phụ trách — phát hiện thêm 3 đầu việc chưa từng được giao cho ai (trong đó có chính kịch bản xử lý lỗi thanh toán) và bổ sung ngay trước ngày ra mắt.

Bài học không nằm ở việc RACI "cứu" buổi ra mắt một cách thần kỳ, mà ở chỗ nó biến một cuộc thảo luận mơ hồ ("chắc ai đó sẽ lo") thành một danh sách buộc phải trả lời dứt khoát — và chính hành động buộc trả lời đó mới là thứ phát hiện ra lỗ hổng.

GÓC NHÌN TEAM LEADER

• Nếu ngay bây giờ tôi hỏi cả đội "ai là Accountable của dự án X", liệu có nhận được cùng một câu trả lời từ tất cả mọi người không?
• Trong ma trận hiện tại (nếu đã có), có dòng nào đang bị gán 2 người Accountable cùng lúc — và tôi đã né tránh việc quyết định ai là người thật sự chịu trách nhiệm chưa?
• Có đầu việc quan trọng nào trong quy trình của đội đang không xuất hiện trong bất kỳ ma trận trách nhiệm nào — tức là đang "vô chủ"?
• Danh sách Consulted của tôi có đang quá dài, khiến mọi quyết định nhỏ cũng phải đi qua nhiều vòng hỏi ý kiến không cần thiết?
• Tôi có đang dùng RACI như công cụ làm rõ vai trò trước khi làm việc, hay đang âm thầm biến nó thành công cụ quy trách nhiệm sau khi sự cố đã xảy ra?

🔗 Liên kết với các bài khác (Alignment)

RACI là công cụ làm rõ vai trò, nhưng nó phát huy hiệu quả cao nhất khi đi cùng các framework khác trong series: kết hợp với Framework RADAR đo sức khỏe đội ngũ để theo dõi xem sự mơ hồ vai trò có đang là nguyên nhân gốc của các vấn đề hiệu suất hay không; là nền tảng để Delegation Framework — 5 cấp độ ủy quyền vận hành trơn tru, vì ủy quyền chỉ hiệu quả khi người nhận việc biết chính xác mình là R hay A; và gắn liền với OKRs cho Nhóm (Team OKRs) — vì một Key Result không có Accountable rõ ràng thì cũng dễ rơi vào đúng cái bẫy "tưởng người khác làm" như trong ví dụ mở đầu.

RACI cũng là mảnh ghép quan trọng khi xây Mô hình 5 Dysfunctions of a Team (Lencioni) — vì sự thiếu trách nhiệm giải trình (accountability) là một trong 5 rối loạn cốt lõi mà Lencioni chỉ ra, và một ma trận RACI được tuân thủ nghiêm túc chính là cách cụ thể hóa accountability thành hành vi hàng ngày thay vì một khẩu hiệu trừu tượng.

Kết luận

Mơ hồ trách nhiệm không tự nhiên biến mất khi đội ngũ "trưởng thành" hơn hay "hiểu ý nhau" hơn — nó chỉ biến mất khi có ai đó chủ động ngồi xuống, liệt kê từng đầu việc, và buộc cả nhóm trả lời rành mạch câu hỏi "ai là người chịu trách nhiệm cuối cùng ở đây". RACI không phức tạp, không cần công cụ đắt tiền, không cần một buổi đào tạo dài — nó chỉ cần kỷ luật áp dụng nguyên tắc một-Accountable-duy-nhất và thói quen review khi có thay đổi. Nếu đội của bạn đang có những việc lặp đi lặp lại kiểu "tưởng người khác làm", đừng chờ đến sự cố tiếp theo — hãy dành một buổi họp, kẻ ra bảng RACI cho dự án đang chạy dở dang nhất, và xem có bao nhiêu dòng đang không có ai thực sự là A.

Bài trước: OKRs cho Nhóm (Team OKRs) · Bài tiếp theo: Mô hình 6 Thinking Hats (Edward de Bono)