Hva er den juridiske betydningen av en unnskyldning fra en leverandør til en bruker i systemutvikling?
I tjenesteytende næringer, ikke bare i systemutvikling, er det selvfølgelig viktig å håndtere klager fra kunder. Dette er ingen unntak i systemutvikling, og det er ofte tilfeller der leverandører som tilbyr tekniske tjenester, blir presset til å håndtere klager fra kunder, som er brukere.
Hvis man legger vekt på å opprettholde god kommunikasjon mellom begge parter, kan det være rasjonelt å lytte til den andre partens argumenter og be om unnskyldning. Men det er kanskje noen som har bekymringer om at urimelige krav fra brukersiden kan bli akseptert som etablerte fakta som et resultat av å be om unnskyldning muntlig eller levere en skriftlig unnskyldning.
I denne artikkelen vil vi fokusere på “unnskyldninger gitt fra leverandører til brukere” og forklare hvordan de forstås juridisk.
Hvorfor blir “unnskyldning” et problem på systemutviklingsstedet?
Systemutvikling er en type tjenesteytelse
Først og fremst, når en ekstern leverandør griper inn i arbeidet med systemutvikling gjennom outsourcing, kan det sies at det er en type “tjenesteytelse for bedrifter”. Hvis vi tør å bringe inn juridiske termer, er det vanlig å inngå kontrakter i form av kontrakter eller quasi-delegasjonskontrakter. Forskjellen mellom kontrakter og quasi-delegasjonskontrakter er forklart i detalj i følgende artikkel.
https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]
Poenget med diskusjonen er at uansett hvilken type kontrakt det er, endrer det ikke det faktum at selskapet på leverandørsiden genererer inntekter basert på teknologisk kapasitet og arbeidskraft (og produktene som produseres med denne kraften). Siden handel som tar sikte på utveksling av tjenester levert av “mennesker” som tilhører leverandørsiden og tilsvarende kompensasjon, er systemutviklingsarbeid i prinsippet en type tjenesteytelse.
Brukerne krever unnskyldning fordi de er “kunder”
Siden systemutvikling er en tjenesteytelse, er det selvfølgelig forventet at klager og krav vil bli fremsatt av brukerne. Samtidig vil leverandøren også bli bedt om å kunne håndtere slike krav på en passende måte. Det er sikkert tilfeller der et samarbeidsmiljø blir gjenoppbygd og prosjektet blir ledet til suksess ved at leverandøren høflig håndterer ulike klager og klager, inkludert unnskyldninger.
Men på den annen side, la oss anta en situasjon der saken blir rotet opp til rettssaken hvis prosjektet virkelig mislykkes etterpå. Brukeren kan hevde at “leverandørsiden anerkjenner også årsaken til tilbakeføringen” basert på unnskyldningen fra leverandørsiden.
Problemet med hvor langt brukeren kan være en kunde
Systemutviklingsprosjektet er faktisk en forretningsavtale mellom “kunden” som er brukeren, og “den eksterne leverandøren” som er leverandøren. Men kompleksiteten som ikke passer inn i dette forholdet er en funksjon av kontrakter relatert til systemutvikling. Med andre ord, brukeren som kunde må også samarbeide med leverandørens forpliktelser, ellers vil prosjektet aldri bli fullført. Det er påpekt i tidligere rettsavgjørelser at brukeren også har en viss samarbeidsforpliktelse, og begge parter bør fremme prosjektet i et samarbeidsforhold.
https://monolith.law/corporate/user-obligatory-cooporation[ja]
Når man vurderer juridiske problemer rundt “unnskyldning” fra leverandøren til brukeren, er det viktig å være klar over denne kompleksiteten i forholdet. Forholdet mellom brukeren og leverandøren kan utvikle seg til et likeverdig partnerskap, eller det kan bli sett på som “en av mange leverandører”. Problemet med urimelige unnskyldningskrav blir ofte tydelig når det grunnleggende prinsippet om at brukeren også skal samarbeide og fremme prosjektets prestasjon er glemt. Dette kan sies å være en unik egenskap ved systemutviklingsarbeid, som ikke ofte sees i andre tjenesteytelser.
Hvordan ser retten på ‘beklager’
La oss nå se på hvordan en beklagelse fra en leverandør i en rettssak om systemutvikling faktisk blir behandlet i juridisk forstand.
Rettssak om unnskyldning 1: Krav om unnskyldning fra brukeren
I dette tilfellet, etter en natt med overtid, ble det rettet anklager mot oss om at vi hadde slettet data da vi besøkte brukeren. Etter å ha blitt tvunget til å beklage, leverte vi en unnskyldning i tråd med brukerens argumenter. Imidlertid uttrykte retten synspunktet at det ikke var noen oppriktighet i unnskyldningen som ble gitt der.
H laget en unnskyldning som nevnt i denne saken, men det var etter en natt med overtid, den 4. oktober 2001 (Heisei 13), da han besøkte saksøkers kontor, ble ensidig strengt kritisert, tvunget til å beklage, og deretter fulgte saksøkers krav, først og fremst for å ro ned saksøkers ledelses sinne, og laget det i tråd med deres argumenter. Det var ikke H’s ekte intensjon, og heller ikke N’s unnskyldning var N’s ekte intensjon.
Tokyo District Court, 23. april 2004 (Heisei 16)
Det kan sies at det er karakteristisk at dommen tar hensyn til partenes følelser, som det faktum at kritikken var “ensidig”, “ro ned sinne”, og “ikke ekte intensjon”.
Rettssak om unnskyldning 2: Valget mellom å skrive en unnskyldning eller betale 20 millioner yen
I følgende sak ble det avgjort at selv om en leverandør har gått med på å skrive en unnskyldning for skaden forårsaket til sluttbrukeren, bør dette skilles fra spørsmålet om den juridiske ansvaret skal tilskrives leverandøren.
Etter å ha mottatt den nevnte rapporten, uttalte saksøkerens representant at “det er nå klart at E-selskapet er i feil, så skriv en unnskyldning eller ta på deg kostnadene for programvareutvikling på 20 millioner yen.” I samsvar med denne forespørselen, laget den tidligere saksøkte en “unnskyldning” datert 19. januar samme år, der de beklaget ulempene forårsaket av den nevnte feilen, og overleverte den til saksøkeren.
(…)
Det bør betraktes som om selgeren av E-selskapets produkt har gjort alt som er mulig, og det kan ikke sies at den tidligere saksøkte har forsømt sin forpliktelse basert på den grunnleggende salgskontrakten bare fordi de ikke gjorde mer.
Tokyo District Court, 11. juli, Heisei 8 (1996)
Det kan leses fra domstolsdokumentene at det er en tankegang som identifiserer hvem som skal holdes ansvarlig, med vekt på hvordan virksomheten skal være, snarere enn hvem som skal være mottaker av en formell unnskyldning.
Det som kan sies å være felles for de ovennevnte rettsavgjørelsene
Det som kan sies ut fra de ovennevnte rettsavgjørelsene er at selv om en leverandør formelt har svart på en forespørsel om unnskyldning, betyr det ikke nødvendigvis at det har en avgjørende betydning i en faktisk rettssak. Det faktum at unnskyldninger ofte blir gitt av praktiske grunner for å fremme forretninger og ting, kan betraktes som en omstendighet som vil bli tatt i betraktning i en rettssak. Snarere enn tilstedeværelsen eller fraværet av slike formelle unnskyldninger, bør rettens holdning være å gjøre en helhetlig vurdering, med tanke på omstendighetene rundt unnskyldningen, hvordan unnskyldningsbrevet ble skrevet, og hvilken type menneskelige relasjoner som ble bygget mellom brukeren og leverandøren.
Det er også rettens synspunkt at brukere har en plikt til å samarbeide med leverandøren i systemutvikling. I tilfeller der det er sett på som en dominerende og høytrykksrelasjon der brukeren knapt kan sies å ha vært samarbeidsvillig med leverandøren, vil unnskyldninger sannsynligvis bli behandlet som bare formelle.
Vær forsiktig, det er ikke alltid passende å be om unnskyldning uten videre
Selv om det er sjelden at en unnskyldning i seg selv blir avgjørende bevis i en rettssak, betyr det ikke at du fritt kan be om unnskyldning. En lettvint unnskyldning kan også øke risikoen for å fremkalle en sta holdning fra brukerens side, selv i forhandlinger før en rettssak. I tillegg, hvis en dommer danner et inntrykk basert på unnskyldningen i de tidlige stadiene av en rettssak, bør du være oppmerksom på at det kan ta mye tid og krefter å rette opp misforståelsen. Videre, hvis innholdet i unnskyldningen eller det skrevne innholdet i unnskyldningsbrevet tydelig peker på leverandørens feil, kan det bli et element som fører til en ugunstig tolkning i fasen av faktumfastsettelse.
Uansett, det er viktig å forstå at håndtering av klager og krav i seg selv er et juridisk problem, og du bør aktivt vurdere å bruke eksterne eksperter for å håndtere spørsmålet om hvordan du skal be om unnskyldning.
Category: IT
Tag: ITSystem Development