In short: Process mining reconstructs how work actually flowed from timestamped event logs, and the distance between the documented process and the discovered one is the working material. A nine step purchase to pay process routinely shows thousands of distinct paths in the log, with the most common single variant covering a small minority of cases, and none of that is dishonesty. Conformance checking compares each case against the model and flags deviations, and a deviation is a question rather than a fault, since many of them are the corrections that got the goods delivered. The technique describes the flow of cases through activities and says nothing about whether the decision at each activity was right, so a fully conformant sourcing process can still award to the wrong supplier every time.
The documented purchase to pay process has nine steps. It is on a wall in the procurement function, it was signed off by three directors, and everyone can describe it. Then somebody exports the event log from the ERP for the last eighteen months, and the median case has twenty three events in it. There are four thousand distinct paths through those nine steps. The most common single variant accounts for under a fifth of cases.
Neither version is a lie. The wall chart describes what the process is supposed to be when nothing unusual happens, and the log describes what happened, including every correction, resubmission, escalation and workaround that got the goods delivered and the invoice paid. The distance between them is the working material.
What the technique does
Process mining reconstructs a process model from timestamped records that the systems already produce. The minimum input is three fields per row: a case identifier, an activity name, and a timestamp. A case is whatever the process is about, so a purchase order, a work order, a change request, a supplier qualification. An activity is something that happened to it. Ordering those rows by case and by time gives a trace, and a set of traces is an event log.
Discovery algorithms turn that log into a model. The alpha algorithm of van der Aalst, Weijters and Maruster in 2004 was the first widely used one and it is brittle on real data; the inductive miner of Leemans, Fahland and van der Aalst in 2013 is the more common working choice because it guarantees a sound model and copes with noise. The IEEE Task Force on Process Mining set out the field's principles in its 2011 Process Mining Manifesto, including the four quality dimensions a discovered model is judged on: fitness, precision, generalisation and simplicity. Those four trade off against each other, which is why two tools pointed at the same log produce different pictures and both can be defensible.
The part that matters for an operations audience is that no new data collection is required. Every timestamp already exists because a transaction system wrote it. The work is extraction, defining the case identifier correctly, and agreeing what counts as an activity.
That second item is where most projects stumble. In a purchase to pay analysis, is the case the purchase requisition, the purchase order, the order line, or the invoice? They have different granularity and different one-to-many relationships, and picking the wrong one produces a model that is technically correct and answers nobody's question. A single requisition that becomes three orders against two suppliers with five deliveries and four invoices is one business event and fourteen cases, depending on how you cut it.
Where it earns its keep in an industrial setting
Two processes carry most of the value in a large operator, and both share a property: high volume, multiple functions touching the same case, and a cycle time that everyone complains about without agreeing on where it goes.
Purchase to pay is the first. It spans requisition, approval, sourcing, order, receipt, invoice, three way match and payment, and it touches operations, procurement, warehouse and finance. The volume is high enough that the log is statistically meaningful within a month of data. The failure modes are expensive in ways that are visible on the balance sheet: early payments that give away working capital, late payments that trigger interest or damage supplier terms, blocked invoices that consume clerical effort, and off-contract buying that pays list price for something a framework agreement already covers.
Work order to completion is the second. Notification, planning, scheduling, permit, execution, technical confirmation, close. In a plant maintenance system this log is rich and almost nobody mines it. The cycle time from notification to completion is the number that determines backlog, and backlog is what determines whether the integrity programme runs to plan (N11). The interesting intervals are the ones between notification and planning, and between a job being ready and being scheduled, which together usually dwarf the execution time.
The approval chains inside both are where the analysis usually starts paying. Approvals are cheap to add to a workflow and nobody ever removes one, so a purchase order for a routine consumable inherits a chain designed for a capital item, and the chain shows up in the log as a sequence of steps each adding hours or days of waiting.
The findings that keep recurring
Rework loops. A case returns to an activity it already visited. In purchase to pay this looks like repeated changes to a purchase order after release, and each change frequently resets an approval and invalidates a receipt. Counting the loops and attributing them to a cause, whether it is a requester who specifies incompletely, a supplier who confirms different terms, or a price that was never in the contract, converts a diffuse complaint into a countable defect rate. Rework is also the cleanest business case in the whole exercise, because the cost of a loop is the fully loaded time of everyone it touches multiplied by a frequency you can now measure.
Approval steps that never reject. An approval activity appears in ninety thousand cases and produced a rejection in forty of them. That step is a delay with a signature attached, and its rejection rate is the argument for removing it or raising its threshold. Care is needed before concluding it is worthless, since some approvals deter bad requests that are never submitted, and a control may exist for audit reasons rather than for decision quality. The analysis gives you the number, and the judgement about whether the control is doing preventive work stays with the people who own it.
Waiting that nobody owns. The long durations in an industrial process sit between activities rather than inside them. An invoice arrives and sits for eleven days before anyone opens it. A work order is technically complete and sits for three weeks before the confirmation is entered. These gaps have no owner because no function's metrics cover the space between two functions, and they are usually the largest single component of end to end cycle time.
Sequence violations that are actually better. Occasionally the log shows a path that departs from the documented process and finishes faster with no adverse outcome. People invented a shortcut that works. The default institutional response is to stamp it out. The better response is to look at whether the documented process should change.
Conformance checking, and what a deviation means
Discovery asks what the process looks like. Conformance checking asks how far reality departs from a model you already have, which is the relevant question once a documented process exists.
The technique that made this practical is alignment based conformance, developed by Adriansyah, van Dongen and van der Aalst around 2011. It takes each real trace and finds the cheapest way to line it up against the model, recording where the log had to skip a model step and where it did something the model does not allow. The output per case is a list of specific deviations rather than a single conformance score, which is what makes it actionable.
The interpretation requires care, because deviations come in at least three kinds and they need different responses. Some are genuine control failures, such as a goods receipt posted after the invoice was paid. Some are the model being wrong, where the documented process omits a step that the operation cannot function without. And some are data artefacts, where an activity happened but was recorded late or by a batch job, so the trace looks non-conformant while the work was done in order.
Treating all three as violations is how a process mining programme turns into a compliance exercise and loses the operations audience within two quarters. Sorting them is a manual pass over a sample, and it is worth doing once properly at the start, because the classification usually holds for the rest of the analysis.
Turning a finding into a change
The failure mode of this discipline is a beautiful process map that gets presented once and changes nothing. Three things separate the analyses that land.
The first is attaching a cost to each finding in the units the process owner is measured in. A rework loop occurring nine thousand times a year at an average of two hours of handling is a headcount number. Eleven days of average invoice sitting time on a given payment term is a working capital number. A three week lag before technical confirmation is a backlog and a deferred cost recognition number. Findings expressed in variant counts and fitness scores do not survive contact with an operations review.
The second is naming the control point that changes. Almost every recurring finding traces back to something specific and changeable: a threshold in a workflow rule, a field that is optional and should be mandatory, an assignment rule that sends work to a queue with no owner, a material master record with no contract linked. The deliverable is that list, with an owner and a system against each item, rather than the map.
The third is a measurement plan that runs on the same log afterwards. The analysis that produced the finding can be rerun monthly at near zero marginal cost, which means the improvement is verifiable in the same terms it was proposed in. Process mining is unusual among improvement methods in that the baseline and the verification come from the identical query, so the argument about whether the change worked can be settled with data rather than opinion.
Where this stops
The analysis sees activity that produced a timestamp in a system. Everything else is invisible.
That exclusion is large in an industrial operation. The engineer who calls a supplier to chase a delivery, the corridor conversation that resolves a specification question, the email thread where three people agree an approach before anyone touches the system, the WhatsApp message that unblocks a permit. None of that appears in the log, and some of it is the actual mechanism by which work gets done. A process that looks like it has an eleven day gap may have had ten days of active chasing inside it, and the map will show a wait.
The related problem is that logged duration and actual duration are different quantities. Systems get updated when someone has time, in batches, at the end of a shift, or by a nightly job that stamps two hundred records with the same timestamp at 02:00. An activity showing zero elapsed time is usually a data entry convention. An activity showing four days may be one hour of work and three days of the record sitting unposted. Any duration analysis needs a pass to identify batch stamping before its numbers mean anything, and the usual tell is a suspicious concentration of timestamps at particular minutes of the day.
There is also a scope limit worth stating plainly. Process mining describes the flow of cases through activities. It says nothing about whether the decision made at each activity was correct. A sourcing process can be perfectly conformant, fast and loop free while consistently awarding to the wrong supplier, and no amount of log analysis surfaces that, because the log records that an award happened rather than whether it was a good one.
Export six months of purchase to pay events with case, activity and timestamp, and before running any tool, count the distinct variants and plot the ten longest average waits between consecutive activities. That takes an afternoon in a spreadsheet and it tells you whether there is enough there to justify anything more.