INFOCHIEF ACADEMY · CIO KNOWLEDGE SERIES · BÀI 06

Ai quyết định điều gì trong quản trị IT: HĐQT, Ban điều hành hay bộ phận công nghệ?

Một dự án có thể chậm nhiều tuần chỉ vì không ai chắc ai có quyền phê duyệt. Một rủi ro có thể bị kéo dài vì HĐQT tưởng Ban điều hành đã xử lý, trong khi Ban điều hành lại xem đó là việc của CIO. Quản trị IT hiệu quả bắt đầu bằng một câu hỏi tưởng đơn giản nhưng thường bị bỏ qua: ai có quyền quyết định điều gì, dựa trên thông tin nào và chịu trách nhiệm đến đâu?

Biên soạn: Infochief Academy · Chuyên đề: Giám đốc Công nghệ Thông tin – CIO

← Trở về danh mục CIO

Minh họa biên tập: Ban lãnh đạo xác lập quyền quyết định giữa HĐQT, Ban điều hành, CIO và các đơn vị kinh doanh.

Quản trị IT thất bại thường bắt đầu từ quyền quyết định mơ hồ

Khi quyền quyết định không được thiết kế rõ, tổ chức rất dễ rơi vào hai cực. Ở cực thứ nhất, mọi quyết định công nghệ đều bị đẩy lên cấp lãnh đạo cao nhất, khiến HĐQT hoặc Tổng Giám đốc phải xử lý cả những vấn đề mang tính vận hành. Ở cực thứ hai, bộ phận IT tự quyết định những vấn đề có tác động lớn đến chiến lược, rủi ro hoặc ngân sách mà thiếu sự tham gia của chủ doanh nghiệp.

Điểm cần phân biệt là governance và management. Governance xác lập định hướng, tiêu chí, giới hạn và cơ chế giám sát; management tổ chức nguồn lực và thực hiện trong những giới hạn đó. ISO/IEC 38500:2024 nhấn mạnh vai trò của governing body trong việc định hướng và giám sát việc sử dụng IT của tổ chức. Điều này không đồng nghĩa HĐQT phải chọn phần mềm, cấu hình firewall hay phê duyệt mọi thay đổi kỹ thuật.

Ở cấp CIO, năng lực quan trọng là biết đưa quyết định lên đúng cấp. Nội dung này gắn trực tiếp với năng lực lãnh đạo và quản trị CIO: lãnh đạo công nghệ không phải giành quyền quyết định nhiều hơn, mà là thiết kế một hệ thống ra quyết định giúp doanh nghiệp vừa nhanh vừa có kiểm soát.

Bốn lớp quyết định cần tách biệt

Một cách thực dụng là phân loại quyết định IT thành bốn lớp. Mỗi lớp có chủ thể quyết định khác nhau và yêu cầu bằng chứng khác nhau.

Lớp quyết định	Ví dụ	Chủ thể chính
Định hướng & khẩu vị rủi ro	Mức chấp nhận gián đoạn, nguyên tắc AI, giới hạn rủi ro bên thứ ba	HĐQT / cơ quan quản trị
Ưu tiên & phân bổ nguồn lực	Danh mục đầu tư, ngân sách, ưu tiên chương trình chuyển đổi	Ban điều hành
Thiết kế & quản lý năng lực IT	Kiến trúc, tiêu chuẩn, sourcing, dịch vụ, nhân sự IT	CIO và lãnh đạo IT
Thực thi vận hành	Thay đổi chuẩn, xử lý sự cố, vận hành dịch vụ	Đội IT theo ủy quyền

Các ranh giới này không tuyệt đối. Ví dụ, kiến trúc doanh nghiệp là trách nhiệm chuyên môn của CIO nhưng một quyết định kiến trúc làm tăng đáng kể rủi ro tập trung nhà cung cấp hoặc chi phí dài hạn có thể cần Ban điều hành xem xét. Điều quan trọng là xác lập trước ngưỡng escalations, thay vì tranh luận quyền hạn sau khi vấn đề phát sinh.

HĐQT nên quyết định điều gì và không nên quyết định điều gì?

HĐQT hoặc cơ quan quản trị nên tập trung vào các quyết định có tính định hướng, rủi ro và trách nhiệm giải trình. HĐQT cần biết công nghệ đang hỗ trợ chiến lược nào, doanh nghiệp đang chấp nhận mức rủi ro nào, những khoản đầu tư lớn có luận chứng gì và năng lực giám sát có phù hợp hay không.

HĐQT không nên trở thành “kiến trúc sư giải pháp” hoặc “ủy ban lựa chọn phần mềm”. Khi HĐQT tranh luận sản phẩm cụ thể mà chưa thống nhất tiêu chí kinh doanh, cấp quản trị đang đi quá sâu vào quản lý. Ngược lại, nếu HĐQT chỉ nhận báo cáo uptime mà không thấy rủi ro phụ thuộc công nghệ, nợ kỹ thuật hoặc mức độ thực hiện chiến lược, vai trò giám sát lại quá nông.

Ban điều hành biến định hướng thành ưu tiên và nguồn lực

Ban điều hành là nơi chiến lược được chuyển thành danh mục ưu tiên. Đây là cấp phải giải quyết xung đột giữa tăng trưởng, hiệu quả, tuân thủ, trải nghiệm khách hàng và khả năng cung ứng nguồn lực. CIO cung cấp phương án và phân tích; Ban điều hành quyết định mức ưu tiên khi lợi ích và nguồn lực cạnh tranh nhau.

Một cơ chế hữu ích là yêu cầu mọi sáng kiến lớn trả lời cùng một bộ câu hỏi: mục tiêu kinh doanh nào được hỗ trợ, lợi ích nào có chủ sở hữu nghiệp vụ, tổng chi phí vòng đời ra sao, rủi ro chính là gì, năng lực thực thi có đủ hay không và điều gì sẽ phải trì hoãn nếu sáng kiến được phê duyệt. Khóa Lập Kế Hoạch & Quản Lý Ngân Sách IT có thể hỗ trợ đội ngũ chuẩn hóa phần ngân sách, trong khi năng lực lãnh đạo dự án IT giúp chuyển quyết định đầu tư thành cơ chế thực thi có trách nhiệm.

CIO sở hữu khuyến nghị chuyên môn, không sở hữu mọi quyết định

CIO cần có thẩm quyền đủ mạnh đối với kiến trúc, tiêu chuẩn công nghệ, quản lý dịch vụ, an toàn kỹ thuật và năng lực đội ngũ; nhưng không nên tự xác nhận giá trị kinh doanh của chính khoản đầu tư do IT đề xuất. Chủ quy trình hoặc đơn vị kinh doanh phải đồng sở hữu lợi ích.

Điểm trưởng thành của CIO không phải là “IT được toàn quyền” mà là quyết định được đưa về nơi có thông tin tốt nhất và trách nhiệm phù hợp nhất. Với những hoạt động lặp lại, CIO nên thiết kế delegation matrix để IT Manager và các nhóm chuyên môn có thể ra quyết định trong giới hạn rõ ràng. Đây là cầu nối tự nhiên với năng lực quản lý bộ phận IT.

Ba câu hỏi trước khi CIO nhận một quyền quyết định

Quyết định này có tác động vượt quá phạm vi IT hay không?
Ai là chủ sở hữu lợi ích hoặc rủi ro cuối cùng?
Cấp ra quyết định có đủ dữ liệu và có chịu trách nhiệm về hệ quả hay không?

Từ RACI đến Decision Rights Matrix

RACI hữu ích để phân công công việc nhưng không phải lúc nào cũng đủ để mô tả quyền quyết định. Một người “Accountable” trong RACI có thể vẫn chưa rõ có quyền phê duyệt, quyền phủ quyết hay chỉ chịu trách nhiệm điều phối. Vì vậy, với các quyết định trọng yếu, nên bổ sung Decision Rights Matrix.

Quyết định	Đề xuất	Thẩm định	Quyết định	Giám sát
Chiến lược IT	CIO	Ban điều hành	CEO/HĐQT theo cơ chế công ty	HĐQT/Ban điều hành
Đầu tư lớn	Business owner + CIO	CFO/Risk/Architecture	Ban điều hành	Steering Committee
Tiêu chuẩn kiến trúc	Enterprise Architecture	Security/Operations	CIO hoặc Architecture Board	CIO
Thay đổi thường lệ	Service/Technical owner	Theo quy trình	Ủy quyền trong ngưỡng	IT Management

Ma trận chỉ có giá trị khi đi cùng ngưỡng quyết định và dữ liệu đầu vào. Một quyết định mua sắm dưới ngưỡng có thể được ủy quyền, nhưng nếu tạo rủi ro dữ liệu hoặc phụ thuộc chiến lược thì vẫn phải escalated.

Tình huống minh họa: dự án AI bị kẹt giữa ba cấp

Tình huống minh họa: một doanh nghiệp muốn triển khai trợ lý AI nội bộ. Bộ phận kinh doanh yêu cầu triển khai nhanh; IT lo ngại dữ liệu; tài chính muốn kiểm soát chi phí; HĐQT quan tâm rủi ro danh tiếng. Dự án trì hoãn vì mỗi cuộc họp đều quay lại câu hỏi “ai được quyết định?”.

Cách xử lý không phải thành lập thêm một ủy ban, mà là tách quyết định. HĐQT xác lập nguyên tắc và khẩu vị rủi ro AI; Ban điều hành chọn use case ưu tiên và mức ngân sách; CIO cùng bộ phận an toàn thông tin thiết kế tiêu chuẩn dữ liệu, kiến trúc và kiểm soát; business owner chịu trách nhiệm về mức áp dụng và lợi ích. Khi ranh giới rõ, tốc độ thường tăng vì ít phải xin lại phê duyệt.

Checklist thiết kế quyền quyết định IT

Mỗi nhóm quyết định trọng yếu có một cấp quyết định rõ ràng.
Phân biệt người đề xuất, người thẩm định và người phê duyệt.
Có ngưỡng escalations cho chi phí, rủi ro, kiến trúc và dữ liệu.
Chủ sở hữu nghiệp vụ đồng chịu trách nhiệm với lợi ích của đầu tư IT.
HĐQT nhận thông tin về chiến lược và rủi ro, không bị chìm trong chi tiết vận hành.
CIO có đủ quyền để duy trì tiêu chuẩn nhưng không tự xác nhận mọi lợi ích.
Quyền được ủy quyền xuống IT Manager và technical owner được ghi nhận rõ.
Ma trận được xem xét lại khi mô hình kinh doanh, cấu trúc tổ chức hoặc rủi ro thay đổi.

Hành động nên bắt đầu: chọn 10 quyết định IT gây tranh luận nhiều nhất trong sáu tháng gần đây, xác định ai đã quyết định thực tế, ai đáng lẽ phải quyết định và nguyên nhân chênh lệch. Đây thường là cách nhanh nhất để nhìn thấy lỗ hổng governance.

Nguồn tham khảo

Các nguồn trên được dùng làm tài liệu tham khảo cho nguyên tắc quản trị, tài chính, đo lường hoặc quản lý rủi ro. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy.