Nehéz minden IT-vezető élete, nincs semmi kétség efelől. Boardülések követelőző üzleti területi vezetőkkel, pattanásig tömött (majd időnként szét is pattanó) projektportfóliók, demotivált, innovatív projektek és konstans fizetésemelés után vágyó beosztottak, lángoló karddal fenyegetően közeledő felügyeleti vagy ISO auditorok, tetszőleges pillanatban összeomló kritikus üzleti rendszerek szegélyezik a CIO-k küzdelmes mindennapjait. Úgy tűnhet, ilyen helyzetben kisebb csoda kell ahhoz, hogy a szervezet működésére, folyamatainak fejlesztésére is jusson idő. A csoda persze rendre elmarad, így aztán a viharvert IT-vezető hamarosan Tűzoltóparancsnokká változik.
A Tűzoltóparancsnoknak pedig egy dolog fontos: ha lehet, ne gyulladjon ki semmi, vagy ha valami lángra kap, lehetőleg oltsa el valaki, mielőtt kitörne egy mindent elhamvasztó tűzvész. A Tűzoltóparancsnok a legveszélyesebb tüzeket maga oltja el. Vagy legalábbis személyesen irányítja az oltási munkálatokat, egyik tűzfészektől a másikig rohangálva. A tűzoltók szeretik is emiatt a Tűzoltóparancsnokot, mert igazi bajtársként viselkedik, és mindig fordulhatnak hozzá, ha nem tudják eldönteni, hogy porral vagy vízzel oltsanak, illetve a kismacskát vagy a nagymamát kell-e kimenteni először a lángok közül. A Tűzoltóparancsnoknak nagy segítség az a néhány Hős Tűzoltó, akik életüket kockáztatva rohannak minden oltásnál a lángok közé, de a nagy pánikban arra már nekik sincs idejük, hogy a tüzeket csak biztonságos távolból figyelő Elméleti Tűzoltó Kollégákat is valódi oltási munkára fogják. Időnként persze leég egy-egy épület, de hát a tűzoltók is csak emberek, és a nap végén, mikor holtfáradtan otthon a kanapéra rogynak, már gondolni sem tudnak arra, hogy a tűzoltás helyett lehetne megelőzéssel is foglalkozni.
Én azt hiszem, a legtöbb CIO nem akar Tűzoltóparancsnok lenni. Vagy nem is akart soha. Vagy már belefáradt a szerepbe, csak nem tudja, hogyan szabaduljon meg tőle. Mert tüzet oltani bármelyik tűzoltó tud a parancsnokságon, de stratégiában gondolkozni, irányt mutatni, jövőt tervezni, szolgáltatás fejleszteni, folyamatokat rendbe rakni, fenntartható működést kialakítani, építkezni csak a Parancsnok tud, és ha ő nem csinálja ezeket, akkor biztosan nem fogja csinálni senki.
De mik gátolják meg az IT vezetőket hogy kibontakozzanak, és maguk mögött hagyják a napi tűzoltást?
A spagetti szervezet
Ha ránézünk a mindennapi működésünkre, bizony sokszor csak egy hatalmas problémagombócot látunk, és ha abból megpróbálunk kihúzni egy szálat, jön vele az összes többi. De mivel kezdjek el foglalkozni, amikor egyszerre van emberhiány a BI-projektben, omlik össze nap mint nap a call center szoftvere, két hete vissza kellett volna küldeni a HR-nek a képzési tervet, és már megint egyszerre akar felmondani az egész infra üzemeltetési részleg?
A megoldás viszonylag kézenfekvő: az IT-szervezet folyamatainak jól elválasztható szegmensekre bontása és fontossági sorrendbe állítása. Nincs értelme addig a projektportfólió-menedzsmentet vagy a tesztmódszertant építgetnünk, amíg a folyosón véletlenszerűen szembejövő kollégáknak osztogatunk feladatokat, és minden feladatot az a néhány mindent nyakába vevő hősünk hajt végre. Kezdjük hát minden esetben a következőkkel: tegyük rendbe:
● a feladatmenedzsmentet, hogy tudjuk, ki mit és mikorra csinál meg a csapatban;
● az erőforrásmenedzsmentet, hogy tudjuk, mennyi szabad kapacitásunk van, milyen erőforrásokat kell pótolnunk, és hogy betartható határidőket vállaljunk
● az igénymenedzsmentet, hogy azokra a témákra fordítsuk a véges erőforrásainkat, amik igazán fontosak.
Ha ezek már megbízhatóan működnek, tovább lehet lépni a fejlesztési folyamat, tesztmódszertan, projektmódszertan rendberakásával. Aztán ha már minden elég jól – bár nyilván nem tökéletesen – működik, csillogó szemmel el lehet vonulni IT-stratégiát írni.
Most akkor revolution vagy evolution?
Csábító gondolat lehet, hogy fogjunk egy divatos új módszertant, és borítsuk rá az egészet a szervezetre. Mondjuk, egy teljes pályás agilis transzformációt – természetesen egy patinás nevű tanácsadó cég irányításával. Akik persze azt mondják, hogy „evolution, not revolution”, aztán ledózerolják az addigi működést – például egy skandináv zenei streaming szolgáltató által használt módszertannal –, majd a kialakult káoszból angolosan távoznak.
Ha nem ez a vágyott út, akkor egy esélyünk van: ha a kis lépésekben haladunk a működésfejlesztésben, és azt a meglevő működésre, emberekre, kultúrára építjük. Itt három alapelvet kell szem előtt tartani.
1. A gépezet nem állhat meg, folyamatosan kell szállítani és üzemeltetni. Márpedig egy tarvágás után erre nincs esély.
2. A meglévő értékek VALÓDI értékek, és nem csak szavak egy SWOT analízis egyik sorában. Ha ezeket kidobjuk, kidobjuk azt, ami a cspatot egyedivé és sikeressé tette. Nem szégyellni kell azt, amilyenek vagyunk, hanem szét kell választani azt, amire tudunk építeni tudsz és azt, amin változtatni kell!
3. Nem elég a szabályzatokból új verziót kiadni: szokásokat kell kialakítani, embereket kell megváltoztatni... Ez igencsak időigényes folyamat. A szabály: legyünk türelmesek, következetesek, ragaszkodjunk az új működéshez, és nézzünk időnként vissza az úton, hogy lássuk, milyen messzire jutottunk!
Nem köszöni meg senki, és nincs is ideális pillanat
Az, hogy az IT hogyan működik belül, nem igazán érdekel senkit. Nem érdekli a vezérigazgatót, nem érdekli az üzletet, nem érdekli az ügyfeleket: az egyetlen, akinek fontos a működés fejlesztése, az maga az IT vezető, és a szervezetben dolgozók. Meg kell találnod hát a módját annak, hogy motiváld magad arra, hogy abból a borzasztóan véges rendelkezésre álló időből és erőforrásból a legmostohább körülmények között is fordíts a tükörbe nézésre és a fejlődésre.
Olyan ez, mint a testedzés: nem köszöni meg neked senki, ha eljársz a konditerembe, és két alkalom után még nem is látszik az eredménye, de ha kötelező részévé válik az életednek, és elég kitartó vagy, akkor egyszer csak az fog visszanézni rád a tükörből, aki mindig is lenni akartál.
A Wunderplan tanácsadó cég ügyvezetője, projektmenedzsment- és szervezetfejlesztási szakértő. Tapasztalatait élvezetes írásokban osztja meg a szakmában népszerű Derrick és Harry blogon.
Tavasszal indult egy csomó projekt, akkor azért nem fért bele. Nyáron mindenki szabin lesz, akkor azért nem lehet. Ősszel majd összetorlódnak a határidők, meg jön az audit is – inkább ne erőltessük. Télen meg ott lesz az év vége meg az év eleje, olyankor nem érünk rá ilyesmire.
Két lehetőségünk van: megvárjuk, amíg elfogynak az operatív feladatok, és akkor ráérünk a működésünkkel is foglalkozni. Ez az eset általában akkor áll fenn, amikor a cégvégelszámolás alá került. A másik lehetőség: belevágunk most. Nem a jövő héten, nem a jövő hónapban, nem az audit után, nem a release után... Hanem most. Fájni fog? Naná! Nehéz lesz? Nagyon! Megéri? Megéri!
Meg amúgy is: ez lenne a legfontosabb dolga minden IT-vezetőnek, aki nem akar örökké Tűzoltóparancsnok maradni.
Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak