A jogi következmények, ha a rendszerfejlesztési díjat nem fizetik ki
A rendszerek fejlesztését vállaló szolgáltatók számára talán a legnagyobb kockázatot az jelenti, ha a felhasználók nem hajlandóak fizetni a szolgáltatásért, annak ellenére, hogy a rendszer már át lett szállítva. A rendszerfejlesztés költségeinek nagy részét a programozók és más képzett szakemberek alkotják, így gyakran jelentős személyi költségekkel jár. Az eladások behajtásának elmaradása időnként létfontosságú problémává válhat. Ebben a cikkben jogi szempontból megvizsgáljuk, milyen kérdéseket kell mérlegelnie a szolgáltatónak, ha a felhasználó nem hajlandó fizetni a szolgáltatásért.
Először is, ellenőrizni kell, hogy lehetséges-e a díjazás igénylése
- A szolgáltató már leszállította a terméket a felhasználónak, de a felhasználó nem fogadja el a szállítást, és emiatt a díjazás igénylése is elakad.
- A szolgáltató úgy gondolta, hogy a termék átvétele már megtörtént, de valamilyen eltérés van a felhasználó értelmezése és a sajátja között, és a felhasználó nem hajlandó fizetni a díjazást.
Ezek a helyzetek valóságosan is előfordulhatnak.
Megjegyzendő, hogy a felhasználó által ellenőrzött és elfogadott rendszer specifikációkat a rendszerfejlesztés terminológiájában “átvételnek” hívjuk. Az átvétel jelentőségéről és a teendőkről, ha az nem halad előre megfelelően, részletesen tárgyaljuk az alábbi cikkben.
Kapcsolódó cikk: A rendszerfejlesztés átvétele és a feltételezett átvételi záradék alkalmazása[ja]
Bár az átvételről általánosságban a fenti cikkben beszélünk, jogilag fontos megvizsgálni, hogy a felhasználó átvétele teljesült-e, figyelembe véve a “feltételezett átvételi záradék” rendelkezéseit.
Ezt szem előtt tartva, az első dolog, amit meg kell vizsgálni, ha a felhasználó nem hajlandó fizetni a díjazást, a következő:
- Vajon a munka már befejeződött-e, vagy még nem?
- Alkalmazható-e a hibás teljesítésért való felelősség (a Polgári Törvénykönyv 635. cikke)?
Azért kell először ellenőrizni a fenti két pontot, mert ha a munka már befejeződött, és nincs alkalmazva a hibás teljesítésért való felelősség (a Polgári Törvénykönyv 635. cikke), akkor még ha pereskedés is kezdődik, nem várható, hogy a díjazást megkapjuk.
De hogyan vizsgálhatjuk meg konkrétan a fenti két pontot? Nézzük meg, milyen dokumentumokat kell ellenőriznie a szolgáltató felelősének.
Azok a dokumentumok, amelyeket a díjazás igénylésének megvizsgálásához kell ellenőrizni
| Szállítólevél Ha nincs szállítólevél, akkor feltételezhető, hogy a szállítás még nem történt meg, és a munka még nincs befejezve. |
| Az átvétel eredményét közlő dokumentum Ez a legfontosabb dokumentum, amikor arról döntünk, hogy a munkát befejezettnek tekinthetjük-e. Ezenkívül, ha a felhasználó kényelme miatt az átvétel elhalasztásra kerül, érdemes ellenőrizni, hogy a szerződésben hogyan szerepel a “feltételezett átvételi záradék”. |
| Feladatkezelési lista Ez a dokumentum szolgál arra, hogy megtudjuk, milyen feladatokat találtunk eddig, és milyen intézkedéseket hoztunk. Ezenkívül ez a dokumentum szolgál arra is, hogy megértsük a szállítás után felmerült hibák és problémák helyzetét, valamint a javítások állapotát. |
| Követelménydefiníciós dokumentum, tervezési dokumentum és változáskezelési dokumentum, különböző ülések jegyzőkönyvei stb. Ezek a dokumentumok arra szolgálnak, hogy tisztázzák, milyen megértés volt eredetileg a felhasználó és a szolgáltató között, és hogy mi számít hibának vagy problémának. |
Megjegyzés: A fejlesztendő rendszer specifikációinak változásainak kezeléséről és a változáskezelési dokumentum elkészítésének módjáról részletes magyarázatot adunk egy másik cikkben.
Kapcsolódó cikk: A jogi szempontból nézve, hogyan kell kezelni a változásokat a rendszerfejlesztés során[ja]
| Felmondási értesítés vagy a felhasználó szándékát rögzítő dokumentum Ez a módszer arra szolgál, hogy megismerjük a felhasználó szándékát, ha nem kívánja folytatni az átvételt (vagy nem hajlandó fizetni a díjat). |
Következő lépés: meghatározni, mennyi díjat lehet felszámolni
Az, hogy mennyi díjat lehet felszámolni, alapvetően a szerződésben van meghatározva. Azonban előfordulhat, hogy a specifikációk megváltoztatása vagy hasonló módosítások után nincs megfelelő szerződés (vagy ahhoz hasonló dokumentum). A specifikációk megváltoztatása, új funkciók hozzáadása és más utólagos okok miatt szükség lehet a költségvetés újraszámítására. Ezt a folyamatot részletesen ismertetjük az alábbi cikkben.
Kapcsolódó cikk: Lehetséges-e a rendszerfejlesztési költségvetés utólagos növelése?[ja]
A költségvetés újraszámításának módja a fenti cikkben található, de különösen a díj növelésének lehetőségét vizsgálva:
- Az extra fejlesztési és funkció javítási részek költségvetésének megléte és tartalma
- A felhasználók reakciója a költségvetésre
- Az extra fejlesztési és funkció javítási részeket tartalmazó feladatkezelő táblázatban szereplő információk, és a díjra vonatkozó megállapodás megléte
Ezeket a szempontokat kell figyelembe venni. A lényeg az, hogy meg kell vizsgálni, vajon a felhasználók egyetértettek-e azzal, hogy “ezért az összegért rendeljük meg a munkát” (vagyis létrejött-e a szerződés).
Végül, vizsgáljuk meg a pereskedés során felmerülő kérdéseket
Figyeljünk a visszaper lehetőségére
A rendszerfejlesztés során, ha a felhasználó vagy a szolgáltató perel, gyakran előfordul, hogy a másik fél visszaperel. Ez azt jelenti, hogy ha a felhasználó nem hajlandó fizetni, akkor valószínűleg van valamilyen érvényes indoka.
A rendszerfejlesztés során a felhasználónak is vannak kötelezettségei, de először is, nem szabad elfelejtenünk, hogy a szolgáltató, mint a rendszerfejlesztés szakértője, nagy felelősséggel és széles körű mérlegelési jogkörrel rendelkezik. A szolgáltató által a rendszerfejlesztés során viselt projektmenedzsment kötelezettségekről a következő cikkben tárgyalunk részletesen.
Kapcsolódó cikk: Mi a projektmenedzsment kötelezettség a rendszerfejlesztés során?[ja]
Tehát, azt kell megvizsgálnunk, hogy a felhasználó, aki egyoldalúan nem hajlandó fizetni, felelőssé tehető-e. A korábbi bírósági ítéleteket vizsgálva, gyakran előfordul, hogy a szolgáltató kezdeményezett fizetési igényt, de a felhasználó visszaperelt, követelve az eredeti állapot helyreállítását vagy kártérítést.
Meg kell vizsgálni, hogy valóban előnyös-e a pereskedés
Ha a szolgáltató érvei érvényesülnek, és a bíróság elismeri, hogy jogosan követelhető a fizetés, de a helyzet pereskedésig fajul, akkor valószínű, hogy a további üzleti kapcsolatok fenntartása problémás lesz. Ráadásul, még ha a bíróság elismeri is a szolgáltató érveit, számítani kell arra, hogy a fizetés megérkezése jelentős időt vehet igénybe. Ha figyelembe vesszük a pereskedés költségeit és időigényét, gyakran jobb megoldás lehet a kompromisszum keresése.
Összefoglalás
Ha a felhasználók nem hajlandók fizetni a jutalmat, a probléma jogi vizsgálatához szükség van többféle dokumentum ellenőrzésére. Ezen túlmenően, nem elég, ha csak a dokumentumkezelés alapos, meg kell vizsgálni azt is, hogy milyen szervezeti kockázatokkal és hátrányokkal jár, ha végül pereskedésre kerül sor.
A dokumentumkezelés napi szintű alapossága valóban a helyszíni szintű munkához tartozik általában. Azonban, ha a tárolt dokumentumok és anyagok alapján pereskedésre kerül sor, ez súlyos üzleti döntéssé válhat. Ebben a rendkívüli helyzetben nem csak a helyszíni és a vezetői csapat összefogása és szervezeti ereje kerül próbára, hanem fontos, hogy megértsük az egész folyamatot.
Category: IT
Tag: ITSystem Development
