Change-processen kan være lang og kedelig, hvilket bremser din organisation. Hvordan kan du gøre det mere agilt? Ved at genopfinde CAB’en (Change Advisory Board). Det gør man sådan her.

Problemet: CAB’en bremser din organisation

Alle kender det: CAB’en er lidt af et problem.

I teorien er det en fantastisk måde at kontrollere ændringerne på i din organisation. I praksis bremser det din godkendelsesproces ift. changes. Virkelig meget!

Der er masser af organisationer, hvor behandlingen af forespørgsler tager flere uger eller endda måneder. Som fx denne organisation, der altid havde en backlog på ca. 180 change-forespørgsler, hvor selv de enkleste changes kunne tage flere måneder at behandle.

I en verden, hvor agilitet og omstillingsparathed er afgørende for it-organisationerne, er det helt uacceptabelt. Så hvordan kan du fremskynde godkendelsesprocessen ift. changes uden at miste kontrollen?

Det er tid til at genopfinde din CAB og godkendelsesproces. Her er det, som er galt med din CAB:
Change process

Skift holdning: det er ikke alle changes, der skal evalueres af din CAB

Din CAB evaluerer sandsynligvis alle forespørgsler som ikke-standard changes – i henhold til ITIL’s retningslinjer. Det holder ikke, og det ved du godt.

I de fleste organisationer er der langt flere change-forespørgsler end nogen CAB kan håndtere på deres CAB-møder. De fleste forespørgsler har en relativt lille konsekvens og kræver ikke en bestyrelse på seks til otte personer til at vurdere dem.

Her må man prioritere det, der tæller. Du må afgøre, hvilke change-forespørgsler dine CAB-medlemmer skal bruge deres tid og kræfter på. Det lyder muligvis som umuligt. For hvordan kan man estimere konsekvensen af en ændring, før man har lavet en konsekvensanalyse?

Det gør man sådan her.

Løsningen: introducér en Quick Impact Score

Vi foreslår en Quick Impact Score: en mindre version af konsekvensanalysen for ikke-standard changes. Målet er at bestemme, om en change-forespørgsel skal godkendes – og i givet fald af hvem.

Det fungerer sådan her.

1. Vælg dine konsekvenskriterier

Først definerer du nogle kriterier, der hjælper dig med at måle konsekvensen af en change-forespørgsel. Det er op til dig, hvilke kriterier du bruger, dog helst højst fem. Kombinationen af følgende faktorer giver en temmelig god indikation af den forventede konsekvens af en ændring:

  • Antal berørte kunder: hvor mange mennesker påvirkes af ændringen, hvis noget går galt? Jo større tal, des større er konsekvensen.
  • Omkostninger: hvilke omkostninger vil være forbundet med at gennemføre ændringen? Jo større omkostninger, des større er konsekvensen.
  • Antal involverede operatører: hvor mange operatører vil være involveret i realiseringen af ændringen? Jo flere operatører og parter der er involveret, jo større er konsekvensen.
  • Sikkerhed: hvilke sikkerhedsrisici vil ændringen medføre? Hvis ændringen kan udgøre en sikkerhedsrisiko, er der højst sandsynligt tale om en ændring med stor konsekvens.
  • Love og regler: kan ændringen på nogen måde påvirke din overholdelse af love og regler? Hvis svaret er ja, har change-forespørgslen sandsynligvis stor konsekvens.

2. Definer konsekvensen pr. kriterie

For hver af disse kriterier, skal du bestemme et interval for hhv. lille, mellem og stor konsekvens.

Mht. ‘antal berørte kunder’ kan du skelne mellem følgende; en person eller et enkelt team medfører en lille, en forretningsenhed en mellemstor og hele organisationen en stor konsekvens. Gør det samme for de andre kriterier.

Når du vurderer en change-forespørgsel, baseret på disse kriterier, afgøres den samlede konsekvensscore af den højeste score.

3. Udpeg en, der godkender hver konsekvensscore

Det næste skridt er at beslutte, hvem der bestemmer, hvorvidt change-forespørgsler får en lav, mellemstor eller stor konsekvens. Du kan frit designe det, som du vil. Du vil under alle omstændigheder skulle afbalancere kvalitetskontrollen med hastigheden på beslutningstagningen. Kunsten er kun at involvere de nødvendige personer.

Sådan kan du håndtere godkendelse af change-forespørgsler:

  • Lille konsekvens: kræver ingen godkendelse, forespørgslen er klar til at blive behandlet af den relevante operatør. Det gælder typisk de ukomplicerede ændringer.
  • Mellemstor konsekvens: kræver godkendelse af en person. Du kan uddelegere det til en change manager, men det kan også være it-manageren eller en anden procesmanager. Udnævn en, der arbejder på taktisk niveau, som er bekendt med den type changes, dit team håndterer.
  • Stor konsekvens: kræver godkendelse fra CAB. For disse change-forespørgsler er det bare ‘business as usual’.

Normalt anslås ca. 80 % af alle forespørgsler at få en lille konsekvens og 10 til 15 % at få en mellemstor konsekvens. Det betyder, at CAB’en kun skal behandle 5 til 10 % af de change-forespørgsler, de håndterer i øjeblikket. Tænk lige over det: Din CAB ville få 5 til 10 % af den arbejdsmængde, som de har nu.

Nu har du alt, du skal bruge, for at lave en Quick Impact Score af din change-forespørgsel. Lad os køre processen gennem en test.

Sådan vurderer du konsekvensen af en change-forespørgsel

Lad os sige, at du vil opdatere et gratis program som Notepad++ for hele organisationen. Det kan en enkelt application manager gøre på under en dag – og det udgør ingen sikkerheds- eller complianceproblemer. Så, hvordan ser dens Quick Impact Score ud?

1. Vurder change-forespørgslen baseret på dine kriterier

Du vurderer kriterierne som følger:

  • Antal berørte kunder: alle ansatte => stor konsekvens
  • Omkostninger: gratis => lav konsekvens
  • Antal involverede operatører: 1 => lille konsekvens
  • Sikkerhed: ingen involverede sikkerhedsrisici => lille konsekvens
  • Love og regler: ikke relevant

2. Den højeste score er din konsekvensscore

Gennemgangen af den samlede Quick Impact Score bestemmer konsekvensen af change-forespørgslen vha. den højeste værdi – ikke vha. et gennemsnit. I dette eksempel er alle konsekvensscores små, med undtagelse af ‘antal berørte kunder’, som har stor konsekvens. Dette betyder, at konsekvensscoren for hele denne change-forespørgsel er høj.

3. Se om du kan reducere konsekvensen af din change-forespørgsel

Når du har en change-forespørgsel med mellemstor eller stor konsekvens, er spørgsmålet: er der noget, du kan gøre for at reducere konsekvensscoren?

Når du skal opdatere Notepad++, bør du tjekke, om du kan mindske antallet af berørte kunder. F.eks. ved at lave opdateringen uden for dine servicevinduer. Eller ved først at rulle den ud i en mindre testgruppe. Når det lykkes, sænker du også konsekvensen af appens opdatering for resten af organisationen.

Sådan overbeviser du CAB’ens medlemmer om at opgive lidt af kontrollen

Quick Impact Scoren kan muligvis give nogle indvendinger.

Et af argumenterne kan se sådan ud: ‘Det, du foreslår, giver god mening, men jeg tror ikke, det vil fungere i min organisation.’ Normalt er det et underliggende problem, at CAB’ens medlemmer skal opgive kontrol – og de færreste organisationer tror ikke, at det kommer til at ske i den nærmeste fremtid.

Det argument er fuldt forståeligt. Ved gennemgangen af enhver change-forespørgsel, med en gruppe repræsentanter fra alle afdelinger, kan man faktisk kontrollere risikoen for de foreslåede ændringer mht. funktionalitet eller infrastruktur. Vi foreslår ikke, at du skal nedlægge CAB’en, da den fortsat vil have en vigtig funktion i din change-proces.

Men tænk lige over dette: opvejer fordelen ved at forhindre potentielle (mindre) risici de ulemper, som dine nuværende processer har? Den tid CAB’ens medlemmer bruger? Den – til tider latterligt – lange behandlingstid? Den resulterende mangel på organisatorisk agilitet? Nej, det gør det ikke.

For mange changes er risikoen ved behandlingen af disse changes praktisk talt nul. Nogle CAB’er bruger deres tid på at evaluere, om de skal tilføje et felt i et bestemt stykke software. Det bør CAB’en slet ikke bekymre sig om.

Ja, når man bevæger sig mod Quick Impact Scores, betyder det, at CAB-medlemmerne skal opgive noget kontrol eller indflydelse ift. mange af ændringerne. Og det er det værd: din organisation opnår mere fart, agilitet og effektivitet. Og de fleste CAB-medlemmer vil meget hellere bruge deres energi på indsatser, der giver organisationen størst mulig værdi, end at bruge to timer om ugen på at gennemgå hver enkel change-forespørgsel.

Arbejdet mod en mere agil CAB

Hvis du virkelig vil forbedre agilitet og hastigheden i din change-proces, er din eneste mulighed at revidere, hvordan din CAB fungerer. Hvad nu, hvis et CAB-medlem protesterer? Fortæl dem, hvordan det frigør tid, så de kan bruge deres talent på andre måder – og dermed få en endnu større indflydelse på organisationen.

Mere om Agile Service Management

Søger du mere inspiration om, hvordan du gør dit service management mere agilt? Så kan følgende være relevant for dig:

Hvis du vil dykke dybere ned i Agile Service Management, bør du læse vores gratis e-bog med en guide, der bringer fleksibilitet, hastighed og kundefokus tilbage i dit it-team.