Flowchart for ændringsstyring (ITIL)

Sådan fungerer det

1. Omdøb banerne til de roller, I faktisk har

   Erstat Rekvirent, Ændringsansvarlig, CAB, Implementeringsteam og Serviceejer med jeres egne funktioner. Mange organisationer har én person, der både er ændringsansvarlig og formand for CAB, og mindre teams har slet ikke et separat implementeringsteam. Læg de baner sammen frem for at tegne en struktur, I ikke har, og hold jer til højst fem baner — ellers kan diagrammet ikke længere aflæses på et blik.

2. Definer jeres tre ændringstyper ved triage-beslutningen

   Skriv ned, hvad der kvalificerer som standard, normal og akut ved siden af beslutningen 'Ændringstype?', og sæt grænserne efter risiko og konsekvensomfang frem for efter arbejdsindsats eller sagsstørrelse. Hold listen over forhåndsgodkendte standardændringer kort nok til, at nogen reelt vedligeholder den, og giv hver standardændring en dokumenteret ændringsmodel, den skal følge.

3. Navngiv ændringsmyndigheden, dens kadence og dens akutte modstykke

   Notér ved CAB-trinnet, hvem godkenderne er, hvor ofte de mødes, og hvornår deadline for dagsordenen er. Definer ECAB for sig: den, der må godkende en rettelse uden for arbejdstid, er sjældent hele boardet. Reglen, de fleste teams lander på, er at godkende mundtligt inden for få minutter, skrive sagen samme dag og gennemgå den på næste CAB-møde.

4. Angiv, hvad vurderingsdokumentet skal indeholde

   Lav 'Dokumentér vurdering og rollback-plan' om til en rigtig tjekliste: berørte services og brugere, risikoniveau, afhængigheder, nedetidsvindue, testmetode, rollback-trin og hvem der udfører dem. CAB's beslutning er kun så god som dette dokument — og det er præcis det, en auditor beder om måneder senere.

5. Gør reglerne for planlægning og konflikter eksplicitte

   Angiv jeres fredningsperioder, minimumsvarsler og hvem der ejer ændringskalenderen. Konflikttjekket i dette diagram er bevidst en beslutning og ikke en formalitet, fordi de fleste sammenstød er to teams, der rører en fælles afhængighed, og ikke det samme system. Beslut på forhånd, om en konflikt betyder ny planlægning eller eskalering.

6. Definer succes, og udgiv derefter proceduren med versionsstyring

   Sig, hvad 'Lykkedes ændringen?' betyder hos jer: hvilke smoke tests, hvor længe serviceejeren holder øje, og hvad der udløser beslutningen om rollback. Del derefter diagrammet dér, hvor arbejdet foregår — ved siden af ændringsanmodningen eller i runbooken — indhent godkendelse fra de personer, der er nævnt i det, og gem de tidligere versioner, så I kan vise, hvornår proceduren ændrede sig og hvorfor.

Ofte stillede spørgsmål

Er det it-ændringsstyring eller organisatorisk forandringsledelse?

It-ændringsstyring. De to deler navn og næsten intet andet. Dette flowchart er den ITIL-agtige driftsproces for ændringer af driftsatte services: en RFC oprettes, triageres, vurderes, godkendes, planlægges, implementeres, verificeres og lukkes. Organisatorisk forandringsledelse er den menneskeorienterede disciplin, der hjælper medarbejdere med at tage en ny arbejdsform til sig, typisk struktureret efter modeller som ADKAR eller Kotters otte trin — og den har hverken CAB, ændringskalender eller rollback-plan. Leder I efter interessentanalyse og kommunikationsplanlægning, er det her det forkerte diagram.

Hvad er forskellen på en standard-, en normal og en akut ændring?

En standardændring har lav risiko, udføres ofte og er forhåndsgodkendt efter en dokumenteret ændringsmodel, så den kræver ingen individuel godkendelse og går direkte til planlægning. En normal ændring er alt, der skal vurderes og godkendes på egne præmisser — det er vejen gennem risiko- og konsekvensvurdering til CAB. En akut ændring er en, hvor det ville gøre mere skade at vente på næste CAB-møde end selve ændringen, så den får en fremskyndet godkendelse i et akut CAB. I dette diagram mødes alle tre i den samme ændringskalender, implementering og evaluering, fordi kategorien ændrer godkendelsesvejen — ikke dokumentationen.

Skal alle ændringer forbi CAB?

Nej, og at sende alt derhen er den hurtigste måde at få folk til at arbejde uden om processen. CAB findes for at gennemgå ændringer, hvis risiko ikke allerede er kendt. Når en ændringstype er udført tilstrækkeligt mange gange til at have en pålidelig procedure og en kendt fejlmåde, så forfrem den til en standardændring med en dokumenteret model, og tag den af dagsordenen. Et CAB, der bruger mødet på at gummistemple rutinearbejde, gennemgår ikke noget — og køen, det skaber, skubber de reelt risikable ændringer over på den akutte vej.

Hvad skal der ske, når en ændring mislykkes?

Den følger den samme vej til lukning som en vellykket. I dette diagram udløser en mislykket verifikation i 'Lykkedes ændringen?' rollback-planen i implementeringsteamets bane, og den tilbagerullede ændring går derefter til evaluering efter implementering og lukning præcis som en vellykket. To ting får det til at fungere i praksis: rollback-planen var skrevet og godkendt, før ændringen blev kørt, i stedet for improviseret midt i hændelsen, og evalueringen spørger, om ændringstypen var den rigtige — ikke kun om ændringen virkede. Forsøg nummer to er en ny RFC, så det mislykkede forsøg beholder sin egen sag.