Az agilis szoftverfejlesztés után/mellett most nézzük meg, milyen az agilis szervezet.

Az agilis szoftverfejlesztés után/mellett most nézzük meg, milyen az agilis szervezet.

Az agilis, az agilitás korunk egyik buzzword-je, és már sokat írtam az agilis szoftverfejlesztéssel kapcsolatban – ami egy óriási téma. Ugyanakkor az agilitás nem csak a szoftverfejlesztők sajátja, hanem mostanában (talán egyre gyakrabban) az informatikai vezetőké, a cégvezetőké is. Ezért most az informatikát félretéve az agilis szervezetről, az agilis szervezet kiépítéséről szeretnék írni.

A téma apropóját az adja, hogy az elmúlt fél évben 3 olyan vezetői prezentációt is láttam, ahol a téma – agilis szervezet – felmerült, plusz a Harvard Business Review is írt róla.

Az agilis szervezet, az agilis vállalat igen jól meghatározható. Olyan szervezetről vagy vállalatról beszélünk, amelyik nem csak végrehajtja az utasításokat, hanem rugalmasan alkalmazkodik a körülményekhez és az új igényekhez. Vagyis egy komplex adaptív rendszerről beszélünk. Az előnyök konkrétan azt eredményezik, hogy a változás költsége alacsony, illetve a Time-To-Market ideje (a ciklusidő) csökken.

Mondanom sem kell, ezek olyan előnyök, amik könnyen érthetőek és könnyen kommunikálhatóak. Érti a pénzügyi vezető, a marketinges, az értékesítő és a gyárvezető, érti a munkás és a menedzser is. Mindez azt jelenti, hogy az agilis szervezet, vagy az agilitás mint stratégiai cél egyértelmű és világos. Soha senki sem fogja megkérdőjelezi, senki sem fogja azt mondani, hogy ne legyen a vállalat agilis.

(Még akkor is, ha ezt valaki esetleg túlságosan utópisztikusnak bélyegezné – valljuk meg, elméletben és papíron ezek az előnyök nagyon kecsegtetőek, amiért érdemes legalább egyszer foglalkozni a témával.)

A vállalati szintű agilitás ráadásul egy annyira megfogható és elképzelhető dolog, hogy az agilis vállalat jellemzői egyértelműen meghatározhatóak. Az interneten százszámra fogunk találni cikkeket, amelyek precízen leírják, milyen egy agilis vállalat.

A lényeg a lényeg, az agilis szervezet, az agilitás nagyon jól tud mutatni egy 3-5 éves stratégia részeként, jól tud mutatni egy prezentáción.

A probléma ott kezdődik, amikor ebből a célkitűzésből konkrét tervet kell csinálni. Tervet ugyanis kell csinálni: az agilis szervezet nem lesz magától agilis, hanem azért tenni kell. Mégpedig felülről. Arra nem lehet várni, hogy az eddig folyamatok, előírások és utasítások által vezérelt közösség majd holnaptól magától agilis lesz.

Ez a legnagyobb hiba, amit egy felsővezető tehet: azt várni, hogy a szervezet majd alulról felfelé agilissá válik. Nem elég, ha a beosztottakat és menedzsereket „agilizálják”, azaz elküldik tanfolyamra. Az sem elég, ha az éves célkitűzésükbe beleírják az „agilis szervezet” kitételt, és majd annak függvényében osztanak bónuszt, ki mennyire agilis. Nem, ennek a változásnak – pont úgy, mint minden más szervezeti változásnak – felülről kell elindulnia.

Na ezért kell terv és ezért kellenek konkrét lépések.

És itt jutunk el oda, ahol a part szakad. Sok cikk szól az agilitás előnyeiről, és hogy milyen egy agilis szervezet, de arról kevés, hogy akkor konkrétan mit is kell tenni a sikeres átalakuláshoz. Az eredményről sok szó esik, az útról kevés. A legtöbb esetben szerencsesüti-jellegű bölcsességeket lehet találni. Pl. meg kell találni az egyensúlyt, hogyan vezessük a káoszt, illetve hogy a tradicionális utakat magunk mögött hagyva új utakat kell keresni.

A PR-jellegű agilizálódást a valódi agilizálódástól a részletek különböztetik meg. Mármint hogy vannak részletek. Az agilizálódás módszertani, szemléletbeli és cégkultúra-beli változásokat jelent. Nem egy-két dolog változik, hanem minden – vagy legalábbis több alapvető dolog. Ha ezek a változások nincsenek megtervezve és lefektetve, akkor ott délibáb-kergetés zajlik.

A másik probléma az agilis, adaptív szervezettel az, ahogyan azt a felsővezető – a változás motorja – elképzeli. Mert nyilván adottság, hogy a döntéshozást nem engedi ki a kezéből. Továbbra is szoros ellenőrzést akar. Ez azt jelenti, hogy a folyamatok és a bürokrácia a helyén marad.

Folyamatokkal és bürokráciával pedig úgy lehet a ciklusidőt csökkenteni, ha a folyamatainkat felgyorsítjuk. Például több és jobb sztenderdünk lesz, belső folyamatoptimalizálást hajtunk végre, vagy összevonunk és központosítunk.

Ez az út, amit a CMMI fejlettségi szintekhez hasonlítanék. A szervezet elindul onnan, hogy lazák a folyamatok, a siker „csak úgy” megtörténik. Innen eljutunk oda, hogy már vannak folyamataink, de még reaktívak vagyunk. Aztán fejlődünk, proaktívak leszünk. Aztán központosítunk, mindent mérünk és ellenőrzünk. És eljutunk az 5. szintre, hogy a mért és ellenőrzött, központosított folyamatainkat optimalizáljuk. Ehhez képest lesz az adaptív szervezet a 6. szint.

Aki nem értette a címet, az remélem most megértette. Az agilitáshoz úgy jutunk el, hogy az eddigieknél jobban egységesítünk. Agility through Unity. Aki ismerősnek találja a jelmondatot, annak igaza van: a V for Vendetta nevű filmből való utalás ("Strength through Unity. Unity through Faith").

Fog-e ez működni? Biztosan nem, sőt éppen az ellenkező hatást lehet vele elérni. Az adaptív szervezet, az agilitás pontosan azért tud jól működni, mert az egyént helyezi előtérbe a folyamatokkal szemben. Tehát az igazi agilis szervezethez úgy jutunk el, ha nem a folyamatokat erősítjük (összevonás, egységesítés, ellenőrzés) hanem éppen ellenkezőleg: ha gyengítjük azokat. Ha felszámolunk folyamatokat, ha inkább az eredményeknek mint a számoknak hiszünk, ha arra építünk, hogy majd a beosztottak és a menedzserek az adott helyzetben a józan paraszti észre/logikára hallgatva a cégnek előnyös döntéseket hozzák.

Például a HBR májusi számában Fred Hassan arról ír, hogy mennyire fontosak a cég sikerének szempontjából az alsóvezetők – akikkel a felsővezetők minimális időt foglalkoznak.

Hogyan lehet akkor átállítani egy szervezetet agilisra? A siker kulcsát sajnos nem tudom, de azt tudom, hogyan nem fog sikerülni: vezényszóra, a részletek kidolgozása nélkül, kevés erőfeszítéssel, és ha a változást csak mint apró korrekciót képzelik el.