Cách so sánh chi phí sử dụng phần mềm

Để so sánh chính xác, doanh nghiệp cần chuyển từ câu hỏi “phần mềm nào có giá thấp hơn?” sang câu hỏi “phương án nào tạo ra tổng chi phí thấp nhất cho cùng một phạm vi sử dụng, cùng mức độ đáp ứng và cùng khoảng thời gian đánh giá?”.

Khung phù hợp nhất là tổng chi phí sở hữu, thường được gọi là Total Cost of Ownership hoặc TCO. TCO tập hợp toàn bộ chi phí trực tiếp, gián tiếp và chi phí rủi ro trong suốt vòng đời sử dụng phần mềm. Khi các phương án được chuẩn hóa theo cùng giả định, TCO giúp doanh nghiệp phát hiện những khoản chi chưa xuất hiện trong báo giá và tránh chọn nhầm giải pháp có giá mua thấp nhưng chi phí vận hành cao.

Vì sao giá niêm yết không phản ánh chi phí thực tế?

Giá niêm yết thường chỉ bao gồm quyền truy cập hoặc quyền sử dụng phần mềm. Trong thực tế, doanh nghiệp còn phải đưa phần mềm vào hệ thống hiện có, chuyển dữ liệu, đào tạo người dùng, điều chỉnh quy trình, duy trì tích hợp và xử lý các thay đổi phát sinh.

Có thể biểu diễn chi phí thực tế bằng công thức:

Tổng chi phí sử dụng = Chi phí mua hoặc thuê Chi phí triển khai Chi phí vận hành Chi phí nội bộ Chi phí thay đổi Chi phí rủi ro − Giá trị thu hồi

Trong đó, giá trị thu hồi có thể là giá trị bán lại giấy phép, chi phí hạ tầng được giải phóng hoặc phần chi phí được tránh nhờ thay thế hệ thống cũ. Với phần mềm thuê bao, giá trị thu hồi thường không đáng kể; với hệ thống mua đứt hoặc có tài sản hạ tầng đi kèm, yếu tố này có thể cần được ghi nhận.

Hai phần mềm có cùng mức phí 20 triệu đồng mỗi tháng vẫn có thể tạo ra TCO rất khác nhau. Phần mềm thứ nhất có thể hoạt động gần như ngay lập tức, trong khi phần mềm thứ hai cần sáu tháng tích hợp, một nhóm vận hành riêng và nhiều giờ nhập liệu thủ công. Chênh lệch lớn nhất khi đó không nằm ở phí thuê bao mà nằm ở nguồn lực cần thiết để phần mềm thực sự vận hành.

Sai lầm phổ biến là so sánh một con số chắc chắn của phương án này với một con số chưa đầy đủ của phương án khác. Chẳng hạn, doanh nghiệp đưa toàn bộ chi phí tùy chỉnh của giải pháp A vào bảng tính nhưng chỉ sử dụng phí bản quyền của giải pháp B. Kết quả có vẻ chính xác về mặt số học nhưng không có giá trị cho quyết định.

Chuẩn hóa phạm vi trước khi so sánh

Trước khi tính chi phí, doanh nghiệp phải bảo đảm các phần mềm được so sánh trên cùng một mặt bằng. Nếu phạm vi sử dụng khác nhau, kết quả TCO sẽ bị sai lệch ngay từ đầu.

Các giả định tối thiểu cần thống nhất gồm:

·         Số lượng người dùng thực tế

·         Số lượng người dùng đồng thời

·         Phòng ban và đơn vị áp dụng

·         Tính năng bắt buộc

·         Khối lượng dữ liệu cần lưu trữ

·         Số hệ thống cần tích hợp

·         Mức hỗ trợ kỹ thuật yêu cầu

·         Yêu cầu bảo mật và phân quyền

·         Mức độ sẵn sàng cần đạt

·         Thời gian đánh giá

·         Tốc độ tăng trưởng dự kiến

·         Phạm vi triển khai theo quốc gia hoặc chi nhánh

Một phần mềm giá thấp nhưng chỉ đáp ứng 70% yêu cầu không nên được so sánh trực tiếp với phần mềm đáp ứng 95% yêu cầu. Khoảng thiếu 25% có thể phải được bù bằng phát triển riêng, thao tác thủ công hoặc một công cụ bổ sung.

Doanh nghiệp nên thiết lập một cấu hình so sánh chuẩn. Ví dụ:

·         150 người dùng trong năm đầu

·         Tăng trưởng người dùng 10% mỗi năm

·         Thời gian đánh giá 3 năm

·         4 hệ thống cần tích hợp

·         500 GB dữ liệu ban đầu

·         Hỗ trợ kỹ thuật trong giờ hành chính

·         Mức đáp ứng nghiệp vụ tối thiểu 90%

Mọi nhà cung cấp phải báo giá và giải thích chi phí dựa trên cấu hình này. Nếu một giải pháp không đáp ứng được cấu hình, phần thiếu phải được chuyển thành chi phí bổ sung hoặc được ghi nhận như một giới hạn.

Xác định khoảng thời gian tính tổng chi phí

Phần mềm doanh nghiệp hiếm khi chỉ được sử dụng trong vài tháng. Vì vậy, so sánh chi phí của riêng năm đầu có thể tạo ra kết luận sai.

Khoảng thời gian phổ biến để phân tích là 3 đến 5 năm. Thời gian phù hợp phụ thuộc vào quy mô triển khai, mức độ tích hợp và chi phí chuyển đổi hệ thống.

Phân tích 3 năm thường phù hợp khi:

·         Nhu cầu kinh doanh thay đổi nhanh

·         Phần mềm có mô hình thuê bao linh hoạt

·         Chi phí chuyển đổi không quá lớn

·         Doanh nghiệp chưa chắc chắn về tốc độ tăng trưởng

Phân tích 5 năm thường phù hợp khi:

·         Hệ thống ảnh hưởng đến nhiều quy trình cốt lõi

·         Chi phí triển khai ban đầu cao

·         Có nhiều tích hợp hoặc tùy chỉnh

·         Việc thay thế phần mềm trong thời gian ngắn rất khó

Doanh nghiệp không nên mặc định rằng chi phí năm đầu sẽ lặp lại nguyên trạng ở các năm sau. Phí thuê bao có thể tăng theo số lượng người dùng, dung lượng dữ liệu, giao dịch, chi nhánh hoặc mức dịch vụ. Ngược lại, chi phí triển khai thường tập trung ở giai đoạn đầu.

Công thức tổng quát cho một phương án trong thời gian (n) năm là:

TCO = Chi phí ban đầu Tổng chi phí định kỳ từng năm Chi phí phát sinh dự kiến Chi phí rủi ro

Nếu cần so sánh tài chính chặt chẽ hơn, doanh nghiệp có thể quy đổi các khoản chi tương lai về giá trị hiện tại. Cách này đặc biệt hữu ích khi hai phương án có cấu trúc dòng tiền rất khác nhau, chẳng hạn một phương án yêu cầu đầu tư lớn ngay từ đầu còn phương án kia thu phí thuê bao qua nhiều năm.

Liệt kê đầy đủ các nhóm chi phí

Chi phí mua bản quyền hoặc thuê bao

Đây là nhóm chi phí dễ nhận biết nhất nhưng vẫn có thể bị tính thiếu. Cách tính phí của phần mềm doanh nghiệp thường không chỉ dựa trên một mức giá cố định.

Doanh nghiệp cần kiểm tra:

·         Phí theo người dùng

·         Phí theo người dùng đồng thời

·         Phí theo mô-đun

·         Phí theo giao dịch

·         Phí theo doanh thu

·         Phí theo dung lượng lưu trữ

·         Phí theo môi trường vận hành

·         Phí cho tài khoản quản trị

·         Phí truy cập API

·         Phí báo cáo nâng cao

·         Phí hỗ trợ cao cấp

·         Mức mua tối thiểu

·         Cơ chế điều chỉnh giá hằng năm

Một phần mềm có mức phí 400.000 đồng mỗi người dùng mỗi tháng sẽ tiêu tốn 720 triệu đồng một năm cho 150 người dùng, chưa tính thuế và dịch vụ bổ sung:

400.000 × 150 × 12 = 720.000.000 đồng

Nếu số người dùng tăng 10% mỗi năm, không thể lấy 720 triệu đồng nhân đều cho ba năm. Chi phí phải được tính theo quy mô của từng năm.

Doanh nghiệp cũng cần phân biệt người dùng được cấp tài khoản với người dùng thực sự cần truy cập. Cấp giấy phép cho toàn bộ nhân sự dù chỉ một phần sử dụng thường làm tăng chi phí mà không tạo thêm giá trị.

Chi phí triển khai

Chi phí triển khai là khoản cần thiết để biến một sản phẩm tiêu chuẩn thành một hệ thống có thể sử dụng trong doanh nghiệp.

Nhóm này có thể bao gồm:

·         Khảo sát yêu cầu

·         Thiết kế giải pháp

·         Cấu hình hệ thống

·         Tùy chỉnh chức năng

·         Thiết lập phân quyền

·         Thiết kế biểu mẫu

·         Thiết lập quy trình phê duyệt

·         Kiểm thử

·         Quản lý dự án

·         Hỗ trợ vận hành ban đầu

·         Nghiệm thu

Một báo giá triển khai trọn gói chưa chắc đã bao gồm toàn bộ công việc. Doanh nghiệp cần xác định rõ số ngày tư vấn, số vòng chỉnh sửa, số quy trình, số báo cáo và tiêu chí nghiệm thu được bao gồm.

Nếu phạm vi chưa rõ, chi phí triển khai nên được tách thành:

Chi phí cơ sở Chi phí theo đơn vị công việc Khoản dự phòng thay đổi phạm vi

Ví dụ minh họa, một dự án có chi phí cơ sở 300 triệu đồng, 20 ngày tùy chỉnh với đơn giá 12 triệu đồng mỗi ngày và dự phòng 15% sẽ có ngân sách dự kiến:

(300 20 × 12) × 115% = 621 triệu đồng

Đây là phép tính ngân sách, không phải cam kết rằng dự án chắc chắn sẽ tiêu hết số tiền đó. Mục đích của khoản dự phòng là phản ánh mức độ bất định khi yêu cầu chưa hoàn toàn ổn định.

Chi phí tích hợp

Phần mềm hiếm khi hoạt động độc lập. Nó có thể cần trao đổi dữ liệu với hệ thống kế toán, quản trị nhân sự, bán hàng, kho, thương mại điện tử, ngân hàng hoặc nền tảng phân tích.

Chi phí tích hợp phụ thuộc vào:

·         Số hệ thống kết nối

·         Loại API được hỗ trợ

·         Tần suất đồng bộ

·         Khối lượng giao dịch

·         Mức độ biến đổi dữ liệu

·         Yêu cầu xử lý lỗi

·         Mức độ giám sát

·         Trách nhiệm bảo trì

·         Chính sách tính phí API

Không nên chỉ tính chi phí xây dựng kết nối ban đầu. Mỗi khi một trong hai hệ thống thay đổi cấu trúc dữ liệu, phiên bản API hoặc cơ chế xác thực, doanh nghiệp có thể phải sửa lại tích hợp.

Chi phí tích hợp vòng đời có thể được tính như sau:

Chi phí tích hợp = Chi phí xây dựng ban đầu Chi phí kiểm thử Chi phí giám sát Chi phí bảo trì Chi phí sửa đổi dự kiến

Một kết nối miễn phí ở thời điểm triển khai không đồng nghĩa với việc nó không tạo chi phí. Nếu nhân sự nội bộ phải kiểm tra lỗi mỗi ngày, chi phí lao động đó vẫn thuộc TCO.

Chi phí chuyển đổi và làm sạch dữ liệu

Chuyển dữ liệu thường bị xem là một công việc kỹ thuật đơn giản, nhưng chất lượng dữ liệu cũ có thể khiến khoản này tăng nhanh.

Các hoạt động cần tính gồm:

·         Kiểm kê nguồn dữ liệu

·         Xác định dữ liệu cần giữ lại

·         Loại bỏ dữ liệu trùng lặp

·         Chuẩn hóa mã và định dạng

·         Ánh xạ trường dữ liệu

·         Chuyển đổi dữ liệu

·         Đối soát sau chuyển đổi

·         Xử lý dữ liệu lỗi

·         Lưu trữ dữ liệu lịch sử

·         Chạy thử nhiều lần

Chi phí không chỉ phụ thuộc vào số GB dữ liệu. Một tập dữ liệu nhỏ nhưng thiếu chuẩn hóa có thể tốn nhiều công sức hơn một tập dữ liệu lớn có cấu trúc nhất quán.

Doanh nghiệp nên yêu cầu nhà cung cấp nêu rõ:

·         Khối lượng dữ liệu được bao gồm

·         Số nguồn dữ liệu

·         Số lần chuyển thử

·         Trách nhiệm làm sạch dữ liệu

·         Tiêu chí đối soát

·         Chi phí khi dữ liệu vượt phạm vi

Chi phí hạ tầng và vận hành kỹ thuật

Với phần mềm cài đặt tại doanh nghiệp, chi phí hạ tầng thường bao gồm máy chủ, lưu trữ, sao lưu, bản quyền hệ điều hành, cơ sở dữ liệu, giám sát và nhân sự quản trị.

Với phần mềm dịch vụ đám mây, nhiều khoản đã nằm trong phí thuê bao nhưng không phải lúc nào cũng bao gồm toàn bộ nhu cầu. Doanh nghiệp vẫn có thể phải trả thêm cho:

·         Dung lượng vượt mức

·         Băng thông

·         Sao lưu dài hạn

·         Môi trường kiểm thử

·         Nhật ký hệ thống

·         Công cụ giám sát

·         Khôi phục dữ liệu

·         Kết nối riêng

·         Giải pháp đăng nhập một lần

·         Công cụ bảo mật bổ sung

So sánh phần mềm tại chỗ với phần mềm đám mây chỉ bằng giá máy chủ và phí thuê bao là chưa đủ. Phương án tại chỗ cần tính cả điện, không gian, bảo trì, thay thế thiết bị, thời gian quản trị và năng lực phục hồi. Phương án đám mây cần tính tăng trưởng người dùng, dữ liệu, giao dịch và khả năng điều chỉnh giá.

Chi phí đào tạo và quản trị thay đổi

Một phần mềm chỉ tạo giá trị khi người dùng áp dụng đúng vào công việc. Do đó, đào tạo và quản trị thay đổi không phải khoản phụ mà là một phần của chi phí triển khai thực tế.

Chi phí có thể gồm:

·         Thiết kế tài liệu hướng dẫn

·         Đào tạo người dùng chủ chốt

·         Đào tạo người dùng cuối

·         Thời gian nhân viên tham gia đào tạo

·         Hỗ trợ sau đào tạo

·         Truyền thông nội bộ

·         Cập nhật quy trình

·         Xử lý phản hồi

·         Đào tạo nhân viên mới

·         Đào tạo lại khi phần mềm thay đổi

Chi phí thời gian đào tạo có thể được quy đổi:

Chi phí đào tạo nội bộ = Số người tham gia × Số giờ đào tạo × Chi phí lao động bình quân mỗi giờ

Ví dụ, 150 nhân viên tham gia 8 giờ đào tạo với chi phí lao động bình quân 180.000 đồng mỗi giờ sẽ tạo ra 216 triệu đồng chi phí thời gian:

150 × 8 × 180.000 = 216.000.000 đồng

Con số này không phải khoản thanh toán cho nhà cung cấp nhưng vẫn là nguồn lực doanh nghiệp đã sử dụng.

Chi phí nhân sự nội bộ

Nhiều dự án phần mềm có báo giá bên ngoài thấp nhưng tiêu tốn đáng kể nguồn lực nội bộ.

Nhân sự nội bộ có thể tham gia:

·         Thu thập yêu cầu

·         Chuẩn hóa quy trình

·         Chuẩn bị dữ liệu

·         Kiểm thử

·         Họp dự án

·         Phê duyệt cấu hình

·         Đào tạo

·         Hỗ trợ người dùng

·         Quản trị hệ thống

·         Làm việc với nhà cung cấp

Cách tính cơ bản là:

Chi phí nội bộ = Tổng số giờ tham gia × Chi phí đầy đủ mỗi giờ

Chi phí đầy đủ mỗi giờ không chỉ là tiền lương. Tùy mục đích phân tích, doanh nghiệp có thể cộng các khoản liên quan như bảo hiểm, phúc lợi, chi phí quản lý và chi phí cơ hội.

Không phải mọi giờ làm việc đều nên được tính theo cùng một mức. Thời gian của chuyên viên nghiệp vụ, quản lý dự án, lãnh đạo phê duyệt và kỹ sư tích hợp có giá trị khác nhau.

Chi phí hỗ trợ, bảo trì và nâng cấp

Doanh nghiệp cần phân biệt hỗ trợ tiêu chuẩn với hỗ trợ đáp ứng yêu cầu vận hành thực tế.

Các khoản cần kiểm tra gồm:

·         Phí bảo trì hằng năm

·         Phí hỗ trợ ngoài giờ

·         Phí hỗ trợ ưu tiên

·         Phí nâng cấp phiên bản

·         Phí kiểm thử sau nâng cấp

·         Phí sửa tùy chỉnh

·         Phí duy trì tích hợp

·         Phí gia hạn chứng thư hoặc kết nối

·         Phí tư vấn bổ sung

Với phần mềm tùy chỉnh nhiều, nâng cấp có thể phát sinh chi phí đáng kể vì các phần tùy chỉnh cần được kiểm thử hoặc viết lại. Ngược lại, phần mềm tiêu chuẩn hóa cao thường giảm gánh nặng nâng cấp nhưng có thể hạn chế khả năng điều chỉnh theo quy trình riêng.

Đưa chi phí gián tiếp vào mô hình

Chi phí do giảm năng suất trong giai đoạn chuyển đổi

Trong những tuần hoặc tháng đầu, người dùng thường thao tác chậm hơn vì chưa quen hệ thống. Một số quy trình có thể phải chạy song song trên phần mềm cũ và mới.

Chi phí suy giảm năng suất có thể được ước tính:

Chi phí giảm năng suất = Số người bị ảnh hưởng × Số giờ làm việc × Tỷ lệ suy giảm × Chi phí lao động mỗi giờ

Ví dụ, 100 nhân viên làm việc 160 giờ trong một tháng, năng suất giảm 8% và chi phí lao động là 150.000 đồng mỗi giờ:

100 × 160 × 8% × 150.000 = 192.000.000 đồng

Đây là mô hình ước tính. Doanh nghiệp nên điều chỉnh tỷ lệ suy giảm theo mức độ thay đổi của quy trình và kinh nghiệm từ các dự án trước.

Chi phí của thao tác thủ công còn lại

Một phần mềm không đáp ứng đầy đủ nghiệp vụ có thể buộc nhân viên tiếp tục dùng bảng tính, nhập lại dữ liệu hoặc đối chiếu bằng tay.

Chi phí hằng năm của thao tác thủ công có thể tính bằng:

Số lần thực hiện × Thời gian mỗi lần × Chi phí lao động mỗi giờ

Khoản chi nhỏ ở từng giao dịch có thể trở thành chi phí lớn khi lặp lại hàng nghìn lần. Vì vậy, tỷ lệ đáp ứng chức năng cần được chuyển thành tác động vận hành, không chỉ chấm điểm định tính.

Chi phí do gián đoạn hệ thống

Ngừng hoạt động có thể làm mất doanh thu, trì hoãn giao dịch, ảnh hưởng dịch vụ khách hàng hoặc khiến nhân sự không thể làm việc.

Chi phí kỳ vọng của gián đoạn được ước tính:

Chi phí gián đoạn kỳ vọng = Xác suất xảy ra × Thời gian gián đoạn × Thiệt hại mỗi giờ

Một cam kết mức dịch vụ cao hơn chỉ có giá trị khi thời gian ngừng hoạt động thực sự tạo ra thiệt hại đáng kể. Với quy trình không quan trọng, trả thêm phí cho mức sẵn sàng cao nhất có thể không hiệu quả.

Ngược lại, với hệ thống xử lý đơn hàng hoặc vận hành sản xuất, chỉ một vài giờ gián đoạn cũng có thể lớn hơn phần chênh lệch phí thuê bao cả năm.

Chi phí cơ hội

Chi phí cơ hội là giá trị doanh nghiệp mất đi khi chọn một phương án hoặc trì hoãn triển khai.

Ví dụ:

·         Chậm đưa sản phẩm ra thị trường

·         Không thể mở thêm chi nhánh đúng kế hoạch

·         Nhân sự phải duy trì quy trình thủ công

·         Dữ liệu không đủ nhanh để hỗ trợ quyết định

·         Đội kỹ thuật phải bảo trì hệ thống cũ thay vì phát triển năng lực mới

Chi phí cơ hội thường khó đo chính xác hơn chi phí hóa đơn. Doanh nghiệp không nên bỏ qua nhưng cũng không nên đưa vào như một con số chắc chắn. Có thể sử dụng ba kịch bản thấp, cơ sở và cao để phản ánh bất định.

Lượng hóa chi phí rủi ro

Chi phí rủi ro không phải khoản chắc chắn phát sinh. Đó là giá trị kỳ vọng của các sự kiện có thể xảy ra.

Công thức cơ bản:

Chi phí rủi ro kỳ vọng = Xác suất xảy ra × Mức thiệt hại nếu xảy ra

Ví dụ, một rủi ro chuyển đổi dữ liệu được ước tính có xác suất 20% và chi phí xử lý 500 triệu đồng. Chi phí kỳ vọng là:

20% × 500 triệu = 100 triệu đồng

Các rủi ro cần xem xét gồm:

·         Dự án chậm tiến độ

·         Vượt phạm vi triển khai

·         Dữ liệu chuyển đổi không đạt yêu cầu

·         Tích hợp không ổn định

·         Người dùng không chấp nhận hệ thống

·         Nhà cung cấp ngừng hỗ trợ sản phẩm

·         Giá thuê bao tăng

·         Hợp đồng khó chấm dứt

·         Khó xuất dữ liệu

·         Phụ thuộc vào tùy chỉnh độc quyền

·         Không đáp ứng yêu cầu bảo mật

·         Không đáp ứng tốc độ tăng trưởng

Không nên cộng toàn bộ mức thiệt hại tối đa vào TCO vì điều đó giả định mọi rủi ro chắc chắn xảy ra. Cũng không nên ghi chi phí rủi ro bằng 0 chỉ vì chưa xảy ra. Giá trị kỳ vọng tạo ra cách so sánh cân bằng hơn.

Khi không có dữ liệu đủ để gán xác suất đáng tin cậy, doanh nghiệp nên trình bày rủi ro như một khoảng chi phí hoặc chạy phân tích độ nhạy.

Lập bảng TCO cho từng phương án

Một bảng TCO hiệu quả cần tách chi phí theo thời điểm và theo nhóm, thay vì chỉ đưa ra một con số tổng.

Cấu trúc có thể gồm:

Năm 0 là giai đoạn trước khi hệ thống chính thức vận hành. Việc tách năm 0 giúp doanh nghiệp nhìn rõ khoản đầu tư ban đầu và thời điểm cần dòng tiền.

Mỗi dòng nên đi kèm ba thông tin:

·         Công thức tính

·         Nguồn dữ liệu

·         Mức độ chắc chắn

Ví dụ, phí thuê bao từ hợp đồng có mức chắc chắn cao. Chi phí giảm năng suất dựa trên giả định có mức chắc chắn thấp hơn. Phân biệt hai loại này giúp người ra quyết định không hiểu mọi con số trong bảng là chính xác như nhau.

So sánh bằng chi phí trên một đơn vị giá trị sử dụng

TCO thấp nhất chưa chắc là phương án tốt nhất. Một phần mềm có chi phí cao hơn nhưng phục vụ nhiều người dùng hơn, xử lý nhiều giao dịch hơn hoặc loại bỏ nhiều công việc thủ công hơn có thể tạo ra hiệu quả kinh tế tốt hơn.

Doanh nghiệp có thể sử dụng các chỉ số chuẩn hóa:

Chi phí trên một người dùng = TCO ÷ Tổng số người dùng hiệu dụng

Chi phí trên một giao dịch = TCO ÷ Tổng số giao dịch xử lý

Chi phí trên một quy trình = TCO ÷ Số quy trình được số hóa

Chi phí trên một giờ lao động tiết kiệm = TCO ÷ Tổng số giờ tiết kiệm

“Người dùng hiệu dụng” nên phản ánh mức sử dụng thực tế, không chỉ số tài khoản được cấp. Nếu 200 tài khoản được mua nhưng chỉ 120 người sử dụng thường xuyên, tính trên 200 người sẽ làm chi phí trên người dùng có vẻ thấp hơn thực tế.

Chỉ số phù hợp phải gắn với mục tiêu của hệ thống. Phần mềm bán hàng nên được đánh giá theo người dùng, giao dịch hoặc doanh thu được hỗ trợ. Phần mềm tự động hóa quy trình có thể phù hợp hơn với số giờ tiết kiệm hoặc số tác vụ được xử lý.

Kết hợp chi phí với mức độ đáp ứng

So sánh thuần túy bằng TCO có thể ưu tiên một phương án rẻ nhưng không đáp ứng nhu cầu. Doanh nghiệp cần đặt TCO cạnh điểm đáp ứng chức năng và mức độ rủi ro.

Có thể xây dựng một điểm số tổng hợp:

Điểm giá trị = Điểm đáp ứng đã điều chỉnh rủi ro ÷ TCO

Điểm đáp ứng nên được tính theo trọng số:

Điểm đáp ứng = Tổng của điểm từng tiêu chí × Trọng số tiêu chí

Ví dụ:

Trọng số chỉ là ví dụ minh họa. Doanh nghiệp phải điều chỉnh theo mục tiêu và mức độ quan trọng của từng nhóm.

Các yêu cầu bắt buộc không nên được bù trừ bằng điểm số. Nếu một phần mềm không đáp ứng yêu cầu pháp lý, bảo mật hoặc vận hành trọng yếu, điểm cao ở các tiêu chí khác không làm cho phương án trở nên phù hợp.

Một cách xử lý hợp lý là chia tiêu chí thành:

·         Điều kiện loại

·         Tiêu chí chấm điểm

·         Tiêu chí dùng để phân biệt khi điểm gần nhau

Chỉ những phần mềm vượt qua điều kiện loại mới được đưa vào phân tích TCO cuối cùng.

Chạy ba kịch bản thay vì dùng một con số

TCO luôn phụ thuộc vào giả định. Doanh nghiệp nên xây dựng ít nhất ba kịch bản:

Kịch bản thấp

Phản ánh trường hợp thuận lợi:

·         Ít tùy chỉnh

·         Tăng trưởng người dùng chậm

·         Không có phát sinh lớn

·         Tiến độ triển khai đúng kế hoạch

Kịch bản cơ sở

Phản ánh giả định có khả năng xảy ra cao nhất:

·         Khối lượng công việc theo kế hoạch

·         Mức tăng trưởng dự kiến

·         Một phần chi phí dự phòng được sử dụng

·         Năng suất phục hồi theo tiến độ thông thường

Kịch bản cao

Phản ánh trường hợp bất lợi nhưng có thể xảy ra:

·         Phát sinh tùy chỉnh

·         Tích hợp phức tạp hơn dự kiến

·         Chậm triển khai

·         Tăng số lượng người dùng

·         Chi phí nhà cung cấp tăng

·         Nhu cầu hỗ trợ cao hơn

Nếu phương án A chỉ rẻ hơn trong kịch bản thấp nhưng đắt hơn trong kịch bản cơ sở và cao, lợi thế chi phí của nó không bền vững. Ngược lại, một phương án có TCO cao hơn một chút nhưng ít biến động có thể phù hợp với doanh nghiệp ưu tiên khả năng kiểm soát ngân sách.

Kiểm tra độ nhạy của các giả định quan trọng

Phân tích độ nhạy cho biết biến số nào có thể làm thay đổi kết luận lựa chọn.

Các biến thường có ảnh hưởng lớn gồm:

·         Số người dùng

·         Mức tăng giá hằng năm

·         Số ngày tư vấn

·         Tỷ lệ tùy chỉnh

·         Khối lượng dữ liệu

·         Chi phí tích hợp

·         Tốc độ tăng trưởng giao dịch

·         Thời gian triển khai

·         Mức giảm năng suất

·         Thời gian duy trì hệ thống cũ

·         Chi phí chuyển đổi nhà cung cấp

Doanh nghiệp có thể thay đổi từng giả định trong một khoảng hợp lý, chẳng hạn tăng hoặc giảm 10%, 20% hoặc theo ngưỡng thực tế của dự án.

Nếu thay đổi nhỏ ở một biến làm phương án rẻ nhất trở thành đắt nhất, kết luận có độ ổn định thấp. Khi đó, doanh nghiệp cần thu thập báo giá chi tiết hơn, đàm phán điều khoản hoặc thiết kế biện pháp kiểm soát rủi ro.

Đọc hợp đồng để phát hiện chi phí bị trì hoãn

Một số chi phí không xuất hiện trong năm đầu nhưng được kích hoạt khi doanh nghiệp mở rộng, nâng cấp hoặc kết thúc hợp đồng.

Các điều khoản cần kiểm tra gồm:

·         Mức tăng giá khi gia hạn

·         Cách tính người dùng tối thiểu

·         Phí vượt dung lượng

·         Phí gọi API

·         Phí hỗ trợ ngoài phạm vi

·         Thời hạn cam kết

·         Điều kiện tự động gia hạn

·         Phí chấm dứt sớm

·         Định dạng xuất dữ liệu

·         Phí hỗ trợ xuất dữ liệu

·         Thời gian lưu dữ liệu sau chấm dứt

·         Quyền sở hữu phần tùy chỉnh

·         Trách nhiệm bảo trì tích hợp

·         Chi phí nâng cấp

·         Giới hạn trách nhiệm của nhà cung cấp

Chi phí thoát khỏi hệ thống cần được tính ngay từ lúc lựa chọn. Một phần mềm dễ mua nhưng khó rời bỏ có thể tạo ra chi phí chuyển đổi lớn trong tương lai.

Doanh nghiệp nên yêu cầu nhà cung cấp mô tả quy trình chấm dứt, thời gian bàn giao dữ liệu, định dạng dữ liệu và mức phí liên quan. Nếu các nội dung này không rõ, rủi ro phụ thuộc nhà cung cấp cần được phản ánh trong mô hình.

Những sai lầm thường làm sai kết quả so sánh

Chỉ so sánh phí tháng hoặc phí năm

Cách này bỏ qua triển khai, dữ liệu, tích hợp, đào tạo, nhân sự nội bộ và rủi ro. Phí thuê bao thấp có thể đi kèm chi phí vận hành cao.

Dùng số lượng tài khoản hiện tại cho toàn bộ vòng đời

Số người dùng, dữ liệu và giao dịch thường thay đổi. Không mô hình hóa tăng trưởng sẽ làm TCO bị đánh giá thấp.

Xem thời gian nhân sự nội bộ là miễn phí

Nhân viên tham gia dự án không tạo ra hóa đơn nhưng vẫn tiêu tốn nguồn lực. Nếu bỏ qua, giải pháp cần nhiều công sức nội bộ sẽ có vẻ rẻ hơn thực tế.

So sánh các phạm vi chức năng khác nhau

Một phần mềm có thể rẻ vì thiếu tính năng, báo cáo, tích hợp hoặc hỗ trợ cần thiết. Phần thiếu phải được chuyển thành chi phí bổ sung hoặc giới hạn sử dụng.

Gộp chi phí chắc chắn với chi phí ước tính

Không phân biệt độ tin cậy của dữ liệu khiến người đọc bảng TCO hiểu sai mức chính xác. Mỗi giả định nên có nguồn và mức độ chắc chắn.

Bỏ qua chi phí duy trì hệ thống cũ

Trong giai đoạn chuyển đổi, doanh nghiệp có thể phải vận hành song song hai hệ thống. Phí bản quyền, hạ tầng và nhân sự của hệ thống cũ cần được tính cho đến khi ngừng hoàn toàn.

Không tính chi phí thoát khỏi phần mềm

Xuất dữ liệu, thay đổi tích hợp, đào tạo lại và duy trì hoạt động trong quá trình chuyển đổi đều có thể phát sinh khi thay nhà cung cấp.

Dùng điểm số để che lấp yêu cầu bắt buộc

Một phần mềm không đáp ứng yêu cầu trọng yếu không nên được giữ lại chỉ vì tổng điểm vẫn cao. Điều kiện bắt buộc phải được kiểm tra trước khi chấm điểm.

Quy trình so sánh chi phí phần mềm doanh nghiệp

Doanh nghiệp có thể thực hiện theo tám bước:

1.    Xác định phạm vi sử dụng và yêu cầu bắt buộc

2.    Chọn khoảng thời gian phân tích thống nhất

3.    Chuẩn hóa giả định về người dùng, dữ liệu và tăng trưởng

4.    Thu thập chi phí trực tiếp từ báo giá và hợp đồng

5.    Ước tính chi phí nội bộ, chi phí gián tiếp và chi phí rủi ro

6.    Lập bảng TCO cho từng năm và từng phương án

7.    Chạy kịch bản cùng phân tích độ nhạy

8.    So sánh TCO với mức độ đáp ứng và giá trị sử dụng

Kết quả cuối cùng không nên chỉ là “phần mềm A rẻ hơn phần mềm B”. Một kết luận hữu ích cần chỉ rõ:

·         Phương án nào có TCO thấp nhất trong kịch bản cơ sở

·         Khoản chi nào tạo ra phần lớn chênh lệch

·         Giả định nào có ảnh hưởng mạnh nhất

·         Rủi ro nào chưa được phản ánh đầy đủ

·         Điều kiện nào có thể làm thay đổi kết luận

·         Phương án nào tạo ra giá trị tốt nhất cho cùng mức chi phí

So sánh chi phí phần mềm doanh nghiệp là bài toán về toàn bộ vòng đời sử dụng, không phải bài toán đọc bảng giá. Doanh nghiệp cần chuẩn hóa phạm vi, tính đủ chi phí trực tiếp và gián tiếp, lượng hóa rủi ro, mô hình hóa tăng trưởng, đồng thời đặt TCO cạnh mức độ đáp ứng thực tế.

Một lựa chọn có giá mua thấp chỉ thực sự tiết kiệm khi nó không chuyển chi phí sang triển khai, vận hành, nhân sự hoặc giai đoạn chấm dứt hợp đồng. Phương án phù hợp nhất là phương án có tổng chi phí có thể kiểm soát, đáp ứng các yêu cầu bắt buộc và tạo ra giá trị sử dụng tốt trong suốt thời gian đánh giá.