I systemutvikling oppstår juridiske problemer ofte i forbindelse med “akseptanse”.
“Akseptanse” refererer til oppdragsgivers plikt til å inspisere og godkjenne leveransen når leverandøren har levert sluttproduktet. Hvis oppdragsgiver ikke gjennomfører “akseptanse” etter leveransen, vil leverandøren befinne seg i en juridisk usikker posisjon.
For å løse slike problemer, inkluderer kontrakter ofte en klausul om “antas akseptanse”.
I denne artikkelen vil vi forklare i hvilke tilfeller “antas akseptanse” gjelder, basert på faktiske rettsavgjørelser.
Hva er akseptansetest i systemutvikling?
Generelt sett refererer “akseptansetest” i et systemutviklingsprosjekt til prosessen der brukeren, som er oppdragsgiveren, inspiserer og kontrollerer om leverandørens leverte produkt (her referert til som IT-systemet) oppfyller de spesifikasjonene som ble bestilt for å oppnå det ønskede formålet.
Fra utviklerens perspektiv kan dette betraktes som en testfase for å bekrefte om produktet virkelig er ferdigstilt.
På grunn av arbeidsoppgavens natur, har leverandøren ofte stor frihet i systemutvikling, noe som kan føre til avvik mellom det faktiske produktet og det brukeren ønsket.
Generelt sett betyr bestått akseptansetest at brukeren selv har bekreftet at det leverte produktet samsvarer med det som ble bestilt (eller formålet med å be om systemutvikling).
Selv om det i praksis kan oppstå tilfeller der feil i systemet oppdages etter akseptansetest, er det vanlig at bestått akseptansetest er en betingelse for betaling.
Vær oppmerksom på antatt akseptklausul
Hvis det oppstår problemer i akseptfasen, kan både brukeren og leverandøren stå overfor vanskelige situasjoner.
For eksempel, hva skjer hvis leverandøren har fullført og presentert leveransen, men brukeren ikke godtar den på grunn av interne forhold?
For å forutse slike situasjoner, inkluderer kontrakter for systemutvikling ofte en klausul kjent som “antatt akseptklausul”.
Hva er en anerkjennelsesklausul?
(Inspeksjon av programvaren) Artikkel 28 For programvaren som er en del av leveransen, skal Part A inspisere den innen perioden spesifisert i den individuelle kontrakten (heretter kalt “inspeksjonsperioden”) i henhold til inspeksjonsspesifikasjonen i forrige artikkel, og kontrollere om systemspesifikasjonen og programvaren samsvarer.
2. Hvis programvaren oppfyller inspeksjonskravene i forrige avsnitt, skal Part A signere og stemple inspeksjonssertifikatet og overlevere det til Part B. Hvis programvaren ikke oppfyller inspeksjonskravene, skal Part A umiddelbart gi Part B en skriftlig forklaring på de spesifikke grunnene til at den ikke besto, og be om rettelser eller tillegg. Hvis grunnene til ikke-bestått er akseptable, skal Part B, etter avtale, rette opp feilene kostnadsfritt innen en avtalt frist og levere programvaren til Part A, som deretter skal utføre inspeksjonen på nytt i nødvendig omfang.
3. Selv om inspeksjonssertifikatet ikke er utstedt, skal programvaren anses som bestått inspeksjonen spesifisert i denne artikkelen hvis Part A ikke skriftlig uttrykker spesifikke innvendinger innen inspeksjonsperioden.
4. Når inspeksjonen spesifisert i denne artikkelen er bestått, anses programvaren som fullstendig inspisert.
Juridisk sett er uttrykket “anses som” i tredje avsnitt et viktig punkt å merke seg. Når det gjelder juridiske termer, har “anse” og “anta” faktisk helt forskjellige betydninger.
Anse・・・ →Selv om noe faktisk ikke er tilfelle, behandles det som om det er tilfelle i henhold til loven.
(Eksempel) Hvis man bruker en smarttelefon under en eksamen, anses det som juks. →Uansett om bruken av smarttelefonen faktisk var juks eller ikke, vil det bli behandlet som juks.
Anta・・・ →Med mindre det finnes bevis som motbeviser en bestemt faktum, behandles det som en sannhet.
(Eksempel) Hvis man ser på en smarttelefon under en eksamen, antas det som juks. →Det antas som juks med mindre man kan motbevise det ved å vise at smarttelefonen ble brukt til noe annet. (Selv om det er sjeldent å høre en slik kunngjøring i en eksamenssal.)
Med andre ord, det er en betydelig forskjell i hvor vanskelig det er å motbevise “anta” og “anse”. Her betyr det at programvaren behandles som bestått inspeksjonen, uavhengig av om den faktisk besto eller ikke.
Rettseksempler relatert til antatte klausulbestemmelser
Det har tidligere vært tilfeller der antatte inspeksjonsklausuler har hatt avgjørende betydning i rettssaker. For eksempel, i den følgende dommen, reiste brukeren en sak etter å ha hevdet at nødvendige funksjoner ikke var implementert, uten å ha gjennomført inspeksjon innen den angitte perioden. Retten konkluderte imidlertid med at leveransen allerede var fullført basert på den antatte klausulbestemmelsen.
I denne kontrakten er det fastsatt at selskap Y skal inspisere systemet umiddelbart etter levering og varsle skriftlig innen 10 dager. Hvis det ikke gis varsel innen denne fristen, anses inspeksjonen som godkjent. Det er ikke påvist at det ble gitt varsel om mangler ved inspeksjonen i denne saken, og derfor kan leveransen og inspeksjonen anses som fullført.
Tokyo District Court, dom av 29. februar Heisei 24 (2012)
På den annen side finnes det også rettsavgjørelser som har avvist anvendelsen av denne antatte inspeksjonsklausulen og anerkjent leverandørens brudd på forpliktelser.
I den følgende dommen var leverandørens samarbeid nødvendig for å gjennomføre inspeksjonen, men leverandøren unnlot å samarbeide, noe som skiller denne saken fra den tidligere nevnte dommen.
Saksøker (leverandøren) hevder at saksøkte (brukeren) ikke varslet om inspeksjonsresultatene innen 10 dager etter leveringsdatoen, og at produktet derfor anses som inspisert i henhold til paragraf 9, punkt 4 i programvareutviklingskontrakten. Imidlertid er saksøkers samarbeid avgjørende for at dette resultatet skal kunne oppnås, og det er påvist at saksøker ikke har gitt nødvendig samarbeid for inspeksjonen. Derfor kan ikke produktet anses som inspisert i henhold til paragraf 9, punkt 4 i denne saken, selv om saksøkte ikke varslet om inspeksjonsresultatene innen 10 dager etter leveringsdatoen.
Tokyo District Court, dom av 23. juni Heisei 16 (2004)
Formålet med antatte inspeksjonsklausuler er å frigjøre leverandøren fra en usikker situasjon der arbeidet forsinkes på grunn av brukerens ensidige forhold, og å opprettholde et rettferdig forhold mellom partene.
Derfor kan ikke antatte inspeksjonsklausuler brukes som et middel for å utsette inspeksjonen og tvinge brukeren til å akseptere defekte produkter.
Hvis inspeksjonen anses som godkjent, må brukeren betale vederlaget for systemutviklingen. Med tanke på denne alvorligheten, tar retten også hensyn til leverandørens samarbeidsvilje for å gjøre en rettferdig vurdering.
For å støtte slike vurderinger kan ikke bare kontrakten, men også møtereferater fra systemutviklingsprosessen være viktige bevis. Dette er detaljert forklart i artikkelen nedenfor.
For mer informasjon om hvilke omfattende forpliktelser leverandøren har som systemutviklingsekspert i prosjektet, se artikkelen nedenfor.
Selv om inspeksjonsarbeidet i prinsippet skal utføres av brukeren, er det naturlig at leverandøren som systemutviklingsekspert også skal gi nødvendig samarbeid for inspeksjonen. Dette er forklart i detalj i artikkelen nedenfor.
Det er imidlertid mulig at mangler i systemet (juridisk referert til som “feil”) oppdages i inspeksjonsfasen. For juridiske problemer i slike tilfeller, vennligst se detaljene i artikkelen nedenfor.
Innen systemutvikling er “akseptansetest” svært viktig både for brukeren og leverandøren, da det i prinsippet viser at leverandøren har oppfylt sine forpliktelser. For å unngå alvorlige problemer på dette stadiet, bør både bestiller og leverandør ha en god forståelse av “antatt akseptansetest-klausulen”.
Videre, for å forberede seg på en situasjon der akseptansetest ikke går som planlagt, er det viktig at begge parter nøye justerer sine forventninger og forståelse av bestemmelsene knyttet til akseptansetest allerede i kontraktsfasen.
An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.
