olav m.j. christiansen bloghoved olav christiansen

Tragedier i IT - del 2

I forbindelse med mit blogindlæg om Humor i IT var der nogen, der opfordrede mig til at lave et indlæg med tragedier i IT. Det blev langt, så jeg delte det i to - del 1 kan du finde her.

I del 1 kan du også læse det første eksempel på tragedier i IT, nemlig den artikel, som egentlig er grunden til dette blogindlæg.

Eksempel nr. 2

Det næste eksempel handler om Sundhedsplatformen. Jeg er så heldig at jeg aldrig direkte har arbejdet i det projekt, så derfor tør jeg godt at udtale mig lidt om det set udefra. Mine kilder er derfor kun dem, som alle andre også har adgang til via pressen og de officielle udmeldinger. Og jeg vil med det samme tage det forbehold at jeg faktisk ikke har læst meget mere end nogle overskrifter hist og pist. Så jeg kender i virkeligheden ikke det projekt i detaljer på nogen måde.

Først og fremmest vil jeg tøve med at erklære hele Sundhedsplatformen for en tragedie. Dertil er det lidt for komplekst, og man bliver nødt til at tage mange ting i betragtning først. F.eks. skal man se det i lyset af alle de mange gamle systemer, det har erstattet. De problemer, man har set med det nye system, ville man måske også have oplevet med de gamle systemer, og nogle af fejlene kunne også have været til stede i et tænkt alternativt system.

Så jeg vil nøjes med denne gang at dykke ned i en enkelt sag, nemlig den med de forkerte recepter, og spekulere lidt over hvad man kunne have gjort anderledes for at undgå den type fejl.

For dem, der ikke har læst om den sag, kommer her et hurtigt resumé: Det har vist sig at der er en fejl i Sundhedsplatformen, der gør at man under visse omstændigheder kan få udskrevet en forkert recept til patienter. Samtidig gik der en del tid fra man opdagede fejlen til den rent faktisk blev rettet.

https://www.version2.dk/artikel/sundhedsplatformen-printede-forkerte-pil...

Vi har altså to problemer/udfordringer (issues på danglish): 1. Selve fejlen og 2. Den lange tid der gik, før det blev rettet.

Hvis man kigger på selve fejlen, viser det sig, at det ikke engang er en 'rigtig' fejl. Det handler i virkeligheden mere om brugergrænsefladen. Hvis lægen, som anvendte systemet, brugte det på en bestemt måde ville den nye/ændrede recept ikke slå igennem på den etiket, der er på medicinen (men godt nok i systemet og databasen). Så egentlig handlede fejlen om en uhensigtsmæssig måde at bruge systemet på.

Den type fejl kan man rette på to måder: Der skal uddannes ordentligt i systemet, så man sikrer sig bedst muligt imod at man kommer til at udføre noget forkert. Men samtidig bør man også i grænsefladen tydeliggøre hvordan man skal bruge det - og så vidt muligt sørge for at undgå at det overhovedet er muligt at gøre noget forkert.

Lad os tage det sidste først. Alle, der har brugt et kontorprogram ved at man kan komme til at afslutte uden at gemme det aktuelle dokument. Det er ikke en fejl. Sådan er de fleste af den type applikationer bygget. Men mange programmer vil advare brugeren om at man nu er i færd med at foretage sig noget utilsigtet (dvs. afslutte uden at gemme). Det er noget lignende dette man nu har indført for at løse problemet fremadrettet (foruden bedre undervisning i systemet formodentlig). Der kommer nu en pop-up, så lægen ved at der kan opstå et problem, hvis man ikke gør tingene i den rigtige rækkefølge.

Så langt så godt. Men kunne man have opdaget fejlen før systemet blev sat i produktion? Det mener jeg bestemt godt man kunne.

For det første skal man sørge for at inddrage brugere tidligt i forløbet, sådan at man får afprøvet og beskrevet de forskellige brugerscenarier. Dernæst skal man - efter at have bygget/tilrettet systemet - gennemføre en omfattende afprøvning - en test. Denne test burde have opdaget den type fejl, så man kan kun spekulere på hvorfor den ikke er opdaget. Et gæt er at det kun er interne testere, der har afprøvet systemet. Dvs. at de egentlige anvendere af systemet måske ikke har gennemført mere omfattende tests af det, før man tog systemet i brug. En læge er jo en dyr ressource sammenlignet med mange andre personalekategorier, så man kan jo spekulere i at de rigtige brugere af systemet kun har deltaget i en mindre del af afprøvningen af systemet. Det kan så undre én at man ikke har opdaget fejlen f.eks. i forbindelse med undervisning i systemet, hvor man jo burde have gennemført nogle af de samme scenarier.

Vi kan måske lidt forsigtigt konkludere at en bedre brugerinddragelse og en bedre test burde have fanget sådan en fejl - også selv om der aldrig er nogen garanti for at man finder alle fejl i et system før det implementeres. Men hvorfor det ikke skete, tør jeg selvfølgelig ikke gætte på. Det kan der være mange forskellige forklaringer på.

Hvad så med det andet problem? Hvorfor gik der så lang tid før man fik rettet fejlen?

Der tør jeg igen kun gisne lidt om hvad der er sket. Tilsyneladende har fejlen være der siden systemet blev taget i brug i maj 2016. Den blev rapporteret ind af en bruger 5. juli sidste år (2018), men blev først endeligt løst i systemet den 25. oktober (også i 2018).

Regionerne siger selv at det har været svært at finde frem til hvad fejlen skyldes, men køber vi den forklaring? Nej, det må jeg som fagmand sige er en bortforklaring. Hvis man har en helt konkret hændelse, er det forholdsvis let at gå tilbage og rekonstruere hvad der er sket. Man bør jo vide helt præcist hvilken læge, der opdaterede den pågældende recept og så f.eks. bede vedkommende om at gentage proceduren. Det er efter min bedste overbevisning ikke en fejl, der er svær at reproducere, så hvad kan der så være gået galt?

Igen kan jeg kun gisne, da jeg ikke kender systemet indefra. Det bedste bud fra min side er nok at fejlmeldingen er druknet blandt en masse andre fejl og ikke rigtig taget alvorligt. Man ser desværre ofte en ikke helt professionel håndtering af fejlmeldinger, hvor det hjul, der piber mest, oftest bliver smurt. En fejl bør altid vurderes objektivt, uanset om den kun er meldt ind én gang. Og den bør kategoriseres som det allerførste, så man ved hvor alvorlig fejlen er. Om det er sket på en korrekt måde, tør jeg slet ikke gætte på. Men jeg vil da gerne opfordre Version2 og andre medier til at søge agtindsigt i det sagsbehandlingssystem, der er anvendt til fejlrapporteringen (ifølge medierne et system, der hedder Snow). Det kunne da være interessant at vide helt præcist hvad tiden er gået med fra fejlen er meldt ind den 5. juli og frem til den er rettet den 25. oktober.

Jeg kan altså ikke udefra se præcist hvad der er gået galt i processen, men jeg mener ikke det er professionelt håndteret hvis en alvorlig systemfejl først er rettet efter 112 dage, uanset hvordan man vender og drejer det.

Er det så en tragedie? Ja, det må det bestemt siges at være, for der har været fejl på ret mange recepter. Jeg har set tallet 3.829 nævnt, hvilket er ret højt. Og mange af de mennesker kan rent faktisk have taget skade af dette, så det må siges at være ret alvorligt.

https://www.dr.dk/nyheder/regionale/hovedstadsomraadet/sundhedsplatforme...
https://www.sundhed.dk/sundhedsfaglig/information-til-praksis/hovedstade...
https://www.regionh.dk/presse-og-nyt/pressemeddelelser-og-nyheder/Sider/...
https://www.tv2lorry.dk/artikel/regioner-opdager-tusindvis-af-fejl-paa-r...

PS: Det viser sig i øvrigt at være et langt større problem end først antaget:
https://www.dr.dk/nyheder/regionale/hovedstadsomraadet/flere-nye-fejl-i-...

Eksempel nr. 3

Det sidste eksempel jeg har valgt til dette indlæg, handler om noget helt andet. Og så dog ...

Her i sommer kom det frem at Københavns Universitet nedlagde et it-projekt, der har været fem år under udvikling:

https://www.computerworld.dk/art/243881/koebenhavns-universitet-dropper-...

Grunden til at jeg bider mærke i sådan en historie, er at fem år er ret lang tid - især når man tænker på at det dels drejer sig om noget så almindeligt og udbredt som et system til personaleadministration og dels at det er KU, vi taler om. Det jo bl.a. dem, der uddanner vores fremtidige it-specialister, så hvordan kan det være at de ikke kan finde ud af at styre sådan et projekt, når nu de underviser i hvordan det bliver gjort?

Måske kan andre offentlige instanser ånde lettet op, når de ser dette, og tænke: Nå ja. Når de ikke engang kan finde ud af det, så kan man vel heller ikke bebrejde os at vi fejler i vores projekter.

KU skulle have implementeret systemet Epos i oktober 2018, men har i stedet ophævet kontrakten med leverandøren, og man bliver nu nødt til at gå tilbage til det gamle system ScanPas, som er omkring tyve år gammelt.

Man har ikke ønsket at oplyse hvad KU har brugt på systemet, men på fem år kan man godt nå at brænde en del penge af - penge der kunne være brugt på mange andre mere fornuftige ting. Mit eget personlige gæt er at vi er oppe i et tocifret millionbeløb, men det er selvfølgelig bare et (kvalificeret) gæt.

Hvad var så årsagen til at man opsagde kontrakten? Tja, den officielle udmelding er at det skyldes en forsinkelse hos leverandøren, men det lyder for mig lidt tyndbenet. En forsinkelse kan ikke i sig selv være årsag til en opsigelse, især ikke hvis man har brugt (læs: spildt) fem år på projektet. Der må ligge noget andet bag den beslutning.

Hvad mener man egentlig, når man siger at et projekt er forsinket? Det handler jo i bund og grund om at man har lavet en forventningsafstemning mellem leverandøren og kunden om hvornår produktet skal leveres. Dette involverer bl.a. nogle estimater og har formodentlig resulteret i en tidsplan, som man er blevet enige om. Hvis en bestemt leverance så er forsinket i forhold til den fælles plan, kan man tale om en forsinkelse. Men er en forsinkelse i sig selv nok til at stoppe projektet? Nej, det lyder mærkeligt. Det er faktisk helt almindeligt at man kan være forsinket i forhold til en tidsplan, da sådan en plan jo netop er baseret på nogle estimater, som ikke nødvendigvis holder i den sidste ende. Det er helt almindeligt og efter bogen at man justerer planer ind efterhånden som man bliver klogere.

Der må altså ligge flere ting bag beslutningen, som jeg ikke har kunnet fremsøge. Måske er der læsere, der kan gøre os andre klogere på processen?

Agilitet

Lad mig lige tage endnu en afstikker til teoriens verden og kigge på de agile principper. Hvad forstår vi ved at være agile? En væsentlig del af det at være agil er at man er hurtig til at træffe beslutninger og f.eks. reagere på forandringer. Man kan faktisk tale om hvor agile man er ved at kigge på hvor hurtigt man kan agere i et projekt og ændre retning.

Vi kunne tage et par af mine sædvanlige dårlige analogier som eksempler: Et stort skib (f.eks. et containerskib, en olietanker eller et hangarskib) kan ikke ændre retning specielt hurtigt. Der er så meget inerti pga. den store (sammenhængende) masse at man bliver nødt til at planlægge ruten i forvejen og hele tiden vide hvilken vej man skal. Kommer der pludselig noget i vejen, kan det ende katastrofalt. Kigger vi i stedet på f.eks. en fugleflok, en fiskestime eller en flok zebraer der løber hen over sletten, kan sådan en stor flok individer godt reagere på forandringer og ændre på retningen, hvis der sker noget uventet. Det skyldes jo primært at der ikke er tale om én samlet masse, men i stedet mange uafhængige individer, som hver for sig kan agere i forhold til de andre. Og skulle der ske noget katastrofalt, går det måske kun ud over ganske få individer.

Agiliteten ser altså ud til at være bedre i en masse små selvstyrende enheder end i en stor sammenhængende mekanisme, hvor det hele skal flytte sig samtidigt. Det er jo så kun en fordel, hvis gruppen samlet har et fælles mål. Et mod-eksempel er lemminger, der løber hen mod en skrænt og kaster sig ud i afgrunden.

Der er i øvrigt nylige interessante studier om myrer, som ser ud til at have en slags kollektiv hukommelse, der overlever det enkelte individ. Desværre ser det ud til at menneskehedens fælles samlede hukommelse er på vej nedad, men det er igen et sidespring (begge dele fik mig til at tænke på begrebet den lærende organisation, men det må vi kigge på en anden god gang).

Hvorfor bringer jeg så det med agiliteten på banen?

Lad os lige hoppe tilbage til faget i stedet for de dårlige analogier: En udvikler, der koder sit eget system ud fra sine egne ideer, er nok det mest agile projekt man kan tænke sig. Vedkommende kan jo ændre retning fra minut til minut, så her er reaktionstiden ekstremt kort. Går man lidt videre kan man kigge på f.eks. Scrum, hvor man typisk kører sprint af 14 dages varighed. Det betyder også at agiliteten (reaktionstiden) typisk ligger omkring to uger for sådan et projekt. Et mere traditionsstyret PRINCE2-projekt vil måske kun ændre retning mellem faser, når styregruppen beslutter det, så her taler vi typisk om en måned eller mere, mens et program (flere projekter, der arbejder sammen om et fælles mål) kan have en endnu længere reaktionstid.

Udfordringen mellem at vælge og implementere den rigtige projekt- og udviklingsmodel er altså at få etableret et passende styringsniveau i forhold til opgaven, men samtidig få sikret nogle mekanismer der minimerer den ellers manglende agilitet i en for stram styringsmodel. Vi vil hellere kunne reagere som en flok fugle end som et containerskib.

Her er det så at man kan konstatere at KU tilsyneladende har haft en reaktionstid på fem år. Det er altså et tal for hvor agilt det projekt har været.

Uden at kende mere til baggrunden tør jeg slet ikke gætte på hvad der er sket. Måske er det den rigtige beslutning at man stoppede projektet, men det kan i så fald undre én at det kan tage hele fem år at komme frem til den beslutning. Hvis man havde haft nogle trafiklys undervejs, kunne man måske have ageret hurtigere og enten bringe projektet tilbage på sporet eller stoppe det før man har brugt så meget tid på det.

Det kunne være interessant at se referater fra de styregruppemøder, der nødvendigvis må have været undervejs. Det er jo netop et af den slags projekter, man kan lære noget af, så man burde jo bruge erfaringen fra sådan et projekt fremadrettet.

Er det så en tragedie? Tja, det er i hvert fald tragisk at man har smidt en masse penge (og andre ressourcer) ud af vinduet og spildt fem år på tilsyneladende ingenting for hvad der principielt er offentlige midler. Men resten vil jeg overlade til læserne at vurdere.

PS: Husk at fortælle os hvad du mener er en tragedie i IT.

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

det er KU, vi taler om. Det jo bl.a. dem, der uddanner vores fremtidige it-specialister, så hvordan kan det være at de ikke kan finde ud af at styre sådan et projekt, når nu de underviser i hvordan det bliver gjort?

Desværre har undervisere og forskere i datalogi på KU stort set ingen indflydelse på KUs IT-projekter. Ikke fordi datalogerne ikke vil, men fordi de ikke bliver spurgt.

  • 5
  • 0
Chris Bagge

Nu er jeg der hende hvor pensionen nærmer sig meget hurtigt, men alligevel. Et projekt der gik galt på rigtigt mange måder var, som jeg husker det Amanda til arbejdsformidlingen. Der var problemer med hele ideen - hvis bare vi registrerer nok kan vi løse alle problemer. Der var problemer med platformen OS/2, der teknisk set var fin. Der var problem med performance. Der var problemer med leveringstid. Og som jeg husker det blev det skrottet, inden det rigtigt kom i drift.
Blev der lavet nogle analyser den gang? Bonnerupudvalget?

  • 1
  • 0
Chris Bagge

Referencen til et Hangarfartøj er nok ikke ret god. Sådan en bassedreng kan, ved en fart på 30 knob, dreje 180 grader rundt på omkring 1 sømil (1852 m)! Men der er en pris for det, energi. Den bruger buler at energi, hele tiden! Som analogi ville det være. Ja, vi kan godt have et agilt projekt der er stort men så skal der tages højde for det frabegyndelsen af (arkitekturen) og så koster det ressourcer, hele vejen igennem.

  • 0
  • 0
Chris Bagge

Der tales ved agile projekter om, at man hele tiden kan ændre tingene, og at det er forretningskrav der styrer det. Det skurrer i mine ører når jeg tænker på store systemer. Hvis man ikke får lavet en ordentlig arkitektur bliver det ikke et godt system. Jeg mangler i dag en respekt for systemarbejdet. Hvis der ikke er en ordentlig arkitektur så når vi ikke i mål. Arkitekturen skal defineres først og laves ordentligt (af en meget lille gruppe). Ideen med at vi bare laver refaktoring holder ikke. Et af de tydeligste eksempler herpå er Kent Beck eXtreme programming projekt for Chrysler, der fik masser af omtale, men som aldrig kom i drift.

  • 0
  • 0
Anne-Marie Krogsbøll

SP- forløbet kan bestemt kaldes en tragedie for det sjællandske sundhedsvæsen - og, måske, for patienter, der er kommet i klemme i varierende alvorligt omfang. Men det er ikke til at komme uden om, at der også er noget tragikomisk over det. Læs nyuddannede sygeplejerske Stine Fuglsang Larsens oplevelser i dag med kursus i den nye version af Splatformen:
https://www.facebook.com/groups/217879532080844/

Tragisk, tragikomisk eller måske begge dele? Beskrivelsen kunne i hvert fald uden ret meget arbejde dramatiseres i et satireprogram. Vi kan vist godt forberede os på, at der bliver nok at skive om om et par måneder, når den nye version rulles ud.

  • 0
  • 0
Jørn Madsen

Desværre har undervisere og forskere i datalogi på KU stort set ingen indflydelse på KUs IT-projekter. Ikke fordi datalogerne ikke vil, men fordi de ikke bliver spurgt.

Det har altid undret mig. Du og mange andre kompetencer på uni ville i forbindelse med mange IT indkøb, offentlige som private, kunne komme med vanvittigt gode input omkring design, teknologier og alt muligt.

Jeg fatter ikke, at det ikke er mere brugt i Danmark, men det er som om vi har opbygget en mur imellem dygtige folk på uni og den "virkelige verden".
Såvidt jeg ved, så er det modsatte gældende i f.eks. Sverige. Der er et intensivt samarbejde mellem uddannelsesinstitutioner og erhvervsliv.
Samfundet mister meget, ved ikke at udnytte den viden,- og uddannelserne ville måske blive endnu bedre, hvis man sparrede med "virkeligheden".

Men man skal nok ikke glemme, at der jo også er parter, der absolut ikke ønsker jeres input/vurdering.

  • 3
  • 0
Olav M.j. Christiansen Blogger

Der var problemer med platformen OS/2, der teknisk set var fin. Der var problem med performance. Der var problemer med leveringstid. Og som jeg husker det blev det skrottet, inden det rigtigt kom i drift.

Tilfældigvis talte jeg på et tidspunkt med nogle af de udviklere, der var involveret i Amanda, og de sagde det samme: Selve platformen fungerede teknisk set fint nok.

Blev der lavet nogle analyser den gang? Bonnerupudvalget?

Godt spørgsmål. Jeg ved det ikke. Desværre er det offentlige ikke rigtig god til at lære af fejltagelserne i den type projekter. Det kan der være mange forskellige forklaringer på.

Der står en smule om Amanda på wikipedia her:
https://da.wikipedia.org/wiki/Amanda_(edbsystem)

  • 0
  • 0
Olav M.j. Christiansen Blogger

Referencen til et Hangarfartøj er nok ikke ret god.

Nu har jeg jo heldigvis skrevet at det er en dårlig analogi :-)

Men lad mig forsikre dig om at hvis der sker noget uventet få meter foran stævnen på et meget stort skib, så har det ingen som helst jordisk chance for at undgå f.eks. en kollision, uanset hvor stor motor det måtte have.

Du skal nok ikke fokusere så meget på analogierne eller læse det alt for bogstaveligt. Så risikerer du at gå glip af pointen ved indlægget. Det kan være jeg på et tidspunkt bør lave et blogindlæg kun om analogier. Indtil da må du dog nøjes med dette:
https://www.version2.dk/blog/daarlig-analogi-1086282

  • 0
  • 0
Olav M.j. Christiansen Blogger
  • 0
  • 0
Chris Bagge

Har her i weekenden siddet og læst i "Crosstalk Magazine", http://www.crosstalkonline.org/. Bladet (nu elektronisk) udgives af USAF Software Technology Support Center (STSC). Det ser desværre ud til at udgivelsen er gået i stå i 2017.
November/December 2016 udgaven af bladet har titlen "Beyond the Agile Manifesto". Her er der et indlæg af Alistair Cockburn, en af medskribenterne på Agile Manifesto. En anden af artiklerne "Beyond the Agile Manifesto" er også spændende. Den ser på hvad der får et team til at virke. En af erfaringerne fra Googles "Project Aristotele" er:

"that the real key ingredients are the interactions of the team members and the structure of their work. The No. 1 characteristic Google identified, and that they asserted made the most difference in whether a team could be high-performing, was the presence of psychological safety".
samt:
"the final piece is the realization that members of those teams need to feel that they are operating in an environment in which they can not only do their best work but also learn from their failures."

Dette står i skærende kontrast til den måde hvorpå vi opfører os her hjemme, især i offentlige projekter. Folk får mundkurv på. Man vil ikke have at der er nogen der kigger projektet efter i sømmene. Embedsværket/politikerne gør tilsyneladende deres bedste for at undgå high-performing teams.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize