ITIL – koppling till andra ramverk

Det finns mycket kunskap och erfarenhet kring hur infrastruktur ska sättas ihop och driftas, hur applikationer ska utvecklas och sättas in i produktion, IT-tjänster flyttas från egen regi till outsourcingleverantör och från egen hårdvara till molnet. Delar av dessa kunskaper och erfarenheter paketeras i formen av ramverk och modeller.
Jag tänker försöka ge några tips och betraktelser från denna märkliga värld. I denna första del ger jag mina två cent kring hur man kan förhålla sig till ramverk och kunskapskällor generellt. I nästkommande kommer jag att, mycket kortfattat, beskriva omfattning, syfte och position för några av de vanligast förekommande ramverken inom IT-världen och hur de kopplar till ITIL. Från min horisont, kanske ska påpekas. Ramverk och modeller som kommer hanteras inkluderar Cobit, Devops, Togaf, Lean, KCS samt agila metoder.
Jag hoppas att du som läser detta finner det värdefullt och du kanske till och med kommenterar det jag skriver.
I resonemanget kring ramverk och modeller kommer jag att förhålla mig till en utgångspunkt: 
Själva poängen är att leverera värdefulla IT-tjänster till kunder som får det utfall de vill och behöver. IT-tjänsterna ska levereras på ett kvalitativt och kostnadseffektivt sätt. 
Allt annat kommer att vara sekundärt. Om inte ovan gäller, är inget annat intressant eller användbart.
Konceptet kallas ”IT Service Management” eller ”ITSM”. Vikten av effektiv ITSM går inte att överskatta. ITIL som ramverk för ITSM är väl känt och spritt, men har i de flesta svenska organisationer inte levt upp till sin fulla potential. Anledningen till det är ämnet för ett annat blogginlägg.
Förutom ITIL finns det andra ramverk och modeller för att sprida kunskap och erfarenheter kring delar av ITSM. En del har några år på nacken och har fått positionera och formulera om sig i förhållande till nya tider i allmänhet och ITIL och ITSM i synnerhet. Andra är yngre och har det redan i sig från start. Ytterligare andra missar sin positionering.
En utgångspunkt för allt detta är att det finns oerhört mycket kunskap och erfarenhet kring väldigt många områden inom IT. Mycket mer än vad en enskild människa kan greppa och använda sig av på ett vettigt sätt. Man kan däremot välja att antingen bli lite bättre på vissa saker och inte på andra - det kallas specialist – eller så blir man bredare och grundare i sina kunskaper – det kallas konsult! Eller generalist.
Skämt åsido – det är viktigt för oss konsulter att vara tydliga med vad vi faktiskt kan bidra med, specialistkompetens eller generalistkunskap. Och vad den är bra för. Igen, ett annat blogginlägg. 
För att få maximal nytta av ramverk och modeller är det viktigt att anamma dessa under ordnade former.  
Ordnade former betyder att organisationen tydliggör, på lämpligt sätt, vilka ramverk som organisationen använder sig av och i stora drag hur de ska bidra till verksamheten.
Ibland, tyvärr ganska ofta, sker detta på mindre ordnat sätt. Någon initiativrik person hittar en källa till kunskap, tycker att den verkar bra och börjar sedan använda och tillämpa på sin egen del av verksamheten. Inget ont i detta, men kanske inte så effektivt. I bästa fall.
Vill det sig lite värre så är personen i fråga ännu mer företagsam och lyckas få med sig andra och en del av budgeten i investeringar och kostnader som helt enkelt inte borde uppstå.
Detta kan gagna individers roll, rykte och karriär samt ge värdefulla kunskaper och åsikter. Men, det är inte optimalt för organisationen som helhet.
En god idé är att få ned en förteckning över vilka ramverk och andra källor till kunskap som organisationen ska använda (eller redan börjat använda?) samt hur de ska användas. Om det är något som används mycket och ofta, in på listan med det. Om det används sparsamt och inte så ofta – ta inte med det. Sätt upp mål kring vad som ska göras med de ramverk som är på listan. Att vara på listan betyder att det är värt att förvaltas. Och tvärtom.
De ramverk som hamnar utanför listan är givetvis tillgängliga vid behov ändå, men förmodligen inte så lätt, snabbt och tillämpbart som det som är på listan. Och givetvis bör man kunna ändra sig och ta bort respektive lägga till ramverk under resan.
Att positionera ramverken och tydliggöra vilken omfattning och avgränsning som de har hjälper också till. Kan man dessutom tala om vem som ska arbeta med det är det ännu bättre. Det börjar dra ihop sig till en checklista: 

• Identifiera vilka ramverk som organisationen ska använda
• Sätt kriterierna innan, se ovan
• Tillsätt någon som ansvarig/ägare
• Om detta blir svårt för att ingen är intresserad, så är det förmodligen ett ramverk som inte ska vara på listan 
• Positionera, sätt omfattning och avgränsning
• Tydliggör i era processer hur ramverket ska tillämpas

Vad ska då en ansvarig/ägare av ett ramverk göra? Tja, förutom att åka på härliga, långväga konferenser, köpa roliga böcker och gå på kurser i ämnet finns det ett antal punkter som borde fungera:

1. Tillhandahålla fokalpunkt för diskussioner i ämnet
2. Bidra till strategiska och taktiska diskussioner och beslut där ramverket är relevant
3. Hantera kompetensutveckling och internutbildning
4. Samverka med HR, chefer eller utbildningsansvarig
5. Ansvara för kunskapsobjekten, dvs böcker, e-learningkurser, abonnemang etc.
6. Ansvara för förvaltningen av ramverket, uppdateringar, kompletterande kunskap och analys av tillämpningar

För vissa ramverk, exempelvis Togaf, är det naturligt att det hanteras av olika arkitektroller. Arkitekter av olika ordning brukar tycka att det är naturligt att skriva policies och riktlinjer samt instruktioner hur riktlinjerna ska tillämpas. Det är ett bra arbetssätt, särskilt när det kombineras med starka, mogna processer. Så borde fler områden hanteras. En ”service transition policy” skulle kraftfullt och tydligt kunna sätta spelreglerna för all driftsättning, releasehantering, beslutsfattande etc.
Sammanfattningsvis, positionering av ramverket och dess tillämpning är viktigt. Att tydligt kunna peka ut i vilka frågor som kunskapen, riktlinjerna från respektive ramverk ska användas.
Som sagt, syfte med detta inlägg har varit att positionera ramverk rent generellt. Nästa inlägg kommer konkretisera hur ITIL förhåller sig till agila metoder.
Skicka gärna dina kommentarer kring detta. Jag uppskattar det mycket.
Hälsningar

Jim Lindfors

Verksamhetskonsult och utbildare