Process Mining + AI: Soi Quy Trình Thật Trước Khi Tự Động Hóa

Posted on: 10/19/2026 1:18:22 AM

Một nhà phân phối muốn đưa AI agent vào quy trình xử lý đơn hàng. Tài liệu nội bộ vẽ quy trình gọn gàng bảy bước: tạo đơn, kiểm tra tín dụng, duyệt, xuất kho, giao hàng, xuất hóa đơn, thu tiền. Nhưng khi đội dữ liệu dựng lại quy trình từ log của ERP, họ thấy hơn bốn trăm "con đường" khác nhau mà đơn hàng thực sự đi qua: có đơn bỏ qua bước kiểm tra tín dụng, có đơn bị sửa giá sau khi đã duyệt, có đơn quay vòng "sửa – duyệt lại" năm lần. Nếu giao cho agent tự động hóa quy trình trên giấy, agent sẽ chạy nhanh hơn — trên một quy trình không tồn tại.

Process mining (khai phá quy trình) là kỹ thuật dựng lại quy trình thật từ dấu vết mà hệ thống để lại: mỗi lần một đơn hàng được tạo, duyệt hay giao, ERP, CRM hoặc ứng dụng của bạn đều ghi một bản ghi có thời gian. Từ hàng triệu bản ghi đó, thuật toán vẽ ra bản đồ quy trình, đo thời gian chờ giữa các bước, chỉ ra chỗ lệch chuẩn. Năm 2026, lĩnh vực này đang chuyển mình thành process intelligence: kết hợp với LLM để hỏi đáp bằng ngôn ngữ tự nhiên, và trở thành nguồn ngữ cảnh vận hành cho chính các AI agent. Bài viết này đi từ nền tảng thuật toán, chuẩn dữ liệu OCEL 2.0, đến cách ghép LLM và agent vào đúng chỗ — kèm code Python chạy được với pm4py.

1. Process mining là gì, và vì sao lại quan trọng lúc này

Ý tưởng cốt lõi rất đơn giản: hầu như mọi hệ thống nghiệp vụ đều lưu lại ai làm gì, với đối tượng nào, lúc nào. Bảng lịch sử thay đổi của ERP, trạng thái ticket trong hệ thống CSKH, audit log của ứng dụng nội bộ, thậm chí trace của OpenTelemetry — tất cả đều là nguyên liệu. Chỉ cần ba trường là đủ để bắt đầu:

Từ những bản ghi như vậy, process mining giải ba bài toán:

• Discovery (khám phá): không cần ai vẽ trước, thuật toán tự dựng mô hình quy trình từ log — quy trình thật trông ra sao, có bao nhiêu biến thể, đâu là "đường cao tốc", đâu là "đường làng".
• Conformance checking (kiểm tra tuân thủ): so log với mô hình chuẩn mà doanh nghiệp mong muốn — case nào bỏ qua bước duyệt, case nào làm sai thứ tự, case nào vi phạm SLA.
• Enhancement (cải tiến): phủ thêm dữ liệu thời gian, chi phí, người thực hiện lên mô hình để thấy điểm nghẽn, nguyên nhân gốc và dự báo case nào sắp trễ.

Vì sao đề tài này nóng lên năm 2026? Vì làn sóng AI agent khiến mọi doanh nghiệp đều muốn "tự động hóa quy trình X", nhưng rất ít nơi biết quy trình X thực sự vận hành ra sao. Ngày 5/5/2026, Gartner chính thức đổi tên báo cáo Magic Quadrant từ "Process Mining Platforms" thành "Process Intelligence Platforms" — một tín hiệu rằng thị trường không còn dừng ở phân tích hồi cứu, mà muốn quy trình trở thành ngữ cảnh sống cho quyết định và cho agent.

flowchart LR
  subgraph SRC["Hệ thống nguồn"]
    ERP["ERP
đơn hàng, hóa đơn"]
    CRM["CRM / Ticket"]
    APP["Audit log ứng dụng"]
    OT["OpenTelemetry traces"]
  end
  SRC --> ETL["Trích xuất và chuẩn hóa
case · activity · timestamp"]
  ETL --> LOG[("Event log
XES hoặc OCEL 2.0")]
  LOG --> D["Discovery
quy trình thật ra sao?"]
  LOG --> C["Conformance
lệch chuẩn ở đâu?"]
  LOG --> E["Enhancement
chậm ở đâu, vì sao?"]
  D --> ACT["Hành động
thiết kế lại · tự động hóa · AI agent"]
  C --> ACT
  E --> ACT
  classDef hot fill:#e94560,stroke:#fff,color:#fff
  classDef light fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  classDef dark fill:#2c3e50,stroke:#fff,color:#fff
  class LOG dark
  class D,C,E light
  class ACT hot

2. Từ event log đến bản đồ quy trình

Kỹ thuật nền tảng nhất là Directly-Follows Graph (DFG): mỗi node là một hoạt động, mỗi cạnh A → B nghĩa là "trong cùng một case, B xảy ra ngay sau A", kèm số lần và thời gian chờ. DFG dễ hiểu, tính nhanh trên hàng chục triệu sự kiện, và thường là thứ đầu tiên làm người quản lý giật mình.

flowchart LR
  S(("Bắt đầu")) --> A["Tạo đơn
10.000 case"]
  A -->|"9.200 · 2 giờ"| B["Kiểm tra tín dụng"]
  A -->|"800 · bỏ qua"| D["Duyệt đơn"]
  B -->|"8.900 · 26 giờ"| D
  B -->|"300 · 4 giờ"| X["Sửa đơn"]
  D -->|"2.100 · 5 giờ"| X
  X -->|"2.400 · 31 giờ"| D
  D -->|"9.700 · 3 giờ"| W["Xuất kho"]
  W -->|"9.600 · 18 giờ"| G["Giao hàng"]
  G -->|"9.500 · 1 giờ"| I["Xuất hóa đơn"]
  I -->|"9.100 · 34 ngày"| P["Thu tiền"]
  P --> F(("Kết thúc"))
  classDef hot fill:#e94560,stroke:#fff,color:#fff
  classDef light fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  class X hot
  class A,B,D,W,G,I,P light

Đọc bản đồ trên, ba vấn đề lộ ra ngay mà không cần phỏng vấn ai:

• Vòng lặp làm lại: cặp "Duyệt đơn ↔ Sửa đơn" xuất hiện 2.400 lần. Mỗi vòng tốn thêm khoảng một ngày rưỡi chờ. Đây là ứng viên số một để tìm nguyên nhân gốc (giá sai từ đầu? thiếu thông tin giao hàng?).
• Bỏ qua kiểm soát: 800 đơn đi thẳng từ "Tạo đơn" sang "Duyệt đơn", không qua kiểm tra tín dụng. Có thể hợp lệ (khách VIP) hoặc là lỗ hổng rủi ro công nợ.
• Chờ, không phải làm: bước kiểm tra tín dụng chỉ mất vài phút, nhưng đơn phải chờ trung bình 26 giờ mới được duyệt. Điểm nghẽn nằm ở hàng đợi, không nằm ở công việc — điều mà bảng KPI tổng thời gian không bao giờ cho thấy.

DFG có giới hạn: nó không phân biệt được rẽ nhánh song song với rẽ nhánh lựa chọn, và với log thật thường thành "đĩa mì spaghetti" khi có hàng trăm biến thể. Vì vậy người ta dùng thêm các thuật toán khám phá cho mô hình có ngữ nghĩa chặt hơn, phổ biến nhất là Inductive Miner — sinh ra process tree hoặc Petri net đảm bảo "sound" (không deadlock, luôn kết thúc được), có tham số lọc nhiễu để bỏ các đường hiếm.

import pandas as pd
import pm4py

# Event log xuất từ ERP: mỗi dòng là một sự kiện
df = pd.read_csv("order_events.csv")          # order_id, activity, ts, resource
df["ts"] = pd.to_datetime(df["ts"], utc=True)
df = pm4py.format_dataframe(df, case_id="order_id",
                            activity_key="activity",
                            timestamp_key="ts")

# 1) Bản đồ "ai đi sau ai" kèm thời gian chờ
perf_dfg, starts, ends = pm4py.discover_performance_dfg(df)

# 2) Có bao nhiêu "con đường" khác nhau?
variants = pm4py.get_variants(df)
print(len(variants), "biến thể")

# 3) Giữ 10 biến thể phổ biến nhất rồi khám phá mô hình có ngữ nghĩa
top = pm4py.filter_variants_top_k(df, 10)
net, im, fm = pm4py.discover_petri_net_inductive(top, noise_threshold=0.2)
pm4py.save_vis_petri_net(net, im, fm, "o2c_model.png")

3. Conformance checking: quy trình đang lệch chuẩn ở đâu

Khi đã có mô hình chuẩn (do phòng vận hành vẽ bằng BPMN, hoặc do quy định nội bộ), conformance checking trả lời câu hỏi: từng case có tuân thủ không, và lệch ở bước nào. Có bốn họ kỹ thuật chính, đánh đổi giữa độ chính xác và chi phí tính toán:

# Mô hình chuẩn do phòng vận hành vẽ bằng BPMN
bpmn = pm4py.read_bpmn("o2c_chuan.bpmn")
net, im, fm = pm4py.convert_to_petri_net(bpmn)

fit = pm4py.fitness_alignments(df, net, im, fm)
print(fit["log_fitness"])            # 1.0 nghĩa là mọi case khớp hoàn toàn

diag = pm4py.conformance_diagnostics_alignments(df, net, im, fm)
lech = [d for d in diag if d["fitness"] < 1.0]
# d["alignment"] chứa các cặp (log, model); ký hiệu ">>" đánh dấu bước bị bỏ qua hoặc chèn thêm

# Vi phạm thời gian: cặp hoạt động có khoảng cách lệch quá 2 độ lệch chuẩn
tp = pm4py.discover_temporal_profile(df)
sla = pm4py.conformance_temporal_profile(df, tp, zeta=2.0)

Trong thực tế, conformance checking là nơi process mining tạo ra giá trị nhanh nhất cho các bộ phận tài chính và kiểm soát nội bộ: phát hiện thanh toán trùng, mua hàng không có PO trước ("maverick buying"), sửa giá sau khi duyệt, hay giao hàng cho khách đang bị khóa tín dụng. Khác với kiểm toán chọn mẫu, nó kiểm tra 100% giao dịch.

4. Giới hạn của "một case id" và Object-Centric Process Mining

Mọi kỹ thuật ở trên đều giả định mỗi sự kiện thuộc về đúng một case. Nhưng thế giới nghiệp vụ không như vậy. Một đơn hàng có nhiều mặt hàng, các mặt hàng được gom vào những chuyến giao khác nhau, một hóa đơn lại gộp nhiều chuyến giao. Sự kiện "Tạo đơn" liên quan đến một order và ba item; sự kiện "Giao hàng" liên quan đến một delivery và các item từ nhiều order.

flowchart LR
  O["Order A1"] ---|"chứa"| I1["Item i1"]
  O ---|"chứa"| I2["Item i2"]
  O ---|"chứa"| I3["Item i3"]
  I1 ---|"giao trong"| D1["Delivery d1"]
  I2 ---|"giao trong"| D1
  I3 ---|"giao trong"| D2["Delivery d2"]
  D1 ---|"lập hóa đơn"| V["Invoice v1"]
  D2 ---|"lập hóa đơn"| V
  classDef hot fill:#e94560,stroke:#fff,color:#fff
  classDef light fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  classDef dark fill:#2c3e50,stroke:#fff,color:#fff
  class O hot
  class I1,I2,I3 light
  class D1,D2,V dark

Khi buộc phải "làm phẳng" log theo một case id duy nhất, ba lỗi kinh điển xuất hiện (được Wil van der Aalst, cha đẻ của process mining, mô tả từ 2019):

• Convergence (hội tụ): làm phẳng theo item thì sự kiện "Tạo đơn" bị nhân bản ba lần, mọi thống kê về số lần và chi phí bị thổi phồng.
• Divergence (phân kỳ): làm phẳng theo order thì "Giao hàng" xuất hiện hai lần trong cùng case, trông như vòng lặp làm lại dù thực ra là hai chuyến giao song song.
• Deficiency (thiếu hụt): sự kiện không gắn với order (vd "Nhập kho" chỉ gắn với item và kho) bị loại khỏi phân tích hoàn toàn.

Object-Centric Process Mining (OCPM) giải quyết bằng cách bỏ khái niệm case: mỗi sự kiện liên kết với nhiều đối tượng thuộc nhiều loại. Chuẩn trao đổi dữ liệu cho cách tiếp cận này là OCEL 2.0, do nhóm RWTH Aachen công bố, với các điểm chính:

• E2O (event-to-object): mỗi sự kiện gắn với ít nhất một đối tượng, quan hệ có thể kèm "qualifier" mô tả vai trò (vd item "được thêm vào", order "được tạo").
• O2O (object-to-object): hai đối tượng có thể liên quan trực tiếp mà không cần chung sự kiện (vd item thuộc order).
• Thuộc tính đối tượng thay đổi theo thời gian: giá, trạng thái, địa chỉ giao hàng có lịch sử — điều OCEL 1.0 không làm được.
• Ba định dạng: SQLite (quan hệ), XML và JSON, đều có schema chính thức để kiểm tra hợp lệ.

ocel = pm4py.read_ocel2("o2c.jsonocel")            # hoặc .xmlocel / .sqlite
print(pm4py.ocel_get_object_types(ocel))          # ['order', 'item', 'delivery', 'invoice']

# DFG đa đối tượng: mỗi loại đối tượng có "làn" riêng, không nhân bản sự kiện
ocdfg = pm4py.discover_ocdfg(ocel)
pm4py.view_ocdfg(ocdfg)

# Khi cần dùng thuật toán truyền thống: chủ động làm phẳng theo MỘT loại đối tượng
flat_items = pm4py.ocel_flattening(ocel, "item")

5. Khi LLM gặp process mining: để mô hình làm đúng việc

Ý tưởng tự nhiên nhất là đưa event log cho LLM và hỏi "quy trình có vấn đề gì?". Đây cũng là cách làm sai phổ biến nhất. Log thật có hàng triệu dòng, không vừa context window; và kể cả khi vừa, LLM không đáng tin khi tự tính toán số liệu — nó có thể bịa ra thời gian chờ trung bình nghe rất hợp lý. Cách làm đúng là phân vai rõ ràng:

Thư viện pm4py hiện thực hóa đúng triết lý này qua module pm4py.llm: thay vì gửi log thô, nó cung cấp các hàm trừu tượng hóa thành văn bản — abstract_dfg, abstract_variants, abstract_ocel_ocdfg, abstract_temporal_profile, abstract_petri_net… — mỗi hàm nén một góc nhìn của log thành chuỗi văn bản có giới hạn độ dài (max_len). Module cũng có sẵn connector cho OpenAI, Google và Anthropic, cùng các tiện ích như nlp_to_log_query (chuyển câu hỏi tự nhiên thành truy vấn trên log) hay automated_hypotheses_formulation.

import os
import pm4py

# Nén log thành văn bản vừa context: số liệu do pm4py tính, không phải LLM
dfg_text = pm4py.llm.abstract_dfg(df, max_len=8000, include_performance=True)
var_text = pm4py.llm.abstract_variants(df, max_len=4000)

prompt = f"""Bạn là chuyên gia vận hành chuỗi cung ứng.
Dưới đây là tóm tắt quy trình order-to-cash (số liệu đã được tính sẵn, KHÔNG tự tính lại):
{dfg_text}
{var_text}
Nhiệm vụ: chỉ ra 3 điểm nghẽn đáng ngờ nhất, nêu giả thuyết nguyên nhân,
và với mỗi giả thuyết đề xuất một phép kiểm chứng cụ thể trên event log."""

answer = pm4py.llm.anthropic_query(prompt,
                                   api_key=os.environ["ANTHROPIC_API_KEY"],
                                   model="claude-sonnet-5-5")

Về năng lực thật của LLM trong lĩnh vực này, bộ PM-LLM-Benchmark (Berti, Kourani, van der Aalst) là đánh giá có hệ thống đầu tiên: phần lớn các LLM lớn xử lý tác vụ process mining ở mức chấp nhận được, nhưng các model rất nhỏ chạy trên thiết bị biên vẫn chưa đủ. Nhóm tác giả cũng cảnh báo việc dùng chính LLM làm giám khảo chấm điểm dễ gây thiên lệch — một bài học áp dụng cho mọi hệ thống evals.

6. Kiến trúc agentic: Engineer tính toán, Analyst diễn giải

Bước tiếp theo là để agent tự chủ động phân tích. Nghiên cứu PMAx (tháng 3/2026, cùng nhóm RWTH Aachen) đề xuất một kiến trúc hai agent rất đáng tham khảo cho bất kỳ hệ thống "AI phân tích dữ liệu" nào:

• Engineer agent đọc metadata của log (tên cột, loại hoạt động, khoảng thời gian), tự viết script dùng các thuật toán process mining đã được kiểm chứng, chạy cục bộ và sinh ra artifact: mô hình, bảng số liệu, biểu đồ.
• Analyst agent nhận artifact — không phải dữ liệu thô — để diễn giải và viết báo cáo cho người dùng không chuyên.

sequenceDiagram
  participant U as Người dùng
  participant A as Analyst agent
  participant E as Engineer agent
  participant R as Sandbox nội bộ - pm4py
  participant L as Event log
  U->>A: Vì sao đơn miền Trung giao chậm quý này?
  A->>E: Cần thời gian chờ theo vùng, biến thể và điểm nghẽn
  E->>R: Sinh script phân tích và chạy
  R->>L: Đọc log, dữ liệu không rời hạ tầng
  R-->>E: Bảng số liệu, DFG, biểu đồ
  E-->>A: Artifact kèm metadata, không có dữ liệu thô
  A-->>U: Báo cáo nguyên nhân, bằng chứng, đề xuất

Điểm hay của mẫu này: số liệu luôn đúng vì do thuật toán tính; dữ liệu nhạy cảm không bao giờ rời hạ tầng; và script do Engineer sinh ra có thể lưu lại để kiểm tra, tái chạy, đưa vào CI. Đây là một biến thể của nguyên tắc "LLM viết code, máy chạy code" mà mọi hệ thống phân tích nghiêm túc nên theo.

Đóng gói process mining thành MCP tool

Cách thực dụng nhất để các agent vận hành khác (agent CSKH, agent mua hàng, agent điều phối kho) dùng được tri thức quy trình là đóng gói thành MCP server. Celonis đã đi theo hướng này với "Agent Tools (MCP) asset" — cho phép agent truy vấn knowledge model, lấy KPI và insight quy trình, kích hoạt hành động ở hệ thống ngoài và ghi ngược quyết định về nền tảng; xác thực bằng OAuth 2.0, giới hạn mặc định 500 lượt gọi mỗi phút cho mỗi asset. Với stack mã nguồn mở, bạn có thể tự dựng phiên bản tối giản:

import pandas as pd
import pm4py
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("process-intel")
LOG = pm4py.format_dataframe(pd.read_parquet("o2c.parquet"), case_id="order_id",
                             activity_key="activity", timestamp_key="ts")
CASE, ACT, TS = "case:concept:name", "concept:name", "time:timestamp"

@mcp.tool()
def top_variants(k: int = 5) -> list[dict]:
    """Trả về k biến thể phổ biến nhất của quy trình order-to-cash và số case
    tương ứng. Chỉ đọc, không chứa dữ liệu cá nhân."""
    paths = LOG.sort_values(TS).groupby(CASE)[ACT].agg(" -> ".join)
    vc = paths.value_counts().head(k)
    return [{"path": p, "cases": int(n)} for p, n in vc.items()]

@mcp.tool()
def waiting_time(source: str, target: str) -> dict:
    """Thời gian chờ (giờ) khi hoạt động `target` xảy ra ngay sau `source`
    trong cùng một đơn: số lần, trung vị p50 và p90."""
    d = LOG.sort_values([CASE, TS])
    nxt = d.groupby(CASE)[[ACT, TS]].shift(-1)
    m = (d[ACT] == source) & (nxt[ACT] == target)
    if not m.any():
        return {"count": 0}
    h = (nxt.loc[m, TS] - d.loc[m, TS]).dt.total_seconds() / 3600
    return {"count": int(m.sum()), "p50_h": round(h.median(), 1),
            "p90_h": round(h.quantile(0.9), 1)}

if __name__ == "__main__":
    mcp.run()

Chú ý cách viết docstring: mô tả rõ tool trả về gì, đơn vị là gì, có chỉ đọc hay không. Agent chọn tool dựa vào đúng những dòng chữ này. Nên thêm các tool có ngữ nghĩa nghiệp vụ như cases_violating(rule) với danh sách quy tắc định nghĩa sẵn, thay vì mở một tool "chạy SQL tùy ý" — vừa an toàn hơn, vừa giúp agent ít đoán sai hơn.

7. Từ insight đến hành động: đừng tự động hóa quy trình hỏng

Giá trị thật của process mining không nằm ở bản đồ đẹp, mà ở vòng lặp cải tiến liên tục. Khi kết hợp với agent, vòng lặp đó có thể khép kín: agent hành động dựa trên ngữ cảnh quy trình, và chính hành động của agent lại sinh ra sự kiện mới để mining tiếp.

flowchart TB
  M["Mining
event log thành quy trình thật"] --> Q["Chẩn đoán
điểm nghẽn, vi phạm, nguyên nhân"]
  Q --> R["Thiết kế lại
bỏ bước thừa, đổi luật duyệt"]
  R --> AU["Tự động hóa có chọn lọc
rule · RPA · AI agent"]
  AU --> MON["Giám sát vận hành
KPI, dự báo trễ, cảnh báo"]
  MON --> AG["Agent hành động
với ngữ cảnh quy trình qua MCP"]
  AG --> WB["Ghi ngược quyết định
thành sự kiện mới"]
  WB --> M
  classDef hot fill:#e94560,stroke:#fff,color:#fff
  classDef light fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  classDef dark fill:#2c3e50,stroke:#fff,color:#fff
  class M,WB dark
  class Q,R,MON light
  class AU,AG hot

Mỗi tín hiệu từ process mining gợi ý một loại can thiệp khác nhau. Không phải chỗ nào cũng cần AI agent:

8. Góc nhìn mới: mining chính các AI agent

Có một ứng dụng thú vị đang nổi lên: dùng process mining để hiểu hành vi của agent. Một agent chạy production sinh ra hàng nghìn trace mỗi ngày, mỗi trace gồm nhiều bước gọi model, gọi tool, thử lại. Dashboard observability cho bạn xem từng trace riêng lẻ; process mining cho bạn thấy bức tranh tổng thể: agent thực sự đi những con đường nào, vòng lặp nào tốn kém nhất, và có tuân theo kế hoạch thiết kế ban đầu không.

Quy ước ngữ nghĩa GenAI của OpenTelemetry (đang ở trạng thái Development) đã chuẩn hóa tên span cho agent như invoke_agent, execute_tool, kèm thuộc tính gen_ai.agent.name, gen_ai.tool.name. Nhờ đó việc chuyển trace thành event log trở nên khá cơ học:

flowchart LR
  T1["invoke_agent
support_agent"] --> T2["chat
lập kế hoạch"]
  T2 --> T3["execute_tool
search_orders"]
  T3 -->|"62%"| T4["execute_tool
get_invoice"]
  T3 -->|"38% · lỗi schema, thử lại"| T3
  T4 --> T5["chat
soạn trả lời"]
  T5 -->|"21% · guardrail chặn"| T2
  T5 -->|"79%"| T6(("Trả kết quả"))
  classDef hot fill:#e94560,stroke:#fff,color:#fff
  classDef light fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  class T3 hot
  class T1,T2,T4,T5 light

spans = pd.read_json("agent_spans.jsonl", lines=True)
spans = spans[spans["name"].str.startswith(("invoke_agent", "execute_tool", "chat"))]

agent_log = pm4py.format_dataframe(
    spans.rename(columns={"trace_id": "case", "name": "activity", "start_time": "ts"}),
    case_id="case", activity_key="activity", timestamp_key="ts")

# Con đường thực tế của agent so với luồng thiết kế
pm4py.view_dfg(*pm4py.discover_dfg(agent_log))
plan_net, im, fm = pm4py.read_pnml("support_agent_plan.pnml")
print(pm4py.fitness_token_based_replay(agent_log, plan_net, im, fm))

Một lưu ý kỹ thuật: trace của agent có span lồng nhau và chạy song song, nên thứ tự theo thời gian bắt đầu không phải lúc nào cũng phản ánh quan hệ nhân quả. Hãy chọn một mức trừu tượng nhất quán (vd chỉ lấy span gọi tool và gọi model), hoặc mô hình hóa theo hướng object-centric với các loại đối tượng như hội thoại, agent, tool.

9. Những cái bẫy khi triển khai thực tế

• Trích xuất dữ liệu chiếm phần lớn công sức. Các dự án process mining thường dành phần lớn thời gian cho việc xác định bảng nào chứa sự kiện gì, nối khóa giữa các hệ thống và làm sạch. Đừng hứa dashboard trong tuần đầu.
• Timestamp là cái bẫy lớn nhất. Múi giờ lẫn lộn (server UTC, người dùng GMT+7), độ phân giải chỉ đến ngày khiến thứ tự sự kiện trong cùng ngày bị đảo, hoặc batch job ghi cùng một thời điểm cho cả trăm sự kiện. Chuẩn hóa về UTC và ghi lại độ tin cậy của từng nguồn.
• Tên hoạt động không thống nhất. "Duyệt ĐH", "Approve Order", "DUYET_DON" là cùng một bước. Đây là nơi LLM hữu ích thật sự: đề xuất bảng ánh xạ để con người duyệt.
• Quyền riêng tư và con người. Event log có trường resource — tức là tên nhân viên. Phân tích hiệu suất theo từng cá nhân dễ biến thành công cụ giám sát và làm mất lòng tin. Hãy ẩn danh hóa, tổng hợp theo nhóm, minh bạch mục đích với nhân viên, và tuân thủ Luật Bảo vệ dữ liệu cá nhân (có hiệu lực từ 1/1/2026).
• Giấy phép. pm4py dùng giấy phép AGPL-3.0; nếu nhúng vào sản phẩm thương mại mã nguồn đóng, cần xem xét giấy phép thương mại riêng mà đơn vị phát triển cung cấp.

10. Lộ trình áp dụng 90 ngày

Kết luận

AI agent làm cho việc tự động hóa trở nên rẻ hơn bao giờ hết — và chính vì rẻ, rủi ro tự động hóa sai chỗ cũng lớn hơn bao giờ hết. Process mining là lớp "nhìn thấy" mà mọi chiến lược tự động hóa cần có trước: nó cho biết quy trình thật vận hành ra sao, chỗ nào chờ, chỗ nào làm lại, chỗ nào lệch chuẩn, dựa trên 100% dữ liệu thay vì cảm nhận.

Bức tranh năm 2026 khá rõ ràng: thuật toán process mining lo phần tính toán tất định, chuẩn OCEL 2.0 giúp mô tả đúng thế giới nhiều đối tượng, LLM lo phần hiểu câu hỏi và diễn giải, còn MCP biến tri thức quy trình thành ngữ cảnh mà agent vận hành có thể truy vấn. Một bước nhỏ để bắt đầu ngay tuần này: xuất audit log của một quy trình bạn quen thuộc ra CSV, chạy năm dòng pm4py ở trên, và đếm xem quy trình "bảy bước" của bạn thực ra có bao nhiêu biến thể.