INFOCHIEF ACADEMY · COBIT 5 KNOWLEDGE SERIES
Xây dựng ma trận trách nhiệm RACI cho các quy trình quản trị IT.
RACI cần được xây từ đầu ra, quyền và điểm giao nhận. Tách hoạt động đủ rõ, tùy chỉnh vai trò và thử bằng một quyết định khó giúp ma trận trở thành công cụ làm việc thay vì danh sách tên trong các ô.
Biên soạn: Infochief Academy · Chuyên đề: Quản trị IT theo COBIT 5
Một ma trận RACI có thể phủ kín tên các bộ phận mà vẫn không trả lời được ai quyết định khi họ bất đồng. Càng nhiều người được đánh dấu tham gia, trách nhiệm càng dễ bị hiểu là trách nhiệm chung. Khi công việc chậm, mỗi bên đều có thể nói mình chỉ chờ ý kiến của bên còn lại.
Xây RACI cho quản trị IT cần bắt đầu từ quyết định và đầu ra, sau đó mới đến chữ cái. Công cụ có ích khi người thực hiện biết mình phải tạo ra điều gì, người chịu trách nhiệm có quyền xác nhận, còn người tham vấn và nhận thông tin được đưa vào đúng thời điểm.
Chọn phạm vi đủ rõ để phân công
RACI là viết tắt của Responsible, Accountable, Consulted và Informed. Có thể hiểu lần lượt là người thực hiện, người chịu trách nhiệm giải trình, người được tham vấn và người cần được thông báo. Các vai trò này mô tả quan hệ với một hoạt động, không phải thứ bậc cố định giữa các chức danh.
Vấn đề đầu tiên là kích thước của dòng công việc. Một dòng như “quản trị đầu tư IT” chứa nhiều nội dung: xác lập ưu tiên, đánh giá phương án, phân bổ vốn, triển khai và kiểm chứng lợi ích. Gán RACI cho cả dòng thường làm nhiều người cùng mang A mà không biết họ chịu trách nhiệm về phần nào.
Nên tách theo đầu ra và quyết định có thể xác nhận. Chẳng hạn, xác lập tiêu chí lựa chọn, chuẩn bị hồ sơ đề xuất, quyết định phân bổ nguồn lực và xác nhận kết quả lợi ích là những hoạt động khác nhau. Việc tách giúp giữ rõ tầng quản trị và tầng quản lý, thay vì gộp chúng trong một cụm từ.
Không cần phân rã mọi thao tác nhỏ. Ma trận ở cấp quản trị nên tập trung vào hoạt động có quyền hoặc giao nhận quan trọng. Những việc chi tiết có thể được tổ chức ở quy trình quản lý tương ứng. Nếu RACI quá dài, người dùng khó tìm trách nhiệm lúc cần và công cụ sẽ ít được sử dụng.
Dùng bảng COBIT làm tham khảo, rồi đối chiếu tổ chức
COBIT 5 có các bảng RACI tham khảo trong hướng dẫn quy trình. Vai trò được mô tả theo chức năng để tổ chức tùy chỉnh. Không nên sao chép tên vị trí rồi cho rằng doanh nghiệp đã có đủ chủ thể hoặc quyền tương ứng; cơ cấu thực tế có thể gộp vai trò hoặc phân quyền theo cách khác.
Trước khi lập bảng, cần đối chiếu điều lệ, quyền được giao và cơ chế quyết định của doanh nghiệp. Một ủy ban có thể chỉ tư vấn hoặc có thể được quyền quyết định trong phạm vi xác định. Việc đánh dấu A phải phản ánh quyền thật, không tạo quyền mới chỉ bằng một ma trận.
Cũng cần nhìn vai trò nghiệp vụ ngoài IT. Chủ quy trình xác nhận yêu cầu và kết quả công việc; chủ dữ liệu quyết định những nội dung thuộc dữ liệu; người quản lý dịch vụ tổ chức khả năng cung cấp. Nếu tất cả đều được giao cho CIO, trách nhiệm có thể vượt khả năng kiểm soát của một người.
Nền tảng trong chương trình COBIT 5 Foundation là hướng tham khảo để thống nhất cách đọc các vai trò. Việc tùy chỉnh vẫn cần cuộc thảo luận với những người sẽ thực hiện và sử dụng ma trận, để bảng phản ánh cách tổ chức có thể hoạt động.
Phân biệt làm việc, chịu trách nhiệm và được hỏi ý kiến
R là người hoặc nhóm thực hiện công việc tạo đầu ra. A chịu trách nhiệm giải trình về hoạt động đã xác định và cần có quyền phù hợp để xác nhận hoặc tổ chức hoàn tất. Người mang A có thể không trực tiếp làm mọi phần, nhưng không nên chỉ nhận thông tin sau khi việc đã xong.
C là người cần được tham vấn trước khi lựa chọn hoặc đầu ra được hoàn tất. Tham vấn là giao tiếp hai chiều có mục đích, không phải gửi tài liệu rộng rồi mặc định im lặng là đồng ý. Cần nêu nội dung hỏi và thời điểm phản hồi, nhất là khi ý kiến ảnh hưởng điều kiện triển khai.
I là người nhận thông tin phù hợp để biết kết quả hoặc chuẩn bị công việc liên quan. Thông báo không đồng nghĩa phê duyệt. Nếu người nhận thực tế có quyền dừng hoặc yêu cầu điều kiện, vai trò cần được mô tả lại, tránh ghi I nhưng chờ họ đồng ý trong mọi trường hợp.
Một cách thiết kế thường hữu ích là giữ một đầu mối A cho một hoạt động đã đủ rõ. Nếu có nhiều A, kiểm tra xem dòng đang chứa nhiều quyết định hay cần cơ chế quyết định tập thể được mô tả. Đây là lựa chọn thiết kế để làm rõ trách nhiệm, không phải lý do bỏ qua thẩm quyền của một cơ quan tập thể.
| Hoạt động trong ví dụ đề xuất | A theo quyền được giao | Các vai trò thực hiện và phối hợp |
|---|---|---|
| Chuẩn bị phương án đầu tư | Chủ đề xuất được chỉ định | R: nhóm chuẩn bị; C: nghiệp vụ, IT, tài chính; I: đầu mối danh mục |
| Quyết định phân bổ nguồn lực | Cấp có thẩm quyền của doanh nghiệp | R: đầu mối tổng hợp; C: chủ lợi ích và rủi ro; I: nhóm thực hiện |
| Xác nhận điều kiện triển khai | Người được giao quyền cho phép | R: nhóm triển khai; C: nghiệp vụ, vận hành, bảo mật; I: nhóm bị ảnh hưởng |
| Kiểm chứng lợi ích nghiệp vụ | Chủ kết quả được xác định | R: nhóm thu thập và phân tích; C: IT, tài chính; I: cấp giám sát |
Bảng chỉ minh họa cách tổ chức ma trận, không phải RACI chính thức của một quy trình COBIT. Doanh nghiệp phải thay vai trò bằng vị trí thực tế và xác nhận quyền trước khi dùng. Mỗi dòng cũng cần có đầu ra và căn cứ để người mang A biết họ xác nhận điều gì.
Năng lực phân công và điều phối có thể được phát triển qua chương trình Trưởng Phòng IT – IT Manager. Trong áp dụng, cần kiểm tra thời gian, nguồn lực và quyền yêu cầu phối hợp của người nhận trách nhiệm, vì chữ cái không tự tạo điều kiện thực hiện.
Thử ma trận bằng một ngoại lệ có thật
Tình huống giả định: dự án đã kiểm thử chức năng nhưng còn thiếu phương án đối soát khi chuyển dữ liệu. Nhóm dự án muốn giữ lịch, vận hành đề nghị hoãn, còn nghiệp vụ cho rằng cơ hội kinh doanh không thể chờ. Ma trận chỉ ghi “nghiệm thu và triển khai” với ba bộ phận cùng chịu trách nhiệm.
Khi thử trên tình huống, nhóm nhận ra dòng đó phải tách. Nghiệm thu chức năng xác nhận đáp ứng yêu cầu; cho phép triển khai xác nhận điều kiện sẵn sàng; chấp nhận thiếu hụt đối soát là lựa chọn rủi ro có tác động kinh doanh. Mỗi nội dung cần người có quyền và bằng chứng phù hợp.
Ma trận được sửa để người chuẩn bị phương án không tự chấp nhận rủi ro thay tổ chức. Vận hành và nghiệp vụ cung cấp ý kiến theo phạm vi, còn cấp có thẩm quyền chọn hoãn, thu hẹp hoặc triển khai với điều kiện. Quyết định phải ghi cách theo dõi thiếu hụt và ngưỡng cần trình lại.
Năng lực kiểm soát giao nhận và các quyết định triển khai có thể được tham khảo qua chương trình Quản lý Dự án IT. Điều quan trọng là thiết kế trách nhiệm trước thời điểm khẩn cấp, để người thực hiện không phải đoán quyền trong lúc các lựa chọn đang thu hẹp.
Giữ tham vấn đủ rộng nhưng có giới hạn
Một sai lầm phổ biến là thêm mọi bộ phận vào C để tránh bị cho là bỏ sót. Kết quả có thể là đầu ra chờ nhiều ý kiến không ảnh hưởng lựa chọn. Cần xác định người được hỏi vì họ sở hữu thông tin, chịu tác động hoặc có trách nhiệm chuyên môn thực sự liên quan.
Với từng C, ghi nội dung cần phản hồi. Nhóm bảo mật có thể đánh giá điều kiện bảo vệ; chủ nghiệp vụ xác nhận khả năng làm việc; vận hành xác nhận khả năng duy trì. Không nên yêu cầu mọi người phê duyệt toàn bộ tài liệu nếu họ chỉ đủ căn cứ cho một phần.
Thời hạn tham vấn và đường xử lý khi thiếu ý kiến cần được thống nhất theo rủi ro. Im lặng không nên tự trở thành sự chấp nhận cho các nội dung trọng yếu. Khi chưa có ý kiến cần thiết, người mang A phải biết có thể yêu cầu bổ sung, đổi phạm vi hoặc trình lựa chọn nào.
Phần thông báo cũng cần chọn thời điểm. Một nhóm hỗ trợ được báo sau triển khai sẽ không kịp chuẩn bị, dù họ được ghi I đúng về tên vai trò. Vì vậy, RACI nên được nối với luồng công việc và thời điểm giao nhận, không chỉ tồn tại như phụ lục cuối tài liệu.
Duy trì RACI cùng quyền và nhân sự
Ma trận cần được rà khi cơ cấu, dịch vụ hoặc cách thuê ngoài thay đổi. Thay tên người không đủ nếu công việc và quyền đã đổi. Nhà cung cấp có thể thực hiện hoạt động, nhưng doanh nghiệp vẫn cần người sở hữu để xác nhận kết quả và những lựa chọn thuộc trách nhiệm của mình.
Khi một người kiêm nhiều vai trò, cần xem khả năng và yêu cầu phân tách nhiệm vụ. Việc gộp có thể phù hợp trong tổ chức nhỏ, nhưng các quyết định quan trọng vẫn cần cơ chế kiểm tra tương xứng. Không nên tạo danh sách chức danh giả để bảng trông giống mô hình tham khảo.
Ở cấp lãnh đạo, RACI cần giúp nhìn quyền đang thiếu, trách nhiệm đang chồng và điểm giao nhận đang chậm. Góc nhìn trong chương trình Lãnh đạo IT – CIO là hướng tham khảo để phát triển khả năng tổ chức các quyết định này trong cơ chế quản trị chung.
Bước bắt đầu phù hợp là chọn vài hoạt động đang gây bất đồng và kiểm tra bằng quyết định gần đây. Khi bảng cho biết ai làm, ai chịu trách nhiệm, ai được hỏi và ai phải biết đúng lúc, RACI đã trở thành công cụ làm việc. Nếu chưa, cần sửa nội dung và quyền trước khi bổ sung thêm tên vào các ô.