A rendszerfejlesztés befejezése után a szállító által viselt támogatási kötelezettség

A rendszerfejlesztés terén jól ismert, hogy a rendszerfejlesztés szakértői, a szolgáltatók, a “projektmenedzsment kötelezettséget” viselik, de a jogi szempontból hasonló, de mégis különböző fogalomként a “támogatási kötelezettség” is felmerül. Ebben a cikkben a “támogatási kötelezettségről” fogunk beszélni, figyelembe véve a korábbi bírósági ítéleteket is.

A támogatási kötelezettség jelentése

A támogatási kötelezettség áttekintése

A szolgáltatók által a felhasználók felé vállalt kötelezettségek közül a legjellemzőbb a projektmenedzsment-kötelezettség. Ez a kötelezettség a korábbi bírósági ítéletekben többször is megjelent, és a rendszerfejlesztési szakértőként a szolgáltatók által a teljes projekt során vállalt kötelezettségeket összefoglaló fogalom.

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

A projektmenedzsment-kötelezettség a rendszerfejlesztési jogi terminológiában nagyon ismert, és kétségtelen, hogy ez a szolgáltatók által vállalt fő kötelezettség. Azonban néhány bírósági ítéletben megjelenik egy másik, a projektmenedzsment-kötelezettségtől eltérő kötelezettség, amelyet “támogatási kötelezettség”-ként ismerünk.

A támogatási kötelezettség a felhasználók működtetési támogatásával kapcsolatos problémákban merül fel

De mi is a támogatási kötelezettség? És miért hívják ezt a kötelezettséget külön néven a projektmenedzsment-kötelezettségtől? A támogatási kötelezettség általában a rendszerfejlesztési projekt befejezése után merül fel. A rendszerfejlesztési projektek, mivel “fejlesztési” projektek, alapvetően akkor érnek véget, amikor a létrehozandó rendszer elkészül. Vagyis a rendszerfejlesztési projekt azzal kezdődik, hogy tisztázni kell, milyen rendszert kell létrehozni (=követelmények meghatározása), és azzal ér véget, hogy ellenőrizzük, hogy a rendszer valóban elkészült-e (=tesztelés vagy átvétel). Az átvételi folyamatról, amelynek “a rendszerfejlesztési projekt befejezése” szempontjából fontos jelentősége van, és a jogi problémákról, amelyek gyakran merülnek fel ebben a szakaszban, a következő cikkben részletesen tárgyalunk.

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

Az viszont, hogy a rendszerfejlesztési projekt maga a fejlesztési folyamat, még ha úgy is értelmezzük, a fejlesztett rendszert a későbbiekben természetesen üzleti tevékenységben fogják használni. Vagyis, ha teljesen figyelmen kívül hagyjuk azt a kérdést, hogy a rendszer fejlesztése után hogyan fogjuk azt használni, és azt mondjuk, hogy “mivel csak a fejlesztési munkát végzem, elég, ha csak létrehozom a rendszert”, akkor nagy valószínűséggel irracionális helyzetet teremtünk. Ezt figyelembe véve, a korábbi bírósági ítéletekben is felmerült a kérdés, hogy a rendszerfejlesztést végző szolgáltatókra is lehet-e működtetési támogatási kötelezettséget róni. Vagyis, a kérdés az, hogy a rendszerfejlesztési szerződésben a szolgáltató által vállalt kötelezettségek között szerepel-e a fejlesztés utáni működtetési támogatási kötelezettség is. Mivel a működtetési támogatás nem része a fejlesztési folyamatnak, ezért a projektmenedzsment-kötelezettségtől való megkülönböztetés érdekében a “támogatási kötelezettség” kifejezést használták.
　

Milyen ítéletekben merült fel a támogatási kötelezettség kérdése?

Egy példa, amikor a rendszertesztelés során a felhasználó munkáját akadályozták

Az alábbi idézett ítéletben a rendszer működését megelőző rendszertesztelés során a felhasználó nem tudta a rendszert úgy használni, ahogyan azt eredetileg elképzelte, és ennek eredményeként a felhasználó felhagyott a rendszer működésével. Ez a probléma a felhasználó működésének kezdeti problémája volt, és a kérdés az volt, hogyan lehet a szolgáltató felelősségét a rendszerfejlesztési szerződésből eredően alátámasztani. A végső következtetés az volt, hogy a felhasználó kártérítési igényét elismerték, és ennek alapjául a “támogatási kötelezettség megsértése” szolgált.

I. Támogatási kötelezettség megsértése
(A) A felperes képviselője 1997. július 14-én (Heisei 9) a vádlottnak azt mondta, hogy “Nem csak a rendszert kell létrehozni, hanem gondoskodni kell arról is, hogy az rendesen működjön.“, “Mi laikusok vagyunk, sok pénzt adunk, ezért szeretnénk, ha a végéig használhatnánk.“. Erre válaszul a vádlott magyarázta, hogy képes létrehozni egy olyan rendszert, amely eléri a felperes bevezetési céljait, és megígérte, hogy támogatja a rendszer használatát, amíg az rendesen működik. Ezzel a felperes és a vádlott között létrejött egy megállapodás, amely szerint a vádlott támogatja a felperest, amíg a rendszer rendesen működik.
A vádlott támogatási kötelezettségét a felperessel szemben a szerződéses díj “csomagbevezetési támogatás” című tételében 17,26 millió forint költséget számoltak fel, a becslésben a havi karbantartási díj “ingyenes karbantartás a bevezetés utáni hat hónapban” szöveggel szerepel, és a “Jövőbeli SE támogatás (belső megbeszélés anyaga)” című dokumentumban a friss rendelés és a “bevezetési eljárás (terv) létrehozása” és a “data/működési ellenőrzési munka” SE támogatásának megerősítése is szerepel.

(B) A vádlott támogatási kötelezettsége a felperessel szemben konkrétan legalább a következőket jelenti: a vádlott a felperes számára ①megfelelő tanácsot nyújt a rendszer működésének módjáról, ②részt vesz a működési tesztben és kezeli a teszt során felmerülő rendszerhibákat, ③javítja a rendszert a működési teszt eredményei alapján, ④bevezető oktatást tart az operátoroknak.
Az alperes azonban, annak ellenére, hogy a működési teszt során számos probléma merült fel, nem vette komolyan ezeket, és csak az operátorok bevezető oktatásának költségeit követelte, és nem nyújtott semmilyen megfelelő támogatást a felperesnek a rendszer működésének elindítása érdekében.

Tokiói Kerületi Bíróság Hachioji Fiókja, 2003. november 5-i (Heisei 15) ítélete

Ebben az ítéletben, beleértve a tartalomjegyzéket is, a “támogatás” szó mintegy 30 alkalommal szerepel az egész ítéletben. A felhasználók igényeinek megfelelő támogatást kérő hangjuk közvetlenül az ítéletben szerepel, ami azt sugallja, hogy a döntés a probléma részletes mérlegelése után, igazságos megoldásra törekedve született. Különösen figyelemre méltó pontok a jelen eset megértésében:

• A támogatási kötelezettség megsértése “szerződésszegésként” kezelt, és ennek eredményeként a következményeként keletkezett kártérítési igényt is elrendelték.
• A “projektmenedzsment kötelezettség” kifejezés nem szerepel az ítéletben.

Ez azt sugallja, hogy bár a projektmenedzsmenttől eltérő fogalom, a rendszerfejlesztési szerződésben foglalt szerződéses kötelezettségként kezelik.

A támogatási kötelezettség természetét hogyan kell értelmezni

A támogatási kötelezettség még mindig nem egyértelmű fogalom

Az előzőleg említett bírósági ítélet lényegében azt mutatja, hogy a rendszerfejlesztést végző szállítónak a felhasználó működésbe hozatalához szükséges támogatást is nyújtania kell. Azonban a támogatási kötelezettség nem olyan gazdag bírósági gyakorlatban, mint a projektmenedzsment kötelezettség, és a valóságát ismerő nyomok sem olyan széles körben elérhetőek. Különösen a “támogatás” kifejezés maga is tartalmazza azt a problémát, hogy nem egyértelmű, mit kell konkrétan tenni.

A támogatási kötelezettség nem korlátlanul elismerhető

Ezenkívül a szállító támogatási kötelezettségének megsértését elismerő fenti ítélet is nagyon fontos pontot tett.

A vádlottat úgy kell értelmezni, hogy a jelen szerződés alapján köteles bizonyos támogatást nyújtani a felperesnek a felperes által épített és átadott rendszer működtetéséhez. Azonban a tartalma nem úgy értelmezhető, mint ahogy a felperes állítja, hogy korlátlan ideig, ingyenesen mindenféle támogatást nyújt, amíg a felperes ténylegesen képes működtetni a rendszert.

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

Ha a fő feladat a rendszer “fejlesztése”, akkor a későbbi “működés” támogatására vonatkozóan is vannak korlátozások. Ezt az ítéletben is megemlítették, figyelembe véve a szállító oldalra nehezedő nagy terhet, ha a támogatási kötelezettség fogalma korlátlanul kiterjed.

A támogatási kötelezettség valósága a felhasználó együttműködési kötelezettségével együtt vizsgálandó

Az eddig elmondottak lényegében arról szólnak, hogy “a rendszerfejlesztés kezdeti szakaszában, hogyan osztoznak a munkaterhelésen a felhasználó és a szállító”. Ez magában foglalja a kissé bonyolult kérdést is, hogy a “fejlesztés” szerződéséből milyen mértékű jogi kötelezettséget vállal a szállító a működés megkezdésekor. Ugyanakkor el kell ismerni, hogy erős a tendencia az egyedi körülmények figyelembe vételére.

Mindazonáltal, a szállító által viselt támogatási kötelezettség valósága a felhasználó együttműködési kötelezettségének megértésével válik biztosabbá.

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

Az új rendszerrel való munkafolyamat-javítási kezdeményezés alapvetően a technikai szakértő szállító és a belső munkafolyamat-tudással rendelkező felhasználó közös munkája. Ezért a támogatási kötelezettség kérdésében is, ha a felhasználó egyértelműen meghatározza, mely kérdéseket kell megoldania az “együttműködési kötelezettség teljesítése” keretében, a hatáskör is magától értetődően meghatározódik.

Összefoglalás

Ebben a cikkben a projektmenedzsment alapjaira építve rendeztük a ‘támogatási kötelezettség’ koncepcióját, amelyet a projektmenedzsment egyfajta származékosának is tekinthetünk. A támogatási kötelezettség fogalma még mindig sok homályos pontot tartalmaz, de úgy gondoljuk, hogy a megértésében kulcsfontosságúak a ‘projektmenedzsment kötelezettség’ és a ‘kooperációs kötelezettség’ alapvető kérdései.