Et nyt system er forsinket, fejlene hober sig op, og leverandøren siger, at det skyldes jeres ændringsønsker. Mange tvister om IT-projekter afgøres af, hvem der bedst kan dokumentere forløbet. Den dokumentation skal laves nu, mens projektet er i gang, og ikke når samarbejdet er brudt sammen.
Det betyder ikke, at I skal forberede en retssag. Det betyder, at I skal holde orden på det, der sker, så I kan vise det senere, uanset om sagen ender i en forhandling, en mægling eller ved domstolene.
Hvorfor det haster
- Adgang kan forsvinde: Leverandøren kan lukke jeres adgang til projektværktøjer og testmiljøer.
- Systemer ændres: Nye versioner overskriver de fejl, der skulle dokumenteres.
- Logfiler roterer: Logs over fejl og nedbrud slettes efter en periode.
- Hukommelsen svigter: Det, der blev sagt på møder, huskes forskelligt.
- Folk skifter: Projektlederen hos jer eller hos leverandøren kan stoppe, og med dem forsvinder viden om forløbet.
Det skal dokumenteres
- Aftalen · Kontrakt, kravspecifikation, ændringsaftaler, tidsplaner
- Kommunikation · Mails, Teams-chats, mødereferater
- Projektværktøjer · Sager i Jira, DevOps eller lignende, med historik
- Fejl · Hvad sker der, hvornår, i hvilken version, med hvilke data
- Leverancer · Hvad er leveret, hvornår, og hvad blev godkendt
- Tid og betaling · Fakturaer, timeopgørelser
- Driftsdata · Logs over nedbrud, svartider, fejlmeddelelser
Sørg for at have aftalen i de versioner, der faktisk gjaldt. Ændringsaftaler og mails, hvor krav blev ændret, er ofte kernen i uenigheden.
→ Digitale beviser i kontrakttvister
Hvem gør hvad hos jer
- Projektleder · Fører fejlliste og gemmer referater
- Brugere · Melder fejl med tid, version og beskrivelse
- IT · Sikrer logs og eksporterer fra værktøjer
- Ledelse · Beslutter, hvornår der skal en advokat ind
- Økonomi · Samler fakturaer og betalinger
Udpeg én person, der har ansvaret for at samle dokumentationen. Ellers ligger den spredt i postkasser og på skriveborde, når der er brug for den.
Sådan dokumenterer I fejl
- Beskriv fejlen: Hvad gjorde I, hvad forventede I, hvad skete der?
- Notér tid og version: Dato, klokkeslæt, systemversion, bruger.
- Optag skærmen: En video viser forløbet bedre end et skærmbillede. → Skærmbilleder som bevis
- Gem fejlmeddelelser og logs.
- Registrér fejlen i det aftalte system, så leverandøren har fået besked.
- Saml det i en fejlliste med nummer og status.
Vær præcis og saglig. “Systemet virker ikke” er svært at bruge. “Faktura kan ikke bogføres, fejlmeddelelse X, version 2.3, 14. marts kl. 10.12” kan efterprøves.
Eksportér fra projektværktøjerne
Projektværktøjer hos leverandøren kan lukkes for jer. Eksportér sager, kommentarer og historik løbende, gerne med vedhæftede filer. Gem eksporten med dato, og notér, hvem der lavede den, og fra hvilket system. Gør det fx hver måned og altid før et vigtigt møde.
Møder og mundtlige aftaler
Mange vigtige beslutninger træffes på møder og i telefonen. Skriv et kort referat efter hvert møde med dato, deltagere, beslutninger og frister, og send det til leverandøren. Bed om bemærkninger inden for en frist. Et referat, som ingen har gjort indsigelse imod, er langt stærkere end en erindring.
Bliver noget aftalt i telefonen, så send en kort mail bagefter: “Som aftalt i telefonen i dag …” Det tager to minutter og kan spare lange diskussioner.
Optag ikke møder eller samtaler uden at sige det. Spørg i stedet, om mødet må optages, eller hold jer til skriftlige referater.
Data og kildekode
Ligger jeres data i leverandørens system, så tjek, om I selv kan trække en eksport. Gør det med jævne mellemrum, så I har jeres data, hvis adgangen lukkes. Er der aftalt deponering af kildekode eller udlevering ved ophør, så find bestemmelsen frem og notér, hvad den siger.
Er jeres egne data årsag til fejl, vil leverandøren ofte sige det. Gem derfor også eksempler på de data, der blev brugt, da fejlen opstod. Gem dem uændrede og med dato, så det senere kan efterprøves, om fejlen skyldtes data eller system.
→ Exit-bistand og dataudlevering ved ophør
Sikr testmiljøet
Kan fejlene ses i et testmiljø, så overvej at få det sikret eller dokumenteret af en uvildig, før leverandøren opdaterer det. Ved en senere skønsforretning skal skønsmanden kunne se systemet, som det var.
Undgå at forværre sagen
- Skriv sagligt i mails. Alt kan blive fremlagt.
- Lav ikke selv ændringer i systemet, som kan forklare fejlene.
- Gem både det, der taler for jer, og det, der taler imod. Et ufuldstændigt billede svækker troværdigheden.
- Tilbagehold ikke betaling uden at tale med en advokat.
- Godkend ikke leverancer i blinde. En godkendelse kan senere blive brugt som bevis for, at leverancen var i orden.
- Slet ikke gamle versioner af kravspecifikationen, selv om de er forældede.
Typiske situationer
Forløbene ligner ofte hinanden. Leverandøren mener, at kravene er ændret undervejs, og at fejlene skyldes jeres data eller jeres brugere. I mener, at systemet ikke lever op til aftalen. Uden dokumentation bliver det påstand mod påstand.
En anden typisk situation er, at projektet glider stille. Ingen fejl er dramatiske, men deadlines skrider en uge ad gangen. Her er en simpel tidslinje over lovede og faktiske leverancedatoer ofte mere værd end en lang mail.
Hvornår skal en IT-sagkyndig ind?
- Når I er uenige med leverandøren om, hvad fejlene skyldes
- Når I overvejer at hæve aftalen eller kræve erstatning
- Når der skal sikres systemer, logs eller kildekode
- Når leverandøren varsler, at adgang eller testmiljø lukkes
En tidlig, uvildig vurdering kan også bruges i en forhandling, fordi den giver begge parter et fælles billede af, hvor fejlene ligger.
Hvis samarbejdet ender med en opsigelse, så læs også, hvordan I sikrer data, før adgangen lukkes.
→ Opsigelse af en IT-leverandør
Tjekliste
- ☐ Aftalegrundlaget er samlet i de gældende versioner
- ☐ Kommunikation er gemt
- ☐ Projektværktøjer er eksporteret
- ☐ Fejlliste er ført med dato og version
- ☐ Fejl er optaget på video
- ☐ Logs er sikret
- ☐ Testmiljøet er dokumenteret
- ☐ Én person har ansvaret for dokumentationen
Nielco IT er uvildig, sælger ikke produkter og har ingen leverandørpartnerskaber.
Næste skridt
- Kunden betaler ikke og påstår fejl: saml dokumentationen før inkasso
- Leverandøren overholder ikke SLA: mål og dokumentér selv
- IT-leverandøren vil ikke udlevere adgange eller data
- Den gamle IT-mand er stoppet og har alle adgangskoderne
Læs også: Agilt projekt i tvist: det tæller som dokumentation · Opsigelse af en IT-leverandør: sikr data og logfiler først
→ Tvist med en IT-leverandør eller en kunde · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
