Mangler ved IT‑leverancer: dokumentation i retssagen

Tvister om IT-leverancer handler sjældent om én fejl. De handler om et forløb: en kravspecifikation, der blev tolket forskelligt, ændringsønsker, der blev aftalt eller ikke aftalt, test, der blev godkendt med forbehold, og en tidsplan, der skred. Når sagen når retten, skal forløbet kunne genfortælles med data og ikke kun med parternes erindring.

Om leverancen er mangelfuld i aftalens forstand, og hvilke konsekvenser det har, er advokatens vurdering. Her ser vi på, hvilke digitale spor der kan understøtte eller svække påstanden, og hvordan de sikres. Den brede gennemgang af IT-projekttvister findes under Tvister om IT-projekter, og kundens praktiske tjekliste under Leverandøren leverer ikke.

Tre slags påstande, tre slags beviser

• Systemet virker ikke som aftalt · Testrapporter, fejlsager, logfiler, testmiljø
• Leverancen er forsinket · Tidsplaner, milepæle, versionshistorik, leverancebreve
• Kravene er ændret undervejs · Ændringsanmodninger, mødereferater, mails, backloghistorik

Mange sager rummer alle tre. Hold dem adskilt i bevisførelsen. En forsinkelse kan skyldes leverandøren, kundens egne ændringsønsker eller manglende medvirken fra kunden, og de samme data kan pege i flere retninger.

Hvor data ligger, og hvem der har dem

• Projektværktøjer: Jira, Azure DevOps eller lignende. Her ligger fejlsager, prioriteringer og statusskift med tidsstempler. Ofte ejer leverandøren værktøjet, og kunden har kun en brugeradgang.
• Kildekode og versionsstyring: Normalt hos leverandøren. Historikken viser, hvornår funktioner blev udviklet og rettet.
• Test- og produktionsmiljø: Kan ligge hos kunden, hos leverandøren eller hos en hostingudbyder. Logfiler slettes eller overskrives ofte efter kort tid.
• Mails og chatkanaler: Hos begge parter. De forklarer ofte, hvorfor en fejlsag blev lukket eller nedprioriteret.
• Dokumentarkiv: Kravspecifikation, løsningsbeskrivelse, testplaner og godkendelser, typisk i flere versioner.

Afklar tidligt, hvilke kilder klienten selv kan sikre, og hvilke der kræver medvirken fra modparten. Når samarbejdet er brudt, lukker leverandøren ofte kundens adgang til projektværktøjet. En eksport, før det sker, er langt lettere end en senere editionsbegæring. → Editionsbegæring set fra IT-siden

Det skal sikres først

1. Eksport fra leverandørens værktøjer: Fejlsager med fuld historik og kommentarer, ikke kun den aktuelle status.
2. Testmiljøet i sin nuværende tilstand: Hvis kunden har et testmiljø, så frys eller kopiér det. En ny version fra leverandøren kan overskrive netop den fejl, sagen handler om.
3. Logfiler fra produktion: Hvis systemet er i drift, kan fejl ses i applikationslogs og fejlrapporter. De slettes typisk automatisk.
4. Den aftalte kravspecifikation: Den version, der var bilag til kontrakten, og senere versioner med ændringsspor.
5. Mails og møder: Postkasser for projektlederen og nøglepersoner hos kunden sættes på bevarelse. → Bevarelsespligt og litigation hold

Hvad data kan og ikke kan vise

Data kan vise, at en fejlsag blev oprettet en bestemt dag, hvem der lukkede den, og hvilken kode der blev ændret. Data kan også vise, at en funktion fejlede i testmiljøet med en bestemt fejlmeddelelse på et bestemt tidspunkt.

Data kan derimod ikke alene vise, at fejlen er en mangel. Det kræver, at fejlen holdes op mod det aftalte. Den sammenholdelse er netop skønsmandens opgave og advokatens argumentation. Data viser heller ikke i sig selv, om en fejl er alvorlig. Alvoren afhænger af, hvordan systemet skal bruges, og det skal forklares.

Et eksempel: Kunden fremlægger en liste med mange åbne fejlsager. Leverandøren svarer, at de fleste i virkeligheden er ændringsønsker, der er registreret som fejl. Uden en gennemgang af den enkelte sag og den kravtekst, den vedrører, står påstand mod påstand. En kategorisering foretaget af en sagkyndig med henvisning til kravspecifikationen kan gøre listen brugbar for retten.

Ændringsønsker: hvor sagerne ofte afgøres

Ændringer aftales sjældent så formelt, som kontrakten foreskriver. De aftales på et møde, i en chat eller i en kommentar til en fejlsag. Bed klienten om at finde netop de steder:

• Kommentarer i projektværktøjet, hvor omfang eller pris drøftes
• Referater fra styregruppemøder og spor af, at de er godkendt
• Mails med ord som “ekstra”, “tillæg” eller “uden for scope”
• Ændringer i backloggen, hvor opgaver er flyttet mellem faser eller leverancer

Versionshistorik i dokumenter og backlog kan vise, hvornår et krav blev ændret, og af hvilken bruger. Det er ofte mere overbevisende end en senere forklaring om, hvad parterne mente.

Test og godkendelse

Mange IT-kontrakter har en overtagelsesprøve eller en anden form for godkendelse. Hvad en godkendelse betyder retligt, er advokatens vurdering. Teknisk er spørgsmålet, hvad der faktisk blev testet. Sikr testplanen, testdata, testresultaterne og den mail eller signatur, der markerer godkendelsen. Et forbehold, der kun står i et mødereferat, kan være svært at finde senere, hvis ingen har gemt det.

Typiske fejl

• Kunden lader leverandøren rette i testmiljøet, efter tvisten er opstået, uden at tilstanden er sikret først.
• Fejlsager fremlægges som skærmbilleder uden historik og kommentarer.
• Klientens egen IT-afdeling genskaber fejl uden at dokumentere, hvordan det blev gjort.
• Der fremlægges hundredvis af fejlsager uden sortering, så retten ikke kan se, hvilke der er væsentlige.
• Systemet afinstalleres, og klienten skifter leverandør, før nogen uafhængig har set det i drift.

Spørgsmål til klienten

• Hvem havde adgang til projektværktøjet, og har I det stadig?
• Findes der et testmiljø, og hvem kan ændre i det?
• Hvilken version af kravspecifikationen indgik i kontrakten?
• Hvor blev ændringer drøftet i praksis?
• Har I selv foretaget ændringer eller tilpasninger i systemet?
• Er der sket en overtagelse eller godkendelse, og med hvilke forbehold?

Spørgsmål til modpartens sagkyndige

Har leverandøren eller kunden fremlagt en partsindhentet erklæring om leverancen, er det værd at gennemgå den med faste spørgsmål:

• Hvilken version af systemet og hvilken version af kravspecifikationen er vurderet?
• Er vurderingen foretaget i et testmiljø, i produktion eller ud fra dokumentation alene?
• Hvem har stillet data og adgang til rådighed, og er der data, den sagkyndige ikke har set?
• Hvordan er fejlsager kategoriseret som fejl eller ændringsønsker, og med hvilken begrundelse?
• Er konklusionerne knyttet til konkrete krav, eller er de generelle vurderinger af kvaliteten?

Svarene viser ofte, om uenigheden handler om data, om metode eller om fortolkningen af kontrakten. Det første og det andet kan afklares teknisk, fx ved supplerende spørgsmål eller syn og skøn. Det tredje er et spørgsmål for advokaterne og retten. → Partsindhentet erklæring eller skønserklæring

Spørgsmål til skønsmanden

Spørgsmålene bør være konkrete og knyttet til kontraktens krav. → Syn og skøn i IT-sager

• Svagt: “Er systemet mangelfuldt?”
• Bedre: “Opfylder systemet i den leverede version kravene i kravspecifikationens afsnit om fakturering, og i bekræftende fald med hvilke afvigelser?”
• Svagt: “Hvem har skylden for forsinkelsen?”
• Bedre: “Kan det ud fra projektværktøjets historik opgøres, hvor mange af de registrerede fejlsager der vedrører funktioner, som ikke indgår i den kontraktuelle kravspecifikation?”

Overvej også, om skønsmanden skal se et kørende system frem for kun dokumentation. Det kræver aftale med modparten. → Skønsmandens adgang til systemer og data

Tjekliste

• ☐ Fejlsager eksporteret med fuld historik
• ☐ Testmiljø frosset eller kopieret
• ☐ Produktionslogs sikret før sletning
• ☐ Kontraktens version af kravspecifikationen identificeret
• ☐ Ændringsdrøftelser fundet og samlet
• ☐ Nøglepersoners postkasser sat på bevarelse
• ☐ Skønstemaet knyttet til konkrete krav

→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT