Den digitale tinglysning, NemID, Amanda og Polsag.
Fejl på fejl på fejl. Det er for dyrt, forsinket og forfejlet. Ikke underligt, hvis nogen tænker, at staten ikke aner, hvad den laver, når der skal købes store nye it-systemer. Og de har helt ret.
»Det er sjældent leverandørens fejl, men derimod kundens uhensigtsmæssige krav og dumstædige holdninger, der ender med at afspore systemer,« siger Søren Lauesen, professor ved IT-Universitetet.
50 års erfaring har professoren på bagen. Efter 20 år i it-industrien gik han over til universitetsverdenen, hvor han nu har været i 30 år. De sidste 10 af dem har han blandt andet undersøgt, hvorfor store it-systemer så ofte går i vasken.
Private går også i to it-fælder
Men hvorfor er det så svært at lave et it-system, som virker?
Søren Lauesen mener, at der er flere grunde, men de to største er:
De store systemer lanceres uden først at være afprøvet på brugere De værktøjer, der bruges til at beskrive ens ønsker til it-systemerne, giver dårlige systemer
Private virksomheder begår faktisk de samme fejl som det offentlige – der er bare ikke lige så stor offentlig opmærksomhed omkring det.
Borgerne har en forventning om, at statens it skal virke gnidningsløst. Det virker som en selvfølgelighed, at det offentlige ansætter de bedste eksperter, så der ikke opstår problemer, når hele Danmark skal bruge det nye system.
Det er desværre ikke tilfældet. Og netop fordi de offentlige systemer berører så mange mennesker, er der også langt større opmærksomhed på, om systemerne virker eller ej.
»For nogle år siden skete det for Mærsk, at de endte med it-løsning, der var så dårlig, at deres forretning fik store problemer. Det hørte man ikke særlig meget til,« fortæller Søren Lauesen.
Panik fører til big bang
Den digitale tinglysning er et tekstbogseksempel på et system, der blev lanceret uden at være blevet brugsmæssigt afprøvet først. Systemet blev forsinket med halvandet år.
Som reaktion på forsinkelsen blev systemet sat i gang nærmest fra den ene dag til den anden.
»I panik blev systemet sat i gang med et ‘big bang’ – alle skulle bruge systemet på en gang. Der var ikke noget galt med selve teknikken, men ingen havde taget højde for, at advokater og ejendomsmæglere skulle have fuldmagt til at underskrive for deres klienter,« forklarer Søren Lauesen.
Mange af de borgere, der skulle bruge tinglysningen, havde endnu ikke anskaffet sig digital signatur. Derfor måtte boligadvokater få fuldmagt af husejerne. De fuldmagter skulle behandles manuelt, og der var mange fuldmagter, der skulle behandles på en gang.
»Myndighederne testede ikke engang om dem, der skulle bruge sitet, kunne finde ud af at bruge det, før de søsatte det. Resultatet blev, at de fik en overbelastet hotline, og de penge, de ville have sparet på lønninger, blev brugt på at hyre ekstra medarbejdere til at fjerne den voldsomme arbejdsbyrde,« fortæller Søren Lauesen.
Sørg for at brugerteste først
Ups. Det var en økonomisk katastrofe for nogle brugere. Enkelte måtte gå fra hus og hjem med store økonomiske tab. I skrivende stund har 50 borgere rapporteret at have tabt omkring 1.2 millioner kroner på grund af forsinket sagsbehandling.
»Man skal aldrig lancere et system efter ‘big bang’-modellen. Den ideelle situation er at starte med begrænset drift – enten i forhold til geografi eller efter en frivillighedsmodel, hvor brugerne selv bestemmer om de vil deltage.«
»SKAT bruger frivillighedsmodellen på deres side til selvangivelse, og det er en succes. Dog er de er ikke helt tilfredse med, hvor mange der bruger det. Det kan være et spørgsmål om brugervenlighed,« siger Søren Lauesen.
Brugervenlighed er et kernespørgsmål, når man laver store it-systemer. Men alt for ofte glemmer leverandøren at tjekke for det. Derfor ender det i programmer, som ingen har lyst til, eller kan finde ud af, at bruge.
Frem med blyant og papir
Brugervenligheden kan sikres ved at bruge to ret simple værktøjer, kaldet blyant og papir.
Leverandøren tegner skærmbilleder, som den har tænkt sig, programmet skal vise. Tilfældigt udvalgte brugere indkaldes til at teste systemet. Det foregår ved, at de prøver at bruge skærmbillederne til at udføre typiske arbejdsopgaver.
Brugerne ‘klikker’ med blyanten på de knapper, de mener skal bruges osv.
»Ofte går det helt galt med den første gruppe, man bruger. Så bruger man de erfaringer, man har fået med første gruppe, tegner nye forbedrede skærmbilleder, inviterer en ny gruppe og gentager processen.«
»Tredje gang man gør det, har man som regel et rigtigt brugervenligt system,« fortæller Søren Lauesen.
Ny metode gør det lettere at få gode resultater
Kravspecifikation lyder relativt let, men det er i virkeligheden svært at formulere noget, der resulterer i et godt system. Søren Lauesen har udviklet en ny metode, der endnu ikke er udbredt, men som giver gode resultater.
»Jeg har forsket i, hvordan man bedst formulerer sin kravspecifikation. Jeg har lavet et eksempel på en stor, svær kravspecifikation, som man kan hente direkte fra min side. Så kan man bruge den som skabelon, og fylde sit eget indhold i.«
»Ideen er, at man beskriver brugernes arbejdsopgaver og beder leverandøren udvikle et system, som kan støtte dem i de opgaver,« forklarer han.
Tanken er, at man i stedet for at sige, at programmet skal kunne gøre x,y og z, så beskriver man sine arbejdsopgaver og beder om et program, der kan hjælpe en med at udføre de opgaver på en mere effektiv måde.
DSB og 40 andre er allerede i gang
Teknikken er indtil videre brugt i mindst 40 projekter. DSB startede med at bruge værktøjet til to mindre projekter, og de blev så glade for resultaterne, at de nu vil bruge modellen til alle større opgaver.
Udbredelsen af værktøjet går langsomt, men sikkert.
»Den store ulempe ved den måde at tænke kravspecifikationer på er, at det kun tager mellem en femtedel og en tiendedel af den tid, det normalt ville.«
»Det betyder, at konsulenterne kommer til at tjene mindre. Hvorfor skulle de sprede en teknik, der ville skære kraftigt ned på deres timer og dermed løn?« lyder det fra Søren Lauesen.
