ITIL (IT Infrastructure Library) az
informatikaszolgáltatás módszertana
Készült: 2002. novemberében a Széchenyi-terv támogatásával Verzió: 3.1
Tartalom 1. VEZETŐI ÁTTEKINTÉS ......................................................................................................................................... 3 2. BEVEZETÉS .............................................................................................................................................................. 5 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.
AZ ITIL KIALAKULÁSA, FEJLŐDÉSE ÉS MAI HELYZETE .................................................................................... 5 A MÓDSZERTAN ÁTTEKINTÉSE ÉS ÉRTÉKELÉSE ................................................................................................ 8 IMPLEMENTÁLÁSI KÉRDÉSEK ......................................................................................................................... 13 A KIALAKULT DOKUMENTÁCIÓ ...................................................................................................................... 15 OKTATÁSI RENDSZER ..................................................................................................................................... 16 VIZSGÁZTATÁSI RENDSZER, NEMZETKÖZILEG ELISMERT DIPLOMÁK ............................................................. 17 A FELHASZNÁLÓI FÓRUMOK MŰKÖDÉSE ........................................................................................................ 17 KIKNEK LEHET HASZNOS AZ ITIL? ................................................................................................................ 17
3. ELŐKÉSZÍTÉS: AZ ÖTLETTŐL A SZERZŐDÉSIG........................................................................................ 18 3.1. 3.2. 3.3. 3.4. 3.5. 3.6.
AZ INFORMATIKA, MINT SZOLGÁLTATÁS ....................................................................................................... 18 BIZALOM ÉS KÉTSÉG ...................................................................................................................................... 23 ÚT A DÖNTÉSHEZ ........................................................................................................................................... 24 DÖNTÉS ......................................................................................................................................................... 32 FELADATOK KIDOLGOZÁSA ........................................................................................................................... 33 SZERZŐDÉSKÖTÉS .......................................................................................................................................... 36
4. MÓDSZERTANI ÖSSZEFOGLALÓ .................................................................................................................... 39 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9. 4.10. 4.11. 4.12.
ÁTTEKINTÉS .................................................................................................................................................. 39 ÜGYFÉLSZOLGÁLAT....................................................................................................................................... 42 KONFIGURÁCIÓKEZELÉS ................................................................................................................................ 43 INCIDENSFELÜGYELET ................................................................................................................................... 47 PROBLÉMAKEZELÉS ....................................................................................................................................... 50 VÁLTOZÁSKEZELÉS ....................................................................................................................................... 52 KIADÁSKEZELÉS ............................................................................................................................................ 54 SZOLGÁLTATÁSI SZINT MENEDZSMENT.......................................................................................................... 57 KAPACITÁS MENEDZSMENT ........................................................................................................................... 61 INFORMATIKASZOLGÁLTATÁS PÉNZÜGYI IRÁNYÍTÁSA .................................................................................. 63 RENDELKEZÉSREÁLLÁS MENEDZSMENT ........................................................................................................ 66 INFORMATIKASZOLGÁLTATÁS-FOLYTONOSSÁG IRÁNYÍTÁSA ........................................................................ 69
5. ESETTANULMÁNYOK ......................................................................................................................................... 74 5.1. 5.2. 5.3. 5.4. 5.5.
EGY ONLINE SZAKMAI INFORMÁCIÓS RENDSZER ÜZEMELTETÉSE ................................................................. 74 VEVŐSZOLGÁLATI RENDSZER KIALAKÍTÁSA ÉS A SZOLGÁLTATÁSMENEDZSMENT TÁMOGATÁSA .................. 78 AZ INFORMATIKAI INFRASTRUKTÚRA ÜZEMELTETÉS KISZERVEZÉSE ............................................................. 83 EGY ALKALMAZÁSÜZEMELTETÉS FELÜGYELETÉT ELŐKÉSZÍTŐ PROJEKT ....................................................... 88 KISZERVEZÉS ITIL ALAPJÁN.......................................................................................................................... 96
6. FEJLESZTÉS ÉS FELÜLVIZSGÁLAT.............................................................................................................. 101 6.1. 6.2.
SZOLGÁLTATÁSFEJLESZTÉS ......................................................................................................................... 101 HELYZETFELMÉRÉS ..................................................................................................................................... 110
A.
FÜGGELÉK: GYORS, KÉRDŐÍVES ÖSSZEMÉRÉS AZ ITIL-LEL ....................................................... 121
B.
FÜGGELÉK: ITIL TERMINOLÓGIA DEFINICIÓK................................................................................. 139
C.
FÜGGELÉK: ANGOL-MAGYAR ITIL-SZÓTÁR ....................................................................................... 165
D.
FÜGGELÉK WWW.ITSMF.HU WEB-TARTALOM .................................................................................. 171
2
1. Vezetői áttekintés A hazai vállalatok üzleti sikerességének és versenyképességének egyik fontos feltétele, hogy üzletvitelük informatikai támogatása folyamatosan a kor színvonalának megfelelő és hatékony legyen. Ma már általánosan felismert, hogy ehhez nemcsak egyre újabb és egyre integráltabb informatikai alkalmazások kellenek, hanem olyan vállalati szintű informatikai ill. infokommunikációs architektúra és erre épülő informatikaszolgáltatási kultúra kialakítása is szükséges, amely rugalmasan tud alkalmazkodni a változó üzleti elvárásokhoz és hatékonyan képes a vállalat üzleti céljait informatikai megoldásokkal kiszolgálni. Ennek a tanulmánynak alapvető célkitűzése, hogy elősegítse az informatikaszolgáltatás nemzetközi szinten bevált és mértékadónak tekintett gyakorlatának hazai elterjedését, és, hogy ezzel is támogassa az informatikai rendszerek működtetési kultúrájának fejlődését. A tanulmány egyes fejezetei ezért önállóan is érthető dokumentumok, amelyekből a különböző érdeklődésű és felkészültséggel rendelkező olvasók igényük szerint kaphatnak tájékoztatást és információt az ITIL módszertanról, az informatikaszolgáltatás irányításának korszerű, nyílt és nemzetközileg elterjedt megközelítéséről. A Bevezetés c. fejezet az ITIL kialakulásáról, mai helyzetéről, lényegéről, dokumentációjáról és oktatásáról kísérel meg egy áttekintő képet adni, hogy segítse az olvasó eligazodását. Az Előkészítés: az ötlettől a szerződésig c. fejezet hasznos tudnivalókat és közvetlen tanácsokat tartalmaz mindazok számára, akiknél már felmerült az igény, ill. lehetőség a vállalat informatikai igényeinek radikálisan új módon – külső erőforrások egyre növekvő mértékű bevonásán keresztül – történő kielégítésére. Az informatika korábban egyoldalúan hardverközpontú szemléletét hazánkban is fokozatosan felváltja az informatika szolgáltatásorientált felfogása: a vállalatvezetőket, a felhasználókat egyre inkább az a közvetlen haszon érdekli, amit az informatika adni tud, és nem tereli el erről figyelmüket a háttérben működő, komplex műszaki rendszerek feltétlen csodálata. Ha azonban az informatika lényege nem a tárgyi eszközökben testesül meg, akkor nem is kell feltétlenül birtokolni azokat (és ezzel működtetésük teljes anyagi és szakmai felelősségét is magunkra venni), hanem elegendő a hozzáférést biztosítani ezekhez az eszközökhöz és megoldásokhoz. Az ötlet tehát egyszerű. Az út azonban rögös – legalábbis az olyan jól működő szerződések megkötéséig, amelyekkel a belső informatika megfelelő szintű kiszervezése, és ezzel egyidejűleg külső informatikai erőforrások hatékony bevonása lehetővé válik. E fejezet elsősorban azoknak szól, akik kerülő utak és zsákutcák nélkül, biztonságosan akarnak ezen az úton végigmenni. De mellesleg az is kiderül, hogy út közben hogyan segítheti térképként az ITIL a tájékozódást. A Módszertani összefoglaló c. fejezet tömör leírást ad a módszertan fő folyamatairól és fogalmairól, azok egymással való kapcsolatáról. Egyfajta zsebkönyv ez, amely egyaránt segítheti az első ismerkedést, és szolgálhat a mélyebb ismeretek elsajátítása után emlékeztetőül, felfrissítve a tanultakat. Az Esettanulmányok c. fejezet néhány konkrét esetet mutat be, ahol az informatikai rendszer vagy infrastruktúra üzemeltetését, működtetését kellett megszervezni. Ennek során alkalmazták a módszertan egyes elemeit, figyelembe vették, vagy éppen figyelmen kívül hagyták annak ajánlásait. Az alkalmazás pozitív vagy negatív tapasztalatai, nehézségei segíthetnek az olvasónak, amikor egy ilyen bevezetési, alkalmazási szituációban a módszertan egyes elemeit az adott konkrét helyzetben akarja használni. Az esettanulmányok jól mutatják, hogy az ITIL nem dogma, alkalmazása nem öncél. Mindig abból a szempontból kell nézni, hogy segíti-e az üzlet vagy szervezet igényeinek jobb kielégítését. Ugyanakkor, mint minden bevált gyakorlatnál, a sikertelen bevezetés oka nem a módszertanban (hiszen azt sokan sikerrel alkalmazták), hanem az
3
zetés oka nem a módszertanban (hiszen azt sokan sikerrel alkalmazták), hanem az alkalmazó testreszabási képességében keresendő. A Fejlesztés és felülvizsgálat c. fejezet az informatikaszolgáltatás fejlesztésével és felülvizsgálatával foglalkozik. Az ITIL kiemelt jelentőséget tulajdonít egy működő informatikaszolgáltatás folyamatos javításának, fejlesztésének. A folyamatos javítás programja megkívánja, hogy időnként egy felülvizsgálat keretében megállapítsuk, hol tartunk, milyen érettségi szintet értünk el a szolgáltatás szinvonalában, annak irányításában. A fejezethez mellékelt A. függelék: Gyors, kérdőíves összemérés az ITIL-lel c. részben megadunk egy felmérési kérdőívet, amelynek megválaszolásával elvégezhető egy gyors összemérés az ITIL-el. A B. függelék: ITIL terminológia definiciók megadja a leggyakrabban használt fogalmak meghatározását. Ezzel egyben kiinduló javaslatot is teszünk a magyar nyelvű terminológiára, amelyet később folyamatosan lehet javítani és fejleszteni a felhasználói fórum közreműködésével. A C. függelék: Angol-magyar ITIL-szótár megadja az angol terminológia magyar megfelelőit, ahol szükséges, két vagy három alternatív jelentéssel, hogy a magyar nyelvű leírásokban minél kifejezőbb fogalmakat lehessen használni. A tanulmány maga is él ezekkel az alternatív kifejezésekkel. Végül a D. függelék www.itsmf.hu web-tartalom ismerteti a megszervezés alatt álló Informatikai Szolgáltatásmenedzsment Fórum kísérleti címlapjának fő céljait és tartalmát. A fenti webcímre kattintva közvetlenül és folyamatosan tájékozódni lehet a Fórum szerveződéséről és működéséről.
4
2. Bevezetés
2.1.
Az ITIL kialakulása, fejlődése és mai helyzete
2.1.1.
Előzmények
Az információtechnológia terjedésével mind az infrastruktúra, mind az informatikai rendszerek egyre mélyebben épültek be a vállalatok, intézmények működésébe. Ezek működtetése, üzemeltetése hosszú időre nyúlik vissza és a tapasztalatok műszaki területen vissza is hatottak a számítástechnika fejlődésére (gondoljunk az operációs rendszerek fejlődésére). A 80-as években azonban új jelenséget figyelhetünk meg, a vállalatok, intézmények kezdenek függő helyzetbe kerülni az információtechnológiai rendszerektől, illetve az azok által biztosított szolgáltatásoktól. Ez a függőség persze azelőtt is létezett, de mértéke és elterjedtsége kisebb volt, így az üzemeltetés a számítástechnika belügye, annak egyik részterülete volt. A felmerült problémára adott egyik válasz angol kormányzati kezdeményezésre és támogatással született. A CCTA (Central Computer and Telecommunication Agency - Központi Számítástechnikai és Távközlési Ügynökség1) támogatásával elindítottak egy programot, amely egy egységes szerkezetben próbálta meg dokumentálni a jó és sikeres gyakorlatot (best practice). Ez a dokumentáció sorozat, az IT Infrastructure Library (ITIL), IT Infrastruktúra Könyvtár, azzal a céllal gyűjtötte össze és írta le a bevált gyakorlati tapasztalatokat, hogy azokat felhasználva a kormányzati területen javítsák az informatikai infrastruktúra működtetését. A sorozatban több mint 40 kötet látott napvilágot és ez lett az alapja és névadója a kialakult módszertannak. Az ennek nyomán megszületett brit kormányzati ajánlás a 10 legfontosabb témakört kiválasztva hozta létre ITIL néven azt az informatikai szolgáltatásirányítási, üzemeltetési módszertant, amely az óta „de facto” nemzetközi szabvánnyá vált. A módszertan létrehozásának első lépése a kiválasztott területek, folyamatok leírása volt, ez tekinthető az ITIL első változatának. A dokumentált és ajánlott gyakorlatnak létrehozták az oktatási és vizsgáztatási rendszerét is, melynek akkreditálásáért az ISEB (Information Systems Examination Board) lett a felelős.
2.1.2.
Felhasználói fórumok
Egy dokumentált módszertan, amely az összegyűjtött jó és bevált gyakorlaton alapul, úgy működik, mint egy modell. Egy modell megalkotásakor a kezelhetőség érdekében elhanyagolásokat, egyszerűsítéseket kell végezni, amelyeket a tervezés végén figyelembe kell venni. A módszertan a konkrét esetektől elvonatkoztatott, közös és általános tulajdonságokat emeli ki. Amikor egy módszertant alkalmazunk, mindig számításba kell venni a konkrét körülményeket, azaz a módszertant „testre kell szabni”. Erre lehet ugyan ajánlásokat tenni, de nagyon fontos az alkalmazások során szerzett tapasztalatok figyelembe vétele. Ezeknek a tapasztalatoknak a cseréjét, közzétételét szolgálják a felhasználói fórumok. Az ITIL felhasználói is létrehoztak ilyen fórumokat. Az első fórum, az IT Service Management Forum Nagy-Britanniában jött létre 1991-ben. A Fórum tagjai rendszeres szemináriumokon és konferenciákon tették közzé az ITIL alkalmazása során szerzett tapasztalataikat. A Fórum független, csak a felhasználók által irányított szervezet, amely a gyakorlati tapasztalatok cseréje mellett az ITIL elterjedésének támogatását is célul tűzte ki. A Fórum munkájában természetesen nemcsak a felhasználók, hanem a szolgáltatók is részt vesznek, a konferenciákon azonban a szolgáltatók nem reklámozhatják magukat direkt módon. Erre a
1
A mai utódszervezet neve és rövidítse: Office for Government Commerce (OGC)
5
konferenciák mellett megrendezett kiállítás szolgál, ahol az oktató, konzulens vagy támogató szoftver eszközöket szállító szolgáltató cégek bemutathatják kínálatukat. Az természetesen megengedett, hogy a szolgáltató cégek is tartsanak előadásokat ezeken a konferenciákon, és képviselőik részt vehetnek a Fórum munkájában, de ott nem a saját cégüket képviselik, hanem a Fórumot.
2.1.3.
Elterjedés
Az ITIL először az angol kormányzat és közigazgatás területén terjedt el. Az elterjedésben természetesen közrejátszott, hogy kormányzati ajánlás lett és a közigazgatási területen általában megkövetelték az alkalmazását. Mivel a gyakorlati alkalmazás tapasztalatai kedvezőek voltak, a módszertant a piaci környezetben is egyre inkább használni kezdték és mára „de facto” szabvánnyá vált. Az ITIL-t egyre inkább használni kezdték a szigetországon kívül is. Egyre több országban alakultak helyi Fórumok, ezek összefogására létrejött az IT Service Management Forum International, amely a nemzeti fórumokon keresztül egyrészt segítette az ITIL terjedését, másrészt ügyelt arra, hogy az egységes maradjon. A második nemzeti fórum Hollandiában alakult ki, ahol az EXIN informatikai oktató és vizsgaközpont lett a módszertan hivatalos gazdája (hasonlóan a CCTA/ISEB szerepéhez), és az itSMF Hollandia a holland felhasználók fóruma. Mivel az ITIL Hollandiában is „hivatalos, ajánlott” módszerré vált, az ITIL diplomákat itt is gyakran megkövetelik, sok tenderfelhívásban az ITIL megfelelőséget pályázati feltételkén írják elő. A kilencvenes évek második felében néhány évig az IT Service Management International is hollandiai székhellyel működött. Azóta több országban alakult nemzeti fórum, így az Egyesült Államokban, Kanadában, a Dél-Afrikai Köztársaságban, Ausztráliában, Németországban, Svájcban, Ausztriában.
2.1.4.
AZ ITIL Magyarországon
Ismereteink szerint az ITIL dokumentáció először az MTA KFKI könyvtárában, majd a MATÁV informatika üzemeltetés szervezeténél jelent meg, mint szakkönyv gyűjtemény. Később a Miniszterelnöki Hivatal támogatásával, - amely a CCTA-val jó kapcsolatokat épített ki, - az MTA Információtechnológiai Alapítvány munkatársainak közreműködésével 1996-ban az Informatikai Tárcaközi Bizottság kormányzati ajánlásként elfogadta. Az itSMF konferenciáin rendszeres a magyar részvétel. Ez a tanulmány is azt a célt szolgálja, hogy széles körben ismertté tegye, áttekintő képet adjon kialakulásáról, helyzetéről, lényegéről és használatáról.
2.1.5.
Az ITIL megújított, második változata
Az első tíz év tapasztalatai és az informatika szerepének növekedése a vállalatok, intézmények működésében felvetették a módszertan megújításának szükségességét. A CCTA, majd az OGC (Office of Government Commerce), amelybe a CCTA 2001-ben beolvadt, támogatta ezt a megújítást. Az új változat kidolgozásában a Fórum és a szolgáltatók képviselői, szakértői aktívan részt vettek. A dokumentáció két kötetben, a Service Delivery és a Service Support kötetekben 2000ben került kiadásra, amelyek eggyel több, összesen 11 szakterületet, folyamatot írnak le megújított tartalommal. Az első változathoz képest kettébontották a Help Desk (segélyszolgálat) témakört Service Desk (ügyfélszolgálat) és Incident Management (incidensmenedzsment) témakörökre. A megújítás során további kiegészítő köteteket is meghatároztak, amelyek közül, azóta több meg is jelent.
2.1.6.
Mai helyzet
Az ITIL mára „de facto” nemzetközi szabvánnyá vált, amelynek több országban működik felhasználói szervezete, meghatározó módszertanná vált az informatikai infrastruktúra és informatikaszolgáltatás irányítása területén. Az ITIL-t számos nemzetközi informatikai cég is elfogadta és támogatja, így pl. a Hewlett Packard, Microsoft, IBM stb. Ezek a cégek saját gyakorlatukba beépítették az ITIL terminológiáját és megközelítését. Sok szolgáltató, amely támogató szoftver eszközöket kínál, igyekszik azokat ITIL konformmá tenni, hogy ezzel is javítsa piaci pozícióját.
6
2.1.7.
Magyar helyzet
Az utóbbi években Magyarországon is megnőtt a vállalatok, intézmények informatika függősége, és egyre nagyobb szerepet kap a működtetés megszervezése, irányítása, menedzsmentje. Megjelent az informatikai rendszerek kiszervezésének igénye is (outsourcing). Egyre több szolgáltató hivatkozik az ITIL-re, vagy alkalmazza annak elemeit. Terjed a szolgáltatási megállapodások (SLA-k) megkötése, a Help Desk alkalmazása gyakori lett. Nem járunk messze az igazságtól, ha azt mondjuk, hogy megérett a helyzet, hogy az ITIL bevált gyakorlatát ne csak részeiben, hanem teljes összefüggésében alkalmazzuk. A felhasználók elemi érdeke, hogy a működésüket támogató informatikaszolgáltatást kézben tartsák, irányításuk alá vonják. A szolgáltató szervezetek - legyenek akár belső, akár külső szolgáltatók – érdeke, hogy létezésüket és költségeiket indokolják azzal, hogy a szervezet működéséhez minél magasabb hozzáadott értékkel járuljanak hozzá, elősegítve azok üzleti sikerét, versenyképességét stb. Az ITIL terjesztése ma kultúra teremtés is, ismertté kell tenni a lényegét, a használt terminológiát, meg kell teremteni az oktatást és közzé kell tenni az alkalmazásának tapasztalatait. Jó lenne megújítani a kormányzati ajánlást és ösztönözni a szakképzettség megszerzését. Ma azt tapasztaljuk, hogy azok, akik bőrükön érzik az informatikai rendszerek és az infrastruktúra működtetésének gondját, érdeklődnek használható, bevált gyakorlatok iránt, és ha már hallottak az ITIL-ről, akkor az ITIL iránt is. Megérett a helyzet egy magyar Informatikai Szolgáltatásmenedzsment Fórum létrehozására is, amely segíthetne az ismeretterjesztésben és a gyakorlati tapasztalatok megosztásában. Úgy látjuk, hogy ez a kultúrateremtés a szolgáltatói oldalnak is érdeke, mivel a működtetési szolgáltatások piacán piacgeneráló szerepe lehet.
7
2.2.
A módszertan áttekintése és értékelése
2.2.1.
Mi az informatikai szolgáltatásmenedzsment
Az informatikai szolgáltatásmenedzsment egymással együttműködő folyamatok együttese, amelynek feladata, hogy az ügyféllel megállapodott szolgáltatási szinteken biztosítsa az informatikaszolgáltatás minőségét. Az ITIL módszertan leírja és definiálja a kulcsfolyamatokat és egy keretet az informatikaszolgáltatás irányítására. Ez a keret segítheti egy informatikai szervezetben a folyamatok azonosítását és megvitatását. Azáltal, hogy a figyelmet az egyes folyamatok összehangolására és meghatározására összpontosítja, az informatikai szervezet azonosíthatja a hatékonyság javítására adódó lehetőségeket, amely javíthatja a szervezet azon képességét, hogy jobban menedzselje a szolgáltatásbiztosítást és a szolgáltatások minőségét.
2.2.2.
A szolgáltatásmenedzsment filozófiája
A szolgáltatásmenedzsment három fő célkitűzése a következő: •
Az informatika szolgáltatását hozzá kell rendelni a jelen és jövő üzleti igényeihez és felhasználóihoz.
•
Javítani kell a nyújtott informatikaszolgáltatás minőségét.
•
Csökkenteni kell a szolgáltatások hosszú távú költségét
Az informatikát már hosszú ideje használjuk, de az Internet elterjedése sok szervezet számára megmutatta, hogy „az informatika üzlet és az üzlet informatika” Ezért lényeges felismerni a legtöbb üzleti szervezet erős vagy teljes függőségét az információs és távközlési technológia infrastruktúrájától és az általa nyújtott információ mennyiségétől, minőségétől és a rendelkezésreállásától. A kihívás, amellyel a mai informatikai vezetőknek szembe kell nézni, hogy össze tudják hangolni az informatikát az üzlettel, és partneri együttműködést alakítsanak ki vele, új üzleti lehetőségek megteremtése érdekében. Ezt úgy kell elérniük, hogy közben csökkentik az informatika teljes költségét. E cél elérésének fő módszere az irányítási és támogatási általános költségek csökkentése, miközben új üzleti modelleket dolgoznak ki az üzletnek nyújtott szolgáltatások minőségének megőrzésére és javítására. Hogy ezt megtegyék, létre kell hozni, és be kell vezetni a megfelelő üzleti és informatikai folyamatokat. Az informatika irányítása az emberek, a folyamatok és a termékek (eszközök és technológia) hatékony és hatásos használatáról szól. Az ITIL filozófiája folyamatorientált megközelítést alkalmaz, amely méretezhető és alkalmazható mind a kis, mind a nagy informatikai szervezetekre. A szolgáltatásmenedzsmentet szorosan ösz-
8
szefüggő, magasan integrált folyamatok rendszerének tekinti. Annak érdekében, hogy a szolgáltatásmenedzsment megvalósíthassa fő célkitűzéseit, e folyamatoknak hatékonyan, hatásosan és gazdaságosan kell használni az emberi erőforrásokat és a termékeket, miközben biztosítania kell az üzleti folyamatokkal összehangolt, minőségi és innovatív informatikaszolgáltatást.
2.2.3.
Az informatikai szolgáltatásmenedzsment részei
Az informatikai szolgáltatásmenedzsment az összefoglaló neve azoknak a folyamatoknak és eljárásoknak, amelyek egy szervezet üzleti, működési igényeit jó minőségben kielégítik és támogatják. Az ITIL a szolgáltatásmenedzsmenthez tartozó témaköröket két fő csoportba szervezte:
Szolgáltatásbiztosítás Szolgáltatási szint menedzsment Rendelkezésreállás menedzsment Informatikaszolgáltatás-folytonosság menedzsment Kapacitásmenedzsment Informatikaszolgáltatás pénzügyi irányítása
Szolgáltatástámogatás Ügyfélszolgálat Incidensmenedzsment Problémamenedzsment Változáskezelés Konfigurációkezelés Kiadáskezelés A szervezeteknek testre kell szabni, és be kell fogadni ezeket az eljárásokat, hogy képesek legyenek kielégíteni a saját egyedi helyzetükből adódó követelményeket. A fenti témakörök részletesebb leírását „Az ITIL összefoglalása” című fejezetben tesszük meg, itt csak rövid leírásokat adunk. Ez alól csak a szolgáltatási szint menedzsment esetén teszünk kivételt, mert úgy érezzük, hogy egy jó áttekintéshez ez nélkülözhetetlen. 2.2.3.1. Szolgáltatásbiztosítás: 2.2.3.1.1.
Szolgáltatási szint menedzsment
A szolgáltatási szint menedzsment az a folyamat, amely a szolgáltatási megállapodásban (SLA) dokumentált célokkal az ügyfélnek nyújtott szolgáltatások szintjeit meghatározza, egyezteti, megállapodik róluk, majd implementálja, figyeli, folyamatosan értékeli és menedzseli azokat. A szolgáltatási megállapodás egy olyan írásbeli egyezmény a szolgáltatás felhasználója és a szolgáltatást biztosító szervezet között, amely mérhető módon definiálja a szolgáltatási célokat, a 9
felelősségeket és elvárásokat mindkét fél vonatkozásában. A mérhetőség teremti meg az ellenőrzés, visszacsatolás, tehát az irányítás lehetőségét. A 90-es évek elején, amikor az SLA-k divatosak lettek, sok informatikai szervezet ment el abba az irányba, hogy szolgáltatási megállapodást hozott létre, de úgy kezelte azt, mint különálló folyamatot. Ezen korai kezdeményezések legtöbbje elbukott, különösen osztott rendszerkörnyezetek esetében. Ennek az volt az oka, hogy nem léteztek azok a folyamatok, amelyek szükségesek a konzisztens, megbízható és megjósolható szolgáltatásbiztosításhoz. Az SLA kezdeményezések elbuknak, ha az informatikai szervezetnek nincs módja azoknak a tényezőknek a hatását mérni, megfigyelni és megérteni, amelyek a szolgáltatást megszakítják (pl: a változások) és ha nem megfelelő felhasználói elvárásokat állítanak föl. Egy ilyen megközelítés eredménye mindig a szolgáltatási megállapodások és a szolgáltatási szint menedzsment folyamat diszkreditálása lesz. A szolgáltatási szint menedzsment a fő hajtóerő a folyamatos javításban továbbá az ügyféllel folytatott folyamatos kommunikáció egyik eszköze, és mint ilyen, erősen függ más támogató folyamatoktól. A szolgáltatási szint menedzsment önmaga nem tudja megoldani a problémát, ha a javulás, amit el kellene érni, sokkal lényegesebb, mint egy látszatjavítás. A vállalatoknak ahhoz, hogy effektív szolgáltatási szint menedzsmentet végezzenek, a következő definiált és megfelelően érett integrált folyamatokra van szüksége: változáskezelés, konfigurációkezelés, incidensmenedzsment, problémakezelés, rendelkezésreállás menedzsment, kapacitásmenedzsment, és kiadáskezelés. Támogató folyamatok nélkül a szolgáltatás megállapodott szintjeinek biztosítása nagyon véletlenszerű, nagyon esetleges. Pl. amikor egy alkalmazás új verzióját bocsátjuk ki, előfordulhat, hogy nem vizsgáljuk meg hatását a kapacitásokra, vagy más alkalmazásokra. Ez előre nem látható problémákat eredményezhet, amely a nyújtott szolgáltatások minőségét csökkenti, mivel reagáló tevékenységet igényel a proaktív, megelőző tevékenység helyett. A legtöbb hiba a szolgáltatási szint menedzsmentben rendszerint e támogató folyamatok gyengeségéhez kapcsolódik, sokkal inkább, mint a szolgáltatási szintek egyeztetéséhez, vagy monitorozásához. Ezekben a támogató folyamatokban lévő hibák azok, amelyek rendszerint azt a „tűzoltó” mentalitást eredményezik, mely gyakran áthatja az informatikai csoportokat. Hogyan tud az ITIL segíteni? Az ITIL erejének titka a szolgáltatási szint menedzsment teljes, holisztikus megközelítésében rejlik, amelynek során a szolgáltatási szint menedzsmentet integrálja a támogató folyamatokkal. Az ITIL egy integrált keretet biztosít, amelyen belül minden kulcsfolyamat definiálva van. Ami még fontosabb, hogy definiálva vannak e folyamatok belső összefüggései, kölcsönös kapcsolatai. Bármely informatikai szervezet, amely elhatározza, hogy implementálja, vagy javítja a szolgáltatási szint menedzsmentet, és a szolgáltatási megállapodást, annak ezen integrált keret környezetén belül kell ezt megtenni. Azok részére az ITIL nyilvánvaló és világos választás. Az informatikai szervezetnek e folyamatokhoz, mint egészhez kell mérni magukat, ahelyett, hogy csak magát a szolgáltatási szint menedzsmentet céloznánk meg. A szolgáltatási szint menedzsment folyamata maga, nagyon helyesen, nagy hangsúlyt helyez arra, hogy a szolgáltatási megállapodásokat üzemeltetési szint szerződésekkel (OLA - Operational Level Agreement), megállapodásokkal támogassa, melyeket más belső csoportokkal kötnek, azért hogy a szolgáltatási megállapodást támogassák, továbbá tartalmazza a külső szolgáltatókkal kötött megállapodásokat, melyek szintén szükségesek, hogy az ügyféllel kötött megállapodást betartsák. A szolgáltatási szint menedzsment hangsúlyozza az ügyféllel folytatott egyeztetés szükségességét, de nem igazán tartalmazza az ügyfélkapcsolat-menedzsment folyamatait és szerepköreit (bár ez az ITIL The Business Perspective kötetében meg fog jelenni). Szintén ajánlja a több szintű
10
szolgáltatási megállapodás használatát nagy szervezetekben, úgy mint vállalati, ügyfél és szolgáltatás szintekre, amely segít az szolgáltatási megállapodások méretét kézben tartani, csökkenti az ismétléseket, és remény szerint az aktualizálások gyakoriságát. A vállalatoknak azonban nem szabad alábecsülni a szükséges erőfeszítéseket és implementációs időt, különösen a szervezeti ellenállás legyőzését, ha egy integrált és hatékony szolgáltatási szint menedzsment stratégiát akarnak megvalósítani. Továbbá nem szabad figyelmen kívül hagyniuk semmilyen bevált folyamatot sem, melyet házon belül fejlesztettek. A rések integrálására és azonosítására kell figyelniük, miközben az ITIL keretet használják. Az ITIL keret gondosan definiálja a konfiguráció- és az eszköz-menedzsmentet. Mindamellett bizonyos informatikai eszköz-menedzsment funkcionalitást csak kívánatosnak tart (pl: a licencek és szerződések karbantartásával kapcsolatos jogi aspektusokat). 2.2.3.1.2.
Rendelkezésreállás menedzsmentje
Ez az informatikaszolgáltatás tervezési, implementálási és irányítási folyamataiból áll a rendszerek elérhetőségének magas szintjét biztosítandó, hogy kielégíthetőek legyenek a szervezet üzleti igényei. A rendelkezésreállás menedzsmentje számos kulcsfontosságú elemből áll. Ezek:
2.2.3.1.3.
•
Rendelkezésreállás
•
Megbízhatóság
•
Javíthatóság
•
Szervizelhetőség
•
Biztonság
•
Ellenállóképesség
Az informatikaszolgáltatás folytonosságának menedzsmentje
Az informatikaszolgáltatás-folytonosság kifejezést abban az értelemben használjuk, mint az üzletmenet-folytonosság tervezésének az informatikára vonatkozó részét. Tartalmazza a katasztrófa-elhárítás és az informatika előre nem látható helyreállítási tevékenységeit. Ezek a folyamatok határozzák meg a kockázatokat és a katasztrófákkal szembeni sérülékenységet, és megfelelő intézkedéseket foganatosítanak az üzletmenet folytonosságának biztosítására. 2.2.3.1.4.
Kapacitásmenedzsment
Ez biztosítja, hogy a szervezet mindig megfelelő informatikai kapacitással rendelkezzen, ugyanakkor minimális legyen a túlterhelés, illetve az alacsony kihasználtság. A nem kielégítő kapacitás rendszerint teljesítményproblémákat okoz, míg a fölösleges megdrágítja a szolgáltatás költségeit. A fő területei az üzleti, a szolgáltatási és infrastruktúra kapacitáskezelés. 2.2.3.1.5.
Az informatikaszolgáltatás pénzügyi irányítása
Minden olyan pénzügyi szemponttal foglalkozik, amely az informatikaszolgáltatás biztosításával és támogatásával kapcsolatos. Sok szervezet megpróbál egyensúlyt teremteni a költségek és költségterhelések (számlázások) között.
11
Három fő eleme van: a költségkeret tervezés, költségkimutatás és költségterhelés. 2.2.3.2. Szolgáltatástámogatás: 2.2.3.2.1.
Ügyfélszolgálat
Az ügyfélszolgálat célja, hogy egyetlen központi kapcsolati pontot biztosítson az ügyfél és az informatikai szolgáltatásmenedzsment között, kezelje az incidenseket és az igényeket, és kapcsolatot biztosítson a többi folyamathoz: a változás-, probléma-, konfiguráció-, kiadás-, szolgáltatási szint és az informatikaszolgáltatás-folytonosság menedzsmenthez. Eltérően a többi szakterülettől, amely folyamat, az ügyfélszolgálat egy funkció. Feladatai:
2.2.3.2.2.
•
központi hely legyen minden informatikai felhasználó számára
•
helyreállítani a szolgáltatást, amikor csak lehetséges
•
maximálni a szolgáltatás rendelkezésreállását
•
minden incidens kezelése a lezárásig
•
legyen tisztában az üzleti követelményekkel és az üzletmenetre gyakorolt hatással.
Incidensmenedzsment
Az incidensmenedzsment elsődleges célja zavar esetén a normál szolgáltatási feltételek visszaállítása, amilyen gyorsan az lehetséges, minimalizálva a üzleti tevékenységre gyakorolt káros hatását, így biztosítva a szolgáltatás minőségének lehetséges legjobb színvonalát. Tevékenységei a következők:
2.2.3.2.3.
•
az incidens detektálása és naplózása
•
osztályozás és kezdeti támogatás
•
hibakeresés és diagnózis
•
megoldás és helyreállítás
•
az incidens lezárása
•
az incidens birtoklása (gazdaszerep), megfigyelés, nyomkövetés és kommunikáció.
Problémamenedzsment
A problémamenedsment célja az informatikai infrastruktúrán belüli hibák által okozott incidensek és problémák üzleti tevékenységre gyakorolt káros hatásának a minimalizálása, és az ezekhez a hibákhoz tartozó incidensek ismételt előfordulásának a megakadályozása. Ennek a célnak az eléréséhez a problémakezelés az incidensek kiváltó okát keresi, és kezdeményezi azokat a tevékenységeket, amelyek az így kialakult helyzet javítását, helyreállítását eredményezik, illetve megelőzik annak jövőbeni ismételt előfordulását.
12
2.2.3.2.4.
Változáskezelés
A változás az a folyamat, amikor az egyik definiált állapotból a másik definiált állapotba mozdulunk el. A változáskezelés célja, hogy minden változás gyors és hatékony kezelésére szabványos módszerek és eljárások használatát biztosítsa annak érdekében, hogy a változással összefüggő incidensek szolgáltatás minőségre gyakorolt hatását minimalizálja, és következésképpen javítsa a szervezet napi működését. Az ITIL egyetlen, centralizált változáskezelési rendszert javasol a teljes informatikai infrastruktúra számára. Az ajánlás szerint ennek a rendszernek szorosan integrálva kell lennie a konfigurációkezelési rendszerrel. 2.2.3.2.5.
Konfigurációkezelés
A konfigurációkezelés annak a folyamatnak a neve, amely magában foglalja minden informatikai komponens azonosítását, rögzítését és jelentését, beleértve azok verzióját, alkotó részeit és kapcsolatait. A konfigurációs elemekre (CI) vonatkozó információkat a konfigurációkezelő adatbázisban (CMDB) tárolja, amelyet a szolgáltatásmenedzsment minden folyamata használ. 2.2.3.2.6.
Kiadáskezelés
A kiadás az informatikaszolgáltatás jóváhagyott változásainak halmazát írja le. A kiadáskezelés végzi a hardver és szoftver ütemezését, tervezését, építését, konfigurálását és tesztelését, hogy a kiadás komponensek egy készletét hozza létre a működő környezet számára. Tevékenységei ugyancsak lefedik egy kiadás több ügyfél és több helyszín számára történő tervezését, előkészítését és ütemezését.
2.3.
Implementálási kérdések
2.3.1.
A hajtóerők
Az alább felsoroltak képezik azokat az okokat, amelyek meghatározzák a magas színvonalú informatikaszolgáltatás iránti igényt és hajtóerőt jelentenek a szolgáltatásmenedzsment bevezetésében: •
A szervezetek egyre nagyobb mértében válnak függővé az informatikaszolgáltatástól
•
A hibák észlelhetőségének magasabb foka
•
A felhasználói igények pontosodása, konkrétabbá válása
•
Az infrastruktúra komplexitásának (bonyolultságának) növekedése
•
Az informatikaszolgáltatás költségterhei
•
Az ügyfelekért folytatott verseny
Tételezzük fel egy szolgáltatásjavító programot, egy projektet, amely fokozatosan növeli a szolgáltatási minőséget az ITIL irányelveknek megfelelően. Hogy ezt elérjük, egy „szolgáltatási kultúra” létrehozására van szükség az informatikai szolgáltató szervezet területén.
13
Ennek tartalmazni kell: •
Annak felismerését, hogy az informatikai szervezet azért van, hogy az adott szervezet üzleti céljait támogassa
•
Egy szervezeti küldetést (missziót), hogy a megállapodás szerinti minimális szolgáltatási szintet (vagy annál magasabbat) biztosítsa
•
Az ügyfél perspektívájának a megértése
•
Hajlandóság annak a plusz-lépésnek a megtételére, hogy kielégítse az ügyfél szükségleteit
•
A felső-vezetés támogatása
•
Annak a megértése, hogy miért nyújtják az informatikaszolgáltatást és a nem kielégítő szolgáltatás hatásának ismerete
•
Világos és mérhető célok, amelyek alapján a javítás iránya meghatározható.
Az informatikai szolgáltatásmenedzsment megvalósítását formális projektként kell kezelni és irányítását elismert projektvezetési módszerrel, – pl. PRINCE2 – célszerű végezni. A projekt lépései: •
Indítás
•
A figyelem felkeltése
•
Tervezés
•
Megvalósítás
•
Megvalósítás utáni áttekintés, értékelés
14
2.4.
A kialakult dokumentáció
ITIL – A szolgáltatásmenedzsment bevezetésének előkészítése
Ü z l e t v i t e l
Szolgáltatásmenedzsment Szolgáltatástámogatás Az üzleti nézőpont
Szolgáltatásnyújtás
Infokom infrastruktúra menedzsmentje
Biztonságmenedzsment
Alkalmazásmenedzsment
T e c h n o l ó g i a
1. ábra: Az ITIL dokumentációs rendszere
Szolgáltatástámogatás - Service Support A Service Support könyv az az ügyfélnek nyújtott szolgáltatások támogatásával kapcsolatos öt központi ITIL folyamatot írja le, az ügyfélszolgálati funkcióval együtt, amely a többi folyamatra támaszkodik. Szolgáltatásnyújtás - Service Delivery A Service Delivery kötet azt az öt fő ITIL folyamatot írja le, amelyek az üzletnek nyújtott szolgáltatások biztosításával kapcsolatosak, együtt az ügyfélszolgálati funkcióval, amely igénybe veszi a többi folyamatot. Az üzleti nézőpont - The Business Perspective A Business Perspective kötet szeretné megismertetni az üzletvezetést az üzleti folyamatok támogatásához szükséges informatikai és kommunikációs technológia összetevőivel és architekturális tervezésével, és elősegíteni az informatikai szolgáltatásmenedzsment szabványainak és bevált gyakorlatának megértését. Informatikai és kommunikációs technológiai infrastruktúra menedzsmentje – ICT Infrastructure Management Az ICT Infrastructure Management kötet tárgyalja az ICT infrastruktúra menedzsment minden aspektusát: az üzleti követelmények meghatározását, a tenderezés folyamatát, az infrastruktúra alkotórészeinek és az informatikaszolgáltatás egyes elemeinek a tesztelését, installációját, üzembe állítását, folyamatos támogatását és karbantartását.
15
Alkalmazásmenedzsment - Applications Management Az Applications Management kötet az alkalmazásmenedzsment tárgykörét dolgozza fel, a kezdeti üzleti igényektől az alkalmazásmenedzsment életciklusán keresztül egészen a megszüntetésig, beleértve a Service Delivery, Service Support és ICT Infrastructure Management. Kötetekben tárgyalt szolgáltatásirányítási szakterületekkel történő interakciót is. Biztonságmenedzsment - Security Management A Security Management kötet a étező ITIL folyamatokat bővíti biztonságmenezsmenttel. A biztonságmenedzsment folyamata, bár különálló, amennyire csak lehetséges, a többi folyamatba integrálódik. Ezen kívül, a bevált gyakorlatból származó intézkedéseket és irányelveket vezet be, hogy segítse a biztonságmenedzsment implementálását és működtetését. A BSI Code of Practice for Information Security Management (BS7799) brit szabványügyi kiadványt használja hivatkozásként. Az informatikai szolgáltatásmenedzsment gyakorlatának kódexe – A Code of practice for IT Service Management – PD0005 A Brit Szabványügyi Hivatal kiadványa, amely az ITIL elvein alapul, a szabványt magyarázó, annak alkalmazását elősegítő dokumentum. Az új ITIL modell a BSI modell kiterjesztésének tekinthető, amely továbbfejleszti az informatikai szolgáltatásmenedzsmentet. Az alábbi diagramm a PD0005 ábrázolása a szolgáltatás menedzsment folyamatairól:
Szolgáltatástervezési és –menedzsment folyamatok Biztonságmenedzsment
Szolgáltatási szint menedzsmentje
Rendelkezésre állás és vészhelyzet menedzsmentje
Szolgáltatásjelentés
Kiadási folyamatok
Kapacitásmenedzsment
Pénzügyi menedzsment
Szabályozási folyamatok Tárgyieszköz- és konfigurációkezelés Változáskezelés
Kiadáskezelés
Megoldási folyamatok Incidenskezelés Problémakezelés
Szállítói folyamatok
Ügyfélkapcsolat-kezelés Beszállítókezelés
Automatizálás 2. ábra: Az informatikaszolgáltatás menedzsmentjének folyamatai
2.5.
Oktatási rendszer
Az informatikai szolgáltatásmenedzsment oktatási rendszerét az Information Systems Examination Board (ISEB) szabályozta. Alapfokú és vezetői (menedzsment) szintű tanfolyamokat definiál, meghatározva azok tartalmát, minimális óraszámát, az oktatók képzettségét és a hivata16
losan elismert tanfolyamok akkreditálásának feltételeit. Az akkreditáció kiterjed az oktató cégre, az oktatókra és a tananyagra, amelyet a hallgatók megkapnak. Az alapfokú tanfolyamok 3 naposak, sikeres elvégzésük feltétele a vezetői szintű tanfolyamokon való részvételnek. Alapfokú tanfolyamok: ITIL Foundation Course, ITIL for Practitioners és a Network Management Course. A vezetői tanfolyamok a Service Delivery és a Service Support 5-5 naposak, amelyeket a vizsga előtt egy 1 napos ismétlést célzó áttekintő oktatás foglal össze.
2.6.
Vizsgáztatási rendszer, nemzetközileg elismert diplomák
Az alapfokú vizsga egy 40 kérdéses választásos tesztvizsga, amelyen az előírt minimális szint 65% (26 pont), ennek elérése esetén a vizsgázó megkapja az ITIL Foundation Certificate oklevelet, amely a vezetői tanfolyam és vizsga előfeltétele. Az ITIL Manager Certificate oklevél alapja egy kétszer 3 órás írásbeli vizsga, a Service Delivery és a Service Support témakörökben. A vizsgák hivatalos anyaga a Service Delivery és a Service Support könyvek teljes anyaga. Vizsgáztatást az ISEB-en kívül a holland EXIN is végez, ugyanolyan szabályok szerint, egyenértékű nemzetközi oklevél kibocsátásával. A vizsgáztatási jogot elvileg más országok intézményei is megszerezhetik, ha betartják azokat a szabályokat, amelyek garantálják az oklevelek színvonalának egységességét.
2.7.
A felhasználói fórumok működése
A felhasználói fórumok egységes alapszabály alapján működnek. Az alapszabályok betartását az itSMF International ellenőrzi. Ennek lényege, hogy a fórumok függetlenek, a tagságuk irányítása alatt működnek, non profit szervezetek és feladatuk a szolgáltatásmenedzsment ITIL módszertanának támogatása, alkalmazási tapasztalatainak megosztása és továbbfejlesztése. Az egyes nemzeti fórumok konferenciákat és szemináriumokat szerveznek, népszerűsítik a bevált gyakorlatot, és információval látják el tagságukat. A rendezvényeken a közvetlen reklámozás nem megengedett, de a rendezvények mellett rendezett kiállításokon szponzorálási díj ellenében a terméket vagy szolgáltatást kínáló cégek bemutathatják kínálatukat.
2.8.
Kiknek lehet hasznos az ITIL?
Az ITIL bevált gyakorlatának átvétele és alkalmazása mindenkinek ajánlott, aki működő informatikai rendszerei és infrastruktúrája által szervezetének nyújtott szolgáltatások minőségét kontrollálni és javítani akarja. Az ITIL nem dogma, rugalmasan, a szervezet igényeihez szabva lehet alkalmazni. Alkalmazható mind a nagy, mind a kis szervezetek informatikaszolgáltatásának irányítására.
17
3. Előkészítés: az ötlettől a szerződésig Az alábbi fejezetben megpróbáljuk összefoglalni mindazon szempontokat, amik segítik egy informatikaszolgáltatást nyújtó szakcég és az ezt igénybe vevő vállalatok közt a jó és tartós üzleti kapcsolat kialakítását. Felvázoljuk ezen kapcsolat szorosságának fokozatait, a szolgáltatás lehetséges típusait, és azt az utat, amíg a felek eljutnak a döntéshez, hogy milyen típusú szolgáltatás az, ami az ügyfélnek leginkább megfelel. Ez az út a kölcsönös megismerésről és az üzleti bizalom kiépítéséről szól, ami alapja lehet egy kölcsönösen előnyös szolgáltatási szerződés megkötésének. Ennek a folyamatnak elvi és módszertani alapját az ITIL (IT Infrastructure Library) módszertani ajánlás adja. Már a cégek közti együttműködés elején ajánlatos az ITIL-terminológia bevezetése, hogy a továbbiakban a felek között egy egyértelmű kommunikáció alakuljon ki. Mindkét fél tudja, hogy a másik mire gondol, amikor olyan kifejezéseket használ, mint: „problémamegoldás”, „konfigurációkezelés” vagy „eszkaláció”.
3.1.
Az informatika, mint szolgáltatás
Korunkban egyre elterjedtebb igény, hogy a vállalatok fókuszáljanak a saját alaptevékenységükre, és a profiltisztítás következtében felszabaduló erőforrásokat a piaci részesedés növelésére fordítsák. A vállalat akkor tud az alaptevékenységére (core business) koncentrálni, ha minden olyan feladatot átad szakcégeknek, ami nem tartozik az alaptevékenységéhez. Ezek közé tartozik a cég működését gyakran meghatározó és vezérlő, kiszolgáló ICT-vel (információ- és kommunikációtechnológia) kapcsolatos tevékenység is. „Csinálhatja–e ezt más is, mint mi?” - teszik fel a kérdést a vállalatvezetők. Járjuk körbe tehát ezt a kérdést!
3.1.1.
Jellemzők – hajtóerők
Vizsgáljuk meg mik azok a hajtóerők, amik miatt a cégvezetők gondolkodni kezdenek bizonyos informatikai feladatok kiszervezésén:
Stratégiai szempontok •
Az ICT gyors fejlődése állandóan változó lehetőségeket és elvárásokat támaszt a nem informatikai vállalatokkal szemben is. Ezen cégek a fejlődés követését úgy szeretnék biztosítani, hogy az ehhez szükséges szakértelmet és technológiát megveszik, hogy ne fenyegesse őket a gyors elévülés veszélye.
•
A vezetők jól tervezhető és ellenőrizhető informatikai költségeket szeretnének.
•
Nem akarnak hosszadalmas és azonnal nagy költségű informatikai projekteket. Helyette készen elérhető szolgáltatásokat kívánnak igénybe venni. Az informatikai költségek a folyamatos fejlesztési igény miatt nehezen tervezhetők és magas vállalati állandó költséget jelentenek.
•
Egy szolgáltató céggel kötött tartós kapcsolat lehetővé teheti a piaci változásokhoz gyorsan alkalmazkodó informatikai megoldások bevezetését, legyen az technikai vagy ügyviteli jellegű.
•
Az ügyfelek egyre kevésbé kívánják birtokolni az általuk használt informatikai eszközöket, mert ezek folyamatos szinten tartása és a kor igényeinek megfelelő szintre való fejlesztése folyamatos karbantartási és beruházási költségeket jelent.
•
Jelentősen növeli a vállalat mobilitását, mind a méretnövekedésből csökkenésből adódó ráfordítások terén, mind pedig a telephely változtatások okozta IT struktúra változás terén.
18
•
Tartós a nem IT vállalatoknál egyre nagyobb a jól képzett IT szakértelem hiánya, limitált a tudásszint, illetve alaptevékenységre való fókuszálási kényszer miatt nem akarnak magasan kvalifikált és fizetett informatikai szakembereket tartani, folyamatos képzési költségekkel biztosítva a technológia fejlődés követését.
•
A cég kiszolgáltatott egy-két munkatársának, akik egyedi tudással rendelkeznek és kellő dokumentáltság hiányában ez a tudás nehezen pótolható.
•
Nem tudnak kialakítani szabályozott belső eljárásokat és nincs kialakult mérési rendszere az IT szolgáltatás teljesítményének, ezért a legtöbb vállalatvezető, mint fekete dobozt, mint pénznyelőt lát az IT szervezetben.
•
Jelentős vezetői energiát visznek el a folyamatos fejlesztési és beruházási döntések és egyéb operatív IT irányítási feladat.
•
A termékek verzió követés és jogtisztaságának biztosítása a szolgáltató feladatává válhat.
•
Professzionális üzemeltetési körülmények biztosíthatók (24 órás rendszerfelügyelet, szabályozott adatarchiválás és mentési eljárások, Internet-biztonság, katasztrófavédelem, területvédelem), amiket a cégek saját maguknak csak igen magas költségekkel tudnak megteremteni és üzemeltetni.
•
Jelentős informatikai rekonstrukció helyett illetve vállalati folyamatátszervezést segítendő fordulnak külső szakcégekhez. A feladatkiszervezés forradalmi lendületet adhat egy beállt és megváltoztathatatlannak tűnő folyamat újragondolásához.
Ha a fentiekből adódó előnyök mind érvényre jutnak, mondhatjuk, hogy ezek az előnyök a vállalati stratégiát érintik, melynek alapján a vállalati erőforrások jobban kihasználhatóbbá válhatnak, versenyelőnyt biztosíthatnak a szervezetnek.
3.1.2.
Választási lehetőségek
Az informatikaüzemeltetés támogatásának és kiszervezésének számos ma már többé-kevésbé definiált válfaja létezik. Az elvek sokban azonosak, de a kapcsolat mélysége, valamint a nyújtott szolgáltatás technológiai és szakmai bázisa jelentősen eltérhet egymástól. Egy konkrét partnerkapcsolat esetén a működés különböző területeire ezek a különböző formák egy időben is megvalósulhatnak. Az informatikaszolgáltatás lehetséges formáinak egy fajta csoportosítása:
Bérlet (Eszköz-, szoftver-, erőforrásbérlet adott időre) •
Üzemeltetési környezet bérlete (Hosting, co-location, catastrophe site) Biztonságosan és alternatív hálózat és áramszolgáltatással kialakított géptermekbe helyezik el a központi számítógépparkot. A szolgáltató 24 órás rendszerfelügyeletet biztosít (megszakítás nélküli áramellátás légkondicionálás és kommunikációs kapcsolat, esetleg szerver és hálózat felügyelet, stb.), magas fokú őrzés mellett.
•
Munkaerőbérlet (Outtasking) Munkaerő-kölcsönzőtől bérelt munkatársak hosszútávra vagy kampányfeladatok ellátásához.
•
Távmenedzselés, bérelt munkaerővel (Managed Service Provision - MSP) Rendszerek 24 órás ellenőrzésének és adott szintű felügyeletének biztosítása külső szolgáltató által informatikai hálózaton keresztül. (Lásd Menedzsment technológiák című fejezetet)
19
Forráskihelyezés, kiszervezés (outsourcing) •
Infrastruktúrakihelyezés (Infrastructure outsourcing) A vállalat eladja tulajdonában lévő informatikai berendezéseket, hálózatot a szolgáltatónak, aki biztosítja ezek folyamatos üzemképességét, szükség szerinti fejlesztését, üzemeltetési díj ellenében. Az infrastruktúrához kapcsolódó szolgáltatásokat nyújtja (Data Center, adatmentés, katasztrófa-helyreállítás, informatikai eszközök karbantartása és támogató személyzet)
•
Alkalmazásüzemeltetés (Application Hosting Provider - AHP) Már létező, korábban testre szabott, egyedi alkalmazások átadása üzemeltetésre. Használat üzemeltetési díj ellenében.
•
Alkalmazáskihelyezés (Application outsourcing) Már létező, korábban testre szabott, alkalmazások eladása üzemeltetésre és fejlesztésre. Használat havi bérleti díj ellenében. A szerverinfrastruktúra lehet saját vagy bérelt, a környezet szintén saját vagy bérelt (co-location, hosting, server hostel) Két fő formája van: az alkalmazásbérlet (Application Service Provisioning, ASP) és az alkalmazásfenntartás, -támogatás (Application Maintenance Outsourcing, AMO) típusú. ♦ Alkalmazásbérlet (ASP - Application Service Provider) Előre konfigurált, sablonalkalmazások távoli használata hálózaton keresztül előfizetés alapú (bérleti) szerződés keretében. (Minimális vagy nulla testre szabás.) Explicite nem jelenik meg, de járulékos hardver és hálózati infrastruktúra használat is van az árban. ♦ Alkalmazásfenntartás, -támogatás kihelyezése (AMO - Application Maintenance Outsourcing) Egyedi alkalmazások üzemeltetésének biztosítása a szolgáltató által. Ami az informatikai feladatok ellátásán kívül kiterjedhet az alkalmazási rendszer szakmai felügyeletére, követésére is.
•
Üzleti folyamat kihelyezése (BPO –Information utilities and Business Process Outsourcing) Elsősorban a napi üzleti folyamatokra koncentrál (könyvelés, pénzügy, rendeléskezelés, számlázás) Ekkor az üzleti felelősség is a szolgáltatót terhelheti.
•
Központi ügyeleti szolgáltatás (Call-center, Help-desk szolgáltatás) A fenti szolgáltatások mindegyike igényel egy folyamatos hibabejelentés-fogadási szolgáltatást. Ez a szolgáltatás lehet egy bejelentéseket fogadó adminisztratív diszpécser szolgálat (call-center), vagy egy magasabb szintű szakmai támogatást nyújtó „forródrót”-szolgálat (hotline, help-desk), ahol az adott szolgáltatás használatában tanácsot adni tudó illetve az esetleges hibaelhárításban intézkedni tudó szakszemélyzet lát el folyamatos rendelkezésre állással szolgálatot.
3.1.3.
Ki a vevő?
Az előző szakaszban láttuk, hogy milyen igények váltják ki az érdeklődést az informatikaszolgáltatás iránt. Azt is láttuk, hogy ennek mélysége és a szolgáltatás spektruma igen széles lehet. Az alábbiakban egy-két ökölszabályt fogalmazunk meg arra nézve, hogy melyik szolgáltatási szintnek kik lehetnek az igénylői: •
Üzemeltetési környezet bérlete Minden olyan cégnek ajánlott, ahol nagy értékű és nagy kockázatú adatkezelés folyik. Bankok, államigazgatási intézmények, web szolgáltatók szervereit vagy tartalék rendszereit he-
20
lyezik itt el (lásd 2001. szeptember 11., New York: minden informatikaszolgáltatás egy-két óra múlva zavartalanul működött). •
Távmenedzselés Saját informatikai infrastruktúrával rendelkező közepes és nagyvállalatok, akiknek a teljes kiszervezés nem megfelelő. Előny: Azonnali megtakarítás a személyzeti költségeken, és a rendszermenedzsment-technológiákból adódó minőségi szolgáltatás elérése.
•
Alkalmazásbérlet Kisvállalatok, infrastruktúrával nem vagy alacsony szinten rendelkező, induló vállalkozások. Előny: Nulla induló beruházás, alkalmazások azonnal rendelkezésre állnak, bérelhető informatikai háttér és szaktudás. Elsősorban általános alkalmazások (irodai eszközök, levelezés, csoportmunka) és szabványos megoldások (bérelszámolás, könyvelés) esetén szokták igénybevenni.
•
Forrás kihelyezés, kiszervezés Nagy vállalatok, létező, egyedi infrastruktúrával, folyamatokkal. Előnye ennek a formának a szolgáltatásminőség színvonalának emelkedése, és hogy a cég saját üzleti tevékenységére jobban tud koncentrálni. Ezen előnyök mögött másodlagos haszonnak tekinthető 1) az esetlegesen alacsonyabb költség; 2) a beruházási keretek proporcionális költséggé alakulásának gazdasági előnye. A technológia átadásakor szerzett egyszeri pénzügyi forrás nyújtotta új lehetőségek is motiválók szokta lenni a jelentős technológiai beruházás előtt álló vagy financiális nehézségekkel küzdő cégek számára. A kiszervezési szerződések nagy értékű szerződések, a lassú megtérülés miatt több éves megállapodások (>5 év) születnek. Jól érzékelhető, hogy egy ilyen döntés nem az informatikai vezető szándékán múlik, hanem ez a vállalat stratégiai döntése.
A későbbiekben látható lesz, hogy ezen durva besorolások azonban nem elégségesek a döntés meghozatalához. Csak több hónapos és sok lépcsős egyeztetés után alakulhat ki a megrendelő igényeit leginkább kielégítő szolgáltatás pontos tartalma és keretei, ahol a szolgáltatás teljesítménye és értéke mindkét fél számára megfelelően alakul.
3.1.4.
Kiből lehet üzemeltető cég?
Az alábbiakban felsorolunk néhány szempontot, amelyeket az informatikaszolgáltató választásakor érdemes figyelembe venni. Ezek segítségével könnyebben megállapíthatjuk mi az erősségük, melyek a gyenge pontjaik, mire képesek, és mi az, amiben szakértők. Vizsgálandó, hogy •
A szolgáltató az infrastruktúra illetve alkalmazás teljes életciklusára kiterjedő szolgáltatásokat tud-e nyújtani, ideértve az alapvető tervezési tanácsadást, telepítést, üzemeltetést, oktatást, terméktámogatást és a rendszer folyamatos fejlesztését, bővítését a vállalat mindenkori igényeinek megfelelően;
•
Mire terjed ki és milyen mély a szolgáltató technikai szakértelme. Melyek a cég speciális szakterületei;
•
A legfontosabb technikai munkatársak szakértelmükre hol és milyen munkák kapcsán tettek szert;
•
Milyen cégeknél van működő referenciájuk, kik az ügyfelek, és milyen eredményeket értek el a szolgáltatás kapcsán;
•
Milyen a szolgáltatások színvonalát rögzítő szerződéseket javasolnak, és milyen pénzügyi lépéseket kötnek ki hibás teljesítés esetére.
•
Fontos szempont, hogy a szolgáltató infrastruktúrája hogyan biztosítja: ♦ a magas fokú rendelkezésre állást,
21
♦ a tökéletes adatintegritást, ♦ a skálázhatóságot, ♦ a megbízhatóságot, ♦ a nagy teljesítményt, ♦ a biztonságot és a hozzáférés-szabályozást; •
Milyen módon és eljárásokkal képes a szolgáltató a hét minden napján 24 órán át technikai támogatást adni a végfelhasználóknak? Milyen eljárásokat alkalmaznak a problémák feljebbviteléhez? Nyújtanak-e magas prioritású hibaelhárítási szolgáltatást? Külön-külön kapcsolattartó foglalkozik-e az egyes ügyfelekkel?
•
Rendelkezik-e a szolgáltató az alkalmazások testreszabásához, egyedi igények szerinti átalakításához fejlesztési tapasztalattal, szakértelemmel;
•
Hogyan oldja meg a szolgáltató a termékfrissítéseket, illetve a termékek újabb elemeinek üzembe helyezését;
•
Hogyan képes követni és milyen szakmai támogatást tud adni a szolgáltató a cég növekedése esetén szükséges átalakításokra, bővítésekre;
•
A támogatás a cég minden informatikai területét átfogja vagy csak egy-egy elkülönülő részét. A szolgáltató képes-e több „alszolgáltató” szakmai munkáját koordinálni;
•
Hogyan ítéli meg a szolgáltató cég üzleti stabilitását, mennyire bízik a szolgáltató cégben; Pozitív irányba billenti a mérleg nyelvét, ha a szolgáltató korábban már bizonyított sok ügyfelet kiszolgáló és kezelő rendszerek területén.
•
Vizsgálandó a szolgáltató által használt technológiák szintje, az ajánlott technológia kapacitása, a rendszermenedzsment-technológia színvonala;
•
Fontos szempont a működési biztonság (folyamatos üzemelés és ügyfélszolgálat, napi mentés, időszakonkénti archiválás stb., adatbiztonsági és védelmi rendszerek, szolgáltató pénzügyi stabilitása stb.);
•
Kritikus alkalmazásoknál előtérbe kerül a természeti csapások és terrortámadás elleni védettsége a szolgáltatói környezetnek: földrengés- és tűzbiztos szerverszoba, kétoldali árambetáplálás, dízelgenerátor, több alternatív hálózati szolgáltató, biztonsági szolgálat által szavatolt biztonság;
•
Végül pedig a szolgáltatásnak a fentiek függvényében megállapított, folyamatos költségként jelentkező ára.
Ugyanakkor, vizsgáljuk meg, mi kell ahhoz, hogy egy üzemeltetést támogató szolgáltató sikeres lehessen. •
Először is jól meg kell választani a célpiacot és az ehhez illeszkedő szolgáltatási portfoliót.
•
Gyors piaci felfutást kell elérni ahhoz, hogy a kezdeti beruházások megtérüljenek, és kellő tapasztalata és szaktudása legyen a csapatnak.
•
Alacsony költség mellett biztosítható üzemvitelt kell kialakítani, és ezt folyamatosan vizsgálva növelni kell tudni az üzemeltetési rendszer és a teljes informatikaszolgáltatás hatékonyságát.
•
Megbízható és egységes technológiai és infrastrukturális hátteret kell kiépíteni.
•
Folyamatos magas szintű rendelkezésre állást kell biztosítani egy strukturált eszkalációs (feljebbviteli) lánc működtetésével. A partnerkapcsolat-tartás és a szolgáltatásmenedzsment magas szintű kell, hogy legyen.
22
•
Biztosítani kell egy szolgáltatás-orientált személyzetet, akinek folyamatos képzéséről azonban gondoskodni kell.
Nem véletlen, hogy olyan cégek alakítanak ki informatikaszolgáltatást, akik a saját rendszereik üzemeltetése során kiépítették a megfelelő infrastruktúrát és megszerezték a kellő tapasztalatokat. Ilyenek lehetnek a távközlési cégek, vasúttársaságok, közműszolgáltatók informatikai szervezetei. A másik nagy csoportja az ilyen szolgáltatásnyújtó cégeknek az informatikai rendszerintegrátor cégek, akik mások számára már korábban is kiépítettek olyan integrált rendszereket, amelyeknek – éppen ezért – az üzemeltetését is el tudják látni, ill. cálszerű ellátniuk. Más cégek tapasztalatok hiányában csak nagy tőkével tudnak belépni erre a piacra, és csak akkor, ha egy piaci résre fókuszálnak. Ez nem kis kockázattal jár mind a vevő, mind az szolgáltató cég számára.
3.2.
Bizalom és kétség
A fentiek jó támpontokat adnak egy partner, és az által nyújtott szolgáltatási ajánlat kockázatelemzéséhez, ugyanakkor nem lehet megfeledkezni a döntési folyamatban szerepet játszó szubjektív elemekről sem. A legfontosabb kérdés: kialakul-e az a bizalom a szolgáltatóval szemben, ami meghatározza az együttműködés melletti döntésünket. Eddig az előnyöket vizsgáltuk, most nézzük meg milyen szempontok csökkentik a bizalmat a kiszervezéssel szemben és a teljesség igénye nélkül, milyen válaszokat adhatunk ezekre a kifogásokra: A fő veszély a visszafordíthatatlanság, hiszen a belső szakértelem leépítése után annak újbóli kialakítása lassú és költséges, és az esetleges szolgáltatóváltás is nehézkes és nagy megrázkódtatásokkal jár. •
A szolgáltató hosszabb távon erőfölénybe kerülhet a vállalattal szemben. Az előkészítés során jól szabályozott, egyértelmű és transzparens folyamatok alakulnak ki, amik könnyebben változtathatók, mint a rendezetlen, dokumentálatlan és több beszállítónak kiszolgáltatott állapot.
•
A szervezeti ellenállás a szolgáltatással szemben erős veszélyt jelenthet. A fogadó cégben az informatika kezelése stratégiai vezetés szintjére emelkedik az operatív irányítási szintről és így ennek aspektusai is jelentősen eltérnek a korábbi szempontoktól.
•
A szolgáltató elhanyagolhatja az üzleti igények támogatását, csökkentheti a színvonalat, elmaradnak az új alkalmazásfejlesztések. Az informatika stratégiai irányítását a cégnél kell tartani, és biztosítani kell a két cég közti folyamatos és magas szintű kommunikációt is.
•
A szolgáltató esetleg nem érti meg a vevő céljait, érdekeit, igényeit. Ilyen partnerrel ne kezdjünk.
•
Az alapos megértés is veszélyes lehet, hiszen a szolgáltató így kényes információk birtokosává válhat. A szolgáltató stratégiai fontosságú adatok birtokába kerülhet, ezek felügyeletét tehát nehezebb fenntartani. Általában kisebb a kockázat, mint a saját dolgozók kilépése esetén, hiszen a szolgáltató üzleti érdeke a maximális megbízhatóság és titoktartás garantálása.
•
Hogyan tovább, ha a beruházási döntésekhez nincs meg a kellő szakértelem; ha kicsi az informatikai szaktudás a szervezetben.
23
Megfelelő tudású és tapasztalatú operatív, adminisztratív vagy informatikai vezető kiválasztása nélkül ne is kezdjünk ilyen együttműködésbe. •
Nehézkessé válik a minőség és a költség-hatékonyság felügyelete. A jó szolgáltatási szerződés és a mögöttük lévő mérési és beszámoltatási rendszer ennek elejét veheti.
•
Hosszabb távon a költségek megnövekedhetnek a megtakarításokhoz képest. A költségek sokkal transzparensebbek lehetnek és a szolgáltató a kezdeti időszak után egy degresszív árat tud ajánlani.
•
A szolgáltató csőd esetén a vállalatot is magával ránthatja. Ez a veszély alapos előminősítési eljárással csökkenthető.
•
Az alkalmazói szoftverek nagy része nem alkalmas távfelügyeletre, ami a költségek kezdeti növekedéséhez vezethet. A cégek által alkalmazott rendszerek gyors elévülése miatt 2-3 éves távlatban ez a gond jelentősen csökkenhet.
•
A szolgáltatók korlátozottan vállalnak felelősséget adatvesztés esetén (Ezt általában a szolgáltatási szerződésben kikötik). A szolgáltató szakszerű és szabályozott folyamatai általában nagyobb biztonságot jelentenek, mint a saját eljárások. Általában a saját szervezetben elkövetett hibák felelősségi kérdései semmilyen megoldásra sem vezetnek, viszont a szolgáltató szervezet elemi érdeke a kockázatok minimalizálása.
3.2.1.
Az együttműködés
A fentiekből is kitűnik, hogy a feladat összetett és hosszú távú döntést igényel. A szerződéskötés után a kockázat közös csak más-más formában jelenik meg a két félnél. Itt csak együtt lehet győzni. A szolgáltatási és kiszervezési szerződések csak akkor tarthatók fenn, ha mindkét fél nyertesnek érzi magát. Ennek megértése elengedhetetlen feltétele már a szerződés előkészítési fázisának is. A munka során mindkét fél számára ismert adatokból közösen kell, hogy meghatározzák az optimális együttműködési modellt. Éppen ezért nem vezet a legjobb megoldáshoz, ha ilyen típusú feladatokat pályáztatás utján döntenek el. Természetesen a potenciális partner előminősítés alapján történő kiválasztása elkerülhetetlen. Ugyanakkor a szolgáltatás mikéntjét meghatározó előkészületi munka is egy olyan folyamat, amikor a felek képességeiket és lehetőségeiket kölcsönösen egymáshoz alakítják, és ennek eredményeként határozzák meg a szerződéses feltételeket.
3.3.
Út a döntéshez
Mint a fentiekből láttuk, rengeteg érv szólhat mellette és ellene annak, hogy egy cég külső szolgáltatóra bízza informatikai rendszereinek vagy azok egy részének üzemeltetését. A döntésig több lépcsős folyamat vezet, aminek célja feltárni a valódi, adott helyzetben, adott cégnél lévő érveket és ellenérveket. Az előkészítő folyamat végcéljának tekinthetjük egy szolgáltatási szerződés (SLA – Service Level Agreement) kidolgozását. Tekintsük át milyen lépések vezetnek el addig, amíg a szerződéstervezet elkészül, és a végső döntést meg kell hozni. Első lépésként meg kell ismertetnünk partnerünkkel azt a módszertant és definíciós rendszert, ami segítségünkre lesz az együttműködés során a közös nyelv és definíciók megteremtésében. Ehhez javasolható az ITIL-módszertan (IT Infrastructure Library) követése (ld. 4. . fejezetet).
24
3.3.1.
Helyzetfelmérés: az igény felkeltése – a tünetek elemzése
Bármilyen tartós együttműködés alapja az adottságok, körülmények és feladatok kölcsönös és alapos megismerése. Ennek hiányában akár mindkét fél részére „zsákbamacska” lesz a későbbiekben javasolt megoldás, nem lesz mihez viszonyítani és értékelni a változást. A hiányos vagy rossz helyzetértékelés mindkét fél számára megnehezíti a további döntéseket. A helyzetfelmérés szerepéről, lehetőségeiről, fajtáiról bővebben a 6.2. fejezet ad tájékoztatást. A helyzetfelmérés során rögzíteni kell a környezeti paramétereket: az aktuális üzemeltetési szinteket, technikai, szakmai erőforrásokat. Meg kell határozni (meg kell becsülni) a megbízó alkalmazásainak az üzemeltetéshez minimálisan szükséges szolgáltatási, rendszerfelügyeleti szintjeit, valamint a felügyelet alá vonandó informatikai elemeket és architektúrát. El kell készíteni a meglévő szolgáltatások katalógusát: fontos, hogy a szolgáltató jól átlássa és megértse a szükséges szolgáltatásokat, ismerje azok jellemzőit és minden szükséges információval rendelkezzen a felhasználókról. Ennek érdekében valamennyi szolgáltatási jellemzőt dokumentálni kell egy szolgáltatási katalógusban. Ez a szolgáltatási katalógus teszi lehetővé a szolgáltatandó informatikai funkciók későbbi megosztását a felhasználó cég és a szolgáltató cég között. Szolgáltatási funkciónként fel kell tárni, és mindkét félnek meg kell érteni, illetve meg kell határozni azokat az elvárásokat és kockázati elemeket, amik a kialakítandó üzemeltetési szolgáltatással kapcsolatban felmerülnek. Ugyancsak rögzíteni kell a vállalat életében várható és már betervezett fejlesztéseket, változásokat. Legkésőbb ebben a fázisban érdemes eldönteni, hogy az informatikaával kapcsolatos eljárások átalakítása milyen mértékben befolyásolja a vállalat egyéb eljárásait. Szükséges-e az üzemeltetési rend megváltoztatásának előszítésével együtt az alaptevékenységet érintő folyamatszervezési feladatokat is elvégezni? Sok vállalat használja ki az alkalmat rég óta halogatott átalakítási feladatainak végrehajtására az informatikai működési modell változásakor, legyen az egy új informatikai alkalmazás bevezetése vagy az informatikai feladatok kiszervezése. A folyamatszervezés beindításának igénye adódhat: •
a cég technológiai változásának igényéből;
•
újonnan bevezetendő informatikai technológia támasztotta követelményekből;
•
személyzettel szembeni létszám- és szakértelemigény változásából.
3.3.2.
Irányok kijelölése
A szolgáltatási szerződés kereteinek kijelölése A helyzetfelmérés alapján a következő lépés az informatikakihelyezés szabályozására létrehozandó szolgáltatási szerződés kereteinek meghatározása. Az informatikaszolgáltatási területek kereteinek kijelölése, és az ehhez kapcsolódó feladatok listájának összeállítása az első lépés. A felek meghatározzák, hogy mely feladatokat akarja a cég saját hatáskörében megtartani, és melyek kerüljenek a szolgáltató által biztosított, illetve támogatott feladatok közé. Magától értetődő, hogy ez egy iteratív folyamat. A részletek tisztázása során fokozatosan pontosítódnak a határfelületek és a felelősségek, hiszen a kidolgozandó technológiák és eljárásrend valamint a költségelemzések ismeretében ezek a kezdeti szándékok újraértékelődhetnek egy optimális feladatelhatárolás irányába. Természetesen, ha a teljes informatika kiszervezéséről vagy csupán néhány alkalmazás bérletéről beszélünk, akkor a feladatok és felelősségek elhatárolása és a szerződés kialakítása sok szempontból egyszerűbb, mint egy részleges feladat- és felelősségmegosztás esetén, ahol a vállalt számára kritikus alkalmazások is szóba kerülnek.
25
Az érintett szakmai területek, melyekre a szerződés kidolgozása vonatkozhat igen szerteágazóak lehetnek. A teljesség igénye nélkül néhány terület: •
Hálózatfelügyelet, ami kiterjedhet a lokális és országos hálózatokra egyaránt (LAN, WAN)
•
Szerverfelügyelet, ami a központi alkalmazási és a kommunikációs szerverekre vonatkozhat
•
Számítógép-felügyelet, ami a cég asztali számítógépeinek és a hozzájuk tartozó perifériák és rendszerszoftverek (pl. Windows, esetleg MS Office) üzemeletetését és karbantartását ölelheti fel
•
Alkalmazástámogatási rendelkezésre állás, aminek mélysége igen eltérő lehet az alkalmi frissítések végrehajtástól az alkalmazáshasználati tanácsadásig vagy egy üzletifolyamatkiszervezés esetén a folyamat kimeneteinek szolgáltatásáig. (Ilyen lehet pl. egy teljes körű bérelszámolás vagy könyvelés kiszervezése, ahol nem csak az informatikai rendszer, hanem a tényleges funkcionális szolgáltatás is házon kívül kerül.)
•
Szerver számítógép-központban történő üzemeltetése, ahol a rendszerek elhelyezése és megállapodás szerinti rendszeradminisztrátori feladatok kerülhetnek házon kívülre.
•
Ügyfélszolgálat nyújtása és távoli rendszerfelügyelet
3.3.3.
Feladatok elemzése – felelősségek elhatárolása
Az érintett területek kijelölése után, minden területre meg kell határozni az adott területen végzendő feladatokat. Ezeket a feladatokat csoportosítani kell és minden egyes feladatról készítendő egy adatlap (lásd 4. ábra és 5. ábra). Az első lépésben az adatlapnak csak az első oldala kerül kitöltésre, ahol a feladatot definiáltuk, és a feladatvégzéshez kapcsolódó tevékenységeket számba vettük, valamint meghatároztuk azokat a meglévő vagy később elkészítendő dokumentációkat, amik a feladatvégzéshez szükségesek. A feladatlapokból összeállított feladatjegyzék lesz a feladatok elvégzéséhez szükséges erőforrásterv alapja. Az erőforrásterv részletes műszaki becslésen alapszik. Meghatározásra kerülnek a ciklikusan végzendő feladatok gyakorisági és ráfordításadatai, valamint a rendkívüli események valószínűsége és egy becsült éves ráfordításigény. Az így megbecsült erőforrásterv lehet minden további létszám-kalkuláció és felelősségmegosztási terv alapja. Ezen feladatok ellátásának szabályozása és teljesítési szintjeinek meghatározása képezi a részletes kidolgozási időszakban végzendő munkák vázát is.
26
3. ábra: Példa feladatjegyzékre
Feladat neve:
WAN-hálózat monitorozása – 1. vonalbeli támogatás
Verzió:
V 1.0
Típus:
átalány
Dátum:
2002/01/30-n
Cél: A WAN-monitorozás célja, hogy a WAN hálózat folyamatos üzemeltetése biztosított legyen, valamint hogy a hibák felmerülése esetén az elhárítás minnél elöbb megkezdődjön és lezáruljon. Tevékenység: A tevékenység a következő főbb altevékenységből tevődik össze: WAN hálózati eszközök folyamatos monitorozása Hibák észlelése és regisztrálása az ügyfélszolgálati és a hibajegykezelő rendszerben Hibabejelentések és státuszkérések fogadása felhasználó kijelölt személyzete felöl A hibák ill. a hibajegyek életciklusának figyelemmel kísérése A 2. voalbeli támogatás igénybevétele a hibák elhárításakor A hibák lezárásakor hibajelentések generálása felhasználó személyzete felé e-mail-ben A szolgáltatási szerződés negyedéves statisztikai jelentéseinek generálása Előfeltételek: Kapcsolódó eljárások:
Eszköz:
Fejlesztés/ tesztelés:
27
Ügyfélszolgálati eljárások WAN 2. vonalbeli támogatási szerződés Hálózati audit és hálózati dokumentáció a telephelyi WAN hálózatokról 4. ábra: Példa feladatspecifikációs lapra / 1. oldal
28
WAN-hálózat monitorozása – WAN 1. vonalbeli támogatás
Verzió:
1.0
Típus:
átalány
Dátum:
2002/01/30-n
Leírás:
Olyan üzemeltetési szolgáltatási megegyezés, amelynek keretében a vállalkozó vállalja a felhasználó WAN hálózatának folyamatos monitorozását abból a célból, hogy a hálózat minnél nagyobb rendelkezésre állással üzemeljen és a hibák minnél rövidebb idő alatt elhárításra kerüljenek.
Szolgáltató:
XYZ Kft.
Divízió:
Telephely
Kiemelt telephely
Központ
igen
igen
igen
Sz.gépközpont (Alkalmazásszerver)
Sz.gépközpont (egyéb szerver)
igen
igen
Felhasználó:
Érvényes:
…………..…../…….../.……-től
Aláíró:
Megbizó részéről:
Szolgáltató részéről:
Aláírás: Szolgáltatás elérhetősége:
folyamatos:
Ügyfélszolgálat elérhetősége:
0. szint:
kiemelt időszak:
munkaidő:
alkalmi:
szint:
heti:
havi:
2. szint:
negyedévi:
fé-
évi:
lévi:
3. szint:
Üzemidő:
riasztás:
Bejelentett hibák kezelése: Besorolási szint:
1
2
3
4
Max egyidejű hibák száma:
1
2
4
8
Központban:
0.25 munkaóra
0.25 munkaóra
0.25 munkaóra
1 munkaóra
Budapesten:
0.5 munkaóra
0.5 munkaóra
0.5 munkaóra
4 munkaóra
Bp-n kívül:
0.5 munkaóra
0.5 munkaóra
0.5 munkaóra
4 munkaóra
Javítás megkezdése:
Helyreállítási terv: Biztonsági kérdések: Jogosultság: A szolgáltatás biztosításához szükséges külső szerződések: Garanciális:
igen
nem
Érvényesség: …………..…../…….../.……-ig
Külső szerződések:
MATÁV, PANTEL szolgáltatási szerződés
Adminisztráció:
Az ügyfélszolgálati rendszer segítségével
Havi riportok:
A havi helyett negyedéves riportok
Szerződésfelülvizsgálat:
Évente
Árkalkuláció: Az árképzés alapelvei xxx melléklet, xxx szolgáltatások tételei szerint
29
5. ábra: Példa feladatspecifikációs lapra / 2. oldal
3.3.4.
Lehetőségek vizsgálata – keretek meghatározása
A feladatmegosztási tervek elkészülte után kerülhet sor a jövőbeni együttműködési modellek kidolgozására. Ez valójában nem más mind egy megvalósíthatósági vizsgálat, ami folyamatos egyeztetések és részdöntések alapján rögzíti a javasolt kereteket. Ennek során az alábbi részkérdések kerülnek tisztázásra: • Meg kell határozni a rendszerfelügyeleti technológiákat, és az ezektől elvárt szolgáltatási szinteket; • Meg kell határozni az üzemeltetési elveket mindazon eszközökre, amiknek felügyeletét illetve üzemeltetését a cég külső szolgáltatóra bízza; • Meg kell határozni azokat az eszkalációs modelleket, amik biztosítani fogják, hogy a különböző működési zavarok a lehető legrövidebb idő alatt, a legkisebb kockázattal és költséggel elháríthatók legyenek; • Meg kell határozni a változások kezelésére vonatkozó eljárások elveit; • Meg kell határozni a vállalatnál szükséges működési szabályokat az új elképzeléseknek megfelelően; • Meg kell határozni a szolgáltatási szerződés tartalmi struktúráját, rögzíteni kell a terjedelmét, a cégek közti kapcsolatrendszert, felelősségmegosztási elveket; • Meg kell határozni a várható költségeket és megtakarításokat. Az elfogadott elvek alapján kerül sor a részletes eljárásrendek kidolgozására. Az ITIL-módszertan részletes ajánlásokat tartalmaz a fenti kérdések megválaszolásához és tisztázásához. 3.3.4.1. Költségkeretek meghatározása – lehetőségek elemzése A feladatspecifikáció és a megfogalmazott eljárás elvek alapján kerülnek kidolgozásra a pénzügyi keretek, ami között pl. egy 3-5 éves szolgáltatás kölcsönös előnyök alapján működtethető. Természetesen, ezen keretszámok a részletes kidolgozások során pontosításra kerülnek, de már ebben a korai fázisban mindkét félnek rendelkeznie kell irányszámokkal arra nézve, hogy melyik megoldás milyen költségekkel illetve megtérülésekkel jár a tervezett futamidőre. Ezen költségbecslések megbízhatósága azonban alapvetően meghatározhatja a további munka menetét. Amíg a keretszámokban, a várható költségek nagyságrendjében nincs konszenzus a felek között, addig felesleges a további elemző munka befektetése. Mindkét fél meghatározhatja azt a költségszintet, ami számára a releváns kereteket biztosítja és a további eljárások kidolgozása ezen keretek ismeretében optimalizálható. Az árak és költségek végső beállítása sokszori ismétléseket tartalmazó folyamat. A költségkalkuláció a rendszerek teljes, vagy részleges saját, vagy külső erőforrások bevonásával történő üzemeltetési kérdésének eldöntéséhez is szükséges. A költségkalkuláció során meghatározásra kerülnek a szükséges emberi erőforrások költségei, annak függvényében – akár több alternatívában is –, hogy milyen felügyeleti technológiákat, milyen szolgáltatási szintet és rendelkezésre állást kell biztosítani a cég számára optimális üzemvitel esetén.
30
Meg kell tudni határozni minden területre a fix, és proporcionális, az egyszeri és visszatérő költségelemeket és ezek nagyságrendi értékét. A vállalatok gyakran használják az ú.n. összköltség-számítás (Total Cost of Ownership – TCO) modelljét, amikor technológiai becsléseket végeznek. A TCO-modell egy időszakra vetítve tartalmazza mind az első befektetés, mind az évek során felmerült költségeket. Átlagos formában alkalmas lehet különböző beruházások összehasonlítására. A TCO-modell előnyei: •
Értelmezhetővé válnak a jövőbeni költségek, nem csak a kezdeti beruházások.
•
Segítséget nyújt egy költséghatékony stratégia kialakításához.
•
Átlagolva a TCO-mutatót összehasonlíthatóvá válnak az azonos időhorizontra vetített költségek, könnyebbé válik a választás a különböző lehetőségek között.
A TCO-modellnek azonban hátrányai is vannak: •
Nem veszi figyelembe az elérhető hozamokat, kizárólag a költségekre koncentrál.
•
Gondot jelenthet a választásnál (nem mindig a kevésbé költséges a jó választás).
•
Figyelmen kívül hagyja a befektetések során várható hozamokat.
•
Nem jelent segítséget a hozamok maximalizálásához.
Sok vállalat a TCO-modellt tartja elsődlegesen a legfontosabb mértéknek, mert könnyen érthető, megfogható elem az elemzések során. Az ú.n. megtérülési (Return of Investment – ROI) mutató a hasznok és a költségek arányát mutatja meg. Az informatika esetén általában 3 éves időtartamra számítják a magas technikai avulás miatt. A ROI-mutató a különböző lehetséges megoldások összehasonlítására alkalmas, nem az azonos szolgáltatást kínáló vállalatok összevetésére. Tekintsük át röviden az informatikai rendszerek fő költségelemeit 3.3.4.1.1.
Hardverköltségek
Egy kiszervezési megoldásnak jelentős hatása lehet a vállalat hardverberuházásaira illetve eszközállományának alakulására. Gyakran motiválja a cégeket az eszközök kiszervezésénél – még a vagyonvesztés terhére is – a szabad pénzeszközhöz való jutás lehetősége. Természetesen azonban a kiszervezés többletberuházásokat is igényelhet. Nagyobb sávszélességű, megbízhatóbb hálózati megoldások, rendszerfelügyeleti szoftver használatát írhatja elő a szolgáltató a garantált szolgáltatás biztosítása végett. 3.3.4.1.2.
Szoftverköltségek
A szoftverköltségek és főleg a szoftverkövetés költségei is igen eltérőek lehetnek a különböző kiszervezési megoldásoknál. ASP illetve BPO esetén nem is beszélhetünk explicit szoftverköltségről, hiszen ezek a szolgáltatási díjban, akár több megrendelő közt elosztva jelennek meg. 3.3.4.1.3.
Tanácsadási költségek
Egy új rendszer és alkalmazás bevezetése esetén jelentősen eltérhetnek a tanácsadási és képzési költségek annak függvényében, hogy eleve teljes kiszervezési, ASP- vagy BPO-megoldást választunk-e. Ezen eljárásoknál a vállalat csak az alkalmazás felhasználásának eljárásaival kell, hogy megismerkedjen, a többi mögöttes kérdés akár „fekete doboz” is maradhat számára.
31
3.3.4.1.4.
Személyzettel kapcsolatos költségek
A választott modell függvényében és a feladatmegosztási tervek alapján jelentősen eltérhetnek a vállalatnál megmaradó személyzeti költségek, hiszen a létszám és annak kvalifikáltsági szintjei sokban függnek a választott modelltől. 3.3.4.1.5.
Egyéb költségek
Ebbe a kategóriába tartozhatnak a biztosítási díjak, az Internet-előfizetések, a bérelt vonal fenntartása, a helységek bérleti díja, a szükséges biztonságtechnika költségei, valamint a beruházáshoz, szolgáltatáshoz szükséges eszközök egyéb járulékos költségei, amik szintén modellfüggően mások és mások lehetnek. A költségkeret-meghatározás során akár több féle releváns modellre is kidolgozandók lehetnek a költségkalkulációk. Ezen modellek összehasonlítása során alakulhat ki az a végső elképzelés, amire már a részletes folyamattervezés irányul.
3.4.
Döntés
Mint már korábban említettük a kiszervezési feladatok megtervezése egy folyamatos megismerési, elemzési és döntési folyamat. Vizsgáljuk most ezt az előkészítési eljárást a döntések oldalról. A feladatot kidolgozó munkacsoportoknak és a vállalati stratégiát és költségeket kézbentartó menedzsmentnek lépésről lépésre kell behatárolni a cég számára optimális játékteret, és ebben a szolgáltató cégnek elsősorban tanácsadási és elemzési, a folyamat menedzselését segítő feladatai vannak, de a döntés a megrendelő cég vezetőire hárul. Természetesen elképzelhető egy olyan eljárás is, ahol egy szerteágazó és több verziós (akár több pályázós) eljárásból szeretné a menedzsment a végső döntést meghozni. Ebben az esetben a vezetés kimarad a tanulási folyamatból. A szakértők és a cég munkatársai rengeteg felesleges munkát végeznek az alternatívák mély kidolgozásával, és a döntési helyzet kockázata is sokkal nagyobb lehet, mint a lépésenkénti együtthaladásnál. A több lépcsős döntési folyamat segíti a felek közti közös gondolkodás kialakulását, növeli az elkötelezettséget a majdani közös feladat iránt és megalapozza végső döntéshez szükséges bizalmat a felek közt. Kilenc kiemelt döntési pontot lehet meghatározni attól a pillanattól kezdve, hogy a partnerünket egy előminősítési folyamatban már kiválasztottuk: 1. döntési pont: A szolgáltatás terjedelme és típusa 2. döntési pont: Feladatmegosztás 3. döntési pont: Üzemeltetési modell 4. döntési pont: Technológiai szintre vonatkozó elvárások 5. döntési pont: Eszkalációs rend 6. döntési pont: Teljesítményszintek meghatározása 7. döntési pont: Szerződéses feltételek 8. döntési pont: Szerződés aláírása 9. döntési pont: Az éles indulás
32
Az első lépésben meg kell határozni, hogy mely területeket vonjuk be a vizsgálat látókörébe. Két út közül választhatunk: a teljes kiszervezés és a részleges kiszervezés közül. A részleges kiszervezés esetén is két lehetőségünk van: 1) fókuszálunk a vállalat életében legfontosabbnak minősített feladatok megoldására vagy 2) perifériális területek kiadásával „próbaköröket” futhatunk. A második megoldás veszélye, hogy a cég nem fordít kellő figyelmet az előkészítő folyamatra, és nem tudja megszerezni azokat a tapasztalatokat, amik a nagyobb lépések megtételét segítenék. A vizsgálandó területek meghatározása után a feladatmegosztás elveinek elfogadása következik. Ezen döntések meghozatala biztosítja, hogy a későbbi erőforrástervek (ember, eszköz, technológia, pénz) és költségkalkulációk nem vezetnek zsákutcába és a cég stratégiának megfelelő elképzeléseket tükröznek. A feladatmegosztás konkrét ismeretében lehet alternatív szolgáltatási modelleket felvázolni és a technológiai szintre vonatkozó javaslat (pl: megvalósítási tanulmány a javasolt felügyeleti technológiákra, hálózati kiépítésre, eszközfejlesztésre, szervezet struktúrára és létszámra, költségkalkuláció és megtérülésszámítás, stb.) kidolgozásával már a vezetésnek is és a szolgáltatónak is kellő információ áll rendelkezésre, hogy meghatározza a költségkereteket és a gazdaságossági kritériumokat. Ez az a pillanat, amikor a valódi döntés megszületik a szándékokról. Innen indul az aprómunka, amit már teljesen felesleges elvégezni, ha a vezetői elhatározás nincs meg a választott modell bevezetésére. A meghatározott modell és pénzügyi kritériumok alapján újraértékelhetők és véglegesíthetők az előzőekben kidolgozott elvek és eljárások és megindul a részletes folyamattervezés. Kidolgozásra kerülnek a későbbi együttműködés technikai és szabályozási feltételei, rögzítésre kerülnek a szolgáltatási szintek és ezek mérési, beszámolási eljárásai. Ezen eljárások elfogadása után már csak a szerződés jogi és elszámolástechnikai részleteit kell kidolgozni, mert a tartalmi elemek már mind meghatározásra kerültek és a várható költségek és bevételek sem okoznak meglepetést a feleknek. A szerződéses feltételek ismeretében már szándéknyilatkozat vagy előszerződés alapján mindkét fél megkezdheti az előkészületi munkákat a konkrét kivitelezésre. Megszülethetnek a megrendelések és szerződések az előkészítésre és a technológiai feltételek megteremtésére. Előkészítésre kerülnek a kapcsolódó partnerekkel az új helyzetre vonatkozó szerződések. Létrejönnek az új struktúrák, elvégzésre kerülnek a tesztek, és amikor mindez megnyugtatóan összeállt, már csak az éles indulás megkezdéséről kell dönteni a feleknek.
3.5.
Feladatok kidolgozása
Az ITIL-módszertan és a mellékelt esettanulmányok részletesen taglalják a kidolgozandó feladatok elvi és gyakorlati eljárásait, ezért itt most csak rövid áttekintést adunk az elvégzendő feladatokról. A részletes feladatkidolgozás célja az egyes szolgáltatási területek elvárásrendszerének, illetve az azokhoz kapcsolódó műszaki és ügyrendi eljárásoknak a részletes kidolgozása és leszabályozása a szolgáltatási szerződés megkötését megelőzően. A kidolgozás során minden egyes szolgáltatáselemről meghatározásra kerülnek a felelősségi és reagálási kritériumok (lásd a feladatspecifikációs lap 2. oldala). Ezek nemcsak a szolgáltatótól elvárt reakcióidőket és szolgáltatási szintre vonatkozó előírásokat (teljesítményszinteket) tartalmazzák, hanem utalást mindazon szabályzatokra, műszaki leírásokra, amik szerint az adott feladatot el kell végezni. Természetesen a feladatspecifikációs lap csak utal ezekre a dokumentációkra, de a szolgáltatás megkezdéséig mindezen dokumentációknak is rendelkezésre kell állni, hiszen ezek írják le a mű-
33
szaki eljárásrendet, illetve szolgálnak működési utasításként is a szerződő felek számára. Ebből következik, hogy ezen anyagok kidolgozásában általában mindkét félnek részt kell venni. A feladatspecifikációs lapok minden feladatnál mindazon kapcsolódó szerződésre is utalnak, amelyek ismerete a feladatot végző személyek számára szükséges ahhoz, hogy a megfelelő eszkalációs és változáskezelési döntéseket meg tudják hozni. Lehetőség van ezen feladatok kidolgozása során az egyéb kapcsolódó vállalakozói megállapodások felülvizsgálatára és a szükséges elvárásrendszerek újradefiniálására az egységes üzemeltetési környezet elveinek érvényesítése végett. A kidolgozás ki kell, hogy térjen a bevezetési eljárásokra is. A részletes feladatterv minden eleméhez meg kell határozni •
a feladatok megvalósításának előfeltételeit
•
megvalósítási eljárás lépéseit, ütemtervét, felelősségi köreit
•
szükséges szervezeti változásokat
•
képzési tervet
•
feljebbviteli eljárásokat
•
beszámoltatási rendszert
A feladatkidolgozás során meg kell valósítani mindazon technológiák bevezetését, amik az elvárt magasszintű szolgáltatás nyújtásához elengedhetetlenül szükségesek. Ilyenek lehetnek a rendszerfelügyeleti (monitoring) rendszerek (WAN-, LANhálózatfelügyeleti vagy szerverfelügyeleti szoftver és ezek működéséhez szükséges infrastruktúrális megoldások, lásd 5.4.2.2.2 fejezetet).
HL 0 HD 1 IN 2 EX 3
Hotline 0. szintű támogatás
VTT
Változásügyi Tanácskozó testület
Help-Desk 1. szintű támogatás Saját szakértő 2. szintű támogatás Külső szakértő 3. szintű támogatás
VDB
Változásügyi Döntőbizottság
Rendkívüli Döntőbizottság
ELJÁRÁS
INPUT
KONFIGURÁCIÓ kezelés
RDB
OUTPUT
SW könyvtár Eljárás-SLA Konfiguráció adatbázis
Gyorssegély szolgálat jelenség
monitorozás
PROBLÉMA kezelés
HD1
hibabehatárolás HL0
HD1
HL0-2,IN0-2,E3
lezárás
esemény
HD1
HD1 probléma meghatározás
Problémakezelés
probléma feltárás HD1-2, IN2
HD1-2, IN2
VÁLTOZÁS kezelés
hibaelhárítás
engedélyezés
fejlesztés, karbantartás, módositás igény
VDB, RDB
IN2
változás kérés
végrehajtás HD1,IN2
VTT
tervezés
VERZIÓ kezelés
verzióváltás
HD1
döntés döntés elõkészítés HD2, IN2
HD,EX3
VDB változás kérés
végrehajtás HD1-2,EX3
VTT
üzleti elvárás
KAPACITÁS kezelés
IN2 IN2
lezárás HD1
lezárás HD1
engedélyezés technikai elvárás HD2,IN2
VDB változás kérés VTT
végrehajtás lezárás
HD1-3,EX3,IN2 HD1
6. ábra: Az informatika müködtetése egymásba kapcsolódó eljárások rendszere
Minden egyes érintett területre egységes elvek szerint meg kell határozni a cégek közti kommunikációs eljárások rendjét mind a hibaesemények, mind a változtatási igények esetén.
34
Az eszkalációs modellekhez kapcsolódóan meghatározásra kerülnek az egyes koordinációs, felügyeleti szervezetek, alvállalkozói struktúrák, a közöttük lévő kapcsolatrendszerek, felelősségi területek.
Ügyfelek
Ügyfelek
Helyi seg élyh ely
Helyi seg élyh ely
Közpo nti seg élyh ely
WAN
WAN
H ív ás keze lő re ndszer
LAN Problé ma ke zelés
LAN
LAN
H álózatfe lügye le t
Számítógé pfe lügye le t
7. ábra: Elosztott ügyfélszolgálati-felügyeleti rendszer sémája
Ezen eszkalációs modellek írják elő az információáramlási eljárásokat: kit, mikor kell tájékoztatni, és mikor kell bevonni újabb és újabb szakértelmet a hiba elhárítása érdekében. Ezen előírások képezik alapját egy ügyfélszolgálati eljárásrendnek.
1. szállító
2. szállító
3. szállító
Megállapodás a szolgáltatás szintjéről
Szolgáltatásmenedzser 1. szint
2. szint
3. szint szállítók
0. szint Ügyfélszolgálat Informatikai felügyelet
Hibabejelentés
8. ábra: Eszkalációs szintek
35
Az ügyfélszolgálati eljárásrend vezérli az operatív működést és biztosítja a két cég közti folyamatos kapcsolatot és információáramlást. Az ügyfélszolgálat nem csak regisztrálja a hibabejelentéseket, hanem felel a hibaelhárítási folyamat teljes lebonyolódásáért is: 1. Bevonja a megfelelő szakértőket, ellenőrzi a feladatok időben történő teljesítését, szükség esetén az eszkalációs modell előírásai szerint újabb és újabb szakértelmet hív be a feladatmegoldásba. 2. Adminisztrálja a teljes szolgáltatást és riportokat készít a szolgáltató és a megbízó menedzsmentje számára egy–egy időszak eseményeiről és teljesítményeiről. 3. Az eszkalációs folyamat során szükség szerint riasztja a megbízó kijelölt munkatársait is a járulékos feladatok elvégzésére. (pl.: alternatív ügyrendek életbeléptetése) Mindezen feladatok kidolgozottságának szintje nagyban befolyásolhatja a partnerek közti kapcsolatok egyértelműségét, valamint a munka és költségek áttekinthetőségét.
3.6.
Szerződéskötés
A felek a fentiekben megfogalmazott keretek között szolgáltatási szerződést kötnek egymással és a feladat ellátásába bevonandó alvállalkozókkal, szolgáltatókkal. Ha az előkészítő munka során jól dolgoztunk, akkor a szerződés megkötésére már minden eljárás kidolgozva rendelkezésünkre áll és ez beemelhető a szolgáltatási szerződés mellékleteként. Ilyenek lehetnek az általánosan meghatározott és a szolgáltatás egy-egy szakterületére vonatkoztatott alábbi dokumentációk: •
A szerződés terjedelmének meghatározására szolgáló mellékletek, a szerződés hatálya alá vont szoftver- és hardvereszközök és -eljárások, feladatok jegyzékei. Esetleges átveendő személyzetre vonatkozó adatok.
•
A kidolgozott működési szabályzatok és üzemeltetési utasítások.
•
A teljesítményszinteket leíró feladatjegyzékek és/vagy egyéb teljesítményelőírások
•
A kapcsolattartás rendjére vonatkozó előírások és megállapodások
•
A változáskezelésre vonatkozó előírások és megállapodások
•
Jogosultsági előírások
•
Szervezeti kapcsolatok és ezekre vonatkozó előírások
•
A kiinduló állapot rögzítésére készült dokumentumok
36
•
A szolgáltatás teljesíthetőségére vonatkozó behatárolások, amik rögzítik az informatika környezeti adottságait, teljesítési helyszíneket, stb.
•
A behatárolások legfontosabb eleme a terhelési szint, ameddig a szolgáltató változás nélkül garantálja a szolgáltatást (pl. adatvolumen, sávszélesség, bővíthetőség stb.)
•
A rendelkezésre állás kritériumrendszere, pl. tervezett és nem tervezett leállások, időbeni behatárolások (pl. éjjeli, nappali üzem, főidő, mellékidő stb.)
•
Felelősség- és feladatmegosztási valamint eszkalációs eljárások leírásai
tárgya kiinduló állapot teljesítés helye hardver környezet
behatárolások
szoftver környezet applikáció elemei
terhelés összetétel tervezett leállások egyéb leállásigény
előzmények
rendelkezésreállás
Applicatió rendelkezésreállás
szolgáltatás terjedelme
nem tervezettleállások rendelkezésreállás időbeni behatárolása
vezetői összefoglaló
ár képzés
rendelkezésreállási szint
kapcsolattartók havi díjak
al- és társvállalkozók költség
kezdeti beruházási költségek eseti díjak kiszállási díjak
előzmények
fővállalkozó
szerződés célja
feleősségmegosztás
szerződés tárgya kiinduló állapot Minőségbiztositás felelősségek
SZERZŐDÉS
alapárak extrák
Server rendelkezésreállás
2001.07.30. - v5
Megoldás leírása
visszatérítés
megrendelő alvállalkozók
Általános bevezető
LAN rendelkezésreállás Árazás
infláció követés Szerver üzemeltetési előírás
WAN rendelkezésreállás
Kliens üzemeltetési előírás felmondás, elállás
Filszerver üzemeltetési előírás
kárigény
Hálózat üzemeltetési előírás
számlázás rendje
Helpdesk kapcsolattartás fizetési feltételek
Upgrade eljárások Változás kezelés rendje Szerződés alá vont hardver eszközök Szerződés alá vont szoftver eszközök
késedelmi kamat kötbér
Mellékletek szervezeti változások
Egyéb rendelkezések
riporting
Helyszinek
jogorvoslati kérdések
Kapcsolattartók adatai
változáskezelési eljárások
Jogosultsági rendszer
hatályba lépés
adatkezelési előírások
Vis Major
szervezeti séma
szerződés időtartama
beruházási terv
INFO RM ATIKAI
beruházások átadott eszközök tulajdonjoga
K F T.
9. ábra: A szolgáltatási szerződés szempontjai
A szerződés főszövege kell, hogy rendelkezzen a fizetési kritériumokról. A fizetési feltételek szorosan kapcsolódhatnak a szolgáltatási (pl. rendelkezésre állási) szintek betartásához, amiket a jelentési rendszer alapján ellenőriznek a felek. Csak olyan elemeknek kell a megállapodásbe bekerülnie, amelyek megfigyelhetők és mérhetők. Ez a megállapodás meghatározza mind a szolgáltatóra, mind a felhasználóra háruló felelősségeket. Gyakran használnak az ilyen szerződéseknél premizálási rendszert, ahol a szolgáltatás ellenértéke a teljesítési szinttől függ. Igen kritikus elem lehet a kártérítési kérdése. Milyen esetben kötelezhető a szolgáltató kártérítésre és milyen mértékben. A másik oldalon viszont meddig köti a szerződés a megbízót, és mi történik szerződésbontás esetén. Éppen ezért nagyon fontos elem a szerződésfelbontás lehetőségeinek rögzítése. Ez a hosszabb távú (pl. 3-5 évre szóló) szolgálta-
37
tási szerződéseknél különösen érzékeny kérdés, hiszen a szolgáltató egy-egy adott szerződéshez jelentős többletberuházások és létszámok kiépítésére kényszerült, melyek gazdaságosságát a szerződés teljes futamidejére határozta meg. A szerződés teljesíthetőségéhez szükséges beruházásokra és előkészítő munkákra vonatkozó megállapodás lehet ezen szerződés része, de az előkészítő projekt átfutási idejének csökkentése érdekében, megfelelő kölcsönös elkötelezettség vagy biztosítékok esetén, külön megrendelésben vagy szerződésben már korábbi fázisban is lehet intézkedni a műszaki feltételek megteremtéséről (pl.: bérelt vonalak biztosítása, infrastruktúrarekonstrukció, szoftverbeszerzés stb.) Természetesen az egyéb szokásos szerződési kitételek meghatározása is igen fontos a „vis major” meghatározásától a jogorvoslati megállapodásokig. A szerződés évenkénti felülvizsgálatára mindkét félnek lehetőséget kell biztosítani egy ilyen megállapodás keretében végzett munka csak akkor lehet megfelelő színvonalú, ha ez mindkét fél számára egyaránt előnyös. Ezt a kölcsönösen nyerő pozíciót hosszú távon fenn kell tudni tartani, és ebben mindkét félnek kellő rugalmasságot és megértést kell tanúsítania. Érdekmúlás esetén a feladat komplexitása miatt nagyon nehéz helyzet állhat elő a felek közt, ami mindkét fél számára üzletileg hátrányos eredményre vezethet és „kölcsönösen vesztő” helyzet alakulhat ki. Ennek elkerülésére a felek a szolgáltatásmenedzsereken keresztül folyamatos (napi, heti) szintű kapcsolattartásra kell, hogy berendezkedjenek. A szolgálttásmenedzserek legfőbb feladatai közé tartozik a konfliktuseszkaláció felügyelete, továbbá a hatékony működési formák kialakítása és fenntartsa. Természetesen az üzleti célok és körülmények folyamatosan változnak, ahogy a piac fejlődik, vagy hirtelen átalakul. Az egyik évben az adott üzleti céloknak megfelelően megkötött szerződés a következő években más igényeknek kell, hogy megfeleljen. Így már az eredeti szerződésben ki kell kötni, hogy a feleknek lehetősége legyen a szerződés felülvizsgálatára. A szerződésnek elég rugalmasnak kell lennie, hogy lehetőséget nyújtson olyan változásokra a felhasználó informatikai környezetében, mint pl. egy divízió szét- vagy leválása vagy a cég terjeszkedése. Nagyon ajánlott, hogy az elkötelezett és cégünk működését jól ismerő szolgáltató partnerünket stratégiai döntéseink előkészítésbe időben bevonjuk, hiszen az informatikai funkciók egy-egy vállalat életében már elérhetik az üzemviteli feladatok 50-80%-át is, és minden olyan változás, ami ezt érinti, meghatározó lehet a vállalat életében. Ugyanakkor az informatikai lehetőségek jobb kihasználása jelentős versenyelőnyt jelenthet a cég piaci helyzetében.
38
4. Módszertani összefoglaló
4.1.
Áttekintés
A szolgáltatásmenedzsmenthez tartozó ITIL témaköröket két fő részre bonthatjuk. A rövidtávú feladatokat a szolgáltatás támogatása, a hosszabb távú, taktikai, stratégiai feladatokon keresztül a szolgáltatások tervezését és nyújtását pedig a szolgáltatás biztosítása csoport tartalmazza. Tekintsük át folyamat-szerűen a szolgáltatás támogatása csoportba tartozó témaköröket. Először a hibabejelentés vagy igény megérkezik az ügyfélszolgálatra. Az incidensfelügyelet biztosítja az igény minél gyorsabb kezelését, a hiba gyors elhárítását, szolgáltatás kiesésének minimalizálását. A problémakezelés a hiba okának feltárását végzi: a súlyos következményekkel járó, vagy gyakran előforduló incidensek jövőbeni előfordulását küszöböli ki. A javításokat és egyéb szükségszerű változtatásokat a változáskezelés felügyeli. Az engedélyezett hardver és szoftver kiadásokat a kiadáskezelés állítja össze, teríti szét. A konfigurációkezelés mindegyik témakörhöz szervesen kapcsolódik: az infrastruktúra konfigurációs elemeit kezeli, konzisztens központi információ forrást biztosít. A szolgáltatás biztosítása csoportban központi szerepet játszik a szolgáltatási szint menedzsment, amelynek célja az informatikaszolgáltatás biztosítása, minőségének folyamatos javítása. Az informatikaszolgáltatás pénzügyi irányítása a költségek feltérképezésével és költségterheléssel gazdaságossá teszi a szolgáltatások nyújtását. A kapacitásmenedzsment biztosítja, hogy rendelkezésre álljon a szükséges erőforrás kapacitás és a meglevő erőforrásokat minél jobban kihasználjuk. A rendelkezésreállás menedzsment a szolgáltatásokra, infrastruktúrrára vonatkozó olyan rendelkezésreállási célok elérését segíti, amely költséghatékony és támogatja az üzleti célok elérését. Az informatikaszolgáltatás folytonosságának irányítása támogatja az üzletmenetfolytonosságot az informatikaszolgáltatás, infrastruktúra üzleti igényeknek megfelelő, elfogadott időn belül történő visszaállításával. A továbbiakban felvázoljuk az egyes témakörök közötti kapcsolatokat, majd részletesen tárgyaljuk azokat. Minden témakörnél meghatározzuk az elérendő célt, ismertetjük a legfontosabb fogalmakat, az adott folyamat létrehozásához, illetve végrehajtásához szükséges tevékenységeket, majd elemezzük a potenciális előnyöket és a lehetséges problémákat.
39
Ügyfél, vevő
Kérdés Hibabejelentés
Menedzsment Eszközök
Szolgáltatás riportok Incidens statisztikák Audit riportok
Változtatások
Ügyfélszolgálat / Vevőszolgálat
Incidensek
Incidensmenedzsment
Kommunikáció Módosítások Riportok
Problémakezelés
Probléma statisztikák, riportok Trend analízis Probléma áttekintések Diagnosztikai segítség Audit riportok
Ügyfél megelégedettségi riport
Változáskezelés
Ütemezett változtatások Változáskezelési megbeszélések jegyzőkönyvei Változtatások statisztikái Változtatások áttekintése Audit riportok
Kiadáskezelés
Ütemezett kiadások Kiadások áttekintése Kiadások statisztikái Biztonságos könyvtár Tesztelési előírások Audit riportok
Konfigurációkezelés
Konfigurációs adatbázis riportok, statisztikák Alap konfigurációk Audit riportok
Incidensek
Problémák Ismert hibák
Változtatások
Kiadások
Konfigurációs elemek kapcsolata Ismert hibák
10. ábra: Szolgáltatástámogatás csoportjába tartozó témakörök közötti kapcsolatok
40
Ügyfél, vevő
Kommunikáció Módosítások Riportok
Lekérdezések
Szolgáltatási Szint Menedzsment
SLA-k, OLA-k, Szolgáltatás riportok Szolgáltatás Katalógus Szolgáltatás Javítási Program Átlépések riportok Audit riportok
Követelmények Célok Eredmények Rendelkezéseállás Menedzsment
Rendelkezésreállás terv Tervezési kritériumok Célok/ Határértékek Riportok Audit riportok
Kapacitás Menedzsment
IT Szolgáltatások Pénzügyi Irányítása
Kapacitás Terv Kapacitás adatbázis Célok/ Határértékek Kapacitás Riportok Ütemezések Audit riportok
IT Szolgáltatás Folytonosság Irányítás
Pénzügyi terv modellek Költségek és díjak Riportok Költség tervezés és előrejelzés Audit riportok IT Folytonosság Terv Kockázat és hatáselemzés Katasztrófa elhárítási szerződések Riporok Audit riportok Riasztások, Átlépések Változtatások
Menedzsment eszközök és IT infrastruktúra
11. ábra: SZOLGÁLTATÁSBIZTOSÍTÁS csoportjába tartozó témakörök közötti kapcsolatok
41
4.2.
Ügyfélszolgálat
4.2.1.
Ügyfélszolgálat célja
Az ügyfélszolgálat a többi ITIL témakörtől eltérően nem folyamatot jelent, hanem a szolgáltatás és az ügyfél vagy vevő közötti kapcsolódási pontot. Az ügyfélszolgálat az incidensmenedzsment által meghatározott tevékenységeket végzi.
4.2.2.
Fogalmak
Incidens (Incident) – Olyan esemény, amely nem része az informatikaszolgáltatás normális működésének és a szolgáltatás kiesését vagy minőségének romlását eredményezi. Ügyfélszolgálat (Service Desk) – Az ügyfelek és az informatikaszolgáltatást nyújtók közötti kapcsolatot biztosítja. Nem csak incidensek, problémák, kérdések, változtatáskérelmek kezelésére használják, hanem a szolgáltatási szint menedzsment, konfigurációkezelés, rendelkezésreállás menedzsment, informatikaszolgáltatás pénzügyi irányítása, informatikaszolgáltatás folytonosságának irányítása témakörökhöz is kapcsolódik. Az ügyfélszolgálat első vonal beli hibaelhárítást végez, és háttértámogatást kaphat szakmai csoportoktól.
4.2.3.
Ügyfélszolgálati tevékenységek
Az ügyfélszolgálat működésekor az alábbi fontos tényezőket érdemes figyelembe venni. Bejelentéskor meghatározott struktúra szerint javasolt feltenni az ügyfélnek a kérdéseket. Így biztosítható, hogy a további diagnosztizáláshoz minden szükséges információt begyűjtünk, függetlenül attól, hogy ki rögzítette a hívást. Az ügyfél adatait egyedi azonosító alapján tároljuk az ügyfélszolgálati adatbázisban. Legyen mód az ügyfél adatainak előhívására az egyes jellemzők alapján. A szervezetek általában több helyen tárolnak adatokat az ügyfelekről, ezért az adatbázis karbantartásának sarkalatos pontja a központi adatforrás biztosítása. Az ügyfélkapcsolat javítása érdekében az ügyfélszolgálat tevékenységét érdemes ismertetni az ügyfelekkel. Az ügyfélszolgálat működéséről, az incidensek összetételéről, állapotáról, a támogató személyzet kihasználtságáról, az egyes esetekkel eltöltött idő mennyiségéről személyre és csoportra vonatkoztatva érdemes riportokat készíteni. Az incidensekről készített riportok tartalmát, gyakoriságát az üzleti igényeknek megfelelően kell megállapítani. Az idő elteltével bizonyos bejelentéseket javasolt a nap, mint nap használt adatoktól külön választani és alkalmi előhívások céljára archiválni. Így a nem rendszeresen használt adatok nem lassítják a rendszert, és áttekinthető marad az adatmennyiség.
4.2.4.
Előnyök
Az ügyfélszolgálaton keresztül a szolgáltatást nyújtó szervezet megítélése javítható. Az ügyfél és a szolgáltató között hatékony és kézben tartható kommunikációt biztosít az egypontos kapcsolódás.
42
Az ügyfélszolgálati rendszer a rutinszerűen végzett műveleteket automatizálja, ezáltal gyorsítja az incidenskezelést. Az összegyűjtött adatok a menedzsment számára értékes információt szolgáltatnak a szolgáltatás minőségéről. A rögzített incidensek az incidensmenedzsment alá kerülnek és az eszkalációs rendszer következtében időben megoldásra kerülnek, nem sikkadnak el.
4.2.5.
Problémák
Sokszor előfordul előfordul, hogy az ügyfélkezelési eljárás nem struktúrált vagy nem definiált. Hasonló problémák újból és újból előfordulnak, a menedzsmentnek nincs pontos információja az ügyfélszolgálat működéséről. Problémát jelenthet az is, ha a hívások kezelésének minősége nem konzisztens, tehát függ a hívást kezelő személytől.
4.3.
Konfigurációkezelés
4.3.1.
Konfigurációkezelés célja
A konfigurációkezelés célja az informatikai infrastuktúra adatainak kézben tartása, az egyes komponensek beazonosítása, figyelemmel követése és karbantartása. A szolgáltatásokról, a szoftver és hardver konfigurációkról és azok dokumentációjáról központilag tárol információkat így segíti az incidensfelügyeletet, problémakezelést, változáskezelést és a kiadáskezelést.
4.3.2.
Fogalmak
Konfigurációs elem (configuration item) – az infrastruktúra egy részegysége, amely a konfigurációkezelés hatásköre alá tartozik. Konfigurációs elemek közé tartoznak a szoftverek, azok moduljai, hardver elemek, de a dokumentációk, incidens és változáskérelmek is. Az egyes konfigurációs elemekből álló konfigurációt összetett konfigurációs elemnek nevezzük. Alapkonfiguráció (baseline) – egy adott időpillanatban a konfigurációs elemek jellemzőinek és azok kapcsolatának állapota, amely hivatkozási alapként felhasználható egy későbbi időpontban. Életciklus (lifecycle) – állapotváltozások meghatározott menete, amely jellemző az adott konfigurációs elem típusra. Konfigurációs adatbázis (Configuration Management Database CMDB) – egy olyan logikailag egységes adatbázis, amely tartalmazza a konfigurációs elemek adatait és a köztük levő kapcsolatokról is tárol információt Változat (variant) – egy olyan konfigurációs elem, amely alapvetően egy adott konfigurációs elem szerint épül fel, attól csak kis mértékben tér el.
4.3.3.
Tevékenységek
4.3.3.1. Konfigurációkezelés tervezése Amennyiben a konfigurációkezelés folyamat még nem létezik, az első lépés a tervezési fázis. Ennek keretében gondoskodni kell a megfelelő emberi erőforrásról, meghatározzuk az elérendő távlati célokat, a konfigurációkezelés terjedelmét, definiáljuk a folyamatokat, szerepköröket. Kidolgozzuk a konfigurációs elemek névkonvencióját, elkezdjük a konfigurációs adatbázis tervezését és felmérjük, milyen új eszközök lesznek szükségesek az adatkezelés támogatására. A tervezésnél figyelembe kell venni, hogy idővel általában növekszik a konfigurációkezelés alá bevont konfigurációs elemek és a hozzá tartozó változtatások száma. A növekedés mértékéről a
43
szervezet kapacitásterve nyújthat információt. Konfigurációk létrehozása Az informatikai infrastruktúra konfigurációit és azok alkotó elemeket olyan szinten kell meghatározni, amely lehetővé teszi azok hatékony kezelését. Addig a szintig érdemes lebontani a konfigurációkat, amely egységnél jelentkeznek a változtatások. Ha például a notebook egy részegységének meghibásodásakor az egész notebook kerül kicserélésre, akkor ezt egy egészként érdemes kezelni, nem kell további komponensekre bontani. Konfigurációk felépítése, konfigurációs elemek kiválasztása A konfigurációk meghatározzák a konfigurációs elemek kapcsolatát és pozícióját az adott struktúrában. A konfigurációk nem csak az infrastruktúra (hardver, szoftver és hálózat), hanem a szolgáltatások felépítését is tartalmazza. Mikor az egyes konfigurációt alkotórészeire bontjuk, meg kell választani a konfigurációs elemek kiválasztásának módját. Egy konfigurációs elemet (például java futtatási környezetet) több más alkalmazás is használhat, tehát nem szükséges ezt valamelyik más konfigurációs elem részeként kezelni, hanem egy kapcsolat létrehozásával külön érdemes definiálni. A konfigurációs elem legalsóbb szintjét úgy kell megválasztani, hogy az hosszú távon megfeleljen az igényeknek. A konfigurációkezelést támogató eszköz kiválasztásánál pedig fontos szempont, hogy ne legyen korlátozva a lebontási szintek változtatása. Ezt a szintet időnként érdemes megvizsgálni abból a célból, hogy nem tárolunk-e feleslegesen olyan információt, amit nem használunk, illetve a problémakezelés kinyerheti-e a számára szükséges adatokat. Konfigurációs elem típusok és életciklusok A konfigurációs elemek könnyű kezelhetősége érdekében típusokba soroljuk be azokat. Ilyen típusok pédául az operációs rendszerek, alkalmazói szoftverek, szerverek, munkaállomások, nyomtatók, routerek. Az egyes típusokhoz meghatározzuk, milyen tulajdonságokról tárolunk információt és definiáljuk az életciklust. Egy hardver eszköznél az életciklus a következőképpen alakulhat: megrendelve, raktárban, tesztelve, installáció alatt, használatban, javítás alatt, visszavonva. A konfigurációkezelést támogató eszköznek elég rugalmasnak kell lennie, hogy támogassa a típusoktól függő attribútumokat és életciklusokat. Konfigurációs elem kapcsolatok A konfigurációs elemek közötti függőségi viszonyt kapcsolatok definiálásával jellemezzük. Egyik elem tartalmaz egy másikat: számítógép tartalmazza a memóriát. Egy konfigurációs elem használ egy másikat: szoftver könyvtárat több alkalmazás is használ. Egyik elem hozzá van kapcsolva fizikailag vagy logikailag egy másik elemhez: számítógép és nyomtató kapcsolata. Az infrastuktúra és a szolgáltatások kapcsolatán kívül a konfigurációs elemek és a hozzá tartozó incidensek, problémák, ismert hibák, változtatások közötti kapcsolatot is tároljuk a konfigurációs adatbázisban. Alapkonfigurációk meghatározása Az alapkonfiguráció kiindulási alapként szolgálhat a továbbfejlesztéseknél, illetve sikertelen változtatásoknál visszatérési pontként szolgálhat. Az alapkonfigurációkat formális eljárások révén hozzuk létre, amelyek a konfiguráció ellenőrzés alapját képezik. Az elfogadott alapkonfigurációk és az azokhoz képest végrehajtott jóváhagyott változtatások révén jönnek létre a jóváhagyott konfigurációk.
44
Névkonvenciók Névkonvenciót kell létrehozni a konfigurációs elemek, alapkonfigurációk, dokumentációk, változtatások, szoftver és hardver kiadások azonosítására. Olyan könnyen kezelhető rendszert ajánlott kidolgozni, amely támogatja a konfigurációs elemek közötti kapcsolatokat, idomul a beszállítók jelölési szisztémájához és az infrastruktúra bővülését is figyelembe veszi. Az eszközök elnevezésében a típusra és a gyártóra utaló kód segíti a karbantartási munkákat. Úgy érdemes meghatározni a konfigurációs elem nevét, hogy egy másik jellemzővel (pl. gyártási szám, verzió) együttesen egyedi azonosítót alkosson. Konfigurációs elemek felcímkézése Minden konfigurációs elemet ellátunk azonosítóval. A hardver eszközökre cimkéket ragasztunk, amely egységes formátumot követ. Ajánlott a vonalkódos címkék alkalmazása, amely megkönnyíti a leltár készítés menetét. A szoftver médián érdemes feltüntetni az azonosítót, verziót és a másolat számát. A dokumentumoknál, ugyanúgy mint a szoftvereknél, a másolatokat lehet kiadni használatra, az eredeti példányokat pedig az ellenőrzött könyvtárban kell tárolni. 4.3.3.2. Konfigurációs elemek felügyelete A konfigurációs elemek felügyeletének célja, hogy csak megfelelően azonosítható, jóváhagyott komponensek kerüljenek a rendszerbe és az egyes konfigurációk ellenőrzött módon változhassanak. Tehát a változtatások a változáskezelés elvei szerint történnek, így csak jóváhagyott módosítások lehetségesek. Új konfigurációs elem rögzítése A felügyeleti ciklus az új konfigurációs elem megérkezésével vagy a kifejlesztett alkalmazás kibocsátásával kezdődik. A lehető leghamarabb, a megrendeléskor érdemes a konfigurációs elemet a konfigurációkezelés alá vonni, de legkésőbb a megérkezéskor. Belső fejlesztésű szoftverek esetében a kibocsátás pillanata az az időpont, amikor a szoftver átesik a minőségi ellenőrzésen és átkerül a fejlesztői környezetből az ellenőrzött szoftver könyvtárba. Amennyiben a kifejlesztett alkalmazás adatai a konfigurációs adatbázisban voltak tárolva, akkor ez egy állapotváltoztatást jelent, ellenkező esetben fel kell venni az új elemet. Készen kapható konfigurációs elemek (hardver eszközök, rendszer szoftverek, kommunikációs eszközök, alkalmazások) használatba vétele minőségi ellenőrzés és jóváhagyás után történik. Szoftver és hardver konfigurációs elemekből összeállított konfigurációk kibocsátása a kiadáskezelés elvei szerint zajlanak. Konfigurációs elemek adatainak változtatása A konfigurációs elemek életútjuk során különböző állapotokat vesznek fel, amelyeket követni kell a konfigurációs adatbázisban. Az egyes tulajdonságok változását a nyomon követhetőség érdekében nem csak követni, hanem naplózni is érdemes így az egész változás történet elérhetővé válik. Emellett a konfigurációs elemhez kapcsolódó változás bejegyzéseket is tároljuk. A konfigurációkezelés keretén belül ellenőrizhetjük, hogy a szoftverek, dokumentációk eredeti példánya, licenszek, karbantartási szerződések megfelelően lettek tárolva az ellenőrzött szoftver könyvtárban. Használatból kivont konfigurációs elemek
45
Pénzügyi és biztonsági szempontból nagyon fontos, hogy a használatból kivont szoftverek ennek megfelelő módon szerepeljenek a nyilvántartásban. Ezt az adatbázisból való törlés helyett az adott elem állapotának megváltoztatásával érdemes megtenni. Konfigurációk egységének biztosítása A konfigurációk integritását meg kell védeni a nem jóváhagyott változtatásokkal és a váratlan eseményekkel szemben. Ezért be kell tartatni a definiált konfiguráció-változtatási eljárásokat, az adatvesztés elkerülése érdekében az adathordozó médiát annak élettartamával összhangban cserélni kell, vírus veszélyt elhárítani, a katasztrófa helyzetre biztonságos adattárolással eljárásokkal kell felkészülni. Amennyiben valaki a munkája során nem regisztrált konfigurációs elemet észlel, vagy annak valamilyen jellemzője nem egyezik meg az adatbázisban tárolt információval, akkor jelenti az illetékeseknek. 4.3.3.3. Konfigurációk státuszának követése A konfigurációk állapotának követésére rendszeres időközönként audit riportokat készíthetünk, amelyekben szerepel a jelenlegi, megelőző és a tervezett következő állapot. A riportban az egyes elemek egyedi azonosítója mellett az alapkonfiguráció, a nyitott problémák, változtatáskérelmek, változtatások története és a változtatásért felelős személy is szerepel. Az audit riportok lehetővé teszik az egyes konfigurációk változásának nyomonkövetését. 4.3.3.4. Konfiguráció ellenőrzés és audit A konfigurációkezelés tevékenység csak akkor lehet hatékony, ha a valóságnak megfelelő adatokat tárolunk a konfigurációs adatbázisban. A tényleges és a tárolt információkat az informatikai rendszert érintő jelentős változtatások előtt, rendszeres időközönként vagy nagymértékű eltérés észlelésekor érdemes végrehajtani. Az audit folyamatot nagymértékben gyorsítja, ha feltérképező szoftvert használunk. Az így detektált, korábban nem regisztrált eszközöket, szoftvereket, licenszeket vagy felveszük az adatbázisba, vagy kiiktatjuk a rendszerből. Az audit eredményeképpen biztosítjuk, hogy csak jóváhagyott konfigurációs elemek léteznek az éles rendszerben. 4.3.3.5. Konfigurációs adatbázis karbantartása Mivel a konfigurációs adatbázis kritikus információt tárol az egész infrastruktúrára és a szervezetre vonatkozóan, gondoskodni kell az adatok biztonsági másolatáról, archiválásáról. Az adatbázis túlzott növekedését elkerülendő, ki kell dolgozni egy mechanizmust az idővel hasznos információt nem nyújtó, histórikus adatok törlésére. A konfigurációkezelés hatásköréből kivont konfigurációs elemek adatait törölni kell az adatbázisból.
4.3.4.
Előnyök
A konfigurációkezelés sikeres működése az informatikai erőforrások hatékony használatát segíti, amely nagymértékben segíti a magas szinvonalú szolgáltatás biztosítását. Támogatja az incidensfelügyelet, problémakezelés, változáskezelés, kapacitásmenedzsment, informatikaszolgáltatás-folytonosság irányítás folyamatokat, ami szintén a szolgáltatások minőségének növelését segíti. Közvetlen előnyként jelentkezik, hogy az informatikai eszközökről pontos információt tárol, ezáltal azok ellenőrzése, kezelése hatékonyan történhet. A konfigurációs elemek költségeinek nyomon követésével gazdaságos informatikaszolgáltatás nyújtható. Új eszközök, licencek beszerzésekor,
46
karbantartási szerződések megkötésekor a kiadások jól tervezhetők, ami megtakarításokat eredményez. A nem engedélyezett változtatások minimalizálhatók, a változások (pl. licensz használat) nyomon követhetők és a megfelelő intézkedés életbe léptethető.
4.3.5.
Problémák
Ha a konfigurációs elemek legalsó szintjét rosszul választjuk meg, akkor túl sok vagy túl kevés adatot tartunk nyilván, ami többletköltséget vagy nem hatékony problémakezelést von maga után. Problémát jelenthet, ha egyszerre túl ambiciózus célt tűzünk ki, és a befektetett munka mellett nem jelentkeznek az eredmények. Ezt fázisonként történő bevezetéssel lehet kikerülni. Ha a konfigurációs adatbázis kezelésére, az infrastruktúra állapotának feltérképezésére, audit riportok készítésére nincs támogató eszköz, akkor a folyamat időigényes. Ha a konfiguráció kezelési eljárások túl komplikáltak, a menedzsment részéről hiányzik a támogatás vagy a tevékenységek nincsenek megfelelő eszközzel segítve, akkor gyakran előfordul, hogy az előírásokat megkerülik és így a konfigurációs adatok idővel pontatlanok lesznek. Ha a konfigurációs adatbázisban nem kerülnek frissítésre az adatok, akkor az egész konfigurációkezelés elvesztheti a hitelét.
4.4.
Incidensfelügyelet
4.4.1.
Incidensfelügyelet célja
Az incidensfelügyelet célja a szolgáltatás normális szintjének lehető rövidebb időn belül történő visszaállítása, hogy az a legkisebb kedvezőtlen hatást jelentse az üzletmenetre.
4.4.2.
Fogalmak
Incidens (Incident) – Olyan esemény, amely nem része az informatikaszolgáltatás normális működésének és a szolgáltatás kiesését vagy minőségének romlását eredményezi. Probléma (Problem) - Az incidens(ek) valódi, még fel nem tárt oka. Ez lehet egy meghibásodott konfigurációs elem vagy ismeretlen hiba. Ismert Hiba (Known error) - incidens vagy probléma ismert oka, amelyre létezik megkerülő vagy igazi megoldás. Az ismert hiba addig létezik, amíg egy vátoztatással végleg meg nem oldottuk a problémát. Ügyfélszolgálat (Service Desk) – Az ügyfelek és az informatikaszolgáltatást nyújtók közötti kapcsolatot biztosítja. Nem csak incidensek, problémák, kérdések, változtatáskérelmek kezelésére használják, hanem a szolgáltatási szint menedzsment, konfigurációkezelés, rendelkezésreállás menedzsment, informatikaszolgáltatás pénzügyi irányítása, informatikaiszolgáltatás folytonosságának irányítása témakörökhöz is kapcsolódik. Az ügyfélszolgálat első vonal beli hibaelhárítást végez, és háttértámogatást kaphat szakmai csoportoktól. Hatás (Impact) – Ez a mérőszám jellemzi, mennyire kritikus az incidens az üzletmenetre. Általában arányos az elvárt szolgáltatási szint megváltozásának mértékével. Sürgősség (Urgency) - Ez a jellemző megadja, milyen kritikus az üzletmenetre az adott incidens vagy probléma és emellett figyelembe veszi az ügyfél saját igényeit is.
47
Prioritás – A hatás és sürgősségtől függő érték, amely meghatározza az incidensek vagy problémak megoldásának sorrendjét.
4.4.3.
Incidensfelügyelet folyamat
Az incidensfelügyeleti folyamatokat javasolt egy automatizált ügyfélszolgálati rendszerrel támogatni, amely könnyebbé teszi a szabályok betartását, és hatékonnyá teszi az incidensek adatainak rögzítését, keresését és lehetővé teszik bizonyos konfigurációs elemek (incidensek, problémák, ismert hibák, változtatások, szoftver elemek, hardver elemek) összekapcsolását. Incidens detektálása és rögzítése Az incidensek az ügyfélszolgálaton keresztül vagy egy rendszer-felügyeleti eszközből jutnak el az Incidensmenedzsment hatáskörébe. Az incidenseket konfigurációs adatbázisban tároljuk a hozzá kapcsolódó adatokkal együtt. Minden olyan részletet rögzítünk, ami az incidens kivizsgálásához, megoldásához és a felhasználó értesítéséhez szükséges. Ilyen alap adatok többek között az incidens körülményét tartalmazó részletes leírás, az érintett konfigurációs elem, a bejelentő adatai és a bejelentés időpontja. Automatizált rendszereknél lehetőség van arra, hogy a felhasználó közvetlenül hozzon létre bejelentést. Ebben az esetben a rendszernek biztosítani kell, hogy minden szükséges információt begyűjtsön és csak ezután rögzítse az incidenst. Incidens besorolása és kezdeti támogatás Az incidens besorolása folyamán a kiváltó ok keresése és a megfelelő megoldás keresése zajlik. Először a ténylegesen meghibásodott konfigurációs elem beazonosítása, részletes adatainak (verzió, gyártási szám, gyártó) történik. Az incidens leírása vagy a meghibásodott konfigurációs elem alapján, korábban előforduló hasonló incidensek között keresünk az adatbázisban. Amenynyiben létezik az incidenssel összefüggésbe hozható probléma vagy ismert hiba, akkor ezek felhasználhatók, és ha ez megoldást ad, akkor lezárható az eset. Az incidens besorolása során megadjuk mindazon adatokat, amelyek szükségesek a megoldási folyamathoz. Ennek keretén belül felmérjük, mely szolgáltatás érintett és milyen szolgáltatási megállapodás vonatkozik erre. A diagnózis fázist segítő részletes információt gyűjtünk, amely a tartalmazza a hibaüzenetet és a szolgáltatáshoz kapcsolható konfigurációs elemeket. Felmérjük az incidens által érintett felhasználók számát és a szolgáltatásra gyakorolt hatását. Meghatározzuk a sürgősséget, amelyet általában az incidens jellege meghatároz meg. A sürgősség és a hatás alapján meghatározzuk a prioritást, amely megadja, hogy milyen sorrendben foglalkozzunk az incidensekkel. Amennyiben nem lehet azonnal megoldani az incidenst, a besorolásnak megfelelő felelős csoportnak kell azt kiosztani. Diagnózis, vizsgálat Az incidens körülményeinek vizsgálata és a diagnosztikai lépések iteratív jelleggel követik egymást. Előfordulhat, hogy egy felelős csoporton belül (például az ügyelet-váltások miatt) más és más személy kapja meg az esetet, vagy az alaposabb vizsgálat során az incidens kategorizálása megváltozik, és így más támogatást nyújtó csoporthoz kerül. Ezért elengedhetetlenül szükséges, hogy minden szükséges adat rendelkezésre álljon és a hibaelhárítás során végzett tevékenységeket, felelősváltásokat, állapotváltozást naplózzuk. Megoldás és szolgáltatás visszaállítás
48
Az incidens megoldása történhet megkerülő megoldással, amely során a szolgáltatást akár csökkentett színvonalon is, de tovább biztosítjuk, vagy a hiba okát megszüntető tényleges megoldással. A megoldási fázis végeredménye egy olyan változtatáskérelem kezdeményezése, amely az adott probléma megszüntetését célozza. A megoldás megkeresése vagy kidolgozása után a szolgáltatás működőképességének vagy eredeti színvonalának visszaállítását általában a háttértámogatást nyújtó csoportok végzik. Incidens lezárás Az incidens megoldásáról az érintett felhasználót értesítjük és ellenőrizzük, hogy elfogadható-e a megoldás. Amennyiben a felhasználó ezt jóváhagyja, vagy a felhasználó által is ismert adott időn belül nincs ellenvetése, akkor az esetet lezárjuk. Ebben a lépésben lehet magadni a hibaelhárítással töltött időt, az incidens végső kategorizálását és ekkor lehet az incidenst a megfelelő problémához vagy ismert hibához kapcsolni. Az incidens újra megnyitását érdemes mellőzni, helyette új incidens rögzítése javasolt. Ha ez mégis szükséges, akkor ez csak ellenőrzött módon, meghatározott személyek végezzék. Incidens életciklus követése Az incidens mindenkori birtokosa az ügyfélszolgálat, amelynek nyomon kell követni az egész életciklusát. Folyamatosan figyeli az állapotát, és a vonatkozó szolgáltatási megállapodás betartását ellenőrzi. A vállalt elhárítási idő betartását segíti egy jól definiált eszkalációs folyamat, amikor is meghatározott idő után - amennyiben nem történt megfelelő előrehaladás - a kijelölt személyeket értesítjük. Könnyen kezelhető, akár több szintű eszkalációs rendet lehet megvalósítani automatizált eszköz használatával.
4.4.4.
Előnyök
Az incidensmenedzsment sikeres megvalósításának legnagyobb előnye az incidensek üzletmenetre gyakorolt negatív hatásának csökkentése, amely az incidensek számának csökkentésében és a kiesési idők rövidülésében jelentkezik. Ez közvetlenül pénzügyi veszteségek csökkenését eredményezi, közvetetten pedig a felhasználók produktivitását növeli. Az incidensmenedzsment másik nagy előnye, hogy az informatikai csoport és a felhasználók közötti kommunikáció javításával növekedik a felhasználói megelégedettség: nincsenek nem fogadott hívások, elfelejtett esetek. A megoldási folyamatról folyamatosan információt kapnak a bejelentők. Az eszkalációs rendnek és a priorálási szabályoknak köszönhetően, az esetek kritikusságának megfelelően kezelődnek a bejelentések. Az incidensmenedzsment megvalósításával hatékonyan lehet használni az informatikai csoport erőforrásait, a bejelentések szétosztása egyenletes terhelést jelent a csoporttagoknak. A bejelentések adatainak elemzésével értékes információ nyerhető a szolgáltatási megállapodások betartására és a szolgáltatás minőségére vonatkozóan. Az incidensek elemzésével a rendszer javítását célzó megelőző intézkedéseket hozhatunk.
4.4.5.
Problémák
Ha az incidens életútja nincs megfelelően követve, vagyis az incidenst nem kapja meg a időben a megfelelő személy vagy nem kap róla értesítést, akkor a megoldásig eltelt idő növekszik. Hosszú
49
megoldási időt eredményez az is, ha az incidensek megoldásakor a felelős személy nem támaszkodik a saját vagy mások által megoldott hasonló típusú esetek adataira. Amennyiben a felhasználó nem kap információt a megoldás előrehaladásáról, akkor a felhasználó megelégedettsége csökken. Pontatlan szolgáltatási szint adatokat eredményezhet, ha nincs pontos információ a kiesés idejéről (bejelentés és megoldás időpontja). Első vonalbeli támogatás nem szűri meg a bejelentéseket, akkor a háttértámogatást nyújtók nem tudnak a kritikus esetekkel foglalkozni, mert a gyakori bejelentések megszakítják a munkájukat.
4.5.
Problémakezelés
4.5.1.
Problémakezelés célja
A problémakezelés célja az incidensek által okozott kedvezőtlen hatások minimalizálása. Reaktív módon a hiba okának megkeresésével foglalkozik és megelőző, proaktív módon az incidensek jövőbeni előfordulásának megakadályozását végzi.
4.5.2.
Fogalmak
Probléma felügyelet – (problem control) célja az incidensek okát jelentő problémák, mint például egy hibás konfigurációs elem feltárása, megkerülő megoldások keresése és ezek kommunikálása az ügyfélszolgálat felé. Szoros kapcsolatban áll az incidensfelügyelettel, mivel az incidenseknél használt megkerülő megoldások a problémáknál kerülnek bejegyzésre és később onnan kereshetők elő. Mivel a probléma felügyelet az incidensek újbóli előfordulását hivatott megelőzni és elsősorban a súlyos következményekkel járó problémákkal foglalkozik, ezért alaposan meg kell tervezni az itt végrehajtandó folyamatokat. Hiba felügyelet – (error control) célja az ismert hibák felmérése, költség-hatékony megoldás keresése, megoldási folyamat figyelemmel követése és lezárása. A hiba felügyelet tehát az ismert hibák kezelésével foglalkozik, egészen azok teljes megszüntetéséig.
4.5.3.
Problémakezelés tevékenységek
4.5.3.1. Problémafelügyeleti tevékenységek Probléma azonosítás és rögzítés A problémákat az incidensektől külön tároljuk a konfigurációs adatbázisban, de képesnek kell lennünk ezek összekapcsolására. A probléma bejegyzés más jellegű kísérő információt tartalmaz, mint az incidens. Például nincs felhasználói információ, viszont az érintett konfigurációs elemekről tárol adatokat. A problémáknál rögzítjük a megkerülő megoldások leírását is, továbbá azon incidensek számát tárolhatjuk, amelyek az adott problémához köthetők. Probléma besorolás A probléma besorolásakor meghatározzuk azokat a jellemzőket, amelyek a probléma szolgáltatásra való hatását írja le. Ezek a kategorizálás, amely az érintett területet adja meg (alkalmazói szoftver, hardver, operációs rendszer), a hatás, sürgősség és a prioritás. Ezek a jellemzők az incidensmenedzsmentnél megadottak szerint kezelendők. Probléma vizsgálat
50
A probléma vizsgálata és diagnosztizálása az incidensek vizsgálatához hasonlít, de azzal ellentétben itt nem a felszíni hibaelhárítás a cél, hanem az incidens igazi okának feltárása. A vizsgálat eredményeképp előálló megkerülő megoldásokat rögzíteni kell a problémával együtt. Amikor sikerül azonosítani a hibás konfigurációs egységet, a probléma átminősül ismert hibává. Előfordulhat, hogy nem meghibásodás jelenti az igazi okot, hanem eljárásbeli problémával állunk szemben. Ekkor a probléma alapján kezdeményezzük a változtatást, és a probléma nem válik ismert hibává. 4.5.3.2. Hiba felügyelet tevékenységek Hiba azonosítás Amikor sikerül azonosítani a hibás konfigurációs egységet és megkerülő megoldást sikerült találni, a probléma átminősül ismert hibává. Az ismert hiba két forrásból származhat. Az egyik az éles rendszerből származó hibák, amelyek konfigurációs elemekre vezethetők vissza. A másik forrás a fejlesztői környezetből származó szoftver kiadásokból adódó hibák, amelyek ismertek, de még nem létezik rájuk megoldás. Hiba felmérés A hiba felmérése során meghatározzuk a megoldás sürgősségét és hatását, ami végső soron meghatározza a hiba megszüntetését célzó változtatáskérelem prioritását. A nyomon követés érdekében a hibát és a hozzá tartozó változtatáskérelmet össze kell tudnunk kapcsolni. A hibamegoldás végső fázisa a változáskezelés hatáskörébe tartozik. Amennyiben a hiba külső fél által karbantartott eszközre vagy szoftverre vonatkozik, a kapcsolattartó személyt vagy csoportot értesítjük, és figyelemmel kell kísérni a megoldást annak érdekében, hogy az előírt megoldási idő be legyen tartva. Megoldás rögzítése Az ismert hiba bejegyzéssel együtt a végleges megoldás mellett a folyamatot is ajánlatos naplózni. Az ismert hibákat tartalmazó adatbázis tartalmazza az érintett konfigurációs elemek adatait, hibaüzeneteket, hibaelhárítási lépéseket. Ez az információ később rendelkezésre áll az incidensek vizsgálatánál, a probléma és a megoldás keresésénél. Hiba lezárása A hiba megszüntetését célzó változtatás sikeres befejezése után az ehhez kapcsolódó ismert hibát, problémát, incidenst le lehet zárni. Az incidens esetében érdemes ellenőrizni, hogy a felhasználó meg van elégedve a megoldással. A probléma és az ismert hiba pedig a végleges lezárás előtt egy közbenső (félig lezárt) állapotba kerülhet, ami a végső ellenőrzés után kerülhet teljesen lezárt állapotba. Probléma és hiba megoldásának figyelemmel követése Az ismert hibák elhárítását a változáskezelés végzi, de ezt a folyamatot figyelemmel kíséri a problémakezelés, ha szükséges rendszeres riportokat kap az előrehaladásról. A problémakezelés folyamatosan figyeli a problémák, ismert hibák felhasználókra gyakorolt hatását, és ha szükséges új változtatáskérelmet nyújt be vagy növeli a korábbi kérelem prioritását.
4.5.4.
Előnyök
A problémakezelés megvalósításának legfontosabb eredménye az informatikaszolgáltatás minőségének javítása, megbízhatóságának növelése. Ez egyrészről az incidensek számának csökkenéséből, másrészről a súlyos következményekkel járó incidensek megszüntetésével érhető el.
51
Mivel nem felszíni hibaelhárítás történik, hanem a hiba igazi okát szüntetjük meg, ezért a megoldás tartós vagy végleges megoldást nyújt. A megoldásokból tudásbázis hozható létre, amivel gyorsítható a megoldási folyamat és bizonyos mértékben tehermentesíthetők a szakmai csoportok. A megoldások és megkerülő megoldások használatával az első vonal beli hibaelhárítás mértéke növelhető, aminek következtében az ügyfelek elégedettsége növekszik.
4.5.5.
Problémák
Előfordulhat, hogy a jól működő problémakezelő csoportot a felhasználók a vevőszolgálat megkerülésével közvetlenül megkeresik. Ekkor vissza kell irányítani a hívásokat a vevőszolgálatnak, különben a gyakori megszakítások hátráltatják a hibafeltárási munkát. Az incidensek, problémák, ismert hibák összekapcsolására integrációs lehetőségre van szükség, amelyet megfelelő eszközzel érdemes támogatni. Mivel a problémakezelés időigényes folyamat, ezért a támogató csoportok részéről elkötelezettség és tudatosság szükséges, különben a mindennapi teendők háttérbe szorítják az ilyen jellegű munkát. Bizonyos mértékű érdekellentét van az incidensmenedzsment és a problémakezelés tevékenységek között, mivel az egyik minél előbb próbálja visszaállítani a szolgáltatást, akár megkerülő megoldások alkalmazásával, míg a másik időigényes hibafeltárást szeretne végezni. Ezért egyensúlyt kell teremteni a két témakör között, egymás céljainak figyelembe vételével.
4.6.
Változáskezelés
4.6.1.
Változáskezelés célja
A változáskezelés célja a végrehajtott változtatások sikerességének biztosítása, kedvezőtlen hatások minimalizálása. Változtatások a problémák megoldásából és a szervezet igényeiből, kötelezettségeiből származhatnak.
4.6.2.
Fogalmak
Változáskérelem (request for change) – olyan írásos vagy elektronikus nyomtatvány, amely leírja az infrastruktúra elemét vagy eljárást érintő változtatás kérelem részleteit. Változáskezelési tanács (Change Advisory Board - CAB) – olyan csoport, amely a változtatások végrehajtásához szükséges véleményt alkot és tanácsot ad. Az informatika több területéről delegált személyekből áll, akik kompetensek a felmerülő kérdésekben. A csoport tagja vagy formális megbeszélésen jönnek össze, vagy elektronikus úton tartják a kapcsolatot egymással. Változáskezelési tanács sürgősségi bizottsága (Change Advisory Board Executive Committe CAB/EC) – a változáskezelési bizottság bizonyos tagjaiból álló csoport, akik a sürgős változtatások ügyében döntenek.
4.6.3.
Változáskezelés tevékenységek
Változáskérelmek kezdeményezése Változáskérelmet elsősorban a műszaki személyzet nyújt be, de biztosítani kell a felhasználóktól jövő kezdeményezések fogadását is. Ezt leghatékonyabban kapcsolattartók kijelölésével lehet megvalósítani, akik kiszűrik és összefogják a felhasználóktól eredő kérelmeket.
52
Kérelmek szűrése A változáskezelés menedzser megszűri az ésszerűtlen és többszörösen előforduló kérelmeket és dönt a sürgősségéről. A felhasználók számára biztosítani kell valamilyen módot a fellebbezési lehetőségre. Priorálás, kategorizálás Először a probléma prioritásának meghatározása történik a szolgáltatásra gyakorolt hatás és a sürgősség alapján. A kérelem prioritását a változáskezelés menedzser és szükség esetén a változáskezelési tanács dönti el a kezdeményező bevonásával. A prioritás határozza meg, hogy a többi kérelemhez viszonyítva milyen sorrendben történik a feldolgozás. Ugyanekkor történik a kockázat felmérés is. Ezután a változáskezelés menedzser a változtatást a hatása, kiterjedése és a szükséges erőforrás szerint kategorizálja. Például az első kategóriába a kis hatással bíró változások, a második kategóriába a közepes hatású, jelentős erőforrást igénylő változtatások, a harmadikba pedig a nagy hatással, nagy kiterjedtséggel bíró, sok erőforrást igénylő változtatások tartoznak. Változtatás felmérés A változáskezelési tanács megvizsgálja, hogy a változtatás milyen hatással van az üzemvitelre, kapacitásra, a szolgáltatások minőségére, rendelkezésreállására és milyen erőforrások szükségesek a végrehajtáshoz. A felmérésben résztvevők jelzik, hogy támogatják-e a változtatást. Jóváhagyás, ütemezés Ebben a fázisban történik a változáskérelem elfogadása vagy elvetése, ami a változáskezelés menedzser feladata. Míg kisebb horderejű döntésekről csak információt kap a jóváhagyó testület, addig a fontos változtatásokról maga dönt. A jóváhagyás többfajta - pénzügyi, műszaki és üzleti szempontok figyelembe-vételével történik. A változtatásokat egymáshoz képest ütemezni kell, majd az érintettek tudomására kell hozni. Bizonyos szoftvermódosításokat érdemes összefogva, csomagkiadásként kezelni, és több változtatást egyszerre végrehajtani. Változtatás tervezése és létrehozása A jóváhagyott változtatás a megfelelő műszaki csoporthoz kerül, aki kidolgozza a lépéseket. Ezen kívül visszatérési tervet készít, ami sikertelen változtatás során lép életbe. A változáskelésnek csak felügyeleti szerepe van a tervezés, tesztelés és végrehajtás során. Változtatás teszt A változtatást teszt környezetben ajánlott végrehajtani a funkcionalitás, teljesítmény, megbízhatósági és a biztonsági szempontok figyelembevételével. Változtatás végrehajtása A változtatást akkorra érdemes időzíteni, amikor az a legkisebb szolgáltatás kiesést eredményezheti. Nagyobb horderejű változtatásokkor javasolt erre az időre készenlétbe helyezni a jelentkező hibákat lekezelő szakmai személyeket. Az eredményről a változáskezelés menedzser értesíti a felhasználókat és az érintett feleket. Változtatás elemzése
53
Rendszeres időközönként meg kell vizsgálni az összes, adott időszakon belül végrehajtott változtatást abból a szempontból, hogy a kitűzött célt elérték-e. Amennyiben a végeredmény nem megfelelő vagy mellékhatások jelentkeztek, új változáskérelmet lehet kezdeményezni. Sürgős változtatások kezelése A sürgős változtatásokat is ellenőrzött módon kell végrehajtani. Az egyes lépések kissé módosulnak és gyorsabban hajtódnak végre. A felmérési fázist a változáskezelési tanács sürgősségi bizottsága végzi. A visszatérési tervet és a tesztelést akkor végezzük el, ha elegendő idő áll rendelkezésre. A változtatás végrehajtása után a dokumentációs feladatokat utólag el kell végezni.
4.6.4.
Előnyök
A hatékonyan működő változáskezelés a kockázatok felmérésével, helyes döntések meghozatalával képes a változtatások negatív hatásainak csökkentésére és a magasabb szinvonalú szolgáltatás elérésére. A változtatásokkal járó költségek felmérhetők, előre figyelembe vehetők, ami a gazdaságosságot segíti. A jól működő eljárások alkalmazásával nagy számú változtatás végrehajtása lehetséges. A kevesebb sikertelen változtatás révén a felhasználók munkája zavartalanabb, nagyobb produktivitással dolgoznak, és az informatikai csoport is hatékonyabban dolgozik, mert kevesebbszer kell visszaállítani az eredeti állapotot.
4.6.5.
Problémák
Ha változáskezelési folyamat nincs megfelelő eszközzel támogatva, akkor nagy adminisztratív terhet, szűk keresztmetszetet jelent, ezért a dolgozók igyekeznek megkerülni a bürokráciát, nem jóváhagyott változtatásokat végrehajtva. A központosított változáskezelés ellenállásba ütközhet, amit felvilágosítással lehet orvosolni. Problémát jelenthet az is, hogy a beszállítók, szolgáltatók nem kellőképpen alkalmazkodnak a szervezet változáskezelési előírásaihoz.
4.7.
Kiadáskezelés
4.7.1.
Kiadáskezelés célja
A kiadáskezelés célja a változtatások eredményeképpen előállítandó hardver és szoftver kiadások tervezése és felügyelete, a változáskezelés és a konfigurációkezelés támogatása. Biztosítja a szoftverek gyári példányának biztonságos tárolását, védelmét, hardver és szoftver kiadások telepítését és üzembe helyezését. Az éles környezet védelme érdekében csak ellenőrzött hardver és szoftver kiadások kerülhetnek használatba. A konfigurációs adatbázis használatával a kiadott új vagy megváltoztatott hardver elemek állapota nyomon követhető.
54
4.7.2.
Fogalmak
Kiadás (release) – új vagy módosított konfigurációs elemek (hardver vagy szoftver) összeállítása, amelyet tesztelés után az éles környezetbe iktatunk be. Kiadást hozunk létre a szolgáltatás javítása, vagy valamilyen hiba kiküszöbölése érdekében. Kiadás egység (release unit) – Az infrastruktúra azon része, amely egy kiadásban szerepel. Kiadás típusok: teljes, különbségi, csomag (full, delta, package) – Teljes kiadás minden elemét együtt hozzuk létre, teszteljük és léptetjük életbe, nem csak a módosított konfigurációs elemeket tartalmazza. A különbségi, vagy delta kiadás csak azokat a konfigurációs elemeket tartalmazza, amelyek változtak a legutolsó kiadás óta. Teljes és különbségi kiadások együttesen alkotják a csomagkiadást. Ilyen csomagkiadás lehet például az Office termékcsalád. Ellenőrzött szoftver könyvtár (Definitive Software Library - DSL) – Logikailag egységes, de fizikailag több részből álló tároló-hely, ahol az összes gyári vagy kifejlesztett szoftver biztonságos körülmények között van tárolva a fejlesztői és teszt környezettől elkülönítve. A szoftver könyvtárba csak szigorú ellenőrzési eljárásokon keresztül juthat be, illetve kerülhet ki szoftver. A konfigurációs adatbázisban hivatkozások vannak az itt tárolt szoftverekre vonatkozóan. Ellenőrzött hardverraktár (Definitive Hardware Store, DHS) – Tartalék hardver alkatrészek biztonságos tárolására elkülönített tároló helyiség. A konfigurációs adatbázisban hivatkozások vannak az itt tárolt eszközökre vonatkozóan.
4.7.3.
Kiadáskezelés tevékenységek
A kiadáskezelés kezdeti tervezési fázisa alatt az egyes kiadások tervezése, magas szintű tesztelési terv és a kiadás elfogadásának általános kritériumait dolgozzuk ki. Kiadás készítése, konfigurálása A hardver kiadások készítése az egyes elemek összeállítási módjának leírását, elvégzendő műveletek leírását tartalmazza. Szoftverek esetében az egyedi fejlesztésű kód lefordítását, linkelését jelenti. Egyedi és készen rendelkezésre álló szoftvereknél egyaránt elkészítjük a tesztelési, viszszatérési, automatizált vagy egyedi installációs illetve konfigurációs eljárásokat. A kiadások öszszeállítását leíró konfigurációt, mint konfigurációs elemet a konfigurációs adatbázisban tároljuk. Kiadás elfogadása Az életbe léptetés előtt egy elkülönített teszt környezetben vizsgáljuk a kiadást. A tesztelésben részt vesznek az informatikai szakemberek és felhasználók egyaránt. A visszatérési eljárást is ebben a fázisban teszteljük. Az elfogadása a változáskezelés folyamat elfogadási fázisával egyezik meg. Telepítés tervezése A telepítés tervezése kiegészíti a kezdeti tervezési fázist, és figyelembe veszi az infrastruktúra kiterjedését. Kidolgozzuk a kiadások telepítésének fázisait: minden helyszínre egyszerre vagy fázisonként, a kiadások milyen verzióit hova, milyen ütemezéssel telepítjük. Mivel elosztott rendszereknél a pillanatszerű verzióváltás általában nem lehetséges, ezért különös gondot kell fordítani a különböző verziók együttműködésének biztosítására. Telepítés előtti előkészületek
55
A telepítés megkezdése előtt a felhasználókat, a szakmai támogató személyzetet informálni kell, hogy milyen változások várhatók. A sikeres bevezetést segíti, ha a felhasználókat minél nagyobb számban sikerül bevonni a tesztelési fázisba és ez által gyakorlatot szereznek az új rendszerben. Az eszközök, szoftverek üzembeállításáról oktatást tartunk a szakcsoportoknak, a használatáról pedig a felhasználóknak. Telepítés A hardver eszközök tárolási körülményei és kiszállítási eljárásai biztosítják, hogy az eszköz a megfelelő állapotban érkezzen a kijelölt helyre. Szoftver állományok szétterítésénél ellenőrizzük, hogy az teljes egészében megérkezett a célállomásra, menet közben nem korrumpálódott. Nagy, elosztott rendszereknél a szétosztás és az életbe léptetés műveletét érdemes külön választani, ha erre mód van, így elérhető a pillanatszerű átállás. A telepítés művelete a változáskezelés utolsó lépése is egyben, amikor a konfigurációs adatbázist az új állapotnak megfelelően frissítjük. Rögzítjük a konfigurációs elemek új konfigurációját, állapotát, tulajdonosát, elhelyezkedését.
4.7.4.
Előnyök
A kiadáskezelés előnyei akkor mutatkoznak meg igazán, ha szoros együttműködés van a változáskezeléssel és a konfigurációkezeléssel. A szoftver és hardver kiadások sikeres kibocsátása magasabb színvonalú szolgáltatást eredményez. Biztosítja, hogy csak ellenőrzött, legális szoftverek kerüljenek használatba és a futtatáshoz szükséges alapkövetelmények, hardver elemek rendelkezésre álljanak. Az informatikaszolgáltatás biztosításában fontos szerepet játszó informatikai eszközök biztonságos tárolását, kezelését, szoftverek esetében vírusvédelmét biztosítja. A kiadáskezelési eljárások betartásával nagy számú szoftver és hardver változtatás lehetséges és a kiadások ütemezésével azok egymáshoz szinkronizálhatók. Az eltérő, egymással nem jól együttműködő verziók könnyű detektálása, kiszűrése révén az incidensek száma és a szolgáltatások kiesésének időtartama csökken.
4.7.5.
Problémák
Az újonnan kidolgozott kiadáskezelési eljárások betartása ellenállásba ütközhet, amit felvilágosító munkával, az előnyök elmagyarázásával oldhatunk meg. Az eljárások megkerülése, be nem tartása nem engedélyezett szoftver installálásakor vírusveszélyt jelenthet, a nem tesztelt hardver vagy szoftvertelepítések, módosítások hibákat eredményezhetnek. A tesztelési környezet kialakítása időigényes és költséges, de a fejlesztői környezetből közvetlenül az éles környezetbe átvitt kiadások nagy veszélyt jelentenek a szolgáltatásokra. Ha a kiadások telepítésének ütemezése nem megfelelő, akkor kompatibilitási hibák léphetnek fel, amit fázisonkénti bevezetéssel védhetünk ki. A felső-vezetés támogatásának hiánya léphet fel, ha a kiadáskezelés tevékenységeit költségesnek és kényelmetlennek ítélik, így a tevékenységek elvégzésére nem áll elegendő erőforrás vagy támogató eszköz a rendelkezésre.
56
4.8.
Szolgáltatási szint menedzsment
4.8.1.
A szolgáltatási szint menedzsment célja
A szolgáltatási szint menedzsment célja az informatikaszolgáltatás biztosítása és minőségének folyamatos javítása. Ez a minőségi jellemzők definiálásával, a szolgáltatást igénybe vevő ügyfél és a szolgáltatást nyújtó közötti megállapodás létrehozásával, a szolgáltatások jellemzőinek mérésével, rendszeres felülvizsgálatával és javításával érhető el.
4.8.2.
Fogalmak
Szolgáltatási megállapodás (Service Level Agreement - SLA) - írásos megállapodás (nem szerződés) a szolgáltatást nyújtó fél és a szolgáltatást igénybe vevő fél között, amely előírja az igénybe vett szolgáltatásokra vonatkozó szolgáltatási szinteket. Üzemeltetés megállapodás (Operation Level Agreement - OLA) - Vállalaton belüli szervezeti egységek között kötött megállapodás, amely az informatikai csoport munkáját segíti a szolgáltatások biztosításában. Ügyfél (Customer) - A szolgáltatás tulajdonosa (általában felsővezető), aki felelős a szolgáltatás költségeiért és definiálja a szolgáltatással szemben támasztott követelményeket. Elsősorban üzleti szempontból megtérülő szolgáltatásokban érdekelt, a szolgáltatást nyújtókkal a szolgáltatási szint menedzseren keresztül tartja a kapcsolatot. Felhasználók (Users/End Users) - A szolgáltatást ténylegesen használók. Elsősorban magas szintű rendelkezésreállásban, funkciókban gazdag rendszerekben érdekeltek. A szolgáltatást nyújtókkal a vevőszolgálaton keresztül tartják a kapcsolatot. Szolgáltatás katalógus - írásos dokumentum, amelyben az informatikaszolgáltatás egyes elemei és ezek szintjei vannak definiálva.
4.8.3.
Szolgáltatási szint menedzsment tevékenységek
4.8.3.1. A szolgáltatási szint menedzsment folyamat tervezése Amennyiben a szolgáltatási szint menedzsment folyamat még nem létezik, az első lépés a kezdeti tervezési fázis. Ennek keretében gondoskodni kell a megfelelő emberi erőforrásról, meghatározzuk az elérendő távlati célokat, definiáljuk a folyamatokat, szerepköröket, felmérjük a kockázatokat. Elkezdjük a szolgáltatás Katalógus és a szolgáltatási megállapodások struktúrájának tervezését. Felmérjük, hogy a jelenlegi szolgáltatásokat hogyan lehet monitorozni, és a jövőben milyen új eszközök, mérési módszerek lesznek szükségesek. A szolgáltatás javításához úgy láthatunk hozzá, ha tisztában vagyunk, honnan indultunk el: megvizsgáljuk a szolgáltatások jelenlegi színvonalát, vagy kérdőívekkel megelégedettségi felméréseket végzünk. A kitűzött cél eléréséhez szükséges út megtételéhez ez alapján ütemezést készíthetünk. Mielőtt létrehozzuk a szolgáltatási megállapodásokat, ellenőrizzük, vagy ha nem léteznek, kössük meg azokat a szerződéseket, belső megállapodásokat (Üzemeltetés Szint Megállapodásokat), amik a kitűzött célok elérését támogatják. 4.8.3.2. A szolgáltatási szint menedzsment folyamat kialakítása Szolgáltatási katalógus létrehozása
57
A szolgáltatások átláthatósága érdekében ajánlott létrehozni egy katalógust, amely tartalmazza a szolgáltatásokat és a hozzá kapcsolódó felhasználókat (szervezeti egységeket, ügyfeleket). Később ez segítségünkre lehet a szolgáltatási szintek és más ITIL témakörök által használt információk kezelésében is, például a szolgáltatás infrastruktúráját biztosító eszközök, a szolgáltatásokat támogató háttér-szolgáltatások függőségi viszonyának feltérképezésében. Problémát jelenthet, hogy mit is nevezzünk szolgáltatásnak. Irányelvként tekinthetjük, hogy az ügyfél által érzékelt, saját üzleti folyamatait támogató szolgáltatásokat kell figyelembe venni. Az ügyfélt nem érdekli, hogy egy számlázási rendszernek milyen komponensei vannak, (hálózat, szerver, alkalmazás, munkaállomás) az ő érzékelési szintjéhez kell megválasztani azt a szintet, ahol definiáljuk a szolgáltatást. Elvárások kezelése A kezdeti tervezés fázisban felkeltett érdeklődést, elvárásokat megfelelően kezelni kell. A túlzott elvárások könnyen vezethetnek kiábrándultsághoz. A valóságtól elrugaszkodott igényeket legjobban egy számlázási rendszer bevezetésével lehet kordában tartani, különben az informatikai csoport könnyen kerülhet lehetetlen helyzetbe a nem elérhető, vagy nagy erőforrásokat igénylő célok kitűzése miatt. A szolgáltatási megállapodás struktúrájának kialakítása Az ügyfelek és az általuk igénybe vett szolgáltatásokra vonatkozó dokumentumok struktúrája többféleképpen alakítható ki. Az ügyfél alapú szolgáltatási megállapodás ügyfél szerint csoportosítja az igénybe vett szolgáltatásokat. Nagyon kedvelt ez a változat, mert az ügyfél csoport tudja, mik azok a szolgáltatások, amik őket érintik. A szolgáltatás alapú szolgáltatási megállapodás felsorolja az összes ügyfelet, aki igénybe veszi az adott szolgáltatást. Ez akkor előnyös, ha minden ügyfélnek ugyanolyan az előírt szolgáltatási szintje. Ekkor problémát jelenthet, hogy ki képviseli az ügyfelek csoportját, azaz ki írja alá a szolgáltatási megállapodást. A többszintű szolgáltatási megállapodás az előbbiek kombinációja. A legfelső szinten az egész vállalatra érvényes megállapításokat tartalmazó szolgáltatási megállapodás dokumentum található: ezek az adatok változnak legkevésbé. Az alatta levő szinten az ügyfélre vonatkozó, szolgáltatástól független adatok találhatók. A legalsó szinten a szolgáltatások egyedi jellemzőit tárgyaló szolgáltatási megállapodás dokumentum van. Ennek a kialakításnak nagy előnye a rugalmasság és az áttekinthetőség. Szolgáltatási szint követelmények meghatározása és szolgáltatási megállapodás vázlat készítése A szolgáltatási megállapodás létrehozásába minél előbb be kell vonni az ügyfeleket. A követelmények tisztázását segíti, ha a megbeszélésre egy szolgáltatási megállapodás vázlatot készítünk. Fontos megérteni az ügyfél üzleti szempontból támasztott igényeit, de az is előfordulhat, hogy még sohasem fogalmazták meg ezeket, ekkor segíteni kell nekik ebben a folyamatban. Szolgáltatási megállapodás megfogalmazása A szolgáltatási megállapodás nyelvezete egyértelmű, szakzsargontól mentes legyen, törekedni kell a tömör, érthető megfogalmazásra. Ezt segíti, ha egy olyan személy nézi át, aki nem vett részt a szolgáltatási megállapodás megírásában, ezáltal a nem közérthető dolgok könnyen kiszűrhetők. Megállapodás létrehozása A szolgáltatási megállapodás a szolgáltatást nyújtó és az ügyfél közötti megállapodás, amit a két fél tárgyalásokkal és sokszor kompromisszumok árán hoz létre. Figyeljünk arra, hogy az egyeztetések során a vevő megfelelő képviselőjével tárgyaljunk, aki ténylegesen birtokolja majd a szolgáltatást, és az általa hangoztatott igények megfelelnek az egész felhasználói csoport és ügyfe-
58
lek igényeinek. Ha nincsenek korábbi tapasztalatok a szolgáltatásra vonatkozóan, akkor érdemes egy kísérleti szolgáltatási megállapodást létrehozni, és abban megállapodni. A kísérleti rendszert olyan helyen érdemes elkezdeni, ahol nagy az elfogadó készség, majd ezt ki lehet terjeszteni több szolgáltatásra, ügyfélre. Minél magasabb szinten történik a szolgáltatási megállapodás aláírása, annál nagyobb elkötelezettséget jelent. Szolgáltatás figyelésének, monitorozásának beindítása A szolgáltatási megállapodásban csak olyan célokat definiáljunk, melyeket mérni lehet. A pilot rendszer alatt felgyülemlett adatok segíthetnek a reális célok meghatározásában. Meg kell vizsgálni a szolgáltatás minőségét figyelő eszközöket, és szükség esetén ki kell bővíteni azok képességeit. Azokat a jellemzőket kell mérni, amit az ügyfél észlel, vagy az összes olyan részszolgáltatást, amelyekből az egész szolgáltatás felépül. A hálózati forgalomban a másodpercenként mért hibás csomagok száma nem mond semmit a felhasználónak, hiszen ő a válaszidőt érzékeli, pontosabban a végponttól-végpontig történő kommunikáció válaszidejét. Ezért fontos, hogy ha ezt közvetlenül nem tudjuk mérni, akkor az összes szükséges műszaki adatot kell vizsgálni és összefüggésbe hozni a felhasználó által érzékelt minőségi szinttel. Mérőműszer hiányában a rendelkezésreállás adatot a vevőszolgálatba történt bejelentés és a hiba elhárításának időpontja határozza meg. A legtöbb problémát a válaszidővel kapcsolatos esetek jelentik, mivel általában csak az azon nyomban kivizsgált esetek okát (például: egy adott időpontban fennálló, ideiglenes túlterhelés) lehet megtalálni. Válaszidők elvárt szintjének előírásánál javasolt beiktatni valamekkora toleranciát. Például a válaszidő 5 másodperc 10 esetből 9-nél, vagy több mint 5 másodperc legalább 2 percen keresztül. Szolgáltatás minőségének legjobb általános és a szubjektív megítélést is figyelembe vevő módja a megelégedettségi felmérések, amelyeket rendszeresen lehet végrehajtani. A szolgáltatási megállapodást támogató megállapodások, szerződések felülvizsgálata Mielőtt a szolgáltatási megállapodás célok mellett elkötelezi magát a szolgáltatást nyújtó fél, biztosítani kell, hogy léteznek az ezt támogató belső megállapodások (OLA) vagy külső féllel kötött szerződések. Ha például egy alkalmazás szerver hibaelhárítását 4 órán belül el kell végezni és az eset szoftver hibaként volt bejelentve, biztosítani kell, hogy ez alatt az idő alatt a szoftveresek el tudják hárítani a hibát, még akkor is, ha külső támogatást vesznek igénybe. Ha a külső támogatás válaszideje túl nagy, akkor újra kell tárgyalni ezt a szerződést, vagy az szolgáltatási megállapodás célt kell módosítani. Sőt, mind a 4 órát nem használhatják el diagnosztikával a szoftveresek, mert lehet, hogy hardver jellegű a hiba. Ha a hardveresek 2 órán belül cserélik ki a hibás részegységet, akkor a szoftveresek maximum 2 órát foglalkozhatnak az esettel. Riportolás és folyamatok áttekintése A riportolás tartalmáról, formájáról és gyakoriságáról meg kell állapodni az ügyféllel. Emellett a szolgáltatás áttekintésének gyakoriságáról, formájáról is meg kell egyezni. A szolgáltatási megállapodásokat évente, a pénzügyi ciklussal összhangban érdemes áttekinteni. Szolgáltatási megállapodás közzététele A szolgáltatási megállapodás megkötése után nyilvánosságra kell hozni annak tartalmát. A vevőszolgálatnak, a háttértámogatást nyújtó csoportnak ismerni kell a legfontosabb részleteket (megjelenési idő, válaszidő, kapcsolattartó személyek) és a felhasználóknak is tudniuk kell, mit várhatnak el a szolgáltatótól. 4.8.3.3. Mindennapi tevékenységek A szolgáltatási megállapodás életbe léptetése után azonnal el kell kezdeni a szolgáltatás monito-
59
rozását és a szolgáltatásokra vonatkozó elért eredményekről riportokat generálunk napi, heti, havi rendszerességgel. A riportokban az elért eredmények és a kitűzött célok szerepelnek összevetés céljából, amelyet érdemes a megbeszélések előtt átadni a másik félnek, hogy maradjon elegendő idő azok áttanulmányozására. A szolgáltatások áttekintését rendszeres megbeszélések alkalmával lehet végrehajtani havi vagy negyedéves gyakorisággal. A szolgáltatás szinvonalának vizsgálatával kimutathatók a problémás területek. A megbeszélésen el lehet indítani a szolgáltatás javítását célzó intézkedéseket, kezdeményezhető a szolgáltatási megállapodás célok változtatása, üzemeltetési megállapodás, szerződések átvizsgálása. Amennyiben szükséges és a költségek fedezete hosszú távra biztosítható, hosszú távú Szolgáltatás Javítási Programot indíthatunk a minőség javítására, amely érinti a problémakezelés és a rendelkezésreállás menedzsment területeket is. Szolgáltatási megállapodások, szerződések, üzemeltetési szint megállapodások karbantartása. A mindennapi teendők közé tartozik a szolgáltatási megállapodások, szerződések, üzemeltetési szint megállapodások karbantartása. E dokumentumok változtatása a változáskezelés elvei szerint történjen. Biztosítsuk, hogy a célok mindig elérhetők maradjanak, vagyis a szolgáltatások megfelelően le legyenek fedve szerződésekkel, a külső beszállítói feltételek és az ügyfél igényeinek változásait is vegyük figyelembe.
4.8.4.
Előnyök
A Szolgálatási Szint Menedzsment bevezetésével járó legfontosabb előny a szolgáltatás minőségének javítása, egyenletesség biztosítása, megbízhatóságának növelése, amely pénzügyi megtakarításokat is eredményez. Az ügyfél elégedettsége növelhető, véleménye nyomon követhető. A szolgáltatási megállapodásokkal a felelősségi körök tisztázhatók, így az ügyfél tisztában van azzal, mit várhat el és a szolgáltató látja, mit kell biztosítania. Az informatikaszolgáltatás maximálisan és költséghatékonyan támogatja az üzleti folyamatokat. Az üzemeltetési megállapodások, szerződésekkel háttértámogatás révén ténylegesen elérhetők a kitűzött célok. A szolgáltatás folyamatos figyelésével és a gyűjtött adatok feldolgozásával azonosíthatók a gyenge pontok, így a szolgáltatás minősége javítható.
4.8.5.
Problémák
Egyes esetekben a szolgáltatások minőségi jellemzőit, paramétereit nem lehet egyáltalán vagy megfelelő pontossággal mérni, így nem tudható, hogy betartottuk-e a kitűzött célt. Ha a szolgáltatási szint menedzsment bevezetése előtti szolgáltatás minőségéről nincs adatunk, akkor csak becsülni tudjuk az elért eredményeket. A nem vagy nem költség-hatékonyan teljesíthető szolgáltatási megállapodás célok kitűzése elkerülhető, ha megvizsgáljuk azok elérhetőségét, mielőtt elkötelezzük magunkat. Szolgáltatási megállapodások tartalmát nem ismerik az érintett személyek, vagy nincs törekvés azok betartására. A szolgáltatási megállapodások mellőzését eredményezheti, ha annak megfogalmazása túl műszaki, vagy nem veszi figyelembe az ügyfél üzleti szempontjait.
60
4.9.
Kapacitás menedzsment
4.9.1.
Kapacitásmenedzsment célja
A kapacitásmenedzsment az üzletmenet számára biztosítja, hogy a jelenlegi és a jövőbeni igényeknek megfelelően rendelkezésre álljon a megfelelő informatikai kapacitás. A költséghatékonyságot szem előtt tartva elősegíti, hogy az erőforrások a lehető legjobban legyenek kihasználva és szükség esetén a felhasználói igényeket is befolyásolja.
4.9.2.
Fogalmak
Kapacitásmenedzsment adatbázis (Capacity Management Database, CDB) – logikailag egységes adatbázis, amely tartalmazza a szerverek, a hálózat technikai és igénybevételi adatait, üzleti adatokat (pl. kliensek, felhasználók számát) és a kapacitás tervet. Kapacitás terv – dokumentum a jelenlegi erőforrások használatát, jövőbeli felhasználások előrejelzéseit, korábban készített előrejelzések és a tényleges adatok egybevetését és a javasolt változtatásokat, beszerzéseket tartalmazza.
4.9.3.
Kapacitásmenedzsment tevékenységek
A kapacitásmenedzsment három jól megkülönböztethető részfolyamatból áll. Az üzleti szintű kapacitás menedzsment az üzleti igények figyelembevételével új szolgáltatásokat hoz létre, módosítja vagy megszünteti a meglevőket és biztosítja a szolgáltatásokhoz szükséges kapacitást. A szolgáltatás szintű kapacitás menedzsment a szolgáltatások erőforrásigényeinek feltérképezésével, jellegeinek megismerésével segíti a szolgáltatási szint követelmények betartását. Az erőforrás szintű kapacitás menedzsment az egyes konfigurációs elemek igénybevételét figyeli és elősegíti azok optimális használatát. Általános kapacitásmenedzsment tevékenységként a szolgáltatások komponenseiről adatokat gyűjtünk, ezeket analizáljuk és összehasonlítjuk a normál működéshez rendelt értékekkel. Javaslatokat teszünk, és ennek megfelelően hangoljuk a rendszert. A kapacitásmenedzsment keretén belül az alábbiakban felsorolt tevékenységeket különböztethetünk meg: Adat gyűjtés (monitorozás) Rendszermenedzsment eszközökkel a komponensek hardver és szoftver specifikus jellemzőit figyeljük. Ilyenek például a processzor, memória, input/output eszközök használata, tranzakciók válaszideje, nyomtatási sorok hossza. Az egyes szolgáltatásoknál figyelembe kell venni minden érintett konfigurációs elem erőforrás igénybevételét: szerver, hálózat, kliens. Az alapműködésnél mért adatok alapján definiálunk egy alapszintet, és ezekhez küszöbszinteket rendelünk. Adatok elemzése A normál működés adatai alapján rövidtávra (egy napra), középtávra (egy hétre) és hosszú távra (egy évre) trendeket állítunk fel, amely alapján meghatározzuk a normál szolgáltatási szintet. Amint túllépjük az így definiált küszöbszinteket, riasztásokat generálunk. A begyűjtött adatok elemzésével jelezzük előre a jövőben bekövetkező erőforrás használatot. Hangolás Az adatok elemzésével nyilvánvalóvá válhat, melyek azok az erőforrás komponensek, amelyek jobb kihasználásával, hangolásával javítható az egész rendszer teljesítménye. Hangolási technikák között szerepel a szerverek terhelésének szétosztása, diszk használat kiegyenlítése, memória használat optimalizálása.
61
Változtatás Az adatok gyűjtése, analizálása és a hangolás eredményeképpen változtatásokat hajtunk végre az éles rendszerben, amit a kockázatok minimalizálása érdekében a változáskezelés elvei szerint javasolt végrehajtani. Kapacitás menedzsment adatbázis feltöltése, karbantartása Létrehozunk egy olyan adatbázist, amelyben az üzleti tervekről, szolgáltatásokról, konfigurációs elemek technikai jellemzőiről, bővítések pénzügyi vonzatairól, erőforrás használat mennyiségéről adatokat gyűjtünk. Ezeket az adatokat felhasználva jelentéseket készíthetünk a szolgáltatások és konfigurációs elemek kapacitásának kihasználásáról, az elfogadható szint átlépéseiről, továbbá előre jelezhetjük a szükséges kapacitást. Kapacitás terv készítése Az üzleti tervek figyelembe vételével, a jelenlegi szolgáltatásokra és körülbelül két évre előre a jövőre vonatkozóan információt gyűjtünk az igénybevétel mértékéről. Megvizsgáljuk a szolgáltatási megállapodás célokat, hogy elérhető-e a jelenlegi konfigurációval vagy szükséges-e bővítés. A terv készítését a pénzügyi ciklussal összhangban készítjük el. Terhelésmenedzsment (workload management) A terhelésmenedzsment a rendszer erőforrások használatát vizsgálja az egyes felhasználói igénybevételek szerint, így az egyes terhelés összetevőinek változásakor meg lehet határozni az egész rendszer igénybevételét. Igénymenedzsment (demand management) A terhelésmenedzsment által szolgáltatott adatokat felhasználhatjuk a felhasználói viselkedés befolyásolására. Bizonyos esetekben, például a terhelési csúcsidőszakokban szükséges lehet egyes erőforrások igénybevételének korlátozása. Ezt az adott időszakra vonatkozóan emelt díjak alkalmazásával érhetjük el. Modellezés A modellezés eszközével az informatikai rendszer adott terhelés mellett mutatott viselkedését jósoljuk meg. A szimulációs vagy az analitikus módszer közül választhatunk. A szimulációs módszer esetében diszkrét események modellezésével nyerjük ki az eredményeket, a tranzakciókat programozott módon, időzítve hajtjuk végre. Pontos eredményt ad, de idő és pénzigényes, így csak ott érdemes alkalmazni, ahol kritikus a válaszidő. Az analitikus módszer esetében matematikai eszközökkel, sorbaállási elméleti módszerekkel számoljuk ki a rendszer válaszidejét. Gyors eredményt ad, de a szimulációs módszerhez viszonyítva pontatlan: 20%-os pontosság már jónak számít. Alkalmazás méretezés (application sizing) Az alkalmazás méretezés a modellezés egy speciális esete. Az alkalmazás fejlesztésekor előre becsüljük az igényelt erőforrás kapacitást, és figyelembe vesszük a szolgáltatási szinteket. A teljes alkalmazásra vonatkozóan biztosítjuk, hogy a szolgáltatási megállapodásban szereplő célok elérhetőek maradjanak. Erőforrás menedzsment (resource management)
62
Az erőforrásmenedzsment több tevékenységet foglal magába. A szerverek konfigurációs adatairól információt gyűjtünk és a hálózat topológiájáról diagrammot készítünk. A szolgáltatások sebezhetőségének vizsgálatához feltérképezzük, hogy ezek milyen rendszer komponensekből épülnek fel. Az adatkezelés részeként biztosítjuk a tároló médiákat, ezek optimális használatát, névkonvenciót dolgozunk ki, töröljük, illetve archiváljuk a nem használt állományokat, és előre jelezzük a jövőbeli tárkapacitás igényeket. A szoftver és hardver beszállítókkal fenntartott kapcsolat révén az új technológiák által nyújtott előnyöket ki lehet használni.
4.9.4.
Előnyök
Az erőforrások kapacitásának kezelésével a szűk keresztmetszet által okozott meghibásodások kockázata csökken és a tervezett változtatások felmérésével a bekövetkező teljesítményjellemzők módosulása előre jelezhető. A Kapacitásmenedzsment tevékenységek végrehajtásával, vagyis alkalmazások méretezésével, modellezéssel előre lehet jelezni a teljesítményjellemzőket az igénybevétel függvényében. A Kapacitásmenedzsment közvetlen pénzmegtakarítást eredményez, mivel lehetőség van az új eszközök megvásárlásának elhalasztására. Egy későbbi időpontra történő ütemezéssel a technológiai fejlesztéseknek köszönhetően ugyanannyi pénzért több kapacitás nyerhető. A tervezett kiadások esetében kedvezőbb árat lehet elérni, illetve mennyiségi kedvezmények is felhasználhatók. Az üzleti igények figyelembe vételével a nem használt tartalékeszközök mennyisége csökkenthető, a meglevő erőforrások igénybevételének optimalizálásával a szolgáltatásokat gazdaságos módon biztosítjuk. A kapacitásmenedzsment sikeres megvalósításával támogatjuk a többi témakört, elsősorban a szolgáltatási szint menedzsment, változáskezelés és a problémakezelés folyamatokat.
4.9.5.
Problémák
Problémát jelenthet az ügyfelek rendszerrel szemben támasztott túlzott elvárásai. Ezeket az elvárásokat kezelni kell, el kell érni, hogy tisztában legyenek a teljesítményjellemzők költség vonzataival. Egyes esetekben, például alkalmazás-méretezésnél előre figyelembe vehetők a felhasználói igények. Ha beszállítói nyomásra a szükségesnél több kapacitást szerzünk be, vegyük figyelembe, hogy mire teljesen kihasználnánk a rendszert, a használt technológia elavulhat vagy később esetleg olcsóbban juthatunk hozzá. Gondot okozhat az üzleti, illetve technikai információk hiánya. Az üzleti igények előrejelzésére nehéz pontos információt kinyerni, az események véletlenszerűségét nem lehet teljesen kizárni. Emellett az alkalmazások készítésekor, illetve több alkalmazás egy platformon történő futtatásakor nehéz megjósolni a szükséges rendszer erőforrásokat.
4.10.
Informatikaszolgáltatás pénzügyi irányítása
4.10.1. Informatikaszolgáltatás pénzügyi irányításának célja Az informatikaszolgáltatás pénzügyi irányításának célja az informatikaszolgáltatás költségeinek megértése és a költségek menedzselése a gazdaságosság elérése érdekében. Ezt a célt a költségkeret tervezés, költségkimutatás tevékenységek bevezetésével és egyes esetekben a költségterheléssel érjük el.
63
4.10.2. Fogalmak Költségkeret tervezés (budgeting) - folyamat a szervezet költségkereteinek tervezését és betartásának figyelését jelenti. Költségkimutatás (IT accounting) - folyamat számviteli módszerekkel lehetővé teszi a kiadások különböző szempontok (például vevő, szolgáltatás, tevékenység) szerinti elemzését. A kimutatás pontossága függ attól, hogy külső vagy belső ügyfélnek készítjük-e. Költségterhelés (charging) – az igénybe vett szolgáltatások ellenértékét ráterheli az ügyfélre. Költségközpont (cost centre) - üzleti egység, osztály, amelyre költséget terhelünk. Kialakítása függ a szervezet felépítésétől. Költségtípusok (cost type) - Költség elemzéséhez segítséget nyújt azok kategorizálása. A lehetséges típusok: hardver, szoftver, személyi, elhelyezési, külső szolgáltatás (amit nem tudunk az előbbi típusokba sorolni, mert külső fél szolgáltatja), transzfer (a szervezet két osztálya között felmerülő költség) Költségegység (cost unit) - Költség számolás alapja, például CPU idő, háttértároló hely, iroda alapterület, PC, szoftver licensz.
4.10.3. Informatikaszolgáltatás pénzügyi irányításának tevékenységei 4.10.3.1.
Költségkeret tervezés
A költségkeret tervezés általában évente zajlik, mely során áttekintjük az elmúlt ciklust, az aktuális projekteket, szolgáltatási szinteket és a következő évre (évekre) pénzügyi tervet készítünk. A tervezett költségeket költség típusok szerint becsüljük, amely lehetőséget ad a többi évhez történő összehasonlításra. Külön figyelmet kell fordítani azokra a költségekre, amelyek változnak az igénybevételtől függően. A mennyiségi igények változását a korábbi tapasztalati értékek és az előrejelzések vizsgálatával vesszük figyelembe. 4.10.3.2.
Költségkimutatás
A költségkimutatás mindennapi feladatai közé tartozik a költség adatok biztosítása, pontosságának ellenőrzése. A kiadások tervezett mértékétől való eltérést rendszeresen ellenőrizzük, és ha egy előre megállapított határt meghalad, akkor ezt jelezzük. A költség-kimutatási tevékenység elindításakor kialakítjuk, és a pénzügyi ciklusoknál módosíthatjuk a költség modellt és a költség egységeket. A költségmodellben az informatikaszolgáltatás összes költségét azonosítjuk és az azt igénybe vevő ügyfélre, vagy tevékenységekre bontjuk le. A költségek kezelését a költségtípusok használatával tesszük könnyebbé. A költség modell kialakításához a költségeket feloszthatjuk közvetlen (egy ügyfélhez közvetlenül rendelhető) és közvetett (az összes ügyfélhez vagy azok egy részéhez tartozó) költségekre. A közvetett költségeket igyekezzünk minél igazságosabban elosztani, de kerüljük a túlzott részletességet, mert különben a számítási módszer túl sokba kerül. Költségegységek kiszámolása A költségek kimutatásának alapjául olyan egységet érdemes választani, amellyel egyszerűen kezelhető a költség modell. Következő lépés, ezen egységek költségének kiszámítása. Mivel az alapul szolgáltató egység (pl. CPU, tárterület) igénybe vétele változhat, ezért a kalkulált árat egy meghatározott időre számítjuk, és rendszeresen újrakalkuláljuk. Egy szolgáltatásra megvizsgáljuk
64
az összes igénybe vett erőforrás, üzemeltetési támogatás adott időszakra számított költségét és az egyes összetevőkre kiszámoljuk az egységárat. A szolgáltatásra vonatkozóan a használati aránynak megfelelően kiszámítjuk a szolgáltatás költségét. Ezután a szolgáltatás adott időszakra számolt összköltségét egy költség egységre vonatkoztatjuk (Például a szolgáltatás összköltségét elosztjuk a CPU használattal), amit a továbbiakban költség egységként használunk. 4.10.3.3.
Költségterhelés
A költségterhelés a költségkimutatás tevékenységen alapul. Csak akkor érdemes kialakítani, ha ez üzleti előnyökkel jár. A költségek elszámolásakor több modellből választhatunk: Közvetlen – Az erőforrást egy jól meghatározható csoport használja. A felmerülő költséget teljes egészében (beszerzési ár, fenntartási költségek) erre a csoportra hárítjuk. Ennek előnye, hogy egyszerű megérteni és számolni vele, független a használat mértékétől. Erőforrás használat – A költségeket az erőforrás használatának mértékében számoljuk (Például CPU használat szerint). Hátránya, hogy az erőforrás használatát állandóan monitorozni kell, és a számított költség nagymértékben változik a használat mértékétől. Kimenet alapú – Egy bizonyos tranzakcióért vagy kimeneti példányért (riport, nyomtatott oldal) adott összeget számítunk. Könnyű megérteni és így a felhasználó könnyen befolyásolhatja a költséget. Részarányos – Több felhasználói csoport között megosztott erőforrások, szolgáltatások esetében akkor érdemes használni, ha nem lehet könnyen megállapítani a használat összetételét. Ilyen jellegű szolgáltatás az adatok mentése. A szétosztási arányt a többi költség arányában tehetjük meg. Piaci ár – Piaci árak figyelembevételével alakítjuk ki. probléma lehet, hogy nem tudunk ilyen alacsony árat elérni. Számlázásra vonatkozóan javasolt egy rögzített havi összeg megállapítása és év végén a különbözetek elszámolása.
4.10.4. Előnyök Az informatikaszolgáltatás pénzügyi irányítása a költséghatékonyságot szem előtt tartó üzleti célok és a technológiai újdonságok bevezetését támogató informatikai célok összehangolását segíti azzal, hogy az informatika csak arra ruházzon be, amire az üzletnek is szüksége van és megtérül. A költségkeret tervezés, költségkimutatás és költségterhelés tevékenységek által nyújtott előnyök a következők: Beszerzési és üzemeltetési költségekkel tisztában vagyunk, biztosan előre tudunk tervezni és elérhetjük a költségterv betartását. A rendelkezésre álló erőforrások költség-hatékony használata révén versenyképes működést tesz lehetővé. Az ügyfelek a költségkimutatás révén tisztán látják az igénybe vett szolgáltatások biztosításának költségeit. Az informatikaszolgáltatás szükségessége költség oldalról alátámasztható, össze lehet hasonlítani más, hasonló szolgáltatókkal. A nem gazdaságos tevékenységek kiszervezésével költségeket lehet csökkenteni. Amennyiben a szolgáltató nyílt piaci helyzetben van, lehetőség nyílik bevételének növelésére. A költségterhelésen keresztül a felhasználók viselkedésének befolyásolásával elkerülhető a pa65
zarlás, az erőforrások jobb felhasználása lesz lehetséges. Differenciális árazáson keresztül az erőforrások időbeli használatának befolyásolásával elérhető, hogy a felhasználók inkább csúcsidőn kívül használják a rendszert. Ezáltal a terhelési csúcsok elsimíthatók, a kapacitás bővítése elkerülhető, ami megtakarítást eredményez. A költségkimutatás és költségterhelés tevékenységek lehetővé teszik az informatikai költségek igazságos elosztását az összköltségek és az erőforrások használatának ismeretében.
4.10.5. Problémák Új eszközök finanszírozása (bérlés, vásárlás) likviditási problémát jelenthet. Az eszköz hasznos élettartamára írjuk le a költséget több év alatt. Az első években kevesebb lesz a bevétel, mint a kifizetett összeg és csak évek múlva egyenlítődik ki. Felesleges kapacitás jelentkezik új hardver/szoftver eszközök vásárlásakor, bővítéskor, mivel kezdetben a kihasználtság alacsony. A használat mértékével arányos árazás szerint ez drágább szolgáltatást eredményez. Csak idővel lesz a kihasználtság nagyobb, tehát több évre el kell simítani a költséget. A felhasználói viselkedés változása a szolgáltatás használatát jelentősen megváltathatja, ami instabilitást eredményezhet, és ez komoly problémát okozhat, ha nincs felkészülve az informatikai szolgáltató. Ha túl komplikált a költség modell, vagy a begyűjtött információból nem lehet megfelelően számolni, akkor az informatikaszolgáltatás pénzügyi irányítása folyamat által biztosított előnyök háttérbe szorulnak az így keletkező költségek mellett.
4.11.
Rendelkezésreállás menedzsment
4.11.1. Rendelkezésreállás menedzsment célja A rendelkezésreállás menedzsment célja az üzleti igényeknek megfelelő rendelkezésreállás tervezése, figyelése és a szolgáltatások, informatikai infrastruktúra ilyen jellegű képességeinek folyamatos javítása.
4.11.2. Fogalmak Rendelkezésreállás (availability) – az informatikai elem vagy szolgáltatás egy adott időpontban vagy időintervallumban normál működésre kész állapotát jelenti. Ez a jellemző adott időintervallumra vonatkoztatva a rendelkezésreállás tényleges és előírt értékének hányadosával jellemezhető. Megbízhatóság (reliability) – jellemzi az informatikaszolgáltatás hibatűrő képességét. Ezt a jellemzőt a szolgáltatás komponenseinek megbízhatósága és a konfiguráció kialakítások (redundancia) határozza meg. Az incidensek között eltelt átlagidővel számszerűsíthető. Karbantarthatóság (maintainability) – az informatikai elem működőképes állapotban tartását és ebbe az állapotba történő visszaállítását jellemzi. Ezt több összetevő határozza meg: meghibásodások megelőzése, hibadetektálás, diagnosztizálás, hibaelhárítás, hibás komponens helyreállítása, adatok és szolgáltatások visszaállítása, megelőző karbantartási munkák. Szervizelhetőség (serviceability) – külső fél által biztosított szolgáltatásokra vonatkozó, szerződés keretén belül biztosított rendelkezésreállási, megbízhatósági és karbantarthatósági jellemzők.
66
Biztonság (security) – a szolgáltatáshoz rendelkezésreállási jellemzője.
tartozó
adatok
bizalmassági,
integritási
és
4.11.3. Rendelkezésreállás menedzsment tevékenységek A rendelkezésreállás menedzsment tevékenységek két fő részre bonthatók. A kockázatok felmérését végző kockázat analízisre és a bekövetkező negatív hatások kezelését végző kockázat menedzsmentre. Kockázat analízis A kockázat analízis során felmérjük az informatikai erőforrásokat, meghatározzuk az őket érintő szándékos és véletlen jellegű veszélyeket, és megállapítjuk az erőforrások sebezhetőségi szintjét. Az informatikai erőforrásokba a hardver és szoftver elemeken kívül az adatok és a személyezet is bele tartozik. Kockázat analízis módszerek CCTA Risk Analysis and Management Method (CRAMM) A CRAMM módszer olyan széles körben használható eszköz, amely a technikai és nem technikai kockázatokat képes felmérni. Alapszintű informatikai ismeretekkel is lehet használni, mivel tartalmazza a biztonsági szakemberek által összegyűjtött ismereteket. A kockázat elemzést az események különböző forgatókönyvek szerinti vizsgálatával segíti. Component Failure Impact Analysis (CFIA) A CFIA egy egyszerű módszer, amelyben az informatikaszolgáltatás egyes elemeit lebontjuk komponensekre. Egy táblázatot hozunk létre, az oszlopokban a szolgáltatásokkal, sorokban az eszközökkel. A táblázat celláiban jelöljük, hogy az adott eszköz vagy komponens kiesése hogyan befolyásolja az adott szolgáltatást. Ilyen módon azonosíthatók a kritikus erőforrások és az összetett szolgáltatások is átláthatóvá tehetők. Fault Tree Analysis (FTA) Az FTA módszerrel olyan események sorát követjük, amelyek a szolgáltatás rendelkezésreállását befolyásolják. Az események együttes bekövetkezésének viszonyát logikai és / vagy kapcsolattal jellemezzük. Kockázatmenedzsment A kockázat kezelése során intézkedéseket teszünk az eszközök sebezhetőségének csökkentésére. A kockázat számításakor figyelembe vesszük az esemény hatását és a bekövetkezés valószínűségét. A kockázatok kezelése olyan intézkedésekben nyilvánul meg, amely a tervezést és az infrastruktúra kialakítást is magában foglalja. A fizikai környezet kialakításánál a számítástechnikai központok elhelyezkedését, az infrastruktúra elrendezését és a környezeti paramétereket meghatározó tényezőket (klíma, áramellátás) vesszük figyelembe. Az elhelyezkedésnél a szabotázs, árvíz, robbanásveszély és egyéb katasztrófákat igyekezünk elkerülni, illetve készülünk fel a hatás csökkentésére. Elrendezést tekintve a hardver egységek több helyszínen történő elhelyezésével készülünk fel. A kritikus hardver egységeknek megfelelő környezeti tényezőket biztosíthatunk klíma berendezés, szünetmentes tápegység, generátor alkalmazásával.
67
A számítástechnikai központ környezetének kialakításánál a fizikai hozzáférést, az adatok biztonságos kezelését, tárolását, archiválását vesszük figyelembe. Az adattároló médiát tűzbiztos páncélszekrényekben, lehetőleg távoli helyen ajánlott tárolni. Hardver kiépítésnél javasoltak a fürtözött megoldások, a komponensek - CPU, hálózati kártyák, diszkek - redundáns kialakítása. A hálózat kialakításánál fontos szempont az alternatív útvonalak, több csatlakozási pontok kialakítása. Az eszközök mellett a kulcsszerepet betöltő emberek helyettesíthetőségére is gondoljunk. Biztonsági szempontból figyelembe vesszük a szolgáltatáshoz tartozó adatok bizalmassági, integritási és rendelkezésreállási jellemzőit. Tehát csak a megfelelő jogosultsággal rendelkező személy férhessen hozzá az adott szolgáltatáshoz és adathoz. Az adatok módosítás nélkül, sértetlenül álljanak rendelkezésre, akár egy szolgáltatás kiesés után is. Emellett a szolgáltatási megállapodásban előírt időben hozzáférhetők legyenek az adatok.
4.11.4. Előnyök A rendelkezésreállás menedzsment tevékenységek sikeres megvalósításával elérhető, hogy kevesebb megszakítás történjen az informatikaszolgáltatásban. Amennyiben mégis bekövetkezik a leállás, a gyors helyreállítással minimalizálható az üzletmenetre gyakorolt kedvezőtlen hatás. A leállási idők csökkentésével közvetlen a pénzügyi veszteségek csökkenthetők, vagy elkerülhetők. A karbantarthatósági és a szervizelhetőségi tevékenységek menedzselésével a kitűzött célok elérése mellett kézben tarthatók a kiadások. A szolgáltatási szint menedzsment tevékenységet nagymértékben támogatja a reális célok megállapításával, a szolgáltatások rendelkezésreállási jellemzőinek figyelésével, az adatok elemzésével és jelentésével, továbbá a kitűzött célok elérésében. Szorosan együttműködik a kapacitásmenedzsmenttel a szükséges erőforrás kapacitás tervezésével és a használat monitorozásával. Emellett az informatikaszolgáltatás-folytonosság menedzsment tevékenységet egészíti ki a hibatűrő rendszerek kialakításával, mert csökkenti a szolgáltatás kiesésének esélyét.
4.11.5. Problémák Nehézséget jelenthet a kiadások igazolása, mivel a redundáns kialakítások kihasználatlan rendszereknek tűnnek. Akkor lehet a rendelkezésreállás menedzsment hatékony, ha léteznek az ezt támogató problémakezelés, incidensmenedzsment, szolgáltatási szint menedzsment, és egyéb támogató folyamatok. Megfelelő eszköz hiányában adatgyűjtési és feldolgozási nehézségek léphetnek fel. Például nincs információ a szolgáltatás kiesésének vagy komponens meghibásodásának kezdeti és végső időpontjáról, illetve nem tudjuk a rendelkezésreállás számítását automatizálni. Problémát jelenthet a külső szolgáltatóktól való függés, mivel az általuk vállalt elhárítási idők meghatározzák a vállalható szolgáltatási szint célokat. Nehéz lehet az üzleti igények meghatározása a rendelkezésreállásra vonatkozóan. Emellett részletesen kell ismerni az informatikai infrastruktúra komponenseinek egymáshoz való kapcsolódását az egész szolgáltatásra számított rendelkezésreállás számításához. Ehhez a konfigurációs adatbázis nyújthat segítséget.
68
4.12.
Informatikaszolgáltatás-folytonosság irányítása
4.12.1. Az informatikaszolgáltatás-folytonosság irányításának célja Az informatikaszolgáltatás-folytonosság irányítása a teljeskörű üzletmenet-folytonosságot támogatja az informatikaszolgáltatás, infrastruktúra üzleti igényeknek megfelelő, elfogadott időn belül történő visszaállításával.
4.12.2. Fogalmak Tartalék elrendezés (stand-by arrangement) – az üzletmenet megszakadása esetén a használhatatlanná vált elsődleges eszközök helyettesítésére szolgáló tartalék eszközöket tartalmazó létesítmény vagy megoldás. Ez rendszerint az eszközök és a személyzet elhelyezésére szolgáló helyiségeket, informatikai és telekommunikációs rendszereket, hálózatokat és esetleg megfelelően képzett embereket jelent. Hidegtartalék (cold start, cold standby) – olyan hordozható vagy helyhez kötött létesítmény, amelyben alap infrastruktúrával (kábelezés, áramellátás) rendelkező számítógép központ van. Szükséghelyzetben az ügyfél először a tartalék szervereket elhelyezi a létesítményben, majd a saját szoftvereit, archivált adatait erre az infrastruktúrára állítja vissza. Forrótartalék (hot start, hot standby) – olyan létesítmény, amelyben az eszközök azonnal képesek a szoftverek, archivált adatot feltöltésére és futtatására.
4.12.3. Az informatikaszolgáltatás-folytonosság irányításának tevékenységei Az informatikaszolgáltatás folytonosságát nem elszigetelten, hanem az üzletmenettel egységesen kell kezelni. A tevékenységeket idő szerint négy részre bonthatjuk. A kezdeti tervezésre, a követelmények meghatározása és stratégia kidolgozására, a megvalósításra és az üzemeltetési feladatok fázisára. Kezdeti fázis Kidolgozzuk, és nyilvánosságra hozzuk az informatikaszolgáltatás folytonosságára vonatkozó elvi szabályozást, amely az üzletmenet folytonossággal összhangban van. Definiáljuk a felelősségi köröket, a kockázat felmérési és hatás elemzés tevékenységek terjedelmét, biztosítjuk a pénzügyi és emberi erőforrásokat. Mivel az informatikaiszolgáltatás-folytonosság irányítása összetett feladatokat tartalmaz, amelyet hatékonyan kell működtetni, ezért különös hangsúlyt kap a projekt szervezet kialakítása. E fázis végén a változások hatékony kezelése érdekében és a minőségi célok eléréséhez projekt tervet készítünk. Követelmények meghatározása és stratégia kidolgozása Ebben a fázisban az üzletihatás elemzéssel és a kockázat felméréssel meghatározzuk a követelményeket és a kockázat-csökkentési lehetőségek vizsgálatával, kidolgozunk egy stratégiát. Üzletihatás elemzés (Business Impact Analysis) A követelmények meghatározásában döntő, hogy az üzletmenet milyen mértékű szolgáltatás kiesést képes elviselni, illetve a veszteségek milyen gyorsan jelentkeznek a kiesések növekedésével. Az üzletihatás elemzés célja e következmények felmérése. Az elemzés meghatározza a kritikus szolgáltatásokat és a szolgáltatások kiesése által okozott veszteségeket. Ezen kívül foglalkozik a közvetett hatásokkal: elmaradt bevétel, járulékos kiadások, az ügyfelek bizalmának elvesztése. Meghatározza a kritikus szolgáltatások minimálisan elfogadható szintjéhez szükséges sze-
69
mélyi, infrastrukturális és szolgáltatási előfeltételeit. Előírja a szolgáltatások, a személyzet minimálisan elfogadható, illetve a teljes szint biztosításának határidejét. Kockázat felmérés A követelmények meghatározásának másik fontos tényezője a kockázatok felmérése, vagyis a katasztrófa vagy szolgáltatás kiesés bekövetkezésének valószínűsége. A kockázat felmérés - a rendelkezésreállás menedzsment tevékenységnél ismertetett módon -, a kockázat analízisből és a kockázat menedzsmentből áll. Kockázat analízis A kockázat analízis során felmérjük az informatikai erőforrásokat, meghatározzuk az őket érhető szándékos és véletlen jellegű veszélyeket, megállapítjuk az erőforrások, szolgáltatások kiesésének valószínűségét és azt, hogy ezáltal a szervezet működése milyen mértékben érintett. Kockázat menedzsment A kockázat kezelése során intézkedéseket teszünk az eszközök sebezhetőségének csökkentésére. A kockázat számításakor figyelembe vesszük az esemény hatását és a bekövetkezés valószínűségét. Visszaállítási lehetőségek felmérése Általános értelemben a visszaállítási lehetőségeket az emberek, informatikai rendszerek, hálózatok, kritikus szolgáltatások, kritikus eszközök tekintetében kell megvizsgálni. Az alábbiakban az informatikai jellegű visszaállítási lehetőségekről lesz szó. Nagyon ritkán használt megközelítési mód lehet, hogy semmit sem teszünk. Ebben az esetben a vezetésnek tudatosan kell vállalnia ezt a választást. A tevékenységek olyan mértékben támaszkodnak az informatikára, hogy a papír alapú, manuális visszaállítás gyakorlatilag lehetetlen lenne. Sokszor a számítógépes rendszerben levő nyomtatványokról, adatokról nincs aktuális nyomtatott példány. Közbenső megoldásnak, amíg a számítógépes rendszer nem működik, lehet egy praktikus eszköz, de a teljes rendszerre nem alkalmazható. Reciprok (kölcsönös) elrendezés esetében a hasonló technológiát használó szervezetek egymás számára biztosíthatnak számítástechnikai kapacitást. Ez a megoldás elsősorban akkor volt használható, amikor nagyszámítógép alapú adatfeldolgozás zajlott. A jelenleg elterjedt elosztott rendszerek miatt nehezen biztosítható ez a hasonlóság, és emellett üzemeltetési, biztonsági kérdések is felmerülnek. Az adatok biztonsági másolatának tárolására viszont előnyös lehet ez a módozat. Fokozatos visszatérést lehetővé tévő hideg tartalékot olyan szervezetek választják, amelyek a szolgáltatás kiesése után legalább 72 órán keresztül képesek elviselni az informatikaszolgáltatás teljes vagy részleges hiányát. A hideg tartalékként szolgáló számítástechnikai létesítményt külső szolgáltatótól vehetjük igénybe, vagy belsőleg is kialakíthatjuk. Mivel a hardver eszközöket és a szoftvereket üzembe kell állítani, gondolni kell a beszerzés okozta késedelmekre. Mérjük fel az egyedi hardver kiépítéseket, amelyek beszerzése nehézségekbe ütközhet és határozzuk meg azokat az eszközöket, amelyekkel ezek helyettesíthetők. Közbenső visszatérést lehetővé tévő meleg tartalékot olyan szervezetek választják, amelyeknél az informatikaszolgáltatást meghatározott időn belül, tipikusan 24 és 72 óra között vissza kell állítani. Ennél a módozatnál a szolgáltató mobil vagy fix elhelyezkedésű számítástechnikai központot biztosít. A központ teljesen kiépített, szerverekkel, technikai személyzettel el van látva. A vissza-
70
térési időt befolyásolja, hogy a szervezet alkalmazásait telepíteni kell, az adatokat fel kell tölteni és az egyedi konfigurációnak megfelelően be kell állítani a tartalék rendszert. Azonnali visszatérést támogatja a forrótartalék elrendezés, amelyet azok a szervezetek választják, amelyeknél a szolgáltatás megszakítását követő legfeljebb 24 órán belül vissza kell állítani a teljes informatikaszolgáltatást. Az éles rendszernek megfelelő szerverek és alkalmazások futnak a tartalék rendszeren és az adatok replikálva vannak. Így az éles rendszer kiesésekor a kritikus szolgáltatások kiesés nélkül elérhetők, a többi szolgáltatást pedig a 24 órás határon belül lehet visszaállítani. Megvalósítás A megvalósítási fázis lépései az alábbiak szerint alakul. A szervezetet alkalmassá tesszük a katasztrófa helyzetek kezelésére. A vezetők feladata a jóváhagyások, egyes szervezeti egységek, média, szabályozó szervezetek, egyéb külső szervek közötti kapcsolat biztosítása. A koordináló csapat a szervezet egész tevékenységét hangolja össze. Az informatikaszolgáltatást visszaállító csapat a szolgáltatások és alkalmazások szerint tevődik össze. A katasztrófa helyzet esetén végrehajtott tevékenységek megtervezésekor létrehozunk egy magas szintű tervet, amely az egész szervezetre vonatkozik. Ezután az egyes támogatást nyújtó területekre, mint például a számítástechnika, biztonság, telekommunikáció, elhelyezés, személyzet, pénzügy, létrehozunk egy-egy specifikus tervet. Minden terület a saját tervéért felelős, kidolgozza a végrehajtandó eljárásokat és megvizsgálja, hogy az adott terület megfelelően van-e támogatva erőforrással és külső szolgáltatásokkal. A rendelkezésreállás menedzsment tevékenységgel karöltve kockázat csökkentési lépéseket hajtunk végre, amellyel a szolgáltatás kiesésének idejét és bekövetkezésének valószínűségét csökkentjük. Kiválasztjuk a szervezet számára legelőnyösebb visszatérési lehetőséget és megkötjük a szükséges szerződéseket, előkészítjük a létesítményeket. Egy informatikaszolgáltatás-folytonossági tervet készítünk az üzleti szempontból kritikus szolgáltatásokra. Ez nem csak a visszaállítás módját adja meg, hanem leírja a szolgáltatások egymás közötti függőségi viszonyát, tesztelését és az adatok ellenőrzését is. A tervben olyan szinten dolgozzuk ki az eljárásokat, hogy azt az adott feladathoz szükséges képzettséggel rendelkező bármilyen személy végre tudja hajtani. Tartalmazza a hardver és szoftver követelményeket, adat visszatöltési pontokat, konfigurációs részleteket és (funkcionális, adat-konzisztencia) ellenőrzési pontokat az összes visszatérési pontra vonatkozóan. Csak akkor lehetünk biztosak egy kiválasztott stratégia működőképességében, ha az elkészített tervet leteszteltük. A kezdeti elméleti szintű ellenőrzést követően a lehetőségekhez mérten érdemes minél életszerűbben végrehajtani azt, egy adott szituációnak megfelelően. Üzemeltetési feladatok A tervezés és a megvalósítás után biztosítjuk, hogy az előírt folyamatok a mindennapi tevékenységek részévé váljon. Figyelem felkeltés, tájékoztatás révén érhetjük el, hogy mindenki tisztában legyen az üzletmenetés az informatikaszolgáltatás-folytonosság témakörével. A visszaállítási tevékenységet végző csapatot szakmailag fel kell készíteni a feladatok végrehajtására. 71
Felülvizsgálatot végzünk rendszeres időközönként, illetve az informatikai infrastruktúra jelentős változtatásakor vagy az üzleti tevékenység megváltozásakor. A kezdeti tesztelés után rendszeres időközönként hajtunk végre a kritikus részekre koncentráló teszteket, amellyel biztosítjuk, hogy az időközben végrehajtott változtatásokat megfelelően figyelembe vettük. Az informatikaszolgáltatás-folytonossági tervet és a szolgáltatókkal kötött megállapodásokat a változáskezelés hatásköre alá vonjuk, így biztosítva a változtatások átvezetését. Az informatikaszolgáltatás-folytonossági terv életbe léptetését egy kríziskezelési csoportnak kell jóváhagyni. Az egyes helyszíneken, csoporttagoknál kell lenni egy leírásnak, amelyben szerepel a tervek helye, értesítendő személyek elérhetőségi információja, kulcsfontosságú lépések, döntési pontok leírása.
4.12.4. Előnyök Az informatikaszolgáltatás-folytonosság irányításának megvalósítása esetén a krízis helyzetek után a szolgáltatások visszaállítása ellenőrzött módon zajlik. Mivel az elvégzendő teendőket koordináltan és begyakoroltan hajtják végre, nagyobb esély van a sikeres visszatérésre. Az informatikaszolgáltatás-folytonossági terv és folyamat használatával a szolgáltatás kiesésének ideje csökkenthető, nagyobb szolgáltatás folyamatosság érhető el. Az elvesztett adatok mennyisége minimalizálható, a biztonsági kérdéseket megfelelően kezeljük. Az üzleti tevékenységek kiesése minimalizálható és az üzlet által elfogadott szintre csökkenthető. Sokszor törvényben kötelezően előírt követelményeknek kell megfelelni, amelynek hiányában (ha nincs tesztelt megoldás a katasztrófa helyzetek kezelésére) büntetések, szankciók lépnek érvénybe. Az informatika és üzletmenet közötti kapcsolat javítható, az üzleti igényeket informatikai oldalról megközelítve jobban meg lehet érteni. Részletesen meg lehet ismerni az informatikaszolgáltatás kiesése által okozott veszteségeket, előre lehet számolni a kiesési idővel és a szolgáltatások átmeneti időszakra vonatkozó minőségi szintjeivel. Amennyiben egy cégnek létezik az informatikaszolgáltatás folytonosságára vonatkozó politikája, ezt marketing eszközként lehet felhasználni és ez által üzleti előny érhető el. Emellett jelentősen befolyásolhatja a cég befektetők általi megítélését. A kockázat elemzések és az ellenintézkedések kiadásainak felmérésével megfelelő pénzügyi erőforrást lehet fordítani a szolgáltatások folytonosságának biztosítására.
4.12.5. Problémák Problémát jelenthet a felső-vezetés elkötelezettségének hiánya, ezáltal az informatikaszolgáltatás-folytonosság irányításának tervezéséhez és karbantartásához szükséges pénzkeret és emberi erőforrás nem biztosítható. A mindennapi tevékenységek elvégzése mellett külön időt kell biztosítani az ilyen jellegű feladatokra, különben nehéz megnyerni erre a felhasználókat. Az informatikaszolgáltatás-folytonosság irányításának tevékenysége a felső-vezetés szempontjából nem megtérülő beruházást jelent, ezért sokszor jelentkezik a pénzügyi támogatás hiánya. Ezt olyan biztosítás jelegű befektetésnek kell tekinteni, amely az üzletmenet folytonosság része.
72
A szolgáltatás visszaállítási tervek kidolgozása után azokat rendszeresen tesztelni kell, ami az éles rendszer működtetése mellett erőforrás hiányt eredményezhet. Sokszor azt gondolják, hogy a terv kidolgozása után nem kell azokkal foglalkozni. De a tervek rendszeres frissítéséről gondoskodni kell, a változásokat át kell vezetni, mert módosulhat a szolgáltatások prioritása, technológiák, visszatérési lépések menete.
73
5. 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 .
5.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.
5.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.
5.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
74
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.
5.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ál75
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ó:
76
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.
5.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.
77
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.
5.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.
5.2. tása
Vevőszolgálati rendszer kialakítása és a szolgáltatásmenedzsment támoga-
5.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.
5.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 78
„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é.
5.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é
79
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.
5.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 5.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.
80
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. 5.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. 5.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. 5.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. 5.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:
5.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. 81
5.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ó. 5.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. 5.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. 5.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.
5.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.
82
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.
5.3.
Az informatikai infrastruktúra üzemeltetés kiszervezése
5.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-
83
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.
5.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.
5.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,
84
é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.
5.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.
5.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-
85
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.
5.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
86
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
5.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
5.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
87
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.
5.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.
5.4.
Egy alkalmazásüzemeltetés felügyeletét előkészítő projekt
5.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ése2, é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ó 300350 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
2
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.
88
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.
5.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
89
•
Ü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. ACTIVITY
INPUT
CONFIGURATION MANAGAMENT
OUTPUT
SW library SLA Configuration DB
effect
monitoring
ERROR MANAGAMENT
error detect
correct lezárás
event
support
uncovering allowance
CHANGE MANAGAMENT
develop mentmaintenance demand of change
execution demand of change
execution
layout
VERSION MANAGAMENT
decision preparation of decision
upgrade
execution demand of change
expect of business
CAPACITY MANAGAMENT
execution
allowance expect of technology
demand of change
execution execution
90
5.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
KFKI ISYS
FRIESLAND
Jelentések, statisztikák
Jelentések, statisztikák
EX3
IN 2
HD2
Üzleti folyamat felelõs Supervisor
MFG Rendszerfejlesztõ
Nutricia
EX3
QAD Answare Center
KFKI ISYS
IN 0-2
HD 2
IT menedzsment
Data Center
EX3
EX 0-3
Alkalmazás / Adatbázis adminisztrátor
LAN Hálózatadminisztrátor
KFKI ISYS
Kiemelt telephely
IN2
IN 0-1 Rendszergazda
Nutricia
Nutricia
HD2
EX3
IBM Help-Desk / szervíz / Answare Center
Szerver felügyelet Jelentés
Üzleti folyamat felelõs
Kiszállás
WAN szolgáltató I. HelpDesk / Szervíz
Riasztás/értesítés
EX3
Esemény Esemény Kulcsfelhasználó
Végfelhasználó
Nutricia
WAN szolgáltató II. HelpDesk / Szervíz
Nutricia
Esemény
EX3
Esemény
Esemény
EX 0-1
DC szerver-adminisztrátor monitorozás, végrehajtás
Ellátó depó
IN2
Változásügyi Döntőbizottság
RDB
Rendkívüli Döntőbizottság
HL 0
Hotline 0. szintű támogatás
HD 1
Help-Desk 1. szintű támogatás
IN 2
Saját szakértő 2. szintű támogatás
EX 3
Külső szakértő 3. szintű támogatás
Nutricia
Esemény
VDB
Nutricia
HL0-1
Esemény: főidő
Végfelhasználó
Esemény
Változásügyi Tanácskozó Testület
Rendszergazda
Esemény
VTT
Kulcsfelhasználó
Help-Desk
Nutricia E-mail
Ellátott depó Monitoring
Kulcsfelhasználó
Végfelhasználó
Konfigurációs adatbázis
Eljárás SLA
SW könyvtár
91
5.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. 5.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. 5.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.
92
5.4.2.1.4.
Help-Desk szolgáltatás
A 24 órás 365 napos Help-Desk szolgáltatás nagy létszámú sokirányú magas szintű IT szakértelmet igényel, ezért javasoltuk ennek a feladatnak olyan szolgáltatóhoz történő telepítését, aki rendelkezik mindazon szaktudásokkal, ami egy ilyen komplex rendszer üzemeltetéséhez szükséges, és rendelkezik mindazon felügyeleti szoftverek és Help-Desk szoftvert bevezetési és üzemeltetési tapasztalattal, ami a magas szintű szolgáltatáshoz szükséges. 5.4.2.1.5.
Alkalmazás-, adatbázis- és szerverfelügyelet
Az MFG/PRO alkalmazás szempontjából kiemelten fontos kérdés a szerverek és operációsrendszereik (UNIX és NT platform), valamint a Progresses adatbázis felügyeleti feladatok egy kézben tartása, nem elválasztva az alkalmazás felügyeleti feladatoktól. Ennek oka, hogy a rendszerelemek egy kényes és nagy tapasztalatot igénylő összehangolt beállítást igényelnek, melyek független átállítása, hangolása az egész rendszer bizonytalanságához vagy nem kellően hatékony (lassú) működéséhez vezethet. Éppen ezért semmilyen rendszer elem verzióváltását nem javasoltuk a rendszerintegrátori szakértelem bevonása nélkül. Az alkalmazás kezdeti használatbavételekor az első 8-12 hétben fokozott rendelkezésreállás szükséges elsősorban a logisztikai területeken folyó munka begyakorlásáig. Ugyancsak emelt rendelkezésreállási szint tartását javasoltuk az első éves pénzügyi zárásig, a tárgyévet követő év februárig. Az ezt követő időszak már csak a változáskezelési kérdések és a rendkívüli események lekezeléséhez igényel folyamatos partnerkapcsolatot a bevezető cég és a megbízó cég között. Ehhez a munkához nem csak az üzleti folyamatok és a szoftver kezelés magas szintű ismerete szükséges, hanem az adatbázisok belső adatszerkezetének és a rendszer megoldási algoritmusainak tág lehetőségeit is szükséges ismerni. A verziók összehasonlítása alapján, javasoltuk, hogy a teljes szerver, adatbázis és alkalmazás felügyeletet egy szolgáltatóra bízni. Ugyancsak szükségesnek tartottuk, hogy a rendszer felügyeletet ellátó szolgáltatónak legyen rálátása a lokális hálózatra, lehetőség szerint a desktopok beállításáig. Ez sokban segíti és egyszerűsíti a hibabehatárolási és karbantartási feladatok ellátását. 5.4.2.1.6.
WAN-LAN felügyeletszolgáltató
Szükségesnek tartottuk az országos, illetve lokális hálózatok egységes távfelügyeletének biztosítását. Olyan szolgáltatók kiválasztását javasoltuk, aki az alkalmazott routerek, switchek távoli ellenőrzését és hangolását biztosítja. A távfelügyeletet ellátó cégnek rendelkeznie kell az esetleges javítás idejére kellő számú csereeszközzel, amivel a meghibásodott aktív eszközök cseréjét el tudja végezni, vagy végeztetni max. 2-3 órán belül, az ország bármely pontján. (Ez az idő regionális központokban elhelyezett tartalék berendezésekkel csökkenthető) 5.4.2.1.7.
Desk - Top felügyelet és karbantartás
Amennyiben a rendszerben használt Desk-Top-ok korszerűsége lehetővé teszi, akkor az alkalmazásra kerülő monitoring rendszer teljeskörűen biztosítani tudja a Desk-Top-ok távfelügyeletét. Ennek elsősorban az egységes beállítás és szoftver upgrade biztosítása a feladata, ami hozzájárul a beállítási és rendszer kompabilitási hibák minimalizálásához, és lehetővé teszi a legkevesebb élőmunka ráfordítással végrehajtható egységes szoftverfrissítést. A Desk-Top felügyeleti rendszer segíti a Desk-Top karbantartással megbízott cég munkáját is. Addig, amíg a Desk-Top felügyelet megoldását a Nutricia központjában vagy a Help-Desk szolgáltatásnyújtónál javasoltuk megvalósítani, addig a PC szervizt kezdetben a Nutricia meglévő IT munkatársaival, később azonban országos lefedettséget biztosító külső szolgáltatóval javasoltuk
93
megoldani, aki 4 órán belül bárhol biztosítani tudja a megjelenést és szükség esetén tartalék alkatrészt, illetve cserekészüléket. A nyomtató felügyeletre a Nutirciának ma is teljes körű javítási szolgáltatást biztosít a szállító cég. 5.4.2.1.8.
Szerver karbantartás
A garancia lejárta után a nagy értékű és egyedi szerver esetleges meghibásodása esetén csak a gépet szállító IBM tud megfelelő alkatrész utánpótlással gépjavításra vállalkozni. A különböző szintű rendelkezésreállási szolgáltatások közül a kockázat értékelés alapján lehetett kiválasztani a megfelelő szintű szolgáltatást. 5.4.2.2. Az üzemeltetéstámogató technológiák 5.4.2.2.1.
Help-Desk szolgáltatást támogató szoftver
Javasoltuk, a Help-Desk szolgáltatás központi nyilvántartását és a javítási változáskezelési eljárások követését az erre a célra fejlesztett szoftver segítségével. A Help-Desk szolgáltatást támogató szoftvernek biztosítani kell az •
események követhetőségét;
•
a javítások visszakereshetőségét;
•
a korábbi megoldások rendezett tárolását és visszakereshetőségét (tudásbázis).
•
A teljes körű konfigurációkezelést, ami magába foglalja a hardver és szoftver eszközök, valamint az alkalmazás elemeinek adatait és állapotára vonatkozó információkat, valamint automatikusan csatolja a Help-Desk adminisztráció alapján, a velük kapcsolatos eseményeket.
•
A Help-Desk szoftver kell, hogy támogassa a szolgáltatókkal a szerződések szerinti eszkalációs eljárásokat és ezek kiértékelését.
•
Segítse az üzemeltetés hatékonyságát mérő riportok és kimutatások készítését.
5.4.2.2.2.
Hálózat és szerver felügyeleti technológia
Ugyancsak szükségesnek tartottuk a rendszer folyamatos felügyeletére szolgáló monitoring rendszer használatát. A Nutriciánál alkalmazott rendszer igen összetett informatikai környezetet igényel. Nagyszámú felhasználót kell kiszolgálni heterogén, többfajta operációs rendszerből, hálózatból és adatbázisból álló elosztott rendszerben. A földrajzi megosztottság még tovább növeli a komplexitást. A fentiek értelmében olyan Rendszermenedzsment (rendszer felügyeleti szoftverek) eszközre van szükség, amely hiba előrejelzéssel, távvezérléssel, automatikus javító eljárásokkal, adminisztrált mentési folyamatokkal, optimalizált erőforrás kezeléssel segítenek az üzemeltetésben és az esetleges probléma megoldásában. A hálózatokat (rendszereket) központosítottan üzemeltető szoftverek funkciói: •
távvezérlési funkciók segítségével átveszi a távoli gép irányítását, segíti a felhasználó munkáját, már az új alkalmazás betanítási szakaszában is
•
a felügyelt szerver állapotát lekérdezi, és az előre beállított határértékek elérésénél riaszt.
•
hardver-, és szoftverlistát készít a kliensekről. (a 32 bites operációs rendszerrel működő számítógépekre vonatkozik)
94
•
automatikus szoftverterítés, installáció és korszerűsítés hálózaton keresztül.
•
nyomon követhetők a rendszer terhelései
•
aktív résztvevőként felderíti, és automatikusan korrigálja a lehetséges problémákat (pl.: naplózás terület növelése, processzek tuningolása, stb.)
•
összegyűjti az eseményeket a hálózatról, és a beállított határértékekhez viszonyítva meghatározza és elindítja a szükséges automatikus válaszlépést.
•
a hálózat feltérképezését végzi, a hálózati változásokat figyeli, összegyűjti a hálózat teljesítményadatait.
•
felhasználók, csoportok menedzselése.
•
rendszerek, szerverek és a futtatott alkalmazások valós idejű távvezérlését biztosítja LAN és WAN környezetben.
•
precíziós adatmentési és visszatöltési alkalmazás, a kliens gépekre és a szerverekre.
Felügyeleti szoftver hiányában a rendszer üzemeltetője, csak akkor szerez tudomást egy esemény bekövetkeztéről, amikor azt a felhasználó bejelenti a rendszer leállást vagy rendszer lassulást, monitoring eszköz hiányában a bejelentett hiba csak jelentős késedelmek árán hárítható el. A hálózati eszközök által generált nagy mennyiségű üzenet egy jól beállított felügyeleti szoftvereszköz hiányában áttekinthetetlenné válik. Egy olyan intelligens, kifinomult megoldásra van szükség, amely az üzenetek nagy részét maga lekezeli és csak a külső beavatkozást igénylő esetekre ad riasztást.. A javasolt szoftver alkalmazása nélkül nem oldható meg proaktívan a nagy távolságú öszszeköttetések és a hálózati eszközök felügyelete. 5.4.2.2.3.
Alkalmazásfelügyeleti szoftver
A rendszer lehetővé teszi a rendszer terheléséből adódó események szimulálását. Képes vizsgálni a különböző menüpontok egyidejű indításából vagy az azonos menüpontok több végfelhasználó általi egyidejű indításának hatását a teljes infrastruktúrára, azaz a szerverekre és a hálózatra egyaránt. Az eszköz megfelelő alkalmazása esetén lehetőség van a hálózaton egy időben futó eltérő alkalmazások egyidejű terhelésének és a válaszidők vizsgálatára is. Támogatást nyújthat a különböző eszközök (hw és sw) változásának hatás vizsgálatára és a rendszer szűk keresztmetszeteinek behatárolására. Ezeket a rendszereket a teszteket mind a bevezetési eljárás során, mind az éles üzemi működés mellett el lehet végezni. A szoftver használata lehetőséget teremt az éles üzemi tesztnél a teljes hálózati hardverszoftver megoldás szűk keresztmetszeteinek feltárására és a megfelelő válaszidők kontrolljára. 5.4.2.3. Következtetések Amikor áttekintettük a feladatot, annak nagyságát és kiterjedtségét, az első teendőnk az volt hogy olyan megfelelő módszertant találjunk, ami megfelelő útmutatást ad egy ilyen bonyolult, nagy volumenű, integrált rendszerhez. Azzal is számolnunk kellett, hogy a feladat bonyolultsága miatt ügyfelünknek számos esetben nem volt határozott elképzelése az elvárásokról. Miért pont az ITIL-re esett a választás? Az előzőek alapján látható, hogy az ITIL módszertan látványosan fejlődik. A legfontosabb hatása az alkalmazás-kiszolgálásnak a jelenlegi hardver és szoftver beszerzések ésszerűsítése. A legfontosabb előnyök közé tartozik a nem tipikusan a vállalatok fókuszába tartozó informatikai terve-
95
zési, üzemeltetési feladatok csökkentése. Így felszabadul, illetve megspórolható az informatikai rendszerek implementációjával és karbantartásával foglalkozó munkaerő. Nagy vonzerő lehet az új alkalmazás bevezetésének gyorsasága: az akár egy évet is igénybe vevő idő lerövidülhet néhány hónapra. A szolgáltatási szint szerződések (SLA) pontjainak megfogalmazását nem árt szakértőkre, szakemberekre bízni, s referenciákat kérni, vagy esettanulmányokat megvizsgálni, hiszen előfordulhat, hogy a nem kellőképpen megtervezett rendszer bevezetése hosszabb távon költségesebb lehet a saját beruházásnál Úgy tűnik, az elkövetkező két-három évben a kis- és középvállalkozások lesznek az informatikai cégek céltáblái. Mivel Magyarországon a vállalatok egyelőre nem értékelik kellőképpen az ITIL modell nyújtotta lehetőségeket a kínált alkalmazások tekintetében, valamint a közszolgálatok forráshiánnyal küszködnek, remélhetőleg a piac érettsége meghatározó lesz a tradíciók megváltoztatásában. A jövőben csak a komplex IT projekteknek van hosszú távon esélyük a talpon maradásra, valamint nagy jelentősége van a felhasználó igényeihez való maximális alkalmazkodásnak is.
5.5.
Kiszervezés ITIL alapján
5.5.1.
Cégjellemzők
5.5.2.
5.5.3.
•
Multinacionális telekommunikációs cég (UPC)
•
Erős függés az informatikaszolgáltatástól
Helyzetkép •
bejelentési módok: telefon, e-mail, papír, személyes
•
bejelentések rögzítése: nincs
•
a munka objektív eszközökkel nem mérhető, az eseményeket nem lehet visszakeresni
•
nincsenek szintidők
•
nincs informatikai eszköz, és szoftverleltár
•
nem világos, milyen folyamatot kell elvégezni - ami az erőfeszítések többszörözését, rossz megoldásokat, sorozatos megtorpanásokat okoz, emiatt túl hosszúak lesznek a reagálási, javítási idők, növekszik az ideges és frusztrált felhasználók száma.
•
az egyes folyamatokat nem lehet nyomon követni és bizonytalan lefolyásúak.
•
a tevékenységeket ellátó személyzetnek nincsenek egyértelmű felelősségi körei, feladatai, mivel elszámoltathatatlanok, ha a folyamat elakad, nincs felelőse, az informatikai személyzet tagjai feladatkörükön kívüli problémákba bonyolódnak.
Megvalósítandó feladatok •
720 felhasználó, 772 asztali számítógép, 215 nyomtató karbantartása felügyelete.
•
39 telephely az országban: 12 Budapesten, 27 vidéken
96
•
munkaidőben helyszíni, azon kívül telefonos és helyszíni segítségnyújtás
•
felhasználói igényekre koncentráló informatikaszolgáltatást nyújtsunk
•
az informatikaszolgáltatást a szervezeti céloknak rendeljük alá
•
költség-hatékonyság
•
javítsuk a rendszerek megbízhatóságát, és rendelkezésreállását
•
megalapozott szolgáltatási minőségi szinteket határozhassunk meg, és mérhessük a szolgáltatások minőségét,
•
növeljük a hatékonyságot, javítsuk az eredményességet, és csökkentsük a kockázatot,
•
javítsuk a munka-gyakorlatot a kiváló minőség érdekében.
A feladat megoldásához az ITIL keretrendszer alábbi komponenseit vezettük be: •
Helpdesk (ügyfélszolgálat és incidensmenedzsment)
•
Szolgáltatási szint menedzsment
•
Konfigurációmenedzsment
•
Problémamenedzsment
5.5.3.1. Helpdesk A helpdesk szolgálatot azért hoztuk létre, hogy azonnali segítséget adjon a felhasználóknak, amikor az informatikaszolgáltatás használata közben üzemzavar lép fel. A rendellenesség származhat abból, hogy a szolgáltatás nem az elvárt módon (rendellenesen) működik, de a fellépett jelenséget okozhatja a felhasználói ismeretek hiánya is. A szolgálat ezen túlmenőn központi gyűjtőhelye az információtechnológiára épülő rendszerben vélelmezett hibák, és hiányosságok bejelentésének. A gyorssegély-szolgálat visszacsatolási pont is, amely összegyűjti a felhasználói közösség véleményét és igényeit az informatikaszolgáltatással kapcsolatos kérdésekről. Első lépés az SLA-ban rögzített minőségi követelményeknek megfelelő Helpdesk alkalmazás bevezetése. Választásunk a Remedy helpdesk moduljára esett, amelynek segítségével a következő funkciókat valósítottuk meg. •
a hívások központi adatrögzítése, menedzselése
•
tudásbázis megvalósítása, használata
•
minőségirányítási eljárások támogatása
•
statisztikák, adatgyűjtések,
•
a felhasználói hívások hatékonyabb kezelése
•
költséghatékonyság növelése
•
internet, intranet támogatása
•
rendelkezésreállás növelése
97
•
nyomonkövethetőség
•
dokumentáltság
•
mérhetőség
5.5.3.2. SLA menedzsment A szolgáltatási szint menedzsment az a folyamat, amely során a felhasználók és az informatikai szolgáltató részleg között létrejött írásos megállapodás, vagy "szerződés" segítségével menedzselik az informatikaszolgáltatás minőségét. Ez a szerződés meghatározza az egyes felekre háruló felelősséget, és kötelezi az informatikai szolgáltatót, hogy előre meghatározott szintű minőségben és mennyiségben szolgáltasson mindaddig, amíg a felhasználó fenntartja igényét az elfogadott korlátok között. Miért vált szükségessé az SLA bevezetése? •
Az SLA az elvárások menedzselésének eszköze
•
A felhasználó tudni akarja, hogy mit kap, és mennyiért
•
Teljesítmény mérés kerete
•
Belső költség elszámolás alapja
A szolgáltatási szint menedzsment létéből eredő előnyök a következők voltak: •
Az SLA betartása lehetővé teszi egy meghatározott, konzisztens és ellenőrizhető szolgáltatási szabvány elérését.
•
A felhasználó az informatikai funkcióval egyensúlyt teremthet a látszólag szükséges szolgáltatások szintje és nyújtásuk költségei ill. a szolgáltatás komplexitása között.
•
Az SLA hosszú távon pozitív költség-haszon arányt eredményez, mivel a szervezet képessé válik a ténylegesen szükséges informatikai erőforrások pontosabb meghatározására.
•
A szolgáltatásfejlesztő programok javuló szolgáltatási minőséghez vezetnek, növelve a felhasználók termelékenységét.
•
A viták gyorsabban és objektívebben oldhatók meg.
•
Az informatikaszolgáltatás többé nem szembesül előre nem látható igényekkel.
•
A megállapodás szorosabbá teszi a kapcsolatot a felhasználó és a szolgáltató között.
5.5.3.3. Konfigurációmenedzsment Egyetlen szervezet sem lehet igazán hatékony eszközeinek menedzselése nélkül, különösen, ha azok az eszközök létfontosságúak a szervezet tevékenységének folytatásában és sikerességében, amint az sok esetben igaz az információ technológia alapú rendszerekre. A konfigurációkezelés (menedzsment) ad közvetlen kontrollt az informatikai menedzsment számára a szervezeti informatikai eszközök fölött. Minél nagyobb a függés az informatikai (információtechnológiai) eszközöktől, annál nagyobb szükség van e vagyontárgyak felügyeletére és menedzselésére.
98
Első lépésként egy teljes eszköz, és szoftver leltárra volt szükség. Az eszközöket egyedi karakteres, és vonalkódos azonosítóval láttuk el. Az általunk alkalmazott szoftveres megoldás a Remedy Asset modulja volt, amelyben rögzítettünk az eszközökről rendelkezésünkre álló információkat. Jelen pillanatban ez nagymértékű élő munkát vett igénybe. Terveink között szerepel egy hardver-szoftver leltárt lehetővé tévő alkalmazás pl. Microsoft SMS bevezetése, amely könnyen illeszthető a meglévő Remedy modulhoz. A konfiguráció menedzsment bevezetéséből a következő előnyök adódtak: • naprakész információnk van arról, hogy milyen informatikai vagyon van a szervezet birtokában • az eszközök hol találhatóak • az eszközöknek mekkora az értéke • az eszközöket mire használják • milyen kapcsolatban van más eszközökkel • kezelhetőek lettek a változások, és csökkenthetőek a költségek • szervezetnek lehetősége van az eszközök eredményes használatára • Lehetővé teszi nagyszámú változtatás gyors, hatékony és biztonságos megvalósítását az infrastruktúrában. • A problémák hatékony és eredményes kezelését is segíti, hiszen azonosíthatja az érintett konfigurációs elemeket • Nagyobb biztonságot eredményez • A jogszabályi kötelezettségeknek való megfelelésben is segít, mert azonosítja a nem jogtiszta másolatokat. • Megkönnyíti a kiadások tervezését: a karbantartási költségek, a licencdíjak meghatározását. 5.5.3.4. Problémamenedzsment A probléma menedzsment szorosan kapcsolódik a konfiguráció menedzsmenthez. Egy eredményes problémakezelési funkció gyorsan javíthat az informatikaszolgáltatás minőségén. Ez egyértelműen jelentkezik a szervezeti felhasználók esetében is, de jó hatással van az informatikaszolgáltató termelékenységére, és munkamoráljára is. A szoftveres támogatást szintén a a Remedy-vel valósítottuk meg. Minden hónap végén riportokat készítünk, mind az ügyfél, mind a belső elemzések számára, amely kiértékelésre kerül. Ezen elemzések az alapjai mind az SLA, mind a folyamatok változtatásának, módosításának.
99
Célunk a következő: • csökkenjen az események száma, ezeknek a hatása is kisebb lesz az informatikaszolgáltatás minőségére • fokozatosan csökkenjen a problémák és az ismert hibák súlyossága és száma • a már megoldott problémák és ismert hibák megoldottak is maradjanak • tanulunk a korábbi hibákból • javítani szeretnénk a felhasználók termelékenységén, akárcsak a specialistákén • az informatikai vezetés elismertségét javítsuk • felhasználók, technikai személyzet oktatása Egy szervezet rendszereinek tökéletesen hibamentessé tétele nem reális, így a problémakezelés mindig nélkülözhetetlen feladat marad. A végső cél tehát nem az, hogy a rendszer hibáktól mentes legyen, hanem az, hogy az események/hibák számát elfogadható szintre csökkentsük, és általában is csökkentsük a problémák számát. AZ ITIL bevezetéséből eredő előnyök, továbblépési lehetőségek • Lehetővé teszi a múltból tapasztalataiból való okulást azáltal, hogy történeti adatokkal szolgál a szolgáltatásra gyakorolt hatásokról. • Fenntartja a informatikai részleg szavahihetőségét a felhasználók szemében. Ezt a minőségi szolgáltatások megbízható nyújtásával éri el. • Kézben tarthatóvá teszi az informatikaszolgáltatást, a jobb vezetői információk lehetővé teszik a szolgáltatásmenedzsment és rendelkezésreállás menedzsment funkció részére a szolgáltatási megállapodások nyomon követését, illetve a követelmények pontosabb meghatározását tartalmazó szerződéskötéseket. • Lehetővé teszi a szervezeti alaptevékenységek megalapozását, elébe megy a rendszerfejlesztéseknek és változtatásoknak. • A szervezet gyorsabban tudja a változtatásokat feldolgozni, alkalmazkodni hozzájuk és változtatásokra reagálni. • Lehetséges lesz az értékes informatikai vagyontárgyak felügyelete.
100
6. Fejlesztés és felülvizsgálat Az informatikaszolgáltatás fejlesztésének – hasonlóan más szervezeti területek fejlesztéséhez – négy fő területét célszerű megkülönböztetni: Tervezés Nagyvonalú üzleti célok
Helyzetfelmérés
Beavatkozás
Mérhető célok
Végrehajtás
Javítás
Ellenőrzés Mérés
Felülvizsgálat
12. ábra: A szolgáltatásfejlesztési ciklus
E területek együtt egy ú.n. szolgáltatásfejlesztési ciklust alkotnak, amely a maga teljességében tudja csak biztosítani egy szervezeten belül az informatika szolgáltatásának folyamatos fejlődését. Minden szervezet, amely az informatika szolgáltatásának fejlesztésére törekszik, és – akár tudatosan, akár ösztönösen – azt végzi is, e ciklus bizonyos részeit, részterületeit valósítja meg. A különbség e megközelítések között az eredményekben (tkp. a szolgáltatás színvonalának tényleges emelkedése) és az eredmények fenntarthatóságában, azaz a folyamatosan változó körülményekhez (piaci, üzleti és technológiai értelemben egyaránt) való alkalmazkodás gyorsaságában és eredményességében mutatkozik meg. A legnagyobb és legtartósabb hatást a fenti négy terület kiegyensúlyozott és összehangolt megközelítése biztosítja. A fejlesztési ciklus kritikus mozzanatai azok a felülvizsgálati és felmérési lépések, amelyek elősegítik annak meghatározását, hogy milyen intézkedésekre van szükség, és annak értékelését, hogy a meghozott intézkedések milyen hatást fejtettek ki. A következőkben először a szolgáltatásfejlesztés egészére, valamint azon belül a helyzetfelmérések (felmérés, felülvizsgálat) vonatkozó legfontosabb ismereteket és ajánlásokat foglaljuk öszsze.
6.1.
Szolgáltatásfejlesztés
A kiindulás és a cél egyaránt az, hogy az informatikaszolgáltatás az üzletvitelt, annak hatékony és eredményes működését támogassa. A soron következő fejezetek útmutatást adnak arra vonatkozóan, hogy ezt miként lehet elérni. Fontos azonban megjegyezni, hogy ezeket az útmutatásokat nem szabad alkalmazási körülményeiktől elvonatkoztatva, abszolút érvényességgel vagy
101
előírásszerűen követni. Hasznosíthatóságukat és alkalmazhatóságukat azonban nem korlátozza sem az adott informatikai szervezet mérete, sem a működtetett technológia.
6.1.1.
A szolgáltatásmenedzsment célja és helye
A szolgáltatásmenedzsment a következő három fő célt szolgálja: 1. Az informatikaszolgáltatás megfeleltetése az üzleti tevékenység és az ügyfelek meglévő és jövőbeni igényeinek; 2. A ténylegesen nyújtott informatikaszolgáltatás minőségének javítása; 3. A szolgáltatásnyújtás hosszú távú költségeinek csökkentése. A szolgáltatásmenedzsment helye az üzletvitel és a technológia összehangolásában:
Szolgáltatásmenedzsment (ISzM) Szolgáltatástámogatás
Szolgáltatásnyújtás
Infokom infrastruktúra menedzsmentje
Szolgáltatásfejlesztés Üzleti-stratégiai menedzsment
Ü z l e t v i t e l
Biztonságmenedzsment
Alkalmazásmenedzsment
T e c h n o l ó g i a
13. ábra: A szolgáltatásmenedzsment helye
Az üzleti tevékenység és az infokommunikációs technológia összhangját alapvetően a szervezet üzleti-stratégiai menedzsmentje határozza meg: azaz, hogy milyen módon, milyen gyorsan, és milyen hatékonysággal tudja a szervezet felső vezetése •
felismerni a piaci, üzleti és technológiai környezetben bekövetkezett változásokat,
•
képes ezekre sajátos és hatásos válaszokat megfogalmazni, és
•
tudja mozgósítani a szervezet erőforrásait ezek megvalósítására.
Az üzleti stratégia informatikai vetületében két alapvető irány mentén lehet megfogalmazni a célokat: 1. az alkalmazási portfolió meghatározása: milyen új alkalmazásokra, ill. a meglévő alkalmazások milyen módosítására, milyen újfajta kombinációjára, együttműködésére tart igényt közvetlenül az üzletvitel? 2. az informatika szolgáltatása: a mindenkori alkalmazási portfolió és a kapcsolódó infokommunikációs infrastruktúra költséghatékony és az üzleti igényeknek megfelelő működtetése.
102
Az alkalmazásmenedzsment az elsőként említett irányban fejti ki hatását, és ezen keresztül – ha közvetetten is, de – meghatározó hatással van más területekre is. Hatása kiterjed a kezdeti üzleti igényektől az alkalmazásfejlesztés és –integrálás életciklusán át az alkalmazások használatból történő kivonására, valamint az (informatikai) szolgáltatásmenedzsment és az (infokommunikációs) infrastruktúramenedzsment folyamataira. Az (informatikai) szolgáltatásmenedzsment (ISzM) a másodikként említett irány tekintetében fejti ki fő hatását, és emeli ki az informatikaszolgáltatást (tkp. az alkalmazások és az infrastruktúra hozzáférhetőségének és használhatóságának biztosítását) egyszerű technikai (üzemeltetési) tevékenységből sokrétű irányítási feladattá. Az ITIL fogalmi keretet és útmutatást ad erre vonatkozóan a nemzetközileg bevált, jó gyakorlat alapján. Ennek részleteit és két fő részterületét (szolgáltatásnyújtás és szolgáltatástámogatás) e kiadvány más fejezetei ismertetik. A szolgáltatásfejlesztés közvetlenül az informatikaszolgáltatás és az ezt biztosító (informatikai) szolgáltatásmenedzsment üzleti igényeknek való mindenkori megfelelésére és folyamatos fejlődésére irányul. Ennek hangsúlyait, mértékét és ütemét az üzleti stratégia határozza meg, hatása azonban megjelenik az alkalmazások és az infokommunikációs infrastruktúra menedzsmentjében is. Az infrastruktúramenedzsment az infrastruktúra létrehozását irányítja a kezdeti üzleti igényektől a beszerzésen át a tesztelés, telepítés és üzembe helyezés folyamataiig, valamint irányítja az infrastrukturális komponensek és a hozzájuk kapcsolódó szolgáltatások folyamatos támogatását és karbantartását. A biztonságmenedzsment, melynek elveit az ISO/IEC 17799 nemzetközi szabvány határozza meg, szerteágazó módon épül be mind a szolgáltatás-, mind az alkalmazás-, mind az infrastruktúramenedzsment területeire.
6.1.2.
A szolgáltatásfejlesztés alapjai
Az (informatikai) szolgáltatásmenedzsment (ISzM) céljainak megvalósulásához megfelelő irányítási keretben és ezen belül három fő irányban kell az informatikaszolgáltatás fejlesztését végezni: Munkaerő
Kultúra, hozzáállás, meggyőződés és szakértelem
Stratégiai vezetés, irányítás, integrálás Szolgáltatásnyújtás és -támogatés
Folyamatok
Infrastruktúra (eszközök is)
Technológia
Mindemellett azonban a legfontosabb, hogy üzleti értelemben világosan megindokolható legyen a fejlesztési elképzelés: milyen üzleti hasznot fognak hozni a megjavított (informatikai) szolgáltatásmenedzsment-folyamatok (ISzM-folyamatok)?
103
Az ISzM-nek éreztetni kell hatását az egész szervezetben, legyen az üzleti hatékonyság növekedése, az informatikaszolgáltatás költségeinek csökkentése, javuló elégedettség az ügyfélnél, vagy megbízhatóbb informatikaszolgáltatás a kritikus üzleti folyamatoknál. Az (informatikai) szolgáltatásfejlesztési projekteket (ISzFP) vagy programokat (amennyiben több, különböző, párhuzamosan futó projektben célszerű gondolkodni) elindító szervezeteknek: •
tekintettel kell lenniük a piac gazdasági és technológiai fejleményeire,
•
meg kell érteniük ezeknek a szervezetre gyakorolt hatását, és
•
meg kell határozniuk, hogy az ITIL ajánlásait hogyan lehet a legjobban felhasználni az informatika és a változó üzleti igények összhangjának megteremtésére.
Az ISzM megvalósítása a szervezeten belül a közvetlen üzleti hatásokon túl nyújthat pénzügyi, emberierőforrás-kezelési, innovációs és informatikaszolgáltatáson belüli hasznot is. Minden javításnak valamilyen hasznot – ha nem közvetlenül, akkor közvetetten, de – hoznia kell az üzletvitel számára. A tervezett hasznot olyanképpen kell megfogalmazni, hogyan annak valóra válása kimutatható és mérhető legyen. 6.1.2.1. Elvárások a szolgáltatásmenedzsmenttel szemben Az üzleti szervezetekben egyre inkább tudatosul az informatika jelentősége nemcsak támogatói, de előmozdítói szerepben is. A legfontosabb üzleti követelmények ISzM számára: •
A vállalati átalakulás előmozdítása a vállalat-átalakítási programok szerves részeként;
•
Megnövekedett figyelem az informatika egyes minőségi kérdéseiben: megbízhatóság, rendelkezésreállás, kapacitás és biztonság;
•
Az informatika teljesítőképessége láthatóvá válik (pl. Internet), emiatt a kiesések és elégedetlenségek gyakran közvetlen vezetői beavatkozást igényelnek;
•
Az informatikának nyilvánvalóvá kell tenni, hogy a ráfordításokkal összevetve mekkora értéket teremt;
•
Az elektronikus üzletvitelben az informatika már szerves része az üzleti folyamatoknak.
A gyors technológiai fejlődés is követelményeket támaszt az informatikaszolgáltató szervezetekkel szemben: •
Az üzleti tevékenység megértése, és ennek következtében tanácsadási képesség az informatika lehetőségeit és korlátait illetően a vállalati döntéshozók felé;
•
Egyre több technológiai változás egyre gyorsabb abszorpciója a meglévő szolgáltatási színvonal fenntartása mellett;
•
A szolgáltatási színvonal összehangolása az új technológiák üzleti célú felhasználásával;
•
A növekvő informatikai költségek ellenőrzés alatt tartása.
104
6.1.2.2. Az informatikaszolgáltató szervezetek a változás korában Az informatikaszolgáltató (ISz) szervezetek állandóan fokozzák szolgáltatási képességüket válaszul a rendelkezésreállási, kapacitási, megbízhatósági és változtathatósági követelmények növekedésére. Ez azonban gyakran még mindig nem elegendő a változó üzleti igények és elvárások teljesítéséhez. A legtöbb vállalat úgy látja, hogy a jelenlegi informatikájuk sok kívánnivalót hagy maga után, vagy éppenséggel hogy a jelenlegi minőségi színvonal és munkamódszerek lefogadhatatlanok. A vállalatátalakulások informatikai támogatása természetes módon igényli az informatikaszolgáltatás hasonló mértékű átalakulását. Az ITIL ilyen esetekben biztos kiindulási pontot adhat az ISz-szervezeteknek, egyszerre téve lehetővé a magasabb szolgáltatási színvonalat és az informatika költségeinek csökkentését. 6.1.2.3. Tipikus szolgáltatásfejlesztési megközelítések A legjobb természetesen az lenne, ha minden ISz-folyamat bevezetésre kerülne az ISzszervezeteknél. A folyamatok ugyanis egymással összekapcsolódnak, gyakran teljes mértékben függenek egymástól, és ezért nem véletlen, hogy a teljes bevezetéssel realizálható haszon jóval felülmúlja az egyes folyamatokénak összegét. Azonban nincs abszolút helyes útja az ISzM megvalósításának (sem), különösen, ha tekintettel akarunk lenni az ISz-szervezet sajátságos helyzetére is. Az alábbiakban néhány tipikus megközelítést vázolunk: 1. Egy problémára fókuszálás: egy fő problémának a kezelése az azt megoldó folyamat segítségével (esetleg a kapcsolódó folyamatokat is bevonva). Ennek során a legfájóbb ponton igyekeznek orvosolni a helyzetet, amely annak ellenére, hogy gyakran csak felületi kezelést eredményez, már rövidtávon is hatásos lehet, pl.: •
Ügyfélpanaszok és –igények kezeletlensége: Az ügyfélszolgálati folyamat bevezetése az incidens- és problémakezelési folyamatokkal együtt; néhány fő teljesítménymutató figyelemmel követése mellett meglepő mértékű szolgáltatásjavulást lehet elérni, ha ezeket vezetik be elsőként.
•
Sorozatos leállások, alacsony rendelkezésreállás: A problémakezelési folyamat bevezetése elősegíti azoknak a területeknek az azonosítását és megoldását, amelyek a legtöbb üzemzavart és –kiesést okozzák a szervezetben.
•
A változtatások elmaradásának ördögi körében: Sok informatikaszolgáltató szervezet az „idő hiányában elmaradt változtatások Æ növekvő számú incidens-bejelentés Æ újabb problémák megjelenése Æ további változtatások szükségessége” jellegű öngerjesztő üzemmódban működik. A változáskezelési folyamat bevezetése lehetőséget ad az ebből való kitörésre, és bizonyos mértékű ellenőrzést is biztosít. Az informatikai változtatások láthatóságának növelésével és hatáselemzésük elvégzésével a szolgáltatások rendelkezésreállása és az ügyfélszolgálat érdemben javíthatók. Gyors eredményt lehet elérni azzal, ha először csak egy adott szolgáltatásra vagy szolgáltatási körre vezetik be. Ami aztán később kibővíthető további folyamatokkal, kiterjeszthető további szolgáltatásokra, vagy hosszabb távú változáskezelési koncepcióvá fejleszthető.
2. Komplex problémafeltárás: Ennek során az informatika és az üzletvitel képviselői között jelentős egyeztetések folynak, és a fő problémák átfogó feltárása után, ennek eredményeképp, több folyamat egyidejű javításába kezdenek. Az alábbiakban röviden összefoglaljuk azokat az indító, kiváltó eseményeket, amelyek ilyen komplex problémafeltárást, és ennek eredményeképp komplex szolgáltatásfejlesztést eredményezhetnek: •
Kezdeményezés a szolgáltatás folyamatos fejlesztésére: A folyamatos szolgáltatásfejlesztés elvének elfogadtatása és a munkakultúra ilyen irányú megváltoztatása fontos része a
105
szervezetbeli javítások előmozdításának. A megközelítés egy átfogó ISzFP kialakítására épül, amely minden olyan tevékenységet tartalmaz, ami az informatikaszolgáltatás javulásához hozzájárul. •
Az ügyfél elégedettségének felmérése: A felmérés megállapítja az informatikaszolgáltatás jelenlegi színvonalát az ügyfél szemszögéből nézve. A felmérés segít annak meghatározásában, hogy a szervezet működésében alkalmazott javítások megjelennek-e végső soron az ügyfeleknél, valamint hogy mely területeken lehet elérni a lehető legnagyobb előrelépést a fő ügyfeleknél a kedvezőbb megítélés érdekében.
•
Üzleti hatáselemzés: A hatáselemzés feltárja az informatikaszolgáltatás leállásának és esetleges visszaállításának hatását az üzletvitelre. Ennek során meghatározza azokat a területeket és folyamatokat is, amelyek a legnagyobb zavart okozzák az üzletvitelnek normális működési körülmények között. Az elemzés eredménye felhasználható olyan célok kitűzéséhez, amelyek a lehető legnagyobb hasznot hozzák az üzleti tevékenység ill. az ügyfelek számára.
•
SWOT-elemzés az ISz-szervezetben: Az elemzésben feltárt erős ill. gyenge oldalak támpontot adnak, hogy mely belső területeket és folyamatokat kell továbberősíteni ill. jelentős mértékben megváltoztatni. Az elemzés külső környezetre vonatkozó megállapításai (lehetőségek, veszélyek) viszont elsősorban a partneri kapcsolatok és a piaci tendenciák (pl. felvásárlási, kiszervezési hullámok) tekintetében adnak hasznos útmutatást az informatikaszolgáltatás stratégiai léptékű fejlesztéséhez. A szolgáltatás módjának és céljának radikális változásait többnyire a külsö körülmények változásai indokolják és indukálják.
•
Összemérés: Az összehasonlítás a beváltnak tekintett, jónak vélt gyakorlattal igen hatékony módja a lemaradt ill. élenjáró területek meghatározásának. Az értékelés történhet egy általános „mérce” alapján, azaz pl. az ITIL, mint hatásos folyamatok és széles körben jónak tekintett gyakorlat logikus és konzisztens leírása alapján, de történhet egy, az informatikaszolgáltatás területén élenjárónak, követendőnek tekintett másik szervezet konkrét folyamatainak és megközelítésének megismerése, felmérése útján is. Az összemérés különösen hatásos lehet a fő teljesítménymutatók meghatározásában, ugyanis éppen ezek azok, amelyekkel az összemérés eredménye kifejezhető, és vezetői szinten is értelmezhetővé tehető. Az összemérés záró jelentésében a teljesítménymutatók alapján viszonylag egyértelműen lehet a javítandó területeket és folyamatokat azonosítani, és a javítás lehetőségeit és módját megfogalmazni. Az összemérések rendszeres végrehajtása fontos elem az informatikai szolgáltatásfejlesztés (ISzF) folyamatosságának biztosításában is.
•
Kísérleti teljesítménycélok kitűzése: A minimálisan elfogadható szolgáltatási szint meghatározása, amely még elfogadható az ügyfelek számára saját céljaik eléréséhez, többnyire jó kiindulási pont, amely mind az ügyfelek, mind a szolgáltatók számára előrelépést jelent. A nélkül azonban, hogy az ügyfelek elvárásait összhangba hoznánk ezek teljesítésének költségvonzataival, nem lehetséges érdemi megegyezés a szolgáltatás színvonaláról. Ebben a megközelítésben viszonylag egyszerű, kísérleti jellegű teljesítménycélokat írnak elő, pl. a szolgáltatás rendelkezésreállására, a felhasználói válaszidőkre, változtatási területekre, incidenskezelési időkre. Az ilyen ideiglenes (véglegesen el nem fogadott) célok segítségével mintegy „felderítik” azokat a területeket és folyamatokat, ahol javításra lehetőség van, és egyúttal jobban megbecsülhetővé is válik a szolgáltatásfejlesztés ill. magának a szolgáltatásnak a költsége. E megközelítés előnye, hogy a konkrét ügyféligényeknek és ezek teljesítési költségeinek kapcsolata jól kimutathatóvá és érzékelhetővé válik, amely egyben a szolgáltatásfejlesztésnek is irányt és kézzel fogható értelmet ad.
3. Teljes körű bevezetés: ez az összes szolgáltatásmenedzsment-folyamat egyidejű bevezetését jelenti. A bevezetést különböző kezdeményezések vezérelhetik, ill. adhatnak keretet hozzá:
106
Üzleti-informatikai stratégia és jövőkép Folyamatos szolgáltatásfejlesztési program Összemérés A leginkább célra vezető gyakorlati megközelítés ebben az esetben, hogy kis lépéseket hajtanak végre minden folyamatnál. Ez azt igényli, hogy egy átfogó SzF-program segítségével koordinálják a fejlesztéseket, amelyeket az egyes folyamatgazdák (10 az ITIL esetében) külön projektként irányítanak. Ez az egyetlen olyan megközelítés, amely akkor hozza igazán az eredményeket, ha a folyamatok már magasabb fejlettségi szinteket érnek el (4. vagy 5. szinteket az ISzM ún. folyamat-fejlettségi modellje szerint, ld. 17. ábra). Alkalmatlan megközelítések esetei, jellemzői: •
Konfigurációkezelési adatbázis (CMDB) létesítése változáskezelési folyamat nélkül.
•
Az informatikaszolgáltatásért térítést kérni egy átfogó pénzügyi intézkedéscsomag keretében anélkül, hogy az elvárt szolgáltatási szintek tekintetében megegyezés születne.
•
Problémakezelés bevezetése anélkül, hogy az incidenskezelés pontos és teljes körű adatokat tudna szolgáltatni az incidensek megoldását illetően.
•
Lopakodó bevezetés, azaz megfelelő vezetői támogatás nélkül mintegy a színfalak mögött történő bevezetés kísérlete; népszerű, de lehetőleg elkerülendő megközelítés, amely éppen ezért csak figyelmeztetésként került ide.
Alkalmas megközelítések jellemzői: Több, alternatív megközelítést célszerű értékelni, és ezek közül az adott helyzetre legmegfelelőbbet kell választani attól függően, hogy: •
milyen mértékű a felső vezetés elkötelezettsége;
•
mennyi erőforrás áll rendelkezésre és mekkora költségvetést biztosítanak;
•
a szervezet milyen tapasztalattal és szakértelemmel rendelkezik;
•
milyen a szervezeti felépítés és kultúra;
•
van-e és mennyire kidolgozott az üzleti és az informatikai jövőkép és stratégia;
•
milyen eszközök és technológiák állnak rendelkezésre;
•
mekkora a hagyományos üzletvitel iránti igény.
6.1.2.4. A szolgáltatásfejlesztés felülvizsgálata A választott fejlesztési megközelítést időközönként célszerű felülvizsgálat alá venni annak érdekében, hogy mindenkori megfelelősége biztosított legyen. Ahogy az ISz-szervezetek és a SzMfolyamataik fejlődnek, úgy kell fejlődnie a szolgáltatásfejlesztésnél alkalmazott megközelítésnek is, és igen valószínű, hogy fokozatosan a komplex problémafeltárásra épülő ill. a teljes körű bevezetés kerül előtérbe. Nagyobb mérföldkövenként ezért felülvizsgálatot kell beütemezni a fejlesztési megközelítés megfelelőségének felmérése, és a fejlesztési terv módosítása végett, amennyiben erre szükség van.
107
Az informatikaszolgáltatás fejlesztése során rendkívül fontos „gyors eredmények” lehetőségének felismerése és elérése. Legalább ugyanennyire fontos azonban, hogy a hosszú távú célokat ne veszélyeztessük miközben eredmények gyors elérését „hajszoljuk”. Azok az ISz-szervezetek, amelyek fejlettsége SzM-folyamataik tekintetében a SzM-fejlettségi modell alacsonyabb szintjein (pl. 1. vagy 2. szinteken) helyezkednek el, bármelyik korábban említett megközelítést követhetik. Ahogy azonban a szervezet feljebb kerül a fejlettségi „létrán”, egyre inkább a komplex ill. teljes körű megközelítéseket kell alkalmaznia. A 4. vagy magasabb szintek elérése nem lehetséges a teljes körű megközelítés alkalmazása nélkül. 6.1.2.5. A jövőkép szerepe A jövőkép annak kinyilvánítása, hogy milyen állapot kell elérnie az informatikaszolgáltatásnak, amelyet az üzleti és informatikai terület egyaránt és kölcsönösen elfogad. A jövőkép ilyen módon leírja a szolgáltatásfejlesztés céljait és végső rendeltetését. A jól megfogalmazott jövőkép 4 fontos célt is szolgál: •
tisztázza a fejlesztési program körüli esetleges félreértéseket;
•
jó irányban történő cselekvésre ösztönzi a szervezet alkalmazottait;
•
a résztvevők tevékenységét koordinálja;
•
körvonalazza a felső vezetők hozzáállását.
6.1.2.5.1.
A jövőkép kommunikálása
A fejlesztési program összes érdekeltje és résztvevője felé a jövőkép kommunikálását két oldalról kell megközelíteni: •
mi az, ami sűrgeti a program megvalósítását, mi történik, ha nem így teszünk?
•
mi az, ami az egyes érdekeltek, résztvevők számára vonzó a programban, milyen előnye származik abból?
Rendkívül fontos, hogy mindenki számára a saját nézőpontjából kiindulva fogadtassuk el a programot, tegyük számára vonzóvá és kézzelfoghatóvá. Az alábbi táblázat néhány jellemző példát ad az informatikaszolgáltatás fejlesztésétől várható előnyökre az egyes nézőpontok szerint: Érdekelt fél Támogatók az üzleti oldalon
Várható előny 1.
Összhangban lenni a piaci költségekkel
2.
Kevesebb idő kell új informatikai rendszer megvalósításához
3.
Az informatika nagyobb rendelkezésreállása az üzleti tevékenység végzésénél
4.
Az üzleti oldal határozza meg az informatikaszolgáltatás szintjét
5.
A szolgáltatási szint garantált
1.
Az informatika rendelkezésreállása és megbízhatósága növekszik az üzleti tevékenység végzésénél
2.
Az ügyfélelégedettség fenntartása és következetes javítása
Alkalmazottak
1.
Személyes ambíciók teljesülése különböző szinteken
Szakmai elkötelezettek
2.
Javuló munkaköri elégedettség
3.
Együttműködő folyamatok
Ügyfelek Felhasználók
108
4.
Javuló termelékenység, csökkenő bürokrácia
Partnerek
1.
Javuló kapcsolatok és novekvő üzleti sikeresség
Gyártók
2.
Világosabb megértése, hogy milyen helyet foglalnak el az üzleti tevékenységrendszerben
Szervezetváltozás felelőse
1.
A projektmunka teljesítése
Oktatók
2.
Személyes és munkaügyi elismerés. láthatóság
Személyzetisek
3.
Tanulás és fejlesztés
Szállítók
Kommunikációs szakértők Tanácsadók (Szoftver)fejlesztők
Gyorsabb átadási folyamat
A következetes kommunikáció kiemelkedően fontos eleme, hogy amikor csak lehet és a szervezet minden szintjén, tettekkel legyen demonstrálva, hogy a szolgáltatás mindenkori elfogadott szintjét fenntartják, és, esetleg ahol lehet, meghaladják. 6.1.2.5.2.
Az irány kijelölése
Alapvető fontosságú, hogy az üzleti és az informatikai stratégia összhangban legyen. Az informatika fejlesztési irányának kijelölése azt kell eredményezze, hogy létrejön: •
egy olyan stratégia, amely az informatikát összhangba hozza a üzleti oldallal;
•
politikák és szabványok az informatika egységes menedzsmentjét illetően;
•
az üzleti célokat támogató architektúrák az informatika és az eszközkezelés területén.
Az ehhez szükséges fő tevékenységek: 1. Elemezni az üzleti igényeket és azt, hogy az informatika hogyan tudja ezeket valóra váltani; 2. Kockázatkezelési politikát alakítani ki, és biztosítani, hogy ez beépüljön a tervezési és döntéshozatali folyamatokba; 3. Informatikai stratégiát alakítani ki, és biztosítani, hogy ez összhangban legyen az üzleti politikával; 4. Az eredmények hasznosítására politikát alakítani ki, és biztosítani, hogy az informatikába történt befektetések a lehető legnagyobb hasznot hozzák. 6.1.2.5.3.
A siker fő tényezői
Az informatika üzleti orientáltságának megteremtésében a legfontosabb tényezők a következők: 1. Felső vezetői elkötelezettség a változásra és stratégiai irány tartására; 2. A célok világos megfogalmazása és a célmegvalósulás követése, mérése 3. Az innováció és új munkamódszerek elfogadása 4. Az üzleti tevékenység megértése, beleértve az összes érdekeltet és a környezetet is; 5. Az informatikusok megértsék az üzlet igényeit,
109
6. Az üzleti oldal megértse az informatikában rejlő lehetőségeket; 7. Az információ és kommunikáció mindenki számára elérhető legyen, aki arra igényt tart; 8. A technológiai trendek követése olyan lehetőségek felismerése érdekében, amelyeket az üzleti tevékenység támogatására fel lehet használni.
6.2.
Helyzetfelmérés
Mielőtt valamilyen SzF-programba belefogna egy ISz-szervezet, különböző nézőpontokból meg kell érteni-e, hogy hányadán is áll: •
Milyen üzleti hajtóerők érvényesülnek – mi az üzleti stratégia, irányvonal és általában mik azok a témakörök, amelyekkel az üzletvitel szembesül, azt foglalkoztatja, és mindez hogyan érinti az informatikát?
•
Milyen technológiai hajtóerők vannak jelen – melyek a meghatározó technológiai fejlemények, és hogy lehet ezeket felhasználni az üzletvitel támogatására?
•
Hogyan értékeli az üzleti oldal az üzleti és technológiai hajtóerőket, és hogyan akar üzleti hasznot húzni a technológia által nyújtott lehetőségekből?
•
Egyezik-e az üzleti és az informatikai oldal véleménye az informatika jelenlegi szerepét, valamint az informatikaszolgáltatás fejlettségét és színvonalát illetően ezen hajtóerőkhöz viszonyítva?
•
Mi az érdekeltek nézete és igénye?
•
Egyértelmű-e, hogy mi a következménye annak, ha nem történik semmilyen fejlesztés?
Ha világosan megértik, hogy hol is áll az ISz-szervezet, ez segít abban, hogy meghatározzák a jövőkép valóra váltásához szükséges ráfordításokat, különösen azok nagyságrendjét és komplexitását illetően.
6.2.1.
ISz-szervezetek fejlődési modellje
Mielőtt valamilyen SzF-programba belefogna egy ISz-szervezet, fontos megértenie, hogy milyen fejlettségi szinten, milyen fejlődési stádiumban van (ld. alábbi ábra). nagy Befolyás az üzletvitelre
Értékteremtés
kicsi
5. stádium
Üzletközpontúság Ügyfélközpontúság Termék/szolgáltatás Technológia
4. stádium 3. stádium
2. stádium
1. stádium
14. ábra: Fejlődési modell – Az informatika szerepe a szervezeten belül
110
Fontos tudatában lenni annak, hogy: •
Minden fejlődési stádium az ISz-szervezet átalakulását vonja maga után, és ez változásokat kíván mind az emberek (beleértve a munkakultúrát is), mind a folyamatok, mind a technológia tekintetében.
•
Kettőnél több stádium teljesítése egy adott szolgáltatásfejlesztési programon belül a kudarc nagyobb kockázatával jár, és rossz irányban befolyásolhatja nemcsak a személyzet motiváltságát és morálját, de az ügyfelek elégedettségét is.
•
Nem kell minden ISz-szervezetnek a legfelső szintre eljutnia – a szükséges fejlettségi szint nagyban függ az informatikai terület elé állított üzleti igényektől.
Egy következő stádiumra való áttérés többet igényel, mint csupán a vonatkozó ITIL-ajánlások megvalósítása: különböző elemek összehangolt megváltoztatását teszi általában szükségessé (ld. 15. ábra).
Jövőkép és stratégia Irányítás
Üzleti-informatikai kultúra Folyamatok Személyzet Technológia
15. ábra: A szolgáltatásfejlesztés meghatározó komponensei
•
Jövőkép és stratégia – az átfogó irányvonal, amely meghatározza az informatika szerepét és helyzetét az üzletvitel szempontjából;
•
Irányítás – az informatika előtt álló célok és célkitűzések, és ezek figyelemmel követése a stratégia megvalósítása tekintetében;
•
Folyamatok – olyan tevékenységek összességei, amelyek segítségével az informatika előtt álló célokat és célkitűzéseket el lehet érni;
•
Személyzet – szakértelem és képesség a folyamatok végrehajtásához;
•
Technológia – a folyamatok végrehajtásához szükséges támogató infrastruktúra;
•
Kultúra – az üzleti oldal viselkedése és hozzáállása az informatikát illetően.
Az alábbi táblázat vázlatosan jellemzi az egyes stádiumokat (tkp. az informatika szerepének változásait az üzleti oldal viszonylatában) a fent említett fő komponensek, mint nézőpontok szerint. Stádium/szerep
Nézőpont
Jellemzők
111
Stádium/szerep Technológia
Nézőpont Jövőkép és stratégia
1.
Az üzleti oldal az informatikát infrastruktúraszolgáltatónak tekinti.
2.
Nincs világos jövőkép az informatika szerepét illetően.
1.
Költségvezérelt
2.
Fókuszban az informatikai infrastruktúra stabilitása, rendelkezésreállása és teljesítménye.
Folyamatok
1.
Fókuszban a rendszer- és hálózatmenedzsment, valamit az informatikai tervezés és megvalósítás.
Személyzet
1.
Technikai kiválóság
Technológia
1.
Egymástól függetlenül beszerzett rendszer- és hálózatmenedzsment eszközök egyes technológia területek menedzselésére..
Kultúra
1.
Tudatosult informatikai szakértői státusz.
2.
Kevés a kapcsolat az üzleti oldallal, és alacsony szintű annak a megértése, hogy szolgáltatói szerepet várnak az informatikától.
1.
Az informatika termékek és szolgáltatások adott körét nyújtja az üzleti oldal számára.
2.
Az informatikai stratégia tervezése folyik, kevés a hozzájárulás az üzleti oldal felöl..
1.
A szolgáltatásokat technológiai értelemben határozzák meg.
2.
A beszámoltatás és az irányítás az informatika által meghatározott paraméterekkel történik.
1.
Fókuszban a szolgáltatástámogatási és a működtető jellegű szolgáltatásnyújtási folyamatok.
2.
A jelentéseket a termékek és szolgáltatások teljesítményének javítására használkják.
1.
Tisztább meghatározása az informatikai funkcióknak.
2.
Megjelenik az 1. és 2. vonalbeli szakértelem.
1.
Termékszabványosítás.
2.
Architektúrák tervezése és összeintegrálásuk a menedzsmenteszközökkel és -rendszerekkel.
1.
Csapat- és termékközpontúság.
2.
Figyelemfelkeltés és promóció az ügyfelek irányában.
Jövőkép és stratégia
1.
Az informatikát informatikaszolgáltatónak tekintik.
2.
Az informatikai stratégiai kapcsolódik az üzleti stratégiához.
Irányítás
1.
Szolgáltatási megállapodás vezérli az informatikát.
2.
A változáskezelést beépítik a projektekbe, hogy zökkenőmentes legyen az áttérés az új informatikai fejlesztéseknél.
Irányítás
Termék/ szolgáltatás
Jövőkép és stratégia
Irányítás
Folyamatok
Személyzet Technológia
Kultúra Ügyfélorientáltság
Jellemzők
112
Stádium/szerep
Nézőpont Folyamatok
1.
Szolgáltatásmenedzsment, formális ügyfélkezelés.
2.
Fókusz a szolgáltató folyamatok tervezési vonatkozásain.
3.
Egyértelmű szolgáltatást ad és ügyfél-orientált teljesítményt nyújt.
4.
A visszajelzés a folyamatokról a szolgáltatási megállapodás értékelését támogatja.
1.
Oktatás ISzM témakörben, jól meghatározott tevékenységek és szerepkörök.
2.
Folyamatgazda szerepköre megjelenik.
3.
Formális ügyfélkezelési és ISzM-szerepkörök használatban.
1.
Integrált rendszer- és szolgáltatásmenedzsment platformok, beépített menedzselhetőség.
2.
Létezik eljárás a termelő (“éles”) környezetben való működtetésre történő átadásra.
Kultúra
1.
Előtérben az ügyfél elégedettsége.
Jövőkép és stratégia
1.
Az informatika partnere a üzleti oldalnak.
2.
Az informatika az üzleti stratégiát valósítja meg.
3.
Az informatika hozzájárul az üzleti stratégiához.
1.
Informatikai stratégiai célok, informatikai javaslatok a döntéshozói szinten.
2.
Az informatikai befektetések üzleti fontosság és kockázat szerinti értékelése.
3.
A szolgáltatási megállapodást üzleti terminológiában adják meg.
1.
A folyamatok összhangban vannak mind az üzletvitel, mind az ifromatika igényeivel.
2.
Az ISzM-folyamatok kialakítása és integrálása.
3.
‘Műszerfal’-jellegű információk az irányítói szintnek.
4.
Integrált szolgáltatástámogatás és –nyújtás.
5.
Megalapozott tervek és tanácsadás az üzleti oldalnak.
1.
Üzleti hírszerzés és üzleti kompetencia.
2.
“Informatikai igazgató” és “Technológiai igazgató” szerepkörök..
3.
Hasonló szerepkörök az üzleti és az informatikai oldalon.
1.
K+F és technológiai kísérletek.
2.
Egységes vállalati keretben integrálódnak a szolgáltatásés rendszermenedzsment eszközök.
Kultúra
1.
Az informatika segíti és tanácsokat ad az üzleti oldalnak.
Jövőkép és stratégia
1.
Az informatika szerepe az üzleti tevékenység előmozdítása.
2.
Az informatika segíti az üzleti változás kialakítását és vezérli azt. Az informatika partner az üzleti stratégia meghatározásában, amely érdemben hozzájárul ahhoz.
Személyzet
Technológia
Üzletorientáltság
Irányítás
Folyamatok
Személyzet
Technológia
Értékteremtés
Jellemzők
113
Stádium/szerep
Nézőpont Irányítás
Folyamatok
Személyzet
Technológia Kultúra
Jellemzők 1.
Az informatikát úgy irányítják, hogy minél nagyobb mértékben járuljon hozzá az üzleti eredményhez.
2.
Az üzleti tevékenység az informatika használatán keresztül javul.
1.
Üzleti és informatikai stratégiakészítés.
2.
Az informatika zökkenőmentes integrálódást tesz lehetővé a fejlesztéssel és az összes informatikai beszállítóval, és ilyen módon végponttól-végpontig terjedő szolgáltatási láncot képez.
1.
Stratégiakészítés, üzleti tervezés, partnerek és ügyfelek kezelése.
2.
Infrastruktúraintegrátorok.
1.
Technológiai kapcsolatok a beszállítók között.
2.
Megoldásintegráció.
1.
Az informatika előmozdítja az üzleti tevékenységet.
A fenti táblázat segít annak gyors meghatározásában, hogy: •
Mekkora a különbség az informatika jelenlegi és a tervezett szerepe között?
•
Vajon olyan célok alapján irányítják-e az informatikát, amelyek üzleti igényeket közvetítenek? Van-e jól meghatározott célrendszer kitűzve a szolgáltatásfejlesztési program elé?
•
Megvannak-e azok a folyamatok és eljárások, amelyekkel a kitűzött célokat el lehet érni? És ki vannak-e alakítva azok mérési eljárások, amelyekkel a javulást, ha van, ki lehet mutatni?
•
Rendelkezésre állnak-e a szükséges képességek és kompetenciák?
•
Előmozdítja-e a technológia a folyamatok végrehajtását, és lehetővé teszi-e a szükséges méréseket a célok követhetősége érdekében?
•
Vajon a személyzet viselkedése és hozzáállása lehetővé teszi-e, hogy az informatikaszolgáltatás ügyfél- és szolgáltatás-központúvá fejlődjön?
Részletesebb, megbízhatóbb és jobban hasznosítható helyzetfelméréshez különböző technikák állnak rendelkezésre. Ezek rövid összefoglalása a következő fejezetekben található.
6.2.2.
Összemérés
Az összemérés olyan technika, amely közvetlenül teljesítményjavulás elérésére törekszik. Össze lehet hasonlítani különböző szervezetek teljesítményét, vagy egy szervezeten belül különböző egységekét. Olyan folyamatosan használható módszer, amely a termékek, szolgáltatások és tevékenységek mérését és javítását valamilyen bevált, jó gyakorlatnak tekintett megközelítéshez képest határozza meg. Az összemérésben érintett szervezetek szerint általában négy féle összemérésről lehet beszélni: 1. Egy olyan viszonyítási alap létrehozása, amellyel az adott szervezet az idő múltával sajátmagát össze tudja hasonlítani, és ezzel a saját fejlődését le tudja mérni.
114
2. Összehasonlítás más szervezetek által ajánlott – pl. az ITIL keretében megfogalmazott – ipari szabvánnyal3. 3. Közvetlen összehasonlítás más szervezetekkel. 4. Összehasonlítás más rendszerekkel vagy egységekkel ugyanabban a szervezetben. Az összemérés gyakran felfed olyan lehetőségeket, amelyekkel gyors eredményeket lehet elérni, mivel könnyen meg lehet őket valósítani viszonylagosan alacsony költségek mellett, miközben jelentősen hasznot hoznak a személyzet összetartása, a folyamatok hatékonyságjavítása és a költségcsökkentés terén. Azok a szervezetek, amelyek rendszeresen végeznek összeméréseket, általában arról számolnak be, hogy az összemérések költsége egyértelműen megtérül az általuk elindított javítási tevékenység eredményeiben.
6.2.3.
Személyzetfelmérés
Gyakran az egyetlen igazi akadályt az emberi tényező jelenti a szolgáltatásfejlesztés eredményessége előtt. Az informatikaszolgáltatás helyzetének felméréséhez ezért meg kell érteni, hogy jelenleg a személyzet milyen módon dolgozik, hogyan hasznosítja tapasztalatát és szakértelmét. Nem csak a munkavégzés kívülről könnyen észlelhető jellemzőit kell meghatározni (pl. alkalmazott munkamódszerek, eszközhasználati tapasztalat, képzettség stb.), hanem olyan nehezebben megfogható tényezőket is, mint a szervezeti kultúra. Idetartoznak mindazon fő gondolatok, értékrendek, meggyőződések, munkaszokások, elvárt viselkedés és napi megszokások, amelyeket a szervezet dolgozói követnek, jónak ismernek el és egymás közt megosztanak. A kultúra milyensége alapvető fontosságú, amely jól támogathatja a szolgáltatásfejlesztést, de amely az azzal szembeni ellenállás, ellenkezés hordozója, megjelenési formája is lehet. Képet kell kapni ezért a helyzetfelmérés során a szervezeti kultúra fő (fent említett) jellemzőiről, arról, hogy ezek milyen módon akadályozhatják a szükséges változások keresztülvitelét, valamint arról is, hogy a jelenlegi kultúrát milyen módon lehet változtatni, befolyásolni. Szükség lehet ugyanis új célok kitűzésére ezen a területen, és gyakran a dolgozók munkastílusa is megváltoztatandó. Új, javított ISz-folyamatok, munkaeljárások kialakításánál és bevezetésénél a szervezeti munkakultúra megértése elősegíti, hogy kellő figyelem irányuljon azoknak az esetleges problémáknak a megelőzésére, amelyek a jelenlegi létező hozzáállás, viselkedés stb. következtében alakulhatnak ki. Az ISz-szervezetek fejlődési modellje (ld. 14. ábra) kezdeti orientációt adhat e tekintetben is.
6.2.4.
Folyamatfelmérés
Talán a legfontosabb eleme a helyzetfelmérésnek az ISzM-folyamatok olyan értékelése, amely lemegy az egyes folyamatok és tevékenységcsoportok részleteinek megértésébe is. A “folyamat” fogalmát ebből a célból a következőképpen lehet meghatározni: Tevékenységek, eljárások olyan összefüggő rendszere, amit valamilyen konkrét célok és meghatározott eredmények elérése érdekében hajtanak végre. A “folyamatirányítás” fogalma pedig a következőt jelenti:
3
Erre kérdőív formájában egy konkrét példát is ad az 1. függelék.
115
Olyan tervezési és szabályozási jellegű folyamat4, amelynek a célja más folyamatok hatékony és eredményes működése. A következő ábra a folyamatok egy olyan általános modelljét mutatja be, amely megfelel a fenti meghatározásoknak, de azokat további részletekkel gazdagítja:
Célok A folyamat irányítása
Folyamatgazda
Folyamatcélok
Minőségi paraméterek és fő teljesítménymutatók
Folyamat Bemenet
A folyamat támogatása
Erőforrások
Tevékenységek, eljárások és alfolyamatok
Szerepkörök
Eredmény
Más folyamatok
16. ábra: Folyamatok általános modellje
Összegezve tehát a folyamatokról a következőket lehet általánosságban mondani: 1. A folyamatok különböző adatokat, anyagokat és termékeket, mint bemenetet használnak fel, és ezek feldolgozásával újabb adatokat, anyagokat ill. termékeket adnak eredményül. 2. Egy folyamat mindig bizonyos célok körül formálódik, amelyeknek való megfelelésért a folyamatgazda a felelős. 3. A folyamat céljainak való megfelelés magukban az eredményekben kell megmutatkoznia. Ennek érdekében az eredmények minőségi paramétereit és a folyamat teljesítménymutatóit a folyamatirányítás keretében mérik és értékelik. 4. A folyamat – ilyen értelemben vett – célszerű működéséhez tárgyi jellegű erőforrások alkalmazására és szerepek személyek közreműködésével történő ellátására is szükség van, amelyek együtt adnak hathatós támogatást a folyamat végrehajtásához. A közhiedelemmel ellentétben, a fenti értelemben jól meghatározott5 és kialakított6 folyamatok alkalmazása újszerű a legtöbb szervezet számára. Annak ellenére az, hogy széles körben elfo-
4
Azaz – elsősorban és meghatározó módon – tervezési és szabályozási tevékenységek és eljárások rendszere.
116
gadott: egy szervezet hatékonyabban és eredményesebben tud dolgozni, ha pontosan és részleteiben tudja, hogy a tevékenységéhez mi szükséges, és milyen eredményeket kell elérnie. Ha a tevékenységeket és eredményeket mérik, és ezt felhasználják a hatékonyság és eredményesség növelésére. Ha az üzleti kihívásoknak megfelelő elvárásokat minőségi paraméterek és teljesítménymutatók formájában beépítik a tevékenységükbe. A fentiekben körvonalazott folyamatközpontú megközelítés alátámasztja a minőségirányítási renszerek (pl. az ISO 9000:2000 típusú rendszerek) szokásos, „tervezés-végrehajtás-ellenőrzésbeavatkozás” jellegű szabályozási ciklusát (ld. még 12. ábra): a folyamat célját és eredményét olyan módon kell megtervezni (tervezés), hogy a folyamat végrehajtása felülvizsgálható (ellenőrzés) és, ha szükséges, javítható (beavatkozás) legyen. A folyamat eredményének meg kell felelnie az üzleti célokból származtatott operatív szintű követelményeknek. Ha a folyamat eredménye megfelel a követelményeknek, akkor azt eredményesnek lehet tekinteni. Ha a tevékenységeket többletráfordítás nélkül, vagy még inkább a lehető legkisebb ráfordítással hajtják végre, akkor hatékonynak lehet tekinteni. Mindennek eléréséhez azonban előfeltétel, hogy a folyamatok mérési eredményei be legyenek illesztve a szokásos és rendszeres vezetői jelentésekbe. 6.2.4.1. Az ISzM-folyamatok fejlettségi modellje A folyamatok felülvizsgálatának és javításának létezik széles körben elfogadott, nemzetközi szabvány formájában is közzétett modellje7 (ld. 17. ábra). A modellt keretként lehet használni akár egy-egy ISzM-folyamat egyenkénti, akár az ISzM területén az összes folyamat együttes felmérésére. A modell használata az ISzM-folyamatok fejlesztésére épít a ISzM-szervezetek korábban bevezetett ú.n. fejlődési modelljére (ld. 14. ábra), mivel az ISzM-folyamatok fejlettsége valamint a fogadókészség és igény a fejlesztésre erősen függ attól, hogy maga az egész ISzMszervezet milyen fejlődési stádiumban van. A modell szintről szintre jellemzők egy-egy jól meghatározott összességének megváltozását követeli meg annak érdekében, hogy az egyes szinteken a lehetőségek teljes mértékben ki legyenek használva.
5
A folyamat „jól meghatározott”, ha bemenetei, célja, felelőse, a feldolgozás módja, az elvárt eredmények, ezek jellemzői és a szükséges támogatás konzisztens módon leírásra kerültek, és az összes érdekelt azt megértette. 6
A folyamat „kialakított", ha a leírásával összhangban a folyamat bevezetésre, tkp. beágyazásra került a szervezetben: a bemenetek biztosítottak, az erőforrások a kívánt mennyiségben és minőségben rendelkezésre állnak, a szerepeket megfelelő képességekkel rendelkező személyek betöltik (beleértve a folyamatgazdát is), az eredményeket mérik, és ezek alapján értékelik a folyamat célszerű működését. 7
Ilyen a Software Engineering Institute (SEI, http://www.sei.edu/) ú.n. Integrated Capability Maturity Model (CMMI), azaz integrált képességérettségi modellje, valamint az ennek központi részét képező ISO/IEC 15504 szabvány (Szoftverfolyamatok felmérése). E modellek elsősorban a rendszer- és alkalmazásfejlesztés területén használatosak, az itt említett modell ennek átültetése az informatikaszolgáltatás területére.
117
5. Optimalizáló
Fejlettségi szint
4. Irányított 3. Kialakított 2. Megismételhető 1. Végrehajtott 0. Végre nem hajtott
Fejlesztési mérföldkövek 17. ábra: Folyamatfejlettségi modell
Kiindulva a folyamatok általános modelljéből (ld. 16. ábra) jól látható, hogy az informatikaszolgáltatás fejlesztésének korábban bevezetett öt dimenziójának (1. jövőkép, stratégia és irányítás; 2. folyamat, mint feldolgozási tevékenység; 3. személyzet; 4. technológia; 5. kultúra) mindegyikével a folyamatok szoros kapcsolatban állnak, fejlettségük jellemzéséhez igen hasznosak. A fejlettségi modell szintjeit ezért ezen öt dimenzió mentén következőképpen lehet jellemezni: Végre nem hajtott (0. szint): A folyamatot nem hajtják végre, esetleg nem is ismerik. Végrehajtott (1. szint): A folyamatot ismerik és végrehajtják; kevés vagy hiányzó folyamatirányítási tevékenység; a folyamat nem fontos a szervezet számára, nem irányul rá a figyelem, nincs kellő erőforrás biztosítva; gyakran kezdeti, „ad hoc” vagy éppen kaotikus szintnek is nevezik. 1.
Minimális mértékű pénzügyi alapok és erőforrások; kevés ilyen jellegű tevékenység
2.
Az eredményeket időlegesen sem tárolják el
3.
Szórványos jelentések és beszámoltatások
1.
Lazán meghatározott
2.
Teljesen reaktív megközelítés; a probléma felmerülése váltja ki
3.
Rendszertelen, tervezetlen tevékenységek
Személyzet
1.
Lazán meghatározott szerep- és felelősségi körök
Technológia
1.
Manuális folyamatok vagy néhány különálló, egyedi eszköz használata
Kultúra
1.
Eszköz- és technológiaalapú; erősen tevékenységközpontú
Jövőkép, stratégia és irányítás Folyamat
Megismételhető (2. szint): A folyamatot ismerik és végrehajtják; a folyamat kevéssé fontos a szervezet számára, a figyelem nem nagyon irányul rá. A folyamattal kapcsolatos tevékenységeket koordinálatlanul, rendszertelenül és megfelelő irányítás nélkül végzik; a központban az eredményesség áll. Jövőkép, stratégia és irányítás
1.
Nincsenek egyértelmű célok, formális célkitűzések
2.
Pénzügyi alapok és erőforrások rendelkezésre állnak
3.
Rendszertelen, tervezetlen tevékenységek, jelentések és beszámoltatások
Folyamat
1.
Meghatározott
2.
Nagyjában-egészében reaktív megközelítés
3.
Rendszertelen, tervezetlen tevékenységek
118
Személyzet
1.
Elkülönülő szerep- és felelősségi körök
Technológia
1.
Több különálló, egyedi eszköz használata ellenőrzés nélkül
2.
Az adatok különböző helyeken vannak tárolva
1.
Termék- és szolgáltatásalapú és -központú
Kultúra
Kialakított (3. szint): A folyamatot ismerik és végrehajtják, de nincs formális megállapodás, elfogadás vagy elismerés az informatikaszolgáltatás egészén belüli szerepét illetően; van gazdája a folyamatnak; a hatékonyság és az eredményesség egyaránt a központban áll. A jelentéseket és a beszámoltatások eredményeit eltárolják a későbbi visszakereshetőség érdekében. Jövőkép, stratégia és irányítás
Folyamat
Személyzet
Technológia Kultúra
1.
Dokumentált, elfogadott, formális célok és célkitűzések
2.
Formálisan közzétett, felügyelt és felülvizsgált tervek
3.
Jól megalapozott, és kellő erőforrással ellátott tevékenység
4.
Rendszeres és tervezett jelentések és beszámoltatások
1.
Világosan meghatározott és széles körben közzétett
2.
Rendszeres, tervezett tevékenységek
3.
Jól dokumentált
4.
Nagyjában-egészében kezdeményező jellegű megközelítés
1.
Világosan megfogalmazott és elfogadott szerep- és felelősségi körök
2.
Formális célok és célkitűzések
3.
Formalizált oktatási tervek a folyamatok betanítására
1.
Folyamatos adatgyűjtés riasztási és küszöbfigyelő funkciókkal
2.
Egységes adattárolás formális tervezés, előrejelzés és trendelemzés céljából
1.
Szolgáltatás- és ügyfélközpontú, formális megközelítéssel
Irányított (4. szint): A folyamatot teljes mértékben ismerik és elismerik az informatikaszolgáltatás egész területén; a központban a folyamat, mint kifelé nyújtott szolgáltatás áll. Megelőző jellegű, és jól dokumentált, kialakított kapcsolatai vannak más informatikai folyamatokkal. 1.
Üzleti célok és formális célkitűzések
2.
Az előrehaladást mérik
3.
Az informatív vezetői jelentéseket érdemben használják
4.
A folyamatfejlesztési terveket összekapcsolják az üzleti és informatikai tervekkel
5.
Rendszeres, tervezett és felülvizsgált javítások
1.
Jól meghatározott folyamatok, eljárások és szabványok, amelyeket minden informatikus munkaköri leírásába beillesztenek
2.
Világosan meghatározott kapcsolatok és függőségi viszonyok
3.
Integrált informatikaszolgáltató és –fejlesztő folyamatok
4.
Túlnyomóan kezdeményező jellegű megközelítés
1.
Csapatmunka a folyamatok között és azokon belül
2.
A szerep- és felelősségi körök minden informatikai munkaköri leírásban megjelennek
Technológia
1.
Folyamatos követés, mérés, jelentéskészítés és küszöbfigyelés integrált eszközök, adatbázisok és folyamatok központosításával
Kultúra
1.
Üzletközpontú; megértik a szélesebb összefüggéseket is
Jövőkép, stratégia és irányítás
Folyamat
Személyzet
Optimalizáló (5. szint): A folyamatot teljes mértékben a stratégiai, üzleti és informatikai célokkal összhangban lévőnek ismerik és fogadják el. A folyamat intézményesült. Jövőkép,
1.
Integrált stratégiai tervek elválaszthatatlanul összekapcsolódnak az átfogó üzle-
119
stratégia és irányítás
ti tervekkel, célokkal és célkitűzésekkel 2.
A folyamatfelügyelet, -mérés, jelentéskészítés, riasztás és beszámoltatás összekapcsolódik a folyamatos szolgáltatásfejlesztéssel
3.
Rendszeres beszámoltatások és/vagy felülvizsgálatok az eredményesség, hatékonyság és megfelelés érdekében
1.
Jól meghatározott része a teljes szervezeti kultúrának
2.
Kezdeményező és megelőző jellegű megközelítés
1.
Az üzleti igényekkel összhangban lévő célokat és formális célkitűzéseket napi tevékenység keretében aktívan figyelemmel követik
2.
A szerep- és felelősségi körök a teljes szervezti kultúra részét képezik
Technológia
1.
Jól dokumentált, átfogó, teljesen integrált informatikai (eszköz)architektúra a személyzet, folyamatok és technológia minden területén
Kultúra
1.
A hozzáállást a folyamatos fejlesztés elvének elfogadása, követése valamint a stratégia-, üzletközpontúság jellemzi.
2.
Megértik az informatika értékét az üzletvitelben, és a szerepét az üzleti értékteremtésben.
Folyamat Személyzet
6.2.5.
Eszközfelmérés
A helyzetfelmérés során nem szabad elfeledkezni arról sem, hogy leltárt készítsünk a meglévő eszközökről, ezek használatáról és alkalmasságukról az adott területen. Igen gyakori, hogy számtalan különböző eszköz áll rendelkezésre az egyes szervezeti egységeknél, és gyakran: •
ezek kevéssé vannak integrálva, vagy nem osztják meg maguk között az adatokat;
•
az egyes folyamatokhoz használt eszközök nem támogatják a szervezet funkcionális szintjeit;
•
az adatszerkezet és –kezelés nem szabható le olyan rekordattribútumokra és adatokra, amelyek az ITIL-alapú munkafolyamatokhoz kellenek.
Az ISzM-folyamatfejlettségi modell elősegítheti e hiányosságok fokozatos kiküszöbölését is.
120
A. függelék: Gyors, kérdőíves összemérés az ITIL-lel Az alábbi kérdőív jól használható egy informatikai szervezet SzM-folyamatainak összehasonlítására az ITIL-lel, mint a bevált, jó gyakorlat megtestesítőjével. Ez az összemérési megközelítés egy egyszerű kérdőíven alapul, amely lehetővé teszi annak meghatározását, hogy milyen vonatkozásban és mértékben felel meg egy ISz-szervezetnél a jelenlegi gyakorlat az ITIL-folyamatoknak, valamint hogy konkrét lépésekkel hol és hogyan lehet ebben az irányban előrelépni. A megközelítés a folyamatok általános modelljén alapul (ld. 16. ábra), ami több olyan folyamatkomponenst azonosít, amelyeknek a helyükön kell lenniük, működniük, hatniuk kell ahhoz, hogy az üzleti oldal és az ügyfelek igényeinek a folyamat meg tudjon felelni. Annak megállapításához, hogy az ISz-szervezet egy-egy folyamata hol áll az ITIL-folyamatokhoz képest, számos kérdést kell megválaszolni. Ezek a kérdések súlyozva vannak: azok, amelyek valamivel nagyobb jelentőséggel bírnak kötelezően „Igen” választ kell kapniuk, hogy az adott öszszetevő szempontjából az ITIL-folyamatnak megfeleljen. Ezek a kérdések „K” betűvel vannak megjelölve a „Nem” oszlopban (jelezve, hogy „Igen” válasz szükséges a megfeleléshez). Az alábbi lépéseket kell annak érdekében követni, hogy egy folyamat ITIL-követelményeknek való megfelelését megállapíthassuk: •
az 1. szemponttal kell kezdeni, és meg kell válaszolni az összes kérdést bejelölve a megfelelő választ az „Igen” vagy „Nem oszlopokban;
•
ellenőrizni kell az 1. szempont értékelő táblázatának alján szereplő feltételt:
•
•
ha teljesül, akkor a folyamat megfelel az ITIL-követelményeknek ebből a szempontból, és folytatni kell tovább az értékelést a többi szemponttal, hogy a folyamat egésze megfelelésének mértékét pontosabban meg lehessen határozni;
•
ha nem, akkor a folyamat egésze megfelelésének mértékét sikerült meghatározni (ha már az 1. szempont szerint sem felelt meg, akkor az egész folyamat sem felelt meg), de célszerű folytatni a további szempontokkal is, mivel az ezek szerinti értékelés további fontos betekintést adhat a folyamat jelenlegi helyzetének ismeretéhez, ami befolyásolhatja a javító intézkedések meghatározását is;
folytatni kell a többi szemponttal, amíg a feltétel valamelyik szempontnál nem teljesül teljes egészében; például, ha egy folyamatra az1. 2. 3. és 4. szempont feltétele teljesül, de az 5-é nem teljes egészében, akkor a folyamat megfelelésének mértéke 4 (0-9 közötti 10-fokozatú skálán); nem kell további kérdéseket megválaszolni e tekintetben, azonban a kérdőív megmaradt szempontjai szerint célszerű továbbfolytatni az előző megjegyzés értelmében.
A.1. Az összemérés pontozási rendszerének indoklása
A 18. ábra szemlélteti a kérdőívnél alkalmazott pontozási rendszer fő szempontjait. Az első szempont (Előfeltételek) szerinti értékelés megállapítja, hogy a folyamat tevékenységeihez minimálisan szükséges dolgok rendelkezésre állnak-e. A 2. szempont (Üzleti-stratégiai irányítás) szerinti értékelés megállapítja, hogy a szervezet stratégiai irányelvei, üzleti céljai (vagy az ilyen jellegű szándék más hasonló konkrétumai) adnak-e megfelelő irányt és útmutatást a folyamat működéséhez.
121
18. ábra: Folyamatértékelési szempontrendszer
Az értékelési rendszer kezdeti szempontjainál a kérdőív általános fogalmakkal hivatkozik a különböző termékekre és tevékenységekre. A későbbi szempontoknál jóval specifikusabb ITILfogalmakat használ kiindulva abból a feltételezésből, hogy a jobb eredményre törekvő ISzszervezetek nagyobb valószínűséggel ismerik és alkalmazzák az ITIL-szóhasználatot. A 3. szempont (Képesség) szerinti értékelés megvizsgálja, hogy milyen tevékenységeket hajtanak végre. A kérdések arra irányulnak, hogy az ITIL szerint minimálisan szükséges tartott tevékenyésgeket végrehajtják-e. A 4. szempont (Belső integráltság) szerinti értékelés arra irányul, hogy vajon a folyamat tevékenységei megfelelően integráltak-e, hogy a folyamat elérje a célját. Az 5. szempont (Teljesítmény) szerinti értékelés a folyamat tényleges eredményeit vizsgálja meg annak eldöntése érdekében, hogy az összes szükséges terméket/szolgáltatást valóságosan is előállítja-e a folyamat. A 6. szempont (Minőségellenőrzés) szerinti értékelés azzal foglalkozik, hogy a folyamat eredményeinek vizsgálata és igazolása összhangban áll-e a minőségi célkitűzésekkel, képes-e biztosítani ezek elérését. A 7. szempont (Vezetői információk) szerinti értékelés a folyamat irányításával foglalkozik, és azt vizsgálja, hogy megfelelő információkat időben előállít-e a folyamat a szükséges vezetői döntések előkészítése céljából. A 8. szempont (Külső integráltság) szerinti értékelés azt vizsgálja, hogy vajon minden érintkezési felület és kapcsolódási pont az adott folyamat és más folyamatok között megfelelő módon ki lett-e alakítva a szervezetben. Ennél a szempontnál már feltételeződik, hogy a teljes ITIL-fogalomkör ismert és használt az informatikaszolgáltatás menedzsmentjénél.
122
A 9. szempont (Ügyfélelégedettség) szerinti értékelés alapvetően a folyamat külső vizsgálataival és felülvizsgálataival foglalkozik annak érdekében, hogy biztosítsa a folyamat a továbbiakban is az ügyfelek igényeire optimalizáltan fog működni. A kérdőíves összemérés célja nem pusztán annak megállapítása, hogy az adott ISz-szervezet folyamatai teljesen megfelelnek-e az ITIL-követelményeknek vagy sem, hanem sokkal inkább az, hogy a szervezet visszajelzést kapjon arról, hogy mennyire jól működnek összehasonlítva az ITIL-ben megtestesülő bevált gyakorlattal. A kérdőív arra is törekszik, hogy felhívja a figyelmet azokra az irányítási és ellenőrzési treületekre, amelyeket a folyamatok fejlettségének növelése végett javítani kellene. A.2. Konfigurációkezelés 1 Előfeltételek
Igen
Nem
Legalább néhány konfigurációkezelési tevékenység létezik a szervezeten belül, pl. konfigurációs elemek regisztrálása?
K
Meg vannak-e határozva bizonyos konfigurációs elem tulajdonságok, pl. hely, pillanatnyi állapot, szolgáltatás elemek kapcsolata?
K
A konfigurációkezelés feladataival erre kijelölt személyek foglalkoznak vagy külön funkcionális területet jelent? Létezik a jelenleg használt informatikai eszközökről egy naprakész nyilvántartás? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 2 Üzleti-stratégiai irányítás
Igen
Nem
A konfigurációkezelés célját, előnyeit megismerték a szervezeten belül?
K
A konfigurációkezelés tevékenységeinek terjedelme meg van határozva a szervezeten belül? Léteznek eljárások a konfigurációs elemek regisztrálásához? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 3 Képesség
Igen
Nem
A konfigurációkezeléssel kapcsolatos tevékenységek végrehajtására ki vannak jelölve felelős személyek?
K
Létezik a konfigurációs elemek információinak kinyerésére, frissítésére, analizálására létezik eljárás?
K
A hatás felméréshez a konfigurációs adatokat rendszeresen használják? A konfigurációs adatokat rendszeresen használják új konfigurációs elemek létrehozásakor vagy installálásakor? A konfigurációkezelési tevékenységeket rendszeres időközönként átvizsgálják? Végeznek rendszeresen konfiguráció auditot? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 4 Belső integráltság
Igen
Nem
Érvényben vannak ellenintézkedések a duplikált konfigurációs elemek és egyéb anomáliák kiküszöbölésére?
K
A konfigurációs adatokat rendszeresen használják kapacitástervezésre, pl. konfigurációs elemek mennyiségének növekedése? A szolgáltatás támogatását és nyújtását végző személyek rendszeresen kinyerik a szükséges konfigurációs adatokat tevékenységük támogatása céljából, pl. ügyfélszolgálat személyzete? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 5 Teljesítmény
Igen
Nem
A konfigurációs elemekről készülnek rendszeres időközönként előre definiált riportok?
K
A konfigurációkezelés által előállított végtermékek és azok hasznossága a többi témakörök (szolgáltatás támogatása és biztosítása) számára világos a szervezet többi részének? A konfigurációs elemek installációjának, létrehozásának ütemezése a konfigurációs adatbázis alapján történik? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 6 Minőségellenőrzés
Igen
Nem
A konfigurációs elemek regisztrálásakor alkalmazott szabványos eljárások vagy egyéb minőségi kritériumok egyértelműek és be vannak tartva?
K
A konfigurációkezelésért felelős alkalmazottak megfelelően ki vannak képezve?
K
Meg vannak-e határozva és átvizsgálják-e a konfigurációkezelés céljait? Használatban van-e bármely olyan eszköz, amellyel a konfigurációkezelés folyamatot támogatni lehet? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre
123
7 Vezetői információk
Igen
Nem
Előállnak-e az alábbi menedzsment információk? •
Jelentős változtatások által érintett konfigurációs elemekről
K
•
Konfigurációkezelés céljainak eléréséről
K
•
Konfigurációs adatbázis növekedésének és használatáról
•
Az egyes konfigurációs elemeket, típusokat érintő kivételes problémákról
•
Szabványoknak való nem-megfelelésről
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 8 Külső integráltság
Igen
Nem
Tartanak rendszeres megbeszéléseket az érintett szereplőkkel a konfigurációkezelés ügyeinek megbeszélésére?
K
Kapnak-e illetve küldenek-e értesítéseket a változáskezelésnek minden, a konfigurációs elemek üzembe állításáról és az azokat érintő változtatásokról?
K
A hiteles szoftverkönyvtár és a konfigurációs adatbázis konzisztenciájának elérése érdekében van-e információ csere a Kiadáskezeléssel?
K
Az új konfigurációs elemekről rendelkezésre áll-e információ Az ügyfélszolgálat számára? A problémákhoz, beszállítóhoz, ügyfelekhez, változtatásokhoz kapcsolódó konfigurációs elemekről van-e információ csere a problémakezeléssel? A költségekről, költség kódokról és más tulajdonságokról van-e információ csere a pénzügyi menedzsmenttel? A konfigurációs elemekről, mentések részleteiről, biztonsági és katasztrófa elhárítási témákról rendelkezésre áll-e információ a Katasztrófa elhárítás tervezés számára? A konfigurációs adatbázisból rendelkezésre állnak-e információk a növekedés becsléséhez a kapacitásmenedzsment számára? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 9 Ügyfél elégedettség
Igen
Nem
Végez ellenőrzést az ügyféllel arról, hogy a konfigurációkezelés tevékenységek megfelelően támogatják-e az üzleti igényeiket?
K
Ellenőrzik, hogy az ügyfelei elégedettek-e a nyújtott szolgáltatásokkal?
K
Folyamatosan ellenőrzik, hogy az ügyfél elégedettség milyen trendet követ?
K
Az ügyfél megelégedettségi felmérések eredményét felhasználják-e a szolgáltatás-javítási tervben?
K
Mérik a szolgáltatások ügyfelek által érzékelt értékét?
K
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre
A.3. Ügyfélszolgálat 1 Előfeltételek
Igen
Nem
Legalább néhány ügyfélszolgálat tevékenység létezik a szervezeten belül, pl. incidens-rögzítés?
K
Léteznek-e a bejelentések azonosítására, incidensek rögzítésére, kérdések kezelésére vonatkozó eljárások? Az ügyfélszolgálat nyújt-e valamilyen első vonali segítséget? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 2 Üzleti-stratégiai irányítás
Igen
Nem
Az ügyfélszolgálat operátoroknak van a hívások kezelését segítő kérdés lista?
K
Léteznek eljárások az incidensek rögzítéséhez? A ügyfélszolgálat célját, előnyeit megismerték a szervezeten belül? Az incidensek megoldására és hívások kezelésére vannak-e célok kitűzve? Ki vannak-e jelölve a felhasználókat képviselő (kulcsfelhasználók) a szervezeten belül az elsővonali segítségnyújtás és megoldások támogatására? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 3 Képesség
Igen
Nem
Létrejött megállapodás az ügyfélszolgálat funkcióit tekintve?
K
Az ügyfélszolgálat operátorok használnak-e valamilyen stratégiát a bejelentéseknél a szükséges információk kinyeréséhez?
K
Létezik az incidensek monitorozására, a megoldás előrehaladásának figyelésére valamilyen eljárás?
K
Van az incidensek lezárására valamilyen eljárás?
K
Az ügyfélszolgálat tisztázza a tervezett javítások állapotát?
124
Az ügyfélszolgálat tájékoztatja-e az érintett felhasználókat a megoldás a latt levő incidensek / problémák állapotának változásáról? Az ügyfélszolgálat szolgáltat információt az incidensek megoldásáról? A felhasználók kapnak felvilágosítást körözvények révén? Az ügyfélszolgálat értesül az új szolgáltatástámogatási igényekről? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 4 Belső integráltság
Igen
Nem
Az ügyfélszolgálat felelős az összes incidens adat teljességéért?
K
Az ügyfélszolgálat központi (hiba)bejelentési felületet nyújt? Az incidens bejegyzéseket a megoldás előrehaladásának folyamatos monitorozására / ellenőrzésére használják? Az ügyfélszolgálat felelősségi körébe tartozik a megoldás felhasználóval történő egyeztetése és az incidens lezárása? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 5 Teljesítmény
Igen
Nem
Az incidensekről készülnek rendszeres időközönként előre definiált riportok?
K
Az ügyfélszolgálat által nyújtott szolgáltatások az ügyfelek és külső felek számára egyértelműen definiáltak? A menedzsment áttekinti a bejelentéseket új támogatási igények azonosítása céljából? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 6 Minőségellenőrzés
Igen
Nem
Az incidensek rögzítésére és hívások fogadására léteznek szabványos eljárások vagy egyéb minőségi kritériumok, amelyekkel tisztában vannak az ügyfélszolgálat operátorok?
K
Az ügyfélszolgálat személyzet megfelelően ki van képezve?
K
Meg vannak-e határozva és átvizsgálják-e az ügyfélszolgálat céljait? Használatban van-e bármely olyan eszköz, amellyel ügyfélszolgálati funkciót támogatni lehet? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 7 Vezetői információk
Igen
Nem
Előállnak-e az alábbi menedzsment információk? •
Incidens rekordokról
K
•
Az ügyfélszolgálat működésének teljesítményéről
K
•
Felhasználói oktatások szükségességéről
•
A konfigurációs elemek anomáliájáról részletek
•
Incidens előfordulásának, megoldásának trend elemzéséről
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 8 Külső integráltság
Igen
Nem
Tartanak rendszeres megbeszéléseket az érintett szereplőkkel az ügyfélszolgálat ügyeinek megbeszélésére?
K
A problémákkal, ismert hibákkal kapcsolatban van-e információ csere a problémakezeléssel?
K
A konfigurációs bejegyzések könnyű kezelhetőségéről, konfigurációs anomáliákról van-e információ csere a konfigurációkezeléssel? Az incidensek, problémák megoldását célzó lehetséges változtatások részleteiről van-e információ csere a változáskezeléssel? A szolgáltatási szintek megsértéséről, a szolgáltatási és támogatási kötelezettségekről van-e információ csere a szolgáltatási szint menedzsmenttel? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 9 Ügyfél elégedettség
Igen
Nem
Végez ellenőrzést az ügyféllel arról, hogy a ügyfélszolgálati tevékenységek megfelelően támogatják-e az üzleti igényeiket?
K
Ellenőrzik, hogy az ügyfelei elégedettek-e a nyújtott szolgáltatásokkal?
K
Folyamatosan ellenőrzik, hogy az ügyfél elégedettség milyen trendet követ?
K
Az ügyfél megelégedettségi felmérések eredményét felhasználják-e a szolgáltatásjavítási tervben?
K
Mérik a szolgáltatások ügyfelek által érzékelt értékét?
K
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre
A.4. Kiadáskezelés
125
1 Előfeltételek
Igen
Nem
Legalább néhány kiadáskezelés tevékenység létezik a szervezeten belül, pl. szoftver csomag készítésének ellenőrzése, szoftver konfigurációs elemek változtatása?
K
Kiadáskezelés feladataival erre kijelölt személyek foglalkoznak vagy külön funkcionális területet jelent? Létezik friss adatokat tartalmazó szoftver leltár? A szoftver elemeket tároló médiák ellenőrzés alatt vannak? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 2 Üzleti-stratégiai irányítás
Igen
Nem
A kiadáskezelés célját, előnyeit megismerték a szervezeten belül?
K
A kiadáskezelés tevékenységeinek terjedelme meg van határozva a szervezeten belül? Léteznek eljárások a szoftver elemek regisztrálásához függetlenül annak eredetétől, pl. belső fejlesztés? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 3 Képesség
Igen
Nem
Ki vannak jelölve felelősségi körök a szoftver kiadások kezelésére?
K
Vannak üzemeltetési eljárások az új szoftver elfogadására, függetlenül annak eredetétől?
K
Van a szoftver terítés végzését előíró eljárás?
K
Vannak irányelvek a szoftver kiadások létrehozását, kezelését, tesztelését illetően? Vannak formális eljárások új szoftver üzembe helyezésére? Léteznek eljárások a szoftverhasználat monitorozására? Léteznek eljárások a szoftver licencek kezelésére? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 4 Belső integráltság
Igen
Nem
Érvényben vannak ellenintézkedések a duplikált konfigurációs elemek és egyéb anomáliák kiküszöbölésére?
K
A konfigurációs elem rekordok összhangban vannak a tényleges mozgásokkal (változtatásokkal)?
K
A licenc információk a konfigurációs elemek rekordjaival együtt vannak tárolva és a szoftver terítés alatt ezek ellenőrzésen mennek keresztül? A szoftver konfigurációs elemek rekordjait rendszeresen használják a kiadáskezelés folyamata során? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 5 Teljesítmény
Igen
Nem
A szoftver konfigurációs elemek terítéséről készülnek rendszeres időközönként előre definiált riportok?
K
A kiadáskezelés által nyújtott szolgáltatások mások számára (többi témakör) egyértelműen definiáltak? Az összes érintett fél kap értesítést a szoftverinstallálásokról? Kapnak értesítést az érintett felek a licenc információkról? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 6 Minőségellenőrzés
Igen
Nem
A kiadáskezelésnél és a szoftver kiadások kezelésénél léteznek-e szabványos eljárások vagy egyéb minőségi kritériumok?
K
A kiadáskezelés személyzete megfelelően ki van képezve?
K
Meg vannak-e határozva és átvizsgálják-e a kiadáskezelés céljait? Használatban van-e bármely olyan eszköz, amellyel a kiadáskezelés folyamatot támogatni lehet? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 7 Vezetői információk
Igen
Nem
Előállnak-e az alábbi menedzsment információk? •
Új / változtatott szoftverek kiadásáról
K
•
Szoftver licencekről
K
•
Sikertelen telepítésekről
•
Statisztikák mentésekről, archiválásokról
•
Licenc kötelezettségek megsértéséről
•
Redundáns szoftver konfigurációs elemek azonosításáról kiszűréséről
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre
126
8 Külső integráltság
Igen
Nem
Tartanak rendszeres megbeszéléseket az érintett szereplőkkel a kiadáskezelés ügyeinek megbeszélésére?
K
A szoftver komponensekről, köztük levő kapcsolatról, változtatásokról van-e információ csere a konfigurációkezeléssel?
K
Új és változtatott konfigurációs elemekről van-e információ csere a változáskezeléssel?
K
A szoftver könyvtár helyigényének pontosításával kapcsolatban van-e információ csere a kapacitásmenedzsmenttel? A konfigurációs elemekkel kapcsolatos ismert hibákkal kapcsolatban van-e információ csere a problémakezeléssel? A szoftver elemekkel telepítését elősegítése érdekében történő leállásokkal kapcsolatban van-e információ csere a rendelkezésreállás menedzsmenttel? A körözvényekben a felhasználóknak küldött tanácsokkal kapcsolatban van-e információ csere az ügyfélszolgálattal? A felmerülő költségekkel / számlázással kapcsolatban van-e információ csere a pénzügyi menedzsmenttel? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 9 Ügyfél elégedettség
Igen
Nem
Végez ellenőrzést az ügyféllel arról, hogy a kiadáskezelés tevékenységek megfelelően támogatják-e az üzleti igényeiket?
K
Ellenőrzik, hogy az ügyfelei elégedettek-e a nyújtott szolgáltatásokkal?
K
Folyamatosan ellenőrzik, hogy az ügyfél elégedettség milyen trendet követ?
K
Az ügyfél megelégedettségi felmérések eredményét felhasználják-e a szolgáltatásjavítási tervben?
K
Mérik a szolgáltatások ügyfelek által érzékelt értékét?
K
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre
A.5. Problémakezelés 1 Előfeltételek
Igen
Nem
Legalább néhány problémakezelés tevékenység létezik a szervezeten belül, pl. probléma meghatározása, probléma analízis, probléma megoldás?
K
Problémakezelés feladataival erre kijelölt személyek foglalkoznak vagy külön funkcionális területet jelent? Létezik eljárás, amely szerint a fontos incidensek az első vonali ügyfélszolgálattól a szakmai csoportokhoz eszkalálódnak? A potenciális problémákat előzetesen felmérik, azonosítják? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 2 Üzleti-stratégiai irányítás
Igen
Nem
A problémakezelés célját, előnyeit megismerték a szervezeten belül?
K
Léteznek eljárások a problémák és azok megoldásának regisztrálásához? A szervezet elkötelezett a problémák számának csökkentése és a megoldási idők csökkentése iránt? Törekedik-e a menedzsment a megelőző problémakezelés megvalósítására? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 3 Képesség
Igen
Nem
Ki vannak jelölve felelősségi körök a problémakezelés tevékenységeinek végrehajtására?
K
Van-e eljárás a fontos incidensek kezelésére?
K
Létezik-e olyan eljárás, amely szerint a potenciális problémákat vizsgálatnak vetik alá?
K
A problémák felelősei használna-e megfelelő irányelveket a problémák jellegének meghatározásához? Zajlanak-e komplex, pl. több műszaki területet koordináló problémafeltáró tevékenységek? Léteznek eljárások problémák lezárására? Léteznek eljárások a problémamegoldás követésére? Mérik a problémamegoldás hatékonyságát? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 4 Belső integráltság
Igen
Nem
A probléma jellege mindig dokumentálásra kerül a probléma rekorddal együtt?
K
A problémakezelés felelős az összes probléma rekord teljességéért?
K
A problémákra adott megoldás javaslatokat egy külső csoport megvizsgálja és jóváhagyja? A probléma rekordokat módosítják a megoldási tevékenységnek megfelelően? A problémakezelés felelős a probléma rekordok utólagos átvizsgálásáért? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre
127
5 Teljesítmény
Igen
Nem
A problémakezelés tevékenységekről készülnek rendszeres időközönként előre definiált riportok?
K
A problémakezelés által nyújtott szolgáltatások mások számára (többi témakör) egyértelműen definiáltak? A probléma analízis eredményeképp létrejönnek változáskérelmek? Léteznek riportok a megelőző problémakezelés eredményéről? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 6 Minőségellenőrzés
Igen
Nem
A problémakezelésnél léteznek-e szabványos eljárások vagy egyéb minőségi kritériumok?
K
A problémakezelés személyzete megfelelően ki van képezve?
K
Meg vannak-e határozva és átvizsgálják-e a problémakezelés céljait? Használatban van-e bármely olyan eszköz, amellyel a problémakezelés folyamatot támogatni lehet? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 7 Vezetői információk
Igen
Nem
Előállnak-e az alábbi menedzsment információk? •
Probléma rekordok analízisének eredményéről
•
A problémakezelés és más támogatást nyújtó terület teljesítményéről
•
Problémák eloszlásának trendjéről, potenciális gyenge pontokról
K
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 8 Külső integráltság
Igen
Nem
Tartanak rendszeres megbeszéléseket az érintett szereplőkkel a problémakezelés ügyeinek megbeszélésére?
K
A konfigurációs elemek rekordjainak minőségéről van-e információ csere a konfigurációkezeléssel?
K
A probléma megoldások érdekében végrehajtott változtatásokról, sürgős esetek kezeléséről van-e információ csere a változáskezeléssel?
K
A problémákhoz kapcsolódó incidensekről, a felhasználóknak küldött tájékoztatásokról (pl. körözvények a közérdekű incidensekről) van-e információ csere az ügyfélszolgálattal?
K
A problémák prioritásáról, a szolgáltatási szint megállapodásokra való lehetséges hatásokról van-e információ csere a szolgáltatási szint menedzsmenttel? Jelentős szolgáltatás kieséskor végrehajtott lehetséges katasztrófa elhárítási tevékenységekről van-e információ csere az informatikaszolgáltatás-folytonosság menedzsmenttel? A szolgáltatások kiesésének terjedelmével, időtartamával kapcsolatban van-e információ csere a rendelkezésreállás menedzsmenttel? A konfigurációs elemeket, a problémák és a konfigurációs elemek közti kapcsolatot érintően van-e információ csere a kiadáskezeléssel? A problémák trendjével, a kapacitástervezési lehetőségekkel kapcsolatban van-e információ csere a Kapacitásmenezsmenttel? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 9 Ügyfél elégedettség
Igen
Nem
Végez ellenőrzést az ügyféllel arról, hogy a problémakezelés tevékenységei megfelelően támogatják-e az üzleti igényeiket?
K
Ellenőrzik, hogy az ügyfelei elégedettek-e a nyújtott szolgáltatásokkal?
K
Folyamatosan ellenőrzik, hogy az ügyfél elégedettség milyen trendet követ?
K
Az ügyfél megelégedettségi felmérések eredményét felhasználják-e a szolgáltatásjavítási tervben?
K
Mérik a szolgáltatások ügyfelek által érzékelt értékét?
K
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre
A.6. Változáskezelés 1 Előfeltételek
Igen
Nem
Legalább néhány változáskezelés tevékenység létezik a szervezeten belül, pl. változáskérések rögzítése, változás hatásfelmérés, változástervezés?
K
A változáskezelés feladataival erre kijelölt személyek foglalkoznak vagy külön funkcionális területet jelent? Létezik eljárás, amely szerint a változáskéréseket kezdeményezik? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 2 Üzleti-stratégiai irányítás
Igen
Nem
128
A változáskezelés célját, előnyeit megismerték a szervezeten belül?
K
A változáskezelés tevékenységeinek terjedelme meg van határozva a szervezeten belül? Léteznek szabványos eljárások, minőségi kritériumok a változáskérések kezdeményezéséhez, regisztrálásához? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 3 Képesség
Igen
Nem
Ki vannak jelölve felelősségi körök a változáskezelés tevékenységeinek végrehajtására?
K
A változáskérések kezdeményezésére vonatkozó eljárásokat betartják?
K
Létezik eljárás a változáskérések jóváhagyására, ellenőrzésére, ütemezésére?
K
A változtatások üzleti és műszaki hatásait mindig felmérik? A változtatások előrehaladását megfelelően figyelemmel követik? A sikeres változtatások végrehajtását tényét a változáskezelés megerősíti? Létezik eljárás a változtatások utólagos vizsgálatára? Léteznek megfelelő riportok a változáskezelésről? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 4 Belső integráltság
Igen
Nem
Az összes változtatáskérés a kijelölt változáskezelési csatornákon keresztül zajlik?
K
A változtatásokat központilag vagy közös megegyezéssel tervezik, priorálják?
K
A változás rekordokat karbantartják, így azok tükrözik a mindenkori állapotot? A sikertelen változtatások okát feljegyzik és kiértékelik? A sikeres változtatásokat elemzik, hogy azok megfelelnek az üzleti igényeknek? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 5 Teljesítmény
Igen
Nem
A formális változáskezelés rekordokat karbantartják?
K
A jóváhagyott változtatásokat mindig ütemezik?
K
Léteznek rendszeresen előállított szabványos riportok a változtatások eredményéről? Léteznek szabványok a változtatások dokumentálására? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 6 Minőségellenőrzés
Igen
Nem
A változtatások dokumentálására léteznek-e szabványos eljárások vagy egyéb minőségi kritériumok?
K
A változáskezelés személyzete megfelelően ki van képezve?
K
Meg vannak-e határozva és átvizsgálják-e a változáskezelés céljait? Használatban van-e bármely olyan eszköz, amellyel a változáskezelés folyamatot támogatni lehet? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 7 Vezetői információk
Igen
Nem
Előállnak-e az alábbi menedzsment információk? •
A beérkező változtatás kérelmekről
K
•
Változtatások ütemezéséről
K
•
Változtatások számáról
•
A sikeres és sikertelen változtatások számáról
•
Változtatásokról kategóriánként
•
Változtatások elhúzódásáról
•
Problémák megoldásaként végrehajtott változtatások számáról
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 8 Külső integráltság Tartanak rendszeres megbeszéléseket az érintett szereplőkkel a változáskezelés ügyeinek megbeszélésére?
Igen
Nem K
Van-e információ csere a konfigurációkezeléssel a következőkről? •
Változtatások előrehaladása, lezárása
K
•
Változtatások hatása a konfigurációs elemekre
K
Van-e információ csere a problémakezeléssel a következőkről?
129
•
Problémák ismert hibák megoldására végzett változtatások
K
•
Probléma eszkalációs és a megoldás előrehaladását jelző riportok
K
•
Változtatások miatt bekövetkezett problémák
K
Van-e információ csere az ügyfélszolgálattal a következőkről? •
Változtatás folyamatáról értesítés
•
Változtatások ütemezéséről értesítés
•
Változtatások hatásának felmérése az ügyfélszolgálat szolgáltatási színvonalára
•
Változtatások miatt keletkezett incidensekről, bejelentésekről információ
Van-e információ csere a kiadáskezeléssel a következőkről? •
Változtatások végrehajtása
•
Értesítés a szoftver kiadásokról, és a szoftver kiadások ütemezése
Van-e információ csere a szolgáltatási szint menedzsmenttel a következőkről? •
Változtatások ütemezése
•
Változtatások lehetséges hatása a szolgáltatási szint megállapodásokra
Van-e információ csere az informatikaszolgáltatás-folytonosság menedzsmenttel a következőkről? •
Értesítés a változtatások ütemezéséről
•
Változtatások lehetséges hatása a katasztrófa elhárítási tervre
Van-e információ csere a kapacitásmenedzsmenttel a következőkről? •
változásokkal kapcsolatos teljesítmény és kapacitáskérdések
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 9 Ügyfél elégedettség
Igen
Nem
Végez ellenőrzést az ügyféllel arról, hogy a változáskezelés tevékenységei megfelelően támogatják-e az üzleti igényeiket?
K
Ellenőrzik, hogy az ügyfelei elégedettek-e a nyújtott szolgáltatásokkal?
K
Folyamatosan ellenőrzik, hogy az ügyfél elégedettség milyen trendet követ?
K
Az ügyfél megelégedettségi felmérések eredményét felhasználják-e a szolgáltatásjavítási tervben?
K
Mérik a szolgáltatások ügyfelek által érzékelt értékét?
K
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre
A.7. Szolgáltatási szint menedzsment 1 Előfeltételek
Igen
Nem
Legalább néhány szolgáltatási szint menedzsment tevékenység létezik a szervezeten belül, pl. szolgáltatások definiálása, szolgáltatási szint megállapodásokkal kapcsolatos egyeztető megbeszélések?
K
Meg vannak határozva az informatikaszolgáltatás felhasználói/ügyfelei? Definiálva vannak a szolgáltatások tulajdonságai? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 2 Üzleti-stratégiai irányítás
Igen
Nem
A szolgáltatási szint menedzsment célját, előnyeit megismerték a szervezeten belül?
K
Meg vannak határozva a szolgáltatási szint megállapodások alapjául szolgáló adatok? Léteznek olyan elfogadott eljárások, amely alapján a szolgáltatási szint megállapodásokban megállapodnak, áttekintik? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 3 Képesség
Igen
Nem
A szolgáltatási szint menedzsmenttel kapcsolatos tevékenységek végrehajtására ki vannak jelölve felelős személyek?
K
Létezik szolgáltatás katalógus?
K
Létezik a szolgáltatási szint mérésére, áttekintésére eljárás?
K
Az ügyfelek összes szolgáltatás igényét ellenőrzik? Léteznek eljárások a szolgáltatási szint megállapodások létrehozására? Léteznek olyan eljárások, amelyek a szolgáltatások javítását célozzák? Létezik ütemezés a szolgáltatások bevezetésére? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre
130
4 Belső integráltság
Igen
Nem
Végeznek összehasonlítást a tényleges és a megállapodott szolgáltatási szintekre vonatkozóan?
K
Létezik eljárás a szolgáltatás katalógus frissítésére, hogy az új / megváltoztatott szolgáltatásoknak megfeleljen? A szolgáltatásokról rögzített adatokat felhasználják a menedzsmentnek és az ügyfeleknek a szolgáltatás minőségéről adott információkhoz? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 5 Teljesítmény
Igen
Nem
Készülnek rendszeres időközönként előre definiált riportok?
K
A szolgáltatásokról és azok összetevőiről készül dokumentáció? A szolgáltatások összetevői konfigurációs elemként vannak kezelve? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 6 Minőségellenőrzés
Igen
Nem
A szolgáltatási szint menedzsment által használt szabványos eljárások vagy egyéb minőségi kritériumok dokumentálva vannak?
K
A szolgáltatási szint menedzsment felelős alkalmazottai megfelelően ki vannak képezve?
K
Meg vannak-e határozva és átvizsgálják-e a szolgáltatási szint menedzsment céljait? Használatban van-e bármely olyan eszköz, amellyel a szolgáltatási szint menedzsment folyamatot támogatni lehet? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 7 Vezetői információk
Igen
Nem
Előállnak-e az alábbi menedzsment információk? •
Szolgáltatás célokról, tényleges teljesítésről
K
•
Szolgáltatási szint megsértések trendjéről
K
•
Standard szolgáltatásokról
•
Új szolgáltatásra és szolgáltatás-változásra leadott igények számáról
•
Szolgáltatási szint igények trendjéről
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 8 Külső integráltság
Igen
Nem
A szolgáltatási szint menedzsment aktívan bevonja a rendelkezésreállás menedzsmentet a szolgáltatási szintekkel kapcsolatban?
K
A szolgáltatási szintek egyeztetésekor a szolgáltatási szint menedzsment konzultál-e más témakörökkel, pl. kapacitás menedzsment, pénzügyi menedzsment? A szolgáltatási szint menedzsmenttel konzultál-e a változáskezelés a szolgáltatási szinteket érintő változások lehetséges hatásairól? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 9 Ügyfél elégedettség
Igen
Nem
Végez ellenőrzést az ügyféllel arról, hogy a szolgáltatási szint menedzsment tevékenységek megfelelően támogatják-e az üzleti igényeiket?
K
Ellenőrzik, hogy az ügyfelei elégedettek-e a nyújtott szolgáltatásokkal?
K
Folyamatosan ellenőrzik, hogy az ügyfél elégedettség milyen trendet követ?
K
Az ügyfél megelégedettségi felmérések eredményét felhasználják-e a szolgáltatás-javítási tervben?
K
Mérik a szolgáltatások ügyfelek által érzékelt értékét?
K
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre
A.8. Informatikaszolgáltatás-folytonosság menedzsment 1 Előfeltételek
Igen
Nem
Legalább néhány Katasztrófa elhárítás tervezés tevékenység létezik a szervezeten belül, pl. üzleti hatáselemzés, visszatérési tervek készítése?
K
Meg vannak határozva az üzleti folyamatok működéseihez szükséges minimális követelmény szintek? Van a szervezetnek a folyamatos üzletmenet biztosítására stratégiája? Minimális pontszám:
“igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre
2 Üzleti-stratégiai irányítás Az informatikaszolgáltatás-folytonosság menedzsment célját, előnyeit megismerték a szervezeten belül?
Igen
Nem K
131
Meg van határozva az informatikaszolgáltatás-folytonosság menedzsment tevékenység terjedelme? Az összes informatikaszolgáltatás-folytonosság menedzsmenthez szükséges erőforrás biztosítását stratégiai terv írja elő? A legfelsőbb vezetés támogatja az informatikaszolgáltatás-folytonosság menedzsment intézkedéseinek megvalósítását? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 3 Képesség
Igen
Nem
Az informatikaszolgáltatás-folytonosság menedzsment tevékenységeire ki vannak jelölve a felelősök?
K
Az üzleti hatás elemzése révén meg vannak határozva a kritikus üzleti folyamatok minimális követelményei?
K
Lezajlott a kockázat felmérés? A Katasztrófa elhárítás tervezés alkotóelemeivel tisztában vannak? A Katasztrófa elhárítás tervezés tesztelésére, áttekintésére van-e szabványos eljárás ? Létezik kockázat csökkentő program a folyamatos üzemeltetés megvalósítására? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 4 Belső integráltság
Igen
Nem
Az informatikaszolgáltatás-folytonosság menedzsment felelős az informatikai katasztrófa elhárítás terv teljességéért?
K
Az üzleti folytonosság tervezői tájékoztatják az informatikaszolgáltatás-folytonosság menedzsmentet a szolgáltatások kritikusságáról / prioritásáról? A katasztrófa elhárítási terveket rendszeresen felülvizsgálják, az eljárásokat és folyamatokat tesztelik, szükség esetén módosítják? A katasztrófa elhárítási tervek aktiválásához szükséges műszaki tevékenységek teljesen dokumentálva vannak, így az informatikai személyzet végre tudja hajtani a visszatérési műveleteket? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 5 Teljesítmény
Igen
Nem
A kockázat felmérésről és csökkentésről készülnek rendszeres időközönként riportok?
K
Az informatikaszolgáltatás-folytonosság menedzsment készít riportokat alternatív ellenintézkedési opciókról a költségek és az elfogadható szolgáltatási szintek figyelembe vételével? Az informatikaiszolgáltatás-folytonosság menedzsment javítása céljából vannak-e formális változtatás kérések? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 6 Minőségellenőrzés
Igen
Nem
Az informatikaszolgáltatás-folytonosság menedzsment által használt szabványos eljárások vagy egyéb minőségi kritériumokat egyértelműek és használatban vannak?
K
Az informatikaszolgáltatás-folytonosság menedzsment tevékenységért felelős személyzet megfelelően ki van képezve?
K
Meg vannak-e határozva és átvizsgálják-e az informatikaiszolgáltatás-folytonosság menedzsment céljait? Használatban van-e bármely olyan eszköz, amellyel a kockázat felmérést és/vagy a katasztrófa elhárítás terv karbantartását támogatni lehet? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 7 Vezetői információk
Igen
Nem
Előállnak-e az alábbi menedzsment információk? •
Az üzletmenet folytonosságának sebezhetőségi pontjairól és sebezhetőség jellegéről
•
Katasztrófa elhárítási opciókról
•
Katasztrófa elhárítási tervről
•
A katasztrófa elhárítási terv változásairól
•
Visszaállítási tervek ellenőrzéséről
•
Kockázat csökkentésről (kockázat jellege és forrása, kockázat csökkentés/elkerülés mértéke)
•
Üzletmenet folytonossági stratégia eredményességéről
K
K
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 8 Külső integráltság Tartanak rendszeres megbeszéléseket az érintett szereplőkkel a Katasztrófa elhárítás tervezés ügyeinek megbeszélésére?
Igen
Nem K
Van-e információ csere a rendelkezésreállás menedzsmenttel a következőkről? •
Kockázat csökkentés
K
•
A katasztrófa elhárítási terv rendelkezésreállásra vonatkozó komponensei, belső szolgáltatási megállapodások, szerződés külső felekkel
K
132
Van-e információ csere a változáskezeléssel a következőkről? •
A katasztrófa elhárítási tervet érintő változásokról
K
•
Kockázat csökkentő/elkerülő változtatások felmérése
K
Van-e információ csere a kapacitásmenedzsmenttel a következőről? •
Kapacitással / tárolással kapcsolatos kockázatokról
•
Visszatérési tervek teszteléséhez szükséges kapacitás / tárolási követelményekről
Van-e információ csere a szolgáltatási szint menedzsmenttel a következőkről? •
Szolgáltatási szint megállapodások és Katasztrófa elhárítási tervek közötti kereszthivatkozások, katasztrófa illetve visszaállítás ideje alatti speciális szolgáltatási szintek
Van-e információ csere a konfigurációkezeléssel a következőkről? •
Katasztrófa elhárítási követelmények, végleges konfigurációs részletek a konfigurációs adatok pontosságának biztosításának céljából.
•
informatikai komponensek és szolgáltatások közötti kapcsolatok
Van-e információ csere a problémakezeléssel a következőkről? •
Jelentős problémák áttekintése
•
Katasztrófa elhárítás tervezést érintő problémák okainak / megoldásainak megvitatása
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 3 “igen” más kérdésre 9 Ügyfél elégedettség
Igen
Nem
Végez ellenőrzést az ügyféllel arról, hogy a Katasztrófa elhárítás tervezés tevékenységek megfelelően támogatják-e az üzleti igényeiket?
K
Ellenőrzik, hogy az ügyfelei elégedettek-e a nyújtott szolgáltatásokkal?
K
Folyamatosan ellenőrzik, hogy az ügyfél elégedettség milyen trendet követ?
K
Az ügyfél megelégedettségi felmérések eredményét felhasználják-e a szolgáltatás-javítási tervben?
K
Mérik a szolgáltatások ügyfelek által érzékelt értékét?
K
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre
A.9. Rendelkezésreállás menedzsment 1 Előfeltételek
Igen
Nem
Legalább néhány rendelkezésreállás menedzsment tevékenység létezik a szervezeten belül, pl. szolgáltatás komponensek monitorozása, szolgáltatás rendelkezésreállásának analízise?
K
Rendelkezésreállás menedzsment feladataival erre kijelölt személyek foglalkoznak vagy külön funkcionális területet jelent? Létezik eljárás a szolgáltatások kiesésének és a konfigurációs elemek hibáinak észlelésére? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 2 Üzleti-stratégiai irányítás
Igen
Nem
A rendelkezésreállás menedzsment célját, előnyeit megismerték a szervezeten belül?
K
A szervezet elkötelezett a külső partnerek szolgáltatási szint célokkal kapcsolatos teljesítményének monitorozásával kapcsolatban? A szervezet elkötelezett az informatikaszolgáltatás rendelkezésreállási tervének rendszeres elkészítésével kapcsolatban? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 3 Képesség
Igen
Nem
Ki vannak jelölve felelősségi körök a rendelkezésreállás menedzsment tevékenységeinek végrehajtására?
K
A rendelkezésreállás menedzsment tevékenységeinek terjedelme meg van határozva a szervezeten belül?
K
Léteznek eljárások a szolgáltatások rendelkezésreállásának monitorozására, analizálására, előrejelzésére?
K
Léteznek eljárások a szerződéses szolgáltatások rendelkezésreállásának monitorozására? Létezik eljárás a szolgáltatások hibatűrésének javítására? Léteznek eljárások az adatok mentésének visszaállításának kezelésére? Léteznek eljárások az informatikaszolgáltatás biztonságának kezelésére? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 4 Belső integráltság A szolgáltatási szintek részletes rendelkezésreállási követelményeit felülvizsgálják, továbbá rögzítik és használják a rendelkezésreállás tervezetben?
Igen
Nem K
A rendelkezésreállás adatokat felhasználják az rendelkezésreállási szintek előrejelzések, trendek elkészítéséhez?
133
A rendelkezésreállási szint javítása érdekében végrehajtott változásokat alátámasztják a trendekkel, előrejelzésekkel? Minden új vagy módosított konfigurációs elem úgy van tervezve és tesztelve, hogy a rendelkezésreállás kritériumoknak eleget tegyen? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 5 Teljesítmény
Igen
Nem
A rendelkezésreállásról készülnek rendszeres időközönként előre definiált riportok?
K
Létezik rendelkezésreállás terv, és azt rendszeresen felülvizsgálják? A rendelkezésreállás javítását célzó változtatásokat formális változás kérésként kezelik? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 6 Minőségellenőrzés
Igen
Nem
A rendelkezésreállás menedzsment tevékenységekre léteznek-e szabványos eljárások vagy egyéb minőségi kritériumok?
K
A rendelkezésreállás menedzsment személyzete megfelelően ki van képezve?
K
Meg vannak-e határozva és átvizsgálják-e a rendelkezésreállás menedzsment céljait? Használatban van-e bármely olyan eszköz, amellyel a rendelkezésreállás menedzsment folyamatot támogatni lehet? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 7 Vezetői információk
Igen
Nem
Előállnak-e az alábbi menedzsment információk? •
Szolgáltatás rendelkezésreállásról és komponens hibákról
K
•
Javaslatokról és a rendelkezésreállás javítása érdekében javasolt változtatásokról
K
•
Szolgáltatások működési szintjeinek komponensektől való függése
•
Megelőző intézkedések kiértékelése
•
informatikaszolgáltatás rendelkezésreállási terve
•
Változtatások felmérése
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 8 Külső integráltság
Igen
Nem
Tartanak rendszeres megbeszéléseket az érintett szereplőkkel a rendelkezésreállás menedzsment ügyeinek megbeszélésére?
K
Van-e információ csere a problémakezeléssel a következőkről? •
informatikaszolgáltatás kiesése
K
•
Szolgáltatás kiesését okozó konfigurációs elemek
K
•
Szükséges változtatások, probléma megelőző karbantartás
K
Van-e információ csere a kapacitásmenedzsmenttel a következőről? •
K
Rendelkezésreállási terv figyelembe veszi a rendszer használatának trendjeit.
Van-e információ csere a változáskezeléssel a következőkről? •
Javasolt változások felmérése
•
informatikaszolgáltatás rendelkezésreállásának javítása érdekében szükséges változtatások
Van-e információ csere az ügyfélszolgálattal a következőkről? •
Alacsony szintű rendelkezésreállás miatt bejelentett végfelhasználói panaszok
Van-e információ csere a konfigurációkezeléssel a következőkről? •
A konfigurációs elemek adatairól, meghibásodások között letelt időtartamról (MTBF)
A rendelkezésreállás menedzsment és a fejlesztés között van információ csere annak érdekében, hogy a fejlesztés alatt figyelembe vegyék a rendelkezésreállás szempontokat? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 9 Ügyfél elégedettség
Igen
Nem
Végez ellenőrzést az ügyféllel arról, hogy a rendelkezésreállás menedzsment tevékenységek megfelelően támogatják-e az üzleti igényeiket?
K
Ellenőrzik, hogy az ügyfelei elégedettek-e a nyújtott szolgáltatásokkal?
K
Folyamatosan ellenőrzik, hogy az ügyfél elégedettség milyen trendet követ?
K
Az ügyfél megelégedettségi felmérések eredményét felhasználják-e a szolgáltatás-javítási tervben?
K
Mérik a szolgáltatások ügyfelek által érzékelt értékét?
K
134
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre
A.10. Pénzügyi menedzsment 1 Előfeltételek
Igen
Nem
Legalább néhány pénzügyi menedzsment tevékenység létezik a szervezeten belül, pl. költség-előrejelzés, a szolgáltatások költségének menedzselése?
K
Pénzügyi menedzsment feladataival erre kijelölt személyek foglalkoznak vagy külön funkcionális területet jelent? A szolgáltatások biztosítása témakörökre létezik költségvetés? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 2 Üzleti-stratégiai irányítás
Igen
Nem
A pénzügyi menedzsment célját, előnyeit megismerték a szervezeten belül?
K
Meg van határozva a pénzügyi menedzsment tevékenység terjedelme? Az informatikaszolgáltatás kiadásaival és számlázásával kapcsolatos pénzügyi menedzsment célok világosak? Létrejött megállapodás az informatikai költségek számítására és regisztrálására? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 3 Képesség
Igen
Nem
Ki vannak jelölve felelősségi körök a pénzügyi menedzsment tevékenységeinek végrehajtására?
K
Van-e eljárás a kiadások tervezésére?
K
Van-e eljárás az eszközök, szolgáltatások beszerzésére? Van-e megfelelő eljárás a jelentkező költségek követésére? Meg van-e határozva, milyen időközönként kell a kiadásokról riportokat generálni?
K
Van-e előrejelzés az erőforrások és szolgáltatások egység költségeire vonatkozóan? Meg van-e határozva a számlázási eljárás? Létezik-e eljárás a költségek fedezésére? Létezik-e eljárás a szolgáltatások árának meghatározására? Létezik-e eljárás a bevételi riportok készítésére? Létezik-e eljárás a bevételek és a kiadások összevetésére? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 3 “igen” más kérdésre 4 Belső integráltság
Igen
Nem
A pénzügyi menedzsment felelős az informatikai kiadásokról és bevételekről készült riportok teljességéért?
K
A számlázási adatok, ha ilyen létezik, a jelenlegi költség információk alapján készültek? A használt költség besorolás és regisztráció összhangban van az előre definiált struktúrával? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 5 Teljesítmény
Igen
Nem
A kiadásokról és bevételekről készülnek rendszeres időközönként előre definiált riportok?
K
Végez számlázást a felhasználók felé a költség központok és költségfedezeti struktúra alapján? Végez formális költségvetést az ügyfelei számára? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 6 Minőségellenőrzés
Igen
Nem
A pénzügyi menedzsmentre léteznek-e szabványos eljárások vagy egyéb minőségi kritériumok?
K
A pénzügyi menedzsment személyzete megfelelően ki van képezve?
K
Meg vannak-e határozva és átvizsgálják-e a pénzügyi menedzsment céljait? Használatban van-e bármely olyan eszköz, amellyel a pénzügyi menedzsment folyamatot támogatni lehet? Minimális pontszám:
“igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre
7 Vezetői információk
Igen
Nem
Előállnak-e az alábbi menedzsment információk? •
informatikaszolgáltatás biztosításának költségelőrejelzéséről
K
•
Erőforrások, szolgáltatások biztosításának tényleges költségei összehasonlítva a tervezett költségekkel
K
•
Költségek fedezésének pénzügyi céljáról
135
•
Erőforrások következő évre szükséges biztosításáról vagy bérbe/eladásáról előrejelzés
•
Bevételekről erőforrásonként, szolgáltatásonként, ügyfelenként a tervezett bevételhez viszonyítva
•
Szolgáltatások költségének kezeléséről a tervezett pénzügyi célokhoz viszonyítva
•
A pénzügyi célok eléréséhez szükséges tennivalókról
•
Tervektől való eltérés analíziséről
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 8 Külső integráltság
Igen
Nem
Tartanak rendszeres megbeszéléseket az érintett szereplőkkel a pénzügyi menedzsment ügyeinek megbeszélésére?
K
Van-e információ csere a kapacitásmenedzsmenttel a következőkről? •
Árképzési politika meghatározása
K
•
Egység költségek előrejelzése
K
•
Költségfedezet tervezése
K
•
Szolgáltatások változásának meghatározása
K
Van-e információ csere a változáskezeléssel a következőről? •
Szolgáltatások költségeinek kezeléséről (szolgáltatási szintek áttekintése, erőforrásokért számolt árak)
Van-e információ csere a konfigurációkezeléssel a következőkről? •
Beszerzett tételekkel kapcsolatban
•
Egység költségek előrejelzéséről
•
Felmerülő költségek rögzítéséről
Van-e információ csere a szolgáltatási szint menedzsmenttel a következőkről? •
Szolgáltatási szint megállapodások információinak felmérése a szolgáltatások változásának meghatározására
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 9 Ügyfél elégedettség
Igen
Nem
Végez ellenőrzést az ügyféllel arról, hogy a pénzügyi menedzsment tevékenységei megfelelően támogatják-e az üzleti igényeiket?
K
Ellenőrzik, hogy az ügyfelei elégedettek-e a nyújtott szolgáltatásokkal?
K
Folyamatosan ellenőrzik, hogy az ügyfél elégedettség milyen trendet követ?
K
Az ügyfél megelégedettségi felmérések eredményét felhasználják-e a szolgáltatás-javítási tervben?
K
Mérik a szolgáltatások ügyfelek által érzékelt értékét?
K
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre
A.11. Kapacitás menedzsment 1 Előfeltételek
Igen
Nem
Legalább néhány Kapacitás menedzsment tevékenység létezik a szervezeten belül, pl. erőforrás-használat, teljesítmény monitorozása, kapacitástervezés, szolgáltatás elemek méretezése?
K
A Kapacitás menedzsment feladataival erre kijelölt személyek foglalkoznak vagy külön funkcionális területet jelent? A kulcsfontosságú szolgáltatások jellemzői azonosítva vannak, pl. sávszélesség, processzor-terhelés, áteresztőképesség, tárterület? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 2 Üzleti-stratégiai irányítás
Igen
Nem
A kapacitás menedzsment célját, előnyeit megismerték a szervezeten belül?
K
A kapacitás menedzsment tevékenységeinek terjedelme meg van határozva a szervezeten belül? A szervezet elkötelezett a szolgáltatások teljesítményének mérésére? A szervezet elkötelezett a kapacitás terv létrehozására? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 3 Képesség
Igen
Nem
Ki vannak jelölve felelősségi körök a Kapacitás menedzsment tevékenységeinek végrehajtására?
K
Léteznek eljárások a rendszerhasználat analízisére, a teljesítmény-beszámolók készítésére?
K
Az új szolgáltatásokhoz szükséges szolgáltatás elemeket definiálják és méretezik?
K
A szolgáltatások teljesítményének tényleges szintjét rögzítik? A jövőben jelentkező igényeket előrejelzik a jelenlegi terhelés adatok alapján?
136
Modellezik a rendszer viselkedését különböző terhelés alapján? Készítenek kapacitás tervet a vállalat számára? Figyelemmel követik a megjelenő új technológiákat? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 4 Belső integráltság
Igen
Nem
Létezik kapacitás menedzsment adatbázis?
K
Az erőforrás-használat optimalizálása céljából analizálják a használat és teljesítmény adatokat? Az előírt szolgáltatási szinteket és előrejelzéseket felhasználják a szolgáltatás elemek definiálásához és méretezéséhez? Felmérik a tervezett erőforrás használattól való eltéréseket, trendeket? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 5 Teljesítmény
Igen
Nem
Karbantartják a kapacitás tervet?
K
Léteznek rendszeresen előállított szabványos riportok a teljesítménnyel kapcsolatban? Léteznek rendszeresen előállított szabványos riportok a kulcsfontosságú erőforrások használatáról, biztosításáról? Készítenek előrejelzéseket új munkamennyiségekre és azok erőforrásigényeire? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 6 Minőségellenőrzés
Igen
Nem
A kapacitás menedzsment folyamataira léteznek-e szabványos eljárások vagy egyéb minőségi kritériumok?
K
A kapacitás menedzsment feladataiért felelős személyzet megfelelően ki van képezve?
K
Meg vannak-e határozva és átvizsgálják-e a Kapacitás menedzsment céljait? Használatban van-e bármely olyan eszköz, amellyel a kapacitás menedzsment folyamatot támogatni lehet? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 1 “igen” más kérdésre 7 Vezetői információk
Igen
Nem
Előállnak-e az alábbi menedzsment információk? •
Erőforrás használatokról
K
•
Szolgáltatási szintek biztosításához szükséges infrastruktúra követelmények
K
•
Teljesítmény trendek
•
Kiszámlázható erőforrás használatokról
•
Új munkamennyiségekről részletek
•
Javaslatokról, amelyek technológiai trendek, új technológiák alapján készültek
•
Tervezett és tényleges kapacitás használat eltéréséről
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 8 Külső integráltság
Igen
Nem
Tartanak rendszeres megbeszéléseket az érintett szereplőkkel a kapacitás menedzsment ügyeinek megbeszélésére?
K
Van-e információ csere a szolgáltatási szint menedzsmenttel a következőkről? •
Szolgáltatások és munkamennyiségek monitorozása
K
•
Új munkamennyiségek számára javasolt szolgáltatási szintek
K
Van-e információ csere a pénzügyi menedzsmenttel a számlázható költség használatról? Van-e információ csere a konfigurációkezeléssel a következőkről? •
informatikai komponensek és munkaterhelések bevezetésének részletei
•
Változtatások hatásainak részletei a létező munkaterhelésekre és a teljesítmény hatáselemzés eredményének felhasználása
Van-e információ csere a rendszerfejlesztéssel? Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre + 2 “igen” más kérdésre 9 Ügyfél elégedettség
Igen
Nem
Végez ellenőrzést az ügyféllel arról, hogy a Kapacitás menedzsment tevékenységei megfelelően támogatják-e az üzleti igényeiket?
K
Ellenőrzik, hogy az ügyfelei elégedettek-e a nyújtott szolgáltatásokkal?
K
Folyamatosan ellenőrzik, hogy az ügyfél elégedettség milyen trendet követ?
K
Az ügyfél megelégedettségi felmérések eredményét felhasználják-e a szolgáltatás-javítási tervben?
K
137
Mérik a szolgáltatások ügyfelek által érzékelt értékét?
K
Minimális pontszám: “igen” minden kötelező (‘K’) kérdésre
138
B. függelék: ITIL terminológia definiciók
A tulajdonlás teljes költsége - Total Cost of Ownership Egy eszköz birtoklásának összes pénzügyi következménye, a kezdeti vásárlási áron felül jellemzően idetartozik még a karbantartás, elhelyezési díjak, oktatási költségek, fogyó eszközök, belső és külső támogatás, tőkekamat, stb.
Alapkonfiguráció - Baseline Egy konfigurációs elem vagy egy konfigurációs elem-halmaz egy időpontban, bizonyos okból befagyasztott állapotának pillanatfelvétele. Az alapkonfigurációt gyakran feljegyzik, hogy biztosítsák az infrastruktúra megbízható állapotba való visszaállíthatóságát, ha egy változtatás nem sikerül vagy a konfigurációs elemet újra kell építeni. Egy alapkonfigurációt hoznak létre új konfigurációs elemek kibocsátásakor vagy katasztrófa-visszaállítási helyzetben való használathoz. Habár egy állapot, mint amilyet egy projekttervben leírnak, frissítésre kerülhet később, az alapkonfiguráció változatlan marad és hozzáférhető az eredeti állapot referenciájaként és a jelenlegi állapottal való összehasonlításra.
Alapváltozat - Baseline Lásd az alapkonfigurációt.
Alapváltozat összeállítása - Baselining Az a folyamat, amellyel egy szolgáltatás minősége és költséghatékonysága felmérhető, rendszerint a szolgáltatás megváltoztatása előtt. Az alapváltozat összeállítása tartalmazza a szolgáltatás összehasonlítását a változtatás előtt és után vagy a trendinformációk elemzését. Ha az összehasonlítást más vállalkozásokkal szemben végzik, az összemérés kifejezést használják.
Alkalmazászolgáltató - Application Service Provider Olyan szervezet, amely saját telephelyein, saját szerverein ad otthont szoftveralkalmazásoknak. Az ügyfelek az alkalmazásokat közvetlen összeköttetésen vagy az Interneten keresztül érik el. kereskedelmi szolgáltatónak is hívják.
Állásidő - Downtime Az a teljes időtartam, amely alatt egy szolgáltatás vagy komponens nem működik a megállapodott szolgáltatási időn belül. A szolgáltatás vagy komponens meghibásodásától a normális működés újraindulásáig mérik.
Általános költségek - Overheads A közvetett anyagok, fizetések és költségek összege.
Átadott költség - Transfer Cost Az átadott költségek egy szervezet egyik részétől a másiknak “eladott” termékek és szolgáltatások költségeit jelentik, gyakran egy munltinacionális vagy más nagy szervezetet belül, amelynek bonyolult belső könyvelési rendszere van. Az átadott költségeknek láthatóknak kell lenniük a költségmodellekben, ha a szolgáltatások nyújtásának igazi költségét ki akarjuk számolni.
139
Átvizsgálás - Audit A vizsgálat, korrekció és felülvizsgálat folyamata. A nyilvánvaló könyvelési alkalmazásukon kívül az átvizsgálásokat egy tevékenység vagy folyamat gazdaságosságának, hatékonyságának és jogosságának ellenőrzésére használják, illetve, hogy megerősítsék (vagy nem), miszerint egy tevékenységet az általános szabványoknak vagy az elismert legjobb gyakorlatnak megfelelően végeznek. Ebben az értelemben az átvizsgálás inkább ajánl, és nem megvalósít javító tevékenységeket. (Lásd még a megfelelőségi vizsgálatot.)
Az egész világra kiterjedő támogatás - Follow the Sun Support Olyan ügyfélszolgálat, amely 24 órás támogatást nyújt különböző országokban elhelyezett ügyfélszolgálatokkal. A hívásokat az egyiknél rögzítik, és amikor ez az iroda bezár, a következőnek továbbadja, vagy az átveszi.
Az üzletvitel-helyreállítási terv életbeléptetése - Invocation of Bussiness Recovery Plans Az üzletvitel-helyreállítási tervek működtetése egy üzletmegállást követően.
Azonnali helyreállítás - Immediate Recovery Betű szerinti jelentésében ez az informatikaszolgáltatás-folytonossági alternatíva biztosítja a szolgáltatások azonnali helyreállítását vészhelyzet esetén. A szolgáltatások azonnali elérhetősége megkülönbözteti ezt a megoldást attól, amit melegtartaléknak hívnak, ami jellemzően 2-24 órán belül engedi a szolgáltatások helyreállítását attól függően, hogy mennyire kritikus az általa támogatott üzleti folyamat. Ezen üzleti kritikusságtól függően az “azonnali” helyreállítás így nullától 24 óráig változhat. (vö. Fokozatos helyreállítás, Közbenső helyreállítás.)
Befektetés megtérülése - Return on Investment A potenciális pénzügyi nyereség a nyereség megtermeléséhez felhasznált költségek hányadosaként kifejezve.
Belső cél - Internal Target Az egyik mérték, amellyel az informatikaszolgáltatást támogató folyamatokat összehasonlítják. Rendszerint műszaki kifejezésekkel adják meg, amelyek közvetlenül kapcsolódnak a mért támogatott szolgáltatáshoz.
Belső intézkedés - Internal Measure Lásd a belső célt.
Belső specifikációs lap - Internal Specsheet Az a munkadokumentum, amely lehetővé teszi a szolgáltatási szint menedzsment funkció számára, hogy részletezze, mit kell tennie az informatikai osztálynak és beszállítóinak egy vevő számára történő szolgáltatás nyújtásához.
Belső szolgáltatáshoz kötött felhasználók - Tied Users Azok a felhasználók, akiknek nincs választásuk, hogy használják-e a belső informatikai osztály szolgáltatásait vagy nem.
140
Belső szolgáltatáshoz nem kötött felhasználók - Untied Users Azok a felhasználók, akik szabadon eldönthetik, hogy az informaikai szolgáltatásokat egy belső informatikai osztálytól szerzik be vagy egy külső szállítótól.
Bevételi költségek - Revenue Cost Lásd a működési költségeket.
Bizalmasság - Confidentiality Az adat védelme a jogtalan használattal szemben.
Csomagkibocsátás -
- Package Release
Szoftver és/vagy hardver kibocsátási egységek egy sorozata, amelyet együtt teszteltek és bocsátanak ki az éles környezetbe.
Deming - W. Edwards Deming “Kifelé a krízisből” című könyvében W. Edwards Deming 14 pontot írt le, amelyek a minőség növelésének alapját képezik. Mivel az informatikai szolgáltatásmenedzsment filozófiája lényegében nem más, mint egy folyamatos javítás, ez a 14 pont érvényes rá és veszélyes bármilyen informatikai szolgáltatásmenedzsment kezdeményezés, amely figyelmen kívül hagyja őket. Ezek tartalmazzák a következőket: •
Állandó szándék a termék és szolgáltatás fejlesztésére.
•
Hagyjunk fel az ellenőrzéstől való függéssel a minőség elérésében és építsük be a minőséget a szolgáltatásba.
•
Jutalmazzuk az üzletet a teljes költség alapján és nem az árcédula alapján.
•
A termelés és szolgáltatás rendszerét folyamatosan és örökké javítsuk, hogy növeljük a minőséget és a termelékenységet és így állandóan csökkentsük a költségeket.
•
Intézményesítsük a munka közbeni oktatást.
•
Intézményesítsük a vezetői képességet. A felügyelet célja az emberek és gépek segítése, hogy jobb munkát végezzenek.
•
Semmisítsük meg az akadályokat az osztályok között. Mindenkinek együtt kell dolgoznia egy csoportban, hogy előre meglássa a gyártási problémákat és azokat, amelyek a termék vagy szolgáltatás használata során következhetnek be.
•
Intézményesítsük a nyomatékos oktatási programot és az önművelést.
•
Mindenkit dolgoztassunk a szervezetben az átalakítás végrehajtásáért. Az átalakítás mindenki dolga.
Diagnosztikai forgatókönyv - Diagnostic Script
141
Az ügyfélszolgálat által használt strukturált kérdéssor, amely lehetővé teszi az Incidensek gyorsabb elhárítását és/vagy pontosabb kiosztását. A diagnosztikai forgatókönyveket gyakran a műszaki személyzet készíti és tartja karban, mint az incidenskezelési folyamatbeli kötelezettségük egyikét.
Differenciális költségterhelés - Differential Charging Olyan költségterhelési politika, amelynek célja vagy az igény csökkentése egy szűkös vagy drága erőforrás esetében vagy a tartalékkapacitás használatának ösztönzése.
Egypontos hiba - Single Point of Failure Egy komponens, amelynek nincs biztonsági másolata, és jelentős hatással lehet az üzletre, ha meghibásodik.
Egypontos kapcsolat - Single Point of Contact Amikor az összes napi kommunikációt egyetlen helyen irányítják keresztül. Az informatikaszolgáltatásnál ez jellemzően az ügyfélszolgálat lesz. Ez biztosítja, hogy a felhasználók betanított személyzettel léphetnek kapcsolatba, minden kontaktust következetesen jegyeznek fel, a szakértő személyzet képes félbeszakítás nélkül a munkájára koncentrálni és a munkát összehangolják és az esetekkel egyszer foglalkoznak.
Életbeléptetés - Invocation Az informatikaszolgáltatás-folytonosság helyreállítási folyamat elindítása.
menedzsment
szóhasználatában
a
katasztrófa-
Életbeléptetési és helyreállítási fázis - Invocation and Recovery Phase Az üzletvitel-helyreállítási terv második fázisa.
Ellenállóképesség - Resilience Egy sorozat konfigurációs elem (KE) azon képessége, hogy folytatják a megkívánt szolgáltatás nyújtását, ha nem azonnal, akkor nagyon gyorsan, amikor a sorozatból néhány KE meghibásodik.
Ellenőrzött hardverraktár - Definitive Hardwer Store Az a hely vagy helyek, ahol azokat a hardvertartalékokat tárolják biztonságban, amelyeket az éles környezetben lévő azonos hardver konfigurációs elemekkel egy szinten kezelnek. Csak az engedélyezett hardvert lehet befogadni az ellenőrzött hardverraktárba, amelyet a változásmenedzsment és a kiadásmenedzsment szigorúan felügyel.
Ellenőrzött szoftverkönyvtár - Definitive Software Library Az a fizikai könyvtár, ahol az összes szoftver konfigurációs elem (KE) összes minőségellenőrzött verziója teljes formájában van, együtt minden társuló KE-mel mint például a licenc és más dokumentáció. Ez az egy logikai tároló-hely a valóságban egy vagy több fizikai szoftverkönyvtárból vagy irattárolóból állhat. El kell különíteni őket a fejlesztői és tesztelési tároló-helyektől. Csak az engedélyezett szoftvert lehet befogadni az ellenőrzött szoftverraktárba, amelyet a változásmenedzsment és a kiadásmenedzsment szigorúan felügyel.
142
Előírt szolgáltatási idő - Agreed Service Time Az az időszak, amely alatt egy bizonyos informatikaszolgáltatás a szerződés szerint teljes mértékben elérhető, ideális esetben úgy, ahogyan azt a szolgáltatási megállapodásban meghatározták. Az előírt szolgáltatási idő alatt a szolgáltatás szintjei változhatnak, például az ügyfélszolgálat nem feltétlenül végig elérhető abban az időszakban, amikor a felhasználók a szolgáltatásokat igénybe veszik.
Elsőre megjavított esetek aránya - First Time Fix Rate Általánosan használt mérőszám, amely megadja a felhasználó és az ügyfélszolgálat első kapcsolatfelvételekor késedelem vagy továbbadás nélkül megoldott incidensek arányát.
Elsőszintű támogatás - First Level Support Az ügyfélszolgálaton belüli azon műszaki és vezetői erőforrások, amelyek a vevővel/felhasználóval történő első kapcsolatfelvételkor elérhetőek.
Eltérés - Variance A tervezett, költségvetésben meghatározott vagy szokásos költség és a tényleges költség (vagy jövedelem) közti különbség. Az eltéréselemzés azon tényezők elemzése, amelyek az előre elhatározott mértékek és a tényleges eredmények közti különbséget okozták.
Érdekeltek - Stakeholders Mindazok, akiknek érdekeltségük van egy szervezetben, tevékenységeiben és eredményeiben. Ezek között lehetnek vevők, partnerek, alkalmazottak, részvényesek, a kormányzat és felügyeleti szervek.
Eredményeség - Effectiveness Az eredményesség vagy költséghatásosság az egyik mérce a költségarányos érték megállapításában. Magában foglalja egy tevékenység kimeneteinek költségét és e kimenetek megfelelőségét egy specifikációnak vagy igénynek. A tipikus mércék a pénz, idő, emberek és minőség. Bármilyen befektetésnek, amely növeli az informatikaszolgáltatás nyújtásának költségét, a szolgáltatás minőségének vagy mennyiségének növelését kellene eredményeznie. Ha ez nem így van, a gazdaságossági elemzésnek világosan meg kell indokolni, hogy miért szükséges a változtatás.
Érettségi szint - Maturity Level Egy azonosítható fok, a folyamat jellemzőinek nyelvén kifejezve, az érett folyamat eléréséhez vezető úton.
Eszkaláció - Escalation Egy incidensről, problémáról vagy változtatásról szóló információ továbbadása és/vagy intézkedés kérése a rangidős személyzettől (hierarchikus eszkaláció) vagy más szakértőtől (funkcionális eszkaláció). Pontosan le kell írni azokat a körülményeket, amelyek során vagy vertikális eszkaláció történik információért vagy felhatalmazásért a további erőforrások bevonására, vagy horizontális eszkaláció a nagyobb funkcionális bevonásért, hogy az eszkaláció célja és a kívánt válasz természete teljesen világos legyen mindenki számára az eszkaláció folyamán. Az eszkalációs szabályokat a prioritási célokhoz kapcsolják.
143
Eszköz - Asset Betű szerinti jelentése tulajdonolt értékes személy vagy tárgy; az eszközök gyakran megjelennek a mérlegben, mint a szervezet kötelezettségeivel szembeállított tételek. Az informatikaszolgáltatás folytonosságának biztosításában és a biztonsági átvizsgálásban és menedzsmentben az eszközt olyan tételnek tekintik, amellyel kapcsolatban fenyegetések és sebezhetőségek azonosíthatók és számolhatók kockázatelemzés elkészítésének céljából. Ebben az értelemben a szolgáltatások alátámasztásában az eszköz fontossága számít és nem a költsége.
Eszköznyilvántartás - Asset Register Lásd a tárgyieszköz-gazdálkodást.
Észlelés - Detection Az incidens életciklusának második állomása az Előfordulás után, amikor a szolgáltatás hibája ismertté válik az informatikai szolgáltató szervezet számára.
Fájdalomfaktor - Pain Factor Néha Fájdalomértéknek is hívják, egy bizonyos incidens vagy probléma (rendszerint ismétlődő) típus hatása együtt a bekövetkezési gyakoriságával és azzal, hogy mibe kerülne kijavítani szemben a vele való együttéléssel.
Fokozatos helyreállítás - Gradual Recovery Ez az Informatikaszolgáltatás-folytonossági megoldás rendelkezik az informatikaszolgáltatás helyreállításáról azon üzleti folyamatok támogatásában, amelyek 72 vagy több órán át képesek a teljes informatikai támogatásuk nélkül is működni. Néha “hidegtartaléknak/hidegindításnak” is hívják és jellemzően olyan üres (hordozható vagy fix) elhelyezési lehetőséget jelent, amely rendelkezik áramellátással, környezeti szabályozással, helyi hálózati kábelezéssel és telekommunkiációs csatlakozásokkal. A szükséges hardvert és szoftvert ezen felül még telepíteni kell. (vö. azonnali helyreállítás, közbenső helyreállítás.)
Forgatókönyv - Script Lásd a Diagnosztikai forgatókönyvet.
Fő teljesítményjelző - Key Performance Indicator Az az érték (kvantitatív vagy kvalitatív), amely lehetővé teszi egy szolgáltatás teljes nyújtásának felmérését mind az üzlet mind az informatika képviselői által. A fő teljesítményjelzők száma célszerűen alacsony és a szolgáltatás üzleti sikerhez nyújtott potenciális hozzájárulására összpontosít. Azért, hogy hatásosak legyenek az üzleti teljesítmény javításában, a stratégiai tervhez kell kötni őket, amely részletezi, hogy hogyan szándékszik az üzlet elképzelését és küldetését teljesíteni. A választott mértékeknek a teljesítmény eredmények minden szempontjával foglalkozniuk kell, le kell írniuk a megcélzott teljesítményt mérhető kifejezésekkel, és arra a vállalati szintre kell tenni őket, amely rendelkezik a beavatkozáshoz szükséges jogkörrel, erőforrásokkal és tudással.
Függőség - Dependency Egy folyamat vagy tevékenység másiktól való közvetlen vagy közvetett függősége.
144
Gyors siker - Quick Win Talán a szolgáltatásjavítási program kezdeti szakaszaiban alkalmazott Pareto elvről ismerhető fel, a gyors siker a tényleges vagy érzékelt szolgáltatási minőség javulását írja le, amit rövid idő alatt és viszonylag kis erőfeszítéssel érnek el. A legfontosabb hozzájárulás a gyors sikerhez valószínűleg a közös vágy megérteni a szolgáltatás minőségi hiányának eredeti okát és kezdeményezni a kijavító változtatást.
Hagyományos irodai biztonsági másolat - Clerical Backup Vészhelyzet esetén a megkívánt szolgáltatások egy részének nyújtása az informatikai infrastruktúra nélkül. Manapság néhány kézi folyamat mellett ezt valószínűleg önálló számítógépeken végzik, kereskedelmi irodai alkalmazásokkal.
Hatásbekövetkezési forgatókönyv - Impact Scenario Olyan informatikaszolgáltatás-folytonosság menedzsment kifejezés, amely leírja, hogy a szolgáltatás leállása milyen hatással van az üzletre. Rendszerint egy üzleti folyamathoz kapcsolják, és mindig egy időtartamra vonatkozik, például a vevői szolgáltatások nem fognak működni két napig.
Hatáselemzés - Impact Analysis A kritikus üzleti folyamatok és a megszakadásuk által vagy egy javasolt változtatás által a szervezetnek okozott potenciális kár vagy veszteség azonosítása. Az üzleti hatáselemzés azonosítja a kár vagy veszteség formáját; hogyan fog a kár vagy veszteség mértéke valószínűsíthetően növekedni az időben egy incidenst követően, a minimális személyzet, felszerelés és szolgáltatások, amelyek ahhoz szükségesek, hogy az üzleti folyamatok továbbműködhessenek egy elfogadható minimális szinten, és az az idő, amelyen belül helyre kell állítani őket. Azt az időt is megállapítják, amelyen belül az üzleti folyamatok teljes helyreállítást el kell érni.
Hatáskód - Impact Code Egy egyszerű kód, amelyet incidenshez, problémához és változtatáshoz rendelnek olymódon, hogy az tükrözze az ügyfelek üzleti tevékenységeire gyakorolt tényleges vagy potenciális hatásának mértékét. Hasonlóan a szokásos felhasználói szolgáltatási szintek csökkenésének mértékét. A hatáskód nem szükségszerűen rögzített, hanem változhat, hogy tükrözze a megváltozó körülményeket.
Hatékonyság - Efficiency A Hatékonyság az egyik mérce a költségarányos érték megállapításában. Magában foglalja a a bemenetek (gazdaságosság) és a kimentek (eredményesség) hányadosát. A tipikus mércék a pénz, idő, emberek és minőség. (vö. Gazdaságosság, Eredményesség, Költségarányos érték.)
Hatókör - Scope Általánosan az a kiterjedés, amelyre egy folyamat vagy eljárás érvényes. A konfigurációkezelés hatóköre például nem terjedhet ki a felhasználó értesítésére (eltekintve az “ahogyan tájékoztatták” módtól) és egy változáskezelési eljárás hatóköre nem feltétlenül érvényes a “Sürgős változások”-ra. A kiszervezés egyik kulcsgondolata annak meghatározása, hogy milyen tevékenységeket fed le az alapszerződés és melyek a külön számlázandók.
145
Háttérszervezet - Back-office/Back-end Azok az üzleti folyamatok és működési funkciók, amelyek belül vagy az ellátási láncban zajlanak. Ezek gyakran tartalmazzák a leltárkezelést, a beszerzést és elosztást, valamint a megrendelések feldolgozását, követését, szállítását és fogadását.
Háttérszerződés - Underpinning Contract Egy külső szállítóval kötött szerződés, amely olyan termékek és/vagy szolgáltatások szállítását tartalmazza, amelyek hozzájárulnak az ügyfeleknek nyújtott informatikaszolgáltatáshoz. A háttérszerződés kikötéseinek és fizetési feltételeinek tükrözniük kell, és tükröződniük kell a megfelelő szolgáltatási szint szerződésben.
Helyreállítás - Recovery A meghibásodást és a javítást követően a meghibásodott konfigurációs elemeket visszaállítják az éles infrastruktúrába. Ez tartalmazhatja az adatok helyreállítását az utolsó ismert, helyreállítható állapotba. Még maradhatnak további lépések mielőtt a felhasználók számára helyreállítanák a szolgáltatást, például a tesztelés, a tranzakciók újrafuttatása és a felhasználók értesítése. A Helyreállítás az incidens életciklusának utolsó előtti fázisa.
Megtérülési költség - Recovery Cost Amikor egy informatikai egység elemzi teljes kiadását és beruházásait, hogy teljesen visszakaphassa az ügyfelektől, rendszerint formális költségterheléssel de haszon nélkül.
Hiba - Fault Az a feltétel, amely előidézi egy funkcionális egység képtelenségét a megkívánt funkció ellátására.
Hibafelügyelet - Error Control A hibafelügyelet, mint a problémamenedzsment egy feladata felöleli az ismert hibák azonosítását, feljegyzését, osztályba sorolását és haladását. A hibafelügyelet kiterjed a változások előmozdítására és a megoldási fázis befejezésére, vagyis a módosított vagy kicserélt konfigurációs elem sikeres megvalósításának visszaigazolására, amely a kapcsolt probléma és Ismert hiba feljegyzéseinek lezárásához vezet.
Hibajegy - Trouble Ticket Számos szolgáltatástámogatási eszközben használt kifejezés, amely hasonlít, de rendszerint nem közvetlenül egyezik meg a precízebb, az Informatikai infrastruktúra könyvtár (ITIL) által használt incidenssel és problémával.
Hibatűrés - Fault Tolerance A szolgáltatás azon képessége, hogy folytatódik, amikor egy meghibásodás bekövetkezik. (vö. ellenállóképesség.)
146
Hidegtartalék helyszíne (hordozható vagy helyhezkötött) (portable or fixed)
-
Cold Standby Site
Egy üres számítógépszoba, vagy mozgatható vagy helyhezkötött elhelyezéssel, tápfeszültséggel, környezetszabályozással és telekommunikációval ellátva de informatikai eszközök és szoftverek nélkül, katasztrófa esetén történő használatra (vö. fokozatos helyreállítás.)
Hivatkozási alap - Terms of Reference Egy tevékenység vagy igény hatókörét és célját rendszerint leíró dokumentum.
Igénykezelés - Demand Management Befolyásolja az informatikai kapacitás használatát, talán ösztönzés vagy büntetés révén, olyan körülmények között, amikor a kezeletlen igény valószínűleg meghaladja a szolgáltatásnyujtási képességet. Az igénykezelést az erőforrások prioritások szerinti kiadásával érik el.
Incidens - Incident A szolgáltatás szokásos működésének részét nem képező esemény, amely a szolgáltatások minőségében és a vevő termelékenységében csökkenést vagy szakadást okoz vagy okozhat. Az incidens egy probléma azonosításához vagy kivizsgálásához vezethet de soha sem válik problémává. Még akkor is incidens marad ha átadják a problémamenedzsment folyamatnak második vonalbeli incidensfelügyeletre. A problémamenedzsment azonban menedzselheti együtt az incidens és a probléma megoldását, például ha az incidens csak a probléma megoldásával zárható le.
Incidensfelügyelet - Incident Control Az incidensek azonosításának, feljegyzésének, osztályozásának és haladásának folyamata addig, amíg az érintett szolgáltatást helyre nem állítják. Az incidensek azonosításához szükséges adatok gyűjtése az incidensfelügyelet másodlagos célja, habár ez néha az incidens megoldásának elvégzéséhez is kellhet. Az incidensfelügyelet alapvetően az incidensmenedzsment feladata, és így az ügyfélszolgálaté, bár esetenként túlléphet ezen csoport meghatározott szerepén és hatáskörén és más személyzet második vonalbeli támogatását igényelheti, esetleg a problémamenedzsmentét. A pontos körülményeknek, amelyek esetén ez megtörténik egy incidensmenedzsment eljárásban kellene leírva lenniük.
Incidensfelügyeleti támogatás - Incident Control Support Ez alkalmi feladat, talán a promlémamenedzsment csoport vállalja magára. Vannak olyan esetek, amikor incidens történt és nyilvánvalóvá válik, hogy az ügyfélszolgálat (mind az első, mind a második vonalbeli) további idő- és erőforrás-befektetése valószínűleg hatással lesz elsődleges kötelezettségükre, az ügyfeleknek válaszolásra és a szolgáltatások mielőbbi helyreállítására. Ezek azok a helyzetek, amelyek részletes kivizsgálást és diagnózist kívánnak, igénylik a műszaki támogató csoport(ok) koordinációját, vagy amelyek elvégzik az ügyfélszolgálat erőforrásainak átirányítását máshová (pl. más incidensekhez). Egy másik csoportot, például a problémamenedzsmentet kérhetik meg ilyen esetekben az incidens operatív előrehaladásának menedzselésére. Az ügyfélszolgálat mindemellett megtartja átfogó felelősségét az incidens életciklusának menedzselésére. Egy ilyen incidenst az incidensmenedzsment az incidensmenedzsment eljárásoknak megfelelően utalna az incidensfelügyeleti támogatási csoporthoz.
147
Incidenskezelés - Incident Management Lásd incidensmenedzsment.
Incidensmenedzsment - Incident Management A váratlan működésbeli események menedzselésének szolgáltatásmenedzsment folyamata azzal az elsődleges céllal, hogy a szolgáltatást helyreállítsák az ügyfelek számára, amilyen gyorsan csak lehet.
Informatikai infrastruktúra könyvtár - IT Infrastructure Library Az angol OGC (korábban CCTA) által elkészített kötetek gyűjteménye, amelyek leírják az Informatikai szolgáltatásmenedzsment legjobb gyakorlatait. A könyvár célja a szervezetek segítése a minőségi informatikaszolgáltatás nyújtásában olyan körülmények között, mint a költségvetési korlátok, szakértelembeli hiányok, a rendszer komplexitása, gyors változás, jelenlegi és jövőbeli felhasználói igények és növekvő felhasználói elvárások. Eredetileg a nyolcvanas évek végén kilencvenes évek elején készítették több mint negyven kötetes sorozatként, a könyvár legutolsó kiadásának magja hat könyv: •
a Szolgáltatástámogatás és Szolgáltatásbiztosítás tanácsot ad, hogy hogyan irányítsuk az informatikai szolgáltatásmenedzsment fő folyamatait;
•
a Szolgáltatásmenedzsment bevezetésének tervezése elmagyarázza azokat a lépéseket, amelyek szükségesek annak felismerésére, hogy a szervezet hogyan várhat előnyöket az ITIL-től és hogy hogyan kezdheti learatni ezeket az előnyöket;
•
az ICT infrastruktúramenedzsment lefedi a hálózati szolgáltatások menedzsmentjét, az üzemeltetésmenedzsmentet, számítógép telepítések és átvételek menedzsmentjét és első alkalommal a rendszermenedzsmentet;
•
az Alkalmazásmenedzsment felöleli a szoftverfejlesztési életciklust, kiterjesztve a szoftver életciklus támogatásban és az informatikaszolgáltatás tesztelésében érintett kérdéseket. Az alkalmazásmenedzsment részletezi az üzleti változtatást, hangsúlyt helyezve a követelmények világos meghatározására és a megoldások megvalósítására.
•
végül Az üzleti perspektíva kötet az informatikai szolgáltatásnyújtás természetének teljes megértésével foglalkozik, tartalmazza az üzletvitel-folytonossági menedzsmentet, partnerkapcsolatokat, és kiszervezést, a változtatás túlélését és az üzleti gyakorlat átalakítását radikális változtatáson keresztül. (vö. szolgáltatástámogatás, szolgáltatásnyújtás.)
Informatikai szolgáltatás – IT service Szolgáltatási tevékenység az informatika területén. Tágabb tevékenységkör, mint az informatikaszolgáltatás (lásd ott), mert ezen túlmenően tartalmazza az új informatikai rendszerek létrehozására irányuló szolgáltatásokat (pl. rendszeritegráció, alkalmazásfejlesztés és –integráció, számítógép- és hálózatintegráció), valamint az informatikkai tanácsadás és oktatás tevékenységeit is.
Informatikaszolgáltatás – IT service Létező informatikai rendszerek működtetésének és hozzáférhetőségük biztosításának tevékenységköre. Szűkebb mint az informatikai szolgáltatások tevékenységköre (lásd ott).
148
Informatikaszolgáltatás-folytonosság Management
irányítása
-
IT
Service
Continuity
Lásd informatikaszolgáltatás-folytonosság menedzsmentje.
Informatikaiszolgáltatás-folytonosság menedzsmentje Management
-
IT Service Continuity
Az informatikaszolgáltatás kockázatai felmérésének és menedzselésének folyamata a konfigurációs elemek értékeinek, fenyegetettségének és sebezhetőségének vizsgálatával, megfelelő ellenintézkedések kifejlesztésével, informatikaszolgáltatás-folytonossági terv létrehozásával és bármely bekövetkező katasztrófahelyzet menedzselésével. (vö. üzletfolytonosság-menedzsment.)
Informatikaszolgáltatás pénzügyi irányítása Services
-
Financial Management for IT
Az informatikaszolgáltatás költségvetése készítésének, könyvelésének és számlázásának szolgáltatásmenedzsment folyamata.
Informatikaszolgáltatás pénzügyi menedzsmentje - Financial Management for IT Services Lásd informatikaszolgáltatás pénzügyi irányítása.
Integrációtesztelés - Integration Testing Minden összetevő -beleértve a hardvert és a szoftvert- összerakása, amelyeket egy változtatás érint, úgy, ahogyan az éles környezetben lesznek azért, hogy megbizonyosodjunk együttműködésükről.
Integritás - Integrity Teljesség és épség. Ezek fenntartása megkívánja az adatok védelmét a nem engedélyezett változtatástól. Ugyancsak az adatok konzisztenciája és az adatkapcsolatok egy adatbázisban (hivatkozási integritás).
Ismert hiba - Known Error Egy konfigurációs elem hibája, amelyet egy probléma sikeres diagnózisa ismert fel, és amelyhez egy ideiglenes megkerülő megoldást vagy egy végleges megoldást találtak. Az ismert hiba és a KE kapcsolata eredhet egy probléma helyi diagnózisából, de származhat külső forrásból is. Fontos, hogy minden lényeges ismert hibát rögzítsünk a konfigurációkezelés adatbázisába (CMDB), bár az nyilván nem az ismert hibák adatainak egyetel forrása. Mivel sok problémának több kiváltó oka lehet, az egyes problémák és az egyes ismert hibák közötti kapcsolat esetenként igen komplex. (Jó példa egy ismert hibára, amikor a hibát az adott szoftver következő kiadásában fogják csak kijavítani, addig együtt kell élni vele.)
Jelképes költségterhelés - Notional Charging Módszer, melynek során értesítik a vevőt, hogy a használt szolgáltatás ára mennyi volna, habár tényleges pénz nem cserél gazdát; gyakran a teljes költségterhelés bevezetésének egyik lépéseként használják.
149
Jellemző - Attribute Egy konfigurációs elem leíró jellemzői, mint például a gyártmány-/modellszám, verziószám, szállító, vásárlási szerződés száma, kibocsátási szám, adatformátum, szerep vagy kapcsolat, amelyeket a konfigurációkezelési adatbázisban (CMDB) tartanak.
Kapacitásmenedzsment - Capacity Management Az a szolgáltatásirányítási folyamat, amelyenek feladata az informatikai kapacitásra vonatkozó üzleti igények meghatározása mind üzleti mind technikai értelemben, valamint annak megértése és bemutatása, hogy e tevékenységmennyiségeknek az informatikai infrastruktúrán a megfelelő időben és optimális költséggel történő megtermelése milyen következményekkel jár.
Karbantarthatóság - Maintainability Egy komponens vagy informatikaszolgáltatás egy elemének képessége meghatározott feltételek mellett történő használat esetén arra, hogy megtartsák vagy visszaállítsák egy olyan állapotba, amelyben képes ellátni a tőle megkövetelt funkcióit. A karbantarthatóság leírja a meghatározott körülmények melletti, előírt eljárásokat és erőforrásokat felhasználó karbantartást is.
Katasztrófahelyreállítás - Disaster recovery Lásd az informatikaszolgáltatás folytonosságának biztosítását.
Katasztrófaterv - Contingency Plan Lásd az informatikaszolgáltatás-folytonossági tervet
Kemény költségterhelés - Hard Charging A vállalaton belül az a helyzet, amikor a vevőtől a szolgáltatóhoz pénzt utalnak át a szolgáltatások nyújtásának ellenértékeként.
Készenléti rendelkezések - Stand-by Arrangements Rendelkezések, hogy az eszközök, amelyeket tartalékként azonosítottak rendelkezésre álljanak ha az elsődleges eszközök elvesznének egy üzleti megszakadást követően. Jellemzően ezek között van az elhelyezés, informatikai rendszerek, hálózatok és az emberek.
Kézi megkerülő megoldás - Manual Workaround Egy incidens vagy probléma ideiglenes, nem informatikán alapuló megoldása.
Kiadás - Release Jóváhagyott változtatások gyűjteménye az informatikaszolgáltatásban, amelyeket együtt tesztelnek és vezetnek be az éles környezetbe.
Kiadáskezelés - Release Management Az a szolgáltatásmenedzsment folyamat, amely felöleli a hardver- és szoftverkiadások elgondolását, megtervezését, felépítését, beállítását és tesztelését, hogy létrehozzák a kiadási összetevők meghatározott készletét. A kiadási tevékenységek tartalmazzák a tervezést, előkészítést, időzí-
150
tést, oktatást, dokumentálást, szétosztást és telepítést több felhasználó és hely számára is. A kiadáskezelés a változás- és konfigurációkezelés felügyelő folyamatait használja.
Kiszervezés - Outsourcing Amikor korábban a szervezet által végzett funkciókat szerződés szerint egy harmadik fél lát el.
Kiválóság - Excellence Kimagasló gyakorlat a szervezet vezetésében és az eredmények elérésében, amely a következő alapvető elveken alapul: eredmény-orientáltság, ügyfél-orientáltság, vezetés és a cél állandósága, folyamatok és tények, emberek bevonása, folyamatos fejlődés és innováció, kölcsönösen előnyös partnerkapcsolat, nyilvános felelősség. A kiválóságot hatásosan csak a legjobb külső gyakorlattal összehasonlítva lehet mérni.
Kivételes események jelentése - Exception Reporting A készített menedzsment információ lecsökkentése arra, ami a leginkább igényli vagy kiérdemli a figyelmet. Az “első tíz” típusú lista egy példa rá.
Kockázatelemzés - Risk Assessment A kockázatelemzés a kockázatok menedzselésének előzményeként a kockázatok elemzését tartalmazza annak érdekében, hogy a váratlan meghibásodások hatását minimalizáljuk.
Kockázatkezelés - Risk Management Az eszközökre vonatkozó kockázatok kezelése felismeréssel, kiválasztással és ellenintézkedések használatával, amelyeket a felismert kockázatok hiba esetén a szolgáltatásokra gyakorolt potenciális hatásával igazolnak, és e hibák elfogadható szintre csökkentése.
Komponensmeghibásodás hatáselemzése - Component Failure Impact Analysis (C.F.I.A.) Az IBM által kifejlesztett technika, amely mátrixot használ az informatikaszolgáltatás nyújtásában rejlő hibák felismerésére az egyedi konfigurációs elemek hibáit összekapcsolva azok hatásával a nyújtott szolgáltatások teljes szintjére.
Konfigurációellenőrzés - Configuration verification A konfigurációkezelés azon feladata, amely biztosítja, hogy a konfigurációs elemekről a konfigurációkezelési adatbázisban lévő adatok pontosak.
Konfigurációfelügyelet - Configuration Control Azok a tevékenységek, amelyek biztosítják, hogy csak az engedélyezett és azonosított konfigurációs elemek kerülnek be a nyilvántartásba életciklusuk folyamán, és hogy egyetlen konfigurációs elem sem kerül hozzáadásra, módosításra, helyettesítésre és törlésre megfelelő ellenőrző dokumentáció nélkül, mint például egy jóváhagyott változtatáskérelem. A Konfigurációfelügyelet magában foglalja a konfigurációs elemekről nyilvántartott információkhoz való hozzáférés ellenőrzését is.
151
Konfigurációkezelés - Configuration Management A konfigurációs elem tervezésének, azonosításának, felügyeletének és ellenőrzésének folyamata egy szolgáltatáson belül, állapotuk feljegyzése és jelentése, és a változáskezelés támogatására annak felmérése, hogy az elemek megváltoztatásának milyen potenciális informatikai hatása van. (vö. Konfiguráció azonosítás, Konfiguráció felügyelet, Konfigurációs állapotnyilvántartás, Konfigurációellenőrzés.)
Konfigurációmenedzsment - Configuration Management Lásd kofigurációkezelés.
Konfigurációs állapotnyilvántartás - Configuration Status Accounting A konfigurációkezelés azon feladata, amely a konfigurációs elemek állapotát jegyzi fel bármely időpontban, a múltban, a jelenben vagy a jövőben.
Konfigurációs elem (KE) - Configuration Item (CI) A konfigurációs elem egy informatikai infrastruktúra bármely komponense lehet, beleértve a dokumentációs elemeket is, mint például egy szolgáltatási megállapodás vagy egy változáskérelem, és amely a konfigurációkezelés felügyelete alatt áll (vagy kell állnia), és így a formális változásfelügyelet hatáskörébe tartozik. A legalacsonyabb szintű KE rendszerint az a legkisebb egység, amely a többi összetevőtől függetlenül megváltoztatható. A KE-k bonyolultságban, méretben és típusban széleskörűen eltérhetnek, egy teljes szogáltatástól (beleértve az összes hardvert, szoftvert, dokumentációt, stb.) egy programmodulon át egy kisebb hardverösszetevőig. Az összes meglévő vagy potenciális szolgáltatási probléma kapcsolható lesz egy vagy több KE-hez.
Konfigurációs elem típus - CI Type A konfigurációs elemeket osztályba soroljuk közös jellemzőik vagy céljaik szerint. Abban különbözik az alapkonfigurációtól, hogy ez magasabb szintű osztálybasorolás és nem határoz meg konfigurációt.
Konfigurációs készlet - Configuration Set Ezzel a kifejezéssel néha a konfigurációs elemek egy csoportját jellemzik, amelyek rendszerint összetartoznak. (vö. összetett KE, alapkonfiguráció.)
Kölcsönös megállapodás - Reciprocal Agreement Egy informatikaszolgáltatás-folytonosság tervezési megoldás, amely két olyan szervezettől függ, amelyek hajlandók és képesek erőforrásaikat megosztani egy katasztrófa esetén vagy azt megelőzően. A kapacitás és a műszaki összeegyeztethetőség különleges figyelmet kívánó kérdések.
Költségarányos érték - Value for Money Egy szolgáltatás, termék vagy folyamat gazdaságosságához, hatásosságához és hatékonyságához társított elv, vagyis a bemeneti költségek összehasonlítása a kimenetek értékével és annak kvalitatív és kvantitatív megítélése, hogy milyen módon hasznosították és irányították az érintett erőforrásokat.
152
Költségkeret-tervezés - Budgeting A költségek előrejelzésének és ellenőrzésének folyamata. Ismétlődő tárgyalási ciklusokat tartalmaz, ahol a költségvetést (rendszerint éves szinten) megállapítják, és a tényleges vagy megjósolt folyó költségvetések mindennapi figyelését és kiigazítását elvégzik.
Költségszámítás - Costing A költségek azonosításának és üzleti egységekhez vagy tevékenységekhez történő besorolásának folyamata.
Költségterhelés - Charging A költségek megállapításának és a számlázásnak a folyamata annak érdekében, hogy a vásárlóktól a költségeket visszakapjuk. A költségeknek egyszerűknek, érthetőknek, tisztességeseknek és valósaknak kell lenniük.
Közbenső helyreállítás - Intermediate Recovery A közbenső helyreállítás egy olyan informatikaszolgáltatás-folytonossági megoldás, amely egy vészhelyzetben jellemzően 24-72 órán belül nyújta a szolgáltatások helyreállítását. Azok a szervezetek használják, amelyeknek szükségük van az informatikai gépparkjuk helyreállítására egy előre meghatározott időn belül azért, hogy megakadályozzák az üzleti folyamatok súlyos sérülését a meghibásodás miatt. Az azonnali és a fokozatos helyreállítási megoldások között helyezkedik el. (vő. Fokozatos helyreállítás, Azonnali helyreállítás.)
Különbségi kiadás - Delta Release Olyan kiadás, amely egy kibocsátási egységen belül nem cserél le minden összetevő konfigurációs elemet, hanem csak azokat tartalmazza, amelyek megváltoztak a szoftver utolsó kiadása óta. Néha részleges kiadásnak is hívják.
Külső cél - External Target A nyújtott szolgáltatás mértéke olyan szóval kifejezve, amely tükrözi a vevő üzletének nyújtott előnyt.
Külső intézkedés - External Measure Lásd a Külső célt.
Leltárkezelés - Inventory management A konfigurációkezelés egy része, amely az informatikai infrastruktúra legdrágább vagy legérdekesebb konfigurációs elemeinek menedzselésére (ellenőrzés és pénzügyi könyvelés) összpontosít. (vö. tárgyieszköz-gazdálkodás, konfigurációkezelés.)
Leszállítandó - Deliverable Egy elem, amelyet létre kell hozni egy meghatározott követelmény részeként. Lehet végső termék vagy olyan, amelytől egy vagy több következő leszállítandó függ.
153
Létfontosságú üzleti funkció - Vital Business Function Az üzlet informatikaszolgáltatás által támogatott üzletileg kritikus funkciói.
Lezárás - Closure Amikor egy vevő vagy felhasználó elégedett az incidens vagy a probléma megoldásával.
Marginális költség - Marginal Cost Eggyel több kimeneti egység elkészítésének költsége az után, hogy a termelőegységet felállították. Például egy nyomtatott oldal elkészítésének költsége (papír és festékhenger) az után, hogy a lézernyomtatót megvásárolták és üzembeállították.
Másodszintű támogatás - Second Line Incident Control Lásd az incidensfelügyeleti támogatást.
Megállapodás - Agreement Az informatikai szolgáltatásirányítás szóhasználatában a „megállapodás” szó használata a „szerződéssel” ellentétben kevésbé a kettő közti jogi különbségeket jelzi, inkább a megközelítésbeli és a stílusbeli eltéréseket. A megállapodást kizárólag belső felek közti, rendszerint írásbeli megegyezésre használják (bár csatolhatják külső szerződéshez is, amelynek így részévé válik). A megállapodás valószínűleg rögzít egy bizonyos szolgáltatási szint elérésére való törekvést, míg a szerződés rendszerint a megengedhető legalacsonyabb szolgáltatási szintet tartalmazza. A szerződés szóhasználatának tükröznie kell annak jogilag kötelező természetét, de az informatikai szolgáltatásirányítási megállapodás szóhasználata sokkal inkább az érintett felek közti tervezett kapcsolat természetét tükrözi.
Megelőző problémakezelés - Proactive Problem Management A problémák és Ismert hibák felismerésének és megoldásának feladata mielőtt az incidensek bekövetkeznének.
Megfelelőségi vizsgálat - Audit for Compliance Annak ellenőrzése, hogy a folyamatot a tervezett módon hajtják végre, vagyis a megegyezés szerinti eljárásoknak megfelelően.
Meghibásodás - Failure Meghibásodás akkor történik, amikor a funkcionális egység már nem felel meg a céljának.
Meghibásodások közti átlagos idő - Mean Time Between Failures Az informatikaiszolgáltatás egy elemének vagy összetevőjének teljes helyreállítása és ugyanennek a szolgáltatásnak vagy összetevőnek a következő meghibásodása között eltelt átlagos idő.
Megkerülő megoldás - Work-around Eljárás egy incidens vagy probléma elkerülésére vagy egy ideiglenes javítással vagy egy olyan technikával, amely azt eredményezi, hogy a vevő nem függ attól a konfigurációs elemtől, amely ismerten hibát okoz.
154
Megoldás - Resolution Az a tevékenység, amely megold egy incidenst, vagyis lehetővé teszi a felhasználók számára üzleti funkcióik elvégzését. Lehet ideiglenes megkerülő megoldás vagy a hibás KE végleges megjavítása vagy cseréje.
Melegtartalék helyszíne (belső, külső vagy hordozható) - Hot Standby Site Informatikaszolgáltatás-folytonossági megoldás vagy a szervezeten belül vagy harmadik fél által biztosítva, lehetőség szerint állandó helyen vagy hordozhatóan, amely egy számítógépszobából áll teljes környezetszabályozással és telekommunkiációs lehetőségekkel, valamint a szükséges hardverrel és szoftverrel, amelyek lehetővé teszik, hogy a helyszín átvegye az adatfeldolgozást a normális infrastruktúrától minimális szolgáltatáskiesés mellett. (vö. azonnali helyreállítás, közbenső helyreállítás.)
Működésáthidalás - Operations Bridge A számítógépek működésének és a hálózat felügyeletének (és néha a segélyszolgálatnak vagy az ügyfélszolgálatnak) az egyesítése egyetlen fizikai helyen.
Működési költségek - Operational costs Néha a jövedelem vagy a vezetés költségének is hívják; ezek a költségek a szervezet napi működésének eredményei, például munkaerő-költségek, hardverkarbantartás és elektromosság. A megvásárolt tétel értéke csökken, ahogyan elhasználják, mint például a konzultációé. A működési költségek néha változóak (papír, konzultációs segítség) és néha állandóak (fizetések). Az informatikai könyvelésben gyakorlati okokból a működési költségeket úgy tekintik, mint amelyeket egyetlen pénzügyi évre számolnak el, értékcsökkenési rész nélkül.
Műszaki megfigyelői beosztás - Technical Observation Post Egy előre megszervezett értekezlet az informatikai támogatószervezetből érkezett szakértő műszaki támogatószemélyzet számára, amelyet azért hoztak létre, hogy összpontosítson az informatikai rendelkezésreállás megadott jellegzetességeire.
Műszaki súlyosság - Technical Severity Az incidensekhez, problémákhoz és változtatásokhoz rendelt egyszerű kód, amely jelzi az alapjukul szolgáló műszaki komplexitást és hatásukat a műszaki erőforrásokra. Az Üzleti hatással és az Üzleti sürgősséggel együtt használva egyike az informatikai prioritások elosztási tényezőinek.
Nem szétosztható közvetett költség - Unabsorbed Overhead Egy közvetett költség, amely nem osztható szét egy csoport vevő között és más módon kell szétosztani az összes vevő között, mint például a teljes költségük arányában, létszámuk vagy éves költségvetésük arányában, a birtokukban lévő eszközök vagy a munkateljesítményük arányában.
Összemérés - Benchmarking Az összehasonlítás egyik formája, rendszerint egy szervezet és egy vagy több összemérhető külső szervezet tevékenységei között. A szimulációs modellezés egyik formájának leírására is használják, amelynél az egész működési környezetet replikálják vagy szimulálják.
155
Összetett konfigurációs elem (KE) - Assembly CI Olyan konfigurációs elem, amely más konfigurációs elemekből áll.
Probléma - Problem Egy vagy több létező vagy potenciális incidens ismeretlen eredeti oka. A problémákat néha felismerhetjük ha több incidens közös tüneteket mutat. A problémákat egyetlen fontos incidensből is azonosítani lehet, amit egyetlen hiba jelez, amelynek oka ismeretlen. Esetenként a problémákat jóval azelőtt felismerik, mielőtt egyetlen kapcsolódó incidens bekövetkezne.
Problémakezelés - Problem Management Az a szolgáltatásmenedzsment folyamat, amely felöleli a problémafelügyeletet, a hibafelügyeletet és a menedzsment információ elkészítését. A problémakezelés az a folyamat, amely a tényleges és potenciális meghibásodások eredeti okát felismeri. Az elsődleges célja annak biztosítása, hogy a szolgáltatások stabilak, időszerűek és pontosak és hogy a problémák se nem következnek be, se nem ismétlődnek. A folyamat kifejlettségét a problémamegelőzésre való összpontosítási képessége mutatja.
Problémamenedzsment - Problem Management Lásd problémakezelés.
Reagálóképesség - Responsiveness Általában egy bizonyos inger megválaszolásához szükséges idő összehasonlító mérése. A mérés lehet egy informatikai rendszer válaszának sebessége egy felhasználó tevékenységére de egyformán használható egy szervezet viselkedésének megítélésére is például egy incidenst vagy változáskérelmet illetően.
Rendelkezésreálláskezelés - Availability Management Lásd rendelkezésreállás-menedzsment .
Rendelkezésreállás menedzsment - Availability Management Az a szolgáltatásirányítási folyamat, amely elősegíti az ügyfelek követelményeinek meghatározását az informatikaszolgáltatás rendelkezésreállásának tekintetében, megértve az informatikai infrastruktúra képességeit ezen a rendelkezésreállási szintek teljesítésére, és lépéseket tesz a rendelkezésreállás növelésére. Habár a folyamat erősen műszaki szemléletű a legfontosabb a rendelkezésreállás (és különösen a rendelkezésre nem állás hatásának) üzleti értelemben vett megértése.
Riasztás - Alert Figyelmeztetés, hogy egy küszöbértéket elértek, vagy egy hiba történt vagy valószínűleg történni fog. Jellemzően egy rendszermenedzsment eszköz bocsájtja ki.
Riasztási fázis - Alert Phase Az üzletvitel-folytonossági terv első fázisa, amelyben kezdeti sürgősségi eljárásokat és kárfelméréseket indítanak be.
156
Sebezhetőség - Vulnerability Egy szolgáltatás és az őt alkotó konfigurációs elemek (eszközök) gyengesége, amelyet fenyegetésekkel ki lehet használni.
Segélyszolgálat - Help Desk A felület, gyakran egypontos kapcsolatnak is nevezve, az informatika és felhasználói között. Az alapfolyamatai az incidenskezelés és a felhasználói igények kezelése, biztosítva, hogy egy hívás (bejelentés) vagy incidens sem vész el, nem felejtik el vagy hagyják figyelmen kívül, és hogy a szolgáltatást visszaállítják, amilyen gyorsan csak lehet. (vö. ügyfélszolgálat.) Az ITIL új kiadása a segélyszolgálatot kettéosztotta ügyfélszolgálati funkcióra és incidenskezelési folyamatra.
Skálázhatóság - Scalability A szolgáltatás azon képességének mértéke, hogy csökkenti vagy növeli teljesítményét és költségét válaszul az áteresztőképesség vagy igény változásaira.
Súlyos incidens - Major Incident Az az incidens, amelynek üzletre gyakorolt hatása nagyon nagy.
Súlyossági kód - Severity Code A problémákhoz és Ismert hibákhoz rendelt egyszerű kód, amely jelzi hatásuk súlyosságát az informatikaszolgáltatás minőségére. Általános elnevezés a megoldás prioritásának feljegyzési módjára.
Sürgős változtatás - Emergency Change Olyan változtatás, amelyet pillanatok alatt terveznek, időzítenek és hajtanak végre azért, hogy egy szolgáltatást megóvjanak egy elfogadhatatlan kiesési vagy csökkenési kockázattól, a működőképesség hiányától vagy elvesztésétől.
Sürgősség - Urgency Olyan incidens, probléma vagy változtatás üzleti kritikusságának mértéke, amelynek hatása van az üzleti határidőkre. A sürgősség tükrözi a javításra vagy megkerülésre rendelkezésre álló időt, mielőtt az üzlet megérzi a hatást. A hatással és talán a műszaki súlyossággal együtt ez legfőbb eszköz az incidensek, problémák vagy változtatások prioritásának meghatározására.
Szervizelhetőség - Serviceability A szolgáltatókkal szembeni szerződéses feltételek, amelyek tartalmazzák azokat a feltételeket, amelyekkel a szerződéses feltételek érvényesek és elérhetőek egy konfigurációs elemre vagy rendszerre.
Szokásos ár - Going Rate Az az árazási mód, amikor az ár hasonló ahhoz, amit más belső osztályok vagy hasonló szervezetek felszámítanak.
157
Szokásos költségek - Standard Costs A várt költségek előre meghatározott kiszámítása meghatározott működési feltételek esetén. Jellemzően az ellenőrzés alapjául szolgál eltérési könyveléssel, munkaértékeléssel és az eladási árak rögzítésével.
Szokásos változtatás - Standard Change Ismétlődő, jól ismert változtatás, amelyet eljárásban határoztak meg, hogy egy előre meghatározott, viszonylag kockázatmentes utat kövessenek, és amely egy megadott igényre vagy körülmények együttesére való elfogadott válasz, ahol a jóváhagyást valójában a megvalósítás előtt már megadták.
Szolgáltatásbiztosítás - Service Delivery Lásd szolgáltatásnyújtás.
Szolgáltatáseredmény - Service Achievement Egy meghatározott időtartam alatt az informatikai igazgatóság által egy felhasználónak nyújtott tényleges szolgáltatási szintek.
Szolgáltatásgazda - Service Owner Az a személy, akinek elsődleges felelőssége a szolgáltatás, beleértve a megtervezését, céljait és haladását.
Szolgáltatási idő - Service Hours Az a megegyezés szerinti időszak, amikor a szolgáltatásnak elérhetőnek kell lennie.
Szolgáltatási rend - Service Charter Az a nagyon fontos dokumentum a legfelső szinten jóváhagyva, amely tömören és érthetően meghatározza a szolgáltatás általános minőségét, amelyet bármely vevő vagy felhasználó elvárhat az informatikai osztálytól, és amely dokumentum az osztály informatikaszolgáltatásfilozófiájának keretein belül készül. Valószínűleg tartalmazza az Informatika hitvallását és hivatkozik a szervezet kultúrájára, elképzelésére, értékeire és etikai politikájára.
Szolgáltatási szint célkitűzés - Service Level Objective Az a megtárgyalt dokumentum, amely meghatározza a vevőnek nyújtandó szolgáltatást kvalitatív értelemben, habár néhány fő teljesítményjelző is meghatározásra kerülhet. Az szolgáltatási szint célkitűzéseket egyre jobban szeretik, bizonyára kezdetben az SLA-khoz képest, mert tisztán érthetően tartalmazzák az ajánlott szolgáltatás igazi természetét, összpontosítva a szolgáltatás hozzájárulására az üzlet értékláncához. A legjobb gyakorlat javasolja, hogy az üzlet képviselői kezdetben vázoljanak fel szolgáltatási szint célkitűzéseket.
Szolgáltatási szint irányítás - Service Level Management Lásd szolgáltatási szint menedzsment.
158
Szolgáltatási megállapodás - Service Level Agreement Az a formálisan megtárgyalt dokumentum, amely meghatározza (vagy megkísérli meghatározni) kvantitatív (és talán kvalitatív) kifejezésekkel a vevőnek kínált szolgáltatást. El kell kerülni a félreértést, hogy a vajon a kvantitatív definíciók képezik-e az elfogadható szolgáltatás szintjét, célok, amelyekre a szállítónak törekednie kell, vagy elvárások, amelyeket a szolgáltató igyekszik teljesíteni. Bármely mértéket, amely szerepel az SLA-ban, tudni kell rendszeresen mérni és az SLAban rögzíteni kell, hogy ki méri. Tipikusan tartalmazza a szolgáltatási időszakot, a szolgáltatás elérhetőségét, a vevőtámogatás szintjeit, átbocsátóképességet és reagálóképességet, korlátozásokat, funkcionalitást és a vészhelyzet esetén nyújtott szolgáltatási szinteket. Tartalmazhat biztonsági, költségés szóhasználati információkat is. Eltekintve a rendszeres időszaki felülvizsgálatoktól az SLA-kat újra kell tárgyalni, amikor egy üzleti szolgáltatás követelménye megváltozik, vagy fennáll a követelmények szerinti teljesítés képességének hiánya.
Szolgáltatási szint menedzsment - Service Level Management A vevőkiszolgálás igényelt és költségében igazolt szintjei meghatározásának, megállapodásának, dokumentálásának és menedzselésének folyamata. Többel foglalkozik, mint maga a szolgáltatási megállapodás, beleértve a szolgáltatáskatalógust és a felülvizsgálati értekezleteket.
Szolgáltatáskarbantartási célkitűzés - Service Maintenance Objective Az a teljes idő, ami alatt a komponensnek el nem érhetőnek kell lennie, hogy előkészítsék a karbantartásra, elvégezzék a karbantartást és visszaállítsák működőképes állapotába.
Szolgáltatáskatalógus - Service Catalogue Az informatikai osztály által készített dokumentum (nyomtatott vagy interneten/intraneten lévő) vevői és felhasználói tájékoztatására. Rövid áttekintést nyújt üzleti értelemben mindazon üzleti és infrastruktúra szolgáltatásokról, amelyeket az informatikai szolgáltató kínál és tartalmazhatja a szolgáltatások árait is. Ezt a tájékoztatót a részletesebb műszaki tudással együtt karbantartják belső használatra.
Szolgáltatáskiesés elemzése - Service Outage Analysis Egy rendelkezésreállás-menedzsment technika, amelyet a leállási idő elemzésére és a végponttól végpontig tartó szolgáltatás üzemideje javítási lehetőségének felismerésére használnak – alapvetően egy problémamenedzsment tevékenység.
Szolgáltatásirányítás - Service Management Lásd szolgáltatásmenedzsment.
Szolgáltatásmenedzsment - Service Management Az üzlet/informatika összehangolás (vö.) egyik eleme. Az a magasszintű folyamat, amely irányítja az informatikaszolgáltatást az üzleti vevők nevében. Jogköre van döntéseket hozni az informatikaszolgáltatás teljes portfóliójának nyújtásáról. Az Informatikai infrastruktúra könyvtár (ITIL) úgy tekinti a szolgáltatásmenedzsmentet, mint egy átfogó filozófiát, amely áthatja az egyedi ITIL folyamatok működtetését.
159
Szolgáltatásnyújtás - Service Delivery Általában hivatkozás az Informatikai infrastruktúra könyvtár “Szolgáltatásnyújtás” kötetében leírt öt menedzsment folyamatra, amelyek a szolgáltatási szint, a kapacitás, az informatikaszolgáltatás.folytonosság és a rendelkezésreállás menedzsment, valamint az informatikaszolgáltatás pénzügyi irányítása.
Szolgáltatástámogatás - Service Support Általában az Informatikai Infrastruktúra Könyvtár “Szolgáltatástámogatás” kötetében leírt öt menedzsment folyamatra való hivatkozás, amelyek az incidens-, probléma-, változás-, Konfigurációés kiadásmenedzsment, valamint az ügyfélszolgálat funkciójáról szóló fejezet.
Szolgáltató - Service Provider Egy szervezet, amely szolgáltatásokat vagy termékeket nyújt vevőknek. A szolgáltató lehet belső vagy külső is.
Tanúsítás - Certification Egy szervezet folyamatainak független és akkreditált szerv általi formális kiértékelése egy meghatározott szabvány szerint és a megfelelőséget igazoló tanúsítvány kiadása.
Tárgyieszköz-gazdálkodás - Asset Management Szabványos könyvelési eljárás, amely egy bizonyos értékhatár feletti eszközök részleteit és amortizációját kezeli. A tárgyieszköz-gazdálkodási rendszerek egy eszköznyilvántartásban lévő eszközökről tárolhatják az értékről, jelenlegi tulajdonosról és helyről szóló információkat, de – eltérően a konfigurációkezeléstől- nem rögzítik az eszközök közötti kapcsolatokat. Azok az informatikai szervezeti egységek, amelyeknek nincs teljesen kifejlődött konfigurációkezelési adatbázisuk, valószínűleg rendelkeznek egy vagy több eszköznyilvántartással, amely részben leírja az informatikai infrastruktúrát.
Tárolómenedzsment - Storage Management Egy olyan rendszermenedzsment tevékenység, amely az adatok gazdaságos és hatásos tárolását és karbantartását lehetővé tevő alkalmazott politikával, technikákkal és technológiákkal kapcsolatos.
Távoli javítások - Remote Fixes Azok az incidensek vagy problémák, amelyeket a nélkül oldottak meg, hogy a támogató személyzet egy tagja meglátogatta volna a kérdéses helyet.
Teljes kiadás - Full Release Olyan kiadás, amely egy kiadási egység minden összetevőjét teszteli, szétosztja és megvalósítja függetlenül attól, hogy megváltoztak-e a szoftver utolsó kiadása óta.
Teljesítménymenedzsment - Performance Management Annak biztosítása, hogy az infrastruktúra technikai erőforrásai a lehetséges legjobb költségarányos értéket nyújtják és a műszaki dokumentációban leírtan vagy feltételezetten viselkednek.
160
Többes szavazás - Multivoting Az a problémamenedzsment technika, amely nagyszámú tételek (például brainstorming témáinak vagy eredményeinek listája) lecsökkentését segíti egy kezelhető kevés tételre (rendszerint 3-5). A technika lehetővé megengedi a lista gyors lecsökkentését nagyfokú csoportegyetértéssel és kiküszöböli az egyének azonosulását bizonyos elemekkel.
Tulajdonlás - Ownership Elvi felelősséget jelentő általános kifejezés, amely bármely tevékenységre vagy eseményre alkalmazható. Az incidensmenedzsment “tulajdonosa” a folyamat tulajdonos (vö.) lesz, magának az incidensnek az ügyfélszolgálat lesz a tulajdonosa, és a meghibásodott konfigurációs elem tulajdonosa az ügyfél lehet.
Ügyfélorientáltság - Customer Focus Annak felismerése, hogy a termék vagy szolgáltatás minőségének végső döntőbírája a vevő, és hogy a vevőhűség, megtartás és piaci részesedés növelése a legoptimálisabb a jelenlegi és potenciális vevők igényeire való összpontosítás mellett.
Ügyfélszolgálat - Service Desk A segélyszolgálat (HelpDesk) alternatív neve, amelyet gyakran használnak ha a más szolgáltatásmenedzsment folyamatokhoz való kapcsolódást fontosnak gondolják. Egyre inkább így hívják azt az elsővonalbeli támogató csoportot, amely értéket növel az elsőre távolról megjavított hibák magas arányával.
Üzlet és informatika összehangolása - Business/IT Alignment Az üzlet számára nyújtott informatikaszolgáltatás olyan megközelítése, amely elismeri az üzleti igények elsőbbségét. Az üzlet és informatika összehangolása az információs rendszerek erőforrásai szervezésének, menedzselésének, ellenőrzésének és mérésének különféle módjait tartalmazza annak érdekében, hogy maximalizálják az üzlethez hozzáadott értéket. A következőket tartalmazza: •
•
Üzleti vizsgálat o
értéklánc-elemzés
o
az üzleti célok megállapítása
o
informatikai követelmények meghatározása
Informatikai stratégia kialakítása o
informatikai alapelvek megfogalmazása
o
politikák és szabványok meghatározása
o
informatikai képességek megállapítása
o
műszaki architektúra meghatározása
o
informatikai folyamatmodell meghatározása
161
o •
informatikai szervezeti modell meghatározása
Ügyfélkapcsolat-menedzsment o
informatikaszolgáltatás hirdetése
o
ügyfélelégedettség felmérése
o
kapcsolattartás az ügyféllel
o
stratégiai üzleti jelentés
o
ügyféltámogatási követelmények meghatározása
o
új szolgáltatási igények felismerése
Üzletfolytonosság menedzsment - Business Continuity Management Megelőzni azokat az incidenseket, amelyek hatással lehetnek a kritikus üzleti funkciókra és folyamatokra és biztosítani, hogy a szervezet képes legyen válaszolni ilyen incidensekre tervezett és begyakorolt módon.
Üzleti álláspont - Business Case Információ, amely leírja egy beszerzés vagy projekt elindításának és folytatásának megindoklását. Tartalmazza a költségek okait és frissítik a projekt vagy a beszerzési folyamat fontosabb pontjainál.
Üzleti funkció - Business Functions Egy üzleti részleg a szervezeten belül, mint például egy osztály, divízió vagy fiók.
Üzleti hatásvizsgálat - Business Impact Analysis Formális elemzés, amely egy meghatározott informatikaszolgáltatási kör kiesésének az üzletre vonatkozó hatását vizsgálja. Azonosítani fogja azokat a minimális szolgáltatási köröket, amelyekre a szervezetnek a működés folytatásához szüksége van.
Üzleti működés - Business Operations Tevékenységek és műveletek, amelyeket a felhasználók hajtanak végre a szervezet üzleti feladata teljesítésének érdekében. Az ügyfélszolgálat feladata azoknak a megjegyzéseknek és kéréseknek a kezelése és támogatása, amelyek a fenti üzleti működés folyamán keletkeznek.
Üzleti szolgáltatás - Business Service Olyan szolgáltatás, amelyet az üzlet képviselői tisztán azonosíthatnak és egyértelmű kapcsolata van az üzlet értékláncával, és szorosan illeszkedik kifejezett üzleti folyamatokhoz. A legtöbb üzleti szolgáltatásnak könnyen felismerhető rangidős üzleti képviselője van, számos jellegzetes alkalmazásból áll és ezek nyújtásában az infrastruktúra-szolgáltatások pontos működésére támaszkodik. A szolgáltatási szint célkitűzéseket és a szolgáltatási megállapodásokat az Üzleti szolgáltatás szintjén kell megfogalmazni. Az üzleti szolgáltatás tipikus példája a fogyasztói termékek eladását alátámasztó összes logisztikai komponens végrehajtása. Az egészséges és termékeny üzlet és informatika összehangolás (vö.) eléréséhez fontos, hogy az informatikaszolgáltatás világosan kapcsolódjon azokhoz az egyedi üzleti szolgáltatásokhoz,
162
amelyeket alátámasztanak, és egy kiforrott szolgáltatásirányítási környezetben a vevő üzleti szolgáltatásai felsőszintű konfigurációs elemek lesznek.
Üzleti tevékenységi szintek - Bussiness Activity Levels Azon üzleti folyamati tevékenységek előrejelzett vagy történeti szintjei, amelyeket az informatikai infrastruktúrának támogatnia kell vagy kellett. Üzleti értelemben mérik (például a felhasználói fiókok száma).
Üzletikapacitás-menedzsment - Business Capacity Management A kapacitásmenedzsment egyik tevékenysége, amely felelős annak biztosításáért, hogy az informatikaszolgáltatásra vonatkozó üzleti követelményeket figyelembe vegyék, tervezzék és megvalósítsák időben és költséghatékonyan. Az üzletikapacitás-mendzsment közeli kapcsolatban van a szolgáltatási szint menedzsmenttel.
Üzletvitel-helyreállítás - Business Recovery Lásd az üzletfolytonosság menedzsmentet.
Valós költségterhelés - Real Charging Lásd a Kemény költségterhelést.
Változásfelügyelet - Change control Azok az eljárások, amelyek biztosítják, hogy minden változtatás felügyelt legyen, beleértve a benyújtást, feljegyzést, elemzést, döntéshozást, jóváhagyást, megvalósítást és a megvalósítás utáni áttekintést is.
Változáskérelem - Request for Change Egy módszer az informatikai Infrastruktúra bármely összetevőjének vagy az informatikaszolgáltatás bármely jellegének megváltoztatását javasolni. Lehet egy dokumentum vagy egy feljegyzés, amelyben szerepel a javasolt változtatás természete, részletei, igazolása és engedélyezése.
Változáskezelés - Change Management Az a szolgáltatásmenedzsment folyamat, amely az informatikai infrastruktúrán végrehajtandó változtatási kérelmek felügyeletéért és menedzseléséért felelős, illetve az informatikaszolgáltatás bármely jellegéért, hogy támogassa az üzleti előnyöket a szolgáltatások megszakítása kockázatának csökkentésével. A változáskezelés felügyeli és menedzseli is azoknak a változásoknak a végrehajtását, amelyek azt követően jóváhagyásra kerülnek.
Változáskezelési hatóság - Change Authority Projektvezetési szóhasználatban az az alcsoport, amely megkapta a hatalmat a projekten belüli változtatás jóváhagyására, és amelyet néha konfigurációs bizottságnak neveznek. Ha a javasolt változtatásnak volnának kihatásai a szolgáltatásra a változáskezelési hatóságnak a változásmenedzserhez kellene azt utalnia.
163
Változáskezelési tanács - Change Advisory Board Azon emberek irányadó és képviseleti csoportja, akik mind üzleti mind technikai szempontból felelősek minden nagy kihatású változáskérelem értékeléséért. Tanácsot adnak a változáskezelésnek a változáskérelmek prioritásáról, és javaslatot tesznek az erőforrások elosztására, hogy megvalósítsák azokat a változtatásokat. A változáskezelési tanács tagjait a vevő, a felhasználók és az informatika képviselői adják és a tárgyalt változtatások természetétől függően tagja lehet harmadik fél vagy más adminisztratív üzleti képviselő is. A változáskezelési tanács elnöke a változásmenedzser.
Változáskezelési tanács/Sürgősségi bizottság Emergency Committee
-
Change Advisory Board /
A változáskezelési tanács sürgősségi ülése, rendszerint csökkentett létszámmal, amely a sürgős, nagy kihatású változtatásokat tekinti át. A tagságnak, amely esetről esetre változhat, emiatt képviselnie kell mindazt a tudást és hatalmat, amelyre ilyen kivételes esetekben szükség van. A gyakorlatban a tagok döntésüket meghozhatják tényleges összejövetel nélkül is.
Változásmenedzsment - Change Management Lásd változáskezelés.
Változat - Variant Egy konfigurációs elem (KE), amely –habár kissé eltérő- ugyanazzal az alapvető funkcionalitással rendelkezik, mint más KE-k és így megkövetelhetik, hogy általános csoportjával együtt elemezzék.
Változtatási időszak - Change slot Az a szokásos, megállapodott idő, amikor a változtatásokat a szolgáltatásokra vonatkozó minimális kihatással lehet bevezetni.
Visszaállítási terv - Backout plan Az a terv, amely dokumentálja mindazon tevékenységeket, amelyeket a szolgáltatás helyreállításához kell elvégezni ha az azt érintő változtatás vagy kibocsátás részben vagy teljesen sikertelen. A visszaállítási tervek lehetővé tehetik a teljes vagy részleges visszafordítást. Extrém körülmények között a tervek egyszerűen csak utalhatnak az Informatikaszolgáltatás-folytonossági terv alkalmazására.
Zavar - Incident Lásd incidens.
164
C. függelék: Angol-magyar ITIL-szótár
Angol eredeti
Magyar megfelelő(k)
Agreed Service Time
előírt szolgáltatási idő
Agreement
megállapodás szerződés
Alert
riasztás
Alert Phase
riasztási fázis
Application Service Provider
alkalmazásszolgáltató
Assembly Configuration Item (CI)
összetett konfigurációs elem (KE)
Asset
vagyontárgy eszköz
Asset Management
eszközgazdálkodás tárgyieszköz-gazdálkodás
Asset Register
eszköznyilvántartás
Attribute
jellemző
Audit
átvizsgálás felülvizsgálat audit
Audit for Compliance
megfelelőségi vizsgálat
Availability Management
rendelkezésreállás menedzsment
Back-office
háttérszervezet
Backout plan
visszaállítási terv
Baseline
alapváltozat alapkonfiguráció
Baselining
alapváltozat összeállítása
Benchmarking
összemérés
Budgeting
költségkeret tervezés
Bussiness Activity Levels
üzleti tevékenységi szintek
Business Capacity Management
üzletikapacitás menedzsment
Business Case
üzleti álláspont üzleti elemzés
Business Continuity Management
üzletfolytonosság menedzsment üzletvitel-folytonosság biztosítása
Business Functions
üzleti funkciók
Business Impact Analysis
üzleti hatásvizsgálat
Business/IT Alignment
üzlet és informatika összehangolása
Business Operations
üzleti működés
Business Recovery
üzletvitel helyreállítás
Business Service
üzleti szolgáltatás
Capacity Management
kapacitásmenedzsment kapacitáskezelés
165
Angol eredeti
Magyar megfelelő(k)
Certification
tanúsítvány bizonyítvány oklevél
Change Advisory Board
változáskezelési tanács
Change Advisory Board / Emergency Committee változáskezelési tanács sürgősségi bizottsága Change Authority
változáskezelési hatóság
Change control
változásfelügyelet
Change Management
változáskezelés változásmenedzsment
Change slot
változtatási időszak
Charging
költségterhelés
CI Type
konfigurációs elem (KE) típus
Clerical Backup
hagyományos irodai biztonsági másolat hagyományos irodai feldolgozás vészhelyzet esetén
Closure
lezárás
Cold Standby/Start
hidegtartalék / hidegindítás
Component Failure Impact Analysis
komponensmeghibásodások hatáselemzése
Confidentiality
bizalmasság
Configuration Control
konfiguráció felügyelet
Configuration Item (CI)
konfigurációs elem (KE)
Configuration Management
konfigurációkezelés
Configuration Set
konfigurációs készlet
Configuration Status Accounting
konfigurációs állapotnyilvántartás
Configuration verification
konfigurációellenőrzés
Contingency Plan
katasztrófaterv vészhelyzetkezelési terv üzemzavarelhárítási terv
Cost Unit
költségelem
Costing
költségszámítás
Customer Focus
ügyfélorientáltság
Definitive Hardver Store
ellenőrzött hardverraktár
Definitive Software Library
ellenőrzött szoftverkönyvtár
Deliverable
leszállítandó
Delta Release
delta- (különbségi) kiadás
Demand Management
igénykezelés
Deming
W. Edwards Deming (amerikai minőségügyi, TQM szakember)
Dependency
függőség
Detection
észlelés detektálás
Diagnostic Script
diagnosztikai forgatókönyv
Disaster recovery
katasztrófahelyreállítás
Differential Charging
differenciális költségterhelés
166
Angol eredeti
Magyar megfelelő(k)
Downtime
állásidő kieső idő
Effectiveness
eredményesség, hatásosság
Efficiency
hatékonyság
Emergency Change
sürgős változtatás
Error Control
hiba felügyelet
Escalation
eszkaláció
Excellence
kiválóság
Exception Reporting
kivételes események jelentése
External Measure
külső intézkedés
External Target
külső cél
Failure
meghibásodás hiba
Fault
hiba
Fault Tolerance
hibatűrés
Financial Management for IT Services
informatikaszolgáltatás pénzügyi irányítása
First Level Support
első szintű támogatás
First Time Fix Rate
elsőre megjavított esetek aránya
Follow the Sun Support
az egész világra kiterjedő támogatás
Full Release
teljes kiadás
Going Rate
szokásos ár
Gradual Recovery
fokozatos helyreállítás
Hard Charging
kemény költségterhelés
Help Desk
segélyszolgálat ügyfélszolgálat
Hot Standby/Start
melegtartalék / melegindítás
Immediate Recovery
azonnali helyreállítás
Impact Analysis
hatáselemzés
Impact Code
hatáskód
Impact Scenario
hatásbekövetkezési forgatókönyv
Incident
incidens zavar
Incident Control
incidensfelügyelet
Incident Control Support
incidensfelügyeleti támogatás
Incident Management
incidensmenedzsment incidenskezelés
Integration Testing
integrációtesztelés
Integrity
integritás
Intermediate Recovery
közbenső helyreállítás
Internal Measure
belső intézkedés
Internal Specsheet
belső specifikációs lap
Internal Target
belső cél
167
Angol eredeti
Magyar megfelelő(k)
Inventory management
leltárkezelés
Invocation
életbeléptet
Invocation and Recovery Phase
életbeléptetési és helyreállítási fázis
Invocation of Bussiness Recovery Plans
üzletmenet-helyreállítási terv életbeléptetése
IT Infrastructure Library
informatikai infrastruktúra könyvtár
IT Service
informatikaszolgáltatás (szűkebb értelemben) informatikai szolgáltatás (tágabb értelemben)
IT Service Continuity Management
Informatikaszolgáltatás-folytonosság menedzsment
Key Performance Indicator
fő teljesítményjelző
Known Error
ismert hiba
Maintainability
karbantarthatóság
Major Incident
súlyos incidens
Manual Workaround
kézi megkerülő megoldás
Marginal Cost
marginális költség
Maturity Level
érettségi szint
Mean Time Between Failures
meghibásodások közti átlagos idő
Multivoting
többszavazásos
Notional Charging
jelképes költségterhelés
Operational costs
működési költségek
Operations Bridge
működésáthidalás
Outsourcing
kiszervezés kihelyezés (ügyfél oldal) működtetés (szolgáltatói oldal)
Overheads
általános költség
Ownership
tulajdonlás
Package Release
csomagkiadás csomagkibocsátás
Pain Factor
fájdalomfaktor
Performance Management
teljesítménymenedzsment
Proactive Problem Management
megelőző problémakezelés
Problem
probléma
Problem Management
problémakezelés problémamenedzsment
Quick Win
gyors siker
Real Charging
valós költségterhelés
Reciprocal Agreement
kölcsönös megállapodás
Recovery
helyreállítás
Recovery Center
helyreállítási központ
Release
kiadás kibocsátás
Release Management
kiadáskezelés kiadásmenedzsment
168
Angol eredeti
Magyar megfelelő(k)
Remote Fixes
távoli javítás
Request for Change
változáskérelem változtatáskérelem
Resilience
ellenállóképesség
Resolution
megoldás helyreállítás
Responsiveness
reagálóképesség
Return on Investment
befektetés megtérülése
Revenue Cost
bevételi költség
Risk Assessment
kockázatelemzés
Risk Management
kockázatmenedzsment kockázatkezelés
Scalability
skálázhatóság
Scope
alkalmazási/alkalmazhatósági kör hatókör
Script
forgatókönyv
Second Line Incident Control
második szintű incidensfelügyelet
Service Achievement
szolgáltatáseredmény
Service Catalogue
szolgáltatáskatalógus
Service Charter
szolgáltatási rend
Service Delivery
szolgáltatásnyújtás szolgáltatásbiztosítás
Service Desk
ügyfélszolgálat
Service Hours
szolgáltatási idő(szak)
Service Level Aggreement
szolgáltatási megállapodás
Service Level Management
szolgáltatási szint menedzsment szolgáltatási szint irányítás
Service Level Objective
szolgáltatási szint célkitűzés
Service Maintenance Objective
szolgáltatáskarbantartási célkitűzés
Service Management
szolgáltatásmenedzsment szolgáltatásirányítás
Service Outage Analysis
szolgáltatáskiesés elemzése szolgálatleállás elemzése
Service Owner
szolgáltatásgazda
Service Provider
szolgáltató
Service Support
szolgáltatástámogatás
Serviceability
szervizelhetőség
Severity Code
súlyossági kód
Single Point of Contact
egypontos kapcsolat
Single Point of Failure
egypontos hiba
Sizing Report
méretezési jelentés
Stakeholders
érdekeltek
169
Angol eredeti
Magyar megfelelő(k)
Stand-by Arrangements
készenléti rendelkezések
Standard Change
szokásos változtatás
Standard Costs
szokásos költségek
Storage Management
tárolómenedzsment tárolásmenedzsment
Technical Observation Post
műszaki megfigyelői beosztás
Technical Severity
műszaki súlyosság műszaki komolyság
Terms of Reference
hivatkozási alap
Tied Users
(belső szolgáltatáshoz) kötött felhasználók
Total Cost of Ownership
a tulajdonlás teljes költsége
Transfer Cost
átadott költség
Trouble Ticket
hibajegy
Unabsorbed Overhead
nem szétosztható közvetett költség
Underpinning Contract
háttérszerződés alátámasztó szerződés
Untied Users
(belső szolgáltatáshoz) nem kötött felhasználók
Urgency
sürgősség
Value for Money
költségarányos érték
Variance
eltérés
Variant
változat
Vital Business Function
létfontosságú üzleti funkció
Vulnerability
sebezhetőség
Work-around
megkerülő megoldás
170
D. függelék www.itsmf.hu web-tartalom Ez a függelék azzal foglalkozik, milyen legyen a szolgáltatásmenedzsment fórum internetes oldalának felépítése és tartalma. Ennek fő célja a tájékoztatás és az ismeretközlés. Az alábbiakban definiáljuk a célokat, azok támogatását, egy javasolt tartalmi modellt, majd egy induló tartalmat, amely a honlap első tartalma lesz.
A tájékoztatással kapcsolatos célok: •
Áttekinthető szerkezet
•
Könnyen megtalálható honlap
•
Áttekintő tájékoztatás az ITIL-ről
•
Tartalmi tájékoztatás az ITIL-ről
•
Áttekintő tájékoztatás a fórumról és annak működéséről
•
Tájékoztatás a rendezvényekről
•
Tájékoztatás az igényelt információk beszerezhetőségének módjáról
Az ismeretközléssel kapcsolatos célok: •
Módszertani ismeretek
•
Gyakorlati tapasztalatok, esettanulmányok, bevezetési ajánlások
•
Átvizsgálási, összemérési módszerek
•
Terminológia
•
Szakirodalom, internetes hivatkozások
A tájékoztatással kapcsolatos célok lebontása: •
Áttekinthető szerkezet ♦ A felső szinten minden fő téma legyen látható ♦ A navigáció legyen egyértemű ♦ Átlátható faszerkezet ♦ Ne legyenek eldugott témák
•
Könnyen megtalálható honlap ♦ Kulcsszavak megválogatása ♦ Hivatkozások elhelyezése idegen oldalakon ♦ Regisztrálás a fontosabb keresőkbe
•
Áttekintő tájékoztatás az ITIL-ről ♦ Kialakulás ♦ Mire jó, kinek hasznos ♦ Dokumentáció ♦ Oktatás ♦ Támogató szervezetek
171
•
Tartalmi tájékoztatás az ITIL-ről ♦ Összefoglalók ♦ Bevezetési ajánlások ♦ Állapotfelmérés ♦ Előadások ♦ Támogató szakirodalom
•
Áttekintő tájékoztatás a fórumról és annak működéséről ♦ A fórumok rendszere ♦ Működési elvek ♦ Szolgáltatások ♦ Tagsági feltételek, jogosultságok ♦ Hazai fórumra vonatkozó információk
•
Tájékoztatás a rendezvényekről ♦ Konferenciák ♦ Szemináriumok ♦ Tanfolyamok
•
Tájékoztatás az igényelt információk beszerezhetőségének módjáról ♦ Dokumentáció ♦ Oktatás ♦ Szolgáltatók ♦ Szakértők
Az ismeretközléssel kapcsolatos célok lebontása: •
Módszertani ismeretek ♦ A módszertan összefoglalása és hivatkozások
•
Gyakorlati tapasztalatok, esettanulmányok, bevezetési ajánlások ♦ Ajánlások ♦ Előadások ♦ Cikkek, tanulmányok ♦ Konkrét bevezetések, alkalmazások esettanulmányai
•
Átvizsgálási, összemérési módszerek ♦ Audit és benchmark (átvizsgálási és összemérési) módszerek
•
Terminológia ♦ Magyar szóhasználat ♦ Kifejezések tartalmi leírása
•
Szakirodalom, internetes hivatkozások ♦ Az elsődleges dokumentáció felsorolása és elérhetősége 172
♦ Hasznos internetes oldalak címei ♦ Cikkek, tanulmányok ♦ Minták, sablonok ♦ Esetleg ismeretbázis létrehozása és fenntartása
Kiinduló tartalom A kiinduló tartalom célja egy induló honlap gyors létrehozása (itSMF.hu), még a tanulmány elfogadása előtt. A tanulmány elfogadása után annak fejezeteit is beillesztjük a felvázolt struktúrába.
Kulcsszavak: IT szolgáltatás menedzsment, IT szolgáltatás irányítás Informatikaszolgáltatás. Informatikai szolgáltatás informatikai szolgáltatás menedzsment,, informatikai szolgáltatásmenedzsment informatikai szolgáltatás irányítás, informatikai szolgáltatásirányítás üzemeltetés menedzsment, üzemeltetés irányítás, üzemeltetésmenedzsment, üzemeltetésirányítás működésirányítás, működésmenedzsment outsourcing, kiszervezés, távfelügyelet ASP, alkalmazásszolgáltatás Hálózat menedzsment Alkalmazás menedzsment, alkalmazásmenedzsment ITIL, ITIL módszertan, üzemeltetés módszertan „best practice”, „bevált gyakorlat”, ”legjobb gyakorlat”, „jó gyakorlat”
Nyitólap (a felső sáv lehetne a Hírek Rendezvények, de lehet, hogy első körben mást még nem tennénk ide. Esemény a tanfolyam és a konferenciacia. Hír: ezzel a honlappal beindult az itSMF szervezése) ItSMF (logo) IT Service Management Forum Hungary IT Szolgáltatás Menedzsment Fórum Magyarország Üdvözöljük a szerveződő itSMF Magyarország honlapján. Az itSMF az informatikai szolgáltatásmenedzsment területén dolgozó szakemberek független, nemzetközileg elismert fóruma.
173
Az itSMF célja az információcsere, a tapasztalatok megosztása és a tájékoztatás, az informatikai szolgáltatás menedzsment ITIL módszertanának elterjesztése. Reméljük, már ezzel az induló oldallal is segítünk átfogó képet adni. Szivesen látjuk az érdeklődőket és azokat is , akik részt akarnak venni a Fórum szervezésében.
Web struktúra
Fogalmak Mit takar az informatikai szolgáltatás menedzsment
Az informatikai szolgáltatás menedzsment az informatikai rendszerek működtetésének, üzemeltetésének irányítási kérdéseivel foglalkozik. Az informatikát egyre inkább az általa nyújtott szolgáltatásokon keresztül érzékeljük, ítéljük meg és nem is akarjuk tudni, hogy milyen berendezéseket milyen módon üzemeltetve valósulnak meg ezek a szolgáltatások. A működtető szemszögéből viszont fontos, hogy az elvárt szolgáltotásokat az előírt minőségben tudja biztosítani, zavarok esetén minél gyorsabban helyre tudja állítani azokat, írányítani tudja az üzemeltetési folyamatot a szolgáltatási célok teljesítése érdekében. A szolgáltatás menedzsment egy nyilvános, mindenki számára hozzáférhető módszertana az ITIL, amely mára de facto nemzetközi szabvány lett.
Fogalmi szótár
Előkészülés alatt van egy ango-magyar terminológiai szótár és egy fogalmi szótár, amely értelmezi az egyes kifejezések általánosan elfogadott jelentését. A fogalmi szótár november végéig publikálva lesz az interneten.
Amit az ITIL-ről tudni kell Az ITIL módszertan, bevált gyakorlat (best practice)
Az ITIL (IT Infrastructure Library) egy angol kormányzati támogatással létrehozott módszertan. A név arra utal, hogy kezdetben egy egységes szerkezetű könyvsorozatban dokumentálták a sikeres gyakorlati megoldásokat. Később ennek a sorozatnak a 10 legfontosabb témakör bevált gyakorlatát dokumentáló kötete lett a módszertan első változata. A mára nemzetközile elterjedt, 2000-ben megújított módszertan 2 csoportba 11 témakört ölel fel. Szolgáltatásbiztosítás: Szolgáltatási szint menedzsment Rendelkezésre állás menedzsment IT szolgáltatás-folytonosság menedzsment Kapacitás-menedzsment IT szolgáltatások pénzügyi irányítása Szolgáltatástámogatás: Ügyfélszolgálat Incidens menedzsment Probléma menedzsment
174
Változáskezelés Konfigurációkezelés Kiadáskezelés
Dokumentáció
Az informatikai szolgáltatás irányítás módszertanát (ITIL) két kötetben adták ki: Service Delivery Service Support Ezek képezik az új dokumentáció alapját, ez képezi a nemzetközi vizsgák hivatalos anyagát is. További megjelent kötet a Security Management az informatikai biztonság kérdéseivel, a Planning to implement Service Management a bevezetés kérdéseivel foglalkozik, az IT Service Management zsebkönyv pedig egy tömör, vázlatos összefoglalást ad a témáról. További tervezett kötetek az Application Management, az ICT Infrastructure Management és a The Business Perspective.
Oktatási és vizsgarendszer
Az angol ISEB (Information Systems Examination Board) és a holland EXIN által akkreditált tanfolyamok elvégzése után nemzetközi vizsgát lehet tenni. Az ITIL Foundation egy 3 napos alapozó tanfolyam, amely egy alapvizsgára jogosít és készít fel, az ITIL Service Management pedig egy 10 napos képzés, amely a vezetői vizsga előfeltétele. Az alapvizsga egy 40 kérdéses választási teszt, ahol 65%-ot kell elérni, a vezetői vizsga kétszer 3 órás írásbeli, a Service Delivery és Service Support témakörökben. A vizsgák egyelőre csak angol nyelven tehetők le, de hazai lebonyolítást megfelelő számú jelentkező esetén meg tudunk szervezni.
Informatikai rendszerek üzemeltetésének auditja
Egy működő informatikai redszernél sokszor felmerül a kérdés, milyen szinten működtetjük, hol tartunk most, hogy a továbblépést, a szolgáltatások javítását megalapozzuk. Előkészítés alatt van egy magyar nyelvű audit kézikönyv, amelynek segítségével kvalitatív értékelést lehet készíteni az üzemeltetés irányítás szinvonaláról. Ez várhatóan 2002 végéig közzétételre kerül az interneten.
Szervezet Felhasználói fórumok (itSMF)
Az ITIL gyorsan elterjedt a kormányzati informatikában és sikeresnek bizonyult a profitorientált szervezeteknél is. A 90-es évek elején létrejött az első felhasználói szervezet, az it Service Management Forum, amely a brit felhasználókat fogta öszsze. Azóta ezek a fórumok az USA-tól Dél-Afrikán át Ausztráliáig sok országban megjelentek és összehangolt munkájuk sokat segített az ITIL elterjedésében, az oktatás és vizsgakövetelmények nemzetközileg egységes szintjének megtartásában. Austriába 2002 májusában jött létreaz osztrák fórum, Magyarországon pedig most indul a szervezés, ez az oldal már ennek jegyében született. Az itSMF ( it Szolgáltatás Menedzsment Fórum) Magyarország egy független, a felhasználók által szervezett és működtetett fórum, amely a korszerű szolgáltatás(működés/üzemeltetés) irányítási ismeretek terjedését, az egységes terminológia megteremtését és az alkalmazási tapasztalatok cseréjét szolgálja és tagja a Nemzetközi Fórumnak.
Nemzetközi Fórumok (itSMF Global)
175
Az itSMF International a nemzeti fórumok munkáját fogja össze, nemzeti fórum már működik Angliában az USA-ban Kanadában, Hollandiában, Dél-Afrikában, Ausztráliában, Belgiumban és Németoszágban és Svájcban. http://www.itsmf.com/
Magyar itSMF szervezése (it Szolgáltatás Menedzsment Fórum Magyarország)
Megkezdődött a magyar itSMF szervezése, ennek egyik lépése ennek az oldalnak a beindítása. A Széchényi terv támogatásával létrehozunk és interneten keresztül közzéteszünk magyar nyelvű áttekintő és összefoglaló anyagokat, egy terminológiai szótárat, néhány esettanulmányt és egy audit kézikönyvet. A fórum iránt érdeklődők e-mail-ben jelentkezhetnek. Év végéig kidolgozzuk a működés alapszabályát. A fórum első konferenciáját 2003 első felében szeretnénk megszervezni.
Oktatás Oktatási és vizsgarendszer
itt hivatkozás a fenti tartalomra
Tanfolyamok
IT Service Management Foundation tanfolyam angol előadóval (Lloyd Robinson, CEC Europe) 2002 október 1-4-ig lesz Budapesten, korlátozott számban még lehet jelentkezni. A 3 napos tanfolyam után, 4-én vizsgát is szerveztünk, amely angol nyelvű, választásos tesztvizsga, a tanfolyam helyszínén az ISEB vizsgabiztos által felügyelve kerül lebonyolításra. Kellőszámú érdeklődő esetén mind az alap, mind a 10 napos vezetői tanfolyam hazai megszervezését biztosítjuk.
Vizsgák
Október 4-én IT Service Managment Foundation Certificate vizsgát szervezünk (ISEB vizsga) Igény esetén, a Foundation tanfolyamot végzettek számára, akik nem vizsgáztak, vagy nem sikerült a vizsgájuk, igény esetén decemberben EXIN vizsgát szervezünk.
Események Konferenciák, rendezvények, szemináriumok
Az idei angol konferencia Brighton-ban lesz Brighton Metropole Hotel 11-13th November 2002 "Creating Stability In A Changing World" http://www.itsmf.com/conference/index.asp
Mi történt eddig, mi várható a közeljövőben?
1996-ban az ITIL első változatát az ITB elfogadja kormányzati ajánlásként 1998-tól megfigyelőként rendszeresen részt veszünk az itSMF International munkájában és az éves konferenciákon. Eddig 4 hazai tanfolyamot és több vizsgát szerveztünk. 2000-ben megjelent az ITIL második, korszerűsített változata
176
2002 végéig a Széchenyi terv támogatásával egy tanulmány keretében nyilvános tájékoztató, és ismeretterjesztő anyagok készülnek és lesznek publikálva az interneten Előkészítjük a magyar nyelvű alapozó oktatást és ha megoldható, a magyar nyelvű vizsga lehetőségét Szeretnénk lefordítani és kiadni az Informatikai Szolgáltatás Menedzsment zsebkönyvet Elkezdtük a hazai felhasználói fórum szervezését
Tudásbázis
Itt szeretnénk hozzáférhetővé tenni mindazokat a szakmai információkat, amelyek segítik a téma iránt érdeklődőket, valamint a tervezés, bevezetés és használat során szerzett tapasztalatokat. Publikált ismeretek Felhasználói tapasztalatok, esettanulmányok Információ Kapcsolattartás
Ha bármilyen kérdése, kérése vagy javaslata van, írjon az alábbi címre:
[email protected]
Regisztráció
Aki szeretne az itSMF tagja lenni, írja meg nekünk: Nevét Munkakörét Telefonszámát e-mail címét Munkahelye nevét Munkahelye címét
Levelező lista
Aki szeretne e-mail értesítést kapni az itSMF híreiről, eseményeiről, az itt kérheti.
177
