INFOCHIEF ACADEMY · CIO KNOWLEDGE SERIES

Ngân sách IT bị cắt giảm: CIO giữ lại sáng kiến nào và dừng dự án nào?

Khi Ban điều hành yêu cầu giảm 15% ngân sách IT, phản xạ dễ nhất là cắt đều 15% ở mọi nhóm. Cách làm này tạo cảm giác công bằng nhưng thường phá hủy ưu tiên: một dịch vụ thiết yếu bị cắt ngang với một thử nghiệm chưa chứng minh giá trị, một dự án tuân thủ bị đối xử như một nâng cấp “nice to have”. Nhiệm vụ của CIO không phải chia đều nỗi đau mà là bảo vệ giá trị, kiểm soát rủi ro và làm rõ trade-off.

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 danh mục đầu tư dựa trên giá trị, rủi ro, khả năng thực thi và chi phí trì hoãn.

Cắt ngân sách là bài toán danh mục, không phải bài toán kế toán

Ngân sách IT không phải một khối đồng nhất. Trong đó có chi phí giữ dịch vụ hoạt động, nghĩa vụ hợp đồng, kiểm soát an toàn, chương trình tuân thủ, dự án tăng trưởng, đầu tư nền tảng và thử nghiệm đổi mới. Khi cắt theo tỷ lệ đồng đều, doanh nghiệp có thể tiết kiệm ngắn hạn nhưng tăng chi phí hoặc rủi ro trong chu kỳ sau.

ISO/IEC 38506:2020 tiếp cận đầu tư có yếu tố IT từ góc nhìn governance, nhấn mạnh kết quả có lợi và bằng chứng thành công thay vì chỉ xem IT như chi phí. Điều này phù hợp với tình huống cắt giảm: câu hỏi không nên là “dự án nào đắt nhất?” mà là “mỗi khoản chi đang bảo vệ hoặc tạo ra kết quả gì, và điều gì xảy ra nếu hoãn hoặc dừng?”.

CIO cần chuyển cuộc thảo luận từ cost reduction sang portfolio choices. Đây cũng là nơi mối quan hệ CIO–CFO trở nên quan trọng: tài chính giúp kiểm tra cash impact và assumptions; CIO giúp giải thích dependency, risk, technical constraints và khả năng thực thi.

Phân loại chi tiêu trước khi cắt

Trước khi chấm điểm dự án, CIO nên phân loại toàn bộ chi tiêu theo mục đích. Một cấu trúc thực dụng gồm: Run – vận hành dịch vụ hiện tại; Protect – an toàn, tuân thủ, khả năng phục hồi; Improve – tối ưu chi phí, chất lượng và năng suất; Grow – hỗ trợ doanh thu, khách hàng và năng lực mới; Explore – thử nghiệm tương lai.

Không có tỷ lệ “chuẩn” cho mọi doanh nghiệp. Tỷ trọng phụ thuộc ngành, tuổi hệ thống, chiến lược và mức chấp nhận rủi ro. Điều quan trọng là làm lộ trade-off. Nếu Run chiếm quá lớn do hệ thống cũ, cắt Grow không giải quyết nguyên nhân; doanh nghiệp cần chương trình hiện đại hóa để hạ chi phí cấu trúc.

Với chi phí cloud và SaaS, FinOps nhấn mạnh sự phối hợp giữa engineering, finance và business để tối đa giá trị công nghệ. CIO có thể dùng tư duy này để tách “giảm lãng phí” khỏi “cắt năng lực tạo giá trị”.

Năm tiêu chí để đánh giá sáng kiến

Tiêu chí	Câu hỏi chính	Dấu hiệu ưu tiên cao
Strategic alignment	Có trực tiếp hỗ trợ ưu tiên doanh nghiệp?	Liên kết rõ mục tiêu và owner
Business value	Lợi ích có đo được và còn phù hợp?	Outcome rõ, assumptions được kiểm tra
Risk/obligation	Không làm sẽ tăng rủi ro hay vi phạm nghĩa vụ?	Rủi ro trọng yếu, deadline bắt buộc
Cost of delay	Hoãn 3–6 tháng gây mất gì?	Mất doanh thu, kéo dài chi phí, tăng exposure
Execution confidence	Đội ngũ có khả năng tạo kết quả?	Dependency rõ, năng lực sẵn sàng, scope kiểm soát

Không nên biến ma trận thành một “điểm số khách quan tuyệt đối”. Điểm số chỉ giúp tạo kỷ luật và minh bạch; lãnh đạo vẫn cần thảo luận các phụ thuộc chiến lược. Ví dụ, một dự án nền tảng có ROI trực tiếp thấp nhưng là điều kiện để ba sáng kiến tăng trưởng cùng chạy.

Tạo ma trận Keep – Rescope – Defer – Stop

Thay vì hai lựa chọn “giữ” hoặc “hủy”, CIO nên tạo bốn quyết định. Keep cho sáng kiến thiết yếu hoặc giá trị cao. Rescope giữ outcome nhưng giảm phạm vi, chia phase hoặc thay giải pháp. Defer hoãn có chủ đích đến thời điểm điều kiện tốt hơn. Stop dừng khi business case không còn phù hợp hoặc chi phí cơ hội quá lớn.

Rescope thường là công cụ mạnh nhất trong khủng hoảng ngân sách. Một chương trình ERP ba năm có thể chia theo quy trình tạo giá trị lớn nhất; dự án analytics có thể ưu tiên một use case thay vì xây platform toàn diện; dự án nâng cấp có thể tách phần security-critical khỏi phần tiện ích.

Khi rescope, cần bảo đảm “scope tối thiểu” vẫn tạo outcome, không chỉ cắt hạng mục dễ cắt. Đây là kỹ năng quản trị danh mục và dự án; chương trình Giám Đốc Dự Án IT – Project Manager hỗ trợ năng lực kiểm soát phạm vi, dependency và lợi ích trong các quyết định như vậy.

Đừng bỏ qua chi phí trì hoãn và chi phí dừng

Hoãn một dự án không có nghĩa chi phí bằng 0. Doanh nghiệp có thể tiếp tục trả license cũ, duy trì quy trình thủ công, chịu rủi ro bảo mật hoặc mất cơ hội thị trường. Ngược lại, dừng một dự án giữa chừng cũng có termination cost, sunk migration effort, contractual penalty và ảnh hưởng nhân sự.

CIO nên trình bày ba con số thay vì chỉ một: cash saved now, cost created later và value/risk forgone. Ví dụ, trì hoãn thay thế hệ thống legacy có thể tiết kiệm capex năm nay nhưng tăng support cost và kéo dài rủi ro end-of-support. Quyết định vẫn có thể là hoãn, nhưng Ban điều hành cần nhìn đầy đủ hậu quả.

Đối với danh mục cloud, licensing và SaaS, Lập Kế Hoạch & Quản Lý Ngân Sách IT và tư duy FinOps giúp CIO tách tối ưu usage, rate và architecture khỏi việc cắt nhu cầu kinh doanh một cách cơ học.

Quy trình ra quyết định với CFO và chủ nghiệp vụ

CIO không nên tự quyết định dừng các sáng kiến kinh doanh. Quy trình tốt có ba lớp: IT chuẩn bị dữ liệu chi phí, dependency và risk; business owner xác nhận value và cost of delay; CFO kiểm tra assumptions tài chính và khả năng ngân sách. Ban điều hành quyết định khi có trade-off liên phòng ban.

Chốt mục tiêu giảm ngân sách và những vùng không được vi phạm.
Tạo danh mục đầy đủ gồm Run, Protect, Improve, Grow, Explore.
Chuẩn hóa one-page business case cho từng sáng kiến trọng yếu.
Chấm tiêu chí sơ bộ nhưng không dùng điểm thay thế thảo luận.
Phân loại Keep/Rescope/Defer/Stop.
Kiểm tra dependency và hậu quả vòng hai.
Xác nhận lại với owner trước khi khóa kế hoạch.

Khi CIO cần phát triển khả năng trao đổi với tài chính và lãnh đạo về giá trị, rủi ro và ngân sách, đây là một nội dung cốt lõi của chương trình CIO của Infochief Academy.

Tình huống minh họa: giữ nền tảng, dừng tính năng

Tình huống giả định: doanh nghiệp cần giảm 12% ngân sách đầu tư. Một chương trình customer platform gồm ba workstream: chuẩn hóa dữ liệu khách hàng, thay giao diện CRM và triển khai AI recommendation. Nếu cắt đều 12%, cả ba workstream chậm lại và dependency kéo dài.

Sau khi đánh giá, CIO đề xuất giữ nguyên data foundation vì đây là dependency cho CRM và AI; rescope CRM chỉ tập trung quy trình bán hàng chính; defer AI recommendation đến khi dữ liệu và adoption ổn định. Một dự án dashboard nội bộ ít người dùng bị stop hoàn toàn. Tổng ngân sách giảm đạt yêu cầu nhưng năng lực nền tảng và outcome ưu tiên vẫn được bảo vệ.

Bài học: cắt giảm thông minh thường không chia đều. Nó tập trung nguồn lực vào chuỗi tạo giá trị có logic rõ nhất và dừng những phần chưa có bằng chứng.

Checklist tái ưu tiên ngân sách trong 30 ngày

Danh mục chi tiêu đã được phân theo Run/Protect/Improve/Grow/Explore.
Mỗi sáng kiến có owner, outcome, cost-to-complete và cost of delay.
Đã nhận diện nghĩa vụ pháp lý, bảo mật, hợp đồng và end-of-support.
Đã tách sunk cost khỏi future decision; không giữ dự án chỉ vì “đã chi nhiều”.
Đã xem xét Rescope trước khi mặc định Stop.
Dependency giữa các sáng kiến được thể hiện trên cùng một bản đồ.
CFO và business owner xác nhận assumptions trọng yếu.
Danh sách dừng/hoãn có kế hoạch đóng, chuyển giao và quản lý rủi ro.
Phần ngân sách tiết kiệm được theo dõi sau quyết định, không chỉ trên kế hoạch.

Hành động nên bắt đầu: chọn 20 khoản chi lớn nhất, buộc mỗi khoản trả lời ba câu hỏi: nó bảo vệ/tạo outcome nào, rủi ro nếu dừng là gì và phương án rẻ hơn có thể giữ cùng outcome hay không. Danh sách này thường tạo ra cuộc đối thoại tốt hơn bất kỳ yêu cầu “giảm X%” chung chung nào.

Một sai lầm khác là chỉ xem xét ngân sách dự án mới mà bỏ qua “run cost” được tạo ra sau khi dự án đi vào vận hành. Một giải pháp có capex thấp nhưng làm tăng license, hỗ trợ, tích hợp và năng lực vận hành trong ba năm có thể đắt hơn lựa chọn ban đầu tưởng tượng. Khi tái ưu tiên, CIO nên yêu cầu mỗi sáng kiến thể hiện tổng chi phí vòng đời và xác định phần nào trở thành chi phí cố định sau go-live. Điều này giúp tránh việc tiết kiệm ngân sách năm nay nhưng tạo một cơ sở chi phí lớn hơn cho các năm sau.

Ngược lại, không phải mọi khoản “Run” đều bất khả xâm phạm. Các dịch vụ trùng lặp, môi trường không sử dụng, license dư, hợp đồng gia hạn tự động hoặc workload cấu hình quá mức là nơi có thể giảm chi phí mà không giảm outcome. Đây là lý do một chương trình cắt giảm nên chạy hai luồng song song: tối ưu chi tiêu hiện hữu và tái ưu tiên danh mục tương lai. Nếu chỉ dừng dự án mới mà không cải thiện nền chi phí hiện tại, tổ chức sẽ lặp lại áp lực ngân sách vào năm sau.

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ị và thực hành chuyên môn. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy.