Skip to content
Between the Events

Index  ·  Operations

Who Owns It

The role that makes a programme durable, the skills it needs, and the three homes it can have — each with a different distortion.

Analysis

Process mining decays without an owner faster than most analytical capabilities, because the log depends on systems that change.

Why it decays

Activity codes change when a system is configured, and unmapped codes silently vanish or become new activities.

Extracts fail, and a frozen number is worse than none because it is still quoted.

The case identifier stops being valid after a process change.

The person who built it moves on, taking the undocumented decisions with them.

Findings stop being acted on, so the reporting stops being read.

The three homes

Process improvement or operational excellence. Understands the process and the change mechanism, may lack the data skills.

Data or analytics. Builds the pipeline well and struggles to get findings acted on, because the operational relationships are not theirs.

IT. Owns the extracts and treats the output as a technical deliverable.

Each distorts predictably. The workable arrangement is ownership in process improvement with a named data engineering resource and an agreed extract from IT.

The skills actually needed

Enough SQL to build and check the log, which is the largest single gap in practice.

Understanding of the process, which is what distinguishes a finding from an artefact.

Comfort with variation, so ordinary movement is not reported as a change.

The ability to validate with the operation, which is a relationship rather than a technique.

Tool skills last. They are the easiest to acquire and the most often recruited for.

What the owner does

Maintains the extract, the mapping and the exclusion rules, versioned.

Runs the refresh and checks the data quality report.

Produces the one-page measures.

Validates findings with the operation before reporting them.

Tracks open findings to closure.

Re-measures after changes, and reports the null results.

Re-validates annually that the map still reflects reality.

The time it takes

Setting up the first process: weeks, mostly extraction and data quality.

Each subsequent process of a similar type: a fraction of that, if the pattern was recorded.

Ongoing per process: a few hours a week, mostly the refresh check and the findings work.

Not a full-time role for one process, and not a spare-time activity across ten.

The handover problem

Most of the value is in undocumented decisions: why this case identifier, why this boundary, why these exclusions, what the mapping means.

Write them down in one document per process, kept with the queries.

Include what was tried and rejected, which saves the successor repeating it.

A programme whose knowledge lives in one person's head will restart from nothing when they leave, and it usually does not restart.

The per-process decision document

One page that makes handover possible and prevents the successor repeating the work.

Case identifier chosen, and why; what was rejected.

Boundary: start and end activities, and why.

Mapping approach and version.

Exclusion rules and their volumes.

Known data defects and how they are handled.

What was tried and did not work.

Kept with the queries, not in a separate wiki that nobody finds.

The annual re-validation

Processes change and a map ages without announcing it.

Once a year, trace twenty current cases by hand and compare against the log.

Ask the operation whether the map still reflects how they work.

Check the case identifier is still valid after any process change.

Check the boundary still makes sense.

Re-check the mapping against current codes.

A programme that has not re-validated in two years is reporting on a process that no longer exists, confidently.

What the owner actually needs

The role fails when it has the analysis and not the authority.

Access to the source data, without a request each time.

Allocated time, permanently, not as a project.

A route to the process owner who can change the process.

Authority to publish findings including unflattering ones.

A standing slot in the operational review.

Without the last two the role becomes an analyst producing reports on request, which is where most of these functions end up.