menedzsmentben Budapesti Közgazdaságtudományi és Államigazgatási Egyetem BKÁE Gazdálkodási Kar Információrendszerek Tanszék



Hasonló dokumentumok
Az informatikai katasztrófa elhárítás menete

Információ menedzsment

Tartalom. Informatikai biztonsági stratégia

Információ menedzsment

I. Definíciók. 1. Üzletmenet folytonossági terv - katasztrófa terv. Üzletmenet folytonossági tervezés

30 MB INFORMATIKAI PROJEKTELLENŐR

Headline Verdana Bold

Adat és információvédelem Informatikai biztonság. Dr. Beinschróth József CISA

A Hivatal érvényben lévő alábbi dokumentumok létrehozása, szinkronizálása szükséges

DW 9. előadás DW tervezése, DW-projekt

GDPR- INFORMATIKAI MEGOLDÁSOK A JOGI MEGFELELÉS BIZTOSÍTÁSÁNAK ÉRDEKÉBEN

1 A SIKERES PROJEKT KOCKÁZATMENEDZ SMENT FŐ ELEMEI ÉS KULCSTÉNYEZŐI

Tisztelettel köszöntöm a RITEK Zrt. Regionális Információtechnológiai Központ bemutatóján.

Projektmenedzsment sikertényezők Információ biztonsági projektek

INFORMATIKAI SZABÁLYZAT

Vezetői információs rendszerek

A 13. Adatvédelmi rendelkezések fejezet a következőként alakult át

TOGAF elemei a gyakorlatban

Verifikáció és validáció Általános bevezető

A minőség és a kockázat alapú gondolkodás kapcsolata

SLA RÉSZLETESEN. 14. óra

A DFL SYSTEMS KFT. INFORMATIKAI BIZTONSÁGI SZABÁLYZATA

A CRD prevalidáció informatika felügyelési vonatkozásai

A Budapesti Értéktőzsde Részvénytársaság Igazgatóságának 110/2003. számú határozata

IT üzemeltetés és IT biztonság a Takarékbankban

Jogi Behajtási Keretrendszer és moduljai üzemeltetése

Az Agrármérnöki MSc szak tananyagfejlesztése TÁMOP /1/A A NÖVÉNYTERMESZTÉSI ÁGAZATOK ÖKONÓMIÁJA

Budapesti Mûszaki Fõiskola Rejtõ Sándor Könnyûipari Mérnöki Kar Médiatechnológiai Intézet Nyomdaipari Tanszék. Karbantartás-szervezés a nyomdaiparban

MINTA Kereskedelmi és Szolgáltató Kft. FELMÉRÉS EREDMÉNYE

Az informáci alapjai. Bevezetés az információbiztonság és információbiztonsági irányítási rendszer alapfogalmaiba és szükségességébe

Hidak építése a minőségügy és az egészségügy között

147. sz. Ajánlás. a rákkeltő anyagok és hatóanyagok által előidézett foglalkozási ártalmak elleni védekezésről és ezek ellenőrzéséről

Eszköz és karbantartás management

ME/76-01 A mérő és megfigyelőeszközök kezelése

vbar (Vemsoft banki BAR rendszer)

ADATVÉDELMI TÁJÉKOZTATÓ FREDERIK TECHNOLOGIES PARTNEREI RÉSZÉRE

Szociális információnyújtás a Pro-Team Nonprofit Kft.-nél

INFORMATIKA EGYRE NAGYOBB SZEREPE A KÖNYVELÉSBEN

IT Szolgáltatás Menedzsment az oktatási szektorban - 90 nap alatt költséghatékonyan

Az előadási anyagot összeállította: dr. Váró György

TopNet Magyarország Kft. INFORMATIKAI BIZTONSÁGI POLITIKÁJA

Közigazgatási informatika tantárgyból

J NEMZETGAZDASÁGI ÁG - INFORMÁCIÓ, KOMMUNIKÁCIÓ. 62 Információtechnológiai szolgáltatás Információtechnológiai szolgáltatás

A projektvezetési eszköz implementációja hazai építő-, szerelőipari vállalkozásoknál

Összefoglaló jelentés

Informatikai prevalidációs módszertan

3.1. Alapelvek. Miskolci Egyetem, Gyártástudományi Intézet, Prof. Dr. Dudás Illés

Szolgáltatási szint megállapodás

BUDGET-IT Prezentáció. NAVIGATOR Informatika Zrt.

IT biztonsági szolgáltatás csomag. ISO 9001:2000 TÜV ID: Simplexion Informatikai Kft., 1094 Budapest, Tompa utca 11, 3. emelet 24.

ASP 2.0. Tájékoztató PROJEKT Bevezetés tervezett határideje

Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Web:

Zipernowsky Károly Műszaki Szakközépiskola Informatikai Védelmi Szabályzata

Nyomtatási rendszer szolgáltatás - SLA

ITIL V3 ALAPÚ IT SZOLGÁLTATÁSIRÁNYÍRÁSI RENDSZER BEVEZETÉSE A GPITINER SEGÍTSÉGÉVEL. Sztrida Ákos IT ügyvezető igazgató helyettes ITIL Expert

Közbeszerzési rendszerek Informatikai Biztonsági Szabályzata

A katasztrófavédelem megújított rendszere

II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László

A könyvvizsgálat módszertana

Örökölt adattárháztól a CMDB-ig

Az elektronikus közszolgáltatások informatikai biztonságának jogi szabályozása

Informatikai és Biztonsági Szabályzat. I. Bevezető rendelkezések

Azonnali fizetési rendszer megvalósítása

Informatikai projektellenőr szerepe/feladatai Informatika / Az informatika térhódítása Függőség az információtól / informatikától Információs

A-NET Consulting a komplex informatikai megoldásszállító

Kiváló minôségû szolgáltatás, MKIK Védjegy. Az informatikai szolgáltatások tanúsítási követelményei

Új felállás a MAVIR diagnosztika területén. VII. Szigetelésdiagnosztikai Konferencia 2007 Siófok

Nagy méretű projektekhez kapcsolódó kockázatok felmérése és kezelése a KKV szektor szemszögéből

ADATMENTÉSSEL KAPCSOLATOS 7 LEGNAGYOBB HIBA

1. táblázat: a vezetői, stratégiai és menedzsment szinten végbemenő folyamatok Vezetés Stratégia Menedzsment

A Bankok Bázel II megfelelésének informatikai validációja

Kossa György elnök-vezérigazgató címzetes egyetemi docens Az OKF Iparbiztonsági Tanácsadó Testület Elnöke

Karbantartási filozófiák. a karbantartás szervezetére és a folyamat teljes végrehajtására vonatkozó alapelvek rendszere.

TESZTMENEDZSMENT TESZTELŐ SZERVEZET TESZTTERVEZÉS ÉS BECSLÉS

Szolgáltatás mérés/riportolás magas fokon Egy valós megoldás Pepsi berkekben

A SZERVEZT SZERVEZETI IDENTITÁS. SZERVEZETI PROFIL. SZERVEZETI STRATÉGIA

Módszerek és példák a kockázatszemléletű gyakorlatra az ISO 9001:2015 szabvány szellemében

IT szolgáltatás menedzsment bevezetés az IIER projektben

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet

Tárgyszavak: vevőkapcsolatok; CRM; szoftverértékelés.

ITIL alapú folyamat optimalizációs tapasztalatok

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

Miskolci Egyetem Általános Informatikai Tanszék

A tesztelés feladata. Verifikáció

Versenyképesség és az innovatív vagyonvédelem

Indikátorok projekt modellhelyszínein. Domokos Tamás szeptember 13.

77/ Követelmények és a gyakorlat. Dr. Krasznay Csaba egyetemi adjunktus NKE KTK EFI IBT

S atisztika 2. előadás

A települések katasztrófavédelmi besorolásának szabályai, védelmi követelmények.

Történet John Little (1970) (Management Science cikk)

1.1. HOGYAN HASZNÁLJUK AZ ÖNÉRTÉKELÉSI ESZKÖZT. Az eszköz három fő folyamatot ölel fel három szakaszban:

A karbantartásra vonatkozó általános feltételek a TvMI-ben

Információbiztonság fejlesztése önértékeléssel

TPM egy kicsit másképp Szollár Lajos, TPM Koordinátor

Hogyan tudom soros eszközeimet pillanatok alatt hálózatba kötni?

A TESZTELÉS ALAPJAI A TESZTELÉS ALAPVETŐ FOLYAMATA A TESZTELÉS PSZICHOLÓGIÁJA A TESZTELÉS ETIKAI KÓDEXE

AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP B) Kern Zoltán Közoktatási szakértő

A kockázatkezelés az államháztartási belső kontrollrendszer vonatkozásában

Az ALTERA VAGYONKEZELŐ Nyrt. kockázatkezelési irányelvei

Programrendszerek tanúsítása szoftverminőség mérése

Átírás:

Budapesti Közgazdaságtudományi és Államigazgatási Egyetem Gazdálkodástudományi Kar Információrendszerek Tanszék Helpdesk és katasztrófamenedzsment az IT infrastruktúra menedzsmentben Készítette: (2003) Készítés éve: 2003 Főszakirány: Információgazdálkodás Szakcsoport: e-learning Szakszeminárium vezető: Dr. Gábor András VII. / 1.

VII. / 2.

I. Tartalomjegyzék I. Tartalomjegyzék 3 II. Bevezető 5 III. A helpdesk 8 III.1 A helpdesk lényege 9 III.2 A helpdesk fajtái 10 III.2.a Az egyszerű, központosított helpdesk 11 III.2.b Többfunkciós, központosított helpdesk 12 III.2.c Elosztott gyorssegély-szolgálat 12 III.2.d A helpdesk rendszerek erőforrás igény szerinti tipizálása 13 III.3 A gyorssegély-szolgálat személyzeti kérdései 14 III.3.a A gyakorlatlan munkaerő 14 III.3.b Tapasztalt szakemberek 15 III.3.c Szakértők alkalmazása 15 III.4 Helpdesk rendszerek tervezése és bevezetése 15 III.4.a A helpdesk bevezetésének előkészítése (A cél és a küldetés meghatározása) 17 III.4.b A gyorssegély-szolgálati rendszer tervezése 17 III.4.c A helpdesk bevezetése 19 III.4.d A tudásbázis felépítése 21 III.4.e Felmerülő lehetséges problémák 22 III.5 A gyorssegély-szolgálati rendszer bevezetésének hasznai illetve költségvonzatai. 22 III.5.A A helpdesk költségei 22 III.5.b A helpdesk haszna 24 VII. / 3.

III.6 Esettanulmány 25 III.6.a Egy hazai bank gyorssegély-szolgálata 25 III.6.b Egy helpdesk hívás a gyakorlatban 28 IV. Katasztrófa-menedzsment 31 IV.1 A katasztrófák megelőzése 32 IV.1.a Az infrastrukturális védelem 35 IV.1.b A hardvervédelem a következő lépésekből áll: 36 IV.1.c Szoftvervédelem, Adathordozók védelme 37 IV.2 A katasztrófa elhárítás tervezése 37 IV.2.a Katasztrófa elhárítási vázlatok 38 IV.2.b A katasztrófa elhárítási terv tartalma 41 IV.2.c A terv implementálása, szükséghelyzet utáni helyreállítás 43 IV.3 Esettanulmány 44 V. Irodalomjegyzék 48 VI. Ábrajegyzék 50 VII. / 4.

II. Bevezető A XXI. század üzleti vállalkozásainál már elengedhetetlen a modern számítógépes infrastruktúra megléte. Ebben a környezetben meghatározó jelentőségű az eredményes menedzsment az informatikai szolgáltatások területén is. e-learning tananyagunk a számítógépes infrastruktúra menedzsmentből a helpdesk, vagy más néven a gyorssegély-szolgálat és a katasztrófa-menedzsment témakörét emeli ki. Az IT infrastruktúra menedzsment területeit a következő ábra szemlélteti. 1. ábra:az IT infrastruktúra menedzsment területei VII. / 5.

e-learning tananyagunkban bővebben a helpdesk és a katasztrófa menedzsment témakörét dolgoztuk ki, jó gyakorlati alkalmazhatósága, és kézzelfoghatósága miatt. A SZÁMALK segítségével készített tananyag bárki számára könnyen használható, átfogja az említett két témakört. Az informatikában kezdetben a számítástechnikai központok szinte elszigetelten működtek, ami a felhasználókkal való kapcsolattartás hiánya miatt kevésbé hatékony működést okozott. E miatt az IT problémák megoldása nem azonnal történt, az egyes funkciók elszigetelődése miatt a felhasználói igények az egyes alkalmazásokra vonatkozóan nem teljesültek. Az IT infrastruktúra menedzsment ezeket az IT szolgáltatások terén kialakult hiányosságokat pótolja. A helpdesk a problémák megoldását, a katasztrófa-menedzsment a nem várt eseményekre való felkészülést, megelőzést segíti. Az informatikai szolgáltatások menedzsmentjének bevezetése megteremti a lehetőséget a vállalkozás számára, hogy az informatikai részleg költség-hatékony, a szervezet alaptevékenységét megalapozó részleg legyen. Az infrastruktúra menedzsment egyes funkcióinak bevezetése időigényes, az alábbi számok hozzávetőlegesen a tervezéstől a bevezetésig terjedő időtartamot jelölik. 1 Gyorssegély-szolgálat 3 és 6 hónap között (kifinomult, alapos szolgáltatás) Változáskezelés 1 és 3 hónap között, beleértve a támogató eszközök beszerzését Konfigurációkezelés 4 és 12 hónap között, az ötlettől a megvalósításig Problémakezelés 2 és 4 hónap között Szoftverfelügyelet terítés és Hetek feltéve, hogy a konfigurációkezelés funkció már működik 1 Forrás: Az ITB ajánlásai VII. / 6.

1. táblázat: Egyes funkciók bevezetésének időigénye Valamennyi funkció bevezetése projektként kezelendő és valósítandó meg. A tényleges üzembe helyezés rendszerint a támogató szoftver eszköz bevezetéséhez kapcsolódik. A szükséges szoftver eszközök beszerzése után az esetleges testreszabás következhet, a funkció hátterét biztosító rendszerek és a hozzájuk kapcsolódó eljárások kialakítását követően a dokumentáció létrehozása és a rendszer tesztelése kerül sorra. Ennek sikere esetén a megvalósítási terv szemléje, majd a személyzet kiképzése lehet a következő lépés. Ezután elfogadási tesztelést kell végrehajtani, végül az éles üzemelés következik. Valamennyi funkció esetében a bevezetésnek specifikus jellemzői vannak. VII. / 7.

III. A helpdesk A gyorssegély-szolgálat fő funkciója a bekövetkezett IT eszközökkel kapcsolatos hibák orvoslása, naplózása. A hibaelhárítási folyamatot a 2-es számú ábra mutatja. A hiba útja a keletkezéstől a megoldásig a következő: 2. ábra: A hiba útja a Helpdeskig A hiba jelentkezik a végfelhasználónál. A felhasználók először nem a helpdeskkel lépnek kapcsolatba, hanem általában egyik kollégájukkal (Őt nevezik kulcsfelhasználónak), aki tőlük nagyobb tapasztalattal rendelkezik az adott szoftver, vagy a számítástechnika terén. Ha ő nem tud segíteni, akkor hívják a helpdesket. Mivel a felhasználó nem informatikus, nem várható el tőle, hogy elhárítsa, vagy akár pontosan behatárolja annak okát. Tőle csak az várható el, hogy az előzetes ismeretei alapján újra átgondolja, hogy helyesen járt-e el. Amennyiben a hibajelenség továbbra sem szűnik meg, akkor azt jelentenie kell, lehetőleg minél érthetőbben és részletesebben, hogy minél pontosabban rögzíthessék azt a helpdesk rendszerben. A hibabejelentés történhet telefon, Internet, vagy Intranet útján. VII. / 8.

A bejelentett hiba alapján a helpdesk rendszer kezelője elsőszintű hibaelhárítást végez, ami azt jelenti, hogy a számítástechnikai munkatárs a saját tudására, vagy a helpdesk szoftver tudásbázisára támaszkodva azonnali hibaelhárítást kísérel meg, ha ez lehetséges. Ha ez nem valósul meg, akkor továbbadja a problémát egy szakértői csoportnak. Ez a másod szintű hibaelhárítás. Mindkét folyamat végeztével az esetet dokumentálják, hogy a jövőben előforduló hasonló hibák megoldása mielőbb megtörténjen, és utat mutasson az esetleges jövőbeni fejlesztésekhez. III.1 A helpdesk lényege A gyorssegély-szolgálat a szervezeten belüli IT szolgáltatások széleskörben és egyre inkább elterjedt eleme, amely a szervezet méretének növekedésével egyre fontosabbá válik. A kötegelt feldolgozású rendszerek idejében csak viszonylag egyszerű problémák jelentkeztek, mint például az egyes erőforrások megosztásának problémái, vagy nyomtatási sorral, listákkal kapcsolatos problémák. A gyorssegély-szolgálat hagyományosan úgy definiálhatnánk, hogy ez tulajdonképp egyfajta panaszkönyvi mechanizmus, ahol egy szolgáltatás élvezői, fogyasztói megjegyzéseket tehetnek, illetve kifogással élhetnek a számukra biztosított termékekkel, szolgáltatásokkal, eljárásokkal, szállításokkal stb. kapcsolatban. 2 A gyorssegély-szolgálat feladatai közé tartozik az esemény probléma és hibafelügyelet. Azért létezik, hogy segítséget nyújtson a szervezet munkatársainak (felhasználóinak), ha valamely informatikai szolgáltatás használata közben bármilyen rendellenesség vagy üzemzavar lép fel. A 3-as számú ábra mutatja azon területeket, melyekre a gyorssegély-szolgálat hatást gyakorol. 2 Informatikai Tárcaközi Bizottság ajánlásai VII. / 9.

3. ábra: A helpdesk kapcsolatrendszere 3 Az első dolog, amit egy helpdesk operátor megnéz, az a felhasználó által adott hibaleírás. Utána összegyűjti a hiba elhárításához szükséges információkat, majd megpróbálja azt megoldani. A hibaelhárítás menetét befolyásolja a vállalatnál kiépített helpdesk rendszer felépítése. III.2 A helpdesk fajtái A gyorssegély-szolgálatnak alapvetően három típusát különböztetjük meg: Egyszerű, központosított Többfunkciós, központosított Illetve elosztott. 3 Forrás: Klimkó-Szabó: IT infrastruktúra menedzsment VII. / 10.

III.2.a Az egyszerű, központosított helpdesk Ezen helpdesk típust általában akkor célszerű választani, ha a cég egy központi számítógép-központtal rendelkezik. Nagy előnye, hogy közel van a felügyelő személyzethez, a szakértelem jól megosztható, kisebb létszám is elegendő, viszont minden egyes kérést egyetlen mindennel foglalkozó munkahelyre továbbítanak. Nem célszerű ezen típus bevezetése, ha a gyorssegélyszolgálathoz naponta számos kérés érkezik, mert ekkor ez a szervezeti felépítés rontja hatékonyságát. Az egyszerű, központosított helpdesk felépítését a 4-es számú ábra láthatjuk. 4. ábra: Egyszerű, központosított helpdesk 4 4 Klimkó-Szabó: Infrastruktúra menedzsment VII. / 11.

III.2.b Többfunkciós, központosított helpdesk A többfunkciós helpdesket a specializáció jellemzi, ha az alaptevékenységre időszakonként számos kérés érkezik, akkor ennek bevezetése célszerűbb, mint az egyszerű gyorssegély-szolgálaté. Jellemzője, hogy kapcsolat van az IT és a szervezeti alaptevékenységet segítő helpdesk központ között. A többfunkciós központosított gyorssegély-szolgálatot az 5-ös számú ábra mutatja. 5. ábra: Többfunkciós, központosított helpdesk 5 III.2.c Elosztott gyorssegély-szolgálat Ez a módszer hálózatos, többfelhasználós rendszert feltételez, egységes analógiák alapján működnek, az előzőektől gyorsabb és közvetlenebb reagálást tesz lehetővé, ugyanakkor méreténél fogva nehezebb koordinálni. Megvalósítása nagyobb méretű vállalkozásoknál javasolható, mert itt lehet jól kihasználni azon előnyét, hogy fiókonként (telephelyenként) is elérhető. Felépítését a 6-os számú ábrán láthatjuk. 5 Forrás: Klimkó-Szabó: Infrastruktúra menedzsment VII. / 12.

6. ábra: Elosztott helpdesk III.2.d A helpdesk rendszerek erőforrás igény szerinti tipizálása A szervezet méretétől és igényeitől függően bevezethet egyszerű, közepes, és nagyméretű helpdesk üzemeltetést Az egyszerű gyorssegély-szolgálat (helpdesk pult) még a kisebb vállalkozások számára sem javasolható, mert a tevékenysége csupán az események rögzítésére korlátozódik. VII. / 13.

A közepes méretű üzemeltetés a legtöbb cég számára megfelelő lehet, ugyanis ez már képes az események naplózására, koordinálja az IT tevékenységet, többfelhasználós hozzáférést biztosít az informatikai rendszerekhez. A nagyméretű gyorssegély-szolgálat bevezetése azon vállalkozásoknak ajánlott, melyek több távoli telephellyel rendelkeznek, jellemzője, hogy egyetlen központi részlege van. III.3 A gyorssegély-szolgálat személyzeti kérdései A gyorssegély-szolgálat várható kihasználtságának becslésével, tekintettel a napi várható kérések számára a tervezésnél meg kell állapítanunk a kívánt létszámot, és el kell döntenünk, hogy milyen minőségű szakembergárda üzemeltesse a helpdesket. Az üzemeltető személyzetet képzettségük alapján két csoportra bonthatjuk: Tapasztalt műszakiak Minőségi, de nem műszaki személyzet (Ők csak az egyszerűbb feladatokat kezelik, a többi továbbadják a műszakiaknak.) Tapasztalati szintjük alapján a helpdesk személyzetét három osztályba sorolhatjuk: Gyakorlatlan Tapasztalt Szakértő III.3.a A gyakorlatlan munkaerő A gyakorlatlan személyzetre építő gyorssegély-szolgálat előnye, hogy azonnal, és gyorsan képes reagálni a hívásokra, és az egyszerűbb problémákat VII. / 14.

megoldja, viszont a bonyolultabb eseteket továbbadják egy szakértői csoportnak. Az első szintű hibaelhárítás folyamatát kifogástalanul el tudják látni. III.3.b Tapasztalt szakemberek A tapasztalt embereket foglalkoztató helpdesk esetén a hívásokat továbbítják az adott szakterület specialistájához (tapasztalt szakértőjéhez), így a problémák jelentős részét azonnal kezelni tudják. Probléma lehet, hogy ha a szervezeten belül csupán egy ember foglalkozik az adott témával, akkor ez arroganciát szülhet. Ők végzik a másodszintű hibaelhárítást. III.3.c Szakértők alkalmazása Szakértői személyzet alkalmazása esetén a vállalkozás a tudás minőségére épít, a szakemberek a felmerülő problémákat, azok tovagyűrűzése nélkül próbálják megoldani, minden hívást külön-külön elemeznek, és kiértékelnek. Az ilyen szakértői személyzet toborzása nagy körültekintést és persze pénzt igényel. III.4 Helpdesk rendszerek tervezése és bevezetése A gazdálkodó szervezetek IT részlegei túlságosan különböznek ahhoz, hogy egy univerzális megoldás tudjunk adni a gyorssegély-szolgálati rendszerek bevezetéséhez, és üzemeltetéséhez. Mindenek előtt válasszuk ketté a bevezetés folyamatát: 1. Már van a részlegben működő IT szolgáltatás 2. Még nincs semmilyen IT szolgáltatás a részlegben (új részleget hoz létre a szervezet) Az első esetben feltehetőleg azért kerül sor a gyorssegély-szolgálat bevezetésére, mert erre kifejezett igény merül fel, az informatikai szolgáltatások javulását várják a bevezetéstől. Nehezebb a feladat azért, mert már egy meglévő rendszerhez és a megszokott eljárásokhoz kell alkalmazkodni. VII. / 15.

A második eset tulajdonképp egy zöldmezős beruházás, ez esetben a hasonló méretű és tevékenységű részlegeken alapuló becslésekre kell építenünk a bevezetés folyamatát, azaz tervezett adatokat kell alapul vennünk tényadatok helyett. Bármely eset is áll fenn figyelembe kell venni, a tevékenységek és várható események méretét, és a helpdesk a szervezeti alaptevékenységet segítő lehetőségét, amely nem csupán az informatikához kapcsolódó kérésekkel, (klasszikus értelemben vett helpdesk) hanem a szolgáltatás használatához ad átfogó, általános segítséget. Pl. Egy készletnyilvántartó rendszer esetében iránymutatást ad az adott készlet besorolását illetően. Ha meghatároztuk a bevezetendő rendszer alapparamétereit, akkor elkezdhetjük a tervezést. Rendszerfejlesztés Használat Vezetői feladatok A cél meghatározása Küldetés meghatározása Eszközök megválasztása A folyamatok ellenőrzése Szervezeti feladatok A projekt-team kiválasztása és képzése A felhasználók képzése Események rögzítése Technikai folyamatok IT rendszerekhez kapcsolódó Tudásbázishoz Implementáció Integráció Ellenőrzés Kezdeti tudásbázis Karbantartás A tudásbázis folyamatos kapcsolódó felépítése bővítése 2. Táblázat: A helpdesk tervezése és használata során fellépő feladatok 6 6 S. David J. Botkin: Experience management for self-service and helpdesk support VII. / 16.

A következő alfejezetekben a táblázat egyes részeit fogjuk megvizsgálni alaposabban. A III.4.a fejezet a cél és a küldetés meghatározása; a III.4.b az eszközök meghatározása; a III.4.c az implementáció, integráció, és ellenőrzés; a III.4.d fejezet pedig a tudásbázis felépítésének témakörével foglalkozik. III.4.a A helpdesk bevezetésének előkészítése (A cél és a küldetés meghatározása) Vezetői feladatok: A gyorssegély-szolgálat bevezetésék sikeréhez először a célokat kell meghatároznunk, ez utat mutat a menedzsmentnek a bevezetés sikerének értékeléséhez. A célok kommunikálása a gyorssegély-szolgálat bevezetését végző projektteam felé a menedzsment elengedhetetlenül fontos feladata. A bevezetési folyamat sikerének vannak kvantitatív (erős) és kvalitatív (gyenge) kritériumai. A kvantitatív kritériumok magukba foglalják egy probléma megoldásnak átlagos kötéségét, a probléma megoldási idő, és a személyzet kérdését. A kvalitatív kritériumok szubjektív szempontokon alapulnak, úgymint a felhasználók vagy a helpdesk operátorok megelégedettsége. A vállalati kultúrában, a munkavállaló a vállalkozással, és a többi munkavállalóval szembeni (negatív) hatalmának forrása a szaktudás, melynek továbbadásától sokan, még a helpdesk operátorok közül is vonakodnak. A helpdesk szolgáltatás bővítése, bevezetése során ezt az akadályt, úgy lehet legyőzni, hogy bevonjuk őket a fejlesztésbe, figyelembe vesszük igényeiket, kéréseiket. Ezáltal sajátjuknak is érezhetik a projektet. Ilyen formán a befektetett tudás számukra megtérül. III.4.b A gyorssegély-szolgálati rendszer tervezése 7 Az eszközök megválasztása már a konkrét tervezési szakasz része. Figyelembe kell venni a meglévő hardver, szoftver, hálózati kiépítettség, és még sok más 7 e-learning tananyag a Helpdesk és katasztrófa-menedzsmet témakörében (Számalk 2003) VII. / 17.

egyéb fontos tényezőt. A legfontosabb feladat ebben a szakaszban, hogy figyelembe vegyük mind a felhasználók, mind pedig a helpdesk operátorok képzettségi szintjét. A projektteam képzése után az implementáció következik. Implementációs tervet kell készíteni, amely részletes fázisokra bontja a megvalósítást. Ezután meg kell tervezni a főbb elemeket és az alkalmazandó rendszert is. Teszt-tervet is kell készíteni a rendszerhez, amely annak teljesítményét és funkcionalitását ellenőrzi (válaszidő, eszkaláció, jelentések, rendszeradminisztráció, interfészek a többi funkcióval, katasztrófa-terv). Szükség lehet egy kész termék testreszabására, ami magába foglalhatja képernyőtervek és jelentés formátumok tervezését. A gyorssegély-szolgálat interakciós helyein (ahol fogadják a felhasználók kéréseit) szükséges a szoftverhez való hozzáférés lehetősége, illetve a futtatást lehetővé tevő berendezés. Meg kell határozni az eseménykezelés módjait (ez lehet közvetlen - pl. telefon, intranet - és kontrollált - visszahívásos jellegű, pl. fax, e-mail). Definiálni kell a lehetséges eseményekhez tartozó súlyossági szinteket, és az ezeknek megfelelő válaszidőket. Eszkalációs eljárást kell tervezni, ehhez az eszkalációs küszöböket (kritériumokat) világosan meg kell határozni: Kódolási rendszer (a hibákra vonatkozó strukturált kód szerint) Súlyossági/következmény kódok (kód a hozzátartozó leírással és a helyreállítási szintidővel) Meghibásodás osztályozása Híváskezelési eljárások (eleinte papír-alapú leírások, folyamat-diagramok alkalmazhatók, ideális esetben számítógép alapú forgatókönyvek segítik a folyamatot). VII. / 18.

Ezek a kapcsolódó rendszerelemek olyan tervezést igényelnek, amit az adott környezethez kell igazítani. Ki kell alakítani a gyorssegély-szolgálati eljárásokat katasztrófa-szituáció eseteire is (hálózat, telefon kiesése, adatvesztés, elektromos ellátás hiánya, stb.). III.4.c A helpdesk bevezetése A tervezési szakasz lezárultával hozzáláthat a vállalkozás a gyorssegélyszolgálat bevezetéséhez. A működő környezet megteremtése feszesebb ellenőrzést (projekt menedzsmentet) igényel, mint a tervezési fázis, minthogy több ember vesz benne részt és a függőségek nyilvánvalóbbakká válnak. Jóval nagyobb hangsúlyt kell helyezni a projektirányítási (menedzsment) szempontokra, annak érdekében, hogy sikeresen valósítsuk meg a kitűzött követelményeket. Ebben a szakaszban a következő tevékenységekre van szükség: a szükséges berendezéseket be kell szerezni, és üzembe kell állítani, a kész szoftver eszközöket testre kell szabni, a rendszereket tesztelni kell, fel kell állítani a berendezések/szoftverek leltárát, el kell készíteni a dokumentációkat, ki kell képezni a személyzetet, végre kell hajtani az átvételi tesztelést. A berendezések beszerzése és üzembeállítása VII. / 19.

Az időigényes engedélyeztetési eljárásokat (ha szükségesek) a lehető legkorábban meg kell kezdeni. A szoftver csomagokat és a további szükséges berendezéseket meg kell rendelni. A szállítókat értesíteni kell a szállítás időpontjairól és helyszíneiről, ahogy az a megvalósítási tervben szerepel. Minden kapcsolódó hálózati, vagy építészeti munkával az üzembe helyezési tervek szerint egyeztetni kell. Az összes berendezésnek át kell esnie egy alapos üzembe helyezési teszten, ha az szükséges, szállítói segítség igénybevételével. A készen kapható eszközök testreszabása Meg kell győződnünk arról, hogy a beszerzett szoftver eszközökön elvégzett összes módosítás megfelel az utolsó (elfogadott) specifikációnak. Ha a tervezési szakaszok során nem volt lehetséges a testre szabás elvégzése, akkor éljünk a szoftver által nyújtott módosítási/finomítási lehetőségekkel. (Itt szoktak először előjönni azon típus problémák, hogy a szoftver vásárlója/megrendelője nem azokat a megkívánt funkciókat kapta amire tulajdonképpen szüksége lenne.) Ha kisegítő egyedi rutinokra, mint pl. adatbázis betöltésre/konverzióra, meglevő rendszerek változtatására és ad hoc elemző lehetőségekre lenne szükség, akkor ezeket ebben a szakaszban, minél hamarabb ki kell fejleszteni. A rendszerek tesztelése Minden egyes rendszert alaposan, mélyrehatóan tesztelni kell a tesztelési terv előírásai szerint, a testre szabás és a kapcsolódó célirányos fejlesztések befejezése után. Figyelmet kell fordítani az esemény-felügyelő rendszerre. A rendszer funkcionalitásának sikeres tesztelése után a rendszer teljesítőképességét kell vizsgálat alá vetni. Ez maga után vonhatja nagyobb létszámú személyzet foglalkoztatását és az összes kapcsolódó berendezés üzembe helyezését. A berendezések és szoftverek nyilvántartásának felállítása VII. / 20.

A konfigurációkezelés nyilvántartása lényegi és szükséges része az eseménykövető rendszernek. Ha nem létezne ilyen nyilvántartás, a lehető leggyorsabban létre kell hozni. A nyilvántartás felállítása jelentős adminisztratív munkával jár, és késleltetheti a gyorssegély-szolgálat indítását. A dokumentációk elkészítése A tervezési szakasz dokumentumai alapján be kell fejezni az összes előírt dokumentációt. Ezek közé kell, hogy tartozzon a gyorssegély-szolgálat, a számítógép üzemeltetés, a hálózati üzemeltetés, a problémakezelés és más kisegítő csoportok és felhasználó személyzet eljárásai. Ahol az lehetséges, az előző területeken érintett személyzet járuljon hozzá a dokumentációk elkészítéséhez, és adjon az anyag elkészítéséhez technikai segítséget. A személyzet kiképzése Ez valószínűleg a megvalósítási terv legkritikusabb része, így kitüntetett figyelemben kell részesíteni. A képzésnek folyamatos tevékenységnek kell lennie a tervezés, megvalósítás és testre szabás során, ugyanakkor szükséges egy képzési program is, azért, hogy biztosítsuk a személyzet teljes körű felkészültségét az éles üzembeállítás idejére. III.4.d A tudásbázis felépítése Egy olyan gyakorlatorientált rendszer, mint a gyorssegély-szolgálat teljesen hasztalan hasonló környezetben történt esetek, problémák leírása nélkül. A tudásbázis létrehozásának három fő célja van: A helpdesk operátorok képzése A folyamatok megismerése A rendszer elindítása VII. / 21.

A gyakorlatban a kezdeti tudásbázis felépítésében a tervezést, és a bevezetést végző projektteam nagy szerephez jut, segítségükkel feltölthető és elindítható alapesetekkel a helpdesk tudásbázisa. Meg kell alkotni azokat a szükséges formanyomtatványokat, bejelentő lapokat, melyek segítségével a tudásbázis folyamatosan bővíthető. III.4.e Felmerülő lehetséges problémák A helpdesk funkció bevezetése, tervezése, és üzemeltetése során számos probléma merülhet fel. Ha a szolgáltatást újonnan vezették be a vállalatnál, akkor előfordulhat, hogy a felhasználók esetleg kikerülik a szolgálatot, és egyenesen az informatikai személyzetnek jelentik a meghibásodást különösen, ha a bevezetés előtt ez volt a megszokott rendszer. (Pl. Esettanulmány) Ebben az esetben, az informatikai személyzettől meg kell követelni a probléma továbbítását. Megeshet, hogy a funkció bevezetése során oly mértékű többletköltségek jelentkeznek, hogy az megakadályozza a teljese megvalósítást, az ilyen sikertelen bevezetésnél a további kísérletekhez már sokkal nehezebb lesz a felhasználók megnyerése. A gyorssegély-szolgálat, mint kizárólagos kapcsolattartási pont, szűk keresztmetszetnek bizonyulhat, ha nagy számban lépnek fel események, vagy ha egy esemény bekövetkeztekor nagyszámú felhasználó érintett. Ezt a csúcsterhelés megfelelő felmérésével, illetve egy alkalmas helyi megbízott kinevezésével kerülhetjük el. III.5 A gyorssegély-szolgálati rendszer bevezetésének hasznai illetve költségvonzatai. III.5.a A helpdesk költségei 1. "Időköltség": Az informatika területén a hibaelhárítás hagyományosan személyes kapcsolatokon keresztül valósul meg. Harmadik személy bevonása jelentősen megnövelheti a problémamegoldás időszükségletét. VII. / 22.

2. Standard megoldás hiánya: A szervezetek különbözőek, ezért nem lehet egy olyan standard megoldást kidolgozni, ami minden egyes szervezet esetében megfelelő hatékonyságot, illetve eredményességet biztosítana. Ennek következtében minden egyes szervezet esetében, a bevezetés előtt, előzetes, az adott szervezetre vonatkozó felmérésre van szükség, ami többletköltségeket eredményezhet. Ez az elemzés azonban nem spórolható meg, illetve nem lehet félvállról venni, mert annak nem megfelelő súlyú kezelése olyan rendszer bevezetését eredményezheti, ami a szervezet profiljának nem megfelelő, ezáltal nem segíti annak működését sem. Érdemes tehát pénzt és időt áldozni rá. 3. A munka végzéséhez szükséges erőforrások költségei: Ahhoz, hogy a segélyszolgálat betöltse rendeltetését megfelelő emberekre, felszerelésekre (szoftver, hardver stb.) van szükség, aminek beszerzése (esetleg saját fejlesztése) többletberuházással jár. Ezek egy hatékony rendszer esetében hamar megtérülnek. Alkalmazottak fizetése: 250-500 ezer forintig, A feladatok elvégzéséhez szükséges hardware biztosítása: egy PC 500-600 ezer forint 4. Ha szükséges egyedi fejlesztés: Előfordulhat, hogy a megfelelő szoftver nem áll rendelkezésre, és egyedi fejlesztésre van szükség. Ez olyan méretű többletráfordítást eredményezhet, ami gondos és alapos előzetes kutatómunkát, illetve kalkulációkat igényel. 5. Megfelelő infrastruktúra kialakítása: Ebbe a kategóriába a felhasználok felé irányuló kommunikációs csatornák kialakítása tartozik. Ezeken a csatornákon keresztül lehet a megfelelő információkat eljuttatni az illetékes felhasználókhoz. Az infrastruktúra kialakítása: 100 milliós nagyságrendű, (ebben benne van az intranet kifejlesztése is), VII. / 23.

6. A túlterheltség problémájának kezelése Ha a rendszer túlterheltté válik az mindenképpen a segélyszolgálat munkájának hatékonyság-csökkenését eredményezi. 7. Ellenérzések a helpdeskkel kapcsolatban A szervezeten belül jelentkezhet rendszerrel szembeni ellenérzés. Ebben az esetben előfordulhat, hogy nem megfelelően használják, vagy nem minden esetben (amikor egyébként indokolt lenne) veszik igénybe a szolgáltatást a szervezet dolgozói. 8. Ha a bevezetés sikertelen: A funkció bevezetésének sikertelensége a felhasználók körében hiteltelenséghez vezethet. A második (és a sokadik) kísérlethez már sokkal nehezebb lesz a felhasználók elkötelezettségét megszerezni! Ennek következtében az első bevezetésnél nagy körültekintéssel kell eljárni. III.5.b A helpdesk haszna 1. Kommunikáció: A helpdesk elősegíti a hatékony kommunikációt a felhasználók és az informatikai részlegek között. 2. "Központi gyűjtőhely": A rendszerrel kapcsolatos hibáknak, hiányosságoknak a gyűjtőhelye. A tipikus hibák kiszűrhetővé válnak és ezáltal javítható a rendszer működésének hatékonysága. 3. Visszacsatolási pont: Az informatikai szolgáltatásokkal kapcsolatos vélemények összegyűjtése is itt történik. 4. Gyorsaság: Fontos a felhasználók problémáinak azonnali kezelése. Az előzetesen történő forgatókönyvek kialakítása szintén a gyorsaságot segíti elő. VII. / 24.

5. Minőség: A problémamegoldó szolgáltatás színvonalának javulása. 6. Tájékoztatás: A felhasználó folyamatos tájékoztatása az események bekövetkezéséről. 7. Együttműködés: Együttműködés más informatikai szolgáltatókkal a vezetők számára összeállított jelentések készítésében. III.6 Esettanulmány III.6.a Egy hazai bank gyorssegély-szolgálata Egy hazai lakossági és vállalati szolgáltatásokat nyújtó országos hálózattal rendelkező bank helpdesk rendszere nagyvonalakban következő jellemzőket követte: 1. Mivel számos fiókkal rendelkeztek, ezért központosított helpdesk mellett döntöttek. 2. Az egyes számítógépes alkalmazások minden fiókban azonosak voltak. 3. Fiókonként működött egy kisebb-nagyobb helyi IT részleg, aminek feladata a problémák azonnali orvoslása (első szintű hibaelhárítás) volt. 4. A felhasználó döntötte el, hogy probléma felmerülése esetén felhívja e a gyorssegély-szolgálatot vagy a helyi kollégákhoz fordul tanácsért. 5. A kisebb problémák orvoslása általában azonnal megtörtént, viszont tovagyűrűző rendszerhibák esetén a megoldás váratott magára. Összefoglalva, a szervezetnél, egy többfunkciós, központosított gyorssegélyszolgálat működött. VII. / 25.

7. ábra: A bank helpdesk rendszere A bank helpdesk rendszere a gyakorlati tapasztalatok szerint nem működött túl jól, ennek oka az volt, hogy a felhasználók kezdetben bizalmatlanok voltak a helpdesk személyzetével szemben. A gyorssegély-szolgálat személyzete gyakorlatlan volt a problémák kezelése tekintetében. A központi helpdesknél gyakorlott, nagy tapasztalatokkal rendelkező személyzetet kellett volna alkalmazni, ugyanis a felhasználók a tapasztalatok szerint csak akkor hívták őket, ha nagyobb probléma merült fel, amit helyben nem tudtak orvosolni. Ezért lett volna szükség itt a nagyobb szakértelemre. A másik oldalról, ha a központi helpdeskünk gyakorlatlan szakembereket alkalmaz, akkor ez esetben felesleges helyi problémaelhárító IT részlegeket is üzemeltetni, mert ez közel hasonló feladatokat lát el. A nagyobb rendszerhibákat vagy nem, vagy pedig csak elkésve tudták kezelni, ezért nem működött megfelelően a bank gyorssegély-szolgálata. VII. / 26.

A bank később felderítette a hiba okát, végső soron lecserélték teljes IT rendszerüket, és átalakították a gyorssegély-szolgálatot is, mégpedig úgy hogy megszüntették a helyi IT részlegeket, és áttértek az egyszerű, központosított helpdeskre. 8. ábra: Egyszerű, központosított helpdesk a banknál Az eset tanulsága, hogy egy várhatóan sok hibával működő rendszer esetén különös figyelmet kell fordítanunk a gyorssegély-szolgálat megtervezésére, hogy az képes legyen a hibákat időben felderíteni, és megoldani. Annak ellenére, hogy a rendszer nem működött olajozottan, nem fordult elő a banknál adatvesztés, ami a napi tranzakciók újrarögzítését követelte volna. (Az archiválás naponta történt.) VII. / 27.

III.6.b Egy helpdesk hívás a gyakorlatban A következő beszélgetést, egy informatikai szolgáltatások nyújtására szakosodott cég, és egyik ügyfele között rögzítettük: Jó napot kívánok ZW Service Desktől, miben segíthetek? Jó napot kívánok! Kis Balázs vagyok az XY cégtől, és egy problémát szeretnék bejelenteni. (A helpdeskes rögzíti a nevet és megindítja a dokumentálást, rögtön látja az adatbázisban az ügyfél adatait, majd megkezdi a probléma detektálását.) Igen, tessék mondani, hallgatom! Nem férek hozzá a leveleimhez, nem működik a levelezőrendszerem. Mit tapasztalt, kapott valamilyen hibaüzenetet? Elindítottam a gépet, de kaptam egy piros ablakban egy hibaüzenetet. Mi volt a lényege a hibaüzenetnek? Sajnos már nem emlékszem, nincs előttem. Tudja reprodukálni? Igen, elindítom még egyszer. (Közben folyik a dokumentálás: jelenleg ez egy incidens típusú probléma, hisz először fordul elő az ügyfélnél.) Igen? Ezt a hibaüzenetet kapom: Unable to open your profile. Kapott-e megelőzően is ilyet? Nem, ez az első alkalom. VII. / 28.