Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được sếp giao một ngân sách 500 triệu đồng để "tự động hóa quy trình" trong năm nay. Trên bàn bạn là danh sách 40 quy trình mà các phòng ban gửi lên, ai cũng kêu quy trình của mình "khổ lắm, làm thủ công mệt mỏi lắm, anh tự động hóa giúp em". Bạn sẽ bắt đầu từ đâu? Tự động hóa cái nào trước? Cái nào nên để yên? Cái nào tuyệt đối không được đụng vào vì sẽ phản tác dụng?
Đây chính xác là tình huống mà mọi Business Process Analyst phải đối mặt. Và sự thật phũ phàng là: phần lớn các dự án tự động hóa thất bại không phải vì công nghệ kém, mà vì chọn sai quy trình để tự động hóa ngay từ đầu. Người ta đổ tiền vào một quy trình có vẻ "hoành tráng" nhưng tần suất chạy thấp, hoặc tự động hóa một quy trình đầy ngoại lệ khiến robot/hệ thống liên tục "vấp ngã", cuối cùng tốn nhiều công bảo trì hơn cả làm tay.
Bài học hôm nay trang bị cho bạn một công cụ rất thực dụng: mô hình chấm điểm ứng viên tự động hóa (Automation Candidate Scoring). Đây là cách để bạn biến cảm tính ("quy trình này có vẻ tự động hóa được") thành một con số có cơ sở, có thể so sánh, có thể bảo vệ trước hội đồng đầu tư. Nó giúp bạn trả lời câu hỏi vàng: trong hàng chục quy trình, đâu là những "quả ngọt dễ hái" (quick wins) đáng làm trước tiên.
Lưu ý: bài này tập trung vào việc xếp hạng và lựa chọn ứng viên trước khi triển khai. Việc chấm điểm ROI bằng mô phỏng (Bài 34), hay phân biệt BPM với RPA với AI trong hyperautomation (Bài 51) là chủ đề riêng — ở đây ta chỉ làm rõ một mắt xích: làm sao quyết định "nên tự động hóa cái gì".
Khái niệm cốt lõi
Automation Candidate Scoring là quá trình đánh giá một quy trình theo nhiều tiêu chí được định lượng, mỗi tiêu chí cho một số điểm, rồi tổng hợp lại thành một điểm số duy nhất để xếp hạng mức độ "đáng tự động hóa". Triết lý đằng sau nó rất đơn giản: không phải quy trình nào cũng xứng đáng được tự động hóa, và không phải quy trình nào cũng có thể tự động hóa một cách hiệu quả.
Ta sẽ dùng một bộ 6 tiêu chí, mỗi tiêu chí chấm trên thang 1 đến 5 điểm (1 = rất kém phù hợp, 5 = rất phù hợp). Bộ này được chắt lọc từ các khung đánh giá phổ biến trong ngành RPA và BPM.
Tiêu chí 1 — Volume (Khối lượng)
Số lượng instance (lượt chạy) của quy trình mỗi tháng. Logic ở đây là: tự động hóa có chi phí đầu tư cố định (xây dựng, kiểm thử, bảo trì). Quy trình chạy càng nhiều lần, chi phí đó càng được "chia đều" và hoàn vốn càng nhanh.
- 1 điểm: dưới 50 lượt/tháng
- 3 điểm: 200–1.000 lượt/tháng
- 5 điểm: trên 5.000 lượt/tháng
Tiêu chí 2 — Repetitiveness (Tính lặp lại)
Phần trăm các bước giống hệt nhau giữa các lượt chạy. Một quy trình mà mỗi lần làm mỗi khác, phụ thuộc nhiều vào phán đoán con người, sẽ rất khó để máy móc thay thế. Ngược lại, một quy trình mà 95% các lần đều thực hiện đúng những thao tác như nhau là ứng viên lý tưởng.
- 1 điểm: mỗi lượt chạy mỗi khác, nhiều phán đoán
- 5 điểm: trên 90% các bước giống hệt nhau mỗi lần
Tiêu chí 3 — Rule-based (Tính dựa trên quy tắc)
Quy trình có được điều khiển bởi các quy tắc rõ ràng, dạng "nếu… thì…", hay phụ thuộc vào trực giác, sự khéo léo, đàm phán? Máy móc xử lý logic tường minh rất giỏi nhưng "tịt" trước những quyết định mơ hồ. Nếu một bước cần "cảm nhận thái độ khách hàng" thì đó không phải rule-based.
- 1 điểm: nhiều quyết định cảm tính, mơ hồ
- 5 điểm: mọi quyết định đều có quy tắc rõ ràng, viết được ra giấy
Tiêu chí 4 — Data digitization (Mức độ số hóa dữ liệu)
Dữ liệu đầu vào đã ở dạng số hóa, có cấu trúc (structured) chưa? Nếu đầu vào là form điện tử, dữ liệu từ database, file Excel chuẩn — tuyệt vời. Nếu đầu vào là giấy viết tay, ảnh chụp mờ, file scan chất lượng kém — bạn sẽ phải thêm tầng OCR/AI, làm tăng độ phức tạp và tỷ lệ lỗi.
- 1 điểm: dữ liệu giấy, viết tay, không cấu trúc
- 3 điểm: dữ liệu số nhưng bán cấu trúc (PDF, email)
- 5 điểm: dữ liệu số hoàn toàn, có cấu trúc, qua API/database
Tiêu chí 5 — Stability (Độ ổn định)
Quy trình và các hệ thống liên quan có ổn định không, hay thường xuyên thay đổi? Tự động hóa một quy trình mà giao diện phần mềm, biểu mẫu, hay chính sách thay đổi mỗi quý sẽ khiến bạn phải sửa robot liên tục — chi phí bảo trì "ăn" hết lợi ích. Quy trình càng ổn định, tự động hóa càng bền.
- 1 điểm: thay đổi liên tục, hệ thống chưa hoàn thiện
- 5 điểm: ổn định nhiều năm, ít thay đổi
Tiêu chí 6 — Exception rate (Tỷ lệ ngoại lệ)
Đây là tiêu chí "nghịch" — tỷ lệ các trường hợp đi chệch khỏi luồng chuẩn (happy path) càng cao thì điểm càng thấp. Một quy trình mà cứ 10 lượt thì 4 lượt rơi vào tình huống đặc biệt cần con người xử lý thì giá trị tự động hóa giảm mạnh, vì bạn vẫn phải bố trí người trực để "đỡ" các ngoại lệ.
- 1 điểm: trên 30% lượt chạy là ngoại lệ
- 5 điểm: dưới 5% lượt chạy là ngoại lệ
Tổng hợp điểm và phân nhóm
Tổng điểm tối đa là 30 (6 tiêu chí × 5 điểm). Cách phân nhóm thực dụng:
- 24–30 điểm: Ứng viên hạng A — quick win, làm ngay.
- 18–23 điểm: Hạng B — tiềm năng, cần tối ưu quy trình trước hoặc chia nhỏ phạm vi.
- 12–17 điểm: Hạng C — chưa sẵn sàng, nên cải tiến thủ công (Bài 49) trước.
- Dưới 12 điểm: Không nên tự động hóa lúc này.
Tình huống thực tế
Ví dụ 1 — Ngân hàng số tại TP.HCM: chọn đúng "quả ngọt dễ hái"
Một ngân hàng thương mại cổ phần (giả định tên TPDigi Bank) lập đội tự động hóa với ngân sách hạn chế, phải chọn 2 quy trình trong số 5 đề xuất. Đội Business Process Analyst chấm điểm như sau:
| Quy trình | Volume | Repeat | Rule | Data | Stability | Exception | Tổng |
|---|---|---|---|---|---|---|---|
| Đối chiếu sao kê liên ngân hàng | 5 | 5 | 5 | 5 | 4 | 4 | 28 |
| Mở tài khoản tiết kiệm online | 5 | 4 | 4 | 4 | 3 | 4 | 24 |
| Phê duyệt vay tín chấp | 4 | 2 | 2 | 3 | 3 | 2 | 16 |
| Xử lý khiếu nại khách hàng | 4 | 1 | 1 | 2 | 3 | 1 | 12 |
| Soạn báo cáo lãnh đạo hàng tháng | 1 | 3 | 3 | 4 | 4 | 5 | 20 |
Bài học: Quy trình mà phòng ban kêu to nhất chưa chắc là quy trình đáng làm nhất. Việc chấm điểm khách quan giúp đội tránh được cái bẫy "tự động hóa theo tiếng nói lớn nhất". Họ chọn 2 quy trình hạng A, ra mắt thành công sau 6 tuần, lấy được uy tín để mở rộng.
Ví dụ 2 — Doanh nghiệp logistics: cái bẫy của Volume cao nhưng Exception cũng cao
Một công ty giao vận tại Hà Nội (giả định ViệtCargo) có quy trình "xử lý đơn hàng giao thất bại" chạy tới 8.000 lượt/tháng — Volume đạt 5 điểm tròn trĩnh. Đội kỹ thuật nhìn vào con số này và lao vào tự động hóa ngay.
Nhưng họ bỏ qua tiêu chí Exception. Thực tế, đơn giao thất bại có hàng chục lý do: khách không nghe máy, địa chỉ sai, khách đổi ý, hàng hỏng, shipper báo cáo nhầm… Tỷ lệ rơi vào tình huống đặc biệt lên tới 40%. Nếu chấm đủ 6 tiêu chí, quy trình này chỉ được khoảng 15 điểm vì Exception = 1 và Rule-based = 2.
Kết quả: robot tự động hóa xử lý ngon lành 60% các đơn theo luồng chuẩn, nhưng 40% còn lại liên tục văng ra cần người can thiệp. Tệ hơn, mỗi lần một hãng vận chuyển đối tác đổi giao diện web, robot lại hỏng (Stability thấp). Sau 4 tháng, chi phí bảo trì vượt cả tiền tiết kiệm.
Bài học: Volume cao là điều kiện cần nhưng KHÔNG đủ. Phải nhìn toàn bộ 6 tiêu chí. Một quy trình lệch — rất mạnh ở một tiêu chí nhưng rất yếu ở tiêu chí khác — thường nguy hiểm hơn một quy trình "đều đều khá". Giá như họ chấm điểm trước, họ đã chọn cách xử lý một phần (chỉ tự động hóa nhánh "khách không nghe máy" — vốn rõ ràng và lặp lại) thay vì ôm trọn cả quy trình.
Ví dụ 3 — Phòng nhân sự một tập đoàn sản xuất Đông Nam Á: dùng trọng số để phản ánh ưu tiên
Một tập đoàn sản xuất có nhà máy ở Bắc Ninh và Bình Dương muốn tự động hóa các tác vụ HR. Vì mục tiêu chiến lược năm đó là giải phóng nhân sự HR khỏi việc giấy tờ, họ quyết định gán trọng số cao cho Volume (×2) và Repetitiveness (×2), các tiêu chí khác giữ ×1.
Quy trình "tính công và chốt bảng chấm công hàng tháng" có điểm thô: Volume 5, Repeat 5, Rule 4, Data 3, Stability 4, Exception 3. Với trọng số: (5×2)+(5×2)+4+3+4+3 = 34 trên thang tối đa 40. Trong khi quy trình "tổ chức phỏng vấn ứng viên" tuy thú vị nhưng Volume và Repeat thấp, sau khi áp trọng số tụt hẳn xuống cuối bảng.
Bài học: Trọng số là công cụ để mô hình chấm điểm phản ánh đúng chiến lược của tổ chức, không phải để "nặn" cho ra kết quả mong muốn. Hãy quyết định trọng số TRƯỚC khi chấm điểm cụ thể từng quy trình, để tránh thiên kiến vô thức kéo điểm theo ý mình.
Hướng dẫn từng bước
Bước 1 — Lập danh sách ứng viên (longlist). Thu thập mọi quy trình được đề xuất tự động hóa. Đừng lọc vội. Mỗi quy trình ghi rõ tên, phòng ban sở hữu (Process Owner — Bài 10), và mô tả một dòng.
Bước 2 — Thu thập dữ liệu cho 6 tiêu chí. Đây là bước quan trọng nhất và hay bị làm ẩu. Đừng đoán. Hãy lấy số thật: Volume từ log hệ thống hoặc số liệu vận hành; Exception rate bằng cách hỏi người làm "trong 10 lần thì mấy lần bạn gặp tình huống lạ?"; Repetitiveness và Rule-based qua quan sát thực tế (process discovery — Bài 5).
Bước 3 — Lập bảng chấm điểm chuẩn (rubric). Viết rõ mỗi mức điểm 1–5 nghĩa là gì cho từng tiêu chí, như các thang ở phần khái niệm. Rubric càng cụ thể, hai người chấm độc lập càng cho điểm giống nhau (giảm tính chủ quan).
Bước 4 — Chấm điểm, tốt nhất là chấm chéo. Cho ít nhất 2 người chấm độc lập rồi đối chiếu. Nếu chênh nhau quá 1 điểm ở tiêu chí nào, ngồi lại thảo luận. Sự bất đồng thường lộ ra điểm mù trong hiểu biết về quy trình.
Bước 5 — Áp trọng số (nếu có) và tính tổng. Nhân điểm với trọng số đã thống nhất trước, cộng lại, rồi xếp hạng từ cao xuống thấp.
Bước 6 — Vẽ ma trận để trực quan hóa. Một cách hay là vẽ ma trận 2 trục: trục hoành = "Mức độ khả thi kỹ thuật" (gộp Rule, Data, Stability, Exception), trục tung = "Giá trị/lợi ích" (gộp Volume, Repeat). Góc trên-bên-phải chính là vùng quick win.
Bước 7 — Quyết định và ghi lại lý do. Chọn top ứng viên cho đợt đầu. Quan trọng: lưu lại bảng điểm làm hồ sơ. Khi ai đó chất vấn "sao không làm quy trình của tôi", bạn có bằng chứng khách quan thay vì tranh cãi cảm tính.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ nhìn Volume. Như ví dụ ViệtCargo, đây là sai lầm phổ biến nhất. Volume hấp dẫn vì dễ đo và nghe "to tát", nhưng nó chỉ là 1 trong 6 mảnh ghép. Luôn chấm đủ cả 6.
Lỗi 2 — Chấm điểm bằng cảm tính, không có rubric. Khi không có thang chuẩn, mỗi người hiểu "điểm 4" một kiểu, kết quả không thể so sánh. Luôn viết rubric trước.
Lỗi 3 — Tự động hóa quy trình tồi. Có câu kinh điển: "Automating a bad process just gives you a faster bad process" — tự động hóa một quy trình tệ chỉ tạo ra một quy trình tệ chạy nhanh hơn. Nếu một quy trình điểm trung bình vì rườm rà, ngoại lệ nhiều, hãy cải tiến/đơn giản hóa nó trước (To-Be — Bài 9), rồi mới chấm lại.
Lỗi 4 — Bỏ qua chi phí bảo trì khi Stability thấp. Nhiều người chỉ nghĩ đến chi phí xây dựng ban đầu mà quên mất robot/luồng tự động cần được "nuôi". Quy trình tựa trên hệ thống hay đổi sẽ ngốn chi phí dài hạn.
Mẹo 1 — Bắt đầu nhỏ để tạo niềm tin. Chọn 1–2 quy trình hạng A rõ ràng làm trước, ra mắt nhanh, lấy uy tín. Thành công nhỏ mở đường cho ngân sách lớn.
Mẹo 2 — Cập nhật điểm định kỳ. Điểm số không bất biến. Một quy trình hôm nay 14 điểm có thể lên 22 sau khi tổ chức số hóa biểu mẫu giấy. Hãy chấm lại mỗi 6–12 tháng.
Mẹo 3 — Tách phạm vi (scope splitting). Khi một quy trình lớn có điểm trung bình vì lẫn cả nhánh dễ và nhánh khó, hãy tách riêng nhánh "happy path" rõ ràng để tự động hóa, để con người giữ phần ngoại lệ. Điểm của phần được tách thường cao hơn hẳn.
Bài tập thực hành
- Tự xây bảng chấm cho phòng ban của bạn. Liệt kê 5 quy trình mà phòng/công ty bạn đang làm thủ công. Với mỗi quy trình, chấm điểm đủ 6 tiêu chí theo rubric trong bài. Tính tổng và xếp hạng. Quy trình nào lên hạng A?
- Phân tích một trường hợp lệch. Tìm trong danh sách của bạn một quy trình có ít nhất một tiêu chí đạt 5 điểm nhưng có một tiêu chí khác chỉ 1–2 điểm. Viết một đoạn ngắn lý giải: nếu cố tự động hóa nó như hiện trạng, rủi ro lớn nhất là gì? Bạn sẽ tách phạm vi thế nào để cải thiện điểm?
- Thử nghiệm trọng số. Giả sử công ty bạn ưu tiên giảm sai sót hơn là giảm nhân công. Hãy quyết định nên tăng trọng số cho những tiêu chí nào (gợi ý: Rule-based, Exception). Chấm lại danh sách với trọng số mới và xem thứ hạng thay đổi ra sao. Điều này dạy bạn điều gì về việc trọng số phản ánh chiến lược?
- Chấm chéo. Nhờ một đồng nghiệp chấm độc lập cùng 5 quy trình đó. So sánh. Tiêu chí nào hai bạn lệch nhau nhiều nhất? Thảo luận để hiểu vì sao — đó thường là chỗ hiểu biết về quy trình còn mơ hồ.
Tóm tắt
- Tự động hóa thất bại thường vì chọn sai quy trình ngay từ đầu, không phải vì công nghệ.
- Automation Candidate Scoring biến quyết định cảm tính thành con số khách quan, có thể so sánh và bảo vệ.
- Dùng 6 tiêu chí, mỗi tiêu chí 1–5 điểm: Volume, Repetitiveness, Rule-based, Data digitization, Stability — và Exception rate (tiêu chí nghịch). Tổng tối đa 30.
- Phân nhóm: 24–30 làm ngay (quick win), 18–23 tiềm năng cần tối ưu trước, dưới 18 chưa sẵn sàng.
- Volume cao không đủ — phải nhìn toàn bộ 6 tiêu chí; quy trình lệch thường nguy hiểm.
- Đừng tự động hóa quy trình tồi — cải tiến trước, tự động hóa sau.
- Trọng số giúp mô hình phản ánh chiến lược tổ chức; hãy chốt trọng số trước khi chấm điểm.
- Luôn dùng rubric rõ ràng, chấm chéo, và lưu lại hồ sơ điểm để minh bạch trước hội đồng đầu tư.