Gode nyheter for Nav

Vi trenger ingen månelanding i Nav, kun at de enkelte tjenestene løses på en enklere og mer brukervennlig måte.

Publisert Publisert

IT: Ved å dele opp store dataprosjekt kan det offentlige få bedre og billigere løsninger. Men det er kanskje ikke i de store IT-selskapenes interesse. Foto: Stein J Bjørge/Aftenposten

Debattinnlegg

  • Frode Guribye
    Dr. Polit., Førsteamanuensis, Gruppen for Interaksjonsforskning, Insitutt for informasjons- og medievitenskap, UiB
iconDenne artikkelen er over fem år gammel

**Nylig har vi sett** gode eksempler på hvordan noen av utfordringene til Nav kan løses ved hjelp av nye IT-løsninger. I et innlegg i Aftenposten 8. april viste interaksjonsdesigner Tuva Eikås hvordan en avgrenset tjeneste kan gjøres bedre og mer brukervennlig med relativt enkle grep, i dette tilfellet hvordan man kan designe en løsning som vil gjøre det raskt og effektivt å søke om foreldrepermisjon.

I Dagens Næringsliv ble det 15. april rapportert om et prosjekt i Posten hvor man tok en avgrenset oppgave og startet et prosjekt med sterk brukermedvirkning i hele prosessen. Postbudene var selv sterkt delaktige i utformingen av løsningene. Løsningene er teknisk sett ganske enkle og heller ikke spesielt dyre. Innsparingene derimot, er store, og jeg er sikker på postbudene får en enklere arbeidshverdag med dette verktøyet. Det er flere ting vi kan lære av disse eksemplene.

For det første går det ikke å løse alle problemer på en gang. De siste årenes megaprosjekter i det offentlige er dyre og alt for komplekse. Selv om konsulentselskapene som påtar seg disse oppdragene juridisk sett ikke har ansvaret for disse kostbare fiaskoene, må de ha en anelse om at det er veldig vanskelig å spesifisere på en god måte hvordan slike gigantsystemer skal fungere og hvilke løsninger man faktisk vil ende opp med. Slike problemstillinger blir nøye belyst i de fleste IT-utdanninger. Kunnskapen bør således være godt distribuert ut i de mange konsulentselskapene.

Man kan nesten tro at det finnes konsulenter som gir dårlige råd til potensielle kunder, og at er det så mye penger i dette at de store IT-selskapene ikke bryr seg om at de får en liten skrape i lakken når et av deres milliardprosjekter feiler. De har en kontrakt og dokumentasjon som spesifiserer hva de skal levere. Da gjør det kanskje ingenting at prosjektet var utopisk og vanskelig å gjennomføre i utgangspunktet? Dette er big business. Jeg mener de store IT-selskapene må ta sin del av ansvaret.

Det vi kan lære av disse eksemplene er at det er viktig å identifisere mange relativt enkle og overkommelige prosjekter som kan løses på en hensiktsmessig måte. Ta en ting av gangen. Dette er kanskje ikke i de største IT-selskapene sin interesse. Et hvilket som helst lite IT-selskap kan jo levere inn et anbud på et lite prosjekt uten spesialisert kompetanse om offentlige anbudsordninger og hvordan man vinner frem i disse kompliserte prosessene.

For det andre er det viktig å involvere brukerne i prosessen. Når det er snakk om informasjonssystemer er ikke nødvendigvis brukerne de som mottar tjenesten, men gjerne de som utfører en tjeneste — slik som postbudene i det ovennevnte eksempel. Dette skal også alle IT-studenter lære i sine utdanninger, og brukermedvirkning er sentralt i det man kaller den skandinaviske skolen i systemutvikling. Hvorfor blir ikke disse relativt enkle innsikter og metoder benyttet når man skal lage nye tjenester for Nav?

Et svar kan være at det allerede finnes store systemer som løser mange oppgaver i det offentlige og at hvis man skal endre på ett system, så må man endre på alle. Alt henger sammen med alt. Det er også riktig at man vil ha store fordeler av å ha god kommunikasjon og integrasjon mellom ulike systemer - interoperabilitet kalles det. Da kan jo en logisk slutning være at man må løse alle problemer på en gang.

Da Amazon skulle bygge opp sine systemer, tok de en litt annen inngang i dette. I stedet for å lage et megasystem som skulle løse alle problemer og på forhånd spesifisere all kommunikasjon mellom systemer og mellom systemer og brukere, så lagde de en regel for alle utviklingsprosjekter: Alle systemer skulle inkludere et API - et application programming interface.

Enkelt sagt er dette et grensesnitt som spesifiserer og dokumenterer hvordan man kan hente ut data og interagere med et gitt system eller delsystem. Hvis alle systemer har et slikt grensesnitt skal det, teoretisk sett, også være enkelt å integrere systemer - bit for bit. Dette er en alternativ strategi som det offentlige også bør vurdere.

Vi trenger ingen månelanding i Nav, kun at de enkelte tjenestene løses på en enklere og mer brukervennlig måte. Dette er gode nyheter for Nav.

Publisert

Sakene flest leser nå

  1. Denne boligen er den dyreste i Bergen til nå i år

  2. Per og Kristine flytta frå kvarandre etter at dei gifta seg. – Forholdet har aldri vore betre enn no.

  3. Nederlandsk kortbane­verdensmester (27) død

  4. Fotballspilleren fra Bergen har en alvorlig sykdom. Her har han akkurat fullført gåturen fra Bergen til Oslo.

  5. Mann sendt til Haukeland etter knivstikking

  6. – Dette kunne lett blitt dramatisk

Din mening betyr noe
I BT trenger du ikke å være ekspert eller politiker for å slippe til. Skriv om det du har på hjertet! Skriv et innlegg