Proces for Change Management

Proces for Change Management Version: 3.1.4.3 Igangsat den: 16/06 2014 Udarbejdet af: Service Management Formål Formålet er at sikre at ændringer i Region Syddanmarks IT-Drift produktionsmiljø, igangsættes i henhold til aftalte rammer og uden gene for kunderne. Dette gælder også ændringer i TEST- og DEMO-miljøer, som kan påvirke Region Syddanmarks IT-Drift produktionsmiljø. Definitioner Ord el. forkortelse Request for Change (RFC) CI Services PIR CQC Afvigelses CQC CAB Afleveringsfrist Impact Urgency Definition En Request for Change er alt som ændrer status for en CI. Dette inkluderer hvis der tilføjes, slettes eller ændres ved IT miljøet, eller ved planlagte/automatiske stop /start af services, servere osv. Configuration Item (CI) er enhver Component som har behov for en opdatering for at levere en IT Service. CI s er under kontrol af Change Management. Typiske CI s i IT Services er hardware, software, bygninger og dokumentation som fx Process dokumentation and SLAs. Er en ydelse leveret til forretningen/kunden. Som eksempel kan nævnes: Grønt system, Print (PAS system) Cosmic eller EDI Post Implementation Review Change Manager validerer implementeringsstatus, dokumenterer og lukker RFC endeligt. Change Quality Controller behandler normale RFC er med en teknisk vinkel. Change Quality Controller behandler RFC er der ikke overholder afleveringsfristerne, med en teknisk og bemandingsmæssig vinkel. Change Advisory Board Rådgiver Change Manager vedr. udvalgte RFC er og standard change ansøgninger. Er en tidsfrist der sikrer, at RFC er fremsendes rettidigt. Tidsfristerne er afhængige af impactværdi samt changetype. Der måles fra tidspunktet RFC en sendes til CQC godkendelse og frem til start på det ønskede servicevindue (planlagt start) Der er ikke afleveringsfrist på standarchanges. Der beregnes i hele arbejdsdage Angiver kompleksiteten og den forretningsmæssige konsekvens af en RFC. Angiver nødvendigheden af en RFC for forretningen. Urgency bruges som et udtryk for vigtigheden af at RFC en gennemføres i det aftalte

servicevindue (om det kan udskydes eller ej) FSC (Change Schedule) Liste over godkendte RFC er Interessent Alle som har en interesse i at vide, at der gennemføres RFC er på et givet system på et givet tidspunkt, eller se status på en gennemført RFC. SLA Service Level Agreement. Vil blandt andet indeholde en aftale omkring faste servicevinduer, som fremgår af driftshåndbogen for det enkelte system. Servicevindue Dokumentation Planlagt start- og sluttidspunkt for den enkelte RFC angiver start og slut på alle changeaktiviteter, som består af: Implementering, verification og fallback. Brugerverification kan forekomme udenfor servicevinduet. Bemærk: Er der aftalt en SLA omkring servicevinduer, SKAL disse altid benyttes. Fortæller hvad der initierer den fase, der beskrives. Fortæller hvad resultatet af den beskrevne fase er. Fortæller om hvordan der dokumenteres i den pågældende fase, samt hvor det kan findes. Roller og ansvar Rolle Ansvar Change Requester Opretter en change-anmodning, når ændringen er identificeret. Sikrer at den er teknisk forsvarlig, samt udfyldt tilstrækkeligt. Herunder også informationsdelen som udsendes ved godkendelse af RFC. Sikrer korrekt Servicevindue, hvis der er en aftalt SLA. Sikrer at den ud fra beskrivelserne i RFC en kan udføres af andre i samme funktionsområde end den påsatte udfører. Sikrer at den fornødne bemanding er allokeret Tager initiativ til at etablere aftale om RFC er, der kan håndteres som standard changes Change Quality Controller (CQC) Se uddybende instruks Kvalitetssikrer og godkender/afviser RFC Sikrer at den fornødne bemanding er allokeret Sikrer at den er teknisk forsvarlig. Sikrer korrekt Servicevindue, hvis der er en aftalt SLA. Sikrer at informationsdelen, som udsendes ved godkendelse af RFC, er tilstrækkelig. Sikrer at den ud fra beskrivelserne i RFC en kan udføres af andre i samme funktionsområde end den påsatte udfører. (RFC er udført af eksterne er undtaget). Review er testresultater hvis de foreligger. Side 2 af 15

Tager initiativ til et etablere aftale om RFC er, der kan håndteres som standard changes. Afvigelses CQC Kvalitetssikrer og godkender/afviser RFC. Sikrer at den fornødne bemanding er allokeret Se uddybende Sikrer at den er teknisk forsvarlig. instruks Sikrer korrekt Servicevindue, hvis der er en aftalt SLA. Sikrer at informationsdelen, som udsendes ved godkendelse af RFC, er tilstrækkelig. Sikrer at den ud fra beskrivelserne i RFC en kan udføres af andre i samme funktionsområde end den påsatte udfører. (RFC er udført af eksterne er dog undtaget). Review er testresultater, hvis de foreligger. Review er begrundelser for at gennemføre en RFC, der ikke overholder afleveringsfristerne. Change Manager Kvalitetssikrer og godkender/afviser RFC Sikrer korrekt Servicevindue, hvis der er en aftalt SLA Sikrer yderligere godkendelser, hvis dette skønnes nødvendigt Sikrer at information til alle interessenter er tilstrækkelig. Fastlægger servicevinduer i samarbejde med kunden. Foretager PIR Deltager/afholder CAB møder Sikrer grundlag for ledelsesrapportering Behandling af standard change aftaler. Change Implementer Change Advisory Board (CAB) Se uddybende instruks Er hovedansvarlig for RFC ens gennemførelse Igangsætter jvf. execution-planen Verificerer jvf. planen eller sikrer at det udføres Udfører eventuel fallback eller sikrer at det sker Opdaterer RFC en med status på implementeringen. CAB mødet afholdes 1 gang pr. uge og tager stilling til: o RFC er til gennemførelse udvalgt af Change o Manager. Giver endelig ok for ophøjelse til standard changes CAB agerer støtte til Change Manager i beslutningen om gennemførelse af en RFC. Ønsker, anmodninger og krav til it-miljøet Leverandør Forretningen, leverandører samt IT personale fra Region Syddanmark. (generelt for (generelt for changeprocessen) changeproces- Godkendte og gennemførte Modtager Forretningen, leverandører samt IT personale fra Region Syddanmark. Side 3 af 15

sen) ændringer. Information og dokumentation. Andre interessenter som kan være berørt. Rapporter CAB-referater RFC Information til linteressenter Implementeringsplan Dokumentation af procesforløbet af en RFC Dokumentation Dokument Placering Changeprocessen Changeprocessen i Infonet (du føres til vores Sharepoint) Instrukser Instrukser i PDF format (du føres til intranettet) Links til instrukserne i Infonet: Change Quality Controller Afvigelse Change Quality Controller Impact Urgency CAB møde Se changestatistikkerne på vores Sharepoint Se CAB referaterne på vores Sharepoint Ligger i værktøj Ligger i værktøj Ligger i værktøj Ligger i værktøj (tidsstempler, brugerid er, mail-dialoger, statusskift) Procesfaser Fase Beskrivelse 1 Registrering af change (RFC) Change Requester udfylder RFC. Changeplan udarbejdes. 1. Retningslinie registrering af RFC 2 Change Quality Control behandling af RFC Change Quality Controllers kvalitetssikring af RFC. CQC godkender eller afviser RFC en med begrundelse. 2. Retningslinje kvalitetssikring af RFC 3 Change Managers endelige godkendelse eller afvisning af RFC Change Manager foretager kvalitetssikring af RFC er. Liste over særlige RFC er udarbejdes og sendes til CAB. Efterfølgende godkendes eller afvises RFC en. Interessenter informeres. 3. Retningslinje for godkendelse af RFC 4 Implementering af Change RFC en implementeres efter changeplanen. Status på changeforløbet skrives i RFC. 4. Retningslinie for implementering af Change 5 Post Implementation Review (PIR) og close Change Manager validerer, dokumenterer og lukker RFC endeligt. Side 4 af 15

KPI Mål Ansvarlig Målefrekvens 1 90% af alle RFC er skal være gennemført Change Manager Løbende pr. som planlagt. måned 2 Emergency changes må max udgøre 10% Change Manager Løbende pr. måned 3 RFC er, der ikke overholder afleveringsfristerne, må max udgøre 10% Change Manager Løbende pr. måned Procesejer Afdelingschef It-Service Region Syddanmark 1. Retningslinje for registrering af change request Formål Retningslinjen sikrer at RFC en oprettes korrekt, bliver klassificeret rigtigt og at Change Requester opretter RFC en ud fra gældende regler. Roller og ansvar Rolle Ansvar Change Requester Korrekt udfyldning af RFC Ønsker, anmodninger og krav til it-miljøet Leverandør Forretningen, leverandører samt IT personale fra Region Syddanmark. Oprettet RFC Modtager Change quality controller Afvigelses Change quality controller Dokumen- Dokument Placering tation RFC I værktøj Diagram Procesfaser Trinnummer Beskrivelse 1 Bemærk ved change request modtaget via mail, post eller telefon, så skal denne altid oprettes i vores Side 5 af 15

changeværktøj. Change Requester opretter ny RFC. Udfyld RFC med alle relevante oplysninger. BEMÆRK: Ved brug af godkendte Standard Changes. - I oversigten over standard changes laves en kopi af den ønskede RFC. - Planlagt start og slut tidspunkt angives. - Berørte CI s vælges fra listen i feltet Tilladte CI s - RFC fremsendes til godkendt status - Fortsæt ved procesfase 4: Implementering af Change Ved ansøgning om standard changes skal Change Requester - opret en ny eller lav en kopi af en succesfuld gennemført RFC, der ønskes ophøjet til en Standard Change. - udfyld eller tilret ansøgningen og fremsend den til videre godkendelse. 2 Se uddybende instruks 3 Se uddybende instruks REGEL: Følgende skal som minimum være opfyldt ved ansøgning af standard changes: o RFC en har ingen eller kun yderst begrænset konsekvens for kundens kørende system, f.eks. performance nedgang eller lignende o RFC en er en rutinemæssig gennemførelse o Change Requester skal selv kunne gennemføre RFC en. o Impact må ikke være high o Urgency må ikke være Emergency o Behandlingstid for ansøgningen i CM er minimum 14 dage Change Requester vurderer med udgangspunkt i nedenstående faktorer, samt bilaget Impact tabel, RFC ens lmpact: lmpact for end-user Fallback muligheder Er IPL/Boot nødvendig? Performancepåvirkning Kundeinvolvering ved brugerafprøvning Afhængighed til andre systemer/rfc er Påvirkes tilgængelighed? Se Bilag: Impact tabel Angiv urgency. Urgency angiver nødvendigheden af RFC en for forretningen. Hvor vigtigt er det at RFC en gennemføres i det aftalte servicevindue? Kan RFC en udskydes efter behov? (Low urgency) Se Bilag: Urgency tabel Side 6 af 15

4 Change Requester fastlægger en tidsramme (= servicevindue) for RFC en med udgangspunkt i: Angivet lmpact- og Urgency kategori Ønsket udførelsestidspunkt Husk: Verification og fallback er også indeholdt i et servicevindue. Brugerverification kan forekomme udenfor et aftalt servicevindue. Brug aftalt servicevindue fra SLA, hvis en sådan er aftalt. BEMÆRK: Change Requester aftaler med kundens kontaktperson det forventede tidspunkt forrfc ens gennemførsel og evt. yderligere afhængigheder i forbindelse med RFC en. 5 Change Requester tester RFC inkl. fallbackplan. Vurder herefter impact igen. Vurdér bl.a.: Om fallback er tilstrækkeligt beskrevet? Om executionplanen er tilstrækkeligt beskrevet? Om backup er valid (hvis backup er relevant)? Om verificationsaktivitet er tilstrækkeligt beskrevet? Om informationsdelen, der udsendes ved godkendelse af RFC, er tilstrækkelig Eventuelle afhængigheder Eventuelt behov for on-site, tilkalde vagter, herunder fra andre grupper. Om servicevinduet er tilstrækkeligt for gennemførelse af RFC. Er tilstrækkelig bemanding allokeret BEMÆRK: Kan ændringen ikke testes eller testes tilstrækkeligt, - så genovervej: lmpact Beredskab 6 Gentag fra trin 1 hvis der kommer nye eller yderligere oplysninger, der ændrer indholdet i RFC en. Bilag: Impact tabel Impact tabel Se evt. også Impact High Betydning Stor og kompleks. Vital forretningsmæssig konsekvens for kunden. Afleveringsfrist = 15 arbejdsdage Eksempler på anvendelse: Ingen eller vanskelig fallback mulighed. Kundeinvolvering ved brugerafprøvning er Side 7 af 15

uddybende instruks påkrævet IPL/Boot af kritiske systemer som ikke er dublerede. Medium BEMÆRK: lmpact high changes skal ligge i SLA aftalt Servicevindue, hvis et sådant forefindes. Moderat kompleksitet. Yderst begrænset forretningsmæssig konsekvens for kunden. Afleveringsfrist = 8 arbejdsdage Eksempler på anvendelse: Komponenter der er dublerede Kan medføre performancenedgang Boot at dublerede systemer f.eks server i citrix farm Fallback er muligt, men kan påvirke kundernes tilgængelighed. Low BEMÆRK: lmpact medium changes skal ligge i SLA aftalt Servicevindue, hvis et sådant forefindes. Enkel og rutinemæssigt. lngen forretningsmæssig konsekvens for kunden Afleveringsfrist = 3 arbejdsdage Eksempler på anvendelse: lngen afhængighed til andre changes Kan foretages uden at påvirke kundernes tilgængelighed Fallback er muligt og ligetil. Kan gennemføres uden at påvirke kundernes tilgængelíghed. BEMÆRK: lmpact low changes skal ligge i SLA aftalt Servicevindue, hvis et sådant forefindes. Bilag: Urgency tabel Urgency tabel Se evt. også uddybende Urgency Emergency High Betydning 'Her og nu' ændringer der er nødvendige for at opretholde stabil drift. Ændringen gennemføres uden RFC (denne udarbejdes efterfølgende). RFC en SKAL gennemføres. Implementer skal være onsite eller kunne kontaktes, alt efter hvad der er aftalt, for at sikre RFC ens gennemførelse. instruks Medium RFC en skal så vidt muligt gennemføres. Implementer skal kunne kontaktes ved fejl. Side 8 af 15

Low RFC en kan til enhver tid udsættes/aflyses uden konsekvenser. Bilag: Change-typer Change typer Changetyper Betydning Normal En RFC som følger de normale behandlingsrutiner i changeprocessen. Standard change Standard Change er en changetype, hvor det er besluttet at registreringen af ændringen alene er tilstrækkelig, samt at den må udføres når som helst på døgnet. Late Changes der ikke overholder de vedtagne afleveringsfrister Emergency 'Her og nu' ændringer der er nødvendige for at opretholde stabil drift. Ændringen gennemføres uden RFC (denne udarbejdes efterfølgende). Bemærk: Benyttelse af denne Changetype kræver, at der er en tilhørende lncident record 2. Retningslinje for kvalitetssikring af RFC Formål Kvalitetssikring af RFC ved hjælp af kollegagennemgang. Roller og ansvar Rolle Change Quality Controller Afvigelses Change Quality Controller Ansvar Vurdering af normale RFC er Vurdering af RFC er, der ikke overholder de vedtagne afleveringsfrister Oprettet RFC Leverandør Change Requester Afvist RFC Godkendt RFC Modtager Change Requester Change Manager Dokumen- Dokument Placering Side 9 af 15

tation RFC (kan ses i loggen) I værktøj Trin Trinnummer Beskrivelse 1 Begge CQC-roller udfører nedenstående punkter, - dog udfører normal CQC ikke sidste punkt. Godkend eller afvis RFC på baggrund af en samlet vurdering. Tag herunder stilling til følgende: Er RFC teknisk korrekt? Er lmpact korrekt fastsat? Sikrer at den ud fra beskrivelserne i RFC en kan udføres af andre i samme funktionsområde end den påsatte udfører. (dog ikke RFC er fra eksterne leverandører) I den forbindelse vurdér om: - execution er tilstrækkeligt beskrevet? - verification er tilstrækkeligt beskrevet? - fallback er tilstrækkeligt beskrevet? Er backup relevant, og hvis den hentes fra ordinære schedulerede backup er, - er den så valid? Kan verification og fallback gennemføres i servicevinduet? Er der testet inden implementeringen? o Vurdér om testen har været tilstrækkelig? Hvis der ikke er testet, vurder om den alternativt anvendte verificeringsaktivitet er tilstrækkelig? Er der taget stilling til afhængigheder til andre RFC er? Er informationsdelen, der udsendes ved godkendelse af RFC, tilstrækkelig. Er tilkald, onsite vagter et behov og er de mulige og tilstrækkelige? Er de nødvendige godkendelser indhentet fra systemejer. Er den fornødne bemanding allokeret. Dette punkt gælder kun for afvigelses CQC: Er begrundelser for gennemførsel i Late beskrevet tilstrækkeligt Bemærk: Hvis RFC en bliver afviklet i et med kunden SLA aftalt servicevindue, - kan den gennemføres indenfor den aftalte tid? Hvis ikke, - er der så bestilt udvidet servicevindue? Side 10 af 15

3. Retningslinje for godkendelse af RFC Formål Formålet er endelig godkendelse eller afvisning af fremsendte RFC er. Roller og ansvar Rolle Ansvar Change Manager Foretager godkendelse eller afvisning af RFC, herunder at søge information (hos CAB eller på anden vis) for at kunne godkende eller afvise RFC en CAB Rådgiver Change Manager vedr. udvalgte RFC er og standard changes. Godkendt RFC Leverandør Change quality controller Afvigelses Change Quality Controller FSC Godkendte Standard changes Afvist RFC Godkendt RFC Modtager Portal eller via listviews i værktøj Oversigtsliste i værktøj (listview) Change Requester Change Implementer, Change Requester samt interessenter Dokumentation Dokument FSC Godkendte Standard changes Afvist RFC Godkendt RFC Placering I værktøj I værktøj I værktøj I værktøj Trin Trinnummer Beskrivelse 1 Godkend eller afvis RFC på baggrund af en samlet vurdering. Tag herunder stilling til følgende: Er RFC udfyldt med korrekt og forståelig beskrivelse? Er lmpact korrekt fastsat? Er der taget stilling til backup? Er execution tilstrækkeligt beskrevet? Er verificationsaktivitet tilstrækkeligt beskrevet? Er verification includeret i servicevinduet? Er fallback tilstrækkeligt beskrevet? Er fallback includeret i servicevinduet? Er informationsdelen, der udsendes ved godkendelse af RFC, tilstrækkelig. Side 11 af 15

Se uddybende instruks for CAB Er der testet? o Vurderes testen at have været tilstrækkelig. o Hvis der ikke er testet, vurdér så, om den alternativt anvendte verificeringsaktivitet er tilstrækkelig. Er der taget stilling til eventuelle afhængigheder? Er tilkalde/onsite vagter et behov, og er de mulige og tilstrækkelige? Er nødvendige godkendelser indhentet? Er begrundelser for gennemførsel i Late beskrevet tilstrækkeligt Kan RFC en afvikles indenfor servicevinduet? - hvis ikke er der så bestilt udvidet servicevindue? BEMÆRK: Arranger CAB (Change Advisory Board) møde hvis dette skønnes nødvendigt. BEMÆRK. Alle ansøgninger om standard changes samt RFC er, der ønskes gennemført udenfor aftalt SLA servicevinduer, behandles på CAB 2 Change Manager informerer om: FSC via listviews i værktøj Enkelt RFC til interessenter hvor det er aftalt. Godkendte Standard Changes på oversigtsliste i værktøj. 4. Retningslinje for implementering af Change Formål Få implementeret en godkendt RFC eller emergency change i henhold til beskrivelserne og at sikre tilbagemelding umiddelbart efter gennemførsel. Roller og ansvar Rolle Change Implementer Ansvar Implementeringen af RFC i produktionsmiljøet Godkendt RFC Leverandør Change Manager Gennemført RFC Modtager Kunden Dokumen- Dokument Placering Side 12 af 15

tation RFC (via implementeringsstatus) I værktøj Trin Trinnummer Beskrivelse 1 Kontroller om RFC er godkendt i changeværktøjet Bemærk Emergency changes skal efterregistreres umiddelbart efter de er udført 2 lmplementér ændringen som beskrevet i RFC (Execution plan). 3 Verificer implementeringen af ændringen som det er beskrevet i verification Er ændringen implementeret uden problemer, gå videre til trin 4 Hvis problemer: - foretag fejlløsning, hvis tiden tillader det. (evt. fallback skal afsluttes inden servicevinduet er slut). - iværksæt fallback plan som beskrevet 4 Giv tilbagemelding om implementeringsstatus: Luk RFC umiddelbart i forlængelse af implementeringen. Angiv faktisk start/slut Angiv implementeringskode: o Gennemført som planlagt: Alt er OK o Gennemført med problemer: RFC er implementeret helt eller delvist, men der er afvigelser fra det planlagte. Beskriv afvigelse. o Fallback: Den beskrevne plan i RFC kunne ikke implementeres. Derfor er der foretaget fallback. Beskriv afvigelse. o Aflyst: RFC er blevet aflyst. Beskriv afvigelse. Bemærk: Ved planlagte automatiske stop/start af servere/services i tidsrummet kl. 17.00-08.00, kan RFC en afsluttes ved start på efterfølgende arbejdsdag. 5. Retningslinje for PIR og Close Formål At sikre opfølgning på gennemførte RFC er og danne grundlag for senere ledelsesrapportering. Roller og ansvar Rolle Ansvar Change Manager Udfører PIR og lukning (close) af RFC en. Gennemført RFC Leverandør Implementer Side 13 af 15

PIR data Lukket RFC Modtager Ledelsen Interessenter Dokumen- Dokument Placering tation PIR I værktøj Trin Trinnummer Beskrivelse 1 Foretag review af RFC. Opdatér Faktisk Implementeringskode feltet ud fra nedenstående: Har RFC været godkendt inden udførelse? Er der information om gennemførelsen, der konflikter med den angivne implementeringskode? Ved afvigelser valideres tilhørende forklaring Er Changeprocessen overholdt? 2 Kontrollér at der er et relateret incident ved en emergency change. 3 Opdater RFC med korrekt PIR kode, hvor man forholder sig til den faktiske implementeringskode, samt relevant information i RFC en vedrørende implementeringen. Hvis der er angivet uklare afvigelser, skal det følges op overfor Implementer, hvorefter den endelige PIR kode kan angives med én af følgende værdier: Hvis Faktisk implementeringskode er: Gennemført som planlagt så kan følgende PIR koder anvendes: Alt er OK Hvis Faktisk implementeringskode er én af følgende: Aflyst Fallback Gennemført med problemer så kan følgende PIR koder anvendes: Årsagen kan henføres til planlægningen Årsagen kan henføres til udførelsen Årsagen kan henføres til udefra kommende omstændigheder Gennemført uden CM ok Hvis PIR koden er Gennemført uden CM ok, så skal Implementer altid kontaktes for opsummering eller oplæringen i CM processen. Andre PIR koder med afvigelser håndteres som beskrevet i punkt 7. 4 Opdater RFC med korrekt LATE kode, hvor man forholder sig til late begrundelsen samt relevant information i RFC en vedrørende årsagen til at changen kom for sent. Side 14 af 15

Følgende late koder kan vælges efter vurdering af late begrundelsen samt RFC n generelt Late skyldes kunden Late skyldes kritisk fejlretning Late skyldes leverandør Late pga. ledelsesbeslutning Late skyldes requester 5 Hvis aftalt, - informér kunden eller andre interessenter via mail om status på implementeringsforløbet efter implementering. 6 Udarbejd rapport efter behov samt dokumentation over aftalt periode. 7 Sørg for at der bliver iværksat forbedringstiltag ud fra trend analyser og statistikker på PIR koderne. Eksempel: Viser en statistik at en bestemt person fra afdeling A ofte har records med PIR kode Årsagen kan henføres til udførelsen, så bør der igangsættes nogle initiativer på at opkvalificere vedkommende, således at disse problemer forsvinder. Side 15 af 15