Elmaradt írások... (tüköroldal információ)

A blog a továbbiakban a http://tudman.wordpress.com/ oldalon is elérhető. A korábbi bejegyzések ott is megtalálhatóak.

Sőt, néhány bejegyzés csak ott található meg, ezek a következők:

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?

...tovább...

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).

...tovább...

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.

...tovább...

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.

...tovább...

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.

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 7x8-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.
3. A rendelkezésre álló informatikai infrastruktúra állapota, infrastruktúra menedzsment folyamatok (beleértve a biztonságot is). Kérdés, hogy mennyire tudatos, átgondolt az infrastruktúra üzemeltetése: ez alapvetően hatékonysági és költség kérdés. Kérdéses, hogy milyen az informatikai terület szállítóival a viszony, milyenek az anyagi lehetőségek. Persze a tudatosság kialakítása idővel elkerülhetetlen, kérdés csak az, hogy mennyi idő, és erőforrás áll ehhez rendelkezésre. Ehhez a lépéshez jó segédeszköz és iránymutató az ITIL nemzetközi, best practice-en alapuló módszertan (aminek most már a 3. verzióját fogyasztjuk).
4. Folyó projektek, fejlesztések: az üzleti igényekből levezethető, hogy milyen fejlesztésekre, milyen változtatásokra van szükség. Kérdés persze az is, hogy ezen fejlesztések milyen állapotban vannak, illetve projektvezetés szempontjából hogyan áll a terület. Nem csak a projektcélok és az üzleti elvárások összhangjának vizsgálata szükséges, hanem a projektek portfolió kezelése is, azaz hogy a projektek kiegyensúlyozottan támogassák az informatikai szervezet fejlődését (mind rövid, mind közép, mind hosszú távú elképzelések megválaszolása, illetve a stratégia támogatás mellett, az üzemeltetés fejlesztése is).
5. Innováció: A pillanatnyi helyzetkép segít elindulni, de egyben kijelöli a rövidtávú fejlesztési elvárásokat is. A rövidtávú fejlesztési lehetőségek mellett ugyanakkor szükséges lehet az innovatív, akár hosszabb távon megtérülő fejlesztések mérlegelése is. Olyan beruházásoké, melyek lehet, hogy nem jelennek meg felhasználói, vagy üzleti igényként, de mégis hozzájárulhatnak a szervezeti hatékonyság növelésére. Itt gondolok a virtuális munkavégzés lehetőségeire, vagy a tudásmenedzsment megközelítések (akár web2.0 megoldások által kiegészített) lehetőségeire is.
6. Érdemes lenne vizsgálni a szervezet létező informatikai stratégiáját, vagy ha nincs, az erre irányuló projektet el kellene indítani. Az informatikai irányítás keretrendszereként pedig a COBIT aktuális verzióját választanám (most épp 4.1-nél tartunk), mely jó segédletet nyújt az informatikai terület vezetésére, illetve ellenőrző listát a főbb tevékenységek teljességének vizsgálatához, azaz gyakorlatilag az IT Governance (informatikai kormányzás, irányítás) alapvető eszköze. Ha ez még nem lenne bevezetve egy szervezetnél, valószínűleg egy hosszú távú projekt keretében érdemes lenne (legalább részeiben) bevezetni.

Sajnos semmilyen írásból nem derült ki számomra, hogy mit is kellene tennie egy új informatikai vezetőnek, de úgy tűnik, hogy az alkalmazott filozófiát tekintve nem járok messze az igazságtól. Néhány elvárás, tapasztalat ugyanakkor másoktól is összefoglalható:

A Corporate Executive Board egy felmérése szerint nagyvállalati az informatikai vezetők 34%-a vált állást egy éven belül, azaz átlagosan az informatikai vezető hozzávetőlegesen 3 évet tölt el egy munkahelyen. Ez igen magas fluktuációt jelent, és így egy informatikai vezetőnek nincs sok ideje, hogy megvalósítsa elképzeléseit (és valószínűleg a szervezet türelme is véges az eredmények felmutatása tekintetében.

„The first 100 days should be spent observing, analysing, and brainstorming, but after that, actionable steps and deliverable results should be the key focus.”

(forrás: InformationWeek)

Lehet stratégiai szinten pozícionálni az informatikát, lehet kiemelni a fontosságát, de tudjuk, hogy a legtöbb szervezet esetében az informatikának amolyan megtűrt, háttértámogató szerepe van. És ebből a helyzetből az informatika – és az informatikai vezető – csak úgy tud kitörni, ha bizonyítja sikerességét. És a bizonyítás első körben nem a stratégiai világmegváltás, hanem sokkal inkább csak a szolgáltatások magas szintű, és kiszámítható biztosítása. Ha ezt nem sikerül teljesíteni, nincs is értelme hosszú távú tervekről beszélni.

Persze ahhoz, hogy meglegyen az összhang az üzleti / felhasználó elvárások, és az informatikai szolgáltatások között, szükséges, hogy egy informatikai vezető értse mind az üzlet, mind az informatika nyelvét. Én nem értek egyet teljesen azokkal a véleményekkel, hogy az informatikai terület vezetőjének bármilyen üzleti területi vezető jó lehet. Szerintem igenis szükséges, hogy a vezetői ismerje az általa irányított terület lehetőségeit, és ne csak a pénzbeli megtérülési kérdésekben tudjon gondolkodni. Ebből adódóan szerintem egy jó informatikai vezetőnek meglehetősen keverék tevékenységet kell ellátnia.

Itt talán az egyik legnagyobb kihívás az informatikai beruházások / projektek megtérülésének bemutatása, de erről majd inkább egy másik alkalommal írok.

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.