Millised on seadused, kui süsteemiarenduse tasu on maksmata jäetud?

Süsteemiarenduse tööd pakkuvale ettevõttele võib teatud mõttes suurimaks riskiks olla olukord, kus “vaatamata tarnimisele, kasutaja ei maksa tasu”. Süsteemiarenduse kulud koosnevad suuresti oskustega töötajatest, sealhulgas programmeerijatest, mistõttu on sageli suured tööjõukulud. Müügitulu kogumise viivitamine võib mõnikord muutuda elu ja surma küsimuseks. Selles artiklis käsitleme õiguslikust vaatepunktist küsimusi, mida ettevõte peaks kaaluma, kui kasutaja ei nõustu tasu maksmisega.

Kõigepealt tuleb kontrollida, kas tasu nõudmine on võimalik

• Vaatamata sellele, et tarnija on kasutajale tulemuse esitanud, ei aktsepteeri kasutaja tarnimist ja seetõttu on tasu nõudmine edasi lükatud.
• Kuigi arvati, et vastuvõtmine on lõppenud, on kasutaja arusaamal mingi erinevus ja ta ei nõustu tasu maksmisega.

Need olukorrad on täiesti võimalikud reaalsuses.

Muuseas, kasutaja kontrollib valmis süsteemi spetsifikatsioone ja aktsepteerib tarnimist, mida süsteemiarenduse terminites nimetatakse “vastuvõtmiseks”. Selle vastuvõtmise tähenduse ja asjad, mida tuleks kaaluda, kui selle edenemine pole soodne, on üksikasjalikult selgitatud järgmises artiklis.

Seotud artikkel: Mis on süsteemiarenduse vastuvõtmine ja eeldatava vastuvõtmise klausli rakendamise olukord[ja]

Kuigi ma jätan vastuvõtmise üldise selgituse ülaltoodud artiklile, on vaja kaaluda, kas seaduse järgi on kasutaja vastuvõtmine lõpule viidud, võttes arvesse ka “eeldatava vastuvõtmise klausli” sätteid.

Seda silmas pidades, esimene punkt, mida tuleks kaaluda, kui kasutaja ei tee tasu maksmist, on järgmine:

1. Kas töö on üldse lõpetatud või on see veel lõpetamata
2. Kas rakendatakse defekti garantiikohustust (Tsiviilseadustiku artikkel 635)

Põhjus, miks tuleks esmalt kontrollida ülaltoodud kahte punkti, on see, et kui töö pole esialgu lõpetatud ja defekti garantiikohustust (Tsiviilseadustiku artikkel 635) ei kohaldata, ei saa isegi kui kohtuasja algatatakse, loota, et tasu makstakse.

Niisiis, mida peaks tarnija esindaja konkreetselt uurima, et uurida ülaltoodud kahte punkti? Allpool vaatame, milliseid dokumente tuleks kontrollida.

Dokumendid, mida tuleks kontrollida tasu nõudmise õiguspärasuse kindlakstegemiseks

Muuhulgas, kuidas hallata süsteemi spetsifikatsioonide muutusi ja kuidas koostada muudatusjuhtimisdokumente, on üksikasjalikult selgitatud teises artiklis.

Seotud artikkel: Õiguslikust vaatepunktist, kuidas hallata muudatusi süsteemiarenduses[ja]

Järgmisena, kontrollige, kui suurt tasu saab nõuda

Kui palju saab nõuda, sõltub tavaliselt lepingus toodud tingimustest. Kuid kui spetsifikatsioonid on muudetud või on tehtud muid muudatusi pärast lepingu sõlmimist, võib juhtuda, et korralik leping (või sellega võrreldav dokument) puudub. Kuidas ümber arvutada hinnangud, mis põhinevad järeltekkivatel põhjustel, nagu spetsifikatsioonide muutmine või funktsioonide lisamine, on üksikasjalikult selgitatud järgmises artiklis.

Seotud artikkel: Kas süsteemiarenduse hinnangut on võimalik suurendada?[ja]

Kuigi hinnangute ümberarvutamise meetod on selles artiklis kirjeldatud, on eriti oluline kaaluda, kas arveldussumma suurendamine on võimalik, vaadates:

1. Lisatööde ja funktsioonide parandamise osa hinnangute olemasolu ja sisu
2. Kasutaja reaktsioon hinnangutele
3. Lisatööde ja funktsioonide parandamise olukorra ning sellega seotud summa kokkuleppe olemasolu, mis on kirjas ülesannete haldamise tabelis

Peamiselt tuleb vaadata neid aspekte. Põhimõtteliselt on küsimus selles, kas kasutajapoolse nõusoleku korral saab öelda, et “tellitakse tööd selle summa eest” (st kas leping on sõlmitud).

Lõpuks, kaalume tegeliku kohtuasja korral esilekerkivaid küsimusi

Pöörake tähelepanu võimalusele, et vastukaebus esitatakse

Süsteemiarenduses, kui kasutaja või müüja esitab teisele poolele kohtuasja, ei ole haruldane, et vastukaebus esitatakse vastu. See tähendab, et kui on olukord, kus tasu ei maksta, on ka kasutajal mingi argument.

Algselt süsteemiarenduses, kuigi kasutaja pool peab täitma erinevaid koostöökohustusi, ei tohiks me unustada, et müüja pool kannab süsteemiarenduse spetsialistina laiaulatuslikku otsustusõigust ja suurt vastutust. Müüja poolt süsteemiarendusele võetud projekti juhtimise kohustuse kohta on üksikasjalikult selgitatud ka järgmises artiklis.

Seotud artikkel: Mis on projekti juhtimise kohustus süsteemiarenduses[ja]

See tähendab, et kas on võimalik süüdistada ühepoolset tasu mittetasumist kasutaja poolt, tuleb eelnevalt hoolikalt kaaluda. Vaadates varasemaid kohtuotsuseid, on palju juhtumeid, kus algselt nõudis müüja tasu ja esitas kohtuasja, kuid kasutaja esitas vastu kohustuse taastada algseisund või nõuda kahjutasu.

Kaaluge ka, kas äritegevuses on tõesti kasu

Isegi kui müüja argument läheb läbi ja kohtuasjas tunnistatakse, et tasu nõudmine on tegelikult võimalik, kui olukord läheb kohtuasjani, on tulevaste tehingute jätkamine praktiliselt keeruline. Lisaks, isegi kui kohtuasjas tunnistatakse teie argument, peaksite olema valmis selleks, et tasu saamiseks kulub palju aega. Kui arvestada ka kohtuasja läbiviimise vaeva ja kulusid, võib olla parem leida kompromiss ja püüda leida lahendus.

Kokkuvõte

Kui kasutaja ei nõustu tasu maksmisega ja soovime seda probleemi õiguslikult uurida, on vaja kontrollida mitut tüüpi dokumente. Lisaks ei piisa ainult dokumentide haldamise põhjalikkusest, vaid tuleb kaaluda ka seda, milliseid riske ja puudusi organisatsioon lõpuks kohtusse pöördudes võib kanda.

Kuigi dokumentide igapäevane haldamine võib tavaliselt kuuluda töökoha tasandi ülesannete hulka, võib otsus minna kohtusse säilitatud dokumentide ja materjalide põhjal olla oluline juhtimisotsus. Peaksime mõistma kogu protsessi, arvestades, et just sellistes erakorralistes olukordades proovitakse töökoha ja juhtkonna ühtekuuluvust ja organisatsioonilist jõudu.