INFOCHIEF ACADEMY · IT MANAGER KNOWLEDGE SERIES

Áp dụng RACI để giải quyết tình trạng chồng chéo trách nhiệm trong bộ phận IT.

RACI thường bị biến thành một bảng màu đẹp trong tài liệu nhưng ít thay đổi cách làm việc. Nguyên nhân là nhiều tổ chức điền tên vào ma trận trước khi làm rõ quy trình, quyết định và outcome. Khi dùng đúng, RACI không chỉ phân công người làm; nó tạo ngôn ngữ chung để xử lý vùng xám trách nhiệm, escalation và phối hợp liên phòng ban.

Biên soạn: Infochief Academy · Chuyên đề: Trưởng Phòng IT Chuyên Nghiệp – IT Manager

← Trở về danh mục IT Manager

Minh họa biên tập: Ma trận RACI thể hiện Responsible Accountable Consulted Informed cho trách nhiệm trong bộ phận IT.

RACI không giải quyết mọi vấn đề trách nhiệm, nhưng giải quyết tốt vùng giao nhau

Một bộ phận IT thường có nhiều công việc xuyên chức năng: thay đổi hệ thống cần ứng dụng, hạ tầng, bảo mật và business owner; sự cố lớn cần Service Desk, technical team, vendor và quản lý; dự án mới cần project, architecture, operations và người dùng. Chồng chéo thường xuất hiện không phải vì mọi người thiếu thiện chí mà vì mỗi bên hiểu khác nhau về “chịu trách nhiệm”.

RACI là một dạng Responsibility Assignment Matrix. Nó giúp gắn hoạt động hoặc deliverable với bốn vai trò: Responsible, Accountable, Consulted và Informed. PMI cũng mô tả RACI như công cụ để thể hiện mức tham gia của stakeholder đối với hoạt động. Trong môi trường IT, RACI hữu ích nhất ở điểm giao giữa các team hoặc giữa IT và business.

RACI không thay thế quy trình, JD hay governance. Nếu quy trình chưa rõ hoặc decision point chưa xác định, ma trận chỉ ghi lại sự mơ hồ bằng bốn chữ cái. Vì vậy IT Manager cần dùng RACI sau khi đã hiểu workflow và outcome.

Hiểu đúng Responsible, Accountable, Consulted và Informed

Ký hiệu	Ý nghĩa quản lý	Câu hỏi kiểm tra
R – Responsible	người trực tiếp thực hiện hoặc điều phối để tạo đầu ra	Ai làm công việc?
A – Accountable	người chịu trách nhiệm cuối cùng cho kết quả/quyết định	Ai trả lời nếu kết quả không đạt?
C – Consulted	người cần được tham vấn trước quyết định hoặc thực hiện	Ai có kiến thức/quyền lợi phải tham gia hai chiều?
I – Informed	người cần được thông báo để phối hợp hoặc nhận biết	Ai cần biết nhưng không cần tham gia quyết định?

Một nguyên tắc thực hành hữu ích là cố gắng có một A cho mỗi dòng. Nếu có ba người Accountable, thực tế thường không ai thực sự accountable. Có thể có nhiều R khi công việc cần phối hợp, nhưng nên xác định R chính hoặc role điều phối nếu dễ xảy ra đùn đẩy.

Khi nào IT Manager nên dùng RACI – và khi nào không nên

RACI đặc biệt hữu ích cho quy trình có nhiều handoff, quyết định có rủi ro hoặc hoạt động liên phòng ban. Ví dụ: change management, incident major, access approval, backup restore, onboarding/offboarding, procurement, project handover và vendor escalation. Đây là nơi một câu “tưởng bên kia làm” có thể gây hậu quả.

Không cần RACI cho mọi task nhỏ. Nếu một team vận hành hằng ngày có ownership rõ, việc tạo ma trận cho từng bước sẽ làm tăng hành chính. IT Manager nên ưu tiên các điểm có dấu hiệu: công việc bị chậm vì chờ phê duyệt, hai nhóm cùng nghĩ mình có quyền quyết định, nhiều người bị CC nhưng không ai ra quyết định, hoặc sự cố lặp lại do handoff.

Trong quản lý dự án hoặc thay đổi lớn, RACI nên liên kết với cơ chế quản trị dự án của Giám Đốc Dự Án IT – Project Manager và với service ownership trong Quản Lý Dịch Vụ IT – ITSM.

Sáu bước xây RACI có thể sử dụng trong vận hành thật

Chọn phạm vi cụ thể: một quy trình, quyết định hoặc deliverable có vấn đề; tránh xây RACI cho “toàn bộ IT” ngay từ đầu.
Vẽ workflow hiện tại: xác định các bước, handoff, decision point và output.
Liệt kê role thay vì tên người: ví dụ Service Owner, Security Manager, Application Lead; như vậy ma trận bền hơn khi nhân sự thay đổi.
Gán A trước, rồi R: xác định ai chịu trách nhiệm cuối cùng, sau đó ai thực hiện.
Kiểm tra C và I: quá nhiều C làm chậm quyết định; quá nhiều I tạo nhiễu thông tin.
Chạy thử bằng tình huống thật: dùng một sự cố hoặc change gần đây để kiểm tra ma trận có phản ánh cách tổ chức cần vận hành hay không.

Sau workshop, RACI cần được tích hợp vào SOP, ticket workflow, approval flow hoặc agenda review. Nếu ma trận chỉ nằm trong Excel, hành vi cũ sẽ quay lại. Với đội ngũ tuyến đầu, Quản Lý Giám Sát IT – IT Supervisor có thể giúp chuẩn hóa cách giao việc, theo dõi và escalation để RACI trở thành thói quen vận hành.

Mẫu RACI tham khảo cho một số hoạt động IT

Hoạt động	Service Owner	Technical Lead	Security	IT Manager	Business Owner
Phê duyệt change rủi ro cao	R	C	C	A	I
Điều phối major incident	A	R	C	I	I
Cấp quyền đặc biệt	C	R	A	I	C
Chấp nhận rủi ro vận hành	C	C	C	A	C
Xác nhận yêu cầu nghiệp vụ	C	C	I	I	A

Đây chỉ là ví dụ minh họa, không phải ma trận chuẩn. Mỗi doanh nghiệp phải điều chỉnh theo governance và quyền hạn thực tế. Điểm quan trọng là phân biệt phê duyệt kỹ thuật, phê duyệt rủi ro và phê duyệt nghiệp vụ – ba loại trách nhiệm thường bị gộp chung.

Khi RACI chạm đến cấp điều hành hoặc quyết định đầu tư, cần bảo đảm phù hợp với governance tổng thể. ISO/IEC 38500 nhấn mạnh trách nhiệm và cơ chế ra quyết định ở cấp quản trị; COBIT cũng cung cấp khung để phân biệt governance và management.

Tình huống minh họa: change thất bại và bốn nhóm đều nói “không phải bên tôi phê duyệt”

Tình huống giả định: một thay đổi cấu hình database gây gián đoạn ứng dụng. Application team nói DBA đã phê duyệt kỹ thuật; DBA nói Change Coordinator đã cho phép triển khai; Security cho rằng không được tham vấn; business owner không biết change diễn ra trong giờ cao điểm.

IT Manager không giải quyết bằng cách tìm “ai sai”, mà phân rã quyết định: ai xác nhận phương án kỹ thuật, ai xác nhận security impact, ai phê duyệt cửa sổ thay đổi theo tác động kinh doanh, ai có quyền go/no-go. RACI mới được xây quanh các decision point này, sau đó được tích hợp vào change template.

Trong lần change tiếp theo, nhóm không cần thêm nhiều cuộc họp; ngược lại, thời gian giảm vì mọi người biết khi nào cần được Consulted và ai là Accountable. Đây là lợi ích thực của RACI: giảm mơ hồ, không tăng hành chính.

RACI và decision rights: đừng nhầm người chịu trách nhiệm với người có quyền quyết định

Trong thực tế, nhiều xung đột xuất phát từ việc Accountable được gán cho một role nhưng role đó không có authority thực tế. Ví dụ Service Owner bị ghi A cho SLA nhưng không có quyền ưu tiên capacity của technical team. Khi đó RACI tạo cảm giác rõ ràng trên giấy nhưng không thể thực thi. IT Manager phải kiểm tra quyền, ngân sách và quyền escalated đi kèm accountability.

Nếu một quyết định bắt buộc phải qua committee, hãy thể hiện cơ chế đó rõ hơn thay vì cố ép vào một chữ A. RACI là bản đồ trách nhiệm, không phải mô hình governance hoàn chỉnh. Những quyết định lớn có thể cần decision matrix, approval threshold hoặc charter bổ sung.

Checklist review RACI trước khi áp dụng

Mỗi dòng có outcome hoặc decision point đủ cụ thể.
Mỗi dòng có một A rõ ràng hoặc giải thích hợp lý nếu cấu trúc đặc biệt.
Không gán A cho người không có quyền thực tế.
Số lượng C được giới hạn ở những vai trò thực sự cần tham vấn.
RACI dùng role, không phụ thuộc tên cá nhân.
Ma trận đã được kiểm tra bằng một tình huống thực tế.
SOP, workflow, ticket hoặc approval form đã phản ánh RACI.
Có lịch review khi cơ cấu, nhà cung cấp hoặc quy trình thay đổi.

Nếu ma trận trở nên quá rộng, hãy tách theo quy trình hoặc dịch vụ. Một RACI 15 dòng dùng hằng ngày tốt hơn một ma trận 200 dòng không ai mở.

Để RACI duy trì giá trị sau khi ban hành, IT Manager nên đưa ma trận vào nhịp review vận hành. Khi một vai trò đổi, nhà cung cấp thay đổi hoặc quy trình được tự động hóa, trách nhiệm cũng có thể dịch chuyển. Mỗi lần xảy ra sự cố do hiểu sai trách nhiệm là một tín hiệu cần cập nhật. Cách tiếp cận này biến RACI thành tài liệu sống, phản ánh cách tổ chức thực sự ra quyết định thay vì một bảng phân công chỉ được mở khi audit hoặc dự án yêu cầu.

Kết luận: RACI là công cụ làm rõ quyền và trách nhiệm, không phải bài tập điền bảng

RACI tạo giá trị khi nó làm cho quyết định và phối hợp nhanh hơn. IT Manager nên bắt đầu từ những vùng xám gây hậu quả rõ nhất, gán accountability cho outcome và biến ma trận thành một phần của cách làm việc thực tế.

Bước đầu tiên có thể rất nhỏ: chọn một quy trình đang có nhiều tranh luận, tổ chức workshop 60–90 phút để xác định decision point và bốn vai trò. Nếu sau workshop số câu hỏi “ai chịu trách nhiệm?” giảm, RACI đã đi đúng hướng.

Nguồn tham khảo

Các nguồn trên được dùng để tham khảo nguyên tắc quản trị, quản lý dịch vụ, trách nhiệm và tổ chức công việc. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy.