Rigsrevisionen uddeler øretæve til Politiet efter Polsag-skandale
Det gik galt hos Rigspolitiet både da it-systemet Polsag skulle planlægges, under udviklingen og faktisk helt frem til den pilottest af systemet på Bornholm, hvor det for første gang stod helt klart, at Polsag-projektet havde alvorlige problemer.
Sådan konkluderer Rigsrevisionen i en ny beretning, der kulegraver en af de største offentlige it-skandaler i Danmark det seneste årti. Rapporten er ikke offentliggjort endnu, men Computerworld.dk har fået indblik i den og kan referere konklusionen.
Rigsrevisionen skal holde de offentlige kontorer i ørene, og derfor er der udelukkende fokus på håndteringen af Polsag i Rigspolitiet og Justitsministeriet. Leverandøren CSC går altså ram forbi i kritikken.
Men der er tilsyneladende også nok at komme efter på bare den ene side af bordet. Grundlæggende melder Rigsrevisionen om et massivt ledelsessvigt hos politiets it-ansvarlige.
Allerede da Polsag blev undfanget, blev opgaven grebet helt forkert an. I stedet for at modernisere arbejdsprocesserne og tage med i overvejelserne, hvad det valgte ESDH-system Captia kunne i forvejen, bestilte politiet en løsning, der skulle kopiere de eksisterende, oldgamle systemer.
Derfor endte store dele af Polsag som specialudviklet kode, så der til sidst ikke var meget tilbage af Captia, og det gjorde udviklingen langt mere kompleks.
Da systemudviklingen går i gang, er der alt for lidt styring fra Rigspolitiets side, konkluderer Rigsrevisionen.
»Det er Rigsrevisionens vurdering, at Rigspolitiet ikke forberedte og styrede Polsag -projektet tilfredsstillende og på en række punkter ikke fulgte god praksis for at styre statslige it-projekter. (…) 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,« lyder et af kritikpunkterne.
Frem til 2010 var det vicerigspolitichef Peter Carpentier, som havde ansvaret for Polsag, men han blev - tilsyneladende på grund af de voksende Polsag-problemer - flyttet ud til en post som chef for SINE-sekretariatet i stedet.
I december 2010 fik Rigspolitiet sat Polsag i pilotdrift hos de 80 betjente på Bornholm. Men det var ingen succes. Systemet viste sig ikke at være klar til brug - blandt andet var svartiderne alt for lange - og betjentene blev med tiden højlydt utilfredse.
Det får Rigspolitiet også kritik for af Rigsrevisionen, og der manglede generelt støtte til de bornholmske betjente, som altså endte som ’forsøgskaniner’.
Udover al balladen med selve it-udviklingen, var der også store problemer med økonomien, konkluderer Rigsrevisionen. Blandt andet havde Justitsministeriet først oplyst Folketingets Finansudvalg om en markant udvidelse af projektet 9 måneder efter, den var aftalt med leverandøren. Dermed fik Rigspolitiet betalt 12 millioner kroner til CSC for opgaver, som der slet ikke var bevilget penge til. Det finder Rigsrevisionen ’ikke tilfredsstillende’.
»Rigsrevisionen vurderer, at Justitsministeriet ikke styrede bevillingerne til Polsag tilfredsstillende,« lyder det overordnet i Rigsrevisionens konklusion.
Polsag blev lukket ned i februar 2012, efter mere end et års fejlslagen pilotdrift på Bornholm. Den samlede regning for det fejlslagne projekt endte på omkring 567 millioner kroner, skriver Rigsrevisionen.
Kommentarer (6)
Jo jo, den blev skrottet, men gæt hvem som skal stå for det nye system....................RIGTIGT! Du har vundet en pose muldjord...CSC!!!
-
0 -
4
....bestilte politiet en løsning, der skulle kopiere de eksisterende, oldgamle systemer..... .....Derfor endte store dele af Polsag som specialudviklet kode....
Der er intet nyt under solen her, faktisk almindelig praksis de seneste 30-40 år for utallige systemer, og der er faktisk i nogle tilfælde rimelig kontante årsager til, at den 'kopiering' sker, samt at det fortsat vil ske. At kunden så her hverken magtede opgaven eller havde styr på processen fuldender blot sagen.
Et andet tilsvarende eksempel var den digitale tinglysning. Man kunne heller ikke her lave verden om, men havde fortiden med sig, og ledelsen undervurderede projektets belastning. Ikke et kønt syn da det gik i drift, men de fik det da til at trille efter nogen tid.
Utallige offentlige opgaver er kun administrative hjemmeavlede processer, der gennem utallige år er opbygger over lovene, cirkulærer, bestemmelser og andet fra folketinget og ministerier - altså:
- dem der skal ha' et system er administrativ personale, har eget fag og interesser, men er ikke systemfolk/udvikler
- system skal magte allerede eksisterende processer og regler - der er en hjemmel.
- systemet må ikke magte 'noget', som der ikke er hjemmel for
- det koster en formue i uddannelse (og er reelt umuligt) at omskole alle til et komplet ændret system
Men dertil kan vel kun tilføjes, at når man vælger et standardsystem, der ikke du'r til det formål man tænker på, og så specialudvikler sig ud af situationen... det kaldes i ordbogen manglende evner.
-
2
-
0
Er der ikke en der til dagligt arbejder med store IT projekter, der kan forklare følgende:
Hvordan kan prisen enden på næsten 600 mio. kr.?
Selvfølgeligt skal der bruges IT-Udstyr og licenser til udviklerne, men derudover er der vel næppe de store "materialeudgifter".
Hvis vi antager en udvikler tjener 50.000 om måneden i gennemsnit, så er 567 mio. kr. omkring 1.000 "mande-år". Projekter løb i 3? år, det giver over 300 fuldtidsansatte i hele perioden.
Så mange kan der da vel ikke være om at lave et enkelt system, især et der er så ringe?
-
1
-
0
over 300 fuldtidsansatte i hele perioden. Så mange kan der da vel ikke være om at lave et enkelt system, især et der er så ringe?
Man kunne vel argumentere for, at det netop er en forudsætning for at lave et så ringe system. Jf fx Brooks lov. Jeg vil vædde på, at leverandøren har forsøgt at løse problemer ved at smide flere ressourcer efter dem.
-
1
-
0
Selvfølgeligt skal der bruges IT-Udstyr og licenser til udviklerne, men derudover er der vel næppe de store "materialeudgifter".
Jeg tror højst at du skal regne med at halvdelen af prisen for en udvikler går til udvikleren løn.
Husleje, rengøring, arbejdsskadeforsikring, økonomistyring (løn og skat), kantinetilskud, efteruddannelse, rekrutering af erstatning for medarbejdere der forsvinder i perioden, kaffe og mange andre små bække.
Desuden skal der også dækkes udgifter til selve forarbejdet før kontrakten er indgået og for forarbejdet til de udbud som virksomheden ikke vandt. Alt efter hvordan kontrakten er udforment påtager virksomheden sig nogle risici den også skal forsikre sig imod.
Og endelig skal der også lige være plads til et par procent til overskud.
Jeg plejede at regne med at en udvikler koster 1 million om året at have gående. Men de sidste par gange jeg har nævnt den tommelfingerregl i debatten her på version2 har jeg fået at vide at det var alt for lavt. (Men den stammer nu også tilbage fra min tidligere arbejdsplads og det er efterhånden 7 år siden).
-
1
-
0
..det giver over 300 fuldtidsansatte i hele perioden....
Ja og der har ikke været 100 mænd på - fuldtids, antageligt mindre. Men der aflønnes utallige andre udover kode-/udviklerholdet.
I store projekter indgår også hyppigt - især ifm. CSC og KMD - en efterfølgende drift i et antal år. Driften er også en del af kontrakten, som sælger regner på. Dvs. store projekter er hyppigt i en situation, der kan beregnes efter en gang gyngerne og karrusellen.
Er man god til salg og meget heldig, så er der overskud på begge forlystelser :)
I det her tilfælde, så har man på den korte bane nok ikke tabt meget andet en 'æren' på selve projektet, men på langt sigt.... umuligt at bedømme endnu.
Husk lige, at man har haft opgaver og indtægter til en del personer i kriseperioden 2008-2011 - ikke ringe.
-
0
-
0
Tilføj kommentar
