Den lagliga betydelsen av en ursäkt från leverantören till användaren inom systemutveckling
Inte bara inom systemutveckling, utan även inom så kallade tjänstesektorn, är det självklart viktigt att hantera klagomål från kunder. Även inom systemutveckling är detta inget undantag, och det finns ofta situationer där leverantörer av tekniska tjänster tvingas hantera klagomål från kunder, det vill säga användare.
Om man prioriterar god kommunikation mellan de två parterna, kan det vara rationellt att lyssna på den andra partens argument och be om ursäkt i vissa fall. Men det finns kanske de som har oroat sig för att om de ber om ursäkt muntligt eller lämnar in en skriftlig ursäkt, kan användarens orimliga påståenden bli accepterade som etablerade fakta.
I denna artikel kommer vi att fokusera på “ursäkter från leverantören till användaren” och förklara hur det förstås juridiskt.
Varför blir “ursäkter” ett problem på systemutvecklingsplatsen?
Systemutveckling är en typ av tjänstesektor
Från början, när en extern leverantör ingriper i systemutvecklingsarbetet i form av outsourcing, kan det sägas att det är en typ av “företagstjänst”. Om man vågar ta fram juridiska termer, är det vanligt att kontrakt ingås i form av kontrakt eller quasi-delegationskontrakt. Skillnaden mellan kontrakt och quasi-delegationskontrakt förklaras i detalj i följande artikel.
https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]
Den viktiga punkten i diskussionen är att oavsett vilket kontrakt det är, ändras inte det faktum att företaget på leverantörssidan genererar försäljning baserat på den tekniska förmågan och arbetskraften (och produkterna som produceras mot denna bakgrund). Eftersom det är en affärstransaktion som syftar till att utbyta ersättning för tjänster som tillhandahålls av “människor” som tillhör leverantörssidan, kan man säga att IT-systemutveckling i princip är en typ av tjänstesektor.
Användare kräver ursäkter eftersom de är “kunder”
Eftersom systemutveckling är en tjänstesektor, förväntas det naturligtvis att klagomål och krav kommer att framföras från användarna. Samtidigt kommer förmågan att korrekt hantera sådana krav också att krävas av leverantören. Visst, i praktiken kan det finnas fall där ett samarbetsramverk återuppbyggs och projektet leds till framgång genom att leverantören svarar på olika krav och klagomål med en ursäkt, etc.
Å andra sidan, låt oss anta en situation där projektet verkligen misslyckas senare och ärendet blir invecklat tillräckligt för att gå till rättegång. Användaren kan hävda att “leverantören erkänner också orsaken till skulden” på grundval av ursäkten från leverantören.
Frågan om hur långt användaren kan vara en kund
Systemutvecklingsprojektet är verkligen en affärstransaktion som äger rum mellan “kunden” som användare och “extern leverantör” som leverantör på en sida. Men komplexiteten som inte passar in i detta förhållande är en egenskap hos kontraktet relaterat till systemutveckling. Det vill säga, användaren som kund måste också samarbeta med leverantörens skyldigheter, annars kan projektet inte slutföras. Det har påpekats i tidigare rättsfall att användaren också har en viss skyldighet att samarbeta och att båda parter bör gå framåt i projektet i ett samarbetsförhållande.
https://monolith.law/corporate/user-obligatory-cooporation[ja]
När man överväger juridiska frågor kring “ursäkter” från leverantören till användaren är det viktigt att erkänna denna komplexitet i förhållandet. Förhållandet mellan användaren och leverantören kan utvecklas till ett hälsosamt partnerskap, eller det kan ses som “en av många leverantörer”. Problemet med orättvisa ursäkter uppstår ofta när den grundläggande premissen att användaren också ska samarbeta och sträva efter att uppnå projektet, vilket är en laglig skyldighet, glöms bort. Detta kan sägas vara en egenskap som är unik för systemutvecklingsarbetet, som inte ses mycket i andra tjänstesektorer.
Hur ser domstolen på “ursäkter”
Låt oss nu faktiskt titta på hur en ursäkt från en leverantör i en rättegång om systemutveckling behandlas i laglig mening.
Rättsfall kring ursäkter 1: Begäran om att be om ursäkt från användaren
I detta fall, efter att ha arbetat hela natten och besökt användaren, blev det kritiserat att data kan ha raderats, och efter att ha blivit tvingad att be om ursäkt, lämnades en ursäkt i enlighet med användarens argument. Men domstolen uttryckte uppfattningen att det inte fanns någon verklig avsikt i ursäkten där.
H skapade en ursäkt som nämner denna punkt, men det var efter att ha arbetat hela natten, den 4 oktober, Heisei 13 (2001), när han besökte den klagande advokatbyrån, han blev ensidigt starkt kritiserad, och efter att ha blivit tvingad att be om ursäkt, följde han klagandens begäran, för att tillfälligt lugna klagandens styrelsemedlemmars ilska, det skapades i enlighet med deras argument, det var inte H:s verkliga avsikt, och likaså var syftet med ursäkten som N skapade inte N:s verkliga avsikt.
Tokyo District Court, 23 april, Heisei 16 (2004)
Det kan sägas att det är karakteristiskt att domen tar hänsyn till parternas känslor, såsom att kritiken var “ensidig”, “lugna ilska”, och “inte den verkliga avsikten”.
Rättsfall kring ursäkter 2: Valet mellan att skriva ett ursäktbrev eller betala 20 miljoner yen
I följande fall beslutades det att även om en leverantör har gått med på att skriva ett ursäktbrev för skadan som orsakats slutanvändaren, bör detta skiljas från frågan om den juridiska ansvaret bör tillskrivas leverantören.
Efter att ha mottagit rapporten, sa företrädaren för käranden, “Nu är det klart att E-företaget är skyldigt, så skriv ett ursäktbrev eller ta på dig kostnaden för att utveckla programvaran, 20 miljoner yen.” Svaranden följde denna begäran och skapade ett “ursäktbrev” den 19 januari samma år, där de bad om ursäkt för besväret som orsakats käranden på grund av felet.
(Utelämnat)
Det bör anses att de har gjort allt de kan som säljare av E-företagets produkter, och det kan inte sägas att svaranden har försummat sina skyldigheter enligt grundavtalet för försäljningen bara för att de inte gjorde mer.
Tokyo District Court, 11 juli 1996 (Heisei 8)
Det framgår av domen att det inte handlar om vem som ska adresseras i ett formellt ursäktbrev, utan snarare om att prioritera hur verksamheten bör vara och att identifiera vem som bör hållas ansvarig.
Gemensamt för ovanstående rättsfall
Det som kan sägas utifrån ovanstående rättsfall är att även om en leverantör formellt svarar på en begäran om ursäkt, betyder det inte nödvändigtvis att det har en avgörande betydelse i en verklig rättegång. Anledningen till att en ursäkt görs är ofta bara för bekvämlighetens skull för att driva affärer framåt, vilket kan vara en omständighet som noggrant övervägs i rätten. Snarare än förekomsten av sådana formella ursäkter, bör domstolens ståndpunkt ses som att göra en övergripande bedömning baserat på omständigheterna kring ursäkten, som hur relationen mellan användaren och leverantören har byggts upp.
Åsikten att användaren också har en skyldighet att samarbeta med leverantören i systemutveckling är en synpunkt som domstolen ursprungligen har framfört. I fall där det anses ha funnits en dominerande och högtrycksrelation där användaren knappast kan sägas ha varit samarbetsvillig mot leverantören, kommer ursäkten sannolikt att behandlas som bara en formalitet.
Var försiktig, det är inte alltid lämpligt att lättvindigt be om ursäkt
Även om det är sällsynt att en ursäkt i sig blir avgörande bevis i en rättegång, betyder det inte att det är lämpligt att lättvindigt be om ursäkt. En ogenomtänkt ursäkt kan också innebära en risk att framkalla en envis attityd från användarens sida, även i förhandlingar innan rättegången. Dessutom, om en domare formar sin uppfattning kring en ursäkt i de tidiga stadierna av en rättegång, kan det kräva mycket tid och ansträngning att rätta till missförstånd. Det bör också noteras att om innehållet i en ursäkt eller en ursäktsskrivelse tydligt pekar på leverantörens fel, kan det bli en faktor som leder till en ogynnsam tolkning vid fastställandet av fakta.
Hur som helst, med förståelsen att problem som klagomålshantering och reklamationshantering i sig är juridiska frågor, bör man aktivt överväga att använda externa experter för att ta reda på hur man bör be om ursäkt.
Category: IT
Tag: ITSystem Development