Bygga själva, köpa färdigt eller ta hjälp — så väljer ni väg för AI

När ett företag har bestämt sig för att automatisera ett flöde med AI kommer nästa fråga snabbt. Ska vi köpa ett färdigt verktyg, bygga något eget eller ta in någon som hjälper oss? Frågan diskuteras ofta som om den hade ett rätt svar för hela företaget. Det har den inte. Rätt svar beror på flödet, och de flesta företag kommer att använda alla tre vägarna för olika saker.

Det här kapitlet beskriver vad som skiljer de tre vägarna åt, när var och en passar och hur ni fattar beslutet för ett konkret flöde.

Tre vägar

Köpa färdigt. Ett verktyg eller en tjänst som redan finns och som ni börjar använda: en AI-funktion i ert affärssystem, ett fristående verktyg för fakturatolkning, en chattassistent för kundtjänst eller de AI-funktioner som finns i ert kontorspaket.

Bygga själva. Ett system som er egen organisation utvecklar, kopplat till era system och anpassat efter ert flöde. Det kan byggas med färdiga AI-modeller och verktyg som byggstenar, men logiken, integrationerna och förvaltningen är er.

Ta hjälp. En extern partner bygger systemet åt er, ofta tillsammans med er, och lämnar över det eller förvaltar det vidare. Det är en mellanväg där ni får ett anpassat system utan att behöva all kompetens själva från början.

När ni ska köpa färdigt

Färdiga verktyg är rätt val när flödet ser likadant ut hos många företag och verktyget passar hur ni redan arbetar.

Typiska exempel är generella uppgifter som att sammanfatta möten, skriva första utkast av texter, översätta eller söka i dokument. Det kan också vara specialiserade uppgifter som många har gemensamt, som att tolka standardiserade leverantörsfakturor eller transkribera samtal.

Fördelarna är tydliga. Det går snabbt att komma igång, kostnaden är förutsägbar och leverantören står för utvecklingen. För generella uppgifter är det ofta det klokaste valet, och det finns ingen anledning att bygga något som redan finns.

Nackdelarna visar sig när flödet inte passar verktyget. Om verktyget inte kan kopplas till era system, om det inte hanterar era undantag eller om det inte kan följa era regler, uppstår manuellt arbete runt omkring. Någon får kopiera in information, kontrollera resultat för hand eller göra om det verktyget inte klarade. Det arbetet syns sällan i jämförelsen, men det kan äta upp hela effekten.

Ställ därför tre frågor innan ni köper:

1. Kan verktyget hämta informationen från och lämna resultatet i de system där arbetet faktiskt görs?
2. Hanterar det de vanligaste undantagen i ert flöde, eller bara standardfallet?
3. Kan ni mäta kvaliteten och se varför det gjorde som det gjorde?

När ni ska bygga själva

Eget bygge är rätt val när flödet är specifikt för er verksamhet, när det är centralt för hur ni konkurrerar eller när det kräver djup integration i era system.

Exempel är orderflöden med era egna regler och kunder, offertarbete som bygger på er prissättning och ert sortiment, eller kundtjänst som behöver förstå era produkter, era avtal och er historik med kunden. Det är flöden där inget färdigt verktyg kan veta det som behövs.

Fördelarna är att systemet passar flödet exakt, att ni styr utvecklingen och att kunskapen stannar hos er. Över tid blir det en del av hur verksamheten fungerar, och det är svårt för en konkurrent att kopiera.

Nackdelarna är att det kräver kompetens, tid och förvaltning. Ett eget system behöver någon som följer upp kvaliteten, justerar när något förändras och utvecklar det vidare. Om ni saknar den kompetensen helt blir det första systemet både dyrt och långsamt, och risken är stor att det fastnar som en pilot. Hur ni undviker det beskrivs i kapitlet från pilot till drift.

När ni ska ta hjälp

Att ta hjälp är rätt val när flödet kräver ett anpassat system men ni ännu inte har kompetensen att bygga det själva, eller när ni vill komma igång snabbare än er egen organisation hinner.

Det är särskilt vanligt för det första systemet. En partner som har byggt liknande system tidigare vet var problemen brukar uppstå, hur data och integrationer brukar se ut och hur systemet ska byggas för att klara drift. Ni lär er samtidigt, och nästa system kan ni i större utsträckning göra själva.

Fördelarna är fart, erfarenhet och ett system anpassat efter ert flöde. Nackdelarna är beroendet och risken att kunskapen stannar hos partnern. Båda går att hantera, men bara om ni ställer rätt krav från början.

Krav ni ska ställa på en partner

Om ni tar hjälp, ställ följande krav. De skiljer partners som bygger system i drift från partners som bygger demonstrationer.

• De börjar i flödet. Det första samtalet ska handla om ert arbete, era volymer och era problem, inte om vilken modell de använder.
• De kan visa system i drift. Be att få se hur ett system de har byggt följs upp och förvaltas, inte bara hur det såg ut när det lanserades.
• Ni äger resultatet. Instruktioner, regler, exempel, data och kod ska vara era, och gå att lämna över till någon annan.
• De bygger för överlämning. Dokumentation, mätning och förvaltning ska vara en del av leveransen, inte ett tillägg.
• De är ärliga om osäkerheten. En partner som lovar exakta besparingar innan flödet är kartlagt vet för lite eller säger för mycket.

Ett beslutsstöd

För ett konkret flöde kan ni gå igenom fem frågor. Svaren pekar ofta tydligt åt ett håll.

1. Är flödet likt det hos många andra företag? Ja pekar mot att köpa. Nej pekar mot att bygga eller ta hjälp.
2. Kräver flödet djup integration i era system? Ja pekar mot att bygga eller ta hjälp. Nej gör det lättare att köpa.
3. Är flödet en del av hur ni konkurrerar? Ja pekar mot att bygga, med eller utan hjälp, så att kunskapen stannar hos er.
4. Har ni kompetensen att bygga och förvalta? Nej pekar mot att köpa eller ta hjälp, åtminstone för det första systemet.
5. Hur bråttom är det? Kort tid pekar mot att köpa eller ta hjälp. Eget bygge från noll tar ofta längre tid än planerat första gången.

Det är vanligt att svaren pekar åt olika håll. Då är det oftast den andra och tredje frågan som väger tyngst. Ett flöde som kräver djup integration och är en del av hur ni konkurrerar ska sällan lösas med ett generellt verktyg, även om det vore snabbare att komma igång.

Kombinationer är det vanliga

I praktiken använder de flesta företag en kombination. Generella uppgifter löses med färdiga verktyg. Centrala flöden byggs, ofta med hjälp i början. Och de egna systemen använder i sin tur färdiga byggstenar, som AI-modeller från stora leverantörer, färdiga integrationer och standardverktyg för övervakning.

Det viktiga är att kombinationen är medveten. Utan en plan växer det fram en samling verktyg som var och en löser en liten del, som inte pratar med varandra och som ingen har överblick över. Hur ni undviker det när antalet system växer beskrivs i kapitlet om att gå från ett system till tio.

Undvik inlåsning

Oavsett väg finns en risk att bli beroende av en leverantör på ett sätt som blir dyrt längre fram. AI-området förändras snabbt, och det som är bäst i dag är kanske inte det om två år.

Några principer minskar risken:

• Äg det som är ert. Instruktioner, regler, exempel och data är det som gör systemet bra för just er. De ska gå att exportera och använda någon annanstans.
• Separera modellen från logiken. Bygg så att den underliggande AI-modellen kan bytas utan att hela systemet behöver göras om.
• Mät själva. Om ni har egna mått och egna testexempel kan ni jämföra alternativ på riktigt, i stället för att lita på leverantörens beskrivning.
• Skriv det i avtalet. Vad händer med data, kod och dokumentation om samarbetet upphör? Det är en enkel fråga att ställa i början och en svår fråga att lösa i slutet.

Vad det betyder för IT

Oavsett väg behöver IT vara med tidigt. Inte för att äga flödet, det ska verksamheten göra, utan för att säkerhet, åtkomst, integrationer och drift behöver fungera.

För färdiga verktyg handlar det om att granska var data behandlas, vilka behörigheter verktyget får och hur det passar in i befintliga avtal. För egna system och system byggda med en partner handlar det också om var systemet körs, hur det övervakas och vem som larmas när något slutar fungera.

Ett vanligt problem är att verksamheten köper eller bygger något på egen hand, och att IT får veta när det redan används. Det skapar både säkerhetsrisker och onödiga konflikter. Det motsatta problemet är lika vanligt: att IT blir en flaskhals som ska godkänna allt utan att ha tid. Lösningen är enkla, gemensamma regler för vad som kräver granskning och vad som inte gör det, så att små saker kan gå snabbt och stora saker blir rätt.

Kostnaden över tid

En sista sak att tänka på är hur kostnaden utvecklas. Färdiga verktyg har ofta låg startkostnad men en kostnad per användare eller per transaktion som växer med användningen. Egna system har högre startkostnad men lägre marginalkostnad när de väl är byggda. En partner hamnar ofta däremellan, med en kostnad för bygget och en löpande kostnad för förvaltningen.

Räkna därför på mer än det första året. Ett verktyg som är billigast i dag kan vara dyrast om tre år om volymen växer. Ett eget system som verkar dyrt kan vara billigast över tid om det används i många flöden. Hur ni räknar beskrivs i kapitlet om att räkna på ett AI-projekt.

Ett exempel

Ett medelstort företag inom industrihandel har tre flöden på listan.

Det första är mötesanteckningar och sammanfattningar för säljteamet. Det är generellt, ser likadant ut hos alla och kräver ingen djup integration. De köper ett färdigt verktyg och har det igång på en vecka.

Det andra är orderhantering, där beställningar kommer in i många format och ska matchas mot ett sortiment med tiotusentals artiklar och kundspecifika priser. Det är specifikt, kräver integration och är en del av hur de konkurrerar med snabb leverans. De har ingen egen AI-kompetens. De tar hjälp av en partner för det första systemet, med kravet att en egen person ska vara med hela vägen och kunna förvalta det efteråt.

Det tredje är svar på tekniska produktfrågor från kunder. Det kräver tillgång till produktdokumentationen och historiken med kunden. När orderflödet är i drift har de egen person med erfarenhet, och de bygger det tredje flödet själva med samma grund.

Tre flöden, tre vägar. Och en tydlig riktning: att bygga egen kompetens gradvis, med hjälp där det behövs.

Sammanfattning

• Det finns inget rätt svar för hela företaget. Välj väg för varje flöde.
• Köp färdigt när flödet är generellt och verktyget passar hur ni arbetar.
• Bygg själva när flödet är specifikt, centralt och kräver djup integration, och ni har kompetensen.
• Ta hjälp när flödet kräver ett anpassat system men kompetensen inte finns än, och ställ krav på ägarskap och överlämning.
• Kombinera medvetet, undvik inlåsning och räkna på kostnaden över flera år.
• Hur ni designar kontrollpunkterna i det ni bygger beskrivs i kapitlet om människan i loopen.