En systemleverance er ikke en selvstændig lovbestemt entrepriseform. Begrebet bruges ofte om en samlet teknisk leverance, hvor hardware, software, projektering, installation, integration, test og dokumentation hænger sammen. Rettigheder og ansvar afhænger derfor af den konkrete kontrakt og af, om parterne eksempelvis har vedtaget AB 18, ABT 18 eller andre vilkår.

Kontrakten skal passe til den samlede ydelse

Det er ikke navnet “systemleverance”, der afgør, om aftalen skal behandles som entreprise, totalentreprise, køb eller en blandet kontrakt. Klassifikationen afhænger af ydelsens samlede indhold og tyngdepunkt. Det har betydning for blandt andet projekteringsansvar, risiko, aflevering, mangelsbedømmelse og tvisteløsning.

AB 18 og ABT 18 gælder kun, hvis de er vedtaget. ABT 18 er typisk relevant, når leverandøren også har den aftalte projektering, men den konkrete ansvarsfordeling kan være ændret i kontrakten. En funktionsbeskrivelse flytter heller ikke uden videre alt projekterings- og grænsefladeansvar til leverandøren.

Beskriv funktion og grænseflader målbart

Krav som “fuldt funktionsdygtigt”, “komplet integreret” eller “driftsklart” skaber sjældent tilstrækkelig klarhed alene. Kontrakten bør fastlægge målbare krav til kapacitet, nøjagtighed, oppetid, svartider, energi, sikkerhed, kompatibilitet og øvrige relevante funktioner.

Grænseflader til andre entrepriser og til bygherrens eksisterende anlæg bør placeres udtrykkeligt. Det bør fremgå, hvem der leverer data, strøm, netværk, føringsveje, programmering, adgang, myndighedsgodkendelser og koordinering, samt hvem der bærer risikoen, hvis en forudsætning viser sig forkert.

Test og aflevering

En brugbar testprocedure bør beskrive:

• forudsætninger og testmiljø,
• testdata, målemetoder og godkendelseskriterier,
• parternes deltagelse og dokumentation af resultatet,
• håndtering af fejl, gentest og omkostninger, og
• om delsystemer kan afleveres særskilt, og hvilke retsvirkninger det har.

En bestået test er kun lig med juridisk aflevering eller accept, hvis dette følger af aftalen. Tilsvarende kan ibrugtagning, delvis drift eller betaling være bevismomenter uden nødvendigvis alene at udgøre endelig godkendelse af leverancen.

Betaling og tilbageholdelse

Betalingsplanen kan knyttes til dokumenterede milepæle, men betaling efter “godkendelse” eller “accept” kræver klare og objektive kriterier. Ellers risikerer parterne, at betaling afhænger af et uklart eller subjektivt skøn.

Bygherren kan ikke uden særskilt grundlag frit tilbageholde hele betalingen, fordi en del af leverancen er omtvistet. En tilbageholdelse skal have hjemmel i aftalen eller de gældende regler og bør stå i rimeligt forhold til det krav, der søges sikret. Den ubestridte del af et betalingskrav bør håndteres særskilt.

Projekterings- og funktionsansvar

Hvis leverandøren projekterer systemet, bør kontrakten fastlægge, hvilke funktionskrav og forudsætninger leverandøren hæfter for, og hvilke oplysninger bygherren eller andre rådgivere har ansvaret for. Der bør også være en procedure for ændringer i input, myndighedskrav, brugerbehov og tilgrænsende arbejder.

Dokumentationen bør omfatte mere end selve leverancen: versionsstyring, tegninger, beregninger, datablade, kildekode- og licensforhold, drifts- og vedligeholdelsesmateriale, undervisning, reservedelsforhold og log over tests og ændringer kan være centrale for både aflevering og senere drift.

Tvister forebygges med en klar acceptmodel

Kontrakten bør skelne mellem teknisk test, mangelregistrering, betinget godkendelse, aflevering og udløb af en eventuel afhjælpningsperiode. Hvis et AB-regelsæt er vedtaget, skal modellen passe sammen med dets regler om ændringer, betaling, aflevering og mangler.

Den juridiske vurdering af en systemleverance kræver derfor først en kortlægning af den samlede ydelse, det valgte regelsæt, projekteringsansvaret og de konkrete acceptkriterier.