HIBAJAVÍTÁS, ÜZEMELTETÉSI FELADATOK TERÜLETÉN OUTSOURCING LEHETŐSÉGEK A HIBAKEZELÉS,

Átírás

1 Vasvári András 72 OUTSOURCING LEHETŐSÉGEK A HIBAKEZELÉS, HIBAJAVÍTÁS, ÜZEMELTETÉSI FELADATOK TERÜLETÉN A Magyar Honvédség különböző szervezeti egységeiben működő különböző rendszereiben jelentkező hibák elhárítására nincs egységes eljárás. Ennek egyenes következményeként a hibaelhárítási folyamatok hatékonysága, illetve a hibaelhárításban résztvevő munkatársak teljesítménye nehezen, vagy egyáltalán nem mérhető, és a folyamat minősége, hatékonysága nem garantálható. A rendszer feladata, hogy vezérelje a hibakezelés teljes életciklusát. Az ITSM rendszer gondolata és módszere igen jól illeszkedik egy szervezet irányítási rendszerébe, mert fő célja az informatika minőségének magasabb szinten tartása és fejlesztése. Magának a rendszer kialakítása mellett ennek egyik lehetséges megoldása az outsourcing. Generally at a military unit there is not any unified methodology or procedure to service and manage faults occurring in different systems. That is the reason why the efficiency of fault managing processes and the performance of the IT personnel can hardly be measured. Therefore the quality and efficiency of the workflow cannot be guarantied. The responsibility of the system is to control the fault management occurring in different IT system during the entire life cycle. The idea and the method of the Trouble Ticketing fits well into the quality control of a company because its main goal is to keep and develop the higher level of the quality of the IT services in the company. The one of the possible solution is the outsourcnig besides the installation the system. 1. TROUBLE TICKETING RENDSZEREK Miért is van szükség, miért is érdeke egy szervezetnek egy egységes, integrált IT Service Management (továbbiakban ITSM) rendszer létrehozására? 72 doktorandusz, ZMNE 169

2 A kérdés megválaszolása amilyen egyszerű egyben olyan bonyolult is. Közhely, hogy manapság a szervezetek számára egyre nélkülözhetetlenebbé válik az informatika. Ez az állítás igaz a katonai szervezetek esetében is. Így az informatikai infrastruktúra üzemeltetése, az informatikai vagyontárgyakkal való gazdálkodás, az üzemeltető szervezet és a felhasználók közötti jó viszony felépítése egyre nagyobb fontosságot nyer. Az informatikai infrastruktúrába beleértjük a szervezetet, a hardver elemeket (a számítógépeket és a hálózatot is), a szoftver elemeket illetve a szoftverrel kapcsolatos telekommunikációt. Nyugodt szívvel kimondhatjuk, hogy a mai számítástechnikára alapozó világ számára, a kapcsolódó informatikai hardver- és szoftvereszközök magas bekerülési és üzemeltetési díja (ld. TCO) miatt nélkülözhetetlen a szervezettség, a kézbentartás megvalósítása. Az informatika és az informatikai vagyontárgyak összessége mára azonban akkora anyagi értéket képvisel, hogy ez az örökzöld téma újra és újra előtérbe kerül, ezáltal elengedhetetlen, hogy pár szóban elemezzük, hogy milyen követelmények és elvárások fogalmazhatok a témával kapcsolatban, azok milyen elvek, módszerek, eljárások alapján elemezhetők. A Magyar Honvédség különböző szervezeti egységeiben működő különböző rendszereiben jelentkező hibák elhárítására nincs egységes eljárás, a hibaelhárítás mögül hiányzik az informatikai háttértámogatás (itt nemcsak a közvetlen irodai, ún. office környezet biztosítására kell gondolni, hanem az összes egyéb háttér-informatikára illetve speciális szoftvercsomagokra is). Ennek egyenes következményeként a hibaelhárítási folyamatok hatékonysága, illetve a hibaelhárításban résztvevő munkatársak teljesítménye nehezen, vagy egyáltalán nem mérhető, és a folyamat minősége, hatékonysága nem garantálható. Egy ITSM rendszer feladata, hogy a különböző informatikai rendszerekben felmerülő hardver, szoftver, hálózati vagy egyéb jellegű hibákat a rendszer felhasználói rögzíteni tudják, a hibákra egy folyamatosan bővülő tudásbázis alapján önállóan, s így tulajdonképpen költségmentesen megoldást találjanak, illetve amennyiben a tudásbázisban az adott problémára nem létezik megoldás a hibát továbbítani tudják a szakértői csoporthoz, ahol a hiba elhárítását elvégzik. 170

3 Egy ITSM rendszernek támogatnia kell a szervezet alkalmazottainak infrastruktúrával való ellátását a különféle IT eszközök beszerzésétől kezdve azok raktározásán, elosztásán keresztül azoknak a folyamatokból való kikerüléséig, mint például a selejtezéséig. Támogatnia kell a különböző beszállítók és szervizek általi naprakész eszközforgalmat. Mindezek mellett azok hibaelhárítási folyamatainak vezérlését, felügyeletét, biztosítva, hogy a napi munkavégzéshez szükséges megfelelő minőségű, mennyiségű stb. infrastruktúra a rendelkezésre álljon. Ezen valamint a későbbiekben vázolt elveknek megfelelő rendszer kétféleképpen kerülhet megvalósításra, bevezetésre: o a jelenlegi működési folyamatokat, szabályrendszereket szabják testre, és erre a formára gyúrják át az adott rendszert. előny: a szervezet struktúráját nem kell átalakítani; a szervezet működési folyamatait nem vagy csak kis mértékben kell átalakítani; az teljesen egyedi igények is kielégítésre kerülhetnek. hátrány: könnyen az...eddigi is megvoltunk, eddig is működtünk valahogy... hibába eshetünk; az egyedi igények lefedése mindig jóval nagyobb erőforráslekötést igényel gondolhatunk itt a klasszikus fejlesztés erőforrás háromszögére, melynek csúcsaiban rendre az idő, igény, költség helyezkednek el (néha 3. dimenziósítva megjelenik, mint 4. csúcs a minőség is), azaz egyszerű szavakkal megfogalmazva az egyiken csak a másik rovására spórolhatunk. o az elvileg jól megtervezett, általános piaci trendeknek, elvárásoknak megfelelően kialakított ún. out-of-the box rendszert alkalmaznak, és az általa megszabottaknak megfelelően alakítják át a vállalat belső működési folyamatait, szabályzatát. 171

4 előny: gyors implementációs időigény (nincs vagy jóval rövidebb tervezési szakasz, nincs hosszú fejlesztési szakasz); kipróbált, bevált folyamatmodellezés, folyamatkezelés; a Megrendelő előre látja, hogy mit vesz. hátrány: a szervezet struktúráját általában át kell alakítani (akár teljesen új szervezeti egység létrehozása, pl. HelpDesk); a szervezet működési folyamatait általában át kell alakítani (ld. előző pont, tehát új szervezeti egységgel értelemszerűen új folyamatelemek, tevékenységek, résztvevők lépnek be a folyamatba); az teljesen egyedi igények kielégítése könnyen nehézkes és/vagy költséges lehet. Mindenképpen fontos az alábbi rövid összefoglalás (amelyet a későbbi 10 parancsolatban teljesedik ki), mely megmutatja melyek az alapvető, egy ilyen rendszerrel szemben támasztott célok, sikerkritériumok: o növelje az ügyfél -elégedettséget (pl. a bejelentőknek csak egy központi telefonszámot kell ismerniük; mindig tudják, hogy milyen állapotban van a bejelentésük; ismerik, hogy milyen határidőre várható megoldás a problémára); o tehermentesítse a második és harmadik vonalban működő hibaelhárítókat; o a rendszer vezérelje és felügyelje automatikusan a hibaelhárítást a folyamat teljes életciklusán keresztül; o biztosítsa a rendszerben keletkező információk szétosztását; o támogassa a felhasználók által generált különféle igények kielégítését; o a tudásbázis folyamatos bővülésén keresztül növelje az elsőlépcsős (azaz szinte költségmentes) hibaelhárítás arányát; 172

5 o teremtse meg a statisztikai kimutatások értékelésén keresztül a folyamatelemzés, a teljesítmény- és rendelkezésre állás mérésének lehetőségét, a folyamatok minőségbiztosítását; o legyen alkalmas különböző minőségi mérésekre, illetve az ezekhez szükséges információk emészthető formában kinyerésére. Szolgáltasson klasszikus statisztikai kimutatásokat (hibakategóriák, hibatípusok, hibák eloszlása, KPI stb.) és készítsen összefoglaló jelentéseket, amelyekkel különböző rendszerek, osztályok működési minősége ellenőrizhető és értékelhető; o tartsa nyilván a szervezet eszközelemeit (kinek és milyen hardver, szoftver stb. eszköz van a birtokában); o támogassa a hardver és szoftver eszközök logisztikai folyamatainak kezelését; o IT eszközök raktárkezelése, nyilvántartása vagy kapcsolódás, integrálódás az adott funkció(ka)t ellátó rendszerhez. Ezen rendszerek a mindennapi tapasztalatok szerint általában háromszintűek: o az első szint az új HelpDesk szervezet, itt történik majd a bejelentések (hibák, igények fogadása) illetve megoldása; o a második szintet a különböző IT-t támogató részlegek alkotják, ők válaszolják meg azokat a bejelentéseket, amelyeket; a HelpDesk csoportnak nem sikerült; o a harmadik szintet pedig végrehajtás szakértői képviselik. Természetesen ettől mindkét irányban el lehet térni. Alapvetően ez például nagyban függ attól, hogy milyen színtű képzettséggel rendelkezik az első szint (illetve mi a cél. Itt is eltérnek a vélemények hiszen egy képzettebb első vonal jobban tehermentesíti a második vonalat, viszont ehhez képzettebbnek kell lennie, ami pedig tudás és ezáltal költség szinten már közelít a második vonalhoz, tehát visszatértünk a kiinduló ponthoz). Mekkora lehet az egyes szintek szervezeti mérete stb. 173

6 A már említett célok 10 parancsolata részleteiben a következő lehet: [1] 1. Rendelkezésre-állás növelése: A rendelkezésre állás azt jelenti, hogy két meghibásodás között minél nagyobb legyen az időintervallum. Hányszor hallottuk már a következő párbeszédet: Én szóltam, üzentem Nektek, hogy rossz a gépem - mondja az egyik fél. De Én nem kaptam meg az üzeneted - védekezik a másik oldal. Egy ITSM rendszerrel az elveszett bejelentések elkerülhetők, a hibákra a lehető leggyorsabban reagálhatunk. Az SLA-k (Service Level Agreement, ld. később) nyilvántartása abban az esetben is fontos, ha meghatározott hibaesemények elhárítását meghatározott határidőn belül meg kell kezdeni illetve meg kell oldani. Természetesen mindemellett elengedhetetlen, hogy azon alapvető funkciókat, amelyek fentebb összefoglalásra kerültek a rendszer maradéktalanul elégítse ki. Azaz minden hibaesemény és azokkal kapcsolatos tevékenység rögzítésre, rendszerezésre kerüljön (mikor, mivel, mi történt), amelyről illetve annak állapotáról, állapotváltozásáról vagy nem változásáról a kellő szabályrendszer definiálásával értesítéseket küldjön, s mindemellett maga a felhasználó folyamatosan tudja, hogy mi történik a problémájával, éppen milyen státuszban van (minimális státuszigények: Új, Folyamatban, Elutasítva, Függőben, Átadva, Megoldva, Lezárva). Ld. még nyomonkövethetőség. 2. Belső elégedettség növelése A gyorsabb hibaelhárítási folyamat eredménye, hogy munkatársaink elégedettebbek, zavartalanabbul fogják tudni végezni munkájukat. Ha létezik egy központi Helpdesk, akkor nem kell még azt is nyomozgatniuk, hogy mikor, milyen problémával kihez kell fordulniuk. Tehát az ad-hoc, egyéni kreativitás szerint működő szervezet összehangolt szabályok szerint működik. (Elkerülve azt, hogy aki netán véletlenül tudja, vagy kinyomozza, hogy ki az illetékes az ügyben az jobb helyzetben van, aki esetleg még ismeri is és jóban is van az illetékessel annak pedig még jobb). A hibakezelés és hibajavítás egyértelműen a lefektetett szabályok szerint kerül lekezelésre, pl.: keletkezési idő, prioritás, súlyosság stb. 174

7 3. Munka hatékonyságának elősegítése Az információ megfelelő áramlásával a hibákat gyorsabban ki lehet küszöbölni, csupán egy Helpdeskre van szükség, amely kontrollálja a hibajavítási folyamatokat, és munkájával az egész vállalat életét megkönnyítheti. Ő az, aki tudja, hogy milyen incidens, mikor, kihez tartozik. Ezen kívül nagyon fontos paraméter, hogy a 2. vagy 3. szinten elhelyezkedő szakértőkhöz csak az a probléma jut el, ami ténylegesen hozzá tartozik, illetve az elsődleges szűréseket illetve diagnózisokat a Helpdesk már megtette. Ahogy az már korábban elhangzott itt rendkívüli fontosságú a az első szint képzettségi foka. Meg kell találni az egészséges egyensúlyt a feladat súlya és az elvárható kiképzettségi szint között figyelembe véve a már korábban feszegetett paradoxont. Meghatározható egy bonyolultsági mátrix, hogy mely az a probléma, amivel elviekben mindenképpen az első szintnek kell megbirkóznia, mely az, amelyik mindenképpen szakértői illetékességű. Ezek természetesen kiképzésekkel illetve tudásmenedzsmenttel idővel revidiálandó. Nem kevésbé fontos kiegészítés a témában, hogy kiegészíthető a rendszer egy nevezzük erőforrás-rendelkezésre-állási mátrix-szal is, azaz ki, miben illetékes és persze mikor dolgozik (napi 8 óra, 24/72 stb.), plusz milyen a leterheltsége (már vagy 20 hibajegyet rendeltek hozzá csak azért, mert ő az első a névsorban, míg más lógatja a lábát ). 4. Költséghatékonyság A hibaelhárítás hagyományos kézi (informatikai rendszer által nem támogatott) vezérlése már nem lehet hatékony, mert vagy sok embert kell alkalmazni, amely így költségigényes, vagy kevés ember alkalmazásával csak a túlórázásra marad idő. A rendelkezésre álló pénzeszközöket a Helpdesk csoport segítségével a lehető legjobban használhatjuk ki, mely azt jelenti, hogy a kvázi értékesebb szakértői gárdát tehermentesítjük. Könnyen elképzelhető, hogy például egy egyszerű levelezőrendszeri leállás alkalmával (pl.: diszktelitettség miatt, amit egyébként sokkal célszerűbb megelőzni egy menedzsment rendszerben történő figyelő-riasztó beállítással) mennyien is próbálják zaklatni közvetlenül a rendszergazdát (nevezzük tömeghisztériának), ekkor az első vonal akár 50%-nyi munkaidő-pazarlást is megmenthet a szakértő drága idejéből. 175

8 5. Nyomonkövethetőség A számítógép használóknak áttekinthető és egyértelmű tájékoztatást és biztonságot nyújt, hogy a felmerült problémával ki és milyen módon fog foglalkozni, mikor és hogyan oldódik az meg. A hibákat a felmerülésüktől az elhárításig követni lehet a rendszerben (ld. 1-es pont). 6. Dokumentáltság A bejelentések bármikor visszakereshetők. A döntéshozóknak a rendszer segít felderíteni a tipikus hibapontokat, az összegyűjtött adatok alapján összevont statisztikák alapján a vezetés számára egyértelműen látható, hogy mikor, mire kellett pénzeszközöket fordítani. Információt nyújt a beszállítók, külső szervizcégek munkájának objektív minőségéről, mely által biztosítható az igénybevett szolgáltatások állandó magas szinten tartása. A rendszer segíti a belső erőforrások hatékonyabb kihasználását. Mérhetővé teszi a rendszert (különböző statisztikák révén riportolható, hogy ki, mikor mennyit dolgozott; a hibaelhárítási folyamatok eleget tudnak-e tenni az adott szervezet által megszabott ún. KPI (Key Performance Indicator) mutatónak (ilyen lehet pl. a nyitott incidensek száma egy dolgozóra nézve) ld. később. A rendszer számára tanulási funkciót tesz lehetővé: javító, helyesbítő tevékenységet lehet kezdeményezni. 7. Mérhetőség Mérhetővé válik az információs rendszer rendelkezésre állásának legfontosabb paraméterei, mint az üzembe helyezés ideje, vagy a javítás ideje, felbontva azok okaira, mint várakozási idő, hibaelhárítások és karbantartások száma és az azokra fordított idő. Ez nagyon fontos kérdés, hiszen mindamellett, hogy egy rendszernek természetesen az a legfontosabb feladata, hogy vezérelje, s így támogassa a szervezet alapfeladatának elvégzéséhez szükséges informatikai eszközök naprakészentartását, a másik kritériuma, hogy mérhető és elemezhető információkat szolgáltasson. Csak ez utóbbi által érhető az el, hogy meghatározhatók legyenek a szűk keresztmetszetek, a fejlesztendő területek. 176

9 Természetesen, ahhoz hogy megállapítható legyen a jó munka meg kell határozni az elvárt szintet (viszonyítási alapot), mérni kell a tényadatokat, összehasonlítást kell végezni, a megfelelő konzekvenciákat levonni és ha kell beavatkozni (ez egy klasszikus szabályozó körnek tűnik?!) 8. Támogatja a minőségirányítási eljárásokat Továbbfejlesztve az előző gondolatot kimondható, hogy a minőségbiztosítási mérőszámok szolgáltatása az egyik leglényegesebb összetevő a vezetés számára. Az ITSM rendszer gondolata és módszere igen jól illeszkedik egy szervezet irányítási rendszerébe, mert fő célja az informatika minőségének magasabb szinten tartása és fejlesztése. A rendszer kimenő adatai akár ISO dokumentumként szolgálhatnak, például az alvállalkozók minősítésénél, a képzési igények felmérésénél. A dokumentáltság és a nyomonkövethetőség játsza a főszerepet a minőségirányítás témakörben is. 9. TCO számítás segítése Az információs technológia infrastruktúra teljes birtoklási költségének (TCO-nak) közel 50%-t teszik ki az üzemeltetési és a fenntartási költségek. Ez alapján megállapíthatjuk, hogy a Helpdesk munkája nagyon fontos. Ennek részleteiről külön fejezetben (ld. TCO) térnék ki. 10. Tudásmenedzsment Egy központi, dinamikusan bővülő tudásbázis létrehozásával és használatával elősegíthető, hogy akár maguk a felhasználók meg tudják saját maguk oldani a felmerült problémákat (természetesen megfelelő jogosultsági illetve hozzáférési rendszer kialakításával). Így megvalósul tulajdonképpen a 0. szint mivel ezáltal sok esetben a probléma akár el sem jut a bejelentésig. Mindemellett maguk a szakértők is nagy segítséghez jutnak azáltal, hogy egy a múltban már felmerült hiba megoldása így könnyebbé, egyszerűbbé válik. A tudásbázis létrehozása igazán úgy értékes, ha minimum valami alapvető önfejlesztő, tanulási automatizmus is beépítésre kerül. Ez azt jelentheti pl., amennyiben egy megoldás születik, akkor a rendszer észlelheti, hogy ez egy az adott problémára még nem létező új megoldás, amelyet megfelelő kérésre (félautomatikusan) vagy automatikusan feltölt, kiegészít a tudásbázis megfelelő részébe. 177

10 A tudásbázis tervezése kulcskérdés, mivel egyrészről ez nagyban segíti a későbbi munkát, így nagy jelentőségű, másrészről viszont az alapséma csak igazán nehézkesen (így költségesen) alakítható át később. Ezzel szemben mentségére legyen mondva, hogy a megoldáskeresés elősegítésére a hibajegykezelés szerkezetét kell követnie, azaz ha a tudásbázis szerkezét át akarjuk alakítani, az azt jelenti, hogy tulajdonképpen az alapséma is módosítandó. 2. ITIL KÖVETELMÉNYEK A fent említett célokat, célkitűzéseket, alapkövetelményeket különféle szabványok, szabványosítási próbálkozások is alátámasztják. Így az ún. stakeholderek is nagyobb garanciát kaphatnak arra, hogy a releváns logisztikai M-elveknek megfelelő termék kerüljön a birtokukba. Jelenleg Magyarországon az Informatikai Tárcaközi Bizottság ajánlása alapján a módszertan az iparági legjobb gyakorlatra - pontosabban az Európában ma már igen elterjedt az ITIL-re támaszkodik, amely ajánlás a brit Information Technology Infrastructure Library (ITIL) [2] sorozat releváns kötetei. Az ITIL tulajdonképpen gyűjtemény az informatikai üzemeltetés legjobb gyakorlatából. Az iparági tapasztalatok alapján az ITIL összetett és összehangolt ajánlásban fogalmazza meg, miként is kellene egy informatikai szervezetnek működnie, milyen folyamatokat és hogyan kell kialakítania ahhoz, hogy a lehető leghatékonyabb legyen az informatikai szolgáltatások üzemeltetése. Az ITIL a következő fő területeket különbözteti meg (természetesen nem térnék ki a részletekre, hiszen az a kötetekből kiolvasható, kigyűjthető, mely e mű korlátozott terjedelme miatt sem tehető meg): 1. Rendszerszintű követelmények; 2. Biztonsági követelmények; 3. Felhasználói felülettel kapcsolatos követelmények; 4. Konfigurációkezelés; 5. Helpdesk; 6. eseménykezelés; 7. Problémakezelés; 8. Változáskezelés; 178

11 9. Szoftverfelügyelet és terítés; 10. Szolgáltatásszint-kezelés (SLA); 11. Katasztrófaelhárítás-tervezés; 12. Kapacitásfelügyelet; 13. IT-költségkezelés; 14. Rendelkezésreállás-felügyelet ÉRETTSÉGI MODELL Az érettségi modell az adott szervezet IT-szolgáltatás-felügyeleti folyamatait hasonlítja össze az ITIL által meghatározott folyamatokkal. Ha ez vagy az a terület megfelel az ITIL ajánlásainak, akkor azt a modell tökéletesen érettnek tekinti. [3] A modellben minden fő területet öt szempont szerint kell megvizsgálni: a folyamatok, a szervezet, az automatizálás foka, az integráltság más fő folyamatokkal, valamint az alkalmazott mérőszámok aéapján. A különféle szempontok értékelésében a modell meghatározza a vizsgálandó tartalmi elemeket, azok fontosságát, illetve az elemek közötti összefüggéseket. Valamely terület érettségét az öt szempont súlyozott értékelésével kapjuk meg - a különféle szempontok súlya persze területenként más és más lehet. A szolgáltatásfelügyelet vizsgálatát a gyakorlatban elvégezni talán nem is olyan nehéz feladat. A modellhez tartozik egy kérdéslista, s azzal valamennyi fő területen feltérképezhetők az említett értékelési szempontok. Ha a válaszokat (a kérdésekre a szubjektív értékelés elkerülésére csak igennel vagy nemmel lehet válaszolni) behelyettesítjük a modellbe, akkor automatikusan kiadódik az eredmény. Az ITIL szerinti érettség vizsgálata azonban csak az első lépés a leginkább fejlesztendő területek kiválasztásában. A következő feladat annak a meghatározása, hogy egy-egy területnek mekkora a megtakarítási potenciálja. Erre felhasználható a későbbiekben ismertetett módszer (ld. TCO), mely szerint tételesen meg kell határozni, hogy mennyibe kerül a kérdéses területet az ITIL-ajánlásoknak megfelelő szintre fejleszteni, és meg kell határozni azt is, hogy ebből mekkora üzleti érték származik. 179

12 3. INFORMÁCIÓMEGOSZTÁS A VIRTUÁLIS ELLÁTÁSI LÁNCBAN Napjainkban megfigyelhető, hogy például a civil szférában a sikeres szervezetek annak érdekében, hogy gyorsabbak, rugalmasabbak ezáltal reakcióképesebbek legyenek a specifikus vevői/felhasználói igényekre szervezik át ellátási láncukat. A lineáris, szekvenciális ellátási lánc felöl a dinamikus, adaptív virtuális modellek felé mozdulnak el. Miért lenne ez másként az MH-ben is? Az ellátási lánc automatizálása elemzéssel kezdődik, az elemzés fókusza azonban az üzleti egység helyett a teljes ellátási lánc (beleértve pl. a beszállítókat). Az ellátási lánc menedzsmentje három folyamatot anyagi, információs és pénzügyi igyekszik összehangolni, optimalizálni. A cél az, hogy különböző szervezetek illetve szervezeti egységek összehangolják erőfeszítéseiket a hagyományos tranzakció alapú együttműködés helyett teret adva egy olyan partnerségnek, amelyben az információ, a folyamatok, a döntések és az erőforrások megosztottak az ellátási láncon belül. [4] Az információtechnológia fejlődése változást hozott az ellátási lánc menedzsmentjében, hiszen az Internet elterjedése lehetővé teszi a széles körű információ-megosztást komplex ellátási láncokon keresztül, létrehozva ezzel a különböző egységek virtuális logisztikai kapcsolatát. Az ITSM rendszer(ek)nek éppen ezen komplex ellátási lánc egy szeletét kell megvalósítani azon keresztül, hogy támogatja a mindennapi munkafolyamatokat, és naprakész információval látja el a menedzsmentet illetve beintegrálódik a központi Supply Chain Exchange rendszerbe, így alapjául szolgál az együttes igénytervezés, ellátástervezés és készlettervezés egy bizonyos adatkörének. [5] 4. NÉHÁNY SZÓ A KAPCSOLÓDÓ MINŐSÉGBIZTOSÍTÁSI MÉRŐSZÁMOKRÓL Általános megállapítás, hogy a teljesítmény már attól javulni fog, hogy elkezdjük mérni. Sokszor csak az a tény, hogy mindenki tudatában van a teljesítmény mérésének, a teljesítmény javulásához vezet, még ha számszerűsített célokat nem is fogalmaztunk meg. 180

13 Közismert példával élve a fogyókúra azzal kezdődik, hogy ráállunk a mérlegre, azaz elkezdjük a mérést! Még ha nem is tűztük ki magunkban az elérendő testsúlyt, a rendszeres mérés elindít egy kontrollt. Ez teljes mértékben igaz a szervezetekre is SLA Az SLA, azaz a Szolgáltatói Szintű Leírás egy olyan okmány, mely az ügyfelek által használt szolgáltatások elvárható minőségi szintjét biztosítja. [6] A ITSM követelményei közt kiemelt fontosságot igényel az az elvárás, hogy a rendszer támogassa az SLA használatot, szolgáljon sokféle mérési mutatóval, mely a meghatározott SLA-k teljesítésének ellenőrzését teszi lehetővé. Egy hatékonyan működő, informatív és teljes körű SLA rendszer kialakítása mely minden osztály, személy, ügy és körülmény esetén garantálja a megfelelő szolgáltatási minőséget egy nagyon fontos, de ugyanakkor hatalmas feladat. A rendszer által támogatott SLA-k a következő részekből t e- vődnek össze: o SLA típusa és időtartama (kapcsolódó típus, fajta, vállalási idő) o SLA-hoz kapcsolódó műveletek (értesítendő személy azonosítója, értesítés időpontja, értesítési mód) o SLA-k keletkeztetése (Itt olyan kérdésekre kapunk választ, mint mely osztályokat, ezen belül milyen alrendszereket érint; mely hibakategóriák esetén lép érvénybe; milyen feltételek mellett számolandó a ráfordítási idő; mennyi az egyes esetekre fordított idő; mennyi idő lejárta után szükséges további műveletek végrehajtása; milyen műveletek hajtandók végre, ha az SLA-ban foglalt idő lejárt: eszkalációk, értesítések) o SLA riportok (ide tartozik a tulajdonképpeni mérés, azaz ezen jelentések alapján ellenőrizhető, hogy a meghatározott szint és a tényleges szint milyen irányban tér el, ha eltér. 181

14 Ha negatívban, akkor elvileg minden rendben, esetleg megvizsgálandó, hogy a minőségi szintemelkedés érhető-e el annak szigorításával (bár itt általában a már aláírt szerződésekről van szó, de annak lejáratára már rendelkezésünkre állhat egy ilyen elemzés, vagy akár annak plusz költséggel járó módosítása is megérheti?!), ha pedig pozitív irányban tér el, akkor azt mindenképpen szankcionálni, ellenintézkedni kell. Az SLA mérése egyik legfontosabb kérdés egy szervezet életében, hiszen ahogy az említésre került az előzőekben ez határozza meg a minőségi elvárásoknak való megfelelést. Mindazonáltal sokkal fontosabbnak és sokkal nehezebb feladatnak tartom az SLA szintek megtervezését, meghatározását. Ez az egyik kulcskérdés, melyre (többek között) a legtöbb energiát kell fektetni (legalábbis, ami a minőségbiztosítást illeti ezen a területen) KPI A KPI egy angol mozaikszó, mely a Key Performance Indicator rövidítése. Magyarra talán Kulcs Teljesítmény Mutatónak lehetne legjobban lefordítani. A KPI egy mutatószám, amely egy folyamat vagy annak egyik lépésének teljesítményét méri. A logisztikát, mint az anyag- és információáramlás folyamatát tekintve, számtalan olyan részfolyamatot vagy kulcslépést találhatunk, ahol a teljesítmény valamint annak mérése rendkívül fontos az elért minőség megítéléséhez és annak javításához. Esetünkben ilyen pl. az egy hibaelhárítóra eső nyitott hibajegyek száma, amely például nem haladhat meg egy bizonyos értéket, mondjuk 0,2-t. [7] A KPI ilyen értelemben a logisztikai folyamatok kontrolljának egyik fontos eszköze. A számszerűsített teljesítmény mutató időbeli alakulását követve megállapítható, hogy az adott lépés, illetve az azért felelős szervezeti egység teljesítménye az elvárásoknak megfelelően alakulte, szükség van-e beavatkozásra, realisztikusak-e a kitűzött célok? A célok reális megállapítása és azok ismertetése a partnerekkel, a felelős kollégákkal pozitív kihívást jelent. A KPI-k használata azért célszerű, mert méri a folyamat hatékonyságát; 182

15 figyelmeztet a beavatkozás szükségességére; objektívabb értékelést biztosít; visszacsatolás, ösztönzés a szállítók, partnerek és munkatársak felé. A különböző KPI-knál nem lehet megadni általánoson elfogadható abszolút célértéket. Sokkal inkább az egyes KPI-k időbeli alakulását kell figyelni, mert egy mutató nagyfokú ingadozása a mért folyamat bizonytalanságára, míg egy időben romló teljesítmény a beavatkozás szükségességére figyelmeztet. A KPI objektívabb értékelésre ad lehetőséget. A tényeken alapuló, számszerűsített adatokon nem nagyon lehet vitatkozni, ezek objektivitását nehéz megkérdőjelezni. Az objektív értékelés pedig már önmagában motivációs eszköz a partnerek, munkatársak felé. 5. OUTSOURCING Miután felvázolásra került az az informatikai terület, melyet támogatni, hatékonyan működtetni szeretnénk, lássuk hogy a logisztika területén milyen lehetőség(ek) kínálkozik(nak) az adott követelmény kielégítésére ELŐZMÉNYEK Az üzleti folyamatok változásának tendenciái Az elmúlt három évtizedben a vállatok üzleti folyamataiban alapvető változások következtek be. A globalizáció - mely egyszerre volt oka és következménye az információ technológia és kommunikáció kölcsönhatásának, - felgyorsította a gazdasági folyamatokat. Az üzleti élet ciklusai folyamatosan rövidülnek, és ez a tendencia gyorsulóban van jelenleg is. Az 1970-es, nyolcvanas évekre jellemző 7 éves üzlet ciklusok a 90-es évekre hónapra rövidültek. A tendencia további rövidülést mutat, mely akár kvartereket, negyedéves ciklusokat is jelenthet. [8] A gazdasági folyamatot és az abba való beavatkozást szabályozott rendszernek tekintve elméletileg is bizonyított, hogy a rendszer stabilitása nem csak a beavatkozás nagyságától, de az eltérés észlelése és a beavatkozás közötti fáziskésleltetéstől is függ. 183

16 Ez azt jeleneti, hogy akár a nem megfelelő mértékű, vagy fázisú beavatkozás az üzleti folyamat labilitását eredményezheti. A gazdasági folyamatoknak ez a sajátossága az információ pontossága és adekvátsága iránti igényt nagymértékben megnövelte A logisztikai folyamatok változásai A 80-as évektől a fokozódó piaci verseny a termelő vállatokat a költségei csökkentésére kényszerítette. Ez rendkívül nagymértékben felértékelte a logisztikát. Az logisztikai ellátási lánc összekapcsolta a beszerzéstől az értékesítésig a termelőt, a forgalmazót és a fogyasztót. A globalizáció elterjedésével a logisztika elmélete kibővítésre került a bővített ellátási lánc modelljével, amely alapján már figyelembe lehet venni a korábban külsőnek tartott olyan elemeket is, mint az informatika. [9] A költségcsökkentés egyik fontos eszközévé vált az outsourcing, vagy tevékenység kihelyezés. Ez azt jelentette, hogy a vállalatok a fő tevékenységükre koncentráltak, és a kiegészítő tevékenységüket erre specializálódott partnerükre bízták OUTSOURCING MEGHATÁROZÁSA A magyarul leginkább erőforrás-kihelyezésnek nevezett eljárás lényege, hogy a cég bizonyos folyamatait külső szolgáltató vállalkozásokra bizza. Így fő tevékenységére az ún. core competency-re tud koncentrálni, miközben a szolgáltató elvégzi az egyéb feladatait. Mindezeket remélhetőleg jobban, gyorsabban, hatékonyabban, mint azt a megbízó tenné. Legyen az ember egy nagy- vagy egy középvállalat (alegység) élén, előbb-utóbb megkerülhetetlen annak vizsgálata, hogy nem kellene-e bizonyos tevékenységeket a cégen kívülre helyezni. A vezetés gyakran az informatikai tevékenységek részleges vagy teljes kihelyezésétől vár javulást többnyire az alábbi célok szem előtt tartásával: [10] o költségcsökkentés; 184

17 o a szolgáltatási szint javítása; o a költséghatékonyság növelése; o a rugalmasság növelése; o a likviditási és cash-flow pozíció javítása; o a szoftver és hardver eszközállomány nyilvántartásának javítása. Öt-hét év a ciklus Egyes tapasztalatok illetve tanulmányok szerint várhatóan a fenti célok közül csak egy-kettőnél számíthatunk egyidejű jelentős javulásra, attól függően, hogy a kihelyezési folyamat mire optimalizál. Ennek ellenére véleményem szerint e tanulmány ITSM témáján haladva láthatóvá válik, hogy igenis az összes szempontra kihatással van/lehet, persze annak mértéke más és más. Ugyanakkor feltétlenül szem előtt tartandó, hogy a változások nem egyik pillanatról a másikra következnek be éppen ezért nem véletlen, hogy általában egy stratégiai informatikai kihelyezési szerződés sokszor 5-7 éves időszakot ölel át OUTSOURCING BÁZISA Sikertényező A kihelyezett funkciók működésének sikerességét a kihelyezési folyamatnak kell biztosítania. Ezért nagyon fontos, hogy nem érdemes idejekorán erőltetni az erre vonatkozó megtérülési és egyéb üzleti kimutatásokat, hiszen ebben a korai fázisban nem fognak realisztikus képet kapni. Sokkal fontosabb, hogy a korábban már stakeholder-eknek nevezett, üzleti igényeket meghatározók azokat a sikertényezőket tartsák szem előtt, amelyek magát az outsourcing folyamatot teszik eredményessé. Ezek közül az alábbiak tekinthetők fontosnak: [10] o Pontos projektcélok lefektetése. o A szükséges hozzáférés a szervezethez. o Megfelelő kommunikációs, eszkalációs folyamatok. o Független tanácsadói szervezet, outsourcing szakértelemmel. o Minden felmerülő probléma tudatos kezelése. o Az O/S szakértelem átvétele a kezdetektől. 185

18 o Erőforrások folyamatos biztosítása. Ahogy magának a már kész folyamat mérésének fontossága hangsúlyozásra került, nem kevésbé fontos, hogy néhány gondolatban vázoljam, hogy milyen feladatok, nehézségek állnak előttünk ahhoz, hogy a mai magyar informatikai kihelyezési kínálatból kiválasszuk a számunkra megfelelőt (feltételezve, hogy az képes biztosítani a megfelelő szolgáltatási színvonalat). Sokan egyszerűsítik az outsourcing előkészítési folyamatát a szolgáltató körültekintő kiválasztására, holott ez a fajta projekt abban is speciális, hogy a szelekciós folyamat megkezdése előtt felelősségteljes és nemegyszer költséges feladatokat hárít a menedzsmentre Tapasztalatok merítése Vállalatvezetők kérdezik egymástól, hogy ez vagy az a szolgáltató hogyan dolgozik meg vannak-e elégedve vele, beváltotta-e a hozzá fűzött reményeket. A válaszokat azonban sokszor befolyásolhatják, eltorzíthatják a szubjektív vélemények. Javasolható, hogy a tapasztalatgyűjtés kivitelezése minél több forrásból történjen párhuzamosan azzal, hogy meg kell próbálni kideríteni, hogy mi volt a kihelyezési projekt eredeti mozgatórugója, hiszen igazából ezen információk alapján kaphatunk a valósághoz közelibb eredményt vagy inkább a saját döntésünket elősegítő inputot Az előkészítés hangsúlya Az outsourcing szakirodalma abban egységes, hogy sikertényezőként a kihelyezési folyamat előkészítését teszi az első helyre [11]. Kézenfekvőnek tűnhet, hogy a vállalat vezetése a kihelyezési folyamat irányítását annak a kezébe adja, aki a leginkább szeretné a projekt minél korábbi beindítását, függetlenül attól, hogy az adott munkatárs rendelkezik-e elég ismerettel ezen a területen. Azonban fontos, hogy az ezen irányú tapasztalatok is rendelkezésre álljanak. Nagyon fontos, hogy a folyamat vállalaton belüli menedzselését olyan vezetőkre bízzák, akik a javításra kijelölt területért felelnek. Ez nem feltétlenül egyezik csak azzal a területtel, amelyre a kihelyezés kiterjed. A kihelyezési folyamatba a kezdetektől be kell vonni a humán erőforrás, jogi, és pénzügyi területek szakértőit is. 186

19 Azt hiszem, nem kell részletesen ecsetelni, hogy a pénzügy közreműködése nélkül nehéz lenne költségelemzéseket végezni. A jogi osztály nélkül nehéz szerződésterveket készíteni főleg, ha arra gondolunk, hogy egy hosszútávú szerződés esetén (márpedig, ahogy az említésre került egy IT-Outsourcing az az) rendkívüli jelentőségű, hogy milyen lehetőségek nyílnak a szolgáltatás megkezdése után a megállapodások újratárgyalására, ha a vállalatnál jelentős változások állnak be ld. pl. egy fúzió, akvizíció, - vagy milyen árakon hajtja végre a szolgáltató az előre be nem tervezett munkákat. HR szerepe többek között ott kap fontos szerepet, amikor különböző kollektív problémákat kell megoldani. Ilyen lehet, amikor a hatékonyság növelésének egyik megkerülhetetlen eszköze, hogy kevesebb emberrel kell megoldani ugyanazt a feladatkört, ilyenkor a lehetőségek szerint érdemes minden emberről gondoskodni, pl. áthelyezéssel, átképzéssel Célok rangsora Sikerre csak azok számíthatnak, akik gondoskodnak arról, hogy a célokat rangsorolják, veszik a fáradtságot, hogy kendőzetlenül feltárják a jelenlegi működési folyamatokat, és készek meghozni a szükséges döntéseket. A helyzetfelmérésnek ki kell térnie az eszközök, erőforrások és folyamatok feltárásán túl azokra a szerződéses (például: licenc-, karbantartási, jelentési kötelezettségek stb.) elemekre is, amelyek a jelenlegi működés kereteit adják. Ha a feltáró munka során kiderül, hogy bizonyos elemek (licencek, eszközök, stb.) vagy mérési folyamatok (SLA-k, teljesítményadatok) hiányoznak, azok pótlását már a kihelyezési folyamattal párhuzamosan érdemes megkezdeni. A hatékonyságnövekedés fontos alapeleme, hogy a szolgáltató által működtetett folyamatok tökéletesen szabályozottak. Ennek köszönhetően a megbízó saját alaptevékenységeire összpontosíthat, nincs szüksége arra, hogy olyan területeken is komoly szakértelmet és erőforrásokat halmozzon fel, amik nem tartoznak szorosan tevékenységi körébe. Az alábbi táblázat mutatja, hogy jelenleg a világon milyen arányban alkalmaznak IT-outsourcing-ot: 187

20 Az Outsourcing főbb területei az összes kihelyezés arányában (%) Üzleti folyamat Egyedi alkalmazások Alkalmazások karbantartása Hálózatfelügyelet Help desk Alkalmazásfejlesztés Adatközpont 4,3 8,7 6,9 7,4 13,0 15,5 14,8 17,4 17,2 17,3 12,1 14,8 10,3 8,6 8,7 17,2 14,8 21,7 20,7 22,2 USAN kívül USA-ban A világon 26, ábra Esetünkben ez azt jelenti, hogy a HelpDesk területén még van mit fejlődni, hiszen ez az egyik legkevésbé lefedett terület mindamellett, hogy amint látható volt rendkívül jól definiálható folyamatokkal, résztvevőkkel, mérhető paraméterekkel rendelkezik, ami pedig elengedhetetlen alapfeltétele annak, hogy a vázolt előkészítő munkát elvégezhessük OUTSOURCING ALKALMAZÁSA Az informatikai outsourcing szolgáltatásoknál a vállalatoknak legfőképpen azt kell eldönteniük, mit várnak az erőforrás-kihelyezéstől. Két út áll az informatikai erőforrás-kihelyezést választó cégek előtt: kihelyezhetik az egész informatikát, ezen belül is a teljes infrastruktúrát a személyi állománnyal együtt - ezt nevezik stratégiai outsourcingnak, - de választhatják a taktikai outsourcing-ot is, ami az IT-portfólió egy részének általában rövidebb távra való kihelyezését jelenti. A stratégiai outsourcing csak egy bizonyos vállalatméret felett jöhet szóba, ugyanis roppant nagy tranzakciós költséggel jár, majd ezt követően is nagyok a menedzsment kiadások a szolgáltatás igénybevétele során. [12] 188

21 Kulturális változások Ha egy cég ki akarja helyezni a teljes informatikáját, először azt kell felmérnie, mennyibe kerülne a házon belül, illetve azon kívül a megcélzott színvonalú üzemeltetés. A vállalatnak azt is el kell döntenie, mit vár a kihelyezéstől - az ár mellett fontos szempont lehet például a biztonság, illetve a várható minőségjavulás. A döntés előtt a nagyvállalatok rendszerint versenyeztetik a lehetséges szállítókat. Ez egyszerűen hangzik, de komoly problémát jelent azt elérni, hogy a szállítók egymással könnyen összehasonlítható ajánlatokat tegyenek. A várható futamidőre elvégzett gazdasági számítás mellett figyelembe kell venni a nehezen számszerűsíthető előnyöket, illetve hátrányokat is. A kihelyezéssel új kockázatok jelenhetnek meg, ugyanakkor a már meglévő kockázatokat is csökkenteni lehet. Az outsourcing csaknem minden esetben kulturális változással, munkahelyi stílusváltással jár, de ettől megváltoznak a munkafolyamatok is. Ugyanakkor a kihelyezés előnnyel is jár abból a szempontból, hogy tisztább felelősségi viszonyokat teremt Taktika és stratégia A taktikai outsourcing bizonyos szempontból bonyolultabb, mint a teljes körű kihelyezés. Ugyanis nagy körültekintést igényel, hogy egy cég felmérje, mely rendszerét bízhatja külső szolgáltatóra; ugyanakkor kevesebb kötöttséggel jár, hiszen ezek a szerződések rendszerint rövidebb időtartamra szólnak. A döntéshez először is fel kell mérni a vállalat ITportfólióját az infrastruktúrától kezdve az alkalmazásokon át a folyamatok működésszintjéig. Ezt követően azt vizsgálják, hogy az adott területen milyen színvonalú, mennyiségű és stabilitású szakértelem található házon belül. A tanácsadó szerint ezt követően meg kell nézni, mennyire egyediek az alkalmazott technológiák, folyamatok és az azokhoz kapcsolódó üzleti tudás. Csak ezután lehet eldönteni, hogy mely rendszereket helyezik ki. Az előző vizsgálat a kvalitatív előszűrésre alkalmas, de minden esetben meg kell vizsgálni a gazdaságosság kérdését is Szürke zónák Az alábbi ábrán jól látszik, hogy mely esetekben éri meg kihelyezni egy területet. 189

22 Nagy valószínűséggel akkor, ha mind értéke és egyedisége, mind az IT-szervezetben lévő tudás értéke alacsony szinten van. Ha a tudás magas szintű és egyedi területről van szó, akkor utóbbit házon belül kell tartani. Ha azonban a terület nem egyedi, de magas szintű tudás halmozódott fel a szervezetben, csak akkor érdemes kihelyezni, ha létezik egyértelműen olcsóbb alternatíva (ilyen lehet pl., ahol magasabbak az üzemeltetési költségek, ez a megoldás tipikusan az offshore kihelyezés). Ahol egyedi vagy értékes területről van szó, de az IT-tudás alacsony mértékű, a kihelyezésnél azt kell felmérni, hogyan tudnak megküzdeni olyan kérdésekkel, mint a piacra kerülési idő, az erőforráshiány vagy a dolgozók képzése. A tudás, illetve a terület értéke természetesen folyamatosan változhat különböző körülmények hatására. 2. ábra 190

23 A kisebb válallkozások általában méretüknél fogva inkább saját informatikust alkalmaznak, és megelégszenek a piacon kapható közepes szolgáltatási szinvonalat biztosítani képes alkalmazottal, mert ezt tudják megfizetni. Ahhoz, hogy az outsourcing látható eredményt hozzon, el kell érni a kritikus tömeget felhasználói számban, gyorsaságban, alkalmazások számában. Honnan tudja azonban egy vezető, hogy eljött az ideje annak, hogy a szervezet megszabaduljon az informatikai feladatoktól? Természetesen nehéz eldönteni, hogy egy informatikai folyamat kiszervezése olcsóbb-e, mint esetleges elődje. A döntéshez azt kell végiggondolni, hogy a vállalati alkalmazások milyen értékkel bírnak, és azokat milyen hatékonysággal üzemeltetik. A fenti ábra magyarázat kiegészítendő, tekintsük a kérdést kicsit más aspektusból. Tehát (ld. 3.ábra), pl. egy nagy értékű alkalmazást nagy hatékonysággal belső informatikával üzemeltetve és fejlesztve az outsourcing-ot nem érdemes szóba hozni, az egyértelműen felesleges. Általános állapot az, hogy a helyzet nem 3. ábra ez, főleg nem a Magyar Honvédség szervezeti egységeiben. Tovább fűzve a gondolatot, tehát megfontolásra érdemes a helyzet akkor, ha egy nagy értékű alkalmazás kis hatékonysággal vagy egy kis értékű nagy hatékonysággal működik. Ilyenkor két út közül lehet választani: bent tartom és belül fejlesztem, vagy kiadom outsourcing-ba a feladatot. Egyértelmű viszont a helyzet, ha a cégnek vannak kisebb értékű alkalmazásai, amelyek nem hatékonyak, ebben az esetben a megoldást a kiszervezés jelenti.nagyon sok döntéshozó magyarázza az outsourcing-tól való ódzkodását adatvédelmi aggályokkal. 191

24 Természetesen senki sem bízza szívesen legféltettebb adatait egy idegen cégre (az idézőjel nagyon is indokolt, hiszen vegyük figyelembe, hogy ha megfontolt és jól előkészített szolgáltatóválasztáson és szerződésen vagyunk túl, amit nagy valószínűséggel a rendelkezésre álló referenciák is erősen befolyásolnak, akkor nagy meglepetés nem szabadna, hogy érjen bennünket...?!). A Gartner Group egyik sokat emlegetett tanulmánya [13] mely szerint az informatikai támadások négyötöde belülről vagy belső munkatárs támogatásával történik némiképp enyhítit ezt. Kiemeli viszont a vállalaton belüli dolgozói elégedettség fontosságát. Mindemellett hangsúlyoznám, hogy az általános IT piacon már nem nagyon vannak titkok, az ellopható adatok is hetek alatt elavulnak, a vállalati know-how nélkül nem sokat ér semmilyen számsor, a know-how pedig nem igazán tulajdonítható el! 6. AZ IT ÜZLETI ÉRTÉKE Az IT üzleti értéke mint kérdés valószínűleg minden IT-vezetőt foglalkoztat. Elvileg mindenki tudja, hogy az informatika alkalmazása nagy előnyökkel jár, nagyon sokan azonban ma is csak egyszerű kiszolgálói szerepkörben képzelik el az információtechnológiát. Ma már sok lényeges üzleti alkalmazást is üzemeltet az IT, sőt jó néhány, mindenki által használt szolgáltatást kínál (például levelezés, nyomtatás), s emiatt, ha sokakban nem is tudatosul, nem kis fennakadásokat okozhat az üzletmenetben, ha az informatika háza táján valami nem jól működik. Az is bizonyos, hogy minden informatikus órákig sorolhatná, mi minden jót köszönhet a cége az információtechnológiának. Mégsem volna irigylésre méltó helyzetben, ha az informatika által teremtett konkrét üzleti értéket is ki kellene mutatnia. Igaz, ilyesmit általában nem várnak el az informatikai vezetőktől, de azt már annál inkább, hogy ha egy új megoldás - üzleti alkalmazás vagy csak egy levelezőrendszer frissítése - kerülne kivitelezésre, akkor mondja meg, hogyan térül majd meg a befektetett pénz. A pénzügyi vezetőt alighanem hidegen hagyja majd, ha azt hallja, hogy a rendszerek rendelkezésre állása 99,5 százalékra nő. 192

25 S az sem biztos, hogy a cégvezető beéri a helytálló, de roppant semmitmondó javul a hatékonyság válasszal. Az igazi kérdés mindig ugyanaz: mekkora üzleti haszna származik a cégnek a befektetésből? Konkrétan; Forintban! 6.1. ROI Az IT rendszerek bevezetésének kezdeti időszakában azokat a gazdasági elemző módszereket próbálták alkalmazni, amelyek a termelő beruházások esetén korábban sikeresnek bizonyultak. Ilyen a ROI (Return of Investment), amely a beruházásra fordított összege és az általa létrehozott nyereség viszonyát vizsgálta. Ez, és az ehhez hasonló mutató rendszerek nem alkalmasak arra, hogy az IT beruházások, és az általuk létrehozott nyereség között kapcsolatot teremtsenek. Annál is inkább, mivel a vállalatok belső IT szervezetei az esetek többségében nem mint belső szolgáltató egységek kerülnek mérésre. Ahhoz, hogy egy ilyen egység profit centerként legyen mérve szükséges, hogy piaci megmérettetésnek is ki legyen téve. Ez azt jelenti jelen esetben, hogy vagy a saját szolgáltatásait is értékesítse vállalaton kívüli piaci szereplők részére, vagy szolgáltatásai külső piaci szereplők szolgáltatásával legyen összehasonlítva egy buy or make döntés előtt. Tovább bonyolítja az objektív megítélést, hogy az IT költségek jelentős része nem kerül költség elemként kimutatásra a vállalat egyes szervezeti egységei tekintetében, hanem valamilyen szabály szerint visszaosztott általános költségként jelentkezik. A fentiek értelmében a ROI mellett valami más módszert is kellett találni TCO Az IT üzleti értékének meghatározásához először is pontosan meg kell határozni a bevezetendő új megoldás költségeit. Persze nemcsak a mostani költségeket kell figyelembe venni, hanem minden későbbit is - azokat a nemritkán igen tetemes összegeket is, amelyek nem kapcsolhatók közvetlenül a bevezetéshez. Közvetlen költség lehet például a hardver és a szoftver költsége, a bevezetéshez kapcsolódó felügyeleti költségek, vagy a későbbiekben a szállítói támogatás költsége; közvetett költségként általában a végfelhasználói támogatást vagy a rendszerleállás költségét szokták emlegetni a szakemberek. 193

26 Számtalan más tétel is szerepelhet a listán, és mint az már ezekből a kiragadott példákból is látszik, ezek a költségek nem mindig az információtechnológiában bukkannak fel. Ez a Total Cost of Ownership modell (TCO modell). A Total cost of ownership (TCO) nem más, mint magának a számítástechnikai eszköznek a teljes költsége a teljes életciklusán keresztül, azaz a beszerzéstől kezdődően egészen a rendelkezésre bocsátásig. A TCO analízis tulajdonképpeni célja, hogy azonosítsa, nagyságrendileg meghatározza és csökkentse az adott eszköz összes kapcsolódó költségét, amíg az a rendszerben szerepel. A TCO két összetevőből áll, a birtokolt IT eszköz hard és soft költségének kombinációja. A hard költség magában foglalja a tulajdonképpeni eszközt magát, azaz eszköz bekerülési árát, telepítési költségét, az upgrade-ek, karbantartási és üzemeltetési illetve a rendelkezésre bocsátási költségeket. Azért nevezik ezeket hard költségnek, mivel ezek kézzelfoghatók, így kvázi könyvelhető költségek. Mindazonáltal figyelembe kell venni a környezet fenntartásából származó egyéb szignifikáns költségeket, mint például a menedzsment erre eső része, tréningek, egyéb rejtett költségek, állásidők (ezeket nevezzük soft költségnek). Ennek oka, hogy ezek nem lépnek fel a beszerzéskor, legtöbb esetben elfelejtkeznek róla mikor budget-t tervezik és gyakran vezet oda, hogy előre nem várt többlet terhet vagy felelősséget ró mind az irányításra mind a végfelhasználókra. [14] Felh-i üzem Állás Adminisztr. 4. ábra HW & SW Üzemeltetés Kijelenthető, hogy egy PC-s munkaállomás költsége lényegesen nagyobb, mint annak bekerülési költsége. Például egy szoftverbeszerzés többszörös szoftver licenc és upgrade költségeket vonz magával, nem beszélve a hozzá tartozó tréningről és üzemeltetésről. 194

27 Éppen ezért meghatározni egy desktop munkaállomás teljes költségét komplikált feladat. A GartnerGroup piackutató cég elemzése szerint egy PC 5 éves teljes életciklusbeli költsége, TCO-ja átlagosan USD. Ezen értéket felszorozva egy szervezet 100 illetve több százas darabszámú eszközparkjával arra az eredményre jutunk, hogy jelentős figyelmet kell szentelni az eszköznyilvántartásra, s ezáltal beszerzési tervekre. [15] Az egyik leghatékonyabb technika a direkt IT költségek csökkentésére egy a teljes életciklust lefedő eszköznyilvántartó program rendszerbeállítása. Egy sikeresen üzembe állított ITSM rendszerbe integrált eszköznyilvántartás mintegy 10-15%-kal csökkentheti a TCO-t. Az alábbi táblázat tipikus példája egy általános IT költségmodellnek, amely költségtípusok számosságát és sokféleségét bizonyítja. Adott esetben nem kell mást tennünk, mint kitöltenünk a táblázat adott celláit, melynek eredményeképpen megkapjuk a vállalat 3-5 éves kliens/szerver alkalmazásának teljes költségét. A táblázat sorai adják az életciklusbeli elhelyezkedést, míg az oszlopok pedig az IT eszközkategóriákat. Számos tanulmány által bizonyított, hogy a munkaerő költsége közel 50%-a a teljes 5 évre vetített költségeknek. A másik aspektusból közelítve a kérdést pedig azt láthatjuk, hogy az 5 évre vetített összköltséget figyelembe véve a költségek több mint 70%-a jelentkezik a beszerzések után. Azaz a jól képzett, jól szervezett munkaerő rendkívül fontos egy szervezet életében. [16] 195

28 IT források Beszerzési és implementálási költség (beszerzés, bevezetés) HW kts. Szerver beszerzése, upgrade-je; PC kliens beszerzése; Munkaállomás beszerzése; Tárkapacitás beszerzése; Egyéb HW beszerzése SW kts. Operációs rendszer + licenc beszerzése Alkalmazás beszerzése Fejlesztő / migrációs eszköz beszerzése Munkaerő kts. (IT) Munkaerő kts. (felhasználó) továbbképzés Vonalhasználat Esetleges WAN használat Mobil komm. Internet szolgáltató Hálózat és kommunikáció Egyéb kts. Tréning Szervezeti állásidő Hálózati és kommunikációs HW Hálózati és kommunikációs SW Renováció, rekondtrukció Helyszíntervezés IT életciklus szintjei Üzemeltetési költség (3-5 éves üzemeltetés) HW kts. HW bérlet kts. karbantartási Tervezés kts HW installáció SW installáció szerver kliens Hálózati installáció user account egyéb beállítás SW migráció IT tréning Professzionális konzultáció Periodikus licenc kts. SW üzemeltetési kts Garancia Adminisztráció Hibakezelés Folyamatos továbbképzés Hibakezelés Help Folyamatos HW konfiguráció, setup Op.rendszer upgrade szerver kliens Hálózati változtatások Kapacitástervezés Professzionális konzultáció Elektromosság Biztonságtechnika Katasztrófavédelem 1. Táblázat Folyamatos változtatási kérelmek költsége (változtatások, környezeti változások) további szerverek további kliensek Szerverbővítés Rendszer upgrade Tárolókapacitás upgrade Egyéb HW bővítés Operációs upgrade Migrációs beszerzése rendszer eszköz További tréningek Hálózati változtatások tervezése További háló/komm HW, SW További helybővítés 196