Skip to content

Process Mining Review

Software tool — instantiates Informal Structure Mapping

Reconstructs the actual process from timestamped event logs in operational systems and conformance-checks it against the intended workflow, across every case at once.

Process Mining Review is the tool that reads the real process out of the machine's own footprints. Where a hand-drawn map traces a handful of cases and an ethnographer watches a few, process mining ingests the timestamped event log an operational system already produces — every case ID, activity, and time — and algorithmically reconstructs the actual process model: which steps really follow which, how often each path is taken, where cases loop and queue. Its defining strength is completeness at scale: it sees all the cases, not a sample, and it does so objectively from data no one curated for the purpose. Its defining limit is the mirror image — it sees only what leaves a digital trace, so any coordination that happens in a hallway, a phone call, or an unlogged spreadsheet is simply invisible to it.

Example

A large auto insurer suspects its claims process is slower than its documented workflow implies. The intended path is clean: file → assess → approve/deny → pay. Process Mining Review extracts the event log from the claims system — illustratively, several million events across a year of cases — and discovers the actual process graph. It looks nothing like the diagram. Roughly a third of claims (an illustrative figure) pass through a "reassign adjuster" activity two or three times before assessment completes, and cases pile up in a queue before senior-adjuster review, which turns out to be the true throughput bottleneck. Conformance checking flags the reassign loop as a deviation from the intended model present in no documentation.

The tool doesn't say why claims bounce between adjusters — that's not in the log. But it says, with the whole population behind it, exactly where and how often, and it keeps saying so: fed by the live event stream, the discovered model refreshes continuously as new claims flow through, so the map never silently goes stale.

How it works

What distinguishes the tool from a manual map is that the model is derived, automatically, from data:

  • Extract the event log — the minimum is a case ID, an activity name, and a timestamp per event, pulled from the system of record.
  • Discover the actual model algorithmically (e.g. a directly-follows graph), so the process is inferred from what the data did, not from what anyone drew.
  • Conformance-check the discovered model against the intended workflow, flagging deviations, loops, and skips as structural facts.
  • Quantify flow — frequencies, throughput times, and the queues where cases wait — and refresh from the live stream so the model tracks reality over time.

Tuning parameters

  • Log scope and filtering — which activities and case types enter the log. Broader scope is more complete; aggressive filtering sharpens the picture but can erase real minority paths.
  • Discovery algorithm / noise threshold — how rare a path must be before it is dropped as noise. Low thresholds show every exotic variant (a hairball); high thresholds hide rare-but-critical routes.
  • Conformance strictness — how much deviation from the intended model counts as nonconformance, trading false alarms against missed drift.
  • Variant cutoff — how many distinct process variants to display before collapsing the tail; controls readability versus completeness.
  • Refresh interval — batch snapshot versus continuous streaming; continuous keeps the model live but costs pipeline complexity.

When it helps, and when it misleads

Its strength is objectivity and coverage: it reconstructs the real path over every case, free of the sampling bias and recall error that dog interviews, and it surfaces bottleneck queues and rework loops no one would confess to.[n1] For high-volume digital processes it is the fastest route to a truthful actual-practice picture.

Its central failure mode is that it sees only digital footprints. Work that happens off-system — the informal phone call that resolves an exception, the shadow spreadsheet, the hallway approval — is invisible, so an over-trusted mining result can declare a process "clean" precisely where its most important informal repair is happening off the record. Log quality compounds this: missing or mistimed events distort the model. And a discovered path is a what, never a why — the reassign loop is a fact, but its cause is not in the data. The discipline that guards against this is to pair mining with observation before acting, and to treat every flagged deviation as a question to investigate, not a verdict to enforce.

How it implements the components

Process Mining Review fills the data-derived slice of the archetype:

  • actual_practice_trace — its primary output: the actual process model reconstructed from event logs across the full case population.
  • broker_or_bottleneck_node — flow quantification locates the queues and pile-up steps where throughput actually chokes (a bottleneck in the log, not a person in a network).
  • map_update_cadence — fed by the live event stream, the discovered model refreshes continuously, so the map stays current rather than freezing at first draw.

It detects deviation but cannot explain it: it does not produce the formal_informal_gap_diagnosis of why a shadow path exists — that reasoning is Shadow Process Audit and Workflow Ethnography — and it never sees off-system social ties, so it builds no informal_network_map, which is Organizational Network Analysis.

Editorial Notes

Form Classification

Form family: Monitoring, Sensing & Alerting

Rationale: The mechanism refreshes an automatically discovered process model from live event streams and flags deviations, loops, skips, and flow changes over time.

Nearest alternative: Analysis, Modeling & Optimization — Algorithmic inference builds the view, but repeated actual-state observation is the operative ongoing form.

Review outcome: Adjudicated after independent review; high confidence.

Origin Attribution

Primary origin: Computer Science & Software Engineering

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Specialized

Rationale: Process Mining Review is most plausibly rooted in the computer_science tradition because its characteristic form depends on algorithms, data structures, formal interfaces, and software-system practice. The assignment tracks that formative lineage, not the many settings in which the mechanism can now be applied.

Related originating lineages:

  • Data Science & Analytics — The data_science tradition materially shaped Process Mining Review through its own practice of production data pipelines, predictive modeling, and machine-learning validation.
  • Organizational & Management Science — The organizational_management tradition materially shaped Process Mining Review through its own practice of the coordination, governance, learning, and redesign of organized work.

Review outcome: Independent reviewer agreement; high confidence.

Notes

[n1] Process mining and its conformance checking step — reconstructing and diagnosing processes from event logs — were established as a discipline largely through the work of Wil van der Aalst. The technique's power and its blind spot are two sides of one fact: it can only ever see the process the logs recorded.