A rövid szerződés is jó szerződés.

A rövid szerződés is jó szerződés.

A cikksorozat 1. részében egy nagyobb értékű komoly szerződés került megtekintésre. Az informatikai megállapodásokról az átlagember azt gondolja, hogy szükségszerűen hosszúnak, bonyolultnak és átláthatatlannak kell lennie, minden részletet le kell szabályozni. Ezzel szemben most egy olyan szerződést mutatok be, ami mellékletekkel együtt 4 oldal, de minden fontos információt tartalmaz.

A szoftver üzemeltetési megállapodást a HungaroControl Magyar Légiforgalmi Szolgálat kötötte az Atigris Zrt-vel 2008-ban, megtekinthető itt.

Felmerülhet a kérdés, hogy jó-e az ilyen rövid szerződés, mire elég a 4 oldal? Amikor szerződést kötünk, nem szabad elfelejteni, hogy az csak egy darab papír. Egy darab papír, ami irányt mutat vitás esetekben, de nem helyettesíti a bizalmat és a jó kapcsolatot. Nagy értékű beszerzéseknél van tétje a jó szerződésnek, de egy kis értékű beszerzésnél már a tét is kicsi. Akár jó, akár rossz a szerződés, nem fog túl sok múlni rajta – mit nyerünk, ha perre megyünk és nyerünk a másik fél rosszindulatú viselkedése miatt? Lehet, hogy kevesebbet, mint amennyi időt ráfordítunk (és amit az ügyvédnek fizetünk).

Ha az ember kis összegű munkára egy kis céggel szerződik, akkor meg kell találni az egyensúlyt a biztosítékok és megállapodás volumene között. A munkáért fizetendő pénz nem sok, a kkv-nek lesznek tényleges költségei a teljesítés során, a profit nem lesz egetverő. Nem ebből vesz a tulajdonos új házat medencével.
Amennyiben az ügyfél nem bízik meg beszállítójában, és a szerződés vaskos paragrafusai által részletesen előirt kötbérbe kapaszkodik, akkor azzal megnöveli a vállalkozó kockázatát. A kockázat pedig kockázat, a vállalkozónak egyszerűen nem fogja megérni, hogy kis profitra nagy kockázatot vállaljon.

Megfordítva a helyzetet: ha az ügyfél még kis értékű megállapodásnál, kis profit esetén sem bízik meg a beszállítójában, akkor ott nem is érdemes vállalkozni.

A szerződést átolvasva a következő pontokat emelném ki:

Rövid, tömör, csak a lényeget tartalmazza, azaz mennyit kell hogyan fizetni, mit kell leszállítani, és mi a teendő vitás esetben.

Kevéssé fontos részletek hiánya: Nincs szó alvállalkozókról, felmondásról, adatvédelemről, titoktartásról, garanciáról, vis major-ról, gondatlanságról, kárról. Valójában a megrendelőt ezek a részletek nem érdeklik, neki a szolgáltatás kell. A rendszer nem kritikus, nem tartalmaz érzékeny üzleti adatokat, mindegy hogy ki mikor hogyan szervizeli.

Licensz: A hasonló szerződések típushibája, hogy nem tisztázza a szoftver tulajdonjogát, illetve hogy a megrendelő milyen jogokat kap. A szerződés kimondja, hogy a szoftvert a vállalkozó a megrendelő részére készítette, de nem tisztázza, hogy az kié. Nem látni, hogy a megrendelő azt milyen alapon, milyen korlátozásokkal és meddig használhatja. Feltételezzük, hogy létezett egy korábbi, szoftver-fejlesztési megállapodás, ami rögzíti a tulajdonjogokat, és itt ez egyszerűség miatt nincs újra leírva.

Miért nem jó a licenszek hiánya? Mert mi van, ha az üzemeltetési megállapodás végetér, jogosult-e a megrendelő tovább használni a szoftvert? Mi van, ha a megrendelő egy másik IT céget biz meg a további üzemeltetéssel?

Nincs SLA: Ha az ember üzemeltetési szerződést olvas, akkor rögtön a válaszidőket, rendelkezésre állást és megoldási időket keresi. Itt ezek hiányoznak – de ez nem baj (akár azt is mondhatjuk, hogy ez így jó). A lényeg a mellékeltben ott van (5x8 rendelkezésre állás, 6 órás probléma megoldás kezdés). Még ha komplikált SLA-t is írunk, a „nem fontos” kategóriája kéréseket a vállalkozó gyakran „best effort” alapon oldja meg. Azaz legjobb tudása szerint. Ez nem azt jelenti, hogy sosem, hanem azt, hogy azért valamikor. Ha sikerül, akkor azonnal, de az is lehet, hogy jövő hétre.
A 6 órás kezdés azt jelenti, hogy nem lehet akármilyen hosszú ideig elhúzni a javítást – ha a javítás elkezdődött, akkor hamarosan be is kell fejeződnie.
Mivel ez a rendszer nem kritikus, egy esetleg rendszerleállás nem okozna túl nagy problémát. A vállalkozóra nagyobb nyomást lehet gyakorolni a hagyományos kommunikációs/kapcsolati csatornákon keresztül, mint egy rafinált SLA-vel.

Teljesítés igazolása: A munka elszámolása pofonegyszerű módon munkalappal történik, havonkénti jelentéssel. Mivel a kifizetés is havonta történik, ezért egyszerre nem tartoznak túl sokkal a felek egymásnak. A 30 napos fizetési határidő megfelelő. A nem-fizetést a magyar jog kellően kezeli.

Felhasználói támogatás: Nem hiba, de amikor a vállalkozó közvetlen felhasználói támogatásra vállalkozik, akkor célszerű világossá tenni, hány felhasználóról van szó, és hogy a felhasználók fogják-e közvetlenül hívogatni a fejlesztőket, vagy először a megrendelő IT osztálya próbál segíteni. Nem mindegy, hogy a fejlesztőt napi rendszerességgel hívják „elfelejtettem a jelszavamat” súlyú problémákkal.
A szerződést ezt a helyzetet úgy oldja meg, hogy maximálja felhasználói támogatást havi 5+8 órában.

Csomagkapcsolt szolgáltatás: A megállapodásban van minden: üzemeltetés, rendszergazdai támogatás, felhasználói támogatás és fejlesztés. Nem biztos, hogy az ügyfélnek mindenre szükség van, és hogy így van rá szüksége.

Garanciális hibák kezelése: A szerződés nem rendelkezik, hogy a szoftver hibáit, azaz potenciálisan a vállalkozó hibájából adódó üzemeltetési eseményeket hogyan kell elszámolni. Feltehetőleg létezik egy szoftver fejlesztési szerződés, ami a rendelkezik a garanciáról, és nem havi 5 órában pénzért történik a garanciális javítás.

Havi 4+5 óra fejlesztés: A szerződés gyenge pontja a szoftver fejlesztés kezelése. Üzemeltetésnél teljesen korrekt a havi kis óraszámú keretszám, havi elszámolás, és a keret negyedéves görgetése.
Szoftver azonban másképp fejlesztünk. A szoftverfejlesztés tipikusan kampány-jellegű munka, azaz vagy nincs mit fejleszteni, vagy beesik egy igény és akkor sok a munka. Olyan nincs, hogy havonta fejlesztgetek 4-5 órát. És ha már fejlesztés: egy kisebb igény is könnyen eltarthat napokig (mert ugye nem csak kódolni, hanem tesztelni és telepíteni is kell), tehát a keret igazi fejlesztéshez kevés
Az ügyfélnek biztosan rossz lesz: ha nem rendel fejlesztést, akkor elvesznek a kifizetett fejlesztési órák, de ha rendel, akkor azzal szinte biztosan kicsúszik a keretből. A plusz fejlesztői munka órabére nincs rögzítve, ami kockázat.

A negyedéves keret biztosan jó az üzemeltetéshez, de biztosan nem jó fejlesztéshez. Az éves keret lenne korrekt, mert ekkor össze lehetne halmozni annyi órát, amennyi egy tisztességes munkához kell.

A legtisztább persze az lenne, ha nem is venne a megrendelő e szerződés keretében fejlesztést, csak keretszerződés jelleggel rögzítené az egységárat és feltételeket, aztán majd az adott esetben az ügyfél külön megrendeli a munkát, pont annyit amennyire szüksége van.
Ez a fejlesztőknek is jobb lenne, a folyamatos rendelkezésre állás helyett projektszerűen tudnának dolgozni.

Egységárak: A szerződés előnye, hogy az informatikus óradíjak tisztán látszanak – azok részére, akik nem tudják, mi mennyibe kerül.