Om du arbetar inom IT har du förmodligen hört talas om ITIL Foundation. Men vad exakt är det, och varför ska du bry dig? ITIL (Information Technology Infrastructure Library) är ett ramverk för IT Service Management, som används av organisationer runt om i världen för att förbättra kvaliteten på sina IT-tjänster.
ITIL Foundation-kursen ger en introduktion till ITIL-ramverket, som täcker dess nyckelbegrepp, terminologi och processer. Det är en bra utgångspunkt för alla som vill förbättra sin förståelse för ITIL och hur den kan tillämpas i deras organisation.
Så varför ska du gå en ITIL Foundation-kurs? För det första kan det hjälpa dig att avancera din karriär inom IT Service Management. Arbetsgivare värdesätter ITIL-certifiering, eftersom det visar en gedigen förståelse för ITIL-ramverket och dess tillämpning.
Dessutom kan ITIL Foundation hjälpa dig att förbättra din organisations IT-tjänster. Genom att lära dig om de bästa metoderna och processerna som beskrivs i ITIL kommer du att vara bättre rustad att identifiera förbättringsområden och genomföra förändringar som kan gynna både din organisation och dess kunder.
The Larsson Way – Praktiskt, Pragmatiskt och Konkret Vårt mål är att göra skillnad på riktigt. Vi gör det genom ett personligt engagemang och praktiska erfarenheter.
Medarbetarna är vår viktigaste resurs, punkt.
Vi ser individen för den hon är och driver ett individualistiskt ledarskap där du förväntas ta ansvar och bidra till utvecklingen av företaget.
Vi marknadsför oss via vårt goda renommé och har förbjudit skrivbordsprodukter som inte fungerar.
Vi bor och lever alla i Västra Götaland/Halland och tar främst uppdrag där. Vi prioriterar våra familjer och våra kollegor högt. Det är viktigt att livspusslet fungerar och att vi har kul och trivs på våra arbetsplatser.
Vad karaktäriserar en konsult hos Larsson & Co?
En grundläggande syn på alla människors lika värde
Vetgirig och nyfiken
Högt kundfokus
God kommunikationsförmåga
Förmåga att arbeta bra i grupp och självständigt
God förståelse om ramverket ITIL
Bär inte kostym och slips
Vi söker dig med praktisk erfarenhet av att utveckla IT-organisationer, så som att:
Utveckla supportorganisationer (Service Desk)
Utveckla driftorganisationer (IT-operation)
Genomföra processkartläggningar
Driva förstudier
Genomföra nulägesanalyser
Utveckla och etablera processer
Facilitera Workshops
Hålla utbildning
Du ska ha en pragmatisk syn på ITIL och dess bidrag.
Du får gärna ha haft en roll som IT-chef, projektledare, driftchef, supportchef eller motsvarande.
Det är ett plus om du har certifieringar inom ITIL eller projektledning. Våra uppdrag finns främst inom Västra Götaland/Halland. Vi ser därför att du bor i anslutning till våra kunder. Läs mer om oss på http://www.larssonco.com/
Vi vill ha din ansökan, CV och personliga brev på svenska till info@larssonco.com med ”ansökan” i rubriken.
Hur kan vi använda Problem Management för att minimera sannolikheten för och påverkan av incidenter?
Vi ser några nyckelfaktorer till ett framgångsrikt arbete med Problem Management.
Tydligt ägarskap:
För att lyckas är det viktigt att någon får ansvar för att driva arbetet med Problem Management för att skapa arbetssätt, rutiner som hjälper oss att identifiera problem.
Etablerat arbetssätt:
Arbetet med Problem Management bör planeras och bedrivas på ett strukturerat sätt. Detta för att vi kontinuerligt skall identifiera problem och åtgärda de mest prioriterade problemen så snart som möjligt.
Detta innebär ett tydligt arbete kring de tre delarna:
Problem Identification
Problem Control
Error Control
Proaktivt och reaktivt arbete:
Genom att titta på vilka risker vi ser och vilka problem vi kan förutse kan vi förebygga incidenter och på så sätt undvika incidenterna helt alternativt skapa en workaround i förväg vilket minskar påverkan av de som vi inte kan lösa.
Vill du ha fler tips och idéer kring Problem Management titta på presentationen på vår YOuTube-kanal.
Frågor & svar
Under frukostmötet fick vi in flera frågor, vi hann inte med att besvara alla. Men du hittar våra tankar kring dessa frågor här.
Först vill vi bara påpeka att det är svårt att ge generella svar eftersom hur vi implementerar och använder ITIL varierar från organisation till organisation. ITIL pratar om ”adopt and adapt” vilket betyder att vi skall anpassa ramverket efter oss men också anpassa oss efter ramverket. Detta är det givetvis viktigt att ta hänsyn till när ni läser svaren.
Vill du diskutera hur det ser ut hos er eller mer i detalj kring en fråga är du givetvis välkommen att kontakta oss.
Vem ska äga ett problem?
När vi har identifierat ett problem behöver den person eller det team som hanterar det berörda systemet, tjänsten, produkten, komponenten etc. få ägarskap för hur vi kan ta hand om detta problem. Dels för att se om vi kan skapa en Workaround för att minimera påverkan men även för att se om vi kan identifiera lösningar för att åtgärda problemet. Det kan ibland finnas flera möjliga ägare till ett problem och vi rekommenderar då att den som är utsedd till Problem Manager får mandat att delegera ansvaret för det specifika problemet.
I en organisation som jobbar med agile och devOps team – var passar problem, incident, och transition management in? Som egna delar/team/funktioner eller inbyggda i DevOpsteamen?
Vår bild är att det gäller att vi skapar en tydlighet kring vem som ansvarar för vad här. Vi skulle föreslå följande arbetssätt:
Service Desk bör ta emot, prioritera och vid behov eskalera incidenter.
De agila/devops teamen behöver vid behov kunna bistå med lösning av Incident.
Problem management bör hanteras enligt frågan här ovan.
Transition hanteras normalt i de agila teamen, självklart i samarbete med Service Desk.
Finns det ett hinder att samma personer som har driftansvaret för systemet/infrastrukturen och är den som äger Problem management för detta område?
Risken som vi ser är att det kan bli suboptimering om vi inte hittar ett sätt att prioritera och hantera Problem inom olika områden i relation till varandra. Det finns en styrka i att ha en ”oberoende part” som ansvarar för Problem Management. Om vi gör det blir det viktigt att vi använder ITIL’s Guiding Principle ”Collaborate and promote visibility” för att ta med rätt personer i beslut och synliggöra det vi jobbar med.
Hur kan vi prioritera lösning av problem istället för att bara använda workarounds hela tiden?
Med hjälp av ett strukturerat arbete med Problem Management.
Skapa en process för att kontinuerligt analysera och utvärdera de incidenter som hänt samt att gå igenom de workarounds som ni har och värdera (räkna på) tiden ni lägger på att använda dessa workarounds och jämför det med tiden/kostnaden för att åtgärda problemet.
Min tanke är att Problem oftast angrips på samma sätt som Incident, och man missar den mer systematiska delen i Problem Management som inte är lika viktig i Incident Management.
Vi ser också detta och det är anledningen till att vi anser att det bör finnas någon som är uttalat ansvarig för att driva och inspirera till ett aktivt Problem Management och att det även innebär proaktivt arbete.
Problem Manager kan driva arbetet framåt för att undvika just detta.
Vem och hur gör man bedömningen om problemhanteringen är så omfattande så lösningen istället är att ”börja om” är det en ren kostnadsfråga eller finns det stöd i ITIL som vägleder en att ta beslutet att välja helt nytt istället?
ITIL beskriver i den Guiding Priciple som kallas ”Start where you are” mer om hur vi bör tänka kring detta. Rekommenderar att läsa den även om den inte ger exakta svar på hur vi skall göra så hjälper den till med hur vi bör tänka.
Vi rekommenderar att vi först ta reda på vad nuvarande tjänst/system/lösning gör för att säkra att eventuella ersättningssystem täcker detta.
Vi behöver också göra en ordentlig riskbedömning, dels av problemet samt på bytet och det nya systemet. Hur vi sen värderar det beror på fall till fall vilket gör det svårt att svara på rent generellt. Men om värdet/nyttan av att byta överväger risken och kostnaden är det givetvis rätt att byta.
Hur bör man jobba för att ”mata” Problem Manager med info. dvs hur ger man PM underlag för att hen ska kunna analysera och prioritera ev.?
För att göra detta behöver vi sätta upp ett system för insamling av information, det kan till exempel handla om att skapa rapporter för:
Antal Incidenter per klassificering
Major incident rapporter
Information från Partners & Suppliers
Samt information om potentiella problem i nya och befintliga system
Vill du veta mer?
Kontakta oss gärna för mer information eller bara för att diskutera mer kring ämnet.
Du hittar denna och tidigare frukostmöten på vår Youtube-kanal! Klicka här!
Hör gärna av dig!
Telefon: 031-337 57 50 Mail: info@larssonco.com
Klicka på bilden!
Klicka på bilden för att komma till presentationen!
Vi snubblade över en video med Henrik Kniberg där han pratar om sin resa på Spotify & Lego.
Vårt förra frukostmöte handlade om hur man kan kombinera Agila metoder med ITIL. Henrik pratar om hur man kan vara agil inom andra områden är just mjukvaruutveckling.
Går det att få nytta av ITIL när vi arbetar Agilt?
Absolut! – Vi ser många fördelar med det!
Vår omvärld förändras därför behöver vi säkra att vi fortsätter hjälpa verksamheten skapa värde. När vi utvecklar, levererar och förvaltar produkter och tjänster finns det stor nytta att kombinera ITIL med Agila metoder. ITIL 4 är uppdaterat för att hjälpa oss med just det.
ITIL 4 innehåller bra tips på hur vi kan lyckas.
I ITIL 4 beskrivs de tre begreppen nedan och hur vi kan skapa just Fast Flow, Feedback & Improvements:
Fast Flow:
”Change Enablement” beskriver hur vi genom att skapa olika processer för t.ex. en ändring på infrastruktur och/eller en på mjukvara kan möjliggöra snabbare hantering av de förändringar där snabbheten verkligen är viktigt.
Fast Feedback:
”Relationship management” hjälper oss skapa förutsättningar för ”Value co-creation” vilket möjliggör ”Fast feedback” genom ett nära samarbete med kunden/verksamheten.
Fast Improvement:
”Continual Improvement” beskriver hur vi kan skapa en kultur som uppmuntrar till förbättringar och även beskriver hur vi kan arbeta strukturerat och effektivt med förbättringar.
Vill du veta mer?
Kontakta oss gärna för mer information eller bara för att diskutera mer kring ämnet.
Du hittar denna och tidigare frukostmöten på vår Youtube-kanal! Klicka här!
Hör gärna av dig!
Telefon: 031-337 57 50 Mail: info@larssonco.com
Klicka på bilden!
Klicka på bilden för att komma till presentationen!
Nästa frukostmöte
7 maj är det dags för ”Problem med Problem management”.
Vad karaktäriserar en högpresterande IT-organisation och Change Enablement?
Enligt Process Institute finns det tydliga karaktärsdrag hos högpresterande IT-organisationer kopplat till Change Enablement:
Hög tillgänglighet – Höga värden på Mean Time Between Failure (MTBF) och låga värden för Mean Time To Repair (MTTR)
Låg andel oplanerat arbete – Medel: 45% oplanerat arbete, Bäst i klassen: 5% oplanerat arbete
Hög nivå av lyckade ändringar – Upp till 99% av alla ändringar definieras som lyckade införanden
Fokus på arbetet tidigt i flödet – Investerar tid och resurser i planering, test, paketering och implementering
Ändringskultur – Det är självklart att alla arbetar med ändringshantering
Riskoptimering är huvudsyftet med Change Enablement
Att stoppa alla ändringar och ta bort all risk är inte riskoptimering, vi behöver balansera risken med värdet ändringen förväntas ge.
Change Enablement lever i symbios med andra processer
Change Enablement är bara en av flera processer som hänger ihop, vi behöver se till landskapet, inte enstaka processer eller practises. Inte minst behöver vi ha ordning och reda på våra ingående komponenter (konfigurationsobjekt) så som tjänster, hårdvara, applikationer, integrationer, leverantörer, avtal, licenser och mycket mer. Var uppmärksam så ni inte skapar ”process-silos”.
Fyra fokusområden för ett modernt Change Enablement arbete
Vi behöver flytta fokus till arbetet i själva flödet istället för i slutet, kvaliteten måste höjas i utvecklingen/framtagningen och inte i kontrollsteg (traditionell CAB) i slutet av processen
”One size doesn’t fit all” – Börja använda processmodeller för att illustrerar de olika värde-strömmarna (processflödena)
En ändringsmodell är ett sätt att fördefiniera steg för att hantera en specifik ändring på ett överenskommet sätt. Supportverktyg kan sedan användas för att säkerställa det specifika flödet i praktiken.
En ändringsmodell inkluderar sådant som:
Åtgärder/instruktioner som ska utföras för att hantera den specifika ändringen
Den kronologiska ordning i vilken processtegen ska utföras, inklusive eventuella beroenden
Ansvar – vem ska göra vad, inklusive identifiering av de beslutsforum som krävs
Ledtider och tröskelvärden för genomförandet av uppgifterna
Eskaleringsförfaranden – vem ska kontaktas och när
Etablera en delegerat beslutsflöde. Forumen kan bestå av en roll, en person eller en grupp människor. Vilken beslutsnivå som krävs för godkännande av en viss typ av ändring (normal, standard eller akut) bedöms utifrån bl.a. typ, storlek, risk, kostnad och potentiell påverkan etc.
Tips för att misslyckas ????
Vill du veta mer?
ITIL practices
Här kan du läsa detaljerna kring ITIL’s practices.
ITIL kurser
Foundation
Create, Deliver & Support
Drive Stakeholder Value
Direct, Plan & Improve
High Velocity IT
Digital & IT Strategy
Kontakta oss gärna om ni vill ha hjälp! Vi utlovade ju bland annat en timmes onlinemöte med de av er som vill prata mer om just hur Value Streams påverkar just er organisation. Kontakta Andreas på andreas.lindstrom@larssonco.com så hjälper han till.
På vår ITIL-frukost i fredags den 6 november, pratade vi om:
Vad Value Streams och processer är
Hur de hör ihop
Hur vi kan arbeta med att utveckla våra Value Streams
I ITIL 4 presenterade ITIL begreppet Value streams och under våra kurser och i våra uppdrag har vi fått många frågor kring just Value Streams. Därför har vi valt att förklara mer kring det på vår ITIL-frukost.
ITIL handlar om att skapa, utveckla och leverera produkter och tjänster som ger värde till våra kunder och intressenter. För att vi skall kunna göra det krävs det att vi förstår kunden, har rätt resurser och skapar bra arbetssätt för hur vi jobbar och det är här Value Streams och processer kommer in.
”A value stream is a series of steps that an organization uses to create and deliver products and services to a service consumer.
A value stream is a combination of the organization’s value chain activities.”
Service Value Streams, aktiviteter och Service Value Chain
Definitionen på en Service Value Stream kan översättas som: ”en serie steg som en organisation använder för att skapa och leverera produkter och tjänster till en tjänstekonsument” och värdeströmmar består av ”en kombination av organisationens värdekedjeaktiviteter”.
De olika stegen som beskrivs i en Value Stream består av aktiviteter som hanteras med hjälp av processer för att vi på ett effektivt sätt skall kunna omvandla de input som vi får in till output för nästa aktivitet i vår Value Stream. Som på bilden till höger där Den stora vita cirkeln visar hur det kan se ut i aktiviteten ”Engage”.
Rätt resurser gör att vi lyckas!
Oavsett hur bra vi bygger våra Value Streams och våra processer så hjälper inte det om vi inte har rätt resurser även i de andra tre av de ”4 dimensions of Service Management”.
Om vi tittar på Pit-stop teamen (Bilracing), som vi pratade om så är det just ”the 4 dimensions of Service management” som gör skillnaden. Det första teamet fick bara ha fyra personer som skall byta däcken, tank m.m. medans det andra teamet hade tjugo personer, bättre verktyg etc… därför fick de också väldigt olika resultat. En stor del av detta beror så klart på att det inte var tillåtet att vara så många 1950 samt att viss teknik, som skruvdragare, etc. inte fanns tillgängligt. Men det är ju trots allt resurserna som avgör.
Därför är det viktigt att se till att vi har de resurser vi behöver och att vi tänker på alla fyra dimensionerna!
För att utveckla våra Value Streams och hur vi arbetar kan vi använda en metod som kallas ”Value Stream Mapping”.
Kortfattat kan vi säga att det innebär att vi tar reda på alla aktiviteter som ingår i en Value Stream. Listar dem, ofta görs det med post-it’s på en stor vägg, och tittar på hur varje aktivitet bidrar till att leverera värde.
När vi har en tydlig bild av hur vår value stream fungerar idag kontrollerar vi följande:
Saknas det någon aktivitet eller uppgift?
Är det något som inte bidrar till att leverera värde?
Sker stegen i ”rätt ordning”?
När det är klart uppdaterar vi vår Value Stream samt berörda processer och arbetssätt .
Frågor och diskussion:
Under frukostmötet fick vi in lite frågor, bland annat om hur vi gör om vi vill arbeta mer agilt med ITIL.
Kort sagt kan vi säga att det handlar om att anamma ett agilt förhållningssätt i hur vi använder ITIL och ITIL 4 beskriver även en hel del av detta i det utökade materialet kring ”practices” som finns beskrivet av Axelos.
Vill du höra mer om det kan du titta på vår video.
Summering
En Value Streams handlar om att skapa ett flöde som bidrar till värde för våra stakeholders och när vi göra de olika aktiviteterna i våra Value Streams använder vi processer för att skapa bra arbetssätt.
Genom att arbeta med våra Value Streams och våra processer kan vi skapa en effektivare organisation samt bättre IT tjänster och därmed högre värde.
Vill du veta mer?
ITIL practices
Här kan du läsa detaljerna kring ITIL’s practices.
ITIL kurser
Foundation
Create, Deliver & Support
Drive Stakeholder Value
Direct, Plan & Improve
High Velocity IT
Digital & IT Strategy
Kontakta oss gärna om ni vill ha hjälp! Vi utlovade ju bland annat en timmes onlinemöte med de av er som vill prata mer om just hur Value Streams påverkar just er organisation. Kontakta Andreas på andreas.lindstrom@larssonco.com så hjälper han till.
På vårt frukostmöte i fredags, pratade vi om just vad ITIL 4 säger om Service Desk och därför har vi här summerat våra tankar kring detta och vad vi bör tänka på när vi utvecklar vår Service Desk.
Syftet med Service Desk är, enligt ITIL 4, att ”vi skall samla in behov för Incident & Requests”. Dessutom skall Service Desk vara ”startpunkt och Single point of contact för alla användare”, alltså skall all kommunikation med användarna, i första hand skall ske via Service Desk.
Purpose: “To capture demand for incident resolution and service requests. It should also be the entry point and single point of contact for the service provider with all of its users.”
Framgångsfaktorer
ITIL 4 beskriver de ”Framgångsfaktorer” som krävs för att vi skall lyckas med att skapa en effektiv Service Desk som:
Att möjliggöra:
effektiv & smidig kommunikation med våra användare
effektiv hantering av användar-kommunikation, in i ”Value Streams”
Vad innebär det att ha ”effektiv och smidig kommunikation”?
Det går att summera i att en bra Service Desk skall vara ”Convenient” som om vi översätter det betyder bekväm/lämplig/läglig.
Det betyder enkelt förklarat att en bra Service Desk, enligt ITIL 4, skall vara:
Tillgänglig – lätt att komma i kontakta med
Åtkomlig – användarna skall känna att de kan använda vår Service Desk, vi behöver använda rätt språk och även bemöta kulturen.
”Regelrätt” – eller ”säker”, att vi följer lagar och regler och hanterar personuppgifter m.m. på ett korrekt sätt.
Välkända kanaler – ITIL 4 tar upp det faktum att vi skall, så långt det går, använda kanaler som användarna känner till och är vana att använda.
Tjänste-empati – att vi hanterar kunden på ett empatiskt sätt, läs mer längre ner om ”Känsla”
Integrerade kanaler – Att vi samlar information från våra olika kanaler så att vi har tillgång till den information som finns om användaren och dess ärende
Service Desk & ”The Four Dimensions of Service management”
ITIL 4 delar in de resurser som vi behöver i ”de fyra dimensionerna av tjänstehantering”. För att skapa en bra Service Desk behöver vi se till att vi har rätt resurser och för att veta vilka resurser det är behöver vi veta vilka tjänster vi levererar och till vilka olika kunder och användare. Det ger oss förståelse för är det viktigt att vi har rätt resurser, det kan handla om ärendehanteringssystem, kommunikationsverktyg, kunskapsdatabaser m.m. Bilden längre ner visa några exempel på de resurser som vi behöver se över.
Vertikal eller horisontell Service Desk?
ITIL 4 pratar om att vi kan bygga upp Service Desk vertikalt eller horisontellt.
Vertikalt innebär att vi först har en ”1st line” som tar emot ärenden. Vissa ärenden eskaleras till ”2nd line” för att få mer teknisk kompetens och sen eventuellt även till en 3rd line beroende på vad ärendet handlar om.
Horisontell Service Desk betyder att ärenden hanteras på en nivå och där man använder ”Swarming” för att involvera rätt personer i varje ärende. Detta stimulerar kunskapsspridning och kan vara en bättre väg i vissa organisationer. Vilket vi väljer beror självklart på vår organisationen och vad som passar oss bäst.
Utöver detta är det viktigt att titta på vilka resurser vi behöver, det kan vara språk, kultur, kompetenser, systemstöd, kunskapsdatabas, support från leverantörer, kommunikationskanaler m.m.
Det räcker inte bara med rätt resurser, vi behöver även fokusera på hur vi gör vårt jobb i vår Service Desk. Hur uttrycker vi oss etc…
ITIL 4 fokuserar mer på de ”mjuka delarna” än vad ITIL v3 gjorde. Därför trycker man mer på hur vi hanterar vår Service Desk. Vi har summerat det i tre delar:
Kompetens
För att vi skall lyckas är det viktigt att vi har rätt kompetens. De flesta tänker då på den rent tekniska kompetensen men här pratar vi även om kompetens avseende:
Business focus before technical knowledge, does not need to be highly technical…
ITIL 4
Språk & kultur
Att hantera människor i olika situationer
Fokus ligger på att vi skall vara empatiska, kommunikativa, strukturerade och ha bra Kundservice skills.
Kännedom
För att kunna erbjuda en bra Service Desk behöver vi kunna hantera information i flera kanaler och integrera den information vi får in.
Detta för att vi hela tiden skall veta vad användaren vill och förstå vad som hänt tidigare i ärendet.
Känsla
Känsla handlar mycket om det som ITIL beskriver som ”Service Empathy” eller Tjänsteempati.
Det handlar om förmågan att upptäcka, förstå och förutse behoven & upplevelsen hos användarna för att kunna skapa, upprätthålla och förbättra relationen med användarna.
Men det handlar inte om att hålla med användaren om allt utan om att förstå dem och hjälpa dem utifrån den situation de är i.
Diskussioner
Det kom upp en fråga om vad ITIL 4 säger om Service Desk manager och i Service Desk Practice beskrivningen finns Service Desk manager med som roll. Det beskrivs inte i detalj hur rollen ser ut men däremot beskrivs vilka uppgifter en Service Desk manager bör ha kring utveckling av Service Desk samt kring hur vi kommunicerar med användare.
Dessutom kom det förslag på kommande ämnen, har du förslag eller frågor så är du givetvis välkommen att höra av dig till oss.
Summering
För att summera så fokuserar ITIL 4 mycket mer på en Service Desk som tar hand om användarna och hjälper dem genom att samla in deras behov och ta med den in i våra Service Value Streams.
Vill du veta mer?
ITIL practices
Här kan du läsa detaljerna om hur ITIL 4 ser på t.e.x Service Desk.
ITIL kurser (de tre första hanterar Service Desk)
Foundation
Create, Deliver & Support
Drive Stakeholder Value
Direct, Plan & Improve
High Velocity IT
Digital & IT Strategy
Kontakta oss gärna om ni vill ha hjälp!
Vill du se Frukostmötet?
Här kan du se filmen från vårt frukostmöte om ITIL 4 & Service Desk:
31:a aug-2:a Sept genomfördes, trots pandemi, ännu en lyckad kurs på Marstrands Havshotell. Genom åtgärder från hotellet, större kurslokal än normalt kunde vi på ett tryggt sätt genomföra vårens ITIL 4 Foundation – All Inclusive som planerat.
Förutom ett aktuellt och intressant innehåll så visade Marstrand upp sig från sin bästa sida och bjöd på underbart väder.
Dessutom hade Marstrand besök från Greenpeace som laddade upp inför den uppmärksammade aktionen i Lysekil. Tycka vad man vill om det, men det var hur som helst ett vackert skepp.
På vårt frukostmöte den 28 augusti pratade vi om ITIL 4’s Practices Incident, Problem & Change som tidigare har beskrivits av ITIL som processer.
Vad är skillnaden på Processer och Practices?
Vi började pratade om skillnaden mellan det som ITIL 4 beskriver som Pratices och hur det skiljer sig mot det som beskriv som Processer i ITIL v3.
Skillnaden är att practices inkluderar mer än bara själva processen. Man har lyft begreppet för att tydliggöra att det är mer än bara just processen som krävs. För att lyckas med Incident, Problem & Change krävs det att vi har rätt resurser som beskrivs i:
”The Four Dimensions of Service management” som består av:
Orgnization & People
Information & Technology
Partners & Suppliers
Value Streams & Processes
När vi arbetar med till exempel Incident mgmt. behöver vi alltså se till att vår process är utformad och används på rätt sätt men vi behöver även se till att vi har täckt in övriga delar. till exempel att vi har rätt organisation med en kultur som stödjer våra mål, att vi har rätt medarbetare med rätt kompetens m.m.
Incident management handlar om att ”Minimera påverkan av Incidenter, genom att återställa ordinarie tjänsteleverans så snabbt som möjligt”
Framgångsfaktorer:
Upptäcka incidenter tidigt
Lösa incidenter snabbt och effektivt
Kontinuerligt förbättra hanteringen av incidenter
Problem Management
Problem managment handlar om att ”Minimera troligheten och påverkan av Incidenter, genom att identifiera verkliga och möjliga orsaker till Incidenter och att hantera ”workarounds” och ”Known Errors”.
Vi pratade även om de tre delarna som beskrivs i ITIL 4. Samt givetvis vad som är viktigt att tänka på.
Framgångsfaktorer:
Identifiera och förstå problemen och hur de påverkar tjänster
Optimera problemlösningar och mitigeringar.
Change Enablement
ITIL har gått från Change Mangement till Change Enablement och vi pratade om varför det är bättre.
Change Mangement handlar om: ”Att maximera antalet framgångsrika tjänste och produkt förändringar genom att säkra att vi har bedömt risken, godkänt förändringen att fortsätta och hanterat vårt change schedule”.
Vi pratade även om att det är viktigt att vi väljer rätt ”Change Authority” för att lyckas möjliggöra förändringar utan onödiga fördröjningar.
Framgångsfaktorer:
Säkerställa att förändringar genomförs i tid och på ett effektivt sätt
Minimera den negative påverkan av förändringar
Möt förändringsrelaterad governance krav och behov.
Change Management, eller Change Control, nej, vi menar givetvis Change enablement. Man säger ju att kärt barn har många namn.
Vill du se Frukostmötet?
Du hittar inspelningen från veckomötet på vår Youtube-kanal.
Se våra övriga filmer om ITIL på vår Youtube-kanal.
Läsa mer om eller titta på våra tidigare Frukostmöten?
