Process mining is a family of methods for reconstructing and analysing how a process actually unfolded from the digital traces left by real work.
Most organisations already possess fragments of these traces. An order is created. A document is approved. A patient is registered. A service ticket changes status. A machine enters maintenance. A payment is released. A case is escalated. A shipment leaves a warehouse.
Each event may look trivial in isolation. Put the events in the right order, connect them to the same case, and a hidden process begins to appear.
The core idea: instead of asking people how the process is supposed to work, reconstruct what the recorded process actually did.
That difference matters because designed processes and lived processes often diverge. A procedure may show six steps. The event log may reveal twelve common variants, repeated loops, long waiting periods, emergency bypasses and manual handoffs nobody included in the official diagram.
The direct answer
Process mining works by converting event data into a sequence-aware representation of work.
At minimum, an event log normally needs three things:
- Case identifier: which order, claim, ticket, application, machine, patient journey or other process instance the event belongs to.
- Activity: what happened.
- Timestamp: when it happened.
Useful logs often contain more: resource, team, location, system, cost, status, product type, priority, channel and other attributes.
From those records, process-mining methods can support three classic jobs:
- Discovery: infer process structure from the event data.
- Conformance checking: compare recorded behaviour with an intended or permitted process model.
- Enhancement: enrich an existing process model with evidence about timing, bottlenecks, frequencies, resources or other operational properties.
The result is not a magical picture of truth. It is a model reconstructed from traces. Its usefulness depends on whether the traces represent the process well enough to support the question being asked.
1. A process is more than a list of tasks
Traditional reporting often counts activities separately.
- How many orders were approved?
- How many claims were closed?
- How many tickets were escalated?
- How many invoices were paid?
Those measures can be useful. They do not tell you how one case travelled through the system.
Process mining restores sequence.
It can distinguish:
- A → B → C → D
- A → B → C → B → C → D
- A → C → D
- A → B → E → D
All four cases may end in the same status. Operationally, they are not the same journey.
This is the first major reader value of process mining: outcomes are reconnected to the paths that produced them.
2. The case identifier quietly defines the world
Before any algorithm runs, somebody must decide what counts as one case.
That choice can change the analysis.
In an order-to-cash process, should the case be:
- the customer order;
- the order line;
- the shipment;
- the invoice;
- the payment;
- the customer relationship?
Each choice creates a different process view.
An order can split into several shipments. Several orders can be consolidated into one invoice. One payment can settle several invoices. If the case definition ignores these relationships, a clean-looking process map may be structurally wrong.
The case identifier is therefore not clerical metadata. It is a modelling decision.
3. Event extraction is where many projects become fragile
Business systems are rarely designed with process mining in mind.
Useful events may be scattered across:
- ERP systems;
- CRM systems;
- workflow platforms;
- ticketing systems;
- databases;
- machine logs;
- document systems;
- spreadsheets;
- email or messaging records;
- specialist operational applications.
Recent process-mining research continues to identify event-log preparation as a major practical challenge. Data must often be found, joined, cleaned and transformed before process discovery becomes meaningful.
If the event extraction is wrong, the process model can be confidently wrong.
4. Timestamps look objective until you ask what they mean
A timestamp may record:
- when work started;
- when work ended;
- when a database row was updated;
- when a user clicked save;
- when a batch job posted the transaction;
- when an external system delivered the message;
- when the event was later reconstructed.
Those are not interchangeable.
If a nightly batch posts hundreds of transactions at midnight, the log may make many activities appear simultaneous even though the real work happened throughout the day.
Process mining therefore needs timestamp semantics, not merely timestamp fields.
5. Discovery turns traces into a model
Process discovery algorithms infer process structure from event sequences.
They try to capture relationships such as:
- what usually starts a case;
- which activities follow which;
- where paths branch;
- where activities can occur in parallel;
- where loops occur;
- which endings are common;
- which rare variants exist.
The result may be represented using process models such as Petri nets, directly-follows graphs, BPMN-like structures or other formal and visual representations.
The goal is not to draw every possible arrow. It is to produce a representation useful enough to answer the operational question.
6. The spaghetti-model problem
A process map can become unreadable when every rare path is displayed at once.
Large organisations may have thousands of process variants. If the model faithfully renders every one, the result can resemble spaghetti rather than explanation.
This creates a trade-off between:
- fitness: how much observed behaviour the model can reproduce;
- precision: how much extra behaviour the model permits beyond what was seen;
- simplicity: whether people can understand the model;
- generalisation: whether the model captures real structure rather than memorising the log.
A model that fits every historical exception perfectly may be too complex to teach anything useful.
7. Variants reveal how many processes are hiding inside “the process”
Managers often speak of a process in the singular.
The event data may reveal many variants.
For an invoice process, one path may be:
receive → validate → approve → pay
Another may be:
receive → validate → reject → correct → validate → approve → hold → release → pay
The second route may consume far more time even if the actual work minutes are similar, because waiting accumulates between handoffs.
Variant analysis therefore gives organisations a way to ask which routes are normal, exceptional, costly, risky or surprisingly successful.
8. Bottlenecks often live in waiting, not work
Suppose an approval takes five minutes of human work but waits three days in a queue.
A task-duration report may focus on the five minutes.
A process view exposes the three days.
This makes process mining useful for flow questions:
- Where do cases wait?
- Which handoff creates the longest delay?
- Do urgent cases actually move faster?
- Which rework loop consumes the most elapsed time?
- Which team receives work in bursts it cannot absorb?
- Where does a supposedly automated process still return to manual intervention?
The distinction between processing time and waiting time is often where a major improvement opportunity becomes visible.
9. Rework becomes visible as a loop
Many systems count completed activities but hide repeated activities.
Process mining can expose loops such as:
review → correction → review → correction → review
That can lead to a better question than “why is review slow?”
The real question may be “why do so many cases arrive at review incomplete?”
Process mining does not automatically answer the cause. It tells you where the pattern exists and how strongly it is associated with time, cost or other outcomes.
10. Conformance checking compares reality with an intended model
Sometimes the organisation already has a required process.
Conformance checking compares recorded event sequences with that reference model.
The comparison can reveal:
- steps skipped;
- steps repeated unexpectedly;
- activities performed in a different order;
- cases that bypass mandatory approval;
- actions that appear in the log but not the model;
- modelled actions that rarely occur in reality.
This is useful in compliance, quality, internal control and process redesign.
But a deviation is not automatically misconduct. The reference model may be outdated, the event mapping may be incomplete, or the exception may be legitimate.
Conformance checking identifies a discrepancy. Human and domain reasoning still have to interpret it.
11. Enhancement puts performance back onto the process
Once the structure is visible, the model can be enriched.
Activities and paths can be annotated with:
- frequency;
- elapsed time;
- processing time;
- cost;
- resource or team;
- error rate;
- rework rate;
- customer outcome;
- priority;
- other case attributes.
This is where a process map becomes operational evidence rather than merely a diagram.
12. Process mining is not business intelligence with prettier arrows
Business-intelligence dashboards usually aggregate metrics.
Process mining retains event sequence and case trajectory.
A dashboard might say:
Average completion time: 8.4 days.
A process-mining analysis can ask why some cases finish in two days while another family takes eighteen, which path they followed, where they waited and which loops they entered.
The dashboard answers “how much?”
Process mining often adds “through which path?”
13. It is not the same as process modelling
Process modelling usually starts from an intended or described process.
People interview staff, inspect procedures and draw a model.
Process mining starts from observed event traces and reconstructs a model from behaviour.
The two approaches are strongest together.
The intended model explains what the organisation believes should happen. The mined model shows what the recorded system says did happen. The gap between them is often where learning begins.
14. It is not the same as task mining
Task mining typically observes fine-grained user interactions such as clicks, keystrokes or desktop actions.
Process mining usually operates at a higher process level using business events across cases and systems.
A task-mining view might reveal how a worker enters an invoice.
A process-mining view might reveal how the invoice travels from receipt to payment across teams and applications.
They can complement each other, but they answer different reader jobs.
15. Event logs are evidence, not causes
This boundary is critical.
Suppose cases handled by Team B take longer.
The log establishes an association. It does not prove Team B causes the delay.
Team B may receive harder cases. Cases may be transferred to Team B only after something has already gone wrong. Team B may perform a mandatory check that protects quality. The long duration may reflect upstream failures rather than Team B’s performance.
Process mining helps locate patterns. Causal claims require additional reasoning, design and evidence.
16. Correlation can hide selection
A common mistake is to compare paths as though cases were randomly assigned to them.
If urgent cases are deliberately sent down an expensive fast-track route, the route may correlate with higher cost. That does not mean the fast-track causes cases to be expensive. The cases may already be unusual.
The process map needs domain context.
Where decisions depend on case severity, customer type, risk or other hidden variables, analysts should be cautious about turning process associations into causal recommendations.
17. Missing events can invent a process that never existed
Suppose a manual approval happens by phone but is never logged.
The event data may show:
request → payment
The organisation might conclude that approval is being bypassed.
In reality, the approval occurred outside the recorded system.
This is why event-log completeness matters. A process model is a model of the recorded process. The recorded process and the real process overlap; they are not automatically identical.
18. Duplicate events can create imaginary loops
Integration systems sometimes replay messages. Applications may write several records for one logical action. Users may save a form multiple times.
If those records are interpreted as separate activities, the model can infer rework that never happened.
Cleaning rules therefore need to distinguish:
- a repeated real activity;
- a repeated technical event;
- a state update;
- a correction;
- a duplicate record.
Data semantics are part of process analysis.
19. Concurrency can make simple ordering misleading
Not every process is a neat sequence.
Two checks may happen in parallel. Several teams may work on one case simultaneously. A system may record only completion times, leaving true overlap uncertain.
If analysts force every event into a single strict order, they can manufacture dependencies that do not exist.
Good process models need to represent concurrency where the data support it.
20. Process drift means yesterday’s map may not describe today’s work
Processes change.
- A policy changes.
- A new system is introduced.
- A team reorganises.
- Automation removes a manual step.
- A crisis creates a temporary bypass.
- Customers switch channels.
If the event log spans several years, one model may blend several different operating regimes.
Time-sliced analysis can reveal drift: which paths existed before a change, which appeared afterwards, and whether performance improved or merely moved elsewhere.
21. A worked example: order to cash
Imagine a company believes its standard order-to-cash route is:
order received → credit check → pick → ship → invoice → payment
Process mining reconstructs 100,000 orders and finds:
- 62 percent follow the dominant path;
- 18 percent require one order change;
- 9 percent loop through credit review more than once;
- 7 percent ship before a later administrative correction;
- 4 percent follow many rare variants.
These percentages are illustrative, not real company statistics.
The useful question is what the pattern permits next.
The company can compare lead time, margin, error rate and customer outcome by variant. It may discover that the main delay is not picking or shipping. It is repeated credit-review rework triggered by incomplete master data.
That redirects improvement upstream.
22. Improvement should target the mechanism, not the colourful map
A process-mining tool can make bottlenecks visually obvious.
Visual salience is not causal diagnosis.
A long queue before approval may be caused by:
- insufficient approval capacity;
- work arriving in bursts;
- poor information quality;
- too many cases unnecessarily requiring approval;
- priority rules;
- batching;
- dependencies on another system;
- rework from upstream errors.
The map tells you where to investigate. It does not absolve the investigator from understanding the mechanism.
23. Automation opportunities require a second test
Process mining is often used to identify repetitive work that may be automated.
That can be valuable. But frequency alone is not a sufficient automation criterion.
Before automating a path, ask:
- Is the task stable?
- Are the inputs sufficiently structured?
- What exceptions exist?
- Who owns judgement when the normal rule fails?
- Does automation remove a useful control?
- Will the system still generate evidence needed for monitoring?
- Could automation accelerate a flawed process instead of repairing it?
Automating a bad process can make the bad process faster.
24. Privacy and governance belong inside the analysis
Event logs can contain sensitive information about workers, customers and operational decisions.
A process-mining programme should define:
- which data are necessary;
- who may access case-level detail;
- whether identities can be pseudonymised;
- how long data are retained;
- which uses are legitimate;
- how employee monitoring is governed;
- how findings can be challenged when data quality is disputed.
The ability to reconstruct work creates analytical power. That power needs boundaries.
25. A practical process-mining workflow
- Define the decision or process question.
- Choose the case notion deliberately.
- Identify the systems that record relevant events.
- Define event semantics before extraction.
- Build and clean the event log.
- Check timestamps, duplicates, missing events and joins.
- Discover the dominant process structure.
- Inspect variants rather than relying on one aggregate path.
- Measure waiting, processing time, loops and handoffs.
- Compare observed behaviour with the intended model where appropriate.
- Investigate deviations with domain experts.
- Separate association from causal explanation.
- Test proposed interventions against the mechanism.
- Monitor the process after changes.
- Re-mine the process when systems, rules or behaviour drift.
26. Questions to ask before trusting a process map
- What exactly is one case?
- Which parts of the real process are not logged?
- What does each timestamp actually mean?
- Could duplicate technical events be mistaken for work?
- Are activities mapped consistently across systems?
- Which variants have been filtered out?
- Does the model preserve concurrency?
- Does a deviation reflect non-compliance or an outdated reference model?
- Could case complexity explain apparent performance differences?
- Has the process changed during the analysis period?
- Which conclusions are descriptive, and which are causal?
27. Where this fits in the eduKateSG knowledge map
Process mining sits between information systems, operations, monitoring and improvement. It does not replace those fields.
Useful neighbouring routes include How Flow Efficiency Works, How Monitoring Works, How Interfaces Work and How Institutional Memory Works.
This page owns a narrower world-facing reader job: how event logs can reconstruct the paths real cases take through a process, and how those paths can be used without confusing recorded sequence with complete causal explanation.
28. Authoritative sources and further reading
- ProcessMining.org — Process Mining, foundational material distinguishing process discovery, conformance checking and model enhancement.
- IEEE Xplore — Process Mining research, discussing discovery and analysis of process behaviour from event logs.
- IEEE Xplore — Extended Event Log research, highlighting the central role of event logs and the practical challenges of finding, merging and cleaning process data.
29. The quiet conclusion
Organisations tell stories about how work happens.
The procedure tells one story.
The dashboard tells another.
The event log tells a third.
None is automatically the whole truth.
Process mining becomes useful when it turns the third story into something inspectable: the routes, loops, waits and deviations that ordinary aggregation hides.
Then the real work begins.
Not “what does the map look like?”
But:
What does this recorded path reveal about how the system actually behaves—and what additional evidence do we need before we change it?