AI

Så ser en AI-readiness-granskning ut i praktiken

Av reza kalate
Dela:

En företagare vi pratade med hade redan försökt "satsa på AI" en gång tidigare. Hon hade tecknat ett abonnemang på en chatbot, kopplat den till hemsidan och pekat den mot sitt produktsortiment. Tre månader senare svarade den rätt på kanske var tredje kundfråga och blev i praktiken ignorerad resten av tiden. Hennes slutsats blev att AI helt enkelt inte var moget för ett företag i hennes storlek. Det verkliga problemet var att ingen någonsin hade undersökt om hennes företag var redo för AI – det chatboten behövde känna till fanns utspritt över en prislista i PDF-format, en inkorg på Facebook och en enda anställds minne. Ingen mängd AI-modellkvalitet i världen löser det. Det är precis det glappet en AI-readiness-granskning ska täppa till, och det är värt att förstå vad en sådan granskning faktiskt innebär innan ni lägger pengar på vare sig granskningen eller automationen i sig.

Readiness handlar inte om att ha ett eget dataanalysteam

De flesta små och växande företag hör "AI-readiness" och antar att det är en ribba de aldrig kommer över – att det kräver ett datalager, ett analysteam eller åratal av städad historik. Så är det inte. Readiness för ett första användbart AI-projekt handlar om tre betydligt blygsammare saker: data som är tillräckligt ren (inte perfekt, bara konsekvent och tillgänglig), processer som är tillräckligt tydliga för att en människa ska kunna rita upp dem i ett flödesschema, och ett konkret problem värt att lösa – inte en vag ambition om att "använda AI någonstans".

Den sista punkten fäller fler företag än de andra två tillsammans. "Vi vill använda AI" är inte ett projekt. "Vi vill sluta skriva av orderuppgifter för hand från mejl till vårt ordersystem" är ett projekt. Granskningens egentliga uppgift är att hitta den andra meningen, för allt som kommer efter – den tekniska lösningen, kostnaden, tidsplanen – bygger helt och hållet på att först bli specifik.

Så går en riktig readiness-granskning till

Skala bort säljarnas powerpoints och kvar blir en kort, strukturerad genomgång i fem steg. Den ska inte ta veckor, och den ska inte kräva att ni fyller i ett fyrtio frågor långt formulär om er "digitala mognad". Den ska se ut som att någon sätter sig ner med de personer som faktiskt utför arbetet.

1. Kartläggning av arbetsflöden och flaskhalsar

Det här börjar med samtal, inte enkäter. Var fastnar arbetet? Vad tar längre tid än det borde? Vad görs manuellt varje enda dag och känns repetitivt? En bra granskning pratar med de som faktiskt utför uppgiften – personen som hanterar fakturor, personen som sorterar supportärenden – inte bara med ägarens bild av hur processen går till. De två bilderna skiljer sig ofta förvånansvärt mycket åt, och glappet mellan dem är oftast där den verkliga friktionen finns.

2. Koll på datakvalitet och var informationen egentligen finns

Det här är den oglamorösa delen som avgör om något överhuvudtaget kommer att fungera i nästa steg. Ligger kunddatan i ett enda CRM-system, till exempel Visma eller Fortnox, eller är den utspridd mellan CRM-systemet, ett kalkylark som någon underhåller "för säkerhets skull" och en delad inkorg? Är produktregistren konsekventa, eller har samma vara tre olika namn i tre olika system? Ett AI-system är aldrig bättre än det underlag det faktiskt kan läsa av, och det här steget visar om den grunden finns än.

3. Att hitta den mest värdefulla automationskandidaten

Nästan alla företag har fem, sex processer som känns automatiserbara. En seriös granskning motstår lockelsen att ta sig an alla på en gång. Istället rangordnas kandidaterna efter en enkel formel: hur mycket tid eller pengar kostar det här idag, multiplicerat med hur genomförbart det är att faktiskt automatisera givet den data och de system som är inblandade. Vinnaren är sällan den mest spektakulära idén – det är den tråkiga, högfrekventa uppgiften som tyst äter upp timmar varje vecka.

4. En teknisk genomförbarhetskontroll

När det finns en kandidat behöver någon teknisk person ställa obekväma frågor. Har systemet ett API, eller skulle det här kräva skärmskrapning av ett gammalt system som kan gå sönder när som helst? Är bedömningen som ingår i uppgiften regelbaserad, eller beror den på sammanhang som en modell skulle behöva massor av exempel för att lära sig? Det här steget är det som skiljer "vi borde kunna bygga det här" från "vi kan bygga det här", och det är här många entusiastiska idéer landar på en rimlig nivå.

5. En grov uppskattning av kostnad och tidsram

Inte en formell offert – en riktningsvisande siffra. Är det här ett tvåveckorsprojekt eller ett som tar två kvartal? Kräver det löpande underhåll, eller är det närmare ett skript man bygger en gång och sedan lämnar? Det ger tillräckligt underlag för att bestämma om ni ska gå vidare, lägga idén på is, eller strukturera om den till något mindre och billigare att bevisa först.

Det här brukar företag bli förvånade över

Själva granskningen är sällan det förvånande – det är det den avslöjar. Ett par upptäckter dyker upp så pass ofta att de förtjänar att nämnas direkt.

  • Datan är utspridd över fler verktyg än någon insett. Det är vanligt att ett företag tror att kundinformationen "finns i CRM-systemet" och sedan upptäcker, när någon faktiskt spårar den, att en betydande del av de beslutsrelevanta uppgifterna istället lever i mejltrådar, en bokförares kalkylark eller en kollegas anteckningsapp. Inget av det är användbart för ett AI-system förrän det först har samlats ihop, vilket är ett projekt i sig.
  • En process alla trodde var automatiserbar visar sig kräva mänskligt omdöme. Sortering av supportärenden är klassikern. På avstånd ser den regelbaserad ut – "de här orden betyder återbetalning, de här betyder frakt" – men i praktiken är den full av gränsfall, tonläsning och sammanhang som en person tar in utan att tänka på det. Att automatisera den fullt ut leder ofta till en sämre upplevelse, inte en bättre.
  • Det omvända händer minst lika ofta. En uppgift som kändes för nyanserad för att lämna över – säg, att kategorisera och fördela inkommande leads utifrån en lång lista kriterier – visar sig vara en nästan perfekt automationskandidat när den väl kartläggs, för det "omdöme" som var inblandat handlade egentligen bara om att tillämpa samma tolv regler konsekvent, vilket är precis vad ett välbyggt system gör bättre än en trött människa en fredag klockan fyra.

Inget av det här är dåliga nyheter. Det är själva poängen med att göra granskningen innan bygget – att upptäcka vilka antaganden som är fel kostar några dagars utredning istället för månader av bortkastad utveckling.

Är ni redo nu, eller behövs det grundarbete först?

Det är den fråga granskningen till syvende och sist besvarar, och det ärliga svaret är ofta "inte riktigt än, men närmare än ni tror". Några signaler pekar åt varje håll.

Ni är sannolikt redo att sätta igång nu om: processen ni vill automatisera har tydliga, konsekventa indata; datan den bygger på finns i ett eller två system snarare än sex; och ni kan beskriva det önskade resultatet i en mening som en nyanställd skulle kunna följa. Kvalificering av leads baserat på formulärsvar som redan flödar in i ett enda verktyg är ett bra exempel – datan finns, logiken går att beskriva, och vinsten är konkret.

Ni behöver förmodligen grundarbete först om själva datan är problemet. Ett vanligt fall: ett företag vill ha AI-driven leadpoängsättning, men CRM-systemet har år av inkonsekventa registreringar, dubbletter av kontakter och fält som olika medarbetare använder olika. Att bygga en poängsättningsmodell ovanpå det är inget AI-problem – det är ett datastädningsproblem i AI-förklädnad. I det läget är rätt första projekt ofta oglamoröst: standardisera CRM-systemet, definiera vad fälten faktiskt betyder, och få några månaders konsekvent dataflöde innan ni lägger något förutsägande ovanpå. Det är mindre spännande än "vi bygger en AI-funktion", men det är skillnaden mellan ett system som fungerar och ett som producerar självsäkert låtande nonsens från dag ett.

Samma instinkt som borde göra er försiktiga kring en datagrund borde göra er försiktiga kring vem ni anlitar för att bedöma den. När vi skrev om hur man väljer rätt webbyrå var kärnrådet att titta förbi säljpitchen och fråga om det faktiska arbetssättet – hur de avgränsar uppdrag, hur de kommunicerar, vad som händer när något inte går som planerat. Samma frågor gäller en AI-partner, kanske ännu mer, eftersom felen där är tystare. En webbyrå som säljer in för mycket levererar oftast en synligt trasig hemsida. En AI-partner som säljer in för mycket levererar ett system som ser ut att fungera medan det tyst fattar dåliga beslut i bakgrunden. Be att få se hur de faktiskt skulle genomföra granskningen, inte bara vad de lovar att leverera på slutet.

Vad ni ska göra med resultatet

En bra readiness-granskning slutar med ett beslut, inte bara en rapport. Ibland är beslutet "bygg det här specifika, ungefär så mycket kostar det och så lång tid tar det". Ibland är det "inte än – städa upp X först, och ta upp det igen sedan". Båda är legitima, användbara utfall, och vilketdera som helst är mer värt än att hoppa rakt till ett bygge driven enbart av entusiasm. De företag som får ut mest av AI är inte de som rörde sig snabbast – det är de som lade några dagar på att räkna ut exakt var de skulle rikta det innan de skrev en enda rad kod.

Om ni försöker räkna ut om ert företag genuint är redo för ett AI-projekt, eller vilken av era befintliga processer som faktiskt skulle vara en bra första kandidat, börjar vårt arbete inom AI-tjänster med precis den här typen av granskning – ingen press att binda er till ett bygge förrän vi båda har sett hur datan och arbetsflödena faktiskt ser ut. Hör av er om ni vill prata igenom var ert företag står.

Du kanske också gillar