Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là giám đốc vận hành của một ngân hàng. Mỗi ngày có hàng nghìn hồ sơ vay đi qua quy trình phê duyệt. Trên giấy tờ, quy trình ấy rất đẹp: tiếp nhận → thẩm định → phê duyệt → giải ngân, mất trung bình 3 ngày. Nhưng khách hàng thì than phiền mất cả tuần, nhân viên thì kêu quá tải, còn bạn thì... không thật sự biết chuyện gì đang xảy ra bên trong. Bạn chỉ có cảm giác, có vài báo cáo Excel rời rạc, và rất nhiều phỏng đoán.
Đây chính là khoảng trống mà Process Mining (khai phá quy trình) sinh ra để lấp đầy. Thay vì hỏi nhân viên "quy trình diễn ra thế nào?", Process Mining đọc trực tiếp dấu vết số mà các hệ thống công nghệ thông tin để lại — log của ERP, CRM, core banking, ticketing — rồi tái dựng lại bức tranh thật của quy trình. Không phải quy trình như bạn nghĩ, mà quy trình như nó thực sự chạy.
Và đây mới là phần khiến bài này thực sự quan trọng trong khóa học về tự động hóa: khi bạn ghép Process Mining với Machine Learning và AI predictive (dự đoán), bạn không chỉ nhìn thấy quá khứ — bạn bắt đầu dự đoán tương lai của từng hồ sơ, từng đơn hàng, từng case. Hồ sơ này sẽ trễ hạn không? Khách hàng này sắp rời bỏ chăng? Đơn hàng kia có nguy cơ giao chậm bao nhiêu phần trăm? Khi đã dự đoán được, bạn mới có thể can thiệp trước khi sự cố xảy ra — và đó là đòn bẩy thực sự của tự động hóa thông minh. Process Mining trả lời "chuyện gì đã và đang xảy ra"; AI predictive trả lời "chuyện gì sắp xảy ra và ta nên làm gì". Bài này dạy bạn cách đi từ vế đầu sang vế sau.
Khái niệm cốt lõi
Ba tầng giá trị: Discovery → Conformance → Predictive
Process Mining thường được hiểu qua ba nhóm kỹ thuật, và ba nhóm này cũng chính là ba bậc thang trưởng thành mà một tổ chức leo dần.
1. Process Discovery (khai phá — "chuyện gì đã xảy ra")
Đây là điểm khởi đầu. Hệ thống lấy event log (nhật ký sự kiện) và tự động vẽ ra sơ đồ quy trình thực tế. Một event log tối thiểu chỉ cần ba cột:
- Case ID — định danh một thực thể đi qua quy trình (mã hồ sơ, mã đơn hàng, mã ticket).
- Activity — hoạt động đã thực hiện (ví dụ "Tiếp nhận hồ sơ", "Thẩm định", "Phê duyệt").
- Timestamp — thời điểm xảy ra hoạt động.
2. Conformance Checking (đối chiếu — "chuyện gì lẽ ra phải xảy ra")
Khi bạn đã có một mô hình quy trình chuẩn (quy trình thiết kế, hay "to-be"), Conformance Checking so sánh quy trình thực tế với mô hình chuẩn đó để chỉ ra các điểm lệch (deviation). Nó trả lời: ở đâu nhân viên làm sai quy trình? Bước kiểm soát nào hay bị bỏ qua? Có ai "đi cửa sau" để né bước phê duyệt không? Đây là công cụ vàng cho kiểm toán nội bộ, tuân thủ (compliance) và phát hiện gian lận.
3. Predictive Process Monitoring (dự đoán — "chuyện gì sắp xảy ra")
Đây là tầng cao nhất, nơi Process Mining gặp Machine Learning. Thay vì chỉ phân tích các case đã hoàn thành, ta nhìn vào các case đang chạy dở và dự đoán tương lai của chúng. Các bài toán dự đoán điển hình:
- Outcome prediction — case này sẽ kết thúc theo hướng nào? (Hồ sơ vay sẽ được duyệt hay từ chối? Ticket sẽ được giải quyết đúng SLA hay vi phạm?)
- Remaining time prediction — còn bao lâu nữa thì case hoàn thành? Hữu ích để báo cho khách hàng thời gian dự kiến.
- Next activity prediction — bước tiếp theo nhiều khả năng là gì? Giúp gợi ý hành động, phân bổ nguồn lực trước.
Vì sao cần AI/ML chứ không chỉ thống kê?
Bạn có thể hỏi: tính trung bình thời gian từng bước thì cần gì AI? Vấn đề là tương lai của một case phụ thuộc vào rất nhiều biến tương tác phi tuyến: loại sản phẩm, giá trị giao dịch, nhân viên đang xử lý, khối lượng công việc tồn đọng, thời điểm trong tháng, lịch sử các bước đã qua... Mô hình ML — từ Random Forest, Gradient Boosting (XGBoost, LightGBM) cho dữ liệu dạng bảng, đến LSTM/Transformer cho chuỗi sự kiện — học được những tương tác phức tạp này tốt hơn nhiều so với quy tắc thủ công.
Một kỹ thuật then chốt là feature engineering từ trace dở dang (prefix). Với mỗi case đang chạy, ta cắt lấy phần "tiền tố" gồm những bước đã hoàn thành, trích xuất đặc trưng (số bước đã qua, thời gian đã trôi, hoạt động gần nhất, tổng giá trị...), rồi đưa vào mô hình để dự đoán phần còn lại. Đây là sự khác biệt cốt lõi giữa "phân tích quá khứ" và "giám sát dự đoán thời gian thực".
Hệ sinh thái công cụ
Trên thị trường, Celonis là tên tuổi dẫn đầu (đặc biệt mạnh ở phân tích chuỗi cung ứng, Procure-to-Pay, Order-to-Cash), bên cạnh UiPath Process Mining, SAP Signavio, Microsoft Power Automate Process Mining và các thư viện mã nguồn mở như PM4Py (Python) — rất đáng học để hiểu cơ chế bên dưới.
Tình huống thực tế
Ví dụ 1 — Ngân hàng số tại Việt Nam: rút ngắn thời gian phê duyệt vay
Một ngân hàng bán lẻ tầm trung ở TP.HCM (ta gọi là "Ngân hàng V") nhận thấy thời gian phê duyệt vay tiêu dùng trung bình là 4,2 ngày, dù SLA cam kết là 2 ngày. Đội vận hành đổ lỗi cho khâu thẩm định, còn đội thẩm định đổ lỗi cho khâu bổ sung hồ sơ.
Họ trích xuất event log từ hệ thống loan origination trong 6 tháng — khoảng 38.000 hồ sơ — và chạy Process Discovery. Kết quả phơi bày sự thật: có tới 27% hồ sơ rơi vào một vòng lặp "Yêu cầu bổ sung chứng từ → Khách nộp lại → Thẩm định lại", lặp trung bình 2,4 lần mỗi hồ sơ. Đây mới là thủ phạm thật, không phải bước thẩm định.
Bước tiếp theo, họ huấn luyện một mô hình Gradient Boosting dự đoán ngay tại thời điểm tiếp nhận: hồ sơ nào có nguy cơ cao rơi vào vòng lặp bổ sung chứng từ. Mô hình đạt độ chính xác đủ tốt để đội vận hành chủ động gọi khách hàng ngay từ đầu hướng dẫn chuẩn bị đủ giấy tờ cho nhóm rủi ro cao. Sau 4 tháng, tỷ lệ hồ sơ phải bổ sung giảm từ 27% xuống 15%, thời gian phê duyệt trung bình về còn 2,6 ngày.
Bài học: Process Mining tìm ra nút thắt thật (vòng lặp bổ sung hồ sơ), còn AI predictive biến hiểu biết đó thành hành động phòng ngừa trước khi case bị tắc.
Ví dụ 2 — Sàn thương mại điện tử Đông Nam Á: dự đoán đơn giao trễ
Một sàn TMĐT khu vực (giả định, ta gọi là "ShopFast", quy mô tương tự một sàn lớn ở Đông Nam Á) đối mặt với khiếu nại giao hàng trễ vào mùa cao điểm 11.11. Quy trình fulfillment đi qua nhiều hệ thống: đặt hàng → kho lấy hàng (picking) → đóng gói → bàn giao đơn vị vận chuyển → giao. Mỗi hệ thống để lại log riêng.
Đội data hợp nhất các log thành một event log thống nhất theo Case ID là mã đơn hàng. Process Discovery cho thấy khâu bàn giao cho đơn vị vận chuyển vào khung 18h–22h bị dồn ứ nghiêm trọng. Quan trọng hơn, họ xây mô hình remaining time prediction dự đoán thời điểm giao thực tế cho từng đơn đang chạy. Khi mô hình cảnh báo một đơn có xác suất trễ SLA trên 70%, hệ thống tự động: ưu tiên đơn đó trong hàng đợi đóng gói, hoặc tự chuyển sang đơn vị vận chuyển nhanh hơn. Kết quả mùa cao điểm: tỷ lệ đơn trễ SLA giảm khoảng một phần ba so với năm trước, và khách được thông báo thời gian giao thực tế thay vì một con số "đặt đại".
Bài học: Dự đoán remaining time chỉ tạo giá trị khi nó được nối thẳng vào một hành động tự động (re-prioritize, đổi nhà vận chuyển). Dự đoán mà không hành động chỉ là dashboard đẹp.
Ví dụ 3 — Doanh nghiệp sản xuất: phát hiện lệch quy trình và gian lận mua hàng
Một công ty sản xuất hàng tiêu dùng có quy tắc kiểm soát: mọi đơn mua trên 50 triệu đồng phải qua phê duyệt của trưởng phòng trước khi tạo đơn đặt hàng (PO). Đội kiểm toán nội bộ chạy Conformance Checking trên event log của module mua sắm trong ERP và phát hiện 6% giao dịch có trình tự bất thường: PO được tạo trước, rồi mới "phê duyệt ngược" sau đó — dấu hiệu kinh điển của việc lách kiểm soát (maverick buying).
Họ tiến thêm một bước, dùng ML phát hiện bất thường (anomaly detection) để chấm điểm rủi ro từng giao dịch dựa trên tổ hợp đặc trưng: nhà cung cấp mới, giá trị sát ngưỡng phê duyệt, người tạo và người duyệt là cùng một nhóm nhỏ thường xuyên đi cặp với nhau. Danh sách rủi ro cao được chuyển cho kiểm toán điều tra sâu, thay vì kiểm tra mẫu ngẫu nhiên kém hiệu quả như trước.
Bài học: Conformance Checking phát hiện lệch quy trình theo luật, còn ML anomaly detection bắt được các mẫu bất thường tinh vi mà không luật cứng nào mô tả nổi. Hai cái bổ trợ nhau, không thay thế nhau.
Hướng dẫn từng bước
Đây là quy trình thực hành để bạn triển khai một dự án Process Mining có yếu tố dự đoán, từ con số 0.
Bước 1 — Chọn quy trình và xác định Case ID. Đừng tham. Chọn một quy trình có dữ liệu sạch, có nỗi đau rõ ràng (thời gian, chi phí, tuân thủ) và có chủ sở hữu sẵn sàng hành động. Xác định rõ một case là gì: một đơn hàng? một hồ sơ? một ticket?
Bước 2 — Trích xuất và chuẩn hóa event log. Lấy dữ liệu từ các bảng log/transaction trong ERP, CRM, core system. Tối thiểu cần ba cột: Case ID, Activity, Timestamp. Hãy bổ sung các thuộc tính (attribute) hữu ích như giá trị giao dịch, người thực hiện, kênh — chúng sẽ là "nhiên liệu" cho mô hình dự đoán sau này.
Bước 3 — Discovery: vẽ quy trình thật. Nạp event log vào công cụ (Celonis, PM4Py, Power Automate) và để nó tự sinh sơ đồ. Quan sát các variant phổ biến nhất, tần suất từng đường đi, và đặc biệt là phân bố thời gian giữa các bước để lộ nút thắt.
Bước 4 — Conformance: đối chiếu với chuẩn. Nếu có quy trình thiết kế, so sánh để liệt kê các điểm lệch. Xếp hạng theo mức độ ảnh hưởng và rủi ro tuân thủ.
Bước 5 — Định nghĩa bài toán dự đoán. Chọn rõ một mục tiêu: dự đoán outcome (duyệt/từ chối), remaining time, hay vi phạm SLA. Mục tiêu mơ hồ là nguyên nhân số một khiến dự án ML thất bại.
Bước 6 — Feature engineering từ prefix. Với mỗi case, sinh các "ảnh chụp" tại từng bước hoàn thành: số bước đã qua, thời gian đã trôi, hoạt động gần nhất, các thuộc tính tĩnh. Đây là khâu quyết định chất lượng mô hình.
Bước 7 — Huấn luyện và kiểm định. Bắt đầu với mô hình đơn giản (Logistic Regression, Random Forest) làm baseline, rồi nâng lên XGBoost/LightGBM. Quan trọng: chia train/test theo thời gian (temporal split) — huấn luyện trên dữ liệu cũ, kiểm tra trên dữ liệu mới — để mô phỏng đúng cách nó sẽ chạy thật.
Bước 8 — Tích hợp vào hành động. Đây là bước biến phân tích thành giá trị: nối dự đoán vào một trigger tự động (cảnh báo, đổi ưu tiên, phân việc, gọi khách). Dự đoán phải dẫn tới hành động, nếu không nó vô nghĩa.
Bước 9 — Giám sát và tái huấn luyện. Theo dõi độ chính xác theo thời gian. Quy trình thay đổi, mô hình sẽ "trôi" (model drift) — lên lịch tái huấn luyện định kỳ.
Lỗi thường gặp & mẹo
Lỗi 1 — Event log bẩn nhưng vẫn tin tưởng kết quả. Timestamp sai múi giờ, Activity đặt tên không nhất quán ("Approve" vs "approved" vs "Phê duyệt"), case thiếu bước đầu/cuối. Rác vào thì rác ra. Mẹo: dành tối thiểu 40% thời gian dự án cho việc làm sạch và kiểm chứng log trước khi phân tích.
Lỗi 2 — Nhầm tương quan với nhân quả. Process Mining cho thấy hai thứ đi cùng nhau, không có nghĩa cái này gây ra cái kia. Mẹo: luôn ngồi lại với người vận hành (process owner) để diễn giải phát hiện trước khi kết luận.
Lỗi 3 — Rò rỉ dữ liệu tương lai (data leakage) khi train mô hình. Vô tình đưa vào feature chứa thông tin chỉ biết được sau khi case kết thúc — mô hình sẽ chính xác giả tạo trên giấy nhưng vô dụng thực tế. Mẹo: tự hỏi với mỗi feature "tại thời điểm dự đoán, tôi đã thật sự biết giá trị này chưa?".
Lỗi 4 — Chia train/test ngẫu nhiên thay vì theo thời gian. Với dữ liệu quy trình, random split làm phồng độ chính xác giả. Mẹo: luôn dùng temporal split.
Lỗi 5 — Dừng lại ở dashboard. Rất nhiều dự án tạo ra báo cáo đẹp rồi... để đó. Mẹo: ngay từ bước lập kế hoạch, hãy định nghĩa rõ "khi mô hình cảnh báo, ai làm gì, qua hệ thống nào". Gắn dự đoán với một workflow tự động cụ thể.
Lỗi 6 — Bỏ qua quyền riêng tư và yếu tố con người. Event log lộ ra ai làm nhanh, ai làm chậm — dễ thành công cụ giám sát nhân viên gây phản kháng. Mẹo: ẩn danh dữ liệu người thực hiện khi không cần thiết, và truyền thông rõ rằng mục tiêu là cải tiến quy trình, không phải "soi" cá nhân.
Bài tập thực hành
- Lập event log thủ công. Chọn một quy trình bạn quen (ví dụ xử lý đơn nghỉ phép ở công ty bạn). Liệt kê 5–7 case thật, mỗi case ghi đủ ba cột Case ID, Activity, Timestamp. Tự tay vẽ sơ đồ quy trình thật từ các trace này — bạn sẽ thấy nó khác sơ đồ chính thức ra sao.
- Thực hành với PM4Py. Cài thư viện PM4Py (Python), nạp một event log mẫu (file
.xescó sẵn trong bộ dữ liệu công khai như BPI Challenge), chạy Inductive Miner để sinh sơ đồ, và liệt kê 3 variant phổ biến nhất cùng tần suất.
- Thiết kế bài toán dự đoán trên giấy. Với quy trình ở bài tập 1, hãy viết ra: (a) bạn muốn dự đoán gì, (b) tại thời điểm nào trong quy trình, (c) bạn sẽ dùng những feature nào lấy được tại thời điểm đó, (d) khi mô hình cảnh báo thì hành động tự động gì sẽ kích hoạt.
- Săn data leakage. Cho danh sách feature sau khi dự đoán "hồ sơ vay có bị từ chối không" tại thời điểm tiếp nhận: số ngày xử lý, điểm tín dụng khách, lý do từ chối, tên cán bộ thẩm định, giá trị khoản vay. Chỉ ra feature nào bị rò rỉ tương lai và giải thích tại sao.
Tóm tắt
- Process Mining đọc event log (Case ID, Activity, Timestamp) để tái dựng quy trình thực tế, vạch trần khoảng cách giữa quy trình trên giấy và quy trình đang chạy.
- Ba tầng giá trị: Discovery (chuyện gì đã xảy ra) → Conformance (chuyện gì lẽ ra phải xảy ra, phát hiện lệch và gian lận) → Predictive (chuyện gì sắp xảy ra).
- AI predictive ghép ML vào trace dở dang để dự đoán outcome, remaining time, vi phạm SLA — chuyển từ phân tích quá khứ sang can thiệp chủ động.
- Kỹ thuật then chốt: feature engineering từ prefix, temporal split, tránh data leakage, và đặc biệt là nối dự đoán vào hành động tự động — đây là nơi giá trị thật sự được tạo ra.
- Cạm bẫy lớn nhất không nằm ở thuật toán mà ở dữ liệu bẩn, nhầm tương quan–nhân quả, và dừng lại ở dashboard thay vì hành động.