Organise AI Around Workflow Owners

In March we sat with the executive committee of a manufacturing group reviewing its AI programme. The centre of excellence, the central team set up to lead AI, had a slide of pilots that ran to two columns: contract summaries, a sales assistant, invoice reading, a maintenance chatbot, a forecasting experiment. The chief executive asked which of them the business would miss if they were switched off on Friday. After some discussion, the answer was one: the one a plant manager had adopted and was paying for out of his own budget.

Most of the pilots worked, in the sense that the demonstration did what it promised. What set that one apart was an owner: a person whose results depended on it and who got the phone call when it was wrong.

The centre was built around last year's scarce skill

When ChatGPT arrived, the scarce thing was knowing what these models could do. It made sense to gather the few people who understood them into a central team, give it an innovation budget and let it run experiments across the business.

That scarcity is fading. GPT-4 and Anthropic's Claude 3, released last month, are available to any company with a credit card, and capable models keep getting cheaper. Andreessen Horowitz's survey of enterprise leaders, "16 Changes to the Way Enterprises Are Building and Buying Generative AI" (March 2024), found generative AI spend moving from one-off innovation budgets into permanent software budgets. The hard part now is connecting a model to the systems a workflow runs on: the ERP (the core business system), the bank files, the ticket system. A central lab isn't placed to do that.

Klarna did not have a better model

In February Klarna reported that an assistant was handling two thirds of its customer service chats in its first month, with repeat inquiries down 25%. These are Klarna's own figures. The model came from OpenAI, on terms open to its competitors. What Klarna built itself was the connection to its order and refund systems, and the measure: repeat inquiries, a number that belongs to the head of customer service.

The unit of AI is a workflow with an owner

Order to cash, supplier invoice to payment, claim to settlement, ticket to resolution: each has an executive whose numbers it moves, and that executive owns the AI in it, accountable for four things:

• The result. Measured on the workflow's own numbers, such as time to invoice, how many days customers take to pay, or how many issues are solved on first contact. Not on model accuracy.
• The exceptions. Every case the system doesn't handle goes to people who are staffed and trained for it. If exceptions have nowhere to go, the system is likely to be bypassed.
• The rules. Which decisions the system may take, which need a person, and who may change either. Written down and signed.
• The running budget. The cost of running and changing the system for years, in the owner's operating budget, not the innovation fund.

The engineers sit with the operation

Connecting AI to a business means reading from and writing to systems never designed for it, handling a supplier file whose format changed from one month to the next, knowing that an entry dated in a month already closed will be rejected. It is learned next to the people who do the work, watching what they do when the screen says something unexpected. So the engineers building a workflow's AI should work with that team for the months it takes to get it right, not from a ticket queue in a central lab. The job that matters is less fashionable than writing clever prompts: an engineer who can make an ERP accept a correct transaction exactly once, and who knows the accounts payable team by name.

What the centre keeps

The centre runs the shared foundations instead of individual use cases:

• Access and contracts. Approved models, hosting arrangements, data processing terms, one place to buy capacity.
• Standards. How decisions are logged, how a system is tested on real cases before it goes live, what evidence a workflow owner must be able to show.
• Risk policy. Which kinds of decision may be automated at all, and who signs off.
• A small group of specialists who help workflow teams with hard problems and move on.

Software that acts needs a manager

Research is moving from models that answer to systems that act: entering transactions, paying, replying to a customer, changing a record. Managing software that acts looks like managing a team. If software processes a third of the supplier invoices, the accounts payable manager decides what it may handle, sees its workload and errors each week next to those of the people who process the other two thirds, and changes its rules when the business changes. IT and the centre support that work, but they aren't placed to do it from outside the workflow.

What to do this quarter

1. Put a name next to every pilot. The executive whose numbers it changes and who has agreed to own it. Stop the ones without a name, even if that's most of them.
2. Move the money and the engineers. Fund each surviving system from the owner's operating budget, including three years of running it, and assign its builders to the workflow.
3. Change the definition of done. A system is live when it appears in its owner's weekly numbers and its exceptions are written into someone's job description.

Count owners

Report progress as a list of names, not a number of pilots. Each name is a workflow where someone has said: this is ours, this is what it changed, and this is who handles what it can't.