It-kontrakter. 1. Indledning

Størrelse: px
Starte visningen fra side:

Download "It-kontrakter. 1. Indledning"

Transkript

1 It-kontrakter 1. Indledning Det anslås, at der omsættes it-ydelser i Danmark for omkring 30 mia. kr. om året. Ydelserne kan f.eks. være udvikling og vedligeholdelse af store komplekse systemer, salg af standardsoftware, drift af it-systemer, rådgivning og anden konsulentbistand. Dette store beløb udtrykker informationsteknologiens afgørende betydning for virksomheder, offentlige myndigheder, privatpersoner og dermed for samfundet i bred forstand. Virksomheder og offentlige myndigheder investerer betydelige beløb i indkøb, udvikling og drift af it-systemer, fordi effektiv it er en afgørende forudsætning for at kunne levere ydelser og betjene borgere i nutidens samfund. Ofte investeres to-cifret og i nogle tilfælde tre-cifret millionbeløb i udvikling og drift af it-systemer. It-systemernes vitale betydning indebærer, at det ofte har store konsekvenser, når noget går galt. Og med mellemrum går noget galt. Særligt i store og komplekse udviklingsprojekter er spørgsmålet reelt ikke, om noget vil gå galt, men hvor meget der går galt. Komplekse it-projekter kan ikke gennemføres med en fejlprocent på 0. At det kan være forbundet med store konsekvenser, når it-systemer fejler, er illustreret i adskillige offentligt omtalte sager i de senere år. I 2003 indebar driftsfejl i Danske Banks systemer bl.a., at danskere gennem flere dag ikke havde adgang til deres netbank, og at store internationale virksomheder ikke kunne gennemføre betalinger. Nationalbanken måtte træde til med 5 mia. kr. for at sikre likviditeten på pengemarkedet. I 2004 medførte problemer med et nyt lønsystem hos Københavns Kommune, at flere tusinde ansatte i kommunen gennem længere tid fik udbetalt forkert løn og i enkelte tilfælde næsten ingen løn. I 2005 oplevede Mærsk massive it-problemer i containerafdelingen, der bl.a. bevirkede fejlforsendelse og fejllastning af containere, hvilket førte til stor kundeutilfredshed. Analytikere har anslået Mærsks tab på disse problemer til 1,5 mia. kr. Senest har det nye elektroniske tinglysningssystem indebåret store forsinkelser i tinglysningen med tab til følge for en række borgere. Det samlede tab er estimeret til en halv mia. kr. og et gruppesøgsmål skal nu afgøre erstatningsspørgsmålet. Det skal dog retfærdigvis nævnes, at problemerne i den elektroniske 1

2 tinglysning tilsyneladende navnlig skyldes forsinkelser i den manuelle behandling af de sager, der ikke kunne behandles elektronisk. Disse sager illustrerer, at det potentielt er meget store krav, der kan blive rejst, når der opstår it-problemer. Kombinationen af høje omkostninger til anskaffelse og brug af itydelser, ydelsernes vitale betydning og de potentielt store konsekvenser, når noget går galt, skaber et behov for en høj grad af forudsigelighed i parternes indbyrdes aftaleforhold. Parterne har behov for at vide, hvilken ydelse, leverandøren skal levere, og kunden dermed betale for. Dette kan lyde banalt og gælder for enhver form for ydelse. Mange it-leverancer, som f.eks. systemudvikling eller drift, har imidlertid en kompleksitet, der kan gøre det vanskeligt at fastlægge præcist, hvad der er omfattet af leverandørens ydelse. Endvidere forudsætter denne type projekter, at kunden også yder forskellige bidrag f.eks. i forbindelse med afprøvning af systemet. For at skabe klarhed over, hvad leverandøren og kunden hver især skal levere i projektet, indgås en kontrakt, der nærmere beskriver ydelserne og parternes forpligtelser. Parterne har ikke kun behov for at vide hvilke ydelser, de hver især skal tilvejebringe, men også hvilke konsekvenser en misligholdelse af disse forpligtelser udløser. Derfor vil kontrakten normalt også indeholde en detaljeret beskrivelse af parternes misligholdelsesbeføjelser og ansvarsbegrænsninger. Selvom parterne har et ønske om med kontrakten at skabe klarhed over indholdet af deres indbyrdes forpligtelser, misligholdelsesbeføjelser mv., vil det være en illusion, at kontrakten kan eliminere alle uenigheder mellem parterne. Selv ikke den mest omfattende og detaljerede kontrakt vil kunne forholde sig til alle de typer af problemstillinger, der kan opstå i et langvarigt og komplekst it-projekt. Parternes retsforhold vil derfor heller ikke udelukkende blive afgjort af kontraktens indhold. I nogle tilfælde må svaret på en uenighed søges i baggrundsretten, herunder navnlig obligationsretten. Baggrundsretten har ikke kun betydning, når der opstår uenigheder i bestående kontraktforhold. I kontraktforhandlinger kan det være væsentligt at kende retstilstanden efter baggrundsretten, da denne vil være tilbagefaldspositionen, hvis ikke andet aftales i kontrakten. Jurister, der arbejder med it-kontrakter, må derfor både have kendskab til kontraktreguleringen og den baggrundsretlige regulering af it-leverancen. Kravet om kendskab til kontraktreguleringen indebærer bl.a. et kendskab til de reguleringstemaer, som kontrakten bør indeholde, et kendskab til de standardkontrakter, der gælder på området, og i tilknytning hertil et kend- 2

3 skab til de branchekutymer, der gælder for forskellige typer af it-leverancer. Kravet om kendskab til den baggrundsretlige regulering indebærer bl.a., at juristen skal have kendskab til de særlige forhold, som gør sig gældende for den konkrete it-leverance, og fortolke de baggrundsretlige regler i lyset heraf. Det er disse spørgsmål, som er genstandsfeltet for it-kontraktretten. Den nærmere besvarelse af spørgsmålene afhænger af typen af itleverance. Der er ganske stor forskel på at indgå en licensaftale om brug af standardprogrammel og indgå en stor og langvarig udviklingsaftale om udvikling af et nyt system eller om drift af it-systemer. Det er derfor nødvendigt at sondre mellem de forskellige typer af it-leverancer og tilknyttede aftaler. I det følgende sættes fokus på to af de centrale reguleringstemaer i itkontrakter, ændringshåndtering (afsnit 4) og tvistløsnings- og forebyggelsesbestemmelser (afsnit 5). Inden da introduceres de væsentligste typer af it-kontrakter (afsnit 2) og de to it-standardkontrakter K01 og K02 (afsnit 3). 2. Aftaletyper 2.1. Udviklingsaftaler De funktioner, som it-systemer skal varetage, vil i mange tilfælde kunne udføres ved brug af standardsoftware, der ikke er udviklet til en specifik brugers behov. I nogle tilfælde vil en virksomhed eller en myndighed imidlertid have nogle behov, som ikke kan tilgodeses af det standardsoftware, som udbydes på markedet. Brugeren kan i disse tilfælde vælge at indgå en aftale med en leverandør om specialudvikling af programmel, der opfylder brugerens behov. Projektet kan indebære, at programmet udvikles og kodes helt fra bunden, men ofte vil det færdige program være sammensat af nyudviklede komponenter og eksisterende programkomponenter, der eventuelt tilpasses kundens særlige behov. Fordelen for kunden ved at få udviklet sit eget program er som allerede antydet først og fremmest, at kunden får et program, der er skræddersyet til kundens specifikke behov, og som f.eks. kan understøtte de særlige forretningsgange, der gælder i kundens virksomhed. Herudover vil kunden selv kunne afgøre hvornår og hvordan efterfølgende videreudvikling og ændring af programmet skal ske. For standardsoftware er det typisk producenten, der afgør, hvornår der skal udgives nye versioner, og hvilke ændringer disse skal indeholde. 3

4 Ulempen ved specialudviklet programmel er navnlig, at det er væsentligt dyrere at anskaffe end standardprogrammel. Hvor udviklingsomkostningerne til standardprogrammel kan spredes ud på alle brugerne af programmet, er der kun én bruger til at afholde alle omkostninger, herunder leverandørens avance, forbundet med udviklingen af det specialudviklede program. Herudover indebærer udviklingen af specialprogrammel ofte et stort ressourcetræk hos kunden, da en succesfuld gennemførelse af et udviklingsprojekt forudsætter et tæt samarbejde mellem kunden og leverandøren. Endvidere er der en større risiko for leveranceproblemer ved implementering af specialudviklet programmel. For det første er der en (ikke ubetydelig) risiko for forsinkelser, fordi programmet først skal udvikles, og for det andet er der en risiko for, at programmet vil være plaget af børnesygdomme. Disse risici er ikke til stede, hvis der vælges eksisterende og kendt standardprogrammel. Det er et grundlæggende træk ved udviklingsaftalen, at ydelsen ikke eksisterer på tidspunktet for aftalens indgåelse. Dette gør udviklingsaftalen kompleks og kompleksiteten øges yderligere af, at kunden på aftaletidspunktet ofte ikke har fuld klarhed over sine egne behov. I løbet af udviklingsprojektet vil det derfor ofte vise sig, at kunden på nogle punkter ønsker noget andet af programmet end oprindeligt forudsat. Vanskelighederne ved på forhånd klart at definere den endelige ydelse indebærer et kontraktskisma, der er svært at løse: Kunden vil ofte ønske at programmet leveres til en fast pris for at undgå risikoen for, at prisen løber løbsk og bliver langt højere, end hvad kunden har budgetteret med. Leverandøren vil imidlertid have svært ved at binde sig til en fast pris, hvis ikke ydelsen ligger helt fast på aftaletidspunktet. Disse vanskeligheder kan adresseres ved forskellige former for leverancemodeller. De to yderpunkter udgøres af vandfaldsmodellen og fasemodellen. Efter vandfaldsmodellen udfærdiger kunden en kravspecifikation med en detaljeret beskrivelse af de krav, som programmet skal leve op til. Udviklingen af programmet kan være delt op i arbejdsfaser men leveringen sker samlet for programmet ved en afsluttende afprøvning og mod betaling af en fast pris. Vandfaldsmetaforen skal illustrere, at udviklingen af systemet sker i ét kontinuerligt forløb afsluttende med, at systemet (i vandfaldsmetaforen) væltes ud over kanten i en samlet alt eller intet -afprøvning. Det er leverandørens ansvar, at programmet lever op til kravspecifikationen, og leverandøren skal uden beregning tilpasse programmet, hvis ikke 4

5 dette er tilfældet. Såfremt kunden under vejs i projektet ønsker ændringer i programmet i forhold til, hvad der følger af kravspecifikationen, skal kunden betale for sådanne ændringer. Fordelen ved vandfaldsmodellen er, at prisen og ydelsen er kendt på aftaletidspunktet. Kunden risikerer ikke store ekstraregninger, og leverandøren risikerer ikke at blive mødt med krav til programmet, som ikke allerede var kendt. Ulempen er, at modellen ikke levner meget fleksibilitet i projektet. Modellen forudsætter, at kunden helt præcist kan definere sine behov til programmet allerede inden udviklingen er gået i gang, hvilket som nævnt i praksis ofte ikke er muligt. Efter den rene fasemodel udvikles programmet i selvstændige faser. For hver fase aftaler parterne nærmere om indholdet af den pågældende delleverance og prisen herfor. Med denne model opnås en høj grad af fleksibilitet, idet ydelsen løbende defineres i de enkelte delfaser. Modellen rummer imidlertid den ulempe for kunden, at den samlede pris for programmet ikke kendes ved aftalens indgåelse, da denne fastlægges i takt med de enkelte delleverancers gennemførelse. Kunden risikerer endvidere at bringe sig i en svag forhandlingsposition, da udviklingsomkostningerne kan være spildt, hvis projektet opgives halvvejs i forløbet. Når parterne skal nå til enighed om pris og ydelse i de senere delfaser af projektet, vil leverandør derfor have en stærkere forhandlingsposition end kunden. Af disse grunde har den rene fasemodel aldrig vundet udbredelse. Trods de beskrevne svagheder har vandfaldsmodellen gennem mange år været den almindeligt anvendte i it-udviklingsprojekter. Begge de to nedenfor beskrevne standardkontrakter for systemudvikling, K01 og K02, er således baseret på vandfaldsmodellen. I de senere år har hybridmodeller, der placeres sig mellem vandfaldsmodellen og den rene fasemodel, imidlertid tiltrukket sig en del opmærksomhed. Betegnelserne agile og iterative udviklingsaftaler dækker over aftaletyper, hvor der indbygges mere fleksibilitet end i vandfaldsmodellen men stadig således, at den overordnede ramme for kravene til programmet og prisen typisk er kendt på aftaletidspunktet Softwarelicensaftaler Når programmel ikke udvikles for en specifik kunde men til et bredere marked stilles programmet typisk til rådighed for kunderne på vilkår, der fremgår af en softwarelicensaftale. Der kan grundlæggende sondres mellem de klassiske proprietære licensaftaler og open source licensaftaler. Indtil for få år siden var de proprietære licensaftaler reelt den eneste aftaleform, der blev anvendt ved kommerciel tilrådighedsstillelse af programmel. Denne aftaletype er karakteriseret ved, at brugeren får nogle 5

6 nærmere afgrænsede brugsrettigheder til programmet, mens alle ophavsrettigheder og ejendomsrettigheder i øvrigt forbliver hos leverandøren. Heraf betegnelsen proprietær der er afledt af det engelske proprietary rights (ejendomsret). For programmer med en meget omfattende brugerskare, vil licensaftalen have karakter af en masseaftale, hvor den enkelte bruger normalt må acceptere licensaftalen, som den foreligger. Forretningsmodellen for denne type programmer tillader ikke individuel forhandling og særskilte vilkår for de enkelte brugere. Der er tale om et standardiseret produkt, som stilles rådighed på standardvilkår, og prisen for programmet er sat herefter. Typisk, og ud fra samme argumentation, er det ganske begrænset, hvilke krav brugeren kan gøre gældende under aftalen. Programmet sælges som det er og forefindes, eventuelle fejl rettes efter leverandørens egen vurdering, og leverandøren vil have fraskrevet sig næsten alt ansvar for tab opstået som følge af mangler ved programmet. Nogle programmer retter sig mod en mere begrænset brugerskare. Det kan f.eks. være en brancheløsning, der kun har et begrænset antal brancheaktører som brugere. Forholdet mellem parterne vil i disse situationer ligger et sted mellem det forhold, der består mellem kunden og leverandøren ved specialudvikling, og forholdet mellem producenten af standardprogrammel til massemarkedet og brugerne heraf. Den enkelte kunde har større kommerciel betydning for leverandøren, hvilket kan give kunderne en bedre forhandlingsposition og dermed en licensaftale, der i højere grad beror på forhandling mellem parterne. Ofte må leverandøren i denne situation påtage sig videregående forpligtelser og ansvar, end hvad der følger af licensaftaler, der retter sig mod massemarkedet. Det er heller ikke usædvanligt, at videreudviklingen af programmet i disse situationer sker i en tæt dialog mellem leverandøren og de enkelte brugere. For alle typer af proprietærer licensaftaler vil gælde, at aftalen må forholde sig til, hvilke brugsrettigheder brugeren udstyres med, og hvilken betalingsmodel, der skal gælde for brugen. Aftalen må bl.a. forholde sig til brugsrettens tidsmæssige og geografiske afgrænsning, hvilke former for brug der er omfattet, om licens kan overdrages mv. I relation til betaling må aftalen forholde sig til, hvad størrelsen af licensvederlaget skal udregnes efter (antal brugere med adgang til programmet, antal samtidige brugere, antal maskiner programmet er installeret på mv.). Licensmodellerne hører til blandt de væsentligste reguleringstemaer, og de komplicerede modeller giver ofte anledning til tvivl om opgørelsen. 6

7 Gennem de senere år er open source licenser blev stadig mere udbredt som et alternativ til de proprietære licenser. Open source licenser er karakteriseret ved, at udvikleren af programmet stiller kildekoden gratis til rådighed for brugerne (deraf navnet open source ) og samtidig giver brugerne en næsten uindskrænket ret til at kopiere, videredistribuere, ændre og videreudvikle programmet. Open source licenserne blev oprindeligt etableret på et idealistisk grundlag som et opgør med de klassiske proprietære licensers lukkede model: Når kildekoden gøres offentligt tilgængelig, kan alle fejlrette, videreudvikle og forbedre programmet, og dermed kan det globale udviklersamfund bidrage til bedre og mindre fejlbehæftede programmer. På trods af det idealistiske udgangspunkt, har open source licenser fået en betydelig kommerciel udbredelse, og globale leverandører som Microsoft, IBM m.fl. udbyder i dag nogle af deres produkter på open source licenser. På trods af, at kildekoden stilles gratis til rådighed under en open source licens, er der flere muligheder for at tjene penge på open source software, bl.a. gennem vedligehold, rådgivning og salg af premium versioner, der er undergivet en proprietær licens Vedligeholdelsesaftaler Ingen edb-programmer er fejlfrie og selvom programmer normalt gennemgår en grundig test, inden de tages i brug, vil der løbende blive opdaget nye fejl i programmet. Selv den bedste test vil ikke kunne afdække alle fejl. Større programmer rummer så mange funktionaliteter, at afprøvningen kun kan teste nogle af dem. Mange fejl må derfor udbedres, efter programmet er taget i brug. Fejlrettelse forudsætter adgang til programmets kildekode. Brugeren vil typisk ikke have adgang til kildekoden til standardprogrammel, medmindre der er tale om open source programmel. Allerede af denne grund vil brugeren være afhængig af, at producenten retter de fejl, der løbende konstateres. Men selv i situationer, hvor brugeren har adgang til programmets kildekode, f.eks. ved brug af open source programmel eller specialudviklet programmel, vil brugeren ofte ikke have de fornødne kompetencer til selv at foretage fejlrettelse. Det er derfor sædvanligt, at der mellem kunden og leverandøren indgås en vedligeholdelsesaftale, der forpligter leverandøren til løbende at foretage fejlrettelse. Leverandørens vedligeholdelsesforpligtelser er grundlæggende forskellige afhængigt af, om der er tale om standardprogrammel rettet mod massemarkedet, eller der er tale om specialudviklet programmel. For standardprogrammel rettet mod massemarkedet vil leverandørens forpligtelser til at rette fejl sædvanligvis være begrænset, og det vil være leverandørens egen 7

8 beslutning, hvordan og hvornår fejlrettelse sker. Forpligtelsen til at rette fejl vil typisk være langt mere omfattende og detaljeret reguleret i relation til specialprogrammel. Det er i disse situationer, at der indgås en særskilt vedligeholdelsesaftale. Vedligeholdelsesaftalen kan rumme mere end den egentlige fejlrettelse og vil ofte også indeholde et supportelement, der giver brugerne en hotline adgang til at stille spørgsmål om brug af programmet. Nogle gange kan aftalen også give kunden mulighed for at anmode om mindre tilpasninger i programmet, uden at der er tale om egentlig fejlrettelse. Udover selve ydelsesbeskrivelsen og betalingsreguleringen er et af de centrale reguleringstemaer i vedligeholdelsesaftale spørgsmålet om, hvor hurtigt leverandøren skal påbegynde fejlretning efter en fejl er opdaget, og om leverandøren skal forpligte sig til at have udbedret fejlen inden for et bestemt tidsrum. Ved reguleringen af disse spørgsmål sondres normalt mellem forskellige typer af fejl, således at kravene er strengere jo mere alvorlig fejlen er Driftsaftaler Det er af afgørende betydning, at virksomheder og myndigheders itsystemer er tilgængelige for medarbejdere, kunder, borgere og andre brugere, når disse skal bruge systemerne. It-systemernes vitale betydning i det moderne samfund indebærer som allerede beskrevet, at det ofte vil være forbundet med store gener, når systemet ikke er tilgængeligt. Systemernes tilgængelighed sikres gennem brug af et solidt driftsmiljø. Driftsmiljøet består helt overordnet af de computere, som programmerne kører på og netværk, som forbinder de forskellige computere. De enkelte programmer kan ligge lokalt på brugerens egen computer eller på en central server, hvorfra programmet stilles til rådighed for brugerne. Centrale virksomhedssystemer, som lønsystemer, crm-systemer til kundehåndtering mv. vil typisk være lagret på en central server men også brugerprogrammer som f.eks. office- og mailprogrammer kan køres fra et centralt driftsmiljø. Virksomheden kan vælge selv at etablere og drive det centrale driftsmiljø, men virksomheden kan også vælge at lade en ekstern leverandør varetage driften. I så fald har leverandøren ansvaret for driften af kundens systemer, og det er leverandørens opgave at sikre, at driftsmiljøet kører, således at kundens programmer er tilgængelige som planlagt. Når virksomheder og myndigheder vælger at lade en ekstern leverandør varetage driften af deres it-systemer, kan det skyldes flere forhold. Blandt de væsentligste er en forventning om besparelser, bedre drift og fokusering på egne kernekompetencer. Professionelle driftsoperatører vil kunne opnå 8

9 nogle stordriftsfordele, der ofte gør dem i stand til at levere driftsydelserne billigere, end kunden selv kan gøre det. Samtidig kan den professionelle driftsoperatør investere i den nyeste teknologi og tiltrække de dygtigste medarbejdere. Ofte vil driftsoperatøren derfor kunne tilbyde et højere serviceniveau, end kunden kan opnå ved selv at varetage driften. Endelig kan kunden have et ønske om at koncentrere sig om sine egne kernekompetencer frem for at skulle bruge ressource, herunder ledelsesressourcer, på et område (it-drift), som kunden ikke har ekspertise inden for. Der kan også være ulemper forbundet med outsourcing. Som den væsentligste nævnes ofte, at kunden mister kontrollen med driften af sine egne systemer og dermed bliver meget afhængig af leverandøren. I nogle tilfælde har det endvidere vist sig, at de forventede besparelser ikke er opnået, og at kunden har måttet bruge langt flere ressourcer på samarbejdet med leverandøren end forventet. Fordelene synes dog ofte at opveje ulemperne og faktum er, at et meget stort antal virksomheder og myndigheder vælger eksterne leverandører til driften af deres it-systemer. Driftsydelsen vil typisk bestå af en række forskellige ydelser. Ved mainframedrift, dvs. drift fra meget store computere placeret hos leverandøren, vil leverandøren stille serverkapacitet til rådighed, hvorfra kundens systemer vil blive afviklet. Som en del af driftsmiljøet vil leverandøren anvende driftsprogrammel, som sikrer optimal drift af kundens programmel og som ligeledes sikre back up af data og beskytter mod hackerangreb og tilsvarende sikkerhedstrusler. Ofte vil leverandøren som en del af sin driftsydelse også håndtere kundens softwarelicenser (betaling, fornyelse mv.) og eventuelt kontakt med andre af kundens it-leverandører. Driftsydelsen kan også omhandle kundens desktop-miljø, dvs. de computere, som medarbejderne hos kunden anvender. I så fald varetager leverandøren den løbende udskiftning af computere, opgradering af programmel på computerne mv. Den aftale, som parterne indgår om leverandørens drift af kunden itsystemer, vil ofte være af længere varighed, typisk 5-7 år. Der er mange startomkostninger forbundet med at flytte driften til leverandøren, og aftalen bliver derfor kun rentabel, hvis den løber i en længere periode. Blandt de væsentligste reguleringstemaer er derfor behovet for ændringer i løbet af aftaleperioden. Kundens behov vil som regel ændre sig i løbet af aftaleperioden, og det samme vil markedspriserne (normalt i nedadgående retning). Aftalen skal derfor indeholde mekanismer, som tager højde for dette. Et andet væsentligt element i en driftsaftale er de servicemål, som leverandørens ydelse skal leve op til. Aftalen vil typisk indeholde et krav om, at kundens systemer skal have en nærmere angivet tilgængelighed, f.eks. 99,0%, således at systemerne skal være tilgængelige for brugerne i mindst 99,0% af 9

10 den definerede driftstid. Det er vigtigt for kunden, at det er muligt at skifte driftsleverandør ved aftalens ophør, og aftalen vil derfor normalt også indeholde bestemmelser om leverandørens ophørsassistance, når driften skal flyttes til en anden driftsoperatør. Hvis driften tidligere har været varetaget internt hos kunden, vil flytningen til leverandøren ofte indebære en overdragelse af de medarbejdere, der hidtil har varetaget opgaverne internt hos kunden. Reguleringen af denne medarbejderoverdragelse, der er omfattet af lov om virksomhedsoverdragelse, vil også være et reguleringstema i aftalen. Der eksisterer ikke en standarddriftsaftale på samme måde som man med K01 og K02 har standardudviklingsaftaler. 3. Standardkontrakter K01 og K02 Standardkontrakter spiller en stor rolle inden for mange brancher. Itkontraktområdet har også i mange år været præget af nogle få men vigtige standardkontrakter for udvikling af it-systemer. De to første væsentlige standardkontrakter, benævnt K18 og K33, blev udarbejdet i starten af 1990 erne af Kammeradvokaten på vegne af Finansministeriet til brug for de statslige myndigheders indkøb og udvikling af itsystemer. K18 var tiltænkt mindre udviklingsprojekter, mens K33 skulle anvendes til større og mere komplekse udviklingsprojekter. Bogstavet K stod for Kammeradvokaten mens tallene 18 og 33 stod for kontrakternes sideantal. K18 og K33 fik stor udbredelse og er blevet anvendt gennem mange år, ikke kun af offentlige myndigheder men også af private virksomheder ved deres anskaffelse af it-systemer. Kontrakterne blev dog også kritiseret for at være for kundevenlige og ikke skabe en rimelig fordeling af risici mellem kunden og leverandøren. I stigende grad blev kontrakterne endvidere kritiseret for ikke at være tilstrækkelig fleksible og give tilstrækkelig mulighed for at aftale ændringer af ydelsen undervejs i projektet på en hensigtsmæssig måde. Efter en række offentlige skandale-projekter, hvor udvikling af store it-systemer til offentlige kunder var blevet voldsomt forsinket og langt dyrere end først aftalt, nedsatte Teknologirådet i 2000 et udvalg (benævnt Bonnerup-udvalget efter udvalgsformanden Erik Bonnerup), som skulle udarbejde en rapport med anbefalinger til, hvordan man bedre kunne gribe offentlige it-projekter an. En af rapportens anbefalinger var at udarbejde 10

11 nye standardkontrakter til erstatning for K18 og K33, der blev anset for forældede og ufleksible. Umiddelbart herefter nedsatte Statens IT-råd i 2001 en arbejdsgruppe, der skulle udarbejde to nye standardkontrakter til afløsning for K18 og K33. Arbejdsgruppen bestod af repræsentanter fra såvel kundesiden som leverandørsiden. Dette var vigtigt, fordi de nye standardkontrakter hermed fik karakter af agreed documents, dvs. dokumenter der var opnået enighed om blandt repræsentanter fra såvel kunde- som leverandørside. I 2004 blev afløseren for K18, benævnt K01, offentliggjort. K01 er udarbejdet til brug for kortvarige it-udviklingsprojekter. I 2007 blev K02 offentliggjort. K02 afløser K33 og er således tænkt brugt til længerevarende it-udviklingsprojekter med en større grad af nyudvikling, end tilfældet er for K01. Både K01 og K02 er baseret på vandfaldsmodellen, dvs. at det samlede system beskrives inden udviklingsprojektet starter, og parterne indgår aftale om levering af det samlede system til en fast pris. K01 og navnlig K02 rummer dog en række elementer, som giver en højere grad af fleksibilitet end K18 og K33. Kunden har således ret til at træde ud af projektet mod betaling, hvis det i en indledende afklaringsfase viser sig, at der er behov for ændringer i forhold til den oprindelige beskrivelse af systemet, og parterne ikke kan nå til enighed om prisen for disse ændringer. Begge kontrakter indeholder endvidere en ændringshåndteringsprocedure, der beskriver kundens mulighed for mod betaling at anmode om ændringer af systemet undervejs i udviklingsprojektet. I K02 er der herudover mulighed for, at systemet leveres i faser, således at de enkelte delsystemer afprøves for sig, inden systemet til slut afprøves i sin helhed. Både K01 og K02 er opbygget efter en klassisk kontraktmodel, dvs. med en hovedaftale og en række bilag, der bl.a. rummer kravspecifikationen, vedligeholdelsesvilkår, samarbejdsorganisation mv. K01 indeholder modelbilag, dvs. en egentlig skabelon for bilagene til kontrakten, mens K02 kun indeholder forklaringer til, hvad bilagene bør indeholde. For begge kontrakter er der udarbejdet en tilhørende vejledning. Der er endvidere på privat initiativ skrevet kommentarer til såvel K01 som K02 Se Dragsted m.fl., K01 med kommentarer (2004) og samme K02 med kommentarer (2007). K01 og K02 har opnået stor udbredelse både blandt offentlige og private kunder men ofte således, at kontrakterne tilrettes den enkelte kundes særlige ønsker. 11

12 Der findes på nuværende tidspunkt ikke andre standardkontrakter for itleverancer end K01 og K02, men arbejdsgruppen der har udarbejdet de to kontrakter arbejder i øjeblikket på en standardkontrakt for agile udviklingsprojekter (se om agile udviklingsprojekter ovenfor). Det har endvidere været overvejet at udarbejde en standardaftale for drift af it-systemer, men en sådan kontrakt findes ikke på nuværende tidspunkt. Statens og Kommunernes Indkøbs Service (SKI) har udarbejdet en række itrammeaftaler, som offentlige myndigheder kan indkøbe it-leverancer under uden at gå i udbud. Aftalekomplekset omfatter bl.a. aftaler om udvikling, om drift og om softwarelicenser. Kontrakterne har en stor praktisk betydning, men har ikke karakter af standardkontrakter. K01 og K02 og de øvrige standardkontrakter, der måtte komme til, har som udgangspunkt kun betydning for parternes retsforhold, hvis parterne vælger at lægge dem til grund for leverancen. En part kan således ikke støtte ret på en bestemmelse i standardkontrakterne, hvis ikke bestemmelsen er vedtaget mellem parterne. Standardaftalerne kan dog efter omstændighederne udtrykke en branchekutyme, som kan tillægges betydning ved fortolkning af parternes individuelle aftale og eventuelt også ved fastlæggelsen af baggrundsretten. Endvidere kan der muligvis ved uklarhed i aftalegrundlaget opstilles en formodning for, at en bestemmelse skal forstås i overensstemmelse med den retstilstand, der følger af standardkontrakterne. 4. Ændringshåndteringsbestemmelser i it-kontrakter 4.1. Indledning Som det gælder for andre typer af længerevarende og komplekse aftaler, vil der også under vejs i opfyldelsen af it-kontrakter kunne opstå behov for at foretage ændringer af de leverancer og vilkår, der er aftalt mellem parterne. Det vil i særlig grad være kunden, der har et behov for at få ændret leverancen i løbet af projektet. I større udviklingsprojekter vil kunden ofte opleve, at kundens krav til systemet ændrer sig under vejs i udviklingsforløbet i takt med, at kundens indsigt i systemet og i sine egne behov stiger. Kunden har derfor brug for en tilsikring af, at leverandøren vil ændre systemet i overensstemmelse med kundens anmodninger under vejs i projektet. En sådan ændringsanmodning rejser en række spørgsmål: hvordan fastsættes prisen for leverandørens arbejde med at gennemføre ændringen, inden for hvilken tid skal ændringen gennemføres, hvilken indvirkning har ændringen 12

13 på andre dele af systemet, og hvem skal påtage sig risikoen herfor mv. Disse spørgsmål vil aftalen normalt forholde sig til i en ændringshåndteringsbestemmelse. Kunden vil typisk også have behov for at ændre i ydelsen i længerevarende driftsaftaler. Her vil ændringen dog ofte være en kvantificerbar opeller nedjustering af den serverkapacitet, kunden har brug for, hvilket relativt enkelte kan justeres i kontrakten gennem en prisreguleringsmekanisme. Udover ændringer i realydelsen kan der også være behov for at ændre i leverandørens vederlag. I fast pris-projekter kan leverandøren selvsagt ikke beder om yderligere betaling, blot fordi udviklingen af blevet dyrere end oprindeligt forudsat af leverandøren (det ligger netop i fast pris-modellen, at dette er leverandørens risiko), men betaling for løbende ydelser vil ofte blive pristalsreguleret. Nogle typer af ydelser, som f.eks. netværksdrift, kan falde i markedspris, og da kan aftalen indeholde bestemmelser, som skal sikre kunden ikke at betale en pris over markedsprisen. Endelig kan der være behov for at ændre i tidsplanen, f.eks. fordi kundens medarbejdere blive nødt til at bruge tid på andre opgaver og derfor ikke kan deltage i møder med leverandøren mv. som oprindeligt planlagt. Aftalen indeholder derfor ofte også bestemmelser om udskydelse af tidsfrister og konsekvenserne heraf. I det følgende beskrives først med udgangspunkt i K01 og K02 bestemmelser om håndtering af ændringer i systemet (realydelsen), dernæst bestemmelser om vederlagsændringer og endelig bestemmelser om ændringer af tidsplanen Ændringer af systemet (realydelsen) De fleste nyere kontrakter om udvikling af it-systemer vil indeholde en ændringshåndteringsbestemmelse, der regulerer vilkårene for anmodning om ændring af systemet under vejs i udviklingsprojektet. Ændringshåndteringsbestemmelsen må tage stilling til, om leverandøren har pligt til at gennemføre den ønskede ændring. Dette vil sædvanligvis være tilfældet, da en ændring kan være en afgørende forudsætning for, at kunden kan få fuld nytte af systemet, og da leverandøren kan kompenseres for arbejdet med ændringen gennem en merbetaling. Parterne vil derfor normalt også uden videre kunne nå til enighed om, at leverandøren skal gennemføre ændringer på kundens anmodning. Derimod kan det være vanskeligere at blive enige om betalingen for ændringsarbejdet. På tidspunktet for ændringsanmodningen vil kundens forhandlingsposition være svag. Kunden har behov for at få gennemført ændringen og kan være tvunget til at betale den pris, leverandøren forlanger. Kunden vil der- 13

14 for ønske, at ændringshåndteringsbestemmelsen fastsætter en betalingsprocedure, der så vidt muligt sikrer kunden mod, at leverandøren frit kan fastsætte en pris for ændringsarbejdet. Det er selvsagt på kontrakttidspunktet ikke muligt at aftale en fast pris for efterfølgende ændringer, da omfanget af disse først kendes, når ændringsbehovet opstår. I stedet aftales ofte en fast timepris for udførelse af ændringsopgaver. Leverandøren skal da forud for ændringen estimere sit timeforbrug på opgaven. I nogle aftaler forsøger kunden at sikre sig mod meget høje timeestimater fra leverandørens side ved at indsætte en bestemmelse, der giver kunden mulighed for at kræve, at en uvildig tredjepart vurderer leverandørens timeestimat, hvis kunden mener, det er for højt. En ændring af systemet vil normalt indebærer en forsinkelse af projektet. Kunden vil ofte have et behov for, at denne forsinkelse ikke bliver længere end højest nødvendigt. Ændringshåndteringsbestemmelsen vil derfor typisk bestemme, at leverandøren skal fremlægge sit forslag til, hvordan ændringen skal gennemføres, inden for en bestemt tid. Herudover vil leverandøren i løsningsforslaget skulle angive tidsplanen for gennemførelsen af ændringen. Denne vil afhænge af den enkelte ændringsopgave. Leverandørens ændringsforslag bør også indeholde en beskrivelse af, om ændringen har betydning for de øvrige dele af systemet, herunder om der er krav til systemet, der ikke kan opfyldes, hvis ændringen gennemføres. I tilknytning hertil vil ændringshåndteringsbestemmelsen normalt give leverandøren ret til at afvise en ændringsanmodning, hvis det i praksis ikke er muligt at gennemføre inden for rammerne af de tekniske og funktionelle krav, systemet i øvrigt skal opfylde. Ofte vil ændringshåndteringsbestemmelsen indeholde en bagatelregel, således at leverandøren er forpligtet til at gennemføre små ændringer uden iagttagelse af ændringshåndteringsproceduren og dermed uden at kunne kræve ekstra betaling. I så fald må leverandøren indregne et beløb til disse småopgaver i den faste pris. Både K01 og K02 indeholder en ændringshåndteringsbestemmelse. I K02 følger kundens ret til at kræve ændringer af pkt. 6.4, der har følgende indhold: Kundens ændringsanmodninger skal fremsendes skriftligt til Leverandøren. Leverandøren skal uden ugrundet ophold efter modtagelsen udarbejde et estimat over det vederlag, der påregnes at være forbundet med at udarbejde et løsningsforslag for den ønskede ændring. Estimeringen skal ske på grundlag af de i Fejl! Henvisningskilde ikke fundet. anførte timepriser. Estimatet fremsendes til Kunden for dennes godkendelse. 14

15 Når Kundens godkendelse af estimatet foreligger, iværksætter Leverandøren behandlingen af ændringsanmodningen. Leverandøren skal uden ugrundet ophold og senest 20 Arbejdsdage efter, at Kunden ved Meddelelse har godkendt Leverandørens estimat, fremsende et løsningsforslag med angivelse af eventuelle konsekvenser for Leverancen, vedligeholdelse og support samt eventuel Drift, herunder leveringstid, Kundens medvirken og forøgelse eller formindskelse af Leverandørens vederlag samt estimat for timebaserede ydelser. Løsningsforslaget skal i øvrigt have et indhold som beskrevet i bilag 9. Såfremt Leverandøren i løsningsforslaget påviser, at ændringsanmodningen af væsentlige tekniske eller funktionsmæssige hensyn ikke kan gennemføres, er Leverandøren ikke forpligtet til at efterkomme ændringsanmodningen. Dette gælder dog ikke ændringer, der ved Kontraktens underskrivelse er angivet i bilag 3 som en mulig ændring, herunder i form af Optioner. Ved uoverensstemmelser mellem Parterne om konsekvenserne af en ændringsanmodning har Kunden ret til fornøden indsigt i grundlaget for Leverandørens løsningsforslag. Ved prisberegningsmodeller og lignende erhvervshemmeligheder kan Leverandøren forlange, at gennemgangen foretages af en uvildig tredjemand, som er underlagt tavshedspligt. Kunden har til enhver tid ret til at lade en uvildig tredjemand, som er underlagt tavshedspligt, gennemgå Leverandørens løsningsforslag i overensstemmelse med punkt 5.6. Såfremt Kunden kan godkende Leverandørens løsningsforslag, indarbejdes ændringen i Kontrakten i overensstemmelse med punkt Såfremt løsningsforslaget accepteres, bortfalder Leverandørens vederlag for udarbejdelsen. Såfremt løsningsforslaget ikke accepteres, kan Leverandøren kræve et rimeligt vederlag for udarbejdelsen af løsningsforslaget. Vederlaget opgøres efter dokumenteret medgået tid og til de i bilag 12 anførte timepriser samt under hensyntagen til Leverandørens estimat. Såfremt Kundens ændringsanmodning kun har ubetydelige konsekvenser for opfyldelsen af Kundens behov set i forhold til Leverancens samlede omfang og kompleksitet og kun medfører ubetydelige afledte omkostninger for Leverandøren, er Leverandøren forpligtet til at efterkomme ændringsanmodningen uden yderligere vederlag. Ændringshåndteringsbestemmelsen i K02 sikrer kunden en ret til at få gennemført ændringer under vejs i projektet på nærmere angivne vilkår, men den ændrer ikke på, at det grundlæggende er kunden, der har risikoen for, at projektet bliver dyrere som følge af ændrede behov. Hermed har kunden stadig en risiko for, at ændrede behov gør projektet så dyrt, at kunden ikke har råd til at gennemføre det, og dermed står tilbage med et halv gennem- 15

16 ført projekt, som ikke har nogen værdi for kunden. For at begrænse denne risiko, er der i K01 og K02 indført bestemmelser, der giver kunden ret til at træde ud af projektet, hvis en indledende afklaringsfase viser, at der skal ske så store ændringer af systemet i forhold til det oprindeligt forudsatte, at kunden hellere vil træde ud af projektet, end at betale merprisen for ændringerne. Kundens udtrædelsesadgang gælder kun i forbindelse med de ændringsbehov, der afdækkes i afklaringsfasen. Herefter har kunden ikke mulighed for at træde ud af projektet. Da leverandøren påføres udgifter ved afbrydelsen af projektet og heller ikke vil få den forventede indtægt, giver bestemmelsen leverandøren ret til at kræve et særskilt vederlag for kundens udtræden. Vederlaget er fastsat på forhånd, og når flere leverandører byder på en opgave, kan størrelsen af udtrædelsesvederlaget indgå som et konkurrenceparameter. Bestemmelsen om en indledende afklaringsfase og kundens mulighed for udtræden følger i K02 af pkt. 5.1: Afklaringsfase I overensstemmelse med tidsplanen (bilag 1) gennemføres en afklaringsfase, der omfatter alle dele af de ydelser, der skal leveres under Kontrakten, med særlig vægt på Leverancen. Såfremt Kunden i forbindelse med kontraktunderskrivelsen bestiller en eller flere Optioner til levering samtidig med og som en del af Leverancen, indgår disse aktiviteter i afklaringsfasen. Afklaringsfasen har til formål, at Leverandøren opnår nærmere indsigt i Kundens behov, forretningsgange og it-miljø, og at Kunden opnår nærmere indsigt i Leverandørens løsningsforslag med henblik på at foretage en yderligere konkretisering af særligt Leverancens indhold og formål. Parterne gennemgår hvert enkelt krav og løsningsforslag med henblik på at vurdere det nærmere indhold af Kundens behov, og hvorledes behovet opfyldes ved den foreslåede løsning samt forudsætninger knyttet hertil. Endvidere foretages en vurdering af, om der ved en ændring i Kravspecifikationen og/eller i Løsningsbeskrivelsen kan opnås en mere hensigtsmæssig Leverance under hensyn til Kundens behov og Leverandørens muligheder. Parterne er gensidigt forpligtet til nærmere at redegøre for indholdet af og forudsætningerne for de af Parten angivne krav/løsninger og aktivt at forholde sig til de af den anden Part angivne krav/løsninger. Dette gælder såvel i forhold til Kravspecifikation og Løsningsbeskrivelse som i forhold til øvrige dele af Leverancen. I afklaringsfasen skal hver af Parterne yde en betydelig indsats under henvisning til Leverancens kompleksitet, herunder deltage i analyser, workshops og demonstrationer m.v. Aktiviteterne i afklaringsfasen er nærmere beskrevet i bilag 1 og bilag 3. 16

17 Gennemførelse af afklaringsfasen fritager ikke Leverandøren for ansvaret for, at ydelserne under Kontrakten opfylder Leverancebeskrivelsen og Kontrakten i øvrigt, jf. punkt 3.1. På grundlag af afklaringsfasen skal Leverandøren fremkomme med forslag til ændring af Leverancebeskrivelsen, hvorved Leverancen nærmere beskrives. Herudover skal Leverandøren angive, hvorledes ændringsmulighederne i bilag 3 vil blive tilgodeset. Leverandøren skal samtidig med forslag til revideret Leverancebeskrivelse angive eventuelle konsekvenser for tidsplan, vederlag og andre vilkår. Forslag til revideret Leverancebeskrivelse og eventuelle øvrige ændringer til Kontrakten forelægges for Kunden til godkendelse i overensstemmelse med fristerne i tidsplanen, jf. bilag 1. Kunden skal inden 20 Arbejdsdage skriftligt meddele, om forslaget kan godkendes. Enhver ændring i Leverancebeskrivelsen og Kontrakten i øvrigt skal kunne dokumenteres med fuld sporbarhed, jf. punkt Forslag til revideret Leverancebeskrivelse og eventuelle øvrige ændringer til Kontrakten skal godkendes af Kunden, når det heri nærmere angives, hvorledes krav og beskrivelser i Kontrakten vil blive opfyldt, og Kunden kan acceptere eventuelle konsekvenser for tidsplan, vederlag og andre vilkår i Kontrakten. Såfremt Kunden ikke kan godkende forslaget til revideret Leverancebeskrivelse og ikke ønsker at benytte udtrædelsesadgangen, jf. punkt 0, gælder i stedet Leverancebeskrivelsen og de øvrige dele af Kontrakten uændret Kundens udtrædelsesadgang Indtil 20 Arbejdsdage efter Kundens skriftlige afvisning af Leverandørens forslag til revideret Leverancebeskrivelse, jf. punkt 0, dog senest på det i tidsplanen (bilag 1) angivne tidspunkt, har Kunden ret til at udtræde af Kontrakten som helhed. Underretning om udtræden sker ved Meddelelse. Ved sådan udtræden bortfalder begge Parters forpligtelser til videre opfyldelse af Kontrakten. Materiale, såsom rapporter, skemaer og diagrammer, samt viden, der er frembragt i afklaringsfasen frem til udtrædelsestidspunktet, kan Kunden efter betaling af vederlag for udtræden anvende til alternativ opfyldelse af Kundens behov. Retten omfatter dog ikke prototyper eller forretningshemmeligheder, der er relateret til de produkter, der skulle leveres i henhold til Kontrakten. For udtræden betaler Kunden et vederlag til Leverandøren. Vederlaget er fastsat i bilag Ændringer af vederlaget 17

18 Når et it-system skal udvikles til en fast pris, vil udviklingsaftalen normalt ikke give leverandøren adgang til at ændre prisen, hvis ikke kunden anmoder om ændringer i systemet. Det ligger som beskrevet i fast pris-modellen, at leverandøren har risikoen for, at udviklingen tager længere tid end forventet eller på anden måde kompliceres. Det kan være angivet i aftalen, at specifikke forhold er kundens ansvar, f.eks. ændringer i branchespecifik lovgivning, som indebærer behov for ændringer i systemet. I så fald vil det normalt indebærer, at kunden må fremsætte en ændringsanmodning i overensstemmelse med ændringshåndteringsproceduren. Men bortset fra disse situationer kan leverandøren ikke kræve ændringer i det faste vederlag for udviklingen af systemet. Derimod vil der sædvanligvis være en regulering af vederlaget for løbende ydelser, f.eks. vedligehold og drift af systemet. Som følge af den almindelige inflation bliver penge mindre værd over tid. Hvis ikke vederlaget for løbende ydelser skal udhules over tid, må aftalen derfor indeholde en prisreguleringsmekanisme, der sikrer, at priserne løbende reguleres. Dette sker ofte ved at lade priserne følgende udviklingen i et anerkendt indeks, f.eks. nettoprisindekset. Selvom inflationen indebærer, at priserne generelt stiger, kan det modsatte være tilfældet for nogle typer af ydelser. Prisen på teknologiprodukter som computere, tv mv. falder konstant (i en kombination af reelle prisfald og produkter med øget funktionalitet til samme pris). Det samme gælder for teleydelser. Dette betyder, at markedsprisen for f.eks. drift af it-systemer, kan være faldende. Når man som kunde indgår en langvarig driftsaftale med en leverandør, er der derfor en risiko for, at de priser, der aftales ved kontraktens indgåelse, er højere end markedsprisen senere i kontraktens løbetid. Ingen kunder ønsker at betale en højere pris end markedsprisen, og i større driftsaftaler er det derfor sædvanligt at indføre en såkaldt benchmarkingbestemmelsen. En benchmarkingbestemmelse fastsætter en procedure, hvorefter kunden kan undersøge, om aftalens priser er i overensstemmelse med markedsprisen. Det er en vanskelig øvelse, fordi driftsydelsen er kompleks og indeholder mange elementer (udover at stille lagerkapacitet til rådighed vil der f.eks. være krav til sikkerhedsforanstaltninger, back up planer, løbende rådgivning til kunden, håndtering af kundens tredjepartsaftaler og meget andet). En forudsætning for at kunne sammenligne priserne er derfor, at de driftsaftaler, der sammenlignes, indeholder de samme elementer. De aftalemæssige vilkår for driftsydelsen, herunder ansvar og sanktioner, kan også være forskellige for forskellige aftaler. Dette må også inddrages ved en prissammenligning. 18

19 Overvinder kunden disse udfordringer og formår at foretage en benchmarkingundersøgelse, der på baggrund af de kriterier, som benchmarkingbestemmelsen stiller op, viser, at leverandørens priser ligger over markedsprisen, skal bestemmelsen forholde sig til konsekvenserne heraf. En mulighed er, at kunden kan kræve en reduktion af priserne til markedsprisen. Dette kan være problematisk for leverandøren, hvis de høje priser er udtryk for, at leverandøren har for højt et omkostningsniveau. I så fald vil en prisreduktion kunne indebære, at leverandøren bliver tvunget til at levere ydelserne med tab. Leverandøren vil derfor ofte foretrække, at kunden får ret til at opsige driftsaftalen før tid, hvis leverandørens priser er for høje. Benchmarkingbestemmelser bruges primært i driftsaftaler, og hverken K01 eller K02, der omhandler udvikling af it-systemer, indeholder benchmarkingbestemmelser. I driftsaftaler anvendes af og til som supplement til benchmarkingsbestemmelsen en såkaldt most favoured customer-bestemmelse. Efter denne type bestemmelse skal kunden til stadighed have de laveste priser, som leverandøren tilbyder nogle af sine kunder. Hvis leverandøren på et tidspunkt giver en ny kunde en lavere pris, har den eksisterende kunde krav på at få sin pris reduceret til samme niveau. Det er normalt kun store kunder, der har held til at få indført denne type bestemmelser, der, på samme måde som benchmarkingbestemmelser, vil forudsætte, at der er tale om sammenlignelige ydelser i relation til ydelsens karakter, volumen, aftalevilkår mv Ændringer i leveringstiden I udviklingsprojekter aftaler parterne i forbindelse med kontraktens indgåelse en tidsplan for udviklingen fra projektets start og frem til kundens endelige overtagelse af systemet. Det gælder dog ikke altid for de iterative udviklingsprojekter, jf. om disse ovenfor i afsnit 2.1. Det er normalt vigtigt for kunden, at tidsplanen overholdes, så det nye system kan tages i brug som planlagt. Det nye system kan f.eks. medfører besparelser i driften, som er indregnet fra det planlagte overtagelsestidspunkt, eller aftalen med kundens hidtidige leverandør er opsagt med virkning fra dette tidspunkt, hvorfor en forlængelse vil påføre kunden ekstra omkostninger. Af samme grund er det ikke sædvanligt, at leverandøren har ret til at kræve udskydelse af tidsplanen. Derimod er det sædvanligt, at kunden kan kræve udskydelse af tidsplanens forskellige tidsfrister. Selvom systemet skal udvikles af leverandøren, 19

20 forudsætter det en aktiv deltagelse fra kunden i forbindelse med de løbende drøftelser om systemets udformning, afprøvning af systemet, uddannelse af medarbejdere mv. Navnlig i de tilfælde hvor kunden ikke er parat til at levere sin indsats, f.eks. fordi nøglemedarbejdere forlader deres stilling eller må tage sig af andet mere presserende arbejde, vil kunden ønske at kunne udskyde tidsplanen. Dette vil kræve en særlig hjemmel i aftalen, og udviklingsaftaler indeholder ofte en sådan bestemmelse, der giver kunden ret til at anmode om udskydelse af tidsplanen under nærmere angivne vilkår. Kundens udskydelse af tidsplanen vil gøre det vanskeligere for leverandøren at planlægge sit arbejde, da de medarbejdere, leverandøren har allokeret til projektet, skal videre til andre projekter. Leverandøren kan derfor få et ressourceproblem i andre projekter, hvis udviklingsprojektet bliver udskudt i for lang tid. Bestemmelsen om udskydelsesret fastslår derfor normalt, at kunden kun kan udskyde tidsfristerne et vist antal gange og maksimalt med et bestemt samlet antal dage. Hvis kunden eksempelvis ønsker at udskyde en afprøvning af systemet med 20 dage, er det ikke sikkert, at leverandøren vil kunne gennemføre afprøvningen præcis 20 dage senere. Det kan være, at de personer hos leverandøren, der skal stå for afprøvningen, har ferie på dette tidspunkt, eller er forpligtet af andre projekter. Udskydelsesbestemmelsen vil derfor typisk give leverandøren ret til en yderligere udskydelse, når kunden vælger at udskyde, så leverandøren har mulighed for at indrette sig på den nye tidsplan. Endelig skal udskydelsesbestemmelsen forholde sig til de økonomiske konsekvenser af udskydelsen. Ved en udskydelse af tidsplanen, vil betalingsfristerne typisk blive udskudt tilsvarende, da betalingsfristerne er knyttet til bestemte hændelser i tidsplanen. En stor del af betalingen er f.eks. normalt knyttet til en godkendt overtagelsesprøve af systemet. Udskydes datoen for overtagelsesprøven udskydes tilsvarende den del af betalingen, der er knyttet hertil. Til gengæld giver bestemmelsen ofte leverandøren ret til at kræve renter af de udskudte betalinger samt dækning af omkostninger forbundet med udskydelsen. K01 indeholder i pkt. 7.2 et eksempel på en sædvanlig udskydelsesbestemmelse: Med et skriftligt varsel til leverandøren på mindst 20 arbejdsdage har kunden ret til 3 gange efter drøftelse med leverandøren at udskyde enhver i tidsplanen fastsat tidsfrist, dog således at kundens samlede udskydelser af tidsplanen højest kan udgøre 60 arbejdsdage. 20

Bilag 11 Ændringshåndtering

Bilag 11 Ændringshåndtering Bilag 11 Ændringshåndtering Version 1.0 04-07-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 3 TYPER AF ÆNDRINGER... 3 4 GENERELT... 3 5 ATP S FREMSÆTTELSE AF ÆNDRINGSANMODNINGER...

Læs mere

BILAG 6 ÆNDRINGSHÅNDTERING

BILAG 6 ÆNDRINGSHÅNDTERING BILAG 6 ÆNDRINGSHÅNDTERING INDHOLDSFORTEGNELSE 1. Indledning... 4 2. Ændringer... 4 2.1 Kundens ændringsanmodning... 4 2.2 Leverandørens ændringsanmodning... 4 2.3 Mindsteindhold for et løsningsforslag...

Læs mere

BILAG 8 ÆNDRINGSHÅNDTERING SAMT EVENTUEL VIDEREUDVIKLING

BILAG 8 ÆNDRINGSHÅNDTERING SAMT EVENTUEL VIDEREUDVIKLING BILAG 8 ÆNDRINGSHÅNDTERING SAMT EVENTUEL VIDEREUDVIKLING INDHOLDSFORTEGNELSE 1. Indledning... 4 2. Ændringshåndtering... 4 3. Kundens Ændringsanmodning... 4 4. Leverandørens Ændringsanmodning... 4 5. Mindsteindhold

Læs mere

OPTION TIL RM OG RN BILAG 8 TIL KONTRAKT OM EPJ/PAS ÆNDRINGSHÅNDTERING

OPTION TIL RM OG RN BILAG 8 TIL KONTRAKT OM EPJ/PAS ÆNDRINGSHÅNDTERING OPTION TIL RM OG RN BILAG 8 TIL KONTRAKT OM EPJ/PAS ÆNDRINGSHÅNDTERING INSTRUKTION TIL LEVERANDØREN VED UDNYTTELSE AF OPTION: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved

Læs mere

ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT

ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT Executive summary 1. ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT Regeringen har et mål om, at den offentlige sektor skal være blandt de mest effektive og mindst bureaukratiske i verden, og for at

Læs mere

Tredjemandsprogrammel i K03. Alice Grünfeld, chefjurist

Tredjemandsprogrammel i K03. Alice Grünfeld, chefjurist Tredjemandsprogrammel i K03 Alice Grünfeld, chefjurist 1 BEC BEC er ejet af en række banker og har derudover en række finansvirksomheder som kunder samt udbyder af flere brancheløsninger Omsætning ca.

Læs mere

Bestemmelser der indarbejdes i Samarbejdsbilaget samt i Kontrakten

Bestemmelser der indarbejdes i Samarbejdsbilaget samt i Kontrakten Bestemmelser der indarbejdes i Samarbejdsbilaget samt i Kontrakten Punkt 1 med underpunkter indarbejdes i samarbejdsbilaget, mens punkt 2 indarbejdes i bilag 1 (tidsplanen) og 3 samt 4 med underpunkter

Læs mere

K02 STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT. Kontrakt. levering, [drift] og vedligeholdelse af et it-system til [ ] mellem

K02 STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT. Kontrakt. levering, [drift] og vedligeholdelse af et it-system til [ ] mellem J.nr. 46-0360 SOF/MLB/mar/mw Udkast af 7. september 2007 K02 STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT Kontrakt om levering, [drift] og vedligeholdelse af et it-system til [ ] mellem (i det følgende

Læs mere

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet. Bilag 12 - Ændringshåndtering

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet. Bilag 12 - Ændringshåndtering 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

Læs mere

Overvejelser om genudbud af it-løsninger - Jura brugt strategisk i it-kontrakter

Overvejelser om genudbud af it-løsninger - Jura brugt strategisk i it-kontrakter NOTAT Overvejelser om genudbud af it-løsninger - Jura brugt strategisk i it-kontrakter 1. Indledning Hver gang, en kommune foretager et it-udbud bør man allerede i planlægningen af udbuddet tænke frem

Læs mere

. Bestemmelser der indarbejdes i Samarbejdsbilaget samt i Kontrakten

. Bestemmelser der indarbejdes i Samarbejdsbilaget samt i Kontrakten . spe. Bestemmelser der indarbejdes i Samarbejdsbilaget samt i Kontrakten Nedenstående er opdelt i to afsnit. Første afsnit indeholder bestemmelser, der forventes indarbejdet i Samarbejdsbilaget. Andet

Læs mere

Bilag 15 Leverandørkoordinering

Bilag 15 Leverandørkoordinering Bilag 15 Leverandørkoordinering Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 3 LEVERANDØRENS ANSVAR... 4 4 LEVERANDØRENS KOORDINERINGS- OG SAMARBEJDSFORPLIGTELSE...

Læs mere

IT-KONTRAKTER HVORDAN HÅNDTERES BEHOVET FOR FLEKSIBILITET I PRAKSIS?

IT-KONTRAKTER HVORDAN HÅNDTERES BEHOVET FOR FLEKSIBILITET I PRAKSIS? IT-KONTRAKTER HVORDAN HÅNDTERES BEHOVET FOR FLEKSIBILITET I PRAKSIS? Mads Nygaard Madsen, advokat og partner, certificeret IT-advokat, certificeret juridisk ekspert i IT-tvister 22. september 2015 DISPOSITION

Læs mere

Kontrakt om Drift, Videreudvikling, Support af tilskuds- og kontroladministrative

Kontrakt om Drift, Videreudvikling, Support af tilskuds- og kontroladministrative 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:

Læs mere

BILAG 10. Modelbilag til driftsaftale Om IT infrastruktur services (IT drift)

BILAG 10. Modelbilag til driftsaftale Om IT infrastruktur services (IT drift) BILAG 10 Modelbilag til driftsaftale 2017 Om IT infrastruktur services (IT drift) Side 2 1 VEJLEDNING 1.1 Dette afsnit er blot en vejledning til udfyldelse af bilaget og skal slettes inden Kontrakten underskrives.

Læs mere

BILAG 9 KUNDENS BETALINGER

BILAG 9 KUNDENS BETALINGER BILAG 9 KUNDENS BETALINGER INDHOLDSFORTEGNELSE 1. Generelt om vederlag... 5 2. Prismodeller... 5 3. Anvendte prismodeller for Leverancer og Ydelser omfattet af Kontrakten... 6 4. Leverancevederlag... 6

Læs mere

Dagsprogram for IT Contract Manager Grundmodul Torsdag den 2. februar 2012

Dagsprogram for IT Contract Manager Grundmodul Torsdag den 2. februar 2012 Dagsprogram for IT Contract Manager Grundmodul Torsdag den 2. februar 2012 Modul 1 dag 1 Hovedpunkter Tidspunkt Indregistrering Kaffe og morgenbrød kl. 9 30 10 00 Velkomst Præsentation af kursusforløbet

Læs mere

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Bilag 8 Test 12.05.2016 Version 1.0 [Vejledning til tilbudsgiver: Bilaget er i sin helhed at betragte som et mindstekrav (MK).

Læs mere

BILAG 15 TIL KONTRAKT OM EPJ/PAS PROAKTIVE HANDLINGER

BILAG 15 TIL KONTRAKT OM EPJ/PAS PROAKTIVE HANDLINGER BILAG 15 TIL KONTRAKT OM EPJ/PAS PROAKTIVE HANDLINGER INSTRUKTION TIL BESVARELSE AF BILAGET: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse. Formål med bilag:

Læs mere

Leveranceaftale. Miniudbud iht. rammeaftale 02.18 om Borgerskab og Service. Juli 2008

Leveranceaftale. Miniudbud iht. rammeaftale 02.18 om Borgerskab og Service. Juli 2008 Leveranceaftale Miniudbud iht. rammeaftale 02.18 om Borgerskab og Service Juli 2008 Dato: 16-07-2008 Kontor: Sagsbeh.: Digitaliseringsafdelingen Niels Kleberg Versionsnr.: 1.0 Leveranceaftale for miniudbud

Læs mere

Bilag 10 - Programmel og licensbetingelse

Bilag 10 - Programmel og licensbetingelse Bilag 10 - Programmel og licensbetingelse Bilag 10 - Programmel og licensbetingelser KOMBIT A/S, Halfdansgade 8, 2300 København S, CVR-nr. 19 43 50 75 Side 2 af 11 INSTRUKTION TIL TILBUDSGIVER Bilaget

Læs mere

BILAG 13 VEDERLAG OG BETALING

BILAG 13 VEDERLAG OG BETALING BILAG 13 VEDERLAG OG BETALING (Bilaget ligger på http://silkeborgkommune.dk/erhverv/udbud/varer-og-tjenesteydelser i pdfformat og word-format.) Skemaet i pkt. 5 samt Underbilag 13.1 udfyldes af Tilbudsgiver.

Læs mere

Bilag 13. Ophørsbistand. Til Kontrakt. Den Nationale Henvisningsformidling

Bilag 13. Ophørsbistand. Til Kontrakt. Den Nationale Henvisningsformidling Bilag 13 Ophørsbistand Til Kontrakt OM Den Nationale Henvisningsformidling Bilag 13 Ophørsbistand Side 1/7 INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive

Læs mere

Bilag 9. Ændringshåndtering. Udbud af Medical Device Information Collection

Bilag 9. Ændringshåndtering. Udbud af Medical Device Information Collection Bilag 9 Ændringshåndtering Udbud af INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse. Formål med Bilag: Formålet med dette Bilag

Læs mere

Dagsprogram for IT Contract Manager It-kontrakten A-Z Del I Torsdag den 19. marts 2015

Dagsprogram for IT Contract Manager It-kontrakten A-Z Del I Torsdag den 19. marts 2015 Dagsprogram for IT Contract Manager It-kontrakten A-Z Del I Torsdag den 19. marts 2015 Modul 1 dag 1 Hovedpunkter Tidspunkt Indregistrering Kaffe og morgenbrød kl. 9 30 10 00 Velkomst Præsentation af kursusforløbet

Læs mere

BILAG 13 TIL KONTRAKT OM EOJ-SYSTEM RISIKORAPPORTERING SAMT PROAKTIVE HANDLINGER

BILAG 13 TIL KONTRAKT OM EOJ-SYSTEM RISIKORAPPORTERING SAMT PROAKTIVE HANDLINGER BILAG 13 TIL KONTRAKT OM EOJ-SYSTEM RISIKORAPPORTERING SAMT PROAKTIVE HANDLINGER 1 INSTRUKTION TIL BESVARELSE AF BILAGET: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved indgåelse

Læs mere

Samhandelsbetingelser InfraHouse P/S Vers. 1.2 8. Januar 2014

Samhandelsbetingelser InfraHouse P/S Vers. 1.2 8. Januar 2014 Samhandelsbetingelser InfraHouse P/S Vers. 1.2 8. Januar 2014 Indholdsfortegnelse 1. Aftaleindgåelse... 3 2. Ydelsernes omfang... 3 3. Parternes forpligtelser... 4 4. Pris og betalingsbetingelser... 5

Læs mere

BILAG 13 TIL KONTRAKT OM EPJ/PAS LICENSBETINGELSER

BILAG 13 TIL KONTRAKT OM EPJ/PAS LICENSBETINGELSER BILAG 13 TIL KONTRAKT OM EPJ/PAS LICENSBETINGELSER INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse. Formål med bilag: Formålet

Læs mere

Udbud af foranalyse, levering, vedligeholdelse og videreudvikling af en løsning til identitets- og rettighedsstyring

Udbud af foranalyse, levering, vedligeholdelse og videreudvikling af en løsning til identitets- og rettighedsstyring Spørgsmål og svar II Udbud af foranalyse, levering, vedligeholdelse og videreudvikling af en løsning til identitets- og rettighedsstyring Aalborg Universitet Spørgsmål 1 Henvisning: Bilag 3 kravspecifikation

Læs mere

Kontrakt. Ejendomsadministration. Ringsted Kommune

Kontrakt. Ejendomsadministration. Ringsted Kommune Kontrakt Ejendomsadministration Ringsted Kommune Indholdsfortegnelse 1. Aftaleparter 3 2. Bilag 3 3. Baggrund, formål og generelle vilkår 3 4. Ejendomme 4 5. Kontraktperiode 4 6. Forhold vedrørende ikrafttræden

Læs mere

Bilag 19 Projektvilkår

Bilag 19 Projektvilkår Bilag 19 Projektvilkår Version 1.0 23-02-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDHOLD... 4 3 PROJEKTAFTALER... 5 3.10 LEVERANDØRENS ADMINISTRATION AF PROJEKTER... 6 4 LEVERINGSFORPLIGTELSER...

Læs mere

EU-udbud af WAN infrastruktur. Bilag 10 - Ændringshåndtering

EU-udbud af WAN infrastruktur. Bilag 10 - Ændringshåndtering EU-udbud af WAN infrastruktur Bilag 10 - Ændringshåndtering INDHOLD 1. FORMÅL... 3 2. GENERELT OM EGENTLIGE ÆNDRINGER... 3 3. KUNDENS ÆNDRINGSANMODNING... 3 4. LEVERANDØRENS ÆNDRINGSANMODNING... 4 5. MINDSTEINDHOLD

Læs mere

Forretningsbetingelser

Forretningsbetingelser Forretningsbetingelser 1.0 Anvendelsesområde 1.1 Disse generelle aftalevilkår finder anvendelse på enhver aftale mellem SiteLoom ApS og en kunde om levering af konsulentydelser, abonnementsydelser og andre

Læs mere

GENERELLE BETINGELSER FOR SUPPORT OG PROGRAMMELOPDATERING

GENERELLE BETINGELSER FOR SUPPORT OG PROGRAMMELOPDATERING GENERELLE BETINGELSER FOR SUPPORT OG PROGRAMMELOPDATERING DEL I: INDLEDNING Aftalegrundlag I disse betingelser er beskrevet rammerne for, hvordan DFF-EDB leverer support og programmelopdatering til sine

Læs mere

Vejledning til. Kontrakt om udførelse af freelancearbejde, hvor du er selvstændig erhvervsdrivende. Side 1 af 6

Vejledning til. Kontrakt om udførelse af freelancearbejde, hvor du er selvstændig erhvervsdrivende. Side 1 af 6 Vejledning til Kontrakt om udførelse af freelancearbejde, hvor du er selvstændig erhvervsdrivende Side 1 af 6 Indledende bemærkninger: Hvis du har selvstændig virksomhed og er momsregistret, skal du anføre

Læs mere

Bilag 9 udgør et mindstekrav og skal således ikke udfyldes af tilbudsgiver. Tilbudsgiver skal i Bilag 9, Appendiks 9 (regneark) angive følgende:

Bilag 9 udgør et mindstekrav og skal således ikke udfyldes af tilbudsgiver. Tilbudsgiver skal i Bilag 9, Appendiks 9 (regneark) angive følgende: Bilag 9 Vederlag Vejledning til tilbudsgiver. Bilag 9 består af selve Bilag 9, der indeholder en regulering af vederlagsbetingelser for ydelser i henhold til Rammekontrakten, samt Appendiks A, der indeholder

Læs mere

Udkast til Kontrakt. levering, drift og vedligeholdelse af et elektronisk rekrutteringssystem i Region Syddanmark. mellem

Udkast til Kontrakt. levering, drift og vedligeholdelse af et elektronisk rekrutteringssystem i Region Syddanmark. mellem Udkast til Kontrakt om levering, drift og vedligeholdelse af et elektronisk rekrutteringssystem i Region Syddanmark mellem Region Syddanmark Damhaven 12 7100 Vejle (i det følgende kaldet Kunden) og (i

Læs mere

Bilag 17 - Benchmarking

Bilag 17 - Benchmarking Bilag 17 - Benchmarking Version 0.9 05-05-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 BILAGETS INDHOLD... 4 3 DEFINITIONER... 4 4 BENCHMARKINGENS OMFANG... 4 5 PRISERNES KONKURRENCEDYGTIGHED... 4

Læs mere

K01 STANDARDKONTRAKT FOR KORTVARIGT IT-PROJEKT

K01 STANDARDKONTRAKT FOR KORTVARIGT IT-PROJEKT K01 STANDARDKONTRAKT FOR KORTVARIGT IT-PROJEKT K O N T R A K T mellem CVR-nr.... (i det følgende kaldet kunden) og CVR-nr.... (i det følgende kaldet leverandøren) om levering og vedligeholdelse af et it-system

Læs mere

Dagsprogram for IT Contract Manager Grundlæggende it-kontraktret Torsdag den 2. marts 2017

Dagsprogram for IT Contract Manager Grundlæggende it-kontraktret Torsdag den 2. marts 2017 Grundlæggende it-kontraktret Torsdag den 2. marts 2017 Modul 1 dag 1 Hovedpunkter Tidspunkt Indregistrering Kaffe og morgenbrød kl. 9 30 10 00 Velkomst Præsentation af kursusforløbet Præsentation af ITCM-website

Læs mere

Bilag 7: Aftale om drift

Bilag 7: Aftale om drift Bilag 7: Aftale om drift Udbud af E-rekrutteringssystem Aftale om drift mellem REGION SYDDANMARK (i det følgende kaldet Kunden ) og Bilag 7 Aftale om drift 3 7.1 Indledning

Læs mere

Kontraktbilag 8 Prøver

Kontraktbilag 8 Prøver Kontraktbilag 8 Prøver [Vejledning til Leverandør i forbindelse med afgivelse af tilbud Dette kontraktbilag indeholder VHK s krav til Leverandørens prøver. Leverandøren skal ikke udfylde kontraktbilaget.

Læs mere

Standardkontrakt for kortvarigt it-projekt

Standardkontrakt for kortvarigt it-projekt Standardkontrakt for kortvarigt it-projekt K O N T R A K T mellem Kunde navn Person, stilling hjemmeside / profil mail / telefon CVR-nr.... (i det følgende kaldet kunden) og BennekouDesign Anders C. Bennekou

Læs mere

BILAG 7 PRØVER. Udvikling af en hjemmeside til borgerforslag samt hosting og vedligeholdelse

BILAG 7 PRØVER. Udvikling af en hjemmeside til borgerforslag samt hosting og vedligeholdelse BILAG 7 PRØVER Vejledning: I dette bilag fastsættes kundens krav til afprøvning af leverancen og af evt. indfriede optioner. Leverandøren udarbejder på baggrund af kundens krav en overordnet plan for prøverne.

Læs mere

Leveringsaftale. mellem. NaturErhvervstyrelsen. Nyropsgade København V. (herefter benævnt Kunden) [navn] [adresse] [cvr-nr]

Leveringsaftale. mellem. NaturErhvervstyrelsen. Nyropsgade København V. (herefter benævnt Kunden) [navn] [adresse] [cvr-nr] Leveringsaftale mellem NaturErhvervstyrelsen Nyropsgade 30 1780 København V (herefter benævnt Kunden) og [navn] [adresse] [cvr-nr] (herefter benævnt Leverandøren) [dato] Bistand til planlægning af jordfordeling

Læs mere

BASERET PÅ - K01 K O N T R A K T. mellem. CVR-nr... (i det følgende kaldet kunden) CVR-nr... (i det følgende kaldet leverandøren)

BASERET PÅ - K01 K O N T R A K T. mellem. CVR-nr... (i det følgende kaldet kunden) CVR-nr... (i det følgende kaldet leverandøren) BASERET PÅ - K01 MED PROFESSIONSHØJSKOLEN UCC S TILPASNINGER OG ÆNDRINGER K O N T R A K T mellem CVR-nr.... (i det følgende kaldet kunden) og CVR-nr.... (i det følgende kaldet leverandøren) om anskaffelse

Læs mere

Bilag 14 Ændringshåndtering

Bilag 14 Ændringshåndtering Bilag 14 Ændringshåndtering 1 [INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved indgåelse heraf. Formål med bilag: Formålet med Bilag 14 er at

Læs mere

Dias 1. Ændringsrisikoen

Dias 1. Ændringsrisikoen Dias 1 Ændringsrisikoen Problemstillingen og begreb To grundlæggende udfordringer ved it-udvikling Vanskelighederne ved at specificere systemet Vanskelighederne ved at afdække brugerbehovene => Kundebehov

Læs mere

Domstolsstyrelsen. Genudbud af e-tl. Spørgsmål / Svar i forbindelse med tilbudsfasen

Domstolsstyrelsen. Genudbud af e-tl. Spørgsmål / Svar i forbindelse med tilbudsfasen Pulje 3, 3. juli 2014. 1 Jf. afsnit 3.4 i udbudsbetingelserne Ordregiver vil udarbejde et kort referat fra orienteringsmødet, som alle tilbudsgiver efterfølgende vil få adgang til. Spørgsmål: Er dette

Læs mere

Indholdsfortegnelse Afprøvning af Leverancen Fællesregler for afprøvning Fejl! Bogmærke er ikke defineret. Installationsprøve Delleveranceprøve

Indholdsfortegnelse Afprøvning af Leverancen Fællesregler for afprøvning Fejl! Bogmærke er ikke defineret. Installationsprøve Delleveranceprøve Bilag 11 Prøver Indholdsfortegnelse 1. Afprøvning af Leverancen 3 2. Fællesregler for afprøvning 3 2.1 Prøvens gennemførelse 3 2.2 Prøveplan 3 2.3 Rapportering 4 2.4 Godkendelse af en prøve 4 2.5 Leverandørens

Læs mere

Handelsbetingelser. Virksomhedsoplysninger. Grumsen Development ApS CVR: Willemoesgade Tv 6700 Esbjerg Danmark

Handelsbetingelser. Virksomhedsoplysninger. Grumsen Development ApS CVR: Willemoesgade Tv 6700 Esbjerg Danmark Handelsbetingelser Virksomhedsoplysninger Grumsen Development ApS CVR: 37051373 Willemoesgade 50 2. Tv 6700 Esbjerg Danmark 1. Generelle betingelser 1.1. Disse handelsbetingelser gælder for alle leverancer

Læs mere

Kontrakt. Januar. Elektronisk journalsystem til den kommunale tandpleje i Syddjurs og Norddjurs Kommune. Side 1 af 26

Kontrakt. Januar. Elektronisk journalsystem til den kommunale tandpleje i Syddjurs og Norddjurs Kommune. Side 1 af 26 Kontrakt Elektronisk journalsystem til den kommunale tandpleje i Syddjurs og Norddjurs Kommune Januar Side 1 af 26 Kontrakt mellem Syddjurs Kommune Hovedgaden 77 8410 Rønde CVR-nr.: 29189978 Norddjurs

Læs mere

BILAG 0 TIL KONTRAKT OM EOJ-SYSTEM DEFINITIONER

BILAG 0 TIL KONTRAKT OM EOJ-SYSTEM DEFINITIONER BILAG 0 TIL KONTRAKT OM EOJ-SYSTEM DEFINITIONER 1 INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved indgåelse heraf. Formål med bilag: Formålet

Læs mere

Kontrakt K02 MODIFICERET STANDARDKONTRAKT FOR LÆNGEREVARENDE IT- PROJEKT

Kontrakt K02 MODIFICERET STANDARDKONTRAKT FOR LÆNGEREVARENDE IT- PROJEKT K02 MODIFICERET STANDARDKONTRAKT FOR LÆNGEREVARENDE IT- PROJEKT Kontrakt om foranalyse, levering, vedligeholdelse og videreudvikling af en løsning til identitets- og rettighedsstyring til Aalborg Universitet

Læs mere

KONTRAKT OM UDVIKLING, DRIFT OG VEDLIGEHOLDELSE AF HJEMMESIDE MELLEM VISITDENMARK [LEVERANDØRENS NAVN]

KONTRAKT OM UDVIKLING, DRIFT OG VEDLIGEHOLDELSE AF HJEMMESIDE MELLEM VISITDENMARK [LEVERANDØRENS NAVN] KONTRAKT OM UDVIKLING, DRIFT OG VEDLIGEHOLDELSE AF HJEMMESIDE MELLEM VISITDENMARK OG [LEVERANDØRENS NAVN] INDHOLDSFORTEGNELSE 1. Baggrund, Formål og kontraktpart... 6 1.1 Baggrund... 6 1.2 Formål... 6

Læs mere

BILAG 10 VEDLIGEHOLDELSESORDNING

BILAG 10 VEDLIGEHOLDELSESORDNING BILAG 10 VEDLIGEHOLDELSESORDNING (Bilaget ligger på http://silkeborgkommune.dk/erhverv/udbud/varer-og-tjenesteydelser i pdfformat og word-format.) Skemaer med hvide felter udfyldes af. Besvarelsen af bilaget

Læs mere

Bilag 14 Accelereret konfliktløsning og Mediation

Bilag 14 Accelereret konfliktløsning og Mediation Bilag 14 Accelereret konfliktløsning og Mediation Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 3 ACCELERERET KONFLIKTLØSNING MED BRUG AF SAGKYNDIG UDTALELSE... 4

Læs mere

BILAG 13 TIL KONTRAKT OM EPJ/PAS LICENSBETINGELSER

BILAG 13 TIL KONTRAKT OM EPJ/PAS LICENSBETINGELSER BILAG 13 TIL KONTRAKT OM EPJ/PAS LICENSBETINGELSER INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse. Formål med bilag: Formålet

Læs mere

Kontrakt K03 STANDARDKONTRAKT FOR LÆNGEREVA- RENDE IT-PROJEKT BASERET PÅ EN AGIL METODE. udvikling og levering af en it-leverance til [ ] mellem

Kontrakt K03 STANDARDKONTRAKT FOR LÆNGEREVA- RENDE IT-PROJEKT BASERET PÅ EN AGIL METODE. udvikling og levering af en it-leverance til [ ] mellem J.nr.: 460694 HOL/MTG/mw K03 STANDARDKONTRAKT FOR LÆNGEREVA- RENDE IT-PROJEKT BASERET PÅ EN AGIL METODE Kontrakt om udvikling og levering af en it-leverance til [ ] mellem [ ] (i det følgende kaldet Kunden)

Læs mere

Levering af velfærdsteknologi til arbejde med reminiscens

Levering af velfærdsteknologi til arbejde med reminiscens Kontrakt Levering af velfærdsteknologi til arbejde med reminiscens SOSU Nord mellem SOSU Nord På Sporet 8 A 9000 Aalborg (Herefter SOSU ) og ( ) (Herefter Leverandør ) Hver for sig benævnt Part og tilsammen

Læs mere

BILAG 6 TEST OG PRØVER

BILAG 6 TEST OG PRØVER BILAG 6 TEST OG PRØVER Vers. 2.0 3.09.2013 (Bilaget ligger på http://silkeborgkommune.dk/erhverv/udbud/varer-og-tjenesteydelser i pdfformat og word-format.) Skal ikke udfyldes af Tilbudsgiver. Bilaget

Læs mere

Udbud af foranalyse, levering, vedligeholdelse og videreudvikling af en løsning til identitets- og rettighedsstyring

Udbud af foranalyse, levering, vedligeholdelse og videreudvikling af en løsning til identitets- og rettighedsstyring Spørgsmål og svar II Udbud af foranalyse, levering, vedligeholdelse og videreudvikling af en løsning til identitets- og rettighedsstyring Aalborg Universitet Spørgsmål 1 Henvisning: Bilag 3 kravspecifikation

Læs mere

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

KO2 med kommentarer. Nicolai Dragsted Ole Horsfeldt Jesper Langemark Claus Sørensen KO2 med kommentarer KO2 med kommentarer Nicolai Dragsted Ole Horsfeldt Jesper Langemark Claus Sørensen Nicolai Dragsted, Ole Horsfeldt, Jesper Langemark og Claus Sørensen KO2 med kommentarer 1. udgave/1.

Læs mere

UDKAST K03 KONTRAKT. 7. november 2012 STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT BASERET PÅ EN AGIL METODE

UDKAST K03 KONTRAKT. 7. november 2012 STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT BASERET PÅ EN AGIL METODE 7. november 2012 UDKAST K03 STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT BASERET PÅ EN AGIL METODE KONTRAKT om udvikling og levering af en it-leverance til [ ] mellem [.] (i det følgende kaldet Kunden)

Læs mere

Bilag [nr.] Trepartsaftale

Bilag [nr.] Trepartsaftale J.nr.: 7501417 MPE/KRM Bilag [nr.] Trepartsaftale Kammeradvokaten Telefon +45 33 15 20 10 Vester Farimagsgade 23 Fax +45 33 15 61 15 DK-1606 København V www.kammeradvokaten.dk Trepartsaftale INDHOLDSFORTEGNELSE

Læs mere

Standardaftale til kommercialiseringspartnerskab

Standardaftale til kommercialiseringspartnerskab Standardaftale til kommercialiseringspartnerskab Mellem [Navn, adresse, telefonnummer, cpr/cvr. nr.] Herefter Part A og [Navn, adresse, telefonnummer, cpr/cvr. nr.] Herefter Part B indgås dags dato følgende

Læs mere

STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT BASERET PÅ EN AGIL METODE

STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT BASERET PÅ EN AGIL METODE K03 STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT BASERET PÅ EN AGIL METODE Kontrakt om udvikling og levering af en it-leverance til [ ] mellem [ ] (i det følgende kaldet Kunden) og [ ] (i det følgende

Læs mere

TILBUD TIL XXX KONSULENTAFTALE

TILBUD TIL XXX KONSULENTAFTALE INDLEVELSE SKABER UDVIKLING TILBUD TIL XXX KONSULENTAFTALE WWW.BDO.DK KONSULENTAFTALE VEDR. PROJEKT: Gennemgang af forudsætninger og beregninger til skolestrukturrapportens bilag I Vurdering af økonomisk

Læs mere

Bilag 2. Salgs- og Leveringsbetingelser

Bilag 2. Salgs- og Leveringsbetingelser Bilag 2 Salgs- og Leveringsbetingelser Indholdsfortegnelse 1 SALGS- OG LEVERINGSBETINGELSER... 3 1.1 Anvendelse og gyldighed... 3 1.2 Tilbud/ordre... 3 1.3 Priser... 3 1.4 Ejendomsforbehold... 3 1.5 Levering...

Læs mere

AFTALE [indsæt udkastdato] [Adresse] [Postnummer, by] [Cvr.nr.] ( Projektejer )

AFTALE [indsæt udkastdato] [Adresse] [Postnummer, by] [Cvr.nr.] ( Projektejer ) AFTALE [indsæt udkastdato] Mellem [Navn] [Adresse] [Postnummer, by] [Cvr.nr.] ( Projektejer ) og [HOFOR Spildevand København A/S] Ørestads Boulevard 35 2300 København S [Cvr.nr. 26043182] ( HOFOR ) Om

Læs mere

KOMBIT har på vegne af kommunerne gennemført en række komplekse it-indkøb til kommunerne.

KOMBIT har på vegne af kommunerne gennemført en række komplekse it-indkøb til kommunerne. Finansudvalget 2016-17 FIU Alm.del endeligt svar på spørgsmål 218 Offentligt Besvarelse af samrådsspørgsmål P, Q og R 25. januar 2017 Samrådsspørgsmål P Spørgsmål: Hvad er konsekvensen af, at kommunerne

Læs mere

Kontrakt. mellem. Amgros I/S Dampfærgevej 22 København Ø (i det følgende benævnt Amgros) (i det følgende benævnt Pengeinstituttet) 26.

Kontrakt. mellem. Amgros I/S Dampfærgevej 22 København Ø (i det følgende benævnt Amgros) (i det følgende benævnt Pengeinstituttet) 26. J.nr.: 8915980 VFN/KRM Kontrakt om mellem Amgros I/S Dampfærgevej 22 København Ø (i det følgende benævnt Amgros) og [ ] (i det følgende benævnt Pengeinstituttet) Vester Farimagsgade 23 DK-1606 København

Læs mere

Vejledning VEDRØRENDE GENERELLE BETINGELSER FOR ANVENDELSE AF NEMHANDEL. Februar 2015 (VERSION 1.4 AF FEBRUAR 2015)

Vejledning VEDRØRENDE GENERELLE BETINGELSER FOR ANVENDELSE AF NEMHANDEL. Februar 2015 (VERSION 1.4 AF FEBRUAR 2015) Vejledning Februar 2015 VEDRØRENDE GENERELLE BETINGELSER FOR ANVENDELSE AF NEMHANDEL (VERSION 1.4 AF FEBRUAR 2015) Side 2 af 12 Indholdsfortegnelse: Indholdsfortegnelse:... 2 INDLEDNING... 4 GENERELLE

Læs mere

BILAG 14 LICENSBETINGELSER

BILAG 14 LICENSBETINGELSER BILAG 14 LICENSBETINGELSER (Bilaget ligger på http://silkeborgkommune.dk/erhverv/udbud/varer-og-tjenesteydelser i pdfformat og word-format.) Skemaer med hvide felter udfyldes af Tilbudsgiver. De økonomiske

Læs mere

Kontrakt. mellem. Radio- og tv-nævnet Vognmagergade 10, 1. 1120 København K. (herefter "kunden")

Kontrakt. mellem. Radio- og tv-nævnet Vognmagergade 10, 1. 1120 København K. (herefter kunden) Kontrakt mellem Radio- og tv-nævnet Vognmagergade 10, 1. 1120 København K. (herefter "kunden") og [navn] [adresse] [postnummer] (CVR-nr. [........]) (herefter "leverandøren") om informationsindsats om

Læs mere

OPTION TIL RM OG RN BILAG 0 TIL KONTRAKT OM EPJ/PAS DEFINITIONER

OPTION TIL RM OG RN BILAG 0 TIL KONTRAKT OM EPJ/PAS DEFINITIONER OPTION TIL RM OG RN BILAG 0 TIL KONTRAKT OM EPJ/PAS DEFINITIONER INSTRUKTION TIL LEVERANDØR VED UDNYTTELSE AF OPTIONEN: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse.

Læs mere

Bilag C2.3 Licensvilkår med forrang. Rammeaftale 02.06 Standard Software Delaftale 4 Standard Software kompatibelt med SAS software

Bilag C2.3 Licensvilkår med forrang. Rammeaftale 02.06 Standard Software Delaftale 4 Standard Software kompatibelt med SAS software Bilag C2.3 Licensvilkår med forrang Rammeaftale 02.06 Standard Software Delaftale 4 Standard Software kompatibelt med SAS software Indholdsfortegnelse 1. Indledning... 3 2. Afregningsform... 4 3. Fleksibilitet

Læs mere

Bilag 14. Leverandørens forpligtelser ved ophør

Bilag 14. Leverandørens forpligtelser ved ophør Bilag 14 Leverandørens forpligtelser ved ophør Indholdsfortegnelse 1. Indledning 3 2. Leverandørens forpligtelser ved hjemtagelse og overdragelse 3 2.1 Generelle forpligtelser 3 2.2 Samarbejdet ved ophør

Læs mere

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet

Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Bilag 1 Definitioner 12.05.2016 Version 1.0 [Vejledning til tilbudsgiver: Bilaget er i sin helhed at betragte som et mindstekrav

Læs mere

Det Nationale Videncenter for Automation og Robotteknologi Nord v/techcollege

Det Nationale Videncenter for Automation og Robotteknologi Nord v/techcollege Kontrakt Levering af svejserobotter j.nr. 7.01 Det Nationale Videncenter for Automation og Robotteknologi Nord v/techcollege mellem Det Nationale Videncenter for Automation og Robotteknologi Nord v/techcollege

Læs mere

VEJLEDNING TIL STANDARDKONTRAKT FOR LANGVARIGT IT-PROJEKT K02

VEJLEDNING TIL STANDARDKONTRAKT FOR LANGVARIGT IT-PROJEKT K02 VEJLEDNING TIL STANDARDKONTRAKT FOR LANGVARIGT IT-PROJEKT K02 INDHOLDSFORTEGNELSE Indholdsfortegnelse...2 Indledning...5 Baggrund for arbejdet...6 De overordnede målsætninger for kontraktarbejdet...7 Kontraktens

Læs mere

Præsentation af K03. Standardkontrakt for længerevarende it-projekt baseret på en agil metode. v/ advokat Tom Holsøe og advokat Claus F.

Præsentation af K03. Standardkontrakt for længerevarende it-projekt baseret på en agil metode. v/ advokat Tom Holsøe og advokat Claus F. Præsentation af K03 Standardkontrakt for længerevarende it-projekt baseret på en agil metode v/ advokat Tom Holsøe og advokat Claus F. Sørensen Hvad er en agil metode? Side 2 Agil er ikke en fast defineret

Læs mere

Forretningsbetingelser

Forretningsbetingelser Forretningsbetingelser 1. Forretningsbetingelserne, aftale og parterne 1.1. Forretningsbetingelserne gælder for alle opgaver, som Vistisen & Lunde udfører for kunden, medmindre kunden har indgået anden

Læs mere

Kontrakt om anskaffelse og vedligeholdelse. et IT-system

Kontrakt om anskaffelse og vedligeholdelse. et IT-system arbejdsdokumentet skal tilpasses de konkrete forhold af en advokat Kontrakt om anskaffelse og vedligeholdelse af et IT-system indgået mellem ** og Kunden ** ** 200* 2 INDHOLDSFORTEGNELSE Punkt Side Bilagsfortegnelse

Læs mere

k01 pz /bilag 149 Justitsministeriet.

k01 pz /bilag 149 Justitsministeriet. 1 /bilag Justitsministeriet. København, den 18. maj 2009. 149 a. Justitsministeriet anmoder om Finansudvalgets tilslutning til at fortsætte digitaliseringen af tinglysningen, idet der er indgået en tillægsaftale

Læs mere

Salgs og leveringsbetingelser Solido Networks

Salgs og leveringsbetingelser Solido Networks 1 Konsulent- og serviceydelser Salgs og leveringsbetingelser Solido Networks Omfang Nærværende dokument fastlægger de almindelige betingelser for firmaet Solido Networks ( Leverandøren ) leverance til

Læs mere

DSDW, Jobindsats og Refusionsløsningen

DSDW, Jobindsats og Refusionsløsningen Spørgsmål / svar til udbud 1 Kontrakt, Pkt. 2, 3. afsnit I Kontrakten, Pkt. 2, 3. afsnit er det anført at Kunden stiller udviklings- og testmiljøer til rådighed for opgaveløsning som beskrevet i bilag

Læs mere

Generelle Bestemmelser i Forbrugeraftaler 2019 GBF 19

Generelle Bestemmelser i Forbrugeraftaler 2019 GBF 19 Danske Arkitektvirksomheder og Foreningen af Rådgivende Ingeniørers Generelle Bestemmelser i Forbrugeraftaler 2019 FORORD Danske Arkitektvirksomheder og Foreningen af Rådgivende Ingeniører (FRI) har udarbejdet

Læs mere

DATABEHANDLERAFTALE. Omsorgsbemanding

DATABEHANDLERAFTALE. Omsorgsbemanding DATABEHANDLERAFTALE Omsorgsbemanding Nærværende databehandleraftale er indgået mellem Omsorgsbemanding, via Manningsmart IVS (CVR-nr.: 40217231) og brugeren af Omsorgsbemanding. Partnerne omtales i nærværende

Læs mere

Bilag 7: Aftale om drift

Bilag 7: Aftale om drift Bilag 7: Aftale om drift Udbud af telemedicinsk løsning til hjemmemonitorering Aftale om drift mellem REGION SYDDANMARK (i det følgende kaldet Kunden ) og 2 Indholdsfortegnelse

Læs mere

Standardvilkår for samarbejde mellem medicovirksomheder og designvirksomheder

Standardvilkår for samarbejde mellem medicovirksomheder og designvirksomheder Standardvilkår for samarbejde mellem medicovirksomheder og designvirksomheder Nærværende standardvilkår er tænkt som et neutralt udgangspunkt for samarbejdet mellem medico- og designvirksomheder omkring

Læs mere

Udbud af RIPA - Syd. Bilag 1 - Tidsplan

Udbud af RIPA - Syd. Bilag 1 - Tidsplan Udbud af RIPA - Syd til Bilag 1 - Tidsplan Bilag 1 Tidsplan Side 1 af 12 Indholdsfortegnelse: 1. INDLEDNING...4 2. FRIST FOR BEVILLINGSMÆSSIG HJEMMEL...4 3. FERIE UGER...4 4. OVERORDNET FASEOPDEDLING...5

Læs mere

SAMARBEJDSAFTALE VEDRØRENDE KOMMUNERNES TILSLUTNING TIL UDFASNING AF KMD SOCIAL PENSION

SAMARBEJDSAFTALE VEDRØRENDE KOMMUNERNES TILSLUTNING TIL UDFASNING AF KMD SOCIAL PENSION SAMARBEJDSAFTALE VEDRØRENDE KOMMUNERNES TILSLUTNING TIL UDFASNING AF KMD SOCIAL PENSION Mellem Københavns Kommune Rådhuset 1599 København V (herefter "Kommunen") og KOMBIT A/S Halfdansgade 8 2300 København

Læs mere

Udbud af rådgivning i forbindelse med bygningssyn og byggeri samt bygherrerådgivning Delaftale 1-5 Kontraktbilag 5

Udbud af rådgivning i forbindelse med bygningssyn og byggeri samt bygherrerådgivning Delaftale 1-5 Kontraktbilag 5 Udbud af rådgivning i forbindelse med bygningssyn og byggeri samt bygherrerådgivning Delaftale 1-5 Kontraktbilag 5 Model for Leveringskontrakt Bilag 5 delaftale 3 - Model for Leveringskontrakt Side 2 af

Læs mere

Rettelsesblad/ Supplerende meddelelse nr. 3

Rettelsesblad/ Supplerende meddelelse nr. 3 Rettelsesblad/ Supplerende meddelelse nr. 3 Dato 18. september 2018 Sagsbehandler Per Krogsgaard Mail pkro@vd.dk Telefon 4272 3359 Dokument 18/10740-4 Side 1/9 Til de bydende på Udbud af s IT-drift Herved

Læs mere

Konsulentaftale. [Navn på kontrakten/aftalen/opgaven]

Konsulentaftale. [Navn på kontrakten/aftalen/opgaven] Konsulentaftale [Navn på kontrakten/aftalen/opgaven] 1 Parterne 3 2 Baggrund 3 3 Fortolkningsprincipper 3 4 Beskrivelse af opgaven 4 5 Rettigheder og forpligtelser 4 6 Trafik-, Bygge- og Boligstyrelsen

Læs mere

Bestillerrådgivningsaftale

Bestillerrådgivningsaftale Bestillerrådgivningsaftale København Langelinie Allé 35 2100 København Ø Danmark Aarhus Frue Kirkeplads 4 8000 Aarhus C Danmark Shanghai, rep. kontor 83 Loushanguan Road Suite 2635, 26/F Shanghai, Kina

Læs mere

Standard leveringsbetingelser

Standard leveringsbetingelser Standard leveringsbetingelser 1. Anvendelsesområde Disse almindelige betingelser finder anvendelse for enhver af kundens ordrer om levering af ydelser fra CompanYoung ApS (herefter CompanYoung), medmindre

Læs mere

BILAG 10 VEDLIGEHOLDELSE

BILAG 10 VEDLIGEHOLDELSE BILAG 10 VEDLIGEHOLDELSE VEJLEDNING Bilaget skal udfyldes af tilbudsgiver på baggrund af det i bilaget anførte skema samt de nedenfor og i kontrakten og kravspecifikationen nævnte krav og forventninger.

Læs mere

GENERELLE BESTEMMELSER I FORBRUGERAFTALER

GENERELLE BESTEMMELSER I FORBRUGERAFTALER GBF 19 GENERELLE BESTEMMELSER I FORBRUGERAFTALER 2019 Danske Arkitektvirksomheder og Foreningen af Rådgivende Ingeniørers Generelle Bestemmelser i Forbrugeraftaler 2019 GBF 19 Den 30. august 2019, version

Læs mere