ITIL - az informatikaszolgáltatás módszertana Készült: 2002. novemberében a Széchenyi-terv támogatásával KFKI Számítástechnikai Rt Verzió: 3.1 Esettanulmányok Tartalom 1. ESETTANULMÁNYOK... 2 1.1. EGY ONLINE SZAKMAI INFORMÁCIÓS RENDSZER ÜZEMELTETÉSE... 2 1.2. VEVŐSZOLGÁLATI RENDSZER KIALAKÍTÁSA ÉS A SZOLGÁLTATÁSMENEDZSMENT TÁMOGATÁSA... 6 1.3. AZ INFORMATIKAI INFRASTRUKTÚRA ÜZEMELTETÉS KISZERVEZÉSE... 11 1.4. EGY ALKALMAZÁSÜZEMELTETÉS FELÜGYELETÉT ELŐKÉSZÍTŐ PROJEKT... 16 1.5. KISZERVEZÉS ITIL ALAPJÁN... 24
1. Esettanulmányok Az alábbi öt esettanulmány olyan projekteket ísmertet, ahol informatikaszolgáltatást kellett létrehozni. A projektek során különböző mértékben alkalmazták az ITIL ajánlásait, így hasznos képet adhatnak az olvasónak az alkalmazás nehézségeiről és előnyeiről. Az esettanulmányok elkészítése során fogalmazódott meg az a gondolat, hogy a jövőben célszerű lenne kidolgozni egy olyan modellt, amellyel tömören leírhatók az alkalmazás sajátosságai és a pozitív/negatív tapsztalatok, a továbbadásra érdemes tanulságok. Ha ez elkészül, utólag ezeknek az esettanulmányoknak is elkészítjük a szinopszisát. 1.1. Egy Online Szakmai Információs Rendszer üzemeltetése Egy nagy magyar szakmai tömörülés akit a továbbiakban Ügyfél -nek nevezünk 2003 január 1.-én indítja be a szakma magyarországi támogatását célzó omline információs rendszerét. A rendszer egyik fő feladata, hogy egységes adatbázisban gyűjtse össze a releváns adatokat Magyarországról. A szakma fogyasztói oldalának szóló információ mellett a szolgáltatói oldal részére is fórumot ad. A rendszert az IQSoft Rt. fejleszti fővállalkozásban, az ICON Számítástechnikai Rt. alvállalkozásban a kiszolgálópark üzemeltetését végzi. A kiszolgálók szakszerű elhelyezését és szünetmentes tápellátását az Evolit Kft. biztosítja. Jelenleg a rendszer éles próbaüzeme folyik. Az üzemeltetés az ICON Rt. értelmezésében igazából professzionális rendszer-menedzsmentet jelent. A működési hibák és problémák elhárításán, a biztonsági védelmi rendszer által jelzett események kezelésén, illetve mindezek megelőzésén túl a szolgáltatási szintek, a rendelkezésreállás, a teljesítmény és kapacitás menedzselése is elengedhetetlen a hosszú távú folyamatos üzem biztosításához. Az ICON Rt. menedzsmentje korán felismerte az ITIL alkalmazásában rejlő értékeket, már közel öt éve ezt a módszertant követve végzi ügyfélszolgálati tevékenységét. 1.1.1. A szerződés tárgya: rendelkezésreállás biztosítása Az üzemeltetési szerződés nem a bizonyos, pl. napi, heti vagy havi rendszerességgel elvégzendő feladatokról, nem hibaelhárításról, hanem egy mérőszámról szól. Ez a mérőszám azt mutatja, hogy a 7x24 órás üzem mellett éves szinten az idő 99,9%-ában a szolgáltatás elérhető. Ha az üzemeltetés csak reaktív lenne, vagyis a problémák elhárítását célozná meg, a gyakorlati tapasztalatok szerint legfeljebb 95%-os rendelkezésreállás lenne elérhető. A megelőző (proaktív) tevékenység önmagában még kevés a 99,9% eléréséhez, fontos, hogy folyamatainkat a napi feladatoktól a hosszú távú döntésekig szabályozottan, a feladatok és felelősségek pontos definiálása mellett végezzük. 1.1.2. A teljesítés eszközei Az üzemeltető szervezet munkafolyamatait egy úgynevezett Help Desk alkalmazás támogatja, melynek feladatát a következő szakaszban ismertetjük. Az alapinfrastruktúra felügyeletét két területen biztosítják speciális szoftver-eszközök. Az infrastruktúra menedzsmentjét a Microsoft Operations Manager 2000 segítségével valósítottuk meg. Az eszköz figyeli a kiszolgálók eseménynaplóit, teljesítményadatait, ezeket adatbázisban 2
tárolja, szükség esetén riasztást küld az ügyfélszolgálatnak. Emellett a működési paraméterekről heti rendszerességgel jelentéseket állít elő. A szándékos károkozás elleni védelem alapvető tartozéka a rendszernek. A szerverfarmot kettőzött, redundáns tűzfalrendszer védi a támadóktól, emellett hálózat- és szerveralapú behatolásérzékelő rendszer üzemel. A biztonsági rendszereket egy speciális menedzsment-eszköz monitorozza folyamatosan, figyelve az események közötti összefüggéseket, ami a vakriasztások kiszűrését, a szándékos rosszindulatú tevékenységek nagy biztonsággal való felismerését segíti. 1.1.3. Szolgáltatástámogatás Az üzemeltetési szolgáltatás központja az ICON ügyfélszolgálatát támogató HelpDesk-rendszer. Az ICON HelpDesk a rendszert érintő összes bejelentés tárolását és követését végzi. Ide tartoznak: a felhasználók által tapasztalt hibák, az adatok feltöltését és karbantartását végző Ügyfél munkatársainak a rendszerrel kapcsolatos jelzései, a fővállalkozó üzemeltetéssel kapcsolatos bejelentései, valamint a rendszer automatikus felügyeletét ellátó eszközök riasztásai. A bejelentéseket az ICON HelpDesk webes felületén, az ICON Ügyfélszolgálat központi telefonszámán, illetve email-ben lehet megtenni. A beérkező bejelentéseket az ügyfélszolgálat diszpécsere fogadja, felméri az eset súlyosságát és eldönti, hogy azonnal eszkalálni kell-e az adott terület felelőse felé. Ha nem szükséges eszkalál- 3
ni, legfeljebb 30 perc áll a rendelkezésére, hogy a problémát megoldja, ennek leteltével mindenképpen át kell adni az esetet. Ha az azonnali eszkaláció mellett dönt, el kell döntenie, hogy kinek kell továbbítani az esetet: A biztonsági védelmi rendszer riasztásai a biztonsági ügyeleteshez kerülnek. A rendszer által tárolt adatokkal kapcsolatos bejelentéseket az ügyfél kijelölt adatfelelősének irányítja. Az alkalmazással kapcsolatos problémákat a másodvonalbeli támogatást végző mérnöknek továbbítja. Biztonsági riasztás esetén a biztonsági ügyeletes kísérletet tesz a hiba elhárítására, ha ez meghatározott időn belül nem sikerül, vagy a probléma kiesik a kompetenciaköréből, a biztonsági specialistának adja át az esetet. A specialista megteszi a szükséges lépéseket, vagy ha a probléma az infrastruktúra hibájára vezethető vissza továbbítja a problémát a másodvonalbeli támogató mérnöknek. A másodvonalbeli támogató mérnök megvizsgálja, hogy az eset az infrastruktúra, vagy az alkalmazás hibájából ered. Az alkalmazással kapcsolatos hibákat a fejlesztőmérnököknek továbbítja, egyéb esetben az infrastruktúra hibáinak elhárításába kezd. Erre korlátozott idő áll rendelkezésére, ha 3 órán belül nem tudja megoldani, a szoftvergyártók háttértámogatásának (pl. Microsoft Premier Support Services) eszkalálja a hibát. Amennyiben a hiba 24 órán belül nem hárítható el a szolgáltatásfolytonossági terv végrehajtását kell megkezdeni. A leírt folyamat vázlata az alábbi ábrán látható: 4
Az eszkalációs folyamatok mögött az ügyfél és a partnerek felé láthatatlanul a módszertan további folyamatai működnek. A változáskezelést két felelős irányítja, az egyik az infrastruktúra, a másik az alkalmazás változtatásaiért felel, a rendszer egészét érintő esetekben együttes szavuk dönt. A konfigurációkezelés műszaki hátterét a Help Desk rendszer és a konfigurációs adatbázis biztosítja. Ide kerülnek a rendszer főbb elemeinek paraméterei, melyek a szolgáltatástámogatás folyamataihoz szükségesek. 1.1.4. Szolgáltatásbiztosítás A napi feladatokon túl a hosszú távú üzembiztonságot szem előtt tartva stratégiai döntéseket is kell hozni, illetve ha a döntés joga az Ügyfél kezében van kell előkészíteni. A rendszer elvárt működését a szolgáltatásszint-szerződés szabályozza, melyben az Ügyfél által elvárt paraméterek pl. a rendelkezésreállás mértéke kerültek rögzítésre. Ezen elvárások teljesítését folyamatosan monitorozni kell, havi rendszerességgel jelentések készülnek, ez a számlázás alapja. 5
A rendelkezésreállás, a kapacitás és teljesítmény megfelelő szintjének biztosításáért az ügyfélszolgálat kijelölt munkatársa felel. Munkája során figyeli a rendszer működési paramétereit, előkészíti, és időben kezdeményezi a szükséges változtatásokat. A szerződésben vállalt feltételek megkövetelik, hogy az üzemeltetők felkészüljenek a nem várt súlyos hibák, rendszerleállások következményeire. Katasztrófa esetén a helyreállításban közreműködő szakemberek meghatározott terv szerint, a helyreállításért felelős személy irányításával végzik munkájukat. A terv karbantartása, oktatása és ellenőrzése a felelősök rendszeres feladata. 1.1.5. Összegzés Az ITIL módszertan kijelölte az utat a színvonalas szolgáltatás nyújtása felé. Alkalmazása jelentősen csökkentette a bevezetési időt, és a kockázatokat. Olyan eszköz a kezünkben, ami nélkül ma egy informatikai szolgáltató legyen az egy nagyvállalat belső IT-osztálya, vagy külső vállalkozó aligha tud versenyképes szolgáltatást nyújtani. 1.2. Vevőszolgálati rendszer kialakítása és a szolgáltatásmenedzsment támogatása 1.2.1. A cég (LNX) tevékenységéről A Lias-Networx Hálózatintegrációs Kft. (rövidítve LNX) a KFKI Számítástechnikai csoport tagja, Magyarország vezető hálózatintegrációs cége. Az LNX jelenleg 130 munkatársat alkalmaz, éves forgalma 2001-ben elérte a 8,8 milliárd forintot, mostanáig 1600 vevővel rendelkezik és 3600 telepített rendszert tart számon. Az LNX olyan számítógépes hálózatokat és azokra épülő alkalmazásokat ajánl vevőinek, amelyek költség-hatékonyak, az igényeknek megfelelően konfigurálhatók, függetlenek a platformoktól, és az intézményen belüli és azon kívüli kommunikációs lehetőségei a legrugalmasabbak. Minden esetben kiemelt fontosságot tulajdonít a megbízhatósági, rendelkezésreállási és adatbiztonsági követelményeknek. A minőség iránt való elkötelezettséget mutatja, hogy az LNX sikeresen megújította az MSz. EN ISO 9001:2001 szerinti minősítését, a Cisco Gold Partneri minősítő eljárásának újból kiválóan megfelelt, valamint minősített NATO beszállítóvá vált. Az LNX tevékenységei műszaki szempontból három fő csoportba oszthatók. A Hálózatépítés csoport foglalkozik a strukturált kábelezési rendszerek, LAN és WAN megoldások, hálózati biztonság továbbá az IP telefonszolgáltatás tevékenységekkel. A hálózatalkalmazás tevékenységei közé tartoznak a rendszermenedzsment, szolgáltatás menedzsment témakörök és hálózati alkalmazások bevezetése. A vevőszolgálat az átadott eszközök, telepített rendszerek garanciális szervizét biztosítja, működteti a vevőszolgálati rendszert. A cég struktúráját a vevőkkel közvetlen kapcsolatot tartó Front Office, és a műszaki háttértámogatást nyújtó Back Office határozza meg. A Front Office és a Back Office, illetve az azokon belüli csoportok képezik az alapját az egymás közötti költség elszámolásnak és a versenyképesség növelésének. Az LNX telephelye Budapesten található, a vevők köre Magyarország egész területéről tevődik össze. 1.2.2. Miért volt szükséges a vevőszolgálati rendszer kialakítása? A vevőszolgálati rendszer létrehozásának szükségessége több tényezőből tevődött össze. Egyik részről általános célként fogalmazódott meg a szolgáltatás színvonalának emelése és mérhetővé tétele, emellett a vevők és a hibabejelentések száma fokozatosan növekedett. Másrészről az LNX alaptevékenységének tekintett hálózatépítésnél stratégiai partnernek számító Cisco, kezdetben a 6
Silver szintű partneri viszony megújításához, majd később a magasabb szintű Gold partnerség megszerzéséhez és megújításához jól definiált funkciókkal rendelkező vevőszolgálati rendszer működését írta elő. A külső piaci feltételeknek történő megfelelés mellett az LNX egyre inkább felismerte, hogy vevőinek értékesítés utáni rendszer-felügyeleti szolgáltatások magas szintű teljesítésével új eladások generálhatók, mivel a bevétel jelentős részét visszatérő vevők teszik ki. Ezért a cég távlati célja közé került egy dedikált vevőszolgálati csoport kialakítása, a tevékenységét maximálisan támogató vevőszolgálati eszköz alkalmazása és egy optimalizált incidensmenedzsment folyamat definiálása. Egy újabb érvként szerepelt egy olyan ügyfélszolgálati eszköz kiválasztása, használatának, konfigurálásának, testre szabásának megismerése, amelyet a Hálózatalkalmazás csoport az LNX vevőkörének termékként eladhat, így az ügyfélszolgálati rendszerek kialakítása a rendszermenedzsment tevékenység mellett bekerülhetett az LNX hivatalos tevékenységi közé. 1.2.3. Célok, kihívások A vevőszolgálat kialakításához fel kellett állítani egy megfelelő csapatot, definiálni kellett a végrehajtandó folyamatokat és biztosítani kellett a vevőszolgálati tevékenységeket támogató eszközt. Az LNX-en belül szervezeti átalakítást is létre kellett hajtani, ki kellett nevezni egy vevőszolgálati igazgatót aki a szolgáltatási szint menedzser szerepkört is betölti: képes a vevőszolgálati folyamat kialakítására, részt tud venni a vevőszolgálati eszköz fejlesztési igényeinek definiálásában, rendszerfelügyeleti szerződéseket hagy jóvá és felügyeli annak betartását. Szükséges volt egy diszpécser csoport a telefonhívások kezelésére, hibák rögzítésére, incidensmenedzsment tevékenységhez, riportoláshoz. Ki kellett jelölni egy vevőszolgálati menedzsert, akinek a feladatkörébe tartozott a csoport felügyelete, vitás kérdések kezelése. A gyors hibaelhárítás eléréséhez kellett egy mérnökökből álló dedikált csapat (első szintű támogatást nyújtó mérnökök), vagyis egy szakmai csoport, aki először foglalkozik a hibabejelentések megoldásával. A szakmai háttértámogatást az LNX mérnök gárdája biztosította, ügyeleti rendszer keretén belül. A vevőszolgálati folyamatok kialakítása az azt támogató eszköz konfigurálásával párhuzamosan lett ütemezve, ami tág teret adott egy optimalizált rendszer kialakításához, de ugyanakkor időigényesnek bizonyult. Az eszkalációs rendet, prioritási szinteket a rendszer-felügyeleti szerződésben meghatározott válaszidők, elhárítási idők szerint kellett kialakítani. Külön feladatot jelentett a hardveres és szoftveres hibák kezelésének eltérő módja. A kialakítandó vevőszolgálati folyamatnak magában kellett foglalnia a teljes incidensmenedzsmentet, vagyis a bejelentéstől az eset lezárásáig, továbbá az ügyféllel való kapcsolat tartását: rendszeres riport készítését a hibabejelentésekről, határidők betartásáról, illetve túllépéséről. Idővel egyre nagyobb szerepet kapott egy hatékonyan használható tudásbázis létrehozása és a bejelentések könnyű nyomonkövethetősége. A vevőszolgálati rendszerrel szemben támasztott funkcionális elvárásokat külső és belső tényezők egyaránt alakították. A Cisco partneri követelmények között szerepelt többek között a megoldási tevékenységek, prioritás és státuszváltások naplózása, automatikus eszkalációs rend létrehozása, hibák különböző szempont szerinti visszakereshetősége. Nagyon fontos szempont volt a hibaelhárítások során felhasznált tartalék eszközök nyilvántartásának elérése, adatok beintegrálása. Mivel új vevőszolgálati eszköz került bevezetésre és legalább alkalomszerűen sokan használják a rendszert, ezért ennek könnyen használhatónak kellett lenni. Az eszköznek támogatnia kellett az ügyeleti rendszert, könnyen kellett kezelni felelősök változtatását, az eset tovább delegálását, az időelszámolást, és a vevőszolgálati folyamat betartását. A hatékonysági mutatók, vevők felé továbbított jelentések az eszköz által előállított statisztikák, riportok révén nyerhető ki. A rendszerfelügyeleti szerződésekben vállalt követelmények emelkednek, egyre feszítettebbé 7
válik azok betartása, amely csak egy hatékonyan működő vevőszolgálattal lehetséges. Mivel idővel egyre több a felügyelt rendszer, növekedik az ügyfelek száma, egyre bonyolultabb rendszereket kell felügyelni, a rendszerrel több ügyfél kezelését is hatékonyan kellett tudni kezelni. Könynyen elérhetővé kellett tenni a felügyeleti szerződések adatait, kapcsolattartó személyek adatait, az előírt megjelenési és elhárítási időket. 1.2.4. A vevőszolgálati rendszer kialakításának menete Az előírt célok elérése az ITIL keretrendszer alkalmazásával az alábbi lépések szerint zajlottak: Tervezés, előkészítés: Vevőszolgálati folyamat, szerepkörök definiálása, automatizált rendszer kialakítása Vevőszolgálati csoport felállítása, bevezetés, üzemeltetés és folyamatos továbbfejlesztés 1.2.4.1. Tervezés, előkészítés, eszköz kiválasztása A vevőszolgálati eszköz kiválasztása piacvezető termékek vizsgálatával, teszt környezet felállításával kezdődött. Az eszközzel szemben támasztott követelmények az alábbiak szerint került csoportosításra: Alapvető elvárások: Mindenképpen kell teljesíteni ezeket a követelményeket, ellenkező esetben ez kizáró okot jelent. Ilyen alapvető elvárás például a naplózás, státuszkövetés, lekérdezés kulcsszavak alapján, stb. Ezeket mindegyik vizsgált termék teljesítette. Fontos elvárások: Ezek az eszköz kiválasztását erősen befolyásoló, meghatározó tényezők. Itt nem csak a vevőszolgálat, hanem a Hálózatalkalmazás, vagyis közvetve a leendő LNX vevők igényeit, adottságait is figyelembe vettük. Speciális elvárások: Az alapvető használatot lényegesen nem befolyásoló jellemzők, amelyek a használhatóságot segítik. Táblázatban értékeltük az egyes termékek funkcióit, egyes tulajdonságot súlyozva vettünk figyelembe. Ennek összesített eredménye alátámasztotta a végső döntést. A döntés alapvetően a meghatározó fontos elvárások szerint történt. Ezek az eszköz gyártójának piaci részesedése, stabilitása és az általa nyújtott támogatás, magyarországi jelenléte, testre szabhatóság (üzleti folyamatokhoz való alakíthatóság), konfigurálhatóság, integrációs lehetőségek harmadik fél termékeihez (elsősorban hálózatmenedzsment és rendszermenedzsment eszközökhöz), eszköz nyilvántartó adatbázishoz való illeszthetőség, riport készítési lehetőségek. Nagyon fontos szempont volt az egyedi igények szerinti fejlesztés lehetősége, a kész vagy félkész megoldások felhasználásával a gyors bevezetés lehetősége, a rövid betanulási időszak. Meghatározó jellemző, hogy a termékcsalád mennyire fedi le az ITIL által definiált témaköröket, vagyis a vevőszolgálati tevékenység mellett változáskezelést, problémakezelést és a szolgáltatási szint menedzsmentet. Folyamatok, szerepkörök, automatizált rendszerrel szemben támasztott követelmények meghatározása, implementálás A vevőszolgálati folyamatok és az azt támogató eszközzel szemben támasztott követelmények definiálása egy időben zajlott. Ez nehezebbé tette a specifikációs időtartamot, mert az igények egymást is alakították, de így egy optimalizált rendszert lehetett kialakítani. A folyamatok és szerepkörök kialakításakor nagy segítséget nyújtottak az ITIL által megfogalmazott irányelvek. 8
A folyamatok kidolgozása, az eszköz testre-szabása először kísérleti rendszer keretében történt, majd a végleges rendszer bevezetése következett. A rendszer életbe léptetéséig körülbelül háromnegyed év telt el. 1.2.4.2. Bevezetés A fokozatos bevezetést belső figyelemfelkeltés előzte meg: az LNX belső újságában több cikk lejent meg, amely tájékoztatást adott a rendszerről, növelve annak elfogadottságát. A vevőszolgálati rendszer életbe léptetéskor igazgatói utasítás írta le a felelősségi köröket és az ügymeneti szabályokat. A vevőszolgálati vezető és egyes meghatározó személyek ITIL oktatáson vettek részt. Emellett a rendszert használó személyek munkakörüknek megfelelő szintű oktatást kaptak a rendszer használatáról, megismerték a szerződésben vállalt szintidőket. 1.2.4.3. Üzemeltetés Miután megszilárdult a vevőszolgálati rendszer, a hangsúly a rendszer fokozatos továbbfejlesztésére és a változások kezelésére tevődött át. A rendszer-felügyeleti szerződésekben előírt aktuális válaszidőket, javítási időket a Szervizhívás eszkaláció kézikönyv tartalmazza. A vevőszolgálati csoport riportokat generál a szintidő teljesítéséről, amelyet továbbít az ügyfelek felé. A magasabb színvonal elérését ösztönzési rendszer segíti: a sikeres határidőn belüli hibaelhárításért sikerdíjat kap a megoldó személy. 1.2.4.4. Továbbfejlesztés A vevőszolgálati szolgáltatás javítását segíti a vevőszolgálat rendszeres (negyedéves) értékelése, amellyel felismerhetők a problémás területek. A vevőszolgálati eszköz új funkciókkal történő kiegészítéséről a felhasználók oktatásban részesülnek. 1.2.4.5. A vevőszolgálati rendszer terjedelme A vevőszolgálat kialakítása során az incidensmenedzsment, szolgáltatási szint menedzsment, problémakezelés, költség menedzsment (munkaidő alapján történő költség elszámolás) témakörök lettek teljesen vagy részben lefedve: 1.2.5. Vevőszolgálat működésének rövid leírása A vevőszolgálat alapfeladata az LNX által forgalmazott eszközök és rendszerek garanciális szolgáltatásainak biztosítása. Az LNX testre-szabott rendszer-felügyeleti szerződések keretében az ügyfél igényének megfelelő, közösen megállapodott szolgáltatási szintet biztosít. A szolgáltatások kiesésének csökkentése érdekében szintidőre hibaelhárítást végez, azonnali csereeszközt biztosít. Az üzemeltetés támogatását karbantartási, felügyeleti tevékenységgel segíti. Ezen kívül szakmai tanácsadást, konzultációt nyújt. A megállapodások teljesítésének érdekében az LNX vevőszolgálat folyamatosan elérhető hívószámán napi 24 órában fogadja a vevői bejelentéseket, 24 órás mérnöki ügyeletet tart fenn, és nagy mennyiségű tartalékeszköz-készletet tárol. A bejelentések életciklusának követhetőségét, az alkalmazott megoldások tudásbázisba építését a vevőszolgálatot támogató automatizált rendszer biztosítja. A vevőszolgálat működése legjobban a vevői elégedettséggel mérhető. Ezen felmérések szerint a vevőszolgálat megítélése folyamatosan javult, az utolsó vizsgálat alkalmával az ügyfelek értékelése alapján már 4,5-ös átlagot sikerült elérni az 5-ös skálán. 9
1.2.5.1. Bejelentés módja A bejelentéseket elsődlegesen telefonon lehet megtenni egy erre a célra kijelölt telefonszámon. A szám elérhetetlensége esetén a tartalék mobil hívószám használható. A telefonos bejelentéseket (észrevétel, hiba, igény) vevőszolgálati diszpécser fogadja, rögzíti az elektronikus rendszerben, és szétosztja a megfelelő problémakezelőhöz, valamint gondoskodik az ügyfél visszaértesítéséről. A bejelentést írásban is meg kell erősíteni e-mailen vagy faxon. Az operátor esetleges elérhetetlensége esetén a bejelentés üzenetrögzítőre mondható. 1.2.5.2. Ügyeleti rendszer Az LNX többszintű, megfelelő szakképesítéssel rendelkező mérnökökből álló ügyeleti rendszert üzemeltet heti váltásban: Az első szintű, megfelelő szakismeretekkel rendelkező úgynevezett első vonalbeli ügyeletes azonnal megkezdi a hiba elhárítását, szükség esetén helyszíni kiszállással. Amennyiben az első szintű ügyeletes nem tudja megoldani a problémát, azonnal riasztja a következő szintű ügyeletet. A második szintű, magasabban képzett, tapasztaltabb ügyelet akkor lép működésbe, amikor az első vonalbeli ügyeletes nem tud megbirkózni a feladattal. Ez a szakember a harmadik szintű ügyeleteshez fordulhat segítségért, vagy közvetlenül kérhet támogatást a hardver vagy szoftver gyártótól. A harmadik szinten a legmagasabb szintű szakismeretekkel rendelkező főmérnök felügyeli az egész ügyeleti szolgálat munkáját. Hozzá csak az első két szinten megoldatlan feladatok jutnak el. Ő felel azért is, hogy minden olyan probléma, amit az LNX szakemberei nem tudnak megoldani, szintidőre a gyártó felé eszkalálódjon. Az ügyeleti rendszer szolgálatban lévő tagjai mellett munkaidőben az LNX bármely szakembere bevonható a hibaelhárításba. 1.2.5.3. Tartalékeszköz-készlet Az LNX tartalékeszköz raktárat működtet, amely révén biztosítja ügyfelei részére rendszerfelügyeleti szerződések keretében a hardver eszköz egyszeri meghibásodása esetén csereeszköz biztosítását, és vállalja a probléma szintidőn belül történő elhárítását. 1.2.5.4. Vevői elégedettség mérése A vevőszolgálati tevékenység megítélésének legfontosabb módja a vevői elégedettség mérése. A vevők két módon adhatnak hangot észrevételeiknek. Eseti panaszt jelenthetnek be a vevőszolgálat folyamatosan elérhető telefon vonalán, vagy e-mailen keresztül. A vevői reklamációk a legmagasabb prioritással kerülnek rögzítésre a vevőszolgálati rendszerben. Ezen kívül kitölthetik a számukra rendszeres időközönként elküldött vevői elégedettségi" kérdőíveket. Negyedévente minden olyan vevő megkapja ezt a kérdőívet, aki az előző időszakban valamilyen bejelentést tett. 1.2.6. Előnyök, problémák, fejlesztési lehetőségek A vevőszolgálati rendszer kialakításával egy hatékonyan működő ügyfél - LNX kapcsolat jött létre. Mérhetővé vált a vevőszolgálat működése a megelégedettségi mutatók, szolgáltatás terjedelmére (hibaszám, tevékenységek száma, vevők száma) vonatkozó statisztikák révén. Nincs elveszett hívás, elsikkadó eset még akkor sem, ha az ügyeletes éppen nem elérhető. A riportok formájában előálló menedzsment információ segíti az egyre magasabb színvonalú szolgáltatás nyújtását. 10
Folyamatosan javult az ügyfél LNX közötti kommunikáció, jobb szolgáltatási megállapodásokat lehetett kötni a felgyülemlő adatok alapján (szintidők, erőforrás gazdálkodás). Vitás kérdések tisztázhatók a rendszer-felügyeleti szerződések áttekintéseikor a munkanaplóban feljegyzett háttérinformációk alapján, így tovább erősíthető a kölcsönös bizalom. A tipikus hibák kiszűrésével a problémakezelés folyamatot lehet támogatni. A gyakran előforduló hibák elemzésével kiszűrhetők és megszüntethetők a tipikus hibák. A hatékonyságot növeli a tudásbázis fokozatos létrehozása. Az eszkalációs rend működése gyors reagálást és hibaelhárítást eredményez, melynek révén vállalati szintű szolgáltatási színvonal biztosítható. A hibaelhárítást végző mérnök számára azonnal rendelkezésre áll az adott vevőnél előírt válaszidő. A tartalékeszköz-raktár adatbázissal való kapcsolat révén könnyen kezelhető a készlet, könnyen biztosítható a szükséges mennyiségű eszköz és csökkenthető a feleslegesen tárolt eszközök száma. A hibaelhárítással töltött munka idejének nyilvántartásával a költségmenedzsment folyamatot lehet támogatni, ami jobb erőforrás kihasználást jelent és az információ visszacsatolható a szolgáltatási szint menedzsment témakörhöz, felhasználható a szerződéseknél. Az ITIL oktatás révén könnyen specifikálhatók voltak az igények, szerepkörök, a folyamatok könynyen azonosíthatók, tervezhetők voltak és az üzemeltetés során is folyamatosan támpontot nyújtott. A legnagyobb problémát az jelenti, hogy a vevőszolgálati rendszerbe rögzített adatok minden szempontból megfeleljenek az előírásoknak. Ezt a diszpécser csoport az incidensmenedzsment folyamat részeként végzett tartalmi ellenőrzések révén éri el. További javítási lehetőségek vannak még a tudásbázis strukturálásában, használhatóságának növelésében, elérhetőségében, visszakereshetőségében. Új funkció lehet a vevőszolgálati rendszer ügyfelek felé történő kiterjesztése, Web-es elérés biztosítása is, ami azonban újabb problémákat vet fel: felelősségi kérdések, pénzügyi vonzatok. 1.3. Az informatikai infrastruktúra üzemeltetés kiszervezése 1.3.1. Előzmények A KFKI Számítástechnikai csoport, Magyarország egyik vezető informatikai cégcsoportja, amelynek tagjai 1998-ban közös telephelyre költöztek. Az akkor 350 főt számláló cégcsoport dolgozóinak száma mára 800 főre emelkedett. A dinamikus növekedés már akkor megkívánta, hogy a hálózati infrastruktúrát egységes elvek alapján hozzák létre, amely lehetővé teszi a bővítést, rugalmas átkonfigurálást, kiszolgálja a cég számítógép hálózati és telefonhálózati igényeit. Az egyes cégek számítástechnikai infrastruktúrája nem lett összevonva, az eltérő igényekhez úgy lehetett a legkönnyebben alkalmazkodni, hogy minden cég megtartotta saját üzemeltetését, rendszerei és PC-i viszont a strukturált hálózaton kialakított, CISCO alapú VLAN-okba (virtuális lokális hálózatokba) lettek szervezve. A belső strukturált hálózat a külvilág felé közös felületen kapcsolódott (tűzfalak, Internet kapcsolat, behívási rendszer, stb.). Az egyes rendszerek üzemeltetése hagyományos módon volt megszervezve. Informatikai cégcsoportról lévén szó, az informatikai infrastruktúrán sokféle fejlesztő környezet működött, a cégek belső informatikai rendszerei is különbözőek voltak. Az erőteljes növekedés feszítő követelményeket támasztott az informatikaszolgáltatással szem- 11
ben, amit csak erősített a függőség növekedése. A szerződések teljesítése egyre inkább függött a belső informatika által nyújtott szolgáltatásoktól. Megugrott az infrastruktúra beruházási igény, aminek anyagi terheit tovább növelte a heterogén rendszerek sokasága és sokfélesége. A kihívásra adott első válasz az egységesítés megjelenése volt. Irányelvek lettek elfogadva, amelyek hatására elkezdődött a kliens gépek bizonyos egységesítése, azonos szoftverekre való áttérés előkészítése (pl e-mail). A belső információs rendszerek számára és a nagy alkalmazásfejlesztési projektek számára központi szerverek lettek beszerezve. Három év alatt kb 300 millió Ftos infrastruktúra beruházás történt, miközben a kiszolgált létszám megduplázódott. 1.3.2. Kiinduló helyzet Ebben a helyzetben fogalmazódott meg a csoportszintű üzleti igény: egységesíteni és javítani kell a belső informatikaszolgáltatást. A megoldás felé tett első lépés az volt, ki kell szervezni, és ezzel a csoport üzemeltetéssel foglalkozó tagját, az Evolit Kft-t kell megbízni. A következő döntés az volt, hogy próbáljuk meg alkalmazni az ITIL sok helyen bevált gyakorlatát. Az egyes cégek főállású üzemeltető személyzetét átvette a szolgáltató és elkezdődött az előkészítés. Az alábbiakban, ahol lehet, megpróbáljuk az ITIL témakörök közé csoportosítani a projektet, hogy jól érzékelhető legyen, hogy az egyes lépések hogyan kapcsolódtak az ITIL-hez illetve milyen mértékben sikerült az ITIL irányelveit alkalmazni. 1.3.3. Szolgáltatási szint menedzsment A kitűzött határidők szorítása miatt a projekt egy szerződéstervezettel indult. Amikor ezt az egyes cégek megkapták, az eltérő igények miatt a cégek informatikai vezetőiből alakult egy szolgáltatási szint menedzser szerepkört betöltő bizottság (pontosabban az egységesítési irányelvek kidolgozásáért felelős bizottság vette fel ezt a szerepkört). Első lépésben a fő üzleti követelményeket kellett meghatározni. Ezek közül az alábbiakat érdemes kiemelni: Legyen minél egységesebb az informatikaszolgáltatás Egyetlen szolgáltatási szint megállapodás legyen, függetlenül attól, hogy az egyes cégek, mint jogi személyek, külön szerződést kell, hogy kössenek a szolgáltatóval Fejleszzük tovább az egységesítési irányelveket, ezzel is elősegítve, hogy a szolgáltatásokat költség hatékonyan lehessen biztosítani Hajtsuk végre az infrastruktúra konszolidációját, vonjuk össze az egyes szolgáltatásokat megvalósító szervereket, ahol szükséges, hajtsunk végre korszerűsítést Az ügyfélszolgálati funkciót támogassuk egy Helpdesk szoftverrel A cégek specifikus igényeit külön szolgáltatások definiálásával vegyük figyelembe Húzzunk hasznot az ITIL ajánlásaiból A megkötött szerződések ugyanazt a szolgáltatási megállapodást tartalmazzák, melynek cégenként legyen egy cégspecifikus része, de ha több cég is igénybe vesz egy szolgáltatást, akkor azok egységesen legyenek definiálva Létre kell hozni egy közös géptermet A következő lépés a szolgáltatási szint megállapodás és a szolgáltatás katalógus kidolgozása volt. Ezzel kapcsolatban az az álláspont alakult ki, hogy kezdetben minél egyszerűbben kell a szolgáltatásokat definiálni, ugyanakkor a szolgáltatások színvonala egyik cégnél sem csökkenhet, 12
és az áttérés (változás) nem akadályozhatja a cégek üzletvitelét. Az egyes szolgáltatásokat csak tömören kell meghatározni, ugyanakkor minden szolgáltatáshoz szintet kell rendelni, azaz biztosítani kell a mérhetőséget, hogy ellenőrízhető legyen. Ne legyen túl sok szolgáltatás (tehát pl. az irodai szolgáltatások az MS Office XP szolgáltatásait tartalmazták, ezek nem lettek kibontva szövegszerkesztési, táblázatkezelési stb. szolgáltatásokra). A szinteket rendelkezésreállási illetve reagálási és helyreállítási időkkel határoztuk meg. A szolgáltatáskatalógusban voltak funkcionális szolgáltatások (pl elektronikus levelezési szolgáltatás, Internet elérés, távmunka biztosítás stb.), és támogató jellegű szolgáltatások (pl ügyfélszolgálat, ügyeleti szolgáltatás, szerver és desktop szolgáltatások). Díjazás szerint voltak általánydíjas szolgáltatások, amelynek alapja a PC-vel rendelkező felhasználó lett. Ez később, mivel gyakorlatilag minden munkatárs rendelkezik személyi számítógéppel, az átlaglétszámra módosult. (Ebbe viszont az emberi erőforrás vezetők beszámítják a telephelyen dolgozó külső vállalkozókat, vagy a projektek külső résztvevőit is, hiszen sok költségterhelés mutatószáma az adott szervezet munkahellyel, íróasztallal, telefonnal, PC-vel rendelkező munkatársi létszáma). Így egyszerűbb lett a havi elszámolás, ott pedig ahol jelentős lett volna az eltérés, eseti korrekciót alkalmaznak (pl ha egy üzletág jellegénél fogva sok, állandóan az ügyfélnél tartózkodó munkatásrssal rendelkezik). Díjazás szerint voltak igénybevétellel arányos díjazású szolgáltatások (pl PC kölcsönzés) és időarányos díjazású szolgáltatások is. A szolgáltatási szint megállapodás kidolgozása a vártnál tovább tartott (9 hétig), és véglegesítésére már a szolgáltatás beindulása után került sor, de a tapasztalat azt mutatta, hogy érdemes volt alapos munkát végezni. A szerződésekben ugyanakkor rögzítésre került a rendszeres felülvizsgálat, amely biztosíthatja a folyamatos javítási tevékenység figyelembevételét, illetve új szolgáltatások bevezetését, vagy létező szolgáltatások módosítását is. 1.3.4. Ügyfélszolgálat Az ügyfélszolgálat feladata az incidensek és igények bejelentésének fogadása és azok kezelése. Létrehoztunk egy könnyen megjegyezhető belső telefonmelléket, amelyen az ügyfélszolgálat elérhető. Bevezetésre került a Remedy Helpdesk, amelyet elláttak egy intranet bejelentő felülettel, hogy bárki elérhesse a cégcsoporton belül. Kezdetben kötelező volt a felhasználónak a bejelentést Remedy-ben rögzíteni, de a tapasztalatok alapján félévvel később a telefonos bejelentés lett az elsődleges, ezt az ügyfélszolgálat kötelessége lett rögzíteni. Ezt elsősorban az indokolta, hogy az ügyfélszolgálat sokszor pontosabban tudja rögzíteni az incidens részleteit, mint a felhasználó. Természetesen a felhasználó bejegyzési lehetősége is megmaradt. Ki kell emelni azt az ITIL ajánlást, hogy figyelemfelkeltő, meggyőző kampányt kell folytatni, amivel a felhasználóknak elmagyarázzuk, miért és hogyan szolgálja a Helpdesk bejelentés az ő érdekeit. Még egy korábbi Helpdesk bevezetésnél tapasztaltuk, hogy egyes felhasználók hónapokig panaszkodtak, hogy bizonyos híbák, zavarok kijavítása nem történt meg, ugyanakkor nem jelentették be a Helpdesk-be, így nem volt dokumentálható, az üzemeltetés számára pedig nem volt látható, hogy van egy lezáratlan incidens. 1.3.5. Incidens menedzsment Az incidensek kategóriába sorolva rögzítésre kerülnek a Remedy Helpdesk rendszerben, ahol az ügyeletes kategorizálja, és prioritással látja el azokat. A prioritás a szolgáltatási szint megállapodásban általában szolgáltatásokhoz van rendelve, de ezt módosíthatja az incidens munkavégzést akadályozó hatása. Utólag megállapítva, célszerű lett volna egy komplexebb rendszert kialakíta- 13
ni, amelyben legalább a sürgősség és a hatáskód szerepel, és az incidens ennek függvényében kap prioritást az ügyfélszolgálattól. Az incidens állapotok között a következők szerepelnek: az új, bejelentett, kiosztott, megoldása folyamatban, megoldott és lezárt, valamint egy felfüggesztett állapot. A megoldott incidensről a felhasználó egy automatikus elektronikus levélben értesítést kap, és ha elégedett a megoldással, lezárja az incidenst. Ha elfelejti lezárni, a rendszer egy hét után automatikusan lezárja, de erről is értesíti a felhasználót. A rendszer jelenleg úgy üzemel, hogy az incidens minden állapotváltozásáról értesíti a felhasználót, aki így figyelemmel követheti a megoldás folyamatát és szükség esetén kapcsolatba léphet az ügyfélszolgálattal. Azokat az incidenseket, amelyeket az ügyfélszolgálat nem tud azonnal megoldani, jellegüktől függően a kliens vagy a szerver csoporthoz továbbítja. A kliens csoport foglalkozik a PC oldali incidensek megoldásával illetve helyszíni javításával, míg a szervercsoport a hálózati és szerverproblémák magoldásával. Az incidensek csoporthoz és személyhez rendelését a Remedy helpdesk rendszer segítségével végzik. Munkájuk során egyre nagyobb segítséget nyújt a Remedy ismeretbázisa, ahol folyamatosan rögzítik az incidensek és problémák megoldására vonatkozó ismereteket. Ez az ismeretbázis ma már lényeges segítséget nyújt az incidensek hatékony kezeléséhez. 1.3.6. Problémamenedzsment A problémakezelés feladata az incidensek kiváltó okának meghatározása, és az ok megszüntetéséhez szükséges változtatások kezdeményezése illetve azok végrehajtása. Ezt a feladatot is a két említett csoport végzi a szakismeretek szerint szétosztott incidensek hozzárendelése alapján. Munkájuk során szükség esetén igénybe veszik a KFKI csoport más tagjainak, vagy külső szolgáltatók támogatását. A megoldott hibák bekerülnek az ismeretbázisba, azok a hibák pedig, amelyeket az adott helyzetben nem lehet kijavítani (pl. várni kell egy újabb szoftver verzió megjelenésére), az ismert hibák adatbázisába kerülnek. Az eddigi tapasztalatok alapján célszerű lett volna az incidensekhez egy olyan lezáró kódrendszer kidolgozása, amely a kiváltó okok szerint csoportosítja a lezárt incidenseket, ily módon megkönnyítve az utólagos elemzéseket és a megelőző intézkedések meghatározását. Érdemes megemlíteni az incidensek számának alakulását. Az indulás során az egyes cégek informatikai rendszereinek üzemeltetését időben egymást követően vette át a szolgáltató. Az incidensek száma az előkészítés alaposságának függvényében változott ugyan cégenként, de a havi átlag egy kezdeti megugrás után minden cégnél csökkent és beállt egy viszonylag állandó értékre. Ezzel szemben ott, ahol az üzemeltetés átvételével egy időben más változások is voltak, az a beállási folyamat hónapokkal tovább tartott, ami arra mutat, hogy a jelentősebb változtatásokat célszerű időben egymást követően ütemezni. Amikor a stabil állapot bekövetkezett, az incidensek havi átlaga 500 körül ingadozott, miközben a kiszolgált végpontok száma kb. 600 volt. A problémamenedzsment megelőző intézkedéseinek hatására ez a szám ma havi 300-ra csökkent, ami jól szemlélteti az ITIL alkalmazásának eredményét. Miközben csökkent az incidensek száma, csökkent a megoldásra és szolgáltatás helyreállításra fordított munkaidő is. Amikor az első stabilizáció bekövetkezett, elindítottuk a szerverkonszolidációs projektet. Ennek lényege, hogy az egyes szolgáltatásokat nyújtó rendszereket összevontuk és egyetlen rendszer szolgáltatásával helyettesítettük. Így ma már egyetlen file szerver, egyetlen mail szerver szolgálja ki a szolgáltató által kiszolgált cégeket, egységes közös tűzfal és távmunka rendszer lett bevezetve, a belső virtuális lokális hálózatok egységes elvek szerint át lettek struktúrálva, minden cég egységes vírusvédelemmel lett ellátva, a cégek egységes könyvtárszerkezetre tértek át, a cégspecifikus igényeket pedig ezen belül valósították meg. Egységesítve lettek a PC-k elnevezési konvenciói, dinamikus IP cím kiosztást vezettek be, szabályozva lettek a hozzáférési jogok a cégeken belül és a cégek között, illetve a cégek belső szervezeti egységeiben és azok között. A szerverkonszolidáció jól példázta a változáskezelés fontosságát. Egy-egy áttérésnél az incidensek száma mindig megugrott, de a tapasztalatok hasznosításával javítani lehetett a hatásvizsgálatot és a tervezést, így 14
az implementálás során kimutathatóan csökkent az incidensek számának átmeneti megugrása. A szerverkonszolidáció másik hatása éppen ellenkező volt, hosszabb távon csökkentette az incidensek számát. Ezt több tényezővel lehet magyarázni: Egy szolgáltatást egyetlen rendszer biztosít, így relatíve több idő jut a megelőző intézkedések tervezésére és bevezetésére A beállított új rendszerek általában korszerűbbek voltak, még akkor is, ha a közös szolgáltatást biztosító rendszer valamely cég rendszeréből lett kialakítva A szerverkonszolidáció során figyelembe vettük a rendelkezésreállás és kapacitásmenedzsment követelményeit Egyetlen rendszerrel könnyebben kielégíthetőnek bizonyultak a szolgáltatási szint megállapodásban rögzített szolgáltatási szintek Könnyebb lett a szakemberek betanulása, hiszen kevesebb rendszert kell magas szinten ismerni. Különösen igaz ez az újonnan belépő munkatársakra 1.3.7. Rendelkezésreállás menedzsment A rendelkezésreállás javítására a követelmények megfogalmazása után számos intézkedés történt, amelyek részben a szerverkonszolidációs program, részben az ITIL alapú szolgáltatásirányítás bevezetése során lettek foganatosítva: Biztonságpolitika aktualizálása Egységes vírusvédelem bevezetése Mentési rendszer egységesítése és továbbfejlesztése (központilag menedzselhető HP Omniback mentőszoftver, nagyteljesítményű Ultrium mentőegységek beállítása) Fürtözött (cluster) konfigurációk beállítása a kritikus szolgáltatásoknál Redundáns tárolási módok (RAID, tükrözés) általánossá tétele Megbízhatóbb tároló-rendszerek kialakítása, a közeljövőben pedig egy EMC Clarion SAN tároló-rendszer telepítése, amely tovább javítja a rendelkezésreállást Egységes tűzfal menedzsment Távmunka biztonsági rendszerének kiépítése mind a betárcsázás, mind az interneten keresztül történő bejelentkezésekre A súlyos incidensek esetén megelőző intézkedések kidolgozása és bevezetése 1.3.8. Kapacitásmenedzsment A kiinduláskor a kapacitásigények becslése a cégek igényeiből indult ki, de ahogy a szolgáltatások és az infrastruktúra összevonásra került, folyamatosan figyeltük az igények várható változásait és hoztuk meg a reagáló vagy megelőző döntéseket. Itt jól példázza az ITIL megközelítés előnyét a következő példa. A rendelkezésreállás menedzsmenthez tartozó biztonságpolitika előírta, hogy a fontos adatokat a file szerveren kell tárolni, hogy ezzel a mentések automatikusan biztosítva legyenek. Ez jelentős központi tároló kapacitásnövekedést jelzett, így a kapacitáskezelés időben fel tudott rá készülni. A változáskezelés hatásvizsgálata kimutatta, hogy a file szerver 15
funkció központi gépterembe történő összevonása megváltoztatja a hálózati forgalom struktúráját, így bővíteni lehetett a felsőszintű Gigabit Ethernet hálózatot, elejét véve a forgalmi túlterhelésnek. Bővítésre került a külső internet szolgáltatóhoz biztosított sávszélesség, és bevezetésre került egy forgalom felügyelő és szabályzó eszköz, amely előnyt biztosít a magasabb prioritású üzleti forgalomnak. A kapacitástervezést hatékonyan segítették a monitorozó eszközök által biztosított adatok, ugyanakkor nem szabad elhanyagolni az üzleti oldal rendszeres megkérdezését a jövőre vonatkozó bővítési vagy éppen csökkentési igényeikről. 1.3.9. Konfigurációkezelés Bár a konfigurációkezelés, illetve a konfigurációs adatbázis az ITIL folyamatok magja, azaz minden folyamat használja a konfigurációs adatbázist, a valóságban ez az egyik legnehezebben kezelhető terület. Az egyik probléma elvi: annak eldöntése, hogy milyen részletességgel akarjuk kezelni, illetve nyilvántartani a konfigurációkat. Ezt annak gondos mérlegelésével kell eldönteni, vajon a nyilvántartás költsége nem nagyobb-e, mint a cserébe kapott információ értéke. A másik probléma gyakorlati, az összes ITIL folyamatot támogató, integrált, könnyen kezelhető konfigurációs adatbázis kezelő eszközök helyett a legtöbb támogató rendszer inkább csak eszköznyilvántartást támogat. Esetünkben fokozatosan nő a nyilvántartott entitások száma és a nyilvántartás mélysége, de a kapcsolatok létrehozása nehézkes, így a konfigurációkezelés kevesebbet adott, mint amit a módszertan alkalmazásától vártunk. 1.4. Egy alkalmazásüzemeltetés felügyeletét előkészítő projekt 1.4.1. A teljes projekt A Nutricia Kereskedőház Rt.-ben 2001. május elején kezdődött el az MFG/PRO vállalatirányítási rendszer bevezetése 1, és szinte napra pontosan egy év múlva, 2002. május 6-án a kereskedőház első telephelyén használatba is vették a rendszert. Ezt követően június közepén a legnagyobb, a budapesti telephely is csatlakozott a rendszerhez, majd július elejétől további depók használják az MFG/PRO-t a rendelések felvételére, áruk beérkeztetésére és a boltokba történő kiszállítására. A roppant szellemes módon tejút projektnek elnevezett munka végeztével, 2002 szeptemberétől a Nutricia tulajdonú telephelyek mindegyikében az MFG/PRO rendszer támogatja a vállalatirányítási folyamatokat. Természetesen a logisztikai folyamatokhoz tartozó pénzügyi-számviteli tranzakciókat is az MFG/PRO kezeli a társaságnál. A Nutricia Kereskedőház Rt.-nél bevezetett MFG/PRO Integrált vállalatirányítási rendszert kb. 300 felhasználó kezeli napi szinten az informatikai kiszolgálás felügyelete alá tartozó kb. 600 db számítógép közül. A rendszer működését biztosító technológiai komponensek száma több tucat és a felhasznált eszközök száma is meghaladhatja a fél ezret, melyek elhelyezkedése az ország több pontján van. A közel húsz telephely, a 70 rendelésfelvevő és naponta az ország minden pontjára induló 300-350 járat informatikai hátterének kialakítása nagy kihívást jelentő feladat volt a KFKI ISYS MFG/PRO üzletágának számos rendszerbevezetést véghez vitt csapata számára is. A közel 300 felhasználót kiszolgáló integrált rendszer kiépítését a szakértők egy, a kereskedelmi, disztribúciós tevékenységet végző cégek számára kialakított modell alapján végezték. A modell többek között a nagy mennyiségű, napi, vevő ill. bolthálózathoz kapcsolódó rendelésfelvétel, a járatelszámoltatás, a különleges értékesítési és árazási módok, a depók közötti rendelések kezelésével ad testre 1 A Nutricia Kereskődőház Rt.-nél végzett rendszerbevezetésről részletesen az ISYSTÉMA korábbi számaiban olvashat a www.kfki-isys.hu oldalakon. 16
szabott megoldást a Nutricia Kereskedőház, és más kereskedelmi tevékenységet végző cégek számára. Kezeli továbbá a készletek, késztermékek szavatossági idő szerinti illetve párhuzamos, független mértékegységekben történő nyilvántartását, a kiszállításhoz kapcsolódó göngyöleget és számos más, a kereskedő cégek napi működési gyakorlatában megjelenő feladatot. Az új vállalatirányítási rendszer kialakításával és más informatikai fejlesztésekkel egy merőben új informatikai környezet alakult ki a társaságnál. Ennek folyamatos, biztonságos üzemeltetése hatalmas feladat egy informatikai szervezet számára. A KFKI ISYS alakította ki az üzemeltetési tevékenység működtetésének modelljét is, majd a KFKI Csoport cégeivel és más alvállalkozóival közösen meg is valósította azt. A Nutricia működéséből, a forgalmazott termékek jellegéből adódóan folyamatos, 7x24 órás rendelkezésre állás szükséges mind a vállalatirányítási rendszer, mind annak környezete számára. Gondoljunk csak bele, mi történne a köztudottan rövid szavatosságú idejű tejtermékekkel, ha a például a hálózat hibájából veszélybe kerülne a folyamatos árukiszállítás. A központi adatbázisra épülő, országos rendszer on-line adatelérést biztosít a telephelyek felhasználóinak a két clusteres IBM 6H1 pseries 660 központi szerveren keresztül. Az igényeknek megfelelően a telephelyek közötti duplikált MATÁV és PanTel vonalak - WAN hálózat kiépítését is a biztonsági szempontok indokolták. Egy ekkora rendszer biztonságos üzemeltetéséhez ki kellett dolgozni egy - a szereplők számára ismert - eljárást, ahol minden szereplő tisztában van a saját feladatával és felelősségével. Tisztázni kellett az üzemeltetés biztonságáért felelős személyek és szervezetek feladatait és egymáshoz való kapcsolatait. Meg kellett határozni azon technológiát és feltételrendszert, aminek segítségével az üzemeltetési biztonság és az ehhez szükséges kiszolgálás biztosítható. A folyamatos üzem biztosítására a KFKI Csoport szakemberei egy Remedy alapú help-desk rendszert építettek ki, amely valamennyi informatikai alkalmazás felügyeletét ellátja a Tivoli és a HP Openview eszközökkel. A 7x24 órás támogatást a KFKI Csoport call center-e biztosítja. 1.4.2. Az ajánlás Mindezen elvárások figyelembevételével első körben - ajánlást dolgoztunk ki, melynek a következő céljai voltak: Központi felügyelet (Help-desk) koncepció kialakítás Üzemeltetési feladatok számba vétele és végrehajthatósági feltételek meghatározása Lehetséges feladat megosztási koncepciók kialakítása Szükséges támogató technológiák kiválasztásának előkészítése Probléma és változáskezelési eljárási elvek rögzítése Globális költség modellek felvázolása Ennek keretében javaslatunk alapvetően az MFG/PRO alkalmazás és az ahhoz kapcsolódó alkalmazások, informatikai infrastruktúra és számítógéppark biztonságos és jól szervezett üzemeletetetési szolgáltatás feltételrendszerének kialakítását célozta meg: Help-desk szolgáltatás Hibaelhárítási szolgáltatás 17
Üzemviteli szolgáltatás Rendszerfelügyeleti szolgáltatás Támogató szolgáltatás körébe tartozó feladatokat az: MFG/PRO alkalmazás Egyéb támogató alkalmazások (Oracle, Infosys, Variant) és adatbázisaik Szerverek és operációs rendszereik Lokális és országos hálózat Desktop eszközök és nyomtatók területére. Ennek keretén belül értelmeztük a: konfigurációkezelési (hw, sw hálózati és alkalmazás elemek állapot követése) problémakezelési változáskezelési verziókezelési eljárásokat. A melléklet táblázat foglalja össze rendszer felügyelet és hibajavítás keretében elvégzendő feladatokat. INPUT ACTIVITY OUTPUT CONFIGURATION MANAGAMENT SW library SLA Configuration DB ERROR MANAGAMENT monitoring event effect error detect correct lezárás support uncovering CHANGE MANAGAMENT develop mentmaintenance demand of change demand of change allowance execution execution VERSION MANAGAMENT upgrade layout preparation of decision demand of change decision execution execution CAPACITY MANAGAMENT expect of business expect of technology demand of change allowance execution execution 18
1.4.2.1. Javasolt üzemeltetési modell Az üzemeltetési szolgáltatás alapját az ügyfélszolgálati és eszkalációs eljárás képezi. Az ügyfélszolgálati modell tartalmazta az üzemeltetéshez kapcsolódó Nutricián belüli és a társszolgáltatóknál kialakítandó munkakörök (szerepkörök) feladatait és kapcsolatrendszerét. Ügyfélszolgálat lehetséges felépítési modellje VDB RDB VTT Szolgáltatás menedzser Szolgáltatás menedzser Nutricia Jelentések, statisztikák KFKI ISYS Jelentések, statisztikák EX3 IN 2 HD2 EX3 FRIESLAND Üzleti folyamat felelõs - Supervisor MFG Rendszerfejlesztõ QAD Answare Center Nutricia KFKI ISYS EX3 IN 0-2 HD 2 EX 0-3 Data Center IT menedzsment Alkalmazás / Adatbázis adminisztrátor LAN Hálózatadminisztrátor KFKI ISYS Kiemelt telephely EX3 WAN szolgáltató I. Help- Desk / Szervíz Kiszállás IN2 IN 0-1 Üzleti folyamat felelõs Nutricia Esemény Rendszergazda Nutricia Riasztás/értesítés Jelentés HD2 Szerver felügyelet EX3 IBM Help-Desk / szervíz / Answare Center EX3 Esemény Esemény Kulcsfelhasználó Nutricia Végfelhasználó Nutricia Esemény Esemény EX 0-1 WAN szolgáltató II. Help- Desk / Szervíz Ellátó depó DC szerver-adminisztrátor monitorozás, végrehajtás IN2 VTT VDB RDB Változásügyi Tanácskozó Testület Változásügyi Döntőbizottság Rendkívüli Döntőbizottság Kulcsfelhasználó Nutricia Esemény Végfelhasználó Rendszergazda Nutricia Esemény HL0-1 Help-Desk Esemény HL 0 Hotline 0. szintű támogatás Esemény: főidő Nutricia E-mail HD 1 Help-Desk 1. szintű támogatás Ellátott depó IN 2 Saját szakértő 2. szintű támogatás Monitoring EX 3 Külső szakértő 3. szintű támogatás Kulcsfelhasználó Végfelhasználó Konfigurációs adatbázis Eljárás SLA SW könyvtár 19
1.4.2.1.1. Help-Desk A rendszer középpontjában egy Help-Desk szolgáltatás áll. Ez a 24 órás szolgáltatás fogadja az összes IT technológiával és az alkalmazással kapcsolatos bejelentést. Olyan Help-Desk szolgáltatás üzemeltetését javasoltunk, amit mind a Nutricia, mind az alkalmazás felügyeletet ellátó szolgáltató személyzete elér, és mint közös és egységes információ bázist használ. A hibajelenségek egy ilyen összetett, sokkomponensű rendszerben, gyakran csak a teljes informatikai struktúra és ezek állapotváltozásainak komplex vizsgálatával értékelhetők, sokféle szakmai kompetencia együttes munkája is szükségessé válhat. A gyors és pontos információ cseréhez és tájékoztatáshoz egy központosított szakmai információ központ üzemeltetése feltétlen szükségessé vált, egyben jelentős szerepet kapott a szolgáltatók munkájának koordinálásában is. 1.4.2.1.2. Alkalmazástámogatás A Nutriciában kialakításra került egy a végfelhasználók számára elérhető szakmai kérdésekben és rendszerhasználatban támogatást nyújtó eljárás. A logisztikai és pénzügyi, adminisztratív területen dolgozó kulcsfelhasználók közvetlenül segítik a végfelhasználók munkáját; a logisztikai dolgozók 3 műszakos, a pénzügyi, kereskedelmi, marketing, export-import munkatársak 1 műszakos beosztásban. A kiemelt problémákat és a változás kezelés körébe tartozó feladatokat 10 fős üzleti folyamat felelős supervisor team támogatja és ez a team végzi a döntés előkészítő munkákat is. A Nutricia munkáját segíti a KFKI ISYS MFG/PRO alkalmazást támogató szervezete, ami a bejelentéseket a Help-Desken keresztül 24 órán keresztül fogadja, és a kidolgozott eszkalációs rend szerint, a problémák kritikusságának függvényében, ha szükséges azonnal megkezdi a hiba kivizsgálását és elhárítását. 1.4.2.1.3. IT-technológia támogatása A Nutricia IT szervezetének munkatársai a lokális (regionális) és központi irodákból közvetlen kapcsolatban vannak a végfelhasználókkal, illetve kulcsfelhasználókkal. Minden hozzájuk bejelentett eseményt nyilvántartásba vesznek, és a saját hatáskörükben el nem végezhető feladatokat a Help-Desken keresztül eszkalálják, azaz bevonják a külső szolgáltatókat. A telefonon, mailen vagy egy Help-Desk támogató szoftverrendszerbe közvetlenül bejelentett eseményeket a Help-Desk ügyeleti munkatársai fogadják. Ugyancsak az ő feladatuk a kiépített monitoring rendszerek (hálózat és szerver és desktop monitoring) üzenteinek folyamatos értékelése. A bejelentett vagy a monitoring rendszeren keresztül észlelt események elsődleges kiértékelése után, az adott feladat ellátásra kijelölt szolgáltató riasztásra kerül. Ettől kezdve a riasztott szervezet felel a probléma megoldásért, de a Help-Desk munkatárs folyamatosan követi a javítási eseményeket, és szükség esetén tovább eszkalálja a problémát mindaddig, amíg a probléma le nem zárható. Help-Desk munkatársak az általuk el nem végezhető javítási feladatokat a riasztásos ügyeleti rendszerben dolgozó szakértőknek továbbítják, akik a hibaelhárítási felelősséget átvéve végzik munkájukat. Amennyiben szükségesnek tartják, az érvényes üzemeletetési szerződések szerint bevonják a társszolgáltatókat vagy a gyártók/szállítók ügyfélszolgálatát, szervizét a hibaelhárításba. A Nutriciánál a ügyfélszolgálati eljárás működtetéséért és a szükséges üzemeletetési szerződések kidolgozásáért, a Szolgáltatás menedzseri feladatokat ellátó vezető felel. 20