Del IV · Kapitel 2
Från ett AI-system till tio — så bygger ni grunden för att skala
Det första systemet kan byggas för sig. Det femte kan inte det. Så bygger ni en gemensam grund som gör varje nytt flöde billigare och säkrare.
I det här kapitlet12 avsnitt
Det första AI-systemet i ett företag byggs nästan alltid för sig. Det har en egen koppling till en AI-modell, egna integrationer, eget sätt att logga och egna instruktioner i en fil som en person har koll på. Det är helt rimligt. Det första systemet ska bevisa att det går, och att bygga en plattform innan dess vore att gissa.
Men det som fungerar för ett system fungerar inte för tio. Med varje nytt system som byggs på samma sätt växer kostnaden för förvaltning, riskerna med säkerhet och svårigheten att veta vad som händer. Det här kapitlet handlar om när och hur ni bygger den gemensamma grunden, så att det tionde systemet blir enklare än det första i stället för svårare.
Vad som händer utan gemensam grund
Det brukar gå till ungefär så här. Det första systemet lyckas. Ekonomiavdelningen vill ha ett eget. Kundtjänst också. Någon på marknad har redan byggt något med ett färdigt verktyg. Varje system byggs av olika personer, med olika verktyg, olika modeller och olika sätt att hantera data.
Efter ett år finns sex system. Ingen vet exakt vilken data som skickas vart. Två system använder en modell som leverantören snart slutar stödja. Ett system har slutat fungera bra, men ingen märkte det eftersom ingen mätte kvaliteten. Kostnaden för modellanrop har tredubblats utan att någon kan säga varför. Och när ledningen frågar vad AI har gett, finns inget gemensamt sätt att svara.
Inget av det beror på att något enskilt system var dåligt byggt. Det beror på att ingen byggde det som ska vara gemensamt. Ingen hade det som uppgift, och därför blev det inte gjort. Det är den uppgiften det här kapitlet handlar om.
Det som ska vara gemensamt
Den gemensamma grunden behöver inte vara stor. Den består av sex delar.
1. Åtkomst till AI-modeller
Alla system går genom samma lager för att anropa AI-modeller. Det gör att ni kan byta modell på ett ställe, följa kostnaden per system, sätta gränser för användning och se till att data bara skickas till leverantörer som är godkända.
2. Säkerhet och behörigheter
Ett gemensamt sätt att hantera nycklar, behörigheter och åtkomst till data. Varje system får bara komma åt det det behöver, och det finns en lista över vilka system som har tillgång till vad.
3. Loggning
Varje system loggar på samma sätt: vad som kom in, vilka uppslag som gjordes, vad systemet föreslog eller gjorde, vem som granskade och vad resultatet blev. Det gör det möjligt att följa upp fel, svara på frågor från revisorer och kunder och förbättra systemen över tid.
4. Mätning
Ett gemensamt sätt att mäta kvalitet och effekt. Varje system har sina egna mått, men de rapporteras på samma sätt och samlas på ett ställe. Hur ni väljer måtten beskrivs i kapitlet om att mäta effekten av AI.
5. Test
Varje system har en uppsättning testexempel med kända rätta svar. När en instruktion ändras eller en modell byts körs testerna innan förändringen går i drift. Det är det som gör det möjligt att förändra systemen utan att vara rädd.
6. Arbetssätt
Ett gemensamt sätt att ta ett flöde från idé till drift: kartläggning, kalkyl, beslut, bygge, test, driftsättning och uppföljning. Det behöver inte vara byråkratiskt. En checklista som alla följer räcker långt.
När ni ska bygga grunden
Det finns en tidpunkt som är för tidig och en som är för sen.
För tidigt är innan det första systemet är i drift. Då vet ni inte vad som behöver vara gemensamt, och risken är stor att ni bygger en plattform för behov ni inte har.
För sent är när fem eller sex system redan är byggda på olika sätt. Då måste varje system byggas om för att passa grunden, och det blir ett stort projekt som är svårt att motivera.
Den bästa tidpunkten är ofta efter det första eller andra systemet, när ni vet att fler kommer. Ta det ni lärde er av de första systemen och lyft ut det som ska vara gemensamt. Bygg nästa system på grunden från början, och flytta över de första när det passar.
Vem som äger vad
En vanlig fråga är om AI ska ägas centralt eller i verksamheten. Svaret är båda, men för olika saker.
Verksamheten äger flödena. Den som äger ett flöde ansvarar för att det ger resultat, bestämmer vad systemet ska göra och följer upp effekten. Det är samma princip som för det första systemet, och den ska inte ändras när antalet växer.
En liten central funktion äger grunden. Den ansvarar för åtkomst till modeller, säkerhet, loggning, mätning, test och arbetssätt. Den hjälper verksamheten att bygga nya flöden och ser till att de följer gemensamma regler. I ett medelstort företag kan det vara två eller tre personer.
Undvik att låta den centrala funktionen äga alla flöden. Det blir en flaskhals, och kopplingen till verksamhetens resultat försvagas. Undvik också att låta varje avdelning bygga helt fritt. Det leder tillbaka till sex system som ingen har överblick över.
Prioritera öppet
När de första systemen har lyckats vill många ha AI. Det är ett gott tecken, men det kräver prioritering.
Använd samma kalkyl för alla förslag: dagens kostnad, realistisk effekt, kostnad för att genomföra, risk och hur lätt resultatet är att mäta. Kalkylen beskrivs i kapitlet om att räkna på ett AI-projekt. Gör prioriteringslistan synlig. De som får vänta ska förstå varför, och veta vad som skulle få deras flöde att flytta upp.
Prioritera också för lärande. Ett flöde som är medelbra i kalkylen men som testar en ny typ av uppgift, till exempel det första flödet som skriver direkt till kunder, kan vara värt att göra tidigt eftersom det lär organisationen något som nästa flöde har nytta av.
Återanvändning
Med en gemensam grund blir varje nytt system billigare, eftersom mycket redan finns. Men den största vinsten kommer från återanvändning av det som är specifikt för er.
- Uppslag. Ett system som slår upp kunder, ordrar och artiklar kan användas av flera flöden.
- Regler. Regler för vad som alltid ska granskas, till exempel belopp över en gräns eller nya kunder, kan delas mellan flöden.
- Instruktioner. Beskrivningar av er tonalitet, era produkter och era villkor behöver bara skrivas en gång.
- Exempel och test. Testexempel för vanliga uppgifter, som att tolka en beställning, kan användas när ett nytt flöde behöver samma sak.
Ett exempel på hur återanvändning ger effekt finns i kapitlet om att skala innehållsproduktion över marknader, där samma grund används för flera språk och kanaler.
Kostnadskontroll
När antalet system växer blir kostnaden för modellanrop en verklig post. Den är sällan stor per system, men den kan växa oväntat när volymer ökar eller när ett system börjar använda en dyrare modell.
Den gemensamma grunden gör kostnaden synlig. Följ kostnaden per system och per uppgift, sätt gränser som larmar när något avviker och välj modell efter uppgift. Inte alla uppgifter behöver den största och dyraste modellen. Att sortera ett ärende kan göras av en mindre modell, medan att skriva ett komplext svar kanske behöver en större. Med en gemensam åtkomst kan det valet göras och ändras på ett ställe.
Tecken på att grunden fungerar
Hur vet ni att den gemensamma grunden gör sitt jobb? Det finns några tydliga tecken.
- Ett nytt flöde går från beslut till drift snabbare än det första gjorde.
- Ni kan svara på vilka system som skickar vilken data vart, utan att fråga runt.
- Ett modellbyte är en förändring på ett ställe, följd av automatiska tester, inte ett projekt per system.
- Ledningen får en samlad bild av effekt och kostnad för alla system.
- Ett system som börjar fungera sämre upptäcks av mätningen, inte av en kund.
Om tecknen saknas är det ofta mätningen och testerna som brister, eftersom de är minst synliga och lättast att skjuta upp.
Kompetens att bygga upp
När antalet system växer behöver organisationen också växa i kunskap. Det handlar inte om att alla ska bli tekniker, utan om att rätt personer ska förstå tillräckligt för att göra sina roller väl.
Flödesägarna behöver förstå hur man beskriver ett flöde, sätter mål och läser måtten. Granskarna behöver förstå hur systemet fungerar och hur de rapporterar problem. Ledningen behöver förstå hur kalkyl och uppföljning hänger ihop. Och den centrala funktionen behöver djup kunskap om modeller, integrationer, säkerhet och test.
Det mest effektiva sättet att bygga kompetensen är att låta den växa med systemen. Låt personer från verksamheten vara med när nästa flöde byggs, och låt dem som var med på det förra hjälpa till. Kunskap som byggs i verkliga projekt stannar bättre än kunskap från kurser.
Vanliga misstag när ni skalar
- Att skala det som inte är bevisat. Ett system som fortfarande har oklar kvalitet ska inte kopieras till fler avdelningar. Bevisa först, skala sedan.
- Att bygga en plattform för plattformens skull. Grunden ska göra flödena billigare och säkrare. Om den blir ett eget projekt utan koppling till flödena tappar den riktning.
- Att centralisera ägarskapet. När ett centralt team äger både grund och flöden försvinner kopplingen till verksamhetens resultat, och kön av önskemål växer.
- Att glömma de gamla systemen. Det första systemet byggdes innan grunden fanns. Planera in tid för att flytta över det, annars blir det det system som ingen riktigt förvaltar.
- Att mäta antalet system i stället för effekten. Tio system som ingen använder är sämre än tre som ger tydligt resultat.
Ett exempel
Ett tjänsteföretag har två system i drift: ett som sorterar inkommande kundärenden och ett som tar fram utkast till månadsrapporter. Båda fungerar, men de är byggda var för sig. När ekonomiavdelningen och säljavdelningen vill ha egna system bestämmer sig ledningen för att bygga grunden först.
De lyfter ut åtkomsten till modeller, loggningen och mätningen från de två befintliga systemen till en gemensam grund, och skriver en enkel checklista för hur ett nytt flöde tas fram. Arbetet tar några veckor och ger inga nya funktioner för användarna, vilket gör det svårt att motivera. De motiverar det med de två flöden som står på tur: utan grunden skulle varje nytt system behöva bygga samma delar igen. Två personer från det team som byggde de första systemen blir den centrala funktionen.
Det tredje systemet, för leverantörsfakturor, byggs på grunden. Det tar ungefär halva tiden jämfört med det första, och mätningen finns på plats från dag ett. När en av modellerna några månader senare byts mot en bättre och billigare, görs bytet på ett ställe och testas mot alla tre systemens exempel innan det går i drift.
Sammanfattning
- Det första systemet kan byggas för sig. Fler system kräver en gemensam grund.
- Grunden består av sex delar: åtkomst till modeller, säkerhet, loggning, mätning, test och arbetssätt.
- Bygg grunden efter det första eller andra systemet, när ni vet att fler kommer.
- Verksamheten äger flödena. En liten central funktion äger grunden.
- Prioritera öppet med samma kalkyl för alla, och återanvänd uppslag, regler, instruktioner och test.
- Gör kostnaden synlig och välj modell efter uppgift.
- Hur rollerna i organisationen förändras när AI skalar beskrivs i kapitlet om när rollerna förändras.