Kladdigt in, krispigt ut

Två ord som ersatte ett processdokument

Kladdigt in, krispigt ut. Det är metodnamnet. Det är inte en metafor — det är en beskrivning av exakt vad som händer när en domänexpert spelar in sina tankar fritt och vi levererar ett fungerande analysverktyg dagar senare.

Insikten kom ur ett samtal om en leverans. En projektdeltagare beskrev sina egna inspelningar som "kladdigt ljudbludder" — menat något nedsättande. Vi invände. Det kladdiga ljudbludret var råmaterialet. Det innehöll precis det som ett kravdokument hade rensat bort: tvekan, omformuleringar, sidospår, halvfärdiga meningar som avslöjar komplexitet. Ju mer kladd, desto bättre kontext för AI att tolka.

Det är inputkalibreringen som avgör allt. Och det är den vi nu undervisar explicit.

Varför kravdokument misslyckas

BI-verktyg ställer ett krav som verkar rimligt: ren data. Innan man kan visualisera något måste data tvättas, struktureras, valideras. Det projektet i sig tar månader. Och när det är klart har behoven förändrats.

Traditionell kravspecifikation ställer ett annat krav som också verkar rimligt: precision. Definiera vad du vill ha innan du börjar bygga. Problemet är att domänexperter inte vet hur de ska formulera vad de vill ha i tekniska termer. De vet vad de vill se. Att omsätta det till specifikationstext tar veckor och resulterar i dokument som missar det som faktiskt var viktigt — det som framkom i halvmeningarna och sidospåren.

"Evig resa till ren data" är vad en projektdeltagare kallade det. Infrastrukturprojektet före infrastrukturprojektet. Innan du kan börja bygga verktyget måste du bygga förutsättningarna. Det tar längre tid än verktyget.

Vi vänder på logiken. AI tolkar datat semantiskt — det kräver inte ren data, det kräver befintlig data. Och inputen till processen behöver inte vara ett kravdokument, den behöver vara domänexpertens faktiska tänkande, fångat när det är som tätast.

De två inputlägena

Det finns en distinktion som vi nu gör explicit i varje uppdrag.

Kladdigt input är när konsulten eller domänexperten inte har ett strikt mål. De beskriver fritt: vad de vill förstå, vad de sett, vilka frågor de inte kan svara på. "Vi vill kunna se var arbete fastnar... alltså, det handlar om att förstå flödet... ibland stannar saker i review för länge, ibland är det prioriteringar som ändras mitt i... och sen är det det här med att folk jobbar på för många saker samtidigt." Det är kladdigt input. Inget strikt mål. AI välkomnas att tolka, anta, inferera.

Krispigt input är något annat. Det är när man vet exakt vad man vill ha. "Lägg till ett fält för ärendetyp." "Ta bort den här metriken, den förstår inte våra kunder." "Kan vi se samma data men uppdelat per team?" Inga antaganden välkomnas. AI applicerar präcist.

Knisprigt är övergången — när kladdigt material har tolkats tillräckligt för att nästa steg ska vara chirurgiskt. En projektdeltagare hittade ordet spontant mitt i ett samtal. Det rymmer båda lägen: organisk origin, precist resultat.

I praktiken ser ett uppdrag ut så: kladdigt i specifikationsfasen, sedan knisprigt i iterationerna. Man börjar med att svamla fritt om vad man vill förstå, sedan korrigerar man och preciserar baserat på vad man faktiskt ser.

Processen i fem steg

Konsulten spelar in sitt tänkande muntligt — medvetet ostrukturerat, med alla nyanser och osäkerheter intakta. Det är kladdigt input av en anledning: tvekan avslöjar vad som är oklart, omformuleringar visar var problemet är komplext, sidospår innehåller kontext som aldrig hade hamnat i ett dokument. Inspelningen transkriberas och analyseras.

AI genererar följdfrågor baserat på oklarheter och antaganden: vad menar ni med "fastnar"? Vilka statusar signalerar väntan? Hur definierar ni "för lång tid"? Konsulten svarar muntligt igen — fortfarande kladdigt. Varje svar genererar mer specifika frågor. Efter tre-fyra rundor finns en implicit specifikation som fångade vad de faktiskt menade.

Rådata hämtas direkt från befintliga system — tusentals ärenden med historik, statusövergångar och metadata. Ingen tvättning, ingen strukturering i förväg. AI tolkar semantiskt: "det här fältet verkar beskriva ärendetyp, även om det heter olika saker i olika projekt." Tolkningarna valideras: stämmer det att 'Blocked' och 'Waiting for info' båda betyder extern blockering?

Första visualiseringen är klar inom dagar. Inte en mockup — en fungerande prototyp med verkliga ärenden. Siffrorna är verkliga. Mönstren är synliga.

Sedan börjar det krispiga läget. Iterationerna är preciserade korrigeringar: den här metriken förstår inte våra kunder, varför är den stapeln röd, kan vi se detta uppdelat per team. Varje iteration tar timmar, inte veckor.

Boggitrycket som illustration

En analogi från ett samtal: boggitryck. I järnvägsteknik är boggitrycket ett exakt mått — ett specifikt tal med en enhet och ett gränsvärde. Det är krispigt output. Men för att komma till det behöver någon ha kört rälsen, känt av oregelbundenheterna, beskrivit upplevelsen av vad som känns som hög belastning. Det är kladdigt input.

Ingen kompetent ingenjör förväxlar de två. Mätresultatet är inte detsamma som beskrivningen av upplevelsen. Men upplevelsen är förutsättningen för att veta vad man ska mäta.

Det är exakt den relationen mellan kladdigt och knisprigt input i vår process.

En ärlig notering om konfirmationsbias

Det finns en risk i all dataanalys som vi inte ska förtiga. När AI tolkar data semantiskt — när det föreslår att "Blocked" och "Waiting for info" sannolikt betyder samma sak — kan det råka bekräfta en föreställning snarare än avslöja verkligheten. Det ser ut som insikt. Det kanske är projektion.

Det är därför okularbesikning är inbyggt i processen: varje semantisk tolkning presenteras för validering av domänexperten. Stämmer det? Vi frågar. Konsulterna bekräftar eller korrigerar. AI föreslår. Experten bestämmer. Den ordningen är inte förhandlingsbar.

Vad "data först" faktiskt betyder

Vi börjar inte med vad vi ska bygga. Vi börjar med vad vi vill förstå. Kladdigt input etablerar det semantiska fältet. Krispigt input preciserar det iterativt. Prototypen är det visuella lagret ovanpå — inte tvärtom.

Det är vad "data först" ser ut i praktiken. Inte en arkitekturprincip — en inputkalibrering.

Se även: AI-analysverktyg för leveransflöden för resultaten från ett konkret uppdrag där den här metoden tillämpades, och Hur vi arbetar för det bredare metodramverket.