Introduktion
Som udviklere af noget software, der skal anvendes af andre mennesker, har vi ofte meget større betydning end vi tror. Hvis det er et spil, som private forbrugere skal købe, så kan vi måske risikere, at vores spil ikke får den store succes. Vi - eller oftest den virksomhed, vi arbejder for - får måske ikke så meget økonomisk udbytte af vores indsats som ønsket. Hvis det er et system, der har som formål at lette arbejdsprocesser i en virksomhed eller i en offentlig institution, så vil brugerne af systemet meget tydeligt kunne mærke, om systemet fungerer som tiltænkt, men hvad betyder dette egentlig..?
Kravsspecifikationen er altid et godt sted at starte. Er de krav opfyldt, som brugerne (oftest eksperter/magthavere mv. i den organisation, der har bestilt systemet) har udformet? Her kan vi allerede ane et problem med kravsspecifikationen: Hvor stor indflydelse har de faktiske brugere af systemet haft på kravene? Desværre ses tendensen ofte at være, at jo større organisation, der skal bruge systemet, jo længere væk kommer brugerne fra de krav, der stilles til systemet.
Lad os antage, at kravene er gode nok. Det er stadig meget svært at tænke alle aspekter med i udformningen af kravsspecifikationen. Der er mange måder at implementere de enkelte krav. Derfor bruges der hyppigt prototyper og andre teknikker i udviklingsprocessen for at sikre, at udviklerne arbejder henimod et system, som brugerne kan godkende.
Et godt eksempel på et system, hvor resultatet af mange årsager kom til at ligge langt fra et optimalt IT-system er Amanda, der var et nyt system til arbejdsformidlingerne med det formål at forkorte og lette processerne for medarbejderne. Der er flere aspekter i udviklingen og det resulterende IT-system, der er rigtig gode at lære af.
Amanda
Historien bag arbejdsmarkedsstyrelsens knap 650 millioner kroner dyre edb-system Amanda er fortalt i følgende tidslinje:
Tidslinie
1994
I forbindelse med arbejdsmarkedsreformen vedtages det at udvikle et nyt system til arbejdsformidlingerne.
Forår 1996
Folketingets Finansudvalg godkender bevilling på 214,4 millioner kroner.
Forår 2000
Amanda-systemet i drift mere end to år senere end oprindelig planlagt.
Sommer 2000
Arbejdsformidlingernes ansatte nedlægger arbejdet, og arbejdsminister Ove Hygum (S) beskyldes for at misinformere Folketinget.
Efterår 2000
Eksperter anbefaler udskiftning af infrastrukturen i systemet og at gå væk fra OS/2-platformen. Det mener det vil koste 120 millioner kroner. Dette arbejde er endnu ikke afsluttet.
Oktober 2001
Rigsrevisionens rapport frikender Ove Hygum og hans ledende embedsmænd. Prisen for Amanda er steget til 650 millioner kroner.
Maj 2003
En afsluttende evaluering slår fast, at Amanda nu fungerer tilfredsstillende, men at der er problemer med udviklingsplatformen HPS, der kan være forældet i 2008[2].
2008
Amanda blev lagt i graven og erstattet af en webbaseret portal. Driftsomkostningerne var for høje på det mainframe-baserede system[3].
Arbejdsprocesserne i AF
De landsdækkende arbejdsmarkedspolitiske målsætninger for AF’s (arbejdsformidlingernes) indsats er:
- AF skal bidrage til at virksomhederne – på kort og lang sigt – får den arbejdskraft, de har brug for.
- AF skal bidrage til, at modvirke langtidsledighed og marginalisering på arbejdsmarkedet.
I nedenstående figur er de vigtigste forretningsprocesser og et antal støtteprocesser vist. Herudover er der vist, hvorledes AF's indsats kanaliseres til brugerne via arbejdsformidlingskontorer og selvbetjeningsfaciliteter (jobbutikker, job- og CV-banker mv.)[1]
De vigtigste forretningsprocesser omfatter de fire processer i den midterste del af figuren:
- registrering af de ledige,
- registrering af anmeldte jobordrer fra virksomhederne,
- formidling ved henvisning af ledige til jobsamtaler i virksomhederne samt
- aktivering
En forståelse for omfanget af de nævnte processer fås i nedenstående tabel[1]:
Vurdering af IT-systemet
Amanda blev primært indført med henblik på at effektivisere arbejdet i AF så i vurderingen af, om systemet lever op til sin rolle, vejer dette punkt meget stærkt.
Det væsentligste problem ved Amanda var at systemet ikke var brugervenligt. Grundregistreringen af en ny arbejdssøgende blev forlænget, fordi der blev brugt op mod 50 skærmbilleder til én registrering. Med det gamle system tog grundregistreringen fra 10-20 minutter, men med Amanda tog det efter tre måneders drift typisk en time pr. arbejdssøgende.
Det primære problem i brugergrænsefladen kom fra en antagelse om, at arbejdsprocesserne i AF kunne implementeres gennem udførelsen af et antal aktiviteter, der beskrives som en række veldefinerede arbejdsprocesser, der sammenkædes gennem et fælles informationsgrundlag (database)[1].
Det blev ikke taget i betragtning, at der på det enkelte regionskontor traditionelt er stor frihed i relation til arbejdstilrettelæggelsen,
hvilket betød, at Amanda skulle imødekomme betydelige krav om fleksibilitet, netop hvad angår tilrettelæggelsen af arbejdsprocesser. For at imødekomme dette krav, var det nødvendigt at nedbryde den enkelte proces i mange mindre delprocesser (skærmbilleder), som så efterfølgende sammensættes til et samlet procesforløb. Hver proces kommer herved til at gøre brug af mange skærmbilleder, der hver især har et meget lavt informationsindhold. Systemet kommer til at fremstå som tungt at arbejde med og tilmed uoverskueligt i de tilfælde, hvor der er uklarhed om den konkrete forretningsgang[1].
Den valgte tekniske platform var heller ikke særlig heldig. AMANDA blev konstrueret på OS/2, der allerede i 1996 var ved at blive udfaset af IBM. Amanda blev derfor låst til en platform, som hastigt blev forældet. Desuden blev der indkøbt maskiner til brugerne 2-3 år før systemet faktisk kom i drift, så de havde svært ved at klare de krav, der blev stillet af softwaren.
Test & evaluering
I aftestningen af jeres software er I naturligvis nødt til at forholde jer til om de krav, der blev stillet til programmet, rent faktisk er blevet opfyldt. Det kan ofte være nødvendigt at inddrage brugerne i denne test, da deres opfattelse - som vi har været inde på - kan afvige fra udviklernes opfattelse.
Desuden kan en evaluering medtage følgende aspekter ved softwaren:
- Brugervenlighed: Er programmet let at bruge? Hvor lang tid tager de forskellige arbejdsgange? Hvor let er det at lære at bruge programmet?
- Responstid: Virker programmet hurtigt og uden ventetid, der hæmmer arbejdsgangen?
- Den tekniske platform: Hvilke operativsystemer understøttes? Hvilke teknologier er softwaren baseret på?
- Vedligeholdelse: Hvor let er det at supportere, vedligeholde og videreudviklere softwaren?
Evaluering af softwaren
Test jeres egen software og foretag en evaluering ud fra ovenstående principper?
Påvirkning af brugere
Hvordan kan jeres software ændre nogle menneskers arbejdsprocesser eller aktiviteter i øvrigt?