Kontrakt om Drift, Videreudvikling, Vedligeholdelse og Support af tilskuds- og kontroladministrative systemer m.fl. Bilag 12 Change Management 16. marts 2018 Version 1.0 Side 1/16
[Vejledning til tilbudsgiver: Bilaget er i sin helhed at betragte som et mindstekrav (MK). Bilaget skal ikke udfyldes af tilbudsgiver.] Side 2/16
Contents 1. INDLEDNING (MK)... 4 2. KONTRAKTENS ÆNDRINGSTYPER (MK)... 5 3. GENERELT OM CHANGE MANAGEMENT (MK)... 6 4. PROCES FOR CHANGE MANAGEMENT TYPE 1 (MK)... 8 5. PROCES FOR CHANGE MANAGEMENT TYPE 2 (MK)... 9 6. PROCES FOR CHANGE MANAGEMENT TYPE 3 (MK)... 15 7. PROCES FOR HASTEÆNDRINGER (MK)... 16 Side 3/16
1. INDLEDNING (MK) Formålet med dette bilag er at angive den procedure og de regler, der gælder for den samlede Change Management, der skal følges i henhold til nærværende Kontrakt. Ved processerne for Change Management sondres mellem: Type 1: Kontraktuelle Ændringer. Type 2: Tekniske Ændringer, som relaterer sig til Ydelser omfattet af Kontrakten. Type 3: Processuelle Ændringer: o Samarbejde mellem Kunden og Leverandøren. o Dokumentationsformater. Kunden ønsker et velfungerende og tillidsfuldt samarbejde med Leverandøren igennem Kontraktens løbetid. Kunden ønsker generelt, at samarbejdet med Leverandøren skal foregå på grundlag af en gensidig forståelse af altid at søge at finde de for Kunden bedste løsninger såvel kvalitativt som økonomisk. Leverandøren opfordres således til, såfremt Leverandøren finder, at Kundens behov bedre tilgodeses ved en anden løsning, end Kunden har foreslået, at tage dette op i en konstruktiv dialog. Kunden ønsker endvidere, at Leverandøren er åben over for videndeling med hensyn til anvendte metoder og processer, således at Kunden kan lade sig inspirere heraf med henblik på forbedring af egne processer, der grænser op til Leverandørens. Side 4/16
2. KONTRAKTENS ÆNDRINGSTYPER (MK) En Ændring, i henhold til denne Kontrakt, er enhver Change, der påvirker enten Systemerne, Kontrakten eller forhold omkring Systemerne, eksempelvis samarbejdet. Ændringer er derfor ikke begrænset til forhold, der omhandler krav, tid og økonomi. De mulige typer af Changes under Kontrakten er opdelt i tre (3) typer, med hver deres omfang, formål, proces og objektive bestemmelser. Type 1: Kontraktuelle Ændringer af enhver art. De kontraktuelle Ændringer er eksempelvis faktiske Ændringer af aftalens omfang i overensstemmelse med Kontraktens reguleringsprincipper, jf. Kontraktens punkt 28.2. Type 2: Tekniske Ændringer af enhver art. Tekniske Ændringer er alle Ændringer relateret til Drift, Support samt Vedligeholdelse og Videreudvikling af Systemerne. Eksempelvis følgende typer Changes: Installation af nyt Programmel, herunder i forbindelse med opgraderinger. Regulering af servicemål Ændringer i Dokumentationen. Fejlrettelser. Ny/ændret funktionalitet. Type 3: Processuelle Ændringer af enhver art. Processuelle Ændringer indbefatter alle de Ændringer, der foretages i relation til samarbejdets processer mellem Kunden og Leverandøren, herunder administrative processer. Tilknyttede underbilag til dette bilag: Underbilag 12A Skema til brug for Change Request og Løsningsbeskrivelse Side 5/16
3. GENERELT OM CHANGE MANAGEMENT (MK) 3.1 Løsningsforslagets indhold. Indhold af et Løsningsforslag fremgår af underbilag 12A Skema til Change Request og Løsningsbeskrivelse. 3.2 Etablering af ændringslog. Kunden udarbejder og vedligeholder en ændringslog i form af en oversigt over alle Changes (såvel godkendte som afviste samt eventuelt igangværende Change Requests) gennemført under Kontrakten. Kunden ønsker, at der til enhver tid er etableret en samlet viden om samtlige Ændringer/Changes i kontraktperioden, herunder samtlige Ændringer i forhold til Kontrakten. Ændringsloggen skal sammen med vedligeholdelse af bilagene sikre, at det er muligt altid at danne sig et retvisende billede af, hvad der har været gældende hvornår. Kunden skal sikre, at ændringsloggen indeholder oplysninger om, hvornår Kontrakten sidst er blevet opdateret og ændret. 3.3 Indhold i ændringslog. Ændringsloggen indeholder for eksempel følgende: a) Identifikationsnummer (hver Change Request skal tildeles et fortløbende identifikationsnummer, der skal sikre, at den enkelte Ændring/Change kan følges i ændringsloggen), b) Navn og kort beskrivelse af Ændring/Change, c) Ansvarlig for udarbejdelse af Change Request (Kunde eller Leverandør), d) Kontaktperson hos såvel Kunde og Leverandør, e) Status på Change Request (godkendt, afvist, under behandling), f) Vederlag for udførsel af Change (efter medgået tid), g) Dateret Løsningsbeskrivelse, h) Dato for godkendt Løsningsbeskrivelse, i) Leverancetidspunkt for Change, j) Reference til øvrige relevante dokumenter. 3.4 Leverandørens adgang til ændringsloggen. Leverandøren kan efter anmodning få udleveret informationer fra ændringsloggen. 3.5 Tilgang til gennemførelse af Changes. Leverandøren skal anvende en struktureret og effektiv tilgang til at håndtere og gennemføre Change, hvor processen skal sikre dokumentation af ønskede, godkendte, gennemførte og afviste Change Requests. 3.6 Kundens krav til yderligere materiale. Vurderer Kunden, at Leverandørens fremlagte materiale i forbindelse med processen med Change Requests ikke er fyldestgørende eller i øvrigt ikke tilfredsstillende, er Kunden berettiget til at kræve yderligere materiale fremlagt, således at Kunden får fuld indsigt i Leve- Side 6/16
randørens bagvedliggende analyser og estimater vedrørende ressourceforbrug mv. Side 7/16
4. PROCES FOR CHANGE MANAGEMENT TYPE 1 (MK) I dette afsnit beskrives den processuelle håndtering af Changes af Type 1: Kontraktuelle Ændringer. Disse Ændringer kan ske efter anmodning fra såvel Kunde som Leverandør. Der stilles ikke formelle krav til brug af Change Request-blanket for Type 1 Ændringer. 4.1 Ændringsdokumentation. Selve Ændringen dokumenteres i det relevante dokument og versionshistorik for det pågældende dokument opdateres. Derudover sker der en opdatering i ændringsloggen. Side 8/16
5. PROCES FOR CHANGE MANAGEMENT TYPE 2 (MK) I dette afsnit beskrives den konkrete processuelle håndtering af Change Requests, som gælder for Ændringer af Type 2: Tekniske Ændringer. Ændringer/Changes kan ske efter anmodning fra såvel Kunde som Leverandør. 5.1 Change Requests fra Kunden (CR) 5.1.1 Initiering af Ændring/Change. Alle Change Requests initieres ved Kundens oprettelse af en sag i Kundens opgavestyringssystem (Team Foundation Server). 5.1.2 Små sager. For sager, hvor Leverandøren vurderer, at omfanget til gennemførelse vil være mindre end 10 timer, kan Leverandøren umiddelbart påbegynde Ændringen/Changen uden forudgående Løsningsbeskrivelse. Såfremt Leverandøren i den 10. påbegyndte time indser, at Ændringen/Changen ikke kan gennemføres inden for de 1+ timer, skal Leverandøren straks ophøre arbejdet og kontakte Kunden for godkendelse af et opdateret estimat før, at arbejdet med Ændringen/Changen genoptages. 5.1.3 Mindre sager. For sager, hvor Leverandøren eller Kunden vurderer omfanget til at være større end 10 timer, men mindre end 100 timer, skal Leverandøren udarbejde et estimat ved at anvende det til en hvert tid gældende skema for Change Requests samt udarbejde (i samarbejde med Kunden) Løsningsbeskrivelse, som skal godkendes af Kunden forud for, at Ændringen/Changen gennemføres. Det aktuelt gældende skema fremgår af underbilag 12A Skema for Change Request og Løsningsbeskrivelse. 5.1.4 Større sager. For sager, hvor det af Kunden eller Leverandøren vurderes, at der vil medgå mere end 100 timer, vil Kunden udarbejde en Change Request ved at anvende det til en hvert tid gældende skema for Change Requests samt udarbejde (i samarbejde med Kunden) Løsningsbeskrivelse. Det aktuelt gældende skema fremgår af underbilag 12A Skema for Change Request og Løsningsbeskrivelse. 5.1.5 Driftsprøve som del af Løsningsforslag i forbindelse med videreudviklingsydelser. For videreudviklingsydelser kan Kunden kræve gennemførelse af en driftsprøve, jf. bilag 8 Prøver. I givet fald skal Kunden i den relevante Change Request for videreudviklingsydelsen oplyse de specifikke servicemål, der ønskes opfyldt under driftsprøven. Side 9/16
5.1.6 Igangsætning af udarbejdelse af Løsningsbeskrivelse. Såfremt estimatet for udarbejdelse af Løsningsbeskrivelsen godkendes af Kunden, igangsættes proceduren for udarbejdelse af Løsningsbeskrivelsen, jf. pkt. 5.2 nedenfor. 5.1.7 Vederlag for udarbejdelse af Løsningsbeskrivelse. Leverandøren modtager vederlag for udarbejdelsen af Løsningsbeskrivelsen i overensstemmelse med det herfor afgivne estimat, jf. bilag 13 Vederlag. 5.2 Proces for bestilling af drifts-, vedligeholdelses- og videreudviklingsopgaver Bestilling af Drift, Vedligehold og Videreudvikling af Systemerne eller ét eller flere af Systemerne samt bestilling af Ændringer/Changes til Drifts- og Supportydelser gennemføres som beskrevet i det følgende som procestrin A-J. A. Kunden beskriver den ønskede Change på et funktionelt niveau. Ved beskrivelsen benyttes en fast skabelon (i Underbilag 12A). Beskrivelsen fra Kunden skal være så detaljeret, at Leverandøren kan udarbejde et estimat for det vederlag, som vil være forbundet med udarbejdelse af et Løsningsforslag. B. Leverandøren kommer med estimat på udarbejdelse af Løsningsforslag. Eventuelle tidsfrister herfor fremgår af bilag 5 Servicemål. Vederlaget, der er forbundet med udarbejdelsen af et Løsningsforslag, opgøres efter dokumenteret medgået tid og til de i bilag 13 Vederlag anførte timepriser. Leverandøren er ikke berettiget til særskilt vederlag for udarbejdelse af estimater. C. Såfremt Kunden accepterer estimatet, udarbejder Leverandøren Løsningsforslag med tidsestimater for elementer omfattende udviklingen af løsningen, herunder opdatering af Dokumentation, jf. bilag 9 Dokumentation. Eventuelle tidsfrister herfor fremgår af bilag 5 Servicemål. D. Løsningsforslaget drøftes mellem Kunde og Leverandør med henblik på sikring af en fælles forståelse af opgaven og tidsmæssig prioritering af denne. Kunden kan vælge at afvise Løsningsforslaget og dermed stoppe Videreudviklingen. En afvisning af et Løsningsforslag fritager ikke Kunden for betaling for udarbejdelse af Løsningsforslaget. Side 10/16
E. Leverandøren foretager eventuelle tilpasninger af Løsningsforslaget og kommer med endelige tidsestimater. Eventuelle tidsfrister her for fremgår af bilag 5 Servicemål. F. Kunden godkender eller afviser Løsningsforslaget. G. Såfremt Kunden godkender Løsningsforslaget, påbegynder Leverandøren opgaven i henhold til den aftalte tidsplan. H. Såfremt der opstår behov for at tilpasse Løsningsbeskrivelse eller prisestimatet for opgavens løsning sker dette gennem drøftelser mellem Leverandørens og Kundens projektledere. Leverandøren har imidlertid pligt til - straks når det må forudses, at der er risiko for, at et af Leverandøren givet estimat vil blive overskredet - at give begrundet meddelelse herom til Kunden med henblik på, at Kunden kan tage stilling til den herved opståede situation, herunder at Kunden kan beslutte, at den pågældende Change med det samme skal anses for afsluttet for Leverandørens vedkommende. I. Leverandøren afleverer det udviklede/tilrettede Programmel til test hos Kunden sammen med opdateret Dokumentation, herunder Dokumentation for gennemført test og resultater heraf, jf. kravene i bilag 8 Test. J. Eventuelle fejl i det leverede Programmel rettes i garantiperioden af Leverandøren uden beregning, jf. Kontrakten. 5.3 Change Request fra Leverandøren 5.3.1 Teknisk, økonomisk eller samarbejdsmæssigt incitament. Leverandøren kan fremsætte en Change Request til Kunden i tilfælde af, at der er et enten teknisk, økonomisk eller samarbejdsmæssigt incitament for Systemet og Kunden ved gennemførelse af denne Ændring/Change. 5.3.2 Vederlag for udarbejdelse af Change Requests. Leverandøren modtager ikke vederlag for udarbejdelse af Change Requests, jf. dog punkt 5.4.5. 5.3.3 Skema for angivelse af Change Request. Leverandøren fremsætter Change Request til Kunden ved benyttelse af det til en hver tid gældende skema. Det aktuelt gældende skema fremgår af underbilag 12A Skema for Change Request Side 11/16
og Løsningsbeskrivelse. Leverandørens Change Request skal indeholde estimat for udarbejdelse af Løsningsbeskrivelse. 5.3.4 Tidsfrist for tilbagemelding af Change Request til Leverandøren. Kunden skal uden ugrundet ophold, og senest 10 Arbejdsdage efter modtagelsen af Leverandørens Change Request behandle dette og meddele, hvorvidt Change Request en kan imødekommes. 5.3.5 Svar på Change Request uden for aftalt tid. Kunden har mulighed for at meddele Leverandøren, at forslaget ikke kan behandles inden for den aftalte tid. Dette sker med meddelelse om, hvornår Leverandøren kan forvente at modtage svar på den fremsatte Change Request. 5.3.6 Af Leverandøren udarbejdet Løsningsbeskrivelse. Såfremt Kunden imødekommer den fremsatte Change Request, udarbejder Leverandøren en Løsningsbeskrivelse for den fremsatte Change. 5.3.7 Tidsfrist for fremsendelse af Løsningsbeskrivelsen til Kunden. Løsningsbeskrivelsen skal normalt være Kunden i hænde senest 10 Arbejdsdage efter Leverandøren har modtaget meddelelse fra Kunden om, at den fremsatte Change Request kan imødekommes, med mindre andet aftales. 5.4 Løsningsbeskrivelsens indhold 5.4.1 Kundens krav til Løsningsbeskrivelsens indhold. Leverandøren skal, med mindre andet aftales med Kunden, udarbejde Løsningsbeskrivelsen i overensstemmelse med det til enhver tid gældende skema herfor. Det aktuelt gældende skema fremgår af underbilag 12A Skema for Change Request og Løsningsbeskrivelse. 5.4.2 Specificering. Leverandøren skal foretage specificering i overensstemmelse med det til enhver tid gældende skema for Change Request og Løsningsbeskrivelse, jf. underbilag 12A Skema for Change Request og Løsningsbeskrivelse. 5.4.3 Korrektioner. Medmindre andet forudgående er skriftligt aftalt, udarbejder Leverandøren som en del af Løsningsbeskrivelsen en liste over de nødvendige korrektioner til de bilag og til den Dokumentation, der berøres af den pågældende Change. Side 12/16
5.4.4 Udarbejdelse af ændringer/korrektioner. Leverandøren skal udarbejde ændringer/korrektioner til bilagene og/eller Dokumentation. Disse skal være tydeligt markeret, således at konsekvenserne af en accept af en Løsningsbeskrivelse fremgår entydigt. 5.4.5 Vederlag for udarbejdelse af Løsningsbeskrivelse. Leverandøren modtager vederlag for udarbejdelsen af Løsningsbeskrivelsen i overensstemmelse med det i den fremsatte Change Request anførte estimat herfor, jf. bilag 13 Vederlag. 5.4.6 Uenighed om konsekvenser ved Løsningsbeskrivelsen. Såfremt der opstår uoverensstemmelser mellem Parterne om konsekvenserne af en Change Request, har Kunden ret til nødvendig indsigt i grundlaget for Leverandørens Løsningsbeskrivelse. 5.5 Vurdering af Løsningsbeskrivelsen 5.5.1 Muligheder til vurdering af Løsningsbeskrivelsen. Kunden kan vælge at: Afvise Løsningsbeskrivelsen. Anmode om ændring af Løsningsbeskrivelsen. Acceptere Løsningsbeskrivelsen og dermed godkende Change Request. 5.5.2 Anmodning om ændring af Løsningsbeskrivelsen. Hvis Kunden anmoder om ændring af Løsningsbeskrivelsen, udarbejder Leverandøren straks et nyt estimat over det vederlag, der påregnes at være forbundet med udarbejdelse af den reviderede Løsningsbeskrivelse. 5.5.3 Godkendelse af estimat. Godkendes estimatet af Kunden, udarbejder Leverandøren, med mindre andet aftales, en revideret Løsningsbeskrivelse til Kunden senest 10 Arbejdsdage herefter. 5.5.4 Vederlag for udarbejdelse af Løsningsbeskrivelsen. Leverandøren modtager vederlag for udarbejdelsen af Løsningsbeskrivelsen i overensstemmelse med det herfor afgivne estimat, jf. bilag 13 Vederlag. 5.6 Godkendelse og gennemførelse af Ændring/Change 5.6.1 Godkendelse. Godkendelse sker ved, at begge Parter underskriver den pågældende Change Request med den tilhørende Løsningsbeskrivelse. Side 13/16
5.6.2 Opdatering af Kontrakt. Den godkendte Change Request med den godkendte Løsningsbeskrivelse er at opfatte som et kontrakttillæg. 5.6.3 Opdatering af Dokumentation. Levering af opdateret Dokumentation sker i overensstemmelse med bestemmelserne i bilag 9 Dokumentation og nærværende bilag, således at Kunden til enhver tid er i besiddelse af opdateret og relevant Dokumentation i forhold til Systemerne. 5.6.4 Implementering og dokumentering af Ændringen/Changen i Systemerne. Når Change Request med den tilhørende Løsningsbeskrivelse er godkendt, implementerer og dokumenterer Leverandøren Changen i Systemerne eller ét eller flere af Systemerne. 5.6.5 Levering af en Release til test. Den leverede softwarepakke testes som planlagt og anvendes uden ændringer. Hvis der er behov for ændringer til softwarepakken, så skal disse ske hos Leverandøren ved at denne leverer en ny softwarepakke. 5.6.6 Utilsigtede bivirkninger på baggrund af implementering. Hvis der opstår utilsigtede bivirkninger i Systemerne på baggrund af den gennemførte implementering, så er Leverandøren ansvarlig for at bistå Kunden med en udredning heraf, herunder i overensstemmelse med underbilag 11B Vilkår for samarbejde imellem Kundens Leverandører, samt for at orientere og oplyse Kunden om årsager og konsekvenser. Side 14/16
6. PROCES FOR CHANGE MANAGEMENT TYPE 3 (MK) I dette afsnit beskrives den processuelle håndtering af Ændringer af Type 3: Processuelle Ændringer. Disse Ændringer kan ske efter anmodning fra såvel Kunde som Leverandør. Der stilles ikke formelle krav til brug af Change Request-blanket for Type 3 Ændringer. 6.1 Ændringsdokumentation. Selve Ændringen dokumenteres i det relevante dokument og versionshistorik for det pågældende dokument opdateres. Derudover sker der en opdatering i ændringsloggen. Side 15/16
7. PROCES FOR HASTEÆNDRINGER (MK) 7.1 Definition på hasteændringer. I kritiske situationer kan der være behov for at gennemføre en Ændring/Change, uden at alle forhold har kunnet afklares på forhånd. Dette kaldes hasteændringer. Det skal ikke her defineres, hvad en kritisk situation måtte være, men det kunne være Ændringer/Changes afledt af regelændringer, der skal implementeres inden for kort deadline, eller datarettelser. 7.2 Iværksættelse af hasteændring. En hasteændring kan kun iværksættes, hvis den godkendes af Kunden. Hasteændringer kan kun forekomme for Type 2 Ændringer. 7.3 Tidspunkt for dokumentation. Processen for hasteændring følger som udgangspunkt den normale ændringsproces for den pågældende type, men på grund af den hastende karakter, kan det forekomme, at dokumentation af beslutninger først sker efter implementeringen af den konkrete Ændring/Change. Dette skal dog godkendes af Kunden. 7.4 Dokumentationskrav. Efter beslutningen om hasteændringen og dens implementering, skal Leverandøren senest 14 Dage efter dens implementering sikre, at alle dokumentationskrav i forbindelse med ændringsprocessen efterleves. Side 16/16