WTWilly Tai
Case study · live demoAssurance · Process Intelligence

The process you designed is not the process you run. The log knows the difference.

Every ERP already records who did what, to which document, at what time. Process mining reads those events back and draws the as-is process: every path actually taken, the approval that quietly takes three days, the payments that ran before their approvals. This workbench mines 700 procure-to-pay cases live in your browser: the map is computed from the log, not drawn from the SOP, and every deviation it flags is a named case you can open. Clickable link below.

01 / The pain

Nobody in the building knows the real end-to-end process, and the interviews will not tell you.

Ask a process owner to describe procure-to-pay and you get the SOP: requisition, approval, PO, receipt, invoice, match, pay. Ask the event log and you get something else: dozens of distinct variants, rework loops around the invoice match, purchases where the PO was raised after the invoice arrived to paper over a commitment already made, and one department whose PO approvals take days while everyone else's take hours. Consultants traditionally rebuild this picture through workshops, at workshop speed and workshop accuracy. Meanwhile the truth sits in the transaction tables, timestamped, complete, and unread. Process mining is a decade-old discipline built on exactly this insight, and it is why the market leader, Celonis, was valued around US$13 billion at its 2022 raise.

02 / Why the naive approach fails

"Feed the SOPs to an AI and ask it to draw the flowchart" documents the intention, not the behaviour.

The tempting shortcut is to hand the process documents to a language model and ask for a diagram. Three things are wrong with that:

So the workbench keeps the division of labour clean: discovery, conformance and performance are deterministic algorithms over the log. The place where documents matter is upstream, and it is honest about that too: every event in the log carries the source document that stamped it, because process mining's input is documents' timestamps, assembled into cases.

03 / How it works

Three columns in, four instruments out.

An event log needs exactly a case ID, an activity and a timestamp (here enriched with user and source document). From that the workbench derives everything on screen. The map is the directly-follows graph: nodes are activities, edges carry how many cases traversed them, and an abstraction slider hides rare paths the way commercial miners do, so the map stays readable without lying about completeness (the hidden-path count is always shown). Flip the edge metric to performance and the same map recolours by median waiting time. The variant explorer ranks every distinct path. And conformance is four deterministic control rules, checked against all 700 cases: payment before approval, invoice before the PO existed, goods paid without a receipt, and one person holding both payment keys.

THE DOCUMENTS PR-1042 · approved PO-1042 · sent GRN-1042 · booked INV-1042 · matched PAY-1042 · executed THE EVENT LOG (case, activity, timestamp,  user, source_document) 700 cases · 6,787 events process map + slider variant explorer performance view conformance findings every instrument is a deterministic computation over the log · rerun it and the same findings return
fig.1 · documents stamp events; deterministic mining turns events into instruments
04 / One worked example

Slide to abstract, flip to performance, then open the case that paid early.

Open the map at its default abstraction and you see the designed process, plus the rework loop the SOP never mentioned. Drag the slider to zero and the long tail appears: the map grows the rare edges, including Invoice Received → Create PO, which should never exist. Flip to performance and one edge glows red: Create PO → Approve PO. Filter to the Facilities department and the median on that edge jumps to days while every other department clears in hours: a bottleneck found in three clicks, with the filter as the diagnosis. Then open Conformance: every rule lists its cases, and every case opens into its own timeline with users and source documents.

QuestionInstrumentWhat the log answers
What do we actually run?map + sliderthe designed path plus every real variant, counted
Where does it crawl?performance + filterPO approval, and only in one department
Where did controls break?conformance rulesnamed cases: paid-before-approved, maverick buys, missing GRNs, SoD
The map is a by-product. The findings are the product. A flowchart on a wall changes nothing; a list of fourteen named cases where money moved before approval, with timestamps and user IDs, changes a control. That is what separates process mining as an assurance instrument from process mapping as decoration.
05 / Numbers & honest trade-offs

What it does, and what it does and doesn't prove.

700
cases mined live
6,787 events, mined in the browser on every load.
3
columns required
Case, activity, timestamp. Everything else is derived.
4
deterministic rules
Every flagged case named, none sampled.
100%
population coverage
Checks run on all cases, not an audit sample.

Where this stands, honestly. The log is synthetic, from a seeded generator, so every visitor mines the identical data; the generator plants realistic behaviour but writes no labels, and the miner re-derives every finding from raw events (the full log is inspectable on its own tab). Real engagements start one step earlier, extracting the event log from ERP tables, and that extraction is where most of the effort and most of the risk lives. The mining itself is deliberately classical: directly-follows discovery and rule-based conformance, the parts that stay defensible in front of a process owner. The public benchmark culture for the discipline is real too: the BPI Challenge logs are genuine anonymised enterprise event logs, and this workbench's algorithms are the same family that runs on them.

Where AI genuinely helps, and where it doesn't. Mapping messy source tables into case-activity-timestamp form, naming variants in plain language, drafting the finding narrative: model work, useful. Deciding what counts as a deviation, computing the map, attributing cases: deterministic work, and it must stay that way, because a conformance finding that cannot be recomputed is an anecdote. The workbench draws that line visibly: no model touched anything on screen.

06 / Governance, shown

Every finding resolves to cases, documents and timestamps.

Each conformance rule states its logic, and each flagged case opens into a timeline where every event carries its user and the document that stamped it. The finding is not "the model thinks something is off"; it is a property of the records.

Conformance finding · drill-downdeterministic · full population
R1 · Payment executed before it was approved · 14 cases
C1246 · Facilities · Northpoint M&E · S$3,820
  09 Jun 14:12  Execute Payment   tay.hl   PAY-0246
  09 Jun 15:03  Approve Payment   goh.ct   PAY-0246   ← control ran after the money moved

R4 · Same person approved and executed · flagged from user IDs, not narrative
The rules never sample: all 700 cases are checked, and a rerun returns the identical list. The same population-not-sample discipline as the rest of the portfolio.

What this says about how I work.

Process mining was fashionable before language models arrived, and the fashion moved on; the discipline did not stop being right. I trained as an accountant and an internal auditor, and what this instrument delivers is what audit always wanted: the full population instead of the sample, the actual process instead of the described one, findings that resolve to records instead of recollections. The craft decision that matters is refusing to let a model redraw what an algorithm can compute: the map with numbers on its edges is worth more than a prettier diagram that cannot defend itself. Where models help, upstream in extraction and downstream in narration, I use them. Where determinism is the product, I keep them out.

See it run, live.

Drag the abstraction slider to zero and watch the long tail appear. Flip to performance view and find the Facilities bottleneck. Open R1 and click the case that paid early: its whole timeline is there, users and documents included. Then read the log tab to see exactly what three columns produced all of it.

Open the workbench →Runs client-side over a synthetic log: no sign-in, nothing to install.