Process Mining: Seeing How Work Actually Runs, Without Waiting on Event Logs

Key Takeaways

‍

• Process mining compares event logs against the process as it was designed, so the picture comes from system records rather than from anyone's account of how the work happens.
• It needs systems that emit timestamped events with a clear case identifier, plus the integration work to combine those events into one dataset and keep it current as the systems change.
• It sees nothing wherever work happens outside those systems. Spreadsheets, email and manual handoffs between applications generate no event for a log to capture.
• Where the logs are thin, the gap they leave is often where the real delay sits, which is worth knowing before you decide where to start.

‍

‍

Process mining reconstructs how a process actually ran, based on the records that source systems keep. It takes the documented version of a process, the one drawn in a diagram or written into a policy, and compares it against what the event logs show really happened: which steps ran in what order, where the process branched, and how long each stage took.

‍

That comparison is only as good as the logs behind it. Systems that generate timestamped events with a clear case identifier produce a usable record. Work that happens outside those systems doesn't. A process can look fast in the logs and slow in reality, because the waiting happens where nothing is being recorded.

‍

What Is Process Mining?

‍

Process mining is a technique that reconstructs how a business process actually ran by analyzing the event logs that source systems generate as work moves through them. It draws directly from timestamped system records to show the sequence of steps a process took, where it branched, and how long each stage lasted.

‍

Business process mining is the same technique under another name, used when the emphasis falls on applying the method to a specific business function rather than on describing the method itself.

‍

It works by extracting event data already being generated inside systems like ERPs, CRMs or case management platforms, then reconstructing the path a process took across all of them. Comparing that reconstruction against the process as designed is where variants, bottlenecks and deviations become visible. A process built as five sequential steps might, in practice, show a dozen variants, some far more common than the official path. The method has a formal body of practice behind it: the IEEE Task Force on Process Mining publishes the field's manifesto, which sets out its guiding principles and open challenges.

‍

The value is that none of this depends on anyone's account of how a process runs. It depends on what the systems recorded while the work was happening, which is usually more reliable than a process map drawn once and never revisited.

‍

How Process Mining Works

‍

The core process mining techniques run in five steps, each building on the one before it, turning raw system activity into a usable comparison between the intended process and the real one.

‍

1. Collect event logs from source systems

‍

Start by pulling timestamped event data from the systems a process runs through, such as an ERP, CRM or case management platform. Each event includes what happened, when it happened, and a case identifier linking it to a specific instance of the process, like a single order or a single claim. Without a reliable case identifier, events can't be grouped into a coherent sequence, which is why this step depends on systems that generate clean, structured records.

‍

2. Reconstruct the process graph from those events

‍

The collected events form a process graph: a map showing every path the process actually took, built entirely from what the logs recorded. Unlike a diagram drawn by hand, the graph shows every variation the process took in practice. Some of those variations are rare edge cases. Others turn out to be more common than the process that was originally designed.

‍

3. Compare the reconstructed process against the designed process

‍

Next, set the graph against the process as it was designed or documented. The comparison shows where the two align and where they diverge, surfacing every point where real execution departed from the intended sequence. The gap between the two versions is usually the most useful part of the exercise.

‍

4. Analyze variants and bottlenecks

‍

Each divergence becomes a variant: a different path the process took, along with how often it occurred and how long it took relative to the designed path. This step identifies which variants are common enough to matter, and where in the process work is taking longer than the design accounted for. Some variants turn out to be reasonable adaptations. Others are where the process breaks down.

‍

5. Act on what the comparison shows

‍

The comparison produces specific, addressable findings: a step that consistently causes delay, a variant that should become the new standard path, or a bottleneck that only appears under certain conditions. Some findings warrant a process redesign. Others just need the standard path updated to match what already works.

‍

What Process Mining Needs Before It Can Start

‍

Three conditions have to be true before process mining can produce a usable result. They are the infrastructure the technique runs on.

‍

The first is systems that emit timestamped events with a clear case identifier. Every step of a process needs to generate a record, at the moment it happens, tied to the specific case, order or claim it belongs to. The standard formulation is blunt about it: every event has to refer to a case, an activity and a point in time. A system that logs actions without timestamps, or without a way to connect those actions to a single case, can't supply the kind of record process mining needs to reconstruct a sequence.

‍

The second is the extraction and integration work to bring those events into one place. Most processes run across more than one system, and each system stores its event data differently. XES, the IEEE standard for event streams, exists because that data has to move between tools that all format it their own way. Getting a usable dataset means extracting events from every system a process touches, standardizing the format each one uses, and joining them into a single timeline organized around the same case identifier. This is data engineering work, and it takes real time to do correctly.

‍

The third is ongoing maintenance. Source systems change: a field is renamed, an integration is updated, a new system enters part of the process. Each of those changes can break the connection feeding event data into the process mining pipeline. Someone has to own that connection continuously, or the pipeline gradually stops reflecting what is happening.

‍

Together the three add up to a real project. Organizations with clean, well-integrated system data are in a strong position to start. The rest have to build that foundation first, before process mining can produce results they can rely on.

‍

Where the Logs Go Quiet

‍

All of that describes what happens inside systems that generate events. Much of a process happens in the space between them, and that space produces no event at all.

‍

Take a handoff sitting in an inbox. Someone emails an approval request to a manager, and nothing moves until that person opens it, reviews it and replies. The system that eventually records the approval has no record of how long the request sat there first. It sees the moment the decision was logged, not the delay that preceded it.

‍

Or a spreadsheet passed around for review. Someone exports data to build a report, several people edit and comment on a shared file, and the final version is re-entered into a system once everyone signs off. None of that editing, commenting or waiting appears anywhere in an event log. The system sees the final entry, as if it happened in a single instant.

‍

Rekeying between two applications works the same way. An employee looks up information in one system and manually types it into another, because the two don't connect. The time spent switching between applications, finding the right data and typing it in generates no timestamped event in either system. A new record simply appears, with nothing behind it.

‍

This is where the log-based picture starts to mislead. Two events might sit twelve hours apart in a log, which counts as a case moving quickly by that measure, while ten of those hours went to waiting in an inbox, being reformatted in a spreadsheet, or getting rekeyed by hand.

‍

Process mining can tell you a gap exists between two logged events. What happened inside that gap never generated the kind of record the technique depends on, so it stays invisible.

‍

Process Mining, Process Discovery and Process Intelligence

‍

The three terms get used close enough together to be treated as interchangeable, though each covers different ground.

‍

Process mining is the technique already covered in this article: reconstructing how a process ran from event logs, then comparing that reconstruction against the process as designed. It answers a specific question. Given the events a system recorded, what actually happened?

‍

Process discovery is one part of process mining, the step of building that first process graph from raw event data before any comparison or analysis. It is the map itself, before anyone has started asking what it means.

‍

Process intelligence is broader than either. It combines the system-level view process mining produces with data captured at the desktop level: the applications, transitions and manual steps that never generate a system event in the first place. That combination covers the gap described above, the space between systems where process mining alone has nothing to show. Process intelligence explained covers this in more depth.

‍

Process mining tools and software platforms vary in scope, setup and the kind of systems they connect to. The technique is occasionally called "process tracking." How process mining, task mining and process intelligence compare sets these three approaches against task mining, a closely related technique.

‍

What Process Mining Is Used For

‍

Process mining use cases vary by function, but the question is the same one every time: does the process work the way it's supposed to?

‍

Operations teams use it to catch inefficiencies that accumulate as a business scales or its processes shift. A workflow that worked well at one volume or team size can develop bottlenecks at a larger one, and process mining shows where that happens instead of leaving it to intuition.

‍

In finance and shared services, the subject is how transactions move through approval chains, matching and reconciliation. A process designed around three approval steps might route through five in practice, and the analysis shows which transactions take the long path and why.

‍

Claims teams trace how a file moves from intake to settlement, where it stalls between adjusters, systems or review stages, and whether a slow claim is an outlier or part of a pattern.

‍

In customer service, the question is where an order, a support inquiry or a sales transaction stalls across handoffs between teams or systems. One redundant verification step or an unnecessary manual review can be the difference between a fast resolution and a frustrating one, even when no individual team believes it is working slowly.

‍

Compliance and audit teams use it to find where execution diverges from required policy, such as an approval step skipped under time pressure, and to find it before an external audit does.

‍

Change programs use it to establish a factual baseline before a change takes effect, then to verify afterward whether the new process took hold. Without that before-and-after comparison, it is hard to tell whether a program produced a real shift in behavior or only a new diagram nobody follows.

‍

Visualizing a process map, step by step shows how one actually gets built and read.

‍

Starting Without an Event Log

‍

Everything described so far depends on event logs: systems that generate a timestamped record every time a step happens. Not every organization has that in place, and building it is a significant undertaking on its own.

‍

There is another starting point. Instead of extracting events from system logs, you can capture process data at the desktop level, directly from the applications people work in as they do the work. That reaches a first process map without an integration project, and it picks up the between-systems work event logs typically miss: the spreadsheet passed around for approval, the manual step between two applications, the work that happens before anything reaches a system of record.

‍

Workflow Optimization, the Insightful product, maps a process end to end from desktop-level activity, showing stage duration, movement between steps and repeat work, with no event log extraction project in front of it.

‍

It is a starting point rather than a substitute for what enterprise process mining platforms do at scale. Organizations with clean, well-integrated event logs already have a strong foundation for log-based process mining. Workflow Optimization is for the other situation: getting a usable process map when that log infrastructure isn't in place yet, without waiting for a data engineering project to finish first.

‍

Start with a Measured Baseline

‍

A process can look fast in the logs and slow in reality, because the waiting happens where nothing is being recorded. Log-based process mining shows how work moves through the systems that generate events, and it stops where those events stop, which is often where the real delay is hiding.

‍

Getting a first, usable process map doesn't have to wait until every system emits a clean event log. Capturing what happens at the desktop level is another way to start, one that reaches a baseline sooner and picks up the work logs miss entirely.

‍

Workflow Optimization is currently in beta. Request beta access to see how your processes actually run.

‍

FAQs

‍

What is process mining?

Process mining is a technique that reconstructs how a business process actually ran by analyzing the event logs that source systems generate. It compares that reconstruction against the process as it was designed, showing where the two align and where they diverge, based on real system records rather than assumptions about how work happens.

‍

How does process mining work?

Process mining works in three stages. First, you collect event logs from the systems a process runs through. Second, discovery reconstructs the actual process graph from those events. Third, analysis compares that graph against the intended process, surfacing variants, bottlenecks and points where execution diverged from design.

‍

What data does process mining need?

Process mining needs timestamped events, each linked to a case identifier connecting it to a specific instance of the process. Without both, events can't be reliably sequenced or grouped. If a system doesn't generate one or the other, process mining can't reconstruct that part of the process, and the analysis will have a gap exactly where that data is missing.

‍

What is the difference between process mining and process discovery?

Process discovery is one part of process mining: the step of reconstructing a process graph from raw event data, before any comparison or analysis happens. Process mining is the broader technique, which includes discovery along with comparing that reconstruction against the designed process and analyzing the resulting variants and bottlenecks.

‍

Why is process mining important?

Process mining matters because it replaces assumptions about how work happens with evidence. It gives you:

‍

• The path a process actually takes, alongside the intended one
• Bottlenecks and delays that outcome data alone doesn't show
• Variants, including ones more common than the official process
• A factual record, for compliance and audit teams, of how execution matched policy
• A baseline that later changes can be measured against

‍

How many data points are required for process mining?

Three fields, and about 1,000 cases. Every event in the log needs a case ID, an activity name and a timestamp. Without all three you cannot group events into a single process instance or put them in order. Volume depends on how complex the process is and how many variants it produces. Use 1,000 completed cases as a starting point for a moderately complex process, because a path taken by 1% of cases appears only ten times at that scale. A simple linear process can give you useful findings from a few hundred cases. One with hundreds of distinct paths needs several thousand before its rare variants are worth trusting.

‍