Nhắc đến tự động hóa doanh nghiệp, nhiều người sẽ nghĩ ngay đến những con bot chạy lặp lại các thao tác trên màn hình máy tính. Chúng tôi đã làm việc với không ít đội vận hành dùng RPA được vài năm. Câu chuyện khá quen thuộc: bot chạy trơn tru suốt mấy tháng, rồi một buổi sáng bỗng đứng khựng lại chỉ vì phần mềm vừa đổi giao diện. Bài viết này ghi lại hành trình chuyển từ RPA truyền thống sang quy trình có AI hỗ trợ, nhìn từ góc độ kỹ thuật, kèm những việc nên chuẩn bị trước khi bắt tay vào làm.
Những giới hạn của RPA truyền thống
RPA ra đời như một lời giải rất thực dụng. Doanh nghiệp không cần đụng vào hệ thống nền, chỉ cần để một chương trình làm thay người các thao tác nhàm chán trên những ứng dụng đang dùng. Nghe thì gọn gàng. Nhưng chính sự dễ triển khai ấy lại là gốc rễ của khá nhiều rắc rối về sau.
Bot chạy theo luật cứng nên dễ vỡ
Bản chất một bot RPA là ghi nhớ vị trí phần tử trên giao diện, thứ tự thao tác và các điều kiện rẽ nhánh đã được lập sẵn. Bước A thành công thì làm bước B, không thì chuyển sang bước C. Trong môi trường ít thay đổi, mô hình này khá ổn định, và đó là lý do nhiều doanh nghiệp vừa và nhỏ vẫn dùng tốt suốt nhiều năm.
Vấn đề nảy sinh khi phần mềm được nâng cấp, biểu mẫu đổi cấu trúc hoặc xuất hiện thêm một trường dữ liệu mới. Bot không tự thích nghi được. Nó đứng yên đúng ở bước không còn khớp với kịch bản. Đội vận hành lúc đó phải liên tục vá lỗi và cấu hình lại mỗi lần hệ thống thay đổi. Có một đơn vị chúng tôi từng theo dõi, sau một năm chi phí bảo trì gần bằng chi phí triển khai ban đầu, trong khi lúc bắt đầu họ không hề tính khoản này. Bài học rút ra khá rõ: chi phí thật của bot không nằm ở lần cài đặt đầu tiên.
Ba điểm yếu hay gặp nhất gồm:
- Phụ thuộc vào vị trí và thuộc tính giao diện: chỉ một nút bấm đổi chỗ hay một ô nhập liệu đổi tên cũng đủ làm kịch bản gãy.
- Thiếu khả năng xử lý ngoại lệ: gặp tình huống nằm ngoài danh sách đã định, bot dừng hẳn và chờ người vào xử lý.
- Phạm vi hẹp: mỗi bot thường chỉ phục vụ một quy trình trong một ứng dụng nhất định.
Script thuần không đọc được dữ liệu phi cấu trúc
Phần lớn dữ liệu trong doanh nghiệp không nằm gọn trong bảng tính. Đó là email khách hàng, hợp đồng dạng PDF, phiếu yêu cầu viết tay, ghi chú cuộc họp hay tin nhắn trên các kênh nội bộ. Công cụ tự động hóa thuần script được thiết kế để làm tốt với dữ liệu có định dạng rõ ràng, như cột trong bảng, trường trong cơ sở dữ liệu hay JSON theo schema cố định.
Thử hình dung một email phàn nàn từ khách hàng. Một đoạn script so khớp chuỗi ký tự khó lòng phân biệt được đây là khiếu nại về giao hàng hay yêu cầu hoàn tiền. Ngữ nghĩa, ngữ cảnh và sắc thái câu chữ là thứ logic điều kiện truyền thống không nhìn thấy. Đây chính là ranh giới giữa tự động hóa cổ điển và tự động hóa có AI đứng phía sau.
AI biến quy trình cứng thành quy trình biết suy luận
Cần nói rõ ngay từ đầu: AI không thay thế hoàn toàn RPA. Nó đóng vai trò như một lớp nhận thức bổ sung, giúp hệ thống hiểu nội dung, phân loại và đưa ra quyết định mà luật cứng không làm nổi. Khi ghép hai lớp lại với nhau, quy trình mới đủ linh hoạt để theo kịp những thay đổi liên tục của môi trường kinh doanh.
Model đảm nhận những việc gì
Các mô hình ngôn ngữ lớn và model phân loại chuyên biệt có thể đọc văn bản tự do khá gần với cách một người thật đọc. Khi triển khai, chúng thường gánh vài việc cụ thể. Việc đầu tiên là phân loại ý định, tức xác định một yêu cầu hay tài liệu thuộc nhóm nào để chuyển đúng luồng xử lý. Việc thứ hai là trích xuất thông tin có cấu trúc, biến một email hay hợp đồng scan thành các trường dữ liệu mà hệ thống phía sau dùng được.
Model còn hỗ trợ ra quyết định theo ngữ cảnh thay vì chỉ kiểm tra đúng hay sai, và soạn nháp phản hồi như email trả lời hay bản tóm tắt báo cáo theo mẫu. Điều quan trọng nhất là model không đứng một mình. Nó là một khâu trong pipeline, nhận đầu vào từ hệ thống hiện có và trả kết quả cho bước kế tiếp. Nhờ vậy doanh nghiệp giữ được hạ tầng RPA đã đầu tư, đồng thời mở rộng sang những việc trước đây bắt buộc phải có người làm. Nếu muốn hình dung rõ các lớp kỹ thuật này ghép với nhau thế nào trong vận hành thực tế, bạn có thể tham khảo thêm bài về tự động hóa doanh nghiệp bằng AI.
Kết hợp rule engine và AI để vừa kiểm soát vừa linh hoạt
Nỗi lo lớn nhất khi đưa AI vào quy trình là tính minh bạch. Một model có thể trả lời sai hoặc thiếu nhất quán, và điều đó khó chấp nhận với những việc như kế toán, pháp lý hay chăm sóc khách hàng cấp cao. Cách hợp lý nhất mà chúng tôi thấy là xây kiến trúc lai: rule engine giữ phần cứng, AI xử lý phần mềm.
Rule engine xử lý các điều kiện đã rõ, quy định tuân thủ và giới hạn ủy quyền, tức là những việc có đáp án chắc chắn không cần AI can thiệp. AI lo phân loại, hiểu ngữ nghĩa và các trường hợp ngoại lệ chưa được định nghĩa trước. Giữa hai lớp này nên có một vòng xác nhận, nơi quyết định có độ tin cậy thấp được đẩy vào hàng đợi để người xem xét, thay vì tự động thực thi.
Chúng tôi từng gặp các đội kỹ thuật đặt cược toàn bộ vào AI rồi thất vọng vì sai sót khó lường, hoặc ngược lại bỏ hẳn AI và quay về bot cứng. Mô hình lai nằm ở giữa và cho kết quả ổn định hơn nhiều. Đây cũng là hướng nhiều đơn vị phát triển phần mềm đang áp dụng khi thiết kế hệ thống cho khách hàng thuộc nhiều ngành, và bạn có thể tìm hiểu thêm các giải pháp tại mona.media.
Lộ trình triển khai thực tế
Hiểu lý thuyết mới chỉ là bước đầu. Câu hỏi thiết thực hơn là bắt đầu từ đâu và đi theo thứ tự nào để không lãng phí nguồn lực. Kinh nghiệm từ các dự án của chúng tôi cho thấy giai đoạn chuẩn bị quyết định thành bại nhiều hơn là việc chọn công nghệ.
Lập bản đồ quy trình trước khi chọn công cụ
Việc đầu tiên không phải là mở tài liệu so sánh các nền tảng. Hãy vẽ lại quy trình hiện tại để thấy toàn bộ luồng dữ liệu, các điểm chuyển giao giữa bộ phận và những chỗ hay ùn tắc. Từ bản đồ đó, bạn sẽ trả lời được câu hỏi quan trọng nhất: bước nào nên tự động hóa, bước nào nên giữ cho con người.
Khi đã có bản đồ, nên chọn một quy trình có tần suất cao, đầu vào tương đối ổn định và kết quả đo được rõ ràng để thử nghiệm đầu tiên. Đừng mở màn bằng quy trình phức tạp nhất. Lúc này mục tiêu là học nhanh từ thực tế, không phải tự làm khó mình ngay từ đầu.
Thiết kế kiến trúc theo từng lớp độc lập
Một kiến trúc end-to-end thường gồm bốn lớp xếp chồng lên nhau. Lớp tiếp nhận thu dữ liệu từ email, form, API hay file tải lên. Lớp xử lý để rule engine và model phối hợp phân loại, trích xuất và đưa ra quyết định sơ bộ. Lớp thực thi để bot hoặc lời gọi API thao tác trên ERP, CRM hay mail server. Cuối cùng là lớp giám sát, theo dõi trạng thái, ghi log và cảnh báo khi cần người can thiệp.
Mỗi lớp cần đủ độc lập để có thể thay thế hoặc nâng cấp riêng mà không làm sập cả hệ thống. Nguyên tắc này nghe đơn giản, nhưng giúp tránh cảnh vài năm sau hệ thống thành một khối khó sửa mà không ai dám động vào.
Kết luận
Tự động hóa doanh nghiệp là hành trình tăng dần độ thông minh, không phải đích đến đi một lần là xong. Hãy bắt đầu từ những tác vụ rõ ràng nhất, ít biến động và có dữ liệu sạch, để tích lũy kinh nghiệm vận hành trước khi tiến tới các quy trình cần AI sâu hơn. Mỗi bước thành công không chỉ mang lại giá trị trực tiếp mà còn xây dựng năng lực cho tổ chức, từ kỹ năng vận hành, văn hóa dữ liệu đến cách đánh giá rủi ro.
Đồng thời, đừng xem nhẹ dữ liệu đầu vào và cơ chế giám sát. Một model học trên dữ liệu kém sẽ cho kết quả kém, và nếu thiếu giám sát tốt, sai lệch chỉ lộ ra khi hậu quả đã xảy ra. Hai yếu tố này thường bị đánh giá thấp hơn việc chọn nền tảng, nhưng thực tế chúng quyết định phần lớn thành công của dự án.
