Offentligt it-system til 164 millioner kroner bør droppes
It-systemet hos Arbejdsskadestyrelsen bør droppes, fordi det 164 millioner kroner dyre Proask-system giver alt for lange svartider i behandlingen af sager.
Det skriver Arbejdsskadestyrelsen selv i en pressemeddelelse. Udmeldingen kommer på baggrund af en stor rapport, som revision- og rådgivningsfirmaet Deloitte har lavet. Den viser, at det endnu ikke færdigudviklede Proask-system er alt for dyrt i drift.
»Deloitte-rapporten anbefaler, at Proask lukkes ned, fordi omkostningerne er for store, og der ikke er gevinster i form af sparet tid. Det skal vi tage meget alvorligt. Meget lange svartider vil betyde, at systemet bliver meget tidskrævende for vores sagsbehandlere,« siger Anne Marie Rasmussen, der er direktør i Arbejdsskadestyrelsen, i pressemeddelelsen.
Alt i alt opfordrer Deloitte Arbejdsskadestyrelsen til at finde et helt nyt system, da det ganske enkelt ikke kan betale sig at videreudviklet på det nuværende. Proask-systemet behandler hvert år en mindre del af de godt 64.000 sager, som styrelsen skal igennem.
Derfor vil en omlægning af systemet ikke få de store konsekvenser for de mennesker, som har sager liggende i styrelsen, mener Anne Marie Rasmussen ifølge Berlingske.
Proask skulle oprindeligt have været taget i brug i juni 2011, men blev først udskudt til juni 2012. Prisen steg dengang fra 136 millioner til 145 millioner kroner. Arbejdsskadestyrelsen og leverandøren Steria har undervejs været i slagsmål om løsningens kvalitet. Det endte i sommeren 2011 med, at Steria måtte betale dagbøder.
I dag runder prisen 164 millioner kroner, hvilket er med til at bringe Proask ind på listen over top-10 dyreste, offentlig it-projekter i Danmark.
- Efter 283 millioner kroner: Proask bliver skrottet
- Vingeskudt it-projekt: Glemte software og hardware for 7,4 millioner
- Denne artikel
- Nedbrud og langsomme svartider giver it-frustrationer i Beskæftigelsesministeriet
- Her er de 11 dyreste it-projekter i staten
- Arbejdsskadestyrelsens it-system skrider med 9 millioner
- 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.
Fortsæt din læsning
- Sponseret indhold
V2 Briefing | GENERATIV AI: Sådan bruger du det professionelt
Kunstig Intelligens22. marts kl. 13:16
- Sortér efter chevron_right
- Trådet debat
Udfordringen med PROASK er først og fremmest af ikke-teknisk karakter.
Projektet er en omlægning af processerne for sagsbehandling i Arbejdsskadestyrelsen med det formål at opnå en mere effektiv sagsbehandling. Arbejdsskadestyrelsen er ansvarlig for at udarbejde nye processer og gennemføre den organisatoriske implementering. IT-leverandøren er ansvarlig for at levere en teknisk løsning der understøtter de nye processer.
Det viser sig nu, at de nye processer ikke er tilstrækkelig effektive. Det er også derfor vi ser paradokset, at IT-systemet opfylder alle krav til funktionalitet og svartider, men man har stadig problemer med at høste gevinsterne.
Man kan nemt få det indtryk at der er brugt 164 millioner på IT-udvikling, men det drejer sig nok ”kun” om et to-cifret millionbeløb.
... Offentligt IT-system til 164 mill. er en stor succes!
Det ligger ud over min fantasis grænser hvordan et projekt som kan laves med et virtuelt privat netværk, en database og en brugerflade - alt med velkendte afprøvede og testede teknikker - nogensinde kan komme til at koste noget i nærheden af 164 millioner. Så kom af med det og lav noget ligesom alle andre kan.
Det, der er problemet, er at et udbud bruger meget tid/plads/ord på at forklare en meget lille del af systemet, som netop også er den del som kan løses med VPN, DB og UI. Dette er dog kun en lille del.Det ligger ud over min fantasis grænser hvordan et projekt som kan laves med et virtuelt privat netværk, en database og en brugerflade . . .
Udbudsmaterialet nævner kun i en sætning, at info skal hentes fra et støre set af eksisterende systemer, som tilhører andre offentlige/private instanser. Udviklerne finder derefter ud af de systemer enten ikke eksisterer, ikke virker, ikke kan kommunikere med andre systemer. Eller også så kommunikerer de over et interface, som dem der har udviklet det, heller ikke selv ved hvordan fungere. Og så skal man ellers poke datatyper osv. Hedder det 01-26-2014 eller 26-01-2014. ( Dansk Standard og ISO siger 2014-01-26 btw ). Er dette en UUID? er den så også unik? Når vi ser objektet igen fra det system, vil den da have samme UUID? Eller kommer der et nyt hver gang? Når den sender en komma separeret liste af tal, har de så en betydning? Køre de 8859-1 eller UTF? Eller blander de det bare lidt hist og her? Og hvad vil der ske når de ændre i deres system?
Projektet bliver normalt estimeret sådan at det der står meget om i materialet også estimernes højt. Selvom dette er lette. Det med at dokumentere dataformatet på de systemer der kommunikeres med er ofte slet ikke en del af estimatet, selvom dette ofte tager en meget væsentlig del af udviklingstiden.
Desuden er VPN imellem forskelige netværk sjældent den rigtige løsning, men stadig den mest brugte. Men den diskussion kan vi tage en anden dag.
Helt enig - der findes masser af glimrende "standard" journaliseringssystemet, som kan tilrettes for forholdsvis få kroner. Deprimerende at erfare at alle offentlige nye systemer starter med et overflødighedshorn af ønsker og krav, som alle kræver at it-leverandøren skal opfinde det varme vand. Minder mig om at da man opfandt det første hjul, som var firkantet, så "produktudviklede" man det til et trekantet hjul, så man dermed eliminerede et bump pr. omdrejning :-)
Polsas var netop et standard-system, som "bare" skulle tilrettes.der findes masser af glimrende "standard" journaliseringssystemet, som kan tilrettes for forholdsvis få kroner
Ja, det er svindel og humbug.
Endnu et kuldsejlet projekt fra det offentlige i en endeløs række: Arbejdsformidlingens AMANDA blev skrottet, Politiets POLSAG blev skrottet, DSBs IC4 kommer aldrig til at fungere. Jeg vil vædde 1000 kr. at indkøb af vores 30-40 nye kamply til ca. 1.000.000.000 kr. stykket også er penge ud af vinduet da USA efter mange års udvikling stadig ikke kan få det til at fungere. Hvem betaler? Det gør vi fattige der får beskaret dagpenge og kontanthjælp. Hvem tjener? Alle DJØF'erne, IT konsulenterne og inkompetente generaler. Vil personligt gerne proppe deres møgtog og jagerfly op i røven på dem!!!!
-at langt de fleste mislykkede projekter (Amanda, Polsag, hospitalsjournalsystemer, og mange flere) er sagsbehandlingssystemer - altså systemer som griber dybt, dybt ind i en hævdvunden praksis, som berører mange, mange medarbejdere (med megen forskellig it-tilgang), og som udsættes for uanede undtagelser og specialtilfælde (fordi ikke alt kan være regelret når mennesker er involveret).
DERFOR er udviklingsprocessen helt afgørende - mange før mig har talt om trinvis udvikling, prototyper, ændring af interne processer, osv.
De nævnte mislykkede projekter er alle baseret på den vrangforestilling, som Kammeradvokaten i høj grad bidrager til, at projekter kan kontraheres i fast pris og tid. Staten har været uvillig til at acceptere den tilsyneladende usikkerhed som ligger i alt andet end 1) store kravsspecifikationer, 2) fast pris, 3) bodsbetingelser.
ER der nogen læsere som kan beskrive projekter med succes - og ikke mindst komme med nogle årsager ?
P.S.: De konkrete system er kontraheret før nogle af de nye toner så dagens lys - så forliset af projektet er måske bare gammel tankegang ....
Jeg var i 2008 med til at skrive tilbud på PRO*ASK, og ud fra oplægget er det ikke så frygtelig underligt at det kan gå galt på både proces og resultat.
Det udbudte system skulle understøtte en meget lang række arbejdsgange, integrere tæt til højre og venstre, og ikke mindst skulle det afvikles køre på en generel procesmotor (BPMS), så man kunne bygge forretningsgange om efter behov, eller hvordan det ellers var formuleret. Det var den gang folk stadig troede at man kunne købe en færdigstøbt løsningsarkitektur i en kasse, og så bare fylde funktionalitet på.
P.S: Det tilbud, jeg skrev på, var altså ikke det, der vandt, og måske var det meget godt.
Det undrer dog mig at debatten ovenfor overser at rigtig mange landes offentlige IT systemer har tilsvarende problemer. Healthcare.gov, anyone? CSCs NPfIT i Storbritannien? Rusland?
En af grundene til udviklingstiden kan også være love og regler.
Love og regler i det offentlige (kontanthjælps lov, lov om arbejdsmarked osv osv) er meget komplicerede. Faktisk så komplicerede at sagsbehandlerne ikke har mulighed for at kende dem alle sammen. For at give os borgere en ensartet og lovlig behandling i systemet, har man bestemt at have IT systemer som "kender" alle regler og love, og kun giver mulighed for at ens sag bliver behandlet korrekt. Dette er meget svært at lave. En ting, som gør det ekstra svært, er at love og regler bliver ændret temmelig ofte i Danmark, og derfor vil disse systemet i princippet aldrig kunne blive færdige.. Det er ikke muligt at implementere 60 hyldemeter lovtekst i et system, når denne lov konstant er i forandring.. og selv når en lov ikke skrives om kan den "ændre" sig alligevel, hvis der kommer en ny fortolkning fra en domstol eller anden myndighed. Husker med gru tilbage på et projekt jeg arbejdede på.. hver gang vi var stort set færdige, kom der en ny bekendtgørelse, og så var arbejdet i princippet spildt, da systemet ikke længere levede op til lovgivningen på området...
En af grundene til udviklingstiden kan også være love og regler.</p>
<p>Love og regler i det offentlige (kontanthjælps lov, lov om arbejdsmarked osv osv) er meget komplicerede.
Faktisk så komplicerede at sagsbehandlerne ikke har mulighed for at kende dem alle sammen.
For at give os borgere en ensartet og lovlig behandling i systemet, har man bestemt at have IT systemer som "kender" alle regler og love, og kun giver mulighed for at ens sag bliver behandlet korrekt.
Dette er meget svært at lave.
Der er reelt to muligheder - enten skal vi bare konkludere at det ikke kan lade sig gøre at implementere et IT system som dækker de processer på grund af kompleksiteten og foranderligheden. Og så lade være med at spilde penge på det.
Eller så skal vi have gang i en forsimpling af processer og lovkomplekser før vi overhovedet begynder at tænke på IT-ificering.
Har Version2 søgt aktindsigt så vi kan komme til at læse den?
Lige som mange nye versioner af windows, med 8 som undtagelse, kun kunne køre næsten rimeligt på de allenyeste PC. Så venter vi bare på at computer hastigheden komspencere for manglende, dårligt og inkompetent programmering.
Har jeg nævnt det før ?
... God ide, bare der så også er en eller anden form for sanktions struktur i ryggen af den.... ikke nødvendigvis en magtkompetence der skulle ligge i selve IT-havarikommissionen, men måske et andet organ der havde pligt til at følge op og sanktionere på baggrund af IT-havarikommissionens undersøgelser.
Ville hade at se en tandløs løve der kan brøle, men intet kan gøre for at tvinge myndigheder/stat/kommuner til at lære af deres fejl.
God ide, bare der så også er en eller anden form for sanktions struktur i ryggen af den
Nej, det er hverken ITHK's opgave eller problem, den slags har vi kontrakter og domstole til.
ITHK skal bare afdække hvad der gik galt og hvorledes vi kan undgå at begå den/disse fejl igen.
Nej, det tror jeg da ikke ;-DHar jeg nævnt det før ?
Jeg tror at de mislykkede projekter ofte hænger sammen med statens måde at entrerer på; der ville aldrig nogen sinde være en privat aktør som ville tillade udvikling af systemer på timebasis. Jeg ved godt at staten indhenter "tilbud", men der er så mange buffere i de afgivne tilbud at der reelt er tale om udvikling på timebasis og når så samtidig IT-firmaerne mener at de skal honoreres med kr. 4.000,- plus, i timen, kan det ikke gå andet end galt. Kravet til staten må være, at staten laver noget ordenligt udbudsmateriale som ikke honorerer systemer der ikke virker eller ikke bliver færdige til tiden. Hvis ikke IT-firmaer er i stand til at afgive tilbud på disse betingelser (som alle andre leverandører er underlagt), er de ikke kompetente til at deltage i tilbudsafgivning - slut prut!
@Michael Wörffel Intile
Statens IT-projekter</p>
<p>Jeg tror at de mislykkede projekter ofte hænger sammen med statens måde at entrerer på; der ville aldrig nogen sinde være en privat aktør som ville tillade udvikling af systemer på timebasis. Jeg ved godt at staten indhenter "tilbud", men der er så mange buffere i de afgivne tilbud at der reelt er tale om udvikling på timebasis og når så samtidig IT-firmaerne mener at de skal honoreres med kr. 4.000,- plus, i timen, kan det ikke gå andet end galt.
Kravet til staten må være, at staten laver noget ordenligt udbudsmateriale som ikke honorerer systemer der ikke virker eller ikke bliver færdige til tiden. Hvis ikke IT-firmaer er i stand til at afgive tilbud på disse betingelser (som alle andre leverandører er underlagt), er de ikke kompetente til at deltage i tilbudsafgivning - slut prut!
Jeg ved ikke, om du er sarkastisk. Men den model, du beskriver, er præcis den, der fører til de store skandaler. Kæmpestore kravspecifikationer og fastprisaftaler fører direkte til skandalehelvedet ad en vej belagt med ændringsanmodninger. At udvikle it-systemer er ikke det samme som at bygge en bro. Du kan specificere en bro ret komplet, men ikke et it-system. En komplet kravspecifikation er ækvivalent med kildekoden, som den ser ud, når systemet sættes i produktion. Og selv med den perfekte kravspecifikation vil kravene til systemet ændre sig undervejs i udviklingsforløbet i takt med at man bliver klogere og som følge af at virkeligheden ændrer sig (ny lovgivning, nye teknologier etc.).
Bl.a. derfor er det offentlige er så småt begyndt at arbejde agilt, og her er der eksempler på, at samarbejdet fungerer fornuftigt og at budgetterne overholdes. Men vi hører sjældent om velfungerende projekter.
Hvis IT-firmaerne ikke kan håndtere disse "kæmpestore kravspecifikationer og fastprisaftaler" hvorfor hulen byder de så på opgaverne? Og nej, jeg er ikke sarkastisk - IT-firmaer må lære at fungere indenfor de rammer som bliver dem udstukket (lidt li'som resten af erhvervslivet må)! "Bygherre" kan være fuldstændig ligeglad med kildekoder og fanden og hans pumpestok - det er tilbudsgiveres problem. Hvis bygherre kunne lave systemet selv, var der jo ingen grund til at entrere med et dyrt IT-firma.
Er det bare mig, eller virker 6 års udviklingstid ikke som vildt lang tid?
Nu er jeg ikke arbejdsskadeekspert, men groft generaliseret er et sagsbehandlingssystem vel bare en database med en frontend. En sag oprettes/opdateres i frontenden og gemmes i databasen, og så noget statemekanisme til at tracke hvilken fase en given sag er i.
Bevares - der er sikkert flere ting i det, men 6 år?!?
Det er saa nemt at simplificere et stykke software til en database med en frontend (det er saadan ca. alle offentlige systemer).
Robert L. Glass angiver i denne artikel [http://www.eng.auburn.edu/~hendrix/comp6710/readings/Forgotten_Fundamentals_IEEE_Software_May_2001.pdf] nogle fakta omkring software engineering, der kan forklare hvorfor saadan en forsimpling ikke kan bruges. Under 'Requirements and design' naevner han foelgende:
RD1. One of the two most common causes of runaway projects is unstable requirements. (For the other, see ES1.)
RD2. When a project moves from requirements to design, the solution process’s complexity causes an explosion of “derived requirements.” The list of requirements for the design phase is often 50 times longer than the list of original requirements.
Han har samlet flere 'facts & fallacies' i en bog, som varmt kan anbefales, isaer for managere/projektledere, da den forklarer en del omkring software : http://www.amazon.com/Facts-Fallacies-Software-Engineering-Robert/dp/0321117425
Åhjo Jens, det er selvfølgelig stillet på spidsen, som jeg da også selv siger. Men for det første så burde man måske begynde at tilpasse processer til IT-ificering, istedet for at pakke et IT system rundt om bestående processer. Dernæst vil jeg stadig mene at 6 års udviklingstid for et system af den type er helt ude i hampen. Efter de 6 år er man jo kun nået frem til et så ringe produkt, at man nu overvejer at skrotte det helt. Hvor mange år skulle der så til for at færdiggøre det? 10?
Vi er jo næsten på niveau med den tid (dog ikke det budget..) det tog at udvikle Curosity, som jeg da alt andet lige ville mene er en væsentlig mere kompleks opgave.
Eller her nærmer vi os måske kernen i problemet: Det er nemmere at placere et autonomt køretøj på en anden planet, end at udvikle et sagsbehandlingssystem til en offentlig instans i Danmark.
Jeg synes ikke det er ok
Steen, jeg giver dig helt ret i den uhyrlige udviklingstid, jeg kommenterer bare paa den 'det kan da ikke vaere saa svaert'- og 'det er bare lige at goere saadan'-holdning, man tit stoeder paa hos os udviklere. Denne evigt optimistiske tilgang goer at tidsestimater oftest er best scenario (fantasi-scenario), og at vi derfor har et ret daarligt ry udi kunsten at estimere software.
Jeg er enig, Jens. Problemet her er jo med overvejende sandsynlighed ikke inkompetente udviklerere, men mangelfuld specificering og ikke mindst projektledelse.
Var det ikke en idé for en journalist, hint verson2.dk, at lave en opdateret udgave af http://www.version2.dk/artikel/her-er-de-11-dyreste-it-projekter-i-staten-43687
Måske endda lave en simplificeret tabel-udgave over projekterne med kolonner så som:
- Projekt ingangsættelse (Dato)
- Forventet leveringstid
- Faktisk leveringstid
- Forventet pris
- Faktisk pris
- Forventet besparelse
- Antal levernadørskift
- Levetid efter igangsættelse
Og lave udvælgelsen af projekter til listen som værende projekter der endte dyrere end x antal millioner. Lad listen omfatte både projekter der er gået godt, skidt og Amanda!
En sådan fakta liste må da være brænde til PHKs ITHK eller forhåbentlig en øjenåbner for nogle politiske ordførere om at der skal gøres noget.
Kan du prøve at finde ud af hvilke "fejl" som Deloitte påpeger som årsag til en skrotning? Eller er det kun hastighed?
Hvor mange offentlige IT projekter er efterhånden kuldsejlet...
Man kan efterhånden godt blive lidt træt af at betale så meget i skat når man hele tiden læser om hvor dårligt det offentlige behandler vores skattepenge.
Jeg tror Danmark ville have godt af en "oprydnings" statsminister... En som tog fat i råddenskaben som husere indenfor det offentlige.
Hvorfor hører man aldrig om et motorvejsprojekt som er kuldsejlet??? Hvad kan vi evt. lære af dem?
Jeg tror Danmark ville have godt af en "oprydnings" statsminister... En som tog fat i råddenskaben som husere indenfor det offentlige.
Ak ja, men hvor er 'hyn' - der ses ingen på borgen i nuværende regering, og selv hos oppositionen (den forriger regering) er der vist ikke en eneste med hår på brystet.
Embedsværket/maskineriet/Djøf'er foretrækker at fordrive tiden med at skrive eller ringe til hinanden (og bagefter fortæller, at det kunne de aldrig finde på..), så heller ikke der gror noget som helst med fremtid i.
Hvorfor hører man aldrig om et motorvejsprojekt som er kuldsejlet??? Hvad kan vi evt. lære af dem?
... vi kan lære at IT folk ved for lidt om forholdene udenfor IT branchen ;-)
En hurtig tur med google gav mig følgende:
I Danmark:
http://www.tv2fyn.dk/article/49406:Motorvejen-bliver-forsinket
http://dinby.dk/harlev-j./motorvej-ved-sabro-er-forsinket
I Udlandet:
http://bigstory.ap.org/article/icelands-hidden-elves-delay-road-projects
Hvis skjulte elvere begynder at blande sig i motorvejsbyggeriet, så bliver det svært. Eller misforstod jeg noget...?<a href="http://bigstory.ap.org/article/icelands-hidden-elves-delay-road-project…;
Skal vi lige mindes Fiskebækbroen? Det var da en motorvejsprojektkuldsejling, der kunne ses. Og i samme branche var der vist også noget metrobyggeri?
At sammenligne med motorvejsprojekter er en grov oversimplificering. Vi kan netop ikke lære noget af de store ingeniørprojekter, hvor målet er givet på forhånd og meget kan specificeres inden projektet starter. Motorveje kan ikke sættes i drift 10 meter ad gangen, men det kan it-systemer. Lav et godt rammeværk og lav fortløbende projekter, hvor funktionalitet sættes i drift lidt efter lidt og erfaringer drages ind konstant, kort sagt agil udvikling. Iøvrigt er motorvejsprojekter langt dyrere end it-systemer.
@Palle Due Larsen - jo netop motorveje kan tages i brug etapevis og sammenligningen med en motorvejsentreprise er ganske udmærket, men jeg genkender dine argumenter og derfor gentager jeg: IT-leverandører som ikke kan afgive tilbud efter tilbudsmateriale hvor funktion og afleveringsfrist ligger fast, skal ikke have mulighed for at byde på opgaverne. Betyder det så at ingen byder på opgaverne, må man bare vente indtil IT-firmaerne har nået en standard hvor de er kompetente. Når jeg læser dit indlæg kommer jeg til at tænke på Piet Hein: Vil du med rette have ry som lærd,. så tag det lette og gør det svært.
Som de offentlige IT-projekter kører nu, kan man jo blot som byder, byde alt for lavt og hente det hele ind på ekstraregninger.
At sammenligne med motorvejsprojekter er en grov oversimplificering. Vi kan netop ikke lære noget af de store ingeniørprojekter
Selvfølgelig er det en grov oversimplificering - men for hulen da. Man hører jo ikke om så grelle fejlskud i andre brancher som i den danske IT branche når det gælder det offentlige...
Det er jo pinligt - de leverandører som er inde i billedet må da også krumme tæer over deres egne "formåen"...
Det er jo pinligt - de leverandører som er inde i billedet må da også krumme tæer over deres egne "formåen"...
Nu har "det offentlige" snart været hele raden af leverandører rundt. I nogle tilfælde mere end een gang, og det går stadig galt.
Hvis det ikke er leverandørene, så må det altså være den offentlige sektor selv, der er helt utrolig dårlig til at være IT projekt kunde.
@Nikolaj Hansen - Meget, meget, dansk måde at tænke på; hvis ikke produktet er i orden, må det være kunden der er noget galt med.............
Meget, meget, dansk måde at tænke på; hvis ikke produktet er i orden, må det være kunden der er noget galt med.............
Faktisk er det ren logik.
Den eneste konstant har jo været "kunden".
You lost me...........du mener at kunden skal tilpasse sig produktet og ikke omvendt?
Ked af at logikken preller af Michael.
Når du eks. kører en test eller et forsøg, og du skal finde frem til årsagen til et resultat, så skærer du alt det væk, der ændrer sig, og kigger på det, der har været konstant.
Så finder du grunden til, at noget er fejlet.
Its elementary my dear Watson :-D
Ja, og en sten kan ikke flyve og mor Karen kan ikke flyve, altså er mor Karen en sten.............din argumentation er en gang forvrøvlet sofisme Nikolaj. Bundlinien er at danske IT-firmaer ikke kan levere den vare der efterspørges og det skal efterspørgeren saftsusemig ikke rette ind efter - det må være de danske IT-firmaer som er inkompetente
Og på den led kan DJØF'erne, konsulenterne osv. køre videre i samme spor. Det er total ansvars forflygtigelse. Business as usual.
Jeg er selvstændig IT konsulent, så fra et omsætnings perspektiv i min virksomhed, så klapper jeg ad din holdning. Dog vil jeg også gerne se min skatte kroner blive brugt fornuftigt.
Sålænge / hvis din holdning er den udbredte i den offentlige sektor, så vil man fortsætte med at se milliondyre kuldsejlede projekter.
Sektoren bliver nødt til at kigge indad, hvis det skal ende anderledes.
Hvad vil du ha' Nikolaj? Alternativet til en specificeret kontrakt er en blankocheck og det må vel være kunden som definerer sine egne behov og ikke IT-firmaerne. Som IT-firmaerne har ageret hidtil er det sidste man tør betro dem, frie hænder. Jeg har meget svært ved at få øje på ansvarsforflygtigelsen i min holdning, tvært i mod endda. Det rigtigste må da være at kunden beskriver sine behov og IT-firmaerne derefter skruer et produkt sammen som opfylder det behov, alt andet vil være galimatias. IT-firmaerne skal ikke bruge kundens penge til forsøg, de skal levere et færdigt produkt..........det er altså ikke raketvidenskab vi har med at gøre Nikolaj.
Det lyder så enkelt, og alligevel er det ganske ofte her den første (største) fejl sker. Så kan leverandøren være nok så dygtig.kunden som definerer sine egne behov
det er altså ikke raketvidenskab vi har med at gøre Nikolaj
Se der er vi så helt enige, hvis "raketvidenskab" gik galt lige så tit som offentlige projekter, så ville der rulle hoveder.
Jeg ved ikke hvad mere jeg kan sige, hvis du totalt afviser noget ansvar som kunde mellem kontrakten er specificeret og systemet skal tages i brug.
Andet end at konkludere, at det sikkert er her hunden er begravet.
Så lad os runde den af der. Dog vil jeg for en ordens skyld nævne at jeg ikke er offentligt ansat men selvstændig ingeniør/entreprenør i byggebranchen som også har lavet partnering-kontrakter (meget lig den type kontrakter du efterlyser) som har fungeret udmærket(-;
Nej, de griner hele vejen til banken. :-0Det er jo pinligt - de leverandører som er inde i billedet må da også krumme tæer over deres egne "formåen"...
Selvfølgelig er det en grov oversimplificering - men for hulen da.
Man hører jo ikke om så grelle fejlskud i andre brancher som i den danske IT branche når det gælder det offentlige.
Der er mange problemer, der er specifikke for at levere IT til det offentlige. Ingen tvivl om det, og der er ting, vi burde lære (burde HAVE lært!) om det og gjort noget ved.
Men, med det sagt, så går det nu heller ikke problemfrit i den private sektor. Et stykke hen ad vejen er forskellen, at vi i det private ofte har bedre muligheder for at skubbe skeletterne ind i skabet, når der ikke kræves offentlige aktstykker.....
Hermed ikke sagt, at der ikke er STORT rum for forbedring i det offentlige, men en del af det rum overlapper med det private.
Bo, der selv har været med at at gemme nogle ordentlige møgerter af skeletter i skabe i den private sektor. Det er der bare ingen, der har hørt om.....
Bo, der selv har været med at at gemme nogle ordentlige møgerter af skeletter i skabe i den private sektor. Det er der bare ingen, der har hørt om.....
Jeg har oplevet mange private IT projekter der var gået 300-400% over tidsplan og budget, men som stødt kørte videre mod et usikkert mål.
Nogle af de største "huller i luften" i dansk IT er private. Det offentlige har bare, qua at de er offentlige, en større forpligtigelse til at informere og færre muligheder for at skjule end det private.
Jeg kan på baggrund af mine egne erfaringer udpege to indikatorer for IT projekt fiasko:
- EU Udbud
- Projektledelse og styregrupper helt fri for IT kompetencer
Hvorfor EU Udbud stadigt er lovpligtigt er mig en gåde. Jeg har endnu tilgode at opleve et projekt der rent faktisk "fulgte eu reglerne" og kom i mål. Enten snor en erfaren ledelse sig udenom reglerne, og har så en vis chance for succes, eller også følger de reglerne og kører i hegnet.
Foretagender, offentlige såvel som private, bemander stadigt i stor stil IT projekters ledelse, og specielt det indledende projekt der fastlægger krav, budget, arbejdsmetode, valg af platform etc. med folk uden IT udviklings erfaring. De IT kompetente hyres først ind senere i processen, når alle de forkerte beslutninger ikke længere lader sig ændre.