A process map says every purchase request is approved before an order is issued. The system history shows a more complicated pattern: some requests return for clarification, some approvals are recorded after the order, and some cases disappear from the reporting window before they finish.
Process mining can make those patterns visible by analyzing recorded events. Its value lies in connecting operational questions to evidence about actual execution. Its danger lies in treating the resulting map as an objective picture of everything the business did.
Event data is a partial record created by systems for particular purposes. It can omit work, misrepresent timing, and combine different business cases. Leaders should use process mining as a disciplined investigation: define a question, establish what the log represents, test the interpretation with operators, and then evaluate a change. A striking visualization is the beginning of that work.
Choose a question that could change a decision
“Show us our process” is an expensive starting point. A better question is whether late supplier setup delays purchasing, whether invoice disputes repeatedly return to the same team, or whether a particular work type takes a different route than policy expects.
Define the decision that depends on the answer. A finding may justify changing a rule, adding capacity, improving capture, or leaving a justified variant alone. Without that decision, the analysis can accumulate interesting patterns without influencing operations.
The Process Mining Manifesto distinguishes discovery, conformance checking, and enhancement of process models using event data. These are related but different uses: learning observed behavior, comparing it with an expected model, and enriching an existing understanding. Choose the relevant question before choosing the view. IEEE Task Force on Process Mining, Process Mining Manifesto.
For an initial project, select a bounded process with identifiable cases, useful event history, and an owner able to investigate the results. Starting with the entire enterprise can obscure the assumptions that need the most careful checking.
Define the case before extracting events
The case is the unit whose journey is being reconstructed. It might be a service request, invoice, order line, or maintenance work order. Choosing the wrong unit can create a misleading sequence even when the underlying records are accurate.
A purchase order can contain several lines delivered at different times. If the case is the whole order, a receipt for one line may appear to precede approval of another. That does not necessarily mean the process violated policy. It may mean the analysis has collapsed distinct objects into one sequence.
Write the case definition and its boundaries explicitly. Explain how split, merged, cancelled, and reopened cases are represented. Preserve relationships to relevant objects rather than forcing every business fact into a single identifier.
Avoid using a customer account as the case merely because it is easy to join. One customer can have many overlapping processes. Combining them can make unrelated events look like rework or repeated approval.
Build an event-data contract
For each event, establish the case reference, activity meaning, timing, source, and relevant attributes. Determine whether the timestamp represents the start, completion, recording, or effective time of the activity.
A status-change log may show when an employee updated the system, not when the work happened. A nightly interface may stamp many events at the same time. A historical migration may create records with a shared creation date unrelated to operational sequence.
Document extraction and transformation rules. Keep counts of source records, included events, excluded events, and unmatched identifiers. Preserve enough lineage to trace a surprising case back to the original record.
NIST’s log-management guidance addresses generating, transmitting, storing, analyzing, and managing computer-security logs. Its context differs from process mining, but it reinforces that log evidence requires deliberate management rather than being a ready-made account of business reality. NIST SP 800-92.
The event-data contract proposed here is a working project artifact, not a standard. Its purpose is to make the analysis reproducible and its limits understandable.
A packaging manufacturer investigates late purchase orders
Consider a hypothetical packaging manufacturer whose purchase-order report suggests frequent approval after ordering. Management suspects widespread bypassing of policy and considers adding a hard system block.
The process-mining team defines a purchase-order line as the initial case and extracts request, approval, order, change, receipt, and cancellation events. It retains order-level relationships because some approvals cover the whole order and some changes affect only one line.
A sample review reveals three distinct patterns. Some orders genuinely precede required approval. Some approvals occurred on time but were entered later during a system outage. Some apparent reversals result from an amendment being treated as if it were the original approval.
The team separates these patterns before estimating their frequency. It records which conclusions are supported by system evidence and which require external confirmation. Cases with missing history remain an explicit unknown category rather than being treated as compliant or noncompliant by default.
A further review finds that genuine bypasses cluster around urgent replacement materials when the normal approver is absent. The appropriate response may involve delegated authority and clearer urgent-purchase rules, as well as system controls. Automatically blocking every apparent exception would also disrupt cases whose records were merely late.
The pilot therefore tests a revised urgent-purchase route and improved event capture. It evaluates actual authorization timing, retrospective entry, unresolved cases, and purchasing delays. The hypothetical example demonstrates why process mining should inform diagnosis before enforcement; it reports no invented compliance improvement.
Distinguish elapsed time from work time
An interval between recorded events is not necessarily the time spent performing the activity. It may contain waiting, customer delay, a weekend, or work that the system does not record.
Use start and completion events where available and meaningful. If only completion events exist, describe the interval accurately as elapsed time between observations. Avoid labeling it “processing time” without evidence.
Choose calendar or business time according to the question. A customer experiences a weekend delay even if the internal service commitment excludes weekends. Both measures can be useful when their meaning is clear.
Examine distributions and segments rather than only averages. A small group of difficult cases can have long delays while routine work moves smoothly. Conversely, filtering out rare variants can remove the cases with the greatest operational consequence.
Handle incomplete observation windows
A dataset containing only cases completed during the month can exclude the slowest cases still open at month end. That can make the process appear faster than the current backlog suggests.
Define whether the analysis follows cases started in a period, completed in a period, or active during a period. These populations answer different questions. Show open cases and their age separately when their final duration is not yet known.
Check the beginning of the window as well. A case first observed in the extract may have started earlier. If its earlier events are missing, the discovered path can appear to begin halfway through the process.
Be careful when comparing before and after a change. Differences in season, product mix, case complexity, or completion criteria can change observed performance. A process-mining view can reveal associations; it does not automatically establish that the intervention caused the change.
Validate unusual paths with people who know the work
A rare path may be an error, a legitimate exception, or a logging artifact. Review a sample of underlying cases with the people responsible for the activities.
Ask what the sequence means operationally and what evidence would distinguish competing explanations. Do not ask employees merely to confirm the visualization. Encourage them to identify missing work and misleading labels.
Protect the purpose of the investigation. Employee identifiers may be useful for understanding workload or routing, but individual rankings can be misleading when case difficulty, access, and assignment rules differ. Use appropriate privacy controls and avoid treating process analysis as a shortcut to unsupported personnel judgments.
The most useful output is often a set of verified process variants with explanations, not a single simplified map. Preserve the distinction between expected variation, avoidable rework, and uncertainty caused by missing data.
Turn findings into a bounded intervention
Choose a change linked to a verified mechanism. If requests return because a required identifier is missing, improve capture and feedback. If cases wait for an absent decision maker, repair delegation. If the apparent delay is a batch timestamp artifact, improve measurement before changing operations.
Name the owner and define what will be measured after the intervention. Include potential harm: a new validation rule may reduce incomplete requests while blocking legitimate urgent work.
Retain the original definitions and extraction rules, or document changes clearly. Otherwise, a reported improvement may result from a new measurement method rather than better execution.
Plan for recurrence. Process behavior changes with new products, policies, systems, and staffing. Reuse the validated analysis when it supports a continuing decision, but avoid maintaining a complex dashboard without an operational owner or current purpose.
What buyers should test before purchasing a platform
Ask suppliers to demonstrate the journey from source data to an interpretable finding using representative cases. Request explanations of case construction, timestamp semantics, incomplete cases, filtering, and model assumptions.
Inspect the effort required to maintain connectors and business definitions. A prebuilt connector may accelerate extraction while still requiring substantial work to establish what the events mean in this organization.
Require a way to trace a chart back to a case and a case back to source evidence. Test whether a business owner can distinguish a genuine exception from a data-quality issue without relying entirely on the vendor’s analyst.
Process mining is most valuable when it makes the organization more careful about evidence. It can reveal work that conventional maps overlook, but the resulting insight depends on disciplined case definitions, trustworthy event interpretation, and operational validation. The business should buy that capability, not simply the appearance of a process made visible.
