SANS_kontrakter Grundlæggende kontraktprincipper To tvister PLS kontrakten

1. SANS_kontrakter Grundlæggende kontraktprincipper To tvister PLS kontrakten Statens standardkontrakter K33, K18, K01 og K02 Kilder Søren Staugaard Nielsen, PLS Lars Ingemann, Deloitte http://www.itst.dk/it-arkitektur-og-standarder/it-styring/standardkontrakter?searchterm=standardkontrakter

2. 2. Kontrakter: Grundlæggende principper Aftalelov: Tilbud og accept forpligter parterne (rettigheder og pligter). Mundtlige og skriftlige aftaler lige gyldige. Kontrakt: Skriftlig aftale. Lettere at bevise hvad der er aftalt. Købelov: Aftale om levering af en "ting" (formuegode) mod betaling. Misligholdelse: Aftalen overholdes ikke, fx: - Forsinkelse - Mangler ved det leverede (handelskøb: undersøgelsespligt) Rettigheder ved misligholdelse (misligholdelsesbeføjelser): - Hæve købet (parterne giver ting og penge tilbage) - Udbedring af manglen - Afslag i pris - Erstatning hvis en part har lidt tab Praksis ved it-kontrakter også: - Bod (betale for forsinkelse / mangel) - Ændre aftalen Handelskøb: Ved forsinkelse. Ved (for køberen) væsentlige mangler. Handelskøb: Sælger har afhjælpningsret indtil den aftalte leveringstid. En vinder (der har mistet penge) og en bitter taber. Dommen er offentlig. Tvister (man kan ikke blive enige): - Domstol - Voldgift - Mediation (mægling) Lidt mere uformelt. Lidt dyrere. Bindende. Ikke offentlig. Skabe win-win. Hurtigt og billigt. Ikke offentlig.

3. 3. Kontrakter:IT-leverancer Udbredte standard-kontrakter: K18, K33, K01, K02, PLS Omfattende kontrakter der regulerer (har regler for): - Behov og løsning (begge dele kan være krav) - Mangler - Underleverandører - Parternes forpligtelser - Rettigheder - Hvad skal ske hvornår - Afprøvning - Misligholdelsesbeføjelser - Ændringer af aftalen - Andre hændelser, fx strejke, konkurs - Forrang - Tvister - osv. I forhold til det krævede - plus rimelige forventninger Analyse, driftsprøve, mv. Hvornår må man hæve? hvor stor bod? Kunden godkender løsningsbeskrivelsen, men det viser sig den ikke opfylder kravene? Fortolkningsrækkefølge ved domstole: - Ufravigelige regler i lovene - Specielle regler i kontrakten - Generelle regler i kontrakten - Sædvane og branchekutymer - Love på området - Tidligere domme Købeloven siger fx at sædvane har forrang

4. 4. Kontrakter:Eksempel 1 Et firma i oliebranchen fik leveret et ERP system som kunne regnskab, fakturering, mv. Det viste sig at systemet kun beregnede tønder olie med to decimaler, mens alle i oliebranchen regnede med tre decimaler. Kunden ville derfor hæve købet. Leverandøren henviste til at der intet stod om det i kravene og nægtede endda at rette manglen. Imidlertid havde leverandøren kaldt systemet en brancheløsning. Retten fandt at leverandøren kendte kundens forudsætning, hvorfor programmet var mangelfuldt. Men da kunden først havde gjort opmærksom på manglen 6 måneder efter leveringen, havde han forsømt sin undersøgelsespligt og kunne derfor ikke påberåbe sig manglen.

5. 5. Kontrakter:Eksempel 2 En virksomhed havde købt et program, der over en længere periode ikke havde virket tilfredsstillende. Kunden hævede derfor handlen. Som reaktion sendte leverandøren en modificeret version som ikke blev anvendt af kunden, men ej heller returneret. Retten fandt ikke at køberen kunne hæve købet, da sælgeren havde en afhjælpningsret, som han ikke fik mulighed for at udnytte. Endvidere kunne det ikke afvises, at den modificerede version kunne have opfyldt kundens krav.

6. 6. Kontrakter:Tidsforløb iflg. PLS-kontrakten EU begrænset udbud Prækvalificering Udbud Tilbud Kontraktunderskrift Løsningsbeskrivelse godkendt Overtagelsesprøve godkendt Driftsprøve godkendt (svartider, mv.) Garantiperiode udløber Kontrakten udløber Kravspecifikation. Ofte med kontrakt vedlagt Overordnet løsningsbeskivelse. Ofte med kontraktforbehold "Analysefase". Detaljeret løsning / design. Kan indeholde prototyping. Hævebeføjelser med kompensation til leverandør. Hævebeføjelser ved væsentlig forsinkelse. Levering er sket - kunden skal forsikre systemet Kunden må anvende systemet Hævebeføjelser ved væsentlig forsinkelse / mangel Væsentlige mangler udbedres gratis Mangler udbedres via vedligeholdsaftalen

7. 7. Kontrakter: Lidt historie - K33 og K18 • Oprindeligt foregik mange it-anskaffelser ved brug af statens standardkontrakter K33 og K18 • K33 (1987): “Statens standardkontrakt for edb-totalleverancer – samtidig anskaffelse af maskinel, special- og standardudviklet programmel” • Tænkt til større leverancer i form af skræddersyede og nøglefærdige edb-systemer • Kunne ikke anvendes ved prototypeudvikling eller faseopdelte anskaffelser • Kunne ikke anvendes til separate anskaffelser af programmel eller maskinel • K18 (1992): “Statens standardkontrakt for standardiserede edb-systemer” • Samme anvendelsesområde som K33, men er primært tænkt anvendt ved mindre anskaffelser

8. 8. Kontrakter:K33 og K18 • Fordele: • Kontrakterne var meget gennemarbejdede • De regulerede en stor del af de relevante emner • Reguleringen var detaljeret • Kontrakterne var færdige standardkontrakter, og indholdet var kendt af de professionelle aktører på markedet (blev også brugt i den private sektor) • Ulemper: • Kontrakterne var tunge • Kontrakterne var svære at læse for ikke-jurister • Kontrakterne var byrdefulde over for leverandører • Konfliktskabende • Indeholdt ingen konfliktløsningsmodeller • Indeholdt ingen ordentlig ændringshåndtering ”De nuværende standardkontrakters egnethed til it-projekter skal vurderes. IT-rådet, der er et tværministerielt udvalg på afdelingschefniveau, får til opgave sammen med juridiske eksperter, relevante brancheorganisationer og udvalgte konsulentfirmaer at udarbejde nye og mere fleksible modeller for udbud og kontrahering af systemudviklings-leverancer til evt. afløsning af de nuværende standardkontrakter, bl.a. med henblik på at gøre det lettere at opdele store projekter i mindre modeller. ” Finansloven 2001

9. Målsætningen var et ”agreed document”, dvs. en balanceret kontrakt. Det tog lang tid og mange problemer blev flyttet til løsning i ”modelbilagene” 9. Kontrakter til enhver lejlighed • En række nyskabelser bl.a. • Afklaringsfase med udtræden • Samarbejde og kundens medvirken • Læsevenlig • Idriftsættelse selvom mangler • Ansvar for tredjeparts software Iterativ udvikling var hot og der blev udarbejdet særlige ”iterative versioner” af Danske it-advokater Der arbejdes pt. på K03 som skal understøtte ”agil udvikling”

10. 10. Oversigt over bilag til K01 Kun kravspecifikation – ingen bilag til løsningsbeskrivelse Det antages implicit, at kunden selv står for drift • Prøverne omfatter (kun): • Overtagelsesprøve • Driftsprøve ”Incitamenter” anvendes i stedet for bod og kan også være bonus. * = der foreligger ikke modelbilag

11. 11. Oversigt over bilag til K02 Kravspecifikation og løsningsbeskrivelse er nu smeltet sammen til et bilag – leverancebeskrivelse. Drift kan være en del af leverancen – eller bilaget kan være udgået. Reelt en fuld drifts-kontrakt som underbilag ITST havde udarbejdet en modenhedsmodel, som skulle give et bedre samarbejde • Prøverne omfatter nu: • Fabriksprøve • Installationsprøve • Delleveranceprøve (ved fase) • Overtagelsesprøve • Driftsprøve * = der foreligger ikke modelbilag

12. 12. Kontrakter:Tidsforløb iflg. K02-kontrakten Der skal efter tildeling være en ”stand-still” periode på mindst 10 kalenderdage før underskrift Prækvalificering Udbud Tilbud Kontrakttildeling Kontraktunderskrift Afklaringsfase Løsningsbeskrivelse godkendt Fabriksprøve Installationsprøve Delleveranceprøve (ved fase) Overtagelsesprøve godkendt Driftsprøve godkendt (svartider, mv.) Garantiperiode udløber Kontrakten udløber I starten gennemføres en afklaringsfase, som slutter med opdatering af leverancebeskrivelse eller evt. kundens udtræden (evt. med vederlag). Her kan f.eks. gennemføres ”proof-of-concept” o.lign. Kunden må anvende systemet

13. 13. Kontrakter:Typiske situationer Hvad ville du gøre i disse situationer? I afklaringsfasen står det klart, at leverandøren ikke har forstået hvilken løsning, der efterspørges. I afklaringsfasen demonstrerer leverandøren en opgave-understøttelse, som er bedre end den, som er beskrevet i tilbuddet. I forløbet opstår der diskussion om funktionalitet, som ikke er beskrevet som et eksplicit krav, men som I havde forventet var med i løsningen. Leverandøren siger, det er et ændringsønske I forløbet bliver der fra politisk side introduceret ny lovgivning, som løsningen skal understøtte… Få dage før overtagelsesprøven bliver I kontaktet af kundens projektleder, som siger at det nok ikke er sandsynligt, at de bliver klar. Leverandørens gennemfører overtagelsesprøven tidsmæssigt som planlagt, men ifølge godkendelseskriterierne er den ”ikke bestået” Ved gennemførelse af driftsprøven viser det sig, at performancemål ikke er opfyldt Der er undervejs i forløbet en række konflikter på projektledelsesniveau

14. En virksomhed (kunden) har indgået aftale om udvikling og implementering af et Content Management System, til interaktiv præsentation af virksomhedens kataloger overfor medarbejdere og kunder. Man aftaler, at kunden selv skal konvertere historiske data fra et ældre eksisterende system. Det nye CMS skal iht. tidsplanen i kontrakten overtages 1. april. I midten af februar bliver kunden klar over, at der er behov for at præsentere katalogerne på betydeligt flere måder end oprindeligt aftalt. Leverandøren accepterer at udvide projektet mod en merpris. I midten af marts må kunden indse, at han ikke har ressourcer til at gennemføre konverteringen, hvorefter leverandøren overtager denne opgave mod en merpris. Systemet er ikke klart til overtagelsesprøve den 1. april. Forsinkelsen skyldes yderligere tid forbrugt på de nye præsentationer, tid forbrugt på konvertering, samt sygdom hos kundens projektleder, der har medført udsættelse af vigtige projektmøder.  Overtagelsesprøven afholdes først 1. maj, hvor det konstateres, at systemet har den fornødne funktionalitet, men er meget langsomt pga. historiske data i formater, der ikke var forudset ved aftaleindgåelsen. 14. Kontrakter, kilde: Søren Staugaard Nielsen Hvad skal kunden gøre nu? Hvad burde han have gjort?