Svensk politis Oracle-skandale: Nu tager det flere timer at skrive en rapport

Der er store problemer med et kommende it-system til svensk politi. Det tager flere timer at klare en opgave, som tidligere tog højst 20 minutter.

Det er ikke kun i Danmark, at politistyrken ud over forbrydere også skal slås med skandaløse it-systemer.

Ligesom det danske sagsbehandlingssystem Polsag kørte af sporet med en regning på 567 millioner kroner, har svensk politi heller ikke nogen større succes med Pust, der skal være det centrale it-system for de svenske betjente i fremtiden.

I februar kom systemet i drift i 7 ud af 21 politikredse, hvor det foreløbigt bruges til rapporter om mindre alvorlig kriminalitet, og siden har kritikken været hård fra betjentene. Hvor det før tog mellem 10 og 20 minutter at skrive en rapport, er der så store problemer med Pust-systemet, at det nu tager flere timer. Det skriver Computersweden.

Pust, der er baseret på Oracles ERP-system Siebel, har foreløbigt kostet knap 110 millioner danske kroner, og der kommer 43 millioner kroner oven i regningen, før systemet er helt indført, lyder meldingen fra svensk politi.

Men det tal kan også stige, for politiet har nu besluttet at udskyde fuld drift med ni måneder, da den oprindelige deadline ved udgangen af 2014 virker urealistisk. Dermed skal de svenske betjente køre både det nye Pust og det gamle it-system parallelt i mindst to år.

Et af de store kritikpunkter fra betjentene er en uoverskuelig brugergrænseflade, og derfor vil Oracle og Rigspolitiet i Sverige nu udvikle en ny brugergrænseflade. I stedet for at lade alle muligheder være tilgængelige hele tiden, skal der være mulighed for at gennemføre de mest almindelige rutineopgaver uden for mange forstyrrelser.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars K. Hansen

Hvad hulen skal de systemer dog kunne siden de bliver så tunge? For mig lyder det helt vildt at det ene system efter det andet kan køre så meget af sporet.

En politi rapport kan da for hulen ikke være så vanskelig? Det er jo trods alt ikke en rumraket de skal udvikle/styre?

Mikkel Lauritsen

Hvad hulen skal de systemer dog kunne siden de bliver så tunge?

Uden at jeg har nogen form for indblik i det svenske system eller tilsvarende danske problembørn, så er det mit umiddelbare bud, at de ikke skal kunne noget specielt komplekst.

Problemerne skyldes nok snarere, at systemerne er lavet af folk, som mangler dyb forståelse for både domænet og de komponenter, som koden stykkes sammen af. Resultatet af det er kode, som måske nok formår at lave skærmbilleder, som ser korrekte ud, men som under motorhjelmen er den vildeste Storm P.-maskine.

Det betyder elendig performance og ingen mulighed for at vedligeholde og videreudvikle, og hvis den lille hund en dag ikke har lyst til pølse bryder alt sammen.

Finn Christensen

Hvad hulen skal de systemer dog kunne siden de bliver så tunge? For mig lyder det helt vildt at det ene system efter det andet kan køre så meget af sporet.

Glem 'specs' Lars, da krig, kærlighed og politik har andet at byde på.

Organisationer, der driver under politisk ansvar gennem århundrede, vil jo som tiden går nærme sig en gennemgribende omdefinering.

Embedsfolket har ikke den fjerneste interesse i omdefinering, da det truer deres velerhvervede grænser, så de bekæmper alt af den type, og politikerne har i vores tid mest travlt med 'at være på' og planlægge polering af egen navle...

Politi og retsvæsen er meget meget gamle væsner med flere århundrede på bagen, og som enhver stolt flåde fra den tid er de prima mad for pæleorm.

DSB og den gamle Told & Skat (nu Skat) var tilsvarende alle tre oprindeligt gamle og engang solide troværdige etater, som her de seneste år jævnligt må trækkes i tørdok, hvor vi alle via medierne kan se omfattende angreb af pæleorm.

Det nævnte kan jo dårligt kaldes 'enestående tilfælde'.

Kenneth Lylloff

Tjah - sådan er vi jo så forskellige.

Jeg vil vove den påstand, at det stort set aldrig kan betale sig at bygge noget system fra bunden. Og med system mener jeg ikke en tilfældigt program til at løse en lille specifik opgave.
Jeg synes at fornemme at en af de problemer der stort set altid er i store (offentlige) systemer er skalérbarhed. Behold performance men skalér fra 100 - 100.000 brugere. Fra 100 - 100.000.000 dokumenter og så fremdeles. Hvor mange 'engines' af den type er bygget fra bunden succesfuldt?
Byg på en god solid skalérbar motor, lad leverandøren stå for videreudvikling af det centrale. Og byg så kun de regler, processer, interfaces mv. der ikke findes i standardproduktet. Det vil alt andet lige give et betydelig mindre vedligeholdelses arbejde.

Men igen - jeg er måske farvet af mit levebrød.

Henrik Mikael Kristensen

Jeg vil vove den påstand, at det stort set aldrig kan betale sig at bygge noget system fra bunden. Og med system mener jeg ikke en tilfældigt program til at løse en lille specifik opgave.

Man bør ihvertfald ikke bygge store, glorificerede systemer fra bunden med tusinder af siders kravspecifikation, millioner af kroner på bordet, 5-10 års udviklingstid og røde snore der klippes over, hvor man så først herefter finder ud af, det var slet ikke det de ville have.

Der er idag utallige værktøjer til at bygge simple prototyper med, især indenfor brugerfladeudvikling, så man kan få de folk der skal bruge systemet, til at komme med på et par timers møde et par gange om ugen. Det koster måske 2-3 måneders arbejde med et par dygtige kodere, der kunne rejse rundt og snakke med brugere, bygger prototyper, henter feedback, reviderer prototyperne, osv. uden det behøver at koste mere end nogle månedslønninger.

Og lad være med at hyre et konsulentfirma til at matche farverne på knapperne i brugerfladen til linoleumsgulvet i kantinen, fordi det er korrekt "corporate image" og den slags fis.

Mikkel Lauritsen

Jeg vil vove den påstand, at det stort set aldrig kan betale sig at bygge noget system fra bunden. Og med system mener jeg ikke en tilfældigt program til at løse en lille specifik opgave.

Den triste virkelighed er nok, at der ikke findes en klar regel, som siger, at det altid/aldrig kan betale sig at basere sig på en eller anden form for standardsystem.

Det er igen den der med, at man i detaljer skal forstå, hvad ens applikation skal kunne og hvilken funktionalitet, som standardsystemet tilbyder - og så kan man tage stilling til, hvad der giver den billigste løsning.

Man kan have nok så skalerbar kernefunktionalitet, men hvis dens API'er er designet sådan, at den eneste måde at understøtte de ønskede workflows er at lave 100.000 kald i sekundet, så hjælper det ikke det store. Og den anden vej rundt, så kan man selvfølgelig i teorien altid lave den optimale løsning ved at starte fra et blankt stykke papir, men det er ikke nødvendigvis det mindst arbejdskrævende...

Pelle Söderling

Kenneth: Mit indtryk er det stik modsatte, hvis først beløbet begynder at nå ret meget over 20 millioner kr for et system så vil jeg vove at påstå at kravene oftest er specielle nok til at det ALTID kan betale sig at bygge systemet fra bunden tilpasset kunden.

Sandheden er jo at selv de her standardløsninger er sjældent bygget til at skalere til større organisationer og virksomheder og kunden kan nemt have specielle krav som produktet knækker nakken på - og knækker det på skaleringssiden så står man først med store problemer fordi man nu skal til at tilpasse en standardløsning der er bygget til andre formål til at håndtere de her special-scenarier, det kan meget hurtigt blive en ordentlig omgang rod og man mister meget hurtigt gevinsterne ved at have baseret sig på et standardsystem.

Det er langt nemmere at tilpasse et specialdesignet system man selv har skrevet og designet til de skiftende krav man kommer ud for i løbet af projektets varighed.

Det er muligvis business systemer i enterprise enden af skalaen, men det er altså et af de områder der findes flest udviklere der beskæftiger sig med, så det burde ikke være specielt svært at stykke et team sammen til at løfte sådan en opgave - det er på ingen måde rocket science vi taler om.

Niels Danielsen

Disclamer, jeg er ikke udvikler af administrative systemer og PC software. Og jeg har ikke nogen speciel kendskab til politiets arbejde, fra hverken den ene eller den anden side.

Uden at jeg har nogen form for indblik i det svenske system eller tilsvarende danske problembørn, så er det mit umiddelbare bud, at de ikke skal kunne noget specielt komplekst.

En politi rapport kan da for hulen ikke være så vanskelig? Det er jo trods alt ikke en rumraket de skal udvikle/styre?

Det er jeg ikke så sikker på, jeg vil mene at software til en en raket er noget mere simpelt en et ERP system.

Jeg vil tro at sådanne systemer skal gennem en hulens masse metadata på personer, afhøringer, og anmeldelser.
Disse metadata skal bruges til at skaffe overblik over hvem der er potentiel kandidat til en forbrydelse, hvem laver kriminalitet med hvem, hvordan osv.
Der er garanteret også noget work-flow logik der siger noget om hvem der kan lukke en sag, og åbne den igen, kontering af timer etc.

Ud fra den smule der er kommet frem omkring POLSAG, så virker det som om at der er lavet en database på toppen af en anden database.

Sådan et anti-patteren kan fremkomme hvis der anvendes et standard system, hvor der kan gemmes metadata på hver sag som key-value par i det native database system.

Det betyder at man skal igennem milliard vis. Af key-value par. indtil flere gange for at få svar på hvem der bor på fyn, har en voldelig fortid, og køre i en rød bil.

Lars Lundin

Mit indtryk er det stik modsatte, hvis først beløbet begynder at nå ret meget over 20 millioner kr for et system så vil jeg vove at påstå at kravene oftest er specielle nok til at det ALTID kan betale sig at bygge systemet fra bunden tilpasset kunden

Nu er det muligvis et definitionsspørgsmål hvad der menes med "at bygge systemet fra bunden".

Men i open-source verdenen, hvor jeg arbejder, er der rigeligt med standardkomponenter til understøttelse af alle mulige standarder.

Og jo mindre kode man selv skal vedligeholde desto bedre, så det betaler sig at have folk, der ved hvilke af disse standardkomponenter, der er egnede.

Når det ikke er tilfældet og en gruppe af udviklere istedet vælger selv at implementere fra bunden den brøkdel af en given funktionalitet de mener at skulle bruge, så ender deres implementering oftest med et kludetæppe af tilføjelser, som så senere skal omskrives til at bruge den standardkomponent, som hele tiden var til rådighed, men som indledningsvis blev vurderet som overkill.

Men programmering er jo mange ting og det er muligvis helt anderledes med ERP systemer, som jeg dårligt nok kan finde ud at bruge til de simpleste ting.

Kristian Sørensen

De offentlige IT skandaler jeg har været medvirkende til - og det er ikke så få - har alle haft som skjult dagsorden at lave en palads revolution under dække af indførelsen af et større it system.

Man har fra topledelsens side haft et håb om at kunne gennemtvinge en organisationsændring ved at opbygge og indføre et stort og gennemgribende it system.

Ideen er at it systemet opbygges til at facilitere den process og den ansvarsfordeling man ønsker for den nye organisation, og når så systemet er indført må organisationen nødvendigvis tilpasses så den modsvarer den måde it systemet er lavet på.

Topledelsen kan så vaske sine hænder, påstå at organisations ændringerne sker som følge af it systemets opbygning, og dermed fralægge sig ansvaret og undgå magtkampen ved at indføre den ønskede organisations ændring. Det er i hvertfald det fromme håb.

Nuvel, det mønster har mange erfarne folk set før, så det der ofte sker er at mange i organisationen indser at dette er ved at ske og giver sig til at udøve diskrete benspænd. Ofte i form af ønsker til kravspecifikationen for it systemet.

Da kravspecifikationen udarbejdes i tiden før it systemet er indført, og dermed under den gamle organisation med de gamle magtstrukturer, kan fiffige og erfarne folk udnytte denne magt, til at få sæde i de udvalg og komiteer der laver kravspecifikationen. Her får de så indføjet små fiffige krav der sikrer at netop deres job/afdeling/chef/whatever består i det nye it system.

Pelle Söderling

Lars: Nu ved jeg ikke helt hvad du mener med "standardkomponenter" i denne sammenhæng, men det er selvfølgelig ikke sådan at man skriver alt fra bunden - selvfølgelig bruger man frameworks og 3. parts komponenter hvor det giver mening.

Det jeg mener er at man starter med et blankt database-design og implementerer forretningslogikken så den er tilpasset kravene og organisationen.

Hvis du mener at de fleste udviklere ikke er istand til det, så har vores branche dælme et større problem.

Markus Hornum-Stenz

Helt fundamentalt tror jeg at problemet ofte er især 2 ting:

  • det svære ved at få høj sikkerhed og god performance samlet i en pakke, og her er politisystemer nok ikke de mindst problematiske. Følsomme oplysninger og alle må kun kunne se det de er berettiget til.

  • de færreste politisk styrede organisationer lever kun i kraft af deres evne til at levere ensartet sagbehandling, men i lige så høj grad i kraft af deres evne til at levere fleksibel sagsbehandling. 80/20-regelen lever og har det godt, men er ikke nem at håndtere IT-teknisk, fordi de sidste 20% af sagsforløbene er heterogene. DET er den sikre vej til kravspec-helvede....

Log ind eller Opret konto for at kommentere