Process mining reconstructs the path of cases from time-stamped records in business systems. Routine reports count activities but rarely reveal the actual sequence, repeated loops or waiting between them. Marketways interprets these digital traces with people who understand the operation and tests which variants drive delay, cost or failure. The client receives evidence for redesign based on how work happened at scale.
The decision this method supports
We use Process Mining to help clients answer: How does the observed process differ from the intended process?
How the method works
Process mining reconstructs actual process paths from time-stamped system events. The method can reveal variants, loops, waiting and departures from the intended process. Event logs show what the system recorded, so interpretation still requires knowledge of work performed outside the system.
A business example
A claims process may have a documented five-step route. Process mining could show that difficult claims follow dozens of variants and repeatedly return for missing evidence. Interviews can then explain why those variants occur.
How the client uses the result
Process mining gives leaders evidence of how work actually moves through recorded systems. It can reveal repeated loops, unplanned variants and delays that are difficult to see in workshops or standard operating procedures.
What we deliver
We produce a current-state map, evidence about losses, a future workflow, architecture choices or control requirements. The result make ownership, handoffs, exceptions and implementation dependencies explicit.
Limits and complementary methods
System logs reveal recorded activity but may omit conversations, manual work and reasons for variation. Process knowledge remains necessary.
Selected methods and techniques
We select from these established methods according to the decision, evidence and operating conditions.
- Conformance checking: Compare observed process execution with a defined reference process, rule set or control requirement. Translate logs into consistent cases, activities and timestamps, align observed events with allowed behaviour, and identify missing, extra, reordered or mistimed steps and role or data violations. Check whether apparent deviations arise from incomplete logs, an outdated reference or a genuinely different process. Conformance checking asks whether execution matches a reference; process discovery reconstructs what occurs, and variant analysis compares the observed paths with one another. A deviation is not automatically misconduct or control failure.
- Intermittent-demand methods such as Croston variants: Forecast demand for items or services with many zero-demand periods and irregular non-zero amounts by treating the timing of demand and its size separately or through another method designed for sparse occurrence. Define the item population, time interval, forecast horizon, treatment of stockouts and obsolescence and the loss or service measure used to judge performance. Compare Croston-style variants and other suitable intermittent-demand methods with simple zero, mean and aggregate benchmarks using later forecast periods. The method estimates demand rates or distributions under sparse history; it does not mean that every zero is true absence of demand or that a slow-moving item will continue to be required.
- Process mining: Construct and analyse event data to discover process paths, check them against a reference or examine timing and performance. Define what constitutes a case, activity and event; join records across systems; assess missing, duplicated and out-of-order events; and preserve the link from every pattern to source records. Process mining operates across cases and process steps, while task mining examines detailed user interactions within applications. The Process Mining framework record describes the wider discipline and quality principles; this method is the performed analysis. Its findings cover only the execution visible in the event data.
- Process variant analysis: Define a process case and group observed cases by materially different sequences, decisions, loops, roles or exception paths. Compare each variant's frequency, cycle time, rework, resource use, quality or outcome, while accounting for incomplete logs and differences in case mix. Combine trivial technical differences only under an explicit rule and retain rare variants when their consequence is material. Variant analysis compares observed paths with one another; conformance checking instead compares execution with a reference. A slower variant is associated with delay but is not necessarily its cause.
- Task mining: Collect and analyse task-level interaction data, such as application events, screen transitions or user-entered activity labels, to understand how people complete work within and across applications. Define the task and user population, capture period, privacy and access controls, excluded sensitive fields and rules for converting interactions into steps, then validate the reconstructed patterns with participants. Task mining examines detailed user actions; process mining follows cases across wider process events. Recorded clicks reveal visible interaction, not employee intent, hidden work, task value or automatic suitability for surveillance or automation.
- Agentic-AI workflow decomposition: Break a proposed AI-enabled workflow into bounded tasks, inputs, outputs, decisions, tool actions, stored state, human handoffs and exception paths. For each element, identify whether it follows a fixed rule or requires model judgement, what authority is needed, what could fail, what evidence must be logged and when the workflow must stop, ask for help or fall back to a manual route. The method designs and screens the work allocation before or during redesign. It does not establish that a particular agent is accurate, secure or safe for deployment; those claims require system-specific AI and model-risk testing.
- Automation feasibility analysis: Assess whether a defined task or task group can be automated with acceptable reliability, cost and control. Examine input quality, rule stability, frequency, variability, integration needs, exception rates, required judgement, error consequences, human authority, fallback, implementation effort and expected economic benefit. Compare full automation with partial assistance and leaving the work unchanged. The method screens whether automation is worth developing and under what conditions. It does not validate a built system, prove realised savings or imply that every activity in a role should be automated.
- Bottleneck / constraint analysis: Identify the resource, rule, dependency or demand condition that limits the throughput or service objective of a defined process. Specify the unit of flow and operating range, measure capacity, utilisation, queues, blocking and starvation, then test whether relieving the suspected limit increases total output or merely moves the restriction elsewhere. A busy stage or long local wait is not necessarily the binding constraint. The method establishes which limit governs system performance under stated conditions; a Bottleneck Map records locations and evidence, while a Constraint / Bottleneck Profile records tested capacity and slack.
- Bottleneck / throughput analysis: Analyse an end-to-end operating system to identify the resource, rule or dependency that currently limits the rate of completed good work. Define the flow unit, process boundary, period, demand condition, work in progress, stage capacities and observed throughput; distinguish local queues or high utilisation from a binding system constraint; and test whether relieving a candidate restriction would increase total throughput. The constraint may move when demand, product mix or capacity changes. The method identifies and tests limiting conditions; it does not assume that the busiest stage or longest queue is the bottleneck.
- BPMN process mapping: Apply Business Process Model and Notation to represent a defined process using valid activities, events, gateways, sequence flows, message flows and participant lanes. Establish the process boundary and whether the evidence describes current practice or a proposed design, collect steps and exceptions from suitable sources, construct the diagram and review it with process participants and available records. BPMN 2.0.2 supplies the notation rules, BPMN process mapping is the activity of applying them, and a BPMN Process Model is the populated output. A syntactically valid diagram is not evidence that the process is complete or operates as drawn.
- Cycle-time analysis: Measure how long cases take from a defined start event to a defined end event and separate active processing, waiting, transport, rework and other material intervals where the data permit. State the unit of analysis, time basis, treatment of weekends, missing timestamps and unfinished cases, and report the distribution and relevant groups rather than only an average. Cycle-time analysis describes when time is spent and where delay appears. Queueing or bottleneck analysis is needed to explain how demand and capacity create the delay, and a time difference alone does not prove its cause.
- Discrete-event simulation: Build and run a model in which individual cases move through events, activities, queues and resources over time. Define arrivals, routing, service-time distributions, resource schedules, priorities, dependencies and exception rules, initialise the model, verify its logic and compare its baseline behaviour with observed data. Run each scenario enough times to show variation, warm-up effects and uncertainty rather than relying on one simulated path. Discrete-event simulation is the performed modelling method; Process Simulation is the populated analytical output, and a Process Simulation / Capacity Model is the documented client package.
Parent method family
Process, Workflow & Systems explains how this method connects to adjacent methods and relevant services.
Related service families
These service families contain business questions supported by this method. Service pages link to the wider method family so readers can understand the complete analytical approach.