Dette er en kommentar. Rådene er en redaksjonell vurdering, ikke en beskrivelse av en konkret kundehendelse.
En liten endring i et IT-system kan være gjort på fem minutter. Å finne ut hva som ble endret når noe slutter å virke, kan ta langt lenger tid. Derfor mener vi at en enkel endringslogg bør være en del av vanlig drift, også i små virksomheter. Den trenger ikke være et stort saksbehandlingssystem. Den må bare være mulig å finne og forstå.
Når feilen kommer etterpå
Tenk deg at kontaktskjemaet på nettsiden slutter å levere meldinger på mandag. På fredag ble en utvidelse oppdatert, en e-postinnstilling endret og et gammelt skjema fjernet. Kanskje skyldes feilen ett av disse grepene. Kanskje ikke. Uten en oversikt er det vanskeligere å vite hvor undersøkelsen bør begynne.
En logg beviser ikke årsaken. Den gir en tidslinje og noen konkrete hypoteser å teste. Det er en vesentlig forskjell fra å gjette seg bakover ut fra hukommelsen. Og en grønn statusindikator alene sier ikke om skjemaet faktisk leverer; det må kontrolleres som en brukeropplevelse.
Tre linjer kan være nok
For en rutineendring ville vi startet med tre spørsmål:
- Før: Hva skal endres, hvorfor, hvem har ansvaret, og hvordan ser vi at det virker etterpå?
- Under: Hva ble faktisk endret, av hvem og når? Noter avvik fra planen.
- Etter: Hva ble testet, hva ble resultatet, og hva gjør vi hvis vi må tilbake?
For eksempel: «Oppdatert skjema-utvidelsen fredag. Testet innsending fra offentlig side og mottak i riktig postkasse. Ved feil: gjenopprett forrige versjon og test på nytt.» Dette er en tenkt loggoppføring, ikke en rapport fra en utført jobb. Den er nyttig fordi neste person får både endringen og kontrollpunktet.
Omfanget bør følge risikoen. En endring i en overskrift krever ikke samme prosess som en endring i innlogging, betaling eller e-postruting. Men jo viktigere funksjonen er, desto mindre bør virksomheten være avhengig av at én person husker detaljene.
Loggen er ikke det samme som systemloggen
En teknisk systemlogg kan vise hendelser og feil. En menneskelig endringslogg forklarer hensikten: hvorfor noen gjorde en endring, hva de forventet, og hva de sjekket. Begge kan være nyttige, men de svarer på ulike spørsmål. Den korte endringsloggen bør derfor ligge sammen med annen dokumentasjon virksomheten selv har tilgang til, ikke bare i en leverandørs private innboks.
Den bør heller ikke bli et nytt sted å lagre passord, nøkler eller personopplysninger. Skriv hva som ble gjort og hvor autorisert dokumentasjon finnes, ikke hemmelighetene selv.
En liten vane med stor praktisk verdi
Formell endringskontroll kan være omfattende. NIST beskriver blant annet dokumentering, vurdering, gjennomføring og kontroll av konfigurasjonsendringer i en standard for et annet og mer regulert bruksområde. Små norske bedrifter er ikke dermed pålagt akkurat denne prosessen. Prinsippet er likevel nyttig: endringer bør kunne etterprøves.
Vår påstand er enkel: Hvis ingen kan fortelle hva som ble endret sist, er feilsøking unødvendig vanskelig. Begynn med de systemene som faktisk stanser arbeid eller kundekontakt når de svikter. Før en kort logg neste gang dere gjør en endring. Test funksjonen etterpå. Da har dere noe bedre enn både et grønt dashboard og en god hukommelse: et spor dere kan følge.
