Õiguslik tähendus juhtimiseesmärkide ja numbriliste eesmärkide kohta süsteemiarendusprojektides

Süsteemiarendusprojektid on sageli tihedalt seotud ettevõtete ja töökohtade suuremahuliste äritegevuse parandamisega. Sellistes olukordades võib nõuda ka panustamist ettevõtte juhtimisprobleemide lahendamisse või numbriliste eesmärkide saavutamisse. Kuid kas selliste juhtimiseesmärkidega kohustuste võtmine on tõepoolest seaduslik kohustus? Tekib küsimus, milline on numbriliste eesmärkide ja juhtimiseesmärkide seaduslik tähendus. Selles artiklis selgitame süsteemiarendusega seotud erinevate “eesmärkide” ja “eesmärkidega” kaasnevaid õiguslikke küsimusi.

Miks võivad süsteemiarenduse eesmärgid ja eesmärgid olla konflikti allikaks?

See on probleem, mis asub kasutaja koostöökohustuse ja tarnija otsustusvabaduse vahel

Kui vaadata äritehingute olemust, on süsteemiarendusprojektidel mitmeid eripärasid. Üks neist on see, et tarnija poolt läbiviidav süsteemiarendusprojekt ei ole midagi, mida tarnija saaks teha üksi, vaid see nõuab kasutaja poolt koostööd. Selle kohustuse olemasolu on kohtupraktikas selgelt määratletud kui “koostöökohustus”. Peamiselt nõutakse kasutajalt koostööd süsteemiarenduse faasides nagu ① nõuete määratlemine ② põhiline disain ③ lõpptulemuse vastuvõtmine.

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

Teine eripära on see, et tarnijapoolt nõutakse tavaliselt suurt otsustusvabadust tööülesannete täitmisel. Süsteemiarendusprojekti raames tarnija poolt tehtavate ülesannete kogumit nimetatakse õiguslikus mõttes “projektijuhtimise kohustuseks”. Selle kohta on üksikasjalikumalt kirjutatud allpool toodud artiklis.

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

Kokkuvõttes võime siin tuua välja kaks olulist punkti:

• Kasutajalt nõutakse praktikas, et ta annaks tarnijale asjakohast teavet ja aitaks kaasa tarnija arendustegevusele.
• Tarnijalt nõutakse praktikas, et ta mõistaks projekti eesmärki ja eesmärke kasutaja jaoks ning teeks nendega kooskõlas olevaid jõupingutusi.

Ülaltoodud kahe punkti tõttu muutub probleemiks ka see, kui palju võib tarnija kohustuseks olla kasutaja poolt eelnevalt antud selgituste, nagu ärieesmärgid või numbrilised eesmärgid, saavutamine. Teisisõnu, on olemas aspekt, et kasutaja kohustus on esitada tarnijale, mida ta peaks tegema (mitte ebaselgeid asju nagu eesmärgid), spetsifikatsioonides, samas kui tarnijal on ka kohustus pakkuda kasutajale, mida ta tegelikult vajab, mitte lihtsalt teha, mida talle öeldakse. See, et need kaks vastandlikku seisukohta põrkuvad, on ka süsteemiarenduse “eesmärkide” ja “eesmärkide” ümber tekkivate konfliktide tunnusjoon. Lisaks on õiguslikust vaatepunktist väljakutseks pakkuda mõlemale poolele õiglast konflikti lahendamise juhendit.

Konkreetsed olukorrad, kus kasutaja eesmärgid mõjutavad projekti

Süsteemiarenduse projektid on sageli seotud ettevõtete või töökohtade suurte tööparanduste ja efektiivsuse suurendamise meetmetega ning sageli tehakse juba ettepaneku ja planeerimise etapis kuulamisi äriprobleemide ja ärieesmärkide kohta. Seal võib toimuda arutelu süsteemiarendusega kaasnevate kulude ja kasu üle ning arutelu erinevate numbriliste eesmärkide kaudu.

• Tööjõukulude vähendamine tänu tööjõu säästmisele
• Müügi või kasumi suurenemine
• Tööaja lühendamine

Näiteks kui ülaltoodud punktid on projekti lõppeesmärk, võib tarnija eelnevalt konsultandi rollis selgitada süsteemiarenduse investeeringute mõju ja teha müügitööd.

Kohtupraktika, kus probleemiks on kasutaja poolt püstitatud juhtimiseesmärgid

Kuid tuleb märkida, et tarnija on tavaliselt süsteemiarenduse spetsialist. Kui kõik vastutus langeb kasutaja juhtimiseesmärkidele, võib see muutuda liiga karmiks.

Juhtum, kus eesmärgiks oli äritegevuse kiirendamine

Selles küsimuses viidatakse allpool tsiteeritud kohtuotsuse juhtumile, kus projekti alguses koostatud ettepanekus olid kirjas süsteemiarendusprojekti käivitamise eesmärgid ja sihid. Kuid kui süsteem oli valmis ja kasutusele võetud, ei suudetud neid eesmärke ja sihte saavutada, mis viis vaidluseni. Algse ettepaneku kohaselt oli eesmärk saavutada järgmine olukord pärast seda, kui süsteem on valmis ja seda tegelikult kasutatakse:

• Inimese poolt tehtava sisestamise aja vähendamine 50% võrra
• Tagada, et IT-süsteemi abil tehtavad bürootööd saab teha ettenähtud ajavahemikus

Kasutajad ei suutnud neid tulemusi saavutada ja püüdsid seetõttu nõuda tarnijalt võlgnevuse mittetäitmise ja defekti garantiivastutust. Kuid kohus ei nõustunud nende väidetega (allajoonitud ja paksus kirjas osad on autori lisatud).

Ja, (jättes vahele) kogu vaidluse põhisisu põhjal, ① selle juhtumi eesmärk on “äritegevuse tõhustamine”, “CRM-i aluse loomine”, “nähtava juhtimise läbiviimine” jne, mis on abstraktsed, ja sihtmärgid on “suurendada kliendiga suhtlemise punkte”, “jaotada administratiivtöötajate tööjõud sisekontrolli ja müügitoe vahel”, “teha täpsemaid müügiprognoose”, “piirata liigset müügisoodustust” jne, mis on enamasti abstraktsed, ja “vähendada sisestamise aega 50% võrra”, “vähendada hinnapakkumise aega 50% võrra”, “teha seaduslik avalikustamine seadusliku aja jooksul” jne sihtmärgid sõltuvad pärast SBO kasutuselevõttu kostja juhtimise ja äritegevuse viisist ja need ei ole sellised, mida süsteemiarendusettevõte, kes on hageja, saaks saavutada, ② pärast selle juhtumi projekti algust koosolekute protokollides ei ole märge, et oleks arutatud selle juhtumi eesmärke ja sihtmärke, ③ selle juhtumi projektiplaanis on kasutatud väljendeid nagu “saada börsiettevõtteks”, mis ei oma iseenesest lepingu olemust, (jättes vahele) arvestades neid asjaolusid, võib tunnistada, et hageja koostas selle juhtumi eesmärgi kirjelduse selle juhtumi projektiplaanis, tuginedes kostja selgitustele, et vältida selle projekti ebaõnnestumist, et saavutada ühine arusaam selle projekti eesmärgist ja tulemustest, ja ei saa tunnistada, et kostja on delegeerinud hagejale süsteemiarenduse, et saavutada selle juhtumi eesmärk. (jättes vahele) Seetõttu ei saa tunnistada, et hageja on võtnud endale kohustuse arendada süsteemi, et saavutada selle juhtumi eesmärk kostja eest, (jättes vahele) võlgnevuse mittetäitmise ja defekti garantiivastutuse väited on mõlemad põhjendamatud.

Tokyo District Court, December 28, 2010 (Heisei 22)

Õiguslik tähendus juhtimiseesmärkide ja numbriliste eesmärkide kohta kohtupraktika põhjal

Nagu mainitud ka selles otsuses, on tavaline, et süsteemiarenduse eesmärgi või kvantifitseeritud eesmärgi saavutamine sõltub erinevatest teguritest, nagu kasutajapoolne juhtimispingutus. Seetõttu peaksime arvama, et müüja vastutuse künnis on väga kõrge. Algselt, kui müüja kohustuste mittetäitmise või defektide garantiivastutus tunnistatakse, tähendab see, et “eesmärgi” või “eesmärgi” saavutamine on lepingusse sisse kirjutatud. Kuid selles asjas “eesmärgi” või “eesmärgi” osas,

• on abstraktsete ja ebamääraste asjade puhul raske näha neid lepingu osana, kuna need ei sobi õiguslike kohustuste olemusega
• kasutajapoolsete, eriti juhtimisalaste jõupingutuste osas, mis on väljaspool müüja kontrolli, on ebaõiglane panna vastutus müüjale ja on raske näha neid lepinguliste kohustuste osana

Selliseid hinnanguid anti õiguslikult.

Mida veel sellest otsusest välja lugeda

Selles otsuses on veel mitmeid huvitavaid punkte.

• Kohtu arvestab võimalusega, et süsteemiarendusprojektide “eesmärkide” ja “eesmärkide” jagamine võib olla lihtsalt osa kommunikatsioonijõupingutustest, et saavutada “ühine arusaam” kasutajate ja müüjate vahel.
• Kohtu arvestab võimalusega, et süsteemiarendusprojektide “eesmärkide” ja “eesmärkide” jagamine võib olla lihtsalt osa kommunikatsioonijõupingutustest, et saavutada “ühine arusaam” kasutajate ja müüjate vahel.

Muuhulgas, süsteemiarendusprojektidega kaasnevate õiguslike küsimuste osas, dokumentide haldamise ja koosolekute protokollide olulisuse vaatepunktist, pakume selgitusi järgmises artiklis.

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

Juhtimiseesmärkide ja numbriliste eesmärkide ümber keerlevate õiguslike küsimuste märkused

Siiski, selliste “eesmärkide” ja “eesmärkide” ümber keerlevate õiguslike küsimuste puhul tuleks arvestada ka järgmiste lisapunktidega.

Nõustamine võib olla tasuline või tasuta, mis muudab olukorda

Kui te ei tegele mitte ainult süsteemiarendusprojektiga, vaid olete sõlminud ka tasulise nõustamislepingu, võib olukord oluliselt muutuda. Kui kasutajapool ei arvesta oma juhtimisressurssidega ja koostab teostatavuse poolest nõrga tegevuskava, võib tasulise nõustamislepingu osas nõuda võlgnevuste täitmata jätmise eest vastutust.

Toodete defektid, funktsioonide ja spetsifikatsiooninõuete mittevastavus on eraldi probleem

Samuti, kui “arendus” projektil endal on defekte, st kui toodetes tuvastatakse tõrkeid või vigu, tuleb neid probleeme mõista eraldi. Sellisel juhul pole juhtimise “eesmärkide” või “eesmärkide” üle arutlemine oluline, vaid peamiselt on küsimus toodete ja nõutavate funktsiooninõuete või spetsifikatsioonide vastavuses. Näiteks, kui süsteemis ilmneb tagantjärele defekt, on kasutaja vastumeetmed selgitatud järgmises artiklis.

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

Teised seotud teemad hõlmavad asju, mis pole nõuetesse kaasatud, kuid mida peetakse müüja poolt rakendamise kohustuseks. Selle kohta on üksikasjalik selgitus järgmises artiklis.

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

Mõlemal juhul tuleks “eesmärkide” ja “eesmärkide” ümber toimuvaid vaidlusi mõista sarnaste, kuid erinevate asjadena.

Vastutuse ja lepingute teemadel nõutakse põhjalikku mõistmist

Ülaltoodud tekstis selgitasime süsteemiarenduse “eesmärkide” ja “eesmärkide” ümber keerlevaid õiguslikke küsimusi. Selliste punktide ümber toimuvates vaidlustes on kohtud sageli mõistvad, et kasutajad ja müüjad teevad jõupingutusi ühtlustamiseks, ja seda peetakse osaks suhtlemise pingutustest. Kuigi järelduse enda õigsust saab täielikult mõista ka praktikuna, nõutakse protsessi jooksul, mis viib selleni, põhjalikku mõistmist selliste asjade suhtes nagu “vastutus” ja “lepingud”. Selliste punktide kohta leiate selgitusi järgmisest artiklist.

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

On oluline mõista, et õiguslik vastutus erineb ebamäärastest moraalsetest kohustustest ja et mõlema osapoole kindel “kokkulepe” tekitab lepingulise vastutuse. Selline põhjalik mõistmine on oluline.