Az eljárás, ha a rendszer hibái a szemle után derülnek ki

A rendszerfejlesztés általános értelemben a következőképpen zajlik: a követelmények meghatározása fázisában döntött tartalom alapján halad előre a program implementálása, végül mind a felhasználó, mind a szolgáltató ellenőrzi, hogy a végeredmény megfelel-e a specifikációknak. A projektet a tesztelési fázis sikeres lezárása után tekintjük befejezettnek.

Viszont a valóságban előfordulhat, hogy olyan hibák és problémák merülnek fel, amelyeket a tesztelési fázisban vagy a projekt lezárásakor nem sikerült észlelni, és ezek csak a későbbi üzemeltetési fázisban válnak nyilvánvalóvá. Ha egyszer elfogadtuk a szállítást, jogilag milyen követeléseket tehetünk?

Nem meglepő, ha hibák maradnak a tesztelési fázis vagy az átvételi eljárás után

Műszaki szempontból nézve, nem ritka, hogy különféle hibák és problémák merülnek fel a szállítói oldal tesztelési folyamatainak befejezése és a felhasználói oldal átvételi eljárásának sikeres lezárása után. A felhasználók általában a képernyőn látható bemeneti és kimeneti adatok ellenőrzését végzik az átvételi eljárás során. Azonban az IT rendszerek gyakran bonyolultabbak és részletesebbek, mint amit a felhasználók a képernyőn látnak, beleértve a háttérben futó adatbázisokat és a különböző számításokat és vezérléseket végző programokat. Emiatt a felhasználói szemszögből végzett képernyőn látható bemeneti és kimeneti adatok ellenőrzése korlátozott. Ezért nem reális, hogy az ellenőrzés során minden lehetséges hibát és problémát kimerítően ellenőrizzenek, amelyek a későbbi üzemeltetési fázisban előfordulhatnak.

A fentiek hasonlóképpen érvényesek a fejlesztői oldal szemszögéből is. Például a beépített programok tartalmának hibáinak és problémáinak ellenőrzése a “tesztelési fázis”. Azonban a tesztelési fázis során nem feltétlenül lehetséges minden lehetséges hiba és probléma kimerítő ellenőrzése. A fejlesztett rendszer tényleges üzleti használatba vételét követően, a szállítói oldal által nem várt műveletek történhetnek, vagy nagy mennyiségű adat regisztrálódhat, vagy több felhasználó egyszerre léphet be. Mindezek ellenére, egy rendszer létrehozása, amely továbbra is zökkenőmentesen működik, igényli a kiváló technikai képességeket.

Az átvételi és tesztelési szakaszokban nem reális minden lehetséges hibát és problémát felfedezni, és az IT rendszerek esetében gyakran előfordul, hogy a tényleges használatba vétel után különféle problémák merülnek fel. Ezt először is meg kell érteni.

Az adósság teljesítése általában elfogadott

De mi a teendő, ha ilyen problémák merülnek fel? Jogi sorrendben rendezzük a dolgokat.

Először is, ha utólagosan is, de különféle hibák és problémák merülnek fel, a felhasználók valószínűleg felelősségre akarják vonni a szállítót, akivel eddig üzleti kapcsolatban álltak. Azonban általában, ha a szállítás már befejeződött és az átvétel is sikeres volt, az adósság nem teljesítése alapján a felelősség megállapítása gyakran nehéz.

Alapvetően a rendszerfejlesztési szerződések, ha nincs különleges megállapodás, a program implementációjára vonatkozó szabályokat a Polgári Törvénykönyv szerinti vállalkozási szerződés szabályai határozzák meg. A vállalkozási szerződés jellegéről a következő cikkben adunk részletes magyarázatot.

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

A vállalkozási szerződésben a “munka befejezése” az adósság teljesítésének követelménye. A “munka befejezése” pontos jelentéséről a következő cikkben adunk részletes magyarázatot.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Itt magyarázzuk, hogy a korábbi ítélkezési gyakorlat szerint a vállalkozási szerződésben a “munka befejezése” a rendszerfejlesztés kontextusában az összes fejlesztési folyamat befejezését jelenti. És magyarázzuk, hogy a fejlesztési folyamat teljes befejezése után felmerülő hibák és problémák a vállalkozási szerződés hibáinak garanciális felelősségét jelentik.

Összefoglalva, ha egyszer elfogadták a szállítást és az átvétel is sikeres volt, akkor általában az adósság már teljesítettnek tekinthető, és a további minőségi garancia kérdése, azaz a hibák garanciális felelősségének megállapítása lesz a kérdés.

Felelősség megállapítása a hibáért felelősségi alapon

De hogyan kell eljárni, ha a szállítótól a hibáért felelősségi alapon választ várunk? Nézzük meg a következő lépéseket.

Először is ellenőrizzük a hibák és problémák súlyosságát és mértékét

Ha a hibák és problémák utólag derülnek ki, és ezek jogi értelemben “hibásak”, akkor a hibák és problémák súlyossága lesz a kérdés. A jogi hibák kérdése alapvetően három kategóriába sorolható:

1. A hibák és problémák, bár léteznek, csak jelentéktelenek, és jogilag nem tekinthetők “hibásnak”.
2. A hibák jogilag “hibásnak” minősülnek, de a szerződés célját még mindig el lehet érni.
3. A hibák jogilag “hibásnak” minősülnek, és a szerződés célját sem lehet elérni.

Ez a három kategória határozza meg, hogy a hibáért felelősségi alapon milyen felelősséget lehet érvényesíteni. Az 1. és 2. kategória közötti határ az, ami a felelősség megállapítását határozza meg, míg a 2. és 3. kategória közötti határ az, ami a szerződés felbontásának lehetőségét határozza meg.

634. cikk

1. Ha a munka tárgyában hiba van, a megrendelő kijelölhet egy megfelelő időszakot, amely alatt a vállalkozótól a hiba kijavítását kérheti. Azonban, ha a hiba nem jelentős, és a javítás túlzott költségeket igényel, ez nem vonatkozik rá.

2. A megrendelő kártérítést is kérhet a hiba kijavítása helyett, vagy annak mellett. Ebben az esetben a 533. cikk rendelkezéseit alkalmazzuk.

635. cikk

Ha a munka tárgyában hiba van, és emiatt a megrendelő nem tudja elérni a szerződés célját, a megrendelő felbonthatja a szerződést. Azonban, ez nem vonatkozik az épületekre és más földművekre.

A “hiba” fokozatos megkülönböztetését részletesen tárgyaljuk a következő cikkben:

https://monolith.law/corporate/defect-warranty-liability[ja]

Következő lépésként tisztázzuk, mit kell kérnünk a szállítótól

Ezután tisztázni kell, mit kell kérnünk a másik féltől. Ha szeretnénk felbontani a szerződést, nem elég csak azt bizonyítani, hogy van hiba, hanem azt is bizonyítani kell, hogy ez “megakadályozza a szerződés céljának elérését”. A “cél” meghatározásánál fontosak lehetnek a rendszerfejlesztési projekt kezdetén tartott megbeszélések jegyzőkönyvei, a specifikációkban szereplő adatok stb. Mivel a hibák és problémák utólag is felmerülhetnek, még a projekt befejezése után is gondosan meg kell őrizni az összes dokumentumot.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Megjegyzendő, hogy a szerződés felbontása mellett a hibáért felelősségi alapon követelhető dolgok közé tartozik a kártérítési igény és a hiba kijavításának igénye is.

Egyéb figyelembe veendő szempontok

Ha jogi lépéseket teszünk, például szerződést bontunk, figyeljünk a módszerre

Ha a hibáért való felelősség tartalmaként szerződést bontunk, fontos, hogy elsajátítsuk a bontáshoz szükséges jogi adminisztrációs eljárásokat is. A szerződésbontás hatásairól, az érvényes szándéknyilvánítás módjáról, a későbbi problémák elkerülése érdekében a bejelentések megfelelő módjáról a következő cikkben adunk részletes magyarázatot.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

A viták helyett a tárgyalások formájában történő megoldás a kívánatos

Ezen jogi érvelések nem csak akkor érvényesek, ha bírósági per kezdődik. A bírósági vitarendezés mindkét fél számára nagy terhet jelent. Ehelyett, a bírósági eljárás előtti tárgyalási szakaszban is nagy hasznát vehetjük ezeknek az ismereteknek. A jogi ismeretek jelentőségéről a bírósági eljárásokon kívüli tárgyalásokban a következő cikkben adunk magyarázatot.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

A hibákat és a funkcióhiányokat külön kell kezelni

Az implementált funkciók és specifikációk hibái, illetve hiányosságai esetén a vita más jellegű. Ha például a szükséges funkciók nincsenek megfelelően megvalósítva, akkor előfordulhat, hogy a szerződéses munka “befejezését” nem fogadják el, és a kötelezettség teljesítését sem ismerik el.

Másrészt, ha a szükséges funkciók és specifikációk hiányoznak, de a felhasználó nem adott megfelelő információt a követelmények meghatározása során, akkor előfordulhat, hogy a szerződés egy részének tekintése eleve helytelen, és ezt értékelni kell.

Összefoglalás

A projekt folyamatában felmerülő problémák akár a projekt folyamatában is kiderülhetnek, de előfordulhat, hogy csak az üzemeltetési szakaszban vagy utána derülnek ki. Úgy tűnik, hogy a rendszerfejlesztési projektek jellegzetessége, miszerint még a teljes folyamat sikeres befejezése után sem lehetünk teljesen nyugodtak, éppen a “hibabiztosítási felelősség” rendszerében testesül meg. Fontosnak tartjuk, hogy a projekt befejezése után is szem előtt tartsuk a dokumentumkezelés alaposságát, és megértsük ezt a folyamatot.