Mida tähendab tarnija toetusvastutus pärast süsteemiarenduse lõppu?

Süsteemiarenduses on hästi teada, et süsteemiarenduse spetsialistid ehk müüjad võtavad endale “projektijuhtimise kohustuse”, kuid õiguslikult on esile tõstetud ka sarnane, kuid erinev kontseptsioon, mida nimetatakse “toetuskohustuseks”. Selles artiklis selgitame “toetuskohustust”, võttes arvesse ka varasemaid kohtupraktikaid.

Toetusvastutus

Toetusvastutuse ülevaade

Kui rääkida kohustustest, mida tarnija peab kasutaja ees täitma, on üks esinduslikumaid projektijuhtimise kohustus. See on korduvalt mainitud kohtupraktikas ja on süsteemiarenduse spetsialistina tarnija poolt projekti eest vastutamise üldmõiste.

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

Projektijuhtimise kohustus on süsteemiarenduse õigusterminoloogias väga tuntud ja pole kahtlust, et see on peamine kohustus, mida tarnija peab täitma. Kuid mõnedes kohtuotsustes tunnistatakse ka teistsuguse kohustuse olemasolu, mida nimetatakse “toetusvastutuseks”.

Toetusvastutus tekib kasutajatele suunatud operatsioonitoe küsimustes

Aga mis on toetusvastutus? Ja miks seda nimetatakse erinevalt projektijuhtimise kohustusest? Toetusvastutus tekib tavaliselt pärast süsteemiarenduse lõppu. Süsteemiarenduse projektid lõpevad tavaliselt siis, kui süsteem on valmis. See tähendab, et projekt algab süsteemi nõuete määratlemisega ja lõpeb süsteemi valmimise kontrollimisega (testimine või vastuvõtmine). Järgnevas artiklis käsitleme üksikasjalikult õigusprobleeme, mis sageli tekivad vastuvõtmise etapis, arvestades, et see on “süsteemiarenduse projekti lõpp” ja sellel on oluline tähendus.

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

Kuid isegi kui süsteemiarenduse projekt on uue süsteemi loomise protsess, on loomulik eeldus, et arendatud süsteemi kasutatakse hiljem äritegevuses. See tähendab, et kui süsteem on välja töötatud, võib tekkida suur ebaloogilisus, kui öelda, et “kuna olen arendustööde eest vastutav, pean lihtsalt süsteemi looma” ja jätta tähelepanuta, kuidas süsteemi edasi kasutatakse. Arvestades seda, on kohtupraktikas tekkinud küsimus, kas süsteemiarenduse eest vastutavale tarnijale ei saa määrata teatud operatsioonitoe kohustusi. See tähendab, et küsimus on selles, kas süsteemiarenduse lepingus peaks tarnija kohustuste hulka kuuluma ka operatsioonitoe kohustus pärast arendust. Kuna operatsioonitugi ei ole arendusprotsess ise, on seda nimetatud toetusvastutuseks, et eristada seda projektijuhtimise kohustusest.
　

Mis on kohtupraktika, kus tugi kohustus on probleemiks?

Juhtum, kus süsteemi testimise etapis takistas kasutaja äritegevust

Allpool tsiteeritud kohtuotsuse juhtumis ei suutnud kasutaja süsteemi kasutada nii, nagu ta algselt eeldas, süsteemi testimise ajal enne süsteemi käivitamist, ja lõpuks loobus kasutaja süsteemi käivitamisest. See juhtum oli probleem kasutaja kasutuselevõtu ajal, kuidas põhjendada võrgu poole vastutust lepingust, mis sõlmiti enne süsteemi arendamist. Lõppkokkuvõttes tunnustati kasutaja kahjutasu nõuet ja selle aluseks oli “tugi kohustuse rikkumine”.

I Tugi kohustuse rikkumine
(A) Hageja esindaja esitas 14. juulil 1999 (Heisei 9) kostjale taotluse, et “Ma tahan, et te ei loo ainult süsteemi, vaid hoolitseksite selle eest, et see töötaks korralikult lõpuni.“, “Me oleme algajad, nii et kui me maksame palju raha, tahame, et te hoolitseksite selle eest, et me saaksime seda lõpuni kasutada.“. Vastuseks sellele selgitas kostja, et on võimalik ehitada süsteem, mis suudab saavutada hageja kasutuselevõtu eesmärgi ja lubas toetada seda kuni selle korraliku kasutamiseni. Selle tulemusena jõuti hageja ja kostja vahel kokkuleppele, et kostja toetab hagejat kuni ta suudab süsteemi korralikult kasutada.
Kostja kohustus hagejat toetama on ilmne, kuna lepingu tasu on “paketi kasutuselevõtu toetus” ja 1726 tuhat kulu on arvestatud, pakkumises on kuus hooldustasu kirjutatud kui “kuus kuud tasuta hooldus” ja “tulevase SE toetuse kohta (ettevõtte koosoleku materjalid)” pealkirjaga dokumendis on kinnitatud, et saab SE tuge värske tellimuse “kasutuselevõtu protseduuri (kava)” loomise ja “andmete / kasutuse kontrollimise” kohta.

(B) Ja kostja toetuskohustus hageja ees on konkreetselt vähemalt kuni hageja jõuab süsteemi põhikäivitamiseni, kostja peab hagejale pakkuma ① sobivat nõu süsteemi kasutamise kohta, ② osalema kasutuse testimisel ja reageerima süsteemi probleemidele, mis tekivad kasutuse testimisel, ③ parandama süsteemi vastavalt kasutuse testimise tulemustele, ④ pakkuma kasutajatele kasutuselevõtu koolitust.
Kuid kostja, hoolimata sellest, et kasutuse testimisel tekkis palju probleeme, ei võtnud seda tõsiselt ja nõudis ainult kasutajate kasutuselevõtu koolituskulusid, ei pakkunud hagejale mingit sobivat tuge süsteemi põhikäivitamiseks.

Tokyo District Court Hachioji Branch, 5. november 2003 (Heisei 15)

Selles kohtuotsuses, sealhulgas sisukorras ja kogu kohtuotsuses, ilmub sõna “toetus” umbes 30 korda. Kasutaja nõudmised sobiva toetuse järele on otse kohtuotsusesse kirjutatud, mis näitab, et otsus tehti pärast juhtumi üksikasjalikku kaalumist ja õiglase lahenduse otsimist. Eriti tähelepanuväärne on see, et selle juhtumi mõistmisel:

• Tugi kohustuse rikkumist käsitletakse “kohustuse mittetäitmise” osana, mistõttu määrati kahjutasu, mis tekkis selle tulemusena
• “Projektijuhtimise kohustust” ei kasutata kogu kohtuotsuses üldse

See näitab, et kuigi see on erinev projektijuhtimisest, püüab see käsitleda seda süsteemiarenduse lepingu sisaldava lepingulise kohustusena.

Kuidas peaksime mõistma toetuskohustuse olemust?

Toetuskohustus ei ole veel selge kontseptsioon

Nagu eespool mainitud kohtuotsus näitab, peaks süsteemi arendanud müüja pakkuma ka kasutajale vajalikku tuge süsteemi kasutuselevõtuks. Kuid toetuskohustuse kohta ei ole nii palju kohtupraktikat ega muid teadmisi kui projektijuhtimise kohustuse kohta, mistõttu on selle olemuse mõistmine keeruline. Eriti probleemne on see, et termin “toetus” ei ole selgelt määratletud.

Toetuskohustust ei saa piiramatult tunnustada

Lisaks näitas müüja toetuskohustuse rikkumist tunnustanud kohtuotsus ka väga olulist punkti.

Kostja peab lepingu alusel pakkuma hagejale ehitatud ja tarnitud süsteemi kasutamiseks vajalikku toetust. Kuid selle sisu ei ole selline, nagu hageja väidab, et ta peaks pakkuma piiramatu aja jooksul täielikku tasuta tuge, kuni hageja saab süsteemi kasutada.

Tokyo District Court Hachioji Branch, November 5, Heisei 15 (2003)

Kui peamine ülesanne on süsteemi “arendamine”, siis on ka “kasutuselevõtu” toetamiseks tehtavatel tegevustel piirangud. Selle kohtuotsuse puhul on märkimisväärne, et kohtuotsuses on tahtlikult tsiteeritud kasutajate toetuse taotlusi, viidatud eelnevatele hinnangutele ja mainitud erikokkuleppe olemasolu toetuse osutamiseks. See tähendab, et kui toetuskohustuse mõiste laieneb piiramatult, võib see müüjale suurt koormust panna, mistõttu tuleb kohustuse rikkumise tunnustamist teatud määral ettevaatlikult teha.

Toetuskohustuse sisu tuleks uurida koos kasutaja koostöökohustusega

Kõik see tähendab, et “kuidas kasutaja ja müüja peaksid süsteemi arendamise algfaasis töökoormust jagama”. See hõlmab kindlasti keerulist küsimust, millises ulatuses peab müüja kasutuselevõtu ajal “arendamise” lepingust tulenevaid õiguslikke kohustusi täitma. Samuti on vaja teha otsuseid, võttes arvesse konkreetseid asjaolusid.

Kuid müüja toetuskohustuse sisu mõistmine, mõistes ka kasutaja koostöökohustust, võib muuta selle kindlamaks.

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

Üldiselt on uue süsteemi abil äritegevuse parandamise algatused tehniliste ekspertide, müüjate ja ettevõtte äriteadmisi omavate kasutajate ühine töö. Seega, kui määratleda selgelt, milliseid küsimusi peaks kasutaja lahendama “koostöökohustuse täitmise” raames, siis võib ka toetuskohustuse ulatus sageli selgelt määratleda.

Kokkuvõte

Käesolevas artiklis oleme käsitletud projekti juhtimise põhitõdesid ning korraldanud informatsiooni “toetuskohustuse” kohta, mida võib pidada projekti juhtimise derivaadiks. Toetuskohustuse mõiste on endiselt paljuski ebaselge, kuid selle mõistmiseks on olulised just põhilised küsimused nagu “projekti juhtimise kohustus” ja “koostöökohustus”.