Phần lớn dự án RPA không đạt kỳ vọng vì những lý do không nằm ở công nghệ: chọn sai quy trình, tự động hoá quy trình chưa được sửa, đánh giá thấp chi phí vận hành, và bỏ quên con người. Bot thường chạy đúng như được lập trình; vấn đề là thứ được lập trình không phản ánh đúng thực tế, hoặc không ai lo cho nó sau ngày nghiệm thu.
Một số báo cáo của các hãng tư vấn giữa thập niên 2010 từng ước tính một tỷ lệ đáng kể dự án RPA ban đầu thất bại hoặc dừng ở giai đoạn thử nghiệm; các con số khác nhau theo định nghĩa "thất bại" và mẫu khảo sát, nên đừng bám vào một tỷ lệ cụ thể. Điều nhất quán giữa các nguồn, kể cả các nghiên cứu tình huống của Willcocks và Lacity, là mẫu hình của thất bại: rất giống nhau từ ngành này sang ngành khác.
Bài này đi qua tám hiểu lầm phổ biến nhất, đặt cạnh thực tế, rồi tổng hợp thành một danh mục kiểm tra trước khi bắt đầu.
Hiểu lầm 1–2: về bản chất công nghệ
Hiểu lầm 1: "Bot là nhân viên ảo, cứ dạy là làm." Thực tế: bot không học, không hiểu ngữ cảnh, không nhận ra khi có điều gì đó "trông không ổn". Nó thực thi đúng từng bước, nhanh và đều, cho đến khi gặp một tình huống ngoài kịch bản. Phép ẩn dụ "nhân viên số" hữu ích để giải thích, nhưng nguy hiểm khi lãnh đạo bắt đầu kỳ vọng bot tự xử lý ngoại lệ như người. Hãy coi bot là phần mềm — với đủ yêu cầu kiểm thử, quản lý phiên bản và bảo trì của phần mềm.
Hiểu lầm 2: "RPA không cần CNTT tham gia." Thực tế: RPA thường được bán cho phòng nghiệp vụ với thông điệp "không cần lập trình, không cần chờ CNTT". Bot vẫn chạy trên hạ tầng, dùng tài khoản hệ thống, phụ thuộc vào lịch cập nhật ứng dụng và chính sách bảo mật — tất cả đều thuộc CNTT. Nghiên cứu tình huống của Willcocks và Lacity nhấn mạnh rằng các triển khai thành công có CNTT tham gia sớm về hạ tầng, bảo mật và quản trị, dù phòng nghiệp vụ dẫn dắt. Dự án né CNTT thường gặp lại CNTT ở giai đoạn đưa vào chạy thật, khi mọi thứ phải làm lại.
Hiểu lầm 3–4: về quy trình
Hiểu lầm 3: "Tự động hoá quy trình đang có là nhanh nhất." Thực tế: bot làm nhanh hơn những bước lẽ ra phải bỏ. Một quy trình có ba lần đối chiếu trùng lặp sẽ có một bot làm ba lần đối chiếu trùng lặp — và giờ thì không ai muốn sửa nữa vì "đã tự động rồi". Lời cảnh báo "đừng tự động hoá, hãy loại bỏ" của Michael Hammer năm 1990 vẫn đúng. Thứ tự đúng là bỏ, gộp, chuẩn hoá, rồi mới tự động hoá.
Hiểu lầm 4: "Quy trình bên mình đơn giản, ai cũng làm giống nhau." Thực tế: khi ngồi ghi chép chi tiết, gần như luôn xuất hiện các biến thể không ai kể: chi nhánh này dùng mẫu khác, khách hàng lớn được xử lý riêng, cuối tháng có bước bổ sung. Quy trình "đơn giản" trong buổi họp thường hoá ra có nhiều nhánh khi đo bằng dữ liệu. Ước tính sai độ phức tạp làm thời gian xây kéo dài và tỷ lệ ngoại lệ sau khi chạy cao hơn hẳn dự kiến. Cách phòng: đo trước, bằng dữ liệu nhật ký hoặc bấm giờ mẫu, và ghi chép cả luồng ngoại lệ.
Hiểu lầm 5–6: về kinh tế
Hiểu lầm 5: "Xây xong là xong, bot tự chạy." Thực tế: chi phí vận hành và bảo trì là khoản bị đánh giá thấp nhất. Mỗi lần hệ thống nguồn cập nhật, mỗi lần quy định thay đổi, mỗi lần mật khẩu hết hạn, bot cần người. Thêm vào đó là người xử lý hàng đợi ngoại lệ hằng ngày. Một chương trình có vài chục bot mà không có đội vận hành sẽ sớm thấy phần lớn thời gian của đội phát triển dành cho việc sửa bot cũ thay vì xây bot mới — và đó là lúc chương trình chững lại.
Hiểu lầm 6: "Giờ công tiết kiệm bằng tiền tiết kiệm." Thực tế: giờ công tiết kiệm chỉ thành tiền khi có quyết định đi kèm — giảm tuyển mới, giảm làm thêm giờ, giảm thuê ngoài, hoặc chuyển người sang việc tạo ra giá trị đo được. Phần tiết kiệm thường rải ở nhiều người, mỗi người vài giờ một tuần, nên không tự chuyển thành cắt giảm chi phí. Bản đề xuất hứa "tiết kiệm X người" mà không có kế hoạch dùng năng lực đó sẽ mất uy tín ở lần rà soát đầu tiên.
Hiểu lầm 7: con người sẽ tự thích nghi
Thực tế: nhân viên có lý do chính đáng để lo khi nghe "bot sẽ làm phần việc của bạn", và sự lo lắng đó thể hiện bằng những hành vi rất cụ thể: không kể hết các ngoại lệ khi được phỏng vấn, đánh giá bot khắt khe ở giai đoạn chạy song song, hoặc âm thầm giữ lại quy trình thủ công song song "cho chắc". Bất kỳ hành vi nào trong số đó cũng đủ làm dự án chệch hướng.
Có một mặt khác ít được nhắc: khi bot chạy ổn, con người mất dần kỹ năng làm thủ công. Lisanne Bainbridge mô tả hiện tượng này trong bài báo kinh điển "Ironies of Automation" (1983): tự động hoá càng tốt, người vận hành càng ít cơ hội thực hành, nên càng kém khi phải can thiệp đúng vào lúc khó nhất — khi hệ thống tự động hỏng. Parasuraman và Riley (1997) phân tích thêm các kiểu quan hệ lệch giữa người và tự động hoá: tin quá mức (misuse), bỏ không dùng (disuse) và áp dụng sai chỗ (abuse). Cả hai công trình ban đầu xuất phát từ điều khiển công nghiệp và hàng không, nhưng cơ chế tâm lý áp dụng nguyên vẹn cho văn phòng: kế toán viên đã ba năm không tự làm đối chiếu sẽ khó phát hiện bot làm sai.
Cách phòng gồm ba phần: nói rõ từ đầu kế hoạch dùng năng lực được giải phóng (và giữ lời); đưa người làm quy trình vào thiết kế, coi họ là chuyên gia chứ không phải đối tượng bị thay thế; và duy trì tài liệu cùng thực hành định kỳ quy trình thủ công dự phòng cho các bot quan trọng.
Hiểu lầm 8: thành công ở bot đầu tiên nghĩa là mở rộng được
Thực tế: rất nhiều chương trình RPA mắc kẹt ở mức vài bot. Bot thử nghiệm đầu tiên thường được chọn kỹ, có đội giỏi nhất, có sự chú ý của lãnh đạo, chạy trên quy trình dễ nhất. Khi mở rộng, các điều kiện đó biến mất cùng lúc: quy trình khó hơn, người phát triển ít kinh nghiệm hơn, quy chuẩn chưa có, đội vận hành chưa hình thành, và chi phí bảo trì của các bot trước bắt đầu ăn vào năng lực xây mới.
Sự khác biệt giữa thử nghiệm và mở rộng nằm ở nền móng: danh mục quy trình được chấm điểm, quy chuẩn và khuôn mẫu phát triển, mô hình tổ chức với vai trò rõ, đội vận hành có lịch trực, cơ chế quản lý thay đổi gắn với CNTT, và bảng theo dõi chi phí–lợi ích ở cấp danh mục. Những thứ này không cần cho bot đầu tiên, nhưng phải bắt đầu xây ngay sau khi bot đầu tiên thành công — trước khi bot thứ mười xuất hiện.
Một tín hiệu cảnh báo sớm dễ đo: tỷ lệ thời gian của đội phát triển dành cho bảo trì so với xây mới. Khi tỷ lệ bảo trì tăng đều qua từng quý, chương trình đang tích luỹ nợ kỹ thuật nhanh hơn tạo giá trị, và cần dừng lại để chuẩn hoá, thay một số bot bằng tích hợp, hoặc gỡ bớt bot giá trị thấp.
Dấu hiệu sớm cho thấy dự án đang đi chệch
Các tín hiệu dưới đây thường xuất hiện vài tuần đến vài tháng trước khi dự án bị coi là thất bại. Phát hiện sớm thì chi phí sửa còn thấp:
- Giai đoạn ghi chép quy trình kéo dài gấp đôi dự kiến vì liên tục phát hiện nhánh mới: quy trình phức tạp hơn đánh giá ban đầu, cần chấm điểm lại.
- Chạy song song mãi không kết thúc vì người dùng chưa tin kết quả của bot: hoặc bot sai thật, hoặc tiêu chí nghiệm thu chưa được thống nhất từ đầu.
- Hàng đợi ngoại lệ phình to và nhân viên phải dành nhiều thời gian xử lý hơn lúc chưa có bot.
- Bot dừng sau mỗi đợt cập nhật hệ thống mà đội phát triển chỉ biết khi người dùng phàn nàn.
- Không ai trả lời được câu hỏi "bot đã tiết kiệm được gì" bằng số đo, ba tháng sau khi chạy thật.
- Quy trình thủ công cũ vẫn chạy song song một cách không chính thức, nghĩa là doanh nghiệp đang trả tiền cho cả hai.
Gặp hai tín hiệu trở lên, hãy dừng mở rộng và rà lại từ khâu chọn quy trình, thay vì cố thêm tính năng cho bot.
Danh mục kiểm tra trước khi bắt đầu
Gom tám hiểu lầm lại thành các câu hỏi cần trả lời "có" trước khi phê duyệt một dự án hoặc một chương trình RPA:
- Quy trình đã được chấm điểm theo khối lượng, mức dựa trên quy tắc, dữ liệu, tỷ lệ ngoại lệ và độ ổn định, bằng số đo thật?
- Quy trình đã được rà soát để bỏ, gộp, chuẩn hoá các bước trước khi thiết kế bot?
- Đã cân nhắc và loại trừ có lý do các cách bền hơn như tính năng có sẵn, workflow, tích hợp API?
- Bộ phận CNTT đã tham gia về hạ tầng, tài khoản, bảo mật và lịch cập nhật hệ thống?
- Bản tính hiệu quả có đủ chi phí vận hành, bảo trì, xử lý ngoại lệ, và tách lợi ích tiền mặt khỏi năng lực giải phóng?
- Có kế hoạch cụ thể cho năng lực được giải phóng, đã được trao đổi với nhân viên liên quan?
- Có người sở hữu quy trình, người vận hành, phương án thủ công dự phòng và cơ chế đối chiếu đầu ra?
- Nếu đây là bước mở rộng: đã có quy chuẩn phát triển, danh mục bot và mô hình tổ chức chưa?
Một câu trả lời "không" chưa phải lý do huỷ dự án, nhưng là việc phải làm trước. Phần lớn chi phí của thất bại nằm ở những câu hỏi mà không ai hỏi khi còn rẻ để trả lời.
Câu hỏi thường gặp
Có số liệu đáng tin về tỷ lệ dự án RPA thất bại không?
Các con số được trích dẫn rộng rãi phần lớn đến từ khảo sát của các hãng tư vấn, với định nghĩa thất bại và mẫu khảo sát khác nhau, nên không so sánh được với nhau. Điều đáng tin hơn là mẫu hình nguyên nhân lặp lại giữa nhiều nguồn: chọn sai quy trình, thiếu tham gia của CNTT, đánh giá thấp vận hành và quản lý thay đổi.
Dự án RPA đã thất bại có cứu được không?
Thường được, nếu xác định đúng nguyên nhân. Bot hỏng liên tục vì quy trình nhiều ngoại lệ có thể được thu hẹp phạm vi về luồng chuẩn; bot không ai vận hành cần giao người sở hữu; quy trình chưa chuẩn hoá cần quay lại thiết kế. Đôi khi quyết định đúng là gỡ bot và chọn cách khác, chấp nhận chi phí đã bỏ ra là chi phí chìm.
Nghịch lý tự động hoá áp dụng cho văn phòng như thế nào?
Khi bot đảm nhận một việc trong thời gian dài, nhân viên ít thực hành nên mất dần kỹ năng và hiểu biết chi tiết về quy trình. Đúng lúc bot hỏng hoặc gặp ca khó, người phải can thiệp lại kém chuẩn bị nhất. Cách giảm là duy trì tài liệu, luân phiên kiểm tra kết quả bot và diễn tập quy trình thủ công định kỳ.
Thiên kiến tự động hoá là gì và làm sao giảm?
Đó là xu hướng tin vào kết quả của hệ thống tự động hơn mức đáng tin, bỏ qua dấu hiệu sai. Trong văn phòng, nó thể hiện khi người duyệt chấp nhận số liệu bot tổng hợp mà không kiểm. Giảm bằng cách hiển thị rõ dữ liệu nguồn, thiết kế bước kiểm tra có chủ đích, và theo dõi tỷ lệ phát hiện lỗi ở bước kiểm của con người.
Nên bắt đầu lại thế nào sau một dự án RPA thất bại?
Làm một buổi rút kinh nghiệm không đổ lỗi, đối chiếu với tám hiểu lầm để xác định nguyên nhân gốc. Sau đó chọn một quy trình nhỏ đạt điểm cao theo tiêu chí, làm lại với CNTT tham gia, đường cơ sở được đo và người vận hành được chỉ định từ đầu. Một thành công nhỏ có số đo rõ giúp lấy lại niềm tin nhanh hơn một kế hoạch lớn.
AI tạo sinh có giải quyết được các nguyên nhân thất bại này không?
Chỉ một phần. AI giúp xử lý dữ liệu đầu vào kém cấu trúc và có thể giảm số ngoại lệ do định dạng, nhưng không giải quyết chọn sai quy trình, thiếu vận hành hay quản lý thay đổi. AI còn thêm rủi ro mới: kết quả mang tính xác suất, cần ngưỡng tin cậy và bước kiểm của con người được thiết kế rõ.