A szervezetfejlesztésről több könyvtárnyi tanulmányt, cikket írtak, és gombamód szaporodnak az ezzel foglalkozó tanácsadó cégek is. Vezetőként mindenki tanult róla, s legtöbbünk használja is a mindennapi gyakorlatban ezt a tudást.
Ahány ház, annyi szokás...
Abban minden irányzat képviselője egyetért, hogy a szervezetfejlesztésnek az a feladata, hogy hatékonyabban működjön a vállalat és az ott dolgozó munkatársak. Szervezetfejlesztést sokféle módszerrel lehet végezni, és a folyamat során sok szempont figyelembe lehet venni. Ám minden módszertanban közös, hogy a fennálló állapot és folyamatok elemzéséből indul ki, majd egy akcióterv kidolgozásával folytatódik, amely a kívánt cél eléréséhez szükséges teendőket tartalmazza. Végül pedig – a folyamat végén – vissza kell mérni az elért működési hatékonyságot.
A legtöbb iskola fontosnak tartja, hogy a szervezetben dolgozók megismerjék és elfogadják az új folyamatokat és a szervezeti felállást, mert az elengedhetetlen ahhoz, hogy a változtatás elérje a célját. Ez azért is kiemelten fontos, mert ahány szervezet, annyi kultúra. A szervezeti kultúra pedig meghatározza a változtatási módszert is. Ha a kettő független egymástól, nagy az esélye annak, hogy a változás szándéka kudarcba fullad.
A változás örök és folyamatos
Már vezetőként kellett rájönnöm arra, hogy a szervezetfejlesztés nem egy időről időre, pl. 3-5 évenként felmerülő, tanácsadókkal megtámogatott tevékenység, hanem lényegében olyan vezetői feladat, melyet folyamatosan végezni kell. A változásokat ugyanis az előttünk álló megvalósítandó feladatok, a környezethez történő alkalmazkodás és a piaci változásokhoz kapcsolódó versenyhelyzet együttesen és folyamatosan indukálják. Természetesen ez nem azt jelenti, hogy a szervezet működését hetente "felborítjuk", hanem inkább finomhangolások sorozatát a következő nagyobb átalakításig.
Amikor jelenlegi vállalatomhoz kerültem mint szervezési és IT-fejlesztési igazgató, Amikor jelenlegi vállalatomhoz kerültem mint szervezési és IT-fejlesztési igazgató, a feladatom az volt, hogy egy szigetrendszerekből álló alkalmazáshalmazt hogyan lehet korszerű, a digitalizáció követelményeinek megfelelő integrált többrétegű architektúrává alakítani. Ehhez óhatatlanul a szervezetben is változásokat kellett végrehajtani.
A változás nem öncélú
A szervezet ugyanis az évek során alkalmazkodott a szigetszerű rendszerekhez, a szervezeti hierarchia is ahhoz a struktúrához kapcsolódott, és az ebben dolgozó munkatársak is csak különálló rendszerekben gondolkoztak.
Ehhez képest a cél az volt, hogy többrétegű, integrált architektúra jöjjön létre megfelelő szervezeti háttérrel. Csakhogy az akkoriban nem volt általános. Emiatt nagyon nehéz volt a szervezetben dolgozóknak átlátni és elképzelni, hogy a számos rendszert hogyan lehet úgy integrálni, hogy elérjük a kitűzött célt.
Először megalkottunk egy olyan szervezeti modellt, amely megfelelt ennek. Az IT-csapatban kialakítottunk két osztályt: az egyik az adatbázisokkal (háttérrendszerek), a másik a frontrendekkel és – az akkor még nem létező – middleware-rel foglalkozott. Az átalakítások során a meglévő szigetrendszereket is besoroltuk a két terület valamelyikébe az érintett kollégákkal együtt.
A nagy változásoknak mindig lesznek ellenzői
Ez gyorsan és egyszerűen lezajlott, tekintve, hogy itt egy viszonylag mechanikus folyamatról volt szó, ahol nem sok szakmai vitára van lehetőség. Ugyanakkor számolni kellett azzal, hogy egy ilyen lépéssel nem mindenki ért egyet. Az elégedetlenek ilyenkor gyakran távoznak, amire fel kell készülni.
Ez egy olyan változást példáz, amelynél csak az új architektúra felállása után látszott egyértelműen, hogy merre is haladunk. Akkor azonban a szervezet felgyorsult, felvette a fejlődés ritmusát, és a visszamérések alapján csak finomhangolásokat kellett a szervezet folyamatain és működésén elvégezni.
A munkatárs a legjobb KPI
A változtatás igénye nem mindig felülről érkezik. Erre is szeretnék egy példát mutatni.
Mint minden multinacionális cégnél, az Allianznál is évente készítünk felmérést a dolgozók elégedettségéről. Ilyenkor nem csak az a cél, hogy magas legyen a részvételi arány, hanem az is, hogy az eredmények javuljanak, azaz a cég alkalmazottai elégedettek legyenek munkájukkal, munkakörnyezetükkel, vezetőikkel. Ez utóbbira a lezárt felmérések kiértékelése után akciótervek is készültek. Ismerős? Gondolom, sokaknak igen.
A kitöltöttséggel az IT szervezetben soha nem volt baj, a kollégák már presztízsből is a 100 százalékra törekedtek. Az értékek azonban nem javultak az elvártaknak megfelelően, holott az akcióterveket az ott dolgozókkal közösen dolgoztuk ki és hajtottuk végre.
Végül úgy döntöttünk, ismét megbeszéljük – de a korábbiaktól eltérően már nem az elégedettségi kérdőív mentén –, hogy mit kellene változtatni, hogy az IT-szervezetben dolgozók jobban érezzék magukat.
A megbeszélés nem várt eredményt hozott: a munkatársak azért érezték rosszul magukat a szervezetben, mert munkájukat nem tudták olyan hatékonysággal elvégezni, ahogy ők szerették volna, ugyanis számos apró – és éppen ezért alattomos – akadályozó tényezőbe ütköztek. Mivel a problémát ők látták a legtisztábban, azt javasoltuk, hogy alakítsanak teameket, melyek kidolgozzák, hogy milyen irányba kell mozdítani a szervezetet és a folyamatokat, hogy az nekik jobban megfeleljen, és elháruljanak ezek az apró és bosszantó akadályok.
A csapatok egy hónapot kaptak, mely idő alatt igen komoly munkát végeztek. Az eredmény ugyanis egy a teljes szervezetet átfogó átalakítási koncepció lett, melyekben új folyamatok és azoknak megfelelően új KPI-ok is megjelentek.
A munkatársak javaslata az volt, hogy az addigi architektúrális felállás helyett az üzleti funkciók mentén alakítsuk át a két osztályt úgy, hogy az adott üzleti folyamatokhoz kapcsolódó specifikációs, fejlesztési és tesztelési folyamatok egy teamen belül maradjanak.
Csupán a szokásos pénzügyi, folyamatbeli kontrollokra kellett módosításokat kérnünk, így gyakorlatilag az új felállást két hónap alatt be lehetett vezetni. A rövid határidő nem kis részben annak volt köszönhető, hogy az átalakítás a legnagyobb dolgozói támogatással történt.
Megéri foglalkozni vele
Nem meglepő, hogy a szervezeti átalakítást követően az elégedettségi mutatók jelentősen megugrottak. A szervezet a KPI-ok riportjait látva, arra is képes volt, hogy javaslatot tegyen folyamatainak javítására, és megfeleljen a vezetői elvárásoknak.
A fenti tapasztalatok sokat segítenek most is, amikor CIO-ként dolgozom. Például megtapasztaltam, hogy ha a feladatok kellő szakmai kihívást jelentenek a kollégáknak, ők is a hatékony munkavégzésre törekednek, jó javaslataik vannak, részt akarnak venni a saját munkájuk folyamatainak alakításában. A vezető ezt bátran felhasználhatja a szervezetfejlesztés során.
Nem kell nagy dolgokra gondolni. Sokszor apróságokon is nagyon sok múlik. A közelmúltban például ilyen újítás volt, hogy az érintettek kérték, hogy a rendszerszervező (business analyst) üljön együtt a rendszertámogatóval (alkalmazásüzemeltető) akkor is, ha nem egy szervezeti egységhez tartoznak az IT-n belül.
Az ilyen javaslatok persze felvetettek problémákat, olykor nagyon prózaiakat. Például esetünkben azt, hogy egylégterű irodában dolgozunk, és egy ilyen átalakítás azt jelenti, hogy a vezetők nem tudnak a csapatukkal egy helyen lenni. Ám erre is jött megoldás: a vezetők is üljenek le egy közös boxba, ami szintén a hatékonyságot segíti.
Azt gondolom, hogy a változások kitalálása a szervezet megfelelő érettségi fokán nem csak vezetői feladat. Ha megfelelő légkört és érdekes szakmai kihívásokat teremtünk a kollégáinknak, pontosan tudni fogják – és el is árulják –, hogy hogyan tudják a leghatékonyabban elvégezni a munkájukat. Csak hagyni kell őket gondolkodni, hiszen ők is keresik az optimumot.
A cikk a Vezető Informatikusok Szövetsége támogatásával készült.
Szakmai nap a jövőálló digitális infrastruktúra jegyében
A digitális infrastruktúra új kihívásai - legyen szó MI megoldásokról, szigorodó fenntarthatósági követelményekről, vagy az reziliens és szünetmentes működésről - szinte minden nagyobb szervezet életében meghatározó szerepet játszanak. Egy szakmai rendezvénysorozat segítségével közelebb kerülhetünk a megoldásokhoz és segítséget kaphatunk az új technológiák sikeres implementálásához.
a melléklet támogatója a Yettel
Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak