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 æ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 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 Manager vedr. udvalgte RFC er og standard change ansøgninger. Er en tidsfrist, der sikrer den fornødne behandlingstid hos Change Manager. Tidsfristerne er afhængige af impactværdien. 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) Liste over godkendte RFC er Alle som har en interesse i at vide, at der gennemføres RFC er på et givet system på et givet tidspunkt, eller se

SLA Servicevindue Fryseperioder Dokumentation 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 RFC er og andre helt nødvendige RFC er kan gennemføres. Nødvendige RFC er: RFC er, der er forretningskritiske og vigtige at få gennemført, selvom der er fryseperiode. 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. Tager initiativ til at etablere aftale om RFC er, der kan håndteres som standard changes Change Quality Controller (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 RFC er, der kan håndteres som standard changes. Afvigelses CQC Kvalitetssikrer og godkender/afviser RFC. Sikrer at den fornødne bemanding er allokeret Side 2 af 14

Se uddybende KAM CQC Se uddybende 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 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 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. (generelt for changeprocessen) Ønsker, anmodninger og krav til it-miljøet Leverandør Forretningen, leverandører samt IT personale fra Region Syddanmark. Modtager (generelt for Godkendte og Forretningen, leverandører samt IT personale fra Region Side 3 af 14

gennemførte ændringer. Information og dokumentation. Syddanmark. Andre interessenter som kan være berørt. Dokument Placering Changeprocessen http://infonet.regionsyddanmark.dk/#dokid=69222 Instrukser http://intranet.regionsyddanmark.dk/wm308259 Rapporter X:\IT\Fælles\Change Management\Changestatistikker CAB-referater X:\IT\Fælles\Change Management\Referater fra CAB RFC Ligger i værktøj Information til Ligger i værktøj linteressenter Implementeringsplan Ligger i værktøj Dokumentation af Ligger i værktøj procesforløbet af (tidsstempler, brugerid er, mail-dialoger, statusskift) en RFC Dokumentation changeprocessen) 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. 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 Side 4 af 14

2 Emergency changes må max udgøre 10% Change Manager Løbende pr. måned 3 RFC er fra IT-service, som ikke overholder Change Manager Løbende pr. afleveringsfristerne for behandlingstider måned for Change Manager, 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 Ønsker, anmodninger og krav til it-miljøet Leverandør Forretningen, leverandører samt IT personale fra Region Syddanmark. Oprettet RFC Modtager CQC (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 changeværktøj. Change Requester opretter ny RFC. Side 5 af 14

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 3 Se uddybende 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 Bilag: 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 4 Change Requester fastlægger en tidsramme (= servicevindue) for RFC en med udgangspunkt i: Angivet lmpact- og Urgency kategori Side 6 af 14

Ø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. 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å uddybende Impact High 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. Side 7 af 14

Medium Moderat kompleksitet. Yderst begrænset forretningsmæssig konsekvens for kunden. 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. 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' æ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. RFC en skal så vidt muligt gennemføres. Implementer skal kunne kontaktes ved fejl. RFC en kan til enhver tid udsættes/aflyses uden konsekvenser. Bilag: Change-typer Side 8 af 14

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. Standard changes kan ikke gennemføres i fryseperioder, da der kræves ekstraordinære godkendelser (se afsnit med definitioner) 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 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. Oprettet RFC Leverandør Change Requester Afvist RFC Godkendt RFC Modtager Change Requester Change Manager Dokumentation Dokument RFC (kan ses i loggen) Placering I værktøj Side 9 af 14

Trin Trinnummer Beskrivelse 1 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 det nødvendigt at RFC gennemføres selvom den er i fryseperiode. 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? 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 Side 10 af 14

CAB Rådgiver Change Manager vedr. udvalgte RFC er og standard changes. Godkendt RFC Leverandør CQC (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 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 RFC en afvikles indenfor servicevinduet? - hvis ikke er der så bestilt udvidet servicevindue? BEMÆRK: Arranger CAB (Change Advisory Board) møde Side 11 af 14

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 Dokumentation Dokument RFC (via implementeringsstatus) Placering 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. Side 12 af 14

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 RFC en. Gennemført RFC Leverandør Implementer 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? Side 13 af 14

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 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