Millised on vastumeetmed, kui süsteemi tõrge ilmneb pärast vastuvõtmist?

Süsteemiarendus on üldiselt selline, et nõuete määratluse faasis otsustatud sisu järgi viiakse läbi programmi rakendamine ja lõpuks kontrollivad nii kasutaja kui ka müüja, kas see on vastavalt spetsifikatsioonidele valmis või mitte, ja lõpetatakse vastuvõtmise läbimisega.

Kuid reaalsuses võib juhtuda, et testiprotsessi ja vastuvõtmise ajal ei avastatud vigu ega probleeme, mis ilmnevad hilisemates operatsioonifaasides. Kui olete korra tarnimise vastu võtnud, mida saate seaduslikult nõuda?

Pole ebatavaline, et pärast vastuvõtmist või testimisprotsessi on vigu alles

Tehnilisest vaatepunktist ei ole haruldane, et pärast tarnija poolsete erinevate testimisprotsesside lõppu ja kasutaja poolse vastuvõtmise läbimist ilmnevad erinevad vead ja probleemid. Kasutaja poolt vastuvõtmise protsessis tehtav kontroll keskendub tavaliselt sisendi ja väljundi kontrollimisele ekraanilt. Kuid IT-süsteemid on sageli keerukad ja detailirohked, ulatudes kaugemale kasutaja poolt ekraanilt nähtavast, sealhulgas andmebaasid ja erinevad arvutus- ja juhtimisprogrammid. Seetõttu on kasutaja vaatepunktist ekraanilt sisendi ja väljundi kontrollimisel oma piirangud. Seega ei ole realistlik eeldada, et kontroll suudab hõlmata kõiki võimalikke probleeme, mis võivad tekkida hilisemas kasutusfaasis.

Sarnased asjaolud kehtivad ka tarnija vaatepunktist, kes vastutab arendustööde eest. Näiteks on “testimisprotsess” mõeldud kontrollima, kas rakendatud programmis on vigu või probleeme. Kuid testimisprotsessis ei ole alati võimalik kontrollida kõiki võimalikke vigu ja probleeme. Pärast seda, kui arendatud süsteem on hakanud täielikult tööle, võib tekkida olukordi, mida tarnija ei osanud ette näha, näiteks kui teostatakse ootamatuid toiminguid, registreeritakse suur hulk andmeid või kui mitu kasutajat pääsevad süsteemile korraga ligi. Süsteemi loomine, mis suudab sellistes olukordades tõrgeteta töötada, nõuab tõeliselt kõrget tehnilist oskust.

Vastuvõtmise ja testimise etappides ei ole realistlik leida ja lahendada kõiki võimalikke vigu ja probleeme. Peaksime mõistma, et IT-süsteemid võivad pärast kasutuselevõttu ilmneda erinevaid probleeme.

Võlgnevuse täitmine on tavaliselt juba teostatud

Kuidas peaksime selliste probleemide ilmnemisel tegutsema? Korraldame asjad vastavalt õiguslikule järjekorrale.

Esiteks, kui pärast asjaolu on ilmnenud erinevaid vigu ja probleeme, soovib kasutaja tõenäoliselt tarnijalt, kellelt ta on seni teenuseid tellinud, mingil moel vastutust nõuda. Kuid tavaliselt, kui tarnimine on juba lõpule viidud ja vastuvõtmine on heaks kiidetud, on võlgnevuse mittetäitmise alusel vastutuse nõudmine sageli keeruline.

Algselt on süsteemiarenduse lepingud, kui pole ette nähtud mingeid erilisi kokkuleppeid, programmeerimise rakendamise eeskirjad, mis tulenevad tsiviilseadustiku töövõtulepingu sätetest. Töövõtulepingu olemuse kohta on üksikasjalik selgitus järgmises artiklis.

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

Ja töövõtulepingus on “töö lõpetamine” võlgnevuse täitmise nõue. Mis tähendab konkreetset “töö lõpetamist”, on üksikasjalikult selgitatud järgmises artiklis.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Selles artiklis selgitame, et varasemate kohtuotsuste põhjal tähendab “töö lõpetamine” töövõtulepingus, kui rääkida süsteemiarenduse kontekstis, arendusprotsessi kõigi etappide lõpetamist. Ja selgitame, et pärast arendusprotsessi lõpetamist ilmnevad vead ja probleemid on töövõtulepingu alusel defektide garantii küsimus.

Kokkuvõtteks, kui olete juba tarnimise vastu võtnud ja vastuvõtmise heakskiitmise lõpule viinud, eeldatakse tavaliselt, et võlg on juba täidetud, ja seejärel tuleb käsitleda kvaliteedigarantii küsimusi, st defektide garantii nõudmise võimalust.

Vastutuse järgimise tee põhineb puuduste garantii vastutusel

Kui soovite müüjalt vastust puuduste garantii vastutuse alusel, milliseid asju ja millises järjekorras peaksite kaaluma? Vaatame allpool.

Kõigepealt kontrollige viga või tõrke tõsidust ja raskust

Kui vead või tõrked ilmnevad pärast seda ja neid peetakse seaduslikult “puudusteks”, siis nõutakse mingisugust garantiid, siis muutub probleemiks viga või tõrke raskusaste. Seadusliku puuduse küsimus on esiteks

1. isegi kui see on viga või tõrge, on see ainult väike ja seaduslikult ei saa seda nimetada “puuduseks”
2. see vastab seaduslikule “puudusele”, kuid lepingu eesmärgi saavutamine on võimalik
3. see vastab seaduslikule “puudusele” ja lepingu eesmärgi saavutamine ei ole võimalik

Need jagunevad kolmeks tüübiks. Mis eristab vastutuse järgimise võimalust puuduste garantii vastutuse alusel, on 1. ja 2. vaheline piir, ja mis eristab lepingu tühistamise võimalust puuduste garantii vastutuse alusel, on 2. ja 3. vaheline piir.

Artikkel 634

1. Kui töö objektil on puudus, võib tellija määrata mõistliku aja ja nõuda töövõtjalt selle puuduse parandamist. Kuid kui puudus ei ole oluline ja selle parandamine nõuab liigseid kulusid, siis see ei kehti.

2. Tellija võib nõuda kahju hüvitamist puuduse parandamise asemel või koos sellega. Sel juhul kohaldatakse artikli 533 sätteid

Artikkel 635

Kui töö objektil on puudus ja selle tõttu ei saa lepingu eesmärki saavutada, võib tellija lepingu tühistada. Kuid see ei kehti hoonete ja muude maatööde puhul.

Muuseas, selle “puuduse” astmelist eristamist selgitatakse üksikasjalikult järgmises artiklis.

https://monolith.law/corporate/defect-warranty-liability[ja]

Järgmisena selgitage, mida müüjalt nõuda

Samuti peate järgmisena selgitama, mida peaksite teiselt poolelt nõudma. Kui soovite lepingu tühistada, ei piisa sellest, et tõestate, et see on puudus, vaid see peab olema “lepingu eesmärgi saavutamiseks võimatu”. Siin mainitud “eesmärgi” otsustamisel on olulised vihjed süsteemiarendusprojekti alguse koosolekute protokollid ja spetsifikatsioonide kirjed. Kuna on võimalik, et pärast vastuvõtmist ilmnevad vead või tõrked tagantjärele, tuleks arendusprojekti lõppedes kõiki dokumente hoolikalt säilitada.

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

Muuseas, lisaks tühistamisele on puuduste garantii vastutuse sisu, mida saab nõuda, kahju hüvitamise nõue ja puuduste parandamise nõue.

Muud märkused

Olge ettevaatlik, kui teete õigustoiminguid, nagu lepingu tühistamine

Kui te peate lepingu tühistama seoses puudusega, peaksite omandama ka teadmised õiguslike toimingute tegemise viiside kohta. Lepingute tühistamise mõju, kehtivate tahteavalduste tegemise viis ja teavitamise viis, mis ei põhjusta hiljem probleeme, on üksikasjalikult selgitatud järgmises artiklis.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

Eelistatav on lahendada läbirääkimiste, mitte vaidluste kaudu

Lisaks ei oma sellised juriidilised arutelud tähendust ainult siis, kui kohtuasi on tekkinud. Kohtulik vaidluste lahendamine on mõlemale poolele väga koormav. Pigem on need teadmised, mida tuleks kasutada juba enne kohtusse jõudmist läbirääkimiste etapis. Kuidas neid õigusalaseid teadmisi kasutada läbirääkimistes väljaspool kohtusaali, on selgitatud järgmises artiklis.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

Vead ja rikked tuleks eristada funktsioonide puudumisest

Kui rakendatud funktsioonides või spetsifikatsioonides on vigu või rikkeid või kui need on üldse puudulikud, on arutelu erinev. Kui vajalikud funktsioonid pole täielikult olemas, ei pruugi töö “lõpetamist” tunnustada lepingu alusel ja võib-olla ei tunnustata ka kohustuste täitmist.

Kui aga selliseid vajalikke funktsioone või spetsifikatsioone pole, kuid kasutaja ei ole nõuete määratlemise etapis korralikult teavet esitanud, võib olla asjakohane hinnata, et lepingu osa ei ole sobiv.

Kokkuvõte

Probleemid, mis tekivad projekti etappides, võivad ilmneda nii projekti käigus kui ka hiljem, näiteks kasutusetapis. Süsteemiarendusprojektide iseloomulik tunnus, et isegi kui kõik etapid on edukalt lõpule viidud, ei saa me alati olla kindlad, on kõige paremini sümboliseeritud “defekti garantii vastutuse” süsteemiga. On oluline, et dokumentide haldamine oleks põhjalik, võttes arvesse ka süsteemiarendusprojekti lõppu, ning et mõistetakse kogu seda protsessi.