Milyen megoldások léteznek, ha a felhasználói körülmények miatt megszakad a rendszerfejlesztés?

A rendszerszoftver-fejlesztési feladatok gyakran hosszú távú projektek formájában jelennek meg. De mi történik, ha a felhasználók egyszerűen azt mondják, hogy “nem szükséges már a rendszer, nem kell létrehozni”, miután már elkezdtek dolgozni a rendszerfejlesztésen? Mit tehet ilyenkor a szolgáltató?

Ebben a cikkben áttekintjük a rendszerfejlesztési szerződések jellegzetességeit, és bemutatjuk a lehetséges megoldásokat ilyen helyzetekben.

A felhasználói megszakítások jelentőségének megfontolása

A rendszerfejlesztési szerződéseknek vannak olyan sajátosságai, amelyek szerződésként tűnnek fel. Az egyik ilyen, hogy a munkaidő általában hosszú, és a szolgáltató oldalnak nagy mérlegelési jogkörrel és jelentős kötelezettséggel kell rendelkeznie a projekt menedzselése érdekében. A szolgáltató oldal által viselt projektmenedzsment kötelezettségek teljes tartalmát a következő cikkben részletesen ismertetjük.

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

Másrészt, a felhasználóknak, akik ügyfelek, széles körben kötelesek együttműködni a szolgáltató munkájában. Ha a rendszert a saját vállalatukon belül használják, nem lehet egyszerűen “átadni” a szolgáltatónak. A vállalat belső részéről is kötelesek együttműködni, hogy a szolgáltató szakértelmét kihasználva végezhesse a munkát. Ezt a kérdést a következő cikkben részletesen tárgyaljuk.

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

Ha összefoglaljuk a fentieket, a szolgáltató és a felhasználó között van egy “külső szolgáltató” és egy “fizető ügyfél” viszony, de ugyanakkor van egy olyan aspektus is, amelyben mindkét félnek együtt kell működnie a projekt céljainak elérése érdekében. Ez a kapcsolatok összetettsége nem jellemző a szokásos szabászokra, és a rendszerfejlesztési szerződések egyik nagy sajátossága. A rendszerfejlesztéssel kapcsolatos viták ezen összetett kapcsolatok miatt gyakran bonyolultak, és ha egyszer összekuszálódnak, jogilag hogyan kell rendezni a felek közötti kapcsolatot, ez gyakran bonyolult.

Ha a felhasználói oldal megváltoztatja a véleményét, és hirtelen azt mondja, hogy “végül is nincs szükség erre a rendszerre, tehát nem kell tovább haladni a projekttel”, akkor fontos megfontolni, hogyan kell értelmezni a felek jogait és kötelezettségeit. Ez egyfajta példa arra, hogyan kell alkalmazni a jogi gondolkodást ezen összetett szerződési kapcsolatok előtt. Az alábbiakban felsoroljuk azokat a kérdéseket, amelyeket ebben az esetben meg kell vizsgálni.

Először rendezzük a felmondás okait

A szolgáltató szemszögéből nézve, ha a felhasználó egyoldalúan megszakítja a projektet, ez nem feltétlenül jelenti azt, hogy a felhasználóval közös megértésben van. Vegyünk például egy olyan esetet, ahol egy projekt indult a külföldi telephelyen dolgozó kiküldetésben lévő munkavállalók HR rendszerének fejlesztésére, majd később a külföldi terjeszkedési tervet teljesen visszavonták, így a rendszer fejlesztése feleslegessé vált. Valóban, ezt a magyarázatot tekintve, a felhasználó egyoldalú változásának is tekinthetjük.

De mi van, ha a döntés hátterében olyan tényezők állnak, mint például a szolgáltató oldalán a projektmenedzsment kötelezettségeinek megsértése, mint például a késések, és a fejlesztési folyamat nehézségei is hozzájárultak a cég politikájának megváltozásához?

Ahogy korábban is említettük, a rendszerfejlesztés olyan folyamat, amelyben a szolgáltató és a felhasználó is nagy felelősséget vállal, és szorosan együttműködve haladnak előre. Ebből kifolyólag, ha a felhasználó szeretné megszakítani a projektet, és a szolgáltató úgy gondolja, hogy ez a felhasználó saját döntése, akkor fordítva is előfordulhat, hogy a szolgáltatót hibáztatják, és a szerződés megszegése vagy a közös megegyezés alapján történő felmondás lehetőségét hangoztatják.

Az, hogy a felmondás saját döntésen alapul, a szerződés megszegése miatt történik, vagy közös megegyezés alapján, nagymértékben függ a projekt előrehaladásától és a korábbi tárgyalások menetétől. Ezért, ha a szolgáltató úgy gondolja, hogy a felhasználó saját döntése alapján mond fel, fontos, hogy az ülések jegyzőkönyveiben is világosan rögzítsék ezt, hogy később ne legyen vita ebben a kérdésben.

A következő lépés a díjazás és kártérítés alapjául szolgáló jogszabályi rendelkezések ellenőrzése

A fentiek figyelembevételével, ha a felhasználó saját döntése alapján szeretne lemondani a szolgáltatásról, a következő lépés annak megvizsgálása, hogy a szolgáltató jogosult-e a felhasználótól a munka befejezési arányának megfelelő díjat, vagy kártérítést követelni.

Az ilyen esetekben hivatkozandó jogszabályi rendelkezések a szerződés típusától függnek. A rendszerfejlesztési szerződések nagyjából két csoportba sorolhatók: vállalkozási szerződések és megbízási szerződések.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

A Polgári Törvénykönyv (japán: Minpō) a következő rendelkezéseket tartalmazza a megbízási és vállalkozási szerződések esetében:

a.) Megbízási szerződés esetén
Díjazás: Polgári Törvénykönyv 648. cikk 3. bekezdés
Ha a megbízás a megbízott hibájából eredő okból a teljesítés közben szűnik meg, a megbízott a már teljesített munka arányában követelhet díjat.
Kártérítés: Polgári Törvénykönyv 651. cikk
1. A megbízást mindkét fél bármikor felmondhatja.
2. Ha az egyik fél a másik fél számára hátrányos időpontban mondja fel a megbízást, akkor a felmondó félnek kártérítést kell fizetnie a másik félnek. Ha azonban elkerülhetetlen okból történt a felmondás, akkor ez nem érvényes.

b.) Vállalkozási szerződés esetén
Kártérítés: Polgári Törvénykönyv 641. cikk
Amíg a vállalkozó nem fejezi be a munkát, a megrendelő bármikor felmondhatja a szerződést, és kártérítést követelhet.

Megjegyzendő, hogy a Polgári Törvénykönyv 641. cikk alapján követelhető kártérítés nem csak a már kifizetett költségeket, hanem a “szerződés felmondása nélkül realizálható lett volna” nyereséget is magában foglalja. Ez azt tükrözi, hogy értelmetlen lenne a törvénynek erőltetnie a munka befejezését, ha a megrendelő számára az már nem szükséges, és ilyen esetekben inkább a vállalkozó nyereségét kell biztosítani azzal, hogy ugyanannyi díjat fizet.

Azonban a Polgári Törvénykönyv 641. cikk alapján követelhető kártérítés gyakran kizárásra kerül a szolgáltató és a felhasználó közötti egyedi szerződésekben. Ilyen esetekben az egyedi szerződésben megállapodott feltételek (azaz a szerződés) érvényesülnek, és a Polgári Törvénykönyv rendelkezései nem alkalmazhatók, ezért óvatosság szükséges.

További előrelépés a teljesítés és a kár bizonyításában

Ha a felhasználók saját döntésük alapján felmondják a szerződést, a leggyakoribb, hogy a szerződés lehetővé teszi a teljesítés (azaz a befejezett rész) díjának és a kártérítési igénynek a benyújtását. Ezért általában a szolgáltató oldalán szükséges a teljesítés és a kár bizonyítása a kártérítési igény benyújtásához.

Ugyanakkor, a teljesítés, vagyis a befejezési arány bizonyítása gyakran nagyon nehéz feladat lehet. Ennek oka, hogy melyik munkaelem milyen mértékben lett befejezve, különösen, ha több alvállalkozó is van, a haladás ellenőrzéséhez szükséges interjúk mennyisége jelentős lehet. Ráadásul, ha az interjú eredményeit alátámasztó dokumentumokat kell készíteni, és az interjú tartalmát is dokumentálni kell, a munka mennyisége hatalmas lehet. Ha mindezek ellenére a bizonyítékot elégtelennek találják, a bizonyíték előkészítésére fordított erőfeszítések hiábavalóak lehetnek, és számos probléma merülhet fel.

Ezeket figyelembe véve, a megoldás lehet, hogy a szerződés előkészítési szakaszában előre meghatározzuk, hogy ha a szerződést közben felmondják, a felmondás időpontjáig a napok számát napi díj alapján számoljuk, vagy más módon egyszerűsítjük a számítást. Ezenkívül, mivel a teljesítés igazolása időigényes, lehet, hogy lemondunk a teljesítés alapján történő igénylésről, és helyette a “már elkészült részek fejlesztéséhez szükséges költségek” alapján nyújtunk be igényt. Ha a fejlesztési költségek belső költségek, akkor a “munkaóra × egységár” egyszerű képlet alapján könnyen kiszámíthatók. Különösen alacsony profitrátájú projektek esetén, ha a költségalapú igénylést részesítjük előnyben a teljesítés helyett, várhatóan könnyebb lesz a követelések behajtása, miközben a veszteségeket is kompenzáljuk. Ez gyakran reálisabb megoldás lehet.

Mit kellene megfontolniuk a felhasználóknak?

Mellettük, a felhasználóknak is vannak előzetesen megfontolandó szempontjaik, ha saját döntésük alapján szeretnének felmondani egy szerződést. Ilyen például, hogy a szolgáltatóval előzetesen tisztázzák a várható kártérítési összeget. Itt az “előzetes” szóval azt értjük, hogy nagyjából mennyi összegre számíthatnak, ami segít abban, hogy a későbbi tárgyalások során legyen egy irányadó összegük (a felmondási szándék kifejezése nem késlekedhet, ezért nem szükséges a pontos összeg).

Ha az előzetesen meghatározott összeg túlzónak tűnik, kérjenek indoklást. Azonban, ha túlzottan keményen próbálnak alkudozni a fizetendő összeg csökkentése érdekében, az felesleges pereskedéshez és a helyzet további bonyolódásához vezethet. Ha a két fél közötti tárgyalások nehéznek bizonyulnak, érdemes lehet jogi tanácsadóhoz fordulni.

Ebben a cikkben a rendszerfejlesztési szerződések létrejöttét vettük alapul a magyarázatokhoz, de a valós rendszerfejlesztési helyzetekben gyakran vitatott kérdés, hogy “valóban létrejött-e a szerződés”. Ezzel kapcsolatban részletesen tárgyalunk az alábbi cikkben.

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

Összefoglalás

Ebben a cikkben bemutattuk, hogyan kezeljük azt az esetet, amikor a projektet a felhasználó kényelme miatt szakítják félbe. Azonban a cikk legfontosabb pontja az, hogy “valóban a felhasználó saját kényelme miatt történt-e ez”, és “valóban nem volt hiba a szolgáltató részéről” – ezeket a kérdéseket kell először megvizsgálni.

A rendszerfejlesztési projektek jellemzője, hogy mind a szolgáltató, mind a felhasználó nagy felelősséget vállal. Ebből kifolyólag, ha nem vizsgáljuk meg előzetesen, hogy valóban lehetséges-e a felelősség egyoldalú hárítása, akkor ez további problémákat okozhat. Ezt a szempontot érdemes szem előtt tartani.