Rapporter som kraschar på måndagar

Måndag morgon, kvart över åtta. Helgens uppdatering har gått. Så kommer mejlet: ledningens dashboard visar fel, summorna ser konstiga ut, kan någon titta på det? Klockan nio sitter datateamet samlat och går igenom pipeline-loggarna för att hitta steget som gick sönder.

Nästan varje gång är orsaken densamma. Någon ändrade en mappning sent på fredagen för att hinna lägga till ett nytt värde innan det var dags att gå hem. Ändringen såg bra ut. Systemet som läste mappningen validerade ingenting, och något som borde ha stoppats gick obemärkt in i datalagret.

Så här kan det se ut. Sales Ops underhåller en mappning från kontonummer i källsystemet till tvättade kundnamn i en delad Excelfil. Datalagret hämtar den varje natt, joinar den mot transaktionerna och skriver en faktatabell. De flesta dashboards hämtar sin data därifrån.

Fredag klockan fem lägger någon till ett nytt konto och glömmer tabbtecknet på slutet. Excel sparar filen som CSV (eftersom datalagret läser CSV, inte XLSX). Raden läses in med en kolumn mindre än väntat. Kundnamnet hamnar i fel kolumn. Ingenting larmar, eftersom båda kolumnerna är text.

Måndag morgon matchar den felaktiga raden ingenting i joinen. Dashboarden visar intäkter utan kundnamn. Totalsumman stämmer, men inte uppdelningen. Någon i ledningsgruppen ser en tom rad. Mejlet går iväg kvart över åtta.

Vid elva har teamet hittat felet. Rättningen tar tio sekunder. Felsökningen tog två timmar. Tre personer är stressade. Ingen litar på dashboarden förrän efter nästa uppdatering.

Allt det där började med ett enda bortglömt tabbtecken.

Därför sprider sig felet

Pipelinen litar på mappningen. Det finns ingen spärr mellan den som ändrar i filen och systemet som läser den. Utvecklare lägger in validering i formulär som användare fyller i, eftersom användare skriver vad som helst. I interna mappningsfiler har de inte gjort samma sak, eftersom de känns säkra. Det är de inte. En mappningsfil är ett formulär utan validering, som människor fyller i under tidspress.

Tre ändringar som stoppar det

Validera vid källan. En rad som saknar obligatoriska fält går inte att spara. Felet visas direkt för den som kan rätta det, inte tre dagar senare när en rapport går sönder.

Versionshantera varje ändring. När rapporten ändå går sönder får du svar på ”vad har ändrats sedan i fredags?” med två klick, i stället för att lägga en timme på att leta bland filkopior.

Gå över till ett schemakontrakt. Läs mappningen från ett API, inte från en CSV-fil. Om schemat ändras så att det inte längre är kompatibelt stoppar pipelinen direkt, med ett tydligt fel, på fredagseftermiddagen och inte i tysthet på måndagsmorgonen. Lookup API i gridmap fungerar så: fälten har fasta datatyper, och det bygger på samma granskningslogg som den som redigerar ser.

Vad det kostar att låta bli

Två timmars kris i veckan, femtio veckor om året, blir 100 timmar. Även med ett blygsamt timpris för en senior utvecklare är det runt 95 000 kr om året som bara går till att släcka bränder, och då har du inte räknat med alla andra som dras in. Mönstret lever kvar i åratal eftersom ingen enskild person får ta hela smällen. Kostnaden fördelas på så många att ingen någonsin räknar på den.

Vanliga frågor

Är det här bara ett Excelproblem? Till stor del, men alla filbaserade mappningar saknar samma spärr. Lösningen är densamma oavsett format: läs från ett API eller en versionshanterad tabell.

Vi har en regel: inga ändringar på fredagar. Hjälper det? Lite grann. Det egentliga problemet är att varje ändring innebär samma risk. Flyttar du regeln till tisdag ändras bara vilken veckodag dashboarden går sönder.

Hur vet vi när det här är löst? Det syns inte på att buggarna försvinner, utan på hur lång tid det tar att hitta felet. Tar det två minuter att svara på ”vad har ändrats?” finns spärren där den ska.