Fem anledningar att delta i The Phoenix Project (DevOps-simulering)

1. Du får öva på kommunikation och tillit

Vad händer om kunden inte vara med och påverka utvecklingen av en tjänst? Eller om test-teamet inte involveras i rätt fas? Vad händer om teknikern gör en ”riskfri” ändring i infrastrukturen?  Konsekvenserna av brister i kommunikation mellan roller och team blir tydliga och kännbara. Deltagarna får chansen att etablera de kommunikationskanaler och metoder som krävs för att kommunikationen ska bli en naturlig del av arbetet.     

2. Du får med dig handfasta tips på tydlig visualisering av arbetsuppgifter och flöde

”Stop starting, start finishing” är ett mantra för simuleringen. Det viktiga är inte att vara upptagen. Det viktiga är att få rätt uppgifter slutförda. Visualisering av uppgifter, både på team- och individnivå hjälper alla inblandade att skapa tydlighet och fokus. Kanban-tavlor och andra visuella stödverktyg kommer till användning.  

3. Du lär dig prioritera och exkludera

Få team har för lite att göra. Behovet av att sålla och prioritera uppstår dagligen, både på operativ, taktisk och strategisk nivå. Med stöd av visualisering och kommunikation blir arbetet lättare. Vem är det som ansvarar för prioriteringen? Är det beställaren, produktägaren eller är det kanske hela teamet? Deltagarna får chansen att praktisera agila arbetsmetoder som sprintplanering, demos, feedback.  

4. Du får öva på att utvärdera och förbättra

Ett nyckelkoncept inom DevOps är feedback. Det blir en framgångsfaktor att bygga in feedback i arbetssättet. Feedback från kund, feedback från team-medlemmar och feedback från testning och infrastruktur. Utifrån insamlad feedback får deltagarna utveckla tjänster såväl som arbetsmetod.

5. Du får öva på att sprida kompetens och kunskaper

Silo-tänkandets tid är förbi. För att skapa effektiva team krävs att medlemmarna, utöver expertis inom sitt område, även har grundläggande koll på andra arbetsuppgifter som ingår i teamets ansvarsuppgifter. Deltagarna får känna på smärtan som uppstår när det saknas förståelse för varandras uppgifter eller när någon team-medlem plötsligt inte är på plats.  

Nyfiken på mer? Besök vår hemsida här.

Läs mer

ITIL Optimized - utbildning i rätt format!

2009 så genomförde jag själv tredagarskursen ITIL Foundation och minns tillbaka på tre extremt långa dagar i ett klassrum (plus långa kvällar under samma period med förberedelser och självstudier) plus ett ganska stressat test sista dagen. Det är absolut inget fel på originalkursen och Informator har ju under flera år hjälpt hundratals IT-medarbetare som behövt ta till sig konceptet ITIL och genomföra den grundläggande certifieringen, men med den kunskap och den verklighet vi nu har så är det dags att ta nästa steg!

Med den tidsbrist i arbetslivet som nu råder vill vi både kunna stötta dig som av olika anledningar inte har möjlighet att vara borta tre dagar i sträck från jobbet såväl som du som verkligen vill lära dig konceptet ITIL och inte bara bli ett vandrande akronymlexicon (som visserligen klarar testet, men glömt hälften av kursinnehållet en vecka senare). Med hjälp av vår partner Olingo och den lärtransfererfarenhet vi tagit till oss under de senaste två årens arbete med moderna leveransformer så har vi nu byggt ett program där du både har möjlighet att ta till dig innehållet i ditt eget tempo, läsa in dig på de olika under-områdena i förhand med tydligt avstyckat digitalt kursmaterial och stämma av det du tagit till dig med hjälp av videos och förkunskapsquiz för att sedan få en optimal klassrumsdag med experten som hjälper dig fylla i de sista luckorna.

Vårt program ITIL Foundation Optimized + Certification levereras under en treveckorsperiod där du inleder med en e-learningöversikt på hela ITIL-området, borrar djupare i områdena Service Management, Strategy och Design som avslutas med en avstämningsquiz innan den första klassrumsdagen där du tillsammans med kursledaren har möjlighet till en djupare förståelse och konkreta övningar istället för ren teori som du redan gjort innan på egen hand. Resten av veckan fokuseras på Service Transition, Operation och Continous Service Improvement innan det är dags för klassrumsdag 2 som på samma sätt fördjupar dina kunskaper på området.

För att verkligen ge dig bästa möjliga förberedelse inför certifieringen så får du ytterligare en vecka på dig att repetera områdena vi gått igenom och dessutom genomföra en mock-exam som är uppbyggt på samma sätt som den skarpa certifieringen så du får ytterligare ett stöd på vägen att klara av din certifiering på första försöket. Det arbete vi genomfört visar att i jämförelse med att ca 75-80% av deltagarna på en vanlig kurs klarar sitt cert direkt så ökar nu möjligheten till runt 95% av de som genomfört hela vårt optimerade program!

Hittills har vi endast levererat detta koncept som företagsintern utbildning med stor framgång och nu öppnar vi möjligheten även för dig som enskild deltagare att med oss ta nästa steg inom modern kompetenshöjning! Kurstillfället i vår börjar redan fyllas på trots att vi knappt marknadsfört det, men det finns platser kvar och du hittar mer detaljer och möjlighet att boka dig på kursen på https://informator.se/utbildningar/itil/itil-introduktion/itil-foundation-optimized-certification 

Tobias Strandh
Nordic Director Learning Solutions
Informator Tieturi Group
www.informator.se | www.tieturi.fi

Läs mer

DevOps – I framtiden är vi alla nybörjare

Det enda vi säkert vet om framtiden är att den kommer se annorlunda ut än nutiden. I Kevin Kellys utmärkta bok The Inevitable målar han upp tolv tekniska drivkrafter som påverkar utvecklingen i samhället. En av dessa är att vi alla kommer vara nybörjare. Att vi hela tiden måste lära om och lära nytt. Ingen kunskap är beständig. Vi kommer aldrig kunna slå oss till ro med de färdigheter vi besitter. En utmanande insikt.

IT exemplifierar förändringstakten i samhället på ett tydligt sätt. För några år sedan var det legio med långa utvecklingscykler och utvecklingsprojekt där det kunde gå månader och år mellan kravspec och utvecklad produkt. Vattenfallsmetoden regerade på utvecklingsavdelningen. Förbättringar på mjukvaror, till exempel operativsystem, kom i form av ”patchar” som sporadiskt distribuerades till användarna. Installation av dessa patchar var ett högriskspel där priset, i form av funktionshaveri och inkompabilitet, ofta översteg värdet.
Idag ser det annorlunda ut. Molntjänster och operativsystem uppdateras kontinuerligt och, mer eller mindre, utan vår vetskap. IT-tjänsterna utvecklas på ett närmast steglöst sätt och helt plötsligt har ett menyval försvunnit eller tillkommit. Det händer att fel introduceras men lika snabbt som felet dök upp har det försvunnit igen. Populära tjänster som Facebook, Netflix och Spotify genomför flera releaser per dag och enligt uppgift introducerar Amazon uppdateringar i sin produktionsmiljö var elfte sekund.

Vad har möjliggjort skiftet från vattenfall till kontinuerlig utveckling? Dels är det tekniska framsteg men den snabba förändringstakten kräver även nya arbetssätt för utveckling av IT-tjänster. Vattenfallsmetoden har ersatts av agila metoder och manuell testning av automatiserad. Det som på senare tid fått fäste är en ”modell”, DevOps, som binder samman utveckling med drift, support och förvaltning. Ordet Devops är en ihopskrivning av orden ”Development” och ”Operations” och syftet är, som namnet antyder, att knyta ihop utveckling med support och förvaltning. Till skillnad mot flera andra ramverk och metoder, som till exempel ITIL®, finns det ingen som äger eller förvaltar DevOps. Det finns heller ingen vedertagen definition av vad DevOps är och innehåller. Wikipedia definierar DevOps på följande sätt:

DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

Det är en vanlig missuppfattning att DevOps primärt handlar om automatiserad testning och driftsättning. Så är inte fallet. Huvudpoängen är att utvecklingen av en IT-tjänst ska ske i samspel mellan flera roller. I varje utvecklingsteam ska det finnas representanter för drift, support, förvaltning och säkerhet. Dessa aspekter ska byggas in i IT-tjänstens DNA.

Det finns flera exempel på organisationer som har anammat DevOps sedan lång tid tillbaka (till och med innan begreppet DevOps myntades). Spotify, Klarna, Netflix och andra stjärnskott har aldrig jobbat på annat sätt. Nu börjar även organisationer med betydligt fler år på nacken styra in på samma spår, både inom privat och offentlig sektor.

Som en konsekvens av att det inte finns en ägare av DevOps så har det dröjt innan etablerade utbildningar och certifieringar inom DevOps blivit tillgängliga. Nu börjar de dock falla på plats. Det finns två organisationer, DASA och DevOps Institute, som parallellt har tagit fram ackrediteringar och utbildningsvägar. Kursupplägg och innehåll är snarlikt. Olingo har valt att leverera DASAs kursutbud. Anledningen är att det är fler organisationer som står bakom DASA och att vi har bedömt chanserna till världsdominans som större. Den som lever får se.

Ola Källgården, Olingo

Oavsett vad som händer med DASA och DevOps Institute så har DevOps kommit för att stanna så det är väl värt att lära sig för samtliga organisationer som ägnar sig åt tjänsteutveckling. Kunskap ger framgång. Åtminstone fram tills nästa grej dyker upp och vi blir nybörjare igen.

Den 26 september bjuder vi in dig till ett kostnadsfritt frukostseminarium "DevOps - I ett nötskal". För dig som vill gräva lite djupare kompletterar vi med endagskursen "DevOps Introduktion" och du som redan nu vet att ni skall gå vidare rekommenderar vi tredagarskursen "DevOps Fundamentals" som även kan avrundas med en certifiering! Välkommen till ny kompetens i höst!

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

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 Practitioner, ny ITIL-kurs på gång - vad är syftet och vad händer med ITIL-ramverket?

Axelos, som äger varumärket ITIL, har aviserat en ny kurs som ska heta ITIL Practitioner. Den kommer bli tillgänglig som kurs och certifiering i slutet av 2015. Än så länge finns ingen syllabus (innehållsförteckning) framtagen för kursen men Axelos har givit en ungefärlig beskrivning av syfte och innehåll.

Kursens syfte är att ge deltagarna en god förståelse för vad som krävs för att få ITIL att landa bra inom organisationen. Den fokuserar alltså inte på ITIL-processerna i sig, utan är snarare en kurs i förändringsledning kopplat till ITIL. Det är utlovat att det ska finnas delar som beskriver hur ITIL kan samverka med andra modeller och ramverk som t.ex. Lean, devops, cloud-tjänster, agile och SIAM.

Det är viktigt att påpeka att kursen inte ersätter befintliga fördjupningskurser i ITIL-pyramiden. Den kommer utgöra ett komplement där en avklarad certifiering ger "poäng", för den som vill uppnå 'ITIL Expert'-nivå, på motsvarande sätt som nuvarande fördjupningskurser.

ITIL-pyramiden, dvs den kurs/certifieringspyramid, som beskriver hur en person kan ta sig från Foundation-nivå till Expert-nivå har fått utstå en del kritik i branschen. En uppfattning är att det finns för många fördjupningskurser att välja på samt att det är otydligt vilken eller vilka fördjupningskurser, baserat på roll i organisation, som är mest lämpliga.

Axelos har i dagsläget ingen officiell plan för vad som ska hända med kursutbudet på sikt. Det finns heller inte någon officiell information om när nästa version av ITIL kommer. Eller hur den kommer paketeras. Det som är helt klart är att de certifieringar som finns på marknaden idag kommer att vara värdefulla även framöver samt att den kunskap en fördjupningskurs i ITIL ger är fortsatt relevant.

ITIL-grundkursen "ITIL Foundation" hittar du här.
Samtliga ITIL-kurser hos Informator hittar du här.

Har du frågor om ITIL eller vad som händer i ITSM-branschen får du gärna lämna en kommentar nedan eller höra av dig.

// Ola Källgården
Ola är ITIL-utbildare hos Informator.
Han är även VD, verksamhetskonsult
och en av grundarna till Olingo.

Läs mer

Visionen - en viktig del av förändringsledning!

Vad är vision och hur kan vi använda den för att leda en positiv förändring? Är förändring något negativt?

 

Jag vill påstå att förändring kan ske utan negativa effekter. Vi vill oftast uppnå en ökad effektivitet och därmed ökad konkurrenskraft. Att vara konkurrenskraftig och effektiv hör tätt samman med kompetens, lyhördhet, flexibilitet och ödmjukhet. Om vi definierar förändring som en strukturerad förflyttning så behövs en tydlig vision, en riktning, för förändringen. Riktningen måste vara tydlig och gemensam för alla inblandade.

Som förändringsledare ska vi implementera den strukturerade förflyttningen med verktyg som vision, kommunikation, samverkan, proaktivitet och synergier.

Vid införande av ITIL-processer är det många organisationer som börjar med ”brandsläckningsprocesserna”, t.ex. Incident Management, istället för de mer strategiska processerna som t.ex. Demand Management och Service Portfolio Management. Även om det är viktigt med väl fungerande Incident Management så är det inte särskilt inspirerande som vision. Skulle det inte vara roligare att jobba mot en vision kopplad till kundnöjdhet och kundvärde än genomsnittlig svarstid för Incidenter? Visionen är ett av de viktigaste verktygen för att tydliggöra syftet med förändringen. Den bör tydligt visa riktning och föda en känsla av delaktighet hos medarbetaren.

Det finns flera förändringsmetoder att arbeta efter, ADKAR, People Centered Implementation eller Kotters 8-step process. Oavsett vilken metod man väljer att arbeta med, så är det ungefär samma kritiska framgångsfaktorer:

• Skapa medvetenhet om syftet till förändringen
• Tydlig vision
• Tydlig förankring hos ledningen
• Sanktionerad tid och budget
• Förändringsambassadörer
• Integrera medarbetarna
• Sprid budskapet
• Act your change
• Lev som man lär
• Positiv förstärkning
• Ge feedback, fira vinsterna

Förändringsledning handlar om att få med individerna i organisationen, att vända blicken mot visionen, förstå och sträva mot den. Under resans gång kommer det att dyka upp många små vinster och därmed chansen till positiv förstärkning, se vinsterna som en möjlighet att förstärka vi-känsla och det positiva med förändringen, tänk också på vilket beteende som ska få den positiva förstärkningen.

Den positiva förstärkningen är ett verktyg för att hålla igång arbetet, men även för att förtydliga vart vi är på väg. Där kommer återigen visionen in, att knyta an till företagets övergripande vision är ett mycket kraftfullt verktyg och bör vara en ledstjärna som föder både känslor och tydligt visar vilket håll vi siktar åt.
Jobba strategiskt och upprepande med förbättringsarbete och därmed positiva förändringar. Även om det inte är förändringen i sig som skapar värde så är det viktigt för en organisation att se förändring och utveckling som ett naturligt tillstånd.

Jag rundar av med dessa bevingade ord, uttryckta av Nelson Mandela, som väl beskriver kopplingen mellan vision och förändringsledning:

”Action without vision is only passing time, vision without action is merely day dreaming, but vision with action can change the world.”

Lycka till!



Lars Bylund, Verksamhetsutvecklare och ackrediterad lärare inom ITIL hos Informator

Se Informators kurser inom ITIL här

Läs mer

Livet efter ITIL Foundation - En individ lär så länge hon lever, en organisation lever så länge den lär

Hur ska organisationen överleva över tid? Hur ska företaget kunna fortsätta utveckla sin konkurrenskraft? Ett av svaren är strategisk kompetensförsörjning, ett långsiktigt och strategiskt arbete med mål att höja kompetensen samt engagemanget hos en individ och på företaget.

ITIL – ramverket för tjänstehantering. Ett ramverk som många it-avdelningar känner till. Att ha kunskap kring detta ramverk börjar bli en allmän praxis, att ha ITIL Foundation i sitt CV är snart obligatoriskt och ett grundkrav när man söker nya tjänster inom it-området. Därefter kommer kraven på fortsatt genomförd utbildning och bli en konkurrensfördel vid sökandet av nya tjänster.

Vi utbildare som håller kurs, dvs hjälper till att kompetensutveckla medarbetare och företag, har det sista året märkt av en skiftning av kursdeltagarnas bakgrund. Många som idag arbetar inom Service Operation-området har redan genomfört grundutbildning i ITIL och vi ser numera en kraftig ökning av andra roller såsom projektledare, förvaltningsledare/systemförvaltare, SDMer och tjänsteansvariga vid studiebänken. Mycket glädjande eftersom ITIL berör hela tjänsteleveransen – från strategi, design, transition till operation – dvs alla medarbetare inom hela it-avdelningen.

De som gått ITIL Foundation har fått en solid grund att stå på. För de som sökt och fått nya roller t.ex Process Managers, Process Owner och Service Owner brukar nya frågor dyka upp som t.ex hur går en processetablering till, hur bedrivs en processförvaltning, ledning - styrning och kravställande på stödverktyg inom tjänsteleveransen, vad ska vi mäta & följa upp, hur ska ansvarsgränssnittet mellan min roll som processmanager och linjeorganisation fungera, tjänstekatalog – hur?

Ett ypperligt tillfälle att fördjupa sig i dessa frågeställningar, diskutera och nätverka med andra som har liknande roller är anmäla sig till ITILs fortsättningskurser, s.k Intermediate-kurser. Det finns två spår, Lifecycle och Capability. Båda spåren syftar till att ge en djupare förståelse av tjänstens hela livscykel där Lifecyclespåret riktar in sig på varje bok, dvs livcykelfaserna medans Capability tar ett mer holistiskt och praktiskt grepp. Den primära målgruppen för Lifecycle-kurserna är ledarskapsroller medan Capability-kurserna riktar sig mot de som mer handgripligt tillämpar processerna.

 

Kurserna vänder sig således till alla som arbetar med tjänsteleveranser, t.ex de som är på väg in eller redan har en roll inom respektive kursområde. Kurserna vänder sig även till dig som är linjechef och styr och leder en organisation som använder ITIL som arbetssätt.

 

Ingegerd Metz, Olingo Consulting AB
Accrediterad lärare inom ITIL hos Informator

Här nedan kan du läsa mer om kursernas inriktning.

Spår Lifecycle

CONTINUAL SERVICE IMPROVEMENT (CSI)

Kursen riktar sig primärt mot de roller i organisationen som jobbar med strategi, mätning och uppföljning.
Kursen beskriver ett antal modeller och metoder som ger bra i stöd för att omsätta organisationens strategi i tydliga mål och mätetal samt hur dessa ska följas upp.

SERVICE STRATEGY

I denna kurs får du en djupare förståelse för innehållet i Service Strategy-boken. Kursen vänder sig framför allt till dig som har en position på ledningsnivå eller som arbetar med IT-strategier. Förutom att gå igenom ett antal väletablerade strategiska modeller hanteras även processer som t.ex. Business Relationship Management, Service Portfolio Management samt Financial Management.

SERVICE DESIGN

Service Design är en bred kurs som täcker flera områden. Dels kundgränssnittet (tjänstekatalog, SLAer) och leverantörsgränssnittet men även delar som design och uppföljning av tillgänglighet, kapacitet och säkerhet.
Kursen riktar sig till alla som är med i kravställning på, samt utformning av, IT-tjänster.

SERVICE TRANSITION

Service Transition beskriver förflyttningen från design till drift. Processer som Change-, Test och Release Management ligger här men även mer generella processer som Configuration och Knowledge Management.
Om du är inblandad i arbetet med att godkänna eller koordinera ändringar samt releaser är detta kursen för dig.

SERVICE OPERATION

Service Operation-kursen har fokus på delar av ITIL som är kopplade till användarsupport. Processer som Incident och Problem Management avhandlas men även funktioner som Service Desk och Application Management. Du tillhör målgruppen om du har en roll kopplad till Service Desk eller användarsupport.

Spår Capability

SOA - Service Offerings and Agreements 

Kursen ger dig en djupare förståelse för den del av ITIL-ramverket som handlar om tjänstedefinition och avtalsfrågor. Du får chansen att öva på att skapa SLAer och tjänstekataloger men även skapa business case för tjänster, baserat på specifika scenarios.
Det här är en praktisk kurs för dig som arbetar i gränssnittet mellan IT och verksamheten (kunden) eller leverantörer.

RCV - Release,Control and Validation

Du får en djupare förståelse för den del av ITIL-ramverket som handlar om testning, validering och driftsättning av tjänster. Kursen vänder sig framför allt till dig som arbetar aktivt med att planera och utföra förändringar på IT-tjänster. Du får en fördjupad förståelse för samverkan mellan kravställning, testning och driftsättning samt vikten av att ha en väl fungerande configuration management.

PPO - Planning,Protection and Optimization

Du får en djupare förståelse för den del av ITIL-ramverket som rör säkerställande av IT-tjänsternas tillgänglighet. Kursen vänder sig framför allt till dig som arbetar aktivt med planering och drift av IT-tjänster från ett tillgänglighetsperspektiv, både inom design- och operations-fasen. Du får svar på frågor om hur tillgänglighet ska planeras och mätas på bästa sätt samt varför det är så viktigt med kontinuitetshantering.

OSA - OperationalSupport and Analysis

Ger dig en djupare förståelse för den del av ITIL-ramverket som handlar om användarsupport. Kursen vänder sig till dig som vill göra praktiska övningar kopplat supportprocesserna, men även de mjukare delarna av användarsupport. Stor del av utbildningen ägnas åt diskussioner och case studies.

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

Hemligheten bakom förändringsvilliga organisationer

Ola Källgården, utbildare inom ITIL hos Informator och en av grundarna till Olingo.

IT-chefen ställs inför en aldrig sinande ström av nya eller uppdaterade ramverk, filosofier och arbetsmodeller kopplade till IT-leveransen.

Däremot finns sällan tid eller resurser att: 

1. Sätta sig in i den övergripande och långsiktiga utvecklingen och 
2. Göra verkligt välgrundade utvärderingar och val.

IT-chefen har en svår roll. Förståelse för affärsverksamheten ska balanseras mot genuin förståelse för IT-verksamheten. För att styra IT-verksamheten effektivt krävs gedigna kunskaper om de ramverk och modeller som ska användas. 

Hur mycket behöver IT-chefen veta om Itil, agilt, lean, togaf, cobit och andra ramverk och modeller som är aktuella för verksamhetsstyrningen? Hur mycket behöver VD och ekonomichef veta? Itil och andra ramverk är inte längre en angelägenhet för bara IT-avdelningen. Allteftersom IT och affärsverksamheten vävs samman blir ramverk och modeller som spänner över flera delar av organisationen relevanta.

De flesta organisationer är mer eller mindre vilsna i ”ramverksträsket”. Det provas och blandas friskt. Satsningen på agilt avlöser Lean-satsningen som i sin tur avlöste Itil-satsningen. Vad får dessa skjut-och-hoppas-satsningar för konsekvenser? Den uppenbara konsekvensen är att resultatet inte blir som förväntat. En mindre uppenbar är att misslyckade satsningar skapar en förändringströtthet i organisationen.

Hur kommer IT-chefen tillrätta med problemet? En förutsättning är att säkerställa kompetens. Först och främst sin egen kompetens och i förlängningen medarbetarnas. IT-chefen måste ha tillräcklig kunskap om varje ramverk för att förstå dess syfte och vilket värde det skapar. Dels för att fatta beslut om vilka som ska användas men även för att förstå påverkan på organisationen som helhet, inte bara IT-avdelningen. Den kompetensen och de besluten kan inte delegeras till mellanchefer eller andra medarbetare.  

Till att börja med bör varje IT-chef skaffa sig en bra bild av vilka ramverk som är strategiska och påverkar hela IT-verksamheten och vilka som är relevanta för delar av verksamheten. Itil är ett exempel på ett ramverk som är relevant för hela IT-verksamheten och som dessutom påverkar andra delar av organisationen. Det är dessa IT-chefen ska lägga krut på att förstå. 

Flera av ramverken överlappar och/eller kompletterar varandra. I vilka lägen ska Itil användas och när kommer Cobit in i bilden? Finns det någon motsättning mellan Itil och Lean? Mellan Itil och agilt? 

Det är ingen omöjlighet att nå upp till tillräcklig kunskapsnivå eftersom det ”bara” är en handfull ramverk som är av strategisk karaktär. Itil är centralt för de flesta IT-organisationer så det ramverket bör IT-chefen ha bra koll på. Där räcker det inte med att läsa på Wikipedia. Grundkursen i Itil spänner över tre dagar och borde vara obligatorisk för samtliga ledande IT-roller. 

I övrigt bör varje IT-chef ha grundläggande förståelse för Togaf, Cobit samt Lean. Beroende på den specifika situationen kan andra ramverk och modeller, som t.ex. Pm3 och KCS, vara relevanta. Här kan IT-chefen orientera sig genom att gå på seminarier, läsa artiklar och white papers samt prata med personer som har kunskapen. Utifrån den grundläggande kunskapen kan beslut fattas om vilka som är intressanta och värda mer tid.

När bilden av de strategiska ramverken börjar klarna kan beslut fattas om vilka som ska användas och hur. När kompetensen är hög är det även lättare att avgöra om ramverken bör ”ändras” eller bytas allteftersom verksamheten förändras. Kartan och kompassen för att undvika vilsenheten stavas alltså utbildning. 

---

ITIL-utbildningar hos Informator

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