Mida tähendab projektijuhtimise kohustus süsteemiarenduses?

Süsteemiarendus on protsess, mis edeneb ainult siis, kui tellija ja tarnija teevad omavahel koostööd.

Ettevõttes kasutatava IT-süsteemi arendamise projektid ei kulge harva täpselt plaanipäraselt või ootuspäraselt. Pigem on tavaline, et projektid seisavad silmitsi suuremate või väiksemate probleemide ja väljakutsetega, mida tuleb ükshaaval ületada. Selles kontekstis on oluline mitte ainult tellija ja tarnija vaheline koostöö, vaid ka kriisijuhtimine, mis arvestab võimalike konfliktiolukordadega.

Õiguslikust vaatepunktist on kriisijuhtimise esimene samm selgitada, milliseid kohustusi pooled kannavad ja milliseid õigusi nad saavad teineteise suhtes esitada. Selles artiklis selgitame, milliseid õiguslikke kohustusi tarnija peab süsteemiarenduse projekti raames täitma, keskendudes eelkõige projektijuhtimise kohustustele.

Mida tähendab tarnija projektijuhtimise kohustus

Alustuseks vaatame tarnija projektijuhtimise kohustuse sisu.

Kohtupraktika kohaselt on projektijuhtimise kohustuse sisu järgmine:

– Kohustus järgida kokkulepet arendustööde edendamisel, hallata pidevalt edenemise seisundit, püüda avastada arendustööd takistavaid tegureid ja nendega asjakohaselt tegeleda

– Kohustus hallata asjakohaselt ka kasutaja seotust arendusega ja tegutseda kasutaja suhtes, et vältida arendustöö takistamist kasutaja poolt, kes ei oma süsteemiarenduse alaseid erialaseid teadmisi

See tähendab, et tarnija peab näitama ülesandeid ja tähtaegu küsimustes, kus kasutajalt oodatakse otsuste tegemist ja murekohtade lahendamist, näitama takistusi, mis tekivad, kui kasutaja otsustusprotsess viibib, andma nõu, et soodustada kasutaja otsustusprotsessi, ja kui arengu käigus tekib nõudmisi, mida ei saa aktsepteerida, selgitama põhjuseid põhjalikult ja keelduma kasutaja nõudmistest.

Niisiis, tarnijal on kohustus edendada arendustöid ja samal ajal julgustada kasutajat otsuseid tegema ning püüelda süsteemiarenduse õnnestumise poole.

Kasutaja koostöökohustus

Kuid süsteemiarenduses ei ole nii, et tarnija võtab ühepoolselt kõik kohustused. Lõppude lõpuks, kuna see on IT-süsteem, mida kasutatakse tellija ettevõttes, ei tohiks süsteemiarenduse projekt olla “teiste asi” tellija jaoks.

Isegi kui kasutatakse väliseid eksperte, tuginedes arenduseks vajalikule tehnilisele ja organisatsioonilisele võimekusele, peaks sisemine juhtimine olema asjakohane. Ilma pingutuseta välisekspertide võimekuse kasutamiseks on võimatu, et kõik oleks teiste asi ja vajalikud tööd tarnitakse. Selles mõttes on ka kasutajal kohustus koostööd teha süsteemiarenduses.

Kasutaja koostöökohustused on järgmised:

　① Kasutaja teeb aktiivselt riskianalüüsi, kooskõlastab sisemiselt arvamusi asjakohaselt, ühtlustab seisukohti ja edastab soovid tarnijale

　② Kontrollib tulemusi

　③ Vastab tarnija koostöötaotlusele

Kasutajalt oodatakse, et ta edastab süsteemilt nõutava funktsionaalsuse selgelt tarnijale ja teeb aktiivselt koostööd arenduses.

Projektijuhtimine ei ole lihtne

IT-süsteemi puhul, mis koosneb peenikestest osadest, võib olla raske mõista kasutajat, kes vaatab ainult ekraani. Kuid see on väga oluline, kui mõelda süsteemiarenduse projekti juhtimise keerukusele. Just seetõttu nõutakse tarnijalt peentähelepanu ja samal ajal võimet korraldada üldpilti lühidalt ja vaadata asju laiemalt.

Töö keerukus on kohtades, mida on raske ette kujutada, kui vaadata ainult ekraani, ja see on ka põhjus, miks projektid “põlevad”. Esiteks on oluline mõista neid punkte ja teada, et “IT-süsteemi arendamise projekti juhtimine ei ole kindlasti lihtne”, mis on suur eeldus projekti riskijuhtimise õppimisel.

Mis võib juhtuda projektijuhtimise kohustuste rikkumise korral

Nüüd, mis võib juhtuda, kui projektijuhtimise kohustusi rikutakse?

Selle kohta ei ole olemas selget sätet, mis määratleks, mis on “projektijuhtimise kohustused”.

Kuid varasemate kohtuotsuste põhjal on võimalik välja lugeda teatud järjepidev seisukoht selle kohta, mida kasutaja saab teha, kui teenusepakkujal on kohustuste rikkumine.

Kui teenusepakkujal on kohustuste rikkumine, võib kasutaja nõuda teenusepakkujalt kahjutasu või lepingu lõpetamist. Siiski, kui kasutajal on ka probleeme, võib teenusepakkuja vastutust vähendada või kahjutasu summat vähendada.

Teisalt, kui kasutajal on koostöökohustuse rikkumine, võib teenusepakkuja nõuda kasutajalt tasu, kui töö ei ole lõpetatud ohtude kandmise (Jaapani tsiviilseadustiku artikkel 536, lõige 2) või kohustuste mittetäitmise tõttu.

Projektijuhtimise kohustuse näitlik kohtuotsus

Projektijuhtimise kohustuse kohta on esinduslik kohtuotsus, mida selgitatakse allpool.

Alljärgnev juhtum on seotud süsteemiarendusega, kus tekkisid viivitused tarnetähtaegades ja tarnija nõudis esialgse hinnapakkumise suurendamist, mis viis vaidluseni kohtus. See on tüüpiline näide nn “põlevast” juhtumist, kus kasutaja ja tarnija vastutuse jaotamise üle tekib vaidlus, mis jõuab kohtusse.

Kaebaja, süsteemiarenduse spetsialist, pidi oma kõrgelt arenenud erialaste teadmiste ja kogemuste põhjal ehitama süsteemi vastavalt käesoleva arvutisüsteemi arenduslepingu lepingule ja käesoleva arvutisüsteemi ettepanekule ning lõpetama arvutisüsteemi etapilise käivitamise kokkulepitud tähtajaks.
Seega, kaebaja pidi arendustööd jätkama vastavalt arvutisüsteemi arenduslepingu lepingule ja arvutisüsteemi ettepanekule esitatud arendusprotseduuridele, meetoditele ja tööprotsessidele, haldama pidevalt edenemist, püüdma avastada tegureid, mis takistavad arendustööd, ja neile asjakohaselt reageerima. Lisaks, kuna süsteemiarendus viiakse läbi koostöös tellijaga, võttes arvesse tema soove, pidi kaebaja haldama ka hageja, riikliku tervisekindlustuse, seotust süsteemiarendusega, ja töötama hagejaga, et vältida arendustöö takistamist hageja poolt, kes ei oma erialaseid teadmisi süsteemiarendusest (edaspidi nimetatakse neid kohustusi “projektijuhtimise ülesanneteks”).

Tokyo District Court, March 10, 2004 (Heisei 16)

Ülaltoodud otsusest ei ole oluline mõista detailseid sõnastusi või keerulisi juhtumi asjaolusid. Mis on kõige olulisem, on see, et terminit “projektijuhtimise kohustus” kasutatakse otseselt. Kuigi ei ole olemas sõnaselgelt sõnastatud sätteid, on näha, et kohtud püüavad kehtestada juhiseid õiguslike kohustuste jaotamiseks.

Vaatame ülaltoodud otsuse sisu lihtsamalt ja korraldame selle punktide kaupa. Siin mainitud “projektijuhtimise kohustus” tähendab:

• Tegeliku töö edenemist vastavalt eelnevale plaanile (arendusprotseduurid, meetodid, protsessid jne)
• Tegeliku töö sujuva edenemise haldamist
• Kui on olemas “takistavad tegurid”, mis takistavad tegeliku töö sujuvat edenemist, tuleb need avastada ja võtta asjakohaseid meetmeid

Lisaks ülaltoodud kolmele punktile,

• Tarnija ei tohiks teha ainult iseseisvat jõupingutust, vaid peaks ka nõudma kasutajalt vajalikku koostööd ja püüdma suhelda

Need on mõned punktid, mida saab kokku võtta.

Enamikul juhtudel sõlmitakse süsteemiarendus õiguslikult kas agentuurilepingu või töövõtulepingu alusel. Agentuurileping on lihtsalt leping, mis tähendab “teha tööd tasu eest, mis vastab tasule”, seega võib projektijuhtimise kohustus olla mõiste, mis on imendunud “täpsusesse”, mida tuleb saavutada.

Kuigi see on vaieldav teema, on ka töövõtulepingu puhul, mis on leping “teha see, mida on palutud”, arvatavasti võimalik, et tekib projektijuhtimise kohustus. Põhjus on nagu eespool mainitud, süsteemiarendus, olgu see siis agentuurileping või töövõtuleping, nõuab ikkagi projekti juhtimist ja tarnijat peetakse selleks kohustatuks.

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

Kohtupraktika, mis näitab projekti juhtimise kohustusi, mis võivad olla kohustuslikud ka enne lepingu sõlmimist

On arvatud, et projekti juhtimise kohustused võivad olla kohustuslikud ka enne lepingu sõlmimist. Allpool tsiteeritud kohtupraktika näitab, et isegi lepingu sõlmimise eelsetel etappidel, st etappidel, kus esitatakse erinevaid ettepanekuid ja plaane, on müüjapoolsetel osapooltel projekti juhtimise kohustused.

Allpool toodud juhtum puudutab projekti, mis katkestati poole pealt, ja vaidlustati, kas projekti juhtimise kohustust saab tunnustada, põhjendades seda puudustega lepingu sõlmimise eelse plaani või pakkumise etapi hinnangutes ja kasutajatele antud selgitustes. Üldiselt, kuna plaanid ja ettepanekud on lepingu sõlmimise eelsed, tekkis küsimus, kas selliseid kohustusi on õiguslikult võimalik tunnustada, kuid kohus tunnustas seda.

Projekti juhtimise kohustuste mõistmine eespool mainitud kohtupraktikas hõlmab ka lepingu sõlmimise eelset etappi, nagu on selgelt näha allpool.

Plaani ja ettepaneku etapis määratakse projekti eesmärgid, arenduskulud, arendusulatus ja arendusperiood ning projekti kontseptsioon ja teostatavus ning vastavalt sellele määratakse ka projekti riskid. Seega, müüjalt nõutav projekti kavandamine ja riskianalüüs on süsteemi arendamiseks hädavajalikud. Seega, müüjana peaksid nad plaani ja ettepaneku etapis uurima ja kontrollima süsteemi funktsioone, kasutajate vajaduste rahuldamise taset, süsteemi arendusmeetodeid, arendusstruktuuri pärast tellimuse saamist jne ning selgitama kasutajatele eeldatavaid riske. Sellised müüja kohustused seoses kontrollimise, selgitamise jne on seotud lepingu sõlmimise läbirääkimiste protsessis oleva hea usu põhimõttega ja võib öelda, et apellant kannab müüjana selliseid kohustusi (projekti juhtimise kohustused selles etapis).

Tokyo High Court, 26. september 2013 (2013)

Muuseas, mitte ainult IT-projektide puhul, vaid ka kõigi äritehingute ja õiguslike läbirääkimiste puhul on algusest peale olemas mõte, et isegi enne lepingu sõlmimist on teisel poolel teatud õiguslikud kohustused.

Suurte tehingute puhul on “kokkuleppe” protsess lepingu eesmärgini jõudmiseks sageli pikk. Selles protsessis peaks teisele poolele olema aus, mis on vähemalt moraalselt mõistetav. Lihtsamalt öeldes, sellised lood ei piirdu lihtsalt emotsionaalsete moraalitunnetega, vaid on ka õiguslikult mõttekad. (Allpool on tsiteeritud seaduse sätted. Autor on lisanud joone alla.)

Võlaõigusseaduse § 1 lõige 2
Õiguste kasutamine ja kohustuste täitmine peavad toimuma ausalt ja siiralt.

Ülaltoodud sisu kajastab lühidalt kohtuotsuses sisalduvat “hea usu põhimõtet”.

Muuseas, selles artiklis avaldatud kohtupraktika on teatud mõttes “juhend, kuidas tõmmata piir kasutajapoolse koostöökohustuse ja müüjapoolse projekti juhtimise kohustuse vahel”. IT-süsteemi arendamisel kasutajapoolse koostöökohustuse kohta leiate lisateavet järgmisest artiklist.

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

Kokkuvõte: Konsulteerige advokaadiga, kui tekivad probleemid seoses projektijuhtimise kohustuste rikkumisega

Selles artiklis oleme üritanud süstematiseerida üldisi küsimusi, mis on seotud projektijuhtimise kohustustega süsteemiarenduses. Süsteemiarendusega kaasnevad erinevad probleemid ja raskused, kuid kui sellised olukorrad tekivad, tundub, et oluline on keskenduda põhialustele, mis on ühised igas konfliktiolukorras. Iga erakorralise olukorra olemus võib olla lõputult erinev.

Kuid küsimusele “kes ja kui palju õiguslikke kohustusi alguses võttis?” esitamise olulisus ületab juhtumi individuaalsuse ja omab teatud universaalsust, kui seisame silmitsi selliste olukordadega.

Ad hoc probleemide lahendamise asemel tundub, et lahenduse leidmiseks konstruktiivsete probleemide jaotamise kaudu on vihjeid ikkagi seadustes ja varasemates kohtuotsustes.

Kui tekivad probleemid seoses projektijuhtimise kohustuste rikkumisega, pöörduge kohe advokaadi poole.