A rendszerfejlesztési határidők késése és a jogi teljesítési késedelem kapcsolata
A rendszerfejlesztési projektek bizonyos értelemben mindig a határidőkkel való harcnak tekinthetők. A rendszerfejlesztés “határidői” szempontjából jogi nézőpontból megvizsgálhatjuk a “kockázatokat, amelyek akkor válnak nyilvánvalóvá, ha esetleg nem sikerül betartani a határidőt”.
Ebben a cikkben bemutatjuk, hogy milyen esetekben kezelhető a “határidő elmulasztása” teljesítési késedelemként, és milyen jogi felelősséget eredményezhet, például a kötelezettség nem teljesítése.
A határidők jelentősége a rendszerfejlesztésben
A határidő általános értelmezése
Az “határidő” általános értelmezése a vevő által kért termék szállításának időpontjára utal. A fejlesztési helyszínen, ahol előfordulhatnak váratlan problémák, a határidők betartása gyakran szigorú követelmény. Ha a megrendelő és a beszállító közötti erőviszonyokban különbségek vannak, a határidők betartásának tendenciája még hangsúlyosabbá válhat. Vagy esetleg, ha a határidőt túllépik, akkor a túllépés mértékének megfelelően kedvezményt adhatnak, vagy a túlórázásért nem számítanak fel díjat, és ingyenessé teszik. Mindenesetre, a határidő általában a kereskedelmi partnerrel való bizalmi kapcsolat fenntartása érdekében fontos.
A “munka befejezése” jogi fogalmáról és a határidőkről egy másik cikkben is olvashat.
https://monolith.law/corporate/completion-of-work-in-system-development[ja]
A határidő jogi szempontból
Jogi szempontból, amikor a szállító és a felhasználó szerződést köt, a szállítóra nézve kötelezettség (adósság) keletkezik a rendszer szállítására. És a határidő az a korlátozás, amelyet erre az adósság teljesítésének időpontjára állapítanak meg. Vagyis, a határidő késése az adósság nem teljesítésének egy típusa, a teljesítés késése. Tehát, ha a szállító szándékosan vagy hibájából kifolyólag késik a határidővel, akkor az adósság nem teljesítésének felelősségét (a Polgári Törvénykönyv 412. cikke) kell viselnie.
1. Ha az adósság teljesítésének meghatározott határideje van, az adós a határidő lejártától kezdve késedelemi felelősséget visel.
Polgári Törvénykönyv 412. cikk
2. Ha az adósság teljesítésének bizonytalan határideje van, az adós a határidő lejártától kezdve késedelemi felelősséget visel.
3. Ha az adósság teljesítésének határidejét nem határozták meg, az adós a teljesítési követeléstől kezdve késedelemi felelősséget visel.
Ebben a cikkben a “felelősséget visel” kifejezés egyszerűen kártérítési felelősséget jelent.
Ha az adós nem teljesíti az adósságát a követelés lényegének megfelelően, a hitelező kártérítést igényelhet a keletkezett kárért. Ha az adós a teljesítést az ő hibájából nem tudja megtenni, ugyanez a helyzet.
Polgári Törvénykönyv 415. cikk
Továbbá, ha a felhasználó a szállítónak “megfelelő időtartamot” határoz meg, és a szállító mégsem szállítja le a terméket a megadott időpontig, a felhasználó felbontja a szerződést.
Ha az egyik fél nem teljesíti az adósságát, és a másik fél meghatározott időtartamot határoz meg a teljesítés felszólítására, és a teljesítés nem történik meg ezen időszak alatt, a másik fél felbontja a szerződést.
Polgári Törvénykönyv 541. cikk
Egyébként, a “felbontás” opcióról általános magyarázatot adunk a következő cikkben.
https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]
Nem minden késedelmes szállítás jogi értelemben kötelezettségszegés
Az, hogy „nem sikerült betartani a határidőt”, nem feltétlenül jelenti azt, hogy jogi értelemben kötelezettségszegés történt. Ahhoz, hogy a puszta késedelmes szállítás jogi értelemben teljesítési késedelmet jelentsen, a következő feltételeknek kell teljesülniük:
| ・A határidő nem csupán irányelv, hanem a szerződés része, amelyet a szerződő felek kölcsönösen garantálnak. →A határidő szerinti teljesítés csak akkor tekinthető jogi értelemben „kötelezettségnek”, ha a határidő elmulasztása „kötelezettség” megszegését jelenti jogi értelemben. |
| ・A határidő elmulasztása a szállító oldalának szándékos vagy hanyagságból ered, és a szállító oldalán van a felelősség. →A rendszerfejlesztés alapvetően nem csak a szállító, hanem a felhasználó is kötelezettséget vállal. Tehát, ha a felhasználó nem teljesíti a kötelezettségét, és emiatt nem sikerül betartani a határidőt, a szállító oldal nem tehető felelőssé a teljesítési késedelemért. |
https://monolith.law/corporate/user-obligatory-cooporation[ja]
Mivel a rendszerfejlesztés általában olyan projekt, amelyben mind a felhasználó, mind a szállító oldal kötelezettséget vállal, előfordulhat, hogy mindkét fél kötelezettségszegését elismerik, és a kártérítési igényeket egymással szemben elszámolják.
https://monolith.law/corporate/project-management-duties[ja]
Továbbá, a határidő közeledtével általában a „teljesítés ellenőrzése” kerül sorra. Az ellenőrzésről részletesen olvashat az alábbi cikkben. Itt azt tárgyaljuk, hogy mi történik, ha a felhasználó nem hajlandó az ellenőrzésre, és emiatt a szállítás nem fejeződik be.
https://monolith.law/corporate/estimated-inspection-of-system-development[ja]
A lényeg, hogy a „nem sikerült betartani a határidőt = kötelezettségszegés” nem ilyen egyszerű. A határidő elmulasztása lehet a szállító hibája, de lehet a felhasználó hibája is, a okok sokfélék lehetnek. A „határidő elmulasztása” formai tény és a „teljesítési késedelem”, mint valós kötelezettségszegés, jelentős különbséget jelentenek a fogalmak szintjén is.
A teljesítési késedelemmel kapcsolatos bírósági ítéletek
Leírjuk azokat a bírósági ítéleteket, amelyekben vitatott volt, hogy a határidőkkel kapcsolatos szerződésszegési felelősség érvényesíthető-e vagy sem.
Tekintsük át az alábbi bírósági ítéleteket, amelyekben a határidők elmulasztása miatt vitatott volt, hogy a teljesítési késedelem alapján érvényesíthető-e a szerződésszegési felelősség vagy sem. Bár a határidőkkel kapcsolatos viták, a lényeg a “felhasználók együttműködési kötelezettsége”, a “projektmenedzsment kötelezettség”, és a rendszerfejlesztés alapjainak figyelembevétele a kérdések rendezésében. Ez nem különbözik más vitáktól.
Az eset, amikor a teljesítési késedelem a felhasználó együttműködési kötelezettségének megsértésével és hibával lett ellensúlyozva
Az alábbi idézett ítéletben a szállító határideje késedelmet szenvedett, ezért a felhasználó indított pert. Ez a kereset részben elfogadásra került a bíróságon, de ugyanakkor megállapították, hogy a felhasználó nem működött megfelelően együtt, és ez is hozzájárult a helyzethez. Az ítélet szerint a késedelem miatti károk 40%-át a felhasználó viseli.
A fentiek alapján megállapítható, hogy a felperes felhasználó nem hozott időben megfelelő döntéseket, például nem oldotta meg a vádlott által felvetett problémákat a célkitűzött határidőig, tehát nem működött megfelelően együtt. Azonban a felperes felhasználó által a vádlottnak tett további funkciók hozzáadására vagy módosítására vonatkozó kéréseivel kapcsolatban nem állítható, hogy a felperes felhasználó megsértette az együttműködési kötelezettségét, mivel bár elismerhető, hogy a felperes felhasználó kéréseket tett a fejlesztési tartalom hozzáadására vagy módosítására, amelyeket a jelen alapvető tervezési dokumentumban feltételeztek, a vádlott érvelése alaptalan.
Tokiói Kerületi Bíróság, 2004. március 10. (Heisei 16)
Ugyanígy, a felperes felhasználó túlzott kéréseivel kapcsolatban sem állítható, hogy a vádlott megsértette az együttműködési kötelezettségét, mivel nem ismerhető el, hogy a felperes felhasználó túlzott kéréseket tett a jelen számítógépes rendszerfejlesztési szerződés stb. díjaihoz képest, tehát nincs alapja.
Ellenkezőleg, megállapítható, hogy a vádlott projektmenedzsmentjében voltak hibák, például a feldolgozási számok (az adott év júliusi vagy augusztusi “feldolgozás” száma) megismerése 1999 (Heisei 11) januárja után, vagy a túlzottan magas további megbízási díjak terhelésének vagy a feldolgozás csökkentésének javaslata 1999 (Heisei 11) május 31. után.
A fenti ítélet elismeri a szállító határidejének késedelmét, de azt is megállapítja, hogy a késedelem egyik oka az volt, hogy a felhasználó nem oldotta meg a szállítótól kapott aggodalmakat, és ezért a felhasználó által hangoztatott károk 60%-át “levágta”, és elismerte a felhasználó követelését. Ez ugyanaz a “hibás ellensúlyozás” eljárás, mint amikor a baleset áldozatának is hibája van.
Ebben az ítéletben a “közreműködési kötelezettség” kifejezés több mint 40 alkalommal szerepel az egész szövegben, beleértve a tartalomjegyzéket is. Jogilag a kérdés inkább az volt, hogy a szállító projektmenedzsment kötelezettségét és a felhasználó közreműködési kötelezettségét hogyan lehet elkülöníteni.
Teljes mértékben elfogadott ítéletek a teljesítési késedelemről
Az alábbiakban idézett ítélet egy olyan esetben született, ahol a szállítói oldal felelőssége teljes mértékben bizonyítást nyert a határidő elmulasztásával kapcsolatban, és a teljesítési késedelem miatti szerződésszegési felelősséget elismerték. Ebben az esetben a felhasználó felmondta a szerződést a rendszer befejezése előtt, amire a szállítói oldal perrel válaszolt, de a felhasználó vitatkozott, mondván, hogy a késedelem az oka.
A vádlott a tervezési rendszerrel kapcsolatban számos változtatást javasolt, és ezek miatt a befejezés bizonyos mértékben késedelmet szenvedett, ezt nem lehet tagadni. Különösen a vádlott 2005. június 23-án (Heisei 17) adott utolsó változtatási utasítást, így a “szegélykövek részletes tételeinek automatikus számítása” funkció befejezetlenségét nem lehet a felperes hibájának tulajdonítani.
Tokiói Kerületi Bíróság, 2007. február 16. (Heisei 19)
Azonban a vádlott többi változtatási utasítása az év áprilisának első felében történt, és nincs olyan körülmény, amelyet úgy kellene értelmezni, hogy a tervezési rendszer befejezésének terve megváltozott (kivéve a vádlott június 23-i változtatási utasítását).
A felperes 2005. június végén nem fejezte be a tervezési rendszert olyan mértékben, hogy az valóban működőképes legyen (kivéve a június 23-i változtatási utasítás részeit), és a rendszer fontos részei, mint például a képmegjelenítés vagy a keresőfunkció, befejezetlenek voltak.
(…) Látható, hogy a felperes nem kezelte megfelelően a rendszerfejlesztési munkafolyamatokat.
Mindezek alapján nem lehet elfogadni, hogy a felperes nem tudta betartani a határidőt főként a vádlott utasításai miatt, és nem lehet elfogadni, hogy nincsenek olyan okok, amelyek a felperes hibájának tulajdoníthatók.
Ebben az ítéletben a bíróság kimondta, hogy a műszaki specifikációk változtatásának utasítása, amelyet a határidő előtt körülbelül egy héttel adtak ki, nem tehető a szállító hibájává, ha ez a funkció befejezetlen. Azonban,
- a változtatási utasításokra, amelyeket több hónappal korábban adtak ki, még mindig nem reagáltak,
- az utasítások kiadása óta a szállító is küldött e-maileket a befejezés várható dátumáról,
- a befejezetlen részek, mint például a képmegjelenítés vagy a keresőfunkció implementálása, a rendszer fontos részei, és a tény, hogy ezekre nem reagáltak, megerősíti a projektmenedzsment kötelezettségének megsértését,
figyelembe véve, a teljesítési késedelem miatti szerződésszegést elismerték.
Az ítéletek tartalmából levonható következtetések
Az ítéletek alapján elmondható, hogy a rendszerfejlesztés során felmerülő “határidő” kérdése végül is arra a problémára vezethető vissza, hogy hogyan húzzuk meg a felhasználók együttműködési kötelezettsége és a szolgáltató projektmenedzsment kötelezettsége közötti határvonalat. Vagyis, a jogi értelemben vett teljesítési késedelem, mint a kötelezettségszegés egy formája, azt jelenti, hogy a vita középpontjában az áll, hogy volt-e bármilyen kötelezettségszegés a szolgáltató részéről. És ennek eredményeként a károsodás ténye (azaz a felhasználói veszteség, amely a határidő elmulasztásával keletkezik), amely nyilvánvalóvá vált, annak vizsgálatához, hogy a szolgáltató felelőssé tehető-e, szükséges egyidejűleg megvizsgálni, hogy hogyan értelmezzük a felhasználó együttműködési kötelezettségét is.
Összefoglalás
A “teljesítési késedelem” kifejezés hallatán valóban úgy tűnhet elsőre, mintha ez csupán egy másik módja lenne a “határidő elmulasztása” formális tényének megfogalmazására. Azonban a teljesítési késedelem egyfajta szerződésszegés. Ezért inkább a “projektmenedzsmenti kötelezettség megsértése” pozíciójában értelmezendő.
A rendszerfejlesztési projektek “határidejének” kérdése nem csupán a felületes határidők betartására korlátozódik. Fontos, hogy a szolgáltató projektmenedzsmenti kötelezettségét és a felhasználó együttműködési kötelezettségét is figyelembe vegyük.
Category: IT
Tag: ITSystem Development
