Süsteemiarendusprojektide põlemisega" seotud seadused"

Süsteemiarenduse projekt ei ole midagi, mida saab saavutada üleöö. See nõuab paljude inimeste, organisatsioonide, suurte rahasummade ja pika arendusperioodi panust. Selles artiklis selgitame, kuidas süsteemiarenduse projekti “põlemise” nähtust saab korraldada seadusliku raamistiku alusel, ning koostame lahenduste juhised.

Miks projektid “põlevad”?

Üks IT-süsteem toimib korrektselt ainult tänu suurele hulgale loodud programmifailidele ja lähtekoodile, isegi kui see pole erakordselt suuremahuline projekt. IT-süsteemid, eriti need, mille kasutajaliides on lihtne ja selge, on sageli üllatavalt detailne ja hoolikalt konstrueeritud, mis on kasutajale sageli ettekujutamatu.

• Tähtaeg on ainus, mis on eelnevalt kindlaks määratud, samas kui spetsifikatsioonid ja nõuded on endiselt ebaselged ja aeg lihtsalt möödub
• Projektitiimiliikmed on liiga hõivatud ettevõttepoliitika küsimustega, mis põhjustab suurenenud stressi ja viib sageli selle juurde, et liikmed loobuvad projektist
• Projektijuhtimise tasandil, sealhulgas projektijuhtidel, puudub piisav läbirääkimisoskus ja liikmetelt ei nõuta asjakohast aruandlust, suhtlust ega konsulteerimist

Kuigi konkreetsete “põlemise” põhjuste osas võib olla erinevusi projekti lõikes, saab neid õiguslikust vaatepunktist suhteliselt lihtsalt kategoriseerida mitmesse tüüpi.

Põletustüüp 1: Projekt katkeb pooleli

Süsteemiarenduse käigus võib projekti katkemise tüüpiliseks põhjuseks olla kasutajate ja tarnijate vahelise suhtluse puudumine. Süsteemiarenduse projekt nõuab muidugi tarnija poolt süsteemiarenduseks vajalikke erialaseid tehnilisi ja organisatsioonilisi oskusi, kuid see nõuab ka lõppkasutajate koostööd.

Seega, kui projekti suhtes on ebaselge, millist rolli mõlemad pooled mängivad, ja projekt jätkub, võib tekkida omamoodi “tööülesannete edasilükkamine”, mis takistab projekti sujuvat kulgemist. Lisateavet kasutajate kohustuste ja tarnijate kohustuste kohta leiate järgmistest artiklitest.

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

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

Üksikasjalikum teave iga osapoole kohustuste kohta on saadaval ülaltoodud artiklites, kuid siin on oluline mõista, et iga süsteemiarenduse projekti puhul on kasutajatel ja tarnijatel oma kindlad kohustused. Üldiselt on nõuete määratlemine, disain (st põhiline disain), vastuvõtmine jms, mida ei saa lõpule viia ilma kasutajate koostööta, tunnustatud kasutajate koostöökohustusena.

Teiselt poolt on tarnijatel pärast kasutajate koostöö saamist (ja samal ajal pärast sellise koostöö taotlemiseks vajalike suhtlusjõupingutuste tegemist) kohustus tagada projekti sujuv kulgemine ning avastada ja kõrvaldada takistused.

Selle mõtteviisi alusel on kohtud näidanud, et kasutajatel on kohustus rakendada sisemist juhtimist ja tarnijatel on kohustus näidata oma erialaseid ja tehnilisi oskusi, ning nad on näidanud valmisolekut käsitleda kõiki vaidlusi õiglaselt.

Samuti on “katkemine” tavaliselt seotud vastuvõtmisega. Vastuvõtmise kohta leiate üksikasjalikuma selgituse järgmisest artiklist.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Kui tekib vaidlus, on oluline objektiivselt kontrollitav tõend, nagu projekti varasem areng ja koosolekute sisu. Seetõttu on eelnevalt salvestatud dokumentidel sageli suur tähtsus. Dokumentide haldamise põhjalikkus on oluline, et mitte kahjustada oma positsiooni. Süsteemiarenduse dokumentide haldamise tähtsuse kohta leiate üksikasjalikuma selgituse järgmisest artiklist.

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

Põletustüüp 2: Kasutaja poolt isiklikest põhjustest tühistamine

Samuti võib juhtuda, et projekt tühistatakse kasutaja soovil poole pealt. Näiteks, kui ettevõte on alustanud IT-süsteemi loomist, mis haldab kõiki personali küsimusi, sealhulgas välismaa filiaale, ja äkki otsustatakse loobuda ettevõtte laienemisstrateegiast välismaale. Sellisel juhul võib alustatud süsteemi arendamine muutuda kasutajale tarbetuks.

Üldiselt, küsimus, kuidas peaks ettevõttes kasutatav IT-süsteem olema üles ehitatud, ei ole lahutatav küsimusest, milliseid tööülesandeid ettevõttes üldse täidetakse. Seega, organisatsiooni struktuuri või äriüksuste olulised muudatused, strateegia põhjalik ülevaatamine jne võivad mõjutada süsteemi nõudeid, mis võivad muutuda vajalikuks (või tarbetuks) pärast muudatuste tegemist.

Selliste asjaolude tõttu võivad projektide katkestamisel tekkida erinevad õiguslikud probleemid. Tavaliselt, kui tühistamine toimub kasutaja isiklikest põhjustest, on tarnijal õigus nõuda teatud tasu vastavalt töö lõpetamise määrale. Sõltuvalt sõlmitud lepingu tüübist võivad aluseks olevad sätted erineda, kuid sisu võib kokku võtta järgmiselt:

・Töövõtulepingu korral: Tsiviilseadustiku (Jaapani tsiviilseadustik) artikkel 641
Tsiviilseadustiku artikkel 641
→Kui töövõtja ei ole tööd lõpetanud, võib tellija igal ajal lepingu lõpetada, makstes kahjutasu.
・Kaudse volituse lepingu korral: Tsiviilseadustiku artikkel 648 lõige 3 (olenevalt olukorrast võib kohaldada ka Tsiviilseadustiku artiklit 651 kahjutasu nõudmiseks)
Tsiviilseadustiku artikkel 648
→Kui volitus lõpeb täitmise käigus põhjusel, mida ei saa omistada volinikule, võib volinik nõuda tasu vastavalt juba tehtud töö mahule.
Tsiviilseadustiku artikkel 651
→1. Volitus võib igal ajal lõpetada mõlemad pooled.
→2. Kui üks pooltest lõpetab volituse teisele poolele ebasoodsal ajal, peab see pool hüvitama teisele poolele tekitatud kahju. Siiski, kui on olemas mõjuv põhjus, ei kehti see reegel.

Kokkuvõte

Iga süsteemiarenduse projekt läbib erinevaid ja mitmekesiseid keerdkäike. Kuid kui rääkida õiguslikest projektidest, mis “põlevad”, siis käesolevas artiklis esitatud raamistik võib olla üks vaatluskaart. Süsteemiarendusega seotud õiguslikud küsimused hõlmavad tõepoolest väga erinevaid teemasid.

Kuid nagu süsteemiarenduse töö nõuab konstruktiivset mõtlemisvõimet, nii võib ka sellega kaasnev riskijuhtimine muutuda konstruktiivsemaks, kui ei kaotata silmist valdkonna üldpilti.