Allt du behöver veta om effektiv förändringshantering (change management).
Affärslandskapet och kundernas förväntningar förändras ständigt och den digitala omvandlingen har blivit en viktig bidragande orsak till företagens framgång i olika branscher. Digital transformation handlar om att utnyttja tillgänglig teknik för att ta itu med affärsutmaningar och ta vara på möjligheter.
När du bryter ner det är digital omvandling i grunden IT-hantering gjord på ett bättre sätt för att eliminera problematiska områden och utrusta din IT-infrastruktur för att möta affärsutmaningar. Och det handlar om att implementera IT-förändringar som hjälper din organisation att tillämpa ny teknik på befintliga affärs- och IT-processer.
Dessa förändringar kan vara så enkla som att flytta samarbetsappar till molnet för bättre drifteffektivitet eller använda en mobil-först-metod för en bättre konsumentupplevelse. Trots sin enkelhet, så kommer dessa förändringar med sina egna logistiska utmaningar. Om du inte implementerar en förändring på rätt sätt kan organisationen ta ett steg framåt och två steg tillbaka.
En populär banks misslyckade uppgradering av sin mobilapp i december 2018 är ett bra exempel på hur man inte ska genomföra en förändring. Bankens plan att införa en ny och förbättrad mobil bankapp var en bra idé och en välbehövlig sådan. Men från det att den nya appen lanserades hade den problem. Banken introducerade den nya appen efter att den gamla redan fasats ut. När den nya appen inte fungerade kunde tusentals kunder inte komma åt sina bankkonton via appen. För att göra saken värre, kommunikationen om en fix för den nya appen var minimal, vilket gjorde kunderna frustrerade. Mobilappen var nere i fyra dagar innan banken bestämde sig för att ta tillbaka den gamla appen.
Vi kan se att banken misslyckades i olika skeden av den föreslagna förändringen: att släppa den nya appen när den inte var redo att distribueras, inte vara transparent och kommunicera driftstopp i samband med uppdateringen till slutanvändare, och inte komma med en alternativ plan i händelse av fel. Detta är definitivt inte hur du vill att din förändring ska genomföras.
Det är här förändringshantering (change management) kommer in; den hjälper dig att hantera alla olika förändringar i din organisation och ger dig en process för att effektivt distribuera förändringar utan att påverka resten av organisationen. Förändringshantering minskar risken för störningar liknande den som banken hade.
I den här guiden täcker vi vad, varför och hur förändringshantering fungerar. Du får lära dig hur du hjälper din organisation att hålla jämna steg med branschtrender med effektiva förändringar.
Låt oss sätta igång!
ITIL beskriver förändringshantering som processen att spåra och hantera en förändring under hela sin livscykel, från början till slut, i syfte att minimera risken.
Genom att skapa en systematisk förändringshanteringsprocess kan din organisation genomföra incidentfria förändringar med stor framgång.
Enligt ITIL, är en förändring ett "tillägg, förändring, eller avlägsnande av något som kan ha en direkt eller indirekt effekt på tjänster."
I sin enklaste form kallas alla förändringar av en organisations IT-infrastruktur som kan påverka organisationens verksamhet en IT-ändring. Detta inkluderar utbyte av skrivare, projektorer, servrar med mera.
Ärende |
Problem |
Förändring |
|
Definition |
Enligt ITIL, en incident är "ett oplanerat avbrott i en tjänst eller minskning av kvaliteten på en tjänst." |
Enligt ITIL, ett problem är "en orsak, eller potentiell orsak, av en eller flera incidenter." |
Enligt ITIL, en förändring är "tillägg, förändring, eller avlägsnande av något som kan ha en direkt eller indirekt effekt på tjänster." |
Omfattning |
Återställa normal service så snart som möjligt |
Identifiera orsaken till störningar i normal service. |
Implementera en förändring som åtgärdar orsaken för att förhindra ytterligare störningar i normal serviceå. |
Karaktär |
Reaktiv |
Reaktiv och proaktiv |
Reaktiv och proaktiv |
Exempel |
Det går inte att ansluta till nätverket. En lösning utfärdas för att lösa incidenten och ge användarna åtkomst till nätverket. |
Ett problemärende skapas för att utföra grundorsaksanalys (RCA). En nätverksswitch fungerar inte, vilket leder till incidenten. Switchen måste bytas ut. |
Ett förändringsärende skapas för att ersätta den defekta switchen. |
Nu när vi vet vad förändringshantering är, låt oss titta på varför organisationer behöver det, med början i målen för förändringshantering.
Förändringshantering ger dig bättre kontroll över din förändringsprocess och hjälper dig att genomföra förändringar med minimal risk. Genom att följa standardprocesser säkerställer förändringshanteringen att alla aspekter av varje förändring, till exempel planering, riskbedömning och spårning av implementeringen, hanteras effektivt. Att använda ett servicedesk-verktyg för att spåra förändringar från början till slut kan göra underverk och göra det möjligt för en organisation att bättre hantera sin IT-infrastruktur med välplanerade och utförda förändringar.
Genom att spåra hela förändringsprocessen gör förändringshantering det möjligt för organisationer att hålla koll på alla förändringsbegäranden. Det gör det också lättare att identifiera och begränsa antalet obehöriga förändringar. Genom att endast tillåta användare att skicka begäran om förändring (RFC) via servicedesk-verktyget kan organisationer samla in all nödvändig information om förändringen från början och sedan bestämma om förändringen behöver genomföras. En robust godkännandemekanism säkerställer att förändringar får alla nödvändiga godkännanden och behörigheter innan de implementeras.
Förändringshantering är inte bara till för när det går fel; det syftar till att hjälpa organisationer att kontinuerligt förbättra sin infrastruktur och sina processer, samt hålla jämna steg med branschtrender genom att se till att de smidigt kan rulla ut de nödvändiga förändringarna utan att påverka den nuvarande serviceverksamheten.
Låt oss nu titta på hur du kan implementera förändringshantering i din organisation. Det första är att skapa en effektiv förändringsprocess som gör att du kan planera förändringar, få nödvändiga godkännanden och implementera förändringar.
Här är en förändringshanteringsprocess som du kan följa för att effektivt hantera förändringar.
Det första steget är att initiera förändringen. Detta innebär att samla in grundläggande förändringsärendeinformation såsom förändringstyp och prioritet.
Nästa steg är där planeringen av hela förändringen sker. En välplanerad förändring är hemligheten till ett framgångsrikt genomförande av förändringar. Det är också viktigt att få de nödvändiga godkännanden som krävs för att genomföra förändringen. Detaljer som effekterna, utrullningsplaner, backout-planer och tillhörande driftstopp dokumenteras för att tydligt förmedla förändringsplanen till intressenter och övertyga dem om att förändringen är värd att göra.
Därefter måste förändringsplanen godkännas av förändringsrådet (CAB - Change Advisory Board) eller den rådgivande nämnden för nödåtgärder (ECAB - Emergency Change Advisory Board) och alla andra funktioner som har en del i förändringen eller i den organisatoriska infrastruktur som påverkas av förändringen. Genom att skapa anpassade förändringsråd kan organisationer gruppera relevant personal för att enkelt hantera godkännanden. Automatisering av godkännandeprocessen snabbar upp hela förändringen och säkerställer att inga godkännandeärenden förbises.
CAB är en kombination av olika jobbroller och team. Det kan omfatta chefer på C-nivå, teamchefer, tekniska team, ekonomipersonal med mera, beroende på förändringens allvarhetsgrad och omfattning.
När de nödvändiga godkännandena har erhållits kan förändringen genomföras. Organisationer kan spåra och hantera implementeringen av förändringar genom att skapa uppgifter eller skapa ett projekt.
Därefter genomförs en översyn efter genomförandet för att säkerställa att det inte finns några avvikelser i genomförandet och eventuella frågor avklaras innan förändringen avslutas.
Detta är det sista steget i förändringshanteringsprocessen. Den slutförda förändringens art registreras som lyckad, misslyckad eller ofullständig. Om du anger och registrerar rätt stängningskod blir en organisations förändringsarbete mer mätbart och användbart.
Alla förändringar är inte desamma, eftersom vissa har olika krav. Vissa förändringar måste genomföras så snart som möjligt, vissa behöver godkännande från organisationens ledning, och vissa är bara normala förändringar som genomförs varje vecka.
Enligt ITIL kan förändringar i stort sett delas in i tre typer: standard, normal och akuta förändringar.
Dessa är förgodkända förändringar som är lågpåverkande, välkända och dokumenterade. Standardförändringar kräver en riskbedömning och auktorisering när den implementeras för första gången, men efterföljande implementeringar kan göras utan dessa försiktighetsåtgärder så länge förändringen inte har ändrats. Exempel: Byta ut en skrivarbläckpatron
En normal förändring måste följa hela förändringsprocessen. Den bör schemaläggas, få sin risk bedömd och godkännas. Normala förändringar omfattar både mindre (låg till medelhög påverkan och brådska) och större förändringar (stor påverkan och brådska). Alla förändringar som inte är standard- eller nödåtgärder bör behandlas som normala förändringar och följa förändringsprocessen. Exempel: Flytta lokala tjänster till molnet
Akuta förändringar har stor inverkan och brådska, vilket kräver snabb bedömning, godkännande och genomförande för att få igång tjänsterna så snart som möjligt. Förändringar av komponenter som påverkar affärsverksamheten och därmed orsakar driftstopp behandlas som nödändringar. Exempel: Primärt serverfel, avbrott i datacenter och nödkorrigering för säkerhetsproblem.
Förändringshantering involverar flera olika roller med olika ansvarsområden. Här är de vanligaste rollerna:
Förändringsägaren är ansvarig för hela förändringshanteringsprocessen, inklusive dess förbättring. Eftersom de är ansvariga för förändringshantering på sin organisation så är det oftast en högt uppsatt tjänsteman.
Förändringsledaren hanterar implementeringen av förändringen och de aktiviteter som är relaterade till den. De leder också CAB och de olika team och intressenter som är inblandade, och samordnar med dem.
Förändringsinitieraren är den som initierar förändringen och lägger till förändringsplaner, implementeringsplaner och annnan information som krävs. De organiserar också planen för förändringsgenomförande. En förändringsinitierare kan antingen vara tekniker eller slutanvändare.
CAB(Change Advisory Board) är en samling av olika medlemmar från olika team och jobbfunktioner. Tillsammans analyserar de den föreslagna förändringen och ger sitt godkännande och rekommendationer om förändringen och dess genomförande.
Vissa organisationer använder anpassade roller utöver dessa fyra huvudroller för att delegera arbete och dela upp ansvarsområden. Att kunna skapa anpassade roller hjälper dig att skräddarsy din förändringshantering efter organisationens behov. Några vanliga ytterligare roller är:
Process & roller |
Förändrings-ledare |
Förändrings- initierare |
CAB |
Förändrings- ägare |
Inlämning |
C |
R |
- |
A |
Skapandet |
C |
R |
- |
A |
Definiera förändringsroller |
C |
R |
- |
A |
Planering |
C |
R |
- |
A |
Godkännande |
R |
I |
C |
A |
Genomförandet |
C |
R |
- |
A |
Delegering av arbete genom uppgifter |
C |
R |
- |
A |
Utnyttja projektledning |
C |
R |
- |
A |
Granskning |
R |
I |
- |
A |
Stängning |
C |
R |
- |
A |
* R - Responsible, A - Accountable, C - Consulted, I - Informed
Här är fyra gemensamma utmaningar som kan hindra förändringshantering.
Förändringar tar upp en hel del resurser, eftersom mycket tid går till planering av förändringar. Ett stort antal misslyckade förändringar kan snabbt bli dyrt. Vid infrastrukturförändringar kan en hög felfrekvens leda till större problem antingen under implementeringen eller när backout-planerna implementeras. Många misslyckade förändringar är också en indikator på en dålig förändringshanteringsprocess.
Exempel: Zylker planerade att uppgradera sin primära nätverksinfrastruktur, så företaget har skapat ett alternativt nätverk med en tredjepartsnätverksleverantör. De planerade att genomföra förändringen under en helg. Under genomförandet fick Zylker ärenden om att tjänster är nere, vilket var förvånande med tanke på att företaget hade inrättat ett alternativt nätverk. Det visade sig att den alternativa nätleverantören också utförde schemalagt underhåll den helgen, vilket innebar att både Zylkers primära och alternativa nätverk var nere, vilket gjorde Zylkers tjänster otillgängliga. Eftersom förändringen inte var planerad på rätt sätt, misslyckades den.
Obehöriga förändringar är resultatet av en bristfällig godkännandemekanism och underlåtenhet att inkludera rätt intressenter i godkännandestadiet. Dessa förändringar kringgår nödvändiga behörigheter och kan sluta implementeras om de inte flaggas i tid. Obehöriga förändringar kan leda till förändringar som din organisation inte behöver eller inte är redo att implementera. Summan av kardemumman är att obehöriga förändringar är dåliga och en onödig kostnad.
Som tidigare förklarats kräver akuta ändringar ett snabbt godkännande så att de kan genomföras så snart som möjligt. Att behandla för många förändringar som akuta förändringar kan leda till förseningar i händelse av en allvarlig akut förändring som måste genomföras. Det är alltid bra att vara försiktig när man klassificerar en förändring som en akut förändring.
Den populära historien om pojken som ropade varg är en bra analogi för varför det är dåligt att behandla för många förändringar som akuta förändringar. I händelse av en verklig nödsituation, kanske inte din organisation tar förändringen med det allvar som krävs, och du kanske inte har de resurser som krävs för att hantera nödsituationen.
Dålig planering kan leda till förändringskollisioner. En förändringskollision är när två eller flera förändringar oavsiktligt planeras att genomföras samtidigt, vilket stör genomförandet av antingen båda eller den ena förändringen. Om du använder en förändringskalender för att planera förändringarna bättre kan du förhindra att förändringar kolliderar.
Här är de bästa sätten att närma sig förändringshantering.
Alla förändringar är inte desamma. Förändringar har olika prioritetsnivåer och olika krav, vilket förklaras under avsnittet om typer av förändringar (hyperlänk för att ändra typer avsnitt). Därför är det viktigt att först identifiera vilka typer av förändringar som din organisation kan utföra och sedan skapa olika förändringstyper för att effektivt distribuera dem.
Eftersom olika förändringstyper har sina egna unika krav måste du utforma unika processer för att uppfylla dessa behov. Om du använder samma förändringsprocess för alla förändringstyper leder det bara till onödiga förseningar och ofullständiga implementeringar av förändringar.
Du kan skapa olika förändrings-arbetsflöden för var och en av dina förändringstyper.
Genom att definiera roller kan förändringshanteraren delegera aktiviteter och ansvar till andra. Roller gör det enklare att hantera förändringar och de definierar tydligt de aktiviteter som varje person kan utföra.
Det är en bra idé att ha ett organiserat sätt att logga dina förändringar, samt hantera och prioritera dem på ett ställe. Med bättre insyn i organisationens förändringar kan du prioritera vilka förändringar som måste utföras före andra.
Alla förändringar måste gå igenom risk- och konsekvensanalys för att ni ska förstå förändringen bättre och fördela de resurser som krävs. Risk- och effektdetaljerna bör läggas till i planeringsstadiet så att CAB har en tydlig bild av förändringen och kan ge sin rekommendation.
Genom att definiera godkännandeprocessen är det enkelt att få de behörigheter som krävs för att en förändring ska implementeras. Det säkerställer att alla viktiga intressenter är medvetna om förändringar och ger sin rekommendation innan en förändring genomförs. Detta hjälper till att stävja obehöriga förändringar.
Genom att hålla berörda parter informerade om planerade förändringar minskar antalet incidenter som orsakas av förändringar. Genom att leverera snabb information säkerställs också att inga tjänster påverkas på grund av förändringar och att förändringen kan utföras effektivt. Som en bonus, ledningen är också nöjdare när de informeras under hela förändringens livscykel.
Att hålla ett öga på en förändring under hela förändringslivscykeln säkerställer att inget går fel och att förändringen genomförs enligt förändringsplanen. Genom att mäta viktiga mätvärden får du en tydlig bild av hur effektiv din förändringsprocess är och du kan också identifiera områden som du kan förbättra.
Du kan aldrig vara alltför förberedd, så det är alltid en bra idé att planera för det värsta scenariot och komma med en plan under förändringsplaneringen för att backa tillbaka. Den här djupgående planeringen kan innebära skillnaden mellan en misslyckad förändring som backats tillbaka och oåterkalleliga skador på din IT-infrastruktur.
Även om brandbekämpning är en viktig funktion för förändringshantering, har förändringar ett bredare omfång i din organisation. Att använda förändringar för att förbättra teknik och processer, och därmed ständigt förbättra organisationens förmåga att tillhandahålla bättre tjänster, är en viktig funktion för förändringshantering.
Detta whitepaper ger dig en inblick i hur förändringshatering (change management) fungerar i praktiken. Ta del av studieresultat, statistik och kunskap som hjälper dig att få en bättre förståelse för principerna bakom. Och inte minst praktiska tips från erfarna Change Managers.
Förändringshanteringens mål är inte enbart förmågan att slutföra en förändring. Förändringshanteringens förmåga att effektivt lansera förändringar kan dra stor nytta av information som samlas in i andra IT-servicehantering (ITSM) -processer och vice versa.
Möjligheten att associera incidenter med de förändringar som de orsakade eller orsakades av, eller uppdatera CMDB baserat på IT infrastrukturförändringar, är bara början på att skapa en hälsosam ITSM praxis.
Så här kan förändringshantering arbeta tillsammans med dina andra ITSM-processer:
Om du spårar de incidenter som orsakar en förändring och de som orsakas av en förändring får du en bättre förståelse för hur förändringar påverkar din organisation. Till exempel, när en router uppdateras, kan du få ärenden om att internet är nere. Genom att associera förändringar med de ärenden som de orsakade kan du snabbt identifiera orsaken till ett ärende och avstå från att behöva tilldela resurser för att åtgärda det specifika ärendet, eftersom det kommer att åtgärdas så snart förändringen har slutförts.
Det är viktigt att använda förändringar för tjänsteförfrågningar med stor genomslagskraft för att hålla IT-infrastrukturen uppdaterad. Utan förändringar slutar en tjänsteförfrågan för en serveruppgradering eller en förfrågan om att uppgradera Azure-lagringsutrymmet med tjänsten som levereras. Men när du använder en förändring för att implementera tjänsteförfrågningar kan du samla in mer information som orsaken till förändringen och implementeringsplanen, få nödvändiga godkännanden från alla intressenter och uppdatera CMDB med den nya informationen.
Obs: Att använda en förändring för tjänsteförfrågningar fungerar bäst för tjänsteförfrågningar med stor effekt och alla tjänsteförfrågningar som kräver en förändring av CMDB. Om det kräver att CMDB uppdateras, då behöver det en förändring!
Problemhantering kräver att du skapar en förändring för att åtgärda orsaken till ett problem. Att kunna skapa en RFC direkt inifrån ett problemärende gör det enkelt att spåra tillhörande förändringar och problem. Det ger också CAB en bättre bild av varför förändringen krävs, och betonar hur allvarligt problemet som initierade förändringen är.
Vid distribueringen av versioner och uppgraderingar kan du dra nytta av den strukturerade metod som förändringsprocessen medför. Du kan enkelt spåra implementerings- och distributionsplaner samt den faktiska implementeringen av versioner och distributioner med hjälp av förändringar. Förändringarnas öppenhet och synlighet bidrar också till att hålla alla berörda parter informerade.
Alla uppdateringar av CMDB bör alltid göras med en förändring. En förändring ger mycket användbar information om varför, hur och när uppdateringen gjordes. Konsekvensanalysen som utförs tillsammans med en förändring säkerställer också att alla uppdateringar av CMDB analyseras korrekt och att uppdateringen inte skapar några störningar i resten av organisationen. Du kan använda förändringstyper för att registrera CMDB-uppdateringar med varierande prioritet.
Här är några viktiga mått för att mäta effektiviteten i din förändringshanteringsprocess.
KPI |
Formel |
Kommentarer |
Antal obehöriga förändringar |
Antalet obehöriga förändringar som identifierats under en viss tidsperiod |
Ett lägre tal anger att godkännande-processen är robust och kan hantera alla förändringar. |
Antal tjänsteförfrågningar med stor genomslagskraft som har uppfyllts utan förändring |
Antalet serviceförfrågningar med stor genomslagskraft som uppfyllts utan en förändring under en viss tidsperiod |
Tjänstebegäranden med hög effekt måste uppfyllas med hjälp av en förändring. Ett högre tal är ett tecken på att infrastrukturen är sårbar för problem som att inte uppdatera CMDB. |
Procent av backade förändringar |
Procent av förändringarna som använde sin backout-plan på grund av problem under implementeringen |
Ett högre tal är en indikator på dåligt planerade förändringar. |
Förändringar acceptansfrekvens |
Den procentandel av förändringarna som godkändes av CAB |
Detta indikerar hur effektiva dina förändringsbegäranden och förändringsplaner är. Ett högre tal är ett tecken på att dina förändringar och planering är solida. |
Schemaavvikelse |
Avvikelsen i förbrukad tid och den beräknade tiden |
Detta indikerar om dina förändringar implementeras i tid och följer förändringsplanen. |
Antal incidenter som orsakas av förändring |
Antalet incidenter som orsakas av en viss förändring |
Detta anger om en förändring påverkar andra serviceåtgärder. Ett högt antal är tecken på att förändringar måste kommuniceras bättre. |
Procent av förändringarna som slutförts i tid |
Procent av förändringarna som slutförts i tid |
Detta indikerar om förändringsprocessen fungerar med optimal effektivitet. Ju högre procent, desto bättre förändringshanterings-process. |
Låt oss titta på en förändring i detalj för att se hur du kan förbättra din förändringshanteringsprocess.
Zylker, ett företag med ett stort antal fjärranvändare, bestämmer sig för att molnanpassa verksamheten.
För närvarande är alla företagets produktivitetsprogram och resurser interna, så fjärranvändare får VPN-åtkomst till nätverket. För att ge snabbare åtkomst till data bestämmer sig Zylker för att börja använda molnprogram. Företaget väljer Zoho One som produktivitetssvit och Office 365 för e-post. En del av företagets resurser, som dess filservrar och databaser, är fortfarande lokala, så fjärranvändare måste få tillgång till dessa också.
För att uppnå detta krav konfigurerar IT-teamet en hybridmiljö för Azure Active Directory (AD). De etablerar en federationsserver för att replikera sitt lokala AD i det molnbaserade Azure AD. Nu kan slutanvändare, även fjärranvändare, komma åt molnresurser med sina AD-autentiseringsuppgifter.
Det första steget är att generera ett förändringsärende och samla in nödvändig information om förändringen, till exempel förändringstyp, förändringseffekt och brådskandegrad och ange förändringsrollerna. Förändringsinitiatorn kan enkelt generera ett förändringsärende i sin webbportal och välja relevant förändringsmall och förändringstyp. Förändringsmallen samlar in all nödvändig information med obligatoriska fält. Här anger förändringsinitiatorn förändringstypen som vanlig, väljer lämplig förändringsmall, tilldelar förändringsrollerna och ger en beskrivning av varför förändringen krävs.
Därefter lägger förändringsinitieraren till förändringsinformationen, till exempel orsaken till förändringen, detaljerad information om dess effekt, distributions- och backout-planer och schemalagda driftstopp. Förändringsinitieraren lägger också till alla associerade incidenter och problem för att bättre spåra förändringen och dess inverkan. Nedan finns de olika planer som förändringsinitiatorn kom fram till.
Eftersom den befintliga konfigurationen är intakt återgår du till de gamla konfigurations- och återställningstjänsterna.
Planerad stilleståndstid: 12 timmar
Förändringshanteraren ställer in certifikatutfärdare för att granska förändringsplanen och ge sin rekommendation om huruvida förändringen behöver implementeras eller om planen behöver ändras. Eftersom detta är en storskalig förändring krävs godkännanden från olika jobbroller som spänner över en mängd olika funktioner. Här är en lista över CABs och medlemmar som deltar i godkännandeprocessen:
Zylker använder aktiviteter för att spåra implementeringen. Aktiviteter tilldelas olika tekniker och den ordning i vilken de behöver göras definieras med hjälp av aktivitetssamband. Förändringsägaren kan enkelt spåra förloppet för förändringsimplementeringen och hantera uppgifter på ett och samma ställe.
Här är hur Zylker bröt ner genomförandet i aktiviteter för att göra det enkelt att spåra och hantera genomförandet av förändringen:
Därefter granskas förändringsimplementationen av förändringsägaren/ledaren för att kontrollera eventuella avvikelser från planen. Eventuella avvikelser rapporteras och åtgärdas innan förändringen bedöms vara lyckad.
Slutligen stängs förändringen och en stängningskod tilldelas baserat på förändringens stängning.
Förändringsledaren mäter vissa KPI:er för att ta reda på hur effektiv förändringsprocessen är och identifiera områden som kan förbättras.
Här är en lista över funktioner som du behöver hålla utkik efter när du väljer ett servicedeskverktyg. Med dessa funktioner på plats så hjälper det dig att implementera en effektiv förändringshanteringsprocess i din organisation.
Här förklarar vi vanligt förekommande ord vid förändringshantering (change management).
Processen att initiera en förändring med ett giltigt skäl.
Den tidsperiod då en viss tjänst inte är tillgänglig.
Tillägg, förändring eller avlägsnande av allt som kan ha en direkt eller indirekt effekt på tjänster.
Processen att slutföra förändringar med minimala störningar och krockar.
Delegeringen av ansvar över de olika aspekterna av förändringen till olika medlemmar av organisationen
Ett oplanerat avbrott i en IT-tjänst, eller en minskning av kvaliteten på en IT-tjänst. Fel på en konfigurationsartikel, även om det ännu inte har påverkat en tjänst, är också en incident (t.ex. fel på en disk från en speglingsuppsättning).
En databas med alla organisationens konfigurationsobjekt och deras relationer.
Processen att identifiera och fastställa områden som kan förbättras för att göra tjänsterna bättre.
När två eller flera förändringar oavsiktligt planeras att genomföras samtidigt, vilket stör implementeringen av antingen den ena eller båda förändringarna.
En orsak eller potentiell orsak till en eller flera incidenter.
Processen att utvärdera de potentiella riskerna med en förändring.
En grupp bestående av olika intressenter som ger rekommendationer om förändringen och godkänner förändringsplanen.
Kommunikationspunkten mellan tjänsteleverantörer och organisationens användare.
Används för att registrera typen av förändringsstängning, till exempel misslyckad eller lyckad.
Processen att utvärdera om förändringsplanen följdes utan avvikelser, samt att undersöka genomförandet för att se om något behöver ändras.
Nu när du har fått en introduktion till förändringshantering och hur du implementerar effektiva förändringar är det också viktigt att behärska de andra ITSM-processerna. Ladda ner vårt paket med ITSM-resurser:
Nedan har vi samlat några andra kunskapsmaterial om enterprise service management, ITSM och ärendehantering.
Guide till ärendehanteringssystem
Blogg: Så lyckas du med införandet av en CMDB
Blogg: Fyrkantigt eller effektivt? Detta är Change Management
Blogg: Få kollegorna med dig i förändringsledning
E-bok: The many faces of ITSM-driven business improvement
Guide för att bygga en IT-självbetjäningsportal för ditt universitet
10 rapporter varje supportansvarig borde ha tillgång till