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.

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

A tudásmegosztás motivációja

Péntek délután volt egy beszélgetés, mely a közigazgatási tudásmegosztásról szólt: hogyan lehet kinyerni azt a tudást, ami az emberek fejében van. Hogy miért nem osztják meg az emberek a tudást? Mert így szokták meg (kultúra), mert jó nekik (tudásmonopólium), mert időt és energiát igényel (és erre már nem jut).

Azt hiszem az asztal körül mind egyetértettünk abban, hogy a tudásmegosztási törekvéseket a tudásbázis létrehozásának fázisában valamilyen módon motiválni kell, és erre rengeteg példát láthatunk különböző szervezetek gyakorlatában. Ez legtöbbször valamiféle jutalmazás: : pontgyűjtés (amit be lehet cserélni ajándékokra), jutalom, repülőjegy, utazás, stb.

A tudásbázis alapú tudásmegosztási megoldások egyik nagy problémája a feltöltések motiválása. Ennek érdekében sokféle ösztönző megoldást alkalmaztak: Sok vállalatnál ez direkt jutalmazást jelent (pénzbeli elismerés, beváltható jutalompontok, stb.).

• A KMPG a „give to get” megoldást alkalmazta,azaz a dolgozók addig nem férhettek hozzá a tudásbázishoz, amíg maguk nem járultak hozzá valamivel.
• Sok esetben a vezetői példamutatás volt motiváló erejű: a Chevron esetében a vezetők személyesen mondogatták a dolgozóknak, hogy járuljanak hozzá a tudásbázishoz, miközben maguk is számtalan bejegyzést írtak.
• Hasonló történt a Bechtel esetében is: a vezetők, akik meglátogatták az építési helyszíneket, és maguk is sok bejegyzést írtak, arra ösztönözték a mérnököket, hogy ötleteiket, tapasztalataikat írják le, "akár egy sajtpapírra is".
• És sokadik megoldásként meg kell említeni a nemzetközi Ernst&Young tanácsadó céget, ahol a tudásbázishoz való hozzájárulást a dolgozói értékelés részévé tették.

ld még: Dixon (2000) Common Knowledge

Ugyanakkor a jutalom irányába ható motiváció idővel károssá válik: a dolgozók nem a köz hasznáért, a tudás megosztásából eredő szervezeti hatékonyságnövelésért osztják meg a tudásukat, hanem a jutalmakért. Ráadásul pont annyit tesznek ezért, hogy megkapják a jutalmat.

Éppen ezért a motivációs rendszer fenntartása csak addig hasznos, amíg egy tudásbázisban elő nem áll a kritikus tömeg: az a tudásmennyiség, ami már felhasználható, és érzékelhető hasznot jelent a dolgozóknak. Ekkor - remélhetőleg -a dolgozók látják, hogy az ő általuk befektetett energia, munka, tudás sokszorosát kaphatják vissza a tudásbázisból, és ez az a pont, amikor a tudásmegosztást már a saját (tudásmegosztáshoz kapcsolódó) haszon motiválja. Ha ez beépül a kultúrába, akkor ez fenntartható motivációt jelent, míg a különböző ösztönzők - amellett, hogy erőforrásokat vonnak el a szervezettől - csak rövid ideig képesek eredményt biztosítani.

Egy magyar telekommunikációs cég az informatikai folyamatainak támogatására olyan rendszert szándékozott bevezetni, melyben az egyes felmerülő hibákhoz kapcsolódó megoldásokat, illetve a megoldáshoz szükséges tudást elérhetővé tette. A rendszer működéséhez szükséges volt a dolgozók hozzájárulása is, mégpedig a tudásbázis feltöltéséhez, és folyamatos karbantartásához: minden egyes felmerülő problémánál dokumentálni kellett, hogy mi volt a hiba, és hogyan lehet megoldani, valamint ehhez milyen tudás vagy eszköz szükséges.

A dolgozók nagyon sokáig ellenezték ennek az eszköznek a bevetését, mivel ez számukra többletmunkát, nagyobb leterhelést és energiabefektetést jelentett, miközben amúgy is jóval munkaidőn túl dolgoztak. Az ezt javasló, és a bevezetést felügyelő tanácsadókat ellenségnek tekintették. A motivációt egyedül a főnökök utasítása, szoros kontrollja és számonkérése jelentette.

Az ellenállás egészen addig tartott, míg a gyakorlatban meg nem tapasztalták, hogy milyen előnyöket rejt a rendszer: azaz a kezdeti nagyobb energiabefektetés később - miután a rendszerbe már bevitelre került a kritikus tömegű tudás - többszörösen megtérül: a tudásbázis felhasználásával a problémaelhárítási idők töredékére csökkentek, és a dolgozók időben be tudták fejezni munkáikat, és így több időt tölthettek családjukkal. Ettől a ponttól kezdve nem volt már szükséges a főnöki számonkérés és kontroll, a tapasztalatok dokumentálása beépült a napi gyakorlatban, illetve a szervezeti kultúrába.

...még mindig a informális hálózatokról

Úgy egy éves már a cikk, de újra kezembe került, és persze eszembe jutott néhány gondolat . A cikk egy történettel kezdődik:

Ken Loughridge vállalatának frissen kinevezett IT szolgáltatási központ vezetője Új Zélandon. Természetesen senkit sem ismer, még a szervezet felépítése is kicsit idegen. Annak érdekében, hogy jobban megismerje mit és kiket kell vezetnie, elhatározta, hogy feltérképezi a munkatársakat. Ennek keretében felhasználta cégének a már meglévő felmérését, melynek keretében azt kérdezték meg a kollégáktól, hogy kikkel konzultálnak gyakran, kitől kérnek segítséget, illetve ki kér tőlük segítséget.

A válaszokat egy szoftver segítségével vizalizálták, és előállt egy olyan kapcsolati ábra, mely hasonlított a repülőtársaságok útvonalterveire: csomópontok és kapcsolatok. Ez a megoldás segített Loughridge-nek látni a szervezet informális kapcsolatait is.

A térkép alapján Laughridge azonosította a legfontosabb technikai szakértőket, akiket kulcsembereknek gondolt, és elhatározta, hogy személyesen is találkozik velük.

Fél évvel később egy kulcspozícióban lévő menedzser távozott a cégtől. Hogy mérsékelje az így kialakult helyzetet, Loughridge azonnal felvette a kapcsolatot a távozó kollégával szoros informális kapcsolatban állókkal, és igyekezett ezeket az embereket összekötni.

Az informális, vagy szociális hálók felhasználásáról már írtam korábban, de ebben az esetben ezt egy menedzsment eszköznek használták: nem nyilvános nyilvántartás, de segíti a vezetőket abban, hogy értsék a szervezet működését.

Egy formalizált szociális háló alkalmazás felhasználásával nem hiszem, hogy képesek lennénk a valóságban is létező informális kapcsolatokat lemásolni. Egy ilyen alkalmazás haszna ott jelenne meg, ha inkább a szakmai közösségek (communities of practice) számára nyújtanánk valamiféle együttműködési, tudásmegosztási terepet. Erre már egy levelezőlista, egy egyszerű fórum megoldás, vagy fórumok csoportja is alkalmas. De lehet használni vállalati belső blogokat, vagy wiki alapú kollaborációs oldalakat is. Persze ekkor már nem szociális háló alkalmazásnak hívnánk, de az interaktivitás, ill. a részvétel ösztönzése (de legalább lehetővé tétele) fontos abban, hogy összetartson egy ilyen közösséget).

Így most már több szeletét is el tudjuk különíteni az informális kapcsolatok kezelésének:

• Kapcsolati feltérképezések (menedzsment szempontból)
• Tudásfeltérképezés (tudástérkép, megint csak menedzsment szempontból érdekes)
  
• Szociális háló alkalmazás (csak hozzáadott értékkel, hogy működjön)
  
• Tudásmegosztási megoldások (kollaboratív eszközök, fórumok)
  

A vállalati szociális háló megoldásoknak, melyek célja az informális kapcsolatok formalizálása, továbbra is ellene vagyok - illetve csak inkább feleslegesnek tartom, kétségeim vannak, hogy el lehet-e vele érni azokat az eredményeket, melyeket várunk tőle. Ha kiegészítjük új szolgáltatásokkal (szakértő keresés, együttműködési fórum, tudásmegosztás, stb.), akkor hasznosítható, bár az informális kapcsolatok kiteljesedése továbbra is informálisan történik.