Hvad er handlingsplanen, hvis der opdages en systemfejl efter godkendelse?

I almindelighed går systemudvikling ud på, at programimplementeringen skrider frem i overensstemmelse med det indhold, der blev besluttet i kravspecifikationsfasen, og til sidst bekræfter både brugeren og leverandøren, om det er blevet færdiggjort i henhold til specifikationerne, og afsluttes med godkendelse af accepttesten.

Men i virkeligheden kan bugs og fejl, der ikke kunne opdages under testprocessen og ved godkendelse af accepttesten, faktisk komme frem i efterfølgende driftsfaser. Hvis du har accepteret leveringen en gang, hvad kan du så juridisk kræve?

Det er ikke overraskende, at der stadig er fejl efter godkendelse eller testfasen

Set fra et teknisk synspunkt er det ikke usædvanligt, at forskellige fejl og problemer opstår efter afslutningen af leverandørens forskellige testfaser og efter godkendelsen fra brugerens side. Det, som brugeren normalt gør i godkendelsesprocessen, er primært at tjekke input og output, som kan bekræftes fra skærmen. Men IT-systemer har ofte en kompleks og detaljeret struktur i databasen bagved og i de programmer, der styrer forskellige beregninger og kontroller, ud over det udseende, der kan bekræftes fra brugerens side på skærmen. Derfor er der grænser for, hvad der kan undersøges fra brugerens synspunkt ved at tjekke input og output på skærmen. Derfor er det ikke realistisk at forsøge at udtømmende verificere alle mulige problemer, der kan opstå i den efterfølgende driftsfase, ved at tjekke.

De ovenstående omstændigheder gælder også, når man ser det fra leverandørens synspunkt, der håndterer udviklingsarbejdet. For eksempel er “testfasen” hvor man bekræfter, om der er fejl eller problemer i det implementerede program. Men selv i testfasen er det ikke nødvendigvis muligt at udtømme alle mulige fejl og problemer. Selv efter at det udviklede system er begyndt at blive brugt fuldt ud i forretningen, kræver det fremragende tekniske færdigheder at skabe et system, der fortsat kan fungere uden problemer, selv når der udføres operationer, som leverandøren ikke forventede, eller når store mængder data faktisk begynder at blive registreret, eller når flere brugere begynder at få adgang samtidig.

Det er vigtigt at forstå, at det ikke er realistisk at opdage alle fejl og problemer i faser som godkendelse og test, og at forskellige problemer kan opstå, når man faktisk begynder at bruge IT-systemet.

Gælden er normalt betragtet som opfyldt

Hvordan skal man så håndtere sådanne problemer, når de faktisk opstår? Lad os gennemgå det i den juridiske rækkefølge.

Først og fremmest, hvis forskellige bugs og fejl bliver opdaget efterfølgende, vil brugeren sandsynligvis ønske at placere et eller andet ansvar hos leverandøren, som de hidtil har bedt om at udføre arbejdet. Men normalt, hvis leveringen allerede er fuldført og har bestået inspektion, er det ofte svært at placere ansvar baseret på manglende opfyldelse af gæld.

I første omgang er kontrakter om systemudvikling, medmindre der er truffet nogle særlige aftaler, underlagt bestemmelserne om kontrakter i den japanske civillov. Hvad en kontrakt er, er forklaret i detaljer i følgende artikel.

https://monolith.law/corporate/system-development-contact-agreement [ja]

Og i en kontrakt er “fuldførelsen af arbejdet” kravet for opfyldelse af gæld. Hvad “fuldførelsen af arbejdet” konkret betyder, er forklaret i detaljer i følgende artikel.

https://monolith.law/corporate/completion-of-work-in-system-development [ja]

Her forklarer vi, at “fuldførelsen af arbejdet” i en kontrakt, i konteksten af systemudvikling, betyder afslutningen af alle udviklingsprocesser. Og vi forklarer, at problemer som bugs og fejl, der opstår efter at alle udviklingsprocesser er afsluttet, bliver et spørgsmål om ansvar for mangler i kontrakten.

For at opsummere, hvis leveringen er accepteret og inspektionen er bestået, er det normalt antaget, at gælden allerede er opfyldt, og spørgsmålet bliver så, om man kan placere ansvar for mangler, det vil sige kvalitetssikring, efterfølgende.

Vejen til at forfølge ansvar baseret på mangelsansvar

Så, hvad skal man overveje og i hvilken rækkefølge, når man søger en leverandør til at håndtere et problem baseret på mangelsansvar? Lad os se på det nedenfor.

Først skal du bekræfte graden af alvorlighed og alvor af fejl og mangler

Når fejl og mangler bliver opdaget efterfølgende, og du søger en form for garanti for, at det er en juridisk “mangel”, bliver alvorligheden af fejlen eller manglen et problem. Juridiske mangelsproblemer er grundlæggende:

1. Selvom det kan betegnes som en fejl eller mangel, er det kun mindre og kan ikke betegnes som en juridisk “mangel”.
2. Det er en juridisk “mangel”, men det er stadig muligt at opnå formålet med kontrakten.
3. Det er en juridisk “mangel”, og det er ikke muligt at opnå formålet med kontrakten.

Disse tre mønstre adskiller sig. Det, der adskiller muligheden for at forfølge ansvar baseret på mangelsansvar, er grænsen mellem 1 og 2, og det, der adskiller muligheden for at ophæve kontrakten baseret på mangelsansvar, er grænsen mellem 2 og 3.

Artikel 634

1. Når der er en mangel ved det arbejde, der er formålet med kontrakten, kan bestilleren anmode entreprenøren om at rette manglen inden for en rimelig tidsramme. Dog gælder dette ikke, hvis manglen er ubetydelig, og det ville kræve overdreven omkostninger at rette den.

2. Bestilleren kan anmode om erstatning i stedet for eller sammen med rettelse af manglen. I dette tilfælde gælder bestemmelserne i artikel 533.

Artikel 635

Når der er en mangel ved det arbejde, der er formålet med kontrakten, og det er umuligt at opnå formålet med kontrakten på grund af denne mangel, kan bestilleren ophæve kontrakten. Dog gælder dette ikke for bygninger eller andre jordarbejder.

For mere detaljeret forklaring om denne gradvise sondring af “mangler”, se følgende artikel.

https://monolith.law/corporate/defect-warranty-liability [ja]

Dernæst skal du klargøre, hvad du skal kræve af leverandøren

Dernæst skal du klargøre, hvad du skal kræve af den anden part. Hvis du ønsker at ophæve kontrakten, er det ikke nok bare at bevise, at det er en mangel, det skal være noget, der kan siges at gøre det “umuligt at opnå formålet med kontrakten”. Ved vurdering af “formålet” her er mødereferater fra møder afholdt ved starten af systemudviklingsprojektet og oplysninger i specifikationer vigtige spor. Da det er muligt, at fejl og mangler kan blive opdaget efterfølgende, selv efter godkendelse, bør du sørge for at opbevare alle dokumenter grundigt, selv efter afslutningen af udviklingsprojektet.

https://monolith.law/corporate/the-minutes-in-system-development [ja]

Udover ophævelse kan du også kræve erstatning for skader eller anmodning om rettelse af mangler som indhold af mangelsansvar.

Andre bemærkninger

Vær opmærksom på fremgangsmåden, når du udfører juridiske handlinger som ophævelse af kontrakter

Hvis du skal ophæve en kontrakt som en del af indholdet i ansvar for mangler, bør du også lære om den juridiske procedure for at gøre dette. Vi har detaljeret forklaret effekten af kontraktsoptagelse, hvordan man effektivt udtrykker sin vilje, og hvordan man giver meddelelser for at undgå fremtidige problemer i følgende artikel.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development [ja]

Det er bedre at løse konflikter gennem forhandlinger snarere end tvister

Desuden har denne række af juridiske argumenter ikke kun betydning, når en retssag opstår. Tvistløsning gennem retssager er en stor byrde for begge parter. Tværtimod, disse juridiske indsigter bør også være meget nyttige i forhandlingsfasen før en retssag. Vi har forklaret, hvor meget betydning disse juridiske indsigter har i forhandlinger uden for retssager i følgende artikel.

https://monolith.law/corporate/disputes-related-to-system-development [ja]

Man bør skelne mellem bugs og fejl, og manglende funktioner

Der er forskellige diskussioner, hvis der er bugs eller fejl i de funktioner eller specifikationer, du har implementeret, og hvis du mangler de nødvendige funktioner i første omgang. Hvis de nødvendige funktioner ikke er til stede, kan “fuldførelsen af arbejdet” i kontrakten ikke anerkendes, og opfyldelsen af forpligtelserne kan ikke anerkendes.

Desuden, selvom de nødvendige funktioner og specifikationer ikke er til stede, hvis det er resultatet af, at brugeren ikke har givet passende information i kravspecifikationsfasen, kan det være upassende at betragte det som en del af kontraktindholdet i første omgang.

Opsummering

Problemer, der opstår i løbet af et projekts forløb, kan blive opdaget enten under projektets fremdrift eller efterfølgende, som i driftsfasen. Selvom alle trin i projektet er gennemført uden problemer, er det ikke nødvendigvis en garanti for sikkerhed. Dette karakteristiske træk ved systemudviklingsprojekter synes at være symboliseret i det, vi kalder “fejl- og mangelsansvar”. Det er vigtigt at have en grundig dokumenthåndtering, der tager højde for hvad der sker efter afslutningen af systemudviklingsprojektet, og at forstå denne sammenhængende proces.