KO2 med kommentarer. Nicolai Dragsted Ole Horsfeldt Jesper Langemark Claus Sørensen

Transkript

1 KO2 med kommentarer

2

3 KO2 med kommentarer Nicolai Dragsted Ole Horsfeldt Jesper Langemark Claus Sørensen

4 Nicolai Dragsted, Ole Horsfeldt, Jesper Langemark og Claus Sørensen KO2 med kommentarer 1. udgave/1. oplag ISBN: Omslag: Intermail Graphic Vest A/S Sats og tryk: Intermail Graphic Vest A/S Mekanisk, fotografisk eller anden gengivelse af denne bog eller dele af den er ikke tilladt ifølge dansk lov om ophavsret. Alle rettigheder forbeholdes.

5 Indholdsfortegnelse Indholdsfortegnelse Indledning...9 K02 - Ordlyden Introduktion til anskaffelsesprojekter og K Indledning De tre basale elementer ved en anskaffelse (pris, tid og ydelse) Projekt- og udviklingsmodeller Prismodeller Kontrakten som styringsredskab Forretningsmæssige behov Særlige forhold ved it-anskaffelser Udformning af it-kontrakter Forhandling af it-kontrakter Brug af hensigtserklæringer Kommentarer til K Kommentarer til pkt. 1 definitioner Kommentarer til pkt. 2 baggrund og formål Kommentarer til pkt. 3 leverancens omfang Kommentarer til pkt. 4 kundens it-miljø Kommentarer til pkt. 5 leverancens udførelse Kommentarer til pkt. 6 ændringer Kommentarer til pkt. 7 levering Kommentarer til pkt. 8 afprøvning Kommentarer til pkt. 9 ibrugtagning Kommentarer til pkt. 10 overtagelse Kommentarer til pkt. 11 vedligeholdelse og support Kommentarer til pkt. 12 drift Kommentarer til pkt. 13 servicemål Kommentarer til pkt. 14 priser Kommentarer til pkt. 15 incitamenter Kommentarer til pkt. 16 betalingsbetingelser Kommentarer til pkt. 17 garanti Kommentarer til pkt. 18 leverandørens misligholdelse Kommentarer til pkt. 19 kundens misligholdelse Kommentarer til pkt. 20 kundens ophævelse Kommentarer til pkt. 21 erstatning og forsikring Kommentarer til pkt. 22 force majeure...362

6 Indholdsfortegnelse Kommentarer til pkt. 23 rettigheder til programmel og dokumentation Kommentarer til pkt. 24 tavshedspligt Kommentarer til pkt. 25 overdragelse Kommentarer til pkt. 26 varighed Kommentarer til pkt. 27 tvistigheder Kommentarer til pkt. 28 bevillingsmæssige forbehold Kommentarer til pkt. 29 fortolkning og kontraktstyring Kommentarer til pkt. 30 underskrifter Kommentarer til bilag Introduktion Generelle råd vedrørende bilag Kommentarer til bilag Kommentarer til bilag Kommentarer til bilag Kommentarer til bilag Kommentarer til bilag 5 samt paradigma til vedligeholdelsesog supportaftale Kommentarer til bilag 6 samt eksempel på udfyldelse af bilaget Kommentarer til bilag 7 samt paradigma til driftsaftale Kommentarer til bilag Kommentarer til bilag 9 samt paradigma Kommentarer til bilag Kommentarer til bilag Kommentarer til bilag Kommentarer til bilag Kommentarer til bilag Kommentarer til bilag Udbudsret Indledning Udbudsdirektivets anvendelsesområde Udbudsformer Udbudsprocessen Udbudsretlige problemstillinger efter udbudsprocessens afslutning Klagenævnet for Udbud og sanktioner Aftaler om support og vedligeholdelse Indledning Hvem indgås vedligeholdelses- og supportaftalen med? Aftale eller bilag? Hvilke lovregler gælder for vedligeholdelses- og supportydelser?.. 601

7 Indholdsfortegnelse 5.5 Sammenhæng med leverancekontrakten Hvor i K02 reguleres vedligeholdelse og support? Hvad er vedligeholdelse og support? Sammenhæng mellem pris og kvalitet Fra hvilket tidspunkt skal ydelserne leveres? Beskrivelse af vedligeholdelses- og supportydelserne Programmel fra tredjemand Servicemål, service level agreements (SLA) og bod Kundens forpligtelser og forhold Vederlag og betalingsvilkår Ændringshåndtering Varighed og opsigelse Sanktioner og konfliktløsning Aftaler om drift Indledning Hvem indgås driftsaftalen med, hvor leveres ydelserne fra? Aftale eller bilag? Hvilke lovregler gælder for driftrelaterede ydelser? Sammenhæng med leverancekontrakten Hvor i K02 reguleres drift? Leverandørens ydelser Personaleforhold Rettighedsforhold Kundens ydelser Leverandørens vederlag og tilknyttede forhold Ændringsstyring Kontraktens længde, opsigelse mv Misligholdelsesbeføjelser Modelbilag til K Bilag 1 Tidsplan Bilag 2 Kundens it-miljø Bilag 3 Leverancebeskrivelse med Kravspecifikation og Løsningsbeskrivelse samt ændringsmuligheder (herunder Optioner) Bilag 4 Dokumentation Bilag 5 Bilag 6 Bilag 7 Bilag 8 Bilag 9 Vedligeholdelse og support Servicemål Et eksempel på krav til svartider: Drift Leverandørens modenhed Ændringshåndtering...745

8 Bilag 10 Samarbejdsorganisation Bilag 11 Kundens deltagelse og modenhed Bilag 12 Leverancevederlag og betalingsplan samt øvrige priser Bilag 13 Incitamenter Bilag 14 Prøver Bilag 15 Licensbetingelser for Standardprogrammel og Open Source Programmel samt krav til deponering Stikordsregister...779

9 Indledning K02 s tilblivelse I 1987 udgav staten kontrakten K33, der var møntet på it-projekter med specialudvikling. I 1990 kom K17, der var beregnet til standardiserede it-anskaffelser, og i 1992 kom K18, der var en opdatering af K17. Gennem deres udbredelse i både den offentlige og private sektor satte K33 og K18 et afgørende præg på danske kontrakter om anskaffelse af it-ydelser. Efter en række it-skandaler nedsatte Teknologirådet i 2000 en arbejdsgruppe med Erik Bonnerup som formand, der havde til formål at samle erfaringer fra en række store offentlige it-projekter. Arbejdsgruppen afgav i 2001 sin rapport. En af anbefalingerne var: Moderniseringen af standardkontrakterne K18 og K33, der er sat i gang, bør sikres høj prioritet. Arbejdet bør munde ud i nye og mere fleksible modeller for udbud og kontrahering af systemudviklingsopgaver. Som en naturlig del af dette arbejde bør det undersøges, hvilket spillerum Danmark har for at fortolke EU s udbudsregler bredere end hidtil. Allerede inden da havde K33 og K18 i lang tid været stærkt kritiseret af leverandørerne. Kritikkens essens var, at kontrakterne især varetager kundens interesser, de er ikke procesorienterede, og de understøtter ikke etablering af et samarbejde. Ved at lægge risikoen for alle hændelser, der kan påvirke et projekt, på leverandøren får kunden intet incitament til at medvirke ved løsning af problemer. Ved anvendelse af K33 eller K18 må leverandørerne derfor betinge sig et uforholdsmæssigt stort risikovederlag. I konsekvens heraf nedsatte Statens IT-råd i foråret 2001 en arbejdsgruppe, der skulle udarbejde en revision af de eksisterende standardkontrakter. Arbejdsgruppen havde deltagelse af repræsentanter for Videnskabsministeriet, Finansstyrelsen, Konkurrencestyrelsen (der senere udtrådte af arbejdsgruppen), IT-Brancheforeningen og Dansk IT. I lighed med udarbejdelse af K33 og K18 var Kammeradvokaten involveret i konciperingsarbejdet. I april 2004 blev statens kontrakt til brug for standardiserede IT-anskaffelser (K01) offentliggjort, og i umiddelbar forlængelse af denne offentliggørelse blev der nedsat en styregruppe, som havde til formål at tilvejebringe et kontraktgrundlag til brug for mere komplekse it-anskaffelser. Styregruppen nedsatte et udvalg, der skulle forestå den egentlige udarbejdelse af udkast, mens arbejdsgruppen tog stilling til de principielle spørgsmål, som kon- 9

10 Indledning ciperingsgruppen ikke kunne opnå enighed om. Konciperingsgruppen bestod af advokaterne Mette Line Braad og Thorbjøn Softsrud fra Kammeradvokaten, advokater Hanne Bay og Søren Staugaard Nielsen, udpeget af Dansk IT, advokaterne Michael Lemvig og Claus Sørensen, udpeget af IT-Branchen. Fra Videnskabsministeriet/IT- og Telestyrelsen har blandt andre deltaget Line Gulløv Lundh, Maria Munk, Sara Gøtske, Søren Johansen, Dan Christensen, Anders Christian Boisen og Adam Lebech. I september måned 2007 sendte IT- og Telestyrelsen første udkast til den nye standardkontrakt K02 i høring, og på baggrund af høringssvarene blev K02 herefter færdigbearbejdet. Den samlede dokumentpakke angående K02 indeholder følgende dokumenter: K02 standardkontrakten Vejledning i brug af kontrakten med kortfattede bemærkninger til de enkelte bestemmelser (i denne bog benævnt vejledningen) Vejledning i brug af bilag 1-15 med bilagsvis angivelse af de væsentligste krav, der anbefales håndteret i det pågældende bilag. Introduktion til K02 K02 følger samme model som de øvrige K-kontrakter. Grundlaget for kontrakten er en kravspecifikation, der oplister og beskriver de krav, leverandøren skal opfylde, idet vandfaldsmodellen anvendes som projektmodel (se nedenfor under for en beskrivelse af vandfaldsmodellen). Leverancen sker til fast pris og i henhold til en på forhånd fastsat tidsplan. Som den første aktivitet efter kontraktunderskrivelsen afvikler kunde og leverandør i forening en afklaringsfase, der har til formål at undersøge, om det er hensigtsmæssigt at præcisere eller supplere kravspecifikationen. I løbet af afklaringsfasen skal leverandøren opnå et mere detaljeret indblik i kundens behov og forretningsgange samt vurdere, om leverandørens system kan opfylde kundens behov og kravspecifikation. Ved udgangen af afklaringsfasen har kunden udtrædelsesadgang mod betaling. Implementering gennemføres i en eller flere faser, hvor hver fase afsluttes med en delovertagelsesprøve. Resultatet af en fase benævnes en delleverance, og summen af de samlede delleverancer benævnes leverancen. Leverandørens vederlag betales i henhold til en betalingsplan, der aftales ved kontraktindgåelse. Afprøvning vil bestå i en fabriksprøve, en installationsprøve, eventuelle delovertagelsesprøver, en overtagelsesprøve i form af en funktionalitetsprøve og en efterfølgende driftsprøve, der har til formål af efterprøve oppetid og svartider. 10

11 Indledning Efter leverancens overtagelse gælder en support- og vedligeholdelsesordning, der særligt tager sigte på afhjælpning af fejl og mangler. Der skal tages stilling til, hvorvidt leverandøren også skal forestå drift af leverancen. Introduktion til denne bog Denne kommentar til K02 er opbygget som et praktisk arbejdsredskab, der kan være en støtte, når K02 anvendes til en påtænkt anskaffelse, i forbindelse med tilrettelæggelse af kontraktstyring efter kontraktindgåelse og ved eventuelle tvister. I kapitel 2 og 3 kommenteres de enkelte kontraktbestemmelser og bilag. I sammenhæng med kontraktbestemmelserne er tillige angivet udvalgte forslag til alternative formuleringer. Der er udfoldet store bestræbelser på at gøre K02 til et Agreed Document, hvor hensyn til henholdsvis leverandør- og kundeside er afvejet og forhandlet mellem interesseorganisationer, og intentionen har været, at offentlige myndigheder skal anvende dokumentet uden ændringer i selve kontraktteksten. Når vi alligevel angiver konkrete forslag til alternative formuleringer, skyldes det vores erfaringer fra praksis. Kundernes behov og forretningsmæssige situation afviger meget fra sag til sag, hvilket ikke mindst gælder de store og mere komplekse projekter, hvor K02 tænkes anvendt. Endvidere må det forventes, at kontrakten får en vis udbredelse hos kunder i den private sektor, der ikke er bundet af ønsket om ensartet håndtering af kontraktbetingelserne indenfor den offentlige sektor. På hjemmesiden findes link til relevant supplerende materiale, som for eksempel: K02 og K01 Bilagsmateriale, herunder udkast til driftsaftale Vejledningerne Tilsvarende norske standardkontrakter for offentlige it-anskaffelser Aftaleloven, købeloven og ophavsretsloven Udvalgte udbudsretlige regler Modenhed i it-baserede forretningsprojekter Link til nyhedsbreve inden for it-ret. Råd og vejledning anført i denne bog er af generel karakter. Særligt da standardkontrakten er et helt nyt dokument, bør både leverandører og kunder inddrage en advokat med godt kendskab til it-området. Vi kan i den forbindelse henvise til foreningen Danske IT-advokater. 11

12 Indledning Kontrakten indeholder en konfliktløsningsmodel, som indbefatter instrumentet mediation. Vi gør i den forbindelse opmærksom på, at Danske IT-advokater i samarbejde med Advokaternes Serviceselskab i efteråret 2007 har gennemført et længere uddannelsesforløb, hvor 19 af Danske IT-advokaters medlemmer er blevet certificerede mediatorer. Forløbet havde særlig fokus på tvister inden for it-retsområdet, og det kan anbefales at tage kontakt til Danske IT-advokater, hvis der er behov for en mediationsadvokat i et it-projekt. Ved anvendelse af K02 i konkrete sager skal man tage højde for mange omstændigheder, der kan varriere fra sag til sag. Særligt skal leverandører udvise omhu med hensyn til de formkrav og procedureregler, der angives i udbudsmateriale anvendt ved EU-udbud. Men det er vores håb, at denne bog kan bidrage til en hurtigere, mere effektiv og mindre problemfyldt indførelse af K02, end tilfældet var i de første år med K33 og K18. Redaktionen af bogen er afsluttet den 1. marts Nicolai Dragsted Ole Horsfeldt Jesper Langemark Claus Sørensen 12

13 Indledning K02 s anvendelsesområde I henhold til vejledningen er det fundet hensigtsmæssigt at præcisere, hvilke forudsætninger der skal lægges til grund for anvendelsen af kontrakten. De vigtigste forudsætninger er: Kunden er en dansk statsinstitution. Hvis kunden ikke er en dansk statsinstitution, vil det ofte stadigvæk være hensigtsmæssigt at tage udgangspkt. i standardkontrakten. Standardkontrakten skal i så fald tilpasses den pågældende kunde. Som eksempler kan nævnes: a. Kunden er ikke en del af den offentlige forvaltning, og der er en reel risiko for, at kunden ikke vil kunne betale kontraktsummen eller går konkurs. I så fald skal det overvejes at sikre leverandøren med ejendomsforbehold eller lignende. b. Hvis kunden ikke er omfattet af de statslige bevillingsretlige regler, kan det være i begge parters interesse, at kunden betaler (dele af) kontraktsummen tidligere, herunder at kravet om anfordringsgaranti bortfalder. Kunden skal dog i givet fald sikre sig mod leverandørens konkurs eller lignende. c. Hvis kunden ikke er omfattet af EU s udbudsretlige regler, bør det overvejes at udnytte denne frihed. Navnlig standardkontraktens pkt (afklaringsfase) og pkt. 6 (ændringer) er formuleret under hensyn til de begrænsninger, som de udbudsretlige regler, herunder forhandlingsforbuddet, medfører. Større anskaffelser af mere kompleks karakter, hvor udviklings- og implementeringsprojekter er af en vis størrelse (relateret til både økonomisk værdi, forretningsmæssig værdi, tidsforløb, teknisk kompleksitet og organisatorisk kompleksitet). Kontrakten omhandler således ikke leverancer af standardprodukter, hvor der kun i begrænset omfang skal ske specialtilpasninger mv., idet sådanne leverancer er omfattet af K01. Kunden forudsættes at yde en aktiv og kvalificeret medvirken ved projektgennemførelse. Leverandøren har det samlede projektansvar og er totalleverandør, men afhjælpningspligt for fejl i tredjepartsprodukter er modificeret. 13

14 Indledning Der er tale om anskaffelse af en leverance bestående af bl.a. programmel, udstyr og dokumentation, jf. leverancens omfang i kontraktens pkt. 3. Anskaffelsen sker på grundlag af en fyldestgørende leverancebeskrivelse (bestående af kundens kravspecifikation og leverandørens løsningsbeskrivelse). Leverancebeskrivelsen (bilag 3) er det helt centrale bilag og skal indeholde en fyldestgørende beskrivelse af den leverance, der skal leveres. I det omfang det ikke i kravspecifikationen er blevet ordentligt beskrevet, hvad der skal leveres, er det meget ubehageligt for begge parter. Det er dog særligt alvorligt for kunden, for hvis det ikke er beskrevet, har kunden som udgangspkt. ikke krav på at få det leveret, og så hjælper standardkontraktens bestemmelser om levering i rette tid, omfang, indhold, kvalitet, sted osv. med hertil knyttede misligholdelsesbeføjelser ikke. Der sker som udgangspkt. en samlet levering ved overtagelsesdagen, dog kan leverancen være opdelt i faser knyttet til delleverancer til opfyldelse af ibrugtagningsbehov og/eller som projektstyring. Der er en begrænset ret til ibrugtagning forud for overtagelsesdagen. Ibrug tag ning forud for overtagelsesdagen kan ske ved en aftalt ibrugtagning af en delleverance eller overskridelse af en frist for overtagelse. At der som udgangspkt. aftales vedligeholdelse og support af alle dele af leverancen fra overtagelsesdagen. Hvis der er aftalt ibrugtagning af en delleverance, skal leverandøren dog som udgangspkt. yde vedligeholdelse og support fra ibrugtagning af en godkendt delleverance. Hvis disse forudsætninger ikke er til stede, skal der foretages de fornødne tilpasninger i standardkontrakten, herunder i dennes bilag. Som det var tilfældet med K01, tilsigter K02 ikke at regulere alle eventualiteter. I vejledningen er det i øvrigt fundet relevant at præcisere, at selv om standardkontrakten håndterer enkelte problemstillinger omkring anvendelse af open source programmel, bør standardkontrakten dog ikke anvendes, såfremt der er tale om en ren open sourcekontrakt, dvs. en kontrakt, der udelukkende vedrører levering af open sourceprogrammel. 14

15 K02 - Ordlyden K02 STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT Kontrakt om levering, [drift] og vedligeholdelse af et it-system til [ ] mellem (i det følgende kaldet Kunden) og (i det følgende kaldet Leverandøren) 15

16 I N D H O L D S F O R T E G N E L S E 1. Definitioner 2. Baggrund og formål 3. Leverancens omfang 3.1 Generelt 3.2 Programmel 3.3 Udstyr 3.4 Dokumentation 3.5 Konvertering 3.6 Øvrige ydelser 4. Kundens it-miljø 5. Leverancens udførelse 5.1 Afklaringsfase og udtrædelse Afklaringsfase Kundens udtrædelsesadgang 5.2 Projektsamarbejde og medarbejdere 5.3 Modenhed 5.4 Kundens medvirken 5.5 Kvalitetssikring 5.6 Audit 5.7 Sikkerhed 5.8 Benyttelse af underleverandører 6. Ændringer 6.1 Generelt 6.2 Ændringer til levering som en del af Leverancen 6.3 Ændringer til levering som en Selvstændig Opgave 6.4 Kundens fremsættelse af ændringsanmodning 6.5 Leverandørens fremsættelse af ændringsanmodning 6.6 Ændringslog 6.7 Ændringer uden Leverandørens samtykke 7. Levering 7.1 Leveringssted 7.2 Tidsplan 7.3 Faseopdeling 8. Afprøvning 8.1 Generelt 8.2 Fabriksprøve 8.3 Installationsprøve 8.4 Delleveranceprøve 8.5 Overtagelsesprøve 8.6 Driftsprøve 9. Ibrugtagning 10. Overtagelse 11. Vedligeholdelse og support 11.1 Generelt 16

17 11.2 Vedligeholdelsesordningens tidsfrister 11.3 Udførelse 12. Drift 13. Servicemål 13.1 Generelt 13.2 Manglende opfyldelse af servicemål 14. Priser 14.1 Generelt 14.2 Leverancevederlag 14.3 Timebaserede vederlag 14.4 Vedligeholdelse og support Vederlag Fejlafhjælpning Fejlrapportering 14.5 Drift 14.6 Løbende betalinger og øvrige vederlag 15. Incitamenter 16. Betalingsbetingelser 17. Garanti 17.1 Generel garanti 17.2 Kundens medvirken 17.3 Ændringsmuligheder 17.4 Tredjemands udførelse af vedligeholdelse og ændringer 17.5 Hæftelse for underleverandører 17.6 Garanterede servicemål 17.7 Tredjemands rettigheder 17.8 Overholdelse af regler 17.9 Garantiperiode 18. Leverandørens misligholdelse 18.1 Forsinkelse Underretningspligt Bod Kundens beføjelser i øvrigt 18.2 Mangler Afhjælpning Bod for overskridelse af servicemål Forholdsmæssigt afslag Kundens beføjelser i øvrigt 19. Kundens misligholdelse 20. Kundens Ophævelse 20.1 Betingelser for ophævelse 20.2 Opgørelse ved ophævelse 21. Erstatning og forsikring 22. Force majeure 23. Rettigheder til programmel og dokumentation 23.1 Generelt 17

18 23.2 Standardprogrammel 23.3 Kundespecifikt programmel Kundens rettigheder Andre offentlige institutioners rettigheder 23.4 Open Source Programmel 24. Tavshedspligt 25. Overdragelse 26. Varighed 26.1 Vedligeholdelse og support 26.2 Drift 27. Tvistigheder 27.1 Lovvalg 27.2 Uenighed om kategorisering af en Fejl eller opfyldelse af servicemål 27.3 Øvrige tvister Forhandling Mægling Mindre tvister Større tvister 28. Bevillingsmæssige forbehold 29. Fortolkning og kontraktstyring 29.1 Fortolkning og forrang 29.2 Meddelelse 29.3 Kontraktstyring ved ændringer 30. Underskrifter 18

19 B I L A G S F O R T E G N E L S E Bilag 1: Tidsplan Bilag 2: Kundens it-miljø Bilag 3: Leverancebeskrivelse med Kravspecifikation og Løsningsbeskrivelse samt ændringsmuligheder (herunder optioner) Bilag 4: Dokumentation Bilag 5: Vedligeholdelse og support Bilag 6: Servicemål Bilag 7: Drift Bilag 8: Leverandørens modenhed Bilag 9: Ændringshåndtering Bilag 10: Samarbejdsorganisation Bilag 11: Kundens deltagelse og modenhed Bilag 12: Leverancevederlag og betalingsplan samt øvrige priser Bilag 13: Incitamenter Bilag 14: Prøver Bilag 15: Licensbetingelser for Standardprogrammel og Open Source Programmel samt krav til deponering 19

20 1. Definitioner Arbejdsdag Mandag til fredag bortset fra helligdage, juleaftensdag, nytårsaftensdag og grundlovsdag. Brugerdokumentation Beskrivelse(r) af Leverancens funktioner og anvendelses- og opsætningsmuligheder rettet mod slutbrugere, superbrugere, systemadministratorer og andre brugere, der ikke skal have indsigt i arkitektur eller kode. Delleverance En afgrænset del af en Leverance, der leveres i en Fase. Dokumentation Enhver udarbejdet beskrivelse relateret til Leverancen, herunder Bru ger dokumen tation og Systemdokumentation, jf. bilag 4. Drift Eksekvering af det Programmel, der udgør hele eller dele af Leverancen. Fase Periode for udførelse af en Delleverance, der afsluttes med en delleveranceprøve og eventuelt Ibrugtagning. Fejl Der foreligger en Fejl i det leverede, såfremt det ikke opfylder de af Leverandøren givne garantier, eller det i øvrigt ikke er eller fungerer, som Kunden med føje kunne forvente på grundlag af Kontrakten, medmindre der er tale om bagatelagtige forhold. Se tillige definitionen af Mangler. God it-skik En af it-branchen alment accepteret god udførelse inden for et bestemt område. Ibrugtagning Den dag, hvor Kunden tager Leverancen eller en del heraf i brug til daglig afvikling af sine forretningsmæssige opgaver. Installationsdag Den dag, hvor Leverandøren over for Kunden godtgør, at eventuelt udstyr, der indgår i en Delleverance eller en Leverance, er tilsluttet i funktionsdygtig stand hos Kunden, og hvor licenser til Programmel på det aftalte udstyr er tilgængelige. 20

21 Kontrakten Denne kontrakt med bilag og senere ændringer og tillæg. Kravspecifikation De af Kunden udarbejdede krav i bilag 3 til Leverancen med de af Leverandøren indarbejdede ændringer og tilføjelser. Kundespecifikt Programmel Programmel, der i bilag 3 rubriceres som programmel tilpasset, tilrettet eller udviklet specielt til Kunden i forbindelse med Leverandørens opfyldelse af Kontrakten. Leverance Alt, der i henhold til Kontrakten skal leveres senest på Overtagelsesdagen. Dette kan omfatte Programmel, udstyr, Dokumentation, implementering, uddannelse og andre ydel ser, der skal leveres senest på Overtagelsesdagen. Drift samt vedligeholdelse og sup port er ikke en del af Leverancen, selv om den eventuelt udføres forud for Over tagelsesdagen. Leverancebeskrivelse Udgøres af Kravspecifikation og Løsningsbeskrivelse. Løsningsbeskrivelse Leverandørens beskrivelse af, hvorledes Leverandøren opfylder Kundens Kravspe ci fikation. Mangler Der foreligger en Mangel i det leverede, såfremt det ikke opfylder de af Leverandøren givne garantier, eller det i øvrigt ikke er eller fungerer, som Kunden med føje kunne forvente på grundlag af Kontrakten, medmindre der er tale om bagatelagtige forhold. Se tillige definitionen af Fejl. Meddelelse Skriftlig kommunikation afgivet i overensstemmelse med pkt eller meddelelse givet på styregruppemøde, som fremgår af godkendt referat. Offentlig Institution Ministerier, styrelser, statsvirksomheder, selvstændige offentlige virksomheder (SOV), kommuner, regioner, offentlige forvaltningssubjekter, kommunale virksomheder, råd og nævn samt selvejende institutioner, hvis drift i det væsentlige finansieres med offentlige midler. Statslige aktieselskaber samt aktieselskaber med kommunal deltagelse er ikke omfattet. 21

22 Open Source Licens Licensbetingelser for Open Source Programmel, der bl.a. tillader Kunden at foretage ændringer i Programmel på grundlag af kildekode, der er stillet til rådighed af licensgiveren for Kunden, andre Kunder eller offentligheden, hvad enten licensgiveren er Leverandøren eller en tredjepart. Open Source Programmel Programmel, der leveres eller stilles til rådighed både i kildekode og i maskinlæsbar form på grundlag af en Open Source Licens. Option En ret for Kunden til at købe yderligere bestemte ydelser, som beskrevet i bilag 3, til de i Kontrakten fastsatte priser og øvrige vilkår. En Option kan bestilles til levering samtidig med og som en del af Leverancen eller som en Selvstændig Opgave. Overtagelsesdag Den dag, hvor Leverandøren består overtagelsesprøven, forudsat Kunden efterfølgende skriftligt godkender overtagelsesprøven, eller Kunden tager hele eller dele af Leverancen uberettiget i brug, jf. pkt. 10. Parterne Ved Parterne forstås Kunden og Leverandøren, og ved Part en af disse. Programmel Består af Kundespecifikt Programmel og/eller Standardprogrammel. Releases En mindre opdatering af Standardprogrammel eller Kundespecifikt Programmel, her under fejlrettelser. Almindeligvis kendetegnet ved, at identifikationsnummeret for Pro gram mellet ændres med en decimal (f.eks. fra 5.0 til 5.1). Selvstændig Opgave Optioner eller ændringer, som ikke afprøves som en del af Leverancen. Standardprogrammel Programmel, der ikke i bilag 3 er rubriceret som Kundespecifikt Programmel. Standardvedligeholdelses- og Standardudviklingsværktøjer Vedligeholdelses- og udviklingsværktøjer, som er almindeligt tilgængelige på det danske marked på sædvanlige kommercielle vilkår. Systemdokumentation Beskrivelse af Leverancen rettet mod driftspersonale, udviklere og andre 22

23 medarbejdergrupper, der har behov for indsigt i arkitektur og kode med henblik på at kunne ændre parametre, rette, vedligeholde og/eller driftsafvikle Programmellet. Version En opdatering, der indeholder væsentligt ændret funktionalitet. Almindeligvis kendetegnet ved, at hovednummeret for versionen ændres (f.eks. fra 5.1 til 6.0). 2. Baggrund og formål [Tilpasses individuelt - beskriv baggrunden for indgåelse af kontrakten og Kundens formål med leverancen.] 3. Leverancens omfang 3.1 Generelt Leverandøren skal levere de ydelser, der er beskrevet i Leverancebeskrivelsen (bilag 3), herunder bestilte Optioner. Leverancebeskrivelsen (bilag 3) indeholder Kravspecifikationen og Løs nings beskri vel sen. Leverandøren har forud for indgåelse af Kontrakten indarbejdet de fornødne ændringer og tilføjelser i det af Kunden udarbejdede udkast til kravspecifikation, eventuelt i dialog med Kunden, således at Løsningsbeskrivelsen kan forudsættes fuldt ud at opfylde Kravspecifikationen. Endvidere gennemføres en afklaringsfase med henblik på yderligere afstemning mellem Kundens behov og Leverandørens løsning, jf. pkt Hvis det efter kontraktindgåelse konstateres, at Kravspecifikationen alligevel ikke opfyldes ved Løsningsbeskrivelsen, skal Leverandøren i fornødent omfang supplere eller æn dre Løsningsbeskrivelsen samt levere sådanne yderligere ydelser, der er nødvendige for at opfylde Kravspecifikationen og Kontrakten i øvrigt. Sådan levering skal ske på samme vilkår som fastsat i Kontrakten, herunder uden yderligere vederlag og inden for de i tidsplanen fastsatte frister. Såfremt Løsningsbeskrivelsen indeholder yderligere funktionalitet, udstyr mv. end nødvendigt til at opfylde Kravspecifikationen, og uden at dette udtrykkeligt er angivet at være en Option eller anden ændringsmulighed, der skal bestilles særskilt, skal Leverandøren levere dette i tillæg til opfyldelse af Kravspecifikationen. Leverandøren har leveranceansvaret. Dette indebærer, at Leverandøren skal levere de ydelser, herunder Programmel, udstyr og Dokumentation, der sammen med 23

24 KO2 Kundens eksisterende it-miljø, Leverandørens anvisninger om ændringer heri og krav til Kundens medvirken, opfylder Leverancebeskrivelsen og Kontrakten i øvrigt. 3.2 Programmel Leverandøren skal ved opfyldelse af Kontrakten levere Standardprogrammel samt Kundespecifikt Programmel som angivet i Leverancebeskrivelsen (bilag 3). 3.3 Udstyr Leverandøren skal levere det udstyr, der er angivet i Leverancebeskrivelsen (bilag 3), eller som i øvrigt er nødvendigt for, at Kontraktens krav opfyldes. 3.4 Dokumentation Leverandøren skal levere den Dokumentation, der er nødvendig for at udnytte Leverancen, herunder Systemdokumentation for de i Leverancebeskrivelsen beskrevne tekniske grænseflader i Leverancen. Endvidere skal Leverandøren levere den Dokumentation til Kunden, der er nødvendig for, at tredjemand på rimelige og sædvanlige vilkår kan varetage Drift og udføre vedligeholdelse af Programmel og udstyr samt ændring af Kundespecifikt Programmel i henhold til Kontraktens øvrige bestemmelser. Dokumentationen er nærmere specificeret i bilag 4, herunder angivelse af den Dokumentation Leverandøren skal levere ved overtagelsesprøven, delleveranceprøver eller andre prøver. Dokumentationen for de tekniske grænseflader skal opfylde kravene angivet i bilag 4. Medmindre andet fremgår af bilag 4, skal al Dokumentation leveres og godkendes senest på Overtagelsesdagen. Dokumentationen skal udformes i overensstemmelse med God it-skik og opfylde de i Kontrakten fastsatte krav, herunder i bilag 4. Hvis Leverandøren foretager ændringer i Leverancen, herunder som led i vedligeholdelse, skal den leverede Dokumentation samtidig ændres, således at Dokumentationen fortsat opfylder ovennævnte krav. Tilsvarende gælder ved Optioner. Brugerdokumentation skal foreligge på dansk, og øvrig Dokumentation skal foreligge på dansk eller engelsk, medmindre andet er angivet i bilag 4. Dokumentationen kan i sædvanligt omfang stilles til rådighed for Kunden som en integreret del af det relevante Programmel, eller som online-dokumentation, herunder ved at Leverandøren anviser en web-adresse eller lignende, hvorigennem Kunden kan få adgang til Dokumentationen. 3.5 Konvertering Såfremt Leverandøren skal konvertere data eller tilbyder dette som en Option, er kravene hertil nærmere beskrevet i bilag 3, herunder format, medie mv. for 24