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:
- Tillhandahålla fokalpunkt för diskussioner i ämnet
- Bidra till strategiska och taktiska diskussioner och beslut där ramverket är relevant
- Hantera kompetensutveckling och internutbildning
- Samverka med HR, chefer eller utbildningsansvarig
- Ansvara för kunskapsobjekten, dvs böcker, e-learningkurser, abonnemang etc.
- 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
Hej,
SvaraRaderaTack för du att du delar med dig av din kunskap. Jag tycket att din text både var lärorik och intressant samt delar av den fick mig att återkoppla på min egen erfarenhet och kunskap inom ämnet.
Ser framemot att läsa mer
Ha en fortsatt härlig dag
J
Hej Joacim
SvaraRaderaTack för dina vänliga ord. Det uppskattas.
Om det jag skrev triggar dina egna erfarenheter så har jag verkligen lyckats.
Jag återkommer i slutet på nästa vecka med nästa inlägg. Hoppas du orkar läsa det också.
Detsamma!
Jim
Hej igen, Joacim
SvaraRaderaKolla på
http://informatorutbildning.blogspot.se/2014/10/itil-och-agila-metoder-motsatser-eller.html
Nytt och direkt från ugnen.
Ha det
Jim