Milyen együttműködési kötelezettségeket kell vállalnia a rendszerfejlesztést megrendelő felhasználónak?

A rendszerek fejlesztése során, minél nagyobb a fejlesztendő rendszer, annál több emberi erőforrásra és munkaórára van szükség. Ezért nem csak a fejlesztést vállaló szállítói oldalnak, hanem a rendszerfejlesztést megrendelő felhasználói oldalnak is bizonyos együttműködési kötelezettségei vannak.

Ez eltér a szokásos megrendelői és szállítói viszonytól. Például, ha nem IT rendszert, hanem egyedi öltönyt rendelünk egy öltönyboltból, a megrendelő, azaz a vásárló (felhasználó) oldalnak nincsenek különösebb “kötelezettségei”. A “kötelezettségeket” kizárólag a megrendelést teljesítő öltönybolt (szállító) viseli. Az IT rendszerek, melyekhez sok emberi erőforrásra és munkaórára van szükség, éppen ezért igénylik a felhasználók “együttműködését” a szállítóval.

Ebben a cikkben bemutatjuk, milyen jogi kötelezettségek terhelik a megrendelőt a szállítóra hagyatkozás helyett a rendszerfejlesztés során.

Saját rendszerünk lévén, nem lehet mindent ‘teljes mértékben kiszervezni’

Egyetlen rendszerfejlesztési projekt esetében is gyakran számos személy és szervezet vesz részt. Természetesen szükség van a kódolási technikában jártas mérnökökre és programozókra, de az ilyen munkaerő kimenetelét egyetlen eredménnyé összefoglalni a projektmenedzser szerepe is fontos.

Azonban, akármilyen magas technikai és szervezeti képességekkel rendelkezik is a szállító, a rendszerfejlesztést nem lehet csak a szállító erőfeszítéseivel véghezvinni. Például a cég belső használatára szánt szakkifejezésekről vagy a cég sajátos üzleti ismereteiről a szállító egyoldalú erőfeszítéseivel nem tudhat. Minél nagyobb a rendszer fejlesztése, annál általánosabb a tendencia, hogy a rendszert alkalmazó cég maga is nagyvállalat, amely számos embert és feladatot foglal magában. A rendszerfejlesztési projekt sikeréhez valójában gyakran a számítógépes munka előtt az ilyen üzleti logika rendezése a legnagyobb súlyt képviseli.

Ezért a felhasználóknak nem szabad passzívvá válniuk azzal az indokkal, hogy “nem vagyok IT-szakértő”, hanem inkább aktívan kell információt szolgáltatniuk, hogy a projekt zökkenőmentesen haladhasson. Ebben az értelemben a felhasználók szerepe a rendszerfejlesztési projektekben valójában nem kicsi.

A felhasználói együttműködési kötelezettség a bírói gyakorlat alapján

De pontosan milyen együttműködési kötelezettségek terhelik a felhasználókat a rendszerfejlesztési projektekben? Ezzel kapcsolatban számos útmutatást találhatunk a korábbi bírói gyakorlatban.

A bírósági eljárásokban a szolgáltató (alperes) késedelmes teljesítése miatt a felhasználó (felperes) döntéshozatalának késlekedése és egyéb tényezők miatt vitatottá vált a felhasználó fejlesztési együttműködési kötelezettsége. Ebben az ügyben a bíróság megállapította a felhasználó együttműködési kötelezettségének megsértését, és elutasította a szolgáltató szerződésszegési felelősségét. (A szerződés felbontását ugyan elismerték, de itt is 60%-os hibaeloszlást alkalmaztak.)

A jelen informatikai rendszerfejlesztési szerződés egyedi rendszerfejlesztési szerződés, amelyben a megbízott (szolgáltató) önmagában nem képes befejezni a rendszert, ezért a megbízó (felhasználó) köteles a fejlesztési folyamat során belső véleményeket összehangolni, egységes nézetet kialakítani, világosan közölni a megbízottal, milyen funkciókat kíván, együtt a megbízottal megvizsgálni a kívánt funkciókat, végső soron a funkciókat meghatározni, továbbá, a képernyőt és a nyomtatványokat meghatározni, az eredményeket átvenni, stb. szerepeket kell betöltenie.

Tokiói Kerületi Bíróság, 2004. március 10-i (Heisei 16) ítélete

Ez az ítélet nemcsak azt jelzi, hogy a rendszerfejlesztés önmagában is közös munka a felhasználóval, hanem azt is, hogy “milyen pontokon kell együttműködni”, ami nagyon tanulságosnak tűnik.

Próbáljuk meg a fenti ítélet szövegét lefordítani az IT rendszerfejlesztés szakkifejezéseire.

Ezeket így lehet összefoglalni. Mindezek olyan feladatok, amelyeket a felhasználó együttműködése nélkül nem lehet elvégezni, függetlenül attól, hogy milyen magas szintű szakértelemmel rendelkezik az IT rendszerrel szemben. A kívánt funkciók és a képernyő elrendezése alapvetően a felhasználó által tisztázandó kérdések, és csak a felhasználó tudja ellenőrizni, hogy a kívánt eredményeket megvalósították-e.

Mivel a szolgáltatóra ugyanúgy projektmenedzsment kötelezettség hárul, mint a felhasználóra együttműködési kötelezettség, ha a felhasználó megsérti az együttműködési kötelezettséget a fent említett folyamatokban, akkor fordítva a szolgáltató szerződésszegési vagy jogellenes cselekmény alapján kártérítési igénnyel léphet fel a felhasználóval szemben.

Hogyan értelmezhetők az utólagos specifikációváltoztatások kérései?

Ha feltételezzük, hogy a rendszerfejlesztési projektek a felhasználók és a szállítók közös munkája, akkor további fejlett vitákra kerülhet sor. Ilyen például az a kérdés, hogy „Ha a felhasználó utólag kéri a funkciók hozzáadását vagy módosítását, és ezáltal a határidő betartása nehézkes, akkor vajon kinek a felelőssége lesz ez?”.

A rendszerfejlesztés általában a követelmények meghatározásával kezdődik, majd alapvető tervezés, részletes tervezés, gyártás (programimplementáció), tesztelés sorrendben halad, a cél az, hogy a munka visszafordulása a lehető legkevesebb legyen (általában ezt vízesés modellnek nevezik). Azonban valamilyen okból kifolyólag, ha kiderül, hogy a korábbi folyamatban hiányosságok vannak, a munkafolyamatokban visszafordulások is előfordulhatnak, ami a valóságban gyakran előfordul.

Hogyan gondolkodhatunk ilyen esetekben, ha nem sikerül betartani a határidőt? A korábbi ítéletek elemzése alapján úgy tűnik, hogy a következtetésekben eltérések vannak a további munka időzítésétől függően.

Ha a további munka a külső tervezés stb. specifikációjának tisztázása előtt történt

A fent említett ítéletben a felhasználó által a szállítónak a programimplementáció előtti alapvető tervezés során tett további fejlesztési kérésekre vonatkozóan azt is megállapították, hogy az ilyen kérések önmagukban nem sértik a kooperációs kötelezettséget.

A felhasználó által a szállítónak a rendszer kialakításával kapcsolatos különböző kérésekkel való megkeresése az alapvető tervezési munka során, mint a jelen esetben, természetes a rendszerfejlesztési folyamatban, és ráadásul, a szakmai ismeretekkel nem rendelkező felperes felhasználó számára nehéz volt pontosan megítélni, hogy a kérés további díjat vagy a szállítási határidő elhalasztását igényli-e, vagy hogy zavarja-e a munkafolyamatot. Ezért a felperes felhasználónak nem lehetett volna önmérsékletet gyakorolnia a további díjat vagy a szállítási határidő elhalasztását igénylő kérésekkel kapcsolatban. Inkább, ha a felperes felhasználó további díjat vagy a szállítási határidő elhalasztását igénylő kérést tett, a projektmenedzsment kötelezettségét viselő alperesnek kellett volna tájékoztatnia a felperes felhasználót erről, és kérnie a kérés visszavonását vagy a szállítási határidő elhalasztását stb., hogy ne legyen zavar a fejlesztési munkában.

Tokiói Kerületi Bíróság, 2004. március 10. (Heisei 16) ítélete

Ebben az ítéletben megerősítették, hogy a felhasználóknak is van bizonyos kooperációs kötelezettségük, és ugyanakkor azt is megállapították, hogy a felhasználók nem rendszerfejlesztési szakértők. Vagyis, ha a rendelést leadó felhasználó nem rendszerfejlesztési szakértő, akkor a rendszer tartalmának tisztázásáig terjedő időszakban (esetenként még a rendelés leadásához sem szokott hozzá) nem meglepő, ha apránként és szétszórtan adja le a rendeléseit, és még kevésbé, ha a rendelés tartalma a szállítási határidő stb. felülvizsgálatát igényli, és „önállóan kellene rájönnie erre”.

Az itt a szállítóra rótt kötelezettség lényegében a kommunikációs erőfeszítésekre utal, mint például a határidő elhalasztásának kérésére (vagy ha a határidőt nem lehet módosítani, akkor a további kérés visszavonásának javaslatára). Tehát ez nem azt jelenti, hogy a szállítónak minden kötelezettséget bele kell foglalnia, beleértve a felhasználó összes kérésének elfogadását és a terméket az eredeti határidőre történő szállítását is, ezért ezt figyelembe kell venni.

Ha a további munka a gyártás vagy a tesztelési folyamat specifikációjának megerősítése után történt

Ha megfordítjuk a fent említett ítélet tartalmát, akkor bizonyos mértékig előre jelezhetjük, hogy milyen következtetésre jutottak volna, ha a további fejlesztés a specifikációk már megerősítése után történt volna. Ebben az esetben ezek a kérések nehezebben teljesíthetők. Valóban, a felhasználók és a szállítók közötti fejlesztési munkával kapcsolatos megértés nagy mértékben eltér, függetlenül attól, hogy a specifikációk megerősítése előtt vagy után történt-e.

De ha a specifikációk megerősítése után megváltoztatják vagy hozzáadnak a rendelés tartalmához, akkor nagy a valószínűsége, hogy a munkát újra kell kezdeni. Ilyen esetekben gyakran nehéz védelmezni a határidő elmulasztását azzal az érvvel, hogy „a vevő, tehát természetes, hogy különböző kéréseket tesz”. Ráadásul, ha sok specifikációs változás vagy funkció hozzáadása utólag történik, felmerülhet a kérdés, hogy nem volt-e már a felhasználó részéről kooperációs kötelezettség megsértése a már befejezettnek tekintett alapvető tervezési stb. felső folyamatban.

Ezekből a szempontokból is úgy tűnik, hogy nem reális a szállító felelősségének tulajdonítása a határidő elmulasztásáért, ha a specifikációk egyszer már megerősítésre kerültek, és utána történtek specifikációs változtatások. A fent említett ítéletből úgy tűnik, hogy ésszerű ezt a jelentést is egyidejűleg értelmezni.

Ezenkívül ezek a döntések hajlamosak arra, hogy nem csak a szerződést, hanem a rendszerfejlesztés előrehaladásához igazodó jegyzőkönyveket is bizonyítékként használják. A jegyzőkönyvekről a következő cikkben részletesen tájékozódhat.

Kapcsolódó cikk: A rendszerfejlesztés jegyzőkönyvének megőrzése jogi szempontból[ja]

Összefoglalás: Fontos, hogy ne felejtsük el, hogy a követelmények meghatározása a felhasználói folyamat része

A követelmények meghatározása a szolgáltató oldalának szakértelmét mutatja, de először is tudatában kell lennünk annak, hogy ez alapvetően a felhasználói oldal feladata. Ha a rendszer a saját vállalatunkban kerül felhasználásra, akkor még ha külső szakértők segítségét is igénybe vesszük a létrehozásához, jogilag úgy tekintünk rá, mint egy olyan területre, amelynek a saját vállalati irányításunknak kell kiterjednie.

Ha a felhasználói oldal nem működik együtt a fejlesztési folyamatban, akkor még ha a projekt lángba is borul, a bíróság nagy valószínűséggel szigorú álláspontot fog elfoglalni a felhasználói oldallal szemben. Ezt a tényt először is észben kell tartanunk.