RPA (Robotic Process Automation) là phần mềm bắt chước thao tác của con người trên giao diện máy tính — mở ứng dụng, đăng nhập, sao chép dữ liệu từ ô này sang ô kia, bấm nút, tải tệp, gửi thư — để chạy những công việc lặp lại, có quy tắc rõ ràng, mà không cần sửa các hệ thống đang có. Chữ "robot" ở đây không có phần cứng nào: đó là một chương trình chạy trên máy tính hoặc máy chủ, dùng chung giao diện với nhân viên.
Giá trị cốt lõi của RPA là tốc độ triển khai: thay vì chờ bộ phận CNTT viết giao diện lập trình (API) nối hai hệ thống cũ với nhau, doanh nghiệp "dạy" một bot làm đúng các thao tác người vẫn làm. Cái giá phải trả là sự mong manh: bot phụ thuộc vào giao diện, giao diện đổi là bot hỏng. Hiểu cặp đánh đổi này là hiểu gần hết khi nào nên và không nên dùng RPA.
Phần dưới giải thích bot vận hành ra sao, các loại bot, lịch sử khái niệm, những việc RPA làm tốt, những việc nó làm dở, và quan hệ giữa RPA với AI.
Robot phần mềm vận hành ra sao
Một bot RPA gồm ba lớp. Lớp thứ nhất là bộ nhận diện giao diện: bot tìm nút bấm, ô nhập liệu, bảng dữ liệu trên màn hình thông qua cấu trúc bên dưới của ứng dụng (cây phần tử của Windows, cấu trúc trang web) hoặc, khi không còn cách nào khác, qua nhận dạng hình ảnh và toạ độ. Mỗi phần tử được định vị bằng một "bộ chọn" (selector), giống địa chỉ nhà của nó trên giao diện.
Lớp thứ hai là kịch bản quy trình: chuỗi bước có điều kiện, vòng lặp và xử lý lỗi, thường được thiết kế bằng công cụ kéo thả trên một sơ đồ luồng. Ví dụ: "mở thư mục hoá đơn; với mỗi tệp, đọc mã số thuế và tổng tiền; tra trong phần mềm kế toán; nếu khớp thì hạch toán, nếu không khớp thì chuyển cho kế toán viên". Lớp thứ ba là bộ điều phối (orchestrator): nơi lên lịch, phân việc cho nhiều bot, lưu mật khẩu tập trung, ghi nhật ký từng lần chạy và báo động khi bot dừng giữa chừng.
Điểm cần nhớ: bot không "hiểu" nghiệp vụ. Nó thực thi đúng từng bước được mô tả, nhanh và không mệt, nhưng gặp tình huống ngoài kịch bản thì hoặc dừng, hoặc — tệ hơn — làm sai mà không biết mình sai. Vì thế phần xử lý ngoại lệ thường chiếm nhiều công thiết kế hơn phần luồng chính.
Bot có giám sát và bot không giám sát
Hai kiểu triển khai phục vụ hai loại việc khác nhau, chi phí và rủi ro cũng khác nhau.
| Tiêu chí | Bot có giám sát (attended) | Bot không giám sát (unattended) |
|---|---|---|
| Chạy ở đâu | Trên máy của nhân viên, cùng phiên làm việc | Trên máy chủ hoặc máy ảo riêng |
| Ai kích hoạt | Nhân viên bấm chạy khi cần | Lịch hẹn giờ, sự kiện, hàng đợi việc |
| Việc điển hình | Tra cứu nhanh khi đang nghe điện thoại khách, điền sẵn biểu mẫu | Xử lý lô hoá đơn đêm, tổng hợp báo cáo đầu ngày |
| Thế mạnh | Người và bot chia việc trong cùng một giao dịch | Chạy liên tục ngoài giờ, khối lượng lớn |
| Rủi ro chính | Phụ thuộc thao tác và máy của từng người | Lỗi chạy âm thầm nếu không có giám sát và báo động |
Nhiều doanh nghiệp bắt đầu bằng bot có giám sát vì dễ được người dùng chấp nhận — bot là "trợ lý" chứ không phải người thay thế. Lợi ích về chi phí thường đến từ bot không giám sát, nhưng chúng đòi hỏi quy trình đã ổn định và một cơ chế vận hành nghiêm túc: ai theo dõi, ai sửa, trong bao lâu.
Nguồn gốc của khái niệm RPA
Ý tưởng điều khiển phần mềm qua giao diện không mới. Từ thập niên 1990 đã có kỹ thuật screen scraping đọc dữ liệu từ màn hình máy tính lớn, các macro trong bảng tính ghi lại thao tác người dùng, và công cụ kiểm thử tự động giả lập người bấm nút để thử phần mềm. RPA là bước gom các kỹ thuật đó lại, thêm bộ điều phối, quản lý mật khẩu và nhật ký kiểm toán để chạy được ở quy mô doanh nghiệp.
Thuật ngữ "Robotic Process Automation" trở nên phổ biến từ đầu thập niên 2010, khi các nhà cung cấp phần mềm và công ty thuê ngoài dịch vụ kế toán, chăm sóc khách hàng bắt đầu bán nó như cách giảm chi phí xử lý giao dịch. Leslie Willcocks và Mary Lacity (Trường Kinh tế London) là những người nghiên cứu sớm và có hệ thống: loạt nghiên cứu tình huống của họ, tổng hợp trong cuốn Service Automation: Robots and the Future of Work (2016), cho thấy RPA mang lại lợi ích rõ khi được dùng cho quy trình chuẩn hoá cao và có sự tham gia của bộ phận CNTT ngay từ đầu.
Từ cuối thập niên 2010, các hãng gắn thêm nhận dạng ký tự (OCR), học máy và gần đây là mô hình ngôn ngữ lớn vào bot, và một số hãng tư vấn đặt ra các nhãn như "hyperautomation". Về bản chất, phần lõi vẫn là thực thi thao tác theo quy tắc trên giao diện; phần AI được thêm vào để xử lý dữ liệu đầu vào kém cấu trúc.
RPA làm tốt những việc nào
Chuyển dữ liệu giữa các hệ thống không nói chuyện được với nhau. Đây là việc kinh điển: phần mềm bán hàng xuất đơn, nhân viên gõ lại vào phần mềm kế toán; cổng thông tin của đối tác chỉ cho tải tệp qua giao diện web. Khi không có API, hoặc có nhưng chi phí tích hợp quá lớn so với khối lượng, bot là cây cầu tạm thời nhanh nhất.
Đối chiếu và kiểm tra theo quy tắc. So số liệu giữa hai nguồn, kiểm mã số thuế, kiểm hạn hợp đồng, kiểm đủ trường bắt buộc trong hồ sơ. Bot làm việc này đều tay, không bỏ sót dòng thứ 3.000 vì mỏi mắt.
Tổng hợp báo cáo định kỳ. Đăng nhập năm hệ thống lúc 6 giờ sáng, xuất số liệu, ghép vào một bảng tính có định dạng sẵn và gửi cho quản lý trước giờ họp giao ban.
Việc theo mùa, theo đợt. Cuối tháng, cuối quý, mùa quyết toán: khối lượng tăng vọt trong vài ngày rồi biến mất. Tuyển thêm người cho vài ngày là không thực tế; bot có thể chạy thêm ca mà không cần đào tạo lại.
Ghi nhật ký đầy đủ cho kiểm toán. Mỗi lần bot chạy đều để lại vết: đọc gì, ghi gì, lúc nào. Với quy trình tài chính và tuân thủ, đây là lợi ích ít được nhắc nhưng có thật.
Giới hạn của RPA cần biết trước khi đầu tư
Các giới hạn sau không phải lỗi của một sản phẩm cụ thể mà nằm ở chính cách tiếp cận "điều khiển qua giao diện":
- Mong manh trước thay đổi giao diện. Một bản cập nhật đổi vị trí nút, đổi tên trường, thêm bước xác thực là đủ làm bot dừng. Nhà cung cấp phần mềm nguồn không có nghĩa vụ báo trước cho bot của bạn.
- Tự động hoá luôn cả sự kém hiệu quả. Bot chạy đúng quy trình đang có, kể cả các bước thừa. Michael Hammer đã cảnh báo từ năm 1990 trong bài "Reengineering Work: Don't Automate, Obliterate" trên Harvard Business Review: đừng tự động hoá cái cần bỏ đi.
- Không xử lý được phán đoán. Việc đòi hỏi cân nhắc, thương lượng hay đọc ngữ cảnh mơ hồ vẫn cần người, hoặc cần mô hình AI với cơ chế kiểm tra riêng.
- Nợ kỹ thuật tích luỹ. Mỗi bot là một mẩu phần mềm cần bảo trì. Năm mươi bot do năm mươi người viết theo năm mươi kiểu là một hệ thống khó quản lý.
- Rủi ro bảo mật. Bot cần tài khoản và mật khẩu để đăng nhập; tài khoản bot có quyền rộng mà không ai giám sát là điểm yếu thật.
- Không thay thế được tích hợp đúng nghĩa. Với luồng dữ liệu khối lượng lớn, lâu dài và quan trọng, API hoặc tích hợp ở tầng dữ liệu bền và rẻ hơn về dài hạn.
Cách nghĩ thực tế: coi RPA là giải pháp chiến thuật, đặc biệt hợp khi hệ thống cũ sắp được thay hoặc khi khối lượng chưa đủ biện minh cho một dự án tích hợp. Nếu một bot được dự kiến sống mười năm, hãy hỏi lại vì sao không làm tích hợp thật.
Vòng đời triển khai một bot
Một bot chạy ổn định trong sản xuất thường đi qua các giai đoạn sau; bỏ qua giai đoạn nào thì cái giá thường xuất hiện ở giai đoạn vận hành:
- Đánh giá và chọn quy trình theo khối lượng, mức dựa trên quy tắc, tỷ lệ ngoại lệ và độ ổn định. Đây là khâu quyết định phần lớn thành bại.
- Ghi chép quy trình chi tiết đến mức từng màn hình, từng trường dữ liệu, từng quy tắc rẽ nhánh, kèm danh sách ngoại lệ đã biết và cách người đang xử lý chúng.
- Thiết kế giải pháp: phần nào bot làm, phần nào chuyển cho người, bot chạy theo lịch hay theo hàng đợi, đầu ra được đối chiếu thế nào.
- Xây và kiểm thử trên môi trường thử với dữ liệu giống thật, gồm cả các ca hỏng: hệ thống chậm, mất kết nối, dữ liệu thiếu, mật khẩu hết hạn.
- Chạy song song một thời gian: bot và người cùng làm, so kết quả từng giao dịch trước khi giao hẳn cho bot.
- Vận hành: giám sát hằng ngày, xử lý hàng đợi ngoại lệ, sửa khi giao diện thay đổi, báo cáo số giao dịch và tỷ lệ chạy thành công.
- Rà soát và gỡ bỏ: mỗi năm đánh giá lại bot còn cần không, có nên thay bằng tích hợp hay tính năng sẵn có của hệ thống mới không.
Giai đoạn cuối hay bị quên nhất. Bot không ai gỡ tiếp tục chạy trên hệ thống đã đổi quy trình, tạo ra dữ liệu sai một cách đều đặn và khó phát hiện.
RPA và AI: khác nhau và bổ sung cho nhau thế nào
RPA thực thi quy tắc; AI (học máy, mô hình ngôn ngữ) đưa ra dự đoán hoặc diễn giải từ dữ liệu. Một cách hình dung: RPA là đôi tay, AI là đôi mắt và một phần phán đoán. Bot RPA thuần không đọc được một hoá đơn chụp nghiêng; mô-đun nhận dạng chứng từ đọc được, nhưng kèm một độ tin cậy, không phải sự chắc chắn tuyệt đối.
Hệ quả thiết kế quan trọng: khi ghép AI vào luồng tự động, phải có ngưỡng tin cậy và điểm kiểm tra của con người. Ví dụ: kết quả trích xuất có độ tin cậy cao thì chạy thẳng, thấp hơn ngưỡng thì đẩy vào hàng đợi cho nhân viên xác nhận. Không có cơ chế này, sai sót của mô hình sẽ được bot nhân bản với tốc độ máy.
Ở Việt Nam có một điểm đặc thù đáng tận dụng: hoá đơn điện tử theo quy định hiện hành có dữ liệu dạng XML, nên với hoá đơn đầu vào trong nước, việc đọc tệp XML trực tiếp thường chính xác và rẻ hơn nhiều so với chụp ảnh rồi nhận dạng ký tự. Nhận dạng chứng từ bằng AI có giá trị hơn với hồ sơ giấy, chứng từ nước ngoài, hợp đồng và giấy tờ tuỳ thân.
Câu hỏi thường gặp
RPA có phải là trí tuệ nhân tạo không?
Không. RPA thuần là thực thi quy tắc được lập trình sẵn trên giao diện, không học từ dữ liệu. Nhiều sản phẩm hiện nay đóng gói thêm mô-đun AI như nhận dạng chứng từ hay phân loại thư, nhưng đó là thành phần bổ sung. Khi đánh giá một giải pháp, nên tách riêng phần nào là quy tắc, phần nào là mô hình dự đoán, vì cách kiểm soát rủi ro của hai phần khác nhau.
RPA khác macro trong bảng tính ở điểm nào?
Macro chạy bên trong một ứng dụng và thường gắn với máy của một người. RPA điều khiển nhiều ứng dụng khác nhau, chạy được trên máy chủ, có bộ điều phối lên lịch, kho mật khẩu tập trung, nhật ký từng lần chạy và cơ chế xử lý lỗi. Khác biệt chính là khả năng vận hành, giám sát và kiểm toán ở quy mô tổ chức.
Doanh nghiệp nhỏ có nên dùng RPA không?
Có thể, nhưng hãy kiểm hai điều trước: khối lượng việc lặp lại có đủ lớn không, và phần mềm đang dùng có sẵn tính năng xuất nhập dữ liệu hoặc kết nối không. Nhiều việc ở doanh nghiệp nhỏ giải quyết được bằng tính năng có sẵn của phần mềm kế toán, bán hàng hoặc một công cụ workflow đơn giản, rẻ và bền hơn một bot.
Bot RPA có làm việc 24/7 thật không?
Bot không giám sát chạy được ngoài giờ, nhưng chỉ khi các hệ thống nó dùng cũng mở cửa và ổn định. Nhiều cổng thông tin bảo trì ban đêm, giới hạn số phiên đăng nhập hoặc yêu cầu mã xác thực gửi qua điện thoại. Lịch chạy thực tế thường phải thiết kế quanh các ràng buộc đó.
Vì sao bot hay dừng sau khi phần mềm cập nhật?
Bot định vị nút bấm và ô nhập liệu qua bộ chọn giao diện. Khi nhà cung cấp đổi bố cục, tên phần tử hoặc thêm bước mới, bộ chọn không còn khớp. Cách giảm thiểu là dùng bộ chọn ổn định, kiểm thử bot trên môi trường thử trước mỗi đợt cập nhật lớn, và có người phụ trách sửa trong thời hạn cam kết.
RPA có khiến nhân viên mất việc không?
Nghiên cứu tình huống cho thấy kết quả phụ thuộc cách doanh nghiệp dùng phần thời gian được giải phóng: có nơi giảm tuyển mới, có nơi chuyển người sang việc phân tích, chăm sóc khách hàng. RPA thường thay thế từng tác vụ chứ hiếm khi thay trọn một vị trí, vì vị trí nào cũng có phần việc cần phán đoán.