Cách hoạch định ngân sách công nghệ phù hợp

Vì vậy, câu hỏi trọng tâm không nên chỉ là “năm tới có thể chi bao nhiêu cho công nghệ?”, mà phải gồm cả “chi cho nhu cầu nào, vì sao nhu cầu đó quan trọng, tổng nghĩa vụ chi phí là bao nhiêu, giá trị kỳ vọng được đo thế nào và điều kiện nào khiến khoản đầu tư cần được điều chỉnh hoặc dừng lại?”.

Một benchmark như tỷ lệ chi công nghệ trên doanh thu vẫn hữu ích để kiểm tra mức chi tương đối, nhưng không nên trở thành công thức quyết định ngân sách. Dữ liệu khảo sát cho thấy tỷ lệ này có thể khác biệt rất lớn giữa ngành, mô hình kinh doanh và mức độ phụ thuộc vào công nghệ. Deloitte từng ghi nhận mức chi IT theo doanh thu dao động từ dưới 2% ở một số ngành đến gần 8% ở ngân hàng và chứng khoán; các khảo sát mới hơn về đầu tư số cũng cho thấy phạm vi chi tiêu tiếp tục thay đổi đáng kể theo mục tiêu chuyển đổi.

Bắt đầu ngân sách từ nhu cầu kinh doanh, không từ danh sách công nghệ

Bước đầu tiên của hoạch định ngân sách công nghệ là chuyển các mục tiêu kinh doanh thành nhu cầu công nghệ có thể tài trợ. Nếu bắt đầu từ danh sách máy chủ, phần mềm, AI, cloud hoặc các yêu cầu mua sắm riêng lẻ, doanh nghiệp rất dễ hình thành một ngân sách thể hiện “sẽ mua gì” nhưng không giải thích được “kết quả nào cần đạt”.

Một nhu cầu nên được mô tả bằng ít nhất ba thành phần: vấn đề hoặc cơ hội kinh doanh, năng lực công nghệ cần có và kết quả có thể quan sát được.

Ví dụ, “mua hệ thống CRM mới” chỉ mô tả giải pháp. Nhu cầu thực tế có thể là giảm thời gian xử lý lead, thống nhất dữ liệu khách hàng giữa bán hàng và chăm sóc khách hàng, hoặc tăng khả năng theo dõi tỷ lệ chuyển đổi. Khi nhu cầu được diễn đạt theo cách này, doanh nghiệp có thể so sánh CRM với các phương án khác thay vì mặc nhiên coi việc mua hệ thống là quyết định đã có sẵn.

Cùng một logic nên được áp dụng với các khoản đầu tư bắt buộc. An ninh mạng, khả năng phục hồi, tuân thủ hay thay thế hạ tầng hết vòng đời không nhất thiết tạo doanh thu trực tiếp, nhưng chúng bảo vệ khả năng vận hành và giới hạn mức tổn thất mà doanh nghiệp phải chấp nhận. NIST Cybersecurity Framework 2.0 cũng đặt quản trị rủi ro, mục tiêu và mức chấp nhận rủi ro vào quá trình xác định và ưu tiên các kết quả an ninh mạng, thay vì coi bảo mật là danh sách công cụ cần mua.

Kết quả của bước này nên là một danh mục nhu cầu, không phải một danh mục sản phẩm. Mỗi nhu cầu phải trả lời được: doanh nghiệp đang cố tạo giá trị nào hoặc kiểm soát rủi ro nào, ai chịu trách nhiệm cho kết quả đó và điều gì xảy ra nếu không đầu tư.

Xếp hạng ưu tiên trước khi quyết định mức ngân sách

Không phải nhu cầu hợp lý nào cũng nên được tài trợ cùng lúc. Hoạch định ngân sách vì vậy cần có cơ chế xếp hạng để phân biệt giữa khoản phải làm, khoản nên làm và khoản có thể chờ.

Một mô hình ưu tiên thực tế có thể đánh giá từng đề xuất theo năm nhóm tiêu chí:

·         Mức độ gắn với mục tiêu kinh doanh

·         Giá trị tài chính hoặc giá trị vận hành kỳ vọng

·         Mức rủi ro được giảm hoặc nghĩa vụ bắt buộc phải đáp ứng

·         Mức độ cấp bách và phụ thuộc vào các sáng kiến khác

·         Chi phí, độ phức tạp và khả năng thực thi

Các tiêu chí không nhất thiết có trọng số bằng nhau. Với một hệ thống sắp hết hỗ trợ kỹ thuật hoặc một yêu cầu tuân thủ có thời hạn, rủi ro và tính cấp bách có thể quan trọng hơn ROI ngắn hạn. Với một thử nghiệm AI, ngược lại, khả năng chứng minh giá trị và chi phí mở rộng sau thử nghiệm có thể là điều kiện quan trọng hơn.

Một lỗi thường gặp là xếp hạng dự án dựa chủ yếu trên lợi ích được đề xuất bởi chính đơn vị xin ngân sách. Điều đó tạo động cơ để mọi business case đều thể hiện lợi ích lớn. Cách kiểm soát tốt hơn là chuẩn hóa tiêu chí, yêu cầu chủ sở hữu nghiệp vụ chịu trách nhiệm về KPI kết quả và so sánh các sáng kiến trên cùng một cơ sở.

Mục tiêu của việc xếp hạng không phải tìm ra dự án “tốt nhất” một cách tuyệt đối. Nó nhằm xác định thứ tự sử dụng một nguồn lực hữu hạn sao cho mỗi khoản ngân sách được cấp đều có lý do rõ ràng hơn khoản đang đứng phía sau nó.

Tính tổng chi phí sở hữu thay vì chỉ tính giá mua

Một ngân sách công nghệ dễ bị thiếu hụt khi chỉ ghi nhận chi phí mua hoặc triển khai ban đầu. Công nghệ thường tạo ra nghĩa vụ tài chính kéo dài nhiều năm, trong đó một phần đáng kể xuất hiện sau thời điểm dự án được phê duyệt.

Bao gồm toàn bộ chi phí vòng đời

Tổng chi phí sở hữu — Total Cost of Ownership (TCO) — nên tính cả các khoản cần thiết để công nghệ thực sự hoạt động trong khoảng thời gian doanh nghiệp dự kiến sử dụng nó, chẳng hạn:

·         Bản quyền, thuê bao và mức tăng giá theo hợp đồng

·         Cloud, lưu trữ, mạng và mức sử dụng thực tế

·         Triển khai, tích hợp và di chuyển dữ liệu

·         Nhân sự nội bộ và dịch vụ bên ngoài

·         Bảo trì, hỗ trợ và nâng cấp

·         Bảo mật, sao lưu, giám sát và khả năng phục hồi

·         Đào tạo và quản trị thay đổi

·         Chi phí chuyển đổi hoặc ngừng sử dụng khi kết thúc vòng đời

TBM Council tổ chức chi phí công nghệ theo các lớp như cost pools, tài nguyên công nghệ, giải pháp và đối tượng hưởng lợi. Cách phân loại này cho phép doanh nghiệp lần theo chi phí từ thứ đã mua — như lao động, phần mềm hay cloud — đến dịch vụ hoặc kết quả kinh doanh mà nguồn lực đó hỗ trợ. TBM cũng coi TCO là một cơ chế để tính đầy đủ chi phí vòng đời của ứng dụng, dịch vụ, nền tảng và sản phẩm số.

Phân biệt chi phí cố định và chi phí biến đổi

Đặc biệt với cloud và SaaS, ngân sách không nên giả định rằng chi phí sẽ giữ nguyên sau khi hệ thống được triển khai. Mức tiêu thụ có thể thay đổi theo số người dùng, giao dịch, dữ liệu, tài nguyên tính toán hoặc lưu lượng.

Vì thế, ngoài một con số ngân sách cơ sở, nên có kịch bản sử dụng. Ví dụ, chi phí dự kiến ở mức 100.000 giao dịch/tháng chưa đủ để đánh giá nếu doanh nghiệp không biết điều gì xảy ra khi khối lượng tăng lên 200.000 hoặc 500.000 giao dịch.

FinOps Framework đưa forecasting, budgeting, KPI, benchmarking và unit economics vào cùng nhóm hoạt động nhằm lượng hóa giá trị kinh doanh của chi tiêu công nghệ. Với cloud, đo “chi phí trên một đơn vị giá trị” — như chi phí trên giao dịch, khách hàng hoặc đơn hàng — thường hữu ích hơn việc chỉ theo dõi tổng hóa đơn.

Nhờ đó, tăng chi phí không mặc nhiên bị coi là xấu. Nếu chi phí cloud tăng 20% nhưng số giao dịch tạo giá trị tăng 40%, economics của hệ thống có thể đang tốt lên. Ngược lại, tổng chi chỉ tăng nhẹ vẫn là vấn đề nếu chi phí trên mỗi đơn vị đầu ra liên tục tăng.

Đánh giá giá trị kỳ vọng bằng kết quả có thể đo lường

Sau khi biết một nhu cầu tốn bao nhiêu, doanh nghiệp cần xác định khoản chi đó được kỳ vọng tạo ra điều gì. Giá trị công nghệ không chỉ là doanh thu mới. Nó có thể xuất hiện dưới nhiều hình thức: giảm chi phí, tăng năng suất, rút ngắn thời gian xử lý, cải thiện khả năng phục vụ khách hàng, giảm tổn thất kỳ vọng hoặc tạo năng lực mới cho doanh nghiệp.

Điều quan trọng là chuyển những lợi ích này thành KPI trước khi ngân sách được phê duyệt.

Thay vì ghi “hệ thống mới sẽ tăng hiệu quả”, có thể đặt mục tiêu:

·         Giảm thời gian xử lý một giao dịch từ X xuống Y

·         Giảm chi phí trên mỗi giao dịch từ X xuống Y

·         Giảm số giờ xử lý thủ công mỗi tháng

·         Tăng tỷ lệ quy trình được tự động hóa

·         Giảm thời gian gián đoạn dịch vụ

·         Giảm số sự cố thuộc một nhóm rủi ro cụ thể

·         Tăng tỷ lệ người dùng thực sự sử dụng chức năng mục tiêu

·         Đạt mức doanh thu, biên lợi nhuận hoặc tiết kiệm đã xác định

KPI cần gắn với baseline. Nếu không biết trạng thái trước đầu tư, doanh nghiệp rất khó chứng minh thay đổi sau đầu tư có thực sự đến từ công nghệ.

Đồng thời, ROI không nên được áp dụng máy móc cho mọi khoản chi. Một hệ thống bắt buộc để duy trì hoạt động có thể không tạo doanh thu mới nhưng việc trì hoãn nó có thể làm tăng xác suất gián đoạn nghiêm trọng. Một khoản đầu tư bảo mật cũng có thể được đánh giá theo mức rủi ro giảm được thay vì cố biến mọi lợi ích thành doanh thu giả định.

Với sáng kiến có độ bất định cao, nên dùng nhiều kịch bản thay vì một dự báo duy nhất. Kịch bản thấp, cơ sở và cao giúp lãnh đạo thấy khoản đầu tư còn hợp lý hay không khi tỷ lệ áp dụng, chi phí vận hành hoặc lợi ích thực tế lệch khỏi giả định ban đầu.

Phân bổ ngân sách giữa vận hành, bảo vệ và thay đổi

Sau khi từng sáng kiến được đánh giá riêng, doanh nghiệp cần xem danh mục ngân sách như một tổng thể. Một danh mục chỉ tập trung vào vận hành có thể ổn định ngắn hạn nhưng tích tụ nợ công nghệ. Ngược lại, dành quá nhiều tiền cho đổi mới trong khi hệ thống nền tảng thiếu độ tin cậy có thể khiến các sáng kiến mới không thể mở rộng.

Có thể xem ngân sách theo ba nhóm chức năng:

·         Vận hành: duy trì các dịch vụ và năng lực đang được sử dụng

·         Bảo vệ và duy trì khả năng tồn tại: an ninh, tuân thủ, resilience, thay thế hệ thống hết vòng đời và xử lý nợ công nghệ quan trọng

·         Tăng trưởng và chuyển đổi: năng lực mới, tự động hóa, dữ liệu, sản phẩm số, AI hoặc các sáng kiến thay đổi mô hình hoạt động

Không có tỷ lệ phân bổ cố định phù hợp cho mọi doanh nghiệp. Dữ liệu khảo sát Deloitte minh họa rõ điều này: năm 2023, các lãnh đạo công nghệ được khảo sát báo cáo khoảng 48% ngân sách cho “run”, 31% cho “grow” và 21% cho “transform”; đến khảo sát công bố năm 2026, phân bổ đang dịch chuyển theo hướng cân bằng hơn giữa ba nhóm. Đây là benchmark để đặt câu hỏi, không phải tỷ lệ mục tiêu cần sao chép.

Nếu doanh nghiệp phải dùng gần như toàn bộ ngân sách để duy trì hệ thống cũ, vấn đề có thể không phải ngân sách tổng quá thấp mà là cấu trúc chi phí hiện tại đang hạn chế khả năng đầu tư mới. Khi đó, tối ưu license, loại bỏ ứng dụng trùng lặp, hiện đại hóa nền tảng hoặc giảm chi phí đơn vị có thể giải phóng nguồn lực hiệu quả hơn việc chỉ xin thêm ngân sách.

Dùng benchmark để kiểm tra, không dùng benchmark để thay thế quyết định

Tỷ lệ ngân sách công nghệ trên doanh thu là một trong những benchmark dễ sử dụng nhất, nhưng cũng dễ bị hiểu sai nhất.

Hai doanh nghiệp có cùng doanh thu có thể cần mức chi công nghệ hoàn toàn khác nhau nếu một bên bán sản phẩm số, còn bên kia sử dụng công nghệ chủ yếu cho hoạt động hỗ trợ. Quy mô, ngành, mức độ số hóa, hệ thống legacy, yêu cầu tuân thủ, tốc độ tăng trưởng và mức thuê ngoài đều ảnh hưởng đến con số thích hợp.

Các khảo sát cũng minh họa mức dao động này. Một nghiên cứu Deloitte trước đây ghi nhận trung bình IT budget khoảng 3,64% doanh thu nhưng chênh lệch theo ngành từ dưới 2% đến gần 8%. Nghiên cứu khác về lãnh đạo công nghệ cho thấy các tổ chức tạo doanh thu trực tiếp từ công nghệ có mức chi cao hơn đáng kể so với nhóm không tạo doanh thu công nghệ.

Do đó, benchmark nên được sử dụng như một phép kiểm tra:

Nếu chi thấp hơn nhóm tương đồng: doanh nghiệp cần kiểm tra liệu mình có đang đầu tư thiếu vào nền tảng, bảo mật, dữ liệu hoặc năng lực tăng trưởng hay không.

Nếu chi cao hơn nhóm tương đồng: cần xác định mức cao hơn xuất phát từ chiến lược có chủ đích hay từ chi phí kém hiệu quả, hệ thống trùng lặp, nợ công nghệ hoặc đơn giá quá cao.

Nếu chi gần benchmark: điều này vẫn không chứng minh ngân sách phù hợp. Một danh mục có thể đạt đúng “tỷ lệ ngành” nhưng phân bổ sai hoàn toàn so với nhu cầu kinh doanh.

Benchmark vì thế là tín hiệu chẩn đoán, không phải công thức lập ngân sách.

Lập ngân sách theo danh mục có ngưỡng quyết định

Ngân sách công nghệ không nên kết thúc ở trạng thái “đã duyệt”. Đối với khoản đầu tư lớn hoặc có độ bất định cao, việc cấp toàn bộ ngân sách từ đầu có thể khiến doanh nghiệp tiếp tục tài trợ cho một giả định ngay cả khi dữ liệu thực tế đã thay đổi.

Một cách kiểm soát tốt hơn là chia đầu tư thành các giai đoạn có ngưỡng quyết định.

Ví dụ:

1.    Discovery: xác minh nhu cầu, dữ liệu và tính khả thi

2.    Pilot: kiểm tra giải pháp ở phạm vi hạn chế

3.    Scale: mở rộng sau khi KPI cốt lõi đạt ngưỡng

4.    Operate: chuyển sang cơ chế ngân sách vận hành khi giá trị đã được chứng minh

Cách này đặc biệt phù hợp với AI, tự động hóa hoặc sản phẩm số mới, nơi chi phí mở rộng có thể khác rất xa chi phí thử nghiệm.

Ngưỡng quyết định phải được xác định trước. Một pilot không nên được coi là thành công chỉ vì công nghệ hoạt động. Nếu mục tiêu là giảm 30% thời gian xử lý nhưng thử nghiệm chỉ giảm 5%, câu hỏi phải là liệu có bằng chứng cho thấy cải tiến tiếp theo đủ để biện minh cho ngân sách mở rộng hay không.

Ngược lại, một sáng kiến vượt mục tiêu ban đầu có thể đáng được tái phân bổ thêm vốn thay vì buộc phải chờ chu kỳ ngân sách tiếp theo.

Theo dõi cả ngân sách, chi phí thực tế và giá trị thực tế

Một kế hoạch ngân sách chỉ có ý nghĩa khi được kiểm tra trong quá trình thực hiện. Ba dòng dữ liệu cần được theo dõi song song:

Budget: doanh nghiệp đã đồng ý dành bao nhiêu nguồn lực.

Actual cost: thực tế đã tiêu bao nhiêu và mức chi đang biến động theo yếu tố nào.

Realized value: kết quả kinh doanh hoặc mức giảm rủi ro thực sự đạt được đến đâu.

Chỉ theo dõi budget versus actual có thể khiến một dự án được coi là “đúng kế hoạch” dù không tạo giá trị. Ngược lại, một sáng kiến vượt ngân sách đôi chút nhưng tạo giá trị vượt xa kế hoạch có thể vẫn là khoản đầu tư tốt.

Định kỳ theo tháng hoặc quý, mỗi khoản đầu tư đáng kể nên được xem xét bằng cùng một nhóm câu hỏi:

·         Chi phí thực tế có lệch đáng kể khỏi giả định không

·         KPI giá trị có đi đúng hướng không

·         Các giả định ban đầu còn đúng không

·         Có rủi ro mới làm thay đổi thứ tự ưu tiên không

·         Khoản đầu tư nên tiếp tục, tăng vốn, thu hẹp hay dừng

·         Có ngân sách nào có thể tái phân bổ sang cơ hội có giá trị cao hơn không

Nhờ cơ chế này, ngân sách chuyển từ một bản dự báo tĩnh thành hệ thống phân bổ nguồn lực. Đây cũng là điểm khác biệt quan trọng giữa “kiểm soát chi tiêu” và “quản trị giá trị công nghệ”.

Một quy trình hoạch định ngân sách công nghệ có thể áp dụng

Trong thực tế, doanh nghiệp có thể tổ chức quá trình hoạch định theo trình tự sau:

1.    Xác định mục tiêu và nhu cầu kinh doanh

2.    Ghi rõ kết quả cần tạo hoặc rủi ro cần kiểm soát

3.    Lập danh mục năng lực và sáng kiến công nghệ

4.    Chỉ đưa vào danh mục những khoản có liên kết rõ với nhu cầu

5.    Xác định chi phí cơ sở bắt buộc

6.    Bao gồm vận hành, hợp đồng, nhân sự, bảo mật, tuân thủ và nghĩa vụ vòng đời

7.    Tính TCO cho từng khoản đầu tư đáng kể

8.    Không chỉ dùng giá mua hoặc chi phí triển khai năm đầu

9.    Xác định KPI và giá trị kỳ vọng

10.  Có baseline, mục tiêu, thời gian và chủ sở hữu kết quả

11.  Chấm điểm và xếp hạng ưu tiên

12.  So sánh giá trị, rủi ro, cấp bách, phụ thuộc, chi phí và khả năng thực thi

13.  Xây dựng nhiều kịch bản ngân sách

14.  Chẳng hạn ngân sách tối thiểu, ngân sách cơ sở và ngân sách tăng tốc

15.  Kiểm tra bằng benchmark phù hợp

16.  So sánh với doanh nghiệp tương đồng nhưng không sao chép tỷ lệ của họ

17.  Phê duyệt cùng các điều kiện tiếp tục đầu tư

18.  Xác định trước KPI hoặc milestone dùng để mở khóa ngân sách tiếp theo

19.  Theo dõi chi phí và giá trị để tái phân bổ

20.  Điều chỉnh danh mục khi giả định, rủi ro hoặc hiệu quả thực tế thay đổi

Quá trình này buộc từng đồng ngân sách phải đi qua một chuỗi logic có thể giải thích: nhu cầu → ưu tiên → chi phí → giá trị → quyết định tài trợ → kiểm chứng thực tế. Nó cũng tạo ra ngôn ngữ chung giữa công nghệ, tài chính và các đơn vị kinh doanh thay vì để mỗi bên đánh giá khoản đầu tư bằng một tiêu chí riêng.

Hoạch định ngân sách công nghệ phù hợp vì vậy không bắt đầu bằng việc chọn một tỷ lệ chi tiêu lý tưởng. Ngân sách cần được hình thành từ những nhu cầu kinh doanh và rủi ro thực sự, sau đó xếp hạng theo ưu tiên, tính đủ tổng chi phí vòng đời, gắn với KPI giá trị và kiểm tra bằng benchmark phù hợp.

Một con số ngân sách cao chưa chắc thể hiện doanh nghiệp đầu tư tốt; một con số thấp cũng chưa chắc thể hiện hiệu quả. Điều cần đánh giá là cấu trúc của khoản chi: tiền đang duy trì năng lực nào, bảo vệ rủi ro nào, tạo kết quả gì và có thể được tái phân bổ nhanh đến đâu khi dữ liệu thực tế thay đổi.

Khi những câu hỏi đó có câu trả lời rõ ràng, ngân sách công nghệ không còn là giới hạn chi tiêu của bộ phận IT mà trở thành cơ chế lựa chọn và quản trị các khoản đầu tư công nghệ theo giá trị mà doanh nghiệp kỳ vọng nhận được.