INFOCHIEF ACADEMY · IT PROJECT MANAGEMENT KNOWLEDGE SERIES
Thiết lập RACI cho nhóm dự án IT và các bên liên quan.
RACI làm rõ ai thực hiện, ai chịu trách nhiệm cuối cùng, ai cần được tham vấn và thông báo. Thiết kế theo điểm bàn giao, kiểm tra quyền và thời gian giúp bảng phân vai phục vụ phối hợp thực tế.
Biên soạn: Infochief Academy · Chuyên đề: Quản lý dự án IT
Khi dữ liệu kiểm thử chưa được phê duyệt, người quản lý dự án thường thấy nhiều người tham gia nhưng không thấy ai có thể chốt. Trong một tình huống giả định, chuyên viên nghiệp vụ đã chuẩn bị dữ liệu, trưởng nhóm IT đã kiểm tra định dạng, còn đội kiểm thử đang chờ xác nhận. Ai cũng đã làm phần mình hiểu là cần làm. Điểm bàn giao vẫn tắc vì trách nhiệm cuối cùng chưa được thống nhất.
RACI là công cụ phân định người thực hiện, người chịu trách nhiệm cuối cùng, người được tham vấn và người cần được thông báo. Bảng có ích khi làm rõ những điểm giao việc và quyết định dễ mơ hồ. Nó không tự trao quyền, không chứng minh người được ghi tên có thời gian, và không thay thế quy trình phê duyệt của doanh nghiệp.
Xác định điều cần phân vai trước khi điền tên người
Một bảng bắt đầu bằng danh sách phòng ban rồi điền chữ vào từng ô thường khó giải quyết vấn đề thật. Nên bắt đầu từ các sản phẩm, công việc hoặc quyết định quan trọng: chốt yêu cầu, xác nhận dữ liệu, nghiệm thu, cho phép triển khai và tiếp nhận hỗ trợ. Mỗi dòng cần đủ cụ thể để biết khi nào trách nhiệm bắt đầu và kết thúc.
Dòng “quản lý dự án” quá rộng vì chứa nhiều nhiệm vụ và quyền khác nhau. Có thể tách việc cập nhật kế hoạch khỏi việc phê duyệt thay đổi ngân sách. Tương tự, “kiểm thử” có thể gồm chuẩn bị dữ liệu, thực hiện kịch bản và xác nhận kết quả nghiệp vụ. Nếu nhiều người chịu trách nhiệm cuối cùng vì dòng chứa nhiều quyết định, nên xem lại cách chia trước khi tranh luận về chữ A.
Các điểm bàn giao giữa IT, nghiệp vụ và đối tác thường đáng ưu tiên. Người gửi sản phẩm cần biết ai nhận, còn người nhận cần biết điều kiện nào phải kiểm tra. Một RACI ở cấp vừa đủ sẽ làm rõ những điểm này mà không phải mô tả từng thao tác. Phần công việc chi tiết vẫn có thể quản lý trong kế hoạch nhóm.
Năng lực tổ chức công việc trong chương trình Quản Lý Dự Án IT giúp chọn dòng phù hợp. Trước khi điền vai trò, đội nên trả lời được: dòng này mô tả một kết quả hay quyết định nào và bằng chứng nào cho thấy nó đã hoàn tất?
Thống nhất ý nghĩa của bốn vai trò trong bối cảnh doanh nghiệp
Responsible, ký hiệu R, là người thực hiện công việc. Accountable, ký hiệu A, là người chịu trách nhiệm cuối cùng cho kết quả hoặc quyết định của dòng theo quyền được thống nhất. Consulted, ký hiệu C, là người được hỏi ý kiến cần thiết trước khi thực hiện hoặc chốt. Informed, ký hiệu I, là người nhận thông tin phù hợp để phối hợp hoặc biết kết quả.
Vai trò A cần có khả năng bảo đảm việc được hoàn tất và quyền phù hợp với loại quyết định. Nếu người chịu trách nhiệm cuối cùng không có quyền xử lý vướng mắc, bảng đang đặt trách nhiệm vượt khả năng. Ngược lại, người có quyền mà không được xác định ở dòng cần quyết định sẽ khiến công việc phải đi vòng ngoài bảng. Cần đối chiếu với cơ chế ủy quyền thực tế.
Một người có thể đồng thời R và A nếu công việc, quy mô và cơ chế kiểm soát cho phép. Một dòng cũng có thể có nhiều R, nhưng cần đủ rõ ai phối hợp và ai giao sản phẩm. Đối với A, quy ước một đầu mối cuối cùng cho một dòng thường giúp giảm mơ hồ. Đây là nguyên tắc thiết kế thực hành, không phải lý do bỏ qua trường hợp doanh nghiệp có phê duyệt nhiều bước.
Nếu một quyết định cần nhiều chữ ký theo quy định, có thể tách các bước hoặc dùng bảng quyền phê duyệt đi kèm. Không nên ép mọi nghĩa vụ vào một ô RACI rồi cho rằng đã đủ. Năng lực phân quyền trong chương trình Giám Đốc Dự Án IT giúp giữ sự nhất quán giữa trách nhiệm trên bảng và quyết định được phép thực hiện.
Đi qua tình huống thật để thương lượng trách nhiệm
Việc phân vai nên được thảo luận với người được giao. Người quản lý có thể đưa bản đề xuất, sau đó thử bằng tình huống dữ liệu không đạt, yêu cầu thay đổi hoặc lịch triển khai bị xung đột. Câu hỏi không chỉ là ai sẽ làm, mà còn ai cung cấp đầu vào, ai xác nhận kết quả và ai xử lý nếu không thể đạt điều kiện.
Bảng sau là ví dụ giả định, trình bày gọn vai trò R và A cho một số điểm bàn giao của dự án IT. C và I được làm rõ trong phần mô tả để giữ bảng dễ đọc; khi áp dụng, doanh nghiệp có thể dùng ma trận đầy đủ theo vai trò.
| Công việc hoặc quyết định | R: thực hiện | A: chịu trách nhiệm cuối cùng |
|---|---|---|
| Chuẩn bị dữ liệu kiểm thử | Chuyên viên nghiệp vụ được giao | Chủ sở hữu dữ liệu nghiệp vụ |
| Kiểm tra định dạng dữ liệu | Chuyên gia tích hợp | Trưởng nhóm kỹ thuật phụ trách |
| Xác nhận kết quả nghiệp vụ | Nhóm người dùng kiểm tra | Chủ quy trình có thẩm quyền |
| Cập nhật kế hoạch dự án | Người điều phối kế hoạch | Project Manager trong quyền được giao |
Với dòng chuẩn bị dữ liệu, đội kiểm thử và an toàn thông tin có thể là C tùy nội dung dữ liệu; các nhóm cần biết ngày sẵn sàng có thể là I. Phải xác định lý do tham vấn, nội dung cần trả lời và hạn phản hồi. Ghi C cho mọi bên sẽ tạo nhu cầu chờ lớn mà không tăng chất lượng quyết định tương ứng.
Ví dụ cũng cho thấy dữ liệu được xác nhận về nghiệp vụ khác với dữ liệu đúng định dạng. Nếu gộp cả hai vào một dòng, hai đầu mối có thể hiểu mình chỉ chịu trách nhiệm một phần. Tách bước giúp rõ điều kiện giao nhận và tránh việc đội IT bị mặc định chịu trách nhiệm về nghĩa dữ liệu mà họ không có quyền xác nhận.
Sau khi thống nhất, các vai trò nên được gắn với cá nhân hoặc đầu mối cụ thể cho dự án. Dùng vai trò giúp bảng bền hơn khi nhân sự thay đổi, nhưng đội vẫn phải biết hiện ai đang giữ vai trò. Người thay thế và thời điểm chuyển trách nhiệm cũng cần được xác nhận.
Kiểm tra quá tải, khoảng trống và những chữ C không cần thiết
Có thể đọc từng dòng để tìm việc không có R, không có A hoặc có ranh giới hoàn tất mơ hồ. Sau đó đọc từng cột để xem người nào nhận quá nhiều trách nhiệm. Một bảng đầy đủ về hình thức vẫn có thể không khả thi nếu một trưởng bộ phận phải chốt mọi việc nhỏ trong nhiều dự án. Cần điều chỉnh mức phân quyền hoặc phần công việc được giao.
Cam kết thời gian nên được xác nhận với người quản lý trực tiếp. Một chuyên gia được ghi R nhưng chỉ có thể tham gia sau mốc cần thiết sẽ không làm công việc sẵn sàng. Điều này đòi hỏi phối hợp với Trưởng Phòng IT – IT Manager và lãnh đạo nghiệp vụ tương ứng. RACI mô tả vai trò; kế hoạch nguồn lực chứng minh khả năng thực hiện vai trò ấy.
Cần xem lại những dòng có quá nhiều C. Không phải ai quan tâm cũng phải được tham vấn trước quyết định. Một số bên chỉ cần biết kết quả, một số chỉ cần ý kiến ở trường hợp có ảnh hưởng đặc biệt. Khi xác định đúng mục đích, dự án có thể giữ đối thoại cần thiết mà giảm thời gian chờ. Những nghĩa vụ kiểm soát bắt buộc vẫn phải được bảo đảm.
Vai trò I cũng cần nhịp và kênh phù hợp. Thông báo mọi thay đổi nhỏ cho mọi người dễ làm thông tin quan trọng chìm đi. Có thể xác định nội dung nào gửi ngay, nội dung nào tổng hợp theo kỳ và ai cần biết trước khi bắt đầu việc liên quan. Bảng phân vai trở nên hữu ích hơn khi đi cùng quy ước phối hợp ngắn gọn.
Đặt RACI cạnh cơ chế quyết định và tiếp nhận vận hành
RACI không phải bảng ủy quyền ngân sách và cũng không phải trình tự giải quyết mọi tranh chấp. Cần ghi nơi tham chiếu quyền quyết định, dung sai được giao và đường trình lên khi vượt giới hạn. Người quản lý dự án có thể là A cho việc cập nhật kế hoạch nhưng không mặc nhiên là người phê duyệt tăng chi phí. Việc tách rõ tránh nhầm trách nhiệm điều phối với quyền chấp nhận sự đánh đổi.
Ở giai đoạn chuyển giao, trách nhiệm cần thay đổi theo trạng thái sản phẩm. Trước triển khai, đội dự án có thể xử lý cấu hình; sau tiếp nhận, đội vận hành cần sở hữu hoạt động hỗ trợ phù hợp. Phần tồn đọng có thể còn trách nhiệm riêng của nhà cung cấp. Cần chỉ rõ thời điểm chuyển và điều kiện để tránh một khoảng không có người nhận.
Tư duy của Quản Lý Dịch Vụ IT – ITSM giúp phân định những trách nhiệm này. Một buổi bàn giao tài liệu chưa đủ nếu người tiếp nhận chưa có quyền truy cập hoặc chưa biết xử lý sự cố. RACI cần phản ánh ai thực hiện việc tiếp nhận và ai xác nhận năng lực vận hành đã sẵn sàng.
Dùng bảng trong công việc và cập nhật khi cách phối hợp thay đổi
Khi công việc bị kẹt, hãy dùng RACI để xác định đầu mối cần tham gia, sau đó hỏi điều kiện nào còn thiếu. Không nên dùng bảng chỉ để chứng minh một cá nhân có lỗi. Một lần chậm có thể cho thấy dòng quá rộng, quyền chưa đủ hoặc đầu vào chưa được giao. Việc sửa cơ chế cần đi cùng xử lý công việc hiện tại.
Những thay đổi phạm vi, tổ chức hoặc đối tác có thể làm bảng cũ không còn phù hợp. Người quản lý cần cập nhật có kiểm soát, xác nhận với các bên bị ảnh hưởng và thông báo phiên bản đang dùng. Bảng cũng nên được rà tại các điểm chuyển giai đoạn quan trọng. Không cần sửa vì mỗi nhiệm vụ nhỏ, nhưng phải sửa khi trách nhiệm thực tế thay đổi.
Với tình huống dữ liệu ở mở bài, hành động đầu tiên là tách xác nhận nghĩa nghiệp vụ khỏi kiểm tra định dạng, rồi giao người có quyền cho từng phần. Hãy thử quy trình giao nhận trên một tập dữ liệu thật trước khi nhân rộng. RACI phát huy giá trị khi đội biết ai phải làm, ai phải chốt và điều gì phải có để chuyển việc, chứ không phải khi mọi ô đều đã được điền chữ.