ROI của một dự án tự động hoá bằng tổng lợi ích ròng trên vòng đời chia cho tổng chi phí, trong đó cả hai vế phải được tính đầy đủ và trung thực. Công thức thì đơn giản; cái khó nằm ở hai chỗ: phần lớn bản đề xuất bỏ sót chi phí vận hành và bảo trì, đồng thời tính thời gian tiết kiệm như thể đó là tiền mặt. Hai lỗi cùng chiều đó làm ROI trên giấy cao hơn thực tế nhiều lần.
Một bản tính đáng tin phải trả lời ba câu: chi phí trên toàn vòng đời là bao nhiêu (không chỉ chi phí xây), lợi ích nào là tiền thật và lợi ích nào là năng lực được giải phóng, và các giả định nhạy đến mức nào — nếu khối lượng thấp hơn dự kiến một phần ba thì dự án còn đáng làm không.
Bài này đi qua cấu trúc chi phí, các loại lợi ích, một phép tính mẫu ba năm có ghi rõ giả định, cách làm phân tích độ nhạy, và cách đo sau triển khai để biết dự án có thực sự đạt như đã hứa.
Chi phí đầy đủ trên vòng đời
Tổng chi phí sở hữu (TCO) chia thành chi phí một lần và chi phí định kỳ. Cột cuối chỉ ra khoản hay bị bỏ sót.
| Nhóm | Khoản chi phí | Hay bị bỏ sót vì |
|---|---|---|
| Một lần | Đánh giá, ghi chép và thiết kế lại quy trình | Được coi là "việc nội bộ", không tính giờ công |
| Một lần | Xây dựng, kiểm thử, chạy song song | Chỉ tính công lập trình, quên công người nghiệp vụ tham gia kiểm thử |
| Một lần | Hạ tầng: máy chủ, máy ảo, môi trường thử | Tưởng dùng chung hạ tầng sẵn có là miễn phí |
| Một lần | Đào tạo người dùng và quản lý thay đổi | Không ai lập ngân sách cho phần con người |
| Định kỳ | Giấy phép phần mềm, bộ kết nối, dịch vụ đám mây | Giá thay đổi khi gia hạn hoặc khi tăng quy mô |
| Định kỳ | Giám sát và vận hành hằng ngày | Giả định bot "tự chạy" |
| Định kỳ | Bảo trì khi hệ thống nguồn thay đổi | Không dự báo được nên bị bỏ qua |
| Định kỳ | Người xử lý ngoại lệ bot chuyển lại | Coi tỷ lệ ngoại lệ bằng không |
| Định kỳ | Quản trị: danh mục bot, kiểm soát truy cập, kiểm toán | Chi phí chung, không gán cho dự án nào |
Một cách thực dụng để ước chi phí bảo trì khi chưa có dữ liệu lịch sử: hỏi bộ phận CNTT các hệ thống mà bot đi qua cập nhật giao diện bao nhiêu lần mỗi năm, nhân với số giờ sửa trung bình mỗi lần, cộng thêm biên an toàn. Sau một năm vận hành, thay bằng số thật.
Bốn loại lợi ích và cách quy đổi
Lợi ích tiền mặt trực tiếp. Giảm chi phí thuê ngoài, giảm làm thêm giờ, không phải tuyển thêm người dù khối lượng tăng, giảm tiền phạt chậm nộp. Đây là phần duy nhất chắc chắn đi vào báo cáo lãi lỗ, và cũng là phần ban giám đốc tài chính tin nhất.
Năng lực được giải phóng. Giờ công tiết kiệm nhưng người vẫn ở lại. Năng lực này có giá trị khi được chuyển sang việc tạo ra kết quả đo được — chăm sóc khách hàng lớn, phân tích, bán thêm — và cần có kế hoạch cụ thể cho việc chuyển đổi đó. Nếu không có kế hoạch, thời gian được giải phóng thường tan vào các việc nhỏ khác và không để lại dấu vết.
Giảm sai sót và rủi ro. Ít lỗi nhập liệu, ít khiếu nại, ít điều chỉnh sau kiểm toán. Quy đổi bằng: số lỗi trước đây × chi phí trung bình xử lý một lỗi, cộng chi phí hậu quả nếu có số liệu. Phần này thường bị đánh giá thấp vì chi phí sửa lỗi nằm rải rác ở nhiều bộ phận.
Tốc độ và trải nghiệm. Rút thời gian xử lý hồ sơ từ ba ngày xuống vài giờ có thể tăng tỷ lệ khách quay lại, giảm vốn lưu động bị giữ, giúp đóng sổ nhanh hơn. Khó quy đổi chính xác; nên trình bày riêng như lợi ích định tính có chỉ số kèm theo, đừng trộn vào con số ROI chính.
Phép tính mẫu ba năm
Ví dụ giả định — một công ty phân phối cân nhắc tự động hoá việc nhập đơn đặt hàng từ cổng thông tin của các đại lý vào phần mềm bán hàng. Số đo hiện trạng: khoảng 6.000 đơn mỗi tháng, trung bình 4 phút mỗi đơn, tức 400 giờ công mỗi tháng. Tỷ lệ đơn có ngoại lệ phải xử lý tay ước 12%, mỗi đơn ngoại lệ vẫn tốn khoảng 5 phút sau tự động hoá. Chi phí một giờ công đầy đủ (lương, bảo hiểm, chi phí văn phòng) giả định 100.000 đồng. Ba năm trong phép tính được đếm từ lúc bot chạy thật; giai đoạn xây và chạy song song chỉ tính vào chi phí một lần.
Lợi ích giờ công mỗi tháng: 88% đơn chạy thẳng tiết kiệm 5.280 × 4 = 21.120 phút, tức 352 giờ; trừ thời gian giám sát và xử lý ngoại lệ phát sinh mới khoảng 20 giờ, còn khoảng 332 giờ, tương đương 33,2 triệu đồng mỗi tháng nếu quy đổi hết ra tiền, khoảng 398 triệu mỗi năm. Nhưng công ty chỉ dự kiến không tuyển thay hai vị trí sắp nghỉ (giả định 2 × 15 triệu × 12 tháng = 360 triệu chi phí đầy đủ mỗi năm); phần còn lại là năng lực giải phóng, được ghi riêng.
Chi phí: một lần 250 triệu (đánh giá, xây, kiểm thử, chạy song song, đào tạo); định kỳ 120 triệu mỗi năm (giấy phép, hạ tầng, giám sát, bảo trì). Ba năm: tổng chi phí 250 + 3 × 120 = 610 triệu. Lợi ích tiền mặt ba năm: 3 × 360 = 1.080 triệu. Lợi ích ròng: 470 triệu. ROI tiền mặt ba năm ≈ 470 / 610 ≈ 77%. Thời gian hoàn vốn: lợi ích ròng hằng năm 360 − 120 = 240 triệu, nên 250 / 240 ≈ hơn một năm một chút.
Nếu ghép cả năng lực giải phóng vào (quy đổi hết 332 giờ ra tiền), ROI sẽ đẹp hơn hẳn — đó chính là con số hay xuất hiện trong bản chào hàng. Bản tính trung thực trình bày cả hai, ghi rõ con số nào là tiền thật. Nếu quan tâm đến giá trị thời gian của tiền, hãy chiết khấu dòng tiền ba năm theo chi phí vốn của doanh nghiệp để ra giá trị hiện tại ròng (NPV); với dự án ngắn và chi phí vốn vừa phải, kết luận thường không đổi nhưng con số sẽ thận trọng hơn.
Phân tích độ nhạy: giả định nào làm đổi kết luận
Giữ nguyên ví dụ trên, thay từng giả định để xem lợi ích ròng ba năm thay đổi thế nào (ví dụ giả định, số làm tròn).
| Kịch bản | Thay đổi | Lợi ích ròng 3 năm | Kết luận |
|---|---|---|---|
| Cơ sở | Như trên | Khoảng 470 triệu | Đáng làm |
| Chỉ giữ được một vị trí không tuyển thay | Lợi ích tiền mặt giảm một nửa | Khoảng −70 triệu | Không hoàn vốn bằng tiền mặt |
| Bảo trì gấp đôi dự kiến | Chi phí định kỳ 180 triệu | Khoảng 290 triệu | Vẫn đáng làm |
| Chi phí xây vượt 50% | Chi phí một lần 375 triệu | Khoảng 345 triệu | Vẫn đáng làm |
| Đổi phần mềm bán hàng sau 18 tháng | Bot phải gỡ, lợi ích và chi phí định kỳ chỉ còn 1,5 năm | Khoảng 110 triệu | Lãi mỏng, rủi ro cao |
Bảng cho thấy giả định quan trọng nhất không phải chi phí kỹ thuật mà là quyết định nhân sự và độ ổn định của hệ thống. Đó là hai câu hỏi phải có câu trả lời của lãnh đạo và bộ phận CNTT trước khi phê duyệt, không phải sau.
ROI ở cấp danh mục, không chỉ từng bot
Khi doanh nghiệp đã có nhiều quy trình tự động hoá, tính ROI cho từng bot riêng lẻ bắt đầu gây méo. Bot đầu tiên phải gánh chi phí dựng nền tảng, thiết lập bộ điều phối, đào tạo đội ngũ, viết quy chuẩn; nếu tính riêng, nó có thể trông lỗ, trong khi bot thứ mười tận dụng toàn bộ nền đó và trông lãi rất đẹp. Cả hai con số đều không phản ánh đúng giá trị.
Cách trung thực hơn là quản lý như một danh mục đầu tư: chi phí nền tảng và đội ngũ chung được tính ở cấp chương trình; mỗi quy trình được đánh giá theo chi phí biên (công xây, giấy phép tăng thêm, bảo trì riêng) và lợi ích riêng. Báo cáo cấp chương trình cộng tất cả lại, cho thấy tổng chi phí, tổng lợi ích tiền mặt, tổng năng lực giải phóng và xu hướng theo quý.
Cách nhìn danh mục còn giúp ra một quyết định khó: gỡ bot. Một bot có chi phí bảo trì vượt lợi ích, hoặc phục vụ quy trình đã thu hẹp, nên được gỡ thay vì giữ vì "đã lỡ đầu tư". Chi phí đã bỏ ra là chi phí chìm; quyết định chỉ nên dựa trên chi phí và lợi ích từ nay về sau.
Đo sau triển khai: biết dự án có đạt như đã hứa
Bản tính ROI chỉ có giá trị nếu được đối chiếu với thực tế. Một quy trình đo đơn giản:
- Chụp đường cơ sở trước khi triển khai: khối lượng, thời gian mỗi giao dịch, tỷ lệ lỗi, thời gian chu trình, số giờ làm thêm. Không có đường cơ sở thì sau này không chứng minh được gì.
- Định nghĩa chỉ số vận hành của bot: số giao dịch xử lý, tỷ lệ chạy thẳng không cần người, tỷ lệ ngoại lệ theo loại, số lần dừng và thời gian khôi phục.
- Ghi chi phí thật hằng tháng, kể cả giờ công giám sát và sửa lỗi, vào một mã chi phí riêng của dự án.
- Rà soát ở mốc ba tháng, sáu tháng và mười hai tháng, so với bản đề xuất ban đầu; ghi lại giả định nào lệch và vì sao.
- Kiểm việc chuyển đổi năng lực: thời gian được giải phóng đã được dùng vào đâu, kết quả đo được là gì.
- Dùng số thật để hiệu chỉnh các bản đề xuất tiếp theo: tỷ lệ bảo trì, tỷ lệ ngoại lệ thực tế, thời gian xây trung bình.
Theo thời gian, chính kho số liệu này là tài sản quý nhất của một chương trình tự động hoá: nó biến việc ước tính từ phỏng đoán thành dự báo có căn cứ.
Các lỗi phổ biến khi trình bày ROI
Hội đồng phê duyệt có kinh nghiệm thường hỏi ngay những điểm sau; chuẩn bị sẵn câu trả lời giúp bản đề xuất đáng tin hơn:
- Đổi giờ công ra số người ("tiết kiệm 2,1 FTE") rồi ngầm coi là cắt giảm được 2,1 người, trong khi phần tiết kiệm rải ở mười người, mỗi người vài giờ mỗi tuần.
- Dùng khối lượng tháng cao điểm làm khối lượng trung bình.
- Bỏ qua thời gian xây dựng: lợi ích tính từ tháng đầu tiên trong khi bot chỉ chạy thật từ tháng thứ tư.
- Tính lợi ích tốc độ, trải nghiệm bằng con số chính xác không có căn cứ, làm cả bản tính mất uy tín.
- Không có kịch bản xấu: chỉ trình bày một con số, không phân tích độ nhạy.
- Tính một bot riêng lẻ mà bỏ chi phí nền tảng chung: bot đầu tiên phải gánh phần lớn chi phí xây nền, các bot sau rẻ hơn; trình bày theo danh mục sẽ trung thực hơn.
Câu hỏi thường gặp
Nên dùng ROI hay thời gian hoàn vốn để ra quyết định?
Nên trình bày cả hai, kèm NPV nếu dự án dài hơn hai năm. Thời gian hoàn vốn dễ hiểu và phản ánh rủi ro: dự án hoàn vốn trong một năm ít phụ thuộc vào giả định dài hạn. ROI phản ánh quy mô lợi ích. Với dự án tự động hoá, thời gian hoàn vốn ngắn quan trọng vì hệ thống nguồn có thể thay đổi.
Có nên tính lợi ích tinh thần nhân viên vào ROI không?
Không nên đưa vào con số chính vì khó đo và dễ bị coi là thổi phồng. Hãy trình bày như lợi ích định tính có chỉ số theo dõi, ví dụ tỷ lệ nghỉ việc ở bộ phận, kết quả khảo sát nội bộ trước và sau. Nếu sau một năm số liệu cải thiện rõ, đó là bằng chứng tốt cho các dự án sau.
Chi phí giờ công đầy đủ được tính thế nào?
Thường gồm lương, các khoản bảo hiểm và phúc lợi doanh nghiệp đóng, cộng phần phân bổ chi phí văn phòng, thiết bị, quản lý. Bộ phận tài chính nên đưa ra một con số chuẩn cho từng nhóm vị trí để mọi bản đề xuất dùng chung, tránh mỗi dự án tự chọn con số có lợi cho mình.
Dự án ROI âm có bao giờ đáng làm không?
Có, khi mục tiêu chính là tuân thủ, giảm rủi ro hoặc đáp ứng khối lượng tăng mà không tuyển kịp. Ví dụ quy trình mà một lỗi có thể gây hậu quả pháp lý lớn. Khi đó hãy trình bày rõ đây là chi phí giảm rủi ro, nêu kịch bản rủi ro được tránh, thay vì cố ép ROI dương bằng giả định lạc quan.
Bao lâu thì nên đánh giá lại một bot đang chạy?
Ít nhất mỗi năm một lần, hoặc ngay khi hệ thống nguồn có kế hoạch thay đổi lớn. Câu hỏi rà soát gồm: khối lượng còn như dự kiến không, chi phí bảo trì thực tế bao nhiêu, có cách thay thế bền hơn như tích hợp hay tính năng mới của phần mềm không, và bot có còn phục vụ quy trình đang dùng không.