1. No category

Institut for Marketing og Organisation
POLSAG
-A failed project
Forfatter: Daniel Vad Jørgensen
Maj 2015
Vejleder: Per Svejvig
Anslag u. mellemrum: 109.938
Side 0 af 91
1
ABSTRACT................................................................................................................................................................. 2
2
INDLEDNING ............................................................................................................................................................. 4
3
KILDEKRITIK .............................................................................................................................................................. 6
3.1
3.2
EMPIRISKE KILDER ............................................................................................................................................................. 6
TEORETISKE KILDER ........................................................................................................................................................... 7
4
METODE ................................................................................................................................................................... 8
5
DEN ANVENDTE TEORI ............................................................................................................................................ 11
5.1
5.2
5.3
6
BONNERUP RAPPORTEN ................................................................................................................................................... 12
PROFESSIONALISERING AF ARBEJDET MED IT-PROJEKTER I STATEN ............................................................................................ 13
FAKTORER SOM PÅVIRKER SYSTEMUDVIKLINGSPROJEKTERS UDFALD .......................................................................................... 16
POLSAG OG FORLØBET ........................................................................................................................................... 22
6.1
6.2
6.3
GENERELT OM POLSAG .................................................................................................................................................. 22
FORLØBET ..................................................................................................................................................................... 22
GENERELT OM FORLØBET ................................................................................................................................................. 27
7
UDLEDNING AF PROBLEMSTILLINGERNE ................................................................................................................ 28
8
ANALYSE AF POLSAG .............................................................................................................................................. 29
8.2
8.3
8.4
BONNERUP RAPPORTEN ................................................................................................................................................... 42
PROFESSIONALISERING AF ARBEJDET MED IT-PROJEKTER I STATEN ............................................................................................ 44
DELKONKLUSION ............................................................................................................................................................ 46
9
FORSLAG TIL ÆNDRINGER ...................................................................................................................................... 48
10
VURDERING ............................................................................................................................................................ 50
11
KONKLUSION .......................................................................................................................................................... 52
12
KILDELISTE .............................................................................................................................................................. 54
13
APPENDIKS ............................................................................................................................................................. 58
13.1
13.2
13.3
BILAG 1: AFSLAG PÅ ANMODNING OM INTERVIEW............................................................................................................ 58
BILAG 2: SPØRGSMÅL TIL POLITIET ................................................................................................................................ 58
BILAG 3: KODNING OG SPORING AF BELÆG ..................................................................................................................... 60
Side 1 af 91
1 Abstract
This thesis is treating the matter of the it-project POLSAG. The project ended, before it where fully implemented. POLSAG where not the first failed project started in a state institution. It is therefore highly relevant, to focus on the project and the reasons behind the failure. The thesis is
describing the process and the story behind POLSAG, and trying to analyses why the project ended the way it did. Based on the analyze of POLSAG, there is made recommendations on how to
enhance chances of making a successful project, or what should have been done different in the
POLSAG project.
The project is analyzed in the perspective of advices, which were made and published with the
purpose to help projects like POLSAG. In the analyze there is also used some more general theory
to cover the mere general aspects of software system developments, and the relevant factors. Advices that are published after the start of the project are also analyzed, to decide if they would
have done a different in the project.
The project faced a lot of challenges and problems. Some of the most distinct problems were the
long response time in the system, and end-to-end response times. The project did also face delays
recording to the original schedule. Not only in time but also in costing the project exceeded the
intended. The system got only implemented in one police districts and that with a lot of problems
and unhappy policemen as a result. Even though the bad pilot, the extended cost, and the hold-up
on the project were the explanation on the canceling of the project, it was not the reason.
The reason of the failed project should be found in the project itself. The thesis shows that, there
were made multiple bad choices in the process of the project. But also bad circumstances had a
negative impact on the project. Some of the most remarkable reasons to the failure were the lack
of qualified employees at the project. The employees needed specific qualities to deal with the
high complexity of the system. A complexity that was increased because of the large amount of
coding needed to make the chosen standard system fulfill the requirements. Requirements that
partly were based on the former system POLSAS. The determination of the requirements wasn’t
made based on what they wanted to achieve with the new system, but to make sure of could do
the same as the previous one. Some of the other significant problems, were shown to be the lack
of management, and the management of the systems lacked roots in the management of the poSide 2 af 91
lice, which made it hard to make decision influencing anything other than the system. Some of the
other problems showed to be the relationship between the police and the external agents.
At the end of the thesis the focus is on the possible solutions. Primarily on hos the fiasco could
have been avoided, and secondary on how future project in state institutions could benefit from
POLSAG. Some of the solutions to POLSAGs struggle are to make a lot less requirements. In that
way they don’t overcomplicate the system. One of the more important solutions or advises, is to
make a meticulous business case for the project, that including setting some prober goals. With
the business case a risk assessment are also more valuable. It can not only be used to foresee
problems, but also be used to evaluate the project, and use it as a tool to cancel shot down the
project if necessary. At the end of the thesis, is the realism of the proposed solutions and advices
evaluated. That is done in a way were the fact that prior advices is not followed is taken into consideration, and with knowledge of the complexity with the high number of factors effecting a single project.
Side 3 af 91
2 Indledning
Blyanten virker altid. Den er pålidelig, simpel og funktionel. Der er vigtige egenskaber for et redskab, men egenskaber de færreste IT-systemer har fra fødslen. Staten har igennem en årrække
haft et sort antal fejlslagne projekter, hvoraf mange af dem som har fået meget medieomtale og
har lidt under budgetoverskridelser. Gentagene gange er der blevet sat fokus på offentlige itprojekter, og de fejl som der er blevet begået under gennemførelsen af projekterne. Selvom der
er blevet kigget på de offentlige it-projektor, er det stadig interessant og nødvendigt at kigge på
disse. De mange forskellige fejlslagne offentlige projekter kan være antydningen af en tendens,
der skyldes nogen underliggende faktorer.
Eftersom der stadig opstår problemer selv efter flere års erfaring og offentliggjorte rapporter, vil
der derfor stadig være mulighed for at lære endnu mere om projekterne. Herunder de mekanismer der spiller ind i gennemførslen af projektet, og det endelige udfald. Selvom der tidligere er
udarbejdet rapporter, som har givet råd til hvad der skal gøres for at undgå problemer med nye
offentlige it-projekter, er det ikke nødvendigvis betydende at rådene er blevet fulgt. Derfor er det
også relevant at se på om rådende er blevet fulgt, og i hvilket omfang det har haft en positiv eller
negativ effekt. Dette gøres som udgangspunkt ved brug af den såkaldte Bonnerup rapport.
Et af de projekter der har fået stor mediebevågenhed, og har vist sig at ende ud som en fiasko har
været POLSAG. Rigspolitiets nye sags- og dokumenthåndteringssystem der skulle overtage for
det ældre system POLSAS. Projektet endte med store budgetoverskridelser og blev aldrig fuldt ud
implementeret. I stedet for blev det udskældt i medierne, og i den eneste politikreds hvori det
blev implementeret, kritiseret af brugerne. Et af projekt af denne størrelse er derfor relevant at
se nærmere på, for at belyse nogen af de problemstillinger, der har haft betydning for projektets
udfald.
2.1.1 Problemstilling
Problemstilling er derfor at, POLSAG blev en fiasko på trods af at der burde kunne have gjort
brug af erfaringer med tidligere projekter. Derfor er det relevant at se på i hvilken grad at det
havde været en mulighed at have undgået den fiasko projektet endte med at blive, såfremt der
var blevet gjort brug af tilrådehavende anbefalinger.
Side 4 af 91
2.1.1.1 Problemformulering
Hvorfor opstod der problemer med gennemførelsen af POLSAG, og kan de undgås ved
kommende it-projekter?
Hvad var POLSAG og forløbet herom?
Hvad havde betydning for POLSAGS manglende succes?
Hvad skulle være gjort for at have undgået problemerne, og hvordan kan de undgås ved kommende projekter?
Selvom POLSAG er blevet gennemført i en stor organisationen, og med muligheder for at tilføre
de nødvendige ressourcer, er det derfor ikke sikkert at anbefalingerne og best practice er blevet
fulgt.
Ved at analysere projektet bliver det muligt se på de faktorer der har haft indflydelse på projektets gennemførelse og resultat. Samtidig vil det være mere relevant at vurdere i hvilket omfang at
rådene er blevet fulgt, og en efterlevelse ville have medført en forbedret mulighed for succes.
Samtidig er det også relevant at se på i hvilket omfang at de råd som er kommet til efter starten
på POLSAG, kunne have haft en effekt på projektet såfremt at de var kendte inden projekt og var
blevet efterlevet.
2.1.2 Afgrænsning
Der er flere aspekter som ikke vil blive dækket i rapporten. Et af de steder hvor POLSAG er blevet
kritiseret har været kodens kvalitet. Selve kodens kvalitet vil ikke blive behandlet, grundet manglende adgang til koden, samt at årsagen til den udformning af den dårlige kode er mere interessant. Tilgængeligheden af kilder sætter en naturlig begrænsningen i hvad det er muligt at
behandle analytisk. Dette betyder at analysen og rapporten vil fokusere på de faktorer og problemstillinger, som har været muligt at finde belæg for. Herunder er der flere af de interne og
mere uformelle faktorer, som ikke er behandles i det omfang som ellers havde været naturligt og
oplagt. Imedens vil fokus være på at skabe et overblik over de forskellige faktorer, og disses indbyrdes forhold, i stedet for en enkelt faktors betydning.
Side 5 af 91
2.1.3 Opbygning
Selve rapporten er opbygget således at der startes med at skabe det nødvendige kendskab til den
teori der vil blive benyttet. Dette gøres for at sætte de teoretiske rammer, og vise i hvilken kontekst den senere beskrivelse og redegørelse af POLSAG casen skal sættes i. Efter redegørelsen af
POLSAG, udledes der de problemstillinger, som senere vil blive analyseret. Således er det muligt
at finde frem til årsagen til problemerne og i hvilket omfang de har kunnet været undgået. Efter
analysen vil der blive udarbejdet forslag til ændringer, som har til formål at imødekomme nogen
af de problemer som analysen har fundet frem til. Disse løsningsforlag bliver vurderet sammen
med de problemstillinger som er udledt. Heraf bliver brugbarheden af forslagene vurderet. Det
hele bliver samlet i en konklusion, hvorefter der vil blive reflekteret over hele rapporten, og de
perspektiver som gør sig gældende.
3 Kildekritik
Kilderne er en væsentlig del af rapporten, og derfor er det også vigtigt at kildernes troværdighed
samt brugbarhed bliver taget i betragtning og behandlet kritisk. De empiriske kilder skal vurderes ud fra deres troværdighed og vinkling. Samtidig skal de teoretiske kilder også vurderes i forhold til i hvilken omfang de kan bruges som teoristik grundlag, og i hvilken omfang de passer til
empirien.
3.1 Empiriske kilder
Informationssøgningen har været begrænset grundet emnets karakter. Det har ikke været muligt
at få adgang til dele af det materiale der har lagt til grund for projektet, eller få adgang til at interviewe relevante personer. Hvilket er en beslutning som er taget fra politiets ledelse(bilag 1). Derfor består det empiriske grundlag altovervejende af artikler, aktstykker og offentliggjorte
rapporter. Som udgangspunktet har artiklerne været vinklet negativt i forhold til projektet, og
det har dermed været de negative aspekter der er blevet ført frem til offentligheden. Dette kan
skylde journalistiske valg, samt projektets faktiske beskaffenhed. Der skal tages forbehold for
troværdigheden af kilderne, da det er sekundære eller tertiære kilder. Der er derfor taget højde
for dette i måden hvorpå kilderne er blevet anvendt.
Side 6 af 91
I forhold til de aktstykker der er blevet brugt, er de fremsat for folketinget, og derfor må der antages en større troværdighed. Samtidig skal der tages forbehold for at aktstykkerne er blevet
fremlagt med formål at få dem godkendt. Derfor kan der være en tilskyndelse til at fremhæve de
positive aspekter. Herunder skal det bemærkes at der som udgangspunkt blev fremlagt et aktstykke om året, hvilket ved en enkelt lejlighed blev afveget fra. Dette i samme periode at der for
alvor opstod problemer med projektet.
De eksterne rapporter der er blevet brugt i rapporten er fremkommet efter tidligere søgte aktindsigter. Rapporter er udarbejdet af eksterne konsulenter, der har haft adgang til medarbejder
og interne papirer. Derfor er de brugt som kilde, og er tillagt stor troværdighed.
I forhold til det empiriske materiale der har været til rådighed, har det sat begrænsninger forhold
til dybden af de informationer der har vært til rådighed. Det har derfor sat naturlige begrænsninger for dens samlede analyse og den senere konklusion.
3.2 Teoretiske kilder
De teoretiske kilder består i stort omfang af rapporter. Herunder rapporter der målrettet er
kommet med forslag til offentlige projekter. Rapporterne er fremsat af teknologirådet og finansministeriet. I forhold til anbefalingernes korrekthed og brugbarhed er det altid muligt at diskutere disse. Bonneruprapporten er dog udarbejdet af det der i rapporten bliver beskrevet tværfaglig
arbejdsgruppe med særlig indsigt i området. (Bonnerup et al. 2001). Det kan forsvares at bruge
rapporten da den 10 år efter bliver nævnt i finansministeriets rapport, og derfor må have haft betydning for den mellemlæggende periode, og dermed også POLSAG. I forhold til finansministeriets rapport, er den udgivet med støtte fra staten, og i et betydende ministerium. Derfor er
rådende relevante for et offentligt projekt som POLSAG. Selvom rapporten er udgivet efter starten på POLSAG, er det stadig relevant at sætte den i forhold til POLSAG, men i retrospekt perspektivet. I forhold til finansministeriets rapport, kan det kritiseres at rapporten, bygger på flere
tidligere fejlslagne projekter, og herunder POLSAG. Derfor vil der være sammenfald i de anbefalinger der bleiver fremsat i rapporten, og POLSAG. Også her kan rådenes korrekthed og brugbarhed diskuteres, men rådende er grundet rapportens forfattere og udgivere relevant under alle
omstændigheder.
Side 7 af 91
Den teoretiske kilde Factors that affect software systems development (McLeod, MacDonell 2011),
er en sammenkobling af flere tidligere undersøgelser. Den er derfor brugt for at komme bredt
omkring projektet. Derfor er kilden blevet brugt, da det empiriske materiale ikke har kunnet
danne grundlag for en dybere analyse inden for et færre antal faktorer. Derfor er der fokuseret på
at lave en mere bred beskrivelse og analyse af projektet. Dette gøres med formål at belyse de interne sammenhænge imellem faktorerne, og i forhold til råd som er tilpasset det offentlige. Kilden er udgivet i 2011 og har en impact score på 4,529 i det pågældende år, hvilket er
tilfredsstillende i forhold til opgavens udformning, og den rolle kilden udfylder i rapporten.
4 Metode
Igennem en klar fastsat metode, bliver det muligt at strukturere arbejdet med rapporten. Ligeledes muliggør det også senere gentagelse af rapporten indhold, samt at det giver en åbenhed omkring fremgangsmåden.
4.1.1 Videnskabeligt udgangspunkt
I rapporten vil der blive taget udgangspunkt i en tilgang hvor der ikke nødvendigvis findes en endegyldig sandhed, omkring svarene på problemstillingerne. I stedet bliver der taget udgangspunkt i at det behandlede område er yderst kompleks og de faktorer der bruges eksisterer i kraft
af den måde hvorpå de defineres, beskrives og opleves i en samfundsmæssigsammenhæng. Der
skabes en høj kompleksitet, i kraft af de mange faktorer der er med til at påvirke den undersøgte
case. Faktorerne påvirker således både casen direkte, men også indirekte igennem påvirkning af
faktorerne indbyrdes. Det unikke sammenspil af faktorer for en enkelt case, betyder at enkelte
konklusioner ikke nødvendigvis kan overføres til andre cases. Dette betyder ikke at, der ikke kan
findes faktorer eller påvirkninger der har en så stor påvirkning, eller universalhed at de kan
overføres til andre cases end den behandlede. Denne skelnen skal foretages kritisk, men også på
en måde hvorpå der er fokus på at kunne øge konklusionernes brugbarhed fremover. Der gøres
derfor også brug af en pragmatisk tilgang, hvor der er fokus på at finde frem til faktiske løsninger
og konklusioner, i stedet for at fastholde en fokuseret teoretisk tilgang. Fokus vil blive lagt på selve casen, og lade den diktere brugen af teorien, i stedet for en ukritisk brug af teorien.
Side 8 af 91
Det videnskabelige paradigme læner sig derfor mest op af socialkonstruktivismen (Bryman, Bell
2011). Hvor fokus er på at finde frem til forklaringer på det udfald som projektet har haft, og sætte den brugte teori i kontekst. Samtidig er det også et paradigme, der passer bedst til den kvalitative empiri som har været til rådighed.
4.1.2 Undersøgelsesdesign
For at løse problemstillingen som er opført i problemformuleringen, vil der som udgangspunkt
både foregå deduktiv og induktiv behandling casen.(Eriksson, Kovalainen 2008) Den induktive
tilgang vil komme til udtryk ved en informationsindsamling med fokus på POLSAG og den empiri
som vil være muligt at komme i besiddelse af. Hvorimod at den deduktive tilgang vil komme til
udtryk i form af, at konklusioner fundet i teorien, vil blive overført på casen.
Det vil blive udført som et intensiv case studie med udelukkende en enkelt case i form af POLSAG.
Med et intensiv casestudie vil der alene være fokus på POLSAG, og der vil som udgangspunkt ikke
være fokus på at resultaterne vil kunne generaliseres, således de også vil være gyldige for andre
projekter. Generaliseringen vil i stedet blive behandlet i vurderingen af de fremkomne løsningsforslag. Her vil der også blive vurderet i hvilken grad det er muligt at overføre løsningsforslagene
til kommende statslige it-projekter, samt om de ville have haft en positiv effekt på POLSAG. Ligeledes vil realismen i forslagene blive vurderet.
Der vil blive lagt vægt på at kunne gøre brug af et dynamisk design hvor der vil være fokus på
processen omkring POLSAG(Eriksson, Kovalainen 2008). Ligeledes vil designet åbne op for en
iterativ proces hvor der vil blive vekslet imellem afdækning af teori og empiri. Efterhånden som
teorien vil blive afdækket vil det give anledning til at rette fokus mod andre dele af empirien, ligesom efterhånden som empirien vil blive afdækket, vil dette også give anledning til at tage ny
teori i brug. På denne måde bliver det sikret at alle de mest relevante områder bliver dækket, taget betragtning og senere analyseret, og vurderet.
Med udgangspunkt i en praktisk case, og rigtige problemstillinger vil fremgangsmåden have en
problemorienteret indgangsvinkel. Med en problemorienteret indgangsvinkel vil der også blive
brugt en normativ tilgang. Dette vil vise sig ved at POLSAG og dets problemer vil blive sammen-
Side 9 af 91
holdt med de best practice metoder der findes. Ligeledes er et muligt at der bliver fundet frem til
mangler i de best practice metoder der findes.
4.1.3 Informationssøgning
Informationssøgningen vil finde sted for at danne sig et overblik over POLSAG. Igennem kendskab til POLSAG vil det være muligt at blive bekendt med de umildbare problemer, som har været
med POLSAG. Derigennem vil det være muligt at finde den rette litteratur og teori til at kunne
analysere disse problemer fagligt. Ligeledes vil der løbende i processen med udarbejdelsen af opgaven blive inddraget relevant teori, som også vil blive brugt til at behandle emnet fagligt, men
også bruges til at kunne målrette informationssøgningen. Dette vil være med til at gøre problemsøgningen mere fokuseret og kvalificeret. Med inddragelsen af teorien først og derefter empirien vil der også blive gjort brug af en deduktiv tilgang hvor konklusionerne fra teorien vil blive
overført til POLSAG. Her vil det især de rapporter der bygger fra erfaringer fra statslige itprojekter blive inddraget.
Empirien vil både bestå af primærdata og sekundærdata. Primærdata vil hovedsagligt være de
dokumenter, som er frit tilgængelige i form af dokumenter udarbejdet med folketingets vedtagelse og arbejde med POLSAG. Selvom POLSAG er et offentligt projekt er store dele af projektet stadig fortrolige. Ligeledes har projektet haft en manglende succes, som kan have den betydning at
lysten til at informere yderligere om projektet og dets omstændigheder kan være manglende(Se
bilag 1). I stedet vil der blive gjort brug af sekundærdata i form af rapporter som er udarbejdet
med adgang til primærkilder og medieartikler som omhandler POLSAG. Hovedparten hvis ikke
alle data vil derfor være kvalitative data hvilket også vil have betydning for den analyse som vil
blive foretaget.
4.1.4 Analysen
Med udgangspunkt i informationssøgningen vil der blive lavet en redegørelse af POLAG og det
forløb it-projektet har været igennem. Denne redegørelse vil blive lavet for at give et overblik
over POLSAG. Med overblikket og en teoretisk baggrund vil det være muligt at udlede de problemstillinger som har været med til at påvirke POLSAGs forløb. Såfremt der vil blive udledt flere
problemstillinger vil der blive lavet en selekteringsproces, hvor de problemstillinger med den
største påvirkning og faglig relevans vil blive analyseret i forhold til relevant teori. Med en dybSide 10 af 91
degående analyse af problemerne og forholdende omkring POLSAG vil det være muligt at komme
med forslag til ændringer, som ville kunne minimere reducere eller helt undgå dem. Forslagene
til ændringerne vil ligeledes blive vurderet, så der tages stilling til brugbarheden af dem.
Analysen af empirien vil i stort omfang bygge på en systematisk kodning af det materiale, der er
til rådighed. Dette gøres for at få et overblik over materialet. Til at starte med vil der blive foretaget en åben kodning for at få kategoriseret materialet. Efter en åben kodning vil der blive gjort
brug af en axial kodning for at skabe hierarkisk abstraktion, der skaber et øget overblik og kontekst i materiale. (Eriksson, Kovalainen 2008)Efter axial kodning skal der bruges en selektiv kodning for at få indholdet af materiale i en form der gør den anvendelig med den teori som
anvendes. Derigennem opnås der en konstruktion hvorigennem materialet bliver brugbart i forhold til den enkelte teori. Men det vil med de tidligere opdelinger også være muligt at selektere
kodningen på en ny måde så de kan tilpasses den ønskede teori. Kodningen af empirien vil ligeledes blive brugt til at skabe et dokumentationsspor, hvorigennem det bliver muligt at tilbageføre
brugen af empirien tilbage til kilderne, og se hvor i analysen de enkelte uddrag af empirien bliver
anvendt. Store dele af empirien vil blive kodet, men vil ikke nødvendigvis danne direkte grundlag
for analyse. Dette begrundes med at empirien ikke forholder sig direkte til de dele af casen der
analyseres, eller passer til den anvendte teori. Ligeledes vil det også kunne opleves at der opnås
en mætning, hvoraf flere kilder vil kunne bruges til samme formål. Dette vil også udelukkende
være empirien som er kodet i den første omgang. Dette skal være med til at skabe sporbarhed og
gennemsigtighed i forhold til hvordan og med hvilket grundlag analysen er foretaget.
5 Den anvendte teori
For at kunne gennemføre en analyse af empirien og den udvalgte case, er det nødvendigt at det
bygger på et teoretisk grundlag. Et grundlag som skal beskrives og forklares således at den nødvendige klarhed omkring brugen af teorien bliver fastlagt. Samtidig kan teorien være med til at
bestemme og påvirke den vinke hvorpå empirien bliver fortolket.
Side 11 af 91
5.1 Bonnerup rapporten
Teknologirådet udgav i 2001 rapporten ”Erfaringer fra statslige IT-projekter – hvordan gør man
det bedre?”. (Bonnerup et al. 2001)Gruppen der lavede rapporten havde Erik Bonnerup som
formand, og deraf navnet. Formålet med rapporten, var at støtte op omkring politikere og andre
beslutningstagere i den offentlige sektor. Dette skulle gøres igennem at samle erfaringer fra tidligere it-projekter og fra medlemmerne i gruppen. Rapporten behandlede emnerne rammerne for
statslige it-projekter, den offentlige organisation og tamspil mellem leverandør og konsulenter.
Ved hvert af emnerne bliver der givet nogle anbefalinger.
5.1.1 Rammerne for statslige it-projekter
Til den offentlige organisation bliver det anbefalet at ambitionsniveauet skal sænkes, så der i stedet for egenudviklede systemer i højere grad skal bruges standardsystemer, hvor det er muligt. I
forhold til de offentlige kontrakter bliver et anbefalet at de danske standardkontrakter skal gøres
mere fleksible, men stadig inde for EU kravene. Staten bør ligeledes optræde som en samlet indkøber af IT-systerm. Dette skal gøres for at skabe stordriftsfordele, og i højere grad kunne gøre
brug af erfaringer. Når det kommer til den politiske forståelse skal den også styrkes. Dette er specielt med henblik på forståelsen af at der fra start af et projekt ikke nødvendigvis er kendskab til
samtlige krav, og dermed heller ikke den samlede økonomiske ramme.
5.1.2 Den offentlige organisation
I forbindelse med den offentlige organisation bliver der i Bonnerup rapporten anbefalet, at ansvaret for projektet i højere grad skal fæstnendes i den øverste ledelse. Dette skal gøres for at der
i højere grad er økonomiske og karrieremæssige incitamenter for den del af den øverste ledelse
der står med ansvaret.
Inden et projekt skal udvikles skal ledelsen lave et prospekt, som bl.a. skal indeholde informationer om formålet, målsætning, risiko, en samlet cost-benefit analyse, en analyse af organisationens
parathed, og en handlingsplan for hvordan organisationen kan ændres hvis det er nødvendigt.
Omkring størrelsen af leverancerne bliver det anbefalet at der ikke må være mere end 6 måneder
imellem dem, og antallet af beskæftigede udviklere må ikke overstige 30 personer. Dette skal an-
Side 12 af 91
befales for at øge fleksibiliteten imellem leverancerne, men også gøre det muligt i højere grad at
kunne gøre brug af de erfaringer som der skabes undervejs.
Ønsket om mere erfaringsudnyttelse viser sig også i anbefalingen om at gøre brug kollegial rådgivning og en højere grad at skabe en systematisk og dokumenteret erfaringsopsamling.
5.1.3 Samspil med leverandører og konsulenter
I anbefalinger til samspillet mellem leverandører og konsulenter, bliver der også her lagt vægt på
at der skal samles og deles erfaringer. Det er specielt erfaringer omkring kvaliteten af et udførte
arbejde og deres kompetencer der skal samles og deles ifølge anbefalingerne.
I forhold til kontakterne bliver det anbefalet at der skal ændres fra en mere negativ incitamentsstruktur, til en mere positiv incitamentsstruktur. Dette skal foregå for at gøre kontrakterne mere
fleksible og moderne.
Ønsket om den positive incitamentsstruktur understøttes også at det anbefales i højere grad at
gøre brug af store præmier og projektkonkurrencer, for at kvalificere køberens design af ITprojektet.
Det bliver også anbefalet at skabe og løbende vedligeholde en code-of-conduct. Denne skal skabes af staten i samarbejde med it- brancheforeninger og konsulenter. Samtidig skal der også i højere grad arbejdes frem imod at kunne fastholde de projektledere og it-medarbejdere, der har de
rigtige kompetencer og erfaringer.
Samlet set bliver der i Bonnerup rapporten lagt meget vægt på i højere grad at indsamle og gøre
brug af de erfaringer som løbende bliver skabt. Både inden for de enkelte projekter, men også på
tværs af statslige organisationer. I rapporten bliver der også ytret ønsker om mere fleksible og
moderne kontrakter, hvor fokus skal være på formål og positive incitamenter i stedet for bodsbetalinger.
5.2 Professionalisering af arbejdet med IT-projekter i staten
I 2010 blev der udgivet en ny rapport, denne gang fra Finansministeriet, og dermed regeringen.
(Finansministeriet 2010) Rapporten havde som formål at komme med anbefalinger til den fremtidige styring af de statslige it-projekter. Rapporten samler anbefalingerne i nogle indsatsområder som skulle forbedre it-projekterne og deres mulighed for at blive succesfulde. Rapporten
Side 13 af 91
bygger også ligesom Bonneruprapporten på erfaringer fra tidligere statslige it-projekter, herunder POLSAG.
Under fokusområdet kompetenceløft og bedre metoder bliver det anbefalet at lave en fælles itprojektmodel. Denne projektmodel skal danne grundlag for best practice. Igennem den ønskes det
at stille krav om minimums leverancer i løbet af projektet. Samtidig bliver kvaliteten løftet, ligesom dokumentationsniveauet stiger. Dette betyder også bedre mulighed for erfaringsopsamling.
Ligeledes skal projektmodellen være med til sikre at roller og ansvar bliver beskrevet, ligesom
projektets formål. Det bliver også anbefalet at lave en fælles kompetenceudviklingsmodel. Den skal
sikres igennem certificeringer, og skal være med til at hæve niveauet, og tilskynde projektledelse
som en karrierevej. Både den fælles it-projektmodel, og kompetencemodellen skal udvikles og
vedligeholdes af det nyoprettede Ministeriernes projektkontor. Gradvist skal der også oprettes et
fælles projektleder- og ressourceenhed, som skal indeholde personer med gode kompetencer indenfor projektledelse og IT-arkitektur. Dette skal gøres for at samle viden og evner, som kan udlånes til de enkelte styrelser og projekter når der er brug for det. En anden vigtig gevinst ville
være, at det blev nemmere at fastholde kompetente medarbejdere. Medarbejdere der også vil
kunne bruges i de styrelser, hvor der ikke gennemføres projekter særligt ofte. Igennem en obligatorisk udarbejdet bedre business case, som følger en bestemt fastlagt model, når projektsummet
overstiger 10 mio. kr. Hvilket skal gøres for at sikre at der gennemføres mere præcise estimater
for omkostningerne og de forventede gevinster. Samtidig giver det også i højre grad mulighed for
at lave en opfølgning på projektet.
Fokus på de risikofyldte IT-projekter for at holde risikoen nede på de risikofyldte projekter i staten bliver der i rapporten foreslået at det enkelte projekt skal følge fem principper:
”Staten skal være ambitiøs i forhold til digitalisering af den offentlige sektor, men skal kun gå forrest i anvendelsen af umodne tekniske løsninger, såfremt der er særlige perspektiver ved at foretage
en sådan satsning.
Allerede indkøbte eller udviklede løsninger skal genbruges i videst muligt omfang.
Kun projekter med klart beskrevne omkostninger, gevinster og effekter bør gennemføres.
Projekterne skal opdeles i mindre og selvstændige værdiskabende dele, som besluttes
og gennemføres uafhængigt af hinanden.
Side 14 af 91
Projekterne skal gennemføres med fælles metoder og kvalificerede ressourcer,
således at der i alle projekter er et passende modenhedsniveau.” (Finansministeriet 2010, Boston
Consulting Group 2011)
Anbefalingen lyder også på oprettelse af et statsligt it-projektråd. Et råd der skal være med til at
overse de offentlige IT-projekter. Herunder være med til at vurdere risikoprofilerne og hjælpe i
forbindelse med eksterne reviews. De skal ligeledes holde Økonomiudvalget opdateret, og være
med at iværksætte relevante metoder og vejledninger. Risiko profilen skal vurderes allerede tidligt
i projektet, for på den måde hurtigere at kunne finde frem til de risikofyldte projekter. Ligeledes
giver bedre risikovurderinger, mulighed for at foretage en bedre styring og kontrol af de tilstedeværende risici. Der skal også i højere grad gøres brug af kvantitative risikovurderinger. Dette skal
gøres for i højere grad at få en bevidsthed omkring de potentielle økonomiske konsekvenser af de
givne risici. Herunder også hvordan de vil påvirke den samlede business case.
Igennem eksterne reviews af risikofyldte it-projekter, skal projekterne gennemses af eksterne personer. Dermed bliver projekterne gennemset af uafhængige personer, og sandsynligheden for at
finde frem til urealistisk eller forkerte vurderinger vil blive øget. I Rapporten bliver det også ønsket at der ændres på reglerne for fremlæggelsen og orientering af projekterne, og budgetvejledningens særlige disponeringsregler. I rapporten anbefales det, at der foretaget initiativer for at
forbedre forholdet mellem it-projektets leverandører og de andre rådgiver som benyttes. Dette
skyldes at det gode forhold er vigtigt for projektets succes.
Et bedre samarbejde med leverandøre og rådgivere skal bl.a. sikres ved hjælp af løbende tværgående evaluering af leverandører og rådgivere. Dette skal gøres for at samle nyttige erfaringer, men
også få en bevidsthed omkring relationen, samt at kunne drøfte den med leverandøre og rådgivere. Herunder skal der også udarbejdes et katalog om mulighederne for dialog under EU’s udbudsdirektiv. Hvilket skal gøres for at øge mulighederne for dialog, bliver samarbejdet styrket.
Det bliver også anbefalet at udarbejde mindre omfattende kravspecifikationer. Fordi det anategs
at de meget omfangsrige kravspecifikationer er med til at forringe og hæmme samarbejdet. Det
anbefales i stedet at der findes fælles metoder hvorpå kravene kan udformes.
Side 15 af 91
5.3 Faktorer som påvirker systemudviklingsprojekters udfald
I artiklen Factors that Affect Software Systems Development Project Outcomes: A Survey of Research (McLeod, MacDonell 2011), har forfatterne forsøgt at samle empirisk litteratur omkring
systemudviklings projekter, og de faktorer der har betydning for projektets resultat. Herunder
har de inddraget tidligere litteratur, der har forsøgt at klassificere og opdele faktorerne. McLeod
og MacDonell (2011) har lavet deres egen model der viser de faktorer der er med til at påvirke
det endelige resultat, men også illustrer den indbyrdes påvirkning der er imellem faktorerne. (Fig
1.) Faktorerne er delt op i 4 hovedgrupper, med underfaktorer under hver. Hver hovedgruppe
består derunder af de faktiske faktorer der påvirker resultatet af projektet. Faktorer der er behandlet i tidligere empiriske studier. Studier der forholder sig til forskellige dele af faktoren, og
forsøger at redegøre for hvordan faktoren kan påvirke det endelige resultat.
Side 16 af 91
Institutionel kontekst
-Eksterne faktorer
-Interne faktorer
Mennesker og handlinger
Udviklingsprocessen
Udviklere
Brugere
Top ledelsen
Eksterne aktører
projekt team
Den sociale interaktion
Valg af krav
Projektledelse
Brug af standardmetode
Brugerdeltagelse
Brugertræning
Forandringsledelse
Projektets indhold
Projektets karakteristika
Projektets mål og omfang
Ressourcer
Teknologi
Resultatet
Figur 1: Oversigt over modellen (McLeod, MacDonell 2011)
5.3.1 Resultat (project outcomes)
Det bliver forslået i artiklen at der findes flere forskellige måder at måle et projekts resultat på,
og dermed også om hvilken udstrækning det har været en succes eller fiasko. Resultat af et projekt kan derfor måles i det færdigt udviklede produkt, og den proces der har været med til at føre
frem til det endelige produkt. Det kan også måles i implementeringsprocessen og produktet af
Side 17 af 91
denne. Til sidst kan det også måles i den samlede løsning, og hvorledes det har været med til at
påvirke forretningsprocesserne.
I forhold til måden at måle projektets resultat, kan det både gøres i håndgribelige indikatorer,
som økonomiske virkninger, eller tekniske indikatorer. Ikke alt kan nødvendigvis måles, og derfor kan vurderingen af et projekts succes også være mere subjektiv.
Der bliver også lagt vægt på at selvom et projekt ikke gennemføres fuldstædigt, er det ikke nødvendigvis en fiasko. Det skyldes at man selv med et ikke fuldt gennemført projekt har mulighed
for at samle erfaringer og viden, der kan være værdifulde senere.
5.3.2 Mennesker og handlinger (people and action)
Hovedgruppen mennesker og handlinger dækker over flere faktorer, i form af udviklere (developers), brugere (users), ledere (top management), eksterne aktører (external agents), projekt
team (social interaction), og den sociale interaktion (social interaction).
Ved udviklerne, er det især deres kompetencer og erfaring der har betydning. Men også deres
problemløsningsegenskaber, sociale egenskaber, normer og værdier samt viden om det specifikke område de skal lave systemet, for har en effekt. Ligeledes er deres motivation også en væsentlig faktor.
For brugerne, er en af de væsentligste faktorer de forventninger de har til systemet. Dette skyldes
at hvis der er et misforhold mellem forventningerne og det enlige resultat, kan det påvirke det
subjektive resultat negativt. Ligeledes er brugerens attitude og engagement omkring systemet
vigtig. Dette skyldes at hvis brugerne forventer at de kommer til at påvirke dem negativt, og/eller
ikke har betydning for dem, vil det påvirke muligheden for en succes negativt. Til sidst er det også vigtigt hvor erfarne og teknisk dygtige brugerne er.
Nogle af de personer som har den største betydning er ledelsen. Dette skyldes at de har ansvaret
for at udøve den nødvendige support til projektet Derfor er det også vigtigt at de har den rigtige
forståelse for systemet og har det nødvendige engagement. I forhold til ledelsens support er det
også vigtigt at ledelsen prioriterer at tilføre projektet de nødvendige økonomiske og personalemæssige ressourcer. Ledelsen har også mulighed for at påvirke brugernes attitude omkring projektet. Samtidig har ledelsen også ansvaret for at skabe en nødvendig sammenhæng mellem
systemet og forretningen.
Side 18 af 91
Igennem tiden er der sket en udvikling hvor eksterne aktører er begyndt at udfylde en større rolle
i projekterne. De eksterne aktører kan bl.a. udgøres af leverandører eller eksterne konsulenter. I
forhold til de eksterne aktører er det specielt forståelsen mellem dem indbyrdes, og forståelsen
mellem den organisation der ejer projektet. Også de kontrolmuligheder der er, af de eksterne aktører udgør en væsentlig faktor. Herunder er kontrakten betydelig. Ligeledes har kvaliteten af det
arbejde og produkter de leverer betydning for det endelige resultat.
Selve projektteamet har også betydning for projektet. Herunder er det specielt faktorer som størrelse, sammensætning, og stabilitet der har betydning. Her kan for store eller ustabile teams udgøre en risiko. Ligeledes er der som ved andet personale vigtigt at teamet besidder de rigtige
kvalifikationer og den nødvendige erfaring. Også her er det vigtigt at relationerne i teamet er gode, og der er veldefinerede roller. Til sidst har det også betydning i hvor høj grad ansvaret er
klart defineret og placeret.
Den sociale interaktion omkring projektet udgør en væsentlig faktor. Herunder den kommunikation der bliver brugt. Herunder kommunikationskanaler og den kultur der bliver skabt omkring
projektet. Ligeledes har det også betydning, hvilke forventninger og målsætninger forskellige
personer og grupper forventer projektet har. Derudover har det politiske i hvilke mål og ønsker
forskellige grupper har også en effekt. Det er betydende at hvis der er forskel imellem dem, kan
det have negative effekter, både når det kommer til de oplevede og faktiske. Derigennem er det
også vigtigt at der er en forståelse grupperne og personerne imellem. Herunder den historie som
gør sig gældende inden for organisationen.
5.3.3 Projekt indhold (project content)
Selve indholdet af projektet udgør og en af de hovedgrupper der har betydning for det endelige
resultat. Indholdet bliver i artiklen defineret som projektets karakteristika (project characteristics), omfang, mål (project scope, goals & objectives), samt ressourcer (resources) og teknologi(technology).
Med projektets karakteristika menes størrelsen af projektet, og den kompleksitet der er i den ønskede løsning. Projektets størrelse kan måles på flere måder, men som udgangspunkt betyder et
større projekt højere risiko. Ligeledes er der også en sammenhæng imellem kompleksiteten og
Side 19 af 91
risiko for fiasko. Hvor en højere kompleksitet betyder en højere risiko. Yderligere har det også
betydning, hvor nyt og anderledes projektet er i forhold til organisationen.
Mål og omfang af projektet udgør også en væsentlig rolle. Dette kommer til udtryk i den måde
hvorpå mål og omfang bliver defineret for projektet, og hvordan det bliver kommunikeret ud i
organisationen. Ligeledes har det også betydning i hvor høj grad at både mål og omfang er stabile
faktorer i løbet af projektet, samt hvor meget der ændres på dem. Det er også vigtigt at der er en
sammenhæng imellem mål, og så forretningen. En anden betydende del, er at både mål og omfang er realistisk. De ressourcer der bliver allokeret til projektet har også en væsentlig betydning
for det endelige resultat. Dette gør sig gældende for de finansielle ressourcer, menneskelige ressourcer, og udviklingstimer. I forhold til teknologien har den også betydning for indholdet af projektet. Herunder den teknologi og de værktøjer der bliver brugt til at udvikle systemet. Det har
også betydningen i hvor høj grad den teknologi, som skal bruges er ny og hvor gennemprøvet den
er, både de i forhold til de personer der deltager i projektet, men også generelt. Yderligere har det
også betydning hvilket omfang der skal ændres og videreudvikles på den software der tages i
brug. En anden vigtig faktor er kvalitet, formen og tilgængeligheden af de data der skal indgå i systemet.
5.3.4 Udviklingsproces (development processes)
Den udviklingsproces som projektet gennemgår, er også en af de hovedgrupper der har betydning for projektet. Herunder er det faktorer som udvælgelsen af krav (requirements determination), projektledelsen (project management), brug af udviklingsmetode(use of standard method),
ændringer (management of change), træning af brugere (user training) og disses deltagelse (user
participation).
Udvælgelsen af krav er et kritisk punkt i udvikling af systemer. Det er dem som er med til at udforme et system. Derfor er det også vigtigt at de er klart defineret, og konstruerede på en måde
hvorpå alle parter har den samme oplevelse af dem, og er enige om udformningen. Ligeledes har
det betydning hvilke form for krav der defineres, og hvor klare og stabile de er i løbet af projektet.
Faktoren projekt ledelse vedrører, i høj grad projektlederen og hans erfaring og kompetencer.
Også stabiliteten omkring projektlederen og dermed udskiftningen af denne menes at have beSide 20 af 91
tydning. Graden af ledelse og kontrol har også betydning for projekt, ligesom den kontrol der bliver udført. De metoder og teknikker der bliver valgt eller fravalgt i forbindelse med projektledelsen har også en effekt på det endelige resultat. Ikke kun når det kommer til projektledelsen har
brug af metode en betydning, men det gør sig også gældende når det kommer til den overordnede udviklingsmetode, hvor brug af en standard metode har betydning. Dette gælder både for det
endelige resultat men også selve processen. Omfanget og i hvor høg grad den bliver ændret har
også en effekt.
Brugerne er også en faktorer under udviklingsprocessen, da de også er repræsenteret her. Her
gør de det i stedet med input til udviklingen af systemet. Derfor er de også her en væsentlig faktor. Det har betydning i hvilket omfang de bliver brugt, hvornår i processen de bliver brugt, og i
hvor høj grad de aktiviteter de deltager i er meningsfulde. Brugerdeltagelsen er også med til at
skabe brugernes opfattelse af systemet.Træning af brugerne har også en betydning for hvor det
endelige system bliver modtaget og brugt. Her er det specielt den forståelse og tryghed brugerne
får for systemet, og i hvilket omfang de har eller får de rigtige kompetencer til at bruge det.
Omkring de ændringer der bliver foretaget i organisationen og i arbejdsprocesserne et dette også
en væsentlig faktor, hvor timingen og omfanget af dem er de variabler som har betydning for effekten.
5.3.5 Institutionel kontekst (institutional context)
Den institutionelle kontekst udgør en betydningsful faktor, og som placeringen i modellen illustrerer, interagerer den med samtlige af de andre faktorer. Her er der både faktorer internt i organisationen (organizational properties) og eksternt (environmental conditions)der påvirker
resultatet. Internt i organisationen er det faktorer som den interne kultur der påvirker projektet,
herunder også de politikker og den praksis der gør sig gældende i organisationen. Deriblandt
spiller den historie organisationen har med udvikling og brug at it-systemer og en vigtig rolle.
Organisationer der tidligere har haft store problemer med udviklingen af systemer vil også senere have problemer med at få succes, da der i kulturen kan risikeres at forvente kommende fiaskoer. Ikke kun bruget, men også de systemer der befinder sig i organisationen inden spiller også
en rolle i projektet og dets resultat. Når det kommer til de eksterne forhold, er det faktorer som de
socio-politiske og økonomiske faktorer der gør sig gældende. Også udefra komme interessenter
Side 21 af 91
som offentlige myndigheder eller staten kan have betydning. Det er ikke kun kulturen internt i
organisationen der har betydningen, men også kultren i den nationale kontekst har betydning for
projektet.
6 POLSAG og forløbet
Efter at teorien blevet præsenteret og fastlagt, skal der ligeledes skabes et kendskab tilden case
hvorpå at teorien skal benyttes. Ved at skabe kendskab til casen, er det muligt at tydeliggøre,
hvilke problemer der har gjort sig gældende. Problemer der kan give anledning til at bestemme
hvilken teori der kan bruges til at analysere problemstillingerne.
6.1 Generelt om POLSAG
POLSAG var navnet på det projekt der skulle overtage POLSAS, som sags- og dokumenthåndteringssystem hos Rigspolitiet. Systemet skulle være fuldt digitalt i modsætning til det mere papirbaserede POLSAS.(Statsrevisorne 2012) Ligeledes skulle POSAG også fungere som et
landsdækkende system, som ville koble de enkelte politikredse sammen. Ved at lave arbejdsgangene digitalt understøttet, skulle det åbne for nemmere at dele dokumenter og informationer på
tværs af politikredsene, men også åbne op for at systemet kunne understøtte kontakten med eksterne interessenter i form af borgere og domstole.
6.2 Forløbet
I januar blev der i folketinget indgået et forlig om at politiet skulle gennemføre en systemmodernisering. En systemmodernisering som skulle medføre et skifte fra det daværende POLSAS til et
nyt system der senere skulle blive kendt som POLSAG. (Justistsministeriet 2003-04)POLSAS som
havde været i brug siden 1997. Den samlede budgetterede pris til modanisringsprogrammet
havde på daværende tidspunkt en pris på 273 mio. kr. i perioden 2004-2006 heraf skulle de 153
mio. kr. er fordelt på 100 mio. til sagsbehandlingssystemet, 22,5 mio. til integrationslaget, og 30,5
mio. til uforudsete udgifter. Yderligere blev der sat 5,5mio kr. af til at lave et performancetestmiljø som bl.a. skulle bruges i forbindelse med udarbejdelsen af det nye sagsbehandlingssystem,
hvor bl.a. systemets svartider ville være vigtige. (Justistsministeriet 2003-04)I 2004 var Rambøll
Side 22 af 91
sat i gang med at undersøge om et FESD system ville kunne danne grundlag for det sagsbehandlingssystem der skulle udvikles til politiet. Vurderingen af en FESD mulighed blev foretaget af
rigspolitiet i samarbejde med konsulentvirksomheden PLS Rambøll Management.
I 2004 blev en foreløbig risikovurderingen af anskaffelsen af sagsbehandlingssystemet og integrationslaget sat til at have en middel til høj risikoprofil, hvor især det de organisatoriske forhold
udgjorde en væsentlig del af risikoen, med henvisning til systemet centrale placering i politiets
arbejde. Ligeledes var projektets samlede kompleksitet med til at forhøje risikoen. En egentlig risikovurdering blev planlagt til udgangen af 2005. (Justistsministeriet 2003-04)
I januar 2005 giver finansudvalget tilslutning til at starte udviklings- og moderniseringsprogrammet, og hermed også udviklingen af sagsbehandlingssystemet. Hvilket sker i aktstykke 74.
Det oplyses også i aktstykke 74 at konsulentfirmaerne Deloitte Consulting og Gartner mener at
POLSAS teknologiske fundament ikke kan bruges fremadrettet.(Justistsministeriet 2004-05)
For at håndtere risikoen af det samlede moderniseringsproces blev det aftalt at der skulle nedsættes en følgegruppe bestående af 4 medlemmer, heraf en repræsentant fra Justitsministeriets
departement, en fra Finansministeriet og to eksterne medlemmer.
I februar 2006 bliver aktstykke 106 fremført som en orientering omkring moderniseringsprocessen. Her bliver det oplyst at PLS Rambøll Management det er muligt at bruge en FESD løsning
som grundlag for det nye sagsbehandlingssystem. Rambøll vurderer ligeledes at der er to brugbare løsninger i form af Software Innovations ”Public 360x” og CSC Danmark A/S (CSC) med
Scanjour A/S som underleverandørs ”CAPTIA”. Efter yderligere evaluering blev der kun indledt
forhandlinger med CSC og dermed systemet CAPTIA. Efter valget af en FESD løsning og CAPTIA
bliver den samlede risikoprofil stadig vurderet til middel til høj. Det vurderes, at der med valget
af en FESD løsningen bliver minimeret i den tekniske risiko, da der vil blive taget udgangspunkt i
et standardsystem. I stedet vil risikoen forbundet med de organisatoriske forhold stige, fordi de i
højere grad er bundet op på standardfunktionaliteten. (Justistsministeriet 2005-06)
I Aktstykke 119 fra april 2007 bliver det oplyst at rigspolitiet har gjort brug af konsulentfirmaet
PA Consulting til at evaluerer tilbuddet fra CSC. Igennem evalueringen, har de også været med til
at afdække uklarheder og lave yderligere analyse, så der kunne gøres klar til et endeligt tilbud.
Konsulentvirksomheden Devoteam udarbejdede en foranalyse og kravspecifikation for integrati-
Side 23 af 91
onslaget. Analysen og kravspecifikationen blev brugt til at indhente tilbud, inden for en allerede
gældende rammeaftale, som blev holdt op imod POLSAG projektet, og konklusionen blev at en
gennemførelse af begge del ville betyde en alt for høj risikoprofil. Derfor blev det besluttet at i
stedet for at indføre et integrationslag, skulle man sikre sig at POLSAG kunne kobles sammen
med politiets øvrige systemer. Derigennem lave en integrationsløsning (serviceorienteret arkitektur), som skulle danne grundlag for et kommende integrationslag. De samlede omkostningerne til projektet som indbefatter POLSAG og integrationsløsningen, budgetteres i 2007 til at blive
221 mio. kr. Stigningen i de samlede budgetterede omkostninger skyldes ifølge konsulentfirmaet
Gartner at der er tilføjet ekstra ønsket funktionalitet til systemet, ligesom der er tilføjet ønsker
om datawarehouse, skanningsfaciliteter, og et øget brug af konsulenter. Gartner vurderer ligeledes at prisen ligger over markedsprisen. Dette tilskrives det tætte forhold til CSC. Et forhold der
igennem mange års drift, udvikling, samt en lukket arkitektur af eksisterende løsninger. Ligeledes ville valget af en anden leverandør betyde en forhøjet risiko. En risiko som forventes at overstige merprisen. Tidsplanen for projektet i 2007 estimerer projektet til at være implementeret i
sommeren 2010.
I 2007 er der ligeledes blevet lavet en ny risikovurdering, hvor den samlede risiko bliver vurderet til 4 på en skala fra 1 til 5. Ingen af de underliggende faktorer bliver vurderet til under 3. Specielt den tekniske løsning og leverandører, bliver vurderet til faktorer der er med til at højne den
samlede risiko. Den høje risiko er begrundet med at det ønskede system har en høj kompleksitet,
og at der er mange snitflader til andre systemer, som der skal tages højde for. Den høje risiko i
forbindelse med leverandren begrundes med at den aftalemæssige konstruktion er kompleks, og
der er en tæt sammenkobling mellem de enkelte elementer i aftalen. Den tætte sammenkobling
betyder også et små forsinkelser kan have betydning for resten af projektet. For at imødekomme
risikoen aftales det at der skal nedsættes et programkontor, og at CSC vil stå garant for at
POLSAG bliver implementeret til den rigtige tid. (Justitsministeriet 2006-07)
I maj 2008 bliver der i aktstykke 157 orienteret om projektet til Finansudvalget i folketinget(Justistsministeriet 2007-08). I den første del af programmet har der være fokus på design af
systemet. Et fokus som har betydet der på daværende tidspunkt allerede var sket en mindre forsinkelse i processen. Forsinkelsen mentes på daværende tidspunkt at kunne indhentes med en
Side 24 af 91
replanlægning af de resterende designaktiviteter, således at den samlede tidsplan ikke ville blive
berørt. Samlet set har fremdriften i projektet ikke betydet at den samlede risikovurdering af projektet har ændret sig. Det var midlertidigt blevet tydeliggjort at dele af de tekniske risici grundet
de mange snitflader er høj og at designfasen har vist at der er krav til store tilpasninger af systemet Captia. Leverandør faktoren er ligeledes uddybet yderligere, da der har været problemer hos
CSC, med at tilføre tilstrækkeligt med personalemæssige ressourcer. (Justistsministeriet 200708)
I juni 2010 blev der fremlagt et nyt aktstykke i folketingets finansudvalg. Aktstykket gav anledning til et samråd hvor der blev stillet yderligere spørgsmål til projektet. Aktstykket blev senere
trukket tilbage, og erstattet af en ny opdatering i form af aktstykke 66. Tilbagetrækningen skyldes uklarheder i aktstykket om overtagelsesprøven for systemet. I Aktstykket bliver det oplyst at
CSC har haft problemer med at leve op til de opstillede milepæle. Og i efteråret 2008 blev der
estimeret at den samlede tidsplan var skredet med 4 måneder. Der havde ligeledes været problemer med kvaliteten af de leverancer som CSC har udført. Problemer med både kvalitet og
tidsplan, betød at Rigspolitiet fik Boston Consulting Group til at lave et eksterns konsulentreview.
Konsulentreviewt skulle laves for at kunne vurdere om CSC ville være i stand til at kunne levere
et system der levede op til kravspecifikationen. Boston Consulting Group vurderede det som helhed var muligt, men at etableringen af et datawarehouse ikke ville være muligt. Datawarehouset
skulle i stedet erstattes af en rapporteringsfunktionalitet. Rapporten fra Boston Consulting Group
blev afleveret i august 2009. Samtidig var der lavet en ny tidsplan for projektet. Tidsplanen blev
lavet i et samarbejde mellem Rigspolitiet og CSC, og de nødvendige kontraktmæssige justeringer
foretaget. Samlet set blev den samlede forsinkelse estimeret til at være på 13 måneder. Den samlede budgetterede pris til 425 mio. kr. Den samlede risikovurdering var ikke ændret. I forbindelse med den tekniske faktor blev den stadig vurderet til over middel. Dette skyldtes at der var
problemer med performancekravene i systemet, og den samlede kompleksitet. I forhold til leverandør faktoren, lagde risikoen i at der kunne være problemer med kvalitet og deadline på de
delleverancer der skulle leveres. I den samlede risikovurdering, oplyses det at der ikke er lavet
nærmere vurdering af de potentielle økonomiske konsekvenser, de opridsede risici kan have.
(Justistsministeriet 2009-10)
Side 25 af 91
I november 2010, bliver aktstykke 66 fremlagt, og dermed det aktstykke som står i stedet for det
tilbagetrukne aktstykke 157. I aktstykke 66 bliver de budgetterede omkostninger angivet til at
blive 405 mio. kr. Den samlede POLSAG løsning består i 2010 af den oprindelige kravspecifikation samt 2 udviklingspakker fra henholdsvis efteråret 2009 og efteråret 2010. Udviklingspakkerne er tilføjet for at tilpasse systemet til en ny kredsstruktur, en politireform, opdagede
uhensigtsmæssigheder, og yderligere ønsket funktionalitet. (Justistsministeriet 2010-11)
Ved aktstykkets udgivelsesdato er den første udviklingspakket blevet færdigudviklet og testet, og
er klar til at blive implementeret på Bornholm. Udviklingspakke 2 forventes først at skulle være
færdigudviklet og klar til test januar 2011. Dette betyder at den samlede implementering estimeres til først at være gennemført juni 2012. (Justistsministeriet 2010-11)
Aktstykke 66 medførte også en revurderet risikovurdering. En vurdering som på et overordnet
plan udelukkende har ændret sig ved at organisationsfaktoren er vurderet til at være lavere end
tidligere antaget. Den tekniske faktor udgøres på dette tidspunkt stadig den største enkeltstående risiko. Specielt de lange svartider udgør et problem. Det skønnes at leverandøren stadig ville
kunne formå at leve op til de ønskede svartider. Dette skyldes bl.a. at der ikke er skrevet specificerede og kvantificerede end-to-end svartider ind i kontrakten. Det har også betydningen for den
tekniske løsning at systemet er bygget ovenpå Captia. Dette kan have betydning for den senere
mulighed for at skifte leverandør, og dermed også fremtidige omkostninger. I forhold til leverandørerne antages de stadig på dette tidspunkt at udgøre en stor risiko, hvor specielt leverandørenes evne til at levere i rette tid, og med den rette kvalitet.
Efterfølgende begyndte udrulningen af POLSAG i Bornholmspolitikreds. (Hansen 2010)
Et år senere i februar 2013 bliver projektet stoppet helt. Det var regeringen der stod for at stoppe
projektet. Men allerede inden projektet bliver stoppet, har de borholmske betjente været ude i
pressen og ytre deres misbehag omkring systemet. Ytringerne skyldtes bl.a. et udrulningen af systemet havde påvirket trivslen negativt for medarbejderne.(Pedersen 2012) Sammen med de negative erfaringer fra Bornholm, blev rapporter udarbejdet af konsulentvirksomhederne
Globeteam og Boston Consulting Group. Disse var det med til at give et så negativt billede af projektet at det skule lukkes. (Pedersen, Hansen 2013) Rapporten fra Globeteam forholdte sig til
POLSAGs performance. (Røjel, Hvid et al. 2012) Imens forholdte, rapporten fra Boston Consulting
Side 26 af 91
Group sig mere til projektets omkostninger og risici. (Boston Consulting Group 2011). Efter at
projektet blev stoppet blev de samlede anslåede omkostninger opgjort til 567 mio. kr. (Statsrevisorne 2012).
6.3 Generelt om forløbet
Det samlede forløb omkring POLSAG er blevet behandlet i en beretning fra statsrevisorerne. I
denne beretning blev POLSAG og forløbet heromkring kritiseret på flere punkter. Herunder blev
Rigspolitiets forberedelse og styring behandlet. (Statsrevisorne 2012)
På det mere generelle plan blev det kritiseret at politiets ledelse ikke var engageret nok i POLSAG
projektet. Dette er illustreret ved at de styregruppemøder der skulle afholdes udelukkende fungerede som orienteringsmøder, hvor der reelt ikke blev besluttet noget. I de første 4 år blev der
også kun holdt 5 styregruppemøder hvor Rigspolitichefen deltog. I 2009 efter en ny rigspolitichef
blev ansat, steg mødedeltagelsen fra rigspolitichefen. Generelt blev projektet heller ikke dokumenteret grundigt nok. Flere beslutninger blev taget uden at beslutningsgrundlaget blev dokumenteret. Ligeledes blev flere orienteringer også udelukkende foretaget mundtligt. Samtidig var
projektet placeret i Rigspolitiets it-afdeling, hvilket havde den betydning at den nødvendige beslutningskraft ikke lå hos projektledelsen. Dette viste sig bl.a. ved at det ikke varmuligt at kunne
foretage beslutninger som vedrørte politiets arbejdsprocesser. Dette kan også formodes at have
betydning for at der blev valgt at indføre 1:1 krav fra POLSAS. Krav der medførte at POLSAG skulle kunne det samme som POLSAS. På denne måde var det ikke nødvendigt at ændre på arbejdsgangen, i stedet skulle det nye system tilpasses arbejdsprocesserne. Dette blev yderligere
forværret ved at under den brugerinddragelse der blev foretaget, kunne der opstå uenighed imellem brugerne om hvordan funktionaliteten i POLSAS blev brugt i det daglige arbejde. (Statsrevisorne 2012)
Omkring selve kontraktindgåelsen blev den laves således at betalinger og leveringer ikke nødvendigvis fulgtes ad. I stedet fulgte betalingerne de forbrugte arbejdstimer hos leverandøren.
Grunden til at der ikke var sammenhæng mellem betalingerne og leverancer føres tilbage til at
det var en FESD-standardkontrakt der skulle bruges til systemet. I forhold til kontrakten og det
senere problem med svartiderne, var det heller ikke muligt at få tilføjet et konkret krav i kravspecifikationen om en end-to-end svartid. Dette blev begrundet med at en sådan svartid ville væSide 27 af 91
re afhængig af POLSAGS randsystemer, og at leverandøren ikke ville påtage sig ansvaret og risikoen for systemer de ikke havde kontrol over. Dette på trods af at flere af randsystemerne drives
af CSC. I stedet skulle de samlede svartider være ”rimlige”. Kravene til de svartider der udelukkende gjorde sig gældende for POLSAG kunne måles og blive konkrete. (Statsrevisorne 2012)
7 Udledning af problemstillingerne
POLSAG har været meget i medierne og er blevet kritiseret fra flere sider. Specielt har det været
de store budgetoverskridelser og de lange svartider på det implementerede system på Bornholm.
(Bilag 3- 192)Problemer der er mållige og som udgangspunkt relatere sig det det endelige resultat. I stedet for at fokusere på det endelige resultat, og tolkningen af denne, for at vurdere i hvilken grad POLSAG har været en succes, er det mere interessant at fokusere på den proces der
ledte op til resultatet.
Både eksterne konsulenter(Boston Consulting Group 2011) og Statsrevisorerne(Statsrevisorne
2012) har behandlet POLSAG, og er kommet med kritikpunkter. Problemerne er fundet både med
udgangspunkt i teorien, og i empirien.
7.1.1 Projektstyringen
Udover den høje pris for et system der aldrig blev taget i brug, er den skarpe påtale rettet imod
ledelsens engagement og styring af projektet.(Bilag 3-95+96) Punkt som teoretisk bliver behandlet i Bonnerup rapporten fra 2001, men også i finansministeriets rapport fra 2010 og i McLeod i
2011. Derfor er det relevant at behandle dette punkt for at belyse, hvordan POLSAG har fulgt de
fremlagte råd, og analysere hvordan fravigelser fra rådene har påvirket projektet.
7.1.2 Kontrakten
En af de andre kritik punkter som specielt blev fremsat af Boston Consulting Group efter deres
review af POLSAG i 2011, var valget af kontrakt. Anskaffelsen af POLSAG byggede på en standard
ESDH kontrakt. En kontraktform som ikke har passet til det endelige system og projekt. Kontraktformen er ligeledes noget som er beskrevet i de råd der er givet til statslige it-projekter, og i
den beskrevne teori. Enten eksplicit om kontrakter, eller implicit, som forholdet til leverandører.
Side 28 af 91
7.1.3 Kravspecifikationen
Når det kommer til de krav der er sat i forbindelse med POLSAG, har dette også været under kritisk. Specielt forholdet omkring at det er bygget over standardsystemet Captia, og at der skulle
indføres 1:1 krav i forhold til det ældre system POLSAS. (Bilag 3- 109+115+117) Udformningen
af krav påvirker ligeledes leverandørforholdet, men bliver også eksplicit behandlet i Finansministeriets rapport fra 2010 og i McLeod fra 2011. Kravspecifikationen er interessant at kigge på ud
fra flere vinkler. Både i form af den rolle den spiller for det endelige produkt, men også for rollen
i forbindelse udviklingsprocessen. Ligeledes er det relevant i forhold til den betydning kravene
kan have for udformningen og ændringen af de fremtidige arbejdsprocesser.
7.1.4 Risikostyrring
Et af de steder hvori der opstod problemer i forbindelse med styring af projektet, var i forbindelse med ressource mangel (bilag 3- 12), dårlig tekniskløsning (bilag 3-47), budgetoverskridelser,
dårligt samarbejde med leverandørerne. (bilag 3-187+205+206) Problemer som alle kan relateres til risikostyringen. Risiko var et af de punkter der blev fokuseret særligt på i forbindelse finansministeriets rapport fra 2010. Specielt risiko i forbindelse med dyre projekter, som POLSAG.
Derfor er det relevant at kigge på i hvor høj grad POLSAG levede op til de råd der blev givet i
2010, og om de vikke kunne have forhindret den udgang som POLSAG fik.
8 Analyse af POLSAG
Ved at benytte den relevante og tidligere beskrevet teori på casen, er det muligt at gennemføre en
analyse der kan være med til at svare på den fremsatte problemstilling. Igennem analysen bliver
det muligt at finde frem til årsagerne til de problemer som har været med projektet. For at kunne
gennemføre analysen skal empirien og teorien knyttes sammen.
8.1.1 Resultatet
I medierne er POLSAG blevet betegnet som en fiasko. Båd med belæg i at det aldrig blev gennemfært, og at det overskred budgettet væsentligt. Men iflg. McLeod (2011) betyder det at et projekt
ikke er blevet fuldt implementeret, ikke at det nødvendigvis har været en fiasko. I forhold til det
Side 29 af 91
udviklede produkt som de stod med ved projektets afslutning, var det et system som havde meget lange svartider.(bilag 175+192) Dermed kan der argumenteres for at produktet ikke levede
op til det der var forventet. Produktet nåede heller aldrig et niveau for hvori det blev besluttet at
det kunne tages i brug i det planlagte omfang. Det må derfor kunne konkluderes at projektet på
dette plan ikke var nogen succes.
Implementeringen af systemet blev kun foretaget delvist og udelukkende som pilotdrift på
Bornholm. Det er derfor vanskeligt at vurdere om implementeringen ville have været en succes. I
rapporten fra Statsrevisorerne, bliver det fremlagt at såfremt implementeringen skulle have fortsat skulle undervisningsdelen have været justeret, da brugerne på Bornholm ikke havde haft de
rigtige værktøjer til at bruge systemet. (bilag 3-154)Der var derfor problemer i implementeringen af pilotprojektet, men ikke nødvendigvis af en størrelse som oversiger hvad man ville forvænte at finde under pilotdriften.
Hvis man vælger at se på projektet som en samlet løsning hvor man ser på hvordan, det ville passe ind i organisationen, er der også her problemer. Statsrevisorerne oplyser at der selv et år efter
pilotdriften var startet, havde man ikke beskrevet de nye arbejdsprocesser som systemet havde
medført. (bilag3-154) Det kan være svært at vurdere de potentielle forbedringer som systemet
kunne have medført, udelukkende fra en problemetisk pilotdrift. Der vil derfor ikke kunne argumenteres for en ensidig konklusion.
Selvom POLSAG ikke blev gennemført som det var planlagt, kunne det stadig have været en mulighed at der kunne have igangsat en læringsproces. Denne kunne have forbedret mulighederne
senere succeser. Dette har ikke været ensidigt gældende. Statsrevisorerne ytre i stedet kritik af
den manglende dokumentation som projektet har været plaget af. (bilag 3-139) En Dokumentation der kunne have dannet grundlag for en forståelse af de beslutninger der blev taget undervejs.
Med en bedre forståelse af de beslutninger der blev taget undervejs ville de have været muligt i
højere grad at drage erfaringer af projektet. På denne parameter har POLSAG, derfor også manglende succes.
8.1.2 Mennesker og handlinger
Med en analyse af de mennesker og handlinger som har været med til at udføre POLSAG projektet, er det muligt at se på hvilken påvirkning dette har haft. Under en komplet analyse vil det væSide 30 af 91
re nødvendigt at kende til forholdende omkring alle de personer som har deltaget i projektet og
hvordan disse har arbejdet. Grundet projektets art og beskaffenhed er det ikke sikkert det har
været muligt at tage samtlige faktorer i betragtning eller nødvendigt.
8.1.2.1 Udviklere
Projektets udviklere kommet i høj grad fra underleverandørerne CSCog ScanJour. (bilag 3-42) I
Boston Consulting Groups rapport, bliver det beskrevet at leverandørren har haft udfordringer
med at tiltrække medarbejdere med de nødvendige kompetencer til projektet. (bilag 3-12) Under
projektet har der også været en stor afhængighed at få nøglepersoner, som har besiddet de nødvendige kompetencer. (bilag 3-42) Dette kan tolkes som at de ikke har haft mulighed for at besætte projektet med personer med de rigtige kompetencer. Dette kan derfor betyde at projektet
har lidt under dette. Herunder det endelige produkt.
8.1.2.2 Brugere
De bruger der i sidste ende skulle bruge POLSAG, blev også inddraget i udviklingen af systemet.
Mere specifikt var det brugere fra Midt- Vestjyllands politi og fra Københavns politi. Brugerne
blev inddraget igennem workshops. Dette blev gjort for at få viden fra 2 typer af politikredse.(bilag 3-168) Når det kommer til brugernes forventninger til systemet kan de være svære at
måle. Men selv efter projektet blev lukket kunne brugerne på Bornholm se muligheder i systemet
(bilag 3-193) . Et system hvis lukning blev modtaget med klapsalver af samme brugere. (bilag 3192) Ud fra det kan det udledes at der var positive forventninger til det, som brugerne blev lovet
omkring systemet, men efter systemet kom i brug blev forventningerne ændret til det negative.
Selvom brugerne havde en positiv tilgang til hvad systemet har kunnet, har der under interviews
udført under udarbejdelsen af BCG fra 2011 haft tegn på andet Her blev det fremført at medarbejderne stadig ønskede at arbejde med sagerne i et papirformat, i stedet for udelukkende at
bruge systemet. (bilag 3-48) Dette er et tegn på at it paratheden har manglet, og at de ikke fuldt
ud har været en dedikation fra medarbejderne til det fulde projekt. Derfor havde forventningerne til systemet en delvis positiv effekt fra start, som må formodes at kunne have en effekt der har
kunnet motivere til en højere involvering fra brugernes side. Attituden ændrede sig efterfølgende
til det negative, og til en attitude der ville have påvirket den videre implementering i andre politikredse såfremt det var sket.
Side 31 af 91
8.1.2.3 Top ledelsen
Ledelsen spiller en vigtig rolle projektet, og omkring POLSAG har ledelsen været under kritik. I
rapporten fra BCG i 2011 bliver den kritiseret for ikke at have muskler nok i forhold til leverandørerne, og ikke have fokus nok på implementeringen og udviklingen. (bilag3-3) Dette må anses
for at være kritisk for projektet. Samtidig har der ifølge medierne været tilfælde hvor potentiel
ansat, skulle have fået at vide at han ikke skulle tage jobbet, da den daværende tekniske chef for
POLSAG ikke mente at projektet ville lykkedes. En samtale der fandt sted i 2007(bilag 3-202). Såfremt det er sandt har ledelsen ikke haft den nødvendige tro på projektet, og må derfor heller ikke antages at have gjort det nødvendige for at motivere de andre ansatte, som har været
involveret. Samtidig kan lignende ansættelsessamtaler ikke have været fremmende for at få løst
problemet med manglende kvalificeret arbejdskraft. Det er ligeledes et tegn på at der ikke har
været det nødvendige engagement for at få projektets gennemført. Hvis ledelsen ikke går forrest
og viser i hvilken retning projektet skal gå, vil det have svære vilkår. Ledelsen er også med til at
kommunikere projektets og dets mål ud til dets interessenter. Klarheden omkring målene er også vigtig, hvilket en ledelse som ikke tror på projektet kan have svært ved at opretholde. Når ledelsen ikke har en tro på at projektet vil lykkedes, er der også en begrundet tro om at ledelsen
ikke prioritere at tilføre projektet de nødvendige ressourcer. Samtidig kan det lave antal styregruppe møder være et symptom på dette. (bilag 3-137) Det var ikke udelukkende den tekniske
ledelses manglende tro på projektet der er blevet kritiseret. Også at det var en leverandør i form
af CSC der havde ledelsesansvaret er blevet kritiseret. (bilag 3-143) Dette har betydet at ledelsen
af projektet i ikke har haft den samme forankring i organisationen, der har med årsagende til at
den forretningsmæssige indsigt har været det, et projekt af POLSAGs størrelse kræver. Ligeledes
er incitamentet for at lave et system der på lang sigt giver en forretningsmæssig fordel ikke til
stede, hvorimod incitamentet for at leve op til de kontraktmæssige krav er større. Samtidig kan
det også virke modstridende, at placere ledelsen for projektet hos leverandøren, når denne bliver
vurderet til at være en af de mest risikofyldte faktorer i projektet i de løbende risikovurderinger.
8.1.2.4 Eksterne aktører
Omkring de eksterne leverandøer har specielt CSC fået et stort ansvar, i form af ansvaret for projektet. Dette er også blevet kritiseret. (bilag 3-142+198) Ved at placere ledelsen af projektet hos
Side 32 af 91
leverandøren besværliggør det muligheden for at kontrollere dem. Samtidig bliver det i BCG
rapporten fra 2010 oplyst at der under estimeringen af projektet har været tilfælde hvor der har
været en asymmetrisk information imellem ScanJour og CSC. Dette igennem at CSC havde en stor
viden om det forgående system POLSAS som dannede grundlag for flere af kravene. Imens havde
ScanJour en dybdegående viden om Captia. (bilag 3-198) Dette betød designfasen blev groft underestimeret. Dermed har det forskudt tidplanen, og resten af projektet.
Et stort forbrug af eksterne forbrugere i form af underleverandører og konsulenter, betyder også
at der er flere parter med en forskellig baggrund der skal kommunikere. Herigennem åbner det
også op for flere muligheder for fejlkommunikation og fejlfortolkninger. Ligeledes er der også flere aktører, som kan have forskellige incitamenter for at arbejde med projektet. Ved at bruge eksterne aktører, skal det også i højere grad forholdes til kontrakter og disses udformning.
Kontrakten risikerer derfor at komme ind som et filter imellem parterne, hvor fokus kan blive på
at kontrakten skal overholdes, i stedet for projektets mål. Dette ses også igennem ledelsen hos
politiet ønskede at indføre 1:1 kravene fra POLSAS for at sikre arbejdsgange blev implementeret
korrekt. På denne måde blev styringen fokuseret på at opfylde kontrakten, i stedet for at opnå
målet for projektet. Dermed er der opstået et kompromis i forhold til potentielle resultat af projektet, for at sikre et håndgribeligt styringsgrundlag. Samtidig betyder et højt forbrug af eksterne
partnere og de tilhørende kontrakter, at der ikke nødvendigvis er sammenhæng mellem kontrakterne. Ved POLSAG var der en kontrakt for selve POLSAG systemet, og en anden kontrakt for driften af testmiljørene. Begge med CSC som modpart, og begge kontrakter gældende selvom
testmiljøerne ikke kunne bruges grundet forsinkelser med hovedsystemet. (bilag 3-125) Kontrakterne har også haft andre uhensigtsmæssigheder. Herunder var der i kontakten krav til hvor
længe der måtte gå fra en fejl blev opdaget til udbedringen skulle starte. (bilag 3-145-7) Et krav
der som udgangspunkt ikke tilgodeser Rigspolitiet som køber og projektejer, da den i praksis ikke har effekt på hvor længe der går fra en fejl bliver opdaget til den bliver rettet. Leverandøren
kan derfor mangle incitament for at gennemføre rettelserne fuldstændigt.
Ved valget af leverandør blev CSC valgt på trods af en lidt dyrere pris, fordi de havde kendskab til
politiet, og flere af de systemer politiet brugte. På trods af dette formåede politiet ikke at få skre-
Side 33 af 91
vet krav ind i kravspecifikationen, der kunne binde dem til performancekrav som også gældte de
randsystemer, og ikke kun POLSAG isoleret.(bilag 3-162)
Selvom politiet i vid udstrækning har gjort brug af konsulenter, er det ikke nødvendigvis negativt.
Forklaringen skal findes i at politiet ikke har haft de nødvendige ressourcer og kompetencer selv.
Derfor kan det argumenteres for at valget af konsulenter har været det bedste af to onder. Af de
omkostninger der er gået til konsulenter der ca. 61% gået til tekniske specialister og administrativ støtte, ca. 37% til projektledelse, og ca. 2 % juridisk bistand. (bilag 3 -142) Heraf er det specielt den del der er gået til projektledelsen, som kan kritiseres og har haft den mest negative effekt
på projektet.
8.1.2.5 projekt team
Internt i Rigspolitiets IT & Tele afdeling bestod projektteamet i 2009 af 43 medarbejdere. Og
Samlet set var der på det tispunkt brugt 185 årsværk, fordelt ud over 4,5 år. Hvilket giver et gennemsnit på ca. 41 ansatte per år. (bilag 3-184) Det er ikke oplyst hvordan projekt teamet er blevet sammensat. Herunder heller ikke hvordan den interne rollefordeling har været i gruppen,
hvor det er en fordel med veldefinerede roller. Det er oplyst at der har været problemer med at
rekruttere kvalificeret arbejdskraft kan det også have været tilfælde for projektgruppen(bilag 3202). Samtidig er det først fem år efter projektets starter at der blev nedsat et projektkontor. (bilag 3-195+198) I projekter er det en vigtig faktor at medlemmerne i gruppen kender hinanden og
har erfaringer med at arbejde sammen. Som en nydannet gruppe, som starter midt i et projekt, er
denne kendskab til hinanden ikke tilstede, hvilket må påvirke arbejdet i gruppen, og betyde at effektiviteten ikke har været optimal fra start. Herunder kan det have givet problemer med kommunikationen internt i gruppen. Ligeledes er det heller ikke sikkert at der er opstået en fuld
forståelse i gruppen for hvordan de mere uformelle roller er fordelt og hertil hørende ansvar.
8.1.2.6 Den sociale interaktion
En af de vigtige dele i et projekt er kommunikationen imellem de parter der deltager i projektet.
Dette skyldes at der skal være en gensidig tro på, at de forskellige parter arbejder sammen om
det samme mål. Det er ikke kun ensretningen af mål der er vigtig, men også muligheden for at
forventningsafstemme der er vigtig. Det er vigtigt at brugerne har en tro på at det tekniske personale de arbejder sammen med, har forstået deres arbejdsprocesser og krav. Herunder er det
Side 34 af 91
vigtigt at de forskellige personer kender deres roller i projektet. Medbrug af en standard metode
bliver det nemmere at definere rollerne og dermed gøre dem klare for brugerne. Hvilket også er
en af grundene til at der bliver foreslået i højre grad at gøre brug af en bestemt projektmodel fra
staten. Dette virker ikke til at være tilfældet.
I de kilder der er til rådighed er der flere af dem der peger på at der har været problemer med
kommunikationen. Fra rigsrevisionen bliver det kritiseret at leverandørerne ikke havde en god
nok forståelse for politiets arbejdsgange. En forståelse af den kontekst kravet skulle forstås ville
kunne have dannet grundlag for en anden fortolkning af kravet og dermed en bedre implementering af det enkelte krav i løsningen.(bilag 3-90)
Ikke kun imellem Politiet og leverandørerne har der været problemer, men også internt imellem
leverandørerne ScanJour og CSC har der eftersigende været problemer(Hansen 2013). Samtidig
har andre statslige institutioner haft problemer med ScanJour og CSC, efter implementering af
deres Captia-løsning(bilag 3-181). Her er problemerne omkring manglende understøttelse af
sags håndteringen, men specielt helpdesk funktionen gav anledning frustrationer. En frustration
og mistillid der også kan have forplantet sig til justitsministeriet og politiet.
8.1.3 Projektets indhold
En af de vigtigste overordnede faktorer er selve indholdet af projektet. Dette skyldes at det til en
vis omfang danner grundlag for de andre punkter. Det er ligeledes det mest håndgribelige af faktorerne.
8.1.3.1 Projektets karakteristika
I forhold til projektets karakteristika udgøres det af projektets størrelse, kompleksitet, og nyhedsgrad til organisationen. Størrelsen af projektet har været stor, og er ikke blevet delt op i delleveraner, hvilket har betydet at det er kommet til at fremstå større, end hvis det var blevet delt
op. Imedens havde projektet også en høj kompleksitet. En kompleksitet der var en betydende faktor i flere dele af projektet, og var afgørende for den dårlige kodekvalitet, (Bilag 3-33+171) og
problemerne med at rekruttere den nødvendige arbejdskraft. (bilag 3-44) I frohold til nyhedsgraden af projektet i forhold til politiet, var dele af systemets krav bygget over et tidligere system,
som var med til at mindske nyhedsgraden.
Side 35 af 91
8.1.3.2 Projektets mål og omfang
Målene i projektet var en manglende faktor. Specielt i form af konkrete og målbare mål. (bilag 350) Derfor har det heller ikke været muligt at kommunikere dem ud til organisationen, og til de
parter der har arbejdet med projektet. Samtidig er det også svært at tilpasse ikke konkrete mål
med organisationens strategi. I forhold til kravene er de blevet ændret undervejs, men ikke i et
omfang som må antages at overstige hvad der er forventeligt eller håndterbart. Selve omfanget af
projektet blev ændret ved at fjerne selve integrationslaget.
8.1.3.3 Ressourcer
Ressourcer deles op i økonomiske, tidsmæssige og personalemæssige ressourcer. I forhold til de
økonomiske, har de skulle dækkes af offentlige midler. Det har betydet at der potentielt har været
mulighed for at tilføre projektet store økonomiske ressourcer. Derfor kan projektets fiasko ikke
nødvendigvis tilskrives dette, selvom økonomien spillede ind i forklaringen på nedlukningen af
projektet. (bilag 3-203) En af de faktorer der har haft betydning for projektet, har været den form
for allokering der har været af personel. Grundet budgetregler og interne udregninger af omkostninger hos offentlige myndigheder og hos politiet, har der været forskel på konteringen af
omkostningerne til medarbejdere, alt efter om det har været internt i politiet, eller om det har
været eksterne konsulenter. (bilag 3-66+142) Disse regler har betydet at det har været mere fordelagtigt for politiet at gøre brug af eksterne konsulenter eller leverandører, i stedet for interne
ressourcer. Når det kommer til de tidsmæssige ressourcer i forbindelse med udviklingen har der
her været muligt at udskydedeadlines i løbes af projektet. Der her derfor ikke været en deadline
som har udgjort en kritisk faktor for projektet, hvor den er blevet vægtet betydeligt højere end
udviklingsprojektet. Selvom udviklingstiden ikke har været den kritiske faktor, her der været tilfælde hvor der kan argumenteres for at påbegyndelsen af implementeringen er blevet forceret.
Dette kan dog henvises til kontraktlige forhold, i stedet for manglende ressourcer.
Det punkt hvor der har været den største ressourcemangel, har været på personalesiden. Her har
der været problemer med at rekruttere medarbejdere med de rigtige ressourcer. (bilag 312+202) Derfor har det også haft en betydning. En betydning hvor de har været afhængige af få
personer, og hvor det at miste enkelte nøglemedarbejdere har kunnet betyde både udsættelser
og økonomiske fordyrelser.
Side 36 af 91
8.1.3.4 Teknologi
Teknologifaktoren har haft afgørende betydning for POLSAG. Her har det været den store andel
af modifikation og nyudvikling af Captia været påkrævet, for at kunne leve op til de krav der blev
sat. Teknologen der blev brugt til at udvikle var ikke uprøvede teknologier, men i stedet blev der
brugt flere forskellige kodesprog. (bilag 3-28+33+58) Derfor blev det yderligere kompliceret at
udvikle systemet. Samtidig med de mange kodesprog, skulle systemet også integreres med flere
eksisterende systemer. Den teknologiske løsning har derfor været med til at påvirke systemet
negativt på flere punkter.
8.1.4 Udviklingsprocessen
For at lave en dybdegående analyse af udviklingsprocessen i POLSAG skal der også her gøres
brug af kilderne. Derfor bliver analysen lavet ud fra de premisser kilderne tillader. Udviklingsprocessen har betydning for den måde hvorpå projektet forløber, og i hvilket omfang de forskellige parter er blevet inddraget, samt hvordan de er blevet det og i hvilken rækkefølge. Samtidig er
det også sigende at se på hvilket omfang både de bevidste og ubevidste valg har betydning for
projektet.
8.1.4.1 Valg af krav
Et af de steder hvor projektet er blevet kritiseret er specielt omkring de krav der blev sat, og specielt 1:1 kravene fra POLSAS har været under kritik. (bilag 3-109) Kravene udgør et yderst vigtigt
punkt i udviklingsprocessen. Det er dem systemet skal bygges op omkring, og kan også bruges
som et værktøj til at styre kontrakten. Det er også kravene der skal støtte op omkring de arbejdsprocesser systemet senere skal understøtte. Derfor er det også initialt at kravene udformes på
bedst mulige måde. Når en del af kravene bliver stillet ved at kopiere dem fra funktionaliteten fra
et tidligere system, bliver de nye arbejdsgange ikke tænkt ind i processen. Krav der ikke er lavet
med de kommende arbejdsprocesser for øje, vil ikke støtte op omkring dem efter implementeringen af systemet. Hvilket ville have haft betydning hvis implementeringen af POLSAG var blevet
fuldtud gennemført. For POLSAG kunne det have betydet at der skulle udvikles yderligere på systemet for at det ville have passet til de ændrede arbejdsgange.
Ved at gennemføre 1:1 kravene til POLSAG betød det også at der skulle udvikles betydeligt på det
Captia. Op mod 80% af det endelige system var nyudviklet i forhold til Captia. En nyudvikling der
Side 37 af 91
betød at udviklingen blev meget kompliceret. (bilag 3-1) Komplikationer der havde væsentlig betydning for den samlede udvikling, og herunder også krav til de kvalifikationer medarbejderne
skulle besidde. Med krav fra POLSAS blev brugerne også inddraget, for at redegøre for hvordan
funktionaliteten blev brugt. En brugerinddragelse der blotlagde uenigheder imellem brugerne
om hvordan funktionerne blev brugt. Uenigheder der ikke har været med til at køre POLSAS kravene mere tydelige. Kravene til systemet blev også ændret undervejs i projektet, ikke som et resultat af at der blev foretaget iterationer i løbet af udviklingsprocessen, men fordi at der sket
ændringer i omverdenen.
Til et system bliver der også sat krav til teknikken. Ved POLSAG er det specielt svartiderne der
endte med at udgøre et problem. Her blev der ikke sat kvantitative krav til den samlede svartid,
men udelukkende til svartiderne internt i systemet. Dette skyldtes at leverandøren ikke ønskede
at opfylde sådan et krav. (bilag 3-162)
8.1.4.2 Projektledelse
Projektledelsen skal stå for styringen af de ressourcer, som der skal bruges i forbindelse med
gennemførelsen af projektet. Det inkludere også at bestemme projektets, størrelse, mål og have
ansvaret for risikovurderingen. Omkring dele af et som projektledelsen har ansvaret for ligger
derfor hos politikkerne. Det er dem der er med til at bestemme i hvilken grad tilføjes økonomiske
ressourcer. Ligeledes var det politikkerne, der var med til at tage initiativ til at beslutte at der
skulle gennemføres en systemmodernisering. (Justistsministeriet 2003-04)
Ved at lave en grunddig planlægning af projektet sikre man at omkostningerne og ressourcerne
bliver styrret bedre og minimere risikoen for større udsving. Men Det har ikke en bevislig effekt
for muligheden for gennemførelse. I POLSAG blev ressourcerne og tidsplanen forsøgt styret, hvilket også betød at der måtte laves en re-planlægning både af tidsplanene, men også budgettet.
Dette efter at begge dele skred. Omkring risikostyreingen blev den også foretaget og oplyst i de
forskellige aktstykker under forløbet. På trods af at der blev lavet en risikovurdering, blev der ikke lavet nogen plan for de afværgehandlinger, som kunne laves for enten at mindske risikoen, eller for at imødekomme formodede ulemper risiciene dækkede over. Herunder helle ikke en
vurdering af de økonomiske konsekvenser.
Side 38 af 91
Projektledelsen har ansvaret for at lede projektet i en retning hvor de opnåede mål blev nået.
Men for POLSAG var der ikke opsatte nogen målbare mål, og det vigtigste redskab der blev styret
efter var derfor gennemførelsen af kontrakten.
8.1.4.3 Brug af standardmetode
Det er ikke oplyst om udviklingen af POLSAG har fulgt en standardiseret metode. Derfor kan det
heller ikke analyseres på hvorledes det har haft betydning for POLSAG som projekt. Hvis man i
stedet kigger på nogen af de problemer der har været med POLSAG, er det problemer som teoretisk set ville være blevet forbedret hvis der var blevet fulgt en standard udviklingsmetode, eller
den metode de havde brugt var blevet fulgt mere nøjagtigt. Det bliver dog nævnt at de i stor udstrækning har gjort brug af det der beskrives som gængse tekstbogsmetoder til at udarbejde system designet. Metoderne blev dog ikke fulgt helt korrekt, og havde mangler i forbindelse med
udviklingen af målprocesser, som manglende konkrethed. (bilag 3-50)
8.1.4.4 Brugerdeltagelse
Igennem brugerdeltagelsen er det muligt at opnå fordele der kan styrke mulighederne for et succesfuldt projekt. Det kommer an på hvorledes brugerne bliver inddraget og hvornår i projektets
forløb. Forskellige interessenter og herunder også brugerne blev inddraget i udarbejdelsen af systemdesignet. (bilag 3-164) Ved at inddrage brugerne opnår de en viden om de arbejdsgange systemet skal understøtte. På trods af inddragelsen af brugerne, holdt de stadig fast i POLSAS
kravene. Funktioner der med brugerinddragelsen, ikke kunne opnås sikkerhed omkring brugen
af. Inddragelsen af brugerne fulgte ellers gængse tekstbogsmetoder. Det er muligt at det er ønsket om POLSAS kravene, der skulle fungere som sikkerhedsnet for at bibeholde en nødvendig
funktionalitet. Og manglen på konkrete målprocesser, der har været med til at modvirke den positive effekt brugerinddragelsen skulle have haft.
8.1.4.5 Brugertræning
Et af de punkter replanlægingen af implementeringen medførte inden projektet blev lukket, var
at der skulle bruges længere tid på at træne brugerne. Det har derfor også været en prioritet at
forhøje træningsniveauet efter pilotdriften på Bornholm. Her blev det fundet at uddannelsen og
træningen af brugerne var mangelfuld. (bilag 3-154) Hvis brugerne ikke opnår de nødvendige
kompetencer, er de heller ikke i stand til at bruge systemet fuldt ud og på den mest hensigtsmæsSide 39 af 91
sige måde. Samtidig kan der under en implementeringsfase var en forel med veluddannede brugere da de i højere grad har mulighed for at arbejde omkring de fejl der måtte opstå, og kunne
beskrive fejlende bedre.
Den bedre brugertræning betyder ikke nødvendigvis at selve implementeringen går nemmere og
der er større mulighed for succes, men i stedet er det omkring muligheden for at opnå de opstillede mål der bliver nemmere såfremt træningen er på et tilstrækkeligt niveau. POLSAG blev aldrig fuldtud implementeret, og det er derfor ikke den manglende brugertræning der kan
tilskrives den manglende succes.
8.1.4.6 Forandringsledelse
I forhold til forandringsleden er det ikke det vigtigste punkt for POLSAG. Dette skyldes at systemet aldrig blev fuldt ud implementeret, og det derfor ikke nåede at have en væsentlig effekt på
udfaldet. I det materiale der er til rådighed tegner der sig et billede af at det ikke har været forandringsledelsen der har været fokus på. Dette kan skyldes at projektet blev set som et infrastrukturs projekt, og ikke et projekt der skulle optimere arbejdsgangene. Herunder blev der ikke
lavet konkrete målprocesser. (bilag 3-50) Og dermed konkrete mål der senere ville kunne blive
brugt til at måle succes af projektet. Der blev også oplyst at medarbejderne stadig forventede at
ville gøre brug af at arbejde med sagerne i fysisk form. (bilag 3-48) Her formodes det, at et nyt
system ville kunne have minimeret behovet for at arbejde med sagerne i fysiskform. Og have
gjort det på en mere effektiv måde.
8.1.5 Institutionel kontekst
Den sammenhæng som systemet skal udvikles i, og tages i brug i har en vigtig indflydelse på projektet. Specielt omkring POLSAG kan der være faktorer der har haft stor indvirkning. Den institutionelle kontekst, påvirker systemet udvikling og alle de andre faktorer der spiller ind i projektet.
8.1.5.1 Interne faktorer
I organisationen er det vigtigt at se på den kultur der er inden for denne. Politiet har generelt være bagud på it-fonten. (bilag 3-194+199) Hvilket kan være en indikator på at it kundskaberne hos
medarbejderne ikke er ret gode, ligesom der ikke har været en kultur for løbende at inddrage nye
teknologier og muligheder. Derfor kan det have påvirket forløbet omkring POLSAG i en negativ
Side 40 af 91
retning. Dette både igennem de manglende kompetencer til at designe og projektlede itprojekter. Kompetencer der spiller ind i flere af de andre faktorer, og er særdeles vigtige. Sammen med den it-modernisering blev der også igangsat andre mindre projekter, herunder ekstern
e-mail og fiberring i København. Projekter der alle blev gennemført. Dette betyder at politiet i et
vist omfang har haft succes med projekter. Det vil derfor være nødvendigt at sondre imellem projekternes størrelse. Ligeledes betyder tidligere succeser ikke nødvendigvis at kulturen har ændret sig på en måde hvorpå at fremtidig succes er sikker. Det er derfor i højere grad en ulempe at
opnå en fiasko, end det er en fordel at opnå en succes. Om andre offentlige institutioner opfattes
som eksterne eller interne faktorer afhænger af hvordan organisationen defneres. Men det offentlige har igennem en årrække været ramt af at flere forskellige it projekter er endt som fiaskoer. (bilag 3-203+204) Dette kan betyde at der opstår en kultur hvor fiaskoerne bliver forventet.
Dette er med til at virke yderst negativt for succesmulighederne når der igangsættes nye projekter.
Historien internt i organisationen er vigtig. Både når det kommer til de historie it projekter der er
blevet gennemført, og de systemer som der historisk har været i organisationen. For politiet var
der hos politiet en del systemer i forvejen. Systemer som ikke skulle erstattes men som skulle integreres med det nye POLSAG. En integration der betød at de til at starte med planlagde et integrationslag, en del af projektet der senere blev udskudt. Samtidig var den store andel af
integration med til at komplicere projektet yderligere, ligesom at det var en af de væsentligste
grunde til de lange svartider.
8.1.5.2 Eksterne faktorer
Projektet er også afhængigt af omgivelserne. Ved POLSAG er en af de problemer der er blevet
nævnt at det ikke har været muligt a rekruttere personale med de rigtige kompetencer. (bilag 312+202) En omstændighed der har påvirket flere af de andre faktorer betydeligt.
POLSAG var et projekt der skulle gennemføres i en offentlig organisation, og med den samlede
projektsum, blev den derfor også interessant for medierne. Specielt efter at projektet begyndte at
gå i en forkert retning. Et fokus der kan have givet et øget pres på projektet, hvor fokus kan have
flyttet sig over imod at fiaskoen kom til at fremstå mindre, og til en hvis grad holde sin ryg fri, i
stedet for at gemmeføre projektet bedre. Et af de steder hvor de gjorde sig gældende var igennem
Side 41 af 91
den ansvarsfraskrivelse der var imellem politiet og leverandørerne, som foregik igennem medierne. (bilag 3-187) I stedet ville det have givet et mere gunsigt miljø for samarbejde mellem parterne hvis det der ikke havde været samme fokus og pres fra medierne. Ikke kun medierne har
haft fokus på projektet, men også folketinget. Folketinget vedtog også planener om it- modernisering i politiet. Den modernisering der som POLSAG skulle være en del af.
Eksternt er projektet også ramt af at det foregår i en offentlig organisation, hvoraf der skal følges
andre regler end hvis det havde været i en virksomhed. Herunder har de været pålagt at gøre
brug af en bestemt kontrakt type. En type som ikke nødvendigvis har været mest passende til
projektet.
8.2 Bonnerup rapporten
Ved starten på POLSAG projektet var Bonnerup rapporten allerede udkommet, og derfor er det
relevant at se på i hvilket omfang rådene fra rapporten er blevet fulgt. Samtidig er det interessant
at se på hvilken effekt det har haft at de enkelte råd enten er blevet fuldt, eller ikke er blevet det.
8.2.1 Rammerne for statslige it-projekter
Et af rådene var, at ambitionerne skulle dæmpes omkring udviklingen af egne systemer, og i stedet skulle der i større omfang gøres brug af standardsystemer og komponenter. Dette råd blev til
dels fulgt i POLSAG med valget af et standardsystem. Selvom rådet blev fulgt, skulle der stadig
udvikles betydeligt mere på systemet, end hvad der kan betragtes som rimelig. Derfor kan det argumenteres for at rådet blev fulgt i teorien, men ikke nødvendigvis i ånden. En fejltolkning der
betød at systemet blev væsentligt kompliceret, hvilket også medførte at der opstod problemer
med rekrutteringen af medarbejder, og større afhængighed af nøglepersonale.
Selvom der er blevet valgt en anden kontraktform en dem der bliver nævnt i Bonnerup rapporten, har denne stadig været udsat for kritik. Hvor et af problemerne stadig har været den manglende fleksibilitet. En fleksibilitet der har været med til at give problemer i forbindelse med
udviklingen af systemet, men også har betydet at der har været indført negative incitamenter i
stedet for positive. I forbindelse med POLSAG var det hovedsageligt konsulenter der blev brugt,
når der skulle bruges kompetencer som ikke var til stede internt hos politiet. Samtidig måtte der
også betales en overpris for systemet, en overpris som ikke nødvendigvis ville være nødvendig
Side 42 af 91
hvis staten havde stået som en samlet køber, og dermed havde haft en bedre forhandlingsposition. (bilag 3-6) Dette er specielt relevant, da CSC og staten har flere aftaler.
Det kan diskuteres i hvilket omfang at forståelsen for it-projekter er tilstedet hos den politiske
ledelse. Fra politisk side blev projektet ikke stoppet selvom der kom mindre budgetoverskridelser, hvilket kan være et tegn på at de har forstået at it projekters omfang ikke nødvendigvis kendes fra starten.
8.2.2 Den offentlige organisation
Der blev givet flere råd omkring en offentlige organisation i Bonnerup rapporten, herunder at
projektet skulle have en stærk forankring i den øverste ledelse. For POLSAG var dette ikke tilfældet. Projektledelsen blev overdraget til CSC. Det blev foreslået at der skal knyttes positive karrieremæssige muligheder ved at have ansvaret for et succesfuldt projekt. Det er ikke muligt at
fastslå hvilken belønning ledelsen ville have fået hvis POSLAG havde været en succes. Det kan i
stedet konstateres at Rigspolitiets it-chef blev afskediget i 2012. (bilag 3-185+186) Det kan fastslås at der blev føjet negative karrieremæssige incitamenter til jobbet.
Et af de steder hvor der er blevet fejlet omkring projektet har været den manglende beskrivelse
af projektet i form af et prospekt og forholdende omkring projektet inden starten. Herunder har
der specielt manglede konkrete mål for projektet, som senere ville kunne måles. Mål som man
også ville kunne sætte i forhold til de aktiviteter, der skulle udføres under projektet, og danne
grundlag for de valg der skal træffes. Samtidig blev der heller ikke lavet en grundig cost benefit
analyse. Den blev først lavet i en af de senere konsulentrapporter. Dette kan skyldes at systemet
blev set som et infrastrukturprojekt og at der derfor ikke ville være målbare økonomiske fordele
ved projektet. Selvom der løbende blev lavet en risikovurdering af projektet var den ikke fyldestgøende, og manglede at der blev lavet en vurdering af de potentielle omkostninger, og planlagte
afværgehandlinger. En grundig risikovurdering og en cost benefit analyse ville have betydet at
projektet ville være blevet stoppet på et tidligere tidspunkt, og dermed ville omkostningerne ikke
have nået det niveau som var tilfældet.
Et af de råd som delvist blev fulgt var, at projektet skulle deles op i delleverancer. Dette var tilfældet i for de såkaldte udviklingspakker. Disse kom til senere efterhånden som flere krav blev
afdækket. Selvom projektet blev delt op i delleverancer, udgjorde de ikke en størrelse der var lille
Side 43 af 91
nok til at leve op til rådet. Her var specielt den første leverancer af en for stor størrelse. En størrelse der har været med til a gøre projektet unødigt kompliceret. Ligeledes har den store og dermed sene leverance betydet at en stor del af testningen blev lavet sent, og der har ikke været de
samme muligheder for at genere erfaring løbende.
8.2.3 Samspil med leverandører og konsulenter
I sammenspillet mellem leverandørerne og de brugte konsulenter, er der ikke tegn på at der blev
gjort brug af erfaringer omkring disse på tværs af statslige organisationer. Dette vises ved at CSC
bliver valgt, selvom der fra statens side har været problemer med flere af de projekter hvor staten har brugt CSC. (bilag 3-188-191) I forhold til erfaringerne omkring CSC havde rigspolitiet inden gjort sine egne, igennem samarbejde med CSC. Derfor er det tvivlsom hvorvidt en
tværgående statslig erfaringsdeling ville have gjort en forskel på dette punkt. I forbindelse med
forholdet til leverandøren udgør kontrakten en væsentlig faktor. Her anbefaler Bonnerup rapporten at der bliver gjort brug af mere fleksible kontraktmodeller, hvor der også bliver gjort brug af
positive incitamentsformer. Dette har ikke været tilfældet med POLSAG. Punktet er derfor ikke
blevet fulgt. Den manglende fleksibilitet kan skyldes EU regler, imens at det bliver nemmere at
indføre positive incitamenter, når der i projektet er defineret klare konkrete mål.
8.3 Professionalisering af arbejdet med IT-projekter i staten
I forhold til de nye råd til udvikling af projekter i staten, er det mest relevant at fokusere på de
råd der er kommet til udover Bonnerup rapporten. Dermed er det muligt at se på om de råd, som
er kommet til efterfølgende, ville have haft betydning for POLSAG, såfremt de var blevet fulgt. Det
sted hvor finansministeriet adskiller sig væsensligt fra Bonnerup, er forslaget til oprettelsen af
det fælles projektråd. Et af de steder hvor det det ville have gjort en forskel var i forbindelse med
businesscasen. Her er det specielt de nye tiltag er i form af ønsket om at lave en business case på
de projekter der har en projektsum på over 10 mio kr. Dette ville have været gældende for
POLSAG. Derfor ville business casen skulle sendes ind til statens projektråd. På denne måde ville
det have været sikret at businesscasen var blevet lavet, og ville også have endt med at have en
bedre kvalitet. Med en gennemarbejdet business case, ville den i højere grad kunne udfylde et
brugbart værktøj i forbindelse med styringen af projektet. Samtidig ville projektrådet også have
Side 44 af 91
betydet at der ville være lavet et eksternt review af risikovurderingen. En risikovurdering der ikke var udarbejdet tilfredsstillende, og derfor endte med at have betydning for projektet. Med udsigten til at risikovurderingen skulle udsættes for review, ville have dannet grundlag for at have
brugt mere tid på denne aktivitet i projektet. Ved at lave risikovurderingen, opnås der også mulighed for at planlægge nødvendige afværgehandlinger såfremt risikoen finder sted, eller aktivt at
modarbejde dem inden. Ligeledes kan de potentielle økonomiske konsekvenser indregnes. Samtidig vil de med projektrådet også give vejledning på flere punkter herunder budgetteringen.
Hvilket kunne have gjort en forskel for POLSAG, da økonomien var en af årsagerne til at projektet
blev lukket. De store overskridelser kan ikke nødvendigvis tilbageføres til budgettereingen alene,
men til bagvedliggende faktorer.
Et af de steder hvor finansministeriets råd, og oprettelsen af et projektråd ville have gjort en forskel, ville have været i den form for kompetence og erfaringsindsamling som skal foregår indenfor staten. Både i form af at samle erfaringer for de igangsatte projekter, men også indsatsen der
laves for at fastholde medarbejdere med de rigtige kompetencer inden for projektledelse.
POLSAG led af manglende dokumentering, en manglende dokumentering, som ikke ville kunne
have ændret POLSAG, men erfaringsindsamling fra tidligere projekter ville kunne have haft en
positiv betydning for gennemførelsen af POLSAG. Hvis den øgede dokumenterings som er et biprodukt af den øgede erfaringsindsamling havde været til stede, sammenholdt med en klar udviklingsmetode, have påtvunget at flere aktiviteter og handlinger var blevet gennemført, og
dermed også vigtige overvejelser omkring projektet. Såfremt de i højere grad havde dokumenteret flere aspekter, ville det også have forenklet og forbedret mulighederne for at viderekommunikere indholdet og valgene omkring projektet.
Omkring kompetencefastholdelsen ville det have betydet at POLSAG ikke i samme omfang havde
haft brug for at overlade projektstyringen til CSC. En overladning der havde en negativ betydning
for forløbet af projektet. Ved at fastholde medarbejder med erfaring og kompetencer, bliver det
nemmere at fastholde de nødvendige medarbejdere, hvilket var en mangel i POLSAG. Derfor havde der ikke været de samme rekrutteringsproblemer, som prægede projektet.
Finansministeriet foreslår at der i staten skal bruges en fælles projektmodel. En klar projektmodel ville teoretisk set have forbedret mulighederne for at få gennemført et succesfuldt projekt.
Side 45 af 91
Samtidig ville det også støtte op omkring kompetenceudvikling, hvis det udelukkende var en enkelt model der blev brugt i staten.
Forholdet til leverandørerne bliver der også rådgivet omkring. Her er de største afvigelser i forhold til Bonnerup, den løbende evaluering af leverandørerne. Dette skal gøres for at der ikke opstår kommunikation og relations problemer som kan være til skade for projektet. Dette ville have
haft betydning for POLSAG. Her opstod der problemer mellem parterne.
8.4 Delkonklusion
Igennem delkonklusionen vil der blive samlet op på de problemstillinger som er blevet udledt.
Dette gøres for at samle op på de skabe overblik over de konklusioner der er udarbejdet over de
forskellige problemstillinger i løbet af analysen
8.4.1 Risikostyrring
Flere af de faktorer der er analyseret har forholdt sig til risikostyringen. Herunder har det vist sig
at den manglende risikostyring har haft en klar betydning for projektet. De vigtigste af de faktorer hvor risikostyringen er blevet berører, har været under udviklingsprocessen, hvor topledelsen skulle have brugt risikovurderingen som et vigtigt redskab. Samtidig kan risikostyringen
også påvirke ressourceforbruget, da en risiko også kan genere et ressourceforbrug, som skal
dækkes. I forhold til Bonnerup rapporten, bliver risikostyringen også nævnt, men det er først
igennem finansministeriets rapport at der bliver givet mere målrettede råd. Her er der specifikt
råd om bedre risikovurdering og en bedre business case som en sådan risikovurdering ligeledes
må påvirke. Derfor ville de nye tiltag have sikret at risikovurderingen var blevet bedre og mere
brugbar. En brugbarhed som ville kunne have sikret projektet en øget mulighed for succes.
8.4.2 Kontrakten
Selve kontrakten danner grundlag for samarbejdet med leverandørerne. Den påvirker derfor flere af de faktorer der er med til at påvirke projektet. Den faktor hvor kontrakten har haft den største betydning har været i forholdet til leverandørerne og den måde hvorpå de har ageret. Her har
den sat rammerne for samarbejdet, og dermed og de prioriteter som leverandørerne har haft. De
største problemer der har været med kontrakten har været de hovedsageligt negative kontraktincitamenter, og den stramme form. Dermed har kontrakten fået en central rolle i styringen af
Side 46 af 91
projektet, hvor der kan argumenteres for at den har fungeret som en hindring, både i forhold til
et godt forhold til leverandøren, men også i forhold til, at holde fokus på målene for projektet. I
forhold til Bonnerup rapporten blev der ikke fulgt rådet om at undgå standardkontrakter, hvilket
kunne have hindret at kontrakten, var blevet en hindring for projektet. Ligeledes havde det også
været muligt at følge en af de andre råd fra Bonnerup rapporten, hvor det anbefales at bruge mere fleksible kontrakter.
8.4.3 Kravspecifikationen
Et af de steder der særlig har kunnet kritiseret har været kravspecifikationen, som danner grundlag for systemet. Denne har også påvirket flere af de faktorer der har været med til at påvirke
projektet. Specielt under udviklingsprocessen, hvor udvælgelsen af krav er en vigtig faktor. Her
har problemet været, at udvælgelsen af krav har været målrettet en form for rykdækning i forhold til det tidligere system, i stedet for at fokusere på nogle målbare mål. Det har ikke kun været
de funktionelle krav der udgjorde et problem for projektet, men også de tekniske krav, hvor specielt end-to-end fulde svartider har givet problemer. Den omfattende kravspecifikation, har også
haft betydning for forholdet til leverandøren, hvor den ligesom kontrakten har stået i vejen for et
mere gunstigt forhold imellem parterne. I forhold til Bonnerup rapporten bliver der ikke rådet
direkte omkring kravspecifikationen. Dette er mere eksplicit i finansministeriets rapport, hvor
det bliver anbefalet at lave mindre omfattende kravspecifikationer. Derfor kunne det have modvirket nogen af de negative effekter som den omfattende kravspecifikation havde, såfremt dette
råd var blevet fremsat tidligere, og var blevet fulgt.
8.4.4 Projektstyringen
Projektstyringen er vigtigt i et projekt og også i POLSAG. Det er ligeledes en af de faktorer der påvirker projektet på flere måder. I POLSAG blev ledelsen af projektet overdraget til CSC hvilket var
problematisk. Ikke fordi CSC ikke havde de nødvendige ressourcer, men fordi at styringen af projektet ideal set ligger hos projektejeren, da det også er dem der oplever de fremtidige fordele ved
projektet. Dermed følger incitamenterne ikke med ansvaret, og anbefalede positive incitamenter
mangler derfor også hos de personer der har stået for ansvaret for styringen. Flere af de værktøjer, som kunne være brugt til at styre projektet har manglet, i form af værktøjer som konkrete
mål og risikovurdering.
Side 47 af 91
Specielt rapporten fra finansministeriet er kommet med anbefalinger til tiltag, som ville kunne
forbedre mulighederne for en bedre styring af de offentlige projekter, og dermed også tiltag som
ville have kunnet forbedre POLSAGs muligheder for succes. Her er det specielt de ressourcer inden for projektledelse, der bliver stillet til rådighed, ligesom de øgede krav til dokumentering og
kvaliteten af grundlaget for projektet.
9 Forslag til ændringer
For at have øget mulighederne kunne de retrospektivt have gjort brug af de senere udarbejdede
råd fra finansministeriet. Selvom rådene er udarbejdet fra finansministeriet er det ikke sikkert de
er tilstrækkelige, fordi de ikke nødvendigvis bliver fulgt, eller er realistiske. Samtidig er det ikke
sikkert at rådende fra finansministeriet er dækkende, eller har det rette fokus. Samtidig kan dele
af problemerne i forhold til problemerne tilbageskrives til nogen af de forhold som gør sig specielt gældende for offentlige institutioner. Det er som udgangspunkt mest relevant at kigge på de
problemer som har været med POLSAG for at fine en måde at løse sidde på, i stedet for at komme
med mere generelle forslag til ændringer.
9.1.1 Projektstyringen
I forhold til projektstyringen udgjorde dette et problem. Det største problem var outsourcingen
af projektstyringen til CSC. Hvilket skyldtes de manglende kompetencer hos rigspolitiet. Derfor
giver det også god mening at lave en ordning hvor staten fastholder egne projektledere indenfor
staten. Således bliver der muligt at benytte dem når det nødvendigt. De enkelte offentlige institutioner, gennemføre ikke projekter af en størrelse hvori det kan retfærdiggøres at fastansætte de
nødvendige kompetencer. Samtidig bliver opgørelsen af de omkostninger der bruges til at ansætte de nødvendige kompetencer opgjort på forskellige måder alt efter medarbejdernes ansættelsesforhold. Dette er i stedet et økonomistyringsproblem. Det kan derfor i højere grad isolere
samtlige omkostninger til projektet og opgøre dem på en mere hensigtsmæssigmåde, hvor projektet bliver isoleret fra den daglige drift. Dette gør det nemmere at styre ressourceforbrugt i forbindelse med projektet og sikre at økonomien omkring den daglige drift ikke bliver påvirket.
Samtidig vil anbefalingerne omkring styringen fra finansministeriet også kunne være fordelagti-
Side 48 af 91
ge, da de sikre en bedre dokumentation. En dokumentation der sikre at vigtige styringsmæssige
aktiviteter bliver gennemført, på en fornuftig og fyldestgørende måde.
9.1.2 Kravspecifikationen
Omkring kravspecifikationen har problemet været at den har været for omfattende, og der er
blevet brugt krav fra POLSAS, som ikke nødvendigvis har bidraget positivt til systemet. Derfor vil
det give mening af følge rådet om mindre omfangsrige kravspecifikationer. Som udgangspunkt er
det et målbart mål, som ville have positiv effekt på projekterne. Når det kommer til at mindske
størrelsen af kravspecifikationerne, er det i stedet vigtigere at der tilgængeligøres metoder hvorpå at kravspecifikationerne bliver mindre. Ligeledes skal der være større fokus på kravene skal
relatere sig de mål der skal sættes op for projektet og systemet. Herunder skal de tekniske krav i
højere grad gøres konkrete og målbare, og gøres på en måde hvorpå kravene forholder sig til det
faktiske brug, og dermed er mere brugernære.
9.1.3 Kontrakten
Kontrakterne skal også laves om, og anbefalingerne omkring kontrakter med en mere positiv incitamentsstruktur skal efterleves. Her skal det specielt være på en måde hvorpå at de mål der
bliver sat for leverandører bliver belønnet, og i højere grad sammenkobles med faktiske leveringer, og leveringerne som er værdiskabende for køberen. Samtidig er et vigtigt at kontrakten ikke
bliver en forhindring for et positivt og konstruktivt arbejdsforhold imellem partnerne. Kontrakten skal ikke være den primære styringsværkstøj for partnerne, men i stedet fungere som en
nødvendighed. I forhold til mulighederne for at ændre radikalt på kontraktforholdende, skal der
tages højde for den lovgivning som staten skal overhole når det kommer til kontrakter af
POLSAGs størrelse. Derfor skal der som finansministeriet anbefaler undersøges i hvilken grad det
er muligt at forøge kommunikationen mellem parterne inden for kontrakten. Men denne anbefaling bør også strækkes til at undersøge i hvilken grad det er muligt at gøre brug af mere fleksible
kontrakter.
9.1.4 Risikostyrring
Selve risikostyringen udgjorde det væsentlige problem for projektet. Der skal derfor laves forbedringer på dette punkt. Finansministeriet har derfor på dette punkt også kommet med brugba-
Side 49 af 91
re anbefalinger om at udarbejde en risikoscore for projekter med en projektsum over 10 mio kr.
Selvom der bliver udarbejdet en risikoscore skal den også bruges aktivt i styringen af projektet.
Både i form af muligheden for at lukke et projekt ned tidligere, eller foretage de foranstaltninger
tidsnok, men også i form af planlægning og handlinger, således at der kan ageres i stedet for at
reagere. Der skal også stilles krav til at de økonomiske konsekvenser, for de risici med højest score bliver udregnet. Derigennem er der mulighed for at vurdere om risici bliver for store i forhold
til den økonomiske gevinst der kan hentes ved en gennemførelse.
Ligeledes skal der stilles krav til at risikovurderingen bliver lavet løbende i projektet. Dette skyldes at risici ikke nødvendigvis er statiske og det er ikke muligt at afdække samtlige risici fra starten af projektet. Det er også et rimeligt krav at der bliver lavet en løbende risikovurdering.
Specielt med projekter af en størrelse som POLSAG.
10Vurdering
Belysningen af POLSAG og dennes forløb har ført til blotlægning af flere problemstillinger som
har kunnet behandles ud fra et teoretisk udgangspunkt ligesom, der omvendt også er fremkommet problemstillinger, er gennemgang af teorien. Flere af de kilder der har været mulig at få adgang til har haft en delvis negativ vægtning i forhold til POLSAG. Derfor kan problemstillingerne
være blevet gjort større en hvad virkeligt har været tilfældet. Derfor er det også muligt at der er
blotlagt problemer med POLSAG, hvor deltager i projektet har handlet mere hensigtsmæssigt end
det er oplyst.
De løsningsforslag som er udarbejdet vil derfor i noget omfang allerede have været brugt i forbindelse med projektet. Selvom anbefalingerne har været fulgt, har de derfor ikke nødvendigvis
haft den ønskede eller forventede effekt på projektet. Samtidig er det vigtigt at der bliver taget
højde for den kompleksitet der er med de mange forskellige faktorer der spiller ind, og deres
indbyrdes relation. En enkelt ændring vil derfor ikke nødvendigvis kunne have ændret på projektets udfald alene, specielt hvis der ikke tages højde for sammenhængen.
Side 50 af 91
10.1.1
Vurderingen af årsagerne til det mislykkedes projekt
Ved POLSAG var der samlet set flere faktorer der var med til at påvirke projektet negativt. Flere
af faktorerne har spillet sammen, og derfor kan det der har vist sig som et problem, godt have
haft rod i en anden faktor. Et af de grundlæggende problemer som er blevet belyst og behandlet
har været de manglende mål i projektet. Dette kan skyldes at projektet var udformet som et infrastrukturprojekt, og med en forkert kontraktform. Derfor Kan det argumenteres at fokusset på
at det var et infrastrukturprojekt fraholdte fokus på nødvendigheden af mål, imens kontraktformen også kan have modvirket dette. De manglende mål havde betydning for flere aspekter af projektet. Herunder udarbejdelen af kravene som viste sig at være for omfangsrig. Et omfang som
kunne have været minimeret hvis alle krav, var sat i forhold til de konkrete mål som skulle have
været opstillet. Derfor ville opstillingen af mål have haft en stor og vigtig indflydelse for projektet
og dets gennemførelse og resultat.
Udover de manglende mål er den af de andre hovedårsager de manglende ressourcer og erfaringen inden for organisationen. Her kan dele af årsagen til problemerne findes i den offentlige organisation, hvori at budgetreglerne tilskynder den model hvor der bruges eksterne ressourcer i
stedet for interne. Samtidig vil en enkelt offentlig institution som rigspolitiet ikke gennemføre
projekter af en størrelse som POLSAGs ofte nok, til at de har mulighed for at fastholde de nødvendige kompetencer internt. Derfor virker det også logisk at finansministeriet anbefaler at staten skal lave en mulighed for at samle og fastholde de nødvendige kompetencer og ressourcer i
staten således at der kan gøres brug af dem når det er nødvendigt.
10.1.2
Vurdering for fremtidig forbedring
Fremover i staten skal der fortsat gennemføres store projekter, og herunder også et projekt som
skal udfylde den rolle i rigspolitiet som et succesfuldt POLSAG var planlagt til. Allerede med Bonnerup rapporten blev der fremsat anbefalinger, som det var muligt at have gjort brug af. Dette
har vist sig at det ikke var fuldkommengældende. Derfor er det heller ikke sikkert at det råd vil
blive brugt fremadrettet. I de nye råd fra finansministeriet, er anbefalinger i højere grad lagt til at
der skal gennemføres initiativer fra statens side. Initiativer der i højere grad vil føre kontrol og
stille hjælp til rådighed. Dermed bliver ansvaret for at følge anbefalingerne ikke udliciteret til den
enkelte institution under staten. Institutioner som ikke nødvendigvis har den rigtige modenhed
Side 51 af 91
eller kompetencer til at følge dem, eller kender vigtigheden af dette. Derfor må det være positivt
at anbefalinger i højere grad kan blive gennemtvunget og dermed bliver krav i stedet for anbefalinger. Selvom det er positivt at anbefalingerne i højere grad må formodes at blive brugt, er det
ikke sikkert at det vil få den positive effekt som er ønsket. Det skal sikres at de øgede krav til et
projekt ikke kommer til at virke som endnu hindring for at velfungerende samarbejde med leverandørerne og have samme effekt som den forkerte kontraktform. Ligeledes er det vigtigt der er
fokus på at øgede krav fra et centralt organ ikke kommer til at virke som en falsk sikkerhed for en
succesfuld gennemførelse og resultat. Dette bliver forhåbentligt opvejet af de positive karrieremæssige incitamenter som der ligger i rådende, der vil få de medarbejdere der vil sidde med ansvaret til at fokusere på at opnå de ønskede mål, i stedet for at fokusere på at holde deres ryg fri
igennem krav og kontraktopfyldelse.
11Konklusion
I rapporten er POLSAG og det forløb som projektet har gennemgået blevet beskrevet. Forløbet
blev beskrevet med udgangspunkt i de aktstykker, som var med til at danne grundlag for finansieringen af projektet. Og var iværksat grundet moderniseringsreformen som også dækkede politiets it-systemer. Herunder blev POLSAG sat i gang som et infrastrukturprojekt.
Under projektet brugte politiet flere forskellige underleverandører, hvilket de blev kritiseret for.
POLSAG forløbet endte med at Bornholmspolitikreds blev brugt til at gennemføre et pilotprojekt.
Et pilotprojekt, der endte med at blotlægge nogle af de svaghede,r som der var indbygget i
POLSAG systemet. Hvoraf det mest kritiske var de lange svartider. Svartider som længe oversteg
hvad der måtte kunne forventes inden projektets start og besværliggjorde de arbejdsgange som
det nye it-system skulle understøtte. Til sidst blev problemerne med systemet for store, og udsigterne til at få dem løst inden for rimelige økonomiske og tidsmæssige rammer blev for små. Hvilker resulterede i at projektet blev lukket.
Grundene til det fejlslagne projekt manifisterede sig i første omgang i budgetoverskridelserne og
de lange svartider. Det samlede resultat af projektet endte ud i et projektet der aldrig blev gennemført, og et projekt hvori der løbende ikke blev lavet den nødvendige dokumentation. En dokumentationen, der ville kunne være brugt til at opsamle erfaringer til senere brug. Grunden til
Side 52 af 91
den manglende succes skal findes i nogen af de faktorer som har været med til at påvirke projektet. Under de mest væsentlige faktorer var de manglende kvantitative mål som senere ville kunne
måles. Dermed manglende der et redskab som ville kunne bruges til at styre projektets mange
krav. Det store antal krav var med til at komplicere udviklingen af systemet, og betød at det endelige system skønnes at bestå af 80 % nyudvikling. Dette var også med til at resultere i den dårlige
kodekvalitet, som både besværliggøre processen med at udvikle systemet, da det satte forhøjet
krav til de nødvendige kompetencer som projektets medarbejdere skulle besidde. Krav som resulterede i at der opstod en større afhængighed af nøglepersoner i projektet, og svære at rekruttere nye medarbejdere. Et af de andre steder hvor der var problemer med projektet var i forhold
til den kontraktform som blev valgt. Her blev der valgt at gøre brug af en forudbestemt standard
kontrakt, som kan have været med til at besværliggøre udarbejdelsen af krav, men også have forringet forholdet til underleverandørerne. I forholdet til underleverandørerne har de været fokus
på at der skulle leves op til kontrakten, i stedet for at fokusere på at opnå nogen forudbestemte
mål. Dermed har parterne været i en situation at et af de væsentligste styringsværktøjer, har været et værktøj hvor parterne har stået som modstående parter, i stedet for samarbejdende. Hvilket kunne have været løst med positive incitamenter, som i højere grad kunne have tilskyndet
samarbejde og et bedre samarbejdsklima. Samtidig var der i kontrakten problemer med at det
ikke var muligt at sætte krav for den samlede svartid. Svartider som var et afgørende punkt i den
problemfyldte pilotdrift. Et af de andre steder hvor der i styringen af projektet var problemer, var
omkring risikostyringen. En risikostyring hvor der var mangel på vurdering af de potentielle omkostninger projektet kunne opleve, og handlinger som ville kunne minimere risici, eller håndtere
dem såfremt det blev nødvendigt.
POLSAG var langt fra det første offentlige it-projekt, og heller ikke det første med manglende succes. Dette har medført at der er blevet udarbejdet anbefalinger til offentlige it-projekter, som
ville øge muligheden for succes. Anbefalingerne er blevet udarbejdet både inden og efter starten
på POLSAG. De anbefalinger som blev givet inden starten på POLSAG, som blev udformet i Bonnerup rapporten, blev ikke entydigt fulgt. Nogen af de steder hvor der var størst mangler i forhold til at vælge anbefalinger, var omkring de dæmpede ambitioner. Her blev rådet fulgt ved at
gøre brug af et standardsystem, men det endte med at blive en stor andel af egen udvikling. Sam-
Side 53 af 91
tidig formåede politiet ikke at få forankret projektet tilstrækkeligt i den øverste ledelse, eller at få
udarbejdet en brugbar og gennemarbejdet business case. I forholdet til leverandørerne var der
også problemer, som kunne være løst ved eller formindsket med brug af anbefalingerne, hvor det
isæt har været den stramme kontraktform og manglende positive kontrakt incitamenter.
Den rapport som er kommet efter POLSAG, kom også med anbefalinger som ville kunne have været brugt i forbindelse med gennemførelsen af projektet. Her er det specielt oprettelsen af et fællesprojektråd, der ville kunne støtte op og overvåge kommende projekter, som ville kunne have
gjort en positiv forskel. Projektrådet vil sikre at der blive udarbejdet en brugbar business case, en
bedre risikostyring, samt at opbygge og bibeholde de nødvendige ressourcer og kompetencer inden for staten, således at de kan bruges når behovet opstår.
Der er blevet udarbejdet flere løsningsforslag i som ville kunne have forbedret mulighederne for
et mere succesfyldt projekt. Herunder en ændring i måden hvorpå der internt i politiet skal ændres på hvordan økonomistyringen bliver lavet internt, således at det bliver tilskyndet at bruge
interne ressourcer på styringen af projektet i stedet for at lade eksterne overtage. Samtidig skal
både kravspecifikation og kontrakten udformes således at det i mindre grad udgør hindringer for
at nå de ønskede mål. Risikostyringen ska også have et større fokus således at man er forberedt
på potentielle konsekvenser. Herunder også de økonomiske der skal sættes i forhold til en businesscase.
12Kildeliste
BONNERUP ET AL., 2001. Erfaringer fra statslige IT-projekter – hvordan gør man det bedre? Rapport og anbefalinger fra en arbejdsgruppe under Teknologirådet. Teknologirådet.
BOSTON CONSULTING GROUP, 2011. Udvalget vedrørende en undersøgelse af POLSAG, 2011 - Review af POLSAG. København V: Boston Consulting Goup.
BRYMAN, A. and BELL, E., 2011. Business Research Methods. 3. edn. New York: Oxford University
Press.
Side 54 af 91
ERIKSSON, P. and KOVALAINEN, A., 2008. Qualitive Methods in Business Research. SAGE Publications Inc.
FINANSMINISTERIET, 2010. Arbejdsgruppen vedrørende bedre statslige it-projekter:<br
/>Professionalisering af arbejdet med it-projekter i staten<br />- Afrapportering fra arbejdsgruppen vedrørende bedre statslige it-projekter. København K: Finansministeriet.
HANSEN, K., 21. marts 2013, 2013a-last update, CSC og politiet i totterne på hinanden om Polsag
Available:
http://www.computerworld.dk/art/225391/cscogpolitietitotternepaahinandenompolsag?
op=print [4/11, 2015].
HANSEN, K., 20-3-2013, 2013b-last update, Seks risikoområder: Derfor blev Polsag lukket
ned Available: http://www.computerworld.dk/art/225362/seks-risikoomraader-derfor-blevpolsag-lukket-ned?op=print [6-3-2015, 2015].
HANSEN, K., 14. oktober 2010, 2010a-last update, Bøvl lige fra starten: Politiet raser over CSC.
Available: http://www.computerworld.dk/art/100992/boevlligefrastartenpolitietraserovercsc?
op=print [04/24, 2015].
HANSEN, K., 22-12-2010, 2010b-last update, Kort nyt: Bornholm bliver prøveklud for Polsag.
Available: http://www.computerworld.dk/art/113052/kort-nyt-bornholm-bliver-proevekludfor-polsag [24-03-2015, 2015].
HANSEN, K., 22-9-2007, 2007-last update, Fem ministerier utilfredse med CSC og ScanJour. Available: http://www.computerworld.dk/art/42776/femministerierutilfredsemedcscogscanjour?
op=print [6-3, 2015].
HANSEN, T.H., 6-2-2012, 2012-last update, Bornholmske betjente: Polsag kunne skære en
uge af opklaringstiden Available: http://www.version2.dk/artikel/et-fungerende-polsagkunne-spare-dage-i-sagsbehandling-43352 [6-3-2015, 2015].
JUSTISTSMINISTERIET, 2010-11. Aktstykke 66.
JUSTISTSMINISTERIET, 2009-10. Aktstykke 157.
JUSTISTSMINISTERIET, 2007-08. Aktstykke 157.
JUSTISTSMINISTERIET, 2006-07. Aktstykke 119.
JUSTISTSMINISTERIET, 2005-06. Aktstykke 106.
JUSTISTSMINISTERIET, 2004-05. Aktstykke 74.
Side 55 af 91
JUSTISTSMINISTERIET, 2003-04. Aktstykke 167.
KILDEBOGAARD, J., 8. februar 2012, 2012a-last update, Anonyme kilder tæt på Polsag: Derfor gik
det helt galt. Available: http://www.version2.dk/artikel/derforgikdetgaltmedpolsag43388
[4/05, 2015].
KILDEBOGAARD, J., 9-2-2012, 2012b-last update, Grotesk jobinterview i 2007: »Tag ikke jobbet,
vi
får
alligevel
aldrig
Polsag
til
at
virke«
Available:
http://www.version2.dk/artikel/polsagchefi2007vifaaraldrigpolsagtilvirke43423
[6-3-2015,
2015].
KILDEBOGAARD, J., 14. oktober 2011, 2011-last update, »Politiets brug af it er håbløs men det er
meget
normalt«.
Available:
http://www.version2.dk/artikel/politietsbrugafiterhaabloesmendetermegetnormalt31882
[2/14, 2015].
KILDEBOGAARD, J., 5. juli 2010, 2010a-last update, Ekspert: Politiet skulle ikke lade CSC styre
projektet.
Available:
http://www.version2.dk/artikel/ekspertpolitietskulleikkeladecscstyreprojektet15436
[4/5,
2015].
KILDEBOGAARD, J., 5. juli 2010, 2010b-last update, Nyt projektkontor skal redde politiet fra flere
itskandaler
Available:
http://www.version2.dk/artikel/nytprojektkontorskalreddepolitietfraflereitskandaler15435
[2/14, 2015].
KILDEBOGAARD, J., 11. september 2009, 2009-last update, IBM: Politiet er håbløst bagud på itfronten.
Available:
http://www.version2.dk/artikel/ibmpolitieterhaabloestbagudpaaitfronten12093 [2/14, 2015].
MCLEOD, L. and MACDONELL, S.G., 2011. Factors that Affect Software Systems Development Project Outcomes: A Survey of Research. ACM Computing Surveys, 43(4), pp. 24.
PEDERSEN, R., 9-1-2012, 2012-last update, Frustrerede betjente: Rigspolitichef skal se på
Polsag
Available:
http://www.computerworld.dk/art/205411/frustrerede-betjenterigspolitichef-skal-se-paa-polsag?op=print [24-03-2015, 2015].
PEDERSEN, R. and HANSEN, K., 23-01-2013, 2013-last update, Læs det hele: Her er de hemmelige Polsag-rapporter. Available: http://www.computerworld.dk/art/223799/laes-det-heleher-er-de-hemmelige-polsag-rapporter [24-03-2015, 2015].
RØJEL, J., HVID, J. and NIELSEN, M.S., 2012. POLSAG: Performance review. Globeteam.
Side 56 af 91
SANDAL, J.S., 3-2-2012, 2012a-last update, Bornholmske betjentes reaktion over Polsagskrotning: Jubel og klapsalver Available: http://www.version2.dk/artikel/bornholmskebetjentes-reaktion-over-polsag-skrotning-jubel-og-klapsalver-43315 [6-3-2015, 2015].
SANDAL, J.S., 2. april 2012, 2012b-last update, Her er justitsministeriets fejlslagne CSCprojekter
Available: http://www.version2.dk/artikel/hererjustitsministerietsfejlslagnecscprojekter44658
[04/24, 2015].
STATSREVISORNE, 2012. Beretning om politiets it-system POLSAG. København: Statrevisorne.
THOMSEN, M.K., 1. maj 2012, 2012-last update, Rigspolitiet fyrer itchef. Available:
http://www.version2.dk/artikel/breakingrigspolitietsitcheffratraeder45190 [4/11, 2015].
Side 57 af 91
13 Appendiks
13.1 Bilag 1: Afslag på anmodning om interview
Hej Daniel,
Beslutningen i ledelsen blev desværre, at Rigspolitiet ikke ønsker at udtale sig om et projekt, som
er lukket for år tilbage.
Jeg er ked af, at du ikke kan få svar på dine mange, gode spørgsmål, men jeg må respektere ledelsens beslutning.
Held og lykke med din opgave.
13.2 Bilag 2: Spørgsmål til politiet
Bilag 2, er en liste med de spørgsmål der i første omgang blev fremsendt til en repræsentant fra
politiet, og senere blev afvist jf. bilag 1
Spørgsmål vedr. POLSAG:
1. Hvilken stilling bestrider du i politiet?
2. I hvilket omfang har du kontakt med projekter i politiet, og herunder it projekter?
3. Hvordan er den overordnede IT-parathed hos politiet?
4. Havde du selv en rolle i forhold til POLSAG?
5. Hvordan er erfaringerne fra POLSAG blevet brugt i politiet?
6. Hvad tror du det vigtigste man har kunnet lærer af problemerne med POLSAG?
7. I hvor høj grad bliver IT set som en byrde og pligt i det daglige arbejde, og i hvilket omfang
bliver det set som en vigtig hjælp?
8. Hvordan er kulturen hos politiet når det kommer til måling det daglige arbejde og processer?
9. Hvordan foregår evt. måling, og hvordan bliver IT inddraget i denne?
10. Kan man med rimelighed antage at politiet har en meget hierarkisk organisation, og hvordan har det betydning for projektgennemførelse inden for politiet?
Side 58 af 91
11. I hvor høj grad blev der lagt vægt på at optimere politiets arbejdsgange i forbindelse med
udarbejdelsen af POLSAG, bl.a. set i forhold til 1:1 kravene som blev taget fra POLSAS?
12. Hvordan er det daglige samarbejde med CSC, og i hvor høj grad er politiet afhængige af
CSC?
13. Hvilken betydning havde kontrakttypen for gennemførelsen af projektet?
14. Hvor stort var fokus på selve kontraktstyrring i forhold til fokus på projektstyringen og
det endelige resultat?
15. I hvor høj grad er politiets arbejdsopgaver, og dermed de krav der er til et system væsentlig anderledes end andre offentlige institutioner, fx sundhedssektoren?
16. Ville det have været muligt i større grad have taget udgangspunkt i systemer brugt i andre
offentlige sektorer, eller systemer brugt hos politiet i andre lande?
17. Er det muligt at ledelsen hos politiet ikke har taget ejerskab overprojektet?
18. Er det muligt at efterhånden som der opstod problemer og disse blev dækket af medierne,
at støtten i organisationen blev aftagende?
19. Hvordan blev erfaringer fra tidligere statslige IT projekter inddraget i arbejdet med
POLSAG?
20. Hvordan blev der gjort brug af risikostyring i POLSAG, og i hvor stort omfang blev der udarbejdet planer for afværgehandlinger?
21. Ville det i højere grad have været muligt at dele projektet op i delleverancer?
22. Har rådgiveransvar været en del af de kontrakter der var lavet med de forskellige konsulenter i forbindelse med POLSAG?
Side 59 af 91
13.3 Bilag 3: Kodning og sporing af belæg
I dette bilag er oplyst de relevante uddrag som er taget fra empirien, og som i første omgang er blevet kategoriseret, som
et led i processen med at opsamle viden, og senere også analysen. Listen er brugt som et arbejdspapir, Det udgør også et
sporingsgrundlag, hvoraf det er finde sammenhæng mellem analyse og empiri. Samtlige tekstuddrag er nummeret ligesom det er oplyst i hvilket afsnit uddraget er brugt
Kodning
Kilde
Side
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
Side 4.
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
s. 4
S. 5
Evt citat
For det første vurderer flere parter, at valget af FESD-standardkontrakten har været uhensigtsmæssig for Politiet. FESD-kontrakten har ikke været velegnet i en situation, hvor der har været så betydelige mængder af egenudvikling af et standardsystem (Captia), som tilfældet har været det med
POLSAG. Med POLSAG vurderes 80 pct. af den samlede leverance at være egenudvikling. Det vurderes, at normen fra andre systemer, som købes ind over FESD-rammen, har været på 20 pct. egenudvikling.
behov for stor tilretning omkring Captia-kernen, skalerbarhed, performance og fleksibilitet (dækkes
alle i denne rapport) – blev nævnt som potentielle risici.
1. Forkert fokus: I stedet for at understøtte sagsbehandlingen digitalt har man fokuseret på en videreførelse af den klassiske journaltradition.
Kode
Analyse
placering
(Afsnit
nummer)
8.1.4.1
FESD
CAPTIA
Nummer
1
2
FESD, Roller og
personer, ledelsen
8.1.2.3,
3
2. Utilstrækkelig leverandørindsats: Systemerne er generelt blevet leveret i ufærdig stand, og leverandørerne har været langsomme til fejlretning.
3. Utilstrækkelige FESD-rammer: FESD-løsningerne har ikke været egnede til understøttelse af arbejdsgangene i de mere komplekse "sagsfabrikker".
4. Utilstrækkelig ledel
sesindsats: Utilstrækkelig fokus på systemets udvikling og implementering samt utilstrækkelige
"muskler" i forhold til leverandøren.
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 9
Vurderingen af de implementeringsmæssige risici bygger dels på en gennemlæsning af materiale om
implementering af POLSAG-projektet og dels på interviews med såvel nøglepersoner i Rigspolitiet
som medarbejdere og chefer i Bornholms Politi og i Midt- og Vestjyllands Politi. Vi har særligt fokuseret på de organisatoriske forhold, som enten kan betyde, at implementeringen fordyres, eller som
kan betyde, at potentielle gevinster reduceres eller realiseres senere end ellers muligt.
Organisation
Side 60 af 91
4
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S.14
Vi vurderer dels, at der er tekniske risici, der kan betyde, at POLSAG vil være ustabilt i en driftssituation, og dels risici, der kan betyde, at POLSAG ikke på en omkostningseffektiv måde vil kunne bruges
som platform for en yderligere digitalisering af Politiet.
Platform
S.19
CSC, Pris
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S.20
Rigspolitiet har ved tidligere lejligheder opnået prisforbedringer på op til 50 pct. i POLSAGforhandlinger med CSC. BCG har ikke lavet en nærmere undersøgelse af forbedringspotentialet, men
har fra flere kilder hørt vurderet, at priserne til betaling af CSC vurderes som meget høje. Lægges til
grund, at der kan opnås en prisforbedring på mellem 20 og 40 pct. af de forventede 20 mio. kr. pr. år
på selve POLSAG-vedligeholdelseskontrakten kan realiseres forbedringer på mellem 36 og 73 mio.
kr. fra primo 2012 og frem mod 2020.
Den første gruppe, "Umiddelbar drift og funktion" , omhandler dels at systemet vurderes at have visse iboende problempunkter og mangelfuldt testniveau, dels at der ikke foreligger dokumentation for
systemets skalerbarhed og ydeevne.
Test, skalerbarhed, ydevene
7
S. 20
Gruppen "Fremtidig drift og vedligehold" indbefatter som det væsentligste, at den samlede løsning er
svær at overskue og sårbar overfor ændringer, en fragmenteret implementering af forretningslogik,
lav udviklerproduktivitet på grund af manglende værktøjsunderstøttelse, en uhensigtsmæssig blanding af teknologier samt hård binding til Captia.
Kompleks løsning
8
S. 20
Fremtid
9
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 26
Den sidste gruppe, "Muligheder for videreudvikling" er forhold, som vurderes at være af vigtighed i
relation til Politiets fremadrettede funktionelle behov, herunder opstiller væsentlige begrænsninger
for fremtidig videreudvikling af systemet. Eksempler på sidstnævnte er, at systemets brugergrænseflade p.t. er bundet til en web-browser, er baseret på afvikling på et lukket netværk samt at POLSAG i
al væsentlighed bygger på en ældre arkitektur (client/server-lignende). Løsrivelse fra hver af disse
bindinger vil være forbundet med store omkostninger. 21
Derudover vurderes det, at POLSAG-løsningen i sig selv og i sin nuværende form ikke er velegnet til
at danne grundlag for at løfte Politiet til et højere niveau af digitalisering, da systemet ikke har en
skarp separation af brugerflade, processer og forretningshændelser og derfor som udgangspunkt ikke er i stand til at reagere på eksterne hændelser. Dette medfører desuden, at POLSAG-løsningen ikke umiddelbart vurderes at være velegnet til at danne grundlag for eksempelvis borgervendte
tjenester eller frembyde på væsentlige komparative fordele i forhold til en eventuel versionering til
mobile enheder eller i patruljevogne, medmindre det er muligt at genbruge den eksisterende brugergrænseflade i sin helhed.
For det første har BCG konstateret en uhensigtsmæssighed i den måde kontraktkomplekset med CSC
har været udarbejdet på, som har været medvirkende til, at driften af miljøer er blevet endnu større,
end den kunne have været. Miljøerne og selve POLSAG-løsningen har været reguleret af to forskellige
kontrakter mellem Politiet og CSC. Selve POLSAG-løsningen blev forsinket – ifølge Politiet til dels pga.
forsinkelser hos CSC – men miljøerne blev færdiggjort ihht. den oprindelige tidsplan i april 2010.
Det er BCGs forståelse, at de 17 mio. kr. til dels kan forklares med et betydeligt højere forbrug af eksterne konsulenter, end oprindeligt estimeret.
Kontrakt,
CSC,
kompleksitet
10
Konsulenter
11
:
• Manglende tradition i Politiet for bemanding af projekter med projektmedarbejdere, som har erfaring med så omfattende projekter, som POLSAG.
• Et arbejdsmarked, hvor det var svært at rekruttere eksterne medarbejdere til POLSAG.
• Behov for særkompetencer, som ikke kunne rekrutteres.
Konsulenter,
manglende evner
S.27
S.27
5
8.2.1
7.1.4,
8.1.2.1,
8.1.3.3,
8.1.5.2
Side 61 af 91
6
12
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S.27
Udviklingspakke 1 skyldtes dels ændringer som følge af ny organisering og ny lovgivning og dels
ændringer til den oprindelige aftale pga. manglende krav i kravspecifikationen mm.
Kravspec
13
S. 30
Intern økonomistyring
14
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 44
Mere generelt har Politiet oplyst, at økonomistyringen i hele POLSAG-forløbet har haft fokus på ydelser, der bliver leveret af eksterne leverandører og er fakturerbare. Det bemærkes, at dette var en udbredt praksis i mange samtidige statslige it-projekter. Det betyder ifølge Rigspolitiet, at følgende ikke
har indgået i ressourceopgørelsen: Internt anvendt tid i POLSAG-programmet, ydelser der leveres af
andre afdelinger i Rigspolitiet, f.eks. Koncern IT, Politiets kompetencecenter mv., AMU-ressourcer til
uddannelse af brugere i kredsene, driftstab i politikredsene i forbindelse med uddannelse af brugere.
Der vil således være behov for at overføre visse dokumenter og oplysninger til POLSAG. I den forbindelse skal der skelnes mellem sagsoplysninger (metadata) og sagsdokumenter.
Sagsoplysninger er beskrivelser af gerningspersoner, gerningssteder, objekter der indgår i sagen
mm., mens sagsdokumenter kan være afhøringsrapporter, billedmateriale mm.
Klasser
15
Forløb
16
Risici
17
S. 45
1. Såvel sagsoplysninger som sagsdokumenter for verserende sager overføres fra POLSAS til
POLSAG. Dette vil kræve, at alle sagsdokumenter skannes, således at de gamle POLSAS-oprettede sager fra starten gøres til fulde POLSAG-sager.
2. Kun sagsoplysninger overføres fra POLSAS til POLSAG. I denne model opretholdes selve sagsdokumenterne for de sager, som er oprettet i POLSAG, papirbaseret. Der vil være mulighed for at lave
landsdækkende søgninger i sagsoplysningerne, men skal en POLSAS-oprettet sag senere fremfindes,
kræver det at sagen hentes frem fra arkivet i den kreds, hvor den findes.
3. Selve POLSAS-applikationen lukkes ned men databaserne i POLSAS bevares og der etableres et
fælles søgeværktøj for POLSAS og POLSAG således, at der kan laves tværgående søgninger i hhv.
POLSAS' 12 databaser og i POLSAGs ene database. For de enkelte kredse identificeres herefter et
tidspunkt hvor så mange sager vil være afsluttet, at det vil være økonomisk attraktivt at lukke POLSAS og overføre de resterende sager til POLSAG.
Politiet
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 48
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 50
De tekniske risicier de vigtigste i POLSAG-projektet samlet set og at de tekniske risici primært relaterer sig til den valgte løsning med en meget omfattende videreudbygning på toppen af en ESDHplatform kombineret med flere uhensigtsmæssige design- og teknologivalg og en meget lavt testdækning på kodeniveau vurderet med 2011-standarder. Dette fører til betydelig risiko for fordyrelser i form af fremtidige udviklinger og eventuelt dårlig stabilitet og ydeevne i driften.
• De leverandørmæssigerisici er centreret omkring de kontraktuelle forhold, som betyder at Rigspolitiet ikke har ejerskab til kildekoden, samt en forhøjet afhængighed af nøgleressourcer hos underleverandøren.
• De implementeringsmæssige risici primært er relateret til det forholdsvis komprimerede udrulningsforløb samt slutbrugernes parathed overfor ændringer af it-mæssig karakter.
Gruppen "Fremtidig drift og vedligehold" indbefatter forhold, som ikke er kritiske for systemets
umiddelbare idriftsættelse, men som er særdeles væsentlige for så vidt angår gennemførelse af fremtidige drifts- og vedligeholdelsesopgaver. Af disse vurderes de væsentligste at være, at den samlede
løsning er svær at overskue og sårbar overfor ændringer, en fragmenteret implementering af forretningslogik, lav udviklerproduktivitet på grund af manglende værktøjsunderstøttelse, en uhensigtsmæssig blanding af teknologier samt hård binding til Captia.
Konsekvensen af ovenstående er, at selv mindre udbygninger eller tilretninger vurderes at blive dyre
at implementere samt indebære en øget risiko for fejl.
Fremtidig
Captia
rift,
Side 62 af 91
18
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 51
Eksempler på begrænsninger fremadrettet er, at systemet p.t. er bundet til at køre på en webbrowser, er bygget til et lukket netværk samt at POLSAG i al væsentlighed bygger på en ældre arkitektur (client/server-lignende). Løsrivelse fra hver af disse bindinger vil være forbundet med store
omkostninger.
Fremtidig videreudvikling
19
S. 51
Fremtid
20
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 51
I forlængelse af den begrænsede fleksibilitet er der observeret yderligere forhold, som vurderes at
være vigtige for Politiets fremadrettede behov. Det vurderes, at POLSAG-løsningen i sig selv og i sin
nuværende form ikke er velegnet til at danne grundlag for at løfte Politiet til et højere niveau af digitalisering. POLSAG-løsningen har p.t. ikke en skarp separation af brugerflade, processer og forretningshændelser og er derfor som udgangspunkt ikke i stand til at reagere på eksterne hændelser
uden yderligere programmering. Dette medfører desuden, at POLSAG-løsningen ikke umiddelbart
vurderes at være velegnet til at danne grundlag for eksempelvis borgervendte tjenester eller at have
væsentlige komparative fordele i forhold til en eventuel versionering til mobile enheder eller i patruljevogne, medmindre det er muligt at genbruge den eksisterende brugergrænseflade i sin helhed.8
Denne observation er særligt væsentlig al den stund POLSAG ses som et infrastrukturprojekt. Infrastrukturprojekter er projekter, som ikke nødvendigvis i sig selv giver betydelige gevinster, men som
danner grundlag for attraktive opfølgningsprojekter. Hvis der er unødigt store udgifter forbundet
med såvel den almindelig drift som vedligeholdelse og videreudvikling af POLSAG, vil POLSAG ikke
være et attraktivt infrastrukturprojekt.
Det er BCGs vurdering, at de fremadrettede udgifter til videreudvikling kan nedbringes. Men det er
også vores vurdering, at dette kræver forebyggende investeringer i form af korrigerende tiltag. Niveauet for disse investeringer er afhængigt af de krav, der fremadrettet stilles til systemet, dvs. hvilken it-strategisk vej man ønsker at tage POLSAG.
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 54
The
Boston
Cunsulting
Group, 2011. Udvalget ved-
S. 55
Infra-
21
Fremtid; korrektioner
22
Starte forfra
23
POLSAG-løsningen indeholder ikke for nuværende mekanismer til at understøtte rolling upgrades
eller beta/pilot-drift, hvilket betyder, at der kan opstå behov for servicevinduer af et ganske anseligt
omfang under udrulningen af opgraderinger. Manglen på sådanne mekanismer betyder samtidig en
forøget risiko for fejl og deraf følgende ekstra nedetid.
Opdateringer,
servicevinduer
24
S. 54
Det ses som en yderligere risiko, at det ikke for nuværende er en overskuelig og kontrolleret opgave
at ændre i stamdataopsætningerne til en kreds, efter at denne kreds er produktionssat, hvilken kan
55
blive nødvendigt såfremt der skulle vise sig at være fejl relateret til opsætning. Risikoen
Stamdata
25
S. 55
Der er endnu ikke taget beslutning om hvorvidt Captias standardværktøjer til change management Captia Configuration Manager - skal anvendes til ændring af stamdataopsætningerne, eftersom det
ikke er klart om disse i praksis kan håndtere de relativt store mængder af stamdata i POLSAG. Så vidt
vides retter Captia Configuration Manager enkelte dataværdier og skalerer derfor ikke til større ændringer. Erfaringen viser, at manuelle opdateringer direkte i et produktionsmiljø (der er angiveligt
ingen promotion-strategi i de foreliggende værktøjer) ikke er i overensstemmelse med best practice,
da manuelle opdateringer er svært håndterbare og risikable.
POLSAG indeholder derudover blot nogle få automatiserede unit tests. Disse unit tests kunne ikke
eksekveres mens code review'et blev udført. Dette betragtes som en alvorlig mangel for et system af
Captia, Stamdata,
ændringer
26
Test
27
S. 51
S. 53
Tid for gennemførelse: 24-40 måneder.
Forsinkelse: Mindre end udviklingstiden, da løbende udrulning forventes.
Udgift: 100 - 300 mio. kr. (Det er p.t. formodningen, at det vil være billigere at starte forfra for så
vidt angår den tekniske løsning (arbejdet omkring kravspecifikationer mv. formodes i en vis udstrækning at kunne genbruges, da systemet kun i behersket omfang opfylder de foreliggende arkitekturkrav.)
Fremtid,
struktur
Side 63 af 91
rørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
denne type og kompleksitet.
s. 55
Mange (i visse tilfælde også unødigt mange) web service-kald fra browseren.
• Tæt koblede integrationer med eksterne systemer med ukendte karakteristika for så vidt angår
skalerbarhed og ydeevne.
• Et objektlag bygget oven på en Oracle database (Captia SOM).
• En kodebase der ikke er udviklet med hensyntagen til performance (den udbredte brug af joins i
C#-laget betyder, at der er mange kald til databasen).
Ydeevne
8.1.3.4
28
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 56
Risikoen er, at al projektets tid og energi bruges på brandslukning i stedet for på at løse de problemer, projektet står i. It-projekter, der går over tid eller budget, er én ting. It-projekter, der fører til
større fejl eller mangler i den borgerrettede offentlige service, er noget helt andet.
Fejl, Fremti
29
S. 56
For det første vurderes den samlede løsning at være svær at overskue samt sårbar over for ændringer. Dette kan komme til udtryk dels ved uforudsete bivirkninger, dels ved at ændringer ikke bliver
implementeret korrekt, fordi mange funktioner er helt eller delvist duplikeret andetsteds i systemet.
POLSAG er desuden præget af en fragmenteret implementering af forretningslogik, hvilket vurderes
at være en svaghed,
ScanJours Captia-platform understøtter et højt niveau af konfigurerbarhed, hvilket bliver udnyttet af
POLSAG-løsningen. På grund af den måde platformen bliver udnyttet på, hvor de forskellige funktionaliteter ikke er kapslet ind, bevirker dette imidlertid også, at det bliver meget svært at overskue den
samlede løsning.
Fragmenteret
forretningslogik
30
Kompleksitet,
Captia
31
Løsningen er ikke modulært opbygget (dvs. det er vores opfattelse at det hverken er passende lagdelt eller organiseret i funktionelle områder), hvilket gør at ændringer i f.eks. datamodellen kræver
ændringer i mange af løsningens andre teknologikomponenter. Dette øger arbejdsbyrden ved gentest samt risikoen for følgefejl.
7.1.2.1.2 Ændringer i kodebasen vurderes at være forbundet med større omkostninger end forventet
Der er en udbredt brug af "late binding" i POLSAG-løsningen. Dette betyder at mange fejl som normalt vil kunne fanges under oversættelsen i et udviklingsmiljø, først vil kunne fanges i en test og som
sådan i en del af tilfældene må forventes først at blive opdaget ude ved slutbrugerne.
• De generelle kodemetrikker viser, at der er meget høj kompleksitet i koden (meget lange funktioner).
• Det utilstrækkelige niveau af automatiske test giver ikke kun en stor testbyrde under udrulningen,
men også i vedligeholdelsesfasen, hvor det kan være svært at overskue eventuelle følgefejl af en rettelse.
Kompleksitet,
modellering
32
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 58
Et væsentligt forhold set fra et udviklingsmæssigt perspektiv er systemets begrænsede muligheder
for at dække nye behov uden en meget stor udviklingsindsats. Foruden en forhøjet risiko for fejl og
væsentlig dyrere implementering af ændringer er systemet opbygget på en sådan måde, at fremtidig
videreudvikling af systemet som udgangspunkt kræver en væsentlig udviklingsindsats. I forlængelse
af dette er der observeret yderligere forhold, som er vigtige i relation til Politiets fremadrettede behov. Det vurderes, at POLSAG-løsningen i sig selv og i sin nuværende form ikke anses for at være velegnet til at danne grundlag for at løfte Politiet til et højere niveau af digitalisering, eksempelvis i form
af procesunderstøttelse. Det kan godt lade sig gøre at udvide platformen, men det vurderes at være
økonomisk og teknisk uattraktivt.
Kompleks, fremtid
34
The
Boston
Cunsulting
Group, 2011. Udvalget ved-
S. 59
Andre systemer
35
S. 57
S. 57
S. 57
9 systemer ved hjælp af web services,
Kodning,
pleksitet
Kom-
8.1.3.1,
8.1.3.4,
Side 64 af 91
33
rørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
• tæt integration med systemerne Bøde, ATKS og KR, og
• batchoverførsler til 9 andre systemer (politiets egne såvel som andre myndigheders systemer).
S. 59
S. 59
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 60
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 61
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 61
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget ved-
S. 63
S. 60
S. 62
S. 63
(evt. eksterne) hændelser. Captia-platformen indeholder som standard mulighed for afvikling af
standardsøgninger, som kan afvikle kode. Det er på denne måde, at information om visse ændringer
sendes pr. e-mail til manuel opdatering i KR. Dette kan dog ikke betegnes som en tidssvarende måde
at implementere det hændelsesorienterede system på.
eftersom de ikke garanterer leverancen, altså leverer sikkerhed for, hvorvidt en given meddelelse
er afleveret til rette modtager. Således er der risiko for, at en meddelelse rent faktisk bliver registreret, men at systemet ikke ved at dette er tilfældet fordi svaret er fejlet,
• eftersom servicekaldene ikke sikrer, at der kun kommer en kopi af meddelelsen frem, og
• eftersom det ikke sikres, at den har det ønskede indhold samt at den oprindelige rækkefølge i meddelelserne overholdes.
Det bør desuden i denne sammenhæng bemærkes, at løsningen i sin nuværende version ikke blot er
bundet til at køre på en web-browser, men at den er bundet specifikt til Internet Explorer 6. Dette
binder Rigspolitiet til Windows XP. Microsoft er ophørt med at yde ordinær support af Windows XPplatformen og den resterende support (der p.t. er begrænset til sikkerhedsrettelser) afsluttes d. 8.
april 2014.
Det vurderes, at POLSAG-systemet i sin nuværende form ikke er velegnet til at danne grundlag for en
øget digitalisering af arbejdsgangene i Politiet, idet løsningen ikke er disponeret til dette og da ændringer således bliver dyrere end ellers i både initialinvestering og drift/vedligeholdelse. Dette er
blandt andet forårsaget af, at forretningslogikken er spredt rundt i systemet. Desuden vurderes
POLSAG som udgangspunkt ikke at være i stand til at nemt at reagere på eksterne hændelser, hvilket
gør det svært at benytte den som grundlag for borgervendte tjenester.
Et særligt vigtigt forhold i fremadrettet optik er mulighederne for at videreudvikle systemet til at åbne muligheder for direkte procesunderstøttelse. Dette er særligt vigtigt, da Politiet er en særdeles
procestung organisation (modsat eksempelvis Forsvaret eller ministerierne). Dette kommer konkret
til udtryk ved at der udføres et stort antal tidskrævende, rutineprægede opgaver. Det er netop i sådanne organisationer at et it-system med procesunderstøttelse har sin største berettigelse og sit
største potentiale.
POLSAG bygger på en standard ESDH-systemplatform, der oprindelig er udviklet med registrering og
arkivering for øje, og det rummer en meget synlig datamodel. Løsningen har ingen indbygget procesunderstøttelse og er derfor som udgangspunkt ikke i stand til at reagere på eksterne hændelser. I
forlængelse heraf vurderes det at være forbundet med væsentlige vanskeligheder at tilføje effektiv
procesunderstøttelse til platformen.
Forhøjet afhængighed af nøgleressourcer hos ScanJour og hos CSC. Det er BCGs vurdering, at POLSAG
er karakteriseret ved en høj afhængighed af nogle få nøgleressourcer hos ScanJour. Dette skyldes
primært det udviklede systems høje kompleksitet og kodebasens svære tilgængelighed og kan føre
til forhøjede omkostning ved indfasning af nye udviklerressourcer hos ScanJour.
Viden om POLSAG og evnen til at vedligeholde og videreudvikle POLSAG vurderes på basis af interviews reelt at være båret af 5-6 medarbejdere hos ScanJour. Tabet af 2-3 af disse medarbejdere vurderes at kunne have alvorlige konsekvenser for det videre forløb af POLSAG.
Udvikling på Captia Platformen foregår for en stor del i proprietære Captia-teknologier, som har en
lav værktøjsunderstøttelse. Selve POLSAG-kodebasen er derudover relativt kompleks.
Det vurderes i øvrigt at blive sværere end normalt at tiltrække de dygtigste medarbejdere til POLSAG
grundet den unikke blanding af Oracles og Microsofts systemplatforme, det komplekse udviklings-
Hændelser, kodning
36
Stabilitet
37
Klient, IE,
38
Forretningslogik,
flexibilitet
39
Proces
40
ESDH, Datamodel,
Stamdata,
Process
41
Personel
hængighed.
af-
8.1.2.1,
Personel
afhængighed, kompleks
Personel
hængighed,
afre-
42
43
8.1.3.1
Side 65 af 91
44
rørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
miljø og den udbredte brug af ældre teknologi.
S. 66
S. 69
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 83
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 84
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 85
For det første rummer overgangen fra implementering til drift en stor opgave, som kræver at såvel
politiets driftsorganisation som leverandørens driftsorganisation er på plads og har indgået de nødvendige praktiske samarbejdsaftaler. Dette er ikke p.t. tilfældet.
Der oprettes en central enhed i Rigspolitiet med ansvar for og fokus på realisering af effektiviseringsgevinster i politikredsene samt på afhjælpning af de nævnte uhensigtsmæssigheder.
• Der afsættes udviklingsmidler til hurtigt at rette op på konstaterede forretningsmæssige uhensigtsmæssigheder i systemet.
• Der etableres de nødvendige incitamenter til en hensigtsmæssig implementering og udrulning af
POLSAG hos de lokale kredsledelser. Dette kan eventuelt være ved indskrivning af POLSAGrelaterede mål i politidirektørernes resultatkontrakter eller ved indførelse af og POLSAGs-relaterede
effektiviseringsmål i PRES.
• De enkelte kredse tidligt går i gang med at forberede realiseringen af gevinsterne. Til dette formål
har vi lavet en nedbrydning af alle identificerede gevinster til kredsniveau samt lavet et bud på en
tidsplan for hvornår gevinsterne kan realiseres i de enkelte kredse (se afsnit 8.5).
8.2.2.3 Langsomme svartider (server-baseret system)
Som beskrevet i afsnit 7.1 ang. tekniske risici, er der en væsentlig risiko for, at POLSAG har langsommere svartider end POLSAS. Omfanget af dette problem afhænger i høj grad af, hvor stor forlængelsen af svartiden er blevet. Implikationerne kan omfatte alt fra et irritationsmoment til en
decideret forhindring for medarbejderne i forhold til at udføre deres arbejde.
Det sted, hvor problemet forventes at blive mest konkret og kvantificerbart, er i servicecentrene,
hvor langsommere svartider potentielt kan medføre, at centrene ikke vil være i stand til at opfylde de
opstillede krav til responstider inden for den nuværende normering (for eksempel at besvare 95% af
opkaldene inden for 2 min.). Dette vil således enten medføre forringet service for borgerne eller
kræve tilførte ressourcer til servicecentrene. Dette vil fortsætte så længe problemet med langsomme
svartider består.
Det kan umiddelbart virke paradoksalt at overgangen til elektronisk sagshåndtering vil medføre et
forøget papirforbrug. Ikke desto mindre er det BCGs vurdering, at dette kan være tilfældet, endog på
lang sigt. Praktisk talt alle medarbejdere har i forbindelse med interviews givet udtryk for, at de stadig agter at arbejde med sager i papirform, på trods af at disse vil være tilgængelige i deres totalitet
via POLSAG. I praksis betyder dette, at en given efterforsker kan sidde med en skyggesag af papir
under hele forløbet. Herefter pakkes sagen elektronisk og overdrages til anklagemyndigheden. Modtageren vil som det første printe hele sagen, inden vedkommende arbejder videre med den, hvilket
således tilfører en udskrivning af sagen.
Denne arbejdsgang
Hurtigere sagsbehandling (forstået som tiden fra anmeldelse til domsafsigelse), først og fremmest
takket være eliminering af ventetid fra forsendelse og fysisk fordeling af sager.
• Højere medarbejdertilfredshed inden for specifikke personalegrupper, takket være mere moderne
redskaber og teknologi.
• Forøget opklaringsprocent på specifikke sagstyper.
• Højere datakvalitet.
• Mere systematisk og struktureret indtastning af data.
• Højere kvalitet på døgnrapporten.
• Antallet af fejlopdateringer på varetægtsfængslede reduceres.
kruttering
Implementering
45
Realisering
46
Langsomme svartider
7.1.4
47
It parathed, process, organisering
8.1.2.2,
8.1.4.6
48
Kvalitative løft
Side 66 af 91
49
• Bedre ledelsesværktøjer relateret til forbedret decentral udtrækning af data.
85
• Bedre underbygning af sager (flere sager holder i retten pga. bedre data).
• Færdselsuheld registreres mere korrekt end tidligere grundet feltvalideringer.
• Medarbejdere vil blive automatisk påmindet om nært forestående indberetninger.
• Søgning på tværs af kredse (bidrager desuden til flere af de øvrige punkter).
• Sager bliver ikke længere væk.
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
The
Boston
Cunsulting
Group, 2011. Udvalget vedrørende en undersøgelse af
POLSAG 2011 – Review af
POLSAG
S. 85
S. 85
S. 86
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S.6
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 6
For at sikre, at ovenstående kvalitative gevinster realiseres, er det BCGs anbefaling, at der fastsættes
mål for, hvorledes disse bør komme til udtryk, eksempelvis i form af forbedrede resultater i PRES.
Det omtalte nyligt iværksatte måleprogram går et stykke af vejen idet der defineres hypoteser om
mulige forbedringer samt hvorledes disse bør kunne måles, men der er først og fremmest tale om en
objektiv måling af før- og eftersituationen, ikke en egentlig målsætning om realisering af fordele.
Det er BCGs vurdering, at Politiet med POLSAG - såfremt udfordringer relateret til ydeevnen løses –
vil kunne udføre al intern sagshåndtering elektronisk, hvorimod alle grænseflader til eksterne myndigheder og interessenter vil forblive papir-baserede. Dette betyder i praksis, at al indgående information skal indskannes, og al udgående information skal udskrives, hvilket givetvis medfører en
række uhensigtsmæssigheder i forhold til at realisere systemets potentiale.
Tilsvarende betragtninger gør sig gældende i forhold til integration af randsystemer, bortset fra at
dette område har mere direkte implikationer i forhold til politiets interne, elektroniske sagshåndtering. Det er Politiets forventning, at POLSAG med tiden vil kunne føre til udfasning af en række af
POLSAGs randsystemer idet POLSAG kan overtage disse systemers funktionalitet. Såfremt dette sker,
vil der dels være besparelser som følge af nedlukning af disse systemer og dels forretningsmæssige
gevinster da Politiets medarbejdere ikke længere skal arbejde parallelt i mange forskellige systemer.
Udgangspunktet for denne rapport er, at den offentlige
sektor ikke ma forspilde sine chancer for at
anvende informationsteknologien til en bedre og
mere effektiv styring, sagsbehandling og service. For
eksempel ved at udvikle IT-systemer, hvor disse fordele
ikke udnyttes godt nok. Eller ved helt at undlade
at satse ambitiost pa informationsteknologien. Det
vil vare langt alvorligere end de nok sa ubehagelige
forsinkelser og budgetoverskridelser, der har praget
en rakke offentlige IT-projekter i 90’erne.
1.1 Sammenfatning
Den danske offentlige sektor har gennem en lang
periode anvendt informationsteknologien relativt
avanceret sammenlignet med andre lande. Det har
blandt andet kunne lade sig gore, fordi Danmark pa
et tidligt tidspunkt fik gennemfort en entydig identifikation
af den enkelte borger via CPR-nummeret og
af virksomheder via SE-nummeret.
Skal Danmark fortsat kunne vare
For det første at borgerne vil eftersporge en IT-baseret
service fra det offentlige, der mindst er pa niveau
med den, de vil opleve fra de mest avancerede private
virksomheder. Det vil blandt andet sige let og sikker
adgang til at kommunikere, indberette, bestille,
betale og fa malrettet og pracis information via nettet.
Kvalitative
måling
krav,
8.1.3.2,
8.1.4.3,
8.1.4.6
50
Grænseflader,
process
51
Integration, udvikling, fremtid
52
Ambition,mål,
53
Højt niveau,
54
Krav, forventning
55
Side 67 af 91
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 6
For det andet at det i kommende IT-projekter ikke vil
vare teknologien, der satter granser for, hvilke
offentlige opgaver der kan udfores elektronisk. Den
vigtigste barriere for nye projekter bliver det offentliges
egen evne til at realisere de teknologiske potentialer.
Grænser
56
S. 6
Automatisering,
proces, arbejdsgange
57
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 7
Organisatorisk set, var der var typisk tale om automatisering
af velkendte arbejdsrutiner samt enkle
rationaliseringer, der kun medforte overskuelige
omlagninger og nedskaringer i begransede dele af
organisationen. De senere ars IT-projekter gar anderledes
pa tvars af hele organisationen og forudsatter
typisk dybtgaende omlagninger og tilpasninger af
denne.
Det vil imidlertid
krave en langt storre tvargaende koordinering,
hvis borgerne fx skal have mulighed for at indberette
oplysninger – og kunne nojes med at gore det en
gang
S. 9
Valg af løsningsmodel:Offentlige myndigheder har
generelt frie hænder til at vælge IT-løsning. Det har
traditionelt ført til, at myndigheden har krævet specialudviklede
systemer i stedet for at overveje
muligheden for at basere sig på eksisterende standardsystemer,
hvor dette kan lade sig gøre.
Specialudvikling,
Valg, standardsystem
59
S. 9
Konsulenter, tidsramme
60
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Tekno-
S. 9
Bevillingsreglerne og den politiske beslutningsproces:
Bevillingssystemet er i dag så fleksibelt, at det
generelt set ikke forhindrer (eller sikrer), at offentlige
IT-projekter kan gennemføres fornuftigt. Systemet
kan dog være med til fra starten at skabe for
optimistiske forventninger til projektet – herunder
realismen i de fremlagte budgetter og tidsrammer.
Det favoriserer typisk også brugen af eksterne konsulenter
på bekostning af den offentlige institutions
egne ansatte.
Men
det mest almindelige er stadig, at hver enkelt myndighed
finder sin egen losning. Den har hidtil som
regel varet at udvikle et skraddersyet system fra
grunden.
Egen udvikling,
61
Mange myndigheder lider dog ogsa af den misforstaelse,
at deres behov er sa specielle, at de pr. definition
ikke kan opfyldes af markedets standardsystemer.
Det er imidlertid arbejdsgruppens vurdering, at
besvaret med at indrette arbejdsgangene til eksisterende
standardsoftware ofte vil vare langt mindre
Standardsystem,
proces,
62
S. 9
Krav, forventninger, privat, kompleksitet
8.1.3.4
Side 68 af 91
58
logirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 10
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 10
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 10
S. 10
end de risici, der er forbundet med at udvikle helt
nye, uprovede systemer. Ogsa selv om standardsystemerne
forst skal tilpasses myndighedens sarlige
behov, herunder kombineres med et eksisterende
system.
Der er imidlertid ogsa granser for,
hvor meget et standardsystem kan tilrettes, uden at
der derved opstar risici i forbindelse med anvendelse
af kommende versioner og i forbindelse med systemets
ydeevne. Det er i den forbindelse ogsa vigtigt at
vare klar over, at det kan vare lige sa kravende at
styre et IT-projekt, hvor et standardsystem skal
udbygges og implementeres. Det skyldes isar, at der
her vil vare de samme eller storre krav om at tilpasse
organisationens eksisterende arbejdsgange til det
nye system.
Uanset om et IT-projekt forelagges sarskilt for
Finansudvalget vil den pagaldende myndighed
typisk pa et tidligt tidspunkt sikre sig den nodvendige
opbakning til projektet, saledes at det kan indga i
ministeriets samlede prioritering og evt. i forudsatningerne
for en patankt lovgivning. Men pa dette
tidspunkt vil bade projektets okonomi og tidsplan
som regel vare meget usikre. Myndigheden vil i
denne fase derfor vare tilbojelig til at lagge vagt pa
projektets fordele, mens risici og omkostninger let
bliver underbetonet. Problemet med dette er, at ”bordet
fanger”. Nar der forst en gang er prasenteret en
samlet pris og en tidsplan, er det svart at vende tilbage
med en grundigere vurdering af pris og tid,
hvis den er mindre optimistisk. Det vil nemt blive
udlagt som et tegn pa, at der ikke er styr pa projektet
– og dermed bringe ministeren i offentlighedens,
Folketingets og Finansudvalgets kritiske sogelys.
I de senere ar har FU i en rakke
tilfalde stillet krav om en regelmassig rapportering
om storre IT-projekter, fx VUE og AMANDA, men en
sadan rapportering andrer ikke pa det forhold, at
det er den pagaldende minister, der har ansvaret.
Derimod betyder rapporteringen naturligvis, at der i
en periode sattes sarlig politisk fokus pa et projekt.
Dog er der i systemet indbygget en tendens til at
favorisere brugen af konsulentbistand pa bekostning
af myndighedens egne ressourcer. Det skyldes,
at den bevilgede lønsum til myndighedens fastansatte
medarbejdere er væsentlig mindre fleksibel –
og meget vanskeligere at fa politisk tilslutning til at
forhøje – end de driftskonti, der kan bruges til at
købe ekstern konsulentbistand. Hertil kommer, at
projektledere eller andet nøglepersonale i IT-projekter
ofte kan vare vanskelige eller tidskravende at
indpasse i den eksisterende stillings- og lonstruktur.
Standardsystem,
Egen udvikling,
63
Risiko, ejer, politik
64
Politik, Ejer
65
Politik, lønstruktur, konsulenter
8.1.3.3
Side 69 af 91
66
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S.10
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 11
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 13
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 13
S. 14
S. 14
Der er heller ingen tradition for helt eller delvist at
”genbruge” IT-systemer, der er udviklet i andre dele
af centraladministrationen. Det kunne fx vare sagsbehandlingseller dokumenthandteringssystemer.
Det kan i nogle tilfalde skyldes, at der ikke i
kontraktforholdet tages hojde for sporgsmalet om
licens eller ophavsret. Men generelt er det snarere
udtryk for, at den enkelte administrative enhed
opfatter sine opgaver som sa specielle, at de kraver
en unik losning. Ministerierne udnytter dermed ikke
de ”stordriftsfordele”, der kunne skabes ved at fremsta
som en samlet kober og etablere ”koncernfalles”
IT-funktioner.
Normalt er der i de statslige kontrakter ikke indbygget
noget positivt incitament for leverandoren til
at levere den optimale ydelse til kunden. Det kunne
fx vare i form af en bonus, der udloses, hvis en delleverance
leveres som aftalt. Der synes at vare behov
for at udvikle kontraktformer, der bade rummer pisk
og gulerod: Sanktioner, hvis kontrakten misligholdes,
og incitamenter til at overopfylde kontrakten.
Leverandorerne kritiserer bl.a. de nuvarende standardkontrakter
pa folgende punkter:
For det andet har der ikke varet formuleret pracise
mal for IT-projektet, der er set i sammenhang med
organisationens strategi og mal. Dermed har projektet
manglet et meget vigtigt styringsredskab. Det
har endvidere varet umuligt at vurdere, i hvor hoj
grad det har styrket organisationens ”forretningsmassige
mal”, fx bedre service til brugerne, mere
effektiv sagsbehandling og/eller lavere omkostninger.
For det fjerde har styringen af hele projektforlobet
generelt varet for darlig. Blandt andet har projektet
ikke varet bemandet starkt nok, der har fx manglet
risikostyring, brugerne har varet inddraget forkert,
og man har forsomt at dele projektet op i kortere
faser med lobende leverancer af delsystemer.
Standardsystem,
licens, processer
67
Mål, kontrakt, incitament
68
Mål, styring
69
Styring, leverancer,
70
Eksemplet viser, at nar et projekt forst er sat i
vark, er der en tendens til, at diskussioner af tekniske
muligheder og praktiske problemer, stjaler
opmarksomheden fra de ”forretningsmassige”mal
og de resultater, organisationen onsker at na. IT-systemet
bliver et mal i sig selv – i stedet for et redskab
til at udvikle organisationen i den onskede retning.
I de undersogte projekter har der kun i meget
ringe grad varet opstillet malsatninger for systemet,
der var tankt sammen med organisationens
overordnede visioner, strategier og planer, og der har
manglet klare og malbare krav til, hvad organisationen
skulle have ud af det pagaldende projekt. Det
har gjort det svart undervejs lobende at vurdere,om
Mål, proces
71
Mål, styring
72
Side 70 af 91
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 14
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 15
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 15
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 15
S. 15
S. 15
projektet grundlaggende var pa rette spor.
I flere tilfalde har det blandt andet skyldtes,
at hverken kober, konsulenter eller leverandorer
havde noget samlet overblik over, hvor store systemerne
ville blive, og hvilke konsekvenser de ville fa
for organisationerne.
Kompleksitet,
styring, ejer
73
Skal et storre offentligt IT-projekt gennemfores med
succes,ma det fra starten forstas og tilrettelagges
som et organisationsudviklingsprojekt, der skal
understøttes af IT. Det har ikke i tilstrakkelig grad
varet tilfaldet. Saledes har den offentlige kober
typisk fokuseret for ensidigt pa projektets tekniske
konsekvenser og forudsatninger og undervurderet
de organisatoriske.
Der er derfor behov for, at den offentlige
kober, inden projektet gar i gang, kritisk vurderer sin
organisatoriske kapacitet. Det kan enten fore til en
mere pracis plan for, hvordan organisationen kan
modnes til at magte projektet, eller til erkendelsen
af, at det ikke kan lade sig gore, og at projektet derfor
ikke kan gennemfores, for denne modenhed er til
stede.
Hvis systemet ikke fra starten sikres opbakning
fra alle ledelsesniveauer, vil resten af organisationen
heller ikke fole noget ejerskab til systemet, nar det
skal implementeres. Der er flere eksempler pa, at de
forskellige ledelsesniveauer pa papiret var involveret
i projektet, men reelt ikke folte sig forpligtet.
Mål, organisation,
proces
74
Modenhed,
ganosation
or-
75
Ledelses,
ejerskab, organosation, parathed,
76
De har som sagsbehandlende myndighed
haft en traditionel, hierarkisk organisationsform,
der har passet darligt til organiseringen af et
IT-udviklingsprojekt, hvor der isar er brug for direkte
ledelsesadgang og ubureaukratiske beslutningsprocesser.
I praksis har det betydet, at projektorganisationen
har haft alt for lille beslutningskompetence,
og det har berovet projekterne den nodvendige
dynamik og fremdrift. Der har ogsa manglet forstaelse
af arbejdsformen, ansvarsfordelingen og kommunikationsvejene
– bade hos ledelse og medarbejdere
i organisationen og blandt de direkte
involverede i projektet.
For det tredje skal der arbejdes langt mere malrettet
pa at skabe en fælles bevidsthed i organisationen om
projektets formal, forlob og konsekvenser. Et IT-projekt
forudsatter en betydelig omlagning og harmonisering
af procedurer og arbejdsgange. Og uden en
udstrakt forstaelse af dette hos medarbejderne, vil
projektet uundgaeligt skabe usikkerhed eller direkte
modvilje i organisationen.
Ledelse, organisation, hierarki
77
Mål, organisation,
opbakning
78
Side 71 af 91
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 16
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 21
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 21
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
Erfaringer fra statslige
IT-projekter – hvordan
gør man det bedre?
Rapport og anbefalinger fra
en
arbejdsgruppe under Teknologirådet, 2001
S. 22
Professionalisering af arbejdet med it-projekter i staten
S. 23
Fravaret af erfarne og kompetente projektledere i
projektets startfase medforer, at der ikke fra begyndelsen
etableres en professionel projektstyring. Dermed
bliver det vanskeligt at styre og matche leverandoren,
nar det fx handler om fremdriftsstyring,
godkendelsesprocesser og kvalitetssikring af leverancerne.
Den mangelfulde forvaltning af projektledelsesansvaret
er i flere situationer blevet et
problem for bade kober og leverandor. For nar projektledelsen
ikke er stark nok til at skare igennem
og sortere og prioritere andringsforslagene, bliver
alt for mange uafklarede sporgsmal ved med at
dukke op som uoverensstemmelser mellem kober og
leverandor
Samtidig bruges de samme
konsulenter sjaldent som gennemgaende radgivere,
der kan patage sig et samlet ansvar for at folge og
koordinere hele processen. Det kan vare en af forklaringerne
pa, at konsulenterne i nogle tilfalde ikke
har haft en tilstrakkelig bred viden. I en rakke tilfalde
har koberen heller ikke varet klar nok over,
hvad de pagaldende konsulenters kompetencer
egentlig var.
Onsket om detaljerede
kontrakter bunder ikke mindst i, at de offentlige
myndigheder opfatter IT-projekter som afgransede,
tekniske anlagsopgaver. Det folger af denne opfattelse,
at man gennem en detaljeret kravspecifikation
kan designe sig frem til et noglefardigt IT-system.
De detaljerede kontrakter har ogsa faet uheldige
konsekvenser for styringen af projekterne. Den bliver
alt for meget praget af juridisk kontraktstyring
og alt for lidt af den fleksible projektstyring, der er
nodvendig for at udvikle et kompliceret IT-system.
Det bør være leverandørens
opgave løbende at forsyne køber med
ajourført relevant viden, der gør det muligt at vurdere
og styre projektets tekniske risici.
Projektledelse
79
Konsulent, viden,
80
Kravspec,
kontrakt, styrring
81
Leverandør,
svar, risiko
82
Skift i konsulenter
betyder ogsa ofte skift i projektmetoder og i dialogog
samarbejdsformerne. Det har i flere tilfalde fort
til uplanlagte og ukoordinerede metodeskift undervejs
i projektet og betydet, at viden og beslutninger
ikke er blevet overfort fra den ene fase i projektet til
den naste. Erfaringerne fra de undersogte projekter
viser, at der i skiftene mellem forskellige konsulenter
ofte opstar uhensigtsmassige brud eller problemer.
De it-projekter, der går godt, er præget af en god dialog mellem de statslige kunder, leverandørerne
og rådgiverne. Derfor er det væsentligt at samarbejdet mellem staten og leverandørerne forbedres.
Konsulenter,
83
Leverandør, samarbejde, konrakt
84
an-
Side 72 af 91
– Afrapportering fra arbejdsgrupen vedrørende bedre
statslige it-projekter, Maj
2010
Professionalisering af arbejdet med it-projekter i staten
– Afrapportering fra arbejdsgrupen vedrørende bedre
statslige it-projekter, Maj
2010
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 4
S. 4
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 4
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 9
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 9
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 10
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 10
Beretning om politiets it-
S. 10
s.9
Mindre omfattende kravspecifikationer. Meget omfattende kravspecifikationer med op til
flere tusinde krav kan vise sig at være en hæmsko for it-projekterne. Der igangsættes en række
pilotforsøg med anvendelse af forskellige metoder til kravspecificering med henblik på, at der
skal laves mere hensigtsmæssige kravspecifikationer.
Kravspec
85
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ækkende
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 itprojekt,
men et komplekst projekt, som ville få stor betydning for politiets organisation
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 sikrede
sig ikke, at leverandøren havde den nødvendige forståelse af politiets arbejdsprocesser.
Det medførte omfattende og fordyrende specialudvikling af en løsning,
der var baseret på et standardsystem.
Det er Rigsrevisionens vurdering, at Rigspolitiet ikke forberedte og styrede POLSAGprojektet 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 forberedende
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 understøtte,
og som kunne have hjulpet leverandøren i designet af POLSAG. Derfor
skete der et skred i designfasen, der betød, at det valgte standardsystem ikke
blev udnyttet godt nok, og at specialudviklingen blev øget. Det øgede projektets
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 tilstrækkelig
ledelsesmæssig forankring af udviklingen af POLSAG og dokumenterede
generelt ikke centrale milepæle.
Det er Rigsrevisionens vurdering, at Rigspolitiets forberedelse af POLSAG-projektet
på en række punkter var mangelfuld. Rigspolitiet udarbejdede tidligt en business case.
Den indeholdt usikkerheder i forhold til økonomien, og Rigspolitiet brugte eller opdaterede
den ikke efterfølgende, fx ved centrale milepæle som kontraktindgåelse, bevilling
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
Pris, overskridelse
86
Ledelse, styring,
engagement, konsulenter
87
Levrandær, processer, forståelse
88
Forberedelse,
styring,
89
Kompleksitet, risiko, standardsystem,
arbejdsgange,
processer, design
8.1.2.6
90
Ledelse, styrung
91
Milepæle, busniesscase
92
Leverandør, processer,
krav,
kompleksitet
93
Processer, tilpas-
94
Side 73 af 91
system POLSAG, Statsrevisorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 10
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 10
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 10
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 16
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 22
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 24
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 26
Beretning om politiets itsystem POLSAG, Statsrevi-
S. 26
S. 23
skræddersyet løsning baseret på et standardsystem.
ning
Rigsrevisionen vurderer, at kontraktgrundlaget indeholdt en række uhensigtsmæssigheder,
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.
Det er Rigsrevisionens vurdering, at Rigspolitiets styring af POLSAG ikke var tilstrækkelig
i et så stort og komplekst it-udviklingsprojekt. Frem til 2010 forankrede Rigspolitiet
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.
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ærksomhedspunkt
for ministerierne, hvordan de anvender og styrer eksterne konsulenter.
Særligt til projektledelse i længerevarende udviklingsprojekter, hvor behovet for
at sikre ejerskab og forankre viden og kompetencer i organisationen er stort.
For det første har Rigspolitiets ledelsesbehandling været karakteriseret
ved manglende skriftlig dokumentation. Rigspolitiet har oplyst, at alle væsentlige, overordnede
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 samarbejdsprocedurer,
der generelt var gældende i politiet på det tidspunkt. Derfor er ledelsesmæssige
overvejelser og beslutninger ikke dokumenteret. For det andet har Rigspolitiet kun i begræ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 beslutningsforum
for samarbejdet mellem Rigspolitiet og leverandøren.
Udviklingen af POLSAG-projektet var opdelt i såkaldte udviklingspakker. En del af fordyrelsen,
i alt 62,3 mio. kr. (2010-priser), skyldtes 2 nye udviklingspakker, der tilføjede ny funktionalitet
i forhold til de oprindelige krav.
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 tidsregistrering
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.
Udviklingstimer
Hovedkontrakten med
leverandøren var baseret
på timeforbrug.
Leverandøren fakturerede
efter forbrugt tid
svarende til antallet af
timer brugt på at udvikle
POLSAG. Værdien
af kontrakten svarede
derfor til et antal
timer.
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.
49. Rigsrevisionens undersøgelse af Rigspolitiets business case for POLSAG har vist følgende:
Rigspolitiet udarbejdede en business case ved opstarten af POLSAG-projektet, selv om
Kontrakt,
pæle
mile-
7.1.1
95
Styring, ledelse,
organsation
7.1.1
96
Styring, ejerskab,
Bonnerup
97
Dokumentation,
aftale
98
Udviklingspakker,
kravspec
99
Ressourceforbrug
100
Timer, kontrakt,
ressourcer
101
Krav, process, leverandør
102
Businesscase
7.1.3,
Side 74 af 91
103
sorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 27
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 27
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 27
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 27
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 28
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 28
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 28
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevi-
S. 28
S. 27
S. 28
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.
20 RIGSPOLITIETS FORBEREDELSE AF POLSAG
Justitsministeriet og Rigspolitiet burde forud for udvidelsen af projektet i 2010 have udarbejdet
en business case for at have et bedre grundlag for at vurdere POLSAGs fremtid.
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 efter
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.
Rigspolitiet har fremhævet, at POLSAG blev igangsat som et nødvendigt infrastrukturprojekt
mere end som et effektiviseringsprojekt. POLSAG skulle primært udskifte POLSAS.
Rigspolitiet har oplyst, at Rigspolitiet ikke definerede fordelene ved POLSAG yderligere eller
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 stammede
fra den eksterne leverandøranalyse, der lå til grund for Rigspolitiets indledende leverandørvalg
i 2005. Konsulenten, der foretog leverandøranalysen, bad leverandøren belyse økonomien
i Captia-løsningen yderligere, men fik ikke flere oplysninger.
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.
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. POLSAG
endte med at blive en skræddersyet løsning baseret på et standardsystem, hvor
POLSAG blev tilpasset Rigspolitiet og ikke omvendt.
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 forudsat
i kontrakten. Det skyldtes bl.a., at Rigspolitiet og leverandøren ofte fortolkede 1:1kravet sådan, at POLSAG skulle understøtte politiets arbejdsprocesser på præcis samme
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 forudsat
større forretningsanalyser, hvis POLSAG skulle have udnyttet Captia bedre. Det er
Rigsrevisionens vurdering, at Rigspolitiet burde have sikret et bedre grundlag for at begrænse
omfanget af specialudvikling.
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 opmæ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.
57. Udviklingen af Rigspolitiets krav til POLSAG skete i 3 trin – foranalysen, analysefasen
og designfasen.
3 trin i udviklingen af
krav
Businesscase,
Bonnerup
104
Infrastruktur, effektivisering,
105
Pris, usikkerhd,
økonomi
106
Regerytteri, businesscase
107
Krav,
108
Krav
8.1.4.1
109
Krav, processer,
forretning
110
FESD, Standardsystem,
teknik,
Captia
111
Udvikling
112
Udvikling, krav
113
Side 75 af 91
sorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 28
Foranalysen: Rigspolitiet
definerede sammen
med en ekstern
konsulent behov til
POLSAG.
Analysefasen: Rigspolitiet
formulerede krav
til POLSAG, og leverandøren
beskrev løsninger,
inden parterne
underskrev kontrakten.
Designfasen: Underleverandøren
designede
POLSAG i samarbejde
med hovedleverandøren
og Rigspolitiet efter
indgåelsen af kontrakten.
Designet blev
dokumenteret i såkaldte
systemdesigndokumenter.
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 itekspert
har gennemgået behovene. Gennemgangen viser, at behovene beskrev, hvad systemet
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. Rigspolitiet
beskrev i alt 260 behov.
Behov, krav, analyse, leverandør,
Captia
114
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
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 29
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 29
Inden for FESD-rammeaftalen var det muligt at udarbejde kravspecifikationen og løsningsbeskrivelsen
sammen med leverandøren. Det anses generelt for en fordel. Rigspolitiet og leverandø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 hvilken
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 stillede
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 POLSAS.
BOKS 3. FORMULERINGEN AF 1:1-KRAVET
”Al nuværende funktionalitet i POLSAS skal tilvejebringes på en brugervenlig måde i det nye
POLSAG.
Ved tilvejebringelse af tilsvarende funktionalitet som i POLSAS i dag forstås etablering af funktionalitet
– baseret på Captia-løsningen – som understøtter samme forretningsprocesser og løser samme
opgaver, som det eksisterende POLSAS gør i dag.”
Krav, Polsas,
7.1.3
Krav, Polsas
115
116
Side 76 af 91
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 29
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 29
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 29
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 30
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 30
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 30
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 30
Beretning om politiets it-
S. 30
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 politiets
arbejdsprocesser ligesom POLSAS med udgangspunkt i Captias muligheder. Alternativt
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 underleverandøren
og beskrev i grove træk, hvordan skærmbilleder og anden funktionalitet i
det eksisterende POLSAS kunne erstattes af funktionalitet i Captia. Rigsrevisionens eksterne
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 udgangspunkt
i at bruge standardsystemets muligheder.
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.
Polsag,
Polsas,
Krav,
styring,
kontrakt, processer
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 politifolk
(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 detaljeret,
hvad hver knap skulle gøre i forskellige situationer. Det var underleverandøren, der skrev designdokumenterne.
Underleverandøren har bl.a. anført, at det kunne være svært for udviklerne at afvise,
at krav ikke skulle opfyldes på en bestemt måde, når den tilsvarende POLSAS-funktionalitet ikke
var beskrevet, og det ikke var klart, hvad funktionaliteten skulle bruges til. Samtidig oplevede underleverandø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 brugerne
påpegede rapporten bl.a., at projektledelsen skal udfordre og prioritere brugernes krav. Projektledelsen
skal endvidere sørge for, at projektets målsætninger er kendte for at undgå, at brugerne
stiller krav til systemet, der bygger på forskellige forestillinger om, hvad systemet skal bruges til,
og hvilke forretningsgange det skal understøtte.
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 udnyttet
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 september
7.1.3
117
Løsning af krav,
krav, skærmbilleder, standardsystem
118
Captia, tabeller,
løsning, kompleksitet,
standardløsning
119
Krav, processer,
leverandør, Captia
120
Krav,
leverandør, processer,
bruger
Bruger
121
Krav,
bruger,
processer, Bonnerup
122
Proces,
standardsystem,
krav
123
Krav, processer,
124
Side 77 af 91
system POLSAG, Statsrevisorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 31
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 31
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 31
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 32
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 32
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 32
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 33
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 33
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S: 35
2008. Rigspolitiet udskød brugen af mere standardfunktionalitet til en senere version
af POLSAG. Parterne konkluderede, at et eventuelt senere projekt om at forbedre POLSAG
skulle tage udgangspunkt i politiets forretning og processer, og at de personer, der skulle
involveres, skulle have viden om den daglige brug af POLSAG og forretningsprocesserne.
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å leverandø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 fastsatte
svartider for POLSAG, men stadigvæk give brugeren en utilfredsstillende oplevelse
af svartiderne, når randsystemerne blev koblet 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 ikke
fakturere over det til enhver tid akkumulerede beløb i betalingsplanen, og Rigspolitiet kunne
tilbageholde 10 % af beløbet i betalingsplanen. Hovedkontrakten var den økonomisk største.
Det er efter Rigsrevisionens opfattelse forbundet med styringsmæssige vanskeligheder i et
udviklingsprojekt som POLSAG ikke at sikre en kobling mellem betalinger og leveret funktionalitet
eller andre dokumenterede resultater. I yderste konsekvens risikerer kunden at betale
for en ydelse, som ikke bliver leveret. Denne problemstilling skal ses i lyset af, at funktionaliteten
i hovedkontrakten ikke var opdelt i selvstændigt værdiskabende faser. De forskellige
udviklingspakker var indbyrdes afhængige og kunne ikke fungere selvstændigt. Rigspolitiet
kunne fx ikke tage den første udviklingspakke i brug. Systemet skulle tages i brug som
en samlet løsning.
udskydelse,
68. Justitsministeriet har oplyst, at det på tidspunktet for kontraktens indgåelse var Rigspolitiets
vurdering, at der i FESD-kontraktvilkårene ikke var mulighed for at indgå en leveranceaftale
med en betalingsplan knyttet til milepæle, som sikrede en kobling mellem betaling og
leveret funktionalitet.
Kontrakten indeholdt krav til svartider for selve POLSAG-systemet, men ingen konkrete svartidskrav
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 muligheder
for at sikre tilfredsstillende samlede svartider for POLSAG.
Rigspolitiet har oplyst, at det ikke var muligt for Rigspolitiet at få leverandøren til at garantere
svartider for systemer, leverandøren ikke selv havde ansvaret for. Rigsrevisionens eksterne
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 leverandøren.
POLSAG-programmet var fra starten placeret i Rigspolitiets dataafdeling og var i perioden
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 organisationen
og i den øverste ledelse. I 2010 etablerede Rigspolitiet en intern styregruppe
med stærkere ledelsesmæssig forankring.
FESD, kontrakt,
leverance, betaling
130
Svartider, kontrakt
131
Svartider, kontrakt, leverandør, krav
132
Styring,
ledelse
133
Kontrakt,
randør
leve-
8.1.2.4
125
Kontrakt, timer,
leverancer, leverandør, milepæle
126
Krav, svartider
127
Kontrakt, milepæle, betaling,
leverandør
128
Kontrakt,
styring, milepæle
129
krav,
Side 78 af 91
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 35
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 36
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 36
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 36
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 36
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 37
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 37
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 38
S. 36
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 Rigsrevisionens
opfattelse begrænset Rigspolitiets løbende overblik over det hidtidige sagsforløb
i et så omfattende og langstrakt projekt.
75. Bonnerup-rapporten fra 2001 pegede på, at it-projekter skal forankres stærkt i den øverste
ledelse. Især ved et stort it-udviklingsprojekt, der altid vil have konsekvenser for en organisations
arbejdsprocesser.
76. POLSAG-projektet var fra projektets start placeret i Rigspolitiets dataafdeling med en
programleder til at varetage projektledelsen med reference til afdelingschefen for dataafdelingen.
Projektets placering i dataafdelingen som et rent it-projekt gav efter Rigsrevisionens
opfattelse ikke projektledelsen mulighed for at træffe beslutninger om de fremtidige arbejdsprocesser
i POLSAG på tværs af hele politiet.
I september 2005 nedsatte rigspolitichefen en intern styregruppe. Rigspolitichefen var formand.
Styregruppens formål var at følge projektet og drøfte principielle spørgsmål. Rigsrevisionens
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 generelt
tale om orienteringer og beskrivelser af status og indhold i relation til POLSAGs fremdrift.
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.
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. POLSAGprojektet blev organisatorisk placeret i en nyetableret projektafdeling.
Rigspolitiet vurderer, at den nye organisering i 2010, på trods af sin korte aktive levetid, medførte
en samlet styrkelse af arbejdet med POLSAG, men at det dog var vanskeligt at opnå
den fulde effekt i så fremskredent et program.
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 sagsgennemgang
kun fundet dokumentation for 1 skriftlig forelæggelse for rigspolitichefen om POLSAG,
og Rigspolitiet har ikke kunnet identificere yderligere.
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 driftsmæssige
spørgsmål løbende blev drøftet med og godkendt af den daværende chef for Rigspolitiets
ø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 overblik
over det hidtidige sagsforløb i et så omfattende og langstrakt projekt.
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 organisationen
selv, ligesom kunden ikke bør overdrage centrale ledelsesopgaver i organisationen
til en ekstern part, der hverken er underlagt politisk eller økonomisk ansvar.
86. Rigspolitiet brugte forskellige typer konsulenter. Nogle løste specifikke tekniske opgaver,
fx test, mens andre løste mere almindelige projektledelsesopgaver. Konsulentudgifterne
fordelte sig ifølge Rigspolitiets egen opgørelse med ca. 61 % til tekniske specialister og
Manglende
skriftelighed,
styring, krav
134
Bonnerup, ledelse, styring.
processer
Processer, styring, ledelse,
135
Styregruppe,
ledelse, styring
136
8.1.2.3
Styregruppe,
styring, ledelse,
Dokumentation,
styring, ledelse
137
138
8.1.1
139
Dokumentation
140
Ansvar, Bonnerup,
ledelse,
styring, økonomi
141
Konsulenter,
styring
8.1.2.4,
8.1.3.3
Side 79 af 91
142
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 38
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 38
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 39
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 40
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.
88. Rigsrevisionens undersøgelse har også vist, at eksterne konsulenter har varetaget centrale
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, rekrutterede
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 oplyst,
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 involvering
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 funktioner,
som var tiltænkt programchefen.
Regnearket blev brugt til at opstille budgetter på baggrund af fx betalingsplaner og indgåede
kontrakter. Modtagne fakturaer blev registreret i regnearket forud for betalingen i regnskabssystemet,
hvilket gav et aktuelt billede af udviklingen i budgetter og forbrug under POLSAGprogrammet. Regnearket gjorde det dermed muligt for programmets økonomiansvarlige
at følge budgetter og forbrug. Regnearket gjorde det også muligt for Rigspolitiet at udarbejde
detaljeret økonomistyringsinformation på en række forskellige parametre, fx kontraktniveau,
udgiftstyper og aktivitetsområder.
Rigspolitiet har oplyst, at rapporter fra regnearket blev brugt i budgetrapporteringen til ledelsen
og de programansvarlige. Rigspolitiet har ikke kunnet dokumentere ledelsesbehandlingen
af projektets økonomiske status, da Rigspolitiet ikke har gemt materialet.
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 systematisk
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.
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 Rigspolitiet
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 overtage
POLSAG, selv om nye fejl samlet set havde bragt POLSAG over acceptkriterierne. Rigspolitiet
kom derfor i en situation, hvor leverandøren ikke var forpligtet til at håndtere eventuelle
nye alvorlige fejl inden pilotdriften. Nye fejl skulle i stedet håndteres som en del af vedligeholdelsen
af POLSAG.
Konsulent, styring, magt, ansvar
8.1.2.3
Øknomi, styring,
excel, Navision
143
144
Fejl,
8.1.2.4
145
Kontrakt, fejl,
leverandør, styring
8.1.2.4
146
Side 80 af 91
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 41
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 42
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 43
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
. 44
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 46
Beretning om politiets itsystem POLSAG, Statsrevi-
S. 47
S. 45
S. 46
Fejl. Kontrakt,
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 Rigspolitiet
og leverandøren fik viden om, hvordan systemet virkede med rigtige brugere, og her kunne
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 Rigspolitiet
dog, at der var mulighed for at finde fejl i en almindelig driftssituation i en lille politikreds,
inden POLSAG skulle rulles ud til de resterende politikredse.
Rigspolitiets uddannelse af brugerne på Bornholm var mangelfuld, og Rigspolitiet støttede
ikke brugerne til at forstå, hvordan det nye system skulle bruges. Det er Rigsrevisionens
opfattelse, at brugerne i vid udstrækning forventede et system, der kunne bruges i
dagligdagen, mens der reelt var tale om en anvendelsestest.
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.
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æsentlige
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. Rigspolitiet
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.
115. Kontrakten havde mål for, hvor hurtigt leverandøren skulle starte på at rette konstaterede
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 Rigspolitiets
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.
Ca. 1 år efter starten på pilotdriften konstaterede Rigspolitiet, at der var behov for at gennemgå
sagsprocesserne på Bornholm. I den forbindelse skulle det besluttes, hvem der skulle gøre
8.1.2.4
147
Test
148
Test, bruger
149
Fejltyper, fejl,
150
Fejl, integration,
leverandør
151
Kontrakt,
styring
fejl,
152
Fejl,
kontrakt,
styring
153
Test, arbejdsprocesser,
bruger,
8.1.1,
8.1.4.5
Side 81 af 91
154
sorne 2012-13
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 47
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 47
Beretning om politiets itsystem POLSAG, Statsrevisorne 2012-13
S. 48
Boston Consulting group –
Eksterns review 2009
S. 10
Boston Consulting group –
Eksterns review 2009
S. 10
Boston Consulting group –
Eksterns review 2009
S. 11
Boston Consulting group –
Eksterns review 2009
S. 12
Boston Consulting group –
Eksterns review 2009
S. 12
hvad og hvornår, hvilket ville blive integreret i den uddannelsesindsats, der var under planlæ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 opfattelse,
at brugerne i en lang periode havde dårligere betingelser for at udnytte systemet i sagsbehandlingen.
120. Det fremgår af baggrundsmaterialet til evalueringen af pilotdriften på Bornholm, at brugerne
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 Rigspolitiet
ikke i tilstrækkelig grad sikrede, at brugernes forventninger var afstemt med det faktum,
at pilotdriften reelt var en anvendelsestest, hvor brugerne måtte forvente, at der ville opstå
fejl, og at der ville gå tid, før systemet kunne bruges optimalt.
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øgte
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.
Rigspolitiet har oplyst, at leverandøren i stigende grad fokuserede på kontraktens svartidsgarantier,
efterhånden som projektet blev forsinket, og tidsplanen blev mere presset. Endvidere
satte kontrakten ikke Rigspolitiet i stand til at udvide testen af svartider til de samlede
svartider eller fremrykke leverandørens måling af svartiderne.
Leverandørerne af POLSAG (CSC/Scan Jour) er i stand til at levere et system, som opfylder de kvalitetskrav, der er fastsat i deres kontrakt med Rigspolitiet, og at POLSAG vil indeholde den funktionalitet, der er beskrevet i Aktstykke 119 – bortset fra udviklingen af et datawarehouse, der bliver
erstattet af forbedrede rapporteringsfaciliteter i POLSAG. Det vurderes endvidere, at den funktionalitet, som POLSAG kommer til at indeholde, understøtter arbejdsgange i politikredsene.
Det vurderes, at den oprindelige aktstykkebevilling stort set overholdes. Udgifterne til anskaffel-se og
etablering af POLSAG, jf. Aktstykke 119, på 221 mio. kr. (pristalsreguleret til 229 mio. kr.) forventes
på nuværende tidspunkt således alene overskredet med ca. 5 mio. kr.
Der på nuværende tidspunkt er en enkelt faktor, som bidrager til at skabe relativ stor usikkerhed om
POLSAG programmets endelige omkostninger, tidsplan, og kvalitet af løsningen, idet der i forbindelse med en brugertest – forud for gennemførelsen af en egentlig performancetest – er identificeret en potentiel udfordring med systemets performance (svartid).
Ved gennemgang af udvalgte dele af koden kan vi konstatere, at standardteknikker for at fremme
performance ikke er implementeret. Vi kan endvidere konstatere, at det specifikke design og implementering af interfaces til eksterne systemer heller ikke har benyttet best-practice løsninger for at
understøtte optimal performance. De valgte løsninger skaber derfor en betydelig risiko for, at systemets performance ikke vil være tilfredsstillende.
For at vurdere risikoen for øgede omkostninger – som følge af performance-problemerne – skal det
bemærkes at kontrakterne med CSC/ScanJour efter vores opfattelse indeholder en væsentlig uhensigtsmæssighed idet der i kontrakterne ikke angivet et eksplicit (og kvantificeret) krav til end-to-end
performance.
Der er fastsat individuelle svartidsgarantier for selve POLSAG-systemet og for integrationsdelen (integration layer). Svartidsgarantier for at tilgå randsystemer (peripheral systems) fra POLSAG er derimod ikke kvantificeret, idet der er anført, at svartiden skal være ”rimelig”. På grund af måden hvorpå
de garanterede svartider måles, risikeres det desuden, at virkelige svartider kan være lange selvom
garantierne overholdes. Afhængig af type og omfang af performance-problemerne er der derfor en
risiko for, at Rigspolitiet som opdragsgiver kan komme til at betale for dele af arbejdet med at udbed-
uddannelse
Forventning, test
155
Svartider,
risiko
test,
156
Kontrkt, svartider, forsinkelse
157
Kontrakt, leverandør, resultat
158
Pris, budget
159
Performance,
svartid
160
Best-practice,
svartid, performance
161
Krav, svartider,
leverandør
8.1.2.4,
8.1.4.1
Side 82 af 91
162
re problemerne. Alternativt er der en risiko for at politiet må leve med et system, som har en for brugerne ikke-tilfredsstillende performance i visse sammenhænge.
Boston Consulting group –
Eksterns review 2009
S. 13
Boston Consulting group –
Eksterns review 2009
S. 25
Boston Consulting group –
Eksterns review 2009
S. 25
Boston Consulting group –
Eksterns review 2009
S. 25
Boston Consulting group –
Eksterns review 2009
S. 25
Vi baserer denne konklusion på det faktum, at POLSAG-programledelsen for nylig har igangsat et
større og grundigt arbejde med at udvikle og validere sådanne best-practice målprocesser, og at der
8
indtil nu i denne proces ikke er identificeret afgørende mangler i systemet. Eftersom målprocesser
ikke blev defineret i forbindelse med systemdesignfasen, er der dog en risiko for, at de efterfølgen-de
udviklede best-practice målprocesser i en vis udstrækning tilpasses systemet – og ikke omvendt – på
bekostning af procesperformance. Alternativt risikeres det med denne rækkefølge at der vil op-stå
yderligere systemkrav. Risikoen for sidstnævnte vurderes dog som værende lille, givet hvor langt
POLSAG-programledelsen er kommet i samarbejde med udvalgte kredse.
Resultatet af foranalysen var en liste over prioriterede behov som politiet ønskede inkluderet i det
nye sagsbehandlingssystem. For at identificere disse behov blev seks processer relateret til sagsbehandling analyseret dækkende fem gængse sagstyper (f.eks. indbrud og hastighedsovertrædelser)
samt døgnrapportering. Desuden blev en arbejdsgruppe med deltagelse fra kredsene nedsat til at
vurdere muligheden for et elektronisk sagsflow i politiet. De valgte processer blev prioriteret ud af
mere end 100 processer, da disse ansås kumulativt at kunne dække funktionaliteterne i et nyt sagsbehandlingssystem. For de fem sagstyper blev der udviklet detaljerede procesdiagrammer baseret på
eksisterende politiprocesser, og der blev lavet en funktionalitetsbeskrivelse for døgnrapporterin-gen.
Disse blev udviklet med input fra tre kredse; Lyngby, Roskilde og København og blev valideret i
workshops med POLSAG-programmets analysegruppe, som består af repræsentanter fra de forskellige politiforbund såvel som repræsentanter for anklagemyndigheden.
Samlet set blev der identificeret 418 funktionelle og tekniske behov på baggrund af ovenstående arbejde. En vurdering af omkostninger, risici og fordele ved hvert identificeret behov dannede grundlaget for en efterfølgende prioritering, hvor 258 behov blev tilvalgt og 160 fravalgt. Denne
prioriteringsproces foregik med indspil fra både analysegruppen og POLSAG-styregruppen.9
Under kravspecifikations- og løsningsbeskrivelsesfasen har IT & Tele og CSC/ScanJour arbejdet i en
iterativ parallel proces. I denne proces kravspecificerede IT & Tele de prioriterede behov. Use-cases
blev benyttet såfremt et behov var kompleks. Baseret på disse kravspecifikationer og use-cases udviklede CSC/ScanJour en løsningsbeskrivelse for hvordan og om et givent behov kunne løses af Captia
– og hvis nødvendigt – hvilken type udvikling det ville kræve. Ligeledes udviklede CSC/ScanJour også
prototyper i denne fase. På grundlag af disse løsningsbeskrivelser blev yderlige-re 50 behov fravalgt,
da leverandøren ikke fandt Captia-systemet i stand til at løse disse specifikke behov. De resterende
kravspecifikationer og løsningsbeskrivelser dannede herefter grundlag for CSCs tilbud til IT & Tele.
9 Kilde: ”Svar på spørgsmål ang. POLSAG foranalyse, kravspecifikation og system design”, PA Consulting; Interviews. Styre-gruppen er den overordnede referenceenhed for POLSAG programmet, bl.a.
med deltagelse af Rigspolitichefen.
Det er BCGs opfattelse, at den ovenfor beskrevne proces med at udarbejde systemkrav bar præg af én
overordnet svaghed, idet målprocesser ikke eksplicit blev defineret og udarbejdet på trods af at den
gængse “tekstbog-fremgangsmåde” i forbindelse med it-systemdesign foreskriver at definere og
udarbejde målprocesser først, hvorefter systemkrav fastlægges med udgangspunkt i disse. Hvis man
ser bort fra manglen på målprocesser, er det vores opfattelse, at den overordnede proces med at definere systemkrav har været struktureret og omfattende, hvilket der er fire årsager til:
Der er et naturligt flow fra processer til behov til kravspecifikationer
Målprocesser,
arbejdsprocesser,
krav
8.1.2.2,
163
Krav, processer
8.1.4.4
164
Krav, proseccer
165
Krav,processer,
use-cases, leverandør
166
Krav, målprocesser, bruger,
167
Processen bar præg af tidlig og omfattende involvering af interessenter med en god blanding af personer med brugerperspektiv og IT-kompetencer – også inden for IT & Teles POLSAGteam10
Tilsyneladende sund logik bag prioriteringskriterierne til prioritering af processer, behov
og systemkrav11
Den iterative proces under kravspecifikation- og løsningsbeskrivelsesfasen, brugen af use-
Side 83 af 91
cases for kravspecifikation og prototyper for løsningsudvikling er god praksis12
Boston Consulting group –
Eksterns review 2009
S. 26
Boston Consulting group –
Eksterns review 2009
S. 28
Målprocesser, procesdiagrammer, procesbeskrivelser og brugermanualer bliver udformet og valideret sammen med repræsentanter fra to kredse, Midt-/Vestjylland og København. Herefter bliver disse
godkendt af analysegruppen – og i sidste ende styregruppen. Det har været en velovervejet strategi
fra POLSAGs programledelse at involvere kredsene for at sikre, at processerne er i overensstemmelse med hvordan kredsene ønsker at arbejde. Grunden til at Midt- & Vestjylland og København er udvalgt til at repræsentere kredsene er, at de anses at dække politiets forskellige perspektiver og behov – København som den store og tætbefolkede kreds, og Midt- & Vestjylland som den
spredte kreds. Midt- & Vestjylland og København er primært involveret via workshops, hvor processerne er blevet valideret en for en.
Giver et klart ansvar til kredsen ved udpegelse af et projektteam, en projektleder og en
styringsgruppe alle med forankring i kredsen
Proces,
bruger,
shops
krav,
work-
168
implementering
169
Captia, kontrakt,
leverandør
170
Tager direkte fat på udfordringerne relateret til forandringsledelse (change management)
gennem kortlægning og sammenligning af eksisterende politiprocesser i kredsene med de udviklede
best-practice målprocesser for at afdække behov for ændringer i kredsene
Sikrer nødvendig vidensoverdragelse gennem træning af superbrugere og slutbrugere
med et meget begrænset tidsinterval mellem træning og go-live datoen
Yder efterfølgende go-live support ved at have repræsentanter fra POLSAG-projektteamet
tilsted i kredsene (f.eks. ved floorwalking) til at støtte og assistere kredsene efter go-live da-toen
Boston Consulting group –
Eksterns review 2009
S. 37
Boston Consulting group –
Eksterns review 2009
S. 38
Boston Consulting group –
Eksterns review 2009
S. 43
Boston Consulting group –
Eksterns review 2009
Boston Consulting group –
Eksterns review 2009
S. 43
S. 45
ScanJours svar på den anden af de to ovennævnte problemstilling er, at POLSAGs portabilitet aldrig
har været et krav fra IT & Tele, og derfor ikke har været et design- og udviklingsmål i sig selv. Som
følge heraf er ScanJour gået efter et mere tæt koblet systemdesign for dermed at undgå indsatsen og
omkostninger til klart og stringent a indkapsle Captia-kernen og kaldene til eksterne systemer
Hele kodeblokke der er udkommenteret
•• Unødigt lange og sammensatte moduler
• Unødvendig gentagen kode, fordi kodesekvenser er blevet kopieret og delvist tilpasset i stedet for at
benytte parametre til at holde koden koncis • Utilstrækkelig separation af lokalt anvendte funktioner
og generel anvendte funktioner, samt utilstrækkelig dokumentation af hvor generelle funktioner anvendes
• Ingen klar separation af name spaces mellem Captia-kernen og POLSAG-objekterne. (Der eksisterer
dog separate biblioteker til kerneobjekter og POLSAG-objekter, som tillader klar identifikation via
simple opslag)
Det er imidlertid et faktum, at de valgte teknologiske platforme skaber unødig kompleksitet. For så
vidt angår teknologiske platforme har såvel Microsoft, Oracle og IBM deres egne komplette anerkendte produktudbud, som kan opfylde alle POLSAGs nødvendige teknologilag. F.eks. ville en beslutning om at have implementeret POLSAG i et rent Microsoft- eller Oracle-miljø have forenklet arbejde med at planlægge og vedligeholde teknologimiljøet. Derudover kunne dette også have medført
højere produktivitet i livscyklusen for softwareudvikling.
Det har været et krav fra politiet, at leverandørerne ”prøver at holde sig til åbne standarder” som defineret af World Wide Web Consortium, hvilket forbedrer interoperabilitet og portabilitet.
På trods af at CSC/ScanJour, når der ses bort fra tidslinjen, vurderes at kunne levere et produkt som
lever op til kvalitetskravene i kontrakten, er det BCGs vurdering, at der er en risiko for at politiet får et
system som ikke leverer tilfredsstillende performance for brugerne selvom de kontraktlige krav
overholdes.
Kode, kvalitet,
produkt
8.1.3.1
171
Kompleksitet,
teknologi
172
Krav, kompleksitet
Krav, spartid
173
Side 84 af 91
174
Boston Consulting group –
Eksterns review 2009
S. 45
Boston Consulting group –
Eksterns review 2009
S, 50
Boston Consulting group –
Eksterns review 2009
S 52
Desuden er der en klar risiko for, at det endelige produkt, selvom det overholder de kontraktlig forpligtigede funktionaliteter og performance, ikke vil leve op til best-practice standarder i forhold til
den tekniske løsning.
For hver af de specificerede transaktionstyper bliver svartiden i forbindelse med måling af garanti-er
målt for 20 gentagne transaktioner. For alle svartidsgarantier gælder ifølge kontrakten, at 1) de garanterede svartider for hver transaktion skal være opfyldt for mindst 19 ud af 20 målinger og 2) at
svartidskravet skal være opfyldt for gennemsnittet af alle 20 målinger for en given transaktion.
Eftersom det ikke eksplicit fremgår af kontrakten, at de 20 målinger ikke må cache resultaterne af den
første dataforespørgsel og genbruge disse for de næste 19 dataforespørgsler i forbindelse med måling
af svartidsgarantier, er der en risiko for, at dette vil ske i forbindelse med svartidsmåling i henhold til
garantien (hvorved garantien overholdes), men ikke kan ske, når systemet er i brug i virkeligheden.
Denne risiko er i sagens natur kun relevant for de transaktioner, som ikke kan drage fordel af caching
i virkeligheden, hvilket især gælder for transaktioner, som ikke kaldes ofte. Ved en screening af de
transaktioner, som har en defineret kontraktlig svartidsgaranti har BCG fundet ek-sempler på netop
sådanne transaktioner (f.eks. Oprettelse af døgnrapport), hvilket øger risikoen for at POLSAG fra en
brugers perspektiv vil have utilfredsstillende performance på trods af, at de kon-traktlige forpligtelser overholdes af CSC/ScanJour.
For det andet fremgår det i kontrakten, at alle performancemålinger skal foretages fra en klientarbejdsplads, der er tilkoblet serverne direkte eller være tilkoblet netværket i umiddelbar tilknytning til
back-bonen af netværket.49 Eftersom kodegennemgangen af POLSAG har vist, at der er et muligt performance-problem, som netop vedrører kommunikationen mellem applikationen og serveren, vil dette mulige problem ikke blive omfattet af de kontraktlige fastsatte svartidsmålinger, hvorved det kan
således påvirke systemets performance fra en brugers perspektiv yderligere negativt, selv-om de
kontraktuelle krav overholdes.
betragtning af den anslåede budgetoverskridelse på 18-22 mio. kr. er det overvejende sandsynligt, at
ScanJour vil imødese et nyt stort tab i indeværende regnskabsår. Dette rejser spørgsmål som:
Vil ScanJour være i stand til at absorbere tabene og fortsætte som en going concern?
Krav, kvalitet
Kontrakt,
svartid
8.1.1
175
krav,
176
Krav,
leverandør,
økonomi,
risiko
177
Milepæle, kontrakt, krav
178
Kontrakt,
pæle
179
Vil økonomiske problemer resultere i tab af nøglemedarbejdere?
Vil økonomiske problemer resultere i mangelfuld investering i Captia-platformen?
Boston Consulting group –
Eksterns review 2009
S. 55
Boston Consulting group –
Eksterns review 2009
S. 55
Ved udgangen af regnskabsåret 2007/08 havde ScanJour en positiv egenkapitalbeholdning på 31 mio.
kr., hvilket på kort sigt er en relativt sikker margin sammenlignet med sidste års tab -9 mio. kr. Det
står dog klart, at ScanJour ikke har råd til alt for mange negative år inden den nuværende egenkapital
løber tør. Ved udgangen af regnskabsåret 2007/08 var ScanJours likviditet 8 mio. kr. I betragtning af
størrelsen af det potentielle tab i år, og under forudsætning af at et forventet tab i nettoresultatet vil
udmønte sig i et tilsvarende negativt cash-flow, vil ScanJour ikke have likviditet tilbage ved udgangen
af året medmindre yderligere likviditet tilføres.
BCG anser den økonomiske risiko forbundet med ScanJour for tilstedeværende. Såfremt de identificerede performance-problemer skal udbedres og omkostningsmæssigt afholdes af leverandørerne,
vil denne risiko stige og vil således kunne påvirke tidslinje og vilje/evne til at foretage fremtidige investeringer i innovation af Captia-platformen.
I ethvert it-projekt er den historiske overholdelse af milepæle et nyttigt udgangspunkt for at vurde-re
realismen i den resterende del af tidsplanen. For POLSAG er det dog meget vanskeligt at foreta-ge sådanne sammenligninger mellem planlagte og faktiske milepæle på en meningsfuld måde. Dette skyldes to sammenhørende forhold, nemlig opbygningen af leverandørkontrakterne og leve-randørernes
registrering af tidsforbrug. Samlet set slører disse forhold billedet betydeligt, hvis man forsøger at lave 1:1-sammenligninger
FESD-kontrakten er baseret på et ”ansvarligt estimat” af det tidsforbrug, der er nødvendigt for at
gennemføre projektet, mens T14-kontrakten er en fastpriskontrakt.57 For FESD-kontraktens ved-
mile-
Side 85 af 91
kommende betyder dette, at CSC er forpligtet til at registrere det faktiske tidsforbrug for POLSAG for
at kunne fakturere RP. Baseret på den information, som BCG har været i stand til at fremskaffe fra RP,
CSC og ScanJour, har det imidlertid ikke været muligt at sammenkoble denne tidsregistre-ring med
specifik funktionalitet.
Boston Consulting group –
Eksterns review 2009
S. 58
Boston Consulting group –
Eksterns review 2009
S. 58
Boston Consulting group –
Eksterns review 2009
S: 61
Boston Consulting group –
Eksterns review 2009
S. 62
Boston Consulting group –
Eksterns review 2009
S. 74
Rigspolitiet fyrer it-chef –
Version2
(Thomsen 2012)
På et kvalitativt niveau fremhæver CSC en række specifikke kilder til forøget kompleksitet, herun-der
bearbejdning og re-design af Captias standarddatamodel, diverse integrationer (primært til Bødesystemet), rollerettigheder og døgnrapporten.66 I bredere forstand har projekt-setup’et med parallelle
og indbyrdes afhængige design- og udviklingsfaser også medført, at det ved flere lejlighe-der har været
nødvendigt med tilbageløb, dvs. at foretage rettelser/tilføjelser i arbejde udført i tidli-gere faser. Som
følge heraf er produktiviteten blevet negativt påvirket.
En yderligere årsag til de markante estimeringsfejl kan potentielt findes i sammenspillet mellem leverandørkonstellationen og kravspecifikationen. Ét af de centrale krav i kravspecifikationen er, at
POLSAG skal indeholde funktionalitet svarende til POLSAS (se Afsnit 4.1.2 for yderligere informa-tion).
Et sådan krav indebærer naturligvis, at det er afgørende at have endog yderst detaljeret viden om
POLSAS for på pålidelig vis at kunne estimere det nødvendige tidsforbrug for at udvikle sammenlignelig funktionalitet i POLSAG. Mens CSC således har dybdegående viden om POLSAS qua sine
drifts- og vedligeholdelsesaftaler med RP, ligger ScanJours ekspertise imidlertid først og frem-mest inden for Captia-standardsystemet, dvs. grundlaget for POLSAG. Som konsekvens af dette var asymmetrisk information mellem CSC og ScanJour sandsynligvis til stede, da tidsforbruget i forbin-delse med
POLSAG blev estimeret og lagt til grund for FESD-kontrakten. I begyndelsen af projekt-forløbet kan
kommunikationsbrister mellem CSC og ScanJour om kravene til funktionaliteten i POLSAG således have bidraget til de betydelige estimeringsfejl.
Ifølge POLSAG-programledelsen var der imidlertid tre svagheder ved den oprindelige implementerings-plan. For det første fokuserede den oprindelige implementeringsplan på teknisk implementering, hvorfor den ikke inkluderede tilstrækkelig forandringsledelse og forankring i den decentrale
politi-organisation. For det andet benyttede den oprindelige implementeringsplan én pilotkreds,
hvoref-ter de øvrige kredse skulle idriftsættes stort set samtidigt i et ”big-bang”, der var delvist sammenfal-dende med sædvanlige ferieuger. For det tredje var den oprindelige implementeringsplan ikke
af-stemt med større politi-involvering andetsteds, f.eks. i forbindelse med FNs Klimakonference i København i december 2009
CSC/ScanJours værktøjer til projektledelse er blevet forbedret i løbet af POLSAG-programmet, hvorfor
der er væsentligt mere transparens fra Fase 4 og fremefter i forhold til Fase 1-3
Gennem hele POLSAG-programmets levetid har der været tilknyttet et dedikeret projektteam in-ternt i
Rigspolitiets afdeling for IT & Tele. Dette projektteam omfatter pt. 43 medarbejdere, men størrelsen på
teamet har varieret over tid.99 Ved den forventede afslutning af POLSAG-programmet i 2011 kan det
samlede ressourcetræk estimeres til ca. 185 årsværk over projektets levetid på 4½ år.100 Af disse ca.
185 årsværk kan ca. 40 årsværk henføres til den samlede forventede forsinkelse på ca. 10 kalendermåneder
Rigspolitiets itchef
hedder ikke længere Lars Guld Fuglsang. Itchefen
er tirsdag morgen blevet fyret, og rigspolitichef Jens Henrik
Højbjerg overtager ansvaret for Rigspolitiets Koncern ITafdeling.
Ifølge Rigspolitiets presseafdeling er fratrædelsen sket 'efter gensidig overenskomst' og med øjeblikkelig virkning.
»Lars Guld Fuglsang fratræder sin stilling som afdelingschef i Koncern IT den 1. maj 2012 efter
gensidig overenskomst. Jeg vil gerne
takke Lars for indsatsen og anerkende de resultater, som han har været med til at opnå i sin tid
som chef på itområdet
i politiet,« udtaler
Krav, estimering,
design
Estimering, leverandør, information, fjl
180
8.1.2.6
181
Tidsplan,
projektledese, forandringsledelse.
182
Projektledelse,
leverandør
183
Projektteam
8.1.2.5
184
Medarbejder, ledelse, ansættelse,
incitament
8.2.2
185
Side 86 af 91
Rigspolitiet fyrer it-chef –
Version2
CSC og politiet i totterne på
hinanden – Computerworld
(Hansen 2013)
Fem ministerier utilfredse
med CSC og ScanJour – Computerworl.dk
Fem ministerier utilfredse
med CSC og ScanJour – Computerworl.dk
rigspolitichef Jens Henrik Højbjerg i en mail til Version2.
Fyringen kommer i kølvandet på en række itskandalesager
i politiet.
Dertil kommer problemer med vagtplanlægningssystemet Polvagt, som blandt andet voldte københavnske betjente store kvaler.
Læs også: Endnu en 'Amanda' i politiet: Københavnske betjente giver vagtsystem ultimatum
(http://www.version2.dk/artikel/endnuenamandaipolitietkoebenhavnskebetjentegivervagtsystemulti
matum43123)
Endelig har Rigspolitiet haft problemer med udbuddet af det forkromede Pas 2.0system,
som efter Version2's dækning af sagen endte
med at blive droppet og erstattet af et mere skrabet udbud.
Men også forholdet mellem kunden (Rigspolitiet) og leverandøren CSC gik hen og blev et større
problem.
Det fremgår af rapporten, at tilliden mellem parterne simpelthen forduftede.
"Udvalget (der i sidste ende anbefalede at lukke projektet ned, red.) vurderede bl.a., at nogle af de
tekniske risici, der i
2011 blev påpeget af konsulenterne, 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," hedder det i rapporten.
Samarbejde ved pilottest
Samtidig rettede forholdet mellem parterne sig ikke op under pilottesten på Bornholm.
"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 pilotdriften på Bornholm, havde skabt mistillid til
leverandørens evne og vilje til at bringe systemet i en brugbar stand," skriver Rigsrevisionen.
Derudover var forholdet mellem hovedog
underleverandør ikke tilfredsstillende.
"Det medførte ifølge udvalget en væsentlig risiko for uforudsete omkostninger, forsinkelser og
mangelfulde
leverancer," fremføres det.
Imidlertid fremgår det også af rapporten, at leverandøren rent faktisk måtte påpege fejl i konsulentrapporter
undervejs.
Frustrerede brugere og ingen effektiviseringer på grund af alvorlige fejl og en funktionalitet, der ikke understøtter en
moderne digital forvaltning.
Sådan lyder kritikken fra fem ministerier af det såkaldte elektroniske sagsog
dokumenthåndteringssystem, Captia, fra
leverandørerne CSC og ScanJour.
De fem ministerier har sendt et brev direkte til administrerende direktør Jesper Kryhlmand CSC
Danmark og
administrerende direktør Bo Schor fra ScanJour.
"Baggrunden for denne henvendelse er dels en stigende utilfredshed med samarbejdet med CSC,
dels oplevelsen af,
at Captia langt fra fungerer optimalt. Systemet er behæftet med mange heriblandt
meget alvorlige fejl,
og
funktionaliteten understøtter ikke moderne digital forvaltning i tilstrækkelig grad" står der i brevet.
"Resultatet er frustration hos brugerne, og at forventede gevinster i form af mere effektiv sagsbehandling ikke kan
realiseres." lyder det.
Brevets afsendere er Socialministeriet, Videnskabsministeriet, Beskæftigelsesministeriet, Trans-
Problemer,
tur
kul-
8.2.2
186
Leverandør,
samarbejde, klima
7.1.4,
8.1.5.2
187
Leverandør,
kunde, CSC, ScanJour,
Brugere,
staten
8.2.3
188
Samarbejde, leverandør, fejl
8.2.3
189
Side 87 af 91
portog
Energiministeriet og Miljøministeriet.
Fem ministerier utilfredse
med CSC og ScanJour – Computerworl.dk
Fem ministerier utilfredse
med CSC og ScanJour – Computerworl.dk
(Hansen 2007)
Bornholmske betjentes reaktion over Polsag-skrotninger:
Jubel og klapsalver – Version2
(Sandal 2012)
Bornholmske
betjente:
Polsag kunne skære en uge
af opklaringstiden – Version2
(Hansen 2012)
Samtidig forklarer ministerierne, at hver enkelt institution ofte skal dokumentere fejl, som allerede
er kendt fra andre
institutioner.
Og leverandørernes ønske om yderligere dokumentation af det samme problem hos andre institutioner fører til
uhensigtsmæssig forlængelse af problemløsningen, mener ministerierne.
"Det er en forudsætning for samarbejdet, at der kommer styr på fejlretningen, så processen bliver
kortere og der
kommer tidsfrister på rettelser af alvorlige fejl. " lyder det fra ministerierne.
FESDen er slut
Det store FESDprojekt,
hvor offentlige myndigheder køber ESDHsystemer
af tre godkendte leverandører, har
massive problemer.
Tidligere har Computerworld.dk beskrevet hvordan leverandøren Software Innovation fik opsagt
kontrakter med
kommuner, fik offentlig kritik fra KL, DR og en række andre aktører over for lang ventetid på support og en udskiftning
af projektledere, der gjorde det vanskeligt at samarbejde.
Når man tæller FESDleverandørparret
CSC og ScanJour med, har to ud af tre godkendte leverandører store
problemer med leverancerne og kritik fra kunderne.
Nu kan betjente på Bornholm glæde sig over, at deres dårlige erfaringer betyder, at Polsagsystemet
bliver droppet.
»Der blev klappet,« fortæller tillidsrepræsentant Henrik Schwartz fra Bornholms Politi til DR P4
Bornholm
(http://www.dr.dk/P4/Bornholm/Nyheder/2012/02/03/105929.htm) .
Han fortæller ifølge DR, at betjentene blandt andet har oplevet, at de har mistet de tekster, de har
skrevet, fordi de ikke er blevet gemt i
systemet. Ud over lange svartider har betjentene haft problemer med integrationen til kontorapplikationer, og det har ikke fungeret, at flere
betjente skulle kunne arbejde på samme sag.
Derfor er betjentene på Bornholm nu tilfredse med, at systemet ikke får lov til at blive rullet ud i
hele landet, men i stedet skrottes.
»Betjentene har ikke vidst, om der ville blive lyttet til os. Derfor er det en fantastisk dag, som vi har
set frem til i et stykke tid,« siger Henrik
Schwartz til DR P4 Bornholm.
»Hvis Polsag havde virket efter hensigten, havde man haft et langt bedre efterforskningsredskab,« siger Henrik Wraae Schwarz fra
Bornholms politi til Version2.
Han har været med til at teste det nu skrottede system Polsag og er ikke i tvivl om, at der er flere
gode elementer i Polsag, som efter hans
overbevisning bør følge med over i et nyt system, der på et tidspunkt skal afløse det nuværende
Polsas.
Især sagsdeling på tværs af politikredse er stærkt tiltrængt. I dag kan det ifølge Henrik Wraae
Schwarz tage op mod en lille uge at sende
sag til en anden politikreds. Sagen skal nemlig først igennem den interne postfordeling for derefter at blive sendt med brevpost til
brevfordeling i en anden politikreds. Med Polsag kunne man videresende elektronisk med få klik.
Dkumentation,
fejl, leverandør,
8.2.3
190
FESD,
ESDH,
Kontrakt, leverandør
8.2.3
191
Brugere, lukning,
fejl
7,
8.1.1,
8.1.2.2,
192
Brugere, pilotdrift, potentiale,
forventninger
8.1.2.2
193
Side 88 af 91
IBM: Politiet er håbløst bagud på itfronten – Version2
(Kildebogaard 2009)
Nyt projektkontor skal redde
politiet fra flere itskandaler –
Version 2
(Kildebogaard 2010)
Nyt projektkontor skal redde
politiet fra flere itskandaler –
Version 2
Nyt projektkontor skal redde
politiet fra flere itskandaler –
Version 2
Ekspert: Politiet skulle ikke
lade CSC styre projektet –
Version2
(Kildebogaard 2010)
»Politiets brug af it er håb-
Da politiet for nogle år siden i en evaluering fik tung kritik af det teknologiske niveau i etaten, satte
regeringen et trecifret millionbeløb af til
at rette op. Den investering betød, at skrivemaskiner blev udskiftet med computere, og en del af
pengene gik også til det nye digitale tetraradiosystem
SINE, som er ved at blive indført over hele landet.
Men det er ikke nok at indføre tekstbehandling der
mangler i høj grad en samlet itstrategi
for politiet, mener Rasmus Hasselager fra
IBM.
I øjeblikket er politiet ved at udskifte et oldgammelt sagsbehandlingssystem, men den nye løsning, Polsag, er blevet forsinket med mindst
to år, samtidigt med at prisen er steget med 68 millioner kroner til 221 millioner kroner.
Det drejer sig blandt andet om mere professionel release management, bedre styring af leverandørerne og at Politiet bliver bedre til at
specificere, hvad et itsystem
skal kunne.
»Det har også været svært for organisationen at få fat i de nødvendige kompetencer men
der er arbejdsmarkedet mere med os nu,«
siger hun.
Den mere positive vinkel er, at der er et kæmpe potentiale og fuld opbakning til at få vendt skuden, fortæller afdelingschefen, der før
jobskiftet til Rigspolitiet i marts har arbejdet som itprojektansvarlig
i finanssektoren i 12 år.
Andre grunde til forsinkelsen er, at kravene til Polsag blev ændret undervejs. Der kom blandt andet ny lovgivning, der betød ændringer.
»Det er ikke som i finanssektoren, hvor alle er vant til at bruge en computer, fordi det er en forudsætning for at udføre finansielt arbejde.
Politiet har ikke samme itmodenhedsniveau,
og derfor har vi også lavet modenhedsanalyser
af alle kredse. Det er vigtigt, at vi sikrer os,
at folk kan følge med,« siger afdelingschefen
»Vi er ved at lave en business case og se, hvad vi skal måle på før og efter, det er kommet i drift.
Men som det oprindeligt blev lagt ud,
skulle det være en moderne infrastruktur, som afløste Polsas én til én,« siger Camilla Borchorst.
Itprojektet
Polsag hos Politiet er blevet voldsomt forsinket og fordyret, blandt andet fordi styringen ikke var
god nok. Det indrømmer
Politiet selv, som 1. januar i år derfor ruskede op i organisationen og oprettede et nyt projektkontor, der fik ansvaret for Polsag.
Men i den oprindelige aftale med leverandøren CSC valgte man, at CSC skulle stå for koordineringen af projektet, mod at firmaet så
garanterede, at tidsplanen holdt. Og det var en mærkværdig disposition, mener Ejvind Jørgensen,
som stod i spidsen for Dansk IT's
arbejdsgruppe om fejlslagne offentlige itprojekter.
»Det undrer mig, at man sætter leverandøren til at tage det fulde ansvar og have den overordnede styring, når man samtidigt har vurderet
teknik og leverandør som højrisikoområder.
I min verden kan man ikke udlicitere den overordnede styring,« siger Ejvind Jørgensen, som
til daglig er underdirektør hos Rambøll Management.
Selvom leverandøren skulle være verdensmester i at styre projekter, er det stadig kunden, som
skal kunne tage lederrollen og have styr
på risikovurderingerne og den bedst mulige løsning i forhold til organisationens krav, lyder det.
Da han får historien om, hvordan tyverianmeldelser, der løber ind via Politiets webside, bliver prin-
Organisation,
modenhed, politiet,
8.1.5.1
194
Leverandør, styring,
ledelse,
kompetence,
medarbejder,
ansvar
8.1.2.5
195
Modenhed, kultur, it kompetencer
196
Business
mål
197
case,
Styring, ledelse,
leverandør
8.1.2.4,
8.1.2.5
198
Kultur, organisa-
8.1.5.1
199
Side 89 af 91
løs men
det er meget normalt« Version 2
(Kildebogaard 2011)
tet ud og tastet ind igen i andre
systemer, er han ikke overrasket.
»Politiet arbejder i et meget politisk miljø. Politikerne ændrer reglerne hele tiden og vil se ændringerne ført ud i livet med det samme. Så
det kan være, man har fået besked på, at man skulle kunne anmelde tyveri via websiden og så
har måttet skynde sig at finde på en
løsning. Tit skyder man krokodillen, der er tættest på kanonen,« forklarer David Carroll.
tion, parathed,
kompetencer,
politik
Anonyme kilder tæt på
Polsag: Derfor gik det helt
galt – Version 2
»Det var almindeligt kendt i itkredse,
at Rigspolitiet dengang havde en fuldstændig dysfunktionel itorganisation.
I den slags projekter er
det vigtigt, at kunden selv forstår kompleksiteten, og det er helt åbenlyst, at politiet havde en helt
utilstrækkelig organisation til det,« lyder
den ubarmhjertige vurdering fra en kilde.
Den garvede itjournalist
Dorte Toft har i et blogindlæg om Polsagfiaskoen
peget på den mangeårige leder af Rigspolitiets itafdeling,
Peter Carpentier, som en hæmsko for udviklingen.
»Carpentier kan meget vel være en inderlig kompetent jurist, men over årene har han gang på
gang afsløret, at hans styrke IKKE ligger
på den itstrategiske
front. Carpentier har desuden udvist en resistens mod itviden,
der ikke passede i hans kram,« skriver hun.
(http://bizzen.blogs.business.dk/2012/02/03/polsagpatientendodeplaceransvaretrigtigtdennegang/)
»Jeg blev kontaktet af et rekrutteringsbureau og mødte op ude hos Rigspolitiet i Hvidovre. Men da
jeg så kommer ind til jobsamtalen med
den tekniske chef for projektet, siger han: ’Det der Captia får vi nok aldrig til at virke’,« fortæller
kilden, der gerne vil være anonym.
Version2 er bekendt med kildens identitet.
Og den overraskende udmelding var kun begyndelsen.
»Han fortæller videre, at han ikke tror på projektet, men at han snart skal på pension. ’Vi får aldrig
Polsag til at virke. Du er ung, og du skal
ikke ødelægge din karriere på det’, får jeg at vide,« siger kilden.
Rigspolitiets gennemgang af itprojekter
fra 2008 og frem med en kontraktsum, der overstiger 1 mio. kr., viser, at CSC har været
leverandør på 5 itudviklingsprojekter,
hvoraf 3 er gennemført og afleveret som planlagt, mens 2 er lukkede. Det ene af de 2 lukkede itprojekter
vedrørte den nationale del af det fælles europæiske itsystem
(SIS II) til udveksling af oplysninger om efterlyste personer og
genstande mellem landene i Schengen samarbejdet. Itprojektet blev lukket på baggrund af efterfølgende ændringskrav fra EU, som
medførte en væsentlig fordyrelse af det oprindelige projekt. Rigspolitiet har iværksat et nyt og væsentlig mindre omkostningskrævende
nationalt SIS II itprojekt
med en anden leverandør end CSC.
*Det andet itprojekt
er POLSAG, som regeringen har besluttet at opgive. På baggrund af den igangværende forhandlingsproces med
CSC, kan de samlede økonomiske konsekvenser ikke opgøres på nuværende tidspunkt. *
Direktoratet for Kriminalforsorgen har oplyst, at CSC sammen med ScanJour
har leveret ESDHsystemet
Captia 4.2 til
organisation
200
Ledelse, kompetencer,
201
Anonyme kilder tæt på
Polsag: Derfor gik det helt
galt – Version 2
(Kildebogaard 2012)
Grotesk jobinterview i 2007:
»Tag ikke jobbet, vi får alligevel aldrig
Polsag til at virke« - Version2
(Kildebogaard 2012)
Her er justitsministeriets
fejlslagne CSCprojekter –
Version2
Her er justitsministeriets
fejlslagne CSCprojekter –
Version2
Rekruttering,
ledelse, kultur,
medarbejder,
ressourcer
8.1.2.3,
8.1.2.5,
8.1.3.3,
8.1.5.2
202
Leverandør, staten, erfaring,
8.1.3.3,
8.1.5.1
203
Leverandør, staten, erfaring, CSC
8.1.5.1
204
Side 90 af 91
(Sandal 2012)
Bøvl lige fra starten: Politiet
raser over CSC - Computerworld
(Hansen 2010)
Bøvl lige fra starten: Politiet
raser over CSC - Computerworld
Justitsministeriets itfællesskab. Captia 4.2 anvendes i Justitsministeriets departement, Kriminalforsorgen, Civilstyrelsen, Familiestyrelsen
og Pressenævnet. Der har været væsentlige forsinkelser på op til 15 måneder i leverancerne til
enkelte af myndighederne under
Justitsministeriets itfællesskab.
Den endelige betaling blev 360.000 kr. mindre i forhold til angivet i kontrakten for levering af
standardsystemet.
Domstolsstyrelsen har oplyst, at CSC har været hovedleverandør på domstolenes digitale tinglysningssystem, som omhandler
digitalisering af Tingbogen, Bilbogen, Personbogen og Andelsboligbogen. CSC har desuden været leverandør på det gamle elektroniske
tinglysningsprojekt, som blev afsluttet i 2000. Den del af spørgsmålet, der vedrører forsinkelse af
projekter med CSC som leverandør,
besvares i det følgende med udgangspunkt i det digitale tinglysningssystem.
Fire måneders samarbejde.
Så længe skulle der gå, før Rigspolitiet udarbejdede et notat, der
kritiserer leverandøren CSC omkring det skandaleramte Polsagprojekt.
Notatet, der er sendt til styregruppen af projektet, er dateret til den 5.
september 2007 og har overskriften "Manglende rettidig omhu i forhold
til Polsagleverancen".
"Rigspolitiet ønsker med nærværende notat at fremdrage en række
forhold omkring CSC's håndtering af leveranceansvaret for det samlede
Polsagprogram.
De anførte forhold er observeret under de godt fire måneder, Polsag
programmet har kørt og fordeler sig på følgende:
CSC
leverer ikke tilstrækkelig proaktiv koordinering og synkronisering
af aktiviteterne planlagt under T14 (tillægsaftale til applikationskontrakt
indgået i maj 2007, red.).
Der
er utilstrækkelig fremdrift og kvalitet i udarbejdelsen af SDD1 (et
spor i projektet, red).
Ændringsstyring
er endnu ikke etableret."
"Rigspolitiet har endnu ikke modtaget en sammenhængende
masterplan for Polsagprogrammet,
hvilket CSC jf. ovenstående er forpligtet til at levere".
Opsummeringen på de otte siders kritik af CSC lyder:
"Som anskueliggjort ved ovenstående redegørelse så føler Rigspolitiet ikke, at CSC lever op til sit
leveranceansvar for
det samlede Polsagprogram."
"Det er Rigspolitiets vurdering, at dette har haft negative konsekvenser for
kvaliteten af gennemførte leverancer, for
sammenhængen i udarbejdede planer, for
rettidig etablering af de nødvendige styringsprocesser, for
opfølgningen
på fremsendte ændringsanmodninger samt for tilstrækkelig ressourceallokering og aktivitetsstyring."
"Alle forhold, der er yderst kritiske for Polsagprogrammets
succes, og som har medført ekstra omkostninger for
Rigspolitiet i forhold til gennemførelsen af de indtil nu planlagte aktiviteter," hedder det i notatet
Samarbejde, leverandør,
styring, leverance
7.1.4
205
Leverandør, levernace, styring,
masterplan,
planlægning
7.1.4
206
Side 91 af 91