Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa vẽ xong một quy trình "Xử lý đơn hàng" đẹp đẽ trên BPMN: khách đặt hàng → kiểm tra tồn kho → đóng gói → giao hàng → thu tiền → kết thúc. Một đường thẳng tăm tắp, ai nhìn cũng gật gù. Nhưng khi bạn ngồi cạnh đội vận hành cả ngày, bạn sẽ phát hiện một sự thật khó chịu: chỉ khoảng 60-70% đơn hàng đi đúng con đường đẹp đẽ đó. Số còn lại thì đủ kiểu: khách đổi địa chỉ giữa chừng, hết hàng phải đặt nhà cung cấp, khách hủy rồi đặt lại, giao thất bại phải giao lần hai, hoàn tiền, đổi trả...
Con đường "đẹp đẽ" mà ai cũng vẽ ấy gọi là happy path (đường lý tưởng). Tất cả những con đường khác — những biến thể, những ngoại lệ, những vòng lặp — gọi là variants (biến thể quy trình). Và đây là điều mentor muốn bạn khắc cốt ghi tâm: giá trị thật của một Process Analyst không nằm ở việc vẽ đẹp happy path, mà nằm ở việc nhìn ra và quản lý được hàng chục variant đang âm thầm ngốn chi phí, gây chậm trễ và làm khách hàng khó chịu.
Process variant analysis (phân tích biến thể quy trình) chính là kỹ năng đào sâu vào "phần chìm của tảng băng" — những đường đi mà sơ đồ chuẩn không bao giờ thể hiện, nhưng lại chiếm phần lớn rắc rối trong thực tế vận hành. Bài này sẽ dạy bạn cách phát hiện, đo lường, phân loại và xử lý variant một cách có hệ thống.
Khái niệm cốt lõi
Variant là gì và xuất hiện từ đâu
Trong một quy trình, mỗi case (trường hợp cụ thể — ví dụ một đơn hàng, một hồ sơ vay, một ticket khiếu nại) sẽ đi qua một chuỗi hoạt động theo thứ tự nhất định. Chuỗi hoạt động theo đúng trình tự đó gọi là một trace (dấu vết). Khi nhiều case có cùng một trace giống hệt nhau, chúng tạo thành một variant.
Nói cách khác: variant = một mẫu đường đi duy nhất qua quy trình. Nếu có 10.000 đơn hàng nhưng tất cả chỉ đi theo 25 kiểu trình tự khác nhau, thì quy trình của bạn có 25 variant.
Variant sinh ra từ ba nguồn chính:
- Quyết định nghiệp vụ (gateway): đơn dưới 5 triệu tự duyệt, đơn trên 5 triệu cần quản lý ký — đó là hai variant.
- Ngoại lệ và lỗi: hết hàng, thanh toán thất bại, giao hàng không thành công.
- Hành vi con người: nhân viên bỏ qua bước, làm lại, làm tắt, hoặc xử lý thủ công ngoài hệ thống ("workaround").
Phân phối Pareto của variant
Đây là quy luật bạn sẽ gặp ở gần như mọi quy trình thực tế, và nó tuân theo nguyên lý Pareto một cách kinh điển:
- Top 1 variant (happy path) thường chiếm 60-80% số case.
- Top 5-10 variant đầu tiên thường gộp lại chiếm 85-95% case.
- "Cái đuôi dài" (long tail) gồm hàng trăm variant hiếm, mỗi cái chỉ vài case, nhưng gộp lại lại là nơi tập trung phần lớn chi phí xử lý ngoại lệ, chậm trễ và rủi ro.
Vì sao phải phân tích, không chỉ liệt kê
Mục tiêu của variant analysis không phải là "đếm cho biết", mà là trả lời ba câu hỏi vận hành:
- Variant nào đáng để chuẩn hóa hoặc tự động hóa? (thường là top variant tần suất cao)
- Variant nào là "xấu" cần loại bỏ? (làm lại, vòng lặp, bỏ qua kiểm soát)
- Variant nào hiếm nhưng đắt/rủi ro, cần thiết kế xử lý riêng? (đuôi dài chi phí cao)
Variant tốt vs variant xấu
Không phải mọi variant đều xấu. Mentor muốn bạn phân biệt rõ:
- Variant hợp lệ (desirable): phản ánh nhu cầu nghiệp vụ thật. Ví dụ: đơn VIP có thêm bước gọi điện xác nhận. Đây là biến thể có chủ đích, nên giữ.
- Variant không mong muốn (undesirable): phản ánh lỗi, lách quy trình, hoặc thiếu kiểm soát. Ví dụ: đơn được giao trước khi xác nhận thanh toán (skip bước), hay hồ sơ bị "quay lại bước thẩm định" ba lần (rework loop). Đây là thứ cần xóa bỏ.
Tình huống thực tế
Ví dụ 1 — Tiki và quy trình hoàn trả hàng (Reverse Logistics)
Một sàn thương mại điện tử kiểu Tiki có quy trình "Hoàn trả hàng" (return) tưởng đơn giản: khách yêu cầu trả → duyệt → lấy hàng về → kiểm tra → hoàn tiền. Khi đội phân tích trích xuất log của 18.000 yêu cầu hoàn trả trong một quý và nhóm thành variant, họ choáng váng: có tới 214 variant khác nhau.
Phân phối như sau:
- Variant 1 (happy path): 11.700 case (65%).
- Variant 2 (khách tự gửi hàng về thay vì chờ shipper lấy): 2.500 case (14%).
- Variant 3 (hàng kiểm tra không đạt, từ chối hoàn): 1.600 case (9%).
- 211 variant còn lại: 2.200 case (12%) — nhưng tiêu tốn 41% tổng thời gian xử lý của cả phòng.
Bài học rút ra: Nguyên nhân gốc là form yêu cầu hoàn trả không bắt buộc đính kèm ảnh ngay từ đầu. Chỉ một thay đổi nhỏ ở bước đầu (bắt buộc upload ảnh) đã xóa sổ vòng lặp tốn 6 ngày, gộp 38 variant xấu trở về happy path. Variant analysis giúp họ thấy chi phí thật nằm ở đâu — không phải ở happy path, mà ở cái đuôi.
Ví dụ 2 — Ngân hàng và quy trình phê duyệt vay tiêu dùng
Một ngân hàng bán lẻ tại TP.HCM phân tích quy trình "Phê duyệt khoản vay tiêu dùng dưới 100 triệu". Mục tiêu đặt ra: rút ngắn thời gian phê duyệt từ trung bình 4,2 ngày xuống dưới 2 ngày.
Khi nhóm 9.400 hồ sơ thành variant, họ thấy:
- Happy path (thẩm định → chấm điểm → duyệt → giải ngân): chỉ 58% — thấp hơn kỳ vọng.
- Variant "quay lại bổ sung giấy tờ" (rework): 22%.
- Variant "chuyển cấp duyệt cao hơn" (escalation): 11%.
- Đuôi dài: 9%.
Bài học rút ra: Đừng tối ưu trung bình của cả quy trình. Hãy tách variant ra, tìm đúng variant "độc hại" và xử lý nó. Ở đây, root cause là checklist giấy tờ gửi cho khách không đầy đủ, khiến hồ sơ thiếu liên tục. Sửa checklist đầu vào quan trọng hơn việc thúc ép cả phòng làm nhanh hơn.
Ví dụ 3 — Chuỗi F&B và quy trình onboarding nhân viên
Một chuỗi cà phê 80 cửa hàng phát hiện quy trình tuyển và onboarding nhân viên pha chế mới rất lộn xộn giữa các vùng. Họ phân tích variant và thấy: cửa hàng ở Hà Nội đi theo một bộ variant, cửa hàng ở TP.HCM đi theo bộ khác, và các cửa hàng nhượng quyền lại tự chế ra variant riêng — tổng cộng 47 variant cho cùng một quy trình lẽ ra phải thống nhất.
Đây là kiểu phân tích variant theo chiều so sánh nhóm (cohort): so variant của nhóm A với nhóm B để tìm sự khác biệt không đáng có. Họ phát hiện các cửa hàng nhượng quyền thường bỏ qua bước "đào tạo vệ sinh an toàn thực phẩm" — một variant cực kỳ rủi ro về mặt pháp lý.
Bài học rút ra: Variant analysis không chỉ dùng cho quy trình giao dịch, mà cực mạnh khi bạn cần phát hiện sự thiếu nhất quán giữa các đơn vị/chi nhánh. Một variant bỏ qua bước bắt buộc có thể không tốn tiền ngay, nhưng là quả bom hẹn giờ về tuân thủ.
Hướng dẫn từng bước
Đây là quy trình 7 bước mentor khuyên bạn áp dụng mỗi khi làm variant analysis:
Bước 1 — Xác định phạm vi và đơn vị case. Chốt rõ "một case là gì": một đơn hàng? một hồ sơ? một ticket? Và quy trình bắt đầu/kết thúc ở sự kiện nào. Sai ở bước này thì mọi con số sau đều vô nghĩa.
Bước 2 — Thu thập trace cho từng case. Lý tưởng là trích từ event log của hệ thống (mỗi case có chuỗi activity kèm timestamp). Nếu chưa có hệ thống, bạn có thể dựng trace thủ công qua phỏng vấn và quan sát, nhưng độ chính xác thấp hơn.
Bước 3 — Nhóm trace thành variant. Gom tất cả case có cùng trình tự activity giống hệt nhau vào một variant. Kết quả là một bảng: mỗi dòng là một variant, kèm số case và tỷ lệ phần trăm.
Bước 4 — Xếp hạng theo tần suất (variant frequency). Sắp xếp từ nhiều đến ít. Vẽ biểu đồ Pareto tích lũy để thấy ngay top mấy variant chiếm 80% case.
Bước 5 — Bổ sung chiều "chi phí và thời gian". Đừng chỉ nhìn tần suất. Với mỗi variant, tính thêm: cycle time trung bình, chi phí xử lý, số bước, có vòng lặp/rework hay không. Một variant chỉ 2% case nhưng cycle time gấp 5 lần thì đáng chú ý hơn nhiều variant 10% chạy nhanh gọn.
Bước 6 — Phân loại variant vào 4 ô. Dùng ma trận đơn giản: trục ngang là tần suất (cao/thấp), trục dọc là mức độ "tốt/xấu" (giá trị nghiệp vụ hay lãng phí). Bạn sẽ có:
- Tần suất cao + tốt → chuẩn hóa & tự động hóa.
- Tần suất cao + xấu → ưu tiên sửa root cause ngay (đây là nơi tiền chảy ra).
- Tần suất thấp + xấu → đuôi dài, gom nhóm và xử lý theo cụm.
- Tần suất thấp + tốt (ngoại lệ hợp lệ) → thiết kế nhánh xử lý riêng, đừng ép vào happy path.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ đếm tần suất, bỏ qua chi phí. Rất nhiều người dừng ở bảng xếp hạng tần suất rồi kết luận. Nhưng variant đắt nhất hiếm khi là variant đông nhất. Luôn ghép thêm chiều cycle time và cost.
Lỗi 2 — "Variant nổ" do dữ liệu bẩn. Nếu timestamp ghi sai thứ tự, hoặc cùng một hành động được ghi bằng nhiều tên khác nhau ("Duyệt" vs "Phê duyệt" vs "Approve"), bạn sẽ tạo ra hàng trăm variant giả. Mẹo: chuẩn hóa tên activity và làm sạch log trước khi nhóm. Đây là lý do số variant thực tế thường ít hơn nhiều so với con số thô ban đầu.
Lỗi 3 — Cố gắng xóa sạch mọi variant. Sai lầm phổ biến của người mới. Một quy trình không có variant là quy trình cứng nhắc, không phục vụ được thực tế đa dạng. Mục tiêu là loại variant xấu, giữ và chuẩn hóa variant hợp lệ.
Lỗi 4 — Quá tập trung happy path mà bỏ đuôi dài. Ngược lại với lỗi 3. Đuôi dài thường bị coi là "case lẻ, kệ nó". Nhưng cộng dồn lại, đuôi dài có thể chiếm phần lớn chi phí và rủi ro tuân thủ.
Lỗi 5 — Phân tích một lần rồi cất tủ. Variant thay đổi theo thời gian (mùa vụ, sản phẩm mới, chính sách mới). Hãy đo lại định kỳ (hàng quý) để bắt variant mới phát sinh.
Mẹo vàng: Khi trình bày với lãnh đạo, đừng đưa bảng 200 variant. Hãy kể câu chuyện: "65% đi đường tốt mất 2 ngày; 22% bị rework mất 8 ngày và đó là chỗ ta mất tiền". Một con số đắt giá thuyết phục hơn một bảng dài.
Bài tập thực hành
Giả sử bạn nhận được log đơn giản của quy trình "Xử lý khiếu nại khách hàng" với 1.000 case, đã nhóm sẵn thành các variant sau:
| Variant | Trình tự rút gọn | Số case | Cycle time TB |
|---|---|---|---|
| V1 | Tiếp nhận → Phân loại → Xử lý → Đóng | 640 | 1,5 ngày |
| V2 | Tiếp nhận → Phân loại → Chuyển bộ phận → Xử lý → Đóng | 180 | 3,0 ngày |
| V3 | Tiếp nhận → Phân loại → Xử lý → Mở lại → Xử lý → Đóng | 110 | 7,2 ngày |
| V4 | 60 variant đuôi dài khác | 70 | 9,5 ngày |
- Tính tỷ lệ phần trăm mỗi nhóm variant và xác định đâu là happy path.
- Top bao nhiêu variant chiếm 90% số case?
- Variant nào là "xấu" nhất theo bạn? Giải thích dựa trên cả tần suất và cycle time.
- Với variant V3, hãy đề xuất ít nhất 2 giả thuyết root cause cho hành động "Mở lại", và một hành động để xóa nó.
- Variant nào bạn sẽ ưu tiên tự động hóa, variant nào cần thiết kế nhánh xử lý riêng?
Tóm tắt
- Happy path là đường đi lý tưởng, thường chiếm 60-80% case; tất cả đường còn lại là variant.
- Variant tuân theo phân phối Pareto: vài variant đầu chiếm phần lớn case, nhưng cái đuôi dài mới là nơi tập trung chi phí, chậm trễ và rủi ro tuân thủ.
- Phân biệt rõ variant tốt (ngoại lệ nghiệp vụ hợp lệ — nên giữ và chuẩn hóa) với variant xấu (rework, skip kiểm soát, workaround — cần xóa).
- Phân tích phải kết hợp hai chiều: tần suất và chi phí/thời gian. Variant đắt nhất hiếm khi là variant đông nhất.
- Quy trình 7 bước: xác định case → thu thập trace → nhóm thành variant → xếp hạng tần suất → bổ sung chiều chi phí → phân loại 4 ô → truy root cause và hành động.
- Cảnh giác với "variant nổ" do log bẩn; luôn chuẩn hóa tên activity trước khi nhóm.
- Mục tiêu cuối cùng không phải xóa sạch variant, mà là đưa case xấu về happy path và hợp thức hóa variant hợp lệ thành nhánh chính thức trong sơ đồ To-Be.