Case-flow investigation
Reconstruct the recorded sequence of activities for selected cases. Compare common routes and unusual variants, then investigate whether differences reflect legitimate exceptions, workarounds or data-quality problems.
Data & decision intelligence
Process mining
Use event data to understand how work actually flows and where it can improve.
Built around a specific business need.
The process described in a workshop is not always the process that appears in operational records. Cases may wait between systems, return to an earlier step or follow different routes depending on the team involved. Those variations can be difficult to see when reporting focuses only on the final completion date.
Process mining uses suitable event records to investigate how work actually moves through a defined process. We connect that analysis with operational knowledge, because a system event is evidence of a recorded interaction, not a complete account of every activity, delay or decision that occurred.
Who this is for
- Operations teams investigating delays, rework or inconsistent case journeys.
- Transformation teams prioritising process changes using recorded evidence.
- Process owners comparing actual execution with an agreed operating model.
Where this can make a practical difference.
Waiting and rework analysis
Identify where recorded cases accumulate time or repeat activities. Distinguish elapsed time from active processing where the available events allow it, and avoid attributing unexplained gaps automatically to staff performance.
Process-change evaluation
Compare relevant case cohorts before and after an operational change. Consider differences in case mix, seasonality and data capture before interpreting a shorter journey as evidence of improvement.
How we approach the work.
Choose the process question
Define the case being followed, its start and end boundaries and the decisions the analysis should inform. Avoid merging unrelated workflows simply because their records share a system.
Assess event suitability
Review case identifiers, activity names and timestamp meaning. Examine missing events, time zones and whether a recorded date represents creation, start, completion or later administrative entry.
Construct and validate the event view
Join authorised sources with documented rules. Test sample journeys with process specialists so the reconstructed sequence reflects the source correctly and does not invent ordering unsupported by timestamps.
Analyse variants and constraints
Explore routes, waiting patterns and repeated steps. Compare relevant case groups and investigate apparent deviations against the process context rather than labelling every variation a failure.
Translate findings into experiments
Prioritise changes with accountable owners and measurable hypotheses. Revisit the event evidence after implementation, retaining the original scope and definitions for a fair comparison.
The sequence is tailored to the agreed scope, dependencies and risk. It describes our delivery approach, not a fixed timeline or performance guarantee.
What the engagement can deliver.
- Defined process scope and case model.
- Validated event dataset with provenance and limitations.
- Process-flow, variant and waiting-time analysis.
- Evidence-linked improvement hypotheses and priorities.
- Repeatable measurement and process-owner guidance.
The proposal identifies the deliverables, acceptance evidence, responsibilities and support arrangements included in your engagement.
Measure what matters to this workflow.
Case cycle-time distribution
Examine the spread of elapsed times and relevant cohorts, rather than relying only on an overall average.
Recorded rework frequency
Track meaningful repeated activities while distinguishing necessary iteration from avoidable correction.
Event coverage
Measure whether the available records support a sufficiently complete and consistent view of the scoped process.
These are measures to discuss and baseline. Targets are agreed for the specific system and data; no universal improvement percentage is assumed.
What to prepare for discovery.
- Event records containing usable case references and timestamps.
- Process specialists who can explain activities and legitimate exceptions.
- Permission to analyse the selected operational data and reporting levels.
Questions worth asking.
Can process mining prove why a delay happened?
It can identify patterns worth investigating, but event sequences alone may not establish cause. Interviews, operational context and targeted experiments can be needed to explain the pattern credibly.
What if our systems do not record every step?
We assess what the records can support and state the gaps. The first useful outcome may be improved event capture rather than a complete process model built on unreliable assumptions.
Is this a tool for monitoring individual employees?
The proposed focus is process performance. Reporting granularity, permissions and interpretation should be agreed explicitly, avoiding conclusions about individuals that the event data cannot fairly establish.