Change Management

Detta är en förkortad text, du hittar mer utförliga beskrivningar i boken

Change management-processen håller ihop hela överlämningsfasen, från att den aktuella funktionen tar beslutet att en förändring ska genomföras i processen kontinuerlig förbättringtill att driftansvarig formellt tar över ansvaret för den genomförda förändringen.

En förändring definieras som:

”Ett tillägg, en förändring eller en borttagning av något som kan påverka leveransen av IT-tjänster eller tillhörande dokumentation.”

Syfte och omfattning

Huvudsyftet med change management-processen är att säkerställa att förändringar registreras, utvärderas, prioriteras, planeras, testas, etableras och dokumenteras på ett kontrollerat sätt.

Det sker genom att i alla förändringar som genomförs:

  • Säkerställa att all information om förändringen finns registrerad
  • Bedöma om förändringen behöver genomgå tjänstedesign
  • Använda beprövade och dokumenterade metoder och rutiner
  • Utreda vilken påverkan förändringen har på IT-miljön
  • Beakta risken för verksamheten
  • Säkerställa att alla aktuella aspekter av förändringen har beaktats
  • Koordinera driftsättningen med övriga förändringar
  • Säkerställa att det finns en återställningsplan inför driftsättning

Varje IT-organisation måste själv besluta vilka förändringar som ska registreras i change management-processen. Det finns ingen standardnivå som fungerar för alla. Det fungerar heller inte att sätta en nivå för samtliga tjänster när till exempel ett byte av en reservdel i en PC inte behöver registreras i change-processen, medan samma reservdel i en central lagringslösning behöver kontrolleras mer noggrant eftersom den innebär en större risk.

Utöver change management-processen sker förändringar även i driftuppgifteroch i request fulfilment-processen. Att tvinga IT-organisationen till att registrera dessa ärenden även i change management-processen är inte effektivt.

Eftersom både driftuppgifteroch request fulfilmentbygger på dokumenterade rutiner blir den praktiska lösningen att varje ny rutin registreras som en förändring i change management-processen där rutinen kvalitetsgranskas och godkänns som en standardändring. Därefter kan rutinen genomföras i respektive process utan dubbelregistrering av ärendet. Det viktiga är att alla förändringar registreras så att spårbarheten finns om något skulle gå fel.

Ändringstyper

Change management-processen fungerar som en kvalitetskontroll av förändringar som ska genomföras i IT-miljön. En noggrann granskning av varje förändring skulle ta mycket tid och resurser. Dessutom skulle det administrativt fördröja genomströmningen av förändringar så mycket att IT-organisationen inte skulle acceptera processen.

Därför delas förändringsärenden in i olika typer som bygger på vilken risk förändringen har att påverka IT-miljön negativt om något skulle gå fel.

Beslutsgrupper

Beslut i processen

Det finns två nivåer av beslut i processen, en som avgör omen förändring ska genomföras, och en som godkänner kvaliteten inför driftsättning.

Eftersom mandatet för att fatta beslut om en förändring ska genomföras finns i olika forum och på olika nivåer i styrmodellen, används change control board (CCB) som generell benämning för dessa forum.

Change Control Board (CCB)

Change control board är en generell beteckning för de forum som har mandat att besluta om förslag till förändringar. Till exempel en funktion eller en projektstyrgrupp. Förändringsförslagen utreds, bedöms och prioriteras tillsammans med alla andra förslag till förbättringar i processen kontinuerlig förbättring. De förslag som beslutas att de ska genomföras hanteras vidare i change management-processen och drivs av respektive forum.

Change Advisory Board (CAB)

Change advisory board (CAB) är det forum som beslutar om en förändring har tillräcklig kvalitet för att driftsättas i IT-miljön. CAB drivs av change manager men består av olika deltagare beroende på vilka driftsättningsärenden som ska hanteras. Syftet med CAB är att samordna, planera och kvalitetsgranska större driftsättningar så att risken för störningar i verksamheten minimeras.

Ett exempel på bemanning av CAB är:

  • Change manager (sammankallande)
  • Representant för CCB (ärendeägare)
  • Driftansvarig (mottagare)
  • Ansvarig service desk (mottagare)
  • Systemspecialist (expert på systemet)
  • Tekniker (expert på infrastrukturen)

Varje representant för respektive CCB föredrar sina egna ärenden. Även om det på det aktuella mötet inte finns några ärenden för ett specifikt CCB så finns det en samordnande kvalitetskontroll i att samtliga CCB finns representerade på varje CAB iallafall.

Förändringar i IT-miljön är ofta en del av en förändring i verksamheten. Vid denna typ av förändringar har verksamheten en stark knytning till de beslut som tas i change management-processen. Alla beslut från design och finansiering till driftsättning och godkännande är egentligen verksamhetsbeslut i verksamhetens egen beslutsprocess. I dessa situationer sköts samordningen mellan förändringen inom IT-organisationen och förändringen inom verksamheten av CCB forumet.

Aktiviteter

Alla önskemål och förslag till förändringar måste prioriteras av respektive funktion tillsammans med allting annat som ska göras i processen kontinuerlig förbättring. Först efter att funktionen har beslutat att gå vidare med ett förändringsförslag så registreras ärendet som en request for change (RFC) i change management-processen.

Om förändringen är komplex, omfattar flera olika områden eller innebär en hög risk så ska ett designpaket utformas i processen tjänstedesign. Designpaketet omfattar alla aspekter på en förändring och säkerställer att förändringen verkligen uppnår sitt syfte samt att IT-organisationen kan leverera den tänkta funktionaliteten efter driftsättning.

Nästa steg är att godkänna designen. För stora och komplexa förändringsförslag är det först i detta steg som konsekvenserna är belysta och CCB har ett komplett beslutsunderlag. Är förändringen resultatet av en förändring i verksamheten ska beslutsunderlaget för godkännande lyftas till verksamhetens beslutsprocess.

Efter ett formellt godkännande av designen ska CCB koordinera utveckling och test av förändringen. Omfattningen på detta steg kan variera från några timmar till flera månader beroende på storleken på förändringen. Aktiviteterna utveckling och test sker i release management-processen. Här sker även en övergång från att betrakta förändringen som ett enda ärende till att hantera flera releasepaket. En större förändring delas oftast upp i flera releaser och i resterande del av change management-processen hanteras varje specifikt releasepaket som ett eget ärende. Det ursprungliga förändringsärendet ligger kvar under hela förändringen och knyter samman alla releaseärenden.

Den funktionella testen av ett releasepaket sker i release management-processen. När paketet kommer tillbaka till change managementär det kvaliteten inför driftsättning som ska godkännas. Här är första gången som change advisory board (CAB) samlas för att granska ärendet.  CAB ansvarar även för att koordinera driftsättningen på en övergripande nivå vilket sker genom att alla aktuella driftsättningar planeras in i det gemensamma förändringsschemat.

Driftsättningen sker i release management-processen som testar och säkerställer att funktionaliteten och kvaliteten i releasepaketet uppnåtts. Denna testperiod kan vara flera veckor vid större releaser. Efter driftsättningen tas ärendet åter upp i CAB forumet för godkännande av drift. Här sker det formella överlämnandet mellan projektet som utvecklat förändringen och driftansvarig.

När en förändring eller ett releasepaket är godkänt och överlämnat till drift utvärderar och stänger change manager alla förändringar som passerat processen med syftet att identifiera förbättringsförslag. Även genomförda standardförändringar utvärderas för att upptäcka om någon av dessa har resulterat i störningar.

I utvärderingen ställer change manager frågan om en störning som uppkommit beror på att dokumenterade rutiner inte har följts eller om rutinerna behöver förbättras. Vid större störningar eller problem som uppstått under ärendets gång ska en utredning göras för att analysera anledningen till att det hände och vad som kan göras för att det inte ska hända igen. Denna utredning brukar benämnas som post implementation review (PIR).

Change Management process

KONTAKTA OSS

VI är inte online just nu, men skicka oss ett meddelande så svarar vi dig så fort vi kan.

Sending

©2019 OpenTRIM® a model to ease the adoption of ITIL®, OpenTRIM® is a registered trademark of OpenTRIM AB. All rights reserved. ITIL® is a registered trademark of AXELOS AB. All rights reserved.

Log in with your credentials

Forgot your details?