Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là trưởng phòng vận hành của một startup gọi xe công nghệ ở TP.HCM. Một buổi sáng, ba nhóm khác nhau cùng chạy vào phòng bạn: đội Marketing đang chờ đội Product duyệt banner khuyến mãi, đội Product lại bảo họ đang chờ đội Legal xác nhận điều khoản, còn đội Legal thì ngơ ngác vì "không ai bảo tôi phải duyệt cái này." Chiến dịch trễ ba ngày, mất trọn dịp cuối tuần vàng, và không một ai cảm thấy mình có lỗi — vì thật sự không ai biết rõ ai chịu trách nhiệm.
Đây không phải là câu chuyện về năng lực. Ai cũng giỏi, ai cũng bận. Vấn đề nằm ở chỗ quyền quyết định (decision rights) và trách nhiệm chưa được phân định rõ ràng. Khi tổ chức còn nhỏ, năm bảy người ngồi chung một phòng, mọi thứ tự trôi vì ai cũng thấy ai đang làm gì. Nhưng khi bạn scale lên 50, 100, 300 người, sự mơ hồ về trách nhiệm chính là loại "nợ vận hành" âm thầm giết chết tốc độ. Công việc rơi vào khoảng trống giữa các nhóm, hoặc tệ hơn, năm người cùng nghĩ mình sở hữu một quyết định và giẫm chân nhau.
RACI Matrix là một trong những công cụ đơn giản nhất nhưng mạnh nhất để chữa căn bệnh này. Nó không đòi hỏi phần mềm đắt tiền hay quy trình phức tạp — chỉ cần một bảng và sự trung thực. Trong bài này, bạn sẽ học cách dùng nó để biến sự mơ hồ thành sự rõ ràng, và quan trọng hơn, để mỗi quyết định trong tổ chức đều có một "chủ nhân" duy nhất.
Khái niệm cốt lõi
RACI là gì
RACI là viết tắt của bốn vai trò mà mỗi người có thể đảm nhận đối với một công việc hoặc một quyết định cụ thể:
- R — Responsible (Người thực thi): Đây là người (hoặc những người) trực tiếp xắn tay áo làm việc. Họ viết code, soạn hợp đồng, thiết kế banner. Một công việc có thể có nhiều người Responsible.
- A — Accountable (Người chịu trách nhiệm cuối): Đây là người "đứng mũi chịu sào", người phê duyệt kết quả và chịu trách nhiệm nếu mọi thứ hỏng. Quy tắc vàng bất di bất dịch: mỗi công việc chỉ có ĐÚNG MỘT người Accountable. Nếu có hai người Accountable, thực chất là không có ai cả — vì họ sẽ đùn đẩy cho nhau. A là người có quyền nói "được, chốt" hoặc "chưa, làm lại".
- C — Consulted (Người được tham vấn): Đây là những người bạn cần hỏi ý kiến trước khi ra quyết định, vì họ có chuyên môn hoặc lợi ích liên quan. Đây là giao tiếp hai chiều — họ đưa input, bạn lắng nghe và cân nhắc. Ví dụ: đội Legal được tham vấn về điều khoản, đội Security được tham vấn về một thay đổi hạ tầng.
- I — Informed (Người được thông báo): Đây là những người cần biết kết quả sau khi quyết định đã chốt, nhưng không cần cho ý kiến. Giao tiếp một chiều. Ví dụ: CEO cần được thông báo chiến dịch đã chạy, nhưng không cần duyệt từng chi tiết.
Phân biệt Responsible và Accountable — điểm gây nhầm lẫn nhất
Rất nhiều người mới học RACI lẫn lộn R và A, vì trong tiếng Việt cả hai đều dịch là "chịu trách nhiệm". Hãy ghi nhớ cách phân biệt đơn giản: R là người LÀM, A là người DUYỆT và GÁNH. Một lập trình viên viết tính năng thanh toán là R; Engineering Manager duyệt và chịu trách nhiệm nếu tính năng đó làm sập hệ thống là A. Một người có thể vừa là R vừa là A (ví dụ một senior tự làm và tự chịu trách nhiệm cho một task nhỏ), nhưng khi tổ chức lớn lên, tách bạch R và A là điều giúp phân quyền hiệu quả.
Vì sao "chỉ một A" là bất khả xâm phạm
Nguyên lý này bắt nguồn từ một sự thật tâm lý học tổ chức: khi trách nhiệm được chia đều cho nhiều người, không ai thực sự cảm thấy mình sở hữu nó — hiện tượng "social loafing" (lười biếng tập thể). Một Accountable duy nhất tạo ra một điểm quy trách nhiệm rõ ràng (single point of accountability). Nó không có nghĩa người đó độc đoán; A vẫn phải tham vấn C, vẫn phải để R làm việc. Nhưng khi cần một quyết định cuối cùng, ai cũng biết gõ cửa phòng ai.
RACI gắn với Decision Rights
RACI không chỉ để chia việc — sâu xa hơn, nó là công cụ định nghĩa quyền quyết định. Trong một tổ chức đang scale, câu hỏi lớn không phải "ai làm việc này" mà là "ai được quyền nói câu cuối cùng". Khi bạn điền chữ A vào một ô, bạn đang trao quyền quyết định cho người đó. Đây chính là lý do RACI thường được vẽ ở cấp độ tổ chức, không chỉ cấp độ dự án — nó là bản đồ quyền lực được viết ra một cách minh bạch.
Tình huống thực tế
Tình huống 1 — Chiến dịch marketing bị kẹt ở Tiki (bối cảnh giả định hợp lý)
Một đội tăng trưởng tại một sàn thương mại điện tử lớn ở Việt Nam chuẩn bị chạy chiến dịch flash sale 12/12, doanh thu kỳ vọng khoảng 8 tỷ đồng trong 24 giờ. Trước đó, mỗi lần chạy chiến dịch đều rối loạn vì không rõ ai duyệt giá khuyến mãi cuối cùng: Trưởng phòng Marketing nghĩ mình quyết, Giám đốc Tài chính cũng nghĩ mình phải ký, còn Trưởng nhóm Vận hành kho thì không được ai hỏi nên hàng thường thiếu.
Họ ngồi lại và vẽ một RACI cho quy trình "Duyệt và triển khai flash sale":
- Chốt mức giảm giá cuối cùng: A = Giám đốc Tăng trưởng; R = chuyên viên pricing; C = Giám đốc Tài chính; I = CEO.
- Đảm bảo tồn kho đủ hàng: A = Trưởng nhóm Vận hành kho; R = nhân viên điều phối kho; C = đội Mua hàng; I = Giám đốc Tăng trưởng.
- Thiết kế và duyệt creative: A = Trưởng phòng Marketing; R = designer; C = đội Legal (về nội dung quảng cáo); I = đội Tăng trưởng.
Bài học: RACI không chỉ giải quyết "ai làm gì" mà còn tháo ngòi những xung đột quyền lực ngầm. Khi mỗi người biết rõ ranh giới quyền của mình, họ ngừng lấn sân.
Tình huống 2 — Sự cố sập hệ thống và câu hỏi "ai được quyền rollback"
Một công ty fintech ở Singapore mở rộng đội kỹ thuật từ 15 lên 60 người trong một năm. Một đêm, sau khi deploy phiên bản mới, hệ thống thanh toán lỗi 30 phút. Vấn đề không phải là lỗi kỹ thuật — mà là không ai dám bấm nút rollback vì không rõ mình có quyền. Kỹ sư trực đêm sợ bị đổ lỗi, nên gọi điện đánh thức ba người quản lý lúc 2 giờ sáng để "xin phép", mất thêm 20 phút quý giá.
Sau sự cố, họ thiết lập một RACI rõ ràng cho quy trình xử lý sự cố (incident response):
- Quyết định rollback trong lúc sự cố: A = Incident Commander (kỹ sư trực ca, được trao quyền tạm thời); R = kỹ sư on-call; C = không ai (trong lúc khẩn cấp, tham vấn được bỏ qua); I = toàn bộ đội kỹ thuật và quản lý.
- Điều tra nguyên nhân gốc sau sự cố: A = Engineering Manager của đội liên quan; R = kỹ sư gây ra thay đổi; C = đội SRE; I = CTO.
Bài học: Decision rights phải rõ ràng trước khi khủng hoảng xảy ra, không phải giữa lúc khủng hoảng. Một RACI tốt cho incident response giúp giảm thời gian phản ứng từ hàng chục phút xuống còn vài giây.
Tình huống 3 — RACI cứu một dự án cross-team ở công ty SaaS
Một công ty SaaS Việt Nam làm phần mềm quản lý bán hàng triển khai tính năng tích hợp với ngân hàng, đòi hỏi phối hợp giữa bốn nhóm: Product, Backend, Security và Đối tác (partnership). Sau hai tháng, dự án giậm chân tại chỗ. Khi mổ xẻ, họ phát hiện mọi quyết định đều "treo" vì ai cũng nghĩ nhóm khác sẽ quyết.
Họ làm một buổi workshop RACI kéo dài hai giờ. Điều thú vị là ngay trong buổi đó, một tranh cãi nảy lửa nổ ra về việc "ai là A cho quyết định chọn phương thức xác thực API". Product nghĩ đó là quyết định kỹ thuật (thuộc Backend); Backend nghĩ đó là quyết định rủi ro (thuộc Security). Cuộc tranh cãi này chính là giá trị — vì nó phơi bày một khoảng trống trách nhiệm đã âm thầm làm tê liệt dự án suốt hai tháng. Cuối cùng họ thống nhất Security là A (vì đây là quyết định rủi ro), Backend là R, Product là C.
Diễn giải: Đôi khi giá trị lớn nhất của RACI không nằm ở cái bảng cuối cùng, mà ở cuộc trò chuyện để tạo ra nó. Việc buộc mọi người ngồi lại và tranh luận "ai là A" làm lộ ra những giả định ngầm mâu thuẫn nhau.
Bài học: Nếu buổi làm RACI của bạn diễn ra êm ru không ai tranh cãi, hãy cẩn thận — có thể mọi người chưa thực sự suy nghĩ nghiêm túc, hoặc đang né tránh những câu hỏi khó.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng để xây dựng một RACI Matrix cho nhóm hoặc dự án của mình.
Bước 1 — Liệt kê các công việc / quyết định (hàng). Viết ra cột dọc bên trái tất cả những hoạt động hoặc quyết định quan trọng. Đừng liệt kê quá chi tiết vụn vặt; hãy tập trung vào những việc thực sự cần rõ ràng về trách nhiệm. Với một quy trình phức tạp, 10–20 hàng là hợp lý.
Bước 2 — Liệt kê con người / vai trò (cột). Viết ra hàng ngang phía trên tên các vai trò (nên dùng chức danh, không dùng tên riêng, để bảng không lỗi thời khi nhân sự thay đổi). Ví dụ: Product Manager, Engineering Manager, Designer, Legal, CEO.
Bước 3 — Điền R, A, C, I vào từng ô. Đi qua từng hàng, tự hỏi: ai làm (R), ai duyệt và gánh (A), ai cần hỏi trước (C), ai cần báo sau (I). Không phải ô nào cũng cần điền — nhiều ô sẽ để trống, và điều đó hoàn toàn ổn.
Bước 4 — Kiểm tra "luật một A". Rà từng hàng: mỗi hàng phải có đúng một chữ A. Không có A nào là lỗ hổng trách nhiệm; hai A trở lên là mâu thuẫn quyền lực. Đây là bước kiểm tra quan trọng nhất.
Bước 5 — Kiểm tra theo chiều dọc (theo người). Nhìn từng cột: nếu một người có quá nhiều chữ A, họ đang là nút thắt cổ chai (bottleneck) — cân nhắc phân quyền bớt. Nếu một người toàn chữ C, hỏi lại xem họ có thực sự cần được tham vấn không, hay chỉ đang làm chậm mọi thứ.
Bước 6 — Đối chiếu và cam kết. Chia sẻ bảng cho tất cả những người liên quan, thu thập phản hồi, giải quyết bất đồng. Quan trọng: RACI chỉ có giá trị khi mọi người đồng ý với vai trò của mình. Một bảng RACI đẹp mà không ai công nhận thì vô dụng.
Bước 7 — Sống cùng và điều chỉnh. RACI là tài liệu sống. Khi tổ chức thay đổi, khi có vai trò mới, hãy cập nhật. Đưa nó vào onboarding để người mới hiểu ngay cấu trúc quyền quyết định.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhiều hơn một A trên một hàng. Đây là lỗi phổ biến và nguy hiểm nhất. Nó thường xảy ra vì người ta ngại "phật lòng" ai đó nên trao A cho cả hai. Hãy dũng cảm chọn một người duy nhất.
Lỗi 2 — Lạm dụng chữ C. Khi mọi người đều muốn được tham vấn về mọi thứ, quy trình sẽ tê liệt vì phải chờ quá nhiều ý kiến. Mẹo: chỉ đặt C khi thiếu input của người đó thì quyết định sẽ sai lệch nghiêm trọng. Nếu chỉ là "cho họ biết cũng tốt" thì đó là I, không phải C.
Lỗi 3 — Nhầm C thành A. Người được tham vấn hay tưởng mình có quyền phủ quyết. Hãy làm rõ: C đưa input, nhưng A mới là người quyết. C không có quyền veto (trừ khi được quy định rõ, ví dụ Legal có thể có quyền chặn vì lý do pháp lý).
Lỗi 4 — RACI treo tường rồi quên. Nhiều nhóm làm RACI trong một workshop rồi cất vào ngăn kéo. Mẹo: gắn RACI vào công cụ làm việc hằng ngày (Notion, Confluence), và tham chiếu nó khi có tranh cãi về trách nhiệm.
Lỗi 5 — Điền tên riêng thay vì vai trò. Khi nhân sự nghỉ việc hoặc chuyển vị trí, bảng lỗi thời ngay. Dùng chức danh/vai trò để bảng bền vững hơn.
Mẹo nâng cao: Nếu RACI cổ điển gây tranh cãi vì có quá nhiều C làm chậm mọi thứ, hãy tìm hiểu biến thể RAPID (của Bain) hoặc mô hình DACI — chúng tách bạch rõ hơn giữa người đề xuất, người quyết và người thực thi, phù hợp với các quyết định chiến lược phức tạp.
Bài tập thực hành
Hãy chọn một quy trình có thật đang gây rối trong công việc của bạn — ví dụ "duyệt và xuất bản một bài blog", "phê duyệt chi phí trên 10 triệu đồng", hoặc "release một tính năng mới lên production".
- Vẽ một bảng RACI với ít nhất 5 hàng (công việc/quyết định) và 4 cột (vai trò).
- Điền đầy đủ R, A, C, I. Đảm bảo mỗi hàng có đúng một A.
- Kiểm tra chiều dọc: có ai đang giữ quá nhiều A không? Nếu có, thử phân bổ lại và ghi chú vì sao.
- Xác định một hàng mà bạn không chắc ai nên là A. Viết ra hai phương án và lập luận cho mỗi phương án — đây chính là "khoảng trống trách nhiệm" quý giá cần đưa ra thảo luận với đội.
- (Nâng cao) Với quy trình xử lý sự cố, hãy tạo hai phiên bản RACI: một cho "tình huống bình thường" và một cho "tình huống khẩn cấp", và giải thích vì sao chúng khác nhau.
Tóm tắt
RACI Matrix là công cụ đơn giản để biến sự mơ hồ về trách nhiệm — thứ âm thầm bào mòn tốc độ của mọi tổ chức đang scale — thành sự rõ ràng có thể nhìn thấy trên một bảng. Hãy ghi nhớ những điểm cốt lõi:
- R (Responsible) là người làm, có thể nhiều người. A (Accountable) là người duyệt và gánh trách nhiệm cuối, chỉ đúng một người. C (Consulted) đưa input hai chiều trước khi quyết. I (Informed) được báo một chiều sau khi quyết.
- Luật bất khả xâm phạm: mỗi công việc chỉ có một A. Không có A là lỗ hổng; hai A là xung đột.
- RACI không chỉ chia việc, nó định nghĩa quyền quyết định (decision rights) — bản đồ quyền lực minh bạch của tổ chức.
- Giá trị lớn nhất thường nằm ở cuộc trò chuyện để tạo ra bảng, nơi những khoảng trống và mâu thuẫn trách nhiệm ngầm bị phơi bày.
- RACI là tài liệu sống, cần cập nhật theo tổ chức và có thể thay đổi theo ngữ cảnh (bình thường vs khẩn cấp).