Det viktigaste först
Välj en uppgift som återkommer och ett resultat som går att kontrollera. Beskriv även undantagen. Jämför en befintlig funktion, en integration och ett eget verktyg innan du bestämmer om AI behövs.
Skriv ned en uppgift från början till slut
Börja med något som faktiskt tar tid i vardagen: en produktuppdatering, en offertförfrågan eller en beräkning som görs ofta. Följ ett verkligt ärende och skriv ned varje steg. Var kommer uppgifterna ifrån, vem gör arbetet och vart skickas resultatet?
Ett konkret underlag gör det lättare att se om problemet är dubbel inmatning, otydliga regler eller information som saknas. De problemen behöver olika lösningar.
- Hur ofta görs uppgiften och hur lång tid tar ett normalt ärende?
- Vilka system, dokument och personer behövs?
- Vilka undantag kräver en mänsklig bedömning?
- Hur ser ni att resultatet är korrekt?
Välj mellan en funktion, en integration och ett eget verktyg
Kontrollera först om systemet redan har en funktion för uppgiften. En mall, import eller bättre inställning kan räcka. Om samma information måste finnas i flera system är nästa fråga hur den ska föras över och vilket system som bestämmer när uppgifterna skiljer sig åt.
Ett eget verktyg blir intressant när era regler eller kundval inte ryms i en befintlig funktion. I TJB:s kalkylator kopplas mått och produktregler till produkter och materiallistor. Mitt arbete omfattade databas, API, beräkningsregler och tester. Det är ett exempel på regelstyrd utveckling, inte ett påstående om en AI-lösning.
Var passar AI in?
AI kan vara ett alternativ när uppgiften innehåller ostrukturerad text, som att sortera frågor eller ta fram ett förslag som någon sedan granskar. En beräkning som ska följa ett bestämt regelverk behöver däremot ge rätt resultat varje gång; där börjar man med tydliga regler och testfall.
Jämför ett avgränsat AI-test med ert nuvarande arbetssätt. Räkna även tiden för granskning och rättningar. Bestäm i förväg vilka uppgifter som får användas, när ett svar måste stoppas och vem som ansvarar för att det blir rätt.
Ta bort ett onödigt steg före en stor ombyggnad
Ibland kan en liten ändring lösa det mest irriterande dubbelarbetet. För Sharkhead arbetade jag med en offertfunktion som skickar med uppgifter om produkten kunden har valt. Kunden behöver då inte själv återskapa produktinformationen i ett allmänt meddelande.
Samma fråga är användbar i andra flöden: vilka uppgifter har vi redan, och varför ber vi någon skriva dem igen? Kontrollera vilka uppgifter mottagaren faktiskt behöver innan fler fält eller system läggs till.
Prova även det som går fel
En demonstration med perfekta indata räcker inte som underlag för drift. Samla ett litet urval av normala och besvärliga fall. Använd testuppgifter som är lämpliga att dela och undvik att kopiera kundregister till nya verktyg bara för att prova.
Bestäm vad som ska hända om kopplingen bryts eller informationen är ofullständig. Resultatet behöver gå att kontrollera, och någon måste veta att ett ärende inte blev klart.
- Saknad uppgift: stoppa eller be om komplettering.
- Dubblett: kontrollera att samma ärende inte behandlas två gånger.
- Systemet svarar inte: visa felet och ha en rutin för ett nytt försök.
- Felaktigt resultat: kunna rätta det och följa vad som ändrats.
Följ upp tid, kvalitet och ansvar
Mät samma typ av uppgift före och efter. Anteckna handläggningstid, antal rättningar och hur många ärenden som behöver manuell hjälp. En snabb automatisk körning är inte en besparing om granskningen tar längre tid än det tidigare arbetet.
Räkna också med drift, licenser och underhåll. Vem uppdaterar kopplingen om ett annat system ändras? Vem får ändra reglerna? Börja med en avgränsad leverans och bygg vidare när ni kan visa att den hjälper.
