Proces for Change Management

Proces for Change Management Version: 3.1.4 Igangsat den: 30/04 2012 Udarbejdet af: Service Management Formål Formålet er at sikre at changes i Region Syddanmarks IT-Drift produktionsmiljø, igangsættes i henhold til aftalte rammer og uden gene for kunderne. Dette gælder også changes 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 KAM CQC CAB Behandlingstid Impact Urgency FSC (Change Schedule) Interessent 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. hvorved ændringen træder ikraft. 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, der ikke ligger i en fryseperiode, med en teknisk vinkel. Change Quality Controller behandler RFC er, der ligger i en fryseperiode, med en teknisk og bemandingsmæssig vinkel. Key Account Manager CQC behandler RFC er, der ligger i en fryseperiode, med en forretningsmæssig vinkel. Change Advisory Board Rådgiver Change Management vedr. udvalgte changes og standard change ansøgninger. Er en tidsfrist, der sikrer den fornødne behandlingstid hos Change Management Tidsfristerne er afhængige af impactværdien. Angiver kompleksiteten og den forretningsmæssige konsekvens af changen. Angiver nødvendigheden af changen for forretningen. Urgency bruges som et udtryk for vigtigheden af at changen gennemføres i det aftalte servicevindue (om det kan udskydes eller ej) Liste over godkendte changes Alle som har en interesse i at vide, at der gennemføres changes på et givet system på et givet tidspunkt, eller

SLA Servicevindue Fryseperioder se status på en gennemført RFC. Service Level Agreement. Vil blandt andet indeholde en aftale omkring faste servicevinduer, som fremgår af driftshåndbogen for det enkelte system. 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. Er perioder hvor kun emergency changes og andre helt nødvendige changes kan gennemføres. Nødvendige changes: Changes, der er forretningskritiske og vigtige at få gennemført, selvom der er fryseperiode. Roller og ansvar Rolle Ansvar Change Requester Opretter en change-anmodning, når changen 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. Tager initiativ til at etablere aftale om changes, der kan håndteres som standard changes Change Quality Controller (CQC) Se uddybende Afvigelses CQC Se uddybende Kvalitetssikrer og godkender/afviser RFC 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. Tager initiativ til et etablere aftale om changes, der kan håndteres som standard changes. 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. Side 2 af 14

KAM CQC Se uddybende 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 ønskes gennemført i en Fryseperiode. Behandler og vurderer om en RFC er så nødvendig og forretningskritisk, at den skal gennemføres i en Fryseperiode. Sikrer at informationsdelen, som udsendes ved godkendelse af RFC, er tilstrækkelig. Change Manager Kvalitetssikrer og godkender / afviser RFC Sikrer korrekt Servicevindue, hvis der er en aftalt SLA Sikrer i fryseperiode 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 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 change recorden med status på implementeringen. CAB mødet afholdes 1 gang pr. uge og tager stilling til: o Changes til gennemførelse udvalgt af Change o Management. 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 Information Modtager Interessenter Dokumen- Dokument Placering Change Processen http://infonet.regionsyddanmark.dk/#dokid=69222 Side 3 af 14

tation Instrukser Rapporter CAB-referater RFC Information til linteressenter Implementeringsplan Dokumentation af procesforløbet af en RFC http://intranet.regionsyddanmark.dk/wm308259 X:\IT\Fælles\Change Management\Changestatistikker X:\IT\Fælles\Change Management\Referater fra CAB 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) Diagram Procesfaser Fase Beskrivelse 1 Registrering af change (RFC) Change Requester udfylder RFC. Change-plan 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 Managers foretager kvalitetssikring af RFC er. Liste over særlige changes udarbejdes og sendes til CAB. Efterfølgende godkendes eller afvises RFC en. Interessenter informeres. 3. Retningslinje for godkendelse af RFC 4 Implementering af Change Changen implementeres efter change-plan. Status på change-forlø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. KPI Mål Ansvarlig Målefrekvens 1 90% af alle changes skal være gennemført som planlagt. Change Manager Løbende pr. måned 2 Emergency changes må max udgøre 10% Change Manager Løbende pr. måned 3 Changes fra IT-service, som ikke overholder afleveringsfristerne for Change Manager Løbende pr. måned Side 4 af 14

behandlingstider for Change Management, må max udgøre 10% 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 N/A Leverandør N/A Modtager 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 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. Side 5 af 14

- 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 change, der ønskes ophøjet til en Standard Change. - udfyld eller tilret ansøgningen og fremsend den til videre godkendelse. 2 Se uddybende 3 Se uddybende REGEL: Følgende skal som minimum være opfyldt ved ansøgning af standard changes: o Changen har ingen eller kun yderst begrænset konsekvens for kundens kørende system, f.eks. performance nedgang eller lignende o Changen er en rutinemæssig gennemførelse o Change Requester skal selv kunne gennemføre changen. 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 Bilag: Impact tabel, changens lmpact: lmpact for end-user Fallback muligheder Er IPL/Boot nødvendig? Performancepåvirkning Kundeinvolvering ved brugerafprøvning Afhængighed til andre systemer/changes Påvirkes tilgængelighed? Se Bilag: Impact tabel Angiv urgency. Urgency angiver nødvendigheden af changen for forretningen. Hvor vigtigt er det at changen gennemføres i det aftalte servicevindue? Kan changen udskydes efter behov? (Low urgency) Se Bilag: Urgency tabel 4 Change Requester fastlægger en tidsramme (= servicevindue) for changen 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 Side 6 af 14

er aftalt. BEMÆRK: Change Requester aftaler med kundens kontaktperson det forventede tidspunkt for changens gennemførsel og evt. yderligere afhængigheder i forbindelse med changen. 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. BEMÆRK: Kan changen 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 changen. Bilag: Impact tabel Impact tabel Se evt. også uddybende Impact High Medium Betydning Stor og kompleks. Vital forretningsmæssig konsekvens for kunden. Eksempler på anvendelse: Ingen eller vanskelig fallback mulighed. Kundeinvolvering ved brugerafprøvning er påkrævet IPL/Boot af kritiske systemer som ikke er dublerede. Behandlingstid hos Change Manager: 14 dage 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. Eksempler på anvendelse: Komponenter der er dublerede Kan medføre performancenedgang Side 7 af 14

Boot at dublerede systemer f.eks server i citrix farm Fallback er muligt, men kan påvirke kundernes tilgængelighed. Behandlingstid hos Change Manager: 8 dage 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 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. Behandlingstid hos Change Manager: Dag til dag 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 Medium Low Betydning 'Her og nu' changes der er nødvendige for at opretholde stabil drift. Changen gennemføres uden RFC (denne udarbejdes efterfølgende). Changen SKAL gennemføres Implementer skal være onsite eller kunne kontaktes, alt efter hvad der er aftalt, for at sikre changen gennemførelse. Changen skal så vidt muligt gennemføres. Implementer skal kunne kontaktes ved fejl. Changen kan til enhver tid udsættes/aflyses uden konsekvenser. Bilag: Change-typer Change typer Changetyper Betydning Normal En change som følger de normale behandlingsrutiner i change processen. Standard change Standard Change er en change-type, hvor det er besluttet at registreringen af changen alene er tilstrækkelig, samt at den må udføres når som helst på Side 8 af 14

Emergency døgnet. Standard changes kan ikke gennemføres i fryseperioder, da der kræves ekstraordinære godkendelser (se afsnit med definitioner) 'Her og nu' changes der er nødvendige for at opretholde stabil drift. Changen gennemføres uden RFC (denne udarbejdes efterfølgende). Bemærk: Benyttelse af denne Change type 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 KAM Change Quality Ansvar Teknisk vurdering af RFC er, der ikke ligger i en fryseperiode. Teknisk validering samt bemandings- og behovsvurdering af RFC er, der ligger i fryseperioder. Forretningsmæssig behovsvurdering af RFC er, der ligger i fryseperioder. N/A Leverandør N/A Modtager Dokumentation Dokument RFC (Herunder executionplan og fallbackplan) Placering I værktøj Diagram Trin Trinnummer Beskrivelse 1 Godkend eller afvis RFC på baggrund af en samlet vurdering. Tag herunder stilling til følgende: Side 9 af 14

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 det nødvendigt at RFC gennemføres selvom den er i fryseperiode. Bemærk: Hvis changen 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? 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 Management vedr. udvalgte changes og standard changes. Side 10 af 14

N/A Leverandør FSC Enkelte changes Godkendte Standard changes Modtager Portal eller via listviews Interessenter Oversigtsliste i værktøj (listview) Dokumentation Dokument FSC Enkelte changes Godkendte Standard changes Placering I værktøj I værktøj I værktøj Diagram Trin Trinnummer 1 Se uddybende for CAB Beskrivelse 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. 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? Kan changen 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 changes, der ønskes gennemført udenfor aftalt SLA omkring servicevinduer, behandles på CAB Side 11 af 14

2 Change Manager informerer om: FSC via listviews i værktøj Enkelt changes 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 change eller emergency change i henhold til beskrivelserne og at sikre tilbagemelding umiddelbart efter gennemførsel. Roller og ansvar Rolle Change Implementer Ansvar Implementeringen af changen i produktions miljøet Godkendt RFC Incident Leverandør Change Management Incident Management Gennemført RFC Modtager Kunden Dokumentation Dokument RFC (Herunder executionplan og fallbackplan) Placering I værktøj Diagram Trin Trinnummer Beskrivelse 1 Kontroller om RFC er godkendt i change værktøjet Bemærk Emergency changes skal efterregistreres umiddelbart efter de er udført 2 lmplementér changen som det er beskrevet i RFC (Execution plan). 3 Verificer implementeringen af changen som det er beskrevet i verification Er changen implementeret uden problemer, gå videre til trin 4 Side 12 af 14

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 o o o Gennemført som planlagt: Alt er OK Gennemført med problemer: RFC er implementeret helt eller delvist, men der er afvigelser fra det planlagte. Beskriv afvigelse. Fallback: Den beskrevne plan i RFC kunne ikke implementeres. Derfor er der foretaget fallback. Beskriv afvigelse. Aflyst: RFC er blevet aflyst. Beskriv afvigelse. 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 Change Gennemført RFC Leverandør Implementer PIR data Lukket RFC Modtager Ledelsen Interessenter Dokumen- Dokument Placering tation PIR I værktøj Diagram Side 13 af 14

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 Change processen 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 6. 4 Hvis aftalt, - informér kunden eller andre interessenter via mail om status på implementeringsforløbet efter implementering. 5 Udarbejd rapport efter behov samt dokumentation over aftalt periode. 6 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 14 af 14