Miért, nehéz? Legalábbis lényegesen nehezebb, mint korábban, mikor elképesztő CAPEX (beruházás) budget-k álltak rendelkezésre, szinte minden ötlet átment a jóváhagyó fórumokon. Számtalan példát ismerünk a banki világból több száz milliós, évekig tartó projektekről, melyek finoman szólva is kétes eredménnyel zárultak. Ehhez képest ma mi a helyzet? Amit mindenki láthat, 100 milliárd – még egyszer száz milliárd – Ft-ot meghaladó negyedéves veszteségek, több száz fős elbocsájtások, tömeges fiókbezárások. Amit nem lát mindenki, beruházási és operatív költségek drasztikus faragása, konkrét példaként van olyan bank, ahol az IT budget 70%-kal kisebb, mint tavalya, értsd jól, marad kevesebb, mint a harmada.

Rendhagyó lesz ez az írás, kivételesen a „másik oldal”-ról fog szólni. Hogy lehet ilyen közegben banki IT vezetőként jól teljesíteni, - de ne legyünk maximalisták, - legalább túlélni? Mielőtt megpróbálnánk választ találni, picit a korábbi időszakról, az „arany évekről.”
Repüljünk vissza mondjuk a 2000-es évek közepéig. Gazdaság dübörög, hitelezés csúcson, dől a lé. Komoly IT beruházások zajlanak a bank szektorban, frontend-ek, alaprendszer cserék, CRM projektek. Néhány bank már komoly szereptévesztésben van, a vendor kiszolgáltatottságtól való paranoiás félelemtől vezérelve extrém erős IT-t építenek ki, már-már szoftverházakra jellemző erős architektúrális, módszertani és eszközhasználati előírásokkal. Kiemelkedően fizetett IT szakik mondják meg a laborból a tutit, időnként teljesen öncélúan, elfelejtve, hogy tulajdonképpen miért is vannak IT beruházások?! Hogy kiszolgálják az üzletet. Ehhez tényleg 14 különálló cluster-t kell építeni 3 telephelyen?! Nem hiszem. Mások nem gondolták, hogy feltétlen nekik kell diktálniuk, viszont meg kell venni azt a szaktudást is, amíg kiderül mit is szeretnénk pontosan. Eszméletlen összegek mentek el tanácsadásra, koncepció gyártásra, pilot-okra. Mindkét irány – és tuti van még több is – közös tulajdonsága, hogy bődületes pénzekbe kerül. Ami mostanában nem áll már olyan korlátlanul rendelkezésre.

Mit okoz ez? Természetesen a nagy beruházások leálltak, átpriorizálódtak, felfüggesztésre kerültek. Az oktatási költségek magától értetődően egy mozdulattal lehúzásra kerültek. A support és maintenance szerződéseket átnézték, amit lehetett lemondták. A külsős erőforrásokat amennyire lehetett leépítették, a szükséges kompetenciákat megpróbálták belülre húzni. A belsősök közül is sokakat elküldtek, az IT vezetői réteget szűkítették. A szállítók napidíját lenyomták.

Azután ez nem volt elég spóroljunk az OPEX-en is (üzemeltetés). A méregdrága szoftverek helyett használjunk open source-ot, szervereket konszolidáljunk, üzemeltetést szervezzük ki, csökkentsük újra a support-ot, a szükséges rendszer upgrade-eket halasszuk el. Tapasztalt és sokba kerülő munkatársakat cseréljük lelkes és lényegesen kevesebbe kerülő fiatalokra.  A szállítók napidíját nyomjuk le újra.

De az élet nem áll meg. Újabb és újabb deviza hiteles mentőcsomagok születnek, újabb és újabb fejlesztéseket indukálva, lehetetlen határidőkkel. Nem baj, fejlesztünk házon belül. Tudunk? Nem nagyon, elvégre nem ez a core business, de legalább megpróbáljuk. Dolgoztassuk a juniorokat napi 10 órában, időnként hétvégén is. Ha feltétlen kell szállítói közreműködés, próbáljuk az árat csökkenteni azzal, hogy nem kérünk projektvezetést – majd megoldjuk mi – dokumentálni se kelljen nagyon, tesztelni meg még úgy se. A szállítók napidíját nyomjuk le.

Mi az eredmény? Alulmotivált, képességekkel korlátozottan bíró, fiatalok bolyonganak az erdőben, épp úgy mint egy korábbi posztunkban, csak nincs velük Chuck Norris. A rendszer persze elmegy a maga tehetetlenségében még egy ideig, de a hozzá ne értés okozta folyamatos barkácsolás, a core rendszerek kényszeresen elhalasztott upgrade-je előbb-utóbb sokba fog kerülni.

Hogy lehet sikeres ebben a környezetben egy IT banki vezető? Néhány ötlet a teljesség igénye nélkül:

• Egy szerver konszolidáció biztos megtérülés. Akár sikerdíjas alapon is bevállalható.
• Ha már felmérünk, nézzük meg a szoftvereket is. Különösen év forduló előtt érdemes  - megint csak szakértők segítségével - felkészülni.
• Nem mission critical alkalmazásokat áthelyezhetünk nyílt forráskódú platformra, Jboss, Tomcat előnyben.
• Bár sok lelkes juniorunk van, vigyázzunk arra, hogy legyen néhány olyan seniorunk is, akikre rábízhatjuk a fiatalságot, mind szakmailag, mind emberileg.
• Ha vannak projektjeink, próbáljuk meg fókuszáltan, rövid iterációkban, eredmény centrikusan vezetni őket.
• És persze a szállítók napidíját nyomjuk le. :)

Ha van még valakinek ötlete, ossza meg velünk bátran.