Flowchart for ændringsstyring (change control)

Hvad er flowchart for ændringsstyring (change control)?

Ændringsstyring er rækken af gates mellem 'nogen vil ændre noget' og 'ændringen er i drift'. Hver gate efterlader en registrering: hvad der blev anmodet om, hvad konsekvensvurderingen viste, hvem der godkendte, hvornår ændringen blev kørt, om verifikationen bestod, og hvad evalueringen konkluderede. I it- og driftsteams køres det typisk som ITIL-agtig change management med et CAB; i et reguleret kvalitetsstyringssystem er det den styrede ændringsprocedure, der forhindrer validerede processer i at skride. Formen på processen er den samme begge steder.

De fleste fejl i ændringsstyring er overleveringsfejl, ikke procesfejl. Anmoderen ved ikke, hvilke oplysninger vurderingen kræver, CAB læser en ticket-tråd i stedet for en samlet vurdering, udføreren bygger en plan uden rollback, og bagefter er der ingen, der lukker sagen. Derfor er skabelonen tegnet som swimlanes: Anmoder, Ændringsansvarlig, CAB, Udfører og QA ejer hver deres trin, og diagrammet gør det tydeligt, hvor arbejdet skifter hænder.

De to grene, teams oftest lader stå udokumenterede, er også dem, der giver mest diskussion bagefter: hastevejen, og hvad der sker med en afvist ændring. Begge er tegnet med her. Akutte ændringer får hastegodkendelse af CAB-formanden og fortsætter ad præcis samme implementerings- og evalueringsvej, så de aldrig ender uregistrerede. Afviste ændringer går tilbage til anmoderen med CAB's begrundelse og et beslutningspunkt, der enten fører ind i en ny vurdering eller lukker sagen som udskudt.

Hvad dette flowchart dækker

I denne skabelon

• Modtagelse og triage på tværs af banerne Anmoder og Ændringsansvarlig: opret ændringsanmodning, log ændringen i ændringsregistret, og træf derefter en tredelt beslutning om ændringstype, der sender standardændringer direkte til planlægning, normale ændringer til konsekvensvurdering og CAB-behandling, og akutte ændringer til CAB-formanden
• Vurdering: vurder konsekvens og risiko, bekræft omfang og nedetidsvindue med anmoderen, og dokumentér vurdering og risikoniveau i ét samlet dokument, så CAB læser én vurdering frem for en kommentartråd
• Beslutningspunktet i CAB-banen: CAB behandler ændringsanmodningen og godkender den videre til planlægning eller afviser den tilbage til den ændringsansvarlige
• Afvisnings- og udskydelsesgrenen: CAB's tilbagemelding sendes til anmoderen, som enten retter og indsender igen (tilbage i konsekvensvurderingen) eller lukker sagen som udskudt
• Hastevejen: akutte ændringer springer den faste CAB-dagsorden over via hastegodkendelse af CAB-formanden og fortsætter derefter ad nøjagtig samme planlægnings-, implementerings- og evalueringsvej
• Implementering og verifikation i banerne Udfører og QA: planlæg implementering og rollback, planlæg ændringsvinduet, gennemfør ændringen, og test og verificér den. En fejlet verifikation udløser rollback-planen og fører tilbage til planlægningen, mens en bestået verifikation fører til evaluering efter implementering og lukning af ændringssagen

Hvornår du skal bruge skabelonen

• I skal dokumentere en ITIL-agtig procedure for change management i en it-drifts- eller platformsafdeling, inklusive hvem der sidder i CAB, og hvad de ser, før de beslutter
• I skriver en SOP for styrede ændringer i et kvalitetsstyringssystem, hvor ændringer i en valideret proces eller et produkt kræver en dokumenteret konsekvensvurdering og en navngiven godkender
• I skal introducere nye ændringsansvarlige, CAB-medlemmer eller vagthavende teknikere, som har brug for at vide, hvilke ændringer der kræver godkendelse, og hvilke der ikke gør
• I skal blive enige om, hvem der godkender hvad, før I bygger det som et workflow i Jira, ServiceNow eller et QMS, så værktøjet afspejler en aftalt proces frem for at opfinde en
• En kunde eller auditor spørger, hvordan ændringer godkendes, testes og rulles tilbage, og I har brug for en nedskrevet proces at pege på

Sådan fungerer det

1. Omdøb banerne til jeres rigtige roller

   Erstat Anmoder, Ændringsansvarlig, CAB, Udfører og QA med de roller og teams, I faktisk har. Hvis én person både er ændringsansvarlig og CAB-formand, så slå de baner sammen frem for at lade som om, de er adskilte. Hold antallet af baner på fem eller derunder, så diagrammet stadig kan læses.

2. Definer jeres ændringskategorier ved triage-beslutningen

   Beslutningen om ændringstype deler allerede op i standard, normal og akut. Skriv ned, hvad der kvalificerer til hver kategori hos jer, og sæt grænserne ved siden af beslutningen. Sæt dem efter risiko og konsekvensomfang frem for efter sagens størrelse, og hold listen over forhåndsgodkendte standardændringer så kort, at nogen rent faktisk vedligeholder den.

3. Navngiv ændringsmyndigheden og dens mødekadence

   Notér ved CAB-behandlingen, hvem godkenderne er, hvor ofte de mødes, og hvornår deadline for at komme på dagsordenen er. Beskriv hastemyndigheden separat, for den, der kan godkende en rettelse uden for normal arbejdstid, er sjældent hele forsamlingen.

4. Fastlæg, hvad vurderingen skal indeholde

   Lav vurderingstrinnet om til en rigtig tjekliste: berørte services og brugere, nedetidsvindue, risikoniveau, afhængigheder, testtilgang og rollback-tilgang. CAB's beslutning er aldrig bedre end det dokument, og det er samtidig det revisionsspor, ændringen efterlader.

5. Sæt reglerne for rollback og verifikation

   Beslut, hvem der udfører en rollback, hvor lang tid det tager, og hvad der udløser beslutningen. Definér derefter, hvad verifikation betyder for jeres ændringer: røgtest, regressionssuite eller godkendelse fra serviceejeren. Justér løkken ved fejlet verifikation, hvis jeres politik er at rulle tilbage med det samme frem for at planlægge forfra.

6. Udgiv det, og hold styr på versionerne

   Del diagrammet dér, hvor arbejdet foregår: ved siden af ændringsanmodningsformularen eller i runbooken. Gennemgå det efter enhver ændring, der gik galt, og gem de tidligere versioner, så I kan vise, hvornår proceduren blev ændret, og hvorfor.

Ofte stillede spørgsmål

Hvad er forskellen på ændringsstyring (change control) og change management?

Ændringsstyring er den snævre, proceduremæssige del: hvordan en konkret foreslået ændring anmodes, vurderes, godkendes, implementeres, verificeres og lukkes, med en registrering ved hvert trin. Change management er bredere og omfatter strategi, kategorier, roller, kommunikation og den løbende forbedring af selve processen. Dette flowchart er ændringsproceduren, og det er normalt det første, man dokumenterer, fordi det er det, folk følger i det daglige.

Hvem bør godkende en ændring, og skal alt forbi et fuldt CAB?

Nej. At sende hver eneste ændring gennem hele forsamlingen skaber kø og får folk til at arbejde uden om processen. De fleste teams bruger tre niveauer: forhåndsgodkendte standardændringer med en dokumenteret fremgangsmåde, som ikke kræver behandling, normale ændringer, der går til CAB, og akutte ændringer godkendt af én navngiven myndighed, typisk CAB-formanden eller den vagthavende leder. Sæt grænserne efter risiko og konsekvensomfang (ikke efter sagens størrelse), og skriv dem ved siden af triage-beslutningen.

Hvordan passer akutte ændringer ind uden at underminere processen?

En akut ændring komprimerer godkendelsen, den fjerner den ikke. I dette diagram springer hastegrenen den faste CAB-dagsorden over, men får stadig en eksplicit godkendelse, går stadig gennem planlægning med en rollback-plan og ender stadig i evaluering efter implementering og lukning. Den praktiske regel, de fleste teams lander på: godkend mundtligt inden for få minutter, men skriv ændringssagen samme dag, og gennemgå hver akut ændring på næste CAB-møde for at kontrollere, at kategorien var berettiget.

Hvad sker der med ændringer, som CAB afviser eller udskyder?

De skal have en eksplicit afslutning, ellers dukker de op igen som uregistreret arbejde. I denne skabelon sender den ændringsansvarlige CAB's begrundelse tilbage til anmoderen, som derefter rammer en beslutning: ret og indsend igen, hvilket fører tilbage til konsekvensvurdering og en ny behandling, eller accepter udfaldet og luk sagen som udskudt. Begrundelsen betyder lige så meget som beslutningen, for udskudte ændringer kommer som regel tilbage, når den blokerende afhængighed er væk.

Er dette noget andet end dokument- eller SOP-ændringsstyring?

Ja. Dette er den generiske, it-driftsprægede udgave af ændringsstyring: et CAB, en rollback-plan samt et implementerings- og verifikationstrin, bygget til ændringer i systemer og services. /da/templates/dokumentaendringsstyring-workflow og /da/templates/sop-aendringsstyring-proces er smallere varianter af samme form, bygget til en bestemt dokumenttype, hvor CAB er erstattet af dokumentreviewere og -godkendere, og rollback-planen er erstattet af tilbagetrækning af den erstattede version. Handler spørgsmålet reelt om den begrebsmæssige forskel mellem versionsstyring og ændringsstyring frem for om et diagram, så se /guides/version-control-vs-change-control.