Formål
Trinet identificerer projekter, der måske ikke er strategiske og en del af enterprise arkitekturen, men som er taktiske og på kort tid og uden en stor indsats kan give en gevinst i form af effektivitet, besparelser og større kvalitet
Input
Alle eksisterende leverancer fra andre aktiviteter i OIO EA kan i princippet indgå som input. Det gælder både AS IS dokumentation og TO BE beskrivelser. Væsentligst er nok dokumentation fra de aktiviteterne der bestemmer opdraget – Vision, mål og strategier (A1), Udfordringer (A2) samt Programmer og projekter(A5) – samt fra aktiviteten Forretningsprocesser (B4) og fra de fire aktiviteter vedrøremde teknisk arkitektur: Informationsarkitektur (C1), Applikationsarkitektur (C2), Servicearkitektur (C3) og Teknologiarkitektur (C4).
Forretningssiden, IT-chef og andre relevante personer kan inddrages, ligesom der løbende kan komme indput fra stort set alle sider (“alle gode idéer er velkomne”).
Output
Output Muligheder – vigtighed og indsats (D2.1).
På EA niveau er det et dokument, der beskriver identificerede ikke-strategiske projekter, og mulige fordele som projekterne kan give. For hver af dem bør man anføre:
- Beskrivelse af projektet – hvad går det ud på?
- Vigtighed/betydning af gevinsten – målt på en høj/middel/lav skala, 1-10 skala eller andet.
- Indsats der skal til for at gennemføre projektet – målt på en høj/middel/lav skala, 1-10 skala eller andet.
- Samlet ”nytte” (vigtighed og indsats holdt op imod hinanden – ”nemme” projekter med høj betydning vil score højt).
- ”Ejer” af muligheden.
- Indstilling – hvad der foreslås gjort for at udnytte muligheden. Denne kan spænde fra en kort note, til et egentlig projektgrundlag.
På løsningsprojektniveau er det grundlæggende samme tankegang, men her er scope naturligvis nærmere delprojekter eller nogle “quick-wins” i forhold til løsningsmuligheder.
I forholdet mellem EA og løsningsprojekter kan det f.eks. betyde, at EA påvirker også igangværende løsningsprojekter med justeringer f.eks. for at opnås quick wins.
Metode
Metoden er egentlig blot at være få sammenfattet og dokumenteret hurtige gevinster, ”lavthængende frugter” som måske ikke er strategiske om fem år, men som på en kort tidshorisont kan tjene sig hjem. Der er altså tale om en anden slags muligheder end de der blev identificeret i aktiviteten Udfordringer og var årsag til at man begyndte EA arbejdet.
Der kan være tale om muligheder der retter sig mod organisatoriske forhold, mod teknologiske, eller andet.
Indsatsområder kan ofte omfatte at se på leverandørforhold – hardware-, software-og service-priser. Er organisationen på vej mod en strategisk arkitektur, der ændrer leverandørernes rolle (enten til at være mere strategisk eller til at være mindre vigtig) vil man ofte kunne genforhandle kontrakter.
Det kan også være konsolidering af f.eks. CMSer til hjemmesider eller genbrug af eksisterende komponenter til eksempelvis brugerstyring eller print.
Andre muligheder kan være af teknisk art; web frontends til applikationer, brug af nye kommunikationsteknologier (IP telefoni, mobile løsninger osv.).
Og det kan gå helt ned på det sproglige med fælles taksoniomier eller det grafiske i visuel stil, brug af skabeloner, ens ikoner o.l.
Det er vigtigt at spørge eksplicit ind til forbedringsmuligheder, bredt i organisationen. Når man udvikler en enterprise arkitektur, kommer man typisk meget rundt i organisationen, og i kontakt med mange med gode ideer, der bare aldrig er nået frem til it-afdelingen.
Når mulighederne er samlet sammen i et dokument, bør man sammen med ”ejerne” af mulighederne og andre interessenter samles (gerne i en workshop) for at prioritere hvilke der bør udføres hvornår.
Gode råd
Man bør løbende dokumentere muligheder efterhånden som de opdages.
Muligheder, specielt dem der går på tværs af projekter og specifikke løsninger, kan lægges under EA governance, hvor de kan lægges i en “back-log” og prioriteres løbende.