Vad är tillämpningsområdena för godkännande och antagna godkännandeklausuler i systemutveckling?

Ett skede där juridiska problem lätt kan uppstå inom systemutveckling är “acceptanstestning”.

“Acceptanstestning” hänvisar till inspektions- och kontrollskyldigheten som uppstår för beställaren när leverantören levererar resultatet. Om beställaren inte genomför “acceptanstestning” efter leverans, oavsett hur lång tid det tar, kommer leverantören, dvs. leverantören, att hamna i en juridiskt osäker position.

För att lösa sådana problem innehåller kontrakt ofta en klausul om “presumerad acceptans”.

I denna artikel kommer vi att förklara när “presumerad acceptans” tillämpas, baserat på faktiska rättsfall.

Vad innebär godkännande i systemutveckling?

Först och främst, i ett systemutvecklingsprojekt, innebär “godkännande” att användaren, som är beställaren, inspekterar och kontrollerar om det arbete (här syftar vi på IT-systemet) som leverantören har levererat uppfyller de specifikationer som motsvarar det syfte för vilket det beställdes.

Ur utvecklarens perspektiv kan det ses som en “kontroll för att se om det verkligen är färdigt”, och kan placeras i samma kategori som testprocessen.

Arbetet med att utveckla ett IT-system har, på grund av dess arbetsnatur, en stor grad av diskretion från leverantörens sida, vilket kan leda till skillnader mellan den faktiska produkten och vad användaren har efterfrågat.

Generellt sett, innebär godkännande att användaren själv har bekräftat att det arbete som faktiskt har levererats överensstämmer med vad användaren efterfrågade (eller det syfte för vilket systemutvecklingen begärdes).

I praktiken, även om det är möjligt att det kan upptäckas fel i systemet efteråt, är det vanligt att godkännande ställs som ett villkor för betalning av ersättning.

Var försiktig med klausuler om antagen godkännande

När problem uppstår under godkännandefasen kan både användare och leverantörer hamna i besvärliga situationer.

Till exempel, vad händer om leverantören har skapat ett resultat, redan presenterat det, men på grund av omständigheter hos den ansvarige på användarsidan, inte godkänner det?

För att förbereda för sådana situationer, kan det i systemutvecklingskontrakt ofta finnas en klausul som kallas “antagen godkännandeklausul”.

Vad är en presumtiv godkännandeklausul?

(Godkännande av den aktuella mjukvaran) Artikel 28
För den aktuella mjukvaran bland levererade varor, ska part A inspektera den baserat på inspektionsspecifikationerna i föregående artikel inom den period som anges i det individuella kontraktet (hädanefter kallad “inspektionsperioden”) och kontrollera om systemets specifikationer och den aktuella mjukvaran överensstämmer.

2. Om den aktuella mjukvaran uppfyller inspektionen i föregående stycke, ska part A underteckna och stämpla godkännandecertifikatet och överlämna det till part B. Dessutom, om den aktuella mjukvaran inte klarar inspektionen i föregående stycke, ska part A snabbt överlämna ett skriftligt dokument till part B som klart anger den specifika orsaken till underkännandet och begära korrigeringar eller kompletteringar. När orsaken till underkännandet erkänns, ska part B korrigera det utan kostnad inom den överenskomna tidsfristen och leverera det till part A, och part A ska genomföra inspektionen som anges i föregående stycke igen i den omfattning som krävs.

3. Även om ett godkännandecertifikat inte utfärdas, om part A inte uttrycker några invändningar genom att klart ange en specifik orsak skriftligen inom inspektionsperioden, kommer den aktuella mjukvaran att anses ha klarat inspektionen enligt denna artikel.

4. Godkännandet av inspektionen enligt denna artikel ska betraktas som fullbordandet av godkännandet av den aktuella mjukvaran.

https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf

Notera att juridiskt sett är uttrycket “anses vara” i paragraf 3 en punkt som bör uppmärksammas. Om man ser på det som en juridisk term, har “anses vara” och “presumeras vara” faktiskt helt olika betydelser.

Anses vara…
→Även om det faktiskt inte är XX, behandlas det som om det vore XX enligt lagen

(Exempel) Om du använder en smartphone under ett test, “anses” det vara fusk
→Oavsett om det du faktiskt gjorde med din smartphone var fusk eller inte, kommer samma åtgärder att vidtas som om det var fusk.

Presumeras vara…
→Om det inte finns några bevis som förnekar att det är XX, behandlas det som ett faktum.

(Exempel) Om du tittar på en smartphone under ett test, “presumeras” det vara fusk
→Det antas i princip att det har förekommit fusk, men om du kan motbevisa att det var för ett annat ändamål, kan det beslutet ändras i efterhand. (Det är dock osannolikt att du skulle höra ett sådant meddelande på en testplats.)

Med andra ord, tröskeln för att vända “presumeras vara” och “anses vara” är enormt olika. Det innebär att “oavsett om det faktiskt har godkänts eller inte, kommer det att behandlas på samma sätt som om det hade godkänts”.

Rättsfall relaterade till “presumtionsklausul”

Det finns tidigare fall där “presumtionsklausulen” har spelat en avgörande roll i domstol. Till exempel, i det följande citerade domslutet, inledde användaren en rättegång, hävdande att de nödvändiga funktionerna inte hade implementerats efter att de inte hade godkänt leveransen inom den angivna tidsperioden. Men domstolen beslutade, baserat på “presumtionsklausulen”, att leveransen redan hade slutförts.

I detta kontrakt, var det bestämt att företaget Y, efter leverans av systemet, skulle inspektera det utan dröjsmål och meddela godkännandet skriftligen inom 10 dagar. Om ingen anmälan görs inom denna period, anses det att godkännandet har getts. Därför kan det inte erkännas att det fanns någon anmälan om icke-konformitet i denna inspektion, och det kan fastställas att leveransen och godkännandet har ägt rum.

Tokyo District Court, 29 februari 2012 (Heisei 24)

Å andra sidan finns det också rättsfall där, trots att denna “presumtionsklausul” var på plats, dess tillämpning förnekades och leverantörens kontraktsbrott erkändes.

Det följande citerade domslutet skiljer sig från det tidigare rättsfallet i att leverantören hade försummat att samarbeta, trots att detta var nödvändigt för att genomföra inspektionen.

Klaganden (leverantören) hävdar att eftersom svaranden (användaren) inte meddelade inspektionsresultatet inom 10 dagar från leveransdatumet för resultatet, anses det enligt artikel 9.4 i detta mjukvaruutvecklingskontrakt att resultatet har godkänts. Men för att detta ska kunna ske, är det nödvändigt med klagandens samarbete. Eftersom klaganden inte har samarbetat med svaranden för denna inspektion, kan det inte anses att svaranden har godkänt mjukvaran enligt artikel 9.4 i detta mjukvaruutvecklingskontrakt, bara för att svaranden inte meddelade inspektionsresultatet inom 10 dagar från leveransdatumet för resultatet.

Tokyo District Court, 23 juni 2004 (Heisei 16)

Det antas att syftet med “presumtionsklausulen” är att snabbt frigöra leverantören från en osäker position där “trots att de vill gå vidare med godkännandet snabbt, kan de inte göra det på grund av användarens ensidiga omständigheter, vilket leder till att arbetet stagnerar”, och att upprätthålla en rättvis relation mellan parterna.

Därför kan man inte säga att “vi ska använda ‘presumtionsklausulen’ som en sköld, försöka vinna tid och skjuta upp godkännandet, och bara trycka på även om det är en defekt produkt”.

Om det anses att godkännandet har getts, måste användaren betala ersättning för systemutvecklingen. Med tanke på denna allvarliga aspekt, antas det att domstolen strävar efter att göra en rättvis bedömning genom att ta hänsyn till leverantörens samarbetsstatus.

Protokoll som följer framstegen i systemutvecklingen kan vara viktiga bevis för att stödja sådana bedömningar, inte bara kontraktet. Detaljer om detta finns i följande artikel.

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

För mer information om vilka omfattande skyldigheter leverantören har som expert på systemutveckling för projektet, se följande artikel.

Även om godkännandet i princip bör utföras av användaren, bör leverantören, som expert på systemutveckling, samarbeta på olika sätt med godkännandet. Med tanke på innehållet i följande artikel, kommer detta att vara en naturlig slutsats.

https://monolith.law/corporate/project-management-duties[ja]

Mönster där brister upptäcks vid godkännande

Visserligen kan det hända att brister i systemet (i juridiska termer ofta kallade “fel”) upptäcks vid godkännandefasen. För juridiska frågor i detta fall, se följande artikel för mer information.

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

Sammanfattning

I systemutveckling är “acceptanstestning” i princip ett tecken på att leverantörens skyldigheter har fullgjorts, vilket gör det mycket viktigt för både användaren och leverantören. För att undvika allvarliga problem här, bör både beställaren och leverantören ha en god förståelse för “deemed acceptance clause” (den japanska “måste-acceptera-klausulen”).

Om acceptanstestningen inte går smidigt, är det viktigt att båda parter noggrant samordnar sina förväntningar på bestämmelserna som rör acceptanstestning redan från kontraktsstadiet, särskilt i händelse av en eventualitet.