Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Bilag 12 - Ændringshåndtering 12.05.2016 Version 1.0
[Vejledning til tilbudsgiver: Bilaget er i sin helhed at betragte som et mindstekrav (MK). Bilaget skal ikke udfyldes af tilbudsgiver.] Side 2/15
Indhold 1. Indledning (MK)... 4 2. Kontraktens ændringstyper (MK)... 5 3. Generelt om Ændringshåndtering (MK)... 6 4. Proces for Ændringsanmodninger Type 1 (MK)... 7 5. Proces for Ændringsanmodninger Type 2 (MK)... 8 6. Proces for Ændringsanmodninger Type 3 (MK)... 14 7. Proces for hasteændringer (MK)... 15 Side 3/15
1. Indledning (MK) Formålet med dette bilag er at angive den procedure og de regler, der gælder for den samlede Ændringshåndtering, der skal følges i henhold til nærværende Kontrakt. Processerne for Ændringshåndtering 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. Side 4/15
2. Kontraktens ændringstyper (MK) En Ændring i henhold til denne aftale er enhver Ændring, der påvirker enten Systemet, Kontrakten eller forhold omkring Systemet, eksempelvis samarbejdet. Ændringer er derfor ikke begrænset til forhold, der omhandler krav, tid og økonomi. De mulige Ændringer 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. Type 2: Tekniske Ændringer af enhver art. Tekniske Ændringer er alle Ændringer relateret til Vedligeholdelse og Videreudvikling af Systemet. Eksempelvis følgende Ændringer: Installation af nyt Programmel, herunder i forbindelse med opgraderinger. Æ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 Ændringsanmodning og Løsningsbeskrivelse Side 5/15
3. Generelt om Ændringshåndtering (MK) 3.1 Løsningsforslagets indhold. Indhold af et Løsningsforslag fremgår af underbilag 12A Skema til Ændringsanmodning og Løsningsbeskrivelse. 3.2 Etablering af ændringslog. Kunden udarbejder og vedligeholder en ændringslog i form af en oversigt over alle Ændringer (såvel godkendte som afviste samt eventuelt igangværende anmodninger) gennemført under Kontrakten. Kunden ønsker, at der til enhver tid er etableret en samlet viden om samtlige Ændringer 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, jf. kravene i Kontraktens pkt. 28.2. 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 Ændringsanmodning skal tildeles et fortløbende identifikationsnummer, der skal sikre, at den enkelte Ændring kan følges i ændringsloggen), b) Navn og kort beskrivelse af Ændring, c) Ansvarlig for udarbejdelse af Ændringsanmodning (Kunde eller Leverandør), d) Kontaktperson hos såvel Kunde og Leverandør, e) Status på Ændringsanmodning (godkendt, afvist, under behandling), f) Vederlag for udførsel af Ændring, jf. bilag 13 Vederlag, g) Dateret Løsningsbeskrivelse, h) Dato for godkendt Løsningsbeskrivelse, i) Leverancetidspunkt for Ændringen, 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 Ændringer. Leverandøren skal anvende en struktureret og effektiv tilgang til at håndtere og gennemføre Ændringer, hvor processen skal sikre dokumentation af ønskede, godkendte, gennemførte og afviste Ændringsanmodninger. 3.6 Kundens krav til yderligere materiale. Vurderer Kunden, at Leverandørens fremlagte materiale i forbindelse med ændringshåndteringsprocessen 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 Leverandørens bagvedliggende analyser og estimater vedrørende ressourceforbrug mv. Side 6/15
4. Proces for Ændringsanmodninger Type 1 (MK) I dette afsnit beskrives den processuelle håndtering af Ændringer 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 ændringsanmodningsblanket 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 7/15
5. Proces for Ændringsanmodninger Type 2 (MK) I dette afsnit beskrives den konkrete processuelle håndtering af Ændringsanmodninger, som gælder for Ændringer af Type 2: Tekniske Ændringer. Ændringer kan ske efter anmodning fra såvel Kunde som Leverandør. 5.1 Ændringsanmodninger fra Kunden (CR) 5.1.1 Initiering af Ændring. Alle Ændringsanmodninger initieres ved Kundens oprettelse af en sag i Kundens fejlhåndteringssystem 1. 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 uden forudgående Løsningsbeskrivelse. 5.1.3 Mindre sager. For sager, hvor Leverandøren 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 Ændringsanmodninger og Løsningsbeskrivelse, som skal godkendes af Kunden forud for, at Ændringen gennemføres. Det aktuelt gældende skema fremgår af underbilag 12A Skema for Ændringsanmodning og Løsningsbeskrivelse. 5.1.4 Større sager. For sager, hvor det af Kunden vurderes, at der vil medgå mere end 100 timer, vil Kunden udarbejde en Ændringsanmodning ved at anvende det til en hvert tid gældende skema for Ændringsanmodninger og Løsningsbeskrivelse. Det aktuelt gældende skema fremgår af underbilag 12A Skema for Ændringsanmodning 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 Test. I givet fald skal Kunden i Ændringsanmodningen for videreudviklingsydelsen oplyse de specifikke servicemål, der ønskes opfyldt under driftsprøven. 1 Kundens fejlhåndteringssystem TFS er endnu ikke implementeret, men forventes at være klar ved kontraktunderskrivelse. Såfremt dette ikke kan nås, vil Kunden anvende et alternativt system, som Leverandøren vil blive introduceret til. Side 8/15
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 vedligeholdelses- og videreudviklingsopgaver Bestilling af Vedligehold og Videreudvikling af Systemet gennemføres som beskrevet i det følgende som procestrin A-J. Til administration og styring af ovenstående proces for Videreudvikling benyttes Kundens fejlhåndteringssystem 2. A. Kunden beskriver den ønskede Videreudvikling 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 prisoverslag 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 fratager ikke Kunden for betaling for udarbejdelse af Løsningsforslaget. 2 Kundens fejlhåndteringssystem TFS er endnu ikke implementeret, men forventes at være klar ved kontraktunderskrivelse. Såfremt dette ikke kan nås, vil Kunden anvende et alternativt system, som Leverandøren vil blive introduceret til. Side 9/15
E. Leverandøren foretager eventuelle tilpasninger af Løsningsforslaget og kommer med endeligt prisestimat. 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 udviklingsopgaven 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 Ydelserne 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 Ændringsanmodning fra Leverandøren 5.3.1 Teknisk, økonomisk eller samarbejdsmæssigt incitament. Leverandøren kan fremsætte en Ændringsanmodning til Kunden i tilfælde af, at der er et enten teknisk, økonomisk eller samarbejdsmæssigt incitament for denne Ændring. 5.3.2 Vederlag for udarbejdelse af Ændringsanmodninger. Leverandøren modtager ikke vederlag for udarbejdelse af Ændringsanmodninger. 5.3.3 Skema for angivelse af Ændringsanmodning. Leverandøren fremsætter Ændringsanmodning 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 Ændringsanmodning og Løsningsbeskrivelse. Leverandørens Ændringsanmodning skal indeholde estimat for udarbejdelse af Løsningsbeskrivelse. 5.3.4 Tidsfrist for tilbagemelding af Ændringsanmodning til Leverandøren. Kunden skal uden ugrundet ophold, og senest 10 Arbejdsdage efter modtagelsen af Leverandørens Side 10/15
Ændringsanmodning behandle dette og meddele, hvorvidt Ændringsanmodningen kan imødekommes. 5.3.5 Svar på Ændringsanmodning udenfor 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å Ændringsanmodningen. 5.3.6 Af Leverandøren udarbejdet Løsningsbeskrivelse. Såfremt Kunden imødekommer Ændringsanmodningen, udarbejder Leverandøren en Løsningsbeskrivelse for den fremsatte Ændring. 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 Ændringsanmodningen 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 Ændringsanmodning og Løsningsbeskrivelse. 5.4.2 Specificering. Leverandøren skal foretage specificering i overensstemmelse med det til enhver tid gældende skema for Ændringsanmodning og Løsningsbeskrivelse, jf. underbilag 12A Skema for Ændringsanmodning 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 Ændringen. 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 Ændringsanmodningen anførte estimat herfor, jf. bilag 13 Vederlag. Side 11/15
5.4.6 Uenighed om konsekvenser ved Løsningsbeskrivelsen. Såfremt der opstår uoverensstemmelser mellem Parterne om konsekvenserne af en Ændringsanmodning, 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 CR-dokumentet. 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 Ændringen 5.6.1 Godkendelse. Godkendelse sker ved, at begge Parter underskriver Ændringsanmodningen med den tilhørende Løsningsbeskrivelse. 5.6.2 Opdatering af kontrakt. Ændringsanmodningen med den godkendte Løsningsbeskrivelse indarbejdes i Kontrakten og dens bilag, således at der til enhver tid foreligger en opdateret version af den samlede Kontrakt. 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 Systemet. 5.6.4 Implementering og dokumentering af Ændringen i Systemet. Når Ændringsanmodningen med den tilhørende Løsningsbeskrivelse er godkendt, implementerer og dokumenterer Leverandøren Ændringen i Systemet. Side 12/15
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 Systemet 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 13/15
6. Proces for Ændringsanmodninger 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 ændringsanmodningsblanket 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 14/15
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, 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 afledt af regelændringer, der skal implementeres inden for kort deadline. 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. Dette skal dog godkendes af Kunden. 7.4 Dokumentationskrav. Efter beslutningen om hasteændringen og dens implementering, skal Leverandøren sikre, at alle dokumentationskrav i forbindelse med ændringsprocessen efterleves. Der kan dog være tidsmæssige aspekter, som ikke kan overholdes. Side 15/15