Finansudvalget 2012-13
SB 9 1
Offentligt
1229190_0001.png
9/2012
Beretning om
politiets it-system POLSAG
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0002.png
9/2012
Beretning om
politiets it-system POLSAG
Statsrevisorerne fremsender denne beretning
med deres bemærkninger til Folketinget og
vedkommende minister, jf. § 3 i lov om
statsrevisorerne og § 18, stk. 1, i lov om
revisionen af statens regnskaber m.m.
København 2013
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 vedkommende
minister.
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, hvilket
forventes 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 Endelig
betænkning over statsregnskabet 2012, som afgives i april 2014.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
Henvendelse vedrørende
denne publikation rettes til:
Statsrevisorerne
Folketinget
Christiansborg
1240 København K
Telefon: 33 37 59 87
Fax: 33 37 59 95
E-mail: [email protected]
Hjemmeside: www.ft.dk/statsrevisorerne
Yderligere eksemplarer kan
købes ved henvendelse til:
Rosendahls-Schultz Distribution
Herstedvang 10
2620 Albertslund
Telefon: 43 22 73 00
Fax: 43 63 19 69
E-mail: [email protected]
Hjemmeside: www.rosendahls-schultzgrafisk.dk
ISSN 2245-3008
ISBN 978-87-7434-401-8
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0004.png
STATSREVISORERNES BEMÆRKNING
Statsrevisorernes bemærkning
Statsrevisorerne,
den 20. marts 2013
BERETNING OM POLITIETS IT-SYSTEM POLSAG
Politiets 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 i
februar 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 eksterne
konsulenter til at løse programledelsesopgaver, der burde have været forankret i
Rigspolitiets egen organisation.
At Rigspolitiets forberedelse og styring af POLSAG var mangelfuld og på flere
punkter 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 Larsen
Henrik Thorup
Helge Adam Møller
Kristian Jensen
Mogens Jensen
Klaus Frandsen
Statsrevisorerne påtaler, at Justitsministeriet har ført et utilstrækkeligt tilsyn,
og at ministeriet ikke har orienteret Finansudvalget rettidigt og fyldestgørende
om ændringer i POLSAG, projektets omkostninger og risici.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0005.png
Beretning til Statsrevisorerne om
politiets it-system POLSAG
Rigsrevisionen afgiver hermed denne beretning til
Statsrevisorerne i henhold til § 17, stk. 2, i rigsrevi-
sorloven, jf. lovbekendtgørelse nr. 101 af 19. januar
2012. Beretningen vedrører finanslovens § 11. Ju-
stitsministeriet.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0006.png
Indholdsfortegnelse
I.
 
II.
 
Introduktion og konklusion ........................................................................................... 1
 
Indledning .................................................................................................................... 6
 
A.
 
Baggrund .............................................................................................................. 6
 
B.
 
Formål, afgrænsning og metode ........................................................................... 8
 
Justitsministeriets styring af bevillingerne til POLSAG .............................................. 11
 
A.
 
De samlede omkostninger til POLSAG ............................................................... 12
 
B.
 
Bevillingsanmodninger til POLSAG .................................................................... 13
 
Rigspolitiets forberedelse af POLSAG ....................................................................... 19
 
A.
 
Rigspolitiets business case for POLSAG ............................................................ 19
 
B.
 
Rigspolitiets krav til POLSAG ............................................................................. 20
 
C.
 
Kontraktgrundlaget.............................................................................................. 24
 
Rigspolitiets styring af POLSAG-projektet ................................................................. 27
 
A.
 
Projektorganisering ............................................................................................. 28
 
B.
 
Rigspolitiets test af POLSAG før pilotdriften på Bornholm.................................. 32
 
C.
 
Problemer og fejl under pilotdriften på Bornholm................................................ 35
 
D.
 
Rigspolitiets håndtering af risikoen for dårlige svartider ..................................... 40
 
Grundlaget for at lukke POLSAG ............................................................................... 43
 
A.
 
Elementer i indstillingen om at lukke POLSAG ................................................... 43
III.
 
IV.
 
V.
 
VI.
 
Bilag 1. Kronologisk oversigt over POLSAG-projektet ........................................................ 49
 
Bilag 2. Forelæggelser for Finansudvalget ......................................................................... 51
 
Bilag 3. Ordliste ................................................................................................................... 52
 
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0007.png
Beretningen vedrører finanslovens § 11. Justitsministeriet.
I undersøgelsesperioden har der været følgende ministre:
Lene Espersen: november 2001 - september 2008
Brian Mikkelsen: september 2008 - februar 2010
Lars Barfoed: februar 2010 - oktober 2011
Morten Bødskov: oktober 2011 -
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0008.png
INTRODUKTION OG KONKLUSION
1
I. Introduktion og konklusion
1. Denne beretning handler om Rigspolitiets anskaffelse af it-systemet POLSAG, der efter
et langt og dyrt udviklingsforløb endte med ikke at blive taget i brug.
2. I februar 2012 godkendte Finansudvalget, at Rigspolitiet lukkede POLSAG og opsagde
samarbejdet med leverandøren. På det tidspunkt havde POLSAG-projektet været i gang i
knap 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 til
sags- 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. en
ny 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 kom
aldrig i drift i andre kredse.
5. Justitsministeriet har løbende forelagt aktstykker om POLSAG for Finansudvalget i takt
med, at projektet blev ændret og bevillingen øget.
6. Formålet med undersøgelsen er at vurdere Justitsministeriets og Rigspolitiets indsats for
at 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?
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0009.png
2
INTRODUKTION OG KONKLUSION
UNDERSØGELSENS HOVEDKONKLUSION
POLSAG 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 at
lukke 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 praksis
for 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 og
effektivisere arbejdsgange og processer, men valgte, at POLSAG skulle ligne
det eksisterende it-system så meget som muligt. Rigspolitiet sørgede ikke for
i 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, undervurderede
Rigspolitiet 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 fra
en 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 en
væ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 udvidet
projektet markant. I mellemtiden fortsatte projektet, og Rigspolitiet betalte i et
tilfæ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.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0010.png
INTRODUKTION OG KONKLUSION
3
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 Justitsministeriets
grundlag blev udarbejdet med deltagelse af eksterne repræsentanter i et setup, der
ligner 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å usikkerheden
og 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-projektet
på 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øren
fik 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 af
udvikling i designfasen, fordi Rigspolitiet og leverandøren ofte fortolkede kravene til
POLSAG 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 en
skræ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 kobling
mellem betalinger og leverancer i hovedkontrakten. Rigspolitiet fik dog på enkelte
punkter 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 projektet
ville få betydelige konsekvenser for hele politiets organisation og derfor krævede en
stærk ledelsesmæssig forankring.
Rigspolitiet undlod i for stort et omfang at udarbejde skriftlige beslutningsgrundlag
ved centrale beslutninger og milepæle, fx forud for leverandørvalget og pilotdriften
på 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, selv
om de havde et betydeligt omfang.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0011.png
4
INTRODUKTION OG KONKLUSION
Rigspolitiet brugte i vidt omfang eksterne konsulenter – ud over leverandørerne – til
at 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 for
at sikre ejerskab og forankre viden og kompetencer i organisationen er stort.
Rigsrevisionen vurderer, at Rigspolitiet ikke forberedte pilotdriften på Bornholm godt
nok. 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 forretningskritiske
fejl, 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 blive
brugt 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 og
leverandø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 bliver
de 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 til
POLSAG 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 til
2010 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 og
udelod omkostninger, der var en væsentlig forudsætning for at gennemføre POLSAG-
projektet.
Det er Rigsrevisionens opfattelse, at Justitsministeriet tidligere burde have orienteret
Finansudvalget om, at projektet ved en replanlægning i 2009 blev væsentligt ændret.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0012.png
INTRODUKTION OG KONKLUSION
5
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 12
mio. 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 kan
væ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 anderledes
end forventet.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0013.png
6
INDLEDNING
II. Indledning
A.
Baggrund
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 har
igangsat undersøgelsen på eget initiativ.
8. I februar 2012 godkendte Finansudvalget, at Rigspolitiet lukkede POLSAG-projektet og
opsagde samarbejdet med leverandøren. På det tidspunkt havde POLSAG været i gang i
knap 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 er
politiets 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å grund
af 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 bruge
POLSAS. POLSAG kom aldrig i drift i andre kredse.
BOKS 1. FORSKEL PÅ POLSAS OG POLSAG
POLSAS
er et sags- og dokumentstyringssystem, der er udviklet til politiet. Det blev taget i brug af
den første politikreds i oktober 1997. POLSAS blev leveret og vedligeholdt af samme leverandør, som
skulle levere POLSAG.
Sagsbehandlingen i POLSAS er papirbaseret, og systemet kan ikke ”tale” på tværs af politikredse, fx
kan man ikke søge oplysninger om personer mv. på tværs af kredse.
POLSAG
skulle være et fuldt digitaliseret og landsdækkende sags- og dokumentstyringssystem, som
skulle 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 og
elektronisk arkivering af dokumenter, mulighed for digital dataudveksling, bl.a. med domstolene, og
mulighed for internetbaseret selvbetjening for borgerne.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0014.png
INDLEDNING
7
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 et
væsentligt udestående investeringsbehov.
Flerårsaftalen for politiet 2004-2006 og FESD-rammeaftalen
13. 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 omfang
skulle benyttes i udviklingen af politiets sagsbehandlingssystem. Det indebar ifølge Justits-
ministeriet og Rigspolitiet, at POLSAG skulle anskaffes inden for FESD-rammeaftalen, hvis
det var muligt. Se boks 2 for en beskrivelse af FESD-rammeaftalen.
BOKS 2. FESD-RAMMEAFTALEN
FESD er en forkortelse for Fællesoffentligt Elektronisk Sags- og Dokumenthåndteringsprojekt. FESD-
projektet havde til formål at fremme brugen af elektronisk sags- og dokumenthåndtering (ESDH) in-
den for den offentlige administration.
Efter et EU-udbud kvalificerede 3 leverandører sig i 2004 til FESD-rammeaftalen med hver deres
ESDH-løsning. FESD-rammeaftalen indeholdt et standardkontraktgrundlag til leverancer indkøbt un-
der aftalen. De 3 leverandørers løsninger levede op til en standardkravspecifikation, men der var ta-
le om 3 meget forskellige tekniske løsninger.
Ved at købe inden for rammeaftalen skulle den ordregivende myndighed ikke gennemføre et særskilt
EU-udbud.
Rigspolitiet indgik i april 2007 aftale med en leverandør om levering af POLSAG inden for
FESD-rammeaftalen.
14. Figur 1 viser udvalgte centrale begivenheder i POLSAG-projektet.
Figur 1. Centrale begivenheder i POLSAG-projektet i perioden 2005-2012
Eksternt review
af POLSAG
(august 2009)
Rigspolitiet indleder
forhandlinger med
leverandøren om
levering af
POLSAG
(oktober 2005)
Rigspolitiet og
leverandøren
underskriver
hovedkontrakten
(april 2007)
Rigspolitiet og
leverandøren
indgår aftale om
replanlægning
(oktober 2009)
Eksternt review
af POLSAG
(august 2011)
Indstilling fra
Udvalget om
POLSAG
(januar 2012)
Rigspolitiet og
leverandøren
indgår forlig
(juni 2012)
POLSAG sættes
i pilotdrift på
Bornholm
(december 2010)
2005
2007
2009
2010
2011
2012
Finansudvalget
tiltræder
Akt 74 19/1 2005
Finansudvalget
tiltræder
Akt 119 16/5 2007
Justitsministeriet
fremsender
aktstykke nr. 157
(juni 2010), der
bortfalder den
1. september 2010
Finansudvalget
tiltræder
Akt 66 16/12 2010
Justitsministeriet
forelægger fortroligt
aktstykke G
(februar 2012)
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0015.png
8
INDLEDNING
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 er
eksterne undersøgelser af POLSAG, og den orange boks viser tidspunktet for opstarten i
Bornholms politikreds.
Lukningen af POLSAG i 2012
15. Et længere udredningsforløb lå forud for beslutningen om at lukke POLSAG. Arbejdet
blev 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 ny
tidsplan, 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 systemet
næsten færdigudviklet. Udvalget konkluderede, at det ville være for dyrt og risikobetonet at
bringe 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.
17. Justitsministeriet gengav udvalgets anbefaling i en indstilling (Akt G) til Finansudvalget
om 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ådgav
Rigspolitiet og Justitsministeriet om kontraktgrundlaget både op til og efter forelæggelsen
for Finansudvalget.
Rigspolitiet og leverandøren indgik forlig i juni 2012. Justitsministeriet oplyste umiddelbart
derefter Finansudvalget om værdien af forliget, der bestod af en kombination af en kontant
betaling fra leverandøren, eftergivelse af betalingskrav og en række fremtidige rabatter til
Rigspolitiet. 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.
Udvalget for en un-
dersøgelse af POL-
SAG
blev nedsat med
udgangspunkt i Justits-
ministeriets Akt 66
16/12 2010, hvoraf det
fremgik, at der skulle
laves et eksternt re-
view af POLSAG.
Udvalget skulle under-
søge årsagerne til for-
dyrelsen af POLSAG,
vurdere projektets fort-
satte risici og analyse-
re fremtidige driftsud-
gifter og mulige bespa-
relser/effektiviseringer.
Udvalget blev nedsat i
april 2011 og færdig-
gjorde sit arbejde med
en anbefaling i januar
2012.
B.
Formål, afgrænsning og metode
Formål
18. Formålet med undersøgelsen er at vurdere Justitsministeriets og Rigspolitiets indsats
for at gennemføre POLSAG-projektet. Det har Rigsrevisionen undersøgt ved at besvare føl-
gende spørgsmål:
Hvad var Justitsministeriets grundlag for at lukke POLSAG? (Kap. VI).
Gav Rigspolitiets forberedelse af projektet et godt grundlag for at anskaffe POLSAG?
(Kap. IV).
Har Rigspolitiet styret POLSAG-projektet tilfredsstillende? (Kap. V).
Har Justitsministeriet styret bevillingerne til POLSAG tilfredsstillende? (Kap. III).
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0016.png
INDLEDNING
9
Afgrænsning
19. Undersøgelsen omfatter perioden fra november 2003, hvor flerårsaftalen for politiet for
2004-2006 afsatte de første midler til POLSAG, og frem til juni 2012, som er tidspunktet for
forliget mellem Rigspolitiet og leverandøren.
20. Vi behandler i beretningen nogle af de mange årsager til, at POLSAG blev lukket. Det
er 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 som
er 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. Det
gælder også aftaler indgået med leverandøren om drift og vedligehold af POLSAG.
Metode
23. 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 at
tale 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. Det
skyldes 2 forhold. For det første har Rigspolitiets ledelsesbehandling været karakteriseret
ved 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 at
disse 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 april
2010 og frem til september 2011. Leverandørstyregruppen var det overordnede beslutnings-
forum for samarbejdet mellem Rigspolitiet og leverandøren. Den manglende dokumentation
har begrænset Rigsrevisionens mulighed for at afdække denne væsentlige periode i projek-
tet, herunder pilotdriften på Bornholm.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0017.png
10
INDLEDNING
25. Rigsrevisionen har gennemgået projektøkonomien. Herunder har Rigsrevisionen foreta-
get en særskilt gennemgang af Rigspolitiets konsulentudgifter. Kilderne hertil har omfattet
oplysninger i regnskabssystemer, Rigspolitiets registreringer af udgifter og træk fra politiets
tidsregistreringssystem.
26. Rigsrevisionen har modtaget bistand fra en it-ekspert fra IT-Universitetet i København
bl.a. til gennemgang af Rigspolitiets opgørelse af behov til POLSAG, kravspecifikation og
lø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øren
og underleverandøren.
28. Bilag 1 indeholder en kronologisk oversigt over POLSAG-projektet. Bilag 2 indeholder
en oversigt over de aktstykker, Justitsministeriet har forelagt for Finansudvalget. Bilag 3 in-
deholder en ordliste, der forklarer udvalgte ord og begreber.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0018.png
JUSTITSMINISTERIETS STYRING AF BEVILLINGERNE TIL POLSAG
11
III. Justitsministeriets styring af bevillingerne til
POLSAG
Det er Rigsrevisionens vurdering, at Justitsministeriet ikke har styret bevillingerne til
POLSAG 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 til
2010 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 og
udelod omkostninger, der var en væsentlig forudsætning for at gennemføre POLSAG-
projektet.
Det er Rigsrevisionens opfattelse, at Justitsministeriet tidligere burde have orienteret
Finansudvalget 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 12
mio. 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 kan
væ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 anderledes
end forventet.
29. I kapitlet vurderer vi Justitsministeriets styring af bevillingerne til POLSAG-projektet. Vi
vurderer bl.a. ministeriets økonomiske oplysninger i bevillingsanmodningerne til Finansudval-
get. Desuden behandler vi udvidelsen og fordyrelsen af projektet og de bagvedliggende år-
sager. Vi indleder kapitlet med at gennemgå de samlede omkostninger til POLSAG-projektet.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0019.png
12
JUSTITSMINISTERIETS STYRING AF BEVILLINGERNE TIL POLSAG
A.
De samlede omkostninger til POLSAG
30. Rigsrevisionens undersøgelse af de samlede omkostninger til POLSAG har vist følgen-
de:
De samlede omkostninger til POLSAG var ca. 567 mio. kr. i perioden fra 2005 til luknin-
gen i 2012. Heraf gik ca. 145 mio. kr. til interne lønomkostninger.
Fordelingen af de samlede omkostninger til POLSAG
31. 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, Rigspolitiet
har registreret. De eksterne driftsomkostninger er baseret på POLSAG-programmets inter-
ne økonomioplysninger, mens de interne lønomkostninger er skønnet med udgangspunkt i
træk fra politiets tidsregistreringssystem og forudsætninger anvendt i det eksterne review af
POLSAG 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 de
medarbejdere, der skulle bruge POLSAG.
Udviklingsomkost-
ninger
I et omkostningsbase-
ret regnskab skelnes
mellem anlæg og drift.
Udviklingsomkostnin-
ger til POLSAG blev
regnskabsmæssigt re-
gistreret som anlæg.
Bevillingerne via akt-
stykkerne til POLSAG
omfattede udelukken-
de anlægget, dvs. ud-
viklingsomkostninger-
ne til POLSAG.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0020.png
JUSTITSMINISTERIETS STYRING AF BEVILLINGERNE TIL POLSAG
13
De 3 omkostningstyper, og hvordan de blev finansieret, er illustreret i figur 2.
Figur 2. De samlede omkostninger til POLSAG i perioden 2005-2012 fordelt på type
Udviklingsomkostninger
til POLSAG-anlægget
354 mio. kr.
I alt ca. 567 mio. kr.
Eksterne
driftsomkostninger
68 mio. kr.
Interne lønomkostninger
145 mio. kr.
Omkostninger afholdt over aktstykker
Omkostninger afholdt over politiets generelle driftsbevillinger
Omkostninger afholdt over politiets generelle driftsbevillinger
Note: Forskellen mellem 2010-bevillingen (405,5 mio. kr.) og de udviklingsomkostninger til POLSAG-
anlægget, der faktisk var afholdt, da projektet blev lukket (354 mio. kr.), skyldes primært, at Rigs-
politiet ikke brugte hele bevillingen.
Kilde: Navision, Rigspolitiets interne økonomioplysninger og tal for interne lønomkostninger ajourført
af Rigsrevisionen ud fra politiets tidsregistreringssystem og eksternt review i 2011.
Figur 2 viser, at POLSAG samlet har kostet ca. 567 mio. kr. i perioden fra 2005 til luknin-
gen i 2012. Heraf gik ca. 354 mio. kr. til udviklingsomkostninger til POLSAG-anlægget, ca.
68 mio. kr. til eksterne driftsomkostninger og ca. 145 mio. kr. til interne lønomkostninger.
Rigspolitiet er enig i opgørelsen.
Bevillingen i aktstykkerne omfattede udviklingsomkostningerne, mens Rigspolitiet har afholdt
de øvrige omkostninger over politiets generelle driftsbevillinger.
B.
Bevillingsanmodninger til 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 til
POLSAG 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 af
tekniske it-miljøer, der øgede bevillingen med 75 mio. kr. (2010-priser). Justitsministeri-
et burde efter Rigsrevisionens opfattelse have medtaget et skøn over omkostningerne
til miljøerne allerede i aktstykke nr. 119 af 24. april 2007, da miljøerne var en væsentlig
forudsætning for at gennemføre projektet. At Justitsministeriet undlod dette bidrog til at
undervurdere de samlede omkostninger til POLSAG.
Justitsministeriet oplyste først i 2012 Finansudvalget om de interne lønomkostninger til
POLSAG 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.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0021.png
14
JUSTITSMINISTERIETS STYRING AF BEVILLINGERNE TIL POLSAG
Aktstykkerne vedrørende POLSAG har løbende været forelagt med forsinkelse i forhold
til 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 var
forudsat 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. Rigspolitiet
underskrev 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 til POL-
SAG
• Akt 74 19/1 2005
om igangsættelse
af udviklings- og
moderniseringspro-
gram for politiets it-
systemer.
• Akt 119 af 16/5
2007 om tilslutning
til at igangsætte
anskaffelse af et
nyt sagsbehand-
lingssystem.
• Akt 66 16/12 2010
om videreførelse af
et nyt sagsbehand-
lingssystem.
• I Akt G 23/2 2012
tiltrådte Finansud-
valget en merbevil-
ling til at nedskrive
POLSAG og et be-
villingsbortfald.
Bevillinger om POLSAG forelagt for Finansudvalget
33. 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år
af bilag 2.
I begyndelsen af 2005 godkendte Finansudvalget, at Justitsministeriet igangsatte et sam-
let moderniseringsprogram for politiets it-systemer. Programmet bestod af 14 projekter med
POLSAG som det største. Bevillingen til POLSAG udgjorde 173 mio. kr. ud af samlet 309
mio. kr. (2010-priser). Aktstykket blev forelagt, inden Rigspolitiet havde modtaget et tilbud
på POLSAG, hvorfor Justitsministeriet angav, at beløbet var forbundet med usikkerhed.
Omkring 2 �½ år senere anmodede Justitsministeriet i april 2007 om tilslutning til at anskaffe
et nyt sagsbehandlingssystem. Rigspolitiet havde på det tidspunkt afsluttet forhandlingerne
om 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 steg
projektets 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. Udviklingen i bevillingerne til POLSAG
Samlet bevilling (2010-priser)
Akt 19/1 2005
Akt 119 16/5 2007
Akt 66 16/12 2010
173 mio. kr.
236 mio. kr.
405,5 mio. kr.
Stigning (2010-priser)
-
63 mio. kr. eller 36 %
169,5 mio. kr. eller 72 %
Note: I tabellen udgør stigningen fra 2007 til 2010 169,5 mio. kr. Specifikationen af fordy-
relsen fra 2007 til 2010, jf. pkt. 35-37, udgør 164,5 mio. kr. Forskellen på de 2 tal
skyldes forskelle i, hvordan tallene er pristalsreguleret og afrundet.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0022.png
JUSTITSMINISTERIETS STYRING AF BEVILLINGERNE TIL POLSAG
15
Tabel 1 viser stigningen i bevillingerne til POLSAG fra 2005 til 2007 og fra 2007 til 2010. Vi
fokuserer 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 dermed
usikkert estimat.
Årsager til fordyrelsen af POLSAG fra 2007 til 2010
34. Rigsrevisionen har gennemgået årsagerne til, at POLSAG blev fordyret. Justitsministe-
riet redegjorde i aktstykket i 2010 for årsagerne til den udvidede projektøkonomi. Udvidelsen
på 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øer
35. 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øerne
var den hardware, som selve POLSAG-applikationen skulle køre på, fx under test og drift.
Nye udviklingspakker
36. 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 reserve
37. 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 en
ny reserve (2010-priser). Den oprindelige reserve var opbrugt, bl.a. på grund af et højere
konsulentforbrug 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 POLSAG
38. Rigsrevisionen har vurderet, om Justitsministeriet medtog alle væsentlige omkostnin-
ger i bevillingsanmodningerne i 2007 og 2010.
Omkostninger til tekniske it-miljøer
39. 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. At
Justitsministeriet ikke medtog et skøn over de tekniske miljøer i 2007-aktstykket bidrog til at
undervurdere de samlede omkostninger til POLSAG.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0023.png
16
JUSTITSMINISTERIETS STYRING AF BEVILLINGERNE 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 de
tekniske 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. april
2007. Rigspolitiet burde også have regnet de tekniske miljøer med i de interne budgetter for
at opnå et komplet grundlag for den interne styring af projektøkonomien.
Interne lønomkostninger
41. Justitsministeriet angav ikke et skøn over de interne lønomkostninger i aktstykkerne om
POLSAG 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 grund
kan 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 for
at realisere projektet, hvorfor det havde været naturligt, om Justitsministeriet havde oplyst
det 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, at
Rigspolitiet havde haft interne lønomkostninger til POLSAG på i alt 124 mio. kr. Oplysningen
blev gentaget i en orientering til Finansudvalget i juni 2012.
Rigsrevisionen har ajourført 2011-skønnet over de interne lønomkostninger på baggrund af
oplysninger 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 bevillingsanmodninger
43. I april 2005 oplyste Justitsministeriet, at anskaffelsen af et nyt sagsbehandlingssystem
ville 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. Den
kom med aktstykke nr. 119 i april 2007. Forsinkelsen skyldtes, at kontraktforhandlingerne
med leverandøren trak ud.
44. Oprindeligt forudsatte Justitsministeriet i det første aktstykke i 2005, at Finansudvalget
skulle orienteres årligt. Det skete ikke i 2009. Efter forelæggelsen af en status for projektet
i maj 2008, hvoraf det fremgik, at arbejdet med at realisere POLSAG forløb planmæssigt og
inden 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.
Interne lønomkost-
ninger til POLSAG
Skønnet over Rigspo-
litiets interne lønom-
kostninger omfatter
bl.a. medarbejdere,
der arbejdede med
POLSAG-projektet i
Rigspolitiet, tid brugt
på uddannelse i kred-
sene, undervisere i
POLSAG, kredspro-
jekter og tid brugt på
at genindtaste sager
fra POLSAG til POL-
SAS i Bornholms po-
litikreds.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0024.png
JUSTITSMINISTERIETS STYRING AF BEVILLINGERNE TIL POLSAG
17
I efteråret 2008 stod det klart, at leverandøren var forsinket, og Rigspolitiet og leverandøren
blev 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 som
tillæg til det eksisterende kontraktgrundlag. Rigspolitiet underskrev kontrakten med forbehold
for 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 en
stigning på 35 %.
Det var et generelt krav i budgetvejledningen, at væsentlige ændringer af it-projekter skulle
forelægges Finansudvalget. Justitsministeriet forelagde imidlertid først ændringen som følge
af 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 at
ministeriet senere valgte at trække aktstykket tilbage. Finansudvalget var således i juni 2010
orienteret om projektets status. Dermed gik der samlet ca. ¾ år, fra kontrakten om replanlæg-
ningen var underskrevet, til Justitsministeriet forelagde ændringen for Finansudvalget første
gang. 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
Udviklingstimer
Hovedkontrakten med
leverandøren var ba-
seret på timeforbrug.
Leverandøren fakture-
rede efter forbrugt tid
svarende til antallet af
timer brugt på at ud-
vikle POLSAG. Værdi-
en af kontrakten sva-
rede derfor til et antal
timer.
Budgetvejledning
2006
Ved væsentlige æn-
dringer af it-projekter
skal der ske forelæg-
gelse for Finansudval-
get. Det gælder bl.a.,
hvis de samlede udgif-
ter til et projekt på over
50 mio. kr. forøges med
10 % eller derover el-
ler med 10 mio. kr.
Efteråret 2008
Rigspolitiet og leverandøren
aftaler at replanlægge POLSAG.
Leverandøren igangsætter de aktiviteter,
der følger af replanlægningen.
Oktober 2009
Rigspolitiet og leverandøren
underskriver med forbehold for
bevillingsmæssig hjemmel kontrakt
om replanlægningen.
November 2010
Justitsministeriet
forelægger
aktstykke nr. 66
om replanlægningen
for Finansudvalget.
2009
2010
2011
Juni 2009
Rigspolitiet og
leverandøren
færdigforhandler
replanlægningen.
Juni 2010
Justitsministeriet
oversender
aktstykke nr. 157
til Finansudvalget.
Ministeriet trækker
aktstykket tilbage.
December 2010
Finansudvalget
tiltræder
aktstykke nr. 66
om replanlægningen.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0025.png
18
JUSTITSMINISTERIETS STYRING AF BEVILLINGERNE TIL POLSAG
Finansministeren
skrev i november 1996
til samtlige ministre, at
ministrene ”så hurtigt
som muligt og forsvar-
ligt” skulle orientere
Finansudvalget og fo-
relægge en fornyet
bevillingsanmodning,
hvis et it-projekt udvik-
ler sig anderledes end
forventet, hvad angår
økonomi, tid eller ind-
hold. Finansministeren
anførte, at det efter
omstændighederne
kunne være hensigts-
mæssigt at indhente fx
ekspertudsagn om pro-
jektets udvikling, ”og-
så selv om dette inde-
bærer en lille udsky-
delse af forelæggelsen
for Finansudvalget".
Kilde: Endelig betænk-
ning over statsregn-
skabet for finansåret
1999, s. 228.
Bevillingsoverholdelse – betaling uden hjemmel
47. Efter at Rigspolitiet og leverandøren i efteråret 2008 aftalte at replanlægge projektet, men
inden 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. Det
svarer 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, at
leverandø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 var
hjemmel til det.
Justitsministeriet har anført, at der i ministeriet og Rigspolitiet var stort fokus på og dialog
mellem myndighederne om at sikre, at fakturaer under den replanlagte kontrakt ikke blev
betalt, inden Justitsministeriet havde opnået hjemmel.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0026.png
RIGSPOLITIETS FORBEREDELSE AF POLSAG
19
IV. Rigspolitiets forberedelse af POLSAG
Det er Rigsrevisionens vurdering, at Rigspolitiets forberedelse af POLSAG-projektet
på 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øren
fik 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 af
udvikling i designfasen, fordi Rigspolitiet og leverandøren ofte fortolkede kravene til
POLSAG 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 en
skræ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 kobling
mellem betalinger og leverancer i hovedkontrakten. Rigspolitiet fik dog på enkelte
punkter afhjulpet nogle af disse uhensigtsmæssigheder mod slutningen af projektet.
48. I kapitlet vurderer vi Rigspolitiets forberedelse af projektet. Det omfatter Rigspolitiets ar-
bejde med at opstille fordele og omkostninger ved projektet og Rigspolitiets krav til systemet.
Endelig gennemgår vi udvalgte dele af kontraktgrundlaget.
A.
Rigspolitiets business case for POLSAG
49. Rigsrevisionens undersøgelse af Rigspolitiets business case for POLSAG har vist føl-
gende:
Rigspolitiet udarbejdede en business case ved opstarten af POLSAG-projektet, selv om
der ikke var krav herom på daværende tidspunkt.
Rigspolitiet opdaterede ikke business casen, selv om dens økonomiske forudsætninger
ændrede sig markant, og Rigspolitiet selv havde lagt op til, at den skulle opdateres, når
kontrakten var på plads.
Rigspolitiet brugte ikke business casen i den løbende styring af projektet og kunne derfor
ikke foretage valg på baggrund af en vurdering af omkostninger og fordele.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0027.png
20
RIGSPOLITIETS FORBEREDELSE AF POLSAG
Justitsministeriet og Rigspolitiet burde forud for udvidelsen af projektet i 2010 have udar-
bejdet en business case for at have et bedre grundlag for at vurdere POLSAGs fremtid.
Ifølge
Bonnerup-rap-
porten fra 2001
skal
en costbenefit-analyse
af hele projektet sikre,
at det fra starten bliver
synligt, om der er til-
strækkelig dokumen-
tation for projektets
samlede fordele. End-
videre skal en løbende
vurdering af costbene-
fit sikre, at nye ønsker
modsvares af, at min-
dre vigtige ønsker el-
ler krav udelades.
Rigspolitiets brug af business case
50. 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 underskrevet
med 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 og
samlede 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 af
muligheden 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 en
række usikkerheder ville være reducerede. Rigsrevisionens sagsgennemgang har vist, at
det ikke skete, ligesom business casen ikke blev brugt efterfølgende i den løbende styring
af 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, men
det afviste Justitsministeriet med henvisning til, at der ikke var udarbejdet en business case
ved bevillingen af projektet i 2007, og at det ikke oprindeligt havde været et krav.
Finansministeriets
business case-mo-
del for offentlige di-
gitaliseringsprojek-
ter
I dag indeholder Fi-
nansministeriets busi-
ness case-model for
offentlige digitalise-
ringsprojekter krav
om, at der skal udar-
bejdes en business
case, når statslige
myndigheder anskaf-
fer it-systemer.
I 2008 blev det et krav
at anvende business
case-modellen for pro-
jekter over 20 mio. kr.
I 2010 blev kravet ind-
arbejdet i budgetvejled-
ningen.
B.
Rigspolitiets krav til POLSAG
55. Rigsrevisionens undersøgelse af Rigspolitiets krav til POLSAG har vist følgende:
Rigspolitiet havde fra projektets start indikationer på, at POLSAG inden for rammerne af
et standardsystem ville kræve betydelig specialudvikling med deraf følgende risici. POL-
SAG endte med at blive en skræddersyet løsning baseret på et standardsystem, hvor
POLSAG blev tilpasset Rigspolitiet og ikke omvendt.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0028.png
RIGSPOLITIETS FORBEREDELSE AF POLSAG
21
Rigspolitiet opstillede kravene til POLSAG på 2 måder. Et overordnet 1:1-krav om, at
POLSAG skulle have samme funktionalitet som det eksisterende POLSAS. Dertil kom
ca. 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 stedet
for 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 er
Rigsrevisionens 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 udvikling
56. 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 muligt
for Rigspolitiet at anskaffe en FESD-baseret løsning, ligesom det var muligt at gennemføre
de fornødne tilpasninger på en måde, så det ifølge konsulenten var i overensstemmelse med
FESD-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 bedste
lø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 designfasen
57. Udviklingen af Rigspolitiets krav til POLSAG skete i 3 trin – foranalysen, analysefasen
og designfasen.
58. Rigspolitiet identificerede og prioriterede med hjælp fra en ekstern konsulent en lang
række behov til det nye sagsbehandlingssystem i
foranalysen.
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 lange
lister 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 i
analysefasen
forud for kontraktunderskrivelsen. Rigspolitiet og leverandøren
udviklede i fællesskab disse krav og løsningsbeskrivelser, der indgik i kontrakten som bilag.
3 trin i udviklingen af
krav
Foranalysen: Rigspoli-
tiet definerede sam-
men med en ekstern
konsulent behov til
POLSAG.
Analysefasen: Rigspo-
litiet formulerede krav
til POLSAG, og leve-
randøren beskrev løs-
ninger, inden parterne
underskrev kontrakten.
Designfasen: Underle-
verandøren designede
POLSAG i samarbejde
med hovedleverandø-
ren og Rigspolitiet ef-
ter indgåelsen af kon-
trakten. Designet blev
dokumenteret i så-
kaldte systemdesign-
dokumenter.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0029.png
22
RIGSPOLITIETS FORBEREDELSE AF POLSAG
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 denne
del 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 som
det eksisterende system POLSAS. Dette krav blev omtalt som 1:1-kravet, jf. boks 3. For det
andet indeholdt kravspecifikationen ca. 1.000 specifikke krav til POLSAG. De specifikke krav
vedrørte ikke kun ny funktionalitet, men specificerede også eksisterende funktionalitet i POL-
SAS.
BOKS 3. FORMULERINGEN AF 1:1-KRAVET
”Al nuværende funktionalitet i POLSAS skal tilvejebringes på en brugervenlig måde i det nye POL-
SAG. Ved tilvejebringelse af tilsvarende funktionalitet som i POLSAS i dag forstås etablering af funk-
tionalitet – baseret på Captia-løsningen – som understøtter samme forretningsprocesser og løser sam-
me opgaver, som det eksisterende POLSAS gør i dag.”
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 Rigspolitiet
kunne 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 hensyn
til 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 i
det 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 og
løsningsbeskrivelserne i
designfasen
omsat til systemdesigndokumenter. Underleverandø-
ren skrev designdokumenterne i samarbejde med hovedleverandøren og Rigspolitiet.
Tabel
En database består af
tabeller. En tabel kan
fx være en liste af per-
soner, en liste af pa-
truljer, politiet har kørt,
eller en liste af dyre-
transporter, der skal
kontrolleres.
Rigsrevisionens eksterne it-eksperts gennemgang af udvalgte designdokumenter viser, at
POLSAG nu indebar en betydeligt større udviklingsopgave, end der måtte forventes ud fra
kontraktens løsningsbeskrivelser. Bl.a. krævede designet ca. 500 kundespecifikke tabeller
ud over de ca. 300 tabeller, der var indeholdt i Captia.
Den tilvækst i specialudvikling er efter Rigsrevisionens opfattelse et udtryk for, at 1:1-kravet
i designfasen ofte blev fortolket sådan, at POLSAG skulle gøre præcis det samme som POL-
SAS, hvorved der i betydeligt omfang blev set bort fra de muligheder, som lå i Captia, jf. boks
4.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0030.png
RIGSPOLITIETS FORBEREDELSE AF POLSAG
23
BOKS 4. RIGSPOLITIET OG LEVERANDØRENS INDSATS FOR AT OMSÆTTE 1:1-KRAVET
TIL DESIGNET AF POLSAG
Til 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 de
folk, der var med til at drive POLSAS, og systemudviklere, der havde viden om POLSAS, men ikke
viden om politiets forretningsprocesser. Underleverandøren stillede med udviklere, der havde viden
om 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.
Rigspolitiet og leverandørens analyse af den voksende specialudvikling
62. På initiativ fra Rigspolitiet undersøgte Rigspolitiet og leverandøren i 2008, hvordan desig-
net af POLSAG havde udnyttet standardfunktionaliteten i Captia. Efter at have gennemgået
dele af designet, der var godkendt eller tæt på at blive godkendt i maj 2008, var konklusio-
nen, at POLSAG-designet udnyttede den leverede standardfunktionalitet mindre godt. I fle-
re tilfælde havde Rigspolitiet og leverandøren valgt at specialudvikle løsninger, som med for-
del kunne have været løst inden for standardrammerne, jf. boks 5. Det ville dog ifølge Rigs-
politiet og leverandørens analyse have forudsat større forretningsanalyser.
BOKS 5. EKSEMPEL PÅ MANGLENDE UDNYTTELSE AF CAPTIA
Rigspolitiet og leverandøren konkluderede i analysen af designet, at personkategorierne i POLSAG
var baseret på POLSAS’ måde at opfatte personer på og ikke på Captias. Hvis løsningen havde ud-
nyttet Captia mere, ville mange kontroller i POLSAG have været overflødige eller nemmere, og det
ville have været lettere at udnytte nye faciliteter i kommende versioner af Captia.
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 og
2011. I 2009-rapporten blev det konstateret, at underleverandørens tidsforbrug til designet
af 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æddersyet
udviklingsprojekt og anslog, at 80 % af den samlede leverance var specialudvikling. Ifølge
konsulentrapporten vurderede leverandøren, at POLSAG på dette punkt var unikt. De fleste
andre kunder havde snarere 10-20 % tilretning og 80-90 % standardsystem.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0031.png
24
RIGSPOLITIETS FORBEREDELSE AF POLSAG
C.
Kontraktgrundlaget
64. Rigsrevisionens undersøgelse af kontraktgrundlaget har vist følgende:
Der var ikke sammenhæng mellem de forskellige kontrakter, som Rigspolitiet benyttede
til 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, var
ikke 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 en
kobling mellem betalinger og leverancer. Kombineret med at projektet ikke var opdelt i
selvstæ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 andre
it-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 POLSAG
65. Kontraktgrundlaget voldte undervejs problemer for Rigspolitiet. Rigsrevisionen har ikke
foretaget 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 under
aftalen. Rigspolitiet indgik hovedkontrakten om POLSAG på tilrettede standardvilkår under
FESD-rammen. Det var vilkår, som Kammeradvokaten forhandlede til brug for leverancer af
it-systemer med betydelige tilretninger.
Kobling mellem betalinger og leverancer
67. 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.
Tabel 2. POLSAG-kontrakter
Kontrakt
Hovedkontrakt (POLSAG FESD)
T14
T16
Driftsaftale
Indhold
Design og udvikling af POLSAG-applikationen.
Opgradering af eksisterende systemer til at kom-
munikere med POLSAG.
Etablering af driftsmiljøer til POLSAG.
Tilføjelser til politiets eksisterende driftsaftaler
med henblik på drift af test- og driftsmiljøer.
Styringsmekanisme
Betalingsplan fastlagt i kontrakten.
Milepælsbetaling.
Milepælsbetaling og månedligt
vederlag.
Månedligt vederlag.
Kilde: Rigspolitiets kontrakter POLSAG FESD, T14, T16 og driftsaftale (PSAG001).
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0032.png
RIGSPOLITIETS FORBEREDELSE AF POLSAG
25
Det fremgår af tabel 2, at kontrakterne indeholdt forskellige måder at styre betalingerne til
leverandøren på.
Betalingsmodellen i hovedkontrakten bestemte, at leverandøren fakturerede efter forbrugt
tid 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 et
udviklingsprojekt 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 som
en 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 og
leveret 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 til
nogle specifikke krav om bl.a. antallet af fejl. Rigspolitiet har oplyst, at der var tale om ca. 5
mio. kr.
Sammenhæng på tværs af kontrakter
70. 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, som
ikke blev brugt.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0033.png
26
RIGSPOLITIETS FORBEREDELSE AF POLSAG
Randsystemer
POLSAG skulle hente
og aflevere data i en
række forskellige it-sy-
stemer, fx Kriminalre-
gistret og politiets sy-
stem til at håndtere bø-
der.
Rigspolitiets krav til POLSAGs svartider
71. POLSAG skulle hente oplysninger fra andre it-systemer (randsystemer), når der blev ar-
bejdet i POLSAG.
Kontrakten indeholdt krav til svartider for selve POLSAG-systemet, men ingen konkrete svar-
tidskrav for POLSAGs kommunikation med randsystemerne, jf. trin 5, 6 og 7 i boks 6. Her
angav kontraktgrundlaget, at svartiden skulle være rimelig. Det forringede Rigspolitiets mu-
ligheder for at sikre tilfredsstillende samlede svartider for POLSAG.
BOKS 6. SVARTID
Et 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 9
trin. 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.
Det er hele tidsintervallet fra 1 til 10, der er vigtigt for brugeroplevelsen, da det bestemmer den sam-
lede tid, brugeren skal vente. Brugeren oplever ikke svartiden som god i en situation, hvor svartider-
ne i trin 1-4 og 8-10 isoleret set er gode, hvis brugeren skal vente på svar fra randsystemerne i trin 5-7.
Svartiderne fra randsystemerne er derfor en integreret del af brugerens oplevelse af den samlede svar-
tid.
I det eksterne review fra 2009 blev det konkluderet, at selv om leverandøren levede op til
de 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 de
randsystemer, 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 at
lukke POLSAG.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0034.png
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
27
V. Rigspolitiets styring af POLSAG-projektet
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 projektet
ville få betydelige konsekvenser for hele politiets organisation og derfor krævede en
stærk ledelsesmæssig forankring.
Rigspolitiet undlod i for stort et omfang at udarbejde skriftlige beslutningsgrundlag
ved centrale beslutninger og milepæle, fx forud for leverandørvalget og pilotdriften
på 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, selv
om de havde et betydeligt omfang.
Rigspolitiet brugte i vidt omfang eksterne konsulenter – ud over leverandørerne – til
at 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 for
at sikre ejerskab og forankre viden og kompetencer i organisationen er stort.
Rigsrevisionen vurderer, at Rigspolitiet ikke forberedte pilotdriften på Bornholm godt
nok. 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 forretningskritiske
fejl, 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 blive
brugt 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.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0035.png
28
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
Gennem hele projektforløbet var dårlige svartider en central risiko, som Rigspolitiet og
leverandø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 bliver
de samme som ved en driftsprøve. Til gengæld kan kunde og leverandør gennem ud-
viklingen gradvist reducere risikoen for dårlige svartider.
73. I kapitlet vurderer vi Rigspolitiets styring af projektet. Vi ser på, hvordan Rigspolitiet or-
ganiserede sin egen projektledelse og den interne styring af projektøkonomien, og hvordan
Rigspolitiet styrede overgangen fra udvikling til implementering. De vigtige milepæle i over-
gangen var Rigspolitiets test af POLSAG og håndtering af pilotdriften på Bornholm. Sidst i
kapitlet behandler vi, hvordan Rigspolitiet håndterede en af de centrale risici i projektet – ri-
sikoen for dårlige svartider.
A.
Projektorganisering
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 for
hele 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 ved
valget 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 udgifterne
til 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 gav
et 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.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0036.png
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
29
Ledelsesmæssig forankring
75. 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 en
programleder til at varetage projektledelsen med reference til afdelingschefen for dataafde-
lingen. Projektets placering i dataafdelingen som et rent it-projekt gav efter Rigsrevisionens
opfattelse 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 i
styregruppen, ligesom den øverste ledelse generelt var fraværende i styregruppen. Fx gik
der 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 reelt
var en følgegruppe, men at projektet var forankret i Rigspolitiets øverste ledelse i kraft af, at
den 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, og
bå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, en
programejer og en programstyregruppe. Omorganiseringen fandt bl.a. sted, fordi projektet
ifø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 af
politiets organisation, og som sikrede, at projektet var stærkt forankret i politiets ledelse. Det
skyldtes 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 truffet
efter drøftelser mellem afdelingschefen for dataafdelingen og henholdsvis rigspolitichefen og
chefen for Rigspolitiets økonomi- og administrationsafdeling ikke var formaliserede.
Manglende skriftlige beslutningsgrundlag
80. POLSAG-projektet har internt i Rigspolitiet været karakteriseret ved manglende skriftlig
dokumentation, 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.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0037.png
30
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
81. Rigspolitiet har generelt produceret store mængder skriftligt materiale i projektforløbet, fx
i 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 da
Rigspolitiet besluttede at gå i forhandling med leverandøren, og da Rigspolitiet besluttede
at 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. Rigspolitiet
har oplyst, at det indledende leverandørvalg blev truffet ved en mundtlig forelæggelse for
rigspolitichefen.
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å skulle
håndtere en driftssituation på Bornholm med andre krav.
82. Rigspolitiet har oplyst, at alle væsentlige overordnede spørgsmål fra projektets start blev
forelagt 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øftelser
er foregået mundtligt i overensstemmelse med de samarbejdsprocedurer, der generelt var
gæ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 konsulenter
83. Bonnerup-rapporten anbefalede i 2001, at kunden ikke i for høj grad lader konsulenter
udø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 samlede
projektomkostninger 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.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0038.png
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
31
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 ved
at 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ærligt
leverandø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 og
administrativ støtte, ca. 37 % til projektledelse og ca. 2 % til juridisk bistand. Opgørelsen er
beregnet på baggrund af konsulentforbruget i 2010 og 2011. Rigspolitiet vurderer, at denne
fordeling 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 har
varetaget 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 af
eksterne 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øst
af 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 de
ikke 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økonomien
89. 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 er
modtaget.
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.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0039.png
32
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
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 i
Navision 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. Rigsrevisionen
har 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 styring
af 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 intern
tid 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ær
i forbindelse med implementeringen af projektet, hvor alle dele af politiet i sidste ende skul-
le have været inddraget i uddannelsesindsatsen.
B.
Rigspolitiets test af POLSAG før pilotdriften på Bornholm
92. Rigsrevisionens undersøgelse af testen af POLSAG har vist følgende:
Det var en fordel, at Rigspolitiet brugte pilotdriften til at få afklaret, om POLSAG var klar
til at blive brugt i de andre politikredse. Rigspolitiet udførte dog ikke en anvendelsestest
af POLSAG før pilotdriften på Bornholm. Det betød, at man ikke før pilotdriften systema-
tisk fandt de fejl, der ville vise sig, når systemet blev anvendt af rigtige brugere.
Rigspolitiet godkendte at gå i drift på Bornholm på baggrund af, at det samlede fejlniveau
var faldende. Forventningen om et fortsat fald viste sig ikke at holde stik, og POLSAG
blev taget i brug med et større antal fejl, end det var tilsigtet.
Systemtest og
kundetest
Testene af POLSAG
skal sikre, at leveran-
cen er funktionsdygtig,
dækker kravene og er
dokumenteret. Sy-
stemtesten er leveran-
dørens egen test af
det, der skal leveres,
mens kundetesten er
kundens test af det sy-
stem, der skal modta-
ges.
Test i 3 miljøer
93. 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, en
systemtest 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 var
problemer 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).
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0040.png
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
33
Rigspolitiets betingelser for at overtage POLSAG
95. Før pilotdriften på Bornholm skulle leverandøren bestå en overtagelsesprøve, jf. boks 7.
BOKS 7. OVERTAGELSESPRØVE
Overtagelsesprøven skulle gennemføres efter Rigspolitiets kundetest og lå forud for idriftsættelsen af
POLSAG. Ifølge kontrakten var formålet med prøven at gennemføre den formelle overtagelse af POL-
SAG, dvs. at Rigspolitiet overtog systemet fra leverandøren. Ved prøven skulle det konstateres, at
den aftalte funktionalitet og dokumentation var leveret, og at POLSAG kunne tages i brug. Ligeledes
skulle servicemål verificeres i det omfang, det var muligt, specielt skulle en svartidsprøve gennemfø-
res.
96. Leverandøren udskød den oprindeligt planlagte overtagelsesprøve i maj 2010, fordi der
var 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året
2010 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 givent
tidspunkt, der skulle bruges som udgangspunkt for at vurdere, om leverandøren levede op
til 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 fastfrosne
liste. 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 ville
tæ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øven
og 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, og
Rigspolitiet 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 fastfrosne
liste og med det samlede fejlniveau den 9. november 2010, hvor Rigspolitiet godkendte POL-
SAG.
Fejlkategori 1-4
Kategori 1 – kritiske
fejl. Væsentlig funktio-
nalitet fejler eller er ik-
ke tilgængelig.
Kategori 2 – større fejl.
Betydende funktionali-
tet fejler eller er ikke til-
gængelig.
Kategori 3 – mindre
fejl. Ikke kritisk for drif-
ten og skaber ikke væ-
sentlige hindringer for
brugerne.
Kategori 4 – uhensigts-
mæssigheder. Ikke kri-
tisk for driften og berø-
rer ikke eller kun i ringe
udstrækning brugerne.
En
testcase
er en
slags drejebog for en
test, der beskriver,
hvad testpersonen skal
gøre under testen og
forudsætningerne for
testen.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0041.png
34
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
Tabel 3. Acceptkriterier og fejl
(Antal)
Acceptkriterier
i kontrakten
Kategori 1-fejl (kritiske fejl)
Kategori 2-fejl (større fejl)
Kategori 3-fejl (mindre fejl)
Kategori 4-fejl (uhensigtsmæssigheder)
0
10
120
Ubegrænset antal
Fejl på den
fastfrosne liste
den 9. november 2010
0
10
84
Ubegrænset antal
Samlet fejlniveau
i POLSAG
den 9. november 2010
0
103
250
Ubegrænset antal
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år
var 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 tid
ville have et produktionsklart POLSAG. Imidlertid blev der opdaget nye fejl samtidig med, at
antallet 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 kan
få 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 specielle
omstændigheder og ikke indebar en særlig risiko for pilotdriften. Rigsrevisionens eksterne it-
ekspert har ud fra den fastfrosne fejlliste bekræftet denne vurdering.
Produktion
Man taler om produk-
tion, når et it-system
anvendes til at sagbe-
handle i den daglige
drift (producere sager).
Produktionsmiljøet er
det 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 kunne
Rigspolitiet 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 skulle
flyttes ud i et egentligt produktionsmiljø på Bornholm.
Testen af POLSAG omfattede ikke en anvendelsestest
102. POLSAG gennemgik flere typer test. Rigsrevisionen har ikke vurderet kvaliteten af de
gennemfø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.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0042.png
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
35
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 muligt
at 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, og
inden 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. Det
er Rigsrevisionens eksterne it-eksperts vurdering, at de mangeartede fejl, der opstod under
pilotdriften, 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ølgende
blev 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 at
komme i drift for at finde ud af, om kundetestene fungerede og fandt de fejl, der ville være i
drift. 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 brugerne
på Bornholm oplevede.
104. Rigspolitiet overvejede ved replanlægningen af projektet i 2009 at indskyde en pilottest
fø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 det
ikke var muligt at gennemføre en anvendelsestest. Dels fordi en anvendelsestest ikke indgik
i 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. Hvis
Rigspolitiet 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.
C.
Problemer og fejl under pilotdriften på Bornholm
106. Mange af de fejl, der prægede POLSAG, viste sig under pilotdriften på Bornholm, og
erfaringerne herfra indgik i vurderingen af POLSAGs fremtid. Rigsrevisionens undersøgel-
se af de fejl, der prægede POLSAG under pilotdriften på Bornholm og fejlenes konsekven-
ser, har vist følgende:
Rigspolitiet konstaterede, at der under pilotdriften var mange fejl, at der gik lang tid, in-
den fejlene blev rettet, og at fejlretningen affødte nye fejl eller ikke løste de konstatere-
de problemer.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0043.png
36
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
Fejlene havde mange forskellige kilder, og de udsprang af forhold hos både Rigspolitiet
og hos leverandøren.
Rigspolitiet prioriterede den pilotdrift, der efterfølgende skulle have været i gang i Midt-
og Vestjyllands politikreds, da Rigspolitiet skulle vælge, om leverandørens resurser skul-
le gå til at afhjælpe problemer på Bornholm eller til at forberede Midt- og Vestjylland.
Rigspolitiets uddannelse af brugerne på Bornholm var mangelfuld, og Rigspolitiet støtte-
de ikke brugerne til at forstå, hvordan det nye system skulle bruges. Det er Rigsrevisio-
nens opfattelse, at brugerne i vid udstrækning forventede et system, der kunne bruges i
dagligdagen, mens der reelt var tale om en anvendelsestest.
107. Rigspolitiet har peget på flere årsager til den problematiske pilotdrift, heriblandt mæng-
den af fejl i POLSAG, fejlretningen og uddannelsen af og støtten til de bornholmske betjen-
te. Rigsrevisionen gennemgår her årsager til den problematiske drift, som dækker forhold på
både kunde- og leverandørsiden.
Fejlniveau og fejlenes konsekvenser
108. Figur 4 viser udviklingen i fejlniveauet i POLSAG i perioden fra før den udskudte over-
tagelsesprøve i foråret 2010 til februar 2012.
Figur 4. Rigspolitiets opgørelse over fejl i POLSAG uden randsystemer i perioden marts 2010 -
februar 2012
(Antal)
800
700
600
500
400
300
200
100
0
10 dage efter fejllisten blev
fastfrosset
3 dage efter
start på pilotdrift
2010/2011
2011/2012
Kategori 1-fejl
Kategori 2-fejl
Kategori 3-fejl
Note: Niveauet af kategori 1-fejl har været så lavt (mellem 0 og 3), at det ikke kan ses af figuren. Tal-
lene bag grafen er månedlige opgørelser af antallet af fejl, der endnu ikke er færdigbehandlet.
Opgørelsen varierede efter, hvor mange fejl der blev lukket/åbnet.
Kilde: Rigspolitiet.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0044.png
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
37
Det fremgår af figur 4, at fejlniveauet faldt frem mod pilotdriften på Bornholm, der gik i gang
i december 2010, for derefter at stige igen. Det skyldtes bl.a., at der blev opdaget flere fejl, da
Rigspolitiet begyndte at teste yderligere, fordi udviklingsarbejdet ikke var afsluttet. Figuren
illustrerer kvaliteten af systemet ud fra en isoleret betragtning, nemlig omfanget af opgjorte
fejl. Figuren fortæller fx ikke noget om årsagerne til eller konsekvenserne af fejlene. Figuren
viser 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 de
værste børnesygdomme. En pilotdrift identificerer typisk nogle af de børnesygdomme, som
ethvert 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 viser
i figur 4. Efter 6 måneders pilotdrift konstaterede Rigspolitiet i juni 2011, at kvaliteten af den
version 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, at
Bornholms 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 ved
andre lignende it-projekter, men har kunnet konstatere, at både Rigspolitiet og leverandøren
har vurderet, at fejlenes konsekvenser var problematiske.
Rigsrevisionens eksterne it-ekspert har gennemgået Rigspolitiets fejllister. Gennemgangen
viste, at POLSAG på Bornholm var plaget af en kombination af forskellige fejl og problemer
på 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.
Fejlkilder
For at forstå de fejl,
der prægede POL-
SAG, kan det være
hensigtsmæssigt at
skelne mellem forskel-
lige fejlkilder:
• kravfejl (når kun-
dens krav fører til
en uhensigtsmæs-
sig løsning)
• fejl i software (kan
være funktionelle
fejl, småfejl, fx sta-
vefejl eller kvalitets-
fejl som dårlige
svartider, svær ved-
ligeholdelse og lav
brugervenlighed)
• installationsfejl (sy-
stemet er sat for-
kert op)
• manglende bruger-
uddannelse
• drifts- og support-
fejl.
BOKS 8. EKSEMPLER PÅ FEJL PÅ BORNHOLM I – DØGNRAPPORTEN
Det 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 sager
politiet har haft i det senest døgn, men kan også udtrækkes for længere perioder, som man prøvede
på 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 som
gav 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.
110. Ud over problemer med opsætningen af systemet, der i starten gav lange svartider,
skyldtes problemerne på Bornholm ifølge Rigspolitiet primært genereringen af Word-doku-
menter og fejl i skabeloner og dokumenter, jf. boks 8 og 9. Rigspolitiet har oplyst, at ca. halv-
delen af de fejl, som brugerne på Bornholm oplevede, var fejl i dokumenter.
111. Rigspolitiet har oplyst, at Rigspolitiet løbende reklamerede over fejl og mangler. Mod
slutningen af forløbet fremsendte Rigspolitiet en samlet reklamationsliste over fejl og mang-
ler ved systemet til leverandøren.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0045.png
38
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
Rigsrevisionens eksterne it-ekspert har gennemgået reklamationen. Gennemgangen viser,
at hovedparten af fejlene i reklamationslisten er softwarefejl i form af stavefejl, fejl i layout og
formatering, fx forkerte farver og forkert brug af kursiv. Der er 1-2 fejl af denne art pr. skærm-
billede. Rigspolitiet har bekræftet dette. Det er bl.a. udtryk for, at reklamationen også inde-
holder alle de kategori 4-fejl (fx stavefejl), som leverandøren ifølge kontrakten ikke skulle ret-
te.
BOKS 9. EKSEMPLER PÅ FEJL PÅ BORNHOLM II – MANGE STAVEFEJL I BREVSKABELONER
Mange 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 var
leverandø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 forskellige
dokumenter – 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 et
andet 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.
Det fremgår af reklamationen, at det var Rigspolitiets opfattelse, at selv om en stor del af de
enkelte fejl i reklamationen i sig selv ikke var væsentlige, udgjorde de samlet set væsentli-
ge mangler i systemet. Fejlene i skabeloner og dokumenter var forretningskritiske og betød,
at brugerne i tilfælde af fejl ikke kunne anvende de dokumenter, systemet genererede. Rigs-
politiet har fx oplyst, at brugerne ikke havde mulighed for at rette i dokumenterne og derfor
i nogle tilfælde – hvor fejlene i dokumentet forekom uacceptable – fravalgte det automatisk
genererede dokument og i stedet selv skrev det.
Rigspolitiets reklamation gengav også konklusionerne i de tekniske undersøgelser, der blev
gennemført ved det eksterne review i 2011.
BOKS 10. EKSEMPLER PÅ FEJL PÅ BORNHOLM III – LANGSOM LOGIN OG LÅSTE SAGER
På Bornholm tog det i starten meget lang tid at logge på. Årsagen var bl.a., at systemet var forkert
sat op. Når en bruger loggede på, prøvede systemet at identificere ham ved at spørge den række
af 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å adgang
til den, hvis en bruger havde åbnet sagen og ikke lukket den, inden brugeren gik hjem. Captia bruger
normalt "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.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0046.png
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
39
Fejl og langsom fejlretning
112. 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ør
brugernes arbejde, bliver rettet inden for rimelig tid.
113. Rigspolitiet og leverandøren har oplyst, at en for stor andel af de rettede fejl opstod
igen. Det betød, at fejl, der allerede én gang var registreret og forsøgt rettet, igen dukkede
op 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ød
det, 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, at
Rigspolitiet 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 Rigspolitiet
mulighed 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. Kategorierne
tog ifølge ministeriet fx ikke højde for, at en stavefejl, som ville være kategori 4-fejl, der ikke
skulle rettes, kunne være forretningskritisk. Ifølge kontrakten skulle leverandøren ikke rette
kategori 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 at
afhjæ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 mod
Rigspolitiets reklamation over systemet i november 2011.
Uddannelse og støtte af brugerne på Bornholm
117. Det er Rigsrevisionens opfattelse, at en tilstrækkelig forberedelse og støtte af brugerne
er afgørende for en vellykket pilotdrift.
118. Rigspolitiet forberedte forud for pilotdriften på Bornholm brugerne på at tage POLSAG
i brug ved hjælp af en uddannelsesindsats, der kombinerede kursusdage, projekter i kredsen
og et rejsehold kaldet det Nationale UddannelsesTeam, der bistod kredsen.
119. Efter et halvt års pilotdrift konstaterede Rigspolitiet, at den gennemførte uddannelse af
brugerne på Bornholm havde været mangelfuld. Lange sagsbehandlingstider på Bornholm
skyldtes 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 om
de nye arbejdsprocesser i POLSAG. Derfor var det nødvendigt at genuddanne brugerne og
gennemgå de nye arbejdsprocesser, før POLSAG kunne fungere i daglig brug.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0047.png
40
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
BOKS 11. EKSEMPLER PÅ PROBLEMER PÅ BORNHOLM IV – USIKKERHED OM BRUGEN AF
SYSTEMET
Selv om POLSAG ifølge 1:1-kravet skulle indeholde samme funktionalitet som POLSAS, indebar POL-
SAG en ændring af arbejdsprocesserne. Det betød, at der under pilotdriften opstod tvivl om de nye
arbejdsgange. Fx blev betjentene i tvivl om, hvordan de skulle godkende en nedsat bøde. Tidligere
var der et bødeforlæg, som en person godkendte ved at underskrive et stykke papir. Det var ikke be-
skrevet for brugerne, hvordan det skulle foregå elektronisk. Der opstod også tvivl om, hvem der skul-
le sende en afgørelsesudskrift til Kriminalregistret, og hvornår det skulle ske. Tidligere fik anklage-
myndigheden sagen i fysisk form, og modtageren kunne dermed se, at afgørelsesudskriften skulle
sendes til Kriminalregistret.
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 fra
Bornholm til at justere uddannelsesindsatsen for efterfølgende kredse.
Rigspolitiet havde over 1 år efter, pilotdriften var startet, ikke i tilstrækkelig grad beskrevet de
nye 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 hensyn
til både funktionalitet og hastighed. Bornholms politikreds gik over til at bruge POLSAG
100 %, 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.
D.
Rigspolitiets håndtering af risikoen for dårlige svartider
121. Svartider var et af de centrale risikoområder i POLSAG. Rigsrevisionens undersøgelse
af 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 arbejdsgruppe
til 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 kort
fø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 eller
udvide leverandørens målinger af svartider ifølge kontrakten.
POLSAGs svartider er aldrig endeligt dokumenteret.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0048.png
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
41
Rigspolitiets håndtering af POLSAGs svartider
122. 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øren
skulle 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 svartiderne
skulle måles.
Allerede i 2008 nedsatte Rigspolitiet og leverandøren en arbejdsgruppe med særskilt fokus
på 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 POLSAG
blev 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 sent
i 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 udelukkende
kom 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 samlede
svartider eller fremrykke leverandørens måling af svartiderne.
125. Det eksterne review, som Rigspolitiet fik gennemført i 2009, identificerede bl.a. dårlige
svartider 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å reviewets
konklusioner 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 dokumentere
svartider, 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 en
svartidsprø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 politikreds
skulle leverandøren leve op til de garanterede svartider i kontrakten.
Den 22. november 2010 bestod leverandøren en svartidsprøve med dobbelte svartidskrav
forud for pilotdriften på Bornholm i december 2010.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0049.png
42
RIGSPOLITIETS STYRING AF POLSAG-PROJEKTET
I december 2011 udførte leverandøren den endelige svartidsmåling, der skulle bestås inden
den næste pilotdrift. Rigspolitiet og leverandøren nåede aldrig til enighed om, hvorvidt leve-
randøren havde bestået og opnået de garanterede svartider. Det er fortsat uklart, hvad de
endelige svartider ville være, når tiderne fra randsystemerne blev inkluderet.
127. Justitsministeriet har oplyst, at det samlede billede af forløbet omkring svartidsmålinger-
ne er uklart, og at det var vanskeligt for Rigspolitiet at få et præcist billede af situationen og
leverandørens arbejde med svartider.
128. Risikoen for, at POLSAG ville have utilfredsstillende samlede svartider, var ét af de ele-
menter, der indgik i grundlaget for at lukke POLSAG.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0050.png
GRUNDLAGET FOR AT LUKKE POLSAG
43
VI. Grundlaget 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 Justitsministeriets
grundlag blev udarbejdet med deltagelse af eksterne repræsentanter i et setup, der
ligner 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å usikkerheden
og lagde vægt på, at svartiderne endnu ikke var tilfredsstillende dokumenteret.
129. I dette kapitel gennemgår vi grundlaget for at lukke POLSAG. Vi har ikke efterprøvet det
samlede grundlag eller vurderet, om det var den rigtige beslutning, men har undersøgt, om
Justitsministeriet inddrog relevante risici i vurderingen af POLSAGs fremtid.
A.
Elementer i indstillingen om at lukke POLSAG
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 af
et samlet risikobillede, at POLSAG burde lukkes. På det tidspunkt var systemet efter et
langt og dyrt udviklingsforløb næsten færdigudviklet.
De elementer, der indgik i udvalgets vurdering, var relevante for at vurdere POLSAGs
fremtid. De omfattede tekniske og leverandørmæssige risici, erfaringerne fra pilotdriften
på 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.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0051.png
44
GRUNDLAGET FOR AT LUKKE POLSAG
Udvalget for en undersøgelse af POLSAG
131. Justitsministeriet baserede sin indstilling til Finansudvalget om at lukke POLSAG på et
arbejde i et embedsmandsudvalg med deltagelse af en ekstern formand og repræsentanter
fra 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 at
lukke projektet.
Udvalgets arbejde blev gennemført på en måde, der ligner den måde, Statens IT-projektråd
arbejder på. Det repræsenterer i dag bedste praksis for at vurdere it-projekter i staten.
Risikoområder i anbefalingen om at lukke POLSAG
133. Justitsministeriet baserede sin indstilling til Finansudvalget om at lukke POLSAG på en
enig 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 POLSAG
Områder
Tekniske risici
Leverandørmæssige risici
Udvalgets konklusioner
POLSAGs 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 var
præget af mange fejl.
Det ville kræve en meget stor ændring i politiets arbejdsmetode og omfattende
forandringsledelse 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 ikke
understøttede effektivisering af politiets arbejdsprocesser og digital integration med
andre myndigheder uden for politiet.
Det ville være både tids- og resursekrævende at forsøge at genoprette POLSAG
og 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 muligheder
for at effektivisere politiets arbejdsgange med udgangspunkt i systemet og begræn-
sede gevinster i forhold til omkostningerne.
Erfaringerne fra pilotdriften
på Bornholm
Implementeringsrisici
Manglende fremtidssikring
Utilfredsstillende business case
Kilde: Rigsrevisionens omskrivning af konklusionerne i ”Review af POLSAG – afrapportering fra styregruppen”, Udvalget
for en undersøgelse af POLSAG (2011) og Justitsministeriets fortrolige Akt G 23/2 2012.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0052.png
GRUNDLAGET FOR AT LUKKE POLSAG
45
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 Rigspolitiets
erfaringer på Bornholm.
Tekniske undersøgelser af POLSAG
135. Som en del af det eksterne review i 2011 hyrede Rigspolitiet eksterne konsulenter til
bl.a. at gennemføre tekniske undersøgelser af POLSAG. Formålet var at give svar på, om
POLSAG 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 drages
ud 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 at
vurdere 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 af
POLSAGs performance.
It-miljøer
er den hard-
ware og infrastruktur,
softwaren kører på, og
de systemer, der bru-
ges. Til POLSAG-ap-
plikationen var der en
række forskellige mil-
jøer.
Uddannelsesmiljøet,
der blev brugt til at ud-
danne brugerne.
Forskellige
testmiljøer,
som henholdsvis Rigs-
politiet og leverandø-
ren brugte til at teste
systemet.
Produktionsmiljøet,
som var det miljø, bru-
gerne på Bornholm an-
vendte i drift.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0053.png
46
GRUNDLAGET FOR AT LUKKE POLSAG
BOKS 12. DE TEKNISKE UNDERSØGELSER
Eksterne konsulenter undersøgte i 2011 POLSAGs svartider. Resultaterne dokumenterede de i en
rapport kaldet et performance review. Hovedkonklusion viste nogle alvorlige problemer med POLSAGs
potentielle svartid.
Rigsrevisionens eksterne it-ekspert har gennemgået nogle af forudsætningerne og observationerne
i performance reviewet.
For at dække alle politikredses behov skulle POLSAGs web-servere ifølge konsulenternes målinger
behandle 2.187 web-requests pr. sekund. Et web-request er en forespørgsel efter et ikon, et stykke
tekst eller data over nettet. Set med teknikerens øjne er det et meget stort tal, som ville kræve rigtig
mange 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 at
hå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 og
var i gennemsnit ca. 200 requests pr. brugertransaktion. Med 11 transaktioner pr. sekund bliver det
de 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 skal
hentes 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 sat
op 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.
138. Konsulentrapporten blev i den afsluttende fase omarbejdet og suppleret med en række
forbehold og tilføjelser. Konsulenterne anførte bl.a., at nye oplysninger indikerede, at der var
sket en væsentlig forbedring i performance, men at der fortsat var usikkerheder om leveran-
dørens resultater. Senere målinger i produktionsmiljøet havde vist væsentlige forbedringer,
men konsulenterne havde ikke mulighed for at kontrollere oplysningerne.
Det er aldrig endeligt afklaret, om POLSAG ville have haft tilfredsstillende svartider.
139. Udvalget tog i den samlede vurdering af risikoen for, at POLSAG ville have utilfredsstil-
lende svartider, højde for, at der var usikkerhed om konsekvenserne af performance review-
ets resultater.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0054.png
GRUNDLAGET FOR AT LUKKE POLSAG
47
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. Det
skyldtes, at kravene til svartider i kontrakten kun gjaldt selve POLSAG og ikke de tilstøden-
de randsystemer, jf. pkt. 71-72.
Leverandørmæssige risici
140. 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øren
ikke 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 mellem
hoved- og underleverandør ikke fungerede tilfredsstillende. Det medførte ifølge udvalget en
væsentlig risiko for uforudsete omkostninger, forsinkelser og mangelfulde leverancer.
Manglende fremtidssikring
141. 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 som
et forældet system.
Business case for POLSAG
142. Som en del af det eksterne review i 2011 kortlagde konsulenterne POLSAG-projektets
samlede 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 ikke
sammenlignes 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 POLSAG
ikke var attraktiv ud fra en rent økonomisk betragtning, så ville vurderingen af, hvor attraktiv
POLSAG samlet set ville være for politiet også afhænge af de kvalitetsmæssige fordele ved
systemet.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0055.png
48
GRUNDLAGET FOR AT LUKKE POLSAG
Endvidere vurderede konsulenterne, at der – afhængigt af de tekniske risici og behovet for
at 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 det
første som det mest og det sidste som det mindst omkostningstunge scenarie. Scenarierne
blev bl.a. opstillet på baggrund af tekniske undersøgelser af POLSAGs kodekvalitet, der især
blev 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-projekter
at opstille en business case.
Rigsrevisionen, den 13. marts 2013
Lone Strøm
/Lene Schmidt
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0056.png
KRONOLOGISK OVERSIGT OVER POLSAG-PROJEKTET
49
Bilag 1. Kronologisk oversigt over POLSAG-projektet
2005
Januar
September
Oktober
2007
April
Maj
2008
April
November
Rigspolitiet og leverandøren nedsatte en arbejdsgruppe med fokus på svartider.
Rigspolitiet og leverandøren aftalte, at POLSAG-projektet skulle replanlægges på grund af forsinkelse i
projektet og behov for ny/ændret funktionalitet.
Rigspolitiet og leverandøren underskrev hovedkontrakten om POLSAG.
Finansudvalg tiltrådte aktstykke nr. 119 af 27. april 2007 om POLSAG.
Finansudvalget tiltrådte aktstykke nr. 74 af 4. januar 2005 om igangsættelse af et udviklings- og moder-
niseringsprogram for politiets it-systemer (POLSAG var et af flere projekter).
Konsulentundersøgelse af brugen af FESD-rammeaftalen og 2 FESD-leverandører.
Rigspolitiet besluttede at gå i forhandling med den valgte leverandør af POLSAG.
2009
August
Oktober
2010
Marts
April
September
Oktober
November
November
December
December
2011
April
Maj
Juli
August
Oktober
December
Udvalget for en undersøgelse af POLSAG blev nedsat. Dermed gik det andet større, eksterne review af
POLSAG 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 og
behov for yderligere tilretninger af POLSAG.
Rigspolitiet igangsatte yderligere tekniske undersøgelser af POLSAG på grund af foreløbige resultater
fra 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 fra
reviewet.
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, at
leverandø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).
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0057.png
50
KRONOLOGISK OVERSIGT OVER POLSAG-PROJEKTET
2012
Januar
Januar
Februar
Marts
Juni
Juni
Resultaterne af de tekniske undersøgelser forelå.
Udvalget for den eksterne konsulentundersøgelse afrapporterede undersøgelsen.
Justitsministeriet forelagde fortroligt aktstykke G om POLSAG.
Bornholms politikreds gik fra POLSAG tilbage til POLSAS.
Rigspolitiet og leverandøren indgik forlig.
Justitsministeriet orienterede Finansudvalget om resultatet af forliget mellem Rigspolitiet og leverandøren.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0058.png
FORELÆGGELSER FOR FINANSMINISTERIET
51
Bilag 2. Forelæggelser for Finansudvalget
Akt nr.
57
Ministeriets ansøgningsdato
(Tiltrædelsesdato)
30. november 2004
(8/12 2004)
4. januar 2005
(19/1 2005)
Bevilling
153 mio. kr.
(172 mio. kr. i 2010-priser)
153 mio. kr.
(173 mio. kr. i 2010-priser)
Indhold
Igangsættelse af et samlet udviklings- og moder-
niseringsprogram for politiets it-systemer. (Taget
tilbage 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 et
nyt sagsbehandlingssystem og første fase af
en 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 af
350 mio. kr. til straksafskrivning af POLSAG og
37 mio. kr. i bevillingsbortfald.
Orientering om resultatet af forhandlingerne med
leverandøren og det indgåede forlig.
74
106
119
6. februar 2006
(Til efterretning)
24. april 2007
(16/5 2007)
30. maj 2008
(12/6 2008)
16. juni 2010
(1/9 2010)
30. november 2010
(16/12 2010)
1. februar 2012
(23/2 2012)
-
221 mio. kr.
(236 mio. kr. i 2010-priser)
-
425,2 mio. kr.
(422 mio. kr. i 2010-priser)
405,5 mio. kr.
(405,5 mio. kr. i 2010-
priser)
313 mio. kr. eller
350 mio. kr. ÷ 37 mio. kr.
157
157
66
G
-
25. juni 2012
-
-
Note: Godkendte bevillingsanmodninger er fremhævet.
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0059.png
52
ORDLISTE
Bilag 3. Ordliste
Anvendelsestest
Systemtest i de rigtige omgivelser, med rigtige data og brugere, men uden at der er tale
om 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 man
det 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 requests
til 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 med
et projekt.
Mellemlager for data, så data ikke skal hentes fra et fjernt sted hver gang. Når et system
cacher, antager det, at data, der lige er blevet brugt, snart skal bruges igen og derfor
skal 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 den
på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. have
indflydelse 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 kravene
designes en løsning.
Rigspolitiets egen test af, om POLSAG-systemet fungerede og dækkede kravene i krav-
specifikationen og Rigspolitiets faktiske behov.
Applikation
Bonnerup-rapporten
Brugertransaktion
Business case
Cachen/caching
Captia
Costbenefit-analyse
Driftsprøve
Effektiviseringsprojekt
ESDH
FESD
Hardware
Infrastrukturprojekt
It-miljø
Kodekvalitet
Kravspecifikation
Kundetest
Statsrevisorerne beretning SB9/2012 - Bilag 1: Beretning om politiets it-system POLSAG
1229190_0060.png
ORDLISTE
53
Løsningsbeskrivelse
Overtagelsesprøve
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 dokumentation
er 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-system
udvikles 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 kan
hentes 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 synligt
for 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, som
er udarbejdet forud for systemdesigndokumentationen.
En database består af tabeller. I POLSAG kan en tabel fx være en liste af personer, en
liste 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 ord
for performance.
Performance
Randsystem
Request
Skalerbarhed
Software
Specialudvikling
SQL-kald
Standardfunktionalitet
Standardsystem
Svartid
Svartidskrav
Svartidsprøve
Systemdesigndokumentation
Tabel
Web-request
Web-server
Ydeevne