Tre frågor vi ställer till styrelsen innan vi börjar bygga

Det händer ungefär en gång i månaden. Vi sitter i ett konferensrum, oftast någonstans i norra Sverige, ibland digitalt med en VD som ringer in från bilen. På bordet ligger en halvfärdig kravspecifikation och en PowerPoint med rubriken "AI-strategi 2026". Stämningen är positiv. Alla vill framåt. Och det är precis i det ögonblicket vi bromsar.

Inte för att vi inte tror på projektet. Utan för att vi vet vad som händer om man börjar bygga utan att ha svarat på tre specifika frågor. Vi har sett det tillräckligt många gånger. Ett pilotprojekt som levererar imponerande demos men aldrig når produktion. En integration som fungerar tekniskt men som ingen i organisationen förstår eller äger. En investering på några hundra tusen som rinner ut i sanden, inte för att tekniken var fel, utan för att ingen ställde de obekväma frågorna i början.

De här tre frågorna är inte tekniska. De handlar inte om modellval, infrastruktur eller dataformat. De handlar om vad organisationen faktiskt är beredd att förändra. Och de avgör, nästan varje gång, om projektet blir något som lever kvar eller något som bara blev en intressant övning.

Vad är ni beredda att göra av med om det fungerar

Den här frågan skapar nästan alltid en kort tystnad. Inte för att den är provocerande, utan för att den avslöjar något som sällan diskuteras öppet. Om en AI-lösning verkligen fungerar, om den faktiskt gör det den ska, då förändras saker. Processer som idag tar två dagar kanske tar tjugo minuter. Roller som idag handlar om manuell granskning kanske behöver omdefinieras. Beslut som idag fattas av en avdelningschef kanske kan fattas automatiskt, eller åtminstone förberedas så att beslutet bara tar sekunder.

Vi hade ett uppdrag förra året med ett medelstort industribolag som ville automatisera sin offertprocess. De tog emot förfrågningar via mejl, en handläggare läste igenom underlaget, stämde av mot lagersaldo och prislista, och skickade tillbaka en offert. Hela flödet tog i snitt fyra timmar. Lösningen vi byggde kunde hantera åttio procent av alla förfrågningar helt automatiskt, från inkommen mejl till färdig offert, på under tre minuter.

Men det intressanta var inte tekniken. Det intressanta var vad som hände i organisationen. De tre handläggare som tidigare ägnade merparten av sin tid åt rutinofferter fick plötsligt tid över. Frågan var: till vad? Vi hade den diskussionen innan vi skrev en enda rad kod. Styrelsen bestämde att handläggarna skulle fokusera på komplexa offerter och kundrelationer, något de aldrig hade haft tid för. Det beslutet, fattat innan projektet startade, var det som gjorde att lösningen faktiskt landade i organisationen utan friktion.

Om svaret på frågan är "ingenting, vi vill bara lägga till AI ovanpå det vi redan gör", då är det inte nödvändigtvis fel. Men det begränsar kraftigt vad man kan åstadkomma, och det är bättre att veta det från början än att upptäcka det efter tre månaders utveckling.

Hur mäter vi att det fungerar om sex månader

Det finns en vanlig fälla som vi ser upprepas. Ett projekt definieras med formuleringar som "effektivisera kundtjänst" eller "förbättra datakvaliteten" eller, den absolut vanligaste, "vi vill testa AI". Ingen av dessa är ett uppdrag. De är önskemål. Och det är stor skillnad.

Ett uppdrag har ett mätbart utfall. Inte nödvändigtvis ett exakt tal, men åtminstone en riktning och ett tidsfönster. "Vi vill minska genomsnittlig hanteringstid för reklamationsärenden från fyra dagar till en dag inom sex månader" är ett uppdrag. "Vi vill bli bättre på att hantera reklamationer med hjälp av AI" är det inte.

Vi insisterar på den här distinktionen av en väldigt praktisk anledning. Om det inte finns ett överenskommet sätt att mäta om lösningen fungerar, då finns det heller inget sätt att veta om den är värd att behålla. Och det leder nästan alltid till att lösningen antingen avvecklas tyst efter några månader, eller att den lever kvar utan att någon egentligen vet vad den bidrar med.

Vi brukar föreslå en enkel modell. Välj ett eller två nyckeltal som redan mäts i verksamheten, sådant som finns i ert affärssystem eller CRM. Dokumentera nuläget innan projektet startar. Bestäm ett rimligt mål, inte en fantasi utan en konkret förbättring som känns ambitiös men möjlig. Och bestäm redan nu vem som tittar på siffrorna och hur ofta. Det låter trivialt, men i praktiken är det detta som avgör om projektet har en framtid efter att vi har levererat.

Vi gjorde ett projekt åt en fastighetsförvaltare som ville använda AI för att kategorisera och prioritera felanmälningar. Fint. Men det var först när vi satte oss ner och definierade att målet var att minska andelen felaktigt prioriterade ärenden från tjugotre procent till under tio procent, mätt genom stickprov varannan vecka, som projektet fick verklig riktning. Plötsligt kunde vi designa lösningen mot ett specifikt mål istället för en vag ambition.

Vem är ägaren när vi går hem

Den tredje frågan är kanske den viktigaste, och den som oftast saknar svar. Vi är konsulter. Vi bygger, vi levererar, vi lämnar över. Men till vem? Om svaret är "IT-avdelningen" utan att någon specifik person har accepterat ansvaret, då vet vi redan att lösningen kommer att förfalla. Om svaret är "vi tar det sen", då vet vi att det aldrig blir löst.

Det handlar inte om att vi vill skapa beroende eller att vi vill ha långa avtal. Tvärtom. Hela vår modell bygger på att vi bygger något som organisationen sedan kan förvalta själv. Men det kräver att någon faktiskt tar ägarskapet, någon med mandat att fatta beslut om lösningen, budget att underhålla den, och tillräcklig förståelse för att veta när något behöver justeras.

Vi brukar kalla det "intern champion" internt. Det behöver inte vara en teknisk person. Det kan vara en verksamhetschef som förstår problemet lösningen adresserar, eller en projektledare som redan koordinerar liknande initiativ. Det viktiga är att personen finns, att den vet att det är hennes eller hans ansvar, och att det är överenskommet innan projektet startar.

Vi har tyvärr sett vad som händer utan en ägare. En distributör i Mellansverige implementerade ett system för automatisk lageroptimering. Tekniken fungerade. Prognoserna var bättre än de manuella. Men ingen i organisationen hade ansvar för att agera på prognoserna. Sex månader senare var systemet avstängt. Inte för att det inte fungerade, utan för att det inte hade en plats i organisationsstrukturen.

Varför "vi vill testa AI" inte räcker som uppdrag

Vi hör den formuleringen ofta. "Vi vill testa AI." Ibland med tillägg som "vi vill inte hamna efter" eller "konkurrenterna gör det redan". Och vi förstår impulsen. Det finns en genuin oro för att missa något, att vara för långsam, att konkurrenterna ska automatisera sig förbi en.

Men "vi vill testa AI" är ungefär lika användbart som att säga "vi vill testa elektricitet". Det saknar kontext. Vilken del av verksamheten? Vilket problem? Vilken volym? Vilken risknivå? Utan de parametrarna bygger man i bästa fall en intressant prototyp, i sämsta fall något som kostar pengar utan att svara på någon reell fråga.

När vi möter den formuleringen brukar vi backa ett steg. Vi frågar: vad i er vardag tar för lång tid, kostar för mycket, eller fungerar inkonsekvent? Det behöver inte vara ett stort problem. Ofta hittar vi de bästa första projekten i ganska odramatiska processer. Fakturahantering, dokumentsortering, kvalitetskontroll, schemaläggning. Saker som görs hundratals gånger i veckan och där varje timme som sparas multipliceras snabbt.

Poängen är inte att avfärda nyfikenhet. Nyfikenhet är bra. Men nyfikenhet utan riktning leder till piloter som aldrig lämnar pilotfasen. Och det är dyrt, inte bara i pengar utan i förtroende. Varje misslyckad pilot gör nästa AI-initiativ svårare att förankra internt.

Skillnaden mellan pilot och produktionssystem

Det finns en subtil men avgörande skillnad mellan att visa att något kan fungera och att faktiskt drifta det i en verksamhet. En pilot bevisar ett koncept. Den kör på testdata, i en kontrollerad miljö, ofta med en av oss som sitter bredvid och justerar. Och det är helt rätt. Piloter fyller en viktig funktion. De minskar risk, de skapar underlag för beslut, de ger organisationen en möjlighet att känna på tekniken innan man förbinder sig.

Men en pilot är inte ett produktionssystem. Ett produktionssystem hanterar felaktiga indata utan att krascha. Det fungerar när den person som byggde det inte längre är tillgänglig. Det har övervakning som larmar när något avviker. Det har dokumentation som gör att en ny medarbetare kan förstå vad systemet gör. Det har en plan för vad som händer när förutsättningarna förändras, för det gör de alltid.

Vi ser regelbundet organisationer som fastnar i det vi kallar "evig pilot". Projektet levererade en demo som imponerade på ledningsgruppen. Alla var nöjda. Men sedan hände ingenting. Ingen hade budgeterat för att ta piloten till produktion. Ingen hade planerat för integrationer mot befintliga system. Ingen hade tänkt på drift, övervakning eller underhåll. Och så står man där, med en lysande prototyp som ingen använder.

Det är därför vi redan i första mötet pratar om vad som händer efter piloten. Inte för att piloter är dåliga, utan för att beslutet att gå vidare till produktion måste vara fattat i princip innan piloten startar. Annars blir piloten ett mål i sig, och det var aldrig meningen.

Det som avgör innan koden skrivs

De tre frågorna hänger ihop. Om du vet vad du är beredd att förändra, har du riktning. Om du vet hur du mäter framgång, har du en målbild. Om du vet vem som äger lösningen, har du kontinuitet. Utan någon av de tre delarna faller helheten isär, inte alltid omedelbart, men nästan alltid inom ett år.

Det kanske låter som att vi gör det svårt för oss själva. Att vi avskräcker potentiella kunder med obehagliga frågor. Ibland gör vi nog det. Men de organisationer som tar sig igenom de här samtalen och landar i tydliga svar bygger saker som faktiskt förändrar verksamheten. Inte för att tekniken är magisk, utan för att förutsättningarna var på plats från dag ett.

Om du sitter med ett AI-initiativ som känns lite vagt, börja med de tre frågorna. Inte som en formell workshop, utan som ett ärligt samtal med de personer som har mandat att svara. Du behöver inga tekniska förkunskaper. Du behöver bara vara villig att prata om vad som faktiskt ska förändras, och vara ärlig om svaren.