POLSAG

Selvom det er irriterende, er der noget der tyder på at de svenske politikere eller i det mindste det svenske politi har forstået nogle af pointerne ovenfor:

http://www.version2.dk/blog/den-historie-v...

En eller anden med rette adgang: Hæng den tekst op på alle toiletdøre i folketinget.

Er der nogen her der kan komme i tanke om et offentligt IT projekt der er gået efter planen?

Listen af skandaler er uendelig og CSC har vist førertrøjen: http://www.version2.dk/artikel/her-er-cscs...

Kan det offentlige blive ved med at pumpe milliardbeløb ind i et firma der tilsyneladende ikke har kompetancen til at udføre opgaverne?

Eller er det virkelige problem at de der udbyder opgaverne ikke evner at formulere kravene.

Svarer de priser vi ser overhovedet til det udførte arbejde? POLSAG, 400 mil.

Det må efter min regnebog betyde at der er brugt mindst 400 mandår på projektet, er min beregning helt i skoven?

De 400 millioner er betalt til firmaer, som har specialiseret sig i at skrive specifikationer og fakturaer. Det værste der kunne ske for disse firmaer er at systemet kom til at virke, for det ville gøre mulighederne for at skrive fakturaer mindre. Nu skrottes systemet og så kan de samme firmaer byde på et nyt system. Da det jo nu er kendt at 400 millioner kroner er for lidt, vil der nok blive budgetteret med 800 millioner kroner og 12 år.........

Mit gæt for det projekt, som hedder [b]"Betalingsringen"[/b] er: - 1500 millioner - 3 år Hvad gætter I på?

PS: Der er ingen mulighed for gevinst. Alle danskere bliver tabere.

Er der nogen her der kan komme i tanke om et offentligt IT projekt der er gået efter planen?

Ja, f.eks. CVR systemet, men også mange andre. Men det er fiaskoerne som tiltrækker sig opmærksomhed.

Hvis man starter med en enorm kravspec er man godt på vej mod problemer. Lav systemerne så enkelt som muligt og inddrag slutbrugere. Og lave gerne prototyper som kan give brugerne "hands on" erfaringer.

The Mythical Man-Month som PH henviser til er ofte min godnat læsning, det er en klassiker.

Mvh. Peter

Nok snarere 100 mandår, da hele lortet vel er lavet af Super senior projektlederer og system arkitekter. :)

Og så har man vel også købt hardware for mange milioner, før man ved om systemet kommer til at virke. :)

Dankortet må være et eksempel på noget der er gået godt! Men måske er det ikke offentligt?

Når en offentlig institution benytter sig af en privat virksomhed, har man et helt grundlæggende uenighed i målet. Det er lidt firkantet sagt sådan, at kunden ikke har nogen grundlæggende interesse i økonomien men kun i produktet, mens leverandøren ingen interesse har i produktet, men kun i økonomien. Det giver en situation, hvor kunden ikke er bekymret over at blive snydt økonomisk, hvilket leverandøren næppe har noget problem med.

Et af de største problemer er efter min opfattelse, at man sætter tingene i udbud, hvor man vælger efter laveste pris. Det gør blandt andet kravspecifikation til en disciplin, hvor producent og kunde har en interesse i at læse det modsatte af, hvad den anden læser.

http://www.despair.com/consulting.html

Rigspolitichefen bør overflyttes til rejsekortet og IC4-projektet :-)

Stort set alle IT successer er startet af en eller to mand der ikke havde skrevet en kravspecifikation, men i stedet tilpassede forretningsmodellen til hvordan virkeligheden, markedet og IT systemet spillede sammen.

Stort set alle IT katastrofer har kravspecifikationer der fylder ringbind på ringbind på ringbind, der beskriver hvorledes IT systemet skal håndtere og videreføre historiske artifakter, manuelle shortcuts og procedurer der ikke længere tjener noget konstruktivt formål.

Dette er en alt for forsimplet opstilling. En kravspecifikation er et helt afgørende værktøj i udviklingen af et større IT system specielt når det udvikles udenfor den organisation hvor det skal anvendes. Selvfølgelig kan en kravspecifikation både misbruges og udformes så elendigt at den gør mere skade end gavn, men løsningen er altså ikke at overlade statens IT projekter til et par gymnasieelever i en garage.

Det ville være mere konstruktivt at diskutere hvad der udgør en god kravspecifikation.

http://www.despair.com/government.html

Der skal mere end een part til at fejle så grundigt som her...

Måden man laver IT der virker, er ved at finde nogle unge talenter og give dem lov til at forandre ens processer undervejs.

Kan ikke siges bedre, jer meget meget enig med PHK. Før du skyder på politikerne, så husk på at et projekt som polsag og lignende, starter med embedsmænd der mødes, og før eller siden sender sine vilde ideer ind i den politiske proces, hvor ingen rigtigt fostår hvad der foregår. En klog mand forklared mig engang, at forskellen på en cand polit og en cand polyt er, at den første kun er interesseret i processen, mens polytten også er interesseret i hvad der kommer ud af processen, og enda kan finde på at sende noget af det tilbage i processen. Den helt store åbenbaring er for tiden projektet som skal pakke hele staten (og kommuner) ind i et tykt lag IT leveret af store multinationele selskaber, og dermed holde armslængde princippet til en undrende magtesløs befolkning.

Jeg undrer mig virkeligt over at man kan lave en kontrakt med en virksomhed som tillader overskridelser af budget og tidsplan uden nogen former for sanktioner - kan det virkeligt passe?

Jeg vil ikke kaste mig i koret af folk der har nemme løsninger på disse problemer. Men, jeg mener at man tidligere har konkluderet at det er anskaffelsesprocessen der indeholder roden til al det onde. Leverancen af den type løsninger (som åbenbart altid skal være store udviklings-projekter), kræver en udbudsproces. I udbudsprocessen opstilles en myriade af krav. Leverandøren ved at udbuddet kun vindes hvis der svares positivt på kravene, og gerne også har en lav pris. Herefter går det ned ad bakke. Behovet ændrer sig uden at det er muligt at ændre tidsplan og krav, leverandøren begynder at have svært ved at leve op til kravene, økonomien begynder at blive stram, kontrakterne begynder at blive svære at få til at passe med hvad der reelt laves og er brug for, persongalleri udskiftes osv.osv. og det er den historik som aviserne nu kan få lov at boltre sig i de næste par år. Imens fosser pengene fortsat ud til jurister, konsulenter og andre der nu skal få hoved og hale i forløbet, vel vidende at det nok ender i et forlig. Lad og få en mere fleksibel anskaffelsesproces så disse projekter kan nedbrydes i meget mindre bidder og hvor disse realiseres med en meget korte tidshorisont og lad os komme videre....

Nogle IT projekter er gået godt (Kirkeministeriets digitale kirkebog) - hvorfor? hvad kan man lære af disse projekter?

løsningen er altså ikke at overlade statens IT projekter til et par gymnasieelever i en garage.

Nej, de kan sagtens starte før http://www.version2.dk/artikel/moed-fremti... :)

Men bortset fra det, så er vi da enige i at kravspecifikationer er et værktøj der ofte bliver anvendt forkert... personligt har jeg være med til at skrotte en hel del af slagsen fordi dem der har lavet (eller startet med at lave) den er hoppet direkte til specifikationen uden at overveje hvad målet var med "produktet"...

Så for at tage dit spørgsmål om en god kravspecifikation, så mener jeg den starter med at man gør sig klart hvilket overordnet mål der skal opfyldes. Derefter kan vi begynde at snakke om konkrete features, standarder og regler der skal opfyldes - og når det hele er defineret, så tager man lige et grundigt kig igen for at se om det nu også altsammen understøtter det overordnede mål... det er ikke noget der i sig selv giver en god kravspec, men det er i hvert fald væsentlige skridt på vejen...

Eller også starter man med at lave en prototype, som hvis men har lidt talent henter mindst 40% af fordelene for max 5% af omkostningen."

Men sådan vinder man ikke et udbud. Her får man en mappe med krav, og skal svare med en mappe indeholdende diverse forklaringer om, hvorfor man er den bedste leverandør, samt en pris, der er den udslagsgivende faktor.

Et offentligt udbud lægger op til en vandfaldsmodel med al det vanvid, den indebærer.

Frankrigs model.

Løsning: Så små projekter at der ikke er behov for udbud. (Spørg Frankrig om hvordan de gør.)

Dvs. at Staten er tovholder på sine mange små projekter, og samle dem (integrere) dem til noget større. Integrering kan sikkert også laves som et udbud under grænsen for EU udbud.

Det gode ved alt dette er at det kræver software der er testet til at virke, og har klart definerede APIs/protokoller for netværkskommunikation.

Ville det her være protektionisme? Ja, helt sikkert, men jeg har ikke moralske skrupler - staten fattes penge. Vi kan ikke blive ved at ødsle dem bort på den måde.

Hvis EU er utilfreds skal vi ikke rette ind, men fortælle dem at det er EUs udbudsregler der er problemet. IT udvikles ikke på samme måde som f.eks bygninger, broer, tunneler, veje etc

[b]Læs og forstå: Frederick P. Brooks "The Mythical Man-Month"[/b] Eksamen i at forstå den bogs indhold burde være bestået før man i staten kan deltage i et IT projekt.

Nogle IT projekter er gået godt (Kirkeministeriets digitale kirkebog) - hvorfor? hvad kan man lære af disse projekter?

Hvad kostede projektet? Hvad var værdien?

Men ikke der som sædvanlig ved offentlige IT-projekter blev betalt mindst 1000% for meget?

Jeg er som udganspunkt enig med dig. Men, har du dokumentation for din påstand om "velfungerende, større" it-systemer uden kravspecifikation?

Det er desværre en forkert antagelse. Der er ikke noget i udbudsdirektivet, der kræver en vandfaldsmodel. Der findes faktisk en del offentlige udbud, der er kørt agilt indenfor direktivets rammer, fx et nyt havnmanagementsystem til havneselskabet i Kiel. Eller Udenrigsministeriets extranet. Eller Arbejdsmarkedsstyrelsen: http://dit.dk/events/2012/02/08-agile-2012...

Det er desværre en forkert antagelse. Der er ikke noget i udbudsdirektivet, der kræver en vandfaldsmodel. Der findes faktisk en del offentlige udbud, der er kørt agilt indenfor direktivets rammer, fx et nyt havnmanagementsystem til havneselskabet i Kiel. Eller Udenrigsministeriets extranet. Eller Arbejdsmarkedsstyrelsen: http://dit.dk/events/2012/02/08-agile-2012...

Ja, du har ret - jeg antog at der var krav om en vandfaldsmodel.

Du skriver agilt. Er iterativ udvikling [b]også[/b] i orden i forhold til direktivet?

Det er nu meget unfair, fordi det er software som spiller i to forskellige klasser: et operativsystem (kravene til et operativsystem er velkendte, det får alle at vide i studiet) og - lidt polemisk sagt - bare en webserver (igen defineret i en række RFC, så skal der bare nogen ikke-funktionelle ting på plads). Brugerinvolvering i begge tilfælde er faktisk (bortest fra desktop og konfiguration) ikke-eksisterende; ligeledes indeholder begge ting ingen komplicerede forretningsprocesser eller øvrige integrationer. Og så ting som POLSAG: masser af interaktion med andre systemer, sagsbehandlere, potentiel 5 millioner borgere og en lovapparat, der skal - ufravielig og til 100% - overholdes. Eller EFI/Debitormotor: masser af integrationer til alle offentlige myndigheder, banker, virksomheder (til løniddrivelse) - og igen en lovapparat, der ufravielig skal overholdes. Hvis du kan finde et eksempel på et system i en lignende kompleksitetsklasse er jeg overbevist :-)

Vi taler her bare om den rigtige verden, ikke om at lave et lille program til at kunne aflæse computerkonfigurationer i et lokale (som der findes masser af i forvejen).

Du kan sagtens bruge en iterativ tilgang i offentlige projekter. Der er også nogen danske softwarehuse, som - uden at det kræves - byder ind med et agilt/iterativt forløb. Når man læser direktivet, så står softwareprojekter i sammen kategori som arkitektydelser. Så principielt må man godt køre et udbud med forhandling eller projektkonkurrencer på it-projekter. Jeg har igen et eksempel fra Tyskland, hvor de har kørt sådan et forløb til implementering af kontrolrumssoftware til digital politifunk.

Good points. Vi talte om det på arbejde - du siger at det næste der ryger er SKAT's IT pakke. Jeg proklamerede at det var EPJ ... men du har nok ret - EPJ kommer på lidt længere sigt (den er ikke færdig med at vokse sig stor endnu).

Jeg er uddannet plantepatolog og har arbejdet med SAS-programmering siden 1972. Først sygdomsmodeller på friland ud fra meteorologiske data, siden klimastyring i væksthuse. Det sidste var ligesom opgaven hos politiet, en programmør, der bliver mødt med "Kan det også lade sig gøre?" og "Hvad nu hvis?" Som skrevet højere i tråden: en fornuftig programmør, en positiv politistation og så lade dem sammen koge noget sammen. Brug standard udskrifter og tænkte data for at demonstrere, hvad man kan. SAS er dyrt, men let at bruge, og kapaciteten afhænger udelukkende af størrelsen på computeren. Hvis man bliver i SAS er det muligt senere at analysere data på en anden måde end den daglige rutine kræver, uden at det koster en herregård.

Og nej, jeg har ikke noget med SAS at gøre, men der blev efterlyst et program, der kan håndtere den rigtige verden.

Kære PHK

Forstå det næste jeg skriver i et positivt lys, for jeg har stor respekt for din viden, kunnen og evnen til at kort beskrive problemer ved komplekse sammenhænge....men...undskyld mig:

Du og og mange af ovenstående skribenter gør jer skyldige i samme fejltagelse som dem I beskylder.

Begrebet "Den magiske IT sovs" er det væsentligste bidrag her. For mange, inklusive dygtig IT personale gør sig skyldige i at hylde selvsamme sovs: en naiv tro på de hurtige og enkle løsninger. Glem det, det var i de gode gamle dage, hvor man hurtigt kunne imponere, ja man kunne endog score på den baggrund :-)

Nu om stunder skal man have en dyb indsigt i tilgængelige it komponenter sammenholde dem medi kundens ønskede virkemåde, være proaktiv og sørge for at udvikle agilt i små nye komponenter, samtidig med at man ækvilibristisk sætter det hele sammen i et simpelt system, der giver en besparelse der rækker langt ud over det system der skal erstattes.....som allerede har kostet 40 års udvikling med 20 mand....

Den sammenhæng kan du ikke blot smide to unge - uanset hvor dygtige de er - ud i, og så tro at de kan levere på 2 år. Jeg fristes næsten til at indgå et væddemål om det.

Derimod kræver den slags at man bemander med kyndige og dygtige folk på alle poster, lige fra den enkelte programmør over ledelsen og helt ud til indkøberen. Der skal være forretningsforståelse blandt alle, og de skal være indstillet på at levere en herre indsats, for IT, i komplekse sammenhænge, kræver at man at man er sit ansvar bevidst og ikke negligerer når eks. Patienter ikke får rettidig information.

Mit bud er, som altid, at man ikke har forstået - helt fra indkøberens side - at vælge de dygtige IT folk. Og alt for ofte ser man, at man som IT udbyder ikke kan rumme de rigtigt dygtige folk, fordi de ganske enkelt er besværlige at danse med.

Så jo: der skal kravspecifikation til, der skal analyseres sammen med kunden, der skal designes og laves prototyper, der skal udvikles + testes i små enheder, det skal være dygtige IT håndværkere og ikke mindst: de der køber systemet skal være dygtige til både eget fag og den teknologi man får leveret af it-leverandøren.

Det får du ikke to unge knægte på 14 til at levere - sorry.

Mvh. Peter j. Bruun

Man kan ikke lade være med at spørge til "bolden" nu hvor sensationen er kendt! Hvad er den faglige baggrund i dette projekt? - hvilket system bygger dette på? - er det en "tallerken" der er opfundet før? Lad os finde ud af, hvordan disse mega-fejl lader sig gentages i det uendelige mvh Bent

Hvis du kan finde et eksempel på et system i en lignende kompleksitetsklasse er jeg overbevist :-)

Jeg betvivler at sådanne systemer findes. Og hvis de gør, så fungerer de ikke korrekt, kravspecifikation eller ej. Hele problemet er netop den antagelse at du kan bygge et system op omkring eksisterende processer og arbejdsgange. Chancen for at du skal ændre på alle de ting der ikke er kode - den er voldsomt stor.

Derfor er Apache, FreeBSD, Linuxkernen, osv ret gode eksempler: De løser netop en veldefineret opgave med en begrænset snitflade. Alle de her skandaler skyldes bare for store systemer. De kan ikke implementeres.

Så jo: der skal kravspecifikation til, der skal analyseres sammen med kunden, der skal designes og laves prototyper, der skal udvikles + testes i små enheder, det skal være dygtige IT håndværkere og ikke mindst: de der køber systemet skal være dygtige til både eget fag og den teknologi man får leveret af it-leverandøren.

Jeg tror ikke du skal have en stor kravspecifikation. Med sådan en i hånden forsøger man at skabe og prioritere opgavens rammer længe inden man har nogen forståelse om hvorvidt rammerne er rigtige. Men erfaring og historik som udvikler er at de sjældent sætter rammerne rigtigt. Tværtimod.

Jeg tror i stedet du skal finde en minimal prototype du kan sætte i søen og se hvordan folk reagerer overfor den. Derfra plejer de næste delopgaver at give sig selv. Men som bemærket, så passer det ikke ind i udbudsrunder af den enorme størrelse vi her taler om.

Bemærk også at mindre virksomheder ikke kan byde på disse udbud, ligegyldigt hvor kompetente de er.

Det er overraskende at penneføreren i Ingeniøren tager dette ind i en politisk vinkel med henvisning til at kniven skal svinges. Man er "godtroende", hvis man forventer et velfungerende samfund, hvor færre producerer/bidrager og systemet stadig skal levere uden brug af blandt andet IT. Historien har vist at (for) store projekter ofte mister jordforbindelsen. I et lille land kan det ikke blive stort nok. Dette er ikke alene politikerne, men embedsmændene som indstiller løsningerne til polikerne. Sammen kører de efter at store enheder skal stå for store opgaver.

IT virksomheder, får mig tit til at tænke på hjælpeorganisationer.

• vi er ikke til for at løse problemer; men for at lindre smerten.

Problemløsning kan kun faktureres én gang.

Ændring af kravspecifikationer kan faktureres i det uendelige.

I særdeleshed har jeg meget svært ved at finde IT projektsuccess'er hvor kravspecifikationen er på over ca. 500 sider...

Den indledende kravsspecifikation til logistikdelen af den nye lufthavn i Doha startede med 980 sider, hvoraf mere end halvdelen havde at gøre med den IT-mæssige side. Mit firma vandt den ordre, og det sidste jeg har hørt, er at vi leverer før tid. Og det uden at skrive ekstraregninger for andet end det kunden har ombestemt sig om undervejs i projektforløbet.

Men hvis ret skal være ret, så er det også en fornuftig kravsspec, der går mere op i hvilke passagerflow systemet skal kunne håndtere, end i hvordan de enkelte skærmbilleder på operatørernes arbejdsstationer skal se ud.

Når man tegner kontrakt på et projekt formoder jeg at man ud over opgavebeskrivelse og pris, også har aftale om leveringstidspunkt?

Hvis det er tilfældet, må man vel også have en aftale om dagbøder for overskridelser, og sikkerhedsstillelse for det tilfælde at leverandøren af en eller anden grund ikke er i stand til at levere varen, eller tager jeg helt fejl?

Disse betragtninger er desværre noget sarkastiske, da vi jo tydeligt kan se at det ikke sker ved offentlige projekter. Det sker muligvis heller ikke i private, men der hører vi ikke så meget om fiaskoerne, ligesom vi ikke hører om de succeshistorier som forhåbentlig findes

Desværre kan alle leverandører se at der ikke er tilstrækkelige konsekvenser ved at sjofle offentlige opgaver.

Kan man ikke tegne kontrakter som ligner den der er anvendt ved Sønderborg motorvejen. Byggekonsortiet financierer byggeriet og får først betaling når vejen er færdig, desuden skal de vedligeholde vejen i, så vidt jeg husker, 15 år til fast pris. Den bliver færdig mere end et år før aftalt.

Altså: No cure, no pay.

[quote]En kravspecifikation er et helt afgørende værktøj i udviklingen af et større IT system [...]

Hvordan kan du dokumentere den påstand ?

Vil du også bede mig om at dokumentere at det var en god ide at tegne Storebæltsbroen før man gik i gang med at bygge den?

Jeg kender masser af velfungerende større IT systemer der ikke har en kravspecifikation og aldrig har haft det.

Formentlig fordi de er udviklet at brugere selv eller folk med så indgående kendskab til brugen at kravene har været indlysende for alle udviklere.

Jeg har derimod utrolig svært ved at finde velfungerende større IT systemer, der er bygget på basis af en kravspecifikation.

De sælger heller ikke aviser(!)

I særdeleshed har jeg meget svært ved at finde IT projektsuccess'er hvor kravspecifikationen er på over ca. 500 sider...

Vi kan hurtigt blive enige om at hvis den mest overordnede beskrivelse af et system fylder over 500 sider så er der nok tale om at man har misset et abstraktionslag eller to.

Så jeg vil meget gerne se din dokumentation, hvis du har nogen...

Det har jeg ikke. Der er tale om sund fornuft og desuden ligger det indenfor mit arbejdsområde (nej, jeg arbejder ikke for CSC). Hvis man skal have en ekstern organisation til at udføre et stykke arbejde er det nødvendigt at beskrive opgaven i detaljer for at sikre at man har en fælles forståelse. Det gælder ikke blot software.

Ser man på et system som Polsag er det et oplagt problem at man tilsyneladende ikke har sikret sig at leverandøren har en interesse i at systemet rent faktisk er anvendeligt og at man ikke har opdaget det før man havde købt for 400 Mkr. Har der ikke været prototyper eller delleverancer med brugertest og evalueringer? Forsøger man overhovedet hos det offentlige at udnytte tidligere erfaringer, f.eks. ved at have en slags IT-rejsehold som tilknyttes større projektudbud og sikrer mod de mest overordnede fejltagelser?

Der er masser af interessante spørgsmål i denne sag, men hvorvidt det er en god ide at skrive kravspecifikationer eller ej er ikke et af dem.

Storebæltsbroen er et utroligt simpelt projekt, sammenlignet med mange IT projekter, desuden har det den store fordel at det er et fysisk projekt, det er ret nemt at som der mangler noget eller ej.

De senste hangarskibe USA byggede bestod hver af 1 million forskellige dele, det svarer nogenlunde til antallet af kodelinier i en kompetent oversætter til computersproget 'C'.

Det er også nemt at afspore fysiske projekter. Storebæltsbroen er vel ligeså simpel som Hallandsås tunnellen (http://www.trafikverket.se/hallandsas) eller "Sagrada Família"?

Blev hangarskibet bygget af "en eller to mand der ikke havde skrevet en kravspecifikation"?

Problemet er, at den rigtie verden simpelthen ikke er simpel og velafgrænset - I modsætning til webservere eller Linuxkerner. Den tid hvor it kunne leve i et laboratorie og lave operativsystemer, netværksanalyseværktøjer, etc. er long time gone og kommer ikke tilbage. Nu skal der løses rigtige problemer. Hvis du fx tager POLSAG skal den være egnet til at sikre retfærdig for den tiltalte i en straffesag. Og det er størrelsesorden mere komplekst end FreeBSD. At man kunne have fundet en implementering som muligvis er mindre kompliceret er en anden sag ...

"Når man stiller den forkerte opgave, får man ikke en løsning man kan bruge. Hvis ikke man kan stille opgaven så den kan løses, bliver man nødt til at ændre randbetingelserne omkring opgaven."

Ja, ja, når realtiteten ikke passer mig, laver jeg om på realiteten. Det kan lade sig gøre med faktureringsprocesser. Men sådan er det tit ikke, og slet ikke med noget som POLSAG. Der er bare nogle ting i de bagvedliggende specifikationer som "Retsplejeloven", som ikke står til diskussion, fordi det er grundlæggende principper i vores samfund.

P.S.: Som om Apache-projektet ikke kører en benhård feature-management-proces ... Det er Requirements Management at its best ...

Nu er der projekter nok, hvor lige præcis arkitekten er problemet, fordi han anser arkitekturen som ideologi uden tænke på forretningen. Jeg er enig med Peter Bruun: hvis projekter i den omtalte kompleksitetsorden skal lykkes, kræves det mennesker, som er dygtigte til både fagsiden og it-teknik samt en iterativ udviklingsproces.

Til listen med mirakler med IT og netværk vil jeg bare personligt tilføje rejseplanen.dk der altid har imponeret mig. Mener jeg læste en gang, at det bliver lavet af en delvist DSB-uafhængig organisation, hvilket nok forklarer meget, for DSB er ellers en rimelig katastrofal organisation IT mæssigt.

Som daglig bruger af politiets mange it-systemer kan jeg bekræfte mange af problematikkerne.

Der er således en masse it-systemer, som er udviklet efter aller bedste mening. Hvert system er også behørigt bygget op med langsommelig opstart og brug af diverse koder, indbyggede shutdown osv.

Til gengæld er der sjælden interaktion, så man kan få lov at skrive de samme oplysninger flere gange frem for elektronisk overførsel(ironi kan forekomme)

Disse mange forskellige systemer stiller også krav til brugerne, idet de skal uddannes til bruger af systemerne, hvoraf mange ikke lige anvendes hver dag. Rutinerne forsvinder således og systemerne anvendes i mindre grad end tilsigtet.

Hvis brugerne har ytret sin frustration medfører det ofte en længere redegørelse for det enkelte system, og et par konstruktve forsøg "overgiver" brugeren sig til den virkelige og ineffektive it-hverdag.

Og i politiets tilfælde tror jeg, at der var brug for eksterne konsulenter, der med åbent sind scannede systemerne og kom med et bud efter KISS-modellen.

Jeg har ikke selv fornøden it-viden, men som bruger er der utvivlsomt et stort behov for at nye øjne ser på de samlede it-systemer og ikke kun POLSAG.

Derfor synes jeg at IDA kunne byde ind med et panel, bla. bestående af PHK.

Storebæltsbroen er et utroligt simpelt projekt, sammenlignet med mange IT projekter, desuden har det den store fordel at det er et fysisk projekt, det er ret nemt at som der mangler noget eller ej.

Har du noget dokumentation for det for det må jeg ærligt sige jeg oprigtig tvivler på...

Det er også nemt at se om en del mangler i et IT projekt (den del er der ikke, hvis man fx ikke kan skrive bøder ud fra politibilens printer)... Det er ikke den helt så interessante del af ligningen, det der er rigtigt svært er om de dele man kan se er der gør deres job ordenligt. Fx. ved man med storebæltsbroen at en af pylonerne under støbningen (udført af en fransk undeleverandør) ikke vejrsikrede støbningen ordenligt så man har forudset at den pylon vil skulle serviceres ca 20 år tidligere pga den fejl... Hvilke konstruktionsfejl kender man ikke til ?

Ja der er mange flere muligheder for at skjule fejl i kode fordi det er meget nemmere at lave makværk men mange gange iløbet af de sidste 50 år har menneskeliv gået tabt fordi en kritisk del af en relativ simpel konstruktion ikke har levet op til den krav specifikation der var for den del...

Det der rent faktisk er problemet er at det offentlige IKKE har folk med kompetancen til at kunne skrive en solid krav specifikation til software, der faktisk definere de dele af systemet der er kritiske for at det kan fungere og ikke er omkostningstungt at opdatere.

Desuden er dit eksempel med de industri titaner som startede som et to mands team og nu har en omsætning på et en god bunke miliarder er lige så forfejlet. Ja de er store nu men modsat de leverandøre (som CSC) som fejler i deres leverancer til staten har deres udviklingshold ALTID været interne ved de kritiske features og det gør alt forskel i verden. De har desuden kunne starte små og vokse sig større siden og ta sig af de kompleksiteter der opstår når det sker når de har en kundebase der kan financiere de omkostninger. Der er en direkte kobling mellem hvor godt du gør dit job og hvor mange penge du får.

At være mindre end sandfærdig overfor en kunde/overordnet har desuden forskellige konsekvenser og dermed ændres encitamentet.

Hvis du er usandfærdig internt i en virksomhed angående et kritiske del af et kritisk projekt så går det ikke godt for din virksomhed og du får en fyresedel.

Hvis du er mindre end sandfærdig overfor en kunde som virksomheden som resultat af at din usandfærdighed får en 400.000.000 kr. kontrakt så får du en forfremmelse.

Det der er helt fucked med det offentlige er at de ikke har kompetancen til at lave en god produktbeskrivelse der indeholder proaktive tests og løbende driftstest med tolerancemål der sikre at slutproduktet virker ... Det burde de gøre noget ved.

Et rejsehold med dig i spidsen ville måske være en god start, men som du selv indrømmer så ville du skulle være med til at skrive en specifikation der er længere end 10 sider, fordi det er det der skal til når de overaskende komplekse problemstillinger og lokale arbejdsgangs tilpasningskrav man løber ind i når det problem man skal løse er resultatet af offentlig forvaltning og et par hundrede års lovgivning...

NB! Amerikanske hangarskibe er måske designet af 2 personer, men der er en veritable hær af ingeniøre der har været med til at lave kravspecifikationerne der faktisk får dem til at flyde ellers må du meget gerne dokumentere den påstand du kommer med der.

Du må desuden gerne inkludere designet og kravspecifikationerne på softwaren som køre deres command and control centre, samt softwaren som styre de Phalanx CIWS anti anti-ship missile system som stort set ikke har menneskehånd i stystemet længere (da vi som art er for langsome til at reagere hvis der kom et supersonisk anti-ship missile ind over horisonten).

Det kan være man i højere skal gå over til at evaluere dem der skal udføre en opgave mht. hvor godt de fagligt er klædt på til det.

Skal man have løst en softwareudviklingsopgave forlanges fra alle der deltager i projektet en kopi af:

• Eksamensbeviser, certifikater
• CV

De faglige kvalifikationer kan let vurderes på denne måde. Selvlærte færdigheder kan dog ikke ses.

Det er sværere at undersøge de personlige kvalifikationer.

Når man har en oversigt over projektdeltagernes kvalifikationer kan man også finde frem til hvilke projektdeltagere der behøver opkvalificering.

POLSAG og andre IT-skandaler...

Er der nogle der har undersøgt om dem der skulle løse opgaverne har det faglige niveau der skal til. Tjekket eksamensbeviser og CV. Høj anciennitet indenfor et fag er ikke ensbetydende med at have de rigtige kvalifikationer til opgaverne.

Sammenligner man to softwareudviklere: softi 1 og softi 2.

Softi 1 har arbejdet i 10 år med softwareudvikling på jobbet. Softi 1 brænder for sit fag og bruger meget af fritiden på at læse IT og softwaretidsskrifter, rode med PC og servere, kode til hobbyprojekter, osv. Softi 1 har også erhvervet sig nogle IT-certificeringer.

Softi 2 har arbejdet i 10 år med softwareudvikling på jobbet. Softi 2 undgår helst arbejdsopgaver på jobbet hvor der skal læres noget fagligt nyt. Softi 2 bruger fritiden på alt mulig andet end sit fagområde: fodbold, badminton, løb, madlavning, ølsmagning, whiskysmagning, osv.

Softy 1 og softy 2 har begge to 10 års erfaring. Mange vil vurdere softy 1 til at være fagligt dygtigere end softy 2.

Softy 1's kvalifikationer: eksamensbevis (datalog)+ certifikater + selvlærte færdigheder (ikke dokumenterbare)

Softy 2's kvalifikationer: eksamensbevis (datalog)

Der er vist brug for mere kontrol med de faglige kvalifikationer for at højne kvaliteten og minimere fiasko projekter:

Jeg kan lave murerarbejde! Kan du bevise din viden om murerarbejde med et ægte svendebrev ?

Jeg kan lave brystoperationer! Kan du bevise din faglige viden om brystoperationer med ægte eksamensbeviser ?

Jeg kan lave software! Kan du bevise din faglige viden om software med ægte eksamensbeviser ?

Jeg er en dygtig læge! Kan du fremlægge et ægte eksamensbevis der dokumenterer det ?

Jeg er god til at få arbejdsløse i job! Kan du fremlægge nogle ægte eksamensbeviser der beviser hvilke faggrupper du har forstand på ?

IT branchen sylter ofte efteruddannelse pga. tidspres og deadlines der overskrides gang på gang.

Der er brug for en fast del af arbejdstiden til efteruddannelse for at holde det faglige niveau tidssvarende for alle Danmarks IT folk. Uddannelse med eksamen og bevis som dokumentation.

Anciennitetsløn motiverer ikke til at have tidssvarende faglige kvalifikationer.

Rejseplanen bygger jo også på HAFAS fra HaCon. Et tysk firma, der i mange, mange år har leveret rejseplanlægning og billetsystemet til Deutsche Bahn ;-)

Kære Thomas, Jeg har arbejdet sammen med Rigspolitiets it-afdeling og der arbejder en masse dygtige folk, der gør lige præcis det, du efterspørger. Nogle gange tager tingene bare tid - RP har en del ældre systemer, særlige sikkerhedskrav (det er derfor du har al de login og automatisk nedlukning), skarpe databeskyttelsesregler, så kommer der altid nye ting, der skal opprioriteres, fordi der er en ny lov, der skal systemunderstøttes, osv., osv., de systemer, der skal moderniseres (fx Kriminalregisteret) kan du ikke bare nedlukke, så skal RP spare en masse penge ... Det er alle sammen forhold, der gør en systemmodernisering ikke nødvendigvis nemmere ...

// Dygtighedsløn // Arbejdstid: 75% opgavetid + 25% uddannelsestid

if (uddannelse == 1) { løn = løn * (DagligOpgaverPerformance + UddannelseEksamensResultater) } else { // Ingen efteruddannelse. Stillestående arbejdskraft motiveres til læring løn = løn * 0,9 }

Det lyder som om der her på tråden er udbredt enighed om at store kravspecifikations-udbud er dømt til at mislykkes, men på den anden side er der en masse jura omkring udbud som skal opfyldes ved større offentlige investeringer. Kunne man gøre som det amerikanske forsvar når der skal udvikles f.eks. nye jagerfly, betales der for udvikling af FLERE prototyper. Først når prototyperne er testet vælges vinderen af ordren.

Kan man ikke udbyde et IT system ved først at udbyde prototyper af systemet, mindst to, så virksomhederne kan konkurere om levering af den bedste prototype ? Prototyperne kan så dels gøre valget mere sikkert, OG betyde kvalificerede forslag til ændring af arbejdsgange ...

Tysk firma, ikke hollandsk: www.hacon.de :-)

Kære Markus

Jeg har stor forståelse for dine oplysninger, og jeg har absolut ingen dårlige erfaringer med RP.

MEN, der er vist åbenlyst, at der er brug for nye øjne på RPs it-drift.

Det er en kendt metode at lade nye øjne falde på sin organisation, og efter denne her POLSAG-skandale behøver man ikke frygte noget værre.

Det er ihvertfald utroligt trist, hvis politiet efterlades som de eneste, der eksempelvis ikke kan levere elektronisk dokumentation i administrationen. Jeg håber, at vi kan blive enige om at en fortsættelse af det nuværende med telefax og tjenestekuverter må ophøre snarest.

@Thomas Stidsen

Det lyder som om der her på tråden er udbredt enighed om at store kravspecifikations-udbud er dømt til at mislykkes, men på den anden side er der en masse jura omkring udbud som skal opfyldes ved større offentlige investeringer. Kunne man gøre som det amerikanske forsvar når der skal udvikles f.eks. nye jagerfly, betales der for udvikling af FLERE prototyper. Først når prototyperne er testet vælges vinderen af ordren.

Kan man ikke udbyde et IT system ved først at udbyde prototyper af systemet, mindst to, så virksomhederne kan konkurere om levering af den bedste prototype ? Prototyperne kan så dels gøre valget mere sikkert, OG betyde kvalificerede forslag til ændring af arbejdsgange ...

Jeg tror ikke det et realistisk at bruge den model i Danmark. Jeg har hørt om få eksempler hvor man rent faktisk kompenserer leverandøren bare for sin fortolkning af kravene, som er en ret dyr affære hvis han ikke vinder ordren. Jeg er dog enig med dig, at det ville være en bedre måde at hedge mod dårlige leverancer og at det ville øge incitamentet for at levere øjensynlig kvalitet. Det betyder også at man skal betale N gange mere for N leverandørers bud på en prototype, end hvis man havde valgt en enkelt. Eller noget med at leverandørerne skal levere endnu mere for en 1/N af den reelle pris. Hvad tænker du om det?

@Alsel Borup Jensen

Hvis det er tilfældet, må man vel også have en aftale om dagbøder for overskridelser, og sikkerhedsstillelse for det tilfælde at leverandøren af en eller anden grund ikke er i stand til at levere varen, eller tager jeg helt fejl?

Så påtager softwareudvikleren sig en kæmpe risiko, og risiko koster. Nok er der skruebrækkere derude, men fælles for dem alle er, at de er grådige; ikke dumme. Jeg tror ikke nogen prækvalificeret leverandør ville røre den form for risiko med en ildtang :)

@ Markus Hens & Poul-Henning Kamp Rejseplanen var tidligere baseret på en søgealgoritme fra et Hollandsk firma, men det er rigtig lang tid siden, det var dengang Rejseplanen var et DSB projekt.

Senere kom de andre trafikselskaber til og man oprettede et nyt selskab (Rejseplanen A/S). Der blev skiftet til tyske HaCon, der er førende inden for rejseplanlægning.

Rejseplanen er derfor ikke et typisk system udviklet i det offentlige danske regi, men må ses som et fælles europæisk projekt, til passet de regionale behov. Men udviklet af HaCon, et super professionelt tysk softwarefirma. Måske derfor er der succes.

Sysadm, Rejseplanen.

...dem selv Frue, og Deres købmand."

PHK kritiske blik falder på Staten som en ringe kunde: manglende evne til at tænke ud-af-boksen, og rigeligt med juridisk overforsigtighed. Og Dorte Toft: "Hvor mange leverandører er det foreløbigt, at SKAT har fyret?"

Men os som står på den anden side af disken, parate til at ekspedere kunden: Hvad kan vi tilbyde? Agile metoder nævnes i debatten. Det er et (for) nemt svar. Store systemer til en statslig administration må udtænkes i sin helhed - det nytter ikke at starte i et hjørne og levere dette først. Først efter at et godt design er lagt, kan man agilt udfylde detaljerne.

Kan den gængse metodekasse i branchen i dag lave gode designs? Vel, åbenbart ikke, hvis den bedrøvelige virkelighed skal være altings mål. Vi tænker i objektorientering og use-cases og funktionelle enkeltkrav, vi stykker helheden sammen af detaljerne. Det er en metodekasse vi har til fælles med kunderne - den er udbredt fordi den er nem at forstå. Og ingen ønsker uforståelighed. Det er ikke vandfaldsmetoden jeg her kritiserer: vi er her ovenover vandfaldet, heropppe hvor det overordnede design fastlægges - med samt alle detaljerne - og i manglende feed-back fra den efterfølgende udviklingsproces. Det er forkert at fastlægge detaljerne heroppe, men det mest overordnede design skal nødvendigvis fastlægges. Gerne i nogle iterative forløb, men det skal ske inden detaljerne fylder billedet ud.

Så: At edb-systemet ikke virker, eller at kaffen bliver udrikkelig, skyldes vel både kunder og leverandører. Og også og ikke mindst: At de to parter er blevet enige om en virkelighedsforståelse som er bekvem, men måske ikke leder så meget videre, som måske ikke er så progressiv. "Filosofferne har kun fortolket verden forskelligt, men hvad det kommer an på er at forandre den". Vise ord fra Karl Marx. Hvis vi - som edb-folk - vil gøre verden bedre end den er, er det ikke nok at beskrive detaljerne, vi skal have styr på et overordnet design. Det sprog vi bruger, skal katalysere en forandringsproces, for at sige det i bussiness sprog. Datanalyse (som ikke er 'moderne' for tiden) er i den forbindelse et stærkt værktøj, fordi det søger at skabe de datamæssige begreber (både detaljer og større helheder) som konstituerer det sprog som kan beskrive den nye løsning. (Dataanalyse er ikke moderne: Dataanalyse er i use-case metoden nedtonet som et afledet produkt af en use-case analyse, ikke som en analyse i sig selv. Og objektorienteret design går netop ud på at skjule data, at gøre dem sekundære i forhold til metoder).

Nu skal det her ikke lede frem til en salgstale for metode XY, den eneste sande og egentlige metode til at lave edb-systemer. Blot en konstatering af at vi har et problem - ud over at problemet med at vores kunder er nogle idioter. Vi lykkes for sjældent med design af vore edb-systemer, og manglen på overblik gør at systemerne sander til i svartidsproblemer, overbelastningsproblemer, og problemer med datakonstinens, fordi der ikke ligger et samlet datadesign bagved. Vi er måske også for dårlige håndværkere når der skal fyldes detaljer ud. Også her er det præget af fælles og bekvem forståelse mellem kunden og leverandøren: man laver da edb-systemer ved at finde komponenter oppe på komponenthylden (eller nede i Indien), og så blot koble dem sammen. Det med at programmere i detaljen, det var da i gamle dage. Et synspunkt som ofte i praksis viser sig at være i forbavsende og i overvældende grad forkert, ihverfald når der laves systemer til Staten og andre vanskelige kunder.

Det smarte ved den menneskelige intelligens skulle ellers være at man lærer af sine erfaringer og løser de foreliggende problemer, og griber opgaven langt bedre an næste gang. Det lykkes ind i mellem: Mærsks containerstyring, Rejseplanen. Men for sjældent.

Man kan i øvrigt også spørge: Hvor mange leverandører er det foreløbigt, at TDC har fyret? Svaret er: Nogenlunde lige så mange som SKAT. Det her debaterede syndron er ikke begrænset til Staten.

PS: Citatet i overskriften stammer fra en reklamekampagne for 'den frie købmand' tilbage i 1960'erne. Både han og Fruen er for længst bortgået, det eneste der fortsat eksisterer er kaffen.

Første egentlige release skal høste 80% af fordelene for max 20% af omkostningen og derefter skal man gøre det helt klart for dem der skal betale at nu er vi nået til de dyre features som det muligvis slet ikke kan betale sig at lave...

Og det eneste der er værre end en stor kravspecifikation er en enhver kravspecifikation, uanset størrelse, der ikke er baseret på en prototype.

Det er præcis filosofien bag de vellykkede projekter jeg har har været en del af, men prøv at forklare den model til kandidaterne i litteraturhistorie, cand.jurerne m.fl. i fedtlaget mellem de der ved hvad de har med at gøre og det toplag som kun nødtvungent træffer beslutninger og aldrig uden at have rygdækning fra udbudsjuristerne, it-rådet eller nogen af de andre overflødige artefakter skabt af den centralistiske nulfejlskultur.

Sat på spidsen kan end ikke du få en beslutning igennem de niveauer der skal til hvis det eksempelvis drejer sig om 50+ mio. uanset hvor meget ret du har, hvis du ikke bygger grundlaget op efter den forkerte model de spejlblanke generalister tror de forstår og derfor mener er rigtig: Megaudbudsmaterialer baseret på uendelige analyser af eksisterende og forventede arbejdsgange og med en kravspec ingen nogensinde kan få overblik over.

I mellemtiden vil jeg glæde mig til at nogen får nedbrudt udbudssystemet og at dine pointer vinder indpas på alle niveauer. Min tålmodighed er dog ved at være brugt op med umodenheden på kundesiden (og dem som tror at det alene er leverandørerne der er dårlige) og optimismen er næsten væk...

Jeg er naturligvis enig med PHK i at kunden må skærpe sig, 9000 siders oplæg skaber ikke edb-systemer, højst kaos. Hvis debatten - og mængden af kuldsejlede edb-projekter - kunne medvirke til at Staten indser det, så er vi nået langt.

Men: Der er fejl på begge sider. Fruen og 'den frie købmand' bidrog ikke meget til at forbedre smagen af kaffen - der var mest tale om et ressource-krævende nul-sums spil hvor fruen spillede fin frue og købmanden spillede servil diskenspringer. Man har efterfølgende indset at det er andre parametre der skal skrues på hvis vi skal have en ordentlig kop kaffe til en fornuftig pris. Der kører åbenbart også en del nul-sums spil hvis vi kigger på edb-branchen og de statslige kunder.

Et hovedproblem (for leverandøren, ikke for kunden) er at et edb-system er mere end summen af delene. Der ligger et overordnet design bagved, der er en overordnet struktur i løsningen. Det skal være muligt at meningsfuldt beskrive systemets overordnede opbygning. Ikke bare slagords-præget, men en beskrivelse af et reelt skelet som alle detajlerne efterfølgende er hængt op på. Det er godt håndværk, når det lykkes. Som jeg forstår SAP (og andre ERP-løsninger) så bygger succes'en her på at man en gang for alle fik lagt et design som egnede sig til at bygge et lagerstyringssystem. Fint nok, men det siger intet om vore muligheder for at finde det rigtige design i et system til det danske politi. Man kan sige (med fare for virkeligt at få ørerne makuleret i debat-maskinen) at strukturen i det edb-system politiet har haft hiditil nok udgør et fornuftigt first-cut i en analyse af hvordan en sådan struktur skal være.

Og: Detaljerne: Der skal ikke være 9000 siders beskrivelse fra kunden, men systemet skal jo altså implementere de regler der er, eller ihvertfald de fleste af dem. Politi-arbejde er præget af jura. Det ligger i sagens natur: hvis jeg bliver arresteret, så skal det altså håndteres korrekt, det er ikke nok at tænke i lagerstyring og fængselskapacitet. Jævnfør: http://www.version2.dk/artikel/politiets-b... hvor en leverandør af standardsystemer (SAS) siger at det slet ikke er nemt at lave politi-systemer. Det tror jeg på.

En del af diskussionen ovenfor forekommer mig absurd. Bortset fra at PHK åbenbart har det med kravspecifikationer som en vis bondemand havde det med degne kan jeg ikke forestille mig at det offentlige tegner store kontrakter uden at have en aftale om hvad et er man skal have / levere og hvordan det skal fungere. Kald det gerne noget andet end kravspecifikationer hvis det får det til at glide lettere ned. Men et par af indlæggene forsvandt i trængslen, så jeg tager det op igen. Kan det virkelig passe at udbyderen (det offentlige) er så uprofessionel at aftalen ikke indeholder noget om projektansvar? Gerne i form af no cure no pay. Det kan da ikke være rigtigt at en stor det af den fulde pris 400 MKr ikke skal tilbagebetales når leverancen ikke dur. Det giver os godt nok ikke et system der dur, men man er da ikke helt til grin. Og så kan man jo gå igang på en frisk, gerne med PHK som projektleder på et system, som for 10 MKr kan levere det på 2 år. Det vil man jo så have pengene til.

Kan det virkelig passe at udbyderen (det offentlige) er så uprofessionel at aftalen ikke indeholder noget om projektansvar?

[b]Ja[/b]

Der står måske nok noget i den oprindelige aftale om projektansvar, men leverandøren har jo nok brugt en væsentlig del af sine ressourcer i projektet på at sabotere den mulighed. De har stort talent for den slags og sabotagekompetencerne virker på både "store systemer" og "mindre systemer med interfaces".

Sammenholdt med at ingen er ansvarlig for noget som helst kan den slags projekter næsten kun ende på en måde.

Kun hvis der er en ildsjæl med god tid, som vil bruge sit liv på at søge aktindsigt i POLSAG kommer dette for dagens lys. Ellers bliver sagen blot begravet og regningen betalt af skatteyderne. Hverken leverandøren eller det offentlige har interesse i at komme til bunds i skandalen.

Har du noget dokumentation for det for det må jeg ærligt sige jeg oprigtig tvivler på...

Det afgørende er at det at bygge broer har en masse dele der er velkendte. Vi har bygget broer i omkring 2200 år nu uden problemer. De er blevet langt mere raffinerede og langt mere komplekse, men grundideerne er forholdsvist velkendte og det er fysikken bag dem også.

Vi har lavet software i omkring 50-60 år. Store dele af softwarekonstruktion er ikke velkendte og der er ikke nogen statistisk model der kan vise at "metode X skaber gode produkter og løsninger til tiden".

Dertil kommer at alle softwareprojekter, stort set, er højrisikoprojekter hvor du end ikke aner hvad formålet med dem er. Den første ide er så at styre dem med hård hånd fra toppen af: Kravspec! Men faktum er nok at de er så komplekse at du skal have gang i mindre delkomponenter og prototyper.

Det at skrive kode er design. Produktionen er at fyre løs med copy-paste når først designet er på plads. Og det er nemt og koster stort set 0 kr. Og derfor skal udformningen af kravspec naturligvis have en portion der handler om at skrive programmel. Og dem der laver dem skal have absolut indgående viden om at programmere.

Er der en god forklaring paa, at man ikke aftaler at betalingen først falder, naar skidtet virker?

Er der en god forklaring paa, at man ikke aftaler at betalingen først falder, naar skidtet virker?

• Leverandøren er smartere end kunden.
• Kunden har adgang til cirka ubegrænsede midler fra statskassen.
• Ingen er ansvarlige for noget.

Er der en god forklaring på, at man ikke aftaler at betalingen først falder, når skidtet virker?

Ja, der er simpelthen ikke råd til at udvikle noget så komplekst, der også koster leverandøren 100-vis af mandeår uden at få penge for det. Ingen leverandører ville løbe den risiko. Derfor skal vi heller ikke forvente, at staten får hovedparten af de 400 millioner tilbage fra CSC.

Jeg har tænkt en del over dette spørgsmål.

Jeg er nået frem til at kravsspecifikationen er en del af argumentationen for at der mangler et givet system eller afløser for et givet system.

dvs at dokumentes størrelse og form skyldes behovet hos dem der skal beslutte at bevilge pengene.

HVIS denne hypotese er korrekt, så er det virkelige problem, at dokumentet i uændret skikkelse sendes til dem der skal skabe det virkelige system

Hvis en man ikke kan sætte sig i sin godstol og læse & forstå kravspecifikationen på en weekend, er projektet forkert specificeret.

Eller også gaber det over et for stort problem, og burde brydes ned i etaper/uafhængige projekter.

Men der er mange andre faldgruber: Mangel på kvalificerede udviklere, og/eller viljen til at betale det de koster, eklatant mangel på kontakt/forståelse mellem kunde og projektleder/product owner, uvilje til at ændre på specifikationen undervejs (uanset hensigtsmæssigheden).

I modsætning til anlægsprojekter, hvor man (typisk) ikke afleverer projektet, et brofag ad gangen, kan man i IT-projekter typisk godt release i små bidder, der fungerer godt. Dermed bliver der også bedre tid til test og fejlretning.

Forhåbentlig kommer udbuds-DJØFerne snart frem til den erkendelse.

Er der en god forklaring paa, at man ikke aftaler at betalingen først falder, naar skidtet virker?

Nu er det jo uendeligt svært at definere om "skidtet virker" for vi bruger jo alle defekt software hver eneste dag når vi tænder vores windows-pc.

Og alligevel betragter leverandøren det som et perfekt færdigtudviklet system så længe flertallet af brugere trods alt ikke flygter til konkurrenten. Fra et rent økonomisk synspunkt har leverandøren ret, men skarpt defineret hvornår "skidtet virker" er det næppe.

Og sørme om ikke denne leverandør også konsekvent bruger undskyldningen om at systemet er "for komplekst" til at overskue ordentligt.

Jeg synes vi snakker om flere forskellige ting uden at gøre os det klart.

Udfra diverse artikler i pressen har jeg fået den opfattelse at man har skrottet POLSAG, fordi det i drift har vældigt lange svartider og fordi man undervejs i et langt testforløb ved Bornholms politikreds ikke har fået rettet fejl, der af og til giver datatab. Og at man derfor har mistet tilliden til at leverandøren nogensinde får fikset systemet, så det kan holde til daglig brug.

Dvs det ser ikke specielt ud til at være en fejl i kravspefikationen, men måske "bare" i den håndværksmæssige udførelse?

Er der nogen her der kan komme i tanke om et offentligt IT projekt der er gået efter planen?

Ja der er der ;-)

Til projektet "Implementering af Navision Stat" blev jeg hyret ind da det var gået fuldstændig i kage.

Nu skal jeg ikke sidde og blære mig, men jeg fik rettet det op, så det endte med at vi blev færdig 1½ år før tid, og dermed sparede 6-9 mio.

Projektstørrelse var vist 110 mio.

Det gav mig meget indsigt i staten, især da projektet indbefattede besøg hos ca. 200 IT afdelinger/regnskabschefer.

Jeg har også været involveret i nogle udbud, herunder FESD, og det jeg har set er:

Kravspec er typisk i 'punktform', og beskriver ikke forretningsgangen.

Det betyder at leverandørerne faktisk ikke aner hvad systemet skal bruges til (i det virkelige liv), da de ikke har kendskab til de interne forretningsgange.

Under de forhold er det jo klart at sandsynligheden for fejl/fiasko er langt langt større end sandsynligheden for succes.

Når de laver kravspec er det ikke IT folk der har været indblandet, men nærmest sådan en slags 'kaffeklub', hvor den ene siger vi skal huske det osv.

Så miseren starter allerede ved foranalyse(detailanalyse) og kravspec.

Det er fint man hyrer eksterne konsulenter, men disse forstår ikke det 'offentlige sprog'.

Jeg husker i FESD projektet, at vi - selvom det var fælles - ikke kunne holde møder hvor der var både amt og kommune repræsenteret.

De kunne simpelthen ikke sammen.

Inden for staten ekstistere der også 'konkurrence', hvilket man også skal være opmærksom på.

Håber det bedste for staten, men de projekter gjorde at jeg besluttede: "Mit liv er for kort til det offentlige".

Hvis IT-håndteringen af de danske told-, skatte- og afgifts-love kræver 9000 siders kravspecifikation, er det lovene det er galt med.

Er de 9000 sider kravspec alene, eller det samlede udbudsmateriale?

Med de vandvittige beløb som et system som POLSAG koster, så sidder jeg tilbage med en tanke om at det nok er billigere at give en håndfuld politibetjente og programmører en dobbelt uddannelse. Dvs. efteruddanne x10 programmører til strissere (eller den anden vej rundt) og give dem arbejdserfaring indefra med de rapporterings værktøjer som politi arbejde kræver. Sæt dem derefter til enten selv at lave en smartere løsning eller skrive kravspecifikationen. Stil dem til rådighed halvdags for projektet til at svare uddybende, til at sikre forståelsen og til at teste prototyper på programmet. Det koster måske 20 millioner at lave sådan en lille øvelse, men sammenlignet med risikoen for at projekter som POLSAG kører helt af sporet, så er det måske en billig forsikring.

Der bliver sikkert også snart brug for programmører der er sagsbehandlere, sygeplejersker, pædagoger, lærere, landmænd, advokater osv. for jeg tror at det er bedst hvis programmører taler med andre programmører og ikke kun koder ud fra kravspecifikationen. Jeg ved alt for lidt om programmering, der er bare en tanke jeg sidder tilbage med efter at have læst en interessant debat. Tak for den, i øvrigt.

[quote]Til listen med mirakler med IT og netværk vil jeg bare personligt tilføje rejseplanen.dk [...]

Så vidt jeg ved er det et stykke Hollandsk software.[/quote]

Damn! Jamen det forklarer jo alt (facepalm).

@ Markus Hens & Poul-Henning Kamp Rejseplanen var tidligere baseret på en søgealgoritme fra et Hollandsk firma, men det er rigtig lang tid siden, det var dengang Rejseplanen var et DSB projekt.

Senere kom de andre trafikselskaber til og man oprettede et nyt selskab (Rejseplanen A/S). Der blev skiftet til tyske HaCon, der er førende inden for rejseplanlægning.

Rejseplanen er derfor ikke et typisk system udviklet i det offentlige danske regi, men må ses som et fælles europæisk projekt, til passet de regionale behov. Men udviklet af HaCon, et super professionelt tysk softwarefirma. Måske derfor er der succes.

Sysadm, Rejseplanen.

Double-damn! Arghhh...... Men super-ros til rejseplanen.