Tiltak ved oppdagelse av systemfeil etter godkjenning

Systemutvikling innebærer generelt at implementeringen av programmet følger innholdet som ble bestemt i kravdefinisjonsfasen. Til slutt bekrefter både brukeren og leverandøren om resultatet samsvarer med spesifikasjonene, og prosjektet avsluttes når det er godkjent.

Men i virkeligheten kan det oppstå feil eller problemer som ikke ble oppdaget under testfasen eller ved godkjenning, og disse kan komme frem i driftsfasen. Hva kan man juridisk sett kreve når man først har akseptert leveransen?

Det er ikke overraskende at det fortsatt finnes feil etter godkjenning og testfaser

Fra et teknisk perspektiv er det ikke uvanlig at ulike feil og problemer oppdages etter at leverandørens testfaser er fullført og brukeren har godkjent systemet. Under godkjenningsprosessen utfører brukeren vanligvis en sjekk av inn- og utdata som kan bekreftes fra skjermen. Men IT-systemer har ofte en kompleks og detaljert struktur bak skjermens utseende, inkludert databaser og programmer som styrer ulike beregninger og kontroller. Derfor er det begrensninger på hva som kan undersøkes gjennom skjermbaserte inn- og utdata-sjekker fra brukerens perspektiv. Det er derfor ikke realistisk å forvente at alle potensielle problemer som kan oppstå i driftsfasen, kan oppdages gjennom slike sjekker.

De samme forholdene gjelder også fra leverandørens perspektiv. For eksempel er testfasen der man sjekker om det er feil eller problemer i de implementerte programmene. Men det er ikke alltid mulig å oppdage alle potensielle feil og problemer i testfasen. Etter at det utviklede systemet begynner å bli brukt i full skala, kan det oppstå uventede operasjoner fra brukerne, store mengder data kan bli registrert, eller flere brukere kan få tilgang samtidig. Å lage et system som fortsatt fungerer uten problemer under slike forhold krever egentlig høy teknisk kompetanse.

Man bør forstå at det ikke er realistisk å oppdage alle feil og problemer i godkjennings- og testfasene, og at ulike problemer kan oppstå etter at systemet tas i bruk.

Det er vanlig å anse gjelden som oppfylt

Så hvordan bør man håndtere slike problemer når de faktisk oppstår? La oss organisere dette i henhold til juridiske prosedyrer.

Først og fremst, hvis ulike feil og mangler oppdages etter levering, vil brukeren vanligvis ønske å holde leverandøren ansvarlig. Men hvis leveransen allerede er fullført og godkjent, er det ofte vanskelig å forfølge ansvar basert på kontraktsbrudd.

Kontrakter for systemutvikling reguleres vanligvis av bestemmelsene i den japanske sivilretten om oppdragsavtaler, med mindre det er spesielle avtaler. Vi forklarer detaljene om oppdragsavtaler i følgende artikkel.

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

I en oppdragsavtale er “fullføring av arbeidet” en forutsetning for oppfyllelse av gjelden. Vi forklarer hva “fullføring av arbeidet” konkret betyr i følgende artikkel.

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

Her forklarer vi at i tidligere rettssaker har “fullføring av arbeidet” i en oppdragsavtale, i konteksten av systemutvikling, blitt tolket som fullføring av alle utviklingsfaser. Vi forklarer også at problemer som oppstår etter fullføring av utviklingsfasene, som feil og mangler, faller inn under ansvaret for mangler i oppdragsavtalen.

For å oppsummere, hvis leveransen er mottatt og godkjent, anses gjelden som oppfylt. Deretter blir spørsmålet om det er mulig å forfølge ansvar for mangler, det vil si ansvaret for mangler i oppdragsavtalen, vanligvis det sentrale spørsmålet.

Veien til å forfølge ansvar basert på mangelsansvar

Så, hva bør man vurdere og i hvilken rekkefølge når man krever tiltak fra leverandøren basert på mangelsansvar? La oss se nærmere på dette nedenfor.

Først, bekreft alvorlighetsgraden av feil eller mangler

Når feil eller mangler oppdages i etterkant og man ønsker å kreve noen form for kompensasjon under lovens “mangel”, blir alvorlighetsgraden av feilen eller mangelen et sentralt spørsmål. Problemet med lovens mangel kan deles inn i tre kategorier:

1. Selv om det kan kalles en feil eller mangel, er det bare en mindre feil og kan ikke betraktes som en lovlig “mangel”.
2. Det kvalifiserer som en lovlig “mangel”, men det er fortsatt mulig å oppnå kontraktens formål.
3. Det kvalifiserer som en lovlig “mangel”, og det er ikke mulig å oppnå kontraktens formål.

Grensen mellom 1 og 2 avgjør om man kan forfølge ansvar basert på mangelsansvar, mens grensen mellom 2 og 3 avgjør om man kan heve kontrakten basert på mangelsansvar.

Artikkel 634

1. Når det er en mangel i arbeidsobjektet, kan bestilleren kreve at entreprenøren utbedrer mangelen innen en rimelig frist. Dette gjelder imidlertid ikke hvis mangelen er ubetydelig og utbedringen vil medføre uforholdsmessige kostnader.

2. Bestilleren kan kreve erstatning i stedet for, eller sammen med, utbedring av mangelen. I dette tilfellet gjelder bestemmelsene i artikkel 533 tilsvarende.

Artikkel 635

Når det er en mangel i arbeidsobjektet, og det derfor er umulig å oppnå kontraktens formål, kan bestilleren heve kontrakten. Dette gjelder imidlertid ikke for bygninger eller andre konstruksjoner på land.

For en detaljert forklaring av disse trinnvise forskjellene i “mangel”, se artikkelen nedenfor.

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

Deretter, klargjør hva som skal kreves fra leverandøren

Det er også nødvendig å tydeliggjøre hva som skal kreves fra motparten. Hvis man ønsker å heve kontrakten, er det ikke nok å bevise at det er en mangel; det må også bevises at mangelen gjør det “umulig å oppnå kontraktens formål”. Ved vurdering av “formålet” er møtereferater fra oppstarten av systemutviklingsprosjektet og spesifikasjonsdokumenter viktige ledetråder. Siden feil og mangler kan oppdages etter at prosjektet er godkjent, bør man sørge for å oppbevare alle relevante dokumenter også etter prosjektets avslutning.

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

Foruten heving, kan man også kreve erstatning eller utbedring av mangelen som en del av mangelsansvaret.

Andre Viktige Punkter

Vær oppmerksom på metoder ved juridiske handlinger som oppsigelse av kontrakt

Hvis du skal si opp en kontrakt på grunn av mangelsansvar, bør du også tilegne deg kunnskap om de juridiske prosedyrene for oppsigelse. Vi har forklart detaljene om effekten av kontraktsoppsigelse, hvordan man gir en gyldig erklæring, og hvordan man gir varsel for å unngå fremtidige konflikter i artikkelen nedenfor.

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

Forhandle fremfor å gå til rettssak

Disse juridiske prinsippene er ikke bare relevante i tilfelle en rettssak. Rettslige tvister er svært belastende for begge parter. Derfor bør man heller bruke denne kunnskapen i forhandlingsfasen før en eventuell rettssak. Vi har forklart betydningen av juridisk kunnskap i forhandlinger utenfor rettssalen i artikkelen nedenfor.

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

Skille mellom feil og mangler, og mangel på funksjonalitet

Diskusjonen er forskjellig når det gjelder feil og mangler i implementerte funksjoner og spesifikasjoner, sammenlignet med tilfeller der nødvendige funksjoner mangler helt. Hvis nødvendige funksjoner ikke er til stede, kan det hende at “fullføring av arbeidet” i henhold til oppdragskontrakten ikke blir anerkjent, og at oppfyllelse av forpliktelsene ikke blir godkjent.

Selv om nødvendige funksjoner og spesifikasjoner mangler, kan det være upassende å anse dette som en del av kontrakten hvis brukeren ikke har gitt tilstrekkelig informasjon i kravdefinisjonsfasen.

Oppsummering

Problemer som oppstår i løpet av et prosjekt kan avdekkes både under prosjektets gang og i driftsfasen etter prosjektets avslutning. Selv om alle faser av prosjektet fullføres uten problemer, kan man ikke alltid føle seg trygg. Denne egenskapen ved systemutviklingsprosjekter er spesielt tydelig i den japanske “ansvar for skjulte feil”-ordningen. Det er viktig å sikre grundig dokumenthåndtering som tar hensyn til tiden etter prosjektets avslutning, samt å ha en god forståelse av denne prosessen.