Erfaringer fra statslige IT-projekter – hvordan gør man det bedre?Rapport og anbefalinger fra en arbejdsgruppe under Teknologirådet

Indhold

Forord 2Indledning 3Formål og målgruppe 3Afgrænsning og metode 3Øget fokus på området 4Rapportens opbygning 5

Kapitel 1Nye krav til IT i det offentlige 61.1 Sammenfatning 61.2 Den teknologiske og administrative udvikling 61.3 Forventninger til den offentlige service 71.4 Nye krav til offentlig ledelse 7

Kapitel 2Rammerne for statslige IT-projekter 92.1 Sammenfatning 92.2 Valg af løsningsmodel 92.3 Bevillings- og beslutningsprocessen 102.4 Samarbejdet mellem ministerierne 102.5 Udbudsregler og kontraktformer 112.6 Offentlighedsprincippet 122.7 Anbefalinger 12

Kapitel 3Den offentlige organisation 133.1. Sammenfatning 133.2 Den øverste ledelses ansvar 133.3 Mangel på mål og strategisk fokus 143.4 Købers organisation ikke moden 153.5 Problemer med at styre projekterne 163.5.1 Projektet bemandes ikke godt nok 163.5.2 Andres erfaringer bliver ikke brugt 163.5.3 Der mangler risikostyring 173.5.4 Projektet splittes ikke op i delleverancer 173.5.5 Brugerne inddrages på forkerte præmisser 183.5.6 Uventede problemer, når systemet tages i brug 183.6 Anbefalinger 19

Kapitel 4Samspil med leverandører og konsulenter 204.2 Samarbejdsmodellen 204.3 Kontrakterne 214.4 Leverandørerne 224.5 Konsulenterne 224.6 Anbefalinger 23

Appendiks 1Praktiske råd til fremtidens IT-projekter 25

Appendiks 2De fem cases 28Told•Skats Erhvervssystem 28EASY 28Amanda 28Navision Stat 29VUE 29Litteratur 30

Forord

Teknologirådets bestyrelse besluttede i 2000 atsamle erfaringerne fra en række store offentlige IT-projekter og vurdere de fælles problemer, projekter-ne var stødt ind i. Problemer, der har forsinket IT-sys-temerne, gjort dem dyrere end planlagt og i fleretilfælde også skuffet forventningerne til deres nytte-værdi.

Denne rapport fremlægger resultaterne af dettearbejde. Den giver samtidig en række anbefalingertil, hvordan man i den offentlige sektor kan gribekommende IT-projekter an. Anbefalingerne rettersig både til regering og Folketing og til de beslut-ningstagere i den offentlige administration, der fåransvaret for store IT-projekter i fremtiden.

Rapporten er udarbejdet af en tværfaglig arbejds-gruppe under Teknologirådet. Som medlemmer afarbejdsgruppen er valgt en række personer, der harsærlig indsigt i problemstillingen – fx i kraft af derespersonlige erfaringer med offentlige IT-projekter.Arbejdsgruppen har bestået af:

Erik Bonnerup (formand)

Annelone Jensen, fulfilmentmanager, eHuset(udpeget af Dansk Dataforening)

Birgitte Gregersen, lektor, Aalborg Universitet

Erik Andreasen, afdelingsdirektør, Danske Bank

Hans Henrik Østergaard, direktør, Finansstyrelsen

Inge Mærkedal, direktør, Forvaltningshøjskolen

Karsten Dybvad, departementschef, Trafikministeriet

Kim Viborg Andersen, lektor,Handelshøjskolen i København

Kim Østrup, direktør, IBM

Martin Toft Hansen, direktør, CSC Scandihealth (udpeget af IT-Brancheforeningen)

Nina Esmark, projektchef, IBM

Teknologirådet har stillet sekretariat til rådighed forarbejdsgruppen.

Arbejdsgruppens egen viden er blevet suppleretmed knap 30 interviews med involverede aktører ifem store offentlige IT-projekter. Desuden hararbejdsgruppen undervejs i forløbet afholdt enworkshop for en kreds af fagpersoner.

Teknologirådet og arbejdsgruppen vil gerne takkealle, der har bidraget til projektet undervejs. Det gæl-der ikke mindst de mange interviewpersoner, derhar stillet deres viden og erfaringer til rådighed.Ansvaret for den endelige rapport er naturligvisarbejdsgruppens eget.

Teknologirådet, marts 2001Lars Frelle-Petersen, projektleder

2

Indledning

Udgangspunktet for denne rapport er, at den offent-lige sektor ikke må forspilde sine chancer for atanvende informationsteknologien til en bedre ogmere effektiv styring, sagsbehandling og service. Foreksempel ved at udvikle IT-systemer, hvor disse for-dele ikke udnyttes godt nok. Eller ved helt at undladeat satse ambitiøst på informationsteknologien. Détvil være langt alvorligere end de nok så ubehageligeforsinkelser og budgetoverskridelser, der har prægeten række offentlige IT-projekter i 90’erne.

Netop risikoen for, at IT-udviklingen i det offentli-ge taber tempo, er måske den alvorligste konsekvensaf de seneste års problemfyldte IT-projekter og denoffentlige kritik, de har ført med sig. Det er derfor endel af formålet med denne rapport at pege på enrække fælles årsager til, at projekterne ikke når deresmål. Hensigten er at fokusere på, hvilke initiativerder kan tages for at skabe bedre projektforløb.

En ”skandalefri fremtid” kan ingen garantere. Der-til er store IT-udviklingsprojekter både for dynamis-ke og komplekse. Det er umuligt at forudse og kon-trollere alle de forhold, der kan slå et projekt ud afkurs. Men forhåbentlig kan denne rapport bidrage tilat forhindre den skandale, der består i, at man for-sømmer at lære af fortidens fejltagelser og udnyttede positive erfaringer, der trods alt findes i rigt mål.

Formål og målgruppeRapporten henvender sig især til politikere og admi-nistrative beslutningstagere i den offentlige sektor.Dens formål er at systematisere erfaringerne fra enrække store offentlige IT-projekter og kombineredem med arbejdsgruppens egne erfaringer og påden baggrund opstille anbefalinger til fremtidigpraksis. Det har fra starten været arbejdsgruppensudgangspunkt, at rapportens analyser og anbefa-linger skal:

• Gå på tværs af enkeltprojekter: Rapporten præsen-terer de generelle problemer og erfaringer fra femIT-projekter, der indbyrdes er meget forskellige. Kon-klusionerne i rapporten er derfor ikke dækkende fornogen af de fem projekter, men forsøger at give etbillede af de typiske problemer i de fem projekterunder ét.

• Koncentrere sig om projekternes problemer: Der harværet mange vellykkede elementer i de undersøgteprojekter. Og flere projekter har tacklet de proble-mer, der opstod undervejs, på en professionel måde.Arbejdsgruppen har imidlertid set det som sin opga-ve at behandle de mindre vellykkede sider af projek-terne. Dermed risikerer de offentlige IT-projekter atfremstå i et mere ensidigt negativt skær, end degenerelt fortjener.

• Være fremadrettede: Formålet har været at identifi-cere de erfaringer, andre kan lære noget af. Der erikke i rapporten gjort forsøg på at kortlægge og for-klare samtlige problemer i IT-projekterne. Og detligger langt uden for dette projekts opgave, metodeog ressourcer at kunne placere et ansvar for detenkelte projekts problemer hos bestemte aktører.

• Fokusere på strategiske udfordringer: Store offentli-ge IT-projekter rummer udfordringer på alle niveau-er fra den politiske beslutningsproces til den dagligedrift – og ofte er grænserne mellem disse niveauerflydende. Rapporten fokuserer på den del af udfor-dringerne, der især knytter sig til det strategiskeniveau. Det vil bl.a. sige projekternes rammebeting-elser, den offentlige myndigheds organisation samtsamspillet mellem køber, leverandør og konsulenter.I appendiks 1 er der samlet en række mere operatio-nelle anbefalinger til god praksis før, under og efteret IT-udviklingsprojekt.

Rapporten gør sig hverken ud for at være en hånd-bog i projektledelse eller et skudsikkert værn mod deproblemer, der uvægerlig vil opstå undervejs i et IT-projekt. Den skal betragtes som en oversigt over depunkter, der, som minimum, bør være sat på dagsor-denen, inden et IT-projekt sættes i værk, mens syste-met udvikles, og når det tages i brug .

Afgrænsning og metodeRapportens konklusioner bygger dels på arbejds-gruppens egne erfaringer dels på en interview-undersøgelse af fem cases, der beskrives mere udfør-ligt i appendiks 2:

• Amanda – Arbejdsformidlingens integrerede regis-trerings-, aktiverings- og økonomisystem. Enkontrakt blev underskrevet i 1996. Systemet skulleefter planen have været klar 1. januar 1998, men blevførst sat i drift 10. april 2000.

• EASY – Undervisningsministeriets edb-system giveralle erhvervsskoler et fælles, administrativt og øko-nomisk system på skolerne. Systemet blev udbudt i1995 og taget i brug i 1998/1999.

• Erhvervssystemet – Told og Skats edb-system skulleregistrere oplysninger om erhvervsvirksomhedernevedrørende skatter og afgifter. En kontrakt blevunderskrevet i 1995, og systemet skulle efter planenvære sat i drift i juni 1997. I foråret 1997 stod detimidlertid klart, at fire ud af systemets fem dele ikkekunne leveres. Den femte del blev sat i drift i 2000.

3

• Navision Stat – Økonomistyrelsen står bag et stan-dardøkonomisystem, der skal installeres i cirka 400statsinstitutioner. Implementeringen startede i1999 og løber tre til fire år frem.

• VUE – Videregående Uddannelsers Edb-system, VUE,er et integreret informationssystem. Projektet blevstartet i Undervisningsministeriet i 1989. Systemetskulle have været færdig i 1994. De første institutio-ner tog det i brug i 1996, men det stod først endeligtklar i 1999, og bruges i dag kun af en del af institu-tionerne.

Disse fem projekter er udvalgt blandt en rækkeandre mulige kandidater. Kriterierne for valg af detenkelte projekt har blandt andet været, at det havdeen vis størrelse med hensyn til både pris, antal bru-gere, tidsforløb og potentiel betydning for købersorganisation. Det har desuden været en forudsæt-ning, at de offentlige organisationer har været inter-esserede i at medvirke i undersøgelsen, så det villevære let at få adgang til informationer om projektetog komme i kontakt med de implicerede aktører.

De fem valgte cases er alle store IT-projekter i denforstand, at den opgave, de skal understøtte, harafgørende betydning for et helt forvaltningsområde.Økonomisk spænder projekternes oprindelige bud-getter fra godt 25 millioner kr. (EASY) til 268 millio-ner kr. (Amanda).

Der er også efterstræbt en indbyrdes forskellighedi viften af projekter. Det vil blandt andet sige, at denbåde rummer vellykkede og mindre vellykkede pro-jekter, ældre og nyere projekter, projekter, der erfinansieret hhv. over interne driftsmidler og via selv-stændige aktstykker i Finansudvalget, samt endeligbåde projekter, der er opbygget fra bunden og tilpas-sede standardsystemer.

I alle fem projekter er køber en statslig institution.Erfaringer og anbefalinger i rapporten udspringersåledes primært af statslige projekter. Men en langrække af problemstillingerne vil være lige så rele-vante for amter og kommuner, der arbejder medstore IT-udviklingsprojekter.

I hver case er der i gennemsnit interviewet cirkafem nøglepersoner – både fra den offentlige køber ogfra de leverandører og konsulenter, der har medvir-ket i projektet. Interviewpersonerne er blevet bedtom at udtale sig frit og anonymt. Formålet har væretat give deltagerne frihed til at udtale sig både kritiskog selvkritisk om projekterne, og det blev i høj gradogså resultatet. Anonymiteten betyder, at det ikke ermuligt for rapportens læsere at forholde sig til par-ternes egen fremstilling af projektforløbet. Ogsådette forhold understreger, at man ikke kan brugerapporten til at bedømme fejlene i det enkelte pro-jekt.

Arbejdsgruppen er ikke gået i dybden med deenkelte projekters teknologiske kvalitet, fx spørgs-mål om valg af platform, systemarkitektur, funktio-nalitet eller brugergrænseflader. Det skyldes dels, atfællesmængden mellem projekterne teknologisk set

er meget begrænset. Dels at det vil det kræve langtflere ressourcer, end arbejdsgruppen har haft tilrådighed, at komme til bunds i projekternes tekniskeproblemer. Til det formål er offentligheden bedretjent med den type efterforskning, der blandt andeter foretaget i den såkaldte vismandsrapport omAmanda-systemet.

Øget fokus på områdetDenne rapport er den første større danske analyse,der går på tværs af flere store offentlige IT-projekterog de involverede parter, og som bygger på selvstæn-dige empiriske undersøgelser af projekterne. I løbetaf de sidste år har der dog fra flere sider været satfokus på de offentlige IT-projekter. Det gælder blandtandet:

• Rigsrevisionen: ”Beretning til statsrevisorerne omgennemførsel af statslige edb-projekter”

• Dansk Dataforening: ”10 dogmer for offentlige IT-projekter” og ”5 holdninger til offentlige IT-projekter”

• PLS Rambøll Management: ”IT i Praksis 2000”• Rapport fra ekspertgruppen vedrørende Arbejdsfor-

midlingens edb-system: Amanda.

Disse rapporter har fra hver deres synsvinkel belysten række af områdets problemstillinger. Arbejds-gruppen har ikke forholdt sig direkte til disse rappor-ters konklusioner, men blot konstateret, at der på enrække punkter synes at være sammenfald i syns-punkter og forslag. Det samme gælder resultaterneaf undersøgelser af erfaringerne med offentlige IT-projekter i lande som England, Sverige og Norge. Derer henvist til både de danske og de udenlandskepublikationer i rapportens litteraturliste.

Regeringen har i dette projekts løbetid desudentaget en række initiativer på området. Den har opret-tet Statens IT-råd og IT-forum, hvor ledende embeds-mænd skal samle gode og dårlige erfaringer fraoffentlige IT-projekter. I forbindelse med behand-lingen af finansloven for 2001 gav regeringen i efter-året 2000 tilsagn om, at man vil:

• vurdere, om der er behov for at justere bevillings-reglerne, sådan at der fastsættes regler om risiko-vurdering af et projekt, inden det forelæggesFinansudvalget,

• vurdere, om de nuværende standardkontrakter eregnede til IT-projekter samt udarbejde nye og merefleksible modeller for udbud og kontrahering afsystemudviklingsprojekter,

• udarbejde en vejledning om ”best practice” forstyring af statslige udviklingsprojekter og tilbydekollegial rådgivning til ministerier, der står over fornye udviklingsopgaver.

Arbejdsgruppen har holdt sig orienteret om disseinitiativer og en række af rapportens anbefalingerretter sig mod dette arbejde.

4

Rapportens opbygningRapporten er delt i fire kapitler. De indledes alle meden kort sammenfatning, og kapitel 2, 3 og 4 afsluttesmed arbejdsgruppens anbefalinger.

Kapitel 1 beskriver kort, hvordan sammenhængenmellem teknologiudvikling og kravene til den offent-lige forvaltning efter arbejdsgruppens vurdering vilpræge vilkårene for kommende offentlige IT-projek-ter. Kapitlet sætter blandt andet fokus på behovet fordigital forvaltning, det vil sige en gennemgribendedigitalisering af den offentlige sektor. Det skitseres,hvilke krav denne udvikling stiller til den teknologis-ke infrastruktur og ikke mindst til omstillingen afden offentlige forvaltning. Fremtidens IT-systemervil blandt andet kræve et langt stærkere samarbejdepå tværs af de nuværende grænser i den offentligesektor – med deraf følgende krav til sektorens politis-ke og administrative ledelse.

Kapitel 2 gennemgår de politiske, juridiske og admi-nistrative rammebetingelser, der er fælles for alleoffentlige IT-projekter, og som på en række punkteradskiller dem fra tilsvarende projekter i privat regi.Det drejer sig blandt andet om valget af teknologiskløsningsmodel, om den politiske beslutnings- ogbevillingsproces, om samarbejdet mellem ministeri-erne, om fortolkningen af EUs udbudsregler, om deeksisterende standardkontrakter og endelig om densærlige mulighed for offentlig indsigt i projekterne.Kapitlet undersøger, i hvor høj grad disse særligerammer kan forklare problemerne i de offentligeprojekter, og peger på muligheder for at ændre ram-merne eller udnytte dem bedre.

Kapitel 3 behandler den store del af problemerne i deundersøgte IT-projekter, der skyldes interne forhold iden offentlige købers organisation. Det sætter kritiskfokus på, hvordan man har forstået, prioriteret ogstyret projekterne. Blandt de spørgsmål, der belyses,er ledelsens rolle, manglen på strategiske målsæt-ninger for projekterne, modningen af købers organi-sation samt endelig en række mere konkrete proble-mer i styringen af projektforløbene. Kapitlet viser, atde offentlige organisationer generelt ikke har væretmodne til at gennemføre så store projekter på en til-strækkelig professionel måde.

Kapitel 4 identificerer de problemer, der knytter sigtil leverandører og konsulenters rolle og indsats iprojekterne. Der sættes blandt andet spørgsmåls-tegn ved om disse professionelle parter har gjort nokfor at advare om og forebygge de problemer, projek-terne løb ind i. Kapitlet behandler også samspilletmellem køber, leverandør og konsulent. Det gælderdels den stramme kontraktstyring af projekterne,dels den offentlige købers forholdsvis ukritiske brugaf private konsulenter.

Appendiks 1 opstiller skematisk en række gode råd tilden praktiske gennemførelse af IT-projekter. Appen-dikset er udformet som en checkliste for den ledelse,der har det overordnede ansvar for et projekt.

Appendiks 2 beskriver kort de vigtigste faktuelle for-hold omkring de fem IT-projekter, arbejdsgruppenhar gennemgået og analyseret.

5

1.1 SammenfatningDen danske offentlige sektor har gennem en langperiode anvendt informationsteknologien relativtavanceret sammenlignet med andre lande. Det harblandt andet kunne lade sig gøre, fordi Danmark pået tidligt tidspunkt fik gennemført en entydig identi-fikation af den enkelte borger via CPR-nummeret ogaf virksomheder via SE-nummeret.

Skal Danmark fortsat kunne være i front med atudnytte IT til at løse de offentlige opgaver, må enrække grundlæggende og til dels nye forudsætning-er stå klart for den politiske og administrativeledelse i den offentlige sektor:

For det første at borgerne vil efterspørge en IT-base-ret service fra det offentlige, der mindst er på niveaumed den, de vil opleve fra de mest avancerede priva-te virksomheder. Det vil blandt andet sige let og sik-ker adgang til at kommunikere, indberette, bestille,betale og få målrettet og præcis information via net-tet.

For det andet at det i kommende IT-projekter ikke vilvære teknologien, der sætter grænser for, hvilkeoffentlige opgaver der kan udføres elektronisk. Denvigtigste barriere for nye projekter bliver det offent-liges egen evne til at realisere de teknologiske poten-tialer.

For det tredje, at behovet for IT-systemer i fremtidenvil gå på tværs af eksisterende administrative enhe-der og dermed kræve, at den offentlige sektor koordi-nerer sine aktiviteter langt bedre end i dag.

Det betyder alt andet lige, at problemerne med90’ernes IT-projekter, der beskrives i denne rapport,vil blive forstærket i morgendagens projekter. Der-med skal indsatsen for at undgå eller minimere demstyrkes tilsvarende, og det stiller store krav til ikkemindst den øverste politiske og administrativeledelse.

Dette kapitel beskriver kort, hvilke udfordringerIT-udviklingen stiller den offentlige forvaltning overfor. Der er ikke forsøgt at beskrive teknologiensmuligheder nøjere eller på længere sigt. Vægten erlagt på at illustrere, hvad det kræver af den offentligeforvaltning, hvis teknologien skal udnyttes til at løsehelt nye og langt mere komplicerede offentlige opga-ver.

1.2 Den teknologiske og administrative udviklingUdviklingen og anvendelsen af administrative IT-systemer i den offentlige sektor har ændret og udvi-det sig kraftigt i løbet af de seneste årtier. De førstestørre systemer blev indført i slutningen af 1950’erneog 60’erne. De blev primært brugt til at automatiserekendte rutiner, der var knyttet til håndteringen afstore datamængder – herunder beregning og regis-trering af data. Det gjaldt fx løn-, bogholderi- og skat-teopgaver.

De tekniske løsninger var baseret på centrale sys-temer, og først senere blev der adgang til de centraltregistrerede data via terminaler. Indtil midten af80’erne blev stort set alle de større IT-udviklingsop-gaver i staten varetaget af Datacentralen, der ogsåstod for driften af systemerne.

Teknologisk er der sket en fortsat hastig udvikling afsåvel hardware som programmel. Kapaciteten til atlagre, behandle og overføre selv meget store data-mængder (herunder billeder) er ikke længere nogenhindring for de ønskede opgaveløsninger – hverkenteknisk eller økonomisk. Teknologien har også fjer-net begrænsningerne i den fysiske placering af defremtidige systemer.

I kommende IT-projekter vil det med andre ordikke være teknologien, der sætter grænser for, hvilkeoffentlige opgaver, der vil blive løst eller understøttetelektronisk via digitale net. Begrænsningerne vilførst og fremmest ligge i den offentlige sektors evnetil at gennemføre projekterne og de store nødvendi-ge omstillinger, det vil kræve at opnå de økonomiskeog servicemæssige fordele ved investeringerne. Dekrav til den offentlige organisation, der allerede i dager forudsætningen for at gennemføre vellykkedeprojekter, vil blive yderligere forstærket.

Organisatorisk set, var der var typisk tale om auto-matisering af velkendte arbejdsrutiner samt enklerationaliseringer, der kun medførte overskueligeomlægninger og nedskæringer i begrænsede dele aforganisationen. De senere års IT-projekter går ander-ledes på tværs af hele organisationen og forudsættertypisk dybtgående omlægninger og tilpasninger afdenne.

Man kan på nogle områder sammenligne fremti-den for IT-anvendelsen i det offentlige med udvik-lingen i den finansielle sektor. Også her findes enor-me datamængder, et kompliceret ”regelsæt” samtstore krav til systemernes sikkerhed, tilgængelighedog troværdighed. Finanssektoren har gennemførtmeget store rationaliseringer og serviceforbedringer,og samtidig er kundernes brug af bankens filialnet ivid udstrækning afløst af betalingssystemer, dan-kort, telefonbetjening og betjening via internettet.

6

Nye krav til IT i det offentlige

Kapitel 1

Denne udvikling er allerede i gang flere steder i denoffentlige sektor – fx inden for skat og lønindberet-ning. Og i de kommende år må der forventes et sta-digt stigende pres for at gennemføre den på nyeområder. Dels fordi der vil være store samfunds-økonomiske fordele herved. Dels fordi borgerne vilkræve de samme IT-løsninger og forbedringer af detoffentlige, som de er vant til på andre områder, ogsom de derfor ved kan lade sig gøre. Det vil imidler-tid kræve en langt større tværgående koordinering,hvis borgerne fx skal have mulighed for at indberet-te oplysninger – og kunne nøjes med at gøre det éngang

1.3 Forventninger til den offentlige serviceBorgere og virksomheder vil i fremtiden forlange atfå netop de informationer fra det offentlige, der errelevante for dem, præsenteret let tilgængeligt . Ogde vil forvente, at de kan ordne deres mellemvæ-render med det offentlige via nettet. Det vil i praksiskunne betyde, at dialogen mellem borger og myn-dighed bliver struktureret efter ”begivenheder” – såsom fødsel, flytning, ægteskab o.l. Myndighedensinformation til og dialog med borgeren kan så tilpas-ses de aktuelle behov. Og borgere og virksomhedervil typisk være ligeglade med, hvilken myndighed,der leverer de relevante informationer og data, blotde får dem hurtigt og præcist.

Konkret vil borgere og virksomheder fx forvente:

• at få direkte adgang til at kommunikere elektroniskmed deres ”sagsbehandler”og løbende at kunnefølge sagens gang.

• at kunne indberette oplysninger via nettet, og atoplysningerne kun skal indberettes én gang.

• at kunne benytte såkaldte ”intelligente blanketter”,som selv henter de nødvendige og tilgængeligeoplysninger og sender dem videre til den eller derelevante myndigheder.

• at en større del af sagsbehandlingen kan foregåautomatisk fx via forskellige former for elektroniskebeslutningssystemer.

• at offentlige myndigheder har en udstrakt – mendog reguleret – adgang til hinandens oplysninger påtværs af organisatoriske grænser.

• at kunne foretage samlede betalinger over nettet tilde offentlige myndigheder.

• at kunne få adgang til oplysninger om egne data.

For hver enkelt offentlig institution eller myndighedbetyder disse forventninger, at den i løbet af relativtfå år skal blive i stand til:

• at publicere på nettet og stille information om sigselv til rådighed på en let tilgængelig måde.

• at foretage digital sagsbehandling og i øvrigt kunnebesvare alle henvendelser digitalt.

• at arkivere digitalt.• at stille selvbetjeningssystemer til rådighed.• at få IT-systemerne til at hænge sammen med de

respektive forvaltningsopgaver over for gruppersom fx studerende, patienter, tilflyttere, småbørns-forældre etc.

• at købe ind på nettet, således at indkøb hængersammen med økonomisystemerne. Det offentligeskal over en bred front kunne betjene sig af indkøb-sportaler, som er integreret i de øvrige administrati-ve systemer.

En del af disse muligheder er allerede realiseretinden for enkelte sagsområder og i enkelte forvalt-ninger. Men der er endnu meget lang vej at gå, indendet er gennemført på tværs af forvaltningerne.

1.4 Nye krav til offentlig ledelseDet vil være naturligt, at regeringens meget klareudmeldinger om, at Danmark skal være førende påIT-området, bliver udmøntet i konkrete tiltag indenfor det offentlige. Et oplagt eksempel på såvel mulig-heder som udfordringer er sundhedsvæsenet. Her vilen fælles udnyttelse af de teknologiske mulighederfor at få en samlet registrering af patientdata bådekunne give bedre patientbehandling, bedre serviceog betydelige besparelser. Det kræver imidlertid, atder også er politisk enighed om en sådan samlet løs-ning og om at sætte kraft bag den.

I den private sektor er der talrige eksempler på, atde mange informationer i IT-systemerne anvendestil styrings- og ledelsesformål. Det sker ofte på tværsaf de administrative systemer, fx ved at opbygge etsåkaldt data-warehouse, hvor de relevante dataopbevares, så de hurtigt kan kombineres og bearbej-des på nye måder. Det kan fx være til at belyse denforretningsmæssige udvikling på forskellige områ-der, følge op på udviklingstendenser mv.

Offentlige IT- systemer giver på tilsvarende mådebåde den politiske og administrative ledelse mulig-hed for langt hurtigere og mere præcist end i dag atvurdere udviklingen i den offentlige sektor – fx følgeop på konsekvenserne af ændret lovgivning. Detkræver imidlertid igen, at der opstilles krav til koor-dinering og samarbejde på tværs af de nuværendeadministrative inddelinger.

De påkrævede investeringer i den teknologiskeinfrastruktur skal endvidere følges op af investering-er i organisationsudvikling og de menneskelige res-sourcer. Der skal udvikles kompetence til både atgennemføre de nødvendige store IT-satsninger ogudnytte resultaterne af dem. En så gennemgribende

7

omstilling vil ikke kunne realiseres uden en syste-matisk efter- og videreuddannelse af både ledere ogmedarbejdere i den offentlige forvaltning.

Behovet for at styrke forvaltningens IT-kompeten-ce gælder både evnen til at gennemføre og lede IT-projekter, der er knyttet til en faglig kompetence,samt evnen til på brugerniveau at kunne udnytte oganvende systemernes muligheder. Det handlerblandt andet om at udforske, hvordan IT kan integre-res i organisationen og understøtte en professionelsagsbehandling – ofte i samspil med kompetenteborgere.

Når det gælder fremtidens store offentlige IT-pro-jekter, kan der drages tre hovedkonklusioner af detendenser, der er skitseret i dette kapitel:

• For det første, at både behovet og det teknologiskepotentiale for store offentlige IT-projekter måventes at stige markant i de kommende år.

• For det andet, at IT-projekterne organisatorisk set vilblive mere komplekse, fordi de i høj grad skal gå påtværs af eksisterende skel og institutioner i denoffentlige sektor – og dermed også vil udfordredisse strukturer

• For det tredje, at udviklingen i retning af digital for-valtning nok kræver investeringer i den teknologis-ke infrastruktur, men først og fremmest forudsætteren markant satsning på at omstille de offentligeorganisationer og deres medarbejdere til nye måderat arbejde på.

De store offentlige IT-projekters tid er med andre ordførst lige begyndt. Dermed har vi også kun set top-pen af de problemer, projekterne risikerer at stødeind i, hvis de ikke bliver håndteret og koordineretbedre.

Rapportens erfaringer og anbefalinger skal ses idette perspektiv. Ønsket om at bevæge sig i retningaf en sammenhængende digital forvaltning skærpersåledes blot kravene til, hvordan fremtidige IT-pro-jekter i den offentlige sektor bør tilrettelægges.

8

2.1 SammenfatningProblemerne i de fem undersøgte IT-projekter kankun i et vist omfang tilskrives de fælles politiske,juridiske og administrative rammebetingelser, dehar været underlagt. Konsekvenserne af disse ram-mebetingelser bør dels ikke overvurderes, dels er derfaktisk uudnyttede muligheder for at ændre ram-merne eller udnytte dem bedre.

Dette kapitel gennemgår de vigtigste rammebe-tingelser, der er fælles for alle offentlige IT-projekter.Det drejer sig om følgende fem forhold:

• Valg af løsningsmodel: Offentlige myndigheder hargenerelt frie hænder til at vælge IT-løsning. Det hartraditionelt ført til, at myndigheden har krævet spe-cialudviklede systemer i stedet for at overvejemuligheden for at basere sig på eksisterende stan-dardsystemer, hvor dette kan lade sig gøre.

• Bevillingsreglerne og den politiske beslutningspro-ces: Bevillingssystemet er i dag så fleksibelt, at detgenerelt set ikke forhindrer (eller sikrer), at offentli-ge IT-projekter kan gennemføres fornuftigt. Syste-met kan dog være med til fra starten at skabe foroptimistiske forventninger til projektet – herunderrealismen i de fremlagte budgetter og tidsrammer.Det favoriserer typisk også brugen af eksterne kon-sulenter på bekostning af den offentlige institutionsegne ansatte.

• Samarbejdet mellem ministerierne: Samarbejds-kulturen mellem ministerierne indbyrdes er gene-relt alt for svag. Man har forsøgt at etablere tvær-gående initiativer, men der er reelt ingenincitamenter til at dele vigtig viden, fx dårligeerfaringer.

• Udbudsregler og kontraktformer: Danmark fortol-ker EUs udbudsregler mere restriktivt end de flesteandre lande. Problemet forstærkes af, at mangeudbydere vælger at bruge Kammeradvokatens stan-dardkontrakter K18 og K33, der må betragtes somforældede og meget ufleksible.

• Offentlighedsprincippet: Medierne og offentlighe-den har ret til indsigt i de store offentlige IT-projek-ters forløb – og benytter den især flittigt, når projek-terne overskrider budget eller tidsfrister. Det kanbeslaglægge betydelige ressourcer at håndtere etsådant pres fra medier, politikere og offentlighed, ogdet kan gøre det vanskeligere at løse problemermellem køber og leverandør. Men det er selvsagtikke årsagen til projekternes vanskeligheder.

Kapitlet afsluttes med en række anbefalinger til,hvordan rammerne kan ændres eller anvendes, så de

bedst muligt understøtter fremtidens store offentli-ge IT-projekter.

2.2 Valg af løsningsmodelHver enkelt offentlig institution har selv ansvaretfor, hvordan den vil anvende IT til at løse sine opga-ver. Der findes ingen generelle regler på området.Således stilles der ikke fra centralt hold nogen kravom bestemte løsningsmodeller, når et nyt systemskal udvikles. Der findes heller ikke vejledende ret-ningslinjer om valg af teknologi eller lignende.

Inden for staten er der ganske vist udviklet noglefælles, obligatoriske IT-systemer. Det gælder fx Sta-tens Centrale Lønanvisning. Der er også udviklet sys-temer til en hel sektor eller en bestemt opgavetype.Det gælder fx skattesystemer, VUE, AMANDA ogDEMARS. Og som noget nyt i staten tilbyder Økono-mistyrelsen en tilpasset version af standardsystemetNavision til brug i andre statslige institutioner. Mendet mest almindelige er stadig, at hver enkelt myn-dighed finder sin egen løsning. Den har hidtil somregel været at udvikle et skræddersyet system fragrunden.

I nogle tilfælde er det mest hensigtsmæssigt atudvikle helt nye systemer. Standardsystemer til fxskatteadministration og CPR findes typisk hverkenpå markedet eller i andre landes forvaltninger. Derfindes fx heller ikke et lønsystem på markedet, deruden betydelige tilpasninger kan løse de særligeopgaver i det statslige eller kommunale lønnings-væsen.

Mange myndigheder lider dog også af den misfor-ståelse, at deres behov er så specielle, at de pr. defini-tion ikke kan opfyldes af markedets standardsyste-mer. Det er imidlertid arbejdsgruppens vurdering, atbesværet med at indrette arbejdsgangene til eksiste-rende standardsoftware ofte vil være langt mindreend de risici, der er forbundet med at udvikle heltnye, uprøvede systemer. Også selv om standardsy-stemerne først skal tilpasses myndighedens særligebehov, herunder kombineres med et eksisterendesystem.

Denne forståelse er da også så småt ved at bredesig i den offentlige sektor fx:

• Alle almindelige kontorprodukter er i dag standard-systemer – med Microsoft Office som altdomineren-de system.

• Navision indføres nu – med de nødvendige tilpas-ninger – som generelt system til økonomistyring istaten og afløser det specialudviklede SCR-system.

• Økonomistyrings-modulet i VUE er baseret på Ora-cle Financials med ekstraudvikling af moduler tilSCR og SCL. Projektet var oprindelig baseret på etspecialudviklet økonomimodul.

9

Rammerne for statslige IT-projekter

Kapitel 2

Tendensen til at udnytte standardsystemerne, nårdet er muligt, vil reducere de udviklingsomkost-ninger og tekniske risici, der er ved at specialudviklenye systemer. Der er imidlertid også grænser for,hvor meget et standardsystem kan tilrettes, uden atder derved opstår risici i forbindelse med anvendelseaf kommende versioner og i forbindelse med syste-mets ydeevne. Det er i den forbindelse også vigtigt atvære klar over, at det kan være lige så krævende atstyre et IT-projekt, hvor et standardsystem skaludbygges og implementeres. Det skyldes især, at derher vil være de samme eller større krav om at tilpas-se organisationens eksisterende arbejdsgange til detnye system.

2.3 Bevillings- og beslutningsprocessenStatslige IT-projekter finansieres normalt af institu-tionens almindelige rammebevilling til driftsudgif-ter, selv når der er tale om flerårige projekter. Det erkun de helt store projekter, der forelægges særskiltfor Finansudvalget. I de fem undersøgte projekter erVUE, AMANDA og Navision forelagt Finansudvalget,Erhvervssystemet og EASY er finansieret over insti-tutionernes driftsmidler. Men der er ingen klar prak-sis på dette område. Eksempelvis investerer Told-Skat og Økonomistyrelsen hvert år betydeligemillionbeløb i systemudviklingsprojekter, uden atdisse projekter forelægges særskilt for Finans-udvalget. I folketingsårene 98/99 og 99/00 er detsåledes kun 16 ud af over 600 sager i udvalget, derhar vedrørt IT-projekter. Heraf har halvdelenomhandlet AMANDA.

Det er principielt den enkelte minister, der haransvaret for IT-projekter inden for sit ministerområ-de. Det gælder uanset, at projektet i praksis ofte fore-går decentralt i ministeriet, og at ministeren reelthar meget begrænsede muligheder for at sætte sigind i eller følge, hvordan et bestemt projekt forløber.Alligevel vil det være ministeren, der skal stå tilregnskab for projektet over for Folketinget,Finansudvalget og Statsrevisorerne.

Uanset om et IT-projekt forelægges særskilt forFinansudvalget vil den pågældende myndighedtypisk på et tidligt tidspunkt sikre sig den nødvendi-ge opbakning til projektet, således at det kan indgå iministeriets samlede prioritering og evt. i forudsæt-ningerne for en påtænkt lovgivning. Men på dettetidspunkt vil både projektets økonomi og tidsplansom regel være meget usikre. Myndigheden vil idenne fase derfor være tilbøjelig til at lægge vægt påprojektets fordele, mens risici og omkostninger letbliver underbetonet. Problemet med dette er, at ”bor-det fanger”. Når der først en gang er præsenteret ensamlet pris og en tidsplan, er det svært at vende til-bage med en grundigere vurdering af pris og tid,hvis den er mindre optimistisk. Det vil nemt bliveudlagt som et tegn på, at der ikke er styr på projektet– og dermed bringe ministeren i offentlighedens,Folketingets og Finansudvalgets kritiske søgelys.

Problemstillingen bliver meget tydelig, når en

udbudsforretning viser, at de indkomne bud ervæsentligt højere end forventet. Det var fx tilfældet,da udviklingen af Det Centrale Virksomhedsregisterblev udbudt. Skatteministeriet og Danmarks Statis-tik havde længde kæmpet om, hvem der skulle ståfor udviklingen – og i den proces havde de også kon-kurreret om at kunne løse opgaven billigst. Dermedhavde politikerne fra starten fået et alt for optimis-tisk billede af, hvad systemet ville koste. Undervur-deringen af omkostningerne var så at sige indbyggeti beslutningsprocessen.

Hvis forudsætninger som fx budget eller tidsplanfor et IT-projekt ændrer sig i forhold til de oplysning-er, Finansudvalget har fået, skal projektet forelæggesudvalget på ny. Normalt indebærer dette ikke, at denpågældende myndighed som helhed får flere penge.Det pågældende ministerium må typisk spare andresteder i organisationen. Finansministeriet vil kun isjældne tilfælde acceptere, at der samlet tilføres etministerium flere midler, fordi et IT-projekt fordyres.

Bevillingsreglerne har til formål at sikre Folke-tingets indseende og kontrol med regeringen ogadministrationen. De er derimod uegnede somgrundlag for selve styringen af IT-projekter. Og dethar aldrig været meningen, at Finansudvalget skalfungere som en slags bestyrelse for de enkelte minis-teriers virksomhed. I de senere år har FU i en rækketilfælde stillet krav om en regelmæssig rapporteringom større IT-projekter, fx VUE og AMANDA, men ensådan rapportering ændrer ikke på det forhold, atdet er den pågældende minister, der har ansvaret.Derimod betyder rapporteringen naturligvis, at der ien periode sættes særlig politisk fokus på et projekt.

Regeringen har allerede som led i finanslovaftaler-ne i november 2000 taget initiativ til at justere bevil-lingsreglerne. Det er blandt andet tanken, at der skalfastsættes regler for risikovurdering af et projekt,inden det forelægges for Finansudvalget.

Samlet set er bevillingssystemet i dag så fleksibelt,at det næppe kan siges hverken at besværliggøreeller sikre en fornuftig gennemførsel af IT-projekter-ne. Dog er der i systemet indbygget en tendens til atfavorisere brugen af konsulentbistand på bekost-ning af myndighedens egne ressourcer. Det skyldes,at den bevilgede lønsum til myndighedens fastan-satte medarbejdere er væsentlig mindre fleksibel –og meget vanskeligere at få politisk tilslutning til atforhøje – end de driftskonti, der kan bruges til atkøbe ekstern konsulentbistand. Hertil kommer, atprojektledere eller andet nøglepersonale i IT-projek-ter ofte kan være vanskelige eller tidskrævende atindpasse i den eksisterende stillings- og lønstruktur.

2.4 Samarbejdet mellem ministerierneInden for den statslige administration er der ingenudviklet tradition for, at ministerierne trækker påhinandens erfaringer – heller ikke på IT-området.Ganske vist har der gennem årene eksisteret forskel-lige fora for erfaringsudveksling på IT-området,senest Statens IT-Råd og IT-Forum. Men de virkelig

10

værdifulde erfaringsudvekslinger om problemermed IT-projekter foregår usystematisk og bidragerdermed ikke nævneværdigt til en kompetenceop-bygning på tværs af ministerierne.

Manglen på en systematisk opsamling af ogadgang til andres erfaringer er åbenlyst en barrierefor de offentlige IT-projekter. Særlig i betragtning af,at ingen myndighed i sig selv kan opbygge det til-strækkelige erfaringsgrundlag. Dertil foregår udvik-ling af store IT-systemer for sjældent og erfaringernevil derfor ofte være helt eller delvis forældede.

Der er heller ingen tradition for helt eller delvist at”genbruge” IT-systemer, der er udviklet i andre deleaf centraladministrationen. Det kunne fx være sags-behandlings- eller dokumenthåndteringssystemer.Det kan i nogle tilfælde skyldes, at der ikke ikontraktforholdet tages højde for spørgsmålet omlicens eller ophavsret. Men generelt er det snarereudtryk for, at den enkelte administrative enhedopfatter sine opgaver som så specielle, at de kræveren unik løsning. Ministerierne udnytter dermed ikkede ”stordriftsfordele”, der kunne skabes ved at frem-stå som en samlet køber og etablere ”koncernfælles”IT-funktioner.

Også internt i mange ministerier har IT-udvikling-en været ukoordineret. Erfaringer med brugen afkonsulenter og leverandører bliver fx typisk ikkeopsamlet og videreformidlet. Også her kunne minis-terierne med fordel optræde som en stor køber ogevaluere samarbejdet med de enkelte leverandørerog konsulenter. Se kapitel 4. Der er dog nu en tydeligog positiv tendens til, at der her etableres fælles IT-funktioner. Dermed kan der opnås stordriftsfordeleog sikres en ”kritisk masse” af IT-viden i organisatio-nen. Men det er langt fra nogen garanti for en bedrestyring af de store IT-projekter, hvor de ledelsesmæs-sige og organisatoriske aspekter ofte er vigtigere endde rent tekniske. Se også kapitel 3.

2.5 Udbudsregler og kontraktformerEU’s udbudsregler er i dag indarbejdet i myndig-hedernes dagligdag, og de er gennem årene blevetsuppleret med en omfattende og ganske restriktivpraksis, der er fastlagt gennem afgørelser fra Klage-nævnet for Udbud. Det er arbejdsgruppens vurde-ring, at udbudsreglerne i dansk ret fortolkes mererestriktivt end i såvel andre EU-lande som i Kommis-sionen. Grunden til den meget forsigtige kurs erangivelig, at ingen dansk myndighed ønsker at blivepart i en ny Storebæltssag (”køb-dansk-klausulen”).

Denne praksis får imidlertid ganske uheldige kon-sekvenser for netop de store IT-udviklingsprojekter.Det er især to krav, der strider mod projekternesnatur og giver anledning til betydelige vanskelighe-der i praksis: Kravet om udtømmende kravspecifika-tion i udbudsmaterialet og forbuddet mod forhand-ling med tilbudsgiverne. Næppe nogen privatvirksomhed ville iværksætte store komplicerede IT-udviklingsprojekter på grundlag af sådanne regler.Dels forhindrer de en konstruktiv dialog mellem

kunde og leverandør om den optimale løsning indenfor budget og tidsramme. Dels låser de fra starten endynamisk udviklingsproces fast på en række teknis-ke løsninger, der er umulige at specificere i udgangs-punktet og svært eller nærmest umuligt at fravige,når udviklingsarbejdet først er gået i gang.

Det sætter disse problemer i perspektiv, at EUsudbudsreglerne nu har været anvendt i 10 år – såvidt vides uden at et eneste EU-udbud af systemud-viklingsopgaver er blevet vundet af en virksomhedfra et andet EU-land, der ikke havde en afdeling elleren fast base i Danmark.

Selvom udbudsdirektiverne giver en rækkebegrænsninger, er der brug for at se på, hvorledesreglerne kan anvendes i Danmark i dag. Erfaringerneviser nemlig, at det er muligt at anvende reglernemere fleksibelt. Inden for reglerne er der såledesadgang til at lave projektkonkurrencer. Der er fx ogsåmulighed for såkaldte forhåndsmeddelelser, deråbner for en forudgående dialog om projekternesudformning. Dermed kan de potentielle leverandø-rer få mulighed for at forberede sig bedre på projek-tet og kvalificere deres tilbud. Udbudsreglerne for-hindrer heller ikke en faseopdeling af projekter medmulighed for, at et samarbejde bringes til ophør efteren første fase, hvis projektet ikke udvikler sig til-fredsstillende.

Hvad der opleves som begrænsninger i udbudsre-glerne er i mange tilfælde udtryk for, at de offentligemyndigheder i den konkrete udbudsforretning væl-ger en meget stram udbudsform.

Kontrakter om store IT-projekter bliver normaltindgået på grundlag af en af de to standard-kontrakter, K 18 og K 33. De blev udarbejdet af Kam-meradvokaten omkring 1990 for at hjælpe de statsli-ge myndigheder med kontraktforhold i forbindelsemed IT-anskaffelser. De fleste statslige myndighederfølger i dag disse kontraktformer. Det sker angiveligblandt andet fordi, at man herved undgår kritik af deformelle forhold omkring projekterne. Se kapitel 4.Men både kunder og leverandører giver ofte udtrykfor, at disse kontrakter er meget stive og reelt er for-ældede. Enkelte konsulentfirmaer foreslår deresstatslige kunder væsentligt mere fleksible kontrakt-former.

Normalt er der i de statslige kontrakter ikke ind-bygget noget positivt incitament for leverandøren tilat levere den optimale ydelse til kunden. Det kunnefx være i form af en bonus, der udløses, hvis en delle-verance leveres som aftalt. Der synes at være behovfor at udvikle kontraktformer, der både rummer piskog gulerod: Sanktioner, hvis kontrakten mislighol-des, og incitamenter til at overopfylde kontrakten.

Leverandørerne kritiserer bl.a. de nuværende stan-dardkontrakter på følgende punkter:

For det første medfører kontrakterne, at udbyderenaf projektet i praksis kan fraskrive sig ansvaret forgennemførelsen af projektet. På det private markeder det fx almindeligt, at leverandøren har begrænsetsit erstatningsansvar til en vis procentdel af

11

kontraktsummen. Men med K18 og K33 kan leveran-dørens ansvar i de offentlige projekter i princippetgælde udover kontraktsummen og alene værebegrænset af danske erstatningsregler.

For det andet er det almindeligt i kontrakterne at for-udsætte, at leverandøren påtager sig ansvaret fortredjeparts software. I en række tilfælde er sådannekrav ikke realistiske, når leverandøren ikke haradgang til kildekoden, som det fx er tilfældet medMicrosofts produkter.

For det tredje opstår der med de nuværende stan-dardkontrakter ofte tvist om, hvorvidt det er udbyde-rens krav eller leverandørens systembeskrivelse, derskal leveres. I dag er bilag 2 i K18 (kundens krav) fxoverordnet bilag 4 (leverandørens systembeskri-velse). Det har i flere tilfælde betydet, at parterneikke har samme opfattelse af, hvad der skal leveres.Udbyderen har valgt et tilbud, men fastholder, atleverandøren juridisk skal leve op til kundens krav.Det betyder, at de juridiske aspekter fra starten afudviklingsforløbet risikerer at blive dominerende. Seogså kapitel 4.

Regeringen har taget initiativ til at gennemgå denuværende standardkontrakter og vurdere, om derskal udarbejdes nye og mere fleksible modeller forudbudsmateriale og kontrakter til systemudviklings-opgaver. Dette arbejde udføres i et udvalg underForskningsministeriet med deltagelse af juridiskeeksperter og brancheorganisationer. Arbejdsgruppenmener dette arbejde er vigtigt og finder det afgøren-de, at der sker betydelige forbedringer af de nuvæ-rende kontraktformer.

2.6 OffentlighedsprincippetI sager om IT-systemudvikling gælder reglerne omoffentlighed i forvaltningen. Det betyder, at der somudgangspunkt er adgang til almindelig aktindsigt ide dokumenter, der findes i sagen. Retten til aktind-sigt kan dog begrænses, hvor det er nødvendigt for atbeskytte væsentlige hensyn til det offentliges øko-nomiske interesser – fx i forbindelse med kontrakt-indgåelse – eller hvor det er af væsentlig økonomiskbetydning for den virksomhed, oplysningerne angår,at der ikke gives aktindsigt.

Offentlighedens og mediernes interesse samler signaturligt om de situationer, hvor der er problemereller konflikter i forholdet mellem kunde og leveran-dør, eller hvor den offentlige myndighed er interntuenig om, hvordan systemet skal udvikles elleranvendes. For virksomheder, der ikke er vant til atlevere til det offentlige, kan både spilleregler ogmediefokus skabe en vis uro i kundeforholdet, isærhvis der opstår problemer omkring en leverance.

Men der er ingen grund til at tro, at reglerne omoffentlighed og aktindsigt i sig selv skaber proble-mer i forbindelse med styringen af offentlige IT-pro-jekter. Men det forudsætter, at ledelsen hos den

offentlige køber må være indstillet på forklare sigover for offentligheden, hvis der opstår problemer iet projekt. Det kan kræve betydelige ressourcer ogdermed svække den ledelseskraft, der netop skullebruges til at løse problemerne. Dét vilkår er imidler-tid i stigende grad fælles for alle dele af både detpolitiske liv og erhvervslivet. Og det er velkendt, atdet skal besvares med en grundig, kontinuerlig ogåben information til medierne og offentligheden –helst før projekterne bliver udråbt til ”skandaler”.

2.7 AnbefalingerRammebetingelser er per definition vilkår, der kunvanskeligt kan ændres på kort sigt. På de fleste af deområder, der er gennemgået i dette kapitel, er detdog muligt at tilpasse eller udnytte rammerne på enmåde, der kan styrke gennemførelsen af de store IT-projekter. De vigtigste forbedringer vil efter arbejds-gruppens vurdering være:

1. Dæmp ambitionerne om specialudviklede IT-syste-mer. Det bør være praksis ved alle offentlige IT-pro-jekter at vurdere, om organisationens målsætningermed IT-systemet ikke med fordel kan opnås medstandardkomponenter med rimelige tilbygningereller ved at ”genbruge” elementer fra andre offent-lige myndigheders systemer.

2. Moderniseringen af standardkontrakterne K18 ogK33, der er sat i gang, bør sikres høj prioritet. Arbej-det bør munde ud i nye og mere fleksible modellerfor udbud og kontrahering af systemudviklingsop-gaver. Som en naturlig del af dette arbejde bør detundersøges, hvilket spillerum Danmark har for atfortolke EUs udbudsregler bredere end hidtil.

3. Staten bør hvor det er muligt optræde som én storkøber. Dels giver det mulighed for at udnytte stor-driftsfordele og etablere ”koncernfælles” IT-funktio-ner på tværs af centraladministrationen. Dels giverdet mulighed for mere systematisk at opbygge ogudveksle erfaringer med offentlige IT-projekter.Regeringen bør udarbejde retningslinier for, hvor-dan dette kan foregå.

4. Den politiske forståelse af IT-udviklingsprojekter-nes dynamik skal styrkes. Den politiske ledelse skalsikre opbakningen til de overordnede mål og ram-mer for projekterne. Der skal være en klar erken-delse af, at det er umuligt at fastlægge alle krav fraprojektets start, og at der vil opstå ændringerundervejs i udviklingsforløbet. Derfor må de økono-miske rammer også tilpasses i lyset af projekternesrisici. Behovet for politisk forståelse og opbakningbliver endnu større, i takt med at projekterne blivermere komplekse og krydser grænserne mellem fleredele af den offentlige forvaltning.

12

3.1. SammenfatningEn meget væsentlig del af problemerne i de under-søgte offentlige IT-projekter skyldes interne forhold iden offentlige købers organisation. Det gælder isærorganisationens forståelse, prioritering og styring afprojekterne. Alle disse forhold falder i sidste instanstilbage på ledelsen. Men der findes konkrete proble-mer på alle niveauer i den offentlige købers organi-sation: Fra den øverste politiske og administrativeledelse, over projektorganisation og projektledelse tilledere og medarbejdere i resten af organisationen.

Selv om der er betydelige forskelle mellem de femundersøgte projekter, tegner der sig alligevel etfælles mønster:

For det første har IT-projektet ikke været stærkt nokforankret i organisationens øverste ledelse, ellerledelsen har fejlvurderet projektets karakter ogbetydning. Resultatet har været, at IT-projekter medmeget store implikationer for hele organisationensudvikling ikke fra starten har fået de ledelsesmæssi-ge ressourcer og den opmærksomhed, det krævede.

For det andet har der ikke været formuleret præcisemål for IT-projektet, der er set i sammenhæng medorganisationens strategi og mål. Dermed har projek-tet manglet et meget vigtigt styringsredskab. Dethar endvidere været umuligt at vurdere, i hvor højgrad det har styrket organisationens ”forretnings-mæssige mål”, fx bedre service til brugerne, mereeffektiv sagsbehandling og/eller lavere omkostning-er.

For det tredje har ledelsen forsømt at modne organi-sationen, det vil sige gøre den parat til at udvikle oganvende det nye IT-system. Ledelsen har ikke på for-hånd gjort sig klart, hvad det vil kræve at gennemfø-re projektet, og om organisationen overhovedet er istand til at løfte opgaven. Man har både forsømt atskabe den rette forståelse af projektet på alle niveau-er i organisationen og at udvikle de nødvendigekompetencer.

For det fjerde har styringen af hele projektforløbetgenerelt været for dårlig. Blandt andet har projektetikke været bemandet stærkt nok, der har fx mangletrisikostyring, brugerne har været inddraget forkert,og man har forsømt at dele projektet op i korterefaser med løbende leverancer af delsystemer.

Disse fire problemfelter uddybes i dette kapitel, derafrundes med en række anbefalinger.

I en række situationer kan man konstatere, atovenstående problemer ikke undervejs har væretbragt op af de involverede konsulenter og leverandø-

rer, der ellers må forventes at have lignende erfa-ringer fra tidligere projekter. Problemerne i leveran-dørers og konsulenters indsats og i samspilletmellem parterne behandles selvstændigt i kapitel 4.

3.2 Den øverste ledelses ansvarErfaringen fra de undersøgte projekter er, at ledelsensjældent har haft den tilstrækkelige vilje til fra førstedag at tage ansvar for udviklingen af det nye IT-sys-tem. Det gælder såvel arbejdet med at udforme oggennemføre projektet som ibrugtagningen af detfærdige system. Dermed har projektet manglet denledelseskraft, der er en af forudsætningerne for suc-ces. Det har i flere tilfælde skabt tvivl om projektetskurs, og om hvem der egentlig havde ansvaret for atsikre dets fremdrift.

Et stort IT-udviklingsprojekt vil altid have betyde-lige konsekvenser for en organisations struktur, dag-lige virke og udviklingsmuligheder. Det er derfor etalvorligt problem, at der i de undersøgte projekterhar manglet et stærkt og vedholdende engagementfra de øverste niveauer i organisationen. De rentteknologiske problemer i projekterne har i mangetilfælde været langt mindre end de ledelsesmæssige,mens det betydelige underskud af ledelse og ledel-sesansvar i flere tilfælde har udgjort en central risi-kofaktor gennem projekternes forløb.

Den politiske og administrative ledelse har endvi-dere i nogle tilfælde været for svag, når det gjaldt atfastlægge og fastholde de overordnede krav og ram-mer for projektet. Der har fx i flere tilfælde mangleten ledelse, der kunne skære igennem og frasortereforslag, der ikke gavnede systemet som helhed. Kon-sekvensen er blevet, at disse projekter er svulmet op,og systemerne er blevet langt mere kompliceredeend nødvendigt. I VUE-projektet havde institutioner-ne fx den opfattelse, at systemet ikke på noget punktmåtte være dårligere end det bedst kørende systemet eller andet sted i landet. Som ét blandt mangeperifere ønsker krævede et af universiteterne fx atsystemet skulle kunne håndtere de studerende, derdør. Det drejer sig om cirka 10 personer hvert år.

Den øverste ledelse har først og fremmest undladtat sikre, at IT-projektet havde en klar målsætning,der understøttede organisationens strategi (Se ogsåafsnittet om målsætning og strategi på næste side).I andre tilfælde har ledelsen forsømt at gøre projek-tets målsætninger kendte og accepterede i alle deleaf organisationen. Det har blandt andet ført til, atman på andre ledelsesniveauer og blandt de kom-mende brugere opstillede krav og ønsker til syste-met, der byggede på vidt forskellige forestillingerom, hvad systemet skulle bruges til, og hvilke forret-ningsgange det skulle understøtte.

13

Den offentlige organisation

Kapitel 3

I projektets løbende udvikling er det organisationensøverste daglige ledelse, der generelt har forsømt atsætte tilstrækkelig ledelseskraft bag projektet. Hold-ningen på ledelsesniveau i resten af organisationenhar endvidere i en række tilfælde været, at ”den, derlever godt, lever stille”. At den, der ikke tager nogetansvar, kan heller ikke stilles til ansvar. Man har prø-vet at undgå at komme i kontakt med de problemer,der er opstået undervejs. Det har i flere tilfælde førttil, at projektet og projektledelsen blev isoleret iorganisationen. Det betød blandt andet, at der ikkevar tilstrækkelig opbakning fra den øvrige ledelse tilat omstille organisationen og tilpasse forretnings-gangene, inden systemet skulle tages i brug.

Det bør være en af ledelsens hovedopgaver at sikresig en effektiv organisering af hele projektforløbet.Det indebærer blandt andet, at der er en klar forret-ningsgang, hvor ansvar og beslutningskompetenceer placeret på de rette niveauer i projektorganisatio-nen, og hvor den øverste ledelses egen rolle derforogså er synlig. De undersøgte projekter rummerimidlertid mange eksempler på, at ansvar og rollerikke har været klart fordelt. Fx har styregruppensrolle i flere tilfælde været uklar, og deltagerne i grup-pen har ikke fået ordentlig besked om deres funk-tion. Både styregruppe og projektledere har også lidtunder, at projektorganisationen ikke er blevetbemyndiget til at træffe beslutninger og foretageprioriteringer.

3.3 Mangel på mål og strategisk fokusOfte fokuserer man i IT-projekter for ensidigt påteknologien. Det medfører blandt andet, at systemer-ne ikke udvikles til det, de skal bruges til. For eksem-pel stod man i Amanda-projektet meget fast på kortesvartider – altså at søgninger i systemet skulle værehurtige. I takt med at systemet blev mere og merekomplekst, måtte mængden af information, derkunne hentes frem på skærmen for hvert skærm-billede, minimeres for at holde svartiderne nede.Resultatet blev, at en grundregistrering af en ledigtager uhensigtsmæssig lang tid, fordi sagsbehand-leren nu skal hente mange skærmbilleder frem.

Eksemplet viser, at når et projekt først er sat iværk, er der en tendens til, at diskussioner af teknis-ke muligheder og praktiske problemer, stjæleropmærksomheden fra de ”forretningsmæssige” målog de resultater, organisationen ønsker at nå. IT-sys-temet bliver et mål i sig selv – i stedet for et redskabtil at udvikle organisationen i den ønskede retning. Istartfasen er der blevet talt om fordele og bespa-relser ved de nye systemer. Men når udviklingsforlø-bet først er gået i gang, er det hurtigt kommet til athandle om at få det store projekt i havn. De fordele,der var selve udgangspunktet for at investere i pro-jektet, er blevet tabt af syne. Der er således behov foren langt stærkere indsats for at fastholde fokus pådisse mål.

I de undersøgte projekter har der kun i megetringe grad været opstillet målsætninger for syste-

met, der var tænkt sammen med organisationensoverordnede visioner, strategier og planer, og der harmanglet klare og målbare krav til, hvad organisatio-nen skulle have ud af det pågældende projekt. Dethar gjort det svært undervejs løbende at vurdere, omprojektet grundlæggende var på rette spor.

For eksempel blev der hverken i VUE eller Amandafra starten opstillet kvantitative succeskriterier for,hvad systemerne skulle resultere i af besparelser,effektiviseringer eller rationaliseringer. Succeskrite-rierne er i begge tilfælde holdt i meget generellevendinger, der er svære at gøre målbare og følge oppå. De er også kun i begrænset omfang blevetanvendt til at holde projekterne på rette spor ellersom redskab i forbindelse med de ændringer og prio-riteringer, der opstod undervejs.

Nye krav til systemerne er således ikke blevetmødt med krav om tilsvarende at nedprioritere ellerfjerne mindre væsentlige elementer. De samledesystemer er dermed hele tiden blevet pustet op. Ogsåi andre af de undersøgte projekter har der mangletberegninger af, hvad organisationen skulle have udaf IT-projektet – fx i sparede årsværk eller systemres-sourcer. I flere tilfælde har det blandt andet skyldtes,at hverken køber, konsulenter eller leverandørerhavde noget samlet overblik over, hvor store syste-merne ville blive, og hvilke konsekvenser de ville fåfor organisationerne.

Klare målsætninger er også en forudsætning for,at man som ledelse kan vinde forståelse for ogaccept af et projekt i hele organisationen – også hvisdet fx indebærer besparelser eller omstrukturering-er. En tidlig udmelding af målsætningerne giverlængere tid og bedre vilkår for at gøre organisatio-nen moden til ændringerne – herunder gennemførede nødvendige tilpasninger af personalet.

I VUE-projektet var der blandt de højere lærean-stalter fx en udtalt mistro over for systemets erklæ-rede formål: At skabe et bedre administrativt systemfor de højere læreanstalter. Den generelle opfattelsevar, at målet med systemet alene var at styrke minis-teriets kontrol med, hvordan institutionerne forval-tede deres tid og ressourcer. At systemet udelukken-de blev opfattet som et kontrolsystem bremsede foralvor projektets fremdrift. Der gik universitetspolitiki projektet fra den første dag, og systemet fik ikkeden nødvendige opbakning. Målsætningerne medsystemet blev aldrig accepteret og gled hurtigt i bag-grunden. Som en af de involverede har udtrykt det:”Systemet blev født i synd”.

I sommeren 1995 var projektet i dyb krise, og derblev gennemført en række konsulentundersøgelser.Da projektet blev rekonstrueret følte Undervisnings-ministeriet sig derfor tvunget til – på visse beting-elser – at lade institutionerne vælge, om de ville tagesystemet i brug, når det var færdigudviklet. De flesteinstitutioner tog VUEs økonomisystem i brug, menKøbenhavns Universitet og Handelshøjskolen iKøbenhavn fravalgte VUEs studieadministrative sys-tem. Man ønskede ikke at ændre sine studieordning-er og studieadministration til systemet, men valgte i

14

stedet at udvikle sine egne skræddersyede systemer– med de deraf følgende omkostninger.

3.4 Manglende organisatorisk modenhed Skal et større offentligt IT-projekt gennemføres medsucces, må det fra starten forstås og tilrettelæggessom et organisationsudviklingsprojekt, der skalunderstøttes af IT. Det har ikke i tilstrækkelig gradværet tilfældet. Således har den offentlige købertypisk fokuseret for ensidigt på projektets tekniskekonsekvenser og forudsætninger og undervurderetde organisatoriske.

Der er ingen tvivl om, at organisationernes mang-lende modenhed har spillet en vigtig rolle for forlø-bet i alle de fem projekter, arbejdsgruppen harundersøgt. Der er derfor behov for, at den offentligekøber, inden projektet går i gang, kritisk vurderer sinorganisatoriske kapacitet. Det kan enten føre til enmere præcis plan for, hvordan organisationen kanmodnes til at magte projektet, eller til erkendelsenaf, at dét ikke kan lade sig gøre, og at projektet derforikke kan gennemføres, før denne modenhed er tilstede.

Arbejdsgruppen vurderer på baggrund af erfaring-erne fra de undersøgte projekter, at modningengenerelt især bør styrkes på fire områder:

For det første skal der som nævnt i afsnit 3.2 etable-res et stærkere ledelsesmæssigt engagement i IT-pro-jektet på alle niveauer i organisationen – altså ogsåhos mellemledere og ledere af eventuelle decentraleenheder. Der skal særlig skabes forståelse for ogaccept af samspillet mellem organisationens fasteledelsesstruktur og projektorganisationens ledelse. Iét projekt viste det sig fx, at en afdeling i organisatio-nen, der ville blive slutbruger af en vigtig del af sys-temet, ikke svarede tilbage på projektledelsens hen-vendelser, da kravspecifikationen skulle udarbejdes.Ledelsen valgte at fortsætte med den indstilling, athvis folk ikke havde noget at sige, måtte de jo væretilfredse med kravspecifikationen. Det er blot et eks-tremt udtryk for, at organisationernes ledelseslaggenerelt ikke har taget projektet alvorligt nok.

Hvis systemet ikke fra starten sikres opbakningfra alle ledelsesniveauer, vil resten af organisationenheller ikke føle noget ejerskab til systemet, når detskal implementeres. Der er flere eksempler på, at deforskellige ledelsesniveauer på papiret var involvereti projektet, men reelt ikke følte sig forpligtet. I Aman-da-projektet er fx ingen tvivl om, at AF-regionernesønske om større selvstændigt råderum har gjort detsværere for Arbejdsmarkedsstyrelsen at gennemføreudviklingsprojektet i centralt regi. Problemet er ligeså udtalt i VUE-projektet.

For det andet skal der opbygges de nødvendige kom-petencer til at realisere udviklingsprojektet. Det vilblandt andet sige, at organisationen sikrer sig, at denråder over tilstrækkelige interne kompetencer tilnøglefunktioner som blandt andet projektledelse og

kvalitetssikring af IT-projektet. Eller at disse kompe-tencer kan erhverves via uddannelse eller rekrutte-ring af nye medarbejdere. Ofte undervurderer orga-nisationen antallet af medarbejdere, der kræves forat gennemføre det samlede udviklingsprojekt, ogman fokuserer for ensidigt på behovet for teknologi-kompetencer. Resultatet bliver blandt andet, at dersenere i forløbet må bruges uforholdsmæssigtmange ressourcer på at få systemet indarbejdet iorganisationens hverdag.

Det har tydeligvis voldt problemer for flere af deoffentlige organisationer at arbejde projekt- og udvi-klingsorienteret. De har som sagsbehandlende myn-dighed haft en traditionel, hierarkisk organisations-form, der har passet dårligt til organiseringen af etIT-udviklingsprojekt, hvor der især er brug for direk-te ledelsesadgang og ubureaukratiske beslutnings-processer. I praksis har det betydet, at projektorgani-sationen har haft alt for lille beslutningskompetence,og det har berøvet projekterne den nødvendigedynamik og fremdrift. Der har også manglet forstå-else af arbejdsformen, ansvarsfordelingen og kom-munikationsvejene – både hos ledelse og medarbej-dere i organisationen og blandt de direkteinvolverede i projektet.

I flere af de undersøgte projekter har uklareansvarsforhold og kommunikationsveje mellemværts- og projektorganisationen undermineret denhelt afgørende tillid mellem disse. Ofte er der faktiskopstillet ganske fornuftige retningslinier for kom-munikation og ansvar, som blot ikke bliver fulgt. Dethar i flere tilfælde resulteret i, at al kommunikationomkring projektets udvikling er foregået i et lukketkredsløb mellem projektenheden og organisationensøverste ledelse.

For det tredje skal der arbejdes langt mere målrettetpå at skabe en fælles bevidsthed i organisationen omprojektets formål, forløb og konsekvenser. Et IT-pro-jekt forudsætter en betydelig omlægning og harmo-nisering af procedurer og arbejdsgange. Og uden enudstrakt forståelse af dette hos medarbejderne, vilprojektet uundgåeligt skabe usikkerhed eller direktemodvilje i organisationen.

Generelt er det således ikke lykkedes at skabe dennødvendige forståelse i organisationen for, at detnetop er et af formålene med det nye system atændre og effektivisere arbejdsgangene. ”Det måvære teknologien, der skal tilpasses menneskene ogikke omvendt,” lyder en typisk kritik, når et nyt sys-tem udfordrer etablerede vaner og rutiner. Menudsagnet er naturligvis kun fornuftigt, hvis organi-sationen allerede løser opgaverne på den mest effek-tive måde – også med den nye teknologis mulighe-der. Ellers er det en meget dyr undskyldning for ikkeat udnytte de muligheder, den nye teknologi rum-mer.

Modningen af organisationen består her blandtandet i at gøre det klart, at også medarbejderne måændre sig, hvis udviklingsprojektet skal nå sine mål.Denne forståelse er det ofte særlig nødvendig at

15

udvikle hos eventuelle decentrale enheder og bruge-re, der erfaringsmæssigt beder om ganske omfatten-de tilpasninger af systemerne. Men det er vigtigt atgøre det klart, at fælles IT-systemer ikke forhindrer,at man lokalt kan tilrettelægge arbejdet på en fleksi-bel måde, selv om der selvfølgelig må ske en tilpas-ning til det fælles grundsystem.

For det fjerde er det tydeligt, at IT-projekter, der udvi-kles til flere forskellige institutioner (fx NavisionStat) eller til en central myndighed med decentraleenheder (fx Amanda, EASY og VUE) har en væsent-ligt øget risiko for at komme i problemer.

Den øgede risiko skyldes ikke, at sådanne projek-ter nødvendigvis er større eller væsensforskellige fraIT-projekter, der gennemføres inden for én organisa-torisk enhed. Men projekterne involverer typisk flerebeslutningstagere, flere organisationskulturer ogdermed også potentielt flere modstandere. Det erikke mindst fra ledelsen af de decentrale enheder, atmodstanden mod ”standardiseringen” typisk erstærk. Blandt de mest almindelige kritikpunktermod den centrale, systemudviklende myndighed er,at den mangler indsigt i og respekt for behovene hosde decentrale enheder, og at den derfor undervurde-rer, hvor store organisatoriske ændringer systemetkræver lokalt. Imidlertid gør de mange lokale og spe-cielle tilføjelser og ændringer til systemet det unø-digt kompliceret, og det bliver vanskeligere at flyttemedarbejdere rundt i organisationen.

Det er imidlertid tydeligt, at modviljen mod cen-tral indsigt i og kontrol med organisationens arbejdeogså ofte spiller en væsentlig rolle. Og den kritik, derrettes mod det centrale niveau, viser – berettigeteller ej – at modningsprocessen ikke er nået tilstræk-kelig langt ud i organisationen.

3.5 Problemer med at styre projekterne Ud over de nævnte problemstillinger vedrørendeledelse, mål og strategi samt modenhed er der grundtil at pege på en række mere konkrete problemer, derkan sammenfattes som for dårlig styring af IT-pro-jektets forløb. Det drejer sig om følgende områder:

• Projektet bemandes ikke godt nok • Andres erfaringer bliver ikke brugt, egne erfaringer

går tabt• Der mangler risikovurdering • Projektet splittes ikke op i delleverancer• Brugerne inddrages på forkerte præmisser • Problemerne, når systemet tages i brug

Hvert område beskrives nærmere på de følgendesider.

3.5.1 Projektet bemandes ikke godt nokDer er flere eksempler på, at projektorganisationenikke har været bemandet godt nok – hverken kvanti-tativt eller kvalitativt. Man har ikke frigjort de dyg-

tigste medarbejdere til at løse opgaven. I flere tilfæl-de er projektdeltagerne også kun blevet frigjort del-vist fra deres normale arbejde. Det er uheldigt bådefor projektets forløb, og fordi det sender et signal tilhele organisationen, om at projektet ikke har højprioritet.

Problemet er særlig kritisk, når man undervurde-rer betydningen af en erfaren og kompetent projekt-ledelse. Projektlederens kvalifikationer og projekt-faglige indsigt er – sammen med den nødvendigeopbakning fra topledelsen – en af nøglerne til et vel-lykket IT-udviklingsprojekt. Ineffektiv og uerfarenprojektledelse er en anden vigtigste grund til, at IT-projekter mislykkes. Det skyldes blandt andet, at dis-cipliner som projektplanlægning, risikostyring,ændringshåndtering, udformning af aftalegrundlagmv. ikke beherskes godt nok.

I de undersøgte projekter har der været en udpræ-get tendens til at undervurdere, hvor megetprojektledelseserfaringer betyder for organisatio-nens evne til at gennemføre et større IT-projekt.Resultatet har været, at man som regel har brugt demedarbejdere i organisationen, der har erfaring meddriften af et IT-system, men som typisk ikke har erfa-ring fra store projektforløb eller det nødvendige blikfor organisationens arbejdsgange og udviklingsbe-hov.

Fraværet af erfarne og kompetente projektledere iprojektets startfase medfører, at der ikke fra begyn-delsen etableres en professionel projektstyring. Der-med bliver det vanskeligt at styre og matche leveran-døren, når det fx handler om fremdriftsstyring,godkendelsesprocesser og kvalitetssikring af leve-rancerne. Den mangelfulde forvaltning af projekt-ledelsesansvaret er i flere situationer blevet etproblem for både køber og leverandør. For når pro-jektledelsen ikke er stærk nok til at skære igennemog sortere og prioritere ændringsforslagene, bliveralt for mange uafklarede spørgsmål ved med atdukke op som uoverensstemmelser mellem køber ogleverandør.

En af årsagerne til den svage projektledelse er, atdet offentlige generelt har svært ved at rekruttere,uddanne og fastholde kvalificerede projektledere ogmedarbejdere med erfaringer i projektarbejde. Da defleste offentlige institutioner kun gennemfører stør-re IT-projekter med års mellemrum, er det også van-skeligt at bevare den nødvendige ekspertise. Hertilkommer, at projektledelse ikke er en naturlig karrie-revej inden for det offentlige. I stedet har man imange tilfælde valgt at købe sig til projektledelses-kompetencer hos private konsulenter. De problemer,dette indebærer, er nærmere beskrevet i kapitel 4.

3.5.2. Andres erfaringer bliver ikke brugtSkal offentlige institutioner i fremtiden forbedrederes muligheder for at realisere succesfulde IT-pro-jekter, forudsætter det, at der iværksættes systema-tiske evalueringer, der kan opsamle både gode ogdårlige erfaringer med de gennemførte IT-projekter

16

– og herunder ikke mindst erfaringer med de invol-verede leverandører og konsulenter.

I betragtning af de mange problematiske IT-forløbi det offentlige, er det påfaldende, at en sådan syste-matisk erfaringsopsamling og vidensformidlingførst nu er ved at blive sat i værk gennem Statens IT-råd. Se også kapitel 2. Endnu mere bemærkelsesvær-digt er det, at der i ingen af de undersøgte IT-projek-ter fra starten er gjort grundige forsøg på atindhente erfaringer fra lignende projekter. IT-projek-terne er blevet gennemført uden kvalificeret videnom, hvad der er gået galt i tidligere projekter. Man ergroft sagt startet forfra hver gang.

Det er selvsagt ikke alle erfaringer, der kan overfø-res fra projekt til projekt. Dels er både de offentligeorganisationer og deres IT-projekter meget forskelli-ge. Dels ændrer de teknologiske præmisser sig medstor hast. Alligevel vil mange af de processer, projek-terne består af, være ens. Det gælder erfaringer medområder som modning af organisationen, ledelse,brugerinddragelse, risikovurdering, udbudsreglermv.

Den manglende udnyttelse af erfaringerne påtværs af især den statslige sektor understreger beho-vet for at styrke samordningen mellem ministerier-ne på dette område. Staten har nogle oplagte mulig-heder i at optræde som en meget stor og stærk køberfx i forhold til den enkelte leverandør, der ikke leverop til sine forpligtelser. Men det forudsætter, at cen-traladministrationen i disse spørgsmål i højere gradformår at fremstå som én organisation, der koordi-nerer sine erfaringer og sin efterspørgsel, end som20 ”indbyrdes konkurrerende” ministerier.

3.5.3. Der mangler risikostyring Store IT-udviklingsprojekter rummer altid betydeligerisici. Det tekniske og organisatoriske samspil, derskal etableres, er så komplekst, at uforudsete proble-mer og afvigelser fra planerne undervejs er uundgå-elige. Så meget desto vigtigere er det at foretage ensystematisk risikostyring af projektet. Den skal bl.a.identificere mulige risici, vurdere den enkelte risikossandsynlighed og konsekvenser samt opstille planerfor, hvordan man kan eliminere eller håndtere hverenkelt risiko. Risikostyring er også en god måde atpresse kritiske informationer opad i organisationen,så den øverste ledelse tvinges til at forholde sig tildem.

Der er store forskelle på, hvordan risikostyring harværet anvendt i de undersøgte projekter. Men i fleretilfælde har risikostyringen enten manglet helt ellerværet grebet forkert an. De mest almindelige fejl ogforsømmelser har været:

• Der er en tendens til at fokusere for snævert. Foreksempel tages der ikke højde for potentielle kon-flikter mellem centrale myndigheder og decentralebrugere.

• Der fokuseres alene på faktorer, som ledelsen kankontrollere. Eksempelvis omfattes ændret lovgiv-ning eller ændringer i teknologien ikke af risikovur-deringen.

• Der laves ikke realistiske vurderinger af tids- og res-sourceforbrug. Blandt andet fordi der har været entendens til at undervurdere sagsbehandlingstiden.

• Risikostyringen anvendes ikke systematisk, og vars-ler om nye risici undervejs i forløbet tages ikkealvorligt, og der gøres derfor ikke forsøg på at elimi-nere de registrerede risici.

• Der tages ikke højde for konsekvenserne af, at nøg-lemedarbejdere forlader projektet i utide.

Arbejdsgruppen er desuden bekendt med et enkelttilfælde, hvor organisationen i forberedelsesfasenforsøgte at gennemføre en risikovurdering. Men detblev angivelig opgivet, fordi risikostyring blev opfat-tet som ”djævelens værktøj”: Den ville bare virkelig-gøre problemer, der ellers ikke ville opstå, lødbegrundelsen for beslutningen, som der senere blevrig lejlighed til at fortryde.

3.5.4. Projektet splittes ikke op i delleverancerDet er arbejdsgruppens opfattelse, at store IT-projek-ter, der besluttes, udvikles og implementeres ”i éthug”, hører fortiden til. Al erfaring – også fra deundersøgte projekter – taler for, at totalprojektet skalsplittes op i mindre delprojekter. Hvert delprojektbør løbe over maksimalt 6 måneder og som tommel-fingerregel ikke involvere mere end cirka 30 IT-folkog lige så mange brugere. Delprojekterne skal væreselvstændige, afgrænsede og brugbare dele af total-løsningen, som kan implementeres trinvis. Det ertypisk vanskeligt at opdele projekter, der er tilrette-lagt ud fra en række krav til det nye IT-systems funk-tionalitet. En vigtig forudsætning for en fornuftigopdeling i delleverancer vil derfor typisk være at til-rettelægge udviklingsprojektet efter, hvilkeforretningsprocesser og arbejdsgange systemet skalunderstøtte. Dette skal naturligvis også afspejle sig ikravspecifikation og projektplaner. Det kræver imid-lertid en anden måde at arbejde på og opdelingen afprojekterne kan give andre risici.

For en sådan opsplitning af projekterne taler imid-lertid en lang række forhold:

• Det letter en løbende udviklingsproces, hvor manhele tiden bliver klogere

• Det bliver lettere at specificere præcise krav til hverdel – og løbende følge op på, at disse krav opfyldes.

• Det bliver muligt at sadle om undervejs, hvis detekniske forudsætninger for projektet ændrer sigafgørende.

17

• Tids- og ressourceforbruget bliver lettere at styre.

• Idriftsættelsen kan foregå gradvis, og brugerne kanbedre vænne sig til systemet.

• Der bliver bedre mulighed for ændringer undervejs,hvis kravene til systemet ændrer sig i løbet af udvi-klingsperioden, fx på grund af ny lovgivning e.l.

• Det giver bedre muligheder for helt at afbryde pro-jektet undervejs, når enkelte dele af projektet er ble-vet leveret og kan bruges.

Hver af disse faktorer øger chancen for, at projektetsoverordnede målsætninger kan nås. I flere af deundersøgte projekter har man fravalgt opdelingen idelleverancer, fordi det angivelig ville fordyre detsamlede projekt. I realiteten ville det formentlighave været langt billigere.

I mindst et af projekterne er det blevet overvejet atsplitte systemet op i flere dele, men køber er blevetfrarådet denne løsning. Arbejdsgruppen finder detbetænkeligt, at leverandører og konsulenter ikkeover for den offentlige køber har støttet køber i, at såstore projekter skulle splittes op.

3.5.5. Brugerne inddrages på forkerte præmisser Det er en selvfølge, at man inddrager brugerne, istore offentlige IT-projekter. Dels sidder mange bru-gere inde med dyb specialviden, der er afgørende forat udvikle systemet. Dels er accepten hos slutbruger-ne og deres repræsentanter i projektet helt afgøren-de for, at det færdige system får succes i praksis.

Men i flere af de undersøgte projekter er bruger-inddragelsen løbet af sporet. En eller flere af de føl-gende forhold har typisk skabt problemer:

For det første har flere af projekterne – i bestræbelsepå en grundig inddragelse af brugerne – involveretså mange brugere og brugergrupper, at det harværet uoverskueligt at systematisere og koordinerederes krav. Det er en myte, at inddragelse af mangebrugere er lig med et succesfuldt IT-projekt. Samtidiger det ikke altid de dygtigste medarbejdere, der ind-drages i brugergrupperne.

For det andet er det ofte specialisterne blandt bru-gerne, der dominerer. Dermed bliver enkeltområderdækket godt ind, mens der er for få der tænker i heleprocesser. Alle stiller krav, men ingen kan overskuekonsekvenserne for hele systemet. Desuden er detoftest ”gratis” for de specialiserede brugere at bedeom ændringer inden for deres eget specialområde,fordi de ikke har noget direkte ansvar for IT-projek-tets økonomi eller for systemets samlede funktiona-litet.

For det tredje har deltagerne i brugergrupperne sjæl-dent nogen dyb indsigt i, hvor realistiske deres kraver – hverken teknisk, økonomisk eller i forhold tilsystemets overordnede målsætninger. De opstillerkrav og ønsker ud fra hver deres – ofte meget forskel-lige – forestillinger om, hvad systemet skal brugestil.

For det fjerde kan det være vanskeligt for brugerneat danne sig en forestilling om, hvordan det endeligesystem konkret kommer til at se ud. Systemet forbli-ver abstrakt, indtil brugerne får mulighed for at testeproduktet i praksis. Brugerne risikerer dermed atoverse både muligheder og begrænsninger i det nyesystem, når de opstiller deres krav. Dette problemkunne mindskes væsentligt, hvis systemet blevopdelt i moduler, der blev implementeret løbende. Seogså afsnit 3.5.4.

Hovedproblemet i brugerinddragelsen er imidlertiden alt for svag styring af, hvordan en stor mængde afvidt forskellige brugerkrav skal omsættes i operatio-nelle beslutninger. Brugernes krav skal udfordres afprojektledelsen, så de vurderes i forhold til både dettekniske design og succeskriterierne for det samledeprojekt. Ellers eksploderer projektet mellem hænder-ne på deltagerne.

På grund af for svag projektledelse er alt formange ønsker og krav ukritisk enten blevet sat ind ikravspecifikationen og/eller gennemført somændringsanmodninger i udviklingsforløbet. Det hari en række tilfælde direkte forringet systemets funk-tionalitet, og det har forsinket og fordyret udvi-klingsprocessen. Som et grelt eksempel diskuteredeen brugergruppe i et halvt år med leverandøren,hvorvidt en menubjælke i systemet skulle være blåeller grå. Der stod blå i kravspecifikationen, men aftekniske grunde kunne den kun blive grå. Først efteret halvt år greb projektledelsen ind, og brugergrup-pen accepterede den grå farve.

3.5.6 Uventede problemer,når systemet tages i brug Når et nyt IT-system skal tages i brug, bliver det foralvor synligt, om organisationen er parat hertil.

Det er ikke mindst af hensyn til medarbejderne, atibrugtagningen skal varsles og forberedes i god tid.Det gælder især, fordi den som regel ledsages aforganisatoriske omlægninger og afskedigelser. Hergiver en længere tidshorisont bedre muligheder forfx at sætte ind med uddannelse og at gøre tilpas-ningen af medarbejderstaben mindre smertefuld.Det taler også for at tage systemet i brug trinvist.

Det er gennemgående i flere projekter, at man harhaft urealistiske forventninger til, hvordan indkø-ringen af det nye system ville forløbe. I et enkelt pro-jekt var opfattelsen i starten fx, at man bare kunnegive brugerne programmet på disketter, og så villede selv klare resten. Det vil blandt andet sige tilpasseorganisationen, indkøbe den rette hardware oguddanne brugerne.

18

I de undersøgte projekter har der blandt andetværet et eller flere af de nedenstående problemer,når IT-systemerne skulle tages i anvendelse:

• I flere tilfælde er undervisningen af brugerne blevetforvekslet med tilpasning af arbejdsgangene. Manhar uddannet superbrugere, der skulle underviseandre brugere, men glemt at få tilpasset arbejds-gangene til det nye system. Den nødvendige om-stilling kræver mere end blot uddannelse. Og ud-dannelsen skal desuden være bredere end den renttekniske betjening af det nye system.

• Processen med at sikre datakvalitet og konverte-ringen af data fra det gamle til det nye system erblevet undervurderet. Den er ofte er lige så vanske-lig at håndtere som selve udviklingsprojektet. Bru-gerne informeres typisk heller ikke om komplikatio-nerne i forbindelse med konverteringen – fx hvilkedata der vil og ikke vil være til rådighed i det nyesystem.

• Der er ikke afsat tilstrækkelige ressourcer til atuddanne brugerne eller til at nedbringe puklen afindkøringsvanskeligheder, fx i form af en stærktbemandet helpdesk.

• Udvikling og drift varetages af forskellige leveran-dører. Dermed slipper leverandøren systemet forhurtigt, og dennes viden om systemet bliver ikkebrugt effektivt nok til at udbedre de fejl og mangler,der viser sig i systemets første driftsmåneder.

• Kommunikationen om systemets indkøring er forupræcis – både til medarbejderne og til omverde-nen. Dermed skabes der forkerte forventninger til,hvor hurtigt organisationen kan få det optimaleudbytte af systemet. Det fører let til skuffelse og kri-tik, der i sig selv bliver en yderligere barriere for eneffektiv idriftsættelse.

3.6 AnbefalingerPå baggrund af de problemer, der er beskrevet i dettekapitel, anbefaler arbejdsgruppen følgende:

1. Ledelsens ansvar for IT-projektet skal gøres heltentydig, og projektet skal forankres stærkt i denøverste ledelse. Der bør i direktionen være enhovedansvarlig for projektet. Der skal knyttesstærkere karrieremæssige eller økonomiske incita-menter til deltagelse i store IT-projekter for bådeledelse og medarbejdere.

2. Projektledelsen bør – før det besluttes at udviklesystemet – udarbejde et samlet ”prospekt”, derredegør for de overordnede forhold omkring pro-jektet, som alle projektets interessenter har kravpå at kende. Det vil som minimum sige:

• En klar målsætning, der er målbar og integreret iorganisationens samlede strategi.

• En cost-benefit analyse af totalprojektet.• Et ”feasability-studie”, der kortlægger organisatio-

nens forudsætninger for at indlede projektet.• En handlingsplan for, hvordan organisationen i givet

fald kan modnes til at udvikle og modtage systemet– fx hvilke ændringer i arbejdsgange, kompetencerog ledelse, der er brug for.

• En risikovurdering af projektet og retningslinier forden løbende risikostyring.

Prospektet bør tidligt danne udgangspunkt for dialo-gen med medarbejdere, politikere, medier og de leve-randører og konsulenter, der indgår i projektforløbet.Det bør løbende ajourføres og bruges aktivt underhele projektforløbet.

3. De bevilgende myndigheder bør som hovedregelkræve, at det store samlede IT-projekt splittes op idelprojekter med løbende leverance. Som tommel-fingerregel bør hver leverance i projektet højstvare 6 måneder og omfatte omkring 30 udviklereog lige så mange brugere. Der skal være fleksibili-tet mellem leverancerne, så erfaringerne fra enfase kan udnyttes i den næste. For at lette ensådan opdeling bør kravspecifikationer og projekt-planer fokusere på, hvilke forretningsprocesser ogarbejdsgange systemet skal understøtte.

4. I forlængelse af regeringens løfte om at tilbydekollegial rådgivning til ministerier, der står overfor nye udviklingsopgaver, bør der indledes en sys-tematisk og dokumenteret erfaringsopsamling afenkelte IT-projekter. Regeringen bør også tage ini-tiativ til at etablere et netværk af professionelleprivate og offentlige projektledere, der kan stillederes erfaringer til rådighed for nye projekter. Pro-jektledelsen bevarer selv det fulde ansvar for pro-jektet, men skal forpligtes til at konsultere netvær-ket såvel i startfasen som senere i projektforløbet.

19

4.1 SammenfatningSom det fremgår af kapitel 3 bærer køber en stor delaf ansvaret for de problemer, IT-projekterne er hav-net i. Men når køber i de fleste tilfælde har engageretkonsulenter og entreret med leverandører, der – imodsætning til køber – må forventes at have videnog erfaringer fra andre projekter, burde en række afproblemerne være undgået. Det rejser spørgsmåletdels om kvaliteten og professionalismen i disse kon-sulenters og leverandørers arbejde, dels om samspil-let mellem de tre parter. Erfaringerne fra de under-søgte projekter viser, at selve samarbejdsmodellenpå centrale punkter er uheldig, samt at leverandørerog konsulenter langt fra altid lever op til deres del afansvaret for et vellykket samarbejde.

Formelt og juridisk er rollefordelingen mellemparterne klar nok. Køber har ansvaret for at udarbej-de kravspecifikationen, vælge leverandør og styredet samlede projektforløb – herunder at kontrollerekvaliteten af leverandørens arbejde. Leverandørenhar ansvaret for at levere den aftalte ydelse, i denrette kvalitet og til tiden. Køber kan vælge at out-source en række tekniske delfunktioner eller afgræn-sede arbejdsopgaver til private konsulentfirmaer.Det kan fx være hjælp til at udarbejde kravspecifika-tion, til projektplanlægning og –styring etc.

Denne rollefordeling fungerer imidlertid ikke ipraksis. Hovedforklaringen på dette er, at de tre par-ter ikke besidder de kompetencer på hinandensområder, der er forudsat i arbejds- og ansvarsforde-lingen. Altså at den ene part forudsætter en videnhos den anden, som ikke er til stede. Eksempelvismangler køber typisk både tekniske og projektfagli-ge kvalifikationer, mens leverandøren savner indsigti offentlige administrative processer i almindelighedog købers organisation i særdeleshed.

Kontrakternes udformning har yderligere bidragettil at komplicere samarbejdet mellem parterne. Pro-blemet har to dimensioner. For det første specificereskravene til IT-systemet så detaljeret i udbudsmateri-ale og kontrakt, at det bliver en spændetrøje i udvik-lingen af systemet. For det andet bliver det kontrak-tens bestemmelser, der kommer til at styreprojektforløbet. Det bliver stiv kontraktstyring i ste-det for fleksibel projektstyring. Se også kapitel 2.

Leverandørsiden bærer også sin selvstændige delaf ansvaret for samspilsproblemerne i projekterne.Der er eksempler på, at leverandøren har svigtet påafgørende punkter – fx ikke har leveret den tekniskeløsning, der var aftalt, eller ikke har ydet sin andel afden nødvendige projektledelse. Der er også flereeksempler på, at leverandøren har manglet afgøren-de kompetencer inden for samarbejde, kommunika-tion, organisationsforståelse etc. Endelig har leveran-døren i flere tilfælde forsømt at sige tydeligt fra, når

køber har krævet urealistiske løsninger eller harorganiseret projektledelsen uhensigtsmæssigt.

Købers brug af konsulenter har i flere af projekter-ne været problematisk. Der har i flere tilfælde mang-let klarhed om konsulentens opgaver og kompeten-cer. Køber har i for høj grad ladet konsulentervaretage strategiske og centrale ledelsesmæssigefunktioner, der principielt skal forankres i organisa-tionens egen ledelse, og konsulenterne har accepte-ret dette. De er således i vigtige faser af IT-projektetblevet skudt ind mellem køber og leverandør. Resul-tatet har været, at organisationens ansvarlige ledelsereelt har afholdt sig fra selv at følge og vurdere pro-jekters udvikling. Samtidig har kontrollen med kon-sulenternes arbejde i en række tilfælde været forlemfældig, hvilket blot skærper problemstillingen.

Konsulenterne selv burde have sagt fra over fordenne udvidelse af konsulentrollen. Ikke mindst i detilfælde, hvor de har påtaget sig funktioner, der reeltlå uden for eller i udkanten af deres kompetence.

De ovenstående problemfelter uddybes i de føl-gende afsnit. Kapitlet afsluttes med en række anbe-falinger til, hvordan samspillet mellem parterne kanstyrkes fremover.

4.2 Samarbejdsmodellen Det grundlæggende problem i relationerne mellemkøber, konsulent og leverandør har ikke været, atparternes respektive ansvar i projektet juridisk sethar været uklart. Det fremgår således af kontraktvil-kårene, at køber er opdragsgiver, projektleder, ejerdet færdige system og har ansvaret for, at det efter-følgende anvendes efter hensigten. Køber har selv-følgelig også ansvaret for, at organisationen ermoden til at bidrage til at udvikle og modtage syste-met. Leverandøren har ansvaret for at overholde deleverancer og aftaler, der er specificeret i kontrak-ten,og for projektets tekniske kvalitet.

For det første bygger samarbejdsmodellen på denfejlagtige antagelse, at det fra projektets start ermuligt at lave en detaljeret og bindende aftale omhele projektforløbet. For det andet opstår der proble-mer i samspillet, fordi den formelle rollefordelingforudsætter, at parterne har en tilpas omfattendeviden om og indsigt i hinandens faglige områder oghar en fælles forståelse af projektets overordnedevision. Og det har typisk ikke været tilfældet.

De faglige fællesmængder mellem de tre parterhar således generelt været for små:

20

Samspil med leverandører og konsulenter

Kapitel 4

Køber har en viden om egen organisation og debehov, IT-projektet skal opfylde. Derimod er bådeden tekniske og projektfaglige kompetence oftemeget begrænset. Det betyder fx, at brugerne ikøbers organisation har svært ved at håndtere enmere teknisk dialog med leverandørens udviklere.

Leverandøren forudsættes at besidde den nødvendi-ge tekniske og projektfaglige kompetence. Til gen-gæld ved leverandøren typisk kun lidt om de admi-nistrative processer i den offentlige sektor ialmindelighed og om købers organisation i særdeles-hed.

Konsulenterne har typisk den projektfaglige kompe-tence, men ofte ikke tilstrækkelig dyb teknisk kom-petence til reelt at kontrollere kvaliteten af leveran-dørens arbejde. Samtidig bruges de sammekonsulenter sjældent som gennemgående rådgivere,der kan påtage sig et samlet ansvar for at følge ogkoordinere hele processen. Det kan være en af forkla-ringerne på, at konsulenterne i nogle tilfælde ikkehar haft en tilstrækkelig bred viden. I en række til-fælde har køberen heller ikke været klar nok over,hvad de pågældende konsulenters kompetenceregentlig var.

Denne kløft mellem parternes kompetencer harværet stærkt medvirkende til en række af de typiskesamspilsproblemer, der er konstateret i de undersøg-te projekter. Det gælder blandt andet på følgendeområder:

• Ingen af parterne har haft et gennemgående ogsamlet overblik over projektets udvikling – bådeteknologisk og organisatorisk.

• Ingen har både kompetence til og føler ansvar for atadvare mod eventuelle fejludviklinger i projektforlø-bet. Konsulenter og leverandører har i flere tilfældeforsømt at advare mod valget af åbenlyst risikablestrategier.

• De fleste statslige købere er ”umodne købere”. Demøder leverandørerne med mistro. Det er et succes-kriterium for dem at få prisen så lav som mulig, ogleverandøren må gerne tabe penge på opgaven.Køber overser imidlertid princippet om, at den bed-ste handel er den, hvor begge parter er tilfredse.

• Kontrakterne har været udformet alt for detaljeretog ufleksibelt. Se også afsnit 4.3.

• Der bruges for lang tid – med eller uden konsulenter– på at udarbejde kravspecifikationen, uden at pro-jektets endelige deadline rykkes tilsvarende. Detsætter ofte leverandøren under et massivt tidspreslige fra starten.

• Der opstår mange og lange konflikter om tolkning-en af kravspecifikationer og ændringsanmodninger.Hvordan skal kontrakten fortolkes? Hvem skal tagestilling til ændringer? Hvordan måler man behov?Hvornår kan køber påberåbe sig misligholdelse afkontrakten osv.

• Køber har skubbet konsulenterne ind mellem sigselv og leverandøren og dermed reelt overdragetcentrale ledelsesopgaver i organisationen til en eks-tern part, der ikke er underlagt hverken politisk ellerøkonomisk ansvar. Se også afsnit 4.5.

4.3 Kontrakterne Den måde udbudsmateriale og kontrakter udformesog anvendes på udgør et selvstændig problem i sam-spillet mellem køber og leverandør.

I de fleste tilfælde er kravene til IT-løsningen sådetaljeret beskrevet, at de har været en spændetrøje iudviklingsfasen. Eksempelvis fyldte kravspecifikatio-nen til Told og Skats Erhvervssystem 9 ringbind.Arbejdsmarkedsstyrelsens kravspecifikation tilAmanda fyldte ”kun” to. Men ingen i de to projekterhavde et reelt overblik over konsekvenserne af demange krav eller var i stand til at vurdere, om detskitserede system i sidste ende ville understøtteorganisationernes målsætninger. Det var en af årsa-gerne til det store behov for ændringer i projekterneundervejs.

Som beskrevet i kapitel 2 har K18 og K33 en stor delaf ansvaret for, at kontrakterne svulmer op. Men detlangt fra hele forklaringen. Ønsket om detaljeredekontrakter bunder ikke mindst i, at de offentligemyndigheder opfatter IT-projekter som afgrænsede,tekniske anlægsopgaver. Det følger af denne opfat-telse, at man gennem en detaljeret kravspecifikationkan designe sig frem til et nøglefærdigt IT-system.

De detaljerede kontrakter har også fået uheldigekonsekvenser for styringen af projekterne. Den bli-ver alt for meget præget af juridisk kontraktstyringog alt for lidt af den fleksible projektstyring, der ernødvendig for at udvikle et kompliceret IT-system.Konkret sker der ofte det, at man laver projektplanenpå baggrund af kontraktens krav. I stedet burde manudforme en projektplan og lade den være funda-mentet for kontraktens udformning.

Udbudsreglerne bidrager til at forværre proble-met, fordi de opererer med meget korte frister forleverandørerne, typisk 37 dage. Det er en minimums-frist, men fungerer i praksis som et maksimum.Køber er nemlig ofte under tidspres, fordi der brugeslang tid på at udarbejde kravspecifikationen. Derforbliver leverandørerne afkrævet et hurtigt tilbud, somde så har svært ved at nå at arbejde ordentligt igen-nem. Erfaringerne fra de undersøgte projekter viserklart, at offentlige købere helt fra starten bør tagedet udgangspunkt, at ikke alle krav til systemet kanfastlægges på forhånd. Der skal gøres plads til fleksi-bilitet og ændringer undervejs i projektforløbet.Detaljerede kontrakter bør derfor erstattes af mere

21

åbne kontraktformer, der kan motivere køber ogleverandør til et løbende samarbejde om de mestoptimale løsninger. Naturligvis inden for de overord-nede rammer og målsætninger, der er opstillet.

Kontrakterne bør i stedet rumme mere udførligeprincipper for samarbejdsprocessen, herunder fxgøre det klart, hvem der tager stilling til ændringer,hvordan man måler behov, og hvilke proceskrav derskal stilles til projektstyringen. Det bør også, efterkontrakten er indgået, være muligt at udarbejde fæl-les kravspecifikationer – med mulighed for at stand-se samarbejdet. Det kan styrke den fælles forståelseaf problemstillingerne og af, hvad det færdige sys-tem skal kunne.

Desuden vil det styrke projekterne, hvis kontrak-terne ikke blot opererede med bøder, men også medpositive incitamenter.

I stedet bruges der i dag uforholdsmæssigt mangekræfter på at vurdere, om der foreligger en bodssitu-ation. Kræfter der i mange tilfælde var bedreanvendt på at få projekterne gennemført.Erfaringer fra udlandet peger også på mulighedenfor at benytte en slags projektkonkurrencer. Frem-gangsmåden kunne fx være, at forskellige leveran-dører bliver indbudt til at komme med et samlet budpå det nye IT-systems design. Køber kan så vælgemellem de indkomne forslag, inden projektet sendesi egentligt udbud. Det er arbejdsgruppens opfattelse,at designforslagene i en række tilfælde vil være etværdifuldt redskab til at kvalificere købers ønsker tildet nye system. En projektkonkurrence kan ogsåvære med til at pege på, hvor den offentlige køberskal modne sin organisation, inden det egentligesystemudviklingsarbejde går i gang. Se også anbefa-lingerne i afsnit 4.6.

4.4 LeverandørerneDet ligger uden for arbejdsgruppens opgave at vur-dere leverandørernes IT-faglige kompetence eller atidentificere en eventuel misligholdelse af kontrak-terne i juridisk forstand. Men udsagn fra de under-søgte IT-projekters nøgleaktører peger på, at leveran-dørerne på tre andre områder bærer et medansvarfor projekternes problemer.

For det første har leverandøren i flere tilfældeenten ikke kunnet levere den aftalte tekniske løs-ning, eller har præsteret så utilstrækkelig projektle-delse, at det har medvirket stærkt til, at projektet erkørt af sporet.

For det andet har leverandørsiden ofte ikke udvik-let de ”bløde kompetencer”. Leverandører har i flereprojekter manglet viljen til at forstå de organisato-riske aspekter af IT-projektet, til at samarbejde medandre leverandører, til at kommunikere med ikke-teknikere og til at reagere på problemer under opsej-ling.

For det tredje har leverandørerne i nogle tilfældeoptrådt problematisk. Det gælder især følgendepunkter:

• Tilbudsgivere har bevidst givet for lave bud på pro-jektet. Det er angivelig sket i forventning om atkunne hente den nødvendige fortjeneste hjem påkøbers ønsker om ændringer af leverancen under-vejs i udviklingsforløbet, eller når systemet først ertaget i drift. Leverandørerne har derfor også holdtsig meget nøje til kontrakten.

• I tilbudsfasen har leverandører tilknyttet deres dyg-tigste projektledere og sælgere. De er blevet erstat-tet af lavere rangerende medarbejdere, efterkontrakten er underskrevet.

• Leverandøren har i tilbudsgivningen ikke levet op tilsit moralske ansvar for at sige tydeligt fra over forprojekter, hvor det er åbenlyst, at de tekniske kravfra købers side er uhensigtsmæssige. Det kan blandtandet skyldes, at nogle offentlige købere desværrekonsekvent afviser de tilbud, hvor leverandøren hartaget forbehold over for fx tredje personers softwa-re eller urealistiske krav i udbudsmaterialet.

• Leverandører har efter kontraktindgåelse også svig-tet ved ikke tydeligt nok at påpege, at købers orga-nisering og bemanding af projekt er for dårlig, ellerat der mangler basale ting som risikovurderinger afprojektet. I et af de undersøgte projekter var fxsamtlige købers projektdeltagere (inklusiv projektle-delsen) kun tilknyttet udviklingsprojektet på halvtid. Leverandøren burde her have gjort opmærksompå, at dette både ville svække købers stilling og gøredet nødvendige samarbejde mellem partnernemeget vanskeligt.

• Leverandører har i mindst et tilfælde forsømt straksat varsle køber om, at projektets tekniske forudsæt-ninger – set i lyset af den generelle udvikling – varved at ændre sig fundamentalt. Det bør være leve-randørens opgave løbende at forsyne køber medajourført relevant viden, der gør det muligt at vur-dere og styre projektets tekniske risici. I Amanda-projektet var det fx kunden, der løbende skulle spør-ge leverandøren om styresystemets (OS2), ogudviklingsværktøjets (HPS), fortsatte udvikling ogvedligeholdelse. Det burde efter arbejdsgruppensopfattelse være leverandøren, der af egen driftinformerer og rådgiver kunden om afgørendeteknologiske udviklinger og ændringer.

• Leverandøren har i flere tilfælde forsømt at informe-re køberen om, at udviklingen af systemet var for-sinket. Fx vidste køberen i et projekt i lang tid i for-vejen, at leverandøren ikke ville kunne leveresystemet til den aftalte tid. Men af misforstået hen-syn til det videre samarbejde blev spørgsmålet ikkeafklaret, før leverandøren måtte krybe til korset –umiddelbart før deadline. Den slags svækker tillidentil leverandørens projektstyring, og er med til attvinge køber til at bruge kontraktstyring frem forprojektstyring.

22

4.5 KonsulenterneEksterne konsulenter har spillet en stor rolle i alle deundersøgte IT-projekter. Det skyldes blandt andet enmangel på medarbejdere med tekniske og projekt-faglige kompetencer i den offentlige sektor, og atbevillingsprocessen indirekte favoriserer brugen afkonsulenter frem for fastansatte. Se kapitel 2.3. Kon-sulenterne har blandt andet helt eller delvis stået forat udarbejde kravspecifikationen, gennemføreudbudsforretningen, foretage risikovurderingen ogkontraktstyringen, vurdere systemet når det overta-ges, og rådgive om idriftsættelsen. Konsulenternehar også leveret mindre specialiseret arbejdskraft tilkonkrete arbejdsopgaver på projekterne.

Det er arbejdsgruppens vurdering, at de offentligekøbere i for høj grad har ladet konsulenter varetagestrategiske og centrale funktioner, der principielt børforankres i organisationens egen ledelse. Ledelsenbetragter øjensynlig konsulenter som en god”ansvarsforsikring”, der kan give den nødvendigerygdækning i vanskelige situationer: ”Vi fulgte jokonsulentens anbefaling”. I flere projekter har kon-sulenter således varetaget ledelsesmæssige opgaveri købers organisation, fx som projektleder eller pro-jektkoordinator af det samlede udviklingsprojekt.Ledelsesansvaret er i enkelte af projekterne nærmestblevet udliciteret til konsulenterne, når køberensegen organisation undervejs i udviklingsforløbet harvist sig ude af stand til at løfte opgaven. Denne brugaf konsulenter kan være nødvendig i en nødsitua-tion, men den er uhensigtsmæssig af flere grunde:

• Konsulenten kan ikke overtage ledelsens opgaver ogansvar.

• Konsulenterne kender typisk ikke kundens organisa-tion og forretningsgange godt nok. For konsulentenvil det fx ofte være svært eller umuligt at sortere ibrugergruppers ændringsanmodninger. Det erledelsen af organisationen, der efterfølgende skalleve med systemet. Det skal konsulenten ikke.

• Den viden og indsigt, som konsulenterne oparbejderom projektet, forsvinder, når aftalen med konsulen-ten ophører. Når konsulenten derfor kun er tilknyt-tet projektet i bestemte faser, overføres der fx ikkeviden fra udbudsrunden til udviklingsdelen eller fraudviklingen til idriftsættelse. Dermed går værdifuldviden tabt, og den offentlige organisation opbyggerikke blivende kompetence på disse områder.

Det også forkert, når konsulenterne bruges sommellemled mellem køber og leverandør. I et par afprojekterne er konsulenterne således i vigtige faseraf projektet blevet skudt ind mellem parterne somforhandler og repræsentant for køber. Resultatet er,at organisationens ansvarlige ledelse reelt mere ellermindre har opgivet at følge og vurdere projektetsudvikling i tilstrækkeligt omfang.

På konsulentsiden er der endvidere ikke den nød-vendige sammenhæng i projektforløbet. Det typiske

er, at én konsulent fx udarbejder kravspecifikatio-nen, men ikke deltager i projektets senere faser, hvorandre konsulenter – ofte fra andre firmaer – så tagerover. Det gør det vanskeligt at fastholde konsulenter-ne på den rådgivning de har givet. Skift i konsulenterbetyder også ofte skift i projektmetoder og i dialog-og samarbejdsformerne. Det har i flere tilfælde førttil uplanlagte og ukoordinerede metodeskift under-vejs i projektet og betydet, at viden og beslutningerikke er blevet overført fra den ene fase i projektet tilden næste. Erfaringerne fra de undersøgte projekterviser, at der i skiftene mellem forskellige konsulenterofte opstår uhensigtsmæssige brud eller problemer.

Samtidig har kontrollen med konsulenternesarbejde generelt har været for lemfældig. Køber har ifor høj grad betragtet konsulenterne som ”venligehjælpere” i stedet for ”kommercielle service-leverandører”. Kontrakter med konsulenterne er såle-des typisk mindre konkrete og mindre forpligtendeend dem, der indgås med leverandørerne. Hvisansvarsforholdet og forventningerne til konsulen-tens rolle og opgaver ikke gøres helt klart fra starten,er det svært for køber efterfølgende at gøre et rådgiv-ningsansvar gældende.

Reelt er det lige så vigtigt at styre konsulentbi-standen som at styre andre dele af det samlede udvi-klingsprojekt. Mange problemer i IT-projekternehænger sammen med, at konsulentfirmaerne harfået for frie hænder. Køber har blandt andet forsømtat stille håndfaste krav til kvaliteten af konsulenter-nes arbejde, fx ved mere eksplicit at skrive rådgive-ransvaret ind i kontrakten.

Der er således væsentlige problemer i købers brugog styring af private konsulenter. Men der er også enrække kritikpunkter, der må rettes mod konsulenter-ne:

• De har ikke begrænset konsulentrollen fornuftigt,men har accepteret et betydeligt ledelsesansvar.

• De har udarbejdet IT-strategier og kravspecifikatio-ner til nogle af de IT-projekter, som siden hen harfået alvorlige problemer. Konsulenternes rådgivninghar i nogle tilfælde ikke været god nok. Det gælderblandt andet anbefalinger om at gennemføre pro-jektet som ét stort projekt uden delleverancer. Deter også tvivlsomt, i hvilket omfang konsulenternehar taget tilstrækkelig højde for projektets organi-satoriske aspekter og de potentielle risici, forbundetmed teknologiens udvikling.

• Konsulentvirksomhederne har i udstrakt grad ladetderes tunge folk sælge og tilrettelægge opgaven,men ladet mindre erfarne medarbejdere stå forudførelsen – uden at gøre køber klart, hvilke kompe-tencer og erfaringer disse havde på de forskelligeområder.

23

4.6 Anbefalinger På baggrund af de problemer i samspillet med leve-randører og konsulenter, der er beskrevet i dettekapitel, anbefaler arbejdsgruppen følgende:

1. Den opbygning og udveksling af erfaringer medoffentlige IT-projekter, der er anbefalet i kapitel 2,bør også omfatte erfaringer med samarbejdet medde enkelte leverandører og konsulenter, dereskompetencer og kvaliteten af deres arbejde. Det vilvære en vigtig forudsætning for, at det offentligekan koordinere sit indkøb af IT- og konsulenty-delser og stille krav til leverandørerne af disse.

2. Der bør anvendes mere fleksible kontraktmodeller,der afspejler realiteterne i moderne IT-projekter.Kontrakterne bør i højere grad supplere de nød-vendige bodsbestemmelser med en række positiveincitamenter.

3. Der bør opbygges erfaringer med at anvendesåkaldte projektkonkurrencer til at kvalificerekøbers design af IT-projektet. Modellen forudsæt-ter dels, at reglerne på området kan administreresi forbindelse med store IT-projekter, dels at statener villig til at give så store præmier, at det bliverattraktivt at deltage.

4. Brancheforeningerne for IT- og konsulentsiden børsammen med staten udarbejde og vedligeholde encode of conduct for samarbejdet om store IT-pro-jekter i den offentlige sektor.

5. Det bør undersøges, hvilke muligheder der er for atansætte og fastholde særligt kvalificerede projekt-ledere og IT-nøglemedarbejdere i staten.

24

Dette appendiks samler nogle vigtige praktiske rådtil de ledere, der i fremtiden skal stå i spidsen forstore statslige IT-projekter. Rådene bygger dels på defem undersøgte projekter, dels på arbejdsgruppensmedlemmers egne erfaringer med at udvikle, lede ogdeltage i store IT-projekter. De praktiske råd indehol-der derfor også udmøntning af anbefalingerne frarapportens kapitel 2, 3 og 4. De mere generelle ogpolitiske anbefalinger er dog ikke taget med i detteappendiks.

Rådene er delt op efter, hvilket af følgende temaer deretter sig imod:

• Modning af organisationen• Teknologi og rammer for statslige IT-projekter• Organisering af udviklingsprojekter• Samspil med leverandører og konsulenter

Listen over praktiske råd er ikke udtømmende –arbejdsgruppen henviser her til den gængse littera-tur fx om metoder for projektstyring. Men den kanvære en god checkliste for den ledelse, der har detoverordnede ansvar for et projekt. Listen kan hjælpemed at sætte fokus på de områder, som de hidtidigeerfaringer viser oftest bliver overset eller behandletfor uprofessionelt. Det er særlig relevant at forholdesig aktivt til rådene i begyndelsen af et udviklings-projekt, det vil sige før kontrakten skrives under.Mange af punkterne bør man dog løbende vende til-bage til igennem hele projektforløbet.

I litteraturlisten findes en række andre publikatio-ner, der rummer erfaringer med og anbefalinger tilIT-projekter i det offentlige.

Praktiske råd Check

Modning af organisationen:1. Der skal være taget stilling til følgende

spørgsmål, inden udviklingsprojektet sættesi gang:• Hvad er det reelle behov for projektet?• Kan projektet gennemføres?• Hvorledes vil vi være i stand til at gen-

nemføre projektet og den organisatoriskeomstilling, det indebærer?

Besvarelsen af de tre spørgsmål skal gøredet klart for ledelsen i organisationen, hvilkebehov systemet skal opfylde, og hvad detkræver af organisationen at gennemføreudviklingsprojektet.

2. Projektet skal forankres stærkt i den øversteledelse, og der skal her være en hovedan-svarlig for projektet i direktionen. Ledelsensansvar for IT-projektets succes gøres dermedtydelig og entydig.

3. Opgavestiller eller projektledelse skal tidligti forløbet udarbejde et samlet ”prospekt”,der redegør for de overordnede forholdomkring projektet, som projektets interes-senter har krav på at kende. Det vil somminimum sige:• En klar målsætning, der er målbar og inte-

greret i organisationens samlede strategi.• En cost/benefit analyse af totalprojektet,

så det fra starten bliver synligt, om der ertilstrækkelig dokumentation for projek-tets samlede fordele.

• En handlingsplan for, hvordan organisa-tionen kan modnes til at udvikle og mod-tage systemet. Planen skal både omfatte,hvordan organisationen opnår en fællesforståelse af projektets krav, og hvilkekompetencer der skal opbygges. Der skalsættes særlig fokus på organisationensevne til at etablere og drive en projektor-ganisation.

En risikovurdering af projektet og retnings-linier for den løbende risikostyring.

4. Erfaringer fra lignende offentlige IT-projek-ter skal indhentes. Specielt skal andres erfaringer med områder som modning aforganisationen, ledelse, brugerinddragelse,risikovurdering, udbudsregler, projektetssucces og erfaringer med valgte samar-bejdspartnere vurderes i forhold til organi-sationens egne projektplaner.

25

Praktiske råd til fremtidens IT-projekter

Appendiks 1

Praktiske råd Check

5. Ledelsen skal vente med at sætte projektet igang, indtil forudsætningerne er på plads.Det indebærer blandt andet, at organisatio-nen skal råde over de nødvendige ressourcerog kompetencer til at løfte opgaven.

6. Den nødvendige tilpasning af organisatio-nen og dens arbejdsgange skal ske paralleltmed, at systemet udvikles – ikke først nårsystemet skal tages i brug.

7. Det skal gøres klart for medarbejderne frastarten af projektet, om der fx:• er arbejdsprocesser der skal omlægges• skal ske ændringer i serviceniveau• skal indarbejdes nye produkter/ydelser• sker ændringer i personalets størrelse

eller sammensætning • er funktioner, der bliver centraliseret,

decentraliseret eller helt bortfalder.

8. Gevinsterne ved det nye system skal reali-seres hurtigst muligt, efter det er sat i drift.Jo længere tid der går, jo vanskeligere bliverdet at realisere de opstillede succeskriterierog vurdere, om systemet har styrket orga-nisationens forretningsmæssige mål.

Rammer og teknologi:9. Udgangspunktet for udformningen af syste-

met skal være, at det skal være så lille sommuligt – efter devisen ”think big – startsmall”.

10. Ledelsen og de bevilgende myndighederskal sikre sig, at det nye system bidrager til,at organisationen når sine mål. Det skaldesuden vurderes seriøst, om disse mål kannås ved at anvende standardsoftware ellergenbruge dele af andre offentlige myndig-heders systemer.

11. Det samlede IT-projekt skal splittes op i del-projekter med løbende leverancer. Som tom-melfingerregel skal hver leverance i projek-tet højst vare 6 måneder og højst omfatteomkring 30 udviklere og lige så mange bru-gere. Delprojekterne skal være selvstændi-ge, afgrænsede og brugbare dele af total-løsningen, som kan implementeres trinvis.

12. Udviklingsprojektet skal tilrettelæggesefter, hvilke forretningsprocesser og arbejds-gange systemet skal understøtte. Projekt-planer, kravspecifikation m.m. skal tagehøjde herfor.

Praktiske råd Check

13. Projektplanen skal lægges til grund for enfleksibel kontrakt, der kan motivere køberog leverandør til igennem hele forløbet, atsamarbejde om de mest optimale løsningerog sikre, at samarbejdet baseres på projekt-styring frem for juridisk kontraktstyring:• Der skal gøres plads til ændringer under-

vejs.• Der skal opstilles klare principper for sam-

arbejdsprocesserne, herunder fx hvem derhar ansvaret for ændringer, hvordan manmåler behov, hvilke krav der skal opstillestil projektstyring samt køberens og leve-randørens bemanding af projektet.

• Kontrakterne skal ikke blot operere medbøder, men også positive incitamenter ogbonusordninger.

14. Det er organisationens ledelse og de bevilli-gende myndigheders ansvar løbende atfølge op på risikovurderinger, og sikre sig, atrisici bliver elimineret eller begrænset.Omfatter IT-projektet flere forskellige insti-tutioner, skal der tages særskilt højde herfori risikovurderingen.

15. Projektledelsen skal tidligt udarbejde enkommunikationsplan, der sikrer en grundig,kontinuerlig og åben information om pro-jektet internt i projektorganisationen, i heleorganisationen og til medier og offentlig-hed.

16. Der skal laves pilotforsøg med det nye sy-stem, der også omfatter test af nye arbejds-gange og af, om medarbejderne har fåettilstrækkelig introduktion til og uddannelsei det nye system mv. Hvis det ikke er muligtat lave pilottest, skal dette indgå i risiko-vurderingen.

17. Der skal gennemføres systematiske evalue-ringer af projektet, og erfaringerne skalgøres tilgængelige for kommende projekter.Det gør det lettere for kommende projekterat holde deres projektplaner op imod gen-nemførte projekter.

Organisering af udviklingsprojektet:18. Projektledelsen skal udover projektlederen

og den hovedansvarlige fra ledelsen bestå afen styregruppe, der har ansvaret for de over-ordnede strategiske beslutninger.

19. Ansvars- og rollefordelingen skal beskrivesfor alle involverede.

26

Praktiske råd Check

20. Projektplaner, prospektet mv. skal evalueresog kvalitetssikres af erfarne projektfolk.Deres vurderinger skal indgå i den samlederisikovurdering af projektet.

21. Projektorganisationen skal systematiskbemandes med de stærkeste projektledereog medarbejdere. Der skal skabes stærkereincitamenter for at deltage i IT-projektet, fxved at udvikle attraktive karriereveje forprojektdeltagerne – især lederne.

22. Superbrugere skal inddrages i udviklingenog have et selvstændigt ansvar. Det skalvære de dygtigste og mest ansvarsfulde kernebrugere, der inddrages på fuld tid.

23. Brugergruppernes rolle og ansvar skal gøresklart fra starten. Det er afgørende, at pro-jektledelsen konsekvent vurderer og priori-terer brugernes krav i forhold til både dettekniske design og succeskriterierne for detsamlede projekt.

24. En løbende vurdering af cost/benefit skalsikre, at nye ønsker modsvares af, at mindrevigtige ønsker eller krav udelades.

25. Uddannelsen af brugerne skal ikke kunomfatte kommende superbrugere, oguddannelsen skal være bredere end dentekniske betjening af systemet. De nye for-retningsgange, nye ydelser, nye samarbejds-former og intentionerne bag forandringerneskal indgå i uddannelsen.

26. Slutbrugernes ledelse skal sikre, at forvent-ningerne til det nye system afstemmes medsystemets faktiske muligheder. Det vilblandt andet handle om komplikationer iforbindelse med konverteringen af data,samt om hvor hurtigt systemet kan opnåsine mål.

27. Det er vigtigt at håndtere videreudviklingenaf systemet lige så præcist som selve ud-viklingsprocessen. Systemets forretnings-mæssige mål skal fastholdes som styrings-redskab.

Praktiske råd Check

Samspil med leverandører og konsulenter:28. Den praktiske rollefordeling mellem køber

og leverandør skal dokumenteres. Derud-over skal der bl.a. planlægges fælles aktivi-teter for de to parter med henblik på atskabe fælles forståelse af projektets mål.Sådanne aktiviteter skal gentages efter hverstørre delleverance. Det kan sikre det tætteog tillidsfulde samarbejde mellem køber ogleverandør, som er en forudsætning for etgodt projektforløb.

29. Krisehåndtering af projektet skal fastholdefokus på projektets forretningsmål ogcost/benefit. Den skal sikre, at begge parterarbejder konstruktivt for at finde de bedsteløsninger, selv om det ikke ligger inden forkontraktens bogstav.

30. Leverandøren af systemet skal stå for driftenaf systemet i den første periode for at kunneudbedre de fejl og mangler, der typisk visersig i systemets første måneder.

31. Ansvarsforholdet og forventningerne tilkonsulentens rolle og opgaver skal gøreshelt klart fra starten og afspejles i kontrak-ten mellem parterne. Det er lige så vigtigt atstyre konsulentbistanden som andre dele afdet samlede udviklingsprojekt. Derfor skal:• Konsulenterne dokumentere deres kvali-

fikationer og erfaringer i forhold til denopgave, der skal løses.

• Kontrakten indeholde navne på de nøgle-konsulenter, der skal løse opgaven, ogeventuelt senere ændringer skal godken-des af køberen, så konsulentvirksomhe-den ikke stiller med mindre kvalificerederessourcer i gennemførelsen af projektet.

• Køber sikre en ordentlig overdragelsesfor-retning, hvis der skiftes mellem forskel-lige konsulenter undervejs i forløbet.

• Køberen selv varetage de strategiske ogcentrale ledelsesfunktioner, så ledelsesan-svaret er fast forankret i organisationen.

27

Undersøgelser af nedenstående fem projekter harsammen med arbejdsgruppens personlige erfaringerudgjort grundlaget for arbejdsgruppens arbejde.

De fem projekter beskrives herunder kort – medsærlig fokus på deres indhold, formål, opbygning,pris og tidsforløb. Beskrivelserne tager ikke stillingtil, i hvor høj grad de færdige systemer har opfyldtderes oprindelige formål.

Told•Skats ErhvervssystemErhvervssystemet blev udviklet af Told ∑ Skat somfølge af fusionen mellem Statsskattedirektoratet ogDirektoratet for Toldvæsenet. Hensigten var at laveet system, der kunne erstatte de ældre IT-systemer,som de to organisationer havde udviklet hver for sig.Erhvervssystemet var en mindre del af en større IT-modernisering, som også omfattede udskiftning afhardware.

Erhvervssystemet skulle registrere oplysningerom virksomhederne samt varetage regnskabsføring,opkrævning og kontrol af skatter og afgifter forerhvervsvirksomheder. Systemet skulle skabe enbedre, sammenhængende administration og enmere effektiv opgaveløsning.

Erhvervssystemet skulle oprindeligt bestå af femdelsystemer: Virksomhedsregistrering, angivelser,udsøgning, planlægning mv., regnskab samt restan-ce.

Projektet blev indledt i 1995, hvor kontrakten medden eksterne leverandør, Datacentralen (det senereCSC) blev underskrevet. Udgifterne til projektet blevoprindelig anslået til 150-200 millioner kr., der skullefinansieres over Told ∑ Skats eget driftsbudget.

Ifølge kontrakten skulle det planlagte projekt leve-res 30. juni 1997. I foråret 1997 beskar man projektetmarkant og ændrede de oprindelige tidsplaner. Manopgav at udvikle fire af de fem delsystemer, såledesat kun delsystemet ”Virksomhedsregistrering” blevudviklet færdig og implementeret. Det reduceredesystem blev leveret 14. juni 1999. Tilpasninger af sys-temet fortsatte frem til begyndelsen af 2000, hvordet blev sat i drift.

Erhvervssystemet kom i sin beskårne form, ifølgeRigsrevisionen, til at koste Told ∑ Skat 129,3 millio-ner kr. – altså lidt under det beløb, det oprindeligeprojekt med fem delsystemer var budgetteret til.

EASY Erhvervsskolernes Administrative System, EASY, blevudviklet på baggrund af et samarbejde mellemerhvervsskolerne og Undervisningsministeriet. Deter tænkt som et værktøj til at løse administrativeopgaver på landets erhvervsskoler. EASY er envidereudvikling af det tidligere system, ESAS, og erdet mindste IT-system af de fem cases, arbejdsgrup-pen har undersøgt.

Kontrakten med leverandøren WM-data varoprindelig på 25,5 millioner kr. Den blev underskre-vet i maj 1996 med planlagt idriftsættelse juni 1998.Ved designfasens afslutning meddelte leverandøren,at systemet var vokset med 42 pct. i forhold til krav-specifikationen. Årsagerne var angivelig dels arbej-det med den egentlige systembeskrivelse dels nylovgivning på området. En gruppe blev nedsat for atbeskære systemets funktionalitet, og man endte pået niveau, der lå 33 pct. over kravspecifikationen. Merevar det ikke muligt at fjerne uden at redesigne storedele. Kontrakten med leverandøren blev derfor for-højet til 32,7 millioner kr. Grundprojektet blev finansi-eret af en særskilt finanslovskonto, mens tilvækstenblev finansieret over ministeriets driftskonto.

I efteråret 1998 fik EASY-projektet problemer meddatakonverteringen, da systemet skulle tages i brug.Problemerne skabte en del presseomtale, bl.a. fordinogle elever risikerede ikke at kunne modtage eteksamensbevis, når de blev færdige med deresuddannelse.

Idriftsættelsen blev stillet i bero på landets han-delsskoler i tre måneder indtil foråret 1999, hvoreftersystemet blev implementeret som planlagt.

AmandaArbejdsmarkedets Nye Database, Amanda, bleviværksat af Arbejdsmarkedsstyrelsen som en følge afden arbejdsmarkedsreform, der trådte i kraft 1. janu-ar 1994. Amanda skulle afløse arbejds-formidlingernes daværende IT-system, AF-Match.

Amanda skulle føre til, at arbejdsmarkedets behovblev bedre matchet med de lediges kvalifikationer.IT-systemet skulle være tilpas fleksibelt til, at de 14AF-regioner kunne bevare deres forskellige måder attilrettelægge arbejdet på.

Udviklingen af det integrerede system blev sat igang juni 1996, og det samlede projekts økonomiskeramme var oprindelig 268 millioner kr.

Efter få måneders udvikling måtte leverandøren,CSC, opgive det oprindelige mål om at tilpasse syste-met til de forskellige regioners arbejdsgange.

Det var planen, at systemet skulle sættes i drift 1.januar 1998, men det skete først den 10. april 2000 –under stor og kritisk mediebevågenhed. I de følgen-de måneder gav systemet store problemer for opga-

28

De fem cases

Appendiks 2

veafviklingen i AF-regionerne, idet medarbejdernestidsforbrug ved afvikling af de enkelte arbejdsopga-ver steg voldsomt ved anvendelsen af Amanda. Kon-sekvensen var, at produktiviteten blev halveret imånederne efter ibrugtagningen af systemet, og deropstod stor frustration blandt medarbejdere og bru-gere.

Da Rigsrevisionen i 2000 undersøgte Amanda-pro-jektet, blev dets totalomkostninger opgjort til 412,2millioner kr.

Arbejdsministeren satte 31.maj 2000 et udvalgmed tre eksperter til at vurdere, hvad der på kort oglængere sigt skulle gøres for at optimere systemet.Ekspertudvalget konkluderede i oktober 2000, atAmanda skal tilføres yderligere 120 millioner kr. forat fungere fornuftigt. Heraf skal de 60 millioner kr.bruges på at købe ny hardware. Arbejdsmarkedssty-relsen har valgt at følge ekspertudvalgets anbefa-linger.

Navision StatProjektet Navision Stat blev sat i gang af Økonomi-styrelsen. Målet var at etablere et økonomisystem,der kunne afløse Statens Centrale Regnskabssystem,SCR, som statsinstitutionernes regnskabs- og økono-misystem. Navision Stat er en tilpasning af stan-dardsystemet Navision Financials.

IT-systemet installeres i den enkelte institution ien basisudgave, som de betaler for i forhold til dereslønsum. Efterfølgende kan institutionerne selvudnytte standardsystemets udvidelses- og integra-tionsmuligheder. Institutionerne står også selv fordriften af deres eget Navision Stat-system.

Det har været mere ressource- og tidskrævendeend først antaget at implementere systemet i deenkelte institutioner. Økonomistyrelsen måtte der-for i november 2000 udvide budgetrammen fra 70 til110 millioner kr. På Finansloven 2001 fik Økonomi-styrelsen hjemmel til anvende midler af sin opspa-ring til at afholde merudgifterne.

Navision Stat var pr. 1. januar 2001 i drift i 113 ud afi alt cirka 500 institutioner. Implementeringen for-ventes tilendebragt senest i 2003.

VUE Projektet Videregående Uddannelsesinstitutioner-nes Edb-systemer, VUE, blev udviklet af Undervis-ningsministeriet som et fælles administrationssy-stem til landets universiteter. VUE-projektetomfattede udviklingen af et institutionssystem samten modernisering af de eksisterende centrale syste-mer i Undervisningsministeriet (UNI-system). Insti-tutionssystemet bestod af et økonomistyringssy-stem (ØSS) og et studieadministrativt system(STADS).

Projektet blev sat i gang i 1991 bl.a. med henblik påat kunne følge de universitetsansattes timeforbrugpå hhv. forskning, undervisning og administration.

Dette formål blev dog ændret undervejs, så systemetprimært skulle varetage administrationen af de stu-derende ved landets universiteter.

Projektet skulle oprindelig have været sat i drift i1994, men fristen blev ved et aktstykke i 1993 ændrettil 1995. Økonomisystemet blev trinvis sat i drift fra 1.januar 1995, og STADS blev sat i drift i den førsteinstitution 1. april 1996. Grundversionen blev leveretpr. 1. november 1996, og den var i drift primo 1997.Der blev dog udviklet videre på systemet i de efter-følgende år.

VUE-projektet arbejdede til og med 1994 medsædvanlige finanslovsbevillinger, herunder med enekstra aktstykkebevilling i 1993 på cirka 30 millionerkr. De enkelte institutioners udgifter blev afholdtinden for deres egne rammer. Fra og med 1995, hvorøkonomisystemet blev sat i drift, fik VUE-centeret(som statsinstitution) egen bevilling på finansloventil drift og udvikling. Det blev medio 1995 nødven-digt at søge særlig aktstykkebevilling på cirka 18 mil-lioner kr. til at færdigudvikle STADS i 1995/96. I som-meren 1995 blev VUE-projektet reorganiseret, ogsiden har VUE-systemerne været finansieret overVUE-centerets bevilling og gennem brugerbetaling.Ved reorganiseringen gav Undervisningsministerietinstitutionerne mulighed for på visse betingelser atfravælge det studieadministrative system, STADS.

Ved udgangen af 1996 kan de rene udviklingsom-kostninger for begge systemer ifølge Undervisnings-ministeriet opgøres til cirka 129 mio. kr. Fra og med1996 var der i høj grad tale om, at brugerne betaltefor at videreudvikle og vedligeholde systemerne. Fraår 2000 har universiteterne selv dannet deres egenindkøbsforening, der driver og vedligeholder syste-merne.

Systemet administrerer i dag kun cirka 40 pct. afde studerende på de videregående uddannelser iDanmark. Københavns Universitet og Handelshøj-skolen i København har valgt at stå uden for og harudviklet deres egne systemer.

29

Litteratur

Cabinet OfficeSuccessful IT: Modernizing Government in Action.Cabinet Office, GB, 2000.www.iagchampions.gov.uk/itprojectsreview.

Committee of Public Accounts First Report – Improving the Delivery of GovernmentIT Projects. House of Commons, UK, 1999.www.publications.parliament.uk/pa/cm199900/cmselect/cmpubacc/65/6502.htm.

Davidsen, Per Steiner Risikohåndtering av IT-prosjekter. Hvordan skalstyringsgruppen og projektlederen holde kontrol?(Rapport 1998: 7) Statskonsult, Norge, 1998.www.statskonsult.no/publik/publikasjoner/1998-7/.

Jensen, Annelone, Nanné Solem Dahl, Allan BoRasmussen, Malthe Jacobsen, Jens Chr. HaugeOffentlige IT-projekter – på vej mod en skandalefrifremtid. Dansk Dataforening, april 2000.www.ddf.dk/fagraad/organisation_og_it/dogmer.htm

Jensen, Verner, Kurt Nørrisgaard og Jacob Lyngsø Rapport fra ekspertgruppen vedrørendeArbejdsformidlingens edb-system: Amanda.Arbejdsmarkedsstyrelsen, oktober 2000.

Jørgensen, Ejvind, Allan Bo Rasmussen, AnneloneJensen, Peter Sørensen, Jacob Primault5 holdninger til offentlige IT-projekter – på vej moden skandalefri fremtid.Dansk Dataforening, februar 2001www.ddf.dk/5holdninger.htm

Karlsen, Thorbjørn Erfaringer fra store statlige IT-prosjekter – Vurderinger og mulige tiltag. (Rapport 1998: 6),Statskonsult, Norge, 1998.www.statskonsult.no/publik/publikasjoner/1998-6.

PLS Rambøll ManagementIT i praksis 2000. En undersøgelse af anvendelsen afinformationsteknologi i danske virksomheder. PLSRambøll Management A/S, 2000.

Rigsrevisionen:Beretning til statsrevisorerne om gennemførelse afstatslige edb-projekter. (RB B202/00), Rigsrevisionen,Juni 2000.

RiksrevisionsverketIT-utveckling inom staten 1998 – en översikt över 231 större projekt (RRV 1999:16) Riksrevisionsverket, Sverige, 1999.www.rrv.se/PDF-files/PDF9916.pdf.

RiksrevisionsverketIT-utveckling inom staten 1999 (RRV 1999:38)Riksrevisionsverket, Sverige, 1999.www.rrv.se/PDF-files/PDF9938.pdf.

StatskonsultStore Statlige IT-prosjekter. Styring, Organisering ogAnsvarsfordeling. Statskonsult, Norge, 1997.

30

Teknologirådethar til opgave at:

fremme teknologidebatten

vurdere teknologiensmuligheder og konsekvenser

rådgive Folketingetog regeringen

store statslige it-projekter – hvordangør man det bedre?

rapport og anbefalinger fra en arbejdsgruppeunder teknologirådetErik Bonnerup(formand)Annelone JensenBirgitte GregersenErik AndreasenHans HenrikØstergaardInge MærkedalKarsten DybvadKim Viborg AndersenKim ØstrupMartin Toft HansenNina Esmark

sekretariats-betjening afarbejdsgruppenLars Frelle-PetersenPeter SmidtTerkel MøhlNiels Schiander

redaktørOla Jørgensen,Klartekst

designBysted HQ A/S

teknologirådetsrapporter 2001/3

isbn 87-90221-56-7issn 1395-7392

rapporten bestilles hos:TeknologirådetAntonigade 41106 København KTelefon 33 32 05 03Telefax 33 91 05 03tekno@tekno.dk

Rapporten kan ogsådownloades og be-stilles på Teknologi-rådets hjemmesidewww.tekno.dk

Antonigade 41106 København K

Telefon 33 32 05 03Telefax 33 91 05 09

tekno@tekno.dkwww.tekno.dk

Erfaringer fra statslige IT-projekter – hvordan gør man det bedre?

Teknologirådets rapporter XMarts 2001

ISBN 87-90221-56-7ISSN 1395-7392