Vad är åtgärderna om ett systemfel upptäcks efter godkännandet?

Systemutveckling, i allmänna termer, innebär att programimplementeringen fortskrider enligt innehållet som bestämdes i kravspecifikationsfasen, och slutligen kontrollerar både användare och leverantör om det har blivit färdigt enligt specifikationerna, och avslutas med godkännande av accepttestet.

Men i verkligheten kan det mycket väl hända att buggar och fel som inte kunde upptäckas vid testfasen och godkännandet av accepttestet, uppdagas under den efterföljande driftsfasen. Om du har accepterat leveransen en gång, vad kan du juridiskt begära?

Det är inte ovanligt att buggar kvarstår även efter godkänd inspektion eller testprocess

Ur ett tekniskt perspektiv är det inte alls ovanligt att olika buggar och problem upptäcks efter att leverantörens olika testprocesser har slutförts och användarens inspektion har godkänts. Det som användaren normalt gör under inspektionsprocessen är främst att kontrollera in- och utdata som kan bekräftas från skärmen. Men, IT-system har ofta en komplex och detaljerad struktur i databasen bakom och i de olika programmen som styr beräkningar och kontroller, mer än vad som kan ses på skärmen från användarens sida. Därför finns det en inneboende gräns för vad som kan undersökas från användarens perspektiv genom att kontrollera in- och utdata på skärmen. Således är det inte realistiskt att genom en kontroll helt och hållet verifiera alla potentiella problem som kan uppstå i den efterföljande driftsfasen.

Sammanhanget ovan gäller även när man ser det från leverantörens perspektiv, som ansvarar för utvecklingsarbetet. Till exempel är “testprocessen” för att kontrollera om det finns några buggar eller problem i det implementerade programmet. Men även i testprocessen är det inte alltid möjligt att helt och hållet verifiera alla potentiella buggar och problem. Även efter att det utvecklade systemet har börjat användas fullt ut i verksamheten, krävs det utmärkt teknisk förmåga att skapa ett system som fortsätter att fungera utan problem, även när operationer som leverantören inte förutsett utförs, eller när stora mängder data faktiskt börjar registreras, eller när flera användare börjar få tillgång samtidigt.

Det är viktigt att förstå att det inte är realistiskt att upptäcka alla buggar och problem i steg som inspektion och testning, och att olika problem kan upptäckas när man faktiskt börjar använda IT-systemet.

Skulden anses normalt vara uppfylld

Så hur bör man hantera sådana problem när de faktiskt uppstår? Låt oss gå igenom det i enlighet med den juridiska ordningen.

Först och främst, om olika buggar och problem upptäcks efteråt, skulle användaren vilja hålla leverantören, som de har anlitat för arbete hittills, ansvarig på något sätt. Men vanligtvis, om leveransen redan har slutförts och godkänts, är det ofta svårt att hålla leverantören ansvarig för kontraktsbrott.

I grunden gäller bestämmelserna i den japanska civilrätten (Japanese Civil Code) om entreprenadavtal för systemutvecklingskontrakt, om inget speciellt avtal har upprättats. Vi har förklarat i detalj vad ett entreprenadavtal är i följande artikel.

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

Och i ett entreprenadavtal blir “slutförandet av arbetet” ett krav för att uppfylla skulden. Vi har förklarat i detalj vad “slutförandet av arbetet” specifikt innebär i följande artikel.

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

Här förklarar vi att “slutförandet av arbetet” i ett entreprenadavtal, i sammanhanget av systemutveckling, innebär att hela utvecklingsprocessen är avslutad, enligt tidigare rättsfall. Och vi förklarar att problem som buggar och fel som uppstår efter att hela utvecklingsprocessen har avslutats blir en fråga om ansvar för dolda fel i entreprenadavtalet.

För att sammanfatta, om leveransen har accepterats och godkänts, antas skulden redan vara uppfylld, och frågan blir normalt om kvalitetsgarantin efteråt, det vill säga möjligheten att hålla leverantören ansvarig för dolda fel.

Följa upp ansvar baserat på felgaranti

Så, när du begär åtgärder från en leverantör baserat på felgaranti, vad ska du överväga och i vilken ordning? Låt oss gå igenom det nedan.

Först, bekräfta allvaret och omfattningen av buggar och fel

När buggar och fel upptäcks efteråt och du begär någon form av garanti för att det är en juridisk “defekt”, blir allvaret av buggen eller felet ett problem. Juridiska defekter kan i grunden delas in i tre kategorier:

1. Även om det kan kallas en bugg eller ett fel, är det bara en mindre sak och kan inte kallas en juridisk “defekt”.
2. Det är en juridisk “defekt”, men det är fortfarande möjligt att uppnå kontraktets syfte.
3. Det är en juridisk “defekt”, och det är inte möjligt att uppnå kontraktets syfte.

Det som skiljer om du kan följa upp ansvar baserat på felgaranti är gränsen mellan 1 och 2, och det som skiljer om du kan avsluta kontraktet baserat på felgaranti är gränsen mellan 2 och 3.

Artikel 634

1. När det finns en defekt i objektet för arbetet, kan beställaren begära att entreprenören reparerar defekten inom en rimlig tid. Dock gäller detta inte om defekten är obetydlig och reparationen kräver orimliga kostnader.

2. Beställaren kan begära skadestånd istället för eller tillsammans med reparation av defekten. I detta fall tillämpas bestämmelserna i artikel 533.

Artikel 635

När det finns en defekt i objektet för arbetet och det på grund av detta inte är möjligt att uppnå kontraktets syfte, kan beställaren avsluta kontraktet. Dock gäller detta inte för byggnader eller andra markarbeten.

För mer information om dessa stegvisa distinktioner av “defekter”, se följande artikel.

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

Nästa, klargör vad du ska begära från leverantören

Nästa steg är att klart definiera vad du ska begära från den andra parten. Om du vill avsluta kontraktet, räcker det inte att bara bevisa att det är en defekt, det måste vara något som “inte kan uppnå kontraktets syfte”. Vid bedömningen av “syftet” här är mötesprotokoll från initiala systemutvecklingsprojektmöten och specifikationer viktiga ledtrådar. Eftersom det kan hända att buggar och fel upptäcks efter godkännande, bör du noggrant behålla alla dokument även efter att utvecklingsprojektet är avslutat.

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

Förutom uppsägning, kan du begära skadestånd och reparation av defekter som en del av felgarantiansvaret.

Övriga punkter att notera

Var försiktig med hur du genomför juridiska åtgärder som att avsluta ett kontrakt

Om du ska avsluta ett kontrakt som en del av ansvaret för fel och brister, bör du också lära dig hur du genomför de juridiska procedurerna för att göra detta. Vi har detaljerade förklaringar om effekterna av att avsluta ett kontrakt, hur man uttrycker sin vilja effektivt och hur man meddelar på ett sätt som inte leder till problem i framtiden i följande artikel.

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

Det är bättre att lösa problem genom förhandlingar snarare än tvister

Dessa juridiska argument är inte bara meningsfulla när en rättegång uppstår. Tvistlösning genom rättegång är en stor belastning för båda parter. Tvärtom, denna kunskap bör utnyttjas i förhandlingsstadiet innan en rättegång. Vi förklarar hur denna juridiska kunskap kan vara meningsfull i förhandlingar utanför rättegången i följande artikel.

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

Det är viktigt att skilja mellan buggar och fel, och brist på funktioner

Om det finns buggar eller fel i de funktioner eller specifikationer du har implementerat, eller om du helt enkelt saknar nödvändiga funktioner, kommer diskussionen att vara annorlunda. Om de nödvändiga funktionerna inte finns, kanske “jobbets slutförande” i kontraktet inte erkänns, och du kanske inte erkänns för att ha uppfyllt dina skyldigheter.

Även om de nödvändiga funktionerna eller specifikationerna saknas, om användaren inte har tillhandahållit lämplig information under kravspecifikationsstadiet, kan det vara olämpligt att betrakta det som en del av kontraktet i första hand.

Sammanfattning

Problem som uppstår under ett projekts gång kan upptäckas antingen under projektets gång eller efteråt, till exempel under driftfasen. Det verkar som att en av de unika egenskaperna hos systemutvecklingsprojekt, där man inte nödvändigtvis kan känna sig trygg även efter att alla steg har slutförts framgångsrikt, symboliseras av systemet med “felgaranti ansvar” (Japanese “瑕疵担保責任”). Det anses viktigt att ha en noggrann dokumenthantering med tanke på vad som kan hända efter att systemutvecklingsprojektet är avslutat, samt att förstå hela denna process.