Một đợt chạy thử tác tử AI đầu tiên tốt cho doanh nghiệp nhỏ kéo dài sáu tới tám tuần, chỉ gồm một việc lặp lại rủi ro thấp, chạy trên tài khoản riêng với quyền hẹp, ban đầu có người duyệt từng hành động, và được chấm theo những con số đã đo trước khi bắt đầu. Cuối đợt, mình quyết giữ, sửa hay dừng dựa trên thời gian tiết kiệm, số lỗi bắt được và công sức giám sát, chứ không dựa trên màn trình diễn ấn tượng cỡ nào.
Bài này biến điều đó thành kế hoạch cụ thể: đợt thử phải chứng minh điều gì, các bước cài đặt, lịch theo từng tuần, một ví dụ từ một nhà phân phối, những chỉ số đáng đo, những sai lầm làm hỏng phần lớn đợt thử, câu cần hỏi nhà cung cấp, và những chỗ cần chuyên gia bên ngoài.
Đợt chạy thử cần chứng minh gì, và không chứng minh được gì?
Đợt chạy thử trả lời một câu hỏi hẹp: với đúng việc này, dữ liệu này, con người này, tác tử có tiết kiệm thời gian đáng kể mà không gây lỗi ngoài mức chấp nhận, và mình có giám sát nó với chi phí hợp lý được không? Đây không phải bài kiểm tra xem “AI có chạy không” nói chung, và cũng đừng dùng nó để lột xác cả công ty.
Nó cũng phải cho biết tác tử cư xử thế nào khi trục trặc: thiếu dữ liệu, đầu vào lạ, nhà cung cấp đổi mẫu chứng từ. Những lúc đó nói lên nhiều điều hơn các lần chạy êm. Đợt thử chỉ ghi lại thành công thì coi như chưa thử bao nhiêu.
Thứ đợt thử không chứng minh được là tác tử sẽ làm sao với việc khác, ở khối lượng lớn hơn nhiều, hay sau khi nhà cung cấp cập nhật mô hình. Coi một đợt thử thành công là giấy phép để đi tiếp cẩn thận, không phải lời bảo đảm.
Chọn việc là một nửa công sức. Tiêu chí được nói kỹ trong bài giao việc gì cho tác tử AI trước: lặp lại, có quy tắc, dữ liệu với tới được, dễ kiểm, dễ hoàn tác. Với đợt thử, thêm một tiêu chí: người đang làm việc đó phải sẵn lòng tham gia, vì hiểu biết của họ mới giúp đánh giá trung thực.
Cuối cùng, chốt ngân sách từ trước, gồm phí thuê bao, chi phí nhờ người cài đặt nếu có và số giờ nhân viên sẽ bỏ ra. Biết trước trần chi giúp đợt thử không lặng lẽ biến thành một dự án không có hồi kết.
Cài đặt đợt chạy thử từng bước
Mỗi bước tốn vài giờ chứ không phải vài tuần. Bỏ một bước thường tốn thời gian hơn về sau.
- Viết rõ việc và người phụ trách. Một đoạn mô tả việc, kết quả mong đợi, và tên người chịu trách nhiệm đợt thử.
- Đo số liệu nền. Hai tuần trước khi thử, ghi lại việc tốn bao lâu, xử lý bao nhiêu món, sai bao nhiêu. Không có số này thì mọi lời khen “cải thiện” chỉ là đoán.
- Chọn công cụ. Ưu tiên sản phẩm cho cấp quyền hẹp, có bước duyệt và nhật ký dễ đọc. Kiểm điều khoản dữ liệu với người lo pháp lý hoặc IT.
- Tạo tài khoản riêng với quyền tối thiểu. Chỉ đọc khi được, đúng thư mục hay hộp thư cần, tạo nháp thay vì gửi, có hạn mức chi. Tuyệt đối không đưa mật khẩu quản trị.
- Viết bản giao việc. Mục tiêu, nguồn dữ liệu, điều không được làm, cách xử lý chỗ mơ hồ, báo cáo phải có gì.
- Thử trên bản sao. Cho tác tử chạy trên dữ liệu tháng trước hoặc bản sao tệp, rồi so đầu ra của nó với những gì nhân viên đã thật sự làm.
- Chạy thật với duyệt toàn bộ. Những tuần đầu, mọi hành động làm thay đổi dữ liệu đều phải chờ người duyệt.
- Rà hằng tuần và điều chỉnh. Dùng một quy trình ngắn như trong bài giám sát tác tử AI bằng điểm duyệt và nhật ký, ghi lại mọi thay đổi ở bản giao việc hay quyền hạn.
Ghi lại từng quyết định. Cuối đợt, chính bản ghi đó giúp mình giải thích kết quả với đồng nghiệp hay nhà đầu tư.
Lịch theo từng tuần
Chỉnh độ dài cho hợp với việc của mình, nhưng giữ đủ các giai đoạn.
| Tuần | Giai đoạn | Làm gì | Điều kiện qua giai đoạn |
|---|---|---|---|
| Trước khi bắt đầu | Số liệu nền | Đo thời gian, khối lượng, lỗi của việc làm tay | Có hai tuần số liệu đáng tin |
| 1 | Cài đặt và chạy khô | Tạo tài khoản, cấp quyền, viết bản giao việc, thử trên dữ liệu sao chép | Đầu ra của tác tử khớp đầu ra của nhân viên trên dữ liệu thử |
| 2–3 | Chạy thật, duyệt toàn bộ | Tác tử làm trên dữ liệu thật; người duyệt mọi thay đổi | Ít lần bị từ chối, và hiểu được lý do |
| 4–5 | Duyệt chọn lọc | Chỉ duyệt hành động nhạy cảm; rà mẫu hằng tuần | Tỉ lệ lỗi trong mẫu bằng hoặc thấp hơn mức nền |
| 6–7 | Ổn định | Giám sát theo quy trình thường; theo dõi thời gian và chi phí | Kết quả ổn định hai tuần liền |
| 8 | Quyết định | So với số liệu nền; quyết giữ, sửa hay dừng | Có quyết định bằng văn bản kèm lý do |
Giai đoạn nào chưa đạt điều kiện thì kéo dài hoặc lùi lại một giai đoạn. Cứ theo lịch mà tiến khi bằng chứng nói ngược lại là con đường dẫn đợt thử tới sự cố.
Ví dụ cụ thể: nhập đơn hàng ở một nhà phân phối
Một nhà phân phối vật liệu xây dựng ở Đồng Nai mỗi ngày nhận vài chục đơn qua email từ các nhà thầu quen, nhiều khi là ảnh chụp danh sách viết tay hoặc tin nhắn cụt lủn. Hai nhân viên gõ lại vào hệ thống bán hàng. Sai số lượng hay mã hàng làm giao nhầm vài lần mỗi tháng.
Việc thử rất hẹp: đọc email đặt hàng gửi về một địa chỉ chung, tách ra tên khách, mặt hàng, số lượng, khớp mặt hàng với danh mục sản phẩm, rồi tạo đơn nháp trong một bảng trung gian. Nhân viên xem từng đơn nháp rồi mới nhập vào hệ thống thật. Tác tử chỉ được đọc đúng hộp thư đó và chỉ được ghi vào đúng một bảng.
Số liệu nền cho thấy việc gõ chiếm gần hết buổi sáng, mỗi tháng sai một ít. Hai tuần đầu, tác tử làm đúng khung nhưng hay khớp nhầm tên hàng mà các nhà thầu viết tắt theo kiểu địa phương. Nhóm thêm một danh sách ngắn các cách viết tắt hay gặp vào bản giao việc, và độ khớp tốt lên rõ.
Ảnh chụp viết tay vẫn là điểm yếu. Nhóm sửa bản giao việc để tác tử gắn cờ mọi đơn từ ảnh khó đọc cho người nhập tay, thay vì đoán. Lỗi giảm, đổi lại một số đơn vẫn phải làm tay.
Tới tuần thứ tám, thời gian gõ giảm đáng kể, lỗi lọt tới khách thấp hơn mức nền, và mỗi lô duyệt chỉ mất vài phút. Công ty giữ tác tử, vẫn để nhân viên xác nhận từng đơn, và quyết chưa cho nó ghi thẳng vào hệ thống bán hàng cho tới khi có thành tích dài hơn.
Những con số nào cho biết đợt thử thành công?
Tổng thời gian mỗi món, tính cả duyệt. So với mức nền. Chỉ tính thời gian nháp là thổi phồng lợi ích.
Lỗi lọt tới khách hoặc vào hệ thống thật. Đây là con số quan trọng nhất. Nó không được tệ hơn trước.
Lỗi bị bắt ở khâu duyệt. Lúc đầu nhiều là bình thường; nó phải giảm dần khi chỉ dẫn tốt lên.
Tỉ lệ món không cần người sửa. Cho thấy chỗ nào tác tử tin được, chỗ nào cần đỡ.
Số món bị gắn cờ không rõ. Tác tử khoẻ mạnh gắn cờ những ca thật sự mơ hồ thay vì đoán.
Chi phí mỗi món. Phí thuê bao, lượng dùng và thời gian giám sát chia cho khối lượng.
Ý kiến nhân viên. Hỏi người trong cuộc xem việc dễ hơn, khó hơn hay chỉ khác đi. Nhận định của họ thường dự báo được chuyện lâu dài.
Sự cố. Mọi hành động ngoài bản giao việc, mọi lần lộ dữ liệu, mọi khiếu nại của khách liên quan tới tác tử.
Những sai lầm làm hỏng phần lớn đợt thử
Chọn quy trình khó nhất trước. Việc phức tạp, nhiều ngoại lệ hỏng theo kiểu khó hiểu và giết niềm tin ngay từ đầu.
Không có số liệu nền. Không có số trước thì thành công chỉ là cảm nhận, mà thường là cảm nhận hào hứng.
Nối tài khoản cá nhân của chủ. Cài nhanh, nhưng không khoanh vùng được, và trộn việc của tác tử với việc của người.
Nới duyệt theo lịch thay vì theo bằng chứng. “Tuần thứ tư rồi, thôi khỏi duyệt” là lờ đi điều nhật ký đang nói.
Gạt nhân viên ra ngoài. Người đang làm việc đó biết các ngoại lệ. Gạt họ ra thì tác tử kém hơn và đồng nghiệp thêm lo.
Đổi nhiều thứ cùng lúc. Cùng một tuần đổi bản giao việc, đổi công cụ, đổi phạm vi thì không biết cái gì có tác dụng.
Quên chi phí giám sát. Tác tử tiết kiệm hai giờ mà tốn hai giờ kiểm thì chẳng tiết kiệm gì.
Tuyên bố thắng quá sớm. Hai tuần tốt là đáng mừng, chưa phải kết luận. Theo dõi hiện tượng trôi dần sau khi đợt thử kết thúc.
Câu nên hỏi nhà cung cấp tác tử AI
Sản phẩm cần những quyền gì, thu hẹp được không? Tìm tuỳ chọn giới hạn vào đúng thư mục, hộp thư hay hành động.
Hành động nào có thể bắt duyệt? Mình phải được tự chọn, không chỉ chấp nhận mặc định của nhà cung cấp.
Ghi nhật ký những gì, xuất ra được không? Nhật ký phải cho thấy nguồn đã đọc, hành động đã làm, lần duyệt, ở dạng mình giữ được.
Dữ liệu của mình được dùng thế nào, lưu ở đâu? Hỏi có dùng để huấn luyện không, giữ bao lâu. Xin câu trả lời bằng văn bản.
Sản phẩm xử lý nội dung không đáng tin thế nào? Email và trang web có thể chứa chỉ dẫn giấu. Hỏi có lớp bảo vệ gì.
Thu hồi quyền tức thì bằng cách nào? Phải có cách dừng và ngắt kết nối tác tử rõ ràng, có tài liệu hướng dẫn.
Mô hình bên dưới cập nhật thì sao? Hỏi có báo trước không, và hành vi có thể đổi mà không cảnh báo không.
Trong đợt thử được hỗ trợ ra sao? Doanh nghiệp nhỏ được lợi nhiều khi có một đầu mối cụ thể trả lời nhanh các câu hỏi thực tế.
Khi nào cần chuyên gia bên ngoài?
Tác tử sẽ đụng tới dữ liệu cá nhân của khách hàng hay nhân viên thì hỏi luật sư xem quy định hiện hành về bảo vệ dữ liệu cá nhân áp dụng thế nào, gồm sự đồng ý, nơi lưu trữ, và xử lý ra sao nếu dữ liệu bị lộ. Quy định ở Việt Nam về các vấn đề này đang được hoàn thiện, nên dựa vào tư vấn cập nhật chứ đừng dựa vào bài viết cũ.
Tác tử sẽ nối vào hệ thống lõi như kế toán, bán hàng hay nền tảng ngân hàng thì cần người làm IT chuyên nghiệp cài tài khoản, quyền hạn và nhật ký cho đúng. Cấu hình quyền sai là con đường phổ biến nhất biến một đợt thử nhỏ thành sự cố lớn.
Tác tử sẽ ảnh hưởng tới chứng từ thuế, hoá đơn hay báo cáo tài chính thì nhờ kế toán rà quy trình. Một bảng tính trông gọn gàng vẫn có thể trái một yêu cầu mà tác tử không hề biết.
Và nếu có ai hứa tác tử sẽ thay được nhân viên hay tự hoàn vốn trong một khoảng thời gian cố định, hãy xin bằng chứng từ doanh nghiệp giống mình, và tự tính lấy các con số. Nhà cung cấp tử tế nói về chạy thử, giới hạn và giám sát; bị giục chốt nhanh là lý do để chậm lại.
Sau đợt thử: mở rộng từ từ
Một đợt thử thành công tạo sức ép mở rộng nhanh: thêm việc, thêm phòng ban, thêm quyền tự chủ. Đừng làm cả ba cùng lúc. Thứ tự an toàn thường là giữ nguyên việc cũ và nới phạm vi một chút, chẳng hạn từ một hộp thư lên hai, rồi mới thêm loại việc mới.
Mỗi việc mới xứng đáng một đợt thử ngắn riêng, dù ngắn hơn lần đầu. Bài học chuyển sang được, nhưng các ngoại lệ thì không. Tác tử nhập đơn giỏi có thể lúng túng với khiếu nại, nơi giọng điệu và óc phán đoán quan trọng hơn việc trích dữ liệu.
Giữ giấy tờ gọn nhưng có thật. Mỗi tác tử đang dùng nên có một dòng trong danh sách chung: làm việc gì, ai phụ trách, vào được đâu, lần rà gần nhất khi nào. Khi có người nghỉ việc hay công cụ thay đổi, danh sách đó cho biết cần kiểm những gì.
Cuối cùng, để ý các chi phí lặng lẽ. Tác tử nhiều lên thì thuê bao, quyền hạn và việc rà soát cũng nhiều lên. Mỗi quý nhìn lại tất cả tác tử một lượt, hỏi cái nào còn xứng đáng, để khỏi tích tụ một mớ công cụ giám sát nửa vời ở phía sau.
Câu hỏi thường gặp
Đợt chạy thử tác tử AI nên kéo dài bao lâu?
Sáu tới tám tuần hợp với phần lớn việc đơn giản, cộng hai tuần đo số liệu nền trước đó. Ngắn hơn thì hiếm khi gặp đủ ca bất thường; dài hơn thì dễ mất tập trung.
Một đợt thử tốn bao nhiêu tiền?
Tuỳ cách tính giá của công cụ, khối lượng việc và mức cần người hỗ trợ cài đặt. Chi phí ẩn lớn nhất thường là thời gian nhân viên duyệt, nên tính cả vào ngân sách.
Có cần người kỹ thuật trong nhóm không?
Với công cụ làm sẵn và việc đơn giản, một người phụ trách cẩn thận không chuyên kỹ thuật vẫn chạy được đợt thử. Nối vào hệ thống lõi hay cài đặt riêng thì cần người làm IT, ít nhất ở khâu quyền hạn và nhật ký.
Đợt thử thất bại thì sao?
Một câu “không” rõ ràng cũng là kết quả có ích: mình biết việc hoặc công cụ chưa sẵn sàng, với chi phí có giới hạn. Ghi lại lý do để lần thử sau bắt đầu từ hiểu biết đó.
Có nên báo khách là mình đang dùng tác tử AI không?
Tác tử giao tiếp với khách hay xử lý dữ liệu của họ thì minh bạch là khôn ngoan, và có thể bắt buộc theo quy định nền tảng hoặc pháp luật. Hỏi luật sư về nghĩa vụ công khai áp dụng cho doanh nghiệp mình.
Có chạy hai đợt thử cùng lúc được không?
Chỉ khi hai đợt dính tới nhóm và việc khác nhau, mỗi đợt có người phụ trách và số liệu nền riêng. Với lần đầu, mỗi lúc một đợt cho bài học rõ ràng hơn.
