Cách chọn quy trình đầu tiên để thí điểm AI Agent trong doanh nghiệp

Khi đã quyết định thử AI Agent, câu hỏi khó nhất thường không phải chọn mô hình nào mà là thử ở đâu trước. Phòng kinh doanh muốn Agent tư vấn khách, kế toán muốn đọc hóa đơn, ban giám đốc muốn một trợ lý trả lời mọi thứ. Chọn sai quy trình đầu tiên, dự án có thể kéo dài vì tích hợp phức tạp, hoặc chạy xong mà không ai chứng minh được nó có ích.

Một đợt thí điểm tốt không cần gây ấn tượng. Nó chỉ cần trả lời một câu hỏi: trong điều kiện thật của doanh nghiệp, Agent có làm một việc cụ thể tốt hơn cách làm hiện tại hay không.

Bài viết đưa ra tám tiêu chí để chấm điểm các quy trình ứng viên, bốn bước chạy pilot và những dấu hiệu cho thấy nên dừng.

1. Thí điểm AI Agent khác gì một buổi demo

Demo cho thấy công nghệ làm được gì với dữ liệu mẫu. Thí điểm cho thấy nó làm được gì với dữ liệu thật, người dùng thật và ngoại lệ thật, trong một phạm vi đủ nhỏ để kiểm soát. Kết quả của thí điểm là bằng chứng để quyết định mở rộng, điều chỉnh hay dừng, không phải một sản phẩm hoàn chỉnh.

Cách chọn phạm vi an toàn là đi theo ba mức năng lực. Quy trình chỉ cần hỏi đáp trên tài liệu, như trả lời chính sách nội bộ, là điểm khởi đầu ít rủi ro nhất. Quy trình cần tra cứu dữ liệu thời gian thực, như xem trạng thái đơn, đòi thêm kết nối hệ thống. Quy trình cần ghi dữ liệu hoặc ra quyết định, như duyệt mua hàng, nên để các đợt sau. Pilot đầu tiên nên nằm ở mức một hoặc hai, hoặc chỉ chạm mức ba dưới dạng tạo bản nháp chờ người duyệt.

2. Tám tiêu chí chấm điểm quy trình ứng viên

1. Khối lượng công việc

Quy trình phải đủ nhiều việc để thấy khác biệt. Một tác vụ chỉ xuất hiện vài lần mỗi tháng thì dù Agent làm tốt, thời gian tiết kiệm cũng khó đo. Hãy lấy số liệu thật từ hệ thống ticket, hộp thư hoặc sổ theo dõi thay vì ước lượng theo cảm giác của trưởng bộ phận.

2. Mức độ lặp lại

Việc lặp lại với cấu trúc tương tự, như phân loại email yêu cầu hay trả lời câu hỏi về chính sách, dễ đặt tiêu chí đúng sai hơn việc mỗi lần một kiểu. Dấu hiệu tốt là nhân viên đã có sẵn mẫu trả lời hoặc quy tắc xử lý ngầm. Nếu mỗi ca cần một người giỏi suy nghĩ lâu, đó chưa phải ứng viên cho pilot đầu.

3. Độ sẵn sàng dữ liệu

Kiểm tra tài liệu và dữ liệu cần dùng đã tồn tại, đủ mới và có người xác nhận là bản chính thức hay chưa. Quy trình mà thông tin còn nằm trong đầu vài nhân viên sẽ kéo pilot sang việc viết tài liệu. Nên ưu tiên nơi đã có kho chính sách, danh mục hoặc lịch sử xử lý rõ ràng.

4. Rủi ro khi sai

Hỏi thẳng: nếu Agent làm sai một lần thì hậu quả là gì và ai phát hiện. Phân loại nhầm một email nội bộ có thể sửa trong vài phút; báo sai giá cho khách hay duyệt nhầm khoản chi thì khó rút lại. Pilot đầu nên chọn nơi sai sót được phát hiện sớm và sửa được.

5. Khả năng đo kết quả

Trước khi bắt đầu phải có số liệu nền của cách làm hiện tại: thời gian xử lý, tỷ lệ sai, số việc tồn. Không có mốc so sánh thì cuối pilot chỉ còn cảm nhận. Nên chọn ít chỉ số nhưng đo được tự động, như thời gian từ lúc nhận yêu cầu đến lúc chuyển đúng người.

6. Người sở hữu nghiệp vụ

Mỗi pilot cần một người ở bộ phận nghiệp vụ có thời gian và thẩm quyền: xác nhận câu trả lời đúng, quyết định ngoại lệ, chấm kết quả. Quy trình không ai nhận làm chủ thường dừng giữa chừng dù công nghệ ổn. Đây là tiêu chí nên dùng để loại ứng viên sớm nhất.

7. Phạm vi tích hợp

Đếm số hệ thống cần kết nối và kiểm tra từng hệ thống đã có API chưa. Một pilot cần ba hệ thống, trong đó có một hệ thống cũ không có API, sẽ tốn phần lớn thời gian cho tích hợp thay vì đánh giá Agent. Tốt nhất là một hoặc hai nguồn, ưu tiên nguồn đã có cách kết nối ổn định.

8. Khả năng mở rộng

Quy trình đầu nên là phiên bản nhỏ của một nhu cầu lớn hơn. Nếu pilot phân loại email của phòng mua hàng thành công, cách làm có thể áp sang phòng kinh doanh hay chăm sóc khách hàng. Một quy trình quá đặc thù thì thành công cũng khó nhân rộng.

3. Quy trình thí điểm đề xuất

Bước 1: Xác định phạm vi và kết quả cần đo

Chấm điểm các quy trình ứng viên theo tám tiêu chí, chọn một, rồi viết rõ việc nào trong phạm vi và việc nào ngoài phạm vi. Đầu ra là bản mô tả pilot gồm chỉ số thành công, ngưỡng đạt và điều kiện dừng sớm. Người sở hữu nghiệp vụ và người duyệt ngân sách cùng ký.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Gom đúng các tài liệu và nguồn dữ liệu mà quy trình cần, không mở rộng thêm vì tiện. Cấp cho Agent quyền đọc tối thiểu và dùng dữ liệu thật đã lọc bớt thông tin không cần thiết. Đầu ra là danh sách nguồn có người xác nhận và tài khoản dịch vụ có phạm vi quyền đã được kiểm.

Bước 3: Thiết kế tích hợp, ngoại lệ và phê duyệt

Xác định Agent làm gì khi không chắc: chuyển cho ai, qua kênh nào, kèm thông tin gì. Trong pilot, mọi hành động ghi nên dừng ở dạng bản nháp để người duyệt. Đầu ra là sơ đồ luồng có đánh dấu điểm chuyển người, cùng quy trình thủ công dự phòng vẫn chạy song song.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Chạy với một nhóm người dùng nhỏ trong khoảng thời gian đã định, ghi nhật ký mọi yêu cầu, câu trả lời và ca chuyển người. Định kỳ ngồi cùng người sở hữu nghiệp vụ xem lại các ca sai để sửa dữ liệu hoặc quy tắc. Pilot kết thúc bằng báo cáo so sánh với số liệu nền và đề xuất mở rộng, điều chỉnh hay dừng.

4. Ví dụ giả định

Một công ty chọn phân loại email yêu cầu thay vì tự động phê duyệt mua hàng. Quy trình đầu có dữ liệu rõ, rủi ro thấp và dễ đo thời gian tiết kiệm; kết quả pilot cung cấp bằng chứng trước khi mở rộng.

Bộ ca thử cho pilot này lấy từ email thật của các kỳ trước: email rõ loại yêu cầu, email gộp hai yêu cầu, email viết tắt theo thói quen từng phòng, email không thuộc loại nào. Mỗi ca có nhãn đúng do người sở hữu nghiệp vụ gán trước. Khi kết thúc, công ty so sánh không chỉ tỷ lệ phân loại đúng mà cả thời gian email nằm chờ trong hộp thư chung, vì đó mới là vấn đề ban đầu.

5. Rủi ro và giới hạn

• Không chọn quy trình chỉ vì dễ trình diễn
• Tránh pilot quá rộng
• Đặt tiêu chí dừng và thành công trước
• Giữ quy trình thủ công dự phòng

Quy trình dễ trình diễn, như một trợ lý trả lời mọi câu hỏi của công ty, thường khó đo và khó giới hạn. Pilot quá rộng khiến lỗi của nhiều nguồn chồng lên nhau, không biết sửa chỗ nào trước. Tiêu chí thành công đặt ra sau khi đã có kết quả dễ bị chỉnh cho vừa kết quả, nên phải viết trước khi chạy. Trong suốt pilot, cách làm thủ công vẫn phải dùng được để khi Agent lỗi, công việc không bị đứng.

6. Phân chia trách nhiệm vận hành

Người sở hữu nghiệp vụ chọn quy trình, cung cấp ca thử, chấm kết quả và đưa ra quyết định cuối cùng về việc mở rộng. Đội kỹ thuật dựng Agent, kết nối nguồn dữ liệu, ghi nhật ký và báo cáo lỗi kỹ thuật tách riêng khỏi lỗi nội dung. Nhóm người dùng thử cần được biết mình đang tham gia thí điểm, được hướng dẫn cách báo câu trả lời sai và có kênh phản hồi nhanh.

Trong thời gian pilot, mỗi thay đổi về tài liệu, prompt hay quy tắc nên được ghi lại kèm ngày thay đổi; nếu không, cuối kỳ sẽ không biết kết quả tốt lên nhờ đâu. Nên có buổi xem lại định kỳ ngắn giữa người sở hữu nghiệp vụ và đội kỹ thuật để đi qua các ca sai nổi bật. Quyết định dừng sớm khi chạm điều kiện dừng thuộc về người sở hữu nghiệp vụ.

7. Chỉ số nên theo dõi

• Tỷ lệ hoàn thành đúng theo tiêu chí đã duyệt trước pilot
• Tỷ lệ từ chối đúng và chuyển người phụ trách
• Lỗi tích hợp, độ trễ và số thao tác phải sửa
• Chi phí và tác động so với số liệu nền của cách làm cũ

Số lượt người dùng thử tăng chỉ cho thấy họ tò mò. Kết luận của pilot nên dựa trên so sánh với số liệu nền: thời gian xử lý, tỷ lệ sai và khối lượng việc tồn trước và sau. Nên đọc thêm phản hồi của người dùng về những ca Agent làm sai, vì đó thường là nơi lộ ra yêu cầu thật cho giai đoạn mở rộng.

8. Checklist trước khi vận hành

• Quy trình đã được chấm theo tám tiêu chí và có người sở hữu
• Nguồn dữ liệu và chủ sở hữu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Số liệu nền, tiêu chí thành công và điều kiện dừng đã viết thành văn bản

9. Câu hỏi thường gặp

Có thể thí điểm AI Agent khi dữ liệu chưa chuẩn không? Có thể, nếu chọn quy trình cần ít dữ liệu và phần dữ liệu đó đã tương đối rõ. Nếu phải viết lại phần lớn tài liệu trước khi chạy, nên coi đó là việc chuẩn bị riêng, không gộp vào thời gian pilot.

Nên chọn quy trình nào để thí điểm AI Agent đầu tiên? Chọn quy trình có khối lượng đủ lớn, lặp lại, dữ liệu sẵn, sai thì sửa được và có người sở hữu nghiệp vụ rõ ràng. Phân loại yêu cầu, trả lời chính sách nội bộ hoặc tra cứu trạng thái là những ứng viên thường gặp.

Trong giai đoạn thí điểm, khi nào cần người duyệt? Mọi hành động ghi vào hệ thống, gửi thông tin ra ngoài hoặc ảnh hưởng tiền nên dừng ở bản nháp chờ người duyệt. Pilot là lúc thu bằng chứng về độ chính xác, chưa phải lúc trao quyền tự động.

Khi nào nên dừng một đợt thí điểm? Khi chạm điều kiện dừng đã viết từ đầu, chẳng hạn cùng một loại lỗi lặp lại dù đã sửa dữ liệu, hoặc người sở hữu nghiệp vụ không còn thời gian tham gia. Dừng đúng lúc vẫn là một kết quả có giá trị nếu có báo cáo lý do.

Kết luận

Quy trình đầu tiên nên được chọn vì dễ đo và dễ kiểm soát, không phải vì gây ấn tượng. Chấm điểm ứng viên theo tám tiêu chí, viết tiêu chí thành công và điều kiện dừng từ trước, giữ cách làm thủ công chạy song song.

Khi đã chọn được quy trình, hai câu hỏi tiếp theo thường là lập ngân sách AI Agent và thời gian triển khai.

Trao đổi với Naventic để chọn quy trình phù hợp cho đợt thí điểm AI Agent. Đọc thêm: AI Workflow Automation.