HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • sagabona: szia... elég régen született ez a bejegyzés, én csak most akadtam rá véletlenül. Érdekes dolgokat írsz, részben egyetértek az általad gondoltakkal, azonban pár dologban messze más a véleményem - ez ... (2018.10.19. 11:14) Gondolatfoszlányok a pályaválasztásról
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

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!

Címkék: szerződés informatikai

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr75211381

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Petya · http://susnya.hu/ 2010.07.26. 14:57:12

Ez nagyon hasznos sorozatnak ígérkezik, főleg, hogy a közeljövőben nálam is esedékes lesz egy szerződés. Lenne kedved esetleg arról is írni egy keveset, hogy egy szerződés megírásakor milyen mértékben és mikor veszed igénybe jogász(ok) segítségét, és körülbelül mennyi időt emészt fel egy-egy szerződés megfogalmazása?

Ismeretlen_102125 2010.07.26. 16:38:09

Attól függ, hogy a milyen összegű a szerződés és mennyire kritikus az informatikai szolgáltatás/szoftver, amiről a szerződés szól. Ha csak egy radírgumi-nyilvántartó szoftvert veszek 10ezer forintért akkor max 2 oldal is elég. Ha egy üzletileg kritikus szoftvert bérelsz, akkor 15-30 oldal, vagy még több. Ha egy fő informatikai szolgáltatást kiszervezel, akkor 100 oldal körül. A ráfordított munka ezzel arányos. Jogászt MINDIG igénybe kell venni, még kkv-k számára is kötelezőnek számít. Az változó, hogy a szerződés vázlatát ki hozza. A jogászoknak úgyis van sablon szerződése, szerződés mintája, amiben csak a leszállítandókat és a cég nevét kell kicserélni. Viszont ezek a szerződések nem fejtik ki eléggé a műszaki részleteket. Az időt tulajdonképpen nem a szerződés megírása fogja elvinni, hanem amíg mindenki véleményezi és sikerül megalkudni minden pontról. Lesznek apróságok, egy-egy mondat, amiről majd vita alakul ki. A 4 szereplős ping-pong (a két fél és a két fél jogászai) nem megy gyorsan. A mostani szerződés komolyabbnak számít, következő alkalommal egy nagyon rövidet mutatok.