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

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • 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

Informatikai keretszerződések, avagy nagy szerződés + sok pénz.

Informatikai keretszerződések, avagy nagy szerződés + sok pénz.

A cikksorozat 1. része és 2. része után itt a folytatás. Ezúttal egy nagyméretű keretszerződést mutatok be, amely 2009-ben jött létre az Közigazgatási és Elektronikus Közszolgáltatások Központi Hivatala és a Magyar Telekom Nyrt. Között „A Központi Rendszeren, valamint az Informatikai Közhálón nyújtandó emelt szintű szolgáltatások kialakítása és az igénybevevő intézmények részére történő működtetése” tárgyban. A szerződés itt tekinthető meg.

Mi a különbség a hagyományos szerződés és a keretszerződés között? Hagyományos esetben a megrendelőnek van valamilyen igénye (mondjuk 100 darab szerver üzemeltetése), erre kiír egy beszerzést, lesz egy nyertes, kötnek vele egy szerződést, a vállalkozó pedig üzemelteti a 100 darab szervert.
Igen ám, de van az úgy, hogy előre nem lehet tudni, hány szervert is kell üzemeltetni. Mondjuk annyit tudunk, hogy mást van 100, de év közben újakat is telepíthetünk, és végeredményben nem tudjuk, mennyi is az annyi. Ja és nem csak szervereket kellene üzemeltetni, hanem tűzfalakat is, levelezési rendszert is, a hálózatot is felügyelni kéne, vannak ott router-ek, VoIP telefonrendszer, stb, szóval egy csomó minden.
Azt előre tudjuk, hogy kb milyen jellegű szolgáltatásokra lesz szükség, ezekre tudunk egységárat kérni és egységesen specifikálni, de majd ott és akkor fogjuk lehívni a „keretből”, amikor szükség van rá.

A keretszerződés célja az, hogy az együttműködés kereteit rögzíti (innen a neve…), annyira konkrétan amennyire csak lehet, de azt konkrétan nem mondja meg, hogy a Megrendelő pontosan mit mikor rendel meg. A keretszerződésen túl majd lesznek egyedi, eseti megrendelések, amik a keretszerződésre hivatkozva, az ott lefektetett szabályok szerint kerülnek megvalósításra.
Ez a rendszer rugalmasságot biztosít a Megrendelő részére, lehetővé teszi, hogy nem kell egyesével minden igényére beszerzési pályázatot írni.

További előny, hogy az igényeket egy csomagba gyűjtve előnyös ajánlatot lehet kicsikarni a beszállítóktól. Több engedményt lehet kérni egy 10000 darabos számítógép rendelésen, mint 5 darab 2000 daraboson.

A vállalkozó számára is előnyös egy ilyen keretszerződés, hiszen ez lesz a stratégiai együttműködés papírba öntött megtestesülése, ami a megrendelő elkötelezettségét mutatja. A vállalkozó ezután bízvást számíthat az egyedi megrendelésekre, fel tud rájuk készülni, kevésbé lesz kitéve az igények hektikus ingadozásának.

A dokumentumot megnézve kiderül, hogy igencsak vaskos anyagról van szó (36 oldal), pedig a műszaki paramétereket és árakat (pl. óradíjak, havidíjak) kivágták. A keretszerződések bizony ekkorák – kis beszerzésekre nincs értelme befektetni ezt a plusz munkát.

Ha a szerződés tekintélyes méretű, akkor azzal sokat kell dolgozni, és mindig magában hordozza a hiba lehetőségét – hogy valami kimaradt, vagy valami több helyen is többféleképpen rögzítenek, teret engedve a későbbi vitáknak.

E szerződésen látható, hogy egy már meglévő – mindenféle ügyfélre alkalmazható - sablon-szerződésből indultak (feltehetőleg a Vállalkozó hozta), beletéve az adott megrendelésre/adott ügyfélre vonatkozó specifikus paramétereket.

Néhány érdekes pontra hívnám fel a figyelmet:

Szakmai részletek hiánya: Ez így helyes. A keretszerződés célja nem a konkrétumok, hanem a jogi keret definiálása.

Rendelési folyamat: A szerződés elég sokat ír a rendelési folyamatról, azaz hogyan lehet a Vállalkozótól egyes szolgáltatásokat megrendelni. A mellékletekben konkrét űrlapok, formanyomtatványok szerepelnek. Egy keretszerződésnek ezeket mindenképpen tartalmaznia kell, le kell rögzíteni, hogy ki jogosult hogyan mit megrendelni.

Hibaelhárítása, SLA, kötbér: A szerződés – nagyon helyesen – tartalmazza a hibaelhárításra vonatkozó mérőszámokat, illetve köbért azok megszegéséért. Nyilván ezen SLA kategóriák nem tudnak túlságosan konkrétak lenni, hiszen ez itt magas-szintű megállapodás, az egyes konkrétumok majd az adott szolgáltatásnál kerülnek meghatározásra.
Amit problémának érzek, az a súlyossági szintek hiánya. Nagyvonalúan egybemosódik az összes hiba, márpedig vannak blokkoló és nem blokkoló hibák, fontos és kevésbé fontos szolgáltatások.

Támogatási folyamat: Amikor aláírunk egy ilyen volumenű szerződést, akkor ne legyenek arról illúzióink, hogy minden egy csapásra meg fog oldódni. Ez csak egy keret, ami lehetővé teszi, hogy a kereten belül dolgozhatunk. Konkrét támogatási folyamatok nincsenek benne, a szerződés aláírása egyben azt is jelenti, hogy a szerződésen kívül majd a szakemberek közösen kidolgozzák a folyamatokat, és azokat közösen felügyelik. (Ugyebár nem a papír, hanem az üzleti kapcsolat számít!)
Probléma ebből akkor lesz, amikor valaki ezt – még hátralévő – töménytelen sok munkáról megfeledkezik, és azt hiszi, hogy pusztán a kötelezettségvállalástól és a kötbér mértékétől fogva maguktól jól fognak menni a dolgok.
Sőt továbbmegyek, az is illúzió, hogy ha az együttműködés operatív szabályait kidolgozzák, akkor az már elég – nem, nem elég, a világ változik, tehát a folyamatokat is folyamatosan figyelni és javítani kell. Mert például új szervezeti egység hívhat le szolgáltatást a szerződésen keresztül, megnövekedhet a szolgáltatási igény, jogszabályi változás miatt igazítani kell az SLA-ket, stb stb.

Felmondás: A keretszerződésnek mindenképpen ki kell térnie arra, mi történik az együttműködés lejárta vagy felmondása esetén. Ez itt szépen ki van dolgozva. A 30 nap + 30 nap rendkívüli felmondási időt túl kevésnek érzem ahhoz képest, hogy mennyire stratégiai IT szolgáltatások kerülnek ki a Vállalkozó kezébe. (Mondjuk a másik oldalról nézve meg túl sok – ha a Vállalkozó nem akar szolgáltatni, akkor miért kell 60 napot várni)
Felhívnám a figyelmet, hogy nincs lehetőség rendes felmondásra: a megállapodás vagy lejár, vagy valaki okot ad a rendkívüli felmondásra.

Alvállalkozók: A dokumentum példamutatóan kezeli az alvállalkozók kérdését. A 4. melléklet kötötten rögzíti, hogy kik az alvállalkozók, és ezeken csak különleges esetben, a Megrendelő kérésére lehet változtatni.

Feladatmegosztás: A 8. melléklet nagyon érdekes abból a szempontból, hogy a Megrendelő és a Vállalkozó közötti feladatmegosztást rögzíti. Normál esetben a szolgáltatás önmagában jól definiált, nincs szükség külön feladatmegosztásra. Ennek ellenére hasznos, ha írásban rögzítésre kerül, ki mit vár el a másiktól.
Ami a 8. mellékletben zavaró, az az, hogy igazából nem egy ügyfél van, hanem 4 résztvevőnek kell összehangolnia a munkáját a közös siker érdekében. Ismerjük a mondást a közös lóról, ezért jobb lenne nem részletes felelősségi mátrix helyett kizárólagosan egyetlen megrendelő számára dolgozni, és a megrendelő nevében nyújtani szolgáltatást a többi résztvevő részére.
Arról az apróságról nem is beszélve, hogy van egy feladat, amiért senki sem felelős. (Gondolom nyomdahiba, de akkor is… egy nyomdahiba forint milliárdokat érhet adott esetben.)

A szolgáltatások ára: Az 1. számú mellékletet kiszedték, de bizonyára az Ajánlattételi Dokumentáció tartalmazza az egyes szolgáltatások egységárát. Nagyon fontos, hogy a keretszerződés tartalmazza az egységárat, óradíjat, havi díjat, stb. a későbbi viták vagy áremelés elkerülése érdekében.
Azt viszont veszélyesnek tartom, hogy az Ajánlattételi Dokumentáció bekerült a szerződésbe. Meglehet, hogy az ajánlattétel tartalmazott feltételeket/kitételeket, amik ellentmondásban vannak a szerződés törzsével, és félreértéseket eredményeznek. Persze ha az ajánlattétel kötött formátumban történt, akkor ez a veszély nem lép fel. Mivel hiányzik a kérdéses melléklet, ez mind csak spekuláció.

Fejlesztési kötelezettség: Ez a szerződés külön kitér rá, hogy minimum évi 2 milliárd forint értékű fejlesztést kell a Megrendelőnek kérnie a Vállalkozótól. A keretszerződések gyakran nem tartalmaznak ilyen kitételt, azaz a felek csak a jogi keretekben állapodnak meg, a tartalmat pedig nyitva hagyják. Ergo előfordulhat, hogy a Megrendelő egyetlen projektet/szolgáltatást sem rendel meg (avagy hogyan szabaduljunk meg egy partnertől felmondás nélkül).
A fejlesztési kötelezettség a Vállalkozó számára jelent biztonságot. Feltételezhető, hogy a Vállalkozó befektetéseket tesz a szolgáltatások nyújtása érdekében, például munkatársakat vesz fel és kiképzi őket. Jogosan elvárhatja tehát, hogy a költségeiért cserébe jól látható legyenek a megrendelések, amikből ezeket a befektetéseket finanszírozza.

Hogy az évi 2 milliárd forint sok-e vagy kevés… tulajdonképpen sok, nagyon sok. Az ár azt sugallja, hogy 300-400 Telekom-os informatikus fog teljes állásban dolgozni a kormány részére. Elnézve, hogy hányféle és milyen komplex IT szolgáltatásokról van szó, hogy hány kormányzati szerv van, ez az ár lehet reális, sőt meglehet hogy 2 milliárdnál nagyobb értékű szolgáltatásra van szükség.

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

A bejegyzés trackback címe:

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

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.

Nincsenek hozzászólások.
süti beállítások módosítása