Discover the process.
Reconstruct activities from recorded events. Compare common routes, exceptional paths and repeated steps.
Understand the work. Improve the process.
Coming soon
Process mining turns the events recorded by your systems into a clear view of how work gets done. Find bottlenecks, investigate root causes and measure the impact of changes.
01 / The idea
What is process mining?
Process mining is the analysis of recorded business events to reconstruct how a process actually runs. It links each order, claim or other work item to the activities performed on it, their sequence and the time between recorded steps. That history shows the routes work actually takes through your organisation.
Use those routes to locate bottlenecks, investigate repeated work and examine handovers or rule breaches. Combine the findings with operational knowledge to decide what to improve, then measure the recorded process as it changes.
Measure performance.
Use recorded times and sequence to measure lead time, processing intervals, handovers and repeated work.
Check your controls.
Test your operating rules against recorded actions and follow each flagged breach to the records that triggered it.
02 / The evidence
Start with the events behind the work.
Work-item identity, activity and sequence establish the process. People, teams, calendars and rules give you more ways to understand performance.
Identity
Which work item?
A stable order, claim, invoice or other work-object identifier connects related events. Define exactly what that identifier represents before joining records.
Activity
What happened?
Recorded steps such as Register, Inspect, Approve or Dispatch. Use consistent names and definitions so each activity has a clear meaning.
Order and time
When and in what order?
A declared step number or sequence column establishes the route. Timestamps support timing and never replace declared order; start and end times support duration analysis. Without a declared order, the events are kept and paths are withheld.
Optional
Who, where, and under which rule?
Defined people, teams, calendars, due dates and controls support workload and compliance analysis. Missing values are reported as unavailable, preserving the difference between missing and zero.
Cases and connected work objects.
A classic event log groups events under one process instance, often called a case. Operations also connect orders, shipments, invoices and other work objects. Analysing those relationships requires recorded links and a clear definition of what each object represents.
What can you bring?
Start with event histories from ERP, CRM, workflow, ticketing or other systems. Ghost Observatory uses explicit YAML mappings to define the data and publishes the analysis in an auditable SQLite result.
Check required export fieldsPreparing an event log? Inspect the sample rows and preparation guide
Interactive process story / illustrative invoice
Seven events. One gap worth investigating.
Follow one illustrative invoice through seven recorded events. Investigate waiting, handovers and fair attribution. These values teach the method; they are not Observatory results or a customer benchmark.
Invoice INV-001 / fictional records
Seven events, from Day 1 to Day 8.
ReceivedDay 1 · Finance
CheckedDay 1 · Finance
Sent for approvalDay 2 · Finance
Queue observedDay 6 · Management
ApprovedDay 6 · Management
ScheduledDay 7 · Finance
PaidDay 8 · Finance
Elapsed time / recorded evidence
What happened between the records?
Day 1: the invoice is received. No elapsed-time conclusion yet.
The Day 2–6 interval contains no intervening event in this illustrative history. It does not establish that no work occurred, why the invoice waited, or anyone's working time.
Day 1: the invoice is received. This is the first recorded event in the illustrative history.
The longest illustrated gap lies between the Day 2 handover and the Day 6 queue observation. It is elapsed time, not a proven cause or labour duration.
Illustrative records only. WebGPU adds animated connections; all events and explanations remain available without it.
03 / See the proof
See a control check from start to finish.
Our published synthetic claims example contains 300 claims and 7,402 recorded events. The rule asks whether the same person assessed and approved the same claim.
Inspect the source-linked worked example04 / Interpreting results
Know what each measure establishes.
Reliable process intelligence makes the basis of each conclusion clear: the events recorded, the time measured and the sources used.
- 01
Keep record gaps visible.
An absent event leaves an unanswered question. Check whether the activity was unrecorded before concluding that it was skipped.
- 02
Distinguish elapsed time from effort.
A claim waiting overnight has an elapsed interval. Labour time requires separate evidence of the work performed.
- 03
Investigate the cause. Quantify the effect.
Use queues and repeated work to focus the investigation. Establish the cause with operational context, then combine measured time with cost data to build the business case.
- 04
Set clear source authority.
Specify which system supplies identity, sequence and duration when sources disagree. Those decisions keep the analysis consistent and traceable.
Independent reference
For the foundations of the field, see the Process Mining Manifesto (IEEE Task Force on Process Mining).
Ready to see the product?
Explore the Reader captures, the sample data and the complete data requirements.
Explore six Reader viewsFrom the method to a measurable question.
Use the event-log guide to prepare the evidence. Then choose between following a process path and calculating time: the two require different fields.