Právní význam manažerských a kvantitativních cílů v projektech na vývoj systémů

Projekty vývoje systémů jsou často úzce spojeny s rozsáhlými zlepšeními v podnicích a pracovištích. V tomto kontextu může být požadováno, aby se přispívalo k řešení podnikatelských problémů na straně uživatelů nebo k dosažení kvantitativních cílů. Ale je skutečně naším právním závazkem se zavázat k těmto podnikatelským cílům? Otázkou se stává, jaký právní význam mají kvantitativní cíle a podnikatelské cíle. V tomto článku se budeme zabývat právními problémy spojenými s různými “cíli” a “cíli” vývoje systémů.

Proč se cíle a cíle vývoje systému stávají zdrojem konfliktu?

Je to problém, který se nachází mezi povinností uživatele spolupracovat a omezenou pravomocí dodavatele

Pokud se na to podíváme z hlediska obchodních transakcí, projekty vývoje systému mají několik charakteristických rysů. Jedním z nich je, že samotný projekt vývoje systému dodavatelem není něco, co by mohl dodavatel provést sám, ale vyžaduje spolupráci ze strany uživatele. Tato povinnost je jasně definována v judikatuře pod názvem “povinnost spolupráce”. Hlavně v fázích jako jsou ①definice požadavků ②základní návrh ③přijetí výsledků, se od uživatele vyžaduje, aby se podílel na vývoji systému.

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

Dalším bodem je, že se od dodavatele obvykle vyžaduje, aby významně uplatnil své uvážení při provádění svých úkolů. Existuje právní termín “povinnost řízení projektu”, který shrnuje to, co by měl dodavatel udělat v rámci celého projektu vývoje systému. O tomto tématu se podrobněji dočtete v následujícím článku.

https://monolith.law/corporate/project-management-duties[ja]

Když shrneme výše uvedené, můžeme poukázat na dvě důležité body.

• Uživatel je v praxi požadován, aby poskytoval dodavateli příslušné informace a podporoval jeho vývojové práce.
• Dodavatel je v praxi požadován, aby porozuměl cílům a cílům projektu pro uživatele a podnikal kroky, které jsou v souladu s těmito cíli.

V důsledku těchto dvou okolností se stává problémem, do jaké míry se dosažení obchodních a kvantitativních cílů, které byly předem uvedeny uživatelem, může stát povinností dodavatele. Jinými slovy, zatímco je na straně uživatele povinnost shrnout to, co by měl dodavatel udělat (ne něco nejasného jako cíle), do specifikací a předložit je, na straně dodavatele je také povinnost jako odborníka poskytnout to, co uživatel skutečně požaduje (ne jen to, co mu bylo řečeno). Toto je charakteristický rys konfliktů kolem “cílů” a “cílů” vývoje systému, kde se protichůdné názory obou stran střetávají. Z právního hlediska je výzvou v praxi poskytnout směrnice pro řešení sporů, které jsou spravedlivé pro obě strany.

Konkrétní situace, kdy cíle uživatele ovlivňují projekt

Projekty vývoje systému jsou často spojeny s opatřeními pro zlepšení a efektivizaci velkých podnikových nebo pracovních procesů, a často se provádí slyšení o obchodních problémech a cílech již v plánovací a návrhové fázi. Zde může dojít k diskusi o nákladech a výhodách spojených s vývojem systému a k výměně informací prostřednictvím různých kvantitativních cílů.

• Snížení nákladů na pracovní sílu díky automatizaci
• Zvýšení tržeb nebo zisku
• Zkrácení pracovní doby

Například v případě, kdy jsou výše uvedené položky konečným cílem projektu, může dodavatel předem vysvětlit efektivitu investic do vývoje systému z pozice konzultanta a provádět prodej.

Případ soudního sporu, kdy se problémem staly manažerské cíle uživatele

Avšak, dodavatel je obvykle odborníkem na vývoj systémů. Pokud by na něj měla dopadnout veškerá odpovědnost za manažerské cíle uživatele, mohlo by to být až příliš kruté.

Případ, kde bylo cílem zlepšení rychlosti práce

V souvislosti s tímto případem, v citovaném rozsudku bylo uvedeno, že v projektovém plánu vytvořeném na začátku projektu byly zaznamenány cíle a účely zahájení projektu vývoje systému. Avšak po dokončení systému a zahájení jeho provozu se ukázalo, že tyto cíle a účely nebyly dosaženy, což vedlo k sporu. V původním projektovém plánu bylo uvedeno, že po dokončení systému a jeho zavedení do praxe se usiluje o dosažení následujících stavů:

• Snížení času stráveného ručním zadáváním dat o 50%
• Zajištění, že administrativní úkony prováděné pomocí daného IT systému budou dokončeny v předem stanoveném časovém rámci

Uživatelé se pokusili vymáhat odpovědnost za nesplnění závazků a odpovědnost za vady od dodavatele, protože tyto cíle nebyly nakonec dosaženy. Soud však tato tvrzení neuznal (podtržené a tučné části byly přidány autorem).

A tak, (vynecháno)… podle celkového smyslu argumentace, ① hlavním cílem tohoto případu bylo “zvýšení efektivity práce”, “vytvoření základu pro CRM”, “provádění transparentního řízení” atd., což jsou abstraktní pojmy, a cílové hodnoty, jako je “zvýšení počtu kontaktů s klienty”, “přerozdělení pracovní náročnosti administrativních pracovníků na interní kontrolu a podporu prodeje”, “přesnější předpověď prodeje”, “omezení nadměrných slev na prodej”, atd., jsou také převážně abstraktní, a “snížení doby zadávání dat o 50%”, “snížení doby vytváření odhadů o 50%”, “dosažení zákonného zveřejnění v zákonném termínu” atd. jsou cílové hodnoty, které závisí na řízení a způsobu provádění práce obžalovaného po zavedení SBO, a nejsou to věci, které by vývojář systému, který podporuje zavedení balíkového softwaru, mohl převzít za jejich dosažení, a ② v zápisu z jednání po zahájení tohoto projektu nebylo konkrétně diskutováno o dosažení cílů a cílových hodnot tohoto případu, a ③ v plánu tohoto projektu byly použity výrazy, jako je “stát se veřejně obchodovanou společností”, které samotné nemají charakter smlouvy, a (vynecháno)… pokud vezmeme v úvahu tyto okolnosti, je možné uznat, že žalobce vytvořil popis cílů tohoto případu v plánu tohoto projektu na základě vysvětlení obžalovaného, aby se tento projekt neselhal, aby bylo dosaženo společného pochopení cílů a výsledků tohoto projektu, a nemůže být uznáno, že obžalovaný svěřil žalobci vývoj systému za účelem dosažení cílů tohoto případu. (vynecháno)… proto nemůže být uznáno, že žalobce převzal od obžalovaného vývoj systému za účelem dosažení cílů tohoto případu, a (vynecháno)… tvrzení o odpovědnosti za nesplnění závazků a odpovědnosti za vady nemají žádný důvod.

Rozsudek tokijského soudu ze dne 28. prosince 2010 (Heisei 22)

Právní význam manažerských a kvantitativních cílů vyplývající z judikatury

Jak je zmíněno v tomto rozhodnutí, zda je možné dosáhnout cílů systémového vývoje nebo kvantitativně definovaných cílů, obvykle závisí na různých faktorech, jako je úsilí managementu na straně uživatele. Proto by měla být laťka pro odpovědnost dodavatele považována za velmi vysokou. Především, pokud by byla uznána odpovědnost dodavatele za nesplnění závazků nebo záruky za vady, to by znamenalo, že “cíl” nebo “cíle” byly začleněny jako součást smluvních podmínek. Avšak v tomto případě “cíl” nebo “cíle” byly právně hodnoceny takto:

• Co se týče abstraktních a nejasných cílů, je nemožné je považovat za součást smluvních podmínek, protože neodpovídají povaze právních povinností.
• Co se týče cílů, které vyžadují vlastní úsilí ze strany uživatele, zejména na straně managementu, pokud dodavatel nemůže ovlivnit tyto cíle, je nesprávné je přičítat dodavateli a je nemožné je považovat za součást smluvních povinností.

Toto bylo právní hodnocení v tomto případě.

Další poznatky z tohoto rozsudku

V tomto rozsudku jsou také některé zajímavé body.

• Soud zohlednil možnost, že sdílení “cílů” a “cílů” projektu vývoje systému může být pouze součástí úsilí o komunikaci za účelem dosažení “společného porozumění” mezi uživatelem a dodavatelem.
• Při zvažování, jak zásadní byly tyto “cíle” a “cíle” v rámci celého projektu, soud také vzal v úvahu zápis z jednání.

Co se týče právních problémů spojených s projektem vývoje systému, z hlediska důležitosti správy dokumentů a zápisů z jednání, vysvětlení je poskytnuto v následujícím článku.

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

Právní otázky týkající se obchodních a kvantitativních cílů

Je však důležité vzít v úvahu následující doplňující informace týkající se právních otázek spojených s “cíli” a “účely”.

Zda je konzultace placená nebo bezplatná může změnit situaci

Pokud jste uzavřeli konzultační smlouvu za poplatek, nejen v rámci projektu vývoje systému, situace se může značně změnit. Pokud byly například stanoveny plány, které jsou málo realizovatelné bez ohledu na obchodní zdroje uživatele, může být možné, že budete stíháni za nesplnění dluhových závazků v rámci placené konzultační smlouvy.

Chyby výsledků, nesoulad funkcí a specifikací jsou samostatný problém

Pokud je v celém “vývojovém” projektu chyba, tedy pokud jsou výsledky zatíženy chybami nebo chybami, je třeba toto chápat odděleně od těchto problémů. V takovém případě se otázky týkající se “cílů” a “účelů” obchodního řízení nevyskytují, problémem je především soulad mezi výsledkem a požadovanými funkcemi a specifikacemi. Například, jak by měli uživatelé reagovat, pokud se po skončení systému objeví chyby, je vysvětleno v následujícím článku.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Mezi další související témata patří také to, že se uznává povinnost provést implementaci na straně dodavatele, i když to není zahrnuto v požadavcích. Podrobněji o tom pojednává následující článek.

https://monolith.law/corporate/system-development-specs-function[ja]

V každém případě by měly být spory týkající se “cílů” a “účelů” chápány jako něco, co se podobá, ale není to samé.

Základní porozumění tématům jako jsou odpovědnost a smlouvy je také důležité

Výše jsme probrali právní problémy týkající se “cílů” a “cílů” vývoje systémů. V konfliktech týkajících se těchto bodů, soudy často považují za důležité, aby se uživatelé a dodavatelé snažili koordinovat své kroky, a to především jako součást úsilí o komunikaci. Předpokládá se, že toto je dobře pochopeno. Nicméně, i když lze spravedlnost závěru plně pochopit na základě praktického pocitu jako praktik, v procesu vedoucím k tomu je vyžadováno základní porozumění “odpovědnosti” a “smlouvám”. Tyto body jsou vysvětleny v následujícím článku.

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

Je důležité pochopit, že právní odpovědnost je odlišná od nejasné morální odpovědnosti a že jasná “shoda vůle” obou stran vede k odpovědnosti ve smlouvě. Na základě toho je důležité získat hlubší porozumění.