Justitsministeriet har besluttet at droppe politiets nye sagsbehandlingssystem Polsag. Det erfarer Version2.
Hele efteråret har udrulningen af Polsag været sat i stå, på grund af problemer med systemet, da det blev sat i pilotdrift på Bornholm. Siden december 2010 har de 80 bornholmske betjente brugt systemet, men har dårlige erfaringer med systemet, der har lidt af tekniske problemer.
Derfor blev Polsag underkastet en større undersøgelse i efteråret 2011, som nu altså har ført til, at systemet bliver lagt i graven.
Udviklingen af Polsag blev sat i gang i januar 2007, med CSC som leverandør, og systemet skulle have været implementeret i 2008. Oprindeligt var budgettet på 153 millioner kroner, men det er siden steget til over 400 millioner kroner, som staten nu skal prøve at få tilbage fra CSC.
Hold øje med Version2 resten af dagen, når vi følger op på historien:
- Hvem har taget beslutningen?
- Hvad siger CSC?
- Hvad betyder det for politiet?
- Læren fra Polsag: Politikere skal have hurtig besked om it-skandaler
- Derfor blev Polsag skrottet: Ville koste 1,4 milliarder kroner
- Hemmelig rapport afslører CSC's og Scanjours katastrofale Polsag-kode
- Efter 6 års maratonudvikling: Ny Hitman er både agil og vandfald
- Ny it-chef for politiet: Som at renovere en flyvemaskine, mens den flyver
- EPJ-boss skal redde Rigspolitiet op af Polsag-sumpen
- Afsløring: Dårlig kodekvalitet lagde grunden for Polsag-skandalen
- Rigspolitiet fyrer it-chef
- CSC fyrer 1.140 ansatte i Storbritannien
- CSC fyrer 450 i Norden – flest i Danmark
- Staten overvejer at sagsøge CSC for Polsag-fiasko
- Skat overvejer at droppe CSC
- Nu går justitsministeren efter struben på CSC
- Få overblikket: Her er 73 statslige it-projekter til 4,1 mia. kr.
- Grotesk jobinterview i 2007: »Tag ikke jobbet, vi får alligevel aldrig Polsag til at virke«
- ITU-ekspert om Polsags manglende business case: Kompromitterende og dumt
- Ny kriseknuser skal rydde op i CSC's skandaler
- Bornholmske betjente: Polsag kunne skære en uge af opklaringstiden
- Enhedslisten: Nødvendigt med ny it-strategi, hvis skandaler skal undgås
- Venstre vil stille CSC til ansvar: Overvejer erstatningssag
- Rigspolitichef: Polsag ville blive en klods om benet
- It-ordfører (S): Ikke alle Polsag-millionerne er spildt
- Det betyder lukningen af Polsag for politibetjentene
- Her er CSC's it-skandaler
- Rigspolitichef efter skrotning af Polsag: »Vi tror ikke på projektet«
- Denne artikel
- Fejl og CSC-strejke forsinker Politiets Polsag-system - igen
- CSC i løftebrud: Garanterede tidsplanen holdt for Polsag
- emailE-mail
- linkKopier link
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
- Sortér efter chevron_right
- Trådet debat
@Christian Nobel Hokus pokus beregninger ? Det faktum, at du skal bruge en hel del rå disk for at holde og sikre en database er nu reel nok. Igen en 'system' løsning er så meget mere end bare den applikation der bliver udviklet., Hvis du med din lidt uklare formulering, fiskede efter noget andet. SÅ må du jo specifisere lidt bedre, hvad det er du fisker efter.
Jeg ved nu heller ikke rigtig om jeg vil kalde en IBM x100 for en 'server' en PC i et tower er vist mere sigende. Men din pointe med SKI er jo rigtig nok, det er så dyrt at komme med, at du er nødt til at blæse projekterne op, ellers så tjener du sku ikke noget på det. Men det er jo ikke leverandørenes skyld, men nærmere, at man fra offentlig side mener, at det at vælge hvem man vil købe IT projekter hos, best foregår ved at benytte en metode som er god når man gerne vil købe rigtig rigtig mange kuglepenne billigt.
// Jesper
Lige præcis den holdning lader til at være gennemgående hos offentlige indkøbere og deres leverandører.Jeg ved nu heller ikke rigtig om jeg vil kalde en IBM x100 for en 'server' en PC i et tower er vist mere sigende.
Det lyder næsten som en tilståelse. Føj!du er nødt til at blæse projekterne op, ellers så tjener du sku ikke noget på det.
Kære Peter Stricker.
"Lige præcis den holdning lader til at være gennemgående hos offentlige indkøbere og deres leverandører." Jeg tror du måske skulle tage et kig på, hvad der står rund omkring i offentlige Datacentre, ordet Server Sprawl++ kan vist ikke engang dække det.
"Det lyder næsten som en tilståelse. Føj!" Måske skulle du overveje at læse og forstå, hvad jeg skriver, tælle til 10 og tørre fråden rund om munden af. Jeg angriber jo netop SKI for at være tåbeligt.
// Jesper
Og du mener ikke, at den holdning du udtrykte overfor små systemer, kan være en del af årsagen?Jeg tror du måske skulle tage et kig på, hvad der står rund omkring i offentlige Datacentre, ordet Server Sprawl++ kan vist ikke engang dække det.
Er Server Sprawl++ ment positivt?
Det må jeg give dig ret i. Jeg fokuserede for meget på den del af din udtalelse, som jeg citerede. Det beklager jeg.Jeg angriber jo netop SKI for at være tåbeligt.
@Peter Stricker.
x100 er jo basalt en arbejdstation, eller en PC om du vil det, der har fået smækket et server label på sig. Det jeg ikke kan li', som topskatte ramt dansker, er server sprawl, hvor du har XXXX små servere, der alle måske kører med 1-2% average utilization. Det er simpelt hen offentlige penge ud af vinduet. Det har altså været sådan i en hel del år, at prisen på selve serveren kun er en del mindre del af udgifterne i et projekt, ting som strøm, datacenter space, vedligehold etc udgør en større udgift over levetiden af en server, en selve anskaffelses prisen. Og så er der lige hele miljø belastningen.
Og en stor kommune som Københavns kommune, må have nok behov for IT til at man kan lave det effektivt og kost økonomisk.
// Jesper
Og det er jo præcis der filmen knækker som Peter også er inde på, for det er udtryk for en tåbelig og elitær holdning som gør at det offentlige efterhånden har mistet hele jordforbindelsen og dette land er på vej ned i sølet.x100 er jo basalt en arbejdstation, eller en PC om du vil det, der har fået smækket et server label på sig.
Faktum er at mine X100 bokse kørte hamrende stabilt, brugte ikke ret meget strøm, og kunne levere en løsning der ret faktisk virkede og det endda godt.
Jeg har altså været der, og jeg har t-shirten, så jeg ved det virker - hvad det så i øvrigt ikke gør nu hvor det er blevet opulent.
Og så kan jeg fortælle at qua det X100 boksene er så billige kunne jeg have to bokse stående i reserve, og hvis de så begge to for den sags skyld steg af, så kunne jeg være i luften på under en time igen, efter genindlæsning af nattens backup.
Hvis behovet havde været at vi skulle have lavet det for hele landet, eller hele Europa for den sags skyld, så var løsningen altså skalerbar og jeg ville så måske have flyttet den over på IBMs eSeries servere i stedet - det er hvad jeg vil kalde rightsizing! Og læg så mærke til at CSC ikke engang kunne få et pilotprojekt med 80 brugere til at virke, så hvor var skalerbarheden lige der?
Mht. databasen, så fylder data faktisk ikke ret meget, aktuelt kan der, believe it or not, gemmes utroligt meget information på 1GB, og med diske på 80G falder din argumentation altså til jorden. Så jeg vil stadig holde fast i mit oprindelige udsagn, hvorfor ender vi op i disse grotesk store installationer (og igen, jeg har været der!).
Jeg er altså ved at brække mig over denne hovski snovski holdning der er til at vi skal genopfinde den dybe tallerken, gang på gang, og da det jo skal være åh så fint, så skal rumindholdet på tallerkenen altid være på mindst 200 liter, selv om suppen er blevet kold efter de første 5 skefulde er taget!
Vi bor i et lille snotland med 5,5 millioner indbyggere, men takket været djØFFERnes køren med klatten, og vennerne fra de store firmaers uanstændige ragen til sig, så bygges der "løsninger" op der, ud fra en prisbetragtning, måske kunne forsvares hvis vi var 500 millioner her i landet.
Det er for sølle, og jeg mener at vi i IT branchen bør erkende vores ansvar, og indse at for tiden er vi mere en del af problemet end en del af løsningen.
@Christian Nobel.
Måske taler vi lidt forbi hinanden. Jeg har stor respekt for systemer der er udviklet rigtigt. Igen jeg er fra DIKU, og startede med at kode på regnecentralens piccoloer, så ja jeg lidt old school og korser mig også når jeg ser systemer, der så absolut skal bruge x100 mere plads og processor ressourcer for at lave nøjagtig det samme, som det system det afløser. Vi er slet ikke uenige på det punkt, og hvis du ser på essensen i min 'udvikleren med den bærbare dualcore 4GB RAM maske' historie så er essensen i den jo netop, at hvis man gør tingene ordentligt behøver man ikke 2 GB ram per bruger etc etc.
Men når det så er sagt, så mener jeg stadig ikke at server sprawl er en god ting, jeg mener stadig også at det offentlige skal have standarder, og strategier der gør at de har styr på tingene, lige som alle andre virksomheder også bør det. Og jeg mener også at server konsolidering er måden at holde kompleksitet og især udgifterne nede.
// Jesper
Men når det så er sagt, så står jeg stadig ved
Nu kan vi så diskutere server sprawl, men jeg ser ikke noget odiøst i at sprede risikoen for at undgå single point of failure, og miljøargumentationen for at konsolidere med virtualisering eller ej kan have stort set 180 grader modsat udfald, afhængig af hvordan Månen stod i forhold til Orion den pågældende dag.Men når det så er sagt, så mener jeg stadig ikke at server sprawl er en god ting
Men sagen er også at vores "lille" system faktisk løste en ikke uvæsentlig opgave, og nu efter der er gået big-is-beautifull i det ikke mere er et lille system - til gengæld så virker det slet ikke!
Oh ho, se nu rammer du måske noget meget essentielt, for tænk nu hvis man havde meget bedre styr på standarderne, således at udveksling af data mellem forskellige systemer var lade sig gørelig - så ville det måske slet ikke være nødvendigt med alle de monstersystemer der hver især har sindsygt meget overlappende data.jeg mener stadig også at det offentlige skal have standarder, og strategier der gør at de har styr på tingene, lige som alle andre virksomheder også bør det.
Og stadig så er Danmark altså et lille snotland med 5,5 millioner indbyggere, dvs. hele landet er meget mindre end mange storbyer i udlandet, og alligevel skal der laves konstruktioner der fylder terrorbytes, og koster milliarder, hvilket er helt til grin.
Christian.
Mht. til serversprawl, så set isoleret, f.eks. med udgangspunkt i det system du beskriver her, er der jo ikke noget galt i at lave en løsning som du beskriver. Igen du beskriver det som et system, der ikke er bloated, med en løsning stak der er 'god nok' til at løse formålet. Sådan skal det jo være, set isoleret. Men når man snakker om store kommuner som Københavns kommune, om regioner og om staten generelt, så har man jo enormt meget IT. Jeg mener ikke at man kan tillade sig, set fra et økonomisk synspunkt, at fortsætte på den måde som tingene kører på i dag. Man er nødt til at centralisere og standardisere.
Jeg er ikke enig at en sådan tilgang vil forhindre mindre leverandøre i at levere til det offentlige, men tværtimod facilitere at det 'offentlige' kan bruge mindre leverandører. Hvis du har kode standarder, standardiserede grænseflader, standard OS images .... alt sammen virtualizeret på enterprise hardware, så kræver det mindre vertikal løsnings stak ekspertise, at kunne udvikle og implementere en løsning. Du vil kunne få stillet et virtuelt udviklings miljø til rådighed, etc etc. hvis man nu har leverandører der leverer drift eller det offentlige kan have det inhouse.
Hvis nu du ikke skal levere en 'end to end' løsning, men 'bare' en applikation, så har du et mere større felt at vælge fra når du skal have lavet et 'system'. Igen du skal ikke, som leverandør, være i stand til levere det hele, du skal bare levere det du kan, nemlig en applikation. Og dette vil også betyde at man også kan vælge applikations udviklere efter deres forretnings viden og speciale. Igen man kan vælge et mindre firma med speciale i netop det man skal bruge, i stedet for en end to end leverandør.
Nå sønnen trænger til at komme ud og lege i sneen, så vi stopper lige her.
// Jesper
Det jeg ikke kan li', som topskatte ramt dansker - og som i øvrigt nok heller ikke er en fordel for de danskere, der ikke betaler topskat - er når simple, velfungerende systemer afløses af store komplekse systemer med en prisseddel der har mindst et ciffer mere end det gamle system.
Og lur mig om ikke den konsolidering som skal til for at øge server utilization og mindske miljøbelastningen, er med til at øge systemets kompleksitet med adskillige faktorer. Og derigennem alligevel øge miljøbelastningen. Pludselig skal der til at laves indtil flere SLA'er og hele projektstyringen bliver stor og kompleks. Og ikke kun i udviklingsfasen, men også når systemet skal sættes i drift. Og for at holde kompleksiteten i tøjler bliver man nødt til at skære igennem og fokusere på systemets behov og lade brugernes behov træde i baggrunden. Og i stedet for det lille team der lavede den lille elegante løsning Christian beskrev blev man i stedet nødt til at henvende sig til en stor seriøs leverandør der har en proven track-record med at lave store og komplekse løsninger.
@Peter Stricker Der er stor forskel på et lille system, som Christian beskriver her, når man kun har et af dem. Det kan godt være at det lyder godt i dine øre, men faktum er, at 'det offentlige' har mega mange systemer. Og hvis hvert enkelt system, er udviklet af forskellige leverandører med frie hænder, så har du måske hundrede af systemer med tusinde af fysiske maskiner, hvor du så finder alle typer af OS'er, disk systemer, system arkitekturer, kodestandarder, databaser etc etc etc. Sagt med andre ord...kaos. Og det er nøjagtig den beskrivelse, som en af mine bekendte kom med efter at have været til møde hos statens IT med x antal af djøffer, hvor man ønskede at spare 25% på drifts omkostningerne. Som han sagde, der var ingen forståelse for at der skulle investeres for at spares.
Og med så stor en kompleksitet, så er du helt sikker på at det kun er 'de store' der kan byde ind, på opgaver der går på tværs af så mange platforme, som f.eks drift.
// Jesper
(Et hint: TB)
Jeg får regnestykket til ag give 3,5GB (en 7-dobling af de 500MB).
Oh ja, tak Michael :)= GB så ikke TB, men få nu stadig det til en faktor 8.9. Og der er stadig en masse ting vi ikke har med.
// Jesper
Selv når du laver dine hokus pokus beregninger, så holder præmissen altså ikke, for det er klart at når du laver raids, spejlinger og jeg skal gi dig, så har du behov for mere fysisk harddisk kapacitet - men det er talfusk at sige at databasen som så bliver større.Og der er stadig en masse ting vi ikke har med.
Og det er det mit spørgsmål gik på, hvordan pokker kan det lykkes for nogen at få en relativt håndterbar database til at blive et kolossalt monster, som så pga. sin monsterstørrelse kræver endnu mere harddisk for at være på den sikre side, som så gør at projektet bliver endnu større, og og og....
Det er sjovt som man åbenbart mener at et simpelt system til at håndtere nogle få tusinde brugeres adgang til nogle hundrede tusinde poster kræver multimillion kroner mainframes og multimillion kroner Oracle databaser, og jeg skal gi dig, og MySQL mv. det er bare legetøj - underligt at Google og Facebook kan holde rede på millioner af brugere og milliarder af dataposter.
Helt ynkeligt bliver det så at systemet i en testfase (hvis vi skal sammenligne med din udvikler og hans bærbare), aktuelt Polsag med ca. 80 brugere, trods investeringen i alt det åh-så-fine hardware, de dyre databaser samt rat, gear og instrumentbræt alligevel ikke virker - tyder det så ikke mere på at den er helt gal med designet, og man ikke fatter en bjælde om at lave systemer der kan skalere?
Selv når du laver dine hokus pokus beregninger, så holder præmissen altså ikke, for det er klart at når du laver raids, spejlinger og jeg skal gi dig, så har du behov for mere fysisk harddisk kapacitet - men det er talfusk at sige at databasen som så bliver større.</p>
<p>Og det er det mit spørgsmål gik på, hvordan pokker kan det lykkes for nogen at få en relativt håndterbar database til at blive et kolossalt monster, som så pga. sin monsterstørrelse kræver endnu mere harddisk for at være på den sikre side, som så gør at projektet bliver endnu større, og og og....</p>
<p>Det er sjovt som man åbenbart mener at et simpelt system til at håndtere nogle få tusinde brugeres adgang til nogle hundrede tusinde poster kræver multimillion kroner mainframes og multimillion kroner Oracle databaser, og jeg skal gi dig, og MySQL mv. det er bare legetøj - underligt at Google og Facebook kan holde rede på millioner af brugere og milliarder af dataposter.</p>
<p>Helt ynkeligt bliver det så at systemet i en testfase (hvis vi skal sammenligne med din udvikler og hans bærbare), aktuelt Polsag med ca. 80 brugere, trods investeringen i alt det åh-så-fine hardware, de dyre databaser samt rat, gear og instrumentbræt alligevel ikke virker - tyder det så ikke mere på at den er helt gal med designet, og man ikke fatter en bjælde om at lave systemer der kan skalere?
Tak hr. Nobel - du har evigt ret - og det er godt formuleret. Jo vi skal have alle væk fra vanetænkningen om at det der drift behøver at være så dyrt som det gør. Lige nu er alle de her gamle driftsleverandører til det offentlige beskyttet af DS mm. Men det er en stakket frist, for der vil blive tilbudt drift til langt lavere priser i fremtiden (der er allerede leverandører).
Tak.Jo vi skal have alle væk fra vanetænkningen om at det der drift behøver at være så dyrt som det gør. Lige nu er alle de her gamle driftsleverandører til det offentlige beskyttet af DS mm.
Og nu er vil jeg så gerne løfte sløret for endnu en skandale som jeg desværre har været nødt til at gå stille med tidligere, men det kan sgu være ligegyldigt nu.
Vores firma har igennem mange år på vegne af en række kommuner i det Københavnske foretaget håndtering af indberetninger inden for affaldsområdet - ind til og med 2009 modtog vi data fra de forskellige aktører i et opland svarende til ca. en trediedel af landet.
En del af disse data blev indberettet til et relativt simpelt, men IMO uhyre velfungerende webbaseret system, baseret på Linux, Apache og MySQL, alt sammen kørende på 2 IBM X100 servere, den ene som webserver, den anden, isoleret bag firewall på begge sider, som MySQL server med spejlede diske.
Dette system kørte 24/7/365 i 3 år kun med et nedbrud som følge af et strømsvigt og efterfølgende dræning af UPS'en.
Systemet havde rigeligt performance til at kunne håndtere hele landets affaldsindberetninger, men desværre sker der så det at Miljøstyrelsen iværksætter et helt nyt paradigme for hele sektoren, uden på nogen måde at høre efter hvad der er af erfaringer (ikke kun vores men også andre interessenter).
I forbindelse med at der nu skal laves et landsdækkende system er vi jo selvfølgelig for små til at blive taget seriøst, så i stedet vinder Nitten opgaven, gennem et eller andet hemmeligt og obskurt SKI forløb, hvor ingen reelt må få at vide hvad det beløber sig til, men jeg vil umiddelbart gætte på at prisen ligger 5-10 gange højere end den vi ville have forlangt.
Og hvad værre er, så har de ingen faglig forstand inden for affaldsområdet, så der er blevet skruet et horribelt monstersystem frem, normaliseret til døde, således at ingen har noget reelt overblik over data.
Endvidere lavede man ikke pilottest på systemet, men iværksatte det direkte (efter de obligate forsinkelser) med virkning fra 1/4 2010, uden de aktører der skal indberette havde nogen chance for at teste om deres systemer ville fungere op mod det.
Resultatet af det er at sektoren er fuldstændig smadret, og der tidligst i 2013 (måske) kan komme nogle nogenlunde ædruelige data på området - dvs. 3 års planlægningsmulighed er smidt i kloakken, og det har kostet samfundet en formue.
Vi har sagtens kunne håndtere og kvalitetssikre de data der er tale om i mængder på omkring en halv million poster om året, uden at skulle køre med åh-så-oppustede systemer, men nu er der gået volumensyge i det, og så går det helt galt.
Man græmmes.
@Nikolaj Brinch Jørgensen
Nikolaj, jeg giver dig altså ikke helt ret. Der er tale om systemer, der skal replikeres, både mht. storage, servere og kommunikationslinjer OG personale. FSVA. personale, skal de faktisk også dubbleres til en hvis grad. Der er tale om systemer som død og pine skal være i luften 365/24/7 - det koster. Det er nu tilladt at skyde på mig og så sige: Hvad var det så lige, det skete for Danske bank og Mærsk, der havde entreret med landets vel nok mægtigste leverandør og sikkert ikke til peanuts? - hvor var hele backup scenariet henne og måske endnu vigtigere - hvorfor virkede det ikke? Summasumarum: store systemer koster forholdsmæssigt en del mere end små systemer - det vil jeg antage for en naturlov?
Jeg ved ikke hvad du ikke er enig i. Men jeg kan fortælle dig at hvis det er min anke imod at storage skulle være dyr, så kig engang på AWS. Hvis du synes det er dyrt, så OK, så er det dyrt. Jeg siger ikke vi kan ave det til samme pris, men jo større, jo billigere pr. GB - det hedder stordrift :-)Nikolaj, jeg giver dig altså ikke helt ret. Der er tale om systemer, der skal replikeres, både mht. storage, servere og kommunikationslinjer OG personale. FSVA. personale, skal de faktisk også dubbleres til en hvis grad. Der er tale om systemer som død og pine skal være i luften 365/24/7 - det koster. Det er nu tilladt at skyde på mig og så sige: Hvad var det så lige, det skete for Danske bank og Mærsk, der havde entreret med landets vel nok mægtigste leverandør og sikkert ikke til peanuts? - hvor var hele backup scenariet henne og måske endnu vigtigere - hvorfor virkede det ikke?
Summasumarum: store systemer koster forholdsmæssigt en del mere end små systemer - det vil jeg antage for en naturlov?
@Michael Christoffersen
Problemet med projekter der løber over tiden, er jo som regel, at man starter ud optimistisk, og køber ind til at starte med. Det er jo der man har Capex, og så køber man hele lortet og så 6 år senere står man med en platform, som man lige så godt kan smid ud. Og man har så måske skulle igennem en eller flere upgrades undervejs.
Jeg advokere altid for, at man starter med at købe udvikling systemerne og så langsom trapper op, efter en realistisk tidsplan. Igen, når 'bang for the buck' stiger som den gør, skal man købe sit prod system så sent som muligt. Og der er ingen grund til at have systemer stående i enten drift eller pseudo drift der ikke laver noget af værdi.
Igen er vi tilbage til forståelsen for, hvordan man udvikler og driver en total løsning. Og hvis dem der skriver udbuddet ikke forstår det og tager højde for det.. så er det penge ud af vinduet...
// Jesper
@Christian Nobel
"Jeg undrede mig bare over hvordan datamængder i nogen sammenhænge har en tendens til at svulme gevaldigt op, således at 500MB reel information af en eller anden uransagelig grund pludselig er blevet til 500TB, uden der er blevet tilført nogen nytteværdi, what so ever."
Ok en faktor x1000 er måske lidt i overkanten.. men det løber hurtigt op, ikke at det her er en exact science, så your milage may vary.
500 MB reel information i en tekst fil. Lad os starte med at lægge det ind i en database, hvor data så blæses lidt op, man bruger måske ikke varchar eller whatever. Lad os sig 25%. Så skal der lige være lidt ekstra plads i tabellerne til at starte med 25% free space. Så skal der index'er på +100%, så rammer det et filsystem lad os sige 5%, så er der måske en Logical Volume manager 2% overhead, så rammer du så et disk system hvor der er Raid 6 på + en hot spare disk, lad os sige at du kører 7+P (14%) og har en hot spare per 16 diske (6%), disk systemet har så et overhead også, når det nu giver dig en virtuel disk, 10%. Tingene er så spejlede off site 100%. Altså er vores 500 MB data pludselig blevet til 4.5TB rå disk.
Mine beregninger her oven for er bare sådan lige taget fra hovedet, så ja .. og det varierer jo fra implementering til implementering, meeeeenn... Så ja...
// Jesper
Jeg formoder du godt selv kan se fejlen!Altså er vores 500 MB data pludselig blevet til 4.5TB rå disk.
@Christian Nobel
Fejlen ? Mangler jeg noget, er der nogle af mine estimater der er helt hen i vejret ?
Jeg er ikke helt med.
// Jesper
@Peter Makholm
Det lyder ikke helt forkert, måske lidt i underkanten. Det afhænger jo i høj grad også af, hvor mange subcontractors, der er inde over og hvor mange senior folk (++ med vinger og accelerator) du har med i projektet, desuden er der jo så som regel noget mængde rabat. Men det er jo så kun 'cost en' for leverandøren. Så skal der jo tjenes penge oven i hatten, og for subcontracters er det så profit af profit.
// Jesper
Det her er jo i bund og grund et politisk problem.
Hvis man skal have udviklet systemer 'ude af huset' så er det kanon vigtigt at man stadig 'inhouse' har de rigtige tekniske kompetencer, således at man kan have mod/medspil til leverandøren. Således at man kan have sine egne strategier, forståelse for andre systemer, som måske driftes/er udviklet af andre leverandører. Folk der også kan sige, OK det her krav der står i udbudet, kan vi godt se rent teknisk, at vi kan undvære hvis vi.. bla bla.. også fordi det koster os for meget og ikke giver os den værdi bla bla.. I stedet for at du har en Djøffer der sidder firkantet og insisterer på at det skal være sådan, uden at forstå hvad det drejer sig om, selv om det måske er noget der sætter projektet i fare.
Alternativt så skal man helt overlade det hele til leverandøren, og så bare stole blindt på denne. Det sidste er der nok meget få der vil anbefale :)
Men så da for pokker opbygget en ordentlig offentlig IT organisation, der kan sørge for at tingene foregår rigtigt.
// jesper
Man behøver ikke sidde med en masse kompetecer som kunde, man skal bare sørge for at vælge en leverandør der har det, og så skal man stole på ham. Problemerne opstår når man som kunde begynder at blande sig i service navne, LDAP objekt navne, tvinge brugen at æøå igennem på source kode niveau, insistere på at XML er human readable og skal være det, selv vil designe XML skemaer i SA eller andet super lamt EA værktøj. Så falder kæden af, og samarbejdet bliver surt.Hvis man skal have udviklet systemer 'ude af huset' så er det kanon vigtigt at man stadig 'inhouse' har de rigtige tekniske kompetencer, således at man kan have mod/medspil til leverandøren. Således at man kan have sine egne strategier, forståelse for andre systemer, som måske driftes/er udviklet af andre leverandører.
Mener du ikke, at det er den opskrift, politiet har fulgt?Man behøver ikke sidde med en masse kompetecer som kunde, man skal bare sørge for at vælge en leverandør der har det, og så skal man stole på ham.
De har valgt CSC ligesom mange andre offentlige kunder, og de har stolet blindt på at de kunne levere varen.
@Nikolaj Brinch Jørgensen "Man behøver ikke sidde med en masse kompetecer som kunde, man skal bare sørge for at vælge en leverandør der har det, og så skal man stole på ham. Problemerne opstår når man som kunde begynder at blande sig i service navne, LDAP objekt navne, tvinge brugen at æøå igennem på source kode niveau, insistere på at XML er human readable og skal være det, selv vil designe XML skemaer i SA eller andet super lamt EA værktøj. Så falder kæden af, og samarbejdet bliver surt."
Du har ikke ret, når du skriver tingene så generelt som du gør. Mht. til lowlevel implementations specifikke ting som du nævner her, så er jeg enig. Det behøver du nødvendigvis ikke, at have en holdning til. Med mindre du da er så fremsynet at du har standarder på området, som også følges i alle de andre systemer du har fået udviklet ude i byen.
Men et af de problemer man har i det offentlige er, at du har alt, på alle niveauer i løsnings stakken, og i alle kombinationer. Og det er jo, netop det man får, når man overlader det til leverandøren, at stå for det hele. Og så er det, at man ender i vendor lockin. At man ikke kan høste stordrifts fordele. At man mister overblikket, at man ikke får lavet en ordentlig solution lifecycle mangement, at man ender op med usupporterede løsnings stakke, hvor man igen er nødt til at lave en Big Bang løsning, typisk i form af et helt nyt system, som man så skal ud og opdigte en eller anden tåbelig business case på som ikke holder stik.
Du bør have en IT strategi, der også eksekveres, således at du har en vis strømligning af dine løsninger. Og en af de strategier kunne jo være f.eks. at man kun brugte åbne standarder, at man ønskede at fokusere på TCO og ROI i sine løsninger modsat bare at se på TCA som man plejer at gøre. etc etc etc. Desuden så skal man også vide noget om, hvad det er man har i dag. Igen det nytter ikke noget at få udviklet et system, der forudsætter at man har en hurtig PC og en lan forbindelse, hvis det man har stående på en bornholmsk politi station er gamle maskiner på en sløv sløv Wan forbindelse.
// Jesper
Tag en tur over sundet og spørg svenskerne hvad de har gjort rigtigt:
https://www.version2.dk/blog/den-historie-vi-bare-en-gangs-skyld-gerne-ville-hoere-42924
@Christian Nobel
Det er sådan noget man skal se på Top Down, og ikke Buttom Up. Igen tilbage til udvikleren med 1 Bruger (sig selv) på sin dual core 4GB RAM laptop, der brokker sig over at performancen på en 8 core 64 GB RAM (mener jeg det var) maskine med 500 samtidige brugere, er dårligere end den er på hans maskine. Og at det er et Server problem.
Tja ja.
// jesper
Jamen men jeg er ikke uenig i at man skal danne sig et mere holistisk billede, men det betyder ikke man skal navigere i blinde, og derfor bare puste tingene urealistisk op.Det er sådan noget man skal se på Top Down, og ikke Buttom Up. Igen tilbage til udvikleren med 1 Bruger (sig selv) på sin dual core 4GB RAM laptop, der brokker sig over at performancen på en 8 core 64 GB RAM (mener jeg det var) maskine med 500 samtidige brugere, er dårligere end den er på hans maskine. Og at det er et Server problem.
Jeg undrede mig bare over hvordan datamængder i nogen sammenhænge har en tendens til at svulme gevaldigt op, således at 500MB reel information af en eller anden uransagelig grund pludselig er blevet til 500TB, uden der er blevet tilført nogen nytteværdi, what so ever.
Og jeg er helt enig i dig med udvikler eksemplet, en af mine yndlingsaversioner er såkaldte "webudviklere" der snasker håbløse hjemmesider sammen, men fordi de jo fungerer fint lokalt, så virker de nok også på internettet.
Jeg kan også fortælle om en leverandør der engang sagde til en af mine kunder at de skulle have en større og hurtigere server, fordi den de havde nu ikke kunne "responderer" (ja han kunne heller ikke forstå det med ubestemt form - grrrr) hurtigt nok. Jeg analyserede hvor skoen trykkede og lavede en løsning der fungerede, vel at mærke uden at skifte serveren - og det er jo nok i virkeligheden det der er den virkelige lektie, nemlig at man er nødt til at sætte sig ind i tingene, og ikke glemme en vis grad af KISS tænkning.
@Jonas Hovgaard
Det er jo netop sådan en holdning, som den du giver udtryk for der, til resten af løsnings stakken, der ofte får projekter til at gå over budget eller komme i problemer.
Hvis du viste, hvor mange gange jeg, og flere af mine venner har fortalt samme historier, har siddet, som konsulent har været kaldt ud for at løse et performance problem, hvor der så sidder en udvikler med sin 4Gbyte Ram dual core bærbare og brokker sig om at 'serveren' ikke leverer og at det er noget crap produkt XXX lort og hvis bare folk ville gøre deres arbejde ordentligt, fordi på hans bærbare, som jo kun koster 5.000 kr kører det jo fint. (true story btw.)
Så man skal have respekt for hele løsnings stakken, der er ikke noget der bare er "bare"... og du får ikke specielt meget for 500K om måneden. Når du skal dække hardware, opsætning, licenser, drift, backup, support af udviklere etc etc.
// Jesper
Det er rigtig, men det har nu altid undret mig over hvordan datamængderne kan blive så enorme at man tror det er løgn, og dermed retfærdiggøre svimlende store systemer.Så man skal have respekt for hele løsnings stakken, der er ikke noget der bare er "bare"... og du får ikke specielt meget for 500K om måneden. Når du skal dække hardware, opsætning, licenser, drift, backup, support af udviklere etc etc.
Tag eksempelvis CVR registret som trods alt ikke hører til i småtingsafdelingen - der er ca. 700.000 poster i det, og selv om man laver ret store manipulationer af data der er nødt til at trække fra det samlede CVR register (lagt over i en MySQL database), så er det altså ikke noget der trækker specielt mange tænder ud.
Så hvordan hulen kan det lykkes nogen at få systemer der skal håndtere langt færre data til at svulme op så de ender med at koste trecifrede millionbeløb, endda uden der er mulighed for 2 brugere samtidig?
Eller tag CMR - herregud vi taler om 2 millioner omregistreringer per år, og det er altså ikke raketvidenskab.
Det er mig en gåde.
@Nikolaj Brinch Jørgensen.
Jeg mener sådan set, at du starter godt ud i din kommentar, og peger på et par væsentlige punkter. Jeg er så nødvendigvis ikke enig med det hele af resten :)
Selve det, at det her projekt går galt, er jo kun et symptom på noget underliggende.
Et af dem, som du også skriver, er det at lovgivningen ændrer sig så meget som det gør, det er måske så ikke lige så relevant med hensyn til POLSAG, men det at lovgivningen ændrer sig hele tiden gør jo at der skal bruges enorme mængder af ressourcer til at ændre systemer, og lave midlertidige arbejdsgange etc. Og når det er ændringer til systemer under udvikling, så er det noget der som regel vil adderer signifikant risiko til projektet.
Og du skriver så også om 'suits'ne', oh jahhh. Når man læser offentlige udbud kan man se deres fingeraftryk over alt. Bod, fælder, Bilbladsagtig IT visdom, Buzword Bingomania, ansvars forflyttelse etc etc. Alt sammen noget der ikke bidrager til en konstruktiv løsning. Der går rent Djøffistan i den, og nogen gange kan man kun sidde og ryste på hovedet. Jeg glemmer aldrig da jeg selv skrev udbud, hvor vi f.eks. havde et par konsulent huse inde over, for at management kunne føle sig sikre. Nogle af dem prøvede hele tiden af flytte fokus fra essensen i udbuddet over på den del, hvor de havde ekspertisen, og få pisket en stemning op så "systemet", blev så stort som muligt. "I skal have leverandørerne til at garantere oppetid og lave risiko sharing og så skal i have 99.98% oppetid". Det skulle vi så ikke, jeg husker at vi fik barberet bare hardware regningen ned fra 30 millioner til 4 millioner. Ved simpelt hen at vide, hvad vi havde brug for og så købe, stadig høj høj kvalitets UNIX hardware. Tja ja.
Og endelig så er reglen jo, ikke undtagelsen, at offentlige IT projekter enten løber over budgettet, ikke med 5-10-15-20-25% som kan forklares, men med en faktor, hvor der så kræves en længerevarende dyr undersøgelse, som man så ikke tager ved lære af. Eller så går de helt i udu.
Og det kan man altså ikke skylde 100% på leverandørerne. Der er altså nogle underliggende problemer, som man er nødt til at adressere i det 'offentlige'.
Og det hjælper jo heller ikke, at man fyrer alle de folk der prøver, at få tingene til at fungere. Det er jo igen en rigtig rigtig dårlig investering, og personlig mener jeg at det er her en af grundene ligger begravet.
// jesper
Hej Jesper,
Jeg fejler totalt i at se hvor vi er uenige?
Jeg fejler totalt i at se hvor vi er uenige?
Når jeg nu læser dit indlæg igen så kan jeg heller ikke se det. Jeg tror at de store mængder snot jeg har i hovedet lige nu, har spillet mig et puds :)
Jeg er så ikke nødvendigvis enig i din kommentar: "Jo det er billigt. Det er det bare ikke hos de store danske leverandører til det offentlige. Det kan etableres og driftes for en brøkdel af hvad der i dag betales for storage."
Ja, overhead og timepriser (som ofte kan være to sider af samme mønt) er typisk signifikant billigere hos mindre leverandører. Men der er altså også et element af, at 'du får hvad du betaler for' :)=
Jeg skal ikke forsvare nogen, men jeg er af den helt klare holdning, at det at købe kvalitets hardware altid kan betale sig, og holde det up to date. Jeg har måtte rydde op i for mange fejldesignede løsninger, hvor den variable kost har været kæmpe stor fordi man har sparet på hardwaren. Men det skal så også siges, at jeg har set offentlige IT projekter hvor man brugte 75% af hardware og licens budgettet på at købe nogle enterprise disk bokse, som man egentlig ikke rigtig havde brug for. Men leverandøren fløj selvfølgelig, med privat fly, også dem med beslutnings kompetence til rundvisning i deres fabrik, med efterfølgende frokost etc etc etc. Men igen sådan er der så meget.
// Jesper
Så kunne det være rart med en mere fornuftig angrebsvinkel og bygge et system i mindre dele, evt. skalere det sådan, at man har nogle elementer på plads hver 3. måned, og kan checke dem af, at de fungerer.</p>
<p>Disse massive alt-på-en-gang systemer viser gang på gang, at de aldrig lader sig udvikle planmæssigt.
Tror bare ikke det lader sig gøre at lave det ordentligt i mindre bidder med den udbudsmodel det offentlige benytter.
Jeg synes klart de burde dele det op i mange del-projekter som kunne komme i mindre udbud, samt at projektledelsen var et helt seperat udbud hvor der ikke blev fokuseret på pris men kompentancer.
Egentlig synes jeg at source koden, til offentlige projekter som disse, skulle være offentligt tilgængelig så alle kan sætte sig ind i hvordan systemet er lavet. På den måde kan man også, f.eks. som mindre softwarehus, sætte sig ind i systemet på forhånd og kode nogle gode udvidelser det kan sælges til de offentlige institutioner (politiet i dette tilfælde). Man ville derved få fordelt udviklingen på langt flere virksomheder og meget ville kunne udvikles lokalt. Hvis f.eks.
Når et projekt kører så grundigt i hegnet som det er sket her, må der nødvendigvis være fejl på begge sider. Så regn roligt med at størstedelen af de 400 mio. skal dækkes af skatteyderne.
På den baggrund synes jeg det ville være rimeligt at al dokumentation for projektet blev lagt ud til offentligheden. Kontraktgrundlag, kravspecifikationer, ændringsanmodninger, styregruppereferater - rub og stub. Så kunne alle med tid og interesse "obducere" projektet og give alle parter begrundede gode råd.
Jeg ved udmærket at der er alle mulige fortrolighedsklausuler i aftalegrundlaget, men det ville klæde begge parter at frafalde dem.
Undskyld Jonas, men der er altså mange andre udgifter end bare selve mande tiden til udviklingen af "et system".
Der skal købes licenser, der skal købes hardware der skal være en udviklings platform, der skal driftes og og og og og ....
Der bliver også peget meget fingre af CSC, men faktum er altså, at ansvaret ligger hos opgavestiller, som jeg formoder er rigspolitiet. Så som skatteborger er det der man skal rette kritikken. Dermed ikke sagt, at det ikke er CSC's skyld eller.. men det kan ikke KUN være deres skyld. Mine egne personlige erfaringer fra at have siddet på begge sider i sådanne udbud her, er at en stor del af skylden også ligger i selve måden der laves og skrives udbud på, for slet ikke at tale om manglen på strategi og vision i den offentlige IT.
Der er altså en grund til, at det er så få, der faktisk tør/gider give tilbud på offentlige udbud.
// jesper
Ja, jeg er udmærket klar over at der er udgifter til andet end mandetimer, men det er dælme da begrænset.
Jeg arbejder til dagligt i Microsoft miljøet, som må anses som et af de dyreste. Sammenligner jeg, så er de udgifter nærmest ligegyldige mod et budget på 400 millioner. Fair nok, lad os skære 10 udviklere fra, så har du 500.000 kr. om måneden til licenser og udgifter. Det hænger stadig ikke sammen...
Jeg er ikke helt klar over hvorfra jeg har det, men når jeg laver overslag på den slags historier så regner jeg med at en fuldtids udvikler koster en million i drift om året.Ja, jeg er udmærket klar over at der er udgifter til andet end mandetimer, men det er dælme da begrænset.
Det skulle inkluderer alt fra løn, kontorvedligehold, rengøring, personaleledelse, økonomistyring, efteruddannelse, forsikringer og så videre.
Det giver 66 mandeår per år der skal fordeles på programmøre, systemarkitekter, UI-folk, process-konsulenter, ....
Hvorfor tror du at MS er det dyreste. Har du checket prisen på stuff fra Oracle og IBM? Det er monster dyrt.Jeg arbejder til dagligt i Microsoft miljøet, som må anses som et af de dyreste. Sammenligner jeg, så er de udgifter nærmest ligegyldige mod et budget på 400 millioner. Fair nok, lad os skære 10 udviklere fra, så har du 500.000 kr. om måneden til licenser og udgifter. Det hænger stadig ikke sammen...
VI lever i en branche hvor der stadigt er en stor del der tror på de hedengangne mega-fail metoder til udvikling. Se blot på diskursen i denne nylige debat:
https://www.version2.dk/blog/ud-med-v-modellen-43147
Der er en hel horde af folk der sværger til disse dino-modeller. Om det er fordi det er beskæftigelsesterapi, for folk som egentlig ikke har noget at gøre i IT branchen (de kan følge en proces manual, men det kan man sætte alle der kan læse til). Der er fyldt med dette rundt omkring. Før offentlige og andre begynder at lade være med at hyre dyre konsulenter til at "hjælpe" dem med at få udarbejdet projekter (det har noget med at man så har nogle meget dyre jakkesæt man kan tørre ansvar af på), så Ændres intet - desværre.
Jeg tror de fleste (sådan som jeg lige kan læse tråden indtil nu), er meget for, at vi begynder at forsøge at udvikle disse systemer langt mere iterativt, og måske starter med noget Kanban, discipliner fra eXtreme Programming og muligvis noget Scrum (Scrum er svært og ikke noget man bare lige gør - så den er optional - men nogle elementer kan bruges). Men man skal forstå at disse nyere metoder er afhængige af at den enkelte tager ansvar, og er villig til at blive eksponeret, både for det man kan og det man ikke kan. Det er en trussel for mange. Der er en del der ikke bryder sig om det regelsæt. Drivkraften skal komme fra det offentlige, der enten får nogle rådgivere ind, eller nogle folk der selv tør tage ansvar, og så skal de turde satse på at den slagne systemudviklingsmetode de hidtil har benyttet, ikke længere er gangbar valuta, så i de krav der stilles til leverandøren, skal der være metodekrav. AMS har gjort det https://www.version2.dk/artikel/agil-udviklingsmodel-goer-offentlige-projekter-gennemsigtige-31716, og jeg har været involveret i flere ander projekter i det offentlige hvor vi med meget stor succes har anvendt agile metoder. Paradoxet sker, når der skal laves store løsninger. Altså projekter som løber over lang tid. Det er sådan at jo længere tid et projekt løber over jo større er risikoen for at kravene vil ændrer sig (lovgivning osv.). Derfor skal man have en proces som giver mulighed for kravsændring. Det gør de metoder man vælger at anvende på netop store projekter ikke. De har massive change boards, ændringer er meget dyre at få lavet for kunden. Netop i disse situationer giver det enorm meget mening at benytte en helt anden type metoder/processer.
Det er snart trættende at høre om disse historier, og se hvordan der intet gøres ved det.... Der er masser af penge i fallit-systemer for en hel bunke firmaer. Husk også at etableringen af et system er en ting. Der er betalt driftsregning til den helt store guldmedalje løbende, udgifter der for det meste ikke ser dagens lys. Men som det er i DK, så er drift så heftigt prissat, at det offentlige betale ..... ud af bukserne på den konto.
Nikolaj, jeg tror altså ikke det vigtigste at diskutere her er projektmodellen - men mere hvordan offentlige projekter er i udbud og styres. Som det er nu fokuseres der meget ensidigt på udbudspris når der vælges leverandør og udbudende er så detaljeret skruet sammen at det er umuligt at lave ordentlig idéudvikling undervejs.
Du skal et niveau højere op hvis du vil udbudspris fokus til livs (det kan altså godt lade sig gøre at vinde udbud selvom man er dyrest). Der fokuseres alt for ofte på Todenskjolds soldater i mine øjne.Som det er nu fokuseres der meget ensidigt på udbudspris når der vælges leverandør og udbudende er så detaljeret skruet sammen at det er umuligt at lave ordentlig idéudvikling undervejs.
Der er stadigt en del golf-bane/jagt inde over hvem der tildeles opgaverne, tror jeg.
Jo modellerne/processerne er en stor del af fiaskoerne. Big bang virker ikke! Slet ikke når opgaverne blier bare en lille smule store (6 mdr+ i varighed).
Der er stadigt en del golf-bane/jagt inde over hvem der tildeles opgaverne, tror jeg.
Jeg er helt enig.
I mine øjne skulle CSC forbydes at byde på næste projekt. Men de er så fedtet ind i alle offentlige opgaver at det er umuligt.
Og vi er også enige om at big bang projekter er noget lort. Men det stammer helt oppe fra, som du selv siger.
400 millioner er i mit hoved et vanvittigt beløb. Jeg har prøvet at lave et lille regnestykke ved at gå ud fra at 20% af pengene er gået til ansvarshavende (70.000 kr./måned) og 80% til udviklere (50.000 kr./måned). 400 millioner over 6 år giver så adgang til: 15 ansvarshavende 88 udviklere Alle på fuldtid.
Har jeg regnet forkert? Det er jo ikke realistisk!
Nu tror jeg ikke at regnestykket er så ligetil, som du opstiller det her. Der skal vel også bruges noget HW/licencer i både test, udvikling samt produktionsmiljøer, så der er en del andre faktorer der også koster. Eksempelvis storage og storage sikkerhed er ikke helt billigtt disse dage, men 400mill? - der bør man kunne komme rigtig langt. Hvorfor starter myndighederne ikke udbudskonkurrencer om systemerne? - så kan firmaerne levere store komplekse eksempler som kan blive testet af brugerne. Næe, istedet holder man sig til, at det der står skrevet på papiret - det passer og det tror man på, ganske ligesom da Københavns kommune ville udlicitere ambulancekørslen til et Svensk firma, der viste sig kun at eksistere i en gammel lade i Skåne og kun have een ambulance, men firmaet skrev jo, at de godt kunne løfte opgaven. Der er en god grund til, at de aftalebestemmende myndighedspersoner har bagdele, der sjovt nok ligner meget store kontorstole.. Let dog røveren og kom ind i kampen.
Jo det er billigt. Det er det bare ikke hos de store danske leverandører til det offentlige. Det kan etableres og driftes for en brøkdel af hvad der i dag betales for storage.Eksempelvis storage og storage sikkerhed er ikke helt billigtt disse dage, men 400mill? - der bør man kunne komme rigtig langt.
Mht storage og licenser mv, så er der vel ikke betalt for mere end højst nødvendigt? Jeg går da ikke udfra at man har betalt software licenser for samtlige 70.000 kommende brugere?... Det er vel først ved idriftssættelsen at der løber licensomkostninger på.
I Storbritanien skulle de afskrive tæt på 9 milliarder kr (jo, du læste rigtigt) på et kontrakt med sundhedssystemet (næsten 40% af firmaets markedsværdi), så har de kæmpe problemer med levering til et projekt med Skat.... Hvordan i alleverden tjener de penge?
Indtil videre er det jo ikke afklaret om CSC må afskrive de 400 millioner eller om staten alligevel ender med at betale en masse penge for det skrottede system.
På det offentlige...Hvordan i alleverden tjener de penge?
Uhadada... Uden at have noget som helst indblik i POLSAG systemet, tør jeg godt vove pelsen og sige, at det ganske simpelt er for dybt dybt latteligt, at en leverandør ikke engang kan få et sags/journaliseringssystem med 80 brugere til at fungere. Hvor er alle forundersøgelserne? Hvordan fungerer resten af det kommunale Danmark, hvis ikke deres systemer kan håndtere 80 brugere? Der skal ganske simpelt ryddes ud i hele det efterhånden gigantiske cirkusshow, som efterhånden belaster Danmarks økonomi. Polsag:400Mill. IC4:rigtig mange millioner o.s.v. o.s.v... Det kan være, at man istedet skal bruge en masse penge på at undersøge, hvorfor at offentlige projekter i en hvis størrelsesorden har det med fejle: IC4-POLSAG-DR bygningen o.s.v. Kan det være, at vi ganskle simpelt ikke er dygtige nok til store projekter herhjemme? Hvad laver alle de højtuddannede projektplanlæggere? God weekend til alle :-)
Som bruger af disse it-systemer er det surt, at vi politifolk ikke får noget nyere og bedre system.
Men det er mystisk at man kan nå at bruge 400 mio., før man finder ud af at systemet ikke virker.
Det viser endnu engang hvor dårlig projektledelse vi har i det offentlige.. At noget kan stikke helt af på den måde og så alligevel ikke blive til noget, er mig en gåde.
Endnu et empirisk bevis for at big bang implementering ikke virker når projekter når en vis størrelse... (og den er mindre end man tror).
Hvorfor holder firmaer og offentlige instanser ikke op med at gøre det... Det er jo idiotisk.
men det er jo typisk det offentlige/CSC ... Fatter ikke at man kan udvikle et system som slet ikke kan bruges til noget. Stik mig 400 millioner .. så ville jeg med glæde lave noget der virker :-)
Hvor svært kan det være !!!
Det er godt at man nu kan starte forfra - denne gang med en agil process, hvor man ikke behøver vente i mange måneder, før et nyt system bliver klar (når ellers udbudsforløbet er afsluttet).
...men så kunne man undgå de leverandører smo skal have sindsygt mange penge, og alligevel ikke leverer?
Er dette her Ekstrabladet?