Trả lời nhanh: Đo ROI tự động hoá là so sánh lợi ích đã quy đổi ra tiền với tổng chi phí sở hữu (TCO) của bot, theo công thức (lợi ích − TCO) / TCO. Muốn con số đáng tin, bạn phải chốt số liệu trước khi build, tính chi phí bảo trì nhiều năm và đo lại sau khi bot chạy thật.
Điểm chính
- ROI chỉ có nghĩa khi có baseline “trước” đo bằng dữ liệu thật của quy trình.
- TCO gồm giấy phép, phát triển, hạ tầng, bảo trì bot và người giám sát, không chỉ giá phần mềm.
- Giờ công giải phóng chưa phải tiền. Chỉ tính thành tiền phần giờ thật sự giảm chi phí hoặc tránh được chi phí.
- Tỷ lệ xử lý trọn gói (không cần người can thiệp) là biến nhạy nhất của ROI.
- Benchmark của nhà cung cấp chỉ để tham khảo, không thay được số liệu quy trình của bạn.
Mục lục
- ROI tự động hoá khác gì ROI của một khoản đầu tư thông thường?
- Quy trình 5 bước để đo ROI
- Bước 1: Chốt baseline như thế nào cho đáng tin?
- Bước 2: TCO của bot gồm những khoản nào?
- Bước 3: Lợi ích nào quy đổi được thành tiền?
- Ví dụ minh hoạ: ROI của bot đối chiếu hoá đơn
- Sau go-live nên theo dõi những chỉ số nào?
- Lịch đo lại: khi nào và đo gì?
- Khi nào FTE không phải thước đo phù hợp?
- Những lỗi làm ROI bị thổi phồng
- Mẫu trình bày ROI cho ban giám đốc
- Câu hỏi thường gặp
ROI tự động hoá khác gì ROI của một khoản đầu tư thông thường?
Công thức nền là: ROI = (tổng lợi ích − TCO) / TCO. Thời gian hoàn vốn (payback) là số tháng để lợi ích tích luỹ bù hết khoản chi ban đầu. Với RPA, hai điểm làm phép tính khác máy móc thông thường:
- Lợi ích đến từ quy trình, không từ phần mềm. Bot chạy tốt trên quy trình chỉ có 20 ca mỗi tháng thì ROI vẫn thấp. Cùng một bot, ROI có thể chênh nhau nhiều lần giữa hai quy trình.
- Chi phí chạy tiếp không dừng sau go-live. Khi giao diện ứng dụng đổi, biểu mẫu thêm cột hay chứng thư số hết hạn, bot hỏng và phải sửa. Khoản này nằm trong TCO.
Trong giới nghiên cứu RPA, chỉ số phổ biến nhất từ đầu là số giờ làm việc quy đương toàn thời gian (FTE) tiết kiệm được, và ROI thường được suy ra từ đó. Các nghiên cứu mô tả FTE-hours saved là KPI thông dụng nhất của bot RPA, từ đó người ta tính ROI. Cách này dễ làm nhưng dễ sai. Các phần sau chỉ ra chỗ sai và cách tránh.
Nếu bạn còn đang chọn quy trình để làm, hãy xem trước bài về quy trình nên tự động hoá bằng RPA. Bài này giả định bạn đã có một quy trình ứng viên.
Quy trình 5 bước để đo ROI
Thứ tự dưới đây cho phép bạn kiểm tra từng con số trước khi sang bước sau.
Bước 1: Chốt baseline như thế nào cho đáng tin?
Baseline là bộ số đo của quy trình khi còn làm tay. Không có nó thì mọi con số “sau” đều bị tranh cãi. Nên ghi nhận khối lượng, thời gian xử lý, tỷ lệ lỗi và số FTE của quy trình sẽ tự động hoá. Chi tiết cho từng chỉ số:
- Khối lượng: số giao dịch mỗi tháng, tách theo mùa vụ. Quy trình đối chiếu cuối tháng và quy trình chạy đều quanh năm cho ROI rất khác nhau.
- Thời gian xử lý mỗi giao dịch (AHT): bấm giờ thật ở 20–30 giao dịch, ghi riêng ca dễ và ca khó. Đừng lấy con số “khoảng 5 phút” do người phụ trách ước lượng.
- Tỷ lệ ngoại lệ: bao nhiêu phần trăm giao dịch phải có người quyết định (thiếu chứng từ, sai định dạng, khách hàng đặc biệt). Đây là số quyết định bot xử lý trọn gói được bao nhiêu.
- Tỷ lệ lỗi và công sửa lỗi: số giao dịch phải làm lại mỗi tháng và thời gian trung bình để sửa mỗi ca.
- Thời gian chờ giữa các bước: thời gian hồ sơ nằm trong hộp thư hay hàng đợi, thường lớn hơn thời gian thao tác.
Nếu quy trình có nhật ký hệ thống, dùng process mining từ event log để lấy thời gian từng bước và tỷ lệ ngoại lệ thay vì bấm giờ tay. Nếu chưa có nhật ký, bấm giờ mẫu nhỏ vẫn dùng được, miễn là ghi rõ mẫu lấy ở tuần nào và do ai làm.
Với giờ công, hãy dùng chi phí đầy đủ của một giờ làm việc: lương, bảo hiểm bắt buộc, phụ cấp, phần chi phí chỗ ngồi và thiết bị. Chia cho số giờ làm việc thực tế trong tháng, không chia cho 24 giờ.
Bước 2: TCO của bot gồm những khoản nào?
Lỗi hay gặp nhất là chỉ cộng giá giấy phép. Bảng dưới đây liệt kê các khoản cần có trong mô hình tính, kèm cách ước lượng.
| Khoản chi | Tính một lần hay lặp lại | Cách ước lượng |
|---|---|---|
| Giấy phép bot, orchestrator | Hằng năm | Theo báo giá của nhà cung cấp, ghi rõ loại bot (attended hay unattended) |
| Phân tích và phát triển bot | Một lần | Số ngày công của nhà phát triển và nhà phân tích nghiệp vụ nhân với giá ngày công |
| Kiểm thử và nghiệm thu (UAT) | Một lần | Giờ công của người dùng nghiệp vụ tham gia kiểm thử |
| Máy ảo, tài khoản robot, kết nối | Hằng năm | Chi phí máy chủ hoặc cloud, tài khoản dịch vụ cho bot |
| Bảo trì và sửa bot | Hằng năm | Số lần hỏng dự kiến nhân với giờ sửa trung bình |
| Người giám sát và xử lý ngoại lệ | Hằng năm | Phần FTE dành cho theo dõi bot, tính theo giờ thực |
| Đào tạo và quản trị thay đổi | Một lần, có phần lặp | Giờ đào tạo nhân viên của quy trình |
Về tỷ trọng, một số tài liệu của nhà cung cấp đưa ra con số. Automation Anywhere cho rằng chi phí triển khai, hạ tầng, quản trị thay đổi và bảo trì thường gấp 2–4 lần phí giấy phép trong năm đầu. Một blog khác khuyến nghị dự phòng 15–20% chi phí phát triển ban đầu mỗi năm cho cập nhật bot. Cả hai là ước lượng của bên bán dịch vụ, không phải thống kê độc lập. Bạn nên coi chúng là khoảng để kiểm tra mô hình của mình, rồi thay bằng số của doanh nghiệp sau 2–3 quý chạy thực tế. Khung chi phí rộng hơn nằm trong bài chi phí triển khai RPA.
Bước 3: Lợi ích nào quy đổi được thành tiền?
Hãy tách lợi ích thành hai nhóm theo mức độ chắc chắn của việc quy đổi.
Giờ công là chỗ dễ sai nhất. Bot lấy đi 280 giờ làm việc mỗi tháng chỉ thành tiền khi một trong ba điều xảy ra: bạn giảm giờ tăng ca hoặc thuê ngoài, bạn không phải tuyển thêm khi khối lượng tăng, hoặc nhân viên chuyển sang việc tạo ra doanh thu hoặc tránh được chi phí khác. Nếu giờ đó rải đều cho 8 người, mỗi người rảnh thêm 35 giờ và không ai đổi việc, thì lợi ích tài chính bằng không dù báo cáo vẫn ghi “tiết kiệm 280 giờ”. Automation Anywhere cũng cảnh báo chuyện đếm trùng, và gợi ý tách giá trị người được bố trí lại khỏi phần giảm biên chế. Cách tách này dễ giải thích với ban giám đốc, đồng thời tránh biến ROI thành câu chuyện cắt giảm nhân sự. Câu hỏi này liên quan trực tiếp đến bài tự động hoá có thay thế con người.
Giảm lỗi chỉ tính khi bạn có số lỗi thật ở baseline. Giá trị gồm công sửa lỗi, tiền phạt trễ hạn, phí chậm thanh toán hoặc hàng trả lại, tuỳ quy trình.
Tăng tốc độ có giá trị khi tốc độ gắn với dòng tiền hoặc cam kết dịch vụ. Ví dụ, đối chiếu công nợ xong sớm 3 ngày thì có thể thu tiền sớm hơn. Còn khi báo cáo nội bộ nhanh hơn mà không ai dùng sớm hơn, giá trị này bằng không.
Ví dụ minh hoạ: ROI của bot đối chiếu hoá đơn
Đây là ví dụ minh hoạ với số giả định để bạn thấy cách tính. Không phải kết quả của doanh nghiệp thật và không dùng làm benchmark.
Một phòng kế toán công nợ đối chiếu hoá đơn đầu vào với đơn mua hàng và phiếu nhập kho.
Baseline (đo 4 tuần):
- 4.000 hoá đơn mỗi tháng, mỗi hoá đơn 6 phút, tức 400 giờ mỗi tháng.
- 3% hoá đơn phải làm lại (120 hoá đơn), mỗi ca 30 phút, tức 60 giờ mỗi tháng.
- Chi phí đầy đủ một giờ làm việc: 150.000 đồng.
Sau khi chạy thử: bot xử lý trọn gói 70% hoá đơn (2.800 hoá đơn), 30% còn lại vẫn do người xử lý. Tỷ lệ làm lại giảm còn 1%.
Lợi ích hằng năm:
- Giờ giảm: 2.800 × 6 phút = 280 giờ mỗi tháng, tương đương 42 triệu đồng mỗi tháng, tức 504 triệu đồng mỗi năm.
- Công sửa lỗi: giảm từ 60 xuống 20 giờ, tức 40 giờ × 150.000 = 6 triệu đồng mỗi tháng, tức 72 triệu đồng mỗi năm.
- Tổng: 576 triệu đồng mỗi năm.
Chi phí:
- Phát triển và nghiệm thu: 150 triệu đồng, một lần.
- Giấy phép: 120 triệu đồng mỗi năm.
- Máy ảo và hạ tầng: 24 triệu đồng mỗi năm.
- Bảo trì bot: 30 triệu đồng mỗi năm (20% chi phí phát triển, giả định).
- Giám sát, 0,1 FTE: 30 triệu đồng mỗi năm.
| Chỉ tiêu | Năm 1 | Năm 2 |
|---|---|---|
| Lợi ích | 576 triệu | 576 triệu |
| TCO | 354 triệu | 204 triệu |
| ROI | khoảng 63% | khoảng 182% |
| ROI cộng dồn 2 năm | khoảng 106% | |
Hoàn vốn: lợi ích mỗi tháng là 48 triệu đồng, chi phí chạy mỗi tháng khoảng 17 triệu đồng, nên phần ròng khoảng 31 triệu đồng mỗi tháng. Khoản 150 triệu ban đầu được bù sau khoảng 5 tháng kể từ go-live.
Phân tích độ nhạy. Giả sử tỷ lệ xử lý trọn gói chỉ đạt 50% thay vì 70%. Giờ giảm còn 200 giờ mỗi tháng, tổng lợi ích còn khoảng 432 triệu đồng mỗi năm, và ROI năm 1 chỉ còn khoảng 22%. Tỷ lệ ngoại lệ vì vậy đáng được đo kỹ hơn cả giá giấy phép. Hãy tính cả kịch bản xấu, kịch bản cơ sở và kịch bản tốt trước khi đưa con số lên ban giám đốc.
Sau go-live nên theo dõi những chỉ số nào?
ROI tính trước là dự báo. Muốn biết dự báo có đúng, bạn cần các chỉ số vận hành của bot. Phần lớn nền tảng RPA có sẵn nhật ký chạy từ bảng điều khiển orchestrator để lấy số liệu.
| Chỉ số | Cách tính | Cho biết điều gì |
|---|---|---|
| Tỷ lệ xử lý trọn gói | Giao dịch bot xong không cần người / tổng giao dịch | Biến nhạy nhất của lợi ích |
| Tỷ lệ ngoại lệ và nguyên nhân | Số ca chuyển cho người, phân theo lý do | Chỗ nào còn có thể mở rộng quy tắc |
| Số lần hỏng (break-fix cycles) | Số lần bot dừng và phải sửa | Mức độ mong manh của bot |
| Giờ sửa mỗi lần hỏng | Tổng giờ công sửa / số lần hỏng | Chi phí bảo trì thật so với dự phòng |
| Nguyên nhân gốc của lỗi | Phân loại: đổi giao diện, dữ liệu đầu vào sai, hết quyền truy cập | Việc cần sửa ở quy trình, không chỉ ở bot |
| Mức sử dụng | Số giờ bot chạy thật / số giờ có thể chạy | Giấy phép có đang bị bỏ phí không |
Bộ chỉ số về lần hỏng và giờ sửa lấy từ một tài liệu của Blueprint: bot hỏng nghĩa là không còn chạy, nên không giảm chi phí và ảnh hưởng thẳng đến ROI. Đây là lý do mô hình ROI cần cột “giờ sửa bot”, không chỉ cột lợi ích.
Khi có nhiều bot, nên gom việc đo này vào một đầu mối chung. Mô hình đó được mô tả trong bài về trung tâm CoE tự động hoá.
Lịch đo lại: khi nào và đo gì?
Ở mốc 30 ngày, bạn so tỷ lệ xử lý trọn gói thật với giả định trong mô hình. Nếu thấp hơn nhiều, hãy xem bảng nguyên nhân ngoại lệ trước khi kết luận bot kém. Thường lỗi nằm ở dữ liệu đầu vào hoặc quy tắc chưa đủ. Mô hình ROI nên có một dòng riêng ghi “giả định” và một dòng “thực tế” cho mỗi tham số, để từng quý ai cũng thấy chênh lệch. Automation Anywhere cũng khuyến nghị đo lại ROI mỗi quý khi phạm vi bot và độ chín của quy trình thay đổi.
Khi nào FTE không phải thước đo phù hợp?
Phương pháp quy đổi FTE phù hợp nhất với trung tâm xử lý khối lượng lớn. Một bài phân tích của IT Convergence cho rằng cách này hợp lý ở tổ chức có trung tâm dịch vụ chia sẻ lớn, nơi nhiều người cùng làm một hoạt động. Nhưng ở phòng ban nhỏ, mỗi người mất 15–20 phút mỗi ngày cho một việc lặp, bot không bớt được một vị trí nào. Khi đó có ba cách đo thay thế:
- Chi phí tránh được: khối lượng tăng 30% mà không phải tuyển thêm. Cần có kế hoạch tăng trưởng làm căn cứ.
- Thời gian chu kỳ: hồ sơ từ lúc nhận đến lúc xong. Giá trị quy đổi qua dòng tiền hoặc mức độ đạt cam kết dịch vụ (SLA).
- Chất lượng đầu ra: số ca sai phải sửa, số lần bị trả hồ sơ, số khiếu nại.
Những quy trình có dữ liệu hay việc lặp rõ ràng như kế toán, nhân sự hoặc logistics thường có sẵn các chỉ số này. Bài về lợi ích của RPA liệt kê các nhóm lợi ích mà bạn có thể chọn làm thước đo chính.
Những lỗi làm ROI bị thổi phồng
- Chọn baseline sau khi đã build. Người làm quy trình biết bot sắp chạy nên làm chậm lại hoặc đếm lại theo cách khác. Hãy đo trước, ghi ngày đo và người đo.
- Coi 100% giao dịch là xử lý trọn gói. Đưa tỷ lệ ngoại lệ thực vào mô hình, như ví dụ ở trên.
- Không tính giờ làm lại do bot sai. Một lô hoá đơn nhập sai cần người rà soát toàn bộ, tốn công hơn làm tay từ đầu.
- Đếm hai lần. Giờ tiết kiệm vừa được tính là “giảm lao động”, vừa được tính là “năng suất tăng”.
- Dùng benchmark nước ngoài làm kỳ vọng. Số liệu như ROI trung bình khoảng 250% và hoàn vốn 6–9 tháng xuất hiện trong tài liệu của nhà cung cấp, nhưng tiền lương và quy mô giao dịch ở Việt Nam khác. Một bài khác trích lại khảo sát McKinsey rằng ROI năm đầu dao động từ 30 đến 200%. Khoảng rộng đó cho thấy kết quả phụ thuộc mạnh vào quy trình bạn chọn.
- Chỉ đo một lần lúc nghiệm thu. Bot sau 6 tháng có thể ở trạng thái khác hẳn: giao diện đã đổi, số ngoại lệ đã tăng.
Mẫu trình bày ROI cho ban giám đốc
Một trang là đủ nếu có các mục sau, mỗi mục một dòng hoặc một bảng nhỏ:
- Quy trình, phạm vi và thời điểm đo baseline.
- Bảng baseline: khối lượng, AHT, tỷ lệ ngoại lệ, tỷ lệ lỗi, chi phí đầy đủ một giờ làm việc.
- TCO theo năm 1, 2, 3, tách khoản một lần và khoản lặp lại.
- Lợi ích tách hai cột: quy đổi trực tiếp và quy đổi gián tiếp.
- ROI và thời gian hoàn vốn ở ba kịch bản (xấu, cơ sở, tốt), kèm giả định thay đổi giữa các kịch bản.
- Ngày đo lại và người chịu trách nhiệm cập nhật số.
Nếu bạn đang đặt quy trình này vào bức tranh rộng hơn như BPA hay nhiều bot cùng chạy, hãy đối chiếu với bài tự động hoá quy trình là gì để thống nhất thuật ngữ trước khi lập báo cáo.
Câu hỏi thường gặp
Đo ROI tự động hoá nên bắt đầu từ đâu?
Bắt đầu từ baseline: khối lượng, thời gian xử lý, tỷ lệ ngoại lệ, tỷ lệ lỗi và chi phí đầy đủ một giờ làm việc. Có các số này rồi bạn mới tính được lợi ích. Thiếu chúng thì mọi con số sau go-live đều khó chứng minh.
Công thức ROI RPA cơ bản là gì?
ROI = (tổng lợi ích − TCO) / TCO, thường nhân 100% để ra phần trăm. Nên tính theo từng năm vì TCO năm đầu có chi phí phát triển, còn các năm sau chủ yếu là giấy phép, hạ tầng, bảo trì và giám sát. Thời gian hoàn vốn tính riêng bằng cách chia khoản chi ban đầu cho lợi ích ròng mỗi tháng.
Giờ công tiết kiệm có tính hết thành tiền được không?
Không. Chỉ phần giờ thật sự làm giảm chi phí hoặc tránh được chi phí mới tính vào lợi ích trực tiếp, ví dụ giảm tăng ca hoặc không phải tuyển thêm khi khối lượng tăng. Phần giờ chuyển sang việc khác nên ghi ở cột lợi ích gián tiếp, kèm giả định rõ ràng.
Bao lâu thì bot hoàn vốn?
Phụ thuộc vào khối lượng, tỷ lệ xử lý trọn gói và chi phí phát triển của quy trình. Tài liệu của nhà cung cấp thường nêu khoảng 6–9 tháng, nhưng đó là con số tham khảo, không phải cam kết. Hãy tự tính cho quy trình của bạn và kiểm chứng lại ở mốc 30 ngày và mỗi quý.
Có nên tính cả chi phí bảo trì bot vào ROI không?
Có. Bảo trì và giờ sửa bot là chi phí lặp lại hằng năm. Nếu bỏ đi, ROI sẽ cao hơn thực tế, nhất là với bot chạy trên giao diện của ứng dụng hay thay đổi. Hãy theo dõi số lần hỏng và giờ sửa để thay giả định bằng số liệu thật.
Nên chọn quy trình nào để đo ROI đầu tiên?
Chọn quy trình có khối lượng lớn, quy tắc rõ, dữ liệu có sẵn để làm baseline và người dùng kết quả cụ thể. Kế toán công nợ, đối chiếu và nhập liệu từ chứng từ thường thoả điều kiện này. Tiêu chí lựa chọn chi tiết có trong bài về quy trình nên tự động hoá ở phần trên.
Bài viết thuộc chuyên mục RPA & tự động hoá quy trình trên VBPO, trang tin tức và kiến thức công nghệ cho doanh nghiệp Việt Nam về AI, dữ liệu, blockchain, chuyển đổi số và tự động hoá.