AI-implementering: därför fastnar så många projekt efter piloten

AI-implementering är arbetet med att ta en AI-lösning från idé till något som används i den dagliga verksamheten. Det svåra är sällan att få något att fungera i en demo. Det svåra är steget efter: att få lösningen in i de system och arbetssätt som verksamheten faktiskt använder, och att få den att stanna där.

Många företag känner igen mönstret. En pilot sätts upp, den visar lovande resultat, alla är nöjda – och sedan händer ingenting. Den här artikeln går igenom sju vanliga orsaker till att AI-projekt fastnar efter piloten och vad ni kan göra annorlunda från början.

Varför piloten inte är problemet

En pilot är bra. Den låter er pröva en idé utan att binda upp er. Problemet uppstår när piloten byggs som ett experiment snarare än som första versionen av något som ska användas. Då bevisar den att tekniken fungerar, men inte att den fungerar hos er, i era system, för de människor som ska använda den.

Skillnaden låter liten men avgör allt. En pilot som är byggd för att gå i drift har svar på frågorna om data, integration, ägarskap och mått redan från dag ett. En pilot som inte är det får svara på dem efteråt – och det är där projekten stannar.

Sju orsaker till att AI-projekt fastnar

1. Piloten byggdes på exempeldata

En demo på leverantörens exempeldata visar vad lösningen klarar i idealfallet. Den visar inte hur den hanterar era produktnamn, era interna förkortningar, era undantag och hur era kunder formulerar sig. När lösningen möter den riktiga datan sjunker träffsäkerheten, och förtroendet med den.

Gör så här: Testa på er egen data från början, även om det tar längre tid att komma igång.

2. Ingen bestämde vad som skulle bli bättre

Utan ett mått går det inte att säga om piloten lyckades. "Det kändes bra" räcker inte för att motivera en investering i drift. Då blir beslutet att skjuta på beslutet.

Gör så här: Bestäm innan start vad som ska förbättras – tid per ärende, svarstid, antal manuella moment – och mät nuläget. Varför det avgör utfallet utvecklar vi i AI som inte mäts är bara en förhoppning.

3. Ingen äger lösningen

Piloten drevs av en entusiast eller av IT. När den är klar finns ingen i verksamheten som ansvarar för att den används, förbättras och följs upp. Lösningen blir föräldralös.

Gör så här: Utse en ägare i verksamheten – den som har problemet – innan ni bygger.

4. Integrationen sköts upp

I piloten räckte det att klistra in text eller ladda upp en fil. I drift måste lösningen hämta och lämna uppgifter i de system ni redan använder: e-posten, affärssystemet, CRM:et. Den delen är ofta större än själva AI-delen, och när den upptäcks sent spricker tidsplanen.

Gör så här: Ta med minst en riktig integration redan i prototypen, så att ni vet vad som krävs.

5. Säkerhet och juridik kom in för sent

När piloten ska i drift ställer någon frågan om var datan lagras, vilka personuppgifter som behandlas och vem som har åtkomst. Saknas svaren stannar allt medan de tas fram.

Gör så här: Ta frågorna om dataskydd och åtkomst i kartläggningen, innan något byggs. Mer om det i var er AI-data bor.

6. Projektet var för brett

"Vi ska införa AI i hela kundtjänsten" är svårare att lyckas med än "vi ska sortera fakturamejlen automatiskt". Ett brett projekt har många intressenter, många undantag och inget tydligt slut.

Gör så här: Börja med ett avgränsat flöde som återkommer ofta och går att mäta. Bygg vidare när det fungerar.

7. De som skulle använda den var inte med

En lösning som byggts utan dem som ska använda den möter motstånd, ofta med goda skäl. Den passar inte hur arbetet faktiskt går till, eller så förstår användarna inte varför den gör som den gör.

Gör så här: Låt användarna testa prototypen i sin vardag och ändra efter vad de säger. En lösning som förklarar sina förslag är också lättare att lita på.

En AI-implementering som är byggd för drift

Det vi har lärt oss av att ta lösningar hela vägen till drift är att ordningen spelar roll. Vi arbetar i tre steg:

1. Kartläggning, 1–2 veckor. Vi går igenom era flöden, system och var tiden försvinner. Ni får en skriftlig rapport med vad som är värt att bygga – och vad som inte är det.
2. Prototyp, 2–4 veckor. Vi bygger en fungerande prototyp som ni testar på er egen data och i er vardag. Säger ni stopp där är ni inte låsta vid något.
3. Drift. Lösningen integreras med era system och vi tar löpande ansvar, till fast månadspris utan bindningstid.

Det viktiga är inte stegen i sig, utan att prototypen redan från början är första versionen av det som ska i drift. Data, integration, ägare och mått bestäms i kartläggningen – inte efter piloten. Hela arbetssättet beskriver vi i vår metod för AI-implementering.

Kulturen spelar också roll

Ibland fastnar projekt av skäl som inte har med tekniken att göra alls. Ingen vill ta beslutet att gå vidare, eftersom ingen vill stå som ansvarig om det blir fel. Vi har skrivit om det mönstret i mitokratin – när rädslan för att göra fel styr ert företag. Ett tydligt mått och en tydlig ägare är det bästa motgiftet: då handlar beslutet om siffror, inte om mod.

Vanliga frågor

Hur lång tid tar en AI-implementering?

Det beror på hur stor lösningen är och hur många system den ska kopplas till. En avgränsad lösning är oftast i drift på 4–6 veckor, en större på 8–12. Den största tidstjuven är sällan själva bygget, utan beslut och integrationer som skjuts upp.

Ska vi börja med en färdig AI-tjänst eller bygga eget?

Börja med problemet. Finns det en färdig tjänst som löser det bra är det ofta rätt start. Är problemet specifikt för er – era system, era undantag, ert språk – blir en anpassad lösning ofta både bättre och billigare i längden. Vi har jämfört alternativen i skräddarsydd AI slår hyllvara när problemet är ert eget.

Vem i organisationen ska äga AI-implementeringen?

Den som har problemet som ska lösas, inte IT eller en extern konsult. IT och leverantören behövs, men det är verksamheten som avgör om lösningen gör nytta och ser till att den används.

Vad gör vi om piloten inte når målet?

Då har piloten gjort sitt jobb: ni vet något ni inte visste, till en bråkdel av kostnaden för ett helt projekt. Det är just därför prototypen ska testas på er egen data och mot ett mått – ett tydligt nej är också ett resultat.

Nästa steg

Har ni en pilot som har fastnat, eller en idé ni vill pröva utan att den fastnar? Boka ett samtal, så går vi igenom vad som behövs för att ta den hela vägen till drift.