Đo ROI cho khách hàng: đếm việc đạt chuẩn, trừ công kiểm tra và sửa lỗi

Ba tháng sau khi hệ thống lên production, buổi review hằng quý có thêm một người lạ: giám đốc tài chính của khách hàng. Bà ấy không hỏi dùng model gì hay latency bao nhiêu. Bà chỉ hỏi đúng một câu: “Dự án này có đáng số tiền chúng tôi đã bỏ ra không?”

Nếu lúc đó trong tay bạn chỉ có ảnh chụp dashboard và vài lời khen của người dùng, coi như dự án đã thua nửa trận. FDE không được trả lương để giao tính năng.

Bản mô tả công việc Forward Deployed Enablement Engineer của Palantir viết thẳng rằng vai trò này tồn tại để tối đa hóa kết quả của sản phẩm và workflow đã triển khai, gắn với những kết quả kinh doanh quan trọng nhất của khách hàng.

Vì thế đo ROI không phải việc riêng của sales hay phòng tài chính. Đó là một kỹ năng kỹ thuật: cần dữ liệu, cần thiết kế phép đo và cần trung thực. Cách làm dưới đây đi theo một dây chuyền xử lý hóa đơn, từ baseline đến con số cuối cùng đặt trước mặt CFO.

Vì sao không tin được cảm giác “nhanh hơn”?

Cái bẫy đầu tiên là đi hỏi người dùng. Năm 2025, METR làm một thử nghiệm ngẫu nhiên có đối chứng với các lập trình viên open-source giàu kinh nghiệm. Kết quả: khi dùng công cụ AI, họ mất thời gian nhiều hơn 19% so với khi không dùng.

Chi tiết đáng chú ý nằm ở phần sau. Trước thử nghiệm, những người này kỳ vọng mình sẽ nhanh hơn. Sau thử nghiệm, dù số đo nói ngược lại, họ vẫn tin AI đã giúp mình nhanh hơn 20%.

Hai con số này không dùng chung một thước đo: một bên là thời gian làm thêm đo được, một bên là mức tăng tốc người dùng tin là có. Nhưng chúng chỉ về hai hướng ngược nhau, và đó mới là điều đáng lo.

Bài học cho FDE rất rõ: khảo sát kiểu “anh chị thấy tiết kiệm bao nhiêu thời gian?” chỉ giúp hiểu trải nghiệm người dùng, không dùng làm bằng chứng tài chính được. Thứ bạn đưa cho CFO phải là thời gian đo được trên từng tác vụ, có số trước và số sau.

Bắt đầu từ mục tiêu và baseline, không phải từ model

Paul Parks của AICPA & CIMA, viết trên Journal of Accountancy, đề xuất quy trình tính ROI bắt đầu bằng việc xác định mục tiêu: use case là gì và ban lãnh đạo muốn đạt điều gì với khoản đầu tư này. Khung của ông tính cả những lợi ích không quy ra tiền được.

Với FDE, đây chính là customer discovery: trước khi viết dòng code nào, bạn cần biết khách sẽ đánh giá thành công bằng con số nào.

Bước tiếp theo là baseline. Delos khuyên dành 30 ngày đầu của một khung 90 ngày để thiết lập các chỉ số nền, trước khi báo cáo bất kỳ con số ROI nào. Lý do rất đơn giản: không đo trạng thái “trước” thì không có gì để so với “sau”.

Đợi hệ thống chạy rồi mới đi tìm baseline thì thường đã quá muộn, vì quy trình cũ không còn nữa.

Parks cũng chỉ ra rằng phía lợi ích vốn khó đo, vì hầu hết tổ chức chạy nhiều dự án song song. Số hóa đơn xử lý được tăng lên có thể là nhờ hệ thống của bạn, cũng có thể vì phòng kế toán vừa tuyển thêm người.

Nếu được, hãy giữ một nhóm đối chứng, chẳng hạn một chi nhánh hoặc một loại chứng từ chưa dùng hệ thống, để tách riêng tác động của dự án.

Ví dụ: dây chuyền xử lý hóa đơn

Delos đưa ra một ví dụ trước/sau dễ hình dung: thời gian xử lý một hóa đơn giảm từ 8 phút xuống 45 giây. Đây là cách diễn đạt đúng, vì nó tính trên từng tác vụ chứ không nói chung chung kiểu “tăng năng suất”. Nhưng nếu dừng ở đó, con số vẫn đang bị thổi phồng.

GSPANN gọi phần bị bỏ sót là gánh nặng sửa chữa (repair burden): thời gian con người bỏ ra để kiểm tra và sửa output của AI. Họ tóm gọn thế này: công kiểm tra thì lúc nào cũng phải trả, còn công làm lại phụ thuộc vào xác suất.

GSPANN đưa ra một công thức tiết kiệm ròng để tính phần này. Diễn đạt bằng lời: lấy số giờ tiết kiệm gộp trừ đi số giờ sửa chữa, rồi trừ tiếp các khoản chi phí khác của hệ thống.

Thử áp dụng vào một tình huống giả định. Khách xử lý 10.000 hóa đơn mỗi tháng, mỗi hóa đơn cần 1 phút để người kiểm tra lại kết quả, và 5% hóa đơn bị sai, phải làm lại thủ công mất 8 phút.

Thành phần (mỗi hóa đơn)	Cách tính	Số giây
Tiết kiệm gộp	480 − 45	435
Kiểm tra (luôn phải làm)	1 phút × 100%	−60
Làm lại (theo xác suất)	8 phút × 5%	−24
Tiết kiệm ròng		351

Với 10.000 hóa đơn, mức tiết kiệm ròng là 3.510.000 giây, tức 975 giờ mỗi tháng. Delos khuyên quy giờ ra tiền bằng cách nhân thời gian tiết kiệm với chi phí đầy đủ mỗi giờ (fully loaded) của người từng làm việc đó, tức là gồm cả bảo hiểm, phúc lợi và chi phí quản lý chứ không chỉ có lương.

Sau đó bạn trừ chi phí model, hạ tầng và nhân sự vận hành hệ thống.

Con số thứ hai nên đưa cho phía tài chính là chi phí trên mỗi tác vụ thành công. Theo GSPANN, bạn chỉ đếm những việc AI hoàn thành và vượt ngưỡng chất lượng đã định, cộng toàn bộ chi phí tạo ra chúng, rồi chia.

Trong ví dụ trên, nếu giả định rằng hóa đơn phải làm lại thủ công không được tính là việc AI hoàn thành (dù sau khi sửa, chúng có thể đã đạt ngưỡng), thì mẫu số là 9.500 chứ không phải 10.000.

Tự làm cho dự án của bạn

Bắt đầu bằng một buổi làm việc với người giữ ngân sách, không phải với người dùng cuối. Hỏi họ muốn cải thiện chỉ số kinh doanh nào, và đạt ngưỡng chất lượng nào thì được tính là “xong”. Ghi lại thành văn bản và để họ xác nhận.

Sau đó đo baseline trên quy trình cũ: bấm giờ từng tác vụ, đếm số lượng, ghi lại tỷ lệ lỗi hiện tại. Khi hệ thống đã chạy, hãy log ba thứ cho mỗi tác vụ: thời gian xử lý, thời gian người kiểm tra, và tác vụ đó có phải làm lại hay không. Thiếu cột thứ ba, bạn sẽ không bao giờ tính được gánh nặng sửa chữa.

Cuối cùng, nói chuyện thời gian hoàn vốn ngay từ đầu. Khảo sát của Deloitte, được ACCA dẫn lại, cho thấy một use case AI điển hình cần từ hai đến bốn năm mới đạt ROI, và chỉ 6% người trả lời hoàn vốn trong chưa đầy một năm. Hứa hoàn vốn trong một quý là tự đặt mình vào thế thua.

Những lỗi khiến con số bị bác

Lỗi phổ biến nhất là báo cáo tiết kiệm gộp: lấy 8 phút trừ 45 giây rồi nhân lên, bỏ qua thời gian kiểm tra. Người làm tài chính sẽ hỏi ngay ai đang kiểm tra output, và lúc đó con số của bạn sụp đổ.

Lỗi thứ hai là đếm cả tác vụ hỏng vào mẫu số, khiến chi phí trên mỗi tác vụ trông rẻ hơn thực tế. Lỗi thứ ba là gán hết mọi cải thiện cho dự án của mình, trong khi khách đang chạy ba sáng kiến khác cùng lúc.

Lỗi thứ tư là dựa vào khảo sát cảm nhận. METR đã cho thấy cảm nhận có thể sai cả về hướng, chứ không chỉ sai về độ lớn.

Kỹ năng này nằm ở đâu trong CV của bạn?

Với developer Việt Nam muốn chuyển sang FDE, đây là kỹ năng giúp CV nổi bật. Khi đọc job description, hãy để ý các cụm như “business outcomes”, “value realization” hay “customer success”. Đó là dấu hiệu công ty cần người biết đo kết quả, không chỉ người biết build.

Trong CV, thay dòng “xây pipeline OCR hóa đơn” bằng một dòng có baseline, số liệu sau triển khai và tỷ lệ đạt chuẩn.

Bài tập tuần này

Lấy một tính năng bạn từng ship, ở công ty hay trong dự án cá nhân, rồi lập một bảng giống bảng hóa đơn ở trên: tiết kiệm gộp, công kiểm tra, công làm lại, tiết kiệm ròng. Ô nào còn trống vì chưa có số đo thật, đó chính là dữ liệu bạn phải thu thập ngay từ ngày đầu của dự án tiếp theo.

Đến buổi review có CFO, người thắng thường không phải người có demo đẹp nhất mà là người đã đo baseline từ ngày đầu tiên.