From Finding to Change

The common failure is a correct finding that nobody acts on, repeated until the reporting is ignored.

Why findings stall

They point at something expensive, so they are noted and deferred.

They point at another department's process.

No owner, so the finding sits in a deck.

Too many at once, so none is pursued.

No mechanism, because the project was scoped as analysis.

Disputed on data quality grounds, which is settled by validating with the operation before reporting.

The sequence

One finding at a time, the largest by cost rather than the easiest.

Validated with the people who handle those cases, which both settles the data dispute and usually improves the finding.

Costed, in cycle time or money, with the assumption shown.

Owned by someone who can change the process, named.

With a date.

Re-measured from the same log, the same query, afterwards.

Reported, including where nothing changed.

Choosing the first one

Cheap, so it needs no capital case.

Inside the operation's own control, not dependent on another department.

Visible, so people see that the analysis leads somewhere.

Uncontroversial, which means not about individual performance.

A ping-pong loop between two teams, a missing validation at entry, or an availability gap at a particular hour are the usual candidates, and all three are free to fix.

Validating with the operation

The step that is skipped and that determines whether the finding survives.

Take it to the people in that process.

Ask whether it matches what they see.

Ask what the log does not know, which is where the data defects surface.

Ask what they would change, which frequently produces a better answer than the analysis.

A finding that surprises the people who do the work is usually a data problem. One that confirms what they have been saying is usually right and has been ignored.

The re-measurement

Same log, same query, same boundary, same period length.

After a settling period, not immediately.

Reported honestly, including a null result.

This is the whole value of process mining over other improvement methods: the before and after come from the same instrument, so the comparison is unusually clean.

A project that never re-measures has given up its main advantage.

What sustains it

A standing slot in the operational review, not a separate forum.

A short list of open findings with owners and dates, reviewed.

Closure reported, with the measured effect.

A named owner with allocated time, because a programme that is everyone's job is nobody's.

The open findings list

The artefact that keeps a programme from becoming a reporting exercise.

One row per finding: what, cost, owner, date, status.

Short. More than about eight open items means none is being pursued.

Reviewed in an existing operational meeting, not a separate forum.

Closed only after re-measurement, not after the change was made.

Overdue items escalated, which is what produces the attention.

Published, including the ones closed with no effect.

Costing a finding in the operation's currency

The same finding lands differently depending on the unit.

Cycle time in days for a customer-facing process.

Touches or handovers where effort is the concern.

Cases affected where risk is the concern.

Money where finance is the audience, computed from your own rates.

Ask what the owner is measured on and express it in that. A finding in the wrong currency gets acknowledged and not acted on.

The sequence that produces a change

Most analyses end as a report. This is what converts one into a modified process.

One finding at a time, the largest.

Verified with the people who run the process, which settles the data quality dispute before it starts.

Costed roughly, in both directions.

Owned by someone who can change the process, named.

With a date.

Re-measured afterwards from the same log definition, which is the step that establishes whether the programme is worth continuing.

Reported, including when the change did not work.