Alerting That Gets Acted On

Continuous conformance is the one part of process mining worth running daily. It fails by volume.

The rules worth alerting on

Segregation of duties breach: the same person performed two activities that must be separated.

Mandatory approval skipped on a case above a threshold.

Duplicate payment or duplicate case.

A case open beyond a defined age.

A control performed after the thing it controls.

A new activity code appearing, which usually means a system change nobody announced.

Six rules. Start there and add only from incidents.

What not to alert on

Any deviation from a full process model, which fires constantly.

Variant novelty, since new variants appear continuously and mean nothing.

Cycle time above an average, which fires on half the cases by construction.

Anything without a defined action, which is the test: if the recipient does not know what to do, the alert should not exist.

Routing

To a named person or a queue with an owner, not to a distribution list.

As a work item where a case system exists, so it has a state and can be closed.

With the case reference, so the recipient can act without asking for it.

With the rule stated in plain words, not a rule identifier.

Same day for compliance rules, which is the point of running them continuously.

Measuring whether it works

Fire rate per rule per week.

Action rate: how many produced a change or a correction.

Time from fire to action.

False positive rate, investigated rather than assumed.

A rule with a high fire rate and a low action rate is a bad rule, not a disobedient recipient.

Tuning

Review quarterly.

Remove rules that have never produced an action after a year.

Tighten thresholds on rules that fire too often, having checked what the extra firings were.

Investigate rules that never fire, by testing them deliberately, since silence usually means misconfiguration rather than perfection.

The data quality alerts

Separate from the business rules and equally important.

Extract failure.

Volume anomaly, either direction.

Unmapped activity codes appearing.

Negative durations, which should never occur.

Clock offset beyond a threshold.

These prevent the worst failure in the field: a frozen or corrupted log that is still being quoted.

The threshold question

Every alert has a threshold and it should be set from the data, not from a round number.

Look at the distribution first, then choose a point that produces a volume someone can actually handle.

Write down why that number, because it will be questioned and "it seemed reasonable" is not an answer.

Keeping the alert list short

Alerting on process deviation degrades the same way every warning system does.

Start with three rules, not thirty.

Measure the fire rate for a month.

Anything firing daily is a bad rule, almost always.

Route to someone who can act on that case, not to a shared inbox.

Track the finding rate per rule and remove rules that have never produced an action after a year.

Add rules from incidents, which is where the useful ones come from.