Indledning – Teknologirådets Workshop om Offentlige IT Projekter
Fredag den 21.5 afholdt Teknologirådet en workshop om hvorfor offentlige IT projekter fejler.Det var bl.a. baseret på udgivelse af Finansministeriets redegørelse for hvordan man planlægger at stramme op på IT Governance og projektstyring i offentligt regi. Jeg fremlagde i den forbindelse følgende i forbindelse med paneloplæg. Emnet for panelet var, hvordan brug af arkitektur og standarder kunne forbedre succesraten.
Hvorfor fejler offentlige IT projekter?
Offentlige IT-projekter har altid været genstand for kritik, så det er en historisk fejltagelse at tro, at det er en tendens, der er opstået i forbindelse med Internettets udbredelse – vi klarede os glimrende helt tilbage til etableringen af Kildeskatten og Sygesikringssystemet. Og det er ikke engang et specielt dansk fænomen, især UK, Australien, USA og andre har haft rigtigt spektakulære fejltagelser, så vi kan heller ikke skyde skylden på nationalkarakteren. Ser man på EU er det karakteristisk, at EU-systemet konsekvent fremhæver 'best-of-breed' og har alenlange beskrivelser af succesfyldte (EU-medfinansierede) eGovernment-projekter, men ikke nogen troværdige analyser af projekter, der fejler. Teknologirådets rapport, den såkaldte Bonnerup-rapport, en af de første forsøg på at systematisere fejlkilderne herhjemme, men faglitteraturen indeholder en række analyser, som giver flere aspekter, årsager til mulige problemer ved introduktion af teknologi i forskellige organisationsformer.
Maskinbureaukratier og netværksorganisationer
Den første grundlæggende fejltagelse er at opfatte IT og IT-løsninger som et stykke værktøj, der kan benyttes af en hvilken som helst organisation uden ændringer. Et traditionelt bureaukrati, der i en hierarkisk struktur arbejder mod et veldefineret formål, og hvor udførelsen koordineres og styres i kraft af regler og standarder, og vidensbasen holdes ajour i arkiver, skulle på papiret jo ellers være let at forsyne med nye værktøjer og IT løsninger, men til overraskelse for traditionelle sociologer viser det sig, at tilkomsten af teknologi ikke 'bare' automatisk fører til en symbiose: Viden og kunnen, der før var indlejret hos de enkelte medarbejdere, udføres måske nu af nye systemer, og det kræver forandring af (rutine) jobs, og det kræver forandringsledelse – for hvad gør man, ved medarbejdere, der skal 'aflæres' gamle vaner ? Morale nummer 1 er at teknologi og organisationer altid påvirker hinanden.
Men med opblomstringen af internettet er muligheden for at understøtte nye organisationsformer blevet meget mere oplagt – men hermed stiger kompleksiteten flere størrelsesordener og muligheden for spektakulære fejltagelser tilsvarende. En netværksorganisation kan bestå af alt fra uafhængige offentlige og private virksomheder, der 'bare' har en fælles indgangsportal til sammensvejsede og integrerede løsninger, der bygger på samspil mellem de indgående organisationers data, applikationer og programmer. Hvor et traditionelt bureaukrati holdes sammen i hierarkiet ved regler og ordrer, er motivationen og styrken af sammenholdet i en netværksorganisation fuldt og helt bestemt af gensidig tillid, interoperabilitet, fælles værdier – også benævnt 'social capital'. Også her øver teknologien en afgørende indflydelse på netværksorganisationens evne til at fungere, da teknologien medfører transparens, vidensdeling og åbenhed. Hvis kulturen, arbejdsformen, ledelsesformerne i de indgående organisationer er meget forskellig, vil tilførelse af teknologi kræve ændringer – i den enkelte medarbejders arbejde, i de regler, der styrer den enkelte organisation og igen : Det kræver forandringsledelse hos alle indgående organisationer.
Hvis vi skal tænke på nyere eksempler på problemstillinger, der illustrerer de 2 typer af organisationer, er det nærliggende at tage Tinglysningen og Domstolsstyrelsen som eksempel på det traditionelle hierarkiske bureaukrati, medens projekter som Den Offentlige Indkøbsportal, DOIP'en og i nyeste tid det kuldsejlede projekt for det danske katastrofeberedskab, SINE, som et godt eksempel på en netværksorganisation mellem vidt forskellige myndigheder og institutioner.
Hvor DOIP'en nærmest kan betragtes som en fælles portal, er SINE projektet et projekt, der var tænkt at indgå som rygrad i mange forskellige beredskabsmyndigheder – fra politi, beredskab, brand, ambulance, hospitaler, kommunale enheder.
Hvor kommer Arkitekturen så ind i billedet?
I oplægget til dagens seminar står med flammeskrift:
”Det offentlige har brug for en overordnet IT-arkitektur til at sikre interoperabilitet mellem forskellige offentlige systemer og åbne for privat brug af data til støtte af (for ?) den offentlige infrastruktur.” Som standardeksempel på hvor en sådan fælles arkitektur ville have hjulpet, anføres EPJ-situationen i Danmark, hvor vi fortsat står uden en fælles Elektronisk Patientjournal, der dækker hele landet. Implicit synes løsningen derfor at være at ophøje VTU's hvidbog om IT Arkitektur til en lovbefalet, landdækkende arkitektur, hvorefter alle haver sig at rette. Men forholder det sig nu også sådan? Og er der overhovedet nogle fornuftige alternativer til sådan et udsagn?
For at kunne besvare det på en afbalanceret må kan vi gå tilbage til 'Alle EA'ers fædreland' USA.
The Clinger-Cohen Act 1996
Den amerikanske kongres vedtog i 1996 denne lov, der er en forudsætning for amerikanske ministerier og myndigheder for at opnå bevilling til iværksættelse af nye IT systemer. Lovens bogstav kræver af de ansøgende myndigheder, at de har opstillet ”An integrated framework for evolving and maintaining existing information technology and acquiring new information technology to achieve the agency's strategic goals and information resources management goals”
Den praktiske håndhævelse heraf foretages af OMB – Office of Management Bureau – som har udvidet/præciseret ordlyden til at være et krav om en egentlig Enterprise Architecture, som defineres som ”An agency-wide roadmap to achieve an agency's mission through optimal performance of its core business processes within an efficient information technology environment.” Og det er det, vi i dag forbinder med EA: en samlet arkitektur, der binder forretningen og dens strategiske mål og opgaver sammen med IT løsninger og infrastruktur.
Så for at vurdere om ministerier, institutioner, 'agencies' lever op til loven, vurderer OMB så kvaliteten af den EA, der følger med ansøgning om nye bevillinger.
Det man vurderer er kvaliteten af den enkelte EA (Idet der netop ikke forlanges en fælles EA på tværs af myndighederne). Kvaliteten af den enkelte EA måles på:
Tolerance for ændringer – Er det muligt at skifte strategisk sigte/teknologi/organisation ?
Giver EA'en støtte for implementering af det/de nye systemer?
Er der indbygget en evne til at justere delmål undervejs i implementeringen?
Medvirker EA til at sikre en høj grad af målopfyldelse for projektimplementeringen?
Fokus er klart, at EA skal medvirke til at definere og støtte etablering af borger-centrerede, resultatorienterede løsninger – vel at mærke i høj grad baseret på standard komponenter (COTS: Commercial Off The Shelf). Hovedsigtet med loven og den måde, den administreres på, har været og er at medvirke til at få de enkelte resportområder moderniseret og effektiviseret som en direkte følge af den indsats, som Clinton-Gore regeringen satte i gang i halvfemserne.
Det har resulteret i mange og mange forskellige EA-versioner (Se f.eks. Beryl Bellmans paper her:) i de enkelte amerikanske ministerier og forvaltninger: Treasury Enterprise Architecture Framework, Department of Defense Architecture Framework, Federal Enterprise Architecture Framework med 5 underliggende frameworks m.v.
Fordele og mangler ved den amerikanske model
Umiddelbart giver denne måde at løse EA på den generelle fordel, at det enkelte forvaltningsområde bliver tvunget til at redegøre for sine kerneprocesser og sætte dem i relation til IT understøttelsen på den måde, der er mest meningsfyldt for det pågældende område. Det betyder, at man ikke er afhængig af en fælles terminologi, og at man kan beholde sin kulturelt betingede tilgang til opgavedefinitioner, generelle regler, og frem for alt lettere kan afspejle det eksisterende, ofte traditionelle hierarkiske organogram i EA'en. Alt i alt forhold der medvirker til en hurtig accept, og som medvirker til en generel hurtigere forståelse for hvor og i hvilket omfang de planlagte ændringer påvirker organisation og arbejdsgange. Det er altså en god model når det gælder om at sætte strøm til bureaukratiske hierarkiske systemer, som tidligere defineret.
Og fordelen er helt klart at hele processen understøtter og hjælper til forandringsledelse. Herved prøver man så vidt muligt at undgå, at et bestående bureaukrati sander til og modvirker ændringer.
Det er også interessant at bemærke kravet om 'COTS' hvor muligt; hvor mange danske udbud ville ikke have set anderledes ud og været lettere at få udbytte af, hvis flere standardløsninger var blevet indført i stedet for håndprogrammerede løsninger, der opfylder 'ufravigelige krav', men som ikke fornys eller opdateres i takt med andre kunders erfaringer?
Men ulempen ved metoden kommer frem, når det gælder om at understøtte tværgående løsninger, der involverer flere domæner og mange (forskellige) bureaukratiske hierarkiske eller løst koblede netværksorganisationer, herunder frivillige organisationer (NGO'er), internationale partnere o.l.
Der er ikke nogen fælles EA for alle amerikanske myndigheder – og stadig ingen fælles datamodel.
Så der mangler en overgribende, 'meta arkitektur' – netop IKKE en fælles, detaljeret EA, men en arkitekturmodel, der kan favne de forskelligheder som der nu en gang er, og som kan fokusere på at etablere netværkssamarbejde i en serviceoritenteret arkitektur.
Og der er én yderligere ulempe, som måske ikke mærkes i et stort land, men som i Danmarks tilfælde vil spille en afgørende rolle: Et krav om at hver myndighed opstiller, vedligeholder og følger sin EA stiller automatisk krav om tilstedeværelsen af højt uddannede arkitekturkompetencer, for lige præcis koblingen mellem ledelse, strategi, kerneprocesser og IT er ikke noget, der lader sig outsource.
EA i Danmark - Hvor er de reelle udfordringer?
Er det rigtigt, at vi ikke havde fået en EPJ skandale, hvis vi havde haft en fælles arkitektur fra starten? Når vi HAR så mange forskellige, skyldes det jo den daværende sundhedsministers ønske om at 'lade de 1000 blomster blomstre' og derved satte gang i amternes uafhængige udvikling.
Fordelen ved den decentrale udviklingsmodel var, at rigtigt mange specialister og ildsjæle blev stærkt motiveret af det, og kastede sig ud i EPJ-løsninger, der godt nok stritter lidt i alle retninger, men som også hver især er resultatet af en solid lokal forankring og indsats.
Man forsøgte sig så – lidt sent – med at etablere en fælles arkitektur, den såkaldte G-EPJ, som Sundhedsstyrelsen satte sig for bordenden af. Det blev så af amterne opfattet som centralisme, et forsøg på fra SST's side at styrke sin position overfor amter og senere regioner, så de mange og endeløse diskussioner for at beskytte lokale særinteresserer tog så livet af G-EPJ, der i mange af sine definitioner forudsatte en helt bestemt klinisk arbejdsgang.
Og her står vi så. Vi står i en situation, hvor Danmark er det land i Verden, der har den største penetration af EPJ i hele Verden, vi er foregangsland for Obama, fra hele kloden rejser folk hertil for at se vores moderne sundhedsvæsen. Det har man let tilbøjelighed til at glemme.
Det værste, der kunne ske nu, var at nogen (politikere) kom og sagde, at alle eksisterende EPJ-systemer indenfor 5 år skulle erstattes af et fælles EPJ-system. Det ville virkelig spilde tid og penge – for udviklingen indenfor data analyse er heldigvis gået videre, og det ER allerede i dag en kendsgerning, at der er etableret en landsdækkende e-Journal (Se f.eks. fra region Syd:), der på daglig basis opdateres fra -næsten – alle EPJ-systemer i Danmark med fælles forståelige udtræk og informationer, der i langt de fleste tilfælde giver god mening. Samtidig understøtter e-Journalen kravene til datasikkerhed og privacy. Her er det altså data interface-standarden, der er afgørende, og som sikrer at man fra næsten alle sygehuse kan tilgå den fælles Journal, ovenikøbet ved hjælp at en front end løsning, der kan tilpasses individuelle behov. Moralen er her, at løsninger, der i det enkelte sygehus er kørt ind, accepteret af medarbejderne, som afspejler forskelle i arbejdsgange og kultur udgør en infrastruktur, som det vil være det rene spild at erstatte.
Som kuriosum kan vi nævne, at svenskerne tilsyneladende har lært af vores G-EPJ fejltagelser og nu er ved at etablere en fælles svensk standard, der understøtter individuelle arbejdsgange på de enkelte sygehuse og klinikker.
Åbne Standarder og Snitflader
Den anden virkelige udfordring i Danmark består i at blive enige om hvad en åben standard er. Det fremgik af den pinagtige diskussion om åbne dokumentstandarder, at man her i landet er endda meget tilbageholdne med at vedtage tiltag, der går Microsoft imod.
Når vi skal realisere målsætningen om at gøre de offentlige data tilgængelige for borgere og virksomheder, vil diskussionen blusse op igen med fornyet styrke. I modsætning til idealistiske ønsker om at have én fælles, lovbestemt EA for alle styrelser, ministerier og institutioner, må det næste skridt på vejen rimeligvis være at lave en prioriteret plan for de væsentligste offentlige registre, som vil kunne tilgås og forædles via web 2.0 teknikker, som Apps eller på anden vis bidrage til et højere serviceniveau - og til udvikling af nye IT-nicher.
Kort- og Matrikelstyrelsens grunddata, Danmarks Statistiks arsenal af data, Statens Museum for Kunst og den digitale Kulturarv, Det Kongelige Biblioteks samlinger, Rigsarkivet (der burde have været digitaliseret ved udflytningen), Danmarks Radios lyd- og videoarkiv, alle disse samlinger udgør spændende potentialer, men information og standardisering af interfaces, valg af åbne dataformater og billedformater trænger sig på, for at vi ikke én gang til skal stå i det dilemma, som politikerne åbenbart har så svært ved at skære igennem: Skal vi fortsat være afhængige af leverandørinteresser, eller må vi beholde vores kulturarv selv?
Konklusion
Arkitektur og åbne standarder er to af flere vigtige forudsætninger for at IT-projekter ikke kører af sporet. Men det er ikke de eneste krav, der bør stilles – det er ligeså vigtigt, at udbudsformen og udbuddets krav er tilpasset organisation, arbejdsform, graden af fornyelse som projektet indebærer.
Også hele ledelsesprocessen og ejerskabet, det vi kalder IT Governance, er én af de alvorligste og hyppigt tilbagevendende årsager til flops – man kan ikke outsource god ledelse, især ikke god forandringsledelse. Og man ikke klare den slags med et rejsehold.
Det vil ligeledes være ønskeligt at man i Danmark fik en tradition for at efterspørge standard-løsninger, COTS, hvor det vil give mening, i stedet for endeløse opsummeringer af 'ufravigelige' detaljekrav, som konsulenthuse betales gode timepriser for at identificere. Standardsystemer vil have den fordel, at de udvikles i takt med den samlede brugerskares krav, så når NATO kan have COTS som krav, bør den danske stat vel også kunne benytte det?
Og tilbage til arkitektur og åbne standarder: Arkitekturen skal understøtte forandringsprocessen, ikke fastfryse den. Formålet med arkitekturen er have et udgangspunkt, der kan absorbere, udnytte og tilpasse sig den teknologiske udvikling, uanset hvilken retning denne måtte tage. Og standarder er tilsvarende et middel på rejsen, der skal understøtte valgfrihed og fleksibilitet og forhindre utilsigtede konverteringer.
Efterskrift
Når jeg som illustration i starten viste Siena Domkirke som eksempel på en arkitektur, der er etableret som et blueprinty over hele Europa og er tilpasset organisationen og de funktioner, der er udføres i de enkelte varianter af arkitekturen, så er det ment som et kuriosum. Hvilken organisation kan klare sig uforandret igennem flere hundrede år? Hele pointen med EA er, at den skal være fleksibel, kommunikerbar, skalerbar.
