georg strøm bloghoved

Danske IT-Projekter kan lære af Obamacare

Den nye digitale børs hvor amerikanerne skal kunne købe sundhedsforsikring, er løbet ind i problemer. Den gode nyhed er, at der er et bud på årsagerne som går ud over den sædvanlige, hvis de bare havde brugt dit i stedet for dat i selve implementeringen.

Michael Slaby – en af hovedpersonerne bag Obamas meget roste kampagne website, beskriver fire afgørende forskelle mellem hans arbejde, og de udfordringer som designerne af Obamacares website skulle klare.

Den første var, at hans team kunne hyre de personer og vælge de værktøjer, som de mente var mest velegnede til opgaven, mens der var en lang række administrative regler og krav som en offentlig site skulle leve op til. Der er mere fokus på at undgå fejl, og til gengæld mindre plads til innovation.

Det minder om problemerne i Polsag, hvor udviklernes valgmuligheder var administrativt begrænsede. Det er et dårligt udgangspunkt, når man skal skabe en ny type system, hvor en del af udviklingsarbejdet nødvendigvis er eksperimenter.

Slaby beskriver hvordan et offentligt site ofte skal integreres med en lang række eksisterende systemer. Obamacares site skulle integreres med systemerne hos en lang række udbydere af sundhedsforsikringer, og nogle af de systemer havde i forvejen problemer. Opgaven var altså langt mere kompliceret end at bygge et system i et privat firma.

Det ligner Digital Tinglysnings problemer med den manglende integration med advokaters IT-systemer.

Oven i det beskriver Slaby hvordan der var politiske krav, som gjorde opgaven vanskeligere. Et af dem var at brugerne først skulle registrere deres personlige oplysninger, før de kunne se priserne på de relevante tilbud. Det er blevet omtalt som et af de største problemer på den nye site.

Det er en politisk krævet fejl i designet. Udbyderne af forsikringer, ville ikke have at folk kunne se den totale pris på en sundhedsforsikring, men kun prisen efter at de offentlige tilskud som den enkelte borger kunne modtage, var fratrukket.

Noget tilsvarende ser vi i andre offentlige systemer, hvor det er nærmest umuligt at skabe et system som fungerer tilfredsstillende, fordi de regler der skal administreres er for komplicerede.

Slaby beskriver et sidste problem. Det var politisk besluttet, at projektet skulle være færdigt til en bestemt dato, og den dato var besluttet før teknikerne var kommet med et bud på, hvor lang tid opgaven faktisk ville tage. Det var endda umuligt at starte systemet gradvist, da den største gruppe som ville prøve systemet, ville komme på i de første dage.

Det er min erfaring, at sådan en stram deadline kan øge varigheden af projektet. En del af det arbejde som er lavet for at få et eller andet færdigt til deadline, skal siden laves om.

Og så er der er sidste punkt, som Slaby endda har overset. Brugbarheden skal være i orden, og systemet skal svare til brugernes viden og behov. Det er specielt et problem, for et system hvor en stor del af brugerne er blandt de svageste i samfundet, og dem der har mindst erfaring med offentlige regler og med at bruge IT.

Jeg har oplysningerne fra et interview med Michael Slaby på:

http://www.thedailybeast.com/articles/2013/10/18/why-healthcare-gov-the-...

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
David Rechnagel Udsen

Efter at have læst blogindlægget, så virker det mere som om at ACAs hjemmeside kunne have lært af danske IT-projekter (altså den anden vej rundt). Mange af disse problemer som dette amerikanske projekt faldt i er også fælder danske projekter er faldt i.

Så de kunne lære hvordan man ikke skal gøre det; f.eks. arbitrære politisk krav er vigtig del af det.

  • 2
  • 0
Silas Ørting

Nu ved jeg ikke hvad Georg har ment i sit indlæg, men man kan prøve at lære af de fejl som amerikanerne har begået.

For mig at se er tre af problemstillingerne administrative: Hvilke værktøjer skal bruges, for mange/omfattende krav og en urealistisk deadline.

Problemet omkring brugbarhed er svært at løse, især når der er mange brugere der ikke har ensartede behov og færdigheder. Det kræver at der blev sat resurcer af til at undersøge tingene inden, men også at man er indstillet på at tilpasse tingene undervejs.

Problemet med integrering i eksisterende systemer er ikke noget vi kan slippe udenom når vi vil samle systemer eller informationer. En løsning kunne være at diktere et API som forsikringsselskaberne (i det her tilfælde) skal overholde. En af de store IT sammenlægninger herhjemme har været ifbm med Regionerne og sammenlægning af IT på hospitalerne. Midt indtryk er at det konstant bliver bedre og at en vigtig årsag er at der bliver arbejdet med langsigtede planer, hvor systemer stille og roligt opdateres og lægges sammen. Hvis nogen har erfaringer fra det arbejde må de gerne byde ind.

  • 0
  • 0
Log ind eller Opret konto for at kommentere