Av Pål Sørgaard førsteamanuensis i informatikk, UiO
Det går ikke alltid galt med IT i offentlig sektor i Norge. Det er mange eksempler på at det har gått bra. Det er mange mislykkete prosjekter også i privat sektor, og det er en rekke eksempler på liknende problemer også i andre land. Det er trolig lite grunnlag for å bruke denne typen problemer partipolitisk, men der er naturligvis god grunn til å stille krav om profesjonell innsats og oppfølging når det offentlige investerer store beløp i IT.
I de senere årene har både trygdeetaten og skatteetaten gjennomført store IT-prosjekter: det mislykkete Tress-90-prosjektet i trygdeetaten og det velykkete FLID-prosjektet i skatteetaten.
De to etatene har en rekke fellestrek, og umiddelbart skulle det være grunnlag for å sammenlikne de to prosjektene. Etatene er ca. like store, de har en temmelig lik struktur, med kontor i alle kommuner, kontor på fylkesnivå og sentrale direktorater i Oslo. Begge betjener en stor del av befolkningen, og begge har langvarig erfaring med edb. Trygdeetaten har tidligere gjennomført vellykkete prosjekter, så når Tress-90 og FLID trekkes fram, er det ikke for å sammenlikne etater, men for å sammenlikne prosjekter.
Det er mange viktige forskjeller på Tress-90 og FLID. Fire av dem vil bli diskutert her. Det er vanskelig å si om noen av disse alene har vært utslagsgivende for forskjellen i sluttresultat, men det er lett å innse at de tilsammen kan ha ført til svært ulike resultater.
Det har vært stor forskjell mellom FLID og Tress-90 når det gjelder teknisk ambisjonsnivå. FLID er bygget på kjent teknologi og velfungerende konsepter. Ikke slik å forstå at systemene er gammeldagse, men det har ikke vært noe å mål å være avansert. FLID er således i liten grad basert på såkalt klient/tjener-arkitektur. Tress-90 derimot ser ut til å ha satset høyt teknologisk. Det har vært snakk om nye konsepter for støtte til saksbehandling, utstrakt satsing på klient/tjener-arkitektur, etc.
FLID var et nyutviklingsprosjekt. Selv om skatteetaten sentralt har brukt edb i mange år, har det (med enkelte unntak) ikke vært brukt edb på likningskontorene før FLID.
I Tress-90 var det to gamle systemer som skulle erstattes av et nytt. I mellomtiden måtte de gamle systemene holdes kjørende. Slike systemer er ikke upåvirket av endringer i trygdelovgivningen. Det kan være vanskelig nok å foreta de nødvendige endringer i ett system, men å skulle endre to eksisterende systemer samt modifisere et system under utvikling ut fra løpende endringer i behov må innebære store problemer.
Enkelt sagt får skatteetaten nye oppgaver en gang i året, mens trygdeetaten løpende får inn nye saker. Når et likningskontor skal installere nye systemer, utdanne seg, løse problemer mv., er det få som klager over dårlig service! Det er nå en gang slik at de færreste av oss direkte ville savne likningskontoret dersom det stengte en dag eller flere. Trygdeetaten får løpende inn en mengde saker, og den er ansvarlig for månedlige utbetalinger til flere hundre tusen mennesker. Trygdekontoret må holdes oppe, og det samme må etatens systemer.
I FLID-prosjektet ble det drevet utstrakt prøvedrift. Den første versjonen ble prøvd ut allerede fra 1987, og systemene ble forandret flere ganger mens antallet prøvekontorer langsomt vokset fra ett til ni. De ferdige systemene ble satt i drift fra 1992. Da ble de først tatt i bruk ved et mindre antall kontorer. Landets storkommuner fulgte etter i 1993, mens de øvrige 373 likningskontorene tok systemene i bruk i 1994. Dette forløpet gjorde det mulig å korrigere kursen underveis. Vesentlige lærdommer ble gjort, og uklarheter og usikkerheter kunne håndteres mens konsekvensene var små.
I Tress-90 later det til at man satset stort. Innledende eksperimenter med ny utviklingsplattform ble i følge pressen ikke helt gjennomført. Det ble tidlig kjøpt inn nye maskiner til trygdekontorene, og store ressurser ble brukt før man fikk praktiske erfaringer med de nye løsningenes holdbarhet.
Det burde være åpenbart at Tress-90-prosjektet på en rekke punkter har satset på en strategi som innebærer høy risiko. To av punktene er uunngåelige, nemlig at man hadde to eksisterende systemer og at trygdeetaten arbeider under store krav om kontinuerlig «oppetid». Det ville vært logisk å kompensere disse kompliserende faktorene med lav risiko og ulike sikringsrutiner på andre punkter. Tress-90 kunne ha lagt seg på et lavere teknisk ambisjonsnivå og man kunne ha insistert på å sette i drift en prøveversjon av systemene. En slik prøvedrift ville vært kostbar, men den ville ha vært en billig forsikring, og den ville ha åpnet veien for en trinnvis innføring av systemene.
Åpen dialog mellom utviklingsprosjekter og fagmiljøene øker sjansen for nyttige innspill. Samtidig er åpenhet en form for kvalitetssikring: skal du være åpen, bør du ha litt orden i egne saker. Interessant nok har FLID hatt en åpen profil overfor fagmiljøene, mens Tress-90 var temmelig lukket.
Store tekniske ambisjoner kan være på sin plass, særlig om man legger vekt på det offentliges foregangsrolle når det gjelder å etterspørre framtidsrettede løsninger. I slike tilfeller må man være forberedt på omfattende revisjoner før løsningene finner sin endelige form. Politiets OL-satsing hører muligens hjemme i denne kategorien.
Det å anskaffe IT er ikke som å kjøpe bil. Det er et vesentlig kjennetegn at det er usikkerhet om hva som kreves, og det er derfor naturlig at kravene forandrer seg underveis. Det er ikke profesjonelt å bruke dette som en unnskyldning for at det gikk galt. Store prosjekter må legges opp slik at de kan håndtere slike endringer. Eksperimentering, prototyper og prøvedrift er nettopp teknikker for å håndtere dette. Fast produkt til fast pris er bare unntaksvis en praktiserbar løsning. FLID-prosjektet ble forøvrig gjennomført parallelt med skattereformen.
Det er dessverre en velkjent mekanisme at man i store prosjekter er lite tilbøyelig til å revidere sentrale vurderinger. I stedet satser man mer og mer, hardere og hardere, på å nå de målene man opprinnelig satte seg. På den måten kan man unngå et direkte nederlag, men samtidig øker innsatsen vesentlig. Noen ganger går dette godt, men det er tydelig at enkelte prosjekter burde vært revurdert og stanset på et langt tidligere tidspunkt. Den som har ansvar for et stort utviklingsprosjekt, bør derfor finne fram til mekanismer som kompenserer for denne tendensen. I praksis vil dette blant annet bety at ansvarlige ledere må skaffe seg kompetente rådgivere som er uavhengige av det aktuelle prosjektet. Dette gjelder uavhengig av om prosjektet drives av eksterne konsulenter eller interne IT-avdelinger. At det stilles spørsmålstegn ved IT-konsulentenes rolle er bra. I tillegg bør man sette et kritisk lys på IT-avdelingene.
Vi må håpe at den senere tids debatt om uheldige IT-satsinger ikke fører til redusert åpenhet. For offentligheten er det verdt å merke seg at enkelte utspill kan ha sin bakgrunn i interne stridigheter snarere enn i reelle vurderinger av systemenes kvalitet. Utforming av IT-løsninger er ikke løsrevet fra maktforhold forøvrig.
