Minden bizonnyal nem árulunk el hatalmas titkot, ha azt mondjuk: mindenkinek a saját feladata a legfontosabb és a többségben fel sem merül, hogy esetleg a kapcsolódó tevékenységekkel kapcsolatban is érintett lehet. Ez gyakran előforduló probléma az IT üzemeltetés területén is.

Egy üzemeltetési probléma jellemzően technikai erőforrás kérdésekből, kimutatási vagy riport kérdésekből adódik. Másrészt azonban komoly tényező lehet az emberi oldal is, éppen ezért érdemes e két dolgot elkülönítve is megközelíteni.

Kezdjük ott, hogy ahány ember, annyiféle nézőpont: ugyebár vannak az üzemeltetők, akik teljesen mást gondolnak arról, mikor van szükségük segítségére, mint amit az ő közvetlen vezetőjük. És még ez sem az összes aspektus, hiszen a hierarchia legtetején találjuk az IT vezetőt, aki ugyancsak a saját szemszögéből figyeli a dolgokat. Emellett pedig ott van még az ügyfél is, aki szintén jelezheti, ha problémát észlel, s minden bizonnyal számára is az lesz a fő vonulat, ami közvetlenül őt érinti.

A problémák beazonosítása

Van egy mondat, amely az esetek többségében előkerül egy üzemeltetői probléma kialakulásakor: “sajnos semmire sincs időnk”. Ennek elhangzása egyike az első jeleknek, amelyekből már sejthetjük, hogy valami nincs rendjén. Szintén klasszikus égi jel, amikor azt tapasztaljuk, hogy egyre több a visszatérő probléma (erről beszéltünk egy korábbi cikkünkben is ITT), illetve az is, amikor a problémák tömegesen jelentkeznek. Ekkor már látszik, hogy valami nem megfelelően működik, és felmerülhet a tervezés szükségessége.

Időnként előfordul, hogy az üzemeltetés annyira szegmentált, hogy a probléma megoldása két terület között akad el, ilyenkor az érintett területek képviselői egymásra mutogatnak. Ennek sajnos a jövőre nézve sincs jótékony hatása (legfeljebb elmérgesíteni lehet vele a munkahelyi kapcsolatokat, ami tovább gátolhatja az együttműködést), és a probléma megoldását sem szokta elősegíteni.

Sajnos jellemző probléma az is, hogy üzemeltetés nem követi nyomon a rendelkezésre álló hardver, szoftver, licenc mennyiséget. Ennek egyenes következménye a munka elakadása, amint elfogynak az erőforrások.

A problémák megoldása

Ha sikerült beazonosítani egy problémát (pláne ha még a kezdeti szakaszban elcsíptük), az kétség kívül nagy előrelépés. A kérdés már csak az, hogy ilyenkor az üzemeltetői oldal felől, vagy fentről érdemesebb-e megindítani a problémamegoldást.

Nos, szerintünk ez kétirányú. Egyrészt minden ilyen csapatban van egy-két olyan ember, aki képes kicsit felülről nézve, tágabban tekinteni a problémára. Az már csak a hab a tortán, ha képes a kollégákat is ebbe az irányba terelni. Mindenesetre inkább az a jellemző, hogy az üzemeltető észreveszi, érzékeli a problémát, de kevésbé jellemző, hogy egyben megoldással is ő szolgáljon.

S itt jön a képbe a csoportvezető, a közvetlen felettes, az, akinek minderre figyelnie kell, s akinek a hierarchiát tekintve is megvan a lehetősége, hogy erre a szemléletmódra rávezesse a többieket, vagy konkrét megoldást adjon a kezükbe. Általában ő az, akinek feltűnik, hogy folyamatosan csúszásban vannak, egyre több a munka, s egyre kevesebb feladat elvégzésére jut idő. Mindig előre kell venni valamit, semmi nem készült el időre, állandóan haladékot kell kérni az igénylőtől vagy a felettesektől, s az ő tevékenysége is lassan abból áll csak, hogy állandó operatív munkát végez, vagyis a problémákat és az embereket menedzseli. Pedig egy csoportvezető ennél azért többre hivatott, s ha bekerül ebbe a mókuskerékbe, azzal csak egy bizonyos szintet lehet tartani, de előre jutni és hosszú távú megoldásokkal szolgálni aligha.

El kell érni, hogy a csoportvezetőnek jusson ideje a tervezésre, fejlesztésre, hogy indukátorként működhessen és segítségével a csapat is megfelelő ritmusban, tervek alapján tudjon előrehaladni. Ha ez elmarad, az csak újabb problémákat generál. Ha azonban sikerült ezt elérni, általában az is rögtön kiderül, hogy nem az erőforráshiány, hanem a rosszul menedzselt folyamatok jelentették a fő gondot. Ezeket kell tehát tiszta fejjel, felülről áttekintve rendezni.

Éppen ezért egy csoportvezető legfontosabb feladata a folyamatok kitalálása, felügyelete, azok racionalizálása, s amennyire csak lehet - ez ugyebár trendi téma manapság - azok automatizálása is. Ez utóbbit illetően is neki kell átlátnia, mivel lehet segíteni az üzemeltetők munkáját, mi az, amit az automatizálással rábízhatunk a gépre, hogy időt nyerjünk.

A menedzsment szint

A fenti folyamatokon keresztül kiderülhet egy csoportvezetőnél, mikor érkezik el arra a pontra, amikor segítségre van szüksége, még ha nem is feltétlenül veszi ezt észre. A következő szint pedig az IT vezető, azaz a menedzsment szint.

Itt is akad két-három olyan eset, amikor a menedzsment észlelheti ha gond van. Az egyik, hogy házon belül jutnak el hozzá a problémák, vagyis az alatta lévő középvezetőkön is átívelnek. A másik - ami egy menedzsmentnél klasszikus esetnek számít -, amikor SLA riportokat, teljesítménymutatókat (KPI) néznek, s ha azokat rendszeresen olvassák és elemzik, könnyen feltűnik, hogy valahol porszem került a gépezetbe.

A harmadik eset - amelyiket valószínűleg minden cég szeretne elkerülni -, amikor az ügyfelektől érkezik visszajelzés. Lássuk be, ha az ügyfél annyira elégedetlen a szolgáltatással, hogy közvetlenül a menedzsmentet keresi, ott már nagyon ég a ház.

Menedzsment szinten a legfőbb kihívást az jelenti, hogy mielőbb sikerüljön beazonosítani, pontosan hol bújik meg a probléma oka. Ki kell deríteni, hogy emberi mulasztás, esetleg hardveres erőforrás okozza-e, vagy mondjuk a folyamat egy bizonyos pontjával van gond. Ez az a rész, ahol a menedzsment szorulhat a középvezetők segítségére.

Ne építsünk égő házat, avagy a probléma megelőzése

Az eddigiek alapján úgy gondoljuk, a folyamatoknál alapvető, hogy azok átgondoltak, racionalizáltak és az üzemeltetők számára is komfortosak legyenek. Ez az egyik legfontosabb.

Emellett a folyamatokba be kell építeni olyan eszközöket, amelyekkel kimutathatóvá válnak a belefektetett idők, energiák, vagyis statisztikák nyerhetők ki róluk. Így például ha veszünk egy helpdesket, akkor tudnunk kell összegezni az emberek munkáját, a feladatok végrehajtásának idejét, az esetleges teljesülési hiányosságokat. A céges szintű jelentések és csoportszintű beszámolók egyaránt fontosak.

Meg kell találni azokat a termékeket, amelyeket használva kimutatásokat készíthetünk a folyamatok egyes pontjain. Az is nagyon fontos, hogy ezek a riportok, ne másfél-két napos munkával előállítható Excel táblázatok legyenek, feldobva pár kördiagrammal. Ehelyett egyszerűen, gyorsan elkészíthető, nagyon könnyen összehasonlítható kimutatásokra van szükség, ahol egy-egy aktuális értéket villámgyorsan össze lehet hasonlítani az elvárttal. Érjük el, hogy akár a nap végén egyszerűen lehessen lehúzni egy ilyen jelentést. Ez nagyon fontos, hiszen ha egy ilyen beszámoló elkészítése túl sok időt emészt fel, akkor ez lesz a gátja annak, hogy megfelelő visszajelzéseket kapjunk.

Ezekre a feladatokra egyébként bőven akad megfelelő eszköz. A teljesség igénye nélkül ilyenek a különféle helpdesk rendszerek (OTRS, ServiceNow, Freshdesk, ManageEngine…stb). Ezek mindegyike képes jelentéseket készíteni a benne végrehajtott feladatokról. Az ezekben használt ticketek végrehajtása folyamathoz kötött, az ezeken alapuló workflow-k és tevékenységek mind-mind több szinten riportozhatók, tehát akár egy csoportvezető is lehúzhatja magának a statisztikát, például arról, hogy mennyi nyitott jegy van, mennyi van közülük csúszásban, az egyes embereknél mennyi feladat áll. Így rögtön le lehet szűrni, hogy ki az, aki túlterhelt vagy éppen kinek nem jutott feladat. Így optimalizálhatók a folyamatok.

Technikai oldalról térjünk még vissza egy kicsit a monitoringhoz, vagyis hogy miként állnak a hardver erőforrások, a rendelkezésre álló erőforrások, vagy akár a rendelkezésre álló licencek. Ezek technikai dolgok, amelyeket egy monitoring rendszer képes folyamatosan figyelni, követni, képes ezekről trendeket, grafikonokat készíteni, szükség esetén riasztást generálni, és adott időközönként - nyilván itt a hierarchiától függően negyedévente, félévente, évente - készíthet olyan beszámolókat is, amelyekből az erőforrás használati trendek követők. Így ha veszünk egy csoportvezetőt, ő is megnézheti, hogy akár az elmúlt egy hónapra visszamenőleg miként fogytak el a tárhely kapacitások, mennyiben nőtt a virtuális környezetek memória és CPU terhelése, és ebből következtethet arra, hogy a beérkező feladatok, igények és az elfogyott erőforrások között van-e összefüggés? Ebben az esetben akár ő maga is elindíthatja az erőforrásbővítési folyamatot, vagy módosíthat úgy folyamatokat, hogy nagyobb kontrollhoz jusson. Így például elkerülhető, hogy mindenki, minden részfeladatra újabb virtuális gépet kérjen, s így egy idő után már ezer darab virtuális gépünk legyen, amelyek közül ötszáz ugyanazon a feladaton dolgozik.

Tehát a monitoring rendszer technikai statisztikái, grafikonjai, és az emberi erőforrásra vonatkozó jelentések remekül párhuzamba állíthatók. Mindez pedig jól jöhet az éves tervezéseknél, a jövő évi tervek készítésénél is, hiszen így könnyebben kideríthető, miként növekedhetnek az erőforrás igények az ügyfelek oldaláról és saját részről.

A lényeg az, hogy mindig azt a pontot, azt a helyet, azt az embert, azt a csoportot kell tudni pontosan meghatározni, ahol a beavatkozásra, segítségre szükség van.