ITSMF konferencia 2008 – ING Service Center Budapest

Tegnap volt az ITSMf 2008. évi konferenciája. Az ITIL v3 népszerűsítő előadás mellett jónéhány gyakorlati tapasztalattal is megismerkedhettünk.

Azon előadások közül, amiket volt szerencsém látni (mert a nap közepén elmentem egy megbeszélésre, majd sajnos az AAM előadását is ki kellett hagynom a végén), igen tanulságos volt az ING Service Center Budapest története, mely egy siker-story, csak a végén nincs happy end. Ezt a történetet már évek óta követik azok, akik az informatikai szolgáltatásmenedzsment és ITIL iránt komolyan érdeklődnek, melyről már 2006-ban (két éve) is hallhattunk egy igen jó és népszerű előadást (előadás fóliák, video).

Most előadásként a történet végét hallhattuk, ugyanis minden sikeressége ellenére az ING Service Center Budapest 2007-ben bezárt. Remélem az ITSMf megújult honlapjára felkerülnek az új videók, köztük ez az előadás is.

Az ING Service Center Budapest 2001-ben indult el, alapvetően egy régiós IT szolgáltató-központként működött (shared service), ahol az egyik fő tevékenység a Profile/Anyware rendszer bevezetése és üzemeltetése volt. A fő gondolat persze az volt, hogy a szolgáltató-központ a méretgazdaságossági előnyöket nyújtásával ér majd el eredményeket.

Az üzemeltetés alapjaként – filozófiaként – az ITIL-t (akkor még v2 verzió) választották, és igyekeztek minden lehetséges kapcsolódó minősítést begyűjteni. Ez a minősítésgyűjtés marketing oldalon szolgált demonstrációval arra, hogy a szervezet nem csak működik, hanem jól is működik.

Persze a kihívás is igen nagy volt: Míg a régiós bankok jelentős igényekkel jelentkeztek, addig a Service Center alapvetően egy kis szolgáltató-cégnek számított csak, és ez sok kockázatot is magában hordozott. A kockázatok csökkentésének viszont igen hatékony megoldása volt az ITIL alapú üzemeltetés.

Nagy eredmény volt, hogy a cég elnyerte a BS15000 minősítést, Magyarországon először, de a világon is kilencedikként! Így nem volt kérdést, hogy az itSMF Magyarország az év szolgáltatásmenedzsere díjat Patay Gábornak, az év szolgáltatásmenedzsment projektje díjat az ING Service Centre Budapestnek ítélte oda 2006-ban. És persze igen sok szervezett igyekezett ezeket a tapasztalatokat a saját gyakorlatában is hasznosítani.

A siker mellett érdemes megemlékezni a tapasztalatokról is.

Az első ilyen tapasztalat az (ITIL) oktatás kérdése volt. “Megjártuk a saját utunkat. Nem ezzel kezdtük, de ezzel kell kezdeni: Kell egy közös terminológia a külső szolgáltatók, és a belső IT között.” 1-2 éve azt hiszem a Dunaferr IT szolgáltató-központjának vezetőjétől hallottam hasonló gondolatokat, miszerint az ITIL oktatás teremtheti meg a közös nyelvet, szemléletmódot. Sajnos ő is utólag mondta, hogy az oktatás a projekt elején kellett volna.

Véleményem szerint egy kezdeti ITIL oktatás nem csak közös nyelvezetet biztosít a projekt tagjai számára, hanem egy egységes szemléletmódot, orientációt (és remélhetőleg elkötelezettséget) is. Éppen ezért lehet hasznos már mindezt a projekt elején megtenni. Sajnos sok projekt esetében pont az oktatást tekintik puha pénznek (soft money), így ezt a részt ki lehet húzni, és ezen lehet spórolni. Persze utólag már késő bánat, de örülök, hogy nem csak én látom így, hanem nálam tapasztaltabb kollégák is.

Eszembe jut egy történet, amikor még a Westelnél csináltuk Szabó Zoltán kollégámmal az ITIL pilot projektjét. Sok workshop-ot tartottunk különböző IT üzemeltetési csoportokkal, és érdekes élmény volt tapasztalni, hogy ezen csoportoknak mennyire eltérő a filozófiája és a nyelvezete is: volt olyan kifejezés, amit teljesen eltérő értelemben használtak a csoportok, és volt olyan fogalom, melyre 3-4 kifejezésük is volt. Így nem csoda, ha sokszor megakadt a kommunikáció, és néha úgy éreztük, hogy mi tolmácsolunk. Az ITIL ehhez a szituációhoz is közös nyelvet adott.

A következő tapasztalatok a különböző érdekcsoportok bevonásáról szóltak. Egyrészről szükséges egy erős, kitartó vezetői támogatás (anélkül el sem szabad kezdeni): “Meg kell tudni, hogy minden vezető támogatja. Nem lehet próbálkozásnak tálalni, kell a vezetői elkötelezettség, hogy végig akarják csinálni.” Ez az ING Service Center esetében nem lehet gond, de sok vállalatnál ez az elkötelezettség csak félig, vagy úgy sincsen meg.

Ilyen esetekben lehet, hogy már félidőben, az első nagyobb ellenállás megjelenésekor lelövik a projektet. És talán ez még a jobbik eset, mert végig is mehet, csak utána szépen lassan minden eredmény elhal (és ezen a konferencián sajnos ilyen történeteket is hallottam: 1-2 éve még sikeres projekteket bemutató cégek esetében most elmennek a kulcsemberek, mert már nincs meg a vezetői elkötelezettség).

Nem szabad elfelejteni a vezetők mellett a munkatársakat sem, hiszen nélkülük sem megy semmi. Egyrészt kell a folyamatgazdák támogatása, mert rajtuk keresztül lehet elérni a többi dolgozót. Rajtuk keresztül lehet majd a kultúrát, szemléletmódot változtatni. Ha ők elhiszik, hogy az egésznek értelme van, segít átbillenteni a többi dolgozó hozzáállását is. Akik persze inkább fenyegetésnek érzik az egészet, hiszen átláthatóbb, kontrollálhatóbb lesz a működés. És ehhez kell egy kis erőszak is, míg a dolgozók megértik, hogy nekik is jobb lesz így a munka, tehát win-win szituációról van szó. Ebben eleinte sokat kételkednek, és persze a szigorúbb dokumentációs követelmény nem túl népszerű senki körében sem.

Egy ilyen kényszerítő erő lehet egy olyan támogató eszköz, mely kikényszerít bizonyos tevékenységeket (pl. dokumentálás kikényszerítése). Egy ilyen eszköztől elvárhatjuk, hogy workflow motorral segítse a folyamatok végrehajtását, és jelezzen, ha a folyamatok lefutásában gond van. Az ING esetében például a folyamatokban megjelenő holtidőket sikerült minimalizálni, mivel ezek a holtidők láthatóvá váltak.

Az ING esetében 2 év kellett ahhoz, hogy ez a szemléletmód meghonosodjék a gyakorlatban, és beépüljön a szervezeti kultúrába. Ez a tapasztalat rámutat arra, hogy nem elég bevezetni a folyamatokat, nem elég támogató eszközt találni, hanem hónapokon, éveken keresztül szükséges a folyamatos felügyelete a folyamatoknak, amíg azok bele nem épülnek a kultúrába. Sajnos sokfelől hallottam a konferencián, hogy sok szervezet esetében pont a kultúrába való beépülés maradt el, és így lassan a teljes megközelítést lassan ellepi a por, és visszatérnek a régi gyakorlatokhoz.

Az informatikai vezetők változó szerepe

Érdekes, hogy néha hogyan koncentrálódnak bizonyos témák (vagy csak jobban elérik az ember ingerküszöbét). Nemrég az informatikai vezetők feladatairól írtam, majd most a Global CIO Survey 2008 felméréséről számoltam be. Aztán ezen a héten esett be a Strategy&Business következő száma, melyben szintén az informatikai vezetők változó szerepéről van egy cikk, „A gyakorlatias látnok” címmel.A cikk egy esettanulmánnyal kezdődik, mely Michael Gliedman történetét mutatja be:

Michael Gliedman 1999-ben lett a Natinal Basketball Association (NBA) informatikai vezetője. Akkoriban az informatika nem állt épp a helyzet magaslatán az NBA háza táján: az informatikai megoldások funkcionális területenként egyediek voltak, nem foglalkoztak kockázatkezeléssel (bár az 2000. év problémája igencsak sürgető volt), bizonyos részlegek saját kezükbe vették az informatikai irányítását…

Gliedman legfőbb feladata így (kényszerűségből is) a rendrakás volt, mely 18 hónapig tartott: biztosította a szolgáltatások megbízható és hatékony működtetését, és egységesítette az informatikai szolgáltatások nyújtását. „Lehetetlen, hogy bárki is komolyan vegyen az üzleti oldalon, ha 20 percig tart, míg valaki felveszi a telefont a Help-Desk részlegen. Itt főként hallgatnod kell, és csendben megoldani mindent a háttérben. Ha már bizonyítottál, akkor fognak csak komolyan venni, és helyet biztosítani az Asztalnál.”

A megbízható működés miatt Gliedman számára is elérkezett az idő, amikor az Asztalhoz ülhetett, azaz lehetőséget kapott arra, hogy közvetlenül segítse a kijelölt stratégia megvalósítását: a nemzetközi érdeklődés növelése, a női rajongók táborának fejlesztése, illetve a nézők számának növelése.

Mostanra az NBA informatikai részlege kiépítette az NBA digitális archívumát, melyben minden mérkőzést rögzítenek több kamerával is, melyek elérhetőek az NBA weboldalán keresztül. 2007 novemberében sikerült elérni az eddigi rekordot:több, mint 153 millió oldalletöltés mellett 38 millió videót néztek meg.

Gliedman egy másik célcsoportját maguk a kosárlabdacsapatok jelentik. Az ő működésüket üzleti intelligencia programokkal segíti, mely a liga rajongóiról szolgáltat adatokat. És végül ne feledkezzünk meg a liga központjának támogatásáról sem: szervervirtualizáció, SOA és szociális háló alkalmazások segítségével támogatják a dolgozók együttműködését.

Mindemellett természetesen nem lehet megfeledkezni az alapszolgáltatások színvonalas működtetéséről sem.

Gliedman tipikusan azon informatikai vezetők mintaképe, akik a realitások ismerete mellett elérik, hogy az informatika megkapja a maga lehetőségeit. Mint ahogy korábban már én is írtam, először az alapvető működést tekintetében kell elérni a megbecsültséget, és akkor lehet igazán megvalósítani a nagyratörő terveket. Hiszen, ha az informatikai vezető nem tudja a kulcstevékenységét megfelelően nyújtani, akkor miért is kellene, hogy beleszóljon az üzleti döntésekbe?

„Azok az emberek, akik az én osztályomon dolgoznak értik azon víziómat, melyben a működési kiválóságra törekszem, mert ez lehetővé teszi számunkra, hogy olyan klassz (cool) dolgokat is megvalósítsunk, mint az IP telefonok, vagy a szociális háló alkalmazások.” (Michael Gliedman, NBA)

Ennek persze feltétele az is, hogy az informatikai ne alárendelt szerepet játsszon, ami legtöbbször a pénzügyi nézőpontot takarja. Gliedman része a „belső körnek”, részt vesz a stratégiai döntésekben, sőt hozzájárul a stratégia alakításához (pl. az online videó alapú szolgáltatások felfuttatásával).

Az informatika sajátságos helyzetben van: mivel minden területet támogatnia kell, ezért minden területet ismernie is kell. Ennek megfelelően talán egyedül az informatikai terület rendelkezik átfogó képpel a szervezet működéséről. (ennek a Global CIO Survey 2008 felmérésben nem szenteltek kiemelt figyelmet). Ez hatalmas lehetőség abban az értelemben, hogy komplex, az egész szervezetet átfogó fejlesztésekre tud az informatika javaslatot tenni.

Azt gondolom, hogy az informatikai funkció feladat kettős: egyrészről hatékonyan biztosítani kell az alap informatikai szolgáltatásokat (ehhez érdemes lehet az ITIL és Cobit módszertanokat felhasználni). Ez a rész sok embernek akár unalmas is lehet. Ugyanakkor a jó működés biztosítja, hogy az informatikai terület innovatív megoldásokat is megvalósíthasson, akár a belső működés javítása, akár új üzleti lehetőségek kifejlesztése terén.

Informatika és innováció

A húsvéti hétvégét kihasználva, most olvastam a Cap Gemini 2008-as felmérésének eredményeit, melyben az informatikai, illetve az informatikai vezetők változó szerepéről esik szó. Ebben a felmérésben van 1-2 meglepő eredmény is. A felmérés egyébként az egész világra kiterjedt, tehát végre nem csak Amerika véleményét ismerhetjük meg. A tanulmány március 31-i dátummal jelent meg (bár bizonyos eredmények blog szinten már március 12-én megjelentek).

Informatikai és informatikai funkció kapcsolata

Nem újdonság azt állítani, hogy az informatikai feladata támogatni az üzleti stratégiák megvalósulását. Ennek a kihívásnak a frontvonalban az informatikai vezetőnek is meg kell felelnie: nem csak értenie kell az üzlet nyelvét, de beszélnie is.

Főbb megállapítások:

• A felsővezetők 83%-a, míg az informatikai vezetők 62%-a gondolja, hogy az informatikai hozzájárul a jövedelmezőség növekedéséhez.
• Az felsővezetők 41%, illetve az informatikai vezetők 37%-a szerint 5 éven belül már nem lesz önálló informatikai osztály (igazgatóság, divízió stb.) egy vállalaton belül.
• A felhasználók IT tudása jelentősen javult. Az új generáció számára már megszokott eszköz a számítógép, és annak alkalmazásai.
• Az informatikai tevékenységek sok helyen részben, vagy egészben kiszervezésre kerültek.

Míg az informatika szerepét alapvetően innovatívnak ítélik meg a válaszadók, mely képes hozzájárulni a szervezeti innovációhoz (70% egyetért), addig az informatikai funkciót már nem tekintik annyira innovatívnak (50% egyetért). Sőt csak a válaszadók 24% szerint az informatikai funkció az üzleti innováció hajtóereje. A válaszadók az innováció forrásának 6 lehetősége közül az informatikát az utolsó helyre, a pénzügyi funkció elé helyezték (sorrend: 1. Kutatás-fejlesztés 2. Operations 3. Értékesítés 4. Marketing 5. IT 6. Pénzügy).

Érdekes ez az eltérés a megítélésben: jó hír, hogy az üzleti oldal is érti az informatika fontosságát, de mégsem tekint úgy az informatikai osztályokra, mint amelyek képesek ezt teljesíteni. Sőt, még az informatikai innovációt sem az informatikától várják el. Úgy tűnik az informatika növekvő fontossága és megbecsültsége ellenére sem sikerült az informatikai osztályoknak kimozdulni abból a szerepkörből, hogy csak megrendeléseket teljesít.

Pedig az informatika hosszú távú sikerességéhez elengedhetetlen, hogy az innovatív folyamatoknak, és az üzlet hatékony támogatásának részese lehessen.

Innovatív vállalatok

A vállalatok 5% esetében az üzleti innováció alapvető stratégiai cél, és az IT funkció feladata az innovatív tevékenységek vezetése. Ezen vállalatok gyakorlata 5 területen is jelentősen különbözik a többi vállalat gyakorlatától:

• Business leadership csapat, mely érti az informatikai lehetőségeit
• Szoros kapcsolat az informatikai és üzlet között
• Az alapvető informatikai szolgáltatások megbízható nyújtása
• Az informatikai vezető a nem a pénzügyi vezetőnek, hanem a CEO-nak, vagy COO-nak számol be.
• Az informatika partneri kapcsolatban áll az üzleti oldallal

Az innovatív vállalatok informatika költségvetése nem különbözik jelentősen a többi vállalat költségvetésétől, talán egy kicsit erősebben koncentrálnak a stratégiai területekre, és kevésbé az alapműködésre.

Miért is köthető mégis az innováció megvalósítása az informatikai funkcióhoz?

• Mert az informatikai funkció minden területet támogat a szervezeten belül, így minden terület elvárásait és lehetőségeit ismeri.
• Rendelkezik az üzleti adatok, és azok feldolgozási lehetőségei felett
• A technológiai trendek és az informatikai lehetőségek ismerete.

Kérdés, hogy a hagyományos elvárások (olcsóbban jobb és gyorsabb informatikai szolgáltatások nyújtása), vajon van-e elég idő és energia ténylegesen az innovatív megoldások kifejlesztésére?

Míg a működési fókusz alapvetően költség által meghatározott (mind IT üzemeltetési, mind üzleti költségek), addig az innovációs feladat inkább beruházásként értelmezhető, melynek hozzá kell járulnia az üzleti sikerességhez.

Az innovációs képesség megjelenítésében problémát okoz a felhasználói / vezetői látásmód is: az informatikát sokszor olyan szolgáltatásnak tekintik, mint pl. az elektromosság, és akkor tekintik az informatikát jól működőnek, ha kevés kapcsolatuk van vele (hiszen amikor kapcsolatba kerülnek, az azt jelenti, hogy valami nem működik).

Az informatika innovációs, partneri szerepének elfogadásának ugyanakkor alapvető feltétele az alap informatikai szolgáltatások megfelelő színvonalú biztosítása, és sokszor ez a feladat foglalja le az informatikai feladatok legnagyobb részét.

A kettős szerepnek az üzemeltetési oldalán jelenik meg a kiszervezés (outsourcing) lehetősége. Ekkor az informatikai funkció feladata napi szinten inkább a szolgáltatások koordinálása, ellenőrzése, így az a figyelem nagyobb része fordulhat az innovatív megoldások irányába.

Az informatikát akkor fogadják el innovátori szerepben, ha képes innovatív (és az üzlet számára megfelelő) szolgáltatások nyújtására. Ugyanakkor akkor képes az informatikai hatékonyan részt venni az üzleti innovációban, ha partnernek tekintik, és rendelkezésre állnak az üzleti elképzelések. Ez egy ördögi kör, melyből csak lépésről lépésre lehet kitörni.

Az informatika helye

Az innovációs képességet befolyásolja az is, hogy kinek felel az informatikai vezető. Ha az informatikai vezető a pénzügyi igazgatónak felel, úgy általában inkább költséghatékonysági feladatokat kell az informatikának ellátnia, míg a CEO, COO területnek beszámoló informatika nagyobb figyelmet tud fordítani az innovációra is.

Informatikai szolgáltatások menedzsmentje és az ITIL

Az informatikai üzemeltetés kapcsán jutott eszembe egy múlt heti történet. Mivel évek óta foglalkozom az ITIL-lel, ezért feltételezem, hogy az informatikai szakmában mindenki hallott erről a best practice gyűjteményről. Az egyik nap valaki rákérdezett a zakóm hajtókáján lévő ITIL kitűzőre, hogy mi is az. Mondtam, hogy adják a sikeres ITIL vizsgához. Egy szervezet velünk együtt lévő informatikai vezetője ekkor legnagyobb megdöbbenésemre megkérdezte, hogy mi is az?

Rá kellett döbbennem, hogy hiába oktatjuk különféle egyetemeken az informatikai szolgáltatások kezelése kapcsán a különböző módszertanokat (köztük kiemelten az ITIL-t), ez a korábbi informatikus generációk esetében még rejtett maradhatott (és sokszor enélkül is megy az élet). Sőt, sokszor tudnak az ITIL-ről, de azt gondolják, hogy ez csak a gazdag vállalatok privilégiuma.

Ez persze nem igaz, így most nem állom meg, hogy ne írjak legalább néhány szót az ITIL-ről.De mi is akkor az ITIL? Mit értünk informatikai szolgáltatásmenedzsment alatt? Egyszer megjelent az IT-Business-ben egy cikk erről, ami jól összefoglalja az informatikai szolgáltatásmenedzsment lényegét, kitérve az ITIL-re is. Azt hiszem ez egy elég jó összefoglalót jelent, és felesleges lenne ismételni az abban leírtakat.

„Nemcsak az informatikusok, hanem az üzleti területeken dolgozók előtt is világossá lett az elmúlt években, hogy az IT ma már más szerepet tölt be a vállalatok életében, mint az ezredforduló előtt. A számítástechnika őskorától kezdve egészen az 1990-es évek derekáig-végéig az informatika jobbára csak pontszerűen volt jelen a vállalatokban: egy-egy számításintenzív terület (például a pénzügy) munkáját segítette, és ezek az informatikai szigetek jól-rosszul kommunikáltak egymással. Az elmúlt egy évtizedben (és különösen az utóbbi pár évben) azonban hihetetlenül megnőtt az IT-nek az üzletmenetben betöltött szerepe”

Az ITIL egy brit kormányzati kezdeményezés során összeállított iparági best practice gyűjtemény, mely az informatikai üzemeltetés legjobb gyakorlataira építve készített egy komplex ajánlásgyűjteményt. Az ITIL alapvetően az informatikai szolgáltatások nyújtásának folyamataira, és a kapcsolódó megoldásokra koncentrál. Az ajánlásrendszert immáron harmadik verzióját éli, is kitágult a fókusza a stratégiai kérdésekre, és életciklus menedzsment irányába is (kicsit olyan érzése van az embernek, mintha a COBIT és az ITIL egymás irányába fejlődnének), így ténylegesen informatikai szolgáltatásmenedzsment ajánlásrendszerré, szabvánnyá vált.

Az ITIL szerepe első helyen a megbízható szolgáltatások nyújtásának biztosítása. Az ITIL alkalmazásával kevesebb hiba várható, csökken a leállások száma és időtartalma, a hibákat gyorsabban lehet kijavítani. Mivel hatékonyságnövelő hatása van, ezért már rövid távon is számolhatunk költségmegtakarítással (vagy legalább a munkaerő terhelésének radikális csökkentésével).

Az ITIL főbb területei a következők a v2 esetében.

• Szolgáltatások biztosítása: Konfiguráció menedzsment, változtatás kezelés, incidenskezelés, problémakezelés és kiadás kezelés (release management)
• Szolgáltatások támogatása: üzletmenet folytonosság, pénzügyi menedzsment, kapacitásmenedzsment, rendelkezésre állás menedzsment és szolgáltatási szint menedzsment.

Megjegyzendő, hogy bármennyire is igyekszik az ITIL lefedni az informatikai szolgáltatások körét, azért nem csodaszer. Nem lehet minden ajánlását, minden szervezet részére gondolkozás nélkül alkalmazni, hanem testre kell szabni, meg kell feleltetni egy egyedi elvárásoknak. De még ha nem is vezet be egy szervezet ITIL alapú folyamatokat, sok megközelítése, megoldása hasznos lehet.

Sőt, sokszor tapasztalhatjuk azt, hogy egy szervezet saját maga fejleszti szinte tökéletesre belső folyamatait, aztán meglepve tapasztalja, hogy az ITIL hasonló dolgokat javasol. Az ITIL segít sok fáradtságot, gondolkodást és energiát megtakarítani azáltal, hogy bemutatja az egyes területek kiforrott megoldásait. Így az ITIL-t lehet egyfajta ötletgyűjteményként is hasznosítani. Persze az ITIL strukturált felépítését követve sokkal több előny elérhető, és egységes, kontrollált formában hajthatóak végre az egyes feladatok. Az ITIL segít az ellenőrzésben, a teljesítmény kimutatásában, a hatékonyabb munkavégzésben, sőt, közelebb hozzá egymáshoz az üzleti és informatikai gondolkodást is.

Épp most hallottam egy történetet egy biztosító informatikai üzemeltetéséről, ahol a deklarált fejlesztési cél nem az ITIL bevezetése volt, hanem a jó működés elérése. Ehhez felhasználják az ITIL alapelveit, meggondolásait, de alapvetően saját megoldásban gondolkodnak.

A közelmúltban jelent meg az ITIL v3 verziója, mely kibővíti az ITIL fókuszát, és a korábbi két alapkönyv helyett már 5 alapkönyvben mutatja be az egyes területek összefüggéseit. Az ITIL v3 életciklus modellje a stratégiától kezdve a megvalósításig és üzemeltetésig igyekszik minden területet lefedni, szem előtt tartva az üzleti és informatikai gondolkodás erősebb összerendelését. De a v3 sajátosságai azt hiszem megérnek majd egyszer akár egy külön bejegyzést is.

Működési kockázati kategóriák kialakítása

Ahogy már korábban bemutattam, a működési kockázatokra hét veszteségkategóriát szokás kialakítani, és az egyes kockázatokat a pénzügyi szervezetek esetében nyolc üzletág szerint szokás értelmezni. Így összesen akár 56 csoportot is kialakíthatunk.

Ha nem csak becsülni, hanem kezelni is szándékozunk a kockázatokat, akkor szükséges a kockázatok okainak is a vizsgálata, ami a gyakorlatban azt jelenti, hogy minden egyes osztály esetében szükséges értelmezni a folyamatokban rejlő, emberi, technológiai, illetve a külső környezet kockázatait (ld. ábra).

Problémát jelenthet, hogy egy esemény akár több kategóriát (üzleti és veszteség) is érinthet. Ebben az esetben a veszteségek nyilvántartása, illetve az erre épülő számítások már meglehetősen bonyolulttá válnak, ezért elengedhetetlen a kockázatok nyomon követésére az informatikai megoldások használata.

További problémát jelent (ami egy pénzintézet szempontjából inkább örömteli dolog), hogy a kockázati események alacsony száma miatt kevés adat áll rendelkezésre. A 7×8-as mátrix egyes osztályaiban már a néhány tucat esemény is kiemelkedő lehet, de sokszor egy-egy ilyen osztályba egyetlen esemény sem jut. Habár ez azt jelenti, hogy a pénzintézet viszonylag biztonságban van, kockázatkezelés szempontjából nem jelent elégséges alapadatot.A probléma kiküszöbölése érdekében érdemes egyes veszteség, vagy üzleti kategóriákat összevonni, és így nagyobb kockázati osztályokat kialakítani. Megjegyzendő, hogy míg a veszteségkategóriák összevonása torzíthatja a veszteség-eloszlási elvárásainkat (és így a modellépítést), addig az üzletágankénti összevonás esetében az ilyen problémákkal kevésbé kell szembesülni.

A statisztikai eszközök alkalmazása ellenére ugyanakkor a folyamatalapú kockázatértékelést sokkal inkább üzletágakhoz, mintsem veszteségkategóriákhoz lehet kötni. Ebben az esetben a folyamatokhoz feltárásával jobban elemezhetővé válnak a kockázatok okai, így nagyobb lehetőség nyílik azok kezelésére.

Az összevonások során tehát már döntéshelyzetbe kerülünk a tekintetben, hogy a statisztikai alapú, a kockázatértékelésnek nagyobb lehetőségeket nyújtó megközelítés, vagy pedig a folyamat alapú, és így a kockázat kezelésének nagyobb teret adó megközelítés irányába fordítjuk gyakorlatunkat.

A szabályozási elvárások miatt a pénzintézetek rövid távon inkább a statisztikai alapú megközelítés irányába indultak el (kockázat értékelése), míg a tényleges kockázatkezelés inkább hosszabb távú gyakorlat lehet.A kategóriák kialakítása esetében legfontosabb annak szem előtt tartása (és ez nem csak a működési kockázatokra igaz), hogy ne lőjünk ágyúval verébre, azaz a fejlett megközelítéseket csak akkor használjuk, ha biztosítható, hogy egy adott osztályban rendelkezésre fog állni a statisztikai elemzésekhez szükséges adatmennyiség.

Egy informatikai vezető kezdeti lépései

Nemrég egy beszélgetés során ahhoz a témához jutottunk el, hogy mik lennének az első feladatok, mellyel egy új informatikai vezetőnek szembesülnie kellene, illetve milyen irányokban is kellene elindulni. Akkor összegyűjtöttem a magam lépéseit (és le is írtam), aztán tegnap éjjel rákerestem az interneten, hogy van-e erre valamiféle népi bölcsesség? Én a következőket tartanám fontosnak, hogy képbe kerüljünk egy adott szervezet informatikai területével, és ki tudja jelölni a cselekvési utakat (csak vázlat szinten, mert minden témáról külön lehetne egy bejegyzést írni):

1. Üzleti igények megismerése: mit várnak az informatikától, milyen szolgáltatások vannak, mi mennyire fontos, mik a jövőbeli üzleti tervek, trendek az adott szektorban. Az informatika feladata nem csak az, hogy kiszolgálja ezeket az igényeket, hanem az is, hogy lehetőséget biztosítson új megoldások használatára, mellyel a stratégia kiteljesíthető. Szükséges ezért látni, hogy az egyes üzleti igények közül mit, és hogyan sikerül teljesíteni.
2. Az üzleti igények mellett szükséges, hogy a felhasználói igényeket is lássuk. Sokszor összemosódik a felhasználói és üzleti igény, de az üzlet a stratégiai irányvonal támogatását várja el, míg a felhasználók ténylegesen az adott eszközökkel dolgoznak. Hiába vannak jó üzleti megoldásaink, ha a felhasználók ezeket nem tudják elfogadni. Ráadásul az üzleti és felhasználói oldal sokszor másképp látja ugyanazokat a kérdéseket, és más válaszokat is adnának egy adott problémára (persze az informatika egy harmadik oldalt képvisel). Éppen ezért nagyon fontos, hogy ezen szereplők törekvéseit összehangoljuk.

A tudásmonopóliumokról

Tudásmonopóliumokról akkor beszélhetünk, ha egy, vagy kevés ember kezében összpontosul egy szakterületi tudás. A tudásmonopolisták nem csak biztosíthatják a szervezeti hatalmukat, de elismerést, sőt anyagi elismerést is kaphatnak. Ráadásul kulcsemberként az elbocsájtástól sem kell félniük. Ugyanakkor létük veszélyt jelent a szervezetekre: nem kell feltétlenül rossz szándékot feltételezni, de mi van akkor, ha valaki megbetegszik? Akkor ki kezeli az adott területet? Sok cégnél látjuk, hogy ilyenkor megáll az élet, és a munkában akár több hetes csúszások is előfordulhatnak.Hogyan tudjuk kezelni a tudásmonopóliumokat? A legegyszerűbb lenne megelőzni a kialakulásukat.

Néhány éve egy nagy megyei jogú város önkormányzatát látogattuk meg Szabó Zoltán kollégámmal, ahol az informatikai vezetővel beszélgettünk. Valahogy szóba került a tudásmegosztás és megtartás problémája. Az önkormányzat alapvetően nem egy olyan szervezet, mely hosszú távon képes megfizetni a jó informatikusokat, ezért nagy a fluktuáció, és mindig fennáll a veszélye, hogy kulcsember távozik. Az informatikai vezető az ilyen problémákat úgy oldotta meg, hogy a feladat és szakértelmi területek átfedésben vannak egymással, azaz mindenki legalább két területhez ért, és minden területhez legalább ketten értenek. Továbbképzésre nem egy embert küldenek, hanem mindig legalább kettőt, ráadásul kötelességük, hogy megosszák a tréning anyagait, és az ott szerzett tapasztalatokat egy belső minikonferencián mutatják be. Így a szakterületi tudás széles körben megosztott a szervezetben, és nincs lehetőség arra, hogy tudásmonopóliumok alakuljanak ki.

Ha már létező tudásmonopóliummal kell megküzdeni, az lényegesen nehezebbnek bizonyul.

Egy másik szervezetben egy informatikai szakértő esetében alakult ki tudásmonopólium. Nem volt igazán rossz szándék a folyamatban, a cégnek kevés embere volt, és a szakértő sem érezte az elszántságot, hogy megossza tudását. Ráadásul még élvezte is a szervezet feléje irányuló elismerését. Egy idő után azonban a szervezet felismerte, hogy ez a helyzet nem ideális, mivel a szakértő nem tudott egyszerre minden feladatot megoldani, és ez hátráltatta a munkát. Jobb lett volna, ha többen is értenek az adott területhez. Fel is vettek két új kollégát, akiket a szakértő mellé osztottak be, remélve, hogy gyorsan átveszik az ő tudását. A szakértő ekkorra ugyanakkor már érezte kiváltságos helyzetét, és nem törekedett tudásának megosztására.

A szervezet vezetése ekkor fondorlatos módon tudatosan igyekezett túlterhelni ezt a szakértőt, és sok (sokszor mondvacsinált) feladattal látták el, melyek megoldására szűk határidőket szabtak. A szakértő panaszkodott, hogy több időre lenne szüksége, és mennyire túlterhelt, de főnökeinek válasza csak az volt, hogy akkor használja jobban a beosztottjait. A szakértő panaszkodott, hogy a beosztottjainak nincs meg a szükséges szakértelme, de főnökei arra biztatták, hogy mesélje el nekik, hogy mit is kell tudni.

A megközelítés gyors sikert hozott: a szakértő már az első hónapban feladta a küzdelmet, és úgy igyekezett magát tehermentesíteni, hogy betanította beosztottjait. Ezzel elhárult a céget fenyegető hatékonyságbeli veszély is, és a tudás elvesztésének veszélye is. Hozzá kell tenni, hogy nagyon taktikusan a vezetés továbbra is megadja a tiszteletet és elismerést a szakértőnek, illetve most már a szakértők csoportjának, így az történetünkben szereplő informatikai szakértő továbbra is örömmel végzi munkáját.

Ha a tudásmonopólium maga a kultúra része, akkor viszont már radikális lépésekre is szükség lehet.

Szlovén ismerőseim tájékoztattak hónapokon keresztül szinte naprakészen egy szlovén energetikai cég privatizációjával kapcsolatos eseményekről: a szlovén céget, melyet még a régi Jugoszlávia keretei között hoztak létre, a privatizáció során egy francia cégnek adtak el. Mivel a cég a Jugoszláv szocialista rendszer szellemiségét tükrözte, ezért működése távol állt a hatékonyságtól. A privatizációs szerződés keretében az új tulajdonosnak lehetősége volt arra, hogy az átszervezés során a dolgozók jelentős részét elbocsássa. A vállalat dolgozói – igazi szocializmus visszamaradt monstrumként – egy-egy szakterületért voltak felelősek, melynek tudását egyedül birtokolták. Így nagyobbrészt mindenki kiskirály volt a maga szemétdombján. Az új tulajdonosok felismerték a problémát, ezért kezdetben nagy erőfeszítéseket tettek, hogy egy tudásmegosztási kultúrát alakítsanak ki, így ezeket a tudásterületi silókat megszüntessék. A dolgozók ugyanakkor nem igazán bíztak az új tulajdonosban, és úgy gondolták, hogy egyedi tudásuk és szakértelmük biztosítja, hogy megtarthassák állásukat. Így a tudásmegosztási kultúra kialakítására tett minden törekvés meghiúsult.

Egy idő után a tulajdonosok türelme kezdett elfogyni, és egyre eredményeket vártak az új vezetőségtől, akik addig nem mertek nagyobb átalakításba kezdeni, amíg a tudásmonopóliumok problémáját nem oldották meg. A probléma az volt, hogy a dolgozók leépítésével akár a működést is veszélyeztető tudást veszíthetett volna a vállalat. A vezetőség a bátorítás és a szép szavak után a fenyegetés eszközéhez nyúlt: deklarálta, hogy aki nem tesz meg mindent a szakterületi tudás megosztása érdekében, attól meg fognak válni.

A dolgozók számára ez igazán nem jelentett új fenyegetést, és ezt gondolták: “Ha megosztom a tudásom, akkor már nincs szükség rám, és kirúgnak. Ha nem osztom meg, akkor is kirúgnak. Akkor mégis inkább megtartom magamnak, hátha még mindig fontosnak tartanak.” Mivel ez a gondolat elég általános volt, ezért a tudásmegosztási kezdeményezések megint kudarcot vallottak.

Az idő múlásával ugyanakkor a tulajdonosok egyre türelmetlenebbek lettek: az átszervezések késése miatt a cég nem tudott hatékonyan működni, mely továbbra is inkább veszteséget, mint nyereséget termelt. Ebben a helyzetben a vezetőségnek nem maradt már sok választása. Megismételték, hogy aki nem működik közre a tudás megosztásában, azt kirúgják, de aki megfelel a vezetőség elvárásainak, azt biztos, hogy megtartják. A cég vezetése így egyszerre fenyegetett, és vetette fel a jutalmazás (a munkahely biztonságának) lehetőségét.

A dolgozók ennél a pontnál bizonytalanodtak el. Akadt egy-két dolgozó, akik már feladták a küzdelmet, és megosztották tudásukat másokkal, illetve dokumentáltak bizonyos folyamatokat, eljárásokat. Ezt a kevés dolgozót a tulajdonosi testület kiemelte, látványosan megjutalmazta, és példaként állította a többiek elé. A vezetőség a jó dolgozó legfontosabb kritériumának a tudásmegosztást tette. Így aki meg akarta tartani az állását, csak egyféleképpen bizonyíthatta, hogy jó dolgozó: úgy, hogy megosztotta a tudását. Ráadásul a cégnek már nem volt vesztenivalója: ha kirúg kritikus tudással rendelkező embereket, akkor is veszteség éri, de ha nem hajtja végre az átszervezést, akkor is. Így a látványos jutalmazás mellett igyekeztek megtalálni néhány hangadó véleményformálót a szervezetben, és szintén látványosan megváltak tőlük.

Ekkor felgyorsultak az események: a dolgozók igyekeztek bizonyítani, hogy jó dolgozók, ezért megosztották a tudásukat, és reménykedtek az elismerésben. De ez az elismerés csak az elsőknek járt. A kampányszerű tudásmegosztás után a vezetőség már nyugodtan végrehajthatta az átszervezést, és radikális létszámcsökkentést hajtott végre. Érdekes módon az átszervezés után a tudásmegosztás értéke csökkent, és a cég újra elindult a tudásmonopóliumok kialakulása irányába: a dolgozók már nem csak a tulajdonosban és a vezetőségben, hanem már egymásban sem bíztak. Persze néhány év még kell, hogy újra megjelenjen ez a probléma, addig is valahogy működik a szervezet.

A fenti néhány példán keresztül is láthattuk, hogy a tudásmonopóliumok milyen veszélyt jelenthetnek. Gondoljuk csak el, a saját szervezetünkben hol vannak tudásmonopóliumok, és fel tudunk-e készülni ezek megszüntetésére?

… már megint a tudásmegosztás motivációjáról

Eszembe jutott, amit egyszer Lawrence Prusak mesélt, ifjúkori élményeként (egy dublini tudásmenedzsment konferencián). Lassan persze meggyanúsítható vagyok azzal, hogy reklámozom a McKinsey-t, de mit csináljak, ha egyszer ők szolgálnak adalékkal arra, hogy mindenki példálózzon velük, idézgesse őket, vagy akár vitatkozzon a megállapításaikkal. A McKinsey esetében fontos a tudásmegosztás, ezért sok tapasztalatuk mindenki számára látható (és ennek örülünk).

A McKinsey tanácsadó cégnél nem csak a szervezeti kultúra, hanem bizonyos beépített szabályok, mechanizmusok is segítik az együttműködést, a tudás megosztását, a kollégák segítését. L. Prusak mesélte egyszer, hogy amikor a cégnél járt, találkozott egy fiatal tanácsadóval, akinek egy nemzetközi projekhez volt szüksége segítségre, több országból és többnyire jóval felette álló tapasztalt tanácsadóktól, szakértőktől és vezetőktől. A fiatal dolgozó igen lelkesen felhívta ezeket az embereket, és természetesen egyiküket sem érte el, mivel nagyon elfoglaltak voltak, de minden ember titkárnője visszahívást ígért. Természetesen, ha egy vezető visszahívást ígér egy fiatal munkatársnak, azt nem lehet komolyan venni, hogy ténylegesen meg is történik. Prusak ebbéli kétségeit megosztotta a tanácsadóval, aki mosolyogva csak annyit mondott: – “Csak figyelj!”

A nap végére minden szakértő, tapasztalt tanácsadó és vezető visszahívta és segített a munkájában. Egy ilyen jelenség sok cég esetében kisebb csodaként is felfogható, hiszen szinte mindenhol a hierarchia alacsonyabb fokán állók keresik addig a vezetőket, amíg elérik, és akkor sem biztos, hogy éppen lesz idejük velük foglalkozni. A megoldás a McKinsey belső szabályozásában keresendő, miszerint a nem léptetik elő azt, aki nem segíti a másikat – jelen esetben, aki nem hívja vissza azt, aki kereste.

Ez egy olyan szabályozás, mely számonkérhető, és betartatható. A szabályozás egyfajta szemléletmódot is közvetít, értéket hordoz, mely beépül a szervezeti kultúrába. Persze nem biztos, hogy ez a büntetés alapú szabályozás mindenkinek annyira elfogadható – végső soron ez is kultúra kérdése.

… még mindig a tudásmegosztás motivációjáról

Eszembe jutott még egy tanulságos történet a korábbi bejegyzéssel kapcsolatban

Egyszer az egyik nemzetközi tanácsadással foglalkozó cégnél jártam. Ott a HRM vezető volt a tudásmenedzsment felelőse, de ennek ellenére nem a perszonalizációs tudásmenedzsment stratégia, hanem a kodifikáció volt a meghatározó: a dolgozókat arra kérték, hogy projekttapasztalataikat egy elektronikus tudásbázisban rögzítsék. A befektetett munka motivációjaként minden, a tudástárban feltöltött dokumentumért pontokat szerezhettek. A rendszer látszólag kiválóan működött, a tudástárba rendszeresen töltöttek fel dokumentumokat a kollégák.

Látogatásomkor beszélgettem a tanácsadókkal is, akiknek a tapasztalatát ebben a megoldásban rögzítették. Az egyik tanácsadó kolléga igen rossz véleménnyel volt a tudásmegosztási rendszer működéséről: elpanaszolta, hogy igen nehéz releváns információkat találnia, mivel a tudáselemek jelentős része értéktelen, nem szól semmiről. Sőt, elrettentésképp rákeresett a rendszerben egy tudáselemre, mely a következőképpen épült fel: az első bekezdés egy általános bevezető egy szakmai témáról (egy szót sem értettünk belőle, de valószínűleg a mi hibánk), innentől kezdve több bekezdésen át egy Grimm mese következett (emlékeim szerint a Piroska és a farkas), majd az utolsó bekezdés az első bekezdés ismétlése. Persze mivel nemzetközi cégről van szó, minden angolul.

Ez az eset rávilágított arra, hogyan torzulhat el a tudásmegosztás gyakorlata, a hosszú ideig fenntartott ösztönző eszközök mellett. Idővel – mivel úgy érezték, hogy a tudásmegosztás már beépült a szervezet kultúrájába – ezt az ösztönzőt megszüntették. Sajnos az eredménye nem az ilyen értéktelen tudáselemek megszűnése lett, hanem az, hogy a tudásmegosztási hajlandóság gyakorlatilag nullára esett vissza. Mi volt ennek oka?

1. A tudásmegosztás motivációja félresiklott: a dolgozók nem a tudásmegosztás hasznáért osztották meg tapasztalataikat (illetve egy idő után már bármit leírtak ami az eszükbe jutott), hanem a jutalomért. Amikor a jutalom ígérete megszűnt, természetesen megszűnt a tudásmegosztási hajlandóság is. Ebben az esetben elmaradt a szervezeti kultúrába való beépítés, ami talán nem is olyan könnyű.
2. A szervezetben (mint sok már nagy tanácsadó cég esetében is) igen magas a fluktuáció: egy 3 éve a cégnél dolgozó ember már veteránnak számít. Sok dolgozó tapasztalatot szerezni megy az ilyen cégekhez, majd néhány év intenzív tanulás, és az önéletrajzban igen jól mutató bejegyzés után továbbáll. Ilyen szervezetben nehéz változtatni a kultúrát, és rögzíteni a tudásmegosztás értékét. Ebből a szempontból a tanácsadó cégnek igen nagy kihívással kellett szembenéznie, ha a kultúrát változtatni akarta.
3. A tudásbázis szemmel láthatólag nem volt karbantartva. A karbantartás hiánya miatt igen sok értéktelen dokumentum maradhatott a tudásbázisban (amiért ráadásul még jutalmat is kaptak a tanácsadók), így csak nagy energia-befektetéssel lehetett rátalálni a szükséges információkra. Ha az elérhető tudás minősége csökken, akkor maga a rendszerbe vetett bizalom is csökken, így a rendszert magát egyre kevesebben fogják használni. Ekkor már a rendszert nem is igazán érdemes tovább fejleszteni, karbantartani, és a folyamat megállíthatatlan lesz. (Ezt a folyamatát hívják az elektronikus tudásbázisok halálos spiráljának)

Miért szükséges a működési kockázatok felmérése és kezelése?

Az Uniós és a hazai pénzügyi szabályozás célja, hogy a pénzügyi szervezetek minél jobban feltérképezzék és becsüljék mind működési, mind egyéb kockázataikat. Habár lehetőség van háromféle tőkefedezet-képzési megközelítés használatára is, a szabályozás mégis arra motiválja a pénzintézeteket, hogy tárják fel várható kockázataikat, illetve az ezekre vonatkozó adatokat érthető, és átlátható formában mutassák be. Ekkor ezen pénzintézeteket alacsonyabb tőkefedezeti kötelezettség terheli.

De mik is ezek a módszerek?

1) Basic Indicator Approach (BIA): Legegyszerűbb felépítésű intézetek számára, a bank előző három évi átlagos éves bruttó jövedelmének fix százalékaként fejezhető ki.

2) Standardised Approach (STA): Az egyes tevékenységeket nyolc terület alá kell besorolni, majd az egyes területekre kell meghatározni (bruttó jövedelem alapján) a szükséges tőkefedezetet, majd ezeket kell összesíteni.
2/b) Alternative Standardise Approach (ASA): A STA megközelítés különleges válfaja az ASA, melyben bizonyos üzletágak esetében a bruttó jövedelem helyett a hitelezési tömeget veszik alapul.

3) Advanced Measurement Approach (AMA): A pénzintézetek az általuk meghatározott kockázatkezelési rendszer által meghatározott kockázatokra képeznek fedezetet.

Míg a BIA módszer alkalmazásának nincs különösebb feltétele, addig a szabályozás szerint a pénzintézeteknek azt a megközelítést kell alkalmaznia, mely leginkább megfelel működési és kockázatvállalási profiljának. Elvileg a felügyeleti hatóságok (nálunk a PSZÁF) ezt ellenőrizhető, sőt mintegy benchmark-ként összevetheti más, hasonló pénzintézetek gyakorlatával.

Az előírások lehetővé teszik – bizonyos feltételek teljesülése esetén – a megközelítések kevert alkalmazását is. Azaz egy pénzintézet számára nem kötelező minden területen pl. az AMA megközelítés alkalmazása. Annál is inkább, mivel a BIA, STA (ASA) megközelítések nem veszik figyelembe a tényleges kockázatokat, de az AMA megközelítés alkalmazása nem éri meg minden esetben a befektetést.

A pénzintézetek motivációja erősen az AMA megközelítés irányába mozdult el. Bár nagyobb munkabefektetést jelent a módszer alkalmazása, az megközelítést követve nem csak alacsonyabb a kötelező tőkefedezet, hanem a pénzintézetek saját kockázataikat is jobban megismerhetik és kezelhetik.

Persze a kockázatok becslése, és azok kezelése nem esik ugyanabba a kategóriába. A becslésre, és így a felügyeleti szervek számára is elegendő a LDA (Loss Distribution Approach) alkalmazása, ugyanakkor ez a módszer még nem mutatja be a kockázati területeket, és nem ad lehetőséget a kockázatok kezelésére, csökkentésére. Pedig a kockázatok csökkentésével nem a csak a működési hatékonyság javulna és a várható veszteség csökkenne, de végső soron a kötelető tőkefedezet képzés is csökkenne. Persze a szabályozás eleve csak az AMA megközelítést alkalmazók esetében engedélyezi pl. a működési kockázataikra kötött biztosítások csökkentő hatását is (a teljes tőkekövetelmény 20%-ig vehető figyelembe).