WEBES ÉRTÉKESÍTÉS Szolgáltatási szint méréshez kapcsolódó üzemeltetési folyamatok

TVM Fő Projektszerződés 3. sz. módosítás (TVM Webes Értékesítés) - Szolgáltatási szint méréshez kapcsolódó üzemeltetési folyamatok


WEBES ÉRTÉKESÍTÉS

Szolgáltatási szint méréshez kapcsolódó üzemeltetési folyamatok



  1. Bevezetés



Dokumentum célja

Jelen dokumentum meghatározza BKK Budapesti Közlekedési Központ Zrt. (továbbiakban BKK vagy Megrendelő) által megrendelt és a T-Systems Magyarország Zrt. (továbbiakban TSM vagy Vállalkozó) által szállított TVM-szolgáltatásokat kiegészítő Webes értékesítés megoldás Szolgáltatási szint mérésének kapcsolódó folyamatait, alapelveit, megállapodásait és teljes szabályrendszerét.

A dokumentumban rögzített elvárásokra azért van szükség, mert a TVM-rendszernek ezen új funkciója az alap működési modellt új típusú szolgáltatási architektúrával bővíti, melynek érdekében a Szolgáltatási szint mérésére is új – jelen dokumentumban részletezett – folyamatokkal kell kialakítani.

A Szolgáltatási szint mérés terjedelme

A BKK és a TSM megállapodik abban, hogy jelen dokumentum tartalmazza a BKK által elvárt, a rendszer bevezetés előtt megfogalmazott összes olyan folyamatot és funkciót, amellyel mérni kívánja a TSM által biztosított és felügyelt szolgáltatások színvonalát. Amennyiben a BKK az üzemeltetési időszak során a jelen dokumentumban rögzítettekhez képest többlet funkciókat, folyamatokat, elvárásokat fogalmaz meg, azokkal kapcsolatban a [Változásmenedzsment folyamatnak] megfelelően kell eljárni.

A Szolgáltatás szint mérési folyamatok bevezetésének ütemezése

A BKK és a TSM a rendszer bevezetését megelőzően megállapodott abban, hogy a Szolgáltatási szint mérést a rendszer éles üzembeállításakor nem a jelen dokumentumban megfogalmazott összes elvárás, funkció, folyamat alapján, hanem egy közös megállapodás alapján kialakított, alapszintű funkcionalitással, melyet az üzemeltetési tapasztalatok alapján fokozatosan bővítenek, finomhangolnak.

Emellett a Felek megállapodnak egy ütemezésben, amelyben rögzítik, hogy a jelen dokumentumban megfogalmazott elvárt funkcionalitások milyen határidővel és milyen tartalommal kerülnek bevezetésre.

Felek megállapodnak, hogy első ízben az éles működés első 6 hónapjának (2017 Q3-Q4) tapasztalatai alapján az SLA-mérés feltételrendszerét felülvizsgálják, és egy szerződés módosítás keretében rögzítik.

A rendszer indulásakor és azt követően megvalósítandó funkciók tervezett ütemezést jelen dokumentum 1. sz. melléklete tartalmazza.

  1. Eseménymenedzsment

Az eseménymenedzsment az olyan események kezeléséért felelő folyamat, amelyeket a szolgáltatásokból és a konfigurációs tételekből adódó automata riasztás jelzések idéznek elő, és amelyeket az ellenőrző eszközök dolgoznak fel.

Az események alapvető fajtái:

  • informatív jelzések (information): olyan események, amelyek általános üzemeltetési folyamatokkal kapcsolatban adnak jelzést (pl. ütemezett feladat befejeződött, e-mail megérkezett a címzetthez, egy felhasználó speciális alkalmazásba jelentkezett be, stb.)

  • figyelmeztetések (warning): szokatlan, de nem kivételes üzemeltetési riasztást jelző események (pl. egy adott tranzakció befejezési ideje az elvártnál 10%-kal tovább tartott, tartósan magas CPU/memóriakihasználtság, stb.)

  • kivételek (exception): olyan abnormális eseményt jelző riasztások, melyek hatással lehetnek a szolgáltatás minőségre, jellemzően incidensekké válhatnak

A riasztás jelzések konfigurálására a Vállalkozó dolgozza ki az első körös javaslatot, melyet a Megrendelő szakértői validálnak. A Vállalkozónak biztosítania kell azt, hogy az eseményriasztások szabadon konfigurálhatóak legyenek oly módon, hogy az egyes eseménytípusokról a Megrendelő által definiált felhasználói csoportok számára e-mail értesítés kerüljön generálásra. A [Hozzáférés menedzsment] a Felek közötti megállapodások alapján az Megrendelő feladata és felelősségi köre.

Az események monitorozása elsősorban a Vállalkozó feladata, de ezen felül eseménynek tekintendő bármely olyan jelzés/észrevétel, mely a Megrendelő vagy vele szerződéses kapcsolatban álló partner, valamint a szerződésben a Vállalkozó kötelező alvállalkozói által észlelt és az eseménykezelési folyamat szerint rögzítésre került Incidens Bejelentés, függetlenül attól, hogy a rendszer monitoring eszközök adtak-e az eseményhez köthető jelzést vagy sem.

A Vállalkozónak gondoskodnia kell arról, hogy a szolgáltatások és a konfigurációs tételek eseményfeltételekkel legyenek beállítva úgy, hogy kiszűrjék, és azonnal kezeljék az incidenseket és problémákat – amennyire lehetséges az Ügyfeleket érintő következmények nélkül.

A Megrendelő elvárása, hogy a Vállalkozó az eseménymenedzsment folyamatot együtt kezelje a Rendszer monitoring rendszerrel és a kettő közötti együttműködés a folyamatok szintjén garantált legyen. Ez alapvető a Vállalkozó által szállított rendszer üzemeltetésében, tekintettel arra, hogy a monitoring rendszerben keletkező monitoring alapadatok által az [Incidensmenedzsment folyamatban] definiált automatikus incidensrekordok létrehozását indukálja.

Az eseménymenedzsment folyamat célja, hogy

  • optimálisan támogassa az a Vállalkozó és Megrendelő üzemeltetést végző csapatát;

  • csökkentse a humán erőforrás szükségletet a rendszer és a szolgáltatások ellenőrzésében;

  • biztosítsa az események azonnali kezelését;

  • minél nagyobb hatékonysággal ki lehessen szűrni az incidenseket és problémákat;

  • a kivételek azonnal rögzítésre kerüljenek a Megrendelő incidensmenedzser rendszerébe és azok az Incidensmenedzsment folyamat szerint feldolgozásra kerüljenek.

A Megrendelő további igényeket is megfogalmazhat az üzemeltetési időszak során a [Kérés teljesítési folyamatnak] megfelelően, az implementációt pedig már [Változásmenedzsment folyamatnak] megfelelően valósítja meg a Vállalkozó.

  1. Incidensmenedzsment

Az Incidensmenedzsment folyamat célja, hogy a normál szolgáltatásüzemeltetés a lehető leghamarabb kerüljön helyreállításra, és csökkentse a Megrendelő szolgáltatásnyújtására vonatkozó kedvezőtlen hatásokat, ezáltal biztosítva, hogy a szolgáltatások lehető legjobb minőségi és rendelkezésre állási szintje megmaradjon.

A Vállalkozó felelős a szolgáltatásokban felmerülő incidensek, manuális bejelentések megoldására vonatkozó eljárások kidolgozásáért.

A Vállalkozó által biztosított szolgáltatások szolgáltatási szint teljesítésének elszámolása az adott elszámolási időszakra vonatkozó hibajegyek alapján történik, a hibajegyek jelentik az incidenskezelési folyamat alapdokumentumát. Az incidensek elsődleges nyilvántartása a Megrendelő hibajegy kezelő rendszerében, másodlagos nyilvántartása pedig a Vállalkozó hibajegy kezelési rendszerében valósul meg. A két rendszer közötti adatszintű kapcsolatot és kétirányú szinkronizálásra alkalmas interfészt a Feleknek közösen kell kialakítaniuk a szolgáltatások megkezdése előtt.

  1. Vállalkozó Helpdesk rendszere

A Vállalkozó köteles 7/24/365-ben elérhető Helpdesk rendszert üzemeltetni, melynek célja a Megrendelőtől érkező incidensjegyek fogadása, azok kezelése és a Vállalkozó által megoldott incidensjegyek visszaszinkronizálása a Megrendelő hibajegy kezelő rendszerébe.

Amennyiben a Vállalkozó hibajegy kezelő rendszerének karbantartása válik szükségessé, a Vállalkozó köteles minimum 48 órával a műveletek végrehajtása előtt e-mail-ben írásos tájékoztatást adni a tervezett munkálatok megkezdéséről, várható időtartamáról. A Vállalkozó a karbantartási munkálatokat köteles a [Szoftverkarbantartás] folyamatban meghatározott időablakban elvégezni, és az abban a fejezetben megfogalmazott szabályokat értelemszerűen alkalmazni. A tájékoztatás elmulasztása SLA-következményeket von maga után a [Szolgáltatási szint megállapodások] fejezetben foglaltak szerint.

  1. Incidensjegy workflow



  1. Incidensjegy keletkezése

A Teljesítménymutató számítást megvalósító rendszert üzemeltető fél hibajegy kezelő rendszerében rögzített jegy keletkezési és megoldási ideje („timestamp”) képezi az SLA-számítás alapját.

Amennyiben a Felek azt észlelik, hogy SLA-számításba beszámítandó incidensjegyek esetében, több mint 3 perces szinkronizációs eltérés van, abban az esetben a Teljesítménymutató számítást megvalósító rendszert üzemeltető fél szakemberei dokumentáltan elvégzik a szükséges korrekciókat.

A folyamatot a Felek a 2. fázis előtt felülvizsgálják, és szükség szerint módosítanak rajta.

Hibajegyek kétféleképpen keletkezhetnek:

  1. Monitoring rendszer adatai alapján automatikusan generálódnak

Eseményjegyeknek keleteznek automatikus módon a Megrendelő vagy képviselője által jóváhagyott, megfelelően paraméterezett és közösen tesztelt monitoring alapadatok (eseményjelzések) alapján.

Az ily módon keletkezett hibajegyek a Megrendelő HD felületén jelennek meg.

Az automatikus hibajegyek legalább az alábbi adattartalommal kerülnek rögzítésre:

    • Hibajegy logikai kategóriája: (automatikus)

    • Hibajegy ID (automatikus)

    • Incidens létrehozója (automatikus)

    • Incidens észlelésének időpontja (automatikus)

    • Eszköz ID (automatikus)



  1. Megrendelő munkatársai által manuálisan rögzítve (ügyfél bejelentések, saját monitorozási tevékenység alapján)

Duplikáltan történő hibajegykezelés minimalizálása érdekében, a Megrendelő 1st level supportot ellátó kollégája az észlelt incidens Vállalkozó felé történő továbbítás előtt meggyőződik arról, hogy keletkezett-e automatikusan generált vagy létezik-e már manuálisan rögzített hibajegy. Az esetleges duplikációkat a Vállalkozó a megoldási folyamat során a közösen kialakított adminisztratív eljárással kezeli.

A manuális hibajegyeket a BKK HD felületen kell rögzíteni az alábbi paraméterekkel:

    • Hibajegy logikai kategóriája: manuálisan a „csempe” felületről kell kiválasztani

    • Hibajegy ID (automatikus)

    • Incidens létrehozója/szakterülete (automatikus)

    • Eszköz ID/böngésző típusa (kötelező)

      • hibajegy kategóriának megfelelő értékkészletből kerül kiválasztásra

    • Incidens észlelésének időpontja (kötelező)

      • beépített naptár alapján kell megadni (a mindenkori aktuális dátumot és azt megelőző napot lehet kiválasztani)

    • Hiba részletes kifejtése (kötelező)

      • minimum 3 karakter

      • amennyiben webfelülettel kapcsolatos ügyfélbejelentés érkezik és meg tudja adni a böngésző verziószámát, azt itt kell rögzíteni

    • IqDoc azonosító (opcionális)

A lehetséges hibajegy kategóriák (eseménytípusok) listáját és azok CBI besorolását jelen dokumentum 2. sz. melléklete tartalmazza.

Az üzemeltetési időszakban az üzemeltetési tapasztalatok alapján az incidenstípusok listája módosítható/bővíthető. Változtatásokat a Megrendelői igények alapján kell végrehajtani, valamint a Vállalkozó is kezdeményezheti a módosítást, melyhez a Megrendelő jóváhagyása szükséges. A módosításokról való egyeztetéseket a [Kérés teljesítési folyamat], ill. implementáció esetében [Változáskezelési folyamat] szerint kell végrehajtani.

Ezen felül az üzemeltetési időszakban a Feleknek rendszeresen, de minimum 6 havonta felül kell vizsgálnia az aktuális CBI-mátrix relevanciáját és szükség szerint módosítani kell azt a naprakész információk szerint a [Változáskezelési folyamatnak] megfelelően.

A Vállalkozónak meg kell javítania minden, az alábbi szoftver és hardver összetevőkkel kapcsolatos hibát függetlenül attól, hogy a meghibásodás nem megfelelő használatának tulajdonítható (gondatlanság/vandalizmus/baleset/vis maior/stb):

Software komponensek:

  • Webes alkalmazás

  • BO alkalmazás

  • Ügyfél mobil alkalmazás

  • Ellenőri alkalmazás

  • Webservice-k (ügyél alkalmazás, ellenőri alkalmazás)

Hardware komponensek:

  • Szerverek

  • Hálózati eszközök

  • Szünetmentes tápegységek

  • Ellenőri készülékek

  • Minden egyéb szállított hardware eszköz

A Felek megállapodnak, hogy a fenti felsorolt elemekre vonatkozóan egy külön dokumentumban pontosan meghatározásra kerülnek a Megrendelő és a Vállalkozó közötti feladat-, és felelősség megosztások. A feladat elvégzésének határideje az éles indulástól számított 14. naptári nap. A külön dokumentumban felsorolt felelősségi körök a Felek közös szándéka szerint az 1/B Fázis indulásával hatályát veszti, hiszen minden HW/SW-elem üzemeltetési felelőssége a Vállalkozóhoz kerül.

A gondatlanságból, vandalizmusból, jogtalan eltulajdonításból, balesetből, vagy egyéb a Vállalkozónak fel nem róható okból történő meghibásodások javítására speciális eseménykezelési eljárások és SLA feltételek vonatkoznak, melyek jelen műszaki dokumentum [Szolgáltatási Szint Megállapodások] fejezetében kerülnek rögzítésre.

Minden berendezés, eszköz vagy a Vállalkozó által szállított és/vagy  üzemeltetett bármely más rendszerelem a Vállalkozó hibakezelési rendszerének részét kell képeznie.



  1. Hibajegy kezelése

  1. Manuálisan rögzített hibajegyek

Jellemzően ügyfélbejelentéseken alapulnak – nem kerülnek át automatikusan a Vállalkozó hibajegy kezelő rendszerébe. Az ún. 1st level supportot a Megrendelő látja el. A 1st level support ellenőrzi az alábbiakat:

    • Megrendelői felelősségi körben (pl. honlap elérhetősége, holnap funkció) történt-e a meghibásodás

    • a bejelentés panaszjellegű (pl. felhasználói hiba miatt nem történt meg a sikeres tranzakció, vélhetően a felhasználó eszköze (pl. okostelefonja) nem működött megfelelően, mikor ellenőrizték, lemerült a telefonja, stb.) – ezt a Vállalkozóval megosztott aktuális monitoring adatok tudják alátámasztani

Amennyiben Megrendelő hatáskörébe tartozó vagy panasz jellegű bejelentés kerül rögzítésre, úgy a Megrendelő saját hatáskörben oldja meg a hibajegyet, az nem kerül át a TSM Ticketing rendszerébe. Amennyiben egy ilyen jellegű incidens mégis átkerül a Vállalkozóhoz, azt a megfelelő megoldási kóddal oldja meg.

Amennyiben a vizsgálat azt mutatja, hogy a hibajegy megoldása Vállalkozó hatáskörébe tartozik, továbbítja azt. Ez esetben a hibajegy kezdő időpontja a Megrendelő hibajegy kezelő rendszerében rögzített átküldési idő.



  1. Automatikusan keletkezett hibajegyek:

A Megrendelő hibajegy kezelő rendszerében keletkezett automatikus incidensjegyek automatikusan, haladéktalanul átküldésre kerülnek a Vállalkozó hibajegy kezelő rendszerében a kialakított interfészen.

A megoldó csoportok közötti eszkalációs láncok kialakítása, menedzselése a Vállalkozó felelőssége és feladata. A Megrendelő elvárása, hogy a Vállalkozó a minél hatékonyabb és gyorsabb elhárítási folyamatot dolgozzon ki a szolgáltatások helyreállítása érdekében.

  1. Hibajegy megoldása

Amennyiben egy incidens hibaelhárítása sikeresen lezajlott, a Vállalkozó a hibajegyet „megoldott” státuszba állítja, amivel a Vállalkozó hibajegy kezelő rendszere automatikusan szinkronizálja a megoldásban - a Vállalkozó által – megadott információkat és a megoldás időpontját. A Teljesítménymutató számítást megvalósító rendszert üzemeltető fél hibajegy kezelő rendszerében rögzített megoldási idő („timestamp”) képezi az SLA-számítás alapját, kivéve, ha az eltérés nagyobb 3 percnél, ekkor manuális korrekcióra van szükség.

Hibajegy megoldás esetén kötelezően megadandó paraméterek:

  1. Manuálisan rögzített hibajegyek:

    • Megoldás technikai kategóriája

      • A technikai kategóriák listáját és SLA-elszámoláshoz szükséges paramétereit jelen dokumentum 3. sz. melléklete tartalmazza

    • Megoldási kód:

      • A megoldási kódok értékkészletét tartalmazó táblázatot jelen dokumentum 4. sz. melléklete tartalmazza

    • A megoldási folyamat szöveges leírása

      • a meghibásodást kiváltó műszaki/Sw-s ok

      • milyen módon került elhárításra a meghibásodás

    • hibamentes működést igazoló dokumentum (pl. printscreen)

      • Az elvárt dokumentum szükségességét és formátumát hibajegy technikai kategóriánként kell meghatározni



  1. Automatikusan keletkezett hibajegyek:

A hibajegy kezelése megegyezik a manuálisan rögzített hibajegyek kezelésével.

Incidensjegy kizárólag abban az esetben kerülhet “megoldott” státuszba, amikor a Vállalkozó teljes kétséget kizáróan meggyőződött a hibás HW/SW elem tökéletes funkcionális működéséről és ezáltal a szolgáltatás helyreállásáról vagy a monitoring rendszer már nem érzékeli a meghibásodást és automatikusan „megoldva” állapotba léptetei az incidenjegyet. Amennyiben a megoldáskor kötelezően kitöltendő mezők hiányosan vagy pontatlanul kerülnek adminisztrálásra, a hibajegy „Megoldott” státusza elutasításra kerül a Megrendelő hibajegy kezelő rendszere által, melynek tényéről a rendszer interface-üzenetet küld a Vállalkozó részére. Az érintett hibajegy megoldását a Vállalkozónak újra meg kell küldenie a Megrendelő rendszere felé, hogy a Megrendelő rendszerében is rögzítésre kerüljön a Megoldás-státusz.

Az incidensjegyek megoldásának tartalmi elvárásai az üzemeltetési időszak során módosulhatnak. Az Megrendelő jogosult bármikor módosítást kérni a [Változáskezelési folyamatnak] megfelelően.

  1. Hibajegy lezárása

A hibajegy lezárása manuálisan vagy a megoldást követően előre beállított paraméter szerint automatikusan megtörténik.



Az incidens workflow-k az egyes incidensípusokra vonatkozóan az üzemeltetési időszak során változhatnak a Felek közös akaratának megfelelően. A workflow-módosításokat a [Változáskezelési folyamatnak] megfelelően kell kezelni.

Workflow-módosítások lehetnek például, de nem kizárólag az alábbiak:

  • hibajegy felfüggesztési funkció

  • hibajegy újranyitási funkció



  1. Szoftver karbantartás

A Megrendelő elvárja, hogy a Vállalkozó által szállított egész rendszer teljes mértékben és folyamatosan működőképes legyen. Ugyanakkor sok esetben előfordulhat, hogy egy incidens miatt a rendszer hardver- vagy szoftverelemei nem működnek. A Megrendelő célja az incidensek számának minimalizálása a rendszeres, a TSM által felügyelt és üzemeltetett szoftver-elemek megelőző karbantartási szolgáltatása révén.

Ezen felül a Vállalkozó időről időre és szükség szerint gondoskodni köteles a rendszer alkalmazásszoftvereinek, szerveroldali adatbázis kezelőjének és szerveroldali operációs rendszereinek frissítéseiről, programjavításairól, bővítéseiről, továbbfejlesztéseiről, új kiadásairól vagy verzióiról, a Vállalkozó által felügyelt, 3. fejezetben rögzítettek szerint a Vállalkozó felelősségi körébe tartozó HW-eszközökön, amely lista az 1. sz. melléklet szerinti tervezett ütemezésben meghatározott 1/B fázisra a teljes HW/SW-infrastruktúrára kiterjed. A Vállalkozó köteles a módosításokat, frissítéseket oly módon elvégezni, hogy az alkalmazás a frissítés után is legalább a megelőző verzió funkcionalitásával megegyező szinten működjön, az összes aktuálisan támogatott mobil és desktop operációs rendszeren és böngészőn. Amennyiben az alkalmazást az új, a beszerzés időpontjában még nem létező verziószámú operációs rendszerek illetve böngészők nem jelenítik meg megfelelő módon, vagy az alkalmazás működését befolyásoló funkcionális hiba jelentkezik, azt a fejlesztő cég garanciálisan köteles külön költség (munkadíj) felszámolása nélkül javítani az üzemeltetési időszakon belül, ugyanakkor ezen okokra visszavezethető hibajelenségek nem csökkentik egyetlen Teljesítménymutató rendelkezésre állását sem, amennyiben a hibajavítás az új böngésző főverziók megjelenésétől számított 14 naptári napon belül, új operációs rendszer főverzió esetén 30 naptári napon belül megtörténik. A 14. ill. 30. napot követően felvett releváns incidensjegyek beszámításra kerülnek a Szolgáltatási szint számításba.

Rendszer bevezetésekor támogatott böngészők:

Böngésző

Verzió

Chrome

57, 58

Edge

25

Firefox

53, 54

Safari

5.1

Internet Explorer

10, 11



A mobilplatformon támogatott böngészők listáját a Felek 14 napon belül meghatározzák.

A Vállalkozónak végre kell hajtania saját költségére a rendszer alkalmazásszoftvereinek, adatbázisainak és operációs rendszereinek új kiadásainak vagy verzióinak konfigurációjában szükségessé váló bővítést, kiigazítást, testre szabást és módosítást. A Vállalkozó kötelezettségei nem terjednek ki a szoftver új vagy további funkcióinak implementálásra, csak azon módosításokra, amelyeket szoftver szállítója javasol és csökkenti a működési, biztonsági kockázatokat.

Az előre tervezett karbantartásokat annak figyelembe vételével kell ütemezni és végrehajtani, hogy a rendszer feladatai ellátásában jelentős fennakadás ne következzen be, ez kiemelten fontos Megrendelői érdek. A rendszer elemeinek előre tervezett karbantartása ütemtervét az Üzemeltetési időszak minden egyes évének kezdő napjától visszafelé számított 15 naptári napon belül a Felek Projektmenedzserei egy közös, írásbeli jegyzőkönyvbe foglalják. A karbantartási ütemtervben nem kizárólag azt kell feltüntetni, hogy egy adott rendszerelem előre tervezett karbantartását melyik naptári napon tervezi elvégezni, hanem arról is, hogy az adott naptári napon milyen kezdő és befejező időpontok között fog zajlani az előre tervezett karbantartás.

A Vállalkozó eltérhet az éves karbantartási tervben megadott időpontoktól (elhalaszthat, vagy többletmunkát végezhet), de fontos, hogy a módosított időpont kizárólag a Megrendelő által engedélyezett időpontban végezheti. Halasztásról nem kell tájékoztatni a Megrendelőt, többletmunkaigénnyel kapcsolatban viszont a Megrendelő felé írásban kell jeleznie minimum 48 órával a tervezett karbantartás megkezdése előtt. A tájékoztatásban a Vállalkozó köteles részletes írásos tájékoztatást adni a Megrendelő részére a módosítandó/frissítendő szoftver elemekről.

Az előre tervezett karbantartásokat lehetőség szerint olyan időpontra kell tervezni, és azokat olyan időpontban kall végrehajtani, amikor a Megrendelő Ügyfelei a karbantartással érintett rendszerelemek kiesését a legkisebb hatásfokkal érzékelik.

A Megrendelő által karbantartásra, frissítésre, módosításra engedélyezett időszakok: kedd, csütörtök 20:00 és 02:00 közötti időintervallum

Tervezett karbantartások havi kerete: az 1. sz. melléklet szerinti tervezett ütemezésben szereplő 1/A és 1/B fázisra a Felek nem korlátozzák az engedélyezett időablakokban történő szoftverkarbantartás havi mennyiségét. A 2. fázistól számított havi keret 16 óra.

A Vállalkozó minimum 48 órával a műveletek végrehajtása előtt e-mail-ben írásos tájékoztatást ad a tervezett munkálatok megkezdéséről. A tájékoztatás elmulasztása SLA-következményeket von maga után, mely a [Szolgáltatási szint megállapodások] fejezetben kerül rögzítésre.

A Megrendelő felelős az érintett szakterületek tájékoztatásáért a tervezett karbantartási, frissítési, módosítási munkálatokról.

Amennyiben a karbantartási, frissítési, módosítási tevékenység a Vállalkozó megítélése szerint, előreláthatólag több időt vesz igénybe, mint az engedélyezett időszak, azt a tájékoztatásában külön kiemeli, és kéri a Megrendelő jóváhagyását a művelet elvégzésére. Megrendelőnek jogában áll engedélyezni a tevékenység elvégzését vagy más időpontot kijelölni.

A tervezett karbantartás ideje nem számít bele a Rendelkezésre állás idejébe, tehát a tervezett karbantartások (leállások) nem járnak SLA-büntetéssel, kivéve abban az esetben, ha azok nem az engedélyezett időszakban és nem az előre tervezett időablakban valósul meg. Amennyiben a karbantartási, frissítési, módosítási tevékenység kezdete vagy vége az engedélyezett időszakon kívülre esik, az eseményről a szolgáltatás-kiesésnek megfelelő hibajegy rögzítése szükséges, és annak megfelelően számolandó el.

A karbantartási események BI-ban történő kezelésének részletszabályait a 11.5 pont szerinti BI-fejlesztési dokumentumban kell rögzíteni.

Előfordulhatnak sürgősségi esetek (pl. sürgős biztonsági frissítések), amikor a Vállalkozónak fel nem róható okból nem lehetséges az elvárt határidőben való tájékoztatás. Az ilyen esetekben a Vállalkozó felelőssége annyiban korlátozódik, hogy a tőle telhető minden ésszerű erőfeszítést meg kell tennie annak érdekében, hogy tájékoztassa a Megrendelőt a rendszer ideiglenes leállásáról.



  1. Problémamenedzsment

A Vállalkozónak a reaktív és proaktív Problémakezelést elősegítő, szilárd Problémamenedzsment-folyamatot kell kialakítania. A reaktív megközelítés a problémamegoldásra vonatkozik egy vagy több Incidensre való reagálás tekintetében.

A Proaktív Problémamenedzsment a problémák és ismert hibák azonosítására és megoldására vonatkozik, mielőtt incidensre kerülne sor – elsősorban rendszeres trendelemzések révén, amelyek segítségével felismerhetők az incidens-nyilvántartó adatbázisban megjelenő minták.

A Megrendelő meghatározásai szerint egy Probléma egy vagy több incidens ismeretlen, mögöttes oka. Ezen felül egy Xxxxxx Hiba olyan probléma, amely sikeresen diagnosztizálásra került, és amelynek átmeneti megoldása már azonosításra került.

Az előzetesen jóváhagyott megoldásokat vagy átmeneti megoldásokat végre kell hajtani. Az előzetesen nem jóváhagyott megoldásokat vagy átmeneti megoldásokat alá kell vetni a Változásmenedzsment-folyamatnak.

A Vállalkozónak a Problémamenedzsment-folyamatot korlátozás nélkül a következő tevékenységek bevonásával kell kialakítania:

  • Problémák naplózása;

  • Problémák osztályozása;

  • Problémák kijelölése;

  • Problémák vizsgálata és diagnosztizálása;

  • A problémák átmeneti megoldásának és megoldásának a meghatározása;

  • A kiváltó okra irányuló elemzések (RCA) elvégzése, elemzések eredményének prezentálása a Megrendelő részére;

  • Az ismert hibák megoldásának végrehajtása – Változtatás iránti kérelem (RFC) kezdeményezése szükség szerint;

  • A problémák felülvizsgálata és lezárása;

  • Problémák nyomon követése és eszkalációja;

  • Az Ismert hibákról szóló adatbázis karbantartása (KEDB);

  • Az incidensekről/problémákról szóló ad-hoc jellegű felülvizsgálati megbeszéléseken való részvétel;

  • Másod- és harmadszintű támogatás biztosítása az incidensek, problémák, hibák és kérelmek esetén;

  • Megelőző intézkedések kidolgozása, bemutatása a Megrendelő részére;

  • Megrendelő kérésére az aktuális KEDB adatbázis megküldése

  • havi rendszeres Trendelemzés-jelentések készítése a Megrendelőnek

A Felek közös célja, hogy a Problémamenedzsment folyamatok hibajegy alapon kerüljenek kezelésre. A folyamat tervezett kialakítását, bevezetését az 1. sz. melléklet szerinti ütemezésben rögzítik. A közösen kialakított folyamat minden releváns részletet tartalmazó kifejtése külön technikai dokumentumban kerül rögzítésre, ami jelen dokumentum mellékletét fogja képezni.

  1. Informatikai szolgáltatás folytonosság menedzsment (BCP)

A Vállalkozónak az üzemeltetési időszakban biztosítania és fenn kell tartania a megfelelő üzletmenet-folytonossági és helyreállítási mechanizmusokat annak érdekében, hogy eleget tegyenek vagy felülmúlják a megállapodott üzletfolytonossági célkitűzéseket.

Ennek érdekében a Vállalkozó a BKK árajánlat alapján történő külön megrendelése esetén bemutatja a Szolgáltatásfolytonossági és Katasztrófa helyreállítási tervét (DRP, Disaster Recovery Plan).

A Vállalkozó által javasolt katasztrófa utáni helyreállításról szóló protokollt a Megrendelőnek kell jóváhagynia. A Protokoll legalább évente egy alkalommal, szükség szerint több alkalommal kerül felülvizsgálatra a Vállalkozó és a Megrendelő által, illetve kerül helyesbítésre a Megrendelő jóváhagyásának függvényében.

A Protokollban meghatározottak szerinti katasztrófa előfordulása esetében a Protokoll végrehajtásáért a Vállalkozót a saját hatáskörében végrehajtható tevékenységekért teljes körű felelősség terheli.

Az üzletmenet-folytonosság és a katasztrófa-helyreállítás tervezésének az üzleti hatáselemzés eredményein kell alapulniuk.

Az üzleti hatáselemzés célja annak megállapítása, hogy a rendszer egyes komponenseinek kiesése milyen hatást jelenthetnek a Megrendelő számára, ezáltal milyen szintű védelmi intézkedéseket kell kialakítani azokra vonatkozóan.

Az üzleti hatáselemzés során meg kell határozni azokat a kritikus folyamatokat (incidens menedzsment folyamatban kifejtett CBI-mátrix 3-as prioritással rendelkező folyamatai), amelyek bármilyen okból történő kiesése veszteséget okoz a BKK számára. Meg kell vizsgálni, hogy a kritikusként azonosított folyamatok a rendszer mely komponensei által támogatottak, milyen adatokat kezelnek, a rendszer mely komponensei által támogatottak, illetve melyek azok az egyéb folyamatok, melyek függőségi viszonyban vannak a meghatározott kritikus folyamatokkal.

Három fő szempont szerint kell vizsgálni a folyamatokat, a kezelt adatokat, illetve a kapcsolódó rendszer komponenseket:

  • rendelkezésre állás,

  • bizalmasság,

  • sértetlenség.

Meg kell határozni tehát, hogy milyen szintű hatást jelent a rendszerkomponensek különböző időtávú kiesése, a tárolt és kezelt adatok sérülése, illetve idegen kézbe kerülése. Meg kell határozni, mennyi az az idő, amelyen belül a szolgáltatás minimális szintjét vissza kell állítani.

A normális üzletmenettől eltérő események, informatikai kiszolgálás leállása esetén is elvárás a kritikus üzleti területek funkcióinak ellátása (1. sz. mellékletben felsorolt CBI-mátrix 3-as prioritással rendelkező (és a hibajegy megoldásban visszaigazoltan szolgáltatás kiesést jelentő) incidensek), mely ideiglenesen alkalmazható (kerülő) eljárások biztosításán keresztül is megvalósítható.

A Vállalkozó által az 1. sz. mellékletben rögzített határidőre elkészült árajánlat alapján a BKK külön megrendelése alapján a TSM elkészíti és bemutatja a DRP dokumentumot.

  1. Rendszer monitoring

A Vállalkozó a Xxxxx által az 1. sz. mellékletben rögzített tervezett bevezetési ütemezés szerinti, közösen meghatározott Rendszerellenőrző (monitoring) alkalmazás(ok) segítségével köteles a hét minden napján, napi 24 órában ellenőrizni a rendszer működését, és közben folyamatos hozzáférést és ellenőrzést biztosítani a Megrendelő számára. A hozzáférés kiterjed, de nem korlátozódik az alábbi tételekre:

  • a rendszerben éppen aktuális adatokra (Megrendelői igényeknek megfelelő grafikus, interaktív dashboardon vagy egyéb GUI-n keresztül)

  • a rendszerben rögzített historikus eseményjelzési adatok adatbázisára,

  • és minden olyan monitoring alapadatra, mely az automatikusan generált incidens-, és problémajegyek alapadatait szolgáltatják

A Rendszer monitoring tevékenység céljai:

  1. szolgáltatás szintű mérést biztosít (elérhetőek-e az Ügyelek részére biztosított szolgáltatások, és azok megfelelően működnek)

  2. méri a Vállalkozó hatáskörében üzemeltetett felhasználók által elérhető szolgáltatási felületek performanciáját (Webfelület, ügyfél applikációt és ellenőri applikációt kiszolgáló webservice-ek, Megrendelő által elérhető BO felületek)

(Az előzőekben felsorolt monitorozandó elemek listája az alkalmazott technológia függvényében még változhat, ezért csak a monitoring rendszer koncepciójának kialakításakor kerül véglegesítésre.)

  1. elszámolási időszakonként rendelkezésre állási és teljesítményre vonatkozó jelentéseket generál a rendszer működésével kapcsolatban. A jelentéseket a Megrendelő részére elektronikus formában biztosítja

  2. A jelentésekből ki kell derülnie, hogy a monitoring rendszer által mért metrikák alapján az SLA-követelmények teljesültek-e vagy sem, a tényértékek hogyan viszonyulnak az elvárt célértékekhez.

  3. a különböző mérési pontokon észlelt riasztások és jelzések alapján automatikusan generált incidenseket automatikusan továbbítsa a Megrendelő hibajegy kezelő (HelpDesk) rendszeréhez. (opcionális, bevezetése döntéstől függ, lásd 1. sz. melléklet)

A monitorozást végző rendszert a Vállalkozó ajánlásai alapján a Megrendelő elvárásainak megfelelően szükséges paraméterezni. A megfelelő paraméterezés a Vállalkozó felelőssége, melyet a Megrendelő tesztel és hagy jóvá. A Xxxxx által közösen kialakított és bevezetett mérési módszertant és incidens generálási szabályokat dokumentálni szükséges.

A rendszer bevezetésének tervezett ütemezését az1. sz. melléklet tartalmazza.

A közösen kialakított monitoring folyamat minden releváns részletet tartalmazó kifejtése külön technikai dokumentumban kerül rögzítésre, ami jelen dokumentum mellékletét fogja képezni.

A BKK az üzemeltetési időszak során bármikor kezdeményezheti a rendszer monitoring beállítások finomhangolását, módosítását a [Változásmenedzsment folyamatnak] megfelelően.

Az automatikus hibajegykezelés éles bevezetéséig, a Felek az átmeneti időszakra manuálisan végzett hibajegy kezelési folyamatot dolgoznak ki.

A monitoring rendszer implementálását, paraméterezését és a Ticketing rendszerhez illesztését, Megrendelő által történő megrendelésük esetén, az 1. sz. melléklet szerinti ütemezés alapján aTSM egy külön eljárás keretében végzi el, az egyedi ajánlatban foglalt feltételeknek megfelelően.



  1. Kérésteljesítési folyamat (request fullfillment)



A Megrendelő időről időre a Vállalkozóhoz fordulhat olyan esetekben, amikor nem saját hatáskörben végzett tevékenységet vagy számára nem, vagy csak nagy erőforrásigénnyel fellelhető információra, tanácsra, vagy egyszerűbb rendszer paraméter módosításra van szüksége, melyhez nincs szükség külön megállapodásra vagy felsőbb szintű jóváhagyásra.

A Megrendelő formálisan (éles induláskor írásban, e-mail-ben, a tervezett 2. fázistól külön jegytípuson) kér adatot, információt, tanácsot, a Vállalkozótól, mely kéréseket a ticketing rendszer adatbázisában tárolja.

Ilyen kérések lehetnek például, de nem kizárólag az alábbiak:

  • információ/támogatáskérés a rendszerrel, annak működésével kapcsolatban

  • információkérés kritikus incidensről, problémáról

  • információkérés egy ismert hiba hátteréről, megoldásának, megelőzésének módjáról

  • KEDB adatbázis megosztása (azonosított hibák és problémák listája, érintett rendszerelemek/szolgáltatások, szolgáltatás helyreállítási lépések, kerülő megoldások kifejtése)

  • Megrendelő által készített üzemeltetéshez kapcsolódó dokumentum, javaslat véleményezése

  • gyártói/üzemeltetői szakvélemény kérés



A Felek a kérések számát havi szinten korlátozhatják, vagy egy bizonyos mennyiség felett hosszabb határidőben állapodhatnak meg, az 1. sz. melléklet szerinti 2. fázistól kezdődően.

A Felek megállapodásának megfelelően a kérések teljesítésére vonatkozó SLA-követelményeket, limitációkat a Felek az 1. sz. mellékletben rögzített tervezett ütemezés 2. fázisától kezdve alkalmazzák a bevezetéstől számított első 6 hónap üzemeltetési tapasztalatai alapján.

A kéréseket a Vállalkozónak határidőre kell teljesítenie, mely a kéréstípusonként megállapodott, később rögzítendő időtartamot vehet igénybe. Határidő elmulasztása esetén SLA-következményekkel kell számolni, melyek részleteit a [Szolgáltatási Szint Megállapodások] tartalmazza.

A Felek közös célja, hogy a Kérésteljesítési folyamatok hibajegy alapon kerüljenek kezelésre. A folyamat tervezett kialakítását, bevezetését az 1. sz. melléklet szerinti ütemezésben rögzítik. A közösen kialakított folyamat minden releváns részletet tartalmazó kifejtése külön technikai dokumentumban kerül rögzítésre, ami jelen dokumentum mellékletét fogja képezni.

  1. Változásmenedzsment folyamat

A Vállalkozó célja a változáskezelés tekintetében az, hogy a szabvány eljárásokat és módszereket hatékonyan alkalmazzák a változások kezelésére, amellett, hogy törekszenek arra, hogy az informatikai infrastruktúrákat ellenőrizzék és a teljes üzleti kockázatokat optimalizálják.

A Beszállító köteles kategorizálni a változásokat a változások bonyolultsága és sürgősségi állapotuk megállapításának megfelelően. Az egyes kategóriákhoz költséget és határidőket rendelnek a Felek, melyek betartása a Vállalkozó felelőssége. Határidő elmulasztása esetén SLA-következményekkel kell számolni, melyek részleteit a [Szolgáltatási Szint Megállapodások] tartalmazza.

  1. kategória: egyszerűbb, de szakértelmet igénylő, ingyenes módosítások, rövid határidővel vagy jogszabály követési szolgáltatás hatáskörébe tartozó feladat

Jellemzően nem jelent fejlesztési feladatot (pl. CBI-mátrix módosítása, incidensjegyek paraméter módosítása, kártyaelfogadási paraméterek módosítása, online bankkártyás fizetéssel kapcsolatos módosítások, stb.)

  1. kategória: egyszerű fejlesztési feladat, lehet ingyenes vagy díjköteles, a határidővel kapcsolatban a Xxxxx egyedi megállapodást kötnek

  2. kategória: komplex fejlesztési feladat, díjköteles, a határidővel kapcsolatban a Felek egyedi megállapodást kötnek

A Vállalkozó köteles a változáskezelést oly módon fejleszteni, hogy az kiterjedjen, de ne korlátozódjon az alábbi tevékenységekre:

  • Megrendelő által specifikált Változási igényre való reagálás (írásbeli ajánlatadás) a Változás-kategóriánként megállapodott, később rögzítendő időtartamon belül változások kezdeményezése, naplózása, priorizálása, osztályozása (tervezett, nem tervezett); kijelölése a végrehajtó csoportok számára, kockázat- és hatásfelmérése; roll-back terv készítése

  • elfogadott változtatási kérelmek implementálása, tesztelése, kiterjesztése, ellenőrzése és lezárása;

  • a lezárt változtatási folyamatok teljes körű dokumentálása;

  • azon Változtatások kezelése, melyek nem valósultak vállalt határidőre

A Felek közös célja, hogy a Változásmenedzsment folyamatok hibajegy alapon kerüljenek kezelésre. A folyamat tervezett kialakítását, bevezetését az 1. sz. melléklet szerinti ütemezésben rögzítik. A közösen kialakított folyamat minden releváns részletet tartalmazó kifejtése külön technikai dokumentumban kerül rögzítésre, ami jelen dokumentum mellékletét fogja képezni.

  1. Szolgáltatás Katalógus

    1. Üzleti szolgáltatások

      1. Front Office

  1. regisztráció

  2. vásárlás, bankkártyás online fizetés

  3. ügyfél applikáció (bérlet használata)



      1. Back Office (BKK folyamatok+felelősök xls, BKK BO menüstruktúra doc)

  1. Törzsek karbantartása (14 folyamat)

  2. Értékesítési BO folyamatok (11 folyamat)

  3. Kártyakezelés (3 folyamat)

  4. Ellenőri BO folyamatok (2 folyamat)

  5. Bevétel feladás TSM

  6. Számlaarchiválás TSM (Netlock)

  7. Rendszergazdai funkciók (7 folyamat)



      1. Ellenőrzés

  1. ellenőri készülékek javítása, cseréje

  2. mobilkapcsolat biztosítása az ellenőri készülék és a BO között

  3. ellenőri applikáció



    1. Üzemeltetési szolgáltatások

  1. Esemény-, incidens-, és Problémamenedzsment

  2. Szoftver karbantartási szolgáltatások

  3. Kérések teljesítése (request fulfillment)

  4. Változásmenedzsment

  5. Rendszer monitoring (amennyiben TSM szállítja és felügyeli)



Az üzemeltetési időszak során a Felek kezdeményezheti a Szolgáltatás Katalógus módosítását. A módosítás hatását meg kell vizsgálni és el kell dönteni, hogy a módosítás a szerződés módosítását is jelenti vagy elegendő egy [Változásmenedzsment folyamat] szerinti módosítást végrehajtani.

  1. Szolgáltatási szint megállapodások



    1. Szolgáltatás értékelés

Megrendelő mérni kívánja a Válallkozó által nyújtott szolgáltatások minőségét. A Vállalkozó által nyújtott szolgáltatások a [Szolgáltatás Katalógusban] kerülnek definiálásra. A méréseket a Megrendelő ún. KPI-mutatókon keresztül méri, melyekhez a Megrendelő Célértéket rendel. A KPI-mutatók listája, alkalmazásuk módszertana jelen fejezetben kerül rögzítésre. A Felek havonta értékelelik a KPI-mutatók teljesítését. Amennyiben valamely KPI-hoz tartozó Célérték nem teljesült, úgy azt a Felek KPI-szegésnek tekintik és a KPI-hoz tartozó SLA-szabályok alapján elvégzik a díjcsökkentés mértékének kalkulációját.

A KPI-ok mérését és az azokhoz tartozó esetleges díjcsökkentések kalkulációját bevezetéskor a Vállalkozó végzi a közösen megállapodott számítási algoritmusok mentén, és a Megrendelő ellenőrzi, ill. hagyja jóvá a számításokat. Az üzemeltetési időszak során a Megrendelő bármikor dönthet egyoldalúan arról, hogy a KPI-okhoz tartozó díjcsökkentési számításokat saját hatáskörben végzi, ebben az esetben a TSM és a Megrendelő által készített Teljesítménymutató számításokat össze kell hasonlítani és az esetleges eltérések okát fel kell tárni és a megfelelő rendszerben a szükséges módosításokat el kell végezni. A döntésről írásban tájékoztatja a Vállalkozót. Az elkészült riport képzi a havi Teljesítés Igazolás alapját.

    1. SLA-alapelvek

A KPI alapú SLA-rendszer úgy kerül meghatározásra, hogy az tükrözze a Megrendelő üzleti érdekeit és a Vállalkozói oldalon is tervezhetővé tegye a szükséges erőforrás-kapacitásokat.

  • Valamennyi szolgáltatás elem esetén az elvárt szolgáltatási idő 24/7/365

  • A szolgáltatási szint mutatók (KPI-ok) értékelésére havonta kerül sor, a díjcsökkentések is a havi elszámolás alapján kerülnek meghatározásra

  • A Díjcsökkentés mértékének maximuma havionta 1,8 millió Ft üzemeltetési díj

  • A rendelkezése állás mérése során csak azon események (incidensjegyek) lesznek figyelembe véve, amelyek a Szolgáltatás katalógusban azonosított szolgáltatások tényleges kiesésével járnak

  • Kizárólag olyan esetekben kerül sor díjcsökkentésre, amikor a Vállalkozónak felróható okból történt csökkenés a szolgáltatás minőségében

  • A KPI-okat nem lehet oly módon alkalmazni, hogy ugyanazon eseményért a Vállalkozó többszörösen legyen büntetve

  • A KPI teljesítmény-mérések alapbizonylatát jelentő hibajegyek elszámolásakor a Megrendelő hibajegy kezelő rendszerében regisztrált időbélyegeket kell az elszámoláskor figyelembe venni, kivétel, ha a Megrendelő és a Vállalkozó rendszereiben található időbélyegek különbsége több mint három perc. Tehát az időbélyegek manuális korrekciójának lehetőségét a teljesítménymutató számítást megvalósító rendszernek biztosítania kell

  • az incidensek megoldása a KPI-listába meghatározott (15/45 perces) türelmi idővel kezdődnek, mely időintervallum nem számít bele a teljesítménymutató számításba (nem része az aktív jegyidőnek), melynek számítását a BI-modul automatikusan kezeli. Jelen szabály alkalmazását a Felek az 1. sz. melléklet szerinti 2. fázisra felülvizsgálják

  • Az előre jelzett, tervezett szoftver karbantartási időablakok nem számítanak be az SLA-számításba (csökkentik a vetítési alapot), tehát a tervezett karbantartás alatt keletkezett és folyamatban lévő bejelentések aktív jegyidejét csökkenteni kell az tervezett karbantartás időablakával.

  • A tárgyhónapban az alábbi tételeket kell elszámolni:

    • incidensjegyek közül azok, amelyek állapota már „lezárt”, tehát a bejelentések abba a hónapba számítanak, amelyben lezáródtak.

    • olyan események, amelyek értékelése határidőhöz kötött, a Vállalkozó általi teljesítés dátumát követően (pl. egy Kérésteljesítési esemény határideje 01.30, a tényleges teljesítés 02.05, akkor azt a 02. hónapra vonatkozóan kell elszámolni, tekintettel arra, hogy a késés mértéke ekkor vált ismertté)

  • Esetleges duplikációk esetén a szülő-gyermek elvet kell követni az incidenskezelésben, tehát a szülő incidens nyitva marad, a gyermek pedig megoldásra kerül, a szülő incidensre való hivatkozás mellett.

  • Azt, hogy egy bejelentés teljesítménymutató beszámító-e, vagy sem, azt az alábbi feltételrendszer mentén határozható meg:

    • Jegytípus: lehet incidens, igény hatáselemzés, igény végrehajtás, ügyfél panasz, vagy tervezett karbantartás. A jegytípus határozza meg, hogy melyik teljesítménymutatóra és milyen hatással van a szóban forgó bejelentés.

    • Kategorizálás (Technikai kategória): meghatározza az adott kategória teljesítménymutató beszámító-e vagy sem.

    • Megoldási kód: Meghatározza, hogy a szóban forgó bejelentésben leírt hibajelenség hogyan lett megoldva. A rendszer indulásakor alkalmazott megoldási kódok listáját a 4. sz. melléklet tartalmazza.

  • Az aktív jegyidő jegytípustól függetlenül a rögzítés időpontja és a megoldás időpontja között eltelt időintervallumot jelenti.

  • Amennyiben egy ellenőri eszköz gondatlanságból, balesetből vagy szándékos rongálás miatt kerül üzemképtelen állapotba, akkor a javítására vagy cseréjére speciális SLA-szintek kerülnek meghatározásra (az egyes KPI-ok kifejtésénél kerül meghatározásra a pontos elvárás) , a TVM Fő Projektszerződés 3. sz. szerződés módosításában rögzített BKK anyagi felelősségvállalása mellett



    1. KPI fejlesztési alapelvek

  • A KPI mutatók fejlesztésekor vezető irányelvként az áttekinthetőség és a műszaki mérés állt a középpontban;

  • A KPI mutatók célértékei és elérhetőségi szintjei (availability range) oly módon kerülnek meghatározásra, hogy azok megfelelően képviseljék a Megrendelő üzleti érdekeit, valamint kellően motiválóak legyenek a Vállalkozó számára;

  • A KPI mutatók dokumentálása és jelentése biztosított legyen;

  • További KPI mutatók bevezetésének rugalmassága, valamint a KPI mutatók paramétereinek módosítása rugalmas legyen

  • A BKK az üzemeltetési időszak során bármikor kezdeményezheti a KPI-ok listájának vagy az egyes KPI-ok paramétereinek módosítását a [Változásmenedzsment folyamatnak] megfelelően, melynek véglegesítéséhez a Felek megállapodása szükséges.



    1. KPI-lista

A KPI-okat, azok célértékeit és kalkulációs szabályait jelen dokumentum 5. sz. melléklete, míg az egyes KPI-ok elszámolásra vonatkozó információk részletes kifejtését az 5.1 – 5.22 mellékletek tartalmazzák.

    1. BI-fejlesztés

A BKK által megfogalmazott és közösen elfogadott SLA-mérési alapelveket implementálni kell az elszámolások gyors és hibamentes elszámolása érdekében. A BI-rendszer tervezett bevezetését a Felek az 1. sz. melléklet szerinti ütemezésben rögzítik. Az elszámolásra vonatkozó szabályok minden releváns részletét tartalmazó kifejtése egy BI-fejlesztési dokumentumban kerül rögzítésre, ami jelen dokumentum mellékletét fogja képezni.

A Teljesítménymutatók számításának manuálisan rögzített incidensjegyek alapján történő megvalósítása a TSM az 1. sz. melléklet szerinti 1/A és 1/B fázisra külön díjazás nélkül elkészíti. A BI-fejlesztés ütemezése várhatóan a következők szerint alakul:

  • éles indítást követő 30 napon belül elkészül az igény specifikáció

  • az igény specifikáció alapján az implementáció, tesztelés, bevezetés 60-90 naptári napot vesz igénybe

  • a közösen tesztelt és elfogadott BI-rendszer alapján megtörténik a visszamenőleges elszámolás az éles indulástól kezdődően

  • A BI-modul elkészüléséig a Felek megállapodnak abban, hogy

    • az éles indulástól számított 1-4. hónapban 90%-os átalányértéken számolnak el

    • a 5. hónaptól kezdve a BI-modul élesítéséig 100%-os átalányértéken



  1. Mellékletek



  1. sz. melléklet: Szolgáltatási szint méréshez kapcsolódó funkciók bevezetési ütemterve

  2. sz. melléklet: Incidens Logikai Kategóriák listája és CBI-besorolásuk

  3. sz. melléklet: Incidens Technikai Kategóriák listája és paramétereik

  4. sz. melléklet: Incidens Megoldási Kódok listája és beszámítási paramétereik

  5. sz. melléklet: KPI-lista

5.1 – 5.15 sz. mellékletek: KPI-ok részletes adatlapja



  1. melléklet: Szolgáltatási szint méréshez kapcsolódó funkciók bevezetési ütemterve

[Verzió 1.0 (2017.07.08)]



Funkcionalitás

Fázis 1/A

Rendszerbevezetés

(a Webes értékesítés éles indítása,

várhatóan 2017.07.08)

Fázis 1/B

Dedikált infrastruktúrára kerülnek az alkalmazások

(a rendszer éles indítását követő 2-6 hónapon belül)

Fázis 2

Monitoring rendszer elindítása alap scope-pal

(a rendszer éles indítását követő 6 hónapon belül)

Fázis 3

Elszámolási adatok elsődleges információforrása a Rendszer monitoring (hibajegy vagy riport)

(a Fázis 2 lezárását követő 6 hónapon belül)

Eseménymenedzsment





riasztási események beállítása BKK részére

-

-

OK

(Első körös riasztások működnek)

OK

(finomhangolás)

Incidensmenedzsment





Manuális incidensjegyek kezelése

OK

OK

OK

OK

Automatikus incidensjegyek kezelése

-

-

-

OK

(rendszer monitoring koncepció alapján)

1st level support biztosítása

-

-

OK

(rendszer monitoring koncepció alapján)

OK

(rendszer monitoring koncepció alapján)

Szoftverkarbantartás (TMK)





Előzetes tájékoztatás a rendszerkarbantartásról

OK

(e-mailen)

OK

(e-mail-en)

OK

(Külön jegytípuson)

OK

(Külön jegytípuson)

Problémamenedzsment

OK

(induláskor kommunikáció e-mail-en, telefonon,

éles indulástól számított 30 napon belül hibajegy koncepció kidolgozása, Fázis2-re bevezetés)

OK

(kommunikáció e-mail-en, telefonon)

OK

(Külön jegytípuson)

OK

(Külön jegytípuson)

BCP/DRP

Nem alapfeltétel az éles induláshoz.

TSM az éles indulástól számított 30 napon belül indikatív árajánlatot ad.

BKK megrendelés esetén a TSM kidolgozza és leszállítja a dokumentációt

BKK megrendelés esetén a TSM kidolgozza és leszállítja a dokumentációt

BKK megrendelés esetén a TSM kidolgozza és leszállítja a dokumentációt

Rendszermonitoring

TSM az éles indulástól számított 30 napon belül elkészíti a rendszer monitoring koncepciót.

A koncepció alapján folytatott egyeztetettek eredményeként a Felek külön megállapodásban rögzítik a beszerzés feltételeit, oly módon, hogy az alap-scope-pal való indulás a Fázis 2-re (éles indulástól számított 6 hónap) megvalósul, a részletesen specifikált/tesztelt verzió pedig a Fázis 3-ra (további 6 hónap).

A Fázis 2 tervezett indulása abban az esetben tartható, amennyiben a Monitoring rendszert az éles indulástól számított 60 naptári napon belül a BKK megrendeli. A megrendelés csúszása hatással van a Fázis 2 indulására.

A koncepciónak részletesen tartalmaznia kell, hogy mit tervezünk bevezetni 2. és 3. fázisra.

A 1st level support a BKK döntése alapján a 2. fázisra valósulhat meg.

-

OK

(éles indulás a koncepcióban rögzített „alap szintű” scope-pal)

OK

(mérési scope finomhangolása, bővítése, megállapodások, paraméter beállítások dokumentálása, az SLA-elszámolás a monitoring adatok alapján történik)

Request fulfillment

OK

(induláskor kommunikáció e-mail-en, telefonon,

éles indulástól számított 30 napon belül hibajegy koncepció kidolgozása, Fázis2-re bevezetés)

OK

Bevezetéskor hagyományos csatornán, mérés nélkül (tel, e-mail)

OK

(Külön jegytípuson)

OK

Változásmenedzsment

OK

(induláskor kommunikáció e-mail-en, telefonon,

éles indulástól számított 30 napon belül hibajegy koncepció kidolgozása, Fázis2-re bevezetés)

OK

OK

(Külön jegytípuson)

OK

Szolgáltatás katalógus

OK

OK

OK

OK

Szolgáltatási szint mérés

OK

(incidensjegyek esetében Fázis 1-re leegyeztetett KPI-ok és KPI-értékek alapján)

OK

(Finomhangolás)

OK

(Finomhangolás, további jegytípusok kezelése)

OK

(Finomhangolás)

BI-fejlesztés, teljesítménymutató számítás

TSM 11.5 pont szerinti ütemezésben elkészíti a BI—modult, ami az SLA-szabályok alapján kalkulálja az üzemeltetési díjat, és riportol a BKK felé.

BKK előzetesen jóváhagyja a riport tartalmi elemeit/formáját.

Felek a 2, 3 fázisok indulásáig megállapodnak a fázis indulásához szükséges BI-módosítások részleteiben.

OK

OK

(KPI-ok listájának és paramétereinek felülvizsgálata, finomhangolása)

(BKK döntéstől függően saját BI-t fejleszt)

OK

(KPI-ok listájának és paramétereinek felülvizsgálata, finomhangolása)



  1. melléklet: Incidens Logikai Kategóriák listája és CBI-besorolásuk

[Verzió 1.0 (2017.07.08)]

Incidens kategóriák

CBI-érték
(3-magas, 2-közpes, 1-alacsony)

Webfelület

Felület nem elérhető

3

Webfelület

Bejelentkezés

3

Webfelület

Regisztráció

3

Webfelület

Regisztráció módosítás

1

Webfelület

Utas összekapcsolás

1

Webfelület

Vásárlás

3

Webfelület

Számlázás

3

Webfelület

Egyéb

1

Értesítési rendszer - e-mail

Egyedi e-mail küldési hiba

1

Értesítési rendszer - e-mail

Tömeges e-mail küldési probléma

3

Értesítési rendszer - e-mail

Egyéb

1

Mobilalkalmazás

Sikertelen bejelentkezés

1

Mobilalkalmazás

Alkalmazás nem elérhető

3

Mobilalkalmazás

Nyelvi paraméterezési problémák

1

Mobilalkalmazás

Hibás termékadat megjelenítés

1

Mobilalkalmazás

Egyéb

1

Háttérrendszer

Háttérrendszer nem elérhető

3

Háttérrendszer

Törzsek karbantartása

2

Háttérrendszer

Bevételfeladás

3

Háttérrendszer

Számla archiválás

3

Háttérrendszer

Riportgenerálás

2

Háttérrendszer

Díjtermék normál visszaváltása

3

Háttérrendszer

Díjtermék méltányossági visszaváltása

3

Háttérrendszer

Díjtermék letiltás

3

Háttérrendszer

Díjtermék feloldás

3

Háttérrendszer

Számlahelyesbítés

3

Háttérrendszer

Számla újraküldés

3

Háttérrendszer

E-mail újraküldés

2

Háttérrendszer

Panaszkivizsgálás

1

Háttérrendszer

Egyéb

1

Ellenőrzés

Hibás termékadat megjelenés

3

Ellenőrzés

Sikertelen bejelentkezés

1

Ellenőrzés

Alkalmazás hiba

1

Ellenőrzés

Alkalmazás nem elérhető

1

Ellenőrzés

Adatkapcsolati hiba

3

Ellenőrzés

Egyéb

1

Ellenőri készülék

Készülék hiba

1

Ellenőri készülék

Egyéb

1






  1. sz. melléklet: Incidens Technikai Kategóriák listája és paramétereik

[Verzió 1.0 (2017.07.08)]


Technikai Kategória

Beszámítás

Érintett KPI

Szolgáltatáselem név

Főkategória név

Bejelentéstípus név

Szorzó

 

Érintett KPI

Webes alkalmazás

Rendelkezésre állás

Webes alkalmazás nem elérhető

1

FO-01

Webes alkalmazás rendelkezésre állása

Webes alkalmazás

Regisztráció

Sikertelen regisztráció

Eszköztípustól függ

FO-02

Regisztráció funkció elérhetősége

Webes alkalmazás

Regisztráció

Regisztrációs felület nem elérhető

Eszköztípustól függ

FO-02

Regisztráció funkció elérhetősége

Webes alkalmazás

Regisztráció

Egyéb

0

FO-02

Regisztráció funkció elérhetősége

Webes alkalmazás

Értékesítés

Vásárlási folyamat nem indítható

Eszköztípustól függ

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

Termék nem választható

Eszköztípustól függ

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

Termék nem örökli az érvényességet

Eszköztípustól függ

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

Termék érvényesség módosítása hibás

Eszköztípustól függ

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

Terméket nem lehet kosárba rakni

Eszköztípustól függ

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

Terméket nem lehet kosárból törölni

Eszköztípustól függ

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

Kosár értéke vagy darabszáma hibás

Eszköztípustól függ

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

Számlázási képernyő nem érhető el

Eszköztípustól függ

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

Természetes/Nem természetes személy kezelése hibás

Eszköztípustól függ

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

Regisztrációs számlázási adatok nem öröklődnek

Eszköztípustól függ

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

OTP fizetési folyamat nem hajtható végre

0

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

Fizetési folyamat végén a záró képernyő rosszul jelenik meg

Eszköztípustól függ

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Értékesítés

Egyéb

0

FO-03

Értékesítési funkció elérhetősége

Webes alkalmazás

Adatmódosítás

Ügyféladat módosítás sikertelen

Eszköztípustól függ

FO-03

Ügyfél alapadatok módosításának elérhetősége

Webes alkalmazás

Adatmódosítás

Utazási okmányok hozzáadása sikertelen

Eszköztípustól függ

FO-03

Ügyfél alapadatok módosításának elérhetősége

Webes alkalmazás

Adatmódosítás

Utazási okmányok törlése sikertelen

Eszköztípustól függ

FO-03

Ügyfél alapadatok módosításának elérhetősége

Webes alkalmazás

Adatmódosítás

Utazási okmányok aktiválása sikertelen

Eszköztípustól függ

FO-03

Ügyfél alapadatok módosításának elérhetősége

Webes alkalmazás

Adatmódosítás

Egyéb

0

FO-04

Ügyfél alapadatok módosításának elérhetősége

Webes alkalmazás

Utascsoportosítás

Felhasználó csoporttagság megszűntetése

Eszköztípustól függ

FO-05

Utas összekapcsolási funkció elérhetősége

Webes alkalmazás

Utascsoportosítás

Felhasználó csoporttagság hozzáadása

Eszköztípustól függ

FO-05

Utas összekapcsolási funkció elérhetősége

Webes alkalmazás

Utascsoportosítás

Egyéb

0

FO-05

Utas összekapcsolási funkció elérhetősége

Mobilalkalmazás

Mobilalkalmazás

Sikertelen bejelentkezés

0

-

Nem értelmezett

Mobilalkalmazás

Mobilalkalmazás

Alkalmazás nem elérhető

0

-

Nem értelmezett

Mobilalkalmazás

Mobilalkalmazás

Nyelvi paraméterezési problémák

0

-

Nem értelmezett

Mobilalkalmazás

Mobilalkalmazás

Hibás termékadat megjelenítés

0

-

Nem értelmezett

Mobilalkalmazás

Mobilalkalmazás

Egyéb

0

-

Nem értelmezett

Mobilalkalmazás

Mobilalkalmazás webservice

Webservice nem elérhető

1

FO-06

Ügyfél mobilapplikáció webservice elérhetősége

Mobilalkalmazás

Mobilalkalmazás webservice

Egyéb

0

FO-06

Ügyfél mobilapplikáció webservice elérhetősége

Értesítési rendszer

Értesítési rendszer

Értesítési rendszer nem elérhető

1

FO-07

E-mail küldési funkció működése

Értesítési rendszer

Értesítési rendszer

Regisztráció visszaigazolása

0

FO-07

E-mail küldési funkció működése

Értesítési rendszer

Értesítési rendszer

Jelszó emlékeztető

0

FO-07

E-mail küldési funkció működése

Értesítési rendszer

Értesítési rendszer

Csoporttagság felvétel visszaigazolása

0

FO-07

E-mail küldési funkció működése

Értesítési rendszer

Értesítési rendszer

Vásárlás visszaigazolás

0

FO-07

E-mail küldési funkció működése

Értesítési rendszer

Értesítési rendszer

Végfelhasználó értesítése

0

FO-07

E-mail küldési funkció működése

Értesítési rendszer

Értesítési rendszer

Számla

0

FO-07

E-mail küldési funkció működése

Értesítési rendszer

Értesítési rendszer

Egyéb

0

FO-07

E-mail küldési funkció működése

BackOffice

BackOffice

A Back Office rendszer nem érhető el

1

BO-01

BO rendelkezésre állás

BackOffice

Törzsek karbantartása

Értékesítési törzsek karbantartásával kapcsolatos hiba

1

BO-02

Törzsek karbantartásának elérhetősége

BackOffice

Törzsek karbantartása

Számlázási adatok karbantartásával kapcsolatos hiba

1

BO-02

Törzsek karbantartásának elérhetősége

BackOffice

Törzsek karbantartása

E-mail beállítások karbantartásával kapcsolatos hiba

1

BO-02

Törzsek karbantartásának elérhetősége

BackOffice

Törzsek karbantartása

WEB lap szövegek karbantartásával kapcsolatos hiba

1

BO-02

Törzsek karbantartásának elérhetősége

BackOffice

Törzsek karbantartása

Nyomtatványok adatainak karbantartásával kapcsolatos hiba

1

BO-02

Törzsek karbantartásának elérhetősége

BackOffice

Törzsek karbantartása

Ellenőrzéssel kapcsolatos törzsadatok karbantartásával kapcsolatos hiba

1

BO-02

Törzsek karbantartásának elérhetősége

BackOffice

Törzsek karbantartása

Rendszerparaméterek karbantartásával kapcsolatos hiba

1

BO-02

Törzsek karbantartásának elérhetősége

BackOffice

Törzsek karbantartása

Egyéb

0

BO-02

Törzsek karbantartásának elérhetősége

BackOffice

Riportok

Riport - Napi pénztárforgalom riportjaival kapcsolatos hibajelenségek

1

BO-03

Riportok lekérdezésének elérhetősége

BackOffice

Riportok

Riport - Bérlet adatok lekérdezésével kapcsolatos hibajelenségek

1

BO-03

Riportok lekérdezésének elérhetősége

BackOffice

Riportok

Riport - Számla adatok lekérdezésével kapcsolatos hibajelenségek

1

BO-03

Riportok lekérdezésének elérhetősége

BackOffice

Riportok

Riport - Vásárló adatok lekérdezésével kapcsolatos hibajelenségek

1

BO-03

Riportok lekérdezésének elérhetősége

BackOffice

Riportok

Egyéb

0

BO-03

Riportok lekérdezésének elérhetősége

BackOffice

Termékmanagement

Díjtermék normál visszaváltással kapcsolatos hiba

1

BO-04

Ügyfélszolgálat által használt BO funkciók rendelkezésre állása

BackOffice

Termékmanagement

Díjtermék méltányossági visszaváltással kapcsolatos hiba

1

BO-04

Ügyfélszolgálat által használt BO funkciók rendelkezésre állása

BackOffice

Termékmanagement

Díjtermék letiltással kapcsolatos hiba

1

BO-04

Ügyfélszolgálat által használt BO funkciók rendelkezésre állása

BackOffice

Termékmanagement

Díjtermék feloldással kapcsolatos hiba

1

BO-04

Ügyfélszolgálat által használt BO funkciók rendelkezésre állása

BackOffice

Termékmanagement

Számlagenerálási hiba

1

BO-04

Ügyfélszolgálat által használt BO funkciók rendelkezésre állása

BackOffice

Termékmanagement

Számlahelyesbítéssel kapcsolatos hiba

1

BO-04

Ügyfélszolgálat által használt BO funkciók rendelkezésre állása

BackOffice

Termékmanagement

Számla újra küldés sikertelen

1

BO-04

Ügyfélszolgálat által használt BO funkciók rendelkezésre állása

BackOffice

Termékmanagement

Egyéb

0

BO-04

Ügyfélszolgálat által használt BO funkciók rendelkezésre állása

Ellenőrzés

Ellenőri készülék

Ellenőri készülék hiba

0

Ell-02

Ellenőri készülékhiba

Ellenőrzés

Ellenőri készülék

Egyéb

0

Ell-02

Ellenőri készülékhiba

Ellenőrzés

Ellenőri készülék webservice

Ellenőri készülék webservice hiba

1

Ell-01

Ellenőri készülék webservice elérhetősége

Ellenőrzés

Ellenőri készülék webservice

Egyéb

0

Ell-01

Ellenőri készülék webservice elérhetősége










  1. sz. melléklet: Incidens Megoldási Kódok listája és beszámítási paramétereik

[Verzió 1.0 (2017.07.08)]



#

Megoldási kód

Leírás

Teljesítmény-mutató beszámító (igen/nem)

1

Megoldva

A hibajelenség elhárítva.

Igen

2

Javítva

A hibajelenség elhárítva eszközcserével.

Igen

3

Leállást nem okozó funkcionális hiba

A hibajelenség elhárítva, leállást nem okozott.

Nem

4

Duplikáció

A Bejelentésben leírt hibajelenség oka megegyezik egy másik nyitott Bejelentésben szereplővel, melyet korábban jelentettek be.

Nem

5

Több hiba egy jegyen

A Bejelentésben több hibajelenséget is meghatároztak.

Nem

6

Nem beazonosítható

A Bejelentésben leírt hibajelenség nem értelmezhető.

Nem

7

Felhasználói hiba

A jelenség felhasználói tevékenységre vezethető vissza.

Nem

8

Nem reprodukálható

A jelenség nem reprodukálható.

Nem

9

Harmadik fél

A hibajelenség oka egy olyan cégre, személyre vezethető vissza, melynek a tevékenységéért a TSM nem tartozik felelősséggel.

Nem

10

BKK hatáskörű tevékenység

A Bejelentésben foglalt hibajelenség a BKK tevékenységére vezethető vissza.

Nem

11

CR-ként kezelendő

A leírt jelenség nem hiba, hanem igény.

Nem

12

Nem üzemeltetési hatáskör

A jelenség kivizsgálása, elhárítása nem jelen projekt scope-ja.

Nem

13

Paraméterezés

A hibajelenség paraméterezési okokra vezethető vissza.

Nem

14

Normál működés

A jelenség a rendszer normál működésének tekinthető, nem hiba, hanem ez az elvárás.

Nem

15

Általános észrevétel

A Bejelentés nem hibajelenséget, hanem egy észrevételt tartalmaz.

Nem

16

Bankkártyás fizetés megszakadt

A hibajelenség az OTP által biztosított bankkártyás fizetési szolgáltatásra vezethető vissza.

Nem





  1. sz. melléklet: KPI-lista

KPI alapparaméterek


Kalkulátor (BI) paraméterek

KPI ID

KPI megnevezés

Bevezetési fázis

Kritikusság

(3-magas, 2-közepes, 1-alacsony)

Célérték

(elfogadható kiesés mértéke órában)

Türelmi idő a KPI-ra vonatkozó egyedi incidensek esetén

Elszámolási intervallum szélességek

(elszámolási alapegység*intervallumon belüli alapegységek száma)

Intervallumhoz tartozó levonások mértéke

FO-01

Webes alkalmazás rendelkezésre állás

1

3

99,50%

(3,60 óra)

15 perc

0,05%*25 = 0,125%

(0,90 óra)

50.000 Ft

FO-02

Regisztráció funkció elérhetősége

1

3

99,00%

(7,20 óra)

45 perc

0,002%*100 = 0,200%

(1,44 óra)

40.000 Ft

FO-03

Értékesítési funkció elérhetősége

1

3

99,50%

(3,60 óra)

45 perc

0,005%*25 = 0,125%

(0,90 óra)

10.000 Ft

FO-04

Ügyfél alapadatok módosításának elérhetősége

1

1

95,00%

(36 óra)

45 perc

0,005%*100 = 0,500%

(3,60 óra)

20.000 Ft

FO-05

Utas összekapcsolási funkció elérhetősége

1

1

93,00%

(50,4 óra)

45 perc

0,005%*100 = 0,500%

(3,60 óra)

20.000 Ft

FO-06

Ügyfél mobilapplikáció webservice elérhetősége

1

3

99,50%

(3,60 óra)

45 perc

0,005%*100 = 0,500%

(3,60 óra)

75.000 Ft

FO-07

e-mail küldési funkció működése

1

3

99,50%

(3,60 óra)

45 perc

0,005%*100 = 0,500%

(3,60 óra)

75.000 Ft









BO-01

BO rendelkezésre állás

1

3

99,50%

(3,60 óra)

15 perc

0,005%*25 = 0,125%

(0,90 óra)

30.000 Ft

BO-02

Törzsek karbantartásának elérhetősége

1

2

95,00%

(36 óra)

45 perc

0,005%*100 = 0,500%

(3,60 óra)

40.000 Ft

BO-03

Riportok lekérdezésének elérhetősége

1

1

92,00%

(cca 57,6 óra)

45 perc

0,02%*100 = 2,00%

(14,4 óra)

40.000 Ft

B0-04

Ügyfélszolgálat által használt BO funkciók rendelkezésre állása

1

3

99,50%

(3,60 óra)

45 perc

0,005%*25 = 0,125%

(0,90 óra)

10.000 Ft

BO-05

Bevételfeladás

SAP feladási funkció bekapcsolási határideje: 2017.09.30

3

A tárgyhónapra vonatkozó napi bevételfeladásoknak legkésőbb a tárgyhónapot követő 15. naptári napig meg kell érkezni a BKÜ SAP interface területre.

45 perc

késés

(naptári nap)

megkezdett naptári naponként 10.000 Ft









Ell-01

Ellenőri alkalmazás webservice rendelkezésre állás

1

3

99,50%

(3,60 óra)

15 perc

0,005%*25 = 0,125%

(0,90 óra)

50.000 Ft

Ell-02

Ellenőri készülékhiba (hw/sw)

1

1

A BKK számára cserére felhasználható pool-készlet bármely típus esetén 0-ra esik, és további cserekészülék(ek)re lenne szükség (napi limit = 3 csere/típus

45 perc

késés

(naptári nap)

Készülékenként/ megkezdett naptári naponként 8.000 Ft

(1 helyszíni pótdíj mértéke)









Üz-01

Tájékoztatás szoftver karbantartásról

Mérés megkezdése: 2017.10.01-től

3

az esetek 100%-ában legalább 48 órával a tervezett leállás előtt tájékoztatást ad a TSM

elszámolás: alkalmanként

nem értelmezhető

késés

(óra)

max 24 óra késés: 10.000 Ft / alkalom

24-48 óra késés:

50.000 Ft / alkalom

tájékoztatás elmaradása:

100.000 Ft / alkalom

Üz-02

Kérések határidőre történő teljesítése

2

3

elszámolás: alkalmanként

nem értelmezhető

késés

(naptári nap)

Felek a 2. fázis bevezetése előtt határozzák meg

Üz-03

Változáskérelmekre határidőben történő reagálás

2

3

elszámolás: alkalmanként

nem értelmezhető

késés

(naptári nap)

Felek a 2. fázis bevezetése előtt határozzák meg

Üz-04

  1. kat. Változások határidőre történő implementálása

2

1

elszámolás: alkalmanként

nem értelmezhető

késés

(naptári nap)

Felek a 2. fázis bevezetése előtt határozzák meg

Üz-05

  1. kat. Változások határidőre történő implementálása

2

2

elszámolás: alkalmanként

nem értelmezhető

késés

(naptári nap)

Felek a 2. fázis bevezetése előtt határozzák meg

Üz-06

  1. kat. Változások határidőre történő implementálása

2

3

elszámolás: alkalmanként

nem értelmezhető

késés

(naptári nap)

Felek a 2. fázis bevezetése előtt határozzák meg

Üz-07

Beszámításra nem kerülő hibajegyek megfelelő adminisztrálása

2

3

hibajegyek 99%-a 4 órán belül

100%-a 6 órán belül megoldásra kerül

nem értelmezhető


Felek a 2. fázis bevezetése előtt határozzák meg



Webfelület (FO) típusú események súlyozása Platform és Browser szerint:

Platform/Browser kombo

Szorzó:

PC/Chrome

0,35

PC/Firefox

0,10

PC/IE

0,10

PC/Edge

0,02

PC/Safari

0,05

Mobil/Chrome

0,20

Mobil/Firefox

0,04

Mobil/IE

0,02

Mobil/Egde

0,02

Mobil/Safari

0,10



A szorzókra vonatkozó paraméter beállításokat 3 havonta felül lehet vizsgálni és közös jóváhagyást követően implementálni kell a BI-rendszerben.



Az 5. sz. melléklet mellékletei



KPI-ok adattáblái

(v2017.07.08)





    1. sz. melléklet

KPI azonosító

FO-01

KPI megnevezése

Webes alkalmazás rendelkezésre állás

KPI kritikussága

3

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy az ügyfelek számára elérhető webfelület (ahol regisztrálnak, vásárolnak, és további funkciókat érnek el) milyen mértékben áll rendelkezésre.

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,005% (~ 130 sec)

Elfogadható szolgáltatási szint (célérték)

99,50%

SLA sértés esetén alkalmazott büntetés

50.000 Ft / 0,125% (0,90 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek

Amennyiben ezt a KPI-t érintő incidens van „folyamatban” státuszban, az összes, ezt követően megnyitott, ezzel az incidenssel átfedésben lévő „FO” típusú KPI-t érintő összes incidens „Duplikáció” megoldási kóddal megoldásra kerül.





    1. sz. melléklet

KPI azonosító

FO-02

KPI megnevezése

Regisztráció funkció elérhetősége

KPI kritikussága

3

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy az ügyfelek számára milyen mértékben elérhető a webfelületen található regisztrációs funkció, valamint a műszaki-, ill. folyamatleírásoknak megfelelően működik. (aktív-e a funkció, hiba nélkül lefut, stb.)

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,002% (~ 60 sec)

Elfogadható szolgáltatási szint (célérték)

99,00%

SLA sértés esetén alkalmazott büntetés

40.000 Ft / 0,200% (1,44 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek

A KPI mérését szolgáltatás átadási pontonként végezzük (böngésző/platform paraméterek figyelembevételével) A szorzók mindenkor aktuális értékét jelen dokumentum 5. sz. melléklete tartalmazza.





    1. sz. melléklet

KPI azonosító

FO-03

KPI megnevezése

Értékesítési funkció elérhetősége

KPI kritikussága

3

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy az ügyfelek számára milyen mértékben elérhető a webfelület által biztosított értékesítési funkció, valamint a műszaki-, ill. folyamatleírásoknak megfelelően működik. (aktív-e a funkció, hiba nélkül lefut-e a tranzakció, stb.)

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,005% (~ 130 sec)

Elfogadható szolgáltatási szint (célérték)

99,50%

SLA sértés esetén alkalmazott büntetés

10.000 Ft / 0,125% (0,90 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek

A KPI mérését szolgáltatás átadási pontonként végezzük (böngésző/platform paraméterek figyelembevételével) A szorzók mindenkor aktuális értékét jelen dokumentum 5. sz. melléklete tartalmazza.





    1. sz melléklet

KPI azonosító

FO-04

KPI megnevezése

Ügyfél alapadatok módosításának elérhetősége

KPI kritikussága

1

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy az ügyfelek számára milyen mértékben elérhető a webfelület által biztosított regisztrációs alapadat módosítási (pl. számlázási cím) funkció, valamint a műszaki-, ill. folyamatleírásoknak megfelelően működik. (aktív-e a funkció, hiba nélkül lefut-e a módosítási tranzakció, stb.)

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,005% (~ 130 sec)

Elfogadható szolgáltatási szint (célérték)

95,00%

SLA sértés esetén alkalmazott büntetés

20.000 Ft / 0,500% (3,6 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek

A KPI mérését szolgáltatás átadási pontonként végezzük (böngésző/platform paraméterek figyelembevételével) A szorzók mindenkor aktuális értékét jelen dokumentum 5. sz. melléklete tartalmazza.





    1. sz. melléklet

KPI azonosító

FO-05

KPI megnevezése

Utas összekapcsolási funkció elérhetősége

KPI kritikussága

1

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy az ügyfelek számára milyen mértékben elérhető a webfelület által biztosított utas összekapcsolási funkció, valamint a műszaki-, ill. folyamatleírásoknak megfelelően működik. (aktív-e a funkció, hiba nélkül lefut-e az utas összekapcsolás/kapcsolás törlése, stb.)

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,005% (~ 130 sec)

Elfogadható szolgáltatási szint (célérték)

93,00%

SLA sértés esetén alkalmazott büntetés

20.000 Ft / 0,500% (3,60 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek

A KPI mérését szolgáltatás átadási pontonként végezzük (böngésző/platform paraméterek figyelembevételével) A szorzók mindenkor aktuális értékét jelen dokumentum 5. sz. melléklete tartalmazza.





    1. sz. melléklet

KPI azonosító

FO-06

KPI megnevezése

Ügyfél mobilapplikáció webservice elérhetősége

KPI kritikussága

3

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy az ügyfelek számára milyen mértékben elérhető a mobilapplikáció (be tudnak-e jelentkezni a szerverre, tudják-e frissíteni a tokent, ezáltal tudják használni az első ajtós felszálláskor, ill. be tudják mutatni ellenőrzéskor.

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,005% (~ 130 sec)

Elfogadható szolgáltatási szint (célérték)

99,50%

SLA sértés esetén alkalmazott büntetés

75.000 Ft / 0,500% (3,60 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek






    1. sz. melléklet

KPI azonosító

FO-07

KPI megnevezése

E-mail küldési funkció elérhetősége

KPI kritikussága

3

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy az e-mail küldő szerver megfelelően működik-e vagy sem.

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,005% (~ 130 sec)

Elfogadható szolgáltatási szint (célérték)

99,50%

SLA sértés esetén alkalmazott büntetés

75.000 Ft / 0,500% (3,60 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek

A megállapodás szerint az 1. fázisban abban az esetben számolunk szolgáltatáskiesést, amikor tömeges bejelentési hullám történik és bebizonyosodik, hogy az e-mail szerver meghibásodott.





    1. sz. melléklet

KPI azonosító

BO-01

KPI megnevezése

BO rendelkezésre állás

KPI kritikussága

3

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy a Megrendelő kollégái által elérhető BO-felület milyen mértékben áll a rendelkezésre.

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,005% (~ 130 sec)

Elfogadható szolgáltatási szint (célérték)

99,50%

SLA sértés esetén alkalmazott büntetés

30.000 Ft / 0,125% (0,90 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek

Amennyiben ezt a KPI-t érintő incidens van „folyamatban” státuszban, az összes, ezt követően megnyitott, ezzel az incidenssel átfedésben lévő „BO” típusú KPI-t érintő összes incidens „Duplikáció” megoldási kóddal megoldásra kerül.





    1. sz. melléklet

KPI azonosító

BO-02

KPI megnevezése

Törzsek karbantartásának elérhetősége

KPI kritikussága

2

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy a Megrendelő kollégái számára milyen mértékben áll a rendelkezésre a Törzsek karbantartása funkció.

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,005% (~ 130 sec)

Elfogadható szolgáltatási szint (célérték)

95,00%

SLA sértés esetén alkalmazott büntetés

40.000 Ft / 0,500% (3,60 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek






    1. sz. melléklet

KPI azonosító

BO-03

KPI megnevezése

Riportok lekérdezésének elérhetősége

KPI kritikussága

1

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy a Megrendelő kollégái számára milyen mértékben áll a rendelkezésre a Riportok lekérdezése funkció.

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,020% (~ 520 sec)

Elfogadható szolgáltatási szint (célérték)

92,00%

SLA sértés esetén alkalmazott büntetés

40.000 Ft / 2,00% (14,4 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek






    1. sz. melléklet

KPI azonosító

BO-04

KPI megnevezése

Ügyfélszolgálat által használt BO funkciók rendelkezésre állása

KPI kritikussága

3

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy a Megrendelő kollégái számára milyen mértékben áll a rendelkezésre az ügyfélpanaszok kezelésére, ügyféligények kielégítésére létrehozott funkciók (pl. számla újraküldés, bérlet letiltás/újraaktiválás, stb.).

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,005% (~130 sec)

Elfogadható szolgáltatási szint (célérték)

99,50%

SLA sértés esetén alkalmazott büntetés

10.000 Ft / 0,125% (0,90 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek






    1. sz. melléklet

KPI azonosító

BO-05

KPI megnevezése

Bevételfeladás

KPI kritikussága

3

KPI érvényessége

2017.09.30 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

megkezdett naptári nap

KPI kifejtése

A mutató azt méri, hogy a Vállalkozó feladta-e az összes tárgyhónapra vonatkozó bevételi adatot a Megrendelő által meghatározott formában/minőségben a tárgyhónapot követő 15. naptári napig.

Kezdő időpont

riportolt hónap kezdőnapja

Záró Xxxxxxx

riportolt hónap utolsó napja

Képlet

késés(megkezdett naptári nap) * 10.000 Ft

Elszámolási alapegység

megkezdett naptári nap

Elfogadható szolgáltatási szint (célérték)

0 nap késés

SLA sértés esetén alkalmazott büntetés

10.000 Ft / megkezdett naptári nap

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek

A KPI-sértést és annak mértékét a BKK és BKÜ gazdasági területei által jelzett információk alapján kerülnek kivizsgálásra a Vállalkozóval közösen.





    1. sz. melléklet

KPI azonosító

Ell-01

KPI megnevezése

Ellenőri alkalmazás webservice rendelkezésre állás

KPI kritikussága

3

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

Manuális incidensjegy (1. fázisban)

KPI kifejtése

A mutató azt méri, hogy a Megrendelő kollégái számára milyen mértékben áll a rendelkezésre az ellenőrzési funkciót biztosító szerverrel való háttérkapcsolat. A Webservice hiányában a Megrendelő díjtermék ellenőrzési képessége megszűnik.

Kezdő időpont

riportolt hónap kezdőnapja 0:00:00

Záró Xxxxxxx

riportolt hónap utolsó napja 23:59:59

Képlet

vetítési alap (30 napos hónapban másodperc alapon) = (30*24*60*60) – bejelentett és sürgős karbantartások

Elszámolási alapegység

0,005% (~130 sec)

Elfogadható szolgáltatási szint (célérték)

99,50%

SLA sértés esetén alkalmazott büntetés

50.000 Ft / 0,125% (0,90 óra)

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek






    1. sz. melléklet

KPI azonosító

Ell-02

KPI megnevezése

Ellenőri készülékhiba

KPI kritikussága

1

KPI érvényessége

2017.07.08 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

megkezdett naptári nap

KPI kifejtése

A mutató azt méri, hogy a Megrendelő számára rendelkezésre áll-e cserekészülék abban az esetben, ha a BKÜ kolléga leadta azt javításra.

Kezdő időpont

riportolt hónap kezdőnapja

Záró Xxxxxxx

riportolt hónap utolsó napja

Képlet

Ell-02 = pool-készlet feletti csereigény(megkezdett naptári nap) * 8.000 Ft*készülék

Elszámolási alapegység

megkezdett naptári nap

Elfogadható szolgáltatási szint (célérték)

minden nap rendelkezésre áll megfelelő mennyiségű (igényelt) cserekészülék

SLA sértés esetén alkalmazott büntetés

8.000 Ft/nap/igény alapján hiányzó készülék

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek

A KPI-sértést jelképező hibajegyet a BKK és BKÜ ellenőrzési területén dolgozó kollégák akkor rögzítik, amikor már nem tudnak cserekészüléket biztosítani az igénylő kollégának. Amennyiben újabb teljesíthetetlen csereigény merül fel, arra újabb hibajegyet rögzítenek.

Egy nap alatt maximum 3 db hibajegyet lehet rögzíteni.

A készülék pool-okat eszköztípusonként kell kezelni.





    1. sz. melléklet

KPI azonosító

Üz-01

KPI megnevezése

Tájékoztatás szoftverkarbantartásról

KPI kritikussága

3

KPI érvényessége

2017.10.01 - visszavonásig

KPI elszámolási gyakorisága

havonta

KPI elszámolás alapbizonylata

megkezdett naptári nap

KPI kifejtése

A mutató azt méri, hogy a Vállalkozó minden esetben időben (legalább 48 órával korábban) megadta-e a szoftver karbantartásokra (leállásokra) vonatkozó tájékoztatást.

Kezdő időpont

riportolt hónap kezdőnapja

Záró Xxxxxxx

riportolt hónap utolsó napja

Képlet

Üz-01 = SZUM(„1-24óra késés”*10.000 Ft)+SZUM(„24-48 óra késés”*50.000 Ft)+SZUM(„elmaradt tájékoztatás”*100.000Ft)

Elszámolási alapegység

megkezdett óra

Elfogadható szolgáltatási szint (célérték)

minden esetben időben megteszi a tájékoztatást a Vállalkozó a Megrendelő felé

SLA sértés esetén alkalmazott büntetés

1-24 óra késés: 10,000 Ft / alkalom

25-48 óra késés: 50.000 Ft / alkalom

tájékoztatás elmaradása: 100.000 Ft / alkalom

Szerződés felmondására lehetőséget adó teljesítmény szint

szerződésben meghatározott estek szerint

KPI specifikus feltételek, paraméterek




Oldal 21 / 48


Document Metadata

Filed: July 2nd, 2017