FIU, Alm.del - 2012-13 - Bilag 113: Statsrevisor beretninig 9/2012 om politiets it-system POLSAG

Denne beretning til Folketinget skal behandles ifølge lov om revisionen af statens regnskaber, § 18:Statsrevisorerne fremsender med deres eventuelle bemærkninger Rigsrevisionens beretning til Folketinget og vedkommendeminister.Finansministeren og justitsministeren afgiver en redegørelse til beretningen.Rigsrevisor afgiver et notat med bemærkninger til ministrenes redegørelser.På baggrund af ministrenes redegørelser og rigsrevisors notat tager Statsrevisorerne endelig stilling til beretningen, hvilketforventes at ske i august 2013.Ministrenes redegørelser, rigsrevisors bemærkninger og Statsrevisorernes eventuelle bemærkninger samles i Statsreviso-rernes Endelig betænkning over statsregnskabet, som årligt afgives til Folketinget i april måned – i dette tilfælde Endeligbetænkning over statsregnskabet 2012, som afgives i april 2014.

Statsrevisorerne,den 20. marts 2013BERETNING OM POLITIETS IT-SYSTEM POLSAGPolitiets it-system POLSAG var en del af flerårsaftalen for politiet 2004-2006. Formå-let med POLSAG var at modernisere politiets håndtering af sager og dokumenter, såhåndteringen blev elektronisk og landsdækkende.Efter at have brugt ca. 10 år på at forberede, udvikle og anskaffe POLSAG blev det ifebruar 2012 besluttet at lukke POLSAG. Statsrevisorerne bemærker, at beslutnin-gerne om at anskaffe og afvikle POLSAG har været velbegrundede, men at en ræk-ke forhold omkring projektet har været kritisable.Statsrevisorerne påtaler skarpt Rigspolitiets uprofessionelle og utilfredsstillen-de forberedelse og styring af POLSAG.Statsrevisorerne påtaler således:At staten har betalt ca. 567 mio. kr. for et system, som aldrig bliver taget i brug –og at politiet derfor stadig har et udækket behov for et tidssvarende og landsdæk-kende system til håndtering af sager og dokumenter.At Rigspolitiets ledelse ikke har udvist det nødvendige engagement i POLSAG.Ledelsen har ikke haft tilstrækkelig forståelse af, at POLSAG ikke alene var et it-projekt, men et komplekst projekt, som ville få stor betydning for politiets organi-sation og opgaveløsning. Endvidere brugte Rigspolitiet i vidt omfang eksternekonsulenter til at løse programledelsesopgaver, der burde have været forankret iRigspolitiets egen organisation.At Rigspolitiets forberedelse og styring af POLSAG var mangelfuld og på flerepunkter ikke fulgte god praksis for at styre statslige it-projekter. Rigspolitiet sikre-de sig ikke, at leverandøren havde den nødvendige forståelse af politiets arbejds-processer. Det medførte omfattende og fordyrende specialudvikling af en løsning,der var baseret på et standardsystem.Peder LarsenHenrik ThorupHelge Adam MøllerKristian JensenMogens JensenKlaus Frandsen

Introduktion og konklusion ........................................................................................... 1Indledning .................................................................................................................... 6A.Baggrund .............................................................................................................. 6B.Formål, afgrænsning og metode ........................................................................... 8Justitsministeriets styring af bevillingerne til POLSAG .............................................. 11A.De samlede omkostninger til POLSAG ............................................................... 12B.Bevillingsanmodninger til POLSAG .................................................................... 13Rigspolitiets forberedelse af POLSAG ....................................................................... 19A.Rigspolitiets business case for POLSAG ............................................................ 19B.Rigspolitiets krav til POLSAG ............................................................................. 20C.Kontraktgrundlaget.............................................................................................. 24Rigspolitiets styring af POLSAG-projektet ................................................................. 27A.Projektorganisering ............................................................................................. 28B.Rigspolitiets test af POLSAG før pilotdriften på Bornholm.................................. 32C.Problemer og fejl under pilotdriften på Bornholm................................................ 35D.Rigspolitiets håndtering af risikoen for dårlige svartider ..................................... 40Grundlaget for at lukke POLSAG ............................................................................... 43A.Elementer i indstillingen om at lukke POLSAG ................................................... 43

1. Denne beretning handler om Rigspolitiets anskaffelse af it-systemet POLSAG, der efteret langt og dyrt udviklingsforløb endte med ikke at blive taget i brug.2. I februar 2012 godkendte Finansudvalget, at Rigspolitiet lukkede POLSAG og opsagdesamarbejdet med leverandøren. På det tidspunkt havde POLSAG-projektet været i gang iknap 10 år og havde kostet over ½ mia. kr. Justitsministeriets indstilling om at lukke POL-SAG var baseret på arbejdet i et udvalg under en ekstern formand med deltagelse af Finans-ministeriet, Justitsministeriet og Rigspolitiet.3. POLSAG blev anskaffet for at erstatte POLSAS, som er politiets nuværende system tilsags- og dokumenthåndtering. Baggrunden var, at Rigspolitiet på daværende tidspunkt vur-derede, at POLSAS ikke kunne anvendes på længere sigt. Grundlæggende adskilte POL-SAG sig fra POLSAS på 2 områder. For det første ville al sagshåndtering blive elektronisk,og for det andet ville POLSAG blive landsdækkende. POLSAG blev bygget op om standard-systemet Captia, men projektet omfattede også en meget betydelig udviklingsopgave.4. Rigspolitiet skrev efter nogle års forberedelse kontrakt med den valgte leverandør i 2007.I 2009 replanlagde Rigspolitiet og leverandøren POLSAG-projektet. Det omfattede bl.a. enny tidsplan og væsentlige ændringer i projektets økonomi og indhold.POLSAG blev i december 2010 sat i pilotdrift i Bornholms politikreds, der nåede at bruge sy-stemet i over 1 år, inden kredsen i marts 2012 gik tilbage til at bruge POLSAS. POLSAG komaldrig i drift i andre kredse.5. Justitsministeriet har løbende forelagt aktstykker om POLSAG for Finansudvalget i taktmed, at projektet blev ændret og bevillingen øget.6. Formålet med undersøgelsen er at vurdere Justitsministeriets og Rigspolitiets indsats forat gennemføre POLSAG-projektet. Det har Rigsrevisionen undersøgt ved at besvare følgen-de spørgsmål:Hvad var Justitsministeriets grundlag for at lukke POLSAG?Gav Rigspolitiets forberedelse af projektet et godt grundlag for at anskaffe POLSAG?Har Rigspolitiet styret POLSAG-projektet tilfredsstillende?Har Justitsministeriet styret bevillingerne til POLSAG tilfredsstillende?

UNDERSØGELSENS HOVEDKONKLUSIONPOLSAG blev i starten af 2012 lukket efter et langt og dyrt udviklingsforløb.Samlet løb projektet knap 10 år og kom til at koste ca. 567 mio. kr. Rigsrevisio-nen vurderer, at det var hensigtsmæssigt, at grundlaget for beslutningen om atlukke POLSAG blev udarbejdet af et udvalg, hvor eksterne repræsentanter del-tog i at undersøge POLSAG og projektets fremtid.Det er Rigsrevisionens vurdering, at Rigspolitiet ikke forberedte og styrede POL-SAG-projektet tilfredsstillende og på en række punkter ikke fulgte god praksisfor at styre statslige it-projekter.Flere af udfordringerne for POLSAG-projektet blev grundlagt allerede i den for-beredende fase. Rigspolitiet udnyttede ikke mulighederne for at gentænke ogeffektivisere arbejdsgange og processer, men valgte, at POLSAG skulle lignedet eksisterende it-system så meget som muligt. Rigspolitiet sørgede ikke fori tilstrækkelig grad at afdække de arbejdsprocesser, som POLSAG skulle un-derstøtte, og som kunne have hjulpet leverandøren i designet af POLSAG. Der-for skete der et skred i designfasen, der betød, at det valgte standardsystem ik-ke blev udnyttet godt nok, og at specialudviklingen blev øget. Det øgede pro-jektets kompleksitet og risiko.Rigsrevisionen vurderer, at Rigspolitiets styring ikke var tilstrækkelig i et såstort og komplekst it-projekt. Rigspolitiet sørgede frem til 2010 ikke for en til-strækkelig ledelsesmæssig forankring af udviklingen af POLSAG og dokumen-terede generelt ikke centrale milepæle.Da POLSAG skulle sættes i pilotdrift i Bornholms politikreds, undervurderedeRigspolitiet opgaven og sørgede ikke for tilstrækkelig støtte til brugerne. Be-tjentene på Bornholm arbejdede i en lang periode med et system, som ud fraen brugervinkel ikke var tilfredsstillende.Rigsrevisionen vurderer, at Justitsministeriet ikke styrede bevillingerne til POL-SAG tilfredsstillende. Ministeriet belyste ikke de samlede omkostninger ved be-villingsanmodningen i 2007, idet ministeriet udelod omkostninger, der var envæsentlig forudsætning for projektet, og som Justitsministeriet efter Rigsrevi-sionens vurdering burde have taget med i aktstykket. Det bidrog til, at de sam-lede omkostninger til POLSAG i aktstykket var undervurderet. Justitsministeri-et orienterede desuden først Finansudvalget om en væsentlig ændring af pro-jektet � år efter, at Rigspolitiet og leverandøren havde replanlagt og udvidetprojektet markant. I mellemtiden fortsatte projektet, og Rigspolitiet betalte i ettilfælde i alt 12 mio. kr. til leverandøren for opgaver, der ikke var bevillingsmæs-sig hjemmel til. Det finder Rigsrevisionen ikke tilfredsstillende.Rigsrevisionens beretning omhandler Justitsministeriet og Rigspolitiet. Udfal-det af POLSAG-projektet var også et resultat af leverandørens indsats.

Hovedkonklusionen er baseret på følgende delkonklusioner:Hvad var Justitsministeriets grundlag for at lukke POLSAG?Det er Rigsrevisionens vurdering, at Justitsministeriet inddrog både økonomiske, tek-niske og leverandørmæssige risici, der var relevante for at vurdere projektets fremtid,i grundlaget for at lukke POLSAG. Det var hensigtsmæssigt, at Justitsministerietsgrundlag blev udarbejdet med deltagelse af eksterne repræsentanter i et setup, derligner det, der i dag er bedste praksis for at vurdere it-projekter i staten.De tekniske undersøgelser, der indgik i grundlaget for at lukke POLSAG, rejste alvor-lig tvivl om svartiderne, men konsekvenserne af undersøgelsernes resultater var usi-kre. Udvalget, der anbefalede at lukke POLSAG, var opmærksom på usikkerhedenog lagde vægt på, at svartiderne endnu ikke var tilfredsstillende dokumenteret.Gav Rigspolitiets forberedelse af projektet et godt grundlag for at anskaffe POLSAG?Det er Rigsrevisionens vurdering, at Rigspolitiets forberedelse af POLSAG-projektetpå en række punkter var mangelfuld. Rigspolitiet udarbejdede tidligt en business ca-se. Den indeholdt usikkerheder i forhold til økonomien, og Rigspolitiet brugte eller op-daterede den ikke efterfølgende, fx ved centrale milepæle som kontraktindgåelse, be-villing og udvidelse af projektet.Rigsrevisionen finder, at Rigspolitiet ikke i tilstrækkelig grad sikrede, at leverandørenfik den nødvendige forståelse af forretningsområdet, herunder de arbejdsprocesser,som POLSAG skulle understøtte. Det betød bl.a., at der skete et skred i omfanget afudvikling i designfasen, fordi Rigspolitiet og leverandøren ofte fortolkede kravene tilPOLSAG sådan, at POLSAG skulle være præcis det samme som POLSAS.Systemet blev tilpasset politiet og ikke omvendt, og POLSAG endte med at blive enskræddersyet løsning baseret på et standardsystem.Rigsrevisionen vurderer, at kontraktgrundlaget indeholdt en række uhensigtsmæssig-heder, der vanskeliggjorde Rigspolitiets styring af projektet. Fx var der ingen koblingmellem betalinger og leverancer i hovedkontrakten. Rigspolitiet fik dog på enkeltepunkter afhjulpet nogle af disse uhensigtsmæssigheder mod slutningen af projektet.Har Rigspolitiet styret POLSAG-projektet tilfredsstillende?Det er Rigsrevisionens vurdering, at Rigspolitiets styring af POLSAG ikke var tilstræk-kelig i et så stort og komplekst it-udviklingsprojekt. Frem til 2010 forankrede Rigspo-litiet ikke POLSAG i den øverste ledelse på en måde, der tog højde for, at projektetville få betydelige konsekvenser for hele politiets organisation og derfor krævede enstærk ledelsesmæssig forankring.Rigspolitiet undlod i for stort et omfang at udarbejde skriftlige beslutningsgrundlagved centrale beslutninger og milepæle, fx forud for leverandørvalget og pilotdriftenpå Bornholm.Den måde, Rigspolitiet styrede projektøkonomien på, gav tidstro og deltaljerede øko-nomioplysninger. Interne resurser indgik dog ikke i styringen af projektøkonomien, selvom de havde et betydeligt omfang.

Rigspolitiet brugte i vidt omfang eksterne konsulenter – ud over leverandørerne – tilat kompensere for de kompetencer, Rigspolitiet selv manglede til fx it og projektledel-se. Omfanget oversteg langt det forventede niveau og betød, at også centrale roller,der burde have været forankret i Rigspolitiets egen organisation, blev varetaget af eks-terne konsulenter.Rigspolitiets brug af eksterne konsulenter viser efter Rigsrevisionens opfattelse, at det– som allerede anbefalet i Bonnerup-rapporten i 2001 – bør være et centralt opmærk-somhedspunkt for ministerierne, hvordan de anvender og styrer eksterne konsulen-ter. Særligt til projektledelse i længerevarende udviklingsprojekter, hvor behovet forat sikre ejerskab og forankre viden og kompetencer i organisationen er stort.Rigsrevisionen vurderer, at Rigspolitiet ikke forberedte pilotdriften på Bornholm godtnok. Brugernes uddannelse var mangelfuld, og brugerne fik ikke nok støtte i at forstå,hvordan det nye system skulle bruges. Kontrakten betød samtidig, at Rigspolitiet ik-ke i tilstrækkeligt omfang kunne sikre, at leverandøren rettede de forretningskritiskefejl, der prægede systemet. Inden pilotdriften gennemførte Rigspolitiet ikke en anven-delsestest, der tester et system i de rigtige omgivelser og derfor ville have været eg-net til at finde flere af de fejl, som brugerne oplevede på Bornholm. Det var dog en for-del, at Rigspolitiet brugte en pilotdrift til at få afklaret, om POLSAG var klar til at blivebrugt i de andre politikredse.I en situation, hvor brugerne over lang tid oplevede fejl og problemer og samtidig skul-le have systemet til at fungere i den daglige sagsbehandling, blev pilotdriften på Born-holm en dårlig oplevelse.Gennem hele projektforløbet var dårlige svartider en central risiko, som Rigspolitiet ogleverandøren var opmærksomme på, men ikke fik adresseret tidligt nok.Rigsrevisionen anbefaler, at kunde og leverandør – særligt ved mere komplekse it-løsninger – sikrer tidlige test af svartider, fx ved at måle svartider på det, man har ud-viklet indtil videre, og derudfra vurderer, hvordan svartiden vil være i drift. Tidlige må-linger vil være dyrere og kan ikke give fuldstændig sikkerhed for, at svartiderne bliverde samme som ved en driftsprøve. Til gengæld kan kunde og leverandør gennem ud-viklingen gradvist reducere risikoen for dårlige svartider.Har Justitsministeriet styret bevillingerne til POLSAG tilfredsstillende?Det er Rigsrevisionens vurdering, at Justitsministeriet ikke har styret bevillingerne tilPOLSAG tilfredsstillende.Projektet blev løbende udvidet og fordyret og havde, da det blev lukket, samlet ko-stet ca. 567 mio. kr., inkl. ca. 145 mio. kr. til interne lønomkostninger. Fra 2007 til2010 blev bevillingen til POLSAG udvidet med 72 % fra 236 mio. kr. til 405,5 mio. kr.(2010-priser).Rigsrevisionen vurderer, at Justitsministeriets aktstykke i 2007 ikke medtog alle væ-sentlige omkostninger. Ministeriet belyste ikke de samlede projektomkostninger ogudelod omkostninger, der var en væsentlig forudsætning for at gennemføre POLSAG-projektet.Det er Rigsrevisionens opfattelse, at Justitsministeriet tidligere burde have orienteretFinansudvalget om, at projektet ved en replanlægning i 2009 blev væsentligt ændret.

7. Denne beretning handler om Rigspolitiets anskaffelse af it-systemet POLSAG, som ef-ter et langt og dyrt udviklingsforløb endte med ikke at blive taget i brug. Rigsrevisionen harigangsat undersøgelsen på eget initiativ.8. I februar 2012 godkendte Finansudvalget, at Rigspolitiet lukkede POLSAG-projektet ogopsagde samarbejdet med leverandøren. På det tidspunkt havde POLSAG været i gang iknap 10 år, og Rigspolitiet havde i alt brugt ca. 567 mio. kr. på POLSAG, heraf ca. 145 mio.kr. til interne lønomkostninger.9. Rigspolitiet og leverandøren skrev kontrakt om POLSAG i 2007, efter at Rigspolitiet i nog-le år havde forberedt anskaffelsen. POLSAG blev anskaffet for at erstatte POLSAS, som erpolitiets nuværende system til sags- og dokumenthåndtering. Baggrunden var, at en konsu-lentanalyse i 2002 konkluderede, at POLSAS ikke kunne anvendes på længere sigt på grundaf systemets teknologiske beskaffenhed. Forskellen på de 2 systemer fremgår af boks 1.10. POLSAG var bygget op om standardsystemet Captia, der blev anskaffet over en ramme-aftale for køb af systemer til elektronisk sags- og dokumenthåndtering. Projektet indebar og-så en meget betydelig udviklingsopgave.11. POLSAG blev sat i pilotdrift i Bornholms politikreds i december 2010, og politiet på Born-holm nåede at bruge systemet i over 1 år, inden kredsen i marts 2012 gik tilbage til at brugePOLSAS. POLSAG kom aldrig i drift i andre kredse.

BOKS 1. FORSKEL PÅ POLSAS OG POLSAGPOLSASer et sags- og dokumentstyringssystem, der er udviklet til politiet. Det blev taget i brug afden første politikreds i oktober 1997. POLSAS blev leveret og vedligeholdt af samme leverandør, somskulle levere POLSAG.Sagsbehandlingen i POLSAS er papirbaseret, og systemet kan ikke ”tale” på tværs af politikredse, fxkan man ikke søge oplysninger om personer mv. på tværs af kredse.POLSAGskulle være et fuldt digitaliseret og landsdækkende sags- og dokumentstyringssystem, somskulle understøtte politiets arbejdsprocesser ligesom POLSAS.POLSAG skulle understøtte arbejdet i de nye store politikredse og danne grundlag for at levere ledel-sesinformation til politi og anklagemyndighed. POLSAG skulle således bl.a. omfatte indskanning ogelektronisk arkivering af dokumenter, mulighed for digital dataudveksling, bl.a. med domstolene, ogmulighed for internetbaseret selvbetjening for borgerne.

12. I dag bruger alle politikredse POLSAS. Rigspolitiet har oplyst, at POLSAS vil kunne an-vendes i nogle år, men at det vil være med de begrænsninger, som POLSAS har, og med etvæsentligt udestående investeringsbehov.Flerårsaftalen for politiet 2004-2006 og FESD-rammeaftalen13. POLSAG-projektet blev iværksat i 2003 på baggrund af flerårsaftalen for politiet for 2004-2006. Flerårsaftalen fastlagde, at politiets it-systemer skulle forbedres og moderniseres i af-taleperioden, og afsatte en it-udviklingspulje til bl.a. at udskifte POLSAS med et nyt sagsbe-handlingssystem.Det fremgår af aftaleteksten, at de fællesoffentlige standarder (ESDH) i videst muligt omfangskulle benyttes i udviklingen af politiets sagsbehandlingssystem. Det indebar ifølge Justits-ministeriet og Rigspolitiet, at POLSAG skulle anskaffes inden for FESD-rammeaftalen, hvisdet var muligt. Se boks 2 for en beskrivelse af FESD-rammeaftalen.

De grønne bokse viser aftaler mellem Rigspolitiet og leverandøren. De blå bokse er tids-punkter, hvor Justitsministeriet har forelagt projektet for Finansudvalget. De røde bokse ereksterne undersøgelser af POLSAG, og den orange boks viser tidspunktet for opstarten iBornholms politikreds.Lukningen af POLSAG i 201215. Et længere udredningsforløb lå forud for beslutningen om at lukke POLSAG. Arbejdetblev iværksat efter, at Justitsministeriet i efteråret 2010 måtte bede om Finansudvalgets til-slutning til at videreføre POLSAG på et nyt grundlag, der indebar en udvidet bevilling, en nytidsplan, der tog højde for, at projektet var blevet forsinket og udvidet, og et ændret projekt-indhold.16. Udredningen blev ledet af et udvalg med en ekstern formand og repræsentanter fra Fi-nansministeriet, Justitsministeriet og Rigspolitiet og var bl.a. baseret på eksterne konsulent-undersøgelser og erfaringerne fra pilotdriften på Bornholm.Udvalget fandt på baggrund af et samlet risikobillede, der omfattede både tekniske, leveran-dørmæssige og økonomiske risici, at POLSAG burde lukkes. På det tidspunkt var systemetnæsten færdigudviklet. Udvalget konkluderede, at det ville være for dyrt og risikobetonet atbringe POLSAG i en stand, så det kunne føres sikkert i drift, og at der var en betydelig risikofor, at Rigspolitiet ville stå med et system, der ikke fungerede i praksis.17. Justitsministeriet gengav udvalgets anbefaling i en indstilling (Akt G) til Finansudvalgetom at lukke projektet.Efter Finansudvalget havde tiltrådt aktstykket, indledte Rigspolitiet drøftelser med leverandø-ren om samarbejdets ophør. Det skete efter rådgivning fra Kammeradvokaten, der rådgavRigspolitiet og Justitsministeriet om kontraktgrundlaget både op til og efter forelæggelsenfor Finansudvalget.Rigspolitiet og leverandøren indgik forlig i juni 2012. Justitsministeriet oplyste umiddelbartderefter Finansudvalget om værdien af forliget, der bestod af en kombination af en kontantbetaling fra leverandøren, eftergivelse af betalingskrav og en række fremtidige rabatter tilRigspolitiet. Justitsministeriet estimerede værdien af forliget til mellem 40 mio. kr. og 136 mio.kr. Især værdien af de fremtidige rabatter er usikker.

Afgrænsning19. Undersøgelsen omfatter perioden fra november 2003, hvor flerårsaftalen for politiet for2004-2006 afsatte de første midler til POLSAG, og frem til juni 2012, som er tidspunktet forforliget mellem Rigspolitiet og leverandøren.20. Vi behandler i beretningen nogle af de mange årsager til, at POLSAG blev lukket. Deter i den forbindelse vigtigt at understrege, at vores revisionsadgang omfatter Justitsministe-riet og Rigspolitiet. Beretningens resultater afspejler dette, selv om udfaldet af POLSAG-pro-jektet også var et resultat af leverandørens indsats.Rigspolitiet har som led i arbejdet med POLSAG brugt flere konsulenthuse til både enkelt-stående analysebidrag og løbende rådgivning. Rigsrevisionen reviderer ikke konsulentvirk-somhederne, men beretningen gennemgår nogle af konsulenternes bidrag og den rådgiv-ning, Rigspolitiet har fået i forløbet.21. Rigsrevisionen har i beretningen været opmærksom på ikke at vurdere Justitsministeri-et og Rigspolitiet efter de standarder for offentlige it-investeringer, som gælder i dag, og somer blevet udviklet, mens POLSAG-projektet kørte.Rigsrevisionen har bl.a. brugt anbefalingerne fra ”Erfaringer fra statslige IT-projekter – hvor-dan gør man det bedre?” fra 2001 (den såkaldte Bonnerup-rapport) til at vurdere, om Rigs-politiet levede op til god praksis på daværende tidspunkt.22. POLSAG-projektet indebar en omfattende specialudvikling, som ikke blev konkurren-ceudsat under FESD-rammeaftalen. Rigsrevisionen har ikke set på overholdelsen af de ud-budsretlige forhold ved Rigspolitiets brug af den rammeaftale, POLSAG blev købt under. Detgælder også aftaler indgået med leverandøren om drift og vedligehold af POLSAG.Metode23. Undersøgelsen bygger på en gennemgang af skriftligt materiale, som vi har fået udleve-ret af Justitsministeriet og Rigspolitiet. Vi har desuden indhentet materiale fra Finansministe-riet om behandlingen af Justitsministeriets aktstykker om POLSAG. Herudover har vi mod-taget materiale fra leverandørsiden i mere begrænset omfang.Vi har holdt møder med Justitsministeriet, Rigspolitiet, Finansministeriet, leverandøren (bå-de hoved- og underleverandør) og formanden for Udvalget for en undersøgelse af POLSAG.Rigsrevisionen har haft adgang til nogle af de personer, der har været involveret i POLSAG-projektet i Rigspolitiet. På grund af projektets langvarige forløb har det ikke været muligt attale med alle relevante medarbejdere, da mange ikke er ansat hos politiet længere.24. Rigsrevisionen har i undersøgelsen ikke haft adgang til et fuldstændigt materiale. Detskyldes 2 forhold. For det første har Rigspolitiets ledelsesbehandling været karakteriseretved manglende skriftlig dokumentation. Rigspolitiet har oplyst, at alle væsentlige, overord-nede spørgsmål fra programmets start blev forelagt og godkendt af rigspolitichefen, og atdisse drøftelser foregik på et mundtligt grundlag i overensstemmelse med de samarbejds-procedurer, der generelt var gældende i politiet på det tidspunkt. Derfor er ledelsesmæssi-ge overvejelser og beslutninger ikke dokumenteret. For det andet har Rigspolitiet kun i be-grænset omfang kunnet dokumentere møder i leverandørstyregruppen i en periode fra april2010 og frem til september 2011. Leverandørstyregruppen var det overordnede beslutnings-forum for samarbejdet mellem Rigspolitiet og leverandøren. Den manglende dokumentationhar begrænset Rigsrevisionens mulighed for at afdække denne væsentlige periode i projek-tet, herunder pilotdriften på Bornholm.

25. Rigsrevisionen har gennemgået projektøkonomien. Herunder har Rigsrevisionen foreta-get en særskilt gennemgang af Rigspolitiets konsulentudgifter. Kilderne hertil har omfattetoplysninger i regnskabssystemer, Rigspolitiets registreringer af udgifter og træk fra politietstidsregistreringssystem.26. Rigsrevisionen har modtaget bistand fra en it-ekspert fra IT-Universitetet i Københavnbl.a. til gennemgang af Rigspolitiets opgørelse af behov til POLSAG, kravspecifikation ogløsningsbeskrivelser, systemdesigndokumentation, fejl i systemet og udvalgte dele af beslut-ningsgrundlaget for at lukke POLSAG-projektet.27. Beretningen har i udkast været forelagt Justitsministeriet, hvis bemærkninger i videst mu-ligt omfang er indarbejdet. Vi har desuden forelagt relevante uddrag for hovedleverandørenog underleverandøren.28. Bilag 1 indeholder en kronologisk oversigt over POLSAG-projektet. Bilag 2 indeholderen oversigt over de aktstykker, Justitsministeriet har forelagt for Finansudvalget. Bilag 3 in-deholder en ordliste, der forklarer udvalgte ord og begreber.

Det er Rigsrevisionens vurdering, at Justitsministeriet ikke har styret bevillingerne tilPOLSAG tilfredsstillende.Projektet blev løbende udvidet og fordyret og havde, da det blev lukket, samlet ko-stet ca. 567 mio. kr., inkl. ca. 145 mio. kr. til interne lønomkostninger. Fra 2007 til2010 blev bevillingen til POLSAG udvidet med 72 % fra 236 mio. kr. til 405,5 mio. kr.(2010-priser).Rigsrevisionen vurderer, at Justitsministeriets aktstykke i 2007 ikke medtog alle væ-sentlige omkostninger. Ministeriet belyste ikke de samlede projektomkostninger ogudelod omkostninger, der var en væsentlig forudsætning for at gennemføre POLSAG-projektet.Det er Rigsrevisionens opfattelse, at Justitsministeriet tidligere burde have orienteretFinansudvalget om, at projektet ved en replanlægning i 2009 blev væsentligt ændret.Justitsministeriet orienterede først Finansudvalget om den væsentlige ændring af pro-jektet � år efter, at Rigspolitiet og leverandøren havde replanlagt og udvidet projek-tet markant. I mellemtiden fortsatte projektet, og Rigspolitiet betalte i et tilfælde i alt 12mio. kr. til leverandøren for opgaver, der ikke var bevillingsmæssig hjemmel til.Forløbet omkring replanlægningen af POLSAG viser ifølge Rigsrevisionen, at der kanvære god grund til at skærpe opmærksomheden omkring forelæggelser for Finans-udvalget. Rigsrevisionen anbefaler, at Finansministeriet overvejer, hvordan bevillings-myndighederne fremadrettet orienteres i tide, når et it-projekt udvikler sig anderledesend forventet.

Fordelingen af de samlede omkostninger til POLSAG31. Da projektet blev lukket, opgjorde Justitsministeriet, hvad POLSAG samlet havde kostet.Rigsrevisionen har med udgangspunkt i Rigspolitiets tal undersøgt de samlede omkostnin-ger til POLSAG, der er fordelt på udviklingsomkostninger, eksterne driftsomkostninger og in-terne lønomkostninger.Vi har opgjort udviklingsomkostningerne til POLSAG ud fra de anlægsværdier, Rigspolitiethar registreret. De eksterne driftsomkostninger er baseret på POLSAG-programmets inter-ne økonomioplysninger, mens de interne lønomkostninger er skønnet med udgangspunkt itræk fra politiets tidsregistreringssystem og forudsætninger anvendt i det eksterne review afPOLSAG i 2011.Omkostningerne til udviklingen af POLSAG gik især til anskaffelsen og udviklingen af POL-SAG-applikationen, dvs. selve it-programmet eller softwaren, sammenkobling til politiets ek-sisterende it-systemer og de tekniske miljøer, POLSAG skulle køre på.De eksterne driftsomkostninger omfattede fx omkostninger til konsulenter i projektforløbet,vedligeholdelse af politiets eksisterende systemer, så de kunne arbejde sammen med POL-SAG, og drift af det tekniske miljø, der blev brugt i pilotdriften.De interne lønomkostninger var de medarbejderresurser, politiet brugte i POLSAG-projek-tet. Det var fx projektmedarbejdere i Rigspolitiet og tid brugt til uddannelse og støtte af demedarbejdere, der skulle bruge POLSAG.

32. Rigsrevisionens undersøgelse af bevillingerne til POLSAG-projektet har vist følgende:POLSAG-projektet blev løbende udvidet og fordyret. Fra 2007 til 2010 blev bevillingen tilPOLSAG udvidet med 72 % fra 236 mio. kr. til 405,5 mio. kr. (2010-priser).Den største enkeltstående årsag til fordyrelsen fra 2007 til 2010 var etablering og drift aftekniske it-miljøer, der øgede bevillingen med 75 mio. kr. (2010-priser). Justitsministeri-et burde efter Rigsrevisionens opfattelse have medtaget et skøn over omkostningernetil miljøerne allerede i aktstykke nr. 119 af 24. april 2007, da miljøerne var en væsentligforudsætning for at gennemføre projektet. At Justitsministeriet undlod dette bidrog til atundervurdere de samlede omkostninger til POLSAG.Justitsministeriet oplyste først i 2012 Finansudvalget om de interne lønomkostninger tilPOLSAG som en del af de samlede projektomkostninger. Efter Rigsrevisionen opfattel-se burde Justitsministeriet allerede i 2007-aktstykket have skønnet de interne lønomkost-ninger, idet de også var en væsentlig forudsætning for at gennemføre projektet.

Aktstykkerne vedrørende POLSAG har løbende været forelagt med forsinkelse i forholdtil de tidspunkter, Justitsministeriet stillede Finansudvalget i udsigt, ligesom Justitsmini-steriet ikke gav en orientering til Finansudvalget i 2009, selv om der i aktstykket i 2005 varforudsat en årlig orientering.Det er Rigsrevisionens vurdering, at Justitsministeriet tidligere burde have orienteret Fi-nansudvalget om, at der var gennemført væsentlige ændringer af projektet. Rigspolitietunderskrev i oktober 2009 en ny kontrakt om replanlægning af POLSAG, men Justitsmi-nisteriet forelagde først en ny bevillingsanmodning i juni 2010. I den mellemliggende pe-riode fortsatte projektet.Rigspolitiet betalte i et tilfælde for aktiviteter gennemført under den nye kontrakt, før Fi-nansudvalget havde tilsluttet sig aktstykket, der godkendte replanlægningen. Rigspoliti-et betalte i alt 12 mio. kr. for opgaver, der ikke var hjemmel til.

Bevillinger om POLSAG forelagt for Finansudvalget33. Justitsministeriet har forelagt i alt 8 aktstykker og 1 orientering om POLSAG for Finans-udvalget. 3 aktstykker var bevillingsanmodninger til udvikling af POLSAG, som Finansudval-get tiltrådte. En oversigt over forelæggelser vedrørende POLSAG til Finansudvalget fremgåraf bilag 2.I begyndelsen af 2005 godkendte Finansudvalget, at Justitsministeriet igangsatte et sam-let moderniseringsprogram for politiets it-systemer. Programmet bestod af 14 projekter medPOLSAG som det største. Bevillingen til POLSAG udgjorde 173 mio. kr. ud af samlet 309mio. kr. (2010-priser). Aktstykket blev forelagt, inden Rigspolitiet havde modtaget et tilbudpå POLSAG, hvorfor Justitsministeriet angav, at beløbet var forbundet med usikkerhed.Omkring 2 ½ år senere anmodede Justitsministeriet i april 2007 om tilslutning til at anskaffeet nyt sagsbehandlingssystem. Rigspolitiet havde på det tidspunkt afsluttet forhandlingerneom hovedkontrakten med den valgte leverandør med forbehold for, at Finansudvalget god-kendte bevillingen. Dvs. at der forelå et aftalegrundlag med en anskaffelsespris og en hoved-tidsplan. Derfor var oplysningerne i aktstykket mere sikre end i 2005. Fra 2005 til 2007 stegprojektets bevilling med 36 % fra 173 mio. kr. til 236 mio. kr. (2010-priser).I slutningen af 2010 – efter yderligere 2 ½ år – anmodede Justitsministeriet om at viderefø-re POLSAG inden for en forhøjet økonomisk ramme. Fra 2007 til 2010 steg projektets be-villing med 72 % fra 236 mio. kr. til 405,5 mio. kr. (2010-priser).Tabel 1 viser, hvordan projektet løbende blev dyrere. Der er tale om samlede bevillinger,idet den eksisterende bevilling løbende blev forhøjet.

Tabel 1 viser stigningen i bevillingerne til POLSAG fra 2005 til 2007 og fra 2007 til 2010. Vifokuserer i det følgende på fordyrelsen fra 2007 til 2010. Stigningen fra 2005 til 2007 var ud-tryk for, at det økonomiske grundlag i 2005-aktstykket var baseret på et tidligt og dermedusikkert estimat.Årsager til fordyrelsen af POLSAG fra 2007 til 201034. Rigsrevisionen har gennemgået årsagerne til, at POLSAG blev fordyret. Justitsministe-riet redegjorde i aktstykket i 2010 for årsagerne til den udvidede projektøkonomi. Udvidelsenpå 72 % fra 2007 til 2010 kunne ifølge ministeriet henføres til tekniske miljøer, nye udvik-lingspakker, forsinkelser og designændringer og en ny reserve.Tekniske miljøer35. Den største enkeltstående årsag til fordyrelsen var etablering og drift af tekniske miljø-er, der øgede bevillingen med 75,2 mio. kr. (2010-priser) Udgifterne havde hele tiden skul-let afholdes, men var ikke indeholdt i aktstykket i 2007 (nr. 119 af 24. april 2007). Miljøernevar den hardware, som selve POLSAG-applikationen skulle køre på, fx under test og drift.Nye udviklingspakker36. Udviklingen af POLSAG-projektet var opdelt i såkaldte udviklingspakker. En del af fordy-relsen, i alt 62,3 mio. kr. (2010-priser), skyldtes 2 nye udviklingspakker, der tilføjede ny funk-tionalitet i forhold til de oprindelige krav.Justitsministeriet oplyste i aktstykke nr. 66 af 30. november 2010, at der var tale om nye ud-viklingspakker, der tog højde for bl.a. ny lovgivning, en ændret kredsstruktur efter politirefor-men, nye krav i form af rettelser af uhensigtsmæssigheder i det oprindelige design og øn-sker om ny funktionalitet, der var kommet til, efter kontrakten var underskrevet.Dermed blev selve indholdet af projektet udvidet i forhold til oprindeligt.Forsinkelser, designændringer og ny reserve37. Projektomkostningerne steg også på grund af et merforbrug på 27 mio. kr., hvoraf 17 mio.kr. gik til forsinkelser og ændringer i det eksisterende design, og 10 mio. kr. blev afsat til enny reserve (2010-priser). Den oprindelige reserve var opbrugt, bl.a. på grund af et højerekonsulentforbrug end forventet.Mens udviklingspakkerne også tilføjede ny funktionalitet, indebar forsinkelser og designæn-dringer, at den funktionalitet, der var beskrevet i den oprindelige bevilling i Akt 119 16/5 2007,samlet set blev dyrere.Oplysninger i aktstykkerne om de samlede projektomkostninger til POLSAG38. Rigsrevisionen har vurderet, om Justitsministeriet medtog alle væsentlige omkostnin-ger i bevillingsanmodningerne i 2007 og 2010.Omkostninger til tekniske it-miljøer39. Justitsministeriet undlod at oplyse om omkostninger til tekniske it-miljøer i aktstykke nr.119, der blev fremsendt i april 2007 og tiltrådt i maj 2007.Justitsministeriet har oplyst, at Rigspolitiet ved forberedelsen af aktstykket i 2007 forudsat-te, at omkostninger til driftsmiljøer skulle afholdes inden for politiets generelle driftsbevillin-ger og derfor ikke skulle indgå som en del af anskaffelsen i aktstykket.Rigsrevisionen finder, at Justitsministeriet burde have indarbejdet omkostningerne til de tek-niske miljøer i aktstykket i 2007 som en del af de samlede projektomkostninger. Det skyldes,at omkostningerne til tekniske miljøer var en forudsætning for at gennemføre projektet. AtJustitsministeriet ikke medtog et skøn over de tekniske miljøer i 2007-aktstykket bidrog til atundervurdere de samlede omkostninger til POLSAG.

40. Rigspolitiet har anført, at kontrakten på de tekniske miljøer først blev underskrevet i ok-tober 2007. Der forelå imidlertid et kontraktudkast med et skøn over omkostningerne til detekniske miljøer allerede i marts 2007 forud for, at Finansudvalget godkendte aktstykke nr.119 i maj 2007. Rigspolitiet har oplyst, at størrelsen af udgifter til drift og etablering af test-miljøer var kendt fra projektets start.Det er således Rigsrevisionens opfattelse, at det havde været muligt for Rigspolitiet at skøn-ne omkostningerne til drift og etablering af tekniske miljøer i aktstykke nr. 119 af 24. april2007. Rigspolitiet burde også have regnet de tekniske miljøer med i de interne budgetter forat opnå et komplet grundlag for den interne styring af projektøkonomien.Interne lønomkostninger41. Justitsministeriet angav ikke et skøn over de interne lønomkostninger i aktstykkerne omPOLSAG i 2007 og 2010. Endvidere tilrettelagde Rigspolitiet ikke den interne tidsregistre-ring med henblik på at kunne opgøre det faktiske tidsforbrug til POLSAG. Af samme grundkan de interne lønomkostninger i dag også kun opgøres som et skøn.Det er Rigsrevisionens opfattelse, at de interne resurser var en væsentlig forudsætning forat realisere projektet, hvorfor det havde været naturligt, om Justitsministeriet havde oplystdet forventede omfang af de interne omkostninger i aktstykkerne i 2007 og 2010. De inter-ne lønomkostninger omfattede bl.a. tid brugt på projektledelse, test og uddannelse og støt-te af brugerne.Budgetvejledning 2006 omfattede efter Justitsministeriets opfattelse ikke et krav om at med-tage interne lønomkostninger i it-udviklingsprojekter.Det er dog Rigsrevisionens opfattelse, at det under alle omstændigheder havde været hen-sigtsmæssigt, at Justitsministeriet havde oplyst om de interne lønomkostninger i aktstykker-ne. At Justitsministeriet ikke medtog et skøn over de interne lønomkostninger i 2007-akt-stykket og 2010-aktstykket bidrog til at undervurdere de samlede omkostninger til POLSAG.42. Justitsministeriet oplyste først Finansudvalget om de interne lønomkostninger til POL-SAG i Akt G i februar 2012. På baggrund af et skøn fra 2011 oplyste Justitsministeriet, atRigspolitiet havde haft interne lønomkostninger til POLSAG på i alt 124 mio. kr. Oplysningenblev gentaget i en orientering til Finansudvalget i juni 2012.Rigsrevisionen har ajourført 2011-skønnet over de interne lønomkostninger på baggrund afoplysninger fra Rigspolitiet, herunder træk fra politiets tidsregistreringssystem. Rigsrevisio-nen har med udgangspunkt i de samme forudsætninger, som blev anvendt i 2011, skønnet,at Rigspolitiets interne lønomkostninger til POLSAG beløb sig til ca. 145 mio. kr.Tidspunkterne for forelæggelse af bevillingsanmodninger43. I april 2005 oplyste Justitsministeriet, at anskaffelsen af et nyt sagsbehandlingssystemville blive forelagt for Finansudvalget inden udgangen af 2005. I en orientering til Finansud-valget i februar 2006 oplyste Justitsministeriet, at forelæggelsen ville ske medio 2006. Denkom med aktstykke nr. 119 i april 2007. Forsinkelsen skyldtes, at kontraktforhandlingernemed leverandøren trak ud.44. Oprindeligt forudsatte Justitsministeriet i det første aktstykke i 2005, at Finansudvalgetskulle orienteres årligt. Det skete ikke i 2009. Efter forelæggelsen af en status for projekteti maj 2008, hvoraf det fremgik, at arbejdet med at realisere POLSAG forløb planmæssigt oginden for den bevillingsmæssige ramme, forelagde ministeriet først projektet for Finansud-valget igen i juni 2010. På det tidspunkt var projektet forsinket og fordyret.

I efteråret 2008 stod det klart, at leverandøren var forsinket, og Rigspolitiet og leverandørenblev derfor i november 2008 enige om at replanlægge POLSAG-projektet.Replanlægningen omfattede både projektets tidsplan, økonomi og indhold.45. I juni 2009 blev replanlægningen forhandlet færdig mellem Rigspolitiet og leverandøren,og den 1. oktober 2009 blev en ny aftale underskrevet. Replanlægningen blev indgået somtillæg til det eksisterende kontraktgrundlag. Rigspolitiet underskrev kontrakten med forbeholdfor bevillingsmæssig hjemmel. Justitsministeriet har oplyst, at ministeriet forud for en orien-tering af forligskredsen i november 2009 blev orienteret af Rigspolitiet om replanlægningen.Replanlægningen omfattede bl.a. en ændring af hovedkontrakten og havde et betydeligt om-fang. Fx lagde aftalen 34.000 timer til kontraktens oprindelige 97.000 timer. Det svarer til enstigning på 35 %.Det var et generelt krav i budgetvejledningen, at væsentlige ændringer af it-projekter skulleforelægges Finansudvalget. Justitsministeriet forelagde imidlertid først ændringen som følgeaf replanlægningen for Finansudvalget i juni 2010. Ca. � år efter kontrakten var indgået.Justitsministeriet har oplyst, at ministeriet umiddelbart efter, at kontrakten var reforhandlet,burde have orienteret Finansudvalget om, at ministeriet var på vej med et bevilgende aktstyk-ke.Justitsministeriet har anført, at ministeriet i juni 2010 oversendte aktstykke nr. 157, men atministeriet senere valgte at trække aktstykket tilbage. Finansudvalget var således i juni 2010orienteret om projektets status. Dermed gik der samlet ca. � år, fra kontrakten om replanlæg-ningen var underskrevet, til Justitsministeriet forelagde ændringen for Finansudvalget førstegang. Justitsministeren angav, at årsagen til at trække aktstykket tilbage bl.a. var, at leveran-døren alligevel ikke kunne bestå en planlagt overtagelsesprøve. I stedet forelagde Justitsmi-nisteriet i november 2010 aktstykke nr. 66, som Finansudvalget tiltrådte i december 2010.46. Forløbet omkring replanlægningen er illustreret i figur 3.Figur 3. Begivenheder ved replanlægningen

Bevillingsoverholdelse – betaling uden hjemmel47. Efter at Rigspolitiet og leverandøren i efteråret 2008 aftalte at replanlægge projektet, meninden kontrakten blev underskrevet, gik leverandøren i gang med de nye opgaver. Fx opga-ver relateret til de nye udviklingspakker. Leverandøren fremsendte fakturaer for opgaverne,men Rigspolitiet betalte dem ikke i starten, bl.a. med henvisning til, at kontrakten var under-skrevet med forbehold for bevillingsmæssig godkendelse, og at en sådan endnu ikke var op-nået.Rigsrevisionens stikprøve af udvalgte fakturaer relateret til replanlægningen har vist, at Rigs-politiet i marts 2010 betalte en faktura på 18 mio. kr. for ydelser under den replanlagte kon-trakt. Det skete, før der var bevillingsmæssig hjemmel hertil. Den hjemmel opnåede Justits-ministeriet først med Finansudvalgets godkendelse af aktstykke nr. 66 af 30. november 2010.Betalingen omfattede aktiviteter gennemført i perioden juni 2009 - september 2009. Rigs-politiet har oplyst, at⅔af de i alt 18 mio. kr. vedrørte opgaver under den nye kontrakt. Detsvarer til, at Rigspolitiet betalte 12 mio. kr., før der var hjemmel til det.Justitsministeriet har oplyst, at Rigspolitiet efterfølgende modtog yderligere fakturaer fra le-verandøren, men at disse først blev betalt den 17. december 2010 umiddelbart efter, at Fi-nansudvalget godkendte aktstykke nr. 66 af 30. november 2010. Rigspolitiet har oplyst, atleverandøren i alt fremsendte 11 fakturaer til en samlet værdi af 46,7 mio. kr. under den re-planlagte kontrakt, og af de 11 blev kun den ene faktura på 18 mio. kr. betalt, før der varhjemmel til det.Justitsministeriet har anført, at der i ministeriet og Rigspolitiet var stort fokus på og dialogmellem myndighederne om at sikre, at fakturaer under den replanlagte kontrakt ikke blevbetalt, inden Justitsministeriet havde opnået hjemmel.

Det er Rigsrevisionens vurdering, at Rigspolitiets forberedelse af POLSAG-projektetpå en række punkter var mangelfuld. Rigspolitiet udarbejdede tidligt en business ca-se. Den indeholdt usikkerheder i forhold til økonomien, og Rigspolitiet brugte eller op-daterede den ikke efterfølgende, fx ved centrale milepæle som kontraktindgåelse, be-villing og udvidelse af projektet.Rigsrevisionen finder, at Rigspolitiet ikke i tilstrækkelig grad sikrede, at leverandørenfik den nødvendige forståelse af forretningsområdet, herunder de arbejdsprocesser,som POLSAG skulle understøtte. Det betød bl.a., at der skete et skred i omfanget afudvikling i designfasen, fordi Rigspolitiet og leverandøren ofte fortolkede kravene tilPOLSAG sådan, at POLSAG skulle være præcis det samme som POLSAS.Systemet blev tilpasset politiet og ikke omvendt, og POLSAG endte med at blive enskræddersyet løsning baseret på et standardsystem.Rigsrevisionen vurderer, at kontraktgrundlaget indeholdt en række uhensigtsmæssig-heder, der vanskeliggjorde Rigspolitiets styring af projektet. Fx var der ingen koblingmellem betalinger og leverancer i hovedkontrakten. Rigspolitiet fik dog på enkeltepunkter afhjulpet nogle af disse uhensigtsmæssigheder mod slutningen af projektet.

Rigspolitiets brug af business case50. Bonnerup-rapporten anbefalede i 2001 at gennemføre costbenefit-analyser af store it-projekter, og at de forretningsmæssige mål var klare. Først fra 2008 var der krav om at ud-arbejde en business case for statslige it-projekter.Rigspolitiet udarbejdede i april 2006, dvs. ca. 1 år inden hovedkontrakten blev underskrevetmed leverandøren, en business case for POLSAG. Business casen var ikke udarbejdet ef-ter det koncept, der er gældende i dag, men omfattede skøn over kvantificerede fordele ogsamlede omkostninger. Desuden blev nogle ikke-kvantificerbare fordele identificeret.51. Business casen henviste til en række projektmål, som Rigspolitiet havde opstillet i janu-ar 2006, herunder bl.a. mulighed for elektronisk sagsbehandling og mulighed for at få ad-gang til sager på tværs af kredse.52. Ifølge business casen var POLSAG en forudsætning for politiets effektiviserings- og mo-derniseringsplaner. Det fremgik dog samtidig, at det var fordelagtigt for Rigspolitiet at vurde-re projektets fordele og omkostninger, så disse kunne udgøre basis for det videre forløb.Rigspolitiet har fremhævet, at POLSAG blev igangsat som et nødvendigt infrastrukturpro-jekt mere end som et effektiviseringsprojekt. POLSAG skulle primært udskifte POLSAS.Rigspolitiet har oplyst, at Rigspolitiet ikke definerede fordelene ved POLSAG yderligere el-ler prissatte disse, fordi det var åbenlyst, at projektet ville indebære fordele, fx blot i kraft afmuligheden for at søge på tværs af kredsene.53. Business casen byggede bl.a. på et mundtligt prisestimat fra leverandøren, der stamme-de fra den eksterne leverandøranalyse, der lå til grund for Rigspolitiets indledende leveran-dørvalg i 2005. Konsulenten, der foretog leverandøranalysen, bad leverandøren belyse øko-nomien i Captia-løsningen yderligere, men fik ikke flere oplysninger.54. Det fremgår af business casen, at den skulle opdateres, når kontrakten forelå, og enrække usikkerheder ville være reducerede. Rigsrevisionens sagsgennemgang har vist, atdet ikke skete, ligesom business casen ikke blev brugt efterfølgende i den løbende styringaf projektet. Rigspolitiet udarbejdede heller ikke efterfølgende nye business cases, når pro-jektet blev udvidet.Finansministeriet efterspurgte en business case forud for den forøgede bevilling i 2010, mendet afviste Justitsministeriet med henvisning til, at der ikke var udarbejdet en business caseved bevillingen af projektet i 2007, og at det ikke oprindeligt havde været et krav.

Rigspolitiet opstillede kravene til POLSAG på 2 måder. Et overordnet 1:1-krav om, atPOLSAG skulle have samme funktionalitet som det eksisterende POLSAS. Dertil komca. 1.000 specifikke krav. I designfasen blev specialudviklingen betydeligt større end for-udsat i kontrakten. Det skyldtes bl.a., at Rigspolitiet og leverandøren ofte fortolkede 1:1-kravet sådan, at POLSAG skulle understøtte politiets arbejdsprocesser på præcis sam-me måde som POLSAS – fx med skærmbilleder, der lignede dem i POLSAS – i stedetfor at udnytte standardsystemets muligheder.I en fælles analyse med leverandøren konkluderede Rigspolitiet, at det ville have forud-sat større forretningsanalyser, hvis POLSAG skulle have udnyttet Captia bedre. Det erRigsrevisionens vurdering, at Rigspolitiet burde have sikret et bedre grundlag for at be-grænse omfanget af specialudvikling.I den eksterne konsulentundersøgelse fra 2011 blev det vurderet, at 80 % af den sam-lede leverance var skræddersyet, mens 20 % var standard. Ifølge konsulentundersøgel-sen var det modsatte tilfældet for de fleste andre kunder.

Første indikationer på omfanget af udvikling56. Rigspolitiet fik i slutningen af 2004 en konsulent til at vurdere, om POLSAG kunne base-res på 2 ud af 3 FESD-leverandørers løsninger. Den 3. leverandør inden for rammeaftalenønskede ikke at deltage.Analysen lå færdig i september 2005. Konsulenten vurderede overordnet, at det var muligtfor Rigspolitiet at anskaffe en FESD-baseret løsning, ligesom det var muligt at gennemførede fornødne tilpasninger på en måde, så det ifølge konsulenten var i overensstemmelse medFESD-rammeaftalen og udbudsreglerne. Den valgte leverandør gjorde under analysen op-mærksom på, at en løsning inden for FESD-rammen baseret på Captia ikke var den bedsteløsning teknisk set, og at mængden og typen af specialudvikling ville være stor.Justitsministeriet har oplyst, at leverandørens udmelding ikke blev opfattet som et klart bud-skab om, at det var mere risikofyldt at anskaffe POLSAG inden for end uden for FESD-ram-meaftalen. Justitsministeriet har videre oplyst, at også en løsning med 100 % nyudvikling vil-le være kompleks og risikofyldt, og at der ikke fandtes standardløsninger, der kunne opfyl-de politiets behov. Endelig har ministeriet oplyst, at det allerede fra starten af POLSAG-pro-jektet var klart, at POLSAG udviklet inden for FESD-rammeaftalen ville forudsætte betyde-lig specialudvikling.At det tidligt var klart, at den valgte løsning forudsatte betydelig udvikling, betyder efter Rigs-revisionens opfattelse, at Rigspolitiet i designet og udviklingen af POLSAG burde have væ-ret ekstra opmærksom på ikke at øge omfanget yderligere.Udviklingsopgaven voksede betydeligt i designfasen57. Udviklingen af Rigspolitiets krav til POLSAG skete i 3 trin – foranalysen, analysefasenog designfasen.58. Rigspolitiet identificerede og prioriterede med hjælp fra en ekstern konsulent en langrække behov til det nye sagsbehandlingssystem iforanalysen.Rigsrevisionens eksterne it-ekspert har gennemgået behovene. Gennemgangen viser, at behovene beskrev, hvad sy-stemet skulle gøre, men ikke, hvad det skulle bruges til, fx identificerede Rigspolitiet langelister af ting, man skulle kunne søge på, og hvilke rapporttyper der var behov for. Rigspoli-tiet beskrev i alt 260 behov.59. Efter udvælgelsen af leverandøren blev behovene omsat til krav og løsningsbeskrivelser.Det foregik ianalysefasenforud for kontraktunderskrivelsen. Rigspolitiet og leverandørenudviklede i fællesskab disse krav og løsningsbeskrivelser, der indgik i kontrakten som bilag.

Inden for FESD-rammeaftalen var det muligt at udarbejde kravspecifikationen og løsnings-beskrivelsen sammen med leverandøren. Det anses generelt for en fordel. Rigspolitiet og le-verandøren indgik i marts 2006 en separat kontrakt om leverandørens deltagelse i dennedel af projektet. Kontrakten var på ca. 8 mio. kr.Løsningsbeskrivelsen beskrev, hvordan et givet krav kunne opfyldes med Captia, og hvil-ken type udvikling det ville kræve. I denne fase blev nogle af Rigspolitiets behov fravalgt,fordi leverandøren vurderede, at Captia ikke var i stand til at opfylde disse specifikke behov,og nogle krav blev udskudt.60. Rigspolitiet stillede krav til POLSAG på 2 måder i kravspecifikationen. For det første stil-lede Rigspolitiet et overordnet krav om, at POLSAG skulle have samme funktionalitet somdet eksisterende system POLSAS. Dette krav blev omtalt som 1:1-kravet, jf. boks 3. For detandet indeholdt kravspecifikationen ca. 1.000 specifikke krav til POLSAG. De specifikke kravvedrørte ikke kun ny funktionalitet, men specificerede også eksisterende funktionalitet i POL-SAS.

Rigspolitiet har oplyst, at 1:1-kravet bl.a. blev formuleret for at sikre sig mod oversete behov.Kravet blev også anset som et styringsinstrument over for leverandøren, fordi Rigspolitietkunne undgå diskussioner med leverandøren om fortolkningen af enkelte krav.1:1-kravet kan ifølge Rigsrevisionen forstås på 2 måder. At POLSAG skulle understøtte po-litiets arbejdsprocesser ligesom POLSAS med udgangspunkt i Captias muligheder. Alter-nativt at POLSAG skulle understøtte politiet på præcis samme måde uden at tage hensyntil mulighederne i Captia.Løsningsbeskrivelserne, der viste, hvordan hvert krav kunne opfyldes, blev udarbejdet af un-derleverandøren og beskrev i grove træk, hvordan skærmbilleder og anden funktionalitet idet eksisterende POLSAS kunne erstattes af funktionalitet i Captia. Rigsrevisionens ekster-ne it-ekspert har gennemgået udvalgte krav og løsningsbeskrivelser. Gennemgangen viser,at leverandørens løsningsbeskrivelser byggede på den fortolkning af 1:1-kravet, som tog ud-gangspunkt i at bruge standardsystemets muligheder.61. Efter at Rigspolitiet og leverandøren underskrev kontrakten i april 2007, blev kravene ogløsningsbeskrivelserne idesignfasenomsat til systemdesigndokumenter. Underleverandø-ren skrev designdokumenterne i samarbejde med hovedleverandøren og Rigspolitiet.TabelEn database består aftabeller. En tabel kanfx være en liste af per-soner, en liste af pa-truljer, politiet har kørt,eller en liste af dyre-transporter, der skalkontrolleres.

BOKS 4. RIGSPOLITIET OG LEVERANDØRENS INDSATS FOR AT OMSÆTTE 1:1-KRAVETTIL DESIGNET AF POLSAGTil arbejdet med at omsætte kravene til designdokumenterne stillede Rigspolitiet med erfarne politi-folk (brugere), der havde viden om politiets forretning. Hovedleverandøren stillede med nogle af defolk, der var med til at drive POLSAS, og systemudviklere, der havde viden om POLSAS, men ikkeviden om politiets forretningsprocesser. Underleverandøren stillede med udviklere, der havde videnom Captia.Rigspolitiet og leverandøren designede systemet skærmbillede for skærmbillede og beskrev detal-jeret, hvad hver knap skulle gøre i forskellige situationer. Det var underleverandøren, der skrev de-signdokumenterne. Underleverandøren har bl.a. anført, at det kunne være svært for udviklerne at af-vise, at krav ikke skulle opfyldes på en bestemt måde, når den tilsvarende POLSAS-funktionalitet ik-ke var beskrevet, og det ikke var klart, hvad funktionaliteten skulle bruges til. Samtidig oplevede un-derleverandøren, at brugerne kunne være uenige om, hvordan POLSAS faktisk blev brugt.Bonnerup-rapporten fra 2001 pegede på, at brugerinddragelse kræver stram styring. Omkring bru-gerne påpegede rapporten bl.a., at projektledelsen skal udfordre og prioritere brugernes krav. Pro-jektledelsen skal endvidere sørge for, at projektets målsætninger er kendte for at undgå, at bruger-ne stiller krav til systemet, der bygger på forskellige forestillinger om, hvad systemet skal bruges til,og hvilke forretningsgange det skal understøtte.

Analyseresultaterne førte ikke til ændringer i designet af POLSAG, som blev godkendt i sep-tember 2008. Rigspolitiet udskød brugen af mere standardfunktionalitet til en senere versi-on af POLSAG. Parterne konkluderede, at et eventuelt senere projekt om at forbedre POL-SAG skulle tage udgangspunkt i politiets forretning og processer, og at de personer, der skul-le involveres, skulle have viden om den daglige brug af POLSAG og forretningsprocesserne.63. Ved replanlægningen i 2009 blev omfanget af specialudvikling yderligere øget.Omfanget af specialudvikling blev belyst i de eksterne konsulentrapporter i både 2009 og2011. I 2009-rapporten blev det konstateret, at underleverandørens tidsforbrug til designetaf POLSAG blev 7 gange højere end de estimater, der lå til grund for kontrakten. Underleve-randøren afholdt selv ekstraomkostningerne.Den eksterne konsulentundersøgelse i 2011 karakterisede POLSAG som et skræddersyetudviklingsprojekt og anslog, at 80 % af den samlede leverance var specialudvikling. Ifølgekonsulentrapporten vurderede leverandøren, at POLSAG på dette punkt var unikt. De flesteandre kunder havde snarere 10-20 % tilretning og 80-90 % standardsystem.

64. Rigsrevisionens undersøgelse af kontraktgrundlaget har vist følgende:Der var ikke sammenhæng mellem de forskellige kontrakter, som Rigspolitiet benyttedetil at anskaffe POLSAG. Fx måtte Rigspolitiet i en periode betale for drift af testmiljøer,selv om de ikke kunne bruges, fordi POLSAG-applikationen, der skulle bruge miljøerne,var blevet forsinket.Betalingen af leverandøren under hovedkontrakten, som var den økonomisk største, varikke knyttet til indholdet af leverancen, men alene til de forbrugte timer hos leverandøren.Det var set i lyset af det betydelige udviklingsarbejde uhensigtsmæssigt ikke at sikre enkobling mellem betalinger og leverancer. Kombineret med at projektet ikke var opdelt iselvstændige faser, hvor Rigspolitiet kunne stoppe op og få vished om projektets kvalitet,gav det Rigspolitiet begrænsede styringsmuligheder over for leverandøren.Rigspolitiet opstillede krav til POLSAGs svartider i kontrakten, men kunne ikke få leveran-døren til at garantere den samlede svartid, når systemet skulle kommunikere med andreit-systemer. Det medførte en risiko for, at systemet kunne leve op til de kontraktuelt fast-satte svartider for POLSAG, men stadigvæk give brugeren en utilfredsstillende oplevel-se af svartiderne, når randsystemerne blev koblet på.

Kontrakterne om POLSAG65. Kontraktgrundlaget voldte undervejs problemer for Rigspolitiet. Rigsrevisionen har ikkeforetaget en total gennemgang af kontraktgrundlaget for anskaffelsen af POLSAG, men ud-peger i det følgende nogle forhold, hvor kontrakten med leverandøren vanskeliggjorde Rigs-politiets styring af projektet. Nogle af vanskelighederne behandler vi også i kap. V.66. FESD-rammeaftalen indeholdt et standardkontraktgrundlag til leverancer indkøbt underaftalen. Rigspolitiet indgik hovedkontrakten om POLSAG på tilrettede standardvilkår underFESD-rammen. Det var vilkår, som Kammeradvokaten forhandlede til brug for leverancer afit-systemer med betydelige tilretninger.Kobling mellem betalinger og leverancer67. Det samlede kontraktgrundlag bestod ud over hovedkontrakten af flere andre kontrakter,der havde forskellige mekanismer til at styre leverancer og betalinger. Tabel 2 viser en over-sigt over de vigtigste kontrakter.

Det fremgår af tabel 2, at kontrakterne indeholdt forskellige måder at styre betalingerne tilleverandøren på.Betalingsmodellen i hovedkontrakten bestemte, at leverandøren fakturerede efter forbrugttid i overensstemmelse med en på forhånd fastlagt betalingsplan, som indgik i kontrakten.Dermed var der ingen kobling mellem betalinger og leverancer. Dog kunne leverandøren ik-ke fakturere over det til enhver tid akkumulerede beløb i betalingsplanen, og Rigspolitiet kun-ne tilbageholde 10 % af beløbet i betalingsplanen. Hovedkontrakten var den økonomisk stør-ste.Det er efter Rigsrevisionens opfattelse forbundet med styringsmæssige vanskeligheder i etudviklingsprojekt som POLSAG ikke at sikre en kobling mellem betalinger og leveret funk-tionalitet eller andre dokumenterede resultater. I yderste konsekvens risikerer kunden at be-tale for en ydelse, som ikke bliver leveret. Denne problemstilling skal ses i lyset af, at funk-tionaliteten i hovedkontrakten ikke var opdelt i selvstændigt værdiskabende faser. De forskel-lige udviklingspakker var indbyrdes afhængige og kunne ikke fungere selvstændigt. Rigspo-litiet kunne fx ikke tage den første udviklingspakke i brug. Systemet skulle tages i brug somen samlet løsning.T14-kontrakten og T16-kontrakten var i modsætning til hovedkontrakten baseret på, at Rigs-politiet betalte, når leverandøren havde opnået bestemte milepæle eller leveret bestemte le-verancer.68. Justitsministeriet har oplyst, at det på tidspunktet for kontraktens indgåelse var Rigspo-litiets vurdering, at der i FESD-kontraktvilkårene ikke var mulighed for at indgå en leverance-aftale med en betalingsplan knyttet til milepæle, som sikrede en kobling mellem betaling ogleveret funktionalitet.69. I efteråret 2010 forhandlede Rigspolitiet nye overtagelsesvilkår på plads med leverandø-ren. Her lykkedes det Rigspolitiet at få koblet en del af leverandørbetalingen i hovedkontrak-ten til leveret funktionalitet, så betalingen først skulle finde sted, når leverancen levede op tilnogle specifikke krav om bl.a. antallet af fejl. Rigspolitiet har oplyst, at der var tale om ca. 5mio. kr.Sammenhæng på tværs af kontrakter70. Hovedkontrakten omfattede udviklingen af POLSAG-applikationen (software), mens Rigs-politiet anskaffede de tekniske miljøer (hardware), som applikationen skulle køre på, over se-parate kontrakter. Rigspolitiet fik ikke etableret sammenhæng mellem kontrakterne og måt-te i en periode betale for drift af testmiljøer, der ikke kunne bruges, fordi POLSAG-applika-tionen var forsinket. I det eksterne review fra 2011 anslog konsulenterne, at Rigspolitiet sam-let set betalte 8 mio. kr. i driftsudgifter i perioden april 2010 - december 2010, hvor miljøer-ne ikke blev brugt. Rigspolitiet har oplyst, at det blev opvejet af rabatter, som Rigspolitiet ef-terfølgende opnåede på andre leverancer. Rigsrevisionen finder stadig, at det var uhensigts-mæssigt, at Rigspolitiet bragte sig i en situation, hvor Rigspolitiet betalte for en ydelse, somikke blev brugt.

BOKS 6. SVARTIDEt systems svartid forstås som tidsintervallet, fra brugeren sender sin kommando, til resultatet er syn-ligt for brugeren, og denne har mulighed for at afgive en ny kommando. Tidsforbruget kan opdeles i 9trin. Hvert trin tager tid, og den samlede tid er svartiden.1.2.3.4.5.6.7.8.9.10.Brugerens computer udfører et program, som eventuelt også bruger computerens egen disk.Programmet sender noget til serveren (et request) og venter på svar.Serveren udfører et program (Captia og POLSAG-udvidelser af Captia).Programmet henter og skriver ting i databasen.Programmet sender eventuelt noget til randsystemerne og venter på svar.Randsystemet udfører et program, der henter og skriver ting i sin egen database.Randsystemet svarer serveren.Serveren svarer brugerens computer.Brugerens computer sender eventuelt yderligere requests som i trin 2-8.Brugerens computer viser resultaterne på skærmen og lader brugeren afgive næste kommando.

I det eksterne review fra 2009 blev det konkluderet, at selv om leverandøren levede op tilde kontraktlige svartidskrav, ville der være en risiko for, at brugeren ville opleve utilfreds-stillende svartider, fordi kontraktgrundlaget ikke indeholdt et konkret svartidskrav til syste-mets samlede svartid. Det fremgår af rapporten, at de svartidsgarantier, Rigspolitiet opnå-ede, var de bedst opnåelige, da kontrakten blev indgået.Rigspolitiet har oplyst, at det ikke var muligt for Rigspolitiet at få leverandøren til at garante-re svartider for systemer, leverandøren ikke selv havde ansvaret for. Rigsrevisionens eks-terne it-ekspert har bemærket, at det normalt kan være svært, men at størstedelen af derandsystemer, som POLSAG skulle kommunikere med, blev leveret og drevet af leveran-døren.72. Risikoen for dårlige samlede svartider var et af de forhold, der indgik i grundlaget for atlukke POLSAG.

Det er Rigsrevisionens vurdering, at Rigspolitiets styring af POLSAG ikke var tilstræk-kelig i et så stort og komplekst it-udviklingsprojekt. Frem til 2010 forankrede Rigspo-litiet ikke POLSAG i den øverste ledelse på en måde, der tog højde for, at projektetville få betydelige konsekvenser for hele politiets organisation og derfor krævede enstærk ledelsesmæssig forankring.Rigspolitiet undlod i for stort et omfang at udarbejde skriftlige beslutningsgrundlagved centrale beslutninger og milepæle, fx forud for leverandørvalget og pilotdriftenpå Bornholm.Den måde, Rigspolitiet styrede projektøkonomien på, gav tidstro og deltaljerede øko-nomioplysninger. Interne resurser indgik dog ikke i styringen af projektøkonomien, selvom de havde et betydeligt omfang.Rigspolitiet brugte i vidt omfang eksterne konsulenter – ud over leverandørerne – tilat kompensere for de kompetencer, Rigspolitiet selv manglede til fx it og projektledel-se. Omfanget oversteg langt det forventede niveau og betød, at også centrale roller,der burde have været forankret i Rigspolitiets egen organisation, blev varetaget af eks-terne konsulenter.Rigspolitiets brug af eksterne konsulenter viser efter Rigsrevisionens opfattelse, at det– som allerede anbefalet i Bonnerup-rapporten i 2001 – bør være et centralt opmærk-somhedspunkt for ministerierne, hvordan de anvender og styrer eksterne konsulen-ter. Særligt til projektledelse i længerevarende udviklingsprojekter, hvor behovet forat sikre ejerskab og forankre viden og kompetencer i organisationen er stort.Rigsrevisionen vurderer, at Rigspolitiet ikke forberedte pilotdriften på Bornholm godtnok. Brugernes uddannelse var mangelfuld, og brugerne fik ikke nok støtte i at forstå,hvordan det nye system skulle bruges. Kontrakten betød samtidig, at Rigspolitiet ik-ke i tilstrækkeligt omfang kunne sikre, at leverandøren rettede de forretningskritiskefejl, der prægede systemet. Inden pilotdriften gennemførte Rigspolitiet ikke en anven-delsestest, der tester et system i de rigtige omgivelser og derfor ville have været eg-net til at finde flere af de fejl, som brugerne oplevede på Bornholm. Det var dog en for-del, at Rigspolitiet brugte en pilotdrift til at få afklaret, om POLSAG var klar til at blivebrugt i de andre politikredse.I en situation, hvor brugerne over lang tid oplevede fejl og problemer og samtidig skul-le have systemet til at fungere i den daglige sagsbehandling, blev pilotdriften på Born-holm en dårlig oplevelse.

74. Rigsrevisionens undersøgelse af projektorganiseringen har vist følgende:POLSAG-programmet var fra starten placeret i Rigspolitiets dataafdeling og var i perio-den frem til 2010 ikke forankret i et formelt beslutningsforum, der gik på tværs af politiet.Denne organisering tog ikke højde for, at projektet ville få betydelige konsekvenser forhele politiet og derfor krævede, at der var beslutningskraft og forankring på tværs af or-ganisationen og i den øverste ledelse. I 2010 etablerede Rigspolitiet en intern styregrup-pe med stærkere ledelsesmæssig forankring.Der har i forløbet været mangel på skriftlighed om en række centrale beslutninger, fx vedvalget af leverandør og beslutningen om at gå i pilotdrift på Bornholm. Det har efter Rigs-revisionens opfattelse begrænset Rigspolitiets løbende overblik over det hidtidige sags-forløb i et så omfattende og langstrakt projekt.Rigspolitiet brugte i vidt omfang eksterne konsulenter til at kompensere for de kompeten-cer, Rigspolitiet selv manglede til fx it og projektledelse. En markant andel af udgifternetil POLSAG-projektet blev anvendt til de eksterne konsulenter, og det realiserede konsu-lentforbrug lå langt over det forventede niveau ved projektets opstart. Rigspolitiet har op-gjort de samlede konsulentudgifter til 73 mio. kr. Over⅓af konsulentudgifterne gik til pro-jektledelse. Gennemgående for de undersøgte konsulenters ansættelsesforhold var lan-ge ansættelsesperioder og et højt omkostningsniveau.Rollen som programchef, der burde have været forankret i Rigspolitiets egen organisa-tion, blev i en længere periode varetaget af eksterne konsulenter.I den interne styring af projektøkonomien har Rigspolitiet anvendt et regneark, der gavet overblik over projektøkonomien med tidstro data, og som kunne understøtte ledelses-og økonomistyringsinformation.Rigspolitiets interne lønomkostninger indgik ikke i den interne styring af projektøkonomi-en på trods af, at de havde et betydeligt omfang på ca. 145 mio. kr.

Ledelsesmæssig forankring75. Bonnerup-rapporten fra 2001 pegede på, at it-projekter skal forankres stærkt i den øver-ste ledelse. Især ved et stort it-udviklingsprojekt, der altid vil have konsekvenser for en orga-nisations arbejdsprocesser.76. POLSAG-projektet var fra projektets start placeret i Rigspolitiets dataafdeling med enprogramleder til at varetage projektledelsen med reference til afdelingschefen for dataafde-lingen. Projektets placering i dataafdelingen som et rent it-projekt gav efter Rigsrevisionensopfattelse ikke projektledelsen mulighed for at træffe beslutninger om de fremtidige arbejds-processer i POLSAG på tværs af hele politiet.I september 2005 nedsatte rigspolitichefen en intern styregruppe. Rigspolitichefen var for-mand. Styregruppens formål var at følge projektet og drøfte principielle spørgsmål. Rigsre-visionens gennemgang viser, at styregruppemøderne i de 5 første år var rent orienterende.Det fremgår ikke af referaterne fra styregruppen, at der blev truffet beslutninger. Der var ge-nerelt tale om orienteringer og beskrivelser af status og indhold i relation til POLSAGs frem-drift.Sagsgennemgangen har desuden vist, at der i samme periode var en lav mødefrekvens istyregruppen, ligesom den øverste ledelse generelt var fraværende i styregruppen. Fx gikder helt op til 1 år mellem møder. Rigspolitichefen deltog i projektets første 5 år i 4 møder.77. Justitsministeriet har oplyst, at ministeriet og Rigspolitiet er enige i, at styregruppen reeltvar en følgegruppe, men at projektet var forankret i Rigspolitiets øverste ledelse i kraft af, atden daværende afdelingschef for dataafdelingen fulgte projektet tæt og løbende afrapporte-rede til rigspolitichefen, og at overordnede økonomi-, budget- og driftsspørgsmål blev drøf-tet med og godkendt af chefen for økonomi- og administrationsafdelingen.78. I 2009 tiltrådte en ny rigspolitichef, og i 2010 skiftede Rigspolitiet projektorganisation, ogbåde ledelsestilstedeværelsen og mødefrekvensen i styregruppen blev øget.Skiftet i projektorganisationen i efteråret 2010 medførte, at der nu var en programchef, enprogramejer og en programstyregruppe. Omorganiseringen fandt bl.a. sted, fordi projektetifølge Rigspolitiet var i en fase, hvor der skulle være fokus på organisatorisk udrulning. POL-SAG-projektet blev organisatorisk placeret i en nyetableret projektafdeling.Rigspolitiet vurderer, at den nye organisering i 2010, på trods af sin korte aktive levetid, med-førte en samlet styrkelse af arbejdet med POLSAG, men at det dog var vanskeligt at opnåden fulde effekt i så fremskredent et program.79. Samlet set manglede Rigspolitiet fra start et reelt beslutningsforum, der gik på tværs afpolitiets organisation, og som sikrede, at projektet var stærkt forankret i politiets ledelse. Detskyldtes for det første, at der kun var en intern følgegruppe uden beslutningskraft, for det an-det at projektet primært blev ledet i dataafdelingen, og for det tredje at beslutninger truffetefter drøftelser mellem afdelingschefen for dataafdelingen og henholdsvis rigspolitichefen ogchefen for Rigspolitiets økonomi- og administrationsafdeling ikke var formaliserede.Manglende skriftlige beslutningsgrundlag80. POLSAG-projektet har internt i Rigspolitiet været karakteriseret ved manglende skriftligdokumentation, fx om centrale ledelsesbeslutninger. Rigsrevisionen har ved sin sagsgen-nemgang kun fundet dokumentation for 1 skriftlig forelæggelse for rigspolitichefen om POL-SAG, og Rigspolitiet har ikke kunnet identificere yderligere.

81. Rigspolitiet har generelt produceret store mængder skriftligt materiale i projektforløbet, fxi de tekniske spor i form af testrapporter. Men de centrale beslutninger truffet af projektle-delsen og den øverste ledelse, fx i overgangene mellem forskellige faser i projektet, blev ge-nerelt ikke bakket op af skriftligt materiale. Det gælder en række centrale milepæle, fx daRigspolitiet besluttede at gå i forhandling med leverandøren, og da Rigspolitiet besluttedeat gå i pilotdrift på Bornholm.Rigspolitiet gik i forhandling med leverandøren i oktober 2005. Beslutningen blev baseret påen konsulentrapport fra september 2005. Den målte 2 mulige FESD-leverandører på 6 for-skellige parametre, men pegede ikke på den ene frem for den anden. Rigspolitiet udarbejde-de derudover ikke et skriftligt beslutningsgrundlag ved valget af leverandøren. Rigspolitiethar oplyst, at det indledende leverandørvalg blev truffet ved en mundtlig forelæggelse forrigspolitichefen.Beslutningen om at gå i pilotdrift på Bornholm var baseret på, at leverandøren fik bragt an-tallet af fejl i systemet ned til nogle kriterier, der blev aftalt mellem Rigspolitiet og leverandø-ren. Rigspolitiet udarbejdede ikke andet materiale, der fx beskrev konsekvenserne for pro-jektet i en situation, hvor projektet ud over den fortsatte udvikling af POLSAG også skullehåndtere en driftssituation på Bornholm med andre krav.82. Rigspolitiet har oplyst, at alle væsentlige overordnede spørgsmål fra projektets start blevforelagt og godkendt af rigspolitichefen, og at alle overordnede økonomi-, budget- og drifts-mæssige spørgsmål løbende blev drøftet med og godkendt af den daværende chef for Rigs-politiets økonomi- og administrationsafdeling. Rigspolitiet har bemærket, at disse drøftelserer foregået mundtligt i overensstemmelse med de samarbejdsprocedurer, der generelt vargældende i politiet på det tidspunkt.Det er Rigsrevisionens opfattelse, at Rigspolitiet burde have dokumenteret centrale milepæ-le og beslutninger som led i projektstyringen. Det har begrænset Rigspolitiets løbende over-blik over det hidtidige sagsforløb i et så omfattende og langstrakt projekt.Rigspolitiets brug af konsulenter83. Bonnerup-rapporten anbefalede i 2001, at kunden ikke i for høj grad lader konsulenterudøve projektledelsen og varetage strategiske og centrale funktioner, der bør forankres i or-ganisationen selv, ligesom kunden ikke bør overdrage centrale ledelsesopgaver i organisa-tionen til en ekstern part, der hverken er underlagt politisk eller økonomisk ansvar.84. Rigspolitiet har opgjort, at Rigspolitiet i perioden 2007 - maj 2012 anvendte ca. 73 mio.kr. på eksterne konsulenter, hvilket på daværende tidspunkt udgjorde 20 % af omkostninger-ne til POLSAG (ekskl. interne lønomkostninger). Der er dermed tale om, at konsulentforbru-get udgjorde en betydelig andel af omkostningerne til POLSAG-programmet.Konsulentforbruget var også markant højere end oprindeligt skønnet i Akt 119 16/5 2007,hvor Justitsministeriet skønnede forbruget til 12 mio. kr., svarende til 5,4 % af de samledeprojektomkostninger på det tidspunkt.85. Ud over de ca. 73 mio. kr. brugte Rigspolitiet i foranalysen inden kontraktindgåelse og-så ca. 23 mio. kr., hvoraf størstedelen blev anvendt på eksterne konsulenter. Desuden inde-holdt T14-kontrakten ca. 18 mio. kr. til projektledelse hos leverandøren.

Justitsministeriet har oplyst, at Rigspolitiet i lange perioder var nødt til at bruge eksterne kon-sulenter med et højere kompetenceniveau til at bistå Rigspolitiets medarbejdere med hen-blik på at løfte de kontraktuelle forpligtelser og gennemføre opfølgning på leverancerne i kon-trakten. Det skyldtes ifølge ministeriet flere forhold. Rigspolitiet havde bl.a. vanskeligt vedat rekruttere de rette medarbejdere, fx med erfaring fra større projekter. Desuden blev kom-pleksiteten i programmet væsentligt større end forventet ved programmets start, og særligtleverandørens manglende evne til at levere rettidigt og i den fornødne kvalitet krævede fle-re ledelsesresurser. Omfanget af brugen af konsulenter skal ifølge Justitsministeriet ses i ly-set af udvidelserne undervejs, og af at projektet strakte sig over en væsentlig længere pe-riode end forventet.86. Rigspolitiet brugte forskellige typer konsulenter. Nogle løste specifikke tekniske opga-ver, fx test, mens andre løste mere almindelige projektledelsesopgaver. Konsulentudgifter-ne fordelte sig ifølge Rigspolitiets egen opgørelse med ca. 61 % til tekniske specialister ogadministrativ støtte, ca. 37 % til projektledelse og ca. 2 % til juridisk bistand. Opgørelsen erberegnet på baggrund af konsulentforbruget i 2010 og 2011. Rigspolitiet vurderer, at dennefordeling er kendetegnende for alle årene.87. Rigsrevisionen har gennemgået kontraktforholdene for 2 ud af 8 projektledelseskonsu-lenter. Derudover har Rigsrevisionen gennemgået betalingerne til de 2 konsulenter, der harvaretaget programledelsen (som programchef) og de 2 konsulenter, der har ydet administra-tiv støtte. Samlet har over 50 forskellige enkeltpersoner virket som konsulenter for Rigspo-litiet i perioden 2010-2011, dog ikke alle på fuldtid.Gennemgående for de undersøgte forhold var lange ansættelsesperioder og et højt omkost-ningsniveau. Én af projektledelseskonsulenterne var tilknyttet projektet i flere år. Rigspoliti-ets omkostninger til denne ene konsulent, der var tilknyttet projektet på fuldtid, var 3,3 mio.kr. i 2008 og 3,2 mio. kr. i 2009.88. Rigsrevisionens undersøgelse har også vist, at eksterne konsulenter har varetaget cen-trale opgaver i projektforløbet. Funktionen som programchef blev i knap 2 år varetaget afeksterne konsulenter. Da den oprindelige programchef opsagde sin stilling i januar 2010, re-krutterede Rigspolitiet en ekstern konsulent til opgaven. Denne blev i sommeren 2010 afløstaf en anden ekstern konsulent, som først i oktober 2011 blev fastansat. Rigspolitiet har op-lyst, at de 2 konsulenter i høj grad fungerede som daglige ledere af programmet, men at deikke havde kompetence til at træffe væsentlige ledelsesmæssige beslutninger uden involve-ring af afdelingschefen, ligesom økonomiansvaret ikke blev overdraget til programchefen, sålænge denne var en ekstern konsulent. Afdelingschefen varetog derfor en række af de funk-tioner, som var tiltænkt programchefen.Rigspolitiets interne styring af projektøkonomien89. For at understøtte styringen af POLSAG-programmet udarbejdede Rigspolitiet et regne-ark, der blev brugt til at udgiftsstyre programmet. Det udgjorde et supplement til Navision,som er det økonomisystem, der generelt anvendes i staten.Oplysningerne i regnearket var ifølge Rigspolitiet mere tidstro og mere deltaljerede end i Na-vision, hvor regnskabsoplysningerne ofte først bliver registreret 1 måned efter, en faktura ermodtaget.Regnearket blev brugt til at opstille budgetter på baggrund af fx betalingsplaner og indgåe-de kontrakter. Modtagne fakturaer blev registreret i regnearket forud for betalingen i regn-skabssystemet, hvilket gav et aktuelt billede af udviklingen i budgetter og forbrug under POL-SAG-programmet. Regnearket gjorde det dermed muligt for programmets økonomiansvar-lige at følge budgetter og forbrug. Regnearket gjorde det også muligt for Rigspolitiet at ud-arbejde detaljeret økonomistyringsinformation på en række forskellige parametre, fx kon-traktniveau, udgiftstyper og aktivitetsområder.

Rigspolitiet har oplyst, at rapporter fra regnearket blev brugt i budgetrapporteringen til ledel-sen og de programansvarlige. Rigspolitiet har ikke kunnet dokumentere ledelsesbehandlin-gen af projektets økonomiske status, da Rigspolitiet ikke har gemt materialet.90. Rigsrevisionens gennemgang har vist, at sammenhængen til regnskabsoplysningerne iNavision ikke har været klar, fx har Rigspolitiet ikke kunnet dokumentere, at der har været fo-retaget afstemning mellem enkeltposter i henholdsvis Navision og regneark. Rigsrevisionenhar gennemgået sammenhængen mellem anlægsposterne i Navision og regnearket. Påtrods af en mindre uforklaret difference på under 1 % af anlægssummen vurderer Rigsrevi-sionen imidlertid, at regnearket har udgjort et tilstrækkeligt grundlag for den løbende styringaf projektøkonomien.91. Rigspolitiet havde i den interne styring fokus på de eksternt rettede udgifter, dvs. omkost-ninger til leverandører, konsulenter mv., og opgjorde ikke interne omkostninger så som interntid anvendt til POLSAG.Omfanget af interne resurser anvendt på POLSAG udgjorde i alt ca. 145 mio. kr. og har der-med været betydeligt. Det havde efter Rigsrevisionens opfattelse været relevant, at Rigspo-litiet kunne følge op på de anvendte resurser i den interne styring af projektøkonomien, isæri forbindelse med implementeringen af projektet, hvor alle dele af politiet i sidste ende skul-le have været inddraget i uddannelsesindsatsen.

Test i 3 miljøer93. Under udviklingen af POLSAG blev systemet testet af både Rigspolitiet og leverandø-ren. Testen af POLSAG foregik i 3 miljøer. Ved en systemtest hos underleverandøren, ensystemtest hos hovedleverandøren og Rigspolitiets kundetest. Hver part registrerede løben-de fejl, og hvordan de blev håndteret. Kundetesten var Rigspolitiets egen test af, om POL-SAG fungerede efter hensigten. Kundetesten testede også, om integrationen til randsyste-merne fungerede.94. De 3 testmiljøer var sat meget forskelligt op. Rigspolitiet har oplyst, at der generelt varproblemer og opstod fejl i overgangene mellem de forskellige miljøer, når systemet bevæge-de sig fra underleverandøren over hovedleverandøren til Rigspolitiets miljø. Underleveran-døren havde fx ikke adgang til hele den opsætning, som Rigspolitiet skulle anvende i pro-duktion, men udviklede i noget, der kun simulerede de rigtige miljøer (bl.a. randsystemerne).

96. Leverandøren udskød den oprindeligt planlagte overtagelsesprøve i maj 2010, fordi dervar så højt et fejlniveau, at leverandøren vurderede, at det ikke var muligt at bestå prøven.97. Da det høje fejlniveau udskød overtagelsesprøven, forhandlede Rigspolitiet i efteråret2010 nye vilkår for at overtage POLSAG på plads med leverandøren.For at kunne bestå overtagelsesprøven skulle leverandøren leve op til nogle aftalte kriterier,der angav, hvor mange fejl systemet måtte have inden for kategorierne 1-4, hvor 1 var kri-tiske og 4 uhensigtsmæssige fejl.Rigspolitiet og leverandøren aftalte bl.a., at det var de fejl, der var registreret på et giventtidspunkt, der skulle bruges som udgangspunkt for at vurdere, om leverandøren levede optil acceptkriterierne. Disse fejl blev opført på en liste, den såkaldte fastfrosne fejlliste.Fordelen for leverandøren var, at leverandøren kunne fokusere på fejlene på den fastfrosneliste. Selv om det samlede fejlniveau voksede, ville det ikke indgå i vurderingen af, om Rigs-politiet skulle overtage POLSAG.Ulempen for Rigspolitiet var, at nye fejl, der kom til, efter fejllisten var fastfrosset, ikke villetælle med i vurderingen af, om acceptkriterierne var nået. Dermed skulle Rigspolitiet overta-ge POLSAG, selv om nye fejl samlet set havde bragt POLSAG over acceptkriterierne. Rigs-politiet kom derfor i en situation, hvor leverandøren ikke var forpligtet til at håndtere eventu-elle nye alvorlige fejl inden pilotdriften. Nye fejl skulle i stedet håndteres som en del af ved-ligeholdelsen af POLSAG.Til gengæld fik Rigspolitiet mulighed for at udvide antallet af testcases i overtagelsesprøvenog ikke kun de testcases, der indgik i kontraktgrundlaget. Det betød, at Rigspolitiet fik mulig-hed for at teste bredere og potentielt finde flere fejl inden overtagelsen.98. I november 2010 var antallet af fejl på den fastfrosne liste under acceptkriterierne, ogRigspolitiet godkendte POLSAGs funktionalitet. Godkendelsen var betinget, idet den forud-satte, at leverandøren senere levede op til kontraktens svartidskrav.Det samlede fejlniveau i POLSAG var på godkendelsestidspunktet højere end acceptkrite-rierne. Tabel 3 sammenholder kriterierne i kontrakten med antallet af fejl på den fastfrosneliste og med det samlede fejlniveau den 9. november 2010, hvor Rigspolitiet godkendte POL-SAG.

Tabel 3 viser, at selv om antallet af fejl på den fastfrosne liste var under acceptkriterierne,var der på godkendelsestidspunktet samlet set ca. 10 gange så mange kategori 2-fejl og me-re end dobbelt så mange kategori 3-fejl end de aftalte kriterier.99. Justitsministeriet har oplyst, at der forud for aftalen om de ændrede overtagelsesvilkårvar sket et væsentligt fald i fejlniveauet, og at Rigspolitiet derfor vurderede, at der var en væ-sentlig positiv udvikling i fejlretningen, som ville medføre, at man inden for en overskuelig tidville have et produktionsklart POLSAG. Imidlertid blev der opdaget nye fejl samtidig med, atantallet af fejl på den fastfrosne liste blev nedbragt til det aftalte niveau. Det samlede fejlni-veau blev derfor ikke væsentligt ændret. Rigspolitiets forventning om, at den væsentlige re-duktion i antallet af fejl ville fortsætte, blev ifølge ministeriet ikke indfriet af leverandøren.100. Rigsrevisionens eksterne it-ekspert vurderer, at et fejlniveau af dette omfang ikke nød-vendigvis er alvorligt. Mange it-systemer overtages med langt flere kendte fejl. Det afgøren-de er, om kunden har taget stilling til fejlenes karakter, og hvilke konsekvenser fejlene kanfå for brugen af systemet.Rigsrevisionen har ikke set dokumentation for, at Rigspolitiet inden pilotdriften vurderede ar-ten af de kendte fejl og deres betydning for pilotdriften. Rigspolitiet udarbejdede fx heller ik-ke et samlet beslutningsgrundlag for at gå i pilotdrift på Bornholm. Rigspolitiet har dog oplyst,at Rigspolitiet vurderede, at de kendte fejl især var fejl, der kun ville optræde under specielleomstændigheder og ikke indebar en særlig risiko for pilotdriften. Rigsrevisionens eksterne it-ekspert har ud fra den fastfrosne fejlliste bekræftet denne vurdering.ProduktionMan taler om produk-tion, når et it-systemanvendes til at sagbe-handle i den dagligedrift (producere sager).Produktionsmiljøet erdet it-miljø – de sy-stemer – brugerne an-vender i sagsbehand-lingen.

101. Rigspolitiet har oplyst, at fordelen ved at godkende funktionaliteten på de aftalte vil-kår var, at POLSAG kunne sættes i pilotdrift i en fungerende politikreds. Herved kunneRigspolitiet på et oplyst grundlag få afklaret, om POLSAG var klar til at blive udrullet i de øv-rige kredse. Ulempen var, at politikredsen på Bornholm fik et system, hvor der var en ræk-ke kendte fejl, og hvor der var risiko for, at yderligere fejl blev opdaget, når systemet skulleflyttes ud i et egentligt produktionsmiljø på Bornholm.Testen af POLSAG omfattede ikke en anvendelsestest102. POLSAG gennemgik flere typer test. Rigsrevisionen har ikke vurderet kvaliteten af degennemførte test, men vi har undersøgt, hvordan Rigspolitiet forud for pilotdriften på Born-holm sikrede, at POLSAG var klar til at blive sat i drift på Bornholm.

Der er mange måder at teste, om et system er klar til drift. Rigsrevisionens eksterne it-eks-pert har anført, at det i POLSAG-projektet havde været hensigtsmæssigt at anvendelseste-ste POLSAG, før systemet blev sat i drift. Det skyldes bl.a., at der var tale om omfattende ud-vikling og et komplekst system med stor betydning for politiets arbejdsprocesser. Ved en an-vendelsestest prøves systemet i de rigtige omgivelser, med rigtige data og rigtige brugere,uden at der er tale om egentlig produktionsdrift. Det betyder, at det ville have været muligtat opdage andre fejl end dem, Rigspolitiet og leverandøren identificerede i system- og kun-detesten, og at fejlene ville være blevet opdaget, inden systemet blev taget rigtigt i brug, oginden fejlene fik konsekvenser for den daglige produktion.Der blev i testen af POLSAG ikke gennemført en egentlig anvendelsestest inden driften påBornholm. Pilotdriften på Bornholm fik derfor karakter af en anvendelsestest, hvor Rigspoli-tiet og leverandøren fik viden om, hvordan systemet virkede med rigtige brugere, og her kun-ne finde fejl, som først ville vise sig, når brugerne anvendte POLSAG i almindelig drift. Deter Rigsrevisionens eksterne it-eksperts vurdering, at de mangeartede fejl, der opstod underpilotdriften, er typiske for en anvendelsestest. Ved at gennemføre pilotdriften sikrede Rigs-politiet dog, at der var mulighed for at finde fejl i en almindelig driftssituation i en lille politi-kreds, inden POLSAG skulle rulles ud til de resterende politikredse.103. Rigspolitiet har oplyst, at der kun var et lille overlap – omkring 10 % – mellem de fejl,Rigspolitiet fandt i kundetesten under udviklingen af POLSAG, og de fejl, der efterfølgendeblev fundet under pilotdriften på Bornholm. Dvs. at langt størstedelen af de fejl, der blev op-daget i en driftssituation, ikke blev fundet i testforløbet. Rigspolitiet har oplyst, at det lille over-lap bekræftede den opfattelse, der var i Rigspolitiets projektledelse af, at det var vigtigt atkomme i drift for at finde ud af, om kundetestene fungerede og fandt de fejl, der ville være idrift. Det viser efter Rigsrevisionens opfattelse dog også, at det ville have været hensigts-mæssigt med en anvendelsestest, der – inden pilotdriften gik i gang – ville have været eg-net til at finde flere af de fejl, Rigspolitiet ikke kunne finde i kundetesten, men som brugernepå Bornholm oplevede.104. Rigspolitiet overvejede ved replanlægningen af projektet i 2009 at indskyde en pilottestfør pilotdriften, hvor man i 30 dage kunne teste systemet på Bornholm i en rigtig driftssitua-tion. Det ville have svaret til en anvendelsestest. Det var dog Rigspolitiets opfattelse, at detikke var muligt at gennemføre en anvendelsestest. Dels fordi en anvendelsestest ikke indgiki kontraktgrundlaget, dels fordi det ville have været en meget omfattende teknisk udfordring,fx ville det have været svært at undgå dobbeltregistreringer i randsystemerne, hvis disse bå-de skulle anvendes af POLSAG og POLSAS.Rigsrevisionens eksterne it-ekspert er enig i, at det ville have været vanskeligt at introduce-re en anvendelsestest sent i forløbet, og at der ville have været tekniske udfordringer. HvisRigspolitiet fra starten havde tænkt en anvendelsestest ind i projektet, ville disse udfordrin-ger imidlertid have været lettere at håndtere. Samtidig havde det efter Rigsrevisionens op-fattelse også været lettere at håndtere eventuelle kontraktmæssige udfordringer.105. Rigsrevisionen vurderer, at det gav vanskeligere betingelser for pilotdriften på Born-holm, at Rigspolitiet undlod at gennemføre en anvendelsestest.

Det fremgår af figur 4, at fejlniveauet faldt frem mod pilotdriften på Bornholm, der gik i gangi december 2010, for derefter at stige igen. Det skyldtes bl.a., at der blev opdaget flere fejl, daRigspolitiet begyndte at teste yderligere, fordi udviklingsarbejdet ikke var afsluttet. Figurenillustrerer kvaliteten af systemet ud fra en isoleret betragtning, nemlig omfanget af opgjortefejl. Figuren fortæller fx ikke noget om årsagerne til eller konsekvenserne af fejlene. Figurenviser heller ikke kategori 4-fejl, der ifølge kontrakten ikke skulle rettes.Rigspolitiet konkluderede i marts 2011, at pilotdriften havde givet mulighed for at fjerne deværste børnesygdomme. En pilotdrift identificerer typisk nogle af de børnesygdomme, somethvert nyt it-system må forventes at have, bl.a. fordi systemet bliver brugt i nogle nye situ-ationer. Det er bl.a. det, stigningen i fejlniveauet umiddelbart efter pilotdriftens opstart viseri figur 4. Efter 6 måneders pilotdrift konstaterede Rigspolitiet i juni 2011, at kvaliteten af denversion af POLSAG, som blev anvendt på Bornholm, ikke havde været optimal. Brugerne op-levede, at det tog lang tid at behandle sagerne på grund af fejl i systemet og manglende vi-den om systemet, jf. pkt.117. Systemet var også præget af problemer med forkert opsæt-ning. I oktober 2011 efter mere end � års drift på Bornholm konkluderede Rigspolitiet, atBornholms politikreds var stærkt negativt påvirket af de mange fejl.109. Rigsrevisionen har ikke vurderet, om fejlniveauet i POLSAG har været højere end vedandre lignende it-projekter, men har kunnet konstatere, at både Rigspolitiet og leverandørenhar vurderet, at fejlenes konsekvenser var problematiske.Rigsrevisionens eksterne it-ekspert har gennemgået Rigspolitiets fejllister. Gennemgangenviste, at POLSAG på Bornholm var plaget af en kombination af forskellige fejl og problemerpå forskellige tidspunkter i forløbet. Fejlene og problemerne kan ifølge Rigsrevisionens ek-spert i nogle tilfælde tilskrives Rigspolitiet og i andre leverandøren. Forskellige fejltyper i POL-SAG beskrives i boks 8-11.

BOKS 8. EKSEMPLER PÅ FEJL PÅ BORNHOLM I – DØGNRAPPORTENDet tog lang tid – op til 30 minutter – at trække en døgnrapport på 300 sager. Den garanterede svar-tid i kontrakten var 30 sekunder for en døgnrapport med 25 sager. Døgnrapporten viser, hvilke sagerpolitiet har haft i det senest døgn, men kan også udtrækkes for længere perioder, som man prøvedepå Bornholm. Den bruges bredt af både ledelse, vagthavende og betjente til at få overblik over op-gaverne og er derfor et vigtigt arbejdsredskab for politiet.Den lange svartid skyldtes problemer med integrationen til Word. Rigspolitiet havde ønsket, at døgn-rapporten kunne trækkes i Word-format ligesom i POLSAS i stedet for at bruge Captias standardrap-portfunktion. Leverandøren valgte en Word-teknologi, der virkede anderledes end forventet, og somgav lange svartider. Der var også problemer med opsætningen af Rigspolitiets systemer, som gav lan-ge svartider for Word-dokumenter. I samspillet mellem Rigspoliti, hovedleverandør og underleveran-dør gik der lang tid med at identificere og håndtere problemerne, der havde mange årsager. Parter-ne har angivet forskellige kilder til problemerne.

BOKS 9. EKSEMPLER PÅ FEJL PÅ BORNHOLM II – MANGE STAVEFEJL I BREVSKABELONERMange fejl var stavefejl i fx brevskabeloner. Stavefejl var ifølge kontrakten kategori 4-fejl (uhensigts-mæssigheder), der ikke skulle rettes. Men for politiet var der tale om forretnings- og produktionskriti-ske fejl, når der i stedet for afhøringsrapport stod afsløringsrapport i breve, der skulle sendes til fx an-klagemyndigheden, og sagsbehandleren ikke selv havde mulighed for at rette i skabelonen. Det varleverandørens opgave at rette fejlene. Rigspolitiet har oplyst, at det var en udfordring for leverandø-ren at rette fejlene på tværs af alle skabeloner, bl.a. fordi fejl, der var den samme i mange forskelligedokumenter – fx forkert datoformat – skulle rettes i alle skabeloner og ikke kun i én.De mange fejl i brevskabelonerne hænger ifølge underleverandøren også sammen med, at Rigspo-litiet oprindeligt skulle have levereret skabelonerne i Word-format, men endte med at levere dem i etandet format. Da det format ikke umiddelbart kunne omsættes til Word, måtte underleverandøren ef-terfølgende selv udarbejde skabelonerne og løbende tilpasse dem til Rigspolitiets ønsker.

BOKS 10. EKSEMPLER PÅ FEJL PÅ BORNHOLM III – LANGSOM LOGIN OG LÅSTE SAGERPå Bornholm tog det i starten meget lang tid at logge på. Årsagen var bl.a., at systemet var forkertsat op. Når en bruger loggede på, prøvede systemet at identificere ham ved at spørge den rækkeaf brugerkataloger, det var sat op til. Men det første katalog svarede ikke. Efter 20 sekunders vente-tid prøvede systemet det næste katalog i rækken. Det svarede heller ikke. Næste katalog blev prøvet,og til sidst lykkedes det. For brugeren så det ud som om, login var meget langsomt, men der var re-elt tale om en opsætningsfejl.Brugerne på Bornholm oplevede, at en sag blev "låst", så andre ikke kunne få adgang til den. Årsa-gen viste sig at være, at der gik 30 minutter, før systemet låste en sag op, så andre kunne få adgangtil den, hvis en bruger havde åbnet sagen og ikke lukket den, inden brugeren gik hjem. Captia brugernormalt "optimistisk låsning", dvs. at andre altid kan se sagen, selv om den er åben, men hvis de be-gynder at rette i data, mens andre også retter, får de en advarsel. Til POLSAG havde Rigspolitiet valgt"pessimistisk låsning", hvorfor sagen forblev låst i en længere periode.

Fejl og langsom fejlretning112. Under en pilotdrift som den på Bornholm, hvor der reelt var tale om en anvendelsestest,er det særligt afgørende for brugernes oplevelse af systemet, at de fejl, der besværliggørbrugernes arbejde, bliver rettet inden for rimelig tid.113. Rigspolitiet og leverandøren har oplyst, at en for stor andel af de rettede fejl opstodigen. Det betød, at fejl, der allerede én gang var registreret og forsøgt rettet, igen dukkedeop som fejl. Brugerne oplevede dermed, at de samme fejl kom igen og igen.Under driften blev det også konstateret, at fejlretningen affødte nye fejl. For brugerne betøddet, at fejlniveauet blev oplevet som konstant.114. Rigspolitiet var generelt kritisk over for tempoet i leverandørens fejlretning, hvilket Rigs-politiet bl.a. påpegede på møder i leverandørstyregruppen under pilotdriften.115. Kontrakten havde mål for, hvor hurtigt leverandøren skulle starte på at rette konstate-rede fejl, men indeholdt ikke mål for, hvornår en given fejl skulle være rettet. Det betød, atRigspolitiet ikke kunne bruge kontrakten til at styre tempoet i fejlretningen.I forbindelse med de nye overtagelsesvilkår, som blev aftalt i efteråret 2010, fik Rigspolitietmulighed for selv at prioritere, hvilke fejl leverandøren skulle rette først. Det øgede Rigspo-litiets styringsmuligheder. Rigspolitiet har oplyst, at fejlkategorierne i kontrakten (kategori 1-4)ikke nødvendigvis gav mulighed for at prioritere forretningskritiske fejl højest. Kategoriernetog ifølge ministeriet fx ikke højde for, at en stavefejl, som ville være kategori 4-fejl, der ikkeskulle rettes, kunne være forretningskritisk. Ifølge kontrakten skulle leverandøren ikke rettekategori 4-fejl.116. Justitsministeriet har oplyst, at Rigspolitiet og leverandøren var nødt til at prioritere i fejl-retningen. Rigspolitiet skulle bl.a. forholde sig til, om leverandørens resurser skulle gå til atafhjælpe pilotdriften på Bornholm eller til at forberede udrulningen i Midt- og Vestjylland. Si-deløbende med pilotdriften skulle leverandøren også bruge resurser til den fortsatte udvik-ling af POLSAG.Justitsministeriet har oplyst, at Rigspolitiet op til den planlagte driftsstart i Midt- og Vestjyl-land i juni 2010 også måtte vælge mellem at adressere mindre alvorlige fejl på Bornholm el-ler potentielt meget alvorlige fejl i Midt- og Vestjylland, fordi leverandøren ikke havde resur-ser nok til at løse begge opgaver. I den situation valgte Rigspolitiet at prioritere Midt- og Vest-jylland. Rigspolitiet har oplyst, at leverandøren afsatte flere resurser til fejlretning frem modRigspolitiets reklamation over systemet i november 2011.Uddannelse og støtte af brugerne på Bornholm117. Det er Rigsrevisionens opfattelse, at en tilstrækkelig forberedelse og støtte af brugerneer afgørende for en vellykket pilotdrift.118. Rigspolitiet forberedte forud for pilotdriften på Bornholm brugerne på at tage POLSAGi brug ved hjælp af en uddannelsesindsats, der kombinerede kursusdage, projekter i kredsenog et rejsehold kaldet det Nationale UddannelsesTeam, der bistod kredsen.119. Efter et halvt års pilotdrift konstaterede Rigspolitiet, at den gennemførte uddannelse afbrugerne på Bornholm havde været mangelfuld. Lange sagsbehandlingstider på Bornholmskyldtes ud over fejl i systemet bl.a. også, at brugerne manglede viden om funktioner i sy-stemet og smarte måder at bruge det på. Desuden var der blandt brugerne usikkerhed omde nye arbejdsprocesser i POLSAG. Derfor var det nødvendigt at genuddanne brugerne oggennemgå de nye arbejdsprocesser, før POLSAG kunne fungere i daglig brug.

Ca. 1 år efter starten på pilotdriften konstaterede Rigspolitiet, at der var behov for at gennem-gå sagsprocesserne på Bornholm. I den forbindelse skulle det besluttes, hvem der skulle gø-re hvad og hvornår, hvilket ville blive integreret i den uddannelsesindsats, der var under plan-lægning for de næste kredse. Rigspolitiet har oplyst, at Rigspolitiet brugte erfaringerne fraBornholm til at justere uddannelsesindsatsen for efterfølgende kredse.Rigspolitiet havde over 1 år efter, pilotdriften var startet, ikke i tilstrækkelig grad beskrevet denye arbejdsprocesser, der var affødt af POLSAG. Det betyder efter Rigsrevisionens opfattel-se, at brugerne i en lang periode havde dårligere betingelser for at udnytte systemet i sags-behandlingen.120. Det fremgår af baggrundsmaterialet til evalueringen af pilotdriften på Bornholm, at bru-gerne i vid udstrækning forventede et system, der kunne bruges i dagligdagen med hensyntil både funktionalitet og hastighed. Bornholms politikreds gik over til at bruge POLSAG100 %, så al sagsbehandling foregik i POLSAG. Det er Rigsrevisionens opfattelse, at Rigs-politiet ikke i tilstrækkelig grad sikrede, at brugernes forventninger var afstemt med det fak-tum, at pilotdriften reelt var en anvendelsestest, hvor brugerne måtte forvente, at der ville op-stå fejl, og at der ville gå tid, før systemet kunne bruges optimalt.

121. Svartider var et af de centrale risikoområder i POLSAG. Rigsrevisionens undersøgelseaf Rigspolitiets håndtering af risikoen for dårlige svartider har vist følgende:Rigspolitiet anså dårlige svartider for at være en af de centrale risici gennem hele POL-SAG-projektet. Rigspolitiet og leverandøren nedsatte tidligt i forløbet en arbejdsgruppetil at håndtere svartider, men arbejdet var præget af manglende fremdrift.Leverandøren igangsatte først sent målinger af svartiderne, hvorfor Rigspolitiet først kortfør idriftsættelsen på Bornholm havde målinger af systemets svartider. Rigspolitiet forsøg-te løbende at fremskynde arbejdet med svartiderne, men kunne hverken fremrykke ellerudvide leverandørens målinger af svartider ifølge kontrakten.POLSAGs svartider er aldrig endeligt dokumenteret.

Rigspolitiets håndtering af POLSAGs svartider122. Rigspolitiet identificerede fra starten af projektet og i risikovurderinger undervejs util-strækkelige svartider som en af de væsentlige risici i projektet. Det er Rigsrevisionens op-fattelse, at Rigspolitiet på den baggrund skulle følge denne risiko tæt i hele projektperioden.123. Hovedkontrakten definerede kun på et meget overordnet niveau, hvordan leverandørenskulle måle og dokumentere svartiderne. Det betød, at der, efter kontrakten var indgået, ude-stod et større arbejde for Rigspolitiet og leverandøren med at afklare, hvordan svartiderneskulle måles.Allerede i 2008 nedsatte Rigspolitiet og leverandøren en arbejdsgruppe med særskilt fokuspå at måle og forbedre svartiderne i POLSAG. Arbejdet i arbejdsgruppen var imidlertid præ-get af manglende fremdrift. Fx gik der � år, inden leverandørens projektleder tiltrådte, og se-nere manglede der specialister. Samtidig var arbejdet i arbejdsgruppen ifølge Rigspolitiet af-hængigt af fremdriften i udviklingen af POLSAG og etableringen af it-miljøerne. Når POLSAGblev forsinket, blev arbejdet med at måle svartider også forsinket.124. I den oprindelige projektplan havde leverandøren ikke planlagt test af svartider før senti projektet. Formålet med arbejdsgruppen var bl.a. at fremrykke test og at håndtere eventu-elle svartidsproblemer. Oprindeligt var formålet med arbejdsgruppen endvidere at undersø-ge de samlede svartider. Arbejdet blev imidlertid indsnævret, så det til sidst udelukkendekom til at handle om de kontraktuelt garanterede svartider og altså ikke den samlede svartid.Samtidig blev planerne for at gennemføre test af svartider løbende udskudt i projektperioden,og de første delvise svartidsmålinger forelå først i marts 2010.Rigspolitiet har oplyst, at leverandøren i stigende grad fokuserede på kontraktens svartids-garantier, efterhånden som projektet blev forsinket, og tidsplanen blev mere presset. End-videre satte kontrakten ikke Rigspolitiet i stand til at udvide testen af svartider til de samledesvartider eller fremrykke leverandørens måling af svartiderne.125. Det eksterne review, som Rigspolitiet fik gennemført i 2009, identificerede bl.a. dårligesvartider som en risiko. I reviewet konkluderede konsulenterne dog samtidig, at utilfredsstil-lende performance som udgangspunkt altid ville kunne løses med en tilstrækkelig indsats,og at risikoen for, at leverandøren ikke kunne levere denne for at opnå de kontraktlige fast-satte performancekrav, var lav. Rigspolitiet besluttede at behandle opfølgningen på reviewetskonklusioner om svartider i den eksisterende arbejdsgruppe om POLSAGs svartider.126. Det viste sig i efteråret 2010, at Rigspolitiet og leverandøren ikke havde en fælles for-ståelse af, hvornår svartiderne skulle dokumenteres endeligt. Leverandøren skulle ifølge kon-trakten først gennemføre en svartidsprøve ved driftsprøven efter udrulning i alle politikredse,men Rigspolitiet ønskede tidligere at få sikkerhed for, at svartiderne var gode nok. Den tid-ligere omtalte aftale om nye overtagelsesvilkår betød, at leverandøren skulle dokumenteresvartider, før Rigspolitiet satte POLSAG i pilotdrift. Det lykkedes dermed Rigspolitiet at frem-rykke tidspunktet for, hvornår leverandøren skulle dokumentere svartiderne i forhold til ud-gangspunktet i kontrakten.Aftalen indebar, at leverandøren 1 måned før pilotdriften på Bornholm skulle gennemføre ensvartidsprøve, og at leverandøren kunne bestå prøven med dobbelte svartider i forhold til ni-veauet i den oprindelige kontrakt. Inden den anden pilotdrift i Midt- og Vestjyllands politikredsskulle leverandøren leve op til de garanterede svartider i kontrakten.Den 22. november 2010 bestod leverandøren en svartidsprøve med dobbelte svartidskravforud for pilotdriften på Bornholm i december 2010.

130. Rigsrevisionens undersøgelse af indstillingen om at lukke POLSAG har vist følgende:Et udvalg nedsat for at gennemføre et eksternt review af POLSAG fandt på baggrund afet samlet risikobillede, at POLSAG burde lukkes. På det tidspunkt var systemet efter etlangt og dyrt udviklingsforløb næsten færdigudviklet.De elementer, der indgik i udvalgets vurdering, var relevante for at vurdere POLSAGsfremtid. De omfattede tekniske og leverandørmæssige risici, erfaringerne fra pilotdriftenpå Bornholm, manglende fremtidssikring og en business case for projektet.Udvalget havde en ekstern formand og repræsentanter fra både Finansministeriet, Ju-stitsministeriet og Rigspolitiet. Udvalgets arbejde fulgte bedste praksis for at vurdere it-projekter i staten.Som en del af udvalgets arbejde gennemførte konsulenter tekniske undersøgelser af svar-tiderne. De rejste alvorlig tvivl om POLSAG-systemets svartider. Det var efter Rigsrevisio-nens opfattelse imidlertid uklart, hvilke konklusioner der kunne drages på baggrund af un-dersøgelsernes resultater, og POLSAGs svartider er aldrig endeligt afklaret. Udvalget lag-de i den endelige vurdering af risikoen for, at POLSAG ville have utilfredsstillende svar-tider, vægt på, at svartiderne endnu ikke var tilfredsstillende dokumenteret.

Udvalget for en undersøgelse af POLSAG131. Justitsministeriet baserede sin indstilling til Finansudvalget om at lukke POLSAG på etarbejde i et embedsmandsudvalg med deltagelse af en ekstern formand og repræsentanterfra Finansministeriet, Justitsministeriet og Rigspolitiet. Udvalget blev nedsat, efter at Justits-ministeriet i efteråret 2010 måtte bede om Finansudvalgets tilslutning til at videreføre POL-SAG på et nyt grundlag, der bl.a. indebar en udvidelse af bevillingen.132. Udvalgets anbefaling bestod af en længere afrapportering. Anbefalingen blev behand-let i Regeringens Økonomiudvalg, der godkendte, at Justitsministeriet indstillede at lukke pro-jektet. Justitsministeriet gengav anbefalingen i indstillingen (Akt G) til Finansudvalget om atlukke projektet.Udvalgets arbejde blev gennemført på en måde, der ligner den måde, Statens IT-projektrådarbejder på. Det repræsenterer i dag bedste praksis for at vurdere it-projekter i staten.Risikoområder i anbefalingen om at lukke POLSAG133. Justitsministeriet baserede sin indstilling til Finansudvalget om at lukke POLSAG på enenig anbefaling fra Udvalget for en undersøgelse af POLSAG.Udvalgets anbefaling var baseret på en sammenvejning af 6 risikoområder. Udvalget konklu-derede på baggrund af disse risikoområder, at det ville være for dyrt og risikobetonet at brin-ge POLSAG i en stand, så det kunne føres sikkert i drift, og at der var en betydelig risiko for,at Rigspolitiet ville stå med et system, der ikke fungerede i praksis. Risikoområderne er gen-givet i tabel 4.

Tabel 4. Risikoområder og udvalgets konklusioner om POLSAGOmråderTekniske risiciLeverandørmæssige risiciUdvalgets konklusionerPOLSAGs kodekvalitet var utilstrækkelig, og leverandøren havde endnu ikke do-kumenteret, at POLSAG havde en tilstrækkelig performance og skalerbarhed.Samarbejdet mellem hovedleverandør og underleverandør fungerede ikke tilfreds-stillende, og Rigspolitiet havde på baggrund af de hidtidige erfaringer med leveran-døren manglende tillid til, at leverandøren havde evne eller vilje til at levere.Pilotdriften på Bornholm var et utilfredsstillende forløb, der bidrog til indtrykket af,at leverancerne fra leverandøren ikke var i orden. Oplevelsen var, at leverandø-rens forsøg på at rette fejl i systemet ikke løftede kvaliteten af et system, der varpræget af mange fejl.Det ville kræve en meget stor ændring i politiets arbejdsmetode og omfattendeforandringsledelse og uddannelse at gå fra papirbaseret til digital sagsbehand-ling. Dette ville blive besværliggjort, hvis brugerne oplevede, at systemet ikke fun-gerede tilfredsstillende, som det skete på Bornholm.POLSAG var ikke tilstrækkeligt fremtidssikret. Det indebar bl.a., at POLSAG ikkeunderstøttede effektivisering af politiets arbejdsprocesser og digital integration medandre myndigheder uden for politiet.Det ville være både tids- og resursekrævende at forsøge at genoprette POLSAGog løse de identificerede problemer. Kombineret med den hidtidige pris og forsin-kelser vurderede udvalget, at det ville have karakter af ”at smide gode penge ef-ter dårlige” at fortsætte med POLSAG. Samtidig var der begrænsede mulighederfor at effektivisere politiets arbejdsgange med udgangspunkt i systemet og begræn-sede gevinster i forhold til omkostningerne.

Udvalgets vurderinger var bl.a. baseret på et eksternt review udarbejdet af et konsulentfirma,herunder tekniske undersøgelser af POLSAG, og Rigspolitiets erfaringer fra pilotdriften påBornholm.134. Erfaringerne fra Bornholm har vi i vidt omfang behandlet i kap. V. De implementerings-mæssige risici i efterfølgende kredse var ifølge udvalget en konsekvens af erfaringerne påBornholm. De leverandørmæssige risici var ligeledes delvist en konsekvens af Rigspolitietserfaringer på Bornholm.Tekniske undersøgelser af POLSAG135. Som en del af det eksterne review i 2011 hyrede Rigspolitiet eksterne konsulenter tilbl.a. at gennemføre tekniske undersøgelser af POLSAG. Formålet var at give svar på, omPOLSAG kunne udrulles i de andre kredse efter Bornholm. De tekniske undersøgelser ind-gik som en del af arbejdet i Udvalget for en undersøgelse af POLSAG.136. Konsulenternes undersøgelser af svartider viste i første omgang alvorlige problemer.Det er efter Rigsrevisionens opfattelse imidlertid uklart, hvilke konklusioner der kunne dragesud fra undersøgelserne. Målingerne var fx foretaget i uddannelsesmiljøet, som var sat ander-ledes op end produktionsmiljøet. Konsulenterne havde ikke adgang til andre miljøer og måt-te efter aftale med Rigspolitiet konkludere på baggrund af uddannelsesmiljøet med de be-grænsninger, der lå heri. Konsulenterne gennemførte bl.a. sammenlignende analyser for atvurdere konsekvensen af begrænsningerne.137. Inden de tekniske undersøgelser blev færdiggjort var der ad flere omgange dialog mel-lem konsulenterne og leverandøren om metoderne bag rapporterne, og konsulenterne ind-arbejdede bl.a. kommentarer fra leverandøren, der påpegede fejl og mangler i rapporten.Antallet af brugertransaktioner, der lå til grund for konsulenternes målinger, var baseret påinformationer fra Rigspolitiet. Tallene blev justeret af Rigspolitiet, før rapporten blev færdig.Boks 12 forklarer nogle af de mere tekniske problemstillinger i de tekniske undersøgelser afPOLSAGs performance.

BOKS 12. DE TEKNISKE UNDERSØGELSEREksterne konsulenter undersøgte i 2011 POLSAGs svartider. Resultaterne dokumenterede de i enrapport kaldet et performance review. Hovedkonklusion viste nogle alvorlige problemer med POLSAGspotentielle svartid.Rigsrevisionens eksterne it-ekspert har gennemgået nogle af forudsætningerne og observationernei performance reviewet.For at dække alle politikredses behov skulle POLSAGs web-servere ifølge konsulenternes målingerbehandle 2.187 web-requests pr. sekund. Et web-request er en forespørgsel efter et ikon, et stykketekst eller data over nettet. Set med teknikerens øjne er det et meget stort tal, som ville kræve rigtigmange web-servere. At tallet var så højt, skyldtes ifølge konsulenterne den måde, POLSAG var pro-grammeret. Hovedkonklusionen var også, at databasen skulle behandle 100.000 SQL-kald pr. se-kund. Et SQL-kald henter data fra en database. Set med teknikerens øjne er det stort set umuligt athåndtere så stort et antal.Konsulenterne målte POLSAGs ydeevne i uddannelsesmiljøet, som havde korrekt kobling til randsy-stemerne, men var sat op på en anden måde end test- og produktionsmiljøerne.Udgangspunktet for konsulenternes målinger var Rigspolitiets tal for det forventede antal brugertrans-aktioner i løbet af en time for hele landet. Transaktionerne var af meget forskellig art, fx at starte sy-stemet (logge på og se sit startbillede), at oprette en sag og at søge efter en sag. Tallene var base-ret på målinger fra det eksisterende POLSAS-system. I alt skønnede konsulenterne, at der ved spids-belastning ville være ca. 40.000 brugertransaktioner pr. time for hele landet, dvs. ca. 11 pr. sekund.Hver brugertransaktion består af et antal web-requests til systemets web-servere. Konsulenterne mål-te antallet af requests for de forskellige brugertransaktioner. Tallet varierede mellem 13 og 900 ogvar i gennemsnit ca. 200 requests pr. brugertransaktion. Med 11 transaktioner pr. sekund bliver detde nævnte 2.187 web-requests pr. sekund.Mange requests drejede sig om at hente faste dele af skærmbillederne, fx programstumper og iko-ner. Hvis brugerens computer er sat korrekt op, husker den disse ting over flere dage, så de ikke skalhentes fra serveren hver gang (caching). Resultatet ville være, at der var langt færre requests i et kor-rekt driftsmiljø. Konsulenterne anførte, at de ikke havde mulighed for at se, hvordan caching var satop på uddannelsesmiljøets computere, men antog, at det var korrekt.Konsulenterne målte, at der i gennemsnit var 47 SQL-kald pr. request (inkl. 20 såkaldte interne kald).I alt giver det de nævnte 100.000 SQL-kald pr. sekund. Ingen af de involverede parter har kunnet for-klare det meget høje tal, men de er enige om, at med det givne program, burde det ikke være så højt.I en senere udgave af performancerapporten gentog konsulenterne disse tal i hovedkonklusionen,men tilføjede, at en ny måling i et produktionsmiljø viste forbedringer.

Udvalget konkluderede, at POLSAGs performance endnu ikke var tilfredsstillende dokumen-teret. Derudover påpegede udvalget, at Rigspolitiet risikerede at overtage et system, der le-vede op til kontraktens krav, men som ud fra en brugersynsvinkel ikke havde tilstrækkeli-ge svartider, fordi kontraktens krav ikke sikrede brugerne en acceptabel samlet svartid. Detskyldtes, at kravene til svartider i kontrakten kun gjaldt selve POLSAG og ikke de tilstøden-de randsystemer, jf. pkt. 71-72.Leverandørmæssige risici140. Udvalget vurderede bl.a., at nogle af de tekniske risici, der i 2011 blev påpeget af kon-sulenterne, også indgik i det review, Rigspolitiet fik gennemført i 2009, og at leverandørenikke havde fået gennemført afgørende forbedringer siden da.Udvalget koblede desuden de leverandørmæssige risici til erfaringerne under pilotdriften påBornholm. Udvalget vurderede, at Rigspolitiets erfaringer med leverandøren, især under pi-lotdriften på Bornholm, havde skabt mistillid til leverandørens evne og vilje til at bringe sy-stemet i en brugbar stand.Udvalget bemærkede endvidere, at det var Rigspolitiets opfattelse, at samarbejdet mellemhoved- og underleverandør ikke fungerede tilfredsstillende. Det medførte ifølge udvalget envæsentlig risiko for uforudsete omkostninger, forsinkelser og mangelfulde leverancer.Manglende fremtidssikring141. Udvalget konkluderede, at POLSAG fremstod som et sagsbehandlings- og arkiverings-system med begrænset understøttelse af arbejdsprocesser og uden understøttelse af inte-gration til andre interessenter uden for politiet, fx domstolene.Udvalget anførte, at det bl.a. skyldtes, at Rigspolitiet oprindeligt havde defineret POLSAG-projektet som et infrastruktur- og udskiftningsprojekt. Derfor havde Rigspolitiet ikke fra pro-jektets start lagt tilstrækkelig vægt på potentielle muligheder for at effektivisere arbejdsgan-ge og -processer i Rigspolitiet og på, at POLSAG skulle kunne danne grundlag for en digi-talisering, herunder integration mellem Rigspolitiet og andre myndigheder. Udvalget konklu-derede, at POLSAG i forhold til en effektiviserings- og digitaliseringsdagsorden fremstod somet forældet system.Business case for POLSAG142. Som en del af det eksterne review i 2011 kortlagde konsulenterne POLSAG-projektetssamlede udgifter og økonomiske gevinster med udgangspunkt i den statslige business case-model. Konklusionen i august 2011 var, at de totale udgifter til POLSAG over systemets le-vetid (2004-2020) ville blive i alt ca. 1,4 mia. kr., heraf ca. 950 mio. kr. til driftsudgifter. Deøkonomiske gevinster ved POLSAG ville være på ca. 550-850 mio. kr., afhængigt af omfan-get af de kopiopgaver, der ville falde bort med POLSAG. Tallene i business casen kan ikkesammenlignes med de oplysninger om POLSAGs samlede omkostninger, vi bringer her i be-retningen, eller med de bevilgede beløb i aktstykkerne, da der er tale om forskellige opgø-relsesmetoder.Kvalitative aspekter ved POLSAG, fx at det ville blive lettere for politiet at producere og ana-lysere, indgik ikke i business casen. Konsulenterne bemærkede derfor, at selv om POLSAGikke var attraktiv ud fra en rent økonomisk betragtning, så ville vurderingen af, hvor attraktivPOLSAG samlet set ville være for politiet også afhænge af de kvalitetsmæssige fordele vedsystemet.

Endvidere vurderede konsulenterne, at der – afhængigt af de tekniske risici og behovet forat adressere disse – var risiko for, at POLSAG ville koste yderligere mellem 0 og 300 mio.kr., og at der kunne komme betydelige forsinkelser. Denne vurdering var baseret på en ræk-ke scenarier for POLSAGs fremadrettede udvikling. Scenarierne omfattede både fuld funk-tionalitet, genopretning eller udbedring, laveste niveau af stabilisering og lukning – med detførste som det mest og det sidste som det mindst omkostningstunge scenarie. Scenarierneblev bl.a. opstillet på baggrund af tekniske undersøgelser af POLSAGs kodekvalitet, der isærblev brugt til at sige noget om de fremtidige muligheder for at vedligeholde og udvikle POL-SAG. Afhængigt af kodens kvalitet ville det blive mere eller mindre omkostningstungt at æn-dre i POLSAG i fremtiden.143. Udvalget brugte den opstillede business case og scenarierne for POLSAG som et cen-tralt element i vurderingen af POLSAGs fremtid. Det er i dag bedste praksis for it-projekterat opstille en business case.

2009AugustOktober2010MartsAprilSeptemberOktoberNovemberNovemberDecemberDecember2011AprilMajJuliAugustOktoberDecemberUdvalget for en undersøgelse af POLSAG blev nedsat. Dermed gik det andet større, eksterne review afPOLSAG i gang. Det skete med baggrund i Akt 66 16/12 2010.Rigspolitiet udsatte pilotdriften i Midt- og Vestjylland på grund af en faglig konflikt hos leverandøren ogbehov for yderligere tilretninger af POLSAG.Rigspolitiet igangsatte yderligere tekniske undersøgelser af POLSAG på grund af foreløbige resultaterfra konsulentundersøgelsen igangsat i april 2011.Det andet eksterne review blev afsluttet.Rigspolitiet udskød pilotdriften i Midt- og Vestjyllands politikreds på grund af de foreløbige resultater frareviewet.Leverandøren gennemførte svartidsprøve med udgangspunkt i de garanterede svartider i kontrakten.Leverandøren gennemførte de første begrænsede svartidsmålinger.Leverandøren udskød en planlagt overtagelsesprøve på grund af fejlniveauet i POLSAG.Rigspolitiet overtog T14-kontrakten og T16-kontrakten.Rigspolitiet og leverandøren indgik aftale om nye overtagelsesvilkår for POLSAG.Rigspolitiet godkendte funktionaliteten i POLSAG (godkendelsen var betinget, idet den forudsatte, atleverandøren senere levede op til kontraktens svartidskrav).Leverandøren bestod svartidsprøven med dobbelte svartidskrav.Finansudvalget tiltrådte aktstykke nr. 66 af 30. november 2010 om en forhøjet bevilling til POLSAG.POLSAG gik i pilotdrift på Bornholm.Det første større, eksterne review af POLSAG blev afsluttet.Rigspolitiet og leverandøren indgik aftale om replanlægningen af POLSAG (med forbehold for bevilling).

IndholdIgangsættelse af et samlet udviklings- og moder-niseringsprogram for politiets it-systemer. (Tagettilbage og erstattet med aktstykke nr. 74).Igangsættelse af et samlet udviklings- og mo-derniseringsprogram for politiets it-systemer.Omfatter flere projekter. Nyt sagsbehandlings-system udgør 153 (173) ud af 273 (309) mio. kr.Orientering om status om udviklings- og moderni-seringsprogrammet for politiets it-systemer.Tilslutning til at igangsætte anskaffelse af etnyt sagsbehandlingssystem og første fase afen integrationsløsning til politiet.Status om anskaffelse af nyt sagsbehandlingssy-stem.Videreførelse af anskaffelse af et nyt sagsbehand-lingssystem. (Taget tilbage og erstattet med akt-stykke nr. 66).Videreførelse af anskaffelse af et nyt sagsbe-handlingssystem.Fortroligt aktstykke. Mandat til at opsige POL-SAG-kontrakten og indstille anskaffelsen. Sam-let merbevilling på 313 mio. kr., der bestod af350 mio. kr. til straksafskrivning af POLSAG og37 mio. kr. i bevillingsbortfald.Orientering om resultatet af forhandlingerne medleverandøren og det indgåede forlig.

Systemtest i de rigtige omgivelser, med rigtige data og brugere, men uden at der er taleom egentlig produktionsdrift.It-system, der tjener et bestemt formål. Består af software, der fortæller computeren,hvad den skal gøre, og data, som systemet skal opbevare.Rapport fra 2001, der præsenterer en række anbefalinger til at gennemføre statslige it-projekter. Rapportens titel var ”Erfaringer fra statslige IT-projekter – hvordan gør mandet bedre?”Forespørgsel eller kommando, brugeren afgiver til et it-system, fx ”find en sag” eller”opret en sag”. Brugertransaktionen indebærer, at systemet foretager et antal requeststil web-serveren, inden svaret på forespørgslen kan præsenteres for brugeren. Antal-let af brugertransaktioner afhænger af brugsmønstret, fx kan der være mange transak-tioner mandag morgen, når alle brugere starter systemet op.Dokument, der beskriver forventede fordele/gevinster og omkostninger forbundet medet projekt.Mellemlager for data, så data ikke skal hentes fra et fjernt sted hver gang. Når et systemcacher, antager det, at data, der lige er blevet brugt, snart skal bruges igen og derforskal kunne hentes hurtigt.Standarddokumenthåndteringssystem, som POLSAG skulle baseres på.Konsekvensberegning, der kan anvendes som led i vurderingen af, om et givent pro-jekt kan betale sig økonomisk. Stort set det samme som en business case.Fastlægger, om den lovede svartid og tilgængelighed er til stede under rigtig drift.Projekt, hvor dele af eller hele formålet med projektet er at opnå effektiviseringer i denpågældende organisation.Elektronisk Sags- og DokumentHåndtering.Fællesoffentlig Elektronisk Sags- og Dokumenthåndtering.Fysiske it-komponenter, fx diske, kommunikationsledninger og regneenheder.It-projekt, der indfører ny eller opgraderer eksisterende it-teknologi, uden at de organi-satoriske processer skal forandres.Den hardware og basissoftware applikationen kører på, og den måde, de er sat op.Vurdering af, hvor godt et computerprogram er opbygget. Kodekvalitet kan bl.a. haveindflydelse på, hvor svært det er at opdatere og vedligeholde it-systemet.Dokument, der beskriver kundens behov som en række krav. På baggrund af kravenedesignes en løsning.Rigspolitiets egen test af, om POLSAG-systemet fungerede og dækkede kravene i krav-specifikationen og Rigspolitiets faktiske behov.

Beskrivelse af, hvordan de enkelte krav til det ønskede it-system opfyldes.Formålet med prøven er at fastlægge, om den aftalte funktionalitet og dokumentationer leveret. Ofte vil man også fastlægge, om de aftalte svartider er opnået.Udtryk for et it-systems ydeevne, fx svartider ved forskellig belastning.Andre it-systemer som et it-system skal kommunikere med. POLSAG skulle bl.a. kom-munikere med politiets egne eksisterende systemer og med SKATs systemer.En computerkomponents forespørgsel efter data, billeder eller tekst hos en anden kom-ponent.Egenskab, der indikerer systemets evne til at håndtere voksende mængder af transak-tioner på en effektiv måde, fx når antallet af brugere øges.En samling instruktioner, som fortæller en computer, hvad den skal gøre. Betegnes og-så som et computerprogram eller en applikation.Kan forekomme, hvis kunden ønsker særlige løsninger, som ikke er en del af et eksi-sterende it-systems standardfunktionalitet. Forekommer også, hvis et helt nyt it-systemudvikles fra bunden. Er typisk forbundet med risici, fordi løsningen endnu ikke er gen-nemprøvet i praksis.SQL (Structured Query Language) er et programmeringssprog til databaser. SQL bru-ges til relationelle databaser – dvs. data, der er organiseret i tabeller – som data kanhentes fra efter regler skrevet i SQL-sprog.Den eksisterende funktionalitet, der følger med ved køb af et standardsystem. Hvis kun-den ønsker at ændre på den eksisterende funktionalitet, kræver det specialudvikling.It-system, som allerede eksisterer, og som kan bruges til mange forskellige formål.Tidsintervallet, fra brugeren sender sin kommando i et it-system, til resultatet er synligtfor brugeren, og denne har mulighed for at afgive en ny kommando.Kontraktuelle krav om, hvor hurtigt et system skal svare under forskellige omstændig-heder.Prøve, hvor it-systemets svartider måles og sammenholdes med de krævede svartider.Beskrivelse af, hvad et system skal gøre i detaljer, når brugeren klikker på de forskel-lige knapper i forskellige situationer. Er fx baseret på krav- og løsningsbeskrivelser, somer udarbejdet forud for systemdesigndokumentationen.En database består af tabeller. I POLSAG kan en tabel fx være en liste af personer, enliste af patruljer, politiet har kørt, eller en liste af dyretransporter, der skal kontrolleres.Forespørgsel efter fx data, billeder eller tekststykker over internettet.Computerkomponent, der kan modtage web-request og returnere svar.Et udtryk for et it-systems evne til at svare under forskellige belastninger. Et andet ordfor performance.

354 mio. kr.

I alt ca. 567 mio. kr.

68 mio. kr.

145 mio. kr.

Efteråret 2008

Oktober 2009

November 2010

Juni 2009

Juni 2010

December 2010