Process Discovery
Process mining and operational evidence
Learn what process mining can show from event logs, where its evidence stops and how to investigate recorded routes and delays.
Process mining uses recorded events to examine how cases moved through a process. It can show common routes, repeated steps and intervals between events. It cannot, on its own, explain why someone waited, reveal unrecorded work or prove that a proposed change would improve the business result.
Start with a question the process owner can investigate. The answer depends on the case boundary, the events captured and how those events are interpreted.
Pros and Cons of Process Mining for Operational Evidence
- Pros
- Reveals actual process routes, identifies bottlenecks, supports compliance checks
- Cons
- Cannot explain why delays occurred, misses unrecorded work, depends on data quality
Define the case and its result
Choose one unit of work, such as a service request or purchase order. Define its first event and the outcome that counts as completion. Then check whether the systems involved retain the steps between them. A record showing only the current status cannot reconstruct the route a case took.
In a conventional event log, each event has a case identifier, activity and timestamp. Resource information may also be available. The case identifier matters: a customer ID could combine several separate requests into one misleading sequence.
Record which cases, systems and dates the extract covers. Check whether the final event represents the business result or only an internal task closing. Describe email, phone or spreadsheet work outside the log as a gap in the recorded view.
Read each finding for what it shows
| Question | Evidence to inspect | What remains uncertain |
|---|---|---|
| Which routes occurred? | Event sequences, variants and case counts | Whether an unlogged action changed the route |
| Where did time pass? | Case duration and intervals between named events | Whether an interval was queueing, authorised waiting or work elsewhere |
| Did cases follow an expected route? | Recorded cases compared with a defined process model | Whether the model and event mapping are appropriate for those cases |
A process map summarises activities and transitions, but its paths depend on the data and the chosen view. Check striking patterns against individual case histories. Compare like cases: an urgent exception and a routine request may legitimately take different routes.
Keep elapsed time separate from active work. Assignment and approval events establish the interval between those records. They do not establish how long a person worked during it. That requires suitable activity-duration data or another reliable measure.
Process Mining Workflow Timeline
- Data Collection
- Extract event logs from systems (ERP, CRM, etc.)
- Event Mapping
- Assign case IDs, timestamps, activities and resources
- Model Discovery
- Generate process maps from observed sequences
- Conformance Checking
- Compare real paths against expected models
- Decision & Improvement
- Act on findings with follow-up validation
Trace event data to its origin
Event data may come from a database, spreadsheet, transaction log, enterprise resource planning system, message log or open application programming interface. Identifying the source helps clarify which operational actions the log can represent and whether several systems contribute records to the same case.
XES, or eXtensible Event Stream, is a standard format for exchanging event data between information systems and analysis tools. The IEEE Task Force on Process Mining adopted it in 2010, and it became an official IEEE standard in 2016. The standard aims to fix both the syntax and semantics of event data so it can be understood clearly at both the generating and analysing sites.
Key Facts About Event Data and Process Mining
- Standard Format
- XES (eXtensible Event Stream)
- Adopted By
- IEEE Task Force (2010), IEEE Standard (2016)
- Common Sources
- ERP systems, databases, message logs, APIs
Choose measures that match the question
Time measures describe different things. Lead time is the total time from case creation to completion; service time is time worked on a case; and waiting time is time a case waits for a resource to become available. With concurrent work, total service time may exceed lead time, so the measures should not be treated as interchangeable.
Some recorded intervals may reflect synchronisation rather than a resource queue: an activity can be waiting for an external trigger or another parallel branch. Decide which time measure fits the operational question before interpreting a long interval as delay.
Time Measures in Process Mining: Key Differences
- Lead Time
- Total time from case creation to completion
- Service Time
- Time actively worked on a case
- Waiting Time
- Time a case waits for a resource to become available
Use models as comparison points
A process model discovered from an event log represents behaviour observed in that log. Discovery methods can present different abstraction levels, so a broad view may summarise activity while a more detailed view retains distinctions that matter to the question. A model remains an interpretation of recorded behaviour, not proof that every relevant action was captured.
Conformance checking compares observed behaviour with a process model. Its uses include checking compliance with boundaries set by managers, governments or other stakeholders, evaluating a discovered model against its log or unseen test data, and checking conformance to software or service specifications. The comparison depends on the model and on how recorded events are interpreted.
Consider more than time
Process performance can also be examined through cost and quality, not just time. Cost measures may reflect fixed activity costs or costs that depend on the resource used, its utilisation or the activity’s duration; resource utilisation can be tracked over a defined period.
Quality measures concern the product or service delivered. Possible indicators include customer satisfaction measured through questionnaires, average complaints per case or product defects. These measures provide different evidence from route and timing data, so choose indicators that correspond to the result the process owner wants to assess.
Turn a pattern into a decision
Suppose a request log shows cases returning from review to intake. Confirm what both events meant during the period studied. Inspect returned cases and ask the teams what prompted the return. Missing information, a required second review and a duplicate system event call for different responses.
For each finding, record the cases covered, the observed pattern, its count and time measure, known gaps, possible explanations and the next evidence check. If a change follows, compare later outcomes as well as the route. A shorter interval for one team may hide correction work passed to another.
Process mining is useful when comparable cases leave a dependable event history. When important actions are missing, use case records and staff accounts before making a broad claim. A small log may identify a trace worth checking without establishing how common it is.
Steps to Effective Process Mining Analysis
- Define the case and its outcomeChoose a unit of work (e.g., purchase order) and identify start and completion events
- Trace event data to originIdentify source systems (ERP, database, API) and confirm data integrity
- Select appropriate measuresMatch time, cost or quality metrics to the operational question
- Compare with a process modelUse conformance checking to assess compliance or performance gaps
- Investigate patterns with contextCheck team input, missing data and system behaviour before acting
In this guide
- Comparing process logs with the documented workflowMap logged events to the applicable workflow, inspect differences by case and decide whether a gap concerns data, documentation or the route taken.
- Identifying repeated handoffs in a processTrace ownership changes by case, count returns and check why work crossed the same team boundary more than once.
- Distinguishing observed delay from its underlying causeLearn what a long gap in a process log establishes and how to check possible causes against case records.
- Checking whether available event data supports process miningCheck case IDs, activities, timestamps and event coverage before deciding whether process mining can answer your question.
