IT-skøn i tvister om IT-projekter og software

Når et IT-projekt ender i en tvist, står retten typisk med to fortællinger om det samme forløb. Kunden mener, at systemet ikke virker som aftalt og blev leveret for sent. Leverandøren mener, at kravene blev ændret undervejs, og at kunden ikke medvirkede. En skønsmand med IT-faglig baggrund kan give retten et uvildigt grundlag for at vurdere de tekniske dele af tvisten.

Denne side handler om skønnet i IT-projekt- og softwaresager: hvilke temaer der typisk skal belyses, hvilke data skønsmanden har brug for, og hvordan spørgsmålene formuleres, så svarene kan bruges. Hvordan dokumentationen sikres, før sagen anlægges, er beskrevet i Mangler ved IT-leverancer: dokumentation i retssagen og Tjekliste: IT-leverancesag. Den generelle proces for syn og skøn står på IT-skønsmand.

Typiske skønstemaer

De fleste IT-projektsager rummer flere af disse temaer på én gang. Hold dem adskilt i skønstemaet, fordi de kræver forskellige data og forskellige metoder.

Mangler · Om bestemte funktioner virker som beskrevet i kravspecifikationen, og hvor stor afvigelsen er
Forsinkelse · Hvornår leverancer faktisk skete, og hvad versionshistorik og projektværktøjer viser om årsagerne
Kravspecifikation og ændringer · Om en fejlsag vedrører et oprindeligt krav eller et senere ændringsønske
Test og accept · Hvad der faktisk blev testet, med hvilke data, og hvad testresultaterne viser
Ydeevne · Svartider og kapacitet målt under forhold, der svarer til de aftalte
Sikkerhed · Om løsningen lever op til beskrevne sikkerhedskrav, fx adgangsstyring, kryptering og logning
Kildekode og dokumentation · Kodens kvalitet, vedligeholdbarhed og om dokumentationen svarer til det leverede
Drift og SLA · Oppetid, svartider på fejl og om målingerne bag rapporterne er pålidelige

Om en afvigelse er en mangel i aftaleretlig forstand, er ikke et skønsspørgsmål. Skønsmanden kan beskrive, hvad systemet gør, og holde det op mod en konkret kravtekst. Den retlige kvalifikation er advokaternes og rettens. SaaS- og driftstvister er beskrevet nærmere i SaaS-tvister, SLA og logdata.

De data, skønsmanden skal have adgang til

Et skøn i en IT-projektsag kan sjældent besvares ud fra bilagene alene. Skønsmanden har typisk brug for adgang til flere af disse kilder:

Testmiljø eller en kopi af systemet. Fejl skal kunne genskabes og afprøves i en kendt version. Arbejde i et system i drift bør undgås, hvis det kan lade sig gøre.
Ticketsystemet. Fejlsager med fuld historik, kommentarer og statusskift, ikke kun den aktuelle status. → Jira, Zendesk og ticketsystemer som bevis
Versionsstyring. Kildekodens historik viser, hvornår funktioner blev udviklet, ændret og rettet, og hvilken version der blev leveret.
Logs. Applikations- og driftslogs kan vise fejl, svartider og nedetid på bestemte tidspunkter.
Kravspecifikation og ændringsanmodninger i de versioner, der var gældende på de relevante tidspunkter.
Testplaner, testdata og testrapporter fra den aftalte overtagelsesprøve eller tilsvarende.

Ofte har den ene part det hele, typisk leverandøren. Aftal tidligt, hvordan adgangen gives, hvem der er til stede, og hvordan det sikres, at intet ændres undervejs. → Skønsmandens adgang til systemer og data

Data, der er blevet slettet, overskrevet eller ændret, efter tvisten opstod, kan ikke genskabes af skønsmanden. Har klienten ikke sikret testmiljø, logs og eksport fra projektværktøjet, kan skønnet blive mindre præcist, end sagen fortjener.

Før skønstemaet skrives

Et skøn i en IT-projektsag bliver bedre, hvis advokaten har et teknisk overblik, før spørgsmålene formuleres. Tre ting er værd at få på plads:

En tidslinje. Hvornår blev kontrakten indgået, hvornår kom de vigtigste ændringsønsker, hvornår blev der leveret til test, og hvornår gik samarbejdet i stå? Tidslinjen viser, hvilke perioder skønsmanden skal se på. → Tidslinjer som bevis
Et datakort. Hvor ligger data, hvem ejer dem, og hvem har adgang i dag? Det afgør, om skønsmanden kan få adgang uden en editionsbegæring.
En sortering af påstandene. Hvilke fejl er de væsentlige for sagen? Et skøn over ti centrale fejl er ofte mere værd end et skøn over alle registrerede fejlsager.

Er klienten leverandøren, er udgangspunktet et andet: Her handler det ofte om at dokumentere, at det leverede svarer til kravene, og at forsinkelser skyldtes forhold hos kunden. Datakilderne er de samme, men skønsspørgsmålene vendes om.

Gode og dårlige skønsspørgsmål

Et godt skønsspørgsmål kan besvares teknisk, peger på konkrete krav og data og forudsætter ikke svaret.

Mangler

Svagt: “Er systemet mangelfuldt?”
Bedre: “Kan skønsmanden i testmiljøet med version [x] konstatere, om funktionen beskrevet i kravspecifikationens afsnit [y] fungerer som beskrevet, og i benægtende fald beskrive afvigelserne?”

Ændringer

Svagt: “Har kunden ændret kravene?”
Bedre: “Kan skønsmanden for hver af de fejlsager, der er opført i bilag [z], angive, om fejlsagen vedrører et krav i den kontraktuelle kravspecifikation eller en funktion, der ikke er beskrevet der?”

Forsinkelse

Svagt: “Hvem har ansvaret for forsinkelsen?”
Bedre: “Hvornår blev funktionerne i milepæl [n] ifølge versionsstyringen og releasehistorikken første gang leveret til testmiljøet?”

Ydeevne

Svagt: “Er systemet for langsomt?”
Bedre: “Hvad er svartiden for [bestemt handling] målt under de forudsætninger om datamængde og antal samtidige brugere, der fremgår af bilag [x]?”

Spørgsmål om ansvar, skyld og om noget er “rimeligt” hører ikke hjemme i skønstemaet. De kan få skønsmanden til at svare juridisk, og det svækker erklæringen. Se også Skabelon: skønstema i IT-sager og Syn og skøn i IT-sager.

Faldgruber

Systemet er ændret siden tvisten. Leverandøren har rettet fejl eller opdateret testmiljøet, så skønsmanden ser en anden version end den, sagen handler om. Sikr versionen, før skønnet begynder.
Uklart, hvilken kravspecifikation der gælder. Er der flere versioner, bør skønstemaet angive, hvilken skønsmanden skal måle op imod.
Hundredvis af fejlsager uden sortering. Bed om en vurdering af de væsentligste eller af en stikprøve, og beskriv, hvordan udvalget er sket. → Stikprøver i store datamængder
Ensidig kontakt. Al kommunikation med skønsmanden skal ske, så begge parter er orienteret. Det gælder også, når den ene part stiller adgang til rådighed.
Skønsmanden mangler den rette faglighed. Et skøn over kildekodens kvalitet kræver anden erfaring end et skøn over driftssikkerhed eller informationssikkerhed. Vælg ud fra temaet. → Sådan vælger du en IT-sagkyndig
Tidspunktet er forkert. Kommer skønnet efter, at systemet er taget ud af drift og erstattet, kan væsentlige spørgsmål ikke længere besvares.

Er erklæringen kommet, og den ikke svarer på det, sagen handler om, så se Supplerende skøn og overskøn i IT-sager.

Skøn ved domstolene eller i voldgift

Mange IT-kontrakter har en voldgiftsklausul. Skønsspørgsmålene er de samme, men processen er en anden. → Voldgift og skønsmand i IT-sager og IT-udtalelse via Voldgiftsinstituttet

Sådan kan Nielco IT bistå

John Nielsen, Nielco IT, er IT-sagkyndig med retssagserfaring og arbejder for parter, advokater og domstole. Nielco IT sælger ikke produkter og har ingen leverandørpartnerskaber. Opgaven kan være at kunne foreslås som skønsmand, at hjælpe med at formulere skønstemaet eller at gennemgå dokumentationen, før den fremlægges. Den samme person kan ikke have flere roller i samme sag, så rollen afklares først.

→ IT-sagkyndig for advokater · Send en sag