AI Strategy and Transformation: SOPs

Six procedures. Together they answer the question this function exists to answer, which is not "should we use AI" but "which processes consume the most human hours, and which of those can be automated or augmented?"

The order matters. Each one produces the input the next one needs.

SOP 1: Process inventory and ranking#

Run: annually in full, and whenever a function reorganises.

The inventory is the foundation and the part most often skipped, because it is unglamorous and takes weeks. Without it, candidate selection is driven by whoever asks loudest.

1. List every recurring process in the function. Recurring means it happens on a schedule or on a trigger, not once.
2. For each, record: annual human hours, frequency, number of people involved, whether the output is reversible, whether a mistake is visible immediately or discovered later, and whether the process is bound by a regulation.
3. Get hours from observation or system logs, not from asking. People underestimate routine work and overestimate exceptional work, consistently and in that direction.
4. Rank by annual hours. Publish the top 20.

The top 20 by hours is the candidate pool. Nothing enters the pipeline that is not on it, unless someone writes down why the list is wrong.

SOP 2: Candidate scoring#

Run: on every process entering the pipeline.

Score each candidate on four axes, one to five:

A candidate scoring below three on reversibility or tolerance does not proceed to automation, whatever it scores on volume. It may proceed to augmentation, where a person still decides.

That rule is the whole difference between a transformation programme and an incident.

SOP 3: Baseline protocol#

Run: before any change starts. No exceptions.

1. Name the measure. One measure, defined in writing, owned by Data and Analytics.
2. Take at least four weeks of history, or a full cycle if the process is monthly.
3. Record the variance, not just the average. A process averaging two days with a range of one to thirty is a different problem from one that always takes two days.
4. Freeze the baseline. It is not adjusted later because the change underdelivered.

No baseline, no benefit claim. This is the rule most often skipped under time pressure and the most expensive to skip, because without it the argument about whether the programme worked can never be settled with evidence.

SOP 4: Change execution#

Run: per change, through the PMO.

This function does not deliver changes. It defines them, sequences them and measures them; the PMO assigns a project manager and delivery happens through the normal route. Keeping definition and delivery apart is what stops a change being declared successful by the people who built it.

Required before go-live: rollback path written and tested, exception route named, the person accountable for the output identified by name, and the measure already running.

SOP 5: Post-implementation review#

Run: at 90 days, and again at 12 months.

• Compare the same measure against the frozen baseline.
• State the result plainly, including when it is bad. A published failure is worth more than a quiet success, because it is the only thing that stops the next team repeating it.
• Record what would have to be true for the change to be revisited.
• The 12-month re-check exists because benefit decays and nobody looks.

SOP 6: Refusal list review#

Run: quarterly.

Maintain the written list of processes the company will not automate, with the reason and the date. Reasons are usually one of: irreversible outcome, regulated decision, a person must be accountable, or the failure mode is invisible until it is expensive.

Without a published refusal list, every request becomes an individual negotiation and the answer depends on who is asking. With one, the conversation starts from a principle.

Escalation#

Back to AI Strategy & Transformation