What do ITSM and SAM have to offer each other?

Many of us working in the IT sphere have heard about ITSM and the ITIL Framework that puts best practise into wording. There are plenty of other frameworks and manifestos that also claim their piece to describe the same and other parts of IT’s reality. In this wealth of solutions and beliefs, I do miss a more wide spread discussion on one, in my view critical, part of IT.

The part that for most organisations stands for the same amount of money as personnel, i.e. their software expenditure. For most industries it stands for 30% of their IT budget and with an ongoing digitalisation and service-orientation, this has been and will be increasing. So in my view how to manage this part of IT effectively and efficiently deserves a spot among the books on DevOps, Agile, etc.

Because whether it’s a traditional purchased client-application, a hired server-license or some cloud solution, the way we need to manage these assets is still the same. The legal, financial, architectural and operational implications are as demanding and IT needs to deliver their part in a cost efficient and value-adding manner.

I am by far an IT Asset or License expert, but I do know that doing the right things in the right way benefits the business and bottom line. And this requires working with people, processes and tools, managing change. I had the opportunity to work with Software Asset Management issues for the first time some 6 years ago. Having worked a few years with ITSM and with some background in ISO9001 and CRM, our newly appointed License Manager and I embarked on a journey with the appropriate ISO Standard in our bags. As we proceeded a number of things became apparent to us:

-        An organisation can only take in a certain amount of new terminology and adapt to new ways of working. Managing organisational change for SAM is as critical as for ITSM. SAM affects all users in an organisation! Be considered.

-        Clear governance, stipulating policies, objectives, roles, responsibility and mandates is critical

-        A number of processes defined by the ISO 19770-1 are in principle the same as what ITIL describes. It would be a waste of time and resources not to make sure to incorporate SAM requirements into the existing ITSM processes.

-        In particular working with (Software) Asset identification and control, shows how determined one has to be if/when embarking on Configuration Management with probably an even larger scope.

-        Another area of SAM that plays a forefront role is Supplier and Contract Management. Handle it well and it will serve you well

-        At that time acquiring knowledge and sharing experience on SAM seemed, compared to the ITSM/ITIL community, almost non-existing or only available through software vendors.

-        Then also tools for inventory, metering, etc. to help SAM were in an early stage of the hype cycle. Good enough to support specific tasks for License Management, but not management tools that can streamline workflows and decision making.

Due to organisational changes we both engaged in other challenges, but while years passed these thoughts remained in the back of my mind. The last 2 years as an ITSM consultant I have had the opportunity to meet with many more organisations and it is clear that many still struggle (more or less conscious) with ITSM and SAM duties and initiatives not being synced.

While SAM overall was clearly less mature 6 years ago, it has gained traction. Then the methods and concepts to extend the ISO standard came primarily from the vendor side like Microsoft’s MOF. Now there is a recognised independent framework from IAITAM and the tools to support it have improved considerably. At the same time more and more the broader term ITAM is being used instead of SAM, including all IT-related Assets, like hardware, in the approach. And for what it’s worth it, ITIL has clearly sated SAM/ITAM is a critical element of successful IT Service Management.

While ITIL/ITSM, with all right, talks a lot about the importance of organisational capabilities, SAM has a much stronger case for why these should be up to specs: incompliance has tangible legal and direct financial consequences. So while audits (external or internal) can be regarded by some as a blessing to tidy things up once every now and then, the more mature License and Software Asset Managers whish for a more continuous management and continual improvement: to build and manage organisational capability. Within logistics no one closes down a distribution centre to do a yearly inventory. Stock taking is performed daily and integrated with other logistic duties.

The need for management of change becomes evident. Nothing major, rather an evolution that actually also can enrich the ITSM practises of an organisation and help to quantify benefits in monetary terms and risk management, something the CFO will like.

It means taking advance of existing implementation and process capabilities by involving for example your Service Level Manager(s) and Change Manager(s) in the adoption of existing processes to specific requirements from SAM. And be aware the benefits are in either direction: While adding SAM-oriented Change Models will help to make the “ITSM-based” Change Management more complete, data from Incidents and Service Requests will give an extra dimension to Asset data, when meeting suppliers during renegotiations.

This does indicate a certain maturity of the IT organisation, to be able to take advantage of the ITSM capabilities for SAM. But any CIO with a long term vision and strategy to contribute to the bottom line should include the opportunity given by matching these 2 practices once passed the phase of establishment.

//Maarten Merckx
Verksamhetskonsult på Olingo Consulting och ITIL utbildare hos Informator

Vill du lära dig mer om SAM kopplat till ITIL? Då är kursen  ITIL Lifecycle -Service Transition ett steg i rätt riktning. Klicka här för att se hela Informators utbud inom ITIL och ITSM.

Läs mer

Införande av nya arbetssätt - hur hanterar man bieffekterna av det?

AlmostAsleep AB har under sin VD:s och CIO:s ledning i stor enighet fattat beslut att införa ett nytt arbetssätt på sin IT-avdelning! Det här blir succé! Inte bara ledande personer och nästan alla andra på IT-avdelningen. Denna gång även den normalt något IT-frånvända verksamhetssidan är eniga om att detta är vägen framåt. Projekt har startats med upphandling av tjänster och produkter. Man har också investerat i utbildning i nya system och dessutom nya processer. 

Men så sakteliga börjar det gå upp för några att detta faktiskt kommer att börja påverka deras vardag och invanda mönster. Insikten i att morgondagen (bokstavligt talat!) kommer att se annorlunda ut börjar sätta sig i magen och många frågor börjar ställas. Ett veritabelt Shakespeare-drama tar sin början!

Det som ska genomföras har redan motiverats teoretiskt och precis som i de flesta företag går det relativt lätt även för AlmostAsleep AB att få acceptans för förbättrade arbetssätt. Det CIO:n inte har förutsett är att konsekvenserna av en förändring av arbetssätt innebär också en mer genomgripande förändring för de människor som direkt eller indirekt berörs av den. Förändringen på IT-avdelningen sätter fart på krafter som slår an djupt nedärvda sociala behov och förmågan att hantera dessa kan avgöra i vilken utsträckning förändringen lyckas eller ej.
När man gör en organisationsförändring kommer den i de flesta fall påverka någon eller alla av:

• Ledning och Styrning – Nya arbetssätt kan medföra att maktpositioner förändras. En person som tidigare varit en nyckelspelare vid beslutsfattande kan få sitt ansvar halverat. För AlmostAsleep AB:s chefsarkitekt leder den nya rollen till att hennes tidigare mandat plötsligt delas upp på två där en ny person med fokus på digitalisering anställs, hon får ta ansvar för legacy-systemen och en ny person anställs som chefsarkitekt för att hålla samman.

• Ledarskap – Ett nytt arbetssätt innebär många gånger att ett nytt ledarskap krävs. AlmostAsleep AB:s huvudsaklige tekniskt lösningsansvarige har byggt en lång karriär på bolaget på stor insikt i den tekniska plattformen och förmågan att driva både förvaltning och nyutveckling på legacy-systemen. Nu förändras i ett slag arbetsuppgiften till att leda sin gruppering i förflyttningen från ett ansvar i att bygga tekniska lösningar till att vara ansvariga för att kravställa och följa upp leverantören för den tilltänkta outsource:ade leveransen.

• Kompetens – Den tid vi lever i ställer historiskt höga krav på snabb kompetensanpassning för att motsvara företagens kontinuerligt skiftande behov. På AlmostAsleep AB finns t ex Lasse som precis överlevt småbarnsåren, men inte helt hängt med i teknikutvecklingen under tiden. Utvecklingen har möjliggjort för verksamhetssidan att gå direkt till leverantören utan IT som mellanhand. Lena å andra sidan har ytterligare några år på CV:t och har för länge sen slutat ”gå på kurser som ändå bara blir ytterligare en pärm som står och dammar i hyllan”. De är båda exempel på bristande förmåga och vilja att lära sig nya tekniker och kanske helt kunna skifta arbetsområden.

Jag tror inte att något av detta är nytt för någon, men jag förvånas om och om igen över att så få organisationer väljer att på riktigt proaktivt ta tag i frågan och planera för dess genomförande då effekterna av ett misslyckat hanterande av detta kan vara förödande för både den framtida förändringen, men kanske även för andra delar av organisationen.

Hur ska man då angripa detta? Vad är det för frågeställningar man står inför? 

• Hur förändra ansvarsförhållanden och maktpositioner för personer utan att motverka förändringsviljan?
• Hur möjliggör man både formellt och informellt ledarskap som kan driva förändringen mot målet?
• Hur säkerställa kompetenshöjningen men också den oundvikliga frågan om hur man hanterar den nuvarande personalen som kanske inte varken vill eller kan möta de nya kompetensbehoven?

Min bild av detta är att faktiskt inse att detta är frågeställningar som oundvikligen kommer att behöva hanteras. En annan aspekt är att också hantera det på ett strukturerat sätt – även om det är ”ostrukturerad materia” (=människor) som behöver hanteras. Verktygen för detta är Analys och planering, Ledarskap och Mod.

• Analys och planering - Gör en analys av nuläge och önskat läge som omfattar var förändringen av beslutsmandat kommer ske, vilket kompetensbehov och kompetensöverskott man kommer att ha samt vilka nuvarande personer och roller som kommer att vara nyckelroller både under förändringen och efter genomförandet.
• Ledarskap - Det kommer att vara många utmaningar som kommer ställa krav på tydligt ledarskap i hantering av missnöje och motstånd, men kan också uppstå i mer formella chefsuppgifter som personalavveckling och konflikthantering. Högre chefer och ledning behöver också skapa arenor för underställda chefer och informella ledare att agera inom trots att de kan vara mer utsatta när misstag görs som en följd av en ny och delvis okänd miljö.
• Mod - Slutligen och kanske en basplatta för hela förändringen: Mod. Vi har alla sett dessa situationer i större och mindre utsträckning. Att gå igenom en sån fas med ett realiserat resultat, men förhoppningsvis också en positiv organisation kräver styrka, uthållighet och som sagt, mod.

Naturligtvis är detta en väldigt övergripande betraktelse, men jag tror att många med mig – både som genomförande konsulter och chefer och ledare i en organisation – kan dela huvuddragen i den. Och även om det är svåra och stora saker så inspirerar det i alla fall mig dagligen att försöka bemästra Shakespeare-spektaklet samtidigt som jag stöttar bolag i att arbeta bättre och smartare.

Här hittar du Informators utbildningar inom IT, projektledning och ledarskap.

 

Christian Wahlström är senior projekt- och förändringsledare hos Olingo samt kursledare. 

Läs mer

Munnen säger Agil – hjärnan säger Stabil

Under århundraden har människan strävat efter förbättringar av och i sin omgivning. Samtidigt är människan av sitt genetiska ursprung präglad att inte vilja förändras.

Vi har nedärvt att förändringar belastar energiförråden. Inte bara fysisk energi utan även mental energi. Den insikten ligger djupt rotat i vårt medvetande. Att göra som man alltid gjort är mycket energisnålt i jämförelse med att förändra eller lära sig på nytt. Det är därför våra hjärnor i regel reagerar negativt på förändring. Vi vill inte förändra oss men det paradoxala är att vi vill att andra ska göra det.

Vi läser i media dagligen om att vi vill få saker utförda snabbare och få leveranser oftare. Vi ropar alla efter agila arbetssätt. När det gäller systemutveckling är detta en regel. När det gäller tjänsteutveckling vanligt. Men hur är det när det gäller verksamhetsutveckling? Kan vi utveckla förmågan att förändra vår verksamhet snabbare? Kan vi bli agila här också? Hur kan vi arbeta med att ändra människors vanor och arbetssätt agilt? Vad säger vår hjärna om vi inför agil verksamhetsutveckling? Förmodligen nej, aj, och stop, om vi gör fel. Förmodligen ja, ja och ja om vi gör rätt.

Jag tror att vi absolut kan utveckla verksamheter agilt. Det kommer att vara nödvändigt för att vara konkurrenskraftig och en förutsättning för att kunna attrahera duktiga medarbetare. Nyckeln är att skapa ett engagemang och en trygghet i förändringarna. Att bygga på vilja, nyttor, gemensamma värderingar och vision. Man behöver också bygga in i sin kultur, och i var och ens medvetande, att förändringar är bra och att det är nödvändigt att utmana sitt sätt att arbeta.

Idag råder det ingen brist på ramverk, modeller och metoder för att arbeta med förändringsledning, processutveckling, effektivisering och lärande team. Kunskap om dessa är naturligtvis viktigt, och skapar en bra grund för agil verksamhetsutveckling. Det som är än mer viktigt är istället att hitta den takt verksamheten är mogen att ta emot förändringar i, för att de ska bli varaktiga och ge önskad effekt. Och att successivt öka den takten. Det agila handlar om att göra små justeringar ofta, följa upp resultatet och korrigera. Mer pull än push.

Traditionellt har vi utvecklat våra verksamheter genom stora omorganisationer och andra strukturförändringar som krävt mycket initialt arbete och en massiv förankringsprocess för att skapa acceptans. När den nya organisationen är operativ är den troligtvis till vissa delar redan föråldrad.

En sak som ibland slår mig är att många organisationer har hela avdelningar för att förvalta sina tillgångar. Ekonomiavdelning, HR-avdelning, upphandlingsavdelning och säkerhetsavdelning. Det är däremot ganska ovanligt att man har en avdelning som arbetar med metod-, process- och verksamhetsutveckling. Verksamhetsutvecklingen är ofta begränsad till vad ledningsgrupper mäktar med att genomföra.

Verksamhetsutvecklingen behöver lämna ledningsnivån och delegeras till den operativa verksamheten. Den operativa verksamheten behöver ta emot och acceptera ansvaret att ständigt utföra förbättringar i linje med organisationens vision, strategi och som är värdeskapande. Ledande personal behöver skapa engagemang och en vilja att hitta fel och förbättringsområden. Alltid belöna när fel upptäcks. Frigöra tid för korrigering och hitta rätt takt i förändringsarbetet.

Vikla fle grö du igad?


Ragnar Eliasson arbetar på Olingo Consulting som verksamhetsutvecklare och är ackrediterad kursledare inom ITIL hos Informator. Han använder en blandning av ramverk, modeller och metoder i sina uppdrag. Exempel på det är förändringsledning genom ADKAR, Service Management med stöd av ITIL samt kulturförändring och optimering genom Lean for Services.

Fördjupning i området hos Informator:

ITIL® Lifecycle - Continual Service Improvements
Lean Agile Change Management

Läs mer

Införande av nya arbetssätt – Hur hanterar man bieffekterna av det?

AlmostAsleep AB har under sin VD:s och CIO:s ledning i stor enighet fattat beslut att införa ett nytt arbetssätt på sin IT-avdelning! Det här blir succé! Inte bara ledande personer och nästan alla andra på IT-avdelningen. Denna gång även den normalt något IT-frånvända verksamhetssidan är eniga om att detta är vägen framåt. Projekt har startats med upphandling av tjänster och produkter. Man har också investerat i utbildning i nya system och dessutom nya processer.

Men så sakteliga börjar det gå upp för några att detta faktiskt kommer att börja påverka deras vardag och invanda mönster. Insikten i att morgondagen (bokstavligt talat!) kommer att se annorlunda ut börjar sätta sig i magen och många frågor börjar ställas. Ett veritabelt Shakespeare-drama tar sin början!

Det som ska genomföras har redan motiverats teoretiskt och precis som i de flesta företag går det relativt lätt även för AlmostAsleep AB att få acceptans för förbättrade arbetssätt. Det CIO:n inte har förutsett är att konsekvenserna av en förändring av arbetssätt innebär också en mer genomgripande förändring för de människor som direkt eller indirekt berörs av den. Förändringen på IT-avdelningen sätter fart på krafter som slår an djupt nedärvda sociala behov och förmågan att hantera dessa kan avgöra i vilken utsträckning förändringen lyckas eller ej.
När man gör en organisationsförändring kommer den i de flesta fall påverka någon eller alla av:

• Ledning och Styrning – Nya arbetssätt kan medföra att maktpositioner förändras. En person som tidigare varit en nyckelspelare vid beslutsfattande kan få sitt ansvar halverat. För AlmostAsleep AB:s chefsarkitekt leder den nya rollen till att hennes tidigare mandat plötsligt delas upp på två där en ny person med fokus på digitalisering anställs, hon får ta ansvar för legacy-systemen och en ny person anställs som chefsarkitekt för att hålla samman.

• Ledarskap – Ett nytt arbetssätt innebär många gånger att ett nytt ledarskap krävs. AlmostAsleep AB:s huvudsaklige tekniskt lösningsansvarige har byggt en lång karriär på bolaget på stor insikt i den tekniska plattformen och förmågan att driva både förvaltning och nyutveckling på legacy-systemen. Nu förändras i ett slag arbetsuppgiften till att leda sin gruppering i förflyttningen från ett ansvar i att bygga tekniska lösningar till att vara ansvariga för att kravställa och följa upp leverantören för den tilltänkta outsource:ade leveransen.

• Kompetens – Den tid vi lever i ställer historiskt höga krav på snabb kompetensanpassning för att motsvara företagens kontinuerligt skiftande behov. På AlmostAsleep AB finns t ex Lasse som precis överlevt småbarnsåren, men inte helt hängt med i teknikutvecklingen under tiden. Utvecklingen har möjliggjort för verksamhetssidan att gå direkt till leverantören utan IT som mellanhand. Lena å andra sidan har ytterligare några år på CV:t och har för länge sen slutat ”gå på kurser som ändå bara blir ytterligare en pärm som står och dammar i hyllan”. De är båda exempel på bristande förmåga och vilja att lära sig nya tekniker och kanske helt kunna skifta arbetsområden.

Jag tror inte att något av detta är nytt för någon, men jag förvånas om och om igen över att så få organisationer väljer att på riktigt proaktivt ta tag i frågan och planera för dess genomförande då effekterna av ett misslyckat hanterande av detta kan vara förödande för både den framtida förändringen, men kanske även för andra delar av organisationen.

Hur ska man då angripa detta? Vad är det för frågeställningar man står inför?

• Hur förändra ansvarsförhållanden och maktpositioner för personer utan att motverka förändringsviljan?
• Hur möjliggör man både formellt och informellt ledarskap som kan driva förändringen mot målet?
• Hur säkerställa kompetenshöjningen men också den oundvikliga frågan om hur man hanterar den nuvarande personalen som kanske inte varken vill eller kan möta de nya kompetensbehoven?

Min bild av detta är att faktiskt inse att detta är frågeställningar som oundvikligen kommer att behöva hanteras. En annan aspekt är att också hantera det på ett strukturerat sätt – även om det är ”ostrukturerad materia” (=människor) som behöver hanteras. Verktygen för detta är Analys och planering, Ledarskap och Mod.

• Analys och planering - Gör en analys av nuläge och önskat läge som omfattar var förändringen av beslutsmandat kommer ske, vilket kompetensbehov och kompetensöverskott man kommer att ha samt vilka nuvarande personer och roller som kommer att vara nyckelroller både under förändringen och efter genomförandet.
• Ledarskap - Det kommer att vara många utmaningar som kommer ställa krav på tydligt ledarskap i hantering av missnöje och motstånd, men kan också uppstå i mer formella chefsuppgifter som personalavveckling och konflikthantering. Högre chefer och ledning behöver också skapa arenor för underställda chefer och informella ledare att agera inom trots att de kan vara mer utsatta när misstag görs som en följd av en ny och delvis okänd miljö.
• Mod - Slutligen och kanske en basplatta för hela förändringen: Mod. Vi har alla sett dessa situationer i större och mindre utsträckning. Att gå igenom en sån fas med ett realiserat resultat, men förhoppningsvis också en positiv organisation kräver styrka, uthållighet och som sagt, mod.

Naturligtvis är detta en väldigt övergripande betraktelse, men jag tror att många med mig – både som genomförande konsulter och chefer och ledare i en organisation – kan dela huvuddragen i den. Och även om det är svåra och stora saker så inspirerar det i alla fall mig dagligen att försöka bemästra Shakespeare-spektaklet samtidigt som jag stöttar bolag i att arbeta bättre och smartare.

Här hittar du Informators utbildningar inom IT, projektledning och ledarskap.

 Christian Wahlström är senior projekt- och förändringsledare hos Olingo samt kursledare. 

Läs mer

ITSM-verktyg - do's and don'ts

Jag har ofta fått frågor som ”Finns det ett verktyg som kan lösa det här?” ”Behöver vi verkligen ett verktyg till?” ”Vilket verktyg är bäst?” Jag har inte alla svaren, men lite erfarenhet kan jag dela.

Till att börja med tänkte jag definiera vad jag menar med ITSM-verktyg. Oavsett var i en IT-organisation man arbetar behöver man stödverktyg, oftast applikationer, som hjälper till i IT-leveransen. Det kan vara verktyg som används i samband med utvecklingen av IT-tjänster eller verktyg för att hantera drift och support. De verktyg som stödjer tjänsteleveransen kan vi kalla ITSM-verktyg. Exempel på ITSM-verktyg kan vara ärendehanteringsverktyg, konfigurationsdatabaser, självhjälpsportaler.

Om vi börjar med frågan varför man behöver ett verktyg? Oftast när verktygsstöd kommer upp på tapeten så beror det på att något i och runt IT-leveransen har vuxit ett eller flera steg på kort tid. Exempelvis kan mängden kunder ökat och därigenom generera fler ärenden. Effekten av detta yttrar sig oftast i växtvärk med symptom som tappade eller glömda bollar, fel innehåll i leveransen, dålig kvalité i leveransen, stressad personal och missnöjda kunder.

Så hur gör man när symptomen av växtvärk blir för jobbig? Här är några exempel på frågeställningar som man kan använda sig av när man utvärderar verktygsstöd.

• Vad behöver vi verktygsstöd till?
• Finns det något befintligt verktyg i vår organisation som faktiskt kan hantera vårt behov? 
• Kan vi ersätta något eller några befintliga verktyg (läs Excel-ark)med ett nytt verktyg?
• Finns det fler i vår organisation som skulle ha nytta av den funktionalitet som vi söker?

Som i de flesta fall när man genomför en större förändring bör man ta fram ett bra beslutsunderlag och det gäller även vid verktygsval. Själva upphandlingen av verktyg är ett eget kapitel och jag tänkte återkomma till den i ett senare blogg-inlägg.

Så vad är då viktigast när vi tittar på själva verktyget? Verktygsfunktionalitet eller verksamhetsstöd?

Jag har sett många som faller i fällan att basera valet på vilket verktyg som har mest avancerad och omfattande funktionalitet. Risken är att man skjuter över ribban och får betala för funktionalitet som organisationen inte är mogen att dra nytta av. Försök lyfta blicken från funktionaliteten och istället fokusera på verktygets förmåga att stötta just de verksamhetsprocesser som behöver stöd.

Ett annat tips är att ta fram en tydlig roadmap för verktyget och dess funktionalitet och staka ut vägen i etapper. Prioritera och avgränsa med hänsyn till önskad effekt.

Själva införandet av ett nytt verktyg kan man göra på mer eller mindre bra sätt. Det är oftast lättast att fokusera på att få igång tekniken, men man bör också tänka på nuvarande arbetsprocesser samt personalens förutsättningar. Processen behöver ibland uppdateras då verktyget gör att vissa processteg och rutiner inte längre behövs eller görs på ett enklare sätt tack vare verktyget, jobba iterativt med verktyg-/processutvecklingen.

Utbildningen av verktygsanvändare är central för att få ut fullt värde av en verktygsinvestering. Det är lämpligt att dela upp utbildningsinsatsen i dagliganvändare och sällananvändare, för att kunna fokusera på rätt detaljer och hålla rätt tempo. Ta fram scenarion som stämmer med de processer som verktyget skall stötta och genomför små rollspel hellre än att gå igenom ”tryck här och sen tryck där”. Det får man ändå på köpet. Se till att användarna förstår i vilket sammanhang verktyget kommer in. Då blir det lättare att förstå funktionaliteten i verktyget. Passa gärna på att ta ett omtag och utbilda i processerna samtidigt som det nya verktyget införs.

Ett nytt verktyg behöver även förvaltas och utvecklas. Se till att få med utvecklingen av dessa områden vid etableringen. De personer som skall jobba i verktyget måste ha ett enkelt sätt att framföra åsikter och tankar som är relaterade till verktygsutveckling/förbättring. En tydlig mottagare och ägare måste utses samt en process för förbättringsarbetet bör etableras eller vidareutvecklas för att omfatta ett nytt verktyg.
Summa summarum - tänk efter före och se till att ha svar på dessa frågor:

Varför behöver vi ett verktyg? Hur ser vår Roadmap ut för verktyget? Hur inför vi verktyget? Hur förvaltar och förbättrar vi verktygsstödet?

Thomas Godawszky, utbildare inom ITIL hos Informator och
verksamhetsutvecklare inom ITSM på Olingo.

Läs mer

ITIL och agila metoder - Motsatser eller komplement?

I mitt förra inlägg skrev jag om ITIL och förhållandet till ramverk i allmänhet. Nu går vi in på förhållandet till specifika ramverk och vi startar med agila metoder.

Agila metoder har vunnit mark på senare år och det av bra skäl - kortare cykler, snabb anpassning till ändrade behov, bättre nyttjande av kompetens och säkert fler ändå. Tyvärr ser många en konflikt mellan detta och de "rigida" och "oflexibla" ITIL-processerna. Ofta, om inte oftast, är detta en helt onödig konflikt och ett pseudoargument mot ITIL och IT service management i största allmänhet.

För att sätta förväntningarna så definierar jag agila metoder enligt följande: 
Lättrörliga programvaruutvecklingsmetoder som används för programvaruutveckling där fokus ligger på nära samarbete mellan utvecklare och experter på affärens behov och processer. Detta kännetecknas av korta cykler, täta möten mellan beställare och utvecklare med uppföljning och justering, inkrementellt och iterativt arbetssätt och förlitande på människor, relationer och kommunikation mer än process och dokumentation. Se det agila manifestet: http://www.agilealliance.org/the-alliance/the-agile-manifesto/

Jag påstår att missuppfattningen till mycket stor del bygger på det faktum att tillämpningen av ITILs ramverk och utformningen av processerna upplevs som tungrodd. Det är förmodligen helt sant. Men det behöver inte vara så. Tvärtom. Dessa två vinklar in på delvis olika, delvis samma sanning kan samverka och skapa oanade synergier. Låt oss kika på en del områden där det kan uppstå konflikter.

• Change management är ITIL-processen för beslut och kontroll.
• Agil metodik bygger på ständiga små inkrementella beslut.
• Konflikt? Inte nödvändigtvis.

Att fatta beslut om riktlinjer för Change management att hålla sig inom är ett kännetecken för mogna organisationer. Det är mekanismen för högre chefer att ta strategiska beslut att genomsyra de taktiska och operativa besluten.

Exempel: Om strategin är att nå ut snabbt med nya tjänster och kvaliteten inte står i fokus så är det OK med en Change-hantering som inte trycker hårt på testning, kvalitetssäkring och genomarbetade business case. Google är ett företag som har anammat den change-strategin. Det var också en nyckelfaktor för hur www.aftonbladet.se blev den mest framgångsrika nyhetssajten i Sverige redan på 90-talet. Det var ofta nytt utseende på hemsidan och nya sätt att hantera och sortera information. Inte många kommer ihåg att det ofta var störningar och avbrott i tjänsten.

Det finns ingen motsättning till denna strategi i ITIL-processen Change Management. Tvärtom, ITIL trycker hårt på vikten av att anpassa varje enskild (ITIL)-process efter organisationens specifika behov och strategier.

• Release and Deployment management är ITILs process för att med en helhetssyn säkerställa att grupper av godkända ändringar byggs, testas, rullas ut och verifieras på ett säkert, repeterbart och spårbart sätt.
• Inom agila metoder är det inbyggt med inkrementella utrullningar av den programvara som produceras.
• Motsägelsefullt? Inte alls!

De flesta förstår det mycket kraftfulla argumentet som IT service management och ITIL slår fast som en grundbult: det är tjänster som levereras, inte teknik. 

Att programvaruutvecklare tar hand om de fel och brister som uppstår i och med deras ständigt pågående utveckling och utrullning är en bra sak. Vissa kallar detta "dog fooding", dvs man äter sin egen hundmat och tar fullt ansvar för den och alla aspekter av den.
Men, en seriös och mogen beställare inser att det slutliga målet är att detta ska landa i en tjänsteleverans och att förutsättningarna för detta måste skapas Detta är ett ansvar som läggs på utvecklingen av samtliga komponenter - applikationer, infrastruktur, supportprocesser, information och verktyg för hantering av tjänsteinformationen etc.

Alltså - om en organisation väljer att fylla sin Release and Deployment-process med ett agilt innehåll är detta helt OK. Vissa saker kommer att vara annorlunda, andra kommer att vara precis likadana. ServiceDesk kommer fortfarande att behöva förbereda sitt bidrag till den färdiga tjänsten, det kommer fortfarande att behövas en Known Error Database (KEDB), Incident management processen kommer fortfarande att behöva känna till hur den ska anpassas och de nya Service Requests som tjänsten obönhörligt kommer att ge upphov till ska förberedas och fördelas.

Med en lagom stor dos ödmjukhet på alla sidor kan man säkert komma överens och till och med sätta en metodik och erfarenhet som kan gälla framtida utvecklingsprojekt och hur det ska fungera i verkligheten. Ju bättre rustad organisationen är för detta, desto bättre beställning och desto större chans att projektet lyckas hålla sig inom den heliga treenigheten tid - kostnad - resultat/kvalitet.

• En sista jämförelse - Configuration management.
• För det första, det verkar som de flesta inom IT-världen har förstått att Configuration management inom Software Asset Management är en sak och att Configuration management inom IT service management är en annan sak. De har beröringspunkter, men är två olika discipliner.
• Bråk? Inte om man tänker efter först.

För att leverera tjänster med en chans att lyckas behövs kontroll på vad man har och hur det hänger ihop. Självklart kan krav ställas på allt som går i produktion att det ska vara känt vad det är och var det är. På en nivå som tjänstelevererande organisation bestämmer och utvecklingsprojektet tillhandahåller som del av leverans. Komplett med dokumentation.
Om man bara lyssnar och tar hänsyn till alla intressenters behov och krav i förväg har man en bra chans att lyckas. Om inte tar man en stor risk att vakna upp väldigt bryskt.

Nästa inlägg i denna serie kommer att handla om arkitektur och jag kommer att dra en lans för en ny slags arkitektroll. Som vanligt tar jag tacksamt emot era åsikter och kommentarer. 

Jim Lindfors
Verksamhetsutvecklare och utbildare

Läs mer

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

Läs mer

Det räcker inte med ITIL – allt är inte en spik

Det finns ett engelskt uttryck som kan översättas till "om allt du har är en hammare kommer allt se ut som en spik”.
Det har varit många företags inställning till ramverket (verktyget) ITIL - alla IT-avdelningens utmaningar ska lösas med hjälp av ITIL.

För några år sedan räckte det med att kunna stava till ITIL för att bli hälsad som en frälsare. ITIL var lösningen på IT-avdelningens alla problem. Man skulle bli bättre på att förstå kunden, kostnaderna skulle sjunka, driftsäkerheten öka och medarbetarna skulle bli lyckligare.
Idag har flera företag vaknat upp från sitt ITIL-rus till en ganska kraftig baksmälla. Vad var det som hände?
Det som hände var minst ett av nedanstående alternativ, troligtvis allihop:

• Oförmåga att inse att ITIL är ett verktyg och ingen färdig lösning
• Orimliga förväntningar på organisationens förändringsförmåga
• Bristande kunskaper hos egen personal OCH externa konsulter

Jag hävdar med en dåres envishet att ITIL är ett mycket effektivt verktyg. Men man måste förstå hur det ska användas och inse att världen inte bara består av spikar.
Det finns många ramverk och modeller som är alldeles utmärkta, och nödvändiga, komplement till ITIL. Några exempel som kan nämnas är COBIT, ISO/IEC 20000, CMMI, Balanserat Styrkort, PM3 samt Lean. Dessa verktyg ersätter dock inte ITIL utan de har andra styrkor. Med flera verktyg i verktygslådan ser inte allt ut som en spik längre. 
 
I min nästa blogg tänkte jag berätta lite mer om hur några av ovanstående verktyg kompletterar ITIL.  Det blir ett lite längre inlägg som jag hoppas du tar dig tid att läsa. Bra koll på verktygen ökar möjligheterna till ett lyckat bygge!

Läs mer

ITIL i sambaland

För att få ett exotisk touch inför midsommarhelgen tänkte jag låta en av mina kollegor rapportera om ITIL-läget i sambaland... Nicke är en av våra populära konsulter och ITIL-kursledare som för tillfället befinner sig på uppdrag i Brasilien.

-----------

IT Service Management/ITIL är fortfarande i sin linda i Brasilien, dvs man ligger lite ”efter” oss Svenskar/Européer. Givetvis kan man spekulera vilt i vad detta kan bero på, säkerligen kommer en och annan tänka på stränder, iskalla fruktdrinkar, karnevaler och annat. Jag lämnar dock spekulationerna åt sidan och konstaterar att man är väldans nyfiken på ITSM/ITIL. Om inte annat vittnar hyggligt deltagande på vårt seminarium på SwedCham om detta.

För såväl exilsvenskar som för brassar med svenska intressen utgör den svenska handelskammaren, populärt kallad SwedCham, i São Paulo ett populärt forum för erfarenhetsutbyte och kompetensutveckling. Brasilien är en viktig plats för Sveriges näringsliv med hyggligt stor närvaro som följd. Så självklart ville Olingo, nu även med lokal närvaro, eder ödmjuke undertecknad, vara med och vifta med svenska flaggan kompletterad med ett ITSM och ITIL-banér.

Det hela blev ett mycket interaktivt och populärt seminarium om varför det inte bara är en bra idé utan ren och skär överlevnad att använda ITSM/ITIL. Seminariet följdes av många bra frågor och en hel del fruktsamma diskussioner. Så eder ödmjuke tillika på plats varandes Olingoan var så där härligt varm om öronen och glad i själen efter ett lyckad evenemang och jag skulle bli mycket förvånad om inte Brassarna gasar på blixtsnabbt med ITSM för vi vet ju alla hur bra det kan bli. Eller hur!?

På plats i Brasilien

// Brassenicke (a k a Nicklas Fredriksson)

---------------------------------

Med det sagt kompletterar vi brännvinssupen med en caipirinha på midsommarbordet och utbringar en skål till våra vänner i sambaland. Skål och glad midsommar!

Ola

Läs mer

ITIL – varför heter det så?

ITIL står för Information Technology Infrastructure Library. Hur tråkigt låter inte det?! Snacka om att ett ramverk jobbar i motvind med ett sådant namn.

Inte nog med att namnet är tråkigt. Det är dessutom totalt missvisande. ITIL har i praktiken ingenting med infrastruktur att göra och inte ens kopplingen till IT är särskilt stark.
 

Varför heter det då ITIL? Det har med historik att göra.

ITIL skapades i början av 1980-talet av en statlig engelsk instans, CCTA, med uppgift att ge IT-stöd till regeringsdepartement. Ursprungligen var inriktningen ganska teknisk och det fanns visst fog för namnet ITIL. Allteftersom ITIL-ramverket utvecklades i version 2, som kom ut runt sekelskiftet, och version 3, som släpptes 2007, har dock inriktningen glidit över mer och mer mot verksamhetsfrågor. I samband med att version 3 skulle släppas pågick faktiskt en debatt huruvida namnet ITIL skulle ändras till något som bättre beskriver vad det handlar om – verksamhetsutveckling. Beslutet blev dock att behålla namnet eftersom det anses vara inarbetat och att ett namnbyte skulle gunga den tröga IT-industrin alltför mycket.

Kvar står vi alltså med ett taskigt namn på ett i övrigt användbart ramverk.
Det är lite synd eftersom det gör att ITIL har svårt att få ”cred” inom andra avdelningar än IT-avdelningen, trots att ramverket skulle skapa värde även på andra håll i en organisation.

Olingo har äntligen dragit igång på Twitter - https://twitter.com/#!/Olingo_
Följ oss gärna där om du är intresserad av ITSM (IT Service Management) och ITIL.

Läs mer

Köp wienerbröd för pengarna

För några dagar sedan skrev jag ett inlägg om att de flesta så kallade ”ITIL-projekt” är misslyckade. I sann journalistisk anda spetsade jag till verkligheten lite. Misslyckade är ett starkt ord. Det handlar nog snarare om att många ITIL-projekt inte lever upp till högt ställda förväntningar.

Som botgöring ska jag nu försöka ge ITIL lite upprättelse genom att nyansera mig en aning.

ITIL är ett förträffligt verktyg som kan göra underverk för vilken IT-verksamhet som helst. Om det används på rätt sätt.

På Olingo är vi allergiska mot uttrycket ”Vi ska implementera/införa ITIL”. Vi brukar bemöta det påståendet med ett motförslaget att ni kommer troligtvis få bättre valuta för pengarna om ni köper wienerbröd till personalen istället.

Uttrycket ”införa ITIL” skapar en förväntan av att man ska ersätta nuvarande arbetssätt med ITIL-processer. Man ska gå från ett ineffektivt och gammalmodigt sätt att arbeta till ITIL ”best practice” och, som genom ett trollslag, ska alla IT-problem man tidigare upplevt lösa sig.
Det funkar inte riktigt så.

Tanken med ITIL är att man ska utgå från den egna verksamheten och hämta tips och idéer från ITIL-ramverket. Dessa idéer kan användas för att utveckla verksamheten stegvis. En sak i taget.

Så, om du hör någon i din organisation som snackar om att införa ITIL – be om en kanelbulle istället.  

Läs mer

Det är cementblandarens fel!!

De flesta ITIL-projekt är misslyckade. Med det påståendet kan det verka lite konstigt att jag är en av Informators ITIL-kursledare. Men jag står för påståendet. För så är det. De flesta ITIL-projekt är misslyckade.
Varför är det så? Låt oss bena ut det här. 
Tänk dig att du ska bygga ett hus. Vad behöver du då?
Dels behöver du byggelement och verktyg. Till exempel behöver du material till grund, väggar och tak och du behöver maskiner och verktyg som gör det möjligt att anlägga tomten och sätta ihop byggelementen till en helhet. Vi behöver även en ritning och byggplan som visar hur delarna passar ihop och i vilken ordning de ska komma på plats. Med ett gemensamt namn kan vi kalla dessa för resurser.
Räcker det? Känns som att det saknas något…
… jo visst ja, vi behöver ju kunskap att använda maskinerna och verktygen för att få ihop själva huset och vi behöver även konstruktionskompetens för att skapa ritningen. Utöver det behövs byggledarkompetens samt någon slags byggprocess för att säkerställa att ritningen och planen följs. Dessa kunskaper och processer kan vi kalla förmågor.
Det är rätt uppenbart att vi inte klarar oss utan den ena eller andra delen. Utan resurserna får vi självklart inte till något hus men även förmågorna är avgörande för ett lyckat husprojekt.
Den insikten saknas i de flesta ITIL-projekt.
ITIL är ett ramverk som beskriver de förmågor, dvs processer, modeller, roller och arbetssätt som är lämpliga för en lyckad tjänsteleverans inom IT. Tanken med ITIL-ramverket är att det ska användas som en  verktygslåda för att stödja verksamhetsutvecklingen.
Det som ofta saknas i misslyckade ITIL-projekt är kunskap om hur denna verktygslåda ska användas. Kunskap om vilka verktyg i lådan som ska användas och hur de ska användas. Samt kunskap om vilka verktyg som ska väljas bort. Ett vanligt misstag är att alla verktyg används samtidigt och dessutom på fel sätt.

Ett lyckat ITIL-projekt, och dessa finns faktiskt, tar fasta på att det är viktigt att ta fram en tydlig målbild (jmfr med byggnadsritningen) samt en genomarbetad plan för hur målbilden ska uppnås (jmfr med byggplanen).
Att, när ITIL-projektet misslyckas, skylla på ITIL är som att skylla på cementblandaren om husprojektet går i stöpet.

Till slut vill jag passa på att gratulera Visma Retail till Årets ITSM-projekt!!
Ett bevis för att det faktiskt finns lyckade ITIL-projekt, eller snarare verksamhetsprojekt som använder verktygslådan ITIL. På ITSMf-konferensen 20;e mars utsågs nämligen Visma Retails projekt till årets projekt. Olingo var delaktiga i projektet som projektledare och expertstöd. Läs mer på www.olingo.se/aretsprojekt. 

Nästa gång tänkte jag berätta lite om varför jag har så svårt för uttrycket “Vi ska implementera ITIL....”.  


Hepp!

Läs mer

Veckans gästbloggare: Ola Källgården, ITIL-expert

Veckans gästbloggare är ingen mindre än ITIL & ITSM-experten Ola Källgården på Olingo.

Som engagerande utbildare och konsult inom området ITIL och IT Service Management drivs Ola av att skapa ordning ur kaos. Med gedigen praktisk erfarenhet och en fullspäckad certifieringsportfölj har Ola den bakgrund som krävs för att göra verklig skillnad. Ola är en av grundarna till företaget Olingo där han blandar uppdragen som konsult och utbildare med rollen som konsultchef.

Här kan du se Informators ITL-utbildningar

Läs mer