Hogyan néz ki egy igazi informatikai szerződés, és mik azok a típushibák, amiket elkövetnek szerződés készítésekor?

Hogyan néz ki egy igazi informatikai szerződés, és mik azok a típushibák, amiket elkövetnek szerződés készítésekor?

Egy új cikksorozatot szeretnék indítani, ahol igazi, éles informatikai szerződéseket mutatok be. E bemutató célja a kkv-k megsegítése abban a tekintetben, hogy mi minősül fair szerződésnek és mi nem, megmutatom mik a szokásos formulák és mik nem azok. A megrendelői oldalon dolgozóknak azt mutatom meg, hogy mik a tipikus „trükkök” amikre érdemes odafigyelni.
Végül pedig az informatikai munkások részére betekintést szeretnék nyújtani abba a világba, amelytől az ő mindennapjaik nagy mértékben függenek.

Mivel saját szerződéseimet üzleti okok miatt nem mutathatom be, ezért publikus állami szerződéseket kerülnek terítékre.

A sorozat első darabja a HM FLÜ és GlobeNet közötti megállapodás a MedWorkS egészségügyi információs rendszer bevezetésére, üzemben tartására és jogkövetésre 2007-ből.

A következő pontokra hívnám fel a figyelmet:

Alvállalkozók: A szerződés megengedi a Vállalkozónak, hogy alvállalkozókkal dolgoztasson. Ez önmagában véve nem törvénytelen, de a Megrendelőre nézve kockázatos – mi van, ha a Vállalkozó rosszul szerződik le az Alvállalkozóval, aki aztán rosszul teljesít?
Itt ebben a szerződésben – helyesen – a Vállalkozó felelős az alvállalkozókért.
Személy szerint én nem szeretem az alvállalkozói szerveződéseket. A fővállalkozó az ajánlattételben tisztázza, hogy milyen felállásban kíván teljesíteni, megnevezve alvállalkozóit. Vagy ha ez nem sikerül, akkor alvállalkozót csak a Megrendelő engedélyével vonhat be.

Ár: Sajnos a szerződés csak végösszegeket tartalmaz, és ez nem helyes. Ugyanis nem csak egy szoftver kell leszállítani, hanem azt később üzemeltetni is kell, amelynek során mindenféle esemény történhet (tanácsadás, fejlesztés, követelmény elemzés, oktatási igény, extra helpdesk vagy rendszergazdai igények). Éppen ezért az óradíjakban célszerű előre megállapodni – ezek hiányában az ár akármilyen lehet.

Licensz: A szerződés egy nagy hibája – és tipikus hiba – hogy nem tisztázott, a HM FLÜ milyen jogokat kap a MedWorkS rendszerhez. Azaz nem tudjuk, hogy tulajdonosa vagy használója a rendszernek, a használati jog hány munkaállomásra és milyen időtartamra vonatkozik, van-e joga saját maga változtatni a rendszeren, megkapja-e a forráskódot, illetve az üzemeltetés pontosan mekkora részét teszi ki a licensz díj.
Ha a kezdetben jól induló kapcsolat a későbbiekben megromlik, akkor a Megrendelő kezében semmilyen jog nem marad, illetve a Vállalkozó kénye-kedvére ki lesz szolgáltatva, hogy mennyit kér el a licensz jogokért.

Fizetési határidő: 15 nap vagy 30 nap, totális ellentmondás a 3.9 és 10.3 bekezdések között. A 30 nap korrekt – ez elég időt ad a vitás esetek rendezésére, ugyanakkor a vállalkozó is pénzéhez jut. 60 napnál hosszabb fizetési határidő már nem tisztességes.
Mivel a kifizetés és a fizetési határidő a kkv-k érzékeny pontja, ezért nyugodtan lehet a Vállalkozót védő kijelentéseket tenni, pl. késedelmi kamat (amit  a törvény egyébként is előír), illetve egyéb fenyegetések nem-fizetés esetén.
Feleslegesnek érzem a 90 nap utáni rendkívüli felmondást – ha az ügyfél nem fizet, az önmagában is szerződésszegés. De nyilván jobb félni, mint megijedni.

Határozott idejű és határozatlan idejű szerződés: Szakmai szempontból mindegy, hogy a szerződés határozott vagy határozatlan idejű. Ha az informatikai szolgáltatásra folyamatosan szükség van, akkor jobb a határozatlan idejű – nem kell állandóan megújítani.
Azt érdemes végiggondolni, hogy le akarjuk-e váltani a Vállalkozót vagy sem, illetve hogy a Vállalkozó rendes felmondása esetén mennyi idő alatt lehet új vállalkozót, új szoftvert beszerezni és élesbe indítani.

Rendkívüli felmondás: Nem biztos, hogy kell oldalakat szánni a rendkívüli felmondásnak. Ha valaki súlyos szerződésszegést követ el, akkor nyilvánvalóan nem áll szándékában az együttműködést folytatni, veszett fejsze nyele. Nem életszerű elvárni egy teljesíteni nem akaró vállalkozótól, hogy még 2 hónapig szolgáltasson. Feltehetőleg nem fog.

Kifizetés rendkívüli felmondás esetén: A vizsgált szerződés másik nagy hibája, hogy rendkívüli felmondás esetén is jogosult a Vállalkozó pénzre, ráadásul a hátralévő időszakra vonatkozóan. Kvázi ez azt jelenti, hogy a szerződés aláírása után semmit sem kell csinálnia, hiszen pénzt így is kap.
Itt is inkább érdemes a magyar jogot követni, és az el nem végzett munkáért nem fizetni semmit. A 4.4-es bekezdés teljesen felesleges, sőt súlyosan hibás.

Ami a háttérben lehet – és ami miatt mégis van logika a dologban – az az, hogy feltehetőleg a rendszer fejlesztése/testreszabása a Vállalkozó részéről befektetést igényelt, amelynek költségeit nem tudta up-front érvényesíteni.
(Kis magyarázat: az ilyen típusú munkák két részből állnak: fejlesztés/bevezetés + havi karbantartás. Ennek megfelelően a költségek is két részből állnak: az elején egy összegben kifizetendő + havi díj. )
Feltehetőleg a Vállalkozó üzletpolitikai okokból alacsony induló árat szeretett volna adni, ezért cserébe a fejlesztés költségeit a havidíjba építette. Ezt akarja bebiztosítani, hogy mindenképpen hozzájusson.
A leírt módszerben van logika, csak éppen nem ez a szokásos és nem fair.

A tisztességes eljárás az lenne, ha az üzemeltetés valóban csak üzemeltetést tartalmaz, a fejlesztés pedig teljes egészében fejlesztést. Miért? Mert ha 2010-ben meg akarják hosszabbítani a szerződést, akkor nem a valós üzemeltetési költségeket fogják kezelni, hanem egy irreálisan nagyot.

Hosting: A szerződésből nem derül ki, hogy a rendszer fizikailag hol lesz, ki felel érte, kinek a szerverén fut. Ez sok szempontból érdekes kérdés:
- A havi díj mekkora része hosting és mekkora nem hosting?
- Ha a hosting nagyon drága, akkor el lehet-e vinni másik céghez, akik esetleg olcsóbbak?
- Ki garantálja az adatok védelmét és hogyan?
- Ha a Vállalkozónál van fizikailag a szerver, akkor hogyan tud azzal a Megrendelő rendelkezni, hogyan fér hozzá, és hogyan tudja a szerver védelmét ellenőrizni?

A 4.5-ös pont azt sugallja, hogy a Vállalkozónál van a szerver. Ennek függvényében súlyos hiba a részletek hiánya.
Mondjuk később a 8.3 ennek pont az ellenkezőjét sugallja…

Adatokhoz történő hozzáférés szerződésbontás után: A 4.5-ös pont másik nagy hibája, hogy nem fair: a Megrendelő csak akkor férhet hozzá adataihoz, ha tetszés szerinti összeget a Vállalkozónak (ami lehet csillió-millió is).
Nyilván az is igaz, hogy szerződésbontás esetén a Vállalkozó csakis külön díjazás esetén hajlandó bármilyen adatkonverziót vagy adatbányászatot végezni.
Ezért a korrekt középút az, ha a Vállalkozó szerződésbontás esetén köteles ingyen átadni az adatokat olvasható, eredeti formátumukban, viszont felkérés esetén legjobb tudása szerint együttműködik a Megrendelővel, hogy egy külön megállapodás keretében adatkonverziót végezzen.

Titoktartás, adatvédelem: A szerződés külön fejezetet szentel a titokvédelemnek. Amit ebből hiányolok, a szerződésbontás kezelése. Szerződésbontás, szerződés lejárása esetén a Vállalkozó legyen köteles eltávolítani és megsemmisíteni minden, a birtokába került dokumentumot, fájlt, adatot, stb, erről jegyzőkönyvet felvenni.

Egyedi fejlesztés: Az világos, hogy jogszabályi és adatváltozásokat a Vállalkozó köteles megtenni írásos kérés esetén. De az is világos, hogy lesznek változáskérelmek. Ezek sajnos rosszul lettek szabályozva.
Az egyik hiba az, hogy nincs változáskérelmi folyamat, helyette csak egy homályosan megfogalmazott prioritási lista van.
A másik hiba pedig az, hogy 13 napban határozták meg havonta a fejlesztést – ennél lehet több is vagy kevesebb. Ha több, akkor kellene óradíjas alapon dolgozni (ugye hiányzik az óradíj), illetve mi van, ha a fejlesztési igény biztos el fogja érni a 13 napot? Mi van, ha nem éri el, tovább lehet-e vinni a fejlesztési napokat?
Megrendelő oldalról ilyenkor végig kell gondolni, hogy mennyi fejlesztés lesz, és hogy a 13 tényleg jó szám-e?

Milyen szintű support? Típushiba, hogy a felek nem tisztázzák, a szerződés keretében nyújtott támogatás 1., 2. vagy 3. szintű helpdesk lesz-e. Lesz-e a HM-en belül egy saját üzemeltetési 1. szintű helpdesk, vagy a Vállalkozó közvetlenül kapcsolatba kerül az összes felhasználóval?

SLA: Minden ilyen jellegű szerződésnél kulcskérdés a szolgáltatási szintek definíciója. Nem érzem elég jónak a hibaszintek meghatározását (akadályozó, gátló és zavaró hibák). Ennél részletesebb definícióra volna szükség.
A hiba kijavításának megkezdése 2 óra, 3 nap és 5 munkanap, ami a szerződés összegét tekintve (561 millió forint) nevetséges. Ha a szoftver leáll, akkor a kórház szinte megszűnik működni – ne kelljen 3 napot várni csak arra, hogy a szakértők nekiálljanak megkezdeni a munkát.
És ugye ez nem a probléma megoldásának az ideje, csak a megkezdése.

Az egyáltalán nincs benne a szerződésben, hogy a hibákat mennyi időn belül KELL megoldani… mint a marhapörkölt hús nélkül…

Reálisnak azt érezném, hogy a hibák kijavítását meg kell kezdeni 2 órán belül, és mindenképpen kijavítani 4 órán, 1 napon vagy 5 napon belül. Ugye ez integrált kórházi rendszer, ha nem működik akkor a betegek haza is mehetnek, tehát minimum üzleti kritikus.

Büntetés rendszerleállás miatt: Az SLA-nak csak akkor van értelme, ha tétje is van. Azaz ha a Vállalkozót pénzbüntetés sújtja az SLA megsértéséért.
Szó van napi 0,3%-nyi büntetésről, ami abszolút nem reális. Ha a korház leáll szoftverhiba miatt 2 teljes napra, akkor az óriási kárt okoz a betegeknek és a korháznak. Ellenben a Vállalkozó csak a havi díjának 9.3%-ától esik el.
Szélsőséges esetben, tehát ha a rendszer abszolút nem is működik, akkor is csak a pénze 15%-ától esik el.

Normális esetben ezeket úgy kell beállítani, hogy az akadályozó hibáknak tétje legyen, súlyos nem-teljesítés esetén a pénze nagy részét bukja, de legyen tétje a kis hibáknak nincs. (pl nem foglalkozik kényelmi hibákkal)

Garancia: 12 hónap korrekt. Azt viszont tisztázni kellene, hogy a garancia 2007-től indul, vagy onnantól kezdve, amikor új verziót kapott a HM.
Az lenne a korrekt, ha a garancia nem csak a rendszer indítására, hanem minden változtatásra vonatkozna.

Akadályközlés: Felesleges. Helyette elég lenne annyit leírni, hogy ha szolgáltatás a Megrendelő hibájából vagy vele egyetértésben nem teljesül, azért a Vállalkozó nem hibás.
Mert biztos lesz időszakos karbantartás, tervezett rendszerleállás, a Megrendelőnél a megfelelő ember épp nem ér rá, a Megrendelő nem hozza meg a szükséges döntést időben, stb, amiért nem fair a Vállalkozót hibáztatni.

Kártérítés: Vannak olyan esetek, amikor a szoftver hiba forintosítható kárt okoz a felhasználóknak – és ezért az informatikust terheli a felelősség.
Például itt ebben a konkrét esetben, tegyük fel, hogy szoftverhiba miatt nem lehet beteget felvenni a korházba, a beteg hazamegy és az ellátás hiányában meghal (most csak kitaláltam valamit, nem biztos, hogy van ilyen összefüggés). A hozzátartozói beperlik a korházat, és nyernek is 10 millió forintot. Mivel egyértelműen szoftverhiba okozta a kárt, a Vállalkozónak elküldhető a 10 millió forintos kártérítési igény.
Itt ebben a szerződésben a felek 13.3 bekezdésben kikötik, hogy a kártérítési igény nem lehet több, mint a havi díj mértéke, azaz 15 millió forint. Kis értékű szerződéseknél, nem kritikus szoftvereknél ez fair, azaz a havi díj mértéke a plafon. Különben egy becsületes kkv nem is merné aláírni a szerződést.
Kritikus rendszereknél viszont nem biztos, hogy ez a legjobb megoldás, mindenesetre ezt a Megrendelő dolga végiggondolni.

Gondatlanságból eredő kár: A 13.5 bekezdésben van egy hiba, mégpedig az, hogy a Vállalkozónak csak a szerződésszegő magatartás és a szerződésen kívüli károkozás róható fel. Azaz a gyenge minőség és a gondatlanság nem, pl. rosszul megírt programért vagy túl lazán elvégzett tesztért nem felelős.
Nagyon nehéz bizonyítani, hogy mikor járt el a Vállalkozó megfelelően. Ha hiba és kár történt, akkor nem járt el elvárhatóan, nemdebár? És ha mindent megtett, de mégis hiba történt, akkor azt hogyan bizonyítja?
Éppen ezért efféle kijelentéseket ne tegyünk a szerződésbe.

Amit én javaslok, az inkább az, hogy a vállalkozót kötelezzük a minőségi, az aktuális szabványoknak és eljárásoknak megfelelő, szakemberhez méltó munkavégzéshez. Az aktuális szabványok és eljárások jobban kézzelfoghatóak, mint az „elvárható” munka.

Vis Major: Hiányzik az a kijelentés, hogy Vis Major esetében a feleknek mindent meg kell tenniük a Vis Major elhárítására legjobb tudásuk szerint. Ha beüt a Vis Major, akkor már késő, de kellene valamit tenni azon kívül, hogy ölbe tett kézzel ülünk.
Például alternatív megoldást keresni. Vagy egy új megoldást alkalmazni, hogy ne történjen ilyesmi a jövőben.
Példa: tegyük fel, hogy a Vállalkozó hálózatán elszáll egy fontos router (mert mondjuk a Cisco hibázott), és nem tudják támogatni a rendszert távolról 2 napig, amíg a javítás zajlik. Ilyenkor elvárható, hogy autóba üljenek és a helyszínen folytassák a támogatást, illetve szerezzenek be nem csak egy új, hanem egy tartalék routert is.

Még mielőtt valaki feleslegesen nekem esne, a fenti észrevételek a szerződésnek szólnak, nem a szoftvernek és nem a szerződésben részt vevő feleknek. Készséggel elhiszem, hogy a MedWorkS szoftver tökéletes, de amikor SLA-t ír az ember, akkor nem ez jelenti a kiindulási alapot.

Plan for the best, prepare for the worst!