Dansk Folkeparti: Brug hyldevare-software i stedet for Polsag

Hvorfor skal de store offentlige it-projekter altid genopfindes på ny, når det så tit går galt, spørger Dansk Folkepartis it-ordfører. Han efterlyser hyldevarer fra andre lande som erstatning for det kuldsejlede Polsag-system.

Politiets kommende it-system Polsag er nu blevet lagt dødt, og op imod en halv milliard skattekroner er spildt. Dermed er den store opgradering af et helt centralt it-system nu midlertidigt aflyst, indtil der er fundet på en ny løsning, som altså først skal defineres, udvikles og udrulles.

Men hvorfor ikke prøve at bruge et system, som faktisk fungerer og allerede har vist sit værd, spørger Dennis Flydtkjær, der er it-ordfører for Dansk Folkeparti og uddannet datamatiker.

»Hvorfor skal man opfinde den dybe tallerken hver gang og lave pionerarbejde? Det går jo alligevel galt hver gang. Kunne man ikke prøve at se på hyldevarer, når der nu skal findes en afløser for Polsag?« siger han til Version2.

Et sagsbehandlingssystem til politiet er selvfølgeligt ikke noget, der kan sammenlignes med et helt almindeligt ESDH-system, men derfor må det stadig være muligt ikke at skulle starten fra bunden, mener it-ordføreren.

»Der må være politikorps ude i verden, der har et system, som fungerer, og som vi kan rette til efter danske forhold. I Finland har de et, som fungerer rigtig godt, og så vidt jeg ved, overvejer svenskerne at bruge det også,« siger Dennis Flydtkjær.

Om det var en rigtig beslutning at lukke Polsag helt ned, efter at have brugt op mod en halv milliard på systemet, er svært at vurdere lige nu for politikeren. Den eksterne undersøgelse af Polsag bliver nemlig holdt hemmelig, også for Folketinget, hvor det kun er medlemmer af retsudvalget, som har fået fortrolig adgang til rapporten.

Dennis Flydtkjær har i efteråret 2011 forsøgt at få hul igennem til processen, med spørgsmål til retsudvalget, men uden meget held. Da han ikke havde fået svar på sine spørgsmål om Polsag inden for svarfristen på fire uger, rykkede han og fik derefter et temmelig intetsigende svar, der ikke gav svar på noget.

Læs også: Mørklægning af Polsag-skandale fører til klagesag i Folketinget

Forløbet fik ham til at klage til Folketingets Præsidium, og Justitsministeriet måtte derefter beklage, hvordan spørgsmålene var blevet håndteret.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Simon Lyngshede

Jeg tror ikke politikerne er specielt interesseret i hyldevare til noget som helst. Det vil jo typisk indebære at politikerne ikke frit kan lovgive om bestemte områder fordi systemerne nogle gange ikke vil kunne konfigureres til at passe politkernes ideer om samfundet.

Troels Arvin

Begreber som standardsystem og hyldevare er næsten lige så elastiske som "best practice". Som Nikolaj skrev, var der netop taget udgangspunkt i et såkaldt standardsystem, og som Claus P så rammende beskriver, har man så "tilpasset" "standardsystemet" i pervers grad.

Jeg synes at se et lignende mønster i visse andre skandalesystemer: Med DeMars indgår en "hyldevare" som SAP. Prøv på http://www.ams.dk/Publikationer/2004/pub230.aspx at se, hvordan systemet hyldes for at bruge hyldevarer såsom Notes og SAS. Og eksempelvis har jeg ofte måttet høre på frustrerede beretninger fra udmærkede udviklere, som med stor beklagelse måtte finde sig i bizarre løsninger, fordi noget simpel web-udvikling absolut skulle passes ind i SiteCore.

Og man skal ikke bevæge sig meget omkring for at opleve, hvordan folk bruger SharePoint som trylleord for at legitimere dette og hint, på trods af, at middleware har en notorisk kort levetid inden noget nyt og mere moderne bliver comme il faut.

Én af de vigtigste lærepenge fra denne historie er måske præcis, at man skal gå meget langt uden om såkaldte standardsystemer, hvis der er mistanke om, at "standardsystemet" skal vrides eller videreudvikles.

Kristian Sørensen

Hvor er det dejligt at se en politiker så tydeligt demonstrere en af årsagerne til at store offentlige IT projekter kører i hegnet.

Politikeren stiller sig op og siger at fremtidige projekter skal bygges på standard systemer for ikke at ende som Polsag.

Kort efter får man så at vide at Polsag netop er bygget på et standard system

;-) ;-) ;-)

Problemet er netop at statslige IT systemer styres af folk der mangler viden og erfaring om IT, som ikke gør sig den ulejlighed at sætte sig ind i tingene, men som alligevel fører sig frem med meninger, forsøger at indføre politiker og procedurer, regler og forordninger baseret på det rene ingenting.

Tak for den nydelige demonstration hr. politiker;-)

Jan Heisterberg

Hyldevarer forudsætter at kunden, her Politiet, accepterer ændringer i procedurer og arbejdsprocesser - og det er der ofte indædt modstand mod (eller bare mangel for forståelse for).

Endvidere har, forståeligt nok, enhver organisation sit eget begrebsapparat. For eksempel anvender nogle organisationer begrebet "kunde", andre "klient", og andre "samarbejdspartner".
Forståeligt nok, så skal terminologi tilrettes - men så begynder Pandora's æske at blive åbnet.

Så hyldevarer med tilrette terminologi er et godt mål - men det forudsætter altså vilje og evne til at ændre processerne.

Iøvrigt: selv ens organisationer, med samme begrebsapparat - f.eks. kommuner - kan have vidt forskellig måde at håndtere fuldstændig ens sagsbehandling på. Så det er ikke let.

bent madsen

Det er utroligt nemt at sige at man skal bruge hyldevarer.

I det tilfælde at en organisation har processer som direkte understøttes af det som "hyldevaren tilbyder" så er det da lige til, og så synes jeg da man skal anvende "hyldevarer".

Hyldevarer kan ofte på tilstrækkelig abstrakt niveau løse opgaven, men når det bliver krævet at det skal løse en konkret process, så er der altid noget som skal ændres.
Jeg har set et kompliantmap på et stort SAP-system som gik fra at være
helt grønt på alle processerne til at blive gult i en periode, for til slut at være rødt med krav om udvikling i stor grad. Og det var jo så
her man skulle have stoppet op, smidt leverandøren på porten. Men nix
man betalte sig fra det, og den klods om firmaets IT ben forbliver der
indtil man endnu engang laver et nyt forsøg (3. gang er jo lykkens gang)

Et godt eksempel er SAP som var lavet til at løse forsikringsopgaver, men da det skulle anvendes til en ordning hvor gravide skulle kunne melde deres graviditet, blev det registeret som en skade. Og i den efterfølgende process skulle skaden vurderes af en sagsbehandler, nogen frivillige? :-)

Udbudsprocess som køres inden kontrakten skrives under, skal være MEGET specifik på hvad de processer "Hyldevaren" skal kunne løse.
Så det bliver ikke en opgave en konsulentvirksomhed med "Senior" Management konsulenter med max. 5-8 års erfaring kan klare i et tilfælde som Politiets. Det er jo ofte udbudsproceseren køres igennem af et konsulent bureau med minimal indsigt i organisationen og dets arbejdsopgaver. Og det ender ofte i skoven når det skal ud i virkligheden hos kunderne.

Der må kræves at organisationen kan stille erfarnefolk med viden til de konkrete behov som skal løses, tilrådighed i HELE udbudsprocessen (ofte mindst 100% af deres tid). Og at disse folk bliver allokeret til opgaven, og direkte får ansvaret for at det produkt de er med til at få produceret er som det var tiltænkt.

Den Agile tilgang til opgaven kan anbefales, men igen kræver det MEGET øvede personer.
Alt for mange junior udviklere der har lavet Mickey Mouse systemer til få mio. kr. (og som er lykkedes med det) der vil hævde at de kan lave store systemer på tilsvarende måde. En selvtillid de ofte mister når der har prøvet nogle gange. Så når vi er oppe i to/tre cifret mio. beløb så skal der erfarne folk på.
Alternativ kan man jo bede en stor legetøjsfabrikant om en forklaring på hvordan deres Agile udvikling af et internet spil til trecifferet mio. kr. nu blev lukket ned. For med Agile metoder sker det jo ikke at kundens og brugernes behov bliver overset iflg. div. Agile guruer!!!

Og tro nu ikke at progamledelsen bliver mindre kompliceret af man køre tingene Agilt. Det er tvært imod en meget krævende opgave at lede sådanne programmer. Kun få i landet har virkelig prøvet at køre store programmer Agilt, altså indenfor det oprindelige budget. Hvilket jeg forudsætter er den afgørende succesparametrene for et stort program.

Så lad nu nogle erfarne (dem som har lavet store systemer, som virker) komme til hos politiet denne gang. Og det er ikke kun hos CSC der skal være gode folk, men også hos Politiet. Og så skal de sammen kunne stilles til regnskab for det endelige produkt, det kan vel nok få samarbejdet til at blomstre :-)

Og husk på at spidskompetance er dyrt, men ikke noget at regne imod inkompetance :-)

Peter Stricker
Jesper Lund Stocholm Blogger

Alt for mange junior udviklere der har lavet Mickey Mouse systemer til få mio. kr. (og som er lykkedes med det) der vil hævde at de kan lave store systemer på tilsvarende måde. En selvtillid de ofte mister når der har prøvet nogle gange. Så når vi er oppe i to/tre cifret mio. beløb så skal der erfarne folk på.


:o)

Anekdote:
Jeg deltog for nogle år siden på et projekt i København, der nok er den - mediemæssigt - største IT-skandale i København i nyere tid. På min kones daværende arbejde var en IT-gut (datamatiker), der en dag til frokost, hvor snakken kom på projektet, udtalte "jeg er sikker på, at hvis jeg og 4-5 af mine venner fik chancen, så kunne vi lave det der lort på 3 mdr".

Da jeg hørte dette blev jeg pisse-fornærmet - i 2-3 sekunder. Derefter bedret sig et overbærende smil over mine læber imens jeg tænkte: "Det er lidt synd for ham, at han var så løsrevet fra virkeligheden".

Det er klart, at Polsag er en skandale - men hvis diskussionen om hvad vi kan lære af det starter med udsagn som "det kun jeg og mine venner have lavet for 10mil" eller "hvorfor pokker har de ikke anvendt en agil proces?", så står jeg personligt af.

At lave software er i sig selv svært - og at lave og implementere software i så store organisationer som Politiet er altså meget svært.

:o)

Christian Nobel

Alt for mange junior udviklere der har lavet Mickey Mouse systemer til få mio. kr. (og som er lykkedes med det) der vil hævde at de kan lave store systemer på tilsvarende måde. En selvtillid de ofte mister når der har prøvet nogle gange.

Ja for satan, du skal i hvert fald ikke tro du er noget.

Så når vi er oppe i to/tre cifret mio. beløb så skal der erfarne folk på.

Vor herre bevares, hvad fatter gør er altid rigtigt.

Det er jo lige præcis den der hovski-snovski holdning til big-is-beautifull, bigger-is-even-more-beautifull som gør det hele kører af sporet.

Du kan godt droppe det der nedladende "Mickey Mouse" udsagn, for det er udelukkende et udtryk for at jordforbindelsen er helt forsvundet oppe i Babelstårnet.

Og sjovt nok så er Microsoft, Google, Apple, Facebook, Oracle og mange andre lige præcis startet med "Mickey Mouse", og jeg er 100% sikre på at de firmaer aldrig var blevet store hvis de havde startet med storhedsvanvid, et budget på en milliard og en kravspec på 5000 sider.

Herudover bliver jeg faktisk ret pikeret over dit nedladende "Mickey Mouse", al den stund små opgaver, dels kan være lige så seriøse som store, dels løse den opgave de skal løse, og de kan være skalerbare.
Men så snart de pludselig skal være store og åh-så-fine, så, for at forfølge din terminologi, går der Anders And i det (been there, done that, got the t-shirt!).

Christian Nobel

Det er klart, at Polsag er en skandale - men hvis diskussionen om hvad vi kan lære af det starter med udsagn som "det kun jeg og mine venner have lavet for 10mil" eller "hvorfor pokker har de ikke anvendt en agil proces?", så står jeg personligt af.

Det største problem er, får vi nogen sinde lov til at lære af det?

Vil hele processen, tankerne for hvorfor der er blevet ageret, tankerne omkring valg af teknologier, dataspecifikationer, etc, etc overhovedet blive offentliggjort husløst ærligt?
Jeg tvivler, og derfor er jeg rigtig bange for at vi lærer ikke en skid af sagen, for hvis vi ville lære bare det mindste, så har der jeg været nok af skandaler over de sidste mange år at tage af, og alligevel så går det galt gang på gang.

Og det er ikke sikkert at 4 mand og et par millioner kunne have gjort det, men nogen gange så er man også nødt til at tænke ud af boksen, og hvis nu man i stedet startede på at nå nogle realiserbare delmål, og vurderede på prototyper og disse delmål, så er det ikke utænkeligt at andre aktører end de sædvanlige koryfæer kunne komme på banen med en meget bedre løsning.

Endvidere er det også sådan at der er ingen der tør stille spørgsmålstegn ved selve arbejdsmetoderne og procedurerene hos kunden, så hvis kunden altid har ment at den bedste vej mellem A og B er via C,D,E, så er det meget få leverandører der har den lille drengs mod til at sige at det er da for åndsvagt, og kejseren ingen klæder har på.

At lave software er i sig selv svært - og at lave og implementere software i så store organisationer som Politiet er altså meget svært.

Der er vist heller ikke nogen der har sagt andet, men sjovt nok så kunne "de voksne" åbenbart ikke finde ud af det (selv om de er gode til at formøble pengene)!

bent madsen

Kære Cristian Nobel

Du har set dig ret sur på at nogen udtaler sig på baggrund af en del års og en del systemers erfaring (flest velfungerende heldigvis).
Men jeg tror såmænd ikke vi er så langt fra hinanden i synspunkterne.

Jeg vil give dig ret i din påstand om at man bør tænke ud af boxen de gange det er nødvendigt.
Problemet med det er at man skal have budget til at lave de analyser fra den organisation du vil have viden ud af. P.t. er ikke så ofte at et nyt system har den afklaringsfase som du efterlyser.
Ofte er der kun budget til at lave en massiv kravspecifikation.

At der så burde være en sådan foranalysefase for at sikre at systemerne bliver som kunden havde tænkt/har behov for, kan jo sagtens forsvares.
Men jeg har sjældent set at en offentlig organisation, ej heller mange private, sætter mio. af til at lave den form for risikominimering.

Hvis man kan få afsat budget til at lave et forprojekt, gerne v.h.a.
kørende delsystemer. Naturligvis helst lavet v.h.a. de std. system komponenter som leverandøren havde tænk sig at anvende.

Hvis det ikke kan lade sig gøre synes jeg at den bedste måde for kunden er at lave EU udbud efter forhandling. Der har man ret til at forlange at leverandøren stiller op med demonstration og evt. stiller med referencekunder som man kan besøge. Og det er noget nemmere at se om leverandøren har forstået kravene, når de skal vise noget på deres egnen platform. Og jeg synes også at man som kunde bliver mere tryg ved at se at leverandøren så faktisk er klar over hvad han skal levere.

Den endelige kravspecifikation kan laves som del af den sidste fase af udbudet når man har fået viden nok om de tilbudte systemers muligheder. Men det kræver et godt team som kan sikre at alle kravene bliver samlet op på div. forhandlingsmøder. Ikke nogen lille opgave for en organisation at sikre, og de skal en del IT erfaring til for at klare det.

Der er tidl. blevet lavet udbud med krav om "Commercial off the shelf" (COTS) systemer, altså standardsystemer til brug indenfor bl.a. Forsvaret, Luftfart etc.

Den smartesete kunde jeg har leveret til, valgte at lave en kravspecifikation som lagde sig op efter de standarder som COTS's systemeterne var baserede sig på (iflg. deres specifikationer). Og så udlevere de samtidig en testspecifikation som anviste hvordan de havde tænkt sig at systemet skulle verificeres via tests. Og de satte så en "skønhedskonkurrence" op efter få mdr. hvor man skulle køre testen igennem.
Jep, vi vandt opgaven fordi vi kunne køre en demo af systemet så de
kunne se at vi forstod hvad det var de efterspurgte.
Vi havde samlet demo'en af std. komponenter. Kunden fik vi aldrig problemer med, han var/er virkelig tilfreds med hvad han fik.

P.t. er de offentlige kunder nok et stykke fra at kunne være så innovative som Google. Den nuværende udbudsproces forventes jo at sikre at den færdige omfang er kendt fra starten. Men det gør den nuværende process desværre ofte ikke, især ikke når det kræves at
systemer er nyt og kan noget man ikke før har haft kendskab til i
organisationen.

Derfor ville det være fornuftigt at den blev ændret. Men det skal jo sikres at den bliver til det bedre!!
Så derfor er jeg kommet med advarslen om at det ikke bare er løst med at være Agil. Der skal meget mere til inden en samlet Agile process er klar til at sikre vandtætte estimater og aflevere systemer som gør alt det kunden havde drømt om.

Jeg håber at Polsag kan medvirke til erkendelsen af behovet for at få ændret udbudsprocessen og derved sikre at leverandørene får mulighed for at vise hvad de kan og dermed sikre at kunden er klar over hvad han får.

Og beklager hvis det har lydt som om man slet ikke kan anvende nytænkning, for det er der da brug for. Men det skal også kunne styres når det bliver stort, og der kommer politisk høgeøjne på programet som skal løse opgaven.

Som du sikkert kan se er vi ikke helt så uenige som du måske troede :-)

Log ind eller Opret konto for at kommentere
Brugerundersøgelse Version2
maximize minimize