Process Mining — Reconstructing Work from Event Data

Process mining uses event records to examine how a business process has run. It can show sequences, waiting periods, repeated steps and variations that are difficult to see from a process diagram alone.

Its evidence is limited by the records available. Work performed outside the system, missing events and inconsistent identifiers can change what the resulting model shows.

What an event log needs

A basic case-based analysis usually needs a case identifier, an activity and a timestamp. Depending on the question, additional information may include the responsible team, product, value or outcome.

For an invoice process, the case might be an invoice and the events might include receipt, validation, approval and payment. A consistent definition of each event matters: a timestamp for entering a record is not necessarily the time when the underlying work occurred.

More complex processes can involve several related objects rather than a single case. The modelling approach should reflect the question rather than force unrelated events into one sequence.

An illustrative example

A company’s documented approval process may show a simple path, while its event data reveals repeated returns for missing information. Analysis could identify which cases loop, where waiting occurs and whether particular inputs are associated with more rework.

This is a hypothetical example, not a claim about measured client results. Staff input is needed to understand why a pattern occurs and whether changing it would help.

Three types of analysis

Discovery

Build a view of recorded process paths without assuming that the documented flow describes every case. Review the common paths and important exceptions rather than treating every rare variant as a problem.

Conformance checking

Compare recorded behaviour with a reference model or defined rules. A deviation can indicate an issue, an authorised exception or a mismatch in how the data is interpreted. It requires investigation before a conclusion is drawn.

Performance analysis

Examine duration, waiting, rework and other measures across cases. Use distributions and relevant segments rather than averages alone. A long elapsed time may include an intentional wait and should not automatically be counted as wasted effort.

Data quality before conclusions

Check for missing events, duplicated cases, time-zone differences and inconsistent identifiers. Understand which activities are not recorded. A visually detailed process map can still be misleading when its source data is incomplete.

Access to logs also needs to be appropriate for the purpose. Personal information, staff activity and commercially sensitive records may require restrictions and retention rules.

Combine data with operational knowledge

Interviews and observation help explain what the records mean. Process mining can extend that view across a larger dataset, but it does not replace the people who understand exceptions and informal work.

Where suitable logs do not exist, another diagnostic method may be more useful. Creating a reliable event record can itself be a necessary project before automated analysis is possible.

From a finding to an improvement

A finding should lead to a testable hypothesis. For example, adding an input check might reduce cases returned for missing information. Define the proposed change, the expected effect and the measures needed to evaluate it.

Compare the result with a suitable baseline and consider other changes that may have influenced it. Potentially shorter elapsed time is not automatically a cash saving. Activity-Based Costing can help examine the work involved, while NPV and IRR support an investment assessment.

Where it fits in Q-Journey

AiP is the audit component of Q-Journey, with Express and Platinum variants. Platinum includes Lean and Muda consulting. The diagnostic methods and deliverables are agreed for the individual situation; process mining is an option when the data and question support it.

Application development following the audit belongs to Q-Journey’s second stage, including applications without AI. A clearly defined software requirement can also be discussed through Q-Dev.

Start with the process you want to understand, the records available and the decision the analysis should support.