Vad innebär slutförandet av arbete i systemutvecklingskontrakt

Systemutveckling är vanligtvis en långvarig process, och det kan hända att man flera gånger om blir ombedd att ändra specifikationer eller implementera ytterligare funktioner. Detta kan ibland leda till att leverantörer som tar på sig jobbet hamnar i en svår situation där de inte kan se en utväg. För sådana leverantörer kan frågan “Vad och hur mycket behöver vi göra för att anse att vi har slutfört vårt jobb?” ibland bli en verklig källa till bekymmer.

Och systemutveckling utförs ofta på basis av ett kontrakt, vilket är ett avtal som syftar till att “slutföra jobbet”.

I denna artikel kommer vi att förklara juridiskt sett, vid vilken tidpunkt och efter att ha slutfört vad och hur mycket, anses systemutvecklingen vara slutförd.

Vad innebär det att systemutveckling är klar?

Vad systemutveckling innebär för tekniker

I systemutvecklingsmiljön, om du frågar “När är systemutvecklingen klar?”, skulle svaret generellt vara “När testprocessen är klar och produkterna har levererats”. Visst, den allmänna flödet av systemutveckling börjar med kravdefinition, där man identifierar funktioner som ska implementeras, skapar olika design dokument, går vidare till programimplementering, och slutligen avslutas med en testprocess för att bekräfta att systemet fungerar korrekt. Det hela avslutas med användarens godkännande.

Därför, ur teknikernas perspektiv som är direkt involverade i det konkreta arbetet, är det vanligt att förstå “systemutvecklingens slutförande = godkännande”.

Vad systemutveckling innebär ur ett juridiskt perspektiv

Å andra sidan, om du frågar när systemutvecklingen är klar ur ett juridiskt perspektiv, diskussionen kommer naturligtvis att fokusera på när leverantörens juridiska skyldigheter enligt kontraktet har uppfyllts. I grunden kan systemutvecklingskontrakt klassificeras som antingen kontrakt eller quasi-kommission kontrakt.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Jag kommer att lämna förklaringen av skillnaderna mellan dessa två typer av kontrakt till artikeln ovan, men när det gäller slutförandet av systemutveckling, det vill säga uppfyllandet av leverantörens skyldigheter, är de kriterier som används för att bedöma detta som följer:

Kontrakt: Civil Code §632
§632
Kontraktet träder i kraft när en part avtalar att slutföra ett visst arbete och den andra parten avtalar att betala för resultatet av detta arbete.
Quasi-kommission kontrakt: Civil Code §648
§648
1. Om det inte finns något särskilt avtal, kan uppdragstagaren inte begära betalning från uppdragsgivaren.
2. Uppdragstagaren kan inte begära betalning förrän efter att uppdraget har utförts. Om betalningen har fastställts enligt en tidsperiod, gäller bestämmelserna i §624.2.
3. Om uppdraget avslutas mitt i utförandet på grund av omständigheter som inte kan tillskrivas uppdragstagaren, kan uppdragstagaren begära betalning i proportion till det arbete som redan har utförts.

Systemutvecklingens slutförande är ett problem i kontrakt

Men, oavsett kontexten för systemutveckling, är det i grunden kontrakt där frågan “när arbetet är klart” blir ett problem. I fallet med quasi-kommission kontrakt, snarare än att uppfylla skyldigheter genom att leverera ett specifikt resultat eller produkt, är det mer av ett kontrakt där en person med expertis, med viss diskretion, gör vad som är lämpligt (oavsett resultatet). Även i lagtexten för quasi-kommission kontrakt, även om det förväntade resultatet inte har uppnåtts, om affärsprocessen har hanterats korrekt, är det möjligt att begära betalning (§648.2), och om utförandet avslutas mitt i på grund av omständigheter som inte kan tillskrivas uppdragstagaren, är det möjligt att begära betalning i proportion till det arbete som redan har utförts (§648.3). Kontrakt fokuserar på “resultat”, medan quasi-kommission kontrakt fokuserar på “process”.

Därför, i quasi-kommission kontrakt, är det snarare “skyldigheten att vara försiktig” i processen att utföra det uppdragade arbetet som tenderar att bli ett juridiskt problem. Det vill säga, när det finns en hög grad av förtroende, frågan är när man kan utmana överträdelsen av skyldigheten att vara försiktig baserat på ett uppdragskontrakt.

Å andra sidan, i kontrakt är det viktigt att “arbetet är klart”. Om det arbete som ska slutföras inte är klart, kan leverantören inte uppfylla sina skyldigheter, och det är principen att de inte kan begära betalning. Men om arbetet är klart, finns det ingen mening med att ifrågasätta delar av processen längs vägen. Därför kan frågan “när är systemutvecklingsprojektet klart?” i grunden omformuleras som en fråga om juridisk tolkning av frasen “arbetet är klart” i kontrakt.

När anses ett arbete vara slutfört inom systemutveckling?

Så när bör vi konkret betrakta tidpunkten för ett “slutfört arbete”? Låt oss granska tidigare rättsfall i detta avseende.

Rättsfall kring slutförandet av arbete

I det rättsfall som citeras nedan upptäcktes problem med bearbetningshastighet och kommunikationskostnader etc. i det system som leverantören levererade. Trots att dessa problem upptäcktes, var utvecklingsprocessen i sig helt klar, och det diskuterades om det kunde kallas ett “slutfört arbete”. Resultatet var att arbetet ansågs vara slutfört.

Enligt artiklarna 632 och 633 i den japanska civilrätten (Japanska Civilrätten), ska betalning av ersättning till beställaren från entreprenören ske när entreprenören har slutfört arbetet och överlämnat arbetsobjektet till beställaren. Å andra sidan, enligt artikel 634 i samma lag, om det finns brister i arbetsobjektet, har entreprenören en garantiplikt mot beställaren (paragraf 1), och beställaren har rätt att invända mot samtidig prestation av betalning av ersättning tills entreprenören har uppfyllt sin garantiplikt för bristerna i arbetsobjektet (paragraf 2). Enligt dessa bestämmelser i civilrätten, skiljer lagen mellan fall där arbetsresultatet är ofullständigt, dvs. fall där det finns brister i arbetsobjektet och fall där arbetet inte är slutfört, och det förstås att även om det finns brister i arbetsobjektet, oavsett om de är dolda eller uppenbara, anses inte arbetet vara ofullständigt på grund av detta.
Därför, när det gäller om entreprenören har slutfört arbetet eller inte, bör det bedömas utifrån om arbetet har slutförts till den sista processen som ursprungligen planerades i kontraktet, och det är rimligt att förstå att beställaren inte kan vägra att betala kontraktspriset enbart på grund av att det finns brister i arbetsobjektet när entreprenören har slutfört det sista arbetet och överlämnat arbetsobjektet.

I ovanstående dom ansågs “slutförandet av arbetet” uppfyllas om den sista processen i systemutvecklingen var klar. Som en lösning på problemen med bristerna (ofta kallade “fel” i lagliga termer) i systemet som leverantören har skapat, finns det redan ett separat system för garantiansvar för fel.

Därför, även om konceptet “slutförandet av arbetet” tolkas något bredare, kommer det i slutändan inte att resultera i orättvisa för användaren. Sammanfattningsvis är det som följer.

【Skuld i kontrakt = Slutförandet av arbete = Fullbordandet av alla processer】
========
Om arbetet inte är slutfört…
↓
【Ansvar för icke-prestation av skuld】
========
Även om arbetet är slutfört men det finns brister…
↓
【Erkännande av prestation av skuld, fråga om garantiansvar för fel】

Ovanstående rättsfall visar hur man ska dela upp problemen.

Det bör dock noteras att “slutförandet av arbetet” kan undersökas utifrån perspektivet av “godkännande av användarens inspektion”. Juridiska problem när användarens inspektion inte går smidigt förklaras i en separat artikel.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Vad det innebär att ett juridiskt arbete är slutfört

I systemutveckling, om “arbetsfärdigställande” erkänns, anses skulden ha uppfyllts, vilket innebär att du inte längre kan bli föremål för ansvar för “icke-uppfyllande” av skulden. I ett entreprenadkontrakt, om arbetet inte kan anses vara slutfört, kan du inte begära betalning, och även om du har ingått en särskild överenskommelse om förskottsbetalning, måste dessa i grunden återbetalas. Å andra sidan, om det erkänns att arbetet är slutfört, innebär det att leverantören kan ta på sig frågor om garanti för defekter och kvalitetsgarantier enligt kontraktet.

Att leverantören befrias från ansvar för icke-uppfyllande av skulden innebär att möjligheten att användaren avbryter kontraktet minskar dramatiskt. Detta beror på att avbrytande av kontraktet baserat på ansvar för defektgaranti är begränsat till fall där kontraktets syfte inte kan uppnås. Om kontraktet avbryts, förlorar leverantören också rätten att begära betalning (det vill säga, i enkla termer, ingen betalning kommer in alls), vilket ofta leder till tvister kring “arbetsfärdigställande” i praktiken.

För en mer detaljerad förklaring av “avbrytande” av kontrakt i systemutveckling, se följande artikel.

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

Observera vid slutförandet av arbetet

Hur man ser på specifikationsändringar och ytterligare utveckling

Det kan hända att leverantören står inför en situation där de redan har uppfyllt de ursprungliga specifikationerna, men krävs på ändringar av specifikationer eller tillägg av funktioner, och trots att de försöker avsluta arbetet, finns det ingen tydlig avslutning. I sådana fall uppstår problem som “när man ska avsluta systemutvecklingen”. En detaljerad förklaring av detta finns i följande artikel.

https://monolith.law/corporate/increase-of-estimate[ja]

Var uppmärksam på ändringar i civilrätten (Japansk civilrätt)

Bestämmelserna om felansvar baserade på kontraktsavtal är ett område som starkt påverkas av ändringar i civilrätten, eftersom sambandet mellan tidigare paragrafer ofta har varit komplicerat och svårt att förstå. I samband med ändringarna i civilrätten finns en detaljerad förklaring av hur man ska tolka “fel” i följande artikel.

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

Sammanfattning

I denna artikel har vi diskuterat vägen till att koppla systemutvecklingsprojekt, som ofta kan driva en till en situation där “det inte finns någon synlig utgång”, till den juridiska teorin om “arbetsfärdigställande”. Utgången för varje projekt kan variera beroende på utvecklingskraven, men när en tvist uppstår kring dessa punkter, tror vi att det inte är ovanligt att konceptet “arbetsfärdigställande” enligt lag blir en ledtråd.