MONOLITH LAW OFFICE+81-3-6262-3248Všední dny 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Právní význam omluvy od dodavatele k uživateli v systémovém vývoji

IT

Právní význam omluvy od dodavatele k uživateli v systémovém vývoji

Nejen v oblasti vývoje systémů, ale také v takzvaném sektoru služeb, je reakce na stížnosti od zákazníků nesmírně důležitá. Vývoj systémů není výjimkou, a často se stává, že dodavatelé technických služeb jsou nuceni reagovat na stížnosti uživatelů, kteří jsou zároveň jejich zákazníky.

Pokud se zaměříme na udržení dobré komunikace mezi oběma stranami, může být v některých případech rozumné vyslechnout druhou stranu a omluvit se. Nicméně, někteří lidé mohou mít obavy, že pokud se omluví ústně nebo písemně, může to vést k tomu, že nespravedlivé tvrzení uživatele se stane skutečností.

V tomto článku se zaměříme na “omlouvání se od dodavatele k uživateli” a vysvětlíme, jaký právní význam má taková omluva.

Proč se v oblasti vývoje systémů stává “omlouva” problémem?

Vývoj systémů je druhem služby

Vývoj systémů jako takový, pokud se do něj zapojuje externí dodavatel v rámci outsourcingu, lze považovat za druh “služby pro firmy”. Pokud bychom měli použít právní terminologii, obvykle se uzavírají smlouvy ve formě smlouvy o dílo nebo smlouvy o zastoupení. Rozdíl mezi smlouvou o dílo a smlouvou o zastoupení je podrobně vysvětlen v následujícím článku.

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

Podstatou je, že bez ohledu na typ smlouvy, firma na straně dodavatele generuje tržby na základě svých technických dovedností a pracovní síly (a produktů vytvořených na základě těchto sil). Jelikož obchodní transakce zahrnují výměnu služeb poskytovaných “lidmi” na straně dodavatele a odpovídající odměny, lze říci, že vývoj IT systémů je v zásadě druhem služby.

Uživatelé požadují omluvu, protože jsou “zákazníky”

Jelikož je vývoj systémů službou, je samozřejmě předpokládáno, že uživatelé budou mít stížnosti a reklamace. Současně se od dodavatele vyžaduje schopnost adekvátně reagovat na tyto stížnosti. Je pravda, že v některých případech může být projekt úspěšně dokončen díky tomu, že dodavatel se omluví a reaguje na různé stížnosti a reklamace.

Na druhou stranu, pokud se projekt skutečně zhroutí a situace se dostane až k soudu, uživatel může tvrdit, že “dodavatel uznal svou vinu” na základě omluvy od dodavatele.

Otázka, do jaké míry může uživatel zůstat zákazníkem

Projekt vývoje systémů je obchodní transakce mezi “zákazníkem”, kterým je uživatel, a “externím dodavatelem”, kterým je dodavatel. Avšak smlouvy týkající se vývoje systémů mají složitost, která přesahuje tento vztah. Jinými slovy, uživatel jako zákazník také musí spolupracovat s povinnostmi dodavatele, jinak projekt nemůže být dokončen. Je také upozorňováno na soudní případy, kde je uživatel povinen spolupracovat a obě strany by měly spolupracovat na pokroku projektu.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Při zkoumání právních problémů týkajících se “omlouvy” od dodavatele k uživateli je důležité si uvědomit tuto složitost vztahu. Vztah mezi uživatelem a dodavatelem může být zdravým partnerstvím, ale také může být považován za “jednoho z mnoha dodavatelů”. Problém nespravedlivých požadavků na omluvu se často projevuje, když je zapomenuto na základní předpoklad, že uživatelé také spolupracují a spolupracují na dosažení cílů projektu. Tento bod je specifický pro oblast vývoje systémů, která se v jiných službách často nevyskytuje.

Jak soudy vnímají “omlouvání”

I v případě omluvy ze strany dodavatele může být rozhodnuto, že se nejedná o přiznání odpovědnosti, ale o výhodný krok.

Pojďme se nyní podívat na to, jaký právní význam má omluva dodavatele v soudních sporech týkajících se vývoje systémů.

Případ související s omluvou 1: Požadavek na omluvu od uživatele

V tomto případě, po celonocní práci, když jsme navštívili uživatele, byli jsme obviněni z toho, že jsme smazali data, a po tom, co nás donutili se omluvit, jsme podali omluvný dopis podle názoru uživatele. Avšak soud prohlásil, že v omluvném dopise nebyl skutečný úmysl.

H vytvořil omluvný dopis týkající se této záležitosti, ale byl to dopis vytvořený podle názoru uživatele po tom, co byl po celonocní práci dne 4. října 2001 (Heisei 13) jednostranně a tvrdě obviněn při návštěvě kanceláře žalobce, byl donucen se omluvit a pokusil se uklidnit hněv ředitelů žalobce. Nebyl to skutečný úmysl H, stejně jako úmysl N v omluvném dopise, který N vytvořil.

Verdikt Tokijského okresního soudu ze dne 23. dubna 2004 (Heisei 16)

Je možné říci, že je charakteristické, že soud při rozhodování zohlednil pocity stran, jako je to, že obvinění bylo “jednostranné”, “uklidnění hněvu” a “nebyl to skutečný úmysl”.

Případová studie 2 týkající se omluv: Volba mezi napsáním omluvného dopisu nebo zaplacením 20 milionů jenů

V následujícím případě bylo rozhodnuto, že i když dodavatel souhlasil s napsáním omluvného dopisu za škodu způsobenou koncovému uživateli, mělo by se odlišovat, zda by měla být právní odpovědnost přičítána dodavateli.

Po přijetí výše uvedené zprávy řekl zástupce žalobce: “Je jasné, že společnost E je na vině, tak buď napište omluvný dopis, nebo zaplaťte 20 milionů jenů za vývoj softwaru.” Na tuto žádost reagoval žalovaný tím, že dne 19. ledna (rok Heisei 8, 1996) vytvořil omluvný dopis, ve kterém se omluvil za nepříjemnosti způsobené žalobci v důsledku výskytu výše uvedeného problému.

(…)

Mělo by se předpokládat, že jako prodejce produktů společnosti E udělal vše, co bylo v jeho silách, a nemůže se říci, že žalovaný zanedbal své závazky podle základní smlouvy o prodeji jen proto, že nepodnikl další kroky.

Rozsudek tokijského okresního soudu ze dne 11. července roku Heisei 8 (1996)

Z rozsudku je patrné, že místo toho, aby se zaměřovali na formální aspekty, jako je adresa omluvného dopisu, by měli dát přednost skutečné praxi a určit, kdo by měl nést odpovědnost.

Co je společné pro uvedené soudní případy

Co lze říci z výše uvedených soudních případů je, že i když dodavatel formálně odpověděl na požadavek omluvy, to neznamená, že to v reálném soudním procesu nutně má rozhodující význam. Je pravděpodobné, že skutečnost, že omluva je často prováděna z praktických důvodů pro pokračování v obchodě, bude v soudním procesu řádně zvážena. Spíše než přítomnost nebo nepřítomnost takové formální omluvy, soud by měl posuzovat celkově, berouc v úvahu okolnosti, za kterých byla omluva provedena, nebo kontext, v němž byl napsán omluvný dopis, a jaký druh vztahu byl vytvořen mezi uživatelem a dodavatelem.

Názor, že uživatel má také povinnost spolupracovat s dodavatelem při vývoji systému, je názor, který soud původně prezentoval. V případech, kde se zdá, že existoval dominantní a nátlakový vztah, který by bylo těžké označit za spolupracující mezi uživatelem a dodavatelem, se omluva pravděpodobně stane pouze formální záležitostí.

Pozor, ne vždy je vhodné se bezmyšlenkovitě omluvit

I když v případě soudního sporu omluva sama o sobě často není rozhodujícím důkazem, to neznamená, že byste měli bezmyšlenkovitě omlouvat. Bezmyšlenkovitá omluva může představovat riziko, že vyvolá tvrdohlavý postoj ze strany uživatele, a to i v jednání před soudním řízením. Navíc, pokud soudce v počáteční fázi soudního řízení vytvoří svůj dojem na základě omluvy, může to znamenat, že bude třeba vynaložit mnoho úsilí a času na odstranění nedorozumění. Je také třeba poznamenat, že pokud omluva nejen vyjadřuje lítost, ale také podrobně poukazuje na chyby dodavatele, může to být faktor, který vede k nepříznivému výkladu ve fázi zjišťování skutečností.

Každopádně, je důležité si uvědomit, že i otázky jako řešení stížností a reklamací jsou právními problémy. Měli byste aktivně zvážit využití externích odborníků při řešení otázky, jak a kdy se omluvit.
 

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Zpět na začátek