De som har prosjektert Akson har klart å gjøre noe forholdsvis enkelt og begrenset til et digert, omfattende beist. Til en prislapp opp mot 22 milliarder kroner.
Hvordan er det mulig? Vel, det hjelper godt å prosjektere det som et anleggsprosjekt. Dessuten er det viktig å unngå å snakke med programmerere om saken, og ikke minst å overse brukerne.
Forsinkende avhengigheter
I alt for mange år har IT-bransjen vært opptatt av å finne metoder og strukturer for å klare å håndtere alle bindingene og avhengighetene mellom systemkomponenter. Har man sterke avhengigheter vil teamene måtte vente på hverandre for å kunne fullføre det de jobber med.
Og altfor ofte vil én (liten, begrenset) endring i et system føre til at det feiler andre steder. Alle er altså prisgitt andre de ikke har kontroll på for å gjøre jobben.
Problemet er bare at «andre» ikke prioriterer våre behov – de har sine egne mål og prosjekter som allerede er litt på etterskudd. Så vi må vente. Og presse på. Gjøre noe annet imens. Forsøke å eskalere. Forsøke å multitaske så godt vi kan...
Planer og multitasking
For å håndtere denne situasjonen lages det planer som forsøker å sette opp en optimal rekkefølge slik at hindringer blir enklest mulig å håndtere. Men slike planer er ferskvare, det holder at bare én av de vi er avhengige av får forsinkelser (eller omprioriterer), og korthuset begynner å rase.
Løsningen på all denne kompleksiteten er en mengde prosjektdeltakere som bare jobber med planlegging, rapportering og koordinering. De skaper ikke verdi, bare forsøker å legge til rette for de som faktisk er verdiskaperne.
Og vi ender opp med å forsøke å gjøre mange ting i parallell. Når vi blir blokkert ett sted setter vi det på vent - og starter på noe annet i stedet.
Smidig de neste 20 år – når verden blir mindre kommer polene nærmere hverandre
Programmerere hater avhengigheter
Jeg lærte programmering på UiO, IFI på 1980-tallet. Vi lærte blant annet å verdsette lav kopling («low coupling») og høy kohesjon («high cohesion») i programmene våre.
Alle utviklere ønsker å kunne fullføre det de har startet på uten hindringer og venting på andre.
Løsningen på dette er å designe systemene slik at avhengighetene (coupling) er svake og ikke sterke. Og vi lærte å forsøke å holde stabile ting adskilt fra områder der vi forventet høy endringstakt. Det er viktig å kunne gjøre raske, små oppdateringer uten å måtte berøre hele systemet.
Flyt
Det hele dreier seg om å skape flyt i arbeidet. Hver gang man blir forhindret fra å fullføre det man har startet på brytes flyten, og man mister fokus og fart. Dette tvinger en til å multitaske og å bruke tid og krefter på å koordinere arbeidet med folk som ikke har samme mål.
Disse hindringene finner vi på individuelt nivå, på team-/prosjektnivå og på «programnivå». Man kan oppleve at hele prosjekter settes på vent (eller må omprioritere) på grunn av hindringer man ikke har kontroll på.
Vi har nå 15 år med erfaring fra smidige metoder, Lean og Scrum innen IT. Her er det fokus på å gi sterke, tverrfaglige team de kapabilitetene de trenger for nettopp å kunne fullføre det de har startet på.
Får de myndighet (slippe å vente på å «få lov»), gode ferdigheter, kompetanse, metoder, god samhandling, og så videre, er mye gjort. Men ikke alt. Hvis de jobber på en systemarkitektur med for sterke koblinger de ikke kontrollerer selv, hjelper disse kapabilitetene lite.
I Scrum er det stort fokus på å fjerne hindringene («remove impediments») etter hvert som man støter på dem. På den måten kan en gammel, monolittisk systemarkitektur gradvis gjøres mindre smertefull å jobbe med.
Men det beste er jo å unngå å lage monolitter i første omgang.
Usmidig om agile arbeidsmetoder
Bør tilpasses ved behov
Innen prosjektstyringsfaget er det naturlig å bygge opp leveranser «nedenfra og opp». Prosjekter skal jo tradisjonelt ende opp med noe «fysisk», noe som har masse og som er underlagt vanlige fysiske lover: Fundament først, så reisverk, så kabler/rør og lignende, deretter overflatebehandling, etc.
Software har ikke masse. Software kan enkelt endres, korrigeres og tilpasses ved behov. Det kan bygges «sidelengs» fremfor «oppover».
Dette gir en rekke muligheter andre prosjekter bare kan drømme om.
Det betyr for eksempel at vi i mye større grad kan prioritere basert på brukernes behov. Hvilke brukergrupper er viktigst akkurat nå, og hvilke behov er mest presserende for dem?
Det er trygt å starte raskt, for vi tar ikke på oss så store forpliktelser av gangen. Akson kunne vært startet for 4-5 år siden, og allerede skapt verdi for mange av brukergruppene.
Det kan finansieres løpende. Det betyr også at vi kan eksperimentere med liten risiko. Husk at brukerne ikke alltid er i stand til å artikulere akkurat hva de har behov for. De må ofte prøve det før de kan uttale seg om hvor godt det fungerer.
Vi sikrer oss brukernes feedback og korrigerer raskt for å treffe enda bedre, og plutselig har vi en arbeidsform som er mer basert på læring enn på å følge en plan.
Deler uten brukerverdi
Jeg kan ikke forstå at vi skulle behøve å starte fra grunnen av. Det ligger allerede mye data godt lagret med god forvaltning allerede. Disse kan man bygge videre på, i stedet for å skulle flytte dem inn i en felles stor lagringsplass. Nøkkelen er gode, trygge API-er, og innovasjon drevet av brukernes behov.
Dette innebærer også at vi må fjerne oss fra ideen om å først skulle lage «fundament» og andre «byggeklosser» før vi begynner å levere verdi til brukerne.
Akson-prosjektet har vært under planlegging i over fem år, og har til hensikt å bruke ytterligere mange år på å lage «plattform» før brukerne kobles inn og kan begynne å høste av verdiene som er skapt.
Dette er et godt eksempel på at man appliserer «tradisjonell prosjektstyring» på IT, og med andre ord går glipp av de fordelene software har. Christine Bergland, direktør i ehelse tar her til orde for å gjennomføre Akson med flere ulike anbud:
- Journalplattform
- Forvaltning av identiteter og rettigheter
- Utvikling av grensesnitt og integrasjoner
- Applikasjonsdrift og forvaltning
- Driftsplattform
- Kompetanse- og kapasitetsforsterkning
- Tilleggsfunksjonalitet
Fint selvsagt å «dele opp elefanten», men ingen ting på denne lista vil skape brukerverdi, og illustrerer godt at Akson blir prosjektert som om det var i bygg-/anleggs-sektoren og ikke IT. Brukerne kommer i annen rekke, dessverre.
Sintef-forsker: Både hjemmekontor og kveldsjobbing kan være bra
Bør lages «utenfra og inn»
Som Christin Gorman har vært inne på flere ganger, er det viktig å dele inn systemene og prosjektene ut fra brukernes behov framfor en «plattform»-tankegang. Og hvis man legger opp til at en slik plattform skal implementeres med «tilpasset hyllevare» risikerer man jo at alt og alle får sterke avhengigheter av en diger monolittisk sak i midten.
Dette fordrer store prosjektorganisasjoner med forholdsvis få verdiskapere, og desto flere prosjektledere og koordinatorer. Og det vil naturligvis gå ut over flyten, føre til multitasking og kreve mye kalendertid.
I stedet tenk: Hvilke brukergrupper er det som er mest desperate etter en velfungerende journalløsning? Er det ambulansepersonell? Tannleger? Fastleger? Anestesi?
Jeg aner ikke, men det er fullt mulig å starte der behovet er størst, for deretter å gradvis lage en omfattende journalløsning for kommunene «utenifra og inn», gjennom å ta for seg brukergruppe for brukergruppe. Sterke, tverrfaglige, smidige team kan da jobbe ganske uforstyrret og fokusert i direkte kontakt med brukerne: Fin flyt, få hindringer! Og enkelt å utvide tannlege-appen uten å forstyrre andre.
En moderne IT-struktur
Ønsker man systemer som inviterer til innovasjon, videreutvikling og enkelt vedlikehold, og som raskt kan skape verdi, må man følge prinsippene om lav kopling og høy kohesjon. Det er ikke noe i veien med plattform-tanken, så lenge denne plattformen i bunn er enklest mulig (gjerne «hodeløs», som Espen Andersen kaller det).
Man bør skille data og prosess. Data kan lagres og forvaltes der de faglig sett hører hjemme. I sky eller ikke – det skal ikke brukerne eller applikasjonsutviklerne behøve å tenke på.
Definer enkle, men klare, API-er som uten unntak må brukes for å lese/oppdatere data. Dette legger til rette for et velfungerende digitalt økosystem, som Professor Bendik Bygestad tar til orde for i Dagens Medisin.
På denne måten kan man invitere private og offentlige aktører til å lage applikasjoner for bestemte brukergrupper som da vil få gode, brukervennlige løsninger for sine behov.
Det er fortvilet å stå og se på at man fremdeles ikke evner å utnytte programmererne bedre her i landet.
Vi har en mengde drevne, gode utviklere, med evne til å se det store bildet, og er mer opptatt av brukerne enn av sin egen kode. Hvorfor blir ikke disse tatt med på råd?
Hvorfor får konsulenter fra PwC (som tydeligvis ikke har forstand på IT-utvikling) så stor makt i beslutningsprosessene? Og hvordan kan kvalitetssikrere fra A-2 og Holte gi en god pekepinn på om Akson er liv laga, når premisset er at det skal lages en plattform?
Det mest betenkelige i denne prosessen er kanskje hvorfor i all verden en smidig tilnærming basert på enklest mulig «plattform» ikke en gang var ett av de tre alternative konseptene i konseptvalgutredningen fra 2018!
IT-bransjen om digitaliseringsstrategien: Ambisiøse mål, men lite konkrete planer
