Flowchart for ændringsstyring (ITIL)

Hvad er flowchart for ændringsstyring (itil)?

Ændringsstyring betyder i denne skabelon it-servicerelateret ændringsstyring: den faste proces, enhver ændring af en driftsat service går igennem, fra en ændringsanmodning oprettes, til ændringssagen lukkes. Det er ikke organisatorisk forandringsledelse (den menneskeorienterede disciplin, der forbindes med modeller som ADKAR eller Kotters otte trin), selv om begge på dansk ofte kaldes "ændringsledelse". Den version, der er tegnet her, er den ITIL-agtige driftsproces, som en ændringsansvarlig og et Change Advisory Board (CAB) kører løbende.

Det meste af værdien ligger i én enkelt beslutning tidligt i forløbet: hvilken type ændring er det her? At sende alt gennem den samme fulde vurdering og det samme ugentlige board skaber en kø, og en kø er præcis det, der får folk til at lave ændringer uden om processen. Derfor triagerer diagrammet én gang, tidligt. Standardændringer er forhåndsgodkendt efter en dokumenteret ændringsmodel og går direkte til planlægning. Normale ændringer får en risiko- og konsekvensvurdering og går til CAB. Akutte ændringer får en fremskyndet godkendelse i et akut CAB og kobler sig derefter på præcis den samme vej til planlægning, implementering og evaluering, så en hastende rettelse aldrig bliver en uregistreret rettelse.

Det andet, et diagram afklarer, er ejerskab, og derfor er dette tegnet som swimlanes: Rekvirent, Ændringsansvarlig, CAB, Implementeringsteam og Serviceejer. Serviceejeren har sin egen bane, fordi verifikationen er det trin, teams oftest springer over. "Den er deployet" og "servicen virker" er to forskellige påstande, og forskellen mellem dem er hele grunden til, at rollback-vejen findes. I dette diagram udløser en mislykket verifikation rollback-planen, og både den vellykkede og den tilbagerullede ændring når frem til evaluering og lukning.

Hvad dette flowchart dækker

I denne skabelon

• Modtagelse på tværs af Rekvirent- og Ændringsansvarlig-banen: opret en ændringsanmodning (RFC), registrer den i ændringsregistret, og passer derefter filteret 'Er anmodningen komplet og i scope?', der sender tynde anmodninger tilbage til rekvirenten for at få de manglende oplysninger, før den samme kontrol gentages
• Tredelt triage i 'Ændringstype?', der sender standardændringer direkte til ændringskalenderen, normale ændringer til risiko- og konsekvensvurdering og akutte ændringer til godkendelse i ECAB
• Vurdering og godkendelse: vurder risiko og konsekvens for servicen, dokumentér vurdering og rollback-plan som ét samlet dokument frem for en sagstråd, og derefter CAB's gennemgang og beslutningen om at godkende eller afvise, hvor afviste ændringer ender i 'Ændring afvist og lukket' i rekvirentens bane
• Planlægning, hvor den godkendte, den akutte og standardvejen mødes i ændringskalenderen og rammer et konflikttjek mod andre planlagte ændringer, der sender sammenstød tilbage til ny planlægning
• Bygning og implementering i Implementeringsteamets bane: byg og test ændringen, og implementer den derefter i det godkendte vindue
• Verifikation og lukning: serviceejeren verificerer servicen og svarer på 'Lykkedes ændringen?', et nej udfører rollback-planen, og begge udfald mødes i evaluering efter implementering og lukning af ændringssagen

Hvornår du skal bruge skabelonen

• I skal skrive eller opdatere en ITIL-agtig procedure for ændringsstyring til en servicedesk, et platformsteam eller et infrastrukturteam, der i dag kører på vaner og chattråde
• I skal blive enige om, hvad der er standard, normalt og akut, før I konfigurerer ændringstyper i ServiceNow, Jira Service Management eller Freshservice, så værktøjet afspejler en beslutning, I allerede har truffet
• I skal introducere nye ændringsansvarlige, CAB-medlemmer eller vagthavende teknikere, der har brug for at vide, hvilke ændringer der kræver godkendelse, hvem der giver den, og hvad der gælder uden for normal arbejdstid
• I skal dokumentere over for en auditor eller en kunde, hvordan ændringer vurderes, godkendes, testes og rulles tilbage, for eksempel mod SOC 2-kriteriet CC8.1 eller ISO/IEC 27001:2022 Annex A-kontrol 8.32. Diagrammet dokumenterer proceduren; dokumentationen er de ændringssager, den producerer
• I skal ned med andelen af mislykkede ændringer efter et dårligt kvartal og har brug for at se præcis, hvor verifikation og rollback ligger, og hvem der ejer dem

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.