/elektronik

Cowi har fået sin egen IC4-sag: Skandale-testene

Cowi fremstår utroværdig, når ingeniørfirmaet gang på gang lover it-test i folkeskolen, uden at de virker. Det påvirker hvert et hjørne af selskabets forretning, fastslår brancheanalytiker og professor.

Af Magnus Bredsdorff, fredag 05. mar 2010 kl. 09:26

Sagen om den nationale it-test i folkeskolen er lige så skadelig for leverandøren, rådgiverfirmaet Cowi, som de forsinkede IC4-tog er for DSB og den italienske leverandør, Ansaldobreda.

Sammenligningen kommer fra professor Finn Frandsen, der leder Center for Virksomhedskommunikation ved Handelshøjskolen, Århus Universitet, fordi test-systemet nu er udsat for fjerde gang. Systemet er op til fem minutter om at reagere, og Cowi aner ikke, hvor fejlen ligger.

Cowi har påtaget sig det fulde ansvar for skandalen, og det er ifølge professoren lige efter manualen i krisekommunikation. Det hjælper bare ikke så meget, når det nu er tredje år, at systemet er lammet af fejl.

»Firmaet bliver fanget i, at det må bruge den samme krisestrategi igen og igen. Det mister ikke blot noget af sit image og omdømme. Også troværdigheden tager skade,« siger Finn Frandsen med henvisning til, at Cowi gentagne gange har lovet, at systemet ville fungere.

»Alle ved, at implemeteringne af nye, store it- og forandringsprojekter i det offentlige kan gå galt, så man kan slippe af sted at fejle én gang med kun en lille ridse i lakken. Men hvis man drages ind i en proces, hvor der går lang tid, og hvor man igen og igen melder ud, at nu er den der, så smitter det af på image og omdømmet. Det problem kender DSB og de stakkels italienere jo med IC4-togene,« tilføjer professoren.

Han tilføjer, at når først Cowis troværdighed tager skade, så gælder det ikke kun it-forretningen, som ikke fylder meget hos Cowi.

»Hele firmaet kommer til at fremstå som utroværdig og en smule inkompetent,« fastslår Finn Frandsen.

Administrerende direktør Per Andersen fra it-analysefirmaet IDC Nordic mener også, at test-skandalen går ud over Cowis troværdighed, og at det gælder alle firmaets forretningsområder.

»Man kan ikke stykke et brand op i de forskellige dele, som en virksomhed består af,« siger han.

Værst for forholdet til potentielle kunder
Per Andersen understreger dog, at graden af skade varierer afhængig af, hvilken type af relation Cowi har til kunderne.

»Kunder, som Cowi i forvejen har et tæt samarbejde med, vil sikkert sige, at de kender firmaet som godt og solidt, så det betyder ikke noget for dem. Men det vil have betydning, når Cowi møder potentielle kunder. De vil have spørgsmål om, om de nu kan regne med, at deres ingeniørprojekt kører på skinner, når det ikke gælder systemet i folkeskolen,« siger Per Andersen.

Han understreger, at det ikke nødvendigvis er tilstrækkeligt til at komme ud over det dårlige image, at Cowis ingeniører kan overbevise de ingeniører hos kunderne, som de forhandler med.

»For ingeniørerne hos kunderne skal tilbage i deres organisation, hvor de bliver mødt af chefer, som ikke er meget for at tage risici, og som frygter, at det vil de gøre med Cowi,« forklarer Per Andersen.



05. mar 2010 kl 11:37

Carsten Scherrebeck Møller

Hvilke uddannelser?

Når Cowi sælger et sådant projekt, hvem udfører det? Måske et lille antal af ingeniører? Og måske hjulpet at et lille antal af datateknikere? Med andre ord: Er der fx slet ingen dataloger involveret?

Online og realtid, distribueret til hundredevis af skoler, ligner noget som store banker har erfaring med (at give til deres filialnet), og også detailkæder har noget der ligner. Det kræver desuden disciplin, at samtlige steder (skoler) er 100 procent kompatible, således at hvis centrum (et ministerium) retter på en fejl, som måske medfører krav om opgradering af noget i filialer (skoler), at sådan opgradering konsekvent sker i centrums IT-afdeling og alle filialer. Mulighederne for besparelser er enorme, men det kræver systemtænkning og udviklingsmæssig centralisme (hovedsæde) og anvendelsesmæssig decentralisme (filialer), som vi intet har af i Danmark i den offentlige sektor, bortset fra i skattevæsenet. I den forstand er dette famøse projekt et spydspidsprojekt fanget i kviksand og hængedynd og politisk modvind, fordi højrefløjen i Danmark hader systemtanker (bortset fra i skattevæsenet), fordi effektive systemer kan udkonkurrere fx private skoler og private hospitaler, derfor tvinger man offentlige skoler og hospitaler til selvstyre så de hver især skal opfinde de dybe tallerkener, som de aldrig kan på grund af for små størrelser. Desuden har politikere muligvis en tanke, at hvis vi laver professionelle systemer, styret af professionelle styrelser, da frygter politikere for at de mister indflydelse, i forhold til at det ligner at være lettere at få lov til at styre, hvis der intet centrum er, derimod et stort antal decentrale inkompetente enheder, dvs. kommuner der forsøger at styrer deres decentrale inkompetente skoler. Samtidig elsker kommuner at have al ledelsen over deres skoler, akkurat som at små banker elsker at være selvejere i små lokale samfund. Som er naturligt, men det er ikke effektivt. Alle vegne i private sektorer er det bevist, at optimum er at have et hovedsæde med specialafdelinger, der leder et stort net af filialer der hvert sted betjener lokale kunder. Den nylige ændring af antallet af kommuner i Danmark, fra mange små til færre som er større, er et sublimt eksempel på vanvid, fordi det er Rasmus Modsat i forhold til det optimale. I stedet burde vi have skabt flere og mindre kommuner, eller beholdt det hidtidige antal, og i stedet have frataget kommunerne alle de opgaver som kan automatiseres i et stort hovedsædes specialafdelingers IT-systemer, det vil sige styret af en indenrigsstyrelse. En sådan styrelse har vi ikke i Danmark. Vi har heller ingen undervisningsstyrelse, deraf problemet for Cowi, fordi "nationale IT-test af skoleelever" ikke bliver muligt, før vi har en professionel styrelse til at organisere og administrere det. Hvis vi får en sådan styrelse, da vil det være det samme som at fratage skolerne fra kommunerne, gøre folkeskoler til statsskoler, i hvert fald på administrativ måde, en tanke som nogen hader. Det er dog den eneste vej fremad.


05. mar 2010 kl 11:44

Peter Andersen

Fjolser

Hvorfor er det kun fjolser der arbejder med EDB her i landet? Skat's hjemmeside virker heller ikke idag..... SÅ svært skulle det da for fanden heller ikke være


05. mar 2010 kl 11:56

Peter Andersen

Og....

Ikke at glemme tinglysningen....


05. mar 2010 kl 12:20

Peter Hansen

Lasttest og monitoring

...ville have kunnet forhindre dette. Du skal simpelthen fyre op under systemet inden det sættes i drift, med scripts der imiterer brugernes forventede opførsel. Og du skal monitere det fra der hvor brugerne sidder.


05. mar 2010 kl 12:44

Lars Anton Jensen

Re: Lasttest og monitoring

..Test? - Den slags er vist en uhørt kættersk tanke for edb-folk generelt. - Jeg har mødt adskillige af slagsen, og tests synes at være noget de sjældent beflitter sig med. - Selv simple power-point præsentationer kikser jo på en stor del at de projektlederkurser vi alle samme render til i tide og utide, hvor vi lærer om milestones, økonomiopfølgning og kvalitetsikring. - Hvorfor teste? - Sæt det virker? - Så er der jo ikke mere arbejde i dét projekt ;)


05. mar 2010 kl 12:58

Kim Udklit

Klogeåger !

Virkelig konstruktive, omend lidt hårde udtalelser, Peter og Lars...

Dårlig uge ?

Typisk ingeniør udtalelser !


05. mar 2010 kl 13:13

Jesper Møller

Suk.....!

Monstro ikke man kunne have lavet et projekt for driftige, dygtige skoleelever med programmerings evner. Så kunne de have fået ti millioner og brugt resten på flødeboller.....eller Sommersby cider eller hvad Sørensen unge bruger 100 millioner på. Kunne selvfølgelig også måske bruge et par håndøre på toiletter der er ved at falde sammen et par nye vinduer og måske beholde en lærer eller to.

Begriber ikke at et så stor projekt kan fejle så eftertrykkeligt, er test's virkelig så bandlyst eller er jeg svært naiv. Virker bare ikke så professionelt.

Nuvel, god weekend.


05. mar 2010 kl 13:49

Ulrik Suhr

Re: Hvilke uddannelser?

Carsten Scherrebeck Møller
.
Jeg kan kun give dig ret. Det er også min opfattelse af de systemer der bliver udviklet ud fra hvad pressen fortæller.
Det hænger vel også sammen med at de aktører som bestiller projektet ikke helt ved hvor de vil optimere og hvordan. Det sker også i det private, men her er aktørerne mere bevidste om forretningen og ved derfor også meget hvilke processer som kan optimeres meget bedre....
I det offentlige tror jeg der er mange små konger som alle vil bestemme og derfor har vi de systemer som vi bestiller...

Det eneste jeg ikke kan forstå i sådan en implementering er metoden. En langsom 1-x antal skoler af gangen kommer på. dette gentages så med flere året efter etc. så kan man også sikre sig at skalleringen virker.

Jeg kan ikke huske på stående fod hvad systemet hed, men der findes en del stress test programmer så hvis en af disse er benyttet kan man vel udbede sig om data istedet for at spørge en "leder/chef" som ikke ved noget teknisk.


05. mar 2010 kl 14:32

Jesper Jepsen

Re: Lasttest og monitoring

Hvad sker der så når alle de syntetiske test med forventet bruger adfærd møder virkeligheden? som IKKE gør som forventet? Netop går ned med et brag og så sidder de nok så kloge udvikler og fortæller os at de slet ikke kan forstå da de jo har testet... ja men hvordan? virkeligheden banker ikke på først, den vælter huset..


05. mar 2010 kl 14:47

Ulrik Suhr

Re: Re: Lasttest og monitoring

Tror du seriøst at test systemer kun tester valide flows?ok...
tja.. man kunne vel også tage en del aber ind fra zoo og lade dem banke i pc'erne....

'On Topic'
Det test system jeg så på (i det private) var mht. samtidige database adgange for test af peek load, samtidigheds fejl etc. Det var dog kun på database siden.
testen var netop bestilt fordi der skulle bruges en test som ikke testede de "normale" flows.
Det er også derfor jeg undres over at man ikke lige sætte de penge af til at teste med et sådan værktøj..
Derfor min undren "hvor er de test data henne?".


05. mar 2010 kl 15:05

Peter Hansen

Re: Re: Lasttest og monitoring

virkeligheden banker ikke på først

1) Lav en beskrivelse, udfra hvilke processer der skal understøttes.

2) Moniter brugeradfærd i drift, og hvis det viser sig at anvendelsen er forskellig fra det beskrevne, overvej en ændring.

I det aktuelle projekt ville jeg som whatwentwrong analyse kigge på beskrivelsen og test dokumentationen først!


05. mar 2010 kl 15:58

John Vedsegaard

En nem lille opgave

Man kunne f.eks. lade 10. klasse lave sådan et simpelt lille projekt i deres dataundervisning, det er så simpelt at Cowi burde indrømme de ikke har haft 10. klasse til at lave det, men 4. klasse i folkeskolen.


05. mar 2010 kl 16:19

Frithiof Andreas Jensen

Re: Re: Hvilke uddannelser?

I det offentlige tror jeg der er mange små konger som alle vil bestemme og derfor har vi de systemer som vi bestiller.

Inden for det offentlige er der i praksis Ubegrænsede Ressourcer; derfor kan man acceptere tusindvis af systemkrav, inkludere uforståelig lovgivning samt håndtere historiske arbejdsgange uden at man skal prioritere, ændre eller fravælge noget af det - alle skal jo være tilfredse!

Systemerne knuses under deres egen vægt. De tilsvarende manuelle systemer fungerer heller ikke - hvis alle regler og procedurer fulgtes til punkt og prikke - men de reddes af at mennesker har en evne til at omgå forhindringer og levere noget alligevel.


05. mar 2010 kl 16:23

Mads Jørgensen

Japperi

Sådan går det når man japper det hele igennem på en gang.

Man skal altid starte i det små, og så hælde langtsom på.

Det er børnelærdom.

Start op med en forsøgsskole, og efterhånden som systemet virker kunne man langtsomt tilkoble flere og flere skoler i samme forsøgskommune. Derefter en region, og til sidst hele landet.

Og hvorfor ikke have en server i hver kommune for til allersidst at samkøre data?


05. mar 2010 kl 17:17

Lars Anton Jensen

Re: Klogeåger !

Ja ja Kim - undskyld en "undren". - Men hele situationen forekommer da grotesk. - Sæt man havde bygget storebælstbroen efter samme koncept: "Nu ser vi lige om den holder" - eller udviklet en bil eller et tog... øhh... nåe nej. - Forresten er broer også styrtet sammen, biler kaldt hjem fra markedet, og toge indkøbt som vi fortsat venter på. - Os "klogeåger" der ser til, kan ikke gøre så meget andet end at grine (mere eller mindre skadefro), og undre os over at den store lærebog med titlen "Why shit happens" tilsyneladende ikke er skrevet endnu. - Glimrende uge tak:) - Selv om jeg faktisk ikke er ingeniør :)


07. mar 2010 kl 08:11

Henrik Carlsen

Test

1. COWI er et større (en underdrivelse) ingeniørfirma. Det betyder ikke nødvendigvis at det er en flok af kompetente udviklere. IT-ingeniør-titlen er tit en blåstempling, men gør ikke kompetent. Det er et spørgsmål om personligheder og sammensætning - og projektstyring.
2. Min lille erfaring fra den verden (FRI) er, at der sjældent hentes ekstern konsulentbistand. Der er en udbredt modstand for nogle der kræver højere timetakster end dem selv. Har de haft konsulenter til at kigge på det? Jeg kan foreslå flere (mon Google lejer konsulenter ud? De er da eksperter på at udføre søgninger der udnytter båndbredden optimalt)
3. Der snakkes om test. Har der været en koordineret worst-case stress test, med eleverne som testere? Strik en test sammen, som kommer krogene igennem og aftal' at eleverne trykker på send-knappen samtidigt. Det kan bringe ethvert system ned, men med 5-6 buffere rundt omkring i landet burde det kunne lykkes (tænker på en storskala cluster-løsning). Alternativt kunne man lave en test-applikation som blev sendt ud til de enkelte skoler og fjernstyret af COWI.
4. Det kan sgu da ikke være svært at måle på hvor proppen i systemet er. Det må være en bølge af SQL-forespørgsler der kommer i kø et eller andet sted. Det kan ikke passe, at ingen ved hvad der laver ventetiden. Det findes tonsvis at programmer til at overvåge den slags.

Alt det må da have været i tankerne dengang COWI begyndte at strikke databasen sammen - eller har det?


07. mar 2010 kl 08:55

Jens Arne Hansen

Re: Test



En let omskrivning af den gamle talemåde gælder tilsyneladende stadig:
"Bromager, bliv ved din ...."

For 10 år siden mødte jeg en flok rådgivende amatører på vej ind i medicinalindustrien, jeg har ikke fulgt med i om de lærte det eller trak følehornene til sig.
Nu er det så IT, men hvis en smule ydmyghed fandt vej ind i virksomhedskulturen, så man satte sig ind i emnet inden man gik igang, så ville det nok ikke skade!


07. mar 2010 kl 09:07

Jens Madsen

Re: Test

Kan det være korrekt, at Cowi ikke har adgang til programmører som kan løse opgaven? Er det samme programmører, de har sat til opgaven hver gang - eller er det blot lykkedes, at finde nogen nye ukompetente, til hvert forsøg? Er det programmørerne, der har bestemt løsningsmetoden - eller har de fået udstukken hvordan de skal løse opgaven (f.x. fået besked på at der skal bruges microsoft .net, og database af bestemt fabrikat mv. fordi at direktøren har forhandlet sig dertil)? Har de overvejet hastigheden og kapaciteten for de tools, databaser, cgi'er, og lign. de bruger, inden der tages beslutning om de skal bruges? Eller tages beslutningen, uden indhentning af data og uden der laves belastningsundersøgelser først?


07. mar 2010 kl 09:33

Jens Madsen

Re: Re: Test

Hvorfor kræver opgaven SQL databaser og CGI'er? Kunne det ikke gøres uden, med java/javascript alene?


07. mar 2010 kl 10:34

Carsten Scherrebeck Møller

Re: Re: Test

Et gæt er, at undervisningsministeriet ingen IT-viden havde på forhånd, og derfor ikke vidste om hvad sådanne arter af systemer koster af indkøbe og holde i drift, som betyder at Cowi solgte opgaven alt for billigt, måske en pris på kun 3 procent(?). Skolesystemet skal jo kunne tåle titusindevis af brugere ad gangen, og anvendelsen er geografisk vidt udspredt, og systemet skal anvende kryptering for at forhindre snyd og for at beskytte persondata, og det skal omfatte et indbrudssikkert testudviklingsmodul fordi de korrekte testsvar ikke må kunne stjæles, og dertil et ledelsesmæssigt administrationsmodul, og IT-hardware der ikke må kunne svigte, som betyder et system der måske bør koste cirka 1 milliard kroner at udvikle, og koste måske cirka 100 millioner kroner at holde i drift om året i en undervisningsstyrelse, og dertil 1 million kroner i driftomkostninger pr. skole, cirka 300 millioner kroner(?) I stedet for disse ædru tal, solgte Cowi måske et projekt i begyndelsen for under 1 million, med tanker om, hos diverse ledere, at alt hvad er var behov for, var een ældre personlig computer og et gratis Excel regneark og nogle timers spaghetti-programmering.

Spydspidsprojekter får aldrig de penge som de behøver, fordi beslutningstagerne i sagens natur ingen viden har og derfor fornægter prisen, fordi den altid vil ligne at være fatalt alt for dyr. En forståelse af en pris, kræver at man udregner hvad eksisterende metoder koster, for eksempel koster en manuel aftestning af folkeskoleelever det rene vanvid hvert år i form af timelønninger og bygninger og kontorer. Desuden koster det fatalt for vort samfund at alle politikere famler i blinde, fordi det nuværende manuelle skolesystem ingen viden afkaster til landets ledere, derfor kan de diskutere i årevis, fordi ingen er i stand til at bevise noget. Når et IT-baseret aftestningssystem begynder at køre, vil der komme helt andre (brugbare) boller på suppen, data som vil kunne leveres til politikere kun splitsekunder senere i form af overordnet statistik. Til den tid vil man øjeblikkeligt kunne køre til skoler der har præsteret skidt og opdage de faktiske fysiske og menneskelige forhold og gribe øjeblikkelig ind. I dag sejler det hele i inkompetence til sammenligning.

Det helt store problem er med IT-baseret aftestning af skoleelever, at systemet bliver en udgift oven i alle nuværende udgifter, fordi systemet ikke evner at indføre besparelse, så længe som at skolerne tilhører kommunerne, fordi hver kommune selvstændigt bestemmer alt om hvordan skolerne skal administreres og ledes og indrettes og bemandes og bygges. Hvis sådant var tilladt i fx Danske Banks filialer, ville banken gå konkurs. Vi mangler en uddannelsesstyrelse til at lede alle vore offentlige skoler, vi mangler at fratage skolerne fra kommunerne og gøre dem til statsskoler. Når den forandring er sket, vil det være anderledes let at indføre systemer, fordi de vil komme fra ét central sted og blive anvendt decentralt alle vegne, stordriftsfordel. Samtidig vil skolerne kunne fyre et stort antal af overflødige ledere, og i kommunerne vil der også være mennesker der kan fyres, fordi der kun er behov for lærere og een vicevært og een personalechef i hver skole, fordi de skal være filialer drevet af undervisningsstyrelsen. Dette vil betyde et overhead af udgifter på to mennesker i hver skole (vicevært og personalechef), som betyder at skolerne igen kan gøres ganske små og blive lokale ultratæt på hvor børn lever. Disse skoler bør bygges som kopier af een eneste optimalt designet skolebygning, mens alle nuværende skoler skal nedrives, fordi de er forkert bygget og fulde af råddenskab. En sådan revolutionær fremtid er absolut ikke hvad mange ønsker sig. Vi hører da også i medierne nu, at ledere udtaler at de ønsker at gøre IT-aftestning af elever til et "udviklingsprojekt" med frivillige skoler som deltagere, som betyder at disse ledere ønsker at myrde projektet, entet det, eller at de venter på at få et politisk flertal til at indføre en rigtig revolution.


07. mar 2010 kl 10:56

Jens Madsen

Re: Re: Re: Test

Skolesystemet skal jo kunne tåle titusindevis af brugere ad gangen,

Stadigt er mit spørgsmål, om dette ikke automatisk vil være løst, hvis man undgik databaseservere og CGI scripts, og alene brugte javascript.

Umiddelbart, vil jeg påstå Javascript oftest er mere sikkert end CGI scripts, fordi at javascripts køres på klientens computer, og derfor ikke kan blive mixed op med andre personers oplysninger ved en fejl.

Hvis elevens oplysninger skal uploades, så er det også muligt i Java. Her kan bruges et filnavn, som umuligt kan gættes, f.eks. et helt tilfældigt lavet på klientens computer. Muligheden, for at få udlæst directory skal naturligvis forhindres, men hvis dataene der uploades er krypteret, er der ikke store sikkerhedsmæssige risici, selvom der skulle fås adgang til krypterede data. Det rigtige er dog, at ingen har adgang dertil. Igen, er det en fordel, hvis krypteringen sker på client siden, og ikke på server side.

Er alt placeret på client siden, burde der ikke være problemer med at håndtere et stort antal brugere. Og samtidigt, er sikkerheden størst.

Jeg forstår ikke hvorfor, men ofte tror jeg mange tænker i store komplicerede serverscripts og databaseløsninger. Selvom de fleste opgaver, kunne klares alene med javascripts på clientsiden, og at sætte et katalog til writeable (måske ikke læsebart), for alle.


Ny i debatten? Opret en brugerkonto

  • Seneste nyt
  • Mest læste
  • Topdebat
Populært på Facebook
 

Nyhedsbrev

Tilmeld dig vores nyhedsbrev.