2008. augusztus 11., hétfő

Közhasznú információ

Technikai okok miatt ez a blog ezentúl a következő címen folytatódik:

http://tudman.wordpress.com


A korábbi tartalmak az új helyen is teljes mértékben elérhetőek, csak éppen szebb, könnyebben kezelhető, és más anyagokkal dúsított formában.

Tartalom:

2008. április 29., kedd

Nyílt innováció

A nyílt innováció témájára napjainkban már külön szervezetek, mozgalmak alakulnak. A nyílt innováció elvei szerint sokkal jobb eredmények, fejlesztéseket lehet nyújtani azáltal, hogy az innovációs folyamatokat a vállalati határokon túlra is kiterjesztjük, azaz bevonjuk a jelenlegi és jövőbeli felhasználókat is a fejlesztési folyamatokban. Mondhatnánk, hogy a web 2.0 filozófiáját (részvétel) alkalmazzuk az innovációs folyamatos során is.

Ez persze a korábbi kutatás-fejlesztési-innovációs megközelítéseket alapjaiban változtatja meg: míg sok esetben a jövőbeli termékek / szolgáltatások fejlesztése a legkomolyabb üzleti titokként szerepelt, beleértve az elkészült megoldások tartalmát és működését is (ld. pl. a Windows alkalmazások).

A nyílt innováció megközelítésében sokszor belefér az, hogy a fejlesztési folyamat során még félkész megoldásokat nagy felhasználói mintán tesztelik, és lehetőséget biztosítanak a felhasználóknak arra, hogy saját ötleteikkel segítsék az innovációs folyamatot. Ezáltal a szervezetbe olyan ötletek is bekerülhetnek, melyek amúgy fel sem vetődnének, ráadásul a felhasználói oldalról adott visszajelzések igen magas színvonalon segíthetik egy új megoldás sikerét.

Ennek a megközelítésnek a gyökere talán a Linux operációs rendszer, illetve a nyílt forráskódú szoftverek fejlesztéséhez nyúlik vissza (nem feltétlenül csak szabad felhasználású szoftverekről van szó). Ebben a fejlesztési modellben mindenki láthatja a fejlesztendő szoftverkódot, és szabadon változtathat is rajta. Sőt, egy adott keretrendszerhez szabadon hozzáilleszthetőek új programok, megoldások is.

Mostanra ez a fajta szemléletmód széles körben elterjedt, gondoljunk csak olyan zászlóshajókra, mint a Mozilla fejlesztése, vagy a Google webes megoldásai. Ezek a példák is rámutatnak arra, hogy a nyílt innovációs folyamatok gyakran hálózati együttműködésben valósulnak meg, ahol csak gyenge központi koordináció érvényesül. Persze ez a megközelítés nehézkesebbé teszi a célorientált tevékenységeket, de szélesre nyitja az ajtót az ötletek megvalósítása előtt.

Ugyan nem az Európai Unió berkeiből indult, de most már a bizottság támogatását is bírja a Living Lab (élő laboratórium?) hálózatok kialakítása. A living lab filozófiája szerint a fejlesztés középpontjában a felhasználók állnak, illetve a felhasználók kollaboratív intelligenciájának felhasználása (co-creation). Ezáltal a „user=problem” megközelítés felől a „user=solution” irányba kell elmozdulni.

A megközelítés főbb ismérvei a következőképpen foglalhatóak össze:

Olyan környezet létrehozása, ahol az új megoldások valóságos környezetben próbálhatóak ki (azaz nem laborkísérletekről van szó, nem pilot projektekről, hanem élő alkalmazáskipróbálásról). Ebbe beletartozik az is, hogy a felhasználók valós környezetükben, valós időben, és persze nagy számban próbálják ki a megoldásokat.

Az értékelés érdekében megalapozott, szisztematikus megfigyelési és értékelési eljárásokra van szükség. Mivel a felhasználás nem kontrollált környezetben zajlik, ezért mind a megfigyelés, mind pedig az adatgyűjtés során automatikus megoldások használata mellett szerepet kap a felhasználói tapasztalatok kikérdezése is (debriefing).

Egy brüsszeli living lab konferencián – amit a szlovén elnökség szervezett – egy olasz living lab egy 3D fényképezőgépet próbált ki a résztvevőkön. A megoldás nagyon impozáns volt, egyetlen fényképpel készített egy 3D modellt az ember fejéről. Ugyanakkor hiába működött a technológia, a felhasználást tekintve még voltak bizonytalanságok, és a ez a konferencia például jó alkalom volt arra, hogy az európai innovációban résztvevő személyektől ötleteket gyűjtsenek. Valószínűleg nem ez a legjobb példa, de azért érdekes volt látni.

A nyílt innovációs megoldásoktól azt is elvárhatjuk, hogy segítik a fejlesztési ciklusok felgyorsítását azáltal, hogy nagyobb közösség vesz részt a folyamatban, ráadásul önkéntes, és legtöbbször ingyenes formában.

A living lab koncepciójában a nyílt innovációtól az is elvárható, hogy a fejlesztési eredmények ne csak egy szűk közösség hasznát szolgálják. Így a kimenet is legyen nyílt (pl. nyílt forráskódú), illetve maga a fejlesztési is kooperációként valósuljon meg, amiben mind a felhasználók, mind a kutatók, mind pedig az ipari alkalmazók is részt vesznek. Ráadásul minden oldalról többen is, így az eredmények nem csak szűk csoportok érdekét szolgálhatják.

Ilyen megközelítésre van például szükség a határokon átnyúló katasztrófamenedzsment esetében: ipari partnerek, kutatócégek, egyetemek, sőt a kormányzat is érintett, ráadásul több országból is. (Ilyen kezdeményezés indul júniusban az ALADIN szövetség keretein belül).

Az Európai Unió elvárásai szerint a Living Lab megközelítés egy önfenntartó innovációs eszköze lehet az Uniós fejlesztési politikának, de ezzel egyelőre még vannak nehézségek. Ahogy a Brüsszeli konferencián beszélgettek a Living Lab vezetőkkel, résztvevőkkel, az derült ki, hogy a szervezetek, együttműködések fenntartása gondokba ütközik (tudniillik a fenntartóik egyelőre inkább állami szervek, vagy önkormányzatok, és nem annyira civil szféra – tisztelet a kivételeknek). Ráadásul hiába volt a szlovén elnökség igen meggyőző a már említett konferencián, a francia elnökséget képviselő úriember bevallotta, hogy nem igazán tudja, hogy miről is szól az egész, de szívesen ismerkedik a témával. És persze dedikált EU támogatásban senki ne is reménykedjen.

2008. április 15., kedd

Az online szociális hálózatok jövője

Vagy lehetne a cím akár kérdőjellel is: van jövőjük? Az Economist egyik cikke épp erről a kérdésről értekezik, mely jó apropó arra, hogy kicsit boncolgassuk a témát.

Az internetes szolgáltatások fejlődését végigkísérik a nagy felvásárlások: korábban az internetes levelezőprogramok, most pedig a különféle szociális háló megoldások kerültek a középpontba (legalább is mind a Google, mind pedig a Microsoft igyekszik megvetni a lábát ebben a szektorban is). Kérdés, hogy mennyire jelentenek ezek a megoldások üzletet a nagy cégeknek. Van vajon tudatos stratégia a felvásárlások mögött (üzleti modell), vagy pedig csak a remény, hogy hosszú távon ez üzletet is jelenthet.

Láttuk a Microsoft-Facebook összeborulás során, hogy milyen magas piaci értéket tulajdonítanak ezeknek a megoldásoknak a cégek. Kérdés, hogy ez mitől jelent megtérülést? Egy korábbi bejegyzésben írtam a Google üzleti modelljéről, mely a használat – reklámozás összekapcsolásra épít. Első gondolatként ezt várhatjuk az online szociális háló alkalmazásoktól is?

Mint minden internetes oldaltól, web2.0 megoldástól, a szociális háló megoldásoktól is azt várjuk, hogy a felhasználók rabjai lesznek, és kezdő-portálként fogják használni. Az oldalak fejlesztése is ezen filozófia mellett történik, pl. a Facebook és MySpace oldalak funkcionalitása is kibővülni látszik. De mit jelent ez anyagilag? Egyelőre nem nagyon látszik a nagy bevétel: A Google továbbra is a direkt hirdetési megoldásokat preferálja, de sem a MySpace, sem az Orkut esetében nem beszélhetünk jelentős bevételekről. A Microsoft-Facebook esetében pedig a szóbeszéd alapú termékajánlás (Beacon) megbukott a felhasználók ellenállásán és felháborodásán. A Figyelő egyik számában Pálfy Erika cikke kitér arra, hogy az online szociális hálók felhasználói nem is igazán fogékonyak a hirdetésekre, sőt erős ellenérzéseik vannak, és Amerikában a hirdetések erősödése kilépési hullámot is elindított.

De gondoljunk csak bele: igazából a hagyományos e-mail alkalmazásaink is jó alapot biztosítanak az szociális háló alkalmazáshoz (és ezt többen igyekeznek is összemosni), hiszen akikkel levelezünk, azok ilyen-olyan ismerőseink. Így a levelezésen keresztül automatizálható lenne az ismerősök rögzítése is (akik profilját az e-mail címen keresztül el is érhetnénk). Így pl. a gmail automatikusan rögzíti azokat, akiknek levelet írtunk. Ráadásul így láthatnánk a kommunikáció erősségét, intenzitását is. Ha bizonyos alkalmazásokban bombáznak minket reklámmal, nem fordulunk-e vissza olyan alkalmazások felé, melyek még (már) nem olyan fertőzöttek?

Úgy tűnik amúgy, hogy a jövő a különböző alkalmazások összekapcsolásában van (e-mail, szociális háló, kép, videó, blog, stb.), de én még mindig kicsit szkeptikus vagyok, hogy itt a nagy fejlesztésekben miből lesz az üzlet. Vajon lufiról van szó, ami egyszer csak kipukkad?

Problémák

Problémát jelent ugyanakkor hogy több szociális háló megoldás is van a weben, mindegyik a vonatkozó előnyökkel és hátrányokkal. Kérdés, hogy kialakulnak-e a klikkek (ki melyikben van), vagy mindenki igyekszik a nagyobb megoldásokon megjelenni, vagy…? Egy kicsit zavaró tud lenni, ha a felhasználók figyelme már több oldal között oszlik meg. Ez üzleti oldalról is problémát jelent, hiszen a felhasználók hűsége, oldalhoz kötődése gyengül. Sajnos az átjárhatóság (különböző alkalmazások összekötése) még nem valósult meg, pedig felhasználói (és talán üzleti oldalról is) nagy könnyebbséget jelentene. Ráadásul a kommunikáció és sokszor a szociális hálón kívül zajlik: levelezés, képfeltöltés és nézegetés, hírolvasás – ezek miatt már nem jelentkeznek be a felhasználók, csak követik a linkeket. Talán épp az intenzívebb marketingnek köszönhető, hogy a felhasználók egyre kevesebb időt töltenek az online közösségi oldalakon... vagy talán kifulladóban van az egész?

Sok kritika érte így a szociális háló alkalmazások biztonságát. Most volt egy hír a webisztánon, hogy bizonyos nyomozási ügyekben már felhasználják a szociális háló alkalmazásokat: pl. ismerettségek felderítésére, szokások vizsgálatára, anyagi helyzet vizsgálatára (ld. Apeh). Rettegünk a nagy-testvér szindrómától, de közben mi magunk helyezünk el tartalmat magunkról a weben: kapcsolatok, fényképek, élménybeszámolók. Személyes adataink nyitottak. És amikor ezeket elkezdik kihasználni, akkor félő, hogy a felhasználás is visszaesik (vagy már el is kezdődött?).

2008. április 9., szerda

Kockázati önértékelés és forgatókönyv-elemzés

A kockázati önértékelés és a forgatókönyv-elemzés nem tökéletes szinonimái egymásnak, mégis sokszor – nem meglepően - azonos értelemben, hasonló értelmezésben használják ezeket. A terület összefoglalásáról igen jó cikk olvasható a Hitelintézeti Szemlében.

A kockázati önértékelés (self risk assessment - SRA) során az intézmény vezetői, dolgozói feltárják a lehetséges kockázati tényezőket, és megbecsülik ezek várható veszteségét. A forgatókönyv-elemzés lehet ennek egy speciális formája, mely során elsősorban a súlyos események hatásait igyekeznek meghatározni. A forgatókönyv-elemzések során ezek az események meghatározása mellett vizsgálják ezek okát (így megelőzhetőek), illetve lehetséges kimeneteleit (így kezelési lehetőségeket állapítanak meg. A forgatókönyvek elemzése segít feltárni a sebezhető területeket, és megbecsülni a kockázatok várható, illetve maximális értékét. Megjegyzendő, hogy a forgatókönyv-elemzés is egyfajta önértékelésnek tekinthető.

A forgatókönyv elemzés során elterjedt elemzési segítség a Fault Tree Analysis, mely során az egyes tevékenységek, szolgáltatások hátterét tárhatjuk fel: mivel a bevételek elsősorban bizonyos szolgáltatások végrehajtásából származnak, ezért ez a módszer segít az ezeket akadályozó kockázatok, veszélyeztetett elemek azonosításában.

Ezekben az esetekben arra kell törekednünk, hogy mind a kockázatokat, mind a várható (és nem várható) veszteségeket azok állapítsák meg, akik leginkább érintettek. Ebből adódóan a kockázatok azonosítás, illetve azok értékelése nem feltétlenül kerül egyszerre megállapításra (bár lehet workshop-okat szervezni az együttes értelmezés érdekében. Például egy informatikai kockázatot valószínűleg a legjobban az informatikusok tudnak azonosítani, de a kapcsolódó veszteséget már az érintett üzletág(ak) jobban fogja becsülni.

A kockázatok azonosításának egyik lehetősége a szervezet folyamatainak feltérképezése, és az egyes tevékenységekhez kapcsolódó kockázatok azonosítása. Ez a megközelítés lehetővé teszi, hogy a közvetlenül kapcsolódó kockázatok könnyed azonosíthatóak legyenek, a folyamatokat mintegy sorvezetőként használva. Természetesen léteznek olyan működési kockázatok, melyek nem csak egy tevékenységhez, vagy folyamathoz köthetőek.

A további kockázatok azonosításához az vizsgált területek szakértőivel és vezetőivel folytatott strukturált megbeszélések szükségesek.

Az önértékelés, forgatókönyv-elemzés – bármilyen pontos is legyen – becslés eredménye. Éppen ezért szükséges a körültekintő alkalmazás, illetve az eredmények megbízhatóságának érdekében a független kockázatkezelő szakértők mellett akár a belső ellenőrzés bevonása is indokolt lehet.

Az ellenőrzés történhet a meglévő tényadatokkal való összevetés segítségével is, de ezen adatok esetében eleve probléma a teljesség hiánya, illetve az, hogy nem veszik figyelembe az esetleges szervezeti, vagy környezeti változásokat.

A becslések folyamán problémát jelenthet, ha a szakértők nem képesek becsülni: ismerik a kockázatokat, de nem tudják meghatározni azok várható veszteségét. Ilyenkor elfogadott külső adatokra, benchmarkok-ra támaszkodni, persze a szokásos fenntartásokkal.

A kockázati önértékelés és forgatókönyv-elemzés elsősorban abban segít, hogy segít feltárni a szervezetben a kockázatok okait is, a veszteségeloszlások mellett. Sok esetben a veszteségeloszlás alapú megközelítések nem is igazán vezetnek eredményre, mivel sokszor nem áll elégséges múltbeli adat rendelkezésre.

A folyamat alapú kockázatfelmérés arra is lehetőséget ad, hogy a vizsgált kockázatokhoz kapcsolódóan a folyamatokba kontrollpontokat, vagy ellenintézkedéseket illesszünk be.

2008. április 2., szerda

Működési kockázatok egyedi jellemzői

A működési kockázatok nem válaszhatóak el a bank működésétől, megvalósított stratégiájától, illetve más kockázataitól. A működési kockázatok minden folyamatban, tevékenységben jelen vannak, és ezen folyamatok változtatásával változik a kapcsolódó működési kockázat is. A McKinsey tapasztalatai szerint a működési kockázatok kezelésével jobb eredmény érhető el, mint a folyamatok költséghatékonysági átszervezésével.

A működési kockázatokból származó veszteség a bankok esetében átlagosan 4-5%-a a szervezet nettó árbevételének. És ez a statisztika csak a nyilvánosságra hozott adatokon alapul, mely így alacsonyabb (akár jóval alacsonyabb), mint a valóságos értékek. Arról nem is beszélve, hogy ezek a kockázati események az azonnali veszteségen túl megjelennek a részvényárfolyamban is: a működési kockázatok felmerülése kihatással van egy vállalat reputációjára, jóhírére, és így közvetett módon is okozhat veszteséget.

A McKinsey tanulmánya rámutat, hogy a bankok gyakorlatában elsősorban a működési kockázatok értékelésére (és tőkefedezet képzésére) koncentrálnak, míg a kockázatkezelés, és így a kockázati érték csökkentése kevesebb figyelmet kap. Így a kockázati területek azonosítása, azok szisztematikus feltárása és a kockázati okok megszüntetése csak kevés helyen jelent működő gyakorlatot.

Ráadásul a kockázatok azonosítása és kezelése során elsősorban a jól megfogható (hard) tényezőkre koncentrálnak, míg a puhább (soft) tényezőkkel nem foglalkoznak. Való igaz, hogy egy szervezeti kultúrával, egy dolgozói motivációval sokkal nehezebb megküzdeni, sőt hosszabb időbe is telik, mint mondjuk egy szervernek a backup hátterét létrehozni. Ugyanakkor a puha tényezők azonosításával és fejlesztésével nem csak hosszabb távú (tartósabb), de nagyobb mértékű eredmény is érhető el.

Míg a piaci, vagy hitelezési kockázatok viszonylag jól becsülhetőek múltbéli adatokból (akár saját adatbázisból is), addig a működési kockázatok felmerülése sokkal bizonytalanabb, kiszámíthatatlanabb, és a múltbéli események relevanciája sokkal gyengébb.

Tovább nehezíti a helyzetet, hogy a működési kockázatok minden tevékenység (mind az alap, mind a támogató folyamatok) részét képezik, és az intézményeknek minden területtel foglalkoznia kell (persze a priorizálás minden esetben segít).

„Képzeljünk egy bankot, mely dinamikusan növekszik, és évente 300 új termékkel/szolgáltatással jelentkezik. Ez azzal járt együtt, hogy az üzletkötőknek hiányos ismeretei voltak a termékekről, mégis az ő felelősségük volt a szerződési feltételek elbírálása, illetve az ügyfeleknek a tájékoztatás megadása. Ez persze növelte a kockázatokat a szolgáltatások, illetve az ügyfélelégedettség / ügyfélpanaszok tekintetében.”

Ebben az esetben a vezetők nem ismerték fel időben a tudás és tapasztalatok hiányának kockázatát. Ha felismerték volna ezt a kockázatot, akkor szervezhettek volna oktatást, készíthettek volna támogató informatikai rendszereket (melyek megmutatják a feltételek, vagy segítik a szerződéskötést), vagy akár lehetett volna a termékportfóliót is jobban fókuszálni, vagy az üzletkötőket csoportokra bontani. Összességében a kockázat kezelésére, és erős csökkentésére számtalan lehetőség rendelkezésre állna, ha a kockázat ismert lenne.

A működési kockázatok egyik előidézői maguk a dolgozók. Például egy túlhajtott szervezeti működés esetén a dolgozók figyelmetlenebbé válnak, könnyebben vállalják a kockázatokat. De lehet kockázati ok egy olyan szervezeti kultúra is, ahol az előírások, szabályok tisztelete nem érték.

2008. április 1., kedd

Folyamat alapú kockázatelemzés, avagy: jobb félni, mint megijedni.

A kockázatokat folyamatok mentén érdemes vizsgálni, ennek a megközelítésnek bizonyos elemeit igyekszem most bemutatni, a kapcsolódási pontokkal. Persze egy ilyen bejegyzés biztos, hogy nem lesz teljes, de idővel folytatom.

A kockázatok kezelésének feltétele, hogy a kockázatok azonosíthatóak legyenek. A kockázatok elemzésének egyik lehetősége a szervezet folyamatainak felmérése. Mivel a szervezeti folyamatok több szervezeti részleg bevonásával kerülnek végrehajtásra, ezért a kockázatok gyakran kevésbé láthatóak. A szervezeti egységek közötti funkcionális függőségi viszonyok lehetnek, de a folyamatok feltárásával azonosíthatóvá vállnak mind az érintett szervezeti egységek, mind az emberek, mind pedig a felhasználandó technológiai megoldások. A folyamatok (és tevékenységek) azonosítása lehetővé teszi a forgatókönyvelemzést, azaz annak vizsgálatát, hogy mi romolhat el, hol mehet valami félre (emlékezzünk Murphy aranyszabályára: ami elromolhat, az el is romlik)?

A forgatókönyvelemzés folyamán támaszkodhatunk múltbéli adatokra, illetve a tevékenységek alapján feltárhatunk új kockázatokat is.

Az adatok hiánya nem jelenti feltétlenül a kockázatok hiányát.

A kockázatok felmérése így két nagyobb megközelítés együttes alkalmazását követelheti meg:
  • A top-down megközelítés elsősorban a kockázatok múltbéli (külső és belső) adatokon alapuló értékelése szerint halad, mely feltételezi, hogy csak a múltbéli jelenségek ismétlődnek.
  • A bottom-up megközelítés felméri a lehetséges kockázatokat (folyamatalapú, és forgatókönyv alapú megközelítések), de ezek azonosítás sokszor szubjektívnek tekinthető, és szakértői becslések által meghatározott. Ugyanakkor ez a módszer nagyobb teret ad a kockázatok kezelésének azáltal, hogy a kockázati okok pontosabban azonosíthatóak.
Sok esetben a folyamatalapú elemzés során feltárt kockázatokra nincsen múltbéli adatunk, ezért gondolhatnánk azt is, hogy a feltárt kockázat szervezetünk esetében nem releváns. Tipikusan a ritkán jelentkező, de nagy hatású kockázatok esetében hajlamosak a szervezetek arra, hogy ne foglalkozzanak a lehetséges kockázatokkal (itt hadd idézzem egy informatikai vezető mondását: „minden rendszerünk folyamatosan jól, és megbízhatóan működik, nincs szükségünk megelőző intézkedésekre a működés fenntartása érdekében”). Ez a hozzáállás akár jelentős veszteségeket is okozhat, ha egy adott szervezet nem elemezte kellőképpen a lehetséges kockázatokat, illetve azok hatását. Ez sokszor elpocsékolt pénznek tűnik (beleöltük az időt és energiát, és mégsem jelentkezett a kockázat), de hogy néhány közhelyszerű dolgot megemlítsek: jobb félni, mint megijedni, illetve ha az ember esernyőt visz magával nem esik az eső.
Eszembe jut a y2k problémakör (2000. év problémája) kapcsán a vállalatok viselkedése. Az 1998-99 évek folyamán több informatikai tanácsadó cég is igen jól megélt abból, hogy a különböző vállalatokat felkészítették a 2000. év eljövetelére, amikor bizonyos régebbi rendszerek várhatóan leálltak volna. Eljött a 2000. év, és igazából nem történt semmi (bát láttam egy B kategóriás katasztrófafilmet a témában, ahol majdnem robbant egy atomerőmű). Nagyon sok vállalatvezető felháborodott, hogy az egész csak a tanácsadói ipar nagy hülyítése volt, hogy mindenki ész nélkül költse a pénzét. A tanácsadók pedig széttárták a kezüket, és büszkén hirdették: „Jó munkát végeztünk”. Ez persze egy olyan kockázati kategória volt, melyre nem állt rendelkezésre benchmark, ugyanakkor ismerni lehetett a kockázat létezését. Így utólag tehát nehéz igazságot tenni, hogy csak a tanácsadói szektor jó marketingmunkájáról, vagy valós kockázatelhárításról volt szó. Hogy megvédjem a tanácsadókat meg kell említeni, hogy különösen a pénzügyi alkalmazások esetében sok nem 2000. év kompatibilis megoldás is volt, melyeket ki kellett szűrni. De hogy hozzak ellenpéldát a másik oldalról is: egy telekommunikációs cég esetében a tanácsadók még a fénymásolókat is felmérték, hogy 2000. év kompatibilisek-e, bár ezen eszközök nem voltak éppen üzletmenet kritikusak (bár az elvárások között szerepelt a teljességi vizsgálat szükségessége).
A folyamat alapú megközelítés lehetővé teszi, hogy ne csak múltbéli kockázatokra keressünk adatokat, hanem olyan kockázatokat is számba vegyünk, melyek még nem fordultak elő szervezetünk esetében. Az ilyen kockázatok felmérésére és kezelésére elsősorban a külső adatbázisokból származó adatokat (benchmark) szokták felhasználni. Külső adatok felhasználását az intézményeknek indokolnia kell, illetve a felhasználáshoz kapcsolódó megfontolásokat évente független szakértőnek kell értékelnie. A felhasználás és megbízhatóság kérdése azért is érdekes lehet, mivel több adatbázis is rendelkezésre áll a különböző kockázatokból adódó veszteségek gyűjtésére, és azok tartalma sokszor eltérést mutat. Így érdemes szűrni az adatokat azok relevanciája alapján, illetve vizsgálni azt, hogy a kockázati kategóriák, vagy üzletágak alatt ugyanazt értjük-e, mint az adatbázis üzemeltetői. Célszerű olyan külső adatokat használni, melyek követik a CRD (Capital Requirements Directive) 7x8-as mátrixot eredményező veszteség és üzletágstruktúráját.

Az eloszlásokra alapuló modellek hasznos kiegészítői a folyamat alapú megközelítésnek, illetve az eloszlásokra alapuló megközelítéseket a feltárt kockázati lehetőséggel lehet kiegészíteni. Így a két megközelítés együttes használata lehet a legjobb (bár egyben a legkomplexebb) megoldás. Ezt a megközelítést a szakirodalom Hybrid Measurement Approach-nak (HMA) nevezi, és természetesen csak a fejlett mérési módszert alkalmazó bankok használhatják.

Előrejelzések

A folyamatalapú megközelítés hozzájárul a kockázatokra vonatkozó indikátorrendszer meghatározásához is. A folyamatokhoz, illetve az ott megjelenő kockázatokhoz kulcs kockázati indikátorokat (Key Risk Indicators – KRI) rendelhetünk, melyek változásával, illetve figyelembevételével becsülhetjük a kockázatokat. Pl: ATM rablások, munkaerő fluktuáció aránya, ügyfélpanaszok száma, szolgáltatások rendelkezésre állása

Ezen indikátorok mintegy füstérzékelőként működnek: jelzik a füstöt, de nem tudjuk, hogy ég az épület, vagy pedig csak odaégett a kenyér a pirítóban? Ennek kiderítése mindig külön vizsgálatot igényel, de „jobb félni, mint megijedni”. Mindenesetre akkor van csak lehetőségünk a kockázatok felmérésére és kezelésére, ha tisztában vagyunk az üzleti folyamatokkal és azok összefüggésrendszerével.

Ebből következően egy adott indikátor többféle kockázatot is előre jelezhet, illetve az indikátorokat nem egyesével, hanem azok együttesének elemzésével szükséges értelmezni.

Megjegyzendő, hogy a kulcs kockázati indikátorok előrejelző képessége (mely véges) nem biztos, hogy minden kockázatot megfelelően lefed. Ne ringassuk magunkat abba a hitbe, hogy az indikátorok kialakításával kezeltük is a kockázatokat: egyrészről a teljesség sok esetben kérdéses, másrészről a működés, és ezzel együtt a kockázatok is változhatnak. Ugyanakkor a kulcs kockázati indikátorok használata nagy mértékben javíthatja a szervezetek kockázatkezelési lehetőségeit.

2008. március 22., szombat

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

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.


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

2008. március 18., kedd

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.

2008. március 17., hétfő

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.

2008. március 13., csütörtök

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?

2008. március 12., szerda

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

2008. március 11., kedd

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

2008. március 10., hétfő

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

2008. március 9., vasárnap

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

2008. március 5., szerda

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

2008. február 28., csütörtök

A működési kockázatok kezelésének kétféle megközelítése

Tegnap egy megbeszélésen került előtérbe, hogy milyen megközelítési módjai is vannak a működési kockázatok azonosításának és értékelésének. A működési kockázatok modellezésének célja, hogy a kockázatok megfelelőképpen mérje, illetve hogy a kockázatokra elegendő tőkét határozzon meg.

Top-down megközelítés

A megközelítés keretében a kockázatszámítás alapja a múltbéli veszteségadatok számbavétele, azok aggregálása. Ennek keretében modellezzük az időegységre jutó veszteség értékét, illetve a veszteségeloszlást. Ezt a megközelítést LDA (Loss Distribution Approach) néven ismerik.

Az összegyűjtött és elemzett veszteségadatokat statisztikai módszerekkel lehet vizsgálni (eloszlások azonosítása, paraméterek becslése, illeszkedésvizsgálat).

A megközelítés lehetővé teszi, hogy múltbéli kockázati eseményeket azonosítsunk, és ezek jövőbeli előfordulására felkészüljünk. Problémát az jelent, hogy míg a gyakori, de kis hatású kockázatok felmerülése viszonylag jól becsülhető, addig a ritka, de nagy hatású kockázatok igen rosszul becsülhetőek. Az ilyen események becslésekor már érdemes szimulációkat is futtatni, az általunk kialakított modelleken.

A modellépítés ugyanakkor már átvezet a másik megközelítés alkalmazási területére.

Bottom-up megközelítés

A megközelítés alapja, hogy felmérjük az összes lehetséges kockázatot. A Top-Down megközelítéshez képest az előnye abban áll, hogy a felméréssel nem csak a kockázatok értéket tudhatjuk meg, hanem pontosan (az előző módszerhez képest jóval pontosabban) meghatározhatjuk a kockázatok helyét, azok lehetséges okait, illetve feltárhatjuk azokat a kockázatokat is, melyekkel a szervezetnek még nem kellett szembesülnie.

A kockázati értékelés egyik fontos eleme a forgatókönyv- (szcenárió-) elemzés. Ekkor meghatározzuk a lehetséges kockázatokat, azok összefüggéseit, majd felállítjuk a lehetséges forgatókönyveket: legtöbbször optimista, normál és pesszimista megközelítéseket. A háromféle lehetőség vizsgálatára azért van szükség, mivel a kockázatok értékelése eleve becslésen alapul, és maga is bizonytalanságot (kockázatot hordoz). Így a különböző forgatókönyvek hivatottak az ebbéli bizonytalanságot tükrözni.

Ez véleményem szerint egyfajta bottom-up megközelítésnek számít, és a Basel-II iránymutatók alapján külön kategóriaként kezelt SBA (Scenario Based Approach) megközelítés, melyet legtöbbször leszűkítik a stresszesemények (kockázatok) értékelésére, illetve ezekre épített modellre. Ez a top-down megközelítéssel jelentős átfedést mutat. Véleményem szerint a folyamatmodellezésre épülő statisztikai megközelítés jelentené ugyanakkor az LDA és SBA megközelítés hiányzó kiegészítését.
"While LDA models tend to be built on actual loss data and SBA approaches usually rely on constructed (i.e. scenario generated) data, in practice the two methods usually overlap. Hybrid approaches are commonly found, with actual loss data often enriched by constructed data and vice versa."
(forrás: CEBS)
Természetesen mindkét modellnek megvannak a maga előnyei és hiányosságai, ezért logikusnak tűnne, hogy a két megközelítés kombinációját kelljen megvalósítani. Ugyanakkor pont itt érhető el a különbség: míg a top-down megközelítés viszonylag jól számolható, és becsülhető (bár nem deríti fel az okokat), addig egy pontosabb és körültekintőbb bottom-up megközelítés jelentősebb energiabefektetést és munkát igényelne.

Amennyiben a folyamat alapú kockázatfelméréshez már konkrét modelleket, becsléseket (SBA) tudunk megfogalmazni, úgy kockázatfelmérésünk pontosabb lehet. Hátránya ennek idő és energiaigénye, ráadásul nagyobb energiát inkább csak a nagyobb kockázatokra érdemes fordítani (és érdemes itt is szem előtt tartani a 20/80 szabályt).

2008. február 27., szerda

Működési kockázatok értelmezése

Első kérdésként azonnal felmerülhet, hogy mit is értünk működési kockázat alatt, illetve milyen más jellegű kockázatokkal kell még foglalkoznunk?

Kockázat minden tevékenységünkhöz kapcsolódhat, sőt kapcsolódik is. A kockázatot általában negatív értelmezési keretben használjuk, azaz valamilyen jövőbeli veszély, veszteség bekövetkezésére használjuk. Általánosabb értelemben a kockázat nem más, mint a jövő kiszámíthatatlansága, bizonytalansága (és ebben az értelmezésben pozitív kockázatról, azaz a nyereség lehetőségéről is beszélhetünk).

A működési kockázatok értelmezése elsősorban a pénzügyi szektorokban élvez kiemelt figyelmet a Basel II szempontrendszer alkalmazása miatt. A Bázeli Bizottság értelmezésében a „működési kockázatok az emberek, belső folyamatok, a rendszerek nem megfelelő, vagy hibás működése, illetve külső tényező által előidézett veszteségek kockázata”.

A lehatárolás miatt el kell választanunk a banki hitelezési gyakorlathoz (hitelezési kockázat), illetve a piac megváltozásához (piaci kockázat) kapcsolódó, a Bázeli Bizottság által is kiemelt kockázatokat. Persze emellett minden más terület kockázatát is megemlíthetnénk.

A pénzintézetek működési kockázataihoz kapcsolódóan hét veszteségi kategóriát lehet megemlíteni, melyekért együtt, vagy külön-külön felelőssé tehető a négy kockázati terület:

1. Belső csalás (emberek, rendszerek): A belső előírások megsértése, ahol legalább az egyik érintett fél a szervezet dolgozója. Beletartozik az eljárási szabályoktól való eltérés, jogkör bitorlás, belső lopás vagy csalás. Ilyenek lehetnek a felhatalmazás nélküli döntések vagy a bennfentes kereskedelem.
Belső csalásra talán a legaktuálisabb példa a Société Générale-nál elkövetett csalás.
2. Külső csalás (külső tényezők, rendszerek, folyamatok): Jogszabályok és törvények kijátszásával, külső fél által okozott veszteség. Beletartozik a számítógépes rendszerek kijátszása, a szervezeti folyamatok kijátszása, illetve a szervezet becsapása (pl. okirat hamisítás). Pl. Lopás, rablás, számítógépfeltörés, illetéktelen hozzáférés megszerzése, bankkártya csalások. "Külső tényezők
Ehhez a területhez kapcsolódik a közelmúlt egy híre, amikor egy volt ügyvéd hamis bírósági ítéletekkel nyújtott be inkasszót gazdasági társaságok számláival szemben, és cégenként 8-9 millió forintot próbált megszerezni. Mivel korábban már voltak ilyen esetek, ezért a pénzintézetek nem fizették ki automatikusan a kívánt összeget, hanem ellenőrizték az ítéletek valóságtartalmát, és így az elkövető lebukott.
3. Dolgozói tevékenység és munkahelyi biztonság (Folyamatok, emberek): A munkakörülmények, illetve a foglalkoztatás szabályainak megsértése, munkahelyi balesetek, sérülések, nemi, faji vagy bármilyen jellegű diszkrimináció, az egyenlő bánásmód problémái, szexuális zaklatás. Pl. Munkahelyi sérelemért kompenzáció fizetése, büntetés az előírások megsértéséért.
A közelmúltban Nagy Britanniában a City bankot perelte be egy volt dolgozója, akit érvelése szerint a szülési szabadsága után kilépésre kényszerítettek. Az nemi diszkrimációs ügy tétje 1-2 millió font közötti kártérítési összeg. Az eset szerint Ms. Tofeji 2004 végén jelentette be, hogy szülni fog, és innentől kezdve a vezetőség nem bánt vele már megfelelően, sőt ennek tulajdonítja a 2004. évi jutalmának elmaradását is. A gyermek születése után (akit egyedül nevel) kénytelen volt meghosszabbítani szülési szabadságát, míg végül a hét négy napjára talált gondozási lehetőséget gyermekének. Ekkor szerette volna, hogy banki munkaidejét 4 napot tölthetné el. A bank férfi vezetői ezt nem támogatták, az ötnapos munkahét mellett érveltek, de nem hivatalosan kilépésre biztatták. (Financial Times and Guardian, April 17, 2007)
4. Ügyfelek, termékek és üzleti tevékenység (folyamatok): Az ügyfelek felé vállalt kötelezettségek nem szándékos (gondatlan) megszegése. Sokszor fogyasztóvédelmi vonatkozásai is vannak. Pl. Hitelkártya limit túllépés véletlen engedélyezése, vállalt határidőből való kicsúszás, ügyfélnyilvántartás hiányosságai.

5. Fizikai eszközök sérülései (rendszerek): Eszközök, elsősorban az informatika infrastruktúra sérülése és működésképtelensége. Természeti, vagy ember okozta katasztrófahelyzetek. Pl. szerverterem beázása áradás miatt, terrorcselekmény hatásai, építési tevékenység miatti sérülés.
Sajnos napjainkban mind a természeti katasztrófák, mind a terrorista támadások élő veszélyt jelentenek, és nagyon sok cég fel is készül ilyen helyzetekre. A 2001-es World Trade Center elleni támadás az emberáldozatok mellett az informatikai infrastruktúrát, sőt cégek adatait is megsemmisítette. Sok esetben ugyanakkor a biztonsági mentéseknek köszönhetően a működés néhány nap (vagy például a Deutsche Bank esetében 2 óra) elteltével már zavartalanul folyt.

Miami-ban inkább a hurrikánok jelentenek veszélyt. A Banco Santander Central Hispano egy a világ tíz legnagyobb bankja közül. Miami központja nem csak turistalátványosság, hanem egyben a hurrikánok által veszélyeztetett területek egyik kiemelt helye. 2004-ben például a sorozatos hurrikánok 4-szer is leállásra kényszerítették a Miami-ban található adatközpontjukat. Ugyanakkor a veszélyhelyzetre felkészülve háttér szolgáltató központot építettek ki New-York-ban, így a hurrikánveszély ellenére is tudtak foglalkozni ügyfeleikkel.
6. Rendszerek és üzleti tevékenységek megszakadása (Rendszerek): Rendszer meghibásodásból származó üzletmenet megszakadás, alapvetően az informatikai rendszerek hibája: hardver, szoftver, telekommunikáció. Pl. Számlavezető szerverek meghibásodása, ATM vezérlő adatbázis leállása.
Sajnos a hírekben is gyakran hallható, ha egy bank ATM rendszere nem működik, melyet általában valamilyen központi szerver, alkalmazás vagy adatbázis hiba okoz. Nemrégiben a Barclays Bank volt kénytelen szembesülni ilyen problémával, mely fél Nagy Britanniát megbénította. A hírek szerint a problémát egy adatbázis szoftver frissítése okozta, bár a bank az esetet áramszünetre fogta. Az mindenesetre tény, hogy nem gondoskodtak megfelelően a kieső informatikai szolgáltatás kiváltásáról.
7. Folyamatok irányítása, biztosítása és végrehajtása (Folyamatok, rendszerek, emberek): Nyilvántartási tévedések, végrehajtási problémák. Pl. Hibás adatbevitel, könyvelés, külső adatszolgáltatás elmaradása, beszállítói kapcsolatok.

Természetesen egyes esetekben ezen veszteségi kategóriák áttételesen is jelentkezhetnek, több kockázati terület együttes fellépésével. Így akár a külső és a belső tényezők egyszerre jelentkezése nagyobb hatású veszteséget is előidézhet.
A Barings Bank esetében a Nick Leeson által végrehajtott belső csalás, illetve a külső piaci mozgások együttesen eredményezték a veszteséget, de a közelmúlt Société Générale ügyében is a csalás felderítésekor meghozott lépések nem voltak éppen a legjobban időzítve, így növelték a veszteséget.

After Action Review az amerikai hadseregben

Kezembe került egy cikk az amerikai hadsereg tudásmenedzsment gyakorlatáról. Az amerikai hadsereg már régóta úttörője a tudásmenedzsment megoldásoknak, már csak azért is, mert itt nem (csak) pénzről, hanem főként emberéletekről van szó.

Még 2000 környékén Nancy Dixon így foglalta össze az azóta már sok vállalat esetében példaként tekintett After Action Review lényegét:
1994-ben, amikor az amerikai hadsereg megérkezett Haiti-re, egyik feladatuk az volt, hogy begyűjtsék a lázadó városokból a fegyvereket és lőszereket. A bevezetések után kiértékeléseket tartottak, melyeket After Action Review-nak (AAR) nevezünk. Az ilyen kiértékelések célja a tapasztalatok összegyűjtése, és a végrehajtási képesség javítása.

Egy ilyen kiértékelés során egy szakasz katonái megállapították, hogy jelentős ellenállással kell számolni. Egy katona megjegyezte, hogy csak kevés kutyával találkozott a városban, míg egy másik hozzátette, hogy a lakosság nagyon fél a német juhászkutyáktól, melyeket a katonai rendőrség használ. Egy harmadik katona azt javasolta, hogy a következő városban talán magukkal kellene vinni néhányat a katonai rendőrség kutyaállományából, hátha csökkenthetik ezzel az ellenállást.


A következő – már sokkal sikeresebb – bevetés után a szakasz újabb kiértékelésre gyűlt össze. Ezen megállapították, hogy a helyiek sokkal inkább együttműködtek a katonákkal, amikor otthonaikban voltak, mint amikor az utcán találkoztak velük. A rákövetkező kiértékelésen kiderült, hogy a haiti lakosság nagyon tiszteli a nőket. A szakasz úgy döntött, hogy női egységvezetőket kell kinevezni, és a lakosság előtt különös tisztelettel viselkednek a női vezetőkkel.


Az új ötletek beépítésével minden egyes bevetés során a szakasz egyre hatékonyabban volt képes ellátni feladatát.

Dixon ezt az átadási formát „folyamatos átadásnak” nevezte, mivel itt általában ugyanaz a csoport a tudás felhasználója, mint aki a létrehozója. Valójában ez nem is átadás, hiszen a tudást nem kerül ki a csoportból, csupán újra felhasználják. Ennek a feladatnak az eléréséhez szükséges, hogy a csoport tagjai, és maga a csoport felismerje és rögzítse azt a tudást, mely elősegítheti a későbbi munkát. Ennek egy módszere lehet a feladat végzése közbeni, és a lezárást követő megbeszélések, ahol a csoporttagok igyekeznek a tapasztalatok alapján a tudás szintetizálni. A teljes hatékonyság eléréséhez szükséges, hogy a csoport tagjai tényleges csoportot alkossanak, és ne mindenki egyedileg értse meg a problémák és megoldásaikat, hanem azokat együttműködés folyamán is alkalmazni tudják.

A folyamatos átadást elősegítő megbeszélések elsősorban a csoporttagoknak szólnak, így azokat célszerűen egy csoporttag szervezi (akár rotációs rendszerrel). Ez a megoldása elősegíti azt, hogy a megbeszélések akkor legyenek, amikor igazán szükség van rájuk, és ténylegesen azok vegyenek rajta részt, akik érintettek a témában. Ennek megfelelően a megbeszélésekről írásos feljegyzés nem készül, vagy ha mégis, akkor az is csak helyi felhasználásra.

Ez a momentum pont az egyik nagy különbség az AAR módszerek, és más kiértékelési megközelítések (debriefing, project audit/review, sing-off report, stb.) között. Ebben az esetben nem a felelősség keresése, teljesítmény értékelése a cél, hanem hasznosítható tudás kinyerése. Éppen ezért nem is szabad keverni más ilyen módszerekkel, mert csak zavart okoz, és így végső soron hátrányt jelenthet a tudásmegosztás szempontjából.

A különbséget a tudásmenedzsmentben úttörő szerepet játszó Buckman Labs is felismerte:
Robert Buckman visszavonulása után a cég vezetését Steve Buckman vehette át, illetve 2000-ben Katherine Buckman lett az igazgatótanács elnöke. A vezetőváltással együtt új vezetési szemlélet kezdett meghonosodni, mely elsősorban a munkafolyamatok egységesítésére és fejlesztésére fókuszált. A cél az volt, hogy az eladási folyamatok minél egyszerűbbek, ugyanakkor egyre hatékonyabbak legyenek.

A folyamatok fejlesztésére a Buckman Laboratories meghonosította az „After Action Review”-k rendszerét, melynek működését az Amerikai Hadsereg, a BP és a Sprint szervezeteknél tanulmányozták. A megoldás lényege, hogy minden egyes végrehajtott feladat után értékelik az elvégzett feladatot, számba veszik a sikeres és sikertelen tevékenységeket, és igyekeznek a tapasztalatokat összegezni. Az ilyen áttekintések során nem cél az egyéni teljesítmény értékelése, sokkal inkább a szervezeti tanulás megvalósítása.
Természetesen az átadási keretek tágításával a hatékonyság növelhető. Mivel egy ilyen bevetés utáni kiértékelésen azért hangozhat el sok vélemény, mert ezeket a véleményeket nem továbbítják hivatalos jelentésben, ezért nehéz megtalálni azt az egyensúlyi helyzetet, amikor a tudást sikerül is kinyerni, és továbbítani is. Így tehát ezekről a megbeszélésekről a fejlődés érdekében szükséges valamilyen feljegyzést készíteni.
2007 januárjában az amerikai hadsereg egyik elemzője, aki a Center for Army Lessons Learned (CALL ~Katonai tapasztalatok központja) keretében tevékenykedett, felfigyelt arra, hogy a Fort Drum laktanyában a katonák kampókat hegesztenek a gépjárművek ajtóira, mely nagy segítséget jelent akkor, amikor egy robbanásban megsérült gépjárműből kell a katonákat kiszabadítani. Az elemző rájött arra, hogy ez a tapasztalat szélesebb körben is hasznos lehet (főleg Irakban és Afganisztánban, ahol az ilyen támadások mindennaposak). Hogy ez a tudás átadható legyen a katonák segítéségét kérte: együttesen dokumentálták az előállítási és felszerelési folyamatot, melyet fényképekkel is illusztráltak. Az így előálló használati utasítást elérhetővé tették a hadsereg belső információs rendszerében, és már 48 órán belül használták is ezt a megoldást más hadseregcsoportok.
A CALL hálózatot 2006-ban hozták létre, pont a tudásátadás hatékonyságának növelése céljából. Ez első évben már 15 000, a fentihez hasonló ötletet sikerült megosztani, melyek közül 4 000 beépült a mindennapok gyakorlatába. Amikor egy elemző új tapasztalatot, ötletet tölt fel, erről a rendszer felhasználói értesítést kapnak, de persze a megoldások strukturáltan, és keresővel is elérhetőek. (Az egész megoldást MS Sharepoint alapokon építették fel, tehát még nagyon speciális technológiát sem kellett alkalmazni)

A megoldás sikeréhez hozzájárult az a 200 elemző, akik minden laktanyában, és sok bevetési ponton is jelen vannak, hogy a hadsereg tapasztalatait összegyűjtsék. Ezek az elemzők maguk is katonák voltak, így a hadsereg működése, és a megoldások értékelése nem okoz számukra nehézséget, sőt így nem csak a katonák, hanem a katonai vezetők is elfogadják ezeket az ötleteket. Az elemzők a legjobb ötleteket kivonatolják, a katonai vezetőknek közvetlenül is eljuttatják (feltételezve, hogy ők nem csüngenek egész nap a tudásmegosztó rendszeren).
A hadsereg köreiben eleinte nem tetszett nagyon a megoldás, mivel a hibákat (melyekből szintén sokat lehet tanulni) nem akarták sem megosztani, sem névvel ellátni. Az elemzők feladata így kiegészül az anonimitás biztosításával, illetve az általánosítható tapasztalatok megfogalmazásával is.

A „lessons learned” adatbázis építése érdekes módon az elmúlt években elsősorban a kockázatkezelési megoldásokhoz kötődik: azaz kerüljük el, hogy a már egyszer elkövetett hibáinkat újra megismételjük:
„Although the private sector does not mirror the Army’s strict command-and-control discipline, regulators are demanding that companies become more responsible and accountable. The Sarbanes-Oxley Act, which overhauled corporate governance in the aftermath of scandals at companies like Enron and WorldCom, and, more recently, the 2006 amendments to the Federal Rules for Civil Procedure, which address the discovery of electronically stored information, call for information audit trails to make certain that numerous departments within a company are aware of the organization’s activities, starting at the board level and touching on everything from finance to research and development.

A CALL-like system would encourage openness among the various business units. By setting up a formalized process for sharing ideas company-wide — the success stories and the failures — executives could introduce greater accountability to their company’s culture. As the first generation to grow up networked and collaborative in their social and educational lives moves into the work stream, sharing lessons learned across organizations — public or private — will become all the more plausible and necessary.”

(Idézet a cikkből)

2008. február 23., szombat

A Société Générale ügy

A ritka, de nagy hatású operatív kockázatok közé sorolható az a fajta veszély, melyet egyes bankok belső alkalmazottai követhetnek el. Különösen érdekes esetnek tekinthető a közelmúlt Société Générale bank esete (ld. HVG 2008. január 30).

A bank tisztában volt az operatív kockázatok fontosságával. De ugyanennyire tisztában volt vele Jerome Kerviel is, aki korábban épp a kockázatkezelési osztályon dolgozott. Így ismerhette az ellenőrzési szabályokat, illette ismerte azokat a megoldásokat is, melyekkel ezek a szabályok kijátszhatóak.

Kerviel 2005 óta kötött fiktív határidős ügyleteket, megtévesztve a belső ellenőrzési rendszert, és ezt be is vallotta. Ráadásul még azt is állította, hogy nem ő az egyetlen alkalmazott, aki a saját szakállára (de nem feltétlenül a saját hasznára) dolgozik. Kerviel hamis kliensszámlákat felhasználva egymásra épülő határidő üzleteket kötött, az általa felépített pozícióit elrejtette, és úgy tűnik, hogy igazából maga a bank sem akarta nagyon megtalálni. A bank automatikus rendszerei többször is kiadták a riasztást, és ekkor Kerviel felettesei számon is kérték a történéseket (főleg, mivel túllépte az engedélyezett összegeket), de ilyenkor mindig sikerült hamis dokumentumokkal igazlnia, hogy ügyletei nem jelentenek kockázatot a bank számára (ráadásul: "...az Eurex derivatív tőzsde már novemberben jelezte a bank vezetésének, hogy a kereskedő kockázatos ügyletekbe bonyolódott, de Kerviel kimagyarázta magát" - írja a Napi Gazdaság). Ebbe beletartozott az a hamis portfólió is, mely elvileg fedezte a kockázatosabb ügyleteket.Az ügyészség hamisításért, hamisított okiratokkal való visszaélésért és informatikai adatok automatizált rendszerébe történő behatolásért indított eljárást.

Mik az eset tanulságai?
  • Az emberekhez köthető kockázatok nem mindig egyéni haszonszerzés céljából történnek. Kerviel annak ellenére nem a saját zsebére dolgozott, hogy fizetése ebben a szakmai körben nem volt kiemelkedő, egyszerűen szerette volna bebizonyítani, hogy kivételes képességű bróker.
  • Az eset rávilágít arra, hogy hiába van tisztában egy bank az operatív kockázatokkal, nem biztos, hogy mindent megtesz ezek kivédése érdekében. Sőt, az intézmények sok esetben tudatosan vállalnak bizonyos fokú kockázatot, mivel félnek, hogy a túlzott ellenőrzés és kontroll megöli a kezdeményező kedvet. Lehet, hogy itt is erről volt szó?
  • Hiába használ egy intézmény informatikai rendszert a kockázatok felderítésére, ha ezeket hagyományos eszközökkel ki lehet játszani. Hogy fordulhat elő, hogy hamis okiratok fedezik az ügyleteket? Bár elvileg minden tranzakció az informatikai rendszereket keresztül folyik (és mindennek nyoma van), úgy tűnik még mindig nem elég erősek a szabályok.
Megjegyzés: nem tudhatjuk, hogy mennyi kárt okozott Jerome Kerviel, de egyes hírek szerint a 4,9 milliárd eurós veszteség egy része nem is az ő nevéhez fűződik, csak éppen kapóra jött, hogy valakire rá lehet kenni a többi problémát is. Mert ugyan melyik pénzintézet szokta megszellőztetni az ilyen jellegű problémáit? A lebukott alkalmazottaktól sokszor titokban vesznek búcsút, anélkül, hogy a veszteségek nyilvánosságot kapnának. Az ilyen kirívó eseteket évekig példaként lehet felhozni a kockázatkezelési feladatok hiányosságaira és fontosságára.

2008. február 22., péntek

Vállalati szociális háló alkalmazás használata

Kapcsolódva a korábbi social-network témához. Most olvastam egy kezdeményezésről, melynek célja, hogy vállalati social-network eszközt alkalmazzanak, mely segítségével "össze lehet kapcsolni olyan embereket, akik sosem találkoztak, megoszthatják a gondolataikat[stb.]. Ez hozzájárul az elégedettség növeléséhez, illetve a részvétel fokozásához."

A korábbi írásban már idéztem a McKinsey féle megközelítést, hogy formalizáljuk ezeket a hálózatokat. Ha egy laza hálózatot csinálunk, akkor is ennek inkább olyan célt tűznék ki, hogy fogjuk össze az embereket, és támogassuk őket a kommunikácóban. Ebben talán nagyobb szerepe lenne egy nyilvános blognak (vagy bloghálózatnak témaspecifikusan), vagy a vállalati intranetre épülő discussion fórumnak, vagy wikinek.

Egy szociális hálózat eszköz nem biztos, hogy megteremti az ismeretlen emberek közötti kapcsolatot, hiszen pont az a célja, hogy ismerőseinkkel kapcsoljanak össze. Nem fogunk ismeretlen kollégákat felvenni az ismerőseink körébe. Ráadásul a kommunikáció általában nem is a social-network megoldáson keresztül történik (mindenki gondolja csak át a saját példáján keresztül: lehet, hogy az első 1-2 kapcsolat ott kerül kialakításra, de utána már a szokásos levelezőrendszerét használja az ember).

Egy szociális háló alkalmazást persze lehet (sőt akár célszerű is), mintegy tudástérképet használni, de ehhez ezt ki kellene egészíteni a munkavállalói profilokkal. Ennek persze megvannak a maga kihívásai: Mindenki azt tölt fel, amit akar, vagy a HR kezelésébe helyezzük a kérdést? Esetleg az éves értékelések részeként a kollégáktól kérdezzük meg mások tudásprofilját? Vagy ennek egyfajta kombinációját használjuk? Mindenféle módszernek megvannak az előnyei és hátrányai, ez persze az elvárásoktól függ.

Személyes véleményem szerint nem kell azért túldimenzionálni a social network megoldások szerepét. Népszerű web2-es alkalmazásokat bevonni a vállalati működésbe, de nem minden kontroll nélkül. Így a szociális hálózatokat támogató megoldások első körben nem tartoznának a fő megoldások közé. A blogok, wikik, esetleg még a videomegosztás is hasznos lehet, ugyanakkor mindent egy tudatos tudásmenedzsment stratégia körében valósítanám meg. A blogok, wikik lehetnek az informális tudáscsere részei, míg egy tudatosan felépített tudásbázisba érdemes lehet összegyűjteni az ezekben megjelenő best practice-ket. Már csak azért is, mert az informális tudáscserét támogató megoldások strukturáltsági foka alacsony, és nem minden információ jut el oda, ahova szánták. A decentralizált megoldások mellett igenis szükséges a központi kezelés, hogy szűrt és validált információkat alacsony tranzakciós költség mellett (=energiabefektetéssel) meg lehessen szerezni.

2008. február 18., hétfő

Pénzintézetek operatív kockázatai

A pénzintézetek számára mérvadó Basel II ajánlásrendszer 2004-es publikálása, annak 2006-2007 folyamán történő európai elfogadása óta a pénzintézetek egyre nagyobb figyelmet fordítanak a tevékenységükhöz kapcsolódó kockázatok azonosítására, mérésére és kezelésére. Persze nem csak a szabályozási környezet kényszeríti ki ezen elvek alkalmazását, hanem a pénzügyi piacok globalizációja, illetve azon csalások, melyek a pénzintézeteknek jelentős károkat okoznak. Gondoljunk csak a közelmúlt Société Générale csalására, amikor is 4,9 milliárd euró veszett el egy alkalmazott szabálytalan tranzakciói miatt.

A Basel II direktíva a kockázatkezelés és a pénzintézeti tőkemegfelelés kérdéskörét igyekszik az iparági legjobb gyakorlatok felhasználásával segíteni. A kockázatkezelési portfolióban meg kell különböztetnünk a működési, hitelezési és üzleti kockázatokat. Míg a hitelezési kockázatok kezelésére vonatkozólag jelentős tapasztalat áll rendelkezésre, addig a Basel II megközelítésében is újdonság, hogy a működési (operatív) kockázatok külön kerülnek kezelésre.

Az operatív kockázatok között a hagyományos PPT modell (people, process, technology) elemei mellett szerepet kap a külső környezet fenyegetése is.

Bár a Basel II megközelítésében a működési kockázat elválik a hitelezési és piaci kockázattól, a működési kockázatok mégis minden pénzintézeti tevékenység (így pl. a hitelezési folyamatok) részét képezhetik. Miközben a működési kockázatok a végrehajtási szintet vizsgálják, addig a más kockázatok a piaci, vagy ügyfélkörhöz kapcsolódó bizonytalanságokkal számolnak. Így a működési kockázatok elemzése és kezelése jelentős mértékben kiegészíti más kockázatok elemzését.

A működési kockázatok kezelését érdemes folyamatmodell mentén végezni: a pénzintézeti folyamatok feltérképezésével nem csak a sebezhető pontok (informatikai rendszerek, szabályozási hiányosságok) azonosíthatóak, hanem a folyamat maga is racionalizálható, ellenőrzési pontok beiktatásával biztonságosabbá, ugyanakkor hatékonyabbá is tehető. A folyamatrendszer kezelésének automatizálásával, illetve az egyes tevékenységekhez kapcsolódó adatok elemzésével a kockázatok (és hibák) könnyen azonosíthatóvá, így kezelhetővé válnak.

Megjegyzendő, hogy egy működési kockázatokat kezelő rendszer kiépítése korán sem egyszerű, és koránt sem gyors folyamat. A pénzintézetek legtöbb esetben tanácsadó cégek segítségét veszik igénybe, hogy kiépítsék ezt a rendszert. Ez elég racionális döntés, mivel a szakértőket elég bérbevenniük, mintsem állományba.

Az IT Business 2008. 7. számában jelent meg egy cikk, mely a tanácsadók szükségességéről értekezik. Ebben Szalkai Gergely a Credigen IT vezetőjének véleménye szerint "nagyobb, profilt vagy a működést technológiai szempontból is érintő változás esetén kell tanácsadóhoz fordulni segítségért". A pénzintézetek esetében arról van szó, hogy olyan új kockázati terület kezelését kell megoldani, mellyel eddig nem foglalkoztak, sőt nem is igazán kívántak foglalkozni.

Ugyanakkor tanácsadók alkalmazása kihívást is jelent: egy pénzintézet érdeke, hogy életképes kilépési (exit) stratégiával rendelkezzen egy ilyen projekt esetében is: a projekt folyamán a pénzintézetben ki kell jelölni a kockázatmenedzsment felelőseit, és az ő aktív bevonásukkal kell végrehajtani a projektet. A projektfolyamat során a tanácsadók által alkalmazott módszereket, megközelítéseket át kell venniük, majd a projekt lezárulta után alkalmazni.

A már említett IT Business cikkben Futó Iván, a Budapesti Corvinus Egyetem professzora úgy vélekedik, hogy "a projekt során erőteljesen törekedni kellene arra, hogy a belső munkatársak mindazt a tudást megszerezzék, amelylyel a működtetést és az esetleges későbbi módosításokat már külső támogatás nélkül is el tudják végezni. Amennyiben erre nincs mód, akkor azonban már áttévedünk az outsourcing területére."