BIZALOM NÉLKÜL NEM MEGY

A. Bevezetés

Amikor e tanulmány szerzője és munkatársai egy sok konfliktust kiváltó bank-számítástechnikai projekt mélypontján szinte magukba roskadva próbálták megérteni, hogy egy nagy jelentőségű és előremutató fejlesztés hogy válthat ki olyan mértékű ellenállást ill. ellenszenvet a befogadó szervezetben, az egyik munkatárs – huncut mosollyal – egy röplapszerű papírlapot tett a többiek elé, rajta az alábbi, ott angol nyelvű szöveggel:

Nincs a földön nehezebb és kockázatosabb feladat, mint a dolgok rendjének megváltoztatása. A reformernek ellenségei lesznek mindazok, akik a régi rendből hasznot húztak, s csak langyos támogatói azok, akik az új rendtől előnyt remélnek. Ebben az ember eredendő bizalmatlansága nyilvánul meg. Nem igazán hisz abban, ami új, egészen addig, míg előnyeit a valóságban nem tapasztalta.

Machiavelli (1469-1527)

Majd elmondta, hogy ezt a lapot a projekt egy korábbi válságos pillanatában kapta vigasztalásul a munkában résztvevő angol szakértőtől, aki egy korábbi projekt válságos pillanatában kapta akkori főnökétől, aki ....

Az informatikai projektek valóban ritkán tartoznak a könnyű sikert, gyors elismerést, általános megelégedettséget eredményező fejlesztések közé. Későbbi életük sokkal békésebb; rövidebb-hosszabb "berázódás" után a rendszerek mélyen beépülnek az őket befogadó humán közegbe, s egyszer csak csendben megfogalmazza valaki, hogy a "régi módon" már elképzelhetetlen lenne az élet. E csendes beismerés rendszerint jóval korábbi keserves kínlódások és küzdelmek részeseinek adja meg a megkésett, s akkor is szemérmes elismerést. A címzettek ennek csak nagyon ritkán örülhetnek. Addigra ők már valahol máshol vívják újabb csatáikat.

E jelenségek széles körben ismertek. Az izgalmas kérdés azonban az: törvényszerű-e, hogy az informatikai fejlesztéseknek ilyen nagy feszültségeket kell gerjeszteniük, milyen erők gerjesztik ezeket a feszültségeket, s – ami a legfontosabb – nem lehetne-e kikapcsolni vagy akár csak csökkenteni a negatív hatásokat ?

A szerző jó két évtizedet töltött informatikai fejlesztések megvalósításával majd irányításával. E tevékenység döntően pénzintézeti, banki környezetben zajlott, s a szerzőnek nem is áll szándékában megalapozatlan általánosításokkal mondanivalójának szélesebb körű érvényességet tulajdonítani. A gazdasági élet más területein tevékenykedő olvasó azonban valószínűen sok, általa is ismert, általánosítható megállapítással fog találkozni a tanulmány olvasása során.

A tanulmány fejtegetései mögött megbúvó központi kérdés: az emberek hogyan reagálnak azokra a változásokra, amelyeket a korszerű információ technológia gyors térhódítása vált ki mindennapi tevékenységükben. A reakciók természetesen különböznek a változást elszenvedőnek a munkamegosztásban elfoglalt helyzetétől függően. Másképpen éli át a változást az ügyintéző, kinek számára az átállás egy egyszeri és nem is túlságosan tartós többletterhelést jelent, másképpen a középvezető, kinek egzisztenciáját a változás a legjobban veszélyezteti, s másképpen a felső vezető, kinek számára a változásnak az intézményi belső hatalmi viszonyokra gyakorolt hatása jelent kihívást.

Még mielőtt a téma módszeresebb feldolgozásához hozzáfognánk, talán érdemes egy konkrét példa segítségével szemléltetni, milyen mélyen érintik e változások az egyes szereplők egzisztenciális viszonyait.

Egy – korábban csak hagyományos módon dolgozó – bankfiók munkájának gépesítésére új, lokális számítástechnikai rendszert vezettek be. A fiókban együtt dolgozó, döntően fiatalokból álló csoportnak volt egy "korosabb", 40-45 éves vezetője, aki a csoport tagjainak bizalmát élvezte, szakértelmét mindannyian elismerték. Volt a csoportnak egy "fekete báránya" is egy fiatal munkatárs személyében, aki nem találta meg a helyét a bankfiókban, a feladatok nem kötötték le figyelmét, "használhatatlan" volt, bárhol tették próbára képességeit. Történetünk kezdetén már fél lábbal az utcán volt. A számítógépes ügyintézésre való átállás időszakában azonban, mint amolyan "ráérő", másra úgysem használható ember, egyre többet őgyelgett a programozók körül, felkeltette kíváncsiságát az újszerű munka, s mire a rendszer átadása megtörtént, ő lett a "szakértő". Ugyanakkor főnöke, aki életkoránál valamint nyilvánvalóan jóval nagyobb, s az átállás egyébként is hisztérikus légkörű heteiben az elviselhetetlenségig fokozott leterheltségénél fogva nehezebben alkalmazkodott az új helyzethez, fokozatosan elvesztette befolyását az ügyek irányítására, és néhány hét múlva megszégyenülten kilépett.

Ebben a szélsőségességében ritka, de nagyon tanulságos esetben a számítógép egy csapásra megváltoztatta a munkahelyi értékrendet, sikeres embert csinált a haszontalanból, s kudarcba kergette az egyébként minden szempontból értékes, de a változásokat kevésbé befogadni képes személyiséget.

A többség végül is látványos megrázkódtatások nélkül alkalmazkodik a változásokhoz, de hogy a változások mindannyiuk lelkierejét próbára teszik, a fentihez hasonló, több száz átállási folyamat tapasztalatai alapján bizonyosan állítható. A munkaszervezet különböző hierarchia szintjein dolgozó, különböző adottságú és karakterű emberek reakciói egymást szándékolatlanul vagy akár tudatosan befolyásolva, transzformálva egy jellegzetes effektust eredményeznek, melynek lényege: a változásokat meggátolni, hatásukat semlegesíteni, de legalábbis csökkenteni, vagy az általuk kívánt mederbe terelni vagy abban tartani. Szinte a Newton erő-ellenerő törvényének speciális, a társadalmi szférában érvényes változatát érzékeljük: "minden hatással szemben, mely egy szervezet mozgásformáját megváltoztatni szándékozik, fellép egy azzal azonos nagyságú, de ellentétes irányú hatás".

Esetünkben a "hatás" – az erőltetett, sokszor hajszolt korszerűsítési szándék – nyilvánvalóan és szinte minden társadalmilag elfogadott értékrend szerint pozitív, progresszív hatás, és nem is vállalja senki nyíltan az "ellenhatás" szerepét. De az egyéni és kollektív tudat mélyén leküzdhetetlenül működnek azok a személyes és csoportérdekek, melyek nyomában az ellenállás a legkülönbözőbb módon, álcázottan, áttételesen, a felismerhetetlenségig elváltoztatott formában, sőt nagyon sokszor progresszív argumentációval tör fel. Pusztán a retorika alapján a résztvevők "pártállása" nem azonosítható; a külső szemlélő szinte azt hiheti, egyenrangú szakmai alternatívák vitájáról van szó. Az esetek döntő többségében azonban a vita polaritása egyértelmű (legfeljebb nehezen felismerhető): az egyik oldalon áll a helyzetéből, funkciójából adódóan változásokat végrehajtani akaró információ technológiai (IT) szervezet, a másik oldalon az azt szándékában lehetőleg szalonképes indoklással megakadályozni kívánó funkcionális szervezet.

A mondanivaló egyértelmű kifejezésének legmélyebb szándéka sem indokolhatja azonban, hogy egyoldalú és igazságtalan állításokra ragadtassuk magunkat. Természetes, hogy sok esetben az IT szervezet vagy vezetőjének álláspontja hibás, ráadásul oly mértékben, hogy azt akár laikusok is felismerik, máskor a funkcionális szervezet szakértői támogatással tud fellépni a csak látszólag szakértő IT munkatársakkal szemben. Nem ritkán az IT projektek menedzselésének hibáira vezethetők vissza a kudarcok. Mégis, tanulmányunknak nem ezek a gyakran szintén nehezen feltárható konfliktusok  képezik témáját, hiszen ezekben az esetekben egyszerűen helytelen szakmai álláspontok elleni fellépésről van szó. 

Mi az, ami ezeknek a kérdéseknek kiemelt jelentőséget kölcsönöz ? A gazdasági folyamatok – esetünkben a banki szolgáltatások – korszerűsítésére irányuló egyre erősebb objektív igény. A központi irányítás évtizedeiben nem annyira az üzleti szükségszerűség, mint inkább egyfajta presztízs, a fejlett országokban tapasztaltak átvételére irányuló, gyakran egyéni ambíció állt egy-egy fejlesztési döntés hátterében. Ma a piacgazdaság kiépülésével párhuzamosan a gazdasági hatékonyság iránti igény egyre követelőbben jelentkezik. A bankszférában a hatékonyság növelése elsősorban az információ technológia eszközeinek egyre szélesebb körű igénybevételével lehetséges. Az iparilag fejlett országokban ez az igazság már evidencia, de a magyar bankokban is egyre jobban terjedő felismerés. A fejlett országok bankjainak már kiépített információ technológiai infrastruktúrája (központi számlavezető rendszer, adatátviteli hálózat stb.) lehetővé teszi, hogy a bank az üzleti kínálat bővítése nélkül, pusztán új technológia alkalmazásával versenyelőnyhöz jusson (pl. a meglévő folyószámla szolgáltatás üzleti értéke jelentősen megnő, ha az ügyfél mindennapos folyószámla tranzakcióit otthonából telefonon keresztül is kezdeményezni tudja). Ebben a helyzetben a bank presztízsét s így versenyképességét is előnyösen befolyásoló fejlesztések is új jelentőséget kapnak: az új technológia új szolgáltatást jelenthet.

A magyar bankok még az alap infrastruktúra kiépítésének szakaszában vannak. Ebben a fázisban a technológia ezen közvetlen, üzletet befolyásoló hatása még alig érvényesül, ehelyett a manuális munka mennyiségének visszaszorítása, a központi vezetői döntési információk naprakészsége, az ügyviteli rend megszilárdítása stb., végeredményben a bank hatékonyságának növelése kerül előtérbe. Végül is, a motivációtól függetlenül a fejlesztéseket körülvevő konfliktusok természete azonos: a technológiai fejlesztések lépten-nyomon megváltoztatják a korábban kialakult munkafolyamatokat, s egyúttal kiváltják a változásokat meggátolni kívánók reakcióit. Mennél hajszoltabbak a fejlesztések, annál élesebbek a konfliktusok.

Ezért a részletek szintjén fontos célunk lesz bemutatni, melyek e fejlődési konfliktusok magyar, vagy közép-európai sajátosságai. A végső cél persze megfogalmazni azokat az ajánlásokat, melyek hozzásegíthetnek, hogy a frontvonal jobban felismerhető és a konfliktusok s azzal arányosan a veszteségek mennyisége csökkenthető legyen.

A tanulmány soron következő része 3 tézisbe sűrítve próbálja rendszerezni a banki IT fejlesztésének a fentiekben vázolt problematikáját. Látni fogjuk, hogy ebben a speciális megközelítésben a központi fogalom egy, a társadalmi rendszerektől, koroktól független, általános emberi kategória, a bizalom. A bizalom szót két, egymáshoz közel álló értelmében használjuk: egyrészt a személynek, személyeknek (konkrétan és kifejezetten az IT szervezet vezetőjének, vezetőinek, munkatársainak) szóló bizalomról, másrészt az ügynek, a fejlesztés sikerének, az érdekeltek számára előnyös voltának szóló bizalomról beszélünk.

A tanulmány további része bemutatja a magyarországi banki informatikai fejlesztés azon belső ellentmondásait, amelyek a tézisekben megfogalmazott állítások mögött húzódnak meg. Ezeknek az ellenmondásoknak bonyolult összjátéka hozza létre azt a jelenségcsoportot, melyet egy adott nézőpontból a tézisek segítségével próbálunk meg leírni.

Végül a tanulmány záró része megkísérli pozitív ajánlásokban megfogalmazni az általában negatív, kritikus módon megközelített problémák megoldását.

B. Tézisek:

I. Bizalom nélkül nem megy.

II. A bizalmat nem lehet megszerezni.

III. Az érdekek sérelme a meglévő bizalmat is aláássa.

I. Bizalom nélkül nem megy

Az IT fejlesztések nélkülözhetetlen előfeltétele a bizalom. A bank elnökének, vezérigazgatójának, felső vezető testületeinek meg kell bízniuk az IT szervezet vezetőjében és munkatársaiban, hogy azok végeredményben a banki üzletpolitikában meghatározott célok érdekében a legjobb szakmai megoldásokat fogják alkalmazni, s azok hozzásegítik a bankot üzleti céljai eléréséhez.

A tézis más fogalmazásban azt állítja: a banki IT fejlesztések esetében nem támaszkodhatunk a más területeken talán jobban megszokott, a bizalomnál erősebb, közvetlenebb, szilárdabb alapokra, mint pl. tudás, meggyőződés. Az elnök nem lehet bizonyos abban, hogy az IT ügyei jó kézben vannak, csak bízhat benne. Miért?

Az információs technológia rendkívül bonyolult és rendkívül gyorsan fejlődik. A mikrochip-ek világától a rendszerfejlesztési szoftver-eszközökig ma már sok olyan szintje van, mely önálló diszciplína az IT-n belül, s melyek megnyugtató biztonsággal történő átlátása egy embertől nem várható el, bármilyen tapasztalt is legyen. Magasan kvalifikált szakemberek csapata tud csak működőképes rendszert létrehozni. A banki informatika, mint a mai napokig az informatikán belül is egyik legkomplexebben kifejlesztett ágazat, összetettségénél fogva saját művelői számára is nehezen átfogható.

Ma még nincs a magyar bankoknak olyan vezető menedzser állománya, mely az IT fejlesztésekkel kapcsolatos felsőszintű döntésekhez szükséges speciális ismeretekkel ill. tapasztalattal rendelkezne. A jó bank menedzserek legfeljebb a "divatos igazságok" szintjén (pl. jobb a kész programcsomag, mint a saját fejlesztés) érthetik meg a problémákat, különösen nem lehetnek képesek a döntések sokoldalú következmény rendszerének áttekintésére. Ebben természetesen nem személyes adottságaik gyengesége akadályozza meg őket, hanem az az egyszerű tény, hogy általában nem tudnak életükből éveket az információ technológia kérdéseinek tanulmányozására fordítani. A döntéseket előkészítők (pl. IT szakemberek) és a döntéseket meghozók (pl. igazgatósági értekezlet) általában rendkívül eltérő ismereti bázison állnak, gondolkozásmódjuk között óriási a távolság. Egy-egy előterjesztés megvitatása így aztán nagyon gyakran süketek párbeszédévé válik.

Nem jöttek még létre azok a döntési mechanizmusok ill. a működésükhöz szükséges szervezeti formák sem, nem akkumulálódott még a bankok üzleti vezetésében annyi és olyan szintű IT ismeret, amely/ek/ a vázolt döntési problémákat megnyugtató szinten megoldaná/k/. A döntéshozók habitusa, élettempója, megszokott munkamódszere is lehetetlenné teszi, hogy megfelelően elmélyüljenek a döntést motiváló aspektusokban, idegesek lesznek a tőlük idegen témákban eléjük kerülő előterjesztésektől, sokallják azokat. Milyen alapon jöhetnek létre mégis döntések: a bizalom alapján. Amíg bizalom van, fél szavakból értik egymást főnök, beosztott és munkatárs. De ha nincs meg a minimális bizalom, kezdetét veszi a helyettesítő eszközök, mechanizmusok alkalmazásának keserves korszaka. Előbb csak a döntések halogatása, újabb és újabb "részanyagok" kidolgoztatása, majd a fejlesztő csoportok "versenyeztetés" ürügyén történő kijátszása egymás ellen, "független" szakértők alkalmazása a hierarchia különböző szintjein, s egy bizonyos ponton túl be kell, hogy következzék a "személyi konzekvenciák levonása", mely elsősorban a megrendült bizalom helyreállítását célozza: olyan új ember kerüljön a pozícióba, akiben a többiek jobban megbíznak.

Az előzőekben leírtak általános menedzselési problémák, és véletlenül sem kizárólagosan a bankok IT fejlesztésével kapcsolatosak. Első tézisünk nem is kíván sem többet, sem kevesebbet állítani, minthogy a bizalom jelentősége az IT fejlesztésekkel kapcsolatban az átlagosnál nagyobb.

II. A bizalmat nem lehet megszerezni

A munkahelyi szervezetek vezetőivel, munkatársaival vagy akár egy szervezeti egységgel szembeni bizalom kialakulásának mechanizmusa közismert. A bizalom a személlyel, szervezeti egységgel szembeni elvárások teljesülésének és nem teljesülésének egy folyamatosan pozitív szaldójú folyamatában jön létre: sikeres akciók teremtik meg egy újabb akció esetén a bizalom megszavazásának alapját.

A banki IT fejlesztéseknél ez a pozitív szaldójú folyamat legtöbbször nem jön létre:

- az elvárások jellemzően irreálisak, teljesítésük gyakran ténylegesen lehetetlen,

- a felső szintű vezetés hibái /arroganciája, voluntarizmusa, a valós problémák iránti érzéketlensége/ megnehezíti, hogy az eredmények megszülethessenek és az eredmények reális értékelése bekövetkezhessék,

- a fejlesztési folyamat jellegéből adódóan folyamatosan rengeteg feszültség keletkezik az IT szervezet és az IT felhasználói között, ezek végeredményben rossz fényben tüntetik fel az IT szervezet tevékenységét akkor is, ha az eredményes.

így a bizalmat csak megelőlegezett bizalomként lehet elképzelni ill. megszerezni. De ez a bizalom is csak akkor nyugodhatna reális alapokon, ha a megelőlegezés korábban, pl. más intézménynél, más szervezeti egységnél kiérdemelt bizalomra épülne. Ez azonban vagy más jellegű munkaterületen (pl. személyzeti, számviteli) történhetett, s akkor nem mérvadó, vagy éppen részletezett tézisünk szerint lehetetlen.

III. Az érdekek sérelme a meglévő bizalmat is aláássa

A változás – bármilyen jellegű is legyen az (korszerűsítés, racionalizálás, gépesítés, automatizálás) – érdekeket sért. Bár a változás/változtatás szükségességét általában senki nem vonja kétségbe, valós érdekek fűződnek a változatlansághoz is. Ezen érdekekben az objektív és szubjektív elemek széles skálája jelenhet meg:

- bizonyos esetekben a változásnak objektív akadálya van (túl nagy volumenek, túl sokirányú követelmények, bonyolult változtatások egyidejű végrehajtásának követelménye stb.),

- a rendelkezésre álló humán kapacitások szűkössége akár minőségi akár mennyiségi értelemben,

- emberi gyarlóság, mely a változatlanságot, mint kényelmeset preferálja,

- a meglévő ügyviteli rendetlenség nyilvános feltárásától való félelem,

- a változásoknak a személy/csoport számára optimális irányba való eltérítésének szándéka,

- a változás felismert, egzisztenciát érintő hatásából eredő tudatos ellenállás.

E vázlatos felsorolásban a sorrend nem véletlen: az objektív ellenérdekek rovására a szubjektív ellenérdekek dominanciája nő. Ezzel párhuzamosan nő az érdekellentétek által motivált feszültségek mélysége és romboló volta. Míg az emberi lustaság hatása viszonylag könnyen semlegesíthető, az álcázott de tudatos ellenakciók súlyos károkat okoznak a fejlesztő folyamatnak. Az IT szervezettel szemben megnyilvánuló, bizalmat erodáló hatás azonban mind a szubjektív mind az objektív elemeknél jelentős.

Következmények

Ha az I.-II.-III. tézisek együttes hatását megkíséreljük modellezni, azt találjuk, hogy ciklikus folyamatnak kell gerjednie, melyben újabb és újabb "jelöltek" kapnak bizalmat és vesztik el azt. Mivel a bizalom csak megelőlegezett lehet, és birtokosa azt is fokozatosan elveszíti, újra és újra olyan ember (esetenként szervezet) kap bizalmat "akinek még nem volt módja elveszíteni". Ezek az újoncok, akiknek megjelenése önfenntartó elemmel gazdagítja a modellt: a tapasztalatlanságuk miatt valószínűen még hamarabb veszítik el a bizalmat.  

A valós társadalmi folyamatok természetesen sokkal bonyolultabbak, mint hogy a fentiekhez hasonlóan egy-két szabállyal rendelkező modellel leírhatók lennének. Modellünk ennek ellenére "valószerűen" működik. Napjaink mindennapi eseménye a nagy tapasztalatú banki IT menedzserek elhullása, s teljesen tapasztalatlan utódok megjelenése. Még nagy szervezetek sem tudnak bizalmat vesztett első emberük helyett utódot állítani. Világos, miért: vezetőjükkel együtt a második, harmadik vonalban állók is kiérdemelték a "bizalomvesztést".

/Kétségtelen, hogy ez a folyamat egyúttal a banki informatikai menedzser szakismeret hatalmas "eredeti felhalmozódása". Bankjaink, melyek a fenti modell szerint működnek, nagy hatékonysággal termelik a jól képzett és tapasztalt menedzsereket, akik azonban egyenlőre nem számíthatnak sikeres karrierre./ 

C. Ellentmondások

A banki IT fejlesztési folyamat egyes ellentmondásaira korábbi fejtegetéseinkben már utaltunk. Az alábbiakban megkíséreljük ezen ellentmondások módszeres számbavételét. Ennek során – a tanulmány mondanivalójának mennél gazdagabb illusztrálása érdekében – élni fogunk a példálózás nem kifejezetten tudományos eszközével is.

1. Az álmok és a valóság ellentmondása

A meghonosítandó mintákat kiválasztó bankvezérek nyugati társbankoknál, IT gyártóknál, nemzetközi szakmai seregszemléken, szakmai konferenciákon tett látogatásaikon élenjáró technológiát, gazdagon kiépített kommunikációs hálózatokat, több generáción át, több nagyságrendnyi növekedést megért banki felhasználói rendszereket látnak. Érintésre működő képernyőt, intelligens, sok szolgáltatású bank automatát, dinamikus aláírás rögzítőt, automatikus bizonylat olvasót stb. Ezek a termékek már 2-3 jelentős technológiai forradalmat (hardver/szoftver generációt) s egyúttal évszázados banki tradíciókat kódolnak magukban. S ugyanezeket a termékeket olyan intézményekben kellene bevezetni, amelyekben a munkatársak 80-90 %-a, s nem csak az ügyintézői körben, szakképzetlen, ill. "monokultúrás". Ez utóbbi kategória azoké, akik ugyan pontosan tudják, hogy mit csinálnak, de arról, hogy hogyan lehetne, ill. hogyan kellene jobban, se tudásuk, se tapasztalatuk.

Nem kellően felkészült és tapasztalt a fejlesztő gárda sem. Aki egy kis lokális banki üzletágacskát már beprogramozott, az már bank-számítástechnikai szakértőnek számít.

A valóság egyik legkeservesebb eleme a COCOM volt, mely mára ugyan a múlté, de visszahatása még sokáig fékezni fogja a fejlődést. (A COCOM nevű hírhedt intézmény volt hivatva megakadályozni, hogy bármi "használható" technológia bejuthasson a kommunista blokk országaiba). Azok a bankok, melyek a COCOM évtizedeiben a mégis elérhető kényszermegoldásokhoz folyamodtak, most azzal is vesződhetnek, hogy azokat hogyan lehet kiváltani.

Az álmok és a valóság távolsága megvalósíthatatlan, voluntarista döntésekre csábítja a progresszívebb bankvezéreket ("én is ezt szeretném a bankomban, lehetőleg azonnal"), kiszámíthatatlanná teszi a fejlesztési folyamatot (ilyen élmények havonta átrajzolhatják a fejlesztési terveket), ezáltal folyamatosan kudarcokkal terheli a fejlesztéseket végrehajtó, azokat menedzselő réteget. Eredmény: az ügyfél elégedetlen a szolgáltatás minőségével, az ügyintéző a munkafeltételeivel, de a vezérigazgató is azt tapasztalja, hogy semmi sem valósul meg abból, amit ô kezdeményezett.

Példa. A hetvenes évek közepén az egyik bankban létrejött egy adatbázis lekérdező rendszer, mely lehetővé tette, hogy a bank vezetése számára szinte tetszőleges kigyűjtéseket lehessen készíteni, akár percek alatt is. Abban az időben egy ilyen rendszer kiugróan jó eredménynek számított. Az IT területért felelős vezérigazgató helyettes e szavakkal méltatta a rendszer egyik első termékét: "Most megmutatom az elvtársaknak, miért használhatatlan számomra ez a lista ....", majd elmondta, milyen nagyszerű on-line lekérdező rendszert látott ô Amerikában. Nyilvánvalóan ez az élmény határozta meg hozzáállását. Hogy az adott esetben a termék nem elégítette ki a vele szemben támasztott, maximalista igényeket, az nyilvánvaló. Hogy az Amerikai mérce használata a legsötétebb COCOM évek Magyarországán irreális volt, szintén nyilvánvaló. Jó vezetői döntéseket azonban csak a realitások ismeretében lehet hozni. 

2. A banki döntések és az informatikai fejlesztési munka ellentmondása

Egy jó banki üzleti döntés meghozatalának netto időigénye néhány órától néhány napig terjed. Problémafelvetés, néhány konzultációs megbeszélés, előterjesztés fogalmazás, döntés.

A banki döntések által indukált informatikai fejlesztés időigénye azonban nemcsak független a döntéstől, annak súlyától, jelentőségétől, meghozatalának nehézségétől, hanem nagyságrendekkel nagyobb is. A különbséget a részletkérdések áttekintése, aprólékos tisztázása jelenti.

Az alábbi gondolatkísérlettel szemléltethetjük e jelenséget.

Ha egy döntés csak félig kiérlelt, pontatlanul fogalmazott, rejtett ellentmondásokat tartalmaz, az hagyományos módon még végrehajtható. A végrehajtás során előkerülnek a tisztázatlanságok, eseti korrekciós döntések születnek, s bár a végrehajtók bosszankodnak, a végrehajtás megtörténik. Nem egy példa van arra, hogy egy bank apparátusa éppen, hogy előkészített, hiányos vagy csak vázlatos  utasítások alapján megindít egy üzletágat, s sok csikorgással ugyan, de a gépezet beindul. A csiszolódás folyamatában összegyűlnek azok a tapasztalatok, melyek lehetővé teszik, hogy később valóban jó, alapos és korrekt ügyviteli szabályozás készüljön. Ezzel szemben a számítógép nem programozható "bizonytalanul", "ma még nem tudjuk pontosan, hogyan kellene" alapon. Sőt, a legapróbb részletekig tisztázni kell minden speciális, csak ritkán előforduló esetet is. Az emberi közösség intelligenciája az, ami a nem, vagy rosszul megtervezett részleteket öntevékenyen kiigazítja. A számítógép erre nem képes. 

Tipikus, a banki szakember és az IT szakember közötti  beszélgetés az alábbi:

- „Mennyi idő alatt tudnátok módosítani az X rendszert úgy, hogy ....”

- „Csak akkor tudok válaszolni, ha előttem van a pontos feladat specifikáció ....”

E beszélgetés időpontjában a pontos specifikáció természetesen nincs meg, hiszen a kérdés arra irányul, hogy az A, B, vagy C ötletet dolgozzák-e ki a pontos specifikáció szintjén. De a banki szakember újból és újból felteszi a kérdést, s nem igazán érti, miért nem kap világos választ.

"Az ördög a részletekben lakozik". E jól ismert szólás gyakran elhangzik ilyen beszélgetések során. Sajnos (de természetes) a döntéshozók ritkán ismerik azokat a részleteket, amelyek a valós munkaigényt meghatározzák.

Ezen ellentmondás kellemetlenebb megnyilvánulása, hogy a bank vezetősége nem tudja megbecsülni egy-egy döntésének várható következményeit. A gyakorlatban a becslés hibája mindig ugyanolyan előjelű, és az informatikai termék jóval lassabban készül el, mint várják. Ez a jelenség alapvető jelentőségű az IT apparátussal szemben kialakuló bizalmatlanság terén.

Példa. Egy bank vezérigazgatója nyilatkozik a GIRO interfészről: "Nem tudom miért kell olyan nagy ügyet csinálni ebből, hiszen végül is egy egyszerű dologról van szó". Elvileg tényleg egyszerű. De az adott bankban nincsen senki, aki ennek az egyszerű dolognak minden vonatkozását (s nem is hardver/szoftver, hanem pusztán funkcionális szempontból) végig tudná gondolni. A vezérigazgató csalódása törvényszerű lesz.

Ugyanennek a példának rosszabb változata, ha egy – a banki piacra behatolni akaró, és nem kifejezetten tisztességes – külső vállalkozó használja ki a vezérigazgató tapasztalatlanságát, s "aláígér" a banki IT szakemberek becslésének. Az első bizalomvesztés akkor lép fel, amikor a vezérigazgató azt hiszi, hogy saját szakembere becsapja, a második akkor, amikor nem teljesül  a határidő. Egy későbbi akkor, amikor a banki belső IT szervezet valóban irreális ígéreteket tesz azért, hogy a nyilvánvalóan sarlatán vállalkozó ne kaphassa meg a megbízást.

Példa. Egy bank nagyszabású fejlesztésre szánja el magát. A külső cég azt ígéri, hogy egy éven belül elkészül a rendszer. A bank belső IT apparátusa elkeseredetten küzd a döntés ellen, mert tudja, hogy irreális az ígéret. A külső cég vezetője a döntéshozó értekezleten fölényes gúnnyal utasítja vissza a banki IT szervezet "akadékoskodó" vezetőjét. Végül a külső cég vállalásában a projekt egy negyede megvalósul egy helyett négy év alatt.

3. Az integráció és a versenyeztetés ellentmondása

Míg az ipari országok tapasztalata egyértelműen az integrált – sokoldalúan, kiegyensúlyozottan, harmonikusan, egységesen fejlesztett – rendszerek fölényét igazolja, a magyar bankokban jellemző az egymástól függetlenül működő fejlesztő csoportok "versenyeztetése". Vannak nagy, országos hálózattal rendelkező bankok, melyek több, egymástól, s a banktól is független Kft.-t alkalmaznak, egyeseket maguk alapítanak, s persze saját fejlesztő apparátust is működtetnek, máshol függetlenített vezérigazgatói tanácsadói csoportot is  fenntartanak, "nehogy periférikus szakmai érdekek tévútra vezessék a fejlesztést".

Az aggodalom, melynek gyökere a bizalmatlanság, jogos. A magyarországi banki IT eddigi fejlődése – a korábban említett, gyors felhalmozódási folyamat ellenére is – még nem termelte ki azt a szakmai és menedzseri réteget, mely – akár tömegében, akár az egyes személyeket illetően – garanciája lehetne a biztos tájékozódásnak, mely a "bizalmat már kiérdemelte". A verseny elve alapján létrehozott szakmai sokszögek azután "teljesítik is a várakozást", bebizonyítják, hogy a periférikus szakmai érdekek valós veszélyt jelentenek, hiszen valóban egymásnak ellentmondó koncepciók jönnek létre, valóban ádáz presztízsharcok indulnak, s az elmérgesedett helyzetben az egységesítési kísérletek is kudarcba fulladnak. Lehet ilyen helyzetben bármelyik versenyzőnek kizárólagos bizalmat szavazni? 

Az eredmény kudarc: legalábbis hosszú távon bizonyosan. A konkurens koncepciók, eltérő hardver/szoftver eszközök alapján fejlesztett részrendszerek bevezetésük után megkezdik önálló életüket, speciális módon alkalmazkodnak a folyamatosan változó igényekhez, s később már nem hangolhatók össze: a banknak van egy újabb "súlyos öröksége".

Az ellentmondás valós, és nem kívánjuk azt a benyomást kelteni, hogy tehetségtelen, esetleg felelőtlen emberek által kiváltott, szervezeti működési zavarról lenne szó.

4.  A rövid- és hosszú távú érdekek ellentmondása

A banki IT fejlesztés idő- és költségigényes, infrastruktúrát hoz létre, tehát hosszú távon ható folyamat.

A jól megtervezett fejlesztés nyomán a bank bővítheti tevékenységét, s beindíthatja a gyors fejlődés pozitív visszacsatolású folyamatát, ellenkező esetben a fejlesztésre fordított milliók csak a veszteségeket növelik. Mindez azonban csak évek múltán realizálódik. Annak érdekében, hogy néhány év múlva ne veszteségeket kelljen számba venni, a fejlesztéseket hosszú távra tekintve, megalapozottan kell végrehajtani. Ez pedig rengeteg időt és emberi ráfordítást igényel.

A bankokkal szemben támasztott követelmények – különösen a rendszerváltás évtizedében tapasztalható – gyors változása azonban lépten-nyomon rövid-távú megoldásokat követel: "mindegy, hogy hogyan és mit, csak gyorsan". 

A működő rendszerek konzervatívabbak, mint az őket létrehozók, keményen ellenállnak a változtatási szándéknak. A rendszerek e konzervativizmusa és bonyolultsága különös viszonyban van egymással. A jóval bonyolultabb, moduláris felépítésű, paraméterezhető rendszerek széles sávban könnyedén alkalmazkodnak a különböző igényekhez, s csak egy kritikus határ után "keményednek meg", az egyszerű, a konkrét napi igény alapján fejlesztett célrendszerek pedig könnyen módosíthatók kezdetben, s egyre nehézkesebbek, majd kezelhetetlenek lesznek. A sürgős feladatok kielégítésének rövid-távú igénye, és a hosszabb távra tekintő optimalizálás igénye egymásnak ellentmond.

Az IT felelősen gondolkodó vezetője kutyaszorítóba kerül:

- ha enged a sürgetésnek, hosszú távon bizonyosan tönkre teszi a rendszert, s a mostani néhány hónapos nyereség utána hosszú éveken keresztül garantálja a gondot, az elhúzódó kudarc és a vele természetszerűleg együtt járó folyamatos bizalomvesztés az övé lesz,

- ha nem enged, akár egzisztenciálisan is kockáztat, de mindenképpen bizalomvesztéssel kell számolnia.

Súlyosbítja mindezt, hogy a magyar bankok – gazdálkodásuk peremfeltételeinek gyors változása közepette – nem rendelkeznek eléggé stabil, eléggé kipróbált, tehát eléggé hosszú távú üzletpolitikával. így aztán az óceánjáró nehézkességével zuhatag-lovaglást kell megkísérelni.

5. A felszíni ismeretek és a mélystruktúrák ellentmondása.

Az IT fejlesztés egyik saroktörvénye, hogy csak az a fejlesztés számíthat sikerre, amely messzemenően figyelembe veszi a felhasználói szempontokat. Ezt a törvényt mind az IT munkatársak mind a felhasználók jól tudják, mégis ezen a területen koncentrálódnak a konfliktusok. E konfliktusok mögött a felhasználóktól megszerezhető ismeretek és a rendszer megtervezéséhez szükséges ismeretek különbözőségének ellentmondása áll. Ennek több oka van.

Az egyik ok a felhasználók ismereteinek sajátos volta. Ha két különböző bankban működő pénztárak tevékenységét részleteiben megvizsgáljuk, a rengeteg azonosság mellett különbségeket fogunk találni. Pl. az egyik bank pénztárosa minden pénztári tételnél címletjegyzéket készít, a másik nem. A különbségek egy része karakterisztikus, más része csak esetlegességekre vezethető vissza; valamikor, valamiért a pénztáros így szokta meg, s azóta így csinálja, talán már nem is emlékszik, miért.

Az IT fejlesztő nem állhat meg ezen a szinten. Neki a dolgok miértjét is tudnia kell. Rendszerint ebben a pillanatban áll be a rövidzár a felhasználó és az IT fejlesztő között. A fejlesztőnek többet kell tudnia, le kell hatolnia a mélystruktúrákig, s olyan kérdéseket tesz fel, amilyeneket a felhasználó nem akar hallani. A fejlesztőnek mégis tovább kell lépnie, a hiányzó információt tehát megszerzi máshol, vagy kitalálja saját kútfejéből. Amikor visszatér a felhasználóhoz, s elmondja, milyennek képzeli ô a rendszert, a felhasználó ideges lesz, mert nem pontosan azt kapja, amire számít, de nem is tudja megítélni, hogy ami "más", az jó-e vagy rossz.

Hasonlóan zajlik a felhasználó-fejlesztő párbeszéd szoftvercsomagok kiválasztása kapcsán is. A fejlesztő szeretné összeszedni a felhasználói követelményeket, de azok a követelmények, amelyeket a felhasználó megfogalmaz, szinte sohasem elegendők ahhoz, hogy megfelelő szint követelmény jegyzék készüljön.

A tipikus dilemma: ha a fejlesztő önkényesen hoz döntést, akkor azzal nyeri el a felhasználó ellenszenvét, ha nem hoz döntést, s csak vár a felhasználóra (aki nem tud dönteni) akkor áll a fejlesztés. A bizalomvesztés bizonyosan a fejlesztőé.

6. A központi és a hálózati érdekek ellentmondása

A bank vezetése első sorban a bank egészének gazdálkodását figyeli, s megkívánja, hogy napi aktualitású, összesített gazdálkodási adatok álljanak rendelkezésre, s kevéssé érdeklődik az egyes ügyfelek napi tranzakciói iránt.

Az ügyfélszolgálat számára ezzel szemben az analitikus szemlélet a meghatározó, tranzakció mélységig kell kordában tartani, ellenőrizni a folyamatokat.

A szintetikus ill. analitikus szemlélet nyilvánvalóan ugyanannak a dolognak két oldala, de e kettő összehangolt kezelése csak kicsi bankoknál megy könnyen. Nagy, országos hálózattal rendelkező banknál a központ és a hálózat egymástól eltérő igényeinek azonosan magas szintű kielégítése ma szinte lehetetlen. Felmerül tehát a prioritás kérdése, mikor, melyik fontosabb?

A központi és fiókhálózati érdekek ellentmondása jellegzetesen közép-európai jelenség, melynek hátterében egyrészt az adatátviteli infrastruktúra alacsony színvonala áll, másrészt az országos adatbázisok feldolgozására képes nagy teljesítményű számítógépek hiánya. Mindkét probléma a már említett COCOM hatására vezethető vissza.

Példa. Az egyik nagy, országos hálózattal rendelkező bank kezdetben – az akkor rendelkezésre álló számítástechnikai eszközöknek megfelelően – központosított számlavezető rendszereket fejlesztett. Ezek jelentős előrelépést jelentettek a belső információ ellátás terén, de semmi javulást nem eredményeztek a fiókok manuális munkájának könnyítésében. A fiókhálózat nyomására a fejlesztés a fióki rendszerek irányába fordult, annál is inkább, mivel az újabb technológia ezt tette lehetővé. Néhány év múlva azonban ismét a központi vezetői információ szolgáltatás viszonylagosan alacsony színvonala lett a kritika tárgya, a figyelem ismét a központi gépesítés felé fordult.

Egészen addig, amíg a nagy bankok országos informatikai infrastruktúrája ki nem épül (ez még éveket fog igényelni), az IT emberei biztosan számíthatnak az egyenlőtlen fejlődésből származó elégedetlenségre, azaz a folyamatos bizalomvesztésre.

7. Az intézmény és a személy érdekellentéte

A bank, mint intézmény érdeke a sokoldalúan optimalizált, kiegyensúlyozott fejlesztés, mely az üzleti érdekeket, lehetőségeket, a rendelkezésre álló erőforrásokat úgy veszi figyelembe, hogy a fejlesztések összhozama a teljes bank számára maximális legyen. A bank egyes szervezeti egységeinek, és ami ehhez nagyon közel áll, ezen szervezeti egységek vezetőnek, munkatársainak érdeke ettől az érdektől gyakran eltér. A parciális érdekek az őket érvényesíteni kívánó személy karakterétől függően különböző csatornákon törhetnek elő, ennek megfelelően maga az ellentmondás is többrétegű.

7.1. Jóindulatú változat

Az IT szervezet helyzeténél fogva mérlegel, rangsorol, bonyolult kompromisszumot köt különböző alternatívák között, részben segíti létrehozni az intézményi fejlesztési stratégiát, részben megvalósításán dolgozik. Lehetetlen azonban létrehozni olyan részletes IT fejlesztési stratégiát és tervet, mely minden részkérdést intézményi szinten konszenzussal rögzít, s egyébként sem zárható ki az IT fejlesztés folyamatából a különböző felhasználói érdekek  folyamatos ütköztetése.

A funkcionális szervezet ambiciózus, tehetséges egyéniségei ugyanakkor egyéni elképzelésekkel rendelkeznek, melyeket szeretnének megvalósítani/megvalósíttatni. Hangadó voltuknál fogva ugyanezek az emberek azok, akik a legjobb eséllyel tudják a bizalmi viszonyokat – döntően informális módon – befolyásolni.

Nehezen védhető helyzetbe kerül az IT szervezet ill. vezetője, ha funkcióját komolyan véve tiltakozik egy, a bank vezetése által elfogadott stratégiába nem illeszkedő, esetleg annak ellentmondó kezdeményezés ellen, vagy esetleg meg is gátolja megvalósítását. Hamar megkapja a globális minősítést: "nem szolgálja a bank/hálózat/felhasználók érdekét". E minősítés valódi "súlyát" nem csökkenti az sem, ha esetleg a bankban utasítás teszi az IT vezetőjének felelősségévé a bankban használt informatikai eszközök kiválasztását. Lehet, hogy akkor árt magának a legtöbbet, ha pontosan az előírás szerint jár el. Hasonló az eredmény, ha egy egyébként jó kezdeményezést azért nem valósít meg, mert a meglévő erőforrásokat nem tudja átcsoportosítani.

7.2. Rosszindulatú változat

Ma Magyarországon a bankszféra köztudottan egyike a kevés fizetőképes ágazatnak, elmaradott infrastruktúrájának gyors fejlesztésére hatalmas összegek állnak rendelkezésre. Tudják ezt a potenciális szállítók is, és természetesen mindent megtesznek a zsíros üzlet megszerzése érdekében. A legkisebb ellenállás az IT kérdésekben járatlan funkcionális vezetőknél várható. E kezdeményezések akkor válhatnak veszélyessé, ha kevéssé jellemes banki vezetőkkel találkoznak, akik a magas profiton osztozkodás reményében vállalják az ügy bankon belüli elfogadtatását. Még rosszabb, ha az illető banki vezető saját költségkerettel is gazdálkodhat. Mivel az eredeti szándék leleplezhetetlen, az IT vezetője bizton számíthat az újabb bizalom vesztésre, hiszen "ellensége a pozitív kezdeményezéseknek", korrupt kollégája pedig tetszeleghet annak az újító szellemű menedzsernek a szerepében, aki az illetékes terület értetlensége dacára is megvalósítja szándékát.

Példa. Egy nagy bank IT vezetője egy napon tájékoztatást kap arra vonatkozóan, hogy vezérigazgató helyettesi szinten szerződést írtak alá egy értékpapír nyilvántartó rendszernek a fiókhálózatban való elterjesztésére vonatkozóan. A szoftvert egy vidéki bankfiók vezetője "rendelte meg" egy helyi, három főt foglalkoztató Kft.-től. Korábban e feladat megoldásáról, mint magas prioritással rendelkező ügyről, nem esett szó. Ebben a helyzetben – utólag – már természetesen hiába kéri, hogy a bank vezetősége legalább vizsgálja meg azt a másik két megoldási verziót, amelyek korábban ajánlati formában az IT szervezethez eljutottak. A rendszer gyakorlati bevezetése természetesen az IT szervezet feladata lesz.

A példa tipikus történetet mutat:

- egy egyébként esélytelen vállalkozó megkörnyékez egy korlátozott, de elegendő saját büdzsével rendelkező helyi vezetőt,

- a helyi vezető saját hatáskörben megrendeli és kifizeti a fejlesztést,

- mindketten gondoskodnak arról, hogy a szakmai szervezet a fejleményekről ne vegyen tudomást,

- a helyi vezető saját informális csatornáin eléri a legfelső vezetés támogatását,

- a döntésnél az esetleges ellenérvek el sem hangozhatnak,

- a döntés rendkívül kedvező a vállalkozó számára,

- az IT szervezet – hacsak maga is egy hasonló összeesküvést titokban elő nem készített – vert helyzetben van, nem tud gyors alternatívát felajánlani.

A jó- ill. rosszindulatú változat ezután már csak abban különbözik egymástól, hogy a helyi vezető megelégedett-e az "újító szellemű, vállalkozásra, kezdeményezésre kész bankvezető" megtisztelő címével, vagy részesedett is a vállalkozó hasznából.

E példa jelzi azt is, hogy az eset idején a bizalomvesztés már előrehaladott, fejlesztési döntésekben már nem is kívánják figyelembe venni az IT szervezet/vezető véleményét. Ha a bizalom még létezett volna, vitára került volna sor, ahol az IT vezetője számon kérhette volna legalábbis a meglévő banki rendszerekhez történő illesztés követelményét (s valószínű még egy sor egyéb úri huncutságot), s ami a bizalomból még megmaradt, ekkor tékozolta volna el.

7.3. Az erőforrások feletti hatalom

A banki IT fejlesztések nem valósulhatnak meg a banki szakemberek intenzív részvétele nélkül. Egy-egy fejlesztés gyakran egy egész sor szakterület bevonását feltételezi. Pl. egy kártya-kibocsátási projekt esetében nélkülözhetetlen a folyószámla osztály, a számviteli, a bankbiztonsági, a propaganda, a jogi szakterületek együttműködése. A termék megvalósulása sajátos érdekeiket nem érinti, az is előfordulhat, hogy az más, esetleg újonnan felállítandó szervezet érdekét képezi.

A projektek sikere érdekében a legképzettebb, legtapasztaltabb szakembereket kell bevonni. Ugyanezek a szakemberek kulcsfigurák saját területükön is, s vezetőjük nem szívesen mond le munkájukról több hónapra, nem is beszélve arról a veszélyről, hogy hosszabb távollét után a szakember esetleg nem is akar régi szervezetéhez visszamenni.

Példa. Egy bank új üzletági IT rendszert vezet be. A manuális ügyintézést egy szoftvercsomag implementációjával automatizálják. Az üzletági vezető személyében is elzárkózik a projektben való részvételtől, de munkatársait is folyamatosan távol tartja a fejlesztéstől a /valóban/ magas leterheltségre hivatkozással. Így lehetetlen megtervezni az ügyviteli módosításokat, nincs aki döntsön a projekt kapcsán felvetődött üzleti kérdésekben. Ezen a helyzeten az illetékes vezérigazgató helyettes sem tud változtatni. A bankban az üzletág még viszonylag új, a könyvelési osztályon még nincs megfelelő speciális szakismeret. A projekt vezetője tartósan nem tudja megszerezni a számára alapvető fontosságú számla információkat, a könyvelés a sürgetést a túl sok munkára való hivatkozással hárítja el. A projekt befejezése egyre távolabb kerül, majd a rendszer bevezetésére – még mindig nem eléggé kiérlelt állapotban – felső utasításra sor kerül. A bevezetés végül is sikeres, de az első napok botrányos jeleneteiért – a „nem megfelelő projekt menedzsment” miatt –  az IT vezetőjét marasztalják el.

A példa az erőforrások birtoklásával kapcsolatos intézményi és csoport érdekek ellentmondásának működésmódját szemlélteti, de felismerhető, hogy az érintett szakterületek a témával kapcsolatos elégtelen szakismeretüket hogyan álcázzák a túlterhelésre való hivatkozással, ugyanezen érvet hogyan használják fel a felső vezetés részéről tapasztalható nyomás semlegesítésére, de felismerhető az is, hogy a fejlesztés iránti elkötelezettség széles körben elégtelen.

8. Az "a botrány hangos, az eredmény csendes" ellentmondása

Az informatika egyik népszerű alaptörvénye, hogy hibátlan program nincs. A valóságban a bonyolult rendszerek belső ellentmondásai a fejlesztés és tesztelés fázisaiban nem kerülnek maradéktalanul napvilágra, egy részükre a használat során derül fény. Ez a berázódás korábban már említett időszaka, mely keserves konfliktusokat okoz a felhasználóknak: váratlan üzemszüneteket, időrabló és idegőrlő hibakeresést, helyreállítási procedúrákat, mindezt túlórában, hétvégén, éjszaka. Ilyenkor hangos a botrány, s annál hangosabb, mennél több helyről jönnek vészjelzések.

A berázódás után néhány hónappal viszont csend van.

Az a bizalom azonban, mely a botrány zajában elveszett, a későbbi, termékeny csendben csak részben termelődik újra. Ennek az ellentmondásnak az alapja lélektani természetű: mindannyian könnyen és gyorsan megszokjuk a jót, de még rövid időre is nagyon nehezen viseljük el a rosszat.

Példa. Egy nagy bank összes fiókjában ugyanazon a napon kellett bevezetni egy új rendszert. Az IT szervezet több hónapos, koncentrált erőfeszítéssel, sok száz ügyintéző kiképzésével, mint egy bonyolult hadműveletet készítette elő az "X" napot.

A lélektani előkészítéshez az is hozzátartozott, hogy mindenkinek elmondták, az indulás nehéz lesz. Az indulás ugyan jól sikerült, a fiókok töredékében jelentkezett csak probléma, a botrány mégis hangos volt. Az ilyenkor törvényszerűen hisztérikus légkörben újabb hibák csúsztak a rendszerbe, s a berázódás hónapokig elhúzódott. 

Egy évvel később ez a rendszer a bank információs rendszerének legmegbízhatóbb eleme, fontos tartóoszlopa lett.

9. Az időfaktor

Az előző ellentmondás belső struktúrája az időfaktor bevonásával vizsgálható tovább.

Egy új rendszer bevezetésével kapcsolatos megrázkódtatások mennyisége elvileg fordítottan arányos a rendszer előkészítésére fordított energiákkal, adott humán kapacitások esetén a ráfordított idővel. Ebből az következik, hogy hosszabb időt kell hagyni az előkészítésre. A valós nagyságrendek azonban elgondolkoztatók. Egy 1 éves fejlesztés esetén kb. fél éves nagyságrendű az a plusz időráfordítás, amely a bevezetéskor felmerülő gondok mennyiségét felezi, újabb hónapok negyedelik stb. Ha azonban azt tekintjük, mennyi idő kell ahhoz, hogy a felhasználó apparátus számára a bevezetés múló gondjai ne okozzanak nagy megrázkódtatást (mi a megrázkódtatás mértékegysége ?), elviselhetetlenül hosszú idő jön ki.

Egy másik motívum tovább színezi a kérdést. A rendszer egy adott készültségi fokán túl a "laboratóriumi" tesztelés egyre kevésbé hatékony az élő környezetben történő teszteléshez képest. Különösen így van ez a bankokban, ahol az ügyfélforgalom egy nehezen kiszámítható tényezőt, a humán tényezőt is becsempészi. Egy adott komplexitási szint felett nehezen tervezhetők meg azok az anomáliák, melyeket az ügyfelek egyéni problémái okoznak. Van tehát egy olyan határérték, melynek elérésével a rendszert ki kell vinni az életbe, hogy a még meglévő rejtett hibái gyorsabban kerülhessenek napfényre. Az a konfliktus mennyiség azonban, amelyet a rendszer ebben a stádiumában a felhasználókra zúdít, rendszerint még mindig a nehezen elviselhető nagyságrendben van.

Összefoglalva tehát az időfaktor figyelembevétele azt eredményezi, hogy a rendszereket "idő előtt" mélyvízbe dobjuk, s ezáltal a minimálisnál lényegesen több konfliktust gerjesztünk. A bizalmat illetően ez egy törvényszerű és jelentős veszteségforrás, mely alapvetően hozzájárul, hogy pozitív szaldójú folyamat ne indulhasson el.

10. Az integráltság és az egyszerűség ellentmondása

Bár az integrált rendszerek általában magasrendű általánosítás és rengeteg tapasztalat termékei, nehezen vetekednek egyszerűség, közérthetőség, felhasználó közeliség terén azokkal a rendszerekkel, amelyek a hagyományos-manuális munkafolyamatok másolásával keletkeztek. Az IT hosszú távú fejlesztése szempontjából ez utóbbiak a legrosszabbak. A felhasználónak azonban felcsillan a szeme, ha ilyen rendszerrel találkozik. Ebben a pillanatban a bonyodalmak teljes spektrumát ismerő IT szakemberek ügyetlennek, tehetségtelennek, akadékoskodónak tűnnek, "lassan" dolgoznak, bosszantóan sok problémát vetnek fel, ezzel szemben ügyesek, gyorsak, tehetségesek, hatékonyak azok az ajánlkozók, akik tudatosan korlátozott teljesítményű és igényű rendszereikkel bizalmat tudnak kelteni.

Ez az ellentmondás más megközelítésben az intellektuálisan magasrendű termék és az őt felhasználó réteg alacsony szakmai színvonalának ellentmondása. Nem kell rosszindulatot feltételezni arról a banki ügyintézőről, aki szűk körű ismeretei által meghatározott gondolkodásával képtelen elsajátítani egy jóval nagyobb távlatokat megnyitó, de egyúttal jóval bonyolultabb, esetenként elvontabb rendszert, s komplikáltnak, nehézkesnek, idegennek, egyszerűen rossznak minősíti azt.

11. Egyéb parciális érdekek

Komolyabb tudományos elemzés tárhatná fel, milyen egyéb parciális érdekek kaphatnak szerepet az IT fejlesztések befogadásával vagy ellenzésével kapcsolatban. Az alábbiakban bemutatunk néhányat, pusztán az illusztráció kedvéért.

11.1. A hatalom megtartásának érdeke

Egy szervezet, s vezetője számára természetes ambíció a külső befolyásolási lehetőségek minimalizálására való törekvés. Az IT ezekből a szervezetekből nézve a nem kívánatos külső beavatkozások mintapéldája. "Valamit másképpen kell csinálnunk, mint mostanáig, s ráadásul mások mondják meg, hogyan." Nota bene: az IT szervezet is ellenáll azoknak az esetleges, kívülről megjelenő törekvéseknek, melyek belső dolgaik (pl. a projektirányítás formalizálása, szoftverkönyvtárak karbantartási rendje, teljesítmény elszámolási rendszer bevezetése) megváltoztatását célozzák. A funkcionális banki szervezetekben a külső befolyás minimalizálásának egyik lehetősége az IT feladatok saját hatáskörbe vonása.

Példa. Az egyik bankban a fiókvezetők egy csoportja elhatározta, hogy az IT szervezet által kidolgozott rendszer konkurenciájaként saját rendszert készíttet. A külön út vállalásának egyik fontos oka az volt, hogy az IT szervezet által fejlesztett rendszer a napi zárásba beépített kényszerítő mechanizmusokkal megakadályozta, hogy egyik napról a másikra feldolgozatlan tranzakciók mehessenek át, éppen azért, hogy lehetetlenné tegye a korábbi hatalmas, gyakran több hónapos restancia tömegek újraképződését. Az „összeesküvő” szervezetek ezt a "kényelmetlenséget" nem akarták vállalni. Titkos szerződéseket kötöttek egy külső fejlesztő céggel, s az akció csak akkor került nyilvánosságra, amikor a fejlesztés már kb. 60 %-os készültségi fokon állott.

A bank vezetése korlátokkal ugyan, de szabad utat adott a külső fejlesztésnek. E tanulmánynak nem témája, milyen gazdasági hátrányok adódtak a bank számára ebből a döntésből, és hogy milyen alternatív döntési lehetőségek voltak. A bizalom kérdését illetően azonban két fontos elemet vehetünk észre. Egyrészt az összeesküvők előtt az IT szervezetbe vetett bizalom már nyilvánvalóan megrendült, másrészt az, hogy egy, az IT fejlesztés legfontosabb elveit látványosan sutba vető partizán akció legalitást kaphatott, a még megmaradt bizalmat is alaposan megnyirbálta.

E példa sajátos tanulsága éppen az, hogy a bizalom hiányára visszavezethetô kényszerdöntések további bizalomvesztést eredményeznek, s ezzel önmagát erôsítô folyamatot hoznak létre.

11.2. Félelem a létszámelvonástól

Bár nemzetközi statisztikák bizonyítják, hogy IT rendszerek bevezetése banki környezetben sehol sem eredményezett létszámcsökkenést (legfeljebb fokozatos helyi átcsoportosítást, ha a felszabaduló emberi kapacitás más területeken, pl. ügyfélszolgálatnál jobban hasznosul), sok helyen él az a félelem, hogy a rendszer bevezetése után létszámcsökkentésre fog sor kerülni. A rendszert befogadó szervezet vezetője tehát egyenesen abban érdekelt, hogy a rendszerről mennél rosszabb képet fessen felettesei előtt.

Így még a valóban értékes eredmények is bizalom vesztéshez vezetnek.

Példa. Egy bankfiókban, mely hosszú időkön keresztül túlzsúfoltságáról volt hírhedt, új számítógépes rendszert vezettek be. A fiók vezetője és személyzete a várhatónál jobb hozzáállással készítette elő az átállást, s az jól is sikerült. Az átállás miatti egy hetes zárva tartás után a normális napi forgalom háromszorosa zúdult a fiókra, és azt a számítógépes rendszer zökkenőkkel ugyan, de jól levezette, sőt a zárást futtató két munkatárs kivételével aznap már senkinek nem kellett túlóráznia. A korábban mindennapos botrányok helyén egy európai színvonalú bankfiók jött létre. Annál nagyobb volt a fejlesztők meglepetése, amikor néhány héttel később éles kirohanások keretében számtalan kritika érte a rendszert. Miután a rendszer még a berázódás fázisában volt, a jogos kritika senkit sem lepett volna meg. Annál meglepőbb volt a támadások élessége és hisztérikus jellege, mely jelentősen rontotta a rendszer további terjesztésének esélyeit, miután az egész hálózatban elterjedt, mennyire "rossz a rendszer". 

Évekkel később egy elszólás fényt derített az esetre: a bank egy vezetője valahol megemlítette, hogy célszerű lenne a gépesített fiókokból munkaerőt átcsoportosítani a még manuálisan dolgozókhoz.

Talán nem kell megismételni, hogy azt a bizalmat, amit az igazságtalan támadások leromboltak, később már nem lehetett helyreállítani.

11.3. Félelem a helyi gondok nyilvánosságra kerülésétől

Egy új rendszer bevezetése során sok minden kiderül a befogadó szervezetről. Vezetőik tudják a legjobban, hogy mi az, ami kiderülhet, s mindent megtesznek, hogy titkaik megmaradjanak.

Mi derülhet ki ? Csak néhány példa a gyűjteményből:

- a számlakartonok nincsenek rendben, a cserépkályha mögé lecsúsztak, hetek óta az ügyintézô uzsonnás fiókjában vannak,

- restanciák vannak az ügyintézésben (a szerző ismeretei szerinti rekord 13 év),

- évek óta nem egyezik a könyvelés, de az ellenőrzés előtt még mindig sikerült  eltussolni az eltérést,

- már régóta nem tartják be a vonatkozó ügyrendi utasításokat stb.

E szempont súlya jobban értékelhető lesz, ha meggondoljuk, az IT rendszerek bevezetése azt eredményezi, hogy a bank szervezeti egységeiből a korábban csakis belső használatú információ hatalmas tömegben kerül kívülre, s ez az információ tömeg az IT apparátus számára hozzáférhető. A banki szervezetek kívülről történő ellenőrizhetősége is jelentősen megnő.   

Ez a félelem úgy hat az IT fejlesztések befogadására, hogy a szervezet vezetője megkísérli "családon belül" lebonyolítani az eseményeket, az IT szervezet távoltartásával. Ez az ambíció kedvez a külsőô IT cégeknek, mert velük szemben a fenti félelmek kevésbé jelennek meg.

A cél tehát az, hogy ne a bank IT termékét alkalmazzák, ha mégis azt kell, az IT szervezet ne vegyen részt a telepítésben, az oktatást ne az IT szervezet szakemberei tartsák stb. Ezek a jelenségek rontják az együttműködés lehetőségét az IT és a felhasználói szervezetek között, és ily módon hozzájárulnak az IT szervezetről kialakult kép romlásához.

11.4. Presztízs

A korszerű technológiának a felhasználóra gyakorolt vonzóereje jórészt abban a presztízsben van, melyet tulajdonosának kölcsönöz. Ez a presztízs játszhat pozitív szerepet is, de negatív hatása is lehet. A presztízshez való tipikusan szubjektív viszony jellegzetesen különböző táborba sodorja a felhasználókat és az IT szakembereket.

Példa. Egy bank pénzforgalmi területének vezetője "beleszeretett" egy szoftver termékbe, mely színes képernyőn be tudta mutatni a különböző valuták bankjegyeit, azok valódiságának vagy hamisított voltának jegyeit. Álláspontja szerint a program hozzájárulhat ahhoz, hogy a bankjegyek hamisításának egyre szélesebb körű terjedése miatt a pénztárosokra nehezedő teher csökkenjen, ezért elhatározta, hogy a szoftvert a pénztárakban alkalmazni fogják.

Az IT illetékese szerint azonban a program nem elégítette ki az alapvető követelményeket:

- nem könnyítette meg a pénzzel való munkát (nem lehet bankjegyek tucatjait egymás utáni képernyők sorával egyenként ellenőrizni),

- nem csökkentette a pénztáros kockázatát,

- nem biztosította a teljes körű, katalógusszerű információt,

- így nem is járulhatott hozzá, hogy a hamis bankjegyek befogadásából eredő veszteség csökkenésével a beruházás megtérüljön. Az, hogy egy pénztári szoftver tetszetősen és szép színekkel bankjegyeket ábrázoló képernyőket tud rajzolni, szükséges, de nem elegendő indok az alkalmazásra.

A bank természetesen megvásárolta a szoftvert, anélkül, hogy a felmerült hiányosságok megszüntetése érdekében bármilyen lépés történt volna, az "akadékoskodó" IT felelős iránti bizalom pedig ismét csökkent.

A példa plasztikusan mutatja a felhasználói és fejlesztői gondolkozásmód különbségét. A felhasználót nyomasztják saját szakterületének gondjai (túl sok a hamis bankjegy), keres valamilyen megoldást, s talál is valamit. A technológia részletes ismerete nélkül azonban nem látja meg a megtalált "megoldásnak" sem elvi, sem praktikus hátrányait (vagy akár előnyeit). Döntése saját szakterülete ismereteinek megfelelően szubjektív. A másik oldalon a technológusnak, aki napjait színes képernyők és intelligens programok között tölti, nem jelent élményt egy külföldi bankjegy színes képe a képernyőn. Tőle azt várják el, hogy az IT számára rendelkezésre álló erőforrásokkal jó gazda módra gazdálkodjon. Az ô álláspontját nem befolyásolhatja a presztízs, a tartalom nélküli csillogás, pusztán a megoldás szakmai értéke, racionalitása, gazdasági haszna motiválhatja véleményét. S így következhet be azután, hogy, ha felelősséggel akarja gyakorolni funkcióját, szembe kerül "uralkodójával", a felhasználóval. A korábbiakban láttuk, hogy ezek a konfliktusok hogyan járulnak hozzá a bizalomvesztéshez.

11.5. Emberi erőforrás hiány

Új IT megoldások bevezetése a felhasználóval szemben is többlet erőforrás igényt támaszt. Ennek két tipikus területe van:

- a felhasználói szervezet munkatársainak kiképzésen kell részt venniük,

- az átállási periódusban speciális tevékenységeket (számlakarton előkészítés, adatrögzítés, egyeztetések, speciális adatok összegyűjtése stb.) kell végrehajtaniuk.

A pótlólagos kapacitásokat a lehetőségekhez képest külső forrásból kell biztosítani, de a felhasználó szervezet hozzájárulása teljesen nem  nélkülözhető.

A felhasználó szervezetek a legritkább esetben vannak az emberi erőforrásoknak oly mértékben bővében, hogy a többlet igényeket konfliktusok nélkül ki tudják elégíteni.

Különösen az oktatás elmulasztása jellemző. A szervezetek vezetői – szorongatott helyzetükben, hiszen a napi munkának is tovább kell mennie – nem minden munkatársukat küldik el, s inkább azokat, akik nem kulcsemberek. Ha az oktatást több turnusban szervezik meg, hogy mindenki részt vehessen, akkor az oktatás és a tanultak felhasználása kerülhet időben túl messzire egymástól.

Az oktatás elmulasztásából származó hiányosságokat a munkatársak nem mindig érzik, s az elkövetett emberi hibák miatti rendellenes működést a rendszer terhére írják, "rossz a rendszer" mondják, és főnökeik ezt el is hiszik nekik. Valójában sokszor nem is könnyű megítélni, hogy a rendellenes működés végső oka kezelői hiba-e, vagy programhiba (abban az értelemben, hogy a rendszernek észre kellett volna vennie a hibás kezelést), de szempontunkból a  kérdés lényege nem is ez. A felhasználó egyszerű állítását: "rossz a rendszer, rossz az eredmény, rosszul számol a gép" mindenki azonnal megérti, a szakember magyarázata pedig, hogy mi miért történt a gépben úgy, ahogy történt, nem érdekel senkit.

Végeredményben nagyon sok esetben a felhasználó által elkövetett hiba, a felhasználó felületessége, felelőtlensége az IT munkatársak iránti bizalmat erodálja tovább.

11.6. Az információ tulajdon kérdése

Az IT fejlesztés folyamata érdekes változást hoz az ügyviteli folyamatokkal kapcsolatos információ tulajdonlását illetően. Kialakul és egyre jobban terebélyesedik az ügyviteli információnak egy olyan köre, mely technológiai fogantatású és melyet így elsősorban a technológusok birtokolnak. Megszűnik tehát az "elvi-szabályozó" szervezeti egységeknek az az információ monopóliumuk, ami korábban természetes módon létezett. A rendszer működésével kapcsolatos információ egyes esetekben döntő mértékben a technológusoknál koncentrálódhat, akár olyan mértékig is, hogy a rendszer módosításával, továbbfejlesztésével kapcsolatos további döntések átcsúsznak a technológusok asztalára. Más oldalról azonban nyilvánvaló, hogy üzleti döntéseket technológusok nem hozhatnak, a hagyományos szabályozó osztály bevonása nélkülözhetetlen, ők azonban már nem uralják témát.

Mennél előrehaladottabb ez a folyamat, annál tudatosabb erőfeszítéseket igényel a kétféle információ együttes felhasználásának koordinálása. A koordinációs zavarok egy része az IT rendszerek rendellenes működésében fog realizálódni, de nem elhanyagolható a bankon belüli stratégiai információ birtoklásáért folytatott harc más következménye sem, pl. az, hogy az elvi szakosztályok mereven elzárkóznak az IT terület felöl érkező kezdeményezések befogadása elől, mert minden ilyen lépés az információ birtoklási pozíciójuk további romlásához vezethet.

Példa. Egy bank elektronikus számlavezető rendszere hosszú évek fejlődése nyomán egyre bonyolultabb lett, egyúttal az igények változása nyomán továbbfejlesztése egyre sürgetőbbé vált. Az üzletági szakosztály egyre kevésbé tudta átlátni a fejlesztés lehetőségeit, s a bank vezetése részéről egyre határozottabban megfogalmazódó továbbfejlesztési törekvések elől hosszú időn keresztül kitért. Ezzel párhuzamosan egyre több kritika fogalmazódott meg a működő rendszerrel szemben, s úgy tűnt, mintha az IT szervezet tehetetlensége húzódna meg a háttérben. Ebben a helyzetben az IT szervezet saját korszerűsítési elképzeléseit, mely nemcsak technológiai, hanem új üzleti elemeket is tartalmazott, a bank vezetősége elé terjesztette. A szakosztály a kezdeményezést nem támogatta, s így az nem érvényesülhetett. Fél év elteltével a szakosztály előterjesztette lényegében ugyanazt a javaslatot, sikerrel.

A huzavona rossz fényt vetett mind az üzleti, mind az IT szervezetre. Bizalom romboló hatása az IT szervezetet illetően azért jelentősebb, mert a sok oldalról érkező, s mindig azonos előjelű és így halmozódó hatások egyre jobban azt a meggyőződést sugallják, hogy az IT az a szervezet, ahol a gondok sűrűsödnek, ahol tehát azok gyökere van.

D. Ajánlások

Miután a B. fejezetben részletezett tézisek alapján a bizalom elvesztése törvényszerű, megszerzése lehetetlen, úgy tűnhet, hogy bizalmi problémánknak nem is lehet megoldása. A tanulmány eddigi gondolatmenetéhez hűen ezért meg kell vizsgálnunk, melyek azok az ellentmondások, melyeknek romboló hatása tudatos magatartással csökkenthető. Csak ezen az úton feltételezhető, hogy a bizalom keletkezésének és elvesztésének negatív szaldójú folyamata lassan pozitívba forduljon. Az IT fejlesztések jobb menedzselésével az ellentmondások jó része megszüntethető vagy tompítható, ezáltal a fejlesztési folyamat gördülékenyebbé tehető, s végül a bizalomvesztési folyamat megállítható.

Az alábbiakban összefoglaljuk azokat az ajánlásokat, melyek e pozitív folyamatot elindíthatják.    

1. Magas színvonalú személyzeti munka

Egy nagy norvég bankban az IT szervezet  nyugdíjba vonuló vezetőjének utódját 8 hónapig tartó keresés nyomán jelölték ki, majd előd és utód további 8 hónapot dolgozott együtt annak érdekében, hogy a funkciók átadása komplikáció mentes legyen. Csak a 8 hónapi megnyugtató együttműködés után döntött úgy a bank vezetése, hogy a kijelölt utód megkaphatja a kinevezést.

Az utód kiválasztása kemény szakmai kritériumok alapján történt, egyaránt szerepet kapott a szakmai és vezetői múlt, a hazai és nemzetközi kapcsolatrendszer, a nyelvismeret stb.

Az ily módon lefolytatott kiválasztási eljárás legalább két előnnyel jár, egyrészt biztosítja, hogy a lehető legjobbak egyike kerüljön a fontos pozícióba, másrészt a kiválasztási folyamat igényessége a teljes apparátust tekintve a lehető legmagasabb induló bizalmat eredményezi. Mert amennyire igaz az, hogy a kudarcok bizalmatlanságot szülnek, annyira a bizalom is elősegíti a jövendő sikereket.

A személyzeti munka igényessége ennél többet jelent. Folyamatosan nagy súlyt kell fektetni az IT fejlesztéseken együttműködő partnerek képzésére, kiválasztására, az együttműködés figyelésére és az esetleges konfliktusok kezelésére. Annak tudatában, hogy az IT tartósan konfliktus forrás lesz, minden személyzeti lépést alaposan elő kell készíteni.

A magyar bankokban ez a gondosság manapság nem kifejezetten jellemző. Előfordulhat, hogy egy 350 fős IT szervezet élére olyan vezetőt neveznek ki, aki bankban soha nem dolgozott, soha egy embernek vezetője nem volt, nyelveket nem tud; de előfordulhat az is, hogy egy hónapon belül  kinevezés és leváltás is bekövetkezik ugyanazon pozícióban, hogy az IT igazgatója és két főosztályvezetője banki előismeret nélkül kap kinevezést stb.   

2. Maximális erkölcsi támogatás

Egy nemzetközi hír szakértő szervezet vezető munkatársa az egyik magyar bankban folytatott tájékozódás után (nyilván az ott személyesen szerzett tapasztalatok miatt) írásban is visszatért a szóban általa elmondottakra: azokat a munkatársakat, akik a bank számára fontos korszerűsítési projekteken dolgoznak, kiemelt megbecsülésben kell részesíteni, mind erkölcsileg, mind anyagilag. (E tanulmányban mi az utóbbit szeretnénk hangsúlyozni.) Nemcsak ezeknek a munkatársaknak kell érezniük a bank vezetésének kitüntető bizalmát, de a többieknek is napról napra érzékelniük kell, hogy "azok" fontos feladaton dolgoznak és ezért "nekik" megbecsülés jár. A bank vezetésének ezzel kell kompenzálnia azokat a főképpen lelki terheket, melyeket a reformerek hordoznak.

A támogatás legegyszerűbb formája az elért eredmények nyilvános és hangsúlyos elismerése. Ezen a téren elfogadható az elismerés "túllihegése" is, de ártalmas az aggályos méricskélés, az egyrészrôl-másrészrôl óvatoskodása.

Nem lehetséges egy ügyet úgy támogatni, hogy annak képviselői személyesen ne kapjanak támogatást. Nem lehet az IT fejlesztésének ügyét úgy támogatni, hogy közben az IT szervezet nyilvánosan csak a bűnbak szerepét kaphatja.

3. Intenzív képzés

Az ellentmondások tárgyalásánál láttuk, hogy a felhasználók bankismeretének szintje alapvető jelentőségű a fejlesztésekben való együttműködő képességük tekintetében. (Egy más tanulmány témája ugyan, de meg kell említeni itt is, hogy ugyanez érvényes a fejlesztőkre is.) Nem lehet sikeres az együttműködés ott, ahol a gazdasági igazgató nem tudja, hogyan kell jelenérték számítást csinálni, ahol a nemzetközi ügyek főosztályán senki sem ismeri a határidős ügyleteket, ahol a fôkönyvelő nem tud váltót leszámitolni, ahol a lakossági szolgáltatások tervező osztályán senki se tudja, mi az a POS terminál stb. (a példák valósak, és a megemlített személyek megbecsült vezető munkatársai bankjaiknak). 

Az IT szempontjából a képzés súlypontja nem a bank aktuális gyakorlata, hanem az, ahogyan a bank "működhetne". Ha azok a munkatársak, akik a jövő alakításában vesznek részt nem csak saját mindennapos gondjaikat akarják enyhíteni, hanem a működőtől eltérő, korszerűbb bankot is el tudnak képzelni, együttműködésük az informatikusokkal ugrásszerűen megjavul, és ennek következtében arányosan csökken a kudarcok valószínűsége is.

Hosszú távon a jól képzett bankárok tömege tudja kitermelni azt a réteget, mely az IT fejlesztésekben a technológusok partnereként nemcsak bankári hanem IT ismeretekkel is rendelkezik, s ebből a rétegből kerülhetnek ki azok, akik már nem csak bizalmat kaphatnak, de akikről mások "tudják" is, hogy képesek megoldani a feladatokat.

Minden bizonnyal elsősorban a komplex banki+IT ismeretek jóval magasabb szintje magyarázza azt, hogy a fejlett országok bankjaiban az IT fejlesztés már a bizalom pozitív szaldójú folyamatában zajlik. 

4. Stratégia

A banknak ki kell dolgoznia azokat az üzletpolitikát, üzleti stratégiát, IT stratégiát stb. meghatározó dokumentumokat, melyek a napi döntések állandó keretét adják. Minden felmerülő problémát ezen dokumentumokban rögzített elvek tükrében kell megvizsgálni. Sajátos módon e dokumentumok jóságát éppen az mutatja, hogy az aktuális problémákkal szemben mennyire érzékenyek. Nem jó az a stratégia, amit naponta újra kell fogalmazni.

Az IT stratégiának eléggé egyértelműnek kell lennie ahhoz, hogy a rövid távú tervek belőle egyértelműen származtathatóak, ill. a felmerülő új igények beépíthetők, ütemezhetők vagy éppen elutasítandók legyenek. Nem jó pl. az a stratégia, ami az alapvető döntéseket olyan távolra helyezi időben, hogy a taktikai döntéseket teljesen szabadon hagyja.

Nem minden bankban és nem mindig lehet ezeknek a kívánalmaknak megfelelő IT stratégiát kialakítani, de a bank vezetésének mindent meg kell tennie annak érdekében, hogy a fejlesztések széles körben elfogadott és egyértelműen meghatározott keretek között folyjanak.

5. Magas színvonalú projekt szervezés és irányítás

A fentiekben bemutatott ellentmondások többsége nem bank specifikus és nem is magyar sajátosság. A fejlett országokban ugyanezen ellentmondások már jóval korábban felszínre kerültek, s feloldásukra egy sor megoldás született. Ezek döntően a feladat megoldásnak a szervezet hierarchiájából való kiemelésére, a team munkára, a projekt koncepcióra épülnek.

A projekt menedzselés témakörét, melynek irodalma ma már könyvtárakra rúg, e tanulmányban nem tekinthetjük át részleteiben. Itt csak annyit említünk meg, hogy a korszerű projekt menedzselés legfontosabb ambíciója éppen a fejlesztést végrehajtó szervezeten belül fellépő érdekellentétek hatékony feloldása. A banki IT fejlesztések terén a felhasználók egyre intenzívebb bevonása az a jellemző motívum, mely az érdekellentétek oldódásához vezethet. 

A projekt menedzselés kulcskérdése a megfelelő projekt vezető kiválasztása. Személyében az üzleti és technológiai ismereteknek egyaránt megfelelő színvonalon jelen kell lenniük, s rendelkeznie kell a projekt irányításhoz szükséges speciális tapasztalattal is. A projekt irányítás és a sokoldalú képzés kérdése így összefügg.

6. Érdekérvényesítés

A banki IT kérdései összetettek, sokszintűek. Senki sem állíthatja magáról, hogy birtokában van a legfőbb tudásnak. Ezért az IT döntéshozatalt minden szinten demokratikus módon kell kialakítani. E döntéshozatali mechanizmusnak biztosítania kell, hogy egyrészt parciális érdekek ne keresztezhessenek fontosabb érdekeket, másrészt a parciális érdekek is artikulálódhassanak, hogy az érdekek nyíltan ütközhessenek.

Az IT stratégiának olyan előkészítő folyamat termékeként kell megjelennie, amelyben minden számottevő érdekszféra kifejthette elképzeléseit. Magának a dokumentumnak olyannak kell lennie, amit az összes érdekszféra elfogad a saját maga számára is irányadónak. Ez nemcsak az IT kérdések kezelésének demokratikus voltát feltételezi, hanem azt is, hogy a kialakított IT stratégia közismertté tétele, elfogadtatása érdekében a bank vezetése jelentős erőket mozgat meg. A fejlesztési folyamat támogatásának, sőt, már jóindulatú szemlélésének is előfeltétele, hogy azok a munkatársak, akik bármilyen szinten kapcsolatba kerülnek a folyamattal, ismerjék a fő célokat, lehetőségeket, terveket, a projektek készültségi fokát stb.

A bank vezetésének vállalnia kell az elfogadott stratégiát akkor is, amikor parciális érdekek elfogadhatatlan követeléseit kell a stratégia szellemében elutasítani. Biztosítani kell, hogy a stratégiával szemben elvtelen engedményekre senkinek a kezdeményezésére, semmilyen fórumon ne kerülhessen sor, de minden indokolt módosítási igényt a stratégián azonnal átvezessenek. 

Zárszó

A tanulmány végigolvasása után a tisztelt olvasó bizonyára azt érzi, hogy a szerző elfogult, s az elmondottaknak nyilván van más nézőpontja is. Különösen zavaró lehet az olvasó számára, ahogy a szerző az üzleti oldal szereplőire zúdítja kritikája tűzét, mintha minden konfliktusnak ők lennének kiváltói. A felsorolt példák azt az érzést kelthetik, mintha a bankok vezetői rendszeresen rossz döntéseket hoznának, ráadásul olyankor, amikor az IT emberei éppen a helyes döntéseket sugallják.

Az olvasónak igaza van, a kép nyilván egy kissé egyoldalú. A szerző ismeri a felvázolt jelenségek egy másik interpretációját is, melyben nagyobb hangsúlyt kap az IT apparátus gyarlósága, agresszivitása, kompromisszum képtelensége, elfogultsága stb.

A "másik oldal", ha megírná valaki e tanulmány pandantját, arról számolhatna be, hogy az IT fejlesztések kilátástalan helyzetbe hozzák a banki szervezeteket, korábbi működési rendjüket felborítják, a gépekkel állandóan baj van, a programok hibásak stb. és a panaszok áradata végtelen. 

Ez a kép is igaz, s a tanulmány korábbi fejezetei is arról szóltak, hogy az IT fejlesztések körül mindig különösen sok konfliktus van. Az olvasó néha azt is érezhette, hogy a szerző apró-cseprő problémákból "konstruál" mondvacsinált ellentmondásokat, holott nincs másról szó, mint hogy az életben semmi sem megy simán, az ellentmondások egyszerűen menedzselési problémák, melyeket minden szervezetben az arra a posztra állítottaknak kell megoldaniuk.

Ez is igaz. A fő kérdés azonban az, hogy egy adott szervezet a változásokból eredő konfliktusok milyen tömegét viseli el, hol van a konfliktus vállalásnak és az intézményi hatékonyság növekedésnek közös optimuma.

Ha a változtatások végrehajtása nem sürgős, alacsonyabb konfliktus szintre lehet berendezkedni. Ellenkező esetben vállalni kell a konfliktusok éleződését.

A változás sebessége és a generálódó konfliktus mennyiség között egyszerű összefüggések vannak. Pusztán a szemléltetés kedvéért: lassabb változás = több idő = gondosabb oktatás = kiérleltebb programok = jobb dokumentációk = simább áttérés = kevesebb programhiba = kevesebb felhasználói hiba = végeredményben kevesebb konfliktus.

A változás sebessége és a generált konfliktusok mennyisége függ az azt végrehajtó szakemberek számától is. A fejlesztő szervezet azonban nem bővíthető egy adott határnál gyorsabban, sőt a túl gyors szervezeti felfutás egy sor további konfliktus előidézője.

Mindezek alapján a bank vezetésének a legfontosabb kérdések között (milyen ütemű fejlesztést diktál a piac, mennyi pénz áll a fejlesztések rendelkezésére) kell megvizsgálnia: mekkora a bank konfliktustűrő képessége, milyen gyors korszerűsítés lehet reális célkitűzés.

A zárszó ürügyén újabb megfontolások kerültek terítékre, és félő, hogy az olvasóban további megválaszolatlan kérdések keletkeztek. E tanulmánynak azonban nem lehet célja a banki IT fejlesztés összes menedzselési kérdésének napirendre tűzése. Amint a bevezető jelezte, a tanulmány célja: felhívni a figyelmet egy konfliktusoktól különösen terhelt területre, mely jelentős forrásokat köt le, s nem csak a bankok számára nem mindegy, hogy e források eltékozlódnak, vagy optimálisan hasznosulnak.