INFOCHIEF ACADEMY · CIO KNOWLEDGE SERIES · BÀI 09

Ngân sách IT nên chia thế nào giữa vận hành, đổi mới và tăng trưởng dài hạn?

“Bao nhiêu phần trăm cho Run, bao nhiêu cho Change?” là câu hỏi hấp dẫn vì nó hứa hẹn một công thức đơn giản. Nhưng tỷ lệ tốt cho một ngân hàng ổn định chưa chắc phù hợp với doanh nghiệp đang mở thị trường, tích hợp M&A hoặc tái kiến trúc nền tảng. CIO cần một cơ chế phân bổ có thể giải thích và điều chỉnh, không phải một tỷ lệ chuẩn áp cho mọi năm.

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: CIO cân bằng ngân sách giữa năng lực vận hành hôm nay và đầu tư cho tăng trưởng tương lai.

Đừng bắt đầu bằng tỷ lệ 50/30/20

Các tỷ lệ mẫu như 70/20/10 hay 50/30/20 có thể hữu ích để khơi gợi thảo luận, nhưng dễ tạo “neo nhận thức”. Nếu doanh nghiệp đang có hệ thống lõi cũ, tỷ trọng vận hành cao có thể phản ánh nợ kỹ thuật chứ không phải lựa chọn chiến lược. Ngược lại, doanh nghiệp tăng trưởng nhanh có thể cần đầu tư nền tảng lớn trước khi doanh thu xuất hiện.

Điểm khởi đầu tốt hơn là xác định năng lực bắt buộc phải duy trì, năng lực phải thay đổi để đạt chiến lược và mức rủi ro doanh nghiệp chấp nhận. Sau đó mới chuyển thành portfolio envelope và tỷ lệ ngân sách. Đây là góc nhìn được phát triển trong Xây Dựng Kế Hoạch Chiến Lược IT.

Phân loại theo mục đích đầu tư, không theo tên tài khoản

Một chi phí cloud có thể phục vụ vận hành hoặc một sản phẩm tăng trưởng. Một dự án security có thể vừa đáp ứng tuân thủ vừa bảo vệ khả năng tăng trưởng. Vì vậy classification theo accounting line thường không phản ánh mục đích chiến lược.

Nhóm mục đích	Câu hỏi quyết định	Ví dụ
Duy trì & bảo vệ	Năng lực nào phải hoạt động an toàn?	Core systems, cyber hygiene, support, backup
Nâng hiệu quả	Ở đâu có thể giảm cost-to-serve hoặc cycle time?	Automation, simplification, observability
Tăng trưởng	Năng lực nào mở doanh thu/thị trường/công suất?	Digital channel, data product, platform scale
Đổi mới có kiểm soát	Giả thuyết nào cần thử nghiệm trước khi scale?	AI pilot, emerging tech, new operating model

Xác lập “sàn năng lực” trước khi nói đến đổi mới

CIO không nên cắt vận hành đến mức làm suy yếu nền tảng tạo giá trị. Trước khi phân bổ cho đổi mới, cần xác định minimum viable resilience: dịch vụ thiết yếu, yêu cầu bảo mật, phục hồi, năng lực nhân sự, license bắt buộc và nghĩa vụ hợp đồng. Phần “sàn” này phải dựa trên impact và risk, không phải lịch sử chi tiêu.

Đây là nơi Quản Trị Rủi Ro IT và Quản Lý Bảo Mật Thông Tin hỗ trợ CIO giải thích vì sao một số khoản chi không thể đánh giá đơn thuần bằng ROI ngắn hạn.

Thiết kế portfolio envelope thay vì phê duyệt hàng trăm dòng chi

Ban điều hành nên phê duyệt các “envelope” theo mục tiêu, rủi ro và giới hạn thay vì vi mô hóa từng hạng mục. CIO sau đó quản lý danh mục bên trong envelope theo tiêu chí được ủy quyền. Cách này vừa tăng tốc vừa giữ governance.

Một envelope nên có gì?

Mục tiêu kinh doanh hoặc năng lực cần bảo vệ.
Giới hạn ngân sách và mức độ linh hoạt.
Các guardrail về risk, architecture và compliance.
Tiêu chí ưu tiên giữa các sáng kiến.
Trigger để tái phân bổ giữa năm.
Owner chịu trách nhiệm về outcome.

Khóa Lập Kế Hoạch & Quản Lý Ngân Sách IT có thể được dùng để chuẩn hóa quy trình lập kế hoạch và kiểm soát các envelope này.

Ba lớp thời gian giúp tránh hy sinh tương lai cho áp lực hiện tại

Một danh mục cân bằng cần nhìn cùng lúc ba horizon. Horizon 1 bảo vệ năng lực hiện tại; Horizon 2 cải thiện mô hình hiện có; Horizon 3 xây lựa chọn cho tương lai. Không phải mọi doanh nghiệp đều cần ngân sách lớn cho Horizon 3, nhưng nếu luôn cắt phần này khi có áp lực quý, năng lực chiến lược sẽ suy giảm dần.

Horizon	Mục tiêu	Cơ chế quản trị
H1 – Now	Tin cậy, an toàn, hiệu quả	SLA, risk thresholds, unit cost
H2 – Next	Hiện đại hóa, tự động hóa, mở rộng	Benefits, adoption, stage gates
H3 – Options	Thử nghiệm năng lực mới	Hypothesis, learning milestones, stop criteria

Khi ngân sách bị cắt, cắt theo khả năng đảo ngược và giá trị biên

Không phải mọi đồng ngân sách đều có cùng mức độ linh hoạt. License dài hạn, hợp đồng outsource hay nhân sự core có tính “sticky”; pilot, scope bổ sung hoặc roadmap chưa cam kết có thể linh hoạt hơn. CIO nên lập bản đồ committed / adjustable / optional.

Tiếp theo đánh giá marginal value: nếu cắt thêm 10% ở nhóm này, doanh nghiệp mất gì? Nếu tăng thêm 10%, outcome nào có thể cải thiện? Câu hỏi biên tốt hơn việc so sánh tổng ngân sách với năm trước. Với dự án lớn, Giám Đốc Dự Án IT – Project Manager cần cung cấp dữ liệu về chi phí dừng, chi phí trì hoãn và điểm stage gate để quyết định.

Tình huống minh họa: vừa phải tiết kiệm vừa phải tăng trưởng

Tình huống minh họa: doanh nghiệp yêu cầu IT giảm chi phí vận hành nhưng đồng thời mở kênh bán mới. Nếu CIO cắt đồng đều, cả vận hành lẫn dự án tăng trưởng đều thiếu nguồn lực. Thay vào đó, CIO xác định 5 dịch vụ critical với resilience floor, hợp nhất một số công cụ trùng lặp, tái đàm phán SaaS, trì hoãn một dự án nội bộ lợi ích thấp và chuyển nguồn lực cho kênh tăng trưởng.

Điểm quan trọng là CIO không gọi mọi khoản giảm chi là “tiết kiệm”. Phải chỉ ra phần nào là efficiency thực, phần nào là deferred spend và phần nào là risk acceptance. Khi ba khái niệm bị trộn lẫn, Ban điều hành dễ tưởng chi phí đã giảm bền vững trong khi nghĩa vụ chỉ bị đẩy sang năm sau.

Dashboard phân bổ cần giải thích cả dòng tiền lẫn năng lực

Một dashboard ngân sách chiến lược nên cho phép xem theo ít nhất ba trục: mục đích đầu tư, business capability và mức độ commitment. Có thể bổ sung vendor, cost center hoặc cloud service ở lớp drill-down. Đừng bắt đầu bằng 200 dòng GL và kỳ vọng lãnh đạo tự suy ra chiến lược.

Đối với cloud và SaaS, FinOps Foundation khuyến khích cộng tác giữa engineering, finance và business để tối đa hóa business value của technology spend. Điều này đặc biệt hữu ích khi chi phí biến động theo usage và khó cố định bằng budget truyền thống.

Checklist tái cân bằng ngân sách IT

Đã xác định resilience floor cho các dịch vụ và nghĩa vụ trọng yếu.
Mỗi khoản chi lớn được gắn với mục đích chiến lược, không chỉ cost center.
Tách committed, adjustable và optional spend.
Có envelope cho tăng trưởng/đổi mới thay vì chờ phần ngân sách còn lại.
Review marginal value khi tăng hoặc giảm ngân sách.
Đánh giá chi phí dừng/trì hoãn dự án.
Không gọi deferred spend là saving.
Có trigger tái phân bổ giữa năm khi chiến lược hoặc rủi ro thay đổi.

Hành động nên bắt đầu: lấy ngân sách năm hiện tại, gắn từng khoản vào bốn mục đích Duy trì & bảo vệ / Hiệu quả / Tăng trưởng / Đổi mới. Những dòng không thể gắn được thường là nơi cần làm rõ owner và business rationale.

Nợ kỹ thuật là một yêu cầu ngân sách, không chỉ là vấn đề kỹ thuật

Technical debt thường bị che khuất trong phần vận hành: hệ thống vẫn chạy nên việc hiện đại hóa bị coi là tùy chọn. Nhưng khi nợ kỹ thuật làm tăng thời gian thay đổi, phụ thuộc nhân sự hiếm, rủi ro bảo mật hoặc chi phí hỗ trợ, nó trở thành một claim cạnh tranh trực tiếp với tăng trưởng và đổi mới.

CIO nên lượng hóa nợ kỹ thuật theo tác động: số giờ vận hành bổ sung, thời gian release kéo dài, rủi ro end-of-support, chi phí vendor, khả năng tuyển nhân sự hoặc hạn chế tích hợp. Khi đó Ban điều hành có thể quyết định chủ động chấp nhận, trả dần hay xử lý nhanh thay vì coi đây là “mong muốn nâng cấp của IT”.

Tái phân bổ phải là một năng lực định kỳ

Ngân sách năm không nên đóng băng danh mục trong mười hai tháng. Khi một sáng kiến chứng minh giá trị nhanh hơn dự kiến, khi một vendor tăng giá, khi rủi ro mới xuất hiện hoặc khi chiến lược kinh doanh thay đổi, CIO cần có cơ chế chuyển nguồn lực giữa các envelope.

Cơ chế tốt thường quy định trước ngưỡng tái phân bổ CIO có thể tự quyết, ngưỡng cần CFO/CEO phê duyệt và ngưỡng phải đưa ra Ban điều hành. Nhờ vậy doanh nghiệp vừa giữ kỷ luật tài chính vừa không biến ngân sách thành rào cản với tốc độ chiến lược.

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.