Process mining

Forge

Reconstructing how a process actually operates from system event logs, rather than from how it is documented.

What is process mining?

Process mining is the reconstruction of how a process actually operates, derived from the event logs the systems already hold. Each case is assembled into the sequence of steps it followed, which exposes the variants nobody documented. It describes the process as performed rather than as written down.

Why the documented process is the wrong place to start

Automation programmes fail most often at the point of discovery, before any agent exists. The process everybody describes in a workshop is the compliant version that omits the workarounds and the rekeying. Event logs carry the uncomfortable version, including the case that waited for weeks and the step performed twice on a large minority of cases. Choosing what to automate from the documented process produces an agent that meets a variant few cases follow.

  • Event logs record what happened, which no workshop can reliably recall.
  • Variant analysis shows how many paths a single process actually takes.
  • The cases consuming the most elapsed time are usually the undocumented ones.
  • A baseline measured beforehand is the only honest basis for a later claim.

How process mining works

  • Event data is extracted so that each activity carries a case identifier and a timestamp.
  • Cases are assembled into end to end sequences and grouped by variant.
  • Frequency and elapsed time are calculated for each variant and each transition.
  • Rework loops and waiting time are located against the steps that produce them.
  • Candidate work is selected on volume alongside the cost of an error.
  • The baseline is recorded so that any later improvement is measurable against it.

How process mining is evaluated

Process mining is judged on whether its reconstruction matches what practitioners recognise. Examine the following before any automation is scoped:

  • share of cases covered by the extracted event data
  • number of variants accounting for most of the volume
  • elapsed time per variant against the documented expectation
  • rework rate per step across the full case population
  • agreement between the discovered model and operator description

Limitations, risks and common failure modes

  • Event logs omit the steps performed outside the system entirely.
  • Timestamps are recorded at batch commit rather than at the moment of the action.
  • A case identifier breaks where work moves between two systems.
  • Analysis settles on the most frequent variant, which is rarely the expensive one.
  • Discovery becomes a reporting exercise that no automation decision ever consumes.

All 315 terms