Nehéz helyzetben van, aki egzakt módon szeretné leírni az ideális vállalati környezetet, amelyben maximális hatékonysággal működik az IT-szolgáltatásmenedzsment (ITSM). Ilyen nincs is, mert ahány ház, annyi szokás, mondhatnánk. Ám ez így nem teljesen igaz.

Ha például megnézzük a Jirát fejlesztő Atlassian blogját, a szervezeti működéstől a belső csoportszintű és egyéni kommunikáción, az egészséges munkahelyi kapcsolatok fontosságán vagy a munkavégzés módszertanán át a vezetési módszertanig, a hatékony döntéshozatali folyamatokig és a csapatirányításig a legváltozatosabb témákról találunk bejegyzéseket. Ám van a témákban egy nagyon is közös pont: mindegyiknél a folyamatokban gondolkozó és dolgozó ember van a középpontban. (Nem véletlen, hogy a blog címe Work Life.)

A témák együttesen többé-kevésbé azt is kirajzolják, mit is kell értenünk a jó-hatékony ITSM-környezeten: olyan emberek dolgoznak digitalizált és elosztott munkakörnyezetben, együttérző vezetési módszert követő munkahelyi vezetők irányítása alatt, akik képesek csapatban gondolkodni, ismerik saját és kollégáik erősségeit, és csapaton belül és kifelé is tudnak inkluzív módon kommunikálni.

Egy ilyen korszerű szervezet kialakítása, általában a belső működést javító intézkedések leggyakrabban akkor vetődnek fel, amikor egy cég technológiai korszerűsítést is végrehajt. Ahogy összeállításunk előző részében írtuk, az IT-funkciók hatékonyságának növelésétől működési és stratégiai előnyöket is remélnek a szervezetek. Nem meglepő tehát, hogy az Atlassian is nagy szerepet tulajdonít az emberi tényezőnek. Egy magyar pénzintézet Jira-környezetben dolgozó PMO-ja (Project Management Officer) egy beszélgetés során ezt így fogalmazta meg: ha a szervezet nem veszi figyelembe, hogy a rendszereket emberek "mozgatják", a digitalizálás csupán átmenetileg hoz előnyöket, de fenntartható változást nem eredményez.

Az emberi tényező figyelmen kívül hagyására vezethető vissza az egyik alapvető konfliktus, amely az ITSM körül ki szokott alakulni: technológia kontra szervezet. Önmagában a technológia bevezetése gyors is lehet, de a meglévő folyamatok digitális munkafolyamatokká transzformálása szinte mindig lassabban halad. Ezért beszélnek az ITSM-szakértők olyan gyakran vállalati kultúráról, kommunikációról, kollaborációról.

Megőrizni az üzleti fókuszt

Ahogy azt összeállításunk előző részében írtuk, egy jól bevezetett ITSM-platformnak sok hozadéka lehet: csökkenti az IT-költségeket (beszerzés, telepítés, üzemeltetés), javítja az alkalmazottak termelékenységét – és elégedettségét –, támogatja a cégvezetőt abba, hogy az informatikai erőforrásokat hatékonyan mozgósítsa az üzlet érdekében. Működésének természetesen vannak fontos technikai-technológiai momentumai, ezért meg kell határozni a vállalati rendszerek függőségi mátrixát – például mely technológiai komponensek, szerverek, adatbázisok stb. milyen (üzleti) alkalmazásokat támogatnak –, mert ez lehet az alapja többek között a támogatási folyamatok finomhangolásának. Fontos azonban az is, hogy a kapcsolatok és függőségek összetettebbé válásával az ITSM hangsúlya ne helyeződjön át az üzletről a technológiára.

A lépésről lépésre haladás sok csalódástól megkímél egy szervezetet az ITSM kiterjesztésénél. Értelemszerűen az alaptevékenységekkel (pl. incidensmenedzsment, változáskezelés) érdemes kezdeni, majd ha azok "bejáratódtak", következhetnek a további szolgáltatások. A sietség még olyan területen is problémát okozhat, mint a tudásbázis létrehozása. Ha nincsenek hozzá megfelelő folyamatok – például hogy az információk mindig megfelelően frissüljenek –, vagy gyorsan elveszti pozitív szerepét, vagy a pontatlanságok és az elavult információk kiszűrésére kell sok erőforrást (idő, munkaerő) fordítani.

A Gartner is a fontolva haladás híve: mint Chris Matchett, a cég vezető kutatója fogalmazott egy nyilatkozatában, még az alapfunkciók esetében is fontos a rendszeres felülvizsgálat, majd optimalizálás, aminek során azt is mérni kell, hogy adott folyamat szerves részévé vált-e a szervezet kultúrájának. Ez lesz ugyanis később az alapja a zökkenőmentes automatizálásnak. Ha ugyanis a folyamat hibás, akkor az automatizálása is rossz eredményt szül.
 

A csel mindebben az, hogy miközben folyamatosan IT-ról van szó, soha nem szabad szem elől téveszteni: üzleti szolgáltatásokat kell nyújtani. Tehát az ITSM-et az üzleti szempontok figyelembevételével kell megtervezni, előnyeit az üzleti szempontok alapján kell megfogalmazni és értékelni. Ha valaki az üzleti oldalon ül, számára érdektelen, hány incidens volt az IT-nél, számára csak azok az üzleti alkalmazások érdekesek, amit a munkájához használ. Azzal viszont neki is tisztában kell lennie, hogy adott alkalmazáshoz milyen szolgáltatások kapcsolódnak, és azok hogyan hatnak a cég működésére.

Ehhez kommunikálni kell, amihez ki kell alakítani a felhasználók és az IT közös nyelvét. Kommunikálni kell felfelé: hogy a menedzsment is lássa az ITSM üzleti értékét; és kommunikálni kell az alkalmazottak felé, mert csak akkor érvényesülnek az előnyei, ha a vállalati kultúra szerves részévé válik. Például egy az üzleti igényekhez igazított és jól kommunikált SLA csökkenti a felhasználók IT-vel kapcsolatos frusztrációit, mert számíthatnak arra, hogy az üzletkritikus problémák gyorsan elhárulnak, és jobban megértik, hogy a feladatokat az IT mi alapján priorizálja. Vagy: ezen a kommunikáción múlik, hogy a felhasználók megértsék a szervezet igényit, és belássák, mikor éri meg vállalni azt a kockázatot (pl. a karbantartás nehézségei), ami egy rendszer testre szabásával jár, és mikor nem.

Mindezek eredményeként kialakítható egy önkiszolgáló ITSM-rendszer is, ahol egy tudásadatbázisra támaszkodva a felhasználó a leggyakoribb kérdésekre megtalálja a választ – és maga elvégezheti a szükséges lépéseket. Ez az IT-t tehermentesíti, mert (legtöbbször) csak az összetettebb ticketekkel kell foglalkoznia.

Tanulni, tanulni, tanulni

Végül egy fontos kérdés: mennyire érdemes testre szabni egy ITSM-platformot? Mint minden egyedi, belső fejlesztéssel, ezzel is az a probléma, hogy a módosítások rendszerint gyengén dokumentáltak. És minél több van belőlük, annál nehezebb lesz rekonstruálni, hogy mi történt, ha azok, akik a módosításokat kivitelezték, elmennek a vállalattól.

De a túlzott testre szabással más baj is lehet: az ITSM-platformok meglehetősen bonyolultak. A funkciók összetett kölcsönhatása miatt lehet, hogy az egyik testre szabása miatt egy másik funkció rosszul működik majd. A kivételkezelés sem feltétlenül megoldás, mert ha elkezdenek burjánzani a kivételek, könnyen kezelhetetlen mennyiségűvé gyarapodhatnak. (A helyzetről lásd fentebb a keretes szövegrészt.)

A folyamatok szabványosítása (értsd: a platform logikájához igazítása) viszont szervezeti szintű tanulást igényel. Éppen ezért az ITSM-re nem szabad időben korlátozott projektként tekinteni. A rendszert folyamatos menedzselni, az alkalmazottakat pedig képezni kell, mert változnak (ráadásul manapság elég gyorsan) az üzleti követelmények – és változik az ITSM eszköztára is.

Ez a cikk független szerkesztőségi tartalom, mely a META-INF Kft. támogatásával készült. Részletek »