Running It Continuously
Moving from a project to a refresh. What to automate, what to alert on, and why most continuous deployments become dormant.
Procedure
A one-off analysis answers a question. A refreshed log answers whether the answer is still true, which is where the durable value is.
What continuous means
The extract runs on a schedule, incrementally.
The log rebuilds, with the same rules and mapping.
A small set of measures is recomputed and reported.
A smaller set of rules generates alerts.
Not: a dashboard with forty tiles refreshed hourly, which is where most deployments end up and why nobody opens them.
The refresh cadence
Matched to how often anyone could act.
Weekly for most business processes, which is faster than the decisions.
Daily where a compliance rule matters, since a segregation breach should not wait a week.
Hourly is almost never useful for a process whose cases take days, and it produces noise.
What to recompute
Cycle time median and ninetieth percentile.
Waiting as a proportion of cycle time.
Rework rate.
Handovers per case.
Conformance rate on the rules that matter, not a fitness score.
Case volume, so the others can be read against it.
Data quality: exclusion rate, unmapped codes, incomplete cases.
Seven measures, with normal ranges marked so ordinary movement does not generate questions.
What to alert on
A short list, or the alerts get ignored.
Segregation of duties breach.
Mandatory approval skipped above a threshold.
Duplicate payment or duplicate case.
A case open beyond a defined age.
A new activity code appearing, which usually means a system change nobody told you about.
Each routed to someone who can act, the same day.
Why deployments go dormant
Alerts too numerous, so they are filtered to a folder.
Measures nobody owns.
The mapping breaks when a system changes and nobody notices the codes are unmapped.
The extract fails silently and the numbers freeze, which is the worst case because they are still quoted.
No standing forum, so the report has no audience.
Keeping it alive
Alert on the pipeline itself: extract failure, volume anomaly, unmapped codes.
A named owner with allocated time.
A standing slot in an existing operational review, not a new meeting.
Quarterly prune: which measures has anyone used, which alerts produced an action. Remove the rest.
An annual re-validation with the operation that the map still reflects reality, because processes change and the mapping ages.
The honest test
Ask three people what they did differently because of the refresh, in the last month.
A blank answer means it is dormant, and the response is to cut it down to the measures that were used rather than to add more.
The pipeline health alerts
Separate from the business rules and equally necessary.
Extract failure.
Volume anomaly, in either direction.
Unmapped activity codes appearing, which usually means a system change nobody announced.
Negative durations, which should never occur.
Clock offset beyond a threshold.
These prevent the worst failure in the field: a frozen or silently corrupted log whose numbers are still being quoted in meetings.
The quarterly prune
The maintenance activity that keeps a refresh alive.
Which measures has anyone used to make a decision?
Which alerts produced an action?
Remove the rest, which is usually most of them.
Resist adding a measure when a question is asked, since the answer is frequently a one-off analysis rather than a permanent tile.
A report that only grows becomes wallpaper within a year, and the pruning is what keeps the remainder noticed.
Deciding what to run continuously
Most of an analysis is a one-off. A small part is worth a schedule.
Case duration percentiles, weekly.
Rework rate.
Variant count and the share covered by the top paths.
Waiting proportion by stage.
Data quality: exclusion rate and clock agreement.
Not the discovered model, which does not change weekly and takes attention to read.
Five measures with normal ranges marked, on one page, owned by a named person.