Hvad skal man være opmærksom på, når man indgår en kontrakt om systemudvikling?

Kontrakter, der indgås i projekter for udvikling af IT-systemer, er primært entreprenørkontrakter og quasi-delegation kontrakter. Der er forskellige fordele og ulemper ved at anvende hver kontrakttype for både brugere og leverandører, men det er vigtigt at forstå deres karakteristika og hvad man skal være opmærksom på, når man indgår dem. I denne artikel vil vi forklare entreprenørkontrakter i forbindelse med udvikling af IT-systemer.

Systemudvikling og entreprisekontrakter

Hvad er en entreprisekontrakt?

Når man skal forstå, hvad en entreprisekontrakt er, er det først og fremmest vigtigt at bekræfte kontraktens etableringskrav direkte fra lovens tekst.

Artikel 632

En entreprisekontrakt opstår, når en part aftaler at færdiggøre et stykke arbejde, og den anden part aftaler at betale for resultatet af dette arbejde.

“Færdiggørelse af arbejdet” er det vigtigste nøgleord. Et typisk eksempel på en entreprisekontrakt er opførelsen af en bygning, der kræver byggearbejde. For eksempel, hvis et hus eller en bygning er opført inden for den aftalte tidsfrist, betragtes arbejdet som “færdiggjort”, og forpligtelsen er opfyldt. Omvendt, hvis byggearbejdet er forsinket, kan der pålægges ansvar for manglende opfyldelse under visse betingelser. Men hvis “færdiggørelse af arbejdet” først er anerkendt, forsvinder problemet med manglende opfyldelse, og det bliver et spørgsmål om garanti for mangler. I denne forstand er det netop fokus på “færdiggørelse af arbejdet” der kendetegner entreprisekontrakten. Hvad der betragtes som “færdiggørelse af arbejdet” er forklaret i detaljer i følgende artikel.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Entreprisekontrakter bruges ikke kun til byggeri, men også ofte i systemudviklingsprojekter, der kræver store visioner og detaljerede planer.

Hvad er forskellen mellem entreprisekontrakter og quasi-kommissionskontrakter?

Når det er klart, at entreprisekontrakten er en kontraktstype, der fokuserer på “færdiggørelse af arbejdet”, bliver karakteristikaene ved quasi-kommissionskontrakter også klare. Disse fokuserer ikke på “færdiggørelse”, men på processen. For eksempel, hvis arbejdsprocessen er blevet korrekt håndteret, uanset resultatet, er det muligt at anmode om betaling (artikel 648, stk. 2), og hvis opfyldelsen er afsluttet midtvejs på grund af årsager, der ikke kan tilskrives agenten, er det muligt at anmode om betaling i forhold til det (artikel 648, stk. 3).

For en detaljeret forklaring af sammenligningen mellem kommissionskontrakter og quasi-kommissionskontrakter, se følgende artikel.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Hvorfor entreprisekontrakter foretrækkes i systemudvikling

I kontrakter om systemudvikling bruges entreprisekontrakter meget ofte. Grunden til, at entreprisekontrakter bruges ofte, er, at de har visse fordele for både brugeren, der bestiller arbejdet, og leverandøren, der modtager ordren.

For det første er en af fordelene ved at bestille arbejde gennem en entreprisekontrakt for brugeren, at kravene til opfyldelse af forpligtelsen let kan præciseres i form af “færdiggørelse af arbejdet”. Med andre ord, der er en klarhed i, at betaling i princippet ikke skal foretages, medmindre der er opnået en tilstand, der kan betegnes som “færdiggjort” (selvom der kan opstå problemer med garantien for mangler, såsom at finde fejl senere). Dette er meget attraktivt for brugere, der ikke ønsker at løbe risikoen for, at den betaling, de skal foretage, svulmer op, hvis arbejdstiden overstiger forventningerne, eller hvis tidsplanen trækker ud. Der er stor bekvemmelighed i at betale et fast beløb i bytte for det “færdige” produkt fra et budgetstyringsperspektiv.

På den anden side kan der også være visse fordele for leverandøren, der modtager arbejdet, ved at acceptere ordren gennem en entreprisekontrakt. En entreprisekontrakt kan give en større profitmargin end en quasi-kommissionskontrakt, hvis den håndteres korrekt.

Da “færdiggørelse af arbejdet” er et krav for opfyldelse af forpligtelsen, kan leverandøren, der modtager arbejdet, ignorere, hvor meget det har kostet at færdiggøre arbejdet i processen (i tilfælde af systemudvikling er det meste af omkostningerne personaleomkostninger). På denne måde kan både leverandøren, der ønsker at øge sin profitmargin, og brugeren, der ønsker at gøre budgetstyringen lettere, have deres ønsker opfyldt, og derfor er entreprisekontrakter meget populære i systemudvikling.

Punkter at være opmærksom på ved indgåelse af kontrakt

Selvom der er fordele ved kontrakter for både brugere og leverandører, medfører det også risici, især for leverandøren, at indgå kontrakter uden omhu. Frem for alt betyder det, at “fuldførelse af arbejdet” er nødvendigt for at opfylde forpligtelserne, at man ikke kan fritages fra ansvar for manglende opfyldelse af forpligtelserne, medmindre det færdige produkt er færdigt. Dette er også grunden til, at der ofte opstår problemer, hvor leverandøren skal bruge tid på levering, selvom de er i underskud på grund af fejl i deres estimater.

Så hvad skal man være opmærksom på i kontrakten for at indgå en kontrakt? Lad os se på hver enkelt nedenfor.

Klarlæg systemkrav og acceptkriterier på forhånd

Det vigtigste i en kontrakt er naturligvis at klarlægge betingelserne for “fuldførelse af arbejdet”. Normalt refererer “fuldførelse af arbejdet” her til indholdet af aftalen i kravdefineringsfasen. Men i praksis kan der være tilfælde, hvor man er tvunget til at foretage ændringer efterfølgende, efterhånden som udviklingsprocessen skrider frem, og kravene til “fuldførelse af arbejdet” kan også ændre sig. Det er vigtigt at dokumentere ændringshistorikken for specifikationerne, herunder disse. I følgende artikel forklarer vi, hvordan man håndterer ændringsstyring i systemudviklingsprojekter fra et juridisk perspektiv.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Relateret til dette emne er det også effektivt at foretage aftaler på forhånd om “accept af brugeren” for at forhindre fremtidige problemer. Selvom man forsøger at levere det færdige produkt, er det naturligt at forvente situationer, hvor brugerens repræsentant ikke kan kontaktes, eller hvor man ikke får svar i lang tid. For at undgå at lade acceptens godkendelse være uklar i lang tid, er det gavnligt at fastsætte en bestemt frist for accept. Dette er det såkaldte “antagelsesklausul”, som vi forklarer i følgende artikel.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Foretag aftaler på forhånd om, hvorvidt ophavsretten skal overføres

Et andet almindeligt problem er overførsel af ophavsret. Ophavsretten tilfalder i princippet “den, der har skabt det”, dvs. leverandøren i tilfælde af systemudvikling, men det er også muligt at overføre eller overdrage rettighederne på grund af deres natur. Derfor kan det at lave aftaler på forhånd om, hvorvidt ophavsretten skal overdrages til brugeren, forhindre fremtidige problemer. Vi forklarer detaljeret om ophavsret og overførsel i følgende artikel.

https://monolith.law/corporate/copyright-for-the-program-source-code[ja]

Andre punkter at være opmærksom på

Desuden, hvis du ønsker at indgå en kontrakt som en kontrakt uden at inkludere elementer af en stedfortrædende aftale, bør du være opmærksom på følgende:

• At holde betalingen uafhængig af arbejdstiden
• At angive “kontrakt” i kontraktens titel
• At angive klausulen om ansvar for mangler
• At betalingen er en ækvivalent udveksling for resultatet eller produktet

Det er godt at være opmærksom på disse punkter.

Det er dog vigtigt ikke at have en letfærdig tankegang om, at alt bliver en kontrakt, bare fordi man skriver “kontrakt” i kontraktens titel. I praksis er der tilfælde, hvor andre virksomheders kontraktsskabeloner bliver genbrugt uden hensyntagen til, om indholdet af kontrakten er en kontrakt eller en stedfortrædende aftale. Hvis sagen ender i retten, vil mere substantielle spørgsmål, såsom det samlede indhold af kontrakten og tidligere handelspraksis, blive prioriteret over overfladiske elementer som titlen på kontrakten. Det er også vigtigt at være opmærksom på dette punkt.

Opsummering

Hvis man tager højde for ovenstående punkter, bliver det lettere at håndtere kontraktarbejde korrekt gennem outsourcing. Bemærk, at ordet “uddelegering” bruges i både kontraktlige og semi-delegerede kontrakter. Desuden er udtrykket “forretningsuddelegering” typisk brugt, når parterne har en intention om en semi-delegeret kontrakt. Det vil være godt at være opmærksom på disse små forskelle i terminologi.