Er nye bygninger trygge?

Er nye bygninger trygge?

DEBATT: Offentlige it-systemer bør benytte innovasjonsprosesser, ikke byråkratiske prosesser, skriver Anders Haugeto i Iterate.

Av Anders Haugeto, partner i Iterate

Vi er vant til at programvare er full av feil. Utsatt for alt fra ustabile trådløsnettverk, herkete printere og formatteringsfeil i Word, til de grufulle minnene fra Microsoft Windows sin blåskjerm “blue screen of death”, som selv for Bill Gates kom på det mest ubeleilige tidspunkt (da Windows 95 krasjet under en demonstrasjon for pressen), har vi forsonet oss med at programvare ikke er perfekt.

Nå har altså enkelte av oss erfart ubehageligheter med selvangivelsen. Problemer, som strekker seg langt forbi de vanlige ytelsesproblemene som kommer når halve kongeriket samtidig skal sjekke restskatten: Enkelte har til sin store overraskelse fått anledning til å se andre personer sin selvangivelse. Det er kanskje å dra offentliggjøring av skattelistene en smule langt?

Nye IT-systemer og nye versjoner av IT-systemer kommer ofte med feil, og vi tør ikke stole på dem før de har hatt noen runder med forbedringer. Noen feil blir vi til og med så vant til at vi anser dem som en del av systemet. Vi har lært oss å ikke oppgradere noe som helst rett før vi tar med oss laptoppen på hytta uten internettdekning, eller rett før vi går inn i et viktig møte. Jo eldre programvaren er desto mer stoler vi på den, simpelthen fordi vi tiden har luket ut de fleste feilene. Spørsmålet vi burde stille oss er: Var det nødvendig å ha disse feilene der i utgangspunktet?

Det er annerledes med bygninger. Selv føler jeg meg mindre trygg desto eldre bygningen er. En kompis hadde for eksempel en gang en loftsleilighet fra 1800-tallet på Gründerløkka, og etasje delerne besto av knusktørr halm. Én flamme på feil sted i første etasje, og hele bygningen hadde blitt en stor skorstein på 30 sekunder.. Nye bygninger derimot, de står støtt. Bygget etter moderne forskrifter og metoder, og gjennomgått grundig ettersyn. I alle fall de aller fleste av dem.

Hva er det så som skiller ingeniørdisiplinene bygg og programvareutvikling? Kort fortalt er man i byggeindustrien nødt til å sikre kvalitet i hvert ledd. Du kan ikke påbegynne byggingen av andre etasje, før du vet at første etasje holder. Det er man (dessverre) ikke nødt til i programvareindustrien. I motsetning til byggeindustrien, som bygger integritet inn i løsningen, tester man i programvareindustrien for kvalitet etterpå. Og da finner man selvfølgelig masse feil, som man ikke har tid til å rette opp. Enkelte feil finner man ikke før systemet blir tatt i bruk. Jo større lanseringen er, desto flere feil har vi bygget inn. Og dere brukere? Vel, dere er jo vant til at første etasje av og til kollapser.

Hvorfor har det blitt slik? Hvorfor sliter Altinn med en feil som for oss utenforstående fremstår ubehjelpelig klønete? Selv tror jeg det dreier seg om perspektiv. Mer presist: Et manglende perspektiv.

La meg først presisere: Jeg er Altinn-fan. Tross ytelsesproblemer og dagens defekt. Det er jaggu ikke mange andre land i verden hvor det er så enkelt å betale skatt som i Norge. Altinn sparer det offentlige for store summer, og gjør en lite forlystelig oppgave for oss arbeidstagere så enkel som overhodet mulig. Altinn er en kjempesuksess, la oss ikke glemme det.

Når store virksomheter, offentlige såvel som private, kaster seg ut i utviklingen av store IT-systemer, som skal bistå virksomhetens kjernefunksjon, da er vi ikke lenger ute og kjøper pølse fra kiosken på hjørnet. Se heller på det som å stå over en porøs fjellformasjon i minusgrader og helle ut varmt vann. Hvor kommer vannet til å renne? Hvor fryser det først? Hvordan kommer formasjonen til å slå sprekker?

Vi vet ikke.

Derfor må vi sikre oss integritet i alle ledd. Vi bygger en etasje, og flytter inn i den. Da er vi nødt til å vite at den holder, før vi kan påbegynne neste etasje. Da må også alle fagområder og all den ekspertise som kreves for å bygge et system som for eksempel Altinn (det er ikke lite!) samhandle tett om det produktet de utvikler. De må ha et helhetlig perspektiv, som strekker seg langt forbi budsjetter, hierarkier og “linja”.

Oppdragsgiverne til Altinn må skape rammer for innovasjon. Knallhardt fokus på klassiske suksessfaktorer som budsjetter, hierarkier og spesifikasjoner skygger for produktet og skaper individuelle perspektiver. Frykten for å feile gjør paradoksalt nok at vi feiler.

Og feile, det kan ikke et produkt som Altinn. Det offentlige i Norge har kommet langt innen IT, tross alt. Vi er for mange et foregangsland på vårt elektroniske skattesystem, og dette kan vi nok i stor grad tilskrive ildsjeler på alle nivåer. Nå er det på tide å høste av erfaringene, og bli skikkelig proffe. Som brukere forventer vi oss det. Vi godtar ikke lenger blåskjerm.

Et viktig steg i denne retningen er å benytte innovasjonsprosesser, og ikke byråkratiske prosesser, som driver for utvikling av offentlige IT-systemer. Det offentlige må begynne å se på seg selv om en produktutvikler, som bygger integritet inn i sine produkter. Lykkes de med dette, kan vi fortelle våre barnebarn om hvordan IT-systemer tidligere var fulle av feil. Akkurat som mine besteforeldre fortalte meg om hvordan biler rett som det var kunne falle fra hverandre i gamle dager. Slik er det heldigvis ikke nå.

Les om: