Process mining chỉ tốt bằng dữ liệu đầu vào. Nguyên liệu đó là event log — một bảng ghi lại từng sự kiện xảy ra trong quy trình. Nếu bạn chuẩn bị event log đúng, 70% công việc phân tích đã xong. Bài này dạy bạn cấu trúc, trích xuất và làm sạch event log để nó dùng được ngay.
Ba trường bắt buộc
Mọi event log hợp lệ cần tối thiểu ba cột:
- Case ID — định danh một lần chạy quy trình (VD: mã đơn hàng, số ticket).
- Activity — tên bước/hành động (VD: "Duyệt hóa đơn").
- Timestamp — thời điểm xảy ra sự kiện.
case_id,activity,timestamp,resource,cost
1023,Nhan don,2026-06-01 09:12,he_thong,0
1023,Kiem tra ton kho,2026-06-01 09:15,nv_kho,2000
1023,Xac nhan,2026-06-01 11:40,nv_sale,1500
1023,Giao hang,2026-06-02 08:05,dvvc,25000
1024,Nhan don,2026-06-01 09:20,he_thong,0
1024,Kiem tra ton kho,2026-06-01 09:25,nv_kho,2000
Hai cột tùy chọn cực giá trị: resource (ai/hệ thống nào thực hiện) và cost (chi phí bước) — cần cho việc đo và chấm điểm ở bài 4–5.
Trích xuất từ hệ thống thật
Dữ liệu hiếm khi có sẵn dạng event log. Bạn thường phải ghép từ các bảng nghiệp vụ. Ví dụ với đơn hàng trong CSDL:
SELECT o.order_id AS case_id,
'Nhan don' AS activity,
o.created_at AS timestamp
FROM orders o
UNION ALL
SELECT p.order_id, 'Thanh toan', p.paid_at FROM payments p
UNION ALL
SELECT s.order_id, 'Giao hang', s.shipped_at FROM shipments s
ORDER BY case_id, timestamp;
Mỗi mốc thời gian trong các bảng khác nhau trở thành một activity. Đây là mẫu "melt" — biến nhiều cột timestamp thành nhiều dòng sự kiện.
Checklist làm sạch event log
Trước khi mining, chạy qua checklist:
- [ ] Mỗi dòng có đủ case_id, activity, timestamp không rỗng?
- [ ] Timestamp cùng một định dạng và múi giờ?
- [ ] Tên activity đã chuẩn hóa? ("Duyệt" và "Duyet" và "Approve" phải gộp)
- [ ] Loại bỏ case chưa hoàn tất (còn đang chạy) nếu bạn chỉ phân tích case đóng?
- [ ] Xử lý sự kiện trùng (cùng case, activity, timestamp)?
- [ ] Kiểm tra case dị thường: chỉ có 1 sự kiện, hoặc kéo dài bất thường?
Các bước chuẩn bị
- Xác định phạm vi: một quy trình, một khoảng thời gian (VD 3 tháng gần nhất).
- Liệt kê các bảng/nguồn chứa timestamp của từng bước.
- Viết truy vấn UNION để melt thành event log dài.
- Chuẩn hóa tên activity bằng một bảng mapping.
- Kiểm tra thống kê nhanh: số case, số activity duy nhất, khoảng thời gian.
- Xuất ra CSV/XES để nạp vào công cụ (PM4Py, Disco, Celonis...).
Ví dụ chuẩn hóa activity
mapping = {
"Duyet": "Duyet hoa don",
"Approve": "Duyet hoa don",
"approved": "Duyet hoa don",
}
df["activity"] = df["activity"].replace(mapping)
Nếu bỏ bước này, sơ đồ sẽ hiện ba bước riêng biệt trong khi thực chất chỉ là một — làm loãng số liệu tần suất.
Sai lầm thường gặp
- Trộn nhiều quy trình vào một log (đơn hàng + đổi trả + hoàn tiền) khiến sơ đồ rối như tơ vò.
- Timestamp thiếu độ phân giải (chỉ có ngày, không có giờ) làm bạn không xác định được thứ tự các bước trong cùng ngày.
- Quên chuẩn hóa tên activity, dẫn đến tần suất bị chia nhỏ và bạn kết luận sai bước nào phổ biến.
- Lấy cả case đang chạy dở vào phân tích thời gian chu kỳ, kéo con số trung bình lệch.
- Không lưu resource/cost ngay từ đầu, để rồi bài sau phải trích xuất lại từ đầu.
Mẹo kiểm tra chất lượng nhanh
Trước khi mining, hãy chạy vài phép kiểm tra một dòng lệnh để bắt lỗi sớm. Đếm số case chỉ có đúng một sự kiện (thường là dữ liệu cụt hoặc case chưa bắt đầu thật sự). Đếm số activity duy nhất: nếu con số quá lớn (hàng trăm), khả năng cao bạn chưa chuẩn hóa tên hoặc đã trộn nhiều quy trình. Xem phân bố số sự kiện mỗi case: nếu lệch cực đoan, có case bị lặp bất thường. Những phép kiểm tra rẻ tiền này tiết kiệm hàng giờ phân tích sai về sau.
print('So case:', df['case_id'].nunique())
print('So activity duy nhat:', df['activity'].nunique())
print('Su kien/case:', df.groupby('case_id').size().describe())
Một event log sạch, đủ trường, đúng phạm vi là tài sản quý nhất trong toàn bộ dự án. Đừng vội vàng bỏ qua nó.