Organizations usually define processes through procedures, workflows and process models. These are useful because they describe how work is expected to proceed. Actual operations, however, are rarely as linear as the documented flow.
A loan application may return to an earlier step because of missing documentation. A purchase request may follow different approval paths. An IT incident may move between several support teams. Two cases that look similar at the beginning may end up following very different routes.
Process mining reconstructs these actual flows from the transaction records left behind in operational systems.
What data does it use?
ERP, CRM, Core Banking, BPM, ITSM and similar systems generate digital records as work is performed.
Many process mining analyses begin with three basic data fields:
- Case ID: The transaction, request, application, order or case being followed
- Activity: The process step or event that occurred
- Timestamp: When the activity occurred
In a loan process, for example, the application number may serve as the Case ID. Activities may include “Application Received,” “Sent for Assessment” and “Approved,” with timestamps showing when each event took place.
Once these records are linked correctly, the actual sequence of activities can be reconstructed.
Additional attributes such as team, channel, product, customer segment, amount, priority or system can then be added to explain why certain behaviors occur.
A process model describes how the process is expected to work; process mining shows how it actually runs in operational systems.
What can process mining reveal?
Its value goes beyond automatically drawing a process map. The main benefit is making process behavior measurable.
Actual flows and variants
The same process may follow several different paths.
A process documented as five basic steps may contain dozens of variants in real operations. Not all variants are problems; some may be necessary because of product rules, customer types or legitimate exceptions.
The useful question is which variants occur, how often they occur and how they affect performance.
Waiting times and bottlenecks
End-to-end process time is not the same as active processing time.
A case may remain open for five days while only a few hours are spent actively working on it. The rest may be waiting for approval, information, another team or another system.
Process mining can expose this waiting between activities and support bottleneck analysis.
Rework and returns
Cases may return to previous activities, require another approval, reopen after closure or move repeatedly between teams.
These behaviors can be analyzed as rework, loops, reopen patterns or multi-hop handovers.
Conformance
Actual flows can be compared with a defined process model or business rule.
This makes it possible to examine whether mandatory controls were skipped or whether activities occurred in an unexpected sequence.
How is process mining different from reporting?
Organizations already use dashboards and BI tools to monitor process-related KPIs.
Volumes, average completion time, SLA achievement, error counts and backlog can all be reported effectively.
Process mining does not replace this reporting layer.
Its difference is that it connects the KPI to the behavior of the underlying process.
A dashboard may show that average processing time is three days. Process mining can help investigate:
- where those three days are spent,
- which variants take longer,
- what delayed cases have in common,
- where cases return to previous steps,
- which teams or conditions are associated with higher waiting times.
Reporting tells you what the outcome is; process mining helps explain which process behaviors produced that outcome.
What types of analysis are possible?
Depending on the platform, process mining may support:
- Process Discovery
- Variant Analysis
- Performance Analysis
- Conformance Checking
- Root Cause Analysis
- Simulation / What-if
Combined with task mining, it can also help investigate manual desktop work that does not appear fully in enterprise event logs.
Where can it be used?
Business examples include loan origination, customer onboarding, Procure-to-Pay, invoice processing, customer complaints, back-office operations and HR.
IT examples include incident, problem and change management, service requests, access management, software development, testing, release and deployment.
Where should organizations start?
There is no need to mine every process at once.
A good starting process is usually meaningful to the business, sufficiently high in volume, traceable through systems, linked to a measurable performance or conformance question, and actionable once the analysis is complete.
The useful outcome is not a visually impressive process map. It is a better answer to a specific process question and the ability to measure whether the resulting intervention worked.
← All articles