Quy trình phù hợp để tự động hoá là quy trình có khối lượng lớn, quy tắc rõ, dữ liệu đầu vào có cấu trúc, ít ngoại lệ và ổn định trong ít nhất một hai năm tới. Thiếu một trong các điều kiện đó, chi phí xây và bảo trì dễ vượt lợi ích. Thiếu hai, dự án gần như chắc chắn thành gánh nặng.
Sai lầm hay gặp nhất không nằm ở công nghệ mà ở khâu chọn: doanh nghiệp tự động hoá quy trình "gây khó chịu nhất" thay vì quy trình "đáng tự động hoá nhất". Hai thứ đó thường không trùng nhau. Quy trình gây khó chịu thường là quy trình nhiều ngoại lệ, nhiều phán đoán — đúng loại bot làm dở.
Bài này đưa ra bảy tiêu chí, một ma trận chấm điểm có trọng số dùng được ngay trong buổi họp, cách đo khối lượng thực tế thay vì ước đoán, và danh sách các quy trình nên chuẩn hoá hoặc bỏ đi trước khi nghĩ đến bot.
Bảy tiêu chí đánh giá một quy trình
Khối lượng và tần suất. Bao nhiêu giao dịch mỗi tháng, mỗi giao dịch mất bao nhiêu phút công? Một việc 3 phút làm 40 lần mỗi ngày đáng quan tâm hơn một việc 2 giờ làm mỗi quý một lần, dù việc sau "nặng" hơn trong cảm nhận.
Mức độ dựa trên quy tắc. Có thể viết toàn bộ logic thành các mệnh đề "nếu… thì…" mà không cần câu "tuỳ trường hợp" không? Chỗ nào cần phán đoán, đó là điểm phải giữ lại cho người.
Dữ liệu đầu vào có cấu trúc. Dữ liệu đến từ hệ thống, tệp có định dạng cố định, biểu mẫu điện tử thì dễ; đến từ thư tự do, ảnh chụp, giấy viết tay thì phải thêm bước nhận dạng và kiểm tra, làm tăng chi phí và rủi ro.
Tỷ lệ ngoại lệ. Trong 100 giao dịch, bao nhiêu cái đi lệch luồng chuẩn? Tỷ lệ ngoại lệ cao làm bot liên tục đẩy việc lại cho người, và phần tiết kiệm co lại rất nhanh.
Độ ổn định của quy trình và hệ thống. Quy trình có sắp thay đổi vì luật mới, tổ chức lại, thay phần mềm không? Tự động hoá một quy trình sẽ đổi trong sáu tháng là xây nhà trên cát.
Rủi ro và giá trị của sai sót. Lỗi do người gây ra hậu quả gì: phạt chậm nộp, sai số liệu báo cáo, khách hàng phàn nàn? Quy trình có chi phí sai sót cao đáng tự động hoá ngay cả khi khối lượng vừa phải, với điều kiện kiểm soát chặt.
Số hệ thống phải đi qua. Mỗi hệ thống thêm vào là một điểm có thể hỏng. Quy trình đi qua bảy ứng dụng, trong đó hai cái thường xuyên chậm, có xác suất chạy trơn tru thấp hơn nhiều so với quy trình đi qua hai ứng dụng.
Ma trận chấm điểm có trọng số
Chấm mỗi tiêu chí từ 1 (kém phù hợp) đến 5 (rất phù hợp), nhân trọng số, cộng lại. Trọng số dưới đây là gợi ý; mỗi doanh nghiệp nên tự điều chỉnh và ghi lại lý do.
| Tiêu chí | Trọng số | Điểm 1 khi | Điểm 5 khi |
|---|---|---|---|
| Khối lượng × thời gian | 25% | Dưới vài giờ công mỗi tháng | Hàng chục giờ công trở lên mỗi tháng |
| Dựa trên quy tắc | 20% | Nhiều bước cần phán đoán | Toàn bộ logic viết được thành quy tắc |
| Dữ liệu có cấu trúc | 15% | Thư tự do, ảnh, viết tay | Dữ liệu từ hệ thống hoặc biểu mẫu cố định |
| Tỷ lệ ngoại lệ | 15% | Trên một phần tư số giao dịch | Dưới vài phần trăm |
| Ổn định | 10% | Sắp đổi luật, đổi phần mềm | Không dự kiến đổi trong hai năm |
| Giá trị giảm sai sót | 10% | Sai sót ít hậu quả | Sai sót gây phạt hoặc mất khách |
| Số hệ thống | 5% | Năm hệ thống trở lên | Một đến hai hệ thống |
Ví dụ giả định: quy trình đối chiếu công nợ nhà cung cấp chấm 4, 5, 4, 3, 4, 4, 4 → tổng có trọng số 4,05. Quy trình xử lý khiếu nại khách hàng chấm 3, 2, 1, 2, 3, 4, 3 → 2,35. Ngưỡng hợp lý để vào danh sách ưu tiên thường quanh 3,5; dưới 2,5 thì nên tìm cách khác.
Giá trị thật của ma trận không nằm ở con số cuối mà ở cuộc thảo luận khi chấm: hai trưởng phòng chấm cùng một quy trình chênh nhau hai điểm là dấu hiệu quy trình chưa được hiểu giống nhau.
Đo khối lượng thật thay vì ước đoán
Con số "mỗi ngày mất cả buổi" trong buổi họp thường lệch xa thực tế, theo cả hai hướng. Trước khi chấm điểm, hãy đo:
- Lấy số giao dịch từ hệ thống trong ít nhất ba tháng, gồm cả tháng cao điểm. Số đơn, số hoá đơn, số hồ sơ — không dùng trí nhớ.
- Bấm giờ mẫu 20–30 giao dịch do vài người khác nhau làm, ghi riêng thời gian luồng chuẩn và thời gian xử lý ngoại lệ.
- Đếm ngoại lệ theo loại: thiếu dữ liệu, sai định dạng, cần hỏi lại bộ phận khác, cần phê duyệt đặc biệt. Ba loại đầu tiên thường chiếm phần lớn.
- Ghi lại các hệ thống và màn hình phải đi qua, kể cả những bảng tính trung gian "không chính thức" mà nhân viên tự lập.
- Tính giờ công mỗi tháng = số giao dịch × thời gian trung bình, tách phần tự động hoá được và phần buộc phải giữ cho người.
- Đối chiếu với người làm thật: đưa kết quả cho chính nhân viên đọc lại. Họ thường chỉ ra ngay bước mà quản lý không biết là có.
Nếu dữ liệu nhật ký của hệ thống đủ tốt, có thể dùng khai phá quy trình (process mining) để thấy luồng thực tế và tỷ lệ ngoại lệ thay cho bấm giờ thủ công — chủ đề có bài riêng trên chuyên mục này.
Chuẩn hoá trước, tự động hoá sau
Một quy trình chấm điểm thấp chưa chắc là ứng viên tồi vĩnh viễn; nhiều khi nó chỉ chưa được chuẩn hoá. Ví dụ, tỷ lệ ngoại lệ cao vì mỗi chi nhánh gửi bảng kê theo một mẫu khác nhau. Thống nhất một biểu mẫu, bắt buộc các trường dữ liệu, bỏ hai bước xác nhận trùng lặp — chỉ riêng việc đó có thể giảm thời gian xử lý đáng kể trước khi viết một dòng kịch bản bot.
Tư duy này có gốc từ phong trào tái cấu trúc quy trình đầu thập niên 1990 và từ Lean: loại bỏ lãng phí trước, rồi mới tăng tốc phần còn lại. Thứ tự hợp lý là bỏ — gộp — chuẩn hoá — tự động hoá. Đảo thứ tự, bạn sẽ có một bot chạy rất nhanh qua các bước không ai cần.
Một phép thử đơn giản: yêu cầu người phụ trách mô tả quy trình bằng văn bản sao cho một nhân viên mới làm được ngay mà không cần hỏi. Nếu không viết được, quy trình chưa sẵn sàng cho bot. Nếu viết được nhưng dài mười trang với ba mươi nhánh rẽ, hãy hỏi những nhánh nào thực sự cần.
Những quy trình nên tránh hoặc để sau
Quy trình đang thay đổi. Doanh nghiệp đang chuyển phần mềm kế toán, đang tổ chức lại phòng ban, hoặc quy định liên quan vừa sửa và chưa có hướng dẫn ổn định. Đợi hệ thống mới vào ổn định rồi đánh giá lại.
Quy trình mà lỗi bot khó phát hiện. Bot ghi sai số liệu vào sổ cái mà không ai kiểm cho đến khi kiểm toán cuối năm. Nếu chưa có cách đối chiếu đầu ra, đừng tự động hoá.
Quy trình chủ yếu là giao tiếp. Thuyết phục khách hàng, xử lý khiếu nại phức tạp, thương lượng với nhà cung cấp. Bot có thể chuẩn bị dữ liệu, nhưng phần cốt lõi vẫn là người.
Quy trình khối lượng nhỏ nhưng "phiền". Làm mỗi tháng hai lần, mỗi lần nửa giờ. Chi phí xây, kiểm thử và bảo trì bot gần như không bao giờ thu hồi được.
Quy trình đi qua hệ thống có điều khoản cấm tự động hoá. Một số cổng thông tin của đối tác hoặc cơ quan có điều khoản sử dụng hạn chế truy cập tự động, hoặc dùng cơ chế chống bot. Phải kiểm điều khoản và hỏi bên quản lý hệ thống; vượt qua cơ chế đó là vi phạm, không phải mẹo kỹ thuật.
Các thiên lệch hay gặp khi chấm điểm
Thiên lệch do dễ nhớ. Quy trình vừa gây sự cố tuần trước được chấm cao hơn thực tế, vì ký ức gần và sống động. Đây là biểu hiện của heuristic sẵn có mà Tversky và Kahneman mô tả từ năm 1973. Cách chống là dựa vào số giao dịch đo từ hệ thống, không dựa vào cảm giác.
Ý kiến của người có chức vụ cao nhất. Một quy trình được lãnh đạo nhắc đến trong cuộc họp dễ được xếp đầu danh sách dù điểm thấp. Ma trận chỉ có ích khi mọi người chấm độc lập trước rồi mới thảo luận.
Đánh giá thấp chi phí bảo trì. Người đề xuất tính chi phí xây bot nhưng quên chi phí sửa mỗi khi hệ thống cập nhật, chi phí người xử lý ngoại lệ, chi phí giấy phép hằng năm. Khi tính lợi ích, hãy tính trên vòng đời ba năm chứ không phải tháng đầu tiên.
Đếm thời gian tiết kiệm như thể là tiền. Mười giờ công tiết kiệm mỗi tháng chỉ thành tiền khi doanh nghiệp giảm tuyển mới, giảm làm thêm giờ, hoặc dùng thời gian đó vào việc tạo ra giá trị đo được. Nếu không, đó là năng lực rảnh, vẫn có giá trị nhưng không phải dòng tiền.
Từ danh sách ứng viên đến lộ trình
Sau khi chấm, xếp các quy trình lên một ma trận hai trục: trục ngang là độ dễ triển khai (dữ liệu có cấu trúc, ít hệ thống, ít ngoại lệ), trục dọc là giá trị (giờ công, giảm sai sót, tốc độ phục vụ). Góc "dễ và giá trị cao" là đợt một; góc "khó và giá trị cao" cần chuẩn hoá hoặc tích hợp trước; góc "dễ và giá trị thấp" chỉ làm khi đội đã có khuôn mẫu sẵn; góc còn lại bỏ qua.
Đợt một nên gồm hai đến bốn quy trình, đủ để chứng minh giá trị và xây khuôn mẫu (cách đặt tên, cách xử lý lỗi, cách bàn giao), không nhiều đến mức đội triển khai bị dàn mỏng. Một quy trình thử nghiệm thành công với số đo trước–sau rõ ràng có sức thuyết phục hơn mười bản trình bày.
Cuối cùng, ghi lại danh mục quy trình cùng điểm số và lý do trong một nơi mọi người tra được. Sáu tháng sau, khi hệ thống thay đổi hoặc khối lượng tăng, bạn chấm lại thay vì bắt đầu cuộc tranh luận từ đầu.
Câu hỏi thường gặp
Có nên để nhân viên tự đề xuất quy trình cần tự động hoá không?
Nên, vì người làm hằng ngày biết rõ việc lặp lại nằm ở đâu. Nhưng đề xuất cần đi qua cùng bộ tiêu chí và cách đo, nếu không danh sách sẽ nghiêng về việc gây khó chịu nhất. Nhiều tổ chức mở kênh đề xuất kèm biểu mẫu ngắn hỏi khối lượng, số hệ thống và tỷ lệ ngoại lệ ước tính.
Tỷ lệ ngoại lệ bao nhiêu thì vẫn chấp nhận được?
Không có con số chuẩn chung. Điều quan trọng là ngoại lệ được bot nhận ra và chuyển cho người một cách sạch sẽ, kèm lý do. Tỷ lệ ngoại lệ vừa phải vẫn đáng làm nếu luồng chuẩn chiếm phần lớn thời gian; nếu xử lý ngoại lệ chiếm phần lớn thời gian thì lợi ích rất mỏng.
Quy trình chỉ một người biết làm có nên tự động hoá không?
Đây thường là rủi ro vận hành đáng xử lý, nhưng bước đầu tiên là ghi chép quy trình và đào tạo người thứ hai, không phải viết bot. Tự động hoá một quy trình chỉ một người hiểu sẽ biến rủi ro người thành rủi ro bot mà không ai sửa được.
Làm sao biết quy trình có ổn định trong hai năm tới không?
Hỏi ba nguồn: kế hoạch CNTT có định thay hệ thống nào không, bộ phận pháp chế có biết quy định nào sắp sửa không, và lãnh đạo có kế hoạch tái cơ cấu bộ phận liên quan không. Ghi nhận rủi ro thay vì đoán, và chọn thiết kế dễ sửa nếu chưa chắc.
Ma trận chấm điểm có nên dùng cho cả dự án tích hợp và workflow không?
Có, phần lớn tiêu chí dùng chung. Khác biệt nằm ở chi phí: tích hợp qua API tốn nhiều hơn lúc đầu nhưng bền hơn, nên quy trình khối lượng lớn và sống lâu thường nghiêng về tích hợp. Nên chấm quy trình trước, rồi mới chọn công cụ.
Có nên tự động hoá một phần quy trình không?
Thường là nên. Tự động hoá các bước chuẩn như thu thập, đối chiếu, chuẩn bị dữ liệu và để người làm bước phán đoán cuối là cách phân chia hợp lý. Điều cần làm rõ là ranh giới bàn giao giữa bot và người, kể cả người nhận việc biết bot đã làm đến đâu.