Productivity

The question your ICT strategy never had to ask

For years it asked how technology should support the work. Now it has to answer who does it.

Section one

Every ICT strategy you have approved answered the same question

Which platform. Which infrastructure. Which integration. Which vendor, and which of them to retire.

Different questions with one question underneath: how should technology support the work?

That assumption has been carrying more than anyone noticed. It is why an ICT strategy could be approved by the technology function with nobody else in the room, because supporting the work changes nothing about who is accountable for it. It is why you have never had to describe how your organisation actually works in order to buy a platform. Supporting the work tolerates incomplete description, because people carry the ambiguity. Handing the work over does not.

The closest you came to a different question was outsourcing. Payroll to a bureau, support to a managed provider. That did decide who does the work, and it arrived with a counterparty: a contract, a service level, a number to call, and somebody whose job it was to answer when it went wrong. Accountability never actually transferred, because no regulator has ever accepted that the provider did it. But recourse did, and recourse was enough to make the arrangement manageable.

It was also large, visible and expensive, so it forced itself in front of someone who had to approve it.

Every ICT strategy before this one decided how technology supports the work. This is the first one that decides who does it.

AI is the first item on an ICT agenda that can answer who does the work with something other than a person, and with nobody on the other side. No contract, no service level, no number to call. The exception queue is yours. The supervision is yours. And accountability, which never transferred, can end up resting with nobody in particular, because it used to sit quietly with the person performing the work.

It also arrives one workflow at a time, and no single step is large enough to require a decision.

This is not a single choice either. Between supporting the work and doing the work there is a range of positions, and an organisation can sit at any of them on purpose or arrive at one by accident.

Which is where the rest of this goes. One thing first, because everything below will be misread without it. What follows is not a maturity ladder. Letting a system further into the work is not automatically better, and keeping it outside the work can be the correct and final answer for a well-run organisation. The problem is not where you sit. The problem is claiming a return your position cannot support, or discovering that systems have entered the work without anyone having chosen it.

Section two

Four positions, and what changes as you move along them

Between the two poles there are four positions.

Outside the work. A system helps a person: research, drafting, summarising, notes. No formal step in the process changes hands.

Beside the work. It prepares, checks or recommends. A person still performs the step and makes the decision.

Inside the work. It performs a defined step, or holds a responsibility, inside the process.

Exercising delegated judgement. It chooses between permitted actions under uncertainty.

There is a fifth category that is not on that line at all: work deliberately retained as human. That is a refusal rather than a starting point, and an organisation that has named it is ahead of one that has not.

When technology supported the work	When a system performs it
Incomplete description was survivable, because people carried the gaps	It has to be described well enough to hand over, and there is no provider to ask a clarifying question
The product category carried most of the specification	It arrives organisationally blank. You write the job description
Nobody’s accountability changed, because nobody’s role changed	Responsibility moves, so accountability has to be placed deliberately or it goes missing
When it went wrong, there was recourse	There is an exception queue, and it is yours to staff

The second row is the one that catches people, and it is worth being precise about.

AI does not arrive technically blank. It arrives organisationally blank. A payroll platform processes payroll. A firewall controls network traffic. A CRM manages customer information. The product category carried most of the job description, which is exactly why prior experience and a known vendor were rational shortcuts. You were not being lazy. You were using information the category gave you for free.

Most enterprise systems you have bought arrived with a recognisable job description. A general capability does not. You supply the work, the sources it may treat as authoritative, the actions it may take, the limits, the escalation condition, and the person who answers for the result. If you do not define them, the platform’s defaults, the implementer’s assumptions and individual users’ habits will define them for you.

Section three

Seven decisions worth taking early

1	Find out where you already are. Most organisations are further along than they think, through increments nobody approved as a coherent change.
2	Set the current ceiling. How far the organisation is prepared and ready to go now. It is temporary, so record what would have to become true for it to move, who decides that it has, and what evidence they would need.
3	Write the refusals separately. The ceiling says not yet. The refusals say not this. Confuse them and you either close off value because you were briefly unready, or spend years automating something you had already decided should stay human. Refusals must be owned by the executive responsible for the affected outcome, not settled by the technology function alone.
4	Size the description work to the position you chose. Deeper participation demands a more explicit operating model. That is the constraint, and it is also the pricing. Staying near the outside does not require a full redesign to get there.
5	Judge consequence separately from participation. Reversibility, exposure, who is affected, whether an error is visible before it lands, and how often the thing runs.
6	Name an accountable human position for every responsibility held by a system. A system can do the work. It cannot answer for it. When responsibility moves, accountability has to be placed deliberately.
7	Do not claim a return your position cannot support. Individual assistance produces local gains that are real and hard to aggregate. Process-level returns require the system to be in the process.

How far into the work a system sits tells you what has to be described. What happens when it is wrong tells you how strongly it has to be controlled.

Section four

Where people get it wrong

Assumption	Reality
We will decide about AI later	The decision is being taken now, by default. Later means discovering that the operating model has already changed, and reconstructing it after the fact
Further in is more advanced	These are positions, not stages. A well-governed organisation outside the work beats a drifting one inside it
We need to pick the right AI product	Most enterprise systems you bought arrived with a recognisable job description. A general capability does not. You write it, or you inherit someone else’s
It is only routine work, so the risk is low	Routine is not the same as low consequence. A payment run can be entirely deterministic, high in value, and costly to reverse
An ICT strategy is a technology document	If it moves work off people it changes what they answer for, so it cannot be signed out by the technology function alone

Section five

Order before automation

The sequence is the argument. Client value, then the journey, then what has to be true, then the process and who is responsible for each part of it. Technology is the consequence of that work rather than the premise of it.

Which is why the question is not how much AI you want. Almost everyone wants AI, provided it is useful and causes no trouble. That answer carries no information and cannot be designed against.

The question is how far you are prepared to let technology move from supporting your work to performing it. Or, put the way it will actually feel in three years: what work are you willing to have done by something that cannot answer for it.

That is a question about delegation, authority and comfort. You can answer it from experience rather than from a technology briefing, and it is the one decision in an ICT strategy that only you can make.

You cannot invite AI further into the operating model than you are prepared to describe the operating model.

The place to begin is not a product list. Find out where systems already sit in your work, decide which of those positions were chosen and which merely happened, and name what has to stay human.

Start by finding out where you already are.

Start a conversation.