Sokba kerül a szakértő?

Üdvözlök mindenkit! Ez itt a Digit Podcast, Személyi László vagyok, a Future-NOW vezető partnere, és társam a krimiben, Szekér Zoltán, az OD&T Solutiions és a Saling Hangar alapító ügyvezetője. Sziasztok, jó napot kívánok! A Digit Podcast célja, hogy akit nem elégítenek ki a felszínes cikkek és a hangzatos jelszavak, az közelebb kerülhessen a digitalizáció és az informatika mai meghatározó trendjeihez. Mi itt a mélyére fogunk ásni a dolgoknak. Mondhatni itt a Dig-it Podcastban egymásnak adják a mikrofont az emberek. Mai vendégünk egy korábbi vendégünk ajánlásának köszönhető, ugyanis Horváth Ricsi, azaz Horváth Richárd, a digitális családfakutatás tudora hozott össze bennünket Szamosközi Péterrel, a Morihana.

ügyvezetőjével üdvözlünk a stúdióban.

Köszönöm a meghívást!

Üdvözlünk téged, szia!

Felvezetőnek a következőt mondanám. Az innovációs és digitalizációs munkám során én legtöbbször egy adott ponton elakadást tapasztaltam, így egy projektben vagy egy fejlesztésben. A jogászok és a projekt csapat tagjai között alakult ki egyfajta állóháború, ez majdnem mindig előfordult, és azon ment a vita, hogy mit miért nem lehet megcsinálni, vagy legalábbis túl magas a jogi kockázata. Az érdekes az számomra, hogy szinte mindig, legalábbis szinte egy idő után úgy magától elmúlt ez az állapot, mert kiderült, hogy van megoldás, és hogy neked van ilyen tapasztalatod, Péter? Vagy ez csak az én tapasztalatom.

Viszonylag több ilyen tapasztalatom van, merthogy ez egyik ilyen kedvenc területem, még hogyha nem is minden projektem pont erről szól. Ezek a jogszabály megfelelőségi projektek, amiben mondhatni, hogy otthon érzem magam. Az a kihívás, hogy egy jogszabálynak hogyan tud megfelelni az adott szervezet, ami új jogszabály, és ennek vannak előírásai.

Jellemzően meglehet, tehát az IT meg a jog, az ki tud békülni, ennek nagyjából egy feltétele szokott lenni, és ez meg a gazdasági rész. Tehát az az IT megoldás, ami szakmailag mondjuk elég jó, és az a megoldás, amit általában a jogászok elvárnak, hogy elég jó legyen, ezáltal alkun működik, hogyha kellően sok pénzt kap a cég erre a projektre.

És ezért kell a gazdasági ember?

Hát, vagy legalábbis előbb-utóbb bevonódik magától, amivel sorba fog kerülni. Tehát én még olyan IT-projektet nem láttam, ahol az IT-m bukott volna meg. A projekt, és nagyjából tizenkét éve ezzel foglalkozom. Azért kritikus kérdés szokott lenni, hogy mennyi idő van rá, meg mennyi pénz van rá.

És mikor kerül hozzátok ez a projekt? Általában melyik időpillanatban jelentek meg ti a cégeknél, vagy nálatok a cégek, hogy tudjátok ezt a projektet csinálni?

Hát ez teljesen változó. Nekem, és akkor beleértve a korábbi tapasztalataimat is. Az a tipikus, hogy amikor már ég a ház, tehát ugye van az a régi vicc, hogy mikor mentik ki a tűzoltók az állampolgárt az épületből, és hát kérdezik, hogy hát ég körülötte az ágy, meg a szoba, és hát mikor vette észre, hogy itt tűz van, hát már égett, amikor ráfeküdtem. Tehát hogy körülbelül ilyen jellegű projektekkel szoktak megtalálni, hogy hát van mondjuk négy hónap, hogy a két év lemaradást hozzuk be, és akkor hogy húzzuk be négy hónap alatt a két év lemaradást. És akkor behozzuk. Tehát igen, megoldható, hogyan, vagy amennyiből körülbelül ezek szoktak lenni a kritikusok. Tehát volt olyan projekt, ahol tizenkét opciót fölvázoltunk, hogy az IT szempontjából megvalósítható ez a tizenkettő, ebből nyolcat a jog azt mondja, hogy ez szép, a maradék négy nem szép, de ha nagyon muszáj, kidumálja.

Azon múlt, hogy melyik mennyibe kerül, mert nem Korászna erőforrás áll a szervezet rendelkezésére.

Ez egy fantasztikus hozzáállás. Nekem sajnos sok olyan tapasztalatom volt, ahol igazából a projekt a döntéshozók felé egy megoldást terjesztett fel. És abból alakult ki az első állóháború, hogy a menedzsment nem értette, hogy miért csak egy megoldás lehetséges, és elkezdte kérdezgetni, hogy de hogy mi biztos, hogy ezt az összes rendszert, de hogy biztos, hogy ilyen hosszú szöveggel kell aláíratni. És föltett egy csomó ilyen kérdést, amire a projekt igazából azért nem tudott jó választ adni, mert nem gondolta végig. Ő egy verzióban végiggondolta, hogy ez így kerek, ez így jó lesz, akkor ezt visszük. Hogy ebben láttok egyébként egy fejlődést, hogy esetleg ma jobban, hát kreatívabban állnak hozzá, több megoldásban gondolkodva állnak hozzá az emberek, mint mondjuk öt-tíz évvel ezelőtt?

A helyzet az, hogy mindig, én azt mondom a mindigre, ezt vegyük úgy, hogy az elmúlt 25 évben, ahova engem tüzet hívtak oltani. Ott jellemzően az derült ki, hogy a menedzsment odaadta a feladatot az IT-nak. Ez egy IT-s projekt. Oldjátok meg! Az IT nem kapott támogatást abban, semelyik részétől a cégnek, hogy egyébként hogyan kéne megoldania ezt a projektet? Megkapta, ha jól van az úgy, ugye ez a kedvenc megoldási. A kedvenc megoldásom minden projektre. Úgy van, ahogy a múltkori működött. Nézzétek meg a régit. Na de mivel van bajotok? Azt nem tudjuk, de ez így nem jó. De az, amit használunk, az jó, csak. És hogy ezek az információhullámok generálódnak a végén odáig, hogy minden elakad, és ott állnak, és egy ilyen hatalmas válságmenedzsment megbeszéléssé fajul ez az egész projekt, ami normál esetben egy javító szándékkal érkezett. Ezt ti hogy látjátok?

Most ezt szerettem volna hozzáfűzni, hogy honnan alakul ki ez a dolog, és mikor kapjuk meg, mint szakemberek tanácsadásra, hogy ezt egyébként csináljuk meg. Van ennek több része. Általában saját projektjeim, és itt tudom, hogy módszertani kérdések is vannak, jellemzően úgynevezett vízesés modellben működik, ami arról szól, hogy először megmondjuk, hogy mit akarunk, aztán megcsináljuk, aztán megnézzük, hogy jó-e, amit megcsinálhatunk, nagyon leegyszerűsítve. És ennek egy markáns része az, hogy tudjuk, hogy mit akarunk megcsinálni. Volt olyan projekt, hogy régebbi rendszert kellett kiváltani, mert valami miatt nem volt rá szükség. Kérdés az volt, hogy jó, de az új rendszer az mit tudjon. Pont ez volt a válasz, hogy amit az előző.

Az előző rendszert, azt, hát nagyjából aki bevezette, az sem volt a cégnél, meg az utódja sem, meg az azt követők sem. Tehát hogy ez esélytelen volt, dokumentáció nem volt. Egy olyan technológia, amire viszonymérsékelt volt már a szakértelem, ami elérhető.

Úgy a világban.

Igen.

Még talán, de hogy mondjuk Európa ezer részén, az biztos. És akkor mit lehet tenni? És akkor az volt a megoldás, hogy jó, tegyük fel, hogy holnaptól nem működik, kihúzzuk a falból a kábelt, lekapcsoltuk, hol fog fájni. És akkor onnan kezdtük el feltérképezni, hogy mi az a működés, amire egyébként szükségünk lesz akkor is, hogyha ez a rendszer már nem lesz. És így néhány funkciót össze tudtunk írni, ezekre mindenképp szükség lesz. Jó, akkor ezekhez próbáljuk meg valahogy kinyerni az adatokat, és egy olyan rendszert készítsünk, ami ezekből az adatokból, meg a funkciókból tud működni. Mert amire szükség van, azokat összeírtuk, az adatokat ki tudtuk nyerni, és lehet kapcsolni a régi rendszert.

Az az érdekessége, hogy amit mondasz, hogy nálatok is eljött az a pillanat, hogy egyszerűbb kihúzni. Tehát, hogy van egy ilyen mondás, és mennyire gáz már, azt nem tudom szebben kifejezni, és nem is akarom. Mennyire gáz már egy cégnél azt mondani, hogy idáig sem kellett volna rendszer, mert már rég áttértetek papírra. Tehát voltaképpen azzal találkoztatok már? Bármelyikőtök találkozott már olyannal, hogy kihúztátok a rendszert és az alternatív Excelek működtették a céget. Senkinek nem hiányzott maga az ERP vagy a CERE. Annyira béna volt és annyira rosszul volt összerakva, hogy már senki nem használta, csak adatot rögzítettek benne.

Nekem azért nem, mert valahányszor ilyen rendszer volt egy szervezetben, ahová engem is hívtak dolgozni. Mindahányszor az a szervezeti egység, aki ezen a rendszeren volt üzleti, gazdai szerepben, az a végsőkig ragaszkodott hozzá, hogy ez nagyon fontos rendszer, mert egyrészt a saját fontosságát látta benne, másrészt meg senkinek nem merte volna elmondani azt a helyzetet, hogy ő igazából nem is használja, mert az nagyon ciki egy nagy szervezetben. Valószínűleg egy KKV-ban mások a dinamikák, de én többnyire nagy szervezetekben láttam ezt. Most egy kicsit in medias rescue-t, ahogy mondani szokták, ahogy belecsaptunk a lecsóba is. Így a hallgatók nem annyira tudják, hogy Péter hogyan is kezdte a pályát.

Azt azért elárulom, talán nem egy titkos kulissza, hogy tanárember vagy, eredetileg, informatika tanár, tehát azért nem tudom, annyira nem áll távol tőled akkor sem ez a világ. Aztán újságíróként is dolgoztál, úgyhogy így igazából ez a podcastos világ, ez innen már csak egy lépés. Körülbelül egy évtizeddel ezelőtt, egy bő évtizeddel ezelőtt, amikor már volt iphone, meg amikor indult a Whatsapp, meg az Instagram, te akkor gondoltál egyet, és IT projekt tanácsadó, vagy projektvezető lettél, igaz? Hogy amikor meglépted ezt a váltást az újságírásból így az üzleti szférába, akkor gondoltad volna, hogy ez mit fog jelenteni mondjuk így a következő évtizededre?

Volt, amit sejtettem.

Mint a pályaválasztásoknál ez jellemzően az szokott lenni, hogy amikor úgy láttam, hogy több fantázia van egy másik, vagy legalábbis közeli pályán, akkor ott folytattam. És ez igaz volt, amikor átmentem versenyszférába, tehát amikor ezt az IT tanácsadást kitaláltam magamnak, akkor ebből azért Magyarországon nagyon kevés szakirodalom volt. A tervek képzése gyakorlatilag nulla, majdnem nulla. Olyanokat megkérdezni, hogy nagyon lehetett, mert olyan emberek se nagyon voltak, akik ezzel foglalkoztak volna. Az angolszász, mondjuk szakirodalom állt rendelkezésre, illetve angolszász képzések. Ez néha érződik az attitűdömön is, hogy nem az a tipikus, mondjuk, közép-európai, inkább angolszászabb módon állok problémákhoz.

Ez a szakterület tényleg az elmúlt 5-10 évben lendült fel nagyon itthon. Amit akkor gondoltam, az a piacra vagy a szakterületre nézve szerintem most is igaz, mondok pár példát. Ami a hazai gazdasági specialitások, amik tényleg eltérnek mondjuk egy amerikai tavalyi franciától, azokra nem számítottam akkor, de nehéz is lett volna számítani.

A név nélkül.

A rózsaszín világban nagyon erős a problémaközpontúság. Tehát az, hogyha valami nem működik, akkor mondjuk ki, hogy nem működik, üljünk le, találjunk rá megoldást. Mondjuk Közép-Európában vagy Magyarországon nemcsak a probléma szokott lenni az, amit meg kell oldani, hanem megoldhatjuk, igen, kivezethetjük a rendszert, bevezethetünk másikat, de mit fog hozzá szólni a szomszéd? Mi lesz akkor, és egyébként az osztályunknak a súlya a többi osztályhoz képest az hogyan fog változni. Ja, és akkor mit gondolnak rólunk mások? Na most ezek ilyen tágabb értelemben politikai kérdések, amiknek a szűken vett IT problémához pont nulla köze van, és az a fajta attitűd, hogy igen, akkor itt kell valami három zsák alapot kivinni, akkor gyertek hárman, mindenki fog egy zsákot és vigyük arrébb.

Ez ott működik. Hát itthon nem mindig ez a típus, azt hiszem, ezt mondhatom.

Milyen érdekes, hogy ugye az amerikai Gohlman írta meg a világsikerű érzelmi intelligencia munkáján, azt hiszem, ez a magyar címe könyvét. Angolszászként, miközben egyébként szerintem az érzelmi intelligencia szerepe a magyar cégeknél ötvenszer nagyobb, mint az amerikai.

Fontosabb, igen. Egy picivel fontosabb nem gyűjtménynek lenni egy cégnél.

Igen, és akkor mi az, ami mondjuk hasonló és megmaradt, az az, hogy ebben az IT tanácsadásban is több minden van. Ugye tanácsadás alatt azt szoktuk érteni, hogy külsősként megoldunk problémákat, tanácsot adunk az ügyfélnek, hát legalábbis megoldunk neki valamilyen problémát. Ennek az egyik klasszikus esete és az utóbbi időszakban tényleg nagyon nagy igény kezdett jelentkezni efelé, ez az üzleti elemző. Én is ekként kezdtem. Ez az, akiről itt az én területeimen beszélgettünk, hogy próbálja megérteni, hogy mit akar az üzlet. És üzlet alatt én most a MIT-t értem. Milyen problémát akarnak megoldani? Mi az, amit szeretnének, hogy tudjon? És akkor ez a klasszikus kérdés az szokott lenni, amikor üzleti elemzőként voltam egy projektben, hogy tegyük fel, hogy nem IT oldja meg a problémát.

Tegyük fel, hogy papíron, kőtáblán mindegy, meg kell oldani ezt a problémát. Hogyan működne a folyamat? Mire lenne szükség? Az, hogy most ezt egy kőtáblába véssük, papírra írjuk, vagy egy tetszőleges IT megoldásba, az egy technikai kérdés. Az az üzlet a cég működése szempontjából majdhogynem mindegy, mert az a lényeg, hogy kell két jóváhagyó, és két jóváhagyó, hogy hagyja jóvá, az oké, megoldja az IT, de akkor feladat az, hogy legyen két jóváhagyó. Nem az a feladat, hogy vegyünk egy dobozos szoftvert, legalábbis általában nem ez szokott lenni a cél függvényében.

De az olcsóbb.

A célfüggvény, az az olcsósággal függ össze.

Igen, de mit tudjon a doboz a szoftver? Tehát hogy először derüljön ki, hogy mit akarunk. Tehát ez az üzleti jellemző, aki ezt az igényt megpróbálja valahogy ledokumentálni.

Például a projekt arra is kevesen szánnak pénzt vezetők közül, hogy az üzleti elemzőt megfizessék. Most ezt KKV-ra is mondom, tehát KKV-ban kifejezetten tudok rossz arcokat mondani, akik azt mondják, hogy na nem, ne gondolja már Zoltán. Ezek a kedvenc mondataim, ne gondolja már Zoltánnak, ne gondolja már Zoltánnak, ők rendelkeznek három könyvelő szoftverrel, tizenkét dobozos próbálkozással, harminckét kivesézett kifilézett tanácsadóval, és egyébként a marketinges cégük oldja meg az összes IT-st, a számítógépes, tehát a számítástechnikus, a számítástechnikus az legyen ott, és a számítástechnikus a telefon beállítástól a tűzfal konfigurálásig mindent is tud, és az ő tanácsai alapján tud működni a dobozos szoftver bevezetés is.

Igen, ez egy gyakori probléma. Ugye az az egyik ilyen kedvenc mondásom erre, hogy showba kerül a szakértő. Igen, de még többe kerül, ha nem szakértő csinálja meg. Tehát bármelyik problémánál fölmerülhet, hogy volt olyan projektem, nem volt üzleti elemző. Nem volt leírva, hogy mit akar a projekt. Közben derült ki, hogy ja, hát egyébként ezt is szeretnénk. Jaj, a fejlesztő nem tudná még ezt megcsinálni?

Hát ezt még beleképzeljük.

Jó, hogy férjem, ugye?

Bele kéne, hogy férjem, ezzel találkoztatok?

Az egyik fele a másik meg, hogy és minek. Tehát hogy mit szeretnénk, hogy tudjon. Hát körülbelül ezeket. Jó, megcsinálják, letesztelik ezt, tudja, igen. Ja, nem erre gondoltunk. Tehát az üzleti jellemző az nem vízből van kitalálva az iparági sztenderdek szerint. Ez az egyik célja, hogy egy híd szerepet képezzen az IT meg a MIT között. Szintén tanácsadói terület, és nekem ez lett a következő üzleti elemzés után. Ez a projektvezető, aki meg foglalkozik az üzleti elemzővel, az üzlettel, meg az IT-val is, meg még a többi szereplővel, aki még ennek kapcsán fölmerült, de jellemzően az üzletem, meg az IT projektben az IT-val, hogy legyen precízen meg, hogy mit szeretnénk, mert az IT és akkor ez szintén a korábbi kérdésre is egy válasz.

Az IT nagyjából bármit megcsinál. Tehát olyan, hogy az IT nem tudja, ilyen gyakorlatilag nincs. Tudom, vannak olyanok tudomány szerint, de hogy jellemzően nem fordul elő olyan, hogy az IT-nél tudná, kérdés az, hogy mit szeretnénk megoldani.

Ha már Ricsit említettük, korábban Ricsivel volt egy podcastom, ahol lehet hős a rendszergazda, és ezt szeretném egy picit ilyen Dezsőnek visszahozni, hogy biztos? Ezt kérdeztem ma már tőletek. Biztos, hogy mindent az IT-nak kell tudnia. A cég működését az IT-nak fejben kell tudni tartania, és ezzel a gondolattal kell tudni bevezetni egy szoftvert? Hol csinálhatja az IT? Nem feltétlenül az ő dolga, meg csinálhatja az IT is, csak ez megint az a kire bízunk mit? Például egy ilyen határterület, folyamatszervezés, folyamatfelmérések, üzletjellemzők, őket hova rakjuk egy szervezetbe. Sok szervezet azt mondja, hogy ez ilyen majdnem IT, IT például úgyis szükség van rá, tegyük be az IT szervezetbe.

Tehát minden rovarbokár.

Igen. Van olyan szervezet, amelyik azt mondja, hogy ők még nem programoznak, akkor nem IT, és akkor valami üzleti területhez szétosztják őket. Van olyan, amelyik azt mondja, hogy ez ilyen projektekhez mindig kell, a többieknél változó, legyen önálló terület, és akkor valami projektirodára, vagy valami köztes területre önálló szervezeti egységként hozza létre ezt az egységet, és akkor hozzájuk téve mondjuk IT act-eket, akik szintén nem muszáj a projektbe, de hasznos, ha van, mert vannak olyan kérdések, amiket ő ért hozzá őt a múlt, neki van ember rutinja, hamarabb meglesz, és főleg magasabb minőségben, hogyha bevonunk ilyet. Persze mindenki építhet házat, de egyszerűbb, hogyha olyanokra bízzuk, akiknek van ebben szakértelmük.

Emlékeztek Robin Williamsre?

Neki egyébként volt egy másik műfaja is, ő standup volt, amikor még ez nem is volt egyébként akkora nagy cucc, ilyen másfél órákat nyomott a New York-i színházakban, és én ezt nagyon szeretem vissza-visszanézni. Van egy fantasztikus kis 4-5 perces sztori arról, hogy hogy találták fel a skótok a golfot. Ebből idéznék most egy részt, hogy ugye ott van a kis luk a zászlóval, a kezedben a golfütő és ott a labda, és akkor be kell ütni. Tök egyszerű lenne, igen ám, de én kitaláltam a tutit, mondja a részeg skót. Telerakom a pályát pakrokkal, fákkal, árkokkal és tavakkal, hogy jó nehéz legyen. Tehát, hogy körülbelül így látom én egyébként az IT-sok szerepét a cégben, hogy ő náluk van a golfütő, ők pontosan tudják, hogy hogy kell beütni a labdát abba a lukba, csak a szervezet körülöttük, az tele van fákkal, bokrokkal, árkokkal és tavakkal, amikhez igazából nincs támogatásuk, hogy ezen hogy keljenek át, és akkor ottan próbálják a lehetőségek megfelelően megfelelni.

Ez kötelező minden szoftverhez, szoftverbevezetéshez kötelező egy pszichológus, aki az IT-sokat fogja kezelni az üzlet miatt.

Bocsánat, drága pszichológus, de még drágább, ha nincs, ugye?

Igen.

Akkor azt hiszem, hogy most itt ez egy jó pillanat arra, hogy egy személyes kérdést is tegyünk. Ez nagy hagyománya a Tigit Podcastnak, hogy itt nemcsak a témák, de a vendégek mélyére is ásunk.

Az lenne a kérdésem, hogy ha jól tudom, neked nagy hobbid a sakk, és nem csak játékosként foglalkozol vele, de hogy bíróként, meg versenyszervezőként is. És hogy egyrészt miért van az, hogy te bíróként és szervezőként is sakkozol, meg hogy ennek így a képességek, meg a hozzáállás szempontjából van-e átfedése a munkáddal.

Hogy lettem bíró, azt hiszem, az egy régebbi történet. Középiskolásként nagyon NB II-es szintig tudtam vinni, és ott kiderült, hogy hát vagy egyetemen folytatom, és a későbbi hivatásaimmal foglalkozom, vagy az élsport felé, és ez most nem muszáj sakk, bármelyik sportágat ha vennénk az élsportot, az egy teljes állásnak felel meg. Na most véges mennyiségű időm volt. Én úgy gondoltam, hogy azokat a területeket tanulmányozom inkább, ami a későbbi hivatásomat jelentette. Emellé nem fért bele annyi tréning edzés, bármi verseny, ami a sakkbeli előrejutást segítette volna. Viszont arra volt lehetőség egy ismerősöm kapcsán, hogy versenybíróként folytassam. Benne maradtam a közösségben, és jóval kevesebb energia szükséges ahhoz, hogy ezt tudjam vinni.

Ennek a haszna az ugye jogszabály-megfelelőségi projektekből jött, mert ugyanúgy a szabályokat kell betartatni a szereplőkkel, és ezt egy ilyen nagyjából húsz évig vittem aktívan a nemzetközi versenybírói szintig, és az utóbbi pár évvel ezelőtt volt az, hogy azt láttam, hogy a versenybírói lehetőségek, azok szintén, ahogy a pályaíveim váltásánál. Ha nem is felülök korlátosak, de mondjuk nem látok benne akkora továbblépési lehetőséget, mint ami eddig volt benne. Egyrészt, másrészt, hogyha egyébként IT-ban projektvezetek, akkor milyen lenne a sakknak is ezt a részét jobban megismerni, és akkor elvégeztem a nemzetközi versenyszervezői képzést, és azóta inkább a szervezői oldalon élnek meg, ami abban segít egyébként, hogy az absztrakt részét megértenénk.

Tehát az, hogy most projektet vezet az ember, rendezvényt szervez, végül is a versenyszervezés, vagy rendezvényszervezés, rendezvényt szervez, vagy bármi más, nagyon hasonló absztrakt szinten. Mindegyiknél tudni kell, hogy mit akarunk elérni evvel. Tudni kell, hogy mi az a célállapot, amit kívánunk a projekt révén, hogy megvalósuljon. És össze kell ehhez tudni szedni az erőforrásokat, majd rá kell venni azokat, akik ebben szereplők, hogy valósítsák meg azt a tervet, ami azokból az erőforrásokból, amit megálmodtak a projekt kezdetén.

Érdekes ez a dolog, tényleg ez a jogszabályi megfelelés is, meg egyáltalán a projektvezetés is. Szélénkhangárban szoktam adni feladatokat. Az egyik feladat, amikor a projektcsapatokra osztom a résztvevőket, és ugyanazt a feladatot csak két csapatnak kell megvalósítania, még idáig senkinek nem sikerült egyszerre egy időben befejezni. Maga a vezetőképzésnek az egyik feladata az a közös nyelv kitalálása. Ha nem definiálok közös nyelvet, hogy hol és mikor beszélgethetnek, de elmondom, hogy beszélhettek. Az a szabály, hogy nincs szabály, ezekből szoktak a legszebb félresikerült projektek lenni, merthogy nincsenek szabályok, és mégis szabályokat kéne alkotni. És a szabályok megalkotásának a hiánya az, ami elsősorban definiálja azt, hogy miért nem tudnak megvalósítani mondjuk egy óra alatt egy közös feladatot, és legyen ez egy LEGO tárgy építése, amit egyébként napi szinten gyártanak mondjuk a telefoncégnél, ahol ezt a feladatot adtam, ott konkrétan azt kellett megoldaniuk, amit napi szinten gyártanak, két projektcsapat rakja össze Legóból.

Nem sikerült.

És sakkfeladatokat szoktál adni?

Vagy egyáltalán a sakkhasználat megjelent valamikor?

Van meg, de hogy nem úgy jelenik meg, hogy vitorlázás, tehát hogy a vitorlázásban nálam a sakk, az gyakorlatilag, hogy melyik erőforrásodat hova mozdítod el, és hogy miért pont a futót indítod meg, vagy miért pont gyaloggal ütsz és miért gyaloggal véded le? Tehát, hogy most a vitorlázásra lefordítva ugyanezt a mondatot, vannak bizonyos helyzetek, ahol ki kell fognod a szelet a másiknak a vitorlájából, hamarabb fordulsz, vagy később fordulsz. Úgy húzod föl a hátszeles vitorlát, és próbálod meg úgy manőverezni, ezáltal téged is és a másik hajót is elvinni egy másik pozícióra, irányra, és onnan megindítani a támadást. De az alapvető cél az az, hogy te, a teljes pályán az összes változóval együtt a leghamarabb fussál be és nyerd meg ezt a versenyt.

Sakkban azt gondolom, hogy ez a matt.

Lényegében igen.

Laci, neked van valami sakk sztorid?

Van. Én diákkoromban sakkoztam, egyébként a nagyfiaim most is sakkozgatnak. Felnőttként nem folytattam, de diákként csapatban sakkoztam Fóton, és nagyszerű edzővel, meg srácokkal, és az életem egy nagy tanulsága volt, amikor diákolimpián bejutottunk az országos döntőbe, és ugye a csapatverseny eltérő időkben mennek a partik. Nekem egy viszonylag hosszabb partin volt, így már többen ott álltak körülöttem, és egy erősebb ellenfél ellen játszottam, merthogy én magam egyébként valószínűleg pont a betett energiával arányosan nem voltam azért egy olyan óriási ász egyénileg, de jobban álltam, és az erősebb ellenfél fölajánlotta a döntetlent. Azt nem fogadtam el, mert jobban álltam, gondoltam, hogy még itt egy kicsit a futóval, ahogy mondanád, és kikaptam.

Kikaptam, ami pontosan azt a fél pontot jelentette a döntetlenhez képest, amivel másodikak lettünk a csapattal. Ha azt a döntetlent elfogadom, akkor elsőként állunk föl. Na, ez egy életre megtanította nekem, hogy mi az, hogy csapatjáték. Azt hiszem egyébként ez a többi sportban is igaz, hogy nagyon sokat tudunk a munkaéletünkben is tanulni róla. Na most, ha megfelelőségi projektekkel szűkítjük, mert nyilván nagyon sok IT projekt van, de hogyha a megfelelőségit nézzük, akkor én ott azért érzek áthallást tényleg a sakkjátszmákhoz, vagy a sakkjátszmákkal, mert hogy mintha oda-vissza győzködné egymást a technológiai világ. Most itt gondolok különösen az új technológiák világára, a mesterséges intelligencia a chatbotokkal az élen, az IOT, akkor majd nyilván a kvantumszámítógépek, meg egy sereg ilyen új technológia, meg a jogszabály alkotók, akik ugye próbálják ezeket korlátok közé szorítani, megpróbálják a tisztességtelen versenyt megakadályozni, meg az etikátlan használatot megakadályozni, és hogy szerintem minimum két ilyen terület van most a nagy fókuszban, az egyik a mesterséges intelligencia, a másik meg a fenntarthatóság és az ESG szabályok és megoldások világa.

Neked van-e ezekkel bármilyen sztorid tapasztalatod, amit így a hallgatókkal megosztanál?

Pont ilyen projektem nincsen, tehát most teljes kis projektem nincsen, vagy fenntarthatóság. Egyébként fontos üzleti szempontból, de hogy ehhez kapcsolódó IT projekt kevésbé van, azt összességében azért el tudom mondani, hogy jellemzően az IT van előrébb. Tehát ha kitalálnak valamit adott területen, hogy van egy jó műszaki megoldás adott problémára, akkor ki kell érnie annyira az adott megoldásnak, hogy felkeltse a jogalkotó figyelmét. Hogy egyrészt ezzel milyen problémák merülhetnek föl, illetve hogyan lehet ezzel visszaélni, amit szintén célszerűbb lehet szabályozni. Most, hogy vannak-e új európai uniós jogszabályok, amik arról szólnak, hogy hogy kell IT biztonságot szabályozni, de azért kell szabályozni, mert kiderült, hogy ebből milyen problémák merülhetnek föl, ha nincsen szabályozva.

Tehát a rotterdami gátnál tudtátok-e, hogy pont azért, hogy az emberi faktor ne legyen bizonytalan egy ilyen helyzetben, rábízták már a mesterséges intelligenciára és az előrejelzésre, és a hallgatóknak a mostani kérdése az az, hogy mikortól van ez így, hogy magát a gát bezárását, ami milliárdokba kerül, hogyha bezáródik, mikor bízták számítógépes előrejelzésekre és modellekre. Merthogy projektvezetés szempontjából ez egy baromi érdekes kérdés, hogy egy ilyen helyzetben, amikor a családod miatt te elkezdesz rettegni, pszichológiailag is van rajtad egy nyomás, megnyomsz egy gombot, vagy nem nyomsz meg egy gombot, korábban nyomod meg vagy később nyomod meg a gombot, mint ahogy kell. És az az érdekessége a dolognak, hogy bizonyos helyzetekben a mesterséges intelligencia és az automatizáció az pont emiatt kezdett el bejönni, hogy ne kelljen az emberi ilyen típusú felelősséget magára venni annak az embernek, aki megnyom egy gombot.

Laci, te voltál most Bécsben, és ott mit tapasztaltál? Kicsit mesélj már erről a konferenciáról, vagy ahol voltál, mert azért ennek volt a mesterséges intelligenciához köze. Igen, Bécsben a Magic of Innovation konferencián voltam, ez egy biztosítási innovációkkal foglalkozó európai esemény, egy-egy afrikai csáppal, lábbal. Egyébként egy magyar származású hölgy, Krizsán Erika szervezése, most volt kilencedik éve, hogy ez van. És amellett, hogy a Future-val mi közvetítjük az online térben az eseményt, amellett nekem ugye ez abszolút szakmai csemege. Két-három nagyon fontos topik volt. Az egyik, ami leginkább a biztosítási vonal az, hogy igyekeznek áttérni a biztosítási események, vagyis károk jellemzően bekövetkezése utáni ügykezelés hatékonyításáról, meg fejlesztéséről, a biztosítási események, károk megelőzésében nyújtott támogató szolgáltatásokra.

Ez egy óriási szemléletváltás, mondatban is bonyolult, de hát még egy szervezetet így átirányítani fókuszban. A másik ilyen nagy téma, hogy hol lehet mesterséges intelligenciát használni, és hol szabad mesterséges intelligenciát használni egy olyan intézmény esetében, ami alapvetően a bizalom köré épít. Tehát, hogy azért használunk biztosítót, mert abban bízunk, hogy segít, amikor kell, és akkor a harmadik meg ez a fenntarthatósági kérdés, ide értve különösen a klímaváltozást, meg úgy egyáltalán az összes természeti, környezeti kárnak az előrejelzését és becslését, és az egyre növekvő, sajnos egyre növekvő hatását. Itt is óriási innovációk vannak egyébként ebben az előrejelzés meccsre, és terén sokkal pontosabb modellek, satöbbi, áradásokba sem akarok belemenni.

De ugyanakkor ott van a kommunikációs részben is a mesterséges intelligenciának a szerepe, hogy amikor mondjuk van egy ilyen valószínűleg bekövetkező áradás, mondjuk akkor azt hogyan tudom kommunikálni, nem hívhatom fel egyenként az összes ügyfelet. Úgyhogy ott is nagyon sok szempont van, és akkor még nem beszéltünk arról, hogy magának a biztosítónak az ökológiai lábnyoma az most pozitív vagy negatív. Ez egy nagyon spéci állatfaj, szóval hogy ez egy összetett, izgalmas esemény volt, de hogy én például érzek egy ilyet, különösen nagyvállalati környezetben, hogy valóban előrébb jár a technológia, és elkezdték alkalmazni is a technológiát a nagyvállalatok, bevezettek különböző, például EMMI alapú mesterséges intelligencia alapú szoftvereket, és ezeket az ügyfélkiszolgálási folyamatba is beépítették, nem csak hátul statisztikai jelleggel, és már volt ilyen sztori, ahol komoly bírságot kaptak utána belőle, mert nem teljesen megfelelően építették be.

Ez egy dolog, mert az az akkori jogszabálynak nem megfelelt, tehát hogy az egy olyan dolog volt, amiről tudhatott volna a szervezet, hogy nem jól csinálják, de én egy olyat is érzek ebben, hogy most jön egy újabb hulláma ezeknek a jogszabályoknak, ami új környezetet teremt, és a bevezetett megoldásokhoz azért kell majd hozzányúlni, mert az új jogszabálynak nem fog megfelelni. Te érzel egy ilyen feladatkupacot így gördülni lefelé a képzeletbeli havas hegyoldalon?

Igen, igen, és látni is. Látom, hogy például az egyik ilyen, ami már megjelent EU-s rendelet, ez az úgynevezett Dora-rendelet, az IT biztonsággal kapcsolatos adminisztrációt változtatja meg, főleg nagyvállalatoknak. Vagy ugyanilyen a PSD2-ről sokan hallottak. Már folyamatban van a PSD3-mal kapcsolatos előkészítő munka.

Ez a hallgatók kedvéért a Payment Services Directive, tehát a fizetésforgalmi szabályozási környezet.

Akkor egy picit, ha két ilyen nagyon jó szakember ül velem szemben, akkor legyetek szívesek azt elmagyarázni a hallgatóknak.

Igen.

Értem.

Amikor niseztek, meg dorásztok, akkor az is micsoda, jó? Tehát hogy mikortól számít, tehát a hallgatóknak annyit adnátok-e annyi plusz információt, hogy melyik vállalatnál ülve figyeljenek fel ezekre a szavakra, amikor gyöngyöző homlokú informatikusok nincsenek a folyosón, az nem káromkodás.

Igen, tehát amit szerintem úgy tudunk mondani, hogy nemcsak a szűkebb szakmát lelkesíti. 2025-től lesznek bizonyos adminisztrációk arra vonatkozóan, jellemzően nagyvállalatokról beszélünk itt egyébként, hogy a különböző beszállítóikra vonatkozó adatokat kell összegyűjteniük, illetve a különböző IT tevékenységekkel kapcsolatosan további dokumentációkat kell előállítani. És ezen jellemzően nagyvállalatokra, ez a Digital Residence-nek a rövidítése.

Adora. És ugye ennek volt egy előző szabálya, ez a Ni is, most nem tudom, minek a rövidítése, ha feloldjuk. Ez egy EU-s rendelet, és hát még van két év, sőt vannak olyan, ugye az EU-s szabály, tehát még a magyar jogalkotóknak is van ebből feladatuk, hogy a kapcsolódó törvényeket, rendeleteket meghozzák, amikhez még van idő felkészülni, hogy hogyan is értelmezzük Magyarországon az adott EU-s előírást, tehát még ez országonkénti jogalkotói feladat, és utána lesz az, hogy hogyan lehet ennek megfelelni. Tehát alapvetően IT biztonság és alapvetően nagyvállalatokról beszélünk.

Az az érdekes és még egy dolgot, amikor a 2025, mint szó elhangzik, én gyakorlati tapasztalatból tudom nektek mondani, hogy ja, hát ez még akkor van rá időnk. És most visszakérdeznék ennél a dolognál, hogy mit gondoltok, hogy egyébként ennek a felülvizsgálata is egy jó projekt mennyi időt vesz igénybe?

Amennyi rendelkezésre áll, azt tudjuk, de most a Gödöllői Egyetemhez kötődve én is tudom, hogy mennyi idő alatt lehet levizsgázni, tehát hogy már úgy értem, hogy a zárthelyihez tartozó vizsgaidőszak. Miután megtudtad az információt, hogy te tíz perc múlva mész zárt helyezni, bizonyára fel tudsz készülni, de, hogy ez nem egy jó hozzáállás, hanem egy kényszer szülte. Tehát én valahol ezt szeretném egy picit, hogy belőjétek a hallgatóknak, hogy ülünk a nagyvállalati vezetői székünkben, látunk már gyöngyöző homlokú informatikusokat, akik azt mondják, hogy 2025, de ekkor még kérjük a második kávét. De meddig van időnk kávézni? Tehát hol jön el az a pillanat, amit még azt javasoltok, hogy érdemes erre fordítani?

Erre azt tudnám mondani, amit Kállay örökbecsű színészünk a meseautóban a telefonba mondott, hogyhogy még megisszák a kávéjukat, itt mindjárt vér folyik. Mi az, hogy nincs homok? Nem hisztéria a sztorija, szóval hogy azt látom, hogy van erre egy nagyon szép angol kifejezés, a Suns of Eargency, tehát az az érzet, hogy mennyire ég a körmünkre a gyertya, szép magyar örökké becsült kifejezésünkkel. Ez különbözik a szervezet különböző pontjain. Egy nagyvállalatnál mindenképp egy KKV-ban még lehet, hogy 20 embert képes vagy menedzserként egy szinten tartani ilyen körmünkre ég érzetben, de egy nagyvállalatban szerintem ez képtelenség. Vannak olyan szereplők, akik általában úgy érzik, hogy sürgetőbb, ezek tipikusan a jogászok és az informatikusok.

És vannak olyan szereplők, akik meg úgy érzik, hogy hát végül is van sürgetőbb is, mert 2025 az messzebb van. Ezek tipikusan a területi vezetők, illetve személyiségtípus válogatja, de a felsővezető. De egyébként az, hogy a jogász már minden héten dörömböl az ajtón a 2025-tel, az nem véletlen, mert őneki ez a szerepe. Tehát, hogy ő az, aki először megtudja, hogy lesz egy feladat. Ő már akkor megtudja általában, egy pénzügyi világban tipikusan akkor megtudja, mikor még meg se született a jogszabály, mert ezeket a szektorral, bankszövetségen, egyebeken keresztül egyeztetik. A KKV-ban ilyen információforrások általában nincsen, a konferenciákon szoktak néha arról beszélni a jogászok, hogy nemsokára születik egy új jogszabály, de ezt a KKV vezető is fenntartásokkal kezeli, mert lehet, hogy a jövő havi béreken jár az esze nagyon sok esetben.

Az informatikus meg azért szereti sürgetni a dolgokat, merthogy nem érti, hogy mekkora a feladat, és szeretné azt az erőforrást ráfordítani, ami kielemzi az üzleti elemzőt, meg az architektet, számolják ki, hogy ez mekkora munka lesz. És akkor majd megnyugszom, hogyha az nem olyan nagy. De hogy annyiszor látott már egy informatikai szakember, meg akár az informatikai vezető annyiszor látott már bonyolultabb feladatot, mint ami első látásra tűnik, hogy retteg attól, hogy 2025-ig lehet, hogy van még másfél év, de lehet, hogy ez egy két éves munka, ha most egy picit az aktualitást is behozom, akkor Ferrari ismét nyert. Mr. Ford előszobájában ülve látom a piros dossziét, ugye Ford Versus Ferrari, csak hogy legyen ma is egy filmes példánk, és hogy ki okozza a piros dossziéban ezt a szégyenletes vereséget, tehát átmegy csomó osztályon, mi tudjuk azt, hogy ez meg fog történni vagy be fog következni és szólunk.

Hát egyébként, amit említettél, ez a különböző érzékelése a kritikusságnak. Erre jó például egy projektvezető azon kívül, hogy összefogja a munkát. Tehát, hogy látja, hogy a különböző szervezeti egységeknél hogy van ez az érzékelés, és segít ezeket szinkronba hozni. Az egyik része. A másik, és tényleg volt olyan, ahol egy kétéves projektet kellett fél év alatt megoldani, és valahogy meg lehet oldani. És erre mondtam azt, hogy az IT-vel elég sok mindent meg lehet csinálni. És ez az erőforrás kérdése az anyagiaknál. Nagyvállalatoknál tipikus az, hogy megoldható-e időn belül ez a feladat. Úgy értem, hogy sokkal kevesebb időn belül, mint amennyi normális esetben kéne, de most ez hirtelen nagyon sürgőssé vált.

Igen, megoldható, vagy úgy, hogy akkor a kollégák mással nem foglalkoznak, most mindent félreteszünk, ezzel foglalkozunk, vagy úgy, hogy szerzünk külsős kollégát, és akkor a külsős szakértők bevonásával megoldjuk. Vagy, és akkor itt vannak egyéb jogi megoldások, mert sokszor az is megoldás, hogy azt mondja a cégvezető, hogy van egy nem tudom, vezetőségi döntés, hogy a cég viszi ezt a kockázatot. Lehet ilyet is, tehát ez is egy megoldás bizonyos esetekben. De ezt meg kell hozni ezt a döntést. Volt olyan projekt, hogy nagyvállalatban több projekt versengett az adott véges mennyiségű erőforrásért, hogy kié valósuljon meg.

Volt ilyen?

Sose hallottam még ilyet.

És az adott.

Bár megérte a Péter.

A '60-as szervezetben erre késhegyre menő viták voltak, hogy most, de kihozza azt az egy szem fejlesztőt, és már a külsősök elfogytak, de hogy a külsős cég erőforrásait hogy kötik le a projektek, ezen ment a vita. Mert a külső cégnek is véges mennyiségű erőforrása volt. És akkor volt pont egy ilyen projektem, hogy hát milyen kis fontos. És akkor jó, de az övé az nagyobb, és akkor körülbelül ezen már hasonló jellegű viták voltak, hogy ki mekkora projekt, és itt volt az a kérdés, hogy jó, semmi gond, ez egy jogszabálymegfelelőségi projekt. Ennek ez a kockája, ha nem csináljuk meg, akkor ekkora bírságot kapunk. Ha ez be van kalkulálva, akkor viheti az erőforrást a másik projekt, mert akkor ezt menedzsment úgy döntött, hogy ezt a bírságot inkább kifizeti.

Vállalható kockázat.

Igen.

Azzal, hogy nyilván meglesz az, csak nem határidőre, hanem egy kis közvetlen ellenőrzés, akkor az sokba fog fájni, de hát ezt akkor ők vállalták.

Ez azért nagyon érdekes, mert egyébként én látom az evolúciót ebben is, tehát hogy az elmúlt tíz évben a jogszabályalkotók is megértették az idők szeleit és az informatikai és digitalizációs világnak a működését ilyen szempontból, hogy erőforrás-gazdálkodás zajlik, és gyakorlatilag ők maguk is ráálltak erre, hogy kinek, melyik jogszabály alkotónak a projektje vagy melyik jogszabályi területnek a projektje lesz majd az országban, vagy Európában a fontosabb, és a szankciós listát, bocsánat, ez most mást jelent, tehát a lehetséges szankciók listáját és mértékét stromfolják egyre magasabbra, hogy az övék legyen az, amit mindenképp megcsinál a tisztelt nagyvállalat, és majd a másik jogszabály lehet, hogy később lesz.

Nem, nem érzitek ezt, hogy egyre magasabbak a bírságok, de azért, hogy előre kerüljenek a fejlesztési sorban.

Bizonyos értelemben igen, de ugye itt nagyon sokszor arról is beszélünk, mert nyilván nagyvállalati tulajdonosok, meg felsővezetők mellett, amikor tanácsadó az ember, akkor hasonló kérdéseket föltesznek nekem is, hogy most itt van 15 IT projekt, ezt melyiket javaslom, hogy mégis priorizálják be. Erre szoktam mondani, hogy egy ilyen kockázati mátrixot, hogyha tudnánk csinálni, aminek nem csak egy alkotóeleme van, hanem több alkotóelemből csinálok egy mátrixot, ami viszont már egyszerű. És akkor abban már lehet mérlegelni, meg határidőket, netán büdzséket hozzárendelni, mert ezzel a kiváló büdzsétervezéssel is az a probléma, hogyha váratlan időben jön egy olyan projekt, ami hirtelen magas prioritást kap, az lehet, hogy beborítja a céget.

Ugye menedzserként, vezetőként ettől fél az ember, hogy melyik időpillanatban kapok egy olyan projektet, ami kötelező jellegű, be kell vezetnem, de se erőforrásom, se pénzem nincs hozzá, de még jobb bevétel sem fogja fedezni. A jobb esetben tudom fizetni a saját, mondjuk azt, hogy kockázati tartalék tőkémből. Ezeket a típusú fejlesztéseket, de ezt nem lehet fenntarthatóan, és ha már ESG-ről kezdtünk el beszélni, mert itt ESG-ről kezdtünk el beszélni, és ez egy nagyon fontos dolog, hogy azok a projektek, amiket most csináltok, és kockázati mátrixba szervezünk, azok is egy fenntarthatóság miatt jönnek létre, tehát fenn akarom tartani a cégemet, fenn akarom tartani a fejlődését a cégemnek, és fenn szeretném tartani a dinamikáját a cégemnek, és soha nem tudjuk, és visszatérve az elejére a gondolatnak, hogy voltaképpen én most tényleg az IT-től várom el ugyanezeket az üzleti terveket, amiről beszélünk, hogy nekem új szoftver kell, vagy három plusz ember, mert ez a kérdés.

Digitalizálok, és kiváltom három ember munkáját, vagy nem váltom ki három ember munkáját, mindenki ettől retteg. Ó, azért nem csináljuk, mert egyébként mi meg vagyunk elégedve bárkivel. De miért félünk attól, hogy egy gép dolgozik, és miért probléma az, hogy a cég fejlesztése miatt tartok meg három embert, és egy teljesen más pozíciót találok ki. Ezt most IT-soknak teszem fel ezt a kérdést.

Lassan úgy érzem, ez egy idejétmúlt kérdés, mert a legtöbb szervezetben már nem az a kérdés, hogy melyik három embert fogom kirúgni, hogyha digitalizálok, hanem az a kérdés, hogy melyik be nem töltött pozíciót úszhatom le, mert betöltöttem digitális megoldással, nincs annyi ember, mint ahány pozíció a szektorban legalábbis, a jól működő cégeknél mindenképpen. A másik meg, hogy eszembe jutott, hogy hát megint dobálózzunk egy három betűs kifejezéssel, amit nem mondtunk el.

Így van.

De hogy az ENSZ-nek az irányelve a fenntarthatóság kapcsán, az Environmental a Social és a Governance területekre, tehát a környezet mellett, meg a környezetvédelmet már kiskoromban is tanultuk, de hogy amellett most már bejött a társadalmi, meg az irányítási témáknak is a jelentősége. És akkor egyébként visszatérve a legós példádra, szerintem, mármint az egy óra alatt nem megoldható feladat példájára. Na, ott például egy projektvezető kijelölése az igen.

Jó sokat várjatok! A feladat 20 perc alatt volt megoldható, a résztvevők nem tudták projektvezetőkkel és minden szervezeti egység felépítésével és leírt magyarázattal együtt egy óra alatt megoldani. Tehát én azt szeretném elmondani, hogy van egy 20 perc alatt megoldható feladat, amihez a szervezet nem tud megfelelő módon delegálni és alkalmazkodni, részegységekre szedni és egyébként felépíteni. Tehát az a nehéz, amikor nem tudod a cég működését. Én mindig ezt szoktam mondani. Tehát ahhoz, hogy fenntartható legyen valami, ahhoz tudnom kell, hogy mit csinálok. Nem részenként kell tudnom, hogy van egy egyes Legóm.

Az a kérdés, hogy mi lesz az egyes LEGO-k összessége.

Igen, az évtizedekkel ezelőtti kísérlet volt, szintén rakjunk össze valamit. És ebben jellemzően, mondjuk, ha a németeket vesszük, a németeknél úgy választanak vezetőt. Nem tudom, hogy most, hogy van a kísérletben még ez volt a meghatározó, hogy kinek a legmagasabb a végzettsége. Mindegy, hogy milyen területről, mert akkor lenő a vezető és vigye. És mindenki igazodott hozzá. Amikor mondjuk japán vagy koreai közösségben megkeresték, hogy ki a legidősebb, és igazodtak hozzá. És hogy az ilyen típusú feladatokban jellemzően, és tudom, hogy van kivétel jellemzően, mondjuk itt a földrajzi környezetünkben az szokott lenni a legnagyobb kihívás, hogy hogyan választunk vezetőt, és általában az sehogy, az szokott lenni az ötven százalékban, a másik ötvenben meg valakit, ahogy jól van, csak haladjunk már, mert már mindenki unja.

Tehát ez a versenyző kiválasztás, ez valahogy fogalmazzunk úgy, hogy másképp működik, mint a világ sok másik részén, és ebből aztán adódhatnak kihívások, és ez, amit egyébként például egy projektvezetőnek kell kezelni, hogy valahogy őt kiválasztották, hogy vigye a projektet, és akkor most az összes felelősség és szabadság, és bármi az nála van, hogy oldja meg. És aztán, hogy mennyire sikerül, azt hiszem, meg az eredmények mutatják.

Mit javasoltok annak a vezetőnek, aki azon gondolkozik, hogy projektmenedzsment osztályt hozzon létre, új igazgatóságot hozzon létre, nevelje ki az IT-sát közgazdásznak, tehát a fejlesztést erőltesse. Számotokra mi lenne az, ami egy ideális világban, például egy következő Nora, Nis, Dora bármilyen bevezetését meg tudja úgy előlegezni, hogy a jogászok is jól érzik magukat, a gazdaság is jól érzi magát az igazgató, és jól érzi magát, és ő azon gondolkozik, hogy hogy tudja a céget fejleszteni.

Leegyszerűsítve ezt a kérdést, kell-e állandó projektvezető egy nagyvállalatban, ahol sok projekt van, ott jellemzően egyrészt kell, másrészt sok kell belőle, mert folyamatosan kell ezeket vinni, mert akárcsak a jogszabályi projektekből is több van egyszerre. És az üzleti projektekről nem is beszéltünk. Egy kisebb cég önmagában is változik annyit, mert nincsenek annyira kiérlelt, szabályozott folyamatok, meg hát nem is lehet ez a létszám miatt nem megoldható. Ott egyrészt a könnyebb alkalmazkodik, ezért nem feltétlen kell, másrészt meg esetibb jellegű, hogy most itt egy konkrét valamit meg kell csinálni, nincs ötven egyszerre futó projektjük. Van mondjuk egy, vagy kettő, néhány. Ott lehet, hogy el lehet azon gondolkodni, hogy eseti jelleggel.

Ugye ez a korosztály például, amikor a számítástechnikus rendszer gazda, bármi. Elkezdünk egy nagyvállalatot, van egy IT üzemeltető szervezeti egység, mert annyi eszközük van. Van egy kisvállalat, ahol van néhány eszköz, arra elég egy kisebb létszám. És akkor vannak olyan szervezetek, amelyek meg úgy gondolják, hogy nekik meg nem is kell infrastruktúra, mert az egészet mondjuk kiszervezték egy külső szolgáltatónak, és ez akár fizikailag, akár felhőben, akár máshogy, de a lényeg, hogy nem náluk van ez a működtetés. Ez a bérletet vegye ki vagy jegyezze a tömegközlekedés. Attól függ, hogy hányszor utazom, ha sokszor, akkor bérletet. Ha kevésszer, akkor érdemesebb jegyekből akkor venni, amikor éppen szükség van rá.

Tehát ugyanez a példa van.

Szerintem szektortól is nagyon függ. Én is abszolút egyetértek Péterrel, hogy nehéz erre általános választ adni, hogy hova tegyük vagy milyen feltételeket szabjunk a projektvezetőinknek. Talán egy szempontot még behoznék. Ez is inkább a közepes és nagyobb vállalatoknál szempont, hogy vajon mennyire szeretném menedzsmentként vagy felsővezetésként, ha a projektjeim kiszámíthatóan és hasonló elvek szerint működnének a szervezetben. Tehát mondjuk, ha beülök döntéshozóként a következő projektmeetingre, akkor mennyire számíthatok ugyanolyan előkészítettségű, ugyanolyan módon döntési pontokat megfogalmazó anyagra például. Vagy mennyire számíthatok ugyanolyan büdzsé kockázatra nagyjából a projektjeimnél.

Minél inkább szeretném egységesíteni a projektjeimnek a lefolyását és a kiszámíthatóságát, annál fontosabb, hogy ne szerteágazó projektvezetői köröm legyen, mert minden kisebb-nagyobb üzleti területen van egy-két ember, aki kisebb-nagyobb projekttapasztalattal bír, és ezért kinevezték projektvezetőnek, hanem legyen egy központi helyen egy csapat, aki egymást is folyamatosan képzi, és akinek a vezetőjétől elvárhatom a számomra fontos projektvezetési módszertant, ami nem elvek, hanem alapvetően sztenderdek, alapvetően gyakorlatok, amik az előbbi szempontokat biztosítják. Ugyanakkor, ha így teszek, és itt jön, talán ez még úgy nagyjából megvan mindenkinek, de itt jön a nagy trükk, hogyha úgy döntök menedzsmentként, hogy egy csapatot hozok létre projektvezetőkből, és onnan delegálok a mindenféle projektre projektvezetőt, akkor az nagyon fontos lesz, hogy ki lesz az a szakmai vezetője az adott projektcsapatnak, aki viszont magáénak érzi a projektet, és aki lehetőség szerint át fogja venni a projekttől, vagy az ő főnöke át fogja venni a projekttől a leszállított rendszert, folyamatot, dokumentumcsomagot, bármit, mert ha nincs ilyen, a projektvezető addig van ott, amíg a projekt van, utána ő visszamegy a saját

területére, neki az egy biztonságot ad, és nem lesz annyira fontos neki, vagy nem fogja annyira mélyen érinteni, hogy hogyan is zajlik a megoldás, mint az, aki utána átveszi.

Kérdezzek valami bölcset?

Nem, legyen ez a végszó. Azt hiszem, ma sem értünk vissza a hallgatóink türelmével, én ebben bízom, és nagyon köszönjük Péter, hogy velünk tartottál ezen az utazáson. Köszönöm a lehetőséget. Köszönjük szépen.