Organiseer AI rond de eigenaren van workflows

In maart namen we met de directie van een industrieel concern het AI-programma door. Het expertisecentrum, het centrale team voor AI, had een sheet met pilots die twee kolommen vulde: contractsamenvattingen, een verkoopassistent, factuurherkenning, een chatbot voor onderhoud, een experiment met voorspellingen. De CEO vroeg welke daarvan het bedrijf zou missen als ze vrijdag werden stopgezet. Na enige discussie was het antwoord: één. Dat was de pilot die een fabrieksmanager had overgenomen en uit zijn eigen budget betaalde.

De meeste pilots werkten, in de zin dat de demonstratie deed wat ze beloofde. Wat die ene onderscheidde, was een eigenaar: iemand wiens resultaten ervan afhingen en die gebeld werd als de pilot het mis had.

Het centrum werd opgezet rond de schaarse kennis van vorig jaar

Toen ChatGPT verscheen, was de schaarse kennis weten wat deze modellen konden. Het was logisch om de weinige mensen die ze begrepen in een centraal team te bundelen, het een innovatiebudget te geven en het experimenten te laten draaien in het hele bedrijf.

Die schaarste neemt af. GPT-4 en Anthropics Claude 3, vorige maand uitgebracht, zijn beschikbaar voor elk bedrijf met een creditcard, en capabele modellen worden steeds goedkoper. Andreessen Horowitz ondervroeg leidinggevenden van grote ondernemingen ("16 Changes to the Way Enterprises Are Building and Buying Generative AI", maart 2024) en zag uitgaven aan generatieve AI verschuiven van eenmalige innovatiebudgetten naar vaste softwarebudgetten. Het lastige deel is nu een model koppelen aan de systemen waarop een workflow draait: het ERP (het centrale bedrijfssysteem), de bankbestanden, het ticketsysteem. Daarvoor zit een centraal lab niet op de goede plek.

Klarna had geen beter model

In februari meldde Klarna dat een assistent in de eerste maand twee derde van de chats van de klantenservice afhandelde, met 25% minder herhaalvragen. Dat zijn Klarna's eigen cijfers. Het model kwam van OpenAI, op voorwaarden die ook voor concurrenten openstaan. Wat Klarna zelf bouwde, was de koppeling met zijn order- en terugbetalingssystemen, en de maatstaf: herhaalvragen, een cijfer dat van het hoofd klantenservice is.

De eenheid van AI is een workflow met een eigenaar

Order to cash, van leveranciersfactuur tot betaling, van claim tot afwikkeling, van ticket tot oplossing: elke workflow heeft een bestuurder wiens cijfers hij beweegt, en die bestuurder is eigenaar van de AI erin, verantwoordelijk voor vier dingen:

• Het resultaat. Gemeten op de eigen cijfers van de workflow, zoals tijd tot factuur, hoeveel dagen klanten nodig hebben om te betalen of hoeveel vragen bij het eerste contact zijn opgelost. Niet op de nauwkeurigheid van het model.
• De uitzonderingen. Elk geval dat het systeem niet afhandelt, gaat naar mensen die daarvoor zijn ingeroosterd en opgeleid. Als uitzonderingen nergens heen kunnen, wordt het systeem waarschijnlijk omzeild.
• De regels. Welke beslissingen het systeem mag nemen, welke een mens nodig hebben en wie beide mag wijzigen. Opgeschreven en ondertekend.
• Het budget om te draaien. De kosten om het systeem jarenlang te draaien en aan te passen, in het operationele budget van de eigenaar, niet in het innovatiefonds.

De engineers zitten bij de operatie

AI koppelen betekent lezen uit en schrijven naar systemen die daar nooit voor ontworpen zijn, een leveranciersbestand verwerken waarvan het formaat van de ene op de andere maand veranderde, weten dat een boeking in een al afgesloten maand wordt geweigerd. Dat leert u naast de mensen die het werk doen, door te zien wat ze doen als het scherm iets onverwachts laat zien. Dus horen de engineers die de AI van een workflow bouwen met dat team te werken zolang het duurt om het goed te krijgen, niet vanuit een ticketwachtrij in een centraal lab. Het werk dat ertoe doet is minder modieus dan slimme prompts schrijven: een engineer die een ERP een correcte transactie precies één keer laat accepteren, en die het crediteurenteam bij naam kent.

Wat het centrum houdt

Het centrum beheert de gedeelde basis in plaats van losse use cases:

• Toegang en contracten. Goedgekeurde modellen, hostingafspraken, verwerkersovereenkomsten, één plek om capaciteit in te kopen.
• Standaarden. Hoe beslissingen worden gelogd, hoe een systeem vóór livegang op echte gevallen wordt getest, welk bewijs een workflow-eigenaar moet kunnen overleggen.
• Risicobeleid. Welke klassen beslissingen überhaupt geautomatiseerd mogen worden en wie daarvoor tekent.
• Een kleine groep specialisten die workflowteams bij moeilijke problemen helpen en weer doorgaan.

Software die handelt, heeft een leidinggevende nodig

Het onderzoek beweegt van modellen die antwoorden naar systemen die handelen: boeken, betalen, een klant antwoorden, een record wijzigen. Leidinggeven aan software die handelt lijkt op leidinggeven aan een team. Als software een derde van de leveranciersfacturen verwerkt, beslist de manager crediteurenadministratie wat ze mag afhandelen, ziet elke week haar werklast en fouten naast die van de mensen die de andere twee derde verwerken, en past haar regels aan als het bedrijf verandert. IT en het centrum ondersteunen dat, maar zitten niet op de plek om het van buiten de workflow te doen.

Wat dit kwartaal te doen

1. Zet een naam naast elke pilot. De bestuurder wiens cijfers het verandert en die heeft ingestemd eigenaar te zijn. Stop de pilots zonder naam, ook als dat de meeste zijn.
2. Verplaats het geld en de engineers. Financier elk overgebleven systeem uit het operationele budget van de eigenaar, inclusief drie jaar draaien, en wijs de bouwers toe aan de workflow.
3. Verander de definitie van klaar. Een systeem is live als het in de weekcijfers van zijn eigenaar staat en de afhandeling van zijn uitzonderingen in iemands functieomschrijving.

Tel eigenaren

Rapporteer voortgang als een lijst met namen, niet als een aantal pilots. Elke naam is een workflow waarvan iemand heeft gezegd: dit is van ons, dit is wat het veranderde, en zo vangen we op wat het niet kan.