INFOCHIEF ACADEMY · COBIT 5 KNOWLEDGE SERIES
Phân định trách nhiệm quản trị và quản lý IT theo mô hình COBIT 5.
Trách nhiệm cần gắn với nội dung quyết định và quyền thực tế. Tách các loại phê duyệt, tùy chỉnh vai trò và thiết lập đường chuyển cấp giúp mô hình COBIT 5 trở thành cơ chế phối hợp có thể sử dụng.
Biên soạn: Infochief Academy · Chuyên đề: Quản trị IT theo COBIT 5
Khi một dự án gây gián đoạn kinh doanh, câu hỏi “ai chịu trách nhiệm?” thường xuất hiện muộn hơn câu hỏi “ai đã phê duyệt?”. Hai câu hỏi ấy không luôn dẫn đến cùng một người. Người ký có thể chỉ duyệt chi phí, trong khi không ai được xác định là người chấp nhận rủi ro vận hành.
Phân định trách nhiệm theo COBIT 5 cần bắt đầu từ loại quyết định và tác động của nó. Nếu chỉ đưa tên chức danh vào một ma trận, doanh nghiệp có thể tạo cảm giác rõ ràng trên giấy mà vẫn thiếu quyền hành động ở thực tế. Cần nối trách nhiệm với quyền, bằng chứng và cách chuyển cấp để quyết định được đưa ra đúng nơi.
Tách những việc đang bị gọi chung là phê duyệt
Một đề xuất công nghệ có thể chứa nhiều quyết định: lựa chọn ưu tiên kinh doanh, chấp nhận ngân sách, xác nhận thiết kế, cho phép triển khai và tiếp nhận sản phẩm vận hành. Gộp tất cả thành một ô “phê duyệt dự án” khiến các bên khó biết họ đang chịu trách nhiệm cho nội dung nào.
Trong COBIT 5, quản trị và quản lý là hai khu vực trách nhiệm khác nhau. EDM phục vụ đánh giá, chỉ đạo và giám sát ở tầng quản trị; các miền quản lý tổ chức hoạt động theo định hướng đó. Phân biệt này giúp tách quyền xác lập lựa chọn doanh nghiệp khỏi quyền điều hành công việc trong phạm vi đã giao.
Tuy nhiên, không thể lấy tên miền quy trình rồi mặc định một chức danh luôn quyết định mọi việc trong miền đó. Cơ cấu, điều lệ, quyền được ủy nhiệm và mức tác động của doanh nghiệp cần được xem xét. Một ủy ban được giao rà soát không nhất thiết có quyền chấp nhận mọi ngoại lệ.
Cách làm thiết thực là viết quyết định bằng động từ và đối tượng rõ: chấp nhận mức gián đoạn tối đa cho dịch vụ, phân bổ nguồn lực cho sáng kiến, xác nhận điều kiện kiểm thử hoặc cho phép chuyển đổi. Khi nội dung đã cụ thể, việc gán trách nhiệm mới có căn cứ.
Đưa đúng chủ thể vào từng tầng trách nhiệm
Ở tầng quản trị, cơ quan quản trị cao nhất giữ trách nhiệm định hướng và giám sát phù hợp với cơ chế của tổ chức. Các ủy ban hỗ trợ cần có phạm vi công việc, thông tin nhận và quyền quyết định rõ. Việc ủy nhiệm không nên làm mất khả năng nhìn thấy các vấn đề quan trọng ở cấp chịu trách nhiệm cuối cùng.
Ban điều hành tổ chức thực hiện định hướng và xử lý các lựa chọn trong thẩm quyền. CIO đóng vai trò kết nối công nghệ với nhu cầu, tổng hợp phương án và tổ chức năng lực cung cấp. Chủ nghiệp vụ xác nhận kết quả công việc và những thay đổi cần thiết để lợi ích được thực hiện.
Các nhóm kỹ thuật, vận hành và dự án chịu trách nhiệm cho phần việc được giao, nhưng không thể tự chấp nhận mọi tác động doanh nghiệp. Một kỹ sư có thể đánh giá phương án khôi phục; việc chọn tiếp tục một hoạt động có rủi ro đáng kể cần người có thẩm quyền và hiểu hệ quả kinh doanh tham gia.
Người lãnh đạo IT cần biết khi nào mình quyết định, khi nào đề xuất và khi nào phải yêu cầu chủ nghiệp vụ cùng chịu trách nhiệm. Chương trình Lãnh đạo IT – CIO là hướng tham khảo để phát triển năng lực đối thoại và tổ chức trách nhiệm ở tầng này.
Đừng bỏ qua người sở hữu dữ liệu và người sử dụng dịch vụ. Nếu họ không được tham vấn khi thiết kế, quyết định kỹ thuật có thể làm thay đổi cách làm việc mà không ai chuẩn bị. Phân định trách nhiệm tốt phải phản ánh cả người chịu tác động, thay vì chỉ các chức danh thường tham gia cuộc họp IT.
Dùng RACI sau khi đã xác định quyền
RACI phân biệt 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. Đây là công cụ giúp làm rõ vai trò theo hoạt động. Bảng RACI tham khảo của COBIT 5 cần được tùy chỉnh theo các vị trí thực tế, không nên sao chép chức danh rồi coi như cơ chế đã hoàn thành.
Một lựa chọn thiết kế thường hữu ích là xác định một đầu mối chịu trách nhiệm giải trình cho mỗi hoạt động đã được chia đủ rõ. Nếu xuất hiện nhiều đầu mối mà không biết ai quyết định cuối cùng, có thể hoạt động đang gộp nhiều quyết định. Khi đó nên tách nội dung thay vì chỉ xóa bớt tên trong bảng.
| Quyết định cần phân định | Vai trò cần xác định | Bằng chứng trước khi quyết định |
|---|---|---|
| Chọn ưu tiên đầu tư | Cấp có quyền phân bổ nguồn lực | Mục tiêu, phương án và các phụ thuộc |
| Chấp nhận rủi ro còn lại | Người có thẩm quyền theo cơ chế rủi ro | Tác động, biện pháp và thời điểm xem lại |
| Cho phép triển khai | Đầu mối được giao quyền thay đổi | Kiểm thử, phương án phục hồi và điều kiện vận hành |
| Xác nhận lợi ích | Chủ kết quả nghiệp vụ | Dữ liệu nền, kết quả và yếu tố ảnh hưởng |
Bảng này là công cụ xác định nội dung trước khi lập RACI, không phải ma trận phân quyền chính thức của COBIT 5. Với từng dòng, doanh nghiệp bổ sung ai đề xuất, ai thực hiện, ai cần tham vấn và ai nhận thông tin. Sau đó đối chiếu quyền đã có để bảo đảm người nhận trách nhiệm có thể hành động.
Kỹ năng phân công và điều phối này có thể được tham khảo qua chương trình Trưởng Phòng IT – IT Manager. Ở nơi áp dụng, quản lý phải kiểm tra cả khả năng huy động nhân lực, tiếp cận dữ liệu và yêu cầu phối hợp, vì những quyền này quyết định trách nhiệm có khả thi hay không.
Một lần chuyển đổi cho thấy chỗ trống trong ma trận
Tình huống giả định: doanh nghiệp chuẩn bị chuyển hệ thống xử lý đơn hàng vào cuối tuần. Nhóm dự án ghi “Ban điều hành phê duyệt”, nhóm kỹ thuật ghi “IT xác nhận”, còn phòng kinh doanh hiểu rằng nghiệm thu chức năng nghĩa là đã cho phép triển khai. Khi phát hiện dữ liệu đối soát chưa đầy đủ, không ai biết ai có quyền hoãn.
Vấn đề không phải thiếu chữ ký. Các bên đang dùng cùng một từ cho những nội dung khác nhau. Nghiệm thu chức năng xác nhận sản phẩm đáp ứng yêu cầu; cho phép chuyển đổi xác nhận điều kiện triển khai; chấp nhận vận hành với thiếu hụt dữ liệu là quyết định về rủi ro. Ba nội dung cần được tách và nối với thẩm quyền tương ứng.
Doanh nghiệp có thể tổ chức một phiên rà sẵn sàng, trong đó mỗi chủ thể xác nhận phần bằng chứng của mình. Nhóm kỹ thuật trình kiểm thử và phương án phục hồi; vận hành trình khả năng hỗ trợ; nghiệp vụ trình đối soát và phương án làm việc. Người được giao quyền triển khai tổng hợp các điều kiện thay vì nhận những lời xác nhận không rõ phạm vi.
Nếu một điều kiện trọng yếu chưa đạt, người có thẩm quyền chọn hoãn, thu hẹp phạm vi hoặc chấp nhận ngoại lệ với biện pháp bổ sung. Quyết định cần ghi lý do, thời hạn, người theo dõi và ngưỡng dừng. Không nên để một thỏa thuận miệng khiến nhóm triển khai tự chịu trách nhiệm cho hệ quả đã vượt quyền của họ.
Phát triển năng lực giao nhận và kiểm soát triển khai là hướng có thể tham khảo qua chương trình Quản lý Dự án IT. Trong tình huống này, điều quan trọng là phân định rõ nghiệm thu, chuyển giao và cho phép triển khai ngay từ kế hoạch, thay vì đợi tới sát thời điểm chuyển đổi.
Chuyển cấp bằng tác động và thời hạn cần quyết định
Một cơ chế phân quyền chỉ có ích khi người thực hiện biết lúc nào phải chuyển cấp. Ngưỡng có thể dựa trên rủi ro, tác động dịch vụ, nghĩa vụ quan trọng hoặc thay đổi mục tiêu. Chi phí là một yếu tố, nhưng quyết định ít tốn tiền vẫn có thể ảnh hưởng nghiêm trọng đến hoạt động kinh doanh.
Khi trình chuyển cấp, cần nêu quyết định đang cần, thời hạn để lựa chọn còn có hiệu lực và hệ quả nếu chưa quyết định. Phần kỹ thuật nên đủ giải thích, không che câu hỏi chính dưới nhiều dữ liệu. Người nhận cần thấy phương án, căn cứ và điều còn chưa chắc để sử dụng quyền của mình.
Cũng cần chỉ định đường xử lý khi người có quyền vắng mặt hoặc khi các chủ thể bất đồng. Một cơ chế chờ vô hạn có thể tạo rủi ro riêng, nhất là trong sự cố hoặc thay đổi sát thời điểm kinh doanh. Đường thay thế phải phù hợp quyền được giao, không phải mặc định người ở cấp dưới tự quyết mọi việc.
Việc phân tách nhiệm vụ và kiểm tra độc lập cần được thiết kế theo rủi ro. Nhóm tự tạo giải pháp không nên là nguồn bằng chứng duy nhất cho mọi quyết định quan trọng. Tuy vậy, không nên thêm nhiều lớp kiểm tra giống nhau nếu chúng không cung cấp góc nhìn hoặc khả năng phát hiện khác biệt.
Để trách nhiệm tiếp tục có hiệu lực sau cuộc họp
Phân quyền không kết thúc khi bảng được ký. Sau mỗi quyết định quan trọng, doanh nghiệp cần theo dõi hành động, điều kiện đi kèm và bằng chứng đóng việc. Nếu người ra quyết định không biết kết quả hoặc ngoại lệ không được xem lại, trách nhiệm giải trình sẽ mờ dần trong quá trình thực hiện.
Có thể dùng một sổ quyết định gọn với nội dung lựa chọn, người có quyền, căn cứ, điều kiện và ngày rà lại do doanh nghiệp thống nhất. Sổ này không cần ghi mọi thao tác; nên tập trung vào các lựa chọn có tác động hoặc tạo ngoại lệ. Giá trị nằm ở khả năng truy lại tại sao tổ chức đã chọn như vậy.
Khi đổi cơ cấu hoặc thuê ngoài thêm dịch vụ, rà lại quyền thay vì chỉ sửa tên trong bảng. Nhà cung cấp có thể nhận trách nhiệm thực hiện, nhưng trách nhiệm của doanh nghiệp đối với lựa chọn và kết quả không tự chuyển hết sang hợp đồng. Cần giữ người sở hữu dịch vụ và cơ chế kiểm chứng phù hợp.
Chương trình COBIT 5 Foundation có thể hỗ trợ hệ thống hóa mô hình trách nhiệm trước khi tùy chỉnh. Bước thực hành nên bắt đầu từ vài quyết định đang gây nhầm lẫn nhất. Khi mỗi người biết mình đang xác nhận nội dung gì, có quyền tới đâu và phải trình ai khi giới hạn bị vượt, trách nhiệm đã trở thành cơ chế làm việc.