Process Discovery
Part of Process mining and operational evidence
Checking whether available event data supports process mining
Check case IDs, activities, timestamps and event coverage before deciding whether process mining can answer your question.
Available data can support a process-mining question when you can reliably link activities to the same case, order them in time and identify the events needed to answer that question.
A current status and last-updated date usually cannot show the path taken to that status.
Check a small extract before committing to a larger analysis. Decide what it can answer, what needs repair and when another method is needed.
Define the question and case
Write one question, such as 'Which request routes repeatedly return to intake?' Choose the unit that makes one case: a request, order or claim.
Check whether its identifier persists across the steps in scope. If an order has several lines that take different routes, decide whether the analysis concerns orders or lines before joining their events.
State the observation window and expected start and end events. Include still-open cases in the data assessment so the extract does not appear more complete than the work is.
Inspect the event fields
Ask each proposed event source for a sample and field definitions. A conventional event log associates a case identifier, activity and timestamp with each event. Some products use one timestamp for an event; suitable start and end fields can support activity-duration analysis.
| Check | Question for the sample |
|---|---|
| Case ID | Do events for one case join without combining separate cases? |
| Activity | Does each name identify a meaningful step or status change? |
| Time | Is the timestamp parseable, consistently zoned and tied to a known event? |
| Coverage | Are the start, material transitions and outcome recorded? |
| Provenance | Which system created each event, and can its meaning be checked? |
One activity name offers little route analysis. A table storing only the latest state may require a separate history source. Events spread across systems need defensible joins.
Document how source records become analysis rows so a surprising route can be traced back.
Key checks before proceeding with process mining
- Case ID integrityEvents for one case do not merge with events from other cases
- Activity clarityEach activity name represents a meaningful step or status change
- Timestamp reliabilityTimestamp is parseable, consistently zoned and linked to a known event
- Event coverageStart, material transitions and outcome are recorded
- Provenance traceabilityEach event’s source system is identifiable and its meaning verifiable
Challenge the extract with cases
Subject to authorised access, select cases with different outcomes and compare their source histories with the proposed event rows. Look for missing steps, duplicate status writes, reused IDs, timestamps in the wrong order and work done outside the extracted systems. Check whether closure represents the business endpoint or only one team's task.
Record row and distinct-case counts before and after cleaning or filtering. State which case types and periods were excluded. Dropping incomplete cases may simplify a map while making it unsuitable for a question about unresolved work.
Data assessment metrics to track
- Row count (before cleaning)
- To be determined from sample extract
- Distinct case count (before cleaning)
- To be determined from sample extract
- Row count (after cleaning)
- To be determined from cleaned extract
- Distinct case count (after cleaning)
- To be determined from cleaned extract
Decide how to proceed
Proceed with a bounded analysis if case linkage, event meaning and coverage are adequate for the stated question. Report known gaps with the result.
Repair the extract if historical events exist but IDs, time parsing or activity labels need a defensible transformation. Recheck sample cases after the repair.
Use another method first if critical work is unrecorded, case identity cannot be established or available rows show only current state. Case-file review, observation or staff walkthroughs may answer a narrower question and reveal what should be recorded in future.
Process mining readiness: what to do based on data quality
- Proceed with bounded analysisCase linkage, event meaning and coverage are adequate for the question; report known gaps
- Repair the extractHistorical events exist but require defensible transformation of IDs, timestamps or activity labels
- Use another method firstCritical work is unrecorded, case identity cannot be established, or only current state is available
