I mange IT-tvister er det kunden, der påstår mangler, forsinkelse eller manglende oppetid. Repræsenterer advokaten leverandøren, er situationen en anden end på kundesiden. Leverandøren har typisk selv de fleste data: tickets, versionsstyring, testresultater, driftslogs og tidsregistrering. Det er en fordel, men det stiller også krav.
Hvordan leverancen skal vurderes efter aftalen, er en juridisk vurdering. Denne side handler om, hvordan leverandøren samler, sikrer og fremlægger sin egen dokumentation. Kundens perspektiv er beskrevet i Mangler ved IT-leverancer: dokumentation i retssagen.
Fordelen og ulempen ved at have data selv
Leverandøren kan dokumentere forløbet i detaljer. Men de samme data ligger i systemer, som leverandøren styrer. Modparten vil derfor spørge, om data kan være ændret, udvalgt eller slettet. Den mistanke skal imødegås fra starten.
Det kræver tre ting:
- Data sikres i deres oprindelige form, med historik og logs, før de bearbejdes.
- Udvalget kan forklares, så modparten kan se, at intet relevant er udeladt.
- Fremgangsmåden er dokumenteret, så den kan efterprøves af en sagkyndig.
Kilderne
- Ticketsystem · Hvornår fejl blev meldt, hvordan de blev prioriteret og løst
- Versionsstyring · Hvornår kode blev ændret, af hvem, og med hvilken begrundelse
- Deploylogs · Hvornår ændringer blev sat i drift i hvilke miljøer
- Testresultater · Hvad der blev testet, og med hvilket resultat
- Overvågning · Oppetid, svartider og fejl i drift → SaaS-tvister: oppetid, SLA og logdata
- Tidsregistrering · Hvor meget tid der blev brugt på hvad
- Projektværktøjer · Ændringsønsker, beslutninger og godkendelser
- Mails og chats · Aftaler, accept og kundens egne bidrag eller forsinkelser
Kunden har ofte bidraget til forløbet, fx ved sene leverancer af data, ændrede krav eller manglende test. De spor ligger typisk også i leverandørens systemer og kan være centrale.
Sikring før bearbejdning
Det er fristende at lade en projektleder samle en præsentation eller et regneark med de vigtigste tickets. Det kan være nyttigt som oversigt, men det er ikke en sikring. Først bør de underliggende data sikres:
- en fuld eksport fra ticketsystemet for projektet med historik og kommentarer,
- en kopi af repositoriet med fuld historik, ikke kun den aktuelle kode,
- deploylogs og overvågningsdata for perioden,
- eksport af relevante kanaler i chatværktøjet.
Eksporterne bør have hashværdier og en beskrivelse af, hvem der lavede dem, hvornår og hvordan. → Bevarelsespligt og litigation hold
Udvalget skal kunne forklares
Når data er sikret, skal der vælges ud til bilag. En ticketeksport kan rumme tusindvis af sager, og kun en lille del er relevante. Udvalget bør ske efter kriterier, der kan beskrives, fx bestemte moduler, perioder, prioriteter eller nøgleord. Kriterierne bør fremgå af bilagsoversigten eller et særskilt notat.
Det har to fordele. Modparten kan se, at udvalget ikke er tilfældigt eller tilpasset. Og hvis modparten mener, at noget mangler, kan diskussionen tages om kriterierne frem for om enkelte sager.
Det kan også være en fordel at tilbyde modparten adgang til den fulde eksport. Det viser, at leverandøren ikke skjuler noget, og det gør det sværere at hævde, at noget relevant er udeladt.
Ændringsønsker og accept
Mange leverancetvister drejer sig om, hvad der blev bestilt, og hvad der blev godkendt. Leverandørens dokumentation for ændringsønsker og accept er ofte spredt mellem projektværktøjer, mails og mødereferater. En sammenhængende oversigt over hvert ændringsønske med kilde, dato og godkendelse kan være et af de vigtigste bilag.
Godkendelser givet mundtligt eller i en chat er sværere at dokumentere end en underskrevet accepttest. Det er vigtigt at finde ud af, hvad der faktisk findes, før sagen bygges op om en påstand om accept.
Opbevaring og automatisk sletning
Leverandører har ofte faste regler for sletning af logs, gamle miljøer og testdata. Når en tvist er under opsejling, bør de regler sættes i bero for de relevante systemer. Slettes data efter, at tvisten var forudsigelig, kan det svække leverandørens position, også selv om sletningen skete automatisk. → Når data er slettet: bevisforspildelse i civile sager
Det gælder også miljøer, der lukkes ned, når et projekt afsluttes. Et testmiljø kan være det eneste sted, hvor en bestemt version stadig kan afprøves.
Kundens data i leverandørens systemer
Leverandørens systemer indeholder ofte kundens data, fx testdata, kopier af produktionsdata eller kundens dokumenter. Det rejser spørgsmål om fortrolighed og databeskyttelse, når materialet bruges i en sag. Leverandøren kan være databehandler for kunden, og databehandleraftalen kan have regler for brug og sletning.
Det er relevant at afklare, inden data udleveres til advokat, sagkyndig eller retten. → GDPR og bevisførelse
Medarbejdere som vidner
Leverandørens udviklere og projektledere kender forløbet bedst. De kan forklare, hvad en ticket betyder, og hvorfor en beslutning blev truffet. Men deres forklaring vil blive set som partsforklaring. Den vægter mere, hvis den kan støttes på data, der er sikret uafhængigt af dem. → Vidneforklaring fra IT-medarbejdere
Det er også vigtigt, at de medarbejdere, der sikrer data, ikke er de samme, som er centrale for de omstridte beslutninger, hvis det kan undgås.
Når leverandøren har underleverandører
Dele af leverancen kan være udført af underleverandører eller drevet hos en hostingudbyder. Deres logs og tickets er ikke nødvendigvis i leverandørens egne systemer. Aftalerne med dem kan have regler om adgang til data og om opbevaringstid. Det bør afklares tidligt, hvilke data der ligger hos dem, og om de skal anmodes om at bevare dem.
Praktisk rækkefølge
- Stop automatisk sletning i ticketsystem, logs, chat og testmiljøer for projektet.
- Kortlæg systemerne og hvem der administrerer dem, også hos underleverandører.
- Lav fulde eksporter med historik, og beregn hashværdier.
- Beskriv fremgangsmåden i et kort notat: hvem, hvornår og med hvilke værktøjer.
- Udvælg til bilag efter kriterier, der kan beskrives.
- Byg en tidslinje over leverancen, hvor tickets, kodeændringer, deploys og korrespondance indgår. → Tidslinjer som bevis
Rækkefølgen sikrer, at materialet er intakt, før nogen begynder at fortolke det. En IT-sagkyndig, der ikke har været med i projektet, kan udføre punkt 3 og 4, så modparten ikke kan rejse tvivl om, at sikringen er foretaget af de personer, hvis beslutninger sagen handler om.
Typiske fejl
- At fremlægge et regneark med udvalgte tickets uden den underliggende eksport.
- At lade automatisk sletning af logs og miljøer fortsætte.
- At overse kundens bidrag til forsinkelser i egne data.
- At glemme databehandleraftalen, når kundens data bruges i sagen.
- At lade centrale medarbejdere sikre data om egne beslutninger.
Spørgsmål til klienten
- Hvilke systemer blev brugt i projektet, og hvem administrerer dem?
- Er der regler for sletning af logs, miljøer eller chats?
- Hvornår blev tvisten forudsigelig?
- Er nogen data allerede slettet eller ændret?
- Hvilke medarbejdere har forladt virksomheden, og er deres konti lukket?
Tjekliste
- ☐ Fulde eksporter med historik er sikret og hashet
- ☐ Automatisk sletning er sat i bero
- ☐ Udvalget til bilag kan forklares og efterprøves
- ☐ Kundens data er håndteret efter aftale og databeskyttelsesregler
- ☐ Det er dokumenteret, hvem der har sikret hvad
Når leverandørens egne data skal bære sagen, kan en IT-sagkyndig sikre dem uafhængigt af projektets medarbejdere, så modparten har mindre grund til at anfægte dem.
→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT
