Mange virksomheter setter i gang nye IT-prosjekter med god intensjon, men uklart utgangspunkt. Hva skjer når fremtiden planlegges før nåsituasjonen er forstått? Eller når veikartet tegnes uten innsikt i virkelige behov? 

I denne teksten deler Levin Løssfelt i Vali praktiske erfaringer fra foranalysearbeid, med fokus på hvordan kartlegge, modellere og planlegge veien fra nåtid til fremtid:

Som løsningsarkitekt har jeg jobbet i flere prosjekter som har kjøpt eller laget nye IT-systemer. Dette har vært et ledd i den kontinuerlige endringen alle organisasjoner må gjennom. Nåtiden er utdatert, og endring er nødvendig for å overleve i fremtiden. 

Rammeverk og metodikk 

De store linjene i denne prosessen er i bunn og grunn like fra prosjekt til prosjekt. Det starter med et behov som må dekkes. Deretter må man kartlegge nåtid, planlegge for den fremtiden man vil til, analysere hva gapet mellom de to er, for så å lage et veikart fra her til der. Kjært barn har mange navn og i vår verden er de fleste på engelsk, erstatt gjerne ordene over med As-Is, To-Be, Gap (forfriskende likt) og Roadmap, om ønskelig.

Denne rekkefølgen er også beskrevet i TOGAF sin ADM (Architecture Development Method), som inngår i The Open Group Architecture Framework. ADM tilbyr et strukturert rammeverk med faser for å utvikle og styre virksomhetsarkitektur, og er spesielt nyttig i prosjekter med behov for forankring på tvers av organisasjon, IT og ledelse. 

Man trenger ikke å benytte alle faser i ADM slavisk, det bør snarere sees som en verktøykasse som kan tilpasses etter behov. Videre finnes det andre relevante rammeverk, for eksempel SAFe (Scaled Agile Framework), som passer godt der arkitektur må samordnes med tverrfaglige agile team, og ISO/IEC 42010, som gir prinsipper for hvordan arkitektur bør dokumenteres. 

Kort sagt: velg et rammeverk du forstår og kan bruke godt. Det viktigste er at det gir struktur, skaper en felles forståelse og kan tilpasses den virkeligheten prosjektet opererer i. 

Behov 

Som konsulent kommer man gjerne inn etter at behovet har blitt definert og oppdraget har blitt lyst ut. Noen ganger har kunden også allerede bestemt seg for løsningen, offisielt eller ikke. Dette behovet kan det være lurt å anse som et utgangspunkt og ikke en fasit. Årsaken er at et behov må forankres i en god forståelse av nåsituasjonen, hvilket man ofte først har etter at kartleggingen er gjort. 

Dette må naturligvis gjøres med respekt for at kunden kjenner seg selv best, men det vil også være respektløst overfor kundens tid og penger hvis man ikke nevner problemer med behovet. I beste fall er det bare en ulik oppfatning av virkeligheten og man har fått økt forståelse, eller så har man oppdaget og avverget et mulig problem.

Illustrasjon: Lopuchin, LiveJournal, 2007 

Konkret hvilke gevinster kunden ønsker å oppnå er heller ikke alltid godt definert. Det gjør det vanskelig når man skal måle gevinstrealisering. Et behov er ikke alltid det motsatte av en gevinst. 

Nåsituasjon 

Det neste skrittet er kartleggingen av dagens situasjon. Her kan det være fristende for effektivitetens skyld å gjøre dette i parallell med planleggingen av fremtiden, dette er dog en fallgruve som jeg kommer tilbake til. Det er ellers flere andre fallgruver i denne fasen. Et eksempel er når kunden sier at de allerede har gjort en kartlegging, eller at de har tilgjengelig dokumentasjon man kan basere kartleggingen på. Selv om det kan være riktig at de har slike dokumenter, er det ikke alltid de kan brukes til kartleggingen. Noen ganger snakker man forbi hverandre om hva som trengs. Eksempelvis kan dokumentasjonen være utelukkende på arbeidsprosesser, mens behovet var av en mer teknisk karakter. 

Eksisterende dokumentasjon er heller ikke alltid tilgjengelig dokumentasjon. Hvis den er fragmentert, vanskelig å lese, osv., kan det være tidkrevende å sammenstille den for bruk. 

Et annet element er at de som jobber med det som skal kartlegges ofte er preget av å nettopp jobbe med det. Man kan ignorere elementer som virker åpenbare eller uviktige. Her kan en utenforstående med friske øyne stille de riktige spørsmålene som trengs for å forstå essensielle elementer. 

En annen viktig ting man som konsulent kan bringe til bords er kunnskap om hvordan både nåtid og fremtid bør dokumenteres. 

Verktøy og notasjoner 

Arbeidsprosesser og systemlandskap bør tegnes i henhold til anerkjente standarder slik at man ikke kommer i en situasjon hvor man er usikker på hva som menes. For eksempel er standardiserte notasjoner slik som BPMN og ArchiMate bra å bruke, da de øker tydeligheten på hva som er beskrevet.  

BPMN (Business Process Model and Notation) egner seg godt til å illustrere prosessflyt og beslutningspunkter, og fungerer spesielt godt i dialog med forretningssiden. 

ArchiMate, på sin side, gir et helhetlig bilde av hvordan forretning, applikasjoner og teknologi henger sammen og er nyttig i arbeidet med tverrfaglig avklaring og gapanalyse. 

Det anbefales også å bruke verktøystøtte for diagrammene, som Sparx Enterprise Architect, Bizzdesign, eller Archi. Dette sikrer versjonskontroll og gir mulighet til gjenbruk i større prosjekter. Det finnes verktøy i flere varianter av kompleksitet og kostnad, så velg det du trenger og ikke mer. 

Diagrammer bør gjerne suppleres med korte tekstlige beskrivelser for å dokumentere beslutninger, avhengigheter og antakelser som ikke fremgår direkte av modellen. Diagrammene er dog i førersetet. At all kartlegging visualiseres så langt det lar seg gjøre, er et suksesskriterium. 

Gevinster 

En kartlegging kan gi flere gevinster, ved siden av å være en viktig bit av en foranalyse. Som nevnt kan kunden ha blitt blind på nåsituasjonen og ikke være i stand til å se skogen for bare trær. Da kan friske øyne finne ting som redundante arbeidsoppgaver og andre lavthengende frukter. Man kan også oppdage muligheter for forbedring innen prosesser eller systemer som kunden ikke hadde tenkt at var aktuelle. 

Sist, men ikke minst, er produktet man sitter igjen med etter kartleggingen, selve beskrivelsen av nåsituasjonen (om det er forretningsprosesser, systemlandskap, eller mer) et nyttig produkt som kunden kan bruke utover det aktuelle prosjektet. 

Forankring 

En viktig forutsetning for en effektiv kartlegging er nær kontakt mellom utførende part og de med kunnskapen. Ofte snakker vi her om konsulenten og de på «gølvet» hos kunden. Forankring skjer best gjennom direkte dialog mellom arkitekten(e) og de som har domeneinnsikt, som ofte er prosesseiere, systemeiere eller nøkkelpersoner i drift. 

En fallgruve er når prosjekteier eller prosjektleder ønsker en for stor grad av kontroll og sier at alt skal gå gjennom dem. For eksempel ved at hen skal motta og videresende alle spørsmål, eller at alle spørsmål tas i møter. En annen grunn er at de aktuelle ressursene ikke kan fritas fra oppgavene sine og at man frykter en fri flyt av spørsmål skal risikere daglig drift. Selv om man gjerne kan sette en viss begrensning på kontakt slik at det ikke sklir ut, så vil det å hindre direkte kontakt gjøre at arbeidet tar vesentlig lenger tid og koster tilsvarende mye mer. 

En siste fallgruve er hypereffektivisering. Dette er ikke unikt for foranalyser, men verdt å nevne. Man må legge inn buffer for at ting ikke går i henhold til plan. Folk blir syke, omfang endrer seg, etc. Hvis man ikke gjør det så må man være komfortabel med å måtte spontant endre planene hvis og når en slik hendelse inntreffer. En type buffer er å unngå overdreven spesialisering. I et prosjekt med flere utførende parter, er det viktig å planlegge for hyppig synkronisering. Hvis ikke kan uoverensstemmelser vokse og bli problematiske i slutten av prosjektet. 

Fremtid 

Planleggingen av fremtiden bør bygge på innsikten fra nåsituasjonen. Å basere løsningen kun på et tidlig definert behov er sjelden tilstrekkelig. Det vil alltid være minimum en endring i arbeidsprosesser og kultur, som regel også i systemer. Derfor er det viktig å forstå nåsituasjonen. 

Hvis man har ressurser til å starte på fremtiden før kartleggingen av nåtid er ferdig, så er det ikke grunnleggende sett galt. Problemet oppstår når man tror det kan gjøres uten å ta hensyn til nåtiden. Fremtidige prosesser og systemer vil nesten alltid måtte ta hensyn til dagens prosesser og systemer. 

Skjulte forutsetninger 

Forslag til fremtiden bør baseres på kundens behov. Dette virker åpenbart, men det innebærer at kunden må ha tenkt gjennom på hvilken måte nåtid ikke innfrir behovet og gjerne også hvordan de tenker at fremtiden bør løse utfordringen. Det er mulig at kunden ikke har noen klare tanker om hvordan fremtiden bør være og heller overlater dette helt og holdent til de som utarbeider forslaget. I så fall må kunden i hvert fall ha tenkt gjennom hvilke rammer de ønsker å sette for fremtiden, eller hva slags endringer som ikke kan aksepteres. Det er bortkastet arbeid om et forslag må forkastes på grunn av en begrensning som kunden glemte å nevne. 

En mulig løsning på dette er at fremtidsarbeidet starter med et arbeidsmøte hvor man i grove trekk diskuterer mulig løsninger som kan gås nærmere opp. Det vil kunne avdekke skjær i sjøen eller andre rammer som kunden har glemt å nevne. 

Iterativt arbeid 

Et annet verktøy for å hindre slike problemer er iterativt arbeid. Med det menes at man jevnlig, for eksempel hver uke, presenterer arbeidet med løsninger slik det foreligger da. Kunden vil da kunne si ifra hvis de ser en begrensning som ikke er tatt høyde for. 

Også fremtidsforslagene bør fremstilles med diagrammer basert på standardiserte notasjoner. Dette bør gjøres likt som kartleggingen av nåsituasjon, da det forenkler gapanalysen. 

Et siste verktøy og kanskje det viktigste, er som nevnt tidligere at de som jobber med fremtiden bør ha nær kontakt med de hos kunden som har kunnskapen. Da kan den utførende umiddelbart ta kontakt hvis det oppstår usikkerhet rundt en mulig løsning. 

Gapanalyse 

Gapanalysen er nok et eksempel på at noe sekvensering (á la fossefall) må benyttes. Analysen kan ikke ferdigstilles før både nåtid og fremtid er ferdig definert. Det er også diskutabelt hvor tidlig det har hensikt å starte med den, da nåtid og fremtid må ha nådd et visst nivå av stabilitet før de kan sammenlignes. 

I tillegg til å sammenligne prosesser og systemer, bør gapanalysen også vurdere hvilke kapabiliteter (f.eks. digital kompetanse, datakvalitet, integrasjonsmuligheter) som mangler eller må styrkes for å realisere fremtiden. Dette gir et mer helhetlig bilde og legger grunnlag for bedre veikart. 

Som regel vil det være behov for én eller flere overgangsarkitekturer, det vil si mellomsteg der gamle og nye løsninger sameksisterer, for å gjøre overgangen både mer forståelig og håndterbar. 

Analysen bør igjen være visuell. Her ser man fordelen av at nåtid og fremtid har blitt fremstilt så likt som mulig, da det gjør det enklere å vise gapet og identifisere hvilke tiltak som må til. 

Veikart 

Veikartet for å nå fremtiden kan gjerne lages i parallell med gapanalysen. For hvert gap man identifiserer kan man se på hvordan gapet kan lukkes. 

Et godt veikart bør beskrive milepæler, rekkefølge på tiltak, teknologiske avhengigheter, og gjerne også en vurdering av endringskapasitet, både teknisk og organisatorisk. Det må også være fleksibelt nok til å tåle justeringer underveis. 

Når gapanalysen og utkastet til veikartet er ferdig, bør man gjennomgå veikartet igjen for å se på synergier i hvordan fremtiden kan oppnås. 

Igjen er det fordelaktig å gjøre dette i samarbeid med kunden, da det også her kan være unevnte rammer for hvordan fremtiden skal oppnås. Det er i denne fasen at det ofte avdekkes at tiltak må justeres for å være realistiske, eller for å skape raskere gevinstuttak. 

Konklusjon 

Oppsummert: Hva bør en løsningsarkitekt huske på?